#ubuntu-release 2010-06-07
<lamont> i386 ppa issue is being worked on, fyi
<lamont> there.  i386 ppas happy again
#ubuntu-release 2010-06-09
<slangasek> lamont: coreutils FTBFS on sparc,powerpc,armel trying to test linkat - do the buildds all have /proc mounted in the chroot?
<wgrant> slangasek: FWIW, lp-buildd mounts /proc in the chroot, so probably.
<slangasek> ok
<wgrant> And it's a proper -t proc mount.
 * slangasek nods
<lamont> slangasek: though it is a hardy kernel, which &*%^)^%*^*) better not matter
<slangasek> lamont: yeah, I think it's a strange regression in coreutils caused by an updated gnulib; I just don't get why it's only affecting some architectures
#ubuntu-release 2010-06-10
<lamont> slangasek: looking at build logs, wow.  I think I'll roll new maverick chroot tarballs tomorrow
<lamont> and pygobject vs sparc?  fail
 * lamont files a bug
<ScottK> lamont: Anything beyond saying "sparc" was redundant there.
<lamont> heh.
<lamont> ScottK: bug 591990
<ubot4> Launchpad bug 591990 in pygobject (Ubuntu) (and 1 other project) "pygobject hates sparc, kills it (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/591990
<ScottK> lamont: I think it's a mercy killing at this point.
<lamont> yeah, but I had to file the bug anyway, so I could kill it harder
<ScottK> ;-)
<slangasek> lamont: new chroot> was that in reference to the coreutils thing?
<slangasek> lamont: because I can reproduce this ad absurdum on armel here
<lamont> slangasek: nah - that was in reference to how big the dist-upgrade at the start of builds has grown - so new chroot tarballs coming today at some point
<slangasek> lamont: ah, ok
 * lamont wonders what context that was in
<slangasek> a chrooted context :)
<lamont> slangasek: ah.  so... if  you're around, wanna kick off a maverick livecd fs build on cardamom(i386) and kapok(amd64) to verify that you can trigger such things?
#ubuntu-release 2010-06-11
<lamont> slangasek: I kicked off test builds there myself directly on the machine, if you want to trigger one behind that to make sure triggers work,  I suspect we're about to tell you that those are your new machines
<lamont> and afk
<lamont> cjwatson: around?  could you kick off livecd builds on cardamom(i386) and kapok(amd64) from your end of the world, don't care what image, to confirm they will work for you (work for me, but then, I'm stepping into it in mid-process)
<lamont> if so, we can migrate to those.
<cjwatson> lamont: running
<lamont> cjwatson: thanks
<lamont>  /usr/sbin/livecd.sh: line 608: lzma: command not found <-- cjwatson: I assume we're gonna want that in the depends, yes?
 * lamont has another change to make to livecd-rootfs, too
<cjwatson> lamont: yeah, should be a dep
<cjwatson> sorry
<lamont> 1.119 uploaded
<lamont> and you'll want to switch to using cardamom/kapok for all your i386/amd64 livecd needs.  I think you'll like the even-without-tmpfs speeds
<cjwatson> switched
<cjwatson> (livefs build log mirroring too)
<lamont> thanks, and do scream if you find them lacking in anyway
<lamont> any way, too
<cjwatson> thans
<cjwatson> +k
#ubuntu-release 2010-06-12
<cjwatson> lamont: are the new livefs buildds auto-upgrading livecd-rootfs?  it's been nearly a day since you uploaded 1.119 and I'm still getting failures due to missing lzma - I had a feeling that they used to auto-upgrade overnight
#ubuntu-release 2010-06-13
<lamont> cjwatson: interestingly, both kapok and cardamom have 1.119
<cjwatson> they seem to have caught up now
<cjwatson> they had 1.118 when I said that
<cjwatson> if they've caught up by themselves, then I guess I was just too impatient
<lamont> ah, ok
<lamont> 02:15 london is when the job runs, though it does dist-upgrade several chroots...
<lamont> likewise, king and terranova have 1.119 now
#ubuntu-release 2011-06-06
<ScottK> Would someone please promote kaccessible?  It's a new binary from existing Main source that's needed to get the livefs on the DVD buildable.
<ScottK> (it was a bug we didn't include it last cycle)
<cjwatson> ScottK: kaccessible> done
<Laney> I'm getting a taste of how much fun the perl transition must have been :-)
<jibel> Ubuntu and Kubuntu Oneiric alpha 1 are not on http://releases.ubuntu.com/ , is it intentional or a known issue ?
<elmo> jibel: ... ?
<elmo> jibel: alpha's never go onto releases.ubuntu.com
<elmo> releases.ubuntu.com is for betas and actual releases only
<jibel> elmo, oh ok. http://cdimage.ubuntu.com/releases/oneiric/alpha-1/ is what I was looking for. I'll have more coffee. Thanks!
<ScottK> cjwatson: Thanks.
<cjwatson> Laney: yeah, tedious isn't it ...
<cjwatson> Laney: scoring some builds up for you
<Laney> thanks
<Laney> it was much better last night when the buildds were empty
<cjwatson> yeah, I was away yesterday so didn't run the autosync
<cjwatson> so it was a bit batched up
<ScottK> cjwatson: When you have a moment, would you point me to the final Kubuntu powerpc image for Natty?  We don't seem to have released it, but I've had requests.
<cjwatson> I kept a backup but I'm not sure if it's actually published anywhere right now
<cjwatson> I'll republish it somewhere in a bit and give you a link ...
<cjwatson> (it wasn't tested in time for natty; if it gets tested, we can amend the decision not to release it)
<ScottK> Thanks.
 * ScottK nods. 
<ScottK> We'll see what we can manage.
<cjwatson> Laney: pushing ghc a bit further up the hill with some rebuild uploads
<cjwatson> figure we could use the throughput
#ubuntu-release 2011-06-07
<Laney> cjwatson: was waiting for ppc
<Laney> but yes, I tend to agree
<palhmbs> hey is there any releaseteam members here?
<palhmbs> I want to know if ubuntu have a specific future Roadmap page that we can link to on --- >> https://help.launchpad.net/BlueprintRoadmaps
<palhmbs> cause currently it's just dumb to have a dead link
<palhmbs> the web shouldn't be _always_ broken
<palhmbs> if ubuntu don't have a roadmap blueprint, then maybe another blueprint roadmap should be set as the _example to all_
<slangasek> palhmbs: looks like poolie just deleted this page as obsolete?
<palhmbs> yup
<palhmbs> now launchpad can't try to palm that dead link off anyone anymore....
<palhmbs> s/off/off onto/
<palhmbs> slangasek, I was hoping for a good example of a well thought out roadmap, unfortunately it doesn't seem that Ubuntu can provide one....
<palhmbs> at least I can't find one.
<slangasek> that doesn't appear to be what that page was referring to
<slangasek> Ubuntu has things like https://wiki.ubuntu.com/UDSProceedings/O, but I'm not sure if that's what you're looking for
<palhmbs> we probably need to refer to an archived view of the original Ubuntu Roadmap
<palhmbs> I wonder if archives.org would have it
<slangasek> palhmbs: I don't understand what it is you're trying to achieve.  the page has (rightly) been deleted because the feature it documented is no longer part of launchpad.  Are you proposing to use help.launchpad.net to document examples of some other kind of roadmap not implemented in launchpad?
<palhmbs> https://launchpad.net/ubuntu/+roadmap -- was an example of a good roadmap
<palhmbs> I'm just suggesting that for people wanting to create their own blueprint _some_ example would be nice / helpful
<slangasek> that wasn't a pointer to a blueprint
<palhmbs> unfortunately I've just helped delete a page, which will probably make the web more broken / with dead links
<slangasek> it was a pointer to a blueprint *roadmap*, a feature which no longer exists in launchpad
<palhmbs> oh :-0 really?
<slangasek> yep
<slangasek> there are plenty of blueprints available in Ubuntu that could be used as examples, but that's not what that page was about :)
<slangasek> (blueprints are all via https://blueprints.launchpad.net/ubuntu/)
<palhmbs> right, I see
<palhmbs> oh well, hopefully this ends my wild goose chase
<palhmbs> I wanted to create a blueprint for a new project - something that's not possible currently
<palhmbs> how might I setup a new project so that I can write a blueprint for it?
<slangasek> #launchpad is a better place for such questions, but the link for registering a new project is on the launchpad frontpage - "register a project" :)
<palhmbs> slangasek, thanks
<cjwatson> Laney: are you sorting out the haxml build failure?
<Laney> cjwatson: it's building now? (from autosync)
<cjwatson> oh, so it is, fair point
<Laney> was waiting for that
<cjwatson> Laney: should I remove haskell-web-routes-quasi on powerpc, or is powerpc intended to get ghc-ghci at some point?
<Laney> cjwatson: OOD binaries?
<cjwatson> yeah
<Laney> see debian bug #629038 â it will arrive for ppc at some point
<ubot4> Debian bug 629038 in ghc "ghci available on sparc, should provide ghc-ghci" [Normal,Open] http://bugs.debian.org/629038
<cjwatson> libghc-web-routes-quasi-dev |  0.6.3.1-1 | oneiric/universe | powerpc
<cjwatson> libghc-web-routes-quasi-dev |  0.6.3.1-2 | oneiric/universe | amd64, i386
<cjwatson> ah
<Laney> but I wouldn't bank on it being before a new upstream of ghc
<Laney> which I have no appetite for putting in oneiric :-)
<cjwatson> well, right now, the web-routes-quasi powerpc binary is uninstallable and unbuildable
<cjwatson> (dep-wait)
<Laney> if there's a non-abi-breaking upload then I'll do that
<ScottK> Laney: geordi needs to be rebuilt for the boost transition, but it's also a ghc6 package.  Would you mind taking a look at it and updating it to libboost1.46-dev when it makes sense from a ghc perspective?
<Laney> right, killing it is correct then
<cjwatson> ok, will do that for now
<Laney> ScottK: looks rc buggy - do we still want it?
<ScottK> Laney: I don't have an opinion on it.  I just want to get rid of boost1.42.
<Laney> will look into killing it
<ScottK> It seems pretty dead in Debian, so removal is a reasonable choice.
<ScottK> Thanks.
<Laney> CCing you
<ScottK> Thanks.
#ubuntu-release 2011-06-08
<cjwatson> Laney: blimey, Clint is packaging a lot of stuff
<Laney> haha
<Laney> he was interested in getting hledger in, which apparently has a zillion rdepends
<cjwatson> 14 more packages through NEW (mostly Clint, I think one was by Joachim)
<Laney> bet the FTP team are having fun
<cjwatson> quite a bit of Ruby activity at the moment too
<ScottK> I'm a bit confused by today's Kubuntu CD health check.  It says the DVD failed because plasma-widget-lancelot in uninstallable.  It mentions 4:4.6.2-0ubuntu3 (kdeplasma-addons), which was uninstallable, but 4:4.6.3-1ubuntu1, which is installable was uploaded, built, etc on June 6.
<ScottK> Did the DVD livefs not get regenerated last nigh?
<cjwatson> DVDs only get built twice a week
<cjwatson> 47 20 * * 1,5   buildlive kubuntu-dvd dvd && for-project kubuntu cron.dvd
<cjwatson> so Monday and Friday in the case of Kubuntu
<ScottK> Thanks.  Didn't know that.
<ScottK> It should be good when it comes up again then.
<Laney> might update the ghc transition file to remove all ghc6 stuff
<Laney> then we should be able to sync haskell-dummy without it breaking
<cjwatson> NCommander,ogra_: do we still need the '/usr/lib/gdm/gdm-set-default-session unity-2d' hack in livecd-rootfs for ubuntu-netbook/armel?
<ogra_> cjwatson, nope
<ogra_> err, wait
<ogra_> we probably still need the session thingie until we are sure the fallback mechanism is stable enough on armel
<ogra_> but definitely not for gdm anymore if we switch the seeds
<ogra_> which i was planning to do soon
<cjwatson> I could not implement that hack in live-build and you could find out whether it's stable :-)
<ogra_> yep
<ogra_> sounds ok, do you plan to switch soon ?
<cjwatson> this week I hope
<ogra_> k
<cjwatson> I'm sorting out the manifest-desktop thing now, which is the last big chunk of work, although there are still a few remaining small ones
 * ogra_ still needs to work into that code ... 
<cjwatson> (known: finish BuildLiveCD changes, do cdimage-side integration, check whether kubuntu icon-theme.cache hack is still needed, docdirs/fdupes instrumentation, check whether langpack extended_states hack is still needed, filesystem.size, edubuntu LTSP chroot)
<ara> skaet, hello
<skaet> ara, hiya
<maxb> Is there any scope for SRUs that update udebs? Would it be possible to get d-i images published into natty-updates, for example?
<maco> there won't be any new natty isos, so why would a new d-i be needed in natty?
<stgraber> maco: for mini.iso/netinstall ?
<stgraber> http://archive.ubuntu.com/ubuntu/dists/natty/main/installer-amd64/current/images/netboot/
<stgraber> I seem to remember seeing some in -updates for previous release of Ubuntu, so it's not impossible that you can ask for a rebuild
<maco> i know the LTSes had new iso versions....but do regular releases too for netboot?
<cjwatson> maxb: sure, it's been done
<cjwatson> maco: yes, they're useful for netboot in order to deploy new kernel versions that fix things needed at install time
<cjwatson> only useful in some environments of course but often better than nothing
<maxb> cjwatson: OK - do you think it's worth doing in order to adjust the automatic d-i URL used when booting with auto=true url=hostname ?
<maco> cool
<maxb> (Currently maverick and natty pretend to be squeeze in this respect)
<cjwatson> maxb: seems reasonable enough
<maxb> OK - is there a special process to flag bugs as needing this?
<cjwatson> just StableReleaseUpdates
<maxb> But, after the udebs have built and published, someone needs to do something manual?
<cjwatson> I would need to do a d-i upload, yes
#ubuntu-release 2011-06-09
<debfx> could someone please have a look at virtualbox in NEW? it's just a renamed package (from virtualbox-ose) and I'd like to backport it to natty
<cjwatson> ScottK: when you say "Ubuntu changes are all incorporated or OBE", satisfy my curiosity - what does OBE mean?
<cjwatson> (in sync requests)
<ScottK> Overtaken By Events.
<ScottK> (i.e. no longer relevant)
<ScottK> Sorry, I thought that was a generic acronym.
<cjwatson> aha, thanks
<cjwatson> Laney,ScottK: confirm that it's OK to remove geordi, following the Debian removal?  I notice a discussion here a couple of days back which suggests that, but since it's modified in Ubuntu I tend to explicitly ask
<ScottK> cjwatson: Yes.  Please do.
<cjwatson> OK, done, thanks
<Laney> the emails about removing geordi taught me about codepad.org which is actually rather cool
<jdstrand> skaet: hi! it occurred to me that the people who should be notified in !regression-alert was out of date. I got this updated today but was wondering if we could tie its review to the release cycle
<jdstrand> skaet: and it so, where
<jdstrand> skaet: I initially looked at https://wiki.ubuntu.com/ReleaseChecklist, it seemed odd in there (but I'd be happy to put it there if you think that is best)
<skaet> jdstrand,  definitely interested,  but probably need a bit of education.
<jdstrand> skaet: is it this page: https://wiki.ubuntu.com/NewReleaseCycleProcess?
<skaet> jdstrand,  yes that's a better place.
<jdstrand> skaet: do you have a preference which section it belongs in?
<skaet> at the start of the cycle we should know the roles for the upcoming release,  so a cross check then makes sense.
<skaet> probably at the First Few weeks after..
<jdstrand> k
 * jdstrand edits
<skaet> ScottK - based on the Kubuntu council meeting yesterday,  can I assume that the Kubuntu specs are all now approved for Oneiric?
<skaet> jdstrand,  thanks.  :)
<jdstrand> skaet: sure thing! :)
<ScottK> skaet: Yes.  I'll mark the specs ujp here in a bit.
<skaet> ScottK, thanks.
<skaet> ScottK, can you please update https://wiki.ubuntu.com/OneiricOcelot/ReleaseImageContacts with the Kubuntu information?  ie. test contacts, and which images are shipping per milestone.
<ScottK> skaet: I'm a bit tied up today.  Please ping me tomorrow if I forget.
<skaet> ScottK.  Ok,  will add it as an action to the agenda ;-)
<jdstrand> is there something wrong with the publisher?
<jdstrand> I unembargoed something 5 hours ago and it is sitting in ACCEPTED
<cjwatson> jdstrand: it seems to be running - what package?
<jdstrand> cjwatson: I brought it up in #launchpad-ops
<jdstrand> cjwatson: basically, look at the accepted queue for lucid, maverick and natty
#ubuntu-release 2011-06-10
<tumbleweed> Google calendar doesn't like me receiving invites on my ubuntu.com address (even though it's an alternate address on my google profile), so I can't RSVP to the meeting events. How do other people deal with that? (or are RSVPs unecessary)
<cjwatson> tumbleweed: I never bother to ack it on the calendar; I don't know if this annoys skaet :-)
 * tumbleweed is in good company then :)
<skaet> lol
 * skaet figures as long as folk show up, or let me know in advance they can't,  she has no complaints...
<highvoltage> tumbleweed: so is it official now that you're part of the release team?
<tumbleweed> highvoltage: not sure how useful I'll be, but yes I'm the MOTU representative
<highvoltage> nice. well, you're always a good person to have around.
 * NCommander waves
<cjwatson> 15:49 <doko_> cjwatson: re-uploaded, now afk
<cjwatson> oops, echan
#ubuntu-release 2011-06-12
<micahg> any archive admins around to pocket copy something?
#ubuntu-release 2012-06-04
<xnox> https://launchpad.net/ubuntu/+source/imagemagick version in precise is higher than in quantal.... yet probably the security update should have been pushed to both?
<xnox> nevermind I have both...
<RAOF> xnox: That looks like it should have been pushed to Quantal, yes.
<xnox> RAOF: funny thing in my sources I only have quantal, yet I have 3.1 available
<xnox> let me double check
<RAOF> I don't have 3.1 available, nor does rmadison show that for quantal.
<micahg> yeah, that should've been copied, it was published the first week of may
<micahg> the package could use a merge from Debian anyways though
<xnox>  libmagickcore-dev : Depends: libmagickcore4 (= 8:6.6.9.7-5ubuntu3) but 8:6.6.9.7-5ubuntu3.1 is to be installed
 * xnox just had that a moment ago
<xnox> I did apt-get update just now, and it's gone now.
<micahg> xnox: that would happen if you had precise installed without the dev package, got the update before updating to quantal, then tried to install the dev package on quantal
<xnox> aha =)
<xnox> yes, of course.
<xnox> yeap, I did upgrade less than 5 weeks ago.
<micahg> so, if someone with copy powers can make it so, that would be great
 * micahg tries a test build on quantal (if it works, I'll do a no change upload)
<micahg> test build worked |)
<Daviey> micahg: can you clarify the situation ?
<micahg> Daviey: are you AA enough to copy something yet?
<Daviey> micahg: i believe so.. but i'd like to clarify the issue :)
<micahg> Daviey: this security update pushed on 1 May wasn't copied to quantal as it should've been
<Daviey> imagemagick ?
<micahg> yes
<micahg> I could do a no change upload, but I think a merge from Debian would be more useful
<Daviey> micahg: then why not just merge from Debian?
<micahg> Daviey: I don't have time ATM :)
<skaet> micahg,  any specific issue with Firefox 13 beta 6?  (its for an alpha)
<micahg> skaet: there were 2 small bugs fixed in beta 7, but no show stoppers AFAIK
<micahg> one is Mac only
<micahg> the other is fixing a potential crasher, not a blocker IMHO for an alpha, was mainly wondering about the beta 6 label on the package
<skaet> micahg,  beta 6 should be fine for alpha - its all work in progress.   Don't think there should be an issue using beta label,  we release kernel in the milestones with -rc# s.   If others know an issue though I'm overlooking, they're welcome to chime in.  ;)
<skaet> when will beta 7 be landing?
<micahg> skaet: it won't the next upload would probably be 14 beta 7 (we're on 13 now) after alpha 1 is released
<skaet> micahg,  then beta 6 should be fine.
<micahg> ok, thanks :)
<skaet> Just add the known issues to the TechnicalOverview (which I'm about to create ;) )
<micahg> I wouldn't even think it known issue worthy
<micahg> but if any come up, I'll be sure to let you know :)
<skaet> fair 'nuf.   :)  thanks
<tumbleweed> micahg: AFAIK if you can upload a package, you can copy it
<micahg> tumbleweed: ORLY?  I thought that was AA only
 * micahg tries
<micahg> well, u-a-t doesn't seem to have a script that can just copy (this was done server side AFAIK)
 * stgraber tries
<stgraber> micahg: lp-shell didn't complain at least
<micahg> stgraber: right, my lp-shell-foo is lacking :)
<stgraber> micahg: yep, worked
<micahg> stgraber: thanks, Daviey, you can stand down :)
<stgraber> lp-shell production devel
<stgraber> archive=lp.distributions['ubuntu'].archives[0]
<stgraber> archive.copyPackage(from_archive=archive, include_binaries=True, source_name="imagemagick", to_pocket="release", to_series="quantal", version="8:6.6.9.7-5ubuntu3.1")
<stgraber> and that's it :)
<Daviey> stgraber: I was just writing a damn script doing that
<stgraber> < 5 lines => not worth a script ;)
<Daviey> stgraber: well, i disagree.. I was writing something reusable with confirmation.
<micahg> Daviey: I think the script exists, it just needed to be moved to u-a-t
<micahg> or rewritten to work in the world of non-local AA tasks
<Daviey> micahg: no, i don't think there is one that uses the API
<micahg> Daviey: right
<Daviey> exactly, which is what i was doing.
<tumbleweed> sru-accept includes code to do that, if you tell it to
<micahg> well, if it's in -proposed (which this never was)
<micahg> sru-accept?
<tumbleweed> err I mean sru-release
<Daviey> load average: 1003.85, 1001.70, 903.73 ... hmm.. what did i do?
<stgraber> fork bomb? :)
<Daviey> hah, no..
<xnox> thanks all for fixing imagemagick =)
<stgraber> xnox: np, was fun to finally test copyPackage() ;)
 * xnox tries to think of something else to amuse stgraber
<xnox> stgraber: do you want to have fun with deleting binaries? =)
<stgraber> I don't have access to that kind of fun
<xnox> bug 1007970
<ubot2`> Launchpad bug 1007970 in bitcoin "please remove powerpc binaries" [Low,Confirmed] https://launchpad.net/bugs/1007970
<xnox> stgraber: but I was sure that it was migrated to the new type of tools et al
<stgraber> I know cjwatson tested package removals through the API but you still need an archive admin for them
<xnox> ah ok.
 * xnox no more amusment available for stgraber, please check back later ;-)
<stgraber> unless someone decided to allow anyone with upload access to a package to also remove it and its binaries, which might to a certain extent make sense, but I don't think it's what was implemented
<xnox> stgraber: sounds to permissive given that the stuff that you do *not* have upload rights for, may have already rebuild against it.
<stgraber> true, but you could just as well upload a new version of the package and would also break the same set of rdepends, at some point we have to trust people :)
<xnox> stgraber: oh so only at that point you gonna trust people.... =)
<xnox> btw, stgraber for Developer Membership Boards, is it 2 application per type, or in total?
<xnox> where type is type of developer membership
<stgraber> xnox: total
<xnox> =(
<xnox> ok. So I will have to wait until 18th of June to try my luck
<stgraber> we usually ask questions for more than 30min per applicant so we implemented that limit of two applicants to try and have us fit the meeting in our one hour slot
<xnox> I see.
<stgraber> we could probably ask less questions but it'd be a lot less fun :P
 * xnox notes down that stgraber likes to amusement
<jbicha> fun for who?
<xnox> jbicha: i have started to type 'to amuse himself' then thought it might sound wrong and wanted to change it to "likes amusement"
<xnox> obviously I forgot to drop 'to'
<xnox> =)
<Daviey> xnox: 'binary' right?
<xnox> Daviey: well, yeah.... powerpc only ( I did not check if the previous version of the package has actually build one or multiple arch:any packages that succeded on powerpc)
<Daviey> they would have been superseeded for free
<xnox> Daviey: what do you mean? new package doesn't build for powerpc, long time ago it was, by error, listing powerpc as supported arch, but in fact it was not (builds, but does not run properly)
<xnox> so.... even though there is a powerpc binary in the archive, it should not be there.
 * xnox that is unless we care about powerpc at all....
<Daviey> xnox: you mean prior series? Precise etc?
<xnox> Daviey: all as far as I can see
<xnox> http://people.canonical.com/~ubuntu-archive/testing-ports/quantal_outdate_all.txt
<xnox> bitcoin 0.6.2.2-1ubuntu1 bitcoind(powerpc) 0.3.24~dfsg-1 from 0.3.24~dfsg-1 [universe]
<xnox> so package moved from: any -> [i386,amd64,arm-any]
<xnox> because all other arches, even if succeed to build, do not work
<Daviey> xnox: right.. Perhaps i'm tired.. but we are talking about different things :)
<Daviey> src bitcoin produces bitcoind bin, right?
<xnox> yeap
<Daviey> so, one binary.. How would there be multiple prior versions in the same series?
<xnox> Daviey: there is one version per arch, but different arches can have different versions
<Daviey> but we are only talking about power, right?
<xnox> Daviey: yes.
<xnox> so, yeah on powerpc it is stuck at 0.3.24~dfsg-1
<Daviey> Right.. so what others could there be?
<xnox> on powerpc, none at all.
<xnox> marking the package `any` was a mistake from the start.
<Daviey> ok.. still not following.. but ok :)
<Daviey> Anyway, there seems to b a 24hr delay for removals.. or some other bug.. https://launchpad.net/ubuntu/+source/bitcoin/0.3.24~dfsg-1/+publishinghistory  "Removal requested in 23 hours."
<xnox> Daviey: http://bugs.debian.org/650805
<xnox> fail wrong link.
<xnox> aha http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668868
<ubot2`> Debian bug 668868 in src:bitcoin "bitcoind: Assertion failed at startup on mips (big endian)" [Serious,Fixed]
<Daviey> OH.. you mean other arches?
<stgraber> Daviey: my understanding is that bitcoin (source) produces bitcoind (binary). In the past bitcoin was arch=any so produced bitcoind for powerpc. Nowadays bitcoin is arch=any-but-not-powerpc so no longer produces the bitcoind powerpc binary. Which left us with an outdated (pre-arch-field-change) version of bitcoind in quantal and for powerpc only
<ScottK> Which should be removed (on powerpc)
<stgraber> right
<xnox> Daviey: that request seems to remove the whole source package, which is way too much
<Daviey> stgraber: Yeah, i got that.. what confused me is that there seemed to be some doubt as to there being more than one binary to remove.
 * xnox sorry about that confusion
<Daviey> xnox: no, i'm probably tired. :)
<stgraber> tired? it's only 4am on a weekend/bank holiday, perfectly normal time to work ;)
 * xnox same here.
<Daviey> nah, i'm on 3:00AM.. I work on UTC.
<xnox> stgraber: are you based in the UK as well or just happen to have bank holiday as well.
<Daviey> If the whole world adopted UTC working hours, life would be much more efficient.
<jbicha> Daviey: I don't know, that's a bit early
<stgraber> xnox: nah, was just referring to the situation for both Daviey and you. I live in Canada on eastern time, so it's the much more reasonable time of 11pm here :)
<xnox> stgraber: Canada, eh?! =)
<stgraber> Daviey: I'd definitely be happy with the whole world always using the UTC timezone and dropping the stupid DST, thought I'd still be waking up at 13:00UTC
<stgraber> xnox: not hearing much "eh?" around here, mostly some weird french variant ;)
<xnox> UTC... and synchronised with Narnia time
<xnox> http://xkcd.com/1061/
<skaet> https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview <- has framework in place now for Alpha 1 content to be added.
<skaet> Also, "Ubuntu Release Calendar"(http://fridge.ubuntu.com/calendars/ubuntu-release-calendar/) now has the key release schedule events on it for the next 6 months (mirrors what's on the wiki page)
<jibel> mvo, good morning
<jibel> mvo, could you look at update-manager, it failed to build on i386 and as a consequence images are uninstallable
<jibel> mvo, there is a recursive build caused by a symlink on ./Distupgrade
<jibel> mvo, introduced by this change in r391: Add a DistUpgrade -> . symlink in DistUpgrade/, to make it possible to have compatible imports both in update-manager proper and in dist-upgrader tarballs.
<mvo> jibel: I have a look now
<mvo> hm, I guess a new apt with a transition for libapt-inst1.4->libapt-inst1.5 is not a good idea at this time? the amount of rebuilds is pretty small as libapt-pkg4.12 is abi compatible
<Daviey> mvo: might want to outline reasoning and list of rebuilds. :)
<mvo> Daviey: *cough* reasoning? iz new version ;) but seriously, its the merge from debian, it can wait for after a1, it just happens to be read in my bzr repo
<jibel> mvo, any news on update-manager ? it'd be nice to have images other than i386 for A1 :)
<mvo> jibel: *cough* yes, after lunch
<jibel> mvo, k, bon appÃ©tit !
<Riddell> cjwatson: moving kubuntu bits to universe presumably needs changes to ubuntu-cdimage and livefs to create the images with universe?
<Riddell> oh you're on holiday today
<ogra_> Riddell, you arent ?!?!
<ogra_> oh, Daviey is around too
<ogra_> you must all love your queen, eh ?
<ogra_> :P
<Riddell> ogra_: I have too much kubuntu stuff to do to care about bank holidays just now
<ogra_> heh
<Daviey> ogra_: I am not around, i'm a hallucination.
<ogra_> lol
 * ogra_ pust down the crack pipe then, seems i overdid it 
<mvo> jibel: new u-m is uploaded, fingers crossed
<jibel> mvo, successfully built ! Thanks
<mvo> yeeeeeh!
<mvo> :)
<stgraber> good morning
 * infinity wonders when promotion/demotion on component-mismatches was changed to "movement", and why he only just noticed.
<skaet> good morning
<knome> morning skaet! :)
<skaet> :)
 * skaet looks at IRC logs, and thank mvo for the fixed update-manager (fingers crossed)
<skaet> has anyone kicked off the image rebuilds?
 * skaet wondering if stgraber or NCommander are around
<stgraber> skaet: I am
<skaet> coolio.  :)
 * NCommander wakes up
<NCommander> Still enjoying morning diet coke
<stgraber> skaet: was looking whether the archive is in a consistent enough state to try and kick some rebuilds
<stgraber> skaet: already created Alpha 1 on the tracker and changed the config on nusakan to point to it, so anything that builds now will show up on the tracker
<skaet> thanks stgraber,  that's what I was trying to figure out.    gap in IRC log and when I logged in ;)
<ogra_> dont bother with arm images though
<stgraber> ogra_: ok :)
<ogra_> we're still waiting for the MIR team
<skaet> ogra_, ack.
<ogra_> and desktop has compiz issues i'm currently trying to work around
<skaet> ogra_,  what's the bug number of the blocking MIR
<skaet> ?
<ogra_> bug 1006717
<ubot2`> Launchpad bug 1006717 in eilt "[MIR] linux-base" [High,New] https://launchpad.net/bugs/1006717
<ogra_> i wonder why it picks the eilt project here ... that was surely added later
<ogra_> silly bot
<skaet> Thanks ogra_ :)
<stgraber> skaet: turned off cron
<NCommander> ogra_: probably alphabetizes it
<NCommander> e > u afterall
<NCommander> er
<NCommander> e < u
<ogra_> heh
<skaet> thanks stgraber.
<stgraber> skaet: (except for the precise daily builds that can still run without really affecting us)
<skaet> good point.  :)
<knome> stgraber, who was it to contact about the testcase wiki again?
<stgraber> knome: jibel or balloons
<knome> jibel, balloons: (since you are already highlighted:) hi! can you ping me once you're available; thanks! :)
<knome> stgraber, thanks
 * infinity fixes rpm, alien, lsb, (okay, that as all rpm), and linux-image-generic-pae issues, and goes to find some breakfast and ponder why he woke up at 6am.
<ogra_> because your brain is still somewhere between china and canada i.e. over europe ?
 * infinity adds erlang to the list.
<ogra_> infinity, isnt it a bank holiday for you today anyway ?
<infinity> ogra_: Is it?
<ogra_> qell, there is that queen thing
<infinity> Oh, pretty sure only the UK is slacking.
<infinity> I've heard nothing about us doing so.
<ogra_> i though that applies to all the commonwealth
<infinity> We'd all have to have decided so individually.
<infinity> The queen can't force law on us.
<ogra_> ah
<ogra_> poor you then
<infinity> But, like I said, I've not heard anything about Canada slacking to party.
<ogra_> :)
<infinity> Odd reason to party anyway.
<infinity> "Good job on being old and rich."
<ogra_> heh
<infinity> erlang should fix rabbitmq and maas.
<infinity> stgraber: So, if you're doing servery respins (maas/rabbit are on server CDs, yes?), you might want to wait for a publisher cycle to see if testing-probs clears up from the fiddling I just did.
<infinity> And happy PlusOne month to me.
<stgraber> infinity: ok. I'm currently trying a desktop respin to check that amd64 actually builds now. Will avoid server for the next 30min
<skaet> infinity,   stgraber,   not sure that Daviey's finished with his changes, so not sure what state its going to be in.  (ie. if its even ready to be spun)
<stgraber> skaet: ubuntu-amd64 on kapok.buildd finished at 2012-06-04 14:01:57 (success)
<stgraber> yay!
<skaet> :D
<jibel> knome, pong
<skaet> stgraber,  NCommander - http://pad.ubuntu.com/ubuntu-release has been started for Quantal A1.   Image builds still need to be reviewed and edited.
<skaet> utlemming, any concerns about getting images ready for A1 this week?
<stgraber> skaet: thanks. Still waiing for desktop powerpc to finish building...
<utlemming> skaet: no ma'am. They should be good to go this week.
<skaet> utlemming,  coolio.  :)
<stgraber> oh, I guess I can build core though
<skaet> :)
<stgraber> hmm, or not, core is also a live image
<ogra_> err
<ogra_> core is a tarball
<ogra_> (or at least should be)
<skaet> stgraber,   lubuntu alternate should be ok to build.
<stgraber> ogra_: yeah but built with buildlive
<ogra_> yes
<stgraber> skaet: indeed, triggering that one
 * xnox has a highlight for alternate. yes keep building alternate cd's.
 * xnox disappears
<Laney> skaet: Can we get the alpha soft freezes on the schedule? :-)
<stgraber> Laney: hehe, just poked skaet about it too ;)
<micahg> skaet: just noticed that the release schedule doesn't seem to be clear at all about when alpha freezes are (we know them to be the Monday before release at 21:00 UTC)
<Laney> hahahaha
<Laney> there is no secret release schedule scrutinising cabal here
<Laney> honst
<Laney> honest
<stgraber> skaet: right, so as I was telling you in pm, the DMB (^) was discussing it ;)
<skaet> lol
<micahg> well, 2 of you are in the release team :)
<Laney> we don't have any secret channels :(
<stgraber> micahg: 3 actually
<ScottK> Not that you'll admit to.  They wouldn't be secret then.
<stgraber> micahg: oh, you mean, talking in this channel, corect then :)
<micahg> :)
 * skaet just went to double check and they are on the Ubuntu Release Calendar.    
<skaet> however,  yes,  we need to send out the email.
<Laney> there's a calendar?
<skaet> Laney not sure I want to add them to the wiki pages though, since its another line, and makes things a bit confusing.
<Laney> maybe put it in Notes?
<Laney> Alpha 1 (Soft freeze Monday 04/06)
 * Laney shrugs
<skaet> yup,  that should be doable.
<skaet> Laney, stgraber, ScottK, micahg - there's http://fridge.ubuntu.com/calendars/ubuntu-release-calendar/
<micahg> not linked from https://wiki.ubuntu.com/QuantalQuetzal/ReleaseSchedule
<micahg> and ^^ is where we generally point people AIUI
<skaet> micahg,  oversite,  will fix.
<skaet> michag, done
<balloons> skaet, I thought we added the freeze to the interlock page?
 * balloons looks and sees it's not the case
<jdstrand> taking the publisher offline as per https://wiki.ubuntu.com/ArchiveAdministration#Special_case:_update-manager_updates
<mvo> jibel: fwiw, I enabled precise->quantal in do-release-upgrade -d mode (normal upgrade mode, not lts upgrade mode)
<jibel> mvo, great. server and desktop upgrade will start in 1h13min. We'll see how it goes.
<mvo> cool
<balloons> skaet, ping
<stgraber> gah, who broke ruby? ...
<stgraber> both Edubuntu images fail to build because of ruby not being installable
<skaet> balloons, otp,  biab
 * stgraber starts building lubuntu desktop while investigating the ruby problem
<ScottK> stgraber: Debian recently made Ruby 1.9 default.   You didn't get that by sync did you?
<infinity> stgraber: The ruby problem is in hand.
<stgraber> infinity: good :)
<infinity> stgraber: ruby-defaults came in via autosync, required us to rev ruby1.9.1, which I've just done.
<jdstrand> publisher back online
<infinity> jdstrand: Thanks for the review of linux-base.
<jdstrand> np
<skaet> ogra_ ^
<infinity> jdstrand: Given that our kernel team is probably responsible for the lintian-sadness, and I have a couple of them on loan to me this month for +1, I'll use this as a good object lesson for training. :P
 * ogra_ hugs jdstrand 
<jdstrand> infinity: cool :)
 * infinity wishes doko was around to re-activate him in ~ubuntu-mir.
 * jdstrand hugs ogra_ :)
<stgraber> well, I guess it's time for lunch. Lubuntu desktop is building (waiting on powerpc), will then continue with Kubuntu and finally Edubuntu which should be buildable again by then
<ogra_> compuiz fix is uploaded too ... sadly not to quantal-proposed though, i owe everyone a beer at next UDS for whom that caused trouble
<infinity> ogra_: Should be fine.
<ogra_> infinity, the beer you mean ? yeah :)
<infinity> ogra_: I meant it shouldn't be a problem, but I'm happy to accept beer too.
<ogra_> :)
<skaet> Riddell,  cjwatson - during the A1 soft-freeze window,  please hold off on doing autosync's from Debian,  and discuss in this channel if an exception is required.
<Riddell> skaet: that starts end of tuesday?
 * ogra_ wonders if colin will acvtually read IRC before wed. given its a UK holiday
<skaet> Riddell,  no today.
<Riddell> gotcha
<skaet> We've started spinning images now,  and have a lot of cruft to shake down.    So best not introduce any more.
<skaet> Softfreeze starts at 2100 UTC.
<skaet> but we're effectively in it now.
<infinity> ogra_: Compiz happy on arm*, thanks!
<ogra_> \o/
<infinity> ogra_: I hope you and/or didrocks have taken an action to remember it's been kludged and fix it properly? :P
<ogra_> infinity, it will all be different in the next upload anyway (GLES is being merged upstream right now)
<ogra_> so the gles patch will be gone, nothing to revert :)
<ogra_> (i did the hack inside the patch)
<infinity> ogra_: Ahh, shiny.
<stgraber> hmm, what happened to the alternates?
<stgraber> AFAICS the cronjobs are turned off on nusakan and I already built these a while ago, so not quite sure what/who build them again
<jibel> alternate and desktop automated tests passed. upgrades are running
<stgraber> slangasek: why are you rebuilding the daily live images? (and was it you who rebuilt the alternates?)
<slangasek> stgraber: whoops; failure on my part to coordinate, sorry
<slangasek> stgraber: please dump the new builds in favor of the previous ones that were already being tested
<stgraber> slangasek: ok
<stgraber> slangasek: well, according to the tracker we didn't have any result for the previous alternates, so I guess we can keep the new ones then
<slangasek> ok
<stgraber> though we have results for the desktop ones, so if you can stop the build it'd be nice, otherwise I'll revert it when it lands on the tracker
<slangasek> though, jibel said "alternate and desktop automated tests passed", which might have some bearing?
<stgraber> jibel: what version of the desktop and alternate image where these automated tests run against? if that's on 20120604.2 (alternate), I'll revert the builds on the tracker
<skaet> stgraber, as the images emerge off of the builds,  can you update http://pad.ubuntu.com/ubuntu-release, so we can keep coordinated a bit better.  ;)
 * skaet going in and doing som cleaning now.
<skaet> stgraber, NCommander,   afk for a bit,  back on later.
<stgraber> removing these from the tracker^
<jibel> stgraber, it was 20120604.2
<stgraber> jibel: ok, reverting the alternes too then
<jibel> 20120604.3 passed too
<stgraber> oh, ok, well, if 20120604.3 passed too, we can keep them then :)
<stgraber> infinity, ogra_: started building arm desktop now, though I only noticed that mx5 and ac100 aren't candidate after I started the build, so they'll get built, I'll just remove them from the tracker afterwards
 * infinity decides that http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html looks much better and rewards himself with a lunch break.
<slangasek> infinity works for peanuts
<infinity> This isn't the sort of thing one really wants confirmed by one's manager.
<slangasek> infinity: we can throw in some jelly, then you can have a whole sandwich
<infinity> Too kind.
<NCommander> stgraber: I need to go AFK for a bit, I'll be about in ~45 minutes to an hour
<stgraber> NCommander: k
 * skaet back
<stgraber> skaet: arm desktop is still building and so is wubi, everything else is built and posted on the tracker
<skaet> stgraber,  coolio.  :)  thank you.
<balloons> stgraber, skaet, slangasek what's up with wubi this cycle? I thought wubi was moving to an exe only, non-scheduled release cycle Forgive me if this is a silly question, it's been proven I'm scattered today.
<skaet> balloons,  it wasn't clear to me either.  slangasek just confirmed its status quo to last release.
<balloons> skaet, what does that mean? Are you trying to say we're going to continue pushing images of it out or ?
<stgraber> balloons: don't know the exact plan but even without it being on the CD, the actual .img file used by wubi needs testing
<skaet> balloons,  agree we need to get the plan clarified as to what we want tested for it.
<slangasek> balloons: I don't know what "exe only" should mean here, but as stgraber says, there's a wubi image that must still be generated and tested
<slangasek> balloons: is this question coming from https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-wubi-publishing, or from somewhere else?
<slangasek> (btw, it's already status quo that we don't offer a wubi-based install option on the CD in precise)
<balloons> slangasek, yes from that blueprint.. I agree, clearly whatever/however we're doing it it needs tested..
<balloons> I just want to make sure I understand what the plan is, and if testing needs have changed..
<slangasek> balloons: testing should not be changing
<balloons> slangasek, ok, that's good.. has the timing changed at all? I suppose for this alpha nothing has changed
<slangasek> no... nor am I aware of any reason the timing /should/ change... but I wasn't in the session
<slangasek> I'm only going by what was written up in the blueprint - if you think that doesn't reflect what was agreed in the session, please poke the drafter ;)
<balloons> slangasek, lol
<balloons> fair enough.. please excuse my insanity
<balloons> thanks everyone
<balloons> bah, my scatteredness.. back on the wubi thing.. there is no exe for quantal.. at least the link we provide is broken: http://people.canonical.com/~evand/wubi/quantal/
<stgraber> sounds like someone needs to update it for quantal and upload it
<stgraber> ev: ^
<stgraber> I guess it's unlikely for ev to be around with the long UK weekend though
<ev> hi
<ev> ;)
<stgraber> oh, or not :)
<stgraber> ev: want to do some overtime? :)
<balloons> stgraber, when you pushed the builds -- how/why did you do so if the link was broken?
<ev> stgraber: on it now
 * balloons trying to understand how is got kicked off
<balloons> ev, awesome, thanks
<ev> balloons: sure thing - it's largely a background task
<stgraber> balloons: we're building a .img file that's used by wubi, when that file is built the entry is pushed to the tracker
<stgraber> balloons: http://cdimage.ubuntu.com/wubi/20120604.1/
<balloons> stgraber, ahh.. so you have that end of it.. but you need to co-ord with ev to get the exe also.. right right, it's coming back now
<stgraber> exactly
<ev> yeah, I have a work item to push my side of this into the buildds
<balloons> ev, yes we were discussing the blueprint above.. I got quite confused on the issue, but I think the lightbulb is on now
<ev> balloons, stgraber: http://people.canonical.com/~ev/wubi/quantal/stable is in place
<knome> balloons, hey!
<knome> ev, hai!
<ev> hi
<knome> ev, have a moment?
 * balloons in my best darth vader voice knome, so we meet again
<stgraber> ev: thanks (s/ev/evand/g)
<balloons> ev, thank you much for the quick turnaround
<ev> knome: I'm actually on a public holiday. Just popped in to quickly help stgraber with a task that blocks on me
<knome> balloons, yeah! so, i have a simple (i hope) question for you
<knome> ev, ok, i'll send you email
<ev> knome: cheers
<knome> balloons, we want to add xubuntu-specific testcases to the testcase wiki. is there a structure you'd prefer?
<slangasek> balloons: skaet was just asking we about wubi test cases from http://testcases.qa.ubuntu.com/Install/DesktopWubi - case id wdi-001 is now obsolete, and wdi-002 now depends on wdi-004, so maybe these should be reordered?
<slangasek> ev: the testcase tracker also has an entry for "CD boot helper", which uses umenu options Demo and Full installation -> CD-booter ... is this still available?
<slangasek> (if not, we should ask balloons to drop test case wdi-003 as well)
<balloons> knome, yes, we have a structure we'd prefer.. as you know however, we're migrating to using the isotracker to manage them
<balloons> I believe stgraber will be able to import any xubuntu specific testcases into the tracker when we move, so I don't think it would be an issue or waiting however
<balloons> so, format format.. let me find a link
<balloons> slangasek, yes, we have pending work to dive deeper on these testcases this cycle
<knome> balloons, i don't ...
<balloons> but I am always tweaking them
<balloons> since you and ev are the source for wubi, we can do it right now
<balloons> knome, ohh.. well, one moment.. that's more to type then.. and some details and fun to share with you
<slangasek> balloons: right, I think that's what skaet was looking for :)  wdi-001 is absolutely obsolete, since it refers to the option to run Wubi from CD that we took away last cycle - IMHO best to drop the test case to remove confusion
<knome> balloons, PM is okay if you don't want to flood the channel :)
<balloons> slangasek, yes.. I was looking at them a moment ago, but hadn't started down the editing train yet.. ok, so drop test 1 (no more cd)
<ev> slangasek: that's the one piece we kept. lp:wubi/src/wubi/frontends/win32/cd_menu_page.py:55
<slangasek> ok cool
<ev> it uses the NT bootloader to get around having to hit F12 and select a boot device.
<slangasek> balloons: sounds like that's the only one to be dropped, then... and do we want to renumber wdi-004 to wdi-001 (and move it up)?  otherwise wdi-002 makes no sense
<ev> (by writing the contents of the CD to a file on disk and pointing grub at it)
<balloons> slangasek, I'm looking at them now.. we need to re-write 3 as well (I think)
<balloons> or does the cd still have that ability
<balloons> ?
<skaet> slangasek,  maybe better just reordering how they show up on the page - rather than change the numbering so, our past data still makes some sense?
<balloons> skaet, yes, I'm re-ordering, not changing numbering..
<skaet> :)
<balloons> fortunately this will be fixed (kind of) by moving to isotracker to manager
<knome> i hope the testcases are community-manageable in the isotracker too :)
<stgraber> kind of
<knome> :|
<knome> that scares me.
<knome> we wanted to do some moin-including
<stgraber> product managers will be able to pick test suites and assign them to their product, the actual test cases will require extra rights that we'll grant on a case by case basis
<knome> me me me me
<balloons> knome, they will require a trust level (so you don't have people spamming your tests), but community will be able to edit
<stgraber> the reason behind these restrictions is that testcases will be sharable between products, so we hopefully won't have any duplication of tests
<stgraber> the downside being that we can't delegate rights on a per testcase basis as they affect more than one product
<balloons> slangasek, I guess I will have some folks help re-do case #3; should be similar, but likely that menu has changed a bit
<knome> stgraber, i agree that's a good thing. i hope that it's possible to combine testcases though... we want our tests to be similar to ubuntu, but in addition, we want our users to run a xubuntu-specific test
<balloons> knome, yes you will be able to add in testcases from ubuntu along with your own to form a testsuite that needs run
<knome> balloons, great!
<balloons> I guess we're kind of talking about it.. I'll forget pm'ing you :-)
<slangasek> balloons: 3 was the one ev just responded to above saying that the functionality is still there
<bdmurray> slangasek: I'd approve piston-mini-client to precise-proposed
<knome> balloons, would you mind if we added our xubuntu-specific tests to the testcase wiki *now*, or is the migration like *really close* ?
<slangasek> bdmurray: accepted
<stgraber> knome: the code exists and is running on iso.qa.dev.stgraber.org, we're expecting it to land before alpha-2
<knome> stgraber, in that case, i'll hold
<skaet> stgraber,  ogasawara uploaded the linux kernel they want used for A1 earlier today.   I've gone ahead and put that on the pad, so it gets included in next rebuild.
<stgraber> skaet: ok, is it worth respinning for it as soon as it lands or should we wait till tomorrow to get some more fixes?
<skaet> stgraber,  if there are not many test results (or ones marked in testing), probably best to get it respun before Europe comes online.     Since its getting late for you and NCommander's helping out on this one too,  may make sense for him to do the repins this evening.
 * skaet went to go look...
<skaet> hmm,  looks like lubuntu has some momentum as does ubuntu
<stgraber> skaet: kernel is apparently stuck in New, we'll also need a d-i upload for it I believe (assuming ABI bump) and armel failed to build
<stgraber> so doesn't look like we can easily respin at this point
<slangasek> armel FTBFS is ignorable, there are no armel images to be released for a1
<slangasek> NEW can be fixed
<slangasek> do you want me to fix it?
<stgraber> true, wondering if armhf will be affected too (still building)
<skaet> slangasek,  yes, please go ahead and fix the d-i upload.
<slangasek> well, I have to do the NEW processing first
<slangasek> best if someone else can take care of d-i afterwards
<skaet> infinity,  ^ you able to help out?
<stgraber> we'll also need a new linux-meta I believe
<bdmurray> slangasek: I approve of apport for precise-proposed
<slangasek> stgraber: correct - though there's no harm in accepting linux now before we have the timeline on that
<stgraber> sure
<bdmurray> slangasek: I also approve libgrip for precise-proposed
<dobey> there are ~24 hours until freeze, right?
<bdmurray> slangasek: and quickly for precise-proposed
<skaet> dobey,  no,  we're in soft freeze now.    Email went out to ubuntu-devel-announce just after 2100 UTC.
<skaet> dobey,  you can upload to quantal-proposed,  see the email for details.
<bdmurray> slangasek: and nautilus for precise-proposed
<dobey> skaet: i thought the soft freezes happened on tuesday 2100 utc?
<dobey> skaet: did that change?
<bdmurray> slangasek: and I approve of euca2ools for precise-proposed
<slangasek> bdmurray: apport libgrip quickly nautilus euca2ools accepted
<bdmurray> slangasek: thanks
<skaet> dobey,  it tended to float depending how much churn was going on,  to clear up the confusion, we've added  explicitly to the schedule http://fridge.ubuntu.com/calendars/ubuntu-release-calendar/   However, uploads can still go to -proposed
<bdmurray> slangasek: and you are running sru-accept.py too?
<dobey> skaet: eep. :-/ it's not on https://wiki.ubuntu.com/QuantalQuetzal/ReleaseSchedule
<skaet> dobey,  its a soft freeze,   the beta's are the hard ones.
<dobey> skaet: i guess FTBFS fix should go to quantal instead of -proposed though, per your e-mail?
<skaet> dobey,  what bug and package are we talking about specifically
<skaet> ?
<dobey> skaet: haven't seen a bug filed about it, but ubuntuone-client-gnome is currently FTBFS in quantal due to glib adding additional #error in some includes.
<dobey> and i am about to upload a version with the fix
<skaet> dobey,  fair enough,  go ahead and upload to quantal
<dobey> skaet: if i upload other stuff to -proposed, i imagine i will have to do that from now on throughout the entire cycle as well, to keep it properly in sync?
<skaet> dobey, nope.  just during the freeze window.   At the end all will be merged back into quantal.
<dobey> skaet: and if i think the uploads i am making need to be in alpha 1?
<skaet> yes,  we're in the prep for alpha 1 right now.
<bdmurray> slangasek: I approve of me-tv for precise-proposed too
<dobey> skaet: right. but if i upload to -proposed now, will they hang about until after a1, or do i have to poke people to sync them to quantal for a1?
<bdmurray> why are there 2 banshees and 2 clutter-1.0s?
<jbicha> because it's easier to add than to remove
<jbicha> feel free to drop the older clutter-1.0
<skaet> dobey,  hmm,  I said upload to quantal,  not quantal-proposed for that fix.    In general,  we're expecting to have tools to do this sort of post a1 move over so no poking,  but for now this is an experiment, so we will all need to keep an eye on the parts we care about.
<dobey> skaet: for that yes, i did upload it to quantal
<dobey> skaet: i mean for other things i am trying to upload, but aren't that fix, but which i think should be included in the a1 relase
<skaet> dobey,  k,  get them uploaded to proposed, and then we can look at pocket copying them over.   Let us know in this channel when things are built, tested and ready.
<dobey> ok
<dobey> skaet: and what's the cut-off for being able to pocket-copy during the soft freezes?
<skaet> dobey,  that depends on QA and community testers, and whether it makes sense to respin images.
<skaet> Basically earlier the better, and based on severity.
<dobey> ok. thanks
<skaet> :)
<skaet> infinity,  around?   can you help out on d-i for the new kernel,  ^  (see slangasek's comments in backscroll)
<NCommander> infinity: I'll handle it in about 20 minutes if you aren't already on it
<slangasek> bdmurray: haven't been running sru-accept.py, assumed you would :)
<bdmurray> slangasek: okay, I'll do it
<bdmurray> slangasek: I'd also approve mono for p-p
<slangasek> bdmurray: me-tv, mono accepted
<skaet> NCommander,  am heading out for dinner now,  back later.    Feel free to start the respins before I return if all the missing bits have landed.
<NCommander> skaet: kernel seems to have cleared new, doing the d-i bits now
<skaet> Thanks NCommander
 * skaet --> dinner, biab
 * infinity had an interwebs hiccup...
<infinity> NCommander: If you haven't done d-i yet, I can do it right now.
<NCommander> infinity: I did it, just doing test builds ATM
<infinity> NCommander: Ahh, yeah, I see the commit.  Alrighty.
<NCommander> infinity: when I upload, feel free to give it the shove into the archive
<infinity> NCommander: Actually...
<infinity> NCommander: You might want to hold off that upload.
<NCommander> ?
<infinity> Well, the kernel's still building on some arches. :P
 * NCommander shakes a fist
<infinity> Oh, based on the FTBFS on armel, I bet it's going to do the same on armhf anyway. :/
<infinity> Meh.
<infinity> Upload away.
<jbicha> is seeded-in-ubuntu broken for anyone else? bug 1008783
<ubot2`> Launchpad bug 1008783 in ubuntu-dev-tools "seeded-in-ubuntu crashed with IOError in _read_eof(): CRC check failed 0x282b98f1 != 0xdff779cL" [Undecided,New] https://launchpad.net/bugs/1008783
<infinity> NCommander: Updated seeds to match your d-i upload (and added highbank as well)
<NCommander> infinity: thanks.
<NCommander> amd64 test build passed, doing i386 one now
<infinity> That seems a bit overly paranoid.
<infinity> If one passed, you're probably good.
 * NCommander shrugs, and tags an upload
 * infinity notes that's the first time in a long time he's seen the urgency field used on an Ubuntu upload...
<infinity> Not sure the extra 200 or so that gets you in the buildd queue really matters. :P
#ubuntu-release 2012-06-05
<tumbleweed> esp when the queues are empty
<infinity> tumbleweed: Yes, I should have said "matters today".
<micahg> infinity: in quantal I've had quite a few i386 builds fail when amd64 passed and I've started doing some double testing as well
<NCommander> infinity: I do it as a matter of habit (though I never did have an urgency=critical in Debian :-)).
<NCommander> (nor would that d-i upload be criticla in Debian-terms)
 * skaet back from dinner
<skaet> infinity,  was that last set you? ^  linux [armhf] ?
<infinity> skaet: Yes.
<infinity> skaet: Same ABI bump that was already done on x86, the armhf build was still in progress at the time.
<skaet> ah,  gotcha.   thanks.
<skaet> NCommander,  anything left to pick up before the rebuilds get kicked off?
<NCommander> skaet: d-i armhf needs a retry as the kernel just poofed into existance
<infinity> I just did a mythbuntu-meta upload that affects only PPC.
<infinity> And d-i can't retry for about ~30m.
<infinity> (I'm waiting on the publisher)
 * NCommander loves waiting for the publisher :-/
<infinity> Oh, make that ~60m, the publisher didn't run at :03.
<NCommander> *grumble*
<infinity> *shrug*
<infinity> You're outside of work hours anyway, grumble less and go have a beer.
<infinity> ftpmaster and cdimage will both still be here in the morning. :P
<skaet> infinity, yeah, but we'll miss a day of Europeans testing the images...  and finding all sorts of nice interesting bugs.
<skaet> NCommander,  you ok to kick off the rebuilds tonight?
<NCommander> skaet: yeah, I'll set an alarm for an hour to kick d-i, another to kic the images and check channel backscroll at that tie
<infinity> NCommander: I'm watching d-i don't worry about that.
<infinity> NCommander: So, just give yourself ~2h for image respin time.
<NCommander> Great
<skaet> Thanks NCommander, infinity.  :)
 * skaet --> zzz
<infinity> NCommander: publisher ran over itself again, d-i won't be published for another hour or so from now.
<infinity> (Well, ~45m, if all goes smoothly)
<infinity> NCommander: Though, current linux-meta doesn't actually match the current ABI anyway, so we may be held up until the kernel team is happy with the state of things anyway.
<jibel> skaet, balloons I removed the test case for migration-assistant from Ubuntu Desktop
<jibel> Quantal Desktop doesn't install on Mac. I can reproduce bug 1008905 repeatedly
<ubot2`> Launchpad bug 1008905 in linux "Quantal Desktop AMD64+Mac on MacMini: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0" [Undecided,Confirmed] https://launchpad.net/bugs/1008905
<jibel> I reproduced bug 1008898, I think it's A1 critical (can't install desktop over wifi)
<ubot2`> Launchpad bug 1008898 in ubiquity "crash after inserting wireless password" [High,Triaged] https://launchpad.net/bugs/1008898
<ogra_> hmpf, someone should fix d-i to not attempt armel omap builds
<ogra_> stgraber, just build ac100 too, if it works we'll indeed release it for A1
<ogra_> (its not much extra work for me to test)
<skaet> good morning
<Laney> howdy
<skaet> :)
 * iulian waves.
<skaet> jibel,  thanks for flagging bug 1008905.
<ubot2`> Launchpad bug 1008905 in linux "Quantal Desktop AMD64+Mac on MacMini: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0" [High,Confirmed] https://launchpad.net/bugs/1008905
<stgraber> skaet: good morning
<skaet> stgraber,  good morning :)
<jibel> good morning
<skaet> stgraber,  so looks like kernel drops continued last night,  am just trying to figure out if it makes sense to do the respins now, or if anything else is about to land.
<skaet> jibel,  you want a fresh set of images with the latest kernel and d-i changes from yesterday?
<jibel> skaet, this one and 1008898 are the only really important defects found for a1
 * skaet goes to look at bug 1008898
<ubot2`> Launchpad bug 1008898 in ubiquity "crash after inserting wireless password" [High,Triaged] https://launchpad.net/bugs/1008898
<stgraber> skaet: a quick look at bug 1008898 shows that NetworkManager is the likely problem
<ubot2`> Launchpad bug 1008898 in ubiquity "crash after inserting wireless password" [High,Triaged] https://launchpad.net/bugs/1008898
<stgraber> skaet: which also explains all the other bugs where networking stops working completely
<stgraber> cyphermox_: ^
<skaet> jibel,  that one would be good to fix,  but its release notable for A1 if we must.
<stgraber> skaet: basically NetworkManager looks like it just vanishes from dbus (or at least isn't listening in that case)
 * skaet nods
<stgraber> I believe ubiquity does the right call, unless the API changed on NM's side without telling us :)
<skaet> stgraber,  you able to take a pass at seeing if you can fix it?
<stgraber> skaet: I can certainly make ubiquity ignore the missing dbus function but that won't help a whole lot as it'll likely just crash later...
<stgraber> skaet: I poked cyphermox_ a few lines earlier, hopefully he'll have a clue about what's going on with NM
<jibel> skaet, it's release notable sure but a major annoyance. It crashes the installer
<skaet> Thanks.
<jibel> by crash I mean the installer closes when the user clicks on continue
<skaet> jibel,  yup, will prioritize seeing we can get a fix figured out.
<stgraber> jibel: an easy trick would be to turn off the wireless step completely but I'm really more worried about NM being broken than about ubiquity crashing
<stgraber> because nothing tells me yet that networking will work properly post-install
<dobey> can i *please* get someone to accept my ubuntuone-client and ubuntuone-control-panel uploads for precise-proposed?
<jibel> stgraber, post-install network is working. The workaround during installation is to setup wireless with network manager instead of letting Ubiquity doing it (although my test machine just hang :( )
<seb128> dobey, try maybe pinging bdmurray slangasek or SpamapS (or RAOF tomorrow)
<stgraber> jibel: I'm actually quite surprised that the applet works... as far as I know it's supposed to use the same API as ubiquity and so I'd think would fail just as badly
<dobey> SpamapS: ^^ please? :)
<dobey> oh
<dobey> i guess SpamapS might be a bit preoccupied at the moment though
<jibel> skaet, ok for a fresh set of images to get latest kernel and d-i changes :)
<skaet> thanks jibel.  :)
<jibel> stgraber, I confirm that the workaround actually works
<stgraber> jibel: ok, that's weird, but still a good news :)
<skaet> stgraber,  ^  can you kick the full set of rebuilds off?
<stgraber> skaet: yep
<skaet> thanks stgraber,  :)
 * skaet goes to update the pad
<stgraber> skaet: do we actually have a kernel in core? I thought we didn't
<skaet> stgraber, you're right,  oversight.
<cyphermox_> stgraber: I wonder if the signature for AddAndActivateConnection might have changed; but NM is running when the crash happens
<jibel> stgraber, will you respin wubi ?
<stgraber> cyphermox_: can you check what are the valid signatures for AddAndActivateConnection? if it just slightly changed recently, it should be easy enough to fix on my side
<stgraber> jibel: yes
<cyphermox_> yes, that's what I'm doing; but it would surprise me if it had changed
<stgraber> I'm refreshing my ubiquity branch to see if something broke with the python3 port
<jibel> skaet, do we add upgrades to the tracker for a1 ?
<skaet> jibel,  since it should now be working based on yesterday's fixes from mvo,  yes please.
<cyphermox_> stgraber: actually, scratch that, it didn't change; we're still at the same version as in precise
<jibel> skaet, and automated tests passed :)
<skaet> jibel,  :)  that's good news.
<stgraber> jibel: will you be around for a potential test fix?
<stgraber> cyphermox_: looking at the ubiquity code we actually have an handler for the dbus exception, but I believe the exception name might have changed with the switch to python3
<stgraber> barry: ping
<barry> stgraber: pong
<barry> stgraber: hmm, which exception?
<stgraber> barry: is it possible that "except dbus.DBusException as e:" doesn't match with python3 and I instead need "except dbus.exceptions.DBusException as e:"?
<jibel> stgraber, I won't move from my chair
<barry> stgraber: that doesn't sound right, but let me consult the code
<stgraber> barry: we basically get that crash in ubiquity: https://launchpadlibrarian.net/106902328/UbiquityDebug.txt
<stgraber> barry: and on the ubiquity side we didn't change a whole lot, just ported to python3: http://paste.ubuntu.com/1025088/
<stgraber> barry: full nm.py is: http://paste.ubuntu.com/1025089/
<stgraber> barry: AFAICT the dbus exception should be caught by that except...
<barry> stgraber: that could just be its printed name.  exceptions in python are caught by inheritance and reference, not by name, so if dbus.DBusException doesn't catch dbus.exceptions.DBusException then they are different exception hierarchies, which doesn't sound right
<barry> stgraber: unless you're importing it from some place you're not aware of
<stgraber> barry: hmm, and actually, reading the code again, the bit that fails isn't in one of these excepts to start with...
<cyphermox_> looks weird to me that the error is with a signature a{sa{sv}}ss; when it should be a{sa{sv}}oo. stgraber; your code looks like it should be doing the right thing there
<barry> stgraber: this is on quantal right?
<stgraber> barry: yeah
<stgraber> jibel: can you try: python /usr/lib/ubiquity/ubiquity/nm.py and then python3 /usr/lib/ubiquity/ubiquity/nm.py
<stgraber> jibel: and confirm that the first works and the second fails
<barry> stgraber:
<barry> Python 3.2.3 (default, May  3 2012, 15:51:42)
<barry> [GCC 4.6.3] on linux2
<barry> Type "help", "copyright", "credits" or "license" for more information.
<barry> >>> import dbus
<barry> >>> import dbus.exceptions
<jibel> stgraber, both work
<barry> >>> dbus.DBusException is dbus.exceptions.DBusException
<barry> True
<barry>  
<stgraber> jibel: even when connecting?
<jibel> stgraber, ah, sorry
<stgraber> jibel: apparently all the dbus calls works except for the final AddAndActivateConnection, so it should be failing after you press enter
<jibel> stgraber, you're right, 2.7 pass, 3 fails
<stgraber> barry: hey, I heard somewhere that you know a bit about python and dbus :) any clue as to what's going on here (type related problem apparently)?
<barry> stgraber: i think at this point i need something i can reproduce locally
<jibel> barry, you can reproduce from a live session of the latest desktop image
<stgraber> jibel: can you try that one? http://paste.ubuntu.com/1025108/
<stgraber> jibel: it should crash just as much but will print the type of all the parameters
<barry> jibel: let me fire up a vm.
<stgraber> barry: you'll need something with a wireless card. I can reprouce the bug on my laptop by running the python code I just gave to jibel, the problem is, I kind of depend on my wifi at the moment :)
<barry> stgraber: ah.  i *might* be able to get that working on my old mbp, but probably have to burn a cd - which is fine, happy to do that if necessary, but maybe we can debug it a different way
 * stgraber tries to find a wire :)
<barry> stgraber: so, my first question is about what exactly the problem is ;).  are you getting an exception you don't expect, or are you not catching an exception you do expect?
<barry> (or something else? ;)
<stgraber> barry: getting an exception when we shouldn't
<barry> stgraber: so you think that AddAndActivateConnection with the given signature should exist on the server, right?
<stgraber> barry: it exists with a{sa{sv}}oo not with a{sa{sv}}ss
<stgraber> barry: with the same python code, python2-dbus uses the right signature but python3 doesn't
<barry> stgraber: interesting.  where's the server code?
<stgraber> barry: that'd be NetworkManager in C. So we know the server side is identical
<stgraber> barry: http://paste.ubuntu.com/1025120/
<cyphermox_> indeed, that's an issue in dbus
<barry> stgraber: i can hear bells ringing, so give me a moment to look at some code
<cyphermox_> stgraber: if I break it on purpose, with python2: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method "AdAndActivateConnection" with signature "a{sa{sv}}oo" on interface "(null)" doesn't exist
<jibel> stgraber, with which version of python ?
<stgraber> jibel: no longer needed, I found a wire here and ran it myself :) wanted to see the different in output between python2 and python3 but that's what I just pasted to barry
<barry> stgraber: still looking...
<barry> stgraber: i have a bit of an incomplete view of what's happening atm, but here's what i think's going on.  hopefully talking it out loud will clarify it.
<barry> jibel: ^^
<barry> to dbus 's' means utf-8 string
<barry> in python 2, there is a UTF8String type which inherits from StrBase, which is an 8-bit string type
<barry> 'o' is ObjectPath, which in both 2 and 3 inherit from strbase
<barry> in py2 strbase inherits from NATIVESTR_TYPE, which in py2 is PyBytes_Type (i.e. 8-bit str), but in py3 is PyUnicode_Type
<barry> so essentially, an ObjectPath is a str (a.k.a. bytes) in py2 but a unicode in py3
<barry> stgraber, jibel what's tripping you up is that in py2, you'll get auto-downcasted from 'o' to 's' and you'll match the signature, but i believe that auto-downcasting is not happening because the type of ObjectPath doesn't match 's'
<barry> (it's not in the inheritance tree)
<barry> still, that doesn't look exactly right, but it smells like the path we're on
<stgraber> barry: except that it's the other way around, the signature on NM's side is a{sa{sv}}oo
<stgraber> so the auto-downcasting is what's breaking it
<barry> hmm.....
 * barry wonders, why would it try to autodowncast when the signature is 'o'?
<stgraber> barry: is there a way to bypass the autodowncast?
<barry> stgraber: not sure this will work, but in the AddAndActivateConnection() call try adding a trailing keyword argument, e.g.:
<barry> signature='a{sa{sv}}oo'
<stgraber> barry: it works
<stgraber> jibel: can you confirm that http://paste.ubuntu.com/1025156/ works for you?
<jibel> stgraber, let me try
<cyphermox_> stgraber: wise
<barry> stgraber: cool.  i think you should file a bug at freedesktop.org.  istm that the automatic signature calculation is not doing the right thing.  simon will probably have deeper insight though
<barry> stgraber: it's been a while since i traced through that code and it's tricky
<jibel> stgraber, all good, with python 2 and 3
<cyphermox_> stgraber: confirming
<barry> yay!
<stgraber> skaet: once jibel confirms that it works, I'll be uploading a new ubiquity to -proposed. Also uploading a new isc-dhcp to -proposed to fix a pretty serious bug where the dhclient config file is ignored. Once both are built I'll pocket copy and start a respin.
<stgraber> skaet: in theory we should respin desktop+alternate for it as oem-setup also uses ubi-wireless
<barry> stgraber, jibel, cyphermox_ please do file the bug at https://bugs.freedesktop.org/ and if you paste me the url, i'll subscribe to it
<barry> if it's a real bug then i'll work with simon to get it fixed upstream
<skaet> stgraber,  sounds good.   There's some kernel fixes for arm in progress as well.  once everything lands/builds/publishes we'll respin for these.
<skaet> do you have a bug number for isc-dhcp
<stgraber> skaet: cool, can you add the arm stuff on the pad?
<skaet> stgraber,  will do,  as soon as I get a bug number from them ;)
<skaet> ogra_ ^ do you have a bug number for the latest issues?
<stgraber> skaet: added isc-dhcp to pad
<skaet> stgraber, Thanks!
<ogra_> skaet, still collecting, i havent managed a successfull install yet
<skaet> ogra_,  ack.  ok, post it here when one is created please.
<ogra_> or what arm stuff are you referring to ?
<ogra_> (did i miss anything (i had my laptop closed the last hours during testing and debugging)
<ogra_> )
<skaet> kernel config changes for omap to boot
<skaet> bug number associated with it?
<ogra_> ah, well, havent gotten to omap at all yet :)
<ogra_> i'll happily add it if ogasawara or paolo  have a bug # for it
<balloons> anyone try CJK install yet?  I got a hard failure during install  https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1009052
<ubot2`> Launchpad bug 1009052 in ubiquity "CJK Installation fails with error" [Undecided,New]
<jibel> balloons, let me try
<jibel> balloons, did you get it in a VM ?
<balloons> jibel, yes, hence my asking for real hw confirmation :-)
<balloons> trying the amd64 iso now.. it happened on i386
<stgraber> ubiquity and isc-dhcp uploaded to -proposed, will monitor and pocket copy when they're done
<skaet> ack
<bdmurray> slangasek: I approve of the ubuntuone-client upload for precise-proposed
<jibel> balloons, looks like a dependency issue with langpacks
<balloons> jibel, I was also concerned about ubiquity not seeing my active connection..
<jibel> stgraber, skaet can you disable alternate and desktop on the tracker if new images are being rebuilt soon-ish
<stgraber> jibel: yeah, I can disable everything we'll rebuild for sure
<stgraber> done, everything disabled
<jibel> I think we don't need to waste tester time on downloading and testing images that have an hour lifetime.
<stgraber> oh, and I suppose I should be adding the upgrade entries to the tracker now that update-manager is supposedly working :)
<balloons> jibel, amd64 build just failed also in the VM; tried a different language still failed
<jibel> balloons, I confirm the crash with Chinese, it passed with French. Which language did you selected ?
<balloons> I tried chinese just now, and simplified chinese in my bug report
<skaet> jibel,  agreed
<balloons> it's interesting we're missing some string translation coverage in apport
<stgraber> isc-dhcp built and pocket copied to quantal-release
<slangasek> bdmurray, dobey: ubuntuone-client accepted
<slangasek> bdmurray: I don't suppose you have any insight into why that one stalled in the unapproved queue so long?
<bdmurray> slangasek: I believe it was missing test cases for a bit
<slangasek> aha, ok
<ogra_> hmpf, so it seems that omap4 is very very fragile wrt displays ...
<ogra_> might need a release note to boot with no screen attached (to make it fall back to a hardcoded 1024x786 mode)
<balloons> stgraber, skaet can I get details on the rebuilds? I'd like to send something out to everyone.. the build notes on the tracker should contain the reason yes?
<skaet> balloons,  see: http://pad.ubuntu.com/ubuntu-release
<skaet> at the bottom,  is history of what's already been included in the rebuilds so far.
<skaet> status on what's about to go into rebuilds is at the top.
<skaet> (for the next set)
<balloons> right -- so [6] is current?
<balloons> OHH!
<skaet> yes.
<balloons> haha, right on top
 * balloons never saw those
<skaet> however we're about to respin for those triggers - so, ....  timing of when you send the email out will influence content.
<skaet> probably wait until stgraber kicks off the next set of respins, and then summarize what's landing.
<skaet> ?
<balloons> skaet, yes I wanted to summarize yesterday and since I'm at it.. all the respin bugs
<balloons> including stuff that is about to land.. which was driving my question, what's about to land
<skaet> ok, let me know if what's on the pad is not sufficent and we'll add it to there for now.
<skaet> want to have one place to keep history going. ;)
<skaet> so experimenting with format/info.
<stgraber> ubiquity is done building too, waiting for publisher, then pocket copy, then waiting for publisher, then mass rebuild
<balloons> I think i was just confused.. stuff up top is about to land.. stuff on the bottom is history
<balloons> yes?
<stgraber> and using all that waiting for publisher time to get some lunch :)
<stgraber> balloons: correct
<skaet> balloons, yes,  when the rebuild is triggered, I'm moving the info down to history part.
<balloons> skaet, yep makes sense.. :-)
<skaet> numbers are monitonically increasing, so we can keep track over time and refer to triggers explcitly (some aren't bugs and packages)
<stgraber> slangasek: once I'm done with the pocket copying and it's published in the release pocket, should I poke you/another AA to cleanup -proposed or do we already have some process in place to regularly remove the duplicates from -proposed?
<slangasek> stgraber: http://people.canonical.com/~ubuntu-archive/pending-sru.html tracks stale packages in -proposed
 * skaet notes that at bottom is -proposed cleanup"  commands to be run.   ;)
<stgraber> slangasek: oh right, forgot about that part of pending-sru
<bdmurray> slangasek: I approve of ubuntuone-control-panel for precise
<skaet> stgraber,  looks like kernel team has fixes for  bugs 1008905 and 1009061.   linux-meta fix will be uploaded.
<ubot2`> Launchpad bug 1008905 in linux "Quantal Desktop AMD64+Mac on MacMini: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0" [High,In progress] https://launchpad.net/bugs/1008905
<ubot2`> Launchpad bug 1009061 in linux "Beagleboard doesn't boot" [High,Confirmed] https://launchpad.net/bugs/1009061
<skaet> how close are you to starting off the respins?
<skaet> NCommander,  can you handle getting the d-i updates done for these?
<stgraber> skaet: I should have isc-dhcp published soon which will unblock a good set of respins, then ubiquity will be published around 30min later unblocking the rest
<stgraber> skaet: do we want to wait for the kernels? because it sounds like they'll affect pretty much everything too...
<ogra_> does anyone else get scrollbars in the slideshow or is that just caused by my 1024x768 screen ?
<stgraber> ogra_: I remember seeing a report of that on the tracker
<ogra_> great
<skaet> jibel,  would like to get some data on the fixes already queued up,  and then when all the other pieces for the kernel land later today respin (so fresh images for tomorrow),  that work for you?
<stgraber> ogra_: minimum supported resolution is 1024x600, if you get scrollbars with anything >=, it's a bug
<ogra_> yep, i thought so
<jibel> ogra_, bug 1008717
<ubot2`> Launchpad bug 1008717 in ubiquity "Ubiquity displays scrollbars inside of slideshow" [Medium,Triaged] https://launchpad.net/bugs/1008717
<infinity> skaet: I'll fix d-i for the new kernels.
<ogra_> jibel, thanks, will add it to my isotracker report
<skaet> Thanks infinity.
<jibel> skaet, works for me
<skaet> Thanks jibel.
<skaet> stgraber,  ok,  go ahead and spin up the kernels, and we'll collect data on them.   Then pick up the new kernel later today.
<skaet> oops
<skaet> stgraber,  ok,  go ahead and spin up the "images", and we'll collect data on them.   Then pick up the new kernel later today in fresh images.
<slangasek> bdmurray: ubuntuone-control-panel accepted
<stgraber> skaet: right, ETA is 30min for images that don't ship ubiquity and an hour for the hours (ETA to build start that's)
<NCommander> skaet: once the kernel and kernel meta package lands, I'll kick d-i
<skaet> NCommander,  infinity has said he'll help out with d-i,  so may have that covered.   Can you handle the rebuilds tonight?
<NCommander> skaet: I can cover that
<skaet> Thanks NCommander.  :)
<stgraber> isc-dhcp looks published, starting some builds now
<dobey> hi skaet
<dobey> skaet: uploads for things in universe can go straight to quantal still for soft freeze, right? (making sure i understand correctly)
<skaet> Thanks jibel
<stgraber> dobey: depends what packages in universe
<stgraber> dobey: if it's seeded, no
<dobey> stgraber: how do i tell if it's seeded?
<stgraber> dobey: seeded-in-ubuntu <package>
<stgraber> where <package> is the source package
<dobey> right
<dobey> ok
<stgraber> barry: https://bugs.freedesktop.org/show_bug.cgi?id=50740
<ubot2`> Freedesktop bug 50740 in python "py3dbus is downcasting the ObjectPaths to signature 's' when the server is advertising 'o'" [Major,New: ]
<stgraber> barry: feel free to correct my explanation if I missed something ;) I quickly typed that one after Fabio reported the bug to make it a bit more readable for upstream :)
<skaet_> infinity,  NBS list looks like its got a fair bit of cruft in it,  http://people.canonical.com/~ubuntu-archive/nbs.html,  can you sort it?
<stgraber> ok, ubiquity just finished publishing, will start the rebuilds
<infinity> skaet_: Yeah, I'm dealing with that today.  Getting my beer on quantal-probs was my first concern. ;)
<skaet_> lol,  why am I not surprised.  ;)
<infinity> Also, fixing the archive reporting cronjob...
<infinity> And maybe eating breakfast.
<infinity> ^-- Beer.
<infinity> That should be the last uninstallable in !ports.
<infinity> Sadly, mono on armel makes ports look a bit worse. :P
<Daviey> stgraber: bug 1006937 is fix released, re-spin server?  Or should i do it?
<ubot2`> Launchpad bug 1006937 in isc-dhcp "dhclient does not send hostname to dhcp-server" [Undecided,Fix released] https://launchpad.net/bugs/1006937
<stgraber> Daviey: I was told not to respin server
<stgraber> skaet_: ^
<infinity> Daviey: There are new kernels coming anyway, but if you want an interim respin to test things, you can.  *shrug*
<Daviey> infinity: nah, can wait
<Daviey> stgraber: Yep, please continue to build server.
<Daviey> stgraber: I asked QA to make server less of a priority as i was expecting changes, but didn't communicate that to you.. as i wanted them built regardless :)
<skaet_> stgraber,   Daviey had some discusions with others, and its back in for the A1 manifest.
<stgraber> Daviey, skaet_: ok
<barry> stgraber: thanks.  i'll follow up to the upstream bug
<bdmurray> slangasek: +1 for retext in precise-proposed
 * ogra_ hands infinity an eyepatch that hides armel from his view 
 * infinity goes to scramble some eggs for "breakfast".
<ogra_> didnt you just have beer ?
<ogra_> that should be enough for breakfast
<ogra_> :)
<infinity> I don't get beer until the end of this publisher run.
<infinity> Sadness.
<ogra_> ah, and you are bridging with eggs ... understood now :)
<stgraber> skaet_: updated the pad to reflect that we're currently rebuilding the desktop/alternate images to get the new ubiquity+isc-dhcp and will respin the world later for the kernel
<skaet_> thanks stgraber.  :)
<Daviey> why is there a new alternate if a kernel is being waited on?
<Daviey> Is the kernel an ABI bump?
<ogra_> someone said so above
<stgraber> Daviey: ubiquity was quite broken in the previous build, so we want to still get some results
<stgraber> (and ubiquity is on alternate because of the OEM install mode)
<Daviey> stgraber: If it's a kernel ABI bump, will d-i be rebuilt ?
<stgraber> yes
<ogra_> stgraber, well, oem-config just worked fine on preinstalled for me
<Daviey> super
<stgraber> ogra_: not connecting to a wifi I suspect?
<ogra_> ah, no, wired on the panda
<stgraber> right, wifi is what crashes ubiquity
<Daviey> I imagine all OEM's provision their hardware using wifi :)
<ogra_> i dont test such exotic setups for A1 :P
<stgraber> Daviey: it's not the provisioning that's the problem, it's the first-boot configuration screen
<stgraber> Daviey: which on most laptops is going to happen over wifi
<Daviey> ah yeah
<stgraber> ogra_: so based on the changelog, the same kernel that'll fix amd64+mac will fix omap3 right?
<ogra_> yes
<stgraber> ogra_: cool. Do you want to wait for it or do you want an ubuntu desktop preinstalled build now? the ARM builders aren't doing anything :)
<bdmurray> slangasek: I approve of ntp for precise-proposed too
<ogra_> stgraber, well, i tested omp4 already and have my collection of bugs for it ... omap3 wont boot, and ac100 will likely have flash-kernel issues so just leave them for now
<stgraber> ogra_: ok
<ogra_> stgraber, unless infinity wants an mx5 build for testing
 * ogra_ will do a smoketest for ac100 tomorrow but i dont expect it to work OOTB without some default changes to f-k
<stgraber> I believe yesterday's mx5 build failed, was that fixed?
<ogra_> http://cdimage.ubuntu.com/daily-preinstalled/current/ seems to have a recent build
<ogra_> ac100 not though :/
<ogra_> intrestingly the failed ac100 builds dont generate failure mails ... at least i didnt get any
<stgraber> skaet_: so I'll be building the following for now: ubuntu desktop, wubi, edubuntu desktop, kubuntu desktop, lubuntu desktop
<stgraber> skaet_: by the time these are done, we'll probably have the next batch of rebuilds for the kernel
<skaet_> stgraber,  ok.
<stgraber> skaet_: but that should at least leave some time for testing the rest of the system
<NCommander> stgraber: does it make sense to do a rebuild to only do another rebuild for another kernel?
<NCommander> As it stands, test results get hidden against old builds.
<skaet_> NCommander,  earlier discussion indicated it would be good to get some testing cycles on these fixes.
<stgraber> NCommander: I'd kind of like to have smoke testing on some of these images that haven't received any testing for alpha1 yet
<skaet_> NCommander,  we can see via /history prior results, so not lost
<NCommander> stgraber: skaet_: good points, just making sure we're not making more work for ourselves
<stgraber> I've prioritized by images with the least testing done so far (well, except for ubuntu desktop), so hopefully we can catch any critical bug before we respin for the kernel
<skaet_> thanks stgraber,  that makes sense.  :)
 * NCommander goes AFK for lunch
<barry> stgraber, jibel: looks like upstream already fixed it :)  i'll back port the patch for ubuntu while waiting for a new upstream release
<stgraber> barry: that was fast :)
<barry> yep :)
<barry> stgraber: i'v backported the patch, but i'd like you to try it without the nm.py hack (i.e. setting the signature).  would you like to try a ppa or should i just go ahead and upload it?
<stgraber> barry: at this point I'd prefer not to have it uploaded to the archive until post alpha-1 as we already have the workaround in ubiquity
<stgraber> barry: I'm happy to test with a PPA though
<barry> stgraber: perfect, i'll upload it momentarily
<barry> (to my ppa)
<slangasek> bdmurray: retext, ntp accepted
<RAOF> So where's this SRU hangout thingy?
<skaet> RAOF,  didn't get quorum
<skaet> moved it next week.
<bdmurray> SRU hangout?
<RAOF> Ah, ok. I'll go about my regular morning business then :)
<slangasek> skaet: ^^ should bdmurray also be invited, now that he's on the SRU team?
<skaet> slangasek,  yup,  he's going to care about the topic.  ;)  will add.
<bdmurray> slangasek: I approve policycoreutils for precise-proposed
<slangasek> bdmurray: accepted
<slangasek> and hmm, what happened with the discussion about adding you to ubuntu-archive for this :)
<slangasek> RAOF: what archive admin training did we subject you to before adding you to the group?
<bdmurray> indeed
<RAOF> slangasek: None specifically for archive admin; for SRU it was use of the tools, and prodding of launchpad.
<RAOF> slangasek: And a pinky swear to not do the things that I have access to that I'm not authorised to.
<slangasek> RAOF: where "not authorized to" is anything except pocket-copies to -updates, managing the unapproved queue, and deleting packages from -proposed?
<RAOF> slangasek: Yes.
<ScottK> skaet and slangasek: As a reminder, I've volunteered for SRU as well, but it seems to be hard to make progress on it.
<slangasek> bdmurray, cjwatson: ^^ that seems to me like a pretty straightforward policy for non-AA SRU members to follow - should we add bdmurray to ubuntu-archive?
<slangasek> ScottK: oh, indeed - I think we'll want to get you paired up with someone to help train you up
<ScottK> OK.
<ScottK> Since I'm already in ubuntu-archive and was once a motu-sru member, I think the needed training will be minimal (I already know how to drive sru-accept.py since I've done accepts on behalf of non-ubuntu-archive SRU members before).
<slangasek> ah, ok
<slangasek> I think it's still a good idea to give you a refresher on the current tools/policies just in case things have changed (i.e., I'd prefer one of the people dealing with the day-to-day stuff do the training, not me, since my own understanding is potentially bit-rotted :P)
<ScottK> Certainly.
<slangasek> RAOF: would you be willing to train ScottK for current SRU team practices?  That might work well as far as your respective time-of-day availabilities
<RAOF> Yeah, certainly.
<ScottK> I'm kind of booked until my Friday at this point.  Let's try and do it then.
<RAOF> ScottK: When's good for you?
<infinity> skaet: SRU hangout?
<infinity> skaet: Did I miss an invite to something?
<bdmurray> slangasek: yes that policy seems easy to follow
 * micahg sees infinity finally got his beer
<infinity> \o/
<skaet_> infinity, ETA on d-i changes?
<infinity> skaet_: Kernel's still building.
<infinity> skaet_: So... After that. :P
<skaet_> bleh.  thought it would be through by now.
<skaet_> thanks.
<infinity> (I have it all ready to upload when the kernel's done and copied)
<skaet_> Thanks.  :)
 * skaet --> dinner
 * infinity does a bunch of NEW processing while waiting on the last kernel build.
#ubuntu-release 2012-06-06
<skaet> infinity,  once the d-i stuff is published could you nick highlight NCommander?
<infinity> skaet: Yeah.  I jumped the gun on the upload by a few minutes, but it'll build in a while. :P
<skaet> k
<skaet> infinity,  can you check the pad, and make sure I've not missed anything with the latest updates?
<skaet> http://pad.ubuntu.com/ubuntu-release
<infinity> skaet: I think kernel+d-i is a catch-all for everything.
<infinity> skaet: So, I'd just "rebuild everything that's in A1" once d-i publishes, and not worry so much about the specifics, personally. ;)
 * skaet nods
<infinity> I suppose you can skip core if you want, but I haven't been watching -changes like a hawk to make sure nothing's changed in that set since the last build.
<infinity> And it's not like it takes long.
<stgraber> infinity: no need to rebuild core, but besides that, yeah, looks like everything
<stgraber> I rebuilt core just a few hours ago (because I thought we had isc-dhcp in there, which we apparently don't :))
<infinity> Yeah, we really don't. ;)
<infinity> Alright, d-i is building everywhere.  When it's done, it'll need to be published.
<infinity> stgraber: You keeping an eye on things right now?  I need some food.
 * ScottK has leftover spaghetti.  Want some?
<stgraber> infinity: yep, I'm still kind of around
 * infinity wonders why three of his d-i builds appear to be "stuck"...
<infinity> stgraber: And where does the ISO tracker get its "Netboot" info from?
<infinity> stgraber: Cause it's obviously lying. ;)
<stgraber> infinity: looks at LP for published state IIRC but not using rmadison or anything like that to check it's actually published
<infinity> stgraber: Erm, just looks for published state of the source, I guess?
<infinity> stgraber: Cause none of the binaries it just mentioned were published.
<infinity> (Some are still building)
<stgraber> infinity: that sounds likely, yes, IIRC it's based on part of queuebot's code, so probably only looking at sources
<stgraber> I guess I could make that use rmadison instead, would be more accurate and as it's just running once an hour, won't cause any extra load on the already slow rmadison server
<infinity> Or the API...
<infinity> Anyhow.  d-i all built now, should hit the :33 run, and be published before the hour.
<stgraber> yeah but the LP's definition of "published" is usually off by whatever time the publisher needs to run
<infinity> Oh, true.
<ScottK> Which is a really odd definition.
<infinity> It's true, from the publisher's POV.
<infinity> It's published when it hits disk.
<infinity> The fact that it hasn't run apt-ftparchive yet, or triggered mirrors.  Meh. :P
<infinity> (I suppose one could queue up all the "we published in this run" toggles and hit them at the end, but it makes the whole thing be one scary long transaction)
<infinity> Anyhow.  Food.  I was going to do that.
<stgraber> oh, d-i published, let's kick some rebuilds
<skaet> thanks stgraber
<stgraber> desktop and alternates are building
<stgraber> skaet, NCommander, infinity: Going to call it a day now. I have ARM desktop building and the desktop pipeline running on nusakan, assuming it works properly, that should cover everything but ARM server that'll still need to be started manually whenever ARM desktop finishes
<skaet> Thanks stgraber
<skaet> sleep well!
 * skaet looks like she'll be up with the grub/AMI issue for a bit.  :P
<NCommander> stgraber: skaet taking over now for the night
<knome> somebody familiar with gtk3? :]
<NCommander> knome: not really but I might be able to take a look
<NCommander> whats up ?
<knome> bug #1008682
<ubot2`> Launchpad bug 1008682 in gtk+3.0 "Resize handle can lead to unintended window movement and jumps (dup-of: 1001936)" [Undecided,Confirmed] https://launchpad.net/bugs/1008682
<ubot2`> Launchpad bug 1001936 in gtk+3.0 "GTK3 Grab/Move Triggered on Mouse Click" [Undecided,Confirmed] https://launchpad.net/bugs/1001936
<micahg> knome: #ubuntu-desktop
<knome> the dup has better description
<jibel> what is the status of desktop rebuilds ? stgraber says at 3:09UTC "<stgraber> desktop and alternates are building" but I don't see them on the tracker and cdimages.u.c
<cjwatson> ogra_: I wasn't going to do autosyncs before reading IRC anyway. :-)
<micahg> cjwatson: are you up for some security copies?
<cjwatson> slangasek: I'm OK with that - I've gone ahead and added bdmurray now
<cjwatson> micahg: sure, what do I need to do?
<micahg> cjwatson: please copy firefox from ubuntu-mozilla-security for lucid, natty, oneiric, and precise to their respective security pockets (updates as well if you like)
<cjwatson> grr, why are these docs still all about copy-package.py
<cjwatson> do you mind if I take a few minutes to modernise the process while I'm here?
<micahg> cjwatson: sure, I'm working on the USN, so I've got a little time (would like it published sometimes in the next hour :))
<micahg> cjwatson: as long as I have you here, I tried to use lp-shell to do the copy, but ended up with a silent failure
 * micahg wonders which piece he's missing to make this work
<cjwatson> not sure
<cjwatson> you're in core-dev, that should normally be enough to at least get it to land in the queue
<cjwatson> hah, it was
<cjwatson> https://launchpad.net/ubuntu/lucid/+queue?queue_state=1
<cjwatson> micahg: please just do whatever you did for the other series as well :)
<micahg> ooh, but I should have permissions for the other series as well
<micahg> oops, I mean that pocket
<cjwatson> it was a silent *success*, not a silent *failure* - but you missed the fact that it'll land in the queue (a common gotcha, this confused me as well)
<micahg> why is it in unapproved
<cjwatson> because
<micahg> ah, queuebot :)
<cjwatson> happens when archive admins use the API to copy stuff too
<micahg> \o/
<cjwatson> I have a bug open about it
 * micahg didn't notice queuebot spitting that out above
<Riddell> do the current candidate images have known re-spin issues or are they good to test?
<micahg> cjwatson: I'll try to update our scripts to use copyPackage which should fix my timeout issues as well (but how do we approve)
<cjwatson> micahg: you'll have to ask one of us to
<cjwatson> until such time as I can arrange for LP to allow per-pocket queue admin privileges
<Laney> get bug #648611 fixed :-)
<ubot2`> Launchpad bug 648611 in launchpad "ubuntu-sru either have too much or too little permission as queue admins" [High,Triaged] https://launchpad.net/bugs/648611
<micahg> ah, so maybe I'll just make a copy for me ATM (almost everyone else can just do their copies)
<cjwatson> indeed
<micahg> cjwatson: should I do the manual copy to -updates or wait for the copy job?
<cjwatson> I'm fine with letting the cron job do it
<cjwatson> I have kind of started on 648611, I got the DB column added
 * micahg hugs stgraber for showing me lp-shell over the weekend
<micahg> cjwatson: so, they're all there
<cjwatson> I've started on a generic API copy-package tool, but since you've already copied these I won't rush it
<micahg> yeah, i've got the 3 lines I need
<micahg> \o/ and solved the issue of my stuff not hitting the changes list :)
<cjwatson> is there anything useful I can do for a1?  I'm thoroughly out of date :)
<Daviey> cjwatson: Ah, i was writing one over the weekend aswell.. but lost my opportunity to try it.. I'm happy to drop mine.
<Riddell> stgraber is eu based driver for alpha 1 and last seen at 5 in the morning, I guess he won't we awake for a bit!
<cjwatson> Daviey: whichever of us wins :)
<micahg> cjwatson: if you're taking feature requests for the tool, please include the option to sponsor as well
<Daviey> I don't know that copyPackage supports that.
<Daviey> cjwatson: Well, i would have won.. but my chance to use it was hijacked :)
<Laney> copyPackage does support sponsoring. It's how we sponsor syncs
<micahg> hooray for reuseability
<Daviey> Hmm, Laney - do you have a package you know that was used on?
<Laney> gosh
<Daviey> The one over the weekend seems to have a bad 'details' page https://launchpad.net/ubuntu/+source/imagemagick
<Laney> yes, that's another bug
<Daviey> click Quantal publication
<Laney> look at the SPPH in the API, or the changes mail
<Daviey> ah yes, you are quite right, it does support sponsoring :)
<Laney> bug 861488
<ubot2`> Launchpad bug 861488 in launchpad "Mention sync requester on package version page" [High,In progress] https://launchpad.net/bugs/861488
<Daviey> hmm, all details pacges seem broken on that package.
<Laney> I'll need someone to help me finish that though, because Launchpad
 * Laney gets on a train to Cambridge
<jibel> can you respin desktop images or look what happened to the last respin, we need kernel 3.4.0-5.11 for Mac
<Riddell> ooh quantal works!
<Laney> a quantal of solace
<xnox> Laney: tooodotoooo toooodotooo tah dah
<Laney> xnox: this release is forever associated in my mind with http://youtu.be/vjcic99S
<xnox> Laney: with 'An error occurred during validation?!'?
<Laney> hopefully not
<xnox> Laney: the link is broken =( me don't see anything
<Laney> http://youtu.be/vjcic99SNog
<Laney> weird, what happened there?
<ogra_> hmm, is the omap3 kernel still not in the archive ?
 * ogra_ doesnt see any arm image rebuilds
<ogra_> infinity, hmm, looking at the ac100 build failure i guess we need to teach live-build to divert flash-kernel during build, it tries to find the boot partition otherwise during update-initramfs
 * ogra_ would be really happy if someone could trigger another armhf rebuild, seems there was a stale archive lock during the last try
<ogra_> oh, looking at the failure mails that seems to apply to all images, apparetnly something is wrong with the archive mirror
<ogra_> lockfile: Sorry, giving up on "/srv/cdimage.ubuntu.com/etc/.lock-archive-sync"
<ogra_> Timed out waiting for archive sync lock!
<ogra_> hmm, and indeed there are two lockfile processes in the processlist on nusakan
<ogra_> cjwatson, ^^^ any idea ?
 * ogra_ doesnt just want to kill them, i'm not sure what exactly triggers them, though having two for the same lockfile seems pretty wrong
<cjwatson> looking
<cjwatson> it's apparently stale; log/ubuntu/quantal/daily-live-20120606.log got killed for some reason I think.  I've broken the lock
<ogra_> thanks, seems there were rebuilds for almost everything that failed due to it
<ogra_> ubuntu-server/precise/daily, ubuntu/precise/daily and ubuntu/quantal/daily-preinstalled is what i got mails for
<cjwatson> somebody who's more familiar with what the RM actually wants rebuilt today should do that (i.e. not me)
<cjwatson> kind of surprised the cron jobs are still on
<ogra_> precise ...
<cjwatson> oh, they aren't, yeah, ok
<cjwatson> I'll just leave those, they'll wait 'til tomorrow
<ogra_> though we need armhf rebuilds (new omap3 kernel) ... i guess i'll trigger these ... if we wait for someone from release team i wont have enough time to test anymore i guess
<ogra_> heh, looks like you moved something by removing the lock :)
 * ogra_ fires off a preinstalled desktop build 
 * stgraber waves
<stgraber> Riddell: not quite EU based at the moment ;) back in Canada
<stgraber> ok, so looking at what happened there, we seem to have everything but Ubuntu Desktop...
<ogra_> just wait until we swallow you too !
<ogra_> stgraber, there was a stale lockfile
<ogra_> colin fixed it, i didnt know what was missing apart from preinstalled (which i triggered a still running build for)
<Riddell> oh new images
<stgraber> ok, thanks. Did anyone actually retrigger Ubuntu Desktop after that?
<ogra_> nope, as i said, i wasnt sure what else had failed
<ogra_> go ahead :)
<Riddell> stgraber: what's the issue needed these respins?
<stgraber> ok, having a look at the pad then. We also have a precise cron running at the moment that I'll wait for before starting another build
<stgraber> Riddell: kernel
<stgraber> Riddell: exploding on mac hardware
<ogra_> why isnt the pad in the topic anymore though ?
 * ogra_ didnt think about looking there 
<Riddell> ogra_ just what I was wondering
<ogra_> :)
<Riddell> people have been saying the pad has issues
<jibel> Riddell, and new ubiquity
<stgraber>           things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or birdseed | melior malum quod cognoscis
<jibel> to fix wireless setup page
<stgraber> gah
<ogra_> stgraber, try again :)
<stgraber> ogra_: 13:25 -!- #ubuntu-release You're not a channel operator
<ogra_> ah, bah
<Riddell> stgraber: if it is in use, what's the URL?
<jibel> stgraber, I updated the pad. Ubuntu Desktop and Wubi have not been rebuilt
<stgraber> http://pad.ubuntu.com/ubuntu-release
<stgraber> jibel: thanks
<jibel> stgraber, but other images are appearing (k|l|edubuntu) so maybe there's a build in progress
<stgraber> jibel: yeah, updating the pad for these. They were in the pipeline, not sure whether they just worked or whether cjwatson triggered them after fixing the lock
 * stgraber waits for things to settle down on nusakan to look at exactly what we're missing and build that
<stgraber> so far it looks like ARM images (both desktop and server), ubuntu desktop and wubi
<stgraber> ogra_: what ARM images are you building? server or desktop?
<stgraber> jibel: wubi is almost built, then I'll look at ubuntu desktop
 * stgraber tries to understand why the previous ARM desktop builds never published to the tracker, nothing seems to have gone wrong there (besides ac100 failing)
<stgraber> oh, ok, got hit by the same lock issue as ubuntu...
 * skaet waves good morning and goes to check the pad
<stgraber> skaet: lock file prevented most of the overnight builds from happening, cjwatson fixed it earlier today, so we're still missing ARM and Ubuntu Desktop
<skaet> thanks stgraber
<stgraber> skaet: Wubi should appear on the tracker anytime now
 * stgraber starts Ubuntu Desktop now
<stgraber> jibel: ETA 1h30-2h for desktop images
<jibel> stgraber, and wubi is broken
<jibel> the exe downloads precise instead of quantal
<stgraber> ev: ^
<cjwatson> stgraber: I didn't retrigger anything
<ev> arghhh
<ev> my mistake
<ev> fixing
<stgraber> cjwatson: right, noticed after checking exactly what was still running. It just unlocked the existing pipeline but by that time, ubuntu desktop and ARM had already timed out. Anyway, should have everything fixed in a couple of hours (maybe I'm a bit optimistic on ARM build time though ;))
<ogra_> ARM should be done soon
<ogra_> its only ac100 left, all others have finished
<ogra_> though we need preinstalled-server too
<ogra_> skaet, ^^^
<stgraber> ogra_: ok, I'll start preinstalled server as soon as your desktop builds are done
<skaet> ogra_, noted. :)
<stgraber> ogra_: does it look like we'll actually have a working ac100 build this time?
<stgraber> well, s/working//
<ogra_> stgraber, no, that will need live-build changes (flash-kernel needs to be diverted, it tries to write to SD card on the builder)
<ogra_> so no ac100 for A1
<ev> right, despite a curiously slow link to the DC, http://people.canonical.com/~wubi/quantal/stable is in place with the fixes for 12.04 references in quantal
<stgraber> http://people.canonical.com/~evand/wubi/quantal/stable
<jibel> ev, I confirm the fix works
<ev> err yes, that url
<ev> thanks stgraber, jibel :)
<jibel> then second stage of the installation crashes :)
<bdmurray> cjwatson: so to be clear on the +queue page I check the checkbox and click accept?  the overrides are unnecessary most of the time correct?
<cjwatson> For SRUs?
<cjwatson> You generally shouldn't need to override SRUs, no.
<bdmurray> cjwatson: yes, thanks
<jibel> ev, the problem with wubi during the second stage is a kernel crash
<jibel> not wubi's fault
<ev> music to my ears ;)
<jibel> collecting logs will be fun, hard lock, black screen
 * skaet suspects no WUBI for A1
<stgraber> ok, starting arm server now
<ogra_> thanks :)
<jibel> skaet, I confirm no Wubi. kernel crash + segfaults in sysctl, python, stty
<jibel> I'll file a bug with the logs
<skaet> Thanks jibel,   is there a bug number now?
<skaet> heh
<jibel> skaet, apart from Wubi there is bug 1009052 on Ubuntu Desktop with Asian languages
<ubot2`> Launchpad bug 1009052 in language-selector "CJK Installation fails with error: poppler-data : Breaks: cmap-adobe-gb1 (<= 0+20090930-2)" [High,Confirmed] https://launchpad.net/bugs/1009052
<skaet> thanks jibel.
<xnox> ev ^^^^
<xnox> i guess it's not wubi specific is it?
 * ev hides
<skaet> xnox,  nope.
<skaet> :)
<xnox> ev: you can come out now.
<ev> phew
<ev> that was a close one
 * xnox realises that I should get wubi buildable before next milestone as per spec
<jibel> xnox, it is not, now I wish it is not the new kernel.
<seb128> jibel, bug #1009052 is a ghostscript issue, somebody needs to merge it with Debian
<ubot2`> Launchpad bug 1009052 in ghostscript "CJK Installation fails with error: poppler-data : Breaks: cmap-adobe-gb1 (<= 0+20090930-2)" [High,Confirmed] https://launchpad.net/bugs/1009052
<seb128> we need that change
<seb128> ghostscript (9.05~dfsg-6) unstable; urgency=low
<seb128>    * Have libgs9 depend on recent poppler-data favored over
<seb128>      gs-cjk-resource.
<seb128> cyphermox_, ^ do you think you could look at that?
<seb128> cyphermox_, maybe no need to merge it but I think the depends need to be changed for zh to be installable
<cyphermox_> seb128: sure, it was my next firefox tab too ;)
<seb128> cyphermox_, thanks, bug reassigned to you ;-)
<jibel> skaet, bug 1009564
<ubot2`> Launchpad bug 1009564 in linux "Quantal Ubuntu Wubi failed to install" [Undecided,New] https://launchpad.net/bugs/1009564
<skaet> thanks jibel
<stgraber> and that's all the rebuilds finally done!
<stgraber> time for food now, will test Edubuntu when I get back
<balloons> jibel, did you see the wubi upgrade failure from last night? https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1009226
<ubot2`> Launchpad bug 1009226 in update-manager "can't load DistUpgradeViewGtk (No module named vte)" [Undecided,Confirmed]
<balloons> or did that cause the re-spin? ;-)
<balloons> also, will the fix for 1009052 also fix jp language?
<ogra_> infinity, will you test mx5 ?
<infinity> ogra_: Can't right now, my mx5 is in the middle of some builds. :/
<jibel> balloons, I saw the upgrade bug.
<jibel> it can be fixed after post-a1
<ogra_> infinity, ah, sad, i should really get one some day
<ogra_> (not that i'm eager to do more image testing though)
<jibel> desktop on mac and x86 are good. I'll do more tests after dinner.
<jibel> import open issues for a1 bug 1009052 and bug 1009564
<ubot2`> Launchpad bug 1009052 in ghostscript "CJK Installation fails with error: poppler-data : Breaks: cmap-adobe-gb1 (<= 0+20090930-2)" [High,Confirmed] https://launchpad.net/bugs/1009052
<ubot2`> Launchpad bug 1009564 in wubi "Quantal Ubuntu Wubi failed to install" [Critical,Confirmed] https://launchpad.net/bugs/1009564
<seb128> jibel, is the cjk one something you want to see in for a respin?
<seb128> skaet, ^
<seb128> the fix is depends change for ghostscript
<skaet> seb128,  given we're at A1,  I'm fine release noting it.   But if a fix is available,  and we need to respin for other reasons, it would be good to include it, certainly.
<seb128> skaet, ok, fix will be uploaded a bit later by cyphermox_
<skaet> thanks seb128 :)
<jibel> seb128, agreed with skaet
<seb128> skaet, jibel: thanks
 * skaet --> lunch,  biab
<stgraber> highvoltage: did you have a chance to test ltsp-live yet? it looks a bit broken here. I'll test some more and see if I can easily fix it
<highvoltage> stgraber: I did, it failed, I didn't have enough time to confirm the failures so I left it out of the test
<dobey> can someone please accept the ubuntuone-client i just uploaded to precise-proposed, as it is the same set of in-progress SRUs, merged with the security fix that was released today
<stgraber> highvoltage: ok, was it stuck configuring openssh?
<highvoltage> stgraber: it got to "ltsp live should be ready to use", I got dhcp on the clients and it seemed to load the kernel but didn't continue from there
<stgraber> ok, so I had a different problem here ... triple checking the md5 as I saw some squashfs errors at one point, might just be corrupted iso
<stgraber> highvoltage: second try booted and worked fine, so just going to blame it on kernel/squashfs/kvm and consider it a pass (good enough for a1) :)
<highvoltage> stgraber: sounds reasonable.
<balloons> skaet, thoughts on when we expect to announce tomorrow? any more respins in the works? I know there's pending fixes
<skaet> balloons,  depends on whether we decide to respin or not, and how the testing is going.
<skaet> most of the bugs we know about, while not good, we can live with for an A1, and they'll get fixed on the next daily.
<skaet> Daviey,  is server going with the 800MB USB form factor this release as well,  or sticking with CD sized images?
 * skaet trying to figure out if Bug 1009553 is invalid (working by designed or there's something that needs documenting) 
<ubot2`> Launchpad bug 1009553 in debian-installer "jeos install oversized" [Undecided,New] https://launchpad.net/bugs/1009553
<cyphermox_> skaet: ghostscript uploaded; if you're looking to respin the zh image.
<slangasek> skaet: does that bug follow from some documented minimum requirements for jeos?
<skaet> cyphermox_, thanks. :)
<skaet> slangasek,  could be,  not familiar with jeos.
<slangasek> I guess that's a question the server team should answer
<skaet> yup,  but if others know,  feel free to chime in.  ;)
<dobey> slangasek: hi. can you please accept the new ubuntuone-client upload to precise-proposed? it's the same SRU set, but includes the security fix patch that was released today as well
<Daviey> skaet: I'd rather we strive for the smaller image, but not be hold to it
<stgraber> dobey: the diff looks a bit confusing (the changelog entry), did you properly use -v3.0.0-0ubuntu1.1 when building the .changes?
<Daviey> skaet: although.. *A2* currently looks around 875M :o
<skaet> Daviey,   could you put a statement out as to what target you're aiming at?
<slangasek> Daviey: do you know if there's documentation somewhere for what the jeos footprint is supposed to be?
<slangasek> dobey: accepted
<Daviey> slangasek: yes, there is.. and we test for it.. i need to double check the figure
<Daviey> skaet: "Unlike the Desktop flavour, we are currently targeting the image to fit onto a standard cd image (703MB).  However, some structural changes are expected for Alpha 2, which will allow us to re-review this sizing requirement"
<Daviey> slangasek: we are still 703MB for max CD, or was that now reduced ?
<skaet> Daviey,  sounds good.  :)
<slangasek> Daviey: are we talking download size, or image size?
<slangasek> Daviey: bug #1009553 that skaet pointed to is about the install footprint, claiming that it's bigger than it should be
<ubot2> Launchpad bug 1009553 in debian-installer "jeos install oversized" [Undecided,New] https://launchpad.net/bugs/1009553
<Daviey> slangasek: image size for minimal install
<Daviey> (formally known as jeos)
<slangasek> sorry, I meant "download size or install size"
<Daviey> slangasek: That bug ius valid, see https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-server-amd64_minimal-virtual/14/testReport/
<slangasek> ok
<Daviey> It's not an A1 blocker in my book.
<slangasek> it's also probably not a debian-installer bug... is there a better place to track it?
<Daviey> The 500MB is arbitrary that we selected, and it should be reduced to fit that.. but for A1 - i'd be happier release noting it
<Daviey> slangasek: no better place i can think of
<Daviey> cd image project?
<slangasek> Daviey: I was thinking ubuntu-meta, since that actually controls the selection of packages included, I think
<skaet> Daveiy,  I put some placeholders into the TechnicalOverview,  massage to something better as time permits on the image size
<Daviey> ta
<balloons> skaet, stgraber I think we've got a whoops on the tracker.. the upgrades have the upgrade test from lucid.. that shouldn't be a supported upgrade
<balloons> i can disable if you agree
<Daviey> That is most certainly a bug.  Nice catch balloons
<balloons> btw Daviey are you and team doing all the testing for the server images?
<Daviey> balloons: yes, both Jenkins and Human
<Daviey> balloons: https://lists.ubuntu.com/archives/ubuntu-server/2012-June/006328.html
<balloons> k, we had some testing during the precise final iso, but I've not focused on getting community testing for the server images
<balloons> for this alpha I mean to say
<stgraber> balloons: actually it's a bug we shouldn't try to fix until we have the new website
<stgraber> balloons: currently we have both precise and quantal on the tracker
<stgraber> balloons: quantal should only have precise => quantal upgrades
<stgraber> balloons: but precise definitely needs lucid => precise
<Daviey> balloons: yeah, we expected that :P
<balloons> stgraber, yes.. so I should re-enable it then?
<stgraber> balloons: yeah
<balloons> :-)
<stgraber> balloons: it's easier to remember to consider 1/2 as a pass than to go look at oneiric => precise upgrade results to check if they aren't actually lucid => precise :)
<stgraber> and we'll have that fixed for alpha2 with the tracker update
<balloons> k
<balloons> can we get http://www.ubuntu.com/testing updated? who can help with this?
#ubuntu-release 2012-06-07
<jbicha> any idea where bug 1001609 should be assigned to?
<ubot2> Launchpad bug 1001609 in ubuntu "Changelogs not being uploaded to changelog server" [Undecided,Confirmed] https://launchpad.net/bugs/1001609
<ScottK> jbicha: launchpad?
<skaet> balloons - the update for http://www.ubuntu.com/testing will get updated tomorrow as part of the publishing of Alpha 1.    all in hand.
<cjwatson> ScottK: Launchpad doesn't control changelogs.ubuntu.com
<cjwatson> It's an mvo thing
<xnox> Is there a report / qa which tracks version numbers of the packages, specifically those that have versions higher in precise* >> quantal*
<xnox> ?
<cjwatson> xnox: No standing one, but I can generate that on demand, and usually periodically do in the early parts of a cycle
<cjwatson> I wrote a swiss army knife thing called "suite-diff" years ago
<cjwatson> (I think it may have been my first Python program, cough)
<xnox> right =))))
<xnox> cjwatson: I have noticed that imagemagic had precise-security >> quantal; and that lvm2 precise-proposed was/is actually >> quantal (well now it's diverged)
<cjwatson> precise-updates > quantal currently: language packs plus bind9, firefox, openssl098, postgresql-9.1, squid3, ubuntuone-storage-protocol
<xnox> not too bad.
<cjwatson> I'll see about copying those after alpha-1
<xnox> What about -security > quantal?
<cjwatson> -security gets copied to -updates
<xnox> oh ok.
<xnox> aha "updates, security (main)"
<cjwatson> I generally don't enforce -proposed > next-devel, because early in a cycle there's still a fair bit of uploading stuff direct to -proposed and usually maintainers have other plans for next-devel
<xnox> and a separate entry for the set in stone release =)
<xnox> cjwatson: ok. I see your point.
<infinity> cjwatson: It seems a bit late in the cycle to be doing any precise->quantal copies.  I'd really rather things got their own upload so they built with the Q toolchain.
<infinity> cjwatson: Y'know, especially where the toolchain in precise produces binaries that aren't compatible with Q...
<infinity> *cough*armel*cough*
 * infinity really sleeps now, having had his last opinion on the Internet for the night.
<cjwatson> infinity: mm, perhaps
<xnox> infinity: have fun with imagemagick
<xnox> on armel
 * xnox hides
<jibel> seb128, skaet bug 1009928
<ubot2> Launchpad bug 1009928 in ghostscript "Ubuntu Desktop Netboot install failed: unmet dependency - poppler-data Breaks cmap-adobe-japan1 (<= 0+20090930-2)" [High,New] https://launchpad.net/bugs/1009928
<jibel> seb128, with latest ghostscript
 * cjwatson wonders why a bug about poppler-data and cmap-adobe-japan1 is filed on ghostscript.
<jibel> because bug 1009052 has been reassigned to ghostscript
<ubot2> Launchpad bug 1009052 in ghostscript "CJK Installation fails with error: poppler-data : Breaks: cmap-adobe-gb1 (<= 0+20090930-2)" [High,Confirmed] https://launchpad.net/bugs/1009052
<seb128> cjwatson, the issue (or part of the issue) was that libgs9 was depending on gs-cjk-resource but poppler-data Conflicts with gs-cjk-resource now (and zh depends on poppler-data)
<seb128> jibel, thanks, I guess I should get a quantal install to test that out, I just pointed what was obvious from your log yesterday
<cjwatson> does this break images as well as netboot?
<cjwatson> wurgh, I thought about doing a merge but what a nightmare; semi-independent packaging of upstream releases all over the place
<seb128> cjwatson, I think it makes the zh depends uninstallable ... I'm setting up a quantal env to test
<seb128> cjwatson, merge of what?
<cjwatson> ghostscript
<seb128> cjwatson, well it looks like simply that poppler-data is not installable on q and some locales pull it in
<seb128> cjwatson, cyphermox has a full merge but he went for the easy depends fix for a1 yesterday and said he would upload the merge after a1
<seb128> since the merge was not trivial
<jibel> cjwatson, it breaks installations with asian languages
<cjwatson> so if he's done the easy depends fix, surely a new bug about this doesn't belong on ghostscript
<cjwatson> because that part of it has apparently been fixed
<seb128> cjwatson, right, I'm checking what's the new issue, a min
<cjwatson> (and I wonder why 1009052 is still open)
<cjwatson> language-selector has matches in data/pkg_depends for that cmap* stuff
<seb128> cjwatson, cyphermox didn't list the bug in the changelog it seems, I'm closing it
<seb128> ghostscript (9.05~dfsg-0ubuntu5) quantal; urgency=low
<seb128>   * debian/rules: Have libgs9 depend on recent poppler-data favored over
<seb128>     gs-cjk-resource.
<seb128> cjwatson, I don't know a lot about the cmap- stuff but reading the poppler-data entry from http://packages.qa.debian.org/p/poppler-data/news/20120204T162616Z.html
<seb128>      - add {Conflicts:, Replaces:, Provides:} to gs-cjk-resource, cmap-adobe-korea1,
<seb128>        cmap-adobe-cns1, cmap-adobe-japan1, cmap-adobe-japan2, cmap-adobe-gb1
<seb128>  
<seb128> cjwatson, it seems like language-selector should have the cmap-adobe-* replaced by poppler-data
<seb128> though I would prefer to have somebody who knows what those cmap packages are used for to confirm it
<seb128> debian/changelog:  * data/pkg_depends: Add cmap-adobe-* packages for ghostscript. (LP: #496012)
<seb128> cjwatson, jibel: I can do an upload of l-s with that change if you want
<jibel> seb128, pitti proposed to have a look when he's back on Monday
<seb128> cjwatson, jibel: http://pastebin.ubuntu.com/1028368/ ?
<tkamppeter> cjwatson, we can also move the SRU on system-config-printer to -updates. Two users have confirmed that the SRU solves their problems (by setting up printers with non-IPP protocol by default). One bug I detached from the SRU as the user's problem is not covered by the SRU.
<cjwatson> tkamppeter: done; as usual with cases where bugs have been "detached", you'll probably need to fix up bug states after the janitor has closed them
<seb128> cjwatson, I've rebased the changelog on the current version, but do the change seems fine to you? should I upload that?
<cjwatson> seb128: Yeah, that looks right
<cjwatson> Go ahead
<seb128> cjwatson, done, thanks
<ev> hm, why does /srv/cdimage.ubuntu.com complain about divergence when I try to pull
 * ev digs
<ev> stgraber: was your branch not bound when you committed? You have r1424 in /srv/cdimage.ubuntu.com, but I have it in /srv/cdimage.ubuntu.com/bzr/private/cdimage
<cjwatson> Never mind binding, that implies directly pushing to /srv/cdimage.ubuntu.com rather than going via the canonical branch storage areas
<cyphermox> seb128: I'm currently on choppy 3g; but the cmap stuff are definition files which are supposed to be shipped equally by b
<cyphermox> seb128: I'm currently on choppy 3g; but the cmap stuff are definition files which are supposed to be shipped equally by both the -cmap packages and poppler-data
<cyphermox> oh boy, that line is worse than I thought
<seb128> cyphermox, ok, so we changed to use poppler-data which should be ok
<cyphermox> seb128: AFAIK yes. I didn't verify the claim but that's what the poppler-data description says
<cyphermox> bbl
<skaet> good morning
<skaet> jibel,   looks like 1009928 is a duplicate of bug 1009052.   From yesterday's discussions (and on the pad) we decided to not respin for it explicitly, but treat it as something to include, if something else forced a respin otherwise document.  Did something change overnight?
<ubot2> Launchpad bug 1009052 in language-selector "CJK Installation fails with error: poppler-data : Breaks: cmap-adobe-gb1 (<= 0+20090930-2)" [High,Fix released] https://launchpad.net/bugs/1009052
<jibel> skaet, nothing changed, no respin for this defect. The second bug was with a netboot install, after the first bug has been fixed and with a different package, that's why I filed another bug.
<skaet> jibel,  thanks.  :)
<jibel> skaet, and it still unclear to me if they are duplicates because netboot is still failing with latest language-selector seb128 uploaded this morning
<seb128> jibel, can you give me the error log?
<jibel> seb128, yes, next thing the queue :)
<jibel> skaet, https://wiki.ubuntu.com/QATeam/ReleaseReports/QuantalAlpha1TestReport
<skaet> thanks jibel,  :)
<cjwatson> skaet: It wasn't a duplicate as such; there were multiple causes.
<skaet> cjwatson,  thanks,  bug marking probably needs to be changed then.
<skaet> jibel,  any arm results in ?   I thought ogra was testing mx5 yesterday?
<jibel> gema, is testing desktop on omap4
<gema> yes
<gema> skaet: it's failing for me , I am troubleshooting with ppisatti
<gema> skaet: it works for him
<skaet> gema,  interesting.   ok, we'll hold off on deciding about arm for omap4 for a bit.
<gema> skaet: ok, I will keep you posted
<skaet> thanks gema
<jibel> seb128, https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/1009928/+attachment/3179189/+files/netboot-desktop.syslog
<ubot2> Launchpad bug 1009928 in ghostscript "Ubuntu Desktop Netboot install failed: unmet dependency - poppler-data Breaks cmap-adobe-japan1 (<= 0+20090930-2) (dup-of: 1009052)" [High,New]
<ubot2> Launchpad bug 1009052 in language-selector "CJK Installation fails with error: poppler-data : Breaks: cmap-adobe-gb1 (<= 0+20090930-2)" [High,Fix released]
<skaet> Riddell,   ScottK,   not much testing on Kubuntu Desktop marked up on the tracker.   More done than is showing there?
 * skaet notes that Edubuntu is looking good to release.
<skaet> Wubi's not going out
<jibel> skaet, I added 1009226 to the section 'Migration' of the tech overview. update-manager's UI crashes when upgrading to Quantal (do-release-upgrade as fallback)
<skaet> Thanks jibel.  :)
<Riddell> skaet: no that's all we're going to get for alpha 1
<skaet> Riddell,  hmm,  most of the manditory tests haven't been run,  are the images reasonably free of installer issues, or are we causing more problems by releasing them, than not?
<skaet> Riddell,  also no data available  on doing the upgrades from Precise - given what Lubuntu's been seeing,  am worrying that we may need to be providing some guidance
<skaet> infinity,  are the arm core images ok to ship?   no results on the tracker.
<Riddell> skaet: very little has changed so I don't forsee any problems
<Riddell> I don't think I've ever tested upgrade on an alpha 1, it's certainly not what I'd recommend to people
<gema> skaet: hggdh has verified armhf+omap4 server and pgraner armhf+omap4 desktop
<gema> skaet: my environment was buggy
<seb128> jibel, you are sure you got language-selector 0.81?
<hggdh> and I will do desktop again as a validation
<gema> skaet: all is looking green and shiny
<gema> arm-wise
<skaet> gema,  thanks.
<jibel> seb128, that's what apt tells me
<seb128> jibel, ok, I don't know then, I see nothing depending on cmap-adobe-japan2 and language-selector has no mention of it in its current version
<stgraber> ev: hmm, I did use "bzr co" :)
<stgraber> ev: oh, I see, checkout location is wrong...
<jibel> seb128, I think the problem is that ubuntu-desktop recommends cmap-adobe-japan2 but poppler-data breaks on it
<seb128> jibel, I though that recommends would be ignored rather than breaking the install
<stgraber> ev: fixed, sorry for that
<ev> stgraber: no worries!
<ogra_> hey, whats the reason omap3 was removed from the tracker
<skaet> ogra_ no results on the tracker
<skaet> no indication that the testing had started....
<ogra_> skaet, sorry, its a bank holiday in germany, i only stzarted testing 1h ago
<ogra_> (since apparently Qa doest do omap3)
<ogra_> and i'm only done with omap4 yet
<skaet> ogra_  can you please mark up on the tracker which ones you're testing,  so I don't go and remove them as well ...  ;)
 * skaet is doing the cull right now.
<ogra_> yeah, i didnt like to be online at all oon my vacation day, so i only went there now to submit my results
<ogra_> hmpf, but omap3 seems a failure anyway
<stgraber> skaet, ogra_: ^ re-enabled omap3 so ogra_ can post his results
<skaet> thanks stgraber
 * ogra_ hugs stgraber 
<skaet> gema, jibel - are there any results available from the automated test setup for the netboot arm omap4  images?
<ogra_> skaet, armhf -core done
<stgraber> prepare for the flood ;)
<skaet> Thanks ogra_   :)
<stgraber> oh, right, we have more than 25, good ;)
<stgraber> smoser: can you post the testing results? ^
<smoser> stgraber, testing results of?
<smoser> i can go through the monkey work of copying https://jenkins.qa.ubuntu.com/view/Quantal/view/All%20Quantal/job/quantal-server-ec2/ to iso tracker
<stgraber> smoser: yep, that's what we need on the tracker. I've been talking with Ben at UDS about just using the tracker API to push these but AFAIK he didn't work on that script yet, sorry :)
<jibel> skaet, it's running, I'll update results soon-ish
<skaet> thanks jibel
<jamespage> stgraber, re using the tracker API to publish ec2 test results -  thats something I probably need to pickup
<jibel> jamespage, I wrote this http://paste.ubuntu.com/1028694/
<jibel> not tested with ec2 but that should work
<jamespage> jibel, ta
<jamespage> so long as I can reference by ami thats good
<seb128> jibel, I've undupped bug #1009928 but I don't know where the remaining issue is
<ubot2> Launchpad bug 1009928 in ghostscript "Ubuntu Desktop Netboot install failed: unmet dependency - poppler-data Breaks cmap-adobe-japan1 (<= 0+20090930-2)" [High,New] https://launchpad.net/bugs/1009928
<seb128> jibel, that will need input from installer people
<cjwatson> Err, I don't see how that's an installer issue
<jibel> seb128, ok thanks.
<cjwatson> It's about the dependency structure of the packages being installed, unlikely to be anything to do with the installer ..
<ogra_> also why do you do a desktop install at all ?
<seb128> cjwatson, would the packages installation fail if a recommends can't be installed or would the recommends be ignored?
<ogra_> for testing the netboot installer functionality i would just go with the defaults
<seb128> cjwatson, the only place I can see where cmap-adobe-japan1 is mentioned is that ubuntu-desktop recommends it
<cjwatson> It's cmap-adobe-japan2 not japan1 in that syslog, and that has Task: ubuntu-desktop
<cjwatson> Find out why that is
<seb128> cjwatson, but I though recommends would be ignored when they can't be installed rather than making the install bail out
<cjwatson> Not if they conflict like this
<seb128> sorry I meant cmap-adobe-japan2
<seb128> ok
<seb128> so I guess the remaining issue is that ubuntu-desktop should stop recommending it
<seb128> not sure if we should recommends poppler-data instead though
<seb128> we avoided seeded it in the past because of space issues
<cjwatson>  * (cmap-adobe-japan2)           # gs-cjk-resources prefers cmap-adobe-japan1 which is much bigger; language-selector will pull in the right one for a language
<cjwatson> That kind of suggests to me that you should just unseed it
<seb128> ok, thanks
<cjwatson> Since it looks like that was there to force a preferred alternative dep
<stgraber> skaet: oh right, should have told you, my cron job isn't really clever and just re-adds anything that's missing ^  :)
<stgraber> skaet: I'll turn the cron job off and remove these again
<skaet> thanks stgraber.
<bdmurray> It occurred to me that maybe the Ubuntu SRU team should be subscribed to the tag regression-proposed in Launchpad
<skaet> bdmurray,  indeed, that could help with the visibility .
<bdmurray> only 27 bugs have this tag now so it wouldn't be much more mail
<cjwatson> https://code.launchpad.net/~cjwatson/launchpad/pocket-permissions/+merge/109192 *sweat*
 * skaet notes we'll need to update https://help.ubuntu.com/community/BurningIsoHowto or create a separate page, for the larger desktop images
<skaet> Quantal Alpha 1 is released.
<skaet> torrents are comming on line slowly, but rest of images in place.
<skaet> hmm.. that didn't come out right
<skaet> torrents are slowly coming on line.
<infinity> skaet: so, we're good to go for thawing and copying proposed to release?
<infinity> Looks like.
<skaet> infinity,  yes,  good to thaw and copy proposed to release
 * infinity does that.
 * skaet --> errand,  back in an hour or so.   
<skaet> stgraber,  you've got the baton.  :)   And thank you for the excellent work on getting Alpha 1 published! !  :)
<Daviey> stgraber: if we were smart, we'd make a torrent-seeder juju charm :)
<stgraber> Daviey: and deploy it on canonistack ;)
<Daviey> stgraber: yeah.. and every other cloud for global coverage :)
 * skaet --> back
<skaet> stgraber,  thanks for changing over the iso tracker.    cron job re-enabled too?
<stgraber> skaet: wasn't me for the ISO tracker :) but I'm doing the nusakan side of things now (isotracker.conf + cronjob)
<skaet> thanks stgraber.  :-)
 * skaet has disabled the milestone now
<stgraber> skaet: should I move the bugs?
<skaet> stgraber,  hold off please,  want to go through them manually.  :)
 * skaet collecting stats, looking for interesting things.
<stgraber> skaet: list: http://paste.ubuntu.com/1029321/
 * skaet looking
<skaet> thanks stgraber,  got what I need,   please go ahead.
<stgraber> skaet: running
<bdmurray> shouldn't quantal be set to supported?
<bdmurray> http://changelogs.ubuntu.com/meta-release-development
<infinity> bdmurray: No.
<infinity> bdmurray: Cause it's not.
<bdmurray> infinity: ah, I see what the problem was
<stgraber> bdmurray: Prompt=normal?
<stgraber> (assuming your problem was do-release-upgrade -d not telling you about quantal)
<bdmurray> stgraber: yes, that's what I needed.  I wonder if that is worth release noting in the upgrade section
<stgraber> bdmurray: I guess so, it's not really obvious unless you know the upgrader very well and AFAIK it's not visible in the UI
<bdmurray> slangasek: did you say packages would be rejected if they didn't meet SRU criteria?
<bdmurray> I'm tired of looking at the same ones missing info
#ubuntu-release 2012-06-08
<RAOF> bdmurray: If they're not worth SRUing, they should be punted from the queue. If they may be worth SRUing, but we've been waiting for information on the bug for a while, then they can be punted from the queue (and mentioned in the bug that they've been punted, and what the uploader needs to do to actually get them accepted next time they upload it)
<micahg> packages can be unrejected as well if appropriate
<RAOF> How long does that remain true?
<infinity> As long as the package is in the rejected queue.  Was that a helpful response? :P
<RAOF> I could rephrase my question as: under what conditions does a package leave the rejected queue? :P
<infinity> RAOF: When it moves to another queue.
<infinity> RAOF: Or when someone or something decides to purge the queue for space reasons.  But I'm not sure if or when that happens anymore.
<RAOF> Ok. So there's no expiry from that queue, and it'll sit there indefinitely unless something happens to it?
<RAOF> Heh.
<infinity> Keeps track of bugs.
<infinity> You can assign them to people.
<infinity> Maybe you could fix them eventually.
<infinity> ^-- The phabricator website is possibly the funniest thing I've read all week.
<RAOF> So, an indeterminate period, but essentially long enough.
<cjwatson> RAOF: No expiry at all that I'm aware of.
<cjwatson> RAOF: Though of course eventually things there may become non-unrejectable due to being superseded by other updates.
<wildint> is this the right channel to report something odd with the download links?
<cjwatson> Probably
<wildint> so I went to the server page, copied the download link for 64 bit, then tried to download is with wget, it ended up redirecting to an i386 iso
<wildint> now somehow after exploring around mirrors looking for the files I'm stuck downloading from uk mirrors even though I'm in the US
<slangasek> wildint: which page, exactly?
<wildint> http://www.ubuntu.com/download/server/thank-you?distro=server&release=lts&bits=64
<slangasek> hmm; that gives me a link to ubuntu-12.04-server-amd64.iso, which is correct
<wildint> using wget
<cjwatson> That redirects to ubuntu-12.04-server-amd64.iso for me too
<slangasek> ah
<wildint> firefox gets me the right link
<cjwatson> wget works for me
<wildint> but I want to download on a headless server
<cjwatson> Proxy request sent, awaiting response... 302 Moved Temporarily
<cjwatson> Location: http://ubuntu.virginmedia.com/releases//precise/ubuntu-12.04-server-amd64.iso [following]
<wildint> let me paste what I got
<slangasek> http://mirror.ox.ac.uk/sites/releases.ubuntu.com/releases//precise/ubuntu-12.04-server-amd64.iso here
<cjwatson> Obviously different redirects each time, but I've just tried it 20 times or so and I get amd64 every time
<slangasek> which... is a strange choice of mirror for me as well
<cjwatson> wildint: Make sure to paste your wget command line too
 * cjwatson has a suspicion
<wildint> http://pastebin.com/4BkyPa2E
<slangasek> wildint: you have to quote the url
 * cjwatson wins
<slangasek> :)
<cjwatson> but slangasek was too quick
 * slangasek suspected the same :)
<wildint> was not expecting that issue, but wasn't thinking about it
<cjwatson> What "wget http://www.ubuntu.com/start-download?distro=server&bits=64&release=lts" translates to is: 2,13,14,16,17,32,33,64,71]
<cjwatson> oops
<cjwatson> "wget http://www.ubuntu.com/start-download?distro=server" in the background; set bits=64 shell variable in the background; set release=lts shell variable
<wildint> yup quotes does it
 * wildint wishes https://help.ubuntu.com/community/UbuntuHashes was linked off the download page somewhere
<cjwatson> jdstrand: Is anything happening with bug 993304?  It's blocking at least three packages now.
<ubot2> Launchpad bug 993304 in jbigkit "[MIR] jbigkit" [Medium,Confirmed] https://launchpad.net/bugs/993304
<jdstrand> cjwatson: oh! I missed that it got assigned to me. I'll look at it this morning
<Riddell> how do I do new queue through launchpad?
<Riddell> ah found it https://launchpad.net/ubuntu/quantal/+queue
<xnox> cjwatson: have you been running auto-syncs after alpha1? or are we still in a 'freeze'?
<ogra_> iirc inifinity unfreezed and processed -proposed yesterday
<ogra_> not sure that also enabled auto-syncs though
<ogra_> (it should indeed)
<xnox> ogra_: last time i heard auto-syncs still require a human =))) it was work in progress to make it fully automatic
<ogra_> ah
<ogra_> then i'm not up to date ... feel free to ignore my babbling ;)
<cjwatson> xnox: I haven't done it yet, but will do today
<xnox> cjwatson: ok cool =) a couple of boost1.49 transitions will land =)
<cjwatson> ogra_: Yeah, auto-syncing is much better than it was, but it's never been fully automatic
<ogra_> ah
<cjwatson> We just try to run it often enough to make it look like it is ;-)
<ogra_> heh, couldnt cron just do that ?
<ogra_> or is that to dangerous
<cjwatson> We're almost there, but not quite
<ogra_> k
<cjwatson> In particular, bug 1006917 is a current blocker
<ubot2> Launchpad bug 1006917 in launchpad "Distribution archive owners cannot necessarily copy packages" [Low,Triaged] https://launchpad.net/bugs/1006917
<cjwatson> Once it's possible, though, I certainly want to fully automate it
<cjwatson> It's all very well having busywork I can do before I've entirely woken up, but it does get a bit old
<cjwatson> stgraber: ^- I think the above "accepted" entries are queuebot getting desperately confused.  For example, kdesdk [i386] is still in the queue.  Maybe it got confused by the temporary appearance of a large pile of syncs?
<cjwatson> (Unfortunately I didn't quite manage to accept them in time to stop queuebot spamming us.)
<stgraber> cjwatson: I'm not sure how that could happen in the code, though it might have been hit by a LP timeout or something similar (though it's supposed to just ignore those)
<cjwatson> stgraber: I was wondering if maybe it had ignored it a bit too hard and concluded that the timed-out things didn't exist
<bjf> can the armadaxp kernels in the Precise upload queue get some love /
<stgraber> cjwatson: could be, currently the code checks for .status over the API and shows accepted if .status != "Rejected". So maybe it got some weird status back from LP and assumed it was accepted
 * stgraber needs to implement a muting feature in queuebot so we can mute a specific pocket for a while directly from IRC :)
<ogra_> ++
<cjwatson> rejecting duplicate sudo copy to precise-updates
<cjwatson> (my fault)
<cjwatson> bjf: looking
<cjwatson> bjf: will it break anything that the tracking bug isn't listed in .changes?
<bjf> cjwatson, double checking
<bjf> cjwatson: there are only 4 units in the world and they are all in our QA lab
<cjwatson> Hah
<bjf> cjwatson: a somewhat gross exaggeration but fairly accurate
 * ogra_ bets marvell has some too :)
<bjf> cjwatson: thanks
<jamespage> please could someone reject my upload of samba to lucid-updates - had a friday afternoon moment
<cjwatson> bjf: And fixed up the incorrect overrides now too, maybe not before your script notices them
<bjf> cjwatson: thanks again
<Daviey> nova preicse SRU rejected, as one more patch is required.
<jamespage> Daviey, pls could you reject samba from the lucid queue - I uploaded targetted to the wrong pocket
<Daviey> jamespage: done
<jamespage> Daviey, ta - friday afternoon moment :-)
<Daviey> heh
 * stgraber tests new queuebot with the muting feature
<stgraber> mute queue new quantal-release
<stgraber> unmute queue new quantal-release
 * stgraber bumps threads/sub-processes a bit higher on the todo ;)
<stgraber> so you can now use "mute queue", "mute queue <queue>", "mute queue <pocket>", "mute queue <queue> <pocket>", "mute queue <pocket> <queue>" and "mute tracker"
<stgraber> they all have matching "unmute"
<stgraber> and just typing "mute" lists the current entries if any
<stgraber> cjwatson: ^
<stgraber> oh, and it's not persistent (nothing in queuebot is persistent at the moment)
<infinity> stgraber: No persistent seems like a feature anyway.
<stgraber> barry: what are you doing in the queue? ^
<barry> stgraber: good question.  the only thing i've uploaded recently is dbus-python.  what is ^^ ?
<barry> oh, that's the package 'barry' :)
<stgraber> yeah ;)
<barry> grrrr
<skaet> :)
<highvoltage> closest thing to me in the archive is "jove" (jonathan's own version of emacs) and I use vim anyway.
<stgraber> skaet, jibel: just finished implementing the new download link fallback feature in the tracker. So with the next rollout, no more need to duplicate them for every release, SERIES and VERSION will be recognized as place holders and fallback entries will be displayed unless a series-specific one is added.
<skaet> stgraber,  yay!  :)
<cjwatson> stgraber: great, thanks!
<barry> queuebot: you are interrupting my nap!
 * slangasek chuckles
<bdmurray> I used sru-release for a couple of packages in precise-propsed before realizing it was Friday afternoon
<bdmurray> so I'm gonna leave those packages there waiting for approval
<xnox> bdmurray: have a good weekend =)
#ubuntu-release 2012-06-09
<phillw> ooh, bugga, they did say the rules for queuebot were not persistant!
<cjwatson> mute ubuntu-release new quantal-release
<cjwatson> er, yeah, I should read the docs
<cjwatson> mute queue new quantal-release
<cjwatson> queuebot: mute queue new quantal-release
<cjwatson> stgraber: Does it have a whitelist of allowed users, or does it just not say "Added mute entry: ..." any more
<cjwatson> Ah, it's just slow :-)
<stgraber> cjwatson: yeah, I really need to move the queue refreshes into a separate thread/process to fix that :)
<cjwatson> mute
<cjwatson> unmute ubuntu-release new quantal-release
<cjwatson> mute
<cjwatson> queuebot: unmute ubuntu-release new quantal-release
<cjwatson> unmute ubuntu-release new quantal-release
<cjwatson> stgraber: ^- um
<stgraber> unmute queue new quantal-release
<cjwatson> oh DOH
<cjwatson> sorry :)
<cjwatson> I seem to have syntactic confusion in my head
<stgraber> well, I guess it'd help if the list returned by "mute" would be a bit nicer (rather than simply dumping the python list ;))
<Daviey> cjwatson: hey, can you see any issues with upgrading the bzr format for sync-blacklist?
<debfx> could someone please promote libkipi9 to main (libkipi8 was in main already)
<cjwatson> Daviey: nope, makes sense - done
<cjwatson> debfx: done
<debfx> thanks
<cjwatson> Daviey: (well, in progress, presumably LP will get round to it at some point)
<cjwatson> Ah, there it is
#ubuntu-release 2012-06-10
<Daviey> cjwatson: thanks
<cjwatson> mute queue new quantal-release
<cjwatson> unmute queue new quantal-release
<Daviey> Has anyone been doing simulated builds of ubuntu-server?
<infinity> Daviey: As opposed to real ones?
<cjwatson> mute queue new quantal-release
<cjwatson> (bulk-accepting 39 binary NEW entries synced from Debian)
<cjwatson> unmute queue new quantal-release
<micahg> could someone please promote libblas3 to main, the dev package is already in main (as is the source)
<cjwatson> micahg: done
<micahg> cjwatson: thanks
#ubuntu-release 2013-06-03
<tseliot> can an admin approve nvidia-modprobe and nvidia-persistenced in saucy, please?
<mlankhorst> is the component for all the lts-raring packages correct? it seems that they ended up in universe rather than main
<tseliot> someone will have to move the binaries to main
<mlankhorst> ah
<phillw> bdmurray: would you have 30 minutes to spare to hold a classroom session during the week Mon 24th June --> Sun 30th June on filing a good bug and following it up? Gema did the session during Raring (and her notes are available). I'll move my introduction one to be 30 mins before any time that you could spare. https://wiki.ubuntu.com/Testing/Activities/Classroom/Saucy#Section_2
#ubuntu-release 2013-06-04
<didrocks> infinity: Mirv: hey! what's the status on raring unity SRU? It's seem it's again under review. I don't want us to have to reupload again because after a month, the build files are lostâ¦
<Mirv> didrocks: infinity should have it under radar, hopefully there's no obstacles for the reviews to happen this week
<didrocks> ok, let's cross fingers :)
<mlankhorst> ty
<infinity> didrocks: I'll get to it this week.  I still think we should change that process to one that won't lose files, mind you.
<infinity> didrocks: s/won't/can't/
<didrocks> infinity: yeah, that would be helpful, not sure how though
<seb128> why would we loose files?
<infinity> didrocks: I recommended to Mirv that you stage SRUs in an interim PPA where you're not constantly re-uploading dailies, so things won't time out while they're pending review/copy.
<infinity> seb128: PPA history isn't forever, superseded uploads go away after a while.
<seb128> oh, I see
<infinity> seb128: And copies in the queue aren't actually copies, they're just pointers back to the original until they're accepted.
<seb128> ok
<didrocks> infinity: well, but we still want to know if the newest commits are building
<didrocks> and not introducing regressions in the tests
<seb128> well, if we take over a month to accept SRUs for you main desktop component we have another issue
<seb128> for our main*
<infinity> didrocks: Right, hence the SRU PPA.  So, you keep doing the daily thing as always, but when you have a "blessed" set you want to SRU, you copy-with-binaries to the SRU PPA, and then copy to foo-proposed from there.
<infinity> didrocks: And don't delete/supersede them until they're accepted (or until you want a new version instead).
<didrocks> infinity: yeah, that's an option, I will need to hack around, not on top of the list, but that's an acceptable worfklow IMHO
<infinity> seb128: Taking too long to review it was a problem, and I'll fix that, but it's still not ideal to have a source that can go away (there's no service guarantee for superseded PPA packages, nor should there be).
<seb128> infinity, ppa copies should do an actual copy, it would give us a diff to review in the queue and persistance ;-)
<infinity> didrocks: Anyhow, for now, these ones shouldn't disappear before I review them.  We'll be good.  But we *should* treat superseded packages as if they don't exist.
<didrocks> infinity: yeah, understood, I didn't know that the copy binaries was just a pointer and not a real one, but with the sru ppa workflow, that should be fine
<infinity> seb128: That's debatable.  The diff bit, we'll get via other means.  The persistance thing is irksome, but I'm not sure it's worth the code changes to fix/change that.
<xnox> infinity: please demote boost1.49 to universe =)
<infinity> xnox: Done.
<xnox> infinity: thanks.
<infinity> (And yay)
<infinity> xnox: I still have a bunch of boost1.53 stuff that's in main because I just promoted the lot to make the transition easier.  Now that you're done transitioning, does that mean the 1.53 stuff listed on component-mismatches should be safe to demote?
<xnox> infinity: I would think so, however you choose. all of these are build from the source package which is in main, the mpi half is all in universe.
 * xnox goes to collapse boost1.49 universe+main source package into one.
<infinity> And by "collapse", you mean "remove the Ubuntu delta"?
<xnox> infinity: well, checking if it can be synced.
<infinity> xnox: I'm heading to bed, but poke me when you've done that, so I can remove the -mpi source package.
<xnox> infinity: sure. thanks.
<xnox> infinity: bug 1187299
<ubot2> Launchpad bug 1187299 in boost-mpi-source1.49 (Ubuntu) "Please remove boost-mpi-source1.49 from the archive" [Medium,Triaged] https://launchpad.net/bugs/1187299
<infinity> xnox: Sure, can't remove the source until all the binaries change lineage (ie: once the synced source builds everywhere), but I'll do it later.
<xnox> infinity: cool, thanks. Will remember the timing. (I guess if removed early the binaries will end up in the new queue again...)
<infinity> xnox: Well, more to the point, it would render a bunch of stuff unbuildable/uninstallable.
<xnox> =)
<rsalveti> seb128: didrocks: any of you want to take it ^? :-)
<seb128> rsalveti, \o/
<seb128> rsalveti, I can have a look
<didrocks> thanks rsalveti, seb128 :)
<infinity> Why do I have a feeling that'll be a "fun" review, if one's thorough?
<seb128> rsalveti, what are you doing up? did you work all night to get it uploaded?
<rsalveti> seb128: there are quite a few patches there, which I already did most of the clean up, and working to get them upstream
<seb128> ok
<rsalveti> seb128: well, had to review copyright and fix a few other things :-)
<rsalveti> don't want to be the blocker :-)
<rsalveti> infinity: fun indeed :-)
<rsalveti> didrocks: I believe qtubuntu-media will fail, due change in the lib name, so I'll be fixing as soon we start landing the new packages
<didrocks> rsalveti: ok, and about ofono, apart from telepathy-ofono that we add ourself, anything else?
<rsalveti> didrocks: guess that would be all, ofono-qt and telepathy-qt5 only, which will be available in a few
<didrocks> rsalveti: perfect, it seems everything is arriving at the right and same time
<didrocks> rsalveti: jibel and I are continuing deploying otto instead of UTAH
<rsalveti> didrocks: right
<rsalveti> infinity: don't you ever sleep as well?
<infinity> rsalveti: No one waiting in bed for me.  What's your excuse, young man?
<rsalveti> infinity: haha, just to get stuff done :-)
<infinity> rsalveti: Well, your stuff is done.  Shoo.
<rsalveti> infinity: :-)
<rsalveti> seb128: the copyright file is a bit scary as well
<rsalveti> tried my best to put everything in there
<seb128> rsalveti, don't worry, after the qt5 stack I'm sure that one is going to be fine :p
<rsalveti> haha, ok :-)
<seb128> rsalveti, anyway I will review it today but don't block on that to go get some sleep, I will have my review comments by the time you wake up tomorrow (or later today rather)
<rsalveti> seb128: sure, np
<rsalveti> seb128: 5 patches just got accepted: https://github.com/libhybris/libhybris/commits/master
<infinity> rsalveti: Is upstream done being mad at us, then?
<rsalveti> infinity: yup
<infinity> \o/
<tseliot> can an admin please approve nvidia-persistenced and nvidia-modprobe in saucy?
<seb128> rsalveti, great ;-)
<infinity> tseliot: nvidia-modprobe confuses me.  Doesn't the X driver do that automagically?
<infinity> tseliot: Err, and persistenced claims to do the same thing...
<infinity> I suspect one of those descriptions is a lie. :P
<tseliot> infinity: oops, I forgot to update the description of nvidia-persistenced. I guess I used the same packaging scripts as a base
<infinity> tseliot: Right, well.  I should be asleep, so won't do a full review tonight, but I'll poke tomorrow.  And if you want to explain to me in backscroll why we need something that loads modules when we never did before, that would be great.
<tseliot> infinity: please reject nvidia-persistenced and I'll correct it. Here's the readme in case you're interested: https://github.com/NVIDIA/nvidia-persistenced#readme
<infinity> tseliot: That README tells me nothing about what it does, though it does tell me it intends to install its own copy of rpcgen, which I hope you don't do.
<tseliot> infinity: the daemon interface was generated by rpcgen. It doesn't say it will install its own version of rpcgen
<infinity> tseliot: Oh, nevermind, I misread.  They're just saying they pregenerated the rpcgen output.
<infinity> tseliot: Yeah. :P
<tseliot> yep
<tseliot> infinity: as for nvidia-modprobe, it loads  the NVIDIA driver and creates the device nodes, and setuid root,  allowing unprivileged users to create the device nodes. If one of the  NVIDIA driver's userspace components needs access to the kernel module  and device nodes, but they're not loaded/created yet, that driver  component can use nvidia-modprobe.
<infinity> tseliot: Isn't this what udev is for?
<tseliot> infinity: it's NVIDIA's distro agnostic way to do it. Shall I use udev instead?
<infinity> distro-agnostic doesn't mean correct. :)
<infinity> I can look at it again when I'm awake, but I suspect my answer will be "this is crackful when we have udev to handle this very thing, and so does every other distro from this century".
<tseliot> heh
<tseliot> infinity: nvidia-persistenced sets persistence mode to the GPU. Quoting NVIDIA: "When  persistence  mode  is enabled  the  NVIDIA driver remains loaded even when no active clients,  such as X11 or  nvidia-smi,  exist.  This  minimizes  the  driver  load latency associated with running dependent apps, such as CUDA programs"
<tseliot> infinity: funny thing, on some systems the GPU will lock up if persistence mode is disabled
<tseliot> (and it's disabled by default in the driver)
<infinity> tseliot: Curious.  I wonder if this was their answer to "we can't do KMS, due to taint, but we'll still stick around."
<infinity> tseliot: I'll review that one in the morning, but as weird as it sounds, I don't see any reason to not let it in.  I assume you'll be making the newer drivers depend on it?
<tseliot> infinity: yes, as soon as the package is in main/restricted.
<tseliot> in the meantime I'll correct the description
<infinity> tseliot: main, looks like.  It's GPL.  If you intend to throw it at main, you might want to ask #security for a quick review too.
<tseliot> infinity: sure
<tseliot> and right, it's gpl
<infinity> It's mostly MIT/Expat/X11ish, actually.  Just a few GPL bits they cargo-culted that made the whole thing GPL.
<infinity> I wonder if they changed their default free license.
<infinity> And if so, why they didn't relicense their old code.
 * infinity shrugs.
<infinity> I should probably not expect NVIDIA to make sense.
<infinity> Especially not at 4am.
<tseliot> hahaha
<tseliot> caffeine hasn't kicked in here yet either...
<rsalveti> seb128: ^
<seb128> rsalveti, ^ ;-)
<rsalveti> seb128: awesome, thanks!
<seb128> rsalveti, thanks for the work you put in it, nice to see that finally in the archive ;-)
<rsalveti> yeah, /me happy
<rsalveti> seb128: thanks for the review btw
<infinity> rsalveti: Aren't you supposed to be asleep?
<rsalveti> infinity: I believe so
<seb128> infinity, in fact that's not real, you are both asleep and dreaming that conversation
<seb128> rsalveti, yw for the review ;-) have a good night!
<infinity> Seems fair.
<rsalveti> seb128: last one for the day ^ :-)
<rsalveti> seb128: this should be easier, if you want to help with another review
<seb128> rsalveti, looking
<rsalveti> seb128: gone for real now, will check your review in a few hours :-)
<rsalveti> cya
<seb128> rsalveti, night
<cjwatson> oops, bad override on libpackagekit-qt2-5/powerpc I suspect, sorry
<cjwatson> will fix up later
<rsalveti> seb128: thanks for accepting ofono-qt
<seb128> rsalveti, yw
<Riddell> can I move kde 4.10.3 from raring-proposed to raring-updates?  it's tested just nobody done the copying yet
<infinity> Riddell: Fairly sure ScottK will get to it.
<Riddell> that doesn't answer my question :)
<infinity> Riddell: (generally, we prefer that only people in ~ubuntu-sru release SRUs, hence the redirection to Scott)
<Riddell> ok suspected so
 * ogra would appreciate isf an archive admin could let ubuntu-touch-session in soon ... thats the last blocker for getting a working UI up on the flipped container images
<bdmurray> cjwatson: you'd suggested ubuntu-sru or ubuntu-release for the phased updates overrides file.  I'm inclined to use ubuntu-sru since I'm a member.  Do you have a preference?
<seb128> ogra, NEWed
<seb128> ogra, happy to see that you used the current copyright format ;-)
<adam_g> Anyone know what the blue bug links signify @ http://people.canonical.com/~ubuntu-archive/pending-sru.html ?
<bdmurray> adam_g: that it is a link
<bdmurray> adam_g: that is the default color
<adam_g> bdmurray, heh. okay
<ogra> seb128, hahaha, that was already there ... i fixed my last package already though
<cjwatson> bdmurray: My preference would be ubuntu-sru :)
<bdmurray> cjwatson: okay, thanks
<jbicha> why is kylin missing from http://people.canonical.com/~ubuntu-archive/germinate-output/ ?
<slangasek> jbicha: I believe it's because kylin uses a metapackage as a delta on top of Ubuntu desktop, not a seed
<slangasek> (assuming nothing's changed since I last looked)
<jbicha> slangasek: but doesn't Edubuntu do something like that too?
<slangasek> jbicha: not exactly
<slangasek> edubuntu pulls in the Ubuntu and Kubuntu seeds (or metapackages?) but also has seeds in its own right; but kylin uses the ubuntu-defaults package infrastructure
<slangasek> because it's simpler and a better fit for their needs
<ScottK> Riddell (and infinity): KDE SC 4.10.3 released to -updates.
<Riddell> ScottK: lovely thanks
#ubuntu-release 2013-06-05
<jbicha> why are there still raring images on http://cdimage.ubuntu.com/ubuntu-gnome/daily-live/current/ ?
<infinity> jbicha: A curious oops in how publishing scripts work, probably.  Can fix.
<infinity> Ahh, could be because 'current' is a directory instead of a symlink.  Double oops.
<jbicha> check the other flavors too :)
<infinity> jbicha: That might be a bit tidier.
<RAOF> Gah!
<RAOF> âWe've tested this and haven't found any regressionsâ is *not* useful in the [Regression Potential] section of an SRU bug.
<StevenK> You're lagging, that was on G+ a whole two minutes ago. :-P
<seb128> stokachu, stgraber, RAOF: seems like that gnome-keyring precise SRU that just went in proposed has buggy breaks/replaces version
<seb128> SRU team: ^ maybe it should be removed from proposed?
<seb128> (cf comments on the SRU bug)
<infinity> seb128: Removed.
<seb128> infinity, thanks
<infinity> seb128: If you fix it (or get someone else to), feel free to nudge me to get it to the front of the review line, since it should be a few-character fix.
<seb128> infinity, k, thank you ;-)
 * xnox ponders how big is deb-src repository for raring of main/ and restricted/ => converted into PDFs
<StevenK> xnox: You want to work it out?
<cjwatson> *converted into PDFs*?
<xnox> cjwatson: double-checking, yes correct. "Would it be possible to also have an overall source code report with just the first and last 30 pages of the code for 13.04 as a whole?"
<Laney> ?!
<xnox> I think it's an unreasonable request, i'll just wait for steve to wake up.
<infinity> xnox: I don't even know what that means.
<infinity> "First and last 30 pages..."
<Laney> someone asked you for that?
<infinity> xnox: So, I guess you just need 30 pages from aalib and 30 pages from zsync (or whatever).
<xnox> well I generated a few reports for selected binaries & selected source packages, yesterday. that's a followup request.
<Laney> what is this person's goal?
<infinity> xnox: I don't think it's unreasonable so much as it highlights that the person doesn't know what they're asking for.
<brendand> xnox, that's hilarious :)
<brendand> xnox, they must think 'Ubuntu' is one big program
<infinity> brendand: It's not?
<cjwatson> xnox: Er.  Is this a request you actually need to pay attention to?
<brendand> infinity, depends on how you say it :P
<ScottK> Is there a chance the fix to provide a rejection rationale broke sending the reject email itself?  The uploader of oxygen-gtk3 that I just rejected said he didn't get mail.
<ScottK> Where "just" means about 20 minutes ago.
<infinity> ScottK: It's been working for me...
<infinity> StevenK: ^
<infinity> ScottK: Of course, the last time I blamed soyuz for my not getting mail (like, around 12 hours ago), it turned out that my MTA was busted. :P
<cjwatson> infinity: It might also matter that you're in ~launchpad, conceivably
<infinity> cjwatson: Potentially, though I'm the only AA that is, so easy enough to test with someone else rejecting an upload.
<infinity> (And if it wasn't sending mails at all, you'd think someone else would have noticed?)
<cjwatson> Rejections are rare-ish
<StevenK> infinity: You are not, we both are.
<StevenK> ScottK: No, my changes didn't drill that far down.
<infinity> StevenK: Oh, right, but I should remove you from that group, shouldn't I?
<StevenK> The string that was passed down the stack changed, the bottom that sent the mail did not change. Perhaps wgrant's changes broke it.
<infinity> StevenK: (archive, not launchpad)
<StevenK> infinity: I hope not.
<wgrant> StevenK, infinity: My changes only touched copies.
<StevenK> wgrant: Your ZCML mail changes, perhaps
<wgrant> Oh, that, possibly.
<wgrant> But let me see.
<wgrant> Nope, works fine
<StevenK> We don't have logs for rejection sending, since that happens in-request.
<wgrant> Right, the only resource would be MTA logs.
<ScottK> Thanks.
<ScottK> shadeslayer: ^^^
<shadeslayer> huh
<shadeslayer> well, I have 2 mails missing
<shadeslayer> one from a kde4libs upload to raring in ~kubuntu-ninjas
<shadeslayer> and the rejection email from ScottK
<ScottK> So you got the rejection mail?
<ScottK> That came from LP, not me.
<shadeslayer> nope, I'm missing both of them
<infinity> A missing reject and accept?
<ScottK> Ah.
<shadeslayer> a missing reject and a upload I did to a PPA
<infinity> Have you gotten any other mail since?
<shadeslayer> both of those are missing
<shadeslayer> infinity: any other mail from LP? nope, mail from mailing lists? YES
<shadeslayer> whoops @ Caps
<infinity> To the same address LP would be mailing you at?
<shadeslayer> yep
<shadeslayer> I use rohangarg@kubuntu.org and that's working fine
<shadeslayer> oh
<shadeslayer> funsies
<shadeslayer> infinity: http://paste.kde.org/759116/
<shadeslayer> so somehow I got deleted from the virtual alias table :D
<shadeslayer> probably explains mail loss
<infinity> Neat.
<infinity> shadeslayer: I'll ask around and see if anyone can sort out why.
<shadeslayer> thx :)
<infinity> shadeslayer: You still exist, but you might have a sliiiight mail loop.  They're looking into it.
<infinity>  /etc/postfix/kubuntu.org:rohangarg@kubuntu.org rohangarg@ubuntu.com
<infinity>  /etc/postfix/ubuntu.com:rohangarg@ubuntu.com rohangarg@kubuntu.org
<infinity> Why postfix returns "does not exist" instead of "exists excessively", I dunno.  I blame ScottK and lamont.
<shadeslayer> O_O
<infinity> shadeslayer: Did you recently change your primary email address on launchpad, by any chance?
<shadeslayer> nope
<shadeslayer> haven't touched that in years
<infinity> shadeslayer: (This is me shooting in the dark while IS goes hunting)
<infinity> shadeslayer: Kay.  I'll let them sort it out, then.
<shadeslayer> thanks alot fo rthe update
<ScottK> Fun.
<lamont> infinity: it's going to notice the loop during lookup, and reject the address
<infinity> lamont: Sure, I understand that it's probably pulling it from the lookup tables due to the loop, so it really "doesn't exist".  Just a shame it can't be more helpful on the topic.
<lamont> good point.  not sure the api between the two daemons involved lets it be that granular.  either way, sounds like an enhancement-requesting bug is in order
<stgraber> seb128: thanks for spotting. I'll let stokachu/dobey get me (or some other sponsor) a fixed debdiff... Sorry for that, I did test build it locally but took stokachu's word that this was all tested, clearly it wasn't or not properly...
<seb128> stgraber, no worry and yw ;-)
<adam_g_> Anyone in the SRU team able to take a look at releasing the verified Openstack packages  in raring and quantal? (nova, glance, cinder, horizon, quantum) They are all part of an MRE, and some will be getting stomped on by another security update next week (3rd time that has happened with this batch)
<infinity> adam_g_: If the whole lot is ready, sure...
<infinity> adam_g_: Bug #1150720 still seems a bit sketchy on the paramiko situation.
<ubot2`> Launchpad bug 1150720 in Cinder "[SRU] There is now a dependency on paramiko v1.8.0" [High,In progress] https://launchpad.net/bugs/1150720
<infinity> adam_g_: I'm a bit confused by the claim that something needs to be backported for paramiko, but that only appears to have happened in precise and raring, not quantal where the rest of this is being updated...
<adam_g> jeez. freenode.
<adam_g> infinity, well, we've backported the "known fix" to our paramiko 0.7.x package to work around the issue, and i'm not sure what i was reproducing was the same bug. in any case, its a paramiko bug and not a cinder bug
<infinity> adam_g: Erm, but you didn't backport the fix to quantal.
<adam_g> infinity, patching out the paramiko version req. in cinder 's pip-requires file would be needed regardless of the fix we SRU to paramiko
<infinity> adam_g: If updating cinder without fixing paramiko is going to cause this bug to surface, that seems suboptimal.  Pretty please, can we get paramiko SRUed too?
<adam_g> infinity, hmm yea. i can prepare the paramiko SRU but was having no luck reproducing and testing the issue.
<infinity> adam_g: And yet, there are claims that the issue exists.  Can anyone reproduce it (upstream, perhaps?)
<adam_g> zul, ^
<zul> adam_g:  i havent able either
<infinity> adam_g: Anyhow, please prep the Q SRU with the proper backported patch and I'll review that it's the same as precise's.
<infinity> adam_g: And if you can hunt down someone who can reproduce the bug, awesome.  If you can't, then a bit of regression testing will suffice.
<adam_g> infinity, i'll hit them up today. is there any chance we can track this as a separate paramiko issue that isn't blocking cinder?  the bug is paramiko bug gets triggered in a proprietary storage driver that we have no way of testing.
<infinity> adam_g: I'd rather release the lot together, but there's no reason this needs a 7-day wait or anything.  If someone can put it through some quick testing, that's cool.
<infinity> adam_g: The fact that the patch is already in raring and saucy is helpful here.
<adam_g> infinity, cool. ill get something in queue for -proposed after i go visit the iced coffee man
<infinity> adam_g: Stellar plan.  I might go find some breakfast.
<adam_g> infinity, ^ paramiko
<infinity> adam_g: Thanks, accepted.
<adam_g> infinity, commented on bug #1150720 and flipped the tag. hopefully that paves the way for the two openstack batches (quantal + raring) to go out before the weekend.
<ubot2`> Launchpad bug 1150720 in Cinder "[SRU] There is now a dependency on paramiko v1.8.0" [High,In progress] https://launchpad.net/bugs/1150720
#ubuntu-release 2013-06-06
<slangasek> infinity: verification done on rsyslog for bug #1187808
<ubot2`> Launchpad bug 1187808 in rsyslog (Ubuntu Raring) "PreserveFQDN fix introduces regression that might cause rsyslog not to start" [Critical,Fix committed] https://launchpad.net/bugs/1187808
<phillw> hi SRU people, the link from https://wiki.ubuntu.com/StableReleaseUpdates#Procedure section 4 points to a link at https://answers.launchpad.net/launchpad/+question/140509 which reports it as being wrong. Can someone look into this before the classroom session due on https://wiki.ubuntu.com/Testing/Activities/Classroom/Saucy#Reporting_Bugs Many thanks
<phillw> Hi JackYu how has the new release worked?
<ScottK> phillw: Did you notice it's a wiki?  I fixed it, but nothing you couldn't have done too.
<phillw> ScottK: 1) it is referring to MOTU 2) I could not state 100% that my alteration would be correct without asking for someone to check it. In that case, I would prefer an SRU member to correct it as you do need to request confirmation that work has been done correctly :D
<phillw> *as you do NOT need* :P
<ScottK> Just because I'm in the team, doesn't mean I don't make mistakes.
<ScottK> The correction that was needed was all about how LP works and nothing to do with SRU process.
<phillw> ScottK: that was this early morning session, for a new bug triager :) Hey, we even admitted to most destructive mistakes we have learned by :)
<ScottK> It's a wiki.  It's trivial to revert mistakes.
<phillw> knome: I disagree, but am not going into an argument over where the 'best' and 'most accurate' information should be. https://wiki.ubuntu.com/Testing/Activities/Classroom/Instructors
<infinity> ScottK: Were you releasing raring's rsyslog too?
<infinity> ScottK: (I was just about to do raring and precise, and then noticed you'd just done precise)
<phillw> knome: Sorry I mis - pinged you, it was meant for ScottK ^^
<ScottK> infinity: I looked for raring and didn't see it.
<ScottK> Go ahead.
<infinity> ScottK: Alrighty.
<infinity> Just didn't want double-copies messing up -changes. :)
<ScottK> OK.
<infinity> I also decided to let maas loose, so you can stop trying not to care about that one.
<ScottK> OK, although it wasn't taking a lot of effort on my part.
<cjwatson> Rebuilding today's desktop images - I think they failed due to component mismatches
<ogra> cdimage@nusakan:~$ for-project ubuntu-touch cron.daily-preinstalled --live && /home/ogra/utouch-android/do-zip-android
<ogra> lockfile: Forcing lock on "/srv/cdimage.ubuntu.com/etc/.lock-build-image-set-ubuntu-touch-saucy-daily-preinstalled"
<ogra> do i have to be worried ?
<cjwatson> ogra: maybe?
<cjwatson> I don't see any other builds running though
<ogra> there shouldnt
<cjwatson> That'd be the main worry, so I guess you can ignore it unless it happens again and then we'll investigate
<ogra> k
<ogra> hmm, i wonder if that build is stuck ... still havent gotten my prompt back
<shadeslayer> infinity: my email is still broken :(
<shadeslayer> infinity: should I just open a ticket on rt.ubuntu.com ?
<bdmurray> cjwatson: at the client sprint you'd suggested testing Phased-Update-Percentage (for the dice rolling changes) with quantal.  Is there a particular reason you suggested Q?
<cjwatson> I did?
<cjwatson> Um, I don't remember :)
<bdmurray> we were talking with slangasek about how update-manager rolls the dice on a binary package basis and how this might create a problem with dependencies and how update-manager should be changed to roll the dice for source packages
<cjwatson> Right, I remember the discussion, but I can't think why I would have suggested quantal
<cjwatson> Unless it was something to do with a release that I thought might be less in use so safer to fiddle with, or something
<bdmurray> ah okay, so testing with raring seems fine then?
<cjwatson> Yeah, I think so
<bdmurray> its easier to backport the calculation change to R than Q
<cjwatson> Thanks for working on that
<bdmurray> No problem
<infinity> shadeslayer: I've poked again, but if that poke goes nowhere, a ticket might be good.
<infinity> shadeslayer: In fact, yes, please file a ticket so it doesn't get lost.
<infinity> shadeslayer: Give me the RT number, and I'll make sure it's someone's priority.
<infinity> bdmurray: I never take "we should test $feature_foo on $release" at face value, especially right after a release. :P
<infinity> bdmurray: Heck, I'm still writing raring^wsaucy in changelogs.
<bdmurray> infinity: could you run this for me?  it's me upload
<bdmurray> s/me/my/
<bdmurray> remove-package -m "The verification failed in Precise and actually it doesn't need fixing." -d ubuntu -s precise-proposed -e 0.16.2  apport-symptoms
<ScottK> bdmurray: If infinity doesn't answer up in a minute or two, I'll run it.
<infinity> I'm on it.
 * infinity double-checks that it's bdmurray's upload and he's not socially engineering him.
<bdmurray> heh
<infinity> bdmurray: What about the one in raring that is the same patch?
<bdmurray> infinity: I just released that one I thought
<infinity> 'Published 51 seconds ago'
<infinity> Indeed.  I was too quick. :)
<bdmurray> the issue is that ubuntu-release-upgrader-core doesn't exist in P so the symptom does nothing
<infinity> bdmurray: Oh, indeed, it's update-manager-core in precise.
<infinity> bdmurray: Removed.
<bdmurray> infinity: you removed gnome-keyring from precise-propsed, it looks like the same problem will exist with the package upload in the unapproved queue for quantal
<bdmurray> see bug 1094319 for details
<ubot2`> Launchpad bug 1094319 in gnome-keyring (Ubuntu Quantal) "p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory" [Undecided,In progress] https://launchpad.net/bugs/1094319
<infinity> bdmurray: If it has the same incorrect Replaces/Breaks, it will, yep.
<infinity> bdmurray: And it does.  Rejecting.
<bdmurray> infinity: thanks!
<infinity> bdmurray: NP.  Thanks for spotting it before someone else accepted. :)
#ubuntu-release 2013-06-07
<Riddell> how come this doesn't work? http://paste.kde.org/760544/
<Riddell> grantlee slipped to universe
<wgrant> Riddell: Without options it will override the named binary. Use -S to override a source and its binaries.
<Riddell> thanks wgrant
<bdmurray> Could somebody have a look at https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/phased-update-percentage/+merge/167871 and then use it to set the phased-update-percentage for checkbox in raring-updates to 0?
<bdmurray> cjwatson: ^
<cjwatson> bdmurray: Merged - just checkbox or the other binaries too?
<bdmurray> cjwatson: the other binaries too please
<cjwatson> also fixed your code to handle -z 0 :)
<plars> something happened between yesterday and today on the server images. I'm not sure what yet, but today's images are no good
<bdmurray> cjwatson: hrm, thanks
<plars> still debugging, but I cannot seem to get todays image to install
<plars> cjwatson: I think publishing to current is still the default correct? I think it would be good to push yesterdays image back as current if that's the case
<cjwatson> plars: sec, you're in the queue
<infinity> plars: Is it the usual kernel version mismatch confusion?  They may have built just as d-i migrated.
<plars> infinity: could be, kernel is the same as yesterday's image
<cjwatson> bdmurray: ok, fixed up further so that 'change-override -s raring-updates -S -z 0 checkbox' works for this
<plars> infinity: is there an easy place to check the version?
<cjwatson> bdmurray: and overridden
<infinity> plars: I was hoping for some sort of error message from syslog.
<cjwatson> bdmurray: https://launchpad.net/ubuntu/raring/i386/checkbox
<plars> infinity: waiting on jenkins to come back up, so I'm looking at it manually right now
<infinity> plars: Anyhow, if it's booting with 3.9.0-4, it'll be mismatched, cause the ISO has 3.9.0-3 on it.
<cjwatson> plars: punted current back to 20130606 for now
<plars> infinity: first thing is that network seems to not be detected
<bdmurray> cjwatson: how do you get to that url from https://launchpad.net/ubuntu/+source/checkbox?
<cjwatson> plars: that's a classic result of kernel mismatch
<plars> though I think it got past that point on the preseed install
<cjwatson> bdmurray: god, I can never remember, I memorised the URL pattern :)
<bdmurray> cjwatson: okay, I'll work on that then
<cjwatson> the binary package publishing history pages aren't well-linked
<cjwatson> I think you can get at them using a search from /ubuntu/raring
<plars> then right after partman it fails
<plars> mount: mounting /dev/loop0 on /mnt failed: No such device
<plars> we are also fighting jenkins issues today, so I'm doing this by hand at the moment
<cjwatson> so - https://launchpad.net/ubuntu/raring -> "Architectures and builds for Raring" i386 -> search for checkbox and if it ever doesn't time out you should get your answer
<cjwatson> plars: no point continuing past the first failure anyway
<cjwatson> We have a current d-i now so I'll just rebuild
<plars> infinity: kernel version is 3.9.0-4
<infinity> plars: Right.  mismatch it is.
<plars> infinity: sorry
<plars> infinity: it's -3, I typod
<cjwatson> Rebuilding now
<infinity> ...
<plars> infinity: I was asking if there was an easy way to check the d-i version to see if it had gone up before the kernel for some raeson
<infinity> I'm all for not caring until it's rebuilt. :)
<plars> ok
<cjwatson> the way to check is to run uname -a
<plars> cjwatson: for kernel, yes, and it's 3.9.0-3, was asking about d-i
<cjwatson> who cares
<cjwatson> what matters if the kernel embedded in d-i
<plars> ok, will wait for respin
<cjwatson> and uname -a tells you that
<cjwatson> *is the kernel
 * cjwatson grabs an image in parallel to check
<cjwatson> plars,infinity: The problem was that due to unfortunate timing of seed changes vs. the image build only a few module udebs were present.
<cjwatson> A rebuild should clear it up.
<cjwatson> (Basically, those module udebs that were pulled in by dependencies of various random things.)
<bdmurray> cjwatson: what will change on the archive now that the p-u-p is set to 0 for checkbox?
<cjwatson> A Phased-Update-Percentage: 0 control field in the Packages files for those packages
<bdmurray> cjwatson: so the Packages file here http://archive.ubuntu.com/ubuntu/dists/raring-updates/main/binary-amd64/ and look for checkbox?
<cjwatson> Yep
<bdmurray> okay, I'm not seeing it... should I be more patient?
<cjwatson> Your mirror's probably out of date
<cjwatson> It's there on the master
<bdmurray> okay, great
<cjwatson> (To be fair, I think the master only pulsed about eight minutes ago)
<bdmurray> cjwatson: okay, I've tested update-manager if you want to set to 100 now
<cjwatson> bdmurray: OK, done.  You have until the next publisher run to keep testing :)
<bdmurray> cjwatson: thanks for the help
<plars> cjwatson, infinity: respin still fails it seems, looking
<plars> Jun  7 16:49:28 main-menu[1606]: (process:13288): FATAL: Module squashfs not found.
<plars> Jun  7 16:49:28 main-menu[1606]: (process:13288): libkmod: kmod_lookup_alias_from_builtin_file:
<plars> Jun  7 16:49:28 main-menu[1606]: (process:13288): could not open builtin file '/lib/modules/3.9.0-3-generic/modules.builtin.bin'
<plars> Jun  7 16:49:28 main-menu[1606]: (process:13288): mount: mounting /dev/loop0 on /mnt failed: No such device
<plars> Jun  7 16:49:28 main-menu[1606]: WARNING **: Configuring 'live-installer' failed with error code 1
<plars> still d-i/kernel mismatch it seems?
<infinity> Why would it have 3.9.0-3?
<infinity> Methinks something is very confused.
<infinity> plars: Hrm, it seems the mirror on cdimage is failing to update.  I'll poke in a sec.
<plars> thanks infinity
<plars> infinity: ping me if you start another respin and I'll make sure it gets priority for testing
<ScottK> libc++, there's a name that won't cause any confusion ...
<infinity> ScottK: It's llvm's stdc++ ... And yeah, not confusing AT ALL.
<infinity> plars: 20130607.2 should be more pleasant.
<plars> thanks infinity
<infinity> cjwatson: So, looks like the kernel skew issues were because the mirror wasn't being updated pre-build.  I ran anonftpsync by hand, and the images were sane afterward, but up until then, the mirror hadn't been updated for over a day.
<infinity> cjwatson: Not sure why that would be, and too tired right now to try to make sense of it.
<plars> infinity: ok, now something new is broken at least :)
<plars> 'can't get a pty: No such file or directory'
<plars> xnox: is that related to the stuff you were worried about earlier? ^
<xnox> plars: can you point me to the logs?
<plars> xnox: nothing external unfortunately due to the jenkins madness right now
<xnox> plars: well i can get to internal jenkins instance. or is it not even there?
<plars> http://10.98.0.1:8080/view/Saucy/view/Smoke%20Testing/job/saucy-server-amd64-smoke-default/45/ is the best I can give you, it will publish to the visible jenkins instance eventually I hope
<xnox> plars: well I grepped everything there, and can't filed "can't get a pty"
<plars> xnox: no, I had to hand boot it to see this message
<xnox> oh.
<plars> it wasn't clear to me from the logs there why it failed, so I tried it myself
<plars> and the message I pasted above seems to be happening continuously, just after selecting install from the boot menu
<plars> xnox: upstart	1.8-0ubuntu4 did show up in this release it looks like, was that the one you were talking about earlier?
<plars> also several things got dropped it seems, like busybox, cryptsetup, ecryptfs...
<slangasek> cryptsetup+ecryptfs> expected
<slangasek> busybox> doesn't sound problematic, probably related to cryptsetup+ecryptfs
<plars> slangasek: any thoughts as to the upstart bump? was this expected to be something that could cause problems?
<plars> slangasek: xnox mentioned wanting to watch the results when it showed up
<slangasek> plars: we never expect the upstart versions we upload to cause problems ;-)
<plars> slangasek: yes yes, of course :)
<slangasek> sounds like xnox was just being responsibly cautious and wanting to follow up in case there /were/ any problems
<slangasek> I don't know why the new version would have caused pty errors
<slangasek> given that upstart and the kernel both changed at the same time (right?), I think the kernel is the more likely culprit... the changes to upstart should only affect the behavior of 'telinit u'
<plars> slangasek: any suggestions for debugging this? I don't get very far in the boot unfortunately
<slangasek> plars: splice together something using the previous kernel to see if the problem is reproducible, so we can figure out first of all if we should be going after upstart or kernel
<slangasek> in fact, you probably want to try separately downgrading (or upgrading) both the kernel and upstart, to make sure which one is the culprit... if either
<cjwatson> infinity: mm, I thought I'd noticed something like that a while back when there was a stale lock ...
<cjwatson> Yep, /srv/cdimage.ubuntu.com/etc/.sem-build-image-set existed, but dated very recently so hard to say
<cjwatson> I've cleared it, hopefully that will fix life a bit
<cjwatson> plars: can't possibly be anything to do with upstart, which doesn't run during server installation
<cjwatson> I'm syncing an image to investigate
<plars> cjwatson: the booting kernel on both images seem to be the same too though
<cjwatson> With what you have so far I would guess udev, but we'll see
<cjwatson> (Since the relevant startup script supplied by udev-udeb was screwed up not that long ago, and might have been again)
<plars> there are some differences pertaining to rtc in the udev rules when I look in the initrd
<cjwatson> I'll probably use BOOT_DEBUG=3 and step through by hand
<cjwatson> (tends to require 'modprobe vesafb' blind ...)
 * cjwatson SIGSTOPs his nightly mirror run for a bit to try to recover some bandwidth
<plars> start-udev seems to run, but the next one after that is when I start getting the error
<plars> if I use your boot_debug=3 trick
<cjwatson> capitalisation relevant :)
<plars> yes, sorry
<cjwatson> but I assume you got it right or you wouldn't have seen start-udev
<cjwatson> "next one after that"?
<plars> I saw it run some steps that seemed to be after it was doing start-udev
<plars> I was given a prompt
<plars> when I exited the shell at that point, was when I started getting the error
<plars> rebooting now
<cjwatson> right, I'm going to end up stepping through the individual scripts by hand
<cjwatson> here it is, let's see
<cjwatson> wonder if the lack of /dev/pts is relevant
<cjwatson> comparing with raring
<cjwatson> mm, raring at this point has a devpts mount
<cjwatson> I blame systemd
<cjwatson> Again
<plars> ah, yes
<plars> comparing with the image from june 6 (which installed ok) /dev is very populated at this point
<cjwatson> /dev is populated, just not quite enough
<cjwatson> Yep, the old script ended with
<cjwatson> mkdir -p /dev/pts
<cjwatson> mount -t devpts devpts /dev/pts
<cjwatson> Completely missing from the new one
<cjwatson> Might POSSIBLY matter
<cjwatson>   * debian/extra/udev.startup: Drop devpts mounting again, already done by
<cjwatson>     /usr/share/initramfs-tools/init.
<cjwatson> That doesn't even run
<cjwatson> LIES
<plars> heh
<cjwatson> So this was entirely unnecessary and wrong code cleanup ...
<plars> thanks a lot for helping track it down cjwatson
<cjwatson> plars: Is there already a bug for this that I can close?  (If not, I don't need one)
<plars> cjwatson: I was going to open one real quick if that's ok, for purposes of having something to designate why it is red on the results (we get asked sometimes)
<plars> one sec... systemd I guess since udev is there now?
<cjwatson> Well, OK, if *you* need one
<cjwatson> systemd, yes
<cjwatson> It'll need a debian-installer rebuild after systemd is built, but I don't usually open bugs for those (it's a hassle and not very useful)
<cjwatson> You can just make the bug pro-forma describing the bare symptoms if you like, I don't need anything detailed
<cjwatson> (And am waiting for the bug number so I can upload this ...)
<plars> cjohnston: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1188864
<ubot2`> Ubuntu bug 1188864 in systemd (Ubuntu) "/dev/pts not getting mounted before install" [Undecided,New]
<plars> grr
<plars> cjwatson: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1188864
<cjwatson> thanks
<plars> cjohnston: you know you like it when I do that :)
<cjwatson> Uploaded
<cjwatson> https://launchpad.net/ubuntu/+source/systemd/204-0ubuntu3
<cjwatson> slangasek: ^- Do you think that once the above has built and published to saucy-proposed on all architectures, you could do a no-change upload of d-i (lp:~ubuntu-core-dev/debian-installer/ubuntu as usual)?
<cjwatson> It may or may not be worth respinning server images after that, versus just waiting for the cronned build in ~7 hours
<cjwatson> But either way, I could do with some sleep rather than waiting up to insert a d-i upload in between those times :)
<slangasek> cjwatson: that's after systemd publishes?  sure I can take care of that
<cjwatson> Yep.  Thanks a lot
#ubuntu-release 2013-06-08
<cjwatson> Waiting for https://launchpad.net/ubuntu/+source/systemd/204-0ubuntu3/+build/4652462 plus next publisher run after it uploads
<slangasek> yep
 * cjwatson &
<xnox> plars: slangasek: busybox drop is expected, one should gain busybox-static instead.
 * xnox ponders if the above systemd bug was also affecting ogra.
 * ogra looks through backlog
<xnox> ogra: nah, it wouldn't, unless you run d-i in phone images.
<xnox>  (debian/extra/udev.startup is used nowhere else than d-i)
<ogra> heh, nope
<ogra> ha, that one, yeah, i read the changes mail
<ogra> indeed, didnt affect us
<xnox> ogra: /me ponders if I should finally cron my rss feeds + changes into daily kindle news and read them with the morning coffee =)
<ogra> haha, thats what i usually do
<ogra> not actually using a kindle ... an email reader on the tablet/phone does as well
<xnox> I need to do something soon. As google reader will be dead in less than a month..... both online and tablet/phone =(
<ogra> i use gReader, the devs promised to transparently swithc backends ...
<ogra> (third party thing that exactly looks like the google one)
<xnox> interesting.
<xnox> I've tried feedly (didn't import folders), newsblur (still in the queue to register), theoldreader  (no tablet/mobile app)
 * ogra ponders if powerd dieing on the touch image is caused by the upstart job ...
<ogra> looks like the exec lives inside the script stanza
<xnox> which is fine.
<ogra> is it
<xnox> you do need to indicate within the script which command is the one you wish to actually track.
<ogra> the upstart cookbook discourages it
<xnox> huh, true. http://upstart.ubuntu.com/cookbook/#using-expect-with-script-sections
#ubuntu-release 2013-06-09
<shadeslayer> infinity: https://rt.ubuntu.com/Ticket/Display.html?id=22118
<infinity> shadeslayer: Erk.  Still broken?  I'll see if I can escalate it a bit harder on Monday. :/
<shadeslayer> infinity: yeah, I was kicked out of kde-release :/
<shadeslayer> because of broken email
<shadeslayer> would be nice before I get kicked out of other teams because of this
<infinity> Well, that's a solvable problem at least.  Mailing lists just aren't keen on bounces.
<infinity> Err, you were kicked from a team, not just a list?
<shadeslayer> team list :)
<shadeslayer> sigh, I mean mailing list
<infinity> Right.  I'll see what I can do to get someone to spend a bit more time staring at the problem.
<shadeslayer> thanks alot
#ubuntu-release 2014-06-02
<shadeslayer> ScottK: can you acceot cvsservice in binary new
<shadeslayer> *accept
<elfy> anyone got an idea why utopic dailies stopped building a few days ago? (with the exception of ubuntu core and touch)
<cjwatson> elfy: I literally just fixed that
<cjwatson> broken by syslinux 6
<elfy> thanks cjwatson
<cjwatson> which image do you particularly care about and I'll rebuild it?
<elfy> I knew I should have drunk the tea before posting :)
<elfy> xubuntu would be awesome :)
<cjwatson> I can't vouch for whether the images actually *work* with syslinux 6, but I guess we'll find out
<cjwatson> elfy: queued
<elfy> yep :)
<elfy> ok - thanks cjwatson
<shadeslayer> cjwatson: I hear code imports from packages are broken
<shadeslayer> https://code.launchpad.net/~ubuntu-branches/ubuntu/utopic/firefox/utopic
<cjwatson> shadeslayer: lots of individual imports are frequently broken
<shadeslayer> ah I see
<cjwatson> shadeslayer: http://package-import.ubuntu.com/status/ has status and reasons
<shadeslayer> thx
<elfy> cjwatson: in a few words - not very well, can boot the image - but trying to install with the desktop launcher does nothing
<seb128> elfy, it boots for you? the ubuntu iso doesn't give me a language selection menu in virtualbox
<seb128> (same in kvm btw)
<elfy> seb128: yea - no screen for language, no choose between try or install - but it does boot for me
<seb128> hum, k
<elfy> bug 1325632
<elfy> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1325632
<seb128> elfy, thanks
<elfy> that's in a vbox by the way
<seb128> kvm does the same
<luket_> Hello. Is this the correct place to ask about the possibility of backporting the Python 2.7.7 SSL support to 2.7.3 in Precise?
<infinity> luket_: The correct place would be filing a bug on python2.7, but given that precise users and upgrade to trusty, I'm not sure asking for feature backports to precise makes much sense.
<infinity> s/and upgrade/can upgrade/
<luket_> Thank you. We're stuck on 12.04 and OpenStack Essex. We need the SSL support added to 2.7.7 to properly secure Glance.
<xnox> infinity: hm, 2.7.7 is only in utopic-proposed.
<infinity> xnox: Yes, I know.
<infinity> And, in theory, if the backport is similar for both versions, auditable, and meets SRU criteria (some of these things seem less likely than others), we could perhaps do both.
<infinity> luket_: Please file a bug on python2.7, however.
<infinity> luket_: Use https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template for the description (ie: we need to know exactly why this is needed, impact, etc)
<luket_> Thank you. I'll do that.
<ScottK> Would need to update trusty too.
<infinity> ScottK: Obviously, yes.
<infinity> luket_: Especially, if you can expand on what "to properly secure Glance" really means, I could see making an exception for the SRU on that basis, if the argument is sound.
<ScottK> Obviously to you. A surprising number of people need that sort of the pointed out.
<infinity> ScottK: Well, hopefully obvious to any SRU team member who would be reviewing the proposal. :/
<infinity> Hopefully...
<ScottK> Of course, it was for luket_'s benefit.
<luket_> Python 3.4 properly verifies an SSL certificate. Python 2.7 didn't until the Python dev team backported the support to 2.7.7.
<luket_> I'll use the template and go from there. Thanks for pointing me in the right direction.
<infinity> luket_: Ahh, yes.  I think some other software (like ubuntu-one) actually does their own cert chain verification specifically because python doesn't seem to do it itself.
<infinity> luket_: So, that's another option -- make glance, in the face of python << 2.7.7, sort it itself.
<infinity> Probably the smarter option for glance upstream, since they can't exactly demand all their users use bleeding edge python.
<luket_> Yes. I'll check with the Glance team to see if there's any other way to do this before filing the bug report.
<infinity> cjwatson: And, of course, it doesn't fail under GDB.  Whee.
 * ogra_ wonders what happened to his touch image build ... 
<ogra_> i see a process on nusakan
<ogra_> but no related build running on kishi00.buildd
<ogra_> infinity, do you have an idea whats going on there ?
<ogra_> looks like hung ssh stuff ...
<ogra_> ogra@nusakan:~$ ps ax|grep kishi
<ogra_> 10891 ?        S      0:00 ssh -n -o StrictHostKeyChecking=no -o BatchMode=yes buildd@kishi00.buildd /home/buildd/bin/BuildLiveCD -l -f plain -A armhf -d utopic ubuntu-touch
<ogra_> 22116 ?        S      0:00 ssh -n -o StrictHostKeyChecking=no -o BatchMode=yes buildd@kishi00.buildd /home/buildd/bin/BuildLiveCD -l -f plain -A armhf -d precise ubuntu-core
<slangasek> how are you checking for the build on kishi?
<ogra_> slangasek, w3m kishi00.buildd/~buildd/LiveCD/utopic/ubuntu-touch/
<ogra_> from nusakan
<ogra_> there should be a 0602.1 build
<slangasek> ok
<ogra_> but even the top level BuiltLiveCD.log is empty
<ogra_> err
<ogra_> BuildLive.out
<ogra_> alst write to that seems to have been at 4:30 UTC
<ogra_> *last
<infinity> ogra_: How old is that build?  kishi00 was down last night.
<infinity> Ahh, old.
<infinity> Might need a stale lock removed or something.
<ogra_> infinity, i triggered the new buuld 2.5h ago
<infinity> ogra_: Sure, but the old one could be locking it.  Lemme poke a WeBop.
<ogra_> yeah, thanks
<infinity> ogra_: You should be able to try again now.
<ogra_> whee
<ogra_> lets see if my imgbot can cope with that :P
<ogra_> bah, cjwatson's attempt to fix samba seems to have failed bcause it cant build a manpage ... only on i386 and armhf
<ogra_> thats weird
<ogra_> all other arches passed
<infinity> ogra_: Yeah, known.  Looking into it, but it's making my head hurt.  Might try eating breakfast first.
<ogra_> stgraber, hmm, so i triggered a new touch build with the iso tracker a while ago ... seems it hasnt been picked up
<ogra_> infinity, well, i think zul just said in another channel he would be doing the merge ... probably coordinate with him
<zul> ogra_:  yeah im going to re-try the build first
<stgraber> ogra_: there was a stall process on nusakan, killed it now, let's see if that helps...
<stgraber> ogra_: cleared the DB state and requested a rebuild of touch, let's see if it gets picked up now
<ogra_> stgraber, great, thanks
<stgraber> cdimage   3394  0.0  0.0   4404   612 ?        Ss   19:15   0:00  |   \_ /bin/sh -c rebuild-requests -b -q utopic iso
<stgraber> cdimage   3398  0.1  0.0  54392 11696 ?        S    19:15   0:00  |       \_ /usr/bin/python /srv/cdimage.ubuntu.com/bin/rebuild-requests -b -q utopic iso
<stgraber> cdimage   3419 96.4  0.1  62076 15172 ?        R    19:15   1:08  |           \_ /usr/bin/python /srv/cdimage.ubuntu.com/bin/cron.daily-preinstalled --live
<stgraber> cdimage   3440  0.0  0.0  47252  3712 ?        S    19:15   0:00  |               \_ ssh -n -o StrictHostKeyChecking=no -o BatchMode=yes buildd@kishi00.buildd /home/buildd/bin/BuildLiveCD -l -f plain -A armhf -d utopic ubuntu-touch
<stgraber> so looks like the rebuild request got picked up now and things are building
<ogra_> yeah
<ogra_> i see it on kishi00
<ogra_> thanks a lot
<stgraber> np
<infinity> zul: Retrying the build won't help.  I don't imagine merging will either, unless that xml file changed.
<ogra_> infinity, funny that it is only on these two arches
<ogra_> the rest built fine
<zul> infinity:  googling looks like it might be fixed in 4.1.7
<cjwatson> zul: that seems surprising given that the crash is in xsltproc not samba?
<cjwatson> unless there's some bad XML that tickles a bug in xsltproc or something
<zul> cjwatson:  my mistake
<zul> i spoke too soon
<cjwatson> not saying it's impossible, just surprising :)
<zul> well 4.1.7 built fine for me (amd64) but i dont have arm or i386
<cjwatson> if you have amd64 then you have i386
<cjwatson> just use a chroot
<cjwatson> I reproduced the same failure locally
<cjwatson> I uploaded because it was still better than before, I was running out of day, and there was some chance that it might have been some bizarre local failure
<zul> ive reached a hard EOD for me...4.1.7 builds fine for me on amd64 (untested on i386 and arm) i need to go take my kid to swimming lessons
<rcj> stgraber, Would you have time to look at the SRU in bug #1275656? This is open-vm-tools trusty backport to precise for HWE kernels.  It's becoming critical now.
<stgraber> rcj: oh right, sorry, had a bit of a busy week last week. I'll take a look this afternoon, hopefully it's all good and I'll let it into -proposed.
<rcj> stgraber, thanks.
<rcj> stgraber, the precise upload went into universe but this package from trusty had a MIR and is in main for trusty.
<rcj> will it land in main for precise?
<stgraber> rcj: yeah, don't worry about it, if it's good, I'll override it to main
<rcj> stgraber, thanks for taking the time to review this
<cjwatson> infinity: I can reproduce it within waf but not if I pick out the exact same command from strace output and run it manually
<cjwatson> including what look like the relevant environment variables
<cjwatson> no-change rebuilding libxslt doesn't help
<cjwatson> faketime isn't relevant
<cjwatson> I can confirm it works under gdb for me
<infinity> cjwatson: I can reproduce without waf just fine.  Just need to export the right environment.
<cjwatson> OK, I expect I missed something
<cjwatson> trying with valgrind, it's certainly taking a while
<infinity> cjwatson: gdb on the dumped core is pretty monumentally unhelpful.  Might be more interesting with a -O0 libxml2
<infinity> (Though -O0 may also make the behaviour go away...)
 * cjwatson listens to his laptop take off which in fairness doesn't take a lot of provocation
<cjwatson> valgrind also makes it go away
<cjwatson> FFS
<ogra_> hovertop :)
<infinity> Wait...
<cjwatson> -O0 doesn't make it go away
<infinity> cjwatson: In both the gdb and valgrind case (and your "I can't make it fail without waf" case), could the common thread be lack of environment?
<cjwatson> I inserted gdb by editing debian/bin/xsltproc
<cjwatson> So I don't think so
<infinity> Oh, nevermind.  I can reproduce with a clean env too.
<infinity> (utopic-i386)adconrad@cthulhu:~/review/samba-4.1.6+dfsg/bin$ xsltproc --nonet -o default/docs-xml/manpages/smb.conf.5 /home/adconrad/review/samba-4.1.6+dfsg/docs-xml/xslt/man.xsl default/docs-xml/manpages/smb.conf.5.xml
<infinity> Bus error (core dumped)
<infinity> So, no debian/bin foo, and no export before.
<infinity> Irksome.
<cjwatson> Haven't managed to get it to dump core despite prodding ulimit
<infinity> cjwatson: Want my core?  It's not particularly enlightening to me, but maybe you'd do better with it.
<infinity> Oh, except mine is against a local rebuild.  I should downgrade and get a matching one.
<cjwatson> Since it's still reproducible with -O0, I'd suggest doing that first
<infinity> cjwatson: -O0 of libxslt or libxml2?
<cjwatson> Then hopefully the traceback will make sense
<cjwatson> libxslt
<cjwatson> I didn't try libxml2
<infinity> cjwatson: I'm not convinced that it's not libxml2's fault.
<cjwatson> We have an Ubuntu delta to that ...
<cjwatson> I wonder what happens if you back out the recent security update?
<infinity> cjwatson: Here's the 'bt full' from the core: http://lucifer.0c3.net/~adconrad/bt-full.txt
 * cjwatson grabs the previous version
<infinity> cjwatson: Same bus error with -3ubuntu4
<cjwatson> Yeah, likewise
<infinity> Build log diff between previous successful samba build and this one to see what else has changed?
<cjwatson> out of time
<infinity> I'll keep digging in a bit.
<infinity> Most everything (except xml2) looks untouched...
<infinity> Well, and libgcc...
<infinity> I'll have to give this a spin in a trusty chroot and then do selective partial upgrades, I think.
<cjwatson> I had one last test already running: libxml2 -O0 still fails
<cjwatson> disas /rm in gdb says
<cjwatson> => 0xf75bb588 <+12>:    e8 23 71 f7 ff  call   0xf75326b0 <__x86.get_pc_thunk.bx>
<cjwatson> some kind of multiple declarations problem?
<cjwatson> or wrong linker or something
<cjwatson> anyway, really gone
<stgraber> rcj: ^
<rcj> stgraber, Thank you so much
<stgraber> rcj: please do another full test once both packages are built and published in -proposed then confirm that everything looks good in the bug report
<rcj> stgraber, I will.
<cjwatson> infinity: works after "ulimit -s unlimited"
<cjwatson> infinity: if that's any help?
<cjwatson> I might just upload with that to unblock us
<cjwatson> uploaded
<cjwatson> hopefully that'll stick this time
<cjwatson> makes sense given the length of infinity's bt-full though
<infinity> "sense".
<cjwatson> I can certainly well believe that XML/XSLT processing might hit stack size limits
<infinity> Indeed.
<infinity> Gross, though.
<cjwatson> Yeah
<infinity> So, possibly just a fluke of a few kB one way or the other than ppc didn't explode?
<infinity> s/than/that/
<cjwatson> Could be
<cjwatson> Or different stack layout
<infinity> Oh, fair.  PPC is a whole lot of different in that area.
<cjwatson> zul: all sorted now
<stgraber> rcj: hmm, so there's a problem with having open-vm-tools-lts-trusty in main for precise, it build-depends on libdumbnet-dev which isn't in main
 * stgraber should have spotted it in the review...
<stgraber> rcj: so there are two options, 1) keep it in universe, 2) check for any other build-dep that's in universe, convince the security team to support them all, then promote them to main
#ubuntu-release 2014-06-03
<infinity> stgraber: If they're already supporting those packages in trusty, it shouldn't be hard to convince them.
<cjwatson> .
<cjwatson> bah
<pete-woods> cjwatson: hi, I've finally managed to get HUD through ci-train again (apparently my packages were "in no known space and time" for a while)
<pete-woods> cjwatson: really hoping I've cleaned up the changelog suitably for you now :)
<cjwatson> pete-woods: hopefully somebody else can look today as I'm on leave
<pete-woods> cjwatson: no problem, sorry for the holiday nag!
<mlankhorst> any sru admins here? part of the xorg-lts-trusty stack is still unapproved
<Riddell> you want the ~ubuntu-sru team mlankhorst
<rcj> stgraber, libdumbnet was promoted to main with open-vm-tools in trusty.  Let me find the MIR for that for more history
<rcj> stgraber, MIR for libdumbnet was bug #1220950.  Only dependency is libc6
<stgraber> rcj: ok, sounds like it should be fine to promote then (same upstream version so shouldn't be much work to update in case of a security problem)
<rcj> stgraber, yeah.  Sorry I didn't mention it earlier.  We knew about the dependency and I was told that it would get pulled along since we had done the MIR before.  That wasn't correct so sorry for the extra work.
<stgraber> infinity: so just to confirm because I've never done this before, if I want to promote libdumbnet from universe to main in precise and it never had any SRU there, I need a no change rebuild, right?
<stgraber> or do we do weirder magic like copy the version from the release pocket to the update pocket just so we can override it to main?
<doko> stgraber, when is 14.04.1 scheduled?
<stgraber> doko: first or second week of August IIRC
<doko> stgraber, thanks!
<infinity> stgraber: No, you can copy it to -updates and promote it there.
<stgraber> ok, doing that then
<infinity> stgraber: Have you gotten a security person or two to sign off on the precise version being supportable?
<infinity> (Like, maybe the trusty MIR involved an audit, fixing some things, etc)
<seb128> hey SRU team, could you pocket copy to utopic when you move things to -updates? (I noticed some packages are outdated in utopic compared to trusty because they didn't get copied)
<stgraber> infinity: precise and trusty have the same upstream version, only changes that happened in between are switch to dh_python2, change of Debian maintainer and a no change rebuild by doko.
<stgraber> mdeslaur, jdstrand: any objection to me promoting libdumbnet to main in precise for use by open-vm-tools-lts-trusty? (as I said above, same upstream version as trusty, minor packaging changes between the two but nothing that looks security-related)
<mdeslaur> stgraber: no objection from me
<infinity> stgraber: A switch to dh_python2 from what?
<infinity> stgraber: If it was python-support in precise, that change needs to be made there too.
<infinity> seb128: We're a bit far into the cycle to be doing that for every SRU.
<seb128> infinity, what's the issue with pocket copies?
<seb128> that's not different from having those copied when the new serie open
<stgraber> infinity: just grabbed the diff, it was python-central back in precise, so yeah, we need that change in there before promoting
<infinity> seb128: The issue is three things.  (1) If we have new toolchain changes (we don't, currently), we want as much stuff organically rebuilt as possible, but yes, not necessary.
<infinity> seb128: (2) If there's a library transition or some such, the old one just plain won't work on the new series.
<infinity> seb128: (3) we're lacking tooling to actually track sanely when something is a newer version in an older series (yes, our fault, but it means we rely on people who expect an SRU to get copied to notify us of that, not just expect it)
<stgraber> rcj: can you prepare an SRU of libdumbnet for precise which makes it an equivalent of what we have in trusty? (we at least need the switch to dh_python2 but the --add-missing change seems useful too, so I'd just make the SRU be identical to trusty's current version)
<mdeslaur> utopic now has -fstack-protector-strong by default
<seb128> infinity, do we have tooling telling us what is outdated in utopic compared to trusty?
<infinity> seb128: No, we don't, which I mentioned above.
<seb128> k
<infinity> (I mean, it's doable, obviously, but we don't have any reports that tell us)
<seb128> well, I assumed the SRUs would be copied and I didn't keep track of those
<seb128> I guess things are going to sort themself over time
<seb128> I just noticed this morning because somebody had an issue due to trusty-updates having a newer gtk2 than utopic
<infinity> mdeslaur: Ahh, did that happen?  I missed that.  So, that's a fine argument for not copying wholesale every time.
<seb128> well, we do copy on the opening
<mdeslaur> infinity: oh, actually we didn't switch to gcc-4.9 yet
<seb128> if we wanted to rebuild eveyrthing we wouldn't
<infinity> seb128: Sure, we don't want to rebuild everything.  We just generally want uploads to go to the devel series first.
<infinity> seb128: Also so that fixes don't get lost.
<infinity> seb128: So, yeah, if people indicated that something was also meant to go to devel-proposed, sometimes that's perfectly reasonable.
 * infinity copies that gtk2...
<seb128> infinity, thanks, I'm going to have a look to my other SRUs to see which ones are in the same case
<infinity> seb128: Other than the (admitedly shaky) toolchain argument, it's mostly just a lack of tooling/tracking that makes it onerous right now.
<infinity> seb128: Also, you don't need an SRU or AA person to do this.  If you have a list, you can just "for i in $seb_list; do copy-package -s trusty-updates --to-suite=utopic-proposed -b $i; done"
<seb128> infinity, going to do that (I'm archive admin as well, so I've no excuse anyway ;-)
<infinity> seb128: Sure, I know you're an AA, just saying.  Uploaders should be able to do this themselves (except people who were sponsored and would need to poke their sponsor).
<seb128> infinity, but I might be wanting to join the SRU team/help with reviews, if you guys are interested (not sure if I should "apply" somewhere and how, so just mentioning it)
<infinity> seb128: There's no real application, per se, it's a combination of interest and invite, and a bit of 1-on-1 training and glaring from someone who picks apart your slack reviews until they measure up. ;)
<seb128> infinity, well, I stated my interest then I guess ... ;-) (I feel like it's only fair, for all the desktop SRUs I keep sending for review ... and it might help taking other stuff out of the queue and help getting my desktop stuff reviewed as well ;-)
<infinity> seb128: Indeed, that's sort of how we like to see it work.  Cross-team code review is a Good Thing too, IMO.  When you're reviewing code you've never seen and may not understand, you tend to be pickier and ask more "stupid" questions, that gets the uploader thinking about intent, code flow, etc.
<rcj> stgraber, I'll get to work on those changes
<rcj> stgraber, what is the right version for the SRU'd libdumbnet in precise if the current version is 1.12-3.1?  1.12-3.2 or 1.12-4?
<stgraber> rcj: 1.12-3.1ubuntu0.1
<rcj> stgraber, good thing I asked.  Thanks..
<rcj> stgraber, I have an SRU bug #1326025 for the libdumbnet updates and an MP #221919 for the change.
<niedbalski__> Can https://bugs.launchpad.net/ubuntu/+source/biosdevname/+bug/1324558 be reviewed for -proposed ?
<niedbalski__> thanks!
<infinity> zequence: Your desktop-minimal seed change crashes germinate.
<ogra_> we have a desktop-minimal seed ?
<infinity> ogra_: studio.
<ogra_> oh
<ogra_> k
<infinity> zequence: I reverted your last two studio seed commits, since they're crashing germinate in production.  You might want to test locally first before reapplying. :)
<ScottK> Bad commits or germinate bug?
<infinity> ScottK: Undecided.  But reverting them for now was the fastest way to a happy publisher.
<ScottK> Sure.
<infinity> Also, in a fit of "I'm an adult, I can do whatever stupid thing I want", I bought a bunch of butterscotch pudding last night, so nothing can get me down today.  Even exploding infrastructure.
<ScottK> Lol.
<mdeslaur> lol
<zequence> infinity: My lack of knowledge for seeds. But, I'm not too worried about ISO building problems. More about getting those changes through correctly
<zequence> infinity: Are you saying other projects are affected as well, besides Ubuntu Studio?
<infinity> zequence: Yeah, it crashed germinate in production, which wreaks havoc with the publisher.
<zequence> infinity: Could I see the error log somehow?
<infinity> zequence: http://paste.ubuntu.com/7581273/ <-- Obviously only the last two lines matter, the rest is launchpad exploding because of it. :P
<zequence> infinity: Thanks
<rcj> stgraber, the libdumbnet upload in bug #1326025 is complete for precise thanks to smoser.
<stgraber> rcj: thanks. I'll take a look in a few minutes. I'll let it into precise-proposed, promote it to main then build open-vm-tools-lts-trusty against it. We'll need both tested and released together.
<rcj> stgraber, absolutely.  Thanks.
<infinity> stgraber: Keep in mind that if there's even the slightest chance of a security update being done to open-vm-tools-lts-trusty in the future, libdumbnet will need to end up in both updates and security when it's released.
<stgraber> infinity: good point. I'll make sure to do that. We could wait until we actually get a security update but it's probably going to be less confusing to just do it now instead (and the package doesn't have any user visible change, so it's fine to push to -security anyway)
<infinity> stgraber: Assuming it's installible in security despite having been built in proposed against updates.
<infinity> stgraber: Worth a check on that before copying. :)
 * stgraber does some SRU queue review, seems like we're a bit behind with all that sprinting
<cjwatson> ScottK: I'd call them bad commits.  There was a seed that was undeclared in their STRUCTURE file.
<ScottK> Fair enough.  Thanks.
<cjwatson> zequence: ^- that, and also there was an "ububuntustudio" or some such typo in there
<zequence> cjwatson: Ah, thanks
<zequence> just started reading through some about the build process. Seems like most of the docs are in ubuntu-cdimage? Though, I could just do a germinate command to test our seeds specifically?
<cjwatson> ubuntu-cdimage won't help you with germinate
<cjwatson> Yeah, just run it by hand against your seeds and you'll see it
<cjwatson> It has a man page or --help
<zequence> Alright
<stgraber> infinity, cjwatson: do we have some kind of stable release exception for gcc-snapshot? We've got one in the queue with a 175.7MB large diff, I don't really feel like reviewing it ;) (bug 1315378)
<infinity> stgraber: No.
<infinity> stgraber: I'm still not sure I see the point of that bug.  We don't want things build-depending on gcc-snapshot, and if people want to "build and test gnat on arm64" they can do so in 14.10, where gnat works.
<infinity> stgraber: Oh, and since you seem to be queue happy today, I have context on the walinuxagent stuff (I've sent it back a few times already), so I'll deal with that.
<stgraber> infinity: yeah, I noticed it getting rejected a few times so I wasn't going to touch it.
<stgraber> auto-apt, audacity, tracker and ubuntu-touch-meta are all waiting for bug updates or feedback from uploaders.
<stgraber> walinuxagent is yours and I'll take a look at those syncs now (cjwatson said something about one of our tools knowing how to diff them, I'll try to figure out which now :))
<cjwatson> stgraber: I misspoke slightly; what I was remembering was that "queue fetch" knows how to fetch them via the copy, so you can at least pull-lp-source; queue fetch; debdiff
<cjwatson> stgraber: The logic in queue fetch would still be useful for any other tool that wants to do this kind of thing before the Soyuz redesign, though
<stgraber> ah, that's already much better than what I used to do (clicking through 3 pages on LP to grab the dsc)
<infinity> Can queue fetch do only-source now?  Cause having it fetch all the binaries made it pretty awful.
<cjwatson> Yes, I fixed that shortly after noticing the same thing
<infinity> --source I guess?
<cjwatson> Right
<infinity> I'll have to try to remember that.  I've been doing the click, click, click, dget dsc thing.
<cjwatson> Fixed a bit over a year ago by the looks of things
<infinity> Learning new tools takes me a while. :)
<cjwatson> It's almost enough that I don't have much impetus to care about an easier diff tool, except for large packages
<infinity> And sometimes lets me down.  Like, shotly after learning that dget works on .changes, my hopes and dreams for using it were dashed by launchpad's .changes being incomplete (due to translations and ddebs).
<cjwatson> But for large packages it would only really help if it were in LP
<infinity> I suppose dget could use an --ignore-missing option.
<stgraber> rcj: libdumbnet accepted. I'll let it build and publish, then override to main, then retry the open-vm-tools-lts-trusty build, hopefully all of that before I have to run away from here ;)
<infinity> stgraber: Should have overridden it to main before it built, to make sure it doesn't have any build-deps in universe (unless you carefully checked).
<infinity> Ahh, looks good anyway.
<stgraber> infinity: yeah, I should have, but indeed, the two non-obviously correct ones are both main, so that's all fine
<stgraber> done with SRUs for now, queues should be much more reasonable now (hopefully people will reply to my pings and I can process the rest of trusty tomorrow)
<gaughen> thanks stgraber!
<infinity> stgraber: Since you've been in a queue mood today, want to review my d-i upload in trusty (or just tell me to self-accept since it's obvious)?
#ubuntu-release 2014-06-04
<infinity> stgraber: Or maybe you've disappeared, I'll just self-accept. :P
<stgraber> infinity: just got back actually
<infinity> Oh, hey.
<robru> hey, if you guys are in a queue mood, don't accept ubuntu-app-launch just yet. want to get a new image built first ;-)
<stgraber> infinity: accepted
<infinity> stgraber: Ta.
<stgraber> robru: don't worry, it's srcNEW AND a sync, it's way too much trouble to review for me to look into it ;)
<robru> stgraber, haha, yeah, the last few srcNEWs I had took about a week each, so I wasn't worried at first. but now you guys are talking about the queues, thought maybe I was racing against the clock here ;-)
<pete-woods> hi release folks, I see my HUD SRU upload was rejected, just wondered if anyone knew why, and what I should change?
<RAOF> pete-woods: You (or your sponsor) should have got an email with the rejection message.
<pete-woods> RAOF: okay, thanks, will try asking him
<sil2100> RAOF, pete-woods: we have no rejection message e-mails, the package has been sponsored by the CITrain so essentially the e-mail landed somewhere in some inbox that's inaccessible to anyone
<RAOF> Urgh. Yay process.
<pete-woods> :D
<pete-woods> RAOF: does this mean you have been able to find out why?
<pete-woods> or that I have to track down the "rejector"?
<RAOF> You have to track down the rejector
<sil2100> We will probably have to track down who rejected
<infinity> sil2100: Or read the mailbox.
<infinity> sil2100: If literally no one is reading that email, that's a massive failure in the citrain process.
<sil2100> infinity: we would love to, but not sure who has access to it - I remember didrocks mentioning once that fginther has access to it
<sil2100> infinity: right, we know
<didrocks> hum? that completely untrue
<didrocks> as now the sponsor is the guy pressing the publish button, if it was rejected by an archive admin/SRU team member, he will receive the email
<didrocks> or launchpad is buggy otherwise
<didrocks> but we made the change for this.
<infinity> Both should get the email, probably, but I'd have to refresh myself on the rules of how all that works.
<didrocks> sil2100: please, we discussed about it and I did the change for thatâ¦ Try to remember the discussions we are having
<infinity> The bot definitely will get mail still, though, as it's the one doing the actual copy.
<sil2100> didrocks: I didn't get any e-mail and never got one, so I thought it was something that hasn't been implemented in LP
<didrocks> sil2100: we discussed it 2 weeks ago, on that same very channel, and you were in the discussion
<sil2100> didrocks: yes, but it never worked for me, so I thought it wasn't ready
<infinity> The copy may have pre-dated that change?
<infinity> Oh, not likely, if it was the 0528 build I see in rejected.
<sil2100> We made the copy yesterday
<didrocks> so, seems to be more on the launchpad side than "a massive failure in the citrain process" as some people jumped into saying that too early
<infinity> didrocks: I said that based on sil claiming no one reads the email. :P
<sil2100> didrocks: right, but why no one has access to the bot e-mail anyway? Is there some security concerns?
<infinity> (Using the ubuntu archive bot in general is problematic there, until we get the email going somewhere more useful than chiark, it's not citrain's fault, per se)
<sil2100> (or at least no one from the landing people)
<didrocks> sil2100: ask fginther, I'm not the one who created it
<sil2100> didrocks: I'll ask him, maybe this can be sorted out somehow in the meantime
<infinity> sil2100: There's a massive security concern in giving wide access to email for a bot that's a member of restricted groups, yes.
<infinity> sil2100: Since being able to read its email means being able to reset its password.
<infinity> And this isn't Francis's bot, the copy was made by ~ubuntu-archive-robot
<sil2100> infinity: then maybe at least making an e-mail forward in case of rejections to some landing team members
<didrocks> infinity: I guess he's talking about ~ps-jenkins
<didrocks> not the archive admin one
<infinity> didrocks: Right, we should definitely sort out who's getting mail and why. :P
<didrocks> infinity: right, after the sprint, we discussed about a way with Colin, like:
<infinity> And yes, some procmail rules on the archive robot to forward known-safe mail to a list would be helpful too.
<didrocks> - changelog entry be "lander <lander email>"
<didrocks> - sponsored field is the guy pushing the "publish" button
<didrocks> so, from what I get, the lander will then get assurely the email, right?
<infinity> Who is the "lander" in that context?
<infinity> Anyhow, it might be more complicated than that at the LP level.  We'll have to look.  LP tries hard to not spam people without knowing it's mailing the right person.
<infinity> (like, if you build a source package changed-by me, signed by you, I shouldn't get mail about it, as there's zero evidence I actually had anything to do with it other than you spoofing my email)
<didrocks> infinity: the lander is the guy telling "I've done the testing, sorted out the MPs and take responsability for that landing"
<didrocks> (most of the time, it's the tech lead of a team or the manager in the touch context)
<didrocks> infinity: the "sponsored" at least should receive it IMHO (the extra field I'm using now in the copy context). We made the change for that, maybe it's falling into the rule you are describing?
<pete-woods> so can anyone tell me who I should expect to have the email? mhr3 is the one who clicks the build button for me, but I don't know who in CI clicked the publish button
<infinity> Yeah, we'll have to look into it when I'm not passing by a computer at 2am between bed and the washroom.
<pete-woods> is there a log of who accepted / rejected stuff maybe?
<infinity> pete-woods: If it was rejected yesterday, it was almost certainly stgraber, he was on a roll.
<pete-woods> infinity: thanks, I guess I'll have to wait for Canada tz
<infinity> didrocks: I'm not sure what the right answer actually is for who should get mailed, versus how we protect against backscatter.  This wasn't something we had to think about before bots started doing copies, as the "signer" was always the right answer.
<infinity> didrocks: (And the "signer" is the only person you can guarantee actually was involved in the upload, and thus can't complain about being spammed)
<didrocks> infinity: that's a fair question and something to consider for sure, indeed.
<infinity> didrocks: But perhaps a compromise would be to allow people with archive permissions (as the ubuntu-archive robot has) to spoof signer with the sponsored-by field or something.
<didrocks> yeah, we can "trust" more those special signers
<infinity> We'd probably want a separate set-signer attribute, I guess, so all sponsored uploads by all AAs don't suddenly get incorrectly signed.
<infinity> (ie: if I sponsor an upload, it should be signed by me)
<infinity> wgrant: Can you have a ponder at backscroll and see what you make of it?
<didrocks> yeah, just tell me if I need to change anything, but I guess the correct behavior is the correct one (+ eventually the change discussed with colin)
<didrocks> sil2100: do you feel/want to implement (no rush) the "changelog entry ends with the first lander name and email instead of ps-jenkins"? It should be < 7 lines in cu2d?
<sil2100> didrocks: sure :)
<wgrant> infinity, didrocks: "with archive permissions"?
<wgrant> I can create another archive and give myself permissions on that just fine.
<infinity> wgrant: As in, AA permissions on the target archive.
<infinity> wgrant: But good point, one could create a PPA and use that to spam people.
<wgrant> We may just have to bite the bullet and stab people who abuse the field.
<wgrant> But people really like abusing Launchpad features, and we can never win.
<wgrant> We see a similar problem with Debian people.
<wgrant> if we don't attribute them when their packages are copied into Ubuntu, they're all like "grrr why you steal my work without attribution ubuntu is evil die die"
<infinity> wgrant: We've done so very well up until now at not mailing people we shouldn't be, would be a shame to break that.
<wgrant> If we do, the other half are like "grrrrrrr i hate ubuntu, ubuntu must die die die, i don't participate in ubuntu""
<wgrant> We sort of need some way for people to opt into attribution/spam from an archive/distro.
<wgrant> But that's hard.
<infinity> wgrant: But yeah, it would be hard to accidentally spoof the signer if it's a distinct field, so it could only suffer from intentional abuse, not accidents.
<wgrant> That's true.
<wgrant> Most of the abuse we've seen in the past has been Changed-By/Maintainer.
<wgrant> So possibly accidental.
<infinity> And there's no need for, say, copy-package or syncpackage to implement the feature, as if you're a human doing a sync/copy, you ARE the signer, full stop.
<infinity> So, it's really a case of "people abusing it would have had to write their own API client to do so", rather than "Joe Developer may have screwed up".
<wgrant> Yeah
<infinity> That could be enough assurance for me that any abuse would just be a clear TOS no-no, plus pretty unlikely to happen anyway.
<wgrant> Heh, you clearly don't have much experience with some of our special users.
<infinity> Well, there are much easier ways to spam/annoy people with much more interesting emails than to go to effort to create upload backscatter intentionally.
 * infinity shrugs.
<infinity> I'm not sure I see a better way out of this, other than giving a bot super-amazing permissions to be even scarier than normal AAs.
<infinity> Which seems like a poor design decision, not to mention a pain.
<wgrant> Indeed.
<wgrant> So, we have a few fields. We should define who should receive which emails in which circumstances.
<infinity> Well, I'm not positive how it works currently, but my gut says it's always the signer who gets everything.
<infinity> ie: the person who signed the .changes or initiated the sync (which is morally equivalent)
<infinity> So, spoofing the signer perhaps implies that you're overwriting whatever field that is.  uploader?
<infinity> Which then leads to the "hey, people pressing that button in CI really need to have upload rights to the package" argument before the DMB lynches us.
<infinity> And also means that the queue items would no longer unhelpfully say "synced by Ubuntu Archive Robot", but instead say "synced by Joe B Developer".
<infinity> And yes, that option would have to be restricted to people with AA rights on the target archive, cause otherwise any old person could spoof a package signed by anyone else, which seems just fundamentally wrong (again, ignoring that anyone could do this in a PPA, which makes it all fall apart a bit...)
<infinity> Hrm.
 * ogra_ would already be happy if it could automatically list packaging changes in the changelog, regardless who owns the change/upload in the end 
<ogra_> since most of these people are upstreams, not packagers such info usually gets forgotten or never shows up
<ogra_> and its a pain having to dig into the source just for that
<infinity> wgrant: Maybe I'm overthinking the PPA impact.  My concern was audit trails if someone succesfully spoofs another uploader, but since this can't happen on a source upload, only a copy, the original will always be correct, if you trace far enough back.
<cjwatson> infinity,didrocks: the work I did in LP was specifically to ensure that *errors* (that is, copies failed because internal explosion) went to the sponsor of the copy
<cjwatson> there's very likely additional work needed to ensure that *notifications* (e.g. rejections) go to the sponsor
<cjwatson> infinity: there's nothing about this in ~ubuntu-archive-robot's mailbox, FWIW
<infinity> cjwatson: Neat.
<cjwatson> if somebody wants to set up a target list and give me a set of procmail rules then I'll gladly install them
<infinity> cjwatson: We probably should move it to using ubuntu-archive@ubuntu.com, and get IS to set up a real account for that in the procmailers group, instead of having mail from a key infrastructure piece hosted on chiark. :)
<infinity> cjwatson: But not a ticket I feel like filing right now.  I'm going to try to sleep again.
<sil2100> cjwatson: ah, thanks for the info!
<zequence> infinity: I readded yesterdays commits, with a couple of fixes. Tested locally, and seemed to work.
<zequence> cjwatson: infinity: I'd very much like to have a new ISO built for us. The changes in our seeds probably gives a hint. There are a few things I'm a little confused about, like "ship". I've looked in other flavor seeds without getting less confused, just noticing that different seeds are done differently.
<zequence> The idea is we don't ship our multimedia metas on the smaller ISO (cd-live), so not ubuntustudio-audio, -video, -graphics, -publishing and -photography
<zequence> Later, I'll create a plugin for ubiquity that allows one to install those over a network connection. So, this CD would be a sort of netinstall image for us.
<zequence> ..but, with the possibility to do some simple testing - which is why we want a live CD
<zequence> Anyway, I'd appreciate any help we could get on getting this to work. I've done as much as I can understand right now.
<zequence> Hard to find good docs on this stuff, but may be I'm not looking in the right places
<jpds> So, can someone figure out why ima-evm-utils is still in NEW after about a month now?
<seb128> jpds, it's easy to figure out "nobody has free slot to review NEW"
<jpds> seb128: Looks quite empty otherwise: https://launchpad.net/ubuntu/utopic/+queue
<seb128> jpds, not so much got uploaded, and some review happen when there is pushing/things blocked
<seb128> so I guess nobody nagged about ima-evm-utils/it didn't get flagged as blocking work
<seb128> so didn't raise enough in the priority list to get worked on
<ogra_> hmm, i see no valid reason why ubuntu-touch-meta, ubuntu-session and the rest of the ubuntu-app-launch landing are still stuck in -proposed
<ogra_> seems all autopkgtests passed fine
<cjwatson> ogra_: see my comment in #ubuntu-ci-eng
<cjwatson> they need a manual hint but I wanted click to land first
<cjwatson> manual hint just because the autohinter isn't smart enough to notice the relationship between the multiple source packages involved
<ogra_> ah, thanks i didnt realted that to the silo number :)
<ogra_> *relate
<cjwatson> usually it manages it but sometimes it needs help
<cjwatson> so I have the hint prepared but I'll wait for click to get through
<stgraber> infinity, pete-woods, sil2100: just replied in #ubuntu-ci-eng, I rejected due to a bunch of changes in there not having bug references. And yes, it's a massive fail if those rejection e-mails don't get to anyone...
<pete-woods> stgraber: if I indent the bullet points will that count? I was just trying to describe the fix in more detail (as it got rejected for that last time)
<cjwatson> The previous rejection wasn't because there wasn't enough detail, it was because the changelog literally didn't even slightly match the change
<cjwatson> (And, indeed, contained no (relevant) bug references)
<cjwatson> What we're doing is downloading the source package in question and debdiffing it against what's currently in trusty-updates
<cjwatson> The change now at least seems to match up, which is better than before
<cjwatson> But I expect stgraber has reviewed it a bit harder than my skim-read
<cjwatson> Just wanted to clarify the reason for the *previous* rejection
<pete-woods> cjwatson: the problem is I was told to make the diff against what had got released, not against what was in proposed
<pete-woods> so that's why the original changelog looked like that
<pete-woods> I'm just trying to satisfy everyone's requirements here
<cjwatson> I think that's not really good practice unless you're actually discarding all the previous work and effectively rebranching from the version in trusty
<cjwatson> Which would be pretty unusual
<cjwatson> I don't know who told you to do that
<stgraber> for anyone interested, the debdiff is: http://paste.ubuntu.com/7587535/
<cjwatson> This way is definitely more like what the SRU team would normally expect
<stgraber> I'm having an hard time matching the diff with the changelog which is usually a pretty bad sign...
<cjwatson> I wasn't sure, would probably have gone off to check the bzr history if it had been me reviewing it
<pete-woods> apart from the missing bug references, the changelog describe what's changed to me at least
<pete-woods> I was just trying to describe what I did to prevent the crash introduced in the previous release
<stgraber> I don't see where the changelog tells me why you dropped the pre-start of that upstart job or why it's needed
<pete-woods> it was duplicated
<pete-woods> I don't know how it happened
<pete-woods> but yes, I should have mentioned that
<pete-woods> I can even ditch that part of the change if that helps
<pete-woods> it just looked crazy to me to have the section twice in there
<pete-woods> somehow it never stopped the upstart job from working
<stgraber> nah, dropping the duplicate section is fine and may save you some trouble later (should someone decide to change one of them) but it needs to be documented so people looking at the diff (which doesn't include the whole file knows what's going on there and goes to look a bit closer :))
<stgraber> there's also that utopic changelog entry which looks a bit odd but that may have been caused by whatever script generates the changelog for you...
<pete-woods> in terms of the other changes, is there a way to say that these 3 things all refer to the same LP bug?
<stgraber> sure, put the same bug number for each of them
<pete-woods> okay, cool
<stgraber> or ident them below the first one so I know it's additional description and not separate chagnes
<cjwatson> Or indenting is fine too
<stgraber> *changes
<stgraber> *indent
<stgraber> (typing is hard this morning apparently...)
<cjwatson>   * General description of change (LP: #nnnnnnn):
<cjwatson>     - first part
<cjwatson>     - second part
<cjwatson> or whatever
<pete-woods> okay, cool, I will use that format, thanks!
<pete-woods> I figured out where the utopic stuff came from, looks like CI-train accidentally merged to the 14.04 branch instead of 14.10
<pete-woods> or something along those lines
<pete-woods> so next time won't have the utopic stuff
<seb128> pete-woods, if you do a SRU/target trusty, you need to state it in the comments so whoever does the silo config targets the right serie
<seb128> (not sure if that was your issue there)
<pete-woods> seb128: yes, the problem was a manual upload to utopic had its changes merged into the trusty trunk
<pete-woods> it wasn't my upload
<pete-woods> indeed, it was not CI train at all
<sil2100> pete-woods: maybe there was some configuration mis-happening during the failures we've been having
<sil2100> pete-woods: ok, let's reconfigure the silo with your branch then and try re-publishing, double-checking all the targets
<pete-woods> sil2100: cool, I have updated the proposed branch now, so hopefully we are good to go :)
<sil2100> pete-woods: I see it targetting the right branch - was it targetting trunk before?
<pete-woods> sil2100: I don't think it was CI train that went wrong
<sil2100> pete-woods: ah, so what do you think is the case?
<pete-woods> I think someone pushed manually after a manual upload
<pete-woods> maybe I hadn't updated the series at this point, as I wasn't expecting any releases
<sil2100> pete-woods: ok ;)
<sil2100> pete-woods: so anyway, now is the lp:hud/14.04 branch clean (like only having trusty changes) and the fix branch ready?
<pete-woods> sil2100: yes, just removed the mistaken changes about 30 minutes ago
<sil2100> ACK
<sil2100> Excellent
<sil2100> Then just set the silo to ready once it's done and tested and I'll publish
<pete-woods> sil2100: cool, thanks
<rcj> stgraber,
<rcj> All of the architectures built for libdumbnet, can it be moved to main this morning?
<stgraber> rcj: it should already be in main
<stgraber> rcj: yep, it is and has been since yesterday evening
<rcj> stgraber, I was looking at the upload queue which only showed it in universe.  Lesson learned.  Thanks.
<stgraber> rcj: " Missing build dependencies: libcunit1-dev "
<stgraber> rcj: you said libdumbnet was the only one...
<rcj> stgraber, I seriously thought it was... Link to the dep failure?
<stgraber> rcj: https://launchpadlibrarian.net/176896809/buildlog_ubuntu-precise-i386.open-vm-tools-lts-trusty_2%3A9.4.0-1280544-5ubuntu6~precise1_MANUALDEPWAIT.txt.gz
<rcj> stgraber, cunit moved to main in Saucy.  Looking now...
<shadeslayer> ScottK: ^^ 4.13.1 , can you plz accept
<ScottK> shadeslayer: It's all in utopic already?
<shadeslayer> ScottK: no, because we're merging there
<shadeslayer> and I don't want to block
<ScottK> ok
<pete-woods> sil2100: the HUD packages have built now (except for PPC which seemed to have a crazy slow builder that timed out the tests)
<sil2100> pete-woods: let me rebuild ppc then
<pete-woods> thanks
<cjwatson> sil2100: which builder was it on before?
<sil2100> cjwatson: argh, I don't know, already retried - can I get the info somehow still?
<cjwatson> sil2100: Not in the DB any more, but let me check the buildd-manager logs
<cjwatson> ross - i.e. a ten-year-old xserve
<cjwatson> unfortunately the two decent powerpc buildds are going to be busy for a few hours with webkitgtk and openjdk-7 respectively
<cjwatson> so I guess you could trust to luck
<cjwatson> It's on adare now which is the same hardware generation
<pete-woods> sil2100: seems like we don't even try running our tests under valgrind on ppc64, so maybe we should do the same on plain old ppc - it's a huge slowdown
<Laney> Would somebody please promote grilo? https://bugs.launchpad.net/ubuntu/+source/grilo/+bug/1116098
<cjwatson> That might just have been because valgrind didn't exist on ppc64el until April
<cjwatson> But it'd be a reasonable workaround anyway
<pete-woods> yeah, that's pretty much what I was thinking
<pete-woods> although I guess ppc64 = fast modern server
<pete-woods> not poor old xserve
<cjwatson> Yes, I wouldn't expect ppc64el to have a speed problem with pretty much anything ever
<cjwatson> sagari is pretty modern too and sulfur isn't terrible, so if all else fails we can reschedule on one of those once they're free
<pete-woods> cool, thanks
<cjwatson> (And hopefully we'll get powerpc converted to VMs on fast modern servers soon too)
<pete-woods> this is definitely something I need to fix / workaround in the short term, though
<pete-woods> as I can't come bothering you guys for every single HUD landing
<pete-woods> woot, it built this time :)
<stgraber> mdeslaur, jdstrand: do you have any problem with me promoting cunit to main in precise for open-vm-tools-lts-trusty? It's sadly not the exact same version as the one in trusty and I'm not sure we want to SRU the whole thing so that it's in sync. On the other hand, this is just a unit test framework, so seems low risk to me.
<mdeslaur> stgraber: no objection from me
<stgraber> ok, good. cunit doesn't have any universe build-dep so it seems safe to do the copy to updates + override trick
<stgraber> doing that now then
<rcj> stgraber, thank you for running this down.
<stgraber> rcj: in 30min or so I should be able to override cunit into main which should fix the open-vm-tools-lts-trusty build and finally get us binaries
<rcj> stgraber, that's excellent news
<stgraber> infinity: any idea why "./copy-package -d ubuntu -s precise --to-suite=precise-updates -b --auto-approve cunit" would get rejected?
<stgraber> infinity: I get: cunit 2.1-0.dfsg-9 in quantal (binaries conflicting with the existing ones)
<infinity> stgraber: That doesn't make much sense, given quantal has a different version...
<infinity> stgraber: Can you bounce the reject?
<infinity> stgraber: I can't find that string in LP anyhere...
<infinity> Oh, cause I can't type.
<infinity> stgraber: Oh.  Could be a goofy breakage because the original source was actually karmic, and the set of binary builds there doesn't match.  I know there's a bug/misfeature around that...
<infinity> stgraber: Might be easiest to just upload a rebuild. :/
<stgraber> infinity: yeah, I'll do that...
<stgraber> infinity: ^ just did a local test build and things look good (was slightly worried as karmic => precise is quite a bit of time)
<rbasak> cjwatson: this may be a really stupid question (which is why I haven't replied to the ML). It sounds like you're re-inventing the idea of a stable release, which we already have. So why is this different?
<rbasak> If it's a relatively short term thing until things mature, does that mean that the need for this could disappear over time?
<rbasak> I'm just curious - I am not a stakeholder at all here, but I wondered if I'm missing something, or if others will have that question.
<stgraber> rbasak: see near the end of the e-mail, the plan is indeed for this to go away
<stgraber> rbasak: the main problem is the date of the RTM being months before the 14.10 release date
<stgraber> rbasak: we don't want to freeze the whole distro months ahead of schedule so forking the archive at whatever point cjwatson finds appropriate and then only landing the bits that are actually needed for the phone RTM image seems easier and less painful for people working on the rest of Ubuntu
<ScottK> stgraber: Once this works once, how do things ever get back to alignment.
<stgraber> ScottK: oh I absolutely agree with the feeling, some people will probably fight hard to keep the fork, however my hope is that it'll be sufficiently painful for them to keep stuff in sync that switching back to using the distro will be the obvious choice there.
<ScottK> Only if there's some alignment of release schedules?
<rbasak> stgraber: ah, OK. I interpreted that as the limited lifetime of individual RTM branches, as opposed to any limited lifetime of RTM branches altogether.
<stgraber> I guess the plan is that once we've demonstrated that things can work and we have device out that we are in better position to dictate release dates for the OS and avoid that kind of things in the future
<ScottK> Because cadence is important.
#ubuntu-release 2014-06-05
<cjwatson> shadeslayer: you could unstick a chunk of KDE from utopic-proposed by making kdepimlibs b-d on libboost-graph1.55-dev rather than libboost1.55-graph-dev, I think
<infinity> cjwatson: Build-depending on packages that actually exist is so last year.
<infinity> cjwatson: Erm, I also don't see that issue?
<infinity> cjwatson: It seems to build-dep on libboost-graph1.55-dev and then FTBFS.
<infinity> Oh.
<infinity> I'm looking at kdepim, not pimlibs.
<infinity> I'll just fix that for them.
<infinity> shadeslayer: Nevermind cjwatson above, I uploaded the fix.
<ScottK> shadeslayer can still fix it in bzr (unless you did that too).
<infinity> ScottK: I did.
<ScottK> Great.  Thanks.
<infinity> ScottK: I try to be a good little kubuntu member when I touch your packages. :P
<ScottK> Appreciated.
<infinity> Even if I haven't actually booted or looked at the UI in a couple of years...
<ScottK> ;-)
<ScottK> We're going to give having our branches integrated with Debian's on alioth a shot.
<ScottK> That'll make it slightly more fun.
<infinity> Hrm.  That could be interesting for any Ubuntu people without Alioth accounts.
<infinity> In practice, I suspect not a big deal, as very few (core-)devs touch your packages, and those that do probably have at least alioth guest accounts.
<infinity> And, of course, if you're careful to make sure out-of-band uploads don't get dropped, it's a moot point.
<ScottK> It's not like they're hard to get.
<ScottK> Besides, if Canonical's moving stuff like juju off of LP, I don't feel bad about experimenting with going as far as Debian.
<RAOF> Oh, are we moving juju off LP?
<ScottK> Already did.
<ScottK> See Jorge's blog post.
<rbasak> infinity, ScottK: so what's the best way for an infrequent uploader to notice when a particular package has a maintained external VCS tree? Just the Vcs-* headers, or something else?
<rbasak> (since the Vcs-* headers are often inherited from Debian and not replaced)
<ScottK> rbasak: If there's a separate VCS you ought to worry about, then they should be replaced.
<ScottK> If they aren't, I think it's not your problem.
<rbasak> ScottK: so if I see alioth, I might assume that they're not replaced. If you use alioth that's a problem though right?
<ScottK> Good point.
<rbasak> I wonder if there's any possibility for tooling to detect the field and warn me somehow. As it'd be an unusual case for me, I'm worried that I'll forget to even look, since the majority of cases when I do look I won't need to do anything. It'd be an easy mistake to make.
<rbasak> (assuming that I apply/get core dev eventually, which I don't have now)
<rbasak> I'm thinking of something like a central srcpackage->bool mapping, with yes-uses-vcs or no-does-not-use-vcs, and some kind of pre-dput hook which forces me to say --yes-i-know-about-the-vcs when my ~/.something tells it to require that, that I might turn on.
<ScottK> If you apt-get source, you get a warning.
<shadeslayer> rbasak: ScottK tbh infrequent uploaders frequently tend to forget to update bzr when doing KDE packages, so it's not something new, we'll keep syncing the packaging to git, should we move to alioth
<Laney> shadeslayer: can you make it writable by Debian at least? :-)
<infinity> rbasak: To be honest, while I try to be a good VCS citizen where and when I can, it's still the case that source packages are authoritative and it's the responsibility of VCS users to make sure they check for unmerged uploads.
<infinity> rbasak: So, while it's good to do as you do and try to play nicely, it's also not strictly speaking your responsibility to do so when doing a one-shot fix for something someone else broke. :P
<seb128> hey there, I've a SRU question
<seb128> the unity trusty SRU has one of its bugs (the ones listed on the changelog and on http://people.canonical.com/~ubuntu-archive/pending-sru.html) which was wrongly listed
<seb128> is there a way to drop it/make it obvious to the SRU team that it shouldn't block the SRU?
<seb128> everything else got verified/is green on the report
<seb128> that one just happen to be listed in the changelog but not have the actual diff included, so it's not going to be either verified or failed
<xnox> mark it verified-done & later reopen saying "above doesn't actually fix above bug #"
<xnox> or fork the bug, and close the one mentioned in the changelog or some-such.
<xnox> i think i did reopens a few times in the past.
<seb128> k, let's do that
<seb128> xnox, thanks
<infinity> seb128: Is this 1313280?
<seb128> infinity, yes
<infinity> seb128: Right, how about I just release the package, and you can reset the tasks and tags. :P
<seb128> infinity, +1
<seb128> thanks
<infinity> seb128: And please get them to retroactively repair the old changelog entry in bzr so that version no longer claims it fixes that bug after they upload the next.
<seb128> can't change history!
<infinity> You can when history is wrong!
<seb128> so you can ... ;-)
<shadeslayer> infinity: cjwatson: thx
 * shadeslayer points out that kdepimlibs shouldn't have been uploaded btw
<infinity> shadeslayer: Hrm?
<infinity> shadeslayer: A bit late now, I guess. :P
<shadeslayer> yeah
<shadeslayer> it's 4.13.1
<shadeslayer> everything else is still 4.13.0
<shadeslayer> or well, should be
<infinity> kdepim is 4.13.1 too.
<shadeslayer> shouldn't have been uploaded then
<infinity> Though it's also FTBFS.
<shadeslayer> oh
 * shadeslayer checks
<shadeslayer> quite weird, I always build packages locally before commiting to bzr
<shadeslayer> ah grammar
<infinity> seb128: Oh, wait, that bug isn't referenced in the current SRU anyway...
 * infinity scratches his head.
<seb128> infinity, it's on http://people.canonical.com/~ubuntu-archive/pending-sru.html
<infinity> seb128: Yeah, I know.  But not in the current changelog entry.  Maybe there was one preceding it.
<seb128> infinity, yeah, https://launchpad.net/ubuntu/+source/unity/7.2.1+14.04.20140513-0ubuntu1
<seb128> which was superseeded by ubuntu2 the next day
<infinity> seb128: Right.  So, that's already fixed.  Good deal.
<seb128> so seems they fixed history :p
<infinity> http://launchpadlibrarian.net/176537122/unity_7.2.1%2B14.04.20140513-0ubuntu1_7.2.1%2B14.04.20140513-0ubuntu2.diff.gz
<infinity> Yeah, the fixed history.
<infinity> Lovely.
<infinity> SRU released.
<seb128> thanks
<infinity> Bug not autoclosed.
<infinity> Life is good.
<seb128> how come the tracker still had it?
<infinity> I guess it tries to be clever by parsing all versions between A and B.
<infinity> Rather than a diff between A and B.
<seb128> that makes sense
<psivaa> xnox: hey, i see bug 1309617 is assigned to you and i have an install which behaves somewhat the same way as described  in it. this also affects the server smoke tests,
<psivaa> just fyi, i should be able to reproduce fairly reliably if you'd need any more information on it
<pitti> I'm about to upload the first set of utopic langpacks; is there any reason why this is a bad time?
<pitti> cjwatson, infinity, ogra_ ^
<cjwatson> I know of nothing that should stop you
<pitti> I don't see anything either (no test rebuild planned, over-busy buildds, etc.), but I thought I'd check
<ogra_> pitti, unlikely to break anything in touch i guess
<pitti> ogra_: right, I meant more in terms of general traincon-0 or diff noise, etc.
<ogra_> thats all fine, its non intrusive and we can ignore langpacks in the diff
<pitti> ogra_: ack, thanks for confirming
<cjwatson> stgraber: could you add an appropriate cunit task to bug 1275656?
<stgraber> cjwatson: oh right, sure
<stgraber> cjwatson: thanks!
<cjwatson> np
<stgraber> cjwatson: did you accept it in main directly?
<cjwatson> no, I just used sru-review
<cjwatson> feel free to override once published
<stgraber> ok, will do that then, thanks
<stgraber> rcj: ^ so hopefully in a couple of hours open-vm-tools-lts-trusty will finally build :)
<rcj> stgraber, cjwatson: thank you both
<slangasek> barry: so discussing with sil2100, while the autopilot test .debs now correctly depend on python-autopilot if needed, it seems there's some fragility there because people aren't paying close attention to that stack (leading to u-a-l problems)
<slangasek> barry: are the TODOs from https://blueprints.launchpad.net/ubuntu/+spec/core-1311-python3-roadmap still on the radar?
<barry> slangasek: well, i'm happy to keep helping with those, but they aren't on my radar.  dialer-app is a good example.  my branch works for me locally but so far hasn't passed jenkins.  i haven't touched the other todos (address-book actually was merged afaik)
<slangasek> barry: ok; seems like it would be a good idea to follow through on these
<barry> slangasek: it should be easier now (hopefully) to figure out the long tail of ports needed, i.e. dependency on autopilot-legacy
<barry> slangasek: i'll carve out some time to take a look
<cjwatson> I just noticed that colord/i386 didn't build due to B-D-I: argyll; perhaps somebody should revisit bug 821883?
<infinity> RAOF: Care to champion 821883?
<infinity> RAOF: (Or make colord not need it, your call)
<rcj> stgraber, with cunit built, when would open-vm-tools-lts-trusty build?  Just don't know how to tell if it's waiting or when it's stuck.
<jdstrand> fyi, I changed the override for ninja-build prior to oxide Build-Depends hitting the archive
<jdstrand> (MIR was accepted alread)
<jdstrand> oxide is building in the security team ppa, once it is copied over, the mismatch should go away
<stgraber> rcj: open-vm-tools-lts-trusty built and accepted, should appear on archive.ubuntu.com in the next 30min
<rcj> stgraber, thanks
<bdmurray> has anybody looked at the mythtv SRU for trusty? it seems more like an MRE to me.
<bdmurray> bug 1323391
<infinity> bdmurray: One doesn't need an MRE to do a new microversion, just to do one without extensive pain and review. :P
<infinity> If this is bugfix only and one of us is willing to review it, there's nothing wrong with it, in theory.
<infinity> (And if they have a testing strategy, etc)
<bdmurray> infinity: got it
<infinity> bdmurray: Plus, being LTS only, and mythtv being pretty much the raison d'Ãªtre of mythbuntu, I can see the argument that they should perhaps be allowed to keep the flagship piece of software in a good state. ;)
<infinity> (Again, if they have a good testing strategy, blah blah)
<superm1> if our testing strategy needs some improvement we're happy to add something more thorough.  a majority of the validation for it has been happening upstream on an individual branch that wasn't merged until it got enough "works for me, no regressions"
<tgm4883> infinity: bdmurray I'd like to add that we keep a daily builds PPA that pulls from that fixes branch so users can be up to date/test our packages. We suggest using the PPA, but there is still a large portion of users that install and only do updates from the "official" repos. Anything that we try to SRU would have gone to that PPA first for testing
<tgm4883> so as superm1 said, it's tested upstream by the mythtv developers in a separate branch before getting merged to their "fixes" branch, then we pull that fixes branch (daily) and build for release on our PPA, and this SRU is to ensure that the users that only update from the official repos will still get an updated build of mythtv. I'd expect we'll do another
<tgm4883> SRU for the 0.27 fixes branch for 14.04.2. As a policy, we will NOT do an SRU for a major mythtv version (eg. we won't do an SRU for 0.28 for 14.04.x)
<RAOF> infinity: That would require adopting it in Debian, which I'm considering. For the moment I'll drop the argyll requirement for colord, though.
<RAOF> infinity: ...once I work through the transition in Debian :)
#ubuntu-release 2014-06-06
<ogra_> stgraber, "Daily rebuild quota reached for product." ... i got that for touch on the iso tracker ... thought you might want to know about it :) (i started a build directly on nusakan now)
<apw> ogra_, i wonder when the day starts, as it is pretty early relative to UTC
<ogra_> apw, well, i never know if he is in switzerland or canada TZ :)
<apw> ogra_, well i was more thinking of the day for the quota system :)
<ogra_> hah
<Chipaca> any MOTUs around?
<apw> Chipaca, there are bound to be, but they will likely be more responsive to a specific question
<Chipaca> apw: asked more specifically in #ubuntu-motu
<Chipaca> not getting any love there though :)
<rbasak> Chipaca: you need to give it more than a few minutes :) Looking.
<Chipaca> rbasak: I am nothing if not impatient
<infinity> ogra_: Daily quotas are intentional, so no one flavour decides they're so important that they can choke out all the infrastructure's resources.
<ogra_> infinity, interesting ... its not like we did build more than two images a day
<ogra_> 3 at times ... but rarely
<infinity> ogra_: It's possible it's intentionally but also broken. :)
<ogra_> hehe
<infinity> s/intentionally/intentional/
<ogra_> that is why i pinged stgraber about it
<infinity> ogra_: "Living in the past will be possible in the near future"... Hah!
<infinity> ogra_: Wow, and my brain decided to quote you backwards.  I might need to wake up.
<ogra_> haha
<rtg> stgraber, I've corrected the openipmi version that you objected to and have re-uploaded.
<robru> cjwatson, ping about platform-api again. I hit publish on the silo but it doesn't seem to have made it into proposed, likely because of that version issue. any way to fix it?
<infinity> "That version issue"?
<robru> infinity, yeah sorry, was talking with cjwatson about this yesterday
<robru> infinity, what happened is, platform-api was supposed to build v1.2.0 in a ppa, but because the ppa had an old, deleted v2.0.0 in it, citrain screwed up and built 2.0.0 anyway. then *I* screwed up and published that, but it got stuck in -proposed. cjwatson deleted it from -proposed already, so I then rebuilt 1.2.0 correctly and published that, but the upload to -proposed was rejected
<robru> or at least i assume it was rejected, because it's not in proposed. i don't get rejection mails...
<robru> infinity, https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc&rm=full&pli=1#gid=37 here's the status showing platform-api not in proposed along with the rest of the silo
<infinity> robru: How do I determine what PPA that's in, so I can try a manual copy?
<infinity> Oh, it's at the top.
<robru> infinity, that link I gave has a link to the PPA, but also here: https://launchpad.net/~ci-train-ppa-service/+archive/landing-019 yeah ;-)
<robru> infinity, silos are always https://launchpad.net/~ci-train-ppa-service/+archive/landing-0##, I have a saved search for that ;-)
<infinity> robru: Was accepted just fine on a manual copy.  So either your original attempt was before it was deleted, or something else went wrong.  Without the emails, it's hard to tell. :/
<infinity> robru: Copied now, though.
<robru> infinity, great, thanks.
<robru> infinity, yeah, I tried to subscribe to the team that gets the jenkins rejection emails but nobody approved me for that, not sure who to ping
<robru> infinity, i believe cjwatson did the deletion yesterday, so i doubt there was a race between his deletion and my upload (an hour ago). something else is wrong i guess, but at least this is an isolated case
<cjwatson> robru: There's no sign of a copy attempt in the Launchpad logs before infinity did a manual copy
<cjwatson> robru: So something must have been confused on the CI side, but I can't say I know what
<robru> cjwatson, thanks for checking. here's the log, I guess it didn't copy: https://ci-train.ubuntu.com/job/landing-019-2-publish/32/console
<cjwatson> robru: Right, that's a citrain refusal
<cjwatson> robru: It points to the "ignore version destination" option which sounds like it would have been plausible
<cjwatson> robru: But if you were using that and it still didn't work then I guess it's a citrain bug
<robru> it's funny how many individual things had to go wrong for us to get to this state. one landing was in one silo, but then got moved to a different one. the next landing in the first silo contained one of the same projects as the previous landing.  also this would not have been a problem if upstream hadn't bumped the upstream version number
<cjwatson> robru: FWIW if it *had* been a Launchpad copy error then you would have got mail about it as the publisher
<robru> cjwatson, yeah, i had that option checked
<robru> ah
<cjwatson> (regardless of any team that gets jenkins rejection mails)
#ubuntu-release 2014-06-07
<doko> pitti, cjwatson: this blocks libffi, I assume this is some haskell transition issue? https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-haskell-yesod-bin/lastBuild/?
<cjwatson> doko: yes, am most of the way through that and should be done next week
#ubuntu-release 2015-06-01
<kamal> hi, I'm looking for an SRU-team member ...  an SRU package in the unapproved SRU queue has been determined to be invalid, so I'd like it de-queued:  fldigi (3.22.04-1ubuntu1) for vivid
<stgraber> hmm, so I'm trying to figure out why golang isn't migrating to the release pocket and my britney skills appear too limited for that... update_excuses lists it as a valid candidate and update_output mentions something about vim-gocomplete which seems a bit odd since it doesn't depend on golang and can be co-installed fine (just tried in a wily-proposed container)
<stgraber> infinity: if you happen to still/already be around? ^
<cjwatson> stgraber: vim-gocomplete depends on vim-syntax-go, which is no longer produced by the latest golang source
<cjwatson> cf. https://tracker.debian.org/media/packages/g/golang/changelog-2%3A1.4.2-3 2:1.4.1-1~exp1
<ogra_> needs renaming ... vim-gone-complete :)
<cjwatson> http://bugs.debian.org/786891
<ubot93> Debian bug 786891 in gocode "vim-syntax-go no longer built from source" [Important,Fixed]
<cjwatson> stgraber: I think it just needs gocode to be migratable too
<cjwatson> stgraber: which requires gocode not to FTBFS on powerpc, which ISTR is not the only Go-related package with this problem on that arch
<tedg> infinity, Were you able to get Mir building on PPC?
<stgraber> cjwatson: ah, right, so stuck on that gccgo bug then
<stgraber> cjwatson: thanks for the analysis
<stgraber> and yeah, a lot of things are failing with recent gccgo on powerpc, doko is aware and looking into this
<doko> cjwatson, stgraber: can't find the time for that, so I would propose to remove the powerpc binaries. but then again, I don't know if snappy is needed on powerpc ...
<stgraber> and I don't suppose reverting to vivid's gccgo is an option? that one worked fine IIRC
<stgraber> (it's not just snappy, this bug also affects docker, lxd, ... so we can certainly live a few weeks without powerpc support, but we can't release 15.10 like that)
<doko> I know. I verified that I can build ~rc1 in wily, but, wasn't able to bisect any change which let's this fail on powerpc. even 5.1.0-1 is broken
<doko> and for some reason, it works in unstable on powerpc
<infinity> doko: Yeah, the part where it works in sid but not wily is driving me batty too.  I was really hoping we'd magically fix it with the binutils merge, but no such luck. :(
<infinity> doko: And, in principle, I'm okay with removing ppc Go binaries to get past this, *but* the different results between sid and wily point to something Very Bad going on here, and I'd like to understand what's going on before just handwaving past it.
#ubuntu-release 2015-06-02
<Ukikie> Wasn't owncloud supposed to be blacklisted from Ubuntu?
<cjwatson> Ukikie: It was removed from utopic and up; blacklisting isn't normally necessary
<cjwatson> Ukikie: Though in this case blacklisting seems reasonably appropriate, and indeed it is in the sync-blacklist
<Ukikie> Asked due to owncloud-tasks and owncloud-antivirus
<cjwatson> Blacklists aren't wildcards
<Ukikie> Right.
<cjwatson> Those probably ought to be removed referencing bug 1384355
<ubot93> bug 1384355 in owncloud (Ubuntu Utopic) "ownCloud should be removed" [Undecided,Fix released] https://launchpad.net/bugs/1384355
<cjwatson> I'll do that in a moment
<Ukikie> Great, "thanks"
<cjwatson> Also owncloud-apps
<cjwatson> Ukikie: all done, thanks
<Ukikie> Sure, glad it's helpful.
<sil2100> Hello release team! I disabled the system-image importer temporarily for some channel-additions
<sil2100> And the importer re-enabled again
<slangasek> bdmurray: I'm getting this error even though the diff is clearly available in launchpad; any ideas?: $ sru-review -s trusty flash-kernel
<slangasek> ERROR: queue does not have a debdiff
<bdmurray> slangasek: looking
<bdmurray> slangasek: it looks like it may be something with the debdiff_re
<bdmurray> slangasek: hunh, nope that's not it. the scraped html contains "diff from 3.0~rc.4ubuntu49.4 to 3.0~rc.4ubuntu49.5 (pending)"
<infinity> bdmurray: Except, it really doesn't?
<infinity> diff from 3.0~rc.4ubuntu49.4 to 3.0~rc.4ubuntu49.5 (742 bytes)
<bdmurray> infinity: Right, I see what it says when I look at the same url in firefox. urlopen is returning different content for some reason.
<bdmurray> slangasek: sru-review works now w/ no changes to sru-review
<infinity> bdmurray: Logged in versus not logged in, perhaps.  One was getting cached data, the other was forcing fresh.
<sergiusens> can we get a waiver for goget-ubuntu-touch failing on gcc-go for powerpc http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<infinity> sergiusens: We're working on the toolchain bug.
#ubuntu-release 2015-06-03
<sergiusens> infinity: oh goodie, I had word that it wasn't going to be worked on
 * sergiusens will just wait
<infinity> Word from whom?
<sergiusens> infinity: it's probably broken telephone (or whatever that game was called)
<rsalveti> sergiusens: infinity: that's just because doko said he didn't have the time to fix such issues
<rsalveti> but if you say you guys are on top of it, then even better
<infinity> rsalveti: We're looking into it.  doko has a workaround if we can't get to a proper fix in a timely fashion.
<infinity> rsalveti: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66368
<ubot93> gcc.gnu.org bug 66368 in go "[5 Regression] go tool crashes on powerpc-linux-gnu" [Normal,Unconfirmed]
<rsalveti> great
<arges> infinity: was maas ever granted an MRE for 1.7.5 in trusty?
<arges> or is it still a no-go because of upgrading causing users to re-import images
<sil2100> Hello! We would need an archive admin's assistance with signing-off a package that's ready for publishing
<sil2100> We need an archive admin's +1 and review since it adds a new binary package
<sil2100> https://ci-train.ubuntu.com/job/ubuntu-landing-017-2-publish/lastSuccessfulBuild/artifact/telepathy-ofono_packaging_changes.diff <- that's the packaging diff
<sil2100> infinity, slangasek: ^ ?
<infinity> arges: The import thing was fixed, or so they told me.  There's no blanket wave-it-through exception granted yet, but I intend to let that one in and see how it goes.
<arges> infinity: shall i do the honors then
<infinity> sil2100: Looks reasonable to me.
<infinity> arges: I was going to look at it more closely after breakfast.
<sil2100> infinity: \o/ thanks, publishing
<arges> infinity: ack
<ChrisTownsend> arges: Hi!  Are you on SRU duty today?
<arges> ChrisTownsend: yes
<arges> ChrisTownsend: lemme guess... unity?
<ChrisTownsend> arges: Cool, yep, it reverts a commit that was causing a crash regression.
<ChrisTownsend> arges: Do you need the debdiff?
<arges> ChrisTownsend: makes it easier
<arges> than doing it the manual way
<ChrisTownsend> arges: Ok, give me 5 minutes and I'll attach it to the bug.
<ChrisTownsend> arges: Ok, added the debdiff to https://bugs.launchpad.net/unity/+bug/1451613.
<ubot93> Launchpad bug 1451613 in unity (Ubuntu Trusty) "[regression] Unity/compiz crashes when locking screen" [Critical,In progress]
<arges> ChrisTownsend: looks good accepted
<ChrisTownsend> arges: Thanks!
<boiko> hi, I have changed telepathy-ofono packaging to not build one of its subpackages in arm64, powerpc and ppc64el, and now update excuses says there are some old binaries left on those platforms
<cjwatson> boiko: looking
<boiko> cjwatson: it is the telepathy-ofono-ril-mc-plugin that is not building on arm64, powerpc and ppc64el anymore
<cjwatson> boiko: rationale for the change?
<boiko> cjwatson: the package needs libhybris-utils which is not available on those arches
<cjwatson> boiko: aha, makes sense.  removed
<boiko> cjwatson: as we initially landed this change in the vivid overlay ppa, we didn't realize the dependency was not available there
<cjwatson> right
<tedg> infinity, Were you able to have any luck with Mir on PPC?
<infinity> tedg: I made a bit of progress, then got a bit distracted from my debugging, sorry.
<tedg> infinity, K, I guess the question is more "close" or "delete all the binaries" :-)
 * tedg assumes everyone builds from source
<infinity> tedg: I think it's fixable, and fixing is the right direction to be going in.  Just need to dig up a round tuit or two to attack a weird testsuite crash with gdb.  Or ignore that test for the time being.
<infinity> Well, there's also this failure, which just reeks of bad math somewhere:
<infinity> Expected: is equal to 0x100349df340
<infinity>   Actual: 0x349df340 (of type gbm_device*)
<cjwatson> that reeks of G_POINTER_TO_INT abuse or whatever it is
<tedg> Hmm, kgunn do you know who infinity could ping about that? ^
<kgunn> tedg: infinity might ping racarr or kdub in #ubuntu-mir
<boiko> cjwatson: what does the regression result mean? should I do something on my side?
<cjwatson> boiko: I don't know, ask CI folks
<infinity> Not shockingly, I'm amazingly suspicious of any function called "reinterpret_cast"...
<infinity> Dear C++, WTF.
<cjwatson> not really a function
<infinity> cjwatson: A compiler directive, apparently, but yes.
<slangasek> I hear C++11 adds a philip_glass_interpretation < > directive
<infinity> tedg: Oh, FFS.  I should have tried ppc before ppc64el.
<infinity> tedg: http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/src/server/scene/gl_pixel_buffer.cpp#L59
<infinity> tedg: That's a bit more porting work than I was willing to sign up for.
<infinity> tedg: So, yeah, let's look into removals. :(
<tedg> Haha, funny. At least it's documented :-)
<tedg> infinity, Can we just disable the tests?
<infinity> tedg: I suppose we could do that instead.  But we run into the potential for breaking rdeps if something links against a Mirish thing and then actually uses it.
<infinity> tedg: But, in most cases, I imagine the rdeps are fairly lame, except when running in a unity8/mir world.
<tedg> infinity, At least in the UAL case you'd have to be using a pretty desktop specific featureâ¦
<infinity> tedg: The only scary rdep is gtk3.  Which is kinda super scary.  But it currently doesn't try to link against libmir on ppc, and we can just keep it that way.
<infinity> tedg: All the other rdeps seem pretty mir-specific to start with, so I doubt we can make things worse by letting them build but suck a little.
<cjwatson> I remember looking at that and thinking it wasn't *super* difficult ...
<cjwatson> IIRC it's just that file
<infinity> cjwatson: Well, there are two other bugs to hunt too, but yes, I think that file (that function, even) might be the only thing that needs *porting*, rather than bug fixing.
<tedg> infinity, WFM, at least in the near term I don't imagine we'll have a lot of Mir users on PPC.
<infinity> cjwatson: But I'm not in the mood to wrap my brain around endian transforms of whatever that is (pixel colourspaces?)
<cjwatson> It strikes me as the sort of porting that needs pencil and paper, indeed
<infinity> tedg: For big-endian PPC, it might become relevant in the community as the world moves more towards Mir, Wayland, or bust.
<tedg> Back a long time ago (before gcc 3) that was the only case I found that tail recursion was faster than a for loop :-)
<infinity> tedg: For ppc64el, IBM has made noises about desktoppish things "in the future".
<infinity> tedg: But neither is today.
<tedg> That would be kinda cool. I have a warm spot in my heart for PPC.
<tedg> Though I imagine I'll have an arm64 desktop first :-/
<infinity> tedg: Well, unless some OpenPower partners go small/low-power in the near future, any POWER8 "desktop" kit would be high end workstations right now, not exactly home user stuff.
<tedg> DON'T JUDGE MY HOME!
<tedg> ;-)
<infinity> tedg: But there's been noise about shrinking P8 and P9 for more specialised uses, so never say never.
<infinity> That said, with the whole CAPI thing, a P8 workstation would be a force to be reckoned with.
<infinity> SO MUCH GPU BANDWIDTH.
 * infinity shakes.
<infinity> tedg: So, I'll hang on to this WIP branch, but lemme test if it vomits out interesting results if I just skip the testsuite.
<tedg> infinity, Cool, thanks!
#ubuntu-release 2015-06-04
<hyperair> could a friendly ~ubuntu-sru person please release banshee from the vivid queue? banshee's completely unusable in vivid and people are bugging me left right and center for the fix.
<infinity> hyperair: Looking.
<hyperair> thanks
<infinity> hyperair: LGTM.
<hyperair> lgtm?
<infinity> Looks good to me.
<hyperair> oh
<hyperair> yay
<hyperair> infinity: thanks
<Mirv> could an archive admin pre-bin-NEW-ack qtdeclarative5-ubuntu-addressbook0.1 from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+sourcepub/5111080/+listing-archive-extra ?
<Mirv> I'd like bug #1342031 to be fixed for that package instead of adding another package with the old naming, but I don't force people to
<ubot93> bug 1342031 in unity-action-api (Ubuntu) "Rename QML modules to follow qml-module-foo naming" [Low,Triaged] https://launchpad.net/bugs/1342031
<robru> I need an archive admin to ack a new binary package, https://ci-train.ubuntu.com/job/ubuntu-landing-016-2-publish/84/artifact/address-book-app_packaging_changes.diff/*view*/ please & thanks
<infinity> robru: I'm not sure I get the *point* of the split, if component A depends on B anyway, unless A is huge.  But the diff seems sane for the stated intent.
<robru> infinity: I'm not sure either, somebody else was spearheading this. thanks!
<cjwatson> infinity: Perhaps something else is now just going to depend on B.
#ubuntu-release 2016-06-06
<Logan> can someone please reject my musescore upload in Xenial? I did the version numbering incorrectly :(
<Logan> please reject the first one and approve the second one :3
<flexiondotorg> infinity, Morning
<flexiondotorg> infinity, I've got a couple of package deletions for Yakkety.
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/mate-netspeed/+bug/1584769
<ubot5> Launchpad bug 1584769 in mate-netspeed (Ubuntu) "Please remove mate-netspeed from the Yakkety archive, it is now included in mate-applets" [Undecided,New]
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/gnome-main-menu/+bug/1584767
<ubot5> Launchpad bug 1584767 in gnome-main-menu (Ubuntu) "Please remove gnome-main-menu from the Yakkety archive, it is obsolete" [Undecided,New]
<xnox> hello, please reject "s390-tools (xenial-proposed/main) [1.34.0-0ubuntu8 => 1.34.0-0ubuntu8.1] (no packageset)"
<xnox> will reupload with one more bugfix
<apw> xnox, done
<xnox> thanks
<sergiusens> cjwatson hey, sorry to bug you but I uploaded a package on Friday and can't find it, this is all I have "[ubuntu/xenial-proposed] snapcraft 2.10 (Waiting for approval)"
<cjwatson> sergiusens: it's in https://launchpad.net/ubuntu/xenial/+queue?queue_state=1 awaiting SRU team approval
<sergiusens> cjwatson I swear I checked there :-/ Thanks!
<Trevinho> bdmurray: I got emails about possible SRU regresisons (multiple mails actually :-)), but I think they're nothuing new.
<bdmurray> Trevinho: I agree about the regressions not being new issues.  I'll look into why you got multiple emails too.
<sergiusens> infinity hi there, can I get snapcraft allowed into xenial-proposed?
<apw> sergiusens, the exception for that has all sorts of QA requirements, where are you documenting they are complete?  I don't see anything in the first couple of bugs.
<sergiusens> apw are you talking about https://wiki.ubuntu.com/StableReleaseUpdates#Snapcraft ?
<apw> sergiusens, yep that one
<sergiusens> apw everything change lands with a test in code (snapcraft.tests for unit tests, integration_tests and/or demo_tests)
<apw> sergiusens, right but the SRU is supposed to indicate that all of the steps on https://wiki.ubuntu.com/SnapcraftUpdates have been completed
<elopio> apw: QA here. Everything for this release is tested in autopkgtests. Once it gets to proposed, I do a manual verification.
<sergiusens> apw but our package hasn't been built yet, it is stuck in the unnapproved queue
<apw> sergiusens, i was unable to find that easily, so i was asking where as i was sure infinity will ask
<sergiusens> apw https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=snapcraft
<apw> sergiusens, ahh ok the write up there is not well worded as i took it to mean before queueig, and yet in there is says -proposed, so ... ignore me
<sergiusens> elopio mind rewording a bit ^ ?
<elopio> apw: we do parts before it gets to proposed, and parts after it gets to proposed. I thought that by proposing it, we were saying that we followed the process.
<elopio> apw: I'm happy to make this clearer, just not sure how. Should I comment on every bug the tests we did before proposing it?
<xnox> elopio, apw, sergiusens - autopkgtests do run from silos. you should get a silo assigned, upload for xenial sru, which will build and run packages.
<xnox> then sru team can copy that into -proposed.
<xnox> autopkgtests will run again, and things will publish in -proposed
<xnox> and then migrate to -updates if all is good.
<xnox> please use silos in the future, and then you can satisfy everything upfront.
<elopio> xnox: we run the autopkgtests in jenkins. That works the same as putting the package in the silo, afaik. I'm not sure what we will win by that extra step.
<xnox> elopio, not needing jenkins =) and the fact that SRU team has no visibility into jenkins, but do have visibility into http://autopkgtest.ubuntu.com/
<xnox> and that you don't need to block on stable release updates team accepting your package, to see if it will be accepted. as silo assgniment is self-service.
<xnox> and it's the same binary that will be used into the -updates pocket, as the one build in silo.
<xnox> things built in jenkins, are obviously thrown away =)
<elopio> xnox: so if we put the package in a silo, and it passes the autopkgtests there, it will get to proposed without any manual step?
<xnox> elopio, there is manual step still. but there are less questions about those =)
<xnox> as in, it's more trivial to process then opaque thing. as above.
<xnox> *than
<elopio> xnox: if it simplifies things, I'm not against doing that. But I still don't understand some things, like, I don't see any results from silos in autopkgtest.ubuntu.com.
<elopio> what we are trying to explain in the SRU exception page is that no PR lands into master if the autopkgtests don't pass.
<sergiusens> xnox I cannot dput to silos
<xnox> sergiusens, i know i can.
<sergiusens> xnox we are trying to move people away from the equation, not add them
<xnox> sergiusens, do you release from git/bzr branches? silos can just take that, merge branches for you and throw things into a silo...
<sergiusens> xnox I can dput to the archives but not that train ting
<xnox> sergiusens, and e.g. i think it's easy to get right sto dput thing sinto silos.
<sergiusens> xnox yes, git branches on gitub
<xnox> sergiusens, e.g. i can dput to silos.
<sergiusens> github
<xnox> silos can take things from github direct, without $someone in the middle generating things and dput things
<sergiusens> xnox I don't want to depend on people being around, I already have to chase people down to get the darn package accepted.
<xnox> sergiusens, talk to sil2100 to get dput permissions into silos.
<sergiusens> xnox does it still mangle changelogs and versions?
<xnox> sergiusens, yes, that's what i'm trying to reduce too!
<sergiusens> xnox last I talked to him he said it wasn't possible
<xnox> silos are entirely self-service.
<xnox> i'm sure it is, cause i can dput stuff =/
<xnox> into silos
<sergiusens> xnox yeah, they let core devs dput to silos, no one else
<xnox> sergiusens, oh y, r u not core dev? =)
<sergiusens> xnox no, just ppu
<sil2100> sergiusens: hey! Policies changed a bit, if you have PPU access for some packages then we can give you direct-silo upload permissions
<sil2100> sergiusens: we generally do not want to give those powers right now to people that we don't know
<sil2100> sergiusens: let me add you in a minute
<sergiusens> sil2100 xnox ok, I'll do that for the next upload then
<sergiusens> I consider this one running under the agreed upon course
<sergiusens> it would be good to see the StableReleaseUpdates wiki page mention the fact that silos are now required
<sergiusens> slangasek ^
<xnox> sergiusens, they are not required.
<xnox> but they help you, satisfy your requirements.
<sergiusens> xnox ah, then I'll probably pass. We already satisfy our requirements
 * apw regrets muddying the water
<xnox> general srus are one-off, for unique bugs, and hence upload to unapproved queue, wait forever, test whenever, release whenever is good enough.
<xnox> sergiusens, well, not quite.
<sergiusens> xnox we have an exception
<xnox> sergiusens, silo is self-service, and will allow you to do all the testing sans las publications, and you will find your reviewes from a silo copy of binaries to be done reqlly quickly.
<xnox> instead of always being stuck for 1-5 weeks in the SRU unapproved queue.
<xnox> even though you do satisfy requirements.
<sergiusens> xnox so far we've gone from initial upload to publication in 3 days
<xnox> #toolong =)
<infinity> xnox: Err, since when do silo SRUs get reviewed "really quickly"?
<xnox> silos get same day publication, and you essentially can do manual testing straight away, and autopkgtest testing is done straight away.
<xnox> infinity, you are back =)
<infinity> xnox: The SRU team tends to hate reviewing copies. :P
<xnox> infinity, how alive are you? =)
<xnox> or just really good meds?
 * apw hits the rewind time button, and keeps quiet
<infinity> I'm about 60% alive.
 * xnox passes infinity +5 hp healing potion
<xnox> infinity, i guess it's up to you if you want to see bi-weekly snappy SRU as a source dput, or a copy.
<xnox> one might not build, might fail tests, might fail autopkgtest - the other one managed to pass all that, just before a copy.
<cjwatson> xnox: it might be a good idea to check what the SRU team wants before spending ages advising people what to do :-)
<cjwatson> the problem with copies is mainly the age-old one that it's a pain to get diffs for them
<cjwatson> (which is an LP bug, and so my problem, sure, but it's Hard)
<infinity> cjwatson: Soyuz Redesign!
#ubuntu-release 2016-06-07
<mvo> is there something in   https://launchpad.net/ubuntu/yakkety/+queue?queue_state=0&queue_text=golang-gopkg-macaroon.v1 that I could do to make NEW processing easier for you?
<mvo> infinity: who should I ask about https://launchpad.net/ubuntu/yakkety/+queue?queue_state=0&queue_text=golang-gopkg-macaroon.v1 ? would be nice to get a NEW review of this, its going to be a new dependency of snapd
<infinity> mvo: I was just now clearing the NEW queue, I'll have a look at it this morning.
<seb128> mvo, I can trade you reviews :p
<infinity> Or seb can do it!
<mvo> infinity: thank you!
<mvo> seb128: hm, tell me more ;)
<seb128> mvo, want to have a look to https://code.launchpad.net/~seb128/update-notifier/logs-no-ctime/+merge/295806 in exchange? ;-)
<seb128> I'm waiting for your feedback for a while
<seb128> that's the one that mades update-manager never being auto-opened on xenial
<mvo> seb128: hm, indeed, I remember now
<seb128> :-)
<mvo> seb128: and your patch works?
<mvo> seb128: i.e. with that it opens?
<seb128> mvo, from my local testing yes
<infinity> If it's in yakkety, I'd say it's working, cause I get u-m annoying me in Y.
<seb128> rotating the log updates the mtime and not the ctime
<seb128> no, it's not
<infinity> Oh.  Then I'm not seeing the bug in the first place. :)
<seb128> weird
<mvo> seb128: this is the part that I find confusing, I can't quite explain how it fixes it :/
<mvo> seb128: maybe we need to make the code smarter to actually look at the timestamps
<mvo> seb128: inside the file
<seb128> mvo, what do you mean how it fixes it?
<seb128> you say that the log rotation shouldn't update the ctime?
<mvo> seb128: I'm just surprised that ctime is updated but mtime remains, but maybe I'm just missing something, would you mind adding the stat output of a file in question
<mvo> seb128: actually I think I get it now
<mvo> seb128: sorry, long day and all that
<seb128> I don't have one atm, I installed things today
<seb128> no worry
<seb128> I might be overlooking something
<seb128> but I had a machine where I didn't touch packages for > 1 week
<seb128> and the log had been rotated
<seb128> the .1.gz ctime was the rotation date
<seb128> the mtime was the last dpkg use
<seb128> the .log was empty
<seb128> which the code already had a case for/ignores
<mvo> seb128: yeah, logrotate will keep the mtime when it rotates but ctime will be updated, so I think it all makes sense
<seb128> :-)
<mvo> seb128: sorry, a bit dense, I will followup in the LP
<seb128> mvo, thanks
<mvo> seb128: thank you
<seb128> mvo, golang-gopkg-macaroon.v1  looks good, NEWed
<mvo> seb128: ha!
 * mvo hugs seb128
 * seb128 hugs mvo back ;-)
<ogra_> get a room !
<ogra_> :)
<ChrisTownsend> Hello, I have an autopackage test that claims its running, but it is not: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html
<ChrisTownsend> Could somebody please kick that so I can get this completed?
<ChrisTownsend> infinity: slangasek: Are either of you around to help me out?^^^^
<tvoss> slangasek, ping
<slangasek> tvoss: hi - are you pinging about https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html or about something else?
<slangasek> ChrisTownsend: ^^ looking now ;)
<tvoss> slangasek, something else, see pm
<ChrisTownsend> slangasek: Thanks
<slangasek> ok
<slangasek> ChrisTownsend: http://autopkgtest.ubuntu.com/running.shtml
<slangasek> pitti: btw, should silo-triggered autopkgtest results be indexed under e.g. http://autopkgtest.ubuntu.com/packages/c/content-hub/xenial/amd64/ for https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html ?
<ChrisTownsend> slangasek: Thanks again!
<ChrisTownsend> slangasek: Ugh, looks like the content-hub job is hung, maybe waiting on a reboot????
<ChrisTownsend> slangasek: Not sure if you did anything, but it looks like it's running again.
<slangasek> ChrisTownsend: I only poked it the once :)  did it complete successfully now?
#ubuntu-release 2016-06-08
<slangasek> sigh, why is all of suitesparse in main
 * slangasek slowly unpicks the migration knot
<mwhudson> slangasek: thanks (or at least i assume that was you :-p)
<slangasek> mwhudson: you're welcome ;)
<elopio> slangasek: any idea why am I not getting snapcraft after adding proposed from the main archive to the sources?
<elopio> http://paste.ubuntu.com/17106219/
<elopio> arges: are you around?
<jbicha> elopio: snapcraft is in the new queue because snapcraft-parser is a new binary
<jbicha> https://launchpad.net/ubuntu/xenial/+queue
<elopio> jbicha: damn. How can we move it forward?
<jbicha> any new package has to be manually approved by one of https://launchpad.net/~ubuntu-archive
<elopio> wgrant: hello :)
<elopio> thanks for the info jbicha. I had no idea about that.
<cjwatson> elopio: accepted
<elopio> cjwatson: \o/ thank you!
<mwhudson> where did queuebot go?
<teward> it went to bed for the evening?  :P
<elopio> is there anything else needed to get snapcraft into proposed? or just wait for the servers to sync?
<cjwatson> elopio: just wait a bit
<cjwatson> but anyway, I really really must stop optimising postgresql queries and GO TO BED
<elopio> cjwatson: good night!
<ChrisTownsend> slangasek: No, https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html still never completed.  I saw in the log on http://autopkgtest.ubuntu.com/running.shtml while it was running that it looked like it set up some sort of lxd(?), then it rebooted, then saw a bunch of lines that said something like "ssh: Cannot make secure connection.  Retry in 3 seconds..." and it seems to have timed out and failed.
<sergiusens> infinity or bdmurray I was directed to you. I uploaded a package to SRU into xenial. Everything has been verified except for one small bug I'd rather have fixed before releasing. My question is about debian/changelog, -proposed has 2.10 with its changelog, should I upload 2.10.1 with a changelog entry of the fix only or should I replicate 2.10's changelog into 2.10.1. I am asking to know what to do that the infra would handle
<ogra_> if you do that you most likely want to use -v2.10 when building the sroucne package so both changelog entires show up in the upload
<cjwatson> You shouldn't replicate the changelog entry.  It used to be that you needed to do what ogra_ says (except he meant -v2.9 I think), but that should no longer be necessary.
<cjwatson> I think you'll be fine with just a changelog entry describing the thing you're fixing in 2.10.1.
<sergiusens> ogra_ yeah, 2.10.1 would go on top of 2.10 ... but last time I did that, the infra only marked the latest changelog for verification
<ogra_> yeah, sorrym living in the past here :)
<cjwatson> But if you want to be extra-safe, build with -v2.9.
<sergiusens> cjwatson great I'll go with extra safe. Thanks
<cjwatson> sergiusens: FWIW I believe I fixed the infrastructure to traverse all -proposed versions since the most recent in release/-updates in January 2013
<cjwatson> Well I say infrastructure, it's not very infra, it's the web report generator, but anyway
<sergiusens> cjwatson I will need to look into this issue I ran into then and report back :-)
<cjwatson> It may depend on whether you think it's appropriate for all the bugs fixed in 2.10 to be marked for reverification even if they were already verified.
<cjwatson> If the answer is yes, use -v2.9; if the answer is no, don't.
<slashd> morning arges, LP: 1484740  affects "Trusty ", can you please nominate it for Trusty ?
<ubot5> Launchpad bug 1484740 in trousers (Ubuntu) "14.04 trousers version 0.3.11.2-1 fails to start with TPM device" [Medium,Confirmed] https://launchpad.net/bugs/1484740
<arges> slashd: done
<slashd> arges, tks
<slangasek> ChrisTownsend: fwiw whatever problem landing-051 had with autopkgtesting, I see results on that excuses page now
<ChrisTownsend> slangasek: Yeah, thanks, pitti helped me out.
<slangasek> ChrisTownsend: ah - what was the problem?
<ChrisTownsend> slangasek: I'm not really sure, but it was supposedly related to the PS outae yesterday.
<ginggs> slangasek: hi, the test case for LP: #1556685 is in the SRU bug LP: #1556680
<ubot5> Launchpad bug 1556685 in oce (Ubuntu Xenial) "Wrong installation path (0.16 instead of 0.17)" [Undecided,Incomplete] https://launchpad.net/bugs/1556685
<ubot5> Launchpad bug 1556680 in oce (Ubuntu Xenial) "[SRU] Wrong library path in CMake file for 64bit system" [Undecided,Fix committed] https://launchpad.net/bugs/1556680
<slangasek> ginggs: ok; did you see the previous message from pitti on bug #1556685?  it had been marked incomplete 8 days ago and was awaiting feedback
<ubot5> bug 1556685 in oce (Ubuntu Xenial) "Wrong installation path (0.16 instead of 0.17)" [Undecided,Incomplete] https://launchpad.net/bugs/1556685
<slangasek> ginggs: if you could please put a relevant test case in each bug linked from the SRU changelog, that would let the process run more smoothly
<ginggs> slangasek: no sorry, i only saw it now, i didn't get subscribed to that bug
<ginggs> the bug where pitti commented
<slangasek> ginggs: thus, rejecting the SRU has the right effect of triggering action ;)
<ginggs> slangasek: :)
<slangasek> meanwhile, let's deal with the octave g++5 abi transition, which was done in Debian last September but never merged into Ubuntu until yakkety opened, hnnngh
<ginggs> slangasek: i saw you promoted metis, thanks, so now suitesparse (which is mixed up with octave) is good to go
<ginggs> i'm still having trouble decyphering http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<ginggs> to me it looks like fsl might be one of the problems
<ginggs> and in its buid log it looks like two different versions of suitesparse were used
<ginggs> i'm not sure why fsl doesn't appear in the transition tracker though
<slangasek> hmm I haven't checked transition trackers for it frankly
<sergiusens> arges mind looking at https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=snapcraft really small one related to the conversation from earler
<sergiusens> much appreciated
<sergiusens> slangasek if you are still around, mind looking at ^
<slangasek> sergiusens: looking
<slangasek> sergiusens: please note that listing all of these bug references in your changelog for an SRU is going to slow you down; you're not using the exception process when you list individual bugfixes like this
<slangasek> SRUs don't move until all of the referenced bugs are marked verification-done
<sergiusens> slangasek I really don't mind the creating a bug for each item and I am certain elopio prefers this mechanism as well to make sure we never regress. The slow part for me is getting out of the unapproved queue :-)
<slangasek> sergiusens: interestingly, I see that all the bugs referenced in 2.10 just flipped to verification-done... even though there's a regression that you're fixing with 2.10.1
<sergiusens> slangasek yes, elopio decided to create a new bug which is the one mentioned in 2.10.1 I added the original bug that caused the bug to exist as a coment https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1590256
<ubot5> Launchpad bug 1590256 in snapcraft (Ubuntu Yakkety) "snapcraft clean -s strip doesn't show the deprecation message" [Undecided,New]
<sergiusens> slangasek I could mark it as a dup if it satisfies SRU requirements
<slangasek> sergiusens: well, to avoid accidental publication of SRUs that are verification-done, please make sure that one of the bugs for the SRU that you *don't* want published gets marked verification-failed instead :)
<sergiusens> slangasek done
<slangasek> ok
<slangasek> once 2.10.1 shows up on http://people.canonical.com/~ubuntu-archive/pending-sru.html you can safely reset it
<sergiusens> slangasek btw, should snapcraft be MIRed, I was under the impression it shouldn't but oversaw a question of the type "has it been done yet"
<slangasek> sergiusens: things that we care about supporting ought to go into main, which means going through the MIR process
<sergiusens> slangasek thanks I'll ask ogra_ for help on that as he's been doing a lot of those lately ;-)
<elopio> slangasek: sergiusens: verification done for that bug. Should I mark as verification-done also the one that failed?
<elopio> oh, Sergio already did that.
<sergiusens> yup
<sergiusens> now we wait I guess :-)
<slangasek> elopio, sergiusens: if you're happy with snapcraft 2.10.1 (which is suggested by all the bugs being v-done), I can release it now
<elopio> slangasek: yes, please.
<slangasek> elopio: done
<sergiusens> ty
#ubuntu-release 2016-06-09
<bzoltan> hello folks, would somebody plese restart these flaky unity8 tests -> https://requests.ci-train.ubuntu.com/static/britney/ticket-1511/yakkety/excuses.htmlhttps://requests.ci-train.ubuntu.com/static/britney/ticket-1511/vivid/excuses.html
<arges> sergiusens: ok checking in, sounds like you got it taken care of?
<sergiusens> arges yes, thank you for checking!
<flexiondotorg> cjwatson, Are these package removals from the archive something you can assist with?
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/mate-netspeed/+bug/1584769
<ubot5> Launchpad bug 1584769 in mate-netspeed (Ubuntu) "Please remove mate-netspeed from the Yakkety archive, it is now included in mate-applets" [Undecided,New]
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/gnome-main-menu/+bug/1584767
<ubot5> Launchpad bug 1584767 in gnome-main-menu (Ubuntu) "Please remove gnome-main-menu from the Yakkety archive, it is obsolete" [Undecided,New]
<cjwatson> flexiondotorg: neck-deep in postgresql right now, sorry
<flexiondotorg> OK
#ubuntu-release 2016-06-10
<ginggs> pitti, slangasek: i've expanded the info in LP: #1556685 and uploaded the oce SRU again
<ubot5> Launchpad bug 1556685 in oce (Ubuntu Xenial) "[SRU] Wrong installation path (0.16 instead of 0.17)" [Undecided,Incomplete] https://launchpad.net/bugs/1556685
<sergiusens> bdmurray or slangasek care to approve snapcraft into xenial-proposed?
<bdmurray> sergiusens: I'll take a look
<sergiusens> ty
<mardy> hi all, can please someone help me with this: http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#account-plugins
<mardy> the ubuntu-system-settings-online-accounts is already in yakkety
<mardy> so I don't understand what the account-plugins package is waiting for
<nacc> mardy: component mismatch
<nacc> mardy: account-plugins is in main
<nacc> mardy: ubuntu-system-settings-online-accounts is in universe
<nacc> (and account-plugin-owncloud is in main too)
<mardy> nacc: OK... so, if I wanted to move account-plugin-owncloud to universe, how should I do that? is it a matter of changing debian/control?
<nacc> mardy: i think that's indicated here: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed for account-plugin-owncloud
<nacc> mardy: no, someone (an AA? not sure where this permission starts to be granted) has to demote it
<nacc> it's on the list already, afaict
<mardy> nacc: OK. Would you suggest someone to ping, just to be sure?
<cjwatson> AA, yes.  I'll do it
<nacc> cjwatson: thanks! (and noted who has those rights)
<mardy> cjwatson: thanks!
<bdmurray> sergiusens: Why is 2.11+16.10 still in proposed?
<cjwatson> (done)
<bdmurray> sergiusens: it looks like an amd64 test regression - http://autopkgtest.ubuntu.com/packages/s/snapcraft/yakkety/amd64
<sergiusens> bdmurray oh, snapd in -proposed might be hitting us there (which also fails)
<sergiusens> elopio care to look at that? ^
<bdmurray> sergiusens: I don't think its snapd related Get:24 http://ftpmaster.internal/ubuntu yakkety/main amd64 snapd amd64 2.0.2 [4,011 kB]
<bdmurray> sergiusens: from https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/s/snapcraft/20160610_090430@/log.gz
<sergiusens> bdmurray heh snapd on xenial-updates is already 2.0.5...
<bdmurray> sergiusens: my concern is that if the yakkety autopkgtests are failing, they'll likely fail for xenial too
<sergiusens> bdmurray the error is from snapd, not much we can do but disable the tests
<sergiusens> bdmurray they won't
<bdmurray> okay
<sergiusens> bdmurray all our code changes run adt for xenial https://github.com/ubuntu-core/snapcraft/pull/559
<sergiusens> bdmurray you will need vpn to see the results, but we do run
<bdmurray> sergiusens: okay, I'll approve it
<bdmurray> sergiusens: oh and fwiw snapcraft.io/create never loads for me
<didrocks> bdmurray: normal, it will be on on tuesday
<didrocks> the goal is to have the tour available by then
<elopio> bdmurray: thanks.
<elopio> and yes, we won't release this until next week. We just want to be ready for when the site is ready.
<elopio> I'm trying to reproduce the snapd error in yakkety, to report a bug.
<elopio> also we are waiting on yakkety images for our CI lab. Soon we will catch these type of errors earlier.
<elopio> bdmurray: do the autopkgtests get executed when the package is moved to proposed? Or they are only run when trying to migrate from proposed to updates?
<apw> they are run when the package is fully in -proposed, the results then contribute to the decision to release to -updates
<nacc> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html helps :)
<elopio> nacc: that page doesn't show the results in xenial-proposed. Just yakkety.
<Laney> that's http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html
<nacc> elopio: ah sorry, you're right
<elopio> Laney: great. It's not there, but I supposed that's because it needs some time.
<jbicha> could an AA take a look at bug 1585058?
<ubot5> bug 1585058 in pixfrogger (Ubuntu) "Sync pixfrogger 1.0-4 (universe) from Debian unstable (main)" [Wishlist,Fix committed] https://launchpad.net/bugs/1585058
<cjwatson> I think that just needs a member of the release team to force it despite the arch: all uninstallability
<cjwatson> XS-Build-Indep-Architecture is working, but it doesn't affect proposed-migration's behaviour of checking arch: all installability on amd64
<infinity> cjwatson: Hrm.  Since uninst counts are counted against only amd64 for arch:all (I think?), I wonder if teaching britney to check B-I-A and jigger the check for that source's binaries might be smart, to keep the count 0.
<cjwatson> infinity: Wouldn't be a bad idea if it's reasonably easy.
<sergiusens> bdmurray just in case http://autopkgtest.ubuntu.com/packages/s/snapcraft/xenial/amd64/ :-)
<bdmurray> sergiusens: I saw, thanks!
<stokachu> infinity: get my email about getting the 'conjure 0.0.8' purged from the archive?
<nacc> do i need to wait for php7.0-dev to make into release (to remove the last dep), or can I request an AA demote dh-php now, if it's showing up in (source & binary movements to universe) on http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed ?
<cjwatson> stokachu: Not that I saw the email, but we don't remove packages from the release pocket of stable suites (except that time when we had to due to a legal threat, but we don't talk about that).
<stokachu> cjwatson: ok this was a request because of the name change that happened between conjure and conjure-up
<stokachu> cjwatson: afraid users will be confused
<cjwatson> stokachu: The most effective way to stop xenial users seeing it would be to change conjure-up in xenial-updates to ship a transitional package.
<cjwatson> stokachu: That will be like 100x less effort.
<stokachu> ah ok
<stokachu> ill do that
<nacc> well, now that php7.0-dev has moved to release, can an AA demote dh-php to universe?
#ubuntu-release 2016-06-11
<infinity> nacc: Huh.  dh-php didn't survive long.  Is there a new hotness now?
<infinity> nacc: Or is it just that we don't ship any extensions in main?
<infinity> nacc: (demoted, though)
<nacc> infinity: yeah :) ... not necessarily anything new, but it's only a build-time dependency for most packages
<nacc> infinity: thanks! that will help clear up some stuff in proposed
<nacc> infinity: i'll try and check back after dinner, i ran those steps locally and the final result was what I expected (and all three passed tests at the end)
<nacc> infinity: will that automatically get picked up by update_excuses? dh-php is currently stuck as an unsatisfiable dep (xml2) due to the old component mismatch. Or does someone need to poke it?
<infinity> nacc: It'll sort itself out.
<nacc> infinity: ok, great, thanks!
<slangasek> lputils.PackageMissing: Could not find binaries for 'libuhnspell-1.3-0/None' in yakkety
<slangasek> oh the irony
<LocutusOfBorg> please RM pepperflashplugin-nonfree on i386 thanks (following the upstream and debian removal)
<LocutusOfBorg> also vmtk on powerpc
<jbicha> could the status on https://launchpad.net/ubuntu/vivid be set from "supported" to "obsolete"
<cjwatson> jbicha: uh it's complicated
<cjwatson> jbicha: (short answer: sorry, no, not yet, basically due to phones and snappy 15.04, but hopefully in the not too distant future)
<jbicha> ok, I spoke up in case it was just an oversight
<cjwatson> not an oversight, it's definitely annoying that we can't right now
#ubuntu-release 2016-06-12
<LocutusOfBorg> infinity, permission to merge sbuild?
<LocutusOfBorg> in any case, LP: #1591674
<ubot5> Launchpad bug 1591674 in sbuild (Ubuntu) "please merge sbuild from Debian" [Undecided,New] https://launchpad.net/bugs/1591674
<LocutusOfBorg> I don't want cjwatson to shoot at me for breaking stuff :)
<bzoltan> if somebody with upload rights is around, would you please kick that failing test to start again - https://requests.ci-train.ubuntu.com/static/britney/ticket-1511/vivid/excuses.html
#ubuntu-release 2017-06-05
-queuebot:#ubuntu-release- New binary: evolution-data-server [ppc64el] (artful-proposed/main) [3.24.2-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: evolution-data-server [s390x] (artful-proposed/main) [3.24.2-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: evolution-data-server [i386] (artful-proposed/main) [3.24.2-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: evolution-data-server [amd64] (artful-proposed/main) [3.24.2-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: evolution-data-server [arm64] (artful-proposed/main) [3.24.2-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: evolution-data-server [armhf] (artful-proposed/main) [3.24.2-0ubuntu1] (ubuntu-desktop)
<LocutusOfBorg> hello, does anybody feels about helping me and perl migrate? we are 2 tests away from migration
<LocutusOfBorg> libffi-platypus-perl and libdomain-publicsuffix-perl
 * LocutusOfBorg grabs some coffee
<santa_> good morning everyone
<santa_> apw: hi, iirc you were processing some new kubuntu's packages. we have about 10 still there, blocking part of the -proposed migration http://gpul.grupos.udc.es/ka-iron-hand_reports/applications_archive/16.12.3_artful_proposed_migration.pdf
<santa_> note also that that's 16.12.3, kde applications 17.04.1 were already released, and at some point we would like to upload them
<apw> santa_, indeed i was ... i'll try and get some time to wack a few today
<santa_> 17.04 would come with a few new sources too, but not so many
<santa_> (and a myriad of binary-new packages, but that souldn't be difficult from a release manager point of view)
<santa_> apw: thanks
<santa_> apw: also an override for the akonadi autopkgtest would be nice, because we will get a new upstream release which I don't know how it's going to fail wrt autopkgtests
<santa_> akonadi's autopkgtest failures were so far hard to reproduce for me, and usually they fail in a different way locally vs the official infra
<santa_> so if anything, I would like to work on that with 17.04 or higher, since we might need help from fellow kde devels to figure them out, and that's easier to do with a recent version
<alan_g> apw: I understand you were asking about the Mir changelogs. Isn't "+      . Mir needs to be updated to 0.26 in 16.04LTS (LP: #1685186)" what you want?
<ubot5> Launchpad bug 1685186 in mir (Ubuntu Zesty) "[SRU] Mir needs to be updated to 0.26 in 16.04LTS" [High,In progress] https://launchpad.net/bugs/1685186
<LocutusOfBorg> good morning infinity, I see some actions from your side on frama-c, but I fail to understand why the new version has been deleted from the archive...
<LocutusOfBorg>  Deleted on 2017-06-02 by Ubuntu Archive Robot
<LocutusOfBorg> moved to release
<LocutusOfBorg> but it is not in release
 * LocutusOfBorg would like to try a sync again
<LocutusOfBorg> frama-c 20161101+silicon+dfsg-5 in stretch (same version already has published binaries in the destination archive)
<LocutusOfBorg> maybe apw has some more knowledge than me :)
<apw> i don't think syncing it again will work, if the version number is the same
<LocutusOfBorg> yes, I can upload a build1 (already here, just waiting for an ack)
<LocutusOfBorg> but I don't want to do something bad, even if the removal seems "wrong" to me
<LocutusOfBorg> I mean, the log seems good, moved to proposed, and then back to release, but the version moved to release was the old one
 * LocutusOfBorg uploads
<apw> we did used to lose things when we have overlapping override changes with promotion ...it might have been the victim of something like that
<LocutusOfBorg> oh, race condition, that was somewhat in my mind, maybe it was already migrating and hammer from AA happened
 * LocutusOfBorg will fix and forget then
<apw> as you say it seems to have been removed for copying to -release and yet it is not in that pocket
<cjwatson> more likely to be https://bugs.launchpad.net/launchpad/+bug/1685672 than a race
<ubot5> Ubuntu bug 1685672 in Launchpad itself "Copies with binaries between artful pockets fail if package was built in older release" [Undecided,New]
<apw> cjwatson, oh yeah it definatly would have been built in zesty
<LocutusOfBorg> I added a comment to that bug, thanks
-queuebot:#ubuntu-release- New binary: python-scrypt [ppc64el] (artful-proposed/universe) [0.8.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-scrypt [i386] (artful-proposed/universe) [0.8.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-scrypt [arm64] (artful-proposed/universe) [0.8.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-scrypt [amd64] (artful-proposed/universe) [0.8.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-scrypt [armhf] (artful-proposed/universe) [0.8.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-scrypt [s390x] (artful-proposed/universe) [0.8.0-0ubuntu1] (no packageset)
<LocutusOfBorg> how can I subscribe ubuntu-foundations to a bug?
<LocutusOfBorg> bdmurray, maybe? subscribing rhash to foundations bugs will "fix" the MIR process
<LocutusOfBorg> LP: #1688298 (and make cmake migrate)
<ubot5> Launchpad bug 1688298 in rhash (Ubuntu) "[MIR] rhash" [Undecided,New] https://launchpad.net/bugs/1688298
-queuebot:#ubuntu-release- New binary: evolution-data-server [s390x] (artful-proposed/main) [3.24.2-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: evolution-data-server [ppc64el] (artful-proposed/main) [3.24.2-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: evolution-data-server [amd64] (artful-proposed/main) [3.24.2-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: evolution-data-server [i386] (artful-proposed/main) [3.24.2-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: evolution-data-server [arm64] (artful-proposed/main) [3.24.2-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: evolution-data-server [armhf] (artful-proposed/main) [3.24.2-0ubuntu2] (ubuntu-desktop)
<slashd> For SRU, Good Monday, I know most of you are sprinting this week but I was wondering if you guys think you'll have time to approve this Xenial upload made by stgraber for lxd : https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=lxd -- (LP: #1693340) ?
<ubot5> Launchpad bug 1693340 in lxd (Ubuntu Xenial) "SRU of LXD 2.0.10 (upstream bugfix release)" [Undecided,In progress] https://launchpad.net/bugs/1693340
-queuebot:#ubuntu-release- New source: python-zunclient (artful-proposed/primary) [0.2.0-0ubuntu1]
<jamespage> if there is an archive-admin around, it would be really helpful to get vine promoted into main for artful - the MIR is +1'ed, just pending the promotion now
<LocutusOfBorg> jamespage, do you mean that you want all that stuff migrate today? :)
<jamespage> LocutusOfBorg: I'd like to get it clear prior to starting on the next milestones for OpenStack this week :-)
<jamespage> plus proposed migration nagmail is getting annoying
<tjaalton> anyone around to review fwupdate on xenial queue?
-queuebot:#ubuntu-release- Unapproved: sssd (trusty-proposed/main) [1.11.8-0ubuntu0.6 => 1.11.8-0ubuntu0.7] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: vlan (trusty-proposed/main) [1.9-3ubuntu10.3 => 1.9-3ubuntu10.4] (core)
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (trusty-proposed) [1.11.8-0ubuntu0.7]
-queuebot:#ubuntu-release- Unapproved: python-fastimport (zesty-proposed/universe) [0.9.6-2 => 0.9.6-2ubuntu17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected fwupdate [source] (xenial-proposed) [9-1ubuntu0.16.04.1]
#ubuntu-release 2017-06-06
-queuebot:#ubuntu-release- Unapproved: libgweather (zesty-proposed/main) [3.24.0-0ubuntu2 => 3.24.1-0ubuntu0.1] (kubuntu, ubuntu-desktop)
<LocutusOfBorg> hello tjaalton, I fixed some more issues in libepoxy in my artful merge, and I think the SRU should include them too, how do you feel about rejecting your patch in xenial unapproved queue and grab mine? https://bugs.launchpad.net/ubuntu/+source/libepoxy/+bug/1647600/comments/5
<ubot5> Ubuntu bug 1647600 in libepoxy (Ubuntu Xenial) "Xvfb fails with new mesa, results in ubiquity FTBFS" [Undecided,In progress]
<LocutusOfBorg> I can upload, of course
<LocutusOfBorg> the patch I add, is already part and merged upstream in the new release
-queuebot:#ubuntu-release- Unapproved: mir (xenial-proposed/main) [0.26.3+16.04.20170510-0ubuntu1 => 0.26.3+16.04.20170605-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: mir (yakkety-proposed/main) [0.24.0+16.10.20160815.3-0ubuntu2 => 0.26.3+16.10.20170605-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: mir (zesty-proposed/main) [0.26.2+17.04.20170322.1-0ubuntu2 => 0.26.3+17.04.20170605-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: libepoxy (xenial-proposed/main) [1.3.1-1 => 1.3.1-1ubuntu1.16.04.1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: libepoxy (zesty-proposed/main) [1.3.1-1ubuntu1 => 1.3.1-1ubuntu1.17.04.1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: libepoxy (yakkety-proposed/main) [1.3.1-1 => 1.3.1-1ubuntu1.16.10.1] (desktop-core)
<LocutusOfBorg> tjaalton, ^^^
<LocutusOfBorg> I did the upload
<tjaalton> LocutusOfBorg: that"s fine
<LocutusOfBorg> thanks
<jamespage> bdmurray: hello! please could we get cinder released into -updates for yakkety now that verification is complete for bug 1677982
<ubot5> bug 1677982 in cinder (Ubuntu Yakkety) "Request for including an upstream fix for emc vnx volume driver (Newton)" [Undecided,Fix committed] https://launchpad.net/bugs/1677982
<jamespage> which will complete bug 1688557 as well
<ubot5> bug 1688557 in cinder (Ubuntu Yakkety) "[SRU] newton stable releases" [Undecided,Fix committed] https://launchpad.net/bugs/1688557
<LocutusOfBorg> Laney, can you please help me making perl migrate? the failing test has been ignored I guess already a couple of times (in zesty), and I don't really know how to fix (I can reproduce it easily even under gdb)
<LocutusOfBorg> unblocking perl would be awesome because of imagemagic and perl CVEs
<bdmurray> jamespage: looking
<jamespage> bdmurray: ta - the patch got overtaken by the actual point release for cinder; normally we'd drop the reference to the specific bug in this scenario but for misc reasons that got missed
<bdmurray> jamespage: there's a yakkety task on bug 1677982 but they say verified on 16.04 in the comments.
<ubot5> bug 1677982 in cinder (Ubuntu Yakkety) "Request for including an upstream fix for emc vnx volume driver (Newton)" [Undecided,Fix committed] https://launchpad.net/bugs/1677982
<jamespage> bdmurray: looking
<jamespage> bdmurray: and they verified with a newer version - so I suspect its not actually the package from either the UCA or yakkety
 * jamespage sighs
<jamespage> apologies I should have noted that
<bdmurray> No problem, should I comment on the bug or will you sort it out?
<jamespage> bdmurray: I can - but I'd really to not like to hold up the main point release on this bug, bearing in mind the fix should be there anyway
<bdmurray> jamespage: I'm not sure I understand what you want to have happen then.
<jamespage> bdmurray: I'd like to push the cinder update through without specific verification of bug 1677982
<ubot5> bug 1677982 in cinder (Ubuntu Yakkety) "Request for including an upstream fix for emc vnx volume driver (Newton)" [Undecided,Fix committed] https://launchpad.net/bugs/1677982
<jamespage> bdmurray: bearing in mind its been through functional testing as part of bug 1688557
<ubot5> bug 1688557 in cinder (Ubuntu Yakkety) "[SRU] newton stable releases" [Undecided,Fix committed] https://launchpad.net/bugs/1688557
<bdmurray> jamespage: Sorry at a sprint - will have a look at the bug again.
<jamespage> bdmurray: thanks
-queuebot:#ubuntu-release- Unapproved: rejected grub2-signed [source] (trusty-proposed) [1.34.16]
-queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (trusty-proposed) [2.02~beta2-9ubuntu1.14]
<bdmurray> jamespage: There isn't any regression potential in that bug so its hard to evaluate.
<jamespage> bdmurray: ok so for context; the fix was included in cinder 9.1.4 covered under bug 1688557; we're not holding anything in the packaging over and above what upstream released as 9.1.4 for this fix; if I could roll things back, we'd not even have referenced this bug specifically in the changelog
<ubot5> bug 1688557 in cinder (Ubuntu Yakkety) "[SRU] newton stable releases" [Undecided,Fix committed] https://launchpad.net/bugs/1688557
<jamespage> I believe the regression potential is low
<xnox> Laney, i'm failing to detect why src:doxygen is in main.
<xnox> it does not appear to be seeded, nor have any binary reverse-depends.
<xnox> am I missing something, or is our germinate stalled.
<xnox> ok found it.
<xnox> doxygen <- built-using <- libevdev-dev <- qtsystems5-dev and then it's the ubuntu ui toolkit stack.
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-4.0 [source] (xenial-proposed) [1:4.0-1ubuntu1~16.04.1]
<infinity> tjaalton: Tell me why I shouldn't case that this vulkan/xenial upload regresses Mir support.
<infinity> tjaalton: s/case/care/
<valorie> just sent an email to y'all about KDE PIM packages
<valorie> friendly hello from this newbie Kubuntu release manager
<valorie> I assisted wxl last cycle
-queuebot:#ubuntu-release- Unapproved: accepted wayland [source] (xenial-proposed) [1.12.0-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New binary: wayland [amd64] (xenial-proposed/main) [1.12.0-1~ubuntu16.04.1] (desktop-core, ubuntu-server, xorg)
-queuebot:#ubuntu-release- New binary: wayland [ppc64el] (xenial-proposed/main) [1.12.0-1~ubuntu16.04.1] (desktop-core, ubuntu-server, xorg)
-queuebot:#ubuntu-release- New binary: wayland [i386] (xenial-proposed/main) [1.12.0-1~ubuntu16.04.1] (desktop-core, ubuntu-server, xorg)
-queuebot:#ubuntu-release- New binary: wayland [s390x] (xenial-proposed/main) [1.12.0-1~ubuntu16.04.1] (desktop-core, ubuntu-server, xorg)
<slangasek> sergiusens: how is click 0.4.46+17.10.20170602-0ubuntu1 in artful-proposed and https://bileto.ubuntu.com/#/ticket/2790 claims it needs rebuilt for new commits?
-queuebot:#ubuntu-release- New binary: wayland [arm64] (xenial-proposed/main) [1.12.0-1~ubuntu16.04.1] (desktop-core, ubuntu-server, xorg)
-queuebot:#ubuntu-release- New binary: wayland [powerpc] (xenial-proposed/main) [1.12.0-1~ubuntu16.04.1] (desktop-core, ubuntu-server, xorg)
-queuebot:#ubuntu-release- New binary: wayland [armhf] (xenial-proposed/main) [1.12.0-1~ubuntu16.04.1] (desktop-core, ubuntu-server, xorg)
<sil2100> cd ..
<tsimonq2> ls
<sil2100> Darn ;0
<sil2100> ;)
<tsimonq2> sudo rm -rf /home/sil2100
<tsimonq2> :P XD
<valorie> tsimonq2: you have a mean streak!
<tsimonq2> valorie: lol
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (zesty-proposed) [2.02~beta3-4ubuntu2.1]
-queuebot:#ubuntu-release- New binary: llvm-toolchain-4.0 [s390x] (xenial-proposed/main) [1:4.0-1ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: grub2 (zesty-proposed/main) [2.02~beta3-4ubuntu2.1 => 2.02~beta3-4ubuntu2.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (yakkety-proposed) [2.02~beta2-36ubuntu11.3]
-queuebot:#ubuntu-release- New binary: llvm-toolchain-4.0 [ppc64el] (xenial-proposed/main) [1:4.0-1ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: grub2 (yakkety-proposed/main) [2.02~beta2-36ubuntu11.3 => 2.02~beta2-36ubuntu11.3] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (zesty-proposed/main) [2.02~beta3-4ubuntu2.1 => 2.02~beta3-4ubuntu2.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (zesty-proposed) [1.80.1]
-queuebot:#ubuntu-release- New binary: haskell-assert-failure [ppc64el] (artful-proposed/universe) [0.1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-minimorph [ppc64el] (artful-proposed/universe) [0.1.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-enummapset-th [ppc64el] (artful-proposed/universe) [0.6.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-assert-failure [amd64] (artful-proposed/universe) [0.1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hsini [ppc64el] (artful-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-assert-failure [s390x] (artful-proposed/universe) [0.1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-minimorph [s390x] (artful-proposed/universe) [0.1.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-assert-failure [i386] (artful-proposed/universe) [0.1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hsini [s390x] (artful-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-enummapset-th [amd64] (artful-proposed/universe) [0.6.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hsini [i386] (artful-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-enummapset-th [s390x] (artful-proposed/universe) [0.6.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hsini [amd64] (artful-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-minimorph [i386] (artful-proposed/universe) [0.1.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-assert-failure [arm64] (artful-proposed/universe) [0.1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-assert-failure [armhf] (artful-proposed/universe) [0.1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-enummapset-th [i386] (artful-proposed/universe) [0.6.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-minimorph [amd64] (artful-proposed/universe) [0.1.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-minimorph [arm64] (artful-proposed/universe) [0.1.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-minimorph [armhf] (artful-proposed/universe) [0.1.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-enummapset-th [armhf] (artful-proposed/universe) [0.6.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hsini [arm64] (artful-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-enummapset-th [arm64] (artful-proposed/universe) [0.6.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-4.0 [powerpc] (xenial-proposed/main) [1:4.0-1ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hsini [armhf] (artful-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (yakkety-proposed) [1.74.3]
-queuebot:#ubuntu-release- Unapproved: grub2 (yakkety-proposed/main) [2.02~beta2-36ubuntu11.3 => 2.02~beta2-36ubuntu11.3] (core)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-4.0 [amd64] (xenial-proposed/main) [1:4.0-1ubuntu1~16.04.1] (no packageset)
#ubuntu-release 2017-06-07
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (zesty-proposed) [2.02~beta3-4ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (zesty-proposed) [2.02~beta3-4ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (yakkety-proposed) [2.02~beta2-36ubuntu11.3]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (yakkety-proposed) [2.02~beta2-36ubuntu11.3]
-queuebot:#ubuntu-release- Unapproved: nplan (xenial-proposed/universe) [0.21~16.04.1 => 0.23~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected nplan [source] (xenial-proposed) [0.23~16.04.1]
-queuebot:#ubuntu-release- Unapproved: nplan (yakkety-proposed/main) [0.12 => 0.23~16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nplan (zesty-proposed/main) [0.20 => 0.23~17.04.1] (core)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-4.0 [i386] (xenial-proposed/main) [1:4.0-1ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-4.0 [arm64] (xenial-proposed/main) [1:4.0-1ubuntu1~16.04.1] (no packageset)
<tjaalton> infinity: now that mir is being backported, yes. i'll do another upload then
<tjaalton> mesa too
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.12 => 2.408.13] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (yakkety-proposed/main) [2.435.3 => 2.435.4] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (trusty-proposed) [2.208.14]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (trusty-proposed/main) [2.208.13 => 2.208.14] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: rejected vulkan [source] (xenial-proposed) [1.0.42.0+dfsg1-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: vulkan (xenial-proposed/universe) [1.0.21.0+dfsg1-1~16.04.1 => 1.0.42.0+dfsg1-1ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected libepoxy [source] (xenial-proposed) [1.3.1-1ubuntu0.16.04.1]
<tjaalton> infinity: uploaded a new vulkan backport that keeps Mir support
-queuebot:#ubuntu-release- New binary: llvm-toolchain-4.0 [armhf] (xenial-proposed/main) [1:4.0-1ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected libepoxy [source] (xenial-proposed) [1.3.1-1ubuntu1.16.04.1]
-queuebot:#ubuntu-release- Unapproved: libepoxy (xenial-proposed/main) [1.3.1-1 => 1.3.1-1ubuntu0.16.04.1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (zesty-proposed/main) [2.441.3 => 2.441.4] (desktop-core)
<infinity> tjaalton: Ta.
<tjaalton> mir needs to be acked first though :)
-queuebot:#ubuntu-release- Unapproved: accepted libepoxy [source] (xenial-proposed) [1.3.1-1ubuntu0.16.04.1]
<didrocks> good morning
-queuebot:#ubuntu-release- Unapproved: accepted mir [sync] (yakkety-proposed) [0.26.3+16.10.20170531-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected mir [sync] (zesty-proposed) [0.26.3+17.04.20170531-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mir [sync] (xenial-proposed) [0.26.3+16.04.20170605-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mir [sync] (yakkety-proposed) [0.26.3+16.10.20170605-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mir [sync] (zesty-proposed) [0.26.3+17.04.20170605-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (zesty-proposed) [2.26.4+17.04]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.26.4+16.10]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.26.4]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (trusty-proposed) [2.26.4~14.04]
<apw> ^ this latter is being resubmitted with a small tweek
-queuebot:#ubuntu-release- Unapproved: cinder (trusty-proposed/main) [1:2014.1.5-0ubuntu2.1 => 1:2014.1.5-0ubuntu2.2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: aodh (xenial-proposed/universe) [2.0.5-0ubuntu1 => 2.0.6-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: designate (xenial-proposed/universe) [1:2.0.0-0ubuntu1 => 1:2.1.0-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: ceilometer (xenial-proposed/main) [1:6.1.4-0ubuntu1 => 1:6.1.5-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: heat (xenial-proposed/main) [1:6.1.1-0ubuntu1 => 1:6.1.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (xenial-proposed/main) [2:8.4.0-0ubuntu2 => 2:8.4.0-0ubuntu2.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: keystone (xenial-proposed/main) [2:9.3.0-0ubuntu1 => 2:9.3.0-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (xenial-proposed/main) [2:13.1.3-0ubuntu2 => 2:13.1.4-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: horizon (yakkety-proposed/main) [3:10.0.3-0ubuntu1 => 3:10.0.4-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: keystone (yakkety-proposed/main) [2:10.0.1-0ubuntu1 => 2:10.0.1-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (yakkety-proposed/main) [2:9.3.1-0ubuntu1 => 2:9.4.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (yakkety-proposed/main) [2:14.0.5-0ubuntu1 => 2:14.0.7-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: swift (yakkety-proposed/main) [2.10.1-0ubuntu1 => 2.10.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted kexec-tools [source] (yakkety-proposed) [1:2.0.10-2ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: pulseaudio (xenial-proposed/main) [1:8.0-0ubuntu3.2 => 1:8.0-0ubuntu3.3] (core)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.26.1~14.04 => 2.26.4~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.26.4~14.04]
-queuebot:#ubuntu-release- Unapproved: cinder (zesty-proposed/main) [2:10.0.1-0ubuntu1 => 2:10.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: heat (zesty-proposed/main) [1:8.0.0-0ubuntu1 => 1:8.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: horizon (zesty-proposed/main) [3:11.0.1-0ubuntu1 => 3:11.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: keystone (zesty-proposed/main) [2:11.0.0-0ubuntu1.1 => 2:11.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (zesty-proposed/main) [2:10.0.0-0ubuntu5.1 => 2:10.0.2-0ubuntu1] (openstack, ubuntu-server)
<jamespage> hi - please could horizon 11.0.2-0ubuntu1 be rejected from the zesty unapproved queue - I missed the exta orig.tar.gz needed
<apw> jamespage, looking
-queuebot:#ubuntu-release- Unapproved: nova-lxd (zesty-proposed/main) [15.0.1-0ubuntu1.1 => 15.0.2-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: swift (zesty-proposed/main) [2.13.0-0ubuntu1 => 2.13.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (zesty-proposed/main) [2:15.0.2-0ubuntu1 => 2:15.0.5-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected horizon [source] (zesty-proposed) [3:11.0.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted haskell-assert-failure [arm64] (artful-proposed) [0.1.1.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-assert-failure [armhf] (artful-proposed) [0.1.1.0-1]
<apw> jamespage, ^
-queuebot:#ubuntu-release- New: accepted haskell-assert-failure [amd64] (artful-proposed) [0.1.1.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-assert-failure [ppc64el] (artful-proposed) [0.1.1.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-enummapset-th [amd64] (artful-proposed) [0.6.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-enummapset-th [armhf] (artful-proposed) [0.6.1.1-1]
<jamespage> apw: ta
-queuebot:#ubuntu-release- New: accepted haskell-enummapset-th [ppc64el] (artful-proposed) [0.6.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-hsini [amd64] (artful-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-hsini [armhf] (artful-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-hsini [ppc64el] (artful-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-minimorph [arm64] (artful-proposed) [0.1.6.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-assert-failure [i386] (artful-proposed) [0.1.1.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-enummapset-th [arm64] (artful-proposed) [0.6.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-enummapset-th [s390x] (artful-proposed) [0.6.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-hsini [i386] (artful-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-minimorph [armhf] (artful-proposed) [0.1.6.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-assert-failure [s390x] (artful-proposed) [0.1.1.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-hsini [arm64] (artful-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-enummapset-th [i386] (artful-proposed) [0.6.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-hsini [s390x] (artful-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-minimorph [amd64] (artful-proposed) [0.1.6.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-minimorph [ppc64el] (artful-proposed) [0.1.6.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-minimorph [i386] (artful-proposed) [0.1.6.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-minimorph [s390x] (artful-proposed) [0.1.6.1-1]
-queuebot:#ubuntu-release- Unapproved: horizon (zesty-proposed/main) [3:11.0.1-0ubuntu1 => 3:11.0.2-0ubuntu1] (openstack, ubuntu-server)
<jamespage> apw: btw are you an archive-admin? I have an approved MIR for artful (vine) which needs pushing to main so that a ton of stuff can migrate to the release pocket for openstack
<apw> jamespage, got the bug#
<jamespage> apw: https://bugs.launchpad.net/ubuntu/+source/vine/+bug/1688091
<ubot5> Ubuntu bug 1688091 in vine (Ubuntu) "[MIR] vine" [High,Fix committed]
<apw> jamespage, done
<jamespage> apw: thankyou!
<sergiusens> cjwatson: so with that code change I still see autopackage errors; not sure if the module is loaded at all in the testbed and if you should just skip if not
<cjwatson> I can't skip it anyway, no longer have that authority
<cjwatson> always better to try to get it at least somewhat passing to avoid causing problems for other migrations, though
<cjwatson> maybe worth trying a modprobe?  somebody with autopkgtest infrastructure knowledge might be able to advise
<sergiusens> cjwatson: who is the authority; I just feel I sunk into this problem now :-P
<sergiusens> s/;/?/
<sergiusens> oh, wrong channel...
<cjwatson> I don't want to go there; skipping failures at the release team level is a last resort
<cjwatson> Laney: do you know if modprobe will work in autopkgtests?
<jbicha> apw: could you look into letting vala and evolution-data-server through the artful new queue to start those transitions now?
<jbicha> vala in particular will end up causing some pkgs to FTBFS so we shouldn't wait too long to upload it
<Laney> cjwatson: It's just cloud VMs for amd64/i386, so - I don't see why not, if you're root (Restrictions: needs-root)
<Laney> This would probably reproduce using the qemu runner locally
<jbicha> (vala has been stuck in Debian's new queue for 5 weeks)
<infinity> sergiusens: If you need a module loaded, "modinfo foo && modprobe foo || skip_test"
<sergiusens> thanks
<vtapia> hi, we have a regression in sssd (https://bugs.launchpad.net/bugs/1695870), would it be possible to phase the latest release in trusty-updates?
<ubot5> Ubuntu bug 1695870 in sssd (Ubuntu) "[regression] sssd won't start if autofs is not installed" [Undecided,Confirmed]
<vtapia> or maybe push the fix in -proposed to -updates
<vtapia> as it's been verified already
<sil2100> vtapia: let me take a look at how it's aged
<vtapia> ack, thanks sil2100
<slashd> sil2100, 1 day I think
<slashd> not that long
<sil2100> uh, don't like SRU -proposed releases without sru-review
<sil2100> slashd: thanks, the internet here is a bit shitty
<slashd> sil2100, "sssd 	1.11.5-1ubuntu3 	1.11.8-0ubuntu0.6 	1.11.8-0ubuntu0.7 (slashd, vtapia) 	1566508 1695870   	1"
<slashd> from pending sru ^
<sil2100> vtapia: still some days to go for that I would say...
<vtapia> yeah, I'm just asking due to the criticity
<vtapia> either phasing or publishing work for me
<slashd> sil2100, what do you mean by "uh, don't like SRU -proposed releases without sru-review" ?
<slashd> just curious
<sil2100> It's a tooling thing, some reviewers can manually review the SRU and release it without using our sru-review tool, not a big deal though
<slashd> sil2100, ok out of our control ;)
<slashd> sil2100, so we keep the pkg in -update as is ? and we will re-evaluate the situation in couple of days when the pkg will have more days aging in -proposed or we wait the 7 days ? what do you suggest in this case ?
<sil2100> slashd: I would like it to at least get some more testing in -proposed first, might be less than 7 days but I'm really not confident in releasing something that only had a day for user testing
<sil2100> Not sure about phasing tho, bdmurray would have to comment there
<vtapia> sil2100: I'll ask for more reviewers if that helps
<slashd> sil2100, anything we (vtapia and I) can do to help ?
<sil2100> slashd, vtapia: I would maybe be more confident if this got more dogfooding from different people
<slashd> vtapia, sil2100, sure we can ask our teamates to give it a try and provide feedbacks
<slashd> objective feedbacks ;)
<sil2100> To make sure this doesn't regress anything too
<slashd> sil2100, sound good
-queuebot:#ubuntu-release- New binary: jquery-at.js [amd64] (artful-proposed/none) [1.5.3+dfsg.1-1] (no packageset)
<slashd> sil2100, vtapia so let's reconvene in a couple of days if we get more feedbacks ?
<vtapia> slashd: I'm already pinging people
<vtapia> btw, slashd, mind verifying?
<slashd> vtapia, will do
<bdmurray> If the current version of sssd in -updates causes a regression and we are pretty sure the version in -proposed fixes it we should seriously look at releasing the version in -proposed early.
<slashd> vtapia, ^^
<bdmurray> It would have been a good idea to ping someone when the regression was first discovered so that the phased-updater-percentage could have been set to 0 before the update fully phased.
<vtapia> bdmurray: totally agree, I wasn't aware of how phasing worked and jumped to prepare a fix instead
<vtapia> regarding the regression: the cause is a dependency in the upstart service (introduced in the offending update). The proposed fix removes it and creates a different upstart service to cover the original fix
<sil2100> I'll review the diff and release if all is good, but if you guys could give it more testing in the meantime that would be awesome
<bdmurray> Or the package removed.
<sil2100> bdmurray is much more experienced so he knows the procedures much better ;)
-queuebot:#ubuntu-release- Unapproved: desktop-file-utils (trusty-proposed/main) [0.22-1ubuntu1 => 0.22-1ubuntu1.1] (core)
<slashd> thanks sil2100 bdmurray and have a good rest of the sprint
<vtapia> thanks a lot guys!
-queuebot:#ubuntu-release- Unapproved: desktop-file-utils (precise-proposed/main) [0.20-0ubuntu3 => 0.20-0ubuntu3.1] (core)
<sil2100> vtapia, slashd: accepted, yay for lack of regressions!
<sil2100> Remember to give an AA a poke in case this regresses something else ;)
<vtapia> will do, thanks again sil2100 !
<sergiusens> cjwatson: just as a follow-up, locally in adt/qemu, modprobing works; also, the kernel module overlay had an alias of overlayfs back in older releases and now the alias is fs-overlay (in case you were wondering)
<slashd> sil2100, thanks much appreciated as always
<sil2100> yw!
-queuebot:#ubuntu-release- Unapproved: cloud-init (trusty-proposed/main) [0.7.5-0ubuntu1.21 => 0.7.5-0ubuntu1.22] (ubuntu-cloud, ubuntu-server)
<valorie> hi ubuntu release team -- I don't see my email about KDE PIM packages in the release-team list archives. I'm not subbed, so could an ML list admin allow its publication please?
<jbicha> valorie: it was posted several hours ago: https://lists.ubuntu.com/archives/ubuntu-release/2017-June/004132.html
<valorie> yay~
<valorie> thanks
 * valorie now waits for an answer
<valorie> or .... action!
<valorie> gosh, I didn't look very closely, sorry
<xnox> sil2100, could you please re-review https://launchpad.net/ubuntu/zesty/+queue?queue_state=1&queue_text=systemd ? i have updated all the templates on all the bugs
<xnox> some of them were marked as "fix-committed" wrongly, as the package itself is still in -proposed, thus i reset all the status back to non- fix committed
-queuebot:#ubuntu-release- New: accepted wayland [amd64] (xenial-proposed) [1.12.0-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted wayland [armhf] (xenial-proposed) [1.12.0-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted wayland [powerpc] (xenial-proposed) [1.12.0-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted wayland [s390x] (xenial-proposed) [1.12.0-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted wayland [arm64] (xenial-proposed) [1.12.0-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted wayland [ppc64el] (xenial-proposed) [1.12.0-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted wayland [i386] (xenial-proposed) [1.12.0-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-4.0 [amd64] (xenial-proposed) [1:4.0-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-4.0 [armhf] (xenial-proposed) [1:4.0-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-4.0 [powerpc] (xenial-proposed) [1:4.0-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-4.0 [s390x] (xenial-proposed) [1:4.0-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-4.0 [arm64] (xenial-proposed) [1:4.0-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-4.0 [ppc64el] (xenial-proposed) [1:4.0-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-4.0 [i386] (xenial-proposed) [1:4.0-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New binary: libp11-openssl1.1 [amd64] (artful-proposed/universe) [0.4.4-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libp11-openssl1.1 [s390x] (artful-proposed/universe) [0.4.4-4] (no packageset)
-queuebot:#ubuntu-release- New binary: python-iso3166 [amd64] (artful-proposed/universe) [0.8.git20170319-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libp11-openssl1.1 [ppc64el] (artful-proposed/universe) [0.4.4-4] (no packageset)
-queuebot:#ubuntu-release- New binary: node-stream-assert [amd64] (artful-proposed/universe) [2.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libp11-openssl1.1 [arm64] (artful-proposed/universe) [0.4.4-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libp11-openssl1.1 [i386] (artful-proposed/universe) [0.4.4-4] (no packageset)
-queuebot:#ubuntu-release- New binary: lua-argparse [amd64] (artful-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libp11-openssl1.1 [armhf] (artful-proposed/universe) [0.4.4-4] (no packageset)
#ubuntu-release 2017-06-08
<sergiusens> slangasek: mind sponsoring/accepting the click's in https://launchpad.net/~sergiusens/+archive/ubuntu/ppa/+packages?field.name_filter=click&field.status_filter=published&field.series_filter= ? or do I need to ask separate people?
<Ukikie> Has skype allowed/pushed/whatever an update for -partner?  According to them, the version that's in partner will be incompatible with the network July 1st.
<slangasek> sergiusens: I will try to take a look at it.  But why does the 'finalize' log at https://bileto.ubuntu.com/log/2790/finalize/1/ show that the branches were merged before I clicked finalize?
<sergiusens> slangasek: I tried to click and got "unautharized" error, maybe it did really trigger them?
<slangasek> sergiusens: hmm, well I hope not
<sergiusens> slangasek: cannot say much after that, first time I use bileto; I don't have permissions for lp:click nor this part of the command. The merges do say bileto bot
<slangasek> sergiusens: indeed.  Could be a bug in bileto, I simply hope that it wasn't
-queuebot:#ubuntu-release- Unapproved: mesa (zesty-proposed/main) [17.0.6-0ubuntu0.17.04.1 => 17.0.7-0ubuntu0.17.04.1] (core, xorg)
-queuebot:#ubuntu-release- New source: python-os-traits (artful-proposed/primary) [0.3.1-0ubuntu1]
<bluesabre> Hello release team,  is it possible to release thunar (xenial, yakkety, zesty) and xfce4-weather-plugin (xenial) into -proposed? We started the SRU process  a couple weeks ago, but I think these two got missed and never made it to the second step. https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1679488 and https://bugs.launchpad.net/ubuntu/+source/xfce4-weather-plugin/+bug/1688056
<ubot5> Ubuntu bug 1679488 in thunar (Ubuntu Zesty) "Thunar freezes when left inactive for a while" [Undecided,In progress]
<ubot5> Ubuntu bug 1688056 in xfce4-weather-plugin (Ubuntu Xenial) "Package outdated" [Undecided,In progress]
<apw> bluesabre, hmmmm, can look in a little i suspect
-queuebot:#ubuntu-release- Unapproved: accepted thunar [source] (zesty-proposed) [1.6.11-1ubuntu0.17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted thunar [source] (yakkety-proposed) [1.6.11-0ubuntu0.16.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted thunar [source] (xenial-proposed) [1.6.11-0ubuntu0.16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-weather-plugin [source] (xenial-proposed) [0.8.9-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected mesa [source] (zesty-proposed) [17.0.7-0ubuntu0.17.04.1]
-queuebot:#ubuntu-release- Unapproved: mesa (zesty-proposed/main) [17.0.6-0ubuntu0.17.04.1 => 17.0.7-0ubuntu0.17.04.1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: xfce4-weather-plugin (yakkety-proposed/universe) [0.8.7-3 => 0.8.9-0ubuntu0.16.10.1] (ubuntustudio, xubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-weather-plugin [source] (yakkety-proposed) [0.8.9-0ubuntu0.16.10.1]
<tjaalton> could someone override glbinding autopkgtest on armhf, it "fails" because current gcc adds some deprecation notifications to the test output. tests itself pass fine
<apw> tjaalton, is someone going to sort out the tests for next time ?
<tjaalton> as in modifying glbinding pkg?
<tjaalton> maybe I should try that first
<tjaalton> though I don't know how to best do that
<tjaalton> right now it does
<tjaalton> cmake .. && make && make test
<tjaalton> and it's the output from 'make' that fails the autopkgtest
<apw> tjaalton, you do not want to have to read the output for the tests every time for ever going forward to check it is overridable, so we want to do something with it
<tjaalton> yes, but what
<apw> i guess we have some options, 1) fix the code so it is no longer using the deprecated interfaces, 2) elide the deprecation errors from make component
<apw> the first is ideal of course
<tjaalton> I just wanted to update mesa, and now have to update glbinding :P
<tjaalton> esp. since the debian maintainer isn't too active
<tjaalton> this is the initial upload from last year
<apw> heh life does suck sometimes
<apw> it may of course not build .... la la la
<apw> tjaalton, i guess if those are the only errors and you ahve checked them for your mesa we could just ignore them for your upload
<apw> so they don't get a free pass forever in this version
<tjaalton> there are no errors
<tjaalton> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/armhf/g/glbinding/20170608_080105_30a3a@/log.gz
<apw> tjaalton, there are failures when re-testing with your mesa update because of the warnings coming out, right ?
<tjaalton> it's just the make output that makes it fial
<tjaalton> fail
<tjaalton> notifications, yes
<tjaalton> and it's not because of mesa but something else
<tjaalton> that changed in artful
<tjaalton> mesa just triggered the autopkgtes
<tjaalton> t
<apw> tjaalton, so i am saying it would likely be reasonable to say we can ignore the failures for mesa if that is the only regression you have
<tjaalton> it is
<apw> tjaalton, ok done
<tjaalton> thx'
-queuebot:#ubuntu-release- Unapproved: libclc (xenial-proposed/universe) [0.2.0+git20150813-2 => 0.2.0+git20170213-1~16.04.1] (no packageset)
<jamespage> any archive-admins have a few cycles to review some new packages for OpenStack in the artful NEW queue?
<jamespage> specifically: python-deprecation, pypowervm, python-ovsdbapp, python-zunclient and python-os-traits
<slashd> morning bdmurray (today's vanguard), I know you are sprinting and I don't want to take a lot of your time, but could you please have a look at theses uploads whenever you have time [1] - https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=lxd [2]- https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=vlan and if you have extra time to "Fix Released" percona-xtradb-cluster-5.5 that would be
<slashd> awesome for us.
<slashd> ddstreet ^
<stgraber> looks like the snapcraft test is busted right now, most likely because of external code it's getting/running which appears to have changed
<stgraber> that's blocking the push of a critical bugfix for LXD in artful so I'm going to be pushing a force-badtest for snapcraft
<apw> stgraber, if you badtest it it will migrate, so it needs blocking
<apw> stgraber, or you could skiptest lxd if that is its only blocker
<stgraber> apw: I'm badtesting the old snapcraft from artful itself, not the one in artful-proposed (which seems to also be broken)
<apw> stgraber, ahh ok
<stgraber> apw: but indeed as it's the only failure for LXD, I could have gone with skiptest for LXD instead
<stgraber> apw: I pinged kyrofa about it so upstream snapcraft can figure out what's going on here. AFAICT they're downloading bits from pip and running them, so it's likely external code which changed...
<apw> stgraber, the second fatal change in pip in 2 weeks by the sounds of it
<stgraber> yeah, I saw you and infinity pushed similar overrides to snapcraft...
<stgraber> that's a big hint not to depend on external code in your package tests but given what snapcraft does, it might be kinda hard for them to do
<apw> yeah
-queuebot:#ubuntu-release- Unapproved: accepted vlan [source] (trusty-proposed) [1.9-3ubuntu10.4]
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-proposed) [2.0.10-0ubuntu1~16.04.1]
<slashd> sil2100, hi about LP: #1657256. My colleague Mmike told me that this particular fix is percona-xtradb-cluster-5.5 (only available in trusty) and the current fix doesn't apply to Xenial and late because it run 5.6 (totally different source code) and no upstream fix is made yet for 5.6 but there was one already for 5.5, does that make any difference ? if not it's totally fine, just wanted to bring this to the table since the
<slashd> sru has been blocked. If you keep the decision to block the SRU, I'll talk to Mmike in order for him to create a upstream fix to 5.6 before SRU'ing 5.5
<ubot5> Launchpad bug 1657256 in percona-xtradb-cluster-5.5 (Ubuntu) "Percona crashes when doing a a 'larger' update" [Medium,In progress] https://launchpad.net/bugs/1657256
<sil2100> slashd: so the case here is that for us to release a fix somewhere in an older series it needs to be also present in the devel series - the package names are different but basically 5.6 replaces 5.5 in future releases
<slashd> sil2100, yeah I though it wouldn't apply because it's totally 2 different versions, so I'll told MMike to start working on a 5.6 fix upstream, SRU'ing it, and then restart the SRU of 5.5 from skratch
<sil2100> slashd: if we accept the 5.5 fix in trusty and people will upgrade to a future release, the fix will be gone
<sil2100> slashd: this is the biggest worry and the main reason why we require the devel series to be released first
<slashd> sil2100, true, and I'm totally in favour to have the fix release in devel release first. I just thought that since it was 2 different version it wouldn't apply in this particular, case but it's noted for future, thanks
<sil2100> slashd: it doesn't have to be the *very same* fix, but the bug needs to be fixed
<slashd> sil2100, sure, I'll pass the message to MMike and it's noted in my case for similar SRU situation.
<slashd> thanks bdmurray and sil2100, much appreciated
<slangasek> override_dh_fixperms:
<slangasek> 	$(overridden_command) -Xetc/xdg/autostart/kalarm.autostart.desktop
<slangasek> $ cat debian/lintian-overrides
<slangasek> executable-not-elf-or-script etc/xdg/autostart/kalarm.autostart.desktop
<slangasek> $
<slangasek> mmmhmm
<sil2100> slashd: thanks!
-queuebot:#ubuntu-release- New binary: gir-to-d [amd64] (artful-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gir-to-d [armhf] (artful-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gir-to-d [i386] (artful-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pyepsg [amd64] (artful-proposed/universe) [0.3.1-1] (no packageset)
<slangasek> acheronuk: kalarm debian/copyright claims that the code is all GPL2+; the copyright in ./src/kalarmmigrateapplication.{cpp,h} does not agree
-queuebot:#ubuntu-release- New: accepted kalarm [source] (artful-proposed) [4:16.12.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-pyepsg [amd64] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted gir-to-d [amd64] (artful-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted gir-to-d [i386] (artful-proposed) [0.9.0-1]
<acheronuk> slangasek: oh. I didn't do the copyright updated for those, but will make sure any that are wrong are correct with the next upload
-queuebot:#ubuntu-release- New: accepted libp11-openssl1.1 [amd64] (artful-proposed) [0.4.4-4]
-queuebot:#ubuntu-release- New: accepted libp11-openssl1.1 [armhf] (artful-proposed) [0.4.4-4]
-queuebot:#ubuntu-release- New: accepted libp11-openssl1.1 [ppc64el] (artful-proposed) [0.4.4-4]
-queuebot:#ubuntu-release- New: accepted lua-argparse [amd64] (artful-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted python-iso3166 [amd64] (artful-proposed) [0.8.git20170319-1]
-queuebot:#ubuntu-release- New: accepted gir-to-d [armhf] (artful-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted libp11-openssl1.1 [arm64] (artful-proposed) [0.4.4-4]
-queuebot:#ubuntu-release- New: accepted libp11-openssl1.1 [s390x] (artful-proposed) [0.4.4-4]
-queuebot:#ubuntu-release- New: accepted jquery-at.js [amd64] (artful-proposed) [1.5.3+dfsg.1-1]
-queuebot:#ubuntu-release- New: accepted node-stream-assert [amd64] (artful-proposed) [2.0.3-1]
-queuebot:#ubuntu-release- New: accepted libp11-openssl1.1 [i386] (artful-proposed) [0.4.4-4]
<slangasek> acheronuk: this was not a regression vs. kdepim, and I have accepted the package.  should be fixed, though
<acheronuk> slangasek: it will be. thanks for doing that :)
<slangasek> acheronuk: also, see my skepticism above regarding the combination of a dh_fixperms override in debian/rules with a lintian override
<acheronuk> noted, and now looking where that came from
<acheronuk> slangasek: I'm doubtful we need any of that. I'll do a test build to see if we can throw that away and still have that autostart
<Ampelbein> Hi. Is there anything missing for #1513567 to be reviewed? Do you need any more information?
<Ampelbein> bug #1513567
<ubot5> bug 1513567 in gwakeonlan (Ubuntu Xenial) "[SRU] There is no executable in this package" [High,In progress] https://launchpad.net/bugs/1513567
-queuebot:#ubuntu-release- New binary: dpdk [ppc64el] (artful-proposed/main) [16.11.1-2] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: dpdk [amd64] (artful-proposed/main) [16.11.1-2] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: dpdk [i386] (artful-proposed/main) [16.11.1-2] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: dpdk [arm64] (artful-proposed/main) [16.11.1-2] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted dpdk [amd64] (artful-proposed) [16.11.1-2]
-queuebot:#ubuntu-release- New: accepted dpdk [i386] (artful-proposed) [16.11.1-2]
-queuebot:#ubuntu-release- New: accepted dpdk [arm64] (artful-proposed) [16.11.1-2]
-queuebot:#ubuntu-release- New: accepted dpdk [ppc64el] (artful-proposed) [16.11.1-2]
-queuebot:#ubuntu-release- New binary: node-gulp-concat [amd64] (artful-proposed/universe) [2.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave [ppc64el] (artful-proposed/universe) [4.2.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave [i386] (artful-proposed/universe) [4.2.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave [amd64] (artful-proposed/universe) [4.2.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave [s390x] (artful-proposed/universe) [4.2.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave [armhf] (artful-proposed/universe) [4.2.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave [arm64] (artful-proposed/universe) [4.2.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: flask-htmlmin [amd64] (artful-proposed/universe) [1.2-1] (no packageset)
<infinity> lan3y: I had to restart all but 3 ppc64el worker services for autopkgtest.  Not sure how or where to debug why they were dead, so if you feel like doing a post-mortem, please do.
<Laney> infinity: Why did you have to?
<infinity> Laney: Because they were all dead, only 3 things were running, yet hundreds in the queue.
<infinity> Laney: Which implied to me that all the dead ones were maybe an issue.
<infinity> Laney: But I dunno.
<Laney> They're supposed to self-restart
<Laney> Would be interesting if they didn't
<infinity> Laney: "systemctl --all list-units autopkgtest\*|sort | grep dead" seems to disagree on that score.
-queuebot:#ubuntu-release- Unapproved: cloud-init (trusty-proposed/main) [0.7.5-0ubuntu1.21 => 0.7.5-0ubuntu1.22] (ubuntu-cloud, ubuntu-server)
<smoser> hi. there are now 2 cloud-init uploads in trusty  queue
<smoser> could someone NACK my first? the first does not have a fix for bug 1379080
<ubot5> bug 1379080 in cloud-init (Ubuntu Zesty) "update-grub-legacy-ec2 fails to detect xen kernel" [Medium,Fix released] https://launchpad.net/bugs/1379080
<Laney> infinity: I'll look later on if you don't figure it out
<Laney> Got to go watch election results / sleep
<Laney> night
<infinity> Laney: I'm about to go eat all the meat, hence the hand-off (which I assumed would catch you in the morninig, not now. :P)
<infinity> morning.  Typing hard.
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (trusty-proposed) [0.7.5-0ubuntu1.22]
-queuebot:#ubuntu-release- Unapproved: rejected desktop-file-utils [source] (precise-proposed) [0.20-0ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: maas (xenial-proposed/main) [2.1.5+bzr5596-0ubuntu1~16.04.1 => 2.2.0+bzr6054-0ubuntu2~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: maas (yakkety-proposed/main) [2.1.5+bzr5596-0ubuntu1~16.10.1 => 2.2.0+bzr6054-0ubuntu2~16.10.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: maas (zesty-proposed/main) [2.2.0~rc1+bzr5922-0ubuntu2 => 2.2.0+bzr6054-0ubuntu2~17.04.1] (ubuntu-server)
#ubuntu-release 2017-06-09
<jbicha> infinity: well I thought I would try desktop-file-utils at least, thanks
-queuebot:#ubuntu-release- Unapproved: netcfg (zesty-proposed/main) [1.138ubuntu5 => 1.138ubuntu5.1] (core)
-queuebot:#ubuntu-release- Unapproved: netcfg (yakkety-proposed/main) [1.138ubuntu2 => 1.138ubuntu2.1] (core)
-queuebot:#ubuntu-release- Unapproved: netcfg (xenial-proposed/main) [1.135ubuntu4.3 => 1.135ubuntu4.4] (core)
<cyphermox> bdmurray: still around? do you have time to review the netcfgs?
<bdmurray> cyphermox: I think you should come talk to me in person
<cyphermox> but whyyyy?
<cyphermox> :)
<slangasek> doko: I see some autopkgtest regressions caused by new warnings from gcc: http://autopkgtest.ubuntu.com/packages/c/ciftilib/artful/armhf , http://autopkgtest.ubuntu.com/packages/f/fast5/artful/armhf - is that a behavior change that we want to keep?  it's not clear to me that the behavior described by the new warning actually breaks the code under gcc 7.1
<estan> tjaalton: good morning, any chance you could do the qtbase-opensource-src 5.5.1+dfsg-16ubuntu7.5 SRU? it has two nice verfied fixes i'm eagerly awaiting :)
<estan> (some autopkgtests were previously failing, but they were all false positives, and passed after mitya57 restarted them yesterday)
<tjaalton> estan: you mean releasing it? there's a rule to not release on friday..
 * apw concurs
<estan> tjaalton: aha, that makes sense.
<ginggs> slangasek: still around?
<ginggs> slangasek: i guess not, it was discussed in #ubuntu-devel less than two days ago. affected packages glbinding, ciftilib, fast5
<jamespage> o/
<jamespage> any archive admins around to poke python-script binary NEW packages into artful-proposed?
<apw> jamespage, i can ...
-queuebot:#ubuntu-release- New: accepted python-scrypt [arm64] (artful-proposed) [0.8.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-scrypt [ppc64el] (artful-proposed) [0.8.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-scrypt [i386] (artful-proposed) [0.8.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-scrypt [amd64] (artful-proposed) [0.8.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-scrypt [s390x] (artful-proposed) [0.8.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-scrypt [armhf] (artful-proposed) [0.8.0-0ubuntu1]
<jamespage> apw: thanks
<jamespage> apw: would you have a bit of time todo some NEW package reviews for artful? I have 5 or so new python deps for OpenStack in the queue
<apw> jamespage, that thing is exploding, i will see if i can get to it
<jamespage> apw: https://launchpad.net/ubuntu/artful/+queue?queue_state=0&queue_text=python (apart from flask-htmlmin) is blocking OpenStack Pike b2 updates atm
-queuebot:#ubuntu-release- New: accepted flask-htmlmin [amd64] (artful-proposed) [1.2-1]
-queuebot:#ubuntu-release- New: accepted node-gulp-concat [amd64] (artful-proposed) [2.6.1-1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-fan (yakkety-proposed/main) [0.12.0.1 => 0.12.0.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-fan [source] (yakkety-proposed) [0.12.0.2]
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.29 => 2.31] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapcraft (yakkety-proposed/universe) [2.29+16.10 => 2.31+16.10] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapcraft (zesty-proposed/universe) [2.29+17.04 => 2.31+17.04] (no packageset)
<jbicha> sil2100: have you decided you don't like verification-done any more and prefer verification-done-{series} ?
<sil2100> jbicha: yeah, we're in the middle of changing the process so I'm switching all verification-done bugs to the series notation
<sil2100> Don't worry about it, I go through a list and all is good
<sil2100> jbicha: anyway, yes, from now on please use the verification-done-RELEASE tags for everything, even when there's only one series affected
<bdmurray> slangasek: There are some snapcraft uploads in the SRU queue what were you saying yesterday about python3-click?
-queuebot:#ubuntu-release- New binary: debuerreotype [amd64] (artful-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libimage-sane-perl [i386] (artful-proposed/universe) [0.09-1] (no packageset)
-queuebot:#ubuntu-release- New binary: el-mock-el [amd64] (artful-proposed/universe) [1.25.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libimage-sane-perl [ppc64el] (artful-proposed/universe) [0.09-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qml-mode [amd64] (artful-proposed/universe) [0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ert-expectations-el [amd64] (artful-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libimage-sane-perl [arm64] (artful-proposed/universe) [0.09-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jugglinglab [amd64] (artful-proposed/universe) [0.6.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-delayedarray [amd64] (artful-proposed/universe) [0.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libimage-sane-perl [amd64] (artful-proposed/universe) [0.09-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libimage-sane-perl [s390x] (artful-proposed/universe) [0.09-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libimage-sane-perl [armhf] (artful-proposed/universe) [0.09-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jinja2-mode [amd64] (artful-proposed/universe) [0.2-1] (no packageset)
<slangasek> bdmurray: sergiusens had pointed me at ttps://launchpad.net/~sergiusens/+archive/ubuntu/ppa/+packages?field.name_filter=click&field.status_filter=published&field.series_filter= which need uploads sponsored and accepted as SRU
<bdmurray> slangasek: where'd your h go?
<slangasek> bdmurray: the cut'n'paste imp
<apw> takes his cut ...
-queuebot:#ubuntu-release- Unapproved: click (zesty-proposed/main) [0.4.45.1+16.10.20160916-0ubuntu1 => 0.4.46+17.04.20170607.3-0ubuntu1] (ubuntu-desktop)
<slashd> bdmurray, what means "rls-aa-notfixing" -> release-artful-notfixing ? and what does it means for us ?
<slashd> ddstreet^
<slashd> bdmurray, I think I found the answer here : https://blueprints.launchpad.net/ubuntu/+spec/other-q-release-bug-list-workflows
<cyphermox> we're just reviewing bugs in rls-aa-tracking and rls-aa-incoming since we're all face to face
<slashd> cyphermox, thnaks
<slashd> thanks
<cyphermox> specifically, I think this one bug is that you already seem to have it handled, and sponsors are subscribed, so we don't need to be tracking it to schedule engineering time on it (since someone else did)
<slashd> cyphermox, cool was just making sure if something in particular was blocking aa upload or something
<cyphermox> I don't think so. remind me what bug and I can sponsor it if it checks out
<slashd> ddstreet, have the LP # handy for cyphermox ^ if the patch is ready for sponsor
<ddstreet> lp 1693819
<ubot5> Launchpad bug 1693819 in isc-dhcp (Ubuntu Artful) "dhclient DHCPv6 does not work with interface alias" [Low,In progress] https://launchpad.net/bugs/1693819
<ddstreet> cyphermox note that this isn't fixed upstream with isc-dhcp, but i did open a bug with them - their bug tracking is private though
<cyphermox> yeah
<cyphermox> I've opened a tab for it, I will look when we're done with the list of bugs
<ddstreet> thanks, it's not urgent, and feel free to suggest a different way to patch it
<slangasek> slashd: yeah we are just making it clear that foundations is not committing to fix for artful; we are still happy to take your fix
<mdeslaur> FYI, there seems to be a heck of a lot of openssl upgrade failure bugs coming in
<slashd> slangasek, sound good to me thanks for the clarification
-queuebot:#ubuntu-release- Unapproved: click (yakkety-proposed/main) [0.4.45.1+16.10.20160916-0ubuntu1 => 0.4.46+16.10.20170607.3-0ubuntu1] (ubuntu-desktop)
<valorie> dear release team, I've not gotten a response about KDE PIM on the ML; I would appreciate suggestions
<valorie> we're preparing more packages that will need approval and don't want to clog any pipelines
<valorie> alpha 1 approaches
-queuebot:#ubuntu-release- New: accepted kmail [source] (artful-proposed) [4:16.12.3-0ubuntu1]
<slangasek> valorie: I have been looking at the queue following the email prompting (which, btw, your mail seems not to have cleared ubuntu-release or ubuntu-devel but acheronuk's has as of yesterday).  FWIW the sourceful NEW queue in Ubuntu doesn't get much attention because we generally don't expect NEW packages to come into Ubuntu that way in the general case, rather than through Debian
<valorie> thanks for your attention, slangasek
<slangasek> valorie: and you'll usually get better results on the queue talking to AAs in realtime on IRC, so that we can ask questions and give feedback about packages there... such as the kmail-account-wizard source package, which I'm wondering why it has a different source package name than the binary package
<valorie> well, the devels tried
<valorie> clivejo: any input on the above to slangasek?
<slangasek> "the devels tried" - to talk to AAs?
<valorie> I know Rik did
<valorie> slangasek: my post is in the list archives.....
-queuebot:#ubuntu-release- New: accepted debuerreotype [amd64] (artful-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted ert-expectations-el [amd64] (artful-proposed) [0.2-1]
<slangasek> that's interesting, I wonder what ate it here
-queuebot:#ubuntu-release- New: accepted jugglinglab [amd64] (artful-proposed) [0.6.2-1]
-queuebot:#ubuntu-release- New: accepted libimage-sane-perl [arm64] (artful-proposed) [0.09-1]
-queuebot:#ubuntu-release- New: accepted libimage-sane-perl [i386] (artful-proposed) [0.09-1]
-queuebot:#ubuntu-release- New: accepted libimage-sane-perl [s390x] (artful-proposed) [0.09-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-delayedarray [amd64] (artful-proposed) [0.2.4-1]
-queuebot:#ubuntu-release- New: accepted el-mock-el [amd64] (artful-proposed) [1.25.1-1]
-queuebot:#ubuntu-release- New: accepted libimage-sane-perl [amd64] (artful-proposed) [0.09-1]
-queuebot:#ubuntu-release- New: accepted libimage-sane-perl [ppc64el] (artful-proposed) [0.09-1]
-queuebot:#ubuntu-release- New: accepted jinja2-mode [amd64] (artful-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted qml-mode [amd64] (artful-proposed) [0.4-1]
-queuebot:#ubuntu-release- New: accepted libimage-sane-perl [armhf] (artful-proposed) [0.09-1]
<valorie> I'm not subbed, I guess I should do that
<clivejo> I believe Rik and Jose both tried
<valorie> "such as the kmail-account-wizard source package, which I'm wondering why it has a different source package name than the binary package" was the question
<valorie> I know Rik talked to apw, whom I understand is probably swamped
<valorie> but that doesn't help US
<slangasek> well, if a particular AA is busy, you certainly need to be prepared to shop around
<clivejo> most of these have been split or renamed upstream in KDE
<clivejo> KDE renamed the source and the git repo is here - https://cgit.kde.org/kmail-account-wizard.git/
<valorie> unfortunately the Debian freeze has hit us this time around
-queuebot:#ubuntu-release- New: accepted knotes [source] (artful-proposed) [4:16.12.3-0ubuntu1]
<valorie> ooooo
<slangasek> clivejo: there is no requirement that the source package match the upstream source name; there is a soft requirement that a source package producing a single binary package should have the same name as the binary package.  Do you know if Debian will also use the same source name?
<clivejo> slangasek: I can't be sure about it, but there has been a git repo created for it https://anonscm.debian.org/cgit/pkg-kde/applications/kmail-account-wizard.git/
<clivejo> which is a copy of the previous source package kdepim
<clivejo> which they will remove and split it into the new package
#ubuntu-release 2017-06-10
<santa_> gpul's server is up again, doing test rebuilds
<santa_> oops, wrong chan
<tsimonq2> santa_: o/ :)
<santa_> hi
<tsimonq2> Could I get eyes on this please? https://code.launchpad.net/~tsimonq2/ubuntu-seeds/add-nm-to-lubuntu-next/+merge/325440
-queuebot:#ubuntu-release- New: accepted kmail-account-wizard [source] (artful-proposed) [4:16.12.3-0ubuntu1]
<tsimonq2> cyphermox: Just out of curiosity, are you just reviewing the MP or do you plan on merging it? :)
<cyphermox> mostly just reviewing, partly because it's a lubuntu thing someone from lubuntu should be able to merge, and partly because I'm trying to keep my time on the computer to a minimum since packing for a trip :)
<slangasek> clivejo, valorie: korganizer also has a wrong override of permissions on /etc/xdg/autostart/org.kde.korgac.desktop
<cyphermox> (I did tell someone I would review another patch)
<tsimonq2> cyphermox: I don't have access to merge to the Lubuntu seed :P
<cyphermox> tsimonq2: ok, I can merge it then
<tsimonq2> cyphermox: Ok, thanks
-queuebot:#ubuntu-release- New: accepted korganizer [source] (artful-proposed) [4:16.12.3-0ubuntu1]
<cyphermox> tsimonq2: otoh, there are other ways you could make things the image not take five minutes to boot, but nothing that really means you'd have some way to control it via UI
<cyphermox> I suspect that 5 minutes timeout is not /just/ missing NM, even if installing NM fixes it.
<tsimonq2> cyphermox: Well this is the simplest solution, given that we need a network manager anyways.
<cyphermox> yes, that I agree.
<infinity> Is https://cgit.kde.org/networkmanager-qt.git/ really not packaged?
<tsimonq2> Well, it's just waiting for networking. What other deps could it needs besides a... well... network manager?
<tsimonq2> infinity: That's just a library afaict.
<infinity> Oh, quite likely.
<infinity> But does nothing use it, then? :P
<infinity> libkf5networkmanagerqt6 exists, that's comforting.
<tsimonq2> infinity: We have one project that has very experimental usage of it, but the Debian guy wants to wait until it actually serves a purpose before packaging it. :P
<infinity> plasma-nm
<tsimonq2> Sure, but that pulls in a lot of Plasma, afaicr.
<infinity> tsimonq2: Just curious if, say, plasma-nm would bring in fewer scary deps for you than network-manager-gnome, but maybe it's just a tradeoff of one mess for another.
<tsimonq2> Either way, this is the easiest solution until I do a cleanout of the GTK libraries.
<infinity> (I would assume the goal of a Qt-based lubuntu is to not pull in GTK)
<tsimonq2> I need to reorganize lubuntu-default-settings because right now, the Qt-based Lubuntu pulls in all of LXDE with it...
<infinity> Heh.
<tsimonq2> I'm not joking.
<tsimonq2> :P
<cyphermox> infinity: oh, that said, there was some indicator that might work that interfaces with NM but isn't GTK
<infinity> Didn't think you were.
<cyphermox> tsimonq2: indicator-network might work, but YMMV
<infinity> If they have an indicator renderer, yes.
<cyphermox> yes
<tsimonq2> Well this is just the easiest solution at the moment, and I'll do a bit more careful evaluation in the future when we're deciding on final applications.
<infinity> THough isn't that the one that kinda sucks on non-touch devices, because it was designed by people who never tried it with a mouse? :P
<cyphermox> it's a more or less "standardized" protocol though
<cyphermox> no, it was meant to also work with a mouse
<tsimonq2> And this is just a "well, we're pulling in all of GTK right now, soooo"
<infinity> cyphermox: Yeah, meant to, but if it's the one I'm thinking of, it's kinda desktop-unfriendly, despite the attempt.
<cyphermox> (but maybe it got rewritten enough times that this is no longer true)
 * infinity shrugs.
<cyphermox> *shrugs*
 * tsimonq2 shrugs
 * infinity shimmies to the left.
 * tsimonq2 shimmies to the right.
<tsimonq2> Â¯\_(ã)_/Â¯
<tsimonq2> Anyways... I'd like to get this merged and at least do a smoke test tonight ;)
<cyphermox> yep, merging right now
<tsimonq2> cyphermox: gracias
<tsimonq2> My next task will be making the "Qt" slideshow less hardcoded.
<tsimonq2> Because it's hardcoded *everywhere* with Kubuntu logos and Breeze themes, etc. etc.
<tsimonq2> It's actually a little bit humorous to install the Lubuntu Next image right now because of the mismatch :P
<cyphermox> you mean ubiquity
<tsimonq2> Ah yes.
<tsimonq2> Yeah, that. :)
<cyphermox> ddstreet: isc-dhcp reviewed; I think you should instead try to relax that link-local address check.
<cyphermox> tsimonq2: I suppose you need to have lubuntu-meta updated too.
<tsimonq2> cyphermox: Please :)
<tsimonq2> cyphermox: Although it shouldn't need it for the ISO as one of the steps runs germinate, right?
<cyphermox> it does end up on the livefs.
<cyphermox> but indeed, only the task is critical to getting the livefs to include n-m and n-m-gnome.
<tsimonq2> ic :)
 * tsimonq2 will probably apply for MOTU once Stretch is released...
<cyphermox> there, lubuntu-meta is uploaded too
<tsimonq2> \o/
<tsimonq2> cyphermox: Thanks :)
<ginggs> anyone around to update 'force-badtest r-bioc-annotationhub/2.8.1-1' please? older versions are in adconrad hints
-queuebot:#ubuntu-release- Unapproved: cockpit (zesty-backports/universe) [141-2~ubuntu17.04.1 => 142-1~ubuntu17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (yakkety-backports/universe) [141-2~ubuntu16.10.1 => 142-1~ubuntu16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (zesty-backports) [142-1~ubuntu17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (yakkety-backports) [142-1~ubuntu16.10.1]
-queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [141-2~ubuntu16.04.1 => 142-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [142-1~ubuntu16.04.1]
<clivejo> <slangasek> clivejo, valorie: korganizer also has a wrong override of permissions on /etc/xdg/autostart/org.kde.korgac.desktop
<clivejo> Fair enough, but we don't have a MOTU on our team to do an upload and with it stuck in the NEW queue we can get it added to our package set to upload it ourselves
<clivejo> how do we move forward?
<clivejo> all the time we are wasting valuable time that could be used for our users to test these packages and find bugs
<clivejo> I now fear the hardest contributor on our team is getting burnt out from constantly having to nag here to get things done, it is soul destroying :(
 * clivejo bites tongue and leaves before says something he regrets
-queuebot:#ubuntu-release- Unapproved: skiboot (yakkety-proposed/universe) [5.3.3-1 => 5.3.3-1ubuntu0.1] (no packageset)
#ubuntu-release 2017-06-11
-queuebot:#ubuntu-release- Unapproved: rejected skiboot [source] (yakkety-proposed) [5.3.3-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: skiboot (yakkety-proposed/universe) [5.3.3-1 => 5.3.3-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: skiboot (xenial-proposed/universe) [5.1.13-0ubuntu2 => 5.1.13-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: dh-cargo [amd64] (artful-proposed/none) [2] (no packageset)
-queuebot:#ubuntu-release- New: accepted dh-cargo [amd64] (artful-proposed) [2]
<slangasek> cyphermox: who is the team subscriber supposed to be for caribou (LP: #1685867)?
<ubot5> Launchpad bug 1685867 in caribou (Ubuntu) "[MIR] caribou" [Undecided,Fix released] https://launchpad.net/bugs/1685867
#ubuntu-release 2018-06-04
-queuebot:#ubuntu-release- New binary: vkd3d [i386] (cosmic-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: vkd3d [s390x] (cosmic-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: vkd3d [ppc64el] (cosmic-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: vkd3d [amd64] (cosmic-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: vkd3d [arm64] (cosmic-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: vkd3d [armhf] (cosmic-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted vkd3d [amd64] (cosmic-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted vkd3d [armhf] (cosmic-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted vkd3d [ppc64el] (cosmic-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted vkd3d [arm64] (cosmic-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted vkd3d [s390x] (cosmic-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted vkd3d [i386] (cosmic-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted r-cran-roxygen2 [amd64] (cosmic-proposed) [6.0.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-roxygen2 [armhf] (cosmic-proposed) [6.0.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-roxygen2 [ppc64el] (cosmic-proposed) [6.0.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-roxygen2 [arm64] (cosmic-proposed) [6.0.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-roxygen2 [s390x] (cosmic-proposed) [6.0.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-roxygen2 [i386] (cosmic-proposed) [6.0.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pki [amd64] (cosmic-proposed) [0.1-5.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pki [armhf] (cosmic-proposed) [0.1-5.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pki [ppc64el] (cosmic-proposed) [0.1-5.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pki [arm64] (cosmic-proposed) [0.1-5.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pki [s390x] (cosmic-proposed) [0.1-5.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pki [i386] (cosmic-proposed) [0.1-5.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-geometry [amd64] (cosmic-proposed) [0.3-6+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-geometry [armhf] (cosmic-proposed) [0.3-6+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-geometry [ppc64el] (cosmic-proposed) [0.3-6+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-geometry [arm64] (cosmic-proposed) [0.3-6+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-geometry [s390x] (cosmic-proposed) [0.3-6+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-geometry [i386] (cosmic-proposed) [0.3-6+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-relsurv [amd64] (cosmic-proposed) [2.1-2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-relsurv [armhf] (cosmic-proposed) [2.1-2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-relsurv [ppc64el] (cosmic-proposed) [2.1-2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-relsurv [arm64] (cosmic-proposed) [2.1-2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-relsurv [s390x] (cosmic-proposed) [2.1-2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-relsurv [i386] (cosmic-proposed) [2.1-2-1]
-queuebot:#ubuntu-release- New: accepted baresip [amd64] (cosmic-proposed) [0.5.9-1]
-queuebot:#ubuntu-release- New: accepted baresip [armhf] (cosmic-proposed) [0.5.9-1]
-queuebot:#ubuntu-release- New: accepted baresip [ppc64el] (cosmic-proposed) [0.5.9-1]
-queuebot:#ubuntu-release- New: accepted baresip [arm64] (cosmic-proposed) [0.5.9-1]
-queuebot:#ubuntu-release- New: accepted baresip [s390x] (cosmic-proposed) [0.5.9-1]
-queuebot:#ubuntu-release- New: accepted baresip [i386] (cosmic-proposed) [0.5.9-1]
-queuebot:#ubuntu-release- New: accepted r-cran-brobdingnag [amd64] (cosmic-proposed) [1.2-5-2]
-queuebot:#ubuntu-release- New: accepted pytest-cython [amd64] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted logzero [amd64] (cosmic-proposed) [1.5.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rstantools [amd64] (cosmic-proposed) [1.5.0-2]
-queuebot:#ubuntu-release- New: accepted gemmlowp [amd64] (cosmic-proposed) [0.0~git20180416.38ebac7-1]
-queuebot:#ubuntu-release- New: accepted gemmlowp [ppc64el] (cosmic-proposed) [0.0~git20180416.38ebac7-1]
-queuebot:#ubuntu-release- New: accepted gemmlowp [arm64] (cosmic-proposed) [0.0~git20180416.38ebac7-1]
-queuebot:#ubuntu-release- New: accepted gemmlowp [s390x] (cosmic-proposed) [0.0~git20180416.38ebac7-1]
<tjaalton> sil2100: hi, are you handling 16.04.5? :)
<tjaalton> sil2100: asking because mesa needs special care, and would need to be put in bionic-proposed asap, together with libglvnd
<tjaalton> because the (non-glvnd) backport can be put in xenial only after bionic is done
<tjaalton> otherwise upgrades wouldn't work right
<sil2100> tjaalton: hey! I would love too handle it - and I hope I will
<sil2100> s/too/to
<tjaalton> ok cool
<sil2100> tjaalton: I don't see it in the bionic queue?
<tjaalton> yeah not yet, I'm just finishing it
<tjaalton> btw, there's a new bionic linux-oem respin on the ppa ;)
-queuebot:#ubuntu-release- Unapproved: mesa (bionic-proposed/main) [18.0.0~rc5-1ubuntu1 => 18.0.5-0ubuntu0~18.04.1] (core, xorg)
<tjaalton> sil2100: is uploaded now ^
<LocutusOfBorg> thanks cjwatson for fixing boinc import :)
<LocutusOfBorg> I was going to
<cjwatson> You can't except by deleting and recreating
<cjwatson> So it's generally better for staff to do that
<LocutusOfBorg> I agree!
<LocutusOfBorg> so I don't loose daily recipes
<didrocks> was snapd removed from xenial-updates?
<didrocks> Err:5 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 snapd amd64 2.32.3.2
<didrocks> E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/s/snapd/snapd_2.32.3.2_amd64.deb  404  Not Found [IP: 91.189.88.161 80]
<didrocks> rmadison only list 2.0.2 in xenial
<apw> didrocks, 2.32.3.2 was replaced by 2.32.9 ?
<enyc> Query on tracking-down an installer-annoyance...  In 18.04 installer custom partitioning  keeps "auto-mounting" linuxswap-partitions (even if manually onmounted before starting ubiquity)..   This makes creating a new crypto partition impossible, it complains about unsafe-swap mounted etc...  and/or other failure cases --    Any idea if this is acutalyl a ubiquity-issue  or some underpinning
<apw>  snapd | 2.32.9              | xenial-updates          | source
<enyc> udev/systemd/whatever thats' setup for live-cd-mode that does stuff upon rescanning ptbl etc?.
<didrocks> apw: interesting, my rmadison doesn't list it. Context is the CI failing (just tried to rerun it): https://travis-ci.org/ubuntu/gtk-communitheme/builds/387507958
<didrocks> ah sorry, -updates are listed after archives
<apw> didrocks, yes it does, i just pasted the line from it
<didrocks> ok, can be the docker container not up to date
 * didrocks looks at snapcraft docker contain
<apw> ordered by version number i believe
<apw> and so confusingly ordered for things where we backport en-toto
<didrocks> apw: oh, correct, version number, was a trap as not used to that with other debs :)
<didrocks> yeah
<didrocks> ok, the snapcraft docker container is failing for 4 days
<didrocks> thanks apw, that explains it
<apw> didrocks, that is consistent with the release of it
-queuebot:#ubuntu-release- New binary: golang-github-satta-ifplugo [amd64] (cosmic-proposed/none) [0.0~git20180516.4249335-1] (no packageset)
-queuebot:#ubuntu-release- New binary: yaml-mode [amd64] (cosmic-proposed/universe) [0.0.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-throttled-throttled [amd64] (cosmic-proposed/none) [2.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-olivere-elastic.v5 [amd64] (cosmic-proposed/universe) [5.0.69-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mcomix [amd64] (cosmic-proposed/universe) [1.2.1-1.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (bionic-proposed) [18.0.5-0ubuntu0~18.04.1]
-queuebot:#ubuntu-release- Unapproved: python-oslo.versionedobjects (xenial-proposed/main) [1.8.0-1 => 1.8.0-1ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted makedumpfile [source] (artful-proposed) [1:1.6.3-2~17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted kexec-tools [source] (artful-proposed) [1:2.0.16-1ubuntu1~17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted kexec-tools [source] (xenial-proposed) [1:2.0.16-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New binary: magnum [amd64] (cosmic-proposed/universe) [6.1.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted makedumpfile [source] (xenial-proposed) [1:1.6.3-2~16.04.1]
-queuebot:#ubuntu-release- New: accepted golang-github-satta-ifplugo [amd64] (cosmic-proposed) [0.0~git20180516.4249335-1]
-queuebot:#ubuntu-release- New: accepted yaml-mode [amd64] (cosmic-proposed) [0.0.13-1]
-queuebot:#ubuntu-release- New: accepted golang-github-throttled-throttled [amd64] (cosmic-proposed) [2.2.1-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-olivere-elastic.v5 [amd64] (cosmic-proposed) [5.0.69-1]
-queuebot:#ubuntu-release- New: accepted mcomix [amd64] (cosmic-proposed) [1.2.1-1.1]
-queuebot:#ubuntu-release- New: accepted magnum [amd64] (cosmic-proposed) [6.1.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: debhelper (bionic-proposed/main) [11.1.6ubuntu2 => 11.1.6ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: debhelper (artful-proposed/main) [10.7.2ubuntu2 => 10.7.2ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: debhelper (xenial-proposed/main) [10.2.2ubuntu1~ubuntu16.04.1 => 9.20160115ubuntu4] (core)
-queuebot:#ubuntu-release- New binary: ruby-bootsnap [ppc64el] (cosmic-proposed/none) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gammapy [ppc64el] (cosmic-proposed/none) [0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lwip [ppc64el] (cosmic-proposed/none) [2.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-classint [ppc64el] (cosmic-proposed/none) [0.2-3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpdl-vectorvalued-perl [ppc64el] (cosmic-proposed/none) [1.0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nftlb [ppc64el] (cosmic-proposed/none) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hunspell-lv [amd64] (cosmic-proposed/none) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libnet-ssh-authorizedkeysfile-perl [amd64] (cosmic-proposed/none) [0.18-2] (no packageset)
-queuebot:#ubuntu-release- New binary: lwip [armhf] (cosmic-proposed/none) [2.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nftlb [s390x] (cosmic-proposed/none) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-classint [s390x] (cosmic-proposed/none) [0.2-3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhttp-tiny-multipart-perl [amd64] (cosmic-proposed/none) [0.08-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lwip [s390x] (cosmic-proposed/none) [2.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-bootsnap [s390x] (cosmic-proposed/none) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libsoftware-licensemoreutils-perl [amd64] (cosmic-proposed/none) [0.004-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-sprintf-js [amd64] (cosmic-proposed/universe) [1.1.1+ds1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: lwip [amd64] (cosmic-proposed/none) [2.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lwip [i386] (cosmic-proposed/none) [2.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nftlb [arm64] (cosmic-proposed/none) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nftlb [i386] (cosmic-proposed/none) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-bootsnap [amd64] (cosmic-proposed/none) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lwip [arm64] (cosmic-proposed/none) [2.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nftlb [armhf] (cosmic-proposed/none) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nftlb [amd64] (cosmic-proposed/none) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-dygraphs [amd64] (cosmic-proposed/none) [1.1.1.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpdl-vectorvalued-perl [s390x] (cosmic-proposed/universe) [1.0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-keggrest [amd64] (cosmic-proposed/universe) [1.20.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-classint [arm64] (cosmic-proposed/universe) [0.2-3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-prediction [amd64] (cosmic-proposed/universe) [0.3.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-bootsnap [arm64] (cosmic-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpod-minimumversion-perl [amd64] (cosmic-proposed/universe) [50-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-classint [armhf] (cosmic-proposed/universe) [0.2-3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-bootsnap [i386] (cosmic-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-classint [amd64] (cosmic-proposed/universe) [0.2-3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pwr [amd64] (cosmic-proposed/universe) [1.2-2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libdist-zilla-role-modulemetadata-perl [amd64] (cosmic-proposed/universe) [0.006-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-fastcgi-stream [amd64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-postcss-colormin [amd64] (cosmic-proposed/universe) [2.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-bootsnap [armhf] (cosmic-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpdl-vectorvalued-perl [arm64] (cosmic-proposed/universe) [1.0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-classint [i386] (cosmic-proposed/universe) [0.2-3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-fastcgi [amd64] (cosmic-proposed/universe) [1.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpdl-vectorvalued-perl [armhf] (cosmic-proposed/universe) [1.0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpdl-vectorvalued-perl [i386] (cosmic-proposed/universe) [1.0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-epc [amd64] (cosmic-proposed/universe) [0.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gammapy [arm64] (cosmic-proposed/universe) [0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpdl-vectorvalued-perl [amd64] (cosmic-proposed/universe) [1.0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libalgorithm-naivebayes-perl [amd64] (cosmic-proposed/universe) [0.04-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-bufferlist [amd64] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
<cyphermox> tsimonq2: ack
-queuebot:#ubuntu-release- New binary: gammapy [amd64] (cosmic-proposed/universe) [0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gatb-core [amd64] (cosmic-proposed/universe) [1.4.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: netplan.io (bionic-proposed/main) [0.36.2 => 0.38] (core)
-queuebot:#ubuntu-release- New: accepted gatb-core [amd64] (cosmic-proposed) [1.4.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libdist-zilla-role-modulemetadata-perl [amd64] (cosmic-proposed) [0.006-1]
-queuebot:#ubuntu-release- New: accepted libpod-minimumversion-perl [amd64] (cosmic-proposed) [50-1]
-queuebot:#ubuntu-release- New: accepted python-epc [amd64] (cosmic-proposed) [0.0.5-1]
-queuebot:#ubuntu-release- New: accepted libalgorithm-naivebayes-perl [amd64] (cosmic-proposed) [0.04-1]
-queuebot:#ubuntu-release- New: accepted node-bufferlist [amd64] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted libpdl-vectorvalued-perl [amd64] (cosmic-proposed) [1.0.9-1]
-queuebot:#ubuntu-release- New: accepted libhttp-tiny-multipart-perl [amd64] (cosmic-proposed) [0.08-1]
-queuebot:#ubuntu-release- New: accepted libnet-ssh-authorizedkeysfile-perl [amd64] (cosmic-proposed) [0.18-2]
-queuebot:#ubuntu-release- New: accepted r-cran-dygraphs [amd64] (cosmic-proposed) [1.1.1.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ruby-bootsnap [arm64] (cosmic-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-bootsnap [i386] (cosmic-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-bootsnap [amd64] (cosmic-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-bootsnap [s390x] (cosmic-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-bootsnap [armhf] (cosmic-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted node-fastcgi-stream [amd64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-postcss-colormin [amd64] (cosmic-proposed) [2.2.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-classint [amd64] (cosmic-proposed) [0.2-3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-classint [i386] (cosmic-proposed) [0.2-3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-prediction [amd64] (cosmic-proposed) [0.3.6-2]
-queuebot:#ubuntu-release- New: accepted node-fastcgi [amd64] (cosmic-proposed) [1.3.3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-classint [arm64] (cosmic-proposed) [0.2-3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pwr [amd64] (cosmic-proposed) [1.2-2-2]
-queuebot:#ubuntu-release- New: accepted r-bioc-keggrest [amd64] (cosmic-proposed) [1.20.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-classint [s390x] (cosmic-proposed) [0.2-3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-classint [ppc64el] (cosmic-proposed) [0.2-3-1]
-queuebot:#ubuntu-release- New: accepted ruby-bootsnap [ppc64el] (cosmic-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted hunspell-lv [amd64] (cosmic-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted nftlb [arm64] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted nftlb [i386] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted nftlb [s390x] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted nftlb [amd64] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted nftlb [ppc64el] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted nftlb [armhf] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted node-sprintf-js [amd64] (cosmic-proposed) [1.1.1+ds1-3]
-queuebot:#ubuntu-release- New: accepted libpdl-vectorvalued-perl [arm64] (cosmic-proposed) [1.0.9-1]
-queuebot:#ubuntu-release- New: accepted libpdl-vectorvalued-perl [i386] (cosmic-proposed) [1.0.9-1]
-queuebot:#ubuntu-release- New: accepted libpdl-vectorvalued-perl [s390x] (cosmic-proposed) [1.0.9-1]
-queuebot:#ubuntu-release- New: accepted libpdl-vectorvalued-perl [armhf] (cosmic-proposed) [1.0.9-1]
-queuebot:#ubuntu-release- New: accepted libsoftware-licensemoreutils-perl [amd64] (cosmic-proposed) [0.004-1]
-queuebot:#ubuntu-release- New: accepted libpdl-vectorvalued-perl [ppc64el] (cosmic-proposed) [1.0.9-1]
-queuebot:#ubuntu-release- New: accepted gammapy [amd64] (cosmic-proposed) [0.7-1]
-queuebot:#ubuntu-release- New: accepted gammapy [ppc64el] (cosmic-proposed) [0.7-1]
-queuebot:#ubuntu-release- New: accepted lwip [arm64] (cosmic-proposed) [2.0.3-1]
-queuebot:#ubuntu-release- New: accepted lwip [i386] (cosmic-proposed) [2.0.3-1]
-queuebot:#ubuntu-release- New: accepted lwip [s390x] (cosmic-proposed) [2.0.3-1]
-queuebot:#ubuntu-release- New: accepted gammapy [arm64] (cosmic-proposed) [0.7-1]
-queuebot:#ubuntu-release- New: accepted lwip [armhf] (cosmic-proposed) [2.0.3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-classint [armhf] (cosmic-proposed) [0.2-3-1]
-queuebot:#ubuntu-release- New: accepted lwip [amd64] (cosmic-proposed) [2.0.3-1]
-queuebot:#ubuntu-release- New: accepted lwip [ppc64el] (cosmic-proposed) [2.0.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted falkon [source] (bionic-proposed) [3.0.1-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (artful-proposed/partner) [201.0.0-0ubuntu1~17.10.0 => 201.0.0-0ubuntu2~17.10.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (bionic-proposed/partner) [201.0.0-0ubuntu1~18.04.0 => 201.0.0-0ubuntu2~18.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (trusty-proposed/partner) [201.0.0-0ubuntu1~14.04.0 => 201.0.0-0ubuntu2~14.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (xenial-proposed/partner) [201.0.0-0ubuntu1~16.04.0 => 201.0.0-0ubuntu2~16.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (artful-proposed) [201.0.0-0ubuntu2~17.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (bionic-proposed) [201.0.0-0ubuntu2~18.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (trusty-proposed) [201.0.0-0ubuntu2~14.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (xenial-proposed) [201.0.0-0ubuntu2~16.04.0]
<cyphermox> sil2100: livecd-rootfs is blocked on some issues with the ubuntu-image autopkgtests, it looks to me like something unrelated busted
<cyphermox> sil2100: could you please ahve a look and confirm, and if so, could you please badtest this one?
<cyphermox> ie. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/amd64/u/ubuntu-image/20180530_141845_72a9e@/log.gz
<sil2100> cyphermox: sure
<sil2100> Give me a moment
<sil2100> huh
<sil2100> Indeed, something busted our test suite, damn
<sil2100> Let me fill in a bug and hint it for now
<cyphermox> sounds kernely.
<cyphermox> "/sys/firmware/dmi/tables/smbios_entry_point: Permission denied"
<cyphermox> at least that's what the issue is on amd64
<sil2100> cyphermox: done
<sil2100> Yeah, it's that for x86 machines + some snap prepare-image issues everywhere, I filled in two bugs for those
<sil2100> Will have to prioritize those
-queuebot:#ubuntu-release- Unapproved: rejected netplan.io [source] (bionic-proposed) [0.38]
<cyphermox> ok
-queuebot:#ubuntu-release- Unapproved: nplan (xenial-proposed/universe) [0.32~16.04.5 => 0.32~16.04.6] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libservicelog [source] (xenial-proposed) [1.1.16-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02-2ubuntu9 => 2.02-2ubuntu9] (core)
<bdmurray> xnox: I bumped the open-iscsi badtest hint. What is up with the network-manager tests?
<xnox> bdmurray, wrote an email about the revert of artful.
<bdmurray> xnox: great, thanks!
<xnox> bdmurray, network-manager tests Wifi b standard, which is pre-historic. and I wish it would stop testing acient wifi standards =)
<xnox> bdmurray, and it racy timesout on things.
<xnox> as far as I remember
<sarnold> "pre-historic"
<sarnold> .. and here I am still impressed that we can have networking without wires
<xnox> bdmurray, see netplan, trying to test network-manager and asserting how racy it is
<xnox> sarnold, i went to Science Museum and could not understand what the mouse with a ball was. I thought it was a digitalizer to like measure distance / speed.
-queuebot:#ubuntu-release- New binary: golang-github-howeyc-fsnotify [amd64] (cosmic-proposed/universe) [0.9.0+git20151003.f0c08ee-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-dirichletmultinomial [ppc64el] (cosmic-proposed/universe) [1.22.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ei [amd64] (cosmic-proposed/universe) [1.3-3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-dirichletmultinomial [amd64] (cosmic-proposed/universe) [1.22.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-threejs [amd64] (cosmic-proposed/universe) [0.3.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-bayesplot [amd64] (cosmic-proposed/universe) [1.5.0-1] (no packageset)
<sarnold> xnox: well... it *did* sort of measure distance and speed.. :)
-queuebot:#ubuntu-release- New binary: r-bioc-dirichletmultinomial [i386] (cosmic-proposed/universe) [1.22.0-1] (no packageset)
<sarnold> it also measured  how much gunk you had on your desk. did the museum have an interactive "remove the gunk from the rollers" section to the exhibit? :)
-queuebot:#ubuntu-release- New binary: r-cran-colourpicker [amd64] (cosmic-proposed/universe) [1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-dirichletmultinomial [armhf] (cosmic-proposed/universe) [1.22.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-dirichletmultinomial [arm64] (cosmic-proposed/universe) [1.22.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-dirichletmultinomial [s390x] (cosmic-proposed/universe) [1.22.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-lambdabot-haskell-plugins [amd64] (cosmic-proposed/universe) [5.1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-lambdabot-haskell-plugins [i386] (cosmic-proposed/universe) [5.1.0.2-1] (no packageset)
#ubuntu-release 2018-06-05
-queuebot:#ubuntu-release- New binary: haskell-lambdabot-haskell-plugins [ppc64el] (cosmic-proposed/universe) [5.1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-lambdabot-haskell-plugins [arm64] (cosmic-proposed/universe) [5.1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-lambdabot-haskell-plugins [s390x] (cosmic-proposed/universe) [5.1.0.2-1] (no packageset)
<slangasek> ginggs: I don't suppose you have any insight into the haskell-cryptonite/armhf build failure?  it blocks lots of things, including pandoc -> osmcoastline -> gdal
<ginggs> slangasek: sorry, no idea about haskell stuff
<ginggs> LocutusOfBorg: were you looking at haskell?
-queuebot:#ubuntu-release- New: accepted r-cran-bayesplot [amd64] (cosmic-proposed) [1.5.0-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-dirichletmultinomial [amd64] (cosmic-proposed) [1.22.0-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-dirichletmultinomial [armhf] (cosmic-proposed) [1.22.0-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-dirichletmultinomial [ppc64el] (cosmic-proposed) [1.22.0-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-dirichletmultinomial [arm64] (cosmic-proposed) [1.22.0-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-dirichletmultinomial [s390x] (cosmic-proposed) [1.22.0-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-dirichletmultinomial [i386] (cosmic-proposed) [1.22.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-howeyc-fsnotify [amd64] (cosmic-proposed) [0.9.0+git20151003.f0c08ee-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ei [amd64] (cosmic-proposed) [1.3-3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-threejs [amd64] (cosmic-proposed) [0.3.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-colourpicker [amd64] (cosmic-proposed) [1.0+dfsg-1]
-queuebot:#ubuntu-release- New binary: r-cran-zeligei [amd64] (cosmic-proposed/universe) [0.1-2-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gst-libav1.0 (bionic-proposed/universe) [1.14.0-1 => 1.14.1-1~ubuntu18.04.1] (kubuntu) (sync)
-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) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-ugly1.0 (bionic-proposed/universe) [1.14.0-1 => 1.14.1-1~ubuntu18.04.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-rtsp-server1.0 (bionic-proposed/universe) [1.14.0-1 => 1.14.1-1~ubuntu18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gstreamer-vaapi (bionic-proposed/universe) [1.14.0-1 => 1.14.1-1~ubuntu18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-bad1.0 (bionic-proposed/universe) [1.14.0-1ubuntu1 => 1.14.1-1ubuntu1~ubuntu18.04.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-python1.0 (bionic-proposed/universe) [1.14.0-1 => 1.14.1-1~ubuntu18.04.1] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: gstreamer1.0 (bionic-proposed/main) [1.14.0-1 => 1.14.1-1~ubuntu18.04.1] (desktop-core, ubuntu-server) (sync)
-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) (sync)
-queuebot:#ubuntu-release- Unapproved: gstreamer-editing-services1.0 (bionic-proposed/universe) [1.14.0-1 => 1.14.1-1~ubuntu18.04.1] (ubuntustudio) (sync)
<Laney> soz for the copies :'(
<apw> bah copies
-queuebot:#ubuntu-release- New: accepted r-cran-zeligei [amd64] (cosmic-proposed) [0.1-2-1]
-queuebot:#ubuntu-release- New: accepted haskell-lambdabot-haskell-plugins [amd64] (cosmic-proposed) [5.1.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-lambdabot-haskell-plugins [i386] (cosmic-proposed) [5.1.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-lambdabot-haskell-plugins [s390x] (cosmic-proposed) [5.1.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-lambdabot-haskell-plugins [arm64] (cosmic-proposed) [5.1.0.2-1]
-queuebot:#ubuntu-release- New: accepted haskell-lambdabot-haskell-plugins [ppc64el] (cosmic-proposed) [5.1.0.2-1]
<apw> didrocks, your bionic ubuntu-report upload has some apparently travis related files in it, is that expected ?
<didrocks> apw: hum, are they new files? I thought I already shipped them
<didrocks> let me check
<didrocks> (but yeah, there is a .travis.yml on the repo, I can ignore it if needed)
-queuebot:#ubuntu-release- Unapproved: quota (bionic-proposed/main) [4.04-2 => 4.04-2ubuntu0.1] (core)
<didrocks> apw: yeah, the file was already there. The diff is for me to generate binaries on release automatically for other consumers (if any) as part of the CI
<didrocks> the travis file isn't installed anyway
<apw> didrocks, ok
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (cosmic-proposed) [2.02-2ubuntu9]
-queuebot:#ubuntu-release- New binary: r-cran-zeligverse [amd64] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gdm3 (bionic-proposed/main) [3.28.2-0ubuntu1.1 => 3.28.2-0ubuntu1.2] (ubuntu-desktop)
<Laney> that one is the third go at fixing this effing login problem
-queuebot:#ubuntu-release- New: accepted r-cran-zeligverse [amd64] (cosmic-proposed) [0.1.1-1]
<LocutusOfBorg> ginggs, no idea for haskell
<LocutusOfBorg> slangasek, pandoc is sad for other reasons
<LocutusOfBorg> endianess failure on haskell-cmark-gfm is the main pandoc reason
<LocutusOfBorg> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897001
<ubot5> Debian bug 897001 in libghc-cmark-gfm-dev "libghc-cmark-gfm-dev: not big-endian-safe" [Serious,Open]
-queuebot:#ubuntu-release- Unapproved: libglvnd (bionic-proposed/main) [1.0.0-2ubuntu2 => 1.0.0-2ubuntu2.1] (core)
-queuebot:#ubuntu-release- New binary: libmaa [amd64] (cosmic-proposed/main) [1.4.2-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libmaa [s390x] (cosmic-proposed/main) [1.4.2-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libmaa [ppc64el] (cosmic-proposed/main) [1.4.2-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libmaa [i386] (cosmic-proposed/main) [1.4.2-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnuastro [s390x] (cosmic-proposed/universe) [0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmaa [arm64] (cosmic-proposed/main) [1.4.2-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libmaa [armhf] (cosmic-proposed/main) [1.4.2-1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: burrow [ppc64el] (cosmic-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pywebdav [amd64] (cosmic-proposed/universe) [0.9.11~git20180601.5d7d16a-1] (no packageset)
-queuebot:#ubuntu-release- New binary: burrow [s390x] (cosmic-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: imv [ppc64el] (cosmic-proposed/universe) [3.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: imv [s390x] (cosmic-proposed/universe) [3.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-bibtex [ppc64el] (cosmic-proposed/universe) [0.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: postgresql-numeral [ppc64el] (cosmic-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: freeture [ppc64el] (cosmic-proposed/universe) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-metamix [ppc64el] (cosmic-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: freeture [s390x] (cosmic-proposed/universe) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: postgresql-numeral [s390x] (cosmic-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-metamix [s390x] (cosmic-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libmaa [amd64] (cosmic-proposed) [1.4.2-1]
-queuebot:#ubuntu-release- New: accepted libmaa [armhf] (cosmic-proposed) [1.4.2-1]
-queuebot:#ubuntu-release- New: accepted libmaa [ppc64el] (cosmic-proposed) [1.4.2-1]
-queuebot:#ubuntu-release- New: accepted libmaa [arm64] (cosmic-proposed) [1.4.2-1]
-queuebot:#ubuntu-release- New: accepted libmaa [s390x] (cosmic-proposed) [1.4.2-1]
-queuebot:#ubuntu-release- New: accepted libmaa [i386] (cosmic-proposed) [1.4.2-1]
-queuebot:#ubuntu-release- New: accepted pywebdav [amd64] (cosmic-proposed) [0.9.11~git20180601.5d7d16a-1]
-queuebot:#ubuntu-release- New binary: burrow [amd64] (cosmic-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: postgresql-numeral [amd64] (cosmic-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: burrow [i386] (cosmic-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: imv [amd64] (cosmic-proposed/universe) [3.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-bibtex [amd64] (cosmic-proposed/universe) [0.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: postgresql-numeral [i386] (cosmic-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-bibtex [i386] (cosmic-proposed/universe) [0.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-metamix [i386] (cosmic-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lava [amd64] (cosmic-proposed/universe) [2018.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-metamix [amd64] (cosmic-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-googlediff [amd64] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-pikaday [amd64] (cosmic-proposed/universe) [1.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-ifvisible.js [amd64] (cosmic-proposed/universe) [1.0.6+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libperl-critic-pulp-perl [amd64] (cosmic-proposed/universe) [96-1] (no packageset)
-queuebot:#ubuntu-release- New binary: freeture [i386] (cosmic-proposed/universe) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: opgpcard [amd64] (cosmic-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-fs-vacuum [amd64] (cosmic-proposed/universe) [1.2.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: imv [i386] (cosmic-proposed/universe) [3.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuastro [ppc64el] (cosmic-proposed/universe) [0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-classnames [amd64] (cosmic-proposed/universe) [2.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: burrow [armhf] (cosmic-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: imv [arm64] (cosmic-proposed/universe) [3.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: postgresql-numeral [arm64] (cosmic-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuastro [amd64] (cosmic-proposed/universe) [0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: imv [armhf] (cosmic-proposed/universe) [3.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: postgresql-numeral [armhf] (cosmic-proposed/universe) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted freeture [i386] (cosmic-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted freeture [s390x] (cosmic-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted freeture [ppc64el] (cosmic-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New binary: jameica [amd64] (cosmic-proposed/universe) [2.8.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted lava [amd64] (cosmic-proposed) [2018.5-1]
-queuebot:#ubuntu-release- New binary: cataclysm-dda [s390x] (cosmic-proposed/universe) [0.C+git20180520.620a1f9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cataclysm-dda [ppc64el] (cosmic-proposed/universe) [0.C+git20180520.620a1f9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-bibtex [arm64] (cosmic-proposed/universe) [0.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted libperl-critic-pulp-perl [amd64] (cosmic-proposed) [96-1]
-queuebot:#ubuntu-release- New: accepted node-googlediff [amd64] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted node-pikaday [amd64] (cosmic-proposed) [1.7.0-1]
-queuebot:#ubuntu-release- New binary: r-cran-metamix [arm64] (cosmic-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted node-fs-vacuum [amd64] (cosmic-proposed) [1.2.10-1]
-queuebot:#ubuntu-release- New binary: r-cran-bibtex [armhf] (cosmic-proposed/universe) [0.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted node-ifvisible.js [amd64] (cosmic-proposed) [1.0.6+dfsg-1]
-queuebot:#ubuntu-release- New binary: r-cran-metamix [armhf] (cosmic-proposed/universe) [0.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted jameica [amd64] (cosmic-proposed) [2.8.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted opgpcard [amd64] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted node-classnames [amd64] (cosmic-proposed) [2.2.5-1]
-queuebot:#ubuntu-release- New: accepted postgresql-numeral [amd64] (cosmic-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted postgresql-numeral [armhf] (cosmic-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted postgresql-numeral [ppc64el] (cosmic-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted postgresql-numeral [arm64] (cosmic-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted postgresql-numeral [s390x] (cosmic-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted postgresql-numeral [i386] (cosmic-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-bibtex [amd64] (cosmic-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- New: accepted r-cran-bibtex [armhf] (cosmic-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- New: accepted r-cran-bibtex [ppc64el] (cosmic-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- New: accepted r-cran-metamix [arm64] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-metamix [i386] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-metamix [s390x] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-bibtex [arm64] (cosmic-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- New: accepted r-cran-metamix [amd64] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-metamix [ppc64el] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-bibtex [i386] (cosmic-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- New: accepted r-cran-metamix [armhf] (cosmic-proposed) [0.2-1]
-queuebot:#ubuntu-release- New binary: gnuastro [i386] (cosmic-proposed/universe) [0.6-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: desktop-file-utils (artful-proposed/main) [0.23-1ubuntu3 => 0.23-1ubuntu3.17.10.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: desktop-file-utils (bionic-proposed/main) [0.23-1ubuntu3 => 0.23-1ubuntu3.18.04.1] (desktop-core)
-queuebot:#ubuntu-release- New binary: gnuastro [arm64] (cosmic-proposed/universe) [0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnuastro [armhf] (cosmic-proposed/universe) [0.6-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gnuastro [amd64] (cosmic-proposed) [0.6-1]
-queuebot:#ubuntu-release- New: accepted gnuastro [armhf] (cosmic-proposed) [0.6-1]
-queuebot:#ubuntu-release- New: accepted gnuastro [ppc64el] (cosmic-proposed) [0.6-1]
-queuebot:#ubuntu-release- New: accepted gnuastro [arm64] (cosmic-proposed) [0.6-1]
-queuebot:#ubuntu-release- New: accepted gnuastro [s390x] (cosmic-proposed) [0.6-1]
-queuebot:#ubuntu-release- New: accepted gnuastro [i386] (cosmic-proposed) [0.6-1]
-queuebot:#ubuntu-release- New: accepted imv [amd64] (cosmic-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- New: accepted imv [armhf] (cosmic-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- New: accepted imv [ppc64el] (cosmic-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- New binary: cataclysm-dda [amd64] (cosmic-proposed/universe) [0.C+git20180520.620a1f9-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted imv [arm64] (cosmic-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- New: accepted imv [s390x] (cosmic-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- New: accepted imv [i386] (cosmic-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- New: accepted burrow [amd64] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted burrow [i386] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted burrow [s390x] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted cataclysm-dda [ppc64el] (cosmic-proposed) [0.C+git20180520.620a1f9-1]
-queuebot:#ubuntu-release- New: accepted burrow [armhf] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted cataclysm-dda [amd64] (cosmic-proposed) [0.C+git20180520.620a1f9-1]
-queuebot:#ubuntu-release- New: accepted burrow [ppc64el] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted cataclysm-dda [s390x] (cosmic-proposed) [0.C+git20180520.620a1f9-1]
<cyphermox> slangasek: I have started looking at haskell
<cyphermox> it blocks pandoc, which blocks netplan
<cyphermox> ginggs: ^
<cyphermox> haskell-cryptonite is pretty much next on my list, but I have no prior knowledge of haskell to work with
<infinity> cyphermox: Scroll up, LocutusOfBorg references https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897001 as a blocker for pandoc.
<ubot5> Debian bug 897001 in libghc-cmark-gfm-dev "libghc-cmark-gfm-dev: not big-endian-safe" [Serious,Open]
-queuebot:#ubuntu-release- Unapproved: sosreport (bionic-proposed/main) [3.5-1ubuntu3 => 3.5-1ubuntu3.18.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sosreport (artful-proposed/main) [3.5-1~ubuntu17.10.2 => 3.5-1~ubuntu17.10.3] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sosreport (xenial-proposed/main) [3.5-1~ubuntu16.04.2 => 3.5-1~ubuntu16.04.3] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sosreport (trusty-proposed/main) [3.5-1~ubuntu14.04.2 => 3.5-1~ubuntu14.04.3] (ubuntu-desktop)
<cyphermox> infinity: on top of everything else, yes
<slangasek> infinity: "not big-endian safe" is a blocker for cosmic how?
<infinity> slangasek: If it blocks something else it is?
<infinity> (I haven't looked at the chain, I was just parroting previous conversation)
-queuebot:#ubuntu-release- Unapproved: desktop-file-utils (xenial-proposed/main) [0.22-1ubuntu5.1 => 0.22-1ubuntu5.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: python-pylxd (bionic-proposed/main) [2.2.6-0ubuntu1 => 2.2.6-0ubuntu1.1] (ubuntu-server)
<LocutusOfBorg> cyphermox, slangasek lots of stuff uses pandoc to build documentation
<slangasek> yes, and this is terrible
<LocutusOfBorg> e.g.this one https://launchpad.net/ubuntu/+source/osmcoastline/2.1.4-2build4/+build/14935861
<LocutusOfBorg> can't build on s390x and armhf
<LocutusOfBorg> you mean, pandoc should be arch:all?
<cyphermox> slangasek: terrible looks like a weak word
<LocutusOfBorg> osmcoastline is not multiarch, so the manpage is built and installed in arch:any
<LocutusOfBorg> we might split, but meh
<LocutusOfBorg> fixing pandoc is probably better
<slangasek> I mean that "lots of stuff" shouldn't build-depend on tools written in dodgily-portable languages
<LocutusOfBorg> lol, this is haskell after all :)
-queuebot:#ubuntu-release- Unapproved: python-pylxd (artful-proposed/main) [2.2.4-0ubuntu1 => 2.2.6-0ubuntu0.17.10.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: menu (bionic-proposed/universe) [2.1.47ubuntu2 => 2.1.47ubuntu2.1] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: menu (artful-proposed/universe) [2.1.47ubuntu1 => 2.1.47ubuntu1.17.10.1] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: menu (xenial-proposed/universe) [2.1.47ubuntu1 => 2.1.47ubuntu1.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lxcfs (bionic-proposed/main) [3.0.0-0ubuntu1 => 3.0.1-0ubuntu1~18.04.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- New binary: procps [ppc64el] (cosmic-proposed/main) [2:3.3.15-2ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: procps [s390x] (cosmic-proposed/main) [2:3.3.15-2ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: procps [amd64] (cosmic-proposed/main) [2:3.3.15-2ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: procps [arm64] (cosmic-proposed/main) [2:3.3.15-2ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: procps [armhf] (cosmic-proposed/main) [2:3.3.15-2ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: procps [i386] (cosmic-proposed/main) [2:3.3.15-2ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: lxc (bionic-proposed/main) [3.0.0-0ubuntu2 => 3.0.1-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected lxc [source] (bionic-proposed) [3.0.1-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: lxd (bionic-proposed/main) [3.0.0-0ubuntu4 => 3.0.1-0ubuntu1~18.04.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxc (bionic-proposed/main) [3.0.0-0ubuntu2 => 3.0.1-0ubuntu1~18.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- New: accepted procps [amd64] (cosmic-proposed) [2:3.3.15-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted procps [armhf] (cosmic-proposed) [2:3.3.15-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted procps [ppc64el] (cosmic-proposed) [2:3.3.15-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted procps [arm64] (cosmic-proposed) [2:3.3.15-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted procps [s390x] (cosmic-proposed) [2:3.3.15-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted procps [i386] (cosmic-proposed) [2:3.3.15-2ubuntu1]
-queuebot:#ubuntu-release- New binary: nb2plots [amd64] (cosmic-proposed/universe) [0.6-1] (no packageset)
#ubuntu-release 2018-06-06
-queuebot:#ubuntu-release- Unapproved: accepted budgie-desktop-environment [source] (bionic-proposed) [0.9.9ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.versionedobjects [source] (xenial-proposed) [1.8.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected python-pylxd [source] (artful-proposed) [2.2.6-0ubuntu0.17.10.1]
-queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02-2ubuntu10 => 2.02-2ubuntu10] (core)
-queuebot:#ubuntu-release- Unapproved: accepted desktop-file-utils [source] (xenial-proposed) [0.22-1ubuntu5.2]
-queuebot:#ubuntu-release- Unapproved: accepted desktop-file-utils [source] (artful-proposed) [0.23-1ubuntu3.17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted desktop-file-utils [source] (bionic-proposed) [0.23-1ubuntu3.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted menu [source] (xenial-proposed) [2.1.47ubuntu1.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted menu [source] (artful-proposed) [2.1.47ubuntu1.17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted menu [source] (bionic-proposed) [2.1.47ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted percona-xtradb-cluster-5.7 [source] (bionic-proposed) [5.7.20-29.24-0ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02-2ubuntu10 => 2.02-2ubuntu10] (core)
-queuebot:#ubuntu-release- Unapproved: python-pylxd (bionic-proposed/main) [2.2.6-0ubuntu1 => 2.2.6-0ubuntu1.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cups-pk-helper (bionic-proposed/main) [0.2.6-1ubuntu1.1 => 0.2.6-1ubuntu1.2] (kubuntu, ubuntu-desktop)
<LocutusOfBorg> apw, do you think we can kick virtualbox-hwe out of cosmic? it is needed for lts-lts upgrades
-queuebot:#ubuntu-release- New: accepted nb2plots [amd64] (cosmic-proposed) [0.6-1]
<LocutusOfBorg> cyphermox, please don't create haskell-delta, or notify me so I can upload in debian :)
<cyphermox> LocutusOfBorg: notify, I've patched haskell-gloss, haskell-gloss-rendering, and will likely patch ciper-aes to fix the tests.
<LocutusOfBorg> cyphermox, <3
<LocutusOfBorg> I uploaded haskell-gloss*
<LocutusOfBorg> ciper-aes would be really awesome
<LocutusOfBorg> aes seems a bug in ghc, at least to what I did on porterbox
<LocutusOfBorg> https://github.com/vincenthz/hs-cipher-aes/issues/38
<gitlab-bot> vincenthz bug 38 in hs-cipher-aes "BUS error when running testsuite on armhf (with arm64 kernel)" (comments: 0) [Open]
<ubot5> Error: Could not gather data from Launchpad for bug #38 (https://launchpad.net/bugs/38). The error has been logged
<LocutusOfBorg> this is what I discovered so far
<infinity> LocutusOfBorg: If we remove virtualbox-hwe from cosmic, what's the upgrade path for people with virtualbox-hwe installed in bionic?
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (cosmic-proposed) [2.02-2ubuntu10]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (cosmic-proposed) [2.02-2ubuntu10]
<cyphermox> LocutusOfBorg: yes, that's the issue
-queuebot:#ubuntu-release- New binary: python-defaults [i386] (cosmic-proposed/main) [2.7.15-1] (core)
-queuebot:#ubuntu-release- New binary: python-defaults [ppc64el] (cosmic-proposed/main) [2.7.15-1] (core)
-queuebot:#ubuntu-release- New binary: python-defaults [arm64] (cosmic-proposed/main) [2.7.15-1] (core)
-queuebot:#ubuntu-release- New binary: python-defaults [s390x] (cosmic-proposed/main) [2.7.15-1] (core)
-queuebot:#ubuntu-release- New binary: python-defaults [armhf] (cosmic-proposed/main) [2.7.15-1] (core)
-queuebot:#ubuntu-release- New binary: python-defaults [amd64] (cosmic-proposed/main) [2.7.15-1] (core)
-queuebot:#ubuntu-release- New: accepted python-defaults [amd64] (cosmic-proposed) [2.7.15-1]
-queuebot:#ubuntu-release- New: accepted python-defaults [armhf] (cosmic-proposed) [2.7.15-1]
-queuebot:#ubuntu-release- New: accepted python-defaults [ppc64el] (cosmic-proposed) [2.7.15-1]
-queuebot:#ubuntu-release- New: accepted python-defaults [arm64] (cosmic-proposed) [2.7.15-1]
-queuebot:#ubuntu-release- New: accepted python-defaults [s390x] (cosmic-proposed) [2.7.15-1]
-queuebot:#ubuntu-release- New: accepted python-defaults [i386] (cosmic-proposed) [2.7.15-1]
<cyphermox> LocutusOfBorg: eyes glazing over from all the AES; I will look again at a later point
<LocutusOfBorg> infinity, do we support lts to non-lts upgrades?
<LocutusOfBorg> e.g. what happen to bionic-hwe stack when people go to cosmic?
<infinity> LocutusOfBorg: Of course.
<infinity> LocutusOfBorg: For the kernel, this works because of the package naming.
-queuebot:#ubuntu-release- New binary: solvate [ppc64el] (cosmic-proposed/none) [1.0-2] (no packageset)
<LocutusOfBorg> so maybe I should make virtualbox provide also the hwe packages
<LocutusOfBorg> "Provides:" should be enough...
<LocutusOfBorg> but damn, how to make it work again in the next lts?
<infinity> LocutusOfBorg: linux-image-generic-hwe-16.04 from xenial upgrades to linux-image-generic in yakkety->bionic.  linux-image-generic-hwe-18.04 in bionic upgrades to linux-image-generic in cosmic->FF
<infinity> LocutusOfBorg: Provides does nothing for upgrades.
<infinity> LocutusOfBorg: This works for the kernel because the HWE packages are versioned.  Yours aren't.
-queuebot:#ubuntu-release- New binary: gitlab-ci-mode-el [amd64] (cosmic-proposed/none) [20180306.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-coffee-loader [amd64] (cosmic-proposed/none) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-libnmap [amd64] (cosmic-proposed/none) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jsunit [amd64] (cosmic-proposed/none) [0.1.4+git1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tinyjsd [amd64] (cosmic-proposed/none) [1.2+git1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-compare-versions [amd64] (cosmic-proposed/none) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-flow-remove-types [amd64] (cosmic-proposed/none) [1.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libperl-critic-freenode-perl [amd64] (cosmic-proposed/none) [0.026-1] (no packageset)
-queuebot:#ubuntu-release- New binary: solvate [amd64] (cosmic-proposed/none) [1.0-2] (no packageset)
<LocutusOfBorg> soooo what can I do? continue to maintain virtualbox-hwe is one option...
-queuebot:#ubuntu-release- New binary: python-icecream [amd64] (cosmic-proposed/none) [1.3-1] (no packageset)
<infinity> LocutusOfBorg: Make virtuabox-*-hwe packages in non-LTS be metapackages that install the non-hwe version?
-queuebot:#ubuntu-release- New binary: node-md5-hex [amd64] (cosmic-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rio [amd64] (cosmic-proposed/none) [0.5.10-2] (no packageset)
-queuebot:#ubuntu-release- New binary: sadisplay [amd64] (cosmic-proposed/none) [0.4.9-1] (no packageset)
<infinity> LocutusOfBorg: But it would be better if you had followed the kernel naming scheme, so they roll until the next LTS and stop.
-queuebot:#ubuntu-release- New binary: r-cran-blme [amd64] (cosmic-proposed/none) [1.0-4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-vcr [amd64] (cosmic-proposed/none) [0.1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: solvate [i386] (cosmic-proposed/none) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: solvate [arm64] (cosmic-proposed/multiverse) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: solvate [armhf] (cosmic-proposed/multiverse) [1.0-2] (no packageset)
 * LocutusOfBorg uploads vbox-hwe
<LocutusOfBorg> the meta-package should be reverted at each LTS and then reverted back...
<infinity> LocutusOfBorg: The problem with that is that you're assuming people who wanted -hwe in 16.04 also want it in 18.04 and 20.04
<infinity> LocutusOfBorg: Whereas the kernel makes the inverse assumption.
<infinity> LocutusOfBorg: If you install an hwe kernel in 16.04, you get the GA kernel in 18.04 until you explicitly select hwe again.
-queuebot:#ubuntu-release- New binary: solvate [s390x] (cosmic-proposed/multiverse) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted vte2.91 [source] (bionic-proposed) [0.52.2-1ubuntu1~18.04.1]
-queuebot:#ubuntu-release- New: accepted gitlab-ci-mode-el [amd64] (cosmic-proposed) [20180306.1-1]
-queuebot:#ubuntu-release- New: accepted libperl-critic-freenode-perl [amd64] (cosmic-proposed) [0.026-1]
-queuebot:#ubuntu-release- New: accepted node-compare-versions [amd64] (cosmic-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted node-md5-hex [amd64] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted python-libnmap [amd64] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted solvate [arm64] (cosmic-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted solvate [i386] (cosmic-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted solvate [s390x] (cosmic-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted jsunit [amd64] (cosmic-proposed) [0.1.4+git1-1]
-queuebot:#ubuntu-release- New: accepted node-flow-remove-types [amd64] (cosmic-proposed) [1.2.3-1]
-queuebot:#ubuntu-release- New: accepted solvate [amd64] (cosmic-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted solvate [ppc64el] (cosmic-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted node-coffee-loader [amd64] (cosmic-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted solvate [armhf] (cosmic-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted python-icecream [amd64] (cosmic-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted tinyjsd [amd64] (cosmic-proposed) [1.2+git1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-blme [amd64] (cosmic-proposed) [1.0-4-1]
-queuebot:#ubuntu-release- New: accepted r-cran-vcr [amd64] (cosmic-proposed) [0.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rio [amd64] (cosmic-proposed) [0.5.10-2]
-queuebot:#ubuntu-release- New: accepted sadisplay [amd64] (cosmic-proposed) [0.4.9-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-terminal [source] (bionic-proposed) [3.28.2-1ubuntu1~18.04.1]
-queuebot:#ubuntu-release- New binary: node-cosmiconfig [amd64] (cosmic-proposed/universe) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mertools [amd64] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-defaults [ppc64el] (cosmic-proposed/main) [2.7.15-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: python-defaults [s390x] (cosmic-proposed/main) [2.7.15-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: python-defaults [amd64] (cosmic-proposed/main) [2.7.15-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: python-defaults [i386] (cosmic-proposed/main) [2.7.15-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: python-defaults [armhf] (cosmic-proposed/main) [2.7.15-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: python-defaults [arm64] (cosmic-proposed/main) [2.7.15-1ubuntu1] (core)
-queuebot:#ubuntu-release- New: accepted node-cosmiconfig [amd64] (cosmic-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted python-defaults [arm64] (cosmic-proposed) [2.7.15-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-defaults [i386] (cosmic-proposed) [2.7.15-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-defaults [s390x] (cosmic-proposed) [2.7.15-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-defaults [amd64] (cosmic-proposed) [2.7.15-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-defaults [ppc64el] (cosmic-proposed) [2.7.15-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted python-defaults [armhf] (cosmic-proposed) [2.7.15-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted r-cran-mertools [amd64] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New binary: python-defaults [i386] (cosmic-proposed/main) [2.7.15-1ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: python-defaults [s390x] (cosmic-proposed/main) [2.7.15-1ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: python-defaults [ppc64el] (cosmic-proposed/main) [2.7.15-1ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: python-defaults [amd64] (cosmic-proposed/main) [2.7.15-1ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: python-defaults [armhf] (cosmic-proposed/main) [2.7.15-1ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: python-defaults [arm64] (cosmic-proposed/main) [2.7.15-1ubuntu2] (core)
-queuebot:#ubuntu-release- New: accepted python-defaults [amd64] (cosmic-proposed) [2.7.15-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted python-defaults [armhf] (cosmic-proposed) [2.7.15-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted python-defaults [ppc64el] (cosmic-proposed) [2.7.15-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted python-defaults [arm64] (cosmic-proposed) [2.7.15-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted python-defaults [s390x] (cosmic-proposed) [2.7.15-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted python-defaults [i386] (cosmic-proposed) [2.7.15-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: libdrm (xenial-proposed/main) [2.4.83-1~16.04.1 => 2.4.91-2~16.04.1] (core, xorg)
-queuebot:#ubuntu-release- New source: llvm-toolchain-6.0 (xenial-proposed/primary) [1:6.0-1ubuntu2~16.04.1]
-queuebot:#ubuntu-release- New binary: libxkbcommon [amd64] (cosmic-proposed/main) [0.8.0-2] (core, xorg)
-queuebot:#ubuntu-release- New binary: python-defaults [amd64] (cosmic-proposed/main) [2.7.15-2] (core)
-queuebot:#ubuntu-release- New binary: python-defaults [s390x] (cosmic-proposed/main) [2.7.15-2] (core)
-queuebot:#ubuntu-release- New binary: python-defaults [arm64] (cosmic-proposed/main) [2.7.15-2] (core)
-queuebot:#ubuntu-release- New binary: python-defaults [ppc64el] (cosmic-proposed/main) [2.7.15-2] (core)
-queuebot:#ubuntu-release- New binary: python-defaults [i386] (cosmic-proposed/main) [2.7.15-2] (core)
-queuebot:#ubuntu-release- New binary: python-defaults [armhf] (cosmic-proposed/main) [2.7.15-2] (core)
-queuebot:#ubuntu-release- New: accepted libxkbcommon [amd64] (cosmic-proposed) [0.8.0-2]
-queuebot:#ubuntu-release- New: accepted python-defaults [arm64] (cosmic-proposed) [2.7.15-2]
-queuebot:#ubuntu-release- New: accepted python-defaults [i386] (cosmic-proposed) [2.7.15-2]
-queuebot:#ubuntu-release- New: accepted python-defaults [s390x] (cosmic-proposed) [2.7.15-2]
-queuebot:#ubuntu-release- New: accepted python-defaults [amd64] (cosmic-proposed) [2.7.15-2]
-queuebot:#ubuntu-release- New: accepted python-defaults [ppc64el] (cosmic-proposed) [2.7.15-2]
-queuebot:#ubuntu-release- New: accepted python-defaults [armhf] (cosmic-proposed) [2.7.15-2]
#ubuntu-release 2018-06-07
<cyphermox> LocutusOfBorg: haskell-src-exts-util
<cyphermox> ^ fixed to not download stuff.
-queuebot:#ubuntu-release- New binary: manila [amd64] (cosmic-proposed/universe) [1:6.0.0-2ubuntu1] (openstack)
<sarnold> cyphermox: is that a general "don't fetch things in autopkgtest" fix? or is that more a temporary workaround for a specific problem? bundler goes to the web to download things.. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/amd64/b/bundler/20180531_165848_e8fef@/log.gz
-queuebot:#ubuntu-release- New binary: mistral [amd64] (cosmic-proposed/universe) [6.0.0-3ubuntu1] (no packageset)
<cyphermox> sarnold: it's a 'permanent workaround' for buildtime downloading stuff (which is obviously not allowed)
<cyphermox> specific to haskell
<cyphermox> (and I don't really know what I'm doing, just bumbling through to try to unblock things for me)
<cyphermox> sarnold: I think the bundler call is missing --local for that test
<cyphermox> LocutusOfBorg: I'll have already sent the patch to debian for haskell-src-exts-util; and I'll do that for the other things, so I won't keep notifying you of changes
<sarnold> cyphermox: aha, I hadn't realized it was a different type of thing entirely. thanks
<sarnold> cyphermox: thanks, 1775505 for bundler
<LocutusOfBorg> infinity, meh, in the next LTS, the hwe is really the same as the normal one, because the xorg-hwe is a meta-package, once xorg-hwe upgrades, the vbox-hwe changes too, it depends on the user being stuck to xorg-hwe or the normal one, so, I really have to follow them
<LocutusOfBorg> you can't install the -hwe package without the xorg-hwe one and I can't force a xorg downgrade
<LocutusOfBorg> cyphermox, uploading stuff in debian
<LocutusOfBorg> please at least call them "build1" instead of ubuntu1
<LocutusOfBorg> so they are directly syncable automagically
<LocutusOfBorg> cyphermox, haskell-iso8601-time fixed probably too
<LocutusOfBorg> slangasek, good morning, can you please kick haskell-twitter-types? we removed haskell-derive, we should kick it too because it depends on it (maybe just move to proposed, so once derive is fixed it can come back automagically)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [0.6.5.6-0ubuntu21 => 0.6.5.6-0ubuntu22] (no packageset)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (artful-proposed/main) [0.6.5.11-1ubuntu3.4 => 0.6.5.11-1ubuntu3.5] (core)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (bionic-proposed/main) [0.7.5-1ubuntu16 => 0.7.5-1ubuntu16.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (bionic-proposed) [0.7.5-1ubuntu16.1]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (artful-proposed) [0.6.5.11-1ubuntu3.5]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (xenial-proposed) [0.6.5.6-0ubuntu22]
-queuebot:#ubuntu-release- New binary: bolt-lmm [amd64] (cosmic-proposed/universe) [2.3.2+dfsg-2] (no packageset)
<Trevinho> bdmurray: hey could you please unblock https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1766137 fix from the SRU queue?
<ubot5> Ubuntu bug 1766137 in gdm3 (Ubuntu Bionic) "[regression] Password accepted but login fails (blank purple screen and mouse pointer only)" [High,In progress]
-queuebot:#ubuntu-release- New binary: gemma [amd64] (cosmic-proposed/universe) [0.97+dfsg-2] (no packageset)
<LocutusOfBorg> please remove haskell-conduit-combinators? it has been removed from Debian
<LocutusOfBorg> also haskell-twitter-types-lens should be demoted to -proposed (missing haskell-derive)
<LocutusOfBorg> haskell-twitter-types haskell-twitter-types-lens --> move to -proposed, remove haskell-conduit-combinators
-queuebot:#ubuntu-release- New binary: gemma [i386] (cosmic-proposed/universe) [0.97+dfsg-2] (no packageset)
<acheronuk> hmmm 'autopkgtest-build-lxd images:ubuntu/cosmic/amd64'
<acheronuk> I get 'Timed out waiting for container to boot'
<acheronuk> on this real machine, and a remote VPS
<acheronuk> seems to go beyond the timeout before 'lxc exec autopkgtest-prepare-*** runlevel' returns N 5 instead of unknown
<Laney> yeah me and xnox were looking into that
<bdmurray> Trevinho: I'm at a sprint but will look today.
<sil2100> bdmurray: I released those SRUs that were ready, not sure if the pending page updated since then
<bdmurray> sil2100: I saw you did the important one - apport!
<sil2100> bdmurray: I will be doing my SRU shift in some minutes if anything, since I'm basiscally shifted to your timezone now
<sil2100> So if anything you can get busy with meetings if you don't feel like SRUing ;)
<bdmurray> Thanks I do have a meeting in 10 minutes.
-queuebot:#ubuntu-release- Unapproved: fonts-guru-extra (bionic-proposed/main) [2.0-4 => 2.0-4ubuntu0.1] (desktop-core, personal-gunnarhj)
<cyphermox> LocutusOfBorg: it's *ubuntu1 because the patch is submitted to debian, but not necessarily landed yet. since we're doing the work, we can run syncpackage as appropriate when it's necessary.
-queuebot:#ubuntu-release- New binary: zc.lockfile [amd64] (cosmic-proposed/universe) [1.3.0-1] (zope)
-queuebot:#ubuntu-release- Unapproved: python-apt (bionic-proposed/main) [1.6.0 => 1.6.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted cups-pk-helper [source] (bionic-proposed) [0.2.6-1ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (bionic-proposed) [3.5-1ubuntu3.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (artful-proposed) [3.5-1~ubuntu17.10.3]
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (xenial-proposed) [3.5-1~ubuntu16.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (trusty-proposed) [3.5-1~ubuntu14.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted gdm3 [source] (bionic-proposed) [3.28.2-0ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted quota [source] (bionic-proposed) [4.04-2ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: rejected vlc [source] (bionic-proposed) [3.0.3-1ubuntu0.1]
<sil2100> tjaalton: hey! Still around?
<tjaalton> sil2100: somewhat, yes
<tjaalton> hi
<tjaalton> :P
<sil2100> tjaalton: hi! I would really like to approve libglvnd, but it's missing some SRU information on one of the bugs
<sil2100> Like, some info on what test steps to perform to validate the fix
<sil2100> tjaalton: would be awesome if you could quickly hack something up ;)
<tjaalton> alright
<tjaalton> sil2100: which bug?
<sil2100> https://bugs.launchpad.net/ubuntu/+source/libglvnd/+bug/1770913
<tjaalton> ah
<ubot5> Ubuntu bug 1770913 in libglvnd (Ubuntu) "Software rendering is forced after 18.04 upgrade (Intel Core 2 Duo P8600 / GMA 4500MHD)" [Undecided,Triaged]
<tjaalton> got it
<sil2100> :) Thanks!
<tjaalton> sil2100: how's that now?
<sil2100> Purrfect
<tjaalton> btw, I uploaded the first pkgs for 16.04.5 yesterday, libdrm & llvm-6
<sil2100> tjaalton: excellent! I'll pick those up in a moment, didn't get to xenial yet
-queuebot:#ubuntu-release- New binary: murano [amd64] (cosmic-proposed/universe) [1:5.0.0-1ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: accepted libglvnd [source] (bionic-proposed) [1.0.0-2ubuntu2.1]
<sil2100> tjaalton: hm, I don't see the llvm toolchain in the queue - you sure that got properly uploaded?
<sil2100> I'll take care of libdrm in the meantime
<tjaalton> sil2100: it's on NEW
-queuebot:#ubuntu-release- Unapproved: accepted libdrm [source] (xenial-proposed) [2.4.91-2~16.04.1]
-queuebot:#ubuntu-release- Unapproved: swauth (bionic-proposed/universe) [1.3.0-1 => 1.3.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: swauth (artful-proposed/universe) [1.2.0-3 => 1.2.0-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: swauth (bionic-proposed/universe) [1.3.0-1 => 1.3.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-6.0 [source] (xenial-proposed) [1:6.0-1ubuntu2~16.04.1]
<sil2100> Laney: oh, no bileto autopkgtest results for the gst new version?
-queuebot:#ubuntu-release- New binary: u-boot [arm64] (cosmic-proposed/main) [2018.03+dfsg1-2ubuntu1] (core)
<sil2100> Laney: also, is versioning of 1.14.1-1ubuntu1~ubuntu18.04.1 a standard? I guess that's nitpicking already
<infinity> sil2100, Laney: I'd prefer to see 1.14.1-1ubuntu1~18.04.1 for a backport of 1.14.1-1ubuntu1, but meh.
<infinity> (automatic backport tools will do what is in the queue, I think)
<sil2100> Yeah, I'd prefer the other version as well, which is why I asked
<sil2100> But it's just nitpicking
<sil2100> So I'll just finish reviewing all of those tomorrow when I wake up
<sil2100> o/
-queuebot:#ubuntu-release- New binary: llvm-toolchain-6.0 [ppc64el] (xenial-proposed/universe) [1:6.0-1ubuntu2~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-6.0 [amd64] (xenial-proposed/universe) [1:6.0-1ubuntu2~16.04.1] (no packageset)
#ubuntu-release 2018-06-08
-queuebot:#ubuntu-release- New binary: llvm-toolchain-6.0 [powerpc] (xenial-proposed/universe) [1:6.0-1ubuntu2~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-6.0 [i386] (xenial-proposed/universe) [1:6.0-1ubuntu2~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.31 => 2.408.32] (desktop-core)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-6.0 [arm64] (xenial-proposed/universe) [1:6.0-1ubuntu2~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-6.0 [armhf] (xenial-proposed/universe) [1:6.0-1ubuntu2~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.32]
<Laney> I actually *used* the tool. :P
<Laney> (maybe I am the tool...)
 * didrocks puts Laney back on the carpenter's bench
<Laney> slangasek: juliank sil2100 OOM again
<Laney> rbasak: I don't suppose you know who might have a clue about rabbitmq / erlang, at all?
<Laney> We've been seeing incidences of autopkgtest's rabbitmq OOMing and dying in the last month or so
<Laney> The consequences are not very nice for us :/
<Laney> (In that everything breaks)
<LocutusOfBorg> cyphermox, I know the ubuntu1 reason, but since I upload in debian in a matter of minutes, the syncpackage is often useless
<LocutusOfBorg> specially with such transitions, if we forget, we have to do lots of rebuilds
<LocutusOfBorg> *useless* rebuilds :)
<rbasak> Laney: I don't think I know any more than you do, sorry.
<Laney> rbasak: OK, I saw the server team subscriber and thought there might be a person there who could assist.
<rbasak> Laney: sure, by all means put it on our plate
<rbasak> Since we're committed to looking after it.
<rbasak> I just mean that I have no specific knowledge that you don't.
<cking> hi there, my zfsutils uploads from yesterday  didn't work in some scenarios and failed testing, can they be removed from -proposed for series X, A, B and C ?
<rbasak> cking: I can't do the delete, but please can you mark the bug verification-failed?
<rbasak> From an SRU perspective we can just supersede the packages in proposed when you have replacements. An AA can delete from -proposed if the package is causing harm there
<rbasak> (or if they feel like it but harm is a good reason :)
<ginggs> what needs to be done to move r-cran-maptools from multiverse -> universe? - i think it blocks https://launchpad.net/ubuntu/+source/car/3.0-0-1
<cking> rbasak, marked as verification-failed
-queuebot:#ubuntu-release- New binary: uhd [s390x] (cosmic-proposed/universe) [3.12.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: uhd [ppc64el] (cosmic-proposed/universe) [3.12.0.0-2] (no packageset)
<cpaelzer> rbasak: IIRC the *mq* packages are server for historical reasons
<cpaelzer> real knowledge might have be split off in the past and reside with jamespage and team now
-queuebot:#ubuntu-release- New binary: uhd [amd64] (cosmic-proposed/universe) [3.12.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: uhd [i386] (cosmic-proposed/universe) [3.12.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: uhd [armhf] (cosmic-proposed/universe) [3.12.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: uhd [arm64] (cosmic-proposed/universe) [3.12.0.0-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnocchi (bionic-proposed/universe) [4.2.4-0ubuntu1 => 4.2.4-0ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted u-boot [arm64] (cosmic-proposed) [2018.03+dfsg1-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-libav1.0 [sync] (bionic-proposed) [1.14.1-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-bad1.0 [sync] (bionic-proposed) [1.14.1-1ubuntu1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-base1.0 [sync] (bionic-proposed) [1.14.1-1ubuntu1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-good1.0 [sync] (bionic-proposed) [1.14.1-1ubuntu1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-ugly1.0 [sync] (bionic-proposed) [1.14.1-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-python1.0 [sync] (bionic-proposed) [1.14.1-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-rtsp-server1.0 [sync] (bionic-proposed) [1.14.1-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gstreamer-editing-services1.0 [sync] (bionic-proposed) [1.14.1-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gstreamer-vaapi [sync] (bionic-proposed) [1.14.1-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gstreamer1.0 [sync] (bionic-proposed) [1.14.1-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.32 => 2.408.33] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (bionic-proposed/main) [0.7.5-1ubuntu16 => 0.7.5-1ubuntu16.2] (core)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (artful-proposed/main) [0.6.5.11-1ubuntu3.4 => 0.6.5.11-1ubuntu3.6] (core)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.33]
-queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [0.6.5.6-0ubuntu21 => 0.6.5.6-0ubuntu23] (no packageset)
-queuebot:#ubuntu-release- Unapproved: update-manager (bionic-proposed/main) [1:18.04.11.1 => 1:18.04.11.2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (bionic-proposed) [1:18.04.11.2]
<slangasek> cjwatson: it seems you seeded policyrcd-script-zg2 in 2009, but this package never had an owning team... should I check with IS whether this is still interesting to them, or should it just be demoted?
<infinity> slangasek: We use it.
<slangasek> infinity: "we"?
<infinity> slangasek: It's installed in every buildd chroot.
<slangasek> infinity: k. who do you think should be the owning team/
<infinity> slangasek: Us.
<infinity> slangasek: It's amazingly trivial, and pretty much never changes, I'm happy to have you yell at me if it somehow magically breaks. :P
<slangasek> infinity: k, subscribed.
<infinity> (If we dropped it out of main, I'd just cargo-cult its contents wholesale into livecd-rootfs, which would be counter-productive)
<ginggs> what needs to be done to move r-cran-maptools from multiverse -> universe? - i think it blocks https://launchpad.net/ubuntu/+source/car/3.0-0-1
<doko> change the overrides
<doko> done
<mitya57> doko: While you are online, may I ask you for some comment on bug #1771044?
<ubot5> bug 1771044 in redshift (Ubuntu) "sysconfig-debian-schemes.diff patch causes Python packages to FTBFS" [High,Triaged] https://launchpad.net/bugs/1771044
<ginggs> doko: danke! i see r-cran-maptools in universe now, retrying car build
<cjwatson> slangasek: ... what he said
<slangasek> cjwatson: ack :)
<doko> mitya57: yes, not yet ready. will revert that. note it's in 3.7 too, but I hope nobody cares about that for now
<mitya57> doko: ack, thanks. I donât care about 3.7 but a fix in 3.6 is important to me because it blocks some autopkgtests.
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20180510+dfsg1-0ubuntu3~14.04.2 => 20180510+dfsg1-0ubuntu3~14.04.3] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: accepted pollinate [source] (bionic-proposed) [4.33-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: iperf (bionic-proposed/universe) [2.0.10+dfsg1-1 => 2.0.10+dfsg1-1ubuntu0.18.04.1] (edubuntu)
-queuebot:#ubuntu-release- Unapproved: iperf (artful-proposed/universe) [2.0.10+dfsg1-1 => 2.0.10+dfsg1-1ubuntu0.17.10.1] (edubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (trusty-proposed) [20180510+dfsg1-0ubuntu3~14.04.3]
-queuebot:#ubuntu-release- Unapproved: iperf (xenial-proposed/universe) [2.0.5+dfsg1-2 => 2.0.5+dfsg1-2ubuntu0.1] (edubuntu)
#ubuntu-release 2018-06-09
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (bionic-proposed/main) [0.130ubuntu3 => 0.130ubuntu3.1] (core)
-queuebot:#ubuntu-release- New binary: tarantool [amd64] (cosmic-proposed/universe) [1.9.1.26.g63eb81e3c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tarantool [i386] (cosmic-proposed/universe) [1.9.1.26.g63eb81e3c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tarantool [arm64] (cosmic-proposed/universe) [1.9.1.26.g63eb81e3c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tarantool [armhf] (cosmic-proposed/universe) [1.9.1.26.g63eb81e3c-1] (no packageset)
<WMRamadan> Hello I have recently subscibed to the Ubuntu-release mailing list and I was wondering how can I become a part of the Ubuntu-release team?
<valorie> WMRamadan: there is some stuff here that could get you started: https://wiki.ubuntu.com/ReleaseTeam
<WMRamadan> valorie: So how do I get added to the team?
<valorie> please make your way through all the links
<valorie> this is not a team for beginners
<valorie> if you are not already an Ubuntu Developer, begin your work towards that
<WMRamadan> I am currently on the Ubuntu Studio Packaging & Development Team
<valorie> cool!
<valorie> so you have a bit of a taste of what they do here
<ErichEickmeyer> WMRamadan: She's right. Uploading packages has to go through the proper channels, which I'm still learning, but -release is part of that team. Getting to this team takes a while (I'm not even on it, but as the release manager for Ubuntu Studio I make certain decisions regarding packages and their effect on the Studio flavor.)
<ErichEickmeyer> Lurking in this channel is a good learning experience for learning how things are done.
<WMRamadan> Great!
-queuebot:#ubuntu-release- Unapproved: fonts-beng-extra (bionic-proposed/main) [1.0-6 => 1.0-6ubuntu0.1] (desktop-core, personal-gunnarhj)
-queuebot:#ubuntu-release- Unapproved: fonts-deva-extra (bionic-proposed/main) [3.0-4 => 3.0-4ubuntu0.1] (desktop-core, personal-gunnarhj)
-queuebot:#ubuntu-release- Unapproved: fonts-gujr-extra (bionic-proposed/main) [1.0-6 => 1.0-6ubuntu0.1] (desktop-core, personal-gunnarhj)
-queuebot:#ubuntu-release- Unapproved: fonts-orya-extra (bionic-proposed/main) [2.0-5 => 2.0-5ubuntu0.1] (desktop-core, personal-gunnarhj)
-queuebot:#ubuntu-release- New binary: gudhi [s390x] (cosmic-proposed/universe) [2.1.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gudhi [amd64] (cosmic-proposed/universe) [2.1.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gudhi [ppc64el] (cosmic-proposed/universe) [2.1.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gudhi [arm64] (cosmic-proposed/universe) [2.1.0+dfsg-2] (no packageset)
#ubuntu-release 2018-06-10
-queuebot:#ubuntu-release- New binary: genometester [amd64] (cosmic-proposed/none) [4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyaxmlparser [amd64] (cosmic-proposed/none) [0.3.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: genometester [i386] (cosmic-proposed/none) [4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ell [amd64] (cosmic-proposed/universe) [0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: genometester [armhf] (cosmic-proposed/universe) [4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: genometester [arm64] (cosmic-proposed/universe) [4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: genometester [ppc64el] (cosmic-proposed/universe) [4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ell [ppc64el] (cosmic-proposed/universe) [0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ell [i386] (cosmic-proposed/universe) [0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ell [arm64] (cosmic-proposed/universe) [0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-cartopy [amd64] (cosmic-proposed/universe) [0.16.0+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ell [armhf] (cosmic-proposed/universe) [0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: genometester [s390x] (cosmic-proposed/universe) [4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ell [s390x] (cosmic-proposed/universe) [0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-dnephin-cobra [amd64] (cosmic-proposed/universe) [1.5.1+git20170113.0.0e9ca70-3] (no packageset)
-queuebot:#ubuntu-release- New binary: watson [amd64] (cosmic-proposed/universe) [1.6.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: cctools [s390x] (cosmic-proposed/universe) [6.2.9-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cctools [amd64] (cosmic-proposed/universe) [6.2.9-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: im-config (bionic-proposed/main) [0.34-1ubuntu1.1 => 0.34-1ubuntu1.2] (input-methods, kubuntu, personal-gunnarhj, ubuntu-desktop)
#ubuntu-release 2019-06-03
-queuebot:#ubuntu-release- Unapproved: cockpit (disco-backports/universe) [194-1~ubuntu19.04.1 => 195-1~ubuntu19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (disco-backports) [195-1~ubuntu19.04.1]
-queuebot:#ubuntu-release- Unapproved: cockpit (bionic-backports/universe) [194-1~ubuntu18.04.1 => 195-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (cosmic-backports/universe) [194-1~ubuntu18.10.1 => 195-1~ubuntu18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (bionic-backports) [195-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (cosmic-backports) [195-1~ubuntu18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (bionic-proposed) [2:1.19.6-1ubuntu4.3]
-queuebot:#ubuntu-release- Unapproved: libreoffice (bionic-proposed/main) [1:6.0.7-0ubuntu0.18.04.6 => 1:6.0.7-0ubuntu0.18.04.7] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libreoffice-l10n (bionic-proposed/main) [1:6.0.7-0ubuntu0.18.04.4 => 1:6.0.7-0ubuntu0.18.04.7] (ubuntu-desktop)
<Laney> sil2100: (just flipped gnome-shell back to v-done now you've released yaru [thanks for that])
<sil2100> Laney: ACK o/
 * sil2100 looks at gnome-shell and mutter then
<Laney> ð
-queuebot:#ubuntu-release- Unapproved: libreoffice (cosmic-proposed/main) [1:6.1.6-0ubuntu0.18.10.2 => 1:6.1.6-0ubuntu0.18.10.3] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libreoffice-l10n (cosmic-proposed/main) [1:6.1.6-0ubuntu0.18.10.2 => 1:6.1.6-0ubuntu0.18.10.3] (ubuntu-desktop)
-queuebot:#ubuntu-release- New source: indicator-notifications (eoan-proposed/primary) [0.3.3-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected indicator-notifications [source] (eoan-proposed) [0.3.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted indicator-notifications [source] (eoan-proposed) [0.3.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: indicator-notifications [amd64] (eoan-proposed/none) [0.3.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: indicator-notifications [ppc64el] (eoan-proposed/none) [0.3.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: indicator-notifications [i386] (eoan-proposed/none) [0.3.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: indicator-notifications [s390x] (eoan-proposed/none) [0.3.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: indicator-notifications [arm64] (eoan-proposed/none) [0.3.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: indicator-notifications [armhf] (eoan-proposed/none) [0.3.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20190521-0ubuntu1~16.04.0 => 20190522-0ubuntu1~16.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (bionic-proposed/universe) [20190521-0ubuntu1~18.04.0 => 20190522-0ubuntu1~18.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (disco-proposed/main) [20190521-0ubuntu1~19.04.0 => 20190522-0ubuntu1~19.04.0] (core, ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (cosmic-proposed/main) [20190521-0ubuntu1~18.10.0 => 20190522-0ubuntu1~18.10.0] (ubuntu-cloud)
<rbalint> sil2100, ^ please accept the gce-compute-image-packages when you have time
-queuebot:#ubuntu-release- Unapproved: libgeo-coder-googlev3-perl (bionic-proposed/universe) [0.16-1 => 0.16-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: qemu (disco-proposed/main) [1:3.1+dfsg-2ubuntu3.1 => 1:3.1+dfsg-2ubuntu3.2] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu7.14 => 1:2.11+dfsg-1ubuntu7.15] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: qemu (cosmic-proposed/main) [1:2.12+dfsg-3ubuntu8.8 => 1:2.12+dfsg-3ubuntu8.9] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: libvirt (xenial-proposed/main) [1.3.1-1ubuntu10.26 => 1.3.1-1ubuntu10.27] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: libvirt (bionic-proposed/main) [4.0.0-1ubuntu8.10 => 4.0.0-1ubuntu8.11] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: libvirt (cosmic-proposed/main) [4.6.0-2ubuntu3.5 => 4.6.0-2ubuntu3.6] (ubuntu-server, virt)
<cpaelzer> hi, things are mostly good, but I have to ask to cancel the just appeared libvirt (xenial-proposed/main) [1.3.1-1ubuntu10.26 => 1.3.1-1ubuntu10.27]
<cpaelzer> sil2100: rbasak: could one of you do that?
<cpaelzer> the others are good but for just this particular one I need another round of test/dev/verify to be sure the upload does the right thing
<cpaelzer> I'd want to repeat my request for someone to please cancel  libvirt xenial-proposed 1.3.1-1ubuntu10.27 from -unapproved
<sil2100> cpaelzer: you mean, reject it?
<sil2100> On it o/
-queuebot:#ubuntu-release- Unapproved: rejected libvirt [source] (xenial-proposed) [1.3.1-1ubuntu10.27]
-queuebot:#ubuntu-release- New: accepted indicator-notifications [amd64] (eoan-proposed) [0.3.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted indicator-notifications [armhf] (eoan-proposed) [0.3.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted indicator-notifications [ppc64el] (eoan-proposed) [0.3.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted indicator-notifications [arm64] (eoan-proposed) [0.3.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted indicator-notifications [s390x] (eoan-proposed) [0.3.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted indicator-notifications [i386] (eoan-proposed) [0.3.3-0ubuntu1]
<cpaelzer> thank you sil2100
<sil2100> huh, is qa.ubuntuwire.org down?
<Laney> looks like it
-queuebot:#ubuntu-release- Unapproved: apport (xenial-proposed/main) [2.20.1-0ubuntu2.18 => 2.20.1-0ubuntu2.19] (core)
<mparillo> It finally came up for me. I wonder if the google problems are affecting many seemingly-unrelated sites
<jamespage> afternoon
<jamespage> pls can the neutron upload in bionic proposed be rejected; need to include a cherry pick for a functional regression
<xnox> vorlon:  would you please look at https://bugs.launchpad.net/ubuntu/bionic/+source/libgeo-coder-googlev3-perl/+bug/1831443 ? is that an ok way to request hints? or review/accept the sru that effectively skips the offending online tests.
<ubot5> Launchpad bug 1831443 in libgeo-coder-googlev3-perl (Ubuntu Bionic) "[hint] [sru] autopkgtest regressed as an API key is now required" [Undecided,New]
 * Laney is making progress on a juju-2-ified autopkgtest-cloud
-queuebot:#ubuntu-release- Unapproved: accepted glusterfs [source] (bionic-proposed) [3.13.2-1ubuntu1]
<slashd> sil2100, thanks for glusterfs approval ^
<sil2100> o/
-queuebot:#ubuntu-release- Unapproved: accepted cups [source] (disco-proposed) [2.2.10-4ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted cups [source] (cosmic-proposed) [2.2.8-5ubuntu1.4]
-queuebot:#ubuntu-release- Unapproved: accepted cups [source] (bionic-proposed) [2.2.7-1ubuntu2.6]
-queuebot:#ubuntu-release- Unapproved: accepted cups [source] (xenial-proposed) [2.1.3-4ubuntu0.9]
<ddstreet> sil2100 i see you retried the corosync failure in disco - it looks like that's failing because it can't find/download the corosync src in disco?  Could that be because there is only a corosync pkg in disco-release, and the corosync pkgs in disco-proposed were superceded and then the last one deleted when it was moved to eoan?
-queuebot:#ubuntu-release- New: accepted ubuntustudio-look [amd64] (eoan-proposed) [0.61]
<teward> sil2100: thanks for ^ that I'm sure Eickmeyer is very happy that was binNEW ACCEPTED
<teward> :)
<Eickmeyer> YEP!
<Eickmeyer> \o/
<teward> (assuming that was you sil2100 since I poked earlier xD)
<sil2100> yw!
<sil2100> ddstreet: I remember retrying it once because I was a bit surprised with the 'unknown' field, in the end I didn't find the time to track down the actual reason
<ddstreet> sil2100 yeah adt couldn't find a src for it to download, so it didn't know what version it was trying to test
<ddstreet> i'll try to repro locally, i think it's because there are corosync packages in disco-proposed that were superceded and the last disco-proposed version was deleted when it moved into eoan
<ddstreet> but not really sure
<sil2100> Eickmeyer: I'm reviewing your lsp-plugins upload right now - is there any NEW-package bug for that where I could leave feedback?
<Eickmeyer> sil2100: Yes, hang on...
<sil2100> ddstreet: hm, might be possible, didn't see that happening before though
<Eickmeyer> sil2100: bug 1827288
<ubot5> bug 1827288 in Ubuntu Studio "[Needs Packaging] LSP-Plugins for Eoan" [Medium,Fix committed] https://launchpad.net/bugs/1827288
<teward> sil2100: correct me if i'm wrong but that should also be filed against bare Ubuntu too right?
<sil2100> teward: probably, but I don't think that's a strict requirement
<teward> just thought i'd ask :p
<sil2100> What I do like is when the NEW package bug is attached to the changelog, if possible
<sil2100> ;)
<teward> :P
<teward> true statement i see that's missing here
<Eickmeyer> sil2100, teward: Just filed it against bare Ubuntu.
<Eickmeyer> I can fix that changelog too, sil2100. Do we want to do a re-upload once I do?
 * Eickmeyer can't upload that one
<sil2100> Eickmeyer: I left some comments on the bug
<Eickmeyer> Ok
<sil2100> Eickmeyer: I need to EOD soon, but let's touch base tomorrow
<Eickmeyer> sil2100: Works for me.
<sil2100> Eickmeyer: take a look at those and respond on the bug, and then I can re-upload + approve it tomorrow if needed ;)
<Eickmeyer> sil2100: Sounds good. :)
<sil2100> Eickmeyer: ...but in case I forget myself, please do poke me about it
<sil2100> o/
<Eickmeyer> sil2100: Will do. Have a good one!
<teward> sil2100: thanks for looking at them anyways
<teward> enjoy your night :)
<sil2100> Thanks!
-queuebot:#ubuntu-release- New binary: swaybg [amd64] (eoan-proposed/none) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: swaybg [i386] (eoan-proposed/none) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: swaybg [ppc64el] (eoan-proposed/none) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: swaybg [s390x] (eoan-proposed/none) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: swaybg [arm64] (eoan-proposed/none) [1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: swaybg [armhf] (eoan-proposed/none) [1.0-1] (no packageset)
<rbalint> infinity, please accept the gce-compute-image-packages srus if you have time today
<vorlon> xnox: I'd still really prefer MPs instead of bugs, but yeah that looks fine, I'll land the hint (for bionic only; http://autopkgtest.ubuntu.com/packages/libg/libgeo-coder-googlev3-perl shows no tests for xenial).  also do you know about retry-autopkgtest-regressions --no-proposed?
<infinity> rbalint: I'll have a look later today.
-queuebot:#ubuntu-release- Unapproved: rejected libgeo-coder-googlev3-perl [source] (bionic-proposed) [0.16-1ubuntu0.1]
<vorlon> xnox: please also transfer https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1797386/comments/52 into the sru bug description (i.e. fix up 'regression potential')
<ubot5> Launchpad bug 1797386 in python-tornado (Ubuntu) "[SRU] OpenSSL 1.1.1 to 18.04 LTS" [Undecided,In progress]
<Eickmeyer> vorlon: Regarding lsp-plugins, the upstream developer made a few fixes. Do you think this would fix the test issue? https://github.com/sadko4u/lsp-plugins/issues/50
<gitbot> sadko4u issue 50 in lsp-plugins "Tests fail on debian/ubuntu build " [Hotfix, Feature Request, Open]
<vorlon> Eickmeyer: try it and see? :)
<Eickmeyer> vorlon: Ok
<ddstreet> xnox looks like you got corosync-qdevice version 3 into disco-release, but it seems corosync itself version 3 didn't make it into disco-release...you or vorlon want to comment on lp #1831492, as i'm not sure how to fix that mismatch
<ubot5> Launchpad bug 1831492 in corosync (Ubuntu Disco) "autopkgtest --apt-pocket=proposed=<any trigger> fails with corosync in disco" [Undecided,New] https://launchpad.net/bugs/1831492
<ddstreet> besides the obvious 'release corosync version 3 to match, into disco-updates'
-queuebot:#ubuntu-release- Unapproved: dahdi-linux (bionic-proposed/universe) [1:2.11.1~dfsg-1ubuntu4 => 1:2.11.1~dfsg-1ubuntu4.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: sysdig (bionic-proposed/universe) [0.19.1-1ubuntu1 => 0.19.1-1ubuntu1.1] (no packageset)
<Eickmeyer> vorlon: We have a successful build including tests. \o/
<vorlon> ddstreet: so I appreciate that corosync is not in particularly good shape in disco (cf LP: #1826045), but I'm not sure why we should care about this for a non-LTS release; if what you're after is getting systemd through, we should demonstrate that this test is broken in the release pocket, update the hints to reflect that, and move on
<ubot5> Launchpad bug 1826045 in pcs (Ubuntu Disco) "Unsatisfiable recommended dependencies pacemaker >= 2.0, corosync >= 3.0" [High,Confirmed] https://launchpad.net/bugs/1826045
<vorlon> Eickmeyer: the "build twice, test this one, ship that one" you commented in the bug, or something better?
<Eickmeyer> vorlon: no, the upstream developer fixed the test suite, I added patches. Builds with test, no errors.
<vorlon> ah nice
<Eickmeyer> vorlon: I removed your comments (and the override_dh_auto_test:) line from debian/rules since it's no longer necessary.
-queuebot:#ubuntu-release- New binary: u-boot [arm64] (eoan-proposed/main) [2019.04+dfsg-2ubuntu1] (core)
<ddstreet> vorlon we shouldn't care about corosync, pacemaker, pcs in disco?  i mean this isn't just autopkgtest failures, this is actual problems with the packages...if the opinion is we don't care about the packages in disco, then why not just upgrade both pacemaker and corosync to the next major version, which will fix both problems?
<vorlon> ddstreet: because that's more work than doing nothing
<vorlon> so why is it worth doing more work?
<ddstreet> er, because it's broken?
<vorlon> and nothing in that autopkgtest log reads to me as saying anything about the state of the corosync package
<ddstreet> well i explained it in the lp bug
<ddstreet> corosync-qdevice was split out from corosync at version 3
<ddstreet> so it will now be actually literally impossible to release any more version <3 corosync builds for disco
<vorlon> ok but what does that have to do with 'apt-source corosync' apparently failing in the autopkgtest log?
<ddstreet> did you read my bug?  it explains it in detail
<vorlon> your bug does not explain the answer to the question I just asked
<ddstreet> about what is has to do with 'apt-source corosync' in the adt log?
<vorlon> "because the testbed can't find the corosync source" the corosync source hasn't gone anywhere
<ddstreet> there is no corosync source for the corosync-qdevice version
<ddstreet> vorlon if you read the 'other info' section i think it explains it
<ddstreet> if you still aren't clear, please let me know
<vorlon> ok
<vorlon> so, that still doesn't say to me that the corosync package is broken
<vorlon> it says that the package can't be SRUed without also dropping those binaries from the source
<ddstreet> well, anyone installing corosync-qdevice and/or corosync-qnetd will get the wrong (version 3) binaryies
<ddstreet> i don't know if you consider that broken or not, but it's certainly not right in my book
<ddstreet> anyway, i'm about eod, if you have more thoughts on it or want to just hint britney and wontfix the bug, feel free
<vorlon> it also looks to me like runner/autopkgtest is not buggy in the way you describe, but instead does a bidirectional check so it is only comparing versions of binary packages that list this source package as their source
<ddstreet> vorlon it's not buggy, i don't say that adt is buggy anywhere
<ddstreet> it's doing exactly what it should be
<ddstreet> the problem is corosync-qdevice at v3 along with corosync at v2, both existing together
<ddstreet> anywho, add q to the bug if you still don't understand - i'm eod
<vorlon> if it's doing what you say, that's certainly not what it's supposed to be doing
<ddstreet> vorlon i think you still don't understand what the problem is, because adt is doing things right
-queuebot:#ubuntu-release- Unapproved: mesa (bionic-proposed/main) [19.0.2-1ubuntu1~18.04.1 => 19.0.2-1ubuntu1.1~18.04.1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: mesa (disco-proposed/main) [19.0.2-1ubuntu1 => 19.0.2-1ubuntu1.1] (core, xorg)
<vorlon> ddstreet: there's nothing right about mapping source to binaries to source and coming up with a source package version number for a different package
<vorlon> and there is code in here to /guard against that case/
<ddstreet> well, it found this problem, didn't it ;-)
<vorlon> ddstreet: runner/autopkgtest, line 469, is intended to filter out binaries that are listed in this source package but whose current source is not this source package.  It fails because it's using \b to bound the package name and that matches the boundary between c and - in 'corosync-qdevice'.
<vorlon> ddstreet: correction, it doesn't fail because the bit above that already filters it out (show=$(apt-cache show $pkg=$pkg_candidate | grep "^Source:" || true) <-- empty because src_pkg == bin_pkg and there's no Source: line)
<vorlon> ddstreet: but then it hits corosync-qnetd, which does fail in the manner described
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (disco-proposed) [2.578.5]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (cosmic-proposed) [2.542.5]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.26]
#ubuntu-release 2019-06-04
-queuebot:#ubuntu-release- New binary: patiencediff [ppc64el] (eoan-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: patiencediff [amd64] (eoan-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: patiencediff [i386] (eoan-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: patiencediff [armhf] (eoan-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: patiencediff [arm64] (eoan-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: patiencediff [s390x] (eoan-proposed/universe) [0.1.0-1] (no packageset)
<Laney> xnox: ð¤
<Laney> also git diff --word-diff is the best for reviewing autopkgtest-cloud config changes
-queuebot:#ubuntu-release- New: accepted cc-tool [amd64] (eoan-proposed) [0.26.20190527-1]
-queuebot:#ubuntu-release- New: accepted cc-tool [armhf] (eoan-proposed) [0.26.20190527-1]
-queuebot:#ubuntu-release- New: accepted cc-tool [ppc64el] (eoan-proposed) [0.26.20190527-1]
-queuebot:#ubuntu-release- New: accepted golang-github-joyent-gosign [amd64] (eoan-proposed) [0.0~git20161114.9abcee2-1]
-queuebot:#ubuntu-release- New: accepted patiencediff [armhf] (eoan-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted patiencediff [s390x] (eoan-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted cc-tool [arm64] (eoan-proposed) [0.26.20190527-1]
-queuebot:#ubuntu-release- New: accepted cc-tool [s390x] (eoan-proposed) [0.26.20190527-1]
-queuebot:#ubuntu-release- New: accepted patiencediff [i386] (eoan-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted cc-tool [i386] (eoan-proposed) [0.26.20190527-1]
-queuebot:#ubuntu-release- New: accepted patiencediff [arm64] (eoan-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted patiencediff [amd64] (eoan-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted swaybg [amd64] (eoan-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted swaybg [armhf] (eoan-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted swaybg [ppc64el] (eoan-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted patiencediff [ppc64el] (eoan-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted swaybg [i386] (eoan-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted swaybg [arm64] (eoan-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: accepted swaybg [s390x] (eoan-proposed) [1.0-1]
-queuebot:#ubuntu-release- New: rejected lsp-plugins [source] (eoan-proposed) [1.1.9-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted u-boot [arm64] (eoan-proposed) [2019.04+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New source: lsp-plugins (eoan-proposed/primary) [1.1.9-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted lsp-plugins [source] (eoan-proposed) [1.1.9-0ubuntu1]
-queuebot:#ubuntu-release- New binary: lsp-plugins [amd64] (eoan-proposed/universe) [1.1.9-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: lsp-plugins [i386] (eoan-proposed/universe) [1.1.9-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lvm2 (cosmic-proposed/main) [2.02.176-4.1ubuntu3 => 2.02.176-4.1ubuntu3.18.10.1] (core)
-queuebot:#ubuntu-release- Unapproved: lvm2 (xenial-proposed/main) [2.02.133-1ubuntu10 => 2.02.133-1ubuntu10.1] (core)
-queuebot:#ubuntu-release- Unapproved: lvm2 (disco-proposed/main) [2.02.176-4.1ubuntu4 => 2.02.176-4.1ubuntu4.1] (core)
-queuebot:#ubuntu-release- Unapproved: neutron (bionic-proposed/main) [2:12.0.5-0ubuntu5 => 2:12.0.6-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (disco-proposed/main) [2:14.0.0-0ubuntu1 => 2:14.0.0-0ubuntu1.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (cosmic-proposed/main) [2:13.0.2-0ubuntu3.2 => 2:13.0.2-0ubuntu3.3] (openstack, ubuntu-server)
<jamespage> if there is an sru team member around the 2:12.0.6-0ubuntu1 for neutron ^^ supercedes the existing one in the UNAPPROVED queue
<xnox> Laney:  ððð and triggered linux-* retries in bionic and disco now. Hopefully it gets better.
<Laney> heh
<Laney> I'd have probably done one at first ...
<rbalint> bdmurray, RAOF, please accept the gce-compute-image-packages srus if you have time today
<xnox> ah, well =)
<RAOF> rbalint: I'll do them in my shift if bdmurray doesn't get to them first ð
-queuebot:#ubuntu-release- New source: grubzfs-testsuite (eoan-proposed/primary) [0.1]
<RAOF> It seems that the recent Qt5 security release to Bionic has included a regression in Wayland support?
<RAOF> Alan Griffiths has more details; I'll get him to file a bug.
<mdeslaur> RAOF: ok, please let me know the bug number and I'll take a look
<alan_g> I'm just trying to figure out where to file it...
<mdeslaur> alan_g: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+filebug
<alan_g> Sorry for the delay. There's a factor I don't yet understand making it hard to document a reproducer.
<mdeslaur> np
-queuebot:#ubuntu-release- Unapproved: newlib (bionic-proposed/universe) [2.4.0.20160527-3build1 => 2.4.0.20160527-3ubuntu0.1] (no packageset)
<ddstreet> tkamppeter are you able to verify the systemd in b/c-proposed for lp #1754671
<ubot5> Launchpad bug 1754671 in network-manager (Ubuntu Bionic) "Full-tunnel VPN DNS leakage regression" [High,In progress] https://launchpad.net/bugs/1754671
-queuebot:#ubuntu-release- Unapproved: cinder (cosmic-proposed/main) [2:13.0.3-0ubuntu1 => 2:13.0.5-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: heat (cosmic-proposed/main) [1:11.0.0-0ubuntu2 => 1:11.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (cosmic-proposed/main) [2:18.1.0-0ubuntu3 => 2:18.2.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: horizon (cosmic-proposed/main) [3:14.0.2-0ubuntu4 => 3:14.0.3-0ubuntu1] (openstack, ubuntu-server)
<Eickmeyer> sil2100: Thank you so much!!!!
<Eickmeyer> sil2100: Now I see that it's binNEW... what now?
<sil2100> Eickmeyer: ah! On it!
<sil2100> Forgot about it ;)
<Eickmeyer> sil2100: Ha! No worries.
<Eickmeyer> Well, no worries now that you're on it. :)
<sil2100> Eickmeyer: oh, so it FTBFS on all the other arches?
<sil2100> Eickmeyer: should we do a follow up upload limiting the list of arches to amd64 and i386?
<sil2100> Or should it actually build and be usable everywhere?
<Eickmeyer> sil2100: It should build and be usable everywhere per the developer, at least in the bug report conversation we had yesterday. :S
<Eickmeyer> That said, I'm not sure I'm willing to support every arch on the planet.
<sil2100> uh
<Eickmeyer> sil2100: I stand corrected. He built on multiple systems/kernels, not architectures. Should be amd64/i386 only.
<Eickmeyer> I had to go back and read the conversation.
<Eickmeyer> sil2100: He did build on armv7, raspberry pi.
<Eickmeyer> https://github.com/sadko4u/lsp-plugins/issues/50#issuecomment-498409847
<gitbot> sadko4u issue 50 in lsp-plugins "Tests fail on debian/ubuntu build " [Hotfix, Pending For Release, Feature Request, Closed]
<sil2100> Eickmeyer: could you find out what should be the state here? Like, I'd like the package to correspond to the requirements and needs of upstream
<sil2100> e.g. if upstream says it's amd64/i386 only, then let's modify the packaging as such - otherwise we'd need upstream to help us get it building on the respective architectures ;/
<Eickmeyer> sil2100: I'll file a new bug report/question and see what the response is.
<Eickmeyer> sil2100: Bug report filed, waiting for an answer. Upstream has been very responsive.
<sil2100> Eickmeyer: thanks! Let's leave the binaries in there for now - anyway, we're 'almost there' now ;)
<Eickmeyer> sil2100: You've been super encouraging through this. Thank you so much!
<infinity> This doesn't look like an "upstream needs to help" situation.
<infinity> It just shouldn't be calling compilers with -m32.
<infinity> Also, the part where it seems to detect the target arch as "i586" on non-amd64 is a bit lolz.
<Eickmeyer> sil2100: ^
<sil2100> Well, I didn't look at the source of the problem so I wouldn't know - I leave it up to Eickmeyer and/or upstream to take care of that
<sil2100> (ETOOMANYTHINGS, sorry about that o/)
<infinity> Well, the source of this problem is debian/rules
<acheronuk> BUILD_PROFILE=i586
<acheronuk> in rules
<infinity> acheronuk: Jinx. :)
<acheronuk> if not amd64
<infinity> Upstream also defines aarch64 (for arm64) and armv7a (for armhf).
<sil2100> Sure, but I didn't see the project's Makefile's to know what impact it is
<infinity> So at least those two would be trivial to enable in rules.
<sil2100> s/it is/it has/
<sil2100> Anyway
 * Eickmeyer is looking now
<sil2100> Eickmeyer: thanks o/
<sil2100> Eickmeyer: in case you get something that seems to be working, please push it to the vcs and give me a sign
<Eickmeyer> sil2100: Will do.
<sil2100> Eickmeyer: but before that happens do some test-builds on a PPA with more than just amd64/i386 enabled
<sil2100> That's something I could have noticed before, since the autobuild PPA seems to only have those two arches
<infinity> That said, all this BUILD_PROFILE stuff looks completely bogus.  Tearing it all out would work better (as an upstream recommendation).
<sil2100> Eickmeyer: ^ maybe you could give that a try in a PPA? ;)
<Eickmeyer> infinity: Yeah, that was stuff left over from the KXStudio repo (lots of poor packaging happens there, hence my personal undertaking of making it "unnecessary" for Studio users). I should've noticed it, sorry.
<infinity> To be clear, I don't mean "removing it from debian/rules will have the desired result", I mean "the entire concept in the upstream makefiles is ridiculous because it's setting compiler defaults that would be correct if the developer didn't try to micromanage".
<Eickmeyer> sil2100: That's my plan at the moment. Might have to drop everything to get my son ready for school.
<infinity> Like, seriously, explicitly setting "-m elf_x86_64"?
<Eickmeyer> infinity: It does appear to be made that way. :/
<infinity> Eickmeyer: I think for debian/ubuntu, I'd be inclined to add a "generic" BUILD_PROFILE to scripts/make/configure.mk that doesn't do any of this silliness, and just specify THAT one in debian/rules.
<infinity> Eickmeyer: Then compiler defaults will win and DTRT, regardless of arch.
<infinity> Eickmeyer: You already patch out the only braindead use of LD_PATH, so it's just CC_ARCH and LD_ARCH getting in your way here.
<Eickmeyer> infinity: Right. As soon as I can figure out a way to patch out this stuff, then I'll get that done. In the meantime, though, I have to get my son out the door for school. Will report back.
<Eickmeyer> infinity, sil2100: upstream only supports i386, arm64, aarch64, and armv7-ar. Does this affect anything?
<infinity> Eickmeyer: Define "supports".
<Eickmeyer> https://github.com/sadko4u/lsp-plugins/blob/04cc45a4aee3bd3a46ecbd0a9160d0d87f8f8a32/README.txt#L30-L47
<infinity> Eickmeyer: Upstream only has build targets for those arches, but as we've established, those build targets are bunk.
<Eickmeyer> infinity: Then I guess I'm lost. Should I patch out the entire CC_ARCH and LD_ARCH variables?
<infinity> Eickmeyer: So, IMO, if you suddenly built on other arches, they'd just also become "experimental" support by upstream's definition.  No big.
<infinity> Eickmeyer: Patching out hundreds of lines is much more effort than just adding a target that sets those variables blank, and using it.
<infinity> Eickmeyer: ie: right before the x86_64 target, create a "generic" one.  Then in debian/rules, always export BUILD_PROFILE=generic.  DOne.
<infinity> There's literally zero reason to build with -m64/-m32 or -m elf_foo on any sane Debian/Ubuntu toolchain.  We already pick the right things for ABI compat with our ports.
<Eickmeyer> infinity: Okay, That makes sense.
<infinity> Ahh, balls.
<infinity> No, wait, I found one last place where BUILD_PROFILE is actually legit used.
<Eickmeyer> Standing by.
<infinity> https://github.com/sadko4u/lsp-plugins/blob/04cc45a4aee3bd3a46ecbd0a9160d0d87f8f8a32/src/dsp/Makefile
<infinity> So, we *do* want a generic, but it should only be selected as a fallback.
<infinity> You want to beef up your debian/rules selection to select i586 for i386, x86_64 for amd64, armv7a for armhf, aarch64 for arm64, and generic as the fallback.
<infinity> Then it should all DTRT.
<infinity> (THose targets are still "wrong", but they're wrong in harmless ways, so whatever)
<Eickmeyer> infinity: That thought had crossed my mind. I'll go ahead and do it.
<infinity> Eickmeyer: And, actually, those vars are set empty before the test, so you don't actually need to patch in a "generic" BUILD_PROFILE is you don't want to.
<infinity> Just setting BUILD_PROFILE to generic (or any garbage) for arches that don't have an explicit profile definition should DTRT.
<infinity> So all you need to fix is debian/rules.
<Eickmeyer> infinity: That can be done.
<infinity> Eickmeyer: And, IMO, if it still FTBFS or otherwise sucks on arches upstream doesn't define, that's fine, IMO.  Just a best effort attempt to set those 4 profiles correctly and *try* to build generically on everything else is fine.
<Eickmeyer> infinity: Works for me.
<Eickmeyer> infinity, sil2100: Made the changes, pushed, building in my personal PPA (to avoid enabling other architectures in the Studio autobuilds PPA).
<Eickmeyer> infinity, sil2100: Successful builds for those architectures. We're good to go.
<infinity> Eickmeyer: Some nitpicking about the changes in your PPA before you push, but the intent is there. :)
<Eickmeyer> infinity: I haven't pushed the tags, if that's what you mean.
<infinity> Eickmeyer: The major one is that you want DEB_HOST_ARCH, not DEB_HOST_ARCH_CPU
<infinity> Eickmeyer: Also, "armhl" should be "armhf"
<Eickmeyer> heh, silly me and my typo.
<infinity> Testing for DEB_HOST_ARCH_CPU means most of those were just building "generic" instead.
<infinity> Since CPU is x86_64, i386 (sometimes i686), armv7a, etc.
<Eickmeyer> Uh, interesting. Still successfully built. Makes me question if those lines are even necessary, though you did discover the reason, so I trust you.
<infinity> Eickmeyer: Sure, it'll build, but for amd64, you'd skip building the optimised bits.
<infinity> Same for arm64 and armhf.
<Eickmeyer> Ok.
<infinity> Or...
<infinity> Maybe what's actually happening is you broke it so well that it fixed it. :)
<infinity> In that because none of those match, BUILD_PROFILE isn't being set, and the upstream makefile is selecting the right one based on uname(1) :P
<infinity> Which only works on Ubuntu buildds, because we force uname to match the target build arch.
<infinity> It would fail miserably in Debian.
<infinity> Or local builds.
<Eickmeyer> I guess I know how to break things. :D
<infinity> Yep, that's definitely what's happened.
<infinity> Entertaining, though.
<Eickmeyer> Indeed! lol
<infinity> No real point in using filter() there either.
<infinity> Just ifeq ($(DEB_HOST_ARCH),arm64) is enough.
<Eickmeyer> infinity: ack
<infinity> Eickmeyer: It also seems to be missing an "include /usr/share/dpkg/architecture.mk" before that ifeq mess.
<infinity> Eickmeyer: Which sort of makes it all a no-op...
<infinity> Unless dh(1) does something fancy there on re-entry.
<infinity> But not that I know of.
<Eickmeyer> infinity: I'm learning a lot today.
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (disco-proposed) [20190522-0ubuntu1~19.04.0]
<infinity> Eickmeyer: That looks like it might actually do what you expect now.
<Eickmeyer> infinity: Cool. I'll be watching the build. :)
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (cosmic-proposed) [20190522-0ubuntu1~18.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (bionic-proposed) [20190522-0ubuntu1~18.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (xenial-proposed) [20190522-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted exim4 [source] (disco-proposed) [4.92-4ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted ktouch [source] (disco-proposed) [4:18.12.3-0ubuntu1.1]
<Eickmeyer> infinity, sil2100: Looks like that actually gave some decent builds.
-queuebot:#ubuntu-release- Unapproved: accepted hw-detect [source] (disco-proposed) [1.117ubuntu6.19.04.1]
<infinity> Eickmeyer: \o/
<Eickmeyer> infinity: Do you want to reject sil2100's upload of lsp-plugins? Then, if you want to, you can reupload and approve.
<Eickmeyer> Unless sil2100 wants to do it. :)
<infinity> Eickmeyer: Gimme a .dsc somewhere to sponsor for you?
<infinity> I'm curious about the testsuite override.  What/how does it break?
-queuebot:#ubuntu-release- New: rejected lsp-plugins [amd64] (eoan-proposed) [1.1.9-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected lsp-plugins [i386] (eoan-proposed) [1.1.9-0ubuntu1]
<Eickmeyer> infinity: https://code.launchpad.net/~eeickmeyer/+archive/ubuntu/ppa/+packages
<infinity> Eickmeyer: Well, yes, I saw that, but that lacks a correct changelog entry and version.
<Eickmeyer> Ah, yes. Standby...
 * Eickmeyer has to move to a system that'll actually do the build manually, not this Celeron he's currently typing on
<infinity> They still make Celerons?
<Eickmeyer> Dual-core at that!
<infinity> Oh, the test override is commented out.  Maybe you should delete that cruft. :P
<Eickmeyer> infinity: I thought I had.... weird.
<infinity> ...
<infinity> Also, you end up building twice...
<Eickmeyer> ...
<infinity> And I suspect what you install is the binaries you built in the second pass, since I don't see it building them somewhere else.
 * Eickmeyer shakes fist at upstream
<infinity> Oh, wait.
<Eickmeyer> That's exactly what vorlon and I were trying to avoid.
<infinity> It builds the build in .build and the test in .test
<infinity> I think.
-queuebot:#ubuntu-release- Unapproved: accepted hw-detect [source] (cosmic-proposed) [1.117ubuntu6.18.10.1]
<infinity> So hard to decipher with the non-verbose build.
<Eickmeyer> Yes. That was upstream's doing.
<infinity> Okay.
<infinity> Gross, but okay.
<Eickmeyer> Indeed.
<infinity> OOI, why are the test binaries "not suitable" to ship?
<cjwatson> Policy says to override upstream and make the build verbose
<cjwatson> Hopefully there's a V=1 switch or similar
<cjwatson> (https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules)
<Eickmeyer> I honestly don't know. The "make test" doesn't do what one would expect.
-queuebot:#ubuntu-release- Unapproved: accepted hw-detect [source] (bionic-proposed) [1.117ubuntu6.18.04.1]
<infinity> Ahh, -DLSP_TESTING -DLSP_TRACE
<infinity> It's using that to include extra trace and breakpoint vomit.
<infinity> Gross, but whatever.
<Eickmeyer> So should I keep that as-is?
<infinity> Yeah, it's fine.
<infinity> Ignore me.
<Eickmeyer> heh, no worries.
<infinity> Making the upstream Makefiles verbose would be lovely, but unfortunately, that's not practical either.
<infinity> Cause he literally just prefaces everything with @
<Eickmeyer> Shoddy makefiles.
<infinity> It'd be a nightmare to replace them all with a macro in a distro patch.
<vorlon> Eickmeyer: so, that double-build (test one build, ship one build) is exactly what I said we should avoid in the package.  If this is really the status quo, the dh_auto_test override should come back.
<Eickmeyer> vorlon, infinity: In that case, I'll revert the change I just made.
<Eickmeyer> IMO, upstream doesn't understand the meaning of "test suite".
-queuebot:#ubuntu-release- Unapproved: accepted libguestfs [source] (disco-proposed) [1:1.40.2-1ubuntu1.1]
<Eickmeyer> infinity: uploading to my (other) ppa.
<Eickmeyer> infinity: I have a dsc file for you at https://launchpad.net/~eeickmeyer/+archive/ubuntu/ppa2/+packages
<infinity> Eickmeyer: ACK, will look when this TB meeting lets out.
-queuebot:#ubuntu-release- Unapproved: accepted libguestfs [source] (cosmic-proposed) [1:1.38.4-1ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted libguestfs [source] (bionic-proposed) [1:1.36.13-1ubuntu3.3]
<vorlon> E: librados2: symbols-file-contains-current-version-with-debian-revision on symbol
<vorlon> _ZN5boost6spirit2qi4ruleIN9__gnu_cxx17__normal_iteratorIPKcNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEEF11MonCapGrantvENS0_11unused_typeESG_SG_E6defineIN4mpl_5bool_ILb1EEENS_5proto7exprns_4exprINSM_6tagns_3tag11shift_rightENSM_7argsns_5list2IRKNSO_ISR_NST_IRKNSO_ISR_NST_IRKNSO_ISR_NST_IRKNSO_ISR_NST_IRKNSO_ISR_NST_IRKNSO_ISR_NST_IRKNSO_ISR_NST_IRKNSO_ISR_NST_IRKNSO_INSQ_6negateENSS_5list1I
<vorlon> RNS2_ISD_SG_SG_SG_SG_EEEELl1EEERKNSO_ISU_NSV_IRKNSO_ISR_NST_IRKNSO_INSQ_8terminalENSS_4termINS0_11terminal_exINS0_3tag3litENS_6fusion6vectorIJRA6_S5_EEEEEEELl0EEESX_EELl2EEEEELl1EEEEELl2EEERKNSO_IS12_NS13_INS14_IS16_NS18_IJRA8_S5_EEEEEEELl0EEEEELl2EEERKNSO_INSQ_10bitwise_orENST_IRKNSO_IS12_NS13_INS14_IS16_NS18_IJcEEEEEEELl0EEESX_EELl2EEEEELl2EEERKNSO_IS12_NS13_INS14_INS15_4attrENS18_IJSC_EEEEEEELl0E
<vorlon> EEEELl2EEERNS2_ISD_FSC_vESG_SG_SG_EEEELl2EEES2Q_EELl2EEERKNSO_IS12_NS13_INS14_IS2K_NS18_IJSt3mapISC_16StringConstraintSt4lessISC_ESaISt4pairIKSC_S37_EEEEEEEEEELl0EEEEELl2EEERKNSO_IS12_NS13_INS14_IS2K_NS18_IJiEEEEEEELl0EEEEELl2EEERKNSO_ISU_NSV_IRKNSO_ISR_NST_IRKNSO_ISR_NST_IRKNSO_ISR_NST_ISX_S20_EELl2EEESX_EELl2EEES2X_EELl2EEEEELl1EEEEELl2EEEEEvRSH_RKT0_SL_@Base and 1 others
<vorlon> :P
<infinity> SPAM
<Eickmeyer> !paste
<ubot5> For posting multi-line texts into the channel, please use https://paste.ubuntu.com | To post !screenshots use https://imgur.com/ !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<infinity> Eickmeyer: Erm, you wanted -0ubuntu2 there, not ubuntu1.
<infinity> Eickmeyer: ubuntu1 is already in the archive.
<Eickmeyer> infinity: d'oh!
<vorlon> I mean, yes, but pastebinning would ruin the effect
<Eickmeyer> will fix.
<vorlon> for those playing along at home, c++filt also chokes on that symbol name
<infinity> Eickmeyer: Make sure the upload includes the original ubuntu1 changelog entry, and then ubuntu2 with the fixes.
<Eickmeyer> infinity: ack
<infinity> Eickmeyer: Debdiff against "pull-lp-source -d lsp-plugins" to make sure it's sane.
<vorlon> (chokes gracefully - it refuses to demangle it. I was actually curious to see if c++filt would spiral out of control)
<infinity> vorlon: Didn't I hear doko talking about some new and wonderful utopia where templated symbols will eff right off and we can live happily ever after?
<infinity> But yeah, that one's pretty amazing.
<vorlon> infinity: which do you bet is larger, the symbol name or the implementation?
<infinity> The worst part is how much of it I can demangle in my head without a tool.
<infinity> This is not knowlege I should have, and I resent it being in there.
<vorlon> haha
<Eickmeyer> infinity: File lists identical (after any substitutions), so sanity is ensured?
<Eickmeyer> FYI, my next package is a cakewalk compared to this one.
<infinity> Eickmeyer: I meant debdiffing the sources. :)
<infinity> Eickmeyer: To make sure the changelog looked sane, etc.
<Eickmeyer> infinity: Oh. That showed only my changes/changelog addition.
<infinity> Eickmeyer: Kay.  Gimme?
<Eickmeyer> Sure.
-queuebot:#ubuntu-release- Unapproved: kexec-tools (bionic-proposed/main) [1:2.0.16-1ubuntu1 => 1:2.0.16-1ubuntu1.1] (core)
<Eickmeyer> Wait a minute...
-queuebot:#ubuntu-release- Unapproved: rejected mesa [source] (disco-proposed) [19.0.2-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: kexec-tools (cosmic-proposed/main) [1:2.0.16-1ubuntu3 => 1:2.0.16-1ubuntu3.1] (core)
<Eickmeyer> infinity: This is what it spat-out, but maybe I'm doing something wrong. The only source I can find is the tarball. https://paste.ubuntu.com/p/yN4t9hhxr5/
<Eickmeyer> I have the feeling I should update to eoan.
-queuebot:#ubuntu-release- Unapproved: accepted lvm2 [source] (disco-proposed) [2.02.176-4.1ubuntu4.1]
<Eickmeyer> infinity: Anyhow, updated .dsc file
<infinity> Eickmeyer: The diff against the archive version is https://paste.ubuntu.com/p/B8K7jbqZMd/
<infinity> Eickmeyer: Which LGTM.
<Eickmeyer> infinity: Cool. Sorry about my incompetence on that one. Still learning.
<infinity> Eickmeyer: Uploaded.
<Eickmeyer> infinity: Thanks! Are we going to have to wait for a second AA to approve?
<apw> that is for eoan, so no
<infinity> binNEW will still need a review, but I can do that when they pop up.
<infinity> I suppose I should have reviewed the binaries from the previous upload in case they were obviously busted. :P
<infinity> Oh well.
<Eickmeyer> heh. Thanks for your help today. I have two other packages in the sponsorship queue, so we can get that straightened out as soon as a MOTU can look at them.
<infinity> Eickmeyer: Ahh, thanks to include/dsp/types.h it won't build on anything but the 4 arches you enabled, but that's fine.
<Eickmeyer> infinity: Ha! I was just typing to mention that.
<infinity> I mean, it's kinda ridiculous, not fine, but I don't expect you to port it to PPC and S/390 either.
<Eickmeyer> Gotcha. Honestly, it would be rediculous for someone running audio plugins on those architectures anyhow (including ARM imo, but crazier things have happened).
<infinity> Ridiculous on an s390x mainframe, maybe (though, if they can be used for command-line processing, maybe not, it's crazy fast)
<infinity> But not at all weird to do multimedia stuff on PPC.
<infinity> Either way, carefactor low, if I crusaded to make every upstream write portable code, I wouldn't have time for basic bodily functions.
<cjwatson> Might be quite fun to try to get LP appservers working on a mainframe :)
<infinity> cjwatson: Honestly, if we could get a couple more of them, I'd be down with moving our entire infra to s390x.
<infinity> cjwatson: But it's not like we're likely to pay for that, and IBM seems shy about sending us spares.
<infinity> Can't imagine why.
<cjwatson> (More realistically the database, but that's probably boring because PostgreSQL)
<cjwatson> IronStack
<infinity> Plus, you get a free Thinkpad with every mainframe, so that's a super good deal.
 * cjwatson orders the reinforced floor
<infinity> Well, you also get a free POWER8/9 (the storage subsystem).
<infinity> It's three computers for the price of one!
<infinity> Well, for the price of dozens.
<infinity> But still.
-queuebot:#ubuntu-release- Unapproved: accepted lvm2 [source] (cosmic-proposed) [2.02.176-4.1ubuntu3.18.10.1]
-queuebot:#ubuntu-release- New binary: lsp-plugins [amd64] (eoan-proposed/universe) [1.1.9-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: lsp-plugins [i386] (eoan-proposed/universe) [1.1.9-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (disco-proposed) [2:14.0.0-0ubuntu1.1]
-queuebot:#ubuntu-release- New binary: lsp-plugins [arm64] (eoan-proposed/universe) [1.1.9-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: lsp-plugins [armhf] (eoan-proposed/universe) [1.1.9-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (cosmic-proposed) [2:13.0.2-0ubuntu3.3]
-queuebot:#ubuntu-release- Unapproved: rejected neutron [source] (bionic-proposed) [2:12.0.6-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (bionic-proposed) [2:12.0.6-0ubuntu1]
<bdmurray> connor_k: should bug 1828615 also be tested with the 4.15 kernel?
<ubot5> bug 1828615 in v4l2loopback (Ubuntu Bionic) "v4l2loopback 10.0-1ubuntu1 ADT test failure with linux 5.0.0-14-generic" [Undecided,Fix committed] https://launchpad.net/bugs/1828615
<connor_k> bdmurray, I tested it with 4.15.0-49 and 5.0.0-14
<bdmurray> connor_k: I don't see that in comment #5
<connor_k> bdmurray, sorry, you're right. Those tests were for before proposed, let me verify on 4.15 real quick, I'll upload that as well
<bdmurray> connor_k: thanks, I'm here for a bit yet so just ping me
<connor_k> bdmurray, just added the test for 4.15 to comment #6: https://bugs.launchpad.net/ubuntu/+source/v4l2loopback/+bug/1828615/comments/6
<ubot5> Launchpad bug 1828615 in v4l2loopback (Ubuntu Bionic) "v4l2loopback 10.0-1ubuntu1 ADT test failure with linux 5.0.0-14-generic" [Undecided,Fix committed]
<vorlon> jamespage: hi, when you write that ceph's packaging is re-synced with "upstream", what upstream is that?  It's not Debian AFAICS and there are various binary NEW packages which I'm trying to understand
#ubuntu-release 2019-06-05
<RAOF> Urgh, autopackagtests.
<vorlon> urgh? :)
<RAOF> Every SRU I look at releasing is blocked on autopkgtests which look like they might not be false-positives..
<RAOF> But also, autopkgtests continue to be a flood of false-positives.
<vorlon> hmm
<vorlon> I must have stockholm syndrome
<vorlon> the rate of false-positives is higher than I want (because I want it to be 0) but I wouldn't have called it a flood
<RAOF> And not just random universe packages; apt is blocked because apport's autopkgtests are broken in a way that looks like it's probably a false-positive, maybe?
<vorlon> yeah I was just noticing that and I suspect it might be "regressed in release" rather than false-positive
<RAOF> Right, but for apt that's a false-positive.
<vorlon> well, yes
<vorlon> step 1) get autopkgtests running continuously in a loop
<vorlon> but also, juliank evidently retried apport's autopkgtest against the release pocket but nobody told us to hint it :)
<vorlon> adding hint now
<RAOF> What is it with people uploading SRUs to Bionic and Disco, but not Cosmic?
<RAOF> 058813
<tjaalton> bdmurray: thanks for reviewing mesa, turns out that the dropped patch was actually cruft in the source root dir, so was meant to be dropped :P
-queuebot:#ubuntu-release- Unapproved: mesa (disco-proposed/main) [19.0.2-1ubuntu1 => 19.0.2-1ubuntu1.1] (core, xorg)
<jamespage> vorlon: upstream == ceph project itself in this case
<jamespage> it is a bit of a nebulous comment I agree
<juliank> vorlon, RAOF apt/denial? I uploaded a fixed apport, hence did not ask for an unblock.
<juliank> Um, s/denial/xenial/
<RAOF> juliank: Ah, yes.
<RAOF> juliank: That upload would appear to address only one of the two autopkgtest failures, though?
<juliank> RAOF: well, it worked when I uploaded it. Apparently a PPA used in tests has been removed in the meantime?
<juliank> ~fooser/+archive/ubuntu/bar-ppa
<RAOF> Plausibly? The other failure was failing to find a specific set of packages on Launchpad, IIRC.
<juliank> I can't open ~fooser, so I assume it's gone
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.38 => 2.39.2] (desktop-core, ubuntu-server)
<juliank> WARNING: cannot connect to: https://api.launchpad.net/devel/ubuntu/+archive/primary/?ws.op=getPublishedBinaries&binary_name=unity-services&version=7.2.5+14.04.20150521.1-0ubuntu1&exact_match=true
<juliank> I think that's the issue
<RAOF> Seems right.
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.38+18.04 => 2.39.2+18.04] (desktop-core, ubuntu-server)
<juliank> These launchpad tests are so flaky
-queuebot:#ubuntu-release- Unapproved: snapd (cosmic-proposed/main) [2.38+18.10 => 2.39.2+18.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (disco-proposed/main) [2.38+19.04 => 2.39.2+19.04] (core)
<juliank> Usually the error here is launchpad timing out
<juliank> Because it's doing stuff
<juliank> It's unclear if the last two runs were just unlucky or if there's another issue now
<RAOF> Darn tests interacting with external services!
 * apw looks at snapd
<LocutusOfBorg> hello AA please remove circlator NBS proposed thanks https://bugs.launchpad.net/ubuntu/+source/circ
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/circlator/+bug/1828408
<ubot5> Launchpad bug 1828408 in circlator (Ubuntu) "remove circlator on non-amd64 archs" [Undecided,New]
<cjwatson> juliank: That request is pretty expensive.  Can you use either ordered=false or order_by_date=true?
<cjwatson> (potentially expensive anyway)
<juliank> cjwatson: Hmm, probably.
<juliank> cjwatson: Should it return an empty list though? unity 7.2.5+14.04.20150521.1-0ubuntu1 certainly exists, but I get back {"total_size": 0, "start": 0, "entries": []}
<juliank> What we're trying to figure out is the deb file for a given binary package name, version, arch
<juliank> It returns empty even for 7.2.6+14.04.20160408-0ubuntu1 , which is currently in trusty-updatesd
<juliank> oops, + URL encoding
<juliank> So, RAOF , these failures seem to be communication issues w/ launchpad timing out - I just ran it locally and it failed for qemu-utils, but not unity-services
<juliank> maybe we should write a dummy launchpad for testing, I don't know
<juliank> or just mock launchpad in urlopen
<cjwatson> juliank: Are you just trying to download the .deb?
<juliank> cjwatson: So, the function parsing this currently returns the URL of the deb and its sha1
<juliank> I mean, we do want some assurance the deb is not broken optimally I guess
<cjwatson> juliank: Have you considered https://launchpad.net/ubuntu/+archive/primary/+files/unity-services_7.2.5+14.04.20150521.1-0ubuntu1_amd64.deb ?
<juliank> cjwatson: I see two problems: (1) we don't get a hash and (2) we have to try up to two times, for Architecture: all
<cjwatson> We could consider adding headers to librarian responses giving the hash, perhaps
<juliank> though not sure about (2)
<cjwatson> (2) would still be cheaper than making fairly expensive API requests, I'm sure
<juliank> yup
<juliank> the header trick for (1) is probably OK, but requires some refactoring on the client
<juliank> as it currently uses APT'S builtin hash support
<juliank> that is, it stores the hash in the download item, so apt verifies it while downloading
<cjwatson> However, for purposes of integrity, I think it would be sufficient to check the size to guard against short responses; you can rely on TLS for the rest
<cjwatson> In this particular case
<cjwatson> Check the size against Content-Length, that is
<juliank> apt does that already
<juliank> ah, but one problem with re-trying for arch: all is that we build a queue of all items to fetch and then fetch them
<juliank> so some would fail and we'd have to retry those
<juliank> that's not entirely optimal
<cjwatson> It's possible this strategy doesn't work, I just wanted to know if you'd considered it since in some ways it's simpler
<cjwatson> Certainly if this is in test code then I think you should mock LP
-queuebot:#ubuntu-release- Unapproved: libvirt (xenial-proposed/main) [1.3.1-1ubuntu10.26 => 1.3.1-1ubuntu10.27] (ubuntu-server, virt)
<cpaelzer__> coreycb: ^^ FYI
<coreycb> cpaelzer: thanks!
-queuebot:#ubuntu-release- Unapproved: lvm2 (bionic-proposed/main) [2.02.176-4.1ubuntu3 => 2.02.176-4.1ubuntu3.18.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: neutron (cosmic-proposed/main) [2:13.0.2-0ubuntu3.3 => 2:13.0.3-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: binutils (cosmic-proposed/main) [2.31.1-6ubuntu1.1 => 2.31.1-6ubuntu1.2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: eclipse-titan (cosmic-proposed/universe) [6.3.1-1build4.1 => 6.3.1-1build4.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-7 (cosmic-proposed/main) [7.4.0-1ubuntu1~18.10 => 7.4.0-1ubuntu1~18.10.1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-7-cross (cosmic-proposed/universe) [26ubuntu1.1 => 26ubuntu1.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-7-cross-ports (cosmic-proposed/universe) [21ubuntu1.1 => 21ubuntu1.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-8 (cosmic-proposed/main) [8.3.0-6ubuntu1~18.10 => 8.3.0-6ubuntu1~18.10.1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-8-cross (cosmic-proposed/main) [21ubuntu1.1 => 21ubuntu1.2] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-8-cross-ports (cosmic-proposed/universe) [12ubuntu1.1 => 12ubuntu1.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-defaults (cosmic-proposed/main) [1.179ubuntu1.1 => 1.179ubuntu1.2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-defaults-ports (cosmic-proposed/universe) [1.178ubuntu1.1 => 1.178ubuntu1.2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ggcov (cosmic-proposed/universe) [0.9+20190314-0ubuntu1~18.10 => 0.9+20190314-0ubuntu1~18.10.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: binutils (bionic-proposed/main) [2.30-21ubuntu1~18.04.1 => 2.30-21ubuntu1~18.04.2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-7 (bionic-proposed/main) [7.4.0-1ubuntu1~18.04 => 7.4.0-1ubuntu1~18.04.1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: eclipse-titan (bionic-proposed/universe) [6.3.1-1build1.2 => 6.3.1-1build1.3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-7-cross (bionic-proposed/main) [21ubuntu0.2 => 21ubuntu0.3] (ubuntu-desktop) (sync)
<sil2100> It's the -security-only rebuilds if anything, I'm handling those ^
-queuebot:#ubuntu-release- Unapproved: gcc-7-cross-ports (bionic-proposed/universe) [17ubuntu0.2 => 17ubuntu0.3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-8 (bionic-proposed/main) [8.3.0-6ubuntu1~18.04 => 8.3.0-6ubuntu1~18.04.1] (core) (sync)
<sil2100> (-security-only rebuilds of toolchain packages for b/c)
-queuebot:#ubuntu-release- Unapproved: gcc-8-cross (bionic-proposed/main) [18ubuntu0.3 => 18ubuntu0.4] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-8-cross-ports (bionic-proposed/universe) [9ubuntu0.3 => 9ubuntu0.4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-defaults (bionic-proposed/main) [1.176ubuntu2.2 => 1.176ubuntu2.3] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-defaults-ports (bionic-proposed/universe) [1.176ubuntu1.2 => 1.176ubuntu1.3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ggcov (bionic-proposed/universe) [0.9+20190314-0ubuntu1~18.04 => 0.9+20190314-0ubuntu1~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted binutils [sync] (cosmic-proposed) [2.31.1-6ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted eclipse-titan [sync] (cosmic-proposed) [6.3.1-1build4.2]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7 [sync] (cosmic-proposed) [7.4.0-1ubuntu1~18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7-cross [sync] (cosmic-proposed) [26ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7-cross-ports [sync] (cosmic-proposed) [21ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross [sync] (cosmic-proposed) [21ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8 [sync] (cosmic-proposed) [8.3.0-6ubuntu1~18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross-ports [sync] (cosmic-proposed) [12ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-defaults [sync] (cosmic-proposed) [1.179ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-defaults-ports [sync] (cosmic-proposed) [1.178ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted ggcov [sync] (cosmic-proposed) [0.9+20190314-0ubuntu1~18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted binutils [sync] (bionic-proposed) [2.30-21ubuntu1~18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted eclipse-titan [sync] (bionic-proposed) [6.3.1-1build1.3]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7 [sync] (bionic-proposed) [7.4.0-1ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7-cross [sync] (bionic-proposed) [21ubuntu0.3]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7-cross-ports [sync] (bionic-proposed) [17ubuntu0.3]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8 [sync] (bionic-proposed) [8.3.0-6ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross [sync] (bionic-proposed) [18ubuntu0.4]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross-ports [sync] (bionic-proposed) [9ubuntu0.4]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-defaults [sync] (bionic-proposed) [1.176ubuntu2.3]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-defaults-ports [sync] (bionic-proposed) [1.176ubuntu1.3]
-queuebot:#ubuntu-release- Unapproved: accepted ggcov [sync] (bionic-proposed) [0.9+20190314-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: curtin (bionic-proposed/main) [18.2-10-g7afd77fa-0ubuntu1~18.04.1 => 19.1-7-g37a7a0f4-0ubuntu1~18.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: curtin (xenial-proposed/main) [18.2-10-g7afd77fa-0ubuntu1~16.04.1 => 19.1-7-g37a7a0f4-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: curtin (cosmic-proposed/main) [18.2-10-g7afd77fa-0ubuntu1~18.10.1 => 19.1-7-g37a7a0f4-0ubuntu1~18.10.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: curtin (disco-proposed/main) [18.2-22-g08bf6ff7-0ubuntu1 => 19.1-7-g37a7a0f4-0ubuntu1~19.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (disco-proposed/main) [2.2.32-0ubuntu2 => 2.2.40-0ubuntu1~19.04.1] (core, ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (cosmic-proposed/main) [2.2.32-0ubuntu1~18.10.2 => 2.2.40-0ubuntu1~18.10.1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (xenial-proposed/main) [2.2.32-0ubuntu1~16.04.2 => 2.2.40-0ubuntu1~16.04.1] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (bionic-proposed/main) [2.2.32-0ubuntu1~18.04.2 => 2.2.40-0ubuntu1~18.04.1] (ubuntu-cloud)
<vorlon> cyphermox: I see that you've made substantive changes to http://wiki.ubuntu.com/walinuxagentUpdates, which was an exception process approved by the SRU team; who have these changes been discussed with?
<cyphermox> vorlon: I believe these are no-op changes. Just rather than testing in a PPA, pushing packages to devel-proposed and testing there *unless* there is a reason to be secretive.
<cyphermox> (In other words, there was no discussion with the SRU team prior to right now)
<cyphermox> I have however discussed this with fginther, clarifying things because *I* was confused by the doc mentioning uploading to a PPA
<vorlon> cyphermox: ok; I reverted the one change that I considered incorrect
<vorlon> (the section that talked about post-upload testing suddenly became pre-upload testing)
<cyphermox> oh?
<cyphermox> well, that makes sense anyway
#ubuntu-release 2019-06-06
<jibel> sil2100, hi, could you copy latest build of desktop canary somewhere please?
<sil2100> jibel: o/
<sil2100> jibel: https://people.canonical.com/~platform/ubuntu-canary/20190606/
-queuebot:#ubuntu-release- New binary: kubuntu-wallpapers [amd64] (eoan-proposed/universe) [19.10.1] (kubuntu)
<jibel> sil2100, thanks
-queuebot:#ubuntu-release- Unapproved: accepted partman-iscsi [source] (disco-proposed) [40ubuntu3.19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted partman-iscsi [source] (cosmic-proposed) [40ubuntu3.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted partman-iscsi [source] (bionic-proposed) [40ubuntu3.18.04.1]
<marcustomlinson> hey sil2100, pretty please could you have a look at my bionic and cosmic LibreOffice SRUs today? It's a small fix but high impact
-queuebot:#ubuntu-release- New source: grubzfs-testsuite (eoan-proposed/primary) [0.2]
-queuebot:#ubuntu-release- New: rejected grubzfs-testsuite [source] (eoan-proposed) [0.1]
<didrocks> 0.2 replaces 0.1 as it wasn't reviewed yet ^ If someone has the time to review it, that would be great.
-queuebot:#ubuntu-release- Unapproved: neutron (disco-proposed/main) [2:14.0.0-0ubuntu1.1 => 2:14.0.1-0ubuntu1] (openstack, ubuntu-server)
<jibel> xnox, on desktop canary images BOOT is not set because there is no default-boot-to-casper.conf certainly because CASPER_GENERATE_UUID is not set. What and where is it set? We searched in casper, ubuntu-cdimage, debian-cd and livecd-rootfs but found nothing.
<xnox> jibel:  muahahahahhahaha
<sil2100> cpaelzer: hey! The qemu uploads has some non-SRUenabled bugs, could you SRU-enable those?
<jibel> xnox, ?
<xnox> jibel:  let me find it. it was tricky the first time around
<jibel> okay :)
<didrocks> that's what we guessed, looking for the value :) wondering if it's not hardcoded somewhere on buildds ;)
<cjwatson> if it were you'd find it in lp:launchpad-buildd (but it isn't)
 * didrocks wonders if cjwatson has a hilight on buildd! However, good reference repo to note down, thx
<cjwatson> I read most channels I'm in :)
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (disco-proposed) [19.0.2-1ubuntu1.1]
<xnox> doko:  we cannot hear you
<xnox> doko:  please type
-queuebot:#ubuntu-release- Unapproved: rejected mesa [source] (bionic-proposed) [19.0.2-1ubuntu1.1~18.04.1]
<Eickmeyer> sil2100: FYI, the two archs FTBFAA aren't show-stoppers, nor are they supported upstream, hence they were approved.
<Eickmeyer> RE: lsp-plugins
<xnox> jibel:  in your list of searches you are missing "live-build" =)
<xnox> jibel:  live-build-3.0~a57/scripts/build/lb_chroot_hacks:		UPDATE_INITRAMFS_OPTIONS="CASPER_GENERATE_UUID=1"
<xnox> jibel:  which as far as i understand what generated the final initrd that is spitted out of livebuild.
<xnox> jibel:  note that uuid from the initrd, is then extracted and placed on disk itself as well.
<xnox> jibel:  do you want me to look into unbreaking canary images to generate initrds with uuid?
<xnox> (for desktop, on subiquity side we generate multiple initrds, so we do it by hand)
<jibel> xnox, thanks, that would be great if you could unbreak it.
<sil2100> Eickmeyer: hm, ACK
-queuebot:#ubuntu-release- New: accepted kubuntu-wallpapers [amd64] (eoan-proposed) [19.10.1]
<Eickmeyer> infinity, vorlon: Is the lack of ppc64el and s390x what's hanging-up lsp-plugins in proposed?
<infinity> Eickmeyer: No, I'm reviewing the binaries right now.
<Eickmeyer> infinity: Ah, thanks
-queuebot:#ubuntu-release- New: accepted lsp-plugins [amd64] (eoan-proposed) [1.1.9-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted lsp-plugins [armhf] (eoan-proposed) [1.1.9-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted lsp-plugins [arm64] (eoan-proposed) [1.1.9-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted lsp-plugins [i386] (eoan-proposed) [1.1.9-0ubuntu2]
<Eickmeyer> \o/
<infinity> vorlon: '/lastlog ceph' suggests you'd started a binary NEW review of ceph and then aborted.  Did you want to keep context on that and see it through, or hand it off?
<vorlon> infinity: aside from the onerous download time from the queue I have no other context of import
<infinity> Mmkay.
<vorlon> infinity: the answer I got says that I can't do a cursory review based on something that's been judged good in Debian
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-amdgpu-hwe-18.04 [source] (bionic-proposed) [19.0.1-1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-ati-hwe-18.04 [source] (bionic-proposed) [1:19.0.1-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-nouveau-hwe-18.04 [source] (bionic-proposed) [1:1.0.16-1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: mesa (bionic-proposed/main) [19.0.2-1ubuntu1~18.04.1 => 19.0.2-1ubuntu1.1~18.04.1] (core, xorg)
<vorlon> RikMills[m], tsimonq2: you've seen that kubuntu daily is oversized now in eoan?
<vorlon> incidentally, since flavor leads were discussed in the TB meeting this week, I notice that http://iso.qa.ubuntu.com/admin/config/services/qatracker/series/68/manifest lists yofel, who I haven't heard from in a while.  Is he still the right contact for Kubuntu?
<Eickmeyer> vorlon: Along those same lines, sakrecoer is no longer a contact for Ubuntu Studio.
<Eickmeyer> You can put me down for that.
<vorlon> Eickmeyer: done, cheers
<Eickmeyer> vorlon: Thanks. :)
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (bionic-proposed) [19.0.2-1ubuntu1.1~18.04.1]
<tsimonq2> vorlon: I can't really speak for ISO size, that's acheronuk's department, but for contact, please put (in this order): acheronuk, valorie, ~kubuntu-council.
<tsimonq2> vorlon: Also, a TB meeting? Whee.
<vorlon> tsimonq2: thanks, I think it's meant to be an individual contact, so truncated this after the 2nd
<tsimonq2> vorlon: ack
#ubuntu-release 2019-06-07
<acheronuk> vorlon: yeah, I'm aware of the iso oversize. just undecided whether to request a modest increase or trim something. obviously mostly result of nvidia change
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (disco-proposed) [2.39.1+19.04]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (cosmic-proposed) [2.39.1+18.10]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (bionic-proposed) [2.39.1+18.04]
-queuebot:#ubuntu-release- Unapproved: accepted modem-manager-gui [source] (disco-proposed) [0.0.19.1-1ubuntu0.19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted modem-manager-gui [source] (bionic-proposed) [0.0.19.1-1ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (disco-proposed) [1:3.1+dfsg-2ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (cosmic-proposed) [1:2.12+dfsg-3ubuntu8.9]
<cpaelzer> thanks
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (bionic-proposed) [1:2.11+dfsg-1ubuntu7.15]
-queuebot:#ubuntu-release- Unapproved: accepted openvpn [source] (cosmic-proposed) [2.4.6-1ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: accepted openvpn [source] (bionic-proposed) [2.4.4-2ubuntu1.3]
-queuebot:#ubuntu-release- Unapproved: accepted curl [source] (cosmic-proposed) [7.61.0-1ubuntu2.5]
-queuebot:#ubuntu-release- Unapproved: aptdaemon (disco-proposed/main) [1.1.1+bzr982-0ubuntu21 => 1.1.1+bzr982-0ubuntu21.1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: aptdaemon (cosmic-proposed/main) [1.1.1+bzr982-0ubuntu20 => 1.1.1+bzr982-0ubuntu20.1] (ubuntu-desktop)
<juliank> sil2100: Please reject the aptdaemon SRUs for cosmic and disco, they need more work :/
<juliank> I forgot to put a try/except KeyError around the del os.environ part
<sil2100> juliank: ACK
 * Laney kills worker.conf
<juliank> With the next round of aptdaemon SRUs, we should get it green in all releases. It's been sad so far
<Laney> (at least the one maintained in VCS, probably still going to generate them from the charm)
<Laney> so in future config changes to autopkgtest will be via juju configuration
<juliank> oh well, that's. ... different
<Laney> you'll only have one place to change for e.g. a big_package instead of like 6
<Laney> so better :-0
<Laney> :-)*
<juliank> but what if it's a big package relatively for one arch only?
<juliank> dpes tjhat work?
<Laney> probably add a /arch syntax
<juliank> ack
-queuebot:#ubuntu-release- Unapproved: rejected aptdaemon [source] (disco-proposed) [1.1.1+bzr982-0ubuntu21.1]
<Laney> this reactive programming malarkey is interesting
-queuebot:#ubuntu-release- Unapproved: rejected aptdaemon [source] (cosmic-proposed) [1.1.1+bzr982-0ubuntu20.1]
<Laney> syntax> I mean I'm not going to do that now, but if we needed it then that'd be how :P
<Laney> thinking about monitoring too, what's the current way to do that?
 * Laney doesn't really enjoy the email system
<Laney> prometheus, is that the right thing?
-queuebot:#ubuntu-release- Unapproved: aptdaemon (disco-proposed/main) [1.1.1+bzr982-0ubuntu21 => 1.1.1+bzr982-0ubuntu21.1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: aptdaemon (bionic-proposed/main) [1.1.1+bzr982-0ubuntu19 => 1.1.1+bzr982-0ubuntu19.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: aptdaemon (cosmic-proposed/main) [1.1.1+bzr982-0ubuntu20 => 1.1.1+bzr982-0ubuntu20.1] (ubuntu-desktop)
<juliank> Here we go with new SRUs
<juliank> No xenial yet
-queuebot:#ubuntu-release- Unapproved: nova (disco-proposed/main) [2:19.0.0-0ubuntu2.3 => 2:19.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (bionic-proposed/universe) [1.0.0-0ubuntu4~18.04.1 => 1.0.0-0ubuntu4~18.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (disco-proposed/universe) [1.0.0-0ubuntu4.19.04.0 => 1.0.0-0ubuntu4.19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ec2-hibinit-agent (cosmic-proposed/universe) [1.0.0-0ubuntu4~18.10.1 => 1.0.0-0ubuntu4~18.10.2] (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.2] (no packageset)
<rbalint> tjaalton, vorlon, ^ could you please accept them?
<vorlon> rbalint: s/accept/review/ ;)
<rbalint> vorlon, yes it was just implied :-)
<rbalint> vorlon, otoh a review without accepting them would be less useful from my pov ;-)
<vorlon> heh
-queuebot:#ubuntu-release- Unapproved: accepted ec2-hibinit-agent [source] (disco-proposed) [1.0.0-0ubuntu4.19.04.1]
<rharper> tjaalton: Hi, we're starting a curtin SRU (https://bugs.launchpad.net/curtin/+bug/1831772) could you please look at getting curtin into the -proposed pockets /
<ubot5> Launchpad bug 1831772 in curtin (Ubuntu Disco) "sru curtin 2019-06-05 - 19.1-7-g37a7a0f4-0ubuntu1" [Undecided,New]
<tjaalton> rharper: hi, it's 20:06 here, so I'm actually EOW by now ;)
<rharper> tjaalton: ok, thanks ; vorlon would be able to look at the curtin sru to release into -proposed ?
<vorlon> rharper: sounds like you're asking to jump the queue; is there a particular urgency here?
-queuebot:#ubuntu-release- Unapproved: accepted ec2-hibinit-agent [source] (cosmic-proposed) [1.0.0-0ubuntu4~18.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted ec2-hibinit-agent [source] (bionic-proposed) [1.0.0-0ubuntu4~18.04.2]
<rharper> vorlon: no urgency;  didn't mean to jump the queue;
<vorlon> ok
<vorlon> I'll see where I get to today in my reviews then :)
-queuebot:#ubuntu-release- Unapproved: rejected ec2-hibinit-agent [source] (xenial-proposed) [1.0.0-0ubuntu4~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted ec2-hibinit-agent [source] (xenial-proposed) [1.0.0-0ubuntu4~16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (cosmic-proposed) [2:10.3.10-1~ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (bionic-proposed) [2:10.3.10-1~ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (cosmic-proposed) [1:6.1.6-0ubuntu0.18.10.3]
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice-l10n [source] (cosmic-proposed) [1:6.1.6-0ubuntu0.18.10.3]
<marcustomlinson> \o/
<vorlon> marcustomlinson: libreoffice-l10n/bionic was built with the wrong -v option (i.e. probably none), so doesn't have all the right bugs linked in the .changes
<marcustomlinson> vorlon: oh
-queuebot:#ubuntu-release- Unapproved: rejected libreoffice-l10n [source] (bionic-proposed) [1:6.0.7-0ubuntu0.18.04.7]
-queuebot:#ubuntu-release- Unapproved: libreoffice-l10n (bionic-proposed/main) [1:6.0.7-0ubuntu0.18.04.4 => 1:6.0.7-0ubuntu0.18.04.7] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (cosmic-proposed) [4.6.0-2ubuntu3.6]
<marcustomlinson> vorlon: thank you for sort that out!
<marcustomlinson> s/sort/sorting
-queuebot:#ubuntu-release- Unapproved: accepted gst-rtsp-server1.0 [sync] (bionic-proposed) [1.14.4-1~ubuntu18.04.1]
#ubuntu-release 2019-06-08
<valorie> vorlon: where does that ancient information about the kubuntu team come from? I'd like to fix it
<valorie> Yofel is still around and part of the team but hasn't been leading it for years
<vorlon> valorie: I think it's been carried forward cycle over cycle in the iso tracker manifest unexamined.  Per discussion at the last TB meeting, we should be reviewing this more regularly going forward
<vorlon> valorie: (and in this instance it's already been fixed)
-queuebot:#ubuntu-release- Unapproved: accepted gstreamer1.0 [sync] (bionic-proposed) [1.14.4-1~ubuntu18.04.1]
<valorie> that's good news
<valorie> thanks, vorlon
-queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (bionic-proposed/main) [5.9.5+dfsg-0ubuntu2.1 => 5.9.5+dfsg-0ubuntu2.2] (kubuntu, qt5, ubuntu-desktop)
<acheronuk> are the failing daily iso builds on someones TODO?
<acheronuk> initrd fails with 'cpio: premature end of archive'
<acheronuk> fallout from lz4 I guess
<acheronuk> xnox: is that ^^ to be expected at this point in implementing lz4?
<acheronuk> if a release team member should be about, could konsole be skiptested please? the regression in the apport test for i386 also happens with konsole from the release pocket, so not the fault of the -proosed version
<acheronuk> *proposed
<xnox> acheronuk:  that does smell like a fallout.
<xnox> acheronuk:  let me upload a revert, and investigate on monday.
<acheronuk> xnox: ok. thank you
<xnox> hmmm
<xnox>  lz4cat -t /var/tmp/unmkinitramfs_Z3Py41
<xnox> File extension doesn't match expected LZ4_EXTENSION (.lz4); will not process file: /var/tmp/unmkinitramfs_Z3Py41
<xnox> there is no way to ignore extension it seems....
<xnox> acheronuk:  is there a bug number?
<xnox> filed https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1832108
<ubot5> Launchpad bug 1832108 in initramfs-tools (Ubuntu) "unmkinitramfs fails with lz4 compressed initrds" [Undecided,New]
<xnox> and uploaded revert
<acheronuk> xnox: tyv :)
<acheronuk> *ty
#ubuntu-release 2019-06-09
-queuebot:#ubuntu-release- New binary: yubikey-personalization [amd64] (eoan-proposed/universe) [1.19.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: faudio [i386] (eoan-proposed/universe) [19.06.07-1] (no packageset)
-queuebot:#ubuntu-release- New binary: faudio [s390x] (eoan-proposed/universe) [19.06.07-1] (no packageset)
-queuebot:#ubuntu-release- New binary: faudio [ppc64el] (eoan-proposed/universe) [19.06.07-1] (no packageset)
-queuebot:#ubuntu-release- New binary: faudio [amd64] (eoan-proposed/universe) [19.06.07-1] (no packageset)
-queuebot:#ubuntu-release- New binary: faudio [armhf] (eoan-proposed/universe) [19.06.07-1] (no packageset)
-queuebot:#ubuntu-release- New binary: faudio [arm64] (eoan-proposed/universe) [19.06.07-1] (no packageset)
<xnox> apw:  can you unblock linux 5.0.0-16.17 in eoan? it's released in disco already. And I did a matching d-i upload into eoan already.
<apw> xnox: ack
-queuebot:#ubuntu-release- New: accepted faudio [amd64] (eoan-proposed) [19.06.07-1]
-queuebot:#ubuntu-release- New: accepted faudio [armhf] (eoan-proposed) [19.06.07-1]
-queuebot:#ubuntu-release- New: accepted faudio [ppc64el] (eoan-proposed) [19.06.07-1]
-queuebot:#ubuntu-release- New: accepted yubikey-personalization [amd64] (eoan-proposed) [1.19.3-3]
-queuebot:#ubuntu-release- New: accepted faudio [arm64] (eoan-proposed) [19.06.07-1]
-queuebot:#ubuntu-release- New: accepted faudio [s390x] (eoan-proposed) [19.06.07-1]
-queuebot:#ubuntu-release- New: accepted faudio [i386] (eoan-proposed) [19.06.07-1]
-queuebot:#ubuntu-release- New binary: node-d3-fetch [amd64] (eoan-proposed/universe) [1.1.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-dagre-layout [amd64] (eoan-proposed/universe) [0.8.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-request-promise-core [amd64] (eoan-proposed/universe) [1.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-define-properties [amd64] (eoan-proposed/universe) [1.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-d3-contour [amd64] (eoan-proposed/universe) [1.3.2-1] (no packageset)
<xnox> acheronuk:  with a little bit of thought, uploaded a "fix" for lz4cat
#ubuntu-release 2020-06-01
-queuebot:#ubuntu-release- New binary: paraglob [s390x] (groovy-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc [arm64] (groovy-proposed/universe) [3.13.2+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc [s390x] (groovy-proposed/universe) [3.13.2+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc [armhf] (groovy-proposed/universe) [3.13.2+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc4py [riscv64] (groovy-proposed/universe) [3.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc [riscv64] (groovy-proposed/universe) [3.13.2+dfsg1-1] (no packageset)
<amurray> vorlon: we (security) are wanting to SRU libseccomp 2.4.3 back to f/e/b/x via -security - I've prepared it all via LP #1876055 but haven't had any luck getting it reviewed by the SRU team - since this is wanted as part of UC20 it is time-sensitive - how can I get more visibility for it to be reviewed? Updates are ready and sitting in the security-proposed PPA
<ubot5> Launchpad bug 1876055 in libseccomp (Ubuntu Groovy) "SRU: Backport 2.4.3-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base" [Medium,Confirmed] https://launchpad.net/bugs/1876055
-queuebot:#ubuntu-release- New binary: ordered-map [amd64] (groovy-proposed/universe) [0.8.1-2] (no packageset)
<ginggs> vorlon: np, i figured it out.  i was doing them by dependency layer.
-queuebot:#ubuntu-release- New binary: ordered-map [ppc64el] (groovy-proposed/universe) [0.8.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ordered-map [arm64] (groovy-proposed/universe) [0.8.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ordered-map [armhf] (groovy-proposed/universe) [0.8.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ordered-map [s390x] (groovy-proposed/universe) [0.8.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ordered-map [riscv64] (groovy-proposed/universe) [0.8.1-2] (no packageset)
<LocutusOfBorg> hello, please reject lvm2 from focal unapproved queue
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (bionic-proposed) [12.2.13-0ubuntu0.18.04.2]
-queuebot:#ubuntu-release- Unapproved: rejected lvm2 [source] (focal-proposed) [2.03.07-1ubuntu1.20.04.1]
-queuebot:#ubuntu-release- Unapproved: shadow (focal-proposed/main) [1:4.8.1-1ubuntu5 => 1:4.8.1-1ubuntu6] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: rejected shadow [source] (focal-proposed) [1:4.8.1-1ubuntu6]
<xnox> amurray:  i do not believe this is time sensitive for uc20, as we already have something similar via image ppa.
<LocutusOfBorg> xnox, I found your initramfs-tools upload in focal unapproved queue
<LocutusOfBorg> I merged your changes and the new changes from the other pending SRU into one single one
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (focal-proposed/main) [0.136ubuntu6 => 0.136ubuntu6.20.04.1] (core, i386-whitelist)
<LocutusOfBorg> ^^ any any archive admin please reject all the previous uploads of this package in unapproved queue?
-queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (focal-proposed) [0.136ubuntu6.1]
-queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (focal-proposed) [0.136ubuntu6.20.04.3]
-queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (focal-proposed) [0.136ubuntu6.20.04.1]
<vorlon> amurray: right, SRUs are normally processed via the launchpad upload queues and not via SRU bugs.  And if it's being done in the security pocket it doesn't normally need SRU team input. Are you planning to put it to -proposed before publishing to -security? If so probably best to copy-package -b to the -proposed queue and then ping the SRU team member on duty for the day
<xnox> LocutusOfBorg:  well, there will be more initramfs-tools backports..... but yeah lvm2 & arm fix would be nice to go in.
<xnox> LocutusOfBorg:  but by doing this, we are at the back of the queue again =)
-queuebot:#ubuntu-release- Unapproved: nvidia-settings (focal-proposed/main) [440.64-0ubuntu1 => 440.82-0ubuntu0.20.04.1] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: nvidia-settings (bionic-proposed/main) [440.44-0ubuntu0.18.04.1 => 440.82-0ubuntu0.18.04.1] (ubuntu-desktop)
<RikMills> we now have libjs-jquery 3.3.1~dfsg-3 from src:jquery in main and libjs-jquery 3.5.1+dfsg-4 from src:node-jquery in universe
<RikMills> debian have removed src:jquery
<RikMills> anyone looking at this?
<amurray> vorlon: no we weren't planning to go via -proposed but wanted SRU team
<amurray> wanted SRU teams blessing due to version update for most releases
-queuebot:#ubuntu-release- New binary: openbabel [amd64] (groovy-proposed/universe) [3.1.1+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: openbabel [ppc64el] (groovy-proposed/universe) [3.1.1+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: openbabel [armhf] (groovy-proposed/universe) [3.1.1+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: openbabel [arm64] (groovy-proposed/universe) [3.1.1+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: openbabel [s390x] (groovy-proposed/universe) [3.1.1+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-5.3 [amd64] (bionic-proposed/main) [5.3.0-1021.23~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-5.3 [amd64] (bionic-proposed) [5.3.0-1021.23~18.04.1]
-queuebot:#ubuntu-release- Unapproved: gummi (focal-proposed/universe) [0.7.999-1 => 0.8.1-1ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: containerd [amd64] (groovy-proposed/main) [1.3.4-0ubuntu5] (no packageset)
-queuebot:#ubuntu-release- New binary: openbabel [riscv64] (groovy-proposed/universe) [3.1.1+dfsg-2] (kubuntu)
<coreycb> hello SRU team, the OpenStack Ussuri packages should be all set to release to focal-updates
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (focal-proposed/main) [1:0.8.1.1 => 1:0.8.4~0.20.04.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-181.211] (core, kernel)
<vorlon> amurray: I don't regard this as something that requires SRU team "blessing"; if you're looking for a technical review, I think talking to the SRU team member of the day is still best
<vorlon> yuck why does r-cran-knitr depend on node-highlight.js, that's going to be a problem for R on riscv64
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-181.211]
-queuebot:#ubuntu-release- Unapproved: apport (focal-proposed/main) [2.20.11-0ubuntu27.2 => 2.20.11-0ubuntu27.3] (core, i386-whitelist)
<hellsworth> hi sil2100: would you please take a look at libreoffice 6.4.4 stuck in unapproved
<hellsworth> #1856446
<hellsworth> https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1856446
<ubot5> Ubuntu bug 1856446 in libreoffice (Ubuntu Eoan) "[SRU] libreoffice 6.3.4 for eoan" [High,Fix released]
<hellsworth> oh sorry wrong link..
<hellsworth> https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1881007
<ubot5> Ubuntu bug 1881007 in libreoffice (Ubuntu Focal) "[SRU] libreoffice 6.4.4 for focal" [High,In progress]
-queuebot:#ubuntu-release- Packageset: Added jsunit to mozilla in bionic
-queuebot:#ubuntu-release- Packageset: Added jsunit to mozilla in eoan
-queuebot:#ubuntu-release- Packageset: Added jsunit to mozilla in xenial
<xnox> vorlon:  i'm confused on how to test for i386 any more.
<xnox> is there any environment variable that indicates which arch things are being tested for?
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-103.104] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-103.104~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-103.104~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-103.104] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1054.59] (no packageset)
-queuebot:#ubuntu-release- New binary: libplacebo [amd64] (groovy-proposed/universe) [1.29.1+dfsg1-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: libplacebo [i386] (groovy-proposed/universe) [1.29.1+dfsg1-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: libplacebo [ppc64el] (groovy-proposed/universe) [1.29.1+dfsg1-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: libplacebo [arm64] (groovy-proposed/universe) [1.29.1+dfsg1-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: libplacebo [armhf] (groovy-proposed/universe) [1.29.1+dfsg1-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: libplacebo [riscv64] (groovy-proposed/universe) [1.29.1+dfsg1-2] (i386-whitelist, kubuntu)
#ubuntu-release 2020-06-02
<amurray> vorlon: ok, thanks - how do I find out who is the SRU team member for today?
<RAOF> amurray: https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
-queuebot:#ubuntu-release- New binary: libplacebo [s390x] (groovy-proposed/universe) [1.29.1+dfsg1-2] (i386-whitelist, kubuntu)
<amurray> RAOF: thanks - somehow I missed that - would you be able to review the libseccomp updates currently in the security-proposed PPA https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages in light of LP #1876055
<ubot5> Launchpad bug 1876055 in libseccomp (Ubuntu Focal) "SRU: Backport 2.4.3-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base" [Medium,Confirmed] https://launchpad.net/bugs/1876055
<RAOF> Will do.
<RAOF> amurray: The focal upload appears to be missing a reference to LP #1876055?
<ubot5> Launchpad bug 1876055 in libseccomp (Ubuntu Focal) "SRU: Backport 2.4.3-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base" [Medium,Confirmed] https://launchpad.net/bugs/1876055
<RAOF> Hm. I guess that 1876055 doesn't actually apply to the focal package, as focal already has 2.4.3.
<RAOF> LP #1877633 should have the SRU paperwork filled out. Or, alternatively, you could mark it as a duplicate of 1876055 as a duplicate, as that's got the paperwork filled out already.
<ubot5> Launchpad bug 1877633 in libseccomp (Ubuntu Focal) "libseccomp 2.4.3 (and 2.4.2) is not correctly resolving (at least) the getrlimit syscall on arm64" [High,In progress] https://launchpad.net/bugs/1877633
<RAOF> Hm. You're dropped db-properly-reset-attribute-state.patch in the eoan package, and added fix-python-module-install-path.patch without mentioning either in the changelog? Is the python module fix not required in focal? (I can see that the db- patch is included in the new upstream)
<RAOF> Hm, not added, but added-to.
<amurray> RAOF: ah good point re the 2 bug numbers - I can either copy the paperwork over to 1877633 since that is in the changelog or dupe it against 1876055 - do you have a preference?
<RAOF> Well, all the packages before focal have both bugs in their chaneglogs :)
<amurray> RAOF: the python module fix was due to the differences in the debian packaging between eoan/focal IIRC (I prepared these a couple weeks ago so am having to refresh my memory on the details) - but if I forgot to mention it in the changelog that's no good so I'll update it to add that
<RAOF> I maybe have a slight preference for copying the content of 1876055 into 1877633, and then having details specific to how to test the backports in 1876055 (because focal only gets the new syscall, whereas previous series also get a backport)
<amurray> RAOF: gah ok looks like I should go over the changelog's with a fine-toothed comb ;) - thanks for taking a look over them - I'll redo the changelogs and do the bug shuffling and updates as you suggest - cheers
<RAOF> Ta. I've not noticed any other problems with them so far :)
<sil2100> hm, wonder what's going on with the arm64 autopkgtest instances
<cpaelzer> hi sil2100, in regard to +1 I've spotted a FTFBS on arm64/armhf in -proposed
<cpaelzer> that started as an item I had anyway (one of my uploads) but I'd hope to track down the root cause - chances are that might break more things than just my upload
<cpaelzer> and then I'd want to hold it back in proposed if possible
<cpaelzer> I'll let you know once I found something
<cpaelzer> sil2100: what do you mean in regard t arm64 autopkgtest ?
<cpaelzer> the not uncommon network issues connecting to the archive, or something new?
<sil2100> cpaelzer: which package FTBFS you have in mind?
<sil2100> cpaelzer: as for the arm64 ADT runs, maybe I'm just imagining things but the arm64 queue is huge
<cpaelzer> sil2100: my upload was src:spice, it was building fine end of last week
<cpaelzer> so I have some hop ethat whatever broke it might still be in -proposed
<cpaelzer> sil2100: the queue is even bigger on s390x which is more uncommon
<cpaelzer> sometimes the builders get stuck and we ping cjwatson or wgrant to unstcuk them - let me check if it looks like that again ...
<cpaelzer> oh wait
 * cpaelzer needs to wakr up
<cpaelzer> builders, but you are talking autopkgtest
<wgrant> Scalingstack bos02 s390x was a bit sad 12h ago
<wgrant> (but it's been fixed, and I've fixed the LP builders)
<cpaelzer> ok, thanks for the info wgrant
<cpaelzer> well active test numbers seem reasonable https://paste.ubuntu.com/p/vVb9bZh9dc/ so for now we can wait until it churns through its backlog
<Laney> Yep, that's the deal :(
<Laney> Bet you s390x finishes its queue before arm64
<Laney> this would all be more pleasing if we weren't down one cloud region
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1054.59]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-103.104]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-103.104~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-103.104]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-103.104~16.04.1]
<cpaelzer> sil2100: my arm FTFBS debugging is a sad story (always works when trying to recreate)
<sil2100> Ouch ;)
<cpaelzer> sil2100: but I have found something else haunting grovy proposed migration that I want to resolve - but ping you to avoid doing it twice at the same time
<sil2100> I'm looking into nfs-ganesha FTBFS, since it's needed for a mirco-transaction to complete
<cpaelzer> azure-cli was synced the last week but some bits were missing (synced late), due to that the tests were broken and thereby failed for many other packages
<cpaelzer> sil2100:  I have spotted 9 packages blocked by that
<cpaelzer> Logan: has triggered that for knacc - but there are many more
<cpaelzer> those I'll trigger now, they are not yet listed as retries in the test queue
<sil2100> cpaelzer: ACK o/
<sil2100> oh, and earlier I also easy-hinted yara, since the autohinter missed a package, so hopefully that will also migrate
<Laney> not listed as retries> why?
<cpaelzer> Laney: I just checked the autopkgtest queue and haven't seen them listed there
<Laney> cpaelzer: oh, you mean nobody retried those already, I see
<cpaelzer> yes
<mwhudson> i assume there's no equivalent of rescoring for autopkgtest queues?
<cpaelzer> I'd not want to put more onto the queue than needed
<Laney> I thought you meant not lited as failure in excuses
<cpaelzer> oh ok, no Laney I was not meaning that
<Laney> mwhudson: nope, only the huge and not-huge queues (retries go into the latter)
<Laney> I think rabbitmq does have some kind of concept of priority though
<Laney> so if someone wanted to look into how to achieve that, we could
<mwhudson> i guess i'll have to go to bed at a reasonable hour and see if the queue has drained by morning :)
<Laney> bloomin perl uploads eh
<cpaelzer> hmm, this might be better off runngin with all-proposed than listing 10 packages
<cpaelzer> does one of you know if it will make all the packages that "were used" due to all-propsoed migrate - or would it only recognize those if listed as trigger
<Laney> the triggers are not considered outside of the test run itself
<Laney> i.e. all-proposed (or extra triggers) can make inconsistent things migrate
<cpaelzer> I know that part, let me add more detail to my question ...
<cpaelzer> I can essentially either do a) trigger=1,trigger=2,trigger=3,... or b) trigger=1,all-proposed=1; but I'm wondering if (b) will unblock 2 and 3 ...?
<Laney> ok, I see, you need to add the triggers to have the test recorded against that item, yes
<cpaelzer> ok, thanks for confirming
<Laney> maybe use retry-autopkgtest-regressions
<cpaelzer> can that combine multiple?
<Laney> that usually tries to batch up things if it can
<cpaelzer> I do as well, but I want to run the tests for the 8 stalled pkg's as one
<Laney> yes, it does that
<cpaelzer> oh, /me relooks for that again ...
<Laney> well, run it, it just prints the URLs, so no harm if it's not what you want
<cpaelzer> ok submitted, that should eventually help six/python-jmespath/javaproperties/python-tz
<cpaelzer> I'll keep a tab open and recheck the results tomorow
<cpaelzer> sil2100: the rebuild of my arm64/armhf builds on src:spice worked in the archive as well now
<cpaelzer> which is fine for the PKG to migrate, but odd as nothing was changed
<cpaelzer> unless we really have a three-phase issue of "working on thursday" - "broken on the weekend" - "good now"
<cpaelzer> keep an eye out for odd arm64 fails and let me know, maybe we can detect a parrtern
<cpaelzer> lol, "pattern" obviously
-queuebot:#ubuntu-release- New binary: nfs-ganesha [s390x] (groovy-proposed/main) [3.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nfs-ganesha [amd64] (groovy-proposed/main) [3.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nfs-ganesha [ppc64el] (groovy-proposed/main) [3.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nfs-ganesha [arm64] (groovy-proposed/main) [3.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nfs-ganesha [armhf] (groovy-proposed/main) [3.2-2] (no packageset)
<sil2100> cpaelzer: hah ;)
<cpaelzer> cjwatson: for groovy https://code.launchpad.net/~paelzer/ubuntu/+source/openssh/+git/openssh/+merge/384814  is tested and ready to fix https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1876320 - my question to you - do you want to upload that to Debian and sync? Or shall I upload to Groovy as Ubuntu Delta for now?
<ubot5> Ubuntu bug 1876320 in openssh (Ubuntu Focal) "Port parameter sshd_config is 22 AND whatever you specify" [Low,In progress]
<cjwatson> cpaelzer: I'm in the middle of merging 8.3, so can't conveniently upload it just now.  Do what you like
<cpaelzer> cjwatson: well, merging 8.3 will fix it as well - IIRC the fix is in there
<cpaelzer> let me check to be sure
<cjwatson> cpaelzer: No, it's not
<cjwatson> I checked
<cpaelzer> oh, ok
<cjwatson> cpaelzer: Please can you file a Debian bug as a reminder for me to cherry-pick that?
<cpaelzer> I'll upload as ubuntu Delta to groovy now
<cpaelzer> cjwatson: I'll file you a Debian bug to pick it up at or after the 8.3 merge
<cjwatson> (No need to attach a patch, just point to the upstream commit)
<cjwatson> Thanks
<RikMills> could someone no change rebuild libclass-xsaccessor-perl?
<RikMills> anothee perl mini transition has made pkg-kde-tools uninstallable again
<cpaelzer> cjwatson: filed as 962035 and linked from the LP bug so it can be found from both bug trackers
<cpaelzer> RikMills: I can issue that no change rebuild if you want
<cpaelzer> RikMills: nay other context I need to be aware of - dependencies, common test issues ... ?
<RikMills> cpaelzer: would be appreciated :)
<RikMills> cpaelzer: I don't think so. the last rebuild just on the main perl tests which are running now
<RikMills> *just waited
<cpaelzer> ok, for 5.30.3 then as I see
<RikMills> cpaelzer: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962012
<cpaelzer> I'll be queuing and tracking its build/migration
<ubot5> Debian bug 962012 in release.debian.org "binnmus for perl mini-transition 5.30.3" [Normal,Open]
<RikMills> there is that bug for the other bin nmu needed
<RikMills> we can't sync those, so someone will have to rebuild those here soon as well
-queuebot:#ubuntu-release- Unapproved: openblas (focal-proposed/universe) [0.3.8+ds-1 => 0.3.8+ds-1ubuntu0.20.04.1] (kubuntu)
<cpaelzer> RikMills: perl 5.30.3 still isn't build on riscv
<cpaelzer> RikMills: I think my rebase has to wait a bit
<cpaelzer> sorry, "rebuild" not "rebase"
<RikMills> cpaelzer: thanks for noticing!
<cpaelzer> I have this and the other packages ready for no change rebuilds
<RikMills> ty
<cpaelzer> they seem not to be interlocked with each other and seem not to wait on anything else but perl
<cpaelzer> I have the tab on the perl build open and will issue them once ready
<cpaelzer> sil2100: all but the extra long queue architectures worked on azure-cli
<cpaelzer> so that will unblock over night
<cpaelzer> I'm shivering that I ask, but there is a lot of haskell in update-excuses - is anyone looking at that or has an understanding what we wait for?
<cpaelzer> from far away it seems like a few FTFBS and a lot of dependency waits due to that
<sil2100> Wimpress: hey! So I see ubuntu-mate has folder-color in its supported seed
<sil2100> Wimpress: so I'm currently feeling trigger happy to remove that package, with the rationale of it no longer working as python-nautilus has been removed (with only the python3 bindings remaining)
<cpaelzer> can I make reverse-depends / apt-cache rdepends / apt-rdepends (or any other tool) to only list me those packges depending on an (outdated) version. Like reverse-depends --release=groovy 'foo<1.2' ?
<sil2100> Wimpress: I didn't see any development on this package since at least bionic
<cpaelzer> all of these tools give me some unknown package error if I try it like that
<cpaelzer> I use these tools often looking forward, butnow I need to look backwards to see what still needs to be touched depending on an old package of a trasnition
<cpaelzer> I'm sure this exists, yet how exactly is still hiding from me
<sil2100> cpaelzer: hm, I must say nothing comes into my mind so far, usually when I need to check for these things it's when binary packages bump their soversion, so I usually have a good overview doing reverse-depends libfoo3 (when the new one is libfoo4)
<sil2100> Wimpress: any objections for removing it for now? I guess it can be reuploaded once it has python3 support?
<cpaelzer> sil2100: yeah I know that with versioned source names
<Wimpress> sil2100: I am planning to update it this cycle.
<cpaelzer> sil2100: but here it is just a hard dep <<version
<cpaelzer> and the new pacakhe now is >=version, so I see a lot of dependency issues
<cpaelzer> rebuilds will fix it and I "manuall" detected a few, but there must be a programatic way to find all candidates I need to touch ...
<sil2100> Wimpress: I suppose somewhere later in the cycle, right?
<sil2100> hm, actually, maybe I'll instead just try it with python3
<sil2100> Wimpress: ok, nevermind! I've got this
<cpaelzer> sil2100: I have rechecked the perl dependenceis for 5.30.3 - there are a bunch which have alternate deps that make them succeed and the four already identified packages
<cpaelzer> sil2100: it now completed build on riscv64 and was published, I'll upload the no change rebuilds
<cpaelzer> as mentioned before once they all have passed we need to re-trigger most tests of perl with them
<cpaelzer> I'll take a look at that either later today or tomorrow then
<cpaelzer> sil2100: and for the version-reverse-dep I now have a three line command piping things together
<cpaelzer> everyone that knows the right way will shiver (and hopefully let me know about a better way), but this works https://paste.ubuntu.com/p/mPQKPkxxPc/
<cpaelzer> RikMills: ^^ FYI since you asked for these perl bits
<RikMills> cpaelzer: aha. thanks!
<cpaelzer> and while uploading LocutusOfBorg and NikoTyni already beat me pushing that :-)
<cpaelzer> anyway it is in progress
<sil2100> cpaelzer: ooh!
<sil2100> In the meantime I hopefully unblocked nautilus-python, but I guess we'll only start seeing results once the arm64 and s390x tests complete
<RikMills> cpaelzer: right. it was going to be picked up soonish anyway, and without the rebuilds lintian and perhaps more cannot be installed in proposed
<RikMills> thankyou to LocutusOfBorg and NikiTyni :)
<RikMills> I was just trying to make some progress merging 80+ KDE things from debian earlier, and was sad to seed they could not build
<RikMills> *to see
<Laney> what have security done to the autopkgtest queues ð±ð±ð±
<RikMills> omfg
<RikMills> maybe I will come back to see how migrations are going in say, a week!
-queuebot:#ubuntu-release- New binary: nfs-ganesha [riscv64] (groovy-proposed/main) [3.2-2] (no packageset)
<mdeslaur> huh? what'd I do?
<Laney> oh just perl updates to all the things
<apw> mdeslaur, did you patch perl ?
<mdeslaur> oh, hah, yeah
<mdeslaur> do we need more hamsters?
<mdeslaur> oh wow, that's a lot of tests
<apw> ouch ... if this is right there are 79k jobs on the queues
<mdeslaur> you can call me 'killer' from now on
<mdeslaur> can you cancel them? though, I'd like for the xenial ones to run, but the others can be cancelled
<Laney> if you're not interested, sure
<mdeslaur> I'm only interested in xenial
<Laney> okey
<Laney> will do after meetings
<mdeslaur> thanks Laney
-queuebot:#ubuntu-release- Unapproved: nautilus (focal-proposed/main) [1:3.36.2-0ubuntu1 => 1:3.36.3-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected nautilus [source] (focal-proposed) [1:3.36.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: nautilus (focal-proposed/main) [1:3.36.2-0ubuntu1 => 1:3.36.3-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted gummi [source] (focal-proposed) [0.8.1-1ubuntu0.20.04.1]
 * Laney terminates
<LocutusOfBorg> cpaelzer, but I didn't touch any perl bit today, did you upload something on my behalf? thanks :D
<ginggs> would someone please accept slepc and petsc4py from groovy new queue?
-queuebot:#ubuntu-release- Unapproved: cloud-init (focal-proposed/main) [20.1-10-g71af48df-0ubuntu5 => 20.2-45-g5f7825e2-0ubuntu1~20.04.1] (core, edubuntu, ubuntu-cloud)
<cpaelzer> LocutusOfBorg: hmm, maybe the no change rebuild inserted te last uploader instead of me - that would be odd
<cpaelzer> LocutusOfBorg: but if you didn't touch it it is the noly explanation I can come up with
<cpaelzer> indeed, the changes file have taken over the last uploader, dear dch what did you do
<cpaelzer> sorry then LocutusOfBorg, but since I'll track and push it anyway you are good
<cpaelzer> ignore it if you get and further pings on it
<LocutusOfBorg> no problem cpaelzer :) I just have been thanked for doing it over telegram on your behalf :D this is why I went on the web page and saw your name on signoff :)
-queuebot:#ubuntu-release- Unapproved: fwupd (groovy-proposed/main) [1.3.9-4ubuntu1 => 1.3.9-4ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (groovy-proposed/main) [1.3.9-4ubuntu1 => 1.3.9-4ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (groovy-proposed/main) [1.3.9-4ubuntu1 => 1.3.9-4ubuntu1] (core)
<vorlon> xnox: arch being tested for> DEB_HOST_ARCH for the cross-arch case?
<xnox> Yeah, something like that
-queuebot:#ubuntu-release- New: accepted nfs-ganesha [armhf] (groovy-proposed) [3.2-2]
-queuebot:#ubuntu-release- New: accepted nfs-ganesha [riscv64] (groovy-proposed) [3.2-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [arm64] (groovy-proposed) [1.29.1+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [i386] (groovy-proposed) [1.29.1+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [riscv64] (groovy-proposed) [1.29.1+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted nfs-ganesha [amd64] (groovy-proposed) [3.2-2]
-queuebot:#ubuntu-release- New: accepted nfs-ganesha [ppc64el] (groovy-proposed) [3.2-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [armhf] (groovy-proposed) [1.29.1+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [s390x] (groovy-proposed) [1.29.1+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted nfs-ganesha [s390x] (groovy-proposed) [3.2-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [ppc64el] (groovy-proposed) [1.29.1+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted nfs-ganesha [arm64] (groovy-proposed) [3.2-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [amd64] (groovy-proposed) [1.29.1+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted openbabel [arm64] (groovy-proposed) [3.1.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted openbabel [ppc64el] (groovy-proposed) [3.1.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted openbabel [s390x] (groovy-proposed) [3.1.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted ordered-map [s390x] (groovy-proposed) [0.8.1-2]
-queuebot:#ubuntu-release- New: accepted openbabel [amd64] (groovy-proposed) [3.1.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted openbabel [riscv64] (groovy-proposed) [3.1.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted openbabel [armhf] (groovy-proposed) [3.1.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted ordered-map [riscv64] (groovy-proposed) [0.8.1-2]
-queuebot:#ubuntu-release- New: accepted ordered-map [amd64] (groovy-proposed) [0.8.1-2]
-queuebot:#ubuntu-release- New: accepted ordered-map [armhf] (groovy-proposed) [0.8.1-2]
-queuebot:#ubuntu-release- New: accepted petsc4py [riscv64] (groovy-proposed) [3.13.0-2]
-queuebot:#ubuntu-release- New: accepted slepc [armhf] (groovy-proposed) [3.13.2+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted slepc [s390x] (groovy-proposed) [3.13.2+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted ordered-map [arm64] (groovy-proposed) [0.8.1-2]
-queuebot:#ubuntu-release- New: accepted slepc [arm64] (groovy-proposed) [3.13.2+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted ordered-map [ppc64el] (groovy-proposed) [0.8.1-2]
-queuebot:#ubuntu-release- New: accepted slepc [riscv64] (groovy-proposed) [3.13.2+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted paraglob [armhf] (groovy-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted paraglob [s390x] (groovy-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted petsc4py [armhf] (groovy-proposed) [3.13.0-2]
-queuebot:#ubuntu-release- New: accepted petsc4py [s390x] (groovy-proposed) [3.13.0-2]
-queuebot:#ubuntu-release- New: accepted slepc [ppc64el] (groovy-proposed) [3.13.2+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted paraglob [riscv64] (groovy-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted petsc4py [ppc64el] (groovy-proposed) [3.13.0-2]
-queuebot:#ubuntu-release- New: accepted petsc4py [arm64] (groovy-proposed) [3.13.0-2]
-queuebot:#ubuntu-release- New: accepted slepc [amd64] (groovy-proposed) [3.13.2+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted paraglob [amd64] (groovy-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted paraglob [ppc64el] (groovy-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted paraglob [arm64] (groovy-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted petsc4py [amd64] (groovy-proposed) [3.13.0-2]
<vorlon> xnox: well, specifically that.  For cross-arch autopkgtests, DEB_HOST_ARCH is set.
<xnox> Oh
<xnox> Ok
-queuebot:#ubuntu-release- Unapproved: gtk+3.0 (focal-proposed/main) [3.24.18-1ubuntu1 => 3.24.20-0ubuntu1] (i386-whitelist, ubuntu-desktop)
<Eickmeyer> Hi release team. I just did a syncpackage for ardour, but it looks like it's going to get held-up in proposed for FTBFS on ppc64el. Speaking to the devs, PPC support is WIP and might actually be dropped.
<Eickmeyer> I informed the Debian Multimedia Team about the issue, but in the meantime can we get a hint on ppc64el for Ardour? I'd appreciate it. :)
<tumbleweed> the solution to that isn't a hint, but a binary removal of the old ppc64el build
<Eickmeyer> Or that. ^
<tumbleweed> ubuntu-archive: ^^
<Eickmeyer> tumbleweed: Thanks. :)
<Eickmeyer> In fact, the next major release *will* drop ppc, just confirmed.
<mwhudson> strange to see a big autopkgtest queue on s390x, infrastructure issues?
<xnox> mwhudson:  yes
<xnox> and catching up
<xnox> plus perl security update on all series
<mwhudson> ah yes that would be why there are 1000s of tests waiting on xenial?
<xnox> Yeah
<xnox> I think we were wat 50,000+ tests this morning.
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (focal-proposed) [20.2-38-g8377897b-0ubuntu1~20.04.1]
<blackboxsw> thx, eoan bionic and xenial still in progress :/
<blackboxsw> will probably wrap those up and ping sru vanguard tomorrow
<xnox> mwhudson:  publishing
<xnox> bah wrong channel
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (focal-proposed) [20.1-2-g42a9667f-0ubuntu1~20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (bionic-proposed) [20.1-2-g42a9667f-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (xenial-proposed) [20.1-2-g42a9667f-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (focal-proposed) [6.0.0-0ubuntu8.1]
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (focal-proposed) [1:4.2-3ubuntu6.2]
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (eoan-proposed) [1:4.0+dfsg-0ubuntu9.7]
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (bionic-proposed) [1:2.11+dfsg-1ubuntu7.27]
-queuebot:#ubuntu-release- New binary: slepc4py [amd64] (groovy-proposed/universe) [3.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc4py [s390x] (groovy-proposed/universe) [3.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc4py [ppc64el] (groovy-proposed/universe) [3.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc4py [armhf] (groovy-proposed/universe) [3.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc4py [arm64] (groovy-proposed/universe) [3.13.0-2] (no packageset)
<vorlon> Eickmeyer: ardour removed from ppc64el and riscv64; upstream's code clearly has a bug here and I'm further skeptical of the entire per-architecture thing they're implementing here, but it's a desktop app and ppc64el isn't a desktop arch, so
-queuebot:#ubuntu-release- New binary: slepc4py [riscv64] (groovy-proposed/universe) [3.13.0-2] (no packageset)
<Eickmeyer> vorlon: Thanks!
#ubuntu-release 2020-06-03
<tumbleweed> upstreams tend to have far narrower view of architecture support than we do
-queuebot:#ubuntu-release- Unapproved: clamav (bionic-proposed/main) [0.102.3+dfsg-0ubuntu0.18.04.1 => 0.102.3+dfsg-0ubuntu0.18.04.2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted inkscape [source] (focal-proposed) [0.92.5-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (focal-proposed) [0.8.3-1ubuntu12.1]
-queuebot:#ubuntu-release- Unapproved: rejected pegjs [source] (focal-proposed) [0.10.0-3~ubuntu1.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted pegjs [source] (focal-proposed) [0.10.0-3~ubuntu1.20.04.1]
<cpaelzer> Policy question: I found a Debian package that places a .list file in /etc/apt/sources.list.d that enables buster-backports - that won't ever work well in Ubuntu, but is that as bad as needing a package removal?
<cpaelzer> I could file a removal request and leave it to the decision of the ubuntu-archive member handling it, but if there is a pre-discussion to be had I'm all for it
<cpaelzer> doko: seb128: apw: you are thre AAs that might be around atm - opinions on ^^ ?
<doko> which package is this?
<RAOF> cpaelzer: Is there a reason not to simply upload a new version that removes that .list file?
<RAOF> Because removal from the archive is not going to unbreak systems which have already installed it.
<cpaelzer> package is freedombox of src:plinth
<cpaelzer> RAOF: we'd then have Delta to maintain, do regular merges on a rather complex (as it seems) package and TBH I don't know if things of that package will work well then. They must have had a reason to add this (changelog mentions it is there to make some of their components installable)
<cpaelzer> I'm not saying we can't just stop it from doing so
<cpaelzer> but this isn't a package I want to regularly look at and update
<cpaelzer> I'd rather file a bug with Debian to stop doing so - at least if running on Ubuntu and derivatives
<cpaelzer> it is blocked in proposed due to this behavior, so we won't get a new version until this is somehow solved
<doko> even for Debian, should be RC severity
<cpaelzer> how about this approach, I'll file a LP bug and mark it update-excuse (to avoid others doignt he same debug) and a Debian RC bug describing the issue
<RAOF> âWe need to add an extra repository so that we can install our stuffâ sounds like it should be in  that extra repository :)
<cpaelzer> then we can see what happens
<doko> 19.0 has "  * upgrades: Fix premature adding of buster-backports sources"
<cpaelzer> doko: it came back in between 20.3 and 20.10
<cpaelzer> I feel good now, thanks for the discussion doko and RAOF - I think filing the bugs is a good approach
<cpaelzer> it doesn't stop anything else atm, so it isn't super-urgent to be unblocked
<cpaelzer> doko: can you erfer to a particular part of the Debian policy that makes this a RC bug so I could refer to it in my bug?
<doko> a package should not mess with sources ... I mean, google-chrome is doing the same, but that's an archive with just one packge
<doko> no
<doko> but it adds sources without informing the user ... backports ...
<cpaelzer> thank you for the discussion doko and RAOF
<doko> sil2100, apw: please ignore the rapmap autopkg test for any version, for any arch except for amd64. the package is only built there
-queuebot:#ubuntu-release- New binary: slepc4py [s390x] (groovy-proposed/universe) [3.13.0-2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc4py [ppc64el] (groovy-proposed/universe) [3.13.0-2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc4py [amd64] (groovy-proposed/universe) [3.13.0-2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc4py [arm64] (groovy-proposed/universe) [3.13.0-2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc4py [armhf] (groovy-proposed/universe) [3.13.0-2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc4py [riscv64] (groovy-proposed/universe) [3.13.0-2build1] (no packageset)
<ricotz> hello, could someone please take a look at vala 0.40.23-0ubuntu1 which is waiting in the bionic queue
-queuebot:#ubuntu-release- New binary: mandelbulber2 [amd64] (groovy-proposed/universe) [2.20-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mandelbulber2 [ppc64el] (groovy-proposed/universe) [2.20-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mandelbulber2 [s390x] (groovy-proposed/universe) [2.20-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted slepc4py [amd64] (groovy-proposed) [3.13.0-2]
-queuebot:#ubuntu-release- New: accepted slepc4py [armhf] (groovy-proposed) [3.13.0-2]
-queuebot:#ubuntu-release- New: accepted slepc4py [riscv64] (groovy-proposed) [3.13.0-2]
-queuebot:#ubuntu-release- New: accepted slepc4py [amd64] (groovy-proposed) [3.13.0-2build1]
-queuebot:#ubuntu-release- New: accepted slepc4py [armhf] (groovy-proposed) [3.13.0-2build1]
-queuebot:#ubuntu-release- New: accepted slepc4py [riscv64] (groovy-proposed) [3.13.0-2build1]
-queuebot:#ubuntu-release- New: accepted slepc4py [arm64] (groovy-proposed) [3.13.0-2]
-queuebot:#ubuntu-release- New: accepted slepc4py [s390x] (groovy-proposed) [3.13.0-2]
-queuebot:#ubuntu-release- New: accepted slepc4py [ppc64el] (groovy-proposed) [3.13.0-2build1]
-queuebot:#ubuntu-release- New: accepted slepc4py [ppc64el] (groovy-proposed) [3.13.0-2]
-queuebot:#ubuntu-release- New: accepted slepc4py [s390x] (groovy-proposed) [3.13.0-2build1]
-queuebot:#ubuntu-release- New: accepted slepc4py [arm64] (groovy-proposed) [3.13.0-2build1]
-queuebot:#ubuntu-release- New: accepted containerd [amd64] (groovy-proposed) [1.3.4-0ubuntu4]
-queuebot:#ubuntu-release- New: accepted containerd [amd64] (groovy-proposed) [1.3.4-0ubuntu5]
-queuebot:#ubuntu-release- New: accepted libpod [amd64] (groovy-proposed) [1.6.4+dfsg1-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted libpod [armhf] (groovy-proposed) [1.6.4+dfsg1-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted libpod [riscv64] (groovy-proposed) [1.6.4+dfsg1-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted nomad [amd64] (groovy-proposed) [0.10.5+dfsg1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libpod [arm64] (groovy-proposed) [1.6.4+dfsg1-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted libpod [s390x] (groovy-proposed) [1.6.4+dfsg1-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted libpod [ppc64el] (groovy-proposed) [1.6.4+dfsg1-3ubuntu1]
<doko> mwhudson: rustc on riscv64: Missing build dependencies: rustc (>= 1.42.0+dfsg)
<doko> built in focal
-queuebot:#ubuntu-release- New: accepted lsp-plugins [amd64] (groovy-proposed) [1.1.22-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted lsp-plugins [armhf] (groovy-proposed) [1.1.22-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted lsp-plugins [arm64] (groovy-proposed) [1.1.22-0ubuntu1]
<mwhudson> doko: yes, i don't understand what is going on
<mwhudson> (latest rustc ftbfs)
-queuebot:#ubuntu-release- New binary: mandelbulber2 [arm64] (groovy-proposed/universe) [2.20-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mandelbulber2 [armhf] (groovy-proposed/universe) [2.20-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: busybox (focal-proposed/main) [1:1.30.1-4ubuntu6 => 1:1.30.1-4ubuntu6.1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: nomad-driver-lxc [s390x] (groovy-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nomad-driver-lxc [ppc64el] (groovy-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nomad-driver-lxc [amd64] (groovy-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nomad-driver-lxc [arm64] (groovy-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nomad-driver-lxc [armhf] (groovy-proposed/universe) [0.1.0-1] (no packageset)
<doko> mwhudson: you mean, rustc 1.42?
-queuebot:#ubuntu-release- New sync: libnma (groovy-proposed/primary) [1.8.28-2]
<LocutusOfBorg> can anybody please approve it? ^^ it is split out from the new network-manager-applet source package
<LocutusOfBorg> seb128, ^^
<seb128> LocutusOfBorg, I'm unsure in what order things should go, it would probably make sense to wait for n-m-applet to be uploaded so they are a consistent set?
<LocutusOfBorg> the problem is that if I upload, it will be BD_unistallable until the libnma is done
<LocutusOfBorg> I'm updating the git repo
<LocutusOfBorg> ok I failed to do the git stuff
<LocutusOfBorg> and uploaded in Ubuntu
<LocutusOfBorg> do you think you can import the version on git?
-queuebot:#ubuntu-release- Unapproved: alsa-ucm-conf (focal-proposed/main) [1.2.2-1 => 1.2.2-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted vala [source] (bionic-proposed) [0.40.23-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libnma [sync] (groovy-proposed) [1.8.28-2]
<seb128> LocutusOfBorg, k, accepted, please follow up next with the applet :)
-queuebot:#ubuntu-release- New binary: libnma [amd64] (groovy-proposed/none) [1.8.28-2] (no packageset)
<LocutusOfBorg> seb128, applet is already uploaded, please sync the git with the changes if you can :D
<seb128> LocutusOfBorg, hum, why didn't you use the vcs?
<LocutusOfBorg> seb128, I'm not sure about how to proceed
-queuebot:#ubuntu-release- Unapproved: accepted djvulibre [source] (bionic-proposed) [3.5.27.1-8ubuntu0.2]
<seb128> shrug
<LocutusOfBorg> I mean, I can git push, but I don't want to mess with your workflow
<ricotz> rbasak, thank you for processing vala/bionic
-queuebot:#ubuntu-release- Unapproved: gjs (focal-proposed/main) [1.64.2-1ubuntu1~20.04.1 => 1.64.3-1~ubuntu20.04.1] (desktop-core, desktop-extra, i386-whitelist, mozilla)
<rbasak> ricotz: yw!
<LocutusOfBorg> seb128, let me know if I can git push, this is where I pushed changes https://github.com/LocutusOfBorg/ubuntu-applet
<cpaelzer> hmm, this is FTFBS proliferation - is there a tool that allows me "restart all builds on src:haskell-* that are in groovy-proposed and failed to build" ?
<cpaelzer> I might eventually need to be a bit more granular on the "haskell-*" part, but does such a tool exist at all?
<seb128> LocutusOfBorg, did you git merge from salsa?
<LocutusOfBorg> seb128, I failed in doing it
<seb128> shrug
<seb128> it's becoming more work now that I had done it myself :/
<cjwatson> cpaelzer: That's all scriptable using the API but I'm not aware of a tool
<cpaelzer> ok, thanks cjwatson
<cpaelzer> if I end up with more than 50-100 I might take a look at the API then
<cpaelzer> thanks
<LocutusOfBorg> can anybody please accept libnma-common from queue?
<doko> seb128: why do you demote childsplay, and don't remove it?
<seb128> doko, in case someone wants to fix it, Debian didn't remove it yet either ... but feel free if you prefer
<seb128> LocutusOfBorg, NEWed
<doko> seb128: the dependency won't come back, so it will require a new upload
<seb128> right
-queuebot:#ubuntu-release- New: accepted libnma [amd64] (groovy-proposed) [1.8.28-2]
<doko> and it's removed from testing
<seb128> but it's listed on https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html this way
<seb128> anyway, feel free to remove it if you prefer, I don't care much either way
<LocutusOfBorg> thanks
-queuebot:#ubuntu-release- Unapproved: rejected docker.io [source] (focal-proposed) [19.03.8-0ubuntu1.20.04]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-keyring [source] (xenial-proposed) [2012.05.19.1]
<Laney> woot
-queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:20.04.10 => 1:20.04.10.1] (core)
-queuebot:#ubuntu-release- New binary: mandelbulber2 [riscv64] (groovy-proposed/universe) [2.20-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected apport [source] (focal-proposed) [2.20.11-0ubuntu27.3]
-queuebot:#ubuntu-release- Unapproved: update-manager (bionic-proposed/main) [1:18.04.11.12 => 1:18.04.11.13] (core)
-queuebot:#ubuntu-release- Unapproved: update-manager (eoan-proposed/main) [1:19.04.8 => 1:19.04.8.1] (core)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (focal-proposed/main) [0.136ubuntu6 => 0.136ubuntu6.1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (focal-proposed) [0.136ubuntu6.20.04.1]
-queuebot:#ubuntu-release- Unapproved: apport (focal-proposed/main) [2.20.11-0ubuntu27.2 => 2.20.11-0ubuntu27.3] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: cloud-init (eoan-proposed/main) [19.4-33-gbb4131a2-0ubuntu1~19.10.1 => 20.2-45-g5f7825e2-0ubuntu1~19.10.1] (core, edubuntu, ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [19.4-33-gbb4131a2-0ubuntu1~18.04.1 => 20.2-45-g5f7825e2-0ubuntu1~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (focal-proposed/main) [20.1-10-g71af48df-0ubuntu5 => 20.2-45-g5f7825e2-0ubuntu1~20.04.1] (core, edubuntu, ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [19.4-33-gbb4131a2-0ubuntu1~18.04.1 => 20.2-45-g5f7825e2-0ubuntu1~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (eoan-proposed/main) [19.4-33-gbb4131a2-0ubuntu1~19.10.1 => 20.2-45-g5f7825e2-0ubuntu1~19.10.1] (core, edubuntu, ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (focal-proposed) [0.136ubuntu6.1]
-queuebot:#ubuntu-release- New binary: pyqt5-sip [riscv64] (groovy-proposed/universe) [12.8.0-1] (no packageset)
<mwhudson> ubuntu-archive can someone reject https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=golang-1.14 i want to add another patch
<RAOF> mwhudson: Done.
-queuebot:#ubuntu-release- Unapproved: rejected golang-1.14 [source] (focal-proposed) [1.14.3-2ubuntu1~20.04.1]
#ubuntu-release 2020-06-04
<mwhudson> hah, that upload probably wouldn'
<mwhudson> t have built anyway
-queuebot:#ubuntu-release- Unapproved: live-build (focal-proposed/main) [3.0~a57-1ubuntu38.20.04.1 => 3.0~a57-1ubuntu38.20.04.2] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: apport (focal-proposed/main) [2.20.11-0ubuntu27.2 => 2.20.11-0ubuntu27.3] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: rejected apport [source] (focal-proposed) [2.20.11-0ubuntu27.3]
-queuebot:#ubuntu-release- New binary: pyqt5-sip [amd64] (groovy-proposed/universe) [12.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyqt5-sip [arm64] (groovy-proposed/universe) [12.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyqt5-sip [armhf] (groovy-proposed/universe) [12.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyqt5-sip [ppc64el] (groovy-proposed/universe) [12.8.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: memcached (eoan-proposed/main) [1.5.10-0ubuntu3 => 1.5.10-0ubuntu3.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: memcached (focal-proposed/main) [1.5.22-2 => 1.5.22-2ubuntu0.1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: pyqt5-sip [s390x] (groovy-proposed/universe) [12.8.0-1] (no packageset)
<LocutusOfBorg> can anybody please recreate and update ubuntu chroots? there is a bug fixed in debhelper, I can confirm the fix, but even with the fixed debhelper migrating in groovy release ppc64el is still sad
<LocutusOfBorg> (please don't retry the build)
<LocutusOfBorg> https://launchpadlibrarian.net/482665193/buildlog_ubuntu-groovy-ppc64el.telegram-purple_1.4.3-3_BUILDING.txt.gz
<LocutusOfBorg> dpkg-genbuildinfo: error: cannot fstat file ../telegram-purple-dbgsym_1.4.3-3_ppc64el.ddeb: No such file or directory
<LocutusOfBorg> looks like somewhere an old debhelper is used, not the one that is installed in the chroot
<LocutusOfBorg> I tried a build from a newly created local ppc64el chroot and worked
<cjwatson> LocutusOfBorg: That doesn't seem plausible.  There's nowhere that an old debhelper could live.  The problem is something else
<cjwatson> LocutusOfBorg: Did your chroot have pkgbinarymangler in it?
<cjwatson> LocutusOfBorg: Perhaps you could try the latest cpc-buildd image, which would be what we'd update the LP chroots to if we updated them: https://launchpad.net/~cloud-images/+livefs/ubuntu/groovy/cpc-buildd/+build/220089
<cjwatson> (You want livecd.ubuntu-base.rootfs.tar.gz from that)
<LocutusOfBorg> cjwatson, I don't have binarymangler, it was a pbuilder chroot
<LocutusOfBorg> is it possible for an ubuntu-archive admin to kick out gnome-chemistry-utils because of debian bug: #947529? it can't be built since focal
<ubot5> Debian bug 947529 in src:gnome-chemistry-utils "gnome-chemistry-utils: build-depends on deprecated gnome-doc-utils" [Serious,Open] http://bugs.debian.org/947529
<cjwatson> LocutusOfBorg: I think it's necessary to try the candidate new chroot before stating that a new chroot will fix it; and this is the sort of thing where you need more accuracy than a pbuilder chroot will provide
<doko> sil2100, apw, Laney, bdmurray: please ignore the rapmap autopkg test for any version, for any arch except for amd64. the package is only built there
<LocutusOfBorg> cjwatson, actually I'm trying my new chroot with an added b-d on pkgbinarymangler :)
<LocutusOfBorg> I know it might be not the same, but easier for me to test it
<cjwatson> LocutusOfBorg: Anyway chances of a new chroot fixing this kind of thing seem quite negligible
<cjwatson> It's very likely some other complicated interaction that doesn't show up in your less-accurate setup, I'm afraid
<cjwatson> Normally all that new chroots might fix would be possibly some kind of build-dep installation failure, or of course slow build-dep installation
<cjwatson> debhelper isn't even installed in the chroots to start with
<Laney> doko: ok, pushed, fwiw a MP or even giving the text of a hint would make it a little bit easier
<doko> "the package is only built there", but thanks
<Laney> hm?
<doko> tseliot: looking at primus-vk in -proposed, do the depends on the virtual packages need adjustments, or should the package not built at all?
<tseliot> doko, do you have a link I can have a look at?
<doko> tseliot: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#primus-vk
<tseliot> doko, I think we can drop it, since it expects nvidia packages that quite different from ours
<doko> tseliot: could you file a removal bug with the reasoning and assign it to ubuntu-archive?
<doko> ginggs: fyi, ^^^
<doko> LocutusOfBorg, tumbleweed: I see you gave back primer3/s390x. any follow-up on that?
<tseliot> doko, I am going to have a closer look, and if I can't fix it easily, I'll file that bug report
<doko> ta
<LocutusOfBorg> doko, no idea for primer3, looks like an old endianess issue since 2 years or so
<LocutusOfBorg> doko, I have an idea now
<LocutusOfBorg> cjwatson, reproducible in pbuilder too, just we need to call dh_builddeb -a
<LocutusOfBorg> let me find if pkgbinarymangler is responsible
<doko> Trevinho: https://launchpadlibrarian.net/482050195/buildlog_ubuntu-groovy-amd64.nux_4.0.8+18.10.20180623-0ubuntu2_BUILDING.txt.gz
<doko> you introduced these fallthrough comments before. could you have a look, orjust disabled -Werror?
<LocutusOfBorg> cjwatson, confirmed pkgbinarymangler is the one to blame
<cjwatson> Right
<LocutusOfBorg> and only if dpkg-buildpackage is run with -B
<apw> i don't suppose we get to blame p-itti any more
-queuebot:#ubuntu-release- Unapproved: backport-iwlwifi-dkms (focal-proposed/universe) [8324-0ubuntu1 => 8324-0ubuntu3~20.04.1] (no packageset)
-queuebot:#ubuntu-release- New sync: pocketsphinx-python (groovy-proposed/primary) [1:0.1.15-2]
<LocutusOfBorg> can anybody please accept it? it hasn't been autosyncd because pocketsphinx was still needing a merge ^^
-queuebot:#ubuntu-release- New binary: pocketsphinx [amd64] (groovy-proposed/universe) [0.8.0+real5prealpha+1-11ubuntu1] (no packageset)
<RikMills> ubuntu-archive when convenient LP: #1880630
<ubot5> Launchpad bug 1880630 in nootka (Ubuntu) "Please remove nootka from Ubuntu" [Undecided,New] https://launchpad.net/bugs/1880630
<doko> RikMills: already done
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (focal-proposed) [1.142.1]
<RikMills> :)
<LocutusOfBorg> cjwatson, I'm really sad...
<LocutusOfBorg>         cp -p /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm /usr/share/perl5/Debian/Debhelper/Dh_Getopt.pm perl5/Ubuntu/PkgBinaryMangler/.
<LocutusOfBorg>         sed -i 's/Debian::Debhelper::/Ubuntu::PkgBinaryMangler::/g' perl5/Ubuntu/PkgBinaryMangler/*.pm
<LocutusOfBorg> this is done on pkgbinarymangle build, so we "embed" some code from debhelper, and without no-change rebuilds we still get the very same bugs over and over
-queuebot:#ubuntu-release- Unapproved: accepted busybox [source] (focal-proposed) [1:1.30.1-4ubuntu6.1]
<cjwatson> I have no objection to somebody working out how to improve the situation
<LocutusOfBorg> I'm thinking about using the Debhelper one, it is just a copy-paste, but I'm pretty sure who did that had good reasons, and ENOPERL here :)
<LocutusOfBorg> in the meanwhile I'm uploading a no-change rebuild (modulo some changes lol)
<LocutusOfBorg> oh I might know the reason for that. pkgbinarymangler uses Dh_Lib but doesn't depend on debhelper
<LocutusOfBorg> would add a new debhelper dependency generate some chicken and egg issue?
<LocutusOfBorg> (oh we might have some cdbs old stuff still out there)
<cjwatson> cdbs depends on debhelper ...
<cjwatson> It means every build would end up with debhelper installed rather than just 99% of them
<cjwatson> I would mildly prefer to avoid it since those builds are already weird in various ways
<cjwatson> And I can imagine that it would increase the set of possible failure modes that would require manual intervention to get out of
<cjwatson> Probably wouldn't be the absolute end of the world or anything but nice to avoid if possible
<LocutusOfBorg> you mean to depend on debhelper?
<cjwatson> Yes
<cjwatson> Not sure I actually quite understand why it's needed in the first place though
<cjwatson> Ubuntu::PkgBinaryMangler::Dh_Lib is only used by pkgbinarymangler's dh_builddeb wrapper
<cjwatson> And that wrapper is only called by builds that use dh_builddeb, which must all already build-depend on debhelper
<cjwatson> So I think (just by inspection) that it could just as well use Debian::Debhelper::Dh_Lib directly and drop its copies
<cjwatson> That would be better than having it depend on debhelper - it would be a simplification in more ways
<LocutusOfBorg> cjwatson, so you are suggesting my patch to directly use debhelper without depending on it?
<cjwatson> Yes.  I suspect that the copies were introduced when pkgbinarymangler was shaped slightly differently
<cjwatson> Specifically I'm suggesting (but entirely untested) https://paste.ubuntu.com/p/xS7D2P7cS4/
<LocutusOfBorg> cjwatson, it is *exactly* the one I'm testing :)
<LocutusOfBorg> modulo copyright changes :)
<cjwatson> Heh
<cjwatson> (I suspect that at one point this was used in something like a dpkg-deb wrapper that was used more broadly.  But I'm not sure, would need archaeology)
<LocutusOfBorg> just to understand, we need to update chroots now, right?
<xnox> doko:  i got a weird email from launchpad about urweb saying that it is rejected in groovy-proposed because binaries conflicting with the existing ones already exist or some such.
<xnox> doko:  if it was you doing something with urweb, do check what's up. Maybe some other source package took over the binaries already?
<xnox> doko:  or maybe it's a demotion race, and something needs to be copied again?
 * xnox is not sure what was done.
<xnox> do you want that email bounced to you?
<cjwatson> LocutusOfBorg: I don't see why
<cjwatson> LocutusOfBorg: pkgbinarymangler is installed as a package and we do a dist-upgrade at the start of the build
<doko> xnox: I demoted that to proposed
<doko> it was a fakesync, so importing the Debian version doesn't help
<LocutusOfBorg> cjwatson, I found it out after asking :)
<xnox> doko:  right, i'm not sure if demotion published in groovy-proposed or not.
<xnox> doko:  because i got an email that it failed to publish into groovy-proposed. I guess something to double check in a couple of hours.
<enyc> LocutusOfBorg: ooi do you know if  https://www.virtualbox.org/ticket/19496  got imported into the fixes of focal 20.04 virtualbox done just before release etc?
-queuebot:#ubuntu-release- New binary: subversion [amd64] (groovy-proposed/universe) [1.14.0-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: subversion [s390x] (groovy-proposed/universe) [1.14.0-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: subversion [ppc64el] (groovy-proposed/universe) [1.14.0-1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted mandelbulber2 [amd64] (groovy-proposed) [2.20-2]
-queuebot:#ubuntu-release- New: accepted mandelbulber2 [armhf] (groovy-proposed) [2.20-2]
-queuebot:#ubuntu-release- New: accepted mandelbulber2 [riscv64] (groovy-proposed) [2.20-2]
-queuebot:#ubuntu-release- New: accepted pocketsphinx-python [sync] (groovy-proposed) [1:0.1.15-2]
-queuebot:#ubuntu-release- New: accepted mandelbulber2 [arm64] (groovy-proposed) [2.20-2]
-queuebot:#ubuntu-release- New: accepted mandelbulber2 [s390x] (groovy-proposed) [2.20-2]
-queuebot:#ubuntu-release- New: accepted mandelbulber2 [ppc64el] (groovy-proposed) [2.20-2]
-queuebot:#ubuntu-release- New: accepted pocketsphinx [amd64] (groovy-proposed) [0.8.0+real5prealpha+1-11ubuntu1]
-queuebot:#ubuntu-release- New: accepted pyqt5-sip [amd64] (groovy-proposed) [12.8.0-1]
-queuebot:#ubuntu-release- New: accepted pyqt5-sip [armhf] (groovy-proposed) [12.8.0-1]
-queuebot:#ubuntu-release- New: accepted pyqt5-sip [riscv64] (groovy-proposed) [12.8.0-1]
-queuebot:#ubuntu-release- New: accepted pyqt5-sip [arm64] (groovy-proposed) [12.8.0-1]
-queuebot:#ubuntu-release- New: accepted pyqt5-sip [s390x] (groovy-proposed) [12.8.0-1]
-queuebot:#ubuntu-release- New: accepted pyqt5-sip [ppc64el] (groovy-proposed) [12.8.0-1]
-queuebot:#ubuntu-release- New: accepted nomad-driver-lxc [amd64] (groovy-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted nomad-driver-lxc [armhf] (groovy-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted nomad-driver-lxc [s390x] (groovy-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted nomad-driver-lxc [arm64] (groovy-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted nomad-driver-lxc [ppc64el] (groovy-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted cd-boot-images [source] (groovy-proposed) [1]
<LocutusOfBorg> enyc, nope
-queuebot:#ubuntu-release- New binary: cd-boot-images [amd64] (groovy-proposed/none) [1] (no packageset)
-queuebot:#ubuntu-release- New binary: cd-boot-images [ppc64el] (groovy-proposed/none) [1] (no packageset)
-queuebot:#ubuntu-release- New binary: cd-boot-images [arm64] (groovy-proposed/none) [1] (no packageset)
-queuebot:#ubuntu-release- New: accepted cd-boot-images [amd64] (groovy-proposed) [1]
-queuebot:#ubuntu-release- New: accepted cd-boot-images [ppc64el] (groovy-proposed) [1]
-queuebot:#ubuntu-release- New: accepted cd-boot-images [arm64] (groovy-proposed) [1]
-queuebot:#ubuntu-release- New binary: subversion [arm64] (groovy-proposed/universe) [1.14.0-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: subversion [armhf] (groovy-proposed/universe) [1.14.0-1] (kubuntu)
<LocutusOfBorg> enyc, will do eventually :)
-queuebot:#ubuntu-release- Unapproved: budgie-extras (focal-proposed/universe) [1.0.1-2 => 1.0.2-1] (personal-fossfreedom, ubuntu-budgie) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected nvidia-graphics-drivers-440 [source] (bionic-proposed) [440.82-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected nvidia-graphics-drivers-440 [source] (focal-proposed) [440.82.0-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New: rejected nvidia-graphics-drivers-418-server [source] (bionic-proposed) [418.126.02-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New: rejected nvidia-graphics-drivers-440-server [source] (bionic-proposed) [440.64.00-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New: rejected nvidia-graphics-drivers-418-server [source] (focal-proposed) [418.126.02-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New: rejected nvidia-graphics-drivers-440-server [source] (focal-proposed) [440.64.00-0ubuntu0.20.04.1]
<juliank> Laney: are you rebasing britney? because the card is back in backlog, but I think you are?
<juliank> https://trello.com/c/Fvi9ir6D/23-rebase-britney
<Laney> juliank: yup
<Laney> should be in progress
<Laney> or started or whatever
<Laney> about ready to try a test run actually :-o
<Laney> just got to add force-reset-test back
<juliank> Laney: nice
<Laney> well then it'll probably explode in flames, but hey ho
-queuebot:#ubuntu-release- Unapproved: accepted backport-iwlwifi-dkms [source] (focal-proposed) [8324-0ubuntu3~20.04.1]
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (focal-proposed/multiverse) [6.1.6-1 => 6.1.8-1~ubuntu1.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (focal-proposed/multiverse) [6.1.6-dfsg-2ubuntu20.04.1 => 6.1.8-dfsg-2~ubuntu1.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox-guest-additions-iso (focal-proposed/multiverse) [6.1.6-1 => 6.1.8-1~ubuntu1.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox (focal-proposed/multiverse) [6.1.6-dfsg-1 => 6.1.8-dfsg-2~ubuntu1.20.04.1] (ubuntu-cloud)
<LocutusOfBorg> sil2100, if you have spare time... ^^ thanks :D
<LocutusOfBorg> (please wait for the groovy version to migrate first)
-queuebot:#ubuntu-release- New: accepted subversion [amd64] (groovy-proposed) [1.14.0-1]
-queuebot:#ubuntu-release- New: accepted subversion [armhf] (groovy-proposed) [1.14.0-1]
-queuebot:#ubuntu-release- New: accepted subversion [s390x] (groovy-proposed) [1.14.0-1]
-queuebot:#ubuntu-release- New: accepted subversion [arm64] (groovy-proposed) [1.14.0-1]
-queuebot:#ubuntu-release- New: accepted subversion [ppc64el] (groovy-proposed) [1.14.0-1]
<LocutusOfBorg> Hello, does anybody know why merge-o-matic page is not listing e.g. qemu
<LocutusOfBorg> ?
-queuebot:#ubuntu-release- New binary: subversion [riscv64] (groovy-proposed/universe) [1.14.0-1] (kubuntu)
<xnox> sync-blacklist.txt:# stevenk, we don't want qemu from Debian, talk to kirkland
<xnox> sync-blacklist.txt:qemu
<xnox> LocutusOfBorg:  it's in sync-blacklist in https://wiki.ubuntu.com/ArchiveAdministration#Blacklisting / lp:~ubuntu-archive/+junk/sync-blacklist
<xnox> LocutusOfBorg:  do not touch =)
<LocutusOfBorg> xnox, I don't want to touch, I was just curious :)
<Laney> hmm this commit is a bit complex, it interacts with the new neutral handling in interesting ways
-queuebot:#ubuntu-release- Unapproved: neutron (xenial-proposed/main) [2:8.4.0-0ubuntu7.4 => 2:8.4.0-0ubuntu7.5] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [19.4-33-gbb4131a2-0ubuntu1~16.04.1 => 20.2-45-g5f7825e2-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: netplan.io (focal-proposed/main) [0.99-0ubuntu3~20.04.1 => 0.99-0ubuntu3~20.04.2] (core)
-queuebot:#ubuntu-release- Unapproved: rejected netplan.io [source] (focal-proposed) [0.99-0ubuntu3~20.04.2]
<blackboxsw> sil2100: if around today and available cloudinit has queued an sru for X B E and F releases per https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1881018
<ubot5> Ubuntu bug 1881018 in cloud-init (Ubuntu Focal) "sru cloud-init (19.4.33 to 20.2-45) Xenial, Bionic, Eoan and Focal" [Undecided,New]
-queuebot:#ubuntu-release- Unapproved: netplan.io (eoan-proposed/main) [0.99-0ubuntu3~19.10.1 => 0.99-0ubuntu3~19.10.2] (core)
-queuebot:#ubuntu-release- Unapproved: rejected netplan.io [source] (eoan-proposed) [0.99-0ubuntu3~19.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (bionic-proposed) [0.99-0ubuntu3~18.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (eoan-proposed) [0.99-0ubuntu3~19.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (focal-proposed) [0.99-0ubuntu3~20.04.2]
-queuebot:#ubuntu-release- Unapproved: gnome-shell (focal-proposed/main) [3.36.2-1ubuntu1~20.04.1 => 3.36.3-1ubuntu1~20.04.1] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: golang-1.14 (focal-proposed/main) [1.14.2-1ubuntu1 => 1.14.3-2ubuntu2~20.04.1] (no packageset)
#ubuntu-release 2020-06-05
<cpaelzer> Laney: (or anyone else who can) about cancelling tests - please cancel this regexp '\\n{"triggers": \["perl/5.30.3-1"\]'
<cpaelzer> there is a 5.30.3-2 in groovy-proposed now so all old tests will be retried and running the other ~7k that are left is a waste of time I'd think
<enyc> LocutusOfBorg: "enyc, will do eventually :)" -> Thankyou =) I can personally confirm the difference with 6.1.6 to 6.1.8 debian version for example...
<LocutusOfBorg> enyc, https://bugs.launchpad.net/ubuntu/focal/+source/virtualbox-hwe/+bug/1882106
<ubot5> Ubuntu bug 1882106 in virtualbox-hwe (Ubuntu Focal) "[SRU] virtualbox*" [Undecided,In progress]
<LocutusOfBorg> I also added a new patch on top of 6.1.8
<LocutusOfBorg> I'll ask you to test, once somebody accepts the upload from the queue :)
<enyc> LocutusOfBorg: hrrm don't have directly installed 20.04's myself, they are other way round inside vm AT the moment!  but that may change =)
<enyc> LocutusOfBorg: i note, too, 5.2.34 and ubuntu 18.04 ... might warrant update to cope with  HWE kernel in time,   maybe maybe-not ...
<LocutusOfBorg> enyc, I'll do it too
<enyc> LocutusOfBorg: more to the point, for supporting virtualizing newer linux ontop of bionic.  Note 5.2 supported upstream until next month.
<enyc> LocutusOfBorg: any newer 5.2-18.04 i'd be in good positon to test tbh
<LocutusOfBorg> bionic won't have any new kernel anymore, so 5.2.48 or whatever will be the last one, specially because 6.0 is a no-go (amd64 only, I don't want to drop i386 support on bionic)
<enyc> LocutusOfBorg: yes, but it can provide guest-additions to  a newer-kernel  guest-os
<LocutusOfBorg> I'm talking about host, not guest
<enyc> LocutusOfBorg: I know you are =)   uerr sorry not so waake here!
<LocutusOfBorg> :)
 * LocutusOfBorg grabs some coffee too
<xnox> vorlon:  https://paste.ubuntu.com/p/8yXvy48SRy/ => i do not see DEB_HOST_ARCH=i386
<xnox> that's from procenv autopkgtest
<xnox> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/i386/p/procenv/20191130_052433_2c6be@/log.gz
-queuebot:#ubuntu-release- New binary: nvidia-cuda-toolkit [ppc64el] (groovy-proposed/multiverse) [10.1.243-5ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-cuda-toolkit [amd64] (groovy-proposed/multiverse) [10.1.243-5ubuntu2] (no packageset)
<LocutusOfBorg> please reject nvidia-cuda-toolkit new binaries on ppc64el and amd64 ^^
<LocutusOfBorg> new upload will come
<LocutusOfBorg> (from Graham, we need different binaries in Ubuntu)
<LocutusOfBorg> can any archive-admin please NBS-proposed cleanup "erlang-guestfs" (from src:libguestfs) thanks
-queuebot:#ubuntu-release- New binary: wiki2beamer [amd64] (groovy-proposed/none) [0.9.5-2] (no packageset)
<oSoMoN> can someone on the release team please ack https://code.launchpad.net/~osomon/britney/hints-ubuntu-i386-badtests/+merge/385113 ?
<blackboxsw> tjaalton:  if around today and available cloudinit has an unapproved upload queued an sru for X B E and F releases per https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1881018
<ubot5> Ubuntu bug 1881018 in cloud-init (Ubuntu Focal) "sru cloud-init (19.4.33 to 20.2-45) Xenial, Bionic, Eoan and Focal" [Undecided,New]
<tjaalton> blackboxsw: ok
-queuebot:#ubuntu-release- Unapproved: mozjs68 (focal-proposed/main) [68.6.0-1ubuntu1 => 68.9.0-1~ubuntu20.04.1] (i386-whitelist) (sync)
<Trevinho> apw: hey, had any time to look at https://code.launchpad.net/~3v1n0/ubuntu-archive-tools/sru-review-bileto-support/+merge/364193 ?
<Trevinho> I did the change you requested me long time ago
<tjaalton> blackboxsw: each one has two uploads, which one to pick?
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (focal-proposed) [2.20.11-0ubuntu27.3]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (focal-proposed) [1:20.04.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (eoan-proposed) [1:19.04.8.1]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (bionic-proposed) [1:18.04.11.13]
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (bionic-proposed) [20.2-45-g5f7825e2-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (eoan-proposed) [20.2-45-g5f7825e2-0ubuntu1~19.10.1]
-queuebot:#ubuntu-release- New binary: linux-signed-oracle-5.3 [amd64] (bionic-proposed/main) [5.3.0-1019.21~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle-5.3 [amd64] (bionic-proposed) [5.3.0-1019.21~18.04.1]
<Eickmeyer> So, with 20.04.1 coming up in just under 2 months, I want to figure out why our focal dailies are failing. Something about it installing two kernels and livecd-rootfs freaking out?
<Eickmeyer> (Studio)
<blackboxsw> tjaalton: ahh missed that,  checking diffs, I may have accidentally uploaded the same bits twice
<blackboxsw> tjaalton: bionic is 0.2-45-g5f7825e2-0ubuntu1~18.04.1
<blackboxsw> make that 20.2-45-g5f7825e2-0ubuntu1~18.04.1
<blackboxsw> please  avoid any 20.2=-38
<blackboxsw> xenial: 20.2-45-g5f7825e2-0ubuntu1~16.04.1
<blackboxsw> eoan: 20.2-45-g5f7825e2-0ubuntu1~19.10.1
<blackboxsw> tjaalton: and focal was the one I mistakenly uploaded the same content twice https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=cloud-init
<blackboxsw> either one works, that patch diff is the same
<blackboxsw>  	20.2-45-g5f7825e2-0ubuntu1~20.04.1
<blackboxsw> so rejecting any 20.2-38 cloud-init is desired
<Laney> cpaelzer: done (late, I was on PTO today)
-queuebot:#ubuntu-release- Unapproved: mutter (focal-proposed/main) [3.36.2-1ubuntu1~20.04.1 => 3.36.3-0ubuntu0.20.04.1] (desktop-core, desktop-extra)
<tjaalton> blackboxsw: I've rejected the dupes
<tjaalton> and old ones
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (bionic-proposed) [20.2-38-g8377897b-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (focal-proposed) [20.2-45-g5f7825e2-0ubuntu1~20.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (eoan-proposed) [20.2-38-g8377897b-0ubuntu1~19.10.1]
<xnox> ubuntu-archive please process unsual manual uploads removals https://bugs.launchpad.net/bugs/+bugs?field.tag=rm-signed
<xnox> should NBS report be extended to report on signed things?
<blackboxsw> thanks tjaalton
-queuebot:#ubuntu-release- Unapproved: gnome-shell (focal-proposed/main) [3.36.2-1ubuntu1~20.04.1 => 3.36.3-1ubuntu1~20.04.2] (desktop-extra, mozilla, ubuntu-desktop)
<apw> xnox: that is not an archive-admin thing that needs deeper access. vorlon ^
<xnox> apw:  some AAs have that =)
<xnox> but i don't know which
<cpaelzer> thanks Laney
<vorlon> apw: on vacation this week
<vorlon> xnox: how are you checking the environment?  The DEB_HOST_ARCH is definitely set on i386 autopkgtests
<blackboxsw> tjaalton: I wan't sure if there was a followup plan for approving 20.2-45 for cloud-init on xenial, bionic, eoan and focal  after rejecting the previous uploads?
<blackboxsw> I'd expect an EOW there as it's 12 or 1am local time
<blackboxsw> vorlon: not sure if you'll have time today to peek at the cloud-init unapproved queue for SRU X, B, E and F. we're looking to get official verification going on the cloud-init binaries version 20.2-45 for bug https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1881018
<ubot5> Ubuntu bug 1881018 in cloud-init (Ubuntu Focal) "sru cloud-init (19.4.33 to 20.2-45) Xenial, Bionic, Eoan and Focal" [Undecided,New]
<vorlon> blackboxsw: nope, on PTO today
<blackboxsw> ahh good man.
<blackboxsw> will hit folks up Monday. have a good one :)
 * blackboxsw misread the prior message to a-p-w
<Eickmeyer> So, with 20.04.1 coming up in just under 2 months, I want to figure out why our focal dailies are failing. Something about it installing two kernels and livecd-rootfs freaking out?
-queuebot:#ubuntu-release- New binary: wiki2beamer [amd64] (groovy-proposed/universe) [0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-horde [amd64] (groovy-proposed/universe) [5.2.21+debian1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hera [amd64] (groovy-proposed/universe) [0~git20200602+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hera [arm64] (groovy-proposed/universe) [0~git20200602+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hera [armhf] (groovy-proposed/universe) [0~git20200602+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hera [riscv64] (groovy-proposed/universe) [0~git20200602+dfsg-1] (no packageset)
#ubuntu-release 2020-06-06
-queuebot:#ubuntu-release- New binary: ruby-cmath [amd64] (groovy-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-libnotify [amd64] (groovy-proposed/universe) [0.9.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-jekyll-polyglot [amd64] (groovy-proposed/universe) [1.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-rack-livereload [amd64] (groovy-proposed/universe) [0.3.17+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-cool.io [amd64] (groovy-proposed/universe) [1.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-cool.io [armhf] (groovy-proposed/universe) [1.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-cool.io [arm64] (groovy-proposed/universe) [1.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-cool.io [riscv64] (groovy-proposed/universe) [1.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hera [ppc64el] (groovy-proposed/universe) [0~git20200602+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hera [s390x] (groovy-proposed/universe) [0~git20200602+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-cool.io [ppc64el] (groovy-proposed/universe) [1.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-cool.io [s390x] (groovy-proposed/universe) [1.6.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (focal-proposed/multiverse) [6.1.6-1 => 6.1.10-1~ubuntu1.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (focal-proposed/multiverse) [6.1.6-dfsg-2ubuntu20.04.1 => 6.1.10-dfsg-1~ubuntu1.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox-guest-additions-iso (focal-proposed/multiverse) [6.1.6-1 => 6.1.10-1~ubuntu1.20.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox (focal-proposed/multiverse) [6.1.6-dfsg-1 => 6.1.10-dfsg-1ubuntu1.20.04.1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (bionic-proposed/multiverse) [5.2.34-1~ubuntu18.04.1 => 5.2.42-1~ubuntu1.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox (bionic-proposed/multiverse) [5.2.34-dfsg-0~ubuntu18.04.1 => 5.2.42-dfsg-0~ubuntu1.18.04.1] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: virtualbox-guest-additions-iso (bionic-proposed/multiverse) [5.2.34-1~ubuntu18.04.1 => 5.2.42-1~ubuntu1.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (bionic-proposed/multiverse) [5.2.34-dfsg-0~ubuntu18.04.1 => 5.2.42-dfsg-0~ubuntu1.18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: hera [arm64] (groovy-proposed/universe) [0~git20200602+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hera [armhf] (groovy-proposed/universe) [0~git20200602+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: hera [riscv64] (groovy-proposed/universe) [0~git20200602+dfsg-2] (no packageset)
#ubuntu-release 2020-06-07
-queuebot:#ubuntu-release- New binary: chiark-tcl-applet [amd64] (groovy-proposed/universe) [1.0-2] (no packageset)
