#ubuntu-release 2011-03-07
<bdmurray> natty alpha 3 is still listed as a valid milestone in Launchpad
<cjwatson> bdmurray: fixed, thanks
<cjwatson> (I think the term you want is "active" rather than "valid")
<bdmurray> cjwatson: ah true.  If I were just part of the team I wouldn't need to use any term and could just fix it. ;-)
<skaet_> bdmurray,  I tried last week, but there still seem to be permission issues.  :P
<bdmurray> skaet_: oh, right the not allowed to +edit issue
<skaet_> yuppers... :P
<doko> skaet_: didn't hear back from the kubuntu guys about kde buildability
<skaet_> doko, ack
<ScottK> doko: Could you upload qt4-x11 building aganist gcc 4.5 to your toolchain PPA?  It would make testing a lot easier.
<doko> ScottK: gcc-4.5 is building in natty, ogra will take care of it
<ScottK> doko: OK.  That'll work.
<charlie-tca> Could I have all powerpc builds stopped completely?
<charlie-tca> oops, "I" being Xubuntu
<skaet_> cjwatson, ^^ ?
<ScottK> charlie-tca: I bit of "why" would be useful.
<cjwatson> I thought I already did.
<cjwatson> the current ones are just carried over - I've removed them
 * cjwatson fixes the alternate/server builds too
<charlie-tca> Thanks
<charlie-tca> ScottK: because Xubuntu has no developers and testers for ppc. We have not had any for 9 months, and advertising for help has failed for 6 months
<ScottK> charlie-tca: OK.  I didn't realize you meant ISO builds.  I thought you were talking about package builds and was concerned something had gone wrong.
<charlie-tca> I already have both maverick and lucid 10.04.2 out without testing, and they don't really well for the very few that try to install them
<ScottK> Right.  Once I realized you were discussing ISOs, I think it makes total sense.
<micahg> I heard this is the place for archive admin requests?
<micahg> slangasek: are you available to apply some archive overrides?
<slangasek> can be
<micahg> slangasek: http://pastebin.ubuntu.com/577159/
<micahg> slangasek: and is this the best place to ask for these?
<slangasek> this is fine :)
<micahg> slangasek: thank you :)
<slangasek> do I need to apply these overrides to updates or proposed too?
<micahg> I guess it depends if they were copied to -updates yet
<micahg> not -proposed though
<micahg> looks like they're just in -security at the moment
<slangasek> ok
<slangasek> micahg: overrides done
<micahg> slangasek: thanks
<slangasek> micahg: incidentally, a '-y' in there would've made it easier to cut'n'paste the commands :)
<micahg> slangasek: I'll ask jdstrand about that when he gets back tomorrow, thanks
#ubuntu-release 2011-03-08
<cjwatson> https://answers.launchpad.net/launchpad/+question/148358 (FYI0
<cjwatson> )
<skaet> cjwatson,  thanks!
#ubuntu-release 2011-03-10
<bjf> skaet, when you have some time ... :-)
<bjf> skaet, when you have some time ... :-)
<bjf> skaet, sorry, that second one was a typo
<skaet> bjf, yup?
<lamont> there will be a brief manual period for the builders
<lamont> shuffling the world through manual for a bit of maintenance.  should be on manual for about 5 minutes
<lamont> this is so much nicer with a script...
<lamont> and all back
#ubuntu-release 2011-03-11
<Daviey> skaet, Regarding the bugs that doko hilighted earlier, bug 730759 & bug 730760, holstein (ubuntu-studio) will be at the release meeting to try and find a resolution.
<ubot4`> Launchpad bug 730759 in dbus-c++ (Ubuntu Natty) (and 1 other project) "[MIR] b-d for libffado (affects: 1) (heat: 14)" [High,Incomplete] https://launchpad.net/bugs/730759
<ubot4`> Launchpad bug 730760 in libconfig (Ubuntu Natty) (and 1 other project) "[MIR] b-d for libffado (affects: 1) (heat: 14)" [High,Incomplete] https://launchpad.net/bugs/730760
<ScottK> Daviey: Release meetings aren't generally about finding solutions, but reporting them.
<Daviey> ScottK, agreed :)
<Daviey> <Daviey> holstein, I know it's short notice, but If you can try and come up with a solution in time for the meeting - that would be awesome.
<jdstrand> skaet: looking at MeetingAgenda, http://people.canonical.com/~platform/workitems/natty/all-natty-beta.html is a bum link
<jdstrand> skaet: (fyi, and hi!)
<skaet> jdstrand,  ack - will go scrub and see if I can figure out what happened.
 * skaet thought she'd got them all cleaned up ...
<skaet> jdstrand - thanks for flagging it :)
<jdstrand> skaet: np :)
<skaet> jdstrand, its: http://people.canonical.com/~platform/workitems/natty/all-ubuntu-11.04-beta.html
<jdstrand> skaet: thanks
 * skaet thinks it looks a bit weird though... 
<skaet> pitti,  can you take a look,  ^^^
<pitti> skaet: this is an obsolete page -- the milestone was renamed to beta-1
<pitti> http://people.canonical.com/~platform/workitems/natty/all-ubuntu-11.04-beta-1.html
<pitti> jdstrand: ^
<skaet> thanks pitti,  much better.
<jdstrand> ack
<skaet> hmmph,  caught another one that was renamed as well.
<skaet> If anyone else spots broken links, please flag them, so we can clean up from the renaming.
<pitti> skaet, jdstrand: I removed all these old beta files now
<skaet> pitti,  thanks!
#ubuntu-release 2012-03-05
<pitti> Good morning
<nigelb> Morning pitti!
<mvo> if someone could check/accept the release-upgrader-apt to lucid-proposed I will make the auto-upgrade-tester run against that to check that #927993 is really fixed with it. there should be no regression potential as by default we use the release-upgrader-apt in lucid-updates
<infinity> mvo: I sure wish apt's build system could make the diffs between source versions even MORE unreadable. ;)
<infinity> mvo: Looks good, though.  Accepting.
<infinity> mvo: FTBFS.  You broke translations.
 * infinity fixes.
<infinity> mvo: Unless you're already fixing it, I'll fix your apt upload for you.
<mvo> infinity: I haven't fixed it yet, sorry, was at lunch, I can do it (its trivial) but will be equally happy if you do it :)
<mvo> infinity: I fixed it and re-uploaded, sorry for the trouble
<infinity> mvo: Accepted.
<mvo> ta!
<mvo> infinity: yay! i386 build - now in binary NEW, I wasn't aware that proposed needs to go through both NEWs, I learn something new every day :)
<cjwatson> -proposed isn't special regarding NEW
<infinity> Although, it seems like a bug that -proposed doesn't check -updates for NEW status.
<infinity> (I had to NEW the source too for the same reason, despite it already existing in updates)
<mvo> hm, so https://launchpad.net/ubuntu/+source/release-upgrader-apt/0.8.16~exp12ubuntu1~upgrader3/+build/3260800 tells me that there are a a bunch of binaries in -proposed that need NEW)
<infinity> I assume it's only comparing to the release pocket.
<mvo> aha, that makes sense
<infinity> mvo: Yeah, they'll get processes when all the builds are done.
<infinity> processed too.
<infinity> Err, crap, and I realised I NEWed it to universe, not main.  Will fix when I accept the binaries.
<cjwatson> it's based on whatever LP considers the ancestry of the pocket to be
<cjwatson> I kind of maybe agree that -proposed ought to include -updates in its ancestry.  I think.
<infinity> You'd think.
<infinity> It gets this right WRT which pockets are represented in sources.list, you'd think those same inheritance rules would only exist in one place (though obviously not).
<infinity> ie: release < security < updates < proposed
<cjwatson> Anyone have an opinion on whether bug 920545 needs a freeze exception?
<ubot2`> Launchpad bug 920545 in ntfs-3g "[update request] NTFS-3G, new STABLE Version 2012.1.15 [Precise]" [Wishlist,Confirmed] https://launchpad.net/bugs/920545
<cjwatson> We've tended to keep ntfs-3g pretty well up to date in the past.
<infinity> I believe the argument in the past was always "ntfs drivers kinda suck, so any bugs fixed are a win".
<infinity> I suspect that's still true.
<cjwatson> There are some new features, but they mostly seem to be opt-in kind of things.
<infinity> I see at least two fixes in there that fix real (visible to me) bugs.
<cjwatson> The library has got itself multiarched, but AFAICT it's only really usable by the ntfs-3g package itself seeing as it's no longer a separate sonamed binary package.
<infinity> So, I'd wave it through on the "can't be worse than it is" basis.
<cjwatson> So I can't see how that would break anything.
<Daviey> cjwatson: TBH, your opinion carries this.. it's only you that ever touches it.. so i guess you understand the issues more than the rest of us :)
<cjwatson> infinity: which, out of interest?
<infinity>     ntfs-3g: fixed endless recursion when MFT extents are described by themselves
<infinity>     ntfs-3g: fixed truncation of DOS file names (12 ntfschars, not 12 utf8 chars)
<infinity> Those two.
<cjwatson> Daviey: with a clothes peg firmly on my nose, I should add
<Daviey> heh
<infinity> I've run into the former, and it's nasty.  And the latter is just cosmetically ugly.
<Daviey> infinity: You sound like quite an ntfs user :)
<infinity> I used to run NT on several machines.  I'm reformed.
<Daviey> likely story..
<infinity> I wonder if anyone's working on a decent Linux driver for the new Win8 filesystem, or if we have to go through another ten years of reverse engineering pain.
<cjwatson> right, thanks all.  uploaded the merge.
<infinity> mvo: Component fixed and binaries accepted to main, should publish in the :03 run.
<mvo> awsome, thanks! I prepare the auto-upgrade-tester to use it instead of the -updates version
<pitti> huh, why did ntfsprogs suddenly go to universe..
 * pitti promotes it back to main
<cjwatson> probably because ntfs-3g turned it into a transitional package
<pitti> ah, so udisks' recommends need updating
<davmor2> cjwatson: do you happen to have a system you can try a d-i install on that has a wireless card in it?  if I go on wlan0 as my main network interface, I get q1. as If you would like to use any available network, leave this field blank,  I do,  It does a search finds nothing,  q2to skip wireless config and continue leave this field blank I do again and then it goes on to ask me what network I want to use wep/ope
<davmor2> n or wpa which to me isn't skipping
<cjwatson> davmor2: not without losing my current working state
<cjwatson> do an install with DEBCONF_DEBUG=developer in the boot parameters and extract syslog
<cjwatson> making sure to go through that same UI flow
<davmor2> cjwatson: I can on wednesday right now I need to get a system up and running for tomorrow I managed to kill my desktop magically
<stgraber> davmor2: I should be able to test this fairly easily, will try to do later this morning
<davmor2> stgraber: ah cool if you can't give me a ping I can do it on wednesday as I say
<davmor2> stgraber: effectivly you leave the wifi questions blank both times ps the network I have is a wpa, there are no open or wep ones near by
<infinity> pitti: Surely, ntfsprogs wants to stay in main until post-LTS?
<nessita> ScottK: hi there! just saw you question in bug #945061 and since we're in a rush to have this landed today (and release to Ubuntu tomorrow, so strings are available ASAP), I'm letting you know that yes, we wrote the doc and translators lists (links to the email archive in the bug description)
<ubot2`> Launchpad bug 945061 in ubuntu-sso-client "[UIFe] Qt UI: the "Login" and "Forgotten Password" pages don't have titles and subtitles" [Undecided,New] https://launchpad.net/bugs/945061
<ScottK> nessita: Please say so in the bug.
<nessita> ScottK: sure, thanks
<nessita> done
<ScottK> nessita: Approved.  Also 944982.
<ScottK> nessita: Please get them uploaded quickly so the string changes will land soone.
<ScottK> soon....
<nessita> ScottK: sure I will, thanks a lot :-)
<stgraber> any archive admin planning on going through the pending package removals soon? bug 931809 is causing some confusion at the moment because we have both the lttng 1 and lttng 2 stacks in the archive
<ubot2`> Launchpad bug 931809 in ust "Please remove the old LTTng packages from the Ubuntu archive" [Undecided,New] https://launchpad.net/bugs/931809
 * ScottK wishes he had powerz for removals.
<pitti> infinity: yes, that too; but someone moved it to universe, and it showed up on c-m
<infinity> pitti: Yeah, weird that it moved at all.
<cjwatson> possibly a side-effect of changing source package, though still odd
<infinity> Oh, not odd if it was removed and then NEWed.
<infinity> But very odd (and potentially buggy) if it changed source packages and soyuz just decided to demote it willy-nilly.
<ara> skaet, ping
<skaet> hiya ara,  pong but otp...
<stgraber> davmor2: ok, reproduce the bugs (first one is that it doesn't show any wireless, second one is that it doesn't skip with the essid field being empty)
<stgraber> *reproduced
<davmor2> stgraber: it's nice to know it's not just me for a change :)
<davmor2> cjwatson: ^
<cjwatson> stgraber: do you have a DEBCONF_DEBUG=developer log?
<cjwatson> davmor2: bear in mind I just got back off leave and this isn't top of my list :-)
<stgraber> cjwatson: yes, just need to get it off the test machine ;)
<stgraber> cjwatson: I found the problem with the scanning though (at least I think)
<cjwatson> ok
<stgraber> netcfg brings the interface up/down every second during the scan instead of brining it up before the loop and bringing it down afterwards
<davmor2> cjwatson: yeap noted
<stgraber> so if the card takes > 1s to be ready to scan (as most cards seem to), then you won't get anything
<cyphermox> davmor2: I was planning on checking out a d-i install with wireless very soon, I could get this done today if it helps. just let me know exactly what you're looking for, since i'm more trying to reproduce leftover configs from d-i that shouldn't be there after install (otherwise NM doesn't grab the wifi device)
<cyphermox> nm, I didn't see some of the backlog
<stgraber> can someone from the release have a quick look at bug 946861? it's a minor UI change in epoptes (Edubuntu only) and I confirmed it's not affecting any existing screenshot or documentation
<ubot2`> Launchpad bug 946861 in epoptes "[UIFe] show real name menu entry" [Undecided,New] https://launchpad.net/bugs/946861
<ScottK> stgraber: Go for it.
<ScottK> Feel free to copy/paste that in the bug.
<stgraber> ScottK: thanks
#ubuntu-release 2012-03-06
<ScottK> slangasek: Not that I particularly care in this case, but seeing that your gconf upload introduces two new binary packages, shouldn't there have been an FFe?
<slangasek> ScottK: hmm, yes, it probably ought to have - sorry
<ScottK> Consider yourself suitably chastized.
<slangasek> ScottK: could be worse, I could've managed to upload this completely broken patch to soprano I've been working on that my test methodology was broken for :)
<ScottK> slangasek: It depends.  If that would stop Nepomuk eating my CPU it might be a net win.
<slangasek> heh
<ScottK> Actually that's gotten much better recently, but it's fun to complain about.
<knome> hey jibel
<jibel> knome, morning
<knome> jibel, did you get my PM, or should i repost? :)
<jibel> knome, I didn't get it
<knome> jibel, oki - just a sec, i'll PM you again
<greyback> Hi, I need somebody to consider this FFe please: https://bugs.launchpad.net/ubuntu/+source/unity-2d/+bug/947976
<ubot2`> Launchpad bug 947976 in unity-2d "[unity-2d] FF exception to add PointerBarrier to Unity2d" [Undecided,New]
<stgraber> good morning. I'd appreciate it if someone from the release team could look at bug 944849 and give a go/no-go. thanks!
<ubot2`> Launchpad bug 944849 in isc-dhcp "[FFe] converting isc-dhcp from sysvinit to upstart" [Undecided,New] https://launchpad.net/bugs/944849
<skaet> Daviey,  could you weigh in on the implications of FFe 944849 ^,   can we stabilize this change if it lands before 3/15?   Any interactions with the other changes already planned that you're aware of?
<skaet> stgraber,  would the change be able to be landed before 3/15?
<stgraber> skaet: yes
<stgraber> skaet: I'd likely have it done and tested this week
<stgraber> it was initialy an ubuntu-server work item I stole from Daviey's team as they didn't have enough time to do it for 12.04
<skaet> thanks stgraber,  that's what I was hoping to hear.  :)
 * skaet smiles at that... ;)
<Daviey> skaet: I'm not too concerned about that.  stgraber knows what he is doing, and it's easy enough to rollback if we need to.
<skaet> Daviey,  it was more if there were implications with any of your other plans/fixes landing that I was wanting to make sure you had input.
<skaet> but if you don't forsee any issues, with the other fixes landing,  and it can be done this week,  I'm ok with it.
<Daviey> skaet: Yep, thanks.  I understand it, that for IPv4 it would be no-change.. and currently, none of our specific plans are dependant on ipv6 features.
<Daviey> So works for me :)
<skaet> Daviey,  coolio.
<skaet> stgraber,  I'll go put an approved comment in the FFe with the caveat that the work must land before 3/15
<stgraber> skaet: ok, thanks
<skaet> thanks stgraber for improving the IPv6 story.  :)
<Daviey> \o/
<Daviey> stgraber: If you kill my home ipv6 network, i will punish you. kkthnx
<greyback> Hi, I need somebody to consider this FFe please: https://bugs.launchpad.net/ubuntu/+source/unity-2d/+bug/947976
<ubot2`> Launchpad bug 947976 in unity-2d "[unity-2d] FF exception to add PointerBarrier to Unity2d" [High,New]
<stgraber> Daviey: are you using dhcpv6? otherwise you should be fine (or I broke it already) ;)
<Daviey> stgraber: Would you hate me if i said i was still using radvd?
<stgraber> Daviey: no, that's what I'm using here ;)
<stgraber> Daviey: and you'll always need radvd, even with stateful dhcpv6 as dhcpv6 won't announce the default gateway (and you need to set the "other-config" flag in radvd for your clients to start doing dhcpv6)
<skaet> greyback,  need to understand the timing of when your Feature would end up landing.   didrocks,  any concerns about 947976?
<Daviey> stgraber: ah, cool
<didrocks> bug #947976
<ubot2`> Launchpad bug 947976 in unity-2d "[unity-2d] FF exception to add PointerBarrier to Unity2d" [High,New] https://launchpad.net/bugs/947976
<didrocks> skaet: the metacity patch I saw is pretty straightforward
<didrocks> skaet: and unity-2d team is good at writing tests
<didrocks> so I guess that if this is tested as usual with the freeze process
<didrocks> that's fine (and before beta2)
<skaet> didrocks, ok,  its just a question then of when it might be landing and visible,  and how close up to Beta 2 it becomes.   Any insight there?
<didrocks> skaet: next unity/unity2d release (we are still trying to land unity 3d 5.6) will be the 22 march (after freezing our own code the Monday before)
<didrocks> so tests between monday and thursday
<didrocks> and release on time for beta2 freeze
<skaet> didrocks,  landing it right on the freeze is a bit risky - what will the fall back be?
<didrocks> skaet: well, we do that now that we have a freeze period
<didrocks> skaet: as before we land, we have 4 full days of testing and only fixing the unity release critical
<didrocks> and it worked well so far
<didrocks> so it's not "we are cutting a release on thursday"
<didrocks> it's "we are prepping the release starting the monday before"
<skaet> just so I'm clear,  when does 5.6 actually land?   and what will the number be of the one on 3/22
<greyback> During that test period we work closely with distro to ensure all concerns are dealt with
<didrocks> skaet: for unity 2d 5.6 has already landed, 5.8 will be the next one
<skaet> didrocks,  my definition of landed for a component is that its in the archive ;)   I'm still seeing 5.4 as the version there....   when will 5.6 be showing up.
<skaet> https://launchpad.net/ubuntu/+source/unity
<didrocks> skaet: we are speaking about unity-2d here
<didrocks> not unity
<didrocks> this FFe is about unity-2d
<didrocks> https://launchpad.net/ubuntu/+source/unity-2d
<skaet> didrocks, gotcha
<skaet> didrocks, how can we have a unity 5.4 and unity-2d 5.6 in the archive?   I'm afraid I need a bit of education, and I had assumed that both needed to be at the same release number?
<didrocks> skaet: not at all
<didrocks> skaet: we just try to have rougly the same release versionning at the same time
<didrocks> skaet: but even last cycle, the versionning was totally separated
<didrocks> you can think them as two different applicatoins
<didrocks> which, they really are
<didrocks> some parts are in common, like libunity-core
<didrocks> when they preserve API/ABI stability, they are not really linked
<didrocks> (as it's not because a new gtk is out that all GNOME apps are released)
<didrocks> and older GNOME apps still work
<skaet> Thanks for the explanation didrocks.  :)
<didrocks> skaet: you're welcome :)
<skaet> didrocks, https://wiki.ubuntu.com/Unity/ReleaseSchedule has unity-2d 5.8 listed for 3/8 (which I have to admit, am much more comfortable with for the FFE;) )   is unity-2d 5.8 3/8 or 3/22?
<didrocks> skaet: 3/22, not sure who put the date here
<didrocks> certainly not someone making the release :)
<skaet> didrocks, dbarth is page author...
<cjwatson> https://wiki.ubuntu.com/Unity/ReleaseSchedule?action=diff&rev2=15&rev1=14
<didrocks> not sure he has the insight of the release timing then
<didrocks> as well, the LIM is almost 100% sured to be canceled
<didrocks> (in both 3d and 2d)
<skaet> didrocks,  can you work with dbarth to get that page updated please?   we need to know accurately what's landing and when so we can prevent a pileup/system level breakage on beta freeze date.
<didrocks> skaet: speaking with the unity-2d guys right now, we can try having a micro release starting next week, just containing the barrier work to make everyone life easier
<didrocks> then, regular 5.8 release (bug fix only) for 3d and 2d on the 22
<didrocks> wdyt?
<skaet> didrocks,  that would be great if we can manage it.  :)
<greyback> Yes I think it's a good solution to the problem
<didrocks> skaet: it's more work, but overworked to be overworked alreadyâ¦ let's try this
<skaet> thanks didrocks
<didrocks> yw :)
<greyback> skaet: thanking you
<greyback> skaet: Many thanks, your reservations are understood
<skaet> thanks greyback. :)
<ralsina> quick question: ubuntuone-control-panel-qt has a wrong --help. Is that covered by UI freeze? It's not translated.
<cjwatson> I don't think there's any need to regard --help as covered by UI freeze
<ScottK> Maybe we should call it GUI freeze.
<ralsina> ok, thanks!
<utlemming> smoser: I think that adding the apt config of "Acquire::Retries=3" should fix some of our EC2-archive pain
<utlemming> smoser: per the docs, it sets the "Number of retries to perform. If this is non-zero APT will retry failed files the given number of times."
<Laney> ProgramSurfacesIncludedDirectlyInOfficialDocuemtationFreeze
<debfx> hrm, I just uploaded inkscape to add recommends: libgnomevfs2-extra without noticing that it's in universe
<debfx> the source is in main though
<debfx> do you want me to revert that upload?
<micahg> I don't think the desktop team wants to support gnomevfs anymore
<Laney> indeed, don't think we should be supporting that
<Laney> the feature that requires it should use gio now ideally
<debfx> upstream says the next release will use gio but that won't happen in time for precise
<Laney> might have to take that hit then
<Laney> perhaps you could improve the error message to give users more of a clue
 * Laney out
<debfx> micahg: as I said gnome-vfs is in main anyway. it's just about the extra backends.
<seb128> do we need inkscape in main?
<stgraber> isn't it on the DVD image?
<debfx> yes
<micahg> gnome-vfs still has a few build depends in main (firefox, thunderbird, shotwell)
<seb128> chrisccoulson, ^ what are you doing!
<seb128> micahg, shotwell seems a mistake, I though firefox,tb were using gio?
<micahg> seb128: they should be using gio, it's only a build time depedency
<micahg> seb128: all of those were build time only dependencies, here's the runtime dep list: http://paste.ubuntu.com/871965/
<chrisccoulson> micahg, seb128, the build-dependency is there as an artefact of the fact that we can't have per-release build-depends from the same branch
<chrisccoulson> and older releases build with gnomevfs
<chrisccoulson> although
<chrisccoulson> i should change that. we're going to be purging all gnomevfs support from firefox anyway
<micahg> chrisccoulson: you could do that with control.in, but as you said, it's a moot point now
<chrisccoulson> micahg, that wouldn't work in any case. which is why i haven't done it ;)
<micahg> chrisccoulson: well, if you regenerate control.in before uploading it would (the problem is changing control.in in the clean rule, nothing says you couldn't modify the bot to do it separately :))
<micahg> err..s/control.in/control/, but this is getting OT
<ScottK> Does "... but we will SRU key items ..." in http://www.markshuttleworth.com/archives/1027 imply that SRU policy is going to change for 12.04 to add new features post-release?
<infinity> ScottK: I don't think it implies that, and that's certainly not something any of the release team is aware of being new policy (and we're the people who'd need to implement it, and the TB would need to approve it...)
<infinity> ScottK: I'm choosing to read it as "Unity's not perfect, but we promise to keep fixing bugs, even post-release".
<ScottK> I'm good with that.
<ScottK> I hope you're right.
<infinity> Meh, if it means something more, I'm happy to take it to the TB.
<stgraber> yeah, haven't heard of any change on the TB side either, so I assumed it was just usual SRUs (bugfixes only)
<infinity> The same TB that Mark stepped down from, specifically to avoid these sort of conflicts of interest, I suspect. ;)
<infinity> s/sort/sorts/
<stgraber> hmm, that never prevented him sabdfl-ing changes though, just that now it can say that the TB was against it ;)
<infinity> Policy changes are a bit different from sabdfling, say, new software during a development cycle, etc.
<infinity> Not that I'm saying we won't consider sabdflication of SRU policies, but we (both -release and TB, I suspect) will stand up against it, I'm sure.
<infinity> Anyhow, like I said, I'm choosing to read that blog post as "we'll fix bugs, honest".
<infinity> Which is an important commitment to make when you're shipping something that you admit you know has bugs.
#ubuntu-release 2012-03-07
<suihkulokki> Since I got approval to elfutils update, LP#934433, where do I find someone to do the upload?
<pitti> suihkulokki: did you check whether we can sync?
<pitti> an overview about the changes in the new upstream release would be nice (upstream changelog etc.)
<micahg> suihkulokki: elfutils was just uploaded
<suihkulokki> pitti: there is quite a bit of changes, not just bugfixes, so I thought it is better to a minimal update
<pitti> suihkulokki: ah, thanks for checking
<suihkulokki> micahg: thanks
<micahg> can someone please tell me if syncevolution needs an FFe: http://anonscm.debian.org/gitweb/?p=collab-maint/syncevolution.git;a=blob;f=NEWS;h=1907b2f4cf08eab9f5649212c93be8fec71ef26e;hb=HEAD
<micahg> we're at 1.2.1 right now
<tumbleweed> micahg: I wouldn't think so
<micahg> tumbleweed: thanks
<Laney> looks ok to me
 * cjwatson retries the Xubuntu alternate build, which failed for transient reasons
<cjwatson> that's better, worked that time
<dobey> does bug #949424 make any sense to people?
<ubot2`> Launchpad bug 949424 in rhythmbox "[UIFe] String and feature changes in new Rhythmbox" [Undecided,New] https://launchpad.net/bugs/949424
<ScottK> dobey: It needs more detail on the packaging changes you're proposing.
<ScottK> (can't approve "maybe we should re-enable Magnatune", need what the plan is)
<dobey> ScottK: right. i said "maybe" because i am not sure if we should or not. technically not having it is a regression, but i'm not sure it's big enough of one to bother with this late.
<ScottK> Avoiding a regression is good.
<dobey> if we do re-enable it, it's one of the things i'd like to split to a new binary
<ScottK> If it's a seperate binary and  you can find an archive admin with time to review it, not regressing is good and I'd imagine low risk.
<dobey> it didn't used to be. but since i'm also proposing some binary reorg, i think i can fit it in there :)
<dobey> ScottK: updated the description
<ScottK> OK.
<ScottK> I'd see if you can find an archive admin with time (not me)
<dobey> slangasek: wink wink :) ^^ care to look?
<slangasek> dobey: I have time to binary new these for you, yes, and if the only reason you're on the fence about -magnatune is because of the freeze, Just Do It
<slangasek> it's a regression, it's straightforward to fix
<dobey> slangasek: i'm on the fence because it changes strings. but if you think we should do it, i will. :)
<slangasek> ah, what are the string changes for magnatune?
<dobey> there are a couple of s/purchase/download/. and i think 3-4 more strings which seem to be entirely new. i'll have to look at the diff (it's huge) and find them again
<slangasek> but even if built, this wouldn't be installed by default, right?
<slangasek> so isn't really covered by https://wiki.ubuntu.com/UserInterfaceFreeze
<dobey> well, i'd guess we'd want to have -plugins recommends it, to avoid it disappearing on upgrade?
<slangasek> that's not necessarily true
<slangasek> I think it's more important that it continues to be available, than that it continues to be installed by default
<dobey> ok
<dobey> i need to run now, but i'll check back later. there are some important bug fixes we need for the u1 plug-in, so trying to get it cleaned up a bit as well. thanks
<stgraber> is there any cdimage admin around? I just noticed Edubuntu doesn't have .metalink files generated on cdimage, breaking wubi...
<infinity> I might be.
<stgraber> infinity: hey there. I did a quick grep in my usual branches and couldn't find any reference to metalink, so my guess is that it's a private or very obscure branch :)
<infinity> Really, this code's private-only?
<stgraber> anyway, I see that ubuntu, xubuntu, ... dailies all have it, so it's likely some kind of check that needs tweaking
<slangasek> infinity: yup, new code
<slangasek> so it's private only
 * infinity grumbles.
<stgraber> well, either private or not easy to find in the branches I have around (debian-cd, livecd-rootfs and live-build)
<infinity> That list is conspicuously missing cdimage.
<stgraber> oh, good, so it's not me looking at the wrong place, there indeed wasn't anywhere to look then :)
<stgraber> apparently all the daily-live ones have it but Edubuntu is "dvd" and I can't find another dvd product with it, so that might be the current check
#ubuntu-release 2012-03-08
<infinity> Yeah, I suspect it's something like that going wonky.
<infinity> Although, it's not in the TYPE check.
 * infinity scratches his head a bit.
<infinity> Oh lolz.
<infinity> I was looking at publish-release, which may or may not get it right.
<infinity> But publish-daily doesn't.
 * infinity just adds -dvd to the acceptable metalinky targets, since that already kinda happens for publish-release anyway.
<infinity> stgraber: edubuntu does match IMAGE_TYPE=*-dvd, right?
<infinity> Yeah, looks like it.
<stgraber> it should yeah
<infinity> stgraber: Should be fixed, then.
<stgraber> thanks
<infinity> Serious disconnect between publish-daily and publish-release there..
<infinity> One is an inclusive list, the other exclusive.
 * infinity notices that 12 of the last 15 cdimage commits are his, and decides to ignore nusakan for a day.
<jbicha> hi, can I get a verbal FFe for https://mail.gnome.org/archives/ftp-release-list/2012-March/msg00080.html
<infinity> jbicha: Looks alright, as long as you promise it's going to link dynamically to libsqlite from the archive, and not include Yet Another Bundled Sqlite that the security team will shed tears over.
<jbicha> infinity: it won't build without libsqlite3-dev
<infinity> jbicha: That sounds promising, then. :P
<infinity> (I generally expect GNOME to DTRT with regard to system libraries, but sqlite it bundled everywhere, so I thought I'd ask)
<jbicha> should I add something to the changelog about this ffe approval?
<infinity> jbicha: No, just test and upload (and test again).
<infinity> jbicha: And point people to me if they ask.  But FFe stuff doesn't belong in changelogs, IMO.
<infinity> "I asked permission" isn't a change in the package. :P
<jbicha> infinity: ok, thanks! I wasn't looking forward to more paperwork tonight :)
<fabo> skaet: bug that I mentioned yesterday related to compiz -> bug 949805
<ubot2`> Launchpad bug 949805 in gcc-linaro "Linaro GCC packages don't by default use %gnu_unique_object" [Undecided,New] https://launchpad.net/bugs/949805
<skaet> thanks fabo
<fabo> yw
<ogra_> the endless unity gles story ... sigh
<skaet> pitti,  around?
<pitti> hey skaet
<pitti> skaet: sorry, was in a meeting
<bjf> infinity: do you know if there are any more buildds which are fsl-imx51 based still in operation (looking to see if we need to continue to support it)
<infinity> bjf: Distro buildds, no.  I think IS may still run a machine or three for OEM(?) that are babbages.  You might want to ask lamont.
<infinity> bjf: From the distro perspective, though, we're free and clear of babbages.
<ogra_> bjf, given a panda costs $175 you should just send a bill for each imx51 fix you have to do to the owner of tehse babbages, they will realize quickly that buying one or two is cheaper than paying -kernel for it ;)
<bjf> ogra_: heh, i like the suggestion
<ogra_> (i'm actually serious, the work we put in is surely more expensive than just buyinf a bunch of pandas)
<ogra_> *buying
<scott-work> is it too late to add a seed for ubuntu studio, if not, is a particular exception required?
<ScottK> scott-work: What is it you want to do?
<ScottK> (maybe, maybe not)
<scott-work> ScottK: i would like to add a "photography" seed to compliment the other multimedia tasks
<ScottK> scott-work: So it's an internal seed structure change for U-S and not a new image, right?
<ScottK> Does it also need a tasksel change?
<scott-work> ScottK: it would be an internal seed change.  a new image is not required.  that is my understanding
<scott-work> ScottK: i would normally suspect that we would need a tasksel change, but am unsure since we now use the live image and will be migrating to the ubiquity plugin
<ScottK> OK.  I think you need to understand what's needed from Ubiquity (if anything) for this change.
<ScottK> I think it needs an FFe, but it should be easily approved since I suspect the only foot you're at risk of shooting is your own.
<ScottK> Make sure you understand all the ramifications before you ask though.
<scott-work> ScottK: thank you :)
<scott-work> ScottK:  if we haven't implemented the ubiquity plugin and we are using the live image, i wonder how much of an issue this will be?
<scott-work> ScottK: it appears that currently _every_ task installs right now
<ScottK> That's normal, IIRC.
<scott-work> the reason i mention this is because we may postpone the ubiqutiy plugin until next cycle
<scott-work> so it would seem to be a pretty minimal (relatively) consideration, no?
 * scott-work suspect he is grossly missing a point or two :P
<ScottK> It probably affects nothing bug your seeds and so I'm not sure what the point would be as the same packages end up installed.
<scott-work> ScottK: is your suggestion that we just add the desired packaged to another seed then address the structural changes later when the ubiquity plugin is implemented since everything is installed anyways currently?
<ScottK> That's what I was thinking.
<ScottK> It doesn't matter much either way as it just affects internal structure.
<scott-work> ScottK:  good points, i think this is what i will consider then and then address the seed structure and ubiquity plugin next cycle
#ubuntu-release 2012-03-09
<GrueMaster> Can someone verify the beta 1 arm images for me?  I'm still getting failed checksums.  This is after zsyncing locally.  Twice.  http://paste.ubuntu.com/875432/
<infinity> GrueMaster: ubuntu-12.04-beta1-preinstalled-desktop-armhf+ac100.tar.gz: OK
<infinity> GrueMaster: Though I do have the server failures.
<infinity> GrueMaster: Mirrors should be correct now.  Someone should poke me violently tomorrow about finding the root cause of this issue, though.
<infinity> Oh, and I note that there's a bug, and it's been assigned to me.  Lovely.
<GrueMaster> Your welcome.
<ScottK> pitti: The stack of KDE related demotions that component mismatches wants to do look bogus to me.  For example, kcolorchooser is on list.  kdegraphics (which is in Main) depends on it: https://launchpad.net/ubuntu/precise/i386/kdegraphics/5:71~pre15ubuntu11 so why does component mismatches want to demote it (most if not all of the others are similar).
<pitti> ScottK: ok; it's possible it was because of the kde-mdeta/kubuntu-desktop uninstallability? they are gone from c-m as well now, anyway
 * pitti rebuilds ubuntu desktops and alternates, uninstallability is fixed now
<Daviey> pitti: did you promote maas-enlist?
<pitti> Daviey: no? I think I might have demoted it as part of cleaning up component-mismatches
<pitti> but I'm not sure any more which package that was
<pitti> (well, it was several)
<Daviey> pitti: you ACK'd it after jdstrands review, 4 hours ago.
<pitti> right, the FFE
<pitti> but it needs a reason to stay in main
<pitti> otherwise it'll keep falling out again
<Daviey> pitti: it's seeded
<Daviey> it's on c-m
<pitti> it was this morning
<pitti> but for main -> universe
<pitti> http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
 * pitti re-runs it
<pitti> c-m doesn't currently auto-update
<pitti> haven't had time yet to find out why
<Daviey> pitti: it was added to the seed a few days ago :/
<pitti> well, all I can say is that this morning it wanted to go back
<pitti> but perhaps it was another package
<pitti> Daviey: oh, right, that was there before
<pitti> Daviey: now I remember
<pitti> Daviey: I demoted cobbler-enlist
<Daviey> cool
 * pitti promotes maas-enlist
<Daviey> that was correct
<Daviey> thanks
<Laney> could someone score ghc/ppc up please? Looks like we might have a full arch set this time and I would like to avoid any possibility of skew.
<Laney> Took 1h49 last time, so it's not too chunky.
<cjwatson> done
<Laney> cheers
<Laney> cjwatson: also, could I ping about deploying ben?
<Laney> mehdi grabbed me about it the other day
<cjwatson> gcc-4.4 is nearly finished so it should start after that
<cjwatson> oh yeah, ok - I should write up my release meeting stuff first, then I'll have a look
<Laney> cool
<Laney> note that i haven't merged the new config branch with what we currently have for some time
<Laney> we should be able to simplify the configs using the new global.conf stuff
<Laney> urg, there is a new dep if we want to merge upstream again
<Laney> libtyxml-ocaml-dev
<ScottK> pitti: Thanks.
<Riddell> does the release-team meeting have a new format this week?
<pitti> I believe so
<Riddell> pitti: so do I send in a report or do something else?
<pitti> Riddell: the report format hasn't changed
<pitti> just that the meeting won't be a standup round any more, but free form questions AFAIR
<Riddell> pitti: and we read all the e-mails before then ask questions in channel
<pitti> right
<Riddell> I wonder if skeat is planning to do a "poke read e-mails now" before the meeting
<ScottK> We should decide in advance who we're going to pick on and everyone have a question to fire at that one person.  More fun that way!
<ScottK> ;-)
<pitti> fortunately IRC has a natural way of serialization :)
<Riddell> how do I log into a live CD if it puts me at a login manager?
<Riddell> oh the user changed, got it
<doko> skaet, cjwatson, apw, ogasawara: sorry, forgot to send email about yesterday's gcc-4.6 upload. changes affect ARM only. will send email later today
<ogasawara> doko: ack thanks, I'll hold our upload till gcc's finished building
<skaet> doko, prewarning of a day before the upload would be appreciated at this stage in the release cycle.
<skaet> doko,  any more bug fixes on the horizon for gcc/eglibc/binutils between now and beta freeze?
<doko> skaet, just a gcc-defaults upload to make gccgo (universe) point to 4.7 once it's built
<skaet> doko,  thanks. :)
<doko> afk now, getting breakfast
<doko> skaet, wait, there are still two eglibc issues left. jodh looks at 508083, and I have to look at 929219. not sure if before beta2
<skaet> doko,  gotcha, thanks. keep me posted please.  :)
<Daviey> Okay if i do a server (i386|amd64*) respin?
<Daviey> inprogress
<stgraber> infinity: your metalink fix didn't seem to work for some reason... http://cdimage.ubuntu.com/edubuntu/dvd/20120309/
<cjwatson> Daviey: sure
<infinity> stgraber: Curious.  I'll look at that later today when I'm also looking at hash sum weirdness.
<stgraber> infinity: thanks
<ogra_> infinity, yeah, its intresting that ac100 has a proper one ... iirc cjwatson fixed that on my request in the last alpha, i looked but coundt find a commit related to it though
<ogra_> *couldnt
<infinity> I'm sure it was fixed by hand, like I just fixed the beta by hand.
<infinity> But I'm going to look into the root issue later today.
<cjwatson> I wittered about it on IRC at the time
<ogra_> i thought that was about the bashism in our -boot script
<cjwatson> 2012-02-01
<Daviey> pitti: where did you get the '8 mins' per cd build from?
<cjwatson> not just that no
<cjwatson> http://irclogs.ubuntu.com/2012/02/01/%23ubuntu-release.html#t11:54
<cjwatson> note that I went down a blind alley there for a while so read the whole thing rather than believing my initial comments :)
<cjwatson> I thought that the checksum-directory change I made had fixed this
<cjwatson> and I think also the publish-daily change; but evidently not
<infinity> cjwatson: It's not ac100-specific, I think it's more to do with carrying over old builds into new directories.
<cjwatson> right, that was what the checksum-directory change was supposed to be about, though
<infinity> cjwatson: Which is only rarely done in the case of arch-only respins, but now ARM does it on every run.
<cjwatson> anyway, just a place to start
<infinity> cjwatson: But yeah, I'll look later today, it's on my TODO.  Purge it from your mind. ;)
<cjwatson> I might've screwed up the -nt test or something
<pitti> Daviey: if you start the buildlive program on cdimage, you can see the start and end time from the buildds
<Daviey> pitti: right, but seems to take *much* longer for non-live :)
<Daviey> oh, not *much* longer, that was an exaggeration
<pitti> Daviey: alternates should take less than 10 (didn't measure)
<pitti> Daviey: cron.daily-live also take a bit, but it runs in parallel with the next buildlive
<ogra_> Daviey, about time to produce live server images then :P
<Daviey> ogra_: please drive a blueprint at UDS for that :)
<Daviey> (i'm not kidding.)
<ogra_> heh, only if NM goes onto the server-live image :P
<ogra_> (are you actually thinking about live builds ?)
<cjwatson> Riddell,Daviey,ogra_,pitti,etc.: https://wiki.ubuntu.com/ReleaseTeam/CDImageSetup
<Daviey> ogra_: Considering a squashfs into d-i.
<ogra_> whee
<Riddell> cjwatson: lovely, thanks, can you link to it from the description of this team? https://launchpad.net/~ubuntu-cdimage
<Riddell> I expect that's where I'll look when I've forgotten
<ogra_> cjwatson, pretty clear, thx
<cjwatson> Riddell: sure, done
<ogra_> hmm, i have never sudoed to cdimage before deploying ... good that you wrote that up :)
<cjwatson> that would be why there are lots of files owned by ogra then? ;)
<ogra_> heh, sorry
<infinity> Tsk.
<cjwatson> can actually cause problems sometimes - best to always sudo to cdimage before doing anyway
<cjwatson> anything
<ogra_> yeah, i think the distinction of production/development helps there
<ogra_> that way i will always sudo right after login
<micahg> pitti: gilir: skaet: lightdm-gtk-greeter just needs to be consolidated, I have two source packages at the moment that need to be merged and I"ll endeavor to do that over the weekend
<gilir> thanks micahg :) Let me know if you want help for this
<micahg> gilir: I'll need a review of the combined package before upload
<skaet> thanks micahg.  :)
<sbeattie> pitti: FYI, the eglibc package in maverick-proposed to fix bug 605042 has been superceded; also, for some reason that bug was not showing up on the SRU tracking page that I can see.
<ubot2`> Launchpad bug 605042 in eglibc "[armel] java fails to start with eglibc-2.12-0ubuntu4" [High,Fix committed] https://launchpad.net/bugs/605042
<Laney> is anyone available to process bug #951206?
<ubot2`> Launchpad bug 951206 in haskell-deepseq "RM: Provided by GHC" [Undecided,Confirmed] https://launchpad.net/bugs/951206
<slangasek> Laney: what does 'provided' mean?  Is this a source-only removal because the binary should come from somewhere else, or does ghc now ship it in the main binary package?
<slangasek> n/m, see it in the ghc binary package
<slangasek> removing
<Laney> it means that ghc now exposes that library
<Laney> and Provides it in the packaging sense too
<Laney> cheers
#ubuntu-release 2012-03-10
 * cjwatson fixes archive-reports germinate triggering (i.e. component-mismatches and friends) by removing some stale files from the germinate results mirror
<cjwatson> hm, should remove them from cocoplum too, come to think of it
<cjwatson> micahg: can the natty backport in bug 927385 be approved?
<ubot2`> Launchpad bug 927385 in oneiric-backports "Please backport lives (1.6.1~ds1-1) from precise" [Undecided,Fix released] https://launchpad.net/bugs/927385
<broder> cjwatson: i'll ack that, since quadrispro has tested it
<cjwatson> cool
<cjwatson> and processed
<Daviey> Could an AA accept the binNEW's coming out shortly, please?
<Daviey> (curl)
 * cjwatson has officially had enough of archive admining for today, sorry :)
<cjwatson> down to 17 open tasks from something like 77
<cjwatson> 15 shortly
<Daviey> thanks anyway.
<cjwatson> hm, it's just a udeb, maybe I can manage that
<Daviey> \o/
<cjwatson> yeah, ok, that looks fine, processed (to universe; if you need it in main, make something in main depend on it, or seed it, and that doesn't require an MIR for just a binary promotion)
<Daviey> cjwatson: That should have just happend.
<Daviey> well, 30 mins ago.
<cjwatson> ah, well, c-m will show it shortly then I guess
<Daviey> cjwatson: nope, pitti said earlier that it isn't auto-updating.
<Daviey> Unless he's fixed it since then?
<Daviey> "Generated: Fri Mar  9 10:58:53 UTC 2012"
<Daviey> He ran it by hand.
<cjwatson> I fixed it
<cjwatson> 00:12  * cjwatson fixes archive-reports germinate triggering (i.e. component-mismatches and friends) by removing some stale files from the germinate results mirror
<cjwatson> 00:12 <cjwatson> hm, should remove them from cocoplum too, come to think of it
<Daviey> ah, groovy
<Daviey> cjwatson: Can i be a real ass, and ask you to promote it when it shows?  I'd really like to get it into the iso for tomrrow.
<infinity> Daviey: I can do it.
<Daviey> infinity: where were you hiding?
<infinity> I was hiding?
<cjwatson> I'll just do it now
<infinity> Okay, fine, I won't do it. :P
<Daviey> infinity: Ah, i bet you were busy fixing grub upgrade issues?
 * infinity whistles.
<Daviey> :)
<infinity> Yes, that's exactly what I've been doing.
<infinity> It is actually on my list today.
<Daviey> \o/
<infinity> But my today is rapidly coming to an end.
<Daviey>  /o\
<infinity> I have an odd feeling I may get bored on the weekend, however.
 * cjwatson does the override-in-accepted trick.  should land in main for amd64/i386 at the next publisher run.
<infinity> Funerals aren't actually my thing.
<Daviey> cjwatson: appreciated
<infinity> cjwatson: I love how that displays in the UI when you do it.
<cjwatson> mm?
<infinity> cjwatson: Though, less obvious for binaries than source. ;)
<infinity> cjwatson: Next time you do it for source, check the UI claiming that it's publishing in both components.
<cjwatson> I did it in the command line, seeing as the web UI is useless for single-binary overrides
<infinity> (It sorts itself when it publishes)
<cjwatson> whwee
<cjwatson> *whee
<cjwatson> (yeah, 'cos the typo mattered)
<infinity> It sure did.
<Daviey> heh
<infinity> cjwatson: Also, it's the weekend.  I know you've missed us and all, but eff off. ;)
<infinity> Hrm.  Perhaps he actually effed off.  I'm magical!
<cjwatson> heh, yeah.  duly effing off, sir.
<infinity> Happy effing. ;)
<cjwatson> abg zhpu punapr bs gung, cbfg-cneghz naq nyy
<cjwatson> </tmi>
<infinity> Was that something dirty in rot13?
<cjwatson> more far too much detail for a work channel :)
<infinity> Oh hey, it really was rot13.
<infinity> And I wish I hadn't.
<infinity> Shoo. :P
#ubuntu-release 2012-03-11
<micahg> umm, the GHC transition tracker seems to be on the fritz, stuff that Laney uploaded seems to be installable, but the tracker isn't showing it as such
<Laney> indeed, but newer stuff works?
<micahg> newer stuff as in?
<Laney> some things in level 2
<micahg> idk, just checked stuff in level 1
<Laney> toggle good and you see it
 * Laney tries to remember how to run edos-debcheck
<Laney> micahg: I believe it is because the old -doc packages are being held in the archive until built on all arches
<micahg> ah, ok
<Laney> http://paste.debian.net/159299/
<Laney> this was my clue
<micahg> Laney: thanks for checking
<Laney> nps
 * Laney will do some more syncs shortly
<micahg> Laney: can you give a quick FFe for bug 926425?  it should've been done before feature freeze, but was blocked on a sync blacklist removal
<ubot2`> Launchpad bug 926425 in lurker "Sync lurker 2.3-2 (universe) from Debian unstable (main)" [Undecided,In progress] https://launchpad.net/bugs/926425
<micahg> Laney: nevermind, don't feel obligated, I"ll file the appropriate paperwork later
<Laney> doing it
<micahg> ooh, thanks :)
<Laney> no problemo
<micahg> Laney: in case you missed it, it'll have to go through source and binary new since it was removed several releases ago, still ok?
<Laney> yes, syncs are easy there
<micahg> ok, thanks
<jbicha> do multiarch conversions require release team approval?
<Laney> yes
#ubuntu-release 2013-03-04
 * ogra_ wonders why grub-probe runs (and fails indeed) during the edubuntu builds
<cjwatson> The kernel packages are being installed in the wrong phase
<cjwatson> I haven't worked out why yet
<cjwatson> Was vaguely on my list to care about tomorrow
<ogra_> ah, its the first time i bothered to scroll down in the log :)
<ogra_> they roll in since a while already
<cjwatson> Yeah
<cjwatson> I guess it's a new dependency somewhere or similar
<cjwatson> But just a guess
<ogra_> hmpf, so whats libcolorhug1 and why does it break all images for all arches :P
<infinity> It's hugging your images until they suffocate?
<ogra_> lol
<ogra_> i see doko fixed anothetr issue with colord ... and RAOF before him ... neither of them seems to have touched that dep though
<infinity> Nothing depends on libcolorhug...
 * infinity goes to look at logs.
<infinity> Oh, curious.  I guess colord did for a while.
<ogra_> well, it surely did when the image builds ran :)
<infinity> Hrm, yes, my laptop's living slightly in the past.
<infinity> Then again, libcolorhug1 is now in main.
<infinity> So, I guess that got fixed this morning.
<infinity> Probably just more fallout from the override-loss-on-migration bug. :/
<ogra_> ok
<brendand> will there be a freeze this friday, or are things being modified for the rolling release?
<tumbleweed> brendand: I have no idea
<xnox> brendand: we will have uds tomorrow and on wednesday, i'd expect things to be cleared up by thursday.
<ogra_> yeah
<ogra_> UDS should tell
<tumbleweed> xnox: there's no relevent discussion in the UDS schedule, though
<xnox> hm?!
<tumbleweed> am I blind?
<ogra_> https://blueprints.launchpad.net/sprints/uds-1303 has things like monthly milestones etc
<ogra_> which clearly is rolling related
<seb128> monthly snapshot is wednesday at 2pm
<tumbleweed> hrm, I swear it wasn't scheduled when I looked earlier
<xnox> there is: foundations-1303-monthly-snapshots
<xnox> and rolling-kernel spec.
<ogra_> and "rolling kernel maintenance"
<seb128> tumbleweed, yeah, I just did a bunch of scheduling, no client session was scheduled either
<ogra_> heh
<ogra_> snap
<seb128> most of the sessions are on the schedule now
<seb128> let me know if any is missing
<Laney> I thought the rolling thing was officially still a proposal
<tumbleweed> yet all the sessions on tuesday assume it's happening
<smartboyhw> tumbleweed, what?
<smartboyhw> hmm
<smartboyhw> It should STILL be officially a proposal to the Ubuntu community....
<seb128> it's a proposal
<seb128> it doesn't prevent to discuss details of how things should be adapted to make that happen
<Laney> I mean that I'd expect a session like "should we move to a rolling/LTS release model?"
<seb128> is that really something that can happen in a session?
<Laney> UDS is the typical venue for such discussions
<xnox> proposals without action plans are not proposals but wishful thinking.
<seb128> seems like an endless discussion with too many people having different opinions that will never give any concrete output
<tumbleweed> given the limitations of G+ hangouts, I'm not too concerned about that possibility
<seb128> Laney, well, UDS is the right venue, but you better want to split that in subtopics
<Laney> anyway, we need to know by Thursday whether Feature Freeze is happening
<seb128> right
<tumbleweed> seb128: I'd have expected a session like Laney describes to be the first thing on the agenda, with split-out sessions being scheduled from it
 * ogra_ only saw positive feedback for rolling everywhere ... apart from the flavours on ubuntu-devel 
<seb128> tumbleweed, anyone is welcome to create a blueprint
<tumbleweed> we have, of course, already had a lot of discussion so we know many of the details we want to talk about
<seb128> tumbleweed, seems like nobody did so far, that includes you ;-)
<tumbleweed> fair, but I'm not the one driving this
<seb128> e.g feel free to create one I would say
<seb128> who is?
<tumbleweed> rick?
<seb128> right, maybe ping him when he gets online
<tumbleweed> though, I guess if canonical is convinced that they aren't supporting non-LTS releases, there's not much to discuss
<seb128> seems like it would be easy to add that session in the first foundation slot
<seb128> and move the +1 one to 6pm
<Laney> Riddell: are you going to be around for this UDS/
<Laney> I think that it would be a really good idea to have a flavours/rolling session ...
<ogra_> ++
<Riddell> Laney: I guess so
<Riddell> Laney: it's on my todo list for today to work out what session kubuntu needs
<Laney> fair
<Riddell> Laney: if you register one that'll shorten my todo list :)
<Laney> I just expect it's something that would benefit from some pushing from your end
<Laney> well I'd rather not as I'm not involved with any flavour
<Laney> other than being concerned for their success ;-)
<Riddell> fair enough
<xnox> are the "daily CD heath check" mini-reports published on p.c.c/~ubuntu-archive/ somewhere? at least as a single file which gets updated similar to raring_probs?
<ogra_> xnox, i think they are only maikled by default
<ogra_> *mailed
<xnox> ogra_:  it would be nice to "| tee somewhere/health-check.txt |" in whatever mails it ;-)
<ogra_> livecd-rootfs, feel free to hack :)
<ogra_> in the BuildLiveCD script
<cjwatson> Eh, no, it's not in BuildLiveCD
<cjwatson> it's in lp:ubuntu-cdimage bin/daily-checks
<cjwatson> You're thinking of the livefs build failure mails
<ogra_> cjwatson, oops, yeah, sorry
<dobey> hi all. any chance we could get the tomboy SRUs for bug #1115460 pushed to updates today? i know it's not quite 7 days yet, but would be nice to get it pushed out to reduce the chances of people trying to set up notes sync with a server that won't exist in a couple days.
<ubot2`> Launchpad bug 1115460 in tomboy (Ubuntu Quantal) "Ubuntu One notes sync is going away" [Undecided,Fix committed] https://launchpad.net/bugs/1115460
<tseliot> infinity: hi, can you approve nvidia-graphics-drivers-313-updates and nvidia-settings-313-updates in NEW, please?
<antarus> cjwatson: why do all the Ubuntu announcements make me a sad panda?
<slangasek> any SRU members around who could look at the apt in precise?  It's needed to fix the mess that the lts-quantal stack made of things for multiarch
<slangasek> (precise-proposed unapproved queue)
<blitzkrieg3> Is anyone on the SRU team able to move bug 780602 to Fix Released?
<ubot2`> Launchpad bug 780602 in OEM Priority Project precise "nm-applet leaks memory and stops functioning after a while" [High,In progress] https://launchpad.net/bugs/780602
<blitzkrieg3> I've verified that the memory leak is plugged
<infinity> slangasek: Accepted, and thanks for following up with the auto-remove fix, I was about to do the same thing. ;)
<infinity> slangasek: I can haz the same upload to Q, or should I do that one myself when I wake up?
<slangasek> infinity: well, I'm regarding it as lower priority for quantal
<slangasek> blitzkrieg3: looking over the bug log for bug #780602, there's a comment from bdmurray about an NM crash that happens only with the precise-proposed version
<ubot2`> Launchpad bug 780602 in OEM Priority Project precise "nm-applet leaks memory and stops functioning after a while" [High,In progress] https://launchpad.net/bugs/780602
<slangasek> blitzkrieg3: so if there's a regression, we don't really want to publish it...
<blitzkrieg3> slangasek: yes, but cyphermox says it's unrelated
<blitzkrieg3> slangasek: if we can't publish it, can we pull it?
<bdmurray> slangasek: I'm fine with publishing it
<slangasek> blitzkrieg3: where has he said that?  it's not in the bug log
<blitzkrieg3> slangasek: I know, it was over irx
<blitzkrieg3> irc
<slangasek> I would prefer to have these comments in the historical record :)
<blitzkrieg3> slangasek: it's funny, I was just complaining earlier today how no one puts enough info into lp
<blitzkrieg3> slangasek: if it makes sense I'll circle back with cyphermox and bdmurray and tell them to update the bug
#ubuntu-release 2013-03-05
<slangasek> blitzkrieg3: that would be appreciated
<cyphermox> blitzkrieg3: what's up with that bug?
<cyphermox> ah, I see
<blitzkrieg3> cyphermox: yeahhhhh
<cyphermox> blitzkrieg3: like I said, that's why it would be better to pull that SRU, file a new bug for just the memory issues, SRU that, and then handle 780602 separately
<blitzkrieg3> cyphermox: did you ever confirm that the stack trace is unrelated?
<cyphermox> just so that everyone know exactly what's going on
<cyphermox> ah, no
<blitzkrieg3> ohhhhhhhhh
<blitzkrieg3> okay
<cyphermox> the stack trace seemed to be something we already had
<cyphermox> but there is no way to retrace it to make sure
<cyphermox> blitzkrieg3: tbh, too many people chiming in on that bug, so it's really hard to figure out
<blitzkrieg3> cyphermox: is the fix upstream yet?
<blitzkrieg3> cyphermox: I know
<cyphermox> the fix for what?
<blitzkrieg3> cyphermox: alex's patch
<blitzkrieg3> oh wait
<cyphermox> yes, IIRC it was a backport or something
<blitzkrieg3> it was a bug in appindicator portion
<cyphermox> it was?
<blitzkrieg3> so the code doesn't exist upstream
<blitzkrieg3> I _think_ so
<blitzkrieg3> cyphermox: nevermind, alex already sent them upstream
<blitzkrieg3> so we're all good from that angle
<cyphermox> half of it is upstream, the other half is indicator
<blitzkrieg3> got it
 * cyphermox updates the bug
<xnox> this page rendering looks inconsistent: https://ubuntuone.com/31FiXrvioX0ilBayptC8GZ   it got correct after refresh though.
<xnox> meh wgrant says it's totally fine.
<wgrant> It is :)
<wgrant> xnox: If you look at https://launchpad.net/ubuntu/+source/libdivecomputer/+publishinghistory, you'll see that 0.1.0-3 was superseded by the publisher between when you took the screenshot and when you posted in #launchpad
<tumbleweed> SRU team: prod re bug 988395 (> 2 months in the unapproved queue)
<ubot2`> Launchpad bug 988395 in pithos (Ubuntu Precise) "Pandora v34 API Update Required" [High,In progress] https://launchpad.net/bugs/988395
<xnox> Thank you for accepting emacs24! \o/
<infinity> xnox: I did it just for you.
<xnox> infinity: barry, Laney and I love you for doing it =)
<infinity> xnox: Whoah, there are three of you?
<infinity> xnox: I assumed you and rlb were the only emacs users left.
<Laney> M-x oh-look-new-emacs
<ogra_> infinity, do you think you could be around tomorrow at 14:00 UTC for the "building android stack via cdimage" session ?
<barry> \o/
 * ogra_ would like to have another level of expertise in the session 
<cjwatson> ogra_: I expect to be there in any case
<ogra_> ah, good
 * ogra_ is relieved then :)
<infinity> ogra_: I probably won't be around, but Colin's twice as smart as me anyway, and almost 75% as pretty.
<ogra_> lol
<slangasek> psivaa, jamespage, balloons: hangout open for http://summit.ubuntu.com/uds-1303/meeting/21603/community-1303-plusone-maintenance/
<infinity> slangasek: Feel free to assign whatever work items on that to me.  I'm on my way to bed and jetlagged. :/
<slangasek> infinity: :-)
<jamespage> slangasek, won't be able to attend as leading the ceph session
<jamespage> sorry - wanted to attend that one
<slangasek> jamespage: ah, no worries
<slangasek> if only summit told me when people had conflicts
<slangasek> :)
<cjohnston> slangasek: it does :-)
<slangasek> cjohnston: no, it only tells me of conflicts people have that I myself have declared... but this is a familiar argument ;)
<slangasek> infinity: hmm, linux-headers packages don't get autoremoved because dkms packages depend on the virtual linux-headers that they provide... was this an issue we identified previously?
#ubuntu-release 2013-03-06
<infinity> slangasek: Erm, dkms doesn't depend on headers anymore.
<slangasek> infinity: not dkms itself, the dkms packages
<slangasek> i.e., the modules
<slangasek> (I found this out because I had fwts installed)
<infinity> slangasek: Oh.  Well, that's a case-by-case thing, I suppose.  I know I asked tseliot to fix that for all the ones he maintains.  Not sure how many were done.
<knome> what's the situation with 13.04? are we releasing?
<ScottK> Apparently.
<ScottK> http://blogs.kde.org/2013/03/05/1304-go-ahead
<cjwatson> Which session was that?
<ScottK> No idea.
 * ScottK was offline ~all of today.
<slangasek> well, I'm pretty sure he's referring to the first "rolling release" session, but I don't think there was actually a consensus that we will go ahead with 13.04
<slangasek> there was a consensus that, while things were being discussed, we shouldn't go off the rails with the release schedule
<ScottK> So feature freeze on Thursday in any case.
<ScottK> Riddell: ^^^?
<Riddell> that's my understanding
<xnox> I assume Riddell is misquoting.
<Riddell> xnox: my blog on 13.04?  there's no quote in it.  there's my understanding of the consensus based on nobody saying we should stop 13.04 and everyone except rick saying we should go ahead with it
<Riddell> xnox: planning on doing an ubiquity upload before FF?
<seb128> Riddell, some people expressed concerns about the maintenance cost of making the release though
<xnox> Riddell: one can believe whatever one hears. In that session there was an interesting use case proposed by System76 and we spend a lot of time pondering as to how that can be addressed.
<xnox> Riddell: I personally would want to start bypassing quantal for SRUs, but not security and have rolling rolling out quicker.
<xnox> Riddell: but I can see how cutting quantal short would go against what we previously promised.
<seb128> +1 on stopping SRUs on !LTS
<seb128> xnox, raring you mean?
<Laney> raring?
 * xnox re-reads my statement, and xnox believes it is typed correctly. "rolling" (as in rolling release, noun) "rolling out" (verb)
<infinity> xnox: There would be no "cutting short".  Even if everyone+dog agrees rolling is the way to go and, further, agrees that 13.04 shouldn't happen, quantal will still be supported.  We committed to that.
<infinity> xnox: Furthermore, if 13.04 didn't happen, quantal would probably be supported for a bit longer than we'd promised to give proper upgrade overlap to 14.04.
<seb128> infinity, I think xnox meant "raring" when he wrote "quantal"
<seb128> xnox, ^?
<infinity> seb128: I don't think he did.
<seb128> "to start bypassing quantal for SRUs" doesn't make sense
<seb128> we usually don't both to SRU to stable-1 anyway
<seb128> quantal SRUs already started to slow down
<seb128> so that wouldn't be a change
<infinity> It makes sense to someone who's uploaded a fair few Q SRUs, and xnox has. ;)
<xnox> seb128: currently to SRU something to precise, I should be SRUing into quantal as well.
<infinity> xnox: No, that's patently untrue.
<infinity> xnox: You don't need to SRU to every release.
<seb128> xnox, in theory, in practice...
<infinity> xnox: And I actively discourage it.  It makes validation a nightmare.
<xnox> infinity: seb128: hence "should", not "must" ;-)
<seb128> infinity, well, if you want to ensure that precise->quantal updates have no regression, you do need to SRU to quantal
<infinity> xnox: For critical bugs, yes, fixing them in all releases so upgrades don't see a nasty regression, that's valid.
<infinity> seb128: Depends on the regression.  We have alot of "polish" SRUs in precise, often even for fairly cosmetic bugs.
<xnox> infinity: "latvian" as well ;-)
<infinity> seb128: If those cosmetic bugs reappear on an upgrade to Q (but go away in later releases), I'm not sure I deeply care.
<infinity> xnox: Wrong reading of "polish". :P
<xnox> My view is that we can make 12.04.3 better than 12.10. Imho precise is already better than 12.10.
<xnox> If we identify small core packages to aggressively SRU, e.g. new unity sans indicators.
<infinity> xnox: precise has always been better than 12.10.
<infinity> xnox: But pushing new upstream versions to precise won't keep that situation true. :P
<xnox> infinity: when did you join UK Conservative party?! =))))) *kidding* I see your point, it's a slippery slope. Can we pull off a unity-lts-quantal?
<infinity> xnox: Why?
<infinity> xnox: And no, we can't.  Not without serious abuse of unity.
<xnox> it's the last compiz based unity, the most stable one and the one we can support for the next 4 years.
<xnox> i don't think we will push mir/unity-next into precise.
<infinity> I'm really confused.  Why do you want ANY new unity in precise?
<infinity> Does the current one offend you somehow?
<infinity> The one that's in precise is perfectly supportable.
<infinity> The one in quantal requires many new APIs and other such things.
<infinity> And doesn't include unity-2d.
<xnox> infinity: it offends System76. Watch the video from the rolling release session from yesterday. They shipped 70/30 quantal/precise on the (pro)consumer laptops/desktops.
<xnox> and conclude that they like 6-montly releases as they are always faster/better.
<infinity> Did they give reasons?
<infinity> I mean, real reasons?
<seb128> infinity, did you listen to the rolling release discussion yesterday? the system76 guys says most their users want the new features/version
<infinity> Not "we like this more" reasons.
<seb128> yeah, performances are better
<seb128> and it has nice features
<seb128> better look
<xnox> infinity: performance & stability from UX.
<infinity> Well, performance and stability can probably be identifiable cherry-picks.
<xnox> infinity: on the other hand their server offering had a scew towards lts, as one would expect.
<infinity> Backporting it wholesale breaks various worlds.
<infinity> xnox: "skew".
 * xnox almost typped screw, so I almost got it right ;-))))))
<infinity> I dunno.  I get their point (and I should watch the video), but "enthusiast desktop users always want the latest thing" isn't really news.
<infinity> And if that latest thing didn't exist in that form, they'd either use the LTS, or become crazy bleeding edge dev/rolling users.
<infinity> And if you can argue that people ordering from system76 are anything other than enthusiasts, I'd be curious to hear your arguments.
<infinity> Given that almost no one knows who they are, unless you're part of a few small Linux communities.
<infinity> I guess what I'm saying is that their numbers don't prove that quantal is, in itself, desirable, just that enthusiast users like bigger version numbers.
<xnox> infinity: sure, but for example I was considering system76 machines as a present to my close friends and relatives. And I don't consider them enthusiasts. I keep their machines on non-lts, although I might go vorlon-style and keep them on lts from now on.
<infinity> xnox: Yeah, see, that would be *you* making that choice, not *them*.
<infinity> xnox: You said "I keep their...", not that they do. :P
<xnox> infinity: speaking of version numbers, if we go with rolling/2y release cycles next version should be just simply "14"
<xnox> infinity: touche.
<infinity> xnox: Yeah, I could be down with an odd/even unstable/stable version scheme or something if we swap to a 2y cadence.  Call raring "13" in development, and "14" leading up to release.
<xnox> infinity: yeah, canonical offices have enough of awards for the "Excellent Ubuntu 7.6 release"
<infinity> Though, maybe not.  Twiddling versions may confuse the world, since everyone likes to key on them.
<infinity> So, we could just skip version numbers. :P
<infinity> xnox: You mean 6.6?
<xnox> infinity: not release at all - ever =))))))
<xnox> infinity: nope, the award was exactly for the "7.6" award. Our yy.m version numbering scheme is hard for users & media to comprehend.
<infinity> xnox: Erm, but we had no 7.6.  Just 7.4 and 7.10
<xnox> (s/award\./release./)
<infinity> xnox: We did, however, have a 6.6
<xnox> infinity: exactly. We got an award for a release that never was =)
<xnox> version numbers are hard ;-)
<cjwatson> so, I wouldn't support interface changes; but when people say "13.04 is so much smoother to use" [i.e. perf] then that's something we can and should fix, I'd have thought
<infinity> cjwatson: Right.  It's decoupling those things.
<infinity> cjwatson: If they can backport performance fixes without completely upending unity-2d, indicators, gsettings, etc, etc, sure.
<cjwatson> (and I'm fairly sure I've heard that from sources other than system76 too)
<infinity> I wasn't arguing that the new unity isn't faster and smoother (it is, I use it).
<infinity> I was arguing that their numbers don't actually support that.
<cjwatson> Sure, I wasn't actually going off the numbers :)
<infinity> Users aren't chosing quantal because the new unity is faster, they're chosing it because it's the bigger version number, and that's what that class of user does.
<didrocks> cjwatson: infinity: we already backported all "safe" performances fixes
<infinity> The numbers would skew that way if quantal's unity was pink and yelled expletives at them when they logged in.
<cjwatson> didrocks: ah :-/
<didrocks> took a lot of time, but we did that
<didrocks> the remaining ones are minor and more risky
<didrocks> I feel it's more a question of perception than real numbers (that we don't have :/)
<infinity> didrocks: To be fair, I haven't run unity on precise since around release time.  Maybe those backports paid off, and the arguments are moot?
<didrocks> infinity: that's my feeling, more a question of either people not upgrading precise or just a biased view
<infinity> Right.  So, can we make quantal's unity yell expletives at users when they log in, to see if it changes the bias? :P
<infinity> I'd approve that SRU.
<infinity> If it was fully translated.
<didrocks> infinity: no worry as log as you approve it. I can sync with dpm for translations, I'm sure :)
<didrocks> but who pick the words? :p
<infinity> Get Colin drunk, he'll give you some fine ones.
<didrocks> heh
<didrocks> that's a plan! :-)
<xnox> didrocks: Ñ ÑÐ¾Ð¶Ðµ Ð¼Ð¾Ð³Ñ Ð´Ð¾Ð±Ð°Ð²Ð¸ÑÑ Ð¸Ð½ÑÐµÑÐµÑÐ½ÑÐµ ÑÐ¾Ð¾Ð±ÑÐµÐ½Ð¸Ñ =)
<didrocks> xnox: at least, that can exercise our UTF8 support :)
<xnox> didrocks: note, there are plenty of UK online off-license stores that do delivery to the door.
<infinity> didrocks: I was thinking audio, not text, so UTF8 doesn't really factor into it.
<didrocks> interestingâ¦ :-)
<cjwatson> Laney: So, what's the state of the current Haskell transition, were I to want to spend some +1 maint time on unsticking it so that it's easier to see what else is going on in -proposed?
<Laney> cjwatson: I synced a bunch of NEW stuff the other day that should have unblocked syncing some of the lower down packages
<Laney> I haven't poked into the new armhf failures but it's likely to be at least in part the same bug we had before so possibly worth removing at least some of those
<cjwatson> Laney: So the approved current approach is to proceed from the bottom of the stack upwards, and either (a) sync from experimental, if it builds/installs (b) no-change rebuild, if it builds/installs (c) remove armhf/powerpc binaries if necessary?
<Laney> right
<Laney> I just gave back haskell-monoid-extras which looked like it might have been transient
<Laney> (armhf)
<Laney> be aware that experimental has been a bit more of a moving target than I'd hoped - it might have shifted since some lower part of the transition was done
<Laney> oho, it did build - should knock a chain of depwaits off
<cjwatson> I'll leave it a bit and see what happens, then
<Laney> that's just armhf; you can look at stuff which is red on all arches
<Laney> oh, a small number of packages require upstream changes - you can leave those to me (most upstreams have been made aware already)
<Riddell> I'd like to just ignore powerpc for qtwebkit-source and move it to -release, how can I do that?
<cjwatson> 'force qtwebkit-source/VERSION' in a file named for you in lp:~ubuntu-release/britney/hints-ubuntu/
<cjwatson> Oh, and if you're adding a new file there you need to edit britney.conf in lp:~ubuntu-release/britney/britney2-ubuntu/
<infinity> Riddell: Is it actually unportable?  Don't tell me they've joined the long list of people embedding V8 in an unconfigurable way? :/
<Riddell> infinity: it should be workable but without a machine to test it on it's very slow to work through
<Riddell> even with a machine it's very slow
<Riddell> and since we don't care about powerpc...
<infinity> Who's we?
<infinity> Maybe I'll look at it when I get home.  I turned off my fast build machine before I left. :/
<infinity> Actually, looks like it should be simple enough to do blind...
<infinity> Riddell: Should be a 1-liner, and you can back out all your other changes.
<infinity> Oh, wait.  Maybe not.
<infinity> Bah.  Yeah, I'll look at it when I get home on the weekend.
<cjwatson> infinity,slangasek: FYI I believe I've reproduced the notorious overrides bug in LP's test suite now
<slangasek> \o/
<cjwatson> So should be able to debug a fix into place from here
<cjwatson> dobey: Sorry, I had intended to release tomboy earlier but never quite got round to it - doing it now
<dobey> cjwatson: no worries, it's a hectic time. thanks :)
<cjwatson> Now all I have to do is navigate the insane overrides adapter
<cjwatson> (s)
<cjwatson> infinity,slangasek: http://paste.ubuntu.com/5591314/ first cut at overrides fix but will need some more work.  it at least passes the tests I've tried
<cjwatson> logic is simply to add deleted to the list of publishing statuses we consider, on the basis that (a) there won't be many so this doesn't blow up the query too much, (b) any time we need to look up existing overrides and the last publication for the package in question was deleted, we always want to resurrect those overrides by default
<cjwatson> (so infinity's hypothesis about the cause of this problem was AFAICT correct)
<slangasek> \o/
<xnox> omg, shibroken is not so broken!
<xnox> barry: infinity: cjwatson: ^^^^^^
<barry> xnox: \o/
#ubuntu-release 2013-03-07
<cjohnston> awesome!
<zul> can someone tell me why python-oslo-config isnt in raring yet, it built fine for raring-proposed 4 hours ago?
<jbicha> zul: it adds a new binary package which has to be manually approved first https://launchpad.net/ubuntu/raring/+queue?queue_state=0
<zul> k thanks
<jbicha> zul: since you're here, how do you want to handle the final comment of bug 1140613?
<ubot2`> Launchpad bug 1140613 in python-warlock (Ubuntu) "Merge python-warlock 0.8.1-1 (main) from Debian experimental (main)" [Wishlist,Fix committed] https://launchpad.net/bugs/1140613
<zul> jbicha: Its already been taking care of
<jbicha> zul: oh I see, thanks
<zul> can someone please approve python-oslo-config plrease?
<infinity> cjwatson: Woo!
<infinity> zul: What's the rationale for the oslo-config package rename?
<zul> infinity: https://bugs.launchpad.net/ubuntu/+source/oslo-config/+bug/1130196
<ubot2`> Launchpad bug 1130196 in oslo-config "[MIR] oslo-config" [High,Fix released]
<infinity> zul: Hrm.  I was going to check if there was some sort of python naming policy, but I guess there's precedence for the dot-notation in zope.* and z3c.*, etc.
<zul> infinity:  cool thanks
<xnox> infinity: cheers for the shibroken.
<ara> hello! is a freeze happening today?
<seb128> ara, hey, I guess so
<seb128> ara, it would be logical to stick to the schedule until a decision on the next steps is taken
<seb128> ara, it doesn't mean we will not change the freeze or other things in a week if a different path is decided
<seb128> ara, well, that's my view on the situation, don't take it as an official statement ;-)
<cjwatson> that's my understanding too
<didrocks> FYI I warned the PS team this morning about it
<Laney> indeed
<Laney> we should be sure to announce it today
<didrocks> so normally, we should be safe on their side
<seb128> didrocks, good, I wonder if lars & charles had planned to land any indicator work this cycle, they didn't yet
<seb128> didrocks, but let's take that to their channel
<didrocks> seb128: I think this is aborted by now, I don't see them landing that today ;)
<didrocks> but yeah, let's talk with him once they are around (I sent the email to their manager about the freeze)
<ara> seb128, thanks!
<brendand> seb128, exactly what time is it at? we want to upload a package today so it would be good to know
<Laney> normally 2100 UTC
<ara> normally it is at 21:00 UTC
<Laney> SNAP
<tumbleweed> oops, themuso and I both sponsored the nvidia-cuda-toolkit SRU to quantal. queue reject -Q unapproved -s quantal-proposed 5297155 , please
<infinity> I'm going to reject the one that didn't run update-maintainer.
<tumbleweed> even better :)
<tumbleweed> (and I'm impressed you diffed it that quickly)
<ogra_> hmm, regarding the livefs buld logs it looks like we have a dead armhf builder again
<ogra_> *build
<ScottK> qscintilla2 is finally done.
<infinity> ScottK: I see you gave up on the symbols file of doom.
<ScottK> Fornow.
<ScottK> I know how to fix it, I just didn't quit get it to work right.
<ScottK> qiut/quite
<ScottK> Meh.  I give.
<infinity> Yeah, I gave it a short stab before I left for Hong Kong and threw my hands in the air cursing C++ symbols.
<infinity> The answer would have been to hand-write it, in my case.
<infinity> Basically, take a few examples from varying arches, see how it plays out, and then hand-craft a file that makes sense, since pkgkdesymbolsthingee wasn't doing me any favours.
<infinity> It's probably high time someone broke that out of the KDE packaging tools.
<infinity> And then made it less crap.
<nigelb> 8
<nigelb> (grr, sorry)
<infinity> apw: Didn't you write a quick and dirty symbols parser/generator when you were grumping over some C++ symbols files?
<ScottK> infinity: The actual problem is using not using the pkgkde-symbolshelper during the actual build (using it to generate the symbols file isn't - in this case - enough).
<ScottK> The fact that the C++ stuff isn't included in dpkg-gensymbols (or whichever one it is) is unfortunate.
<dobey> so are we in feature freeze?
<Laney> 2100 UTC
<dobey> so 13.04 is still on then?
<Laney> yes, until we hear otherwise
<ScottK> It's on until it's not.
<shadeslayer> I have a new upstream release for KDE Telepathy that I
<shadeslayer> er
<shadeslayer> *That I'm packaging at the moment, and will probably upload in a day or two
<shadeslayer> do I have to file a FFe?
<shadeslayer> Riddell: ScottK ^
<ScottK> shadeslayer: Yes.
<shadeslayer> bah :(
<ScottK> infinity: Is sagari stuck?  If I read the build log right, the "in progress" build finished a long time ago ...
<xnox> ScottK: is that arm?
<Laney> ppc
<ScottK> xnox: powerpc
<xnox> hm.
<Laney> looks like it's shifted now
<ScottK> So it did.
<infinity> ScottK: It appears "stuck" sometimes because its bandwidth sucks, and the final uploading stage can take a while on large packages.
<ScottK> OK.  Thanks.
<infinity> ScottK: It's the only buildd in Boston, and there are some network hiccups there that need solving. :P
<ScottK> Oh. I had no idea.
<infinity> That sounds like the sort of response you'd give to "my mother just died", not "there's a computer in Boston", but okay. ;)
 * xnox ponders if stuff in -proposed at freeze will be let through or not ;-)
<cjwatson> It will
<xnox> ok good.
<ScottK> infinity: qscintilla2 and friends just migrated, so that's off the list.
<ScottK> slangasek, cjwatson, other release team members: Someone should announce feature freeze.
<slangasek> ScottK: yes, I'm going to send out a mail
<ScottK> slangasek: Great.
<ScottK> Thanks.
 * micahg is wrestling with the last few uploads, should be done in ~1.5 hours
<micahg> if that's ok with the release team
<ScottK> Depends on how fast slangasek writes his mail.
 * micahg goes and uploads the thing he's least likely to get an exception for before 21:00
<ogra_> ubuntu-armhf-nexus7 on celbalrai.buildd starting at 2013-03-07 21:03:47
<ogra_> lockfile: Try praying, giving up on "/home/buildd/buildLiveCD.lock"
<ogra_> infinity, ^^^ mind giving it a kick ?
<stgraber> slangasek: just spotted a small problem with the packaging of upstart, I think I fixed it now but it'll take me an extra 5-10min to wait for the test build and post-build tests
<slangasek> stgraber: ok.  I'll consider that "close enough" and worthy of an implicit FFe
<slangasek> no need to incentivize people to upload broken things to avoid the FFe paperwork
<stgraber> slangasek: uploaded. Now to hope it'll build on powerpc (only arch I couldn't testbuild)
<xnox> Hmm... my ubiquity did not go as well =)
<xnox> https://launchpadlibrarian.net/133275922/buildlog_ubuntu-raring-amd64.ubiquity_2.13.13_FAILEDTOBUILD.txt.gz
<xnox> we have uninstalability in raring-release?
<slangasek> packages are built against -proposed, not just against release (for reasons that are obvious if you think about it)
<xnox> yeah, but there is no libsoup in proposed.
<slangasek> yeah
<xnox> ah, but something else, can be broken because of it. I see.
<slangasek> but apt also doesn't bother telling you the real source of the uninstallability in such cases :)
 * xnox will wait for ubiquity to be published in -proposed, and then i'll troubleshoot.
<xnox> (src that is)
<Laney> it's just skew with glib-networking
<slangasek> which flavors are doing Beta1 next week?
<xnox> Laney: oh, ok. Is it in progress? i see that my i386 built fine =)
<Laney> sounds even more like skew then ;-)
<Laney> https://launchpad.net/ubuntu/+source/glib-networking/2.35.9-1
<slangasek> ScottK: you commented earlier about qscintilla2... I currently see it in components-mismatches, is that a phantom or were you referring to something else?
<ScottK> slangasek: I was referring to getting it out of proposed.
<ScottK> It's been stuck there for quite some time.
<ScottK> slangasek: libqsinctilla2-8 is NBS.  That's why it hit CM.
<ScottK> And it looks like 2-9 needs to be put in Main.
<slangasek> ok
<slangasek> (done)
<micahg> slangasek: Xubuntu is on board for beta 1
<micahg> I have 2 more uploads to do before we're ready though
<slangasek> ok
<jbicha> micahg: I have the gimp 2.8.4 update ready, would you prefer that now or after Beta 1?
<micahg> jbicha: now's fine if it's bug fix
<micahg> actually, now's fine either way, just request FFe if you need it
<jbicha> ok, Release Team, it builds, installs and runs here, can I get an IRC FFe for gimp 2.8.2>2.8.4?
<jbicha> https://git.gnome.org/browse/gimp/tree/NEWS?h=gimp-2-8
<robert_ancell> As per slangasek's email. I'm here to beg to get lightdm 1.5.1 into raring as it's just missed feature freeze (lp:~robert-ancell/lightdm/ubuntu-1.5.1)
<robert_ancell> While technically it's a major version bump over 1.4.x the changes are bugfixes, patches from Ubuntu upstreamed and new support for Qt5
<xnox> infinity: doko will buy you beer if you accept https://launchpad.net/ubuntu/quantal/+queue?queue_state=1&queue_text=openssl
 * xnox whoops didn't notice that doko is in the room.
<ogra_> robert_ancell, you should upload in any case ... it will sit in the queue  for acceptance then
<robert_ancell> ogra_, ok
<ogra_> (so it doesnt get delayed even more)
<ScottK> ogra_: No.  It won't.
<ScottK> robert_ancell: ^^^
<ScottK> The archive isn't frozen.
<robert_ancell> ScottK, um, I just uploaded it - can you put a block on it?
<ogra_> hmm, why isnt it frozen if we are in a freeze
<ScottK> Yeah.  We can block the transition to the release pocket.
<robert_ancell> ScottK, ta
<ScottK> ogra_: We have never, ever, ever frozen the archive at feature freeze.  Why would you think we were now?
<ScottK> robert_ancell: lightdm, right?
<robert_ancell> ScottK, yes
<ogra_> ScottK, we froze the queue in the past
<cjwatson> Never for feature freeze.  ScottK is correct
<ScottK> ogra_: Yes.  For final pre-release freeze and for Beta freezes.
<ogra_> hm
<ogra_> sorry for the misinfo then
<Daviey> ogra_: As penance, maybe you could clarify this on https://wiki.ubuntu.com/FeatureFreeze :)
<ScottK> Blocked.
 * ScottK departs.
<ogra_> Daviey, added a note
 * ogra_ better goes to bed before causing more havoc
#ubuntu-release 2013-03-08
<xnox> ogra_: otherwise every little bugfix would have to go through a review ;-)
<ogra_> yeah
<ogra_> i thiink i just mixed it up because we often had alpha or beta freezes right around FF
<xnox> ah, true.
<seb128> ogra_, hey
<ogra_> yo
<ogra_> hmm, doesnt look like infinity saw my ping last night ... seems the armhf buiolder still has a stale lock
<infinity> ogra_: Ask #is.
<infinity> ogra_: And be specific, there are two armhf builders.
<infinity> Actually, I'll ask.
<smartboyhw> Helo Ubuntu Release Team. Do I need to file a FFe bug for a bug-fix upstream update of a universe application (rekonq) since it is now FF?
<Laney> no, bug fix updates don't need FFe
<smartboyhw> Laney, OK
<ogra_> you dont need freeze exceptions for bugfixes or minor version upgrades (i.e. 3.3.1 to 3.3.2 doesnt need an FFe ...)
<ogra_> only for new features or major version upgrades
<Laney> er, depends what is in the minor version update
<smartboyhw> ogra_, OK
<ogra_> indeed
<Laney> the freeze doesn't care about version numbers but the content of changes
<smartboyhw> Well it just is a bug fixing update for bookmarks.....
<ogra_> thats fine
<Laney> can someone fix Archive: in the topic please?
<tumbleweed> how does auto-landing interact with the feature freeze? (re bug 1081843)
<ubot2`> Launchpad bug 1081843 in unity (Ubuntu) "[FFe] Launcher, Window Management - More Effective window switching for apps with multiple windows using the Launcher" [High,In progress] https://launchpad.net/bugs/1081843
<tumbleweed> it's already been committed, and I see the FFe component was just changing the bug title and subscribing us
<Laney> they shouldn't be committing stuff without FFe approval
<tumbleweed> it was committed before FF, just
<Laney> but it will be uploaded after
<tumbleweed> yeah, this is just a weird corner case
<Laney> probably the path of least resistance to approve it if you want to and not fuss, otherwise it can be reverted
<tumbleweed> I'm happy to just wave it through
<xnox> tumbleweed: Laney: I'd apply slangasek's "near miss FFe waiver programme" as per FF email.
<Laney> he's approving it, so moot
<Laney> something to be aware of for daily landing though that there the freeze effectively starts the day before
<tumbleweed> I was asking about it more generally, though
<xnox> A stacked openssl quantal upload is coming up from mdeslaur and myself.
<Laney> â discussed in #-desktop and I told them to go ahead with NEWing
<cjwatson> infinity: https://dogfood.launchpad.net/ubuntu/precise/i386/accessodf \o/
 * cjwatson qa-oks
<xnox> WIN!
<cjwatson> (compare https://dogfood.launchpad.net/ubuntu/precise/i386/python-aafigure which is before that fix)
<xnox> yeah component and priority is not lost any more....
<xnox> although that priority is not lost is not visible in the qa-ok test.
<cjwatson> Yeah it is
<cjwatson> Unless you mean section which I didn't bother changing
<xnox> awesome =)
<jokerdino> hey, any archive admins around?
<jokerdino> could use the help of one to look into the unity-tweak-tool package in the new queue. :/
<xnox> doko, infinity ^^^^ openssl above are the right onces that have mdeslaur bug folded in as well.
<xnox> unless you want them separate.....
<xnox> infinity: for my bugs I did tests on armhf/amd64 for both quantal and precise. Will do stress testing with apache as you suggested later this weekend. Have a few things to catch up on, before EOW.
 * Laney reads "âUbuntu Release Teamâ team's teams" on Launchpad and giggles
<cjwatson> ObjectFactoryFactoryFactory
<Daviey> def teams(team):\n for t in teams(lpteam): print t
<Laney> Riddell: you guys have a bot to file bugs?!
<Riddell> Laney: it can serve beer too
<Laney> reminds me of IRC 15 years ago
<ScottK> It cannot, however, get debian/copyright correct.
 * Laney slaps Riddell around a bit with a wet trout
<xnox> old school, Laney you are showing your age now.
<slangasek> his age is indicated by a fish?
<seb128> slangasek, I think it's more the smell of it which indicates the age
<Laney> I wonder if I can still remember any mIRCscript
<phillw> hi good people. I know I've been told before (I've lost the sticky note). What time UTC does the cron jobs for lubuntu alternate and desktop kick in?
<bdmurray> slangasek: I've a list of packages to be removed from -proposed when you have a chance
<infinity> 29 16 * * *     for-project lubuntu cron.daily; buildlive lubuntu daily-live && for-project lubuntu cron.daily-live
<infinity> phillw: ^
<infinity> bdmurray: I can do that, if you're doing the bug followup.
<bdmurray> infinity: sure - http://pastebin.ubuntu.com/5596423/
<infinity> bdmurray: Consider it done.
<infinity> bdmurray: And all done.
<infinity> ... and I may have done something bad.
<bdmurray> infinity: ?
<phillw> infinity: thanks :)
<infinity> bdmurray: I may have removed those packages from their respective -release pockets.  A little bit.
<infinity> (Which shouldn't actually change anything on-disk, cause we don't re-publish those pockets AFAIK, but...)
 * infinity halts the publisher to copy them all back over themselves.
<cjwatson> You shouldn't even have been able to remove anything from an unmodifiable pocket.
<infinity> cjwatson: I like the theory.
<cjwatson> Have you checked the publishing history?
<infinity> https://launchpad.net/ubuntu/+source/xfce4-settings
<ogra_> infinity, so i dug a little into the panda breakage, seems it got stuck during fdupes
<infinity> ^-- Note the lack of -release versions for precise and quantal.
<cjwatson> Oh my.
<ogra_> i wonder if at the high I/O that causes the USB driver or disk falls over
<cjwatson> Please file an LP bug
<infinity> ogra_: I'm not sure that's meaningful.  "The filesystem went r/o while doing things to it"...
<ogra_> yeah
<ogra_> well, sevea asked me to check when exactly it failed
<ogra_> i'll do that the next time again, lets see if its doing it again
<ogra_> i sadly couldnt get a manual nx7 build going ... somehow foomatic stuff is skewed in the archive atm
<cjwatson> I'm not sure you'll be able to copy it back
<infinity> No...?
<cjwatson> It's certainly not possible to accept a queue item for the release pocket of a stable series
<infinity> (base)adconrad@cthulhu:~$ copy-package --auto-approve -e 4.10.0-1ubuntu2 -s quantal -b xfce4-settings
<infinity> Copy candidates:
<infinity> 	xfce4-settings 4.10.0-1ubuntu2 in quantal
<infinity> Candidate copy target: https://api.launchpad.net/devel/ubuntu/+archive/primary
<infinity> Copy [y|N]? y
<infinity> Not permitted to upload to the RELEASE pocket in a series in the 'CURRENT' state.
<infinity> Hrm, indeed.
<infinity> Well, this is problematic.
<cjwatson> As you say, it won't be published
<infinity> True.  But the history is now broken. :/
<infinity> And, in fact, once I properly delete the -proposed versions, it'll look like it just plain doesn't exist in that series at all.
<cjwatson> Yeah, it needs to be fixed
<cjwatson> If you file the bug about deletion, I can fix that nowish
<infinity> 1152669
<cjwatson> ta
<infinity> This is altogether the wrong time of week to be trying to fix this too.  But, I guess since the changes won't be published, it can wait.
<infinity> The bug references all the accidental deletions, at least. :/
<ogra_> shouldnt you be on a plane ?
<xnox> bdmurray: infinity: NOT THE AUTOFS5 from lucid!
<infinity> ogra_: I don't leave for another 16h or something.
<ogra_> ah
<infinity> xnox: Was that sarcasm?  It's been unverified for 562 days.
<ogra_> pfft, who cares, let it in :P
<xnox> infinity: yeah, but there is only one reason we care about autofs5 in lucid.
<xnox> infinity: that was not sarcasm.
<xnox> Daviey: bug 578536 is scheduled to be removed from lucid-proposed, because it's unverified.
<ubot2`> Launchpad bug 578536 in autofs5 (Ubuntu Lucid) "when stopped, automount orphans some mounts" [Medium,Confirmed] https://launchpad.net/bugs/578536
<infinity> xnox: Read the bug log.  It looks like it needs more/differnt fixing anyway...
<Daviey> xnox: I'm not sure i am bothered :)
<infinity> Points to a dead branch.
<xnox> Daviey: ok, talking with stockachu about it.
<xnox> infinity: never mind, false alarm. Those who would care about fix have now migrated to precise.
<xnox> infinity: stockachu confirm on #ubuntu-devel.
<bdmurray> xnox: I'd spoken with stokachu about it already
<stokachu> hi
<xnox> stokachu: thanks for joining us =)
 * infinity goes about removing from the correct pocket now. :/
 * xnox is raising false alarms again.
<xnox> stokachu: we discuss all things SRU here ;-) as well as other releasy things.
<Daviey> infact, infinity - do you just want to rm -rf lucid/ ?
<xnox> one month too early?!
<xnox> nah, that would be hardy.
<infinity> Daviey: :P
<infinity> cjwatson: I need to get some sleep, and Team Soyuz seems to be napping as well.  Can you remind me (or them) later to try to undo the damage? :/
<cjwatson> Sure
<infinity> Always good to cap off one's week with something that makes you feel really dumb...
<cjwatson> infinity: The best bit is that the test suite (admittedly implicitly) tests that it's possible to remove from the release pocket of a stable series ...
<cjwatson> Wait, maybe it doesn't.  Flipped logic.
<phillw> cjwatson: could you have a quick look and check that the 'desktop' images for lubuntu are still building, the alternates arrived a little while back. Thanks,
<cjwatson> They are, yes
<cjwatson> The powerpc livefs builder is a bit slower so it's waiting for that
<phillw> cjwatson: thanks :)
<cjwatson> From inspection of the timestamps of the last few build logs, the powerpc livefs build would normally expect to finish sometime in the next ten minutes, and then it'll start constructing the ISOs
<phillw> many thanks, I'm just doing some tidying up on the lubuntu-testing wiki so people have an estimated time of when the ISO's land each day.
<phillw> stops them grumbling if they start a test suite and a new daily arrives half way through :)
<cjwatson> Sure, as long as it's clear that it's subject to change - I'm not intending to make any promises here
<cjwatson> I won't change them around frivolously or anything but it's possible
<phillw> understood, I'll add a note with words to that affect. Am I correct in that the arm gets rebuilt on request from the arm team (they fully look after that anyways, I just want to add it for completeness sake.
<cjwatson> No, it's cronned
<cjwatson> 35 1 * * *      buildlive lubuntu daily-preinstalled && for-project lubuntu cron.daily-preinstalled
<bdrung> hi, do i need a FFe for libreoffice 4.0.1-0ubnutu1 that is a bug fix release?
<bdrung> it took a few days to review and improve it
<tumbleweed> if it's a bug fix release, I don't see any issue
<tumbleweed> (esp. on day 1 of FF)
<phillw> cjwatson: hmm, must be the arm builds are 'down', the lubuntu one is 4th March and Ubuntu is 5th March.
<cjwatson> which specific build URLs?
<phillw> cjwatson: http://iso.qa.ubuntu.com/qatracker/milestones/243/builds/38926/downloads for lubuntu
<phillw> http://iso.qa.ubuntu.com/qatracker/milestones/243/builds/39040/downloads for Ubuntu
<cjwatson> phillw: Some of the builds after that failed and since then I think the builder has been down
<cjwatson> The existence of http://people.canonical.com/~ubuntu-archive/livefs-build-logs/raring/ubuntu-nexus7/20130308.1/ suggests it's back up (although currently failing for Ubuntu) and you should get a Lubuntu build tomorrow morning
<jtaylor> hi, concerning bug 1152247
<ubot2`> Launchpad bug 1152247 in julia (Ubuntu) "Sync julia 0.1.2+dfsg-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1152247
<jtaylor> it was intended to be synced before ff, but dinstall ran to late
<jtaylor> its mostly a bugfix I have been told, ok if I still sync that?
<tumbleweed> jtaylor: do it
<jtaylor> k
<jtaylor> thx
<phillw> again, many thanks :)
<ogra_> phillw, arm failed for a few days and is back up again, currently we're waiting for a fix to foomatic-filters that breaks the desktop-common seed
<ogra_> if thats in the archive nefore tomorrow morning, all images should build fine again
<ogra_> *before
<micahg> if there's a package sync'd from Debian that FTBFS in -proposed, but would no longer FTBFS, but there's a new version in Debian and it's never hit the release pocket, can I sync the newer version (there are new features as well)
<micahg> I figure it needs binary NEW anyways, so....
<tumbleweed> seems reasonable
<tumbleweed> (as someone who doesn't do NEW review)
<cjwatson> Indeed
<cjwatson> Go ahead
<micahg> thanks
<phillw> ogra_: thanks, I've updated our wiki page for lubuntu testing to reflect the cron time that colin gave me.
<phillw> cjwatson: any ideas yet from -release as to when the pre-milestone for beta 1 (i.e. freeze of dailies) for those teams using Beta 1 will be implemented?
<phillw> I know FF is some what a 'grey' area :)
<ScottK> feature freeze and beta 1 freeze are different things.
<phillw> ScottK: indeed, we used to get the alpha or beta handed over (in theory) 7 days before the "Yes / No" decision. That it rarely happened is no difference, but it does ask... just when will the image be handed over for testing?
<ScottK> phillw: See u-release email.
<phillw> ScottK: I don't think I'm on that list?
<cjwatson> It has public list archives
<cjwatson> Also, I'm neither coordinating nor release-engineering beta 1
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-release/2013-March/002244.html
<phillw> ScottK: thanks for that, I've just had a chat with julien (gilir) about this. It appears that lubuntu stating that it was taking part in Beta series got lost along the way.
<xnox> I hope "vc" is not "version control" system.
<ScottK> It's not.
<ScottK> library to ease explicit vectorization of C++ code
<ScottK> xnox: ^^^
<xnox> ScottK: meh, good enough then =))))
#ubuntu-release 2013-03-09
<ScottK> cjwatson: Thanks for you abundance of caution with sticking with the process for Kylin.
<cjwatson> Somebody has to :)  GNOME Remix is coming up too, but I need to look into what's needed in terms of live-build configuration there as apparently they aren't currently using live-build so I can't just steal that
<cjwatson> So that may take a little longer.  It was second in the queue anyway
<ScottK> I waved my wand over it too, so the path is clear when ready.
<cjwatson> Oh, is there a general FFE bug for it?
<cjwatson> I think I'll need an RT to get BuildLiveCD updated for Kylin.  Maybe I should check it in but wait until I have the GNOME Remix stuff done too, so that I can save a request.
<jbicha> cjwatson: hmm, I wonder why lubuntu is missing from BuildLiveCD
<cjwatson> Or possibly I should remove the project check from that
<cjwatson> err, good question
<cjwatson> oh
<cjwatson> "*ubuntu" matches
<cjwatson> Ah yes, bug 1152818
<ubot2`> Launchpad bug 1152818 in livecd-rootfs (Ubuntu) "[FFe]: Start building Ubuntu GNOME images" [Wishlist,Triaged] https://launchpad.net/bugs/1152818
<cjwatson> jbicha: Thanks for the details
<zequence> Anyone here who has the power to edit rights to http://iso.qa.ubuntu.com? We currently have the LP team ~ubuntustudio-core assigned to it, but would like our new team ~ubuntustudio-release handle it instead.
<cjwatson> stgraber: ^-
<stgraber> zequence: oops, completely forgot about that, fixing now
<zequence> stgraber: np. Thanks
<stgraber> zequence: done
<zequence> great
 * cjwatson decides that's enough build system wrangling for one night and goes to bed
<phillw> stgraber: are you busy, or do you have a few minutes to spare?
<ogra_> hmpf, the images still fall over on foomatic stuff ... even thouth the recommends was dropped from foomatic-filters
<ogra_> *though
<ogra_> ah, i see the discussion in -devel
<cjwatson> Yeah, I was considering a batch of respins
<cjwatson> Running
<cjwatson> (Ubuntu desktop, Kubuntu, Xubuntu, Wubi, Ubuntu Studio)
<smartboyhw> Oh?
<cjwatson> smartboyhw: The previous builds failed
<smartboyhw> cjwatson, yeah:(
<cjwatson> Hmph, still seems to be failing
<smartboyhw> Uh
<ogra_> cjwatson, its not fixed yet ...
<cjwatson> Except germinate says it should be
<cjwatson> But yeah, still has a Task field
<cjwatson> Maybe it just needs another publisher run
<cjwatson> Might be happier now - a publisher run just finished and it did touch raring
<cjwatson> And foomatic-db-engine no longer has a Task field
<ogra_> \o?
<ogra_> err
<ogra_> \o/
<cjwatson> Yeah, there we go, Xubuntu was lucky in its timing
<cjwatson> So I'll just have to do Ubuntu desktop and Kubuntu again later
<knome> \o/
#ubuntu-release 2013-03-10
<xnox> please respin kubuntu desktop after https://launchpad.net/ubuntu/+source/ubiquity/2.13.13.1 lands
<Laney> Do you want a FFe for me continuing the haskell transition?
<infinity> Laney: No, JFDI please.
<infinity> Laney: I don't consider "finishing pre-freeze transitions" as a "feature".
<infinity> Laney: Though, in some cases, it may pull in massive upstream changes, which need looking at, I doubt that's true of many/any of the haskell bits that still need fixing.
<Laney> Right; I'm doing it by syncing from experimental which may pull in new upstream releases with "features"
<infinity> Yeah, see above.
<Laney> Anyway, whatevs. Will carry on. Ta.
<infinity> If any of them look drastically different and feature-laden, feel free to seek individual approval for those, but in most cases, I'm happy with a generic hand-wave for the lot.
<infinity> And apart from ghc itself, and maybe some of the lower-level build tools, my bet is that 99% of the moduley things are basically unchanged aside from API porting.
<Laney> here comes 36 syncs
<Laney> (or thereabouts)
<infinity> Hrm.  It's approaching new passport time.
<infinity> Guess I should get a haircut to see if I can look eerily unchanged for 3 passports in a row.
<xnox> yeah with haskell in the way proposed-migration is a pain to look at.
<Laney> it's not that hard to skip over
<Laney> huh, you can syncpackage non-current versions
<Laney> feel free to reject the manually uploaded haskell-monad-logger
<Len-nb> xnox, (or anyone else I guess) re, ubuntustudio's ubiquity slideshow. I have fixed it in a branch. How do I get it to the package?
<Len-nb> xnox, I figured it out, my branch was marked personal.
#ubuntu-release 2014-03-03
<xnox> Archive Admins: please decruft unity8-desktop-session on arm64/powerpc/ppc64el.
<xnox> seb128: ^
<seb128> xnox, k
<seb128> hum
<seb128> oh, right, I see what you mean
<seb128> xnox, done, let's see if that makes britney happy
<xnox> =)
<seb128> xnox, bregma: https://launchpad.net/ubuntu/+source/unity8-desktop-session -> it's in the release pocket now
<Laney> that still wants to install libhybris :(
<xnox> Laney: and it needs a custom ppa to run anyway....
<Laney> O_O
<mlankhorst> can I request a syncpackage for libevdev? doesn't seem to have any reverse-depends so a soname bump should be fine
<bregma> seb128, thanks for unblocking -- Laney the libhybris installation would go away if bug #1261935 got fixed properly in the platform-api project and xnox the PPA is required because the Mir project hasn't incorporated the fix for bug #1279092 in any of its last 3 releases
<ubot2`> Launchpad bug 1261935 in platform-api "platform-api needs a non-NULL Desktop sensor implementation" [Undecided,Incomplete] https://launchpad.net/bugs/1261935
<ubot2`> Launchpad bug 1279092 in Mir "Nested Mir crashes with - what(): MesaNativePlatform::create_internal_client is not implemented yet!" [High,In progress] https://launchpad.net/bugs/1279092
<Laney> bregma: The problem is that if you install libhybris then it breaks a lot of egl programs like totem
<xnox> RAOF: are you doing MIR releases? why above MIR fixed was not included yet?
<Laney> I wonder...
<RAOF> xnox: I'm not doing Mir releases, generally; you'd be looking for duflu and/or kgunn. But that hasn't landed because it doesn't work with >1 monitor (both displays freeze rapidly)
<xnox> bregma: is there fix for multi monitor?
<xnox> bregma: i have dual screen, if you want to ssh/test
<bregma> xnox I am not a Mir developer I have no idea what their plans are
<xnox> bregma: at least it should do no harm.... and e.g. fail the unity8-desktop-session.
<xnox> bregma: who wrote the required mir patch?
<infinity> mlankhorst: Done.
<xnox> bregma: if uniy8-desktop-session crashes mir under dual-screen or relies on external ppas, it's not fit for release or to be in the archive.
<mlankhorst> infinity: ty
<bregma> xnox, do you not mean if unity8 crashes it is not fit for the archive?
<xnox> bregma: unity8 package does not crash and is fit for the archive.
<xnox> bregma: i run it all the time, as a stand-alone app.
<xnox> bregma: unity8-session-desktop package however, is not fit in the archive at the moment - as the archive does not have things it depends on in the archive.
<xnox> bregma: (the -mir one, -x11 one is fine)
<xnox> bregma: RAOF: please agree and find how to fix bug 1279092, cause otherwise we can't ship unity8 desktop session on mir in trusty.
<ubot2`> Launchpad bug 1279092 in Mir "Nested Mir crashes with - what(): MesaNativePlatform::create_internal_client is not implemented yet!" [High,In progress] https://launchpad.net/bugs/1279092
<xnox> (... or assign/delegate someone to drive fixing it)
<RAOF> xnox: racarr is investigating the âhangs with multiple outputsâ issue at the moment; it looks to be something not-treadsafe being threaded, but we're still not sure what.
<RAOF> xnox: Once we know how to make it work, it'll land.
<arges> infinity: hi. can you remove-package from quantal/precised -proposed for iproute? the package is verification-failed. thanks
<rtg> infinity, please reject Precise intel-microcode 0.20130906-p-1ubuntu1 in the Unapproved queue. I've got a newer version at Intel's request.
<cjwatson> Has anyone had a chance to consider bug 1282311 yet?  I'm almost ready to land it now, pending review
<ubot2`> Launchpad bug 1282311 in click (Ubuntu) "[FFe] libclick" [Undecided,New] https://launchpad.net/bugs/1282311
<Laney> I'll spend a chunk FFeing in a minute
<jamespage> please could the binary package for openvswitch-lts-saucy be accepted into precise-proposed
<jamespage> https://launchpad.net/ubuntu/+source/openvswitch-lts-saucy/1.10.2-0ubuntu2~ubuntu12.04.1/+build/5621984
<cjwatson> ^- not strictly required but would be nice to make the click test suite handle failures better.  feel free to apply pressure-free judgement
<doko> cjwatson, ftbfs
#ubuntu-release 2014-03-04
<cjwatson> doko: yes, already looking
<cjwatson> I blame tox
<mlankhorst> can anyone look at https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1287326 ? I want to include it in the mesa rc3 upload
<ubot2`> Launchpad bug 1287326 in mesa (Ubuntu) "[FFe] Include Temporal Deinterlacer into libvdpau1-drivers-mesa" [Undecided,New]
<darkxst> Hey release team, I filed a FFe Bug 1228765, hope can get this through, we were blocked on this until the day before feature freeze (and then was busy with ubuntu GNOME beta release last week)...
<ubot2`> Launchpad bug 1228765 in Unity Settings Daemon "[FFe] Implement DisplayConfig dbus interface and transition to gnome-desktop 3.10" [Undecided,In progress] https://launchpad.net/bugs/1228765
<mlankhorst> can libvdpau1-mesa-drivers be kicked to universe and the new binaries accepted?
<infinity> mlankhorst: Possibly.
<mdeslaur> infinity: hi! can you take a look at ffe bug 1287706
<ubot2`> Launchpad bug 1287706 in bind9 (Ubuntu) "[ffe] Please sync or merge bind9 9.9.5 from Debian" [Undecided,New] https://launchpad.net/bugs/1287706
<infinity> mdeslaur: Seems perfectly reasonable to me, but I assume it needs to be a merge, not a sync.
<infinity> Unless our delta is entirely in Debian/upstream now.
<mdeslaur> lamont added some of our changes to the debian package, so I need to take a look to see if anything is still missing
<mdeslaur> I'll take care of it if you give the ok
<infinity> Oh, I guess the only delta we had was dh_autoreconf, once I remove your security backport.
<infinity> mdeslaur: Looks safe to sync, I'll JFDI.
<mdeslaur> infinity: awesome, thanks
<infinity> mlankhorst: Done.
<mlankhorst> thanks
<ochosi> hey folks! would someone of you help xubuntu out and upload light-locker-settings? (it's already in the queue, but as it's a newly written app it would be great if it could get wider testing before release, i.e. landing it asap would be great!)
<seb128> ochosi, upload from where? you want sponsoring? that's probably something for #ubuntu-devel
<Laney> it's in NEW
<seb128> oh
<seb128> NEW review, not upload
<seb128> let me have a look
<ochosi> thanks seb128
<seb128> ochosi, not a NEW blocker but it's a bit weird that INSTALL, .desktop and Makefile.in.in are +x
<ochosi> seb128: hm, i didn't do the packaging, but i'll get our packagers to do a bugfix release for that
<seb128> thanks
<ochosi> i.e. light-locker-settings 1.0.1 or something
<seb128> if [ -e light-locker-settings/$APPNAME.pyc ]
<seb128>     then %python% light-locker-settings/$APPNAME.pyc "$@"
<seb128>     else
<seb128>         if [ -e light-locker-settings/$APPNAME.py ]
<seb128>             then %python% light-locker-settings/$APPNAME.py "$@"
<seb128> that looks "weird" as well
<ochosi> i can also forward that
<seb128> ochosi, ok, no real issue, accepted
<ochosi> thanks a bunch!
<seb128> ochosi, thanks for forwarding the comments ;-)
<ochosi> no problem, thanks for really looking at stuff :)
<ochosi> (instead of "just uploading" it)
<seb128> ochosi, ^ (yw ;-)
<ochosi> weeee! \o/
<ochosi> thanks seb128
<Noskcaj> Can someone please look at bug 1282937 ?
<ubot2`> Launchpad bug 1282937 in xfburn (Ubuntu) "FFe: Please package xfburn 0.5.0" [Undecided,Confirmed] https://launchpad.net/bugs/1282937
<Noskcaj> It's needed for xubuntu 14.04
#ubuntu-release 2014-03-05
<Riddell> any thoughts on how to fix this ppc64el build? https://launchpad.net/ubuntu/+source/strigi/0.7.8-1ubuntu1/+build/5619309
<Riddell> the relevant code hasn't changed
<Riddell> reset(int64_t newpos)
<Riddell> it doesn't treat that as a long I think
<Riddell> and of course I've no machine I can test it on
<Riddell> and it's blocking all of kde!
<cjwatson> I'd have thought the types should actually match, rather than just happen to be the same width; find the call site and cast the arg to int64_t?
<cjwatson> do you have any clue where the call site might be?
<cjwatson> C++ being kind of unhelpful here
<cjwatson> I can test-build a diff for you
<cjwatson> or otherwise be teleoperated
<Riddell> cjwatson: I found a patch which is reported to fix it, could you try it out? https://github.com/falsifian/nixpkgs/blob/ead311aaf06ca9d80efdd9bbcd1ddb0d13536e93/pkgs/development/libraries/strigi/export_bufferedstream.patch
<cjwatson> ok, just making sure I can reproduce the original failure
<cjwatson> Riddell: Yes, that fixes it
<Riddell> cjwatson: great, thanks
<zul> can someone grant the FFE for libvirt(#1287840) and libvirt-python(#1287841) please?
<rtg> slangasek, how do we get a 12.04.5 milestone in LP ?
<slangasek> rtg: you prod a member of the release team ;)
<rtg> slangasek, is't that what I'm doing ? :)
<slangasek> yes
<slangasek> I was answering your question as asked :-)
<rtg> too subtle for me
<slangasek> do we have a target date?
<rtg> ogasawara, ^^
<slangasek> I've created it as 2014-08-07 for the moment
<rtg> cool. thanks.
<ogasawara> rtg: we didn't have a target date, but we do now :)
<rtg> just wanted to make sure linux-firmware got uploaded beforethen
<rtg> or approved, rather
<roaksoax> can someone please review this FFe? https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1281881
<ubot2`> Launchpad bug 1281881 in maas (Ubuntu) "[FFe] Standing FFe for 14.04 features" [Critical,New]
<darkxst> gnome-onliner-miners is still stuck in NEW, anyone able to bump it through?
<Riddell> darkxst: accepted
<darkxst> Riddell, thanks!
#ubuntu-release 2014-03-06
<zequence> I'm wondering if it's possible to add new features to an installer for a point release. Backporting is probably not going to do it.
<zequence> The flavor in question is Ubuntu Studio, so not vanilla
<xnox> zequence: depends on what the feature is and will need approval from the sru-team.
<xnox> zequence: e.g. UEFI & SecureBoot support was introduced in 12.04.2 and was not present in .0 nor .1. But that did fall under hardware-enablement SRU.
<zequence> xnox: I'm dropping trying to get ubuntustudio-live in this late. Lack of time, and it's getting way past FF. But, the LTS is worth polishing.
<zequence> I was thinking of adding the additional plugin(s) to our existing ubuntustudio-live-settings instead, and trying to SRU it, once we got it working for 14.10
<xnox> zequence: i'm not sure what you'd gain from it. Most people upgrade, thus whatever features/options install offers must also be possible to get via manual actions on installed/upgraded machine.
<xnox> zequence: changing installer is risky, but i guess run it by the sru-team.
<xnox> zequence: when ubuntu-one page was developed, it did land in the installed, disabled-by-default.
<xnox> zequence: later when testing via boot-time option uncovered nasty issues, we delayed enabling ubuntu-one page by one release.
<xnox> zequence: so do land as much code as you can, but keep it disabled / under feature flag until it's ready. that way it would be easier for you to test the built/live cds as well.
<infinity> zequence: You still have 6 weeks before release, surely you can get your bits in and tested?
<zequence> I'm not really that worried it won't work. There's plenty of time for testing until 14.04.1. More worried about time and quality, really
<xnox> zequence: ship it, if it would need fixing, it will be sru-worthy bugfix for .1.
<xnox> zequence: ubiquity as shipped in precise .1 was very different from ubiquity shipped in precise .0. We did drop plugins and fixed a of bugs.
<bdmurray> slangasek: there was some discussion about webapps and extensions go through the SRU process at some UDS recently right?
<bdmurray> slangasek: found it
<bdmurray> Anyway, shouldn't the saucy upload of unity-chromium-extension reference an SRU bug?
<slangasek> bdmurray: yes, I don't think the discussion at UDS changed the overall shape of the process, including the requirement for SRU bugs for tracking
<slangasek> bdmurray: also, I'm pretty sure we only talked about expedited SRUs for webapps, not for extensions
<slangasek> (well, I say that as someone who didn't make it to the actual session ;)
<bdmurray> slangasek: right I found the blueprint / wiki page and they were related to only webapps
<bdmurray> slangasek: so who would I ping about this sync request?
<slangasek> ah, whoever requested it?
<bdmurray> The Ubuntu Archive Robot? or is there somewhere else to look
<slangasek> hmm
 * slangasek tries to see
<slangasek> where was it synced from/to?
<bdmurray> from the SRU staging ppa
<slangasek> whose SRU staging ppa?
<bdmurray> https://launchpad.net/~ubuntu-unity/+archive/sru-staging
<slangasek> ah
<slangasek> so I don't know if a reject generates a mail to whoever requested the sync
#ubuntu-release 2014-03-07
<ScottK> Right.  So now that I fixed the bug in clamav where the test suite didn't actually run, turns out the existing ppc64el binaries probably don't work.
<ScottK> Removing them wouldn't be a real regression and I've no idea about fixing it.
<ScottK> Thoughts?
<ScottK> Sorry.  Meant that for -devel.
<sergiusens> can someone check this? https://bugs.launchpad.net/ubuntu/+bug/1282966 need to figure out if I logged it right
<ubot2`> Launchpad bug 1282966 in Ubuntu "[FFe] Sync golang-go-dbus 1~bzr20140217-1 (universe) from Debian unstable (main)" [Undecided,New]
<cjwatson> processed
<cjwatson> no idea what John Kim was thinking but it was obviously nonsense ...
<sergiusens> thanks
<jamespage> !regressionalert
<ubot2`> Factoid 'regressionalert' not found
<infinity> jamespage: Wrong channel for that.
<jamespage> infinity, yeah - I noticed :-)
<jamespage> doing it in the right place now
<rsalveti> infinity: mind checking bug 1289455?
<ubot2`> Launchpad bug 1289455 in Ubuntu "[FFe] Including kernel packages for Nexus 5" [Undecided,New] https://launchpad.net/bugs/1289455
<Noskcaj> Can someone look at bug 1282937 please?
<ubot2`> Launchpad bug 1282937 in xfburn (Ubuntu) "FFe: Please package xfburn 0.5.0" [Undecided,New] https://launchpad.net/bugs/1282937
<ScottK> infinity: ^^^ if you're still around - that's the exact change from Debian that fixed it in Trusty.
<ScottK> OK, so maybe Adam's onto his next flight.  If any other SRU team member is around, I'd appreciate a look at the saucy check SRU I mentioned above.  It's blocking me backporting the current clamav and I'd really like to get that done.
<stgraber> ScottK: accepted
<ScottK> stgraber: Thanks.
<ScottK> stgraber: I've verified the check SRU by rebuilding a package that failed before.  I'm not sure how much sense letting it sit and age makes.  The only way that will result in testing happening is if someone else uploads an SRU/backport that happens to use check's .pc file.  I'd be tempted to push it out.  Your call though since I'm not acting with my SRU hat on here.
<stgraber> yeah, I'm fine with that, will release it now
<stgraber> there you go
<ScottK> Thanks.
<bdmurray> slangasek: I uploaded an ubuntu-release-upgrader SRU to the saucy queue if you are reviewing today...
<slangasek> bdmurray: looking
<bdmurray> also any idea why release.tar.gz.gpg is slow to be created?
<bdmurray> http://archive.ubuntu.com/ubuntu/dists/trusty/main/dist-upgrader-all/current/
<slangasek> hum, that seems like it shouldn't happen
<bdmurray> looking at the saucy one there is about a 10 minute delay
<slangasek> no idea why... what populates the rest of the dir?
<bdmurray> I think its DistUpgrade/build-dist.sh
#ubuntu-release 2014-03-08
<bdmurray> nope, build-tarball.sh
<slangasek> but the signing is done somewhere else, and the current/ symlink is published before the signing is done?
<bdmurray> I guess, I'm not sure where the signing is done
<slangasek> I suppose the bug lies somewhere in launchpad then
<bdmurray> any upgrade without the .gpg file will fail though
<slangasek> sure, it's certainly a bug to be doing this out of order
<bdmurray> agreed
<slangasek> bdmurray: bug #1289604, this is in the twisty maze of upgrades that always confuses me.  Can you document in the bug description which upgrade paths this SRU is supposed to fix?
<ubot2`> Launchpad bug 1289604 in update-manager (Ubuntu) "ubuntu-release-upgrader doesn't depend on python-apport" [High,In progress] https://launchpad.net/bugs/1289604
<bdmurray> slangasek: this affects a Saucy system trying to upgrade to Trusty as a default Saucy system does not have python-apport installed, subsequently not all or maybe no crashes of the release upgrader are caught.
<slangasek> bdmurray: but why is this run under python instead of python3 for the saucy->trusty upgrade path?
<bdmurray> slangasek: is python3 installed by default on Precise?
<slangasek> bdmurray: no, but you said this was for saucy->trusty
<bdmurray> slangasek: yes, but Precise and Saucy use the trusty.tar.gz
<slangasek> ah
<slangasek> didn't we discuss at some point a clever plan to make trusty.tar.gz automatically use the correct interpreter based on the source distribution?
<bdmurray> I don't recall the clever plan.
<slangasek> ok
<slangasek> maybe I'm confusing it with some other clever plan for things that reexec themselves
<bdmurray> slangasek: description updated
<bdmurray> slangasek: should I email our team (since someone might know more) about the gpg file?
<slangasek> bdmurray: thanks, u-r-u accepted
<slangasek> bdmurray: yeah - I would say #launchpad-ops, but it's a bit late in the week for that
<bdmurray> thanks
<xnox> slangasek: would you be able to review debian-installer in precise unapproved queue? it's a kernel version bump across the board, but it's needed to resolve
<xnox> bug #1276739
<ubot2`> Launchpad bug 1276739 in debian-installer (Ubuntu Precise) "partman-crypto uses xts by default, yet xts.ko kernel module is not present in 3.2 (original-point-zero stack) crypto-modules-udeb" [High,In progress] https://launchpad.net/bugs/1276739
<slangasek> xnox: ok, looking
<xnox> i think it did it right... (it's my first d-i itself upload)
<slangasek> xnox: if this is for bug #1276739, why no reference to that in the changelog?
<ubot2`> Launchpad bug 1276739 in debian-installer (Ubuntu Precise) "partman-crypto uses xts by default, yet xts.ko kernel module is not present in 3.2 (original-point-zero stack) crypto-modules-udeb" [High,In progress] https://launchpad.net/bugs/1276739
<slangasek> (there's even an open bug task... so the upload should really reference it for SRU tracking)
<xnox> slangasek: well i added the bug task, and none of the other kernel bumps had sru bug numbers. (e.g. well d-i/ubiquity rebuilds rarely include bug numbers of sru's of included components).
<slangasek> ok
<xnox> slangasek: affected people will have to update their pxe-boot setup anyway, it's not like it's something that apt-get dist-upgrade resolves.
<slangasek> accepted
<apw_> hv-kvp-daemon-init was erroneously building on i386 when we have not been building the hv daemons for that arch, this upload cleans that up but it is therefore now NBS on i386.
<infinity> apw: hv-kvp-daemon-init NBS cleaned up.
<apw> infinity, thanks a lot
<Noskcaj> Can someone please look at bug 1282937 ?
<ubot2`> Launchpad bug 1282937 in xfburn (Ubuntu) "FFe: Please package xfburn 0.5.0" [Undecided,New] https://launchpad.net/bugs/1282937
#ubuntu-release 2014-03-09
<ockham> okay, gourmet 0.17.0 has landed in sid, see https://bugs.launchpad.net/ubuntu/+source/gourmet/+bug/1286073. can i get an FFe, please?
<ubot2`> Launchpad bug 1286073 in gourmet (Ubuntu) "[FFe] Please update gourmet to 0.17.0" [Undecided,New]
<infinity> ockham: Done.
<ockham> infinity: thx a lot!
<teward> infinity: i doubt nginx 1.4.6 would qualify for an FFe, right?  Because it adds new features?  (debian changelog: http://metadata.ftp-master.debian.org/changelogs//main/n/nginx/nginx_1.4.6-1_changelog )
<teward> (I ask because nginx mir is 1.4.5 and latest nginx stable is 1.4.6)
<teward> (nginx mir being the version in the process of being considered for main inclusion)
<infinity> teward: Well, the MIR still had the isssue that we can't do it without disabling lua for all flavours, or porting to lua5.2
<teward> infinity: we're already dropping lua
<teward> for the MIR
<teward> that's already been decided
<teward> (if they need Lua they can use the nginx team ppa)
<infinity> teward: Are we?  Okay.  People do realise this is for *all* flavours, right, not just the one in main?
<teward> infinity: the moment the MIR is approved i'm going to preemptively make a bug about it, and Won't Fix it.  So we can point people to that.  And maybe we should add a NEWS entry
<teward> but that's outside the scope of the question i asked here
<infinity> teward: So, as to the 1.4.5->1.4.6, I'd need to see the upstream diff and changelog, the Debian one isn't helpful.
<teward> i can probably find that
<teward> would a full debdiff between 1.4.5 and 1.4.6 work?
<infinity> Well, just a debdiff between Debian 1.4.5-1 and 1.4.6-1 is enough for me to go hunting through.
<infinity> Jinx.
<teward> :p
<teward> infinity: my concern is these lines in the debian changelog:      + Enable realip module for nginx-light.   + Enable debug module for nginx-light and nginx-extras.
<teward> those add new modules (i.e. new features) to those flavors
<infinity> That's fine.  *shrug*
<teward> standby for debdiff then
<infinity> I mean, if the overall changeset is otherwise fine, that probably is.
<infinity> rsalveti: Are you going to get the kernel team to toss hammerhead in git and do the uploads, or will you be maintaining it seperately?
<teward> infinity: http://paste.ubuntu.com/7062711/ is the debdiff between debian 1.4.5-1 and 1.4.6-1
<infinity> apw: Do you have any context on the hammerhead AOSP kernel?
<teward> if you're willing to approve an FFe, I'll file a bug requesting the merge, and see if cjwatson can merge it (they helped with the last merge)
<teward> then rebase the MIR debdiff on 1.4.6
<infinity> teward: Ahh, kay, to the point of that was module normalisation between the flavours, and the addition of a common_config.  I totally support that change.
<teward> infinity: if you can post on https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1290063 about an FFe being approved, after you review the debdiff, then I'll poke cjwatson :)
<ubot2`> Launchpad bug 1290063 in nginx (Ubuntu) "[FFe needed] Please merge nginx 1.4.6-1 (universe) from Debian unstable (main)" [Undecided,New]
<teward> (and it's a merge because we have a version string delta)
<infinity> Right, so, let's see the merge, and then the MIR patch updated to use the new debian/rules structure, and get it all done today.
<infinity> I don't think Colin will in any way care to be involved, he's TIL on nginx by accident, not design.
<teward> okay
<teward> infinity: i may not be able to do the merge, the last time i tried it FTBFS in sbuild
<teward> so i probably did something wrong
<infinity> Let me have a poke at it.
<teward> infinity: thank you kindly.
<teward> infinity: and RE the Lua drop in all the flavors for the MIR, I'm going to post on my own blog about it, and it'll end up on planet.u.c so then there'll at least be some visibility there
<teward> besides, when Ubuntu comes up in #nginx they poke me xD
<teward> (same for #ubuntu-server)
<infinity> teward: Yeah.  I wish there was some indication of how widely that feature was used.
<infinity> teward: If we're crippling something a lot of people relie on just for the sake of putting it in main, the MIR is completely pointless, IMO.
<infinity> I suppose I should correct attribution on this branding patch while I'm in here...
<infinity> I should probably make it smarter, so it can be submitted to Debian.
<infinity> Though, I suppose now that we'll have a delta for the new flavour, that's a bit less interesting. :/
<infinity> teward: Merge uploaded.
<rsalveti> infinity: will maintain it separately, as it's not officially supported by them
<infinity> rsalveti: Well, none of them are "officially supported", AFAIK, but does it really make sense to have one exist outside where the rest are?
<rsalveti> infinity: well, the kernel team is responsible for the other ones :-)
<rsalveti> infinity: I can ping them tomorrow and see if they can/want to manage that branch together with the other ones
<infinity> rsalveti: Right, I'd argue that they should all live in the same repo with the same level of responsibility.
<infinity> rsalveti: We've never had a good track record with forked kernels maintaining coherent CONFIG_ options, etc.
<infinity> Or security fixes, blah blah.
<rsalveti> right, this one is at least following the same configs and containing the same sauce as we currently have for the other flavors
<infinity> rsalveti: Key word "current".  They diverge pretty quickly if people aren't very careful.
<rsalveti> right, but at least I'm mostly involved with any other sauce or config change we get anyway
<infinity> teward: Aaaand, uploaded again to fix the FTBFS on ppc64el.
<infinity> teward: So, if you want to rebase your MIR patches on top of 1.4.6-1ubuntu2, I can review and sponsor.
<infinity> rsalveti: That will immediately stop being true if we decide we want to do post-release (SRU/security) support for them.
<infinity> rsalveti: Which is probably still up in the air, but we've been looking at how painful it would be.
<infinity> rsalveti: Anyhow, the N5 being one of the only Nexus devices you can actually buy, it seems odd if that's the only kernel our kernel team DOESN'T maintain. :)
<rsalveti> infinity: right, but only mako, manta and flo are officially supported (by the canonical kernel team), the rest is all community supported
<rsalveti> infinity: and how should we do then if we want to include any other kernel tree that the community wants to support?
<infinity> rsalveti: Oh, I'm not against community supported kernels, I just question this specific one.
<rsalveti> I was thinking initially to maintain them at https://code-review.phablet.ubuntu.com/gitweb?p=ubuntu/kernel/trusty.git;a=summary (same place we're currently using for nexus 5)
<infinity> rsalveti: Is that a git repo you can give external access to?
<rsalveti> oh, ok, so it's more a question if we want to keep this as a community supported device or if we'll end up officially supporting it later on
<infinity> (If not, the "community" part of that is a bit of a joke)
<rsalveti> infinity: they can all use it via gerrit
<infinity> rsalveti: So, we don't "officially" support anything, but we also officially support some things.  Unofficially.
<rsalveti> propose patch series and so on
<rsalveti> indeed :-)
<infinity> rsalveti: But the N5 seems like it should be on that unofficially official list.
<rsalveti> nothing from touch is officially supported, but the canonical kernel team has the reponsability to maintain the tress for mako, manta and flo (doing security fixes, bug fixes, and maintaining the latest apparmor in there as well)
<infinity> rsalveti: Given that mako is in that list, and I can't actually buy a mako, but I can buy a hammerhead...
<rsalveti> right, but this is more a question for rick I'd guess
<infinity> rsalveti: So, yeah.  I think we should have a chat with apw/rtg and get hammerhead in the same repo as mako/manta/flo
<rsalveti> no worries, will ping them tomorrow
<infinity> rsalveti: I don't see how Rick is involved...
<rsalveti> rick, together with asac, made the decision to keep only supporting mako and not support hammerhead (from the canonical side)
<infinity> rsalveti: I mean, what you guys (the phonedations folks) decide to advertise as supported *images* is up to you and your management, but I think the *kernel* should be in the kernel team's repo, that's all.
<infinity> (Would definitely be nice, if all the bits can fit together in time, to support N5 *images*, but that's more work than just a kernel, so I understand if it's not a realistic goal)
<rsalveti> yeah
<rsalveti> would need to buy a bunch of devices to put in the qa lab and so on
<rsalveti> but anyway, we can have this discussion tomorrow with the kernel team
<infinity> Well, at least they exist. :P
<infinity> And hey, if you give me an N5 image that doesn't suck, I might actually run it.
<rsalveti> :-)
<infinity> rsalveti: Anyhow, this is all best-practices source management talk.  It doesn't really affect the MIR.
<infinity> rsalveti: As I said on the MIR bug, if you build against the same orig, so I can easily check deltas and review it (and if it passes AA review), the MIR is fine.
<rsalveti> yeah, makes sense
<infinity> Erm, though rtg might not have switched to using a common orig yet.  He told me he was going to.
<infinity> Ahh, manta uses the orig.  mako doesn't yet.
<rsalveti> yeah, I don't think they are using a common tree yet
<infinity> What a fine mess this all is.
<rsalveti> indeed
<apw> infinity, they don't use an orig (mako) cause it has some binary crap in it which is "different" so cannot be represented
<apw> needs figureing out
<infinity> apw: Oh, ick.
<teward> infinity, i'll rebase the patches as soon as my parents give me some [censored] freedom... until then i have insufficient internet strength to download the latest changes you've done.
<teward> s/done/uploaded/
#ubuntu-release 2015-03-02
<ochosi> if any admins are about, please release libxfce4util from NEW so we (xubuntu) can trigger rebuilds of related packages and continue to upload xfce4.12
<mlankhorst> \o/ all mesa regressions from 10.4 to 10.5 on radeon are gone in mesa 10.5 rc3
<sil2100> Hello release team! We would need someone to take a look at the FFe that has been filled for the new oxide release: LP: #1425599
<ubot93> Launchpad bug 1425599 in oxide-qt (Ubuntu) "[FFE] oxide 1.5" [Undecided,New] https://launchpad.net/bugs/1425599
<sil2100> Hello release team! I would like to re-poke regarding the FFe for oxide: LP: #1425599
<ubot93> Launchpad bug 1425599 in oxide-qt (Ubuntu) "[FFE] oxide 1.5" [Undecided,New] https://launchpad.net/bugs/1425599
<sil2100> It is ready for release in a silo, but we don't know if we can publish without a clear decision beforehand
<jdstrand> can someone take a look at the oxide 1.5 FFe? (bug #1425599)
<ubot93> bug 1425599 in oxide-qt (Ubuntu) "[FFE] oxide 1.5" [Undecided,New] https://launchpad.net/bugs/1425599
<jdstrand> oSoMoN and chrisccoulson can speak to the actual changes
<jdstrand> but oxide is in a weird area wrt to this FFe. we plan to push this to stable releases because it is a security update. however, there are some features in it that are for important phone bugs
<jdstrand> in other words, oxide was specifically created to address security issues, fix bugs and implement features to enhance the phone (ie, it uses the firefox model), yet it is blocked on FFe
<jdstrand> seems we wouldn't block firefox-- we would just upload it
<jdstrand> I'm not sure that it helps, but we discussed that we will pursue an MRE for oxide after vivid releases since it is a lot like firefox, and firefox has one
<jdstrand> slangasek: not sure if you have time? ^
 * jdstrand is happy for anyone to look at it. it looks like it was requested a week and a half ago
<ogra_> why does it need an FFe at all ?
<ogra_> given it is a rolling package across all releases anyway
<jdstrand> ogra_: right
<jdstrand> I'm not sure why oSoMoN was advised to file one
<jdstrand> I think sil2100 may have requested it, but not sure where this was discussed in terms of formal processes (if at all)
<oSoMoN> Mirv initially told me Iâd need to file an FFe
<sil2100> I wasn't aware of any exceptions, so FFe was the safest bet - and if someone from the release team would comment that we don't need those, well, we wouldn't request it anymore ;)
<sil2100> I understand all the rationale, it's just that since it's a release-team decision I wanted to have some confirmation from their side
<ogra_> sil2100, well, browsers are generally rolling anyway
<jdstrand> right, well, the argument is out there for the release team to comment. we'll pursue a MRE to kinda cement the idea for stable releases
<infinity> jdstrand: I take it as a given that firefox, chromium, and oxide don't require FFes.
<infinity> sil2100: ^
<infinity> jdstrand: And the firefox/chromium stable exception (which oxide should get by default, IMO), isn't an MRE, unless you change the meaning of "M". :P
<Laney> MyGodWhatIsThis
<jdstrand> infinity: great, thanks!
<sil2100> infinity: thanks :)
<sil2100> jdstrand: ok, let me publish then
<Mirv> are the rollingness exceptions documented somewhere?
<Mirv> or only as MRE after the release as discussed
<Ukikie> https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions is the only one I see, and for firefox this is a micro release. :P
<Mirv> from documentation point of view the problem is thet MRE are for after-release stable release updates, and it'd be nice if the process would be clear for the whole dev cycle + stable period
<infinity> Ukikie: Yeah, we could do with clearing up the browsers as being unique snowflakes in this regard.
<infinity> Mirv: And we could also do with clearing up that MREs for stables imply MREs for the devel series, as long as the upload doesn't destabilise the world during release week or something equally silly.
<ScottK> Hmmm.
<ScottK> For clamav I've always asked for the FFe even though we push major versions to all releases.
<ScottK> I took it as a given it would get approved as long as the timing was non-insane, but I didin't think I was excused from asking.
<infinity> ScottK: I think it's paperwork overload for things we expect to be updated anyway, but ymmv.
<ScottK> OK.  I can accept that and I'm all for not doing unneeded paperwork.
<ScottK> I do think we ought to have the list of packages this applies to documented somewhere.
<ogra_> +1
<infinity> ScottK: Yeah, I think the MRE wiki page needs a section for the rare Major Release Exceptions.  I suspect the reason it doesn't is because we prefer to pretend they don't exist, thus not setting precedent for others to say "I deserve that too!"
<infinity> ScottK: But with enough strong wording of the sort that "these packages are unique snowflakes and get to ship new major versions, but if you ask for that for your own package, the TB's default answer is always no, have a nice day", we can break them out into their own section and be more explicit about it.
<ScottK> Conveniently keeping the same acronym preserves deniability.
<bdmurray> slangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/phasing-progress-link/+merge/251517
#ubuntu-release 2015-03-03
<bluesabre> ScottK: would you mind ack'ing the extra released components in https://bugs.launchpad.net/ubuntu/+source/xfce4-session/+bug/1424887 ? at the least, the updated garcon and libxfce4util provide updated libraries with the xfce-4.12 release
<ubot93> Launchpad bug 1424887 in xfce4-settings (Ubuntu) "[FFe] Xfce 4.12 for Vivid" [Undecided,Triaged]
<jamespage> morning - I have a couple of FFe's that I'd like to get reviewed if there is a release team member around - bug 1423601 and bug 1426761
<ubot93> bug 1423601 in ceph (Ubuntu) "[FFe] ceph 0.93 -> hammer release" [High,New] https://launchpad.net/bugs/1423601
<ubot93> bug 1426761 in pacemaker (Ubuntu) "[FFe] Upgrade pacemaker to 1.1.12" [Medium,New] https://launchpad.net/bugs/1426761
<jamespage> pretty please
<jamespage> :=)
<sil2100> Hello release team! We would like to get opinion on whether or not we will need to fill in a FFe for the new UITK release that's being prepared
<sil2100> It's a big release and the developers mentioned that there might be features changed, but only to fix long-standing bugs
<sil2100> https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/uitk12_final_vivid_landing/+merge/251578
<sil2100> Will we have to pressure for an FFe in this case
<tumbleweed> it sounds like it'd require an FFe. New features require FFes. Bug fixes only don't.
<doko> tumbleweed, no, there are exceptions for stuff like firefox, openjdk, etc ...
<tumbleweed> and uitk isn't in that list
<bzoltan_> tumbleweed:  no application is using the UITK on desktop other than the SDK IDE what we maintain.
<tumbleweed> then the FFe should be easy to grant
<Laney> webbrowser-app
<bzoltan_> tumbleweed:  tbh the FFe in our case would be a pure administrative overhead ... the UITK is pretty much on rolling release to the RTM
<tumbleweed> then it presumably shouldn't be getting new features after FF
<bzoltan_> tumbleweed: it does not
<tumbleweed> then it doesn't need an FFe. The rules are pretty simple. Bugfixes that don't break other things, and don't introduce new features don't require an FFe
<bzoltan_> tumbleweed:  I am the lander, I do not want to do FFe, because I think it is a pointless administrative overhead. So my opinion os not exactly objective :) So I am looking for somebody who's opinion counts in this case. I can answer questions about this landing.
<tumbleweed> bzoltan_: I don't understand what you want. If your upload fits within the FF rules, there isn't a problem. You seem to say that it does, but you also seem to want someone else to approve it, sight unseen.
<bzoltan_> tumbleweed:  I am only looking for second opinion :)
<tumbleweed> and that's less work than an FFe?
<ScottK> Not at the rate we're going.
<ScottK> bzoltan_: Needs FFe.
<ScottK> (I did look at the diff)
<tumbleweed> generally rule of thumb: "Don't know if this needs an ffe" => it does
<ScottK> I was pretty sure by line 8 of a 20K line diff.
<bzoltan_> ScottK: tumbleweed: https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1427662
<ubot93> Launchpad bug 1427662 in ubuntu-ui-toolkit (Ubuntu) "[FFe] Release UITK 1.2" [Undecided,New]
<ScottK> bzoltan_: Approved.
<bzoltan_> ScottK: Thank you
<zul> can i get an ack for python-eventlet 0.7.0 FFE please (#1424639)
<cyphermox> could someone please take a look at console-setup-freebsd, removing it so that console-setup can complete its transition to -release?
<infinity> cyphermox: Yeahp.
<cyphermox> infinity: thanks. good morning :)
<infinity> cyphermox: FWIW, changing the Depends lines seems like unnecessary delta.
<infinity> cyphermox: "Depends: foo | bar" when only foo is in Ubuntu is fine, after all.
<infinity> cyphermox: Also, you didn't drop the freebsd udebs...
<cyphermox> infinity: I'd like to make all of it unnecessary, will propose debian to make console-setup-freebsd Arch: kfreebsd-any.
<cyphermox> infinity: the freebsd udebs are fine, really
<infinity> cyphermox: Why the deb, but not the udebs?
<cyphermox> deb is uninstallable due to vidcontrol, kbdcontrol being uninstallable.
<cyphermox> the udebs people could use if they really wanted to, I guess
<cyphermox> I mean, really, really wanted to
<infinity> Fair enough.
<infinity> Should sort itself on the next britnification.
<cyphermox> thanks
<ari-tczew> could someone take a loon on package osm-gps-map/1.0.2-2 what's wrong with that in -proposed? It contains RC bug fix.
<infinity> Trying easy from autohinter: osm-gps-map/1.0.2-2 gnuais/0.3.2-1
<infinity> leading: osm-gps-map,gnuais
<infinity> start: 158+0: a-48:a-22:a-23:i-22:p-21:p-22
<infinity> orig: 158+0: a-48:a-22:a-23:i-22:p-21:p-22
<infinity> easy: 159+0: a-49:a-22:a-23:i-22:p-21:p-22
<infinity>     * amd64: gpxviewer
<infinity> FAILED
<infinity> ari-tczew: You could read update_output.txt as well as I can to sort out what that means, I suspect.
<infinity> ari-tczew: (That's saying that updating those packages breaks gpxviewer)
<ari-tczew> infinity: right, I forgot about proposed-migration
#ubuntu-release 2015-03-04
<doko> infinity, please could you have a look at the creduce SRU for trusty?
<infinity> doko: So, normally I'd say "WTF, why the backport?", but the diff looks pretty small when you remove all the autotools cruft.  Can you snag an upstream commit log from 2.2~pre1 to 2.2.1 to show us what's fixed and why the backport makes more sense than fixing what's in trusty
<infinity> ?
<doko> well, it works for me without creduce segfaulting anymore since utopic ...
<infinity> doko: Sure, that's also a good reason.  I'd just like to see a commit log to get a better feel for it, rather than trying to audit code I don't know.
<doko> and honestly, who cares?
<infinity> doko: FWIW, that's not me pushing back, that's me saying "yes, this sounds sane, just show me the logs please". :P
<doko> well, then don't push back
<doko> infinity, please see https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/ppa/+sourcepub/4814961/+listing-archive-extra
<infinity> doko: How does pointing me at a PPA build give me the thing I asked for?
<doko> you asked for logs
<doko> infinity, afk now. if you want something different, please tell
<infinity> doko: I asked for upstream commit logs.
<infinity> doko: Twice.
<doko> infinity, so you don't have an utility to remove generated files from a diff?
<infinity> doko: No, I want an explanation of the changes, is that so much to ask for for an SRU?
<doko> infinity, yes, it's to much for the case of creduce
<doko> hmm, why is python-click rejected?
<doko> cjwatson, infinity: ^^^ any idea about python-click?
<cjwatson> doko: I set a message when I rejected it.  You should have mail.
<cjwatson> doko: I already removed the same version from Ubuntu previously.  Its binaries conflict with those from click, and so it can't be accepted into Ubuntu.
<doko> I see
<doko> same module name even?
<cjwatson> Don't know, don't care
<cjwatson> Overlapping binary package names
<doko> yes, and same module name :-/
<cjwatson> Nothing we can really do.  IME Mark doesn't care about name conflicts with other bits of free software.
<bluesabre> in my excitement to get a working exo, I forgot to make it auto-close bug 1424887
<ubot93> bug 1424887 in xfce4-settings (Ubuntu) "[FFe] Xfce 4.12 for Vivid" [Undecided,Triaged] https://launchpad.net/bugs/1424887
<doko> cjwatson, ok, renamed the binary package names. can I keep the source name? easier to follow-up with Debian
<cjwatson> doko: Sure
<cjwatson> I'll let some other archive admin look though; I didn't do any actual review, just noticed the conflicts in binary NEW some time back
<coreycb> arges, hi, would you be able to publish python-eventlet 0.13.0-1ubuntu3.2 to utopic-updates today?  bug 1423675
<ubot93> bug 1423675 in python-eventlet (Ubuntu) "[SRU] python-eventlet fall back to old behavior if SSLContext is not available" [Undecided,New] https://launchpad.net/bugs/1423675
<apw> coreycb, i am not sure arges will be about at all today
<coreycb> apw, ah, right..
<coreycb> bdmurray, would you be able to publish  python-eventlet 0.13.0-1ubuntu3.2 to utopic-updates today?
<bdmurray> coreycb: done
<coreycb> bdmurray, thanks
#ubuntu-release 2015-03-05
<tedg> Hello, I need someone to delete some binaries for me.
<tedg> I have a branch of ubuntu-app-launch which adds a dependency on libmir
<tedg> Which means it can't build on PPC until Mir does.
<tedg> (which sucks, but eh, can't solve that one)
<infinity> tedg: That seems like an odd dependency for what the package claims to be...
<tedg> infinity, It is for a test tool to run applications, it uses a Mir trusted prompt session.
<infinity> Certainly odd for it to be required.
<tedg> It's so they can run the applications with autopilot more easily.
<infinity> tedg: And this can't be conditional?
<tedg> Hmm, it probably could be.
<tedg> Not sure it's worth it, no one is going to use it on PPC without Mir anyway...
<tedg> I might have to learn something about cmake, which would be painful :-)
<infinity> tedg: To be fair, u-a-l doesn't appear to have any revdeps on non-Mir arches anyway, I'm just continually annoyed with the "Mir isn't ported, so let's pretend it's not portable, and make everything else depend on it and also become unported" thing.
<infinity> tedg: And while people keep propping up "who wants Mir on PPC anyway?" as the excuse, they keep ignoring arm64, which is kinda the future of Mir-targetting devices.
<tedg> I'm annoyed too. We should really make Mir deal with this.
<tedg> infinity, It built on arm64
<tedg> Just not PPC and PPC64
<infinity> It did?  Is that new?
 * tedg just works here
<infinity> Ahh, indeed, the arm64 porting happened.
<infinity> Well, that's proof that ppc could as well. :P
<tedg> Cool.
<tedg> Yeah, I think it's just an effort thing.
<tedg> Someone should put it on their backlog or sprint or rave or something.
<infinity> tedg: Oh, and I lied, there are non-Mir-arch revedeps for libubuntu-app-launch2.  A few of them.
<infinity> Could take a while to untangle all of that and not raise the unstallable count. :/
<tedg> Hmm, hadn't thought about the lib results.
<tedg> Okay, I'll figure out CMake then.
<infinity> tedg: If you could make the libmir dep conditional on libmir-dev being installed, that would be much simpler.
<tedg> That's going to be easier.
<infinity> Then just arch-restrict the build-dep for now until Mir gets its act together.
<tedg> So then I make the libmir build-deb architecture specific?
<tedg> dep
<infinity> tedg: Yeah, that would do the trick.
<infinity> tedg: Make CMake DTRT depending on if the library is or isn't installed, and then make the build-dep [arch qualified] and you're set.
<tedg> K, will do.
<tedg> Thanks infinity!
<slangasek> FYI the Canonical CI team is ready to deploy a new layer of testing as part of proposed-migration, which will add boot-testing of packages that are on the phone before promotion from vivid-proposed to vivid
<slangasek> they'd like to land this today, so that if there are any problems they can be debugged before the weekend
<slangasek> any objections here?
<ScottK> slangasek: Will this be overridable by the release team?
<slangasek> good question
<slangasek> cjwatson: ^^ was there an equivalent of force-badtest for boot tests?
<ScottK> If the answer is we can override it if needed, then no objection from me.
<slangasek> ScottK: we could disable the tests as a class by pushing changes to britney
<slangasek> I'm not sure it makes sense to disable it via per-package hints
<ScottK> Depends on what we're doing when.
<slangasek> since the test is the same across packages ("does it boot?"), I don't think we want to override a failed boot test on a per-package basis
<ScottK> I don't think it makes any less sense than per package overrides in other cases.
<ScottK> Depends on if the boot failure is actually related to the package.
<ScottK> If you've got 5 relevant packages in proposed and one causes the failure, doesn't make sense to  block them all.
<cjwatson> slangasek: Same, force-badtest
<cjwatson> I made sure of that
<slangasek> ok
<ScottK> I'm fine with it then.
<ScottK> Riddell: ^^^
<cjwatson> Excuse me, sorry, it's force-skiptest.
<cjwatson> force-badtest is the one that skips a single dispatched test for a causing package out of many; in this case there's only one boottest so it doesn't make sense to support force-badtest.
<cjwatson> But force-skiptest works.
<cjwatson> I think?  In fact the code seems to support both so I could be out of date.  Anyway this is tangential to the basic point. :-)
<slangasek> ScottK: ah, for the case where we've root-caused the failure to a particular package but the test failures are blocking other packages and we want to let them through... check
<slangasek> ScottK: fwiw I would be more comfortable in that case removing the broken package from vivid-proposed and re-testing, to make sure the test *actually* passes
<slangasek> but both options are available if needed
<ScottK> slangasek: Not that it would have affected my opinion, but how long do we expect the addition of the boot test to delay package migration when there aren't errors?
<slangasek> ScottK: I haven't seen any benchmarks on that yet; but I know for instance that systemd already successfully passed a test: https://jenkins.qa.ubuntu.com/job/vivid-boottest-systemd/lastBuild/?
<ScottK> OK.
<slangasek> 14 minutes to run the whole test isn't bad, provided the system scales - which is a known pain point for CI and something they're working on this month
<ScottK> Yeah.
<ScottK> Thanks.
<slangasek> however, the set of source packages included in the phone is pretty small - so I'm confident that any problems will be minor and short-lived
<slangasek> ScottK: btw it seems that the jobs are in fact per-source package... so other packages in -proposed *won't* be entangled in the test results, further reducing the need for overrides
<ScottK> Ah.  Good.
#ubuntu-release 2015-03-07
<teward> stupid question, but is the mirrors team or release team or canonical sysadmin the ones to fix badsig problems on the mirrors
<cjwatson> sysadmin if multiple mirrors with different IP addresses; admin of mirror in question if it's just one, I'd say
#ubuntu-release 2016-03-07
<flexiondotorg> infinity, You available?
<cyphermox> flexiondotorg: anything I can help with?
<flexiondotorg> Just following up on Xubuntu Base and Ubuntu MATE Base.
<flexiondotorg> cyphermox, Can you help progress that? ^
<cyphermox> what's its current status?
<flexiondotorg> cyphermox, Xubuntu and Ubuntu MATE submitted merge proposals some weeks (months?) ago.
<flexiondotorg> infinity, Agree the the "Base" naming ans said he'd review the merge proposals.
<flexiondotorg> Then asked me to pester him a few weeks back, which I've been doing ;-)
<flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/debian-cd/ubuntu-mate-base/+merge/284435
<flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/livecd-rootfs/ubuntu-mate-base/+merge/284432
<flexiondotorg> https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-cdimage/ubuntu-mate-base/+merge/284433
<flexiondotorg> cyphermox, infinity Is there anything more I can do to help progress the Base builds for Xubuntu and Ubuntu MATE?
<cyphermox> flexiondotorg: this is good, you just need someone to merge that code; you need someone in the cdimage team for that
<knome> actually i believe there are things in the xubuntu code that need hacking, but infinity has promised to do that when merging
<knome> what we're looking for is a schedule for the merge to happen, because testing needs to be done before final release
<cyphermox> he's in a different timezone now, but I guess he'll answer and do the merges soon
<flexiondotorg> What knome said. I have testers waiting :-)
<flexiondotorg> knome, What changes do you need?
<flexiondotorg> References to wily change to xenial?
<knome> cyphermox, ack, though he's been supposed and promised to do the merges for some time and hasn't; not blaming him or anything, but i'm not believing the "i'll do that tomorrow" message any more :)
<knome> flexiondotorg, the code currently creates another product, but it shouldn't
<flexiondotorg> OK, do you think we should make the changes to the branches I've proposed to address that?
<knome> flexiondotorg, infinity has promised to do that once he looks at the merge, so no need to do anything
<flexiondotorg> Perhaps a comment on each merge proposal for infinity would be a good idea.
<coreycb> hi, can an archive admin please promote python3-suds to main? this will help get some of our openstack packages out of dep waits.
#ubuntu-release 2016-03-08
<infinity> flexiondotorg: I'm in Bangkok right now, will be looking at the base stuff when I'm not busy in sessions.
<LocutusOfBorg> I finally fixed nifti2dicom
<LocutusOfBorg> please accept :)
<LocutusOfBorg> just a dbg package added (by the debian maintainer :( )
<flexiondotorg> infinity, Enjoy your trip :-)
<cjwatson> Could somebody have a look at my apt upload to trusty-proposed, please?  I'd like to get the Launchpad backport side of that moving so that we can enable xz support so that I can then proceed with apt by-hash work.
<cjwatson> (Just in case you need incentive.)
<rbasak> Somebody being an SRU team member? Otherwise maybe smoser will want to look?
 * rbasak is a little tied up right now :-/
<cjwatson> Somebody being an SRU team member.
<cjwatson> So not something smoser can help with I'm afraid.
<yofel> from the KDE stuff, frameworks and plasma were uploaded. breeze-icons, oxygen-icons5, breeze-gtk, kscreenlocker, plasma-discover, kwallet-pam, kdeclarative and libkscreen in NEW are from that
<mapreri> actually, I guess it would be lovely if somebody just go through everything in NEW (my pet package being libreoffice-dictionaries, but it's there since only 4 hours so..)
<bdmurray> If module-init-tools was removed from xenial why is there still a candidate available? Related to bug 1550741
<ubot5> bug 1550741 in ubuntu-release-upgrader (Ubuntu) "Upgrade failed - unauthenticated package (module-init-tools)" [Critical,Confirmed] https://launchpad.net/bugs/1550741
<Laney> bdmurray: it's nbs
<Laney> I pinged a_pw about it earlier
<apw> Laney, yeah thanks for the heads up ..
<apw> if the issue is just hte nsb that sounds like it should be easy to resolve
<apw> i also thought that we b/c/r that puppy
<apw> oh we don't ... wuld that account for the behaviour ?
<apw> ie if i fixed kmod to b/c/r module-init-tools so it pushes it off first
<apw> how did that not blow up in debian i wonder
<Laney> apw: apt probably tries to update to the new version, but that is uninstallable
<Laney> and it's sort of dead to us as it is NBS
<Laney> I suppose removing the binary would be good, but I can't be completely sure
<apw> nbs rarely helps us, but yes, i would not claim to understand the fallout
<apw> i think the underlying issue is a lack of c/r/b on kmod for m-i-t
<Laney> You might need Provides to make things completely happy
<Laney> + get the NBS killed off after checking that there are no non-alternated Depends/Recommends left - the few I checked all had it
<apw> Laney, i did the alternate fixes for everything to get this to migrate in the firstplace
<Laney> cool beans
 * apw will see if i can get myself into the appropriate mess to confirm the fix
<bdmurray> apw: thanks
<coreycb> hello, can an archive admin please promote python3-mistralclient to main?  this will help get some of our OpenStack packages out of depwaits.
<cyphermox> coreycb: is the MIR already approved?
<coreycb> cyphermox, I believe so, python-mistralclient is already in main
<cyphermox> ah ok
#ubuntu-release 2016-03-09
<tai271828> hi, I note 14.04.3 iso is not in old-releases url http://old-releases.ubuntu.com/releases/trusty/
<tai271828> and still in http://releases.ubuntu.com/14.04/
<tai271828> may someone fix this url link?? thanks
<apw> tai271828, thanks for the report ... i am sure someone will sort that out by-and-by
<tai271828> apw, cool, many thanks!
<knome> could somebody bump the xubuntu ISO size limit up to 1.46GB (the capacity of an 8cm single-sided DVD, if anybody decides to use one)?
<cjwatson> knome: do you have a source for the capacity, preferably one that gives it in bytes?
 * ogra_ sighs ... who is sitting on the arm64 builders today ... they seem to operate at half speed (rootfs buulds that took 30min yesterday take 1h today)
<cjwatson> knome: hm, looks like the real specs are paywalled, I guess I'll go with 1.46 * 10^9
<cjwatson> ogra_: you got a bare-metal builder yesterday by chance.  mostly the ones that are scalingstack instances are just fine and often faster, but perhaps livefs builds are a special case due to the amount of I/O involved
<ogra_> ah, k
<cjwatson> I'm afraid we're likely to be decommissioning those bare-metal ones in the near future; we can't do sandboxing there and we're unlikely to ever be able to get more of them
<cjwatson> scalingstack is the future even if there are certain cases that go slower
<ogra_> i know the build will fail, but was hesitating to hit the cancel button since that also takes 5 min to make it time out anyway and the build was already 30min in ...
<cjwatson> if it's having to time out, then something is wrong
<ogra_> well, with tegh plans to do one image build per snappy commit a build time of 1h+ might kind of kill that idea again
<ogra_> *with the
<cjwatson> maybe it's a bad idea :)
<cjwatson> but meh, it doesn't bother us from the build farm perspective
<ogra_> heh, well, but from a queue perspective perhaps ... after 100 builds piled up there :)
<cjwatson> given 36 builders (once they're all consolidated, surely not
<cjwatson> s/,/),/
<ogra_> yay, finally failed ...
<cjwatson> but of course it depends on how frequent commits are
 * ogra_ re-kicks
<cjwatson> a good strategy is often to try to queue a build on each commit but never have more than one build queued
<ogra_> well, $mgmt asked for that, i suggested to go for 1/day for now but with keeping the 1/commit in mond for the future
<ogra_> *mind
<cjwatson> given that it will use the current versions of things at the point when the build starts anyway
<ogra_> if we move to slower disks i guess we can drop the future target though
<ogra_> (i found even the 20min to long that we had before, though there is still a lot overhead due to still producing tarballs in parallel to the snaps)
<cjwatson> I doubt that it's about slower disks, it's just that it's running on cloud instances and there'll be other stuff happening on the same compute nodes
<cjwatson> you'll probably find that variability is a bit higher
<cjwatson> measure across more than one build, separate into those that hit bos01-arm64-* and those that didn't, and take a longer-term average
<ogra_> right, though for rootfs i mostly care about disk I/O
<cjwatson> no point worrying about what could be outliers
<ogra_> ture
<ogra_> heh, now i'm on "magic" lets see the difference (before was bos-*)
<cjwatson> auburn, beebe, magic, templar, twombly are bare-metal
<cjwatson> ogra_: will do some stats for you after this call
<ogra_> wow, thanks
 * ogra_ holds his breath hoping there will be kernel snaps now ... 2min to go on amd64
<ogra_> heh, and i386 was faster
<ogra_> YAY !
 * ogra_ sees livecd.ubuntu-core.kernel.snap and livecd.ubuntu-core.os.snap at https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/+build/54633
<ogra_> now to wait for armhf which has special cases for raspi2
<ogra_> bah
<ogra_> + cp -a canonical-pc-linux_4.4.0-11-generic.efi.signed-20160309-13-06_amd64.snap livecd.ubuntu-core.kernel.snap
<ogra_> i guess i need to fix that version string
<marlinc> Test
<ogra_> + ln -s vmlinuz-4.4.0-1003-raspi2 vmlinuz-4.4.0-11-generic vmlinuz
<ogra_> ln: target 'vmlinuz' is not a directory
<ogra_> GRRRR !
 * ogra_ fixes ...
<cjwatson> ogra_: so, at least if I consider only successful builds (on the basis that failures may well have had something arbitrarily weird going on), scalingstack is consistently quite a bit *quicker*, not slower
<tgm4883> Is there any way to get dailies from a few days ago? Maybe March 4, 5, 6 or 7?
<ogra_> cjwatson, heh, well, that doesnt really go with what i'm seeing then ... at east for the two arm64 builds we talked about
<ogra_> *least
<cjwatson> ogra_: this is a bit "baby's first matplotlib", but http://people.canonical.com/~cjwatson/tmp/arm64-stats.py -> http://people.canonical.com/~cjwatson/tmp/arm64-metal.png, http://people.canonical.com/~cjwatson/tmp/arm64-scalingstack.png
<cjwatson> ogra_: if you want to argue with the aggregated data, show me where that's wrong :-)
<cjwatson> ogra_: data > single anecdotes
<ogra_> indeed
<cjwatson> (I may have made a mistake, I just don't see it)
<ogra_> is that data for image/rootfs builds ? or just a general aggregation ?
<cjwatson> tgm4883: once it's expired off cdimage, it's gone unless somebody happens to have mirrored it
<cjwatson> ogra_: livefs build times
<ogra_> ok
<cjwatson> ogra_: the script is there, you can see the methodology for yourself
<ogra_> yeah (only looked at the pngs yet)
<tgm4883> cjwatson: that's what I figured :/  Trying to figure out why our installs are hanging on mysql now but everything looks the same between the two dailies I have (Mar 3rd and Mar 8th)
<cjwatson> requires python-{launchpadlib,matplotlib,pytimeparse}
<tgm4883> err. *everything being the stuff that is either mythbuntu or mysql packaging
<cjwatson> tgm4883: the build logs are kept essentially indefinitely though
<tgm4883> cjwatson: That sounds like something I can dig through. Where do those build logs live?
<cjwatson> tgm4883: http://people.canonical.com/~ubuntu-archive/cd-build-logs/
<cjwatson> there are links from each of those to the livefs build log as well where relevant
<tgm4883> cjwatson: cool thanks
<cjwatson> ogra_: of course, if you're systematically cancelling "slow" builds, then that will have skewed the data in ways I can't do much about.  but at any rate, the main trend line of successful builds on scalingstack is faster than any of the successful builds on metal
<ogra_> cjwatson, i havent canceled one in 6 months or so ...
<ogra_> last time i did that there was still a 5min timeout in place too
<ogra_> (which often enough is longer than waiting for the build to fail if i know it will fail, so i just let it run usually)
<cjwatson> There's no five-minute timeout relevant to cancellation.  The only thing I can think of that you might be talking about is a three-minute timeout given to the builder to finish cancelling for itself before buildd-manager gives up on it.  That only applies if the builder somehow fails to terminate when told to, which would indicate that it's stuck at quite a low level.
<cjwatson> In general cancellation goes around sending kill -9 to everything in the chroot, and a timeout would only be hit if that is not successful at killing everything.
<ogra_> weird, i remember you telling me that there would be a delay ... though that was probably about ctrl-C'ing the job on nusakan
<cjwatson> I think you're talking about something utterly different.
<ogra_> (it was in the context of arm64 build failures not vanishing from the LP page)
<cjwatson> The above has been the case since I implemented proper cancellation support in launchpad-buildd in 2013.
<ogra_> (which has since long been fixed)
<cjwatson> ogra_: That sounds like you're perhaps referring to bug 1424672, but that wasn't about a delay.
<ubot5> bug 1424672 in Launchpad itself "LiveFS builds cancelled before they start sort above other builds in history" [Low,Fix released] https://launchpad.net/bugs/1424672
<ogra_> well, if there is no delay then all is fine i guess :)
<ogra_> i doubt it is worth doing forensics for my sieve memory :)
<ogra_> yeah, it was in that context
<cjwatson> If you SIGINT the job on nusakan, then there will be a delay before everything gets cleaned up, but it's not a fixed timeout; it's simply that nothing arranges to stop the LP build, so it will run to completion unless separately cancelled.
<cjwatson> I find it worth explaining how things work rather than people learning myths from IRC logs :-)
<ogra_> heh, indeed
<ogra_> but yeah, i think it was about the nusakan side ...
<cjwatson> I might know what you mean.  After a job finishes, cdimage waits for up to five minutes for Launchpad to fetch the build log from the builder.  If the builder has died sufficiently hard then fetching the build log might fail and in that case we would hit that timeout before cdimage gives up on the build.  However, that won't be the case in a normal case of cancellation.
<cjwatson> A normal cancel still fetches the build log and cdimage will notice the next time it polls, which it does every 15 seconds.
<ogra_> depends what you call "normal" ... but yeah, back then i couldnt look at the logs immediately due to the arm64 builds eating up the LP page and the mirror only running via cron
<cjwatson> Which mirror are you talking about now?
<cjwatson> Perhaps you mean cd-build-logs, which is only mirrored hourly.
<ogra_> livefs build logs to people.c.c
<ogra_> right
<cjwatson> Actually, no, every 15 minutes, not hourly.
<ogra_> i resorted back then to look on nusakan directly
<cjwatson> We no longer mirror livefs build logs, and they never lived on nusakan in any case.
<ogra_> but in that context the 5min thing kept sticking in my head :)
<cjwatson> Also, even back then you could have got at the logs via the API :-)
<ogra_> yeah
<cjwatson> knome: done, belatedly
<knome> cjwatson, thanks!
<wxl> infinity: do you think lubuntu could get a separate lxqt image for y-cycle?
<xnox> stgraber, ^
#ubuntu-release 2016-03-10
<knome> hello! we need an upload for ubiquity-slideshow-ubuntu; i've just pushed xubuntu slides for 16.04 and bumped version numbers on all slideshows up to 16.04 as well as updated translation templates for everybody
 * flexiondotorg agrees with knome. 
<rbasak> docker.io is broken on powerpc, so isn't migrating. Would it be acceptable to delete that binary please, so that everything else migrates?
<rbasak> We're not aware that anyone cares, and having Docker 1.6 instead of 1.10 in the release pocket is worse we think.
 * flexiondotorg wonders if infinity is still sunning himself on some jolly? ;-)
<apw> flexiondotorg, i think it is night for him at the current time
<flexiondotorg> :-)
<flexiondotorg> Sun bed?
<cyphermox> chiluk: ^
<knome> cyphermox, would you be willing to take care of the ubiquity-slideshow-ubuntu upload or was that a ping re: that? :)
<cyphermox> sure I can upload ubiquity-slideshow-ubuntu
<cyphermox> chiluk wanted me to sponsor a coreutils SRU earlier
<knome> cyphermox, right'o, and thanks :)
<cyphermox> is it already all in the code branch?
<knome> yes, the things i mentioned are ready in the branch
<knome> i don't know if other flavors have something incoming today
<knome> cyphermox, https://launchpad.net/ubiquity-slideshow-ubuntu
<knome> cyphermox, the updates are revisions 724-726 in trunk
<knome> hmm, looks like there are some merge requests
<knome> i can merge those so you only have to take care of the uploading
<knome> give me 15 mins :)
<flexiondotorg> cyphermox, Please https://code.launchpad.net/~ubuntu-mate-dev/ubiquity-slideshow-ubuntu/ubiquity-slideshow-ubuntu-mate-xenial/+merge/282117
<knome> flexiondotorg, i'm on it
<flexiondotorg> knome, ty
<cyphermox> ahah, so I approved it but didn't merge?
<flexiondotorg> Yeah :-)
<knome> cyphermox, hold it! :)
<knome> cyphermox, i'll take care of the merge in a second
<cyphermox> knome: I know, I know ;)
<knome> also merging the gnome stuff
<cyphermox> cool
<knome> ...which seems to be invalid markup, so i'll go fix that next...
<cyphermox> ah
<knome> ok, merged mate and gnome stuff, updated translation templates again as well as updated the changelog
<flexiondotorg> knome, Many thanks!
<knome> no problem
<knome> good that i remembered to check that and you were around...
<knome> if you need stuff merged to the slideshow branch in the future, feel free to poke me
<cyphermox> knome: flexiondotorg: test build and then I'll upload
<knome> :)
<knome> so since it's the UIF day and i didn't get any response on #ubuntu-devel...
<knome> could somebody look at bug 1555046 and get the package uploaded? the shimmer-themes package is snatched from us by some packageset magic to kubuntu, so we can't do the upload ourself
<ubot5> bug 1555046 in shimmer-themes (Ubuntu) "Please upload shimmer-themes-2.1.1-0ubuntu1 to xenial" [Undecided,Confirmed] https://launchpad.net/bugs/1555046
<knome> thanks!
<coreycb> hello, can an archive admin please promote python3-positional to main?  python-positional should already be in main.  this will help get some OpenStack packages out of dependency waits.
<chiluk> cyphermox.. yeah arges uploaded it yesterday, but its sitting in unapproved.  Looks like you might have just re-uploaded it again.
<chiluk> cyphermox you don't happen to be on the SRU team are you?
<cyphermox> no, but arges is
<chiluk> oh I thought you were on the SRU team. bugger..
<arges> cyphermox: well i uploaded it... so i should have another SRU person review
<knome> cyphermox, since you seem to be in a helpful mood, maybe you could look at my request above O:)
<cyphermox> right
<chiluk> I guess I can get arges to cancel his upload and accept yours
<chiluk> since he's already done the review.
<chiluk> arges what do you say?
<arges> oh it was uploaded again.. did i forget to unsubscribe sponsors?
<cyphermox> arges: yeah, it was still in the list
<arges> sorry about that
<cyphermox> no worries... as for me I should have checked the queue to be sure before uploading
<arges> ok rejected mine, i'm happy to sru review your upload then
<chiluk> cool.. yay arges.. the bane of my existence may finally be complete!
<chiluk> until we find the next regression I've introduced.
<knome> upload an empty package, less potential for regressions.
<knome> ;)=
<cyphermox> knome: only if it was empty before that too ;)
<chiluk> knome: if only that would make users happy.
<knome> cyphermox, it's a feature, not a bug...
<arges> and it doesn't rebuild with different deps that could cause bugs
<cyphermox> knome: uploaded ubiquity-slideshow-ubuntu
<knome> great!
<coreycb> can an archive admin also promote python3-sphinx-argparse to main?  the MIR is Fix Released.  this will also help get some OpenStack packages out of dependency waits.
<knome> now we're only missing one of the last-minute uploads ;)
<yofel> a big thanks to whoever did all the new processing!
#ubuntu-release 2016-03-11
<jamespage> if there are any release team members around I'd love to get https://bugs.launchpad.net/ubuntu/+source/python-django-compressor/+bug/1554134 reviewed today if possible
<ubot5> Launchpad bug 1554134 in python-django-compressor (Ubuntu) "[FFe] python-django-compressor 2.0" [High,New]
<jamespage> new main dependencies all reviewed by the MIR team
<jamespage> so just pending a release team +1.. thanks!
<infinity> jamespage: +1
<jamespage> infinity, ta
<infinity> jamespage: Close the bug in the upload, SVP.
<jamespage> infinity, will do
<infinity> jamespage: I've lost track this cycle.  How do we align for Openstack this time 'round?  Will be have final before release?
<jamespage> infinity, two weeks before :-)
<infinity> jamespage: \o/
<jamespage> which is awesome
<infinity> jamespage: If anything OS-related gets stuck on process, be sure to escalate.  It would be novel to get it all landed and well-tested before release for once.
<jamespage> infinity, will do and I agree it will be nice
<rbasak> infinity: while you're here, bug 1528583 is ready, but later than expected. Please you you re-review and re-ack the FFe? Oracle have done some extensive testing on my request, as I said that would help with the later FFe. They've written it up at http://paste.ubuntu.com/15346508/. We haven't transferred to the bug yet, and I was going to ask more about conclusion point 2 as I think we have a mitigat
<ubot5> bug 1528583 in mysql-5.6 (Ubuntu) "[FFe] Please update to MySQL 5.7 series" [Wishlist,In progress] https://launchpad.net/bugs/1528583
<rbasak> ion path if that doesn't work. But I thought I'd ask you now as you're online?
<rbasak> I also plan to do one more change, which is to move a bunch of binaries from server to server-core and client to client-core, which is their intended place. But I need to check for clash with MariaDB first.
<rbasak> Since server depends on server-core, as long as I get the B/R right it shouldn't invalidate any of the testing.
<coreycb> infinity, hi, can we get python(3)-positional promoted to main?   the MIR bug 1552384 has been approved
<ubot5> bug 1552384 in python-positional (Ubuntu) "[MIR] python-positional" [Undecided,Fix released] https://launchpad.net/bugs/1552384
<flexiondotorg> infinity, Where in the world are you today? :-)
<tjaalton> can someone poke x11-xserver-utils out of proposed? it's been a valid candidate for two weeks
<rbasak> tjaalton: doing so would make arandr uninstallable: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<rbasak> That's why it's held.
<tjaalton> rbasak: yeah..
<tjaalton> I'll check
<tjaalton> debian
<tjaalton> arandr synced
<infinity> coreycb: Done.
<coreycb> infinity, thanks
<infinity> flexiondotorg: Still in Bangkok.  Beijing tomorrow, and Calgary half a day after that.
<ogra_> infinity, can we look deeper into fakechroot next week (once you are out of your jetlag) ... i'm a bit stuck with that one
<infinity> ogra_: Yup.
<ogra_> thx :)
<flexiondotorg> infinity, Is there anything more I can do to help progress "Base"?
<infinity> flexiondotorg: Not unless you feel the urge to read my mind and make the changes I'll suggest (or JFDI) after I'm done reviewing.
<apw> (or perhaps create some extra hours in the day, that always helps)
<infinity> I'm about to go back in time, that might help a bit.
 * flexiondotorg focuses on infinity's mind
 * flexiondotorg can't get a lock, infinity is too far away.
<flexiondotorg> infinity, I tried.
<ogra_> but he is going back in time, so he can fix it last week !
<infinity> ogra_: Sadly, the plane's not that fast.
<ogra_> damn
<Trevinho> Laney: hey... So, can we get the go for https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1552630?
<ubot5> Launchpad bug 1552630 in unity (Ubuntu) "[FFe] Add support for launcher at the bottom" [Medium,New]
<Laney> Don't know, didn't look yet I'm afraid
<Laney> Someone else might have though
<Trevinho> Ok..
<Laney> I'm not extremely keen in general though - Unity doesn't have the best record on FFes
<Trevinho> It would be nice to get it on it... You know that community really pushed for that
<Trevinho> Laney: well, that is really not affecting normal usage... Most of changes are only applying on if (launcher_position == BOTTOM)... Thus, old code is not touched
<Laney> What's normal usage?
<Laney> You add a new configuration option and now it is part of the code and so you get to support it
<Trevinho> But even the new one is quite stable and there for some weeks... It has been delayed only because of other causes...
<Trevinho> Yeah, indeed we support it.
<Trevinho> And we get support also from kylin comunity
<Trevinho> It's just that it's not regression prone
<Laney> It'll be you that ends up fixing it when bugs are found in release week
<Laney> When omgubuntu publishes an article about it and lots of people decide to try it out
<Laney> Probably do a pass of the outstanding FFes on Monday morning
<infinity> Trevinho: Can I make accepting that FFe conditional on someone investigating and fixing https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1521302 ?
<ubot5> Launchpad bug 1521302 in unity (Ubuntu Xenial) "gnome-terminal maximize than un-maximize behaves odd" [Medium,Confirmed]
<infinity> Trevinho: Cause holy crap that irks me. :P
<Trevinho> infinity: ok.. It can be a good deal
<coreycb> infinity, could we also get python(3)-sphinx-argparse promoted to main for openstack?  it's MIR is approved in bug 1551311
<ubot5> bug 1551311 in sphinx-argparse (Ubuntu) "[MIR] python-sphinx-argparse" [Undecided,Fix released] https://launchpad.net/bugs/1551311
<infinity> coreycb: Done.
<coreycb> infinity, thanks
<cyphermox> anyone could review libcxl in the xenial NEW queue?
#ubuntu-release 2016-03-13
<michi> robru: I just replied to your MR. It was just a few silly typos.
<doko> texlive-extra (2015.20160215-1 to 2015.20160223-2)
<doko> texlive-htmlxml/amd64 unsatisfiable Depends: tex4ht (>= 20051214)
<doko> however tex4ht is 20090611-1.1build1. what am I missing?
<infinity> doko: Possibly fixed.  Will see after a publisher run or two.
<yofel> could someone please add an ignore hint for http://autopkgtest.ubuntu.com/packages/p/plasma-framework/xenial/s390x/
<yofel> that's building for the wrong version for whatever reason and is holding packages in proposed
<infinity> yofel: "building for the wrong version"?
<yofel> infinity: it keeps building the tests for 5.15, how do I get it to build 5.18 - or am I misunderstanding how this works?
<infinity> yofel: Ahh, I can fix that.
<infinity> Looks like someone attempted to fix it two days ago.
<infinity> But there were more uploads since.  I see.
#ubuntu-release 2017-03-06
-queuebot:#ubuntu-release- New: accepted libbluray [amd64] (zesty-proposed) [1:1.0.0-2]
-queuebot:#ubuntu-release- New: accepted libbluray [armhf] (zesty-proposed) [1:1.0.0-2]
-queuebot:#ubuntu-release- New: accepted libbluray [powerpc] (zesty-proposed) [1:1.0.0-2]
-queuebot:#ubuntu-release- New: accepted libbluray [s390x] (zesty-proposed) [1:1.0.0-2]
-queuebot:#ubuntu-release- New: accepted libbluray [arm64] (zesty-proposed) [1:1.0.0-2]
-queuebot:#ubuntu-release- New: accepted libbluray [ppc64el] (zesty-proposed) [1:1.0.0-2]
-queuebot:#ubuntu-release- New: accepted libbluray [i386] (zesty-proposed) [1:1.0.0-2]
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (xenial-proposed/main) [0.90ubuntu0.3 => 0.90ubuntu0.4] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (yakkety-proposed/main) [0.92ubuntu1.2 => 0.92ubuntu1.3] (desktop-core, ubuntu-server)
<Laney> soooooooooooo
<Laney> thoughts on uploading a huge packaging overhaul for glib2.0 to zesty? https://ftp-master.debian.org/new/glib2.0_2.51.4-1.html
<apw> Laney, uggg, i guess it is at least a bit verifyable, could we throw that source in a PPA ?
<Laney> yeh
<apw> Laney, that page is rather nice
<Laney> apw: you mean debian's NEW output?
<apw> Laney, yeah
<Laney> nod
 * Laney gets a silo to have a handy devirt ppa
<Laney> is devirt a thing any more?
<Laney> I mean 'restricted arches' I think :)
<xnox> Laney, one needs devirt for power and s390x i think
<Laney> xnox: I just mean that 'devirt' isn't the right term, since there's no 'virt' any more
<cjwatson> uh
<apw> Laney, i don't think devirt is really a thing.  yes power and s390x are non-virtualised
<apw> but from a PPA point of view you just find it hard to turn them on
<cjwatson> devirt is a thing, but it's only relevant for the arches that don't have virt
 * xnox likes cdbs -> dh
<cjwatson> we don't at present have arches with both virt and non-virt builders
<Laney> right
<cjwatson> but one of the knobs you need to get powerpc and s390x builds is to disable "Require virtualized builders"
<apw> cjwatson, so i can in theory flip a PPA from "virt amd64" to "de-virt amd64" ?
<cjwatson> apw: I doubt you can, but one can; however it does nothing
<apw> cjwatson, i stand corrected :)
<cjwatson> the technical effect of devirt (i.e. disabling "Require virtualized builders") is that builds can be dispatched to either virt or non-virt builders, rather than just virt builders
<cjwatson> this obviously does nothing if there are no non-virt builders :)
<apw> shows how the UI can misslead you :)  given we now only have "on/off" for every arch
<cjwatson> but a PPA with powerpc and s390x enabled won't have anywhere to dispatch builds to unless "Require virtualized builders" is also disabled
<apw> (we == not you :)
<cjwatson> well, the powerpc and s390x checkboxes are greyed out if you don't have access to enable them, too
<apw> right indeed, which is how we've fallen into calling them "restricted arches"
<apw> (incorrectly)
<cjwatson> no, that's correct too
<cjwatson> slightly different from "requires devirt" mind
<cjwatson> it's possible for an architecture to have only virt builders but still be restricted (which we do if we're not yet confident enough in how well it will behave at scale)
<cjwatson> that was the case for arm64 and armhf for a while I believe
<cjwatson> it does confuse webops from time to time though - they frequently get asked to enable s390x or whatever, flip the arch switch, and forget / don't know that they need to devirt as well
<Laney> apw: xnox: building https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2537/+packages
<apw> Laney, in theory we now have that i386 linux regression test disabled correctly, so i am going to un-blacklist it
<Laney> apw: have you done a test run? :-)
<Laney> not required, but if not then please keep an eye on the first real one
<apw> Laney, i have not, will do
<jbicha> good morning, could the chrome-gnome-shell/trusty, ubuntu-gnome-meta/trusty SRUs be reviewed today?
-queuebot:#ubuntu-release- Unapproved: accepted chrome-gnome-shell [source] (trusty-proposed) [8-2ubuntu4~ubuntu14.04.2]
<jbicha> thanks!
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-meta [source] (trusty-proposed) [0.32.1]
<apw> jbicha, ^
-queuebot:#ubuntu-release- Unapproved: accepted cifs-utils [source] (yakkety-proposed) [2:6.5-2ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted cifs-utils [source] (xenial-proposed) [2:6.4-1ubuntu1.1]
<jbicha> rbasak: so if the final decision is not to accept bug 1337898 into trusty-updates, how does that work? is the update deleted from trusty-proposed or does it stay there indefinitely?
<ubot5> bug 1337898 in giflib (Ubuntu Trusty) "Invalid symlinks for libungif.so and libungif.a" [Low,Fix committed] https://launchpad.net/bugs/1337898
<rbasak> jbicha: we'll mark it verification-failed, and an AA will delete it from trusty-proposed eventually.
<apw> if nothing else is done it will get deleted at 105 days
<apw> if we know it is definatly going to be rejected, then a heads up here seems reasonable if you need an AA for that
<jbicha> I'm asking because I think the tracker/yakkety SRU just has too much regression risk
<apw> risk makes us nurvous
<jbicha> the tracker update is in stretch and zesty and it's a "security" update but I think the sandbox still blocks and breaks some things that worked before
<jbicha> given yakkety's short life, it doesn't seem worth the trouble there
<jbicha> apw: since you're an AA, do you want to remove tracker from yakkety-proposed now?
<apw> jbicha, if you are never going to fix the regression that that had, sure
<apw> jbicha, gone
<acheronuk> apw: now a calligra KF5 version with localisation in the main source is through, could the old defunct localisation binaries and their source be removed from zesty please?
<acheronuk> http://packages.ubuntu.com/source/zesty/calligra-l10n
<acheronuk> can do a bug if required
<apw> acheronuk, is there a removal request filed for that with the details ?
<acheronuk> I will make one :)
-queuebot:#ubuntu-release- Unapproved: qemu (xenial-proposed/main) [1:2.5+dfsg-5ubuntu10.9 => 1:2.5+dfsg-5ubuntu10.10] (ubuntu-server, virt) (sync)
<powersj> slangasek: infinity: do either of you know if the ppc64el server ISO tests ever got enabled to block release on failure like amd64/i386?
-queuebot:#ubuntu-release- New source: ukui-session-manager (zesty-proposed/primary) [1.0.0]
<acheronuk> apw: if you are still about: https://bugs.launchpad.net/ubuntu/+source/calligra-l10n/+bug/1670426
<ubot5> Ubuntu bug 1670426 in calligra-l10n (Ubuntu) "Please remove calligra-l10n from zesty" [Undecided,New]
-queuebot:#ubuntu-release- Unapproved: rejected neutron [source] (yakkety-proposed) [2:9.2.0-0ubuntu1]
<rbasak> coreycb: ^
<coreycb> rbasak, thanks
<apw> acheronuk, it seems some of that is still seeded in "kbuntu: supported"
<apw> acheronuk, so i think your images will implode if i remove it
<acheronuk> apw: that probably needs to come off then
<acheronuk> apw: no, nothing calligra at all goes on our iso
<apw> acheronuk, seeded-in-ubuntu say it is in your supported seed.
<apw> whatever you use that for
<acheronuk> apw: that supported seed it not what goes on our iso. the desktop one is
<apw> acheronuk, right i am not communicating clearly.  can you check your seeds do not need these removing
<apw> before i rip them out of the archive
<acheronuk> apw: it only exists in our supported seed - where it can be removed from once it no longer exists in the archive
<apw> acheronuk, ack thanks
<acheronuk> or before. won't break anything wither way
<apw> acheronuk, done
<acheronuk> apw: thx :)
-queuebot:#ubuntu-release- Unapproved: neutron (yakkety-proposed/main) [2:9.1.1-0ubuntu1 => 2:9.2.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.9-0ubuntu1~16.04.2 => 0.7.9-48-g1c795b9-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (yakkety-proposed/main) [0.7.9-0ubuntu1~16.10.1 => 0.7.9-48-g1c795b9-0ubuntu1~16.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: software-properties (xenial-proposed/main) [0.96.20.5 => 0.96.20.6] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: software-properties (yakkety-proposed/main) [0.96.24.7 => 0.96.24.7.1] (desktop-core, ubuntu-server)
#ubuntu-release 2017-03-07
-queuebot:#ubuntu-release- New binary: graphene [amd64] (zesty-proposed/universe) [1.6.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: graphene [ppc64el] (zesty-proposed/universe) [1.6.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: graphene [i386] (zesty-proposed/universe) [1.6.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: graphene [s390x] (zesty-proposed/universe) [1.6.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: graphene [powerpc] (zesty-proposed/universe) [1.6.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: graphene [arm64] (zesty-proposed/universe) [1.6.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: graphene [armhf] (zesty-proposed/universe) [1.6.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cgroup-lite (precise-proposed/main) [1.1.5 => 1.1.6] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cgroup-lite (trusty-backports/main) [1.11~ubuntu14.04.2 => 1.11~ubuntu14.04.3] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cgroup-lite (trusty-backports/main) [1.11~ubuntu14.04.2 => 1.11~ubuntu14.04.3] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cgroup-lite (xenial-proposed/universe) [1.11 => 1.11ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cgroup-lite (yakkety-updates/universe) [1.11 => 1.11ubuntu0.16.10.1] (no packageset)
-queuebot:#ubuntu-release- New sync: pagein (zesty-proposed/primary) [0.00.03-1]
<ginggs> would someone take care of a couple of removals please? LP: #1653238 please let me know if i need to add more info to the bug
<ubot5> Launchpad bug 1653238 in pbseqlib (Ubuntu) "Please remove binaries no longer built from source" [Undecided,New] https://launchpad.net/bugs/1653238
<ginggs> and LP: #1636259
<ubot5> Launchpad bug 1636259 in fftw3-mpi (Ubuntu) "Please remove fftw3-mpi" [Undecided,New] https://launchpad.net/bugs/1636259
<tjaalton> I don't understand this entry in update_output.txt:
<tjaalton> trying: mesa
<tjaalton> skipped: mesa (8, 35, 1)
<tjaalton>     got: 51+0: a-19:a-4:a-4:i-7:p-3:s-14
<tjaalton>     * amd64: libopentk-cil-dev, libopentk1.1-cil
<tjaalton> hm actually, looks like libopentk1.1-cil depends on $world
<tjaalton> and needs fixing
-queuebot:#ubuntu-release- New binary: graphene [i386] (zesty-proposed/universe) [1.6.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: graphene [ppc64el] (zesty-proposed/universe) [1.6.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: graphene [amd64] (zesty-proposed/universe) [1.6.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: graphene [arm64] (zesty-proposed/universe) [1.6.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: graphene [s390x] (zesty-proposed/universe) [1.6.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: graphene [armhf] (zesty-proposed/universe) [1.6.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: graphene [powerpc] (zesty-proposed/universe) [1.6.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New source: retro-gtk (zesty-proposed/primary) [0.9.91-0ubuntu1]
-queuebot:#ubuntu-release- New source: gnome-games-app (zesty-proposed/primary) [3.23.91-0ubuntu1]
<jbicha> you can reject the older retro-gtk, gnome-games-app; I had to rename retro-gtk's -dev package
<zul> can someone please reject horizon 10.0.2 sitting in yakkety-proposed
-queuebot:#ubuntu-release- Unapproved: rejected horizon [source] (yakkety-proposed) [3:10.0.2-0ubuntu1]
<rbasak> zul: ^
<zul> rbasak: yes
<rbasak> zul: just letting you know it's done (and others so they don't duplicate effort looking at the queue)
<zul> thalkns
-queuebot:#ubuntu-release- Unapproved: fglrx-installer (trusty-proposed/restricted) [2:15.201-0ubuntu0.14.04.3 => 2:15.201.1-0ubuntu0.14.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: fglrx-installer-updates (trusty-proposed/restricted) [2:15.201-0ubuntu0.14.04.3 => 2:15.201.1-0ubuntu0.14.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted graphene [amd64] (zesty-proposed) [1.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted graphene [armhf] (zesty-proposed) [1.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted graphene [powerpc] (zesty-proposed) [1.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted graphene [s390x] (zesty-proposed) [1.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted graphene [arm64] (zesty-proposed) [1.6.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted graphene [i386] (zesty-proposed) [1.6.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted graphene [ppc64el] (zesty-proposed) [1.6.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted pagein [sync] (zesty-proposed) [0.00.03-1]
-queuebot:#ubuntu-release- New: accepted graphene [arm64] (zesty-proposed) [1.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted graphene [ppc64el] (zesty-proposed) [1.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted graphene [armhf] (zesty-proposed) [1.6.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted graphene [s390x] (zesty-proposed) [1.6.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted graphene [i386] (zesty-proposed) [1.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted graphene [powerpc] (zesty-proposed) [1.6.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted graphene [amd64] (zesty-proposed) [1.6.0-0ubuntu2]
-queuebot:#ubuntu-release- New: rejected retro-gtk [source] (zesty-proposed) [0.9.91-0ubuntu1]
-queuebot:#ubuntu-release- New binary: pagein [ppc64el] (zesty-proposed/none) [0.00.03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pagein [amd64] (zesty-proposed/universe) [0.00.03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pagein [armhf] (zesty-proposed/universe) [0.00.03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pagein [s390x] (zesty-proposed/universe) [0.00.03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pagein [arm64] (zesty-proposed/universe) [0.00.03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pagein [i386] (zesty-proposed/universe) [0.00.03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pagein [powerpc] (zesty-proposed/universe) [0.00.03-1] (no packageset)
<jamespage> mdeslaur, rbasak: re bug 1668934
<ubot5> bug 1668934 in percona-xtradb-cluster-5.6 (Ubuntu Yakkety) "percona-xtradb-cluster-5.6 5.6.34-26.19, percona-galera-3 3.19, percona-xtrabackup 2.3.7" [High,Triaged] https://launchpad.net/bugs/1668934
<jamespage> zesty uploads acked by release team and completed; xenial and yakkety updates staged in PPA referenced in bug report
<jamespage> a slight horrifying number of CVE's closed out
<mdeslaur> jamespage: ack, thanks, whoever is on community will look at it
<jamespage> I've upgrade tested all three sets of updates
<jamespage> mdeslaur: awesome - thanks!
<rtg> xnox, infinity - I just removed the block-proposed tag from linux 4.10.0-11.13. Please update d-i accordingly.
<rbasak> jamespage: thanks!
-queuebot:#ubuntu-release- Unapproved: sssd (xenial-proposed/main) [1.13.4-1ubuntu1.2 => 1.13.4-1ubuntu1.3] (kubuntu, ubuntu-desktop, ubuntu-server)
<infinity> rtg: And I added it back.  Can you please not remove it until the testing matrix is actually clear?
<rtg> the ADT matrix ?
<infinity> Yes.
<infinity> The one with a bunch of new red and some yellow.
<infinity> (I just retried all of those for you)
<rtg> infinity, the only test failure that ought to have held up promotion is lxd. Seth couldn't repro it, so we decided it must be environmental.
<infinity> rtg: And tests that hadn't run, you decided didn't matter?
<rtg> I thought everything _had_ run at least once
<infinity> That's not what yellow "MISS" blocks mean.
<infinity> But the lxd thing does look like it needs deeper investigation than "oh, it must be the test setup's fault".
-queuebot:#ubuntu-release- Unapproved: sssd (yakkety-proposed/main) [1.13.4-3ubuntu0.1 => 1.13.4-3ubuntu0.2] (kubuntu, ubuntu-desktop, ubuntu-server)
<infinity> Because that conclusion (if correct) means the test/infra needs fixing.  If incorrect, you have a kernel regression.  Neither one of those means we need to rush to ignore the test.
<rtg> If I waited until the test matrix was perfect I'd never get a kernel promoted.
<infinity> If you know the tests are broken, discuss it with the people responsible for the tests.  If you know the kernel is broken, it shouldn't promote.  If you ignore both of those, the testins is useless, and the kernel is in an unknown state.
<rtg> infinity, Seth did talk to stgraber about the lxd failures, and they are being addressed.
<infinity> stgraber: ^
<infinity> rtg: That's exactly not what you said the first time.
<rtg> infinity, you are correct, that was a bit misleading.
<rtg> environmental in the sense that there was a missing dependency
<infinity> rtg: Anyhow, while the lxd one is the most obviously concerning, the point still stands that the tests were not all complete/passed.  I've retried the lot to see how it settles.
<infinity> sforshee: Hey Freshest.
<stgraber> infinity: somehow lvm2 is now being pulled into the autopkgtest images, this is triggering some extra tests on LXD's side which are failing due to missing thin-provisioning-tools. The next LXD upload (2.11 tonight) will have some more test dependencies to account for that new behavior.
<sforshee> infinity: :-P
<infinity> sforshee: That's cool.  Tim's first mention of this was slightly more "we decided it wasn't our fault, so meh" with a bit less actual investigation and proposed solution.   Sorry you had to come translate from Cowboy.
<sforshee> infinity: no problem, looks like I showed up just in time for stgraber to explain
<infinity> Err.  Yes, I should have directed that to stgraber. ;)
<infinity> Same length nick, same first letter, and his message was right after you joined.
<infinity> CONFUSING.
<apw> and completion order changes with who talked last (at least for me)
<infinity> stgraber: lvm2 being pulled in seems weird.  OTOH, if you have tests that weren't being run because of missing deps, depending on all of them so all the tests run sounds A+ to me.
<infinity> apw: For me, it's who I talked to last.
<stgraber> infinity: yeah, no idea why lvm2 is now part of the autopkgtest image, but indeed makes sense for us to test everything so the next upload will be depending on btrfs, lvm2+thin-provisioning-tools and zfs
<apw> which sounds a lot more useful
<apw> infinity, rtg, we are red across the board on zfs on that kernel, though that is likely the dracult *cough* issue.  cking is hand verifying it now.
<Laney> Hmm
<infinity> stgraber: Anyhow, thanks for the investigation and pending fix, please come back to Foundations, etc.
<Laney> why do those MISS results have links to logs that apparently have the right trigger?
<infinity> apw: dracut doesn't have an L in it, though I kinda like yours better. ;)
<apw> it sounds more transylvanian ...
<infinity> Laney: Because I retried everything 20m ago and the page needs to refresh?  Or do you mean old logs?
<Laney> infinity: No, the page right now has MISS results which link to logs
<Laney> Like dpdk
<infinity> Laney: Which log (other than the top, which is the just now retry) looks like it's the right triggers?
<infinity> Well, right according to what Andy's page thinks is right, which might be wrong.
<infinity> (it seems to want the version in proposed, if there is one)
<Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/d/dpdk/20170303_070758_a6b0f@/log.gz
<Laney> There's a new dpdk in zesty since then though
<Laney> So it could be that
<infinity> Yeah, his page insists on results against latest versions.
<Laney> There's a tooltip that could be that
<infinity> So, something goes from GOOD to MISS if a new version is uploaded before migration.
<Laney> Number of failed tests: 39
<Laney> OK
<Laney> A+ would test again
<infinity> Early eBay has forever ruined a generation.
<infinity> I use eBay feedback comments with kids half my age and they look at me like I'm on crack.
<cking> apw, zfs testing on s390x, x86-64, aarch64 passed smoke tests and posix fs tests, just waiting for the looong running tests to complete,but it looks sane to me (as much as it ever has)
<infinity> \o/
<cking> (against the -proposed kernel btw)
<apw> cking, ack thank you!
<cking> i'll see how the full xfs test suite works out on it - that takes a good 30-40 mins, then I run the insane stress tests to see if anything explodes
<infinity> cking: Heh, insane stress tests should probbaly be done regularly on all kernels, but not sure that would fit in adt.
<cking> infinity, i believe the kt tests do run stress-ng on all our kernels
<jbicha> hi, graphene has no rdepends, I renamed the -dev package and it looks like the missing libgraphene-dev is keeping graphene from migrating out of zesty-proposed
<infinity> jbicha: Looks like NBS in proposed.  Will fix.
<infinity> jbicha: Done.
<jbicha> thank you
<jbicha> I don't like having the version number in the -dev package name for packages like this but that's what the Debian package will do so might as well fix it now
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-41.44] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-112.159] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (vivid-proposed/main) [3.19.0-83.91] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-41.44]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-112.159]
-queuebot:#ubuntu-release- New binary: linux-signed-lts-trusty [amd64] (precise-proposed/main) [3.13.0-112.159~precise1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-66.87] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (vivid-proposed) [3.19.0-83.91]
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-66.87~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-trusty [amd64] (precise-proposed) [3.13.0-112.159~precise1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-66.87]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-66.87~14.04.1]
<cking> apw, all the zfs tests run fine on s390x, just waiting for the slower arches to eventually catch up. no explosions with the stress-ng on zfs tests
<cpaelzer> Laney: the dpdk autotests are enabled not as blocker for a reason
<cpaelzer> Laney: they are more often failing than not, we fix up every upload a bit
<cpaelzer> Laney: but they keep breaking
<cpaelzer> Laney: we added them to be executed mainly to get the logs
<cpaelzer> Laney: the other tests are better and active to block on fail
<cpaelzer> Laney: and then we execute the autotests outside of dep8 tests as well (together with many others)
<cpaelzer> Laney: atm for example in the log you posted I get all but one working just fine
<cpaelzer> dpdk (and that is a common pattern) just need to stabilize/mature a bit ore on that
<cpaelzer> Laney: thanks for linking that here - I didn't know what the reason to post was (didn't read all backlog) but I'll add to my tasks to look at them again
<cpaelzer> Laney: most likely lack of sufficient hugepages allocation in LP test infra
<cpaelzer> (that it was in the past)
<smoser> slangasek, i'm well aware that you're busy. but if you could sru review the cloud-init in the queue....
<slangasek> smoser: did you already check with the SRU team member on duty today? https://wiki.ubuntu.com/StableReleaseUpdates#Publishing  If RAOF can't get to it I can take a look yes
<smoser> i did not, sorry to mis-ping.
<smoser> RAOF, ?
<slangasek> (might still be a little early for him)
<smoser> slangasek, thanks
-queuebot:#ubuntu-release- Unapproved: rejected apparmor [source] (trusty-proposed) [2.10.95-0ubuntu2.5~14.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [0.7.9-48-g1c795b9-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (yakkety-proposed) [0.7.9-48-g1c795b9-0ubuntu1~16.10.1]
#ubuntu-release 2017-03-08
-queuebot:#ubuntu-release- New sync: gnome-dvb-daemon (zesty-proposed/primary) [1:0.2.91~git20170110-2]
-queuebot:#ubuntu-release- New binary: graywolf [amd64] (zesty-proposed/universe) [0.1.4+20170307gite1bf319-1] (no packageset)
-queuebot:#ubuntu-release- New binary: graywolf [ppc64el] (zesty-proposed/universe) [0.1.4+20170307gite1bf319-1] (no packageset)
-queuebot:#ubuntu-release- New binary: graywolf [i386] (zesty-proposed/universe) [0.1.4+20170307gite1bf319-1] (no packageset)
-queuebot:#ubuntu-release- New binary: graywolf [s390x] (zesty-proposed/universe) [0.1.4+20170307gite1bf319-1] (no packageset)
-queuebot:#ubuntu-release- New binary: graywolf [arm64] (zesty-proposed/universe) [0.1.4+20170307gite1bf319-1] (no packageset)
-queuebot:#ubuntu-release- New binary: graywolf [powerpc] (zesty-proposed/universe) [0.1.4+20170307gite1bf319-1] (no packageset)
-queuebot:#ubuntu-release- New binary: graywolf [armhf] (zesty-proposed/universe) [0.1.4+20170307gite1bf319-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cgroup-lite [source] (precise-proposed) [1.1.6]
-queuebot:#ubuntu-release- Unapproved: accepted cgroup-lite [source] (xenial-proposed) [1.11ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: fwupdate (zesty-proposed/main) [8-3 => 9-1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupdate (zesty-proposed/main) [8-3 => 9-1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupdate (zesty-proposed/main) [8-3 => 9-1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupdate (zesty-proposed/main) [8-3 => 9-1] (core)
-queuebot:#ubuntu-release- Unapproved: signon-ui (xenial-proposed/main) [0.17+16.04.20151125-0ubuntu1 => 0.17+16.04.20170116-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
<ginggs> would an archive admin please take a look at removals in LP: #1653238 and LP: #1636259 ?
<ubot5> Launchpad bug 1653238 in pbseqlib (Ubuntu) "Please remove binaries no longer built from source" [Undecided,New] https://launchpad.net/bugs/1653238
<ubot5> Launchpad bug 1636259 in fftw3-mpi (Ubuntu) "Please remove fftw3-mpi" [Undecided,New] https://launchpad.net/bugs/1636259
<apw> ginggs, normally those show up and get removed automatically
<apw> (NBS binaries)
<ginggs> apw: even if it is only on certain architectures?
<apw> ginggs, oh that likely nt
-queuebot:#ubuntu-release- New: accepted graywolf [amd64] (zesty-proposed) [0.1.4+20170307gite1bf319-1]
-queuebot:#ubuntu-release- New: accepted graywolf [armhf] (zesty-proposed) [0.1.4+20170307gite1bf319-1]
-queuebot:#ubuntu-release- New: accepted graywolf [powerpc] (zesty-proposed) [0.1.4+20170307gite1bf319-1]
-queuebot:#ubuntu-release- New: accepted graywolf [s390x] (zesty-proposed) [0.1.4+20170307gite1bf319-1]
-queuebot:#ubuntu-release- New: accepted pagein [arm64] (zesty-proposed) [0.00.03-1]
-queuebot:#ubuntu-release- New: accepted pagein [i386] (zesty-proposed) [0.00.03-1]
-queuebot:#ubuntu-release- New: accepted pagein [ppc64el] (zesty-proposed) [0.00.03-1]
-queuebot:#ubuntu-release- New: accepted graywolf [arm64] (zesty-proposed) [0.1.4+20170307gite1bf319-1]
-queuebot:#ubuntu-release- New: accepted graywolf [ppc64el] (zesty-proposed) [0.1.4+20170307gite1bf319-1]
-queuebot:#ubuntu-release- New: accepted pagein [armhf] (zesty-proposed) [0.00.03-1]
-queuebot:#ubuntu-release- New: accepted pagein [s390x] (zesty-proposed) [0.00.03-1]
-queuebot:#ubuntu-release- New: accepted graywolf [i386] (zesty-proposed) [0.1.4+20170307gite1bf319-1]
-queuebot:#ubuntu-release- New: accepted pagein [powerpc] (zesty-proposed) [0.00.03-1]
-queuebot:#ubuntu-release- New: accepted pagein [amd64] (zesty-proposed) [0.00.03-1]
<tjaalton> could and archive-admin remove resteasy from zesty, it's bug 1662654 again
<ubot5> bug 1662654 in resteasy (Ubuntu) "Please remove tomcat 8.5 from zesty-proposed" [Undecided,New] https://launchpad.net/bugs/1662654
<tjaalton> *an
<tjaalton> and zesty-proposed of course
-queuebot:#ubuntu-release- Unapproved: tftp-hpa (trusty-proposed/main) [5.2-7ubuntu3 => 5.2-7ubuntu3.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: tftp-hpa (yakkety-proposed/main) [5.2+20150808-1ubuntu1 => 5.2+20150808-1ubuntu1.16.10.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: tftp-hpa (xenial-proposed/main) [5.2+20150808-1ubuntu1 => 5.2+20150808-1ubuntu1.16.04.1] (ubuntu-desktop, ubuntu-server)
<ginggs> thanks apw! pbdagcon,pbalign,blasr,pbseqlib all migrated now
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (xenial-proposed) [0.96.20.6]
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (yakkety-proposed) [0.96.24.7.1]
<jbicha> bdmurray: can we ignore that bug 1660063 might not be completely fixed?
<ubot5> bug 1660063 in chrome-gnome-shell (Ubuntu Xenial) "chrome-gnome-shell crashed with SIGSEGV in ffi_call_unix64()" [Medium,In progress] https://launchpad.net/bugs/1660063
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (xenial-proposed) [0.90ubuntu0.4]
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (yakkety-proposed) [0.92ubuntu1.3]
-queuebot:#ubuntu-release- Unapproved: accepted ktp-text-ui [source] (xenial-proposed) [4:15.12.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (xenial-proposed) [1.2.20]
-queuebot:#ubuntu-release- Unapproved: accepted wget [source] (xenial-proposed) [1.17.1-1ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted simple-image-reducer [source] (xenial-proposed) [1.0.2-3ubuntu0.16.04.1]
<tjaalton> armhf binaries of openmw should be removed, the new version doesn't build and old one is blocking mesa
<apw> tjaalton, "doesn't build" do we know why ?
<tjaalton> apw: it doesn't build on debian either and doesn't seem upstream is too busy fixing it
<apw> tjaalton, i would say file a removal request for that, so we have all the details in one place
<tjaalton> okay
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.23~14.04 => 2.23.1~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.23 => 2.23.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.23+16.10 => 2.23.1+16.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New source: ukui-menu (zesty-proposed/primary) [1.0.0-0ubuntu1]
<tjaalton> apw: bug 1671129
<ubot5> bug 1671129 in openmw (Ubuntu) "remove armhf binaries for openmw to unblock mesa" [Undecided,New] https://launchpad.net/bugs/1671129
 * apw will review those snapd's once they pass testing in yakkety
<jbicha> you can remove ukui-session-manager/zesty 1.0.0, we are reuploading as a regular (non-native) package
<jbicha> and the older gnome-games-app/zesty
<jbicha> from the new queue
-queuebot:#ubuntu-release- New source: ukui-session-manager (zesty-proposed/primary) [1.0.0-0ubuntu1]
<cyphermox> hi, could someone from the release team please review my FFe? https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1670495
<ubot5> Ubuntu bug 1670495 in nplan (Ubuntu) "[FFe] netplan with forward-definition support" [Undecided,New]
<bdmurray> jbicha: looking
<bdmurray> slangasek: Could you fully phase chrome-gnome-shell for yakkety?
<bdmurray> rbasak: I believe the SRU team discussed in Sevilla using Incomplete more as a way of quickly conveying information about the status of an SRU e.g. setting the systemd task to Incomplete in bug 1649931.
<ubot5> bug 1649931 in systemd (Ubuntu Xenial) "systemd-networkd needs to ensure DNS is up before network-online.target" [Medium,Incomplete] https://launchpad.net/bugs/1649931
<bdmurray> rbasak: This way I don't have to scroll all the way through the report to read you comment about the testing being incomplete.
<bdmurray> And also using it for items in the -proposed queue that might be missing a test case or whatever.
<rbasak> bdmurray: sorry. I must have forgotten that. I had noticed you were using it. I'm happy to do that every time I make a comment if that's the consensus?
<rbasak> (if the comment is blocker I mean)
<bdmurray> rbasak: I didn't mean to come across as saying you were not doing something. Its possible you weren't in the room at the time! I think we should make it the consensus. ;-)
<bdmurray> slangasek: I think you are the one who said we should use Incomplete more...
<rbasak> I don't like overloading the status like that, but pragmatically if that communicates it better then I'm fine with it.
<jbicha> bdmurray: the chrome-gnome-shell update is still in yakkety-proposed
<rbasak> Separately, I have been planning to propose a script auto-comment when there are autopkgtest failures, asking the SRU driver to check and tag the bug with autopkgtest-false-positive or something like that, and then having pending-sru not treat those as green unless the tag exists.
<rbasak> Similarly, perhaps we could have an sru-blocked tag instead of using the Incomplete status? Only a suggestion; I'm happy to follow the consensus.
<jbicha> bdmurray: it's blocked because you removed the verification-done tag
<bdmurray> jbicha: While that's true it won't matter if an AA fully phases it.
<jbicha> bdmurray: I think we're miscommunicating; the SRU team has not accepted it from -proposed yet because it's not verification-done
<bdmurray> rbasak: I believe robru is close to having autopkgtest results emailed to uploaders so two notifications might be a lot. Although, I guess having it on the public record (the bug) would be good.
<robru> bdmurray: I'm close to having stuck package notifications emailed out. autopkgtest results not included.
<bdmurray> jbicha: oh, i can read now. 8.2ubuntu4 not 8.2ubuntu3
<robru> bdmurray: also the email gets sent after the package is stuck for a day
<jbicha> bdmurray: thanks
<bdmurray> jbicha: yep, sorry for being slow!
<jbicha> rbasak: could you look into accepting chrome-gnome-shell and ubuntu-gnome-meta for trusty,xenial,yakkety even though it's not aged 7 days?
<jbicha> the SRUs were slowed down because of the trouble getting new packages into -updates, but Firefox 52 was released yesterday
<jbicha> to clarify, chrome-gnome-shell have been accepted into xenial and yakkety but trusty is still needed and u-g-meta for all 3 releases
<rbasak> jbicha: I'm finished for the day now, sorry. Ping me tomorrow if nobody else manages to look please?
 * rbasak is half asleep already :-/
<jbicha> ok thanks
<zul> can someone reject horizon 9.1.1 from the queue as well please
<slangasek> bdmurray: chrome-gnome-shell phasing done
<apw> zul, from where ?
<zul> apw: sorry xenial-proposed
<slangasek> bdmurray, rbasak: I don't recall if I proposed incomplete for incomplete testing, but that seems not-unreasonable to me
<bdmurray> slangasek: ah, my notes do lean more towards incomplete SRU information not verficiation
-queuebot:#ubuntu-release- Unapproved: rejected horizon [source] (xenial-proposed) [2:9.1.1-0ubuntu1]
<apw> zul, ^
<zul> thanks
<Laney> robru: Hey. I'll do a final pass over your MP tomorrow. Any chance you could provide a commit in another branch or something to log what it would do (who it would email for which excuse) instead of emailing so that I can do a dry run?
<robru> Laney: yeah i made this branch which prints out packages/versions/email addresses instead of sending anything.: https://code.launchpad.net/~robru/britney/+git/britney2-ubuntu/+ref/email-dry-run
<Laney> convenient
<Laney> does that end up in the normal log?
<robru> Laney: well, I *assume* stdout is captured in the normal log...
<robru> Laney: confirmed, self.log() is just a wrapper around print() anyway, so yeah, it'll be the same log
<Laney> robru: ok then, thanks
<robru> Laney: so what's the plan? you'll just copy that commit to snakefruit and we can look at the log? ;-)
<Laney> something like that
-queuebot:#ubuntu-release- New source: ukui-screensaver (zesty-proposed/primary) [1.0.0-0ubuntu1]
<robru> slangasek: gaughen: Laney: Ok I tried it locally and came up with this list of people to email: http://paste.ubuntu.com/24141582/ This is about 1/10 of the emails I was expecting, not clear to me if my attempt at setting up the britney env locally has failed, or if 90% of the stuff stuck in proposed is really auto-syncs that would not be emailed.
<gaughen> looks like slangasek will get a lot of email
<robru> hehe
<robru> I'm running it again with more verbose logging and it does look like there's a lot of stuff that qualifies for a mail but has nobody to mail (so, auto syncs)
<slangasek> robru: why do I get emailed for orthanc-webviewer?  Did I do something manual there?
<slangasek> possibly a manual sync to override the autosync behavior of not reintroducing removed packages
<robru> slangasek: yeah, lp api is blaming you, likely a manual sync.
<robru> slangasek: gaughen: http://paste.ubuntu.com/24141654/ this is more in line with my expectations
<robru> slangasek: so should I send that email and you can roll it out? ;-)
<slangasek> robru: "more in line"> what changed?
<robru> slangasek: it printed the stuck packages that won't be emailed about, so I can see there's more than 37 stuck packages.
<slangasek> robru: and I understood that Laney was on top of this for deployment
<robru> slangasek: going by excuses, I was expecting 370 emails, so when I saw only 37 I was surprised, thought maybe I was missing a chunk of packages somehow. but there's just a bunch that don't get emailed.
<slangasek> ok - so you didn't change anything about who would get mailed, just showing more stuck packages
<robru> yeah
-queuebot:#ubuntu-release- New source: ukui-control-center (zesty-proposed/primary) [1.0.0-0ubuntu1]
<Laney> robru: that doesn't seem to have a "Stuck" line for every excuse
<robru> Laney: it should be only if daysold >= 1
<Laney> e.g nautilus, gobject-introspection, openstack-doc-tools, systemd not mentioned
<robru> hmmmm
<bdmurray> slangasek: Do you think that bug 1654008 which has tens of thousands of incidences is worth SRU'ing given that something is wrong if int(time.time()) is greater than 2147483647?
<ubot5> bug 1654008 in update-manager (Ubuntu Zesty) "/usr/bin/update-manager:OverflowError:/usr/bin/update-manager@117" [High,Triaged] https://launchpad.net/bugs/1654008
<bdmurray> slangasek: It does prevent them from using update-manager, but we'd also need to SRU update-notifier which uses the launch-time key.
<robru> Laney: ok I'm running it again with maximum raw data dump just so I can inspect what's going on...
<Laney> nod
<slangasek> bdmurray: it would fix it so that anyone whose dconf value isn't /yet/ broken will be saved future(heh) pain, right?
<bdmurray> slangasek: afaict can tell the dconf value can't be broken because it doesn't fit in the range of allowed values. the test case is faketime to the future and update-manager crashes trying to write the value.
<robru> Laney: ok so what I'm seeing is that nautilus has excuse.is_valid = True, which doesn't make a lot of sense, but that's why it's not in the list of things to be emailed.
<bdmurray> slangasek: but it'll fix anybody whose clock is wrong
<robru> same with g-i
<robru> Laney: same with all four packages that you mentioned.
<slangasek> bdmurray: ok; that seems worth an SRU to me then
<bdmurray> alrighty
<robru> Laney: slangasek: seems that maybe excuse.is_valid isn't especially trustworthy? I can change the algo to ignore that value and go just by daysold if you think that makes sense.
<Laney> robru: I'm not sure - if slangasek doesn't know then you could ask nthykier for advice maybe
<Laney> Might be that it's not being set to false in some circumstances, and that could possibly be a bug
<slangasek> robru: what are you looking for out of excuse.is_valid?
<robru> Laney: it's possible those ones are being rejected by britney after my policy is inspecting them
<robru> slangasek: the code as it exists does not send mails when excuse.is_valid is True, however Laney pointed out four packages that are stuck for over a day, excuses says "Not considered", but they have excuse.is_valid = True at the time my policy runs.
<slangasek> robru: "is_valid" means that it is a candidate according to update_excuses, it does /not/ mean that it will migrate
<slangasek> robru: so you should not key on excuse.is_valid
<robru> slangasek: ok, will fix, thanks
<slangasek> robru: great :)
<Laney> Hmm?
<Laney> I don't understand that statement
<slangasek> Laney: "is_valid" means "valid candidate"; but things can be stuck because they increase uninstallibility - i.e. anything that needs update_output.txt to debug
<robru> Laney: which
<Laney> The policy is supposed to email for things that are not candidates on excuses isn't it?
-queuebot:#ubuntu-release- New source: ukui-desktop-environment (zesty-proposed/primary) [1.0.0]
<Laney> Or you want to email for transitions too?
<slangasek> Laney: AIUI we want to email for any package that is wedged in -proposed, including those that are wedged because of other packages
<Laney> mmkay
<slangasek> perhaps there should be different aging times for the two cases?
<robru> slangasek: britney gives daysold as an int unfortunately, so unless your idea is 1 day and 2 days...
<slangasek> robru: I don't understand
<robru> slangasek: I'm not sure what you mean by different aging times, but the grantularity I'm working with is integer days.
<Laney> He's saying that something can be 'valid' but still blocked, and that maybe we might want to have a different daysold threshold in that case
<slangasek> what Laney said
<slangasek> days are a unit of time
<robru> yeah. So I'm saying that would be 1 or 2, but I'm not able to do 1.5 or 0.5.
<slangasek> yes, that's fine
<Laney> Seems like a good idea to me
<robru> slangasek: ok so what are you saying then? 1 day if is_valid == False, 2 days if is_valid == True?
<Laney> But that puts you back in the position that is_valid is (maybe) wrongly False for some things
<robru> but at least then it's just 2 days until you get your email instead of never getting an email
<slangasek> I am not specifying a particular number of days here
-queuebot:#ubuntu-release- New sync: genwqe-user (zesty-proposed/primary) [4.0.18-2]
<slangasek> I am saying that if the package has is_valid == True, we might want to wait "longer" before sending mail, but not specifying how long that should be
<robru> slangasek: ok that's fine if you want that, we should figure out what that number is so I can finish this.
<Laney> For systemd it should be is_valid = False because it's rejected by the autopkgtest policy, and your one runs after that
<slangasek> Laney: do you have an opinion what the number should be?
<Laney> I think that's worth debugging
<slangasek> right
<Laney> slangasek: Umm, not a hard one - probably something like 5?
<Laney> It's hard to generalise for all transitions
<slangasek> Laney: that was the number I was thinking of
<Laney> Usually a "few"
<slangasek> ;)
<slangasek> robru: 5
<robru> ok
<robru> I'm just generating the report for what emails would be sent when ignoring is_valid. that information will still be useful, once it finishes I'll make it use a dynamic daysold cutoff.
<robru> slangasek: Laney: http://paste.ubuntu.com/24142092/ ok, there they all are: 142 emails and 400 stuck
<jbicha> robru: gnome-software 3.22.6-0ubuntu1 isn't stuck
<robru> jbicha: did it just migrate? I have stale indexes I'm working with locally.
<jbicha> yes it just migrated but it also was only uploaded a few hours ago
<robru> but but
<robru> jbicha: britney seems to think daysold > 1
<robru> >= 1 I mean
<robru> jbicha: I don't know what to say about that, I only inspect excuse.daysold, I didn't change the way britney calculates it.
-queuebot:#ubuntu-release- Unapproved: accepted nagios-plugins-contrib [source] (yakkety-proposed) [16.20151226ubuntu0.16.10.1]
<robru> slangasek: Laney: ok I changed it to use a cutoff of 5 days when is_valid == True, and 1 day for is_valid == False. Merge pls?
<jbicha> if it's going to email me about gnome-software, maybe you should bump the day from 1 to 2
-queuebot:#ubuntu-release- Unapproved: accepted nagios-plugins-contrib [source] (xenial-proposed) [16.20151226ubuntu0.16.04.1]
<robru> jbicha: https://launchpad.net/ubuntu/+source/fwupdate-signed/1.13 this upload was 15 hours ago but still shows as 0 days old.
-queuebot:#ubuntu-release- New binary: ubuntu-wallpapers [amd64] (zesty-proposed/main) [17.04.0-0ubuntu1] (ubuntu-desktop)
<robru> jbicha: I think something goofy is going on with my local indexes, I don't think it's going to email people for things migrating in hours.
<jbicha> is it possible your index is from that weird time while gnome-software was migrating?
<robru> jbicha: I just downloaded the index a few hours ago and have been running on it since, so yeah
<jbicha> I'm thinking of the gap when https://launchpad.net/ubuntu/+source/gnome-software will not show the package in either zesty-proposed or zesty while it's being published
<robru> jbicha: actually gnome-software shows here as is_valid = True which means it'd get the 5 day threshold anyway
<robru> jbicha: no it was definitely in -proposed when I downloaded it otherwise it wouldn't be being inspected.
<robru> slangasek: where should i send the announcement email to?
<slangasek> robru: it should go to ubuntu-devel-announce
<robru> slangasek: is now a good time?
<slangasek> robru: no reason not to AFAICS; does the mail just tell people that they'll "soon" start receiving emails?
<slangasek> it'll sit in the moderation queue anyway until a list admin looks at it
<robru> Yeah
<nacc> robru: nice feature!
<robru> nacc: thanks
<robru> Get ready for the deluge!
<nacc> robru: although the email address in your above paste for me is not my contact address
<nacc> robru: it is one of my two linked addresses
<nacc> robru: but not my preferred one for lp
<robru> nacc: it's what's on your gpg key. I'm unfortunately unable to query lp for preferred addresses
<nacc> robru: ah i see
<nacc> robru: that's interesting -- do you need to be logged in for that?
<robru> nacc: yeah it needs to be logged in, which snakefruit does have credentials for, but the code is python3 and snakefruit is very old, so it only has lplib for py2. So we're unfortunately stuck with anonymous lp access for now.
<nacc> robru: totally understood, i've had to do sort of similar things for the importer at times (as to what is visible anonymously)
<robru> At some point snakefruit can be updated to xenial and then this code can be ported to py3 lplib
#ubuntu-release 2017-03-09
-queuebot:#ubuntu-release- Unapproved: kexec-tools (yakkety-proposed/main) [1:2.0.10-2ubuntu1.1 => 1:2.0.10-2ubuntu1.2] (core)
-queuebot:#ubuntu-release- Unapproved: kexec-tools (xenial-proposed/main) [1:2.0.10-1ubuntu2.1 => 1:2.0.10-1ubuntu2.2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.23.1+16.10]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.23.1]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.23.1~14.04]
<tjaalton> apw: did you have a look at https://bugs.launchpad.net/ubuntu/+source/openmw/+bug/1671129 ?
<ubot5> Ubuntu bug 1671129 in openmw (Ubuntu) "remove armhf binaries for openmw to unblock mesa" [Undecided,New]
-queuebot:#ubuntu-release- New sync: genwqe-user (zesty-proposed/primary) [4.0.18-2]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-67.88] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-42.45] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: accepted fglrx-installer [source] (trusty-proposed) [2:15.201.1-0ubuntu0.14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted fglrx-installer-updates [source] (trusty-proposed) [2:15.201.1-0ubuntu0.14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-67.88]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-42.45]
<Laney> robru: http://people.canonical.com/~ubuntu-archive/~laney/emails.txt
<bdmurray> slangasek: Is the mongodb autopkgtest failure triggered by init-system-helpers ignorable?
<xnox> apw, genwqe-user in zesty new queue is a bugfix only point release; to replace genwqe package which is now finally maintained in debian
<xnox> also there are two syncs, so one of them can be killed
<jbicha> bdmurray: since you're doing SRUs today (right?) could you look at accepting ubuntu-gnome-meta (trusty,xenial,yakkety) and chrome-gnome-shell (trusty) even though it's not been 7 days yet
<bdmurray> jbicha: What was / is the rational for waiving the 7 day period?
-queuebot:#ubuntu-release- Unapproved: accepted backuppc [source] (xenial-proposed) [3.3.1-2ubuntu3.2]
<jbicha> because these uploads were originally uploaded to the new queue in January but they were delayed because it was hard to find someone willing/able to upload new packages as SRUs
<jbicha> and Firefox 52 was released to all Ubuntu versions Monday or Tuesday, triggering the regression fixed by these uploads
<bdmurray> jbicha: part 1 doesn't seem like a great reason, but part 2 does
<jbicha> right, part 1 is not valid except to explain that I tried to do this sooner
-queuebot:#ubuntu-release- Unapproved: accepted nova-lxd [source] (yakkety-proposed) [14.2.0-0ubuntu0.16.10.1]
-queuebot:#ubuntu-release- Unapproved: horizon (yakkety-proposed/main) [3:10.0.1-0ubuntu1 => 3:10.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (yakkety-proposed) [2:14.0.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: horizon (xenial-proposed/main) [2:9.1.0-0ubuntu1 => 2:9.1.1-0ubuntu1] (openstack, ubuntu-server)
<bdmurray> jbicha: sounds reasonable, I'll have a look shortly
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (yakkety-proposed) [1:7.0.2-0ubuntu1]
-queuebot:#ubuntu-release- New source: ukui-indicators (zesty-proposed/primary) [1.0.0-0ubuntu1]
<robru> Laney: lgtm, you ready to go live yet?
<Laney> robru: ha
<Laney> was going to, then I noticed that the email text is no longer necessarily correct
<Laney> the is_valid days thing
<Laney> also it might be nice to say "Hi," and "Regards, Ubuntu Release Team" but maybe that's just me :)
<Laney> and maybe make From have a name
 * Laney bikesheds
<robru> Laney: ok, are you asking me to clean that up or are you on it?
<Laney> robru: can you do it, if you don't mind?
<Laney> I think only the number of days thing is essential and the others just nice to have but ultimately optional
<Laney> no need to MP though, just give me a place to grab it from
<robru> Laney: ok, on it
<Laney> â¥
-queuebot:#ubuntu-release- Unapproved: ceph (yakkety-proposed/main) [10.2.5-0ubuntu0.16.10.1 => 10.2.6-0ubuntu0.16.10.1] (kubuntu, ubuntu-desktop, ubuntu-server)
<sforshee> is there an AA around who can approve the uefi bits for 4.10.0-12.14 in zesty?
-queuebot:#ubuntu-release- Unapproved: ceph (xenial-proposed/main) [10.2.5-0ubuntu0.16.04.1 => 10.2.6-0ubuntu0.16.04.1] (kubuntu, ubuntu-desktop, ubuntu-server)
 * cyphermox saw the magic U word
<cyphermox> sforshee: (but I can't approve)
<slangasek> bdmurray: mongodb/armhf is ignorable... which one did I not add to the hints?
<robru> Laney: https://git.launchpad.net/~robru/britney/+git/britney2-ubuntu/commit/?id=d66116d80948d8ff647dabe60e7ca5b83c4695df
<Laney> robru: thanks!
<bdmurray> slangasek: I still see mongodb armhf on the pending sru report
<robru> Laney: yw
<slangasek> bdmurray: which release?
 * Laney doesn't know this **locals() trick
<bdmurray> slangasek: xenial
<robru> Laney: it's so handy that the next version of python bakes it into the string literals ;-)
<slangasek> bdmurray: looks like I need to hint mongodb instead of morgodb
<robru> Laney: you know what ** does, right? locals() is just a function that returns local vars in the form of a dict.
<nacc> slangasek: fork it! :)
<slangasek> bdmurray: hint fixed
<robru> Laney: https://docs.python.org/3/whatsnew/3.6.html#whatsnew36-pep498 I'm perhaps too excited for this ;-)
<Laney> robru: yeah I get it, just haven't thought about / seen it before
<Laney> 498> ah, that looks nice
<Laney> robru: ok, pushed, let's see what happens
<Laney> exciting
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (yakkety-proposed) [2:9.1.2-0ubuntu1]
<robru> yay
<Laney> will need to wait for the current run to finish
-queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (yakkety-proposed) [1:7.0.2-0ubuntu1]
<robru> Laney: you around later? I have another britney branch I'd like to get reviewed once the dust settles on this one
-queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (yakkety-proposed) [2:10.0.1-0ubuntu1]
<Laney> robru: approximately 62 more minutes
<Laney> probably have more than 62 minutes of things to do today too, so any review is likely to be tomorrow :-)
<Laney> feel free to find someone else
-queuebot:#ubuntu-release- Unapproved: accepted swift [source] (yakkety-proposed) [2.10.1-0ubuntu1]
<robru> Laney: ok thanks
<bdmurray> coreycb: Have you looked at the autopkgtest failures here? http://autopkgtest.ubuntu.com/packages/n/neutron/yakkety/s390x
<coreycb> bdmurray, hi, yes they should be fixed by the version of neutron in the yakkety upload queue
<bdmurray> coreycb: ah, cool
<bdmurray> coreycb: is bug 1668578 fixed in Zesty?
<ubot5> bug 1668578 in neutron (Ubuntu) "Newton package needs to bump dependency on python-pecan" [Undecided,New] https://launchpad.net/bugs/1668578
<bdmurray> coreycb: that's also missing some SRU info
<coreycb> zul, you mind answer bdmurray since that's your work? ^
<zul> coreycb: sure
<Laney> robru: meh, no ConnectionRefusedError on python 3.2 :(
<robru> Nooooooo
<robru> Laney: what's the log?
<Laney> NameError
<robru> Laney: yeah but like does the full traceback not show what the original error is so i can catch that instead?
<Laney> robru: I don't think there was an error, it's just trying to set up the try: block
<robru> Laney: ok let me refer to the smtplib docs from 3.2 then...
<Laney> ah well, there is AttributeError: __exit__ actually
<Laney> so maybe smtplib isn't a context manager (in 3.2?) either
<robru> Laney: ugh, yeah, looks like smtplib in 3.2 has a totally different API. give me an hour to totally rewrite email policy then, sigh
<Laney> >>> with smtplib.SMTP('localhost') as s:
<Laney> ...     pass
<Laney> ...
<Laney> Traceback (most recent call last): File "<stdin>", line 1, in <module>
<Laney> AttributeError: __exit__
<Laney> yeah
<Laney> doh
<Laney> I'll put this back to dry-run for now ;-)
<robru> Laney: hah, ok thanks
<Laney> robru: be good to make it speak both versions if possible in a nice way, so this works if/when we upgrade the box
<robru> Laney: I believe the new smtplib is backwards compatible, but I'll double check
<Laney> ok, pushed
<Laney> robru: at least not wrt. exceptions, or?
<robru> Laney: I mean I believe the newer python added this context manager feature to smtp lib but kept the old behavior so if I just code it the old way it'll still work when snakefruit is upgraded
<robru> Laney: when I say "backwards compatible" I mean "I expect code written for 3.2 will still work in 3.4". the problem we're having now is that code written for 3.4 is breaking in 3.2
<Laney> robru: Right, but if you catch socket.error and the new one never raises it then that's not ideal?
<robru> Laney: all the new exceptions are backwards compatible as far as I know.
<Laney> It's both the context manager thing and the NameError
<Laney> ok
<robru> Laney: ok this should do it: https://git.launchpad.net/~robru/britney/+git/britney2-ubuntu/commit/?h=email-fix-smtp-3.2&id=2dec3ded31b0b22ce05cb47286b1d61ac1fb66cb
<Laney> robru: we get socket.error on connection refused
<robru> Laney: I was going off the smtplib documentation in 3.2 which claimed SMTPException was the base exception for all the exceptions it raises
<robru> https://docs.python.org/3.2/library/smtplib.html#smtplib.SMTPException
<Laney> I tried it in python3 -i
<robru> alright
<Laney> https://paste.ubuntu.com/24147191/
<robru> Laney: ok https://git.launchpad.net/~robru/britney/+git/britney2-ubuntu/commit/?h=email-fix-smtp-3.2&id=76183583ec9c8a37ef67c04cbe67c45dcd276b9a
<Laney> righto
<robru> wheeee
<Laney> is it going to use the From header or the parameter to sendmail()?
<Laney> looks like send_message existed in 3.2, not sure why you changed that bit
<robru> Laney: I just went with the 3.2 docs example code which shows it this way.
<robru> Laney: it says it doesn't modify the headers, the extra roreply is just for the mta
<Laney> I guess so (just the MAIL FROM) thing - that's not straightforward for me to parse as a non-email-expert
<Laney> meh, was hoping for this to have started running already
 * Laney needs to go out
<Laney> here we go
<jbicha> yay, the Release Team loves me and sent me email :)
<jbicha> "stuck in zesty-proposed for 40.184386574074075 days" :)
<Laney> oho
<nacc> probably could use an int() :)
<Laney> feel free to fix that
<Laney> but I can leave home a happy human
<Laney> laters
<robru> What
<robru> I could have sworn it is an int
<robru> Laney: thanks
<robru> jbicha: can you forward that to me
<nacc> robru: age = int(excuse.daysold) or 0
<nacc> robru: ?
<nacc> i guess you want to do that after the stuck check
<robru> nacc: i remember being frustrated in my testing because i wanted to inspect daysold for fractional values and they weren't there
<nacc> robru: interesting -- all of my e-mails have fractional values
<robru> nacc: eg if you look at excuses html it's all rounded there
<robru> I guess the tests put in ints but the live data is floats
<nacc> robru: ("<li>%d days old\n" % self.daysold)
<nacc> robru: maybe due to the formatting?
<nacc> robru: whereas you are using it as a string (afaict)
<robru> Yeah
<robru> Oh also there's a traceback in production, great
<nacc> robru: and i got a second e-mail 10 minutes later?
<nacc> robru: but only for one of the two packages i got an e-mail originally for
<robru> nacc: yes sir! There's a traceback preventing it from saving the list of things it emailed to the current situation is that it's going to resend all emails forever.
<nacc> robru: :)
<robru> Laney: slangasek: please change email policy back to dry run
<zul> bdmurray/coreycb: updated
<bdmurray> zul: thanks
<robru> slangasek: https://git.launchpad.net/~robru/britney/+git/britney2-ubuntu/commit/?id=80d363ffcfa4f4e045a17e6647f0df38001d8f6f need this commit pulled into production ASAP as Laney left with britney in a broken state.
<robru> alright well I officially have no power to fix anything so anybody who is simultaneously a hater of spam and has access to production, if you could just go ahead and push that commit in, that'd be great.
<robru> bbl
<robru> https://git.launchpad.net/~robru/britney/+git/britney2-ubuntu/commit/?h=fix-traceback&id=e7181465a8f67e767f4eda5d73c78b1ba9b93341
<slangasek> robru: so Laney did an end-of-day rollout? :)
<robru> yep
<slangasek> robru: is there an MP in LP for the above?
<jbicha> it beats doing it on Friday night though, right?
<robru> slangasek: nope I just pushed the commit. you want an MP?
<slangasek> robru: please
<slangasek> robru: especially as I can't find that commit after a 'git remote update'
<slangasek> (the first one you mentioned)
<robru> slangasek: https://code.launchpad.net/~robru/britney/+git/britney2-ubuntu/+merge/319487
<slangasek> robru: why are you using a .0f format instead of casting the input to an int?
<robru> slangasek: because casting to an int will cause the value to be rounded up prior to the time that it's used for comparison. This way we get the full fidelity of the data for the comparison and then only round it for display.
<slangasek> robru: ok. next problem, you're sending emails with *every p-m run* instead of just notifying users once that their packages are stuck
<slangasek> how do I put this back into dry-run mode?
<robru> slangasek: no no, it's only sending every time because the traceback prevents the cache from being written
<slangasek> ah
<robru> slangasek: to go back to dry run there's now a setting in britney.conf
<robru> but I think this MP should fix it based on the traceback I saw
<robru> so maybe just roll it out and hope for the best!
<robru> slangasek: another option is to write the cache after every email sent rather than waiting for the end, but that'll slow it down a bit.
<slangasek> robru: wrt this address_chooser, I thought we had talked about implementing this correctly using python3-launchpadlib and not rolling out until we could rely on that in snakefruit
<slangasek> (anyway, pushed now)
<robru> slangasek: I never saw a timeline on the migration of snakefruit to xenial so I assumed it was best not to block on that? I'll port it to python3-launchpadlib once snakefruit is running xenial.
<robru> slangasek: anyways thanks for pushing, I'll keep an eye on the logs to make sure there's no more tracebacks
<slangasek> robru: I know I specifically said that this should be done using the right lp apis; the snakefruit upgrade needs scheduled by precise EOL
<robru> slangasek: the way I recall that conversation, I asked you when it would happen and you said IS gave us an extension on things not being charmed so it wasn't clear to me when the upgrade would happen.
<cjwatson> that extension is the thing that lets us upgrade snakefruit wholesale to xenial rather than having to break it all up into charmable things
<slangasek> robru: ok, I never said anything about an extension for when the upgrade would happen, I only said it wasn't going to be charmed in the near future; sorry for the confusion
<robru> slangasek: ok, please do let me know when that upgrade will happen, there's lots of python-3.2-isms I'm eager to crush, not just lplib avoidance.
<slangasek> robru: python-3.2-isms should be a much lower priority than the fact that the new feature is not consistently sending email to the correct LP contact addresses
<robru> slangasek: normally i would agree with you, but in this case I mean specifically we are carrying a large delta against debian because we've had to backport a lot of things to python 3.2, so crushing 3.2isms is going to decrease our delta from debian, which is generally a good thing
<slangasek> but *not a priority*
<robru> slangasek: right so I'll fix the email thing the first day and then drop half our delta the second day :-P
<slangasek> robru: I'm still getting emails
<robru> slangasek: Yeah the last run still had old code, the current run is the first run with the new code
<slangasek> robru: ok, I see that this batch of emails have the rounding code now and also there are more emails, so that seems sound
<robru> oh, excellent. I was just going off timestamps.
<robru> slangasek: at the end of this run, assuming no more tracebacks anywhere else, you should see the EmailPolicy file written for the first time with all the info about what has and hasn't been emailed
<robru> and then next run, no more spam
<nacc> robru: e-mail looks better and it made progress to other packages that i have stuick
<nacc> *stuck
 * cjwatson is glad LP has transactional email code :)
<robru> cjwatson: yeah I should have wrote it to write the cache after each mail rather than writing the cache all at once.
<robru> nacc: alright sorry for all the spam
<nacc> robru: np! easy to filter
<nacc> robru: and i knew about all my packages :)
<robru> nacc: fix them then!!! ;-)
<nacc> robru: trying :)
<nacc> robru: if anyone actually understood liblog4ada or emacs25, mine would all be fixed :)
<robru> good luck!
<slangasek> infinity: I think xenial daily builds should be re-enabled; any reason against?
<slangasek> infinity: so from what I can see, current-triggers was never updated for the zesty cycle and needed to be because there's no inheritance in this file?
<slangasek> infinity: is this missing from the archive opening checklist?
<stgraber> oh crap, that lvm2 upload absolutely wasn't meant for the archive
 * stgraber removes
<stgraber> removed
<jgrimm> powersj:  slangasek is looking at your ppc64el smoke test gating right now. thinks it is enabled now.
<powersj> jgrimm: thanks!
<powersj> and slangasek thanks :D
<jgrimm> powersj, i guess watch for future failures and check that its done the right thing
<powersj> will do :)
<jgrimm> thanks sir
<Laney> oh please, it's not like there weren't other release team members around to help out
<slangasek> jbicha: what was the rationale for syncing libdrumstick from experimental?  I assume you've gotten email about it being stuck for months in -proposed due to kmidimon, which is unported (Debian bug #849862)
<ubot5> Debian bug 849862 in kmidimon "kmidimon needs updaing to latest libdrumstick (1.0.2-1)" [Wishlist,Open] http://bugs.debian.org/849862
<apw> sforshee: done
<jbicha> slangasek: I synced it because clivejo asked me to, bug 1584310
<ubot5> bug 1584310 in libdrumstick (Ubuntu) "New upstream release available" [Wishlist,Fix committed] https://launchpad.net/bugs/1584310
<slangasek> jbicha, clivejo: ok, perhaps we should un-sync this until it's migrated out of experimental and someone has dealt with the revdep (kmidimon)?
<clivejo> ack, Kubuntu needs it for KDE Applications
<clivejo> minuet
<clivejo> kmidimon?
<clivejo> thats ancient
<jbicha> maybe we should have emailed clivejo instead :)
<clivejo> that's KDE4 and hasnt been maintained in years!
<clivejo> acheronuk: did we not put in a request for that?
<clivejo> last release was 0.7.5 on 28-07-2013 - https://sourceforge.net/projects/kmidimon/files/
<acheronuk> clivejo: we discussed doing so last week. had slipped my mind though.
<jbicha> clivejo: why does minuet have a Build-Depends on drumstick but doesn't end up depending on drumstick?
<clivejo> its a library?
<jbicha> you said that minuet required the new drumstick so I would have expected one of the minuet packages to depend on libdrumstick1
<slangasek> clivejo: kmidimon is still in the Ubuntu (and Debian) archive; this needs follow-through
<jbicha> or depend on/recommend drumstick-tools?
<clivejo>  I cant get on to alioth to check, so I dont know
<clivejo> from what I remember debian are still on KDE apps 16.04
<clivejo> whilst Kubuntu is shipping with Apps 16.12
<clivejo> Neon's packaging auto syncs with debian
<clivejo> https://packaging.neon.kde.org/applications/minuet.git/
<clivejo> master branch will be what debian have
-queuebot:#ubuntu-release- New sync: libosl (zesty-proposed/primary) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted libosl [sync] (zesty-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New binary: libosl [amd64] (zesty-proposed/universe) [0.8.0-1] (no packageset)
<clivejo> with Debian in FF looks like they arent going to release minuet
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-12.14] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-12.14]
<clivejo> slangasek: can you actually un-sync libdrumstick
<slangasek> clivejo: no, someone needs to follow through on kmidimon
<slangasek> with a fixed upload, or a removal bug
<acheronuk> "ok, perhaps we should un-sync this" <-- so no longer applies?
<clivejo> even with kmidimon 0.7.5-3build1 in proposed?
<clivejo> and libdrumstick 1.0.2-1 also in proposed?
<acheronuk> + it turns out minuet -devs did a switcheroo on their required backends, sop new drumstick seem to not be needed for that.
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (yakkety-proposed) [3:10.0.2-0ubuntu1]
<slangasek> clivejo, acheronuk: oh, sorry - I misread you :-)  I thought you asked "unstick" rather than "un-sync"
<clivejo> no, we mean get rid/purge
<slangasek> clivejo, acheronuk: yes, I can "un-sync" it by deleting libdrumstick and kmidimon from zesty-proposed, and the next time libdrumstick is updated in unstable we can pull that instead
<slangasek> is that what you want?
<clivejo> slangasek: ack
<slangasek> clivejo, acheronuk: done :)
<acheronuk> TY :)
<clivejo> Ill take great pleasure purging it from KCI too
<acheronuk> lol. I recall how much of a pain that was!
<clivejo> jbicha: apology's for the run around :/
<clivejo> when I opened that bug it looked like minuet needed that package to build
<jbicha> slangasek: if you're deletinig kmidimon, then there's no reason libdrumstick needs to be deleted
<jbicha> because kmidimon was what halted the libdrumstick transition
<jbicha> unless you meant delete kmetronome and libdrumstick from zesty-proposed
<slangasek> jbicha: I was deleting them from zesty-proposed, not from zesty.  The need for the experimental libdrumstick went away
<jbicha> slangasek: could you delete kmetronome from zesty-proposed then?
<slangasek> jbicha: gladly - done
<slangasek> powersj: https://wiki.ubuntu.com/CurtinUpdates - what counts as a change to existing features that is covered by the curtin exception, without breaking backwards compatibility and requiring SRU approval?
<powersj> smoser: ^ while I think
<slangasek> (from my pov it probably makes sense to just list "bugfixes and new features")
<powersj> slangasek: what about test changes?
<powersj> otherwise I agree, bug and new features should cover everything else
<slangasek> sounds like a bugfix to me
<slangasek> at least, I've never had a problem from the SRU team side with changes to tests
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (xenial-proposed) [2:8.4.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (xenial-proposed) [2:9.1.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (xenial-proposed) [1:6.1.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (xenial-proposed) [1:6.1.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted swift [source] (xenial-proposed) [2.7.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-lbaas [source] (xenial-proposed) [2:8.3.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted nova-lxd [source] (xenial-proposed) [13.3.0-0ubuntu1]
#ubuntu-release 2017-03-10
<slangasek> powersj, smoser: I think I would like to require that, in cases where curtin's behavior is changing backwards-incompatibly, that the SRU template explicitly explain how the effects will be mitigated (e.g., appropriate versioned Breaks: ?).  Does that sound reasonable here?
<slangasek> powersj, smoser: also it's not clear to me that "vmtest" encompasses end-to-end testing through MAAS; is that part of the test plan?  (Also, going forward: subiquity?)
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (yakkety-proposed) [10.2.6-0ubuntu0.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (xenial-proposed) [10.2.6-0ubuntu0.16.04.1]
<smoser> slangasek, vmtest does not include tests driven by maas.
<smoser> curtin's interaction with maas is limited to essentially 2 things
<smoser> a.) maas sending config
<smoser> b.) that config including config that defines "reporting" that should be done (http posts of events... description timestamp..)
<smoser> for 'a', we feed plenty of config to curtin almost identically to how maas does it (using curtin's "pack")
<smoser> for 'b', we actually do have a http process that listens and we post messages to it and it records them.
<smoser> the shortcoming in 'b' is we do not do oauth there.
<slangasek> smoser: "almost identically to how maas does it" - but if the specific configs change, there's no integration test to ensure that what maas sends is still handled correctly by curtin?
<slangasek> that's the bit that I'm concerned about and would like to understand how we guard against it
<smoser> well, we send dozens of configs
<slangasek> "we" being in the curtin test suite?
<smoser> and we do test forward and backward compatibility.
<smoser> ie, there are 2 ways that you can declare apt configuration, and we do test them both.
<smoser> curtin test suite, yes.
<slangasek> right
<nacc> smoser: does the 'almost identically' refer to the configs themselves or the method of sending the config?
<smoser> method.
<slangasek> so if it's in the curtin test suite, I don't see anything that, structurally, guards against skew between curtin and maas
<nacc> smoser: ok, that's what i thought -- which might allay slangasek
<slangasek> well, but I understand the specific configs being tested are in the curtin test suite
<slangasek> not provided by maas
<smoser> not specifically. however, as input formats change/adapt, we're not adjusting old configs but rather adding new ones.
<slangasek> so they checkpoint a single point in time, when someone created those tests on the curtin side, of what they believed maas would be sending
<nacc> slangasek: right, so it would be 'better' if we also kept a cache of those checkpointed configs in the test suite :)
<nacc> slangasek: *or* used the configs from the old curtin testsuite somehow
<smoser> well we essentially *do* use configs from the old curtin testsuite.
<smoser> by... not removing existing tests.
<nacc> smoser: right and do we not change any existing tests?
<nacc> smoser: or any existing configs, i guess, more importantly
<slangasek> nacc: not sure I understand what you mean; I'm arguing that having the testsuite owned by curtin, and not live testing (w/ version matrix) of maas, means the integration testing is incomplete and possibly subject to drift
<smoser> in general, we add new things we don't remove old things.
<slangasek> drift between maas and curtin
<smoser> slangasek, you're correct.
<nacc> smoser: but that means you might mean you miss a case where you are now dependent on a new thing and the case where that isn't passed is no longer verified to work (and would be used by old maas)?
<nacc> slangasek: right, i follow what you mean
<slangasek> if the process is 1) look at what maas sends 2) add it to curtin test suite 3) make sure test suite doesn't regress, then this misses 2.5) maas changes what it sends, 2.6) curtin changes how it interprets thing maas sent
<smoser> i'm arguing that we're doing a better job of config/api testing than most existing ubuntu products, including those with a micro release exception.
<smoser> i'm not arguing that it is perfect.
<smoser> for example.... firefox doesn't test all possible addons
<smoser> (and in fact breaks them)
<slangasek> firefox does not have a micro release exception
<slangasek> firefox has an "I can't even" exception
<smoser> ?
<nacc> and also curtin's primary consumer is maas, aiui -- so it seems like verifying cross-compatibility in the SRU is rather important
<smoser> maas does test with -proposed
<smoser> i believe that is written in the documentation
<smoser> and they can and do test with our daily ppas
<smoser> which contain stuff as it would go into -proposed before it does
<slangasek> smoser: there is no mention of maas testing in https://wiki.ubuntu.com/CurtinUpdates
<slangasek> if what you're saying is that the maas autopkgtests will ensure compatibility doesn't break, great - then please document that in the exception
<smoser> slangasek, ok. we can get a statement to that affect.
<slangasek> if what you're saying is that maas tests with -proposed /outside/ of autopkgtests, and will somehow signal to stop the SRU if it breaks, then /definitely/ document that in the exception :-)
<slangasek> smoser: sounds good, thanks :)
<smoser> no. maas autopackage tests do not exist to my knowledge
<smoser> maas has c-i that runs with different curtins
<slangasek> right; if it's not done via autopkgtest, the SRU process has no built-in way to stop the line and so it should be called out as part of the test plan
<smoser> fair.
<smoser> slangasek, what would you suggest to get the coverage you are after?
<smoser> i have to run, slangasek thank you for your time. you can leave comments here , or email or anywhere and i'll get to them tomorrow. powersj will see them here too it looks like.
<powersj> I will :)
<nacc> i think the best thing to do would be to document the matrix that is tested, both via autopkgtest and manually by the MAAS team
-queuebot:#ubuntu-release- New source: peony (zesty-proposed/primary) [1.0.0-0ubuntu3]
<dx> hi, out of curiosity, if i wanted to upload a new upstream version of a thing to zesty, would that be as hard as it is to upload things to debian stretch?
<dx> nevermind found the wiki pages answering it, sorta. i'm under the impression that it's slightly softer than debian's freeze
<dx> so what are the chances of pidgin 2.12.0 in? https://bitbucket.org/pidgin/www/src/tip/htdocs/ChangeLog - it's mostly removal of broken protocols and some rather important bugfixes
<dx> ...ignoring the fact that the debian maintainer is half-afk and probably not going to package it any time soon
<jbicha> dx: I'm not on the Release Team, but those changes look fine to me; bugfix updates are still welcome for zesty
<Ukikie> Heh, I was just looking at that too.
<dx> Ukikie: that's a really nice combination of words to hear from you! (also, how often do you change nicks?)
<dx> oh another unrelated but release-relevant thing: zesty has mosh 1.3.0~rc2-1, a release candidate that was migrated from debian unstable accidentally
<dx> release candidate 3 was released since then (a month after rc2). don't know about any ETAs for a final release
<jbicha> dx: did you see https://lists.debian.org/debian-devel-changes/2017/03/msg00481.html
<dx> WHOA
<dx> amazing
<slangasek> smoser, powersj: at least for starters I'd like documentation of what maas testing will be done against the curtin in -proposed, and for this to be included in the test plan so that we don't accidentally release any SRUs without verifying the results of those tests
<powersj> jgrimm: ^
<Ukikie> dx: Hah, I've got no super powers at all, not even MOTU.  And not that often, only around christmas (You'll note I'm not in #irssi with the normal nick, it'll be back.) :)
<dx> Ukikie: ...i'm not sure i get what you mean. but, uh, don't we need someone to upload to zesty-proposed and they ask very politely for a freeze exception?
<dx> s/and they/and then/
<cpaelzer> Hi, we worked with IBM on a few dpdk fixes for ppc64el. Pushing them to zesty-proposed would be really great for dpdk on ppc64el.
<cpaelzer> But then it is late enough to be at least discussion worthy, therefore I made them an FFE
<cpaelzer> IBM completed extra tests on ppc64el, as well as myself doing various tests on x86
<cpaelzer> Also all patches are now upstream
<cpaelzer> before pushing I wanted to ask if one of the release Team could read into bug 1670686 and bug 1670689 and consider acking it as FFE
<ubot5> Error: Could not gather data from Launchpad for bug #1670686 (https://launchpad.net/bugs/1670686). The error has been logged
<ubot5> Error: Could not gather data from Launchpad for bug #1670689 (https://launchpad.net/bugs/1670689). The error has been logged
<apw> cpaelzer, presumably there is little regression potential for applying those given the packages do not exist (if i am reading the bugs right) for ppc64el currently and the code is arch specific?
 * apw notes there was some clarification discussion offline
<apw> cpaelzer, those looks good to me, simple self contained very low risk.  approved.  details in the bug
<cpaelzer> thanks apw
<LocutusOfBorg> dx, it is on my way (pidgin)
<LocutusOfBorg> I'm the usual merger of the package, you can just talk to me directly
<LocutusOfBorg> (I discovered this conversazion just by luck, when reading irclogs trying to find mentions of the spam I got tonight, wrt zesty-proposed packages)
<ginggs> LocutusOfBorg: it's not all spam ;) you can't upload and forget, you need to help your packages migrate
<Ukikie> LocutusOfBorg: If you're itching for updates, http://dev.deluge-torrent.org/wiki/ReleaseNotes/1.3.14 looked somewhat important.
<LocutusOfBorg> ginggs, receiving 10 times a mail "hey systemd didn't migrate" is spam 9 times, and good 1
<LocutusOfBorg> specially when you get all of them in ~3 h
<LocutusOfBorg> I got ~100 emails tonight
<LocutusOfBorg> and 14 in the last few minutes
<ginggs> LocutusOfBorg: how many different packages?
<LocutusOfBorg> around 20 I would wild guess
<LocutusOfBorg> wrt systemd:
<LocutusOfBorg> yesterday at 7.23 9.51 today at 4.31 6.36 6.36 8.57
<ginggs> LocutusOfBorg: I think you are the winner!
<LocutusOfBorg> 6 mails in 10 hours?
<ginggs> 20 stuck packages :)
<LocutusOfBorg> Ukikie, prod the debian maintainer, and I'll be happy to merge it :p
<caribou> Hi, the clamav sync is stucked in -proposed on the MIR for tomsfastmath. MIR is apparently completed so is there anything else to be done to get this sync finalized ?
<LocutusOfBorg> and ginggs lots of them are stuck because of -ocaml broken packages (demoted) -haskell broken packages (demoted) and imagemagick stuck transition due to emacs25
<LocutusOfBorg> that emacs25/arm64 needs some care, but I don't know how to solve
<LocutusOfBorg> oh activity on LP: #1656474
<ubot5> Launchpad bug 1656474 in emacs25 (Ubuntu) "FTBFS on arm64: make[4]: *** [../../lisp/cedet/semantic/bovine/c-by.el] Segmentation fault (core dumped)" [High,Confirmed] https://launchpad.net/bugs/1656474
<Laney> haha
<LocutusOfBorg> nacc, merge imagemagick?
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (yakkety-proposed) [1.13.4-3ubuntu0.2]
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (xenial-proposed) [1.13.4-1ubuntu1.3]
<Laney> apw: thinking about copying that glib2.0 from the other day into z-proposed, any objections?
<Laney> only asking you because I think you eyeballed it slightly
<apw> Laney, i don't recall being upset about it at the time
<Laney> it switches from static -dbg to ddebs, but I think that's ok
<Laney> well, Friday morning, what could possibly go wrong? :-)
<Laney> . o O ( zesty/debug debug/main main/debug, aha!)
<apw> there is no possibilty of confusion there
 * Laney just tried them until they worked
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.8.0-42.45~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.8.0-42.45~16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-67.88~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-67.88~14.04.1]
<mdeslaur> could someone please push gnutls28 and pcsc-lite out of proposed, please? The failing tests are unrelated.
<jackyu> hi
<apw> mdeslaur, looking ...
<mdeslaur> apw: Laney retried it with --all-proposed
<mdeslaur> apw: but pushing them through would be nice
<apw> mdeslaur, as in those are ongoing runs ?
<mdeslaur> he just retried them, so I guess yes
<apw> mdeslaur, ack thanks ...
-queuebot:#ubuntu-release- New binary: linux-signed-lts-trusty [amd64] (precise-proposed/main) [3.13.0-113.160~precise1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-trusty [amd64] (precise-proposed) [3.13.0-113.160~precise1]
<handsome_feng> Hi, apw, seb128, can you help to approve the UKUI packages? bug:1663477, bug:1664229, bug:1664232, bug:1664235, bug:1664244, bug:1664247, bug:1664256, or one of them first? Thank you in advance!
<handsome_feng> bug:#1663477, bug:#1664229, bug:#1664232, bug:#1664235, bug:#1664244, bug:#1664247, bug:#1664256
<handsome_feng> sorry, bug: #1663477, bug: #1664229, bug: #1664232, bug: #1664235, bug: #1664244, bug: #1664247, bug: #1664256
<ubot5> bug 1663477 in Ubuntu "[FFe] UKUI desktop environment" [Wishlist,In progress] https://launchpad.net/bugs/1663477
<ubot5> bug 1664229 in Ubuntu "[FFe] ukui-menu" [Wishlist,In progress] https://launchpad.net/bugs/1664229
<ubot5> bug 1664232 in Ubuntu Kylin "[FFe] ukui-indicators" [Critical,Fix committed] https://launchpad.net/bugs/1664232
<ubot5> bug 1664235 in Ubuntu "[FFe] peony" [Wishlist,In progress] https://launchpad.net/bugs/1664235
<ubot5> bug 1664244 in Ubuntu "[FFe] ukui-control-center" [Wishlist,In progress] https://launchpad.net/bugs/1664244
<jackyu> There are seven packages need to be approved:)
-queuebot:#ubuntu-release- Unapproved: network-manager-applet (xenial-proposed/main) [1.2.6-0ubuntu0.16.04.2 => 1.2.6-0ubuntu0.16.04.3~jdstrand1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected network-manager-applet [source] (xenial-proposed) [1.2.6-0ubuntu0.16.04.3~jdstrand1]
<nacc> well, LocutusOfBorg is already offline, but imagemagick does not need a merge
<nacc> teh version in z-p is good
<nacc> but the emacs25 that is in z-p is needed to migrate with it
<nacc> as there is a packaging transition
<nacc> slangasek: --^ i really have no idea how to fix the arm64 build failure of emacs25 in z-p
<nacc> jbicha: --^ it's your upload, but afaict, it shouldn't have broken the arm64 build on its own, right?
<jbicha> yes, emacs25 and emacs24 has been broken for a while in zesty
<jbicha> I hope I don't get blamed for it!
<nacc> emacs24 seems fine?
<nacc> well, i mean they are all hung up on each other
<nacc> but emacs25 does not build on arm64 "all of a sudden"
<nacc> so the big ratking is stuck :/
<jbicha> oh, just emacs25
<nacc> i just checked the build-logs and the updated emacs25 in z-p (which ahppened to build against the newer imagemagick) will migrate imagemagick too
<jbicha> nacc: I think LocutusOfBorg was referring to all the CVEs at https://tracker.debian.org/media/packages/i/imagemagick/changelog-8%3A6.9.7.4%2Bdfsg-2
<jbicha> since the zesty-proposed version is 6.9.7.0+dfsg-2
<nacc> jbicha: ah, i could merge but then i'd also probably need to go look at the FFe if needed for the change in upstream
<nacc> as i don't trust imagemagick not to change features on their bumps
<nacc> "make[4]: *** [../../lisp/cedet/semantic/bovine/c-by.el] Segmentation fault (core dumped)"
<jbicha> yes I looked at imagmagick's git repo recently :(
<nacc> jbicha: yep, makes your eyes bleed :/
<nacc> mdeslaur: would you prefer i update the imagemagick in z-p now? rather than having to do a security update right away
<mdeslaur> nacc: oh, that would be great
<nacc> mdeslaur: ok, i'll put it on my list; the problem is it'll get stuck in z-p anyways right now on emacs25 afaict. So let me spend some time seeing if i can get that to migrate first
<mdeslaur> sure, thanks
<nacc> jbicha: hrm, and emacs25 on arm64 built in debian at the same version
<nacc> and dannf said that he couldn't reproduce it with upstream source
<nacc> dannf: but you reproduce the pkg build failure on the same system?
<dannf> nacc: right. and emacs25 can build fine in ubuntu, it's just flaky - and scaling stack seems to really hate it. i think it's triggered by a gc
<dannf> nacc: i suspect it could FTBFS in debian too, in the right environment
<nacc> dannf: harrumph, super annoying :)
<dannf> i'll try that w/ a debian VM and see - we can at least get a debian bug filed if so
<nacc> dannf: is it calling flockfile with a NULL pointer?
<nacc> dannf: just trying to parse the backtrace
<nacc> oh that's the sigsegv handler, nm
<nacc> slangasek: would be able to review LP: #1671905 -- trying to make the security team's life easier
<ubot5> Launchpad bug 1671905 in imagemagick (Ubuntu) "[FFe] Please merge with imagemagick 8:6.9.7.4+dfsg-2 from Debian unstable." [Undecided,In progress] https://launchpad.net/bugs/1671905
<nacc> mdeslaur: the bug, for reference --^
<nacc> dannf: that would be great (repro in a debian VM), let me know if there's anything i can do to h elp
<mdeslaur> nacc: thanks!
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-13.15] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-13.15]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-113.160] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-113.160]
-queuebot:#ubuntu-release- New source: switcheroo-control (zesty-proposed/primary) [1.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libosl [amd64] (zesty-proposed) [0.8.0-1]
<tyhicks> hello - would it be possible for someone to allow the docker.io zesty upload through migration?
<tyhicks> it is blocked by an armhf test failure
<nacc> tyhicks: is it a bad test on armhf?
<tyhicks> it is not a regression and is an expected failure according to xnox's changelog entry here: https://launchpad.net/ubuntu/+source/docker.io/1.12.6-0ubuntu2
<nacc> not that i can change the hints, just wondering
<tyhicks> nacc: yes, the changelog entry sheds some light on it
<nacc> tyhicks: ah ok
<nacc> tyhicks: you could possible also subscribe ubuntu-archive to that bug and file a request in there (LP: #1658150)
<ubot5> Launchpad bug 1658150 in runc (Ubuntu) "adt test was insufficient to catch failed docker.io on s390x" [High,Confirmed] https://launchpad.net/bugs/1658150
<nacc> although it doens't really mention armhf there
<nacc> ideally that way the hint (if added) gets a link to that bug or so, which is tied to that upload
<nacc> just my opinion, i guess :)
<tyhicks> nacc: is it ubuntu-archive members that can add the hints?
<nacc> i think it's AAs (members of that team, aiui) -- but I might be wrong
<tyhicks> I guess that makes sense but I had never considered what LP team has that power
<nacc> tyhicks: --^
<tyhicks> ok
<tyhicks> comment left
<tyhicks> thanks
<cjwatson> hints are ~ubuntu-release
<nacc> cjwatson: ah ok
<nacc> tyhicks: --^ correction, then :)
#ubuntu-release 2017-03-11
<tyhicks> thanks!
-queuebot:#ubuntu-release- New binary: gpsshogi [amd64] (zesty-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gpsshogi [amd64] (zesty-proposed) [0.7.0-1]
<jbicha> chrome-gnome-shell is not in yakkety-updates
<jbicha> if you look at http://archive.ubuntu.com/ubuntu/pool/universe/c/chrome-gnome-shell/
<jbicha> chrome-gnome-shell_8-2ubuntu4~ubuntu16.10.1_all.deb is missing
<jbicha> bdmurray: pinging you since you accepted that SRU ^ on Wednesday
<jbicha> also the upload errors for https://launchpad.net/ubuntu/+source/android-sdk-meta/25.0.0+3 are odd
<apw> jbicha, yes, that appers to be published in launchpad's mind and yet not in the pool
<tsimonq2> infinity: Around on weekends?
#ubuntu-release 2017-03-12
-queuebot:#ubuntu-release- New binary: orthanc-dicomweb [i386] (zesty-proposed/universe) [0.3+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: orthanc-dicomweb [ppc64el] (zesty-proposed/universe) [0.3+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: orthanc-dicomweb [amd64] (zesty-proposed/universe) [0.3+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: orthanc-dicomweb [arm64] (zesty-proposed/universe) [0.3+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: orthanc-dicomweb [armhf] (zesty-proposed/universe) [0.3+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: orthanc-dicomweb [powerpc] (zesty-proposed/universe) [0.3+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: orthanc-dicomweb [s390x] (zesty-proposed/universe) [0.3+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: orthanc-webviewer [ppc64el] (zesty-proposed/universe) [2.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: orthanc-webviewer [amd64] (zesty-proposed/universe) [2.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: orthanc-webviewer [i386] (zesty-proposed/universe) [2.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: orthanc-webviewer [arm64] (zesty-proposed/universe) [2.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: orthanc-webviewer [s390x] (zesty-proposed/universe) [2.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: orthanc-webviewer [armhf] (zesty-proposed/universe) [2.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: orthanc-webviewer [powerpc] (zesty-proposed/universe) [2.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: devhelp [ppc64el] (zesty-proposed/main) [3.23.92-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: devhelp [i386] (zesty-proposed/main) [3.23.92-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: devhelp [amd64] (zesty-proposed/main) [3.23.92-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: devhelp [arm64] (zesty-proposed/main) [3.23.92-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: devhelp [s390x] (zesty-proposed/main) [3.23.92-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: devhelp [armhf] (zesty-proposed/main) [3.23.92-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: devhelp [powerpc] (zesty-proposed/main) [3.23.92-0ubuntu1] (kubuntu, ubuntu-desktop)
-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)
#ubuntu-release 2018-03-05
-queuebot:#ubuntu-release- New: rejected linux-aws [sync] (bionic-proposed) [4.4.0-1052.61]
-queuebot:#ubuntu-release- New: rejected linux-gke [sync] (bionic-proposed) [4.4.0-1034.34]
-queuebot:#ubuntu-release- New: rejected linux-kvm [sync] (bionic-proposed) [4.4.0-1019.24]
-queuebot:#ubuntu-release- New: rejected linux-meta-azure [sync] (bionic-proposed) [4.13.0.1011.12]
-queuebot:#ubuntu-release- New: rejected linux-azure [sync] (bionic-proposed) [4.13.0-1011.14]
-queuebot:#ubuntu-release- New: rejected linux-meta-aws [sync] (bionic-proposed) [4.4.0.1052.54]
-queuebot:#ubuntu-release- New: rejected linux-hwe [sync] (bionic-proposed) [4.13.0-36.40~16.04.1]
-queuebot:#ubuntu-release- New: rejected linux-meta-gke [sync] (bionic-proposed) [4.4.0.1034.35]
-queuebot:#ubuntu-release- New: rejected linux-meta-kvm [sync] (bionic-proposed) [4.4.0.1019.18]
-queuebot:#ubuntu-release- New: rejected linux-meta-hwe [sync] (bionic-proposed) [4.13.0.36.55]
<xnox> jbicha, slangasek - is it just britney picking an arbitrary arch to blame things on.
<stgraber> xnox: yeah, not sure what's going on, I can't figure out why the set of lxc packages won't migrate, gets blamed on different arch every time and I've done a number of local tests that show them all as co-installable, both within -proposed and when installing them on top of a system without -proposed (not depending on anything else that's in proposed)
<xnox> stgraber, i smell, being stuck behind libunistring0 -> libunistring2 transition; let me add a transition tracker to verify that.
<stgraber> I didn't see it pull unistring2 when installing just the packages I care about from proposed
<stgraber> let me check that container
<stgraber> ii  libunistring0:amd64              0.9.3-5.2ubuntu1                  amd64        Unicode string library for C
<stgraber> that's the unistring in there after installing the entire lxc stack from proposed, so it's not pulling the new unistring in
<LocutusOfBorg> xnox, it needs a removal of freeipa IIRC, libunistring is all green
<slangasek> stgraber: I notice that you have a versioned breaks/replaces against lxc-common but that this package no longer exists in -proposed, so that should probably be unversioned Conflicts/Replaces and maybe Provides?
<LocutusOfBorg> slangasek, can you please remove the ./vorlon:force-badtest tracker/all/s390x line?
<LocutusOfBorg> thanks :)
<xnox> LocutusOfBorg, yeah, i want to double check the tracker. ideally we should keep the trackers around, until things actually migrate. as sometimes people can regress migrations which are otherwise ready.
<xnox> (and e.g. to see the packages to remove)
<stgraber> slangasek: oh, good catch. It was initially planned to transition it to a transitional package like some of the others but then just dropped as we don't have any rdepends on it other than our own packages
<stgraber> slangasek: I'll change that
<LocutusOfBorg> xnox, I moved the tracker to finished once it became all green
<LocutusOfBorg> feel free to add it back
<slangasek> stgraber: ok.  I'm pretty sure it's not the cause of the migration failure, just something I noticed
 * LocutusOfBorg might be wrong
<slangasek> LocutusOfBorg: tracker/all/s390x is marked 'flaky test'.  Is the test no longer flaky?
<LocutusOfBorg> slangasek, seems to pass now, but you can keep it there, it is not easy to test "flaky" :)
<LocutusOfBorg> I saw it was failing for the same reason as other archs, and now with libunistring 0.9.9 it is green.
<LocutusOfBorg> I scheduled a second run and lets see
<LocutusOfBorg> slangasek, question: curl and libunistring are entangled with kamailio... how can I build a kamailio version with older curl to see everything migrate, and then no change rebuild it again? this would make things easier
<LocutusOfBorg> maybe a kamailio with curl taken from release? is it possible?
<xnox> LocutusOfBorg, well, we need curl migration too....
<xnox> and ruby-defaults mirgration....
<slangasek> LocutusOfBorg: curl is really blocked by xmltooling.  All the rest is just about ready to go on both sides of that transition.  Please don't try to play build env tricks to circumvent
<slangasek> xmltooling and net-cpp and AFAIK that's the complete list
<LocutusOfBorg> ack but curl is also r-base entangled
-queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu7.2 => 2.02~beta3-4ubuntu7.3] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (artful-proposed/main) [1.85.2 => 1.85.3] (core)
<LocutusOfBorg> scilab ftbfs on i386 <-- this is a curl blocker
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox [source] (artful-proposed) [5.1.34-dfsg-0ubuntu1.17.10.1~17.10.1]
<slangasek> who is trying to rebuild xmltooling? :P
<LocutusOfBorg> me, only once, sorry!
<slangasek> ;)
<LocutusOfBorg> I was trying to sort out where the issue was, and I found it, with the debian rc bug too
<slangasek> it definitely isn't going to fix itself
<LocutusOfBorg> meh, "upstream going to do the work, not sure when"
<LocutusOfBorg> yes, indeed, but apt could be more verbose when indirect dependencies are conflicting
<slangasek> LocutusOfBorg: conflict between libxml-security-dev and libssl-dev which is not straightforwardly resolvable
<LocutusOfBorg> slangasek, there is no need to tweak the debian packaging, to make kamailio build against curl in release, just build in a ppa with "release only repo enabled" and copy binaries to the archive (I'm trying to understand, I don't want to do it, unless you ask me)
<smoser> slangasek: not terribly high priority, but on friday we talked about allowing cloud-init into xenial. and delayed primarily because of 'friday'.
<smoser> being it is now monday, could you re-evaluate ?
-queuebot:#ubuntu-release- Unapproved: accepted aptdaemon [source] (artful-proposed) [1.1.1+bzr982-0ubuntu17.1]
-queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (artful-proposed) [4.3.5-3ubuntu2.3]
-queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (xenial-proposed) [4.3.3-5ubuntu12.10]
-queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (trusty-proposed) [4.2.4-7ubuntu12.13]
<tsimonq2> flocculant: Just double checking, y'all aren't doing Beta 1 right?
-queuebot:#ubuntu-release- Unapproved: accepted nplan [source] (artful-proposed) [0.32~17.10.3]
<slangasek> smoser: from my side, the delay was because "it's not a regression in xenial so no reason for extraordinary processing" :)  let me have a quick look
<smoser> fair
<stgraber> slangasek: updated my lxc hint so we'll see if we get any luckier with this upload... if it doesn't migrate, I really have no clue what's going on, the output doesn't make much sense to me
<slangasek> smoser: the latest version has only aged 2 days in xenial-proposed, but that's of course because of the additional upload to fix the regression.  I'm indifferent to whether we release it now, if you are happy that these are ready to release then I can do so
<smoser> blackboxsw: ^
<smoser> i think we're good.
<blackboxsw> +1 slangasek yes I also validated that same set of changes on artful-updates which worked well
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox-hwe [source] (xenial-proposed) [5.1.34-dfsg-0ubuntu1.16.04.1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox [source] (xenial-proposed) [5.1.34-dfsg-0ubuntu1.16.04.1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected nplan [source] (xenial-proposed) [0.32~16.04.4]
<stgraber> slangasek: right, so we're back to the whole lxc stack being considered valid candidates but nothing moving...
<sil2100> cyphermox: I'm accepting it, but please add SRU info to LP: #1747714 o/
<ubot5`> Launchpad bug 1747714 in nplan (Ubuntu Xenial) "network manager snap service name regression" [High,In progress] https://launchpad.net/bugs/1747714
-queuebot:#ubuntu-release- Unapproved: accepted nplan [source] (xenial-proposed) [0.32~16.04.4]
<Laney> stgraber: I think it needs hinting with python3-lxc
<Laney> sec
<stgraber> I thought I skiptested all the relevant bits
<stgraber> otherwise britney wouldn't consider them all valid candidates right?
<Laney> stgraber: they need to migrate in the same transaction and britney isn't considering python3-lxd with the rest
<Laney> it's only doing Trying easy from autohinter: golang-gopkg-lxc-go-lxc.v2/0.0~git20180119.b964baa-1ubuntu3 lxc/3.0.0~beta1-0ubuntu3 lxc-templates/3.0.0~beta1-0ubuntu1
<stgraber> odd
<Laney> britney> easy golang-gopkg-lxc-go-lxc.v2/0.0~git20180119.b964baa-1ubuntu3 lxc/3.0.0~beta1-0ubuntu3 lxc-templates/3.0.0~beta1-0ubuntu1 python3-lxc/3.0.0~beta1-0ubuntu2
<Laney> Trying easy from hint-tester: golang-gopkg-lxc-go-lxc.v2/0.0~git20180119.b964baa-1ubuntu3 lxc/3.0.0~beta1-0ubuntu3 lxc-templates/3.0.0~beta1-0ubuntu1 python3-lxc/3.0.0~beta1-0ubuntu2
<Laney> ...
<Laney> SUCCESS (379/0)
<Laney> I'll add that for the next run
<stgraber> yay, thanks
<sil2100> Laney: hey, is your "+1" an approval for the LP: #1752928 FFe? Should the bug be set to Triaged?
<ubot5`> Launchpad bug 1752928 in ubuntu-meta (Ubuntu) "[FFe] GNOME 3.28" [Undecided,New] https://launchpad.net/bugs/1752928
<Laney> sil2100: yeah, I probably forgot, please feel free to do it
-queuebot:#ubuntu-release- Unapproved: zfs-linux (artful-proposed/main) [0.6.5.11-1ubuntu3.1 => 0.6.5.11-1ubuntu3.2] (core)
-queuebot:#ubuntu-release- New sync: linux-aws (bionic-proposed/primary) [4.15.0-1001.1]
-queuebot:#ubuntu-release- New: accepted linux-aws [sync] (bionic-proposed) [4.15.0-1001.1]
-queuebot:#ubuntu-release- New sync: linux-meta-aws (bionic-proposed/primary) [4.15.0.1001.1]
-queuebot:#ubuntu-release- New sync: linux-azure (bionic-proposed/primary) [4.15.0-1002.2]
-queuebot:#ubuntu-release- New: accepted linux-azure [sync] (bionic-proposed) [4.15.0-1002.2]
-queuebot:#ubuntu-release- New: accepted linux-meta-aws [sync] (bionic-proposed) [4.15.0.1001.1]
-queuebot:#ubuntu-release- New binary: linux-meta-aws [amd64] (bionic-proposed/none) [4.15.0.1001.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-meta-azure [amd64] (bionic-proposed/none) [4.15.0.1002.3] (kernel)
-queuebot:#ubuntu-release- New binary: linux-meta-gcp [amd64] (bionic-proposed/none) [4.15.0.1001.2] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-meta-aws [amd64] (bionic-proposed) [4.15.0.1001.1]
-queuebot:#ubuntu-release- New: accepted linux-meta-azure [amd64] (bionic-proposed) [4.15.0.1002.3]
-queuebot:#ubuntu-release- New: accepted linux-meta-gcp [amd64] (bionic-proposed) [4.15.0.1001.2]
-queuebot:#ubuntu-release- New binary: linux-azure [amd64] (bionic-proposed/main) [4.15.0-1002.2] (kernel)
-queuebot:#ubuntu-release- New sync: hg-git (bionic-proposed/primary) [0.8.11-1]
-queuebot:#ubuntu-release- New sync: libauth-googleauth-perl (bionic-proposed/primary) [1.02-1]
-queuebot:#ubuntu-release- New sync: libwww-shorten-5gp-perl (bionic-proposed/primary) [1.030-1]
-queuebot:#ubuntu-release- New binary: linux-aws [amd64] (bionic-proposed/main) [4.15.0-1001.1] (kernel)
<flocculant> tsimonq2: yes we are
<flocculant> tsimonq2: it's only alpha's we see no gain
<tsimonq2> flocculant: Since when do y'all do Beta 1?
<tsimonq2> XD
<flocculant> since as long as I've been around and longer - it's alpha's we don't do
<flocculant> though I think a while back we had an issue at b1 time and I was refusing to release it in that state
<flocculant> I'd argue for beta's it's alpha's my position is clear on :D
<tsimonq2> :D
<tsimonq2> OK
-queuebot:#ubuntu-release- New binary: linux-gcp [amd64] (bionic-proposed/main) [4.15.0-1001.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: python-cryptography (artful-proposed/main) [1.9-1 => 1.9-1ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: python-cryptography (xenial-proposed/main) [1.2.3-1ubuntu0.1 => 1.2.3-1ubuntu0.2] (ubuntu-desktop, ubuntu-server)
#ubuntu-release 2018-03-06
<wxl> bashfulrobot: seems like you're in charge of coordinating beta 2? we going to have images to test tomorrow?
<bashfulrobot> I'm actually drafting the wiki page and sending the email to the mailing list. So we actually consider this beta 2? Or Jitsu a delayed beta one?
<bashfulrobot> wxl: ^^
<wxl> sorry, i think i meant 1
<wxl> yes i did :)
<wxl> beta 2 is supposed to be next month
<nacc> wxl: did you ever figure out your seed issue?
<wxl> i'm wearing the lubuntu release manager hat from off tsimonq2's head for the better part of the week, just in case you need me, bashfulrobot
<wxl> nacc: no, but i think we have what we need to figure it out. tsimonq2 has a lot more experience with germinate than i do so i left it in his hands.
<nacc> wxl: ack
<bashfulrobot> wxl: I appreciate the offer for help. Simon always guided me through. Lost a hard drive with my notes, but. Prepping wiki page, will email list to get the flavors signed up. Then I know we need to track down someone to help with Nusakan.
<bashfulrobot> I'll confirm in here as well once the wiki and email list has been completed
<wxl> bashfulrobot: he said sil2100 was going to do it but i guess your fall back would be poor old infinity
 * wxl pats adam's well-worn head
 * bashfulrobot plans to hit up sil2200 when the time is right.
<flocculant> bashfulrobot: I've done the flavour bit of this in the past too - another name you can ping if needed :)
<bashfulrobot> Great flocculant ! Appreciate the support
<flocculant> no problem :)
<bashfulrobot> I plan on making detailed notes this time so I don't need to bug anyone next time.
<flocculant> best laid plans of mice and men ...
<bashfulrobot> too true!
<flocculant> added Xubuntu to the wiki page
<bashfulrobot> The one I just created?
<bashfulrobot> Also on past pages there were links from the beta/alpha pages that went to something like: https://wiki.ubuntu.com/BionicBeaver/Beta1/CommonInfrastructure - but many of those pages were never created. I imagine I should just yank that (as it is uselesss)
<flocculant> yea the one you just created
<flocculant> and yea - I'd yank that - only time it really works is the one that Ubuntu joins in with, when they've created the main wiki page
<bashfulrobot> In the past there were also links to release announcements - was that always something official or the release manager wrote it?
<bashfulrobot> flocculant: Cool - I'll comment that out
<flocculant> same
<bashfulrobot> perfect
<bashfulrobot> Commenting up a storm!
<flocculant> pre-Final Beta the only announcement is what whoever does the flavour side writes for the mailing list
<flocculant> bashfulrobot: see https://wiki.ubuntu.com/ArtfulAardvark/Beta1/ReleaseAnnouncement
<bashfulrobot> Cool. I had peeked at that one earlier. I'll leave the page as is for now.
<flocculant> yea
<flocculant> personally when I last did it - I didn't do any of that stuff :)
<bashfulrobot> originally B1 was supposed to be Mar 1 - so I guess we can just push out to Mar 8? 1 week later. Or is that date too close if I am about to email the mailing list?
<flocculant> beta 1 will be out of date as soon as it updates anyway - I try not to advertise it's existence
<bashfulrobot> ha ha
<flocculant> release schedule says 8th
<bashfulrobot> Well, I'll just get the flavors to pipe in on that wiki page. And great for the 8th.
<flocculant> assuming you can get a Canonical bod involved yea
 * bashfulrobot pilfering a previous email to send to the email list.
<flocculant> bashfulrobot: yep - mail release list pointing to it and wait for the deafening silence :D
 * mwhudson stares at freeipa
<flocculant> does mwhudson want other's to join in with freezing stare?
<mwhudson> oh i see there has been lots of talk about this already
<mwhudson> flocculant: more like a "begone from -proposed" stare i think?
<flocculant> :)
<mwhudson> pg-repack
<mwhudson> oops
<mwhudson> although has anyone looked at that?
<bashfulrobot> ok - email sent to the mailing list
 * bashfulrobot waiting to hear the crickets chirp
<bashfulrobot> for those super keen people that want to sign up for beta one...https://wiki.ubuntu.com/BionicBeaver/Beta1
<bashfulrobot> sil2100 and infinity
<bashfulrobot> knocking on the Nusakan door
 * bashfulrobot slinks away into the shadows
 * bashfulrobot turning in. Zzz
<flocculant> bashfulrobot: thanks for doing this :)
<bashfulrobot> flocculant: my pleasure! Like getting involved.
<flocculant> \o/
 * flocculant wanders off for work
<xnox> oh, and linux-meta-kvm
<xnox> slangasek, hwe, hwe-edge, kvm still to do, it looks like.
-queuebot:#ubuntu-release- New: accepted linux-azure [amd64] (bionic-proposed) [4.15.0-1002.2]
-queuebot:#ubuntu-release- New source: curl3 (bionic-proposed/primary) [7.58.0-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted pyxs [source] (bionic-proposed) [0.4.1+dfsg1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: pyxs [amd64] (bionic-proposed/universe) [0.4.1+dfsg1-0ubuntu1] (no packageset)
<xnox> slangasek, curl3 is in, i guess best debdiffed against curl from release pocket....
-queuebot:#ubuntu-release- New: accepted rax-nova-agent [source] (bionic-proposed) [2.1.12-0ubuntu1]
<slangasek> xnox: indeed
<acheronuk> morning. slangasek or anyone else: is anyone able to give attention to the gstreamer plugins-good issue before beta 1 isos get done?
<slangasek> acheronuk: I've flagged it to the MIR team; I'm not on the MIR or security team so approving this into main is not up to me.  If we can't get the MIRs done in time for image mastering, we have two other options: pre-promote these packages into main while the MIR is in progress, with the possibility that they might be rejected and have to be dropped again; or revert the package in -proposed and
<slangasek> accept the ongoing transition without the new upstream gst-plugins-good (<-- Laney?)
<slangasek> xnox: not a NEW blocker, but maybe drop the XSBC-Original-Maintainer from curl3
<xnox> meh, ok.
<slangasek> xnox: or put your own name in a maintainer field for a change ;P
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (artful-proposed/partner) [183.0.0-0ubuntu1~17.10.0 => 191.0.0-0ubuntu1~17.10.0] (no packageset)
<xnox> slangasek, i'm so over it.
<xnox> slangasek, i'm thinking to start uploading binNMUs with -- Ubuntu Developers <ubuntu-devel@....>
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (trusty-proposed/partner) [183.0.0-0ubuntu1~14.04.0 => 191.0.0-0ubuntu1~14.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (xenial-proposed/partner) [183.0.0-0ubuntu1~16.04.0 => 191.0.0-0ubuntu1~16.04.0] (no packageset)
<slangasek> xnox: why is debian/libcurl3.links dropped?  It may not help anyone in practice, but it also doesn't hurt
<xnox> slangasek, reject, let me reupload. It was dropped when i thought i had to provide libcurl3 co-installable with libcurl4, and started to thinking into shipping it as libcurl.so.3 / libcurl.so.3.4.5.1 or some such
<slangasek> xnox: too late, already accepted, you can do a -2
<slangasek> -3
<xnox> ok
-queuebot:#ubuntu-release- New: accepted curl3 [source] (bionic-proposed) [7.58.0-2ubuntu2]
<acheronuk> slangasek: ok. fwiw I have not yet seen any confirmed reports of the alleged issue with upgrades to mesa 18 without the bugfix in -proposed Qt, and by its nature the bug should not in theory affect a fresh install from iso or the live session. so if Qt does not move, at the moment seems a 'this might be buggy on upgrading a current system' in beta release notes could just about be acceptable
<slangasek> acheronuk: well, I think it is important for us to resolve this transition in time for beta, let's continue aiming for that
<acheronuk> slangasek: great. no complaints from with that. thank you
<acheronuk> *from me
-queuebot:#ubuntu-release- New: accepted linux-aws [amd64] (bionic-proposed) [4.15.0-1001.1]
-queuebot:#ubuntu-release- New: accepted linux-gcp [amd64] (bionic-proposed) [4.15.0-1001.1]
-queuebot:#ubuntu-release- New: accepted pyxs [amd64] (bionic-proposed) [0.4.1+dfsg1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (artful-proposed) [191.0.0-0ubuntu1~17.10.0]
-queuebot:#ubuntu-release- New binary: curl3 [s390x] (bionic-proposed/none) [7.58.0-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (xenial-proposed) [191.0.0-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- New binary: curl3 [amd64] (bionic-proposed/none) [7.58.0-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: curl3 [ppc64el] (bionic-proposed/none) [7.58.0-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: curl3 [i386] (bionic-proposed/none) [7.58.0-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (trusty-proposed) [191.0.0-0ubuntu1~14.04.0]
-queuebot:#ubuntu-release- New binary: curl3 [arm64] (bionic-proposed/universe) [7.58.0-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: curl3 [armhf] (bionic-proposed/universe) [7.58.0-2ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: apt (xenial-proposed/main) [1.2.25 => 1.2.26] (core)
-queuebot:#ubuntu-release- New: accepted curl3 [amd64] (bionic-proposed) [7.58.0-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted curl3 [armhf] (bionic-proposed) [7.58.0-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted curl3 [ppc64el] (bionic-proposed) [7.58.0-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted curl3 [arm64] (bionic-proposed) [7.58.0-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted curl3 [s390x] (bionic-proposed) [7.58.0-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted curl3 [i386] (bionic-proposed) [7.58.0-2ubuntu2]
<slangasek> jamespage: you have some significant lintian warnings in python-diskimage-builder around update-alternatives; please have a look
-queuebot:#ubuntu-release- New: accepted python-diskimage-builder [amd64] (bionic-proposed) [2.11.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted dpkg [source] (trusty-proposed) [1.17.5ubuntu5.8]
<bluesabre> slangasek: would you be interested in approving https://bugs.launchpad.net/ubuntu/+source/xubuntu-default-settings/+bug/1753015 ? It's a very minor change and is the last feature missing from xubuntu bionic :)
<ubot5`> Ubuntu bug 1753015 in xubuntu-default-settings (Ubuntu) "[FFe] Add thunar custom action to directly print certain file types" [Undecided,Confirmed]
-queuebot:#ubuntu-release- New binary: rax-nova-agent [amd64] (bionic-proposed/universe) [2.1.12-0ubuntu2] (no packageset)
<LocutusOfBorg> hello, who is the one trying to remove ruby2.3 from the archive
<LocutusOfBorg> ?
<LocutusOfBorg> xnox, a lot of stuff is failing because autopkgtests drags in the ruby2.3 package http://autopkgtest.ubuntu.com/packages/r/ruby-allocations/bionic/amd64
<xnox> LocutusOfBorg, but... ruby-defaults still has not migrated =(
<LocutusOfBorg> I tried with all-proposed and it is failing and dragging 2.3 too
<LocutusOfBorg> maybe adding a conflict on ruby2.5 against 2.3?
<LocutusOfBorg> same, ruby-defaults won't migrate, because autopkgtests are failing for the same reason
<LocutusOfBorg> see: http://autopkgtest.ubuntu.com/packages/r/ruby-turbolinks/bionic/amd64
<LocutusOfBorg> autopkgtest [19:09:17]: test command1: ruby2.3 -e gem\ \"gitlab-turbolinks-classic\"
<LocutusOfBorg> autopkgtest [19:09:17]: test command1: [-----------------------
<LocutusOfBorg> bash: ruby2.3: command not found
<LocutusOfBorg> where is that version picked up?
-queuebot:#ubuntu-release- New sync: python-bayespy (bionic-proposed/primary) [0.5.12-1]
<flexiondotorg> sil2100: Were you contacted by any flavours with regard to spinning Beta 1 images?
<acheronuk> flexiondotorg: haven't tried yet, as there are some transitions to fix 1st
<acheronuk> if they can be
<sil2100> flexiondotorg: yeah, but infinity is leading
<flexiondotorg> Thanks.
<sil2100> He said he'll take care of it so I'm leaving it in his hands
<bashfulrobot> Looks like we have 4 flavours good to go for beta 1. Just getting up and going, so I'm just starting to digest the info.
<bashfulrobot> infinity: I hear you are the man to talk to regarding Nusakan. :-)
<xnox> slangasek, does curl need hinting with curl3?
<xnox> slangasek, RM scilab on i386?! fails test, better not ship broken software on i386, but let everything else to migrate?
<slangasek> xnox: revdeps of scilib?
<slangasek> lab
<xnox> slangasek, twats
<slangasek> xnox: assign java failure to tdaitx_ for investigation?
<slangasek> xnox: skip documentation on i386?
<xnox> slangasek, it's failing in debian too
<xnox> slangasek, possibly, need to check if the docs are arch;all
<slangasek> xnox: could be omitted on a per-arch basis even if not arch:all
<xnox> slangasek, huh, it already has the code to do that, lolz
<xnox> doing so
<acheronuk> bashfulrobot: wanting to go, but maybe not good-to-go yet
<slangasek> xnox: any guesses why abi-monitor alone is reported uninstallable, and only on amd64?
<bashfulrobot> acheronuk: weekday kind of time line so you think you are looking at?
<xnox> slangasek, hmmmmm....... because build-essential is not installable?! it does depend on curl...
<xnox>  Depends: build-essential, cmake, wget, curl, git, perl:any
<acheronuk> bashfulrobot: depends on release team actions, so I can't say
<bashfulrobot> Ok, sounds good
<slangasek> xnox: build-essential did not appear in the list of uninstallables, only abi-monitor
<xnox> ok
-queuebot:#ubuntu-release- Unapproved: python-pyperclip (artful-proposed/main) [1.5.27-3 => 1.5.27-3ubuntu1] (no packageset)
<infinity> bashfulrobot: Yo dawg, I heard you like milestones.
<bashfulrobot> infinity: woof
<bashfulrobot> infinity: milestones can be a good thing
<infinity> bashfulrobot: Setting it up now.
<bashfulrobot> infinity: thank you good sir!
<bashfulrobot> infinity: Is there anything additional that you need from me? Info, etc?
<wxl> bashfulrobot: you did see the topic, right?
<acheronuk> good beer in Budapest
<bashfulrobot> wxl: Missed it
<bashfulrobot> (in the office multi tasking)
<wxl> bashfulrobot: "We accept payment in cash, check or beer"
<bashfulrobot> acheronuk: I'll be on a plane shortly?
<bashfulrobot> Well the next time I am in a city with any one of you. Beers on me.
<bashfulrobot> But that seems liek a cop out
<bashfulrobot> unless there is a beer donation button.
<bashfulrobot> ha ha
<wxl> yeah i don't think release team have implemented that yet
<bashfulrobot> wxl: my IRC client had truncated the topic. :-p But I just expanded it.
<bashfulrobot> Should put the super important payment information at the front of the topic
<bashfulrobot> you know. Beer 1st, beta 2nd??? ha
<acheronuk> must be some app you can send international beer token with
<acheronuk> if there isn't, there should be!
<bashfulrobot> acheronuk: I'll setup the github repo shortly
<rbasak> beerchain.
<bashfulrobot> there we go.
<bashfulrobot> running ledger of beer owed
<rbasak> Free beer for miners.
<rbasak> (as opposed to minors, who should perhaps not be given free beer)
<acheronuk> :)
<infinity> rbasak: But kids love free stuff!
<infinity> bashfulrobot: I don't need anything from you right now.  Just waiting for the archive and britney to settle after putting blocks in place, then will spin up the first set of images.  From there, it should be vaguely self-service until you're ready to release on Thursday.
<bashfulrobot> perfect. Thank you infinity .
<acheronuk> infinity: so gstreamer-plugin-good and Qt 5.9.5 is not getting unblocked?
<acheronuk> Qt 5.9.4
<acheronuk> [08:38] <slangasek> acheronuk: well, I think it is important for us to resolve this transition in time for beta, let's continue aiming for that
<infinity> acheronuk: Oh, are we still waiting on a Qt? :/
<infinity> acheronuk: gst-plugins-good1.0 looks broken?
<acheronuk> [08:31] <slangasek> acheronuk: I've flagged it to the MIR team; I'm not on the MIR or security team so approving this into main is not up to me.  If we can't get the MIRs done in time for image mastering, we have two other options: pre-promote these packages into main while the MIR is in progress, with the possibility that they might be rejected and have to be dropped again; or revert the package in -proposed and
<infinity> Bunch of unsatisfiable deps.
<acheronuk> infinity: apparently needs that MIR?
<infinity> Evidently.
<acheronuk> [08:31] <slangasek> accept the ongoing transition without the new upstream gst-plugins-good (<-- Laney?)
<infinity> acheronuk: OTOH, Steve saying he'd like it to happen isn't the same as someone making it happen. :P
<infinity> acheronuk: Is the gst-plugin thing literally the only thing holding Qt up?
<acheronuk> which is why I had said:
<acheronuk> [08:37] <acheronuk> slangasek: ok. fwiw I have not yet seen any confirmed reports of the alleged issue with upgrades to mesa 18 without the bugfix in -proposed Qt, and by its nature the bug should not in theory affect a fresh install from iso or the live session. so if Qt does not move, at the moment seems a 'this might be buggy on upgrading a current system' in beta release notes could just about be acceptable
<infinity> acheronuk: If so, looks like the MIR is maybe sorted.  Lemme dig deeper.
<acheronuk> infinity: I can't 100% decipher update_output.txt, but if there is anything else, it's not obvious to me
<acheronuk> ok
 * infinity drops the freeze block again while sorting this.
<acheronuk> thanks. I don't want to hold things up too much, but if that did drop into place now, that would be great
 * acheronuk crosses fingers
<infinity> Oh, hrm.  That gst-plugins-good also accidentally pulls gst-qt5 back into main.  I'll mangle that.
<infinity> Alright, archive and seeds mangled.  Will have to wait a bit to see how it all settles.
<acheronuk> infinity: looks like gst-plugins-good rdep failing test here: https://autopkgtest.ubuntu.com/packages/ruby-gnome2/bionic/amd64
<acheronuk> :/
<acheronuk> but don't think the fault of gst-plugins-good
<infinity> acheronuk: Indeed.  I'll re-run a baseline on that.
<infinity> Though, the baseline run 5 days ago looked good.
<infinity> Oh, how quickly we break things. :/
<acheronuk> thanks
<infinity> These are some curious tests.
<infinity> It only installs rub2.3 sometimes.
<infinity> And only sometimes does rub2.3 fail.
<acheronuk> infinity: does this mean Qt would migrate? (from update_output_notest.txt) https://paste.ubuntu.com/p/dQ8xCZxJ5j/
<infinity> acheronuk: It does seem to imply that.
<acheronuk> right. I have never quite grasped what that "Trying easy from autohinter:" is actually doing
<infinity> Okay, hinted ruby-gnome2.  Seems equally broken in the release pocket. :/
<acheronuk> ick. thanks though
<infinity> acheronuk: The autohinter tries to group packages together based on interdeps and generates temporary "easy" hints.  Easy hints are hints that say "try all these together, and if the result is that the archive is no worse than when you started, you win".
<acheronuk> gotcha
<infinity> There are three classes of grouping hints.  hint-easy doesn't allow anything to regress, hint allows uninstallable trading (which is how KDE became briefly broken, cause vorlon did a 'hint' that ended up trading something else broken for your breakage instead), and force-hint, which allows you to regress the archive entirely and jam in broken bits.
<mwhudson> infinity: are you or some other AA going to delete freeipa from proposed? i thought there was agreement to do that and whenever i chase anything complicated looking on excuses it comes down to freeipa blocking curl and libunistring
<infinity> mwhudson: I'm not sure I was party to that discussion.
<mwhudson> infinity: fair enough
<infinity> I thought the freeipa issues were meant to be solved with the nss revert.  I guess not?
<mwhudson> oh maybe
<infinity> mwhudson: Also, if deleting it were enough to make other things migrate, deleting it wouldn't be necessary.
<infinity> mwhudson: So I assume you mean delete it and then upload a no-change rebuild of the release pocket version?
<mwhudson> i find keeping track of this sort of issue basically impossible
<mwhudson> infinity: yes, i think that is what i mean
<mwhudson> when did the nss revert happen?
<infinity> I could certainly do that and then undelete it.
<infinity> The nss revert was in early February, so it clearly didn't fix the freeipa tests. :P
<mwhudson> yeah
<infinity> mwhudson: Deleted and rebuild thrown at the archive.
 * infinity makes a mental note to undelete later.
<mwhudson> infinity: thanks
<mwhudson> infinity: well crap
<infinity> mwhudson: Oh, but a no-change rebuild doesn't build.
<mwhudson> infinity: throw it all into the sea?
<mwhudson> what's DAL in this context
<infinity> mwhudson: I'll put the other version back.  And let Timo sort it out after the sprint and beta.
<mwhudson> infinity: +1
<infinity> And done.
<infinity> acheronuk: Qt looks migratey.
<infinity> migratory?
<infinity> bashfulrobot: You'll have Beta1 images after the archive settles from this Qt migration.
<acheronuk> infinity: \o/
<acheronuk> thank you thank you thank you
<tsimonq2> Thanks!
<bashfulrobot> nice!
<bashfulrobot> infinity: You rule!
<mwhudson> what's the process for getting a package to migrate when it drops a binary package? get an AA to delete the binary package from release?
 * acheronuk slides beer tokens in infinity's direction
<bashfulrobot> infinity: So we are looking good for the Thursday date?
<tsimonq2> mwhudson: iirc yeah.
<tsimonq2> infinity: The topic isn't clear, do y'all accept bitcoin? :P
<tsimonq2> bashfulrobot: Now that the transition seems to be done and over with, looks like it, yeah.
<infinity> tsimonq2: The only fiat currencies I accept are USD and CAD.
<tsimonq2> infinity: USD and fake money? :P
 * tsimonq2 runs
<infinity> tsimonq2: And possibly a 124 Spider.
<tsimonq2> Hah :D
<tsimonq2> infinity: I thought you drove stick. :P
<infinity> tsimonq2: Are you implying that in some weird part of the world you can't get a Fiat Spider with a manual transmission?
<infinity> (You sure can here)
<tsimonq2> LOL
<tsimonq2> It's Canada, ofc you can.
<bashfulrobot> stick is the way to go. Not that you can almost even buy a car with it anymore
<bashfulrobot> Canada?
<bashfulrobot> whaaaaa
<bashfulrobot> ha ha
<infinity> I can't even imagine driving an underpowered lawnmower like that if I couldn't downshift and hold it on the red line.
<infinity> That's pretty much the *only* way to drive those go-karts.
<tsimonq2> :D
<tsimonq2> Wow, that's satisfying... https://i.imgur.com/nTd3A40.png
<mitya57> \o/
<tsimonq2> :D
<tsimonq2> [M
<tsimonq2> F[M
<tsimonq2> (what)
<bashfulrobot> tsimonq2: You just lost me there. ha
<slangasek> mwhudson, infinity: it's not about removing freeipa from -proposed, but from the release pocket.  Which I would do, just as soon as I can figure out why britney claims abi-monitor and ros-simulators are uninstallable on amd64 <sigh>
<acheronuk> where is the vcs for our casper>
<acheronuk> ?
<infinity> slangasek: If it's on amd64-only, it's arch:all packages it's whining about, if that helps.
<slangasek> infinity: yeah, but ros-simulators only depends on ros-robot and gazebo9
<infinity> slangasek: And installing both of those pulls in 744 packages, so fair shot that there's a broken combo in there.
<infinity> Oh, "only" 604 without recommends.
<infinity> slangasek: Another hint is that updating curl3 alone *doesn't* break ros-simulators-dev or abi-monitor, but updating "curl3/7.58.0-2ubuntu2 xmltooling/1.6.4-1ubuntu2" together does.
<slangasek> ahahaha <stab>
<infinity> slangasek: Did you desperately want this in for B1, or can we revisit Thursday?
<infinity> (I don't really want to hold these folks up any longer unless you see the fix jumping out at you)
<slangasek> infinity: I don't think you should delay the beta; but also, per previous rants, I have adjusted the freeze hint to not freeze base system components for an opt-in milestone
<infinity> slangasek: I think our rants on that topic will continue to be at odds until we just stop having opt-in milestones entirely.
<infinity> (Honestly, I'd rather just tell flavours they can't have them than have them testing against moving targets because ermagerd can't wait two days to migrate stuff)
<tsimonq2> (I'd rather have them and wait two days for the things to migrate than have them taken away)
<infinity> tsimonq2: Yes, Steve's telling you that combination isn't an option in his mind.
<infinity> tsimonq2: Which leaves "no milestones" or "base changing during milestones".
<infinity> tsimonq2: But we really should revisit the honest question of "what value do you get from milestones that you wouldn't get from dedicating one day a month to testing dailies?"
<tsimonq2> infinity: It may sound weird but I prefer the latter.
<infinity> tsimonq2: Because, other than publishing them, which encourages people to install from stale ISOs (ick), that's all you're doing.
<slangasek> given how many dozens of hours have been spent trying to get this transition ready, and the risk of setbacks to the transition from stray uncoordinated uploads, I don't really have any sympathy for the view that not allowing a milestone freeze to trump the transition is unreasonable impatience
<tsimonq2> slangasek: I'm not disagreeing with you.
<slangasek> tsimonq2: I know /you're/ not, but infinity is :)
<infinity> slangasek: Yeah, I absolutely am.  Because you're using *this* transition to argue for a global policy.  If intersecting packages aren't frozen, we're saying "yeah, don't worry, Qt, glibc, glib, and GTK all changed between your first spin and your third, but that probably won't set back your testing any".
<infinity> Y'know, cause those are all possiblities in the intersecting base set.
<tsimonq2> infinity: I continue to believe that testing ISOs one day a month doesn't gather as much momentum as a "Beta" because that signals we're in a certain stage of the cycle.
<infinity> slangasek: Then again, you and I agree (I think) that these early milestones are about as valuable as "pick a daily and test it", so what we have is a strangely unresolvable venn diagram of agreement between you, me, and the flavour leads. :)
<slangasek> heh, quite
<tsimonq2> Right, heh
<infinity> tsimonq2: So, call your fourth month of daily testing "beta".
<slangasek> and those are all packages with CI via autopkgtests, and while there is always risk of regression, I don't accept the notion that freezing these packages to ensure the beta candidates are stable in between, only to have massive changes drop the day after beta, is actually valuable to anyone
<infinity> (To be honest, I'd be happier if we did exactly what we do now, including with the ISO tracker, but then didn't release the result... It's the publishing that I greatly disagree with)
<infinity> Milestones have a very negative effect socially, as people are more inclined to install the "tested" Alpha2 than the daily that comes 3 weeks later and fixed a bunch of bugs.
<infinity> Or, as is often the case, the daily that comes two days later and fixed all the bugs found but not deemed RC enough during the ISO testing. :P
<tsimonq2> infinity: "ZOMGWTFROFLCOPTER, this beta wasn't tested at all, why did they let this thing release?!?" or "These flavors didn't release at the same time, what's the point?!?" are two possibilities. I don't personally care about having a set date, or an ISO that stays there for longer than the time it takes for the next ISO to release, for that matter. Just that we have those stages because I'm
<tsimonq2> told it's good for marketing. :P
<tsimonq2> Hell, I wouldn't even care if we did like a biweekly testing coordination thing and just eliminate what we have now. As long as we have stages and not just "prerelease" and "release"
<tsimonq2> infinity, slangasek: I mean, can we find common ground *there*?
<infinity> tsimonq2: Coordinated testing is something I wouldn't even need to get involved in.
<tsimonq2> infinity: It depends on how we do it, but yeah.
<infinity> tsimonq2: (Though I could put it on the release schedule for you, like I do with milestones today, so you don't bikeshed about the date)
<infinity> tsimonq2: Then, on the same date that would have been Alpha2, instead you say "this is Month2 ISO testing week", and flavours flood the ISO tracker with test results, and action said results after the facgt.
<infinity> tsimonq2: All that removes from the current state of affairs is the "blessed image", but my contention has always been that the blessed image does more harm than good.
<infinity> And that's not just guessing, we field a lot of bugs from people who install from milestone media, just to close them with "yes, that bug was fixed three days later".
<infinity> Super not helpful.
<tsimonq2> I'm open to trying it for 18.10 and then evaluating how things went from there.
<tsimonq2> So, consider me (somewhat) convinced.
<tsimonq2> infinity: Is this a decision the Release Team is "just going to make" or should I (or you! :P) send something to the ML?
<infinity> tsimonq2: I mean, it's a decition that Canonical *could* "Just Make", as it's about our human resource involvement in the community process.  But no, I'm not threatening to do that.
<infinity> tsimonq2: But it's no secret that we've wanted to back away from this process for years, and we've been trying to gently (and sometimes not) argue in that direction, and lead by example.
<infinity> decition?  Did apw infect my fingers?
<infinity> decision.
<tsimonq2> infinity: Now to be completely clear here, is this a Canonical decision or an Ubuntu Release Team (or cdimage team, whatever Ubuntu hat you'd like to wear) decision?
<infinity> tsimonq2: The release team, as a community entity could absolutely make this decision (and that's where I'd prefer it be made).
<tsimonq2> If no resource allocation would change (less resources needed for a Blessed Image), then why would it need to be a Canonical decision?
<tsimonq2> RIght
<tsimonq2> *Right.
<tsimonq2> I agree.
<infinity> tsimonq2: Cause then it's not "Canonical is taking away toys", but "the community has decided this is more sane".
<tsimonq2> That's exactly where I was going with that.
<infinity> tsimonq2: The community release team can't force Canonical to spend time/money, but they sure can ask them to spend less. :)
<tsimonq2> Heh, true.
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Bionic Beta 1] (20180306.1) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Bionic Beta 1] (20180306.1) has been added
<infinity> tsimonq2: I think with something as complex as the Debian/Ubuntu archive (and moreso us, because we generate multiple flavours), no matter how good our CI gets (and it can get better), it's a pipe dream to be "always releasable", but we very much should be "always testable".
<infinity> tsimonq2: So, having flag days where we say "okay, for the next two days, spend your time testing and fixing your accumulated cruft" helps keep things in shape, and that's really what milestones have been doing for us for years.
<tsimonq2> infinity: Right, and I can agree with that.
<tsimonq2> infinity: (I'm also curious to see what ideas you have for how Ubuntu's ProposedMigration CI can be improved. :P)
<infinity> I don't have a bunch of stellar ideas, but it's obviously imperfect, thus can be improved.
<tsimonq2> That's for sure.
<mwhudson> slangasek: aah ok
<mwhudson> acheronuk: no vcs for ubuntu casper as far as i'm aware
<mwhudson> acheronuk: and as it was me that made the last upload, if there is a vcs, it's out of date :-p
<tsimonq2> "no vcs" aww come on :/
<mwhudson> tsimonq2: ok, the canonical vcs is the ubuntu archive!!
<cyphermox> err, something got busted because there definitely was one
<cyphermox> but regardless, not that big a deal, the archive is your vcs.
<tsimonq2> mwhudson: Lowercase "c" I hope. :P
<mwhudson> cyphermox: oh hmm
<infinity> cyphermox: debian/control doesn't know about it, so there isn't one.
<infinity> (Pretty sure I never committed to anything but the source package)
<slangasek> 2018/03/06 23:43:39.397222 cmd.go:156: cannot read /proc/self/exe: readlink
<slangasek> wut
<infinity>   * debian/control: Drop Vcs-Bzr:, which does not exist any more.
<infinity>  -- Martin Pitt <martin.pitt@ubuntu.com>  Tue, 19 Apr 2016 15:53:13 +0200
<cyphermox> infinity: lp:casper seems to think otherwise, and I thought I used that before
<infinity> cyphermox: Blame pitti, then. :)
<cyphermox> yes
<infinity> cyphermox: lp:casper trunk last changes 2010-09-28 ... I can see why, 6 years later, pitti decided it might be dead.
<cyphermox> no, lp:ubuntu/casper was dea
<cyphermox> but also grossly outdated, for sure
<infinity> https://code.launchpad.net/casper
<cyphermox> I saw.
<infinity> That's lp:casper, not lp:ubuntu/casper
<slangasek> ah, it's the channel thing
<cyphermox> yes
<cyphermox> infinity: there was also a "comment" on that page. but whatever, this isn't really important
<infinity> I think I need a big bowl o' vietnamese.
<cyphermox> lucky.
#ubuntu-release 2018-03-07
 * cyphermox has cinderella syndrome and logs off.
<slangasek> fossfreedom: hi, so the livecd-rootfs change has landed to install snaps from marked channels, for future-proofing, as per https://wiki.ubuntu.com/UbuntuSeededSnaps; you'll need to open the stable/ubuntu-18.04 branch for ubuntu-budgie-welcome (after which you can close it again)
<infinity> budgie-welcome?
<infinity> Does it come with all the same fun that mate-welcome does?
<slangasek> unknown to me
<slangasek> but it currently causes a build failure
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Bionic Beta 1] (20180306.1) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Bionic Beta 1] (20180306.1) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Bionic Beta 1] (20180306.1) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Bionic Beta 1] (20180306.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Bionic Beta 1] (20180306) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Bionic Beta 1] (20180306) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Bionic Beta 1] (20180306.1) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Bionic Beta 1] (20180306.1) has been added
<mwhudson> slangasek: would it be productive for me to stare at update_output.txt re: those packages you were complaining about?
<slangasek> mwhudson: I got it sorted, adding cmake to the hint made everything happy
<mwhudson> slangasek: woot
<slangasek> I believe it will all migrate in the next run
<tsimonq2> \o\ /o/ \o\ /o/
<slangasek> which I only worked out via lp:~laney/ubuntu-archive-tools/update-output-helper
<slangasek> the beta1 freeze also blocks the libunistring freeze now, though.  do lubuntu want that unblocked?
 * mwhudson runs watch -n 60 -g 'curl --silent http://archive.ubuntu.com/ubuntu/dists/bionic-proposed/{main,universe,restricted,multiverse}/source/Sources.gz | zcat | grep-dctrl -sPackage . | wc -l'
<wxl> tbh i doubt we care too much slangasek :)
 * tsimonq2 thinks that lp:ubuntu-archive-tools should be converted to Git. :P
<slangasek> wxl: considering this is a library transition that actually affects /your/ packages, I would be looking for an affirmative indication that you want it accepted before beta, rather than just "don't care"
<wxl> slangasek: put differently, i think lubuntu would be fine either way, but feel free to unblock it.
<bashfulrobot> slangasek: hi there, I might be able to help out with your question to fossfreedom.
<slangasek> bashfulrobot: if you have collaborator rights on the snap
<bashfulrobot> I'm the one who published it originally. I have access to that account. I'm also the one who has interacted with the form to get the classic confinement and everything done. <---- slangasek
<slangasek> k then :)
<slangasek> bashfulrobot: then please open the 'ubuntu-18.04' branch, then close it again
<slangasek> bashfulrobot: once that's done, someone can kick off another candidate build for beat1
<slangasek> beta1
<bashfulrobot> slangasek: are you talking about within the snap dashboard? Or another location?
<mwhudson> what's with all the failing ruby autopkgtests
<tsimonq2> s/ruby/node/
<mwhudson> and not or
<tsimonq2> heh right
-queuebot:#ubuntu-release- New source: ukwm (bionic-proposed/primary) [1.1.7-0ubuntu1]
<tsimonq2> handsome_feng: ^^^^
<handsome_feng> tsimonq2: Thanks!
<tsimonq2> handsome_feng: np!
-queuebot:#ubuntu-release- New source: peony-extensions (bionic-proposed/primary) [1.1.1-0ubuntu1]
<infinity> mwhudson: Do they take the form of ruby (perhaps just 2.3) whining about not being able to load external bits?
<infinity> mwhudson: If so, I ran into that earlier, and it warrants looking at, I think (or dropping ruby2.3, if that was planned for bionic)
<mwhudson> infinity: yes, seems so
<infinity> mwhudson: I suppose it's plausible that ruby's custom dlopen-like loader is broken with glibc 2.7, but because we only trigger direct rdeps, not rdeps of rdeps, we didn't get coverage on that.
<infinity> mwhudson: Anything that grubs around at the ELF level trying to be tricky is skating on thin ice.
<infinity> *cough*ffi*cough*
<mwhudson> haha
<infinity> s/2.7/2.27/
<infinity> That missing 2 made that a very confusing statement.
-queuebot:#ubuntu-release- New source: kylin-video (bionic-proposed/primary) [1.1.5-0ubuntu1]
<mwhudson> heh heh http://autopkgtest.ubuntu.com/packages/g/golang-github-hashicorp-atlas-go/bionic/amd64
-queuebot:#ubuntu-release- Unapproved: proftpd-dfsg (xenial-proposed/universe) [1.3.5a-1build1 => 1.3.5a-1.1] (no packageset)
<tsimonq2> That sponsoree for proftpd-dfsg has been waiting three months for someone to upload that, so it'd be good if someone could process that fairly soon.
<flocculant> infinity tsimonq2 - interesting discussion re milestones
<infinity> tsimonq2: Was that a sync from Debian?
<infinity> tsimonq2: If not, you misspelled '1ubuntu1'
<tsimonq2> infinity: sigh, indeed I did.
<tsimonq2> infinity: There, reject the oldest one in the queue, I uploaded one with the right version number.
-queuebot:#ubuntu-release- Unapproved: proftpd-dfsg (xenial-proposed/universe) [1.3.5a-1build1 => 1.3.5a-1ubuntu0.1] (no packageset)
<tsimonq2> infinity: ^^^ better, right?
<tsimonq2> flocculant: I'll probably go over the notes this weekend and draft a proposal or something.
<flocculant> tsimonq2: works for me - I know I often tell you my position, but it does come from thought, not just to make you lol a bit ;)
 * flocculant particularly likes not publishing them
<tsimonq2> flocculant: heh :)
<slangasek> bashfulrobot: yes, it can be done through the snap dashboard.  Maybe it can also be done through the snapcraft CLI, but I'm not sure what the command would be there
<slangasek> mwhudson, infinity: get ruby-defaults to migrate, so ruby in bionic release actually points to ruby2.5; then retest with ruby2.5; then tell the ruby maintainers to fix their interpreter package so that transitions are managed correctly like python, instead of leaving us with a set of packages which is installable but inconsistent.
<slangasek> flexiondotorg: hi, same thing for ubuntu-mate as for ubuntu-budgie above: pulsemixer needs an ubuntu-18.04 branch opened in the snap store so that the liveCD can install it in a way that's conformant with the seeded snap policy
<mwhudson> slangasek: ahah
<mwhudson> step 1 looks like heaps of fun
<flexiondotorg> slangasek: Do you mean a track?
<slangasek> flexiondotorg: no, a branch
<flexiondotorg> What ia the purpose of the branch?
<slangasek> flexiondotorg: https://wiki.ubuntu.com/UbuntuSeededSnaps#Channel_availability
 * flexiondotorg reads... 
<slangasek> flexiondotorg: it needs to be opened once and then you can close it; but if it's never been opened, the snap client can't pin the branch, so there is no escape hatch if in the future you need to diverge from the 'stable' channel
<bashfulrobot> slangasek: thanks for the clarification. I just wasn't sure if you were referencing that or else where, say LP.
<xnox> jamespage, pinging slangasek to review percona stuff....
<bashfulrobot> slangasek: I must be missing something. I don't see anywhere to create a branch in the snap dashboard. Still looking. Or I'm bind.
<flexiondotorg> slangasek: pulsemixer branch for ubuntu-18.04 has been opened and closed.
<flexiondotorg> bashfulrobot: You need to use snapcraft.
<flexiondotorg> `snapcraft release --help`
<acheronuk> when is the deadline for deciding to include snaps or not?
<slangasek> flexiondotorg: thanks, retrying the ubuntu-mate build
<flexiondotorg> slangasek: I assume I'll need to do the same for other seeded snap on Ubuntu MATE.
<slangasek> flexiondotorg: heh, yes
<flexiondotorg> doing it now....
<slangasek> flexiondotorg: sorry, I hadn't checked the seeds
<flexiondotorg> slangasek: All done.
<flexiondotorg> slangasek: Here comes some build logs for the armhf build failues we discussed yesterday.
<flexiondotorg> https://launchpadlibrarian.net/359270302/buildlog_snap_ubuntu_xenial_armhf_software-boutique_BUILDING.txt.gz
<slangasek> wgrant: ^^
<slangasek> :)
<flexiondotorg> https://launchpadlibrarian.net/359118374/buildlog_snap_ubuntu_xenial_armhf_software-boutique_BUILDING.txt.gz
<flexiondotorg> https://launchpadlibrarian.net/359270343/buildlog_snap_ubuntu_xenial_armhf_ubuntu-mate-welcome_BUILDING.txt.gz
<flexiondotorg> https://launchpadlibrarian.net/359118572/buildlog_snap_ubuntu_xenial_armhf_ubuntu-mate-welcome_BUILDING.txt.gz
<flexiondotorg> slangasek wgrant Those failures were alongside successful builds on amd64, arm64 and i386.
<bashfulrobot> flexiondotorg: thanks for the clarification!!
<flexiondotorg> bashfulrobot: yw :-)
<wgrant> slangasek, flexiondotorg: Isn't that just the snapcraft !x86 SRU regression?
<wgrant> https://github.com/snapcore/snapcraft/commit/84aaac591a0a3578d91e2a0e25bfb9ce8e546a83
<bashfulrobot> slangasek: I released to stable/ubuntu-18.04 for 32/64bit
<bashfulrobot> So we should be good to trigger the build
<bashfulrobot> I'll leave the branch for now until we know the seeds work, then I'll remove it later.
<bashfulrobot> https://www.irccloud.com/pastebin/Sa5T5Vxt
<bashfulrobot> I'm heading off to bed, but will check in tomorrow slangasek . Thanks for the heads up.
 * bashfulrobot passing out
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (trusty-proposed/partner) [191.0.0-0ubuntu1~14.04.0 => 191.0.0-0ubuntu2~14.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (xenial-proposed/partner) [191.0.0-0ubuntu1~16.04.0 => 191.0.0-0ubuntu2~16.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (artful-proposed/partner) [191.0.0-0ubuntu1~17.10.0 => 191.0.0-0ubuntu2~17.10.0] (no packageset)
<xnox> slangasek, https://code.launchpad.net/~xnox/britney/crushing-failure-and-despair/+merge/340940
<xnox> https://bugs.launchpad.net/britney/+bug/1753940
<ubot5`> Ubuntu bug 1753940 in snapd (Ubuntu) "go vet causing Crushing failure and despair" [Undecided,New]
<xnox> philroche, ^ that's the bug to watch.... a move on above, should make systemd migrate
<sil2100> LocutusOfBorg: hey! re: virtualbox, https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1746316/comments/6
<ubot5`> Ubuntu bug 1746316 in virtualbox (Ubuntu Artful) "[SRU] VirtualBox needs Security Patches" [Undecided,In progress]
<cyphermox> could someone on the release team please review my MP?  https://code.launchpad.net/~cyphermox/britney/+git/britney2-ubuntu/+merge/340864
<cyphermox> also, https://code.launchpad.net/~cyphermox/ubuntu-archive-tools/component-mismatches-mir/+merge/340939
<slangasek> bashfulrobot: now having released to stable/ubuntu-18.04, you probably want to close that branch again so you don't have to do additional work to keep it in sync with stable :)
<xnox> slangasek, do you not agree with merging https://code.launchpad.net/~xnox/britney/crushing-failure-and-despair/+merge/340940 ? please =)
<Laney> it is merged
<slangasek> + This package contains the debugging symbols for the Percona XtraDB Cluster binaries.
<slangasek> jamespage: ^^ no new -dbg packages in Ubuntu for debug symbols; nack on this
<slangasek> jamespage: ah; it's not a regression vs. percona 5.6, despite debian/control being reordered and largely undiffable.  But can we get this fixed with priority?
-queuebot:#ubuntu-release- New: accepted percona-xtradb-cluster-5.7 [source] (bionic-proposed) [5.7.20-29.24-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (artful-proposed) [191.0.0-0ubuntu2~17.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (xenial-proposed) [191.0.0-0ubuntu2~16.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (trusty-proposed) [191.0.0-0ubuntu2~14.04.0]
-queuebot:#ubuntu-release- New binary: percona-xtradb-cluster-5.7 [s390x] (bionic-proposed/universe) [5.7.20-29.24-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: percona-xtradb-cluster-5.7 [ppc64el] (bionic-proposed/universe) [5.7.20-29.24-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: percona-xtradb-cluster-5.7 [amd64] (bionic-proposed/universe) [5.7.20-29.24-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: percona-xtradb-cluster-5.7 [i386] (bionic-proposed/universe) [5.7.20-29.24-0ubuntu1] (no packageset)
<xnox> Laney, but I am a twat and proposed invalid thing
<Laney> naughty xnox
-queuebot:#ubuntu-release- New binary: percona-xtradb-cluster-5.7 [armhf] (bionic-proposed/universe) [5.7.20-29.24-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: percona-xtradb-cluster-5.7 [arm64] (bionic-proposed/universe) [5.7.20-29.24-0ubuntu1] (no packageset)
<ginggs> would someone please bump in vorlon's hints? 'force-badtest r-cran-curl/3.1-2/arm64'
<slangasek> ginggs: why, instead of disabling the test on arm64?
<slangasek> ginggs: and why syncing a new version of the package that is identical to what I already had?
<ginggs> slangasek: 1) I didn't notice it had previously failed on arm64 until after I uploaded. 2) So that other people don't have to spend time on it
<slangasek> ginggs: I don't see why anyone would be spending any time on this, post-FF
<slangasek> ginggs: including you
<Odd_Bloke> doko: I was told to ping you about the Ruby transition; how close are we to all Ruby scripts using 2.5 by default in bionic?
<Odd_Bloke> doko: I'm more-reliably-informed that I can bug other people instead, so never mind. :)
<Odd_Bloke> xnox: http://paste.ubuntu.com/p/7Fc7bW29K8/
<xnox> rbalint, ^
<bashfulrobot> slangasek: sounds good. Appreciate the pointer (re: closing branch).
-queuebot:#ubuntu-release- Unapproved: sahara-dashboard (xenial-proposed/universe) [4.0.0-1 => 4.0.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New source: golang-1.10 (artful-backports/primary) [1.10-1ubuntu1~17.10.1]
-queuebot:#ubuntu-release- New source: golang-1.10 (xenial-backports/primary) [1.10-1ubuntu1~16.04.1]
<Odd_Bloke> slangasek: xnox: If there's a specific autopkgtest that won't run on Ubuntu (for good reasons), is uploading an Ubuntu version that drops that test the appropriate thing to do?
<nacc> Odd_Bloke: I've done that for some packages, I've also added a quilt patch that skips it with a reason, if possible
<slangasek> Odd_Bloke: yes
<bashfulrobot> @infinity: could you possibly kick off a build for Ubuntu budgie? We had to add a branch for our seeded snap package. But we couldn't kick it off from the QA ISO tracker.
<slangasek> bashfulrobot: I'll take a look
<bashfulrobot> Thanks!
<Odd_Bloke> nacc: quilt patch patching debian/tests/foo?
<bashfulrobot> slangasek: quick side question. These branches for seeded snaps. Are they just a one time thing for seeded snaps? Or what is the scenario in which these branches need to be created for seeded snaps?
<nacc> Odd_Bloke: oh it depends on the tests, i meant like if the dep8 is just running upstream tests, they might be in the source
<nacc> Odd_Bloke: if not, then no quilt patch, obviously
<Odd_Bloke> Ah, OK, I didn't think so but was just checking.
<Odd_Bloke> This is just a shell script; would deleting it be the right path, or adding an exit 0 with an explanatory comment?
<nacc> Odd_Bloke: you're removing all the tests?
<Odd_Bloke> nacc: There are two shell script tests; one of them is useful on Ubuntu, the other would require a multiverse package to run on Ubuntu.
<Odd_Bloke> (This is vagrant, FWIW.)
<slangasek> bashfulrobot: the branch needs to be opened for each Ubuntu release in order to create images for that release that include that snap
<nacc> Odd_Bloke: ah I see; then yes, I imagine dropping it with a changelog entry is probably sufficient (is this debian delta?)
<Odd_Bloke> Yeah, this would be delta from Debian.
<Odd_Bloke> nacc: Cool, thanks for the guidance.
<nacc> Odd_Bloke: yeah, that seems appropriate to me
<Odd_Bloke> slangasek: So my next question, in the spirit of being thoughtful about packages are already in -proposed: Vagrant is currently failing due to the Ruby transition (as discussed at length :p), but the autopkgtests will continue to fail after that's resolved; I'm fixing that secondary failure.  Should I wait to upload until the first blockage is cleared?
<bashfulrobot> slangasek: okay. Thank you for the clarification. So basically this would be a one-time thing for 18.04. And then a one-time thing for 18.10, and then another thing for 19.04 and forward. Per seeded snap. Open branch. Perform build. Remove branch. Got it.
<slangasek> Odd_Bloke: I don't see any reason to wait.  Which source package is this for?  vagrant itself, or vagrant-mutate which blocks qemu?
<Odd_Bloke> vagrant itself.
<slangasek> bashfulrobot: exactly
<slangasek> Odd_Bloke: yeah, vagrant/2.0.2+dfsg-2build1 isn't going anywhere on its own right now, no need to wait because it's not magically resolving itself in the near term.  *however*, we should trigger some --all-proposed retests of vagrant, either now or later
<Odd_Bloke> Ack; just uploaded.
<Odd_Bloke> cpaelzer: FYI: ^
<Odd_Bloke> ruby-turbolinks could use a test rebuild with the ruby-defaults in -proposed.
<bashfulrobot> slangasek:
<bashfulrobot> perfect.
<cpaelzer_> Odd_Bloke: slangasek: already triggered the all proposed test about two hours ago
<bashfulrobot> have a great day. let me know if you need anythign else on the ISO build
<cpaelzer_> checking results now ...
<cpaelzer_> no new results in yet
<slangasek> cpaelzer_: then I don't think you successfully triggered
<slangasek> because queues are quite empty
<cpaelzer_> yes I just checked the queues, it is not there
<Odd_Bloke> This specific upload was also ~2 hours ago, so could have missed a retrigger anyway.
<cpaelzer_> Odd_Bloke: it will not retrigger the test of "others"
-queuebot:#ubuntu-release- New: accepted rax-nova-agent [amd64] (bionic-proposed) [2.1.12-0ubuntu2]
<Odd_Bloke> cpaelzer_: Oh, the all-proposed test of vagrant?
<cpaelzer_> I found it
<cpaelzer_> Odd_Bloke: the rebuild of yours made the trigger target unavailable
<slangasek> xnox: do you have any insight into whether the rails autopkgtest failure is broken test vs broken code?
<cpaelzer_> in queue now slangasek / Odd_Bloke
<Odd_Bloke> Thanks!
<cpaelzer_> fixed my triggers to use the new vagrnat rebuild properly (all-proposed takes care of that anyway)
<cpaelzer_> so test should (tm) succeed and qemu be good for now
-queuebot:#ubuntu-release- New: accepted golang-1.10 [source] (artful-backports) [1.10-1ubuntu1~17.10.1]
-queuebot:#ubuntu-release- New: accepted golang-1.10 [source] (xenial-backports) [1.10-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Bionic Beta 1] (20180307) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Bionic Beta 1] (20180307) has been added
-queuebot:#ubuntu-release- New binary: golang-1.10 [i386] (artful-backports/universe) [1.10-1ubuntu1~17.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-1.10 [s390x] (artful-backports/universe) [1.10-1ubuntu1~17.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-1.10 [s390x] (xenial-backports/universe) [1.10-1ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-1.10 [ppc64el] (artful-backports/universe) [1.10-1ubuntu1~17.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-1.10 [ppc64el] (xenial-backports/universe) [1.10-1ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-1.10 [amd64] (artful-backports/universe) [1.10-1ubuntu1~17.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-1.10 [amd64] (xenial-backports/universe) [1.10-1ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-1.10 [i386] (xenial-backports/universe) [1.10-1ubuntu1~16.04.1] (no packageset)
<cpaelzer> slangasek: on the seed changes, just today we realized that openbsd-inetd should also be demoted
<cpaelzer> it has nothing holding it in main than the seed itself
<cpaelzer> and all it did in the past is no more important
<cpaelzer> so I'll make this part of the MP as well
<cpaelzer> if you have concerns, please let me know
-queuebot:#ubuntu-release- New binary: golang-1.10 [arm64] (artful-backports/universe) [1.10-1ubuntu1~17.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-1.10 [arm64] (xenial-backports/universe) [1.10-1ubuntu1~16.04.1] (no packageset)
<acheronuk> [23:43] <mwhudson> tsimonq2: ok, the canonical vcs is the ubuntu archive!!
<acheronuk> a bit hard to do a merge request against that in lp
<acheronuk> I guess a bug report and debdiff them
<acheronuk> *then
-queuebot:#ubuntu-release- New binary: golang-1.10 [armhf] (artful-backports/universe) [1.10-1ubuntu1~17.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-1.10 [armhf] (xenial-backports/universe) [1.10-1ubuntu1~16.04.1] (no packageset)
<tsimonq2> acheronuk: git-ubuntu, hint hint
 * tsimonq2 nudges nacc
<tsimonq2> :)
<nacc> tsimonq2: yeah yeah yeah
<nacc> tsimonq2: we're doing a 1% phasing of main right now
<nacc> (currenlty reimporting everything in our whitelist + 1% of main)
<acheronuk> tsimonq2: lol. I knew someone would pipe up with that!
<nacc> depending on how that goes (it's progressing nicely, but will take a few more days to finish)
<nacc> we'll up the phasing to 2% next week :)
<tsimonq2> nacc: Ah ok. ooc, how do you determine these percentages?
<Odd_Bloke> slangasek: Also: https://github.com/rails/rails/commit/be9dc78fccc80bb5045c67b435b5c7e36ea8a296
<acheronuk> tsimonq2: (done/notdone)*100
 * acheronuk hides
<nacc> tsimonq2: determine as in which way? the value of them (we specify it to the scripts) or what they mean (md5sum(srcpkg name) < phasing percentage * 2^128, just like the -updates phasing)
<nacc> tsimonq2: the 1% is to see how the phasing affects the package count, as well as time, and space on Launchpad
<tsimonq2> Ah ok
<nacc> we also have a blacklist and whitelist, so the phasing percentage is not a direct indicator yet
<nacc> but our short-term goal is 100% of main
<tsimonq2> But like, 1% from an alphabetical list? How is this sorted?
<tsimonq2> Ah ok
<nacc> tsimonq2: no sorting necessary
<nacc> tsimonq2: md5sum(srcpkg name) is a numerical value
<nacc> tsimonq2: compare that to 1% of 2^128
<nacc> and statistically we get ~1% of all source packages, assuming a relatively even distribution (not entirely true, but is an approximation)
<nacc> actually, i think md5sum might be relatively uniform
<tsimonq2> Huh ok
<nacc> (2^128 being the maximum md5sum)
<tsimonq2> nacc: Seems like an algorithm that has a name... what might that be? :)
<nacc> tsimonq2: https://wiki.ubuntu.com/PhasedUpdates
<nacc> tsimonq2: update-manager section
<tsimonq2> Interesting.
<tsimonq2> OK, cool.
<wxl> bashfulrobot: you think you're going to be able to get all your testing in before end ot the day or are you thinking a late release thursday (or a potential delay, whcih might be good for kubuntu)?
<wxl> oh jeez no lubuntu next images. i trust i need to get you to add them, infinity?
<infinity> wxl: Oh, I assumed Next wasn't happening for milestones, since we'd discussed that it probably shouldn't happen for release.  I can add it for the Beta and spin 'em up.
<wxl> infinity: it looks like we had them for milestones only for artful, so i think we're on the same page there.
<infinity> wxl: Building now.
<wxl> infinity: thank you, sir :)
<infinity> (Well, in one minute when the rebuild job ticks over)
<infinity> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/bionic/lubuntu-next
<wxl> infinity: don't they usually show on the tracker as being in a building state?
<infinity> wxl: It does on the daily milestone.   It won't show at all on the Beta milestone until one has been built (this one) :P
<wxl> infinity: weird behavior, but ok :)
<infinity> wxl: Well, I could have done it in a different order by adding one of the older images to the beta milestone and then triggering the rebuild, which would give you the output you expected.
<infinity> wxl: But I don't like adding an image to a milestone for the express purpose of obsoleting it seven seconds later.
<infinity> (Both for reasons of confusion and efficiency)
<wxl> infinity: sounds like the behavior is no different, but it's less obvious with the dailies.
-queuebot:#ubuntu-release- Unapproved: systemd (trusty-proposed/main) [204-5ubuntu20.26 => 204-5ubuntu20.27] (core)
<infinity> wxl: It perhaps helps if you realise there's no difference between "daily" and "milestone", except that when a milestone is active, any daily built that's listed in the manifest *also* gets posted to the milestone.
<infinity> wxl: So, I added next to the manifest, triggered a daily rebuild, and when it posts, it'll show up on both.
<wxl> infinity: yeah, that's whta i was alluding to.
<wxl> infinity: i'll quit bothering you now :)
<bashfulrobot> wxl: we are literally just having a discussion about this. There are some pros to delaying since our ISO was just built today due to a delay with a snap seed. I'm just confirming with our team lead.
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop amd64 [Bionic Beta 1] (20180307) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop i386 [Bionic Beta 1] (20180307) has been added
<wxl> bashfulrobot: alright. ping me when you get it figured out, please?
<infinity> bashfulrobot: If there's a delay, I assume it would just be a day, right?
<infinity> bashfulrobot: I'm fine with releasing on Friday instead of Thursday.  Don't want to keep the soft freeze in place much longer than that.
<bashfulrobot> infinity:  I think so. I wouldn't want to delay any later than that.
<bashfulrobot> wxl: absolutely.
<bashfulrobot> ok, wxl, infinity
<bashfulrobot> tsimonq2:
<bashfulrobot> Are we all in agreement to delay until Friday eve?
<tsimonq2> ACK.
<bashfulrobot> ACK on our part.
<bashfulrobot> Just had to respin our ISo due to a bug in our snap
<bashfulrobot> Quick Q - is this the right place to request permissions to http://iso.qa.ubuntu.com/qatracker (to trigger a new build)? Right now fossfreedom is the only one who can do this on behalf of ubuntu Budgie.
<bashfulrobot> tsimonq2 / infinity ^^ You fine gents may know the answer. ð
<tsimonq2> bashfulrobot: There's an LP team you need to be added to.
<flexiondotorg> bashfulrobot infinity Ubuntu MATE have expressed our intention to participate in Beta 1 bit we don't have isos.
<flexiondotorg> Can anything be done to spin them please?
<bashfulrobot> infinity: had the traditional nusakan stuff been done for mate? Can we squeek that in?
<bashfulrobot> flexiondotorg: FYI - we are likely deferring beta until Friday evening (FYI).
<jbicha> infinity: today's ISO builds still identify as Alpha in their metadata
<flexiondotorg> We can certainly bo the QA by Friday. So if iso can be produced we've got the QA team ready.
-queuebot:#ubuntu-release- New binary: linux [s390x] (bionic-proposed/main) [4.15.0-12.13] (core, kernel)
 * bashfulrobot defers to infinity for nusakan setup.
<bashfulrobot> tsimonq2: Who admins that team?
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Bionic Beta 1] has been updated (20180307.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Bionic Beta 1] has been updated (20180307.1)
<tsimonq2> bashfulrobot: I think you can generally assume ~ubuntu-cdimage members that work for Canonical.
<bashfulrobot> ty
<bashfulrobot> slangasek: I noticed that you are a member of the cd-image team - are you guys the right people to request access to http://iso.qa.ubuntu.com/qatracker?
<bashfulrobot> Well access in the capacity to generate rebuilds on the ISO
<bashfulrobot> not just login for review
<bashfulrobot> slangasek: I know you are at the sprint - so this is not critical, nor a blocker.
<bashfulrobot> slangasek: when you happen to read this - ideally we would like to make https://launchpad.net/~ubuntu-budgie-release a member, however if there is a policy against nesting a group (maybe security concerns), could we add myself?
<bashfulrobot> fossfreedom might be handy to pop an "aye" in here for approval to do so on behalf of Ubuntu Budgie.
<infinity> jbicha: Yeah, not fussed about them saying Alpha, that's not worth invalidating all the testing.
<infinity> flexiondotorg: I can add MATE.  On Tuesday, when I set it up, you hadn't responded.
<infinity> flexiondotorg: In fact, you still haven't responded to the thread asking who was participating, so not sure where it was expressed.
<flexiondotorg> infinity: Thanks for adding MATE. I had told tsimonq2 that we wanted to participate, sorry that wasn't the correct route.
<infinity> flexiondotorg: He isn't the one doing the paperwork bits, so less helpful. ;)
<infinity> flexiondotorg: Uncronned and added.
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Bionic Beta 1] (20180307.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Bionic Beta 1] (20180307.1) has been added
<infinity> bashfulrobot: You should be able to trigger rebuilds now.  Use this power wisely (ie: sparingly).
<bashfulrobot> Thank you Infinity!!! Was that team granted access, or my user directly?
<infinity> bashfulrobot: Your user.
<tsimonq2> flexiondotorg: Ah, I thought you had communicated this back to the Release Team already. Apologies.
<flexiondotorg> infinity tsimonq2 My screw up. I'll do better. Thanks for adding Ubuntu MATE
<infinity> bashfulrobot: A few things.  Don't request rebuilds willy-nilly.  Invalidating all your testing because someone uploaded a spelling correction isn't nice.  Never request a rebuild for something in re-building status.  It'll wedge things.  And, uhm.  That's about it, I guess.
 * infinity is going to see if a nap fixes his headache.
<infinity> If the world explodes while I'm gone, I'll put it back together when I get back.
<bashfulrobot> infinity: thank you very much
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (bionic-proposed/main) [4.15.0-12.13] (core, kernel)
#ubuntu-release 2018-03-08
<wxl> bashfulrobot: are you looking for consensus on delaying until friday eve or is that a decision? i think i like the idea.
-queuebot:#ubuntu-release- New binary: linux [arm64] (bionic-proposed/main) [4.15.0-12.13] (core, kernel)
<valorie> bashfulrobot: I'm a +1 on that as well, unless everyone has successful tests ahead of that
<bashfulrobot> wxl: since there hasn't been enough real feedback. I'm just going to make the call and say Friday evening.
<bashfulrobot> It appears as though enough of the flavors can benefit from this flight extension. But I think we have to be pretty hard on that deadline though.
<wxl> bashfulrobot: sounds good. might want to throw that out on ubuntu-release
<bashfulrobot> valorie: thank you for the feedback!
<bashfulrobot> Okay I'll figure out an email shortly.
<bashfulrobot> Great suggestions. wxl
<tsimonq2> infinity: So I'm hearing reports of this awesome little guy: bug 1752772.
<ubot5`> bug 1752772 in linux (Ubuntu) "r8169 ethernet card don't work after returning from suspension" [Medium,Confirmed] https://launchpad.net/bugs/1752772
<slangasek> that extends the freeze affecting in-flight transitions; how about if I unblock lxhotkey in the meantime, to get libunistring done (low risk of breaking images after a respin)
-queuebot:#ubuntu-release- New: accepted dptfxtract [amd64] (bionic-proposed) [1.2-0ubuntu1]
-queuebot:#ubuntu-release- New binary: linux [armhf] (bionic-proposed/main) [4.15.0-12.13] (core, kernel)
-queuebot:#ubuntu-release- New: accepted percona-xtradb-cluster-5.7 [amd64] (bionic-proposed) [5.7.20-29.24-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted percona-xtradb-cluster-5.7 [armhf] (bionic-proposed) [5.7.20-29.24-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted percona-xtradb-cluster-5.7 [ppc64el] (bionic-proposed) [5.7.20-29.24-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted percona-xtradb-cluster-5.7 [arm64] (bionic-proposed) [5.7.20-29.24-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted percona-xtradb-cluster-5.7 [s390x] (bionic-proposed) [5.7.20-29.24-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted percona-xtradb-cluster-5.7 [i386] (bionic-proposed) [5.7.20-29.24-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted granite [sync] (bionic-proposed) [0.5+ds-1]
-queuebot:#ubuntu-release- New: accepted libauth-googleauth-perl [sync] (bionic-proposed) [1.02-1]
-queuebot:#ubuntu-release- New: accepted libwww-shorten-5gp-perl [sync] (bionic-proposed) [1.030-1]
-queuebot:#ubuntu-release- New: rejected python-bayespy [sync] (bionic-proposed) [0.5.12-1]
-queuebot:#ubuntu-release- New: accepted hg-git [sync] (bionic-proposed) [0.8.11-1]
-queuebot:#ubuntu-release- New: accepted materia-gtk-theme [sync] (bionic-proposed) [20180110-1]
-queuebot:#ubuntu-release- New: accepted libmanette [sync] (bionic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New binary: granite [s390x] (bionic-proposed/universe) [0.5+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmanette [ppc64el] (bionic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libwww-shorten-5gp-perl [amd64] (bionic-proposed/universe) [1.030-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libauth-googleauth-perl [amd64] (bionic-proposed/universe) [1.02-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmanette [s390x] (bionic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmanette [amd64] (bionic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: granite [ppc64el] (bionic-proposed/universe) [0.5+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmanette [i386] (bionic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: granite [amd64] (bionic-proposed/universe) [0.5+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmanette [arm64] (bionic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: granite [i386] (bionic-proposed/universe) [0.5+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: materia-gtk-theme [amd64] (bionic-proposed/universe) [20180110-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hg-git [amd64] (bionic-proposed/universe) [0.8.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: granite [arm64] (bionic-proposed/universe) [0.5+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmanette [armhf] (bionic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: granite [armhf] (bionic-proposed/universe) [0.5+ds-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted granite [amd64] (bionic-proposed) [0.5+ds-1]
-queuebot:#ubuntu-release- New: accepted granite [armhf] (bionic-proposed) [0.5+ds-1]
-queuebot:#ubuntu-release- New: accepted granite [ppc64el] (bionic-proposed) [0.5+ds-1]
-queuebot:#ubuntu-release- New: accepted granite [arm64] (bionic-proposed) [0.5+ds-1]
-queuebot:#ubuntu-release- New: accepted granite [s390x] (bionic-proposed) [0.5+ds-1]
-queuebot:#ubuntu-release- New: accepted granite [i386] (bionic-proposed) [0.5+ds-1]
-queuebot:#ubuntu-release- New: accepted hg-git [amd64] (bionic-proposed) [0.8.11-1]
-queuebot:#ubuntu-release- New: accepted libwww-shorten-5gp-perl [amd64] (bionic-proposed) [1.030-1]
-queuebot:#ubuntu-release- New: accepted libauth-googleauth-perl [amd64] (bionic-proposed) [1.02-1]
-queuebot:#ubuntu-release- New: accepted materia-gtk-theme [amd64] (bionic-proposed) [20180110-1]
-queuebot:#ubuntu-release- Unapproved: pulseaudio (xenial-proposed/main) [1:8.0-0ubuntu3.8 => 1:8.0-0ubuntu3.9] (core)
<tsimonq2> Begone, nodejs delta!
-queuebot:#ubuntu-release- New: accepted libmanette [amd64] (bionic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted libmanette [armhf] (bionic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted libmanette [ppc64el] (bionic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted libmanette [arm64] (bionic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted libmanette [s390x] (bionic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted libmanette [i386] (bionic-proposed) [0.2.0-1]
<Ukikie> s/\ delta//
<tsimonq2> I wish.
<tsimonq2> But, at least this should be the last time (for a while) that my name will be on that beast.
<mwhudson> heh just do what xnox does and put slangasek in the changelog :)
<tsimonq2> hahahahahahaha
<tsimonq2> infinity, slangasek, Laney: Hi, when someone has a chance, I would like some feedback wrt my latest comment on bug 1654761. I want to make sure my pre-implementation notes are correct and that how I want to go about doing this is valid before I proceed.
<ubot5`> bug 1654761 in britney "Use another status for retried but queued items" [Undecided,In progress] https://launchpad.net/bugs/1654761
<tsimonq2> Thanks.
<tsimonq2> Oh, so about nodejs... hah "Not touching package due to block request by freeze (contact #ubuntu-release if update is needed)"
<tsimonq2> Oh well.
<tsimonq2> It's not *urgent*.
 * tsimonq2 goes to bed
<flocculant> bashfulrobot: I guess I'll concur with extending - would be a whole lot better to know this beforehand though
<bashfulrobot> flocculant: apologies. The general consensus seemed to be heading in that way.
<infinity> flexiondotorg: To be fair, if you have no reason to extend, you can mark your images ready on Thursday, and they'll just release the next day with everyone else's. :P
<flocculant> infinity: I assume you meant me - and yea :)
<infinity> flocculant: Yes, you and flexiondotorg break my tab completion every time.
<flocculant> infinity: also to be fair I also concur with your belief that these milestones shouldn't get published :)
<infinity> flocculant: I think we're approaching concensus on that line of reasoning, and going to put forth a proposal next weekish.
<flocculant> infinity: I broke gunnarhj on the discourse thing - he confused us there - and flexiondotorg is wimpress on that ...
<flocculant> yep - read re that discussion the other day in here
<flocculant> infinity: quick question - with the ubiquity change that moves keyboard layout to earlier all the testcases on the tracker are wrong - that's a lot of changes to put through. I sort of have a vague memory of reading something about subiquity replacing ubiquity - is that right? And if it is, likely to be 'soonish' in which case the tescase changes can be less importand I hope
<mwhudson> flocculant: subiquity is "ubiquity for servers"
<mwhudson> flocculant: it's not replacing ubiquity at all
<mwhudson> (it's not even really that really but well)
<flocculant> mwhudson: oh right - read that wrong then :|
<flocculant> would have made life easier lol
<Ukikie> We're not supposed to be reading 'sub-par ubiquity', I gather..
 * tsimonq2 protests by spelling it "sub-iquity" sometimes
<tsimonq2> flocculant: No, that was OMG Ubuntu misinterpreting Didier's commit message. sub-iquity won't replace ubiquity.
<mwhudson> it's /spelt/ "subiquity" but it's /pronounced/ "live-server"
<tsimonq2> That's a bit ambiguous. :P
<Ukikie> mwhudson: ...I don't think that's how English works. :>
<mwhudson> Ukikie: cmon, it's at least plausible
<flocculant> ha
<tsimonq2> ^
<slangasek> mwhudson: you have a golang-golang-x-sys autopkgtest failure on arm64
<slangasek> LocutusOfBorg: you have a python-mechanicalsoup autopkgtest failure on all archs
<acheronuk> bashfulrobot: a delay is fine by me. I have not been able to touch iso testing yet, as was somewhat busy yesterday
<tjaalton> what's up with curl? it's breaking unity-scopes-api tests which block capnproto
<tjaalton> example https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/u/unity-scopes-api/20180308_034127_ac201@/log.gz
<doko> LocutusOfBorg: are you aware of the llvm 6 sanitizer test failures on amd64?
<LocutusOfBorg> slangasek, I did upload the pytest-mock fix in debian yesterday, but got lost due to dak crashing
<LocutusOfBorg> I sync'd it now, should be fixed when it is accepted
<LocutusOfBorg> doko, seems a regression in the package in release too
<LocutusOfBorg> I'll have a look
<LocutusOfBorg> I have some issues with internet, and tomorrow I'll be afk until monday :/
<slangasek> LocutusOfBorg: k, cheers.  Why was python-mechanicalsoup a post-FF upload?
<slangasek> tsimonq2: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1754174 was reported as a bug on the ISO tracker for Lubuntu, it looks very wrong with a syslog full of commands-not-found.  But others are reporting successful installs... do you have any idea what's going on there?
<ubot5`> Ubuntu bug 1754174 in ubiquity (Ubuntu) "Install in VirtualBox crashes when "Installing System"" [Undecided,Confirmed]
<seb128> slangasek, hey, could you update your britney gvfs/s390x hint from ubuntu1 to ubuntu2 to match the recent update?
<slangasek> seb128: done
<seb128> slangasek, thx
<LocutusOfBorg> slangasek, sorry, but I failed to see new features
<LocutusOfBorg> they added some new tests, but not new features
<cyphermox> sil2100: can I haz code review plz? https://code.launchpad.net/~cyphermox/britney/+git/britney2-ubuntu/+merge/340864  :)
<Laney> stgraber: want to look at those armhf config changes with me at some point today/tomorrow?
<jibel> slangasek, I reproduced this bug if I select only-ubiquity on lubuntu. Trying on Ubuntu now.
<mwhudson> blug need to get golang-1.7 and 1.8 removed from bionic
 * mwhudson goes to bed instead of doing anything useful
-queuebot:#ubuntu-release- New binary: linux [i386] (bionic-proposed/main) [4.15.0-12.13] (core, kernel)
<stgraber> Laney: yep, let me know when you have some time
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.13.0-37.42] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.13.0-37.42~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.13.0-37.42]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.13.0-37.42~16.04.1]
-queuebot:#ubuntu-release- New binary: linux [amd64] (bionic-proposed/main) [4.15.0-12.13] (core, kernel)
<Odd_Bloke> xnox: http://paste.ubuntu.com/p/2gVzRDckcp/
<Odd_Bloke> xnox: https://github.com/rails/rails/commit/be9dc78fccc80bb5045c67b435b5c7e36ea8a296
-queuebot:#ubuntu-release- New: accepted linux [amd64] (bionic-proposed) [4.15.0-12.13]
-queuebot:#ubuntu-release- New: accepted linux [armhf] (bionic-proposed) [4.15.0-12.13]
-queuebot:#ubuntu-release- New: accepted linux [ppc64el] (bionic-proposed) [4.15.0-12.13]
-queuebot:#ubuntu-release- New: accepted linux [arm64] (bionic-proposed) [4.15.0-12.13]
-queuebot:#ubuntu-release- New: accepted linux [s390x] (bionic-proposed) [4.15.0-12.13]
-queuebot:#ubuntu-release- New: accepted linux [i386] (bionic-proposed) [4.15.0-12.13]
<Odd_Bloke> xnox: http://paste.ubuntu.com/p/Nzy2GTgG9J/
<tsimonq2> slangasek: No clue.
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-12.13] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-12.13]
-queuebot:#ubuntu-release- New source: openwsman (bionic-proposed/primary) [2.6.5-0ubuntu1]
-queuebot:#ubuntu-release- New source: wsmancli (bionic-proposed/primary) [2.6.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected python-cryptography [source] (artful-proposed) [1.9-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected python-cryptography [source] (xenial-proposed) [1.2.3-1ubuntu0.2]
<Odd_Bloke> slangasek: I believe all of the the ruby-celluloid related regressions need rerunning with the -proposed ruby-defaults.
<Odd_Bloke> xnox: http://paste.ubuntu.com/p/sFrpG7gGFB/
<slangasek> Odd_Bloke: I believe I retriggered those before or after you mentioned here
<slangasek> Odd_Bloke: but I believe many things that are wrong and this is one
-queuebot:#ubuntu-release- Unapproved: accepted python-pyperclip [source] (artful-proposed) [1.5.27-3ubuntu1]
<Odd_Bloke> slangasek: "this"?
<Odd_Bloke> xnox: http://paste.ubuntu.com/p/SY5QjsjNRs/
<slangasek> Odd_Bloke: my previous attempt to retrigger seems not to have done anything - and now I have retriggered again and it's confirmed working
<Odd_Bloke> Glad I could help.
<Odd_Bloke> ^_^
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (artful-proposed) [2.02~beta3-4ubuntu7.3]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (artful-proposed) [1.85.3]
-queuebot:#ubuntu-release- New binary: gedit-plugins [s390x] (bionic-proposed/universe) [3.27.92-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gedit-plugins [ppc64el] (bionic-proposed/universe) [3.27.92-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gedit-plugins [i386] (bionic-proposed/universe) [3.27.92-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gedit-plugins [amd64] (bionic-proposed/universe) [3.27.92-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gedit-plugins [arm64] (bionic-proposed/universe) [3.27.92-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected pulseaudio [source] (xenial-proposed) [1:8.0-0ubuntu3.9]
-queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu7.2 => 2.02~beta3-4ubuntu7.3] (core)
-queuebot:#ubuntu-release- New binary: gedit-plugins [armhf] (bionic-proposed/universe) [3.27.92-1] (no packageset)
<nacc> slangasek: xnox: so what's up with ruby, i'm told i should help fix it :)
-queuebot:#ubuntu-release- Unapproved: accepted sahara-dashboard [source] (xenial-proposed) [4.0.0-1ubuntu1]
<xnox> nacc, see the list of autopkgtest regressions triggered by ruby-defaults.... figure out if these need fixing with uploads; or retries; or by hinting over them. And do these actions, until clean.
<nacc> xnox: ack, i'll pick it up now
<xnox> nacc, some of us have been uploading things. but i don't think anybody will be too sad if we step on each other. most of these are quick, it's just there are a lot of them..... =/
<nacc> xnox: yes, sounds familiar :)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-default-settings [source] (xenial-proposed) [1.3.14ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu7.2 => 2.02~beta3-4ubuntu7.3] (core)
<xnox> nacc, or you can upload Odd_Bloke pastebins above, which he was asking to be sponsored.
<nacc> xnox: i'll take a look
<Odd_Bloke> nacc: http://paste.ubuntu.com/p/SY5QjsjNRs/ and http://paste.ubuntu.com/p/sFrpG7gGFB/ are pending, I believe.
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (xenial-proposed) [1.2.26]
-queuebot:#ubuntu-release- New: accepted gedit-plugins [amd64] (bionic-proposed) [3.27.92-1]
-queuebot:#ubuntu-release- New: accepted gedit-plugins [armhf] (bionic-proposed) [3.27.92-1]
-queuebot:#ubuntu-release- New: accepted gedit-plugins [ppc64el] (bionic-proposed) [3.27.92-1]
-queuebot:#ubuntu-release- New: accepted gedit-plugins [arm64] (bionic-proposed) [3.27.92-1]
-queuebot:#ubuntu-release- New: accepted gedit-plugins [s390x] (bionic-proposed) [3.27.92-1]
-queuebot:#ubuntu-release- New: accepted gedit-plugins [i386] (bionic-proposed) [3.27.92-1]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (xenial-proposed) [229-4ubuntu21.2]
<bashfulrobot> acheronuk: that was the general feeling I was getting from the group.
<nacc> Odd_Bloke: looks like homesick is fixed in debian
<nacc> rake appears to pass with all-proposed
<nacc> ah just needs rake itself rom proposed
<nacc> retriggered those
<nacc> Odd_Bloke: sponsoring your debdiffs
<Odd_Bloke> nacc: Thanks!
<Odd_Bloke> nacc: BTW, I believe xnox has an upload of rails pending, so I'd avoid doing anything there for now.
<Odd_Bloke> xnox: Right?
<Odd_Bloke> cpaelzer_: So vagrant has now migrated, but vagrant-libvirt itself is still stuck because it's trying to use the Debian box in its own autopkgtests.
<Odd_Bloke> cpaelzer_: We don't have a libvirt version of the Ubuntu box, so I'm not sure what to suggest.
<Odd_Bloke> cpaelzer_: (Other than skipping/dropping the test, obviously. :p)
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (trusty-proposed) [204-5ubuntu20.27]
<Odd_Bloke> nacc: https://autopkgtest.ubuntu.com/request.cgi?release=bionic&arch=amd64&package=jekyll&trigger=ruby-safe-yaml%2F1.0.4-1ubuntu1&trigger=ruby-defaults%2F1%3A2.5~1000grauubuntu1 (etc., for the rest of the releases) should fix the ruby-safe-yaml regressions there.
<Odd_Bloke> s/releases/arches/
<nacc> Odd_Bloke: thanks, triggering
<nacc> Odd_Bloke: hrm, did Floats change in 2.5?
<nacc> that seems to be the issue underlying ruby-autoparse
<nacc> undefined method `[]' for 3.14:Float
<Odd_Bloke> nacc: I'm not sure; my thinking on that was that it's testing invalid input _anyway_ so an exception isn't the worst thing in the world.
<Odd_Bloke> But I couldn't quite convince myself of that, so I ignored it. :p
<nacc> I think it should be a different exception
<nacc> Odd_Bloke: given that it passed before
<Odd_Bloke> nacc: That said: https://paste.ubuntu.com/p/MTfWz2jxqR/
<nacc> Odd_Bloke: yeah, so i think it's supposed to be not getting to this point
<nacc> but i'm not sure
<Odd_Bloke> Or, because it's Ruby, something anywhere in the dependency chain could define [] for Float.
<Odd_Bloke> And it's stopped doing it since 2.3
<nacc> Odd_Bloke: right
<nacc> Odd_Bloke: ok, i think what this is trying to test is that you have to have nil-ended binary trees
<nacc> Odd_Bloke: so it does seem like (even if typeerror is wrong), the exception should lead to invalid being true
<nacc> i'm not 100%
<Odd_Bloke> I'm trying to run tests locally to no avail.
<Odd_Bloke> nacc: Nothing depends on it, and it's dead upstream; should we drop it?
<mwhudson> could someone mark golang-github-prometheus-tsdb/0.0~git20180118.467948f-1 as badtest
<mwhudson> it's one of these super flaky tests that has had the bad luck to pass once or twice: http://autopkgtest.ubuntu.com/packages/g/golang-github-prometheus-tsdb/bionic/amd64
<nacc> Odd_Bloke: i'm thinking that might be easiest (for the trasnsition) there's also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888146
<ubot5`> Debian bug 888146 in src:ruby-autoparse "ruby-autoparse: FTBFS on ruby2.5: undefined method `[]' for 3.14:Float" [Serious,Open]
<nacc> Odd_Bloke: which means if debian fixes it, we can sync it back in in the future, in theory
<Odd_Bloke> nacc: +1
<nacc> Odd_Bloke: have you started a bug of stuff that should be removed?
<Odd_Bloke> nacc: And that's also following slangasek's guidance to drop broken stuff to get this done.
<Odd_Bloke> nacc: I have not.
<nacc> Odd_Bloke: ack, will start it
<Odd_Bloke> Thanks.
<nacc> Odd_Bloke: LP: #1754464 we'll just open tasks there as necesary
<ubot5`> Launchpad bug 1754464 in ruby-autoparse (Ubuntu) "remove broken ruby srcpkgs due to ruby-defaults stuck in bionic-proposed" [Undecided,New] https://launchpad.net/bugs/1754464
<Odd_Bloke> nacc: Thanks!
<nacc> Odd_Bloke: np
<nacc> Odd_Bloke: retriggering homesick as the debian version migrated
<Odd_Bloke> nacc: I think retriggering ruby-aws-sdk with ruby-defaults should also fix that.
<nacc> weird, ruby-aws-sdk has already migrated, but rmadison doesn't show the new version in bionic-proposed or bionic release
<nacc> Odd_Bloke: I usually wait until i see it in rmadison to retrigger to be sure it's hit the arhcive
<Odd_Bloke> Ah, yeah, makes sense.
<nacc> but the above is odd
<nacc> https://launchpad.net/ubuntu/+source/ruby-aws-sdk/1.67.0-1ubuntu1/+publishinghistory
<nacc> i'll retrigger it anyways, since it was published a bit ago
<Odd_Bloke> nacc: I can look at ruby-bert.
<nacc> Odd_Bloke: cool, i'll look at the one after that
<nacc> Odd_Bloke: i retriggered ruby-bio to pick up the new version
<Odd_Bloke> Thanks.
<nacc> Odd_Bloke: i'll look at ruby-celluloid-io
<Odd_Bloke> nacc: The ruby-celluloid upload I did earlier should have fixed that.
<nacc> Odd_Bloke: i don't see one?
<nacc> at least not in rmadison
<Odd_Bloke> nacc: I think it migrated?
<nacc> Odd_Bloke: not in bionic at all
<nacc> Odd_Bloke: the version in bionic is what is in artful
<nacc> https://launchpad.net/ubuntu/+source/ruby-celluloid-io
<Odd_Bloke> nacc: s/-io//
<Odd_Bloke> Is what should fix -io.
<nacc> Odd_Bloke: oh that's the underlyiung cuase (ruby-celluloid)
<nacc> sorry
<Odd_Bloke> No worries.
<Odd_Bloke> Low edit distance. :p
<nacc> ok will retrigger those
<nacc> i *just* ran the test locally first and
<nacc> Get:13 http://archive.ubuntu.com/ubuntu bionic/universe amd64 ruby-celluloid all 0.16.0-4 [40.0 kB]
<nacc> wth
<nacc> will check if it passes after another update in the lxd
<nacc> Odd_Bloke: ok confirmed, i must have raced the update :)
<nacc> retriggered celluloid-io
<nacc> are all the *rail* being taken care of by xnox then?
<Odd_Bloke> nacc: Well, I don't know if he'll take care of all of them, but he's going to fix the debug-inspector issue that shows up in a lot of them.
<Odd_Bloke> So I'd wait until that's available, to avoid a bunch of unnecessary triage.
<nacc> yep
<nacc> i'm checking ot see if ruby-cucumber-rails is fixed by the new sdoc
<Odd_Bloke> nacc: http://paste.ubuntu.com/p/bVfH6V8NKd/
<Odd_Bloke> Hold on, actually, I'm testing that locally.
<Odd_Bloke> I forgot that I was going to wait for the tests to finish before I pinged you. :p
<Odd_Bloke> nacc: OK, now it's passed locally.
<nacc> Odd_Bloke: ack, sponsoring (needs an update-mainatiner, i assume)
<nacc> oh nm
<Odd_Bloke> Yeah, I had a confusing moment when I ran it and it errored.
<Odd_Bloke> Looking at ruby-delayed-job-active-record.
<nacc> rbasak: afaict, the SourceSpec does not let me specify the treeish / influence it, right?
<nacc> i could fake it by having one with patches and one without
<rbasak> nacc: correct, but perhaps we should add that as a feature somehow.
<rbasak> I'm assuming you want to mutate the tree object just so it has a different hash for the purpose of this test.
<nacc> yep
<nacc> i think i can do the hack for now, and we can talk about the 'right' way later
<rbasak> But that seems like a legit thing to test, and it should be relatively trivial to implement in SourceSpec.
<nacc> i think i'm in a good groove for writing the cases up
<rbasak> Interesting choice of channel though :)
<nacc> rbasak: bah :)
<nacc> rbasak: mis-typed :)
<Odd_Bloke> nacc: http://paste.ubuntu.com/p/2BjCDNsYrn/ <-- this should fix ruby-delayed-job-active-record, but note it is for ruby-delayed-job
<Odd_Bloke> (-active-record evidently exercises some code that ruby-delayed-job itself doesn't.)
<nacc> Odd_Bloke: sponsoring
<Odd_Bloke> Thanks!
<nacc> Odd_Bloke: np (sponsored)
<Odd_Bloke> ruby-devise is sneakily failing due to rails.
<nacc> heh
<Odd_Bloke> IHNI about the ruby-fakefs failure, I'm seeing if I can reproduce it locally.
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Bionic Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Bionic Beta 1] has been marked as ready
<Odd_Bloke> I can.
<Odd_Bloke> I'm going to skip over it though, it's a bit beyond me at this point in the evening.
<nacc> Odd_Bloke: np, i'm sure we won't get done today :)
<Odd_Bloke> Alright, I'm heading to bed.
<Odd_Bloke> nacc: Good luck!
<Odd_Bloke> (And thanks for the sponsoring!)
<nacc> Odd_Bloke: yw, nice progress so far
<bashfulrobot> How is everyones testing going? Still looking good for the beta 1 release?
<acheronuk> as usual, trouble getting coverage on i386
<jbicha> acheronuk: there's a fix for thatâ¦
<acheronuk> jbicha: yup
<jbicha> acheronuk: 18.10?
<bashfulrobot> acheronuk: drop 386?  ;-p
<jbicha> yes
<bashfulrobot> We have been discussing it as well.
<acheronuk> at the moment, looks likely
<tsimonq2> Not Lubuntu/
 * tsimonq2 whistles
<jbicha> my opinion is that it would be good to announce dropping i386 isos at the same as the LTS release so users don't upgrade to an unsupported path (assuming they read release notes)
<tsimonq2> IMHO that's fine for individual flavors if they decide to do that.
<jbicha> I also thought it would be good if ubuntu-release-upgrader would actively prevent users from upgrading i386 installs if the appropriate flavor metapackage were installed
<jbicha> I guess some people think that's too aggressive though
<acheronuk> a warning that requires positive input to get past then?
<tsimonq2> It should be up to the flavors, really.
<tsimonq2> If a flavor wants to kill i386, let them do that.
<jbicha> with my proposal, it's still possible to install i386 flavors; it just needs to be done manually
 * Odd_Bloke started work on ruby-tinder earlier, too.
<Odd_Bloke> FYI.
#ubuntu-release 2018-03-09
-queuebot:#ubuntu-release- New source: isl-0.18 (bionic-proposed/primary) [0.18-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted isl-0.18 [source] (bionic-proposed) [0.18-1ubuntu1]
-queuebot:#ubuntu-release- New binary: isl-0.18 [s390x] (bionic-proposed/main) [0.18-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Bionic Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Bionic Beta 1] has been marked as ready
-queuebot:#ubuntu-release- New binary: isl-0.18 [amd64] (bionic-proposed/main) [0.18-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: isl-0.18 [ppc64el] (bionic-proposed/main) [0.18-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: isl-0.18 [i386] (bionic-proposed/main) [0.18-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: isl-0.18 [arm64] (bionic-proposed/main) [0.18-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: isl-0.18 [armhf] (bionic-proposed/main) [0.18-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted isl-0.18 [amd64] (bionic-proposed) [0.18-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted isl-0.18 [armhf] (bionic-proposed) [0.18-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted isl-0.18 [ppc64el] (bionic-proposed) [0.18-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted isl-0.18 [arm64] (bionic-proposed) [0.18-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted isl-0.18 [s390x] (bionic-proposed) [0.18-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted isl-0.18 [i386] (bionic-proposed) [0.18-1ubuntu1]
-queuebot:#ubuntu-release- New binary: isl [s390x] (bionic-proposed/main) [0.19-0ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: isl [amd64] (bionic-proposed/main) [0.19-0ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: isl [i386] (bionic-proposed/main) [0.19-0ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: isl [ppc64el] (bionic-proposed/main) [0.19-0ubuntu1] (core)
-queuebot:#ubuntu-release- New: accepted isl [amd64] (bionic-proposed) [0.19-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted isl [ppc64el] (bionic-proposed) [0.19-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted isl [i386] (bionic-proposed) [0.19-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted isl [s390x] (bionic-proposed) [0.19-0ubuntu1]
-queuebot:#ubuntu-release- New binary: isl [arm64] (bionic-proposed/main) [0.19-0ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: isl [armhf] (bionic-proposed/main) [0.19-0ubuntu1] (core)
-queuebot:#ubuntu-release- New: accepted isl [arm64] (bionic-proposed) [0.19-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted isl [armhf] (bionic-proposed) [0.19-0ubuntu1]
<doko> do isl and isl-0.18 need a hint to migrate together?
-queuebot:#ubuntu-release- New source: kylin-burner (bionic-proposed/primary) [3.0.4-0ubuntu1]
<slangasek> mwhudson: badtest added
<slangasek> Odd_Bloke, nacc: ruby-autoparse removed
<slangasek> nacc, Odd_Bloke: also, I will take removals of packages removed from Debian testing without a separate launchpad bug, if you want to save on paperwork
<tsimonq2> slangasek: Please RM gcompris-dbg from bionic. src:gcompris-qt supersedes src:gcompris which switches to dbgsym packages and has a transitional gcompris binary.
<tsimonq2> Once my src:gcompris-qt sync migrates, I'll ask for an RM of src:gcompris.
<tsimonq2> (Unless you wanna kill two birds with one stone and save the paperwork, I'm fine either way.)
<tsimonq2> (ftr I'm asking for the RM because it makes gcompris-qt uninstallable)
<slangasek> tsimonq2: I'll just remove gcompris directly
<slangasek> tsimonq2: actually, I take that back - Debian hasn't removed gcompris yet, so I'd want a removal bug filed for this
<slangasek> tsimonq2: so meanwhile, gcompris-dbg removed
<tsimonq2> slangasek: src:gcompris' removal in Debian is waiting on me to give a green light to sebastien that the bugs are either moved over or closed for src:gcompris.
<tsimonq2> (I'm the only direct human maintainer for gcompris-qt in Debian fwiw)
<tsimonq2> slangasek: So that's something like a day or two away, probably less.
<slangasek> doko: isl+isl-0.18 hinted.  what happened that we need two of these?
<tsimonq2> slangasek: Actually, I'll ping him; it seems ready to RM in Debian (unless you somehow have the powers in Debian too...)
<slangasek> I do not :)
<tsimonq2> Ah OK :)
<tsimonq2> slangasek: What you may have powers to do is to do this same thing in Ubuntu: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892380
<ubot5`> Debian bug 892380 in ftp.debian.org "override: gcompris:oldlibs/optional" [Normal,Open]
<doko> slangasek: transitionary. isl-0.18 will demote, and after I've sorted out the cloog build it can be removed
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Bionic Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Bionic Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Bionic Beta 1] has been marked as ready
<flocculant> bashfulrobot: all marked ready for us
<flocculant> jbicha: yea I'd agree with "it would be good to announce dropping i386 isos at the same as the LTS release" and when we're at this point for 20.04 I suspect that xubuntu will be closer to that point than now
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Bionic Beta 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Bionic Beta 1] has been marked as ready
-queuebot:#ubuntu-release- New source: golang-1.9-race-detector-runtime (xenial-backports/primary) [0.0+svn285455-0ubuntu1~16.04.1]
<Odd_Bloke> xnox: http://paste.ubuntu.com/p/cJXcj7qV6W/
-queuebot:#ubuntu-release- New: accepted golang-1.10 [amd64] (xenial-backports) [1.10-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted golang-1.10 [armhf] (xenial-backports) [1.10-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted golang-1.10 [ppc64el] (xenial-backports) [1.10-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted golang-1.9-race-detector-runtime [source] (xenial-backports) [0.0+svn285455-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted golang-1.10 [arm64] (xenial-backports) [1.10-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted golang-1.10 [s390x] (xenial-backports) [1.10-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted golang-1.10 [i386] (xenial-backports) [1.10-1ubuntu1~16.04.1]
<Odd_Bloke> xnox: My next question: I'm re-adding that Vagrant autopkgtest, but virtualbox is only available on Intel architectures; how do I mark my autopkgtest as only worth running on {amd64,i386}?
-queuebot:#ubuntu-release- New: accepted golang-1.10 [amd64] (artful-backports) [1.10-1ubuntu1~17.10.1]
-queuebot:#ubuntu-release- New: accepted golang-1.10 [armhf] (artful-backports) [1.10-1ubuntu1~17.10.1]
-queuebot:#ubuntu-release- New: accepted golang-1.10 [ppc64el] (artful-backports) [1.10-1ubuntu1~17.10.1]
-queuebot:#ubuntu-release- New source: golang-1.10-race-detector-runtime (artful-backports/primary) [0.0+svn285455-0ubuntu1~17.10.1]
-queuebot:#ubuntu-release- New: accepted golang-1.10 [arm64] (artful-backports) [1.10-1ubuntu1~17.10.1]
-queuebot:#ubuntu-release- New: accepted golang-1.10 [s390x] (artful-backports) [1.10-1ubuntu1~17.10.1]
-queuebot:#ubuntu-release- New: accepted golang-1.10 [i386] (artful-backports) [1.10-1ubuntu1~17.10.1]
-queuebot:#ubuntu-release- New source: golang-1.10-race-detector-runtime (xenial-backports/primary) [0.0+svn285455-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted golang-1.10-race-detector-runtime [source] (artful-backports) [0.0+svn285455-0ubuntu1~17.10.1]
-queuebot:#ubuntu-release- New: accepted golang-1.10-race-detector-runtime [source] (xenial-backports) [0.0+svn285455-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New binary: golang-1.10-race-detector-runtime [amd64] (artful-backports/none) [0.0+svn285455-0ubuntu1~17.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-1.9-race-detector-runtime [amd64] (xenial-backports/none) [0.0+svn285455-0ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-1.10-race-detector-runtime [amd64] (xenial-backports/none) [0.0+svn285455-0ubuntu1~16.04.1] (no packageset)
<Odd_Bloke> Also, https://autopkgtest.ubuntu.com/request.cgi?release=bionic&arch=amd64&package=ruby-bert&trigger=ruby-defaults%2F1%3A2.5%7E1000grauubuntu1 (and architecture friends) should be fixed now, if someone wants to trigger them for me.
<Odd_Bloke> Same with https://autopkgtest.ubuntu.com/request.cgi?release=bionic&arch=amd64&package=ruby-delayed-job-active-record&trigger=ruby-defaults%2F1%3A2.5%7E1000grauubuntu1
<slangasek> grrrrrau
<xnox> Odd_Bloke, you check dpkg --print-artchitecture and exit zero at the top of your script =)
<acheronuk> bashfulrobot: just going through left over testcases in a VM for i386
<xnox> Odd_Bloke, because i do not believe there is amd64 restriction and/or Architecture: tag in debian/tests/control
<slangasek> Odd_Bloke: retriggering the things you mention above
<acheronuk> sadly the only real i386 I have wont boot from removal media at the moment
<mwhudson> slangasek: merci
<Odd_Bloke> rbasak: I know nacc was working on the Ruby transition, but do you have cycles to sponsor uploads before he's awake today?
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/none) [4.13.0-1012.15] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.13.0-1012.15]
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Bionic Beta 1] has been marked as ready
<acheronuk> bashfulrobot: Kubuntu good to go
<acheronuk> bashfulrobot: do we have an ETA we want to get this out by today?
<acheronuk> asking as I see lubuntu tests are not finished
<rbasak> Odd_Bloke: are they trivial? I'm in permanent interrupt mode as you might expect, but throw up a list somewhere and I'll get to them if I can.
<rbasak> Odd_Bloke: assuming nacc is fine with this, ie. that this won't step on his toes?
<Odd_Bloke> rbasak: They are largely trivial, yes; I don't believe it will step on nacc's toes.
<rbasak> OK
<Odd_Bloke> rbasak: https://gist.github.com/OddBloke/08f68c18f2f3d63a002f2c1a26a765ac
 * Odd_Bloke is also looking at ruby-mustermann19 ATM.
<rbasak> Odd_Bloke: uploaded ruby-tinder and ruby-minitest-shared-description, thanks.
<rbasak> nacc: ^
<rbasak> Odd_Bloke, nacc: ruby-mustermann19 uploaded
<Odd_Bloke> rbasak: Thanks, thanks, thanks. :)
<Odd_Bloke> slangasek: I think we can remove ruby-packable; it has an odd error in tests which isn't addressed in (the largely dead) upstream.  There's also a serious Debian bug, so it might get fixed for us to resync: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888164
<ubot5`> Debian bug 888164 in src:ruby-packable "ruby-packable: FTBFS on ruby2.5: Illegal seek @ rb_io_tell" [Serious,Open]
<slangasek> Odd_Bloke: ruby-packable gone
<Odd_Bloke> Danke.
<flocculant> tsimonq2: finished you 64 bit tests
<flocculant> s/you/your
<flocculant> wxl: or you ^^
<Odd_Bloke> rbasak: A couple more at https://gist.github.com/OddBloke/08f68c18f2f3d63a002f2c1a26a765ac
<rbasak> ack
<rbasak> (still in a meeting)
-queuebot:#ubuntu-release- New source: netplan.io (bionic-proposed/primary) [0.34]
-queuebot:#ubuntu-release- Unapproved: snapd (artful-proposed/main) [2.31.1+17.10 => 2.31.2+17.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.31.1~14.04 => 2.31.2~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.31.1 => 2.31.2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted openwsman [source] (bionic-proposed) [2.6.5-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted wsmancli [source] (bionic-proposed) [2.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: openwsman [ppc64el] (bionic-proposed/none) [2.6.5-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: openwsman [s390x] (bionic-proposed/none) [2.6.5-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: openwsman [amd64] (bionic-proposed/none) [2.6.5-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: openwsman [i386] (bionic-proposed/none) [2.6.5-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: openwsman [arm64] (bionic-proposed/none) [2.6.5-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: openwsman [armhf] (bionic-proposed/none) [2.6.5-0ubuntu1] (no packageset)
<xnox> slangasek, ^^^^^^^^^^^
-queuebot:#ubuntu-release- Unapproved: libnative-platform-java (artful-proposed/universe) [0.11-5 => 0.11-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted netplan.io [source] (bionic-proposed) [0.34]
-queuebot:#ubuntu-release- New binary: netplan.io [s390x] (bionic-proposed/none) [0.34] (no packageset)
-queuebot:#ubuntu-release- New binary: netplan.io [amd64] (bionic-proposed/none) [0.34] (no packageset)
-queuebot:#ubuntu-release- New binary: netplan.io [ppc64el] (bionic-proposed/none) [0.34] (no packageset)
-queuebot:#ubuntu-release- New binary: netplan.io [i386] (bionic-proposed/none) [0.34] (no packageset)
-queuebot:#ubuntu-release- New binary: netplan.io [arm64] (bionic-proposed/none) [0.34] (no packageset)
-queuebot:#ubuntu-release- New binary: netplan.io [armhf] (bionic-proposed/none) [0.34] (no packageset)
<Laney> stgraber: the test finished, looks good to me
-queuebot:#ubuntu-release- New: accepted netplan.io [amd64] (bionic-proposed) [0.34]
-queuebot:#ubuntu-release- New: accepted netplan.io [armhf] (bionic-proposed) [0.34]
-queuebot:#ubuntu-release- New: accepted netplan.io [ppc64el] (bionic-proposed) [0.34]
-queuebot:#ubuntu-release- New: accepted netplan.io [arm64] (bionic-proposed) [0.34]
-queuebot:#ubuntu-release- New: accepted netplan.io [s390x] (bionic-proposed) [0.34]
-queuebot:#ubuntu-release- New: accepted netplan.io [i386] (bionic-proposed) [0.34]
-queuebot:#ubuntu-release- Unapproved: python-pylxd (xenial-proposed/main) [2.0.5-0ubuntu1.2 => 2.0.7-0ubuntu1] (ubuntu-server)
<stgraber> Laney: yay
<Laney> stgraber: if you want to mangle the lxd-armhf{2..10} runners ...
 * Laney coughs
<Laney> be my guest :-)
<Laney> it'd quite fun to do a 'broadcast all' thing on a split terminal to admin these
<Laney> 1337 h4x0r
<coreycb> hi, can someone reject python-pylxd from the xenial queue please? it is overwriting the previous upload of which i need to integrate into the package source repo.
<rbasak> Odd_Bloke, nacc: sorry I think it's unlikely I'll get to the rest now. So I'll hand over to nacc I guess: https://gist.github.com/OddBloke/08f68c18f2f3d63a002f2c1a26a765ac
<Odd_Bloke> rbasak: Thanks for what you had time for!
<rbasak> Odd_Bloke: thank you for helping. Also I look forward to your core dev application :-P
<ogra_> huh ? he's not core-dev yet ?!?!
<ogra_> what a world !
-queuebot:#ubuntu-release- Unapproved: python-pylxd (xenial-proposed/main) [2.0.5-0ubuntu1.2 => 2.0.7-0ubuntu1] (ubuntu-server)
<coreycb> this upload should replace the older one in the queue ^
<bashfulrobot> flocculant: thanks for the update!
<bashfulrobot> acheronuk: Dodd you get through your last i386 test cases?
<acheronuk> bashfulrobot: all done. as much as going to be done
<bashfulrobot> acheronuk: disregard. Haha. Just saw your other message. Reading the backlog.
<acheronuk> right :)
<bashfulrobot> As for the time to release, if everyone is good to go, I'll have the email out in about 2 ish hours (6:45 am here) once I arrive at the office.
<bashfulrobot> Well my drive to my office will give everyone a chance to pipe up if they are ready, but (to all), the intent is to send the info in about 2ish hours.
<infinity> bashfulrobot: Sending the email before I'm ready would probably not be the best plan. ;)
<bashfulrobot> infinity: sorry, should have been clear... I was including you as part of the "all clear"... Haha (everyone ready)
 * bashfulrobot makes note to self... Clarity. ðµ
<infinity> bashfulrobot: So, lubuntu hasn't marked any of theirs ready.  And once they do, it still takes me a little while to go through the actual publishing.  2 hours might be optimistic. :)
<bashfulrobot> Okay, I don't see that as being a problem. The 2-hour window was more so the earliest that I was going to be able to draft up the email.
<bashfulrobot> Infinity^^
<bashfulrobot> tsimonq2: how is testing looking on your side?
<Odd_Bloke> If someone could retry all the autopkgtest failures depending on ruby-tinder, I believe they will now pass.
<Odd_Bloke> Same with ruby-minitest-shared-description.
<nacc> Odd_Bloke: i can do that
<nacc> Odd_Bloke: do the other gist pastes just need sponsoring?
-queuebot:#ubuntu-release- New binary: openwsman [s390x] (bionic-proposed/universe) [2.6.5-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: openwsman [amd64] (bionic-proposed/universe) [2.6.5-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: openwsman [ppc64el] (bionic-proposed/universe) [2.6.5-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: openwsman [i386] (bionic-proposed/universe) [2.6.5-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: openwsman [arm64] (bionic-proposed/universe) [2.6.5-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: openwsman [armhf] (bionic-proposed/universe) [2.6.5-0ubuntu2] (no packageset)
 * acheronuk gets out the sharp pointy stick and pokes lubuntu
<infinity> acheronuk: It's only 8:30am Pacific.  Not sure which TZ lubuntuish people are in, but yeah, it's early here in parts of Americanland.
<acheronuk> infinity: I know. just teasing tsimonq2 via the backlog
<infinity> I think I might go hunt some pancakes and bacon while we wait on that.
<acheronuk> mmmmmmmmmm
<flexiondotorg> wxl see above ð
<acheronuk> I *think* wxl and tsimonq2 are CST
<acheronuk> Simon is, for sure
<tsimonq2> wxl is PST
<tsimonq2> And this is the start of my weekend so I just woke up.
<tsimonq2> infinity: iirc you're right in the middle of that, right?
<tsimonq2> I'll poke things with a sharp stick as soon as I get some caffeine.
<infinity> tsimonq2: I'm MST, yes.
 * infinity starts publishing for !lubuntu, while tsimonq2 finishes up.
<infinity> tsimonq2: Looks to me like lubuntu desktop is unreleasable due to LP: #1754174
<ubot5`> Launchpad bug 1754174 in ubiquity (Ubuntu) "[Lubuntu] "Install Lubuntu" fails with several commands not found and permission denied" [Critical,Confirmed] https://launchpad.net/bugs/1754174
<infinity> tsimonq2: And next is untested entirely.
<tsimonq2> infinity: Oh boy.
<infinity> tsimonq2: If I were you, I'd just skip on Beta1. :P
<infinity> tsimonq2: We're definitely not fixing and respinning for the ubiquity thing before release today.
<flocculant> tsimonq2: just so you know - I couldn't replicate that
 * flocculant shuts up again
<infinity> flocculant: jibel implied he could (after saying he couldn't) by setting the bug to Confirmed.
<infinity> But I'm testing myself now.
<flocculant> infinity: yea I saw that - a bit confused I was
<infinity> flocculant: Did you boot live, then click Install on the desktop, or boot to the installer?
<infinity> flocculant: jibel's updated description implies maybe it only fails in the latter case.
<flocculant> infinity: not completely sure - I was in the middle of waking up - but I 'think' I did both
<wxl> tsimonq2, infinity do we even know this is a known issue?
<wxl> like, can it be reproduced?
<flocculant> I did a full drive then an autoresize
<infinity> Yeah, just reproduced when booting directly to the installer.
<tsimonq2> infinity: If that bug is reproducable, we're out.
<infinity> Quite easily reproducible.
<flocculant> infinity: from the first menu?
<infinity> I see one of the bugs in ubiquity just looking at the code, but I'm struggling to see how it causes the chain reaction of doom that follows.
<infinity> flocculant: Yeah.  Install instead of Try.
<flocculant> ack
<infinity> I also see packagekit starting up partway through, so there could also be some nasty race here between pkit and apt/dpkg.
<infinity> But the first bug is the assumption that py2 is in the target, which it isn't (congrats on being the first flavour to kick out py2 entirely)
<infinity> And reproduced again on a second try.  So if it's racy, I'm racing it just right.
<infinity> Or just wrong. :P
<flocculant> :)
<tsimonq2> Yeah no, then I think we're out for this one.
<infinity> bashfulrobot: ^-- No lubuntu for your release announcement.
<flocculant> infinity: where do you see it crash?
<infinity> flocculant: After the file copy stage, it explodes quite spectacularly.
<flocculant> just there almost
<infinity> bashfulrobot: And with that, I'm ready when you are.
<flocculant> infinity: and there it goes for me too
<infinity> flocculant: Good, so jibel and I aren't participating in mass bug hallucination.
<infinity> flocculant: Anyhow, I followed up to the bug.  Like I said, the first bug is obvious.  And *maybe* it's responsible for the whole explosion.  But will need to test.
<bashfulrobot> infinity: thanks! Will email once out of meeting
<infinity> A pain to test when it doesn't happen when booting to the desktop first, sadly.
<infinity> bashfulrobot: ETA on that, so I know when I should push mirrors?
<infinity> bashfulrobot: (I tend to want to push about 30m before you email, so it all sort of lands together)
<bashfulrobot> infinity: give me 30-45min. Being safe on estimate
<infinity> bashfulrobot: Okay, so you're saying I should push nowish. :)
<flocculant> lol
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Bionic Beta 1] has been disabled
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Bionic Beta 1] has been disabled
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop amd64 [Bionic Beta 1] has been disabled
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Bionic Beta 1] has been disabled
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Bionic Beta 1] has been disabled
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop i386 [Bionic Beta 1] has been disabled
<infinity> britney block dropped.
<bashfulrobot> infinity: sounds good
<tsimonq2> Looks like Plasma 5.12.3 is incoming.
<tsimonq2> infinity: I think this is a good example of a milestone shipping something that will be obsolete the next day. :P
<infinity> tsimonq2: They pretty much always do.
 * flocculant keeps quiet 
<infinity> bashfulrobot: Mirrors and torrents look sane to me (do double-check before you send your email, I'm just the monkey behind the curtain), from my POV, you're good to go.
<bashfulrobot> infinity: I'm just linking up in the email.
<bashfulrobot> tsimonq2: I cannot find the lubuntu release notes and also cdimage does not seem to have lubuntu images in their release folder.
<bashfulrobot> infinity: Is the missing lubuntu release folder just a sync waiting to happen?
<flocculant> bashfulrobot: lubuntu aren't releasing I thought?
<bashfulrobot> tsimonq2: Is this the case?
<bashfulrobot> flocculant: I may have missed that
<flocculant> see above from infinity > [18:23:20] < infinity> bashfulrobot: ^-- No lubuntu for your release announcement.
<infinity> bashfulrobot: What he said.
<bashfulrobot> thanks guys!
<infinity> (Which is also what I said...)
<flocculant> ha ha ha
<bashfulrobot> Will remove from the announcment
 * bashfulrobot dumbass
<flocculant> easily done in the heat of getting it finished - flexiondotorg once got the Xubuntu links completely wrong
 * flocculant wasn't sure if it was deliberate or not :D
-queuebot:#ubuntu-release- Unapproved: neutron (artful-proposed/main) [2:11.0.2-0ubuntu1.1 => 2:11.0.2-0ubuntu1.2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (xenial-proposed/main) [2:8.4.0-0ubuntu6 => 2:8.4.0-0ubuntu7] (openstack, ubuntu-server)
<Odd_Bloke> nacc: re:gists, uploads would be good; I'm not sure what test retrying will be needed once they land.
<nacc> Odd_Bloke: ok, i'm going to be afk for a bit due to a doctor's appointment, but i'll try and help out this afternoon
<bashfulrobot> Ubuntu Kylin did not provide a release notes link on the wiki page.
 * bashfulrobot furiously googling
<bashfulrobot> hrm - no go. Announcement may not have their release notes linked then.
<flocculant> that's the way it goes - up to fglavours to give you the information
<bashfulrobot> ypwong: Any links for your release notes for the 18.04 release announcement?
<bashfulrobot> I'll link to the homepage at http://www.ubuntukylin.com/index.php?lang=en instead
<Odd_Bloke> nacc: Thanks!
<bashfulrobot> flexiondotorg: Where might your beta 1 release notes be? Did not find on the wiki or your blog.
<bashfulrobot> flexiondotorg: If I don't hear, I will also link to your home page. https://ubuntu-mate.org/
<flexiondotorg> I'm getting food. Not able to release the blog bashfulrobot
<flexiondotorg> The url will be...
<bashfulrobot> flexiondotorg: Thank you for popping in though.
<flexiondotorg> https://ubuntu-mate.org/blog/ubuntu-mate-bionic-beta1/
<bashfulrobot> flexiondotorg: Perfect. Added
<bashfulrobot> All who are interested. Just need a proofread and this is good to go.
<flocculant> bashfulrobot: I can do that if you like
<bashfulrobot> ok... will poste shortly
<bashfulrobot> flocculant: https://paste.ubuntu.com/p/Kt2yNwt3c7/
<bashfulrobot> tsimonq2: Also gave a proof (THANKS!)
<tsimonq2> np :)
<bashfulrobot> I see one last change. References alpha at bottom
<bashfulrobot> s/alpha/beta
<bashfulrobot> fixed
<flocculant> bashfulrobot: if it's been checked then go for it :)
<bashfulrobot> Alright.
<bashfulrobot> Thanks for the assist all!
<bashfulrobot> Sendign to the list
<bashfulrobot> I'll send to ubuntu-release and ubuntu-devel-annouce
<flocculant> bashfulrobot: thanks fot sitting in the driver seat :)
<bashfulrobot> flocculant: my pleasure!
<bashfulrobot> SENT!
<bashfulrobot> infinity: BTW - thanks for gettign all the Nusakan stuff our of the way for me!
<bashfulrobot> I know we can reference the email archive for the email list, but I created this for an easy formatted link for social media. https://wiki.ubuntu.com/BionicBeaver/Beta1/Annoucement
#ubuntu-release 2018-03-10
-queuebot:#ubuntu-release- New sync: deepin-menu (bionic-proposed/primary) [3.2.0-1]
-queuebot:#ubuntu-release- New sync: deepin-notifications (bionic-proposed/primary) [3.1.2-1]
-queuebot:#ubuntu-release- New: accepted openwsman [amd64] (bionic-proposed) [2.6.5-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted openwsman [armhf] (bionic-proposed) [2.6.5-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted openwsman [ppc64el] (bionic-proposed) [2.6.5-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted openwsman [arm64] (bionic-proposed) [2.6.5-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted openwsman [s390x] (bionic-proposed) [2.6.5-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted openwsman [i386] (bionic-proposed) [2.6.5-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted deepin-menu [sync] (bionic-proposed) [3.2.0-1]
-queuebot:#ubuntu-release- New: accepted openwsman [amd64] (bionic-proposed) [2.6.5-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted openwsman [armhf] (bionic-proposed) [2.6.5-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted openwsman [ppc64el] (bionic-proposed) [2.6.5-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted deepin-notifications [sync] (bionic-proposed) [3.1.2-1]
-queuebot:#ubuntu-release- New: accepted openwsman [i386] (bionic-proposed) [2.6.5-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted openwsman [arm64] (bionic-proposed) [2.6.5-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted openwsman [s390x] (bionic-proposed) [2.6.5-0ubuntu2]
-queuebot:#ubuntu-release- New binary: deepin-menu [s390x] (bionic-proposed/none) [3.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-menu [amd64] (bionic-proposed/none) [3.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-menu [ppc64el] (bionic-proposed/none) [3.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-menu [i386] (bionic-proposed/none) [3.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-notifications [s390x] (bionic-proposed/none) [3.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-notifications [amd64] (bionic-proposed/universe) [3.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-notifications [ppc64el] (bionic-proposed/universe) [3.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-notifications [i386] (bionic-proposed/universe) [3.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-menu [arm64] (bionic-proposed/universe) [3.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-menu [armhf] (bionic-proposed/universe) [3.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-notifications [arm64] (bionic-proposed/universe) [3.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-notifications [armhf] (bionic-proposed/universe) [3.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wsmancli [amd64] (bionic-proposed/universe) [2.6.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: wsmancli [ppc64el] (bionic-proposed/universe) [2.6.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: wsmancli [i386] (bionic-proposed/universe) [2.6.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: wsmancli [s390x] (bionic-proposed/universe) [2.6.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: wsmancli [arm64] (bionic-proposed/universe) [2.6.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: wsmancli [armhf] (bionic-proposed/universe) [2.6.0-0ubuntu1] (no packageset)
<flocculant> infinity: iso doesn't appear to have built last night (Saturday) for us - assume the cron thingymajig isn't sorted post beta
<infinity> flocculant: OOps.  Reenabling now.
<flocculant> infinity: :)
<infinity> flocculant: Fixed.
<flocculant> thanks - wasn't sure you'd be around hence saying Saturday :)
<flocculant> have a good weekend
<infinity> flocculant: I'm not around; this is all in your head.
<flocculant> ha ha ha - see you when I'm awake then :D
<acheronuk> morning
<flocculant> morning acheronuk
<acheronuk> is a new build scheduled now, or do I need to kick one?
<flocculant> you can kick one - if not it will build when cron tells it too - http://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/view/head:/etc/crontab
<flocculant> 4am tomorrow for kubuntu I think
<acheronuk> lol. I want one now
<flocculant> :)
<flocculant> best kick it then :D
<bashfulrobot> good morning infinity was the build cron an issue for all flavours?
<bashfulrobot> Although it looks like one ran about an hour ago if I am translating my time zones right
<bashfulrobot> So likely a moot question
<tsimonq2> Morning.
<tsimonq2> Can an AA please take a look here? https://lists.ubuntu.com/archives/ubuntu-quality/2018-March/007069.html
<tsimonq2> I think that was probably better suited towards ubuntu-release.
<rbasak> o/
<rbasak> I've been intending to deal with that.
 * rbasak leaves a note for himself for Monday
<tsimonq2> OK, cool. Thanks rbasak.
<rbasak> To be clear, I'm not an AA, but intend to file a bug and subscribe the AAs.
<jbicha> rbasak: I'm wondering if switching to mariabdb-10.3 would be best for Debian & Ubuntu?
<jbicha> ok, maybe a bad idea since 10.3 is not stable yet apparently
<jbicha> but why can't mariadb-10.2 be fixed so 10.1 can just be killed?
#ubuntu-release 2018-03-11
<rbasak> jbicha: I think otto's view is that it's too much of a mess and not practical to have in good shape for Bionic.
<jbicha> dropping an epoch when we're already in beta is a mess too
<rbasak> I suspect that can't be done
<rbasak> We'll just have to bump past it
<jbicha> otto's email seems really confusing. He doesn't explain why 10.2 couldn't work for 18.04 LTS
<jbicha> https://mariadb.org/about/maintenance-policy/
<rbasak> Feel free to reply and ask!
<rbasak> Otto has been looking after MariaDB in both Debian and Ubuntu for years
<rbasak> So I generally default to trusting his opinoin.
<jbicha> there's Debian bug 891641
<ubot5`> Debian bug 891641 in ftp.debian.org "RM: mariadb-10.2 -- ROM, NPOASR; skipping this version, upgrade path is 10.1 -> 10.3" [Normal,Open] http://bugs.debian.org/891641
<jbicha> not sure why he emailed the ubuntu-quality list :|
<rbasak> It's an edge case which he doesn't know how to handle in Ubuntu processes.
<rbasak> Just reply to ubuntu-release@ or whatever.
<rbasak> Note that Otto also has an upstream MariaDB hat.
<jbicha> I'm replyingâ¦
<foka> Hi!  I need help with getting golang-blackfriday (1.5.1-1) unstuck from bionic-proposed.  golang-blackfriday changed fixed (thus changed) its HTML output of footnotes, and so both golang-github-chaseadamsio-goorgeous and hugo had to be updated to a newer version to have their tests updated to match golang-blackfriday's new output.  I guess that's the reason the three packages somehow got stuck in the first place.
<foka> For some reasons, https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#golang-blackfriday shows that golang-blackfriday isn't picking up the newer versions of golang-github-chaseadamsio-goorgeous (should be -2 instead of -1) and hugo (should be 0.37.1-1 rather than 0.35-1 and 0.37-2)
<foka> So, I arrived here after reading this: https://wiki.ubuntu.com/ProposedMigration#How_could_installing_a_package_into_the_release_pocket_possibly_break_other_packages.3F
<foka> The latest versions of these three packages, already in bionic-proposed, should work nicely with one another, and should pass the Autopkgtest.  Thank you very much in advance for your help!  :-)
<ginggs> where did that foka go?
<acheronuk> lol
<ginggs> anyway, i retriggered those golang-blackfriday/hugo/golang-github-chaseadamsio-goorgeous test
-queuebot:#ubuntu-release- New binary: python-stringtemplate3 [amd64] (bionic-proposed/universe) [3.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: python-cloudkittyclient [amd64] (bionic-proposed/universe) [1.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyghmi [amd64] (bionic-proposed/universe) [1.0.32-3] (no packageset)
-queuebot:#ubuntu-release- New binary: cloudkitty [amd64] (bionic-proposed/universe) [7.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted cloudkitty [amd64] (bionic-proposed) [7.0.0-2]
-queuebot:#ubuntu-release- New: accepted deepin-menu [arm64] (bionic-proposed) [3.2.0-1]
-queuebot:#ubuntu-release- New: accepted deepin-menu [i386] (bionic-proposed) [3.2.0-1]
-queuebot:#ubuntu-release- New: accepted deepin-menu [s390x] (bionic-proposed) [3.2.0-1]
-queuebot:#ubuntu-release- New: accepted deepin-notifications [arm64] (bionic-proposed) [3.1.2-1]
-queuebot:#ubuntu-release- New: accepted deepin-notifications [i386] (bionic-proposed) [3.1.2-1]
-queuebot:#ubuntu-release- New: accepted deepin-notifications [s390x] (bionic-proposed) [3.1.2-1]
-queuebot:#ubuntu-release- New: accepted deepin-menu [amd64] (bionic-proposed) [3.2.0-1]
-queuebot:#ubuntu-release- New: accepted deepin-menu [ppc64el] (bionic-proposed) [3.2.0-1]
-queuebot:#ubuntu-release- New: accepted deepin-notifications [armhf] (bionic-proposed) [3.1.2-1]
-queuebot:#ubuntu-release- New: accepted python-cloudkittyclient [amd64] (bionic-proposed) [1.2.0-2]
-queuebot:#ubuntu-release- New: accepted deepin-menu [armhf] (bionic-proposed) [3.2.0-1]
-queuebot:#ubuntu-release- New: accepted deepin-notifications [ppc64el] (bionic-proposed) [3.1.2-1]
-queuebot:#ubuntu-release- New: accepted deepin-notifications [amd64] (bionic-proposed) [3.1.2-1]
-queuebot:#ubuntu-release- New: accepted python-pyghmi [amd64] (bionic-proposed) [1.0.32-3]
-queuebot:#ubuntu-release- New: accepted python-stringtemplate3 [amd64] (bionic-proposed) [3.1-3]
#ubuntu-release 2019-03-04
<cpaelzer> vorlon: thanks for letting me know, I'll reprep something that fits our needs then
<ginggs> would someone please remove src:mathicgb from disco ?  it's not compatible with recent googletest LP: #1811562
<ubot5> Launchpad bug 1811562 in mathicgb (Debian) "Please remove src:mathicgb" [Unknown,Confirmed] https://launchpad.net/bugs/1811562
-queuebot:#ubuntu-release- New: accepted netkit-ftp-ssl [sync] (disco-proposed) [0.17.34+0.2-4.1]
-queuebot:#ubuntu-release- New: accepted piuparts [amd64] (disco-proposed) [0.98]
-queuebot:#ubuntu-release- New binary: netkit-ftp-ssl [s390x] (disco-proposed/universe) [0.17.34+0.2-4.1] (no packageset)
-queuebot:#ubuntu-release- New binary: netkit-ftp-ssl [amd64] (disco-proposed/universe) [0.17.34+0.2-4.1] (no packageset)
-queuebot:#ubuntu-release- New binary: netkit-ftp-ssl [armhf] (disco-proposed/universe) [0.17.34+0.2-4.1] (no packageset)
-queuebot:#ubuntu-release- New binary: netkit-ftp-ssl [ppc64el] (disco-proposed/universe) [0.17.34+0.2-4.1] (no packageset)
-queuebot:#ubuntu-release- New binary: netkit-ftp-ssl [i386] (disco-proposed/universe) [0.17.34+0.2-4.1] (no packageset)
-queuebot:#ubuntu-release- New binary: netkit-ftp-ssl [arm64] (disco-proposed/universe) [0.17.34+0.2-4.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted netkit-ftp-ssl [amd64] (disco-proposed) [0.17.34+0.2-4.1]
-queuebot:#ubuntu-release- New: accepted netkit-ftp-ssl [armhf] (disco-proposed) [0.17.34+0.2-4.1]
-queuebot:#ubuntu-release- New: accepted netkit-ftp-ssl [ppc64el] (disco-proposed) [0.17.34+0.2-4.1]
-queuebot:#ubuntu-release- New: accepted netkit-ftp-ssl [arm64] (disco-proposed) [0.17.34+0.2-4.1]
-queuebot:#ubuntu-release- New: accepted netkit-ftp-ssl [s390x] (disco-proposed) [0.17.34+0.2-4.1]
-queuebot:#ubuntu-release- New: accepted netkit-ftp-ssl [i386] (disco-proposed) [0.17.34+0.2-4.1]
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64+mac [Trusty 14.04.6] (20190304) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Trusty 14.04.6] (20190304) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Trusty 14.04.6] (20190304) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Trusty 14.04.6] (20190304) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Trusty 14.04.6] (20190304) has been added
 * apw reviews snapd across the
<apw> board
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (cosmic-proposed) [2.37.4+18.10]
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-384 (xenial-proposed/universe) [384.130-0ubuntu0.16.04.1 => 384.130-0ubuntu0.16.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-384 (trusty-proposed/universe) [384.130-0ubuntu0.14.04.1 => 384.130-0ubuntu0.14.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-340 (xenial-proposed/restricted) [340.104-0ubuntu0.16.04.1 => 340.107-0ubuntu0.16.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-340 (trusty-proposed/restricted) [340.102-0ubuntu0.14.04.1 => 340.107-0ubuntu0.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-304 (xenial-proposed/restricted) [304.135-0ubuntu0.16.04.2 => 304.135-0ubuntu0.16.04.3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-304 (trusty-proposed/restricted) [304.135-0ubuntu0.14.04.1 => 304.135-0ubuntu0.14.04.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.37.4+18.04]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.37.4]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.37.4~14.04]
<ddstreet> seb128 for lp #1812760 why did you mark it verification-failed-bionic?
<ubot5> Launchpad bug 1812760 in systemd (Ubuntu Cosmic) "networkd: [Route] PreferredSource not working in *.network files" [Medium,Fix committed] https://launchpad.net/bugs/1812760
-queuebot:#ubuntu-release- Unapproved: live-build (trusty-proposed/main) [3.0~a57-1ubuntu11.4 => 3.0~a57-1ubuntu11.5] (desktop-core)
<cjwatson> sil2100: Could you do me a favour and run 'mark-suite-dirty -A ppa:snappy-dev/ubuntu/tools-proposed -s bionic' (from lp:ubuntu-archive-tools)?  That'll cause bionic to exist (after a publisher run) in http://ppa.launchpad.net/snappy-dev/tools-proposed/ubuntu/dists/, which would be helpful for some testing I'm doing
<sil2100> cjwatson: sure
<sil2100> cjwatson: should be done o/
<cjwatson> sil2100: cheers
<sil2100> Would be nice if someone could have a look at the trusty live-build changes for the initrd handling ^
<acheronuk> mwhudson vorlon: FYI, I reported the biopython test issue upstream earlier: https://github.com/biopython/biopython/issues/1945
<gitbot> biopython issue 1945 in biopython "Test precision failure on Ubuntu autopkgtests with glibc 2.29" [Open]
-queuebot:#ubuntu-release- Unapproved: accepted fonts-liberation2 [sync] (bionic-proposed) [2.00.1-7~18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice-l10n [sync] (bionic-proposed) [1:6.0.7-0ubuntu0.18.04.4]
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [sync] (bionic-proposed) [1:6.0.7-0ubuntu0.18.04.4]
<cpaelzer> I'm wondering about the whereabout of libsodium in trusty
<cpaelzer> I uploaded it as part of bug 1817665 on 26th of February
<ubot5> bug 1817665 in python-libnacl (Ubuntu Trusty) "Please SRU the pymacaroons stack to Trusty" [Undecided,Fix committed] https://launchpad.net/bugs/1817665
<cpaelzer> and I have got the arrival in NEW queue from LP on all three
<cpaelzer> but it seems vorlon could only see two in -NEW and accepted them
<cpaelzer> I fail to find where the remaining one (src:libsodium) went
<cpaelzer> From my POV it should still be in NEW of trust
<cpaelzer> y
<cpaelzer> but it isn't
<cpaelzer> anyone able to help me finding it or should I just re-upload
<cpaelzer> rbasak: you looked at the case in the past - have you had any issues seeing the uploads?
<cpaelzer> ha - I found it
<cpaelzer> it was accepted but missed an update to the bug
<cpaelzer> interesting
<cpaelzer> also it FTBFS which it didn't in the PPA that I had attached as proof
<cpaelzer> ok - I can go from here - sorry for the noise
<cpaelzer> umm the build started and stopped after 8 minutes - but for whatever reason LP doesn't show me logs oO?
<cpaelzer> rbasak: do you see build logs on https://launchpad.net/ubuntu/+source/libsodium/1.0.8-5~ubuntu14.04.1/+build/16438047 ?
<cpaelzer> I can hit retry but I want to understand as much as possible of this before I might trample on some evidence
<apw> cpaelzer, no build log normally indicates an initialisation failure, i've seen those with timouts pushing the .dsc, though those are normally near exact multiples of 5m
<apw> cpaelzer, and i don't see a log either
<rbasak> Yeah that ^
<juliank> Laney, sil2100 the order of rows changing all the time on autopkgtest request.cgi has been bugging me a bit, so I fixed it: https://code.launchpad.net/~juliank/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/363916
<juliank> :)
<juliank> Now I can switch between request tabs and easily compare them
<cpaelzer> apw: rbasak: so it seems safe that I hit retry then - thanks
<seb128> ddstreet, hey, arg sorry, I forgot to comment on it, it's because of bug #1818340 which is reported as a regression, to make sure we don't validate the SRU by error before that one is sorted out
<ubot5> bug 1818340 in systemd (Ubuntu) "systemd-networkd core dumps in bionic-proposed" [High,New] https://launchpad.net/bugs/1818340
<seb128> xnox-, ^ would be nice to have your input on that one
<seb128> ddstreet, I subscribed you to the new one though, before adding a comment saying why I was failing the SRU bug
<ddstreet> ok thnx, i'll look at the new one
<seb128> thx
<cpaelzer> rbasak: apw: FYI as expected the rebuild worked fine
<cpaelzer> odd case, but relieving that the resut was as expected
<cjwatson> apw: not necessarily initialisation; any kind of catastrophic builder crash will do it too
<cjwatson> or network failures during the build
-queuebot:#ubuntu-release- New binary: python-libnacl [i386] (trusty-proposed/universe) [1.4.5-0ubuntu1~ubuntu14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox (xenial-proposed/multiverse) [5.1.38-dfsg-0ubuntu1.16.04.2 => 5.1.38-dfsg-0ubuntu1.16.04.3] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: virtualbox-lts-xenial (trusty-proposed/multiverse) [4.3.36-dfsg-1+deb8u1ubuntu1.14.04.1~14.04.4 => 4.3.36-dfsg-1+deb8u1ubuntu1.14.04.1~14.04.5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (xenial-proposed/multiverse) [5.1.38-dfsg-0ubuntu1.16.04.1 => 5.1.38-dfsg-0ubuntu1.16.04.2] (no packageset)
<cpaelzer> apw: thanks for helping before - you seem to be the AA being aroudn right now. bug 1817665 which my wondering about failed builds was before is about three packages with build dep each other
<ubot5> bug 1817665 in python-libnacl (Ubuntu Trusty) "Please SRU the pymacaroons stack to Trusty" [Undecided,Fix committed] https://launchpad.net/bugs/1817665
<cpaelzer> apw: but also each of them will hit new queue, so while steve did that for the first already I'm now at https://launchpad.net/ubuntu/+source/python-libnacl/1.4.5-0ubuntu1~ubuntu14.04.1 in trusty-new and somewhen after acceptign that will see the same for pymacaroons
<cpaelzer> apw: might I ask you to accept https://launchpad.net/ubuntu/+source/python-libnacl/1.4.5-0ubuntu1~ubuntu14.04.1 in NEW?
<cpaelzer> or am I misreading the NEW that launchpad shows me
<cpaelzer> as it is not in the classic "new queue" anymore
<cpaelzer> there are too many things called NEW, time they get OLD
<cpaelzer> hmm I can build pymacaroons now it seems, so it is - as I assumed - a different NEW
<cpaelzer> apw: TL;DR no action needed right now
 * cpaelzer goes mad for too many things at once and searches a cup of tea
<cpaelzer> hmm, I spoke too soon - I again got "Missing build dependencies: python3-libnacl"
<cpaelzer> so it might mean that the NEW being listed means some NEW queue - well for the Binaries maybe?
<cpaelzer> yeah https://launchpad.net/ubuntu/+source/python-libnacl/1.4.5-0ubuntu1~ubuntu14.04.1/+build/16438055 is very literal about it "Binary packages awaiting approval in NEW queue"
<cpaelzer> apw: so I was right with my initial request, might I ask you to accept those?
<cpaelzer> rbasak: for our discussions if SRU-NEW queues go right to -proposed - It is true for the src-pacakge but Binaries seem to pop into needing NEW approval again (see above)
<cpaelzer> I must admit I don't see why https://launchpad.net/ubuntu/+source/libsodium/1.0.8-5~ubuntu14.04.1 didn't trigger the same
<cpaelzer> but I hope apw might explain me later when he gets to that
<apw> cpaelzer, i would say it never built on i386 before
<apw> cpaelzer, in fact it never existed before ... and i386 is arch:all
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (trusty-proposed/main) [2.208.15 => 2.208.16] (desktop-core)
<cpaelzer> apw: yep - as I said it was going to the new queue where vorlon accepted the source
<cpaelzer> apw: just now after the build of libsodium all seems fine, but on python-libnacl the binaries are listed to be in NEW
<cpaelzer> apw: and the whole point of the bug those are associated to is to bring all three packages formerly not in trusty at all to trusty
<cpaelzer> that is bug 1817665
<ubot5> bug 1817665 in python-libnacl (Ubuntu Trusty) "Please SRU the pymacaroons stack to Trusty" [Undecided,Fix committed] https://launchpad.net/bugs/1817665
-queuebot:#ubuntu-release- Unapproved: python-eventlet (bionic-proposed/main) [0.20.0-4 => 0.20.0-4ubuntu0.18.04.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-eventlet (cosmic-proposed/main) [0.20.0-5 => 0.20.0-5ubuntu0.18.10.1] (openstack, ubuntu-server)
<cpaelzer> libsodium was not arch_all that was "normal" binaries per arch
<cpaelzer> might that have been the reason it was not triggering NEW "again" ?
<cpaelzer> while src:python-libnacl  with binaries python-libnacl and python3-libnacl are held again in NEW for the Binaries
-queuebot:#ubuntu-release- Unapproved: accepted live-build [source] (trusty-proposed) [3.0~a57-1ubuntu11.5]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (trusty-proposed) [2.208.16]
<apw> cpaelzer, and accepted
<cpaelzer> thank you
-queuebot:#ubuntu-release- New: accepted python-libnacl [i386] (trusty-proposed) [1.4.5-0ubuntu1~ubuntu14.04.1]
<cpaelzer> if pymacaroons behaves the same I might ping again once built
<sil2100> plz no releases into trusty-updates kthx
<vorlon> sil2100: I guess maybe we shouldn't be trying to build panda images for 14.04.6
<sil2100> vorlon: ah, I thought I saw them in .5, but I now see we actually didn't
<sil2100> Ok, so my livecd-rootfs change is not needed then
<sil2100> I mean, I'll release it into -updates later anyway so that the version number doesn't get burned down, the change is harmless in overall
<vorlon> sil2100: even if we had released them, we certainly shouldn't be doing testing on panda now
-queuebot:#ubuntu-release- New binary: pymacaroons [i386] (trusty-proposed/universe) [0.9.2-0ubuntu1~ubuntu14.04.1] (no packageset)
<rbasak> sil2100: please could you delete python-certbot-nginx from xenial-proposed? This isn't part of the current SRU and is no longer planned to be landed.
<rbasak> It'd be good to delete it in advance just in case (unlikely) people verifying the new SRU are relying on that somehow.
<cpaelzer> apw: now the same again for https://launchpad.net/ubuntu/+source/pymacaroons/0.9.2-0ubuntu1~ubuntu14.04.1/+build/16438056
<cpaelzer> apw: this is the last of that stack of packages
<teward> rbasak: anyone relying on it is going to get smacked by me, because it breaks things.
<rbasak> teward: in Xenial, or in general?
<rbasak> But anyway, we're agreed then ?:)
<teward> rbasak: in general, it does SSL configuration which has some headaches with multisite
<teward> but I'm for dropping it in the existing SRU(s)
<teward> rbasak: but i'm talking from an NGINX Generic Support perspective
<cpaelzer> rbasak: I read teward as that being just one more reason to remove it from proposed
<teward> it *works* with single sites.
<Odd_Bloke> vorlon: vagrant is still stuck in disco-proposed, and I'm not sure why; updates_excuses.html looks clear, so I assume it's some dark magic^W^Winstallability issue?
<teward> cpaelzer: please remove it from proposed, I'd sooner torch it in all releases but that's not my call.
<rbasak> teward: does upstream have bug reports on your concern
<rbasak> ?
<rbasak> They are quite responsive
<teward> rbasak: i've talked privately with them, it's more how it does its autoconfigs that results in a HUGE number of SSL config headaches that we see complained about in #nginx
<teward> but they don't have a 'fix' because it's more for 'simple' deployments, rather than more complex deployments - certbot provides a certonly mode which is what I"ve pushed my recommendations with
<teward> which *doesn't* break the configs already in place, and just gens the cert and you point your nginx configs there.
<teward> but that's more me being overly picky about
<rbasak> Should it maybe detect 'complex' and fail more gracefully, recommending certonly itself?
<teward> rbasak: probably, but because of the *really* varying definitions of 'complex' it'd be difficult to ID probably
<teward> cerbot's been on my radar as a headache that i try to avoid with its nginx plugins
<teward> but *that* complaint is not enough on its own to purge it globally
<teward> but for Xenial if it was never in there, drop it from -proposed
<sil2100> rbasak: will do
<vorlon> Odd_Bloke: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt shows sonic-pi becomes uninstallable
<vorlon> (because ruby-i18n has to be updated at the same time as vagrant, and something in ruby-i18n makes sonic-pi uninstallable)
<teward> rbasak: i'll gen an example and share it separately, but i've got a thousand things at work that need my attention first
<Odd_Bloke> vorlon: Exciting stuff; thanks!
<teward> rbasak: *currently* it doesn't 'break' unless you're trying to use the nginx plugin to configure multiple configs at once - *that* is where it can explodify.
-queuebot:#ubuntu-release- Unapproved: packagekit (cosmic-proposed/main) [1.1.10-1ubuntu7 => 1.1.10-1ubuntu7.1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: packagekit (bionic-proposed/main) [1.1.9-1ubuntu2.18.04.4 => 1.1.9-1ubuntu2.18.04.5] (desktop-core)
-queuebot:#ubuntu-release- New: accepted pymacaroons [i386] (trusty-proposed) [0.9.2-0ubuntu1~ubuntu14.04.1]
<cpaelzer> vorlon: I see you are around already - maybe you could do the accept of the binary packages in https://launchpad.net/ubuntu/+source/pymacaroons/0.9.2-0ubuntu1~ubuntu14.04.1/+build/16438056
<cpaelzer> apw: helped me to get the other one processed, but that is still missing
<cpaelzer> I see somebody said yes to those packages since the last reload that I did - thanks to vorlon/apw or whoever did it
<vorlon> cpaelzer: I don't see any binaries waiting in the trusty new queue
<vorlon> ok
<apw> cpaelzer, pretty sure that 2 lines above says it is already done
<cpaelzer> it does
<Odd_Bloke> vorlon: So I've just spun up an i386 lxd container and installing vagrant/ruby-i18n and sonic-pi simultaneously didn't raise any issues; do you have any hints as to how I can go about reproducing the problem?
<sil2100> infinity: hey! Any reason we still have bionic daily builds disabled?
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Trusty 14.04.6] (20190304.2) has been added
<sil2100> hmm
<sil2100> jibel: ^ ok, so i386 seems to have succeeded, but the amd64 livefs failed to build with -proposed enabled, looks like some strange kernel conflict
<jibel> sil2100, can you build without proposed?
<sil2100> Wonder if that's not caused by the trusty kernels that are in -proposed right now
<jibel> and if it passes we're happy
<sil2100> Yeah, I'm thinking even of just kicking a livefs build without cdimage
<jibel> most of the build time is spent in livecd-rootfs so just trigger a build and if there are images then we're good
<jibel> given the error, I am not sure a build without proposed will fix it
<sil2100> jibel: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/trusty/ubuntu/+build/158473 <- it looks like it did
<jibel> cool
<sil2100> jibel: you want me to do a livefs build with -proposed disabled but with the live-build change included?
<sil2100> Anyway, I'll look at the logs in a moment once again, but I'd just push it out to -updates and see how it goes
<jibel> sil2100, yeah, sorry I thought you already pushed the fix
<abeato> vorlon, hey, any chances initramfs-tools-devices can move forward from https://launchpad.net/ubuntu/disco/+queue ?
<vorlon> abeato: I'll queue that up for review today
<abeato> vorlon, sounds good, thanks
-queuebot:#ubuntu-release- Unapproved: unity (bionic-proposed/universe) [7.5.0+18.04.20180413-0ubuntu1 => 7.5.0+18.04.20190304-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: unity (cosmic-proposed/universe) [7.5.0+18.10.20180926.2-0ubuntu1 => 7.5.0+18.10.20190304-0ubuntu1] (no packageset) (sync)
<vorlon> infinity: what's your plan for the remaining glibc autopkgtest regressions?
<infinity> sil2100: bionic dailies were still disabled to avoid stepping on your toes with xenial and trusty.
<infinity> vorlon: Is it just down to two now, or am I scrolling too fast?
<vorlon> infinity: python-biopython + postgresql-hll are the two I know about and don't have an answer for
<infinity> postgresql-hll/all and python-biopython/ppc64el is what I see.
<vorlon> yes
<infinity> Kay, I shall investigate and blame today, and if blame's not mine, hint.
<vorlon> Odd_Bloke: ruby-activesupport (et al.) in disco release pocket have a versioned depend on older ruby-i18n, so if you're enabling -proposed for all and using that, it'll look fine since it's fixed there (but stuck)
<vorlon> Odd_Bloke: found via lp:~vorlon/ubuntu-archive-tools/update-output-helper , ./update-output-helper -u, ./update-output-helper ruby-i18n/1.5.3-1 vagrant/2.2.3+dfsg-1ubuntu1
<vorlon> Laney: ^^ fwiw I seem to have warmed to this tool since you first submitted it for review, and now use it exclusively for debugging update_output, maybe we should revisit merging it :)
<Odd_Bloke> vorlon: Ack, thank you!
<vorlon> Odd_Bloke: also, since ruby-activesupport == rails, and there was discussion w/ server team that we should remove rails rather than maintaining it as debs, perhaps someone wants to socialize that further...
<infinity> vorlon: Oh, and nag re: tidying ubuntu-core history on nusakan.
<vorlon> infinity: I'm not going to do it by hand, I'm going to land sil2100's branch (if it's ready)
<vorlon> sil2100: ^^ is it ready?
<vorlon> (afaics it's not so urgent that I should do it by hand)
<infinity> I mean, we ran out of disk doing the last point release, so... Not urgent when I clean up after, but urgent if we like having breathing room.
<infinity> The trusty one will be a lot smaller though (only Ubuntu), so *shrug*.
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64+mac [Trusty 14.04.6] has been updated (20190304.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Trusty 14.04.6] has been updated (20190304.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Trusty 14.04.6] has been updated (20190304.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Trusty 14.04.6] has been updated (20190304.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Trusty 14.04.6] has been updated (20190304.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64+mac [Trusty 14.04.6] (20190304.4) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Trusty 14.04.6] (20190304.4) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Trusty 14.04.6] has been updated (20190304.4)
<infinity> sil2100: Why the changes for omap?  I'm about 103% sure there were not trusty omap images...
<infinity> s/not/no/
<infinity> sil2100: The part where I can find no omap images in www/ at all probably backs up that assertion.
<sil2100> infinity: that's invalid, I thought I saw those in .5 but I saw wrong, I didn't build them now for instance
<sil2100> I mean, my change was not needed
<infinity> Indeed.
<sil2100> But oh well, since I pushed it to -proposed I just let it out not to have a missing version number
<infinity> Also mostly harmless if you're not building images, so carry on.
<sil2100> And vcs
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Trusty 14.04.6] (20190304.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Trusty 14.04.6] (20190304.1) has been added
<acheronuk> infinity: upstream biopython don't seem bothered by that ppc64el fail: https://github.com/biopython/biopython/issues/1945
<gitbot> biopython issue 1945 in biopython "Test precision failure on Ubuntu autopkgtests with glibc 2.29" [Open]
<infinity> acheronuk: Yeah, I found my way there literally just now. :P
<infinity> By way of debian/changelog -> old ticket -> new ticket.
<infinity> *sigh*
<infinity> acheronuk: So, yes, will upload a quick fix for that.
<infinity> acheronuk: Unless you want to do the honors.
<infinity> acheronuk: And since there seems to be parallel effort here, did you have any insight on postgresql-hll before I go stare at that one?
<acheronuk> infinity: sadly, no upload permissions for that. also not really at the right machine to put something to sponsor together, so I would suggest you just do it :)
<acheronuk> no clue on that one. sorry
<infinity> acheronuk: Sure, I'll JFDI, you can feel free to do the upstream PR though.
<infinity> (I mean, it's a 1-char change, not sure why they're asking for a PR, but I guess they want to give you credit, which is nice)
<acheronuk> yeah. I'm really waiting on upstream to comment back if they want to change more than just that one line and reduce the required precision for the rest of that group of tests
<acheronuk> as the last comment implied they might
<infinity> That feels safest, probably, but one could also make a slippery slope argument that once you reduce by a place on all tests, you might fail to catch an actual rounding regression, or think next month it's okay to go from 4 to 3 or...
<infinity> But meh.
<infinity> Asking for 5 places from fastish math is asking a lot.
<acheronuk> I know, but as 1st time I ever looked at these tests is today, I figured their call is best
<acheronuk> fi they go silent on it, I'll just PR that one
<acheronuk> *if
<infinity> *nod*
<doko> vorlon: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output_notest.txt shows much more migration issues. see my question here from Friday
<vorlon> doko: were you testing with update-output-helper?
<doko> vorlon: yes, and it doesn't work. L aney posted an update here: https://gist.github.com/iainlane/6360602ebd945f0f6c7a126091f02b79
<doko> looks like an unfinished mutter transition
<ginggs> would someone please remove src:mathicgb from disco ?  it's not compatible with recent googletest LP: #1811562
<ubot5> Launchpad bug 1811562 in mathicgb (Debian) "Please remove src:mathicgb" [Unknown,Confirmed] https://launchpad.net/bugs/1811562
<jibel> Are Ubuntu Desktop amd64+mac really something we want to release (and test) for 14.04.6?
<infinity> jibel: We did for every previous point release, so meh.
<jibel> not sure I'll be able to find the hardware somewhere.
<infinity> Well, that could be problematic indeed if we have nowhere to test.
<infinity> And if not, we can just not release that one.
-queuebot:#ubuntu-release- Unapproved: golang-1.8 (bionic-proposed/universe) [1.8.3-2ubuntu1 => 1.8.3-2ubuntu1.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: golang-1.8 (cosmic-proposed/universe) [1.8.3-2ubuntu1 => 1.8.3-2ubuntu1.18.10.1] (lubuntu, ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: rejected golang-1.8 [source] (bionic-proposed) [1.8.3-2ubuntu1.1]
<vorlon> abeato: fwiw 'lintian -I' shows some minor issues in the initramfs-tools-devices source package
-queuebot:#ubuntu-release- New: accepted initramfs-tools-devices [source] (disco-proposed) [0.3]
-queuebot:#ubuntu-release- New binary: initramfs-tools-devices [amd64] (disco-proposed/universe) [0.3] (no packageset)
<vorlon> acheronuk, tsimonq2: Debian removed soprano from unstable in January; but it still has revdeps in Ubuntu.  Should we be nuking the rest of that kde4 stack?
<tsimonq2> vorlon: ack on nuking as much of KDE 4 as possible. :P
<tsimonq2> (Go ahead.)
<vorlon> tsimonq2: that includes amarok which is currently seeded
<vorlon> tsimonq2: do you care to update the seed?
<tsimonq2> vorlon: I'll do that within the hour.
<vorlon> tsimonq2: kde-runtime still has a ton of revdeps
<tsimonq2> vorlon: Are any of those seeded? (I'm not at a computer.)
<vorlon> don't know yet
<tsimonq2> ack
<tsimonq2> kde-runtime and rdeps should be removed as well.
<vorlon> tsimonq2: but e.g. basket is not removed from Debian testing yet and doesn't have any bug reports above wishlist about this (Debian bug #874829)
<ubot5> Debian bug 874829 in src:basket "[basket] Future Qt4 removal from Buster" [Wishlist,Open] http://bugs.debian.org/874829
<tsimonq2> I believe the KDE 4 removal bugs were filed as wishlist, I don't quote recall.
<tsimonq2> I also don't know if it's changed from being a Buster goal.
<tsimonq2> Regardless, I support removal of KDE 4 completely.
<vorlon> tsimonq2: and then for an unrelated stack, Debian also removed lxqt-l10n as 'obsolete source package' but it's not an obsolete source package in Ubuntu...
<tsimonq2> Upstream couldn't makw up their mind. :P
<tsimonq2> 0.12 was l10n in individual packages, 0.13 was all into lxqt-l10n, 0.14 is back  to 0m12 behavior
<tsimonq2> *0.12
 * tsimonq2 finds a computer so I can type properly.
<tsimonq2> vorlon: amarok removed from the Kubuntu seed.
-queuebot:#ubuntu-release- Unapproved: systemd (cosmic-proposed/main) [239-7ubuntu10.9 => 239-7ubuntu10.10] (core)
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.14 => 237-3ubuntu10.15] (core)
<ddstreet> vorlon hey, im back with systemd again :)  for lp #1818340: it appears the backport for lp #1812760 was incomplete/incorrect so reverted those patches and re-uploaded to -proposed.  should be a relatively easy review, as it's only removing patches you already looked at.  for the original bug, i'll take it over since dja did the original work, but has left
<ubot5> Launchpad bug 1818340 in systemd (Ubuntu Cosmic) "systemd-networkd core dumps in bionic-proposed" [Critical,In progress] https://launchpad.net/bugs/1818340
<ubot5> Launchpad bug 1812760 in systemd (Ubuntu Cosmic) "networkd: [Route] PreferredSource not working in *.network files" [Medium,Fix committed] https://launchpad.net/bugs/1812760
-queuebot:#ubuntu-release- Unapproved: gdm3 (bionic-proposed/main) [3.28.3-0ubuntu18.04.4 => 3.28.3-0ubuntu18.04.5] (ubuntu-desktop)
<vorlon> ddstreet: instead of including both the changelog entry for the previous upload and a new changelog entry marking this as a revert, could you please consolidate into a single changelog entry that only describes the differences vs current -updates?
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64+mac [Trusty 14.04.6] has been updated (20190304.5)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Trusty 14.04.6] has been updated (20190304.5)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Trusty 14.04.6] has been updated (20190304.5)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Trusty 14.04.6] has been updated (20190304.2)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64+mac [Trusty 14.04.6] has been updated (20190304.2)
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Trusty 14.04.6] has been updated (20190304.2)
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Trusty 14.04.6] has been updated (20190304.2)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Trusty 14.04.6] has been updated (20190304.2)
#ubuntu-release 2019-03-05
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Trusty 14.04.6] has been updated (20190304.2)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Trusty 14.04.6] has been updated (20190304.2)
<bluesabre> Hello release team! Please release xfce4-settings 4.13.4-1ubuntu2 into disco so we can begin the SRU process for cosmic :)
<tsimonq2> bluesabre: It looks like you're waiting on glibc: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#xfce4-settings
<tsimonq2> As far as I remember, we're close.
<bluesabre> tsimonq2, aha, thanks for that :)
<tsimonq2> No problem at all. :)
<tsimonq2> bluesabre: If you haven't seen it already, I'd take a look here: https://wiki.ubuntu.com/ProposedMigration
<tsimonq2> It Almost Alwaysâ¢ï¸ explains why a package is stuck.
<tsimonq2> (Scroll up about six hours ago, Adam and Steve were talking about the remaining regressions.)
<bluesabre> thanks again tsimonq2... I think this might be the first time I ran into a proposed blocker during during the dev cycle :D
<tsimonq2> No problem, feel free to ping me if you need any other hints (not literally, I'm not on the release team, heh). :)
-queuebot:#ubuntu-release- New binary: snapd-glib [amd64] (disco-proposed/main) [1.46-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: snapd-glib [s390x] (disco-proposed/main) [1.46-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: snapd-glib [i386] (disco-proposed/main) [1.46-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: snapd-glib [ppc64el] (disco-proposed/main) [1.46-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: snapd-glib [arm64] (disco-proposed/main) [1.46-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: snapd-glib [armhf] (disco-proposed/main) [1.46-0ubuntu1] (desktop-core)
<infinity> bluesabre: For what it's worth, the SRU process does not require that it's migrated in devel before you upload to other releases.
<infinity> bluesabre: Just that it's uploaded to proposed and migration is expected (ie: it's not FTBFS or causing autopkgtest regressions)
<abeato> vorlon, thanks, will take a look
<pieq> jibel, hi!
<jibel> hey pieq
<pieq> jibel, regarding i386 testing for trusty, can we use any device (even newer ones) or should we stick with older ones?
<jibel> pieq, you can use any
<pieq> jibel, got it, thanks!
<doko> jbicha: your ansible upload breaks at least os-faults. please fix
<doko> jamespage, coreycb: ^^^
<jbicha> doko: see bug 1813600
<ubot5> bug 1813600 in os-faults (Ubuntu) "[RM] os-faults" [Undecided,New] https://launchpad.net/bugs/1813600
<doko> oSoMoN, sil2100: http://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html  should the libreoffice/i386 autopkg test regression be ignored (updating the hint), or fixed?
-queuebot:#ubuntu-release- New: accepted initramfs-tools-devices [amd64] (disco-proposed) [0.3]
-queuebot:#ubuntu-release- New: accepted snapd-glib [arm64] (disco-proposed) [1.46-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted snapd-glib [i386] (disco-proposed) [1.46-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted snapd-glib [s390x] (disco-proposed) [1.46-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted snapd-glib [amd64] (disco-proposed) [1.46-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted snapd-glib [ppc64el] (disco-proposed) [1.46-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted snapd-glib [armhf] (disco-proposed) [1.46-0ubuntu1]
<oSoMoN> doko, it was run against the wrong version of openjdk-11
<oSoMoN> (10.0.2+13-1ubuntu0.18.04.4)
<oSoMoN> I retried it
<ddstreet> sil2100 can you reject the systemd uploads to b/c, so can reupload with corrected changelog
<Laney> vorlon: very nice, I had just been quietly using / developing it in a minor way myself & had given up on getting it merged
<Laney> actually yesterday doko was pinging me about a bug in it and I fixed that (possibly) :>
<ginggs> doko: i was about to upload https://launchpad.net/~ginggs/+archive/ubuntu/sru/+sourcepub/9948222/+listing-archive-extra once the tests finish
<doko> ginggs: ouch
<ginggs> monotone was removed from disco a few hours ago
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Trusty 14.04.6] (20190305) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Trusty 14.04.6] (20190305) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Trusty 14.04.6] (20190305) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Trusty 14.04.6] (20190305) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base powerpc [Trusty 14.04.6] (20190305) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Trusty 14.04.6] (20190305) has been added
<bluesabre> infinity, oh, right on :)
-queuebot:#ubuntu-release- Unapproved: open-vm-tools (bionic-proposed/main) [2:10.3.0-0ubuntu1~18.04.3 => 2:10.3.5-7~ubuntu0.18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: open-vm-tools (cosmic-proposed/main) [2:10.3.0-0ubuntu3 => 2:10.3.5-7~ubuntu0.18.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<cpaelzer_> jamespage: juergh: I tried to link our old bug 1736390 to your recent mail to OVS "openvswitch crash on i386"
<ubot5> bug 1736390 in linux (Ubuntu Cosmic) "openvswitch: kernel oops destroying interfaces on i386" [High,In progress] https://launchpad.net/bugs/1736390
<cpaelzer> juergh: they really seem to be the same thing to me
<cpaelzer> juergh: thanks for picking it up again
<sil2100> Laney: heeeeeey, you have access to snakefruit, right?
 * Laney snakes towards sil2100 
<Laney> yeah, what do you need?
<sil2100> Laney: I'd need an archive snapshotty done for 14.04.6 ;)
<sil2100> Laney: I guess that would be something like `point-release-snapshot trusty trusty.6-security-updates-snapshot`, right?
<Laney> oh gosh
<Laney> I've never done that before
<Laney> I can see the xenial command that someone used ...
<sil2100> Yeah, do the same just with s/xenial/trusty/, the xenial one was ran by vorlon and infinity so they had to know what they were doing
<sil2100> ;)
<sil2100> Not sure how long it takes
<sil2100> So possibly do it in a screen session
<Laney> ok I read the script, seems simple enough
<Laney> done
<Laney> it only copies dists/ of security & updates, so takes no time
<doko> ginggs: do you want continue with merucrial, or should I?
<sil2100> Laney: thanks o/
<ginggs> doko: can you back out version 4-9.2ubuntu1 ?
<doko> ginggs, remove it from -proposed?
-queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (bionic-proposed) [237-3ubuntu10.15]
-queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (cosmic-proposed) [239-7ubuntu10.10]
<ginggs> doko: will that allow me to upload 4.8.2-1ubuntu3 ?
<apw> ginggs, yes
-queuebot:#ubuntu-release- Unapproved: systemd (cosmic-proposed/main) [239-7ubuntu10.9 => 239-7ubuntu10.10] (core)
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.14 => 237-3ubuntu10.15] (core)
<ginggs> apw: ok, will you please do that, then i'll upload
<apw> ginggs, from where, and "why" for the logs
<ginggs> apw:  4-9.2ubuntu1 from disco-proposed - new version breaks hg-git
<apw> ginggs, and you have confirmed nothing is built with it ...
<ginggs> apw: hmm, how do i do that?
<apw> ginggs, look at the reverse-depends and see if any of them is in -propsoed as a first step
<ginggs> apw: i don't see any of the reverse-build-dependencies in -proposed
<apw> ginggs, then we are probabally ok
<apw> ok gone
<ginggs> apw: ta!
-queuebot:#ubuntu-release- Unapproved: netbeans (bionic-proposed/universe) [10.0-2~18.04 => 10.0-3~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libjavaewah-java (bionic-proposed/universe) [0.6.12-2 => 0.7.9-1~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libjogl2-java (bionic-proposed/universe) [2.3.2+dfsg-7 => 2.3.2+dfsg-8~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: scilab (bionic-proposed/universe) [6.0.1-1ubuntu1 => 6.0.1-7~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted netbeans [sync] (bionic-proposed) [10.0-3~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted libjavaewah-java [sync] (bionic-proposed) [0.7.9-1~18.04.1]
<ginggs> apw: based on my ppa test earlier, we are going to need 'force-badtest mercurial/4.8.2-1ubuntu3/arm64'
<ginggs> apw: and p.itti's 'force-badtest mercurial/all/armhf' can probably be dropped (or at least made more specific)
<apw> ginggs, always going to need some background to do that
-queuebot:#ubuntu-release- Unapproved: accepted libjogl2-java [sync] (bionic-proposed) [2.3.2+dfsg-8~18.04]
<ginggs> apw: we already have a hint for 4.8.2-1ubuntu2, so it's just bumping that
<apw> ginggs, ok
<ginggs> and it has been passing on armhf lately, although somewhat flaky
-queuebot:#ubuntu-release- Unapproved: accepted scilab [sync] (bionic-proposed) [6.0.1-7~18.04]
-queuebot:#ubuntu-release- New source: wslu (disco-proposed/primary) [1.9+dfsg1-0ubuntu1]
<rbalint> ^ i'm looking for a friendly archive admin here :-)
-queuebot:#ubuntu-release- New: accepted wslu [source] (disco-proposed) [1.9+dfsg1-0ubuntu1]
<didrocks> rbalint: NEWED ^
-queuebot:#ubuntu-release- New binary: wslu [amd64] (disco-proposed/none) [1.9+dfsg1-0ubuntu1] (no packageset)
<rbalint> didrocks, thanks!
<didrocks> rbalint: yw, I'll binNEW in a moment
-queuebot:#ubuntu-release- New: accepted wslu [amd64] (disco-proposed) [1.9+dfsg1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (cosmic-proposed) [239-7ubuntu10.10]
-queuebot:#ubuntu-release- Unapproved: libxkbcommon (bionic-proposed/main) [0.8.0-1ubuntu0.1 => 0.8.2-1~ubuntu18.04.1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu10.15]
-queuebot:#ubuntu-release- Unapproved: rejected libxkbcommon [source] (bionic-proposed) [0.8.2-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: libxkbcommon (bionic-proposed/main) [0.8.0-1ubuntu0.1 => 0.8.2-1~ubuntu18.04.1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: gluegen2 (bionic-proposed/universe) [2.3.2-6 => 2.3.2-7~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gluegen2 [sync] (bionic-proposed) [2.3.2-7~18.04]
 * Laney fist bumps juliank 
<Laney> just used ADT_PACKAGE for the first time
<Laney> this wins
<juliank> :)
<juliank> Laney: I've used it a few times already, as did other(s?)
<Laney> it's actualy surprisingly fast
<Laney> -u filtering was quite slow on there
<juliank> Laney: I think it's doing an indexed search
<juliank> Laney: You can also ask it journalctl -F ADT_PACKAGE and it would show you all values it has seen
<Laney> that's nice
<doko> LocutusOfBorg: https://launchpadlibrarian.net/413357077/buildlog_ubuntu-bionic-amd64.virtualbox-hwe_5.2.18-dfsg-3~ubuntu18.04.2_BUILDING.txt.gz  this needs an update for openjdk-11
-queuebot:#ubuntu-release- New sync: eclipse-debian-helper (bionic-proposed/primary) [1.5~18.04]
-queuebot:#ubuntu-release- New sync: eclipse-jdt-debug (bionic-proposed/primary) [4.10-2~18.04]
-queuebot:#ubuntu-release- New sync: eclipse-platform-debug (bionic-proposed/primary) [4.10-1~18.04]
-queuebot:#ubuntu-release- New sync: eclipse-jdt-core (bionic-proposed/primary) [4.10-1~18.04]
-queuebot:#ubuntu-release- New sync: eclipse-platform-resources (bionic-proposed/primary) [4.10-1~18.04]
-queuebot:#ubuntu-release- Unapproved: eclipse-emf (bionic-proposed/universe) [2.8.3-2 => 2.16.0-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: eclipse-jdt-ui (bionic-proposed/primary) [4.10-1~18.04]
-queuebot:#ubuntu-release- Unapproved: ecj (bionic-proposed/universe) [3.13.3-1 => 3.16.0-1~18.04] (kubuntu) (sync)
-queuebot:#ubuntu-release- New sync: eclipse-platform-runtime (bionic-proposed/primary) [4.10-1~18.04]
-queuebot:#ubuntu-release- New sync: eclipse-platform-text (bionic-proposed/primary) [4.10-1~18.04]
-queuebot:#ubuntu-release- New sync: eclipse-platform-ui (bionic-proposed/primary) [4.10-1~18.04]
-queuebot:#ubuntu-release- New sync: equinox-bundles (bionic-proposed/primary) [4.10-1~18.04]
-queuebot:#ubuntu-release- New sync: equinox-p2 (bionic-proposed/primary) [4.10-1~18.04]
-queuebot:#ubuntu-release- New sync: eclipse-platform-team (bionic-proposed/primary) [4.10-1~18.04]
-queuebot:#ubuntu-release- New sync: el-api (bionic-proposed/primary) [3.0.0-2~18.04]
-queuebot:#ubuntu-release- Unapproved: jetty9 (bionic-proposed/universe) [9.2.23-1 => 9.4.15-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: eclipse-platform-ua (bionic-proposed/primary) [4.10-1~18.04]
-queuebot:#ubuntu-release- New sync: equinox-framework (bionic-proposed/primary) [4.10-1~18.04]
-queuebot:#ubuntu-release- New sync: jsp-api (bionic-proposed/primary) [2.3.4-2~18.04]
-queuebot:#ubuntu-release- New sync: tomcat9 (bionic-proposed/primary) [9.0.16-3~18.04]
-queuebot:#ubuntu-release- New sync: servlet-api (bionic-proposed/primary) [4.0.1-2~18.04]
-queuebot:#ubuntu-release- New sync: websocket-api (bionic-proposed/primary) [1.1-1~18.04]
-queuebot:#ubuntu-release- Unapproved: swt4-gtk (bionic-proposed/universe) [4.6.3-2 => 4.10.0-3~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: tomcat8 (bionic-proposed/universe) [8.5.30-1ubuntu1.4 => 8.5.38-2ubuntu1~18.04] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: tomcat-native (bionic-proposed/universe) [1.2.16-1build1 => 1.2.21-1~18.04] (no packageset) (sync)
<doko> Laney, infinity, vorlon: is there a possibility to generate an update_excuses.txt for bionic, as if the global block request would not exist?
<vorlon> doko: the long term plan is to have sru-release drive britney hints instead of doing copies directly; so if you're asking because you're interested in uninstallability problems, that's a more comprehensive solution
-queuebot:#ubuntu-release- Unapproved: accepted ecj [sync] (bionic-proposed) [3.16.0-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted eclipse-emf [sync] (bionic-proposed) [2.16.0-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted jetty9 [sync] (bionic-proposed) [9.4.15-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted swt4-gtk [sync] (bionic-proposed) [4.10.0-3~18.04]
<doko> vorlon: I just want to know if all the openjdk stuff would migrate
-queuebot:#ubuntu-release- Unapproved: accepted tomcat-native [sync] (bionic-proposed) [1.2.21-1~18.04]
<vorlon> doko: well, I can set unblock hints for the regular britney; let me try that
<doko> vorlon: but don't let it migrate by accident ...
<vorlon> doko: the britney instance isn't currently set up to write to lp
-queuebot:#ubuntu-release- Unapproved: accepted tomcat8 [sync] (bionic-proposed) [8.5.38-2ubuntu1~18.04]
-queuebot:#ubuntu-release- New: accepted eclipse-debian-helper [sync] (bionic-proposed) [1.5~18.04]
-queuebot:#ubuntu-release- New: accepted eclipse-jdt-core [sync] (bionic-proposed) [4.10-1~18.04]
-queuebot:#ubuntu-release- New: accepted eclipse-jdt-debug [sync] (bionic-proposed) [4.10-2~18.04]
-queuebot:#ubuntu-release- New: accepted eclipse-jdt-ui [sync] (bionic-proposed) [4.10-1~18.04]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-debug [sync] (bionic-proposed) [4.10-1~18.04]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-resources [sync] (bionic-proposed) [4.10-1~18.04]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-runtime [sync] (bionic-proposed) [4.10-1~18.04]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-team [sync] (bionic-proposed) [4.10-1~18.04]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-text [sync] (bionic-proposed) [4.10-1~18.04]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-ua [sync] (bionic-proposed) [4.10-1~18.04]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-ui [sync] (bionic-proposed) [4.10-1~18.04]
-queuebot:#ubuntu-release- New: accepted el-api [sync] (bionic-proposed) [3.0.0-2~18.04]
-queuebot:#ubuntu-release- New: accepted equinox-bundles [sync] (bionic-proposed) [4.10-1~18.04]
-queuebot:#ubuntu-release- New: accepted equinox-framework [sync] (bionic-proposed) [4.10-1~18.04]
-queuebot:#ubuntu-release- New: accepted equinox-p2 [sync] (bionic-proposed) [4.10-1~18.04]
-queuebot:#ubuntu-release- New: accepted jsp-api [sync] (bionic-proposed) [2.3.4-2~18.04]
-queuebot:#ubuntu-release- New: accepted servlet-api [sync] (bionic-proposed) [4.0.1-2~18.04]
-queuebot:#ubuntu-release- New: accepted tomcat9 [sync] (bionic-proposed) [9.0.16-3~18.04]
-queuebot:#ubuntu-release- New: accepted websocket-api [sync] (bionic-proposed) [1.1-1~18.04]
<rharper> bdmurray: Hi, I've uploaded a curtin SRU that has a couple field critical bugs that need to get SRU'ed and I was wondering if you could take a look to get curtin into -proposed
<bdmurray> rharper: for which release of Ubuntu?
<rharper> Cosmic, Bionic and Xenial
<bdmurray> rharper: sure
<rharper> bdmurray: thanks!
<bdmurray> rharper: bug 1811117 is missing SRU information
<ubot5> bug 1811117 in curtin "Failed deployment: FileNotFoundError: [Errno 2] No such file or directory: '/sys/class/block/bcache0/bcache0p1/slaves'" [Critical,In progress] https://launchpad.net/bugs/1811117
<rharper> looking
<bdmurray> rharper: actually all the bugs are except for the "new upstream release" one
<rharper> https://bugs.launchpad.net/ubuntu/disco/+source/curtin/+bug/1817964
<ubot5> Ubuntu bug 1817964 in curtin (Ubuntu Cosmic) "sru curtin 2019-02-27 - 18.2-10-g7afd77fa-0ubuntu1" [Undecided,New]
<rharper> curtin uses a single SRU bug, sorry
<bdmurray> rharper: then the other bugs shouldn't be included in Launchpad-Bugs-Fixed.
<rharper> bdmurray: hrm, I think it's just cosmic that's got it wrong
<rharper> this was the first SRU into cosmic, so I've missed something in that source package build
<rharper> bdmurray: I suspect I'll need a new upload into cosmic to fix;  does the current unapproved package in cosmic queue need to be removed ?
<bdmurray> rharper: okay, no you could reupload the same version with -f
<rharper> oh, good
-queuebot:#ubuntu-release- Unapproved: rejected curtin [source] (cosmic-proposed) [18.2-10-g7afd77fa-0ubuntu1~18.10.1]
<ginggs> would someone please kick the can along? 'force-badtest mercurial/4.8.2-1ubuntu3/arm64'
<vorlon> ginggs: done
<ginggs> vorlon: ta!  there's a 'force-badtest mercurial/all/armhf' in p.itti's hints - maybe this can be removed now?
<vorlon> ginggs: looks like it - also done
<ginggs> thanks again!
-queuebot:#ubuntu-release- Unapproved: curtin (cosmic-proposed/main) [18.1-59-g0f993084-0ubuntu1 => 18.2-10-g7afd77fa-0ubuntu1~18.10.1] (ubuntu-desktop, ubuntu-server)
<rharper> bdmurray: ok, I fixed the changelog in the cosmic package and just uploaded again; thank you for the review and help
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (cosmic-proposed) [18.2-10-g7afd77fa-0ubuntu1~18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (bionic-proposed) [18.2-10-g7afd77fa-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (xenial-proposed) [18.2-10-g7afd77fa-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted numactl [source] (cosmic-proposed) [2.0.11-2.2ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted numactl [source] (bionic-proposed) [2.0.11-2.1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted qtwebengine-opensource-src [source] (cosmic-proposed) [5.11.1+dfsg-2ubuntu4.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-eventlet [source] (cosmic-proposed) [0.20.0-5ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-eventlet [source] (bionic-proposed) [0.20.0-4ubuntu0.18.04.1]
<Eickmeyer> Is there any chance I can bug anyone about bug 1818373? We need this in Ubuntu Studio so some packages can get updated that depend on it.
<ubot5> bug 1818373 in ubuntustudio-meta "[FFe] grub2-themes-ubuntustudio" [Critical,New] https://launchpad.net/bugs/1818373
<Eickmeyer> Also bug 1818366 needs an FFe.
<ubot5> bug 1818366 in Ubuntu Studio "[FFe] Carla: Please Upload to Universe" [Critical,New] https://launchpad.net/bugs/1818366
<vorlon> infinity: postgriopython-hll?
<infinity> vorlon: Err, can I really not copy/paste?
<vorlon> infinity: no, that was me asking a question
<infinity> Oh.
<vorlon> perhaps my question raced your answer
<infinity> python thingee was fixed yesterday, psql thingee, I've determined that if it is a precision issue, I can't figure out how, and punted to an upstream git ticket and hinted.
<infinity> glibc's just waiting on a snapd-glib test to do a thing now, it seems.
<vorlon> ok
<vorlon> how long's it been waiting for that?
<vorlon> that's a completely new test
<infinity> Dunno, I only just noticed it.
<vorlon> can we just skiptest and be done?
<infinity> Could do.
<infinity> Be my guest.
<infinity> I'll be chasing it with a new glibc in a day or two anyway (once I stop puzzling over this new container test infra thing), so that test will get its day in court.
<vorlon> infinity: hint added
<infinity> May god have mercy on our souls.
<vorlon> Eickmeyer: so, I'm taking a look at the FFe requests now, but I'm more bothered by the meta question of why there are still no ubuntustudio team members with upload rights
<Eickmeyer> vorlon: Because there are only 3 of us active. I'm new in the past year, OvenWerks has been told he doesn't have enough packaging experience, and Rosco2, while he does have Debian rights, also has been told he doesn't have enough packaging experience in Ubuntu. I'm going to try to apply after the 19.04 release.
<vorlon> Eickmeyer: "doesn't have enough packaging experience in Ubuntu" - can you please give me a pointer to this discussion?
<Eickmeyer> Anyone with upload rights didn't hand-off the project properly.
<Eickmeyer> vorlon: I cannot, it's anecdotal from OvenWerks.
<Eickmeyer> Also, I need to speak with Rosco2 more about this.
<vorlon> Eickmeyer: so, with my TB hat on I raised the point directly to the DMB over 2 years ago that it was a problem for there to not be any uploaders for ubuntustudio, in reference to Rosco2's application; I am dismayed to learn there has apparently been no progress
<Eickmeyer> vorlon: I agree. Since joining the team and being the figurehead, it has been frustrating every 6 months to run into this same brick wall.
<Eickmeyer> We /might/ get sakrecoer back in the summer.
<Eickmeyer> But that's no guarantee.
<tsimonq2> This isn't a point for or against anyone in particular but it's noteworthy that when Ubuntu Studio was revived after the hiatus, they didn't have to go through a flavor reapplication process with the TB. The TB would have caught this.
<vorlon> tsimonq2: when was the hiatus?
<Eickmeyer> tsimonq2: Was Ubuntu Studio ever officially dropped?
<vorlon> I really think it's improper to have a flavor that has no uploaders.  I think this needs to be fixed before 19.04 releases (which effectively means, before beta)
<Eickmeyer> Then how do we fix it?
<vorlon> Eickmeyer: who of the current ubuntustudio members has recently (re)applied for uploader rights?
<tsimonq2> I have an action item with the DMB to standardize the Lubuntu Developer qualification requirements, so that can lead you in the right direction: https://phab.lubuntu.me/w/lubuntu-dev/
<tsimonq2> I have offered to mentor Eickmeyer if needed.
<tsimonq2> vorlon: I don't recall specifics but ~ 16.04 iirc
<Eickmeyer> vorlon: I don't know. Nobody in the past year that I know of.
<tsimonq2> Er, 18.04
<tsimonq2> Recently there was a hiatus before Eickmeyer showed up.
<Eickmeyer> tsimonq2: I joined just before 18.04 released and acted as release manager.
<Eickmeyer> I've been with the project for a year now.
<tsimonq2> Eickmeyer: Wasn't 18.04 non-LTS from your side?
<Eickmeyer> tsimonq2: Yes, and that was our decision.
<tsimonq2> vorlon: ^ pre-Eickmeyer was the hiatus time.
<Eickmeyer> sakrecoer dropped after 16.10, and Rosco2 acted as release manager for 17.04 and 17.10.
<Eickmeyer> 17.04, 17.10, and 18.04 were all really just maintenance releases.
<vorlon> Eickmeyer: right, so it needs to be a priority on the part of the ubuntustudio devs to be applying for upload rights; it needs to be a priority of the DMB to work out what upload rights can reasonably be granted to an ubuntustudio packageset to allow the maintenance to continue; and it needs to be a priority for the TB to be prepared to revoke the flavor status if there's no movement on this
<tsimonq2> Rosco2 is a DD, what does his Ubuntu uploading story look like?
<tsimonq2> vorlon: +1, would you like me to bring it up to the DMB?
<vorlon> tsimonq2: I will be doing so :)
<tsimonq2> Sounds good.
<vorlon> tsimonq2: you joined the DMB too late to have my previous mails on the subject in your mailbox ;P
<tsimonq2> vorlon: I can dig through the archives though. :P
<vorlon> tsimonq2: October 2016
<tsimonq2> ack, thanks.
<Eickmeyer> Excellent. Is there any way I can attend this meeting?
<vorlon> somewhere there is a calendar that says when the DMB irc meetings are :)
<vorlon> I was just going to send mail (and cc y'all)
<Eickmeyer> Excellent. eeickmeyer@ubuntu in my case.
<cyphermox> fwiw there already is an ubuntustudio packageset.
<tsimonq2> vorlon: So my understanding from reading the thread is that the DMB has yet to evaluate this. Am I correct?
<tsimonq2> Er, wait.
<vorlon> tsimonq2: I don't know anything beyond that thread since I'm not privy to dmb private discussions
<tsimonq2> Yeah, one member's email about needing sponsors and such is accurate.
<tsimonq2> vorlon: No further discussion took place privately on that thread.
<vorlon> I had hoped that the DMB would revisit the question of Rosco2's upload status in light of the impact on flavor status but I don't know whether or not that was actually doen
<tsimonq2> From what I can tell, it wasn't.
<vorlon> Eickmeyer: regarding LP: #1818373 and LP: #1818366, were you actually told by a would-be sponsor that you needed to file an FFe? I wouldn't have considered an FFe necessary for either of these
<ubot5> Launchpad bug 1818373 in grub2-themes-ubuntustudio "[FFe] grub2-themes-ubuntustudio" [Critical,Triaged] https://launchpad.net/bugs/1818373
<ubot5> Launchpad bug 1818366 in ubuntustudio-meta (Ubuntu) "[FFe] Carla: Please Upload to Universe" [Wishlist,Triaged] https://launchpad.net/bugs/1818366
<vorlon> (of course, ppu rights also don't really help with new packages...)
<Eickmeyer> vorlon: Only really Carla, since slangasek just trivially approved and said it falled under UIFe. Also, the wiki entry on the FFe subject implied that any new packages required an FFe after FF.
<tsimonq2> slangasek = vorlon ;)
<Eickmeyer> OOOOhhhhh!
<vorlon> haha
<Eickmeyer> New nick or just an additional one?
<vorlon> old nick reborn
<Eickmeyer> Nice.
<vorlon> also it now matches the launchpad id
<bdmurray> juliank: Is bug 1814727 fixed in Disco? the tasks don't reflect that
<ubot5> bug 1814727 in apt (Ubuntu Disco) "Backport never pinning and Packages-Require-Authorization" [Undecided,In progress] https://launchpad.net/bugs/1814727
<Eickmeyer> Makes sense. I'd have to add an E to make it match. Name is hard enough as it is, so meh.
<vorlon> eh, https://wiki.ubuntu.com/FreezeExceptionProcess doesn't so much imply as outright state that you have to get release signoff on new packages
<vorlon> but that hasn't been true for a very, very long time
<Eickmeyer> Good to know.
<Eickmeyer> Since Rosco2 wasn't in this chat, I went ahead and forwarded him a copy-paste via email, so he knows what's going on.
<Eickmeyer> Also, OvenWerks has been having family issues lately (death in the family), so he's been somewhat (understandably) absent as of late.
-queuebot:#ubuntu-release- Unapproved: accepted packagekit [source] (cosmic-proposed) [1.1.10-1ubuntu7.1]
-queuebot:#ubuntu-release- Unapproved: accepted packagekit [source] (bionic-proposed) [1.1.9-1ubuntu2.18.04.5]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-7.8] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-7.8] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-7.8] (core, kernel)
<juliank> bdmurray: yes, not sure what I did with the tasks
-queuebot:#ubuntu-release- Unapproved: accepted opencryptoki [source] (cosmic-proposed) [3.10.0+dfsg-0ubuntu1.1]
<bdmurray> juliank: okay, I'll have a look at it again in a bit
-queuebot:#ubuntu-release- Unapproved: rejected chromium-browser [source] (cosmic-proposed) [72.0.3626.119-0ubuntu0.18.10.1]
<juliank> bdmurray: if you're like a bit bored, it would be great if you could accept the apt SRUs :-)
<juliank> ugh, me is confused
<juliank> that's what we've been talking about
<juliank> that's what I get for writing at 22:20 ...
<vorlon> doko: glibc looks fine, but the britney autohinter is getting things wrong so I'm manually hinting
<vorlon> doko: well, in fact infinity also added a hint, so one or the other of our hints should DTRT ;)
<infinity> vorlon: Oh look, my easy hint worked.  glibc migrated.
<infinity> vorlon: You were too late. :P
 * infinity drops both hints.
<vorlon> :)
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (cosmic-proposed) [1.7.3]
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (bionic-proposed) [1.6.9]
-queuebot:#ubuntu-release- Unapproved: snapd-glib (cosmic-proposed/main) [1.44-1 => 1.46-0ubuntu0.18.10.0] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (xenial-proposed) [1.2.30]
-queuebot:#ubuntu-release- Unapproved: lmdb (cosmic-proposed/universe) [0.9.22-1 => 0.9.22-1ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (trusty-proposed) [1.0.1ubuntu2.21]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-7.8]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-7.8]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-7.8]
-queuebot:#ubuntu-release- Unapproved: rejected lmdb [source] (cosmic-proposed) [0.9.22-1ubuntu1~cosmic18.10]
-queuebot:#ubuntu-release- Unapproved: rejected lmdb [source] (bionic-proposed) [0.9.21-1ubuntu2~bionic18.04]
-queuebot:#ubuntu-release- Unapproved: lmdb (bionic-proposed/universe) [0.9.21-1 => 0.9.21-1ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted ec2-hibinit-agent [source] (cosmic-proposed) [1.0.0-0ubuntu4~18.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted ec2-hibinit-agent [source] (bionic-proposed) [1.0.0-0ubuntu4~18.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted ec2-hibinit-agent [source] (xenial-proposed) [1.0.0-0ubuntu4~16.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted ec2-hibinit-agent [source] (trusty-proposed) [1.0.0-0ubuntu4~14.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted lmdb [source] (cosmic-proposed) [0.9.22-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted lmdb [source] (bionic-proposed) [0.9.21-1ubuntu0.1]
#ubuntu-release 2019-03-06
-queuebot:#ubuntu-release- Unapproved: grub2 (disco-proposed/main) [2.02+dfsg1-12ubuntu1 => 2.02+dfsg1-12ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (disco-proposed/main) [2.02+dfsg1-12ubuntu1 => 2.02+dfsg1-12ubuntu1] (core)
<vorlon> doko: and http://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_output.txt if you want to look at it
-queuebot:#ubuntu-release- Unapproved: snapd-glib (cosmic-proposed/main) [1.44-1 => 1.47-0ubuntu0.18.10.0] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: snapd-glib (bionic-proposed/main) [1.43-0ubuntu0.18.04.1 => 1.47-0ubuntu0.18.04.0] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd-glib (xenial-proposed/main) [1.33-0ubuntu0.16.04.1 => 1.47-0ubuntu0.16.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (disco-proposed) [2.02+dfsg1-12ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (disco-proposed) [2.02+dfsg1-12ubuntu1]
<jibel> sil2100, images are good on mac.
<jibel> sil2100, however on some machines with intel+nvidia and another with no discrete card the system doesn't boot after installation in legacy mode while it works with uefi
<jibel> I'm trying to reproduce it here
<sil2100> Not good
<jibel> this is the autoresize test case
<sil2100> Can you check .5 for that as well?
<jibel> I'm checking .6 first
<jibel> if it's an issue with the machine or the image
<jibel> sil2100, I cannot reproduce on the machine I've here. I'm waiting for the logs. Other than that everything LGTM
<sil2100> jibel: ok
<ogra> sil2100, i'm getting friendly mails from "proposed-migration" pointing me to http://people.canonical.com/~ubuntu-archive/proposed-migration/disco/update_excuses.html#initramfs-tools-ubuntu-core
<ogra> it says valid candidate there, any idea why it wouldnt auto-migrate ?
<cjwatson> Did you check update_output?
<cjwatson> update_excuses is just the first stage
<cjwatson> Also it seems to have migrated in the most recent run
<ogra> ah
<ogra> yeah, i was about to say update_output looks fine to me too
<doko> vorlon: yep, exactly that, now looking at the eclipse uninstallability ...
<paride> Hi. The ISO tracker download links for ubuntu-server 14.04.6 are broken: http://iso.qa.ubuntu.com/qatracker/milestones/401/builds/189291/downloads
<paride> and indeed http://cdimage.ubuntu.com/ubuntu-server/daily/ has no image from 20190304
<sil2100> paride: oh, let me take a look
<paride> sil2100, thanks :)
<sil2100> Yeah, those are obviously pointing to the disco ones, geh
<sil2100> paride: in the meantime, the correct link is http://cdimage.ubuntu.com/ubuntu-server/trusty/daily/20190304.2/
<paride> sil2100, great, thanks
-queuebot:#ubuntu-release- Unapproved: qemu (cosmic-proposed/main) [1:2.12+dfsg-3ubuntu8.3 => 1:2.12+dfsg-3ubuntu8.4] (ubuntu-server, virt)
<doko> vorlon: please also add scilab fonts-liberation2 libreoffice libreoffice-l10n, and fix the version for jaxws
<doko> sil2100: ^^^ or could you do that (bionic)?
-queuebot:#ubuntu-release- Unapproved: rejected python-urllib3 [source] (xenial-proposed) [1.13.1-2ubuntu0.16.04.3]
<doko> apw: when is linux 5 supposed to migrate?
<apw> doko, as soon as it can, it would not be in -proposed (i believe) if it wasn't really really close
<doko> ok
<doko> ... updating the c-t-b packages
<doko> apw: autopkgtest for linux/5.0.0-7.8: i386: Regression
<apw> doko, yeah ... this is the stupiditiy that new test which are by definition not a regression, are deemed a regression
<apw> doko, will get it hinted once i have that confirmed as cause
<doko> are autopkg testers running different kernel versions than builders?
<doko> 4.18+
-queuebot:#ubuntu-release- Unapproved: postgresql-9.5 (xenial-proposed/main) [9.5.14-0ubuntu0.16.04 => 9.5.16-0ubuntu0.16.04.1] (core)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Trusty 14.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Trusty 14.04.6] has been marked as ready
-queuebot:#ubuntu-release- New sync: libeclipse-emf (bionic-proposed/primary) [2.16.0-1~18.04.1]
-queuebot:#ubuntu-release- New: accepted libeclipse-emf [sync] (bionic-proposed) [2.16.0-1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: activemq (bionic-proposed/universe) [5.15.3-2 => 5.15.8-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: annotation-indexer (bionic-proposed/universe) [1.9-1 => 1.12-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: aspectj-maven-plugin (bionic-proposed/universe) [1.10-1 => 1.11-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: afterburner.fx (bionic-proposed/universe) [1.7.0-1 => 1.7.0-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: aspectj (bionic-proposed/universe) [1.8.9-2 => 1.9.2-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: apache-directory-server (bionic-proposed/universe) [2.0.0~M15-4 => 2.0.0~M24-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: batik (bionic-proposed/universe) [1.9-3 => 1.10-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: bridge-method-injector (bionic-proposed/universe) [1.18-1 => 1.18-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: commons-httpclient (bionic-proposed/universe) [3.1-14 => 3.1-15~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: bindex (bionic-proposed/universe) [2.2+svn101-3 => 2.2+svn101-4~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: carrotsearch-hppc (bionic-proposed/universe) [0.6.1-5 => 0.7.2-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: clojure (bionic-proposed/universe) [1.9.0-2 => 1.9.0-6~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: elki (bionic-proposed/universe) [0.7.1-6 => 0.7.1-10~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: fontawesomefx (bionic-proposed/universe) [8.9-1 => 9.1.2-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: hsqldb (bionic-proposed/universe) [2.4.0-2 => 2.4.1-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: eclipselink (bionic-proposed/universe) [2.6.5-3 => 2.6.6-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: hikaricp (bionic-proposed/universe) [2.7.1-1 => 2.7.1-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: figtree (bionic-proposed/universe) [1.4.3+dfsg-5ubuntu0.1 => 1.4.4-3~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: mariadb-connector-java (bionic-proposed/primary) [2.3.0-1~18.04]
-queuebot:#ubuntu-release- Unapproved: hsqldb1.8.0 (bionic-proposed/universe) [1.8.0.10+dfsg-8 => 1.8.0.10+dfsg-10~18.04] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: jackson-core (bionic-proposed/universe) [2.9.4-1 => 2.9.8-3~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jackson-dataformat-xml (bionic-proposed/universe) [2.9.4-1 => 2.9.8-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jabref (bionic-proposed/universe) [3.8.2+ds-3 => 3.8.2+ds-12~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jackson-module-jaxb-annotations (bionic-proposed/universe) [2.8.10-2 => 2.8.10-4~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jackson-databind (bionic-proposed/universe) [2.9.5-1 => 2.9.8-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: javafxsvg (bionic-proposed/universe) [1.2.1-1 => 1.2.1-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jboss-classfilewriter (bionic-proposed/universe) [1.2.2-2 => 1.2.4-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: javamail (bionic-proposed/universe) [1.6.1-2 => 1.6.2-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jboss-jdeparser2 (bionic-proposed/universe) [2.0.2-1 => 2.0.2-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jboss-modules (bionic-proposed/universe) [1.8.1-1 => 1.9.0-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jersey1 (bionic-proposed/universe) [1.19.3-4 => 1.19.3-6~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jhove (bionic-proposed/multiverse) [1.6+dfsg-1 => 1.20.1-5~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jts (bionic-proposed/universe) [1.14+ds-2 => 1.15.1+ds-2~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jcommander (bionic-proposed/universe) [1.71-1 => 1.71-3~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jmdns (bionic-proposed/universe) [3.5.3-1 => 3.5.5-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jftp (bionic-proposed/universe) [1.60+dfsg-2 => 1.60+dfsg-3~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: junit4 (bionic-proposed/universe) [4.12-6 => 4.12-8~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jxgrabkey (bionic-proposed/universe) [0.3.2-9 => 0.3.2-10~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libbtm-java (bionic-proposed/universe) [2.1.4-3 => 2.1.4-4~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libcommons-collections4-java (bionic-proposed/universe) [4.1-1 => 4.2-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libapache-poi-java (bionic-proposed/universe) [3.10.1-3 => 4.0.1-1~18.03] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libcommons-compress-java (bionic-proposed/universe) [1.13-2 => 1.18-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libcommons-collections3-java (bionic-proposed/universe) [3.2.2-1 => 3.2.2-2~18.04] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: fwupd-signed (cosmic-proposed/main) [1.2ubuntu0.1 => 1.2.0ubuntu0.1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: ibm-java80 (xenial-proposed/partner) [8.0.5.25-0ubuntu1 => 8.0.5.30-0ubuntu1] (no packageset)
<vorlon> doko: bionic unblock list updated
-queuebot:#ubuntu-release- Unapproved: accepted activemq [sync] (bionic-proposed) [5.15.8-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted afterburner.fx [sync] (bionic-proposed) [1.7.0-2~18.04]
-queuebot:#ubuntu-release- Unapproved: nautilus (cosmic-proposed/main) [1:3.26.4-0ubuntu7.1 => 1:3.26.4-0ubuntu7.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected nautilus [source] (cosmic-proposed) [1:3.26.4-0ubuntu7.2]
-queuebot:#ubuntu-release- Unapproved: accepted annotation-indexer [sync] (bionic-proposed) [1.12-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd-signed [source] (cosmic-proposed) [1.2.0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: nautilus (cosmic-proposed/main) [1:3.26.4-0ubuntu7.1 => 1:3.26.4-0ubuntu7.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: nautilus (bionic-proposed/main) [1:3.26.4-0~ubuntu18.04.3 => 1:3.26.4-0~ubuntu18.04.4] (ubuntu-desktop)
<vorlon> doko: and you've seen that swt4-gtk in bionic-proposed drops gtk2 support, breaking some revdeps?
-queuebot:#ubuntu-release- Unapproved: accepted apache-directory-server [sync] (bionic-proposed) [2.0.0~M24-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted aspectj [sync] (bionic-proposed) [1.9.2-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted aspectj-maven-plugin [sync] (bionic-proposed) [1.11-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted batik [sync] (bionic-proposed) [1.10-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted bindex [sync] (bionic-proposed) [2.2+svn101-4~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted bridge-method-injector [sync] (bionic-proposed) [1.18-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted carrotsearch-hppc [sync] (bionic-proposed) [0.7.2-2~18.04]
<doko> vorlon: yes, looking. for now, please remove eclipse-emf/2.16.0-1~18.04 from the hint
-queuebot:#ubuntu-release- Unapproved: accepted commons-httpclient [sync] (bionic-proposed) [3.1-15~18.04]
<vorlon> doko: ok (why?)
<doko> removed, replaced by libeclipse-emf
<vorlon> ok
<doko> all binaries are distinct
<doko> so don't touch the old source
<doko> I already removed eclipse-emf from bionic-proposed
<doko> vorlon: so the other ones will clear once stegosuite gets reviewed and copied, so maybe alread add stegosuite/0.8.0-2~18.04 to the hint
-queuebot:#ubuntu-release- Unapproved: accepted eclipselink [sync] (bionic-proposed) [2.6.6-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted elki [sync] (bionic-proposed) [0.7.1-10~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted clojure [sync] (bionic-proposed) [1.9.0-6~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted figtree [sync] (bionic-proposed) [1.4.4-3~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted fontawesomefx [sync] (bionic-proposed) [9.1.2-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted hikaricp [sync] (bionic-proposed) [2.7.1-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted hsqldb [sync] (bionic-proposed) [2.4.1-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted hsqldb1.8.0 [sync] (bionic-proposed) [1.8.0.10+dfsg-10~18.04]
<vorlon> doko: so you're going to leave an uninstallable libswt-gtk2-4-jni binary in the release pocket and switch stegosuite to gtk3 in SRU?  this doesn't smell good
-queuebot:#ubuntu-release- Unapproved: accepted jabref [sync] (bionic-proposed) [3.8.2+ds-12~18.04]
<vorlon> doko: can we not re-add the gtk2 bindings?
<vorlon> is the new upstream source incompatible, or was it just dropped in the packaging as part of gtk2 deprecation?
<doko> vorlon: where do you see that?
<vorlon> doko: that's my analysis of swt4-gtk
-queuebot:#ubuntu-release- Unapproved: accepted jackson-core [sync] (bionic-proposed) [2.9.8-3~18.04]
<vorlon> doko: libswt-gtk2-4-jni doesn't show up as an uninstallable in britney output because britney assumes it can remove the old binary at the same time - but it can't
-queuebot:#ubuntu-release- Unapproved: accepted jackson-databind [sync] (bionic-proposed) [2.9.8-1~18.04]
<doko> ahh, I see. ok, l'll see how to restore that one
-queuebot:#ubuntu-release- Unapproved: accepted jackson-dataformat-xml [sync] (bionic-proposed) [2.9.8-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted jackson-module-jaxb-annotations [sync] (bionic-proposed) [2.8.10-4~18.04]
<doko> ugh ...
<doko>   * New upstream release
<doko>     - Refreshed the patches
<doko>     - GTK 2 support has been removed
<vorlon> doko: oh - actually it looks like libswt-gtk2-4-jni doesn't become uninstallable, but because britney assumes it will be removed, it shows stegosuite as uninstallable
<vorlon> doko: so we don't actually need to update stegosuite, however it would be depending on a binary that's NBS and not security updatable
-queuebot:#ubuntu-release- Unapproved: accepted javafxsvg [sync] (bionic-proposed) [1.2.1-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted javamail [sync] (bionic-proposed) [1.6.2-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted jboss-classfilewriter [sync] (bionic-proposed) [1.2.4-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted jboss-jdeparser2 [sync] (bionic-proposed) [2.0.2-2~18.04]
<doko> vorlon: ok, then I'll remove stegosuite from the ppa's, if we can handle it like this
-queuebot:#ubuntu-release- Unapproved: accepted jboss-modules [sync] (bionic-proposed) [1.9.0-1~18.04]
<vorlon> doko: I think that changelog is ambiguous wrt whether the support for gtk2 was dropped upstream or just as part of packaging the new upstream version; I'll do a quick build test here
<doko> ok, ta
<doko> vorlon: if it builds, an update should go to the tomcat2 ppa
<vorlon> doko: full url for that ppa?
<doko> https://launchpad.net/~openjdk-11-transition/+archive/ubuntu/tomcat2/+packages
<vorlon> ok
<vorlon> might be a bit before I upload it, but I'll follow through
-queuebot:#ubuntu-release- Unapproved: accepted jcommander [sync] (bionic-proposed) [1.71-3~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted jersey1 [sync] (bionic-proposed) [1.19.3-6~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted jftp [sync] (bionic-proposed) [1.60+dfsg-3~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted jhove [sync] (bionic-proposed) [1.20.1-5~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted jmdns [sync] (bionic-proposed) [3.5.5-1~18.04]
<vorlon> if someone were to be able to reproduce the autopkgtest failure of gdpc 2.2.5-9, I would be interested to know how, I can't reproduce it locally
-queuebot:#ubuntu-release- Unapproved: accepted jts [sync] (bionic-proposed) [1.15.1+ds-2~18.04.1]
<vorlon> doko: ok yeah, swt4-gtk now requires the gtk3-only gtk/gtkx.h so it's non-trivial
-queuebot:#ubuntu-release- Unapproved: accepted junit4 [sync] (bionic-proposed) [4.12-8~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted jxgrabkey [sync] (bionic-proposed) [0.3.2-10~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted libapache-poi-java [sync] (bionic-proposed) [4.0.1-1~18.03]
<doko> vorlon: ok, the keep the stegosuite as it is in bionic
<vorlon> doko: I still prefer to keep the gtk2 bindings available rather than drop in SRU so I will dig a little further
-queuebot:#ubuntu-release- Unapproved: accepted libbtm-java [sync] (bionic-proposed) [2.1.4-4~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted libcommons-collections3-java [sync] (bionic-proposed) [3.2.2-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted libcommons-collections4-java [sync] (bionic-proposed) [4.2-1~18.04]
<doko> vorlon: src:swt-gtk still has them
-queuebot:#ubuntu-release- Unapproved: accepted libcommons-compress-java [sync] (bionic-proposed) [1.18-1~18.04]
-queuebot:#ubuntu-release- New: accepted mariadb-connector-java [sync] (bionic-proposed) [2.3.0-1~18.04]
<vorlon> doko: in disco?
<vorlon> libswt-gtk-3-jni from swt-gtk in bionic doesn't look like it'd be the same thing
<doko> no, not in disco
<doko> swt-gtk should have been removed in disco
<vorlon> doko: the gtk2 bindings were still there in cosmic, should we backport from there instead of disco?
<doko> vorlon: no, if you want to do that, backport them from 4.9
<doko> but in any case, then we have to use a fake version 4.10+4.9?
<doko> rather 4.10~4.9 ...
<doko> vorlon: please add hints for the above unapproved packages, up to libcommons-compress-java
<doko> afk now for a while
<vorlon> doko: version numbers in -proposed don't have to be monotonically increasing, we can drop the current package and replace it with a lower version #
-queuebot:#ubuntu-release- Unapproved: figtree (bionic-proposed/universe) [1.4.4-3~18.04 => 1.4.4-3~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- New source: grub2-themes-ubuntustudio (disco-proposed/primary) [0.1]
<Eickmeyer> \o/
<Eickmeyer> tsimonq2: ^
<tsimonq2> Cool (wasn't me)
<Eickmeyer> Dmitrii-Sh: THANK YOU!!!
<mitya57> It was me, not that Dmitry who you highlighted :)
 * mitya57 looks at the other packages
<Eickmeyer> Oh, sorry!
<tsimonq2> Thanks mitya57 :)
<Eickmeyer> mitya57: If you manage to do all of this, I'll owe you a steak dinner if you ever come to the Seattle area.
<vorlon> network connection errors from armhf autopkgtest runners are high again (i.e. non-zero)
<mitya57> Eickmeyer: should ubuntustudio-icon-theme have âubuntu1â in version, or can be just 0.19 like all past uploads?
<Eickmeyer> mitya57: Yeah, I don't know why ubuntu1 is in there, that would imply it's superceding a Debian package, correct?
<mitya57> Yes, ubuntuX is needed when there is a package in Debian (and Ubuntu has a delta against it).
<Eickmeyer> Yeah, we can remove that.
<Eickmeyer> Do you want me to do that or is it trivial for you?
<vorlon> 'dch -i' does that automatically on Ubuntu even when it sometimes shouldn't.  But yes a native Ubuntu package for a flavor doesn't need the ubuntu in the versions
<mitya57> Eickmeyer: It's trivial.
<Eickmeyer> vorlon: That's probably what happened then. I'll watch for that in the future.
<mitya57> Eickmeyer: etc/xdg/menus/applications-merged/studio.menu has a very ugly mix of tabs and spaces in indentation. I can upload it as is now, but please fix stick to some one way of indentation for the next version.
<Eickmeyer> mitya57: Eek, okay. Probably leftover from years of work. I'll put that on my list of things to clean.
<mitya57> E.g. it is visible on https://git.launchpad.net/ubuntustudio-menu/commit/?id=2ee52da5045f993ef033c44793ef8c2728889731 that neighbor items are indented differently.
<Eickmeyer> mitya57: I just alerted the ubuntustudio-devel channel about it, so perhaps between myself and OvenWerks we can get that sorted.
<mitya57> Thanks!
<mitya57> Eickmeyer: will you mind if I add LP: #XXX to the first line of changelog, to make the bugs auto-closed?
<Eickmeyer> mitya57: I don't mind that at all.
<mitya57> Ok.
<rharper> rbasak: if you're around, I wanted to see if you could look at the cloud-init SRU, we've completed verification, https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1813346
<ubot5> Ubuntu bug 1813346 in cloud-init (Ubuntu) "sru cloud-init (18.4.0 update to 18.5-21-g8ee294d5) Xenial, Bionic, Cosmic" [Undecided,Confirmed]
<mitya57> Eickmeyer: debian/copyright in ubuntustudio-icon-theme is broken (see lintian warnings). I can fix it but please say who is the copyright owner of ubuntustudio-logo.svg.
<Eickmeyer> mitya57: I think that was Scott Lavender?
<rbasak> rharper: I am around but I don't feel up to reviewing something right now, sorry.
<rharper> rbasak: ok
<mitya57> Eickmeyer: Yes, it is currently marked as âCopyright 2012 Scott Lavenderâ, but you changed that icon in June 2018, that's why I am asking.
<mitya57> If it's still his icon then I will just bump the year.
<Eickmeyer> mitya57: Pretty sure he still owns the copyright, so yes. It's just a variation on the original.
<Eickmeyer> All I did was update to the modern version.
<Eickmeyer> Feel free to bump the year.
<doko> vorlon: swt4-gtk is now ready for review. then I assume we should update stegosuite as well. Please update the hints for all the new packages before your EOD. afk now
-queuebot:#ubuntu-release- New binary: ubuntustudio-default-settings [amd64] (disco-proposed/universe) [0.65] (no packageset)
<Eickmeyer> \o/
<mitya57> Eickmeyer: In ubuntustudio-installer, usr/bin/ubuntustudio-installer-ppa uses add-apt-repository. Maybe it should depend on software-properties-common?
<Eickmeyer> mitya57: Not a bad idea at all.
-queuebot:#ubuntu-release- New: accepted ubuntustudio-default-settings [amd64] (disco-proposed) [0.65]
<mitya57> Ok, I will add it to Depends.
-queuebot:#ubuntu-release- Unapproved: swt4-gtk (bionic-proposed/universe) [4.6.3-2 => 4.9.0-1~18.04] (no packageset) (sync)
<mitya57> Eickmeyer: Oh, after uploading ubuntustudio-menu I noticed that it needs Breaks/Replaces against old ubuntustudio-default-settings because two files moved from there.
<mitya57> I will do a follow-up 0.28.1 upload now.
<Eickmeyer> mitya57: OOkay.
<mitya57> Eickmeyer: also should ubuntustudio-default-settings depend on materia-gtk-theme, now that it sets that theme as default?
<Eickmeyer> mitya57: Yes, that's correct, but the dependency on -look takes care of that?
<vorlon> doko: am I meant to do binary or sourceful copies from https://launchpad.net/~openjdk-11-transition/+archive/ubuntu/tomcat2/+packages ?
<vorlon> ah, confirmed, previous one was binary
<tdaitx> vorlon: to bionic-proposed? we have been doing binary copies
 * vorlon nods
<vorlon> tdaitx: why are there no ddebs in this copy? is the ppa not configured to build / publish them?
<mitya57> Eickmeyer: ah, ok. Maybe bump that dependency from >= 0.48~ to >= 0.56~ for the next upload?
<Eickmeyer> mitya57: Sounds good.
<vorlon> tdaitx: so... we've been doing binary copies, but the source ppa is not configured correctly.
<doko> vorlon: binary, because you would pick up -proposed packages otherwise
<mitya57> Eickmeyer: That's a minor thing, so I will leave it for you to fix later.
<doko> and -updates
<Eickmeyer> Okay.
<tdaitx> vorlon: by default that is not enabled in a new ppa and it was not something we discussed about, so it was left disabled
<vorlon> tdaitx: ok, you MUST make the ppa settings match what the main archive does if you are going to do binary copies from the ppa to the main archive
<vorlon> doko: ^^
<vorlon> so all of these SRUs are missing dbgsyms now
<tdaitx> T_T
<vorlon> I've updated the flags so that any future package builds done in this ppa are done correctly
<doko> vorlon: ouch, ok. but there are only a few ones building arch:any
<doko> vorlon: which ppa's?
<vorlon> doko: https://launchpad.net/~openjdk-11-transition/+archive/ubuntu/tomcat2 I just fixed
<doko> openjdk-11 itself doesn't have dbgsyms
<vorlon> and we don't want it to rebuild in -proposed because it has to be copied to security
<vorlon> doko: two choices, we can bump the version number again and rebuild in the same ppa or we can reuse the same version number but create a new ppa
<doko> I'd prefer the former
<vorlon> ok
<doko> and I'll look for other :any builds in other ppa's
<vorlon> thanks
-queuebot:#ubuntu-release- Unapproved: rejected swt4-gtk [sync] (bionic-proposed) [4.9.0-1~18.04]
<doko> building ...
<doko> I assume we don't need a re-review by sbeattie for those
<mitya57> Eickmeyer: now I uploaded everything except ubuntustudio-look (depends on grub2-themes-ubuntustudio which is in New queue) and carla
<mitya57> carla is a large package and I will review it tomorrow â it's 1:26 am here and I will definitely miss something important if I review it now.
<Eickmeyer> mitya57: I appreciate everything you have done. I cannot tell you how much of a relief all of this has been to me, and to others.
<mitya57> Eickmeyer: you are welcome! Will you create git tags yourself, or do you want me to create them?
<Eickmeyer> mitya57: I probably could, but if it's trivial for you, feel free.
<tdaitx> doko: vorlon: arch any packages in the ppas: gettext gluegen2 java3d java-common jxgrabkey libjogl2-java openjfx swt4-gtk tomcat-native visualvm zeroc-ice
<mitya57> Eickmeyer: Ok, will do now
<doko> tdaitx: I'm EOD. can you adjust the ppa settings and upload to the ppa's?
<doko> java-common is a false positive
-queuebot:#ubuntu-release- Unapproved: swt4-gtk (bionic-proposed/universe) [4.6.3-2 => 4.9.0-1~18.04.1] (no packageset) (sync)
<tdaitx> indeed
<doko> vorlon: copying before publication?
<sbeattie> doko: no, if it's jut a no change rebuild to pick up ddebs, I don't need to review that.
<vorlon> doko: copying when a dry run shows me the binaries are visible from the api :-)
-queuebot:#ubuntu-release- Unapproved: accepted swt4-gtk [sync] (bionic-proposed) [4.9.0-1~18.04.1]
<tdaitx> vorlon: doko: rebuilding in https://launchpad.net/~openjdk-11-transition/+archive/ubuntu/ddebs/+packages
<vorlon> tdaitx: cheers
<vorlon> tdaitx: however, these packages had already been accepted in -proposed and need to have their version numbers incremented
<tdaitx> vorlon: I assumed it would be ok to remove them from -proposed and then copy again
<vorlon> tdaitx: (same changelog entry preferred, just bump the version number)
<vorlon> tdaitx: nope, once the version number has been used in the archive, it's burned
<doko> hmm, so what was this about using the same ppa's and incrementing version numbers?
<doko> I#d like to have a safe fall-back
<vorlon> doko: I don't care where they're built as long as they're built with the right ppa config... having them all built in one new ppa at least makes it easy for me to see what to copy
<vorlon> version numbers still need changed, regardless
<doko> I'm not here to reduce your work load on my expense
<vorlon> and I'm not asking you to do more work, I'm saying I don't have a problem with what tdaitx did.  If you do, that's between the two of you
<doko> tdaitx: so please upload to the ppa's. vorlon should be intellectually capable to cope with this
<tdaitx> vorlon: doko: uploaded the bumped versions into the ddebs ppa, I would rather not overwrite what has been reviewed - I can copy them later to the other ppas if anyone feels this ppa is useless ;-)
<tdaitx> sbeattie: just in case I am rebuild the arch any packages in a separate ppa, if you are still going through any packages in apps, stage3, stage5, or tomcat2 you might want to look into the ddebs ppa (https://launchpad.net/~openjdk-11-transition/+archive/ubuntu/ddebs/+packages)
<sbeattie> tdaitx: thanks
#ubuntu-release 2019-03-07
-queuebot:#ubuntu-release- New source: carla (disco-proposed/primary) [1.9.13-0ubuntu1]
<Eickmeyer> If anybody can speed grub2-themes-ubuntustudio through, that would be great. We have another package waiting for that one before any action can be taken on the upload. cyphermox and mitya57 have been helping. :)
-queuebot:#ubuntu-release- Unapproved: vaultlocker (cosmic-proposed/universe) [1.0.3-0ubuntu1 => 1.0.3-0ubuntu1.18.10.1] (no packageset)
<sil2100> Nice, someone linked bug #1 to the 14.04.6 testing
<ubot5> bug 1 in Ubuntu Malaysia LoCo Team "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1
<jibel> it's because this user added a comment to the test but didn't file a bug and you cannot fail a test without a bug #
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Trusty 14.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot i386 [Trusty 14.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64+mac [Trusty 14.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Trusty 14.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Trusty 14.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot armhf [Trusty 14.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Trusty 14.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Trusty 14.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Trusty 14.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Trusty 14.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Trusty 14.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base powerpc [Trusty 14.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Trusty 14.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64+mac [Trusty 14.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Trusty 14.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Trusty 14.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Trusty 14.04.6] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Trusty 14.04.6] has been marked as ready
<sil2100> Prepublishing 14.04.6 images ^
<doko> vorlon: the swt4-gtk downgrade invalidates the eclipse/equinox stack. now downgrading ...
<tjaalton> doko: I'm planning to move mesa to llvm-8, with the new release (19.0.x)
<doko> tjaalton: please subscribe your team to the package ...
<tjaalton> yep
<doko> I think 7 didn't have a subscriber
<tjaalton> possible
<tjaalton> subscribed to both
<tjaalton> also, I'd need an ack for bug 1818516
<ubot5> bug 1818516 in mesa (Ubuntu) "FFe: Mesa 19.0.x for disco" [Medium,New] https://launchpad.net/bugs/1818516
-queuebot:#ubuntu-release- Unapproved: rejected figtree [sync] (bionic-proposed) [1.4.4-3~18.04.1]
<cpaelzer> sil2100: I'll take a look for LXD due to libseccomp
<cpaelzer> since the tests come in so much time after our upload (wait for SRU accept, and then build and then test) I fail to regularly check them
<sil2100> cpaelzer: thanks o/ Probably unrelated, but yeah, still want someone to double-confirm
<cpaelzer> we'd need a better way than you guys sending a ping to catch those
<cpaelzer> maybe whatever generates http://people.canonical.com/~ubuntu-archive/pending-sru could one day send a mail?
<sil2100> cpaelzer: there's a branch for that!
<sil2100> Not for e-mails though
<sil2100> We have an MP in review for sending bug comments on ADT regressions
<cpaelzer> sounds great
<cpaelzer> sil2100: as expected the issues were unrelated and just flaky, they are all green now
<ginggs> would someone please 'force-badtest octave-image/2.10.0-2/ppc64el' ?  it has regressed in release (as did amd64 and i386, which are already hinted)
<doko> vorlon, sil2100: removing eclipse-platform-text and eclipse-platform-ui from bionic-proposed, replacing the 4.10 versions to 4.9, required for the swt4-gtk downgrade
-queuebot:#ubuntu-release- New sync: eclipse-platform-text (bionic-proposed/primary) [4.9-1~18.04]
-queuebot:#ubuntu-release- New sync: eclipse-platform-ui (bionic-proposed/primary) [4.9-1~18.04]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-text [sync] (bionic-proposed) [4.9-1~18.04]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-ui [sync] (bionic-proposed) [4.9-1~18.04]
<sil2100> doko: ACK
<doko> sil2100, vorlon: please update https://paste.ubuntu.com/p/K5xnm7k5YF/
<doko> fixing version numbers, and adding a line with new uploads
<doko> vorlon, sil2100: and now downgrade the rest of of the eclipse packages to 4.9 ...
-queuebot:#ubuntu-release- New sync: eclipse-jdt-core (bionic-proposed/primary) [4.9-1~18.04]
-queuebot:#ubuntu-release- New sync: eclipse-jdt-debug (bionic-proposed/primary) [4.9-1~18.04]
-queuebot:#ubuntu-release- New sync: eclipse-platform-debug (bionic-proposed/primary) [4.9-1~18.04]
-queuebot:#ubuntu-release- New sync: eclipse-platform-runtime (bionic-proposed/primary) [4.9-1~18.04]
-queuebot:#ubuntu-release- New sync: eclipse-platform-ua (bionic-proposed/primary) [4.9-1~18.04]
-queuebot:#ubuntu-release- New sync: eclipse-jdt-ui (bionic-proposed/primary) [4.9-1~18.04]
-queuebot:#ubuntu-release- New sync: eclipse-platform-team (bionic-proposed/primary) [4.9-1~18.04]
-queuebot:#ubuntu-release- New sync: eclipse-platform-resources (bionic-proposed/primary) [4.9-1~18.04]
-queuebot:#ubuntu-release- New: accepted eclipse-jdt-core [sync] (bionic-proposed) [4.9-1~18.04]
-queuebot:#ubuntu-release- New: accepted eclipse-jdt-ui [sync] (bionic-proposed) [4.9-1~18.04]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-resources [sync] (bionic-proposed) [4.9-1~18.04]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-team [sync] (bionic-proposed) [4.9-1~18.04]
-queuebot:#ubuntu-release- New: accepted eclipse-jdt-debug [sync] (bionic-proposed) [4.9-1~18.04]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-runtime [sync] (bionic-proposed) [4.9-1~18.04]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-debug [sync] (bionic-proposed) [4.9-1~18.04]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-ua [sync] (bionic-proposed) [4.9-1~18.04]
<mitya57> Eickmeyer: I see that carla is uploaded now, but I still have a comment about it. It build-depends on libqt4-dev, however we have a goal of removing Qt 4 from Ubuntu: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=qt4-removal
<mitya57> The same applies to libgtk2.0-dev, that is also a deprecated library. Please consider removing Qt 4 and GTK 2 support in the next version.
<doko> sil2100, vorlon: updated version numbers: https://paste.ubuntu.com/p/4wh4X8h4yG/
-queuebot:#ubuntu-release- Unapproved: nova (bionic-proposed/main) [2:17.0.7-0ubuntu2 => 2:17.0.9-0ubuntu1] (openstack, ubuntu-server)
<Laney> turning off bos01 autopkgtest runners for now, the cloud seems busted atm /o\
<doko> is this ppc64el only?
<Laney> arm64 s390x ppc64el
<Laney> there's a second region serving those architectures, so it's only reduced service
-queuebot:#ubuntu-release- Unapproved: swift (bionic-proposed/main) [2.17.0-0ubuntu1 => 2.17.1-0ubuntu1] (openstack, ubuntu-server)
 * sil2100 is publishing images slowly for 14.04.6
<gaughen> sil2100, how goes 14.04.6
<gaughen> ha!
<gaughen> jinx
<sil2100> gaughen: I knew you're going to ask, which is why I started pressing the buttonz
<Laney> keylogger existence disclosed
 * Laney extracts sil2100 
<gaughen> :-)
 * sil2100 jumps on the ladder Laney drops from his helicopter and they both fly away in haste
-queuebot:#ubuntu-release- Unapproved: cinder (bionic-proposed/main) [2:12.0.4-0ubuntu1 => 2:12.0.5-0ubuntu1] (openstack, ubuntu-server)
<Eickmeyer> mitya57: Thanks! I think those are relics from a previous version of the package which was Qt4 based. Upstream migrated to Qt5 a long time ago.
<sil2100> Ok, images are out
<Eickmeyer> Would anybody be willing to speed grub2-themes-ubuntustudio through the NEW queue? We have another package waiting for that one before any action can be taken on its upload. cyphermox and mitya57 have been helping. :)
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-304 [source] (xenial-proposed) [304.135-0ubuntu0.16.04.3]
-queuebot:#ubuntu-release- New binary: ubuntustudio-look [amd64] (disco-proposed/universe) [0.56] (no packageset)
<rbasak> vorlon: ^ I believe you have volunteered? :-P
-queuebot:#ubuntu-release- New: accepted ubuntustudio-look [amd64] (disco-proposed) [0.56]
<Eickmeyer> Looks like the package in question is uploaded (ubuntustudio-look), but it has a dependency problem on grub2-themes-ubuntustudio.
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-384 [source] (xenial-proposed) [384.130-0ubuntu0.16.04.2]
<Eickmeyer> mitya57, cyphermox: Would you be willing to look at these PPU applictions since you've seen and reviewed our packages? Again, thanks for your help. https://wiki.ubuntu.com/Eickmeyer/PPUApplication https://wiki.ubuntu.com/RossGammon/PPUApplication
<mitya57> I will leave a comment on both, yes
<Eickmeyer> Thanks. :)
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [source] (xenial-proposed) [5.1.38-dfsg-0ubuntu1.16.04.3]
<sil2100> jibel: thanks for all the 14.04.6 testing o/
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (xenial-proposed) [5.1.38-dfsg-0ubuntu1.16.04.2]
<jibel> sil2100, you're welcome :) thanks for driving the release o/
-queuebot:#ubuntu-release- Unapproved: gettext (bionic-proposed/main) [0.19.8.1-6ubuntu0.2 => 0.19.8.1-6ubuntu0.3] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: openjfx (bionic-proposed/universe) [11.0.2+1-1~18.04.1 => 11.0.2+1-1~18.04.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: openjdk-11-jre-dcevm (bionic-proposed/universe) [11.0.1+8-1~18.04 => 11.0.1+8-1~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: tomcat-native (bionic-proposed/universe) [1.2.21-1~18.04 => 1.2.21-1~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-340 [source] (xenial-proposed) [340.107-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: java3d (bionic-proposed/universe) [1.5.2+dfsg-16~18.04.1 => 1.5.2+dfsg-16~18.04.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: visualvm (bionic-proposed/universe) [1.4.2-2~18.04 => 1.4.2-2~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: zeroc-ice (bionic-proposed/universe) [3.7.0-5 => 3.7.0-5ubuntu0.2] (cli-mono) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox-lts-xenial [source] (trusty-proposed) [4.3.40-dfsg-0ubuntu1.14.04.1~14.04.4]
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox-lts-xenial [source] (trusty-proposed) [4.3.40-dfsg-0ubuntu1.14.04.1~14.04.4]
-queuebot:#ubuntu-release- Unapproved: accepted gettext [sync] (bionic-proposed) [0.19.8.1-6ubuntu0.3]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-384 [source] (trusty-proposed) [384.130-0ubuntu0.14.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted openjfx [sync] (bionic-proposed) [11.0.2+1-1~18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-11-jre-dcevm [sync] (bionic-proposed) [11.0.1+8-1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted tomcat-native [sync] (bionic-proposed) [1.2.21-1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted java3d [sync] (bionic-proposed) [1.5.2+dfsg-16~18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-304 [source] (trusty-proposed) [304.135-0ubuntu0.14.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted visualvm [sync] (bionic-proposed) [1.4.2-2~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted zeroc-ice [sync] (bionic-proposed) [3.7.0-5ubuntu0.2]
<doko> vorlon: https://paste.ubuntu.com/p/Y7mykgN33J/  updated again for the above uploads
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-340 [source] (trusty-proposed) [340.107-0ubuntu0.14.04.1]
<vorlon> doko: you could raise an mp for that rather than a pastebin...
<doko> next time, afk now
-queuebot:#ubuntu-release- Unapproved: accepted gdm3 [source] (bionic-proposed) [3.28.3-0ubuntu18.04.5]
<vorlon> Eickmeyer: hi
<Eickmeyer> vorlon: Hi!
<vorlon> Eickmeyer: I've identified a couple of issues in the package in the new queue, one of which I think is a blocker; I'm just finishing up posting my notes to LP: #1818373 now
<ubot5> Launchpad bug 1818373 in ubuntustudio-meta (Ubuntu) "[needs-packaging] [FFe] grub2-themes-ubuntustudio" [Wishlist,Triaged] https://launchpad.net/bugs/1818373
<vorlon> Eickmeyer: can you explain to me why debian/postinst is expected to do anything?
<vorlon> (comment posted)
<Eickmeyer> vorlon: It's just to trigger an update of grub to apply the new theme.
<Eickmeyer> Is that bad?
<vorlon> Eickmeyer: but I see nothing in the package that actually causes this theme to be selected
<Eickmeyer> vorlon: That's done by the plymouth theme, a concept from which I borrowed from the default Ubuntu plymouth theme & grub theme.
<Eickmeyer> I would've wrapped them into the same package had the grub theme not been a fork.
<Eickmeyer> cyphermox knows more about that after inspecting the ubuntustudio-look package.
<vorlon> Eickmeyer: ok, but then what you have is a race condition wrt which package is configured / unpacked first, and the theme may not be applied.  The plymouth package which triggers the changes to /usr/share/plymouth/themes/default.grub should be the package that calls update-grub (and should depend on the grub theme package)
<vorlon> we should call update-grub exactly once, when the theme config change is guaranteed to have been applied to the fs
<Eickmeyer> vorlon: I'm pretty sure that exists in grub2-themes-ubuntu-mate then.
<vorlon> Eickmeyer: I downloaded grub2-themes-ubuntu-mate and don't see that debian/post{inst,rm} there
-queuebot:#ubuntu-release- New source: masakari-monitors (disco-proposed/primary) [7.0.0~b1-0ubuntu1]
<cyphermox> vorlon: it's more complicated than that though
<cyphermox> I couldn't find where that file was being used at all
<vorlon> cyphermox: which file?
<vorlon> /usr/share/plymouth/themes/default.grub is referenced by /etc/grub.d/05_debian_theme
<cyphermox> /usr/share/plymouth/theme/default.grub
<Eickmeyer> vorlon: I can go ahead and move the postinst code to the plymouth theme, if you'd like. I did just look, and yes, it's my file.
<cyphermox> did I fail to parse the sed command properly?
<cyphermox> oh, of course I did
<cyphermox> nevermind me.
<vorlon> Eickmeyer: and also make the plymouth theme package depend on the grub theme package
<Eickmeyer> vorlon: It already does depend.
<vorlon> ok
<vorlon> then yes, that'll do it
<vorlon> Eickmeyer: and I'm happy to sponsor fixed versions of both packages if you can prepare them somewhere
<Eickmeyer> vorlon: Work in progress right now.
<coreycb> hi all, i seeded some masakari packages in Feb and expected that to create component mismatches but I've not any yet.
<coreycb> not seen
<coreycb> any thoughts? maybe i'm missing a step.
<vorlon> cyphermox: seeded where?
<vorlon> cyphermox: sorry
<vorlon> coreycb: seeded where?
<coreycb> vorlon: seeded in platform/supported-misc-servers
<vorlon> coreycb: not according to https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/+ref/disco
<Eickmeyer> vorlon: The lintian error you mentioned is saying current is 4.2.1 when the lintian error I got was current is 4.3.0, which is what is in debian/control on grub2-themes-ubuntustudio. Can I get some clarification here?
<vorlon> Eickmeyer: oh oops, sorry - I always (frequently) read that lintian message backwards, it's dumb that when I run lintian on a stable release it complains about time not standing still
<vorlon> Eickmeyer: so that's my mistake, please ignore
<coreycb> vorlon: oh.. it looks like the default branch is cosmic
<Eickmeyer> Ok
<vorlon> coreycb: heh fail. fixed now; do you want to revert your cosmic change and push to disco, then?
<coreycb> vorlon: yes sure, and thanks :)
<vorlon> (also, this is why we should always call trunk branches 'devel' and never name them after the series)
<tsimonq2> Eickmeyer: It's not a bad idea to run Lintian with -EViL +pedantic (just like sponsors >_>)
<tsimonq2> *ahem* just like sponsors run
<tsimonq2> ;)
<coreycb> vorlon: follow on question, we have another source package for masakari that i've just pushed to disco. would it be ok if i seed that too at this point in the cycle?
<coreycb> to disco NEW that is
<vorlon> coreycb: yes
<Eickmeyer> tsimonq2: I did run with pedantic.
<coreycb> vorlon: thanks
<vorlon> sil2100: hi
<tsimonq2> Eickmeyer: Try with -EViL too then ;)
-queuebot:#ubuntu-release- New binary: gcc-8-cross-mipsen [amd64] (disco-proposed/universe) [2~c2ubuntu1] (no packageset)
<Eickmeyer> tsimonq2: -_- Maybe next time. Right now I'm just trying to fix those two packages.
<vorlon> sil2100: can I actually get a review of https://code.launchpad.net/~vorlon/ubuntu-cdimage/prune-obsolete-code/+merge/363782 please? :)  at the mention of this branch's existence, jibel + didrocks seem to have rebased some of their changes on it, so now it's a critical path for their branch
<Eickmeyer> vorlon: On the copyright issue, should I simply delete all of the stanzas except the one with *, or do those need to be wrapped into the * stanza?
<vorlon> Eickmeyer: * already matches everything recursively so there's no need to call out the other bits separately; you can just drop the other two stanza
<vorlon> s
<Eickmeyer> Sounds good.
<sil2100> vorlon: hey! Sure ;)
<sil2100> HOLY SHIT IT'S THAT BRANCH
<vorlon> sil2100: diffstat shows net negative LOC, WHAT COULD GO WRONG
-queuebot:#ubuntu-release- New binary: gcc-8-cross-mipsen [i386] (disco-proposed/universe) [2~c2ubuntu1] (no packageset)
<tsimonq2> 4813 lines (+594/-1579)
<tsimonq2> XD
<tsimonq2> 1:3 basically
-queuebot:#ubuntu-release- New: accepted gcc-8-cross-mipsen [amd64] (disco-proposed) [2~c2ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-8-cross-mipsen [i386] (disco-proposed) [2~c2ubuntu1]
<Eickmeyer> vorlon: Just pushed fixes to both grub2-themes-ubuntustudio and ubuntustudio-look. https://launchpad.net/grub2-theme-ubuntustudio and https://launchpad.net/ubuntustudio-look respectively.
<vorlon> Eickmeyer: grabbing
<vorlon> Eickmeyer: it looks like you did revert the Standards-Version after all; was that an accident?
<Eickmeyer> Oops, yes. Sorry.
-queuebot:#ubuntu-release- New binary: gcc-defaults-mipsen [i386] (disco-proposed/none) [1.181.1] (no packageset)
<vorlon> Eickmeyer: also, I said to squash only the debian/copyright stanzas for debian/* and theme.txt; you can't collapse the *.png one, that has a different license
-queuebot:#ubuntu-release- New binary: gcc-defaults-mipsen [amd64] (disco-proposed/none) [1.181.1] (no packageset)
<Eickmeyer> vorlon: I'll revert that. My mistake.
<Eickmeyer> vorlon: Fixed the standards-version and added the *.png copyright stanza back.
<Eickmeyer> vorlon: Also pushed a minor change to -look regarding the "update-grub2" to be changed to "update-grub".
-queuebot:#ubuntu-release- New source: grub2-themes-ubuntustudio (disco-proposed/primary) [0.1]
-queuebot:#ubuntu-release- New: accepted gcc-defaults-mipsen [amd64] (disco-proposed) [1.181.1]
-queuebot:#ubuntu-release- New: rejected grub2-themes-ubuntustudio [source] (disco-proposed) [0.1]
-queuebot:#ubuntu-release- New: accepted gcc-defaults-mipsen [i386] (disco-proposed) [1.181.1]
-queuebot:#ubuntu-release- New: accepted grub2-themes-ubuntustudio [source] (disco-proposed) [0.1]
<vorlon> Eickmeyer: thanks, uploaded && accepted
<Eickmeyer> vorlon: Thanks!
-queuebot:#ubuntu-release- Unapproved: distro-info-data (cosmic-proposed/main) [0.38ubuntu0.1 => 0.38ubuntu0.2] (core)
<Eickmeyer> If you're ever in Seattle, I might have to get you a steak dinner (along with cyphermox and mitya57). :)
<Eickmeyer> vorlon: ^
-queuebot:#ubuntu-release- Unapproved: distro-info (cosmic-proposed/main) [0.18 => 0.18ubuntu0.18.10.1] (core)
-queuebot:#ubuntu-release- New binary: grub2-themes-ubuntustudio [amd64] (disco-proposed/none) [0.1] (no packageset)
<vorlon> Eickmeyer: now ubuntustudio-look, the branch history doesn't seem to match the archive, I see 0.56 has already been uploaded
<vorlon> Eickmeyer: do you want to fix up the history or shall I?
<Eickmeyer> vorlon: Yeah, I don't know how that happened.
 * Eickmeyer doesn't even know how to fix that.
<vorlon> Eickmeyer: depends on whether you want to git push --force or not
<vorlon> (which I think is fine in this case)
<Eickmeyer> Okay, I'll do that.
<Eickmeyer> vorlon: "Everything up-to-date".
<vorlon> basically, you: branch from before your most recent commit; land the changes to match what's uploaded to the archive; (optionally) tag; cherry-pick your new changes onto the branch; then git push --force that to the trunk
<Eickmeyer> Working...
<Eickmeyer> vorlon: Go ahead and do another clone, I think I fixed it.
-queuebot:#ubuntu-release- Unapproved: distro-info (bionic-proposed/main) [0.18 => 0.18ubuntu0.18.04.1] (core)
<vorlon> Eickmeyer: branch history still doesn't show me a commit that corresponds to the 0.56 upload
<Eickmeyer> vorlon: That's strainge, mitya57 did that earlier today.
<vorlon> Eickmeyer: would you like me to do the surgery?
<Eickmeyer> Sure.
-queuebot:#ubuntu-release- Unapproved: distro-info-data (bionic-proposed/main) [0.37ubuntu0.2 => 0.37ubuntu0.3] (core)
<Eickmeyer> vorlon: Did you figure out what went wrong with the history on that?
<vorlon> Eickmeyer: well without knowing what you did I can't say what went wrong; but I'm pushing the fixed branch now
<Eickmeyer> Okay, perfect.
<vorlon> Eickmeyer: done
<Eickmeyer> vorlon: Knowing that everything is getting better is a huge relief. I cannot tell you how much I appreciate all of this.
<Eickmeyer> With my PPU and Ross's PPU apps in, I am going to take the next few days and relax before Monday's meeting.
<vorlon> Eickmeyer: please drop the 'which update-grub2' check
<vorlon> Eickmeyer: (or I can before upload)
<vorlon> and do you want to push a debian/changelog?
<Eickmeyer> vorlon: Is there no debian/changelog?
<vorlon> Eickmeyer: there are no changelog entries for your two latest commits
<Eickmeyer> Oh, okay. I'll add those.
<Eickmeyer> vorlon: Changes are pushed.
-queuebot:#ubuntu-release- New: accepted grub2-themes-ubuntustudio [amd64] (disco-proposed) [0.1]
<doko> vorlon: ping scipy
-queuebot:#ubuntu-release- Unapproved: distro-info-data (xenial-proposed/main) [0.28ubuntu0.9 => 0.28ubuntu0.10] (core)
-queuebot:#ubuntu-release- Unapproved: distro-info (xenial-proposed/main) [0.18~ubuntu16.04.1 => 0.14ubuntu0.1] (core)
<mitya57> vorlon: âthere should be no reason for an out-of-date standards versionâ â 4.3.0 was not out of date, but now Erich reverted to 4.2.1 which is :)
<vorlon> mitya57: didn't we manage to un-revert?
<Eickmeyer> vorlon, mitya57: I un-reverted that.
<mitya57> Ah, you did. Nevermind then.
<Eickmeyer> vorlon: Did you get my changes to ubuntustudio-look, including updating the changelog?
<vorlon> Eickmeyer: just pulled; you appear to have modified the changelog for 0.56 which is wrong because that's already uploaded, this needs to be a new 0.57 changelog entry
<vorlon> doko: what hint should I be adding?
<Eickmeyer> vorlon: Ah, right.
<Eickmeyer> vorlon: Bumped version, fixed changelog
<doko> vorlon: that would be for python-scipy/1.2.1-0ubuntu1 on amd64 and i386. but I see that there is a new python-numpy upload, so lets wait for these results. I retried to autopkg tests now
<vorlon> Eickmeyer: note that 'git diff 0.56' still shows a change to the previous changelog entry vs what I tagged as being in the archive, please clean this up too :)
<vorlon> doko: ok
<vorlon> doko: I saw discussion about python-scipy on debian-python today fwiw
<doko> vorlon: that's unrelated, old scipy
<vorlon> ok
<doko> $ fgrep scipy *
<doko> ubuntu-release:force-badtest python-scipy/1.1.0-2/i386
<doko> vorlon: ^^^but please update that hint
<mitya57> Eickmeyer: https://wiki.ubuntu.com/Eickmeyer/PPUApplication#Dmitry_Shachnev
<vorlon> doko: python-scipy/i386 hint bumped, amd64 left alone
<Eickmeyer> vorlon: I think I just got 0.57's tag pushed.
<Eickmeyer> I did a diff and it seems to make sense.
<Eickmeyer> mitya57: Thanks!
-queuebot:#ubuntu-release- Unapproved: pacemaker (xenial-proposed/main) [1.1.14-2ubuntu1.4 => 1.1.14-2ubuntu1.5] (ubuntu-server)
<vorlon> Eickmeyer: I don't see any new commits pushed
-queuebot:#ubuntu-release- Unapproved: netplan.io (cosmic-proposed/main) [0.40.2.2 => 0.96-0ubuntu0.18.10.1] (core)
<Eickmeyer> vorlon: Should be new commits now. Sorry I'm so slow.
<vorlon> Eickmeyer: 'git diff 0.56' still shows a diff to the uploader line for 0.56
<Eickmeyer> vorlon: Now I officially have no idea what I'm doing.
<vorlon> Eickmeyer: do you see the same thing as me when running 'git diff 0.56'? http://paste.ubuntu.com/p/YznmZpCygq/
<vorlon> Eickmeyer: it's the second diff hunk that's the problem - it looks like your latest commit reverted the upload target of 0.57, which is not what I was calling attention to
<Eickmeyer> vorlon: I see it now.
<Eickmeyer> vorlon: New commit. Sorry for being dense.
<Eickmeyer> vorlon: In the future, I promise not to waste your time on this. I know you're really busy.
<vorlon> Eickmeyer: uploaded, and pushed with tags (a tag that probably conflicts with one you have locally but didn't push)
<Eickmeyer> vorlon: Not a problem. I'll probably just re-clone to be overly cautious.
-queuebot:#ubuntu-release- Unapproved: distro-info-data (trusty-proposed/main) [0.18ubuntu0.10 => 0.18ubuntu0.11] (core)
-queuebot:#ubuntu-release- Unapproved: distro-info (trusty-proposed/main) [0.12 => 0.12ubuntu0.1] (core)
-queuebot:#ubuntu-release- Unapproved: qemu (xenial-proposed/main) [1:2.5+dfsg-5ubuntu10.34 => 1:2.5+dfsg-5ubuntu10.35] (ubuntu-server, virt)
#ubuntu-release 2019-03-08
<tsimonq2> vorlon: You removed the no-change rebuild of gdal from disco-proposed due to a mysql transition which isn't ready yet, but poppler needs it to be rebuilt to migrate.
<tsimonq2> Would it be okay to rebuild gdal now?
<vorlon> tsimonq2: yes
<tsimonq2> ack, thanks
<vorlon> jbicha: are you following through on the uninstallables from your geany sync? (geany-plugins)
<rnpalmer> beignet (x86 only) is stuck in -proposed because autopkgtest is testing it on architectures where it doesn't exist - bug 1815131
<ubot5> bug 1815131 in britney "runs autopkgtests on architectures where the package under test does not exist" [Undecided,New] https://launchpad.net/bugs/1815131
<rnpalmer> This now fails as uninstallable, but as it used to "pass" as "unknown restriction skippable", is considered a regression
-queuebot:#ubuntu-release- Unapproved: postgresql-10 (bionic-proposed/main) [10.6-0ubuntu0.18.04.1 => 10.7-0ubuntu0.18.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: postgresql-10 (cosmic-proposed/main) [10.6-0ubuntu0.18.10.1 => 10.7-0ubuntu0.18.10.1] (core)
-queuebot:#ubuntu-release- Unapproved: rejected snapd-glib [source] (cosmic-proposed) [1.46-0ubuntu0.18.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (cosmic-proposed) [3:14.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted golang-1.8 [source] (cosmic-proposed) [1.8.3-2ubuntu1.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted golang-1.8 [source] (bionic-proposed) [1.8.3-2ubuntu1.18.04.1]
<tjaalton> vorlon: hmm, I'll let you handle open-vm-tools, as I think you'll know best if the issues from previous review are all addressed now
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (cosmic-proposed) [1:2.12+dfsg-3ubuntu8.4]
-queuebot:#ubuntu-release- Unapproved: accepted nautilus [source] (cosmic-proposed) [1:3.26.4-0ubuntu7.2]
-queuebot:#ubuntu-release- Unapproved: accepted vaultlocker [source] (cosmic-proposed) [1.0.3-0ubuntu1.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted nautilus [source] (bionic-proposed) [1:3.26.4-0~ubuntu18.04.4]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (cosmic-proposed) [0.38ubuntu0.2]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info [source] (cosmic-proposed) [0.18ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info [source] (bionic-proposed) [0.18ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (bionic-proposed) [0.37ubuntu0.3]
<tjaalton> cyphermox: hi, I think the netplan.io sru's are a bit premature.. most bugs don't have any sru template and the package hasn't even made it through to disco because it's own tests are failing
<tjaalton> tkamppeter: is bug 1783298 unfixed in disco/cosmic?
<ubot5> bug 1783298 in cups (Ubuntu) "[SRU] AuthInfoRequired negotiate in cups 2.2.7 in Bionic does not work" [Undecided,Incomplete] https://launchpad.net/bugs/1783298
-queuebot:#ubuntu-release- Unapproved: accepted distro-info [source] (xenial-proposed) [0.14ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (xenial-proposed) [0.28ubuntu0.10]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info [source] (trusty-proposed) [0.12ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info-data [source] (trusty-proposed) [0.18ubuntu0.11]
-queuebot:#ubuntu-release- Unapproved: rejected snapd-glib [source] (bionic-proposed) [1.45-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted upower [source] (bionic-proposed) [0.99.7-2ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected gnome-software [source] (bionic-proposed) [3.28.1-0ubuntu4.18.04.9]
-queuebot:#ubuntu-release- Unapproved: rejected gnome-software [source] (bionic-proposed) [3.28.1-0ubuntu4.18.04.9]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate [source] (bionic-proposed) [12-3bionic2]
-queuebot:#ubuntu-release- Unapproved: accepted fwupdate-signed [source] (bionic-proposed) [1.19bionic2]
-queuebot:#ubuntu-release- Unapproved: fwupdate (bionic-proposed/main) [10-3 => 12-3bionic2] (core)
-queuebot:#ubuntu-release- Unapproved: fwupdate (bionic-proposed/main) [10-3 => 12-3bionic2] (core)
-queuebot:#ubuntu-release- Unapproved: fwupdate (bionic-proposed/main) [10-3 => 12-3bionic2] (core)
-queuebot:#ubuntu-release- Unapproved: fwupdate (bionic-proposed/main) [10-3 => 12-3bionic2] (core)
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox-lts-xenial [source] (trusty-proposed) [4.3.40-dfsg-0ubuntu1.14.04.1~14.04.5]
-queuebot:#ubuntu-release- Unapproved: accepted xdg-desktop-portal [source] (bionic-proposed) [1.0.3-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted xdg-desktop-portal-gtk [source] (bionic-proposed) [1.0.2-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-lts-xenial [source] (trusty-proposed) [4.3.36-dfsg-1+deb8u1ubuntu1.14.04.1~14.04.5]
-queuebot:#ubuntu-release- New binary: geany-plugins [s390x] (disco-proposed/universe) [1.34+dfsg-1~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: geany-plugins [amd64] (disco-proposed/universe) [1.34+dfsg-1~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: geany-plugins [i386] (disco-proposed/universe) [1.34+dfsg-1~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: geany-plugins [ppc64el] (disco-proposed/universe) [1.34+dfsg-1~build1] (no packageset)
<jbicha> vorlon: geany was waiting on geany-plugins in Debian NEW but I'll go ahead and upload it now to Ubuntu NEW
-queuebot:#ubuntu-release- Unapproved: libreoffice (bionic-proposed/main) [1:6.0.7-0ubuntu0.18.04.4 => 1:6.0.7-0ubuntu0.18.04.5] (kubuntu, ubuntu-desktop) (sync)
<tjaalton> jbicha: seems to be in ubuntu new already
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [sync] (bionic-proposed) [1:6.0.7-0ubuntu0.18.04.5]
<jbicha> :)
-queuebot:#ubuntu-release- New binary: geany-plugins [armhf] (disco-proposed/universe) [1.34+dfsg-1~build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-340 (xenial-proposed/restricted) [340.107-0ubuntu0.16.04.1 => 340.107-0ubuntu0.16.04.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted libsdl2 [source] (bionic-proposed) [2.0.8+dfsg1-1ubuntu1.18.04.3]
-queuebot:#ubuntu-release- New binary: geany-plugins [arm64] (disco-proposed/universe) [1.34+dfsg-1~build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (xenial-proposed) [1.13.4-1ubuntu1.13]
-queuebot:#ubuntu-release- Unapproved: accepted freeipmi [source] (xenial-proposed) [1.4.11-1.1ubuntu4.1~0.16.04]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-340 [source] (xenial-proposed) [340.107-0ubuntu0.16.04.2]
<tjaalton> tkamppeter: don't upload an SRU when the bug isn't yet fixed in the devel series..
<tjaalton> hmm, or maybe it is fixed in 2.2.10
<tjaalton> seems to be fixed in cosmic/2.2.8 too, but nothing is mentioned on the bug
-queuebot:#ubuntu-release- Unapproved: accepted cups [source] (bionic-proposed) [2.2.7-1ubuntu2.4]
-queuebot:#ubuntu-release- New: accepted geany-plugins [amd64] (disco-proposed) [1.34+dfsg-1~build1]
-queuebot:#ubuntu-release- New: accepted geany-plugins [armhf] (disco-proposed) [1.34+dfsg-1~build1]
-queuebot:#ubuntu-release- New: accepted geany-plugins [ppc64el] (disco-proposed) [1.34+dfsg-1~build1]
-queuebot:#ubuntu-release- New: accepted geany-plugins [arm64] (disco-proposed) [1.34+dfsg-1~build1]
-queuebot:#ubuntu-release- New: accepted geany-plugins [s390x] (disco-proposed) [1.34+dfsg-1~build1]
-queuebot:#ubuntu-release- New: accepted geany-plugins [i386] (disco-proposed) [1.34+dfsg-1~build1]
<Laney> rolling new lxd-armhf workers for autopkgtest
<Laney> a few of the previous ones had fallen over
 * apw hands Laney a medal for services above and beyond the call of duty
<rbasak> Could I get the release team's attention on https://lists.ubuntu.com/archives/ubuntu-devel/2019-February/040599.html please? Seems bad that someone has contacted us with an explanation of what's wrong and what we need to do, and we haven't responded.
<rbasak> She has filed bug 1815014 and everything.
<ubot5> bug 1815014 in beignet (Ubuntu) "Please let beignet (soon to be 1.3.2-6) out of -proposed" [Undecided,New] https://launchpad.net/bugs/1815014
<rbasak> These are the kinds of volunteers that we need more of, so please prioritise them.
<fidencio> jibel: hey/ping. is there some tools that can be used to validate a preseed file against a specific version of ubuntu/debian?
<fidencio> jibel: didrocks: is there some plan to add such a tool for the new yaml-based-installer?
 * Laney starts up 1 bos01-arm64 instance to see if it's working again
<didrocks> fidencio: I don't think so, but a good idea to keep in our roadmap
<teward> anyone able to give a review to https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1817750 which needs an FFe?
<ubot5> Ubuntu bug 1817750 in nginx (Ubuntu) "[FFe Needed] Please update NGINX to 1.15.9 in Ubuntu Disco" [Wishlist,New]
<vorlon> tjaalton: open-vm-tools> oh... thanks ;)
<vorlon> teward: is this the final version of nginx to ship with 19.04?
<teward> vorlon: that I intend to work on for 19.04 barring any major bugs that need fixes (or any major security vulns)?  Yes.
<vorlon> ok
<vorlon> teward: because if there were more coming, I would want to deal with them as part of the single FFe.  FFe granted, thanks.
<teward> vorlon: if this had been 20.04 LTS I'd have said "No" because we'd be trying to keep up with nginx mainline AHEAD of a release so that even if nginx stable is cut right as we release, we can SRU the version-string-only change.
<teward> vorlon: there's precedent for that from the 16.04 and 18.04 cycles, though, I think infinity was the one assisting in those drives at those times thoughj
<teward> vorlon: thanks I'll upload shortly, since it's approved.
<teward> there's some trickiness when we try and target a 'stable' branch release with NGINX for a release vs. a mainline specific branch
<teward> (Debian has the same headaches)
<teward> vorlon: uploaded and system has indicated it was accepted, barring any FTBFSes we'll be good to go
-queuebot:#ubuntu-release- Unapproved: indicator-application (bionic-proposed/universe) [12.10.1+17.04.20161201-0ubuntu1 => 12.10.1+18.04.20190308.1-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: indicator-application (cosmic-proposed/universe) [12.10.1+17.04.20161201-0ubuntu1 => 12.10.1+18.10.20190308.1-0ubuntu1] (ubuntu-desktop) (sync)
<teward> thanks again vorlon :)
-queuebot:#ubuntu-release- Unapproved: neutron-vpnaas (bionic-proposed/universe) [2:12.0.0-0ubuntu1 => 2:12.0.1-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: netplan.io (bionic-proposed/main) [0.40.1~18.04.4 => 0.96-0ubuntu0.18.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: distro-info (cosmic-proposed/main) [0.18ubuntu0.18.10.1 => 0.18ubuntu0.18.10.2] (core)
<bdmurray> vorlon: Could you have a look at those distro-infos for cosmic and trusty since I failed last time?
-queuebot:#ubuntu-release- Unapproved: distro-info (trusty-proposed/main) [0.12ubuntu0.1 => 0.12ubuntu0.2] (core)
<ginggs> tseliot: hi, any plans for nvida 418 drivers for disco?  needed for cuda 10.1 that supports gcc 8 and clang 7
<vorlon> Eickmeyer: whoops, ubuntustudio daily image build fails because of the added update-grub call (not because we added it there but because we added it at all)
<vorlon> this may be a livecd-rootfs bug
<Eickmeyer> vorlon: Good to know, thanks.
<Eickmeyer> vorlon: Should I remove it?
<Eickmeyer> vorlon: And, furthermore, would the if-exists check have prevented that?
<ginggs> would someone please 'force-badtest octave-image/2.10.0-2/ppc64el' ?  it has regressed in release (as did amd64 and i386, which are already hinted)
<vorlon> Eickmeyer: no, we shouldn't remove it; but we do need to work out how to make sure update-grub doesn't fail during this image build
<vorlon> there's lots of logic in livecd-rootfs around diverting grub-probe / os-prober to avoid this class of failure, so it's just a matter of making sure the right handling is applied around the ubuntustudio package installs
<Eickmeyer> vorlon: Okay, so basically, I just have to leave it in your capable hands, correct?
<vorlon> well
<vorlon> if someone were to fix it before me, that would not be amiss ;)
<Eickmeyer> Haha. Understood. I'm getting somewhere with packaging, but I'm not sure I can code my way out of a paper bag. :)
<tseliot> ginggs: hi, yes. I have it in a PPA (it doesn't come with transitional packages for 410 yet). I hope to upload it to 19.04 very soon. https://launchpad.net/~oem-solutions-group/+archive/ubuntu/nvidia-driver-staging
-queuebot:#ubuntu-release- Unapproved: angular-maven-plugin (bionic-proposed/universe) [0.3.4-2 => 0.3.4-3~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: antlr4 (bionic-proposed/universe) [4.5.3-2 => 4.7.2-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: gradle-apt-plugin (bionic-proposed/primary) [0.10-1~18.04]
-queuebot:#ubuntu-release- New sync: gradle-completion (bionic-proposed/primary) [1.3.1-1~18.04]
-queuebot:#ubuntu-release- Unapproved: ant-contrib (bionic-proposed/universe) [1.0~b3+svn177-9 => 1.0~b3+svn177-10~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: clojure-maven-plugin (bionic-proposed/universe) [1.7.1-1 => 1.7.1-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: maven-ant-helper (bionic-proposed/universe) [8.4 => 8.5~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: maven-dependency-analyzer (bionic-proposed/universe) [1.7-2 => 1.10-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: maven-jar-plugin (bionic-proposed/universe) [3.0.2-2 => 3.1.1-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ant (bionic-proposed/universe) [1.10.3-1ubuntu0.1 => 1.10.5-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: maven-clean-plugin (bionic-proposed/universe) [3.0.0-2 => 3.1.0-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: maven (bionic-proposed/universe) [3.5.2-2 => 3.6.0-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jarjar-maven-plugin (bionic-proposed/universe) [1.9-7 => 1.9-8~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: maven-doxia-tools (bionic-proposed/universe) [1.4-3 => 1.4-4~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: maven-cache-cleanup (bionic-proposed/primary) [1.0.4-1~18.04]
-queuebot:#ubuntu-release- Unapproved: maven-parent (bionic-proposed/universe) [27-2 => 31-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: maven-processor-plugin (bionic-proposed/universe) [3.3.2-2 => 3.3.3-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: maven-resolver (bionic-proposed/universe) [1.1.0-3 => 1.3.1-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: maven-shade-plugin (bionic-proposed/universe) [3.1.0-3 => 3.1.1-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: properties-maven-plugin (bionic-proposed/universe) [1.0.0-1 => 1.0.0-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: maven-plugin-testing (bionic-proposed/universe) [2.1-1 => 3.3.0-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: maven-resources-plugin (bionic-proposed/universe) [3.0.2-1 => 3.1.0-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: xml-maven-plugin (bionic-proposed/universe) [1.0.1-3 => 1.0.1-4~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: string-template-maven-plugin (bionic-proposed/primary) [1.1-1~18.04ubuntu1]
-queuebot:#ubuntu-release- Unapproved: maven-repo-helper (bionic-proposed/universe) [1.9.2 => 1.9.3~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: mojo-executor (bionic-proposed/primary) [2.3.0-1~18.04]
-queuebot:#ubuntu-release- Unapproved: maven-shared-utils (bionic-proposed/universe) [3.1.0-2 => 3.3.0-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted unity [sync] (cosmic-proposed) [7.5.0+18.10.20190304-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (cosmic-proposed) [2:10.3.5-7~ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: figtree (bionic-proposed/universe) [1.4.4-3~18.04 => 1.4.4-3~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libhibernate-validator-java (bionic-proposed/universe) [4.3.3-4 => 4.3.4-1~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: jxgrabkey (bionic-proposed/universe) [0.3.2-10~18.04 => 0.3.2-10~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libjackson-json-java (bionic-proposed/universe) [1.9.2-9 => 1.9.13-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: libscram-java (bionic-proposed/primary) [1.0.0~beta.2-3~18.04]
-queuebot:#ubuntu-release- Unapproved: libjdo-api-java (bionic-proposed/universe) [3.1-2 => 3.1-3~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libnetx-java (bionic-proposed/universe) [0.5-3 => 0.5-4~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libpicocontainer-java (bionic-proposed/universe) [2.15-2 => 2.15+repack-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libsambox-java (bionic-proposed/universe) [1.1.19-1 => 1.1.46-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libspring-java (bionic-proposed/universe) [4.3.14-1 => 4.3.22-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libxml-security-java (bionic-proposed/universe) [1.5.8-2 => 2.0.10-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: lucene-solr (bionic-proposed/universe) [3.6.2+dfsg-11 => 3.6.2+dfsg-18~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libjdom1-java (bionic-proposed/universe) [1.1.3-1 => 1.1.3-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libquartz-java (bionic-proposed/universe) [1:1.8.6-5 => 1:1.8.6-6~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libswingx-java (bionic-proposed/universe) [1:1.6.2-3 => 1:1.6.2-4~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libpdfbox2-java (bionic-proposed/universe) [2.0.9-1 => 2.0.13-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libxstream-java (bionic-proposed/universe) [1.4.10-1 => 1.4.11.1-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: mckoisqldb (bionic-proposed/primary) [1.0.6-2~18.04]
-queuebot:#ubuntu-release- Unapproved: libsejda-java (bionic-proposed/universe) [3.2.38-1 => 3.2.66-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- New sync: obantoo (bionic-proposed/primary) [2.1.12+ds1-2~18.04]
-queuebot:#ubuntu-release- New sync: mapsforge (bionic-proposed/primary) [0.10.0+dfsg.1-1ubuntu0~18.04.1]
-queuebot:#ubuntu-release- Unapproved: mavibot (bionic-proposed/universe) [1.0.0~M1-2 => 1.0.0~M8-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: mockito (bionic-proposed/universe) [1.10.19-2 => 1.10.19-4~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: objenesis (bionic-proposed/universe) [2.6-1 => 3.0.1-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: openhft-chronicle-core (bionic-proposed/universe) [1.1.8-1 => 2.17.5-v1.1.8-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: openjpa (bionic-proposed/universe) [2.4.2-4 => 2.4.2-6~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: pdfsam (bionic-proposed/universe) [3.3.5-1 => 4.0.1-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: procyon (bionic-proposed/universe) [0.5.32-3 => 0.5.32-5~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: rdp-classifier (bionic-proposed/universe) [2.10.2-2 => 2.10.2-4~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: mobile-atlas-creator (bionic-proposed/universe) [1.9.16+dfsg1-1 => 2.1.0-1~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: openhft-chronicle-bytes (bionic-proposed/universe) [1.1.15-1 => 1.1.15-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: orthanc-imagej (bionic-proposed/universe) [1.1+dfsg-2 => 1.2+dfsg-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: rdp-alignment (bionic-proposed/universe) [1.2.0-3 => 1.2.0-5~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: msv (bionic-proposed/universe) [2009.1+dfsg1-5 => 2009.1+dfsg1-6~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: plexus-io (bionic-proposed/universe) [3.0.0-1 => 3.1.1-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: openhft-lang (bionic-proposed/universe) [6.7.6-1 => 6.7.6-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: rdp-readseq (bionic-proposed/universe) [2.0.2-3 => 2.0.2-6~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: resteasy3.0 (bionic-proposed/universe) [3.0.19-2 => 3.0.26-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: rsyntaxtextarea (bionic-proposed/universe) [2.5.0-1 => 2.5.8-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: sitemesh (bionic-proposed/universe) [2.4.1+dfsg-6 => 2.4.1+dfsg-7~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: svgsalamander (bionic-proposed/universe) [1.1.1+dfsg-2 => 1.1.1+dfsg-3~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: trove3 (bionic-proposed/universe) [3.0.3-4 => 3.0.3-5~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: unsafe-mock (bionic-proposed/universe) [8.0-2 => 8.0-3~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: xmlbeans (bionic-proposed/universe) [2.6.0+dfsg-3 => 3.0.2-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: rome (bionic-proposed/universe) [1.0-7 => 1.12.0-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: snakeyaml (bionic-proposed/universe) [1.20-1 => 1.23-1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: uimaj (bionic-proposed/universe) [2.10.1-2 => 2.10.2-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: shiro (bionic-proposed/universe) [1.3.2-2 => 1.3.2-3~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: writer2latex (bionic-proposed/universe) [1.4-3 => 1.4-8~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: timingframework (bionic-proposed/universe) [1.0-1 => 1.0-2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (bionic-proposed) [2:10.3.5-7~ubuntu0.18.04.1]
#ubuntu-release 2019-03-09
-queuebot:#ubuntu-release- Unapproved: accepted distro-info [source] (cosmic-proposed) [0.18ubuntu0.18.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted distro-info [source] (trusty-proposed) [0.12ubuntu0.2]
-queuebot:#ubuntu-release- Unapproved: accepted angular-maven-plugin [sync] (bionic-proposed) [0.3.4-3~18.04]
-queuebot:#ubuntu-release- Unapproved: postgresql-10 (bionic-proposed/main) [10.6-0ubuntu0.18.04.1 => 10.7-0ubuntu0.18.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted antlr4 [sync] (bionic-proposed) [4.7.2-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted ant [sync] (bionic-proposed) [1.10.5-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted ant-contrib [sync] (bionic-proposed) [1.0~b3+svn177-10~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted clojure-maven-plugin [sync] (bionic-proposed) [1.7.1-2~18.04]
-queuebot:#ubuntu-release- Unapproved: snapd-glib (bionic-proposed/main) [1.43-0ubuntu0.18.04.1 => 1.47-0ubuntu0.18.04.0] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted gradle-apt-plugin [sync] (bionic-proposed) [0.10-1~18.04]
-queuebot:#ubuntu-release- New: accepted gradle-completion [sync] (bionic-proposed) [1.3.1-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted jarjar-maven-plugin [sync] (bionic-proposed) [1.9-8~18.04]
-queuebot:#ubuntu-release- Unapproved: libxkbcommon (bionic-proposed/main) [0.8.0-1ubuntu0.1 => 0.8.2-1~ubuntu18.04.1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: accepted maven [sync] (bionic-proposed) [3.6.0-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted maven-ant-helper [sync] (bionic-proposed) [8.5~18.04]
-queuebot:#ubuntu-release- Unapproved: ruby2.5 (bionic-proposed/main) [2.5.1-1ubuntu1.1 => 2.5.1-1ubuntu1.3] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted maven-cache-cleanup [sync] (bionic-proposed) [1.0.4-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted maven-clean-plugin [sync] (bionic-proposed) [3.1.0-1~18.04]
-queuebot:#ubuntu-release- Unapproved: xfwm4 (bionic-proposed/universe) [4.12.4-0ubuntu1 => 4.12.5-1ubuntu0.18.04.1] (xubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted maven-dependency-analyzer [sync] (bionic-proposed) [1.10-1~18.04]
-queuebot:#ubuntu-release- Unapproved: glib2.0 (bionic-proposed/main) [2.56.3-0ubuntu0.18.04.1 => 2.56.4-0ubuntu0.18.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted maven-doxia-tools [sync] (bionic-proposed) [1.4-4~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted maven-jar-plugin [sync] (bionic-proposed) [3.1.1-1~18.04]
-queuebot:#ubuntu-release- Unapproved: libio-socket-ssl-perl (bionic-proposed/main) [2.056-1 => 2.060-3~ubuntu18.04.0] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted maven-parent [sync] (bionic-proposed) [31-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted maven-plugin-testing [sync] (bionic-proposed) [3.3.0-1~18.04]
-queuebot:#ubuntu-release- Unapproved: ruby-openssl (bionic-proposed/universe) [2.0.5-1build3 => 2.0.9-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted maven-processor-plugin [sync] (bionic-proposed) [3.3.3-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted maven-repo-helper [sync] (bionic-proposed) [1.9.3~18.04]
-queuebot:#ubuntu-release- Unapproved: python-cryptography (bionic-proposed/main) [2.1.4-1ubuntu1.2 => 2.1.4-1ubuntu1.3] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted maven-resolver [sync] (bionic-proposed) [1.3.1-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted maven-resources-plugin [sync] (bionic-proposed) [3.1.0-1~18.04]
-queuebot:#ubuntu-release- Unapproved: python2.7 (bionic-proposed/main) [2.7.15~rc1-1ubuntu0.1 => 2.7.15-4ubuntu4~18.04] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted maven-shade-plugin [sync] (bionic-proposed) [3.1.1-1~18.04]
-queuebot:#ubuntu-release- Unapproved: python3.6 (bionic-proposed/main) [3.6.7-1~18.04 => 3.6.8-1~18.04.1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted maven-shared-utils [sync] (bionic-proposed) [3.3.0-1~18.04]
-queuebot:#ubuntu-release- New: accepted mojo-executor [sync] (bionic-proposed) [2.3.0-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted properties-maven-plugin [sync] (bionic-proposed) [1.0.0-2~18.04]
-queuebot:#ubuntu-release- Unapproved: makedumpfile (bionic-proposed/main) [1:1.6.3-2 => 1:1.6.5-1ubuntu1~18.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted xml-maven-plugin [sync] (bionic-proposed) [1.0.1-4~18.04]
-queuebot:#ubuntu-release- Unapproved: linux-firmware (bionic-proposed/main) [1.173.3 => 1.173.4] (core, kernel)
-queuebot:#ubuntu-release- New: accepted string-template-maven-plugin [sync] (bionic-proposed) [1.1-1~18.04ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted figtree [sync] (bionic-proposed) [1.4.4-3~18.04.1]
-queuebot:#ubuntu-release- Unapproved: mate-screensaver (bionic-proposed/universe) [1.20.0-1 => 1.20.2-1~ubuntu18.04.1] (ubuntu-mate) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted jxgrabkey [sync] (bionic-proposed) [0.3.2-10~18.04.1]
-queuebot:#ubuntu-release- Unapproved: inxi (bionic-backports/universe) [2.3.56-1 => 3.0.24-1-1~ubuntu18.04.1] (ubuntu-mate, ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted libhibernate-validator-java [sync] (bionic-proposed) [4.3.4-1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted libjackson-json-java [sync] (bionic-proposed) [1.9.13-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted libjdo-api-java [sync] (bionic-proposed) [3.1-3~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted libjdom1-java [sync] (bionic-proposed) [1.1.3-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted libnetx-java [sync] (bionic-proposed) [0.5-4~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted libpdfbox2-java [sync] (bionic-proposed) [2.0.13-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted libpicocontainer-java [sync] (bionic-proposed) [2.15+repack-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted libquartz-java [sync] (bionic-proposed) [1:1.8.6-6~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted libsambox-java [sync] (bionic-proposed) [1.1.46-1~18.04]
-queuebot:#ubuntu-release- New: accepted libscram-java [sync] (bionic-proposed) [1.0.0~beta.2-3~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted libsejda-java [sync] (bionic-proposed) [3.2.66-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted libspring-java [sync] (bionic-proposed) [4.3.22-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted libswingx-java [sync] (bionic-proposed) [1:1.6.2-4~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted libxml-security-java [sync] (bionic-proposed) [2.0.10-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted libxstream-java [sync] (bionic-proposed) [1.4.11.1-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted lucene-solr [sync] (bionic-proposed) [3.6.2+dfsg-18~18.04]
<acheronuk> vorlon: FFe delegations for Kubuntu. I assume can s/cosmic/disco here? https://wiki.ubuntu.com/FreezeExceptionProcess#Packageset_FFe_Delegations
-queuebot:#ubuntu-release- Unapproved: accepted mavibot [sync] (bionic-proposed) [1.0.0~M8-1~18.04]
-queuebot:#ubuntu-release- New: accepted mapsforge [sync] (bionic-proposed) [0.10.0+dfsg.1-1ubuntu0~18.04.1]
-queuebot:#ubuntu-release- New: accepted mckoisqldb [sync] (bionic-proposed) [1.0.6-2~18.04]
<vorlon> acheronuk: yes
<acheronuk> vorlon: TY
-queuebot:#ubuntu-release- Unapproved: accepted mobile-atlas-creator [sync] (bionic-proposed) [2.1.0-1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted mockito [sync] (bionic-proposed) [1.10.19-4~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted msv [sync] (bionic-proposed) [2009.1+dfsg1-6~18.04]
-queuebot:#ubuntu-release- New: accepted obantoo [sync] (bionic-proposed) [2.1.12+ds1-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted objenesis [sync] (bionic-proposed) [3.0.1-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted openhft-chronicle-bytes [sync] (bionic-proposed) [1.1.15-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted openhft-chronicle-core [sync] (bionic-proposed) [2.17.5-v1.1.8-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted openhft-lang [sync] (bionic-proposed) [6.7.6-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted openjpa [sync] (bionic-proposed) [2.4.2-6~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted orthanc-imagej [sync] (bionic-proposed) [1.2+dfsg-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted pdfsam [sync] (bionic-proposed) [4.0.1-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted plexus-io [sync] (bionic-proposed) [3.1.1-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted procyon [sync] (bionic-proposed) [0.5.32-5~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted rdp-alignment [sync] (bionic-proposed) [1.2.0-5~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted rdp-classifier [sync] (bionic-proposed) [2.10.2-4~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted rdp-readseq [sync] (bionic-proposed) [2.0.2-6~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted resteasy3.0 [sync] (bionic-proposed) [3.0.26-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted rome [sync] (bionic-proposed) [1.12.0-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted rsyntaxtextarea [sync] (bionic-proposed) [2.5.8-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted shiro [sync] (bionic-proposed) [1.3.2-3~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted sitemesh [sync] (bionic-proposed) [2.4.1+dfsg-7~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted snakeyaml [sync] (bionic-proposed) [1.23-1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted svgsalamander [sync] (bionic-proposed) [1.1.1+dfsg-3~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted timingframework [sync] (bionic-proposed) [1.0-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted trove3 [sync] (bionic-proposed) [3.0.3-5~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted uimaj [sync] (bionic-proposed) [2.10.2-2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted unsafe-mock [sync] (bionic-proposed) [8.0-3~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted writer2latex [sync] (bionic-proposed) [1.4-8~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted xmlbeans [sync] (bionic-proposed) [3.0.2-1~18.04]
<doko> vorlon: ^^^ not all of the above packages appear in -proposed Packages.gz. e.g. maven-shared-utils show in update_excuses but doesn't exist
<cjwatson> $ curl -s http://archive.ubuntu.com/ubuntu/dists/bionic-proposed/universe/binary-amd64/Packages.gz | zcat | grep-dctrl -SX maven-shared-utils | tbl-dctrl -H -d' ' -cPackage -cVersion
<cjwatson> libmaven-shared-utils-java 3.3.0-1~18.04
<cjwatson> libmaven-shared-utils-java-doc 3.3.0-1~18.04
<cjwatson> doko: ^-
<doko> hmm, then waiting. apt-get update doesn't see it yet
<doko> the above accepted syncs (msv .. xmlbeans). don't seem to be published
<doko> wait, they are, but update-excuses seems to be out of date
<ahasenack> doko: I'm starting the upload of the samba+deps stuff
<ahasenack> fyi
-queuebot:#ubuntu-release- New binary: talloc [s390x] (disco-proposed/main) [2.1.16-0ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: talloc [amd64] (disco-proposed/main) [2.1.16-0ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: talloc [i386] (disco-proposed/main) [2.1.16-0ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: talloc [ppc64el] (disco-proposed/main) [2.1.16-0ubuntu1] (core)
<ahasenack> hello archive admins, the talloc new binaries are python3-talloc{,dev}. This upload is dropping the py2 counterparts
<ahasenack> https://launchpad.net/ubuntu/+source/talloc/2.1.16-0ubuntu1
-queuebot:#ubuntu-release- New binary: talloc [arm64] (disco-proposed/main) [2.1.16-0ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: talloc [armhf] (disco-proposed/main) [2.1.16-0ubuntu1] (core)
<apw> ahasenack, are you handling all of the existing rdeps ?
<ahasenack> apw: yes, they are all in samba & friends
<ahasenack> I'm updating them all
<ahasenack> the only one where I had to keep the python2 one was tdb, because bzr-git wants it
<ahasenack> after this, I have tevent, then ldb, then samba itself
<ahasenack> all py3
-queuebot:#ubuntu-release- New: accepted talloc [amd64] (disco-proposed) [2.1.16-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted talloc [armhf] (disco-proposed) [2.1.16-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted talloc [ppc64el] (disco-proposed) [2.1.16-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted talloc [arm64] (disco-proposed) [2.1.16-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted talloc [s390x] (disco-proposed) [2.1.16-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted talloc [i386] (disco-proposed) [2.1.16-0ubuntu1]
<ahasenack> apw: thanks!
-queuebot:#ubuntu-release- New binary: kauth [s390x] (disco-proposed/universe) [5.56.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kauth [ppc64el] (disco-proposed/universe) [5.56.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kauth [amd64] (disco-proposed/universe) [5.56.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kauth [i386] (disco-proposed/universe) [5.56.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kauth [arm64] (disco-proposed/universe) [5.56.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kauth [armhf] (disco-proposed/universe) [5.56.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted kauth [amd64] (disco-proposed) [5.56.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kauth [armhf] (disco-proposed) [5.56.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kauth [ppc64el] (disco-proposed) [5.56.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kauth [arm64] (disco-proposed) [5.56.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kauth [s390x] (disco-proposed) [5.56.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kauth [i386] (disco-proposed) [5.56.0-0ubuntu1]
<vorlon> Eickmeyer: https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/+git/livecd-rootfs/+merge/364206 - I'm asking for review on it rather than just committing it diretly because I still find it surprising that no other flavor has had this problem and want a second set of eyeballs
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-openssl [sync] (bionic-proposed) [1.0.1-1ubuntu1.1]
-queuebot:#ubuntu-release- New binary: ldb [ppc64el] (disco-proposed/main) [2:1.5.4-0ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: ldb [s390x] (disco-proposed/main) [2:1.5.4-0ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: ldb [amd64] (disco-proposed/main) [2:1.5.4-0ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: ldb [i386] (disco-proposed/main) [2:1.5.4-0ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: ldb [arm64] (disco-proposed/main) [2:1.5.4-0ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: ldb [armhf] (disco-proposed/main) [2:1.5.4-0ubuntu1] (core)
<ahasenack> hi archive admins, the new ldb packages are python3-ldb and python3-ldb-dev, from the same source
<ahasenack> FFe bug is linked in d/changelog
#ubuntu-release 2019-03-10
<Eickmeyer> vorlon: ack
<Eickmeyer> vorlon: I find it especially interesting considering Ubuntu MATE has a similar grub theme, so perhaps Wimpress can shed some light on it as well?
-queuebot:#ubuntu-release- Unapproved: accepted ruby-openssl [sync] (bionic-proposed) [2.0.9-0ubuntu1]
<tsimonq2> infinity, vorlon: Could ubuntu-archive-tools be converted to Git? I have some code that uses copy-package and delete-package and I'd like to be able to define it as a Git submodule without having to keep git-remote-bzr in the job slave (and without some crazy wget/curl hardcoding).
<tsimonq2> You know, besides the other reasons it should be converted. :P
<tsimonq2> https://phab.lubuntu.me/source/ppa-britney/ <-- using the Bileto fetch-indexes script and Ubuntu's britney2 as a base, I'm working on a fully-functioning Britney to be used with PPAs, independent of Bileto.
<tsimonq2> I have it working locally, I just need to glue it all together either in a script or in the Jenkins job itself.
<tsimonq2> (Update: glued together and working. Yay.)
<Eickmeyer> {insert Britney Spears pun here}
<Eickmeyer> Sorry, couldn't resist.
-queuebot:#ubuntu-release- New: accepted ldb [amd64] (disco-proposed) [2:1.5.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ldb [armhf] (disco-proposed) [2:1.5.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ldb [ppc64el] (disco-proposed) [2:1.5.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ldb [arm64] (disco-proposed) [2:1.5.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ldb [s390x] (disco-proposed) [2:1.5.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ldb [i386] (disco-proposed) [2:1.5.4-0ubuntu1]
<doko> ahasenack: done
-queuebot:#ubuntu-release- New binary: nvtop [amd64] (disco-proposed/multiverse) [1.0.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted nvtop [amd64] (disco-proposed) [1.0.0-1ubuntu1]
<ahasenack> doko: thanks
<ahasenack> now comes the last one, samba itself
-queuebot:#ubuntu-release- New binary: samba [s390x] (disco-proposed/main) [2:4.10.0~rc4+dfsg-0ubuntu1] (core)
-queuebot:#ubuntu-release- New: accepted samba [s390x] (disco-proposed) [2:4.10.0~rc4+dfsg-0ubuntu1]
-queuebot:#ubuntu-release- New binary: samba [i386] (disco-proposed/main) [2:4.10.0~rc4+dfsg-0ubuntu1] (core)
-queuebot:#ubuntu-release- New: accepted samba [i386] (disco-proposed) [2:4.10.0~rc4+dfsg-0ubuntu1]
-queuebot:#ubuntu-release- New binary: samba [ppc64el] (disco-proposed/main) [2:4.10.0~rc4+dfsg-0ubuntu1] (core)
-queuebot:#ubuntu-release- New: accepted samba [ppc64el] (disco-proposed) [2:4.10.0~rc4+dfsg-0ubuntu1]
<doko> is somebody/something running automatical demotions?
<fossfreedom> yes I know its a sunday...! anybody any thoughts why our (Ubuntu Budgie) disco daily has failed today - I've hit the rebuild and it also fails http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-budgie/disco/daily-live-20190310.1.log
<acheronuk> UnknownManifestFile: .manifest has non-existent file /trusty/ubuntu-14.04.5-desktop-amd64.iso
<acheronuk> I would guess something a bit out of kilter after the trusty 14.04.6 point release? image removed but not all refs to it?
<acheronuk> sil2100 would be my bet to ask, but not online right now
<acheronuk> sorry. thought this was in flavours channel. I'll shut up and let proper release-team speak if they are about
<fossfreedom> thx acheronuk - yeah thought that looked very strange.  Forgot the trusty ISOs were respun last week.
<tsimonq2> Yeah, maybe vorlon knows.
<tsimonq2> Same thing with Lubuntu.
<acheronuk> Kubuntu seems ok.
<tsimonq2> O_O
<tsimonq2> hmm
<acheronuk> http://people.canonical.com/~ubuntu-archive/cd-build-logs/kubuntu/disco/daily-live-20190310.log
<tsimonq2> acheronuk: Wait, did Kubuntu do 14.04.6?
<acheronuk> nope
<acheronuk> so maybe...
-queuebot:#ubuntu-release- Unapproved: cockpit (cosmic-backports/universe) [187-1~ubuntu18.10.1 => 189-1~ubuntu18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (bionic-backports/universe) [187-1~ubuntu18.04.1 => 189-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (cosmic-backports) [189-1~ubuntu18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (bionic-backports) [189-1~ubuntu18.04.1]
<wxl> so it does seem to me that lubuntu's problem relates to non-participation in 14.04.6 as budgie also has the same problems and they also did not participate
<wxl> mate did not participate, either, but they never had a trusty release so that may be irrelevant
<wxl> xubuntu doesn't have the problem and they didn't participate, but perhaps this is timing related, since they have one of the earliest builds there is
<wxl> actually the two earliest are xubuntu and mate
<wxl> it seems that lp:ubuntu-cdimage doesn't have any changes quite that new, though
<acheronuk> kubuntu did not participate in, but our cd built
<acheronuk> we had a trusty release
<acheronuk> but we are early as well
<Eickmeyer> Anybody feeling brave enough to review carla?
#ubuntu-release 2020-03-02
<mwhudson> can a kind friendly AA process rustc through binary NEW please
<mwhudson> ?
-queuebot:#ubuntu-release- New: accepted rustc [amd64] (focal-proposed) [1.40.0+dfsg1+llvm-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [armhf] (focal-proposed) [1.40.0+dfsg1+llvm-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [ppc64el] (focal-proposed) [1.40.0+dfsg1+llvm-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [arm64] (focal-proposed) [1.40.0+dfsg1+llvm-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [s390x] (focal-proposed) [1.40.0+dfsg1+llvm-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [i386] (focal-proposed) [1.40.0+dfsg1+llvm-5ubuntu1]
<mwhudson> apw: thanks
<bdmurray> sil2100: Can you have a look at an early release for apport to -updates?
<bdmurray> sil2100: the verification is all done
<sil2100> bdmurray: looking
<seb128> is there any reason to not switch ubuntu-archive-tools to python3?
<seb128> no python2 launchpadlib on focal
<seb128> demote-to-proposed just work with python3, but I was wondering if others want to keep compatibility by doing archive tools on older series?
<cjwatson> seb128: Just needs to be tested and done
<cjwatson> seb128: It should mostly work modulo bitrot
<cjwatson> (and #! changes)
<cjwatson> seb128: But IMO feel free to JFDI anything you use and can test
<seb128> cjwatson, right, the question was mostly if depending on python3 would break people using e.g bionic (I didn't test there)
<cjwatson> No, it should be fine
<seb128> k, thanks, I though so but I preferred to still ask/get another opinion before doing it
<seb128> thx
<cjwatson> python3-launchpadlib goes back to xenial.  Older versions had some bugs, but I'd be surprised if many users of u-a-t were doing so on anything older than bionic at this point
<cjwatson> (at least xenial, anyway)
<seb128> right
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [5.0.0-1034.36] (kernel)
<kanashiro> LocutusOfBorg, thanks for jruby and ruby-psych
<LocutusOfBorg> kanashiro, my pleasure!
<enyc> LocutusOfBorg: meow!  at what point consider updating bionic vbox to 5.2.38  for compatible with newer kernels  (main reason)
<mfo> sil2100, hey. When you have a chance, could you please review util-linux in the upload queue for Eoan?
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-440 (eoan-proposed/multiverse) [440.59-0ubuntu0.19.10.1 => 440.59-0ubuntu0.19.10.2] (no packageset)
<tseliot> sil2100, hey, apparently the amd64 build of nvidia-graphics-drivers-440 failed to build in eoan-proposed. So, I have just uploaded a new release. Sorry. ^
<locutus_> enyc, bug?
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (eoan-proposed) [2.34-0.1ubuntu2.3]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [5.0.0-1034.36]
-queuebot:#ubuntu-release- Unapproved: accepted crash [source] (eoan-proposed) [7.2.8-1ubuntu0.19.10.1]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1058.62] (kernel)
<sil2100> tseliot: oh my, ok o/
<sil2100> hellsworth: hello! I'm looking at your libreoffice SRU upload right now, and I just have a quick question for double confirmation:
<tseliot> sil2100, thanks
<locutus_> vorlon, good morning, please hint aspectc++/i386?
<sil2100> hellsworth: ...actually, nvm! I think I have everything
<locutus_> satpy/proposed/s390x gained a dependency on python3-zarr->python3-numcodecs that is NBS on s390x, what can I do about it? it is an arch:all package that is not installable anymore on s390x, same on Debian, hint the test?
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (eoan-proposed) [1:6.3.5-0ubuntu0.19.10.1]
<sil2100> tseliot: ah, so the package_name does seem to matter in the end!
<ginggs> locutus_: LP: #1865437
<ubot5> Launchpad bug 1865437 in satpy (Ubuntu) "satpy: autopkgtest unable to run on s390x" [Undecided,New] https://launchpad.net/bugs/1865437
<tseliot> sil2100, what do you mean?
<locutus_> so apw please can you run "force-reset-test satpy/0.19.1-1/s390x" t fix LP: #1865437 ?
<ubot5> Launchpad bug 1865437 in satpy (Ubuntu) "satpy: autopkgtest unable to run on s390x" [Undecided,New] https://launchpad.net/bugs/1865437
<tseliot> sil2100, oh, now I remember, no it's definitely not that.
<hellsworth> sil2100: ah ok good you have anything but let me know if that changes :)
<sil2100> tseliot: ah, yeah, see more changes than that, thanks!
<sil2100> hellsworth: sure o/
<rbasak> FFe request in bug 1865518 please, just because it's a little late. I hope that the lack of being more than a few days late means that the bar is still low.
<ubot5> bug 1865518 in inspircd (Ubuntu) "[FFe] Update to inspircd 3.4.0-2 from Debian" [Undecided,New] https://launchpad.net/bugs/1865518
<enyc> locutus_: uerm? you'd like me to make an SRU request bug?
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-440 [source] (eoan-proposed) [440.59-0ubuntu0.19.10.2]
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-440 [i386] (eoan-proposed/multiverse) [440.59-0ubuntu0.19.10.2] (no packageset)
<locutus_> enyc, without a bug I won't act on anything, on stable it is required
<enyc> locutus_: I was (more) asking when it might be appropricate, // making the suggestion
<enyc> locutus_: you might say ... bionic should never be used with 5.4+ kernel
-queuebot:#ubuntu-release- Unapproved: rejected network-manager [source] (bionic-proposed) [1.10.6-2ubuntu1.4]
<doko> vorlon: please could you whitelist libxcrypt/i386? will be a new glibc dependency
<locutus_> enyc, I support whatever goes into linux-hwe and linux-hwe-edge
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1058.62]
<enyc> locutus_: AHA useful answer, that means 5.4.0 for bionic-updates seemingly
<locutus_> so, a bug report asking for "please update to 5.2.38" to support python3.8 and kernel up to 5.5 is a good start for me
<locutus_> and of course, test my builds
<enyc> locutus_: oh maybe not
<enyc> locutus_: is 5.3 seemingly
<locutus_> yes I know, but meh, the update to 5.2.38 is not too huge
<locutus_> so I can do it
<enyc> kernel.org list 5.4 as longterm so reasonable to presume likely to be the LTS-HWE kernel
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1055.58] (no packageset)
<locutus_> enyc, so, please check or open a bug, and test an eventual build I'll give you!
<enyc> bah!
<enyc> in https://bugs.launchpad.net/ubuntu/  signed in etc... try to click "report a bug"  [link to https://bugs.launchpad.net/ubuntu/+filebug]
<enyc> instead keep getting redirected to   https://help.ubuntu.com/community/ReportingBugs   !!!
-queuebot:#ubuntu-release- Packageset: Removed libmicrodns from i386-whitelist in focal
-queuebot:#ubuntu-release- Unapproved: sip4 (bionic-proposed/universe) [4.19.7+dfsg-1 => 4.19.7+dfsg-1ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libfprint [s390x] (focal-proposed/main) [1:1.90.1+tod1-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: libfprint [amd64] (focal-proposed/main) [1:1.90.1+tod1-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: libfprint [ppc64el] (focal-proposed/main) [1:1.90.1+tod1-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: libfprint [armhf] (focal-proposed/main) [1:1.90.1+tod1-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: libfprint [arm64] (focal-proposed/main) [1:1.90.1+tod1-0ubuntu1] (desktop-core)
<vorlon> doko: libxcrypt/i386 done
<ahasenack> vorlon: I have a fix for apache's cacti armhf failure, btw
<ahasenack> https://bugs.launchpad.net/cacti/+bug/1865067
<ubot5> Ubuntu bug 1865067 in cacti (Ubuntu) "DEP8 error on armhf (32bits): long2ip() requires int" [Undecided,In progress]
-queuebot:#ubuntu-release- Packageset: Added libxcrypt to i386-whitelist in focal
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1055.58]
-queuebot:#ubuntu-release- Unapproved: sip4 (xenial-proposed/universe) [4.17+dfsg-1build1 => 4.17+dfsg-1ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1074.79] (kernel)
-queuebot:#ubuntu-release- New binary: rustc [s390x] (focal-proposed/universe) [1.41.0+dfsg1+llvm-0ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: rustc [i386] (focal-proposed/universe) [1.41.0+dfsg1+llvm-0ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: rustc [ppc64el] (focal-proposed/universe) [1.41.0+dfsg1+llvm-0ubuntu1] (i386-whitelist)
<vorlon> Trevinho: W: libfprint-2-tod-1: package-name-doesnt-match-sonames libfprint-2-tod1
<vorlon> Trevinho: is there a good reason to not follow the standard convention?
-queuebot:#ubuntu-release- New binary: uwsgi [s390x] (focal-proposed/universe) [2.0.18-5ubuntu7] (no packageset)
-queuebot:#ubuntu-release- New binary: uwsgi [ppc64el] (focal-proposed/universe) [2.0.18-5ubuntu7] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1074.79]
-queuebot:#ubuntu-release- New binary: uwsgi [amd64] (focal-proposed/universe) [2.0.18-5ubuntu7] (no packageset)
-queuebot:#ubuntu-release- New binary: uwsgi [armhf] (focal-proposed/universe) [2.0.18-5ubuntu7] (no packageset)
-queuebot:#ubuntu-release- New binary: uwsgi [arm64] (focal-proposed/universe) [2.0.18-5ubuntu7] (no packageset)
<vorlon> Test-Command: tox -e py37
<vorlon> >_<
#ubuntu-release 2020-03-03
<vorlon> Laney: so is there some kind of new flood protection in place on autopkgtest? I'm getting 403s on the site
<vorlon> (intermittently, over the past week)
-queuebot:#ubuntu-release- New binary: rustc [amd64] (focal-proposed/universe) [1.41.0+dfsg1+llvm-0ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: rustc [armhf] (focal-proposed/universe) [1.41.0+dfsg1+llvm-0ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: rustc [arm64] (focal-proposed/universe) [1.41.0+dfsg1+llvm-0ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New: accepted rustc [amd64] (focal-proposed) [1.41.0+dfsg1+llvm-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [armhf] (focal-proposed) [1.41.0+dfsg1+llvm-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [ppc64el] (focal-proposed) [1.41.0+dfsg1+llvm-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted uwsgi [amd64] (focal-proposed) [2.0.18-5ubuntu7]
-queuebot:#ubuntu-release- New: accepted uwsgi [armhf] (focal-proposed) [2.0.18-5ubuntu7]
-queuebot:#ubuntu-release- New: accepted uwsgi [s390x] (focal-proposed) [2.0.18-5ubuntu7]
-queuebot:#ubuntu-release- New: accepted rustc [arm64] (focal-proposed) [1.41.0+dfsg1+llvm-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [s390x] (focal-proposed) [1.41.0+dfsg1+llvm-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted uwsgi [ppc64el] (focal-proposed) [2.0.18-5ubuntu7]
-queuebot:#ubuntu-release- New: accepted rustc [i386] (focal-proposed) [1.41.0+dfsg1+llvm-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted uwsgi [arm64] (focal-proposed) [2.0.18-5ubuntu7]
<vorlon> Laney: hmm do you know how network-manager 1.22.8-1ubuntu1 got into the release pocket without ever triggering netplan.io autopkgtests?
<Laney> vorlon: Yeah, last week it was being made unresponsive by web crawlers / attackers(?) hitting each page so I enabled mod_evasive or whatever the name is
<Trevinho> vorlon: mh, well was to follow librprint naming I think, but ok to change
<Laney> and that fixed the problem, but perhaps it affects people making lots of legitimate requests in rapid sequence
<Laney> I'll look at network-manager quickly
-queuebot:#ubuntu-release- New: rejected libfprint [amd64] (focal-proposed) [1:1.90.1+tod1-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected libfprint [armhf] (focal-proposed) [1:1.90.1+tod1-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected libfprint [s390x] (focal-proposed) [1:1.90.1+tod1-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected libfprint [arm64] (focal-proposed) [1:1.90.1+tod1-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected libfprint [ppc64el] (focal-proposed) [1:1.90.1+tod1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: network-manager (bionic-proposed/main) [1.10.6-2ubuntu1.3 => 1.10.6-2ubuntu1.4] (kubuntu, ubuntu-desktop)
<xnox> bryce: facter has  usr/lib/x86_64-linux-gnu/ruby/vendor_ruby/2.5.0/libfacter.so
<xnox> despite not having any ruby2.5 deps, i guess you need to rebuild facter against ruby2.7
<xnox> not sure how you will be able to ensure it doesn't migrate pre-maturely =/
<Laney> vorlon: netplan.io has no Testsuite-Triggers in its .dsc
<Laney> That can happen if you use an old dpkg-source to build the source package
<RikMills> could an AA please action the removal in LP: #1757647
<ubot5> Launchpad bug 1757647 in gle-graphics (Ubuntu) "RM: Please port your package away from Qt 4" [Undecided,Triaged] https://launchpad.net/bugs/1757647
-queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (bionic-proposed) [1.10.6-2ubuntu1.4]
-queuebot:#ubuntu-release- New binary: libfprint [s390x] (focal-proposed/main) [1:1.90.1+tod1-0ubuntu2] (desktop-core)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (eoan-proposed/main) [5.3.0-1015.16] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (eoan-proposed/main) [5.3.0-1011.12] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (eoan-proposed/main) [5.3.0-1014.15] (core, kernel)
-queuebot:#ubuntu-release- New binary: libfprint [ppc64el] (focal-proposed/main) [1:1.90.1+tod1-0ubuntu2] (desktop-core)
-queuebot:#ubuntu-release- New binary: libfprint [amd64] (focal-proposed/main) [1:1.90.1+tod1-0ubuntu2] (desktop-core)
-queuebot:#ubuntu-release- New binary: libfprint [armhf] (focal-proposed/main) [1:1.90.1+tod1-0ubuntu2] (desktop-core)
-queuebot:#ubuntu-release- New binary: libfprint [arm64] (focal-proposed/main) [1:1.90.1+tod1-0ubuntu2] (desktop-core)
<seb128> Laney, vorlon, sorry, that was my fault, I did a new upload to restore the Testsuite-Triggers now
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-440 [amd64] (eoan-proposed/multiverse) [440.59-0ubuntu0.19.10.2] (no packageset)
<xnox> seb128:  you can use sbuild to build source packages from the target release chroot, rather than on your host. There are things like that, which matter to have target series build-deps to run the clean stage and/or generate a matching source package for a given target release series.
<seb128> xnox, right, I don't remember what I did there, probably picked the wrong env
-queuebot:#ubuntu-release- New: accepted libfprint [amd64] (focal-proposed) [1:1.90.1+tod1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libfprint [armhf] (focal-proposed) [1:1.90.1+tod1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libfprint [s390x] (focal-proposed) [1:1.90.1+tod1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libfprint [arm64] (focal-proposed) [1:1.90.1+tod1-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libfprint [ppc64el] (focal-proposed) [1:1.90.1+tod1-0ubuntu2]
<Laney> cpaelzer: Did you try retrying?
<Laney> context: 03/03 13:37:22 <cpaelzer> Laney: Do you know what could have happened or who I could ask what is going on here https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/c/ctioga2/20200303_131512_05a90@/log.gz ?
<cpaelzer> Laney: I hit retry, but it is too soon - I have no retry result yet
<cpaelzer> started maybe 5 minutes ago
<cpaelzer> the test is no more in http://autopkgtest.ubuntu.com/running so its result should show up in a bit
<cpaelzer> Laney: ok it was a one time issue
<cpaelzer> on retry it worked
<doko> o/
<Laney> interesting
<Laney> wonder what happened, maybe some transient failure in the cloud
<Laney> ideally we wouldn't have marked that as a real failure
<doko> ubuntu-archive: o/
<seb128> doko, hey
<RAOF> Hey, yo!
<doko> ubuntu-archive: for sil2100 ...
<sil2100> doko: works!
<sil2100> ubuntu-archive: something something
<RAOF> ubuntu-archive: Mumble mumble grumble ping.
<stgraber> working
<bdmurray> Is somebody announcing this alias?
<cjwatson> Worked for me
* cjwatson changed the topic of #ubuntu-release to: Released: Bionic 18.04.4, Eoan 19.10 | Archive: Open | Highlight ubuntu-archive for archive admin help | Focal Release Coordination | We accept payment in cash, cheque or gin | melius malum quod cognoscis
<cjwatson> Like that maybe?
<bdmurray> sure
<mwhudson> ooo
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (eoan-proposed) [2.620.1]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.41]
<tseliot> sil2100, hey, can you approve nvidia-graphics-drivers-440, please? They ended up in NEW, so they're not in eoan-proposed yet
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-440 [amd64] (eoan-proposed) [440.59-0ubuntu0.19.10.2]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-440 [i386] (eoan-proposed) [440.59-0ubuntu0.19.10.2]
<ginggs> ubuntu-archive: ^
<ginggs> ah, i was too slow
<tseliot> sil2100, thanks
<rbasak> FFe request in bug 1865518 please, just because it's a little late. I hope that the lack of being more than a few days late means that the bar is still low.
<ubot5> bug 1865518 in inspircd (Ubuntu) "[FFe] Update to inspircd 3.4.0-2 from Debian" [Undecided,New] https://launchpad.net/bugs/1865518
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (eoan-proposed) [5.3.0-1015.16]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (eoan-proposed) [5.3.0-1011.12]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (eoan-proposed) [5.3.0-1014.15]
<teward> FFE request on #1865902 please.  This is mostly bugfixes, but NGINX Upstream made a change to only allow a single Host request header which is the only 'change' that needs to be FFe'd otherwise this would be a bugfix only microrelease. (We're still tracking Mainline ahead of NGINX Stable release in April, like we did last LTS cycle and the one before it.)  (It's been uploaded right now and is sitting in Proposed...
<teward> ... not sure if that means it's 'done' or not, but...)
<powersj> bug 1865902
<ubot5> bug 1865902 in nginx (Ubuntu) "[FFe] Please update NGINX to 1.17.9 (latest mainline release)" [Undecided,New] https://launchpad.net/bugs/1865902
-queuebot:#ubuntu-release- New binary: icu [amd64] (focal-proposed/main) [66.1~rc-1~ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: icu [s390x] (focal-proposed/main) [66.1~rc-1~ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: icu [ppc64el] (focal-proposed/main) [66.1~rc-1~ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: icu [i386] (focal-proposed/main) [66.1~rc-1~ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: icu [arm64] (focal-proposed/main) [66.1~rc-1~ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: icu [armhf] (focal-proposed/main) [66.1~rc-1~ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New: accepted icu [amd64] (focal-proposed) [66.1~rc-1~ubuntu1]
-queuebot:#ubuntu-release- New: accepted icu [armhf] (focal-proposed) [66.1~rc-1~ubuntu1]
-queuebot:#ubuntu-release- New: accepted icu [ppc64el] (focal-proposed) [66.1~rc-1~ubuntu1]
-queuebot:#ubuntu-release- New: accepted icu [arm64] (focal-proposed) [66.1~rc-1~ubuntu1]
-queuebot:#ubuntu-release- New: accepted icu [s390x] (focal-proposed) [66.1~rc-1~ubuntu1]
-queuebot:#ubuntu-release- New: accepted icu [i386] (focal-proposed) [66.1~rc-1~ubuntu1]
<RikMills> vorlon: could you please do this removal? LP: #1757647
<ubot5> Launchpad bug 1757647 in gle-graphics (Ubuntu) "RM: Please remove from focal" [Undecided,Triaged] https://launchpad.net/bugs/1757647
<vorlon> Laney: ok; I didn't see any communication about the fact that the server config was changed, did I overlook that?
<vorlon> seb128, Laney: missing Testsuite-Triggers> ouch ok
<vorlon> RikMills: removals processed
<RikMills> thanks!
<RikMills> only qt4 now is heimdall-flash
-queuebot:#ubuntu-release- New binary: gnome-getting-started-docs [amd64] (focal-proposed/main) [3.35.92-0ubuntu1] (personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-5.3 [amd64] (bionic-proposed/main) [5.3.0-1014.15~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.3 [amd64] (bionic-proposed/universe) [5.3.0-1014.15~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1032.33] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle-5.3 [amd64] (bionic-proposed/main) [5.3.0-1011.12~18.04.1] (no packageset)
#ubuntu-release 2020-03-04
<vorlon> doko: where's the freeze exception paperwork for https://launchpad.net/ubuntu/+source/icu/66.1~rc-1~ubuntu1 ? (cc: xnox)
<vorlon> doko: also cf the discussion on ubuntu-devel about the reasons why icu 66 is risky
<vorlon> Laney: fwiw the current mod_evasive config appears to specifically conflict with the sample recommended usage of retry-autopkgtest-regressions, which tries to push 10 requests at a time in parallel
<vorlon> rbalint: are you tracking the autopkgtest failures on kodi?
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (focal-proposed/main) [5.4.0-1004.4] (core, kernel)
-queuebot:#ubuntu-release- New: accepted gnome-getting-started-docs [amd64] (focal-proposed) [3.35.92-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (focal-proposed) [5.4.0-1004.4]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-5.3 [amd64] (bionic-proposed) [5.3.0-1014.15~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.3 [amd64] (bionic-proposed) [5.3.0-1014.15~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1032.33]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle-5.3 [amd64] (bionic-proposed) [5.3.0-1011.12~18.04.1]
<Laney> vorlon: I was chuntering on in some channel at the time, yeah, but I guess I overlooked highlighting you, sorry
<Laney> tweaking it sounds like a Top Idea
<vorlon> Laney: done, raised the parallel limit to 10
<Laney> cheers
<Laney> I suppose I could delete the entries blacklisting those web crawlers now, since they should fetch robots.txt now
<Laney> it didn't exist at the time, and I wanted to cut them off immediately, but now it's there
<Laney> (done)
<rbalint> vorlon, yes, i'm on it
<rbalint> vorlon, just file the update-excuse bug
<vorlon> rbalint: ta
<rbalint> vorlon, just filed
<cpaelzer> doko: runc/containerd are showing up in component mismatches now and have approved MIRs
<cpaelzer> doko: do you have the time on the sprint to promote them to main?
<cpaelzer> actually since any of you could do that apw seb128 didrocks ^^
<mwhudson> cpaelzer: you can ping "ubuntu-archive" now!
<cpaelzer> oh really
<cpaelzer> It is not a user/bot
<cpaelzer> mwhudson: is it just an AA agreement that they highlight on this word?
<cpaelzer> I see the channel topci was changed by cjwatson adding theinfo to highlight it
<vorlon> cpaelzer, doko: I can take this
<mwhudson> cpaelzer: yes, as of like yesterday or something
<cpaelzer> thanks vorlon
<cpaelzer> I hope I can beat my muscle-memory of highlighting the people indivicually
<vorlon> Laney, juliank: anyone analyzed why the amd64 autopkgtest queue is growing much more than the other archs?
<vorlon> (and i386 to a lesser degree)
<Laney> vorlon: lcy01 being down some compute capacity so we are at 75% of normal available workers
<vorlon> aha
<Laney> but I don't know if that would explain it fully
<vorlon> it's an explanation I accept for the moment :-)
-queuebot:#ubuntu-release- Unapproved: libvirt (eoan-proposed/main) [5.4.0-0ubuntu5 => 5.4.0-0ubuntu5.1] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: libvirt (bionic-proposed/main) [4.0.0-1ubuntu8.14 => 4.0.0-1ubuntu8.15] (ubuntu-server, virt)
<rbasak> FFe request in bug 1865518 please, just because it's a little late. I hope that the lack of being more than a few days late means that the bar is still low.
<ubot5> bug 1865518 in inspircd (Ubuntu) "[FFe] Update to inspircd 3.4.0-2 from Debian" [Undecided,New] https://launchpad.net/bugs/1865518
<LocutusOfBorg> rafaeldtinoco, kanashiro should ruby autopkgtests run with --all proposed stuff?
<rafaeldtinoco> kanashiro: ^ i think so
<rafaeldtinoco> all my builds, before uploading, were done locally with -proposed up to date
<LocutusOfBorg> yes but I mean autopkgtests
<LocutusOfBorg> vorlon, your opinion=
<kanashiro> LocutusOfBorg, yeah, we have many regressions because some packages need some deps from proposed
<rafaeldtinoco> LocutusOfBorg: yep, me too
<rafaeldtinoco> there are deps satisfied during autopkgtest run only
<LocutusOfBorg> I'm retrying only s390x and ppc64el, since queues are empty
<kanashiro> I've been building a list of packages that need to be triggered together to make them pass
<kanashiro> but if it is possible to enable deps from proposed (without specifying which deps are needed) it'd be helpful
<doko> vorlon: nodejs ftbfs with the new acorn. what would the next version for 6.2.1+ds+~0.4.0+~4.0.0+really4.0.0+~1.0.0+~5.0.1+ds+~1.7.0+ds+~0.1.1+~0.3.1+~0.2.0+~0.1.0+~0.3.0+~0.3.0-14 really being 5.3 ...?
<juliank> doko: wooooooooooooooooooooooooooooooooooooow
<doko> I mean, the acorn version ...
<xnox> ahahhahahhahhahahhahhahaa
<xnox> doko:  thank you for helping me clear my lungs with this coughing fit i just had over this version number
<Laney> :D
<Laney> that's actually real, amazing
<mdeslaur> WAAAAAAA
<oSoMoN> doko, I successfully built nodejs 12.16.1 against that version of acorn yesterday (in https://launchpad.net/~osomon/+archive/ubuntu/nodejs-mozilla/+packages)
<oSoMoN> and that version is being prepared in Debian
<mwhudson> https://metadata.ftp-master.debian.org/changelogs//main/a/acorn/acorn_6.2.1+ds+~0.4.0+~4.0.0+really4.0.0+~1.0.0+~5.0.1+ds+~1.7.0+ds+~0.1.1+~0.3.1+~0.2.0+~0.1.0+~0.3.0+~0.3.0-14_changelog
<mwhudson> i have questions
<doko> oSoMoN: is it planned to update focal to it?
<doko> there's also a 10.19.0 upstream
<oSoMoN> doko, I would like to, if it doesn't break too many rdeps
<oSoMoN> both versions are LTS releases of nodejs, but the 12 series will be supported longer
<doko> well, if you drive that ...
<oSoMoN> doko, for context I'm looking at that because nodejs is a build dep of firefox, and they recently bumped the version requirement to something > than what we currently have in the archive
<oSoMoN> (they==mozilla)
<xnox> mwhudson:  i'm going to open an RC bug report
<xnox> doko:  the next version apperantly is different "A new upstream version 7.1.1+~0.4.0+~4.0.0+~1.0.0+~5.2.0+~2.0.0+~0.1.1+~0.3.1+~0.2.0+~0.1.0+~0.3.0+~0.3.0 is available, you should consider packaging it."
<mwhudson> xnox: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940708
<ubot5> Debian bug 940708 in src:acorn "acorn: please revisit your versioning strategy before making a sid upload" [Normal,Open]
<xnox> oh
<xnox> ok
-queuebot:#ubuntu-release- Unapproved: collectd (bionic-proposed/universe) [5.7.2-2ubuntu1.1 => 5.7.2-2ubuntu1.2] (no packageset)
<vorlon> rafaeldtinoco, kanashiro: fyi I did rerun all ruby-defaults autopkgtests with all-proposed=1 yesterday, so the remaining failures appear to need further uploads to fix them
<vorlon> doko: acorn> ugh
<rafaeldtinoco> vorlon: thanks a lot!
<kanashiro> vorlon, many of them will be fixed when we rerun with the autodep8 now in proposed, and for some packages autopkgtest pulled the version from the release pocket and not from proposed
<kanashiro> I am handling those with bryce's help
<vorlon> ah
<bryce> kanashiro, vorlon I've retriggered them just now
<kanashiro> thanks bryce
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-1 => 1.3.9-1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-1 => 1.3.9-1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-1 => 1.3.9-1] (core)
#ubuntu-release 2020-03-05
<vorlon> xnox: well, https://people.canonical.com/~ubuntu-archive/transitions/html/unversioned-python-rm.html still looks wrong, only 2 packages in the "bad" set which is definitely a lie
-queuebot:#ubuntu-release- Unapproved: rejected system-config-printer [source] (eoan-proposed) [1.5.11-4ubuntu2]
<xnox> vorlon:  but is it more than 16?
<xnox> vorlon:  so i think regexp is not matching things right with like
<xnox> ", python (<< 2.8)," not being detected as "bad" potentially
<vorlon> xnox: yes, if you expose the 'good' packages, the very first package in the list, bareos, has a build-dependency on python-dev (in -proposed; no version in release)
-queuebot:#ubuntu-release- Unapproved: accepted stress-ng [source] (eoan-proposed) [0.10.07-1ubuntu4]
<vorlon> xnox: bcron is similar, but in release and not in -proposed
<vorlon> (i.e. no version in -proposed)
<sil2100> cking: hey! I'm looking at the stress-ng upload for bionic - there is a verification-failed stress-ng already in bionic-proposed
<sil2100> cking: I guess we want to revert it before we want to push the new one?
<sil2100> cking: I think the stress-ng upload in the bionic queue is based on the -proposed version, right?
<sil2100> cking: could you re-upload after sorting this out? If you think the previous bionic-proposed upload is still valid, please re-upload with -v to include the old bugs in the .changes, but I suppose it was supposed to be reverted
-queuebot:#ubuntu-release- Unapproved: rejected stress-ng [source] (bionic-proposed) [0.09.25-1ubuntu8]
<seb128> I've submitted a small improvement to the by-team proposed-migration report, if someone want to give a look/review
<seb128> https://code.launchpad.net/~seb128/ubuntu-archive-scripts/display-migrate-after/+merge/380276
<seb128> it adds the "needs to migrate after those items" information to Candidates
<mwhudson> seb128: lgtm but needs ubuntu-archive to look i guess, do you have example output?
<sil2100> The highlighting works o/
<sil2100> Yeah, would be nice to see an example output of this, if possible, to see if it looks sane
-queuebot:#ubuntu-release- Unapproved: ukui-biometric-auth (eoan-proposed/universe) [1.0.3-2 => 1.0.3-2ubuntu0.1] (ubuntukylin)
<seb128> sil2100, mwhudson, https://people.canonical.com/~seb128/report.html
<seb128> sil2100, mwhudson , look at the dee entry or for libical3 for a fake multi-after-items one
<mwhudson> seb128: i didn't know laney was not in the release pocket! :)
<seb128> :)
 * Laney caused too many regressions
<seb128> sil2100, mwhudson, appdirs is a case of candidate without migrate-after showing that this case didn't regress
<sil2100> seb128: I htink it looks good, approved
<doko> vorlon, xnox: looks like ben is unable to handle transitions where virtual packages are involved. it throws everything into the same dependency level
<vorlon> well ben's idea of dependency levels are upside-down anyway
<Laney> we should update to a non ancient ben :(
<Laney> can we get a container / chroot for a non-ancient release on snakefruit to do that in?
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1042.47] (no packageset)
<vorlon> via an RT request, probably
<doko> hmm, didn't Colin try to do that and failed to get it working? maybe retry with a focal container?
<vorlon> I don't know
<Laney> I do remember some experimentation having taken place but no details
<vorlon> chroot:bionic-transitions
<vorlon> exists
<cjwatson> Yeah, I failed to get ben to work there
<cjwatson> Feel free to try
<cjwatson> I got lost in ocaml
<cjwatson> I talked about it here at the time so it should be in IRC logs somewhere
<seb128> sil2100, thanks
<kanashiro> hi! I'd like to ask your help to solve an issue I am facing regarding the multiple ruby-defaults regressions. More than 100 of them have this: "command1             FAIL non-zero exit status 77"
<kanashiro> the latest gem2deb returns this when no test suite is declared
<kanashiro> and the latest autodep8 considers this test skippable if it returns 77
-queuebot:#ubuntu-release- Unapproved: apr-util (eoan-proposed/main) [1.6.1-4build1 => 1.6.1-4ubuntu0.1] (core)
<kanashiro> however, yesterday we triggered a bunch of test executions against the autodep8 in proposed and we still get the same failures
<kanashiro> is there a way to make sure that the autodep8 from proposed is used since it is not an actual test dependency?
<Laney> autodep8's not run from the archive
<Laney> we need to update that on the controller
<Laney> I'll do that
<kanashiro> Laney, thanks for the info and for taking action, I appreciate that :)
<Laney> kanashiro: should be done, can you try one retry?
<kanashiro> Laney, I can't, I am not a core-dev yet
<kanashiro> Laney, could you try ruby-curses?
<Laney> ok
<Laney> kanashiro: it resulted in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/r/ruby-curses/20200305_123852_4fea8@/log.gz
<LocutusOfBorg> nice kanashiro Laney thanks
<kanashiro> Laney, great, the test was skipped
-queuebot:#ubuntu-release- Unapproved: accepted procps [source] (xenial-proposed) [2:3.3.10-4ubuntu2.5]
<LocutusOfBorg> I tried to understand how to get autodep8 used
<LocutusOfBorg> so can we retry them now? without even needing the extra trigger?
<kanashiro> hey LocutusOfBorg o/ I've seen you triggered some reruns, thanks for your work
<kanashiro> LocutusOfBorg, yes, I have a list of packages that should be fixed with the new autodep8, just a sec
<kanashiro> LocutusOfBorg, https://paste.ubuntu.com/p/pdhSgsYVSh/
-queuebot:#ubuntu-release- New source: hud (focal-proposed/primary) [14.10+17.10.20170619-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted ukui-biometric-auth [source] (eoan-proposed) [1.0.3-2ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (eoan-proposed) [5.4.0-0ubuntu5.1]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (bionic-proposed) [4.0.0-1ubuntu8.15]
-queuebot:#ubuntu-release- New binary: linux-signed-azure-5.3 [amd64] (bionic-proposed/main) [5.3.0-1015.16~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (focal-proposed/main) [5.4.0-1004.4] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: libvirt (xenial-proposed/main) [1.3.1-1ubuntu10.29 => 1.3.1-1ubuntu10.30] (ubuntu-server, virt)
<seb128> sil2100, another easy on to review, https://code.launchpad.net/~seb128/ubuntu-archive-scripts/report-include-timezone/+merge/380301
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [5.0.0-1033.34] (kernel)
<siqueira> Hi, Does anyone knows if Gnome3 session with Wayland will be set as a default on Ubuntu LTS 20.04 (FocalFossa)?
<bryce> php-mailparse has a version string "3.0.4+2.1.7~dev20160128.orig"
<bryce> so the tarball is named php-mailparse_3.0.4+2.1.7~dev20160128.orig.orig.tar.xz
<bryce> when I upload a no-change rebuild of this package, I get an error back from Ubuntu Installer <archive@ubuntu.com>:
<bryce> Rejected:
<bryce> Unable to find php-mailparse_3.0.4+2.1.7~dev20160128.orig-1build1.debian.tar.xz in upload or distribution.
<bryce> php-mailparse_3.0.4+2.1.7~dev20160128.orig-1build1.dsc: must have only an orig.tar.*, a debian.tar.*, and
<bryce> optionally orig-*.tar.*
<bryce> Files specified in DSC are broken or missing, skipping package unpack verification.
<bryce> I'm guessing the '.orig' in the upstream tarball is the cause of the problem here, yes?
<cjwatson> Adventures in corner cases
<cjwatson> It seems like a good theory ...
<bryce> so I'm wondering if there is an established workaround for this type of corner case?
<cjwatson> I've never heard of this before
<bryce> ah fun
<cjwatson> If it is as you suggest then I think the workaround would be to use a less daft version
<bryce> it sync'd in from Debian ok
<cjwatson> But I haven't actually checked
<cjwatson> I can't see anything in LP that specifically looks for .orig
<cjwatson> Do you have the .changes file handy?
<bryce> yeah
<bryce> https://paste.ubuntu.com/p/2jtzpVssV2/
<bryce> I wonder if something is detecting the .orig as indicating this is a source archive upload
<cjwatson> bryce: Well, LP is right, you don't have a debian.tar.xz there.  I expect ... yes, that
<cjwatson> Probably dpkg-genchanges
<cjwatson> You could work around it by manually editing the .changes or by finding the dpkg bug and fixing that locally ...
<cjwatson>         foreach my $f (grep { m/\.orig(-.+)?\.tar\.$ext$/ } $checksums->get_files()) {
<cjwatson> Maybe that
<bryce> cjwatson, ok thanks I'll try that.  Never edited the .changes before... adventures indeed
<cjwatson> So basically it thinks that the file is one of the extra orig component things (.orig-foo.tar.xz) and removed it
<bryce> cjwatson, ahh that regex looks like what I was thinking must exist
<cjwatson> Building with -sa would also work around it, more easily
<cjwatson> You'd just redundantly upload the .orig.tar.xz, but that's OK
<bryce> ok I'll try that first
<bryce> no go, same error returned; trying .changes editing next
<bryce> no go on the .changes editing either (https://paste.ubuntu.com/p/gHNfknNqkr/).
<locutus__> kanashiro, I syncd rails to make the ruby transition move a little bit
<locutus__> but autopkgtests are sad
<locutus__> and I also dropped that bootsnap hack
<locutus__> not sure if still needed or not
<locutus__> please have a look
<locutus__> (I remember it was making some armhf autopkgtests sad against rails)
<locutus__> http://launchpadlibrarian.net/417386218/rails_2%3A5.2.2+dfsg-6_2%3A5.2.2+dfsg-6ubuntu1.diff.gz
<kanashiro> locutus__, taking a look now
-queuebot:#ubuntu-release- New sync: ruby-factory-bot-rails (focal-proposed/primary) [5.1.1-2]
-queuebot:#ubuntu-release- New sync: morris (focal-proposed/primary) [0.2-6]
<kanashiro> locutus__, I think I have a patch to fix it, I should come up with a bug report + patch soon
<kanashiro> locutus__, could you review/sponsor this patch? https://bugs.launchpad.net/ubuntu/+source/ruby-bootsnap/+bug/1866223
<ubot5> Ubuntu bug 1866223 in ruby-bootsnap (Ubuntu) "Missing Ruby 2.7 support" [Undecided,New]
<kanashiro> it fixed rails autopkgtest regression for me locally
<locutus__> sure
<locutus__> kanashiro, please upload them into a ppa, so I can sponsor from there
<kanashiro> locutus__, ack
<kanashiro> locutus__, it is building it in different architectures but here is the link: https://launchpad.net/~lucaskanashiro/+archive/ubuntu/focal-ruby-bootsnap-ruby27-support/+packages
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (focal-proposed) [5.4.0-1004.4]
<cjwatson> bryce: Ah, it trips a similar regex in LP, I see.
<cjwatson> bryce: dak doesn't hit this because it has a slightly stricter regex (orig_source_ext_re in daklib.regexes)
<cjwatson> bryce: Using a less silly version is probably the only possible workaround for now.  You can certainly file a bug against LP for the set of rejections you got after working around the dpkg bug, although it will certainly be Priority: low :-)
<bryce> cjwatson, ok thanks, that clarifies that then.  :-)  Yes, I figured best path is to redo the tarball.
#ubuntu-release 2020-03-06
<vorlon> Eickmeyer: you'll need to pick up the changes from ubuntustudio-default-settings 0.74ubuntu1 that was uploaded by doko
<LocutusOfBorg> kanashiro, hello, thanks for the ppa upload, but I was meaning "from the next one" :) I don't care about binaries, because copying them from ppa is forbidden, I care about sources and diffs :D
<LocutusOfBorg> and also, it might be even easier for you to upload it instead of opening a bug each time
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (focal-proposed) [1.3.9-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (focal-proposed) [1.3.9-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (focal-proposed) [1.3.9-1]
<doko> bryce: is it still planned to remove php7.3 in focal? in this case I'm suggestion to just ignore the failed autopkg tests triggered by php7.3, which are also run by php7.4
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.57 => 2.408.58] (desktop-core)
<vorlon> doko: fwiw I pinged bryce in another channel about this as well, and I've set the skiptest hint now, as there should be plenty of time for him to object today before the icu transition is actually going to go through
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (eoan-proposed) [1.9+19.10ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.58]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (bionic-proposed) [1.9+18.04ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (xenial-proposed) [1.9+16.04ubuntu1]
<kanashiro> locutus_, ack :)
<ahasenack> hi release team, bind9 and bind9-libs are stuck because of the kernel (https://launchpad.net/bugs/1865025), via debian-installer. Is this something we could migrate manually, since debian-installer isn't used in a live system, or is that worse?
<ubot5> Ubuntu bug 1865025 in Kernel SRU Workflow regression-testing "focal/linux: 5.4.0-17.21 -proposed tracker" [Medium,In progress]
<vorlon> ahasenack: well it would break buildability of the classic server ISOs, and I expect it would break netboot images as well
<ahasenack> ok :(
<ahasenack> I'm just anxious that these big bind9 changes haven't seen "real world" use yet
<cpaelzer> hiho, I know someone has done it in the past for openstack test cases but I forgot the buzzwords to search for. I'm looking for how to mark a test as huge.
<ahasenack> I know, I know!
<cpaelzer> tel lme please
<cpaelzer> as I have debugged a case in our proposed migration down to a OOM
<ahasenack> I have to check my swap file, just a moment
 * cpaelzer is eagerly waiting for ahasenack to come back with his notes
<ahasenack> have to do some sleuthing, it all started with a hint branch
<cpaelzer> ok that seems to be the natural place
<ahasenack> cpaelzer: https://code.launchpad.net/~ahasenack/britney/hint-mysql8-arm64/+merge/379582
<ahasenack> cpaelzer: check steve's response, and mine
<ahasenack> cpaelzer: oh, and https://code.launchpad.net/~ahasenack/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/379592 for a direct route
<cpaelzer> yeah and I see nova in the list as I remembered :-)
<cpaelzer> thanks a lot ahasenack
<cpaelzer> that is for python-cffi which is blocking python3-defaults so I guess people will be happy
<cpaelzer> there will soon be an MP and more details in my proposed migration status mail ...
<cpaelzer> ahasenack: look at the dir I already found this repo ~/work/britney/autopkgtest-cloud :-)
<cpaelzer> makes sense
<ahasenack> we organize our directories per the solution, not the problem :)
<ahasenack> oh, this autopkgtest-cloud should have been in the "what I learned" column of our retrospective
<cpaelzer> ahasenack: yeah
<cpaelzer> especially since over the last two years I now learned it thrice I think
<cpaelzer> ahasenack: here is it https://code.launchpad.net/~paelzer/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/380362
<cpaelzer> actually vorlon if you are still around you might want to look at this MP ^^
<cpaelzer> I saw you re-ran python-cffi tests as well
<vorlon> cpaelzer: so the tests are running out of memory?
<vorlon> cpaelzer: merged and deployed; feel free to retry the tests now
<Mirv> I have a vague memory that getting MIR approved source package's binary package to main did not involve formal process and I could ask here?
<Mirv> Could I get libenchant-2-voikko into main? I've added it to language-selector at https://launchpad.net/ubuntu/+source/language-selector/0.201 but it's not getting installed by default presumably due to it being still in universe.
<Mirv> (yes, found at 1859601 that binaries don't generally have to go through MIR process)
<Mirv> didrocks: ^ maybe you can help with that if you happen to be around, or then I'll just wait and ping someone next week
<vorlon> Mirv: it isn't showing up as a mismatch on https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed
<Mirv> vorlon: right, that's another topic - if it's only language selector that is pulling it in, it's not showing as package dependency problem
<vorlon> Mirv: is there a seed that things referenced by language-selector are normally added to?
<vorlon> libenchant-voikko is in the supported seed
<vorlon> so I guess it needs adding there?
<Mirv> right, seeds, those I had forgotten about. correct, then. I see if I can do a MR.
<vorlon> and should libenchant-voikko be dropped, in favor of libenchant-2-voikko?  is this a swap?
<Mirv> the transition isn't 100% complete, enchant 1 is still in default installation, so maybe not for 20.04 yet
<vorlon> Mirv: so in what cases is language-selector installing -2- instead of libenchant-voikko?
<Mirv> I'm trying to update myself on this topic.. it seems my installation was outdated. It seems default installation no longer installs enchant 1, but eg abiword does want it. Enchant 1 is in main, but maybe nothing in main depends on it anymore.. but this goes a bit out of voikko topic.
<Mirv> vorlon: It's currently trying to install plugins for both enchant 2 and enchant 1. I think it'd be alright if enchant 1 would not be automatically installed during installation, but suggested after installation by Language Support when universe repo is enabled.
<Mirv> (in the case Enchant 1 would be demoted to universe)
<Mirv> That would mean I could both add -2- to seeds and remove the version 1 from there, as the latter is a useful package but not required in default installation.
 * vorlon nods
<Mirv> ok done the change add https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?id=6901c478d792124c2fe3cf2289daac94ec245644 - please review, I feel shaky at using my superpowers which I don't do daily these days
<vorlon> Mirv: lgtm
-queuebot:#ubuntu-release- Unapproved: accepted crash [source] (bionic-proposed) [7.2.8-1ubuntu0.18.04.1]
<Eickmeyer> vorlon, doko: Ok, then please reject 0.76 hanging around in proposed.
<Eickmeyer> doko: To answer your question, I was unaware you did anything because we do everything using git, and there were no changes there.
<cpaelzer> thanks vorlon, I re-scheduled the tests that formerly failed
<cpaelzer> will check somewhen later if they succeed now as intended
<Eickmeyer> vorlon: nm, I guess it'll just supercede anyhow.
<wxl> there's some weird stuff going on with our lubuntu daily. should i just assume this is some sort of blip and restart? https://launchpadlibrarian.net/468001105/buildlog_ubuntu_focal_amd64_lubuntu_BUILDING.txt.gz similar issue in budgie btw https://launchpadlibrarian.net/467987391/buildlog_ubuntu_focal_amd64_ubuntu-budgie_BUILDING.txt.gz
<RikMills> some kubuntu 20.04 users have reported the same error. looks like the last plymouth upload
<wxl> on upgrade?
<RikMills> yes, they pasted this error https://paste.ubuntu.com/p/wDSsdSh2YQ/
<RikMills> I'm going to update a VM to see shortly
<wxl> looks like that file was added here https://launchpadlibrarian.net/467954305/plymouth_0.9.4git20200109-0ubuntu3.3_0.9.4git20200109-0ubuntu5.diff.gz
<RikMills> wxl: I get this: https://i.imgur.com/hK2eEFX.png
<wxl> looks similar
<RikMills> looks like seb128 has already logged off IRC for the day
<wxl> that file most definitely does not exist
<RikMills> I guess it wouldn't, as a flavour would not have the ubuntu log plymouth theme installed
<RikMills> *log
<RikMills> *logo
<RikMills> ffs
 * RikMills blames new keyboard....
<wxl> no, i mean that image does not exist in the package
<wxl> so we added a reference in rules to install a file that doesn't exist
<wxl> that change should really be reverted until someone can actually add the right image XD
<franksmcb> RikMills we are seeing that plymouth error in Ubuntu MATE
<RikMills> there is a /usr/share/plymouth/themes/spinner/watermark.png installed by the plymouth deb
<franksmcb> https://bugs.launchpad.net/ubuntu-mate/+bug/1866377
<ubot5> Ubuntu bug 1866377 in Ubuntu MATE "update-initramfs fails on plymouth hook" [Undecided,New]
<wxl> that's the problem file RikMills
<RikMills> wxl: I think it is more that the target dir of the copy command does not exist?
<wxl> it's the file itself
<RikMills> no
<wxl> ??
<RikMills> wxl: cp /usr/share/plymouth/ubuntu-logo.png "${DESTDIR}/usr/share/plymouth/themes/spinner/watermark.png"
<RikMills> ubuntu-logo.png exists
<RikMills> if ${DESTDIR}/usr/share/plymouth/themes/spinner/ does not exist, you would get the error in the upgrade
<wxl> oh derp i didn't read that right
<wxl> you're right RikMills it's the target dir
<cpaelzer> vorlon: python-cffi now passed on all arches - no more blocking itself and python3-defaults
<cpaelzer> just FYI, thank for merging the big_packages MP
<tumbleweed> cpaelzer: how did you get it passing?
<ginggs> tumbleweed: https://git.launchpad.net/autopkgtest-cloud/commit/?id=c47f5e879fa836425d950053b6bf128598591527
<tumbleweed> aha, thanks
<tumbleweed> I *knew* it had to be something infra...
<tumbleweed> not sure what test is that huge, though
<Eickmeyer> RikMills, wxl: Same with Ubuntu Studio. ISO FTB.
<kanashiro> hi, chef and some related packages were removed from Debian testing as per maintainer request: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952792
<ubot5> Debian bug 952792 in release.debian.org "RM: chef/13.8.7-6" [Normal,Open]
<kanashiro> we also have some issues with chef and ruby 2.7
<kanashiro> should we follow Debian and remove them as well?
<tumbleweed> yes
<bryce> doko yep removing 7.3 is the plan, and do feel free to skip anything as needed to resolve icu, I suspect getting that transition completed is a much higher priority.
<doko> bryce: it would be nice if yould look the php-horde-* test failures triggered by php7.4
<ahasenack> "yould" "you could"? :)
<kanashiro> I just talked one of the chef maintainers in Debian and he said that he will try to fix it this weekend, let's wait until Monday and if he has those packages fixed I'll request a FFe
<doko> late here ... sprint finished ;p
<bryce> doko, yep it's on our list, cpaelzer had looked at them a couple days ago
<bryce> for some reason those didn't show up on the ben-generated report, nor in the excuses page but I remembered they were problems with php7.2->7.3
<doko> Unpacking libc6:amd64 (2.31-0ubuntu1) over (2.30-0ubuntu3) ...
<doko> Setting up libc6:amd64 (2.31-0ubuntu1) ...
<doko> /usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory
<doko> dpkg: error processing package libc6:amd64 (--configure):
<doko>  installed libc6:amd64 package post-installation script subprocess returned error exit status 127
<doko> Errors were encountered while processing:
<doko>  libc6:amd64
<doko> E: Sub-process /usr/bin/dpkg returned an error code (1)
<doko> vorlon: so every autopkg test fails now, and there's nothing that pulls in libcrypt1
<doko> I assume we can cancel almost all running autopkg tests
<juliank> doko: sounds like libc6 must predepend on libcrypt1
<juliank> or depends, i'm not sure
<doko> I uploaded perl to pick up that dependency, but getting all those tests passing quicky doesn't seem to be possible, so I'm uploading base-files to depend on libcrypt1, planning to copy that to the release pocket
<doko> juliank: it has the dependency, but almost all autopkg tests are picking up the glibc from the release pocket
<juliank> doko: I don't understand, glibc in release pocket ships libcrypto1, so that should be fine; and if libc6 from proposed depends on libcrypto1 it should be fine too
<doko> hmm
<doko> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/3/389-ds-base/20200306_162651_f9385@/log.gz
<doko> it unpacks libcrypt1 before updating libc6
<juliank> doko: right, but it might need running ldconfig between those steps to make it pick it up in the ld.so cache
<doko> just wondering why that wasn't see in unstabÃ¶e
<doko> seen even
<juliank> doko: so libcrypt1 needs to be configured before libc6, aka libc6 needs to pre-depend on libcrypto1 (or run ldconfig in its preinst)
<juliank> running ldconfig in the preinst should be easier
<juliank> it at least avoids a pre-depends at the bottom layer of the dependency tree
<juliank> doko: oh but it is configured
<juliank> doko: oh, but the ldconfig call is done by triggers, it probably has not been executed at that point?
<juliank> anyway, seems a bit odd
<doko> yep, but why doesn't it fail in unstable? I was looking for some version tests which I didn't update, but can't find anything
<juliank> i don't really know
<doko> something to investigate before the release ...
<juliank> doko: I played around locally, upgrading libc6 (which instlaled libcrypt1), and it configured fine
<juliank> so ... confused
<doko> libxcrypt should never have migrated to the release pocket with the wrong breaks/replaces, but it was a debian sync :-/
<doko> juliank: so calling ldconfig in the preinst unconditionally sounds like an appropriate fix, when updating to the current version. but not now. I'll look at that tomorrow again
<juliank> doko: not unconditionally, but on first upgrade to version depending on libcrypt1 should be ok
<juliank> But maybe you meant that
<doko> yep, that's what I mean
<juliank> Ok
<juliank> It's late
<doko> the pre-depends wouldn't work with the current breaks/replaces in libcrypt1
<doko> juliank: https://launchpad.net/~doko/+archive/ubuntu/toolchain/+sourcepub/11045520/+listing-archive-extra  now building, will check tomorrow
<xnox> doko:  and do just execute the ldconfig with LDCONFIG_NOTRIGGER=1 environment variable to actually force the ldconfig to happen.
#ubuntu-release 2020-03-07
-queuebot:#ubuntu-release- New binary: ubuntustudio-look [amd64] (focal-proposed/universe) [0.68] (ubuntustudio)
<doko> xnox: ta. now uploaded
<doko> now perl-base has a pre-depends on libc6 (>= 2.29), libcrypt1 (>= 1:4.1.0).
<doko> give back all autopkg tests with an extra trigger on that perl version?
<RikMills> could someone please retry? https://autopkgtest.ubuntu.com/request.cgi?release=focal&arch=amd64&package=systemd&trigger=plymouth%2F0.9.4git20200109-0ubuntu7
<RikMills> see if we can get fixed plymouth through to unbreak flavour upgrades and ISO builds"
<RikMills> ^^ someone did. thanks
<Eickmeyer[m]> Looks like we've got some issues with glibc and libcrypt1? It's causing ubuntustudio-look to fail to migrate.
<tumbleweed> Eickmeyer[m]: it's in NEW
<tumbleweed> https://launchpad.net/ubuntu/focal/+queue
<Eickmeyer[m]> tumbleweed: Yeah, I feel like a dummy. Just needs a rubber stamp; all I did was introduce wallpapers. I've got more coming, but they'll go into existing packages.
<tumbleweed> :)
#ubuntu-release 2020-03-08
<RikMills> https://launchpadlibrarian.net/468188742/buildlog_ubuntu_focal_amd64_kubuntu_BUILDING.txt.gz
<RikMills> I: Extracting libcrypt1...
<RikMills> E: Tried to extract package, but file already exists. Exit...
<RikMills> ditto for ubuntu-mate and xubuntu livefs recently
<RikMills> in release libcrypt1 Breaks libc6 (<< 2.31), but glibc in release is still 2.30!
<RikMills> that is screwed up :/
-queuebot:#ubuntu-release- New sync: kipi-plugins (focal-proposed/primary) [4:19.12.3-1]
<OldManWinter> Indeed, and it's throwing dose3 on my personal repo all out of whack. :P
<juliank> RikMills: that sounds right?
<RikMills> nope
<juliank> RikMills: libc6 2.30 contains libcrypt1, libc6 2.31 does not
<juliank> Hence Breaks / Replaces (<< 2.31)
<vorlon> it doesn't sound right that there should be a package in the release pocket which Depends: libc6 and Breaks: libc6 (<< 2.31) when the release pocket has libc6 2.30
<vorlon> p-m shouldn't have allowed this into the release pocket
<RikMills> juliank: the breaks is right. it being in the release pocket is not
<juliank> ah yes
<vorlon> I could demote it back to -proposed, but I don't see how it got into the release pocket in the first place so I expect it would just sneak back
<RikMills> trying: base-files libxcrypt
<RikMills> accepted: base-files libxcrypt
<RikMills> :?
<juliank> this is very confusing!
<juliank> base-files should not be in release pocket either?
<RikMills> it doesn't install
<juliank> yeah
<juliank> does britney not understand breaks correctly?
<juliank> did someone hint it badly
<juliank> it sure sounds dangerous
<RikMills> in a vm I have base-files, login and passwd held back
<juliank> on m y laptop I have base-files, libcrypt1 held back
<juliank> login and passwd it is going to upgrade
<vorlon> found no evidence of a hint
<juliank> ack
<juliank> so a bug in britney solver then
<juliank> vorlon: revert base-files and libcrypt1, demoting the versions to proposed, and add a block hint?
<vorlon> yeah probably
<vorlon> let's see
<RikMills> looks like dok was doing something weird with publishing base-files and build essential?
<vorlon> why are there packages in the release pocket that depend on libcrypt1 :P
<RikMills> I have emails about the going into focal, not focal-proposed
<RikMills> *them going
<RikMills> as if they have been repubished there
<vorlon> I don't see any manual publications to the release pocket in the lp history
<vorlon> libxcrypt, base-files, shadow, libuser, apache2 rolled back
<vorlon> and p-m disabled for the moment to make sure it doesn't start up again mid-publication
<RikMills> :)
<RikMills> btw, I think we should be good to get rid of Qt4 now. It has been removed from unstable
<vorlon> publication appears to be done, turning p-m back on
<vorlon> and I'm off to bed
<RikMills> night, and thanks!
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-5.3 [amd64] (bionic-proposed) [5.3.0-1015.16~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1042.47]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [5.0.0-1033.34]
-queuebot:#ubuntu-release- New binary: llvm-toolchain-10 [s390x] (focal-proposed/universe) [1:10.0.0~+rc3-1] (no packageset)
<doko> is this libcrypt1 breaks/replaces libc6 (<< 2.31) the reason that the package doesn't migrate?
<doko> can't retry autopkg tests, all requests are timing out
<RikMills> doko: 'the package' = libxcrypt? vorlon put a block hint on that this morning
<doko> yep, I know, but I don't understand why the breaks/replaces would affect that.
<doko> I mean, why is it blocked without the hint?
<RikMills> it wasn't blocked and did migrate, that was what broke things. it was demoted back to -proposed along with a few other things that should never have migrated
<doko> RikMills: could you retry an autopkg test to see if it times out for you?
<RikMills> any test?
<doko> yep. http://autopkgtest.ubuntu.com/running isn't updated either. so there might be more than the timing out retries
 * RikMills waits
<RikMills> not timing out so far, but retry page is not loading either
<RikMills> something is not well
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-10 [s390x] (focal-proposed) [1:10.0.0~+rc3-1]
-queuebot:#ubuntu-release- New: accepted ubuntustudio-look [amd64] (focal-proposed) [0.68]
<doko> still showing the 4413/2004 pending builds for arm64/armhf
-queuebot:#ubuntu-release- New binary: qgis [ppc64el] (focal-proposed/universe) [3.10.3+dfsg-1~exp2] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [amd64] (focal-proposed/universe) [3.10.3+dfsg-1~exp2] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [armhf] (focal-proposed/universe) [3.10.3+dfsg-1~exp2] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [s390x] (focal-proposed/universe) [3.10.3+dfsg-1~exp2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-tinyalign [amd64] (focal-proposed/universe) [0.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-tinyalign [ppc64el] (focal-proposed/universe) [0.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-tinyalign [arm64] (focal-proposed/universe) [0.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-tinyalign [s390x] (focal-proposed/universe) [0.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-tinyalign [armhf] (focal-proposed/universe) [0.2-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd-glib (eoan-proposed/main) [1.49-0ubuntu1.19.10.0 => 1.56-0ubuntu0.19.10.0] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: snapd-glib (eoan-proposed/main) [1.49-0ubuntu1.19.10.0 => 1.56-0ubuntu0.19.10.1] (desktop-core)
