#ubuntu-release 2010-05-24
<lamont> slangasek: how soon are you planning on daily builds?
<lamont> slangasek: rolling new maverick tarballs, btw
<cjwatson> installer still isn't quite ready though I'm getting close
<elmo> someone should fix the topic, just sayin
* cjwatson changed the topic of #ubuntu-release to: Maverick Meerkat Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release managers with beer | we accept payment in cash, check or car insurance ads | melior malum quod cognoscis
<lamont> so if I send you a car insurance ad, that'll count as payment?
<ScottK> lamont: remember this script you put in to make OOo not timeout on armel?  Could we have something similar to get qt4-x11 built there?
<lamont> ScottK: this early in the cycle, could we just fix the package please?
<ScottK> It's not clear what 'fix' would mean in it's current state since the dbg really takes that long to build.
<ScottK> We are promised qt4-x11 getting more modular, but it hasn't happened yet.
<lamont> something that makes sure we spit something out to stdout every 120 min or so, after verifying that the build is, in fact, progressing
<lamont> take a look at the compilers :-(
<ScottK> Sigh.
#ubuntu-release 2010-05-25
<lamont> ScottK: as in this is what I get for bending over and violating rules just to avoid rebuilding oo.o everywhere
<ScottK> lamont: OK.  I'll figure something out.
<Riddell> someone doing New queue?
<Riddell> cjwatson?
<cjwatson> yes
<cjwatson> just new-binary-debian-universe though, not anything more substantial
<cjwatson> I was clearing it out a bit in preparation for a new-source run
<cjwatson> I've filtered out everything that already had a source publishing record in the main archive (so was probably removed at some point); the rest looks OK
<Riddell> cjwatson: ok, I'm going to start on reviewing the manual bits of new queue
<cjwatson> Riddell: I'm dropping a new-source run (for Debian main anyway) into NEW now - I'll process it all straight away on the basis that it comes from Debian, but you'll see a temporary spike in the queue size
<cjwatson> 352 source packages
<Riddell> whee
#ubuntu-release 2010-05-26
<Riddell> I approved libvpx for webm video codec yesterday but I read an article this morning about it not being open source because the patent licence is only for "this implementation of VP8" anyone got an opinion? http://www.webmproject.org/license/software/
<Riddell> http://www.computerworlduk.com/community/blogs/index.cfm?entryid=2973
<ogra> cjwatson, do you think its evil to wipe the image files from the scratch dir on antimony after building the actual image (i guess there is a reason we keep them around)
<ogra> with the preinstalled images we'll build for omap the image spit out by livecd-rootfs will be around 1.5G, i dont want to waste the space permanently (we plan to bzip the image once debian-cd is done so the result is only ~500M)
<cjwatson> ogra: up to you for this one image, but please don't purge scratch stuff in general - it's often useful for debugging
<ogra> nah, not in general, but given the size constraints i dont want to have a 1.5G ext3 image around if i dont really need it
<ogra> since we'll build two images (one for omap, the other for omap4) that already piles up to 3G
 * ogra doesnt want to make elmo cry
<cjwatson> remove it if it seems most sensible, it's not worth spending time discussing it :)
<ogra> indeed
<ogra> i just wanted to know if there was a pressing reason to keep them
<ScottK> Riddell: My understanding, which may be incorrect, is that we only worry about patents that people are actively enforcing.  On that understanding, I think it's OK.
<Riddell> ScottK: yes that's what I'm thinking too
#ubuntu-release 2010-05-27
<seb128> nigelb, there?
<seb128> nigelb, where should I look for patches to reviews?
<seb128> ups
<seb128> wrong channel
<lamont> slangasek: not that you're using it, but kapok is not yours atm, use king if you have a need.
#ubuntu-release 2010-05-28
<slangasek> liveCD builds broken due to DPKG_FSYNC?
<cjwatson> heh, I hadn't actually looked at the failures yet
<cjwatson> lamont: ^- could you please unhose livecd.sh in the maverick chroots?
<lamont> slangasek: you're building lucid livecds then....  I thought you always forced the distro, no?
<cjwatson> uh
<cjwatson> certainly not intentionally building lucid
<cjwatson> and I didn't change anything in how buildlive is invokved
<cjwatson> *invoked
<cjwatson> if we're not forcing it now, we never were
<cjwatson> ah, heh, there's a DIST=lucid lying around
<cjwatson> sigh - fixing
<lamont> the DPKG_FSYNC hackery was just inside lucid chroots.
<lamont> I've changed things to default to maverick, too.
<lamont> and planning to review and land NCommander's change to actually parse options sanely
<cjwatson> fixed buildlive defaults, rerunning
<ogra> lamont, oh, do you plan to merge the ext2/3 stuff too (then i wont bother)
<lamont> ogra: that's the part I have to review. he gagged on the command line option parsing
<lamont> which I cannot blame him for
<ogra> yes, i know
<lamont> ogra: if you want to review and merge it, that'd be a win from my perspective
<ogra> i was firstly asking him to take it back but he said you were happy about it :)
<cjwatson> ah, now we have proper failures
<lamont> originally, there were no options.  then it grew
<ogra> the other code looks fine to me, i reviewed it already but didnt find time to actually do the merge
<lamont> ogra: go for it.  and then toss a ticket at me to migrate BuildLiveCD out of the chroot so that you can actually pass in the options you need...
<ogra> perfect, will do it before ending my day
<lamont> sad to say, it's more a dev thing that a me-thing, for the current hat-of-the-day
<ogra> we're still lacking debian-cd changes so there is no hurry
<ogra> (i dont expect us to make A1)
 * cjwatson wonders whether A1 will make A1
<ogra> heh
<ogra> we could hand-rool some images :)
<ogra> *roll
<cjwatson> ah good, there's an approved MIR here for argparse
<cjwatson> fixed some archive problems that were also breaking things
<ScottK> cjwatson: If I wanted to have a brief chat with the release manager, who would I talk with at this point?
<cjwatson> ScottK: that's a good question
<ScottK> cjwatson: OK.  I'd like to have such a chat.  Would you perhaps suffice?
<cjwatson> possibly - although I'm just about to end-of-week
<ScottK> It can wait until next week.  I'll try and catch you then.
#ubuntu-release 2010-05-30
 * slangasek giggles at the predicted http://q-funk.blogspot.com/2010/05/ubuntu-building-its-i386-libc6-with.html
#ubuntu-release 2011-05-23
<lamont> how quickly could we push through a lucid-updates version of debootstrap that knows about oneiric?  (the one that just got promoted added natty, and I'm 99% certain it is a fresh promotion)
<cjwatson> there's no debootstrap in lucid-updates at all - traditionally we've put that in lucid-backports
<cjwatson> I can do the latter straight away
<cjwatson> (have done it in the past ...)
<lamont> cjwatson: launchpad.net/ubuntu/+source/debootstrap begs to differ with you
<lamont> https://launchpad.net/ubuntu/+source/debootstrap/1.0.20ubuntu1.2 to be more precise
<cjwatson> uh, oh yes
<lamont> (which recently got promoted and overrode the -cat version we had...
<cjwatson> bah
<cjwatson> if by "fresh promotion" you mean January ...
<lamont> I believe that was when it was built in -proposed
<cjwatson> it was published to -updates on 2011-01-27
<lamont> because I know I verified things after building your version in -cat
<lamont> hrmpf
<cjwatson> can you file a bug?  I can do it in -proposed quickly, at least
<lamont> sure
<lamont> 786956
<cjwatson> uploaded
<cjwatson> perhaps somebody else in the SRU team could review
<bdmurray> karmic is still listed as supported at https://launchpad.net/ubuntu/karmic
<bdmurray> I realized I could just fix it so di
<cjwatson> bdmurray: er, I heard it was pending a new kernel
<cjwatson> 16:02 <skaet> Karmic Koala (9.10) final announce is pending last kernel being published.
<skaet> bdmurray, cjwatson - there was a linux-ec2 kernel that we were waiting on results from.
<skaet> it apears to have been pushed out though last week.
<skaet> possible process failure though on the SRU side.    Am double checking it now.
<bdmurray> okay, I hadn't heard about that kernel update
<GrueMaster> Has anyone noticed that the release schedule shows Alpha 2 release the same week as the platform rally?
<skaet> GrueMaster, we're changing that now
<GrueMaster> Ah, ok.
<skaet> just getting oks from various teams.
<skaet> (or at least giving them a chance to add into the discussion ;)
<skaet> https://wiki.ubuntu.com/OneiricReleaseSchedule
<skaet> has what I think its going to end up like now...
<ScottK> DIF still seems way early.
<Daviey> skaet, Why are we caring about QA'ing Karmic EC2 kernel?
<cjwatson> ScottK: it's not atypically so now, AFAICT
<ScottK> OK.
<cjwatson> hardy -> week 8, intrepid -> week 9, jaunty -> week 8, karmic -> week 9, lucid -> week 15 (flagged as "LTSDebianImportFreeze"), maverick -> week 8, natty -> week 11, oneiric proposed -> week 9
<cjwatson> so natty was a bit off pattern for a reason I'm unsure of, but otherwise ...
<ScottK> OK.  Sounds like we're good then.
#ubuntu-release 2011-05-24
<lamont> ScottK: around still?
<lamont> SRU team god: review for bug 786956 ?
<ubot4> Launchpad bug 786956 in debootstrap (Ubuntu Lucid) (and 1 other project) "debootstrap lacks oneiric support in lucid (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/786956
<ScottK> lamont: Yes.
<ScottK> lamont: I'm not in the SRU team.  Bug SpamapS.
<ScottK> He's both west of you and in the SRU team.
<lamont> ah, cool
<lamont> SpamapS: ^^
<SpamapS> lamont: accepted into -proposed
<lamont> ta
 * ScottK thinks SpamapS was just torturing you by waiting.  He accepted that 7 minutes before pitti good morning'ed on ubuntu-devel.
<micahg> ScottK: that would make it the same time...
<didrocks> hey
<didrocks> small question, I think I have a good view now on how to seed unity-2d by default (I'll probably clean up the packaging still), with the qt part (which will be untouched first)
<didrocks> I think it can be in a good shape for thursday (looking at it tomorrow and taking one extra day for unseen issues)
<didrocks> not sure if it's good to seed it before or after alpha1
<didrocks> right now, we don't have any "fallback" session anymore (gnome-panel won't be there by default)
<didrocks> so maybe worth to try to make it for first alpha?
<ScottK> Alpha 1 is always very rocky, so if you think you've got a shot at building an image with it, I'd go for it.
<didrocks> ScottK: ok, will do that then, thanks :)
<charlie-tca> I would go for it too. Without a fallback, we will get a lot of nvidia users complaining/fileing useless bugs
<cjwatson> agreed
<didrocks> ok, I'll try to seed that for Thursday
<ScottK> didrocks: qt4-x11 is needing a merge from Debian as well, so if you have additional changes you need for it it'd be nice to get the merge done at the same time (we should get someone who was in the upstream patch review at UDS to look at it so make sure we get those bits right).
<didrocks> ScottK: well, not before alpha1 I'm afraid, but post apha1, I can have a look and discuss that on #kubuntu-devel if you have no volonteer for the merge (the only change I'm seeing right now in qt4-x11 is one for qtcreator, but the DD is quite busy right now and I need to speak about the plan with the qt guys as well)
<ScottK> Yes.  Please.
<didrocks> ScottK: ok, I'm adding myself a WI for the merge post-alpha1 then
<didrocks> and of course, will make it reviewed on #kubuntu-devel
<ScottK> Sounds good.
<cjwatson> I'm getting down to minor details (at least on x86) in the live-build migration; not yet sure whether to attempt to land that for alpha-1 though
<cjwatson> the biggest remaining thing is how to handle generating manifest-desktop
<cody-somerville> cjwatson, I use a binary hook and to generate the manifest-desktop for OEM Services.
<cody-somerville> (I also use a binary hook to recompress initramfs with lzma but its been my intention to patch live-build at some point to handle it)
<cjwatson> I'm not happy with relying on binary hooks
<cjwatson> I gave my reasoning for this in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627332#25
<ubot4> Debian bug 627332 in live-build "update mlocate database?" [Wishlist,Open]
<cjwatson> cody-somerville: too slow :-)  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627677
<ubot4> Debian bug 627677 in live-build "alternative initramfs compressor" [Wishlist,Open]
<cjwatson> general bug for manifest handling: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627439
<ubot4> Debian bug 627439 in live-build "handling Ubuntu's multiple manifest scheme" [Wishlist,Open]
<slangasek> cjwatson: do you still mean to add hal to the transition tracker?
<slangasek> (maybe it's there already, I don't have a link handy to the web UI...)
<cjwatson> seb128: will do, thanks.  should be soon, I just need to take safekeeping copies of the images that weren't released with natty
<cjwatson> er, oops
<cjwatson> (accidental up-arrow)
<cjwatson> slangasek: had forgotten about it, is there a work item somewhere for it?
<cjwatson> and is it just libhal* deps we care about, or hal itself, or both?
<slangasek> cjwatson: no work item, the conversation we had was to scrap the blueprint in favor of the tracker :-)
<slangasek> cjwatson: and we care about both libhal* and hal
<cjwatson> Laney: please pull the tracker branch
<cjwatson> slangasek: ^- done once Laney does that
<Laney> banzai
<Laney> any progress on the IS hosting?
<cjwatson> lamont asked me a question about it but it went dark after that
<slangasek> cjwatson: ta
<lamont> cjwatson: lillypilly is being its own slow self
<cody-somerville> cjwatson, Its always been my intention to reduce the number of standard hooks we needed to zero for the same rationale.
<cjwatson> cody-somerville: https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-live-build, if you haven't seen it
<cjwatson> anything marked done there is either fixed in unstable or has a Debian bug
<cjwatson> (I'll make an ubuntu1 upload if I need to, though I would prefer not to)
<cjwatson> (Debian bug with a patch, that is)
<cody-somerville> cjwatson, I took a quick look yesterday but haven't had a chance to give it a proper read yet. Very excited about this. Huge kudos for your contributions.
<lamont> SpamapS: I would really like to see sysvinit from -proposed not land until that has the fix to bug 619246 in it
<ubot4> Launchpad bug 619246 in sysvinit (Ubuntu) "invoke-rc.d don't return same anwswer when the variable RUNLEVEL is setup at boot time (affects: 4) (heat: 22)" [Undecided,Confirmed] https://launchpad.net/bugs/619246
<lamont> that would be most relevant to my desires
<SpamapS> Hm
<SpamapS> lamont: its waiting on bug 665185 right now... and I believe there is another lucid sysvinit SRU that is blocked on that one
<ubot4> Launchpad bug 665185 in sysvinit (Ubuntu Maverick) (and 2 other projects) "/etc/init.d/sendsigs fails to kill some processes (affects: 1) (heat: 30)" [Low,Fix committed] https://launchpad.net/bugs/665185
<SpamapS> lamont: they're totally unrelated.. but.. I wouldn't mind letting bug 619246 into -proposed if you promised to verify 665185 too..
<ubot4> Launchpad bug 619246 in sysvinit (Ubuntu) "invoke-rc.d don't return same anwswer when the variable RUNLEVEL is setup at boot time (affects: 4) (heat: 22)" [Undecided,Confirmed] https://launchpad.net/bugs/619246
<lamont> SpamapS: I might be talked into that
<lamont> is that as simple as uploading to -proposed, or where do I get to send it for review?
<SpamapS> lamont: since 665185 is a race condition .. verification can consist of "I installed it and rebooted a couple times and my data is still on the filesystem"
<SpamapS> Yeah, you'd just upload it to -proposed.
<lamont> ta
<lamont> it'll be this weekend at the earliest
<lamont> it's just that if you stuff 17.2 into lucid-updates, you'll regress my world and make me sad
<SpamapS> I'm not sure I follow .. 17.2 causes problems, but only if you don't have the invoke-rc.d fix?
#ubuntu-release 2011-05-25
<cjwatson> skaet: FYI, /srv/cdimage.ubuntu.com/backups/natty-unreleased/ has copies of the eight current daily builds that we didn't release with 11.04
<cjwatson> (on antimony)
<cjwatson> and trying an initial round of oneiric CD builds before bed
<skaet> cjwatson,  thanks.
<cjwatson> http://cdimage.ubuntu.com/daily/current/
<cjwatson> http://cdimage.ubuntu.com/daily-live/current/
<cjwatson> several images way oversized, and absolutely no idea whether they work
<cjwatson> also not cronned yet
<stgraber> wow, they actually built the first time around?
<cjwatson> yeah
<cjwatson> I did wait until I thought they probably would
<cjwatson> I suspect amd64/efi may be busted, haven't checked yet
<skaet> very cool.    :)
<cjwatson> hah, amd64 doesn't even build, score
<skaet> when do we cut over from doing the natty daily builds?
<cjwatson> skaet: what natty daily builds?
<cjwatson> (no daily builds since we released)
<skaet> http://cdimage.ubuntu.com/daily/current/ has natty builds in it...
<skaet> d'oh
<skaet> april 26
<skaet> sorry,  my bad.
<cjwatson> yeah, those were carried over by accident, I just removed them
<skaet> :)
<cjwatson> well, not by accident, by a long-standing cdimage bug/misfeature/something
<cjwatson> anyway, bed
<skaet> sleep well.
<stgraber> good night
<cjwatson> promoting ttf-sil-nuosusil, since it's a successor of ttf-sil-yi which was previously in main
<cjwatson> Laney: http://people.canonical.com/~ubuntu-archive/transitions/
<cjwatson> merry Christmas
<Laney> happy days!
 * Laney adds IS to the Good List
<cjwatson> I think I got everything of yours sucked in
<cjwatson> had to hack it a bit for lucid
<cjwatson> wrote http://paste.ubuntu.com/612768/ as a 'go' script
<Laney> I think some of my claims in readme.txt might be lies
<cjwatson> I edited that a bit
<Laney> you can add --use-cache to the 2nd+ runs
<Laney> and you might want --run-debcheck too
<cjwatson> aha
<cjwatson> --run-debcheck for all of them?
<Laney> that's how I had it yeah, but I don't know if that's necessary
<cjwatson> http://paste.ubuntu.com/612772/
<cjwatson> oopsie, need edos-debcheck installed
<Laney> you could even put it at line 14
<cjwatson> how do you mean?
<cjwatson> oh, the cache
<cjwatson> done
<Laney> bonza
<cjwatson> Laney: --run-debcheck back in now (thanks lamont)
<Laney> brillo pads, thanks
<bdmurray> What was the Final Answer about Karmic being supported?
<skaet> bdmurray,  Karmic is EOL'd now.  In process of working through checklist and trying to get it shut down officially now.   Issue that was holding up the decision is documented in https://bugs.launchpad.net/ubuntu/+source/linux-ec2/+bug/737761
<ubot4> Launchpad bug 737761 in linux-ec2 (Ubuntu Karmic) (and 1 other project) "linux-ec2: 2.6.31-308.29 -proposed tracker (affects: 1) (heat: 14)" [Undecided,Fix committed]
<bdmurray> skaet: is there an EOL checklist?  I'd like to take a peek at it
<skaet> bdmurray,  https://wiki.ubuntu.com/EndOfLifeProcess - if you spot anything missing,  that should be done, feel free to add ;)
<bdmurray> skaet: I was just curious about meta-release since I was looking at that today
<skaet> bdmurray,  have ping'ed  mvo to edit it, and waiting on him.
<bdmurray> skaet: right, okay
<skaet> can you deactivate karmic-updates for me - I still dont seem to have permission... grumble.
<skaet> ?
<maxb> On a semi-related note, is there a planned date for shutdown of karmic PPA builds?
<skaet> maxb,  its being coordinated with the OEM folk, within the next 6 months. If I am understanding your question correctly.
<skaet> cjwatson,  can you do the honors on turning off karmic-updates milestone?  my perms still aren't letting me.
<maxb> Thanks - it's interesting to know to plan maintenance of PPAs - will a date be announced somewhere once it's decided?
<skaet> maxb,  will talk to the OEM team and see if something can be arranged.   Where would you be looking to see the announce though?
<maxb> I don't mind - anywhere I can look to see once it's been decided :-)
<maxb> IIRC, intrepid just stopped working one day, and jaunty is still enabled
<maxb> Maybe launchpad-users would be a good place to announce it
<skaet> One the EOL announce goes out,  they are effectively unsupported and can disappear at any time.    However,  will talk with OEM, and see if we should add something to the process notes to make it explicit.
<mvo> skaet: supported is set to false now
<skaet> thanks mvo.  :)
<mvo> np
<cjwatson> skaet: done
<skaet> cjwatson,  thanks!
<cjwatson> Laney: are you running the libav transition?  do you know if it typically requires sourceful changes, or if it's just a slew of rebuild-only uploads?
<cjwatson> oh, heh, /usr/share/doc/libavcodec53/APIChanges
<micahg> cjwatson: sourceful changes :(, but it's good to know about that file :)
 * cjwatson might steer clear then, not having the time for that
<cjwatson> not doing sync requests at the moment because qa.debian.org is down
<cjwatson> (bed anyway)
#ubuntu-release 2011-05-26
<Laney> cjwatson: libav> yeah, I found the same. I mostly put it up because I saw it all on nbs.html and wanted to have it visible
<Laney> we should make siretart aware :-)
<cjwatson> CD image cron jobs back on
#ubuntu-release 2011-05-27
<Laney> I need to get smarter with my bugmail filtering now ;)
<cjwatson> or use LP's new smarter bugmail muting
<Laney> is process-removals still [going to
<Laney> ] be run?
<cjwatson> yeah, anything in particular?
<Laney> some haskell stuff, nothing urgent - was just wondering if I should be filing removal bugs for them
<cjwatson> no need for removal bugs.  when were they removed from Debian?
<Laney> within the last few days
<cjwatson> I know I processed some already
<cjwatson> process-removals isn't showing anything to do for the last week's worth of Debian removals
<cjwatson> hmm, something's wrong though
<Laney> actually, they might have been done already
<Laney> yeah - sorry for noise
<cjwatson> ah, helps to be looking at the current removals.txt generation
<Laney> I was looking at one of today's. Probably a bit much to expect that to have been done already :-)
 * Laney is pleased this transition is happening mostly automatically
<cjwatson> yeah, all the recent haskell stuff is done
<cjwatson> ISTR doing a haskell removal this morning
<cjwatson> oh, but need Debian Sources files to be up to date locally
<Laney> no need to do anything urgently
<ScottK> Would someone please promote akonadi-backend-mysql, muon-installer qapt-deb-installer libphononexperimental-dev, phonon-backend-null to Main.  They're all from existing source packages in Main.
<slangasek> ScottK: done
<ScottK> slangasek: Thanks.
<cjwatson> Laney: removed haskell-gnomevfs and haskell-soegtk now
<Laney> cheers
#ubuntu-release 2011-05-28
<Laney> maybe we'll get this finished in debian over the weekend
<Laney> fingers crossed
<cjwatson> 33 left, seems doable
<Laney> even fewer in sid
<cjwatson> hmm, how come we're behind?
<cjwatson> or is that just the difference from today?
<Laney> a couple of outstanding syncs and today's uploads
<cjwatson> oh wow, http://release.debian.org/transitions/html/ghc7.html looks good
<Laney> that is broken :-(
<Laney> http://pkg-haskell.alioth.debian.org/haskell-pkg-graph.pdf is probably the best view
<cjwatson> I don't see any Haskell-related sync requests
<cjwatson> there was one retry request oddly in the archive queue, for alex
<cjwatson> I'll do an autosync run now, might as well
<cjwatson> overnight capacity and all
<Laney> outstanding> I haven't requested them
<cjwatson> ah
<Laney> hopefully almost all of the deltas should go away
<Laney> I had to introduce a lot in natty due to moving haskell-utf8-string ahead of Debian
<cjwatson> yeah
<cjwatson> there you go, have a bunch of syncs
<cjwatson> Laney: shouldn't we flag .build-depends ~ /ghc6/ as bad?
<cjwatson> (but not symmetrically for good, since the new packages have to build)
<Laney> could do, yeah
<Laney> might correctly make the apps show up as bad
<cjwatson> that was my thought
<cjwatson> I'll try it
<cjwatson> Laney: that didn't have any effect that I noticed.  Maybe it doesn't process build-depends for is_good/is_bad :-(
<cjwatson> bed
<cjwatson> Laney: https://launchpadlibrarian.net/72490176/buildlog_ubuntu-oneiric-i386.haskell-hs3_0.5.6-1_FAILEDTOBUILD.txt.gz - does missingh need to be rebuilt against current hslogger or something?
<Laney> urgh, yeah
<Laney> thought we'd avoided those this time
<ScottK> Would someone please promote libdlrestrictions1 and libdlrestrictions-dev to Main?  They come from existing source in Main and will be depends/bulid-depends for the current set of KDE uploads we are preparing.
<doko__> please file a MIR to document that
<ScottK> doko__: For promotion of a new binary from existing Main source?
<doko__> yes, it's non obvious; did do the same for other packages too
<ScottK> Sigh.
<ScottK> doko: Bug #789659
<ubot4> Launchpad bug 789659 in pkg-kde-tools (Ubuntu) "MIR libdlrestrictions1 and libdlrestrictions-dev (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/789659
#ubuntu-release 2011-05-29
<Laney> urgh, I ought to remove my old transition pages
<Laney> spent a while just now looking at ancient output
<GrueMaster> s there a reasone why the last natty daily build for preinstalled-headless-armel is being copied in with the current daily headless-preinstalled for oneiric?  http://cdimage.ubuntu.com/ubuntu-headless/daily-preinstalled/
<ogra_> GrueMaster, looks like a bug to me
<ScottK> I've filed the MIR for promotion of new binary packages from a Main source as doko requested (Bug #789659).  In the meantime kde4libs is now depwait and further work on KDE is blocked waiting for libdlrestrictions1 and libdlrestrictions-dev.  I would appreciate it if someone would promote them so the team can keep working.  If the MIR review produces issues, then I'll make sure they are addressed.
<ubot4> Launchpad bug 789659 in pkg-kde-tools (Ubuntu) "MIR libdlrestrictions1 and libdlrestrictions-dev (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/789659
<cjwatson> GrueMaster: long-standing known bug/misfeature in the cdimage code.  I'll clean up the stale images in a bit.
<ScottK> cjwatson: If you have a moment, I'd really appreciate it if you would do the promotion of libdlrestrictions1 and libdlrestrictions-dev I mentioned above?
<cjwatson> doko's been very annoyed with people doing pre-promotions in the past
<cjwatson> though I find it weird that we've started needing MIRs for binaries.  When and why did that change?
<ScottK> No idea.
<ScottK> Since it's either approve the MIR or carry a permanent significant delta from Debian in all the core KDE packages, I think I know what happens in the end.
<ScottK> If there's stuff that needs fixing in the new code, we'll work it out with Debian (this is native Debian code)
<ScottK> So I think the point of the MIR would be to identify issues that ought to be worked out, not do we promote it or not.
<cjwatson> ScottK: done, see bug comment
<ScottK> Thanks.
<ScottK> I think the comment makes complete sense.
#ubuntu-release 2012-05-21
<micahg> BTW, the rest of the tntnet binaries will be coming through shortly
<micahg> pitti: could I ask you to process the promotion requests in the ubuntu-archive queue as well please?
<micahg> multiverse -> universe ones I mean
<pitti> micahg: done
<micahg> pitti: thanks
<RAOF> Another gtk+3.0? :/
<seb128> RAOF, there was a regression in the previous one
<RAOF> Yay.
<cjwatson> precise daily CD builds should be up and running again now, though the first ones haven't run yet
<skaet> :)
 * ogra_ crosses fingers for arms
<bjf> skaet, pitti, can someone copy the Precise kernel package (3.2.0-24.38) from -proposed to -updates?
<skaet> bjf, hmm... looks like someones just taken care of it.
<pitti> bjf: done
<skaet> :)
<bjf> pitti, thanks
<pitti> (ubuntu-docs shouldn't go to -security, rejecting that)
<cjwatson> I have moved the sync-blacklist to lp:~ubuntu-archive/+junk/sync-blacklist; please stop using the old location (which I'm going to render inoperative)
 * micahg assumes that includes fixing syncpackage and/or launchpad to check the new location as well?
<cjwatson> No, because they already used http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
<cjwatson> Launchpad itself hasn't cared for some months
<cjwatson> The only clients are syncpackage and auto-sync, both client-side
<micahg> sorry, ignore me :)
<bdmurray> is this the right channel to talk about the SRU-ability of a bug for Precise?
<slangasek> probably
<infinity> Almost certainly.
<bdmurray> I want to SRU this change to Precise but I'm not excited about writing a test case
<bdmurray> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/quantal/apport/ubuntu/revision/1961
<bdmurray> honestly, I'm not sure how to get a .deb to generate that message
<slangasek> hmm, quite
<bdmurray> and this seems like an 'obviously safe patch' to me
<slangasek> obviously safe, yes, but we also want to be sure it fixes the bug
<bdmurray> ah true
<slangasek> bdmurray: how about dpkg-divert --add --local --rename --divert /usr/bin/dpkg.real /usr/bin/dpkg, and then a wrapper script that deliberately clobbers any files in /var/cache/apt/archives with bogus data?
<infinity> If you're diverting dpkg, you can just replace it with something that throws the error every time it's run...
<infinity> Mangling data seems a bit silly at that point.
<bdmurray> The foundations bug bot takes care of these after reporting and I only see 24 tagged not-debian-format so maybe its not worth it
<slangasek> maybe something like this: http://paste.ubuntu.com/999824/
<slangasek> (untested)
<slangasek> infinity: this bug is tied up with whether strings are localized or not
<slangasek> infinity: so I think it's easier to do a wrapper script than to correctly emulate dpkg behavior
<slangasek> (I'm not even sure which fd the message is output on...)
<slangasek> $ sudo dpkg -i /var/cache/apt/archives/postfix_2.9.1-5_amd64.deb
<slangasek> dpkg-deb: error: `/var/cache/apt/archives/postfix_2.9.1-5_amd64.deb' is not a debian format archive
<slangasek> dpkg: error processing /var/cache/apt/archives/postfix_2.9.1-5_amd64.deb (--install):
<slangasek>  subprocess dpkg-deb --control returned error exit status 2
<slangasek> Errors were encountered while processing:
<slangasek>  /var/cache/apt/archives/postfix_2.9.1-5_amd64.deb
<slangasek> bdmurray: ^^ tested
<jdstrand> cjwatson: fyi, I started adding comments to the end of the commands I have been running on cocoplum so that 'history' will show why I am doing things
<jdstrand> cjwatson: (referencing your eliminating shell access on cocoplum work items here)
<bdmurray> slangasek: okay, noted I'll open a bug with the test case and precise task but may wait for more bugs before causing the SRU work
<slangasek> bdmurray: sounds good
<cjwatson> jdstrand: OK, but maybe best just edit the wiki page directly if you do something not mentioned there; I'm probably not going to trawl the history again :)
<jdstrand> well, it was more about "why did he do that?" if someone was looking there. I will update the wiki as needed
<cjwatson> Laney: your update-sources problems were a MoM bug - 'def open' at the top level of a module is liable to produce abject confusion ...
<Laney> hrm, how did it ever work then?
<cjwatson> It used to use file()
<cjwatson> I changed it some time ago (since file() no longer works in Python 3), but either an older version of Python resolved local definition vs. builtin differently, or I didn't deploy that change until after MoM stopped working for other reasons
<cjwatson> Ooh, this new box has twice the disk too
<cjwatson> And a honkload of CPUs
<Laney> woot
<lamont> slangasek: what have you done!?!?
<slangasek> lamont: mm?
<jdstrand> fyi, my team has also been seeing oddities with the work items tracker
<slangasek> lamont: I have done many things... care to be more specific? :)
<lamont> slangasek: the postfix dpkg -i highlighted me, that's all.
<slangasek> oh, haha
<slangasek> lamont: I replaced dpkg with a very malicious shell script
<jdstrand> people haven't been able to delete things from 'security-q-ecryptfs' and things are reordered after save ('security-q-apparmor-dev')
<lamont> slangasek: ah, yes, I can see that now.
<jdstrand> to delete, when I went to edit, I copied all the work items somewhere (I used gnote), and then deleted everything from the work items, saved it, then added them all back minus the one I deleted
<jdstrand> s/I deleted/I wanted deleted/
<slangasek> skaet: do you know who it was that worked on the WI implementation in launchpad?
<jdstrand> I will probably be copying things somewhere else for a little while
#ubuntu-release 2012-05-22
<zul> can someone review python-jsonschema please its sitting in binary new, and its blocking glance
<cjwatson> zul: Sorry for the delay.  For main inclusion, I expect that the MIR team will want (a) a watch file and (b) for the package to run its test suite at build time (e.g. 'python -m unittest discover').  Neither of these block acceptance into the archive, though, so accepted.  Thanks
<zul> cjwatson: cool...ill get to that today, thanks
<cjwatson> zul: Hmm, why does python-jsonschema seem to install into /usr/lib/python2.7/dist-packages/ directly rather than as a symlink into /usr/share/pyshared/?  Am I hallucinating?
<zul> cjwatson: im not sure but ill take another look at it
<cjwatson> Not a big deal since there'll be no python2.8, but it's a bit weird
<pitti> cjwatson, zul: I think that's completely expected
<pitti> dh_python2 just does that now, it seems the /pyshared/ approach has been dropped
<pitti> i. e. it affects all python packages now
<pitti> not just -jsonschema
<cjwatson> Oh, huh
<cjwatson> Surprising
<pitti> NB I'm not saying that it really should be like that, just that it's not package specific, but a changed behaviour from dh_python2 apparently
<cjwatson> Yeah, I see that now
<ScottK> pitti and cjwatson: The change doko made in dh_python2 in Ubuntu is uncoordinated with Debian and gratuitously breaks packages.  It should be reverted.
<ScottK> The relevant bug is Bug 1001912
<ubot2> Launchpad bug 1001912 in python-defaults "dh_python2: revert pyshared removal in 2.7.3-0ubuntu3" [High,Confirmed] https://launchpad.net/bugs/1001912
<slangasek> ScottK: doko is currently away so you shouldn't expect a quick response from him; I think you should go ahead and revert it for now as the safer option
<ScottK> slangasek: Thanks.
<ScottK> slangasek: Would you mind saying so on ubuntu-devel ML too (so I can point to it when he gets back)?
<Laney> well, he has been replying on the bug
<slangasek> I mind saying on ubuntu-devel that he's away, yes :)
<ScottK> slangasek: Right, I mean that I should go ahead.
<ScottK> I don't mind leaving the reason out.
<highvoltage> I guess inside canonical you have some kind of free/busy calendar.
<highvoltage> it would actually be nice if there were somewhere where anyone could mark themselves as temporarily away.
<slangasek> ScottK: sure
<highvoltage> (sorry I'm just thinking out aloud)
<Daviey> cjwatson: Hey, what changes do i need to make on nusakan to start using a livefs?
 * ogra_ wonders if you actually need any code changes 
<ogra_> theoretically you might be able to just use the right cmdline
<cjwatson> Daviey: mail me the details of what you're doing and I can advise and/or sort it out
<Daviey> cjwatson: Does it really need a mail?  'make ubuntu server use live-installer'
 * ogra_ thinks theoretically teh following might just work ... : buildlive ubuntu-server daily-live && for-project ubuntu-server cron.daily-live
<ogra_> but you will likely need ubiquity adjustments or do you plan to run under X ?
<Daviey> ogra_: We've tested with d-i net installs, using live-installer udeb, not ubiquty.
<cjwatson> Daviey: please mail me :)
<cjwatson> I don't have a lot of spare brain
<cjwatson> and I need to know what if anything you've done to livecd-rootfs so far
<cjwatson> also you guys owe me two live-installer bug reports from UDS
<skaet> cjwatson, can you add me to the response.   Would like to understand this.
<cjwatson> Daviey: ^-
<Daviey> cjwatson: were they not reported.. *sigh*.. Sorry... Well, we can't switch until they are fixed.. So, i'll shelve this, pending those bugs.
<cjwatson> Daviey: have you done anything to livecd-rootfs?
<Daviey> cjwatson: nein
<cjwatson> Daviey: here, I have one of the bugs fixed locally already (missing kernel).  do you remember off the top of your head what the other one was?
<Daviey> cjwatson: One was kernel not being installed if outside the squashfs.. and the other was a debconf value for remote retrieval of squashfs
<cjwatson> oh, that one
<cjwatson> hm, not sure how to do those two simultaneously, mind :)
<cjwatson> maybe it would be easier to disable the kernel hack in server squashfs generation for now
 * cjwatson also notes that live-installer doesn't seem to update the initramfs, at least from code inspection
<Daviey> well.. if you are netinstalling, you don't have the kernel on the filesystem, do you?
<Daviey> which means they need additional retrieval, unless bundled into the quashfs (yucky)
<cjwatson> bundling it into the squashfs isn't particularly yucky
<cjwatson> it's a removal of an Ubuntu-specific optimisation *shrug*
<ogra_> all other squashfses carry it
<Daviey> well, it means for cd image, the kernel is shipped twice?
<cjwatson> Yes
<cjwatson> Not the end of the worl
<cjwatson> d
<Daviey> no.
<cjwatson> It makes some difference for space, but we got by without it for quite a while
<cjwatson> update-initramfs> Ah, never mind, it'll remove casper and then update-initramfs, now that I look at it
<Daviey> cjwatson: okay, bundling seems reasonable, and satisfies cd and netinst.
<cjwatson> I've fixed live-installer to cope with unbundling (I think) anyway
<skaet> https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule
<Daviey> oo, thanks
<skaet> has been updated, based on the interlock.
<skaet> if anyone spots any glitches,  please flag.  :)
<skaet> https://wiki.ubuntu.com/QuantalQuetzal/ReleaseInterlock
<skaet> has all the key events in it now as well.
<skaet> (getting a few more details added from Linaro though...)
<cjwatson> Daviey: and you have network image support as well, assuming I didn't screw it up.  can't easily test it until we have images.
<ScottK> Is the chroot problem on nihal known?  See https://launchpad.net/ubuntu/+source/python-defaults/2.7.3-0ubuntu4/+build/3509558
<cjwatson> I got ops to fix that, but didn't go through and retry stuff.  Oh, but that's more recent.  Not again.
<cjwatson> reported
<ScottK> Thanks.
<cjwatson> Hope those boxes get upgraded to precise/armhf soon ...
 * ogra_ hopes for highbank instead :) 
<stgraber> ogra_: you should have put that calxeda server in your bag while there weren't looking ;)
<ogra_> damned, now you tell me !
<ogra_> though i would have been to sick to carry it i guess
<ogra_> geez
<ogra_> ubuntu-server-dove/quantal/armel+dove failed to build
<ogra_> i wouldnt have thought i'd ever seee such a message again :)
<highvoltage> ogra_: awesome!!!
<ogra_> heh
<ogra_> i doubt building dove was intentional :)
<highvoltage> ogra_: that's going straight to google+!
<cjwatson> ogra_: wasn't intentional, I was experimenting but not with that; I'll fix it up in a bit
<Laney> best. process improvement. ever.
<slangasek> ?
<Laney> oh, you've ignored queuebot :P
<slangasek> ;)
<Laney> backports DIY + queuebot = fast acceptance
<slangasek> so was that sarcasm? :)
<slangasek> ah
<slangasek> the queuebot should just send to twitter
<stgraber> that's certainly easy to implement ;)
<tumbleweed> that was a very fast backport!
<Laney> still binary NEW to go!
 * Laney whips ubuntu-archive
<ScottK> Laney: That's not the proper backports versioning.
<ScottK> Should be 1.9.9-1~precise1
<Laney> it is what broder and cjwatson came up with at UDS
<ScottK> Sigh.
<ScottK> Any particular reason to change or are we just changing for changes sake?
<tumbleweed> to work around the zaney zebra wrap-around
<Daviey> I thought there was a concerted effort to try to reduce the use of codenames post release?
<cjwatson> We're about to wrap round the alphabet.
<cjwatson> FSVO "about".
<cjwatson> We need to stop assuming that codenames sort.
<ScottK> OK.
<ScottK> Backports is approximately the last place we need to assume that though.
<ScottK> err .. stop assuming that.
<cjwatson> Indeed.  But why wait? :-)
<cjwatson> It's also one of the few places that was assuming it in the first place.
<ScottK> It's certainly a change there should be some communication about.
<ScottK> OK.
<Daviey> well, i would hope that there would be a newer upstream version of software come wrap-around time for the backports usecase..
<Daviey> but yes, it's a race regardless.
<ScottK> I mind the surprise more than I mind the change.
<cjwatson> I was hoping broder would send mail about it ;-)
<Laney> hm, the process page doesn't mention versioning at all any more
 * cjwatson eyes openlp and wonders if he can get the local primary school to stop using Powerpoint for projecting hymns ...
<Laney> the modern age... back in my day we made good with OHP
<Daviey> hand written lyrics no less.
<Laney> of course
<Daviey> kids today, don't know they are born, eh Laney ?
 * Laney shares a Werthers with Daviey 
#ubuntu-release 2012-05-23
<micahg> RAOF: can you reject libxkbfile from precise-proposed?
<RAOF> Can, and have.
<micahg> thanks
 * micahg forgot a slash in the changelog :-/
<pitti> IOError: [Errno 28] No space left on device
<pitti> ^ on ddebs.ubuntu.com
<pitti> argh
<pitti> I think at this point I rather sacrifice natty than losing quantal ddebs
<infinity> Yeah, natty will EOL "soon" anyway.
<infinity> FSVO soon.
<pitti> at least it's a rather uninteresting target to still fix crashes for
<micahg> umm, what about removing the dbgsym ddebs?
<infinity> As opposed to...?
<micahg> removing natty
<infinity> All the ddebs are dbgsym ddebs, I'm a bit confused. :P
<micahg> oh, hrm, sorry :(
<micahg> for some reason I thought there were duplicates
<micahg> I meant dbg-dbgsym
<micahg> but those probably don't exist
<infinity> I think pkg-create-dbgsym tries to detect that scenario and do something clever, but I forget what now. :P
<micahg> lack of sleep catching up with me, time for a break :)
<pitti> micahg: yes, pkg-create-dbgsym doesn't generate -dbgsyms for -dbg packages
<pitti> nor for any package which doesn't have an ELF file with a debug symbol section
<infinity> pitti: You do still get duplication between -dbg.deb and -dbgsym.ddeb though, right?
<pitti> yes
<infinity> pitti: Since they share the same package namespace, couldn't we cleverly detect that situation and make -dbgsym.ddeb an empty package that depends on -dbg.deb?
<pitti> infinity: we certainly could; we even detect that and add a Conflicts: to the -dbg package
<pitti> infinity: we had a spec a while ago to get rid of all -dbg packages to reduce the size of the main archive
<pitti> but it never got implemented
<pitti> so I guess we could do it that way around
<infinity> Sounds like a lot of unnecessary delta from Debian.
<infinity> Until someone can convince them to go the ddeb route.
<infinity> (which would be nice)
<pitti> nah, not by modifying the source obviously :)
<infinity> Oh, just by silently dropping them on the floor at upload time?
<pitti> more like the pkgbinarymangler approach
<infinity> That would mean the -dbg packages better all be nothing but detached symbols.  I know, in the past, some actually contained Useful Things.
<infinity> (debug utilities, etc)
<pitti> but I guess your way around makes more sense then
<infinity> Well, the only problem with mine is that it makes apport-retrace need to be even smarter, when it's fetching old ddebs from the librarian (you know, once they're there)
<infinity> Cause it'll need to follow dependencies.
<pitti> bug 1003234
<ubot2> Launchpad bug 1003234 in pkg-create-dbgsym "Build dummy -dbgsym for packages which already have a -dbg" [Undecided,Triaged] https://launchpad.net/bugs/1003234
<pitti> infinity: right, but once we do fetch ddebs from Launchpad, it shouldn't make much of a difference
 * infinity nods.
<infinity> I hope to get to testing the state of all of that this week.
<infinity> Once I'm done tearing my hair out over nscd.
<infinity> Or jump off a building.
<infinity> Whichever comes first.
<pitti> infinity: when you go for the building, please do so from the doghouse
 * pitti watches HDD space slowly come back on macquarie
<wgrant> infinity: If we're fetching old ddebs from the librarian, why not fetch new ones from there too?
<wgrant> infinity: Perhaps we don't need them published at all
<pitti> we still want to have an archive for them
<pitti> a lot of developers use them in their apt sources
<pitti> wgrant: an intermediate step would be to chagne ddeb-retriever to fetch them from the librarian, and continue to build the ddeb archive separately on macquarie
<wgrant> Ah
<wgrant> That's a bit sad.
<pitti> then the only thing that LP needs to do is to accept them in the .changes
<pitti> and put them into the librarian
<pitti> it would be a whole lot more robust than the current "on apache for 7 days" hack
<wgrant> Yeah, that was an intermediate step I considered, but decided it wasn't worth it since we were always pressed for librarian space.
<wgrant> Now it's on the SAN that might not be such an insurmountable issue.
<pitti> wgrant: I still don't think we should keep each and every ddeb we ever built
<wgrant> Oh, certainly not.
<wgrant> That would be insane.
<infinity> Well, the plan is to expire them at the same time we expire binaries.
<infinity> Which does happen.
<pitti> wgrant: for a released ubuntu we only need the ones from published packages
<wgrant> infinity: We can't keep them that long, I don't think
<wgrant> infinity: We only expire binaries once the series is obsoleted.
<wgrant> If we ever do at all.
<pitti> and for the dev release it would be nice to keep a backlog of two weeks or so
<wgrant> Right, those policies sound reasonable.
<infinity> wgrant: We also expire some binaries from released series.
<wgrant> infinity: Not deliberately.
<infinity> wgrant: Like old ones from updates/security that aren't current.
<wgrant> That would be a bug.
<infinity> This is what I was told happens. :P
<wgrant> You were lied to :)
<infinity> Blame elmo.
<infinity> Either way, I think we should *aim* to not have special expiry for ddebs, since they'll just be part of the binary upload.
<infinity> Should that prove a problem, we can revisit.
<wgrant> They're so enormous that we'd need to change the binary expiration policy.
<wgrant> Which we probably should.
<wgrant> (and that requires rewriting the archive file expirer from scratch to not be a patched together pile of bugs, which I've been meaning to do for a while...)
<wgrant> Currently the process for expiring PPA binaries is automated, but for primary archive stuff it's done by a frequently buggy piece of manual SQL
<wgrant> It gets rewritten by someone every second time or so.
<infinity> Comforting.
<wgrant> And most times it has nice bugs that will wipe out half the live archive too.
<wgrant> It's reliable, quality stuff.
<pitti> "things you don't want to hear on a quiet, peaceful morning"
<wgrant> Anyway, I have rough plans for a sensible garbage collector which will let us have a reasonably flexible binary expiration policy.
<wgrant> Rather than the manual SQL.
<wgrant> Which is buggy.
<wgrant> Until then, we can't really have ddebs for the primary archive in the librarian.
<wgrant> Or I think elmo will strangle me.
<pitti> wgrant: thanks for the heads-up; now I at least know what the current blocker is
<wgrant> Linaro's been happily using native ddeb support in their PPAs for several months, so most of it's fairly well tested.
<infinity> wgrant: Well, ddebs in the librarian would only be for builds going forward, nothing historical.  So, it'll take a while for the cruft to build up.
<wgrant> infinity: Yeah, but then the cruft will build up.
<infinity> wgrant: Anyhow, elmo seemed okay with the idea when we discussed it.
<wgrant> And we won't have any way to get rid of it.
<wgrant> That situation is less than ideal.
<wgrant> Although that might be a cunning way to get the GC rewrite scheduled...
<infinity> (And he didn't assume that development releases were getting binaries reaped during development)
<cjwatson> pitti: dropping -dbg> At least (say) python2.7-dbg and friends are genuinely different builds and useful, so shouldn't be dropped.
<pitti> cjwatson: *nod*; also what infinity said about -dbg shipping other useful tools
<pitti> cjwatson: so I'd rather do it the other way around and don't build -dbgsym for pacakges with -dbg, or build empty ones with just a -dbg dependency
<pitti> the latter is compatible with apport-retrace, I filed it as bug 1003234
<ubot2> Launchpad bug 1003234 in pkg-create-dbgsym "Build dummy -dbgsym for packages which already have a -dbg" [Undecided,Triaged] https://launchpad.net/bugs/1003234
<cjwatson> wgrant: Expiry: do you have any thoughts about the problem of ensuring that point releases are kept around even if we have a more aggressive expiration policy?  It's a bit tricky since LP doesn't model point releases.
<wgrant> cjwatson: I would be tempted to just not expire post-release pockets.
<wgrant> cjwatson: They're small enough
<wgrant> cjwatson: The big stuff is the development churn in Release
<wgrant> I should probably get some hard numbers, though
<cjwatson> I'm trying to work out whether it's worth us keeping hardlink farms of the pool for point releases, as opposed to just of dists.
<cjwatson> Just copies of dists, indeed.
<cjwatson> The difference being that we can much more easily do only the latter on a mirror, while the latter is kind of cocoplum-specific (or a mirror with insane space).
<cjwatson> https://lists.ubuntu.com/archives/kubuntu-devel/2012-May/006080.html for those interested in archive-reorg kinds of issues
<cjwatson> ^- Daviey's first accept
<pitti> Daviey: wohoo!
<Daviey> oh dammit, if i follow the law of 'firsts'.. i need to buy a round of beer.
<pitti> hm, why is https://launchpad.net/~ubuntu-release-nominators a member of https://launchpad.net/~ubuntu-release ? that sounds a bit backwards
<pitti> oh, I guess the LP priv is bound to ~ubuntu-release
<cjwatson> Yes
<cjwatson> It's a hack
<stgraber> cjwatson: I very quickly scanned through that thread, but I'm wondering if using "X-Ubuntu-Use-Langpack: yes" where they think langpacks are beneficial would fix their remaining concerns?
<stgraber> we've started using it for a few new Edubuntu packages where we knew translation would be sub-optimal at release time and wanted to benefit from post-release translations improvements through the langpacks
<skaet> pitti,  L3, QA  needed to nominate bug to specific releases, and yes, its a hack.
<pitti> skaet: sorry, what?
<skaet> pitti,  ubuntu -release-nominators
<skaet> :)
<pitti> skaet: aah, thanks
<skaet> cjwatson, slangasek, stgraber, infinity, stefanor, Laney, ScottK, and others interested,  https://wiki.ubuntu.com/QuantalQuetzal/ReleaseInterlock has most of the key information in it now.   (and related ReleaseSchedules updated from it),  can you review it, and make sure it matches up with your impressions from UDS?   I'll send mail out to ubuntu-release with this info as well.
<skaet> Daviey, ^
 * Daviey grumbles about being an afterthought.
 * skaet is sorry.  needs a better way to let release team members know in channel,  missed Ncommander too :/
<stgraber> !dmb-ping
<ubot2> bdrung, cody-somerville, Laney, micahg, barry, tumbleweed, stgraber: DMB ping
<stgraber> skaet: like that ^
<stgraber> (sorry for the ping ;))
<skaet> stgraber, coolio.  :)  how do they get set up?
<barry> stgraber: you woke me up from a nice nap.  i was dreaming about weekly team meetings
<skaet> :)
<stgraber> skaet: trying to get it setup in the bot now, will likely need someone from #ubuntu-irc to do it
<stgraber> !release-ping is infinity, cjwatson, Daviey, Laney, iulian, Riddell, skaet, NCommander, ScottK, tumbleweed, sistpoty, slangasek, stgraber: Release team ping
<Daviey> !-release-ping
<ubot2> Factoid 'release-ping' not found
<stgraber> Daviey: it needs approval by #ubuntu-irc, talking to them now
<Daviey> stgraber: i am one of those.
<Daviey> !release-ping is infinity, cjwatson, Daviey, Laney, iulian, Riddell, skaet, NCommander, ScottK, tumbleweed, sistpoty, slangasek, stgraber: Release team ping
<Laney> argh
<stgraber> Daviey: good to know :)
<skaet> :)
<stgraber> !release-ping
<ubot2> Factoid 'release-ping' not found
<stgraber> skaet: so apparently ubot2 needs to sync the new factoid from ubottu but it should be working fine next time you need it
<skaet> awesome!   Thank you!
<bjf> infinity: regarding the Precise 3.2.0-24.39 kernel: the patch has been verified to work and the kernel team have been boot testing the kernel on a wide variety of systems with no regressions
<infinity> bjf: Excellent.
<infinity> bjf: Well, get the bug tasks in a state that lets me know I'm good to go, and I'll make sure things happen.
<infinity> bjf: (So, either get team signoffs or mark invalid where appropriate)
<bjf> infinity: will do, thanks
<bjf> infinity: i think i've hacked the tracking bug to reflect the correct state and added comments why i did what i did
<infinity> bjf: Check.  Will poke it in a sec.
 * ScottK wonders how https://launchpad.net/ubuntu/+source/stellarium/0.11.2-1/+build/3513355 got a build score of 5000?
<stgraber> ScottK: that would be because I helped it a bit, synced stellarium from Debian (for Edubuntu) and wanted to confirm it builds on all arch before I can update edubuntu-meta (sadly arm still fails ...)
<ScottK> OK.
 * ScottK wanted to make sure it wasn't something related to recent build prioritization changes.
<cjwatson> Nope, none of those would result in 5000
<cjwatson> Anything that round isn't an auto-score :)
<ScottK> I didn't think so.
<ScottK> OK.
<ScottK> It just didn't look like the sort of critical package one typically sees manually rescored.
<cjwatson> Generally automatic scores aren't divisible by 100.
<cjwatson> Due to +5/10/15/20 for urgency, +5/10/15/20/50/100 for queue tim
<cjwatson> e
<cjwatson> You'd have to have carefully selected packageset or archive relative build scores for that
<Laney> Daviey: you're supposed to request backports on a bug, not just upload them yourself
<Laney> https://wiki.ubuntu.com/UbuntuBackports
<bjf> infinity, my intent is *not* to bug you, just a gentle reminder of my precise kernel
<Daviey> Laney: I suggest re-working the wording, as it doesn't emphatically state a bog should be opened, unless you want to 'request a backport'
<Daviey> ie, someone else please do the work for me
<Laney> I did just add some more information to that page
<Daviey> Laney: are you happy to review based as is, or do you want a bug?
<Laney> can you have a look at the page and see if it's more clear?
<Laney> I'd like a bug for bookkeeping, but it should be trivial to do so with requestbackport
<Daviey> otp right now
<Laney> the upload won't have the bug reference, but oh well
<Laney> does anyone mind if I update the process to say that the accepting AA will set the bug to Fix Released?
<Daviey> does -backports not Fix Release a series bug task?
<Laney> no
<Laney> it's a separate project
<Laney> also I believe that backports are special cased in soyuz to never close bugs
<ScottK> Daviey: If you aren't a backporter, you need approval to backport something.  Just because you have the theoretical rights, doesn't mean it's OK.
<ScottK> FWIW, some of the most difficult backports we've had were snuck in by archive admins without consulting the backports team (although that was long ago - it's been years since I noticed someone doing it).
<cjwatson> Laney: I don't mind, but I'm pretty sure I've forgotten to close bugs pretty much every time so far.  We could use some tooling here.
<Laney> cjwatson: Don't you use the web UI to accept stuff?
<Laney> (if so then it doesn't seem so amenable to scripting)
<cjwatson> We do at the moment.  Probably not forever.
<cjwatson> But yes, that would be an impediment at the moment.  Some scripts do things like "go accept this, then press Enter and I'll close the bug"
<cjwatson> Like syncpackage
<cjwatson> (OK, that's "wait for sync to be processed, but ...")
<cjwatson> And since we need a backport verification script anyway, that'd be somewhere for it to go
<Laney> Yeah. I think broder was going to implement that, but the wait for backports is somewhat more indeterminate.
<cjwatson> So the workflow for the time being would be "verify-backport blah" - downloads pair of source packages, diffs, asks you if it's OK, if you say no it bails out, if it says yes it gives you a queue URL and says to press Enter when you're finished with it
<cjwatson> I agree it's a bit more tenuous to do the wait on the backportpackage side, so if it didn't involve AAs having to manually open up bug URLs and paste stuff into them, I'd be fine with it
<Laney> If you'd actually use a script (and not find it a cumbersome impediment), then that sounds reasonable.
<slangasek> I find scripts universally preferable to the web ui ;)
<Laney> I just figured it was a bit of click click on the queue UI, so switching out to a terminal would be irritating
<cjwatson> I'd definitely use a script
<cjwatson> The click click will go away soon enough - PackageUpload.acceptFromQueue() or whatever isn't that far off
<cjwatson> I think possibly I need to break down that branch into pieces as I was having trouble figuring out the tests for the override part
 * Daviey returns
<Daviey> ScottK: Right.. I didn't suggest otherwise.. The backporting page wasn't clear.  I read it as, if you want a package backported (and cannot/will not) do it yourself, you raise a bug.
<Daviey> If you can do it yourself (upload), you upload and it's simply reviewed in queue.
<Daviey> It's not entirely clear to me what having a bug to track the "will do it yourself" helps with.. It's surely a binary operation?
<infinity> bjf: What kernel?
<Daviey> Yes, we accept this as a backport and it's good quality... No, this isn't appropriate for a backport, or bad quality.
<bjf> infinity, the fast tracked Precise kernel
<infinity> bjf: (look up)
<Daviey> ScottK: otherwise, why aren't srcNEW packages required to have tracking bugs in the development release?  Surely it's similar issues?
<bjf> infinity: ok, thanks
<cjwatson> Whoops, linux-tools and nvidia-support weren't meant to happen there, some kind of caching issue
<cjwatson> Other than that, that was auto-sync in batch mode, seemed to DTRT
<cjwatson> So just existing-NEW-detection and a bot account and I can entirely automate this
<cjwatson> Well, except for the NEW processing at the end
<cjwatson> Batch mode is "sync all autosyncable existing packages that don't overwrite existing *ubuntu*-versioned binaries, plus any new packages that don't overwrite existing *ubuntu*-versioned binaries and that have never previously been published in Ubuntu"
<cjwatson> So anything that's been removed but has then returned for good reason will still need manual attention, as will source renames of things with Ubuntu modifications
<Daviey> cjwatson: what about ubuntu native packages that do not have ubuntu in the version string, and Debian introduces a package of the same name?
<infinity> We add those to the blacklist.
<infinity> Or, we should.
<cjwatson> They'd have been autosynced in both the current and previous systems without anyone noticing
<Daviey> So, confirming that the new world order supports that.
<cjwatson> So either blacklist in advance, or repair after the fact
<cjwatson> Nothing about blacklisting has changed
<infinity> If you intend to have non-ubuntu-versioned stuff that's different from Debian, blacklist early and often.
<cjwatson> Well, except that it's now in a bzr branch on LP rather than a private one on cocoplum
<infinity> (udev being the canonical case that springs to mind)
<Daviey> cjwatson: hmm.. where is this branch?
<cjwatson> Daviey: lp:~ubuntu-archive/+junk/sync-blacklist
<cjwatson> Ah, ArchiveAdministration is out of date
<cjwatson> I only moved it there the other day
<Daviey> super.
<cjwatson> Fixed
<Daviey> ScottK: Can you respond to my above comments when you have a chance please?
<cjwatson> OK, and now auto-sync will (hopefully) detect things that are already in NEW and not repeat itself
<ScottK> Daviey: It's supposed to be approved via the bug before upload.  That's the difference.
<ScottK> The do it yourself aspect of this is supposed to be fore ubuntu-backporters,n ot for general use.
<Daviey> ScottK: and that used to be the case for SRU, but was reverted.
<Daviey> ScottK: wait, ubuntu-backporters don't need a tracking bug, as they review their own stuff, and everyone else does?
<Daviey> ScottK: So please, what is the difference between using a tracking bug to 'approve' and upload, and just 'approving' from the queue?
<ScottK> Daviey: Because not all backporters have access to the queue.
<Daviey> ScottK: okay, can you compare to srcNEW for the development release?
<ScottK> Daviey: If you want a process change, please don't just make it up and start doing the new way.  Discuss it with people first.
<Daviey> Sponsorship bug vs just uploading?
<Daviey> ScottK: this isn't a process change.. Process is documented, this was not.
<ScottK> Yes and if you're not in backporters you need sponsoring.
<Daviey> Or at least ambiguous at best.
<ScottK> So far only for you.
<ScottK> I have to go.
<Daviey> Yeah, we don't exactly have a bustling backporters community, so yeah.
<cjwatson> What ScottK is describing is definitely how I understood the process.
<cjwatson> (I have abused archive admin to shove in backports in the past, although only for debootstrap; I've been persuaded by argument not to do this in future)
<Daviey> cjwatson: right, but i'm trying to determine the difference between 'review in queue' and 'review via tracking bug'.  Especially as ~ubuntu-backports can self approve a backport without a bug.
<cjwatson> I'm not aware that they actually do so.
<Daviey> cjwatson: well ScottK just suggested otherwise.
<cjwatson> AFAICS -backporters use tracking bugs even for things they care about personally ...
<cjwatson> Anyway, for me, the important bit is that authority for the backports pocket is wholly delegated to -backporters
<Daviey> +1
<cjwatson> While archive admins happen to have queue admin access there, we're doing so on behalf of -backporters until such time as they can do it themselves
<cjwatson> So it's not for us to create policy on their behalf
<Daviey> cjwatson: right, i'm not doing that.. The documented 'policy' was (in my mind) ambiguous.
<cjwatson> OK; but then in that case verbal clarification should be enough for the time being, with the understanding that it's generally worth clarifying documents when people misunderstand them
<cjwatson> I just don't think "this is ambiguous" "it means this" "but this is ambiguous" is necessarily a productive continuation
<cjwatson> IYSWIM
<Daviey> cjwatson: yes, i see that.
 * infinity needs new glasses.
<infinity> "New binary: horse-simulator [i386] ..."
<RAOF> infinity: New binary: my-little-pony [armhf] ...
<jdstrand> is it accurate to say that the 'all' files in each seed directory in http://people.canonical.com/~ubuntu-archive/germinate-output/ contains all the packages that make up the seed. eg ubuntu.precise/all is all of 'ubuntu' and xubuntu.precise/all is all of xubuntu?
<jdstrand> meh, gotta run
<cjwatson> jdstrand: It contains all directly seeded packages and the fully-expanded chains of run-time dependencies/recommendations and build-dependencies.
<cjwatson> (I'd recommend reserving "seed" for e.g. "desktop" and using "seed collection" for "ubuntu.precise".)
#ubuntu-release 2012-05-24
<Daviey> infinity: Fancy revewing ubuntu-archive ML, i have a held mail.
<cjwatson> Daviey: Done, and whitelisted you for the future.
<Daviey> cjwatson: thank you sir.
<Daviey> (i assumed you'd be smarter than me, and be afk :)
<micahg> skaet: would it be ok for me to add Firefox/Thunderbird to the interlock page?
<skaet> micahg,  please do.  :)   Thanks!
<micahg> skaet: only conflicts seem to be alpha 1 (we can upload final early I think), and final freeze (release is 2 days before RC candidates)
<skaet> micahg,  thanks for making that visible.  :)
<infinity> cjwatson: Okay, arm* toolchains should be in a sane state again.  I'm going to freshen all the buildd chroots after eglibc is done building, and you should be good to go on the unstable autosync switcheroo any time after that (so, in a few hours).
<infinity> cjwatson: Alright, chroots all updated and verified happy.
<cjwatson> infinity: great, thanks
<xnox> cjwatson: based from email to u-d, did you start syncs from unstable or are you still working on a work-around to enable syncing from unstable?
<cjwatson> I meant what I said :-)
<cjwatson> I'm still working on the workaround
<cjwatson> I just wanted to give slightly more than "hi, I just started syncing from unstable, kthxbye" kind of notice
<cjwatson> But certainly this is "speak now or forever hold your peace" kind of time
<xnox> ok.
<xnox> I have managed to make ubiquity fail one unit test by the way ;-)
<xnox> but is comming up.
<cjwatson> oh?
<cjwatson> (-> #ubuntu-installer maybe)
<cjwatson> gosh, my auto-sync workaround seems to be working more or less first time; I genuinely hadn't expected that
<xnox> you are just awesome =) didn't you get used to that by now?! ;-)
<ogra_> xnox, the prob is that he never belives us :)
<wgrant> cjwatson: What'd you do?
<cjwatson> wgrant: Fell back to fetching Sources from Debian
<cjwatson> You thought auto-sync was elegant?
<wgrant> Heh
<cjwatson> Hm, slightly different results for new packages though; will need to look into that
<ScottK> I'd appreciate it if someone from ubuntu-sru could accept the remaining KDE 4.8.3 packages for precise-proposed so we can get testing.
<cjwatson> wgrant: Looking at this, I'm not sure I believe the accuracy of DSD creation in the slightest.
<cjwatson> I'll file a bug, but right now I think I'm honestly better off not bothering to look at them.
<wgrant> cjwatson: I don't trust them at all, but what's the issue?
<wgrant> I had no part in them other than defining the base version calculation.
<cjwatson> A fair number of new packages in wheezy that have no DSDs.
<wgrant> That's unhelpful.
<cjwatson> Including some that were never in Ubuntu and ought to be synced, and some that were removed but have since had new versions in Debian.
<cjwatson> wgrant: Do you think it will cause any major obstacle to investigation if I go ahead and sync some of the packages that should be synced?
<wgrant> cjwatson: Go ahead
<wgrant> It'll be months/years before anyone can investigate, and there are probably other cases
<cjwatson> Righto
<slangasek> how do I see from launchpad who synced a package?
<slangasek> someone synced python-xattr over an Ubuntu delta, dropping the dh_python2 integration
<stgraber> slangasek: Signed-By: Andres Rodriguez <andreserl@ubuntu-pe.org>
<slangasek> stgraber: how do I see that ;)
<stgraber> slangasek: quantal-changes :)
<slangasek> stgraber: ah, ok
<stgraber> slangasek: there might be some obscure way of getting it from LP too
<tumbleweed> slangasek, stgraber: The SPPH record creator in the LP API
<slangasek> tumbleweed: so nowhere visible in the UI?
<tumbleweed> no, that would be too easy :)
<slangasek> ack :)
<slangasek> thanks for the info
<cjwatson> Right, running a final auto-sync with the new algorithm from Debian testing, and then I'll attempt a switch to unstable
<cjwatson> This has taken way too much of the day
<tumbleweed> cjwatson: [reading backscroll] it may be useful to output a report on removed packages that have never versions in Debian to the version we removed (assuming they weren't blacklisted). or are such reintroductions rare enough not to bother?
<cjwatson> auto-sync outputs those
<cjwatson> Whoever's running it gets to decide what to do (or defer)
<tumbleweed> great
<cjwatson> They're certainly not infrequent
<cjwatson> At some point I might add some stuff to open up packages.qa.debian.org and publishinghistory URLs in a browser or something
<cjwatson> Since that's usually what I do to try to work it out
<cjwatson> Auto-sync from unstable in progress ...
<seb128> *fear* ;-)
 * micahg wonders how many builds will end up in the queue
<cjwatson> You know, I'm just going to go with "lots"
 * micahg is just wondering if it'll be anywhere near the 10k at the first autosync
<cjwatson> I shouldn't think so
<stgraber> cjwatson: are you expecting a lot of things to hit New? (wondering if we should silence queuebot again)
<cjwatson> Yes
<cjwatson> Probably a plan
<cjwatson> [New] nyancat_0.1+git20120401.5a88b86-1
<cjwatson> obviously that's vital
<knome>  
<stgraber> ;)
<stgraber> cjwatson: can you run "/msg chanserv quiet #ubuntu-release queuebot"? (chanserv tells me I don't have access)
<cjwatson> There you go
 * knome is wondering if stgraber ircs from the same host
<knome> ;]
<cjwatson> He's cloaked, hopefully that makes a difference
<knome> we probably see in a moment ;)
<stgraber> I'm connected with @shell01.dmz.dcnue.stgraber.net which is also vorash but over IPv6
<knome> heh
<stgraber> (and the cloak probably also lets me avoid that mask)
<cjwatson> http://paste.ubuntu.com/1005184/
<cjwatson> pressed enter, let's see how many goes it takes to get it through LP
<ScottK> pitti: Thanks for accepting kde-l10n for precise.  If you could also accept blinken and cantor, we'd have all of KDE 4.8.3 in (they're in Universe and the uploader isn't MOTU, so they took longer to get in the queue).
<cjwatson> (1256 syncs, FWIW)
<micahg> 15 hrs on powerpc, not so exciting
<cjwatson> It's not finished processing the PCJs yet, but sure
<micahg> ah, ok
<tumbleweed> looks like we got to 42 hours on ppc
<micahg> nice, hopefully we'll end up with less build failures than we currently have
<stgraber> I just uploaded a new lxc (-3ubuntu57) to precise-proposed. The diff is fairly big though I think I did a reasonable job of describing everything in the changelog.
<stgraber> as discussed earlier with SpamapS, quite a few improvements are in there that won't change the behavior for the user but will make it significantly easier for us to cherry-pick additional fixes from quantal (if needed)
<stgraber> I have testcases in all the linked bugs except one (lxc-start-ephemeral failing to get the IP from dhcp lease file) but I was told by gary_poster that the bug would be updated tomorrow
<stgraber> the LXC testsuite was also run without spotting any regression. If whoever reviews it has any question, feel free to poke me :)
 * xnox is puzzled
<xnox> bitcoin	[build logs] (0.6.2.2-1)	â	â	â	â	â
<xnox> in the boost1.49 transition tracker, when it required boost1.49 merge, to get gcc4.7 ftbfs fixes
<micahg> xnox: old binaries exist
<xnox> micahg: but they would not have passed the transition criteria
<micahg> hrm?
<xnox> it looks like it was synced 3h40m ago, maybe newer bitcoin works around boost brokeness
<micahg> no, it just dropped the other archs
<xnox> micahg: I am talking about this page: http://people.canonical.com/~ubuntu-archive/transitions/boost1.49.html
<micahg> err...idk about boost, but it dropped the other archs
<xnox> are we on the same page?
<micahg> xnox: yes, I nkow
<micahg>   bitcoind | 0.3.24~dfsg-1 | quantal/universe | armel, armhf, powerpc
<xnox> aha thanks
<xnox> I wonder why though
<micahg> hrm, LP doesn't recognize any-arm apparently
<xnox> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669200
<micahg> infinity: ^^
<ubot2> Debian bug 669200 in bitcoind "bitcoin: FTBFS on armel, armhf" [Normal,Fixed]
<xnox> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668864
<ubot2> Debian bug 668864 in bitcoind "bitcoind: Doesn't support big-endian systems" [Wishlist,Fixed]
<micahg> xnox: yes, powerpc binary should be removed, but arm needs any-arm to be recognized
<xnox> micahg saves the day again!
 * micahg flies off into the sunset
 * xnox files an lp bug?
<micahg> bug 917708
<ubot2> Launchpad bug 917708 in launchpad "Launchpad does not recognize Arch = any-arm" [Low,Triaged] https://launchpad.net/bugs/917708
<xnox> yeap, found it as well now =) you are quicker
<xnox> micahg: can we bump the priority of that bug?
<micahg> xnox: better off buying infinity cookies
<xnox> infinity: I promise british biscuits to you =)
<infinity> That's a recognized arch?
<micahg> infinity: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668868#28
<ubot2> Debian bug 668868 in src:bitcoin "bitcoind: Assertion failed at startup on mips (big endian)" [Serious,Fixed]
<infinity> xnox: And yeah, for now, you'll just want to replace any-arm with "armel armhf"
<infinity> (I can't imagine any-arm is used a lot...)
<slangasek> whoa, any-arm is an alias to arm*?  That seems contrary to the other any globs
<slangasek> I would've expected any-arm to match arm, hurd-arm :P
<infinity> Yeah, I would have too.  But it seems to be a CPU alias.
<slangasek> yuck
<infinity> Which, actually, would make it incorrect for bitcoin's stated use ANYWAY.
<infinity> Since it would match any-armeb.
<slangasek> \o/
<infinity> xnox: So, file a bug on bitcoin to change it to any-armel and any-armhf. :P
<infinity> xnox: (In Debian)
<infinity> Not that anyone builds armeb anymore, but it's the principle of the thing.
<slangasek> or arwoofeb
<infinity> aarc64eb
<infinity> With a missing h.
<slangasek> aardvarch
<infinity> aardvarcheebie.
<infinity> I'm actually kinda hoping the ditched the ability to flip endianness in v8, but I haven't looked.
<slangasek> dh_clean: No compatibility level specified in debian/compat
<slangasek> dh_clean: This package will soon FTBFS; time to fix it!
<slangasek> wow
<slangasek> what have I gotten myself into
<infinity> No compat?  Seriously?
<slangasek> well, DH_COMPAT=5 in debian/rules
<slangasek> so it's one of Those
<slangasek> ScottK: python-pam hasn't had a new upstream version since 1999, nor a Debian maintainer upload since 2007, and the packaging is quite ancient.  I'm happy to modernize the packaging but don't really want to be on the hook for maintaining it going forward; what would you recommend?
<slangasek> (would be happy for it to go away under the circumstances, but python-twisted-core wants it)
<RAOF> Hm. When I copied utouch-geis out of precise-proposed I should have also copied it to quantal, but didn't. Is there an existing tool to sync from precise-updates to quantal?
<slangasek> RAOF: there are tools... but I may be using one that's deprecated since it's on cocoplum ;P  which one are you using?
<RAOF> I'm not currently using one; I'm looking for one :)
<RAOF> (Or, rather, I *used* sru-release for the copy from precise-proposed to -updates, but forgot to add the --devel switch)
<stgraber> RAOF: maybe something like that from lp-shell will do it: http://paste.ubuntu.com/1005675/
<RAOF> Or maybe something like that will OOPS on launchpad with a timeout :)
<RAOF> Thanks, though.
<slangasek> RAOF: I can run a copy-package for you now
<RAOF> slangasek: That'd be good, thanks.
<slangasek> though, we're well past the point in the cycle at which anyone should be uploading to -proposed and expecting us to copy to quantal
<slangasek> next time this happens, we ought to make it the uploader's problem... :)
<RAOF> This was uploaded to precise-updates before the precise release; it's only just been verified.
<slangasek> ah
<RAOF> That said... there doesn't seem to be any particularly good reason to wait for it to be verified before copying it from precise-proposed to quantal.
<slangasek> true
<stgraber> RAOF: oh, well, that probably means that it was the right call, just got into the usual LP timeout on package copy :)
<RAOF> It *does* have about 4 bugs attached; that might bring poor little launchpad to its knees :)
<slangasek> RAOF: my point is, though, that we're well into the cycle now and we should be getting stuff rebuilt with the quantal toolchain / lib deps
<slangasek> so should make people reupload to quantal anyway
<slangasek> (so that the SRU team doesn't have to do a bunch of work to make a determination of whether it's safe to copy, that takes us more time than it would take to just reupload it)
<slangasek> anyway - copied now
<RAOF> Thanks.
#ubuntu-release 2012-05-25
<cjwatson> stgraber: s/syncSource/copyPackage/
<cjwatson> would probably not have timed out
<stgraber> cjwatson: I really should change my bookmark for /devel.html... always looking at the stable API makes me miss all the new shiny async ones
<jdstrand> hrm, http://status.ubuntu.com/ubuntu-quantal/canonical-security.html is having a problem
<jdstrand> we added several blueprints today and moved some stuff out of the existing ones into the new ones, but the new ones aren't showing up
<jdstrand> (they aren't in canonical-security.json)
<jdstrand> it's weird cause security-q-catch-all-essential was added today, and it showed up but security-q-apparmor-dev-lxc and security-q-apparmor-dev-dbus did not
<jdstrand> and security-q-apparmor-dev-essential did not either
<jdstrand> actually, security-q-catch-all-essential was not added today
<jdstrand> that was added yesterday
<jdstrand> anyhoo, heading out, maybe it'll magically work itself out while I am asleep
<skaet> jdstrand,  yeah,  I was talking to cjohnston about it earlier,  he's in Hong Kong right now at Linaro connect, so not quite sure how responsive.
 * skaet has a bunch of changes that aren't showing up either.
<jdstrand> skaet: well, that is good for me. we made a ton of changes today
<jdstrand> skaet: and I was worried it might be releated to what we did
<jdstrand> skaet: thanks
<jdstrand> skaet: do you know if we will be doing a reset anytime soon? istr that happening sometime within a couple weeks of UDS
<skaet> jdstrand,  trend lines will be reset right after FeatureDefinitionFreeze
<skaet> (if that's what you mean by a reset)
<jdstrand> skaet: ok. I was more talking about the ramp up of work items, but that's fine (I also know I can override the trend line)
<skaet> ramp up is interesting data too,  so not sure we should loose that.  ;)
<jdstrand> that's cool
<jbicha> hi, any volunteers to post http://paste.ubuntu.com/1001275/ to the Ubuntu transition tracker?
<ScottK> slangasek: Not sure why you're asking me about python-pam. ENOCONTEXT.
<slangasek> ScottK: asking you for advice on what to do with respect to the Debian maintenance status, since it's a python module
<slangasek> ScottK: since I'm not interested in being the maintainer myself, I don't know if it's appropriate to arrange for its orphaning and, er, "gift" it to the DPMT?
<Laney> Daviey: you can go ahead and accept your backport
 * micahg didn't think Daviey was an AA
<Laney> as of very recently i think
 * Laney â research away day. ttyl.
<micahg> I see
<Daviey> Laney: thanks
<tumbleweed> slangasek: if it was gifted to DPMT it'd still need a real maintainer
<xnox> tumbleweed: python-pam is nice
<xnox> I've used it onces
<xnox> it didn't work though and crashed my session and I have fun time trying to regain root again
<tumbleweed> xnox: volunteering to maintain it? :)
<xnox> nah
<xnox> :P
 * xnox my dns lookups are funny
<xnox> they timeout
<Daviey> i used python-pam for yubikey pam integration.
<knome> when's the baseline set for real in status.ubuntu.com ?
<tumbleweed> feature definition freeze
<knome> k, thanks
<ogra_> hmm, running buildlive for daily-preinstalled gets me: "No valid suites to build for"  ... cjwatson do you have any idea wheer that message comes from, i cant find anything related in either cdimage nor debian-cd code
<ogra_> oh, might be livecd-rootfs or live-build
<tumbleweed> whee, the unstable sync brought in quite a few FTBFSs http://people.ubuntuwire.org/~stefanor/lp-ftbfs-report/historical/primary-quantal.html
<ogra_> great, there it is
<cjwatson> <cjwatson@sarantium ~/src/ubuntu/livecd-rootfs/livecd-rootfs>$ grep 'No valid' *
<cjwatson> BuildLiveCD:    echo "No valid suites to build for" >&2 && exit 1
<infinity> ogra_: As I pointed out earlier, some of the arm buildds appear to not have quantal chroots yet.
<infinity> ogra_: Which would trigger that error.
<ogra_> infinity, oh, so i was right, then i'll stop digging, i though you didnt get to it yet
<mvo>  we we  fasttrack 5.2.2.1 to -updates to fix bug ##1002271? this is a bit unfortunate (i.e. miscommunication on our part) that the 5.2.2 should have been superseeded instead of going to updates
<mvo> eh, s/we we/could we/ ?
<seb128> (the said bug is first on errors.ubuntu.com today)
<astraljava> skaet: Apologies for sending the mail a little late. But there was not that much to report anyway. I'm going to miss the meeting, too, so if there are any questions for Xubuntu, please let me know and I can get the answers afterwards.
<ScottK> slangasek: Ah.  I get it now.  DPMT generally wants someone real associated with each package, so unless you can convince someone to be the warm body associated with it, it's probably not appropriate.
<seb128> the release meeting is in one hour right? (just checking I don't have a wrong time, you never know with google calendar and dst)
<zul> can someone promote dwarves-dfsg and python-jsonschema for me, it passed the MIR process
<skaet> seb128,  yes
<skaet> :)
<seb128> skaet, hey, thanks ;-)
 * skaet busy working through ubuntu-release emails,  so nick highlight if questions.  :)
<cjwatson> zul: Are you about to start (build-)depending on them somewhere?
<zul> not yet for jsonschema, but yes for dwarves for libvirt
<cjwatson> I've promoted dwarves-dfsg then; please ask once you're about ready to start depending on python-jsonschema - if I move it now, it'll show up in the report to be moved back to universe and it's possible we'll have to go through it all again
<zul> cjwatson: ack
<ev> would someone be so kind as to demote migration-assistant to universe?
<cjwatson> ev: ubiquity needs to be uploaded first
<cjwatson> Then it should show up in http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<ev> cjwatson: good call! Apols, I ran around checking the seeds and things and completely forgot about the missing upload
<cjwatson> Hm, actually, not ubiquity
<cjwatson> It's in the installer seed
<ev> oh? I grepped through ubuntu.quantal
<cjwatson> platform.quantal
 * ev headdesk
 * ev fixes
<slangasek> tumbleweed, ScottK: ack; I guess I'll try to do that then, after I get barry to bless the actual python3 porting
<slangasek> tumbleweed, ScottK: thanks :)
<ev> right, migration-assistant is finally in component-mismatches. Would someone kindly send it to universe?
<cjwatson> ev: done
<ev> cjwatson: thanks!
<barry> slangasek: the port looked good to me.  minor comments, but overall 'approved'
<slangasek> barry: did you send your minor comments to the mp?  I apparently don't have them yet
<barry> slangasek: i did.  i guess it takes some time for lp to process it
<slangasek> okie
<barry> (responded via email)
<ScottK> RAOF or SpamapS: There's cantor, blinken, and an updated kde-workspace in the queue for precise-proposed.  Would one of you please accept.  That'll complete KDE 4.8.3.
<bjf> skaet, got a load of kernel packages that need to be copied to various places. at least one from -proposed to -updates and some new ones in the ppa
<cjwatson> bjf: Shoot
<bjf> cjwatson: oneiric 3.0.0-20.34 from -proposed to -updates
<bjf> cjwatson: and then there is a list down at the bottom of the pending-sru report: http://people.canonical.com/~ubuntu-archive/pending-sru.html
<cjwatson> bjf: Am I meant to ignore that only one of the bugs associated with that kernel upload has verification-done set?  I vaguely recall that there's some other verification process for the kernel, but I don't know it well.
<bjf> cjwatson: let me look
<cjwatson> Ah, yes, I see the tracking bug ...
<bjf> cjwatson: yes, that's where i was heading
<cjwatson> So "certification-tracking-passed" is what you use to mean "good to go"?
<cjwatson> And am I meant to copy to -security too, per that bug task?
<bjf> charlieS: all states except promote-to-updates and promote-to-security are "Fix Released"
<cjwatson> Sorry for all the questions; I don't think I've done this for a while
<bjf> charlieS: sorry, meant cjwatson
<cjwatson> OK, I think I understand
<cjwatson> All of "linux linux-backports-modules-3.0.0 linux-meta"?
<bjf> cjwatson: yes please
<bjf> cjwatson: not that you weren't aware already, but this is the pile of packages we upload fresh every 3 weeks
<cjwatson> loosely aware
<bjf> it's a crapload
<cjwatson> but I wasn't familiar with the details so needed to read up
<cjwatson> copied to security/updates
<cjwatson> Should I close the bug?
<bjf> cjwatson: just mark you task "promote-to-updates" as "Fix Released"
<cjwatson> And promote-to-security since I did that
<bjf> cjwatson: ack
<cjwatson> Done, feel free to check I didn't screw it up
<bjf> cjwatson: we have a bot that watches things and flags problems, i'll keep an eye on it
<cjwatson> And you want everything in the "Kernel PPA" section
<cjwatson> ?
<cjwatson> In fact, is it generally safe for me to just act directly on them whenever I see anything in that section, or am I better off waiting for an explicit request?
 * skaet sees cjwatson is handling, and goes back to her blueprint wrangling.  thanks cjwatson.
<bjf> cjwatson: yes, if it's in the ppa section it can be handled
 * skaet nods
<cjwatson> Great, knowing that should improve throughput
<skaet> generally bjf just pings, when its been ignored for 12 hours.
<bjf> skaet: in this case we are at the end of the "prep" week and i want to be ready for the "verification" week
<bjf> skaet: i really try to resist nagging, i know people have a lot of other issues they are dealing with
<bjf> cjwatson: when we (people with upload rights) can pocket copy from the ppa to -proposed that will help
<cjwatson> You can.  Wanna try?
<skaet> bjf,  right now with the transition of pitti to his new role,  reminders are welcome, until we sort out the new flow.
<cjwatson> It needs approval by an archive admin, but the copy itself shouldn't be a restricted operation any more.
<skaet> \o/
<cjwatson> Incidentally I'm marking the main (development release) task on the tracking bugs Invalid, per https://wiki.ubuntu.com/ArchiveAdministration#Copying_PPA_kernels_to_proposed
<bjf> cjwatson: ack
<cjwatson> And where necessary approving nominations for stable
<cjwatson> bjf: So, 'bzr branch lp:ubuntu-archive-tools' and in there run './copy-proposed-kernel.py lucid linux'
<bjf> cjwatson: heh, was just about to ask
<stgraber> cjwatson: speaking of which, I'm not sure whether https://code.launchpad.net/~stgraber/ubuntu-archive-tools/pkgsets-improvements/+merge/102543 is somewhere on your list of stuff to look at
<cjwatson> stgraber: obviously forgot, I'll have a look, thanks
<cjwatson> Let me just untangle myself from this pile of stuff first though
<cjwatson> bjf: Any luck?
<cjwatson> bjf: Also, I went through all the bugs and fixed up a few bug states; the only one that still looks a bit out of the ordinary is bug 951043
<ubot2> Launchpad bug 951043 in linux-ti-omap4 "Port OOM changes into do_page_fault for arm" [Medium,Confirmed] https://launchpad.net/bugs/951043
<bjf> cjwatson: have not tried, was assuming since i'd asked you, you would do it and i was going to try on the next packages, i can give it a try now though
<cjwatson> bjf: You might as well try now
<bjf> cjwatson: will do
<cjwatson> Oh, also, I'm going to unquiet queuebot now since most of the autosync noise has probably died down
<cjwatson> That'll let me see the copies
<cjwatson> (heh, I thought I'd done those accepts enough in advance ...)
<stgraber> cjwatson: it's looking at the queues every minute
<cjwatson> Yeah, I just miscalculated
<bjf> cjwatson: script ran, i see it in the upload queue
<bjf> there it blows
<cjwatson> Yay
<bjf> cjwatson: has the issue been fixed so it can't be accidentally copied to universe ?
<cjwatson> No, I'll check it by hand
<bjf> cjwatson: ack
<cjwatson> But from the looks of things I need to wait until it's published
<cjwatson> bjf: Can you go right ahead and do the other copies off pending-sru, then?
<bjf> cjwatson: yes, i will try to do so
<cjwatson> It should all just work for you
<cjwatson> stgraber: merged, thanks
<stgraber> np. do_copy will be quite useful for the DMB (as for some weird reason, new uploaders want to also be able to upload SRUs ... :))
<bjf> cjwatson, bug 1003534 comment #4
<ubot2> Launchpad bug 1003534 in kernel-sru-workflow "linux: 3.2.0-25.40 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/1003534
<bjf> skaet: ^
<infinity> bjf: I'll fix.
<infinity> cjwatson: disregard bjf. ;)
<bjf> infinity: thanks
<bjf> indeed
<infinity> bjf: So I don't end up doing this 7 times, is it just precise-proposed/linux that has the problem?  No other pockets or source packages?
<bjf> infinity: that's all my bot has bitched about so far
<infinity> bjf: Alright, fixed in the next publisher run, then.
<herton> bjf, infinity: not only linux, but last entries bitch about linux-backports-modules-3.2.0 as well
<herton> the packages with 3.2.0-25.10 version are from lbm
<infinity> herton: Ahh, thanks.
 * infinity fixes that too.
<infinity> Silly me, I didn't notice the comment was truncated.
<bjf> infinity: so, this is the first time that i ran the copy-proposed-kernel.py script myself. is the problem there or elsewhere ?
<infinity> The problem is that that script can't work right without an archive admin to babysit it.
<infinity> Did someone imply otherwise?
<bjf> cjwatson suggested i was able to run it
<infinity> Well, sure.  You are.  Things just end up in the wrong components. :P
<bjf> infinity: ok, so i "can" run it, i just "shouldn't"
<infinity> (They always do, and we always clean up, but it's less obvious that cleaning up needs to be done if someone else ran the copy)
<infinity> Yeah, probably that. :P
<infinity> It's three issues compounded that make it irksome.
<infinity> The first is that PPAs are flat (not a bug, just a misfeature, IMO), the second is that NEW packages default to the wrong component (IMO, they should default the same component as their source, a bug exists for this), and thirdly, I believe that PPA->proposed copies skip NEW, though maybe that's been fixed.  I haven't done a copy recently.
<infinity> If the latter is no longer true, then you can blame the AA who accepted your copy, perhaps.
<infinity> But I think there's no change to override in the queue, so it has to be done later.
<infinity> s/change/chance/
<bjf> infinity: i think this is good information to pass along to cjwatson, skaet and others
<cjwatson> bjf: yeah, I'd been having an evening and hadn't had a chance to run the fixer script
<cjwatson> infinity: thanks
<infinity> I'm not entirely sure why we have a "fixer script".
<infinity> linux and lbm are entirely in main.
<infinity> That's not rocket science.
<bjf> cjwatson: so, do you agree that I really shouldn't be running that script and that it needs the fine touch of an AA ?
<cjwatson> I think there's absolutely no reason why you shouldn't continue to run the script yourself.
<cjwatson> An AA has to accept it anyway.
<infinity> (As in, the "fix" is just to change-override -c main -S linux, there's no logic needed)
<cjwatson> It's only that I wasn't around after the publisher run to fix it.
<cjwatson> With syncs, we can't override it in the queue.
<infinity> cjwatson: With NEW syncs, that really should be fixed...
<cjwatson> Anyway, I'm just going to add this to my list of things to fix in LP.
<infinity> cjwatson: Is there a bug for that?
<cjwatson> Dunno.
<cjwatson> I'm mostly watching TV right now. :)
<infinity> Still, fixing the default component bug would paper over this issue.
<infinity> And that's probably a one-line fix somewhere.
<infinity> Well, maybe a few lines.
<infinity> But.
<cjwatson> bjf: We'd have had the exact same problem if I'd run the script.  It makes no difference.
<infinity> Maybe I should make sure the laptop I take to HK has an LP checkout, and I'll try not to drink myself into a stupor on the plane.
<cjwatson> infinity: They indeed don't go through NEW; and that's fixable.
<infinity> cjwatson: Yeah, I think I noted that it's not the script that's at fault, just that whoever accepts it needs to be aware.
<cjwatson> That sais
<cjwatson> said
<cjwatson> The copy goes through unapproved
<cjwatson> With include_binaries=True
<cjwatson> We wouldn't want to have to accept twice in a row
<bjf> cjwatson, infinity, i'm perfectly fine running the script and will continue to do so
<cjwatson> I'll think about this
<infinity> cjwatson: You can override in unapproved too.
<infinity> cjwatson: You can override in any queue.
<cjwatson> The queue entry only contains the PCJ.
<infinity> cjwatson: But I'm not sure that syncs are currently overridable.
<cjwatson> The binaries aren't visible separately.
<infinity> Right.
<infinity> That's really the buggy feature, IMO.
<infinity> Well, sync representation in the queue is all kinds of misfeatured.
<cjwatson> So unapproved, new, makes no difference, it's what's in the queue entry that matters.
<cjwatson> Anyway, gone for now :)
<infinity> cjwatson: Before you go...
<infinity> cjwatson: Did you intentionally not flush all your syncs from the quantal queue?
<cjwatson> infinity: Uh.  No.  I've got it in history, I'll try again in a bit
<cjwatson> I think that's it
<infinity> cjwatson: Ahh, I could have done it, I just wasn't sure if they were sitting there intentionally.
<cjwatson> infinity: No, I think I just ran queue accept before the copy jobs had processed but didn't notice
#ubuntu-release 2012-05-26
<astraljava> skaet: Apologies for sending the mail a little late. But there was not that much to report anyway. I'm going to miss the meeting, too, so if there are any questions for Xubuntu, please let me know and I can get the answers afterwards.
<astraljava> grr... sorry about that. I should know better to not touch the Enter key when I have connection problems.
#ubuntu-release 2012-05-27
<xnox> how often does lp.net update it's debian mirror?
<xnox> $ requestsync clasp
<xnox> W: Target release missing - assuming quantal
<xnox> E: The version in Ubuntu (2.0.6-1ubuntu1) is newer than the version in Debian (2.0.6-1). Aborting.
<Laney> can be up to a day ime
<cjwatson> I'm told the importer runs every six hours, although I'm not sure that *entirely* tallies with my experience
<cjwatson> 10 3,9,15,21 * * * /srv/debian-import.launchpad.net/production/launchpad/scripts/gina.py squeeze sid experimental wheezy -q --log-file=INFO:/srv/debian-import.launchpad.net/production-logs/gina.log
<Laney> doesn't it pull from the UK mirror?
<Laney> so there are several sources of delay in between
<cjwatson> Slightly more complete:
<cjwatson> # Mirror from ftp.uk.debian.org.  Debian publishes at "52 1,7,13,19"
<cjwatson> # but we also need to allow time for the above mirror to update.
<cjwatson> 05 3,9,15,21 * * * sh /srv/debian-import.launchpad.net/scripts/mirror-update.sh >> /srv/debian-import.launchpad.net/production-logs/mirror-update.log 2>&1
<cjwatson> # Allow 5 minutes between mirroring and running Gina. The mirror logs suggest
<cjwatson> # that mirroring takes at most about 1m30s.
<cjwatson> 10 3,9,15,21 * * * /srv/debian-import.launchpad.net/production/launchpad/scripts/gina.py squeeze sid experimental wheezy -q --log-file=INFO:/srv/debian-import.launchpad.net/production-logs/gina.log
<cjwatson> I don't know why those two jobs aren't a single job with &&; might ask about that
<cjwatson> (but during the week)
<cjwatson> Oh, mind you, .au might have started
<xnox> ok, thanks. Back to drinking sunday evening tea =)
<cjwatson> Hm, I think it might be optimistic about Debian's publishing time
<cjwatson> So we might be hitting near worst-case latency
<cjwatson> I'll keep an eye on it as best I can and have a look
<cjwatson> xnox: This is basically bug 798611
<ubot2> Launchpad bug 798611 in launchpad "Package Auto Sync seems to get ahead of +localdiff calculation" [High,Triaged] https://launchpad.net/bugs/798611
<tumbleweed> or if we really wanted to optimise it, organise push mirroring
<Daviey> Does config changes for status.ubuntu.com get rolled out automagically now, or does it still require a human to pull?
 * xnox is this sync running....
<cjwatson> xnox: the new binaries?  yes, I run syncs more or less daily
<cjwatson> you can ignore queuebot if it's not interesting :)
<xnox> cjwatson: ok. I'm just pondering when will I finally be able to requestsync clasp.
<xnox> I am doing ubuntu development DD styly: "TeamUpload/NMU + sync to ubuntu" =))))
<xnox> s/styly/style/
<cjwatson> my investigations earlier suggested that the maximum latency is ~13 hours.  but remember that that's from Debian actually publishing to mirrors, not from the upload
<cjwatson> the clasp source is still in incoming.debian.org
<cjwatson> oh, it's on ftp as well
<cjwatson> a little surprising it's not on LP now
<Laney> push could be an idea
<cjwatson> but given it's not, I'd expect it to arrive in the import that finishes around 03:40
<cjwatson> (UTC)
<cjwatson> unless the import starting at 21:10 UTC is slower than I've been led to believe, I guess
<cjwatson> I don't have easy access to the logs
<cjwatson> moving the import back an hour is probably an order of magnitude less effort than push mirroring, even if it's hacky :)
<Daviey> If you want it sooner, uploading with ~ubuntu1, then syncing out the package when LP knows about it is the best of all evils IMO.
<cjwatson> I doubt clasp is that urgent
<xnox> Daviey: if I had upload rights in ubuntu....
<Daviey> Encourages push to Debian first, avoids having an essential fakesync (different sigs).. and still a lower version allowing a sync to override
<cjwatson> I'd really prefer people not do that unless they have a damn good reason please
<cjwatson> uses buildd resources for minor benefit
<cjwatson> and it's easy to screw it up and end up requiring a fakesync in future
<Daviey> cjwatson: right, 'if it's urgent'
<cjwatson> *very urgent
<cjwatson> anyway, it looks like we can easily make the importer have considerably less latency, and I'll look into that tomorrow
<xnox> awesome =)
#ubuntu-release 2013-05-20
<stokachu> lol @ stoken
<davmor2> cjwatson: is this week a better one to discuss the secureboot issues on upgrading from raring to saucy?  did you want me to reinstall raring and try again? Was it just an unsigned kernel?  Is there some other issue?
<cjwatson> Honestly, you might be better off asking kernel folks
<cjwatson> But I suppose it's worth at least looking at the output of:  dpkg-query -W grub-efi-amd64\* linux-image\*
<cjwatson> PS this is the wrong channel
<davmor2> D'oh why did I think this was installer :( long day and it's only just begun
<rtg_> infinity, I'm not groking the problem here, nor can I reproduce it in my local chroot: https://launchpadlibrarian.net/140308235/buildlog_ubuntu-saucy-i386.linux_3.9.0-2.7_FAILEDTOBUILD.txt.gz
<infinity> rtg_: Probably has to do with the texlive mess Colin and I are currently unwinding.
<rtg_> infinity, ah. shall I just restart that build once you're done ?
<infinity> rtg_: Yeah.
<infinity> rtg_: (And you could reproduce it if you had proposed enabled, surely)
<rtg_> infinity, I thought proposed was bad news on saucy ?
<cjwatson> It is for users.  Builds have to have it.
<cjwatson> I can restart the build if you give me a pointer to the archive it's in.
<rtg_> makes sense
<infinity> rtg_: Running proposed is bad, building against it is somewhat necessary.
<cjwatson> My build chroots all have -proposed enabled, since otherwise it's impossible to do anything with transitions.
<infinity> cjwatson: https://launchpad.net/ubuntu/+source/linux/3.9.0-2.7
<infinity> (ie: primary)
<cjwatson> Aha
<cjwatson> Fine - I have a batch of stuff to retry later
<cjwatson> Right, well, I'm basically waiting for All The Builds now.  Time for a break.
#ubuntu-release 2013-05-21
<bdmurray> cjwatson: is there a reason queuediff doesn't use the API to get the .changes and debdiff files?
<cjwatson> The diff isn't exposed on the API yet
<bdmurray> I'm not find the changes_file off of package_upload either
<bdmurray> s/find/finding/
<cjwatson> changes_file_url
<cjwatson> in devel
<bdmurray> right, I see it is supposed to be there...
<cjwatson> But since we have to scrape for the diff at present it makes little difference
<cjwatson> I certainly think package_upload should be fixed to expose the diff
<bdmurray> I'm working on a tool to help with the review and accept process
<bdmurray> so it seemed like a good idea to use the API
<cjwatson> You'll need to extend the API first :)
<cjwatson> Note that there's an independent problem of lack of diffs for copies, which is harder: bug 851562
<ubot2> Launchpad bug 851562 in Launchpad itself "Diff's not available for sync's on +queue page like for regular uploads" [High,Triaged] https://launchpad.net/bugs/851562
<bdmurray> okay, thanks
<cjwatson> Certainly in general I'm all for burning HTML-scraping code with fire
<rtg_> infinity, please NEW linux-maguro in the saucy queue.
<ogra_> whee !
<rsalveti> the last one
<infinity> rtg_: These stupid names keep making me hungry.  Please package linux-saba for me, and serve it with umeshu and wasabi, kthx.
<rtg_> infinity, I think I'm done with fish for awhile
<xnox> If someone can please explain the two FTBFS on armhf/powerpc of https://launchpad.net/ubuntu/+source/qt4-x11/4:4.8.4+dfsg-0ubuntu10       I am all ears.  Is it simply ENOSPACE?
<TheLordOfTime> xnox:  i'm not sure, but does this answer?  "/usr/include/stdc-predef.h:39:1: fatal error: .pch/release-shared/QtCore: No such file or directory"
 * TheLordOfTime might be wrong, but that looks like a missing-file-during-compile problem
<infinity> xnox: I'm guessing bits that are meant to be autogenerated but fail to be?
#ubuntu-release 2013-05-22
<xnox> infinity: but they do look like they got generated correctly earlier in the build. *sigh* will poke it more on my panda tomorrow.
<ogra_> could someone let initramfs-tools-ubuntu-touch in from the NEW queue ?
<seb128> ogra_, you could have done an effort and use the current format for the copyright :p
<seb128> ogra_, NEWed
<ogra_> lintian didnt complain
<ogra_> thanks !
<seb128> ogra_, I'm not lintian, and I'm complaining :p
<seb128> ogra_, yw ;-)
<ogra_> :)
<xnox> ogra_: seb128 is better than lintian, because he is french =)
<ogra_> ++
<seb128> ;-)
 * xnox now wonders if lintian is mostly written by french or not as well
<Laney> queuebot silent again?
<plars> no images today yet?
<plars> infinity, cjwatson: ^
<cjwatson> Hm, I didn't get any failure logs
<stgraber> there are a lot of cron jobs running on nusakan
<stgraber> I wonder if they got stuck somehow
<cjwatson> Yeah, looks like stuck builders
<cjwatson> But across lots of arches, which is weird
<cjwatson> Usually it's just one machine that does its nut
<cjwatson> Earliest build there is XUbuntu
<cjwatson> Er, Xubuntu
<cjwatson> But http://people.canonical.com/~ubuntu-archive/livefs-build-logs/saucy/xubuntu/20130521/livecd-20130521-i386.out looks OK
<cjwatson> I'll ask ops
<stgraber> can't see anything in the logs (looked at kapok) that'd explain why it's stuck...
<cjwatson> The next build to start after xubuntu/saucy was mythbuntu/saucy, and that has no logs
<cjwatson> So probably stuck on a lock
<plars> thanks cjwatson
<cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/saucy/lubuntu/20130521/livecd-20130521-powerpc.out is the last powerpc build to get anywhere
<cjwatson> https://pastebin.canonical.com/91437/ for those who can see that
<cjwatson> root     24285  0.0  0.0   2360   752 ?        S    May21   0:00  |                   \_ /bin/sh ./auto/build
<cjwatson> root     24316  0.0  0.0   2140   492 ?        S    May21   0:00  |                       \_ tee binary.log
<cjwatson> Guess we need to try to reproduce locally
<cjwatson> I'll do a full upgrade and see what I can unearth
<cjwatson> plars: This may take a while.  Hope it's not urgent. :-/
<plars> cjwatson: just wanted to make sure you all were aware since we saw the images didn't get tested today
<plars> (because they didn't exist yet)
<cjwatson> Yeah, thanks for reporting, I hadn't noticed
<rtg_> is that why linux-maguro has no binaries ? https://launchpad.net/ubuntu/+source/linux-maguro/3.0.0-0.1
<rtg_> nm, just too stupis yet this AM
<Laney> that's just NEW: https://launchpad.net/ubuntu/saucy/+queue?queue_state=0&queue_text=
 * Laney gets 66 build failure emails(!)
<cjwatson> plars: OK, to keep you updated, this is bug 1182540.  I have fixes in progress, but they won't all be available until tomorrow.
<ubot2> Launchpad bug 1182540 in ubiquity (Ubuntu) "Daemon-suppression code in installer breaks new invoke-rc.d logic" [Critical,Fix committed] https://launchpad.net/bugs/1182540
<cjwatson> Laney: Yeah, I just killed a bunch
<cjwatson> I've disabled the saucy part of the crontab
<cjwatson> Given that LP package index imports are currently broken, I think I'd better upload debootstrap directly rather than waiting for a sync
<Laney> I thought they worked for <gdb
<cjwatson> Oh good point
<cjwatson> Alphabet convenience
<tumbleweed> erm, if someone wasts to kill that pypy armhf build, I know it can't succeed
<stgraber> cjwatson: let me know once we can build raring images again, I'll want to do a couple of test builds to test a cdimage change I just landed (post_qa support for multiple trackers)
<cjwatson> stgraber: YM saucy?
<stgraber> cjwatson: hmm, yeah :) Have been spending too much time in the cdimage testsuite it looks like (lots of raring in there ;))
<cjwatson> stgraber: It'll probably be tomorrow, but you could always test with the post-qa command
<cjwatson> Shouldn't need a full build
<stgraber> cjwatson: ah yeah, good point. I'm currently running a couple of precise test builds to test publishing of those but will do the rest directly with post-qa (and then go manually revert the changes in the tracker DB)
<stgraber> (in case someone notices and wonders, yes I'm building a zh_CN precise image, yes those are deprecated but it's my only production use case for the multiple tracker instance support)
<slangasek> stgraber: if that's the only use case, maybe it's fine to let that code wither and die?
<stgraber> slangasek: well, that specific code is just a small extra tweak on top of the code to support building multiple series so it doesn't really hurt us to keep it around especially as it's not entirely impossible that we may move some products to a separate tracker at some point
<slangasek> stgraber: well, ok; it just seems to me that if you're building a deprecated thing just to test the code that's only used for the deprecated thing, it would save effort to not do that :)
<stgraber> the change I'm testing essentially makes the code generic and drops the hardcoded "china-" that we had in the past and simply checks what tracker a product is published to (last column from the new qa-product file)
<stgraber> alright, code all tested, now to see if I can get that ported to the upstream qatracker python module instead of our local isotracker module (really need to get python(3)-qatracker packaged...)
<stgraber> oh, it actually uses the new isotracker.py from ubuntu-archive-tools which is a wrapper around qatracker.py (upstream python-qatracker), so it's already using the new code indirectly, good enough. I just want to avoid having the RPC implementation done twice but that's not the case.
<infinity> stgraber: queuebot's unhappy again.
<stgraber> stgraber@castiana:~/data/code/cdimage/cdimage$ CDIMAGE_ROOT=. bin/rebuild-requests saucy iso
<stgraber>  - Edubuntu DVD amd64 for Saucy => ('edubuntu', 'dvd', 'dvd', 'amd64')
<stgraber>  - Edubuntu DVD i386 for Saucy => ('edubuntu', 'dvd', 'dvd', 'i386')
<stgraber> cjwatson: ^ so that's what I'm getting from the tracker now, any recommendation on how to get from that to a running build? can I do that in pure python or should I use for-project instead?
<bdmurray> is queuediff often used with ppas?
#ubuntu-release 2013-05-23
<cjwatson> Ah, excellent, that's more like it
<cjwatson> Updated:                  117 (12.02%)
<cjwatson> thanks wgrant et al
<Laney> nice
<Laney> thought it'd be more
<cjwatson> Laney: You can just about see the effect in the graph at the bottom of https://merges.ubuntu.com/main.html, mind
<psivaa> cjwatson: infinity: No saucy dailies yet for today too. Will they be available later today?
<psivaa> xnox: ogra_: Laney: would any of you know if saucy images will appear later ^
<ogra_> no idea, i know there were issues yesterday
<ogra_> ask cjwatson, i think he cared for it
<psivaa> ok thanks
<Laney> psivaa: the cron jobs are still disabled although the relevant upload appears to be in saucy so I assume it can be re-enabled
<Laney> leaving it up to cjw though
<psivaa> Laney: ack, thanks
<cjwatson> Yeah, I didn't get round to turning them on this morning
<cjwatson> Sorting it out now
<cjwatson> Actually maybe I'll try it once before enabling the cron jobs
<stgraber> working on a similar SRU for lucid, I'll then ask for them to be reviewed in priority as this is currently preventing lucid and precise from running as containers on saucy (some kind of change in the 3.9 kernel caused the UDP checksum to be "optimized out" and so prevents dhclient from working with veth devices...)
<lool> cjwatson: sorry, two quick cdimage questions: 1) is it ok if I ask IS to install zip/unzip there (would like to make the two daily touch images rsync friendly) and 2) www.pre* seem to eat 360+ GiB, might be worth rm-ing if it's ok?
<cjwatson> 1) fine 2) it's almost all hardlinks
<cjwatson> so du is misleading
<lool> cjwatson: actually it acconted hardlinks properly
<lool> cjwatson: with out hardlinks each is 1T; I du-ed them together to get the 360G figure
<cjwatson> ah, well, I've removed them now in any case
<lool> cool
<lool> thakns
<psivaa> cjwatson: Reported bug 1183455 to account for oem smoke test failures of today's saucy images
<ubot2> Launchpad bug 1183455 in ubiquity (Ubuntu) "/home/oem/Desktop/oem-config-prepare-gtk.desktop is not present in the desktop images" [Undecided,New] https://launchpad.net/bugs/1183455
<cjwatson> Oh, I was going to re-enable the cron jobs, wasn't I
<cjwatson> ogra_: Do you mind if, probably tomorrow, I spend some time pulling /home/ogra/utouch-android/do-zip-android into the mainline cdimage code?  I really don't want to get into a situation where we have a bunch of local code running out of people's home directories
<cjwatson> It's really short so shouldn't take me long
<ogra_> cjwatson, well, i wanted to have that happening on the livefs builder originally
<cjwatson> That would probably be better, but anything is better than /home/foo in cdimage's crontab
<ogra_> we dont really need the tarballs so i wanted to have the zips directly on the builder
<ogra_> and that doesnt have the latest ubuntu/script stuff
<cjwatson> So, I'm happy to work on integrating either of those if you aren't already midway through doing so
<ogra_> bah
<cjwatson> Tell me which you'd prefer
<ogra_> *ubuntu-script
<ogra_> i havent had time for it yet and was actually waiting for the bionic toolchain, so feel free (i'm super busy with the container flip on the phone til end of the month anyway)
<cjwatson> psivaa: Right.  Will take me a while
<psivaa> cjwatson: ack
<ogra_> cjwatson, if you want to do it i'm fine with either implementation :)
<ogra_> what suits you best :)
<cjwatson> psivaa: Or maybe not - this is actually just a simple cdimage operator glitch
<cjwatson> Stale lock
<cjwatson> Just fallout from having to kill a bunch of builds
<ogra_> cjwatson, oh, note that if you want to do it in cdimage that nusakan doesnt have zip installed
<cjwatson> lool was going to get IS to fix that.
<ogra_> (which is why there is a zip binary in my script tree)
<cjwatson> And apparently somebody added it to cdimage's crontab without regard for that, anyway. :-)
<ogra_> no, i was evil :)
<cjwatson> I have no problem with zip and unzip being on nusakan, but it may not be the right approach as you suggest above.
<ogra_> right, i think its better to have it in a package
<cjwatson> That said, I can't put random unbuildable binaries in livecd-rootfs / live-build
<ogra_> btw, we need to set up sergiusens and rsalveti accounts on nusakan
<cjwatson> Remind me tomorrow, it's nearly dinnertime here
<ogra_> thats why i was waiting for the toolchain ;)
<ogra_> here too :)
<sergiusens> \o/
<lool> ogra_, cjwatson: zip/unzip is there now
<lool> I got mixed success on the zip work though; I need to dig deeper into it as the files got reordered in my manual attempts
<ogra_> lool, have a look in my home dir on nusakan, there is the whole stuff we currently use
<ogra_> lool, namely everything under utouch-android/
<lool> ogra_: sure, maybe we can look tomorrow
<lool> getting late for us  :-)
#ubuntu-release 2013-05-24
<stgraber> finally managed to get the lucid version of the patch working ^
<stgraber> so if some SRU team member is around, it'd be great if I could have those two dhcp package reviewed and let through to -proposed (dhcp3 in lucid-proposed and isc-dhcp in precise-proposed)
<stgraber> it's currently preventing containers of those two Ubuntu versions from getting an IP when running on a saucy machine. I'm told this is annoying for people doing LP dev on saucy ;)
<infinity> stgraber: I'll have a look right nowish.  Just those two releases?
<infinity> stgraber: The changelog history in precise is a bit goofy.
<stgraber> infinity: yeah, I think we had an SRU that was pushed to proposed and removed, so I couldn't just +1 on the version number...
<infinity> stgraber: Sure, I just assumed the 5.7 changelog would remain intact, instead of getting eaten in yours, but meh. :0
<stgraber> yeah, I didn't feel like figuring out where to grab the removed 5.7 package to copy its changelog entry ;)
<infinity> https://launchpad.net/ubuntu/+source/isc-dhcp/4.1.ESV-R4-0ubuntu5.7
<stgraber> right, there ;)
<infinity> No big deal.  This works.
<infinity> Yay, po cruft in the lucid upload.
<stgraber> was just about to mention that, I'm not sure where it's coming from, I certainly didn't touch any of it so I'm assuming that some magic debian/rules decided to shuffle the po headers around...
<infinity> I assume something in clean is doing it, yeah.
<infinity> I tend to call dpkg-buildpackage with -nc (making sure I'm in a clean copy first) by habit these days to avoid that sort of thing.
<stgraber> yeah, I guess I should start doing that too. It always annoys me when I have a perfectly clean diff in bzr and I end up with a bunch more crap in the final debdiff...
<infinity> It disturbs me that this is muscle memory: dpkg-buildpackage -i -I -rfakeroot -uc -us -S  -nc
<stgraber> ;)
<infinity> Pretty sure -rfakeroot has been the default for YEARS too, but I can't stop typing it.
<stgraber> cjwatson: ^ once that's done building you can try updating your lucid container to the -proposed version of dhcp3 and then drop that mangle rule, if the binary package LP will spit out matches my locally built one, that should give you working dhcp in your container
<wgrant> stgraber: Ah, thanks for fixing the dhcp checksum thing. I tried to get the patch working on lucid in Oakland but ended up deferring it.
<wgrant> I've just been using an ethtool workaround
<infinity> wgrant: Well, if you can make with the testing and verifying, that would be great then. ;)
<wgrant> infinity: Sure, if you promise to not comment on bug #225 again :)
<ubot2> Launchpad bug 225 in Launchpad itself "Search navigation and listing summary text are confusing." [Medium,Fix released] https://launchpad.net/bugs/225
<infinity> wgrant: Haha.  I got spammed too, served me right.
<infinity> wgrant: (Was due to a broken .changes in a -lowlatency SRU... *sigh*)
<wgrant> Aha
<wgrant> infinity: It works
<infinity> ScottK: Since you seem to have most recent context on #1109283, I'm leaving it to you. :P
 * ScottK wonders if he wants to know what that is.
<ScottK> Oh.  That.
<infinity> Probably not, but the bug log does invoke your name.
 * ScottK is comfortable with it where it is.
<ScottK> If their claims are accurate, they addressed my concern.
<cjwatson> Laney: so, Joachim's preparing a mass push of Haskell to unstable at the moment
<cjwatson> Laney: we're going to end up with that like it or not thanks to auto-sync; might we as well make sure to build a new ghc first?
<cjwatson> Since we'll end up rebuilding the world anyway
<Laney> I don't have a very good handle on how far ahead experimental is over saucy
<cjwatson> Not much
<Laney> we might get lucky with ABIs and not have to do much work
<cjwatson> That was the mini-transition at the start of this cycle - I synced us up
<cjwatson> I guess
<cjwatson> So I could just leave auto-sync alone and see what happens
<Laney> maybe let it happen and if it's huge then do a full one
<cjwatson> The blurbs stuff is all in haskell-devscripts and there are tight build-deps, it seems
<cjwatson> Joachim's reuploading every haskell package, it's not just copies, so we will end up with effectively a full rebuild although as you say we might get lucky and not have to *rebuild* stuff
<cjwatson> *again
<Laney> ah, wait, I see
<Laney> if we get ghc into saucy-proposed early we might get the transition for less cost
<Laney> if everything is going to be synced over anyway
<cjwatson> Yeah, that's what I meant
<cjwatson> I might have to temporarily stop auto-sync or something
<Laney> works for me
<Laney> of course we won't get as much help on build ordering as Debian does
<Laney> you can see why Joachim was motivated to implement some of that stuff :-)
<cjwatson> Yeah
<infinity> +1 to merging the new GHC and seeing what happens.
<cjwatson> It's a nine-hour build on armhf, so we'd definitely not be able to rely on it beating the next auto-sync.
<Laney> disabling it seems reasonable
<infinity> Shame about GHCi being disabled on armhf.
<cjwatson> I spent weeks trying to fix it; it was just too hard
<Laney> apparently the upcoming upstream series Fixes Everythingâ¢
<cjwatson> Laney: ho ho ho
<cjwatson> I'll believe it when I see it :)
<infinity> Laney: You mean 8.x, 7.8, or 7.6.betterthanwhatwehave?
<Laney> Milestone 7.8.1 according to http://hackage.haskell.org/trac/ghc/ticket/3658
<Laney> Igloo's your man on that one
<infinity> Yeah, he's a helpful sort.
 * infinity thinks it might be time for a nap.
<cjwatson> aha, texlive-doc was removed from unstable, that's why there was no upload transitioning it to new texlive
 * cjwatson processes that
<cjwatson> Hmm, I wonder if I just made texlive-base uninstallable
<cjwatson> Oops
<cjwatson> proposed-migration should sort it out in a cycle
<ogra_> oh sigh sigh sigh ...
<ogra_> http://paste.ubuntu.com/5696703/
 * ogra_ tries to package the latest phablet.ubuntu/com tarballl
<ogra_> 4.3M only for license data
<ogra_> and i dont really know what to do for the tons of binaries included in the tree
<ogra_> nobody will want to ever read the copyright file i'll assembel from these txt files
<ogra_> *assemble
<cjwatson> Foul
<ogra_> well, i guess i can shrink the whole a bit based on subdirs using the same license
<ogra_> but it will still be horrible to read
 * cjwatson uploads ghc
 * Laney fears
<cjwatson> As soon as I can squeeze packets round the side of dput I'll stop auto-sync until it's built
<cjwatson> wgrant: Are you able to extend http://qa.ubuntuwire.com/debcheck/ to cover saucy?
<wgrant> cjwatson: I think it is extended, but crashing due to multiarch
<wgrant> It's still running the pre-edos-debcheck codebase
<wgrant> From like 2006
<cjwatson> Ah, oops
<cjwatson> I guess I can get britney to tell me
<wgrant> Oh, and edos-debcheck itself is superseded now.
<cjwatson> Only in name, I thought
<wgrant> Indeed
<wgrant> cjwatson: Are you particularly attached to the mildly hideous per-pub changeOverride?
<cjwatson> wgrant: Well, I can guess why you're asking - what interface were you thinking of instead?
 * Laney gets a weird haskell-platform rejection mail
<cjwatson> Laney: my problem, dealing with it
<cjwatson> I'm working on a demote-to-proposed script and running into some stupidities in the copier
<cjwatson> You have to say include_binaries=True except when you mustn't
<wgrant> cjwatson: Giving an API a set of names and override changes, I guess. Batchier and less prone to corruption due to races
<wgrant> cjwatson: Oh?
<wgrant> Intra-archive copies should always fail without it.
<cjwatson> Unless there were never any binaries built for that source.
<wgrant> Hah
<cjwatson> In which case it fails with "source has no binaries to be copied" because OBVIOUSLY that's what I meant.
<wgrant> There's no reason for that check other than that it's probably not what you want
<wgrant> Except in cases like this
<cjwatson> include_binaries=True should be "copy any binaries that exist", IMO
<wgrant> I believe that check predates the current relatively pedantic build status checks
<wgrant> So it's probably reasonable to ditch it
<cjwatson> Wait, there's a strict_binaries param there ...
<cjwatson> Except that is randomly strict about other things beyond what the docs say
<cjwatson> Well, sort of
<cjwatson> Probably a red herring
<wgrant> Huh, is there?
<wgrant> Oh, that might have been added for the rather inventive IDS stuff
<wgrant> Yeah
<cjwatson> Yeah.  I think it's not what I want here.
<cjwatson> Just removing the check implies that it's possible to copy-with-binaries within the same series and archive even when everything's still building
<cjwatson> But that's probably actually OK
<cjwatson> ahahaha
<cjwatson> include_binaries=False:
<cjwatson> haskell-platform 2012.2.0.0ubuntu1 in saucy (same version already has published binaries in the destination archive)
<cjwatson> include_binaries=True:
<cjwatson> haskell-platform 2012.2.0.0ubuntu1 in saucy (source has no binaries to be copied)
<cjwatson> Laney: FWIW we need to make sure to sync haskell-devscripts before the deluge starts, too.  Have to wait for the next gina run before I can do that
<Laney> right, I was checking to see if it's been picked up
<cjwatson> Two and a bit hours
<cjwatson> It'll be well before ghc/armhf builds
<wgrant> cjwatson: Are we out of sync with dak?
<Laney> fair
<Laney> I'll be on trains by then though
<cjwatson> wgrant: I didn't think so
<Laney> heading up to beautiful Humberside
 * Laney nods towards xnox 
<cjwatson> 52         1,7,13,19  *   *   *   /srv/ftp-master.debian.org/dak/config/debian/cron.dinstall
<cjwatson> May 24 09:07:26 franck dinstall[15590]: Daily cron scripts successful, all done
<wgrant> So it takes ~75 minutes?
<cjwatson> Haha, two minutes after our mirror started
<wgrant> + mirroring..
<cjwatson> And yeah, ftp.uk needs time
<cjwatson> So indeed - I think we should probably shuffle back an hour
<wgrant> So we might do well to push it back like half an hour
<wgrant> Or an hour
<cjwatson> http://ftp.uk.debian.org/debian/project/trace/ says it synced at 09:22
<xnox> Laney: ah..... =)))))
<wgrant> It also probably wouldn't hurt to mirror every 30 minutes and run gina if the archive has changed
<wgrant> But just pushing it back an hour works
<cjwatson> Wait, but surely our cron times are UTC
<wgrant> They should be nowadays
<cjwatson> And we mirror at 10:05 and start gina at 10:10
<wgrant> Ah
<wgrant> So it's about right
<cjwatson> So if franck is on UTC too it should be fine
<cjwatson> Which at least the log file allegedly is
<cjwatson> mirror every etc.> yeah, I've been suggesting that at six-monthly intervals for a while ;-)
<cjwatson> e.g. https://bugs.launchpad.net/launchpad/+bug/798611/comments/5
<ubot2> Ubuntu bug 798611 in Launchpad itself "Package Auto Sync seems to get ahead of +localdiff calculation" [High,Triaged]
<wgrant> The extension of that is then to rewrite the runner bits of gina so that it can diff the LP and disk states in <30s like it should be able to..
<cjwatson> Well, that too, but the thing that drives it could just check timestamps in project/trace/ or something
<wgrant> Yeah
<cjwatson> haskell-devscripts 0.8.16 was accepted at 09:33, so it's not a surprise that it would have to wait for the 13:52 dinstall
<Laney> Could we not get a push mirror so that this stuff happens when triggered?
<bdmurray> I'm looking at the SRU fixing bug 1056545 and it hasn't been positively verified, but there are no incidents of the crash with the version from -proposed on errors.  Does that seem like enough to mark it v-done?
<ubot2> Launchpad bug 1056545 in Session Installer "session-installer crashed with AlreadyCalledDeferred in callback()" [Undecided,Incomplete] https://launchpad.net/bugs/1056545
<bdmurray> infinity, slangasek: ^^ ?
<infinity> bdmurray: Did you have a reproducer for it?  It would be nice to actually test it meaningfully.
<infinity> bdmurray: For an "everyone uses it" desktop component, I'd be happy enough with the "silence is golden" idea that errors is giving us the whole story (like, say, a compiz crash no longer happening), but it's equally possible in this case that people running -proposed just aren't doing the thing(s) that trigger this bug.
<phillw> Hi, sorry about this, as I am sure I have asked before.. is the usage of xdg-open no longer suggested for 'quick-links' such as those on "Easy Install" https://help.ubuntu.com/community/RestrictedFormats
<bdmurray> infinity: I may have had a reproducer for it, I'll look again
<infinity> phillw: That sounds more like a -devel question.
<phillw> infinity: thanks :)
<slangasek> bdmurray: so you did some scripting around notifying of unverified packages that are subject to removal... is there anything that I can use for selectively removing packages that failed verification?
<slangasek> (clearly, running remove-package and commenting on the bug by hand is too many steps for me :)
<bdmurray> slangasek: no, I don't have anything for that
<slangasek> ok
<ScottK> slangasek: Maybe bdmurray could whip up a script that tracks SRUs unverified after 30 days by uploader and decline further SRUs from such people until they verify an equal number of other people's SRUs.
<slangasek> hmm!
<ScottK> The moral of the story would be don't upload SRUs you don't have a plan to get verified.
<slangasek> yep
<infinity> ScottK: My plan usually involves "wait for a week or two for bug submitters to verify, and if they don't get around to it, do so myself".
<infinity> ScottK: The latter part sometimes takes a gentle reminder from someone, though. :/
<ScottK> Right, so the new rule would be motivation to be more organized.
 * infinity has certainly been guilty of leaving his own SRUs in proposed too long.
<infinity> Though, I don't feel too bad about leaving glibc in proposed for ages, cause it means it gets well-tested.
<infinity> It just also means it gets superseded by security updates over and over again. :P
<ScottK> There are some packages for which a longer wait is a good idea.
<cjwatson> OK, ghc has built and published everywhere.  Unleashing the auto-sync hounds
<infinity> OH GOD NOW.
<infinity> s/W//
<infinity> Thanks for inverting my meaning there, fingers.
<infinity> Jerk fingers.
 * infinity does some chroot updating.
<cjwatson> Updated: 373.  *clang*
<cjwatson> (Well, not clang.  But.)
<infinity> scping new chroots now to cope. :P
<infinity> And look, another acl2 that will inexplicably fail on Ubuntu and not Debian.
<cjwatson> It's Lisp, what do you expect
<infinity> I expect not to care, except that I keep seeing it at the top of the list, and it irks me.
<infinity> If it was zcl2, I could blissfully ignore it.
<cjwatson> I keep confusing it with acl.
<cjwatson> I WONDER WHY.
<slangasek> setfacl2confuse
<infinity> cjwatson: More fun because the current version of ACL is 2.
<infinity> (Though the SOVER is 1)
<cjwatson> At least these uploads do seem to be aimed at disabling the tests that are failing for us ...
<cjwatson> Dunno whether Camm's looking at Ubuntu build logs or whether they failed somewhere in Debian too
<infinity> Dunno.  We'll find out in three days, I guess.
<cjwatson> In fact, https://buildd.debian.org/status/fetch.php?pkg=acl2&arch=i386&ver=6.1-2&stamp=1369251882 doesn't look that dissimilar to our failure
<infinity> I suspect some of my more nightmarish buildd confusions will just go away when I have ARM buildds with 4G of RAM and fast disks to swap to.
<infinity> My current confusion is "why am I on hour 19 of a build that takes 6 hours in Debian on slower hardware?"
<infinity> I'm not sure if I should blame g++-4.8's memory usage, or the fact that we're building with parallel=2, but either way, it's bad.
<infinity> Why does Haskell get all the good package names?  I knew about "happy", this is the first time I've noticed "frown" too.
<cjwatson> BTW I expect a bunch of these builds to fail; feel free to ignore them and I'll go through and retry them in dep order over the weekend
<cjwatson> y-u-no-validate is pretty good
<infinity> Hahaha.
<infinity> I saw that on the last transition, I think.
<cjwatson> Though sadly it's a XUL extension so presumably slated for removal somewhere
<infinity> I guess it's proof that the developer community keeps getting fresh blood if we have packages with 4chan-meme naming schemes.
 * infinity considers rewriting fail2ban in C and calling it something like "umadbro".
<infinity> Can even claim I wrote it originally for Ubuntu, hence the "u" name.
<cjwatson> Thanks for the chroot updates.  Bed, I think
<infinity> 'Nighty night.
#ubuntu-release 2013-05-25
<NCommander> infinity, cjwatson: can someone renew me in ~ubuntu-release?
<ScottK> Do you need to be in -release?
#ubuntu-release 2013-05-26
<TheDrums> stgraber: Hello, so it would appear pastebinit uses lang in some places, and format in others, so pastebinit -f doesn't actually do a thing.
<TheDrums> http://paste.openstack.org/show/5QUGMGTfjlzTENk0dCR1/ works, but isn't quite right python code wise.
<stgraber> TheDrums: I think you misread pastebinit's code, pastebinit itself never uses 'lang', some of the pastebins do in their html form, but that's why you usually see "format = lang" in the [format] section which tells pastebinit to use the html "lang" field to store the format
<stgraber> TheDrums: it's however not possible that some of the config files are wrong ;)
<stgraber> TheDrums: *impossible
<stgraber> TheDrums: look at paste.debian.net.conf for an example where the pastebin uses "lang" as html form field and is properly mapped to pastebinit's "format" (I just tested and "pastebinit -f python -b http://paste.debian.net <some file>" gives you python syntax highlighting)
<TheDrums> stgraber: Yeah, I may have had my head on backwards when I looked at the main program there. I knew what the config files did there, but was wondering why it wasn't working with -f, but did work if I changed the default in pastebin config.  Sorry about that.  (Clearly had it backewards as it classified the program as being off and config right. :P )
<TheDrums> (I, of course, used openstack, but couple others seem off as well.)  Thanks for that.
<knome> could somebody approve https://blueprints.launchpad.net/ubuntu/+spec/topic-saucy-flavor-xubuntu for saucy so it'll start showing up in status.ubuntu.com? also, where are we regarding giving flavor leads such cow powers? :)
<infinity> Looks approved to me...
<knome> Series goal: Proposed for saucy
<infinity> Oh, for saucy.
<knome> as i said. :)
<infinity> Accepted.
<knome> ta
<knome> also, do we seriously have to use the other-s-xubuntu-blueprintname naming?
<knome> would xubuntu-s-blueprintname do as well?
<infinity> Not sure what permission structure that lives under, but it's likely more of an "LP permissions are whack" technical issue than anything social, FWIW.
<knome> this has been discussed before, i'm just quite not certain what the outcome was.
<infinity> As for the naming thing, you might want to ask someone who hacks both summit and status (maybe cjohnston?) to see what magic is needed, and why.
<infinity> knome: My guess is the permissions are tied to ubuntu-drivers, as so many random permissions are, but I'll bring it up with my massive team of two people and see if there's anything we can do for flavors that's bordering on sane.
<knome> from my understanding, as long as we add all our blueprints as dependencies for that umbrella blueprint and they are accepted to saucy, we should be fine
<infinity> knome: But for now, I'm happy to approve crap if you bring it to me. :)
<knome> infinity, thanks, and thanks :)
<knome> infinity, technical issues aside, would you be fine with the new naming scheme?
<infinity> knome: I'm honestly not picky about how people choose to name their blueprints at all, so it's entirely about if it causes technical/tracking issues for any of the tools (hence the suggesting to ask cjohnston about it before you change anything).
<infinity> knome: Aesthetically, flavor-release-thing makes perfect sense to me, as it does to you.
<knome> infinity, okay, thanks. i'll go with that and see if it turns up. you can always rename.
<infinity> knome: FWIW, I think Ubuntu has switched to naming blueprints after the month they were written, rather than the release they're targetting.
<infinity> knome: See, eg https://blueprints.launchpad.net/?searchtext=foundations-1305
<knome> aha. that doesn't make sense for us
<knome> but good to know
<infinity> knome: Which makes some sense, as you can retarget them later without them seeming silly in retrospect, I guess.
<infinity> (I probably still have some -p- and -q- blueprints I should have retargetted instead of abandoning and rewriting, for instance)
<knome> sure... but isn't that the same to rename to a new release? :)
<infinity> Well, renaming shouldn't happen, IMO.  As it breaks links to the blueprint, etc.
<infinity> So, this just encodes that it was written in 1305, but doesn't encode the target.
<infinity> Then again "it was written for -s-" is about as useful to know, so whatever. :P
<knome> oh right.
<knome> i see the point
<infinity> At the end of the day, it's all meaningless faff if we make sure the tracking tools all just follow the "approved for series" bit, and ignore names entirely as meaningless.
<knome> yeah
<infinity> But I think status curently has some silly notions about the names being meaningful.  I believe there was work being done (or already done) on tearing that logic out.
<knome> infinity, went ahead and proposed several blueprints for saucy (xubuntu-s-*). they're all dependencies for https://blueprints.launchpad.net/ubuntu/+spec/topic-saucy-flavor-xubuntu
<infinity> knome: Approved.
 * knome bows
#ubuntu-release 2014-05-19
<cjwatson> psivaa: Before you ask :-), yes, I'm looking at the across-the-board server/desktop image failures
<cjwatson> I expect that's due to the new syslinux
<cjwatson> Although that's only in -proposed, so maybe not ...
<psivaa> cjwatson: ack, thanks. saw the failure during the weekend could not look into see if there is any issues on our side
<cjwatson> mm, the failure predates the new syslinux
<infinity> cjwatson: I self-accepted my grub2-signed SRU up there.  Figured it was a no-brainer.
<cjwatson> Yeah, no problem
<infinity> cjwatson: (After seeing smb, who had -proposed enabled, get his signed grub torn out on upgrade :P)
<cjwatson> Would've done but you beat me to it
<cjwatson> (accepted, I mean)
<infinity> cjwatson: Things like this definitely make a solid argument for "we really need britney gating SRUs too".
<infinity> cjwatson: Cause if no one had noticed, we might have released with the skew.
<cjwatson> Yep, no argument there
<infinity>  /win 250
<infinity> Erm.
<infinity> Also, argh, I'm still auto-voiced.
<infinity> cjwatson: Do you remember what you did to ChanServ to make that happen, and can you reverse it? :P
<cjwatson> will do
 * apw has become quite attached to your yellow +
<infinity> I thought devoicing myself via chanserv last time I noticed would be enough, but apparently there's some extra trickery afoot.
<infinity> Or, I'm stuck being voiced forever.  I dunno. ;)
<cjwatson> Should stick now (I told chanserv about it first)
<infinity> Ta.  We'll see the next time I lose connectivity.
<cjwatson> psivaa: Hm, it actually installs just fine locally.  The syslog (https://jenkins.qa.ubuntu.com/job/utopic-server-amd64-smoke-default/19/artifact/log/utah-23211.syslog.log/*view*/) shows that the installer stops because it's prompting whether to unmount an active partition on /dev/vda.  Has something changed in the testbed setup?
<cjwatson> Not sure whether desktop is the same thing; http://jenkins.qa.ubuntu.com/job/utopic-desktop-amd64-smoke-default/20/artifact/log/utah-23213.syslog.log/*view*/ kind of just stops
<psivaa> cjwatson: the host was upgraded from precise to trusty is the change that i know of
<psivaa> cjwatson: the host where the tests run i mean
<cjwatson> psivaa: Could be, yes.  Can I kick this back to you folks for now, since the image itself looks OK to me?
<psivaa> cjwatson: yes, thanks for looking at it. i'll try to look into it and ask doanac to look at it if i can't
<cjwatson> Thanks
<michagogo> infinity: Why wait to lose connectivity? Why not just /cycle?
<michagogo> (but yes, your flags now appear to be +Aiostv, so you shouldn't be autovoiced)
<stgraber> Laney: the extra space in the name of the product in qa-products will cause a failure to publish on iso.qa.ubuntu.com, you probably want to fix that
<Laney> I want to fix all things :)
<Laney> well spotted
<cjwatson> Laney: also typo "ubuntu-deskto-next"
<Laney> got it
<psivaa> cjwatson: so jfyi, the issue in the desktop/server installations is that there is a utah bug (bug #1199349) hitting us because the host is trusty. we should workaround that and get the tests going soon
<psivaa> bug #1199349
<cjwatson> Got it, thanks
<psivaa> ty :)
<cjwatson> The debian-installer/exit/poweroff workaround won't work with desktop, FYI
<cjwatson> (Also doesn't seem desperately related to the logs I saw, but I may be missing something)
<psivaa> yea, the logs indicate that /dev/vda is mounted because it was the second round of installations in the loop
<cjwatson> Ah, right
<cjwatson> Makes sense, obscure to track down :)
<psivaa> cjwatson: yea, mislead us for a bit :)
<psivaa> cjwatson: is there an equivalent preseed line for the above, btw?
<psivaa> for desktop that is
<cjwatson> No.
<cjwatson> Actually, maybe ubiquity/poweroff would do it
<psivaa> cjwatson: ack, thx. let me try that
<cjwatson> ubiquity ubiquity/poweroff boolean true
<psivaa> ack
<jpds> Can someone poke ima-evm-utils out of NEW?
<bdmurray> for the record I'm updating the meta-release files with quantal as unsupported
<infinity> bdmurray: Ta.  That's a lie from LP's POV until I close the release (which I'm doing after the last kernel goes in, since we already took the effort to spin it).
<infinity> bdmurray: But from the "do we support it anymore?" POV, that's correct, so thanks. :)
<rcj> stgraber, Would you have a few minutes to talk about the SRU in bug #1275656.  This is regarding the port of trusty's open-vm-tools to precise as a new package for HWE support
<rcj> The packages have been uploaded already.
<stgraber> rcj: not right now, I'm about to head to bed here (temporarily in Europe before the Malta sprint next week)
<rcj> stgraber, np.  Thanks for the reply.
#ubuntu-release 2014-05-20
<xnox> I download http://cdimages.ubuntu.com/daily-live/current/utopic-desktop-amd64.iso and i get sha256 checksum failure. (does not match SHA256SUMS)
<cjwatson> gosh, that's impressive
<cjwatson> broken on the master - how on earth did that go wrong
<xnox> ok, i thought maybe just the wire-tap wonky on my connection =)
<xnox> (edward snowden interview on TED was funny)
<stgraber> c960526985ce357b51feb961d4c80cd9ce060ddde43d34ed06de5dbb5080a2d3  www/full/daily-live/20140520/utopic-desktop-amd64.iso
<cjwatson> I'll force a rechecksum for now
<stgraber> so SHA256SUMS for current contains the checksum of 20140520 but the symlinks points to 20140515
<xnox>  /pending/ is all correct.
<cjwatson> yes, 20140515 and 20140520 are fine in isolation
<stgraber> do we have locking to prevent a race between a new build and jenkins marking a new image as current?
<cjwatson> there's no race there
<cjwatson> mark-current from ordinary builds won't update things that are expected to be updated by jenkins
<cjwatson> hm, I guess actually there is a possible race
<cjwatson> might be worth a lock there, though it seems very rare, can somebody file a bug?
<cjwatson> xnox: should be fixed nowish
 * stgraber volunteers xnox 
<xnox> stgraber: i can honestly say, i did not touch/code any components involved in all of this =)
<xnox> cjwatson: stgraber: are trusty dailies not enabled? or am i just failing to find them?
<xnox> i am expecting something like http://cdimages.ubuntu.com/trusty/ but that's 404
<xnox> cjwatson: daily-live/current - all is good. ubuntu-server/daily/current still fails verification.
<xnox> same issue?!
<cjwatson> They aren't enabled right now
<cjwatson> Since we're still building precise, I'd kind of like to wait until the LP livefs code is in place before starting that, if possible
<bdrung_work> ScottK, can you copy ifupdown for the other releases besides trusty?
<cjwatson> (BTW the canonical hostname is cdimage.ubuntu.com)
<xnox> cjwatson: ack.
 * xnox wishes to know how to unteach my browser history....
<doko> xnox, https://launchpadlibrarian.net/175890344/buildlog_ubuntu-utopic-amd64.autopilot-gtk_1.4%2B14.04.20140107-0ubuntu3_FAILEDTOBUILD.txt.gz
<xnox> doko: yes, there is a better fix by pitti (either MP or upload, not sure)
<xnox> doko: https://code.launchpad.net/~pitti/autopilot-gtk/update-tests/+merge/220075
<pitti> I prodded the AP guys about landing it; I was promised "this week"
<pitti> if it becomes a blocker, I can also upload directly and then we just use the MP to sync back bzr
<doko> well, gcc-4.9 will take a while to build, but not more than 8 hours
<Laney> cjwatson: did you want to review my cdimage MP some more?
<Laney> that reads like a prod to do it now - I meant it to read as a question :)
<Laney> ah, thanks
<cjwatson> Laney: done anyway.  one mistake I noticed after merging - "daily" should've been "daily-live", but I just made it a wildcard since there's no reason to limit it
<Laney> oh yes, in default-arches
<cjwatson> where do the seeds live?
<cjwatson> and does this need any debian-cd handling?
<Laney> inside ubuntu-touch.utopic
<Laney> and I'm not sure, how do I answer that question?
<cjwatson> is the image an ISO?
<Laney> yes
<cjwatson> right, then it will need some more work
<cjwatson> let me see
<Laney> Happy to look given pointers
<cjwatson> I've done the boring and fiddly debian-cd bits
<cjwatson> but we need to educate this about seed locations
<cjwatson> Laney: I think you need something in lib/cdimage/germinate.py:Germination.seed_dist
<Laney> Okay, it wasn't clear how this all fit together
<cjwatson> Cases where one flavour is embedded in another's seed collection are exceptional and seed_dist needs to be told about those
<cjwatson> Laney: Also I suspect that this flavour needs universe enabled, so add it to the list of flavours that have CDIMAGE_UNSUPPORTED set to 1 in lib/cdimage/build.py:configure_for_project
<Laney> I see, touch wasn't in seed_dist because it fits the default case
<Laney> I've just added a branch for ubuntu-desktop-next â ubuntu-touch
<cjwatson> Also touch is simpler than this because it doesn't build an ISO
<Laney> does it need to know that we're using "desktop-next" within ubuntu-touch?
<cjwatson> Something like ubuntu-gnome is probably a better template
<cjwatson> Err is there any chance that you could harmonise the seed names instead?
<cjwatson> list_seeds is roughly what controls all this
<cjwatson> (lib/cdimage/germinate.py)
<cjwatson> In fact pretty much the whole GerminateOutput class there
<cjwatson> It's probably mainly the ship-live seed that matters
<cjwatson> We're going to need at least some things in ship-live, such as grub-efi/grub-efi-amd64-signed
<cjwatson> So copy that seed over from ubuntu.utopic and cut it down as you see fit
<cjwatson> Given that the desktop-next seed is in a different seed collection, is there any reason not to just call it desktop?
<cjwatson> That would be easier to cope with
<Laney> Sorry this is a bit opaque to me currently
<Laney> I was following the name of the project
<cjwatson> OK, if you don't have a good reason just rename it to desktop :)
<cjwatson> We're also going to need a Launchpad change to make it generate tasks for the ubuntu-touch seed collection
<Laney> ship-live> can we just use the ubuntu one?
<cjwatson> You can probably just copy it
<cjwatson> Can't use it directly from ubuntu.utopic because the seed inheritance would be all wrong
<cjwatson> For Launchpad, you'll want to change cronscripts/publishing/cron.germinate and add ubuntu-touch to the FLAVOURS list
<cjwatson> I don't think there are any meaningful tests for that but it doesn't much matter
<cjwatson> That will bloat up Packages a bit more with the other touch tasks, but that's probably a drop in the ocean and arguably they should be there anyway
<cjwatson> Is that enough to be going on with?
<Laney> I'll see what I can do, not confident I'm going to get the germinate part in cdimage right first time but we'll see
<cjwatson> The best way to make it simple is to have the seed collection as much like others as possible
<cjwatson> So it's probably enough to rename desktop-next -> desktop and add ship-live, and the associated STRUCTURE tweaks
<cjwatson> I don't mind if it goes wrong a couple of times in production and we need to rerun :)
<Laney> In ubuntu.utopic/STRUCTURE ship-live inherits from boot and live
<Laney> do we need to take care of that here?
<cjwatson> Probably, yes
<cjwatson> You need a live seed because otherwise there's no way to avoid having the installer still exist on the installed system
<cjwatson> boot is in platform.utopic so you don't need to copy it (unlike live), but you probably do want to mirror ubuntu.utopic's STRUCTURE inheritance for the relevant seeds as closely as possible unless you enjoy debugging thoroughly obtuse bits of germinate
<ScottK> bdrung_work: I'll get to the other releases.  I only had time for trusty last night before I went to bed.
<ScottK> bdrung_work: Done.
<bdrung_work> ScottK, thanks
<sergiusens> can someone please take a look at golang-udm (source) in the utopic queue?
<rcj> stgraber, Is now a better time to look at the SRU in bug #1275656?  This is regarding the port of trusty's open-vm-tools to precise as a new package for HWE support
<stgraber> rcj: yep, I'm around now
<rcj> stgraber, great.  This is the package we spoke about in person.  I tried to capture everything in the SRU template but I'm sure there will be questions.
<stgraber> rcj: reading the bug report now
<stgraber> rcj: I think I'd have preferred the prefix be -lts-trusty to be in line with what's done for the kernel, the X stack and openvswitch but since there won't be any further backports, it's not critical
<rcj> stgraber, I didn't use that because it would work with the the saucy hwe kernel as well.  I thought that trusty was in early test and wouldn't be supported until 12.04.5.
<stgraber> well, the trusty X stack also works fine with the saucy kernel :) I usually assume the -lts-X to simply be an indication of the source of the package more than a requirement that they all be installed together
<rcj> stgraber, ah, good to know.
<stgraber> but anyway, it really doesn't matter this time around since it's just a single backport and we won't be backporting from utopic to precise
<rcj> sure, but I'll keep it in mind for the future
<stgraber> rcj: so I assume you already test built all of those locally, made sure that installing the -hwe packages on a machine which already has the non-hwe bits work fine and that upgrading a machine with those -hwe to trusty works with your updated trusty package?
<rcj> Yes.  Tested each of those scenarios.
<stgraber> rcj: ok, so one problem with the precise backport is its version number. You should upload with something like ~precise1 as a prefix to avoid the case where we need to fix a bug in open-vm-dkms-hwe in precise, therefore bumping the version and as a result end up with binary packages that have an higher version number than those on trusty (breaking the transition)
<stgraber> (when a binary is moved from one package to another as is the case here with your transitional package, the version of the new source package must be higher than that of the old one for an upgrade to happen)
<rcj> stgraber, so '2:9.4.0-1280544-5ubuntu6~precise1', correct?
<stgraber> yep
<rcj> okay, I can fix that.
<stgraber> I'm taking a quick look at the source too to see if there's anything else that should be fixed at the same time
<stgraber> rcj: so the debdiff from the precise hwe to trusty is: http://paste.ubuntu.com/7492904/
<stgraber> quickly going through it, there appears to be some missing conflicts
<stgraber> unless it's indeed possible to co-install open-vm-tools-desktop and open-vm-tools-hwe-desktop for example
<rcj> stgraber, that's the correct debdiff.  I'll fix that and figure out why I didn't catch that in testing
<stgraber> rcj: cool, I'll reject what's in the queue, let me know when you have an updated package uploaded. (Note that I'm not working the rest of the week, so you may want to catch someone else if you don't want to wait until next week)
<stgraber> rcj: apw pointed out in private messages that ~precise1 is a suffix not a prefix, though you apparently assumed as much since your proposed version string was correct :)
<rcj> stgraber, thanks for the review.  I'll get this fixed up.
<cjwatson> infinity: FYI, between didrocks and I, I believe we now have it so that people will be notified if there's some kind of error from the async copy job when they publish a package from the CI Train.
<didrocks> cjwatson: I need to dedicate some time to do the modification, but I'll before EOW
<cjwatson> didrocks: I thought you already did
<cjwatson> I wasn't highlighting you to request that you did anything :-)
<didrocks> not that one, only the assigning to landers that we discussed on thursday and friday
<cjwatson> Oh, right
<didrocks> but not about the async copy
<cjwatson> Well, at least a real person gets the mail now, even if it's the wrong real person
<didrocks> yeah
<didrocks> if it's a rejection, not if the async job is stuck or anything (we need someone to ssh to the machine for now)
<didrocks> I'll expose some logs, just need to find what level is suited to append to a file
<cjwatson> Hm, rejections might be a different matter
<cjwatson>             # This possibly should be sending a rejection email but I
<cjwatson>             # don't think we need them for sync rejections.
<cjwatson>             return
<cjwatson> Thanks, whoever wrote that
<didrocks> oh, yeah, as it's a syncâ¦
<cjwatson> I was looking at actual errors or OOPSes
<rcj> stgraber, I'll make the change to -lts-trusty as well with this.  Is there a preferred naming for this... open-vm-tools -> open-vm-tools-lts-trusty, but for open-vm-tools-dkms I used open-vm-tools-lts-trusty-dkms.  Any preference against the -dkms suffix after -lts-trusty?
<stgraber> rcj: looking at our existing examples (X stack), we currently always put the -lts-trusty after the normal package name so it'd be open-vm-tools-dkms-lts-trusty but I'm not too attached to it personaly so whatever
<mlankhorst> yeah except for -dbg :p
<rcj> stgraber: okay
<rcj> stgraber, I'll make sure that -lts-trusty comes last on all of the packages
<rcj> stgraber, re-reading that.  -dbg must come last. right?
<stgraber> rcj: yeah
<mlankhorst> I did that just in case, to keep symmetry
<rcj> stgraber, mlankhorst; thanks.  I'll clean this up to make it sane and consistent.
<rcj> stgraber, and when you asked about the missing conflicts I was forgetting that those packages don't exist in the precise open-vm-tools so that's deliberate.
<mlankhorst> rcj: do you want to add those packages to xorg-lts-transitional perhaps? :p
<mlankhorst> in trusty
<stgraber> rcj: ah, ok, makes sense then, sorry I didn't check for that particular case.
<rcj> mlankhorst, I don't believe so.  This package backport enables some additional guest customizations when running in a vmware vCHS host environment.  It needs a 3.9 or later kernel but doesn't relate to anything in the X stack.
<rcj> mlankhorst, the backport is to support that env for cloud images and otherwise I would rather that users need to install it manually so that they know what they're getting with this.
<mlankhorst> rcj: xorg-lts-transitional is a package in trusty, and used when upgrading from precise to trusty
<mlankhorst> and contains dummy packages with epoch 3 (bigger than anything in the xorg stack) so all the xorg lts-* packages get upgraded to the unrenamed xorg packages :)
<rcj> mlankhorst, I'm confused as to what it gets me for open-vm-tools?  They would be upgrades to open-vm-tools in trusty per the packaging changes I'm making for that package.
<rcj> typo..  The precise packages would be upgraded to open-vm-tools in trusty per the packaging changes I'm making for that package.
<mlankhorst> ok
<marrusl> Hello.  Anyone happen to know when the trusty X stack is expected in -proposed?
<marrusl> precise-proposed
<mlankhorst> it's in NEW, just pending review
<marrusl> thanks mlankhorst
<sergiusens> slangasek: hey, do you mind looking at golang-udm? We uploaded it directly instead of through the train since the changelog it created for the new package didn't look that nice
<sbeattie> Hi, is there a reason the i386 iso image 20140520 for ubuntu-desktop hasn't been promoted from pending/ to current/ but the rest of the images have been? (Also, partially promoting images like this breaks the checksum files)
<cjwatson> sbeattie: Thought I fixed the checksums this morning, and it isn't supposed to break them, we think it might be a race
<cjwatson> sbeattie: The amd64 and i386 images go through automatic testing before they're promoted to current/; the others don't have automated testing set up so they go straight through
<cjwatson> (autotesting was the entire point of the pending/current split)
<cjwatson> sbeattie: https://bugs.launchpad.net/utah/+bug/1199349 has been blocking autotesting
<cjwatson> And I see that http://ci.ubuntu.com/smokeng/utopic/desktop/ shows a pass on amd64 now which is probably why only i386 is held back now
<cjwatson> So yeah, I see that the i386 checksums are broken again.  We need to figure out what's causing that, since now I don't buy the race theory any more
<sbeattie> cjwatson: thanks. It's the broken checksum issue that made me ask.
<cjwatson> (but I have to run, so not right now)
<rtg> I uploaded a utopic package (openipmi) that should also be in trusty. is it sufficient to request a pocket copy, or should I futz with the trusty version and re-upload ?
<infinity> rtg: If you uploaded to utopic first, we won't copy it backward.
<infinity> rtg: So, yes, if it's an SRU we should have, please SRU it in the usual fashion.
<rtg> infinity, ok, I'll swizzle the version and SRU it.
 * rtg should have done trusty first. oops.
<slangasek> we're far enough along that two uploads are preferred anyway
<slangasek> it's just that we *never* copy backwards, whereas we *sometimes* copy forwards
<slangasek> (except, er, for shim)
#ubuntu-release 2014-05-21
<lool> hey, excuses say fakeroot in utopic-proposed is waiting for the bzr builddeb autopkg to pass, if I click on the public link it says it passed yesterday; is the link broken between the two?
<cjwatson> lool: There's some occasional timing problem there, but I've observed that retrying the test seems to clear it up, so I've requested another build
<lool> thanks
<mlankhorst> infinity: ping?
<mlankhorst> can you review the xorg-lts-stack?
<Trevinho> Hi, any news on the status of the unity package that is SRU queue?
<rcj> arges, Can you review/upload the patches in bug #1275656.  Minor version and naming change.  Rest was good.
<rcj> rest was good as far as stephane was concerned yesterday.
<arges> rcj: yea i think that's a good call on his part
<zul> can someone review the pending Nova SRU please?
<Trevinho> cjwatson: ^
<cjwatson> Not now sorry
<cjwatson> (Meeting then EOD)
<Trevinho> cjwatson: ok, np
<Trevinho> infinity: maybe? :) ^
<xnox> dh-php5 used to be shipped as part of php5 package, but now is split out to be separate.
<xnox> hence the components missmatches. Do I need M.I.R?
<ogra_> splits dont need MIRs iirc
<ogra_> (but you will get stuck in binary NEW)
<xnox> i think it got NEWed already, hence components missmatches, rather un-installable.
<infinity> xnox: Which package used to provide dh-php5?
<infinity> Ahh, php5-dev.
<infinity> Yeah, just promiting that wholesale, then.
<xnox> infinity: ta.
<robru> can I get somebody to NEW signon-plugin-oauth2? thanks
<robru> oops, I mean signon-apparmor-extension
<bdmurray> slangasek: would you mind looking at bug 1316841 / apport for early release in trusty-updates...
<slangasek> bdmurray: released
<slangasek> bdmurray: btw, is "late resume:LENOVO 0831CTO:1.23" the full text of the duplicate signature?  It seems to me that over time you may have multiple causes of suspend/resume failures on a single hardware/firmware combo
<slangasek> so this may lead to false bucketing
<slangasek> (not an argument against releasing this right now, though)
<bdmurray> slangasek: yes, that is currently the extent of the signature
<slangasek> ok
<slangasek> room for improvement then, but something is better than nothing for now
<slangasek> (and no, I don't actually have any practical ideas on how to improve the signature ;)
<bjf> #maas
#ubuntu-release 2014-05-22
<ogra_> there is a regression in libsoup that keeps network-manager from passing autopkgtests (via friends), could some archive admin please override that so that network-manager can go in ... we urgently wait for the included fix for touch images
<cjwatson> ogra_: done
<ogra_> yep, thanks, seen
<cjwatson> well, you asked in multiple channels, so you get replies in multiple channels for the benefit of anyone else who might otherwise go to take action on it :)
<ogra_> yeah, well, i asked generically here in case you are off today :)
<Laney> I think I've fixed friends too
<Laney> new libsoup added more annotations to some functions
<ogra_> nice !
<Laney> so vala could now infer the length and knows what type the array should have
<Laney> (bytes)
<darkxst> infinity, remember we demoted cinnamon a while ago?, well muffin probably needs the same treatment!
<rtg> can I get some binaries for intel-gpu-tools NEW'ed ?
<bdmurray> infinity had mentioned making quantal unsupported in LP (after something?) but it hasn't happened yet, is that something still holding it up?
<slangasek> bdmurray: is this just about flipping the switch in LP?
<slangasek> bdmurray: I don't know of any reason we couldn't mark it unsupported, but I see that I don't have access to do this in LP
<bdmurray> slangasek: ah, infinity had mentioned flipping the switch after the last kernel goes in
<slangasek> ah, right
<bdmurray> is that done?
<slangasek> I know there were some delays due to regressions being found
<slangasek> and it looks like we still have a kernel in quantal-proposed
<bdmurray> ah, okay its not a huge deal. someone had just nominated a bug for quantal.
<ScottK> slangasek: I seem to recall infinity saying he wanted the kernel in updates as one final gesture before stuff got archived.
<ScottK> oh.  bdmurray  said that already.
<superm1> ScottK: you released one of the packages for bug  https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1290460 but not the other
<superm1> can you release the second one too?
<ScottK> superm1: It wasn't marked verified.
<ScottK> I can if it is.
<superm1> i thought https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1290460/comments/18 indicated it was confirmed
<superm1> but maybe i'm mistaken, tgm4883 ^
<superm1> yeah between that and https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1290460/comments/16 it sounds like both together positive test
<ScottK> OK.
<ScottK> superm1: Done.
<superm1> thanks
<superm1> can you copy binaries forward to utopic for both too?
<superm1> or do we need to redo the upload for utopic?
<ScottK> superm1: better to just upload. I'm away from my computer and can't do it now.
<infinity> bdmurray: Yeah, we should be denying all Q SRUs.  It's just that kernel I'm waiting on, since the work's already been done anyway.
<bdmurray> infinity: it was a bug task nomination not an SRU
<infinity> bdmurray: Tomayto, tomahto.
#ubuntu-release 2014-05-23
<slangasek> bdmurray: remind me how update-manager determines which sources are third-party?  I just had it disable archive.ubuntu.com on an attempted upgrade to utopic
<slangasek> bdmurray: hmmm possibly related to my /etc/update-manager/release-upgrades.d/local-mirrors.cfg no longer having the expected effect
<tseliot> hi, can and admin reject xorg-server-lts-saucy from precise-proposed, please? (I forgot to include the previous release in the diff)
<infinity> tseliot: Done.
<tseliot> infinity: thanks
<superm1> slangasek: currently http://cdimages.ubuntu.com/mythbuntu/precise/ appears to be building still daily, can you change it so that the LTS's that build daily will be the trusty LTS instead at this point?
<cjwatson> We haven't started any trusty LTS builds yet
<cjwatson> I was planning to do that after the livefs infrastructure changes are done
<ScottK> Do CI train packages somehow skip binary New?  qtdeclarative-opensource-src grew a new binary in the last upload and I don't see where it hit new.
<xnox> cjwatson: well, can we spin up mythubuntu trusty daily? mythbuntu have fixes in -updates that unbreak mythubuntu ubiqyity plugins.
<xnox> (e.g. to prevent installer from crashing if one chooses vnc option)
<infinity> ScottK: All copies skip binary NEW, it's a longstanding bug.
<ScottK> Sigh.
<infinity> Well, s/bug/misfeature/ ... It's not trivial to fix, but it's on the TODO.
<ScottK> So CI train is both a backdoor for non-developers to upload and gets less scrutiny.
<infinity> Pretty much means completely rewriting what a copy is.
<ogra_> could some archive admin let golang-udm out of NEW ?
<ScottK> infinity: that or deciding copy from CI train isn't the right way.
<infinity> ScottK: All copies have this particular problem, and we're not going to stop using them entirely, so it's a bug that needs fixing.
<ScottK> AFAICT source only copy and rebuild would make it hit new.
<infinity> Yes, it would.
<infinity> But it would also invalidate to some extent the binary testing that was done, as well as being a waste of resources.
<ScottK> The tests get rerun anyway for migration from proposed don't they?
<infinity> Different testing.  Which is, indeed, also a problem IMO.
<infinity> All the testing they do should be done at the -proposed stage, not before.
<ScottK> I agree it would cost some additional resources, but I don't think it would be a waste.
<infinity> ScottK: So, I'm curious what the deep concern here is in this case.  I assume the package rename was warranted.
<infinity> ScottK: The broken one only existed in utopic, so the earlier it's fixed, the sooner they can drop the transitional one and pretend like it never happened.
<infinity> (or just P/C/R it out of existence, which is probably smarter than a transitional)
<infinity> ScottK: Your review didn't raise any technical arguments for why it was bad, just that it should wait to be less of a hassle.
<ScottK> Given new gets skipped, it doesn't matter.
<jamespage> bdmurray, picked up a new ceph bug whilst testing proposed yesterday/today - its not technically a regression compared to release - bug 1322498
<ScottK> I mostly don't appreciate being ignored.
<jamespage> bdmurray, I have a tested fix but wanted to check whether I should let bug 1278466 release first or stack it ontop of the existing proposed package
<ScottK> If comments from people who aren't on their team are going to be ignored, let's quit pretending there's community involvement.
<ScottK> If someone had said CI train uploads skip new so it doesn't matter then I'd have said go for it.
<infinity> ScottK: It landed in the distro 5 hours BEFORE your review.  I'm not sure what responsiveness you were hoping for.
<infinity> 6 hours, even.
<ScottK> infinity: OK.  Then that's a different bug.
<ScottK> I've NFC why it's even sent out for review.
<ScottK> Thanks for pointing that out.
<infinity> I suspect it's a bit of a disconnect between CI train reusing LP MPs for its own test-and-approve process (probably a good thing, component reuse, for the win) and the fact that that's also spamming real people who subscribe to those packages. :/
<infinity> Though I *am* curious what the CI stuff does if a real person registers a negative review before the bot returns a positive one.
<infinity> Cause that should probably halt it.
<Laney> It doesn't check the reviews or status at all AIUI
<infinity> Laney: Yeah, that would seem to me to be a problem.  A bot-driven MP like this should still allow humans to play along.
<ScottK> Also if it's automatically copied,  the MP get automatically merged so people don't review stale proposals.
<infinity> (Obviously not in this case, where Scott was 6h too late, but let's assume he got a review in before someone hit the big red publish button, that button should tell them "hey, a human had an issue on this MP, dude")
<ScottK> Yep.
<ScottK> But in this case something should have marked it merged when it was copied.
<ScottK> Then I wouldn't have reviewed a stale proposal.
<Laney> Hrm
<Laney> Was this a source package upload through the train?
<ogra_> if it was the train you should file a bug ...
<infinity> Laney: https://code.launchpad.net/~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_fixpkgname/+merge/220601
<infinity> It was that.  Whatever that means.  Looks trainy.
<Laney> infinity: I see it
<Laney> Train can handle human uploads to its PPAs too
<Laney> but I think you lose any merging-back if you do that
<ogra_> yeah
<sil2100> When direct uploads are being made and handled by the CI train, no bzr merges are made by the infrastructure
<Laney> I think if I was going to upload it then I'd have just pushed the branch instead of creating a merge proposal
<ogra_> then you make robru jobless :P
<ogra_> i guess he was the one who merged it and drove it through the train
<ogra_> (guessing by the landing time)
<xnox> ScottK: branch merges happen at -proposed -> release copy stage, not during ppa -> proposed copy.
<Laney> ogra_: https://ci-train.ubuntu.com/job/landing-016-2-publish/22/
<ScottK> xnox: Why? Anyone I know that manages branches directly tags it when it's uploaded.
<ogra_> ah, so Timo himself
<ogra_> ScottK, and if the merge expoxes massive errors during autopkgtest ?
<xnox> ScottK: during ppa -> -proposed, there is a separate branch available owned by bot.
<ScottK> Yet another misfeature.
<ogra_> you really dont want it to land in trunk before it passed testing
<xnox> ScottK: the idea is that, when things were getting stuck in -proposed -> -release migration, the trunk would move on, without migrating previous release... or something.
<xnox> ogra_: testing is meant to be complete by that time (ppa -> -proposed copy)
<ogra_> xnox, why do we have proposed->archive then ?
<xnox> ogra_: that's britney migration.
<xnox> and ADT.
<ogra_> testing the package itself is done by that time ... that doesnt mean it plays nicely with the archive
<xnox> either manual testing needs to move during proposed->archive stage.
<ogra_> or its rdeps
<xnox> (e.g. open a blocking bug)
<ScottK> ogra: It's already in the archive so what's the point of not making the cvs catch up.
<ogra_> ScottK, if issues are found in proposed so that the package gets dropped your branch will be out of sync
<ScottK> xnox: In this case it's a packaging branch so trunk moves on isn't relevant.
<ogra_> (note that i dont work on CI i'm just a consumer myself)
<ogra_> but i think it is logical to wait with merging till *all* testing is done ...
<ScottK> ogra: Once it's in the archive it's part of the history of the package.  Not merging and pretending it never happened is just modifying history to ignore what actually happened.
<ogra_> but it isnt in the archive until britney lets it
<infinity> ogra_: Yes it is.
<infinity> ogra_: It's been uploaded to the archive, release pocket is irrelevant to packaging history.
<ogra_> we had removals from -proposed in the past, didnt we ?
<infinity> On rare occasions, that doesn't mean the upload never existed.
<infinity> The right way forward is always forward, even if that's a full revert of the code and a new changelog entry saying "revert the last upload".
<ogra_> you shoudl probably involve some train developer/admin in this discussion  ;)
<infinity> You still want your VCS to reflect that, maybe someone wants to see what was reverted and why.
<infinity> So someone else doesn't try the same broken thing two days later. :P
<ogra_> i'm sure there is a reason didrocks picked this way to workflow
<ogra_> s/to/of/
<ogra_> if it couldnt be merged due to being dropped from proposed the MP histrory will reflect that
<infinity> MP history isn't VCS history.
<ogra_> admittedly the changelog perhaps wont
<infinity> Nor is it package history.
<ogra_> depending on the developer and how he works with changelogs
<infinity> But I think I'm going to take my sick butt back to bed instead. :P
<ogra_> yeah, get better so we can meet next week :)
<rcj> arges, Would you have time this morning to look at bug #1275656?
<cjwatson> It does actually get committed to revision control when it hits -proposed, just to a different branch
<cjwatson> I made the same initial objection but having it on a different branch actually does seem kind of sensible
<cjwatson> Or at least defensible
<arges> rcj: i already did look at it and sponsored it. What changed?
<cjwatson> xnox: I can have a look on Monday, I guess, but probably not today
<rcj> arges, ah, the v3 patches from 5/21 are uploaded now?  How do I check these things so that I don't bother you?
<arges> rcj: https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=open-vm-tools I'll reject the older one
<rcj> arges, thanks
<arges> rcj: the other one is here https://launchpad.net/ubuntu/precise/+queue?queue_state=0&queue_text=open-vm-tools
<rcj> arges, Thank you.
<arges> rcj: no problem
<ScottK> cjwatson: I don't understand why.  Once it's in the archive, it's irreversibly there.  Not merging the branch just means the VCS and the archive are out of sync.
<ogra_> as you can see above -proposed isnt irreversible
<cjwatson> Well, I said defensible not that I necessarily agreed ...
<cjwatson> I think this would make a lot more sense in git where you wouldn't have to dig out a separate URL
<cjwatson> Then it'd be analogous to "master" and "next"
<ScottK> ogra_: For the package history it is.
<superm1> can someone axe the mythtv upload in trusty-proposed?  upstream decided to land some patches upstream that fix it more nicely that I would like to test instead
<slangasek> superm1: done (the upload axe, not the cdimage change which I will defer to cjwatson on)
<superm1> thanks
<ogra_> slangasek, do you feel like reviewing another go package ... golang-udm is sitting in NEW since ~1 week now ... and we wannt to work on MMS stuff in malta next week
<slangasek> ogra_: I had already reviewed it and spotted some issues that I needed to talk with sergiusens about, unfortunately since he's already in Malta it's been hard to catch him online
<ogra_> ah, k
<slangasek> I'm assuming you don't want me to do a straight review->reject, so... :)
<ogra_> yeah, better not :)
<slangasek> anyway, I will try to send an email to him today with my questions, but I guess for all intents and purposes nothing's going to progress on this until Monday now
<ogra_> right ... and then you can do it in person anyway
<ogra_> which will be faster
<slangasek> (unless you want to discuss with me today why this one is using gc again after we sorted out nuntium using gccgo)
<ogra_> no, i was just forwarding the request
 * slangasek nods
<didrocks> xnox: I think the answer to your question is "yes", but I wouldn't guess and let infinity answering
<xnox> didrocks: sorry, i think i lost context =)
<xnox> only question i had recently, was responded by colin....
<ogra_> xnox, who cares about context as long as the answer is positive ;)
<Logan_> why was libav rejected?
<ScottK> Logan_: it FTBFS on two archs.
<ScottK> Starting a transition on just some archs sucks.
<Logan_> right, I figured - just making sure
<xnox> Logan_: is anybody looking into fixing libav? or shall i take a look.
<Logan_> the most I did in terms of looking into fixing it was triaging the appropriate bug for ppc64el :P
<Logan_> I'm not sure whether to report the arm64 issue upstream or not
<Logan_> xnox: but if you have any ideas on how to fix either, feel free to go ahead with patches
<xnox> Logan_: ok, let me try.
<infinity> xnox: I was going to look at it.
<infinity> xnox: The simple fix is, well, simple.
<Logan_> infinity: disabling altivec?
<infinity> Logan_: altivec on ppc64el and neon on arm64, yeah.
<Logan_> I see that as a stopgap tbh
<infinity> As do I.  siretart and I chatted about this last night.
<Logan_> would any collaboration with libav upstream help?
<infinity> Just needs someone who knows both arches well to sit down with the code and sort out why it's broken.
<infinity> I'm assuming similar reasons for both.  The neon code probably assume armv7t2, and the atlivec code probably assume big-endian.
<infinity> s/assume/assumes/g
<xnox> "assume armv7t2" hm. i thought neon is compatible...
<infinity> Or it could just be buggy assembly...
<xnox> infinity: well, looking at that file the bits that blow up on arm64 are in the conditional CONFIG_RV40_DECODER, below it there is also CONFIG_VC1_DECODER so possibly just RV40_DECODER could be disabled on arm64
<xnox> (assuming that vc1 is not bust)
<xnox> (*disabled = neon optimization of RV40 decoder that is)
<xnox> hm, or is it bailing because rv40bias constants become undefined even if they are called...... i really have no clue in asm =(
#ubuntu-release 2014-05-24
<Logan_> hmm, someone synced conn man
<Logan_> interesting
<Logan_> *connman
<Logan_> why on earth did he do that?
<infinity> Why not?
<Logan_> there was a huge Ubuntu delta
<infinity> Oh.
<infinity> Well, looks like you get to chew out both ari and asac, once you sort out if that delta was still necessary.
<ScottK> As long as it works on the phone, it's all good,  right?
<xnox> ScottK: i thought phone uses network manager, not connman.
<rsalveti> yup, phone uses nm
<ScottK> xnox: There was some sarcasm there.
#ubuntu-release 2015-05-18
<Mirv> could I get a pre-ack for my qtbase sync from Debian (to wily) that adds a new binary package libqt5libqgtk2 for an existing file? see the first 1/5 of https://ci-train.ubuntu.com/job/ubuntu-landing-019-1-build/lastSuccessfulBuild/artifact/qtbase-opensource-src_packaging_changes.diff
<Mirv> that drops GTK2 requirement from Qt 5 which we also want
<Mirv> so that it's recommended only
<mitya57> Mirv: unrelated to the NEW package, just FYI: the two patches you disabled can be still useful in case someone compiles an app using gcc5 against a gcc4-compiled Qt.
<mitya57> was the case in i.e. debian #783127
<ubot93> Error: Could not parse data returned by Debian: timed out
<mitya57> Also, it will be really nice to have a list of Ubuntu delta :)
<Mirv> mitya57: oh, right
<doko__> mitya57, Mirv, which are these gcc/4/gcc5 patches?
<Mirv> doko__: require_fpic_instead_of_fpie.patch + make_qglobal_h_complain_if_you_use_fpie.patch
<Mirv> in that url above
<Mirv> my thinking was to wait for gcc5 to be default in Ubuntu, then enable those, remove that one ubuntu-only patch and add back reduce-relocations to Qt config
<mitya57> http://code.qt.io/cgit/qt/qtbase.git/commit/?id=36d6eb721e7d5997ade75e289d4088dc48678d0d, http://code.qt.io/cgit/qt/qtbase.git/commit/?id=3eca75de67b3fd2c890715b30c7899cebc096fe9
<mitya57> Those links have some clickable links to bugreports and discussions
<doko__> ahh, thanks
<slangasek> wgrant, infinity: so I have XS-Build-Indep-Architecture: amd64 set in the edk2 source, but this happened. https://launchpad.net/ubuntu/+source/edk2/0~20150106.5c2d456b-1
<slangasek> wgrant, infinity: looks like LP isn't honoring it correctly, can we get that fixed?
<infinity> slangasek: Ahh, that's probably hitting a corner case in the parser, because you have no amd64 binaries.  Seems like it should be fixable.
 * infinity files a bug.
<wgrant> slangasek: That's because gina doesn't import custom fields like Build-Indep-Architecture. That's a bug, but it'll work fine if you upload directly to anywhere in LP.
<slangasek> wgrant: ok, thanks
<slangasek> wgrant: well, now I get https://launchpad.net/ubuntu/+source/edk2/0~20150106.5c2d456b-1build1/+build/7441990 instead :)
<wgrant> slangasek: Does modern sbuild cope with that case?
<slangasek> wgrant: good question, I haven't tested that and it wouldn't have gone through sbuild for the Debian upload.  I'll give it a spin
<wgrant> slangasek: If it works (or if it doesn't, but is easily fixable), the sbuild upgrade is ready from the LP end. Just waiting on scalingstack to be unbroken enough that we can do a test rebuild with it.
<slangasek> wgrant: yeah looks like current sbuild doesn't cope either
<slangasek> (wily)
<wgrant> slangasek: Looking at the code in wily, it looks like -A should make it work.
<wgrant>         if ($dscarchs ne "any" && !($valid_arch) &&
<wgrant>             !($dscarchs =~ /\ball\b/ && $self->get_conf('BUILD_ARCH_ALL')) )  {
<wgrant> So if -A is set and there's an all token in Architecture it is meant to permit it.
<wgrant> Seems to work.
<wgrant> So we just need the sbuild upgrade.
<slangasek> oh?  didn't work here with the wily sbuild, not sure what I was doing wrong then
<wgrant> You sure you gave it -A?
<slangasek> yes
<slangasek> oh it actually didn't fail out with skipping architecture
<slangasek> so I just have some other problem with my sbuild setup
<wgrant> Yeah
<wgrant> Mine failed for other reasons too.
<wgrant> Specifically, that my home directory went away because lol.
<wgrant> But it failed after the arch check.
#ubuntu-release 2015-05-19
<Mirv> repeating my yesterday's request. could an archive admin pre-binNEW ack new binary package libqt5libqgtk2 at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-019/+packages ? (one file split to a new package in Debian to avoid requiring GTK2 in Qt 5 if the theme support is not needed)
<infinity> Mirv: If that matches experimental, fine by me.
<Mirv> infinity: yes, it matches. thanks.
<rcj> wgrant, Can you help me with an arm64/armhf buildd failure for Wily?  It's blocking cloud images, etc.
<rcj> https://launchpad.net/~cloud-images-release-managers/+livefs/ubuntu/wily/cpc/+build/27219
<rcj> For some reason on wily it fails because it can't find '/usr/bin/env'
<rcj> ^ cjwatson
<wgrant> rcj: New livefses build on virtual builders by default.
<wgrant> Which for ARM means qemu-user-static, which means failure.
<wgrant> I've fixed that one's config.
<wgrant> So the next build should work.
<rcj> wgrant, thanks.  the armhf build was https://launchpad.net/~cloud-images-release-managers/+livefs/ubuntu/wily/cpc/+build/27218 with the same
<wgrant> Yep, all controlled by the same flag.
<wgrant> Which is now set correctly.
<rcj> wgrant, excellent.  Thanks again.
<wgrant> np
<wgrant> This'll all go away Soonâ¢
<wgrant> We have hardware for both, just need it set up now.
<rcj> wgrant, excellent!
<rcj> wgrant, odd failures now on wily with package config failing.  https://launchpadlibrarian.net/206896807/buildlog_ubuntu_wily_amd64_cpc_BUILDING.txt.gz  seeing that on all archs
<cjwatson> rcj: Not a Launchpad problem - debootstrap is failing locally too, try it for yourself.  Here's debootstrap.log: http://paste.ubuntu.com/11227070/
<rcj> cjwatson, just caught that.  Thanks.
<cjwatson> (search for "Setting up util-linux")
<cjwatson> rcj: poked pitti on #ubuntu-devel
#ubuntu-release 2015-05-20
<ypwong> could someone please release indicator-china-weather 1.1.0-0ubuntu3 from trusty-proposed?
<infinity> ypwong: Done.  It was a bit broken because the .changes file didn't have the bug closure.  I guess the uploader didn't build the source on Ubuntu.
<ypwong> infinity, oh..
<ypwong> infinity, thanks
<tedg> We're adding a feature to UAL to make dealing with Mir trusted prompt sessions easier.
<tedg> Which unfortunately makes libubuntu-app-launch dependent on libmir
<tedg> Which has the result of making it so that libual can't build on ppc or ppc64
<tedg> So, I need some help deleting binaries for libual and anything that depends on it for those architectures.
<tedg> infinity, Perhaps are you around? ^
<infinity> tedg: That looks like quite a mess to untangle on a day off.
<tedg> infinity, Heh, yes.
<tedg> For the record, I have gotten a card on the MIr backlog to fix the PPC issue.
<tedg> But trying to get silos landed in the mean time.
<infinity> tedg: I was just about to try a PPC build to see what "the issue" is.  It's been going on more than long enough.
<infinity> tedg: Anyhow, I'm on VAC until tomorrow.  If it can wait until then, I'll help you tidy up.  If it can't, I'm sure you can hunt someone else down to try to unwind the mess.
<tedg> infinity, I think the issue is something with Mesa and the test suite, I've suggested the test suite passing isn't as important as getting a build.
<infinity> tedg: My plan was to cargo-cult exactly the same hacks that are in place for arm64, and then see where it explodes.
<infinity> Which I've half done now.  Was too lazy to do the other half before trying a quick build.
<tedg> WFM, I just don't want per-arch stuff leeching up the stack.
<infinity> Okay, so it indeed builds, and then fails 2 tests:
<infinity> 99% tests passed, 2 tests failed out of 281
<infinity> I need to employ the rest of the arm64 hacks and see if those affect that.
<infinity> And then we can probably just temp ignore the ppc-specific failures.
<infinity> And skip out on removing your packages altogether.
<infinity> tedg: Can you ask a Mirish person where the source for test_data/lib$(arch).so is?
<tedg> infinity, asked
<infinity> Was hoping some grepping would make it jump out, but I guess I grep poorly.  Or that blob is sourceless, which would be unfortunate. :P
<tedg> echo /dev/urandom > lib$(arch).so # Confuse release team
<tedg> cat
<infinity> It's definitely not urandom, since it's a valid ELF object for the target arch. ;)
<tedg> urandom, c++, who can tell the difference? :-)
<infinity> Maybe it'll be kind and make me one during the build.  Not holding my breath.
<infinity> Yeah, no such luck there, it comes from an external something.
 * infinity shrugs.
<infinity> 	167 - mir_unit_tests.MesaClientPlatformTest.* (Failed)
<infinity> 	233 - mir_unit_tests.SharedLibraryProber.* (Failed)
<infinity> So, the second one would be fixed by getting those objects built for ppc/ppc64el.
<infinity> The first one is worth a dig, but also perfectly reasonable for us to give a temp pass, and stop playing these awful arch restriction games, IMO.
<infinity> Value of: reinterpret_cast<struct gbm_device*>(pkg.data[previous_data_count])
<infinity> Expected: is equal to 0x10023e2f340
<infinity>   Actual: 0x23e2f340 (of type gbm_device*)
<infinity> Hrm.  Curious.
<infinity> That looks pretty tractable.
<infinity> What with all the suspiciously similar but not quite numbers.
<infinity> tedg: Quite confident we can just sort this in the morning when I'm back from VAC.  I might enjoy my last day and go nap or beer or beer and then nap, though.
<tedg> infinity, Sounds great, thank you!
<infinity> tedg: If you can hunt down the mysterious test data source for me, that would be awesome, then it's just this one bug that needs squashing or ignoring.
<tedg> Enjoy your napping beer ;-)
<tedg> Will do
<flexiondotorg> infinity, I've had a few sponsor requests turned down.
<flexiondotorg>  infinity, Please take a peek at this - https://bugs.launchpad.net/ubuntu-mate/+bug/1456591
<ubot93> Launchpad bug 1456591 in ubuntu-mate-artwork (Ubuntu) " ubuntu-mate-artwork 0.4.8 bug fix release [debdiff attached]" [Wishlist,Incomplete]
<flexiondotorg> infinity, I'm just wanting to know if this is standard practice?
<flexiondotorg> infinity, Should all sponsoring "bugs" be self referencing?
<flexiondotorg> infinity, https://bugs.launchpad.net/ubuntu-mate/+bug/1456597
<ubot93> Launchpad bug 1456597 in ubuntu-mate-settings (Ubuntu) " ubuntu-mate-settings 0.4.5 release [debdiff attached]" [Wishlist,Incomplete]
#ubuntu-release 2015-05-21
<micahg> flexiondotorg: he's off today, but to answer your question, yes, the idea is that the upload will close the bug that's tracking the upload
<tjaalton> infinity: ping lts-vivid
<infinity> tjaalton: Working on it today.  First day back from VAC.
<tjaalton> infinity: ah ok, nice
<tedg> infinity, Did you figure out where that lib comes from? No one I pinged on the Mir side got back to me, but I can try some more.
<RAOF> tedg, infinity: Those âlibrariesâ are sourceless; they're empty.
<RAOF> tedg, infinity: Their job is to be the minimum possible valid ELF libraries for various architectures, so we can test that our loader paths (a) report appropriate errors, and (b) will actually load a library.
<tedg> RAOF, Then are they built by hand? How do you get that?
<RAOF> tedg: Yeah, they were built by hand. The reason for this is that they're test data, and we *want* to try to load libarm64.so on i386.
<RAOF> I... actually forget how we built them :)
<RAOF> The shared library prober tests actually have a list of expected architectures.
<tedg> RAOF, So infinity's issue is that he wants to build one for PPC
<RAOF> Yeah.
<RAOF> tedg: âtouch foo.cpp; gcc -o foo.so -shared foo.cppâ is the way to generate them.
<tedg> RAOF, Probably should be a shell script, eh?
<RAOF> Possibly.
<RAOF> It can't be run during Mir build, though, because we won't have all of {i386, x86_64, armhf, arm64, powerpc, ppc64, ppc64el} compilers :)
<tedg> Sure, but if we add arm128 we'll need someone to remember how to do it :-)
<tedg> At least a README
<RAOF> Also, the shared library tests need to do something a bit more interesting, because we encode a list of architectures we expect in there.
<RAOF> Please file a Mir bug about that :)
<tedg> RAOF, So I think that infinity is probably working towards an MR with the PPC lib in it, what would be preferred as a MR reviewer?
<arges> bdmurray: hi
<bdmurray> arges: howdy
<arges> bdmurray: hey jamespage was wondering about releasing bug 1443429, i can handle it, but i know today is your day
<ubot93> bug 1443429 in nova (Ubuntu) " [SRU] juno 2014.2.3 point release" [Undecided,New] https://launchpad.net/bugs/1443429
<arges> looking at it, just looks like cinder needs releasing
<bdmurray> arges: feel free to do it
<arges> bdmurray: ok
<RAOF> tedg: He'll need to also adjust the tests, but that'd be fine.
<RAOF> infinity, tedg: https://code.launchpad.net/~raof/mir/document-our-random-test-binary-data/+merge/259798
<RAOF> Documents how those binaries have arrived.
<tedg> RAOF, Awesome, thanks!
<infinity> RAOF: I already fixed everything around it, just needed to know how to generate the .so itself.  Thanks.
<ChrisTownsend> bdmurray: Hi, are you on SRU duty today?
<bdmurray> ChrisTownsend: yes, I am
<ChrisTownsend> bdmurray: Great, would you have time to review the Unity SRU in unapproved?
<bdmurray> ChrisTownsend: for which release?
<ChrisTownsend> bdmurray: Trusty
<ChrisTownsend> bdmurray: I added the debdiff to each bug targetted.
<bdmurray> ChrisTownsend: I'll look at in a bit I have a call soon
<ChrisTownsend> bdmurray: Thank you very much!
<ChrisTownsend> bdmurray: debdiff is linked at the end of SRU header section in the description.
#ubuntu-release 2015-05-22
<ChrisTownsend> bdmurray: Thanks for accepting that Unity Trusty SRU.
<mdeslaur> can someone please pocket-copy autofs from vivid-updates to wily?
<Laney> mdeslaur: you can - copy-package --from-suite vivid-updates --to-suite wily-proposed --include-binaries autofs
<mdeslaur> Laney: where did you get copy-package from?
<Laney> lp:ubuntu-archive-tools
<mdeslaur> Laney: cool, thanks!
<Laney> np!
<tedg> infinity, Were you able to get Mir on PPC?
#ubuntu-release 2015-05-23
<ari-tczew> please delete from vivid-proposed a package gnote - http://launchpadlibrarian.net/207258369/gnote_3.16.0-1ubuntu1_source.changes
<ari-tczew> it has been wrong uploaded
#ubuntu-release 2016-05-23
<pitti> cyphermox: grub2-signed> wasn't aware of that, I'll update it
<pitti> cyphermox: apw already uploaded grub2-signed, thanks apw
#ubuntu-release 2016-05-24
<RAOF> Hm. Queubot *may* have gone slightly mad.
<cjwatson> stgraber: ^- please fix
<Trevinho> SRU team, please can you move bamf (xenial) and unity (trusty) sync to proposed?
<Trevinho> bdmurray, pitti ^
<Trevinho> It would be nice if you guys could provide a "single name" to ping the team alltogether, as it's not so easy to figure out who is in charge. And for xenial we'd need to do quite a lot of SRUs, and I'd like the process to be agile.
<Trevinho> Ah, it seems I missed https://wiki.ubuntu.com/StableReleaseUpdates#Publishing...
<Trevinho> Then... RAOF ^^ :)
<seb128> Trevinho, he's in .au so likely called it a day by now
<Trevinho> seb128: yeah... well, leaving that for tomorrow then
<seb128> well maybe bdmurray or arges can help you and have a look, would be nice to get those in since LTS users missing menus is not nice and we should already have landed that earlier
<seb128> but yeah, let's see
<LocutusOfBorg> please accept hexchat merge from new :)
<flexiondotorg> Laney, I've just uploaded a bug fixed mate-panel 1.12.2-2 to xenial.
<flexiondotorg> Do I need to file an SRU for that?
<flexiondotorg> One patch has been added.
<Laney> flexiondotorg: You need to make all linked bugs contain the required SRU information
<flexiondotorg> So create an SRU.
<flexiondotorg> And a comment in the original bug with a link to the SRU?
<flexiondotorg> And, an SRU is required.
<Laney> No need to file a new bug if the changelog already contains one
<Laney> Just edit it
<flexiondotorg> Change has the link to the bug.
<flexiondotorg> *Changelog
<Laney> Then use that one
<flexiondotorg> OK, so convert the existing bug into an SRU?
<Laney> nod
<flexiondotorg> Thanks,.
<rbasak> Technically it's the act of uploading to Xenial (or another stable release) that makes it an SRU. One might consider a bug to have SRU information if it has SRU template style description and one or more bug tasks for stable releases.
<rbasak> (if that helps make anything clearer)
<flexiondotorg> rbasak, I've editted the original bug opening post to include the SRU template.
<stgraber> restarting queuebot, lets see if it's happier
<cjwatson> stgraber: thanks
<slangasek> cjwatson, infinity: the spikes on http://people.canonical.com/~ubuntu-archive/component-mismatches.svg where c-m wanted to demote a number of source packages approximately equal to the number of source packages in main are artifacts in the data, right? any objections to me cleaning those out?
<slangasek> cjwatson, infinity: sorry, not http://people.canonical.com/~ubuntu-archive/component-mismatches.svg, I mean http://people.canonical.com/~ubuntu-archive/component-mismatches.csv
<cjwatson> slangasek: fine by me
<slangasek> done
<slangasek> (backup taken, so revertible)
<robru> ^^ please reject these qtmir-gles uploads for xenial/vivid, those are mistakes.
<apw> robru, done
<slangasek> robru: done
<slangasek> :)
<apw> oh i wonder what that will do :)
<slangasek> apw: you got them first, that explains why the commands silently succeeded for me ;)
<apw> ahh :)
<Saviq> hi can someone please cancel/restart https://launchpad.net/ubuntu/+source/upstart/1.13.2-0ubuntu23/+build/9668581 - it's building for 10h already where it should take ~25mins
<Saviq> not sure why the error in the first place, but it shouldn't be stuck for 10h anyway
<slangasek> Saviq: retrying the build just increases the chances of us getting stuck with upstart binaries again on s390x, which were deliberately removed
<slangasek> Saviq: I guess you care about this for ubuntu-app-launch + ubuntu-ui-toolkit?
<Saviq> slangasek, yeah http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#ubuntu-app-launch
<slangasek> is this a new dependency introduced in the new ubuntu-app-launch in -proposed?
<Saviq> tedg, ââ?
<Saviq> slangasek, I doubt it, u-a-l was based on upstart since the beginning
<Saviq> we'll need to remove u-a-l and ubuntu-ui-toolkit s390x IIUC?
<slangasek> Saviq: yes, that's probably what we want to do; but we don't want to just remove binaries and have them build again (and get stuck again) on the next upload. Can we have these packages declare a build-dep on upstart?
<slangasek> (I can remove the binaries now so as not to require a new landing, but I don't want to do this without a committment to fix the underlying issue)
<Saviq> slangasek, u-a-l already does
<slangasek> haha
<slangasek> so it got built during the window when the upstart/s390x binary was in the archive before we removed it, fail
<slangasek> Saviq: ok, ual binaries removed from yakkety-proposed for s390x; that should unblock, assuming there aren't other revdeps on ual that have also built on s390x and will also now need removal
<Saviq> slangasek, but indeed ubuntu-ui-toolkit does not B-D on upstart - not sure if it should D on it in the first place
<slangasek> also, it's awfully unfriendly of proposed-migration to refuse to consider this package a candidate given that the same package is uninstallable already in yakkety on s390x
 * tedg back
<tedg> Thanks slangasek
 * pitti sighs at the xenial-proposed queue, ok, let's go
<pitti> much of it is just xnox doing half an archive rebuild :)
<slangasek> pitti: hmm, did you see my notes on all of those SRU bugs? :)
<slangasek> those were !accepted because they're lacking autopkgtests and therefore an SRU regression test plan
<slangasek> so, test plan still missing, but now they're in -proposed so at increased risk of publication without ever being tested <shrug>
<pitti> right, so they need to be smoketested maunally
<pitti> slangasek: ah, ok (and no, didn't see your comment in the middle of the bug trail, sorry)
<pitti> it seemed to me that without proposed binaries there's little chance of actually testing them
<pitti> leaving the others in -proposed then, resuming at cacti-spine
<bdmurray> slangasek: Could you fully phase this systemd SRU for xenial? the problems are all package install failures
<Saviq> slangasek, do you need to delete the u-a-l packages too http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#ubuntu-app-launch ?
<pitti> bdmurray: indeed, I saw another instance of bug 1560797, one instance of bug 1584751, and two failures of pam-auth-update; none of that was touched in the SRU, these were old bugs
<ubot5> bug 1560797 in apt (Ubuntu Wily) "apt does not configure Pre-Depends: before depending package" [High,Fix released] https://launchpad.net/bugs/1560797
<ubot5> bug 1584751 in systemd (Ubuntu) "package systemd 229-4ubuntu5 failed to install/upgrade: le sous-processus script pre-removal installÃ© a retournÃ© une erreur de sortie d'Ã©tat 2" [Undecided,New] https://launchpad.net/bugs/1584751
<slangasek> Saviq: dohh, I removed them from yakkety instead of yakkety-proposed? fixed now
<slangasek> bdmurray: done
<Saviq> slangasek, is this a new thing that we don't want upstart for s390x? it seems it was happily there for xenial?
<Saviq> except for the -proposed versions that died on power and s390x...
<slangasek> Saviq: it's only used for client sessions in xenial and beyond, which do not apply on s390x.  It built by chance on s390x before, then regressed due to problems apparently outside control of upstart itself
<Saviq> slangasek, ack, filing a bug for uitk
<pitti> arges: SRU handover for xenial: upower is from myself (review appreciated), everything else up to unity-control-center (my current top) is blocked on something and has bug followups
<pitti> ah, forgot some
<pitti> jamespage: crmsh in wily-proposed queue> this is essentially a backport, and wily seems mostly uninteresting for servers (even more now that xenial is released); does bug 1445616 still actually make sense to SRU?
<ubot5> bug 1445616 in crmsh (Ubuntu Wily) "[SRU] crmsh in vivid/wily/xenial is not compatible with pacemaker" [High,Triaged] https://launchpad.net/bugs/1445616
 * pitti sees a bunch of similar major new upstream releases in https://launchpad.net/ubuntu/wily/+queue?queue_state=1
<Saviq> hrm should this not have gone away by now http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#ubuntu-app-launch Â¿?
<pitti>  ubuntu-app-launch          | 0.9+16.04.20160510.2-0ubuntu1 | yakkety-proposed/universe | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
<pitti> Saviq: no ^
<pitti> s390x was removed from yakkety, but not yakkety-proposed
<Saviq> slangasek, â?
<pitti> or it was and this is publisher/mirror lag
<Saviq> ack
<pitti> arges: wily SRU handover> IMHO all the remaining packages in the queue (manila is my top one) should be rejected and not be an SRU
<pitti> bugs commented on
<pitti> caribou: ping @ bug 1532789
<ubot5> bug 1532789 in multipath-tools (Ubuntu Trusty) "Trusty multipath-tools suffering seg faults" [High,Fix committed] https://launchpad.net/bugs/1532789
<slangasek> pitti, Saviq: yes, publisher + proposed-migration delay; should look better on the next run
<Saviq> ack
<Saviq> indeed it's already gone
<pitti> *phew, SRU queues all processed
<arges> pitti: ack
#ubuntu-release 2016-05-25
<pitti> arges: thanks
<caribou> pitti: yes ?
<pitti> caribou: I meant I had a question for you in bug 1532789
<ubot5> bug 1532789 in multipath-tools (Ubuntu Trusty) "Trusty multipath-tools suffering seg faults" [High,Fix committed] https://launchpad.net/bugs/1532789
<cking> hi there, stress-ng 0.6.04-1 has been stuck in autopkgtest testing for ppc64el for ~4+ days in  the "Test in progress" state (looking at the update_excuses page). I think it needs some kicking
<jamespage> pitti, I think its important that we maintain interim Ubuntu release until the end of their life - one reason being that they are actually the primary source for Ubuntu Cloud Archive pockets, so if we stop maintaining Ubuntu two months prior to eol, then I have to start maintain the same packages directly in the UCA for 2 months extra :-)
<jamespage> pitti, crmsh is a bit of exception to that rule as its not in the UCA, however ovs and ceph both are...
<jamespage> pitti, for UCA updates, we push through the associated ubuntu release first (on the assumption its still supported)
<jamespage> so for OpenStack Liberty UCA, Wily is still the point for entry for updates...
<pitti> jamespage: wow, we have production stuff running on wily?
<jamespage> pitti, that's not quite what I said
<jamespage> pitti, we have production stuff running on trusty based on the packages that are in wily
<jamespage> pitti, UCA is just one huge backport
<jamespage> :-)
<pitti> jamespage: ok, fair enough; I just wanted to ask if all that effort was actually useful, and it does seem to be a major risk for users on actual wily
<jamespage> pitti, well for crmsh wily users are completely broken atm
<pitti> jamespage: right, so for the crmsh case: who will actually care
<jamespage> pitti, I was all up for the 'no one is going to actually use wily for production' but then a load of people commented on that bug...
<pitti> jamespage: i. e. who will start using wily for crmsh now that xenial is out
<jamespage> thats true now, but was not the case two months ago when I did the updates, testing and upload...
<jamespage> pitti, tbh i think people where testing on wily in preparation for xenial
<pitti> yeah, that seems plausible
<jamespage> pitti, from my perspective, most of the work is already done in terms of time, so I'd rather see it through...
<pitti> jamespage: so you want ceph, curtin, maas, openvswitch
<jamespage> and be happy stating that we did support wily for 9 months
<jamespage> pitti, can't comment on maas and curtin, but yes please to ceph and openvswitch
<pitti> jamespage: the verification work of this is going to be substantial too, I suppose
<pitti> jamespage: ok, and I guess we bury  crmsh?
<jamespage> pitti, for crmsh? no the testing is automated - we know its broken (wily-liberty is currently disabled...)
<jamespage> infact the testing is automated for ceph and ovs as well
<pitti> jamespage: I mean for ceph, curtin, etc.
<jamespage> curtin/maas - defer to server team on that front...
<pitti> jamespage: we have automated tests that check that an upgrade from a current wily deployment still works?
<pitti> as that's what actually matters
<pitti> we know that the new versions by themselves are fine (presumably)
<pitti> but we are throwing that at existing users of the wily version
<jamespage> pitti, yes
<jamespage> deploy/test/upgrade/test
<jamespage> basically
<jamespage> pitti, I stand corrected - that's not fully automated, but is a cycle we go through for SRU's
<jamespage> but its still not resource intensive
<arges> pitti: i'm trying to understand your comment on the wily SRU review queue. isn't wily supported until july?
<pitti> arges: it is, yes
<pitti> arges: and we shuold certainly continue to supply major bug fixes
<pitti> arges: but I wonder if "update a server package to a major new release" makes sense at this point
<pitti> the testing and risk by far outweigh the benefit IMHO
<pitti> arges: that said, see backscroll from jamespage a few lines up
<arges> pitti: fwiw some of the server packages go into wily then into cloud archive
<pitti> yes, he pointed that out
<pitti> so accepting these is fine
<pitti> arges: but I think we should bury crmsh
<arges> oh ok : ) yea i need to increase scrollback on weechat
<arges> yea that seems like a bit jump anyway
<Odd_Bloke> infinity: I see you've commented again on https://code.launchpad.net/~daniel-thewatkins/livecd-rootfs/enable-backports/+merge/295059; have you had a chance to re-review it fully?
<Odd_Bloke> infinity: Oh, I see you're not working; don't worry about it!
<infinity> Odd_Bloke: Nah, I'm still off work until tomorrow, that was just a side comment to ogra's comment.
<infinity> Odd_Bloke: I'll get you all reviewed and merged tomorrow (or later today if this whole laying around on drugs thing threatens my sanity).
<Odd_Bloke> infinity: Cool, thanks!
<Odd_Bloke> infinity: Enjoy your stupor!
<infinity> Odd_Bloke: Once this is tested and proven, is the intent to backport to xenial for 16.04.1?
<infinity> (and maybe trusty too, though meh...)
<ogra_> lol
<Odd_Bloke> infinity: Yeah, definitely for xenial.
<ogra_> 2011 ?
<ogra_> woah
<infinity> ogra_: Yeah, it's okay, I was as surprised as you.  Old people don't deal well with change.
<ogra_> lol, yeah
<infinity> Odd_Bloke: Kay.  Let's make sure that ball gets rolling as soon as this is landed in yakkety and a few builds appear to produce sane results.
<infinity> Odd_Bloke: For now, I'm high on Oxy and going to movie myself to sleep.
<ogra_> "oxi brings movies to your sleep" :)
#ubuntu-release 2016-05-26
<Trevinho> tjaalton, slangasek: hey, could you please publish compiz and unity SRUs that have just hit the queue: https://launchpad.net/ubuntu/xenial/+queue?queue_state=1 ?
<tjaalton> Trevinho: it's too fresh for sru-review
<tjaalton> and I'm about to EOD
<seb128> tjaalton, you mean?
<tjaalton> ERROR: queue does not have a debdiff
<Trevinho> tjaalton: it won't have it, since it's a ppa sync
<seb128> it's not going to
<seb128> what Trevinho said
<tjaalton> what's the rush?
<seb128> none I guess
<Trevinho> tjaalton: various xenial fixes
<Trevinho> but, ok... I just wanted to clear the queu
<seb128> would be nice to see it approved today
<seb128> it's overdue from our side
<tjaalton> fine, acked
<Trevinho> tjaalton: debdiffs are at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-036/+packages though
<seb128> Trevinho is being a big eager now :p
<tjaalton> my shift is tomorrow btw, don't mind the queue being a bit shorter then ;)
<Trevinho> tjaalton: thanks then
<seb128> queue is fairly short thanks to p_itti rounds ;-)
<Trevinho> indeed... :)
<coreycb> hello, can an archive admin please promote python3-ply and python3-dateutil to main?  python-ply and python-dateutil are already in main.  this will help us with our MIR for bug 1586061
<ubot5`> bug 1586061 in python-microversion-parse (Ubuntu) "[MIR] python-microversion-parse" [Undecided,New] https://launchpad.net/bugs/1586061
<coreycb> apologies, that bug is not related ^ , however we'd like to have these promoted for an upcoming MIR
<cjwatson> coreycb: Would prefer them to show up in one of the component-mismatches reports first.
<cjwatson> coreycb: You don't need them to be promoted in advance of an MIR.
<coreycb> cjwatson, ok
<Trevinho> seb128: do you know why, although unity/compiz are in xenial-proposed now, there have been no bug comments for verification requests?
<seb128> Trevinho, I guess because tjaalton didn't use the tool right
<Trevinho> seb128: oh... you know who could trigger that?
 * Trevinho can send them too, in case... But, it's a little annoying
<seb128> Trevinho, sru team probably knows, try to see if bdmurray or arges can help you
<bdmurray> slangasek: https://code.launchpad.net/~brian-murray/britney/britney2-ubuntu/+merge/295847 - I couldn't JFDI
<arges> Trevinho: looks like https://launchpadlibrarian.net/261667453/unity_7.4.0+16.04.20160526.1-0ubuntu1_source.changes shows the correct Launchpad-Bugs-Fixed  . maybe 'sru-review' script didn't append those correctly.
<Trevinho> arges: yeah, it's weird... same for compiz
<Trevinho> arges: or maybe because it was a ppa sync?
<bdmurray> Its worked in the past with PPA syncs
<bdmurray> I got some cronmail about LP timeouts over my night
<arges> I've had this happen to me due to Launchpad timeouts. I had to manually copy and paste the call for testing message
<arges> yea
<bdmurray> As an example bug 1491913 from a previous SRU was commented on
<ubot5`> bug 1491913 in Unity 7.2 "Force high gfx mode with UNITY_LOW_GFX_MODE == 0" [Low,Fix committed] https://launchpad.net/bugs/1491913
<Trevinho> also in previous release we didn't get the "fix released" msg for all the bugs, it will be another script, but maybe it's the same issue?
<bdmurray> Launchpad itself does the Fix Released change e.g. https://bugs.launchpad.net/unity/+bug/1491913/comments/4 so that shouldn't time out.
<ubot5`> Launchpad bug 1491913 in Unity 7.2 "Force high gfx mode with UNITY_LOW_GFX_MODE == 0" [Low,Fix committed]
<bdmurray> The "Update Released" message is an SRU team tool.
<Trevinho> bdmurray: ah, ok... that didn't happen for some recent changes though
<bdmurray> Trevinho: if you show me something I could have a look
<Trevinho> bdmurray: for example https://launchpad.net/ubuntu/+source/compiz/1:0.9.12.2+16.04.20160526-0ubuntu1 fixed bugs #1521302 and #1574866, but nothing was updated there
<ubot5`> bug 1521302 in unity (Ubuntu Xenial) "gnome-terminal maximize than un-maximize behaves odd" [Medium,In progress] https://launchpad.net/bugs/1521302
<ubot5`> bug 1574866 in Compiz "Compiz does not paint background" [Medium,Fix committed] https://launchpad.net/bugs/1574866
<Trevinho> (and other bugs either, but I don't recall them all since I've set them as fix released manually)
<bdmurray> Trevinho: that's the one that was published 2 hours and arges and I were just talking about possible LP timeouts
<stgraber> infinity: someone just did the whole reverting SRU thing again in the archive...
<stgraber> infinity: this time with eglibc in trusty (at least)
<Trevinho> bdmurray: I'm speaking of the fix in yakkety, not the SRU msg
<Trevinho> bdmurray: well, both in fact
<Trevinho> none of them arrived there
<stgraber> infinity: got all my machines reporting that they're running a version of eglibc which doesn't exist in the archive (2.19-0ubuntu6.8)
<stgraber> infinity: according to LP, wgrant is to blame this time around for doing a straight delete and not uploading a revert
<bdmurray> Trevinho: I don't see any bug numbers in the changelog for yaketty
<cjwatson> that was an emergency, it was killing lots of DC machines; there was discussion in #security I believe
<Trevinho> bdmurray: oh, sorry I pasted the wrong link
<stgraber> cjwatson: yeah, I figured it was, but usually part of dealing with the emergency is to upload the old thing as a newer version immediately to -updates, so people can actually downgrade to the non-broken version
<Trevinho> bdmurray: here it is https://launchpad.net/ubuntu/+source/compiz/1:0.9.12.2+16.10.20160517-0ubuntu1
<cjwatson> yeah but given the nature of the problem I think that might actually have caused similar problems in reverse
<cjwatson> it was a subtle thing to do with binaries that have one version of libc in memory and try to dynamically load something involving the other version of libm, I believe
<stgraber> ah right, so if someone fixed those services (by bouncing them I guess), then uploading the revert will break them again
<cjwatson> this is speculation but it seems at least plausible
<cjwatson> somebody was working on a proper fix
<bdmurray> Trevinho: bug 1521302 doesn't have a compiz bug task, only unity.  The janitor looks at source package name and bug number.
<ubot5`> bug 1521302 in unity (Ubuntu Xenial) "gnome-terminal maximize than un-maximize behaves odd" [Medium,In progress] https://launchpad.net/bugs/1521302
<bdmurray> Trevinho: and it looks like bug 1574866 had the ubuntu compiz task added after the yakkety upload
<ubot5`> bug 1574866 in Compiz "Compiz does not paint background" [Medium,Fix committed] https://launchpad.net/bugs/1574866
<Trevinho> bdmurray: yeah, i just added that...
<Trevinho> bdmurray: it wasn't there before. But generally in these cases LP added the tasks
<bdmurray> Trevinho: I don't think Launchpad automatically adds tasks to bugs
<Trevinho> mh, weird... I think it did. Although i used to run a script to keep downstream and upstream bugs in sync
<bdmurray> Trevinho: with the Xenial SRU it looks like there are similar issues https://launchpadlibrarian.net/261667453/unity_7.4.0+16.04.20160526.1-0ubuntu1_source.changes is a unity upload referencing a bug with only a compiz task 1580212
<Trevinho> bdmurray: mh, I've fixed some of them, but still we didn't get messages either for the bugs that had proper tasks
<Trevinho> bdmurray: there were no Xenial tasks, maybe... but that used to be added automatically (i've not the powers for doing that I can only suggest series)
<bdmurray> Trevinho: Could you show me a bug with a proper task?
<Trevinho> bdmurray: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1574689
<ubot5`> Launchpad bug 1574689 in unity (Ubuntu) "Middle-clicking application icon in switcher, doesn't close it" [Low,Fix released]
<bdmurray> Trevinho: okay, that one doesn't have a Xenial task and iirc the tool won't add one.  I've personally just been manually adding tasks when they are missing but will look at improving the tools.
<Trevinho> bdmurray: it would be nice if you could add distro tasks automatically, since only few people can do that (/me excluded), so it just makes the process longer
<slangasek> bdmurray: though you could JFDI consolidate the files in the hints branch into 'freeze' :)
<slangasek> (though it indeed seems we would need to adjust the perms on the 'freeze' file then)
<slangasek> Laney: do you have any idea why http://autopkgtest.ubuntu.com/packages/l/linux-keystone/trusty/armhf/ didn't find the linux-keystone package in trusty-updates when I tried to manually trigger this?  AFAICS from the logs the adt-run invocation is materially the same between the latest run and the previous run
<Laney> slangasek / bdmurray: consolidating> It's useful to be able to see who added a hint on excuses.html, IMO
<Laney> linux-keystone> looking, but I'm not sure I'll know
<tjaalton> Trevinho, seb128, arges: i didn't use sru-review because there was no debdiff
<slangasek> Laney: useful, but IMHO this doesn't outweigh the annoyance of a) having to manage hints across a stack of files, b) having to manually update permissions in the britney branch if the team membership changes
<slangasek> there's a hint -> bzr blame, works just as well for me, YMMV
<slangasek> Laney: and for reference, my full command was 'run-autopkgtest -s trusty -a armhf --trigger eglibc/2.19-0ubunt6.8 linux-keystone'
<bdmurray> tjaalton: there's a --no-diff switch
<slangasek> -s trusty-updates doesn't work
<slangasek> this is a package that didn't exist in the trusty release pocket; previous runs somehow managed to get it right
<Trevinho> tjaalton: not sure if you can use it with that tool, but the ppa generates one
<Laney> It's annoying for a smaller set of people than those that look at excuses
<tjaalton> bdmurray: oh, ok
<slangasek> people who look at excuses but aren't part of the team usually don't need to directly care which member of the release team added a hint :)
<tjaalton> Trevinho: point was that sru-review didn't work, because i didn't use --no-diff
<Trevinho> tjaalton: ah I see... bdmurray what's the way to fix it?
<Trevinho> I mean, can we just post the msg from sru-tool, or should I hack it to do that?
<bdmurray> tjaalton, Trevinho: sru-accept could be used to comment on the bugs after the fact, just need to pass it a whole mess of options
<bdmurray> tjaalton, Trevinho: actually let me do that as I can work on adding the release tasks w/ it too
<Trevinho> bdmurray: ok, thanks a lot then
<Trevinho> bdmurray, tjaalton: I'm sorry to create such annoyance with Ci-train based SRUs, but I'd like the proces to be as smooth as possible, since I expect quite a lot of SRU for xenial. And it would be nice if we can get it done both quickly and properly.
<slangasek> yes, it's really a launchpad bug (feature request) that the queue can't give us diffs
<slangasek> these are always going to lag a bit so long as we don't have diffs to review
<slangasek> s/lag a bit/require more effort from the SRU team/
<Laney> slangasek: sorry, I don't see immediately what's wrong with linux-keystone - perhaps some delicate problem with the pinning
<Laney> apw might be able to help if he's around
<Laney> and I've got to go, o/
<apw> slangasek, linux-keystone might be in a mess, as in linux-meta does not match linux for that ...
<slangasek> apw: it indeed might be - but none of that should cause autopkgtest to fail to find the source package :)
<apw> slangasek, well linux-meta is in general a bit magical, there is a lot of implying tests up from linux -> linux-meta and the like going on, having missmatched linux/linnux-meta pairs might well find new bugs
 * apw goes see if he can make the missmatch go away yet
<infinity> stgraber: A revert would be as harmful as the upgrade was.
<infinity> stgraber: A new version will be coming, but it can't be a straight and simple revert.
<slangasek> Laney, apw: not sure why it should have mattered, but I just noticed I typoed the version of the eglibc trigger for the linux-keystone test; retrying now with the right version to see if it makes a difference
<slangasek> Laney, apw: right, using a real eglibc package version in the trigger somehow sorted it
<slangasek> (test is running now)
<ginggs> any archive admins around to remove some packages please?
<bdmurray> slangasek: Looking at https://wiki.ubuntu.com/SnapdUpdates I would have expected bug 1583085 to have the "Packaging QA" section done.
<ubot5`> bug 1583085 in snapd (Ubuntu) "[SRU] New stable micro release" [Undecided,New] https://launchpad.net/bugs/1583085
<slangasek> bdmurray: hmm indeed
<slangasek> ginggs: possibly - what do you have for us?
<ginggs> hi slangasek!
<bdmurray> slangasek: Okay, I wanted to make sure I was understanding things
<ginggs> for starters here's LP: #1580039 ,  LP: #1580041 and LP: #1580047
<ubot5`> Launchpad bug 1580039 in syfi (Ubuntu) "Please remove syfi - obsolete" [Undecided,New] https://launchpad.net/bugs/1580039
<ubot5`> Launchpad bug 1580041 in ufc (Ubuntu) "Please remove ufc - superceded by ffc" [Undecided,New] https://launchpad.net/bugs/1580041
<ubot5`> Launchpad bug 1580047 in swig2.0 (Ubuntu) "swig2.0 removal" [Undecided,New] https://launchpad.net/bugs/1580047
<ginggs> and then there's LP: #1584717 LP: #1585795 LP: #1586043  LP: #1586047
<ubot5`> Launchpad bug 1584717 in pion-net (Ubuntu) "Please remove pion-net" [Undecided,New] https://launchpad.net/bugs/1584717
<ubot5`> Launchpad bug 1585795 in python-glpk (Ubuntu) "Please remove python-glpk" [Undecided,New] https://launchpad.net/bugs/1585795
<ubot5`> Launchpad bug 1586043 in elmerfem (Ubuntu) "Please remove elmerfem" [Undecided,New] https://launchpad.net/bugs/1586043
<ubot5`> Launchpad bug 1586047 in pyviennacl (Ubuntu) "Please remove pyviennacl" [Undecided,New] https://launchpad.net/bugs/1586047
<ginggs> and lastly (for now) there's LP: #1586038 where the maintainer asked that we just remove the binaries
<ubot5`> Launchpad bug 1586038 in faumachine (Ubuntu) "Please demote faumachine to -proposed" [Undecided,New] https://launchpad.net/bugs/1586038
<slangasek> ginggs: is someone racing me to these? syfi isn't in yakkety
<slangasek> nor ufc
<slangasek> ginggs: looks like cjwatson has processed some of these via process-removals, not seeing your bugs :)
<ginggs> ah, and that was only yesterday
<slangasek> ginggs: in the case of ufc, this package was in sync - there's usually no need to file a removal request for such a package as it will be semi-automatically removed by an AA
<ginggs> great, so swig2.0 can go now, the merge of subversion has just landed
<slangasek> (unless there are revdeps that aren't sorted, but then, sort those and the AA will do the rest)
<slangasek> ginggs: heh, these bug reports suggest there was a dead spot in 2013 when we failed to do process-removals :/
<slangasek> how does a pyviennacl compare to a posixacl
<ginggs> thanks slangasek.  so that swig2.0 has a -1ubuntu4 version, so does that mean it has to be removed manually (or were you still getting to that one?)
<slangasek> ginggs:
<slangasek> ginggs: it's a manual removal, and I'm looking at it still
<ginggs> sorry, carry on then :)
<slangasek> ginggs: if someone were to improve http://qa.ubuntuwire.org/rdepends to report alternate dependencies, it would be easier to process these ;)
<slangasek> (less manual review of the output of reverse-depends)
<ginggs> tumbleweed: ^^^
<slangasek> I've mentioned this to tumbleweed before and he was ENOTIME
<ginggs> yeah, and he's organizing a debconf now
<tumbleweed> erm, IIRC it does report alternate dependencies, but doesn't resolve virtual ones
<tumbleweed> I seem to remember some people wanting it to *not* report alternate dependencies
<slangasek> tumbleweed: well, for my purposes it would be very useful *to* report alternate dependencies
<slangasek> who are these other people and how can I bribe them to agree with me ;)
<cjwatson> slangasek: yeah, one of these days we should beef up the removal tools to deal with bugs better
<cjwatson> it's kind of deeply annoying to deal with the two worlds in parallel
<bdmurray> slangasek: so fpc seems to be a bad test (http://autopkgtest.ubuntu.com/packages/f/fpc/xenial/amd64/) and its listed as a regression for binutils.  It deserves a hint then?
<cyphermox> hmm, perhaps that version number for ipmitool for xenial isn't so great
<bdmurray> I'm happy to reject it for you ;-)
<cyphermox> please :)
<wgrant> stgraber: As Colin says, there was no other option. Uploading a newer package with the patches reverted would have caused problems too. It took several hours for the security team to devise and validate a proper fix that could safely upgrade from both.
<wgrant> We had dozens of dead apaches, so it was pretty important to pull it ASAP.
<slangasek> bdmurray: hint> only question is, why does it show up as a regression given that this test never succeeded on xenial
<slangasek> bdmurray: so, fine to hint, but please also talk to pitti about why it's a "regression"
#ubuntu-release 2016-05-27
<wgrant> stgraber: Did the revert actually cause problems? Why did your machines care? The previous version was restored in the bad version's place, so it should only have prevented installations of exact versioned dependencies.
<stgraber> wgrant: I have a nagios check on all systems I managed which triggers if I have packages that are installed from an unknown source
<stgraber> wgrant: it usually indicates somebody screwed something up in the archive :)
<wgrant> Ah
<wgrant> Well in this case it indicated that you had a bad update, so working as intended.
<slangasek> hrm
<slangasek> where is https://launchpad.net/ubuntu/yakkety/arm64/inkscape/0.91-8ubuntu2 ?
<slangasek> y
<slangasek> have done some analysis on the gdal+poppler transition; pdf2htmlex needs a fix for an s390x build failure, inkscape I've reuploaded to correct the awol arm64 build, libreoffice has a FTBFS that needs sorted, and libgdcm-tools is broken upstream and will need removed or its uninstallability ignored
<tjaalton> mdeslaur: hi, shouldn't bug 1574727 have efibootmgr instead of efivar? or both?
<ubot5> bug 1574727 in shim-signed (Ubuntu Xenial) "[SRU] Enforce using signed kernels and modules on UEFI" [Undecided,New] https://launchpad.net/bugs/1574727
<mdeslaur> tjaalton: I'm not sure... cyphermox ^
<tjaalton> mdeslaur: the queue only has efibootmgr but the bug doesn't mention it
<tjaalton> as being affected
<cyphermox> tjaalton: indeed, it should have efibootmgr too, sorry. I found that out while testing -- the new efivar breaks the old efibootmgr
<tjaalton> cyphermox: heh, ok
<ginggs> michi: hi, would you have a look at the ftbfs in thumbnailer, please? i think it might be similar to failure in
<ginggs> persistent-cache-cpp
<bdmurray> slangasek: I'll be doing some more SRU reviews today as I'm still working on some tool changes to add release tasks to bugs, so feel free to skip your shift.
<slangasek> bdmurray: got it, thanks
<bdmurray> coreycb: With regards to your comment in bug 1546116 - what will the Liberty cloud archive do once Wily is EoL?
<ubot5> bug 1546116 in Ubuntu Cloud Archive liberty "[SRU] manila share process init script is missing" [Undecided,New] https://launchpad.net/bugs/1546116
<coreycb> bdmurray, once wily is EOL we will have to backport fixes directly to the cloud archive, but for now we go to wily, then backport to trusty-liberty
<sergiusens> arges hey, I know it's not your turn today, but any idea how long until snapcraft gets out of -proposed?
<sergiusens> asking in case I am missing a step
<arges> sergiusens: typically we try to avoid releasing on fridays unless its an emergency
<sergiusens> arges ok, so we are all set for a Monday release? As in, do I need to do anything or will it all happen on its own?
<arges> sergiusens: everything is verified LGTM
<sergiusens> thanks
<arges> sergiusens: also i won't be in on monday, but you can check the sru team member in the wiki for their day
<sergiusens> arges sounds good.
<infinity> I'll be around.  It'll escape on Monday.
<infinity> (Though, given the tiny current userbase of snapd, if there is an urgent need for promotion, I'd consider it)
<michi> ginggs: Just saw your ping. Iâm about to leave, but can look at it later today. (Itâs Sat here.) Do you have a build log link?
#ubuntu-release 2016-05-28
<ginggs> michi: here you go https://launchpad.net/ubuntu/+source/thumbnailer/2.4+16.04.20160321-0ubuntu2
#ubuntu-release 2017-05-22
<xnox> infinity, https://errors.ubuntu.com/ snap-install is high up there
<xnox> i wonder if anybody is looking at those, who shall i ping? mvo?
<infinity> xnox: I would think you should poke mvo about those two, yeah.
<apw> xnox, are those not both specific snap hook failures
<infinity> apw: Whatever they are, if they're registering as a "crash", something's not ideal.
<infinity> apw: Well, especially a "crash" in snapd.  So, maybe apport needs some logic, if the blame lies elsewhere.
<infinity> apw: (Much in the same way it doesn't blame dpkg for every aborted maintainer scripts)
<infinity> s/scripts/script/
<apw> infinity, indeed
<xnox> apw, it even smells like particular snaps failing or some such.
<ogra_> hmm, we had at least one user in the channel last week that had the same error ...
<ogra_> "cannot create lock directory /run/snapd/lock â Permission denied"
<ogra_> it might actually be a bug in snapd
<xnox> apw, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/s/systemd/20170520_150952_306ba@/log.gz is funny, src:systemd tests fail when running due to aws trigger as modules are missing. Is there aws-extra package that systemd test suite needs to opportunistically install?
<apw> xnox, there is not
<xnox> so i guess somehow, i need to detect "funny" kernels and skip the tests.
<xnox> do you want clean adt from systemd upon aws updates?
<xnox> (i wonder if other kernels are affected too, e.g. the other A kernel and the G kernel)
 * xnox giggles the FAANG kernels
<apw> xnox, we always want adt clean, so either we need to make that test check for and skip itself if there is no support for it, or reinstate that supprot in them
<infinity> xnox: "if modinfo scsi_debug >/dev/null; then run_test; fi"?
<xnox> infinity, i like that yes.
<infinity> Or, indeed, ask for scsi_debug to be included in linux-aws.  But if there's no solid argument for it outside of testsuites, it doesn't really belong in cloud kernels.
<xnox> i think scsi_debug is a liability in the cloud kernels.
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.29 => 2.30] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapcraft (yakkety-proposed/universe) [2.29+16.10 => 2.30+16.10] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapcraft (zesty-proposed/universe) [2.29+17.04 => 2.30+17.04] (no packageset)
<sergiusens> can I get those 3 reviewed? ^
<apw> sergiusens, i guess i can have a look
<apw> sergiusens, i assume artful is already uploaded
<sergiusens> apw: uploaded and in the release pocket
<sergiusens> thanks
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-79.100~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-79.100~14.04.1]
<xnox> apw, hm FANG kernels are only in xenial. But we do publish images for the non-lts releases too. Could the kernels be copied up?
<ginggs> would someone please remove 64-bit binaries of pixbros and pixfrogger from artful? packages have changed from arch:all to 32-bit only
<ginggs> also, please update p.itti's hints file and force-badtest r-cran-dplyr/0.5.0-1ubuntu2/armhf instead of r-cran-dplyr/0.5.0-1
<vtapia> Hi, could someone review the sssd upload in the queue for trusty?
<apw> xnox, i don't think that they were intended to be copies up
<apw> vtapia, can you confirm that Z/A are both ok ?
<vtapia> apw: yes, they are both ok :)
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (trusty-proposed) [1.11.8-0ubuntu0.6]
-queuebot:#ubuntu-release- Unapproved: accepted nagios3 [sync] (zesty-proposed) [3.5.1.dfsg-2.1ubuntu5.1]
-queuebot:#ubuntu-release- Unapproved: accepted nagios3 [sync] (yakkety-proposed) [3.5.1.dfsg-2.1ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: accepted nagios3 [sync] (xenial-proposed) [3.5.1.dfsg-2.1ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted nagios3 [sync] (trusty-proposed) [3.5.1-1ubuntu1.2]
<jbicha> libgit2 is stuck in artful-proposed: "old binaries left", libgit2-25 is left over from an accidental transition that was reverted the next day in unstable
<apw> jbicha, +really ugg
<apw> jbicha, and gone
<jbicha> yeah, there are too many affected packages for me to be confident about finishing the libgit2 transition very quickly in Ubuntu
<slashd> sil2100, could you please have a look at LP:# 1689854 ? isc-dhcp was built on "2017-05-15", the verification-done has been done the same day and the package passed the minimum aging period of 7 days. It prevent me for starting a new SRU for isc-dhcp. Thanks.
<rbasak> slashd: oh yes, I'm not sure if I forgot to mention - the SRU will have to be rebased on the latest, but I think that's just a minor changelog conflict to resolve as they're in entirely different areas.
<rbasak> FWIW the pending-sru report says days=6, not 7.
<slashd> rbasak, ack I count the days looking my laptop calendar
<slashd> rbasak, thanks for your reply for LP: #1176046 (binary split), I'll start the upload as soon as the current isc-dhcp is completed.
<ubot5> Launchpad bug 1176046 in isc-dhcp (Ubuntu Trusty) "isc-dhcp dhclient listens on extra random ports" [Wishlist,In progress] https://launchpad.net/bugs/1176046
<xnox> infinity, when is 16.04.3 scheduled for? because i need to know if i have time to land all the systemd srus i want to land =/
<xnox> and i have holidays and stuff
<jamespage> any MIR team members around? need a review for https://bugs.launchpad.net/ubuntu/+source/vine/+bug/1688091
<ubot5> Ubuntu bug 1688091 in vine (Ubuntu) "[MIR] vine" [High,New]
<jamespage> which is blocking up proposed for most of openstack at the moment
-queuebot:#ubuntu-release- Unapproved: ubuntu-fan (zesty-proposed/main) [0.12.2 => 0.12.2.1] (no packageset)
<bdmurray> slangasek: Could you have a look at u-r-u in zesty?
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (zesty-proposed) [1:17.04.8]
<bdmurray> slangasek: thanks
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (zesty-proposed) [2.30+17.04]
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (yakkety-proposed) [2.30+16.10]
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.30]
#ubuntu-release 2017-05-23
-queuebot:#ubuntu-release- Unapproved: mutter (zesty-proposed/universe) [3.24.1-0ubuntu1 => 3.24.2-0ubuntu0.1] (desktop-extra, edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-fan [source] (zesty-proposed) [0.12.2.1]
-queuebot:#ubuntu-release- New source: unity-mail (artful-proposed/primary) [1.7.5.1]
-queuebot:#ubuntu-release- Unapproved: qemu (zesty-proposed/main) [1:2.8+dfsg-3ubuntu2.2 => 1:2.8+dfsg-3ubuntu2.3] (ubuntu-server, virt)
<ginggs> Morning!  Would someone please update p.itti's hints file and force-badtest r-cran-dplyr/0.5.0-1ubuntu2/armhf instead of r-cran-dplyr/0.5.0-1 ?
<apw> ginggs, why are we not caring about armhf in that context ?
<apw> (given the other arches became happy)
<ginggs> apw: other arches became happy because I fixed a test that always failed, armhf seems to be a different problem and it is not new
<apw> ginggs, hmmm, ok i guess
<ginggs> apw: i figured happy tests on most arches are better than force-badtest everywhere
<apw> ginggs, yep i guess it is
<apw> and done
<ginggs> apw: thanks!
<ginggs> i think pixbros and pixfrogger require some removal from artful, they were arch:all, now 32-bit only - the 64-bit arches are complaining of missing builds
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-22.24] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-22.24]
-queuebot:#ubuntu-release- Unapproved: grub2 (yakkety-proposed/main) [2.02~beta2-36ubuntu11.2 => 2.02~beta2-36ubuntu11.3] (core)
-queuebot:#ubuntu-release- Unapproved: netcfg (xenial-proposed/main) [1.135ubuntu4.2 => 1.135ubuntu4.3] (core)
<slangasek> tsimonq2: so, was there a plan forward on how to make the lubuntu-next images buildable, now that we flagged that they were trying to use a non-existent task?
-queuebot:#ubuntu-release- Unapproved: lxc (trusty-proposed/main) [2.0.7-0ubuntu1~14.04.1 => 1.0.10-0ubuntu1] (ubuntu-server)
<slangasek> infinity, apw, wgrant, cjwatson, stgraber: any of you care to give feedback on https://code.launchpad.net/~vorlon/ddeb-retriever/python3/+merge/324233 ?
<tsimonq2> slangasek: Just needs an MP approved.
<tsimonq2> slangasek: I wanted feedback from gilir, he requested some changes, and I pushed the changes.
<slangasek> ok
<tsimonq2> slangasek: Since you're part of Core Dev, mind having a look? https://code.launchpad.net/~tsimonq2/livecd-rootfs/proper-task-names/+merge/324017
<slangasek> tsimonq2: weren't we trying to get away from the no-install-recommends, even for lubuntu? <-- infinity
-queuebot:#ubuntu-release- Unapproved: nplan (xenial-proposed/universe) [0.21~16.04.1 => 0.22~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnome-software (zesty-proposed/main) [3.22.7-0ubuntu3.17.04.2 => 3.22.7-0ubuntu3.17.04.4] (ubuntu-desktop)
<cjwatson> slangasek: +1 with some extra suggestions
<infinity> slangasek: That was, indeed, a goal, but I'm not going to force it on them either.
<slangasek> k. tsimonq2: merged
<slangasek> hngh no changelog entry for it, hohum
-queuebot:#ubuntu-release- New binary: r-bioc-genomeinfodbdata [amd64] (artful-proposed/universe) [0.99.0-1] (no packageset)
#ubuntu-release 2017-05-24
<jbicha> RAOF: sphinx is an interesting SRU, it's reached its 7 days now, I'd like it released to -updates so that webkit2gtk updates will pass their autopkgtests without manual intervention
<jbicha> but, there are rdepends that now fail their autopkgtests but it doesn't look like it's because sphinx changed in this SRU
<RAOF> Ok, I'll check it out.
<RAOF> Once I work out why no internet!
-queuebot:#ubuntu-release- Unapproved: gnome-software (yakkety-proposed/main) [3.20.1+git20170509.0.8292905-0ubuntu1 => 3.20.1+git20170524.0.ea2fe2b0-0ubuntu0.16.10.1] (ubuntu-desktop)
<RAOF> So many Xenial SRUs that could be released if only Yakkety failures were resolved... :(
<RAOF> Woot!
<RAOF> Now with a working Cat5 cable!
-queuebot:#ubuntu-release- Unapproved: gnome-software (xenial-proposed/main) [3.20.1+git20170509.0.8292905-0ubuntu1~xenial1 => 3.20.1+git20170524.0.ea2fe2b0-0ubuntu0.16.04.1] (ubuntu-desktop)
<wolsen> whenever possible, it'd be much appreciated to get a sponsor for bug 1683076
<ubot5> bug 1683076 in swift (Ubuntu Xenial) "Swift-storage dies if rsyslog is stopped" [Critical,New] https://launchpad.net/bugs/1683076
-queuebot:#ubuntu-release- Unapproved: swift (xenial-proposed/main) [2.7.1-0ubuntu1 => 2.7.1-0ubuntu1.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: swift (trusty-proposed/main) [1.13.1-0ubuntu1.2 => 1.13.1-0ubuntu1.3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: telegram-desktop (zesty-proposed/universe) [1.0.29-1 => 1.0.29-1ubuntu1.17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted netcfg [source] (xenial-proposed) [1.135ubuntu4.3]
-queuebot:#ubuntu-release- New binary: debian-med [amd64] (artful-proposed/universe) [3.0.1ubuntu1] (no packageset)
<ginggs> is britney on vac today?
<apw> hmmm
<apw> ginggs, possible it is less britney and more the publisher ... hmmm
<mdeslaur> publisher doesn't seem to be working, I've been waiting over an hour and a half now
<ginggs> publisher you had one job
<apw> yeah the publisher is sad, people are looking
<cjwatson> Yeah, override generation got stuck for some reason.  I killed the stuck job and am keeping an eye on it.
<mdeslaur> thanks
 * sil2100 was waiting for a signed kernel to publish since the morning
 * mdeslaur bribes publisher with plate of fancy cakes
<cjwatson> Do feel free to mention unusual-looking delays :)
<apw> yeah it had gotten to 5 hours since i'd seen anything change, 3 hours i can imagine kde making :)
<mdeslaur> ah! the cakes worked :)
<mdeslaur> thanks cjwatson
<ginggs> with a bit of luck, soon the only things blocking the r-base migration will be r-cran-spatstat on armhf and s390x, tests segfault with 'memory not mapped'. could we run these tests on large instances, please?
<xnox> there are no instances for either of those arches.
<xnox> the tests are run inside lxd/lxc containers on those architectures
<ginggs> xnox: but can those containers run on large instances?  i seem to recall this working previously
<xnox> ginggs, these are containers running on physical hardware....
<xnox> baremetal... they are not "instances" that one can "resize" =)
 * xnox wishes we could just "resize" physical servers =)
<xnox> it is possible those tests get blocked by security policies of the container.
<ginggs> xnox: so would adding r-cran-spatstat to big_packages not have any effect on armhf and s390x?
<xnox> i don't have access to do that, or check what the effect would be.
<xnox> Laney, ^ ?
<Laney> that's not a thing
<ginggs> xnox, Laney: thanks, i must be confused
<Laney> it's a thing for cloud but not for those arches
-queuebot:#ubuntu-release- Unapproved: isc-dhcp (trusty-proposed/main) [4.2.4-7ubuntu12.9 => 4.2.4-7ubuntu12.10] (core)
-queuebot:#ubuntu-release- Unapproved: isc-dhcp (xenial-proposed/main) [4.3.3-5ubuntu12.6 => 4.3.3-5ubuntu12.7] (core)
<slashd> rbasak, good day, I just uploaded isc-dhcp for Trusty and Xenial in their respective upload queues, could you please have a look and make them start building in -proposed (if all the criteria are meet) ?
<slashd> arges, ^^
<sil2100> slashd: I can take a look at those if others are busy
<sil2100> rbasak: taking those if you're ok with that ^
<sil2100> hm, ok, I see rbasak was handling this before, so maybe I should leave it to him after all, since he has all the context
<slashd> sil2100, ack, yeah let's see if rbasak will take it or not since he know all the context of it
<slashd> sil2100, tks for offering
<rbasak> slashd, sil2100: I'll take a look. If it's identical to what I reviewed, then I only need a cursory check.
<rbasak> slashd: I appreciate the fixing up of the descriptions and changelog wrapping etc.
<rbasak> slashd: it'd be nice if you could control your editor to avoid extra trailing whitespace everywhere though. It's ugly and my syntax highlighter is showing red everywhere.
<slashd> rbasak, will pay attention to that
<rbasak> slashd: also the Trusty debian/changelog is going >80 characters
<rbasak> and you have tabs in there
<Laney> set list lcs=tab:Â»Â·,trail:Â· :-)
<slashd> rbasak, weird let me check
<slashd> rbasak, want me to fix the >80 character ? and tabs ?
<rbasak> slashd: yes please. That's for Trusty. Xenial's wrapping is OK, and the trailing whitespace I can cope with.
<slashd> rbasak, so you'll reject Trusty ? and I'll re-upload it ? or I can overwrite the actual one ?
<rbasak> You can re-upload over the top. I'll reject the old one, but that doesn't block the upload of your replacement.
<slashd> rbasak, so no problem keeping the same pkg version ? just to make sure
<rbasak> slashd: correct. Same version. Just edit the changelog entry in-place and reupload.
<slashd> rbasak, ok I'll do the modification and re-upload in the next hour tks
<rbasak> dput will reject unless you delete the .upload file first.
<slashd> rbasak, right
-queuebot:#ubuntu-release- Unapproved: rejected isc-dhcp [source] (trusty-proposed) [4.2.4-7ubuntu12.10]
-queuebot:#ubuntu-release- Unapproved: systemd (zesty-proposed/main) [232-21ubuntu3 => 232-21ubuntu4] (core)
<cyphermox> rbasak: could you reject grub2  	2.02~beta3-4ubuntu2.1 from the zesty queue?
<cyphermox> (please)
<cyphermox> leave grub2-signed; it's still good, but grub2 is missing a bit.
-queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (zesty-proposed) [2.02~beta3-4ubuntu2.1]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (xenial-proposed/main) [4.10.0-22.24~16.04.1] (kernel)
<xnox> apw, could the SRUs for the #1618463 be deleted? the proposed fix is not actually needed, as the software works correctly. The bug itself is invalid, as the bug is between chair and keyboard as was pointed out to us by the vendor.
<xnox> i will be SRUing revert into zesty, and already uploaded revert into artful.
<xnox> or shall i just trump current SRU with a revert, + the new bugfixes we do need to fix?
<apw> xnox, which package is that ...
<xnox> s390-tools in xenial-proposed and yakkety-proposed
<apw> xnox, gone
<xnox> whoop whoop.
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-9.3 [sync] (trusty-proposed) [9.3.17-0ubuntu0.14.04]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (xenial-proposed) [4.10.0-22.24~16.04.1]
<slashd> rbasak, re-upload for Trusty
-queuebot:#ubuntu-release- Unapproved: isc-dhcp (trusty-proposed/main) [4.2.4-7ubuntu12.9 => 4.2.4-7ubuntu12.10] (core)
-queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (zesty-proposed) [1.4.4-1ubuntu3.1]
<ginggs> would someone please review r-bioc-genomeinfodbdata in artful NEW? it only contains data files that were shipped in r-bioc-genomeinfodb previously
<slangasek> ginggs: no, but I will wave it through as a Debian sync :)
<ginggs> slangasek: handwaving accepted, thanks
-queuebot:#ubuntu-release- New: accepted r-bioc-genomeinfodbdata [amd64] (artful-proposed) [0.99.0-1]
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-proposed/main) [2.13-0ubuntu3~ubuntu16.04.1 => 2.0.10-0ubuntu1~16.04.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: grub2 (zesty-proposed/main) [2.02~beta3-4ubuntu2 => 2.02~beta3-4ubuntu2.1] (core)
<tsimonq2> slangasek, infinity: Sooooo lubuntu-next livefs building was FINALLY successful, but it's failing because of the following... I assume there's a place that I specified the location for this (and it's incorrect), orrr is it built-in tooling that's being fun?
<tsimonq2> * Fetching branch of http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/lubuntu-next.artful/
<tsimonq2> bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/lubuntu-next.artful/".
<tsimonq2> ! Could not open STRUCTURE from checkout of (any of):
<ubot5> tsimonq2: I am only a bot, please don't think I'm intelligent :)
<tsimonq2> !   http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/lubuntu-next.artful
<ubot5> tsimonq2: I am only a bot, please don't think I'm intelligent :)
 * tsimonq2 kicks ubot5 "{
<tsimonq2> *:P
<slangasek> tsimonq2: where does that error happen? AFAIK the correct branch is lp:~lubuntu-dev/ubuntu-seeds/lubuntu.artful/
<tsimonq2> slangasek: http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu-next/artful/daily-live-20170524.log
<tsimonq2> Actual file:
<tsimonq2> CalledProcessError: Command '['/srv/cdimage.ubuntu.com/germinate/bin/germinate', '--seed-source', 'http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/', '--mirror', 'file:///srv/cdimage.ubuntu.com/scratch/lubuntu-next/artful/daily-live/germinate/', '--seed-dist', 'lubuntu-next.artful', '--dist', 'artful,artful-security,artful-updates', '--arch', 'amd64', '--components', 'main',
<tsimonq2> '--no-rdepends', '--bzr']' returned non-zero exit status 1
<tsimonq2> afaict that's called from:
<tsimonq2>  File "/srv/cdimage.ubuntu.com/bin/../lib/cdimage/build.py", line 758, in build_image_set_locked
<tsimonq2>     germination.run()
<tsimonq2> slangasek: And yes, the branch you said is the correct one.
<slangasek> tsimonq2: I believe you need to patch lib/cdimage/germinate.py:seed_sources() in lp:ubuntu-cdimage
<tsimonq2> slangasek: ack
<slangasek> tsimonq2: and also seed_dist()
<tsimonq2> slangasek: Ok. And also, do I have access to rebuild lubuntu-next images, or is that something you guys have to do on the ~core-dev/Archive Admin side?
<slangasek> tsimonq2: rebuilds are triggered through iso.qa.ubuntu.com; per-flavor product owners should have access to rebuild
<slangasek> I don't know if you currently have access or not, I would have to dig in to see and I'm currently in a meeting
<tsimonq2> slangasek: It doesn't look like it's even on iso.qa.ubuntu.com... Any chance you could dig in when you have a min? :)
<tsimonq2> That being said, we don't even have artful images on there yet...
<slangasek> http://iso.qa.ubuntu.com/qatracker/milestones/376/builds is there
<tsimonq2> Oh...
<tsimonq2> Weird
<tsimonq2> Didn't see it on my end...
<tsimonq2> slangasek: But yeah, no Lubuntu Next :)
<tsimonq2> slangasek: fwiw it isn't really something I need RIGHT NOW, but as soon as we have working Lubuntu Next images, I'd certainly like access.
<tsimonq2> s/access/access to rebuild/
<tsimonq2> slangasek: Would you be OK with me explicitly specifying pattern in seed_sources, or do you need me to actually put in the functionality allowing for multiple seeds at one bzr branch?
<tsimonq2> :P
<slangasek> tsimonq2: there should be existing examples there that you can crib from
<tsimonq2> slangasek: That isn't the case here.
<tsimonq2> slangasek: This is what's modified in the if/else code: pattern = "http://bazaar.launchpad.net/~%s/ubuntu-seeds/"
<tsimonq2> slangasek: It looks like it just takes the project name and appends it on the end.
<tsimonq2> slangasek: Am I mistaken here?
<slangasek> tsimonq2: the appended part is why you need to also change seed_dist()
<tsimonq2> slangasek: Ahhhh ok, yeah, that makes sense.
<tsimonq2> slangasek: https://code.launchpad.net/~tsimonq2/ubuntu-cdimage/lubuntu-next-germinate/+merge/324571
<slangasek> tsimonq2: I've done all the setup of lubuntu-next as a project on the ISO tracker, but I don't see anything in the web ui to let me add people to groups and I don't recall where else that might live. I think we'll need to get stgraber's help
<tsimonq2> slangasek: Well afair flocculant did Ubuntu Budgie's, so he might know?
<stgraber> slangasek: it's rather well hidden
<tsimonq2> ohai stgraber :D
<tsimonq2> nvm flocculant
<slangasek> tsimonq2: 'elif project == "lubuntu" or "lubuntu-next"' is written 'elif project in ("lubuntu", "lubuntu-next")' (cf the kubuntu-plasma handling above)
<stgraber> slangasek: so looks like you tied Lubuntu Next to the "lubuntu release" role, so that should actually be all good already
<slangasek> stgraber: we don't think tsimonq2 is in that role
<slangasek> or we don't know
<tsimonq2> I am.
<slangasek> oh
<tsimonq2> I can rebuild lubuntu images
<slangasek> you didn't say ;)
<tsimonq2> That happened as of... February something?
<stgraber> "lubuntu release" maps to ~lubuntu-product-managers on launchpad
<slangasek> that's transparent
<stgraber> slangasek: http://iso.qa.ubuntu.com/admin/config/services/openid_teams if you're admin enough to access :)
<tsimonq2> Well then consider this my indication... I'm Lubuntu Release Manager as of https://lists.ubuntu.com/archives/lubuntu-devel/2017-February/000968.html and should have all the relevant permissions if wxl didn't screw anything up ;) XD
<slangasek> tsimonq2: branch merged with the above adjustment, and deployed; you should be able to try a respin now
<stgraber> slangasek: QA products are tied to Drupal roles which are then tied to OpenID roles coming from SSO that are themselves LP teams
<tsimonq2> slangasek: ack
<stgraber> so yeah, not the easiest thing to track down :)
<slangasek> stgraber: yeah, I can't see that link. who all are the admins and why is it not a 1:1 for the nusakan admins?
<tsimonq2> Hmm, why wouldn't http://iso.qa.ubuntu.com/qatracker have Artful yet?
<stgraber> hmm, ubuntu release is linked to the "ubuntu iso admin" role, that should have been enough...
<stgraber> tsimonq2: it does, look at the bottom :)
<tsimonq2> stgraber: Oh... why... :P
<stgraber> tsimonq2: sorting is hard
<tsimonq2> stgraber: heh
<tsimonq2> stgraber: I got that :P
 * tsimonq2 sips more coffee
<stgraber> slangasek: try logging out and back in, being in ~ubuntu-release should now get you full admin
<slangasek> stgraber: looks good, thanks!
<slangasek> well I mean, the UI makes me sad
<slangasek> but I definitely have more privs now ;)
<stgraber> :)
<slangasek> stgraber: what url should actually show me the 'lubuntu release' -> ~lubuntu-product-managers mapping?
<stgraber> slangasek: http://iso.qa.ubuntu.com/admin/config/services/openid_teams
<slangasek> stgraber: ta
<tsimonq2> slangasek: Any success so far? :)
<slangasek> tsimonq2: success with what?  I'm done and turned it over to you to trigger rebuilds :)
<tsimonq2> slangasek: Uhm... but where is it?
<tsimonq2> slangasek: I don't see it on http://iso.qa.ubuntu.com/qatracker/milestones/376/builds
<tsimonq2> slangasek: Maybe I just don't know all the ways to trigger a rebuild? :P
<infinity> It won't be on the tracker until it's had at least one successful run.
<slangasek> tsimonq2: ok; ISTR having this before, where you can't 'rebuild' unless there's first been a successful build right
<slangasek> so I'll retrigger from my end
<tsimonq2> Ack
<tsimonq2> infinity, slangasek, stgraber: Gracias por la ayuda. :)
<slangasek> tsimonq2: no hay de que (y cuidado con la lengua en este canal si no pretendes practicar de veras)
<stgraber> :)
 * infinity wonders if he accidentally joined #ubuntu-release-es
<tsimonq2> slangasek: Heyyy, yo aprendiendo EspaÃ±ol en mi escuela. :P
<slangasek> infinity: #ubuntu-rel-es por favor
<tsimonq2> infinity: Necesitamos #ubuntu-release-es porque EspaÃ±ol es divertido. :P
 * tsimonq2 stops speaking Spanish for now :P
<slangasek> tsimonq2: Â¿cuÃ¡nto tiempo suele tardar el construyo en fallar?
<infinity> slangasek: #ubuntu-rel-es-es?
<infinity> Also, I love that there's an inverted interrobang called gnaborretni.
<infinity> Though, I don't know how to compose it.
<infinity> â¸â½
<infinity> Ah-ha.
<infinity> Just the inverse sequence.
<tsimonq2> slangasek: No sÃ©... generalmente una hora y treinta minutos pero varÃ­a.
<slangasek> hmm eso es mucho
<slangasek> pero vale, esperemos
<cyphermox> slangasek: infinity: I'm curious about sponsor logos appearing in slideshow source; could you give your 2 pesos on https://code.launchpad.net/~aaronhoneycutt/ubiquity-slideshow-ubuntu/artful/+merge/324285 ?
<tsimonq2> cyphermox: "2 pesos" lol
<cyphermox> oh, I had failed to see it was even in a big file all together... yuck
<cyphermox> ahoneybun: ^
<tsimonq2> slangasek: No sÃ© exactamente... soooo :P
<cyphermox> (as in, usually people would complain that you muck with their trademark logos by putting them together, so I'd ask the sponsors directly...)
<tsimonq2> cyphermox: It's on kubuntu.org. I saw the discussion on the KC side about it and generally people were OK with it because it's already on the site...
<cyphermox> being on the site is not the same as being in public source, and/or being in one large image.
<tsimonq2> But having Steve's and Adam's 2 pesos is probably a good thing, I agree.
<tsimonq2> cyphermox: Good point.
<cyphermox> admittedly, IANAL, but trademark/copyright law is complex and fraught with peril
<cyphermox> for this kind of thing, I rather be extra extra cautious
<tsimonq2> slangasek: Ohhhh... el construyo por livefs o todos?
<tsimonq2> slangasek: Porque mi estimacion es por todos los procesos...
<tsimonq2> slangasek: Your turn to fix the failure :P http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu-next/artful/daily-live-20170524.1.log
<tsimonq2> slangasek: (because it's on the ISO QA tracker side)
<slangasek> and needs the name adjusted, ack
<slangasek> tsimonq2: it does seem like the image built, at least
<slangasek> tsimonq2: and is oversized ;P
 * infinity is trying really hard not to respond with "So's your mom".
<slangasek> tsimonq2: habiendo cambiado el nombre, lanzo de nuevo el construyo
<slangasek> cyphermox: which logos specifically are you concerned about / in what file?
<infinity> I think he's referring to slideshows/kubuntu/slides/11_Sponsors.html
<tsimonq2> slangasek: Gracias
<slangasek> infinity: the .png that references appears to not be a file added as part of this diff?
<infinity> slangasek: Dunno.  I just pulled the merge and ran the slideshow test.
<infinity> slangasek: http://lucifer.0c3.net/~adconrad/logos.png
<infinity> slangasek: Because the best thing to do when one suspect a copyright violation is to make more copies.
<tsimonq2> lol
<ahoneybun> infinity: slangasek it's in the screenshot dir
<ahoneybun> sponsors-slide
<ahoneybun> it's all one image
<infinity> ahoneybun: Are they free use logos?   And are you violating anyone's weird trademark requirements (must have X amount of whitespace, can't be shown near a mark of someone who sell boneless chicken burgers, because boneless chickens are just plain wrong, etc)?
<jbicha> it's very common for logo policies to specify that logos need plenty of padding (they shouldn't be placed so closely to other logos)
<ahoneybun> tbh I did not look that up
<jbicha> like it almost looks like Launchpad is part of Linode in that screenshot
<ahoneybun> like I said tho it's all one image to take down
<ahoneybun> if it can't be included
<infinity> I appreciate the sentiment (and I expect your sponsors would too), and we already give trademarks a pass on not needing to meet DFSG requirements for modification, but you should probably make sure you're respecting whatever licenses and requirements they have, so they see it as a Good Thing rather than an abuse of their mark.
<doko> I love -O3 on ppc64el :-/
<ahoneybun> infinity: prehaps take it out for now and add it later in?
<infinity> cyphermox: ^
<ahoneybun> I'd like to get the new slides design in asap before a freeze or something
<ahoneybun> also test how they look on a live iso
<acheronUK> that slide does look untidy :/
<acheronUK> like someone took a load of logo fridge magnets and threw them at a fridge door. and accepted where they stuck
<infinity> acheronUK: At least they're all right side up?  That's some solid magnet-tossing skill right there.
<acheronUK> infinity: lol. true
 * acheronUK would have been obsessive enough to straighten then in place after throwing though
 * Ukikie gives acheronUK a magnet, magnet:?xt=urn:btih:aee3499cb4276c6f15bed91705717cb2c02100b2&tr=http://torrent.ubuntu.com:6969/announce
<ahoneybun> cyphermox: pushed some text changes and removed the sponsors slide for now
<cyphermox> ahoneybun: ack
<cyphermox> (sorry, I went to cook and eat dinner)
 * ahoneybun messes with his Nextcloud
<tsimonq2> Oh, wonderful.
<tsimonq2> The Lubuntu Next image boots... but has an "unsupported arguments" error, right after launching an unthemed Openbox session...
<tsimonq2> That'll be fun to fix ^.^
<Ukikie> Yeah, throw some theming on that Openbox session, it'll look pretty fantastic.
<tsimonq2> Ukikie: No, but right now it's literally Openbox with an error message... :P
<ahoneybun> thanks <3 cyphermox
<cyphermox> it's uploading too, just a big tarball
<cyphermox> tsimonq2: are you doing autologin?
<cyphermox> I seem to recall some display manager had issues with a setup we used for autologin (though it was for oem)
<cyphermox> also if you changed things, like the live session username, and the dm doesn't know about it, it would fail... so two things to look at for starters :)
<cyphermox> I would expect things to work though, as casper just reads casper.conf, and livecd-rootfs knows how to write that.
#ubuntu-release 2017-05-25
<tsimonq2> cyphermox: Totally unsure >_<
<tsimonq2> cyphermox: I'll find that out...
<tsimonq2> cyphermox: Also, I'm going to have to have a look at getting us a Qt slideshow that isn't completely Kubuntu branded >_<
<tsimonq2> cyphermox: s/slideshow/ubiquity/
<cyphermox> tsimonq2: Qt shouldn't mean that the slideshow is kubuntu branded
<cyphermox> in any case, that would be in ubiquity
<tsimonq2> cyphermox: Hm, let's see which packages are in the seed for lubuntu-next live...
<cyphermox> bbl, it's an ice cream break.
<tsimonq2> !info ubiquity-frontend-kde
<ubot5> ubiquity-frontend-kde (source: ubiquity): KDE frontend for Ubiquity live installer. In component universe, is optional. Version 17.04.9 (zesty), package size 66 kB, installed size 536 kB
<tsimonq2> Ah, ok, so it is part of ubiquity. Got it.
<ahoneybun> yep tsimonq2
<ahoneybun> blaze and I fixed it a release or two ago
<ahoneybun> when PyQt4 dropped webkit
<ahoneybun> so we moved it to PyQt5
<tsimonq2> ahoneybun: Mind if I fork?
<ahoneybun> it's not mine
<ahoneybun> fork what?
<tsimonq2> ahoneybun: Or maybe move to a common base that Kubuntu and Lubuntu Next can just share?
<tsimonq2> The Qt part of the ubiquity frontend.
<ahoneybun> I'm not sure what you mean
<ahoneybun> ohhh
<tsimonq2> Yeah :)
<ahoneybun> fork it I guess
<ahoneybun> but ubiquity provides the main UI on the side with the progress
<tsimonq2> Yeah
<ahoneybun> the progress bar on the bottom is that -kde frontend
<ahoneybun> the slides are ubiquity-slideshow-ubuntu
<tsimonq2> ahoneybun: Are there KDE Frameworks libraries used?
<tsimonq2> Oh, doesn't look like it?
<tsimonq2> In that case we can make something work.
<ahoneybun> it's just python I think
<tsimonq2> Yay!
<ahoneybun>  /ubiquity/artful/ubiquity/frontend
<ahoneybun> kep
<ahoneybun> kde_ui.py
<tsimonq2> Oh bah, there is KDE frameworks in there...
<tsimonq2> Ugh
<ahoneybun> where?
<tsimonq2> from ubiquity.frontend.kde_components import ProgressDialog
<tsimonq2> from ubiquity.frontend.kde_components.Breadcrumb import Breadcrumb
<tsimonq2> from ubiquity.frontend.kde_components import qssutils
<tsimonq2> In kde_ui.py
<ahoneybun> most likely KDE4 stuff
<ahoneybun> nah
<ahoneybun> Qt5 now
<ahoneybun> I mean you should just need to hook inot the kde qt frontend
<tsimonq2> I'll try getting a minimal LXD container and just installing that package and seeing what mess it pulls in.
<tsimonq2> If it pulls in three quarters of all KDE Frameworks then I'm noping out and rewriting it :P
<ahoneybun> well the frameworks should be small now
<ahoneybun> well in small pieces lol
<ahoneybun> just be happy your not the first Qt based distro tsimonq2
<ahoneybun> then it would be worse
<tsimonq2> Yeah lol
 * ahoneybun has a new domain
<tsimonq2> :D
<ahoneybun> and they gave me a long IP for this new linode
<ahoneybun> damn it
<ahoneybun> I want an .xyz domain
<cyphermox> tsimonq2: all you really should have to do is remove obvious branding that is directly in ubiquity for the "KDE UI" which is really just a pretty standard Qt GUI, and in doing so no fork but just making things customizable (there should be plenty of examples of generic stuff in the Gtk sections)
<cyphermox> also, might I suggest not using the Qt GUI if possible, unless you plan on spending a lot of time on it, it's definitely not as well tested as the rest (fewer users, it needs some work for other issues that were noticed)
<tsimonq2> cyphermox: Then what would we use if not the Qt GUI?
<tsimonq2> I don't want to include a bunch of GTK libraries just to run Ubiquity...
<cyphermox> I mean, it's *important* that it works, for whomever wants to use it, but there are few people looking at ubiquity regularly... and by few I mean mostly just me, maybe xnox, and possibly infinity?
<cyphermox> if you have time to hack on the Qt GUI to make it real solid, by all means :)
<xnox> yes, i do.
<cyphermox> xnox: yeah, but it's not your main focus
<xnox> tsimonq2, did you fall into the trap of not specifying which frontend you want?
<cyphermox> xnox: no, they actually want Qt.
<cyphermox> I'm just expressing my concern for the Qt GUI not being as well tested so far, because it's only used by Kubuntu
<xnox> tsimonq2, i believe there is qt4, qt5 frontends, but both are /kde/ frameworks based. I believe there was a QML frontend in progress, not sure if it is merged or not.
<tsimonq2> xnox: :/
<cyphermox> there is?
<xnox> a pure QML kdeframeworkless frontend would be nice.
<cyphermox> afaik it's all only Qt5.
<cyphermox> xnox: none of ubiquity requires KDE really, AFAIK
<xnox> there was a branch by somebody either on launchpad, or something werid like a tarball import on github.
<tsimonq2> xnox: That would be my end goal, here.
<xnox> taking kde frontend as a starting point and moving that to qml would be a way forward.
<xnox> unless you somehow can google up previous efforts of the same.
<xnox> a QML subiquity frontend would be awesome too ;-)
<tsimonq2> xnox: You mean sub-iquity?
 * tsimonq2 is a "super big fan" of the naming choice on that one :P
<xnox> yeah, new iteration of installer tech, based on cloud/maas experience. subiquity = server ubiquity
<tsimonq2> xnox: But yeah, I'll probably use that as my starting point though.
<cyphermox> xnox: that would probably be a major undertaking, it's *not at all* the same thing as the usual desktop installer.
<xnox> sure.
<tsimonq2> Soooo it's sub-iquity then? :D
<xnox> tsimonq2, so looking at ubiquity kde frontend it is pure qt so far.
<tsimonq2> xnox: Excellent! But does it depend on KDE Frameworks?
<xnox> the bits that say from ubiquity.frontend.kde_components are the custom /ubiquity/ widgets for Qt.
<xnox> so should not need any KDE frameworks.
<cyphermox> nope.
<cyphermox> maybe ksmserver, whatever that is
<cyphermox> probably easy enough to make optional.
 * xnox wonders if i'm looking at old xenial qt4 build though, one second
<cyphermox> xnox: don't worry, there isn't much to look at; I have an up to date branch here.
<xnox> curently requires kde-window-manager but that's probably because the ubiquity-dm is not ported to not use that.
<xnox> tsimonq2, you may want to fix that ^
<xnox> there are no dependeinds declared on kdeframework anything
<xnox> ubiquity-dm is the only thing that call into kde, and should be ported to support whatever LXQT wants.
<tsimonq2> xnox: Yeah, it was recently ported to Qt 5.
<cyphermox> tsimonq2: short story, don't hesitate to ask on #ubuntu-installer if you have questions
<tsimonq2> cyphermox: OK :)
<cyphermox> xnox or I can answer :)
<tsimonq2> I wonder how easy it would be to have some common Qt libraries between Lubuntu LXQt and Kubuntu and just have some elements customized...
<cyphermox> tsimonq2: at first glance you have almost nothing to do; but I haven't seen your new image, you mentioned there was some stray branding from kubuntu.
<cyphermox> tbf, there probably should not be any branding in ubiquity directly, that belongs to the theming, $flavour-default-settings, u-slideshow-$flavour and whatnot
<tsimonq2> cyphermox: tl;dr, on a system with a wired connection, boot the image into "Try Without Installing," Click OK when it gets to the X error, then right-click and select the terminal emulator. Then run ubiquity from there, and you'll see what I'm talking about irt.
<tsimonq2> s/irt/irt this/
<cyphermox> ok
<tsimonq2> I did it in virt-manager, but ymmv
<cyphermox> oh boy, this is doing to take a while to download
<tsimonq2> Yeeeah, hopefully in the future we'll slim that down... :P
<cyphermox> it's not about that, somehow my tubes are slow
<cyphermox> I will let it download, and catch up on it / on scrollback tomorrow morning.
<cyphermox> tsimonq2: if you figure it in the meantime I'll be happy to review and merge a MP.
<tsimonq2> cyphermox: ack :)
<ahoneybun> any branding is done with a kubuntu.svg file in ubiquity
<ahoneybun> just add the lubuntu one, make a change to one line and done
<ahoneybun> tsimonq2: ^
<tsimonq2> ahoneybun: ack :P
-queuebot:#ubuntu-release- Unapproved: thunar (zesty-proposed/universe) [1.6.11-1 => 1.6.11-1ubuntu0.17.04.1] (mythbuntu, xubuntu)
-queuebot:#ubuntu-release- Unapproved: thunar (yakkety-proposed/universe) [1.6.11-0ubuntu0.16.10.1 => 1.6.11-0ubuntu0.16.10.2] (mythbuntu, xubuntu)
-queuebot:#ubuntu-release- Unapproved: thunar (xenial-proposed/universe) [1.6.11-0ubuntu0.16.04.1 => 1.6.11-0ubuntu0.16.04.2] (mythbuntu, xubuntu)
-queuebot:#ubuntu-release- Unapproved: xfce4-weather-plugin (xenial-proposed/universe) [0.8.6-1 => 0.8.9-0ubuntu0.16.04.1] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- New source: python-pypowervm (artful-proposed/primary) [1.1.4-0ubuntu1]
<ginggs> r-base is ready to migrate except for r-cran-spatstat on armhf and s390x http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#r-base i tried running it in lxc on amd64 locally, and it failed the first time, but not the 2nd time when i added -s . any ideas please?
<alan_g> I'm trying to update the version of mir in 16.04 (SRU bug 1685186): it's reached minimum age in -proposed. Can we please proceed to -updates?
<ubot5> bug 1685186 in mir (Ubuntu) "[SRU] Mir needs to be updated to 0.26 in 16.04LTS" [High,In progress] https://launchpad.net/bugs/1685186
<apw> alan_g, this seems to leave xenial with a newer version than in well everything after, thats not good for an upgrade perspective
<alan_g> apw: next on my list is 0.27 for artful. You're concerned with zesty though?
<apw> alan_g, the rules are concerned with all releases, they say you can't have a version in xenial that is higher than yakkety etc
<apw> alan_g, not actually sure how this got accepted into -proposed as things stand
<apw> tjaalton, ^^ ?
<alan_g> So, we'd need to release a 0.26.4 version on yakkety and zenial? (0.26.3 has been tweaked to build for xenial, so that would need reverting)
<Laney> ginggs: Let's skip those
<apw> alan_g, well something with a version number higher than that in xenial would be the norm yes; for y z and a.  unless you have some kind of exception i am unaware of (and i could be)
<ginggs> Laney: thanks
<alan_g> How would I go about justifying an exception?
<alan_g> The way we get here is that the 0.26 series was used for xenial+overlay and that was used for IoT projects on Ubuntu Core. We want to drop "overlay" now but maintain the same Mir support.
<apw> alan_g, it is not clear how this would be possible without truly breaking updates, but you are LTS oriented; slangasek ^ ?
<alan_g> Updating zesty from 0.26.2 to 0.26.4 would be simple enough. Yakkety was on an earlier series, so that would cause some issues.
<alan_g> But the only people I think might care are UbuntuCore users that need "kiosk", or developers who I don't expect to be targeting yakkety.
<jbicha> alan_g: technically, if you are not in a hurry and don't want to update Yakkety, then you could just wait until July when Yakkety is EOL
<jbicha> but I think all that's being asked for now is that Yakkety has a higher version number than Xenial so that upgraders don't have a package newer than what is available in the archives
-queuebot:#ubuntu-release- Unapproved: rejected isc-dhcp [source] (trusty-proposed) [4.2.4-7ubuntu12.10]
<slashd> rbasak, uploaded
<rbasak> ack
-queuebot:#ubuntu-release- Unapproved: isc-dhcp (trusty-proposed/main) [4.2.4-7ubuntu12.9 => 4.2.4-7ubuntu12.10] (core)
-queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (trusty-proposed) [4.2.4-7ubuntu12.10]
-queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (xenial-proposed) [4.3.3-5ubuntu12.7]
-queuebot:#ubuntu-release- New binary: isc-dhcp [i386] (trusty-proposed/main) [4.2.4-7ubuntu12.10] (core)
-queuebot:#ubuntu-release- New binary: isc-dhcp [ppc64el] (trusty-proposed/main) [4.2.4-7ubuntu12.10] (core)
-queuebot:#ubuntu-release- New binary: isc-dhcp [powerpc] (trusty-proposed/main) [4.2.4-7ubuntu12.10] (core)
-queuebot:#ubuntu-release- New binary: isc-dhcp [amd64] (trusty-proposed/main) [4.2.4-7ubuntu12.10] (core)
-queuebot:#ubuntu-release- New binary: isc-dhcp [armhf] (trusty-proposed/main) [4.2.4-7ubuntu12.10] (core)
-queuebot:#ubuntu-release- New binary: isc-dhcp [arm64] (trusty-proposed/main) [4.2.4-7ubuntu12.10] (core)
<rbasak> slashd: ^ you may need to track down an archive admin to accept from NEW.
<slashd> rbasak, https://launchpad.net/~ubuntu-archive ???
<rbasak> Yep
<slashd> rbasak, ack will do
<rbasak> slashd: https://launchpad.net/ubuntu/trusty/+queue
<slashd> sil2100, the SRU that rbasak just approved is introducing ^ a new binary pkg --> https://launchpad.net/ubuntu/trusty/+queue. Could you please accept the new binary in the archive ?
<sil2100> slashd: hey! Sadly my AA privilages only allow to take care of kernel related packages - I guess you'd have to poke a real AA like apw ^
<slashd> apw ^^ could you please have a look at this request ^ ?
<slashd> tks sil2100
<cyphermox> rbasak: could you please reject my nplan from the xenial queue? I just realized it's missing -v
<rbasak> ack
-queuebot:#ubuntu-release- Unapproved: rejected nplan [source] (xenial-proposed) [0.22~16.04.1]
<cyphermox> rbasak: ta
-queuebot:#ubuntu-release- New: accepted isc-dhcp [amd64] (trusty-proposed) [4.2.4-7ubuntu12.10]
-queuebot:#ubuntu-release- New: accepted isc-dhcp [armhf] (trusty-proposed) [4.2.4-7ubuntu12.10]
-queuebot:#ubuntu-release- New: accepted isc-dhcp [powerpc] (trusty-proposed) [4.2.4-7ubuntu12.10]
-queuebot:#ubuntu-release- New: accepted isc-dhcp [arm64] (trusty-proposed) [4.2.4-7ubuntu12.10]
-queuebot:#ubuntu-release- New: accepted isc-dhcp [ppc64el] (trusty-proposed) [4.2.4-7ubuntu12.10]
-queuebot:#ubuntu-release- New: accepted isc-dhcp [i386] (trusty-proposed) [4.2.4-7ubuntu12.10]
<apw> slashd, ^
-queuebot:#ubuntu-release- Unapproved: nplan (xenial-proposed/universe) [0.21~16.04.1 => 0.22~16.04.1] (no packageset)
<slashd> apw, thanks
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (xenial-proposed) [1.157.11]
-queuebot:#ubuntu-release- Unapproved: util-linux (zesty-proposed/main) [2.29-1ubuntu2 => 2.29-1ubuntu2.1] (core)
-queuebot:#ubuntu-release- Unapproved: util-linux (yakkety-proposed/main) [2.28.2-1ubuntu1.1 => 2.28.2-1ubuntu1.2] (core)
-queuebot:#ubuntu-release- Unapproved: util-linux (xenial-proposed/main) [2.27.1-6ubuntu3.2 => 2.27.1-6ubuntu3.3] (core)
<bdmurray> cyphermox: How did you verify bug 1680279?
<ubot5> bug 1680279 in shim-signed (Ubuntu Yakkety) "attach secureboot state files to shim-signed apport reports" [Undecided,Fix committed] https://launchpad.net/bugs/1680279
<bdmurray> cyphermox: specifically how did you review the report?
<cyphermox> bdmurray: I can generate a crash file, and look in to see if we have a value for the two variables (SecureBoot-* and MokSBStateRT-*)
<cyphermox> the fact that the value is an unprintable character isn't too much an issue (we can "decipher" that, but just knowing that the files are there or not helps a lot already)
<bdmurray> cyphermox: You viewed the .crash in /var/crash with a text editor or something? Was it not apport-gtk's dialog?
<cyphermox> as I remember I went to vi the .crash file in /var/crash.
<bdmurray> Maybe we should let slangasek decide since he did the SRU work
<bdmurray> cyphermox: Also might these files not exist? there is attach_file_if_exists() instead of attach_file()
<cyphermox> yes, at least MokSBStateRT can be absent
<slangasek> fwiw when I was testing this I used apport-gtk's dialog
<bdmurray> And did you choose not to use attach_file_if_exists()?
<bdmurray> It won't cause a problem as apport will carry on, it'll just be extra baggage with the bug.
<bdmurray> Oh, I guess its okay
<bdmurray> Error: [Errno 2] No such file or directory: '/sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23'
<bdmurray> slangasek: is the fact that its an unprintable character an issue?
<slangasek> bdmurray: the 'no such file or directory' messages are actually useful information to me, it shows a recent enough version of the hook was run and found nothing
<slangasek> bdmurray: the unprintable character is an issue, but IMHO having unprintable character is better than nothing
<slangasek> and I told cyphermox I wasn't going to be working on the unprintable character problem any time soon, which was why he switched from v-failed to v-done
<bdmurray> slangasek: okay, cool
<cyphermox> ^that. unprintable character is better than nothing, as just existence already give you all you need for the MokSBStateRT case anyway (it's either there or not)
<bdmurray> Sure it just seems like you could store this information as a boolean e.g. MokSBStateRtExists: True and it'd be cleaner.
<slangasek> bdmurray: for most of them we do care about the content, and it is possible if inconvenient to extract that info from the unprintable character IIRC
<slangasek> ultimately I want the content
<bdmurray> slangasek: Understood.
<bdmurray> Bug 1659618 mentions a kexec-tools SRU ftbfs on armhf but that's not showing up on the pending-sru report...
<ubot5> bug 1659618 in kexec-tools (Ubuntu Yakkety) "Enable ARM64 support in kexec-tools" [High,Fix committed] https://launchpad.net/bugs/1659618
<bdmurray> I see some other ftbfs on the report.
<slangasek> bdmurray: under yakkety I see 'kexec-tools armhf: Failed to build', is that not what you're talking about?
<bdmurray> slangasek: I'm talking about 1:2.0.10-1ubuntu2.1 for xenial which FTBFS but come to find out there is an even newer version in xenial which isn't in the bug comments at all.
<slangasek> ok
<bdmurray> So while I was looking at the wrong package version an SRU team member didn't comment on the bug when accepting the new version in.
<bdmurray> That should have flipped the tags for xenial too.
-queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu4 => 2.02~beta3-4ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu4 => 2.02~beta3-4ubuntu4] (core)
<gaughen> cyphermox, would you have a look at this MIR request please - https://bugs.launchpad.net/ubuntu/+source/vine/+bug/1688091
<ubot5> Ubuntu bug 1688091 in vine (Ubuntu) "[MIR] vine" [High,New]
<cyphermox> sure
<gaughen> thank you cyphermox!
<jbicha> cyphermox: and LP: #1686726 too?
<ubot5> Launchpad bug 1686726 in gnome-getting-started-docs (Ubuntu) "[MIR] gnome-getting-started-docs" [High,Triaged] https://launchpad.net/bugs/1686726
<bdmurray> tjaalton: Why was mir accepted in xenial-proposed when it doesn't seem to be fixed in Artful and the version number will be greater than any other release?
#ubuntu-release 2017-05-26
-queuebot:#ubuntu-release- Unapproved: lmdb (xenial-backports/universe) [0.9.17-3 => 0.9.18-4~ubuntu16.04.1] (kubuntu)
<ahoneybun> mm cyphermox http://imgur.com/a/7oRRu
<ahoneybun> some spacing issues
<ahoneybun> I think the real slides are larger then the test slide
-queuebot:#ubuntu-release- Unapproved: ninja-build (xenial-backports/universe) [1.5.1-0.1ubuntu1 => 1.7.1-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: meson (xenial-backports/universe) [0.29.0-1 => 0.40.1-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mustache-d (xenial-backports/universe) [0.1.1-1~ubuntu16.04.1 => 0.1.3-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted lmdb [source] (xenial-backports) [0.9.18-4~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted ninja-build [source] (xenial-backports) [1.7.1-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: meson (zesty-backports/universe) [0.39.1-1 => 0.40.1-1~ubuntu17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: meson (yakkety-backports/universe) [0.34.0-1 => 0.40.1-1~ubuntu16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted meson [source] (xenial-backports) [0.40.1-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted mustache-d [source] (xenial-backports) [0.1.3-1~ubuntu16.04.1]
<slashd> sil2100, good day, I have a question for you ... we are currently working on a fix for ebtables package. The upstream project is un-maintained anymore since 2015 in favour of nft project (where all the development is happening now) and we have submitted a bug in Debian to commit and upload our patch but no news as well after a couples of weeks. With that being said how can we make our patch land in Ubuntu to accomodate
<slashd> users having this particular bug ? (LP: #1645324)
<ubot5> Launchpad bug 1645324 in ebtables (Ubuntu Artful) "ebtables: Lock file handling has races" [Medium,In progress] https://launchpad.net/bugs/1645324
-queuebot:#ubuntu-release- Unapproved: accepted meson [source] (yakkety-backports) [0.40.1-1~ubuntu16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted meson [source] (zesty-backports) [0.40.1-1~ubuntu17.04.1]
<slashd> SRU team ? rbasak ? ^^^^
<apw> slashd, if you have a fix for it, it sounds like something that can be sru#d
<slashd> apw, even if not merged at any other level such as upstream or debian due to no longer maintain ?
<apw> slashd, it is not uncommon to apply a fix locally first, and then it may get replaced by an "official" fix later
<slashd> apw, ok thanks so I'll proceed with the upload then
<apw> slashd, though as you have submitted it to debian the chances are the fix if it ever gets applied, would match
<apw> slashd, so not in need to any modification if and when debian does apply it
<slashd> thank you very much apw
<cyphermox> ahoneybun: the real fix for that is to not use a background at all; just the screenshot you need and properly insert it in the right place in the html of the slide
<cyphermox> (the grey header is already included in the slideshow code, and the background color is something you can set in CSS anyway.
-queuebot:#ubuntu-release- Unapproved: gwakeonlan (xenial-proposed/universe) [0.5.1-1.1 => 0.5.1-1.1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fwupd (zesty-proposed/main) [0.8.1-3 => 0.8.1-3ubuntu0.1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: vlan (zesty-proposed/main) [1.9-3.2ubuntu2 => 1.9-3.2ubuntu2.17.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: vlan (yakkety-proposed/main) [1.9-3.2ubuntu2 => 1.9-3.2ubuntu2.16.10.1] (core)
-queuebot:#ubuntu-release- Unapproved: vlan (xenial-proposed/main) [1.9-3.2ubuntu1.16.04.1 => 1.9-3.2ubuntu1.16.04.2] (core)
-queuebot:#ubuntu-release- Unapproved: vlan (trusty-proposed/main) [1.9-3ubuntu10.1 => 1.9-3ubuntu10.2] (core)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-54.57] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.8.0-54.57~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.8.0-54.57~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-54.57]
<cyphermox> hi, could someone please review and accept grub2 (amd64 and arm64) in artful NEW queue?
<mapreri> rbasak: Gianfranco asked me to tell you please move virtualbox-ext-pack to release too, not only virtualbox (as otherwise update in systems with both installed is broken)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (artful-proposed) [2.02~beta3-4ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (artful-proposed) [2.02~beta3-4ubuntu4]
-queuebot:#ubuntu-release- New: accepted debian-med [amd64] (artful-proposed) [3.0.1ubuntu1]
<ahoneybun> cyphermox: well I wanted to use certain colors and don't like css/html too much
<cyphermox> ahoneybun: well, it doesn't work and your colors look like very nearly the same as provided on the system anyway (the header in your image is just slightly lighter)
<ahoneybun> cyphermox: I see I did set that color myself so working on getting it right
<cyphermox> ahoneybun: I think we're talking past each other
<cyphermox> are you looking to have a different color than what is  currently there for the header?
<cyphermox> or are you trying to make the "background" match the color of the header?
<ahoneybun> cyphermox: I was using an image as the whole thing
<cyphermox> yes
<ahoneybun> and the problem was that the test-slideshow was using a smaller size then the real one
<cyphermox> yeah, that shouldn't be an issue
<ahoneybun> getting rid of the image and just going with css background-color
<ahoneybun> should have something to merge by the end of the weekend
<cyphermox> if you use just the screenshot for the image you want to appear on screen and putting it in the right div tag (use an example from another flavour) should work
<cyphermox> (ie. you don't need to have the image be the whole slide, or have a header, or anything like that)
<ahoneybun> yea that was my problem
<ahoneybun> trying to avoid css/html xD
<cyphermox> please don't, it should be trivial anyway, you should be able to just copy-paste from another release
<cyphermox> *flavour
<cyphermox> otherwise you need to repeat the same process for every slide, whereas with CSS you set the theming once and you're done
<cyphermox> tbf, I don't "enjoy" doing html and css either, but sometimes that's the best way to do things, and it's much less yucky than other languages
<slangasek> 'perhaps set LP_DISABLE_SSL_CERTIFICATE_VALIDATION if certificate validation failed and you genuinely trust the remote server.'
<slangasek> perhaps never ever recommend such things in a stack trace message
<nacc> slangasek: oh was that in the backtrace of those earlier failures? or something else
<slangasek> nacc: apport retracer crash
<nacc> slangasek: ah fun
<cjwatson> maybe it should be LP_ROOT_ME_PLEASE
<nacc> heh
<cjwatson> (I do sometimes use LP_DISABLE_SSL_CERTIFICATE_VALIDATION, but only against a development instance, and never with anything to do with apport ...)
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.9-113-g513e99e0-0ubuntu1~16.04.1 => 0.7.9-153-g16a7302f-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (yakkety-proposed/main) [0.7.9-113-g513e99e0-0ubuntu1~16.10.1 => 0.7.9-153-g16a7302f-0ubuntu1~16.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-113-g513e99e0-0ubuntu1~17.04.1 => 0.7.9-153-g16a7302f-0ubuntu1~17.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<tsimonq2> Any chance someone on the release team can adjust the oversize warning for Lubuntu Next to 1.5 GB?
-queuebot:#ubuntu-release- Unapproved: libgweather (zesty-proposed/main) [3.24.0-0ubuntu2 => 3.24.0-0ubuntu2.1] (kubuntu, ubuntu-desktop)
#ubuntu-release 2017-05-27
<rbasak> mapreri: looking, but also, that sounds like a missing Breaks clause then, no?
<rbasak> mapreri: we don't usually release SRUs on Fridays or over the weekend. Not sure what to do here, but it's also 1am for me and I'm half asleep so I don't feel confident touching this right now.
<rbasak> I suspect that I didn't release it before due to the automated Zesty regression note.
<rbasak> And infinity relaesed it on Thursday I think? ^
<rbasak> infinity: also see 17:47 UTC above.
<infinity> rbasak: Nope, I didn't release it, but also don't mind doing the other bit now.  *shrug*
<acheronUK> hi virtualbox 5.1.22-2~17.04.1  has been rleased to zesty-updates, but the matching extension pack and additions sources needed are still stuck in -proposed?
<acheronUK> deliberate? oversight?
<infinity> acheronUK: Literally just fixed.
<infinity> But yes, probably an oversight when bdmurray did the release.
<acheronUK> infinity: ok. thank you :)
#ubuntu-release 2017-05-28
<ahoneybun> mmm what? https://irc-attachments.kde.org/J7F9qWEo/file_2671.jpg
<ahoneybun> my name and a link to my blog post on the installer slideshow is on there
<ahoneybun> kirkland: ^
<ahoneybun> ubu.one/kubuart
<mapreri> infinity, rbasak: ack, thanks.  (relaying to Gianfranco, I don't know anything about virtualbox stuff).
-queuebot:#ubuntu-release- New binary: node-stream-array [amd64] (artful-proposed/none) [1.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slick-greeter [ppc64el] (artful-proposed/none) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: htmlmin [amd64] (artful-proposed/none) [0.1.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pymssql [s390x] (artful-proposed/universe) [2.1.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slick-greeter [s390x] (artful-proposed/none) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pymssql [ppc64el] (artful-proposed/universe) [2.1.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slick-greeter [amd64] (artful-proposed/none) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pymssql [amd64] (artful-proposed/universe) [2.1.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slick-greeter [arm64] (artful-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pymssql [i386] (artful-proposed/universe) [2.1.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slick-greeter [armhf] (artful-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pymssql [arm64] (artful-proposed/universe) [2.1.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slick-greeter [i386] (artful-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pymssql [armhf] (artful-proposed/universe) [2.1.3+dfsg-1] (no packageset)
#ubuntu-release 2018-05-21
-queuebot:#ubuntu-release- New binary: haskell-thyme [arm64] (cosmic-proposed/universe) [0.3.5.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-thyme [armhf] (cosmic-proposed/universe) [0.3.5.5-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: packagekit (bionic-proposed/main) [1.1.9-1ubuntu2 => 1.1.9-1ubuntu2.18.04.1] (desktop-core)
<wxl> i appear to be blind and can't find the apport hook for ubiquity. anyone want to help the other abled?
-queuebot:#ubuntu-release- New sync: haskell-tuple (cosmic-proposed/primary) [0.3.0.2-1]
-queuebot:#ubuntu-release- New sync: haskell-xml-helpers (cosmic-proposed/primary) [1.0.0-1]
<xnox> infinity, i need to update ubuntu-meta for s/btrfs-tools/btrfs-progs/, however running straight update does something funny: "Added e2fsprogs to minimal"
<xnox> looking at history, it's been in and out of minimal. And i can't seem to spot what the difference is with bionic - i.e. intentional and good; or a bug.
<xnox> infinity, ah, it's no longer Essential: yes.
-queuebot:#ubuntu-release- New sync: haskell-yi-keymap-vim (cosmic-proposed/primary) [0.17.1-1]
-queuebot:#ubuntu-release- New sync: haskell-yi-keymap-emacs (cosmic-proposed/primary) [0.17.1-1]
<LocutusOfBorg> anybody can help me with a misaligned access on arm64 userspace and armhf build?
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/haskell-cipher-aes/0.2.11-6/+build/14904327
<LocutusOfBorg> infinity, ^^ maybe you can help me in debugging that bus error
<LocutusOfBorg> I tried on debian porterbox and I can reproduce
<LocutusOfBorg> but it fails in a strange way
<LocutusOfBorg> any AA please accept some haskell stuff :)
-queuebot:#ubuntu-release- New: accepted haskell-hslua-module-text [amd64] (cosmic-proposed) [0.1.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-hslua-module-text [armhf] (cosmic-proposed) [0.1.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-hslua-module-text [ppc64el] (cosmic-proposed) [0.1.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-hslua-module-text [arm64] (cosmic-proposed) [0.1.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-hslua-module-text [s390x] (cosmic-proposed) [0.1.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-hslua-module-text [i386] (cosmic-proposed) [0.1.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-microstache [amd64] (cosmic-proposed) [1.0.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-microstache [armhf] (cosmic-proposed) [1.0.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-microstache [ppc64el] (cosmic-proposed) [1.0.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-microstache [arm64] (cosmic-proposed) [1.0.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-microstache [s390x] (cosmic-proposed) [1.0.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-microstache [i386] (cosmic-proposed) [1.0.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-ini [amd64] (cosmic-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted haskell-ini [armhf] (cosmic-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted haskell-ini [ppc64el] (cosmic-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted haskell-ini [arm64] (cosmic-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted haskell-ini [s390x] (cosmic-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted haskell-ini [i386] (cosmic-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted haskell-config-ini [amd64] (cosmic-proposed) [0.2.2.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-config-ini [armhf] (cosmic-proposed) [0.2.2.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-config-ini [ppc64el] (cosmic-proposed) [0.2.2.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-config-ini [arm64] (cosmic-proposed) [0.2.2.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-config-ini [s390x] (cosmic-proposed) [0.2.2.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-config-ini [i386] (cosmic-proposed) [0.2.2.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-thyme [amd64] (cosmic-proposed) [0.3.5.5-2]
-queuebot:#ubuntu-release- New: accepted haskell-thyme [armhf] (cosmic-proposed) [0.3.5.5-2]
-queuebot:#ubuntu-release- New: accepted haskell-thyme [ppc64el] (cosmic-proposed) [0.3.5.5-2]
-queuebot:#ubuntu-release- New: accepted haskell-thyme [arm64] (cosmic-proposed) [0.3.5.5-2]
-queuebot:#ubuntu-release- New: accepted haskell-thyme [s390x] (cosmic-proposed) [0.3.5.5-2]
-queuebot:#ubuntu-release- New: accepted haskell-thyme [i386] (cosmic-proposed) [0.3.5.5-2]
<LocutusOfBorg> ta
<LocutusOfBorg> haskell-hedgehog can be accepted, it is already build on every architecture that is building fine (same as debian)
<LocutusOfBorg> haskell-yi-keymap-emacs haskell-yi-keymap-vim haskell-xml-helpers haskell-tuple can be accepted in universe, trivial packaging, easy stuff
<Laney> looks like the autopkgtest-lxd-worker machine has crashed or something :(
 * Laney reboots it
<apw> Laney, ouch
<Laney> sounds like I accidentally booted apw
<Laney> oh still can't SSH to it
<apw> heh yeah it does
<Laney> whyyy
<apw> did you cheat on it ?
<Laney> I did spend more time with the nova node :(
<Laney> looks like some fallout from a bit of maintenance
<Laney> trying to get it resolved
<xnox> Laney, what's wrong with systemd-resolved?
<xnox> oh
<apw> what is _right_ with it is surely easier
 * Laney eyes xnox suspiciously
<ginggs> would someone please 'force-badtest node-external-editor/2.0.4+dfsg-1' ? it has regressed in release
<apw> ginggs, looking
<ginggs> apw: thanks. as before I ran its autopkgtest in release http://autopkgtest.ubuntu.com/packages/n/node-external-editor/cosmic/amd64
<apw> ginggs, looks like your test is right, pushed
<ginggs> apw: ta!
<tsimonq2> (systemd-resolved should be aliased systemd-painintheneck amirite)
<apw> tsimonq2, ln -f /dev/null systemd.resolved ?
<tsimonq2> Perfect.
-queuebot:#ubuntu-release- New: accepted haskell-hedgehog [amd64] (cosmic-proposed) [0.5.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-hedgehog [ppc64el] (cosmic-proposed) [0.5.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-hedgehog [arm64] (cosmic-proposed) [0.5.3-1]
<LocutusOfBorg> wgrant, hello, what happened to lgw01-amd64-033? building haskell-simple since too much time
<LocutusOfBorg> I cancelled it, lets see
<sil2100> fossfreedom: hey! How frequently does LP: #1771606 occur?
<ubot5> Launchpad bug 1771606 in budgie-extras (Ubuntu Bionic) "[SRU] Fix budgie panel hang when USB inserted" [Low,New] https://launchpad.net/bugs/1771606
-queuebot:#ubuntu-release- New: accepted haskell-tuple [sync] (cosmic-proposed) [0.3.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-yi-keymap-emacs [sync] (cosmic-proposed) [0.17.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-xml-helpers [sync] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-yi-keymap-vim [sync] (cosmic-proposed) [0.17.1-1]
<sil2100> fossfreedom: also, I see the original reporter mentioned having the issue on artful
-queuebot:#ubuntu-release- New binary: haskell-xml-helpers [i386] (cosmic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-xml-helpers [s390x] (cosmic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-xml-helpers [ppc64el] (cosmic-proposed/none) [1.0.0-1] (no packageset)
<sil2100> fossfreedom: I'm asking about frequency, since in overall I'm fine to accept it but it seems to be a low-priority fix, and each upgrade introduces some risks + requires update from users, so bandwidth
-queuebot:#ubuntu-release- New binary: haskell-tuple [i386] (cosmic-proposed/none) [0.3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-yi-keymap-emacs [amd64] (cosmic-proposed/none) [0.17.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-yi-keymap-emacs [s390x] (cosmic-proposed/none) [0.17.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-tuple [s390x] (cosmic-proposed/none) [0.3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-yi-keymap-emacs [ppc64el] (cosmic-proposed/none) [0.17.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-tuple [amd64] (cosmic-proposed/none) [0.3.0.2-1] (no packageset)
<sil2100> fossfreedom: if the issue appears frequently enough and/or there are no plans for an update of this package in the nearest time, I'd be willing to accept it
-queuebot:#ubuntu-release- New binary: haskell-tuple [ppc64el] (cosmic-proposed/none) [0.3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-xml-helpers [amd64] (cosmic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-yi-keymap-vim [i386] (cosmic-proposed/none) [0.17.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-yi-keymap-emacs [arm64] (cosmic-proposed/none) [0.17.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-yi-keymap-vim [ppc64el] (cosmic-proposed/none) [0.17.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-yi-keymap-emacs [i386] (cosmic-proposed/none) [0.17.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-yi-keymap-vim [s390x] (cosmic-proposed/none) [0.17.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-xml-helpers [arm64] (cosmic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-yi-keymap-emacs [armhf] (cosmic-proposed/none) [0.17.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-xml-helpers [armhf] (cosmic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-xml-helpers [amd64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-xml-helpers [armhf] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-xml-helpers [ppc64el] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-xml-helpers [arm64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-xml-helpers [s390x] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-xml-helpers [i386] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (bionic-proposed) [1.173.1]
-queuebot:#ubuntu-release- New binary: haskell-tuple [arm64] (cosmic-proposed/none) [0.3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-yi-keymap-vim [amd64] (cosmic-proposed/none) [0.17.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-yi-keymap-emacs [amd64] (cosmic-proposed) [0.17.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-yi-keymap-emacs [s390x] (cosmic-proposed) [0.17.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-yi-keymap-emacs [ppc64el] (cosmic-proposed) [0.17.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-yi-keymap-emacs [arm64] (cosmic-proposed) [0.17.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-yi-keymap-emacs [i386] (cosmic-proposed) [0.17.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-yi-keymap-emacs [armhf] (cosmic-proposed) [0.17.1-1]
-queuebot:#ubuntu-release- New binary: haskell-tuple [armhf] (cosmic-proposed/none) [0.3.0.2-1] (no packageset)
<sil2100> blackboxsw: hey! o/
<sil2100> blackboxsw: I'm looking at the curtin SRU right now, and I'm obligated to formally ask this: the bug mentions version 18.1-16-g18835845-0ubuntu1 but the uploaded one is 18.1-17-gae48e86f-0ubuntu1
<sil2100> blackboxsw: I guess the bug needs to be updated for -17?
-queuebot:#ubuntu-release- New binary: haskell-yi-keymap-vim [arm64] (cosmic-proposed/none) [0.17.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pikopixel.app [source] (bionic-proposed) [1.0-b9b-1ubuntu1]
<sil2100> blackboxsw: I'll accept it as is, since I suppose there's no bad in uploading a newer version than the one mentioned in the bug, but please modify it in the bug
-queuebot:#ubuntu-release- New: accepted haskell-tuple [amd64] (cosmic-proposed) [0.3.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-tuple [armhf] (cosmic-proposed) [0.3.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-tuple [ppc64el] (cosmic-proposed) [0.3.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-tuple [arm64] (cosmic-proposed) [0.3.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-tuple [s390x] (cosmic-proposed) [0.3.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-tuple [i386] (cosmic-proposed) [0.3.0.2-1]
-queuebot:#ubuntu-release- New binary: haskell-yi-keymap-vim [armhf] (cosmic-proposed/none) [0.17.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-yi-keymap-vim [amd64] (cosmic-proposed) [0.17.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-yi-keymap-vim [armhf] (cosmic-proposed) [0.17.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-yi-keymap-vim [ppc64el] (cosmic-proposed) [0.17.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-yi-keymap-vim [arm64] (cosmic-proposed) [0.17.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-yi-keymap-vim [s390x] (cosmic-proposed) [0.17.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-yi-keymap-vim [i386] (cosmic-proposed) [0.17.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (bionic-proposed) [18.1-17-gae48e86f-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (artful-proposed) [18.1-17-gae48e86f-0ubuntu1~17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (xenial-proposed) [18.1-17-gae48e86f-0ubuntu1~16.04.1]
<sil2100> Laney: hey! Were you able to resolve the armhf lxd workers being down?
<sil2100> Need a hand?
<Laney> sil2100: out of our hands, waiting for IS to fix it
<sil2100> :<
-queuebot:#ubuntu-release- New binary: yi [amd64] (cosmic-proposed/universe) [0.17.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: yi [ppc64el] (cosmic-proposed/universe) [0.17.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: yi [i386] (cosmic-proposed/universe) [0.17.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: yi [s390x] (cosmic-proposed/universe) [0.17.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-tasty-hedgehog [ppc64el] (cosmic-proposed/universe) [0.1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-tasty-hedgehog [amd64] (cosmic-proposed/universe) [0.1.0.2-1] (no packageset)
<Laney> indeed
-queuebot:#ubuntu-release- New binary: yi [arm64] (cosmic-proposed/universe) [0.17.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: yi [armhf] (cosmic-proposed/universe) [0.17.1-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (artful-proposed/partner) [191.0.0-0ubuntu2~17.10.0 => 201.0.0-0ubuntu1~17.10.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (bionic-proposed/partner) [191.0.0-0ubuntu2 => 201.0.0-0ubuntu1~18.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (trusty-proposed/partner) [191.0.0-0ubuntu2~14.04.0 => 201.0.0-0ubuntu1~14.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (xenial-proposed/partner) [191.0.0-0ubuntu2~16.04.0 => 201.0.0-0ubuntu1~16.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (artful-proposed) [201.0.0-0ubuntu1~17.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (bionic-proposed) [201.0.0-0ubuntu1~18.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (trusty-proposed) [201.0.0-0ubuntu1~14.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (xenial-proposed) [201.0.0-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- New binary: haskell-tasty-hedgehog [arm64] (cosmic-proposed/universe) [0.1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted yi [amd64] (cosmic-proposed) [0.17.1-2]
-queuebot:#ubuntu-release- New: accepted yi [armhf] (cosmic-proposed) [0.17.1-2]
-queuebot:#ubuntu-release- New: accepted yi [ppc64el] (cosmic-proposed) [0.17.1-2]
-queuebot:#ubuntu-release- New: accepted yi [arm64] (cosmic-proposed) [0.17.1-2]
-queuebot:#ubuntu-release- New: accepted yi [s390x] (cosmic-proposed) [0.17.1-2]
-queuebot:#ubuntu-release- New: accepted yi [i386] (cosmic-proposed) [0.17.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-tasty-hedgehog [amd64] (cosmic-proposed) [0.1.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-tasty-hedgehog [ppc64el] (cosmic-proposed) [0.1.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-tasty-hedgehog [arm64] (cosmic-proposed) [0.1.0.2-1]
<tsimonq2> win 5
<tsimonq2> grr
-queuebot:#ubuntu-release- Unapproved: pulseaudio (bionic-proposed/main) [1:11.1-1ubuntu7 => 1:11.1-1ubuntu7.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New sync: haskell-sdl2 (cosmic-proposed/primary) [2.4.0.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted language-selector [source] (bionic-proposed) [0.188.1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (xenial-proposed) [1.157.19]
<fossfreedom_> sil2100: re the budgie-extras SRU.  The OP mentioned artful because he was testing stuff for us.  It occurs infrequently.  There are some other per plugin fixes I would like to roll over the next few weeks  to fix stuff before 18.04.1.  Also aware that usually SRU's should be narrowly focussed rather than bundling stuff.
<sil2100> fossfreedom_: hey! Thanks for the info - in most cases we aim for SRUs to be narrowly focussed indeed, but for low-priority bugs I guess it's bess to bundle those together
<sil2100> fossfreedom_: since as mentioned, even small fixes can introduce regressions and now its a matter of if it's worth risking an upload with just a minor fix to introduce a bigger regression + there's the whole case of users having to download an update multiple times for multiple fixes
<sil2100> fossfreedom_: so we tend to recommend bundling small minor issue fixes along with bigger ones
<fossfreedom_> sil2100: the upcoming stuff I'm referring to the team are absolutely happy with.  I'm happy to bundle all the minors together if  it make it easier.  If so please reject and I'll work on a tested combined upload this week/next week.
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.42 => 2.42.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-sdl2 [sync] (cosmic-proposed) [2.4.0.1-1]
-queuebot:#ubuntu-release- Unapproved: snapcraft (bionic-proposed/universe) [2.42+18.04.2 => 2.42.1+18.04] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-sdl2 [i386] (cosmic-proposed/none) [2.4.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-sdl2 [amd64] (cosmic-proposed/none) [2.4.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-sdl2 [ppc64el] (cosmic-proposed/none) [2.4.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-sdl2 [s390x] (cosmic-proposed/none) [2.4.0.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (bionic-proposed) [2.42.1+18.04]
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.42.1]
-queuebot:#ubuntu-release- New binary: python-bayespy [amd64] (cosmic-proposed/none) [0.5.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-sdl2 [arm64] (cosmic-proposed/none) [2.4.0.1-1] (no packageset)
<LocutusOfBorg> any AA, you can now re-enable haskell autosync
<slangasek> LocutusOfBorg: doing
<slangasek> LocutusOfBorg: done
-queuebot:#ubuntu-release- New binary: haskell-sdl2 [armhf] (cosmic-proposed/universe) [2.4.0.1-1] (no packageset)
<Laney> armhf's running again
<wxl> can someone help me understand why the lubuntu bionic manifest shows python, python2.7, and python3 packages are all included and yet the installed system only has python3?
<slangasek> which manifest are you looking at?
<wxl> slangasek: http://cdimage.ubuntu.com/lubuntu/releases/18.04/release/lubuntu-18.04-desktop-amd64.manifest
<slangasek> ok
<slangasek> what does germinate say about the seeding of python2.7?  perhaps it's part of the live seed only, and not part of the desktop seed - meaning it's only used as a dependency of something in the installer, and gets removed after?
<wxl> tbh i've never used germinate before. is it as simple as feeding it a set of seeds?
<slangasek> wxl: it's not "simple", but I was more meaning for you to look at the contents of http://people.canonical.com/~ubuntu-archive/germinate-output/
<slangasek> which, I'll grant you, is also difficult to traverse via http and you probably just want to mirror it all locally and grep
<slangasek> wxl: anyway, if I look at http://people.canonical.com/~ubuntu-archive/germinate-output/lubuntu.bionic/live-share.depends I find that python2.7 is pulled in via samba-common-bin -> python -> python-minimal, which is only part of the lubuntu-live seed, not part of the lubuntu-desktop seed
<slangasek> and that's manually seeded in live-share as a recommends of cifs-utils
<wxl> i *HATE* no recommends.
<slangasek> well, that simply brings the lubuntu live seed to parity with others (e.g. ubuntu)
<wxl> i am surprised python is not simply core
<slangasek> it absolutely isn't. python2 is deprecated, and samba upstream porting is the only thing keeping it in main at all.
<slangasek> we switched to python3 by default ~2 LTSes ago
<wxl> xubuntu for example seems to have python referring to python2, which suggests it's not the default?
<slangasek> "python" is always python2
<slangasek> that's not meaningfully a "default"
<wxl> except when you don't have python2
<slangasek> python will always be python2
-queuebot:#ubuntu-release- New: accepted haskell-sdl2 [amd64] (cosmic-proposed) [2.4.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-sdl2 [armhf] (cosmic-proposed) [2.4.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-sdl2 [ppc64el] (cosmic-proposed) [2.4.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-sdl2 [arm64] (cosmic-proposed) [2.4.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-sdl2 [s390x] (cosmic-proposed) [2.4.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-sdl2 [i386] (cosmic-proposed) [2.4.0.1-1]
-queuebot:#ubuntu-release- New: accepted python-bayespy [amd64] (cosmic-proposed) [0.5.17-1]
-queuebot:#ubuntu-release- Unapproved: ebtables (bionic-proposed/main) [2.0.10.4-3.5ubuntu2 => 2.0.10.4-3.5ubuntu2.18.04.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ebtables (artful-proposed/main) [2.0.10.4-3.5ubuntu2 => 2.0.10.4-3.5ubuntu2.17.10.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ebtables (trusty-proposed/main) [2.0.10.4-3ubuntu1.14.04.1 => 2.0.10.4-3ubuntu1.14.04.2] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ebtables (xenial-proposed/main) [2.0.10.4-3.4ubuntu2 => 2.0.10.4-3.4ubuntu2.16.04.1] (ubuntu-server)
<ddstreet> sil2100 you able to approve ebtables ^ there's a bit of urgency to get the process started for it, and the patch is quite trivial
<ddstreet> or slangasek or infinity if either of you could approve ebtables uploads for t/x/a/b would be great, rather urgent to get it started
<slangasek> looking
<slangasek> (EAGAIN||EACCES) lulz
<slangasek> ddstreet: cosmic is listed as 'in progress', not 'fix committed'?  is it uploaded?
<ddstreet> slangasek it's uploaded
<ddstreet> not yet approved tho
<ddstreet> in sru queue
<slangasek> ddstreet: cosmic
<slangasek> I see no new upload for the devel series.  Needs to be fixed on trunk before you SRU
<ddstreet> slangasek no not to cosmic as i don't have magic fairy dust to upload to that
<ddstreet> slangasek ok sure
<ddstreet> slangasek ha, looks like i can upload to cosmic...done
<slangasek> ddstreet: thanks
-queuebot:#ubuntu-release- Unapproved: accepted ebtables [source] (bionic-proposed) [2.0.10.4-3.5ubuntu2.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted ebtables [source] (xenial-proposed) [2.0.10.4-3.4ubuntu2.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted ebtables [source] (artful-proposed) [2.0.10.4-3.5ubuntu2.17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted ebtables [source] (trusty-proposed) [2.0.10.4-3ubuntu1.14.04.2]
<wxl> when do we plan on having a release schedule for cosmic?
<valorie> totally got one:
<valorie> Ubuntu 18.10
<valorie> Cosmic Cuttlefish
<valorie> October 18, 2018
<valorie> https://wiki.ubuntu.com/Releases
<valorie> the important stuff is All There
<acheronuk> things like feature, final beta, and final freeze dates are not
<wxl> supposedly ReleaseTaskSignup lists a Final beta
<wxl> but tsimonq2 put that in and you know he can't be trusted
<valorie> acheronuk: I was just kidding.... tsimonq2 offered to make the page awhile ago but someone else said they'd rather
<acheronuk> ah, went over my head
<tsimonq2> ...?
<valorie> you've been working mighty hard on that SRU!
<tsimonq2> I DID make the page.
<tsimonq2> wxl: That's not Final Beta on the cosmic page.
<tsimonq2> If it is, someone else edited it.
<tsimonq2> infinity: We're waiting for you on the Release Schedule  btw. :O
<tsimonq2> *:P
<valorie> tsimonq2: not yet linked anywhere though
 * tsimonq2 glares at infinity. :P
 * valorie gives infinity some sunglasses
<valorie> let the man work in peace!
<mwhudson> itym enjoy victoria day
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-127.153] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-127.153]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (xenial-proposed/main) [4.15.0-22.24~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.13.0-1018.21] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.13.0-1018.21]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (xenial-proposed) [4.15.0-22.24~16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-22.24] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [ppc64el] (xenial-proposed/main) [4.15.0-22.24~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-149.199] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (xenial-proposed/universe) [4.13.0-1028.31] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-22.24]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-149.199]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [ppc64el] (xenial-proposed) [4.15.0-22.24~16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-127.153~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (xenial-proposed) [4.13.0-1028.31]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-127.153~14.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1006.9] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-22.24] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1006.9]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-22.24]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.13.0-43.48~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.13.0-43.48~16.04.1]
<slangasek> Laney: all the autopkgtest/lxd units were stopped; I've restarted them
<slangasek> Laney: (they seem to have failed at the 18:00 cronjob... and the host has no mailto set for cron...)
#ubuntu-release 2018-05-22
-queuebot:#ubuntu-release- Unapproved: snapd-glib (bionic-proposed/main) [1.39-0ubuntu1 => 1.40-0ubuntu0.18.04.1] (kubuntu, ubuntu-desktop, ubuntu-server)
<doko_> apw: please could you have a look at the linux/arm64 autopkg test failure triggered by both gcc-7 and gcc-8?
-queuebot:#ubuntu-release- Unapproved: netcat-openbsd (bionic-proposed/main) [1.187-1 => 1.187-1ubuntu0.1] (core)
<Laney> slangasek: something destroyed the lxd remotes..?
<Laney> hmm, guess it's the BindsTo in the socat units
<Laney> but why T F would that not have always been broken?
<Laney> #thingssoftwareengineerssay
<apw> it is a univeral constant that code works for years when completely, utterly, and fatally flawed, and then breaks on the day you care
<Laney> oh for the love of
<Laney> there's some ancient commit from pitti that we didn't get
<Laney> this is some jujuism
 * Laney runs juju upgrade-charm right now
<xnox> (singularity in progress... 10%)
-queuebot:#ubuntu-release- New source: ndctl (cosmic-proposed/primary) [60.1-0ubuntu1]
-queuebot:#ubuntu-release- New source: pmdk (cosmic-proposed/primary) [1.4-0ubuntu1]
<rbasak> ahasenack, dpb1: ^
<rbasak> ahasenack: I noticed that ndctl 60.3 is available but uploaded this one to make progress. Once updated through NEW, you may want to update that.
<rbasak> *Once accepted through NEW
<tsimonq2> apw: Finagle's law?
<apw> tsimonq2, indeed
<apw> tsimonq2, though i am sure there is a corollory to the corollory here ... that it will wait for that time even if working in the meantime is impossible
<ahasenack> rbasak: thanks
<ahasenack> stgraber: hi, you started to review pmdk/ndctl a while ago, would you like to continue? They are in the NEW pocket ^
<tsimonq2> apw: Indeed.
<apw> s/pocket/queue
<tsimonq2> Just a general note; my plan is to land the LXQt 0.13.0 transition tonight in Cosmic, then as soon as I use my new DM permissions (!) to get Qt 5.11.0 in Experimental, it'll be in Cosmic too, before the Sid transition.
<xnox> http://cdimage.ubuntu.com/ubuntu-server/daily/current/ strangely contains both bionic and cosmic files.... i thought it should only have cosmic
<xnox> or is this the new world order?
<xnox> infinity, ^ ?
-queuebot:#ubuntu-release- New binary: dovecot [s390x] (cosmic-proposed/main) [1:2.2.35-2ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: dovecot [amd64] (cosmic-proposed/main) [1:2.2.35-2ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: dovecot [i386] (cosmic-proposed/main) [1:2.2.35-2ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: dovecot [ppc64el] (cosmic-proposed/main) [1:2.2.35-2ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: dovecot [armhf] (cosmic-proposed/main) [1:2.2.35-2ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: dovecot [arm64] (cosmic-proposed/main) [1:2.2.35-2ubuntu1] (ubuntu-server)
<cpaelzer> hi, I'm unsure if this needs an AA or "just" a ubuntu-sru team member
<cpaelzer> I got a mail on increased crash rates on the last libvirt SRU
<cpaelzer> 4.0.0-1ubuntu8.1 into Bionic
<cpaelzer> I checked all crashes, none is related to the upload
<cpaelzer> so I'd want to ask to kick the phasing to continue again
<cpaelzer> but I wonder, who exactly can do so
<cpaelzer> mail says "please let a member of the Ubuntu Stable Release Updates team (~ubuntu-sru) know so that phasing of the update can proceed."
<cpaelzer> rbasak: ^^ you said you are unsure you can do so being "just" SRU Member right?
<rbasak> AIUI, the tool to do it is change-override, which would need an AA.
<rbasak> I'm not aware that we have documented anywhere a process to follow to make changes wrt. this.
<rbasak> (well it's not the tool that decides who can use it but ACLs on the other end, but it seems likely to me that it'd be AA only if it's override related)
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10 => 237-3ubuntu10.1] (core)
<dpb1> ahasenack: I think the only reason stgraber was looking was we were past feature freeze
<dpb1> ah, I see rbasak replied
<dpb1> ok, we wait and let stgraber or one of his AA cohorts take a look
<ahasenack> we still need an AA because it's a new package, doesn't have to be stgraber
-queuebot:#ubuntu-release- Unapproved: tomcat8 (bionic-proposed/universe) [8.5.30-1ubuntu1 => 8.5.30-1ubuntu1.1] (kubuntu)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.15.0-1012.12] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.15.0-1012.12]
<cpaelzer> since there was no +1 yet, anyone here now able to re-start SRU phasing - see messages ~1.25h ago
<jbicha> cpaelzer: I usually ask bdmurray questions about SRU phasing :)
<cpaelzer> hehe thanks jbicha, so he might know when he sees the highlight then
-queuebot:#ubuntu-release- Unapproved: openldap (xenial-proposed/main) [2.4.42+dfsg-2ubuntu3.2 => 2.4.42+dfsg-2ubuntu3.3] (ubuntu-server)
<bdmurray> cpaelzer, rbasak: change-override is useful for stopping an update from phasing - you'd use it to set the phasing percentage to 0 for a bad SRU
<bdmurray> the phased-updater can be told to ignore individual crashes by putting them in the text file in this branch https://launchpad.net/~ubuntu-sru/+junk/phased-update-overrides
<rbasak> Ah.
<rbasak> Thanks!
<rbasak> bdmurray: can a non-AA SRU member use change-override?
<bdmurray> tkamppeter: Nope
<bdmurray> sorry, no it requires an AA to use change-override
<rbasak> OK, thanks.
<rbasak> But useful to know I can override false positive error rates
<bdmurray> I'm sure I sent an email to the ubuntu-sru team about the overrides but it may have been before you joined.
<bdmurray> cpaelzer: What about this crash which only occurs with the version in -updates? https://errors.ubuntu.com/problem/ecae502be63a7615908e449a22c4141d257aa468
<cpaelzer> bdmurray: also not related
<cpaelzer> bdmurray: not a single entry on that code path is touched by the changes, it doesn't even interafct with the code we changed
<cpaelzer> so it is not even like a does something and due to that b fails
<cpaelzer> the line those two things crash is an odd issue, but not related
<cpaelzer> it does return a constant value
<cpaelzer> so it is a #define foo 4096
<cpaelzer> and what fails is a function that does return foo
<cpaelzer> thrrad #9 that is stuck somewhere in /usr/lib/libvirt/connection-driver/libvirt_driver_nodedev.so might be related to this crash, but not the ongoing SRU
<cpaelzer> bdmurray: so really I thinke the SRU can continue phasing
<bdmurray> cpaelzer: okay, I'll get the override taken care of
<cpaelzer> I'd not see how they are related
<cpaelzer> thanks bdmurray
-queuebot:#ubuntu-release- Unapproved: libsdl2 (artful-proposed/universe) [2.0.6+dfsg1-3ubuntu1 => 2.0.6+dfsg1-3ubuntu1.17.10.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libsdl2 (bionic-proposed/universe) [2.0.8+dfsg1-1ubuntu1 => 2.0.8+dfsg1-1ubuntu1.18.04.1] (kubuntu)
<infinity> xnox: That would be because the cosmic images have never passed smoketesting on some arches, I imagine.
<xnox> infinity, fancy!
-queuebot:#ubuntu-release- New binary: libnitrokey [amd64] (cosmic-proposed/universe) [3.3-2] (no packageset)
-queuebot:#ubuntu-release- New source: jboss-annotations-1.2-api (cosmic-proposed/primary) [1.0.0-0ubuntu1]
<tjaalton> dogtag-pki needs that ^ :/
-queuebot:#ubuntu-release- New: accepted libnitrokey [amd64] (cosmic-proposed) [3.3-2]
<tsimonq2> infinity: debian-cd> We don't have the equivalent of the "Try or Install" screen with Calamares, yet.
<tsimonq2> infinity: Am I misunderstanding the way things work? I thought that was in the Ubiquity codebase.
<infinity> tsimonq2: Oh, you're doing the installer switch thing too.  Ick.  Mmkay.
<infinity> tsimonq2: Buuut, if Calamares doesn't have that screen, and you're switching installers, it seems like a huge mistake to switch your boot options to not have a "try" and "install" option, surely?
<infinity> tsimonq2: Or is there also no way to boot directly to the installer, so you have to boot live, then click an icon?
<infinity> tsimonq2: Your initial commit message talking about "being consistent with Kubuntu" is why I made the comment I did.  Obviously, you're not being consistent with Kubuntu. :P
<teward> can an archive admin mark the nginx autopkgtest call of searx as ignored?  Autopkgtests for searx wherever it's called from fail in Cosmic, and also upstream in Debian.  ahasenack was kind enough to help me dig, and we have two bugs now for this, one for the autopkgtest failures globally and one for the uwsgi crashdump - bugs 1772749 and 1772753 respectively.
<slangasek> right, exactly
<ubot5> bug 1772753 in searx (Ubuntu) "[searx] - uwsgi-core crashed with SIGSEGV in __libc_fork()" [Undecided,New] https://launchpad.net/bugs/1772753
<ubot5> bug 1772749 in searx (Ubuntu) "[Cosmic] searx segfaults when being run" [Critical,New] https://launchpad.net/bugs/1772749
<teward> the autopkgtests failing are blocking other applications in proposed (including nginx)
<teward> and the autopkgtest failure is on uwsgi, not nginx.
<slangasek> tsimonq2, infinity: that's the reason for my nack also - it's fine if lubuntu is going to have a different set of options because calamares, but the meaning of the terms used for each of those options should not be inconsistent between flavors
<tsimonq2> infinity: Well, the "being consistent with Kubuntu" is *technically* right in the sense that the boot option string would be pretty much the same. :P
<slangasek> "Start $ubuntu" --> try-or-install menu (which should be consistently implemented w/ the maybe-ubiquity boot option).  "Install $ubuntu" --> direct to installer. "Try $ubuntu" --> boot to desktop env, click icon if you want to install.
<tsimonq2> So then Lubuntu should just be "Try Lubuntu"
<slangasek> ok
<tsimonq2> I'll correct it now, unless one of y'all wants to JFDI.
<slangasek> and that, I think, has implications for how you jigger the code to keep it maximally readable
<tsimonq2> Right.
<infinity> Hrm, I'm not sure I agree with that entirely. :)
<tsimonq2> Aaaaaaaaactually, hang on just a second.
<tsimonq2> So, I think Neon does a thing with this.
<infinity> If there's no way to boot to the installer (thus, no way to have both try and install), having only "try" makes people think it's live-only-without-installer.
<infinity> Maybe.
<infinity> I see "Start" as "the thing to have when try and install are the same button", regardless of how you get there.
<tsimonq2> What's this do? https://packaging.neon.kde.org/neon/calamares-settings-pinebook.git/tree/lib/live/config/1200-calamares?h=Neon/unstable
<slangasek> infinity: that wasn't my understanding of the existing code, where Kubuntu -> "start" -> maybe-ubiquity?
<tsimonq2> It seems like throwing something in /lib/live/config seems to be on the right track.
 * tsimonq2 does some more poking
<wxl> maybe we should pull kubuntu devs in here to help with this discuss?
<slangasek> infinity: I agree that your interpretation of the label makes sense; I just don't think it matches current practice
<infinity> slangasek: Sure, existing code, start=maybe-ubiq, but start also means "try and install collapsed into one option", so it's a question of where you draw your line in the sand on the meaning.
<tsimonq2> wxl: acheronuk didn't initially set this up; this'd be Riddell and sitter days.
<tsimonq2> (this'd? hmm)
<wxl> tsimonq2: still, is this not how things are done now?
<tsimonq2> wxl: In what sense?
 * wxl haven't booted a lvie kubuntu in a bit
<tsimonq2> infinity, slangasek: What's the "proper" way to be able to throw something like "maybe-ubiquity" in there and have it start the Calamares binary as root?
<wxl> tsimonq2: i took what you said to me (and what you suggest above) to mean that kubuntu just has one boot option
<slangasek> infinity: should subiquity images say 'Start' instead of 'Install'?
<infinity> tsimonq2: You're asking us how to configure calamares?
<tsimonq2> infinity: I'm asking how it's already done so I can do the thing with mine.
<infinity> slangasek: No, because subiquity is a special snowflake that has no live env.
<slangasek> infinity: sure it does, Alt+F2
<infinity> slangasek: Start="live+install are the same boot option", try="live", install="install".
<infinity> slangasek: Okay, it has no obvious live env, but boots directly to an installer? :P
<slangasek> :)
<tsimonq2> So, to clarify, what's the backend which allows a binary to be executed when a specific boot option is called? Is this kernel level plumbery, d-i plumbery, or a bit higher up the chain?
<slangasek> tsimonq2: the ubiquity package starts ubiquity-dm via its systemd unit, which interprets those boot options
<slangasek> however, we should not have a proliferation of different kernel commandline options on account of a change in the installer implementation
<slangasek> if calamares has need for a kernel commandline option to do a $thing, it should use the same name that ubiquity already uses
<infinity> We could generify that to "maybe-installer, only-installer" instead of *-ubiquity.
<tsimonq2> Was just about to say that.
<tsimonq2> I'm not a fan of confusing people should both wxl and I get hit by a bus, if we don't leave code comments. :P
<infinity> See the big case statement at the top of scripts/start-ubiquity-dm for all of the options.
<tsimonq2> Will do.
<slangasek> I think it's more awkward to do the transition than to carry on with the existing option names that are already well known to those who livecd
<infinity> I'm still not convinced that this foray into other installers will end well.
<infinity> But I've failed to talk you out of it, so...
<tsimonq2> QML > Electron, Just Sayin'.
<infinity> slangasek: Having ubiquity understand both is a trvial patch, having other installers read *-ubiquity options seems slightly daft.  IMO.
<tsimonq2> I would agree.
<infinity> tsimonq2: QML is better than electron, which means... What in this context? :P
<tsimonq2> One more thing real quick; what does putting something in /lib/live/config *actually* do?
<tsimonq2> infinity: The new installer seems to be an Electron thing. :P
<infinity> tsimonq2: Which new installer?
 * infinity is suddenly amazingly confused.
<tsimonq2> infinity: That one that Mark told us all about.
<wxl> "ubiquity-ng"
<tsimonq2> ^
<slangasek> infinity: so then the dependency chain before they can adopt calamares is 1) change ubiquity to understand the new option, 2) change debian-cd to emit the new option, 3) change calamares to accept the new option, 4) slangasek cries in a corner for a while at the inconsistency between pre-bionic and post-cosmic commandlines
<infinity> That very much doesn't exist.
<tsimonq2> https://lists.ubuntu.com/archives/ubuntu-devel/2018-May/040301.html
<slangasek> ubingquity
<tsimonq2> infinity: Not now, it doesn't.
<tsimonq2> But, I look at long term.
<tsimonq2> (In this specific situation...)
<tsimonq2> Anyway.
<tsimonq2> So, I'd say for now, disregard my MP.
<tsimonq2> infinity, slangasek: I'll follow Steve's checklist, minus #4, which is up to slangasek if he actually wants to go through with. :P
<tsimonq2> But to get the bikeshedding over with, s/ubiquity/installer/g right?
<slangasek> tsimonq2: well also, I guess I'm left not entirely certain you need the installer options at all
<tsimonq2> slangasek: How so?
<slangasek> tsimonq2: don't you only care about the option names if you're implementing maybe-* behavior?
<tsimonq2> slangasek: But, I want to do that now. :P
<slangasek> ah
<slangasek> ok then ;)
<slangasek> if your intent had been to only support a single boot option, that boots to a live session, with an 'install' button on the desktop, then I was going to concede the point to infinity that this should be called 'Start'
<slangasek> and that it wouldn't need a 'maybe-ubiquity' option
<tsimonq2> Originally, that was my thought. But it seems easier than I thought to just have maybe-installer (ahem ;) ) behavior instead.
<tsimonq2> To be clear, I'll write all of this, I just need reviews and merges. ;)
<infinity> tsimonq2: Well, you can go the easy route, then follow up the hard.  They're not mutually exclusive.
<tsimonq2> Now I'm conflicted. :P
<tsimonq2> I think that's a smart move, actually.
<infinity> That statement was meant to remove conflict.
<tsimonq2> (Personally conflicted. :P)
<infinity> tsimonq2: So, if that's the path you want to take today, I'd suggest you collapse ku|ku-pl5, like I asked, and set a NOTRYONLYDO to test later, and call it good.
<infinity> tsimonq2: I also don't care at all if you drop the ubuntu-mid bit, that project hasn't existed since forever.
<tsimonq2> I'll go with that and fix my code as soon as I can get some sort of verification that if I just copy Neon and throw something like https://packaging.neon.kde.org/neon/calamares-settings-pinebook.git/tree/lib/live/config/1200-calamares?h=Neon/unstable in /lib/live/config, it'll DTRT. Because I'm not even sure how to test that without just throwing something in my Calamares config and uploading it
<tsimonq2> to the archive, which isn't smart but it's ultima ratio.
<tsimonq2> infinity: So you don't care if I drop ubuntu-mid but you care if I drop ku-pl5? :P
<infinity> But if we drop old projects, we need to scrub for all occurrences, so dropping them in that commit is less pleasant.
<tsimonq2> Ahh.
<tsimonq2> infinity: Bikeshedding real quick, if you have a second. My Python experience yells "==" but Bash seems to also do "=" for string comparison. Which one do you prefer?
<tsimonq2> (And gosh darn it all, why can't this be consistent? :P)
<slangasek> tsimonq2: = is correct. == is a bashism
<tsimonq2> Thanks.
<tsimonq2> Wait, what? It's also a Pythonism... :P
<slangasek> no, in the context of shell it's a bashism, meaning it's not POSIX sh
<tsimonq2> Ohh, gotcha.
<tsimonq2> infinity: .
<infinity> tsimonq2: In many languages, = is assignment, == is comparison, POSIX shell uses context to decide when = means one or the other, bash and zsh muddied the waters by letting you use == when, frankly, they shouldn't have.
<tsimonq2> infinity: That's what I thought.
<sarnold> there's also -eq just to make things extra-confusing
<tsimonq2> Oh jeez, really?
 * tsimonq2 RTFMs
<infinity> sarnold: -eq is arithmetic, = is a string comparison.
<infinity> You'll have a very bad day if you confuse them.
<tsimonq2> Ahh.
<slangasek> not to be confused with -=eq
<infinity> Which would just be Steve trolling.
<infinity> tsimonq2: The trick to '=' contextually working in shell is that shell itself has NO comparison operators in the base language, all of these things we're discussing are actually arguments to test(1)
<slangasek> Content-Type: multipart/mixed; boundary=eq=trololololololololololo
<infinity> tsimonq2: And [ is actually an alias for test.
<infinity> tsimonq2: So, wrap your head around that fun design.
<sarnold> is [ a shell builtin? or executable? or both! have fun!
<infinity> Both.
<tsimonq2> infinity: Seems like a bit of a cluster...heck, but it has to serve a purpose somewhere... right?
<infinity> test and [ are built in to every shell I use, but coreutils also provides an implementation, should your shell be super awful.
<slangasek> [ `which which` -eq $(type type) ]
<sarnold> *groan*
<infinity> Some people shouldn't be allowed to have computers.
<sarnold> hear hear
<sarnold> also
<sarnold> here here
<slangasek> infinity: speaking of which, time to reboot
<sarnold> I'd like to outside and play today intead :)
<slangasek> here: command not found
<sarnold> slangasek: <<<HERE then
<wxl> here strings are cool but process substitution is where it's at
<wxl> XD
<tsimonq2> Holy what.
<tsimonq2> Oh. That's actually pretty darn cool.
<slangasek> sarnold: +1
<infinity> 6 minutes to reboot?  Did you have to resync a raid over USB?
<sarnold> squid shutdown?
<tsimonq2> *mumble* something something GNOME *mumble *mumble*
<infinity> Squid's shutdown makes me irrationally angry.
<infinity> But not quite enough to look into what it's doing and make it stop.
<sarnold> s/ir//
<infinity> sarnold: Maybe I meant disproportionately, not irrationally.  I have solid reason to be annoyed, but perhaps not quite enough reason to decide flinging my laptop out the window is a solid response.
<infinity> "Today, we're teaching ThinkPads how to fly!" -- UHF, sort of.
<sarnold> rofl
<sarnold> oh man
<tsimonq2> Thinkpads are super reliable, though.
<tsimonq2> I've heard of people chucking them out of cars and them surviving without a scratch.
<infinity> https://youtu.be/Btdp-sC8MJI?t=84
<tsimonq2> LOL
<tsimonq2> Well, that's not *really* funny because hurting dogs is bad, but the actor is funny... :P
<infinity> No poodles were harmed in the filming of UHF.
<infinity> Spatulas, on the other hand...
<wxl> we're spatula city
<wxl> we sell spatulas
<wxl> and that's all
<wxl> interesting fact: i have most of the lyrics to the soundtrack of UHF committed to memory
<infinity> Seems like a noble use of grey matter.
<slangasek> www.amazon.com/Spatulas/
<wxl> indeed. if only i still had the LP
<sarnold> wxl: heh, and i've got the movie memorized..
<wxl> sarnold: great minds think alike, my friend
<slangasek> now
<slangasek> someone explain to tsimonq2 what the title means
<tsimonq2> Please do. I want to know. :P
<wxl> hahahahah
<wxl> it'll take too long
<sarnold> ehehe
<wxl> that'd be like explaining POTS
<slangasek> tsimonq2: so in the olden days, before all TV transmissions were digital...
<wxl> or gopher
<slangasek> or HBO's iconic intro sequence
<wxl> or when MTV stood for *MUSIC* television
<infinity> wxl: And, for those who thought Spatula City seemed a bit silly and far-fetched, let me point out that I used to pass https://www.casterland.com/ on the train every day on the way to school.
<wxl> um, wow.
<sarnold> oh man 50% casters??
<infinity> It is, actually, kind of as awesome as it sounds, if you really want to put wheels on... Anything.
<tsimonq2> wxl, slangasek: I guess I need to do some researching. :P  I'm barely old enough to remember the THX intro, though. I used to be mesmerized with that thing as a kid.
<sarnold> four locations :)
<sarnold> thx intro was good stuff..
<wxl> tsimonq2: doesn't count. if you had watched thx-1138, THAT would count.
<tsimonq2> Hah.
<tsimonq2> More researching... lol
<slangasek> https://www.youtube.com/watch?v=nu0R96OZy6w
<sarnold> I have to wonder if UHF would be fun today as a new viewer.. I kind of think it would be, but perhaps feel a bit slow..
<slangasek> tsimonq2: yes, do your research and some day you, too can be as cool as the old people
<wxl> slangasek: not to mention he has no idea about the Tracey Ullman Show
<sarnold> slangasek: <3
<tsimonq2> slangasek: :D
<tsimonq2> OMG that Simpson's video
<tsimonq2> "Turn it up! Turn it up!"
<infinity> slangasek: I raise you a Ralph: https://www.youtube.com/watch?v=gin_JSHuavY
<infinity> slangasek: The laughter in the cinema when he poppued up there was deafening.
<wxl> https://www.youtube.com/watch?v=dFQC-Qsc2V4
<slangasek> infinity: ahaha I'd forgotten that one
<sarnold> how could you forget that? I hear ralph every time i hear that music now.
<wxl> oh here we go
<wxl> bonus points if you can name where the visuals are from
<wxl> https://www.youtube.com/watch?v=X3HeX326haQ
<wxl> and if you looked at the credits, shame on you
<slangasek> wxl: imma go with Johnny Mnemonic
<infinity> wxl: It's a tossup between an assembly.org demo or a WMP/WinAMP visualisation plugin. :P
<wxl> not even close in terms of release date
<wxl> that might actually be what it was made with, but the idea is getting the movie it was in, infinity
<slangasek> still standing by my answer
<wxl> actually, no, it's older than i thought, actually. totally predates personal computers
<infinity> Yeah, it would have been done with light and camera tricks, not digitally.
<wxl> it's from the very end of 2001: A Space Odyssey, where everything gets really, really, really trippy
<infinity> Or possibly hand-animated, but it looks like time-lapse lightbox work to me.
<wxl> it's from '68
<infinity> *nod*
<slangasek> Johnny Mnemonic was Kubrick's best film
<wxl> BAH
<infinity> slangasek: A Clockwork Orange would like to staple your eyelids open and have a word with you.
<wxl> Dr. Strangelove is really awesome, too
<infinity> https://www.youtube.com/watch?v=UAeqVGP-GPM
<infinity> Indeed.
<wxl> also was that Johnny Mnemonic was Kubrick's best film some sort of troll attempt?
<wxl> XD
<infinity> Because it wasn't Kubrik, or because anything with Dolph Lundgren in it can't be the best of any collection?
<slangasek> I only ever saw Dr. Strangelove last year when I was stuck in a tin can over an ocean.  I found that I hadn't missed any of the nuance from not having seen it with my own eyes
<sarnold> aww :( watching dr strangelove has been on my todo list for .. uhh .. a while.
<slangasek> wxl: yeeeeees
<infinity> sarnold: Get the audiobook instead.  Bobcat Goldthwait reads the screenplay.
<slangasek> ahaha
<wxl> it's really really good, though unlike most of Kubrick's work, wasn't too remarkable in the cinematography department
<sarnold> infinity: ha! sounds solid
<wxl> there again
<infinity> I'm giggling imagining him reading the precious bodily fluids bits.
<wxl> we couldn't possibly explain "Zed" to tsimonq2
<slangasek> sarnold: I'm guessing maybe it's more impactful if the plot hadn't already been spoiled
<slangasek> you know, by being a trope of our civilization
<infinity> slangasek: Yeah, I'm not sure what the statute of limitations on spoilers is, but I'm pretty sure it's less than 54 years.
<wxl> X''''D
<wxl> https://www.youtube.com/watch?v=NliooKg12yE
<tsimonq2> ...what is this? :D
<wxl> Bobcat Goldthwait
<tsimonq2> Oh. My. Gawd. This... this is beautiful. XD
<wxl> playing Zed from Police Academy, but ultimately, that seemed to be what ALL his characters were and actually what HE was
<slangasek> https://www.youtube.com/watch?v=LFasrNIqY1Q
<wxl> is this from your personal collection, slangasek ? XD
<wxl> i would have been more terrified about the pilot announcing they were landing in cleveland
<tsimonq2> XD
<tsimonq2> https://www.youtube.com/watch?v=rITk6utJvRY <-- omg Letterman, WHAT is that hairstyle
<sarnold> tsimonq2: http://overlookedgems.blogspot.com/2006/04/dry-look.html
<tsimonq2> sarnold: But that's from '82!
-queuebot:#ubuntu-release- New binary: libticonv [ppc64el] (cosmic-proposed/universe) [1.1.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libticables [amd64] (cosmic-proposed/universe) [1.3.5+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libticables [s390x] (cosmic-proposed/universe) [1.3.5+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libticables [ppc64el] (cosmic-proposed/universe) [1.3.5+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libticables [i386] (cosmic-proposed/universe) [1.3.5+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-tktreectrl [amd64] (cosmic-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libticonv [s390x] (cosmic-proposed/universe) [1.1.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pymecavideo [amd64] (cosmic-proposed/universe) [6.5-2] (no packageset)
<tsimonq2> This was fun... have a good night y'all. :)
<tsimonq2> Chat later when I haz patches.
<sarnold> gnight tsimonq2 :)
-queuebot:#ubuntu-release- New binary: libticonv [i386] (cosmic-proposed/universe) [1.1.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ublock-origin [amd64] (cosmic-proposed/universe) [1.16.6+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnucap [s390x] (cosmic-proposed/universe) [1:0.36~20171003-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libticonv [amd64] (cosmic-proposed/universe) [1.1.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: weston [ppc64el] (cosmic-proposed/universe) [4.0.0-1] (xorg)
-queuebot:#ubuntu-release- New binary: weston [s390x] (cosmic-proposed/universe) [4.0.0-1] (xorg)
-queuebot:#ubuntu-release- New binary: libticables [arm64] (cosmic-proposed/universe) [1.3.5+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: weston [i386] (cosmic-proposed/universe) [4.0.0-1] (xorg)
-queuebot:#ubuntu-release- New binary: weston [amd64] (cosmic-proposed/universe) [4.0.0-1] (xorg)
-queuebot:#ubuntu-release- New binary: gnucap [ppc64el] (cosmic-proposed/universe) [1:0.36~20171003-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libticables [armhf] (cosmic-proposed/universe) [1.3.5+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libticonv [arm64] (cosmic-proposed/universe) [1.1.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libticonv [armhf] (cosmic-proposed/universe) [1.1.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnucap [amd64] (cosmic-proposed/universe) [1:0.36~20171003-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnucap [i386] (cosmic-proposed/universe) [1:0.36~20171003-1] (no packageset)
-queuebot:#ubuntu-release- New binary: healpy [amd64] (cosmic-proposed/universe) [1.10.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: weston [arm64] (cosmic-proposed/universe) [4.0.0-1] (xorg)
-queuebot:#ubuntu-release- New binary: gnucap [arm64] (cosmic-proposed/universe) [1:0.36~20171003-1] (no packageset)
-queuebot:#ubuntu-release- New binary: weston [armhf] (cosmic-proposed/universe) [4.0.0-1] (xorg)
-queuebot:#ubuntu-release- New binary: gnucap [armhf] (cosmic-proposed/universe) [1:0.36~20171003-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gnucap [arm64] (cosmic-proposed) [1:0.36~20171003-1]
-queuebot:#ubuntu-release- New: accepted gnucap [armhf] (cosmic-proposed) [1:0.36~20171003-1]
-queuebot:#ubuntu-release- New: accepted gnucap [amd64] (cosmic-proposed) [1:0.36~20171003-1]
-queuebot:#ubuntu-release- New: accepted gnucap [ppc64el] (cosmic-proposed) [1:0.36~20171003-1]
-queuebot:#ubuntu-release- New: accepted healpy [amd64] (cosmic-proposed) [1.10.3-3]
-queuebot:#ubuntu-release- New: accepted libticables [arm64] (cosmic-proposed) [1.3.5+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libticables [i386] (cosmic-proposed) [1.3.5+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libticables [s390x] (cosmic-proposed) [1.3.5+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libticonv [arm64] (cosmic-proposed) [1.1.5-2]
-queuebot:#ubuntu-release- New: accepted libticonv [i386] (cosmic-proposed) [1.1.5-2]
-queuebot:#ubuntu-release- New: accepted libticonv [s390x] (cosmic-proposed) [1.1.5-2]
-queuebot:#ubuntu-release- New: accepted python-tktreectrl [amd64] (cosmic-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted gnucap [i386] (cosmic-proposed) [1:0.36~20171003-1]
-queuebot:#ubuntu-release- New: accepted libticables [amd64] (cosmic-proposed) [1.3.5+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libticables [ppc64el] (cosmic-proposed) [1.3.5+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libticonv [armhf] (cosmic-proposed) [1.1.5-2]
-queuebot:#ubuntu-release- New: accepted pymecavideo [amd64] (cosmic-proposed) [6.5-2]
-queuebot:#ubuntu-release- New: accepted weston [amd64] (cosmic-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New: accepted weston [armhf] (cosmic-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New: accepted weston [ppc64el] (cosmic-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New: accepted gnucap [s390x] (cosmic-proposed) [1:0.36~20171003-1]
-queuebot:#ubuntu-release- New: accepted libticonv [amd64] (cosmic-proposed) [1.1.5-2]
-queuebot:#ubuntu-release- New: accepted ublock-origin [amd64] (cosmic-proposed) [1.16.6+dfsg-1]
-queuebot:#ubuntu-release- New: accepted weston [i386] (cosmic-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New: accepted libticables [armhf] (cosmic-proposed) [1.3.5+dfsg-2]
-queuebot:#ubuntu-release- New: accepted weston [arm64] (cosmic-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New: accepted libticonv [ppc64el] (cosmic-proposed) [1.1.5-2]
-queuebot:#ubuntu-release- New: accepted weston [s390x] (cosmic-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New binary: inkscape [amd64] (cosmic-proposed/universe) [0.92.3-2] (ubuntustudio)
#ubuntu-release 2018-05-23
-queuebot:#ubuntu-release- New binary: libtifiles [ppc64el] (cosmic-proposed/universe) [1.1.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libtifiles [s390x] (cosmic-proposed/universe) [1.1.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libtifiles [amd64] (cosmic-proposed/universe) [1.1.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libtifiles [i386] (cosmic-proposed/universe) [1.1.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libtifiles [arm64] (cosmic-proposed/universe) [1.1.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libtifiles [armhf] (cosmic-proposed/universe) [1.1.7-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted libtifiles [amd64] (cosmic-proposed) [1.1.7-2]
-queuebot:#ubuntu-release- New: accepted libtifiles [armhf] (cosmic-proposed) [1.1.7-2]
-queuebot:#ubuntu-release- New: accepted libtifiles [ppc64el] (cosmic-proposed) [1.1.7-2]
-queuebot:#ubuntu-release- New: accepted libtifiles [arm64] (cosmic-proposed) [1.1.7-2]
-queuebot:#ubuntu-release- New: accepted libtifiles [s390x] (cosmic-proposed) [1.1.7-2]
-queuebot:#ubuntu-release- New: accepted libtifiles [i386] (cosmic-proposed) [1.1.7-2]
-queuebot:#ubuntu-release- New binary: libticalcs [ppc64el] (cosmic-proposed/universe) [1.1.9+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libticalcs [s390x] (cosmic-proposed/universe) [1.1.9+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libticalcs [amd64] (cosmic-proposed/universe) [1.1.9+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libticalcs [i386] (cosmic-proposed/universe) [1.1.9+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libticalcs [arm64] (cosmic-proposed/universe) [1.1.9+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libticalcs [armhf] (cosmic-proposed/universe) [1.1.9+dfsg-2] (no packageset)
<xnox> slangasek, infinity - i want to change UEFI boot options as well. Default to maybe-ubiquity, call that menu option "Ubuntu" and hide other options in additional submenu (e.g. Try, Install, Debug, etc.)
-queuebot:#ubuntu-release- New: accepted inkscape [amd64] (cosmic-proposed) [0.92.3-2]
-queuebot:#ubuntu-release- New: accepted libticalcs [arm64] (cosmic-proposed) [1.1.9+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libticalcs [i386] (cosmic-proposed) [1.1.9+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libticalcs [s390x] (cosmic-proposed) [1.1.9+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libticalcs [amd64] (cosmic-proposed) [1.1.9+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libticalcs [ppc64el] (cosmic-proposed) [1.1.9+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libticalcs [armhf] (cosmic-proposed) [1.1.9+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: ncurses (bionic-proposed/main) [6.1-1ubuntu1 => 6.1-1ubuntu1.18.04] (core)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-bad1.0 (bionic-proposed/universe) [1.14.0-1ubuntu1 => 1.14.1-1ubuntu1~ubuntu18.04.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-good1.0 (bionic-proposed/main) [1.14.0-1ubuntu1 => 1.14.1-1ubuntu1~ubuntu18.04.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-base1.0 (bionic-proposed/main) [1.14.0-2ubuntu1 => 1.14.1-1ubuntu1~ubuntu18.04.1] (desktop-core, ubuntu-server)
<tsimonq2> xnox: If you let me know where that is, I can make it part of my MPs.
<tsimonq2> And you mean "maybe-installer"? ;)
<xnox> tsimonq2, i believe it is in lp:~ubuntu-cdimage/debian-cd/ubuntu in tools/boot/bionic/boot-amd64 for example, the grub.cfg portions
<tsimonq2> ack, thanks
-queuebot:#ubuntu-release- Unapproved: gnome-characters (bionic-proposed/main) [3.28.0-3 => 3.28.2-0ubuntu1] (ubuntu-desktop, ubuntugnome)
<ahasenack> hi, is apache2 "not considered" in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html because of "old binaries left ..."?
<ahasenack>  2.4.33-3ubuntu1 never migrated and 3ubuntu2 is fixing that
<ahasenack> exactly because of those new binaries
<ahasenack> or did the page just not update yet? There was a failing test in the previous refresh that now passed
<ahasenack> update_output.txt doesn't seen to have an entry for apache2
<apw> ahasenack, no you are doing something more complex than it can understnad, it needs a finger inserted
<apw> ahasenack, can you confirm, the listed binaries were added and then removed again in the uploads that were only in -proposed
<ahasenack> apw: yes I confirm
<ahasenack> apw: they exist in the archive already, but from another source package
<apw> ahasenack, with luck that is resolved, let me know if it doesn't after a publisher run
<ahasenack> apw: thanks
<Laney> someone reject those gst-* please
<Laney> using a silo instead
 * Laney the irritator of the SRU team
<apw> Laney, bionic ?
<Laney> ya
-queuebot:#ubuntu-release- Unapproved: rejected gst-plugins-bad1.0 [source] (bionic-proposed) [1.14.1-1ubuntu1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected gst-plugins-good1.0 [source] (bionic-proposed) [1.14.1-1ubuntu1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected gst-plugins-base1.0 [source] (bionic-proposed) [1.14.1-1ubuntu1~ubuntu18.04.1]
<Laney> ð
<Laney> thanks apw ð¯
 * apw awwws, i missed your emoticon phase
<sil2100> Now the emojis are all colorful on my irssi window
<apw> yeah mine are nice a shiney too
<Laney> :D
-queuebot:#ubuntu-release- Unapproved: crda (xenial-proposed/main) [3.13-1 => 3.13-1ubuntu0.16.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted crda [source] (xenial-proposed) [3.13-1ubuntu0.16.04.1]
<slangasek> xnox: can you communicate on ubuntu-devel about bzr's demotion, so that any teams that still have branches maintained in bzr (like, um, the release team and the cdimage team, and the core-dev team with all the seed branches that you just updated) know that it's no longer officially supported?  and did you look at bringing breezy in to replace it?
<slangasek> xnox: UEFI boot options> the lack of consistency between UEFI and BIOS is terribly annoying.  I don't necessarily know that defaulting to maybe-ubiquity will resolve this.
<xnox> slangasek, it's not about bzr or breezy. Bringing in breezy will not help, as that is still python2-only at the moment.
<slangasek> ok, I thought there was supposed to be python3ery
<slangasek> if it's still only "in progress", well
<xnox> slangasek, *planning to become*
<xnox> slangasek, ubuntu development team has many tools and utilities which are not in main, and are used to develop ubuntu. And that is fine by me.
<xnox> slangasek, including launchpad itself, bzr branches, etc.
<slangasek> xnox: please communicate this change to the developers all the same
<xnox> slangasek, but we should not ship python2 in main going forward because of that.
<cjwatson> breezy's at least getting there
<cjwatson> but it probably ought to have a stable release before anyone goes around recommending it
<cjwatson> (we're waiting for that before switching LP's code hosting over to it, for instance)
<slangasek> infinity, cjwatson: speaking of which, I wasn't sure if there needed to be any discussion or if I should JFDI the bzr->git migration for the seeds https://wiki.ubuntu.com/Germinate/ConvertingToGit
<cjwatson> I have no particular problem with JFDI
<cjwatson> git all the things
<tsimonq2> I sent Adam an email...
<tsimonq2> JFDI.
<tsimonq2> I already converted the branches, pushed to my LP profile
<cpaelzer> can someone in here free dovecot from cosmics new queue?
<cpaelzer> in artful we dropped one of its binary packages
<cpaelzer> issues are now resolved, so it is reintorucde
<cpaelzer> which makes it stuck in new queue
-queuebot:#ubuntu-release- Unapproved: chrony (bionic-proposed/main) [3.2-4ubuntu4 => 3.2-4ubuntu4.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted chrony [source] (bionic-proposed) [3.2-4ubuntu4.1]
<xnox> infinity, thanks a lot! powersj fixed everything and http://cdimage.ubuntu.com/ubuntu-server/daily/current/ looks awesome now.
<mdeslaur> is the publisher broken again? I've been waiting 2 hours
<cjwatson> it wasn't broken last time you asked, it was just busy vacuuming
<cjwatson> and that's what it's doing at the moment too
<Laney> should have used a dyson
<mdeslaur> cjwatson: how often does it vacuum? can the job me moved away from the usual unembargo times?
<cjwatson> mdeslaur: I'm waiting for infinity's promised patch to make it weekly on Sunday evening or whatever rather than daily when it's >24hr since the last run
<cjwatson> mdeslaur: or alternatively for infinity to tell me he no longer holds the baton on that patch in which case I'll do it
 * mdeslaur sends beer to infinity
-queuebot:#ubuntu-release- New: rejected ndctl [source] (cosmic-proposed) [60.1-0ubuntu1]
<coreycb> hello, can an archive admin please promote the following list of packages to main? https://paste.ubuntu.com/p/RZcZ9tbFYT/  these are all python3 packages with corresponding python2 packages that are already in main.
<slangasek> coreycb: I will work through these
<coreycb> slangasek: thank you
<slangasek> coreycb: overridden
<coreycb> slangasek: great, thanks again
<wxl> does anyone envision the return of edubuntu or mythbuntu? i see they're still mentioned at https://wiki.ubuntu.com/UbuntuFlavors
<sarnold> seems unlikely to me
<wxl> that's my feeling, too, and given u.c/download/flavours doesn't mention them...
<wxl> is there any reason why we can't store flavors in old-images.u.c like we do with ubuntu?
-queuebot:#ubuntu-release- Unapproved: dkms (bionic-proposed/main) [2.3-3ubuntu9 => 2.3-3ubuntu9.1] (kubuntu, ubuntu-desktop)
<slangasek> wxl: because space is not unlimited and we need to manage the rate of growth on that service.  Flavors may provide their own archives (and we may be able to recover images from older releases if there's sufficient interest), but Canonical hasn't offered to host that
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20180510+dfsg1-0ubuntu3~14.04.0 => 20180510+dfsg1-0ubuntu3~14.04.1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: apport (bionic-proposed/main) [2.20.9-0ubuntu7 => 2.20.9-0ubuntu7.1] (core)
#ubuntu-release 2018-05-24
<tsimonq2> slangasek: Altispeed (my employer) can host that.
<tsimonq2> I get a machine with decent storage space to do whatever I'd like with by the end of the week.
<tsimonq2> slangasek: If I have one request though, it would be for Canonical to provide checksums (and only checksums) for ISOs so people who don't trust me or Altispeed can do their own verification.
<tsimonq2> Otherwise I'd be happy to give whoever (~ubuntu-release is probably a prereq) SSH access.
<slangasek> tsimonq2: surely they should be doing verification via the SHA256SUMS.gpg files, which are all signed with the cdimage key and would be part of anything you would be serving up
<tsimonq2> slangasek: Ah, that works.
<slangasek> tsimonq2: anyway, if you want to set up a mirror of the images, you don't need to coordinate that; and once set up you can let me know what images you want us to try to pull out of cold storage
<tsimonq2> slangasek: Lubuntu at minimum is on board, but I'm just generally wondering how open y'all would be to copying the ISOs over to this server during the EOL process, or if you would consider this just "a random mirror that exists on the internet"
<tsimonq2> Seeing that they can verify the ISOs, and I'm willing to do whatever possible to make this work (and so is Altispeed), I'd be inclined to do the former, but if it's the latter because it's not in Canonical's control (the real hardware isn't, anyway) then I guess that's it.
<slangasek> tsimonq2: I would suggest there's no real value in having this be something we push rather than something you pull, and if you pull it you can do it all before EOL rather than it being part of an EOL process
<tsimonq2> slangasek: WFM.
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525 => 2.525.1] (desktop-core)
<tsimonq2> slangasek: So, the more ISOs you have the better, of all flavors.
<tsimonq2> There, so that should be the last of the LXQt transition. It migrates pretty quickly, almost too quickly to call it a transition. :P
<acheronuk> morning. openexr in it's transition seems to have built before the new ilmbase libs were available, so is seemingly blocking itself in it's own transition
 * acheronuk glares at what lack of caffeine does to his grammar ^^^
<cpaelzer> re-ping if anyone could free dovecot from cosmic-new queue?
<cpaelzer> it is reintroducing a package that we dropped artful/bionic
<cpaelzer> now things are fine so we re-introduce
-queuebot:#ubuntu-release- New: accepted dovecot [amd64] (cosmic-proposed) [1:2.2.35-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted dovecot [armhf] (cosmic-proposed) [1:2.2.35-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted dovecot [ppc64el] (cosmic-proposed) [1:2.2.35-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted dovecot [arm64] (cosmic-proposed) [1:2.2.35-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted dovecot [s390x] (cosmic-proposed) [1:2.2.35-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted dovecot [i386] (cosmic-proposed) [1:2.2.35-2ubuntu1]
<apw> cpaelzer, ^
<cpaelzer> thanks apw
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (trusty-proposed) [20180510+dfsg1-0ubuntu3~14.04.1]
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20180510+dfsg1-0ubuntu3~14.04.0 => 20180510+dfsg1-0ubuntu3~14.04.1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (trusty-proposed) [20180510+dfsg1-0ubuntu3~14.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected snapd-glib [source] (bionic-proposed) [1.40-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted netcat-openbsd [source] (bionic-proposed) [1.187-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu10.1]
-queuebot:#ubuntu-release- Unapproved: mdadm (bionic-proposed/main) [4.0-2ubuntu1 => 4.0-2ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted libsdl2 [source] (bionic-proposed) [2.0.8+dfsg1-1ubuntu1.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted libsdl2 [source] (artful-proposed) [2.0.6+dfsg1-3ubuntu1.17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-9.5 [source] (xenial-proposed) [9.5.13-0ubuntu0.16.04]
-queuebot:#ubuntu-release- New binary: qgis [s390x] (cosmic-proposed/universe) [2.18.20+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-23.25] (core, kernel)
-queuebot:#ubuntu-release- New binary: qgis [ppc64el] (cosmic-proposed/universe) [2.18.20+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-23.25] (core, kernel)
-queuebot:#ubuntu-release- New binary: qgis [i386] (cosmic-proposed/universe) [2.18.20+dfsg-1] (no packageset)
<cpaelzer> sil2100: thanks for accepting the postgres MRE into x-proposed
<cpaelzer> sil2100: any reason not to do the same on T/A/B ?
<cpaelzer> see bug 1769888 as they belong together
<ubot5> bug 1769888 in postgresql-10 (Ubuntu Bionic) "New upstream microreleases 9.3.23, 9.5.13, 9.6.9 and 10.4" [Undecided,Triaged] https://launchpad.net/bugs/1769888
-queuebot:#ubuntu-release- New binary: qgis [amd64] (cosmic-proposed/universe) [2.18.20+dfsg-1] (no packageset)
<sil2100> cpaelzer: I'll get to them soon, got pulled off to something else + lunch
<sil2100> cpaelzer: btw. is Bileto having issues with autopkgtests again?
-queuebot:#ubuntu-release- New binary: qgis [armhf] (cosmic-proposed/universe) [2.18.20+dfsg-1] (no packageset)
<cpaelzer> sil2100: yes
<cpaelzer> >=Bionic I can't precheck via Bileto
<cpaelzer> I did on some of the tests, but can't achieve the same cross arch coverage that the real infra gives me
-queuebot:#ubuntu-release- New binary: qgis [arm64] (cosmic-proposed/universe) [2.18.20+dfsg-1] (no packageset)
<sil2100> cpaelzer: I'll try fixing that after lunch
<cpaelzer> sil2100: oh are you the one I can ping on this now
<cpaelzer> didn't realize you took that from robru
<cpaelzer> I was just kind of slowly giving up, would be great if it works again
-queuebot:#ubuntu-release- New source: ndctl (cosmic-proposed/primary) [60.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-9.6 [source] (artful-proposed) [9.6.9-0ubuntu0.17.10]
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-10 [source] (bionic-proposed) [10.4-0ubuntu0.18.04]
<mdeslaur> could someone please remove apport from the bionic upload queue?
<mdeslaur> bdmurray is aware of it
<mdeslaur> bdmurray: it was just bionic, right?
<bdmurray> mdeslaur: yeah, I can remove it myself
-queuebot:#ubuntu-release- Unapproved: rejected apport [source] (bionic-proposed) [2.20.9-0ubuntu7.1]
<Laney> bdmurray: can you point me to the code for the rls-mgr reports?
<bdmurray> Laney: https://code.launchpad.net/~ubuntu-reports-dev/ubuntu-reports/trunk
<mdeslaur> thanks bdmurray
<Laney> thx
<vtapia> hi sil2100, just added the missing regression potential field in bug 1771805, thanks and sorry for that!
<ubot5> bug 1771805 in sssd (Ubuntu Xenial) "AD keytab renewal task leaks a file descriptor" [Medium,In progress] https://launchpad.net/bugs/1771805
<sil2100> vtapia: thanks!
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-9.3 [source] (trusty-proposed) [9.3.23-0ubuntu0.14.04]
<sil2100> vtapia: approved
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (xenial-proposed) [1.13.4-1ubuntu1.11]
 * sil2100 had to read up some about talloc for this one
<vtapia> cool, thanks sil2100!
-queuebot:#ubuntu-release- Unapproved: maas (bionic-proposed/main) [2.4.0~beta2-6865-gec43e47e6-0ubuntu1 => 2.4.0-6981-g011e51b7a-0ubuntu1~18.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: maas (bionic-proposed/main) [2.4.0~beta2-6865-gec43e47e6-0ubuntu1 => 2.4.0-6981-g011e51b7a-0ubuntu1~18.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- New source: pmdk (cosmic-proposed/primary) [1.4-0ubuntu1]
<bdmurray> sil2100: Are you all done with SRU work?
<sil2100> bdmurray: yes
<bdmurray> sil2100: thanks
<tsimonq2> sil2100: By Monday, my plan is to do another VLC SRU, this time for Xenial amnd 2.2.8.
<tsimonq2> *and
<tsimonq2> Would you expect the same from this as with Bionic?
<tsimonq2> (Call for testing, multiple people, etc.)
<tsimonq2> It would certainly make security updates a tad bit easier I think. ;)
<ahasenack> hi, could someone please reject the old pmdk from https://launchpad.net/ubuntu/cosmic/+queue, the one from May 22nd?
-queuebot:#ubuntu-release- New: rejected pmdk [source] (cosmic-proposed) [1.4-0ubuntu1]
<apw> ahasenack, ^
<ahasenack> apw: thanks
-queuebot:#ubuntu-release- New binary: spirv-headers [amd64] (cosmic-proposed/none) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-23.25]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-23.25]
-queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (bionic-proposed) [2.3-3ubuntu9.1]
-queuebot:#ubuntu-release- Unapproved: accepted mdadm [source] (bionic-proposed) [4.0-2ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (bionic-proposed) [2.525.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-characters [source] (bionic-proposed) [3.28.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ncurses [source] (bionic-proposed) [6.1-1ubuntu1.18.04]
-queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (bionic-proposed) [1:11.1-1ubuntu7.1]
-queuebot:#ubuntu-release- New binary: rustc [s390x] (cosmic-proposed/universe) [1.26.0+dfsg0+llvm-0ubuntu1] (no packageset)
<teward> anyone around who can mark a handful of autopkgtests as ignored?
-queuebot:#ubuntu-release- New binary: rustc [ppc64el] (cosmic-proposed/universe) [1.26.0+dfsg0+llvm-0ubuntu1] (no packageset)
<apw> teward, we don't like to do that without a good reason ...
<teward> apw: how about a package which fails all of its autopkgtests regardless of who triggers it, because the app itself segfaults?
<teward> and in turn blocks other *functioning* applications from migrating
<apw> that is sounding like a believeable reason
<teward> apw: searx is failing consistently some of its autopkgtests, including in Debian, and has 'Regression' failures for nginx's triggering of it.  myself and others in #ubuntu-server tracked the issue to the application itself and uwsgi having a segfault problem.
<teward> but not an nginx issue
<teward> nginx has a dependency on Perl which is *also* migrating, but searx's autopkgtests fail including in Debian
<teward> digging into it we found it was the app itself via uwsgi triggers a segfault
<teward> even if nginx is not installed and Apache is tested/used.
<teward> so there's three "regression" status autopkgtests triggered by the nginx upload which should be ignored because the issue is in the searx app itself.
<teward> (and those are the only failing autopkgtests)
<apw> teward, ack thanks
<teward> apw: FWIW there's bugs on this as well against searx
<teward> opened during the dig-down yesterday by myself and ahasenack
<apw> teward, cna i have the number ... i'll add it with the hint
<teward> standby let me pull them
<teward> https://bugs.launchpad.net/ubuntu/+source/searx/+bug/1772749 is the bug about the autopkgtest failures, https://bugs.launchpad.net/ubuntu/+source/searx/+bug/1772753 is the crash dump bug report.
<ubot5> Ubuntu bug 1772749 in searx (Ubuntu) "[Cosmic] searx segfaults when being run" [Critical,New]
<ubot5> Ubuntu bug 1772753 in searx (Ubuntu) "[searx] - uwsgi-core crashed with SIGSEGV in __libc_fork()" [Medium,New]
<teward> (though uwsgi-core crashed, uwsgi on its own with the "Hello World" example from upstream works fine)
<teward> (so that crash bug was repointed to searx)
<apw> teward, transcribed and pushed
<teward> apw: thank you kindly.
-queuebot:#ubuntu-release- Unapproved: accepted openldap [source] (xenial-proposed) [2.4.42+dfsg-2ubuntu3.3]
<teward> apw: i just got an email from proposed-migration from the release team via noreply@, should I disregard that?
<teward> (saying it's been stuck for 6 days)
-queuebot:#ubuntu-release- Unapproved: accepted haproxy [source] (trusty-proposed) [1.4.24-2ubuntu0.5]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.13.0-44.49] (core, kernel)
<slangasek> ginggs: did you have any fun with seqan2's sigbus?
<ginggs> slangasek: ah no, been busy with openmpi
<apw> teward, yeah it tends to send you those and release it at the same time ...
<ginggs> slangasek: if we drop armhf as an archtecture we solve both problems
<LocutusOfBorg> ginggs, I syncd openmpi from debian...
<LocutusOfBorg> tomorrow I'll help debugging it if needed (and with my little knowledge)
<ginggs> LocutusOfBorg: ok, you can re-run all the autopkgtests with the correct versions
-queuebot:#ubuntu-release- Unapproved: budgie-desktop-environment (bionic-proposed/universe) [0.9.9 => 0.9.9ubuntu1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (bionic-proposed/main) [1.1ubuntu1 => 1.2ubuntu1~18.04.0] (desktop-core, ubuntu-server)
<LocutusOfBorg> I prefer to use the debian patch, seems "better" wrt the ubuntu one http://launchpadlibrarian.net/371725772/openmpi_3.1.0-3ubuntu1_3.1.0-4.diff.gz
<LocutusOfBorg> sure ginggs I'll retry them tomorrow :)
 * LocutusOfBorg goes to sleep some bits
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (artful-proposed/main) [0.98ubuntu1.1 => 1.2ubuntu1~17.10.0] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: im-config (bionic-proposed/main) [0.34-1ubuntu1 => 0.34-1ubuntu1.1] (input-methods, kubuntu, personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: rustc [arm64] (cosmic-proposed/universe) [1.26.0+dfsg0+llvm-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.13.0-44.49]
#ubuntu-release 2018-05-25
<acheronuk> jbicha: seems field3d and pink-pony still depend on libilmbase12
<tsimonq2> pink-pony lol
<acheronuk> pink-pony: 3D racing game with ponies
<acheronuk> always more weird stuff to find in the archive I never knew about!#
<sarnold> watch out bzflag looks like there's a new linux game
-queuebot:#ubuntu-release- New: accepted qgis [amd64] (cosmic-proposed) [2.18.20+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [armhf] (cosmic-proposed) [2.18.20+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [ppc64el] (cosmic-proposed) [2.18.20+dfsg-1]
-queuebot:#ubuntu-release- New: accepted spirv-headers [amd64] (cosmic-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted qgis [arm64] (cosmic-proposed) [2.18.20+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [s390x] (cosmic-proposed) [2.18.20+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [i386] (cosmic-proposed) [2.18.20+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: plasma-discover (bionic-proposed/universe) [5.12.5-0ubuntu0.1 => 5.12.5.1-0ubuntu0.1] (kubuntu)
<LocutusOfBorg> ginggs, stuff retried, I'm doing gdal rebuilds too, because vtk is entangled
<ginggs> LocutusOfBorg: ok
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.15.0-1013.13] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.15.0-1013.13]
-queuebot:#ubuntu-release- Unapproved: gnome-calendar (bionic-proposed/main) [3.28.1-1ubuntu2 => 3.28.2-0ubuntu0.18.04.1] (desktop-extra, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: opencryptoki (bionic-proposed/universe) [3.9.0+dfsg-0ubuntu1 => 3.9.0+dfsg-0ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: opencryptoki (artful-proposed/universe) [3.7.0+dfsg-4 => 3.7.0+dfsg-4ubuntu1] (no packageset)
<teward> apw: ack, I will just disregard it since it shows as 'valid candidate' now.  Just have to wait on Perl heh
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-150.200] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-150.200]
<acheronuk> bdmurray sil2100 - can you please continue phasing of ksysguard and plasma-workspace in bionic updates? considering the previous error report history for both, I can see no causal relationship between them and the latest update
<acheronuk> plasma-discover has a fix in the unapproved queue
<rbalint> doko, i prepared a merge for procps which involves a small transition (4 rdeps) that's going on in Debian already, should i coordinate about the upload and no change rebuilds or i can go ahead in the next days with it?
<doko> just go ahead, I don't think that you need any kind of approval for that
<rbalint> doko, i just don't want to mess up other transitions, thanks
-queuebot:#ubuntu-release- New binary: rustc [s390x] (cosmic-proposed/universe) [1.26.0+dfsg0+llvm-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: bolt (bionic-proposed/main) [0.2-0ubuntu1 => 0.3-0ubuntu0.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (bionic-proposed/main) [1:3.28.1-0ubuntu1 => 1:3.28.1-0ubuntu1.18.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: rustc [ppc64el] (cosmic-proposed/universe) [1.26.0+dfsg0+llvm-0ubuntu2] (no packageset)
<bdmurray> acheronuk: looking
-queuebot:#ubuntu-release- New binary: rustc [i386] (cosmic-proposed/universe) [1.26.0+dfsg0+llvm-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted plasma-discover [source] (bionic-proposed) [5.12.5.1-0ubuntu0.1]
<cascardo> https://bugs.launchpad.net/ubuntu/cosmic/+source/nbd/+bug/1772024
<ubot5> Ubuntu bug 1772024 in nbd (Ubuntu Cosmic) "linux 4.13.0-42.47 ADT test failure with linux 4.13.0-42.47 (nbd-smoke-test)" [High,In progress]
<cascardo> can anyone review/sponsor my debdiff for nbd? target is cosmic
<bdmurray> Did you try ubuntu-devel? There should be more developers there.
<cascardo> will try that, thanks
-queuebot:#ubuntu-release- New binary: rustc [armhf] (cosmic-proposed/universe) [1.26.0+dfsg0+llvm-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [arm64] (cosmic-proposed/universe) [1.26.0+dfsg0+llvm-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: wireless-regdb (xenial-proposed/main) [2015.07.20-1ubuntu1 => 2018.05.09-0ubuntu1~16.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: wireless-regdb (bionic-proposed/main) [2016.06.10-0ubuntu1 => 2018.05.09-0ubuntu1~18.04.1] (core)
#ubuntu-release 2018-05-26
<acheronuk> LocutusOfBorg: have you any fix for the FTBFS of your merge of python-numpy on armhf?
<acheronuk> oh. reading back a loooong way, seems slangasek was looking at that?
<slangasek> except that I'm still blocked on reproducing it until IS sets up cosmic porter chroots for me
<acheronuk> slangasek or anyone else: also seems jemalloc was (unwisely?) synced from experimental, where it was FTBFS on multiple architectures, and now sits preventing some redep rebuilds for the ilmbases/openexr transition from becoming valid candidates
<acheronuk> could that maybe be removed?
<acheronuk> slangasek: oh. right. fair enough
<slangasek> jemalloc is on my list to look at still; it can be removed if necessary, as I told doko already
<acheronuk> slangasek: right. hmmm. my bnc scrollback clearly has some gaps. apologies
<slangasek> acheronuk: not necessarily, I told that to doko elsewhere :)
-queuebot:#ubuntu-release- Unapproved: debootstrap (artful-proposed/main) [1.0.91ubuntu1.1 => 1.0.91ubuntu1.2] (core)
-queuebot:#ubuntu-release- Unapproved: debootstrap (xenial-proposed/main) [1.0.78+nmu1ubuntu1.5 => 1.0.78+nmu1ubuntu1.6] (core)
-queuebot:#ubuntu-release- Unapproved: debootstrap (bionic-proposed/main) [1.0.95 => 1.0.95ubuntu0.1] (core)
-queuebot:#ubuntu-release- Unapproved: debootstrap (trusty-proposed/main) [1.0.59ubuntu0.9 => 1.0.59ubuntu0.10] (core)
<acheronuk> slangasek: kubuntu-meta has "seed_base: http://people.ubuntu.com/~ubuntu-archive/seeds/" in update.cfg
<acheronuk> I assume that is ok to keep?
<LocutusOfBorg> slangasek, if you have some minutes, also haskell-cipher-aes has a sad "arm64 usespace and armhf build misaligment"
<LocutusOfBorg> and I can't sort out the proxy error for haskell-iso8601-time and haskell-src-exts-util	
<LocutusOfBorg> but it is reproducible on pbuilder, so I'll debug it now
<LocutusOfBorg> interesting, pbuilder-dist sid login and then dpkg-buildpackage is ok, while pbuilder-dist sid build gives that HTTP error message
<LocutusOfBorg> any idea?
<slangasek> LocutusOfBorg: I'm again unlikely to be able to do anything with haskell-cipher-aes until porter chroots are available
<slangasek> acheronuk: seed_base: http://people.ubuntu.com/~ubuntu-archive/seeds/> well, I'd say it's not ideal, but it won't break as a result of the platform bzr->git migration
<acheronuk> slangasek: looks like its been that for a long time. I guess someone before my time thought it was a better choice :/
<acheronuk> slangasek: also https://github.com/numpy/numpy/issues/11088
<ubot5-ng> numpy bug 11088 in numpy "1.14.3 on sparc64: numpy.core.tests.test_multiarray.TestMethods.test__complex__should_not_work ... Bus error" (comments: 1) [Open]
<ubot5> bug 11088 in Ubuntu "scm: new changes from Debian require merging" [Wishlist,Invalid] https://launchpad.net/bugs/11088
<acheronuk> the github issue looks superficially the same/similar from the debian uploader
<acheronuk> not sure if that is overly illuminating at the moment, but fyi in case you had not seen that
<slangasek> acheronuk: sparc64 and armhf-on-arm64 have similar alignment requirements, but I don't know that there's a sparc64 Debian porter box currently either ;)
<slangasek> if there were an upstream patch that fixed it on sparc64 I would be +1 for applying it
<acheronuk> not yet that I can see. now I more or less confirm the issue, hopefully may be forthcoming
<slangasek> yeah there don't appear to be any reachable sparc64 Debian porterboxes currently
<acheronuk> oh well. hope for an upstream fix sooner than later then
<ginggs> slangasek: won't a armhf chroot on amdahl.d.o do the trick?
-queuebot:#ubuntu-release- New binary: blitz++ [ppc64el] (cosmic-proposed/none) [1:0.10+ds-3] (no packageset)
-queuebot:#ubuntu-release- New binary: blitz++ [s390x] (cosmic-proposed/none) [1:0.10+ds-3] (no packageset)
-queuebot:#ubuntu-release- New binary: blitz++ [amd64] (cosmic-proposed/none) [1:0.10+ds-3] (no packageset)
-queuebot:#ubuntu-release- New binary: blitz++ [arm64] (cosmic-proposed/universe) [1:0.10+ds-3] (no packageset)
-queuebot:#ubuntu-release- New binary: blitz++ [armhf] (cosmic-proposed/universe) [1:0.10+ds-3] (no packageset)
#ubuntu-release 2018-05-27
-queuebot:#ubuntu-release- New binary: libsis-jhdf5-java [i386] (cosmic-proposed/universe) [14.12.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libsis-jhdf5-java [ppc64el] (cosmic-proposed/universe) [14.12.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libsis-jhdf5-java [s390x] (cosmic-proposed/universe) [14.12.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libsis-jhdf5-java [amd64] (cosmic-proposed/universe) [14.12.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libsis-jhdf5-java [arm64] (cosmic-proposed/universe) [14.12.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libsis-jhdf5-java [armhf] (cosmic-proposed/universe) [14.12.6-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted libsis-jhdf5-java [amd64] (cosmic-proposed) [14.12.6-2]
-queuebot:#ubuntu-release- New: accepted libsis-jhdf5-java [armhf] (cosmic-proposed) [14.12.6-2]
-queuebot:#ubuntu-release- New: accepted libsis-jhdf5-java [ppc64el] (cosmic-proposed) [14.12.6-2]
-queuebot:#ubuntu-release- New: accepted libsis-jhdf5-java [arm64] (cosmic-proposed) [14.12.6-2]
-queuebot:#ubuntu-release- New: accepted libsis-jhdf5-java [s390x] (cosmic-proposed) [14.12.6-2]
-queuebot:#ubuntu-release- New: accepted libsis-jhdf5-java [i386] (cosmic-proposed) [14.12.6-2]
<slangasek> ginggs: empirically: no, it won't
<slangasek> ginggs: oops, I spoke too soon - just hit the failure
<slangasek> so yes
-queuebot:#ubuntu-release- New binary: budgie-extras [amd64] (cosmic-proposed/universe) [0.5.0-1] (personal-fossfreedom, ubuntu-budgie)
<slangasek> ginggs: https://paste.ubuntu.com/p/pFqprbDRCq/
-queuebot:#ubuntu-release- New: accepted budgie-extras [amd64] (cosmic-proposed) [0.5.0-1]
<mwhudson> a SIGBUS in something called DOUBLE_setitem, what are the chances
<slangasek> even better, it's C templating code ;P
-queuebot:#ubuntu-release- New: accepted blitz++ [amd64] (cosmic-proposed) [1:0.10+ds-3]
-queuebot:#ubuntu-release- New: accepted blitz++ [armhf] (cosmic-proposed) [1:0.10+ds-3]
-queuebot:#ubuntu-release- New: accepted blitz++ [arm64] (cosmic-proposed) [1:0.10+ds-3]
-queuebot:#ubuntu-release- New: accepted blitz++ [s390x] (cosmic-proposed) [1:0.10+ds-3]
-queuebot:#ubuntu-release- New: accepted blitz++ [ppc64el] (cosmic-proposed) [1:0.10+ds-3]
-queuebot:#ubuntu-release- New binary: codec2 [ppc64el] (cosmic-proposed/universe) [0.8-2] (no packageset)
-queuebot:#ubuntu-release- New binary: codec2 [s390x] (cosmic-proposed/universe) [0.8-2] (no packageset)
-queuebot:#ubuntu-release- New binary: codec2 [amd64] (cosmic-proposed/universe) [0.8-2] (no packageset)
-queuebot:#ubuntu-release- New binary: codec2 [arm64] (cosmic-proposed/universe) [0.8-2] (no packageset)
-queuebot:#ubuntu-release- New binary: codec2 [armhf] (cosmic-proposed/universe) [0.8-2] (no packageset)
-queuebot:#ubuntu-release- New binary: codec2 [i386] (cosmic-proposed/universe) [0.8-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted codec2 [amd64] (cosmic-proposed) [0.8-2]
-queuebot:#ubuntu-release- New: accepted codec2 [armhf] (cosmic-proposed) [0.8-2]
-queuebot:#ubuntu-release- New: accepted codec2 [ppc64el] (cosmic-proposed) [0.8-2]
-queuebot:#ubuntu-release- New: accepted codec2 [arm64] (cosmic-proposed) [0.8-2]
-queuebot:#ubuntu-release- New: accepted codec2 [s390x] (cosmic-proposed) [0.8-2]
-queuebot:#ubuntu-release- New: accepted codec2 [i386] (cosmic-proposed) [0.8-2]
#ubuntu-release 2019-05-20
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (bionic-proposed) [2:12.0.5-0ubuntu5]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.18.0-1019.19~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (cosmic-proposed) [4.18.0-1019.19]
<rbalint> sil2100, could you please release livecd-rootfs sru-s? it is early but it is a special package
<sil2100> rbalint: let me look at those in some moments
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1007.7] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1007.7]
-queuebot:#ubuntu-release- Unapproved: accepted apt-setup [source] (bionic-proposed) [1:0.104ubuntu5.1]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (cosmic-proposed/main) [4.18.0-1012.13] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (cosmic-proposed) [4.18.0-1012.13]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.18.0-21.22] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.18.0-21.22] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.18.0-21.22]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.18.0-21.22]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1046.50] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1046.50]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-51.55~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-51.55~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-51.55~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-51.55~16.04.1]
<coreycb> infinity: sil2100: hello, if you have some cycles we have a nova SRU in the bionic unapproved queue that is feeling some heat
<sil2100> coreycb: ACK
-queuebot:#ubuntu-release- Unapproved: accepted nautilus [source] (disco-proposed) [1:3.32.1-0ubuntu0.19.04.0]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [4.15.0-1033.35] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1033.35]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (disco-proposed) [3.30.6-2ubuntu4.19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (bionic-proposed) [2:17.0.9-0ubuntu3]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1033.35~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1033.35~16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-edge [amd64] (bionic-proposed/main) [4.18.0-1012.13~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: swift-im [s390x] (eoan-proposed/universe) [3.0.4-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: swift-im [amd64] (eoan-proposed/universe) [3.0.4-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: swift-im [i386] (eoan-proposed/universe) [3.0.4-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: swift-im [ppc64el] (eoan-proposed/universe) [3.0.4-1.1] (no packageset)
#ubuntu-release 2019-05-21
-queuebot:#ubuntu-release- New binary: swift-im [armhf] (eoan-proposed/universe) [3.0.4-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: swift-im [arm64] (eoan-proposed/universe) [3.0.4-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdist-zilla-plugin-checkextratests-perl [amd64] (eoan-proposed/none) [0.029-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-discourse-diff [amd64] (eoan-proposed/none) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libstring-interpolate-perl [amd64] (eoan-proposed/none) [0.32-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-discriminator [amd64] (eoan-proposed/none) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-has-scope [amd64] (eoan-proposed/none) [0.7.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-safely-block [amd64] (eoan-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-friendly-id [amd64] (eoan-proposed/none) [5.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-user-agent-parser [amd64] (eoan-proposed/none) [2.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-heroku-deflater [amd64] (eoan-proposed/none) [0.6.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ensmallen [s390x] (eoan-proposed/none) [1.14.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libdevel-findperl-perl [amd64] (eoan-proposed/none) [0.015-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ensmallen [amd64] (eoan-proposed/none) [1.14.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ensmallen [i386] (eoan-proposed/none) [1.14.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ensmallen [ppc64el] (eoan-proposed/none) [1.14.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ensmallen [arm64] (eoan-proposed/none) [1.14.3-1] (no packageset)
<Laney> vorlon: oh yeah, that's funny, I guess that would happen - we could prune journal just before we shut down the instance?
-queuebot:#ubuntu-release- Unapproved: libwww-perl (bionic-proposed/main) [6.31-1 => 6.31-1ubuntu0.1] (core) (sync)
-queuebot:#ubuntu-release- New: accepted ensmallen [amd64] (eoan-proposed) [1.14.3-1]
-queuebot:#ubuntu-release- New: accepted ensmallen [i386] (eoan-proposed) [1.14.3-1]
-queuebot:#ubuntu-release- New: accepted ensmallen [s390x] (eoan-proposed) [1.14.3-1]
-queuebot:#ubuntu-release- New: accepted libdist-zilla-plugin-checkextratests-perl [amd64] (eoan-proposed) [0.029-1]
-queuebot:#ubuntu-release- New: accepted ruby-discourse-diff [amd64] (eoan-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-friendly-id [amd64] (eoan-proposed) [5.2.5-1]
-queuebot:#ubuntu-release- New: accepted ruby-heroku-deflater [amd64] (eoan-proposed) [0.6.3-1]
-queuebot:#ubuntu-release- New: accepted ruby-user-agent-parser [amd64] (eoan-proposed) [2.5.1-1]
-queuebot:#ubuntu-release- New: accepted swift-im [arm64] (eoan-proposed) [3.0.4-1.1]
-queuebot:#ubuntu-release- New: accepted swift-im [i386] (eoan-proposed) [3.0.4-1.1]
-queuebot:#ubuntu-release- New: accepted ensmallen [arm64] (eoan-proposed) [1.14.3-1]
-queuebot:#ubuntu-release- New: accepted libdevel-findperl-perl [amd64] (eoan-proposed) [0.015-1]
-queuebot:#ubuntu-release- New: accepted ruby-discriminator [amd64] (eoan-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted ruby-safely-block [amd64] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted swift-im [armhf] (eoan-proposed) [3.0.4-1.1]
-queuebot:#ubuntu-release- New: accepted swift-im [s390x] (eoan-proposed) [3.0.4-1.1]
-queuebot:#ubuntu-release- New: accepted ensmallen [ppc64el] (eoan-proposed) [1.14.3-1]
-queuebot:#ubuntu-release- New: accepted ruby-has-scope [amd64] (eoan-proposed) [0.7.2-1]
-queuebot:#ubuntu-release- New: accepted swift-im [ppc64el] (eoan-proposed) [3.0.4-1.1]
-queuebot:#ubuntu-release- New: accepted libstring-interpolate-perl [amd64] (eoan-proposed) [0.32-1]
-queuebot:#ubuntu-release- New: accepted swift-im [amd64] (eoan-proposed) [3.0.4-1.1]
-queuebot:#ubuntu-release- Unapproved: gst-libav1.0 (bionic-proposed/universe) [1.14.1-1~ubuntu18.04.1 => 1.14.4-0ubuntu1~ubuntu18.04.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-base1.0 (bionic-proposed/main) [1.14.1-1ubuntu1~ubuntu18.04.2 => 1.14.4-1ubuntu1.1~ubuntu18.04.1] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-ugly1.0 (bionic-proposed/universe) [1.14.1-1~ubuntu18.04.1 => 1.14.4-1~ubuntu18.04.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-rtsp-server1.0 (bionic-proposed/universe) [1.14.1-1~ubuntu18.04.1 => 1.14.4-1~ubuntu18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gstreamer-vaapi (bionic-proposed/universe) [1.14.1-1~ubuntu18.04.1 => 1.14.4-1~ubuntu18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-bad1.0 (bionic-proposed/universe) [1.14.1-1ubuntu1~ubuntu18.04.1 => 1.14.4-1ubuntu1~ubuntu18.04.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-python1.0 (bionic-proposed/universe) [1.14.1-1~ubuntu18.04.1 => 1.14.4-1~ubuntu18.04.1] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: gstreamer1.0 (bionic-proposed/main) [1.14.1-1~ubuntu18.04.2 => 1.14.4-1~ubuntu18.04.1] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-good1.0 (bionic-proposed/main) [1.14.1-1ubuntu1~ubuntu18.04.1 => 1.14.4-1ubuntu1~ubuntu18.04.1] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: gstreamer-editing-services1.0 (bionic-proposed/universe) [1.14.1-1~ubuntu18.04.1 => 1.14.4-1~ubuntu18.04.1] (ubuntustudio) (sync)
<ddstreet> rbalint did you see that your systemd kbd patch may have caused a regression upstream?
<ddstreet> https://github.com/systemd/systemd/pull/12378#issuecomment-493776598
<gitbot> systemd issue (Pull request) 12378 in systemd "VT kbd reset check" [Login, Reviewed/Needs-Rework ð¨, Util-Lib, Vconsole, Closed]
<ddstreet> maybe the systemd uploads for c/d should be delayed until that's figured out?
<rbalint> RAOF, bdmurray please reject my systemd sru uploads
<rbalint> ddstreet, ^
<rbalint> at least they need Breaks: if the regression needs to be fixed in other packages
<xnox> apw:  linux -15.16 to eoan-release. not sure when you want to copy up -16.17 from disco-proposed, to eoan-proposed.
<apw> xnox, will look
<marcustomlinson> hi bdmurray, if you have any free cycles to today, please could you have a look at my libreoffice SRUs for xenial and bionic?
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1014.16] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-edge [amd64] (bionic-proposed) [4.18.0-1012.13~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1014.16]
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1014.16~16.04.1] (kernel)
<vorlon> Laney: yeah, I raised an mp to do that, and tagged you for review https://code.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/367610
<Laney> thx
-queuebot:#ubuntu-release- Unapproved: poppler (disco-proposed/main) [0.74.0-0ubuntu1 => 0.74.0-0ubuntu1.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1014.16~16.04.1]
<bdmurray> rbalint: Instead of modifying the title of bug 520546 editing the tags would be better as that is what the pending-sru report uses.
<ubot5> bug 520546 in linux (Ubuntu Disco) "[Don't release SRU yet]Alt+KEY incorrectly behaves like Ctrl+Alt+KEY, and/or unwanted VT switch from Alt+Left/Right" [High,Confirmed] https://launchpad.net/bugs/520546
-queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (disco-proposed) [240-6ubuntu5.1]
<rbalint> bdmurray, well, yeah i see you set verification failed, but it is not entirely accurate either because the verification itself passed and i was thinking about setting block-proposed instead
-queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (cosmic-proposed) [239-7ubuntu10.14]
<bdmurray> rbalint: the sru-report isn't aware of block-proposed afaik
<rbalint> ok
<infinity> bdmurray: Given that block-proposed is ~7 years old, maybe it should learn.  Seems like a natural fit for this sort of thing.
<infinity> (and would be even more natural in that magical future where britney actually does the migrations)
-queuebot:#ubuntu-release- Unapproved: base-files (xenial-proposed/main) [9.4ubuntu4.8 => 9.4ubuntu4.9] (core)
<xnox> the magical future would also probably need to teach britney about block-series-proposed
-queuebot:#ubuntu-release- Unapproved: gnome-shell (bionic-proposed/main) [3.28.3+git20190124-0ubuntu18.04.2 => 3.28.4-0ubuntu18.04.1] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.3+git20190124-0ubuntu18.04.2 => 3.28.4-0ubuntu18.04.1] (desktop-extra, ubuntu-desktop)
<Laney> those two supersede uploads in the queue already, might want to reject them
-queuebot:#ubuntu-release- Unapproved: rejected mutter [source] (bionic-proposed) [3.28.3+git20190124-0ubuntu18.04.3]
-queuebot:#ubuntu-release- Unapproved: rejected gnome-shell [source] (bionic-proposed) [3.28.3+git20190124-0ubuntu18.04.3]
-queuebot:#ubuntu-release- New binary: dnlib [amd64] (eoan-proposed/none) [2.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hcxdumptool [i386] (eoan-proposed/none) [5.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbigwig [i386] (eoan-proposed/none) [0.4.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hcxdumptool [amd64] (eoan-proposed/none) [5.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbigwig [amd64] (eoan-proposed/none) [0.4.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: einsteinpy [amd64] (eoan-proposed/none) [0.1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbigwig [arm64] (eoan-proposed/none) [0.4.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: piperka-client [i386] (eoan-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rttr [i386] (eoan-proposed/none) [0.9.6+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lablie [amd64] (eoan-proposed/none) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: plf-colony [amd64] (eoan-proposed/none) [5.06-1] (no packageset)
-queuebot:#ubuntu-release- New binary: piperka-client [amd64] (eoan-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hcxdumptool [armhf] (eoan-proposed/none) [5.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbigwig [armhf] (eoan-proposed/none) [0.4.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rttr [amd64] (eoan-proposed/none) [0.9.6+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hcxdumptool [s390x] (eoan-proposed/none) [5.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbigwig [s390x] (eoan-proposed/none) [0.4.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hcxdumptool [arm64] (eoan-proposed/none) [5.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: piperka-client [armhf] (eoan-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rttr [s390x] (eoan-proposed/none) [0.9.6+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: piperka-client [arm64] (eoan-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: piperka-client [s390x] (eoan-proposed/none) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: byteman [amd64] (eoan-proposed/none) [4.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rttr [armhf] (eoan-proposed/none) [0.9.6+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rttr [arm64] (eoan-proposed/none) [0.9.6+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-desktop-icons [source] (disco-proposed) [19.01.3-1~ubuntu19.04.1]
-queuebot:#ubuntu-release- New binary: hcxdumptool [ppc64el] (eoan-proposed/universe) [5.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbigwig [ppc64el] (eoan-proposed/universe) [0.4.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: piperka-client [ppc64el] (eoan-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rttr [ppc64el] (eoan-proposed/universe) [0.9.6+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted openvpn [source] (disco-proposed) [2.4.6-1ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (disco-proposed) [5.0.0-1ubuntu2.2]
<bdmurray> juliank: can you add SRU information to bug 1827697?
<ubot5> bug 1827697 in dkms (Ubuntu Disco) "Enroll key whiptail prompt blocks kernel header package upgrades" [High,In progress] https://launchpad.net/bugs/1827697
<coreycb> bdmurray: RAOF: hello, if you have a chance i'd like to see if we can get a review of octavia in the disco unapproved queue and neutron-fwaas-dashboard in the cosmic unapproved queue.
<bdmurray> coreycb: I can do that next
<coreycb> thanks bdmurray
-queuebot:#ubuntu-release- Unapproved: accepted poppler [source] (disco-proposed) [0.74.0-0ubuntu1.1]
<juliank> bdmurray: gotta figure out what to test first :/
<juliank> Will look at that tommorow
-queuebot:#ubuntu-release- Unapproved: accepted octavia [source] (disco-proposed) [4.0.0-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas-dashboard [source] (cosmic-proposed) [1.5.0-0ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-controls [source] (disco-proposed) [1.7.1]
-queuebot:#ubuntu-release- Unapproved: accepted deepin-qt5dxcb-plugin [source] (disco-proposed) [1.1.22-1ubuntu1.1]
<bdmurray> cpaelzer: What does "Note: open-vm-tools-desktop is in universe and must be in main." in bug 1819207 really mean?
<ubot5> bug 1819207 in ubuntu-drivers-common (Ubuntu Disco) "[FFe] Add Modaliases to open-vm-tools-desktop to allow automatic installation by ubuntu-drivers" [High,Fix released] https://launchpad.net/bugs/1819207
-queuebot:#ubuntu-release- Unapproved: accepted gvfs [source] (cosmic-proposed) [1.38.1-0ubuntu1.3.1]
-queuebot:#ubuntu-release- Unapproved: accepted gvfs [source] (bionic-proposed) [1.36.1-0ubuntu1.3.2]
-queuebot:#ubuntu-release- Unapproved: accepted python-glance-store [source] (cosmic-proposed) [0.26.1-0ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (cosmic-proposed) [1.7.5]
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (bionic-proposed) [1.6.11]
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (xenial-proposed) [1.2.32]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (disco-proposed/main) [2.578.2 => 2.578.3] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.24 => 2.525.25] (desktop-core)
-queuebot:#ubuntu-release- New binary: piperka-client [amd64] (eoan-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: piperka-client [i386] (eoan-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: piperka-client [arm64] (eoan-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: piperka-client [armhf] (eoan-proposed/universe) [0.2.2-1] (no packageset)
#ubuntu-release 2019-05-22
-queuebot:#ubuntu-release- Unapproved: runc (xenial-proposed/universe) [1.0.0~rc7+git20190403.029124da-0ubuntu1~16.04.1 => 1.0.0~rc7+git20190403.029124da-0ubuntu1~16.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.46 => 2.408.47] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (cosmic-proposed/main) [2.542.3 => 2.542.4] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted runc [source] (xenial-proposed) [1.0.0~rc7+git20190403.029124da-0ubuntu1~16.04.2]
-queuebot:#ubuntu-release- Unapproved: runc (xenial-proposed/universe) [1.0.0~rc7+git20190403.029124da-0ubuntu1~16.04.2 => 1.0.0~rc7+git20190403.029124da-0ubuntu1~16.04.3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected runc [source] (xenial-proposed) [1.0.0~rc7+git20190403.029124da-0ubuntu1~16.04.3]
-queuebot:#ubuntu-release- New: accepted piperka-client [amd64] (eoan-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted piperka-client [armhf] (eoan-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted piperka-client [arm64] (eoan-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted byteman [amd64] (eoan-proposed) [4.0.5-1]
-queuebot:#ubuntu-release- New: accepted libbigwig [ppc64el] (eoan-proposed) [0.4.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted piperka-client [armhf] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted piperka-client [i386] (eoan-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted rttr [armhf] (eoan-proposed) [0.9.6+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted rttr [s390x] (eoan-proposed) [0.9.6+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted hcxdumptool [ppc64el] (eoan-proposed) [5.1.4-1]
-queuebot:#ubuntu-release- New: accepted piperka-client [ppc64el] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rttr [ppc64el] (eoan-proposed) [0.9.6+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted piperka-client [arm64] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rttr [arm64] (eoan-proposed) [0.9.6+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted hcxdumptool [arm64] (eoan-proposed) [5.1.4-1]
-queuebot:#ubuntu-release- New: accepted hcxdumptool [s390x] (eoan-proposed) [5.1.4-1]
-queuebot:#ubuntu-release- New: accepted libbigwig [armhf] (eoan-proposed) [0.4.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted piperka-client [i386] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rttr [amd64] (eoan-proposed) [0.9.6+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted hcxdumptool [armhf] (eoan-proposed) [5.1.4-1]
-queuebot:#ubuntu-release- New: accepted libbigwig [s390x] (eoan-proposed) [0.4.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted rttr [i386] (eoan-proposed) [0.9.6+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted libbigwig [arm64] (eoan-proposed) [0.4.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted piperka-client [s390x] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted dnlib [amd64] (eoan-proposed) [2.1-2]
-queuebot:#ubuntu-release- New: accepted hcxdumptool [amd64] (eoan-proposed) [5.1.4-1]
-queuebot:#ubuntu-release- New: accepted lablie [amd64] (eoan-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted libbigwig [i386] (eoan-proposed) [0.4.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted plf-colony [amd64] (eoan-proposed) [5.06-1]
-queuebot:#ubuntu-release- New: accepted einsteinpy [amd64] (eoan-proposed) [0.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libbigwig [amd64] (eoan-proposed) [0.4.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted hcxdumptool [i386] (eoan-proposed) [5.1.4-1]
-queuebot:#ubuntu-release- New: accepted piperka-client [amd64] (eoan-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rustc [amd64] (eoan-proposed) [1.34.1+dfsg2+llvm-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [armhf] (eoan-proposed) [1.34.1+dfsg2+llvm-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [ppc64el] (eoan-proposed) [1.34.1+dfsg2+llvm-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [arm64] (eoan-proposed) [1.34.1+dfsg2+llvm-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [s390x] (eoan-proposed) [1.34.1+dfsg2+llvm-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [i386] (eoan-proposed) [1.34.1+dfsg2+llvm-0ubuntu1]
<cpaelzer> bdmurray: at the time the binary package was in universe (up to and including cosmic)
<cpaelzer> bdmurray: the src package already had the MIR processed
<cpaelzer> bdmurray: and as part of making it onto the desktop CD for said bug it had to be promoted
<cpaelzer> but all that already happened afaik
-queuebot:#ubuntu-release- Unapproved: fwupd (xenial-proposed/main) [0.8.3-0ubuntu4 => 0.8.3-0ubuntu5] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: runc (xenial-proposed/universe) [1.0.0~rc7+git20190403.029124da-0ubuntu1~16.04.2 => 1.0.0~rc7+git20190403.029124da-0ubuntu1~16.04.3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ibus-libpinyin (disco-proposed/main) [1.11.0-1 => 1.11.0-1ubuntu0.19.04] (input-methods, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted runc [source] (xenial-proposed) [1.0.0~rc7+git20190403.029124da-0ubuntu1~16.04.3]
<bdmurray> cpaelzer: afaict open-vm-tools-desktop is in universe for bionic and cosmic
<bdmurray> sil2100: Could you look at releasing ubuntu-release-upgrader from -proposed?
<sil2100> bdmurray: can I offer a trade? Since I was looking for someone to release my ubuntu-image SRUs ;)
<sil2100> bdmurray: anyway, looking!
<sil2100> bdmurray: the bionic one seems to be one day too early aging-wise - but let me see if maybe the changes can be released earlier
<bdmurray> sil2100: I don't think the bionic one really "needs" early releasing but if you feel like it I won't complain.
<Laney> sil2100: getting close to merging the SRU ADT stuff
<Laney> I'm making some changes directly and will squash your commits into one, is that ok?
<bdmurray> \o/
<Laney> that'll be in dry-run mode for some time initially to make sure it will behave ok
<Laney> unrelated: why is component-mismatches repeatedly spamming about python 2 stuff?
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1033.35] (no packageset)
<sil2100> Laney: sure, thanks!
<sil2100> Yeah, let's set it as dry-run for now
<sil2100> Since there was only a limited number of testing I could have performed
<sil2100> bdmurray: ACK
<Laney> |o/
-queuebot:#ubuntu-release- New binary: dmarc-cat [amd64] (eoan-proposed/universe) [0.9.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dmarc-cat [s390x] (eoan-proposed/universe) [0.9.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dmarc-cat [ppc64el] (eoan-proposed/universe) [0.9.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dmarc-cat [i386] (eoan-proposed/universe) [0.9.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dmarc-cat [arm64] (eoan-proposed/universe) [0.9.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dmarc-cat [armhf] (eoan-proposed/universe) [0.9.2-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted dmarc-cat [amd64] (eoan-proposed) [0.9.2-2]
-queuebot:#ubuntu-release- New: accepted dmarc-cat [armhf] (eoan-proposed) [0.9.2-2]
-queuebot:#ubuntu-release- New: accepted dmarc-cat [ppc64el] (eoan-proposed) [0.9.2-2]
-queuebot:#ubuntu-release- New: accepted dmarc-cat [arm64] (eoan-proposed) [0.9.2-2]
-queuebot:#ubuntu-release- New: accepted dmarc-cat [s390x] (eoan-proposed) [0.9.2-2]
-queuebot:#ubuntu-release- New: accepted dmarc-cat [i386] (eoan-proposed) [0.9.2-2]
-queuebot:#ubuntu-release- Unapproved: blktrace (bionic-proposed/universe) [1.1.0-2+deb9u1build0.18.04.1 => 1.1.0-2+deb9u1ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: blktrace (xenial-proposed/universe) [1.1.0-2+deb9u1build0.16.04.1 => 1.1.0-2+deb9u1ubuntu0.16.04.1] (no packageset)
<Laney> sil2100: thinking about not doing the save_progress() call in dry-run mode, what do you think?
<Laney> might slow down runs too much
<Laney> OK let's leave that on - we can clear the state files out if we want to re-test from scratch for whatever reason.
<sil2100> Laney: yeah, it's all experimental code, so best if we can check how it's working with all the features
<Laney> sil2100: last question, what's the 'britney' parameter to restore_state() for?
<Laney> as far as I can see this is never called with anything other than the default value, and it just means the log message won't be written
<sil2100> Oh, uh, I think I had a plan for that once
<sil2100> But not anymore, ugh
<Laney> can just delete that
<Laney> if I'm not missing something :P
<sil2100> I guess we can remove it and just leave the logging there
<sil2100> ;p
<sil2100> Sorry about that
<Laney> np, that's what review is for
<Laney> ok, let's go
<sil2100> If it just dies and crashes in production, not my fault!
<Laney> teehee
<Laney> it is DONE
<sil2100> Laney: should we wait with putting this in production until tomorrow?
<sil2100> Since I guess it's close to EOD for you as well
<Laney> nah I'm watching it
<sil2100> Ok \o/
<Laney> well it should default to 'no', I'll just make sure it doesn't break completely like a syntax error
<Laney> will do the dry-run thing tomorrow indeed
-queuebot:#ubuntu-release- New binary: r-cran-ggrepel [s390x] (eoan-proposed/none) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: telegram-purple [arm64] (eoan-proposed/universe) [1.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: telegram-purple [armhf] (eoan-proposed/universe) [1.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ggrepel [armhf] (eoan-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ggrepel [arm64] (eoan-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ggrepel [amd64] (eoan-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ggrepel [i386] (eoan-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-inherited-resources [amd64] (eoan-proposed/universe) [1.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ggrepel [ppc64el] (eoan-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: telegram-purple [i386] (eoan-proposed/universe) [1.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-paper-trail [amd64] (eoan-proposed/universe) [10.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: telegram-purple [amd64] (eoan-proposed/universe) [1.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: telegram-purple [ppc64el] (eoan-proposed/universe) [1.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted r-cran-ggrepel [amd64] (eoan-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ggrepel [armhf] (eoan-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ggrepel [ppc64el] (eoan-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ggrepel [arm64] (eoan-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ggrepel [s390x] (eoan-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ggrepel [i386] (eoan-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-inherited-resources [amd64] (eoan-proposed) [1.9.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-paper-trail [amd64] (eoan-proposed) [10.3.0-1]
-queuebot:#ubuntu-release- New: accepted telegram-purple [amd64] (eoan-proposed) [1.4.1-1]
-queuebot:#ubuntu-release- New: accepted telegram-purple [armhf] (eoan-proposed) [1.4.1-1]
-queuebot:#ubuntu-release- New: accepted telegram-purple [ppc64el] (eoan-proposed) [1.4.1-1]
-queuebot:#ubuntu-release- New: accepted telegram-purple [arm64] (eoan-proposed) [1.4.1-1]
-queuebot:#ubuntu-release- New: accepted telegram-purple [i386] (eoan-proposed) [1.4.1-1]
<cpaelzer> bdmurray: yes open-vm-tools-desktop is in universe for bionic and cosmic, but not in disco and later
<cpaelzer> bdmurray: the bug you had linked had no SRU associated
<cpaelzer> the change was made in the desktop-installer or seeds and only for later releases
<bdmurray> cpaelzer: its in Launchpad-Bugs-Fixed for the cosmic upload of open-vm-tools in the unapproved queue
<bdmurray> cpaelzer: it being bug 1819207
<ubot5> bug 1819207 in ubuntu-drivers-common (Ubuntu Disco) "[FFe] Add Modaliases to open-vm-tools-desktop to allow automatic installation by ubuntu-drivers" [High,Fix released] https://launchpad.net/bugs/1819207
<cpaelzer> bdmurray: now I see
<cpaelzer> bdmurray: thanks, let me explan
<cpaelzer> bdmurray: there was one part of the work in open-vm-tools (the modalias)
<cpaelzer> that is part of the regular backports
<cpaelzer> but that doesn't make it need to be in main
<cpaelzer> and there was a second change in the desktop installer which based on that modalias can now detect and install it
<cpaelzer> to do so it needed to go on their install image
<cpaelzer> but that change in the installer is only >=Disco
<cpaelzer> in open-vm-tools just the change to provide a modalias is part of the regular MRE backport
<bdmurray> cpaelzer: So why is the "Note: ..." in the bug description? Is just leftover from the Disco work?
<cpaelzer> yes
<cpaelzer> sorry
<cpaelzer> I can clean it up if it helps
<cpaelzer> now that I know how this was triggered I know what to modify
<bdmurray> cpaelzer: I think it would help as I may not get back to the SRU today.
<cpaelzer> ok
<cpaelzer> bdmurray: done
<cpaelzer> bdmurray: thanks for helping to clarify this
<rcj> Hey all, can I get someone to review livecd-rootfs in the upload queues for cosmic, bionic, and xenial?
<rcj> bug #1829938 ^
<ubot5> bug 1829938 in livecd-rootfs (Ubuntu) "[SRU] Support parallel builds for the ubuntu-cpc project" [Undecided,New] https://launchpad.net/bugs/1829938
#ubuntu-release 2019-05-23
<rcj> infinity, bdmurray? ^
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (cosmic-proposed) [2.542.4]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.25]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.47]
<marcustomlinson> hi sil2100, if you have any free cycles to today, please could you have a look at my libreoffice SRUs for xenial and bionic?
<sil2100> marcustomlinson: hey! Sure thing
<marcustomlinson> sil2100: thanks!
-queuebot:#ubuntu-release- Unapproved: gcc-9 (disco-proposed/main) [9-20190402-1ubuntu1 => 9.1.0-2ubuntu2~19.04] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-9-cross (disco-proposed/main) [4ubuntu4 => 4ubuntu4.1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-9-cross-ports (disco-proposed/universe) [3ubuntu4 => 3ubuntu4.1] (no packageset) (sync)
<mwhudson> sil2100: could you also look at releasing containerd/docker.io/runc for bionic and cosmic? :)
<sil2100> mwhudson: doing it just now
<sil2100> docker.io got copied, but then I'm getting timeouts all the time ;/ So will take a moment
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [source] (cosmic-proposed) [2.6.0-0ubuntu7.3]
 * Laney forgot about the proposed-migration config mangling that happens in b1
<Laney> was getting angry that my changes kept being reverted
<sil2100> Laney: as for the SRU regression messaging, thinking about it now I might want to add one thing before we switch it from dry-run to a normal one
<sil2100> Laney: since I guess we want to only do this for stable series
<sil2100> I'll prep something for that today
<Laney> sil2100: you mean to the text?
<Laney> https://people.canonical.com/~ubuntu-archive/proposed-migration/log/bionic/2019-05-23/09:14:21.log btw ;-)
<Laney> (hopefully fixed)
<sil2100> Laney: I mean not commenting on bugs from the current development release, since that makes no sense there
<sil2100> Ouchie
<Laney> sil2100: oh yeah, that's handled in britney1, just turning the config on for the right releases only
<Laney> like we do for the email policy already
<Laney> sil2100: ok https://people.canonical.com/~ubuntu-archive/proposed-migration/log/disco/2019-05-23/09:52:22.log
<Laney> now why didn't it try to send for libseccomp?
<sil2100> Laney: let me try investigating that - most important thing is that it's not exploding anymore ;p
<sil2100> Laney: I'll look at that so that you don't have to waste any time
<Laney> thanks â¥
<sil2100> Laney: thanks for shepherding it to production!
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [ppc64el] (bionic-proposed/main) [5.0.0-16.17~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [arm64] (bionic-proposed/main) [5.0.0-16.17~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (bionic-proposed/main) [5.0.0-16.17~18.04.1] (kernel)
<Laney> sil2100: the state file doesn't seem to be working either, it's emailing every run
<Laney> oh yes save_progress() bails out in that case
<Laney> hmm not sure about this .new logic on a second look; what's it trying to protect against?
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (bionic-proposed/universe) [20190315-0ubuntu1~18.04.0 => 20190521-0ubuntu1~18.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (disco-proposed/main) [20190315-0ubuntu1~19.04.0 => 20190521-0ubuntu1~19.04.0] (core, ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (cosmic-proposed/main) [20190315-0ubuntu1~18.10.0 => 20190521-0ubuntu1~18.10.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20190315-0ubuntu1~16.04.0 => 20190521-0ubuntu1~16.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New source: finalrd (bionic-proposed/primary) [3~ubuntu18.04.0]
<rbalint> xnox, ^ \o/
<rbalint> sil2100, could you please accept the gce-compute-image-packages packages?
<xnox> rbalint:  heh. thanks. but like NEW queue in stable releases is typically ignored, so i expect for like bionic to go EOESM before it gets accepted.
<rbalint> xnox, it is quite important to fix shutdown i can't believe it won't be accepted quickly
<sil2100> rbalint: I'll try
<sil2100> marcustomlinson: regarding libreoffice - for bionic I don't see libreoffice-l10n, is it not needed?
<marcustomlinson> sil2100: not needed no
<sil2100> marcustomlinson: ACK
<sil2100> Laney: yeah, I see some more unneeded leftover code I need to prune ;/ Will push fixes after my SRU shift
<Laney> sil2100: ok :-)
<Laney> I've stopped looking at it anyway so I'll not be pointing anything else out right now
<Laney> :P
-queuebot:#ubuntu-release- Unapproved: gst-plugins-good1.0 (bionic-security/main) [1.14.1-1ubuntu1~ubuntu18.04.1 => 1.14.0-1ubuntu1] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-good1.0 [sync] (bionic-security) [1.14.0-1ubuntu1]
<Laney> what
<sil2100> Laney: shhh, you didn't see anything o/
<sil2100> Laney: but seriously, I had to promote one of it's binaries to main, but we only had gst-plugins-good1.0 in bionic release and -updates
<sil2100> Laney: didn't want to cause a mismatch for only promoting the one in -updates, so I bin-copied release to security and promoted the binary in both pockets to main
<sil2100> (since the release pocket is immutable)
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (bionic-proposed) [1:6.0.7-0ubuntu0.18.04.6]
<Laney> for that libreoffice upload right?
<sil2100> Yeah
<sil2100> The source is already in main, but the needed binary was not
<Laney> I guess if that SRU is heading for -security it makes sense
<sil2100> Laney: it's not going there actually, but my thinking here is: if I only promoted the -updates one and security would want to release a libreoffice security update, we might forget that the binary is not in main for -security and get a mismatch then
<sil2100> So I preferred to promote in all the pockets, since sooner or later a new libreoffice in -security might appear
<sil2100> Possibly unneeded, but oh well
<Laney> ðº
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (xenial-proposed) [1:5.1.6~rc2-0ubuntu1~xenial7]
<Laney> sil2100: I can understand the reasoning actually, since the tooling there isn't very good it'd be easy to miss next time
<marcustomlinson> sil2100: thank you!
<Eickmeyer> xnox: I'm working on figuring out how we differ from xubuntu in regards to bug 1830201. Can you shed some light on this?
<ubot5> bug 1830201 in ubuntustudio-meta (Ubuntu) "ubiquity-frontend-gtk and ubiquity-frontend-gtk-panel split" [Undecided,New] https://launchpad.net/bugs/1830201
<Eickmeyer> We = Ubuntu Studio
<xnox> Eickmeyer:  well, maybe you don't. the code that was done in ubiquity is this one:
<xnox> Eickmeyer:  https://git.launchpad.net/ubiquity/commit/?id=40ed9a796bc4c06d4409944d4b22766dc2d4790b
<Eickmeyer> xnox: I've been inspecting our default panel layouts and have discovered some differences, but I don't know if it's related.
<xnox> Eickmeyer:  so that bit says, that during maybe-ubiquity or only-ubiquity do not launch panel app if
<xnox> xfwm4 is the wm_cmd
<xnox> and studio i guess uese xfwm4 for ubuntu-dm
<xnox> and thus i guess you don't use panel app
<xnox> subsequently that panel is empty if there are no indicators available.
<xnox> which xubuntu unseeded.
<Eickmeyer> Correct. We use Xfce as the desktop, therefore this shouldn't apply to us at all. We're more closely related to Xubuntu in this respect.
<xnox> they still seed something-something-app-indicator such that any weird 3rd party things can publish into panel, just nothing by default in neither live or ubiquity-dm
<Eickmeyer> Studio has used Xfce since 12.04.
<xnox> ack
<xnox> so i guess studio is out, but let me check seeds, one sec.
<Eickmeyer> k
<xnox> $ grep indicator */* 2>/dev/null | grep -e xubuntu -e studio
<xnox> ubuntustudio/desktop: * (indicator-messages)
<xnox> ubuntustudio/desktop-core: * (xfce4-indicator-plugin)
<xnox> ubuntustudio/desktop-core: * (indicator-application)
<xnox> ubuntustudio/desktop-core: * (indicator-sound)
<xnox> xubuntu/core: * (xfce4-indicator-plugin)
<xnox> xubuntu/desktop: * (indicator-messages)
<xnox> so slight difference of studio recommending -mesages and -sound which xubuntu i guess dropped
<xnox> Eickmeyer:  maybe you want to trace that, and see if you'd like to also drop that.
<xnox> Eickmeyer:  but at least there is no action on your part needed for the panel seed then.
<Eickmeyer> xnox: ack. I'll invalidate the bug for us, and we just decided that it's best to work on this now rather than during the 20.04 cycle irt -application and -sound.
<xnox> sorry -sound & -application
<xnox> cool!
<Eickmeyer> Thanks!
<xnox> Eickmeyer:  note canonical no longer uses, nor maintains indicator-* stack. It would be nice to remove them from the archive, but we can't as it's still seeded in flavours.
<Eickmeyer> xnox: ack, as soon as we get the panel layout synced with Xubuntu we can likely drop the indicator-* stack.
-queuebot:#ubuntu-release- New binary: monero [amd64] (eoan-proposed/universe) [0.14.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1033.35]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [arm64] (bionic-proposed) [5.0.0-16.17~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (bionic-proposed) [5.0.0-16.17~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [ppc64el] (bionic-proposed) [5.0.0-16.17~18.04.1]
-queuebot:#ubuntu-release- New binary: monero [i386] (eoan-proposed/universe) [0.14.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [s390x] (eoan-proposed/universe) [3.4.8+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [i386] (eoan-proposed/universe) [3.4.8+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [ppc64el] (eoan-proposed/universe) [3.4.8+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [amd64] (eoan-proposed/universe) [3.4.8+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: monero [armhf] (eoan-proposed/universe) [0.14.0.2-1] (no packageset)
<rcj> Can I get an SRU member to review livecd-rootfs in the upload queue for disco?
-queuebot:#ubuntu-release- New: accepted monero [armhf] (eoan-proposed) [0.14.0.2-1]
-queuebot:#ubuntu-release- New: accepted qgis [i386] (eoan-proposed) [3.4.8+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [amd64] (eoan-proposed) [3.4.8+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [ppc64el] (eoan-proposed) [3.4.8+dfsg-1]
-queuebot:#ubuntu-release- New: accepted monero [amd64] (eoan-proposed) [0.14.0.2-1]
-queuebot:#ubuntu-release- New: accepted qgis [s390x] (eoan-proposed) [3.4.8+dfsg-1]
-queuebot:#ubuntu-release- New: accepted monero [i386] (eoan-proposed) [0.14.0.2-1]
<vorlon> rcj: wasn't disco going to get another fix to magic-proxy?
<rcj> vorlon: Oh yeah, I thought it was in there.  Okay, so I need an upload of https://code.launchpad.net/~rcj/livecd-rootfs/+git/livecd-rootfs/+merge/367729
<rcj> drat
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (disco-proposed/main) [2.578.2 => 2.578.4] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (disco-proposed) [2.578.3]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (disco-proposed) [2.578.4]
-queuebot:#ubuntu-release- New binary: ubiquity [i386] (eoan-proposed/main) [19.10.2] (core)
-queuebot:#ubuntu-release- New binary: ubiquity [amd64] (eoan-proposed/main) [19.10.2] (core)
-queuebot:#ubuntu-release- New binary: ubiquity [ppc64el] (eoan-proposed/main) [19.10.2] (core)
-queuebot:#ubuntu-release- New binary: ubiquity [arm64] (eoan-proposed/main) [19.10.2] (core)
-queuebot:#ubuntu-release- New binary: ubiquity [armhf] (eoan-proposed/main) [19.10.2] (core)
<rcj> vorlon: Thank you
<vorlon> rcj: n/p
#ubuntu-release 2019-05-24
-queuebot:#ubuntu-release- New: rejected dmarc-cat [amd64] (eoan-proposed) [0.9.2-1ubuntu1]
-queuebot:#ubuntu-release- New: rejected dmarc-cat [armhf] (eoan-proposed) [0.9.2-1ubuntu1]
-queuebot:#ubuntu-release- New: rejected dmarc-cat [ppc64el] (eoan-proposed) [0.9.2-1ubuntu1]
-queuebot:#ubuntu-release- New: rejected dmarc-cat [arm64] (eoan-proposed) [0.9.2-1ubuntu1]
-queuebot:#ubuntu-release- New: rejected dmarc-cat [s390x] (eoan-proposed) [0.9.2-1ubuntu1]
-queuebot:#ubuntu-release- New: rejected dmarc-cat [i386] (eoan-proposed) [0.9.2-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted hy [source] (eoan-proposed) [0.16.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ubiquity [amd64] (eoan-proposed) [19.10.2]
-queuebot:#ubuntu-release- New: accepted ubiquity [armhf] (eoan-proposed) [19.10.2]
-queuebot:#ubuntu-release- New: accepted ubiquity [ppc64el] (eoan-proposed) [19.10.2]
-queuebot:#ubuntu-release- New: accepted ubiquity [arm64] (eoan-proposed) [19.10.2]
-queuebot:#ubuntu-release- New: accepted ubiquity [i386] (eoan-proposed) [19.10.2]
-queuebot:#ubuntu-release- New binary: r-cran-webgestaltr [ppc64el] (eoan-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-webgestaltr [s390x] (eoan-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-webgestaltr [amd64] (eoan-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-webgestaltr [i386] (eoan-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-webgestaltr [arm64] (eoan-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-webgestaltr [armhf] (eoan-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-9 [sync] (disco-proposed) [9.1.0-2ubuntu2~19.04]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-9-cross [sync] (disco-proposed) [4ubuntu4.1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-9-cross-ports [sync] (disco-proposed) [3ubuntu4.1]
-queuebot:#ubuntu-release- Unapproved: yaru-theme (disco-proposed/main) [19.04.2 => 19.04.3] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted yaru-theme [source] (disco-proposed) [19.04.3]
<LocutusOfBorg> any AA can please remove hy 0.16.0-0ubuntu1 from eoan-proposed? I want to do some testing with the old version before updating... never built
<LocutusOfBorg> I don't know why but today the old version seems building
-queuebot:#ubuntu-release- Unapproved: update-notifier (bionic-proposed/main) [3.192.1.6 => 3.192.1.7] (ubuntu-desktop, ubuntu-server)
<tjaalton> vorlon: do you want to handle fwupd* et al on bionic queue/NEW? fwupd is still on unapproved for some reason, while libxmlb and fwupd-signed are already on NEW..
<seb128> tjaalton, there is no "some reason/while" here, those 2 are packages that don't exist today in bionic so  uploading them hit sourceNEW and not unapproved
<tjaalton> seb128: oh, source NEW?
<tjaalton> even more reason for an AA to review them in tandem
<seb128> tjaalton, yes, the first one is a new library that is needed by the new fwupd version
<seb128> right
<seb128> I don't expect that to be an easy SRU, maybe best for vorlon to review :)
<tjaalton> right, I'll do the easier ones then :)
<LocutusOfBorg> apw, please kick hy out from eoan...
<LocutusOfBorg> I want to replace with a copy from cosmic
<LocutusOfBorg> and then do a no-change rebuild
<LocutusOfBorg> and fix failures with single patches on top of 0.12 because the new version requires lots of other library updates
<tjaalton> xnox: why is openssl targeted for 'disco-updates' instead of proposed? the sru tooling doesn't see the diff so it's harder to review
<Laney> worse than that, that means that when you accept it it'll go straight to -updates
<Laney> (AIUI)
<tjaalton> sigh
<Laney> reject it :>
<tjaalton> done
-queuebot:#ubuntu-release- Unapproved: rejected openssl [source] (disco-updates) [1.1.1b-1ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (disco-proposed) [2.6.1-4ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (cosmic-proposed) [2.3-3ubuntu11.1]
-queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (bionic-proposed) [2.3-3ubuntu9.3]
-queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (xenial-proposed) [2.2.0.3-2ubuntu11.7]
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (bionic-proposed) [3.192.1.7]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1007.7] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: rejected software-properties [source] (bionic-proposed) [0.96.24.32.9]
<sil2100> Laney: ok, I finally had a moment to sit down on the britney SRU regression thingy - fixed a few things regarding state record and read, but in besides that it seems to be working correctly
<sil2100> Laney: for instance yeah, it doesn't send a message for libseccomp for bionic because that upload has no launchpad bugs in its .changes
<sil2100> Laney: for bionic at least it seems that for all the others it did the 'right thing'
<Laney> sil2100: oh! thanks, I didn't consider that possibliity :-O
-queuebot:#ubuntu-release- Unapproved: software-properties (bionic-proposed/main) [0.96.24.32.8 => 0.96.24.32.9] (desktop-core, ubuntu-server)
<Laney> vorlon: Looks like bos02 randomly healed itself... going to turn it back on
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (bionic-proposed) [0.96.24.32.9]
<vorlon> Laney: heh ok
<Laney> such reliable
<LocutusOfBorg> any AA please remove hy from eoan, and let me copy the previous binary from cosmic
<LocutusOfBorg> vorlon, ^^ :D
<LocutusOfBorg> pleeeeeeease
<LocutusOfBorg> (rationale above)
<vorlon> mm
<LocutusOfBorg> the new release can't build...
<LocutusOfBorg> and the old one seems to build fine now
<LocutusOfBorg> I spent three days trying to make the new one work, but requires lots of more changes, in other python libs
<LocutusOfBorg> better stick with cosmic and cherry-pick fixes
<vorlon> removed
<LocutusOfBorg> or let debian do it :D
<LocutusOfBorg> <3
<vorlon> but why was it uploaded to eoan if it wasn't buildable?
<LocutusOfBorg> mistake, it was directed to ppa!
<LocutusOfBorg> I asked to not accept few times, and I gave up...
<LocutusOfBorg> anyway, ./copy-package --from=ubuntu --from-suite=cosmic hy --to=ubuntu --to-suite=eoan-proposed -b
<LocutusOfBorg> correct?
 * LocutusOfBorg tries and goes catching a train
-queuebot:#ubuntu-release- New sync: hy (eoan-proposed/primary) [0.12.1-2]
<vorlon> LocutusOfBorg: syntactically correct, but I'm not happy to accept a binary sync from cosmic to eoan of a package that was dropped in disco
-queuebot:#ubuntu-release- New: rejected hy [sync] (eoan-proposed) [0.12.1-2]
-queuebot:#ubuntu-release- New: accepted r-cran-webgestaltr [amd64] (eoan-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-webgestaltr [armhf] (eoan-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-webgestaltr [ppc64el] (eoan-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-webgestaltr [arm64] (eoan-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-webgestaltr [s390x] (eoan-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-webgestaltr [i386] (eoan-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1007.7]
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1039.44] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1039.44]
<LocutusOfBorg> ok, so better now?
<LocutusOfBorg> I or should I upload a build1 version?
-queuebot:#ubuntu-release- New sync: hy (eoan-proposed/primary) [0.12.1-2]
<LocutusOfBorg> I uploaded both :D
<vorlon> LocutusOfBorg: I don't mean that you should sync it from a different release, I mean that I'm not accepting a forward-sync of a package that was dropped in disco.  sourceful upload.
<vorlon> LocutusOfBorg: and I only see your sync, not your build1 upload
<vorlon> (I did write that in the reject comment before, which I guess you didn't see before re-syncing)
-queuebot:#ubuntu-release- New: rejected hy [sync] (eoan-proposed) [0.12.1-2]
<LocutusOfBorg> vorlon, I think I did it now, the build1 was "ENONET" interrupted
-queuebot:#ubuntu-release- New source: hy (eoan-proposed/primary) [0.12.1-2build1]
-queuebot:#ubuntu-release- New: accepted hy [source] (eoan-proposed) [0.12.1-2build1]
<LocutusOfBorg> and no, sorry I didn't receive the reject email, even now
-queuebot:#ubuntu-release- New binary: hy [amd64] (eoan-proposed/universe) [0.12.1-2build1] (no packageset)
<LocutusOfBorg> strange that it built without touching it... meh
<LocutusOfBorg> I suppose autopkgtests will be sad
<LocutusOfBorg> vorlon, please accept it? :)
<LocutusOfBorg> so I can start my weekend having fixed itk4  poppler elastix lintian hy and deken from proposed :D
<LocutusOfBorg> acorn is ongoing upstream work
-queuebot:#ubuntu-release- New: accepted hy [amd64] (eoan-proposed) [0.12.1-2build1]
<jdstrand> sil2100, Laney: note that the libseccomp is there for wider testing before the security team publishes a USN. it isn't a normal SRU
-queuebot:#ubuntu-release- New binary: deken [amd64] (eoan-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (bionic-proposed/universe) [1.0.0-0ubuntu4~18.04.0 => 1.0.0-0ubuntu4~18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (disco-proposed/universe) [1.0.0-0ubuntu4 => 1.0.0-0ubuntu4.19.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (cosmic-proposed/universe) [1.0.0-0ubuntu4~18.10.0 => 1.0.0-0ubuntu4~18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (xenial-proposed/universe) [1.0.0-0ubuntu4~16.04.0 => 1.0.0-0ubuntu4~16.04.1] (no packageset)
<rbalint> tjaalton, vorlon could you please accept those packages? ^
<rbalint> the diff is tiny :-)
<vorlon> rbalint: I don't understand why the test case involves a long-running process. is that to prove that the instance resumed, as opposed to something else (auto-killed by the hypervisor due to networking not coming up?)
<vorlon> haha I feel we should really take a closer look at the interaction between this hook, and the hook in lizardfs-chunkserver
<rbalint>  vorlon yes, just to prove that the instance is resumed
<vorlon> ok
<rbalint> i just use screen top
-queuebot:#ubuntu-release- Unapproved: accepted ec2-hibinit-agent [source] (disco-proposed) [1.0.0-0ubuntu4.19.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted ec2-hibinit-agent [source] (cosmic-proposed) [1.0.0-0ubuntu4~18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted ec2-hibinit-agent [source] (bionic-proposed) [1.0.0-0ubuntu4~18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected geary [source] (bionic-proposed) [0.12.4-4~ubuntu0.18.04.1]
#ubuntu-release 2019-05-25
-queuebot:#ubuntu-release- Unapproved: accepted lyx [source] (bionic-proposed) [2.2.4-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected gnupg2 [source] (bionic-proposed) [2.2.4-1ubuntu1.3]
-queuebot:#ubuntu-release- Unapproved: rejected gnupg2 [source] (cosmic-proposed) [2.2.8-3ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: rejected gnupg2 [source] (xenial-proposed) [2.1.11-6ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: accepted ruby2.5 [sync] (bionic-proposed) [2.5.1-1ubuntu1.4]
-queuebot:#ubuntu-release- Unapproved: rejected geocode-glib [source] (bionic-proposed) [3.25.4.1-4ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: geocode-glib (bionic-proposed/main) [3.25.4.1-4 => 3.25.4.1-4ubuntu0.18.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted geocode-glib [source] (bionic-proposed) [3.25.4.1-4ubuntu0.18.04.1]
#ubuntu-release 2020-05-18
<locutus__> so, protobuf+ignition*+sdformat+libdvdread... probably also caffe should be reverted
<locutus__> caffe 1.0.0+git20180821.99bd997-7 should be good then
<locutus__> vorlon, if you could NBS-proposed cleanup libschroedinger-coordgenlibs-dev, libschroedinger-coordgenlibs1
<locutus__> I'm preparing an rdkit sync/merge
<tumbleweed> vorlon: I think hdf5 is almost there
<tumbleweed> (well, at least build-wise. autopkgtests may be another story)
<locutus__> just entangling with.... everything
<tumbleweed> yeah :/
-queuebot:#ubuntu-release- Unapproved: simple-scan (focal-proposed/main) [3.36.0-0ubuntu1 => 3.36.2.1-0ubuntu0.20.04.0] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: notcurses [s390x] (groovy-proposed/universe) [1.4.2.3+dfsg.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: notcurses [amd64] (groovy-proposed/universe) [1.4.2.3+dfsg.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: notcurses [ppc64el] (groovy-proposed/universe) [1.4.2.3+dfsg.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: notcurses [arm64] (groovy-proposed/universe) [1.4.2.3+dfsg.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: wireguard-linux-compat (focal-proposed/universe) [1.0.20200413-1 => 1.0.20200506-1~20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: wireguard (focal-proposed/universe) [1.0.20200319-1ubuntu1 => 1.0.20200513-1~20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: wireguard-linux-compat (eoan-proposed/universe) [1.0.20200401-1ubuntu1~19.10.1 => 1.0.20200506-1~19.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: wireguard (eoan-proposed/universe) [1.0.20200319-1ubuntu1~19.10.1 => 1.0.20200513-1~19.10.1] (no packageset)
-queuebot:#ubuntu-release- New binary: notcurses [riscv64] (groovy-proposed/universe) [1.4.2.3+dfsg.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: open-iscsi (bionic-proposed/main) [2.0.874-5ubuntu2.9 => 2.0.874-5ubuntu2.10] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: open-iscsi (eoan-proposed/main) [2.0.874-7.1ubuntu3 => 2.0.874-7.1ubuntu3.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: open-iscsi (focal-proposed/main) [2.0.874-7.1ubuntu6 => 2.0.874-7.1ubuntu6.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected mesa [source] (bionic-proposed) [20.0.4-2ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: mesa (bionic-proposed/main) [19.2.8-0ubuntu0~18.04.3 => 20.0.4-2ubuntu1~18.04.1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: bbswitch (focal-proposed/universe) [0.8-8 => 0.8-8.0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [s390x] (groovy-proposed/universe) [1.42.0+dfsg1+llvm-1ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: rustc [ppc64el] (groovy-proposed/universe) [1.42.0+dfsg1+llvm-1ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- New binary: rustc [i386] (groovy-proposed/universe) [1.42.0+dfsg1+llvm-1ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted wireguard [source] (focal-proposed) [1.0.20200513-1~20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted wireguard-linux-compat [source] (focal-proposed) [1.0.20200506-1~20.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1037.38] (kernel)
<locutus__> vorlon, I stole your initramfs-tools merge sorry
<locutus__> please roollback caffe?
-queuebot:#ubuntu-release- Unapproved: accepted wireguard [source] (eoan-proposed) [1.0.20200513-1~19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted wireguard-linux-compat [source] (eoan-proposed) [1.0.20200506-1~19.10.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1037.38]
-queuebot:#ubuntu-release- New binary: rustc [amd64] (groovy-proposed/universe) [1.42.0+dfsg1+llvm-1ubuntu1] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: gamemode (focal-proposed/main) [1.5.1-0ubuntu3 => 1.5.1-0ubuntu3.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: thermald (focal-proposed/main) [1.9.1-1ubuntu0.1 => 1.9.1-1ubuntu0.2] (core)
-queuebot:#ubuntu-release- Unapproved: vala (focal-proposed/universe) [0.48.5-0ubuntu1 => 0.48.6-0ubuntu1] (i386-whitelist, ubuntu-desktop)
<vorlon> RikMills[m]: the sync of qtwebengine-opensource-src stomped on the in-progress protobuf,re2 transition; I'm rolling this back to let that transition complete.  When uploading packages that already have versions in -proposed, please coordinate
-queuebot:#ubuntu-release- Unapproved: pulseaudio (bionic-proposed/main) [1:11.1-1ubuntu7.7 => 1:11.1-1ubuntu7.8] (desktop-core, ubuntu-server)
<locutus_> vorlon, looks like (but -ENOBRITNEYEXPERT), britney is not able to make rdkit transition complete
<locutus_> Trying easy from autohinter: rdkit/201909.1-4ubuntu1 schroedinger-maeparser/1.2.3-3
<locutus_> Trying easy from autohinter: rdkit/201909.1-4ubuntu1 schroedinger-coordgenlibs/1.4.0-2
<locutus_> but there is not trying with them both
<RikMills> vorlon: oops. apologies
<vorlon> locutus_: well I just tried to reload update_output and now the server isn't responding to me; but the previous run did show an easy hint for all 3 packages
<vorlon> locutus_: appears openbabel needs a rebuild for libschroedinger-maeparser
<locutus_> I'm facing the same issues in reloading the page...
<locutus_> and please kick out caffe or rollback to 1.0.0+git20180821.99bd997-7 otherwise we get hdf entangled with protobuf
 * locutus_ grabs and merges openbabel
<vorlon> should a no-change rebuild not work? I'm just uploading that
<vorlon> hmm somehow my scripts said schroedinger-coordgenlibs also needed uploaded for libmaeparser1 :/
<vorlon> so I might have to nuke that
<locutus_> nope vorlon
<locutus_>    * Replacing libschroedinger-maeparser-dev with libmaeparser-dev.
<vorlon> ok
<locutus_> this is why we need the -4
<locutus_> you know, changing -dev package names is... funny!
<vorlon> yeah.
<locutus_> rmadison -u ubuntu libschroedinger-maeparser-dev
<locutus_> curl: (35) error:0407008A:rsa routines:RSA_padding_check_PKCS1_type_1:invalid padding
<locutus_> even more funny now
<vorlon> so I'm waiting until I can see with my own eyes what the entanglement is with caffe before kicking it out
<locutus_> you can replace with previous version
<locutus_> it was in proposed
<locutus_> no need to just kick it out
<locutus_> it can migrate with protobuf the -7 upload
<locutus_>     * amd64: caffe-cpu, caffe-tools-cpu, compiz, compiz-gnome, compiz-mate, cura, cytadela, cytadela-dbg, dnsdist, forensics-extra-gui, forensics-full, freetuxtv, gazebo, gazebo-plugin-base, gazebo9, gazebo9-plugin-base, hdhomerun-config-gui, kaffeine, libcaffe-cpu-dev, libcaffe-cpu1, libgazebo-dev, libgazebo11, libgazebo9-dev, libignition-fuel-tools-dev, libignition-fuel-tools1-dev, libignition-fuel-tools4-4,
<locutus_> phonon4qt5-backend-vlc, python3-caffe-cpu, ubuntu-unity-desktop, unity, unity-session, unity-tweak-tool, vlc, vlc-plugin-base
<locutus_> I don't see much stuff anymore, gazebo should disentangle, and other might just be because of the qt stuff
-queuebot:#ubuntu-release- New binary: rustc [arm64] (groovy-proposed/universe) [1.42.0+dfsg1+llvm-1ubuntu1] (i386-whitelist)
<tumbleweed> vorlon: pretty much as in the changelog: https://launchpad.net/ubuntu/+source/caffe/1.0.0+git20180821.99bd997-7build1 libcaffe1 gets a dep on libhdf5
-queuebot:#ubuntu-release- New binary: rustc [armhf] (groovy-proposed/universe) [1.42.0+dfsg1+llvm-1ubuntu1] (i386-whitelist)
<locutus_>     * amd64: caffe-cpu, caffe-tools-cpu, libcaffe-cpu-dev, libcaffe-cpu1, python3-caffe-cpu
<locutus_> vorlon, ^^ you now have your answer :)
<vorlon> locutus_, tumbleweed: ack, caffe rolled back, so hopefully that all transitions shortly
<tumbleweed> touch wood
 * locutus_ fingers crossed
<locutus_> its migrating!!!
-queuebot:#ubuntu-release- Unapproved: maas (focal-proposed/main) [1:0.6 => 1:0.7] (ubuntu-server)
<tumbleweed> vorlon: will you copy those rebuilds back into the archive again? or must they be re-uploaded?
<tumbleweed> now I can do the next re2 transition :P
<vorlon> tumbleweed: I'll copy them back to -proposed now
<vorlon> "next re2 transition" ugh
<tumbleweed> those are tiny, at least
<tumbleweed> C++ ,always transitioning...
<vorlon> copy-backs done
-queuebot:#ubuntu-release- Unapproved: pulseaudio (focal-proposed/main) [1:13.99.1-1ubuntu3.2 => 1:13.99.1-1ubuntu3.3] (desktop-core, i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (focal-proposed) [2:16.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted openstack-trove [source] (focal-proposed) [1:13.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Packageset: Added cloud-utils to ubuntu-cloud in bionic
-queuebot:#ubuntu-release- Packageset: Added cloud-utils to ubuntu-cloud in eoan
-queuebot:#ubuntu-release- Packageset: Added cloud-utils to ubuntu-cloud in focal
-queuebot:#ubuntu-release- Packageset: Added cloud-utils to ubuntu-cloud in groovy
-queuebot:#ubuntu-release- Packageset: Added cloud-utils to ubuntu-cloud in xenial
<Kamilion> well, just as heads up, mini.iso seems to be busted on xen.
<Kamilion> error: not xen image.
<Kamilion> alloc magic is broken at 0x7f7aec40: 7f234920
<Kamilion> Aborted. Press any key to exit.
<Kamilion> no biggie, but I figured i'd say something
<locutus_> Kamilion, it might be my inintramfs-tools upload...
<Kamilion> doubt that
<Kamilion> mini.iso was built on april 21st
<locutus_> vorlon can you please kick it out from proposed? I merged 0.137ubuntu1 and regressed lots, then I uploaded 0.137ubuntu2 that is the same as the one in release, still regressed. So, something behind initramfs but I don't get what
<locutus_> the merge was good to me
<Kamilion> and it's failing to boot under xen4.6
<vorlon> locutus_: removing
<vorlon> Kamilion: ok, and how does that compare to the 19.10 mini.iso?
<Kamilion> no idea, wouldn't touch a non-lts
<locutus_> vorlon, do you have any idea for the regression?
<locutus_> thanks for doing it
<Kamilion> I'll see if I can check eoan for the same issue later; but since mini.iso should be pining for the fjords, it's just a point of data
<Kamilion> trying to merge the pxe boot info on discourse with my existing ipxe deployments
-queuebot:#ubuntu-release- Unapproved: accepted murano-agent [source] (focal-proposed) [1:5.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected masakari [source] (focal-proposed) [9.0.0-0ubuntu0.20.04.1]
<vorlon> locutus_: what was the regression? I didn't see any details
-queuebot:#ubuntu-release- Unapproved: accepted masakari [source] (focal-proposed) [9.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted networking-mlnx [source] (focal-proposed) [1:15.0.2-0ubuntu0.20.04.1]
<Kamilion> *sigh* VFS panic mounting root, using the netboot parameters suggested at https://discourse.ubuntu.com/t/netbooting-the-live-server-installer/14510
<Kamilion> seems to choke on root=/dev/ram0 ramdisk_size=1500000
<Kamilion> https://photos.app.goo.gl/fp9GvJWVepRzP3kx5
-queuebot:#ubuntu-release- Unapproved: accepted networking-l2gw [source] (focal-proposed) [1:16.0.0~git2020051415.30f4209-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted placement [source] (focal-proposed) [3.0.0-0ubuntu0.20.04.1]
<Kamilion> oooooookay, apparently it just doesn't like uEFI PXE boot mode.
<vorlon> which doesn't?
-queuebot:#ubuntu-release- Unapproved: accepted networking-bagpipe [source] (focal-proposed) [12.0.0-0ubuntu0.20.04.1]
<Kamilion> focal release
<Kamilion> specifically, the stock lubuntu release image's kernel and initrd extracted
<Kamilion> booting with the CSM PXE module successfully initiated the .iso download
<vorlon> you're using the instructions on https://discourse.ubuntu.com/t/netbooting-the-live-server-installer/14510 for something which is not the live server installer?
<Kamilion> ... that only works for the live-server?
<Kamilion> not all the isos? >.M
<Kamilion> Eh, casper seems to have done the right thing with just ip=dhcp url=<link-to-iso>
<Kamilion> huh, did I tell it TORAM? ... No, it figured that out on it's own.
<Kamilion> ah, no, I did tell it explicitly
<Kamilion> yeah, sitting at the desktop right now; acting just as if I'd TORAM'd it from the USB, only much much slower
<Kamilion> oooh, it threw the iso loopback away on it's own once it yanked the squashfs out
-queuebot:#ubuntu-release- Unapproved: rejected zaqar [source] (focal-proposed) [10.0.0-0ubuntu0.20.04.2]
-queuebot:#ubuntu-release- Unapproved: zaqar (focal-proposed/universe) [10.0.0~b3~git2020041014.22c457a5-0ubuntu1 => 10.0.0-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted panko [source] (focal-proposed) [8.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted zaqar [source] (focal-proposed) [10.0.0-0ubuntu0.20.04.1]
#ubuntu-release 2020-05-19
-queuebot:#ubuntu-release- Unapproved: wireguard-linux-compat (eoan-proposed/universe) [1.0.20200506-1~19.10.1 => 1.0.20200506-1~19.10.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-os-ken [source] (focal-proposed) [1.0.0-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.service [source] (focal-proposed) [2.1.1-0ubuntu1.1]
<locutus_> vorlon, look e.g. http://autopkgtest.ubuntu.com/packages/b/bilibop/groovy/amd64
<locutus_> and people reporting "can't boot properly with -proposed enabled"
-queuebot:#ubuntu-release- Unapproved: wireguard-linux-compat (eoan-proposed/universe) [1.0.20200506-1~19.10.1 => 1.0.20200506-1~19.10.2] (no packageset)
<locutus_> and even after uploading the "ubuntu2" (that is bit-bit the same as the one in release), the autopkgtests still were bad
-queuebot:#ubuntu-release- Unapproved: rejected wireguard-linux-compat [source] (eoan-proposed) [1.0.20200506-1~19.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted wireguard-linux-compat [source] (eoan-proposed) [1.0.20200506-1~19.10.2]
<juliank> heads up that apt 2.1.3 seems to have broken dpkg --unpack/-i && apt-get install -f type scenarios, which breaks autopkgtest amongst other things
<juliank> So it won't make it out of proposed, as it can't satisfy its own test dependencies :D
<juliank> But still might cause some trouble with all-proposed runs, for example
<Laney> any reason to keep it in proposed?
<sil2100> Should I drop it from -proposed then?
<Laney> juliank: ^----
<Laney> sil2100: (imho yes)
<juliank> Laney: We can, yes
<juliank> sil2100: ^
<juliank> Now releasing 2.1.4
<juliank> so I could locally sync that and avoid extra work on your side
<juliank> but it's a bit of a meh situation I suppose
<sil2100> juliank: it's not a big deal, let me remove it then
<seb128> could someone from the SRU team review vala/focal? it's needed to fix bug #1878361 (we need the fixed vala then to rebuild the application)
<ubot5> bug 1878361 in gnome-clocks (Ubuntu) "After update in the gnome-clocks package, the sound of the timer and the alarm stopped working" [High,In progress] https://launchpad.net/bugs/1878361
<locutus_> hello vorlon do you think we can kick out from release scap-security-guide? its preventing python3-only pyyaml migration
<locutus_> its out from debian testing
<seb128> bdmurray, ^ if you could review the vala SRU later maybe?
<locutus_> do we still need mongodb? xnox ?
<locutus_> vorlon, regarding your hint on r-bioc-rhdf5/amd64, looks like the new r-cran-testthat (probably) started running tests, so they are not a real regression, just they were not run before
<locutus_> or the new pkg-r-autopkgtest probably
<locutus_> in any case, not a regression
<locutus_> this is something that introduced lots of regression in other r-* packages too, specially s390x, holding almost all the ongoing transitions
<xnox> locutus_:  we want to rip out src:mongodb, but we had a vague plan to upload src:mongodb-sspl into multiverse. But i'm not sure if that has happened yet. (and thus offer users some continiuty)
<xnox> locutus_:  but also i think we still had a few packages in universe that reference mongodb, and that should be dropped and/or demoted from Depends to something lower.
<xnox> Reverse-Build-Depends-Indep
<xnox> * aodh                          (for mongodb)
<xnox> * zaqar                         (for mongodb)
<xnox> i think will fail, if we demote src:mongodb to multiverse as src:mongodb-sspl but not sure.
<xnox> actually maybe it should work hm.... I can't remember if universe builds, are allowed to build-depend on multiverse or not.
<xnox> (i know that binaries may not depend, but can't remember if it was allowed in Ubuntu, to be used during build)
<cjwatson> They aren't
<cjwatson> Build-dependencies downward in supportedness are allowed nowadays, but not downward in freedom
<xnox> cjwatson:  thank you! that makes sense.
<xnox> (i.e. restricted can build-depend on multiverse)
<cjwatson> Yes
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (focal-proposed/main) [5.4.0-32.36] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-desktop-icons (focal-proposed/main) [20.04.0-1 => 20.04.0-2~ubuntu20.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (focal-proposed/main) [5.4.0-32.36] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (focal-proposed/main) [5.4.0-32.36] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (focal-proposed/main) [5.4.0-32.36] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (focal-proposed) [5.4.0-32.36]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (focal-proposed) [5.4.0-32.36]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (focal-proposed) [5.4.0-32.36]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (focal-proposed) [5.4.0-32.36]
<locutus_> aodh and zaqar needs merge from debian?
<locutus_> in Debian they use pymongo
<locutus_> (and suggest mongodb)
-queuebot:#ubuntu-release- Unapproved: sssd (eoan-proposed/main) [2.2.0-4ubuntu1 => 2.2.0-4ubuntu1.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sssd (bionic-proposed/main) [1.16.1-1ubuntu1.5 => 1.16.1-1ubuntu1.6] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: evince (focal-proposed/main) [3.36.0-2 => 3.36.1-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-102.103] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-180.210] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-102.103] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-180.210]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-102.103]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-102.103]
<cking> hi there, i'd like to get 0.05.23-1ubuntu3 in xenial released, it fixes an issue found in testing during for 0.05.23-1ubuntu2, can this be nudged
-queuebot:#ubuntu-release- Unapproved: accepted neutron-dynamic-routing [source] (focal-proposed) [2:16.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted networking-hyperv [source] (focal-proposed) [1:8.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted networking-bgpvpn [source] (focal-proposed) [12.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted networking-odl [source] (focal-proposed) [1:16.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted networking-sfc [source] (focal-proposed) [10.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas [source] (focal-proposed) [1:16.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-vpnaas [source] (focal-proposed) [2:16.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted octavia [source] (focal-proposed) [6.0.0-0ubuntu0.20.04.1]
<vorlon> locutus_: wrt the initramfs-tools merge, if you used MoM for the merge, did you happen to verify that none of the scripts that were +x in the earlier tarball had been made -x by the merge?
<vorlon> because MoM seems to have an annoying bug in this regard which has defied fixing
-queuebot:#ubuntu-release- Unapproved: accepted swift [source] (focal-proposed) [2.25.0-0ubuntu0.20.04.1]
<vorlon> locutus_: pyyaml seems to have migrated and is now only NBS?
-queuebot:#ubuntu-release- Unapproved: accepted manila [source] (focal-proposed) [1:10.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted mistral [source] (focal-proposed) [10.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: apparmor (focal-proposed/main) [2.13.3-7ubuntu5 => 2.13.3-7ubuntu5.1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted senlin [source] (focal-proposed) [9.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted watcher [source] (focal-proposed) [1:4.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New binary: umis [ppc64el] (groovy-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: umis [amd64] (groovy-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: umis [armhf] (groovy-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: umis [arm64] (groovy-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: masakari (focal-proposed/main) [9.0.0-0ubuntu0.20.04.1 => 9.0.0-0ubuntu0.20.04.2] (no packageset)
-queuebot:#ubuntu-release- New binary: umis [riscv64] (groovy-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted sahara [source] (focal-proposed) [1:12.0.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted vala [source] (focal-proposed) [0.48.6-0ubuntu1]
<bdmurray> dannf`: Did you do the regression test in bug 1875984?
<ubot5> bug 1875984 in clevis (Ubuntu Focal) "console noise when / is not bound" [Undecided,Fix committed] https://launchpad.net/bugs/1875984
<dannf`> bdmurray: i don't recall - but i just did. it worked, i'll note as much in the bug
<coreycb> bdmurray: I have just one more upload in the focal unapproved queue to fix a component mismatch for masakari
<coreycb> bdmurray: vorlon: thanks for all the reviews, really appreciate it
<bdmurray> coreycb: I looked but was waiting for it to migrate in groovy
<coreycb> bdmurray: ah cool, good idea
<bdmurray> coreycb: if you see it migrate feel free to ping me
<coreycb> bdmurray: sounds good, I'll keep an eye on it and will let you know
-queuebot:#ubuntu-release- New source: python-masakariclient (groovy-proposed/primary) [6.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (focal-proposed) [1.450.1]
-queuebot:#ubuntu-release- Unapproved: accepted sbuild-launchpad-chroot [source] (focal-proposed) [0.16ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted sbuild-launchpad-chroot [source] (eoan-proposed) [0.15ubuntu0.19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted sbuild-launchpad-chroot [source] (bionic-proposed) [0.14ubuntu0.18.04.2]
<coreycb> bdmurray: masakari has migrated in groovy
<bdmurray> coreycb: ack
<kanashiro> hi, I am investigating why genshi is blocked in proposed for 18 days and I noticed python 2 binary package was dropped in this new version and in the excuses page says that python-genshi is missing
<kanashiro> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#genshi
<kanashiro> I also did not find any reverse dependency
<kanashiro> does anyone has a clue on how to unblock it?
-queuebot:#ubuntu-release- Unapproved: accepted yaru-theme [source] (focal-proposed) [20.04.7]
-queuebot:#ubuntu-release- Unapproved: accepted adwaita-icon-theme [source] (focal-proposed) [3.36.1-2ubuntu0.20.04.1]
<vorlon> kanashiro: that's an awkward thing in britney because the package moved from building an arch: any binary to now only building arch: all binaries; so it miscalculates whether a build is missing
<vorlon> kanashiro: I'll just axe the python-genshi binaries from groovy (after double-checking no revdeps) and that will clear it
<kanashiro> vorlon: ah right, thank you for that
-queuebot:#ubuntu-release- Unapproved: accepted masakari [source] (focal-proposed) [9.0.0-0ubuntu0.20.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted tilda [source] (focal-proposed) [1.5.2-0ubuntu1]
<bdmurray> hrrm, sru-review is hung and I don't know what its up to
#ubuntu-release 2020-05-20
<tumbleweed> what version of autodep8 is the CI infrastructure using?
<tumbleweed> if it's from from 18.04, it'd explain the r-bioc-rhdf5 failure and I can stop tearing hair out (missing tset dep)
<vorlon> tumbleweed: autodep8 is deployed from https://git.launchpad.net/~ubuntu-release/+git/autodep8
<vorlon> seems to be 0.19
<vorlon> so not 18.04, but older than what's in focal, to be sure
<Eickmeyer> Quick question: what is the proper versioning for a Debian package that needs to be SRU'd? For instance, if it's 0.24.8~dfsg0-1 would it be 0.24.8~dfsg0-1~20.04.1 or 0.24.8~dfsg0-1ubuntu1~20.04.1?
<vorlon> Eickmeyer: recommending versioning scheme here: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
<Eickmeyer> vorlon: ta
<Eickmeyer> (I was close with my second example)
<vorlon> tumbleweed: correction, looks like that branch is up-to-date with 0.22
<tumbleweed> vorlon: with what apt sources available?
<tumbleweed> (the R stuff uses grep-aptavail)
<tumbleweed> well, more to the point, grep-dctrl
<tumbleweed> no, the aptavail is what matters
<tumbleweed> so, I'm guessing xenial
-queuebot:#ubuntu-release- New binary: libclamunrar [amd64] (groovy-proposed/multiverse) [0.102.3-2] (no packageset)
<vorlon> tumbleweed: er, it runs grep-dctrl against a file in the package source, doesn't it? (DESCRIPTION)
<tumbleweed> vorlon: yes, but it gets the list of R modules available in the world, from apt
<tumbleweed> there was a force-reset-test for it. commented and bumped
<vorlon> tumbleweed: ah.  ok, that seems rather terrible
<tumbleweed> indeed
<tumbleweed> we colud hack it to look at lists of packages that we maintain separately, but ick
<tumbleweed> I guess it's a sign that autopkgtests are maturing, that this release a lot of the issues I'm looking at are specific to Ubuntu's test-runner environment's difference to debian
<LocutusOfBorg> vorlon, you were right, missing "+x" on init file
<LocutusOfBorg> damn MoM bugs!
<LocutusOfBorg> and thanks!
<Laney> tumbleweed: Sounds like a bug in autodep8 :(
<Laney> does Debian provide that guarantee?
<LocutusOfBorg> uploading on bileto, lets see
<Laney> I guess we should check snakefruit to see if anything to stuck after the networking incident yesterday
<Laney> that's happened before
 * Laney does
<Laney> heh, there was a run of https://people.canonical.com/~ubuntu-archive/testing-ports/ from Apr 26
<Laney> such a used service
<Laney> looks ok apart from that
<doko> RikMills: loaklize still recommends python2 packages, blocking some NBS
-queuebot:#ubuntu-release- Unapproved: wpa (focal-proposed/main) [2:2.9-1ubuntu4 => 2:2.9-1ubuntu5] (core)
-queuebot:#ubuntu-release- Unapproved: rejected wpa [source] (focal-proposed) [2:2.9-1ubuntu5]
-queuebot:#ubuntu-release- Unapproved: wpa (focal-proposed/main) [2:2.9-1ubuntu4 => 2:2.9-1ubuntu5] (core)
-queuebot:#ubuntu-release- New binary: select2.js [amd64] (groovy-proposed/universe) [4.0.13+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libproxy (focal-proposed/main) [0.4.15-10 => 0.4.15-10ubuntu1] (core, i386-whitelist)
<RikMills> doko: https://launchpad.net/ubuntu/+source/lokalize/4:20.04.1-0ubuntu2
<doko> ta
-queuebot:#ubuntu-release- Unapproved: urwid (focal-proposed/universe) [2.0.1-3 => 2.1.0-1ubuntu1] (no packageset)
<doko> Laney: can you have an extra dependency for an autopkg test, which is triggered by Testsuite: autopkgtest-pkg-python
<doko> or anybody else
-queuebot:#ubuntu-release- Unapproved: rejected urwid [source] (focal-proposed) [2.1.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: s390-tools (groovy-proposed/main) [2.12.0-0ubuntu3 => 2.12.0-0ubuntu4] (core)
<coreycb> doko: hi, we had python-ironicclient in main at one point via bug 1376238. by any chance could we get python3-ironicclient into main for focal and above?
<ubot5> bug 1376238 in python-ironicclient (Ubuntu) "[MIR] python-ironicclient" [High,Fix released] https://launchpad.net/bugs/1376238
<Laney> doko: If you add a test with "Restrictions: hint-testsuite-triggers" and the extra depends in "Depends:" of that test, it should do what you want (I think, test it in bileto or something)
<doko> Laney: in debian/control ? the package doesn't have a separate test
<Laney> in debian/tests/control
-queuebot:#ubuntu-release- Unapproved: gnome-clocks (focal-proposed/universe) [3.36.0-1ubuntu0.1 => 3.36.0-1ubuntu0.2] (desktop-extra)
-queuebot:#ubuntu-release- Unapproved: vala (bionic-proposed/universe) [0.40.19-0ubuntu1 => 0.40.23-0ubuntu1] (ubuntu-desktop)
<seb128> rbasak, ^ could you review that gnome-clocks SRU? it's a trivial no change upload to rebuild with a fixed toolchain and fix a regression from the previous SRU (which sadly already moved to -updates so would be nice to get the regression fix going)
<rbasak> Looking
<rbasak> seb128: broken bug reference?
<doko> xnox: could you have a look at https://launchpadlibrarian.net/477651652/buildlog_ubuntu-groovy-amd64.vcmi_0.99+dfsg+git20190113.f06c8a87-1build2_BUILDING.txt.gz  boost 1.71 issue
-queuebot:#ubuntu-release- Unapproved: gnome-clocks (focal-proposed/universe) [3.36.0-1ubuntu0.1 => 3.36.0-1ubuntu0.2] (desktop-extra)
<seb128> rbasak, good eyes! thanks, ^
<zesty> "pkexec do-release-upgrade -d -m desktop -f DistUpgradeViewKDE" gives me a front door message that says "This release is still in development. Do not install it on production machines."  Just an oversight?
<vorlon> Laney: testing-ports> heh
<zesty> without the "-d" option I get "There is no development version of an LTS available."
<zesty> So... mostly released?
-queuebot:#ubuntu-release- Unapproved: adwaita-icon-theme (focal-proposed/main) [3.36.1-2ubuntu0.20.04.1 => 3.36.1-2ubuntu0.20.04.2] (core, i386-whitelist)
<xnox> doko:  looks very odd indeed.
<doko> bdmurray: apport should b-d on pyflakes3, not pyflakes. could you change that?
<bdmurray> doko: yes
<doko> bdmurray: are you calling pyflakes3 as well?
<bdmurray> doko: yes
-queuebot:#ubuntu-release- Unapproved: rejected gnome-clocks [source] (focal-proposed) [3.36.0-1ubuntu0.2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-clocks [source] (focal-proposed) [3.36.0-1ubuntu0.2]
<rbasak> seb128: ^ sorry for the delay. I had interrupts and am still unwinding my stack.
<rbasak> I was going to add a vala Focal task but I think a Launchpad bug is stopping me from doing that.
<rbasak> (presumably it is Fix Released though)
<vorlon> doko, bdmurray: oops I already uploaded that change
<vorlon> and NBS-cleaned up pyflakes
<bdmurray> okay
<bdmurray> vorlon: shouldn't these tzdata updates go to -security?
<tumbleweed> Laney: filed a bug for the autodep8 R thing: https://bugs.debian.org/961138
<ubot5> Debian bug 961138 in autodep8 "autodep8 uses host APT packages to generate dependencies for pkg-r-autopkgtest tests" [Normal,Open]
<Laney> nice one
<seb128> rbasak, it's fix release in g for vala yes, and fix commit in focal (SRU in proposed)
<seb128> rbasak, and thanks for the reviews!
-queuebot:#ubuntu-release- New binary: biosig4c++ [ppc64el] (groovy-proposed/universe) [1.9.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: biosig4c++ [s390x] (groovy-proposed/universe) [1.9.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: biosig4c++ [amd64] (groovy-proposed/universe) [1.9.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: biosig4c++ [armhf] (groovy-proposed/universe) [1.9.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: biosig4c++ [arm64] (groovy-proposed/universe) [1.9.5-1] (no packageset)
<vorlon> bdmurray: well security SRUs are supposed to be built in the security pocket, which these haven't been
<vorlon> bdmurray: maybe that's ok because they're data-only, but we'd need the security team to ack
<bdmurray> vorlon: how can we get that ack?
<vorlon> sbeattie: ^^ do you want to ack this? :)
<sbeattie> one sec, let me look
<vorlon> "Due to the potentially disastrous consequences of having localtime differ between systems running -updates and systems running only -security, this package is always kept in sync between the two pockets." https://wiki.ubuntu.com/StableReleaseUpdates but it doesn't mention whether the package needs to be built in -security
<bdmurray> this built w/ updates afaict https://launchpad.net/ubuntu/+source/tzdata/2019c-0ubuntu0.18.04/+build/17837399
<sbeattie> I acked on LP: #1878108
<ubot5> Launchpad bug 1878108 in tzdata (Ubuntu Trusty) "new upstream release 2020a" [Undecided,In progress] https://launchpad.net/bugs/1878108
<bdmurray> sbeattie: what should the process be going forward?
<Eickmeyer> rbasak: I have an SRU in bug 1877806, I just wanted to gauge your thoughts on it.
<ubot5> bug 1877806 in ardour (Ubuntu Focal) "[SRU] ardour crashes when saving lv2 plugin preset - bug discovered in lilv" [Undecided,Triaged] https://launchpad.net/bugs/1877806
<sbeattie> bdmurray: as long as tzdata retains the status of being data-only plus one shell script, I think going forward it is fine to build in -proposed.
<rbasak> Eickmeyer: sorry, I won't have time today - about to finish.
<Eickmeyer> rbasak: Ok, thanks.
<bdmurray> sbeattie: okay, should we get security to review each one?
<sbeattie> bdmurray: yeah, let's do that, and if it interferes with the ability to get timely tzdata updates landed, we can revisit.
<bdmurray> sbeattie: the review could happen before the verification is done / when it ends up in -proposed
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (bionic-proposed) [0.99-0ubuntu3~18.04.2]
-queuebot:#ubuntu-release- Unapproved: tmux (focal-proposed/main) [3.0a-2 => 3.0a-2ubuntu0.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted tmux [source] (focal-proposed) [3.0a-2ubuntu0.1]
-queuebot:#ubuntu-release- New binary: biosig4c++ [riscv64] (groovy-proposed/universe) [1.9.5-1] (no packageset)
-queuebot:#ubuntu-release- Packageset: Added lilv to ubuntustudio in bionic
-queuebot:#ubuntu-release- Packageset: Added lilv to ubuntustudio in eoan
-queuebot:#ubuntu-release- Packageset: Added lilv to ubuntustudio in focal
-queuebot:#ubuntu-release- Packageset: Added lilv to ubuntustudio in groovy
-queuebot:#ubuntu-release- New binary: python-matrix-nio [amd64] (groovy-proposed/none) [0.11.2-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lilv (focal-proposed/universe) [0.24.6-1 => 0.24.8~dfsg0-1ubuntu0.20.04.1] (i386-whitelist, kubuntu, ubuntustudio)
<Eickmeyer> Can I get a reject on lilv above? It has a dependency issue I need to resolve. Sorry about the mess!
<Eickmeyer> vorlon: ^ ?
<vorlon> Eickmeyer: rejected
-queuebot:#ubuntu-release- Unapproved: rejected lilv [source] (focal-proposed) [0.24.8~dfsg0-1ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New: accepted biosig4c++ [amd64] (groovy-proposed) [1.9.5-1]
-queuebot:#ubuntu-release- New: accepted biosig4c++ [armhf] (groovy-proposed) [1.9.5-1]
-queuebot:#ubuntu-release- New: accepted biosig4c++ [riscv64] (groovy-proposed) [1.9.5-1]
-queuebot:#ubuntu-release- New: accepted libclamunrar [amd64] (groovy-proposed) [0.102.3-2]
-queuebot:#ubuntu-release- New: accepted python-matrix-nio [amd64] (groovy-proposed) [0.11.2-2]
-queuebot:#ubuntu-release- New: accepted biosig4c++ [arm64] (groovy-proposed) [1.9.5-1]
-queuebot:#ubuntu-release- New: accepted biosig4c++ [s390x] (groovy-proposed) [1.9.5-1]
-queuebot:#ubuntu-release- New: accepted select2.js [amd64] (groovy-proposed) [4.0.13+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted biosig4c++ [ppc64el] (groovy-proposed) [1.9.5-1]
-queuebot:#ubuntu-release- New: accepted python-masakariclient [source] (groovy-proposed) [6.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted umis [amd64] (groovy-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted umis [armhf] (groovy-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted umis [riscv64] (groovy-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted umis [arm64] (groovy-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted umis [ppc64el] (groovy-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted libclamunrar [amd64] (groovy-proposed) [0.102.3-1]
-queuebot:#ubuntu-release- New: accepted notcurses [arm64] (groovy-proposed) [1.4.2.3+dfsg.1-1]
-queuebot:#ubuntu-release- New: accepted notcurses [riscv64] (groovy-proposed) [1.4.2.3+dfsg.1-1]
-queuebot:#ubuntu-release- New: accepted purify [amd64] (groovy-proposed) [2.0.0-5]
-queuebot:#ubuntu-release- New: accepted purify [armhf] (groovy-proposed) [2.0.0-5]
-queuebot:#ubuntu-release- New: accepted purify [s390x] (groovy-proposed) [2.0.0-5]
-queuebot:#ubuntu-release- New: accepted rustc [arm64] (groovy-proposed) [1.42.0+dfsg1+llvm-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [i386] (groovy-proposed) [1.42.0+dfsg1+llvm-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [s390x] (groovy-proposed) [1.42.0+dfsg1+llvm-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted notcurses [amd64] (groovy-proposed) [1.4.2.3+dfsg.1-1]
-queuebot:#ubuntu-release- New: accepted notcurses [s390x] (groovy-proposed) [1.4.2.3+dfsg.1-1]
-queuebot:#ubuntu-release- New: accepted purify [ppc64el] (groovy-proposed) [2.0.0-5]
-queuebot:#ubuntu-release- New: accepted rustc [armhf] (groovy-proposed) [1.42.0+dfsg1+llvm-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted notcurses [ppc64el] (groovy-proposed) [1.4.2.3+dfsg.1-1]
-queuebot:#ubuntu-release- New: accepted rustc [amd64] (groovy-proposed) [1.42.0+dfsg1+llvm-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted purify [arm64] (groovy-proposed) [2.0.0-5]
-queuebot:#ubuntu-release- New: accepted rustc [ppc64el] (groovy-proposed) [1.42.0+dfsg1+llvm-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted apertium-cat-ita [amd64] (groovy-proposed) [0.2.1-2]
-queuebot:#ubuntu-release- New: accepted yara [arm64] (groovy-proposed) [4.0.1-1]
-queuebot:#ubuntu-release- New: accepted yara [ppc64el] (groovy-proposed) [4.0.1-1]
-queuebot:#ubuntu-release- New: accepted yara [s390x] (groovy-proposed) [4.0.1-1]
-queuebot:#ubuntu-release- New: accepted yara [amd64] (groovy-proposed) [4.0.1-1]
-queuebot:#ubuntu-release- New: accepted yara [riscv64] (groovy-proposed) [4.0.1-1]
-queuebot:#ubuntu-release- New: accepted yara [armhf] (groovy-proposed) [4.0.1-1]
-queuebot:#ubuntu-release- New binary: python-masakariclient [amd64] (groovy-proposed/none) [6.0.0-0ubuntu1] (no packageset)
<Eickmeyer> vorlon: ta
-queuebot:#ubuntu-release- New: accepted python-masakariclient [amd64] (groovy-proposed) [6.0.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: live-build (focal-proposed/main) [3.0~a57-1ubuntu38 => 3.0~a57-1ubuntu38.20.04.1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: lilv (focal-proposed/universe) [0.24.6-1 => 0.24.6-1ubuntu0.3] (i386-whitelist, kubuntu, ubuntustudio)
<Eickmeyer> vorlon: Sorry to bug you again, but could you reject lilv again? I meant to put that in a PPA first.
<Eickmeyer> It builds, but I have yet to test and the versioning is wrong.
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (focal-proposed) [2.20.11-0ubuntu27.2]
-queuebot:#ubuntu-release- Unapproved: accepted aptdaemon [source] (focal-proposed) [1.1.1+bzr982-0ubuntu32.1]
-queuebot:#ubuntu-release- Unapproved: accepted aptdaemon [source] (eoan-proposed) [1.1.1+bzr982-0ubuntu28.2]
-queuebot:#ubuntu-release- Unapproved: accepted aptdaemon [source] (bionic-proposed) [1.1.1+bzr982-0ubuntu19.3]
-queuebot:#ubuntu-release- Unapproved: accepted aptdaemon [source] (xenial-proposed) [1.1.1+bzr982-0ubuntu14.3]
-queuebot:#ubuntu-release- Unapproved: rejected lilv [source] (focal-proposed) [0.24.6-1ubuntu0.3]
<Eickmeyer> vorlon: ta
<mwhudson> ubuntu-archive: is it ok to "SRU" a rustc to focal that won't build on riscv?
<jdstrand> hey, fyi, the pulseaudio in groovy-proposed isn't migrating cause of a testsuite failure 'FAIL: volume-test'. I did the upload to address a CVE amd didn't touch this area of the code
<jdstrand> err, testsuite failure on *riscv64* only
<jdstrand> all the other archs pass. this also bundles a fix from the desktop team from ubuntu4, but it wasn't built on riscv64 there
<jdstrand> I'm not really in a position to fix this arch-specific issue atm. is this a candidate to be forced?
 * jdstrand notes pulseaudio ftbfs on focal
<jdstrand> (again, for riscv64)
-queuebot:#ubuntu-release- New binary: pantalaimon [amd64] (groovy-proposed/universe) [0.6.1-2] (no packageset)
<vorlon> mwhudson: is that going to cause the rustc package itself to be out of date on riscv64?  will it cause regressions in installability?
<mwhudson> vorlon: yes to the former, don't think so to the latter
<mwhudson> i guess it means that there will be a librust-std1.41 or whatever it's called on riscv still and librust-std1.42 on others
<vorlon> mwhudson: ok.  as long as it doesn't increase uninstallabilities, I'd consider it acceptable
<mwhudson> vorlon: is there an easy way to check that?
<vorlon> mwhudson: well we should probably use britney to do that
<mwhudson> vorlon: ah well we can almost do that now https://people.canonical.com/~ubuntu-archive/proposed-migration/groovy/update_excuses.html#rustc
<mwhudson> vorlon: how do we get britney to ignore the missing build?
<vorlon> mwhudson: yeah except that's to the release pocket vs updates; there are britney instances for SRUs, so I'd say upload it and we'll see
<mwhudson> i know removing the old binaries is one way
<vorlon> I don't think we do want to ignore the missing build for devel
<mwhudson> ok
<mwhudson> vorlon: ok i've uploaded to focal unapproved
<mwhudson> vorlon: this needs to get to the security pocket eventually but i guess that can be done via another upload?
-queuebot:#ubuntu-release- Unapproved: rustc (focal-proposed/universe) [1.41.0+dfsg1+llvm-0ubuntu2 => 1.42.0+dfsg1+llvm-1ubuntu2~20.04.1] (i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: lilv (focal-proposed/universe) [0.24.6-1 => 0.24.6-1ubuntu0.1] (i386-whitelist, kubuntu, ubuntustudio)
<Eickmeyer> Ok, ^ that one is for real for SRU bug 1877806
<ubot5> bug 1877806 in ardour (Ubuntu Focal) "[SRU] ardour crashes when saving lv2 plugin preset - bug discovered in lilv" [Undecided,Triaged] https://launchpad.net/bugs/1877806
<RikMills> vorlon: it seems that nmapsi4 in proposed switched to build depending on QtWebEngine, so is now not buildable on ppc4el/s390x/riscv64. Could you remove the release pocket binaries for those?
<vorlon> RikMills: forensics-all-gui needs fixed first to not depend on it
<vorlon> RikMills: oh wait, that's arch: all - nevermind
<vorlon> RikMills: removed
<RikMills> vorlon: thanks!
-queuebot:#ubuntu-release- Unapproved: network-manager (focal-proposed/main) [1.22.10-1ubuntu2 => 1.22.10-1ubuntu2.1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: rejected wpa [source] (focal-proposed) [2:2.9-1ubuntu5]
-queuebot:#ubuntu-release- Unapproved: wpa (focal-proposed/main) [2:2.9-1ubuntu4 => 2:2.9-1ubuntu5] (core)
-queuebot:#ubuntu-release- Unapproved: djvulibre (bionic-proposed/main) [3.5.27.1-8ubuntu0.1 => 3.5.27.1-8ubuntu0.2] (desktop-core, ubuntu-server)
<vorlon> wgrant: any idea why util-linux's setarch --uname-2.6 test would have regressed on riscv64?  it's not a new test
<wgrant> vorlon: that was failing early on last year, due to an assumption about iirc stack layout that was fixed upstream. I carried a patch in my out-of-archive port for a while, but then one update it started building fine so I assumed the upstream fix had made it downstream. I have notes somewhere, will find in a bit.
<wgrant> vorlon: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/sys-utils/setarch.c?id=33e87bf1524baa215413cbcb26668e600a7b5cb8 was the fix in question
<wgrant> not sure if it's the same issue
-queuebot:#ubuntu-release- New binary: kmod [amd64] (groovy-proposed/main) [27+20200310-2ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: kmod [s390x] (groovy-proposed/main) [27+20200310-2ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: kmod [i386] (groovy-proposed/main) [27+20200310-2ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: kmod [ppc64el] (groovy-proposed/main) [27+20200310-2ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: kmod [arm64] (groovy-proposed/main) [27+20200310-2ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New: accepted kmod [amd64] (groovy-proposed) [27+20200310-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted kmod [i386] (groovy-proposed) [27+20200310-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted kmod [s390x] (groovy-proposed) [27+20200310-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted kmod [arm64] (groovy-proposed) [27+20200310-2ubuntu1]
-queuebot:#ubuntu-release- New binary: kmod [armhf] (groovy-proposed/main) [27+20200310-2ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New: accepted kmod [ppc64el] (groovy-proposed) [27+20200310-2ubuntu1]
#ubuntu-release 2020-05-21
-queuebot:#ubuntu-release- New: accepted kmod [armhf] (groovy-proposed) [27+20200310-2ubuntu1]
-queuebot:#ubuntu-release- New binary: staden-io-lib [amd64] (groovy-proposed/universe) [1.14.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: staden-io-lib [ppc64el] (groovy-proposed/universe) [1.14.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: staden-io-lib [arm64] (groovy-proposed/universe) [1.14.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: staden-io-lib [armhf] (groovy-proposed/universe) [1.14.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: staden-io-lib [riscv64] (groovy-proposed/universe) [1.14.12-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pantalaimon [amd64] (groovy-proposed) [0.6.1-2]
-queuebot:#ubuntu-release- New: accepted staden-io-lib [arm64] (groovy-proposed) [1.14.12-1]
-queuebot:#ubuntu-release- New: accepted staden-io-lib [ppc64el] (groovy-proposed) [1.14.12-1]
-queuebot:#ubuntu-release- New: accepted staden-io-lib [amd64] (groovy-proposed) [1.14.12-1]
-queuebot:#ubuntu-release- New: accepted staden-io-lib [riscv64] (groovy-proposed) [1.14.12-1]
-queuebot:#ubuntu-release- New: accepted staden-io-lib [armhf] (groovy-proposed) [1.14.12-1]
<vorlon> wgrant: ok, we definitely have that commit from upstream in this version of util-linux, so must be a different issue
-queuebot:#ubuntu-release- Unapproved: ceph (bionic-proposed/main) [12.2.13-0ubuntu0.18.04.1 => 12.2.13-0ubuntu0.18.04.2] (desktop-core, ubuntu-server)
<RikMills> sil2100: if you are doing SRUs, I have just marked plasma for focal done. if you prefer to leave that longer (next week) then no worries
-queuebot:#ubuntu-release- Unapproved: ceph (eoan-proposed/main) [14.2.8-0ubuntu0.19.10.1 => 14.2.9-0ubuntu0.19.10.1] (desktop-core, ubuntu-server)
<sil2100> RikMills: let me take a look in a bit
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-amdgpu-hwe-18.04 (bionic-proposed/main) [19.0.1-1ubuntu1~18.04.1 => 19.1.0-1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-ati-hwe-18.04 (bionic-proposed/main) [1:19.0.1-1ubuntu1~18.04.1 => 1:19.1.0-1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xorg-server (focal-proposed/main) [2:1.20.8-2ubuntu2 => 2:1.20.8-2ubuntu2.1] (desktop-core, i386-whitelist, xorg)
-queuebot:#ubuntu-release- Unapproved: rejected xorg-server-hwe-18.04 [source] (bionic-proposed) [2:1.20.8-2ubuntu2~18.04.1]
-queuebot:#ubuntu-release- Unapproved: xorg-server-hwe-18.04 (bionic-proposed/main) [2:1.20.5+git20191008-0ubuntu1~18.04.1 => 2:1.20.8-2ubuntu2.1~18.04.1] (no packageset)
<sil2100> paride: hey! I was looking into the server images situation on cdimage, and I would like to understand how currently the marking of images for current in server works
<sil2100> paride: since looking at the images, it feels as if something went wrong when marking images as current, which is done as result of testing - since for instance current/ does not have a groovy live-server image for s390x or arm64, only old focal ones
<sil2100> So not knowing how the server QA triggers those, my theory right now is that the QA for those images didn't yet run mark-current on any s390x or arm64 images? Are the tests failing or something?
<sil2100> There is also a leftover amd64 focal image there, which makes no sense since there's also a groovy one there too - but this one I can clean up
<sil2100> paride: is testing for those clean? Should s390x and arm64 pending images have been marked as current as well?
<paride> sil2100, the tests are indeed failing because of https://bugs.launchpad.net/ubuntu/+source/debian-cd/+bug/1877538
<ubot5> Ubuntu bug 1877538 in debian-cd (Ubuntu) "preseed directory missing from Groovy images" [Undecided,New]
<xnox> Right. Which I didn't have time to look into
<xnox> Yet
<paride> the directory is missing from the amd64 images too, but was not in the lists of the things to check as part of the static validation process
<paride> jibel, ^
<paride> sil2100, the promotion is done by calling: /srv/cdimage.ubuntu.com/bin/mark-current -p $PROJECT -s $RELEASE -t $TYPE -a $ARCH $BUILDSTAMP
<paride> via ssh on nusanak
<paride> sil2100, it doesn't seems that the script can be called with wrong parameters so for example a focal image is moved where groovy images should go
<sil2100> paride: I guess the amd64 is some weird leftover then, but yeah, in that case if the arm64 and s390x tests are failing and no mark-current is executed for those, having old focal images there is a natural consequence
<sil2100> Since there were no groovy images that could be marked current
<sil2100> I'll remove the weird amd64 focal images though, rest should resolve by itself once the tests are green I suppose
<paride> sil2100, ack, let's try to cleanup and see if it stays clean. The .metalink files of out-of-place focal images have a recent timestamp, but I guess they're auto-generated periodically
<xnox> ooooh
<xnox> i think i found it!
<xnox> sil2100:  one momement
<sil2100> xnox: what's up? :)
<xnox> sil2100:  https://code.launchpad.net/~xnox/debian-cd/missing-tools-groovy/+merge/384336
<xnox> sil2100:  only 2/3rds of "focal" things got copied to "groovy" things in debian-cd
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (bionic-proposed) [20.0.4-2ubuntu1~18.04.1]
<sil2100> Oh my
<RikMills> sil2100: thanks for releasing plasma :)
<sil2100> xnox: ah! Indeed!
<sil2100> I guess I copied only tools/boot/focal but not tools/focal
<xnox> life is hard, we should kill debian-cd
<sil2100> xnox: good catch, merged! Yeah, totally missed this one
 * paride looking forward the new batch of images :)
<paride> speaking of live-server, do we need those preseeds?
<sil2100> ...and now deployed
 * sil2100 would have never found that
<sil2100> Since I have never bootstrapped a new release on debian-cd before!
<sil2100> paride, xnox: let me kick off new server-live images in this case
<jibel> sil2100, can you do desktop too?
<xnox> sil2100:  i think everything is affected
<xnox> paride:  no, no we don't. but i wanted to find them first; before killing them properly and asserting that we don't have them =)
<paride> xnox, sounds good!
-queuebot:#ubuntu-release- New binary: calamares-settings-ubuntu [amd64] (groovy-proposed/universe) [1:20.10.1] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-ati-hwe-18.04 [source] (bionic-proposed) [1:19.1.0-1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-amdgpu-hwe-18.04 [source] (bionic-proposed) [19.1.0-1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server-hwe-18.04 [source] (bionic-proposed) [2:1.20.8-2ubuntu2.1~18.04.1]
<paride> xnox, focal-live-server still can't seed the snaps
<paride> sorry, bionic
<paride> focal is fine
-queuebot:#ubuntu-release- New source: openscap (groovy-proposed/primary) [1.2.16-2ubuntu5]
<xnox> paride:  looking
-queuebot:#ubuntu-release- New: accepted calamares-settings-ubuntu [amd64] (groovy-proposed) [1:20.10.1]
-queuebot:#ubuntu-release- New: accepted openscap [source] (groovy-proposed) [1.2.16-2ubuntu5]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-418-server [source] (groovy-proposed) [418.126.02-0ubuntu1]
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-418-server [ppc64el] (groovy-proposed/none) [418.126.02-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: openscap [s390x] (groovy-proposed/none) [1.2.16-2ubuntu5] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-418-server [amd64] (groovy-proposed/none) [418.126.02-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: openscap [amd64] (groovy-proposed/none) [1.2.16-2ubuntu5] (no packageset)
-queuebot:#ubuntu-release- New binary: openscap [ppc64el] (groovy-proposed/none) [1.2.16-2ubuntu5] (no packageset)
-queuebot:#ubuntu-release- New binary: openscap [armhf] (groovy-proposed/universe) [1.2.16-2ubuntu5] (no packageset)
-queuebot:#ubuntu-release- New: accepted libdrm [amd64] (bionic-proposed) [2.4.101-2~18.04.1]
-queuebot:#ubuntu-release- New: accepted libdrm [armhf] (bionic-proposed) [2.4.101-2~18.04.1]
-queuebot:#ubuntu-release- New: accepted libdrm [ppc64el] (bionic-proposed) [2.4.101-2~18.04.1]
-queuebot:#ubuntu-release- New: accepted libdrm [arm64] (bionic-proposed) [2.4.101-2~18.04.1]
-queuebot:#ubuntu-release- New: accepted libdrm [s390x] (bionic-proposed) [2.4.101-2~18.04.1]
-queuebot:#ubuntu-release- New: accepted libdrm [i386] (bionic-proposed) [2.4.101-2~18.04.1]
-queuebot:#ubuntu-release- New binary: openscap [arm64] (groovy-proposed/universe) [1.2.16-2ubuntu5] (no packageset)
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-418-server [amd64] (groovy-proposed) [418.126.02-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-418-server [ppc64el] (groovy-proposed) [418.126.02-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (focal-proposed) [2:1.20.8-2ubuntu2.1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-10 [source] (bionic-proposed) [1:10.0.0-4ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (eoan-proposed) [2.20.11-0ubuntu8.9]
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (bionic-proposed) [2.20.9-0ubuntu7.15]
-queuebot:#ubuntu-release- Unapproved: gnome-logs (focal-proposed/main) [3.34.0-1 => 3.34.0-1ubuntu1] (ubuntu-desktop, ubuntugnome)
-queuebot:#ubuntu-release- New binary: openscap [riscv64] (groovy-proposed/universe) [1.2.16-2ubuntu5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python-apt [source] (eoan-proposed) [1.9.0ubuntu1.4]
-queuebot:#ubuntu-release- Unapproved: accepted python-apt [source] (bionic-proposed) [1.6.5ubuntu0.3]
-queuebot:#ubuntu-release- Unapproved: accepted python-apt [source] (xenial-proposed) [1.1.0~beta1ubuntu0.16.04.9]
-queuebot:#ubuntu-release- New: accepted openscap [amd64] (groovy-proposed) [1.2.16-2ubuntu5]
-queuebot:#ubuntu-release- New: accepted openscap [armhf] (groovy-proposed) [1.2.16-2ubuntu5]
-queuebot:#ubuntu-release- New: accepted openscap [riscv64] (groovy-proposed) [1.2.16-2ubuntu5]
-queuebot:#ubuntu-release- New: accepted openscap [arm64] (groovy-proposed) [1.2.16-2ubuntu5]
-queuebot:#ubuntu-release- New: accepted openscap [s390x] (groovy-proposed) [1.2.16-2ubuntu5]
-queuebot:#ubuntu-release- New: accepted openscap [ppc64el] (groovy-proposed) [1.2.16-2ubuntu5]
-queuebot:#ubuntu-release- Packageset: Added lubuntu-update-notifier to lubuntu in focal
-queuebot:#ubuntu-release- Packageset: Added calamares-settings-ubuntu to ubuntustudio in groovy
-queuebot:#ubuntu-release- Packageset: Added lubuntu-update-notifier to lubuntu in groovy
-queuebot:#ubuntu-release- New binary: xmds2 [amd64] (groovy-proposed/universe) [3.0.0+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: coccinelle [amd64] (groovy-proposed/universe) [1.0.8.deb-2] (no packageset)
<Eickmeyer> sil2100: Got time for an SRU today before you EOD? bug 1877806
<ubot5> bug 1877806 in ardour (Ubuntu Focal) "[SRU] ardour crashes when saving lv2 plugin preset - bug discovered in lilv" [Undecided,Triaged] https://launchpad.net/bugs/1877806
-queuebot:#ubuntu-release- New binary: llvm-toolchain-10 [s390x] (bionic-proposed/universe) [1:10.0.0-4ubuntu1~18.04.1] (no packageset)
<sil2100> Eickmeyer: sure o/
<sil2100> Looking
<Eickmeyer> sil2100: Heh, fixed a typo in [Impact] just now.
<sil2100> Eickmeyer: so this only requires a fix in lilv, not in ardour, right? Could we mark it Invalid if that's the case?
<Eickmeyer> Correct.
<Eickmeyer> Done.
-queuebot:#ubuntu-release- New: accepted coccinelle [amd64] (groovy-proposed) [1.0.8.deb-2]
-queuebot:#ubuntu-release- New: accepted xmds2 [amd64] (groovy-proposed) [3.0.0+dfsg-3]
<sil2100> Eickmeyer: thanks o/
<sil2100> Oh damn, that's a lot of patches!
<Eickmeyer> sil2100: Indeed. Each one is a cherry-picked commit in order to get to the correct one.
<Eickmeyer> Obviously already in the version in Groovy, but for Focal this required patching gymnastics.
<Eickmeyer> sil2100: The main patch is 0007, but looks like 0008-0012 are code-cleanup for that one patch.
<Eickmeyer> 0002-0006 are just the commits leading up to that.
<sil2100> Ah, I see, so 0007-Fix-deleting-state-bundles-loaded-from-the-model.patch is the actual fix - patches before are all needed for the patch to be applicable + the patches after it are fixes for issues introduced with that commit, correct?
<Eickmeyer> sil2100: In essence, you read my mind (what I was just explaining). :D
<Eickmeyer> Patch 1001 is pre-existing.
-queuebot:#ubuntu-release- Unapproved: accepted lilv [source] (focal-proposed) [0.24.6-1ubuntu0.1]
<Eickmeyer> sil2100: ta
<xnox> sil2100:  vorlon: apw: can you please approve s390-tools signed build in groovy?
<xnox> (blocking systemd autopkgtests, blocking busybox, blocking casper work for .1 release)
<xnox> https://launchpad.net/ubuntu/groovy/+queue?queue_state=1&queue_text=
<vorlon> done
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [s390x] (groovy-proposed) [2.12.0-0ubuntu4]
<vorlon> ahasenack: please commit your debian-installer upload to the VCS
<vorlon> ahasenack: (also it seems to have somehow not rebuilt correctly against current bind9-libs, since it migrated to the release pocket and bind9-libs is still stalled)
<ahasenack> vorlon: you mean the pastebin/patch I posted here a few days ago?
<ahasenack> about switching from focal to groovy?
<ahasenack> vorlon: that's why I think it still used the old bind9-libs
<vorlon> ahasenack: well for the upload I mean 615 which is in groovy but not in bzr
<vorlon> ahasenack: as for the cause of the misbuild, I missed that
<ahasenack> vorlon: oh, bzr
<ahasenack> vorlon: xnox said if I "fixed" that, it would entangle with the kernel
<ahasenack> and he would take a look at it
<vorlon> hmm
<ahasenack> vorlon: https://irclogs.ubuntu.com/2020/05/20/%23ubuntu-devel.html#t12:52
<vorlon> xnox: ^^ should really jfdi, yes it entangles the kernel but it needs doing anyway if there's a new kernel in -proposed, and there shouldn't be any other library transitions right now
<ahasenack> (bzr is still branching d-i here)
<xnox> ahasenack:  yeah your no-change upload, really did a no-change rebuild without using any groovy =)
<xnox> vorlon:  fair.
 * xnox hoped to rip out d-i by now
<ahasenack> should d-i be added to some sort of post-release checklist, so that it points at the new name?
<vorlon> xnox: or that ;)
<xnox> ahasenack:  it was meant to be dead for 8 months now!
<ahasenack> you know what they say about undeads and zombies...
<xnox> it's a 7 degree spectrum of deadness?
<ahasenack> they keep making comebacks in the movies at least
<ahasenack> fascinating topic
<ahasenack> xnox: will you also update the bzr branch then, that I missed?
<xnox> ahasenack:  yeah, let me do it all
<ahasenack> thank you so much, will offer you rice and beans the next time you are in Brazil
<ahasenack> or a churrasco
<ahasenack> whichever you prefer
-queuebot:#ubuntu-release- New binary: llvm-toolchain-10 [ppc64el] (bionic-proposed/universe) [1:10.0.0-4ubuntu1~18.04.1] (no packageset)
<sbeattie> hi, can I get an SRU team yay or nay on LP: #1878654 ?
<ubot5> Launchpad bug 1878654 in gce-compute-image-packages (Ubuntu Focal) "Remove automatically added groups from os-login" [Undecided,New] https://launchpad.net/bugs/1878654
<sbeattie> They are not in the normal unapproved proposed queue, because they may get pocket-copied to the security pockets from updates, so they've been built in the ubuntu-security-proposed ppa.
<mclemenceau> hey vorlon I think that thanks to waveform we have a fix for python-meshio proposed-migration on groovy with s390x
<vorlon> sweet
<vorlon> sbeattie: why is this a 'maybe' for security?
-queuebot:#ubuntu-release- New binary: llvm-toolchain-10 [i386] (bionic-proposed/universe) [1:10.0.0-4ubuntu1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-10 [amd64] (bionic-proposed/universe) [1:10.0.0-4ubuntu1~18.04.1] (no packageset)
<xnox> ahasenack:  uploaded d-i, hopefully it will migrate
<ahasenack> xnox: thanks, I'll keep an eye on it
<ahasenack> xnox: was it accepted? https://launchpad.net/ubuntu/+source/debian-installer/20101020ubuntu616 is still a 404
<xnox> it's building https://launchpad.net/ubuntu/+source/debian-installer/20101020ubuntu617
<xnox> i tagged and pushed 616, only to notice ftbfs, so burned a version number.
<xnox> i should be the last d-i upload ever
<ahasenack> \o/
<ahasenack> xnox: d-i grabbed old bind9-libs again, didn't you have to change focal to groovy in ./build/config/common and ./debian/rules ?
<xnox> ahasenack:  yes.... it did.... and i don't care..... =)
<xnox> ahasenack:  i made an evil upload, yet everything should migrate
<ahasenack> ok
<ahasenack> "Do not generate meta-package which blocks package transitions,"
<sbeattie> vorlon: realistically, it will go eventually to security, but the reporters and people driving the issue want it to land in -updates and be available in gce before a security advisory is announced.
<vorlon> sbeattie: ok; ack then
<sbeattie> vorlon: thank you!
<vorlon> tumbleweed: your commit to reorder i386 hints appears to have dropped some (e.g. deap)
<vorlon> tumbleweed: and some of these seem like they should've still been detected as part of the grep-dctrl... (bzr-git, dirspec)
<vorlon> tumbleweed: ah bzr-git and dirspec both no longer have a Testsuite declared so that's fine, and deap went from Arch: all to Arch: any all so that's also expected
<vorlon> tumbleweed: but it looks like you didn't have multiverse enabled when you ran the script :)
<vorlon> tumbleweed: nah scratch that, doc-rfc is there but was in a different order than I expected
<tumbleweed> :)
<tumbleweed> I did vet it fairly carefully
<tumbleweed> the things that dropped seemed legit. But yes, some did
<tumbleweed> I also included proposed, which the original didn't
<vorlon> tumbleweed: yeah I've changed the script now to force LANG=C collation order so that everyone updating in the future gets the same results
<xnox> ahayzen:  d-i & bind9-libs migrated
<tumbleweed> may be a good idea to put generated things like that in separate files, so people den't mess wit them
<tumbleweed> (and rather refresh wholesale)
<vorlon> could wrap it in a sed command now that you have begin/end tags :)
-queuebot:#ubuntu-release- New binary: nix [s390x] (groovy-proposed/universe) [2.3.4+dfsg3-1] (no packageset)
<tumbleweed> :)
<ahayzen> xnox, think you tagged the wrong person :-)
<vorlon> creating separate files requires fiddling with britney config so I'm not keen
<vorlon> ahayzen: yeah, ahasenack trickily left the channel
<xnox> bah
<ahayzen> :-)
-queuebot:#ubuntu-release- New: accepted nix [s390x] (groovy-proposed) [2.3.4+dfsg3-1]
<xnox> apw:  can you please unblock 5.4.0-29.33 (yes that old) from groovy-proposed, such that it migrates in groovy?
<xnox> apw:  and then copy up focal-updates to groovy-proposed? (the 31.35)
<xnox> apw:  unless you want to go straight to 32.36 in groovy-proposed too?
-queuebot:#ubuntu-release- New binary: fonts-cherrybomb [amd64] (groovy-proposed/universe) [3.00+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: re2 [s390x] (groovy-proposed/main) [20200501+dfsg-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: nix [ppc64el] (groovy-proposed/universe) [2.3.4+dfsg3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: re2 [amd64] (groovy-proposed/main) [20200501+dfsg-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: nix [amd64] (groovy-proposed/universe) [2.3.4+dfsg3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: re2 [ppc64el] (groovy-proposed/main) [20200501+dfsg-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: re2 [arm64] (groovy-proposed/main) [20200501+dfsg-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New: accepted re2 [arm64] (groovy-proposed) [20200501+dfsg-2]
-queuebot:#ubuntu-release- New: accepted re2 [ppc64el] (groovy-proposed) [20200501+dfsg-2]
-queuebot:#ubuntu-release- New: accepted fonts-cherrybomb [amd64] (groovy-proposed) [3.00+dfsg-1]
-queuebot:#ubuntu-release- New: accepted nix [ppc64el] (groovy-proposed) [2.3.4+dfsg3-1]
-queuebot:#ubuntu-release- New: accepted re2 [s390x] (groovy-proposed) [20200501+dfsg-2]
-queuebot:#ubuntu-release- New: accepted nix [amd64] (groovy-proposed) [2.3.4+dfsg3-1]
-queuebot:#ubuntu-release- New: accepted re2 [amd64] (groovy-proposed) [20200501+dfsg-2]
#ubuntu-release 2020-05-22
-queuebot:#ubuntu-release- Unapproved: golang-1.14 (focal-proposed/main) [1.14.2-1ubuntu1 => 1.14.3-2ubuntu1~20.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: picolibc [amd64] (groovy-proposed/universe) [1.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-10 [armhf] (bionic-proposed/universe) [1:10.0.0-4ubuntu1~18.04.1] (no packageset)
<LocutusOfBorg> sil2100, automake-1.15 switched to python3, I'm going to sync it
<LocutusOfBorg> also doing automake-1.16 ( seb128 doko ) (trying to sync and preparing a merge in case armhf is still sad)
<seb128> LocutusOfBorg, get the merge ready now I think :)
<sil2100> LocutusOfBorg: thanks!
<LocutusOfBorg> seb128, its already ready to go :)
<LocutusOfBorg> the reason for the sync, is to keep a history of armhf failures in LP
-queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (focal-proposed) [1:13.99.1-1ubuntu3.3]
<LocutusOfBorg> since azure-cli regressed autopkgtests in release https://autopkgtest.ubuntu.com/packages/azure-cli/groovy/amd64 can we please get an hint?
<LocutusOfBorg> also regressed in Debian FWIW
-queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (bionic-proposed) [1:11.1-1ubuntu7.8]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-desktop-icons [source] (focal-proposed) [20.04.0-2~ubuntu20.04.1]
<rbasak> coreycb: I don't see anything waiting in the queue for bug 1877642. Is that correct?
<ubot5> bug 1877642 in vmware-nsx (Ubuntu Focal) "[SRU] OpenStack Ussuri final release" [High,Triaged] https://launchpad.net/bugs/1877642
-queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (focal-proposed) [1.22.10-1ubuntu2.1]
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-55.49] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-55.49] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.3.0-55.49] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-55.49] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.3.0-55.49]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.3.0-55.49]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.3.0-55.49]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (eoan-proposed) [5.3.0-55.49]
<jdstrand> can someone take a look at the apparmor in focal unapproved? it fixes bug #1872564 which has quite a few dupes
<ubot5> bug 1872564 in apparmor (Ubuntu Focal) "/proc/sys/kernel/random/boot_id rule missing from abstractions/nameservice" [Undecided,In progress] https://launchpad.net/bugs/1872564
<jdstrand> cc sergiodj ^
<tjaalton> jdstrand: accepted
-queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (focal-proposed) [2.13.3-7ubuntu5.1]
<jdstrand> tjaalton: thanks!
<jdstrand> sergiodj: you can do sru verification now
<jdstrand> sergiodj: well, when it finishes building of course :)
<LocutusOfBorg> hello vorlon, please NBS-proposed cleanup missing build on amd64: golang-go.net-dev (from 1:0.0+git20190811.74dc4d7+dfsg-1)
<LocutusOfBorg>  ?
-queuebot:#ubuntu-release- New binary: golang-github-containers-buildah [s390x] (groovy-proposed/universe) [1.11.6-1ubuntu5] (no packageset)
-queuebot:#ubuntu-release- New: accepted picolibc [amd64] (groovy-proposed) [1.4.2-2]
-queuebot:#ubuntu-release- New binary: golang-github-containers-buildah [ppc64el] (groovy-proposed/universe) [1.11.6-1ubuntu5] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-containers-buildah [amd64] (groovy-proposed/universe) [1.11.6-1ubuntu5] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-containers-buildah [arm64] (groovy-proposed/universe) [1.11.6-1ubuntu5] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-containers-buildah [armhf] (groovy-proposed/universe) [1.11.6-1ubuntu5] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-containers-buildah [riscv64] (groovy-proposed/universe) [1.11.6-1ubuntu5] (no packageset)
<RikMills> vorlon & tumbleweed: could we roll back QtWebEngine in proposed to 5.14.2+dfsg-1? The current ongoing rebuild is going to entangle the re2 and perl transition with the ongoing Qt one, if I read excuses correctly
<RikMills> that is it even builds, which is not certain at the moment
<ahasenack> xnox: hi, sg3-utils is also producing a udeb package. In fact, debian dropped it, but it's our delta
<ahasenack> xnox: do your recent d-i changes mean we can drop this udeb?
<coreycb> rbasak: that's correct, there's nothing left in the queue. thanks for checking!
<xnox> ahasenack:  no, you still need that at the moment
<ahasenack> ok
<ahasenack> sadface
<xnox> ahasenack:  inspecting http://archive.ubuntu.com/ubuntu/ubuntu/dists/focal/main/debian-installer/binary-amd64/Packages.gz
<xnox> you can see that multipath-udeb depends on sg3-udeb, meaning multipath-udeb will become "uninstallable" and thus hold things up
<ahasenack> but if we are no longer going to build d-i, why do we still need all these udebs?
<xnox> either we need to make britney not care about udeb installability, or like make launchpad to build everything with noudeb build profile
<xnox> ahasenack:  because we need to unwind them in an orderly fashion, and we have not yet done that work =)
<ahasenack> ah, ok
<ahasenack> their days are numbered then
<xnox> and one needs to like remove leave udebs first, or like all of them together, something like that
<juliank> xnox: or we just remove them from the archive and ignore them on uploads :)
<xnox> juliank:  yeah, that, too. but i guess lp change too?
<juliank> either a tiny LP change or just strip them from .changes automatically before uploading
<juliank> :D
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (focal-proposed/main) [5.4.0-33.37] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (focal-proposed/main) [5.4.0-33.37] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (focal-proposed/main) [5.4.0-33.37] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (focal-proposed/main) [5.4.0-33.37] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (focal-proposed) [5.4.0-33.37]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (focal-proposed) [5.4.0-33.37]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (focal-proposed) [5.4.0-33.37]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (focal-proposed) [5.4.0-33.37]
<sergiodj> jdstrand: thanks.  I'll wait for simon to do the verification.  if we don't see anything until the end of the day, I'll do it myself
<jdstrand> sergiodj: cool, thanks! I suspect he will jump on it. you might wait til Monday to give him a chance to do it over the weekend
<sergiodj> jdstrand: awesome, will do :)
<jdstrand> sergiodj: it needs to sit in proposed for a week any way :)
<tumbleweed> RikMills: I'd expect the re2 transition to sail through. But, ah I hadn't realised that I'd be entangling perl too. Duh.
<tumbleweed> no objection for me, if you can get qt through
-queuebot:#ubuntu-release- New binary: bind9 [s390x] (groovy-proposed/main) [1:9.16.2-3ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: bind9 [i386] (groovy-proposed/main) [1:9.16.2-3ubuntu1] (core, i386-whitelist)
<RikMills> tumbleweed: thanks. I'll see what vorlon thinks this evening
-queuebot:#ubuntu-release- New binary: bind9 [ppc64el] (groovy-proposed/main) [1:9.16.2-3ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: bind9 [amd64] (groovy-proposed/main) [1:9.16.2-3ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: bind9 [arm64] (groovy-proposed/main) [1:9.16.2-3ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: bind9 [armhf] (groovy-proposed/main) [1:9.16.2-3ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1060.63] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1040.44~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-4.15 [amd64] (bionic-proposed/universe) [4.15.0-1072.82] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1038.39] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-4.15 [amd64] (bionic-proposed) [4.15.0-1072.82]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1038.39]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1060.63]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1040.44~16.04.1]
-queuebot:#ubuntu-release- Packageset: Added qt5-ukui-platformtheme to ubuntukylin in bionic
-queuebot:#ubuntu-release- Packageset: Added ukui-sidebar to ubuntukylin in eoan
-queuebot:#ubuntu-release- Packageset: Added qt5-ukui-platformtheme to ubuntukylin in focal
-queuebot:#ubuntu-release- Packageset: Added ukui-sidebar to ubuntukylin in groovy
-queuebot:#ubuntu-release- Packageset: Added qt5-ukui-platformtheme to ubuntukylin in eoan
-queuebot:#ubuntu-release- Packageset: Added ukui-sidebar to ubuntukylin in focal
-queuebot:#ubuntu-release- Packageset: Added ukui-sidebar to ubuntukylin in bionic
-queuebot:#ubuntu-release- Packageset: Added qt5-ukui-platformtheme to ubuntukylin in groovy
-queuebot:#ubuntu-release- New binary: bind9 [riscv64] (groovy-proposed/main) [1:9.16.2-3ubuntu1] (core, i386-whitelist)
<ahasenack> ubuntu-archive: hello, bind9 has a new bind9-dev binary
<rbalint> ubuntu-archive please check https://code.launchpad.net/~rbalint/ubuntu-archive-tools/bzr-to-git/+merge/384436
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1040.44] (kernel)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (focal-proposed/main) [2.664.1 => 2.664.2] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1040.44]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (eoan-proposed/main) [2.620.2 => 2.620.3] (desktop-core)
-queuebot:#ubuntu-release- New: accepted golang-github-containers-buildah [amd64] (groovy-proposed) [1.11.6-1ubuntu5]
-queuebot:#ubuntu-release- New: accepted golang-github-containers-buildah [armhf] (groovy-proposed) [1.11.6-1ubuntu5]
-queuebot:#ubuntu-release- New: accepted golang-github-containers-buildah [riscv64] (groovy-proposed) [1.11.6-1ubuntu5]
-queuebot:#ubuntu-release- New: accepted golang-github-containers-buildah [arm64] (groovy-proposed) [1.11.6-1ubuntu5]
-queuebot:#ubuntu-release- New: accepted golang-github-containers-buildah [s390x] (groovy-proposed) [1.11.6-1ubuntu5]
-queuebot:#ubuntu-release- New: accepted golang-github-containers-buildah [ppc64el] (groovy-proposed) [1.11.6-1ubuntu5]
-queuebot:#ubuntu-release- New: accepted bind9 [amd64] (groovy-proposed) [1:9.16.2-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted bind9 [ppc64el] (groovy-proposed) [1:9.16.2-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted bind9 [i386] (groovy-proposed) [1:9.16.2-3ubuntu1]
<ahasenack> thanks! ^
-queuebot:#ubuntu-release- New: accepted bind9 [s390x] (groovy-proposed) [1:9.16.2-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted bind9 [arm64] (groovy-proposed) [1:9.16.2-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted bind9 [riscv64] (groovy-proposed) [1:9.16.2-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted bind9 [armhf] (groovy-proposed) [1:9.16.2-3ubuntu1]
<vorlon> sil2100: question on LP: #1875485 for you
<ubot5> Launchpad bug 1875485 in python-botocore (Ubuntu Focal) "[SRU] python-botocore out of date" [Undecided,New] https://launchpad.net/bugs/1875485
-queuebot:#ubuntu-release- Unapproved: accepted python-botocore [source] (focal-proposed) [1.15.46+repack-1ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected awscli [source] (focal-proposed) [1.18.46-1ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected awscli [source] (eoan-proposed) [1.18.46-1ubuntu0.19.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected awscli [source] (eoan-proposed) [1.18.46-1ubuntu0.19.10.1]
<RikMills> vorlon: can we roll back qtwebengine, or do we accept that the re2 and perl transition will entangle with the Qt one?
<vorlon> sil2100: hmm I see that on versions prior to eoan, awscli was uploaded to depend on python3-botocore (>= 1.12.103), but the version mentioned in the bug as required is 1.15.47... which is correct? setup.cfg says botocore==1.15.46
<vorlon> doko: you say you uploaded probert for pyflakes removal; did you send the changes to the Server Team? (LP: #1879731)
<ubot5> Launchpad bug 1879731 in probert (Ubuntu) "probert build-depends on obsolete pyflakes package" [High,New] https://launchpad.net/bugs/1879731
-queuebot:#ubuntu-release- Unapproved: rejected awscli [source] (bionic-proposed) [1.18.46-1ubuntu0.18.04.1]
<vorlon> tumbleweed: ^^ see RikMills comment above, if packages are already in -proposed as part of other transitions please check with folks before uploading
<vorlon> RikMills: IIRC qtwebengine takes quite a while to build, so I should probably let it finish before deciding whether to remove anything
<vorlon> RikMills: and this does not necessarily slow down the qt transition, which is still waiting for test results on a number of dependent packages
-queuebot:#ubuntu-release- Unapproved: rejected awscli [source] (xenial-proposed) [1.18.46-1ubuntu0.16.04.1]
<RikMills> vorlon: no problem. webengine can sometimes take ~24hrs on arm64, sometimes less
-queuebot:#ubuntu-release- Packageset: Added libnamespace-autoclean-perl to i386-whitelist in groovy
<tumbleweed> yeah, I didn't expect Qt to migrate before I got this ready
<tumbleweed> But I wasn't expecting perl to be caught up (I'm less familiar with their dependencies). That seems like a problem
<RikMills> tumbleweed: the rdeps test of the entangling re2 rebuild look a bit angry (red)
<RikMills> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libre-engine-re2-perl
<tumbleweed> yeah, I see those. I'll dig into them
<RikMills> autodep8-perl-build-deps FAIL
<RikMills> perl itself had broken tests for 4 or 5 packages, so that is not a valid candidate soon :/
<tumbleweed> indeed. I've been picking some of them off
<RikMills> then again, Qt transition is already blocked on the hdf5/proj/etc one, so not as if that will be ok soon either
<vorlon> xnox: what do you want to have happen with https://code.launchpad.net/~xnox/ubuntu-archive-tools/built-using/+merge/308697 ? you had reviewed it needs-fixing yourself
<vorlon> I'm not sure if you currently believe this dtrt or not, or what was in the "too much stuff" you said infinity said it was promoting
<xnox> vorlon:  my comment from 2018 went un-answered
<xnox> vorlon:  i think we merge something, but not it, and the current reports are still confusing
<vorlon> xnox: because I don't understand that comment, and it didn't change your own review status
<xnox> vorlon:  i.e. do you have something today that is blocked on built-using MIR in components-missmatches and is it hard to tell why?
<vorlon> xnox: I thought the issue is that today, things that are in built-using for main are NOT listed in c-m?
<vorlon> so we aren't promoting them but are meant to
<xnox> hm
<xnox> vorlon:  and i can't run components-missmatches report
<xnox> because i do not have any ssh access to any machine with unsplit mirror
<xnox> and all of these reports cannot work against split mirrors
<xnox> or like against apt sources, that have all arches enabled and have things in /var/lib/apt/lists/
<xnox> vorlon:  give me shell access to snakefruit, and let me have RO access to the unsplit mirror, and i can poke it
<xnox> vorlon:  i think most of this fell out of concern when we stopped doing static linkin of prebuilt golang stuff?
<xnox> since 2016 my hacked up version of things is gone
<vorlon> that's not a reason for getting shell access to snakefruit :)
<xnox> vorlon:  i need access to unsplit mirror
<xnox> vorlon:  how can i have it?
<xnox> vorlon:  all of you have it, but me. cause i don't have shell on snakefruit, nor nusakan, and there is no other machine with unsplit mirror available.
<vorlon> xnox: doesn't canonistack give access to ftpmaster.internal?
<xnox> over the network
<xnox> not locally mounted
<xnox> and all of this stuff access things not over the network, but via file access
<xnox> vorlon:  can i nfs mount ftpmaster.internal?
<vorlon> I don't believe so
<xnox> so i should go and create one more local copy of ftpmaster.internal on people.canonical.com?
<vorlon> obviously not
<xnox> i think before snakefruit, it was available to everyone on people.canonical.com because ~ubuntu-archive was there too
<vorlon> but you could launch a large instance, rsync it, do what you need to do
<xnox> and then terminate
<xnox> is it reasonable to make our tools not use RAW unsplit mirror?
<vorlon> do you even need access to the pool or just dists?
<xnox> i.e. port the reports to use chdist which enables ports & archive, and apt-get updates all the things?
<vorlon> $ for src in $(grep-dctrl -n -sBuilt-Using -FBuilt-Using -r . /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_focal_main_*amd64_Packages | sed -e's/ ([^)]*)//g; s/, */\n/g'| sort -u); do rmadison -s focal -a source $src | grep /; done
<xnox> vorlon:  most of the reports only ever need dists, or just a subset of files.
<vorlon>  unicode-data | 13.0.0-2build1 | focal/universe | source
<vorlon> $
<vorlon> so focal has one B-U-based component mismatch that we didn't know about
<xnox> yet somehow they operate against full raw mirrors, for no reason
<xnox> which was there since 2016 and we knew about ;-)
<xnox> https://people.canonical.com/~xnox/germinate-output/builtusing/components-missmatches.svg
<xnox> cuase it's up there
<xnox> also ubuntu-push (but that is dead now, irght?)
<xnox> unicode-data: unicode-data
<xnox> MIR: #1194070 (Fix Released)
<xnox> [Reverse-Built-Using: libgucharmap-2-90-7 (MAIN)]
<xnox> vorlon:  i think we can just promote that one thing and forget about all of this?
<vorlon> nusakan uses the pool.  snakefruit, I don't think mirrors anything but dists.  it's not that difficult to just rsync dists from both sources for local operations, or from ftpmaster.internal if on the Canonical network.  A wrapper script to do that would be reasonable.
<vorlon> xnox: that doesn't help us for future mismatches that get overlooked
<vorlon> the scripts don't implement the policy
<vorlon> heh, nusakan has an apt-mirror directory with 109G in dists, none of it newer than yakkety
<vorlon> super effective
<xnox> yes
<xnox> maybe we can purge that
<vorlon> 9.6G	apt-mirror/dists/ci-train-ppa-service
<xnox> or like use rsync-fuse fs to just "mount" ftpmaster.internal
<xnox> most of the time, we just access the same 100-300 .debs that are in the pool
<xnox> on isos
<xnox> and not all of it
<vorlon> oops, I said nusakan above and I meant snakefruit
<vorlon> *snakefruit* has 109G of garbage
<xnox> vorlon:  is there rsync from ftpmaster.internal? from people.canonical.com rsync ftpmaster.internal is nothing
<xnox> vorlon:  what is the anonftp settings on nusakan?
<vorlon> yes, there is; nusakan uses rsync.  I wouldn't think that's restricted
<xnox> module name or something?
<vorlon> ah it uses a password
<vorlon> so apparently restricted
<xnox> so yeah, that's my problem is that i cannot mirror or access mounted ftpmaster.internal
<xnox> and all of you, brush it off, as if it is available, when it is not
<vorlon> can't mirror with rsync.  can trivially do so with wget
<xnox> no, one cannot trivially mirror with wget
<xnox> because _nothing_ does it like that
<vorlon> nusakan needs rsync because it needs the pool
<vorlon> you don't need the pool for germinate work
<xnox> good luck trying to build ubuntu-cdimage/debian-cd images for amd64 & arm64 simultaniously with split rsyncs
<vorlon> look, I'm aware that this sucks for doing debian-cd work
<xnox> to do any debian-cd / ubuntu-cdimage work, i have a a massive patch to skip building pool and downloading artefacts
<vorlon> that's just one reason why I'd like to get rid of debian-cd from the toolchain
<vorlon> but we were talking about ubuntu-archive-tools
<xnox> right
<xnox> and that wants a consistent multiarch view of the archive
<vorlon> and you're rejecting the practical workarounds that I'm offering
<vorlon> mirroring dists is not hard
<xnox> which is?
<xnox> use wget on people.canonical.com?
<vorlon> sure
<xnox> about cdimage
<xnox> why does it publish a full tree as a thing that frontends rsync
<xnox> instead of like publishing all of that into a swift bucket?
<xnox> and then just let swift serve the bucket publically?
<xnox> is it because we rely on apache serving those dirs with httpaccess & HEADER.html stuff?
<vorlon> because it predates swift :P
<xnox> can we pre-render those htmls too?
<xnox> to have it a static content thing?
<xnox> vorlon:  the problem i have with wget, is that it has no idea what symlinks are
<xnox> and /ubuntu/ubuntu/ubuntu is aweful
<vorlon> heh
<cjwatson> the HEADER.html stuff was initially because it was shell and doing all the directory listing stuff was too much of a pain.  I'm sure it could pre-render index.html nowadays instead if somebody cared to do the work
<vorlon> but that's outside of dists
<cjwatson> and for releases.u.c, rsync and mirroring are pretty essential
<xnox> vorlon:  yes, and all the current/ symlinks under http://archive.ubuntu.com/ubuntu/dists/focal/main/
<xnox> are not fun to download over and over again
<xnox> cjwatson:  hm..... indeed. instead of generating HEADER.html it could spit out the full index.html
<vorlon> I'm pretty sure you or I could have had the whole thing downloaded, duplicate contents included, in the time we've spent talking about this :)
<vorlon> (and on that note, afk)
<LocutusOfBorg> please archive admins NBS cleanup golang-go.net-dev
<cjwatson> PS ftpmaster.internal::ubuntu-dists/ is rsyncable from lillypilly
<cjwatson> xnox: ^-
<cjwatson> That is the same thing that snakefruit rsyncs
<cjwatson> (And yes, possibly a bit historical because ~ubuntu-archive used to be there; but nevertheless, it works, and as long as staff aren't ridiculously abusing it to the point where ftpmaster stops performing reasonably, there's no particular reason to remove it)
<xnox> cjwatson:  thank you. I've asked vorlon which modules are available to rsync (because doing rsync ftpmaster.internal:: says nothing) and vorlon didn't know
<xnox> cjwatson:  this is amazing!
<cjwatson> lillypilly has access to ubuntu-dists and ubuntu-germinate
<xnox> cjwatson:  what is ubuntu-germinate?
<xnox> (germinate output as produced by lp publication stuff?)
<cjwatson> That
<cjwatson> Used by some of the archive reports
<xnox> tah
-queuebot:#ubuntu-release- New binary: skopeo [amd64] (groovy-proposed/universe) [0.1.40-2] (no packageset)
-queuebot:#ubuntu-release- New binary: skopeo [s390x] (groovy-proposed/universe) [0.1.40-2] (no packageset)
-queuebot:#ubuntu-release- New binary: skopeo [ppc64el] (groovy-proposed/universe) [0.1.40-2] (no packageset)
-queuebot:#ubuntu-release- New binary: skopeo [arm64] (groovy-proposed/universe) [0.1.40-2] (no packageset)
-queuebot:#ubuntu-release- New binary: skopeo [armhf] (groovy-proposed/universe) [0.1.40-2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1072.82~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1072.82~16.04.1]
-queuebot:#ubuntu-release- New binary: skopeo [riscv64] (groovy-proposed/universe) [0.1.40-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted skopeo [amd64] (groovy-proposed) [0.1.40-2]
-queuebot:#ubuntu-release- New: accepted skopeo [armhf] (groovy-proposed) [0.1.40-2]
-queuebot:#ubuntu-release- New: accepted skopeo [riscv64] (groovy-proposed) [0.1.40-2]
-queuebot:#ubuntu-release- New: accepted skopeo [arm64] (groovy-proposed) [0.1.40-2]
-queuebot:#ubuntu-release- New: accepted skopeo [s390x] (groovy-proposed) [0.1.40-2]
-queuebot:#ubuntu-release- New: accepted skopeo [ppc64el] (groovy-proposed) [0.1.40-2]
<vorlon> LocutusOfBorg: golang-go.net-dev> done
-queuebot:#ubuntu-release- Unapproved: accepted php7.4 [source] (focal-proposed) [7.4.3-4ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted php7.3 [source] (eoan-proposed) [7.3.11-0ubuntu0.19.10.5]
-queuebot:#ubuntu-release- Unapproved: accepted php7.2 [source] (bionic-proposed) [7.2.24-0ubuntu0.18.04.5]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-desktop3 [source] (focal-proposed) [3.36.2-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected simple-scan [source] (focal-proposed) [3.36.2.1-0ubuntu0.20.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (focal-proposed) [2.0.874-7.1ubuntu6.1]
<vorlon> rafaeldtinoco: hi, it's unclear to me why you've set the block-proposed-focal tag on LP: #1877617 in addition to block-proposed-groovy, can you explain?
<ubot5> Launchpad bug 1877617 in open-iscsi (Ubuntu Eoan) "Automatic scans cause instability for cloud use cases" [Medium,In progress] https://launchpad.net/bugs/1877617
<vorlon> rafaeldtinoco: (considering it's been uploaded for multiple series and focal is the only stable series that has the block tag set)
-queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (eoan-proposed) [2.0.874-7.1ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (bionic-proposed) [2.0.874-5ubuntu2.10]
-queuebot:#ubuntu-release- Unapproved: accepted gamemode [source] (focal-proposed) [1.5.1-0ubuntu3.1]
-queuebot:#ubuntu-release- New binary: pspp [s390x] (groovy-proposed/none) [1.2.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde-service-urlshortener [amd64] (groovy-proposed/none) [2.0.3-5] (no packageset)
-queuebot:#ubuntu-release- New binary: pspp [amd64] (groovy-proposed/universe) [1.2.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: pspp [arm64] (groovy-proposed/universe) [1.2.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: pspp [armhf] (groovy-proposed/universe) [1.2.0-4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted maas [source] (focal-proposed) [1:0.7]
<rafaeldtinoco> vorlon: I should have removed that tag now, my mistake
<rafaeldtinoco> sorry about that
<vorlon> rafaeldtinoco: ok
#ubuntu-release 2020-05-23
-queuebot:#ubuntu-release- Unapproved: accepted libproxy [source] (focal-proposed) [0.4.15-10ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted adwaita-icon-theme [source] (focal-proposed) [3.36.1-2ubuntu0.20.04.2]
<vorlon> oh lovely, why does libfile-desktopentry-perl want us to pick up a completely different implementation of x-terminal-emulator into main
<xnox> because we try to satisfy x-terminal-emulator on i386 without considering amd64 providers of x-terminal-emulator
<xnox> we need a fake-provides x-terminal-emulator on i386
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-102.103~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-102.103~16.04.1] (kernel)
<locutus_> vorlon, looks like the golang hammer deleted too much? golang-golang-x-net-dev has no binaries on any arch :)
<locutus_> I uploaded a no change rebuild :)
<locutus_> oh its fine, the decruft made golang-golang-x-net migrate, with the same binary name
<locutus_> wgrant, would you mind setting parallel for riscv64 back to 4 instead of 8? I would like to understand if cpl-plugin-naco is sad because of it or not...
-queuebot:#ubuntu-release- Unapproved: plasma-nm (focal-proposed/universe) [4:5.18.4.1-0ubuntu1 => 4:5.18.4.1-0ubuntu1.1] (kubuntu)
-queuebot:#ubuntu-release- New binary: knockpy [amd64] (groovy-proposed/universe) [4.1.0-2] (no packageset)
<RikMills> vorlon: Qt looks ok now testwise. just the few entanglements (proj & re2 rdeps etc) that are not
<RikMills> for proj https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961211
<ubot5> Debian bug 961211 in src:r-cran-lwgeom "r-cran-lwgeom: autopkgtest failures on s390x" [Serious,Open]
 * RikMills goes in search of beer
<valorie> Qt drives RikMills to drink..... what's new!
-queuebot:#ubuntu-release- Packageset: Added materia-kde to ubuntustudio in groovy
-queuebot:#ubuntu-release- New binary: knockpy [amd64] (groovy-proposed/universe) [4.1.0-3] (no packageset)
#ubuntu-release 2020-05-24
-queuebot:#ubuntu-release- New binary: jinja-vanish [amd64] (groovy-proposed/universe) [0.2~git20160124.8980cb2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mailnag [amd64] (groovy-proposed/universe) [2.0.0-0.2] (no packageset)
-queuebot:#ubuntu-release- New binary: knockpy [amd64] (groovy-proposed/universe) [4.1.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-clipboard [amd64] (groovy-proposed/universe) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-clipboard [ppc64el] (groovy-proposed/universe) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-clipboard [s390x] (groovy-proposed/universe) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-clipboard [armhf] (groovy-proposed/universe) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-clipboard [arm64] (groovy-proposed/universe) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-clipboard [riscv64] (groovy-proposed/universe) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fsevent-sys [amd64] (groovy-proposed/none) [3.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fsevent-sys [s390x] (groovy-proposed/universe) [3.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ipnet [s390x] (groovy-proposed/universe) [2.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ipnet [amd64] (groovy-proposed/universe) [2.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pveclib [ppc64el] (groovy-proposed/universe) [1.0.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fsevent-sys [ppc64el] (groovy-proposed/universe) [3.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ipnet [ppc64el] (groovy-proposed/universe) [2.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fsevent-sys [armhf] (groovy-proposed/universe) [3.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ipnet [armhf] (groovy-proposed/universe) [2.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fsevent-sys [arm64] (groovy-proposed/universe) [3.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ipnet [arm64] (groovy-proposed/universe) [2.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fsevent-sys [riscv64] (groovy-proposed/universe) [3.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ipnet [riscv64] (groovy-proposed/universe) [2.2.0-1] (no packageset)
