#ubuntu-release 2010-03-22
<micahg> anyone around to approve FFe merges?
<lamont> cjwatson/slangasek: I assume that daily builds are back to normal now that the beta is out?  could you trigger a new edubuntu-dvd build for i386 pls?
<lamont> afk for a bit
<cjwatson> yes.  running
<cjwatson> lamont: ^-
<lamont> ta
<cjwatson> actually that probably did it for amd64 too, but ...
<lamont> cjwatson: that should have the ltsp squashfs appear in the file list for i386 when it finishes
<lamont> and there will be a 1.108 of livecd-rootfs
<cjwatson> ok
<lamont> seems y'all don't build "edubuntu" anymore, just the -dvd :(
<cjwatson> indeed
<lamont> and afk
<lamont> cjwatson: next question:  what is needed to get lucid/edubuntu-dvd/current/livecd.edubuntu-dvd-ltsp.squashfs onto the DVD iso?
<cjwatson> lamont: is there a bug for this?  at the moment, I'm buried in grub
<lamont> https://bugs.edge.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/531546 is the closest I've got... it's either incorrectly closed and should be reopened and assigned somewhere, or a new bug created for the other... how you want me to do it?
<ubottu> Ubuntu bug 531546 in livecd-rootfs "Have a LTSP chroot built and placed on the Edubuntu DVD" [Undecided,Fix released]
<lamont> the bug clearly thought it was the complete thing
<cjwatson> lamont: add a task on the ubuntu-cdimage project please
<lamont> done
<stgraber> slangasek: highvoltage just filed bug 544372 so we have that written somewhere, please ping us if we need to document anything else
<ubottu> Launchpad bug 544372 in edubuntu-artwork "Edubuntu Artwork Freeze Exception" [Medium,Confirmed] https://launchpad.net/bugs/544372
<slangasek> stgraber: the only thing is to make sure anyone doing screenshots of Edubuntu for documentation knows it's coming; so either a mail to ubuntu-doc, or talking directly to the people who are doing Edubuntu doc if you know who that is specifically
<micahg> can I get someone to approve FFe bug 513163 please?
<ubottu> Launchpad bug 513163 in google-gadgets "[FFe] merge google-gadgets 0.11.2-1 from debian expermiental" [Wishlist,Confirmed] https://launchpad.net/bugs/513163
<micahg> nhandler: ^^
<nhandler> Let me look micahg
<micahg> nhandler: thanks
<nhandler> micahg: Why is it in experimental ?
<micahg> they broke their api I think
<nhandler> micahg: Does that break anything else ?
<micahg> nhandler: I'm checking now, I forgot about that...is there a way to check source rdepends easily?
<micahg> I don't think anything else depends on it...
<nhandler> micahg: apt-cache rdepends
<micahg> nhandler: does not look like anything else depends on it
<micahg> nhandler: do you need any more information?
<nhandler> micahg: Not right now. I'll look at it in a minute or so
<micahg> nhandler: ok, thanks
<stgraber> slangasek: Most of the work review and stuff like that is being done by nixternal and he's part of the Edubuntu council so it should be fine. We also still have an Edubuntu doc day to schedule and are currently waiting on the new artwork before we set a date for it.
<slangasek> stgraber: ok
#ubuntu-release 2010-03-23
<kirkland> slangasek: around?  I need to get seabios and vgabios re-promoted to main
<kirkland> slangasek: i did the MIRs earlier this cycle got them approved
<kirkland> slangasek: but they fell out of main for a bit when qemu-kvm stopped depending on them
<kirkland> slangasek: bug qemu-kvm now depends on them again...
<kirkland> https://bugs.edge.launchpad.net/ubuntu/+source/vgabios/+bug/181876
<ubottu> Ubuntu bug 181876 in vgabios "[MIR] vgabios" [High,Fix released]
<kirkland> https://bugs.edge.launchpad.net/ubuntu/+source/seabios/+bug/508870
<ubottu> Ubuntu bug 508870 in seabios "[MIR] seabios" [High,Fix released]
<slangasek> kirkland: the packages still don't show up in http://people.canonical.com/~ubuntu-archive/component-mismatches.txt - what version of qemu-kvm depends on them?
<slangasek> (I'm not going to promote them until they have a revdep in main, that just runs the risk of another archive admin kicking them right back out again)
<lamont> slangasek: livecd-rootfs_1.108 - how much documentation do you need for that - it's the upload to match the change that I made live to terranova earlier today...
<lamont> (please to be blessing, once the source shows up - uploaded about 3 min ago)
<lamont> or less
<lamont> or do you want a bug filed for it for posterity?
<lamont> anyway, bed for me.  I'll read scrollback in the morning
<slangasek> lamont: er, you know we're not in archive freeze, right?  If you uploaded it, it goes straight in
<slangasek> cjwatson, mvo: did you guys ever figure out a way to make libparted0/libparted1.8-12 happy?  (Still held back here for me)
<mvo> slangasek: I did not inverstigate further, did I ask you for your /var/lib/dpkg/status file already?
<mvo> slangasek: I will add a hint to u-m as a stop-gap, until a proper fix is there
<slangasek> mvo: I wasn't the one reporting it originally, I think it was pitti
<mvo> slangasek: ok, could you mail me the status file please? just so that I can easily reproduce it?
<slangasek> mvo: sent
<cjwatson> slangasek: I didn't - is there any way you can test adding libparted0 Conflicts:/Replaces: libparted1.8-12, libparted-2.1-0?
<slangasek> can do that in the morning
<mvo> thanks slangasek
<slangasek> cjwatson: fwiw, my first instinct there would've been to name the package 'libparted0deb' :)
<cjwatson> mm, I really hate that sort of thing though ...
<cjwatson> (and it'll be hard to do that now, I've already started the 2.2 transition in unstable)
 * slangasek nods
<lamont> slangasek: oh. doh.
<Riddell> BSD with advertising clause means multiverse?
<Riddell> hmm, not in non-free in Debian
<cjwatson> BSD with advertising clause is free, just GPL-incompatible
<ScottK> and really annoying.
<kirkland> slangasek: cjwatson got them for me
#ubuntu-release 2010-03-24
<_Andrew> Is there anyone I can talk to about packaging up something for Lucid? I want to see this package upgraded to 1.7.0 stable ( https://launchpad.net/ubuntu/lucid/+source/ogre/1.6.4.dfsg1-1 ) however it looks like it's just imported from debian with no ubuntu maintainer?
<cjwatson> lamont: so what happened to the code to generate ltsp squashfses on edubuntu dvd builds?
<cjwatson> http://terranova.buildd/~buildd/LiveCD/lucid/edubuntu-dvd/current/livecd.edubuntu-dvd-ltsp.squashfs:
<cjwatson> 02:25:51 ERROR 404: Not Found.
<lamont> cjwatson: good question
<lamont> Warning: --skipimage set, not building squashfs image, run ltsp-update-image later
<lamont> ...
<lamont> LTSP: Unable to build the chroot, see above for details.
<lamont> so...  it executed the code to build it, that code just failed./
<lamont> not sure whether that wants to prevent the dvd build so we notice, or what.
<cjwatson> lamont: well, right now, it will fail the DVD build stage anyway even though it doesn't fail the livefs build stage
<cjwatson> so I'd be happy for it to fail the livefs build stage too
<lamont> oh, that's easy to do
<lamont> cjwatson: fixed /current, and the file - please trigger an edubuntu-dvd build?
<cjwatson> running
<lamont> hopefully, it still fails, so we get that test case
<lamont> fwiw, 0323 succeeded and is now "current"
<stgraber> lamont: that "Skipping invalid chroot: /build/buildd means that /build/buildd/bin/true didn't exist at this point which should never happen as it's provided by coreutils
<lamont> stgraber: ew
<stgraber> hmm, actually it's just the detection code that's thinking it might be a chroot (as it's looking at everything in /build/), shouldn't be an issue then ...
<stgraber> as /build/ltsp-live is scanned properly
<stgraber> argh, looks like it might be LTSP 5.2.1 packaging that's slightly broken
<stgraber> already fixed + uploaded for a bug but seems like I've another one there
<stgraber> I'll be fixing that in the next hour
<stgraber> lamont: easiest will be to drop the call to ltsp-update-image and replace by a direct call to mksquashfs, I'll give you a small patch to do that change. Seems like ltsp-update-image is trying to configure inetd + copy files in the tftp dir + ... which we really don't want to do on the builder
<lamont> stgraber: exactly - we want a make-client-image that doesn't actually need all that crap
<lamont> er, stuff
<lamont> stgraber: making the image should be completely separate from placing  the image for use by the client
<stgraber> lamont: well, getting rid of ltsp-build-client will be an issue as it needs a lot of scripts that are used to build the image but for Lucid+1 we can probably split ltsp-server into two packages to make that easier
<stgraber> lamont: for now, the only thing we'll replace is the call to ltsp-update-image (which builds the squashfs out of what ltsp-build-client made)
<lamont> right
<lamont> stgraber: anyway, pushed 1.109 in the bzr tree - I'll upload thatonce the run finishes, but go ahead and base on that for your changes
<stgraber> lamont: did you update the bzr branch or is it no longer used ? (~ubuntu-core-dev/livecd-rootfs/trunk)
<lamont> stgraber: just pushed rev 82
<lamont> "pushed 1.109" ==> rev82 to the branch
<lamont> bzr+ssh://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/livecd-rootfs/lucid/
<lamont> to be specific
<stgraber> lamont: http://pastebin.com/cqRHYjAi
<lamont> tested, I presume?
<lamont> cjwatson: wanna smack another round of edubuntu-dvd into running?
<cjwatson> previous one's still going on antimony
<stgraber> lamont: well, "tested" as in I took that mksquashfs out of an actual run of ltsp-update-image. I didn't test in an actual build chroot as I don't have access to one ;)
<stgraber> would be great if we could wait to have -0ubuntu3 before triggering a new build (ltsp that's)
<stgraber> it's uploaded so should reach the archive very soon
<lamont> heh. ok
<lamont> stgraber: bzr branch lp:~lamont/launchpad-buildd/chroot-scripts; chroot-scripts/make-chroot.sh -dlucid --buildd --live
<lamont> well, you might want a --user in there... see --help
<lamont> the original form will try to create ~buildd/build-lucid-live/chroot-lucid
<cjwatson> lamont: it's upgraded now
<cjwatson> err, echan
<stgraber> cjwatson, lamont: ltsp 5.2.1-0ubuntu3 is now in the archive. It'd be great if we could get another set of Edubuntu DVD images built, that's if the builders aren't super-busy with something else of course.
<ScottK> slangasek: There's a new clamav RC out.  It has a minor new feature (urgh).  I'm planning on assuming the the existing clamav FFe that was approved before I uploaded the first RC is adequate for getting to clamav 0.96 final.  Please tell me if that's not the case and you want more paperwork.
<slangasek> ScottK: no papers needed, please go ahead
<ScottK> slangasek: Thanks.
<ev> would someone be so kind as to look bug 538156 (FFe) over?  It's a small change.
<ubottu> Launchpad bug 538156 in ubiquity "Freeze exception request: remove the seconds from the time zone map time" [Undecided,New] https://launchpad.net/bugs/538156
<slangasek> ev: done
<ev> slangasek: thanks a bunch!
#ubuntu-release 2010-03-25
<slangasek> cjwatson: libparted0 added conflicts/replaces don't seem to make a difference
<stgraber> lamont: Just looked at http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/edubuntu-dvd/20100325/livecd-20100325-i386.out and I see no mention of the LTSP chroot (or error message related to it), any idea of what happened ?
<lamont> stgraber: that's 1.108 - you want 1.109 before we stopped doing update-image
<lamont> stgraber: and 1.110 is now current, next run should get what you want
<stgraber> lamont: great, thanks
<Daviey> A multiverse build failed, and i belive it was a hiccup with the buildd rather than an issue with package.  If i wanted a no change rebuild done, is it an AA or LP folk that i need to ask?
<Daviey> (probelm solved, thanks anyway)
<Daviey> okay, not *quite* solved.  Something seems odd, *mysql*3ubuntu8 was built 10 hours ago.  Nothing seemed to fail afaics, but only *mysql*3ubuntu8_amd64 seems to have been published.  *mysql*3ubuntu7* is still in the archive pool.
<slangasek> Daviey: package name?
<Daviey> slangasek: Specifically libmysqlclient16 is what raised the issue with me
<Daviey> But this seems related https://bugs.edge.launchpad.net/ubuntu/+source/mysql-dfsg-5.1/+bug/546691
<ubottu> Ubuntu bug 546691 in mysql-dfsg-5.1 "MySQL package dependancies are broken for Lucid" [Undecided,New]
<slangasek> according to the archive, all architectures have published *except* i386 and sparc; that probably means i386 is in binary NEW. Checking.
<slangasek> yep - processing
<Daviey> hmm, doesn't really explain why amd64 is playing up tho.
<Daviey> slangasek: the build that raised it with me was: https://edge.launchpad.net/ubuntu/+source/mythplugins/0.23.0+fixes23784-0ubuntu1/+build/1580419
<Daviey> further investigation, pbuilding on amd64 gave: http://paste.ubuntu.com/401035/
<slangasek> unfortunately, the new package that's causing mysql to be held up in the queue is broken and built for the wrong architecture (arch: all when it should be arch: any); let me fix this properly before letting it through
<Daviey> slangasek: great, thanks
<slangasek> Daviey: turns out that's more complicated than I thought, so I've filed a bug about it and let the package through; so libmysqlclient16 should be installable again with the next publishing run
<Daviey> slangasek: great thanks
#ubuntu-release 2010-03-26
<slangasek> ev: what are the known reasons that ubiquity might fail to offer to install side-by-side on a system with Windows 7, using Windows 7 loader, that has 45GB free?
<slangasek> stgraber, lamont: edubuntu builds still failing with the same error, what's outstanding here?
<ev> slangasek: what does ntfsresize --info say?
<mvo> slangasek, pitti: any news for the feature freeze exception for computer-janitors dbus branch? bug #541990
<ubottu> Launchpad bug 541990 in computer-janitor "[FFe] Upgrade Computer Janitor to 2.0 (dbus edition)" [Undecided,New] https://launchpad.net/bugs/541990
<pitti> mvo: hm, this seems to be a "damned if you do, damned if you don't" kind of thing
<pitti> c-j was pretty brittle in the past and caused lots of grief; I'm really nervous with having a complete rewrite at this point..
<ScottK> That could also be an argument for the rewrite.
<barry> pitti: i do think it's much more stable, and i already have another use case for the dbus backend :)
<pitti> ScottK: except that we know that the current version at least by and large works and doesn't wreak havoc
<mvo> pitti: yeah, its tricky, however I think the benefits are worth the risk, the current threading issues are really hard to fix and dbus makes it all go away nicely
<barry> pitti: btw, most of the core logic is essentially unchanged.  all the plugings, cruft model, cleanup actions have just been moved into a dbus service.  not saying there aren't bugs of course, but that stuff hasn't been really rewritten (cleaned up, refactored, tested, yes :)
<barry> but i understand the concern, being here at b1
<slangasek> ev: dunno - will have to check next time I'm in getting a haircut
<slangasek> :-)
 * ev raises an eyebrow
<ev> clearly I missed some context :)
<slangasek> my barber was interested in trying it, so I gave him a CD, and it won't auto-resize his Windows 7 :(
<cjwatson> if I can ever get this damn machine to my right working, I'll test it
<cjwatson> I have too many bugs to be able to spend time on hardware maint
<slangasek> it doesn't fail /generally/, only on his machine
<Keybuk> besides, my pilots licence quite clearly states STAY CLEAR OF CLOUD
<lamont> slangasek: sigh.  let me go figure it out.  do you need terranova anytime soonish? (next hour or 2)
<slangasek> lamont: not urgently
<slangasek> Keybuk: <snort>
<lamont> Keybuk: clearly you need to go for instrument rating
<slangasek> for the privilege of flying blind in the cloud?
<Keybuk> slangasek: yeah, you need an IR to be legally allowed to enter cloud (or in the UK, even fly above it)
<slangasek> yes, I know
<slangasek> I was just stretching out the word game :)
<ev> slangasek, kees: do either of you know for certain if derivative distributions (specifically, Xubuntu) can use the LTS designation?
<ev> That is, do we cover everything they ship with security updates for 5 years?
<jdstrand> afaik, they have not in the past
<jdstrand> eg, kubuntu in hardy was not LTS
<charlie-tca> 3 for desktops, I think. 5 for servers
<ScottK> Canonical already doesn't do security updates for Xubuntu
<ev> but to be clear, Kubuntu definitely is this time, right?
<ScottK> ev: yes.
<ev> okay
<jdstrand> I thought Xubuntu was all in universe these days?
<jdstrand> maybe I am misremembering...
<ScottK> jdstrand: That's why I said Canonical didn't do security updates for it.
<ev> ah indeed, xfce4-panel at least is
<ev> okay
<ScottK> ev: To be even more specific, Kubuntu (desktop) is LTS, Kubuntu Netbook Remix is not.
<ev> so it's not an LTS then
 * jdstrand thanks ScottK for helping him remember, before he thought to wonder if he forgot
<ev> ScottK: ah, thanks for that clarification, I hadn't thought to consider the netbook editions
<slangasek> ev: modulo UNE not actually being an LTS: https://wiki.ubuntu.com/LucidLynx/ReleaseManifest
<ev> slangasek: ah, I forgot about that page
<ev> thanks a bunch!
<jdstrand> as did I
<pitti> slangasek: I replied to bug 546933, and I'm mildly in favor, but would like to get more opinions on that one
<ubottu> Launchpad bug 546933 in xorg-server "FFE: xorg.conf.d/inputclass backport" [Wishlist,New] https://launchpad.net/bugs/546933
<ScottK> slangasek: One thing to consider for LTS/non-LTS is new ISOs for point releases.  I think it'd be very confusing for Kubuntu/KNR or Ubuntu/UNE to have different package versions in their current ISO.  I think it would make sense to respin those at least for .1.
<slangasek> ScottK: confusing perhaps, but we already don't have a policy of respinning all ISOs for the point releases; 8.04.1 DVD, for instance, was only respun because of the ssh security issue
<slangasek> pitti: will look at it this morning
<ScottK> True.
<ScottK> You just end up in the odd position of after 3 months the easiest way (if you have poor bandwidth) to install KNR would be to download Kubuntu 10.04.1 and then switch it.
<slangasek> hum
<slangasek> it would be nice if the SRU delta were not so great as to make that true
 * kees still wishes ReleaseManifest had seeds listed
<slangasek> it's something to think about, anyway; though the practical limiting factor is usually our ability to validate the ISOs for point releases
<slangasek> kees: weren't we waiting for you to tell us what the seeds were?
<kees> slangasek: me? no, that's up to what defines the release
<slangasek> ok, then I guess I need to check with mvo/barry on this
<kees> slangasek: i.e. "Ubuntu Server" is server-ship. so when Jos says "this is 5 year", mvo's tool marks that seed
<kees> but right now, we have to guess at the seed based on the product/image in the ReleaseManifest
<slangasek> who does?
<slangasek> is it security team guessing, or mvo, or?
<kees> I'm saying "one" guesses.  for lucid, we (security and mvo) understand 5 year support to be server-support + server-ship.
<slangasek> then that's what I'm going to write there
<kees> heh
<kees> I find ReleaseManifest confusing because the "Maint commit" column does not map to anything direct.  (i.e. no mention of main vs universe, seeds, etc)
<slangasek> kees: my understanding was that you and mvo were in the process of *defining* that mapping, since it was done slipshod previously
<slangasek> ev: btw, "is it an LTS" is a subtly different question from "is it supported for 3 years", because LTS is a product definition which might or might not be applied to Xubuntu even if the community decided to provide 3y of security support
<ev> slangasek: that strikes me as being very confusing to end users
<ev> if that's the case, what does LTS convey
<slangasek> it conveys that Canonical is standing behind its status as a long-term-supported product
<slangasek> which would not *automatically* the case for Xubuntu with a community security committment
<kees> slangasek: mostly it was the mechanisms, and adjusting seeds to match expectations.  it's always been defined as "server-supported" and "server-ship".  we just tweak those contents and add things to a blacklist in rarer cases
<kees> slangasek: so really it's now "supported-server" + "server-ship" - explicit blacklist
<slangasek> kees: ok, where is the list of mappings that mvo's tool uses?
<kees> slangasek: afaiu, it's done somewhere in launchpad via cron.germinate and maintenance-check.py
<kees> slangasek: the blacklist is lp:~ubuntu-core-dev/ubuntu-seeds/platform.lucid/ SUPPORTED_HINTS
<kees> slangasek: right now, it is pending a change to add server-ship which was missed in the first version.
<kees> slangasek: at which point the commented out bits in SUPPORTED_HINTS will be added, and then I'll re-check the lists to see what's creeped in since the sprint.
<stgraber> slangasek, lamont: Any clue on what's happening with Edubuntu ?
<slangasek> I'm waiting for lamont's analysis
<stgraber> Could not create destination file: No such file or directory
<stgraber> that's new ...
<stgraber> might be something broken in my mksquashfs cmdline though it's based on what ltsp-build-client calls ...
 * stgraber make a note to add some debug next time he proposes a patch for that script ... would be useful to know what commands are started
<stgraber> doh, I guess I found the problem ...
<stgraber> seems like mksquashfs doesn't like creating an image in a non-existing directory
<stgraber> http://pastebin.com/anpmac7s
<stgraber> lamont: ^
<lamont> stgraber: heh
<lamont> stgraber: testing
<lamont> afk for a few while the build runs
<ScottK> slangasek: Hello.
<slangasek> ScottK: heya
<slangasek> so I have http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi, which AIUI I can rely on to start with as the list of failing packages
<ScottK> Right.
<slangasek> for this spec, I should filter those down to packages that have the same binary versions in karmic and lucid, right?
<ScottK> That's a different way to look at it than I did initially.
 * ScottK ponders.
<slangasek> what was your way?  that's what I'm having a hard time remembering
<ScottK> My way was to take a list of the rebuild failures just after the toolchain upload (which I've mailed you) and then remove the ones that built after that.
<ScottK> So it'd be that initial list less the ones with a different binary version that aren't also still failing to build.
<slangasek> ok - I'm actually not sure I ever received that email from you
<ScottK> X - (Y-z)
 * ScottK looks for it.
<ScottK> Sent in January 31, 2010 at 00:35 my time.
<slangasek> misplaced on my end then, sorry
<ScottK> No problem.  Resent.
<ScottK> The X - (Y -Z) bit was only the first part of the question.
<ScottK> That gives us a good list for i386 and amd64.
<ScottK> The next question was ports.
<slangasek> sorry - I knew you had intended to send that mail, but when I failed to find it in my inbox folks directed me to lucas's later rebuild mails instead, which is where I started floundering because AFAIK those weren't being done with the snapshot from the original plan
<ScottK> Right.  No problem.
<slangasek> right, the ports part I remember - remove the ports binaries IFF i386 or amd64 FTBFS and is up-to-date in the archive
<ScottK> For ports, we wanted to assume anything that failed amd64 or i386 would fail on ports and remove those too, except for port specific packages (e.g. silo).
<ScottK> Yes.
<slangasek> (in fact, that's documented clearly in the spec :)
<ScottK> Ah, good.
<ScottK> Is it clear now then?
<slangasek> yes, thanks
<slangasek> though I still don't have that email from you
<slangasek> getting wedged/filtered somewhere, I fear
<ScottK> Let me post the files somewhere then.
<slangasek> ok
<ScottK> slangasek: http://kitterman.com/kubuntu/
<slangasek> great, thanks!
<ScottK> nbs.i386only is empty on purpose
<slangasek> ScottK: right, I should follow through on this while I have the state in my brain - if you're around later, I'd like to tackle the python syncs question as well
<ScottK> OK.  I'll be around off and on from here on out today.
<lamont> gotta love the speed of that edubuntu-dvd build
<stgraber> heh, it's just a huge squashfs and a smaller one ;)
<stgraber> so livefs takes a lot of time (especially on i386 as it build ltsp as well) but the DVD build process should then be quite fast ;)
<lamont> heh
<lamont> yeah - it
<lamont> s currently squashing the dvd image
<lamont> and then we get to see if the other fixed it.
<lamont> stgraber: fail
<lamont> + mksquashfs /build/buildd/ltsp-live /build/buildd/images/ltsp-live.img -noF -noD -noI -no-exports -e cdrom
<lamont> Could not create destination file: No such file or directory
<lamont> gar
<stgraber> lamont: and I assume /build/buildd/images exists ?
<stgraber> that's what that mkdir was supposed to do
<lamont> stgraber: nope.
<lamont> and you created the source directory... :-p
<lamont> fixed and running again already
<stgraber> argh, seems like my mind wanted to create the destination but my fingers went with the source instead ...
<lamont> yeah.  and I had faith in your fingers.
<stgraber> sorry for having you have to trigger another rebuild :(
<lamont> I read the manpage right after pasting the error above, and went "doh"
<lamont> OTOH, if this works, they can burn ISOs, since it's a genuine run
<lamont> slangasek: still have the lock, but only because BuildLiveCD is acutally running - it's back to normal otherwise.  kthx
<slangasek> lamont: cheers
<lamont> slangasek: and totally cowboyed - I'll upload after I confirm it works
#ubuntu-release 2010-03-27
<lamont> -rwx------ 1 buildd root    550354944 Mar 26 21:59 livecd.edubuntu-dvd-ltsp-20100326.1-i386.squashfs
<lamont> woot!
<lamont> and 1.111 uploaded
<stgraber> lamont: yeah ! thanks
<lamont> stgraber: well, it was sorta ex-post-facto, but yeah
<lamont> current (20100326.1) has the bits, 0327 is building now
<stgraber> lamont: did you get that build log ? (20100327)
<stgraber> http://terranova.buildd/~buildd/LiveCD/lucid/edubuntu-dvd/current/livecd.edubuntu-dvd-ltsp.squashfs:
<stgraber> 02:11:17 ERROR 403: Forbidden.
<lamont> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
<lamont> stgraber: somehow, I had the impression this was tested
<stgraber> well, that's very weird as I believe that part succeeded in the past didn't it ?
<lamont> the image is created mode 600 by mksquashfs - dunno if that's a recent change, but I doubt it
<stgraber> hmm, that might explain some things ... in a real LTSP environment the process accessing the image is running as root so it wouldn't be an issue.
 * stgraber quickly looks at ltsp-update-image for a call to chmod
<lamont> I added a chmod 644
<stgraber> thanks
<lamont> meanwhile, I chmodded the image
<stgraber> I really hope that's the last time I have to ping you to fix things I broke this week ;) ... would be great if Edubuntu started to build as it's supposed to so I can get it tested and then focus on all these other things remaining on my Ubuntu todolist ... (release is getting really close now)
<lamont> yeah - if someone wants to tickle just the ISO build, it should work this time - rebuilding the livefs won't right now, it'll 403 again
<slangasek> launching an ISO build
<stgraber> slangasek: thanks
<lamont> ta
#ubuntu-release 2010-03-28
<slangasek> lamont: http://terranova.buildd/~buildd/LiveCD/lucid/edubuntu-dvd/current/livecd.edubuntu-dvd-ltsp.squashfs: ERROR 403: Forbidden.
<lamont> remind me to stab myself in the eye sometime, pls
<lamont> chmodded, and typo fixed
<lamont> slangasek: you wanna kick another edubuntu-dvd/i386 build, so I can actually make sure this works before I upload 1.113
<slangasek> lamont: livefs build or ISO build?
<lamont> well, if stgraber wants his iso faster, you could do iso first, and then fs+iso for me, I suppose
<lamont> 644  != 0644
<slangasek> heh
 * lamont sleeps
<sbeattie> slangasek: FYI, the cdimages still identify themselves as alphas, not betas
<slangasek> sbeattie: the current ones?  we reset to 'alpha' for dailies that aren't beta candidates
<sbeattie> slangasek: ah! Yes, the dailies.
#ubuntu-release 2011-03-21
<zul> l
<stgraber> who should I contact for yet another kde language pack breaking Edubuntu livefs build ?
<cjwatson> I asked pitti about that this morning
<cjwatson> (#ubuntu-devel)
<pitti> still in the pipeline
<stgraber> cool, thanks
 * stgraber go read #ubuntu-devel's backlog
<stgraber> ah, ok, it broke more than just edubuntu this time ;) Usually we are the only ones getting the weird issues as we include all the existing langpacks and get broken livefs when a langpack stops being generated (or similar).
<pitti> stgraber, cjwatson: langpacks fixed; was noise in the source dirs on macquarie, sorry about that
<cjwatson> thanks
<stgraber> yeah ! thanks pitti
<stgraber> can we get a respin ?
<pitti> stgraber: the two packages still need to build/publish
<pitti> stgraber: tomorrow's cronjobs will take care of it, or do you need it urgently?
<stgraber> I guess we can wait till "tomorrow" (as in, later this evening here).
<highvoltage> stgraber: fine, I'm here now :)
<stgraber> highvoltage: cool ;)
<micahg> skaet: ping re latexila and cairo dock
<skaet> micahg, latexila seems reasonable, impact scope (via rdepends) is localized, approved.    looking into cairo dock now.
<skaet> micahg,  what's the bug number for cairo doc?   (am not spotting it, probably overlooking something :P )
<micahg> skaet: bug 723994, it's not entirely ready for upload yet, but basically it's in Debian, but we still might need to keep a diff, I hope to have it ready before beta
<ubot4`> Launchpad bug 723994 in cairo-dock (Ubuntu) "FFe: Please update Cairo-Dock to 2.3.0~0rc1 version (affects: 2) (heat: 14)" [Wishlist,New] https://launchpad.net/bugs/723994
<skaet> micahg,  have gone in and subscribed ubuntu-release team to it, so it shows up on the list properly, and indicatedits being targetted to Natty.     When its ready,  please update the bug with the testing done and scope of impact, so we can figure out the risk and timing based on when its available.  :)
<micahg> skaet: ok, thanks
<ScottK> skaet: Why do we have a new mailing list for the Ubuntu Release team?  We already have a mailing list.
 * iulian nods.
<skaet> ScottK, Iulian,  because I was trying to send a message to just the members of the release team to do some coordination and discussion, and since its set for individuals right now, people weren't able to see each others responses.
<ScottK> skaet: We have ubuntu-release on lists.ubuntu.com.
<ScottK> https://lists.ubuntu.com/mailman/listinfo/Ubuntu-release
<skaet> ScottK, Iulian, Sorry, was OTP.  Yes we have that list, but the culture that has evolved around it, is that it appears to be generally used for announces from what I've been able to observe (since I've been the one posting to it mostly for the last couple of months ;) ).   There are 50+ folk subscribed to it, most with gmail accounts and names I don't recognize, so I think they're expecting it to be release announc
<skaet> ements.
<nhandler> skaet: I don't think it has ever been marketed as being for release announcements. That is what ubuntu-announce and ubuntu-devel-announce are for.
<skaet> nhandler, it seems to be mostly a dead list if you look at the archives, and with 50+ folk subscribed didn't feel like a good place to have the discussion about final release freeze date.
<slangasek> skaet: quite - that list exists for (public) discussion among the release team, that it's mostly used for announcements these days is really beside the point
<slangasek> I don't think we really want another new mailing list
<nhandler> I also think you will find a number of developers and users subscribed to that list for the sole purpose of being able to observe these sorts of discussions
<skaet> ok.   will tryi it that way then.
<skaet> and see what emerges.
<ev> slangasek: are you on archive admin duty today? Would you mind NEWing apt-clone?
<slangasek> ev: I am, and I would not mind in the least
<ev> yay, thanks
<slangasek> ev: I'm assuming it's ok for this to be in universe, it's not expected to go into main this long after FF?
<ev> it already exists in ubiquity, this is just better organizing things
<ev> so I'd like it to go into main
<slangasek> ok
<slangasek> accepted
<ev> brilliant, thanks again
#ubuntu-release 2011-03-22
<doko> slangasek: now after the multiarch email, should it be safe for a rebuild test?
<iulian> cjwatson: Could you also sync kadu 0.9.0-1, please?  bug #739335
<ubot4`> Launchpad bug 739335 in kadu (Ubuntu) "[FFe] Sync kadu 0.9.0-1 (universe) from Debian unstable (main) (affects: 1) (heat: 10)" [Wishlist,Confirmed] https://launchpad.net/bugs/739335
<cjwatson> iulian: done
<iulian> cjwatson: Ta.
<cjwatson> rebuilding Ubuntu desktop following the overrides fix from earlier
<didrocks> cjwatson: hey, so what Neil propose is to roll a tarball over night on Wednesday (once the US guys integrated this work), then we all test the work on Thursday morning  and do the upload right away, what do you think?
<cjwatson> when have you done the upload to natty before?
<didrocks> cjwatson: you mean, last unity release? it was on Thursday
<cjwatson> when on Thursday?
<didrocks> was at 4 UTC IIRC
<cjwatson> 4am or 4pm?
<didrocks> 4pm, we aim at afternoon release for the weekly uploads
<didrocks> but not for this beta one
<seb128> cjwatson, usual schedule is that njpatel rolls the tarball in the uk afternoon and that didrocks pick it up and upload before eod
<didrocks> we will aim for an upload at 9/10am UTC
<njpatel> yeah, I'll roll before you guys wake up in CET
<cjwatson> it's not ideal, but it is an improvement
<cjwatson> that would presumably mean we get some testing throughout the EU day
<didrocks> right
<njpatel> Yes
<cjwatson> is there anything that can be done to increase the probability that if things go wrong we can move back by reverting changes rather than having to move forward and debug?
<seb128> landing usually takes some 3 hours
<seb128> i.e nux needs to be built and published than unity builds
<didrocks> cjwatson: we still can revert both libnux and unity (as unity is the only nux consumer)
<cjwatson> but that's an all-or-nothing thing
<didrocks> and as compiz release will be today, hopefully, we won't depend on that ABI breakage
<didrocks> yeah
<cjwatson> I agree that moving the compiz release forward significantly decreases the surface area of things that might go wrong on Thu
<didrocks> basically, libunity/dee/places are independent
<didrocks> let me check we don't have melt changes there
<seb128> going one version backward doesn't seem the best way to move toward a solid natty release anyway so downgrading doesn't seem something we should plan for
<seb128> we never had a weekly release broken enough that we had to rollback or that we couldn't have shipped a CD with it until now
<skaet> seb128,  we need a fall back, given the scope of changes coming in at the last minute, and the visibility of this beta
<didrocks> seb128: agreed on that, we had extra crashers, but they all have been fixed in due time when we saw it was a wide impact
<seb128> skaet, we have weekly rollouts, that one doesn't seem to be especially disruptive to me?
<seb128> it's never over a week work and tested by a complete team during the week
<skaet> seb128,  its the scrollbars landing so late, and we really don't have a full development week here, but rather just a couple of days.
<seb128> skaet, we have some annoying crashers that collect duplicate in the current version though, I would really rather look to a way of moving forward and getting issues fixed than planning on staying backward
<doko> skaet: I would like to ask for a standing freeze exception, mostly for universe packages to fix ld-no-add-needed and gcc-4.5-ftbfs, introducing new upstream versions with syncs/merges if fixes are available in debian, as long as we don't introduce new library sonames. would that generally be ok with you?
<seb128> skaet, scrollbars have nothing to do with unity though
<seb128> skaet, they don't seem on track to land this week to me, if we speak about overlay scrollbars
<didrocks> those changing are totally independant to nux/unity
<cjwatson> seb128: at least some previous weekly releases before milestones haven't worked well enough to make the milestone releasable until late Monday night, which really eats into validation time
<cjwatson> a few bug fixes are one thing, that wouldn't be a big deal
<cjwatson> being badly broken on Monday is a problem
<seb128> well usually they did plan 2 released, one on thursday and one bug fix one on monday
<didrocks> cjwatson: we didn't push broken things in nattyâ¦
<seb128> and that's because they were still landing features
<seb128> that's not the case there
<seb128> we are over feature freeze
<cjwatson> err, multitouch!
<njpatel> what about it?
<cjwatson> new feature not yet in natty, landing in this update, right?
<seb128> cjwatson, that should makes any difference on normal desktop installs though
<cjwatson> sure, but even so, it's a new feature being landed
<cjwatson> I will have to look back through history to find out what happened, but I'm certain that we have had serious issues on the Monday of a milestone this cycle
<seb128> cjwatson, well seems you guys are freaking out for some reasons I don't understand
<cjwatson> I'm not freaking out, I'm trying to minimise risk
<seb128> cjwatson, right as said those were weeks with 2 releases planned
<cjwatson> bug fixes on the Monday of a milestone should be a last resort, not a plan
<seb128> one to land features being short on time, one to fix issues
<seb128> that's not the case this week
<cjwatson> er, on the Monday of a beta, sorry
<seb128> there is no hurry feature landing
<cjwatson> so is what you're saying that the Unity release this Thursday will be small and much more risk-free than previous releases?
<didrocks> cjwatson: that was for alphaâ¦
<seb128> the alpha2 rollouts being done on monday were planned this way to give extra time to land features for the thursday
<cjwatson> didrocks: yes; we're looking for assurance that this will not be like that
<didrocks> cjwatson: and only bug fixes. Otherwise, freezing on Monday morning has no meaning for alpha
<didrocks> cjwatson: and as I told you, it's not planned for beta as we have one week freeze
<cjwatson> so what is the character of this Thursday release?
<cjwatson> is it mainly new features or mainly bug fixes?
<seb128> cjwatson, it's not a trivial update but it's focussed on bug fixing and stabilization where alpha were focussed on rushing to land features missing still
<seb128> it's mainly bug fixing and stabilization
<seb128> with some ui tweaks
<cjwatson> if it's not something you're planning to *have* to fix up four days later, I am less worried about it
<cjwatson> I'd still like it as early as possible to minimise risk
<seb128> and a bit of new things (the ffe which got granted)
<seb128> cjwatson, right, the alpha landings were scheduled this way, land thing half broken and do a round of fixing on monday
<cjwatson> but can you see why the release team is taking a once-bitten-twice-shy approach?
<seb128> that's not the case there
<seb128> the release is planned to be stable
<cjwatson> it's hard to distinguish planned-breakage from just-plain-breakage
<cjwatson> from our point of view
<cjwatson> we just see that it made us be hugely stressed for three days
<seb128> <cjwatson> but can you see why the release team is taking a once-bitten-twice-shy approach?
<seb128> yes
<seb128> though I didn't realize that people got really bitten before
<cjwatson> so we're just trying to make sure that we're not going to be hugely stressed for this reason at least, this time round :)
<njpatel> seb128, didrocks Just to be clear, we've already agreed not to do a Monday release right?
<seb128> I though that stabilizing alpha on mondays was a clearly communicated and agreed decision between teams
<seb128> njpatel, yes, we need something stable tomorrow night
<njpatel> right
<didrocks> njpatel: right, as that for quite some time alreadyâ¦
<seb128> njpatel, beta needs extra testing and stability
<didrocks> and there is no released planned on Monday: https://launchpad.net/unity/+series
<didrocks> contrary to the other time
<njpatel> Yeah, this all breaks for US/EU people but whatever
<njpatel> that's fine, I'll release before Thurs AM
<cjwatson> OK
<skaet> seb128,  which specific FFes  are you refering to for the new things?   can you be specific on when each part will land?    all on Thurs AM?  or some before?
<seb128> didrocks, do you have a list of the ffe pending?
<cjwatson> and to be clear, we don't object if it turns out that you absolutely *need* to fix something on Monday - the distinction is whether you're planning for it, or whether it's something that comes up
<seb128> njpatel, ^
<seb128> cjwatson, right, nobody planned to be late for this round
<skaet> +1 on what cjwatson said.  ^^
<seb128> alpha were rushs because we were behind
<cjwatson> with the intention that we can do an initial validation pass on Monday
<cjwatson> understood
<njpatel> skaet, we land them in trunk as the week goes on and roll on thurs morning normally (so they get testing through the week)
<didrocks> seb128: the latest one is the MT support: https://bugs.launchpad.net/unity/+bug/737601
<ubot4`> Launchpad bug 737601 in unity (Ubuntu) (and 1 other project) "Restore MT support in Unity (affects: 1) (heat: 879)" [Undecided,In progress]
<seb128> skaet, ^
<njpatel> skaet, so we've landed a big change already, one more from me today, and then minor bit stomorrow (and testing) until release tomorrow evening
<skaet> njpatel,  thanks,  this is what I was looking to understand.
<njpatel> cjwatson, We're working on the idea that we're not allowed to upload past thursday morning, unless we've broken the world
<njpatel> and we're not planning to do that (april 1st is still some time away ;)
 * skaet notes release is on March 31st... 
<seb128> skaet, you mentioned scrollbars, that's another story
<cjwatson> *beta 1* release is on March 31st :-)
 * njpatel makes sure that the launcher icons turning into pictures of Mark is still working
<seb128> skaet, but that shouldn't have any impact on the default installation
<cjwatson> (having gone "oh god it isn't is it?")
<skaet> lol
<doko> skaet: I would like to ask for a standing freeze exception, mostly for universe packages to fix ld-no-add-needed and gcc-4.5-ftbfs, introducing new upstream versions with syncs/merges if fixes are available in debian, as long as we don't introduce new library sonames. would that generally be ok with you?
<skaet> seb128,  and there shouldn't be any impact or interaction from the new changes with 2-D ?
<skaet> doko,  sorry to not getting to your early post.   trying to follow the thread here.
<seb128> skaet, from what? scrollbars? or unity 3d?
<skaet> seb128,  either ;)
<seb128> skaet, reply to doko, when we can continue on unity and scrollbar after that
<seb128> skaet, what do you call 2d? unity 2d or GNOME classic? ;-)
<seb128> but no, nothing should impact on either of those
<doko> no haste, if you are in a meeting ...
<skaet> doko,  just trying to settle issues with the release... and am thinking about the implications of what you're asking.
<skaet> doko,  I don't think we can take a broad FFE approach, uploadable at any time approach right now.  However there where be windows of time, where getting the fixes in should be ok, as long as they are just fixing the ld-no-add-needed, and gcc-4.5 ftbfs.  Its what else might be included in the packages with those fixes, compared to whats in the repository that concerns me.
<doko> skaet: sure, I know, but we'll probably release with a lot of ftbfs without such an approach
<skaet> That being said,  if the package is in universe a broader FFEs for those actual ones, is probably ok.  If its not in universe - would like it explicitly FFe's and implications scrutinized a bit more.
<skaet> doko, can we keep the uploads down until after the beta 1 is out, and then revisit on the friday meeting?
<skaet> I'd like to get the ftbfs fixed as well, just they can't go in, in an ad hoc manner.
<doko> skaet: I didn't ask for ad-hoc
<skaet> doko,  I misunderstood broad FFE then.
<skaet> doko,  what is specific proposal for the changes to universe,  ( when uploads ),  and what is it for the others.  (reacting to the word "mostly universe") in you original request).
 * skaet looks at format of above line and hangs her head.
<doko> skaet: s/universe/not main/
<skaet> doko,  so request is for blanket approval for FFEs in non main archives only?
<doko> skaet: yes
<doko> and without library transitions
 * skaet thinking....
<skaet> doko, if the changes are only to fix the ftbfs and not introducing new features from the current version,   we should be fine then.   If there is functionality change in together with the fixes, would prefer those get considered on a case by case basis or wait to Oneiric.  If you avoid uploads during the beta freeze windows, esp. if we're having to do alot of rebuilds to get the images, that would be appreciated.
<skaet> s/ftbfs/ ftbfs and ld-no-add-needed/
<doko> skaet: ok, will file rc reports then, please feel free to re-assign these ;)
<skaet> doko,  fair enough, and thanks for pushing for this.  getting these ftbfs cleaned up is a good thing.
<skaet> seb128,  if nothing thats coming should cause a regression on unity 2d or GNOME classic,  am happy.    :)
<seb128> skaet, ok great ;-)
<seb128> skaet, btw you were mentioning scrollbars before, did you have any specific concern about those? do they need to land in beta if they land in natty?
<skaet> I had thought they'd be showing up this week.   However if they're not stable/debugged enough, would like to very carefully work out when their landing.
<skaet> seb128 ^^
<seb128> skaet, ok, I'm still waiting on an update patch to gtk to review and the bug will need a ffe approval once that's done
<seb128> updated
<seb128> then we need the new source to be uploaded to universe, reviewed, approved, etc
<skaet> ok,  lets over communicate a bit on this one, and judge the tactical window based on when things are ready and solid enough from your side.
<seb128> ok
<seb128> skaet, well I'm not happy that we have to ship a gtk hack in ubuntu but it doesn't seem it's going to be an issue for the distro stability so it's already something
<seb128> i.e the patch is not likely to break things, it's just that it's not done the right way and hackish
<seb128> I've no strong opinion about the lib itself yet but since that's an opt-in thing we can still evaluate how stable it is
<skaet> seb 128,  expectation set for the release notes is then that the implementation will improve in oneiric,  and interface is provided as a prototype?  will be on stand by for more data on the lib itself.
<seb128> skaet, ok
<seb128> thanks
<seb128> I will keep you updated if I get new infos on that front
<skaet> sournds good
<skaet> sounds, even
<skaet> thanks
<doko> skaet, ScottK, Riddell: what's the state of kde on armel?
<skaet> doko,   I remember seeing that they fail to build in the daily reports, but am not sure of I've heard a root cause, yet.    Went to go look up the recent reports, but I appear to have been a bit enthusiastic in cleaning my inbox this morning. :P
<cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/ is your friend
<skaet> cjwatson,  awesome!  :D
<lamont> ScottK: postfix 2.8.2-1 uploaded to debian... did you want me to ask for a sync,  or upload or ??
<Riddell> doko: mostly good I believe except for packages which use opengl
<doko> Riddell: hmm, just saw a subversion build failure:
<doko> The following packages have unmet dependencies:
<doko>  kdelibs5-dev : Depends: kdoctools (= 4:4.6.1-0ubuntu2) but it is not going to be installed
<doko> E: Broken packages
<lamont> I find that I am annoyed at the arm builders... quiescing the whole lot of them, then I'm going to make them happy , and put them all back in the pool together.
<Riddell> doko: indeed kde4libs failed and there's no logs so I don't know why
<slangasek> given that it's armel, perhaps it's related to lamont's above comment about builders being unhappy
<slangasek> I've requested a retry
<slangasek> (at least then we'll get a log, hopefully)
<lamont> if it was building before I just stabbed them all, well, that'd be why there's no log
<lamont> is the pile of builds on i386 a translations update pile?
<ScottK> doko: As Riddell said, the issue right now is packages that use GL.  I'm not sure where they are on getting fixed.  I think slangasek had someone looking into that.
<doko> ScottK: well, lets hope that kde4libs gets built first ...
<ScottK> doko: Sure.  It's built before so there's no reason to think it won't.
#ubuntu-release 2011-03-23
<ev> might I pester someone to process the overrides and review https://bugs.launchpad.net/ubuntu/+source/apt-clone/+bug/739808 today? I'd like to get a new ubiquity in to fix https://bugs.launchpad.net/ubuntu/natty/+source/ubiquity/+bug/738366
<ubot4`> Launchpad bug 739808 in apt-clone (Ubuntu) "[MIR] apt-clone (affects: 1) (heat: 8)" [Undecided,New]
<skaet> all,  buildd turnaround for the next couple of hours may be a bit delayed as a fix for a security vulnerability is pushed through.   Please contact me directly if this is causing you problems.
<ScottK> skaet: What's the difference between armel server and headless images?
<skaet> ogra_, ^^
<ogra_> ScottK, the list of packages that are available
<ogra_> headless only ships ubuntu-standard
<ScottK> OK.
<ogra_> they might turn into the base for server images in oneric
<ScottK> Right.
<ogra_> with pre-Ã¼populated apt cache or some such
<ScottK> ogra_: Would it make sense to swap the Kubuntu mx51 image that I'm currently volunteered to test for a headless image instead?  Should be easier to test and more generally useful (sudo apt-get install kubuntu-desktop after install isn't very hard).
<ogra_> up to you, you own it :)
<ScottK> Should/Would
<ScottK> OK.  I think it makes sense.
<ogra_> installing packages on headless definitely requires a working net connection
<ogra_> thats the only thing to regard
<ScottK> Ah.
<ogra_> and it defaults to serial all over for oem-config
<ScottK> That causes me to have second thoughts.
<ScottK> Let me consider it.
<ogra_> well, you can disable serial by dropping the preseed option from cmdline
<ogra_> and indeed oem-config offers netcfg ... but you still need a network to attach to
<ogra_> (on headless we also default to offering tasksel btw, so installing kubuntu-desktop should be very easy ... you could even preseed it)
<ScottK> ogra_: As it is now, if you install you don't have working video?
<ScottK> I'm trying to understand what defaulting to serial means.
<ogra_> you do, but oem-config does run on the serial tty by default
<ScottK> I see.
<ScottK> So if I drop that, it's like a server oem install, but fewer packages.
<ScottK> ?
<ogra_> we preseed debian-installer/framebuffer=false and set console=ttyO2,115200n8
<ogra_> no packages
<ScottK> Not even the packages in ubuntu-standard?
<ogra_> they are installed but not shipped as debs
<ScottK> So it's a pre-installed image with ubuntu-standard, so after an install I have a bare ubuntu-standard system.
<ogra_> imagine a live image with only ubuntu-standard and defaulting to oem-config ... no archive or anything
<ogra_> yeah, right
<ScottK> So worst case with no network at install time, I get a network, reboot, and add stuff, right?
<ogra_> yes
<ogra_> you have a fully working cmdline system in any case
<ScottK> Why do you default oem-config to serial?
<ogra_> and we have tasksel so you could preselect kubuntu-desktop in a preseed cmdline option
<ogra_> because it is mainly designed as developer image
<ScottK> OK.
<ScottK> Would you be willing to help me get this set up?  I can test it, but it's been ~a year and a half since I did anything with getting images set up and what little I knew about then is long forgotten.
<ScottK> I'm actually not that concerned about preseeding taskself for Kubuntu.
<ogra_> well, we need a flavour based hack for the image builder so your cmdline options are different
<ScottK> It would be just the standard headless less the serial preseed.
<ogra_> right
<ogra_> hmm, tricky
<ScottK> ENOCLUE on what needs to be done to the image builder.
<ogra_> well, looking at the code the imx51 images are 100% babbage board images
<ogra_> do you plan to use babbage ?
<ScottK> What I have is Efika MX Smarttop.
<ogra_> right
<ogra_> do you have a kernel and bootloader for that in the archive =
<ogra_> ?`
<ScottK> I think we do.
<ScottK> I've been procrastinating investigating this.
<ogra_> i know the linaor one doesnt work for one of the efikas
<ScottK> We have a kernel.
<ScottK> err
<ogra_> i think the netbook though
<ScottK> I'm told the linaro one should work now.
<ScottK> I think it's the netbook that doesn't work.
<ScottK> The smarttop, I think, works.
<ogra_> i was told yesterday that it only works on one of the models
<ogra_> yeah
<ogra_> i think someone said efikasb doesnt work
<ogra_> who was supposed to implement that on the builder
<ScottK> If you'd look into what it would take to get the headless image while I verify we have something that works on my hardware, I'd appreciate it.
<ScottK> Dunno.
<ogra_> it's several days of work to implement a new subarch
<ScottK> Sigh.
<ScottK> Is it a new subarch?
<ogra_> and especially harder if you dont have the HW to test on while developing
<ScottK> Right.
<ScottK> Let me go investigate a bit and see where we are.
<ogra_> we cant drop imx51 i think
<ogra_> so it would likely be a new subarch
<ogra_> (the builder needs to be able to roll images for older releases still so i wouldnt like to drop imx51)
<ScottK> Does it?
<ogra_> (not that we usually do that for armel)
<ScottK> I thought Karmic was the last mx51 release?
<ScottK> It's about to go away.
<ogra_> i thought it was lucid
 * ScottK looks
<ogra_> lucid should be dove and imx51 plus an unsupported omap3 image
<ScottK> You're right.
<ScottK> nevermind
<ogra_> anyway, we can probably drop it if nobody complains ... its just not the usual habit
<ScottK> It would be nice to have something going forward.  I think that's more important than the last 6 months of support on Lucid (since it's non-LTS)
<ogra_> but still, someone needs to implement it, the arm team is swamped in pre beta work atm :(
<ScottK> Let me see what I can figure out.
<ogra_> we should have identified someone from the cdimage team to implement it during UDS
<ogra_> lets note that for next time :)
<ScottK> I shouldn't have assumed someone had been.
<ogasawara> skaet: just a heads up, I'm likely going to need a beta freeze exception to do a no-change kernel upload to force a rebuild due to the recent gcc upload.
<skaet> ogasawara, when do you expect the rebuild to happen?
<skaet> ogasawara, thanks for the heads up,  btw.  ;)
<ogasawara> skaet: gcc should finish building by tomorrow and I'll plan to upload the kernel after that.  The arm build takes the longest for the kernel (~19hrs) so it should finish by fri morning your time.
<ogasawara> skaet: but that's a day past beta freeze
<skaet> ogasawara, thanks for letting me know.   Should all work out ok.
<micahg> skaet: I might need a beta freeze exception for gmusicbrowser (it's really small) for xubuntu (default music player), latest it would be ready would be midday tomorrow
<skaet> micahg, betafreeze goes into effect at 2300 UTC.    Let me know if you can't make that deadline tomorrow.
<micahg> skaet: 2300UTC tomorrow?
<skaet> yup.
<micahg> skaet: shouldn't be a problem then, thanks :)
<slangasek> ogasawara: do you need to wait for gcc to finish on arm before uploading, in fact?  Are there any out-of-tree modules that we need to worry about building for arm?
<slangasek> could I get an archive admin to poke at the linux-linaro-* kernels in binary NEW?
<slangasek> would like to get that metapackage uploaded today
<ogasawara> slangasek: I was talking with tgardner and we really don't have any out of tree modules we really care about in Natty that isn't handled by a DKMS package.
<slangasek> ogasawara: well, AIUI dkms doesn't protect anyone from the issue with checking compiler versions, as that's in the upstream kernel build rules
<slangasek> I guess my question is, do we care if dkms works on armel
<slangasek> for beta anyway
<ogasawara> slangasek: I don't think we really care, but since skaet said it should all work out ok to upload the kernel a day late, I'll just do it.
<slangasek> ok
<kirkland> ScottK: I'd like to get a FFe to upload the latest version of bikeshed into Natty universe;  it adds small/useful shell script and manpage;  the changes are visible at: http://bazaar.launchpad.net/~bikeshed/bikeshed/trunk/revision/84
<ScottK> kirkland: If the only feature change is a new script (I consider the manpage a bug fix), please go ahead.
<kirkland> ScottK: that's all;  thanks.
#ubuntu-release 2011-03-24
<zul> zul
<highvoltage> highvoltage
<highvoltage> TIMMEAH
<nigelb> highvoltage: heh
<didrocks> cjwatson: skaet: FYI, nux and unity uploaded, release well tested :)
<didrocks> now more than time to go to bed, see you tomorrow
<skaet> didrocks:  awesome.    thanks!   sleep well.
<didrocks> thanks :)
<ogra_> lamont, Calling command: /home/buildd/bin/BuildLiveCD -f ext3 -s omap4 -d natty ubuntu-headless
<ogra_> ssh: connect to host acorn.buildd port 22: No route to host
<ogra_> acorn.buildd finished at Thu Mar 24 08:38:03 UTC 2011 (failed)
<zul> does anyone know what happened to the amd64 iso for server today?
<ogra_> did you check the logs?
<zul> where are the logs?
<ogra_> http://people.canonical.com/~ubuntu-archive/
<ogra_> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/natty/ for server
<zul> ogra_: thanks
<cjwatson> zul: I've fixed the overrides for the next publisher run
<zul> cjwatson: cool thanks..
<cjwatson> (some packages were at Priority: required when they shouldn't have been, due to a snafu in NEW)
<Riddell> is this acceptable? https://lists.ubuntu.com/archives/ubuntu-archive/2011-March/040160.html  linking to sources on sourceforge to comply with MPL/GPL obligations, I would say not since the files on sourceforge might disappear
<cjwatson> I'd tend to agree, we should meet our source distribution obligations without the aid of third parties
<cjwatson> if nothing else it's in our own interest to do so
<cjwatson> (though I haven't read the exact terms of the MPL here)
<ScottK> Would a copy of the source at p.u.c be sufficient?
<cjwatson> why can't it go in the package?
<cjwatson> it doesn't have to be built from it if the governing licence doesn't require that; but we have a perfectly good standard way to distribute source, I'm not sure why we wouldn't want to use it
<ScottK> Makes sense.
<ScottK> cjwatson: I discussed adding mx51images for Headless and Kubuntu with skaet last night and she was in favor.  I also confirmed that the hardware I have to test them is functional with that subarch (and doesn't need a separate one of it's own).  Would you be able to help me out with getting the images started?
<cjwatson> ScottK: possibly, what's involved?
<ScottK> cjwatson: For Headless it should be just another subarch build.
<ScottK> I'm not sure what exactly needs to be done for that.
<cjwatson> well, what's the required image format like?
<ScottK> I don't know more than 'like the ompa3/4 images'
<cjwatson> I think we used to have i.MX51 images.  Would it be sufficient to resurrect them?
<cjwatson> in fact, the code's still in debian-cd for natty, just not built
<ScottK> It should be.
<cjwatson> what kernel should be used?
<cjwatson> we'll need a d-i build against it
<ScottK> It's built out of the linaro kernel.
<ScottK> let me look
<ScottK> https://launchpad.net/ubuntu/+source/linux-linaro-mx51
<cjwatson> good, it has udebs at least
<seb128> should bug #727726 be assigned to someone or milestoned? it's still an issue
<ubot4`> Launchpad bug 727726 in ubiquity (Ubuntu Natty) (and 1 other project) "gnome panel is about 4px instead of 30 on install (affects: 2) (heat: 177)" [Low,Confirmed] https://launchpad.net/bugs/727726
<seb128> the current custom partioner screen and tz selection page don't fit on a 1024x600 screen also
<seb128> there is bug #732068 and a serie of others in launchpad
<seb128> but none seems targetted for natty
<ubot4`> seb128: Bug 732068 on http://launchpad.net/bugs/732068 is private
<seb128> bug #732068
<ubot4`> Launchpad bug 732068 in ubiquity (Ubuntu) "partitioning part of LiveCD installer doesn't fit on 1024x600 screen (affects: 1) (heat: 254)" [Undecided,New] https://launchpad.net/bugs/732068
<seb128> it's not? stupid bot :p
<cjwatson> ev: ^- FYI
<ev> indeed, on my hit list via a separate bug
<ev> marking as a duplicate now
<seb128> ev: thanks
<seb128> ev: btw we were discussing ubuntu-geonames with desktopers yesterday, do you know if the fact that the locations are not translated would be easy to fix for natty?
<seb128> not sure where the datas are coming from and if the translated infos are available
<ev> https://bugs.launchpad.net/ubuntu-geonames/+bug/729022
<ubot4`> Launchpad bug 729022 in indicator-datetime (Ubuntu Natty) (and 5 other projects) "Locations in the settings are not localized (affects: 1) (heat: 10)" [Low,Invalid]
<ev> mterry and I talked through it a bit yesterday in #ubuntu-installer
<ev> I don't know if I'll have time for that, but fortunately it's a largely a server-side problem
<seb128> ev: right, the question is rather "is that something easy to fix, or is the current database you use not providing what is needed"
<ev> we can anticipate the eventual change by passing the locale as an argument to the url
<ev> the database has it
<seb128> ev: or asked differently "should we look at using libgweather for the indicator to fix that issue"
<seb128> which is what the GNOME applet uses
<seb128> it has its locations translated
<ev> it has a table of translated names
<seb128> ok
<seb128> so let's try to fix it
<seb128> ev: thanks ;-)
<ev> http://irclogs.ubuntu.com/2011/03/23/%23ubuntu-installer.html around 14:24
<ev> sure
<slangasek> lamont: do you know why https://launchpad.net/ubuntu/+source/libgd2/2.0.36~rc1~dfsg-5ubuntu2/+buildjob/2342500 is starting in 1 minute for 30 minutes?  Is that within tolerance for launchpad's ability to predict start times, or is something wedged? :)
<Daviey> I thought https://launchpad.net/ubuntu/+source/gcj-4.5/4.5.2-7ubuntu1/+buildjob/2342162 looked wedged... but seems it does take a long time!  took 18 hours, 35 min to build on Maverick.. that is awful.  (compared with 2.5 hours on amd64)
<slangasek> right, libgd2 is building now, so 'sallgood
<doko> Daviey: don't worry about java core packages, take care of eucalyptus ;p
 * slangasek chuckles
#ubuntu-release 2011-03-25
<micahg> hi skaet, still around?
<skaet> hi micahg, yup,  what's up?
<micahg> skaet: 1st, I have to apologize, I forgot to tell mr_pouit that gmusicbrowser needed an FFe for the sound menu integration, should I file a bug and get a retroactive FFe?
<micahg> I think he assumed I already got it, but it got lost in the shuffle
<skaet> micahg, yes please.
<micahg> skaet: ok, thanks, second, what to do with cairo-dock, bug 723994
<ubot4`> Launchpad bug 723994 in cairo-dock (Ubuntu Natty) (and 1 other project) "FFe: Please update Cairo-Dock to 2.3.0~0rc1 version (affects: 2) (heat: 16)" [Wishlist,New] https://launchpad.net/bugs/723994
<skaet> you were waiting for some things to land,  where are they?
 * skaet hasn't looked at the bug yet, and probably should :/
<skaet> s/yet/today
<micahg> skaet: so, now he tells me the Debian package isn't good and we should just use his version, so I'm a little confused, maybe he was hoping Debian would take his changes
<micahg> I was hoping we would just be able to sync, but that's not possible apparently
<skaet> micahg,  my preference is to leave it on the bench then for a while, and sort it out after beta1 comes out.
<micahg> skaet: we can still upload then?  Does UiF factor in?
<skaet> It does.
<skaet> But right now,  we're at UIF as well.
<skaet> UIF/BetaFreeze was 2300 UTC
<micahg> ugh, ok
 * skaet should send out a note.   Was chasing too many loose ends earlier.   Will do now
<micahg> skaet: bug 742185
<ubot4`> Launchpad bug 742185 in gmusicbrowser (Ubuntu) "FFe: Please Sync gmusicbrowser (universe) 1.1.7-1 from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New] https://launchpad.net/bugs/742185
<micahg> changed title to look less actionable :)
 * micahg will have to go hunt for whale food now...
<micahg> skaet: anyways, thanks
<skaet> micahg,  gone in and added comments, and subscribed ubuntu archive admin.
<micahg> skaet: no need, it's already in
<skaet> heh
<skaet> okie
<micahg> that's why I changed the title and apologized :)
<skaet> :)
 * skaet needs to get that note out now...
* slangasek changed the topic of #ubuntu-release to: Beta Freeze in effect! | Natty Narwhal Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release managers with beer | we accept payment in cash, check or whale food | melior malum quod cognoscis
<lamont> slangasek: it's because y'all keep stuffing huge builds through arm, and breaking sleeves and stuff
<slangasek> breaking wut
<slangasek> and hey, the biggest thing I stuffed through the arm queue today was php5
<slangasek> so don't look at me ;)
<lamont> well, all y'all
<lamont> by which I mean DOKO
<lamont> though to be fair, that's mostly because he got a bunch of huge phat packages dropped on his head a few years back
<lamont> doko_: gcj-4.5 is also playing shooting-gallery with the armel targets.
 * lamont plays whack-a-mole with the outdated gcj-4.5 (-ubuntu1) on hubbard
<micahg> lamont: I'm about to upload chromium in a couple hours :)
<slangasek> yeah, and I think the double gcj-4.5 upload is due to a multiarch buglet, so you can blame that one on me anyway
<micahg> lamont: actually if you're short armel builders, I can save chromium for the weekend
<micahg> hmm, is this new, all uploads need manual approval until release or until beta freeze is over?
<lamont> slangasek: heh
<lamont> anyway, the obviously mad armels are all stuffed back into the race
<lamont> the not-obviously mad ones will eventually be obviously mad
<lamont> but I need to go do some admin work on my daughter's laptop before she bursts into pouting
<nhandler> j/48
<chrisccoulson> skaet, could i get an NSS upload in to natty (it fixes the same issue as bug 741528, and is a pretty safe change)?
<ubot4`> Launchpad bug 741528 in firefox-3.5 (Ubuntu Karmic) (and 15 other projects) "Compromised Comodo SSL certificates puts users at risk (affects: 1) (heat: 258)" [Medium,Fix released] https://launchpad.net/bugs/741528
<cjwatson> right, we're going to be wanting queuebot then
<cjwatson> ScottK: mx51> linux-linaro-mx51 is going to need to be promoted to main to make this work.  Can you deal with any exception bugs or whatever that you feel are needed for that?
<ScottK> Sure.
<ScottK> chrisccoulson: I'd suggest go ahead and upload and someone will review it in the queue.
<cjwatson> ScottK: can I keep on calling it imx51 in d-i, or is mx51 better?
<cjwatson> I don't know the meanings of the terms
<chrisccoulson> ScottK, thanks
<ScottK> cjwatson: I'm not sure.  I'd say let's try to take the shortest path to success, but I'm not sure.
<cjwatson> it's not significantly harder either way; I'm more interested in what's right
<cjwatson> grepping for imx51 and changing it to mx51 is easy enough
<cjwatson> if that's the right thing to do
<cjwatson> but if they're just different names for the same thing, I'll stick with imx51
<ScottK> I'll ask and see if I can find out.
<cjwatson> thanks
<ogra_> cjwatson, i think linaro implemented something in flash kernel thats called mx51
<ogra_> hrm
<ogra_> we have pleany of imx arches now in the code
<ogra_> and the efika HW doesnt have a subarch check at all
<ogra_> (so from flash-kernel perspective the name doesnt matter)
<cjwatson> flash-kernel doesn't care about the d-i image name anyway, only about what archdetect says
<ogra_> (given that the kernel will likely only run on efika i would suggest calling it efikamx or some such though)
<cjwatson> (and certainly archdetect names should be static)
<cjwatson> hm, if that were the right name shouldn't it also be the kernel package name though?
<cjwatson> I don't really like *inventing* names for d-i images
<cjwatson> I'd rather either stick with current (inertia) or else match the kernel package name
<ogra_> well, flash-kernel nowadays checks for "imx5"|"mx51" and for "Freescale MX51 Babbage Board", "Freescale MX53 LOCO Board" and for "Genesi Efika MX (Smartbook)" | "Genesi Efika MX (Smarttop)"
<ogra_> i dont think archdetect has the latter two at all
<cjwatson> so is mx51 a more general term than imx51?
<ogra_> i think they are different subarches
<cjwatson> http://www.genesi-usa.com/products/efika says "Freescale i.MX515"
<cjwatson> so I guess imx51 is still accurate?
<cjwatson> so confusing
<ogra_> well, i havent been involved with mx51 at all, thats a pure linaro thing, what i know is that their kernel partially works on the nettop and should also work on the babbage
 * ogra_ checks how their kernel is called
<ogra_> -mx51
<ogra_> so call the subarch that then :)
<cjwatson> ok
<cjwatson> is there any reason to leave the imx51 subarch in place in d-i?
<ogra_> no
<cjwatson> or can I rename it to mx51?
<cjwatson> ok
<ogra_> only historical ones probably, but i doubt we'll ever to a ludic image rebuild
<ogra_> and if so, likely not with this d-i :)
<ogra_> (god, my typing sucks)
<cjwatson> ScottK: also, is there a bug for this feature in general?  if so, can it have a d-i task?
<ScottK> cjwatson: I'll be sure to add it once I write it.
<ScottK> cjwatson: It's 742430
<cjwatson> ta
<zul> skaet: can i get a FFE for new cobbler and openstack snapshot they are both in universe
<ScottK> zul: Please just file the bugs and we'll look at them.
<ScottK> cjwatson: I was going to subscribe ubuntu-mir to the bug and ask about promotion after someone approved the FFe.  I've discussed this with skaet and she OK'ed it, so I can either wait for her or some other release team member can mark it approved.
<ScottK> cjwatson: So now I look around and that's not all.  I was under the impression that we had images for Kubuntu Mobile on n900 already.  We don't.  This already has an FFe (724534), but it's kernel, linux-n900 (which is based on Linaro's) is also in Universe.  Sigh.
<ScottK> This image is also on the manifest.
<ScottK> Do pre-installed images need D-I changes?
<ScottK> Riddell: ^^^
<Riddell> I didn't know we were planning on having images for n900, would be awesome though
<ScottK> It's been on the manifest for the entire cycle.
<cjwatson> I don't think preinstalled images need d-i, but perhaps ogra could confirm
<ogra_> only oem-config
<ogra_> but you need a relatively complex debian-cd setup
<ScottK> My head hurts.
<ScottK> ogra_: Does headless need D-I?
<ogra_> no, as i said above, only uses oem-config
<ScottK> I thought that was pre-installed.
<ScottK> But great if it's both.
<ScottK> cjwatson: If we do the Kubuntu image as a preinstalled image then I don't think we need mx51 support in D-I then.  Which also means we don't need to promote the kernels, right?
<ogra_> you need the kernels for preinstalled too indeed
<cjwatson> well, not on account of d-i at any rate; I don't know what preinstalled images require/prefer in that department
<ogra_> preinstalled is pretty much identical to live images with its requirements
<ScottK> ogra_: But does the kernel need to be in Main?
<ogra_> hmm, i dont think so
<ogra_> cjwatson, we have a universe mirror antimony can access, right ?
<ScottK> It does for D-I, so avoiding that for the propsed linaro based images would be a really good thing.
<ogra_> debian-cd pulls bootloader and kernel from the archive during build so both need to be accessible from the cdimage server (antimony)
<ogra_> if thats the case it should work without promotion
<cjwatson> antimony can use universe for images that are configured that way, yes
<cjwatson> it's separated a bit to avoid universe leaking into main-only images by accident
<ogra_> well, the debian-cd post-boot-armel+mx51 script needs to be created (preferably by someone having the HW), it needs to be able to pull the bootloader from the archive and pulls the kernel and initrd from the livefs builder livefs
<ogra_> -livefs
<ogra_> i see that kubuntu-mobile already has universe enabled in livecd-rootfs
<ScottK> It does.
<ogra_> so it should be able to find the kernel there
<ScottK> So it's mainly the debian-cd work that needs doing?
<ogra_> kubuntu hasnt though
<ScottK> Ah.  Right.
<ogra_> that will likely need more changes
<ScottK> How about Ubuntu Headless?  Is that Main only?
<ogra_> you need to add a switch for COMP i guess
<ogra_> yes, headless is main only
<ogra_>         headless)
<ogra_>             LIST="$LIST minimal^ standard^"
<ogra_>             LIVELIST="$LIVE_BOOT_SCRIPTS"
<ogra_>             ;;
<ogra_> thats all headless sets as defaults
<ScottK> Because if we could just do the mx51 headless image, then I wouldn't worry about the Kubuntu one for this cycle.
<ScottK> n900 should be doable already since Kubuntu Mobile already has Universe enabled.
<ogra_> headless is completely focused on serial though
<ScottK> Right, but if one edits boot.scr before booting it to remove the oem-config preseed, then it should work, right?
<ogra_> theoretically yes, untested though
<ScottK> For mx51 I'd be willing to try it.
<ScottK> (I've got hardware)
<ogra_> we currently set console= to serial and preseed debian-installer/framebuffer=false
<ogra_> theoretically removing both should get you framebuffer oem-config in debconf mode
<ScottK> So if we could get the image built, I could try it and see.
<ScottK> If it works, then we can go from there.  I think "If you don't want to work via serial, do X, Y, Z" is not an unreasonable release note.
<ogra_> do you have a bootloader in the archive ?
<ogra_> and a working boot.scr
<jibel_> skaet, bug 703230
<ubot4`> Launchpad bug 703230 in pango1.0 (Debian) (and 2 other projects) ""rm: cannot remove `/usr/share/doc/libpango1.0-0': Is a directory" when updating to 1.28.3-4 (affects: 3) (dups: 3) (heat: 79)" [Unknown,Fix released] https://launchpad.net/bugs/703230
<ogra_> ScottK, i see u-boot-linaro-efikamx as well as u-boot-linaro-mx51evk ... with which in turn strikes me that livecd-rootfs wont be able to handle a kernel with linaro in the name OOTB, that will need a change too
<ScottK> OK.  Sorry.  Got distracted by $WORK.  I'll look at this later.
<doko_> skaet, cjwatson: please approve openjdk-6 and openjdk-6b18 (multiarch library path)
<micahg> are unseeded package uploads still welcome?
<cjwatson> micahg: generally yes, though they'll still go through the queue for review and avoidance-of-buildd-load
<micahg> ok, also, will the archive be open again after beta or remain moderated, I wasn't sure based on the beta freeze e-mail
<cjwatson> https://wiki.ubuntu.com/BetaFreeze clarifies I think
<cjwatson> we'll be open for 10 days after beta-1, then hard-freeze for beta-2
<micahg> right, that's what I remember from the last 2 cycles, just wanted to make sure something didn't change since we switched to a beta 2
<micahg> eh, relatively close at least :)
<micahg> cjwatson: you commented last release about sync with Debian uploads, when should those stop, hard freeze?
<cjwatson> I did?
<micahg> cjwatson: yeah, I uploaded enigmail that just basically merged a Debian changelog
<micahg> err, wasn't sync, was a merge
<micahg> cjwatson: was this upload: https://launchpad.net/ubuntu/+source/enigmail/2:1.1.2-1ubuntu1
<micahg> I'm just wondering where the point is to only sync/merge where we gain something instead of just being in sync or ready for sync
<cjwatson> micahg: that sort of tidy-up should only really run up to Debian import freeze IMO
<cjwatson> later than that there must be better things to do o:)
<cjwatson> substantive syncs are fine whenever a corresponding direct upload with the same change would be, IMO
<micahg> cjwatson: ok, will keep in mind for the future, thanks
<bdrung> may i upload the ftbfs fix for lintian or should i wait until the beta freeze is lifted?
<ScottK> bdrung: Go ahead and upload.
<ScottK> Worst case it sits in queue.
<bdrung> k, done
<ScottK> bdrung: The tests you dropped: Did Debian drop them too?
<bdrung> ScottK: no, but they are worthless with our two changes
<ScottK> bdrung: I don't get the no-upstream-changelog change.  IIRC we are shipping at least partial changelog in all packages.
<bdrung> ScottK: some of the test cases produced the no-upstream-changelog warning, but the testcase didn't expected it.
<ScottK> Sounds like something that shouldn't be.
<zul> robbiew
<robbiew> zul: what's up
<bdrung> ScottK: look at the test cases. they do not carry an upstream changelog.
<ScottK> OK.
 * bdrung has to leave now.
<ScottK> Did you file a bug with Debian on this?
<bdrung> ScottK: not yet, but i will forward it.
<ScottK> OK.
<zul> robbiew: sorry misfire
<robbiew> zul: lol
<ScottK> bdrung: Accepted.
<cjwatson> parted and dmraid should either go together or not at all
<slangasek> robbiew: why the proposal to drop netboot support for !x86? (https://wiki.ubuntu.com/NattyNarwhal/ReleaseImageContacts)
<robbiew> slangasek: x86?
<robbiew> uh
<slangasek> no, !x86
<slangasek> :)
<slangasek> the netboot images are free as long as we're doing an existing d-i build for the arch
<cjwatson> agreed, netboot support should be kept even if there are no testers IMO - it's actively painful to remove them
<robbiew> slangasek: I can't test them...and that was a requirement
<skaet> slangasek,  no ones signed up to test them,   d-i's will keep building
<cjwatson> skaet: I can't make them stop publishing without doing violence to d-i
<skaet> cjwatson,  don't want you to
<robbiew> "Drop from that wiki page"
<robbiew> ;)
<cjwatson> where are you proposing to drop them from, then?
<cjwatson> I don't understand
<skaet> Not publishing them as part of the 11.04 artifacts.
<skaet> This is all back to the UDS discussions on not publishing images we don't test.
<cjwatson> to where?  you mean http://cdimage.ubuntu.com/netboot/11.04/ or something?
<skaet> yes,
<cjwatson> (those are just links, sure, they're easy to drop)
<skaet> I don't want the dailies to stop.
<cjwatson> ok
<skaet> :)
<doko_> slangasek: while you are at it, please accept openjdk-6 too (and python2.6, python3.1, python3.2)
<slangasek> doko_: ack, looking
<doko_> only openjdk-6 is on the dvd, but not on the cd's
<doko_> will try to get binutils fixed over the weekend
 * lamont does another round of armel buildd restoration
<ogasawara> cjwatson: I've uploaded linux-2.6.38-7.39, could I get it approved in the queue please?
<cjwatson> ogasawara: done
<ogasawara> cjwatson: thanks
<kirkland> FYI ... ^ bikeshed upload I had okay'd with ScottK earlier this week;  I missed a one-liner in the Makefile to get the change to take effect
<ScottK> I'll review it.
<ScottK> kirkland: Accepted.
<kirkland> ScottK: thanks
<ScottK> You're welcome.
<slangasek> pango1.0 in unapproved is a multiarch upgrade-handling fix we'll want for beta
<cjwatson> slangasek: accepted; I think we want the same the other way round too?
<slangasek> from the plymouth side it just needs to be made more robust wrt these files being missing; plymouth itself shouldn't depend on pango, only plymouth-label does
<slangasek> so a bit of tuning is still needed there
<cjwatson> well, OK; I just noticed that new plymouth and old pango1.0 broke, and had been meaning to say something about it
<slangasek> yeah, we should fix it that way 'round too - I just think a better fix is in order than Breaks
<cjwatson> we shouldn't simply ignore those files being missing since that would result in no text being displayed (AIUI)
<cjwatson> I suppose we could fall back to the text theme or something
<slangasek> not that text gets displayed currently /anyway/ of course
<cjwatson> I think Breaks might result in a more consistent user experience though
<cjwatson> it gets displayed correctly for me - I can't reproduce that bug, so far
<cjwatson> at least IIRC
<slangasek> ah - I can reproduce the bug, and will see what I can figure out
<cjwatson> that'd be lovely, thanks - plymouth bugs I can't reproduce are no fun at all
<cjwatson> I should probably check again mind you
<cjwatson> works on nouveau, modulo the need to alt-f1/f7 before it shows anything (which I should investigate, but that's separate)
<slangasek> that's with plymouth in the initramfs?
<slangasek> it may be that the hook is missing something else for the initramfs case
<cjwatson> hm, now, I didn't think to try that - no, plymouth is not in the initramfs
<cjwatson> I have some time nowish, I'll wedge together an initramfs test case
<cjwatson> good call, I think that's it
<cjwatson> I don't see the blanked-out areas here like were in the image in the bug, but I don't see text either, having touched /forcefsck
<cjwatson> so that should be amenable to strace debugging
<slangasek> cool
<cjwatson> the effective diff in the grub2 upload (it's a merge, so maybe not trivial to work out which changelog entries matter) is:
<cjwatson> - Fix crash when extending menu entry line beyond 79 characters
<cjwatson> - Switch back to framebuffer page zero before loading the kernel (basically fixes black-screen that occurred on average 50% of the time when switching VTs on fglrx, and possibly broke other things too)
<cjwatson> - Stop grub-setup being really slow if the first partition isn't near the start of the disk
<cjwatson> plymouth> looks like missing libGL symlink, am poking
<slangasek> \o/
#ubuntu-release 2011-03-26
<slangasek> cjwatson: dmraid> doesn't the to_cpu() function need updated to also handle conversion of the total_secs_h field?
<cjwatson> slangasek: no, because it's only one byte
<slangasek> oh
<slangasek> so it is :)
<slangasek> parted,dmraid accepted
<ScottK> Very scary.
<ScottK> I ust accepted zope.html, which was right next to dmraid on the list and then say dmraid building.
<ScottK> ust/just
<ScottK> say/saw
<ScottK> Urgh.
<cjwatson> timing's fun
<slangasek> :-)
<cjwatson> urgh, maybe I should have test-built dmraid :-/
 * cjwatson fixes
<cjwatson> score
<cjwatson> slangasek: sanity-check on http://paste.ubuntu.com/585685/ ?
<cjwatson> slangasek: it does mean that libraries installed to multiarch directories in the initramfs will also be collapsed to /lib or /usr/lib; but I can't think of a neater way to do it
<slangasek> cjwatson: multiarch directories shouldn't need ld.so.conf to work, actually?
<cjwatson> no, but I have /etc/ld.so.conf/i686-linux-gnu.conf here
<slangasek> the ld.so.conf snippets are for the benefit of ldconfig (so everything gets into the cache, not just the stuff for the native arch), and for other tools that are naughty and parse ld.so.conf themselves
<cjwatson> I'm hoping to avoid special-casing libGL here
<cjwatson> which lands in /usr/lib/mesa/libGL.so.1, which *does* require ld.so.conf
<slangasek> ok, if this is for libGL's benefit, sure
<cjwatson> that's the actual problem
<slangasek> wasn't sure if we were still on the same topic :)
<cjwatson> oh, yeah, should have clarified since this was a few logical steps along
<slangasek> yeah, LGTM
<cjwatson> great
<cjwatson> I tried to get ldconfig working but I think it's a doomed endeavour
<slangasek> yeah, and it seems rather unnecessary in the context of an initramfs
<cjwatson> quite (though it might make it a bit faster, possibly)
<cjwatson> fractionally
<slangasek> jdstrand: to keep you in the loop given this morning's meeting discussion, I currently have a list of 14 library packages in main that need to be fixed up due to broken .la references to .la files moved by multiarch; I expect to have these all fixed over the weekend
<slangasek> (they could all be "fixed" with a no-change rebuild, but I'm fixing them harder)
<slangasek> that's the last set of breakages (in main) that I'm aware of from multiarch
<slangasek> (I haven't pulled a list of affected packages for universe yet, I'll do that afterwards)
<slangasek> doko_: do you want binutils fixed before doing the archive rebuild? I don't think binutils' view of the linker path should affect main, but ICBW
<doko_> slangasek: I would like to
<slangasek> ok
<doko_> trying to get something tomorrow or Sunday
<ScottK> I've accepted everything in the queue I was comfortable with accepting.
<ScottK> Either I need more uploads or it's someone else's turn.
<doko__> please accept bzr (component mismatch, no functional change, just running the tests sequentially)
<cjwatson> I was going to look at bzr, but my mirror job is hammering my bandwidth and I can't tell whether that's why queuediff is refusing to show me a diff yet or not; in any case I ought to sleep
<cjwatson> if it's still there tomorrow I'll look at it
<doko__> ubuntu-release, please have a look at bug #730759, that would be the last component mismatch
<ubot4`> Launchpad bug 730759 in dbus-c++ (Ubuntu Natty) (and 1 other project) "[MIR] b-d for libffado (affects: 1) (heat: 18)" [High,New] https://launchpad.net/bugs/730759
<slangasek> I'm still uploading libs, I'll have a look at the queue once I'm done there :)
<ScottK> If only LP made diffs faster ...
<ScottK> slangasek: Can you upload libmusicbrainz to Debian?  It's QA maintained, so if you upload the change we can just sync later and there's no diff to maintain.
<slangasek> ScottK: yes, I've uploaded there as well, but given the number of libs I'm having to upload I didn't want to wait for it to publish to Debian before getting it into Ubuntu
<slangasek> (especially since the Debian publisher is on manual this week for the ftp-master sprint)
<ScottK> Agreed.  Thus the later in my comment.
<slangasek> ok
<slangasek> yes, I'm forwarding all of these directly to Debian, either bug report or QA upload
<cjwatson> for general reference, I'm not going to accept syncpackage uploads for beta-1
<cjwatson> if people want to have syncs performed, they can do it the standard way; syncpackage doesn't even let me see who asked for the sync at the Ubuntu end
<cjwatson> (aview, bbrun)
<cjwatson> (papaya)
<cjwatson> rejected the syncpackage uploads
<cjwatson> and I've written an explanatory mail to -devel
<bdrung> ^ this is the 'figure out what went wrong' upload
<cjwatson> accepted
<ScottK> cjwatson: +1 on the -1 for syncpackage during freeze.
<iulian> Indeed.  I'm quite impressed how many people still use syncpackage.
<ScottK> Syncs get processed a lot faster these days, so I think people are making present virtue out of past necessity.
<iulian> cjwatson: Apparently you've just filled two separate bugs for the same package.  squashfs-tools 1:4.2-1.  Would you like me to fix that for you?
<iulian> ScottK: Yea...
<iulian> cjwatson: 1:4.2-1 looks good to me but I wouldn't mind if someone else takes another quick look at it, just to be sure that I haven't missed something important.
<iulian> ScottK: I agree with you here but the thing is that they know that syncs get processed faster these days and honestly this bothers me a bit.
<ScottK> I think some of it's habit, some of it is it's cooler/more fun to upload than to file a bug.
<ScottK> If we get syncs in LP, then I think that will go away.
<ScottK> iulian: If there's stuff in the queue you're ready to accept, just ping me and I'll be glad to push the button for you.
<ScottK> (although speak fast for the moment as I'll be offline for awhile in ~10 muntes.
<ScottK> )
<iulian> ScottK: Hopefully it will go away, yes.
<iulian> I've got nothing now for you.  Maybe later on.  Thanks, appreciate it.
<ScottK> OK.
<gilbert_> hi, could someone please take a look at bug #669211?  if that issue isn't fixed, you're going to release a completely broken xpdf package with natty.  btw i'm the debian xpdf maintainer.
<ubot4`> Launchpad bug 669211 in xpdf (Ubuntu) "Xpdf segfaults on start in libpoppler.so.7 (affects: 13) (dups: 3) (heat: 96)" [Medium,Confirmed] https://launchpad.net/bugs/669211
<cjwatson> iulian: hmm, requestsync raised an exception and it wasn't visible when I looked in the web interface so I filed it by hand
<cjwatson> iulian: if you could fix that'd be great, thanks
<iulian> cjwatson: Fixed.
<charlie-tca> zsync ed the images today, Ubuntu natty-alternate-i386.iso shows 679MB on the server, but synced to 705MB on my system
<charlie-tca> Do I need to do a full download to get the size down locally?
<ScottK> charlie-tca: #ubuntu-testing might be a better place for that question.
<charlie-tca> Okay, I was just hoping it is not an error at the server
<ScottK> ^^^ is my upload, so I won't be reviewing it ...
<cjwatson> iulian: ta
 * slangasek looks at kdegames
<slangasek> ScottK: no changes needed to debian/rules to compensate for the opengl build-dep going away?
<slangasek> (e.g., have you tested that removing libqt4-opengl-dev and building with -d works on x86?)
<ScottK> slangasek: No.  It's all automagically detected in CMake.  I tested on armel.
<slangasek> ok
<slangasek> accepted
<ScottK> Thanks.
<ScottK> slangasek: Avogadro is going to take some surgery to fix on armel.  Not sure if you've got someone who can look into it or not, but the chances of kubuntu-dev fixing it are ~nil.
<ScottK> (unless I completely misunderstood the situation with it, which is also a possibliity)
<slangasek> ack, assigning someone to it now
<ScottK> Thanks.
<ScottK> armel builders appear to be dieing like flies.
<slangasek> :/
<ScottK> Fortunately the backlog is small, so I think we'll be OK until lamont can wave his magic wand at them.
<ScottK> Oh, fun from your libisofs upload yesterday: libisofs/make_isohybrid_mbr.c:446:1: internal compiler error: in get_arm_condition_code, at config/arm/arm.c:17274
<slangasek> yes, bug #742961
<ubot4`> Launchpad bug 742961 in libisofs (Ubuntu) (and 2 other projects) "libisofs ftbfs on armel with current gcc-4.5 (affects: 1) (heat: 6)" [High,Fix released] https://launchpad.net/bugs/742961
<fabrice_sp> please reject my upload of vlc: it is useless
<ScottK> OK
<ScottK> fabrice_sp: Done.
<fabrice_sp> ScottK, thanks
<lamont> ScottK: yeah - I'm about to smack 'em
<lamont> adoxaceae|UNK|False|True|False|Non-virtual builder in ABORTED state, requires admin to restart
 * lamont sighs
 * lamont restarts launchpad-buildd on 5 otherwise-idle builders
<lamont> ScottK: so the real question that I'm ignoring for the weekend:  which build is it that's hitting them hard enough to make buildd-master go ZOMG I GIVE UP and mark them dead?
<lamont> interestingly, all 5 have been up for 4 days, 1 hour 22 minutes.
<ScottK> Like since the last time this happened...
<lamont> nah, that's when I rebooted them all for new kernels
<ScottK> Oh.
<lamont> this is what happens when a build has a in-memory footprint of 2+GB and a total of 512MB of RAM in which to work
<ScottK> My arm box has a SDcard just for swap.
<lamont> and yeah, when I glanced at the machines this morning, there was a fairly short queue, so I didn't bother before running off with kids for many hours
<ScottK> It's slower, but it doesn't die.
<lamont> 30GB of the USB drive is swap, the rest of it is /
<ScottK> Ah.
<lamont> that was from the "tired now" school of swap design
<ScottK> Heh.
<slangasek> and never mind that a process can't address more than 2GB of userspace memory on those kernels. :)
<lamont> slangasek: that 2GB+ footprint is generally somewhere between 50 and (yes) 200 processes
<slangasek> heh
<lamont> because, I mean, what's wrong with make -j, or make -j $undefined_variable ?
<lamont> though to be fair, the normal culprit seems to be java stress tests
<ScottK> Sounds like a reasonable candidate for a mbf in Debian if there's a reasonable way to detect such cases.
#ubuntu-release 2011-03-27
<ScottK>  ^^^ is my upload so I can't review it.  I did test build it on armel and confirm the changes are adequate to address the lack of GL.
<doko_> slangasek: uploaded binutils
<slangasek> doko_: thanks, looking
<slangasek> btw, if we're waiting for binutils before doing the archive snapshot rebuild, it would be good to also get liblouis in as this package ships its .so in the wrong multiarch directory on i386
<slangasek> ScottK: ^^ if you could look at liblouis, I'd appreciate it
<slangasek> looking at kipi-plugins now
<ScottK> cjwatson: Would you please turn off queuebot until the lang pack flood passes.
<ScottK> slangasek: Looking.  Why Pre-Depends: ${misc:Pre-Depends}?
 * ScottK didn't see that before.
<slangasek> ScottK: debhelper 8.1.2ubuntu2 and above turn this into Pre-Depends: multiarch-support, which is the transitional package that ensures (on i386, specifically) that you don't install libs to /usr/lib/i386-linux-gnu before there's an ld.so unpacked that knows this path
<ScottK> OK.
<ScottK> slangasek: Also, in debian/rules is  ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) still the correct test or should it be DEB_HOST_MULTIARCH?
<slangasek> that's still correct - it's the test for whether we're cross-compiling
<ScottK> OK.
<ScottK> Accepting.
<slangasek> ta :)
<doko_> binutils failed to build, will have to change the soname, or update to the branch again, adding some powerpc fixes too
<slangasek> what's the build failure?  looks like a -j build, I'm not sure what the actual failure is
<doko_> as: error while loading shared libraries: /build/buildd/binutils-2.21.0.20110322/builddir-single/./opcodes/.libs/libopcodes-2.21.0-system.20110322.so: invalid ELF header
<doko_> make[5]: *** [defstd.o] Error 1
<slangasek> hmm, so what causes that?
<slangasek> kipi-plugins accepted
<ScottK> Thanks
<ScottK> slangasek: FYI, fixing the GL/GLES issue for kdeedu and kdeplasma-addons both block on the avogadro fix done.  They should be ~trivial afterwards.  I have a koffice test build in progress now, so if that works out we should be ~there as soon as your person has an avogadro fix in hand.
<iulian> ScottK: dnspython in Debian seems a bit out-of-date.  Any ideas why?
<ScottK> iulian: Maintainer only pays attention intermittently.
<iulian> Oh.  It's not team-maintained.  This might be one of the reasons.
<ScottK> Yes.
<ScottK> Eventually he'll notice and update.
<iulian> Indeed.  Please go ahead and upload.
<ScottK> Will do.
<ScottK> Done.
<iulian> OK, ta.
 * iulian goes to bed now.
<iulian> Have a good night.
#ubuntu-release 2012-03-19
<cjwatson> ScottK: sync from incoming the old-fashioned way> FWIW I removed the LP code for that
<cjwatson> I mean for old-fashioned syncs in general
<jamespage> morning all
<jamespage> Riddell, I just finished uploading the zentyal packages associated with bug 928501 to NEW for precise
<ubot2`> Launchpad bug 928501 in ebox "[FFe] Upload new Zentyal packages (was Precise will ship totally broken ebox packages)" [High,In progress] https://launchpad.net/bugs/928501
<jamespage> adding transitional package took a bit longer than expected
<jamespage> if you would so kind as to review much appreciated
<Riddell> jamespage: thanks, added to my today's todo list
<jamespage> Riddell, ta - any chance you could review owasp-java-html-sanitizer as well?  I need it to close out a security vulnerability in Jenkins
<Riddell> jamespage: will do
<jamespage> Riddell, marvellous - thankyou!
<ScottK> cjwatson: OK.  I won't suggest that again.  Thanks for letting me know.
<cjwatson> syncpackage --no-lp or whatever is still usable in emergencies
<knome> anybody know why xubuntu i386 images aren't building since march 15?
<slangasek> join #ubuntu-installer
<slangasek> doh
<knome> :)=
<cjwatson> knome: I thought I fixed that yesterday evening
<cjwatson> did it fail again this morning
<cjwatson> ?
<cjwatson> hm, ok, still a problem
<cjwatson> knome: fixed
<cjwatson> knome: I've kicked off fresh builds for you
<knome> cjwatson, thanks :)
<skaet> pitti, https://bugs.launchpad.net/ubuntu/+bug/959032 - could you please review and comment on the impact of letting this onto beta 2 disk.  Want to make sure this doesn't cause disks to get oversized.   We pointed to it in the beta 1 release.
<ubot2`> Launchpad bug 959032 in ubuntu "[needs-packaging] Checkbox-app-testing" [Undecided,New]
<pitti> skaet: "It is not intended to be included on the final cd."
<pitti> skaet: so should not harm too much
<skaet> pitti,  worried about beta 2 getting oversize (and less usuable)
<pitti> skaet: asked
<pitti> skaet: right, did the same
<skaet> pitti, thanks.
<ScottK> Component mismatches kind of exploded.
<infinity> ScottK: We, err.  Ew.  Did someone promote something haskellish to main?
<ScottK> I suspect it was a new upload of something MaaS like.
<cjwatson> distro-info, I'm going to guess
<ScottK> Dunno.
<infinity> Looks like.
<infinity> (Looks like distro-info, that is)
<cjwatson> cobbler recommends: distro-info build-depends: haskell world
<debfx> could someone please have a look at the zsh FFe request: bug #762286
<ubot2`> Launchpad bug 762286 in zsh "FFe: Please merge zsh 4.3.17-1 from Debian" [Wishlist,Confirmed] https://launchpad.net/bugs/762286
<infinity> Why on earth is distro-info anything more complex than a simple shell script? :P
<cjwatson> and I think separately, maas stuff pulling in python-support *spit*
<cjwatson> http://people.canonical.com/~ubuntu-archive/component-mismatches.svg has the graph
<ScottK> cjwatson: Good thing all this stuff is landing early in the cycle so there's plenty of time to sort it out.
<ScottK> </sarcasm>
<infinity> *cough*
<ScottK> I think getting stuff in early is the most important for projects developed specifically for Ubuntu and it's exactly those (the ones outside the distro team) that seem to be the worst at aligning to the schedule.
<Riddell> it's because they align to the ubuntu 6 month cycle with ubuntu final release being the psychological target for their final release when they want to align to ubuntu cycle - 2 months
<ScottK> Agreed.
<infinity> ScottK: Thankfully, all the crap cobbler is trying to pull in is in Recommends.  It could just be that those should be suggests.
<ScottK> It's even been discussed.
<infinity> (I mean, really, debmirror?)
<ScottK> infinity: Good news.
<ScottK> They just never seem to do it.
<infinity> Daviey: Can you look into getting your minions to evaluate the cobbler Recommends line and drop all/most of that to Suggests?
<Daviey> infinity: it's in progress
<infinity> Daviey: Danke.
<Daviey> Really, does this require 4 people to discuss? :)
<Daviey> I'm on it :)
<infinity> Daviey: Almost none of that looks like it should be a Recommend to me.
<Daviey> distro-info will get rid of the haskel noise.
<infinity> Daviey: But it's also trying to promote debmirror, hardlink... I stopped reading after that.
<Daviey> infinity: good idea
<infinity> Daviey: Actually, just those.
<infinity> Daviey: So, either those need an MIR, or they need to be dropped to Suggests too.
<Daviey> infinity: you don't think i knew that?
<infinity> Daviey: :P
<infinity> Daviey: We get grumpy when our pretty archive checking tools explode.
<ScottK> And every cycle it's something.
<Laney> Do you have any easy way of discovering (to remove) all OOD haskell binaries?
<cjwatson> are they not NBS?
<Laney> no
<Laney> like some things might have started to depend on ghc-ghci which isn't available on !x86
<cjwatson> http://people.canonical.com/~ubuntu-archive/testing/precise_outdate_all.txt perhaps?
<cjwatson> ditto testing-ports
<Laney> yes
<Laney> shall I file a bug or can you do it from the list there?
<cjwatson> not just now, installer-sprinting
<Laney> in general
<cjwatson> probably best file a bug
<Laney> ok
<cjwatson> if it were a short list and I didn't have to exercise any editorial discretion then wouldn't need a bug
<cjwatson> but I'd be a bit scared about doing things wrong in this case
<Laney> libghc-* looks right from a quick glance
<Laney> i'll do it later, thanks
<infinity> Laney: Is there any active development to make ghci work elsewhere (like, say, armhf)?
<Laney> infinity: I would like to say so, but really I have no idea
<Laney> there is a "ghcarm" effort, but I don't know where they are putting their efforts
<Laney> I understand the dynamic linker is the main problem; check out rts/Linker.c
<Daviey> infinity / ScottK: The tool and depends you are mostly talking about, has had a MIR open for quite some time.
<ScottK> Yes and IIRC you gave it an FFe.
<Daviey> ScottK: no, that was for maas.. not cobbler
<ScottK> Ah.  Right.
 * ScottK can't keep track.
<Daviey> ScottK: thankfully, i am :)
<ScottK> MaaS appears to be Canonical's major entry in the "never planned to work with the release schedule" sweepstakes for this cycle.
<Daviey> ScottK: Are there prizes ?
<ScottK> So far mostly public ridicule, but who knows what the future will bring.
<Daviey> I'm missing the ridicule, must try harder.
<ScottK> We haven't declared a winner for this cycle yet.
<ScottK> There may be some last minute font crisis again.
<jamespage> Riddell, thanks for reviewing/accepting the zentyal packages
<Riddell> jamespage: thanks for your contribution to Ubuntu :)
<knome> ubuntu studio needs UIFe for #959504
<knome> stgraber, skaet: ^ that's for the slideshow
<knome> also, when zsyncing, how does a person know which image (s)he has?
<phillw> knome: if you do an ls it should report its full name.
<knome> including the date?
<sbeattie> 'isoinfo -x /.disk/info -J -i /path/to/iso' should give the build information encoded in the iso.
<knome> okay, thanks
<knome> btw... one of our testers reported that zsyncs from http://cdimage.ubuntu.com/xubuntu/daily/current/ gave him an iso from february
<knome> ^ explains the question before
<cjwatson> don't know why that would be, since it's current
<cjwatson> maybe a bogus web cache in the way or something
<knome> cjwatson, https://launchpad.net/debian-cd is still used?
<cjwatson> yes - specifically https://code.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu
<cjwatson> only tangentially for live CDs, though
<knome> hmm, so it means we have to update the logo there too... :)
<ScottK> slangasek: , cjwatson, whoever's around: Would you please promote python3-nose to Main.  Now that we're building python3 packages for numpy it's needed as a build-dep and it's from a source that's already in main.
<ScottK> barry: ^^^
<slangasek> looking
<slangasek> ScottK: done
<ScottK> slangasek: Thanks.
#ubuntu-release 2012-03-20
<cjwatson> skaet: do you know why bug 901741 refuses to vanish from http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-mgr-p-tracking-bugs.html?  I untagged it nearly a week ago.
<ubot2`> Launchpad bug 901741 in debsums "perl-modules lucid->precise upgrade failure: debsums is noisy when Perl-related packages are inconsistent" [Low,Triaged] https://launchpad.net/bugs/901741
 * skaet looking
<skaet> cjwatson,  that's weird.  yeah it shouldn't be there.
<skaet> I'll work with bjf on it tomorrow to see if we can figure out, what could be happening... weird.
<cjwatson> thanks
<ScottK> cjwatson: I screwed up and accepted libzip2 binaries into Universe.  Would you please promote them?
<ScottK> (or maybe slangasek)
<infinity> ScottK: I can.
<ScottK> infinity: Yes.  Please.
<infinity> ScottK: Err, which source package?
<ScottK> libzip
<infinity> Oh, SOVER bump.  Yeah.  On it.
<ScottK> Thanks.
<ScottK> I've got all the rdepends ready to upload.
<infinity> Sadly, we just missed the publisher while talking.
<infinity> But it'll resolve in the :33 run.  If there is a :33 run. :P
<infinity> ScottK: Committed.
<ScottK> Thanks.
<ScottK> All but one are in Universe, so it's not so bad.
<infinity> We have this source package in main for exactly one rdep?
<ScottK> Yes.
<infinity> That seems suboptimal.
<ScottK> Which is in main for one rdep.
 * ScottK just uploaded the lot.
<ScottK> I'll retry the main one after the promotion is done.
<infinity> Erm.
<ScottK> It ends up losing some data formats from okular if it's not there.
<infinity> Oh, just a confused tool.
<infinity> I saw the rbuild-dep, but no binary dep.
<infinity> But there it is.
<infinity> Just our checkrdeps tool confused because libzip1 is no longer related to libzip.
<infinity> ScottK: I might actually have to give Kubuntu a spin sometime.
<ScottK> Some people seem to like it.
<ScottK> Come on over.
<ScottK> The water is fine.
<infinity> ScottK: I was doing KDE installer testing/fixing today, probably the first time I've genuinely looked at KDE in almost a decade.  It's kinda shiny.
<ScottK> :-)
<infinity> How well does it do at theming GTK+ apps to not look like crap?
<ScottK> Pretty good.
<ScottK> Better with gtk2 than gtk3 at tihs point, but that's coming along.
<infinity> That's okay, I have no GTK3 theming at all on my Xubuntu desktop right now. :P
<infinity> (My own fault, because I'm using the old GTK2 Human theme, but yeah.  Ugly square grey buttons in evince, FTL)
<ScottK> Okular is one of the best KDE apps.  You won't need to worry about Evince.
<infinity> I really need to find a round tuit to port Human to GTK3 and sneak it into precise.
<infinity> ScottK: Oh, I assume I don't need to worry about GTK apps much in general, but there's always the one or two.
<ScottK> Yes.  You'll still want FF/Chromium and LO if you use an office suite.
<ScottK> Maybe Gimp.
<ScottK> Other than that, I use all KDE stuff.
<infinity> Well, Chromium never looks right on Ubuntu anyway.
<infinity> But we do put some solid effort into making Mozilla apps play nicely and fit in.
<ScottK> We had a very nice set of KDE patches for FF, but they've been dropped for LTS due to too much trouble with the new Mozilla rapid release process.
<ScottK> I've uploaded enough stuff to guarantee a :33 publisher run.
<infinity> ScottK: It's not about enough stuff being uploaded, but if the :03 run takes more then 30 minutes.
<ScottK> Oh.
<ScottK> Well there's also the no uploads option.
<infinity> s/then/than/
<infinity> ScottK: Looks like a :33 run is happening.
<ScottK> Great.
<ScottK> When do they normally finish?
<infinity> Anywhere between 15 and 30 minutes.
<ScottK> In the good old days, I remember it was start at :03 and finish :44 - :47.
<ScottK> Thanks.
<ScottK> I need to do a better job of getting you engrained in the list of archive admins that live to the west of me.
<infinity> I'm probably more accurate described as the archive admin that doesn't sleep.
<ScottK> That too.
<ScottK> Then there's pitti, who is generally well east of me, but gets up early, so we often overlap before I go to bed.
<ScottK> So I'm looking at libzip2_0.10-1_i386.deb in http://archive.ubuntu.com/ubuntu/pool/main/libz/libzip/ and yet the package still fails because it's not there?
<ScottK> Is there a better place to tell which it's shown up and is available to build with?
<infinity> Packages.gz
<infinity> Pool location is largely irrelevant, and often a strange lie for packages with main/universe splits.
<micahg> there's rmadison output as well
<ScottK> OK.  Thanks.
<infinity> rmadison is just Packages.gz with a nice wrapper. :P
<infinity> (And a bit of lag)
<infinity> ScottK: I could just tell you when the publisher's done.
<infinity> ScottK: Since all you care about is ftpmaster, not archive (archive being a mirror and all)
<ScottK> That would work too.
<ScottK> Yes.
<ScottK> Right, but if archive is good, the ftpmaster should be as well.
<infinity> True.
<ajmitch> once that's published, that could fix a couple more haskell packages as well :)
<micahg> right, which is why I mentioned it to fabo in the first place ;)
<ajmitch> aha
<infinity> ScottK: Should be good to go now.
<ScottK> OK.
 * ScottK mashes retry
<ScottK> Thanks.  All mashed.
<Riddell> a video driver uploaded presumably for universe with "All Rights Reserved" in the copyright file, should I reject on the grounds that means we have no copying licence at all?
<Laney> ScottK: oh, you took the libzip SONAME bump â that means haskell-libzip is saved!
<Riddell> ubuntu-sru: bug 901959 is over 4 weeks old
<ubot2`> Launchpad bug 901959 in xserver-xorg-video-intel "Clipping in libreoffice welcome screen" [Undecided,Confirmed] https://launchpad.net/bugs/901959
<ScottK> Riddell: Does it have a free license otherwise?
<Riddell> ScottK: no
<Riddell> I assume it's for rejected but jani asked for it to be rejected while he worked on the copying file
<Riddell> s/rejected/restricted/  similar works :)
<ScottK> Agree, it should be rejected.
<ScottK> "All rights reserved" seems to get interpreted as "All other rights reserved" if there's a free license, but you've got to have that ...
<ScottK> Even for restricted it's got to be distributable.
<knome> cjwatson, you around?
<brendand> Daviey, i think beta1 has boned the network card on one of our servers :(
<brendand> but i need to check with the lab engineer to make sure it's not something more obvious (like unpluggies)
<Daviey> brendand: eeek
<Daviey> brendand: dmesg have anything of interest ?
<brendand> eth0: link is not ready
<brendand> ?
<brendand> and
<brendand> eth0: No IPv6 routers present
<brendand> Daviey, in ifconfig it is an inet6 addr only
<Daviey> brendand: nothing earlier in the dmesg?
<Daviey> brendand: I'm expecting missing firmware or something, in which case - it's a kernel bug.
<brendand> there is a missing firmware message, but i don't know for sure it's for the network card
<brendand> err, not missing firmware
<brendand> vpd r/w failed?
<brendand> let me see if i can get the log to you
<Daviey> brendand: See if you can pastebin the whole dmesg
<cjwatson> knome: yes, now
<knome> cjwatson, https://code.launchpad.net/~knome/debian-cd/xubuntu-logo-precise/+merge/98396
<cjwatson> right, saw that in mail, thanks
<knome> great :)
<brendand> Daviey - i can't get anything off the server right now (unless there's a feature of this Raritan KVM i don't know about)
<brendand> Daviey, no network access
<Daviey> brendand: no serial console?
<brendand> Daviey, not that i know of...
 * brendand checks
<brendand> Daviey, the IS page claims there's one but i can't access it
<brendand> Daviey, http://paste.ubuntu.com/892292/
<Daviey> brendand: thanks :)
<Daviey> brendand: yeah, looks like a kernel issue.. can i ask you to raise a bug and throw this on there.. I'll follow it up with the kernel folks.
<brendand> Daviey, oh cool. what gave it away?
<Daviey> brendand: tg3 0000:01:00.0: vpd r/w failed.  This is likely a firmware bug on this device.  Contact the card vendor for a firmware update. ... tg3 is a broadcom network adapter.
<Daviey> I find it hard to believe that the newer kernel requires a firmware update, which makes me think something in the kernel is doing something wrong.
<Daviey> If i knew what the something's were, i'd be happy :)
<slangasek> Riddell: "all rights reserved" is a standard statement that copyright exists and is orthogonal to the license; so seeing that doesn't necessarily mean it will be bound for restricted afterwards, though of course we need debian/copyright to reflect whatever license we actually have
<brendand> Daviey, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/960311
<ubot2`> Launchpad bug 960311 in linux "Networking on Dell PowerEdge R300 with Broadcom Corporation NetXtreme BCM5722 Gigabit Ethernet PCI Express is not functional" [Undecided,New]
<Daviey> brendand: thanks
<brendand> Daviey, i'd get all the logs i could but apport isn't installed and obviously i can't install it myself
<Daviey> brendand: groovy!
<knome> doko, i'm not sure if this could be related, but i heard another guy had problems with wireless in the daily builds too, but he confirmed it was only under vbox...
<knome> Daviey, ^ even
<Daviey> knome: wireless in vbox? :o
<greyback> Hi guys, a UIFe request: https://bugs.launchpad.net/unity-2d/+bug/960194
<ubot2`> Launchpad bug 960194 in unity-2d "[UIFe] Use average color of wallpaper to tint launcher/dash/panel/hud" [Low,Confirmed]
<skaet> cjwatson,  901741 no longer showing up in the list.   Seems we have a problem in the code that tracks bugs rather than querying to launchpad.  Full regeneration of the table, pulling the information directly from launchpad sorted it.
<cjwatson> skaet: neat, thanks - might this recur for other bugs then?
<skaet> cjwatson,  unfortunately yes,  we probably need bdmurray to look at the code a bit.   If you spot another one,  flag it to him as well.
<brendand> Daviey, looks like bug 960311 is happening with Oneiric too
<ubot2`> Launchpad bug 960311 in linux "Networking on Dell PowerEdge R300 with Broadcom Corporation NetXtreme BCM5722 Gigabit Ethernet PCI Express is not functional" [High,Incomplete] https://launchpad.net/bugs/960311
<brendand> Daviey, i reckon the firmware got updated on that system recently (i wasn't aware it was though)
<brendand> Daviey, so if this is a bug it could have been around for a while
<brendand> Daviey, i added a comment. got to go now but i'll make sure to test with the daily image tomorrow and try and get someone to install the upstream kernel for me
<cyphermox> hey, I know it's getting quite late for this, but if someone could review https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/960494 ; there's two changes in NM especially which make me uncertain to upload NM 0.9.4.0 as just bugfix
<ubot2`> Launchpad bug 960494 in network-manager "[FFe] update to NetworkManager 0.9.4.0" [Undecided,New]
<cyphermox> Also, in that bug I'm mentioning "will be released by March 23", because it's supposed to be released today or tomorrow, and definitely before the end of the week as the upstream lead developer will be on vacation after that
<infinity> cyphermox: Commented.
<cyphermox> infinity: thanks; yeah, I'm making sure of that right now
<cyphermox> I suspect there might still be some additional changes but they are supposed to be just bugfix; upstream is aware of our schedules and also commented on the "it's too late for features now"
<cyphermox> the ipv6 things they just landed just work on what's already applied; partly because the person who wanted these changes are submitted the patch keeps bugging me and dcbw to land them in Ubuntu :)
<ScottK> psycopg2 and pymilter both have binary renames and are in New for i386 only (FFe approved).  Since there's archive skew until they are out, I'd appreciate it if someone would have a look.
<knome> cjwatson, can we expect the new logo appear on debian-cd now?
<cjwatson> knome: yes, any builds after I set that bug to Fix Released will have it
<knome> cjwatson, which bug? :) #955396 is pending on other stuff too
<cjwatson> er I mean since the merge proposal went to Merged
<knome> hehe, okay, thanks :)
<knome> as i thought, just wanted to make sure that's it
<infinity> ScottK: Done.
<ScottK> infinity: thanks
<infinity> zul: "* New upstream release" is nowhere near enough of a changelog for a package that introduces new binary packages.
<ScottK> Let me guess.  No FFe?
#ubuntu-release 2012-03-21
<infinity> ScottK: None mentioned.
<rsalveti> infinity: skaet: bug 960893
<ubot2`> Launchpad bug 960893 in clutter-1.0 "Clutter is unable to find a valid input backend and abort the execution on ARM" [High,Confirmed] https://launchpad.net/bugs/960893
<rsalveti> this is the bug that's currently causing clutter-gst to fail
<rsalveti> then empathy will break as well, blocking the arm images
<rsalveti> I'm currently debugging it, but my local build will take a few minutes still to finish
<rsalveti> so will probably continue it tomorrow
<rsalveti> basically clutter is completely broken on arm atm
<Daviey> infinity: Are the opportunity targets for arm server still valid?
<greyback> skaet: hi you got a second, can you look at https://bugs.launchpad.net/unity-2d/+bug/960194 please?
<ubot2`> Launchpad bug 960194 in unity-2d "[UIFe] Use average color of wallpaper to tint launcher/dash/panel/hud" [Low,Confirmed]
<brendand> Daviey, so this bug 960311 is a bit funny
<ubot2`> Launchpad bug 960311 in linux "Networking on Dell PowerEdge R300 with Broadcom Corporation NetXtreme BCM5722 Gigabit Ethernet PCI Express is not functional" [High,Incomplete] https://launchpad.net/bugs/960311
<Daviey> brendand: oh?
<brendand> Daviey, that error pops up kind of non-deterministically
<brendand> Daviey, at the moment it seems to effect every release
<Daviey> brendand: can i sugegst taking this to #ubuntu-kernel .. smb is looking into it.
<Riddell> Daviey: where do you discuss arm issues?  there seems to be no mailing list for them
<Daviey> Riddell: #ubuntu-arm ?
<Riddell> Daviey: oh well.
<Riddell> hey lool, are you the guy who knows about the arm images?  where do I ask about them not working?
<knome> hey Riddell
<Riddell> hello knome
<knome> Riddell, in bug 959504, we asked a permission to tweak the ubuntu studio ubiquity slideshow to fit netbooks (reduce height). can we do the same for xubuntu, as long as we promise to take care of any possible doc screenshots too, which was the condition for US too? do you want me to file another bug just for this (our content is totally the same, we're just modifying the height, and making some things fit a little better)?
<ubot2`> Launchpad bug 959504 in ubiquity-slideshow-ubuntu "[UIFe] ubuntu studio slideshow requires update" [Undecided,Triaged] https://launchpad.net/bugs/959504
<Riddell> knome: are there screenshots elsewhere like on websites?
<knome> at least not on ours
<Riddell> knome: file a bug then and I'll approve it
<knome> okay, thanks
<apw> there is a kernel update (linux) sitting in the queue, this contains the fix for older powerpc UP machines
<Riddell> apw: multipath-modules-3.2.0-19-generic-di ?
<apw> Riddell, ahh is that why its pending, a new udeb
<Riddell> apw: got a FFe for that?
<apw> Riddell, ignore me, i thought it was caught in the beta freeze, but thats 2 days out isn't it
<apw> i'll go find out :)
<Riddell> aye not until tomorrow euro evening
<knome> Riddell, bug 961041
<ubot2`> Launchpad bug 961041 in ubiquity-slideshow-ubuntu "Xubuntu slideshow doesn't fit netbook screens" [Undecided,New] https://launchpad.net/bugs/961041
<apw> Riddell, ok it seems although its a new udeb, its actually existing functionality those modules were built-in before and we should always have had the names udeb, anyhow, as we are not in freeze there is no rush and i'll get with the normal process
<lool> Riddell: Hmm I worked on ARM images many months ago; I'm not sure who is in charge for them today, the usual suspects I would hint at would be infinity, ogra_, janimo, NCommander
<lool> Riddell: but it depends on the image; e.g. AC100 might be handled by different people than imx or omap if we still have these
<apw> Riddell, whats the symptom on the arm issue?
<Daviey> AC100 does have a mailing list btw.
<Daviey> Riddell: why is #ubuntu-arm not a suitable place to ask?
<Riddell> knome: accepted!
<knome> Riddell, thanks :)
<Riddell> apw: my pandaboard doesn't boot (and I've had this conversation plenty on irc and wish to move it to a mailing list)
<Riddell> Daviey: because of the usual communication differences between irc and mailing lists
<apw> Riddell, kernel issue ?
<Riddell> apw: probably
<apw> odd i am sure someone is meant to be boot testing those regularly
<Daviey> Riddell: with the ARM team essentially being divided into the different engineering teams.. i'm not sure a generic list makes sense.. We don't have an amd64 mailing list either :)
<Riddell> apw: yes they are, and I have also had this conversation lots, and so I would like to move it to a mailing list where it can be explained properly
<Riddell> Daviey: where should I go then?
<Riddell> there is a need for a place people can discuss arm issues
<apw> Riddell, fine and you are welcome to go do that, i am not interested per-see the specifici issue, i am interested in there being one and our testing not bringing it to our attention
<apw> the meta issue is more worrying
<Daviey> Riddell: my first port of call would be ogra_, now on foundations
<Riddell> apw: blame Grue then for not having enough pandaboards :)
<Riddell> Daviey: yes, I have already had this conversation with him.  next?
<Daviey> apw: pgraner is working hard on creating a panda lab for automated testing of arm dailies btw.
<Daviey> Riddell: what was the outcome?
<Riddell> Daviey: he didn't know the problem
<apw> Daviey, yeah i heard rumors, though i am pretty sure we also test on panda before upload, so if its a kernel issue i am wondering how thats occured
<Daviey> Riddell: what is the bug number?
<Riddell> Daviey: I haven't got a bug number because I haven't tracked down a bug
<Daviey> Riddell: "does not boot" is probably a bug.. having a centralised bug to push data, is probably more useful than irc conversations or a mail.
<Daviey> :)
<Daviey> Riddell: even if you raise it against the Ubuntu project, rather than a package.
<Riddell> Daviey: a bug without a package will never get much attention
<Daviey> Riddell: right, but it would stop you having to repeat the symptoms.. and the patterns you have followed.  A mail referencing a bug, might then be useful.
<Riddell> Daviey: where would the mail go?
<Daviey> Riddell: where would you send a mail if you saw the same issue with amd64?
<Daviey> Riddell: ubuntu-devel, i'd say.
<Riddell> mm
<Riddell> Daviey: so if that doesn't work will you give in and accept the need for an ubuntu-arm mailing list?  (like you already have an ubuntu-server-arm but that is too specific to be useful to anyone)
<Daviey> Riddell: setting up ubuntu-server-arm was a mistake IMO.
<Riddell> mv ubuntu-server-arm ubuntu-arm  voila, useful list
<Daviey> Riddell: I'm not against the idea, but equally - special casing one architecture seems odd to me.
<Riddell> arm is an odd architecture
<Daviey> Riddell: and, as i am discovering.. so is i386 with SMP :)
<Daviey> Riddell: All i have learned so far about this is, 'does not boot' .. is there serial console output?
<Riddell> Daviey: yes http://starsky.19inch.net/~jr/tmp/precice-arm-boot.txt
<Riddell> as already reviewed by grue and ogra who say "oh weird, it's trying to use ext3"
<Daviey> Riddell: can you try a different SD card please?
<Riddell> Daviey: done
<Riddell> I've already had this conversation
<Riddell> it works fine on the validatoin image, it works fine for oneiric, it works fine enough for ubuntu server precise
<Daviey> Riddell: can you see why having this coversation on a bug would be helpful? :)
<Riddell> ...or a mailing list
<Riddell> since I have nothing to file the bug under
<Daviey> Riddell: $ grep -i CONFIG_EXT4  /boot/config-VERSION | pastebinit ?
<Daviey> Riddell: linux (Ubuntu) :)
<Riddell> Daviey: I don't currently have it setup with the broken desktop image
<Daviey> Riddell: *please* raise a bug with the steps you have done so far, and what you know.. I'll reproduce myself.
<Riddell> Daviey: nobody has been able to recreate it so far so I suspect you won't be able to
<Daviey> Riddell: okay, i won't try then.. Problem solved.
<Riddell> oh do try, I just am skepitcal it'll work alas
<Riddell> Daviey: but you've booted an ubuntu desktop precise image ?
<Daviey> Riddell: no, only server.. but i'm willing to go that extra mile for you.. if you raise a bug with steps to reproduce :)
<Riddell> Daviey: ok, will do
<apw> i'd say if its not booting that filing it against the kernel is appropriate in the first instance, if its bootloader or something else we can punt it
<Riddell> thanks
<apw> Riddell, and paolo says he booted uses precise on his panda every day, he is downloading todays image to test that
<Riddell> I know it works for other people, I need it tested with  rev 1A pandaboard
<apw> Riddell, thats definatly 1A not A1 ?
<Riddell> apw: probably A1
<Riddell> yes A1
<apw> Riddell, ok so paolo has the exact same board rev then good
<Daviey> Riddell: ah, mine is A2
<apw> Riddell, ok paolo tested his A1 with this image: http://cdimage.ubuntu.com/daily-preinstalled/current/precise-preinstalled-desktop-armhf+omap4.img.gz and it booted and he was able to install it
<apw> Riddell, did we get a linux bug filed yet?  i'll add it there too if so
<Riddell> apw: not yet I'm afraid
<cjwatson> Riddell: multipath-modules> that's not FFe-worthy - it's a bug-fix (regression, module that used to be available in the installer now being missing).  I've accepted it.
<Riddell> thanks cjwatson
<ogra_> Riddell, arm discussions should happen where powerpc discussions happen ;)
<ogra_> Riddell, hint ... ubuntu-devel ML :)
<ogra_> Riddell, whats your issue exactly ?
<Riddell> ogra_: the same one I've been talking to you and grue about
<Riddell> bug 961133
<ubot2`> Launchpad bug 961133 in linux "Ubuntu Desktop ARM Images do not boot on my Pandaboard" [Undecided,Incomplete] https://launchpad.net/bugs/961133
<ogra_> and there is still no explanation i can give you, the images work on all my pandas with different SDs
<Riddell> yes
<ogra_> i seriously dont know what you boot there, but it cant be an ubuntu image if rootfstype= is set
<ogra_> there was never any ubuntu image where this option showed up
<Riddell> it is the ubuntu desktop image for precise
<Riddell> I change the boot file to remove "quiet splash"
<ogra_> cant be, unless you hacked it ... you shouldnt get all that kernel messages on serial at all
<ogra_> ah
<ogra_> k, that explains the serial output
<ogra_> but you seem to have changed a lot more
<ogra_> "vram=16M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait"
<ogra_> that cant boot
<Riddell> clearly, that's my whole problem :)
<Riddell> I move the boot.scr file to Env.txt and remove the first line of non-human readable  characters
<ogra_> well, try a fresh image, dont modify it
<Riddell> I have
<ogra_> you also removed the ability to use an initrd
<ogra_> (it doesnt load one at all)
<Riddell> I am not aware of doing that
<Riddell> how did I do that?
<ogra_> well, your serial output says so
<ogra_> by putting some weird boot.scr/preEnv.txt in place
<Riddell> that's not the same thing as me doing it conciously
<ogra_> https://launchpadlibrarian.net/97732667/precice-arm-boot.txt cleasrly shows that
<Riddell> I have been doing what grue has told me to,  mv boot.scr Env.txt
<ogra_> it should only load boot.scr ... and then uIamge and uInitrd in that order
<ogra_> ugh
<ogra_> that cant work
<ogra_> boot.scr has a binary header
<Riddell> yes, which was I told to remove
<ogra_> well, you have a preEnv.txt there
<ogra_> seriously, zero out the card and write it with a freshly pulled image
<Riddell> seriously, I have
<Riddell> ogra_: how about this log? http://starsky.19inch.net/~jr/tmp/arm/ubuntu-precisebeta1-armhf-noquiet
<ogra_> same thing
<ogra_> see the kernel cmdline
<Riddell> well that's just the same, mv boot.scr Env.txt and remove "quiet splash"
<ogra_> (also the uBoot messages are very important, please include them in such logs)
<ogra_> right, dont do that ;)
<ogra_> give me the serial output of a freshly downloaded and dd'ed image, lets see if it loads initrd
<ogra_> and to be 100% sure, make sure to zero out the card before dd'ing
<Riddell> ogra_: ok I'll do that, the machine is currently in use so we'll need to wait for that to finish
<Riddell> ogra_: what's the command for that?
<ogra_> well, i'm at the foundationd installer vsprint atm, so i'll work until 22:00 UTC
<ogra_> sudo dd if=/dev/zero of=/path/to/your/SD/device bs=1M count=<make a pick how many megs you want to wipe>
<ogra_> i would suggest something like 10-20M for the count= value
<ogra_> that should definutely wipe the boot partiton
<Riddell> thanks
<ogra_> the device needs to actually be the device, not a partition
<ogra_> i.e. if you use a USB reader something like /dev/sdb ... not sdb1 ...  or with a native SD reader mmcblk0, not mmcblk0p1 or p2 or whatever
<ogra_> same thing as if you write the SD
<Riddell> yes
<skaet> pitti,  given ubuntu-docs is asking for a week extension to the freeze to get the unity documentation into shape, we're going to be putting pressure on the translators.     If we give an exception to the NonLanguagePackTranlationDeadline of a week for just the ubuntu-docs' portion (make it the same as the LanguagePackTranslationDeadline),  will that still give us enough time to prep for the CandidateWindowStarts?
<skaet> https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule
<pitti> skaet: sounds ok to me
<pitti> the images that we build on that Thursday won't be final anyway
<pitti> we'll need to build new fresh langpacks, and will almost certainly have bug fixes which we want to pull int
<skaet> pitti,  actually we are trying very hard for those images to potentially be shippable.
<pitti> ...o the release
<pitti> skaet: well, we can't put the langpack translation deadline and "final image" on the same day
<skaet> pitti,  its on Tuesday
<skaet> :)
<pitti> ah
<pitti> well, then the ubuntu-docs deadline should be on that day, too
<pitti> but still, why cut the bug fix window by a whole week?
<seb128> skaet, pitti: just checking but will monday 16th still be ok for GNOME updates?
<seb128> it's 3.4.1 tarballs day
<pitti> we certainly want potentially releasable images on that day, but that's not the same as "don't allow any bug fixes any more"
<Riddell> who's the release driver for beta 2?
<pitti> ttps://wiki.ubuntu.com/PrecisePangolin/ReleaseTaskSignup
<pitti> -> cjwatson and me
<skaet> seb128, its after FInalFreeze (12th).
<greyback> Hi can someone look again at: https://bugs.launchpad.net/unity-2d/+bug/960194
<ubot2`> Launchpad bug 960194 in unity-2d "[UIFe] Use average color of wallpaper to tint launcher/dash/panel/hud" [Low,Confirmed]
<seb128> skaet, right, that's why I'm asking
<seb128> skaet, pitti: that's something we pointed at UDS, we need to get .1 in or we will create a lot of extra work for us or lower quality by missing a month of bug fixes
<pitti> I think we need to review the uplaods and check the diffs (we'll do anyway, as we'll be frozen)
<pitti> many updates are just translation updates, which are fine; and for the real bug fixes, looking at a particular one makes it a lot easier to say yay or nay than a blanket exception
<pitti> as usual, final freeze again just means that uploads are reviewed by the release team
<seb128> pitti, I'm just trying to make sure it's still ok, because if it's not we need a plan B, i.e snapshoting or backporting fixes earlier
<pitti> Monday should just about make it for the langpack deadline, so we'll catch the updated translations as well
<skaet> seb128,  pitti,   its the bug fixes and regression potential I'm worried about here.   Is there any way we can the fixes in before the final freeze?
<pitti> skaet: yes, with essentially doubling the work
<seb128> skaet, we can, but it might end of having to backport patches over 15 tarballs and spending days of work doing that
<pitti> skaet: and working on weekends
<skaet> let them shake out, and then just sync to pick up the translations.
<pitti> skaet: we can still reject patches which might cause regressions, after all
<skaet> pitti,  but might we end up rejecting the entire tar ball if the same problems are noticed on the 16th?
<pitti> yes, in unapproved it's just "take the whole thing" or "reject"
<pitti> but as I expect that most changes should be fine, it's still a net win
<pitti> and usually the uploader reviews the changes in advance anyway
<seb128> knowing that GNOME is hard frozen
<seb128> ups, ignore that
<seb128> they will not between .0 and .1
<seb128> but it's on bug fix only mode, usually it's a net win as pitti says
<pitti> we really need to get back to the pre-maverick rhythm
<pitti> moving the release cycle back three weeks in maverick really hurt our alignment with gnome
<seb128> right, we had the same discussion last cycle
<skaet> pitti, I think we're getting closer now, but yeah, this sort of glitch is hurting.
<greyback> infinity: sorry to bother you, but freeze on it's way, can you take look at: https://bugs.launchpad.net/unity-2d/+bug/960194
<ubot2`> Launchpad bug 960194 in unity-2d "[UIFe] Use average color of wallpaper to tint launcher/dash/panel/hud" [Low,Confirmed]
<skaet> jbicha, ^ what is the impact of this change from greyback - have those screenshots been done already?
<jbicha_> skaet: greyback: we use Unity 3D for screenshots, any changes to Unity 2D that make it more like 3D are awesome
<greyback> jbicha_: that's good to know. We've other small visual tweaks to make to close the gap, so I'm happy that isn't causing you any difficulties
<jbicha_> greyback: no, I don't believe that'll be a problem
<skaet> greyback,  based on jbicha_'s response,  consider the change approved (and based on the comments in the bug),  I'll go add a note there now.
<greyback> jbicha_: ok thank you. I'll contact you if I'm concerned we're pushing it :)
<greyback> skaet: thank you
<jbicha_> this is basically all the mention we have of 2D: https://help.ubuntu.com/11.10/ubuntu-help/fallback-mode.html
<greyback> jbicha_: awww :(
<jbicha_> greyback: if you have extra text you want to add, just send it to us; we still have another day or so before Docs Freeze :)
<greyback> jbicha_: nah I'm good. That does summarize all Unity2D does.
<jbicha_> I'm especially interested in a simple answer to the question "how can I tell whether I'm running 2D or 3D?"
<greyback> jbicha_: probably best answer is to look for a shadow under the panel. Other visual differences are much harder to spot. The Alt tab not being fancy is another big indicator
<greyback> skaet: thanking you
<greyback> oh I already said that. duuuh
<skaet> greyback,  np.  :)
<jbicha_> skaet: good afternoon, I've got a proposal for the Docs Freeze :)
<skaet> jbicha_, yup,  see the backscroll for discussion of how we can accomodate or not.  ;)
<skaet> lol
<jbicha_> oh, I missed the backscroll, busy day
<skaet> jbicha_, :)  anyhow,  I'll respond to your email properly,  I think there's a plan that can work.
<skaet> we probably need to relook at these deadlines at UDS
<knome> AHOI release team! https://lists.ubuntu.com/archives/ubuntu-release/2012-March/000990.html
<knome> (yes, it's me again, and this won't be the last before beta freeze :|)
<cjwatson> it'd be helpful to attach a patch rather than the whole new file
<skaet> cjwatson,  you're right.   I should have asked for the diff,  file itself looked straightforward enough, but diff would indeed make it clearer what changed.
<knome> i can create a patch file, but i need to find out how to create one.
<skaet> https://wiki.ubuntu.com/FreezeExceptionProcess
<skaet> has the commands.  :)
<cjwatson> short version: 'diff -u old-file new-file'
<skaet> yup..:)
<knome> i added an actual patch file.
<knome> that's not a huge change... :)
<skaet> thanks knome.   its approved now.
<knome> thanks. i'll commit :)
<knome> err, i don't ;)
 * knome doesn't have rights
<knome> hahah, i'll forward :)
<kees> what specific time is the freeze tomorrow?
<skaet> kees, 2100 UTC
<kees> skaet: thanks!
<skaet> np
<ogasawara> skaet: we just received an updated seccomp patch set which kees is hoping to land in beta-2
<kees> skaet: I'm hoping to get a kernel feature in before the freeze, but it sounds like it might need a bit longer to build.
<kees> heh, what ogasawara said :)
<ogasawara> skaet: given the time of freeze tomorrow, if I uploaded a kernel now it might not make it before the deadline
<kees> ogasawara: by "make it" you mean build everything and get the meta package bumped?
<ogasawara> kees: yep
 * kees nods
<skaet> ogasawara, if its ready to go,  lets get it started, I assume its got goodness/bug fixes that are wanted for beta2.
<kees> skaet: so, I guess I'm asking for a pre-emptive freeze exception for a very long kernel build. :)
<kees> skaet: yeah, I've got some people very interested in trying this goodness (it's been long-awaited)
<ogasawara> skaet: I've got his patches, just want to kick off a few test builds/boots before uploading.  it does have goodness that the Chrome security team would like for Beta-2
<skaet> ogaswara, kees - make sure no regressions, and then go ahead.   flag when its uploaded, and we'll respin to catch it if it hasn't finished when the dailies kick off tomorrow.
<ogasawara> skaet: ack
 * kees hugs skaet and ogasawara
<skaet> zul,  have rejected quantum,  details in PM
<infinity> skaet: FWIW, ARM/Ubuntu/desktop will be unbuildable for beta-2 unless bug 960893 is fixed in time.
<ubot2`> Launchpad bug 960893 in clutter-gst "Clutter is unable to find a valid input backend and abort the execution on ARM" [High,Confirmed] https://launchpad.net/bugs/960893
<infinity> skaet: So, we can remove it from the preinstalled pipeline pending that bug closure.
<infinity> skaet: (kubuntu, ubuntu-server, core, etc will all still be fine)
<skaet> infinity, thanks for flagging,  probably worth reseting the tracker and adding it to there, so we have a record.
<infinity> Well, it's not an image bug, so much as a "we can't build images at all" bug.
<infinity> So, I'm not sure how trackable that is in the tracker.
<skaet> once the bug is fixed,  the image can be built (I'll just consider that as a rebuild trigger)
<skaet> :)
<skaet> pad.ubuntu.com has been reset for beta 2
<skaet> bug added.
<skaet> pitti, ^
<infinity> skaet: Check, I ammended you note.
<skaet> infinity,  yup, saw it flash infront of my eyes, real time.
<infinity> MAGIC TECHNOLOGY.
<skaet> lol, indeed
<rsalveti> infinity: I got the fix for it
<rsalveti> infinity: just checked and it worked
<rsalveti> infinity: preparing the debdiff now
<rsalveti> skaet: ^
<infinity> rsalveti: <3
<infinity> rsalveti: Do you need it sponsored, or are you a core-dev?
<rsalveti> infinity: would need someone to sponsor
 * skaet hugs rsalveti
<rsalveti> will update the bug and ping you directly
<infinity> rsalveti: And is it a fix to clutter itself?
<infinity> rsalveti: Cause that's broken right now for other reasons. :P
<rsalveti> yup, fixing the symbols as last upload failed for all archs and disable the egl flag properly
<infinity> rsalveti: (I assume your diff is against the latest version)
<rsalveti> yes
<infinity> rsalveti: "Fixing" the symbols is the wrong fix for the current FTBFS.
<infinity> rsalveti: Unless you mean "making it produce those symbols again by adding the missing configure flag and/or build-deps".
<rsalveti> infinity: yup
<infinity> rsalveti: Oh, in that case, shiny.  I'll be happy to test and sponsor.
<rsalveti> great, will ping you back in a few
<infinity> skaet: BTW, I'm going to jam an eglibc security-fix-only upload in under the wire too.
<infinity> skaet: It slipped from my radar for a while, and sbeattie just berated us for it. :P
<skaet> infinity,  what testing has it had?
 * skaet gets nervous about eglibc and scope of change...
<infinity> skaet: The same patches are present in all stable releases.
<infinity> skaet: Just not precise.
<infinity> skaet: So, I'd say it's had fairly wide testing. ;)
<skaet> infinity,  that's a little less worrisome.  :)  thanks.
<Daviey> infinity: is bug 759545 going to make B2?
<ubot2`> Launchpad bug 759545 in ubuntu-release-notes "user prompted to update unmodified grub configuration during Ubuntu server upgrade" [Undecided,Fix released] https://launchpad.net/bugs/759545
<infinity> Daviey: It'll get looked at during B2 week (and maybe even fixed locally), but I'm not sure if it'll make it in (probably not).
<Daviey> infinity: what about for release?
<infinity> Daviey: It's vaguely near the top of my list, so yeah.
 * Daviey hugs infinity 
<Daviey> infinity: *ideally*, i'd like it fixed before kernel freeze.. so there is a good chance it'll be exposed for real.. :)
<Daviey> infinity: Go straight to UDS, collect beer.
<Daviey> (from me)
<infinity> I do like beer.
<ScottK> o/
<knome> cjwatson, https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/961218 :((
<ubot2`> Launchpad bug 961218 in debian-installer "Lubuntu and Xubuntu alternate images fail to find kernel modules" [Undecided,New]
<doko> skaet, is precise already frozen? asking when I can start the test rebuild
<skaet> lol
<infinity> doko: It's not Thursday yet. :P
<skaet> doko,  everyone else is wanting more time... and you're wanting it to start :D
<skaet> doko,  its tomorrow at 2100 UTC for the freeze,  but I'm expecting the builders to stay busy for a while (kernel rebuild may trail over)
<broder> any chance there's an AA willing to do a srcNEW review for mosh in a week or so? (it's currently in debian, but maintainer has asked me to wait until he rolls a new release before trying anything)
<broder> i can repay you in beer and/or cookies at UDS
<infinity> broder: I like cookies.
<broder> infinity: i live in sf, so i can even offer *fresh* cookies :)
<infinity> !
<doko> hmm, ok
<broder> infinity: sounds like we have the beginnings of a deal. i'll start on the other miscellaneous paperwork, and ping you once everything's in order. thanks
<infinity> broder: I'll be in SF in a week and a half, if you'd like to try bribery, rather than reward.
<infinity> *cough*
<broder> haha. i'll dredge up my cookbooks :)
 * micahg would think it better to start the rebuild before the weekend as there will probably be a lot of buildd downtime
<skaet> micahg, there is Friday to start things off.
<micahg> indeed
<rsalveti> infinity: just attached the debdiff to the bug: https://launchpadlibrarian.net/97800087/clutter-1.0_1.9.16-0ubuntu2.debdiff
<infinity> rsalveti: My hero.
<rsalveti> tested it locally but also pushed to canonical-arm ppa to test it properly
<rsalveti> was also able to build clutter-gst
<rsalveti> on ARMHF
<rsalveti> so that should solve our issues
<rsalveti> also tested with the SGX driver, and clutter seems to be working on EGL again after these changes
<skaet> nice news to end the day on,  thanks rsalveti!  :)
<knome> skaet, i have some news too. we have two more FFe's, which to ubuntu-release was subscribed a moment ago... :)
<infinity> rsalveti: I'm guessing that if cogl is brokering GL/EGL, you could have dropped the libgl-mesa build-deps for !arm too?
<infinity> rsalveti: But that's nitpicking. :)
<rsalveti> infinity: no, that's related with another thing
<infinity> rsalveti: Fair enough.
<rsalveti> we still need it for x86, but can't yet on arm
<jbicha> rsalveti: awesome, thanks!
<rsalveti> jbicha: hey!
<infinity> rsalveti: One last thing, if the egl symbols are now gone, do we need to do an rdep rebuild for everything on ARM that linked to clutter? :/
<skaet> knome,  ack
<rsalveti> infinity: I really don't think anyone was using that directly
<infinity> Here's hoping.
<infinity> But it might be worth double-checking that soon. :P
<rsalveti> yup
<infinity> Anyhow.  All looks good.
<rsalveti> once that hits the archive we can test the clutter related packages again
<infinity> jbicha: I'll sponsor this for rsalveti, unless you felt the urge?
<knome> skaet, was that "you can go ahead"? O:) *whistles*
<rsalveti> and would need to trigger a rebuild for clutter-gst
<rsalveti> once that lands
<infinity> rsalveti: Yeah, that's simple enough.
<jbicha> infinity: feel free to do it if you like
<infinity> jbicha: Doing.
<rsalveti> wow, our amd64 builders are really fast
<skaet> knome,  it means I'm postponing my dinner to go look at it.   :)
<knome> thanks!
<cjwatson> knome: gotcha; seed fiddling required, I'll look tomorrow morning
<rsalveti> infinity: if you still didn't push it, wait a sec
<knome> cjwatson, thanks :)
<rsalveti> ppa build finished successfully on amd64 but it seems that the arm build is not going well
<rsalveti> armel
<rsalveti> will check the logs
<infinity> rsalveti: Haven't uloaded yet.
<infinity> Nor uploaded.
<rsalveti> infinity: ping you back in a few
<infinity> Sure.
<rsalveti> I wish I could build as fast as the amd64 builder on arm :-)
<infinity> distcc, cross-compile, more hamsters?
<rsalveti> still, io is the problem
<rsalveti> I got an imx6 with sata
<rsalveti> but it's quite unstable
<infinity> cjwatson: I imagine the issue is that they both just inherit the platform seeds for that.
<cjwatson> indeed
<cjwatson> Need to figure out how to fix that preferably without having to duplicate the seed.
<infinity> Yeah...
<cjwatson> Which I'm not going to try to do at nearly midnight. :-)
<infinity> I was just pondering the same.
<cjwatson> There's precedent for doing vile sed hacks in cdimage.
<cjwatson> Not that I'm proud of it.
<infinity> Oh, indeed.  Wasn't there some ps3-related hackery I saw when I was in there doing PPC changes?
 * skaet leaves it in cjwatson's hands and heads for dinner...
<infinity> Probably grepping ps3 across everything would find all the bits that need attention.
<cjwatson> Right.  It's technically wrong because there's no reason udebs from different kernel flavour have to have the same dependency structure.
<cjwatson> It's all in bin/germinate-to-tasks.
<skaet> * cjwatson's hands in his morning.... and wishes him sleep well. ;)
<phillw> cjwatson: sorry to bother you, but could you have a quick look at a regex and alter it to post the most recent log at the top, instead of the oldest at the top working down to the most recent?
<cjwatson> phillw: The very idea of doing that with a regex is horrifying.  But I guess.
<infinity> sort -r? :P
<cjwatson> infinity: It'd be better to be able to override Kernel-Version in inheriting seeds and otherwise use the same seed text as the inherited seed, but I somehow doubt germinate supports that.
<cjwatson> phillw: (Show me the whole program involved, not just the regex, please.)
<infinity> cjwatson: I'm almost entirely positive it doesn't, but yeah, overrides would be a nice addition.
<phillw> cjwatson: ##<<PageList(regex:^QATeam/Meetings/QA/2012[0-9\-]+$)>>
<cjwatson> Wuh, I have no idea how this works in moin.
<infinity> cjwatson: For now, cargo-culting the ps3 hack and adapting it to dist_ge precise && PROJECT=whatever should suffice.
<phillw> it is on the https://wiki.ubuntu.com/QATeam/Meetings
<phillw> area
<cjwatson> I doubt that any possible change to the regex will help.  All the regex does is effectively return a boolean: does this page match, or does it not?  It has no effect on sorting.
<infinity> Now, if Moin had a PageListInverse or something...
<cjwatson> https://wiki.ubuntu.com/HelpOnMacros doesn't indicate that PageList has any useful options.
<infinity> (That wasn't sarcasm, I have no idea if it might)
<phillw> cjwatson: thanks, I wanted most recent at the top.
<cjwatson> Mind you, it doesn't document regex:, so who knows.
<cjwatson> phillw: I can't fix your problem.  It may not be fixable given the wiki engine.
<cjwatson> http://moinmo.in/FeatureRequests/PageListSortorder has it as a feature request.  Who knows whether it's implemented ...
<phillw> I'll ask which the team prefers. on lubuntu we add the meeting amnually.
<infinity> http://moinmo.in/FeatureRequests/PageListSortorder
<cjwatson> Jinx.
<infinity> phillw: See if PageList(reverse,regex:....) works, maybe we're carrying that patch.
<phillw> *manually*
<cjwatson> No hint in the source of that syntax working.
<phillw> infinity: I've already pretty much broken the page. But I will try it.
<infinity> Could be worth a bug report on wiki.u.c to add said patch.  Seems like useful functionality.
<cjwatson> That patch doesn't apply to the current version.
<infinity> cjwatson: Not even with some human defuzzing?
<phillw> infinity: I'm not a great fan of reporting bugs, they just allow mine to time out....
<cjwatson> Neither of the methods it's talking about exist.
<infinity> cjwatson: \o/
<cjwatson> Unreported bugs are even less likely to be fixed than reported bugs.
<cjwatson> It's probably for moin 1.5 or something.
<astraljava> May I quote you on that? :)
<phillw> cjwatson: I have reported them, under the guidence of phil bull. so, if no one takes any notice of two wiki editors... there comes a point when we just say it is broken. :(
<astraljava> It's so going to my .sig file. :)
<cjwatson> The URL above links to http://hg.moinmo.in/moin/extensions/file/tip/data/plugin/macro/ListPages.py, which might be installable as an extension.
<cjwatson> astraljava: I guess, I didn't think it was that funny :-)
<astraljava> Try saying that to yourself in front of a mirror, with a straight face, a couple of times over. :)
<infinity> rsalveti: If cogl-dev needs gl/egl-dev, surely that's a bug in cogl, not something the depending packages need to sort out?
#ubuntu-release 2012-03-22
<rsalveti> infinity: that's what I'm trying to find out
<rsalveti> but yes, cogl-dev should be the one pulling egl here
<infinity> rsalveti: (But given our beta timeline, working around it in clutter's build-deps for tonight seems acceptable)
<rsalveti> yeah
<rsalveti> hehe, libcogl-dev is not depending on any mesa related package
<rsalveti> not for gl and not for egl
<infinity> Yeah, that seems like a bug to me.
<infinity> And probably just unnoticed because clutter is cogl's only consumer that anyone cares about, and it build-deps on gl/egl.
<infinity> Or did, until just now. ;)
<rsalveti> exactly
<kees> infinity: oh, does that eglibc update include my crazy vfprintf fix?
<infinity> kees: I don't like it when you use the word crazy.
<micahg> can someone please tell me if I need an FFe for this: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=blob;f=Changelog;h=cb04ee49926d4bf11d9480c2a8cf3092416991f7;hb=HEAD#l15
<micahg> oh, nevermind, APIs added, will file an FFe
<kees> infinity: sorry, trying again... does that include my fix for crazy vfprintf?
<infinity> micahg: Added beats removed at least.
<infinity> kees: Your sane fix for a crazy vprintf?  Yes, yes it does.
<kees> \o/
<infinity> vfprintf, even.
<kees> cool, I didn't want precise to miss out on that.
<micahg> infinity: indeed :)
<infinity> kees: CVE-2012-0864, yes?
<ubot2`> infinity: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0864)
<infinity> ubot2`: You're not helpful AT ALL with CVEs, stop trying.
<ubot2`> infinity: Error: I am only a bot, please don't think I'm intelligent :)
<infinity> kees: Do you know if anyone at mitre has ever discussed actually pulishing CVEs in a timely manner?  I love how they lag disclosure time by, sometimes, months (or years).
<infinity> rsalveti: armel still sad.
<rsalveti> infinity: let me check
<infinity>  /usr/include/cogl/cogl/cogl-defines.h:33:23: fatal error: GLES2/gl2.h: No such file or directory
<infinity> Definitely points to missing deps in cogl-dev, at least. :P
<rsalveti> infinity: yup, cogl-dev broken
<rsalveti> I'm trying to fix it properly there, 1 sec
<infinity> Check.
<infinity> rsalveti: I've got all night and freeze isn't until tomorrow, let's just do it right and be done with it.
<rsalveti> infinity: yeah
<kees> infinity: mitre has been getting worse and worse :(
<kees> but yeah, that's the CVE
<infinity> kees: That's not saying much, given how bad they were back when I used to deal with them a lot.
<cjwatson> Sod it, I'd worked out how to fix the lubuntu/xubuntu generic kernel thing so just did it.
<micahg> skaet: FYI, there's a new chromium security release coming, idk if it'll be released before Beta freeze, but it should be this week
<cjwatson> knome: ^-
<micahg> skaet: heh, Chromium was just released, I'll get it in before the freeze
<ScottK> broder: If you still need a volunteer for New, I'll do it if it's a sync from Debian.
<ajmitch> ScottK: how much longer do you think we'll be allowed to sync new packages & have someone review them? :)
<ajmitch> & how much does it cost?
<ScottK> If they're syncs, not much.
<ScottK> How late depends on why.
<infinity> ScottK: Are you trying to talk broder out of baking me cookies?
<ScottK> No.  He should do that on general principles.
<ajmitch> ScottK: just packages that might be 'nice-to-have'
<ScottK> ajmitch: Depends on my mood, I guess.
<ajmitch> ok
<ajmitch> I'll try & be super-nice to you when I'm ready to ask for them
<ScottK> infinity: Is he someone who's cooking you want to eat?  You might be better off with store bought.
 * ScottK doesn't know.
<infinity> ScottK: He did mention something about "recipes".  That might be a warning sign.
<infinity> Even I can make cookies without looking up how.
<ScottK> Or a good one.
<ScottK> I mean, if you can read you can cook as long as you can do the steps in the right order.
<ScottK> Computer people ought to be reasonably capable in that regard.
<infinity> Sure, but it relies on you having a good recipe to start with.
<infinity> Not all cookies are created equally. :P
<ScottK> That's definitely true.
<rsalveti> infinity: bug 961798
<ubot2`> Launchpad bug 961798 in cogl "libcogl-dev should also depend on gl/gles -dev packages" [High,In progress] https://launchpad.net/bugs/961798
 * micahg figures there are at least 300 packages that should probably be sync'd for one reason or another ATM
<rsalveti> infinity: https://launchpadlibrarian.net/97809829/cogl_1.10.0-0ubuntu2.debdiff
<rsalveti> infinity: with the previous clutter debdiff I posted at the other bug it worked fine now
<rsalveti> after pushing this package to the ppa
<rsalveti> finished fine for all archs
<infinity> rsalveti: Alright, I'll get on that.
<infinity> rsalveti: I suppose that also means that clutter no longer needs the GL build-dep on !arm either.
<infinity> rsalveti: Unless it has a local, non-cogl reason to need it too, then it's correct as-is.
<infinity> (Even if slightly redundant)
<ogasawara> skaet, kees: kernel uploaded.  based on previous build times it should finish in time for us to rev and upload linux-backports-modules and linux-meta before the 21:00UTC beta-2 freeze deadline.
<rsalveti> infinity: there's a local reason for that, but yeah, redundant
<infinity> rsalveti: Local reason's enough for me.  I'll sponsor these as-is.
<rsalveti> infinity: great, thanks
<ajmitch> micahg: that many?
<micahg> ajmitch: yeah, I think so, between really outdated upstreams, dh_python2, RC, FTBFS, and translation updates
<infinity> ogasawara: Dangit, you should have warned me.
<infinity> ogasawara: I could have aimed the i386 build at a builder that doesn't suck.
<ajmitch> micahg: I'll look at the rc list this weekend, I guess I may be filing a few FFes :)
<ogasawara> infinity: ahh dammit
<infinity> I suppose I still can.
<ogasawara> infinity: I think we have enough time even if the builds are slow
<infinity> ogasawara: Yeah, but fast doesn't hurt, and we have two quick builders available for x86.
<ogasawara> infinity: I won't argue if you move it to a faster machine :)
<infinity> ogasawara: There, you have roseapple and allspice for your x86 builds now.
<infinity> ogasawara: And PPC should be starting in ~15m.
<micahg> infinity: will you be around in ~2hrs for a round of package copies?
<infinity> micahg: Maaaaaybe.
<micahg> heh, also, can you reset to auto the other buildds :)
<infinity> micahg: No.
<infinity> (I'd already done it before you asked)
<infinity> ogasawara: Is there a ti-omap4 merge in the works to match the changes in -20.32?
<micahg> ah, I refreshed like 5 times
<ajmitch> micahg: blame LP's caching or something
<micahg> infinity: I'll just have the package copies done in the morning, I guess a few hours won't hurt at this point
<infinity> micahg: I'm sure I'll be around laterish, if you poke me.
<infinity> micahg: And if I'm not, pitti will be up in 3 or 4 hours. :P
<micahg> ok, well, I'd prefer to use my AA favors tonight for other things :)
<infinity> There isn't a limited number you can use.  It just affects how much of my homework I'll make you do later.
<ogasawara> infinity: I suspect ppisati will get to it in the morning.  I wouldn't consider it urgent for arm as the patches only affect amd64/i386.
<infinity> ogasawara: Oh, really?  I assumed it was a generic thing, didn't look closely.
<infinity> kees: Stop implementing x86-only security features, jerkpants.
<ogasawara> heh
<micahg> chromium's uploading
<nigelb> lol
<micahg> finished about 7 minutes ago
<stgraber> can someone look at ubuntuone-client in NEW? it's currently breaking upgrades here
<stgraber> they apparently introduced ubuntuone-client-proxy
<stgraber> FFe is bug 929207
<ubot2`> Launchpad bug 929207 in ubuntuone-client/trunk "[FFE] Proxy "tunnel" for syncdaemon" [High,Fix released] https://launchpad.net/bugs/929207
<infinity> stgraber: Done.
<stgraber> infinity: thanks
<infinity> cjwatson: You know, now that iwj isn't around to complain anymore that his mirroring tool from 1996 won't work without it, I wonder if we shouldn't discuss dropping ls-lR.gz from the archive (and the 6 minutes it takes to generate...)
<infinity> pitti, slangasek: Thoughts? ---^
<rsalveti> infinity: seems clutter is just waiting to hit the archive, then we'll be finally able to trigger clutter-gst
<rsalveti> and see if the image is blocked by another package
<rsalveti> infinity: are you also able to trigger new image builds?
<infinity> rsalveti: I am.
<rsalveti> great
<infinity> (And I know that we're waiting on clutter to be published, see above about my annoyance with the publisher taking so long) :P
<infinity> It overlapped its lock and missed the :33 run, so I have to wait for :03.
<rsalveti> yeah, thought it was related :-)
<slangasek> infinity: huh.  I know nothing about ls-lR.gz (I had long forgotten it was there), so I defer to the mirrors team.
<infinity> slangasek: Well, it wasn't there for a good while after we did the katie->soyuz switch, and no one complained until we hired iwj and he had a fit that his ancient mirroring tool (forget what it was) wouldn't work. :)
<slangasek> yes - still, I'd ask the mirroring team since they're the only ones likely to care about it
 * infinity nods.
<infinity> Fair enough.
<kees> infinity: there are detailed instructions on how an architecture can enable it in the HAVE_ARCH_SECCOMP_FILTER Kconfig help :) also, ARM is planned, but after this one is all the way upstream first.
<kees> ogasawara: nice!
<infinity> kees: I'll show you "all the way upstream".
<infinity> Or something.
<kees> hehe
<kees> my choice of phrasing was intentional there :P
<broder> ScottK: oy! my cooking is *just* fine, thank you :-P
<infinity> rsalveti: Kicking off new armhf ubuntu-desktop dailies in 3600 seconds.
<rsalveti> infinity: awesome
<infinity> rsalveti: (As in: sleep 3600 && do stuff)
<infinity> Since I won't be around then. ;)
<rsalveti> I might be available still
<infinity> Well, I'm going out for a bit.
<infinity> I'll be back later to check on them.
<rsalveti> great, thanks
<infinity> But thanks for the clutter fixes.
<infinity> Now, if you can convince markos to make gnat go (or maybe put someone like riku on the problem?), I'll love you forever.
<rsalveti> yeah, will ping them
<pitti> good morning
<rsalveti> morning!
<pitti> micahg: still need package copies?
<infinity> Guten watevertimeofdayitis.
<micahg> pitti: no, not ready unfortunately, decided to do stuff for beta 2 instead
<pitti> infinity: I don't know of anything which needs ls-lR.gz, it just sounds like something for client-side mirroring?
<infinity> pitti: Yeah, it's all about mirroring.
<infinity> pitti: As vorlon suggested, I'll ping the mirror people about it sometime and see if anyone actually cares.
 * micahg could use someone to look at bug 961873
<ubot2`> Launchpad bug 961873 in blueman "FFe: Update to 1.23" [Undecided,New] https://launchpad.net/bugs/961873
<infinity> micahg: What there's actually a feature, other than the appindicator bit?
<micahg> I think that was it, there's also the new icon, but I guess that would need a UIFe
<infinity> micahg: And is the appindicator support smart enough to go either/or on indicator versus systray, or will I end up with two icons? :P
<micahg> hmm, not sure, I suppose I should try that :)
<infinity> Yeah.
<infinity> Cause I have both an indicator tray and a more classic systray on my xubuntu desktop.
<pitti> micahg: responded
<infinity> Blueman is currently in the latter.
<infinity> Would be annoying to have it in both.
<micahg> hmm, I think this might be the only machine on precise with xfce and I don't want to reboot into it, care to test for me :)
<micahg> xfce and bluetooth that is
<infinity> micahg: Do you have PPA packages somewhere?
<infinity> And will I have to log out?  I have a ton of crap open...
<micahg> infinity: no, but I have a binary I built locally
<micahg> oh, hmm, same boat :)
<infinity> I imagine just killing it might do the trick.
<micahg> infinity: will an amd64 binary work for you?
<infinity>  2117 ?        Sl     0:01 /usr/bin/python /usr/bin/blueman-applet
<infinity> micahg: Sure.
<infinity> I'm guessing just killing the above will DTRT.
<infinity> I hope. :P
<infinity> (Well, and potentially re-running it)
<infinity> Crap, publisher overlapped again.
 * infinity changes his sleep on that image build.
<infinity> micahg: Quick like a bunny, I have places to be. ;)
<micahg> sorry, figured you wanted a signed changes file :0
<infinity> Just scp it to lillypilly, and I'll assume it's from you.
<infinity> Cause I'm trusting that way.
<micahg> infinity: done
<infinity> micahg: Okay.  I have only one icon (and it's the right one).
<infinity> micahg: But did this disable non-indicator support for people who don't have an indicator panel?
<infinity> micahg: Or does it do smart runtime detection?
<micahg> infinity: no idea, haven't dug too deep into it
<infinity> micahg: I suppose not a massive concern anyway, since the default Xubuntu profile ships with an indicator panel enabled.
<micahg> and I have a patch to disable by default in Lubuntu
<infinity> micahg: But it looks good to me, and only gave me one icon, so I'm cool with it.
<infinity> Does lubuntu not have an indicator tray/panel?
<infinity> Irksome.
<micahg> it's too heavy to have on by default
<infinity> Really?
<infinity> *shrug*
<infinity> Alright.
<infinity> I thought it was one of the cleaner bits of in-house code we'd done.
<infinity> Anyhoo.  It gets my Xubuntu nod of approval.  I have no way to test it on lubuntu without serious effort.
<infinity> Speaking of indicator icons and UIFes, though, I really need to do something about update-manager's hideous icons.
<infinity> They really don't fit in.  At all.
<micahg> ok, I really do need to go to sleep, the only thing left for me for beta 2 now is lightdm-gtk-greeter which I'll finish later today
<infinity> micahg: http://lucifer.0c3.net/~adconrad/not_pretty.png <-- I can't be the only person that icon bugs, right? :)
<micahg> heh, yeah, doesn't seem to size right
<micahg> looks fine for me in Xfce and Unity 2d
<micahg> (Xfce machine doesn't hae bluetooth)
<infinity> Well, my theme is hardly a default setup.
<Laney> hardening-buildflags changes like http://anonscm.debian.org/gitweb/?p=pkg-mono/packages/mono.git;a=commitdiff;h=96d7d4a3a91ab204958ff26b9210328c5db82e19;hp=86127dcf508213eac5b50a65c989cf5971b57378 should be OK without FFe?
<jamespage> morning all
<jamespage> please could the zentyal-* binary packages be accepted into precise
<Riddell> jamespage: please nudge steveK who is listed as the day's contact at https://wiki.kubuntu.org/ArchiveAdministration#Archive_days
<Riddell> if he doesn't reply then nudge me and I'll do it
<jamespage> Riddell, ack
 * jamespage goes to look for StevenK
<knome> cjwatson, great, thanks :)
<rsalveti> \o/ seems we finally have an image for omap4
<rsalveti> not yet synced at cdimages but at least last livecd log is looking good again
<rsalveti> I wonder when the image will be available at cdimage, so we can finally test it again
<rsalveti> ogra_: you might know :-)
<cjwatson> cd builds run immediately after livefs builds
<rsalveti> hm, ok, so it might just be waiting other livefs builds then
<rsalveti> or just in progress
<cjwatson> yes
<cjwatson> it waits for all the livefs builds in the batch to complete
<rsalveti> great, should be available in a few then :-)
<rsalveti> at least I know it worked, happy about that already
<rsalveti> guess we didn't have a working image for a few days already
<rsalveti> for arm I mean
<ogra_> rsalveti, we had omap4 since weeks, what was broken for you ?
<rsalveti> ogra_: the image was broken for a few days
<ogra_> not here
<rsalveti> ogra_: the ones at cdimages are just a copy from the last working image
<ogra_> some builds were broken due to nautiluzs-empathy and some due to gnome-games, but generally they worked
<rsalveti> that's why once I download the one from 17/18 the others matched the md5 perfectly
<ogra_> we definitely had a good bunch of working ones the last 14 days
<ogra_> the md5 summing is broken since over a month now
<ogra_> dont count on md5 sums
<rsalveti> let me check the livecd logs
 * ogra_ gets mails for every failed arm build 
<ogra_> there were a few but there also were many that didnt break
<ogra_> infinity is on the md5sum stuff since a few days
<ogra_> should be fine soon
<rsalveti> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/precise/ubuntu-omap4/20120319/livecd-20120319-armhf.out is the last working one
<ogra_> right, 20th had the games issue, 21 and 22 the nautilus-empathy breakage
<rsalveti> yup, that got fixed with clutter
<ogra_> the latter ?
<ogra_> aha
<rsalveti> yep
<rsalveti> empathy -> clutter-gst -> clutter
<Riddell> need new ones built?
 * ogra_ didnt dig into that, i would have done that on monday ..... for the installer sprint i only need headless 
<rsalveti> Riddell: the last one worked, just not yet at cdimages
<rsalveti> so we should be good
<rsalveti> ogra_: I noticed because I wanted to test the desktop image for beta-2
<ogra_> thats still a week t go :)
<rsalveti> sure, but beta freeze is today I guess
<ogra_> should be on monday
<ogra_> not sure though
<rsalveti> and there are still some annoying issues =\
<ogra_> ah, no, its tomorrow
<rsalveti> perf is broken, kernel is unstable with 4460, lightdm is incredibly slow
<rsalveti> and a few other minor ones
<ogra_> well, release is still a month out
<ogra_> no worries ;)
<rsalveti> :-)
<ogra_> i see your xorg fix made it in already ?
<ogra_> so you only need sponsoring for the pvr driver ?
<rsalveti> ogra_: yup
<ogra_> k
<Riddell> cjwatson, pitti: you guys onto the release minus 10 and 7 days tasks?
<cjwatson> guess I ought to be
 * cjwatson will clear out some installer work first though
<pitti> I'm constantly monitoring NBS, c-m, and uninstallability, but haven't gotten around the other bits yet TBH
<Riddell> I expect skaet will do the various e-mails it needs when she wakes up
<cjwatson> the ubiquity warning message is already gone from beta-1; checked that yesterday
 * skaet wakes up,  sips coffee and starts on the backscroll ;)
<skaet> Riddell,  yup, will start on those messages this morning.
<ara> skaet, hello
<ara> skaet, cr3 made the needed changes in LP results for the API stgraber was asking for
<ara> skaet, the deployment is blocked on RT #51666
<ara> in case you want to talk to IS ;-)
<skaet> ara,  thanks for flagging.  :)
<ara> skaet, I already raised priority, but the more stakeholders, the better, I guess :)
<skaet> ara,  yup.  :)
<Riddell> kubuntu live images are all under 700MB but alternates are well over, if I can't track that down do we have a way to just remove packages from only alternates?
<cjwatson> Depends.  It's easy if they're in the ship seed.
<cjwatson> If they're within desktop, not really.
<stgraber> can I get an Edubuntu respin, it failed yesterday because of lxc's postinst (fixed now)?
<cjwatson> stgraber: running
<stgraber> cjwatson: thanks
 * skaet went to go start and noticed....
<skaet> thanks cjwatson
<ogra_> skaet, when do youplan to call out the freeze tomorrow ? rather in your morning or in your evening ?
 * skaet gives ogra_ points for a good try to get the freeze moved ;)
<ogra_> huh ?
<skaet> freeze is at 2100 UTC today.
<ogra_> the schedule say 23rd
<seb128> ogra_, not it doesn't?
<skaet> ogra_,  link please
<seb128> ogra_, it says week 23
<seb128> it's confusing :p
<seb128> 23 march 22nd
<seb128> I got bitten by that in the past as well :p
<skaet> ogra_,  its been in the weekly agenda, and I post it at the start of each week's meeting too...
<seb128> it would probably help if the first column on https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule was in a different color
<seb128> it's easy to take the week number as a day as it is now
<skaet> seb128,  if I forget please remind me at UDS as one of the improvements for Q...
<ogra_> seb128, argh, yeah
<seb128> skaet, will do!
<seb128> ogra_, hehe, you are not the first one to fall into it ;-)
<ogra_> well, instead of adding 23 there make it W23
<ogra_> that clearly identifies it as not being a date
<seb128> ogra_, but well, freeze have never been on friday, you should have stopped on that ;-)
<ogra_> seb128, i was doing the installer vsprint until yesterday and left some bits slip due to well, seeing the freeze on 23rd
<ogra_> i'll survive though :)
<knome> skaet, i suppose you will be pretty much around until beta2 release?
<skaet> knome, myself, pitti, and cjwatson will be focusing on getting it out.   We do need to sleep, eat, etc.  though ;)
<knome> skaet, overrated. it's going to take us until 19UTC to get to uploading the bugs filed yesterday. and we might need andother ACK to fix the plymouth theme (all messages show now, but on one line, and not all of it fits in in a small resolution)
<skaet> knome,  I'll be around until beta 2 freeze at 2100.
<knome> skaet, thanks. i'll get back to you :)
<micahg> ScottK: re: cairo-dock-plug-ins> a few things looked like features like:    - Enable GVFS if detected,     + Enabling threads on the Python Interface
<ScottK> micahg: OK.  I was relying on the statement that it was a bug fix release.
<ScottK> Enabling threads might be a bit sporting.
<ScottK> Would you please follow-up in the bug.
<micahg> sure
<micahg> you want -release resubscribed?
<ScottK> Sounds like it would be a good idea.
<skaet> pitti, https://bugs.launchpad.net/ubuntu/+bug/959032 - is there even the option to put checkbox-gtk on the disk in a reasonable way for just beta2 or is this clearly not going to be able to happen for this release?
<ubot2`> Launchpad bug 959032 in ubuntu "[needs-packaging] Checkbox-app-testing" [Wishlist,New]
<pitti> skaet: option yes, but it seems that the checkbox guys didn't really fully make up their mind yet?
<pitti> I don't feel I'm able to make a decision which one is better
<skaet> ara, ^
<skaet> what is the recommendation?
<ara> skaet, we have checkbox-qt in the CD and that's the one that should stay there
<ara> skaet, from 0.13.5 is ffeature complete
<ara> skaet, but this is a different thing, isnt't it?
<pitti> it seems it broke the test format, so that Nicholas' tests now ceased to work
<pitti> see bug 959032
<ubot2`> Launchpad bug 959032 in ubuntu "[needs-packaging] Checkbox-app-testing" [Wishlist,New] https://launchpad.net/bugs/959032
<ara> pitti, ah, OK, because we use a mark up language to format the tests
<pitti> so it seems we shoudl defer this ^ and get the tests converted?
<ara> balloons, how long would it take to convert your tests?
<balloons> hey :-)
<balloons> I was just asking the team this morning about checkbox-qt.. there was a bug marc was working on that was critical for me also
<ara> balloons, which bug?
<balloons> on the test conversion, it's nontrivial.. however, I was going to offer to try and do it, assuming the app worked for me now
<balloons> https://bugs.launchpad.net/checkbox/+bug/959463
<ubot2`> Launchpad bug 959463 in checkbox "Apport should prompt when failing a test during development" [High,Fix released]
<balloons> I haven't had success getting the tests to run even under the new format, so it's not been an option honestly
<ara> balloons, that bug is now fixed in Precise
<balloons> hmm.. I get another error, but maybe it's just me :-(
<balloons> regardless, I filed the ffe hoping the cd had space to ship checkbox-gtk as well as I know my package is working and stable as is
<ara> balloons, what error do you  get?
<balloons> on the apport thing? "Cannot connect to crash database, please check your Internet connection.
<balloons> <urlopen error [Errno -2] Name or service not known>"
<balloons> I just pulled the version roadmr says is shipping in precise.. The bigger issue than that bug (although it looks better despite failing on my box), is the test format change. And me not have success getting my tests to run even after changing them over
<sladen> doesn't look like the wallpapers are going to turn up at this rate
<sladen> so those might appear after unfreeze instead
<Laney> why is it so late?
<sladen> wallpapers.  They always go in last ;-)
<Riddell> make sure you get docs team to give the ok on that
<brendand> Daviey, hey
 * pitti cleans up NBS
<Laney> it's not really on
<cjwatson> Thoughts on bug 958430?
<ubot2`> Launchpad bug 958430 in openssl "[FFe] Please merge openssl 1.0.1 from Debian unstable" [High,Triaged] https://launchpad.net/bugs/958430
<cjwatson> (maybe I shouldn't have marked that Triaged)
<adam_g> hi all, sorry to spam here for a handout but are there any archive admins around who might be able to help get the nova upload nudged through the queue, or is there anything i can do to help get things moving? the last upload introduced a new binary package (nova-consoleauth) which consists of a script previously packaged in nova-console, plus an upstart job + man page
<stgraber> pitti: will we have refreshed langpacks for beta2? (just wondering, couldn't find an upload schedule for these)
<ScottK> cjwatson: I agree updating to the new release is better than cherrypicking changes.
 * ScottK is inclined to think it's a good idea, but reluctant to get tagged as the guy that said it was OK.
<pitti> stgraber: yes, we should; I'll deal with them tomorrow
<cjwatson> ScottK: heh, yeah, understood
<stgraber> pitti: cool, thanks. Hopefully that'll be the first Edubuntu milestone where everything supports translations (took a while...) :)
 * cjwatson attaches build logs and such for form's sake
 * ScottK thinks slangasek should approve it.
<slangasek> which?
<ScottK> openssl FFe
<slangasek> openssl?
<ScottK> Yes
<Riddell> adam_g: steveK is on duty today have you pinged him?
<slangasek> yeah, I can look at that one
<ScottK> Excellent.
<micahg> Riddell: it's the middle of the night for stevenk :)
<Riddell> micahg: that's no excuse for shirking off from your duties!
<adam_g> Riddell: i haven't, is there somewhere that i can find the schedule of whos on duty / who to bother?
<Riddell> adam_g: https://wiki.kubuntu.org/ArchiveAdministration#Archive_days
<adam_g> Riddell: thanks!
<Laney> I am under the impression that those archive days haven't been happening for some time
<Laney> maybe I'm wrong
<cjwatson> you're generally correct
<cjwatson> just double-checking with the security team about the qrt failure there
<Riddell> Laney: I'm back on mine now
<jdstrand> Laney: I was off last friday
<sladen> Laney: re: ^^ I'm inclined to agree.  But also as predictable as the tides and seasons of the sea
<jdstrand> Laney: but people have been tending to focus on specific areas. eg, I typically spend my time on NEW, +1 maintenance works on many of the others
<Laney> jdstrand: Riddell: I just thought that it had become more task-driven rather than time-driven.
<jdstrand> Laney: it is moving towards that
<Laney> sladen: yes. So how can we fix this for next time?
<Laney> Reject the UIFe? ;-)
<cjwatson> adam_g: looking
<cjwatson> adam_g: This breaks upgrades.  It needs Breaks: nova-console (<< 2012.1~rc1-0ubuntu1) and Replaces: nova-console (<< 2012.1~rc1-0ubuntu1)
<cjwatson> adam_g: rejecting, sorry.  Please upload a new source package that fixes this
<adam_g> cjwatson: 10-4, thanks for the input
<Daviey> brendand: hey
<cjwatson> adam_g: also, should nova-console have some kind of dependency relationship on nova-consoleauth so that it doesn't vanish on people?
<cjwatson> adam_g: or do you have a reason to avoid that?
<cjwatson> adam_g: it also seems odd that nova-consoleauth's long description (as opposed to the one-line short description) is identical to that of nova-console
<cjwatson> adam_g: FWIW, citation for the need for Breaks/Replaces when you move files around: http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.6.1
<cjwatson> adam_g: oh, and the nova-console package here still ships /usr/bin/nova-consoleauth - so please remove that and bump the Breaks/Replaces to (<< 2012.1~rc1-0ubuntu2)
<adam_g> cjwatson: thanks. the console + consoleauth components were apparently packaged together in error, the latter without any init script or upstart job. ill see about getting a new upload together as this one seems botched
<cjwatson> ok - feel free to transfer all this into a bug or whatever if that helps
<cjwatson> and also to ask me to review the next upload in the queue so that another admin doesn't need to start from scratch
<skaet> cjwatson, there's a new quantum upload in the queue now,  could you take a pass and confirm that the blockers you noticed have been handled?
<slangasek> cjwatson: which way should I be reading these openssl speed numbers in the FFe bug?
<slangasek> 'k' as a suffix would've suggested to me that larger == better, but you interpret the numbers as saying the new aes code is slower on your machine in 64-bit mode and I don't see that
<cjwatson> slangasek: bigger is better.  sorry, I was unclear, it's faster for small block sizes and slower for large block sizes
<slangasek> ohh, there it is
<slangasek> right, I missed that when eyeballing because there's an extra digit :)
<cjwatson> it's only for aes-128, and newer hardware doesn't show the same symptoms, so I'm not regarding it as a big deal, but I wasn't going to edit the data :)
<slangasek> yep, exactly
<slangasek> cjwatson: ffe appproved
<ScottK> You should've made cjwatson approve the upstart one first ...
<cjwatson> skaet: yes, this looks better now within the limits of my ability to review at the moment; accepted
<skaet> thanks cjwatson. :)
<cjwatson> ScottK: hey, I was reviewing server packaging, I'm sure my karma must be adequately stocked
<skaet> Daviey, ^
<cyphermox> ScottK: updated the FFE for bluez, sorry, this was indeed a little confusing
<Daviey> cjwatson: Keep this up, and you should apply for server set upload access :)
<cjwatson> ha ha bonk
 * cjwatson uploads openssl and crosses fingers
<slangasek> ScottK: I was going to ask you to approve the upstart one :P
 * ScottK steps away
<infinity> rsalveti: All your work yesterday paid off, BTW, we have fresh ARM images.
<rsalveti> infinity: great, need to check that
<infinity> Now to figure out how I managed to fix md5sums for all the *gz images, but the stupid ac100 bootimg is still wrong.
 * infinity is inclined to blame ogra_ for that.
<infinity> rsalveti: Oh, I'd almost forgotten the whole point of this exercise (other than fixing things for beta) was to figure out WTF the slideshow wasn't there, wasn't it? :P
<rsalveti> infinity: haha, yup, doing that now
<infinity> rsalveti: And it's still not.  I guess I get to investigate now.
<rsalveti> oh, you validated already
<rsalveti> great then
<ogra_> did you fix get lost or so ?
<infinity> rsalveti: Well, I just checked the build log to see if the package was being installed, and it's not.
<ogra_> iirc you fixed that in oneiric and it worked
<infinity> ogra_: No, my fallback fix is there, the package literally isn't being installed at all.
<ogra_> with some seed magic
<ogra_> oh
<ogra_> weird, since it worked fine in oneiric, i remember seeing the slideshow after your fix
<infinity> ogra_: Yeah.  The slideshow is still in the ubuntu-live task.  But not being installed.  I'm a bit puzzled, but looking.
<infinity> Oh.
<infinity> That looks suspiciously like my code.
<infinity> if [ "$PREINSTALLED" != "true" ]; then
<infinity>         add_task live "$LIVE_TASK"
<infinity> fi
<infinity> When did I do that, he asks bzr blame...
<ogra_> != true ?
<ubot2`> Factoid 'true ?' not found
<infinity> Yeah, totally my fault.
<infinity> I dropped LIVE_TASK (for good reason), but completely forgot the slideshow was coming from there.
<ogra_> ah
 * infinity fiddles.
<ogra_> oh, i remember
<ogra_> the kde bits etc
<infinity> Well, lots of bits.
<ogra_> right
<ogra_> but that explains why it worked in oeniric
<infinity> oem-config doesn't remove the desktop/live delta the way ubiquity does, so it left cruft.
<infinity> Anyhow.  rsalveti was right, adding the slideshow manually is the way to go for now (though he got the package name wrong, that's all)
<ogra_> effectively we should look into oem-config and fix it there though
<infinity> ogra_: Fix what?
<ogra_> the handling of the live task
<ogra_> something for Q though
<infinity> ogra_: That would mean shipping manifests on the filesystem.
<ogra_> we shouldnt need workarounds but have a switch to make oem-config use the same routine
<infinity> ogra_: And oem-config really isn't meant to do any of this. :P
<ogra_> same goes for things like apt-setup (and i'm sure there are more)
<ogra_> oem-config supresses a good bunch of ubiquity bits we should make switchable imho
<infinity> We mostly just provide preinstalled images as fun tech preview toys anyway, until that changes, I'm not sure how much more effort I want to put into making oem-config an installer (when it's really not).
<ogra_> well, then we should probably switch back to live images :)
<infinity> At some point, we should.
<ogra_> with the known drawbacks indeed
<infinity> But probably not while 99% of our developer base is using glorified cell phones as their hardware platform.
<ogra_> heh, yeah
<infinity> rsalveti: I'll spin another set of images once that livecd-rootfs is built.
<rsalveti> infinity: great, thanks
<stgraber> can someone from -release review bug 950157?
<ubot2`> Launchpad bug 950157 in ldm-ubuntu-themes "[UIFe] Lubuntu LDM Theme" [Low,Confirmed] https://launchpad.net/bugs/950157
<stgraber> it's been approved by gilir already
<knome> skaet, just a heads up, we're still working for another patch to fix the problems in bug #961546
<ubot2`> Launchpad bug 961546 in xubuntu-artwork "Xubuntu Plymouth theme shows cut messages" [Undecided,Fix released] https://launchpad.net/bugs/961546
<skaet> knome,  gotcha
<knome> and, still waiting for mr_pouit to get home and upload a few other ack'd Fe's ;)
<kees> skaet: I've got a (hopefully) quick FFe for the release team: bug 962431
<ubot2`> Launchpad bug 962431 in manpages "[FFe] update to manpages 3.35" [Undecided,Confirmed] https://launchpad.net/bugs/962431
<stgraber> kees: didn't two release team members already approve it? :)
<kees> stgraber: oh! I didn't reload! hah.
<pitti> heh, ScottK and I raced :)
<pitti> hey kees
<kees> sweet! hi pitti!
<kees> okay, uploading. :)
<kees> ta-da.
<skaet> kees,  looks like there was a collision between ScottK and Martin before I got to it.
<kees> yay, now "man 7 capabilities" will list CAP_SYSLOG :)
<skaet> pitti,  isn't approved state -> Triaged?
<pitti> "confirmed" usually
<kees> skaet: yeah, thanks! ScottK and pitti were all over it before I even noticed :)
<skaet> kees,  :)
<pitti> but the state is not always unanimous, it usually takes a check through the comments to be 100% sure
<pitti> i. e. for "fix committed", when it's fixed upstream, but not yet in the distro, and needs an exception
<skaet> hmm... we need to update some docs then..   What I'm seeing is:
<skaet> https://wiki.ubuntu.com/FreezeExceptionProcess
<skaet> Once the Feature Freeze Exception has been ACK'd by a member of the Release Team, the status will be changed to TRIAGED. You can then either upload the package (in case you're in motu or ubuntu-core-dev), or follow the SponsorshipProcess. Please close the bug from the upload, where possible.
<pitti> skaet: oh, right
<pitti> ok, I'll update my mental model accordingly, sorry
<skaet> :)  thanks pitti
<kees> whoops, I didn't close the bug with the upload. I'll handle that manually.
<stgraber> highvoltage, gilir: new ldm-ubuntu-themes uploaded. It'll need to wait for an archive admin to process the new binary package though
<highvoltage> stgraber: great, alkis will be pleased
<micahg> pitti: I don't have time to do what I wanted with lightdm-gtk-greeter, so I'm going to upload the version that mr_pouit made as soon as I run some final checks on it
<cyphermox> ScottK: sorry for the trouble.
<micahg> umm, do I need an FFe for lightdm-gtk-greeter before I upload since it's already in the archive, just a new source?
<infinity> micahg: I'm not sure I understood the question.
<slangasek> micahg: if it's just the package splitting, then no
<infinity> micahg: You need an FFe if it has new features.
<slangasek> infinity: lightdm dropped the greeter, !ubuntu flavors still depend on it
<micahg> well, new binaries need an FFe, was wondering if a new source technically did as well :)
<slangasek> (and are meant to do so - which means the source needs reintroduced)
<infinity> (A package split is a new feature, in that you could do it wrong WRT to dependencies and transition and such)
<slangasek> it's only a new source package, not a new binary package; I don't see any new feature here per se
<infinity> But if it's just reintroducing a binary that was previously dropped, I see no reason for the FFe.
<infinity> Yeah.
<micahg> this is just for technical reasons, I know I have the ok to upload, just wanted all the i's dotted and t's crossed :)
<infinity> micahg: More importantly, freeze is in an hour, upload fast.
<micahg> heh, here it goes
<infinity> Get out and push, if you have to.
<infinity> MASSAGE THE PHONE LINE.
<slangasek> wat
<infinity> slangasek: Helps squeeze the bits through.
<slangasek> how about acupuncture
 * infinity wonders if he's been doing it wrong all these years.
<infinity> I also lubricate the wall jacks.
<infinity> Just in case.
 * skaet thinks acupuncture could be counter productive in this case ;)
<infinity> Yeah, the bits will spill out.
<infinity> You'll have upload all over the floor.
<infinity> Bad scene.
<skaet> lol
<infinity> micahg: Does this need to be in main for anyone, or is universe fine?
<knome> skaet, #961546 has a new patch, can you ACK?
<micahg> infinity: I think universe is fine as that's where the current binary is
 * infinity grabs the source for a cursory review.
<brendand> Daviey - hey. sorry for the well late pingback. i was trying to gather logs for bug 906311 but apport-collect seems to be failing when i run it
<ubot2`> Launchpad bug 906311 in openquake "jredis error on gemsun03" [High,Fix committed] https://launchpad.net/bugs/906311
<brendand> err bug 960311
<ubot2`> Launchpad bug 960311 in linux "Networking on Dell PowerEdge R300 with Broadcom Corporation NetXtreme BCM5722 Gigabit Ethernet PCI Express is not functional" [High,Incomplete] https://launchpad.net/bugs/960311
<brendand> Daviey, but it's not because the network isn't working :)
<infinity> micahg: I know it's not a widely-used thing, but shouldn't "Recommends: lightdm" be "Enhances: lightdm"? :P
<infinity> micahg: Also, if the postinst calls binaries provided by lightdm, that's just a hard depend.
<skaet> knome,  done.  it was showing fixed release,  have changed it back to in progress..
<smoser> hey, can i get a SRU team member to help please?
<micahg> infinity: looking
<smoser> https://launchpad.net/ubuntu/oneiric/+queue?queue_state=1&queue_text=cloud-init
<smoser> oops
<knome> thanks, we will upload ASAP
<smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/948461
<ubot2`> Launchpad bug 948461 in apt "apt-get hashsum/size mismatch because s3 mirrors don't support http pipelining correctly" [High,Confirmed]
<pitti> skaet: FWIW, not really happy about bug 961606, but it's a sabdfl thing; and we now have a compromise of only adding a tiny installer shim instead of landscape itself, so the impact is as small as we can make it
<ubot2`> Launchpad bug 961606 in ubuntu-meta "[FFE] landscape-client-ui-install package needs to be installed by default on desktop release" [High,Triaged] https://launchpad.net/bugs/961606
<smoser> that needs archive -proposed approval, and every day we don't get it is one day we have to delay the cutting over to S3 mirrors in EC2.
<infinity> micahg: Well, the postinst guards the /usr/lib/lightdm/lightdm-set-defaults call in a -x, but I'd consider that a bit of a bug/misfeature, since it means that package installation order will change if the greeter is enabled.
<infinity> micahg: non-deterministic installation results don't seem like a good idea.
<pitti> skaet: doing the changes now, the package-to-be-uploaded is good enough now (i18n etc.)
<micahg> infinity: right, well, I think it was a recommends rather than a depends so as not to create circular dependencies
<micahg> enhances is a good idea though, I can add that
<infinity> micahg: (ie: without a hard dependency, the greeter could installed before lightdm, the postinst won't fire set-defaults, and it's delivered stillborn)
<infinity> micahg: Where would the circular dep be, if lightdm doesn't depend on it?
<pitti> skaet: for coordination, do you handle the freeze announcement and pinging IS to freeze?
<pitti> skaet: (I'm going to crash soon, long 'nuff day)_
<skaet> pitti,  understood (not happy, but no good options)  thanks for minimizing impact.
<infinity> micahg: Nevermind Enhances.  That made more sense before I looked at what it does.  It really should be a dependency in this case.
<skaet> pitti,  yeah,  I'll put the checklist up on the pad, with what I've done,  and let you double check a few other things.
<infinity> micahg: Or your postinst is non-deterministic.
<micahg> infinity: oh, doesn't exist anymore since lightdm only recommends the greeter, I can make that a hard dependency I guess
<skaet> I'll handle the email, LOSA ping, etc.
<micahg> infinity: wanna reject and I'll fix?
<skaet> some folk that I need to double check some things with are offline, so when you get up.
<infinity> Hrm.  I wonder if unity-greeter has this same postinst issue.
<micahg> infinity: do you think it should still set-defaults command should still be guarded?
<infinity> micahg: No need to guard it if there's a hard dep there.
<micahg> infinity: yes, I think it was C/P from whoever had it first :)
<infinity> micahg: The one in postrm still needs to be guarded, though.
 * infinity considers this a miracle that it works at all.
<infinity> Or maybe it only "works" because most systems don't have both installed, and lightdm DTRT with only one installed?
<micahg> well, once lightdm is installed, it'll work fine
<micahg> infinity: ok, ready with another upload if you like
<knome> skaet, the fix for bug #961546 will be in the next 15-20 minutes :]
<ubot2`> Launchpad bug 961546 in xubuntu-artwork "Xubuntu Plymouth theme shows cut messages" [Undecided,In progress] https://launchpad.net/bugs/961546
<knome> *will be uploaded
<zul> can someone reject the last nova uploaded i just did
<brendand> Daviey, so sorry. lost my connection
 * skaet watches knome to see him skate right up to the wire.... ;)
<stgraber> zul: the archive isn't frozzen yet, so if you uploaded something, it's too late (unless it gets into binary NEW)
<smoser> SpamapS, pitti slangasek ... if someone could look at approving -proposed for https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/948461 i would really appreciate it.
<ubot2`> Launchpad bug 948461 in apt "apt-get hashsum/size mismatch because s3 mirrors don't support http pipelining correctly" [High,Confirmed]
<SpamapS> smoser: sorry juju has preempted you for 3 days now. :-P
<knome> skaet, that's not even close! you should see me in action ;)
<micahg> so, I've got an ubuntustudio package which added a new wallpaper, but the only proof of licensing is an e-mail, do we need a copy of the e-mail in the copyright file or is just the license itself being documented sufficient?
<SpamapS> incoming FFE https://bugs.launchpad.net/ubuntu/+source/juju/+bug/962507
<ubot2`> Launchpad bug 962507 in juju "[FFE] Latest juju snapshot enables maas provider" [Undecided,New]
<SpamapS> Daviey: awake?
<Daviey> SpamapS: always baby
<SpamapS> Daviey: ^^ FFE for juju+maas
<ScottK> pitti: Thanks to LP growing the ability to automatically make bugs confirmed, it wasn't very useful as a state to represent 'approved' anymore.
<pitti> ScottK: right
<pitti> somehow I seem to have forgotten/missed the policy of setting them to "triaged" now
<Daviey> SpamapS: Great.. will review that in a few moments....
<slangasek> smoser: I don't see bug #948461 mentioned in the changelog of the cloud-init uploaded to lucid-proposed, and the changelog also clobbers the previously-uploaded 0.5.10-0ubuntu1.6 which is still in -proposed
<ubot2`> Launchpad bug 948461 in apt "apt-get hashsum/size mismatch because s3 mirrors don't support http pipelining correctly" [High,Confirmed] https://launchpad.net/bugs/948461
<smoser> slangasek, the second part of that is by design.
<smoser> the first part... let me check.
<smoser> the bug number is wrong, slangasek in the changelog.
<smoser> :-(
<smoser> it was in the precise upload and then just copied.
<smoser> should i re-upload each ?
<slangasek> smoser: deliberate> why is that?  is it because the fix for bug #615545 is unnecessary if you're turning up the S3 mirror?
<Daviey> SpamapS:"  merge fix-charm-upgrade "
<ubot2`> Launchpad bug 615545 in cloud-init "Instances launched in a VPC cannot access ec2.archive.ubuntu.com" [Undecided,Fix committed] https://launchpad.net/bugs/615545
<slangasek> smoser: yeah, we'll want a reupload with the right bug #, sorry
<smoser> slangasek, i can do that. no problem.
<slangasek> smoser: rejecting the current uploads
<smoser> regardin ghte othe rbug.
<smoser> amazon has since changed omse things, and the previous fix that was in -proposed no longer actually fixes anything
<smoser> so i dropped it.
<slangasek> ok
<pitti> good night everyone
<micahg> anyone see my licensing question about?
<micahg> *above
<slangasek> night, pitti!
<SpamapS> Daviey: https://code.launchpad.net/~fwereade/juju/fix-charm-upgrade
<Daviey> micahg: You might get better answers tomorrow TBH
<slangasek> micahg: license itself being documented should be sufficient
<slangasek> micahg: I generally don't bother with attaching emails unless there's *conflicting* licensing information in the upstream tarball
<micahg> ok ,thanks
<micahg> Daviey: tomorrow doesn't help me upload before the freeze :)
<Daviey> SpamapS: can you confirm if bootstrap still pulls from lp:juju?
<SpamapS> Daviey: bootstrap has never pulled from lp:juju unless you say 'juju-branch: lp:juju'
<Daviey> SpamapS: hmm, i thought it was a default behaviour whilst things were being stagged.
<Daviey> Is that not the case?
<skaet> good night pitti,  sleep well.
<Daviey> SpamapS: please upload
<infinity> skaet: When are you disabling the crontab?
<skaet> infinity,  we'll leave it going tonight unless you have a compelling reason otherwise.
<skaet> decide on it tomorrow.
<infinity> skaet: Nope, I'm just not going to do a manual arm test-run if cron will do it for me overnight.
<skaet> infinity,  exactly.
<smoser> slangasek, thank you for looking. will upload shortly.
<SpamapS> Daviey: have to add one more commit, the test suite was broken
<infinity> micahg: So, yeah, I suspect the only reason the ubiquity-greeter postinst works as intended (and the gtk-greeter one used to) is because they were probably both installed in the same run, so unpack;unpack;configure;configure.  If that weren't the case, things wouldn't end so well.
<infinity> micahg: Err, unity-greeter, I mean.
<infinity> micahg: I think I'll file a bug on unity-greeter pointing this out.
<Daviey> SpamapS: ok
<SpamapS> Daviey: test build is running
<infinity> micahg: Though, this seems to be standard practice for all of lightdm-*-greeter.  Silly.
<micahg> infinity: like I said copy/paste error
<micahg> skaet: I need another minute or two for the ubuntustudio-meta
<infinity> micahg: Yeah.  I wonder where it started before it cascaded.
<skaet> micahg,  I've put the request in now,  will have to get manually escorted through now I'm afraid.
<micahg> that's fine :)
<jdstrand> skaet: so, I am building and testing an apparmor package that is needed for LXC beta-2. I apologize for the tardiness. it has been verified upstream and I just need to build and do the distro readiness tests. it should be within the hour
<infinity> jdstrand: This will go on your permanent record.
<jdstrand> heh
<skaet> stgraber,  can you turn on the bot?
<stgraber> skaet: you were saying? :)
<skaet> thanks stgraber :)
<skaet> jdstrand, ack.  will keep eye out.
<skaet> builds will be starting at the normal cron job times, so bits landing before then will be picked up.
<phillw> skaet: will tomorrows builds have the finals of the Ubiquity sprint?
<slangasek> phillw: today's do already
<skaet> phillw,  yes
<skaet> :)
<skaet> what slangasek says....  :)
<phillw> slangasek: hmm, http://pad.ubuntu.com/ubuntu-installer-sprint does not have a listing of which ones were closed for today?
<slangasek> phillw: ah, nobody closed out the pad; let me see what I can do about that
<phillw> thanks :)
<smoser> slangasek, 4 new uploads.
<smoser> thank you for reviewing.
<stgraber> phillw: https://launchpad.net/ubuntu/+source/ubiquity/+changelog
<SpamapS> Daviey: looks like the test suite doesn't pass on build.. will have to push past freeze. :-P
<stgraber> phillw: 2.9.32 + 2.9.33 is what we had in today's dailies
<stgraber> phillw: 2.10.0 will be in tomorrow's
<Daviey> SpamapS: it's a bug fix, right?
<phillw> stgraber: thanks.
<slangasek> phillw: documented the upload on the pad now
<adam_g> cjwatson: i imagine its past your EOD but theres a new nova in the queue whenever you get a moment..
<ScottK> I guess that answers my question if I uploaded in time.
<phillw> thanks
<infinity> ScottK: We'll pretend you did.
<ScottK> It's a pretty trivial change.
<ScottK> Thanks.
<SpamapS> Daviey: sorry, internet cut out on me
<SpamapS> Daviey: yes bugs need to be fixed in the test suite
<Daviey> SpamapS: okay, thanks for raising them.  I imagine bugs from hereon tracking issues would be great :)
<SpamapS> Daviey: indeed
<Daviey> Please can maas-enlist and cobbler be accepted.  They are both simple changes.
<Daviey> .. and wanted on the iso tomorrow.
<slangasek> smoser: out of curiosity, why can cloud-init's maintainer script not call "cloud-init-cfg apt-pipelining once-per-instance" in the case where /var/lib/cloud/data/cache/obj.pkl doesn't exist?
<slangasek> smoser: also, it's better form to have a package version check, so that if the user deletes /etc/apt/apt.conf.d/90cloud-init-pipelining locally, a package upgrade doesn't re-add it
<slangasek> -db_input high maas-enlist/warning-note || true
<slangasek> -db_go
<slangasek> +#db_input high maas-enlist/warning-note || true
<slangasek> +#db_go
<slangasek> Daviey: ^^ surely those lines should have been deleted instead?
<slangasek> (maas-enlist)
<Daviey> slangasek: They will be reintroduced before release.
<slangasek> hmm
<slangasek> Daviey: well, not pertinent to the current upload, so approved - but it's generally bad form to use debconf 'note' types
<slangasek> (i.e., they've been considered deprecated for 5 years or so)
<Daviey> slangasek: really?  I didn't know that...
<Daviey> slangasek: do you know that the reboot warning at the end of the installer is of type note?
<Daviey> slangasek: What was it superseeded with?
<slangasek> yes; maybe there are exceptions for the installer, which cjwatson could speak to, but in general you're not supposed to flash pages of text at the user unless you're actually giving them choices
<slangasek> *or* if there's an error condition
<slangasek> Daviey: type: error :)
<Daviey> slangasek: I knew it was not liked, by merrit of http://lintian.debian.org/tags/possible-debconf-note-abuse.html .. but i didn't know it was deprecated
<slangasek> the reasoning is that, if what you're doing is unconditionally displaying a message to the user, there's probably a better way to do that
<slangasek> without interrupting the flow of installation
<Daviey> slangasek: Okay.. i agree with deb maintainer scripts.. but i'd not heard of that in udeb's.. learn every day.
<slangasek> as I said, perhaps exceptions are made for the installer
<Daviey> slangasek: For general packages, where did you read they were deprecated ? http://manpages.ubuntu.com/manpages/precise/man7/debconf-devel.7.html .. suggests they are still OK if it's an urgent matter
<slangasek> Daviey: the manpage words it much less strongly than joeyh did on the mailing list at the time 'error' was introduced :)
<Daviey> slangasek: ah!
<slangasek> Daviey: cobbler> no one's going to be annoyed by you changing this? :)
<slangasek> (accepted)
<Daviey> slangasek: We've left it until now.. As we are comfortable that it's not the largest part of the thing :)
<SpamapS> syncpackage ok for universe unseeded packages?
<slangasek> yes
<SpamapS> slangasek: danke
<SpamapS> or rather
<SpamapS> dekojume moc :)
<SpamapS> dekujume even ;)
<SpamapS> even in czech, I cannot type :-P
 * skaet figures SpamapS gets the sentiment across ...  ;)
<slangasek> nenÃ­ zaÄ
<jdstrand> skaet: a half an hour later than I said, but apparmor is uploaded
<skaet> jdstrand,  :)   that seems to be the trend today,  I think all the folks in the US wish they weren't on DST right now... ;)
<skaet> jdstrand,  there's a copyright in there that looks a bit suspect, but know we want to get it in the builds tonight.   Could you please double check apparmor-2.7.102/utils/aa-exec tomorrow, and update if appropriate to 2012.
 * infinity loves how apt-get dist-upgrade on freeze days brings in so many more upgrades than usual. :P
<skaet> infinity, could you look at: xserver-xorg-video-vmware,  fix landed just landed, and bug just opened, so not sure how well integrated it really is.  looks like something that could impact widely though.
<infinity> skaet: The changelog looks sane, except that I'm not actually seeing the patch being dropped in the diff...
<infinity> Oh, cause the diff is against Debian?  Thanks, Launchpad.
 * infinity checks locally.
<infinity> Oh, I see.
<infinity> It was synced when it shouldn't have been, and this is the cleanup.
<jdstrand> skaet: done and fixed
<infinity> skaet: Looks reasonable to me.
<skaet> thanks jdstrand,  infinity.  :)
<infinity> Accepted curl as well.
 * skaet --> dinner
<Laney> oh, -proposed pre-release works now?
<ajmitch> Laney: apparantly it works during pre-release freezes, so yes
#ubuntu-release 2012-03-23
<smoser> slangasek, sorry, i ran off. yeah, the version check woudl make sense, although realistically, if the user deleted that file, it is an upgrade and they'd have /var/lib/cloud/data/cache/obj.pkl
<smoser> but your way is better, i agree.
<smoser> regarding /var/lib/cloud/data/cache/obj.pkl
<smoser> cloud-init-cfg depends on that file being present (basically, that indicates that there is a cloud data source provided, which is not the case during our image builds)
 * infinity goes to find dinner; back later if people need reviews and such.
 * skaet back from dinner,  seeing builds from daily cron start to emerge on the ISO tracker.... :)
<wgrant> infinity: Do you feel like updating all the archive admin scripts to use a new LP tree?
<wgrant> /srv/launchpad.net/production/launchpad instead of /srv/launchpad.net/codelines/current
<stgraber> ^ that'd be one of mine, universe package, not seeded, bugfix for non-x86 support, would appreciate if someone could let it through
<ScottK> stgraber: ^^
<stgraber> thanks
<ScottK> You're welcome.
 * skaet --> zzz
<pitti> Good morning
 * pitti starts to build langpacks for beta-2
<slangasek> ^^ that's for the lucid-main upgrade bug, if someone wants to let it in
<pitti> !
<pitti> I'll have a look, I soo want to see this fixed :)
<pitti> ^ FTBFS/NBS fix, trivial; approving
<micahg> wow, NBS almost clear
<pitti> slangasek: ... I hate debian/patches/debian-changes
<pitti> micahg: :)
<pitti> slangasek: it seems it kept the patch, but changed the description to the current changelog; that makes no sense at all..
<slangasek> pitti: heh, eew
<slangasek> sorry, I didn't look at the debdiff and assumed the source was generated correctly
<pitti> slangasek: no worries, I was just ranting
<pitti> so that covers the mono side, the bug also has a perl task; I guess we need that as well before the upgrade can work?
<pitti> slangasek: oh, perl for the added Conflict:, I take it?
<slangasek> pitti: yes - so we should wait until mono is built everywhere before uploading the perl change
<pitti> *nod*
<infinity> wgrant: Uhh, what?
<infinity> wgrant: Why gratuitously move the path it deploys to?
<wgrant> infinity: We need two separate trees on cocoplum, since poppy can't be upgraded without downtime. We also need to move cocoplum into line with the rest of the servers circa 2008, so the new nodowntime tree complies with the new naming scheme.
<wgrant> This will let us upgrade cocoplum several times a week, as we do with every other Launchpad server.
<wgrant> Sadly nasty people have shell access on cocoplum, so we have delayed doing this for a while :)
<infinity> >:(
<infinity> Anyhow, you'll want webops to carefully do the cronjob changes, but I can poke around at local scripts and .profiles and such.
<wgrant> Cronjobs are already changed.
<infinity> Oh, I didn't log in and see that this was already done.
<infinity> Thanks for the warning? ;)
<wgrant> The old tree still works for now, but for our deployment schedule to become more sensible we really need everything except poppy to run out of the new tree.
<infinity> Sure.
<pitti> infinity: do you know why so many buildds are on manual?
 * pitti could use some i386 horsepower for the incoming langpack rebuild for b2
<infinity> pitti: Doing some lp-buildd upgrades.  Can the langpack uploads hold off for a short bit?
<infinity> pitti: Those upgrades should make the builds faster.
<infinity> pitti: (I'm also refreshing the chroots, which should make things faster)
<pitti> infinity: oh yes, they are still being generated; upload in an hour or 1.5
<pitti> no panic :)
<pitti> chroot upgrades are appreciated indeed
<pitti> infinity: thanks for the heads-up
<pitti> ^ looks fine and fixes i18n, which I requested for this to be included, accepting
<infinity> pitti: chroots are all freshened, webops are just finishing up with updating lp-buildd for me (though x86 should be all done, which is all you care about)
<infinity> pitti: So, given that we never once actually used the "failed-to-uninstall-deps" return code from sbuild, I just removed the build-dep removal stage in lp-buildd.  Should knock anything from a few seconds to upwards of 5 minutes off some builds.
<astraljava> skaet: folks, sorry for the release mail mess for Xubuntu, it's my first, so be gentle, please. :)
<pitti> infinity: \o/ cheers
<infinity> pitti: I assume you'll want to steal allspice for i386 before you start?
<pitti> infinity: yes, probably two amd64 builders (as long as the queue is empty), and maybe molybdenium, too
<infinity> pitti: Heh.
<infinity> pitti: allspice is like 8 molybdenums anyway.
<pitti> ah, generation of the package is complete; I give them a quick local test, and then upload
<micahg> you can steal lpia for at least 3 hrs, maybe more
<infinity> pitti: My bet is that with the fresh chroots and the new lp-buildd, you'd be happy doing langpacks on just allspice and roseapple.
<infinity> Although, you're German, so I suppose you're never happy.  *duck*
<pitti> looking forward to seeing them in action :)
<pitti> infinity: *smirk*
<pitti> who is able to control the ubottu thing and tell it to STFU for the ~ 800 uploads and 800 approvals?
<infinity> You mean the queuebot?
<pitti> right
<infinity> You may be out of luck, that version's running from stgraber's machine.
<pitti> ah, ok;
<infinity> stgraber: Awake, by any chance? ;)
<pitti> so, brace for impact, upload coming :)
<infinity> Well, if they all hit the queue at the same time, you might get queuebot K-lined.
<infinity> Which would be entertaining.
<micahg> couldn't you mute queuebot in this channel?
<infinity> That would require someone who's an op.
<infinity> pitti might be, pretty sure I'm not.
<pitti> what's the magic incantation again to become op?
<infinity>  /msg chanserv help :P
<infinity> I never remember.
<infinity> Oh, go you.
<pitti> powah
<infinity> Can you add me to the list? ;)
 * pitti <- IRC n00b; if you tell me how :)
<pitti> /msg chanserv quiet #ubuntu-release ubottu
<pitti> does that sound sensible?
<pitti> that's what help quiet says
<infinity> That should do/
<pitti> hah, "you are not authorized to perform this action"
<infinity> I don't recall how to add people to op access lists.
<infinity> Oh, lame.
 * pitti starts the upload anyway
<infinity> You could set the channel +v, and just upload.
<pitti> infinity: I can't
<infinity> Err, +m
<infinity>  /mode #ubuntu-release +m
<pitti> /mode #ubuntu-release +m
<pitti> whatever that just did then
<infinity> That should have set the channel moderated, and only allowed +o and +v people to talk, but clearly not on Freenode.
<pitti> jibel: uh, we should have set that for b1 already, thanks for pointing out
<pitti> ok, commandeered allspice and crested to help out, I left a note in the description
<pitti> let's see how quickly I can accept them before the bot catches them
<pitti> ah, too late
<micahg> pitti: feel free to steal the lpia builder until someone from the security team needs it
<pitti> micahg: ok, thanks
<pitti> 1:30 minutes for a -base pack on allspice, that's great!
<infinity> pitti: So, for comparison, 21 seconds to build a KDE langpack on allspice, 2:20 on older hardware.
<infinity> pitti: That's why I say allspice and roseapple are probably all you care about. :)
<pitti> cool
<pitti> hah, take that queuebot, I slip 2/3 of the packages through without you noticing
<infinity> And there it goes. ;)
<infinity> Okay, I'm pretty happy with the new lp-buildd.  Seeing most of these builds clock at under a minute (which is now almost entirely the chroot tarball unpack) makes me happy.
<infinity> (sbuild reporting builds that took "0:02" is fun)
<micahg> wow, a build in 20 seconds is awesome
<infinity> Yeah.  I could (and should, to reduce PPA load) further optimise the Xen-virt case here.
<infinity> But that's for the next time I feel silly enough to look at lp-buildd for more than 2 minutes.
<ajmitch> not inclined to make it use a modern sbuild?
<infinity> ajmitch: Other than people thinking that would be cool, I have yet to hear a valid reason. :P
<infinity> ajmitch: The current one works.
<ajmitch> backports build-depends on other backports?
<infinity> What does that have to do with sbuild?
<tumbleweed> sbuild's internal dependancy resolver doesn't handle that
<tumbleweed> (well, the ancient one we have)
<infinity> Oh, as in, because of the default pinning for backports?
<ajmitch> yes
<infinity> That's a 2-second fix in lp-buildd to just undo the pinning when building for backports.
<infinity> Is there a bug about this?
<ajmitch> bug #888665
<ubot2`> Launchpad bug 888665 in launchpad "Backports can't build-depend on other backports" [Critical,Triaged] https://launchpad.net/bugs/888665
<infinity> Oh, one I commented on even.  I wonder if I was asleep when I did.
<ajmitch> if it's *that* simple... :)
<infinity> Oh, I kinda mentioned the above, but I don't think my brain fully grasped how easy it would be until we just brought it up now.
<infinity> Ahh, and I forgot the weird "we only want it to use backports for build-deps if required" requirement.
<infinity> That makes it trickier.
<infinity> Yeah, okay, maybe the sbuild switch is the better option, but that's not today. :P
<infinity> ajmitch: Toggling the Automatic thing is almost literally a 2-minute fix (well, modulo the painful rollout process), but yeah, that has the side-effect of backports pulling in ALL of backports, which I think people don't want.
<ajmitch> probably not ideal
<infinity> ajmitch: Or, that's the impression I get here.
<Laney> indeed, the NotAutomatic semantics are what we want
<infinity> Fine.  I'm convinced.  New sbuild it is, at some point.
<infinity> I could take wgrant's branch and hack in support for the bits he missed.
<infinity> But.  No idea when I can commit to that.
<ajmitch> you would deserve many beers for that
<infinity> (I do realise it'll also make home sbuild users feel warm and fuzzy that it's basically the same as the buildds, but that's less of a concern for me)
<wgrant> infinity: It's a bit of a challenge now.
<infinity> wgrant: In what way?
<wgrant> infinity: Because, since my branch, distro sbuild has been refactored significantly into about a thousand pieces.
<infinity> wgrant: Yeah, I've seen that.
<infinity> wgrant: My plan is to remove sbuild from lp-buildd entirely.
<infinity> wgrant: And fork the distro package for LP/IS.
<wgrant> That was my implementation, yes.
<wgrant> I looked maybe 6 months ago at reviving it.
<wgrant> But it was going to prove a challenge to use a post-Lucid sbuild.
<wgrant> You may have better luck.
<micahg> pitti: any reason you haven't grabbed the lpia buildd yet?
<infinity> wgrant: I'll poke it with a stick at some point.
<wgrant> https://code.launchpad.net/~wgrant/ubuntu/lucid/sbuild/extended-result and https://code.launchpad.net/~wgrant/launchpad/use-system-sbuild are relevant.
<infinity> wgrant: I don't think it's as hard as all that, really.  And I can probably get some of the patches into Ubuntu's sbuild (though not Debian's) as command-line options.
<wgrant> Note that the ddeb hack probably needs to be readded.
<infinity> That's not difficult.
<infinity> This was mostly my mess to start with, I'm somewhat familiar with it.
<wgrant> Not difficult, just ugly as hell :)
<infinity> No argument here.
<infinity> What's the blocker on ddebs-in-soyuz?
<infinity> We already do it for PPAs now, right?
<infinity> Do we just need a machine from IS provisioned to publish them?
<wgrant> They need different expiry policies, which means altering the copier to cope with sometimes having expired binaries.
<wgrant> Because otherwise cocoplum and acamar will melt.
<wgrant> And there's also the issue that we've decided the original constraint about forcing them into a separate archive is impractical and unnecessary.
<infinity> It is?
<infinity> This sort of assumes cocoplum gets a ton more space, then.
<pitti> micahg: I think it won't make that much difference after all
<wgrant> It does, yes.
<infinity> And when you say "separate archive", you do just mean on-disk, I hope?
<infinity> Actually, wait.  How is ddebs laid out?
<wgrant> infinity: Right, practically they have to be part of the same Soyuz archive.
<wgrant> I envisage that they will be split like ports is.
<infinity> Err, we can't,
<infinity> Not without changing the implementation everywhere. :/
<infinity> ddebs re-use archive namespace.
<infinity> (ie: dists/precise/binary-amd64/Packages)
<infinity> And we sure as heck aren't adding them to the primary Packages file.
<wgrant> Of course.
<wgrant> But we can work around that.
<wgrant> Like we do with d-i
<wgrant> Component of main/debug, for example.
<infinity> Yes, by "changing the implementation everywhere", like i said. :P
<wgrant> That's roughly 10 lines of code.
<infinity> You're not in a bubble here.
<wgrant> In LP.
<infinity> ddebs has clients.
<infinity> Moving files around breaks them.
<pitti> could we keep transitional symlinks for the old packages.gz locations?
<tumbleweed> putting them in the same archive means mirrors have to carry them
<wgrant> tumbleweed: No
<wgrant> tumbleweed: Like ports, they can be split into a separate archive for mirroring.
<infinity> tumbleweed: No, syncproxy takes care of that.
<tumbleweed> ah
<infinity> pitti: I suppose syncproxy could re-create the old hierarcy and symlink to the new, but ew?
<wgrant> We could do something like the old -commercial hack
<wgrant> Or we could just update the few users' sources.lists...
<pitti> infinity: if we could at least keep a symlink hierarchy for stables, and use the new layout from then on, it'll phase itself out
<wgrant> Right, that's how partner went.
<wgrant> We had a script around for years which mangled partner to dapper-commercial etc.
<infinity> Yeah, I guess it's doable on syncproxy.
<infinity> ln -s installer-i386 debug-i386, go.
<infinity> Err.
<infinity> Somewhere, I had an aneurysm.
<infinity> But you know what I meant.
<infinity> debug-i386 binary-i386
<infinity> Anyhow.
<wgrant> Needs Release mangling as well.
<pitti> this still scares me a bit
<wgrant> But there's precedent for this.
<infinity> wgrant: So, basically, this is waiting on cocoplum being hooked up to the mythical SAN with endless storage.
<wgrant> The SAN is no longer mythical :)
<wgrant> The librarian runs on it.
<pitti> of course mirrors don't have to mirror them all, but they might not expect that change coming, so I guess many of them aren't configured to not mirror the debug- components?
<wgrant> pitti: The mirrors won't see them.
<infinity> pitti: syncproxy.
<wgrant> It's just like ports.
<pitti> aah
<infinity> pitti: It'll split archive/ports/ddebs
<pitti> yes, nevermind me
<infinity> wgrant: And there's no need for release mangling.
<infinity> wgrant: In fact, that would be *wrong*.
<wgrant> My implementation has been proven pretty robust by Linaro and another few PPAs, which is nice.
<wgrant> infinity: Huh?
<infinity> wgrant: Note that http://archive.ubuntu.com/ubuntu/dists/precise/Release includes ports stanzas. :P
<wgrant> infinity: Yeah
<infinity> Oh, but you mean mangling for s/debug/binary/ for old releases.
<infinity> Ugh.
<wgrant> infinity: But if we symlink binary-i386 -> debug-i386, the hashes for binary-i386 will be wrong
<wgrant> Yeah
<infinity> syncproxy doesn't sign things.
<wgrant> No
<wgrant> That's why commercial-compat.sh was on cocoplum.
<micahg> pitti: can you please copy thunderbird 3.1.20 from ubuntu-mozilla-security for lucid-natty to -security please?
<wgrant> Part of LP
<infinity> wgrant: What did that do?  Do I want to know? :)
<pitti> micahg: on it
<pitti> micahg: confirming, !oneiric ?
<micahg> pitti: correct, I should've deleted that one already
<wgrant> infinity: http://pastebin.ubuntu.com/896198/
<infinity> (I'm guessing we'd do something like mangle, write out, and sign a Release-ddebs, and then have syncproxy shuffle the files around as appropriate?)
<micahg> pitti: I mean oneiric was already done :)
<wgrant> Although *-commercial was a different suite, so this just writes a full new Release file...
<infinity> wgrant: Yeah.  My above bit works, though.
<wgrant> Indeed.
<infinity> wgrant: You just create a second release file, sign it, and have syncproxy sort the mess.
<wgrant> We could even sign with a different key if we want.
<wgrant> I guess.
<infinity> (Which sucks, but)
<infinity> No, same key.
<infinity> It should be transparent to the user once moved around.
<pitti> micahg: done
<micahg> pitti: thanks
<wgrant> infinity: It's not the same key now.
<infinity> The only cruft would be Release-foo.* on ftpmaster.
<pitti> yes, but I don't think the current key is very valuable
<pitti> it's only signed by me really
<infinity> wgrant: It's not the same key because pitti can't use the archive key. :P
<infinity> wgrant: That's not a feature.
<pitti> this whole thing was never intended to last for 6 years :)
<wgrant> Heh
<infinity> pitti: Ugh, has it been that long?
<wgrant> It was Edgy :/
<infinity> I feel old.
<wgrant> Anyway, if we take this approach, we just need to work out expiry policies and find an extra terabyte of disk for cocoplum :/
<infinity> wgrant: The disk thing is going to get punted to the SAN.  But worth talking to IS about it again.
<infinity> wgrant: Sorting the LP code sounds like not a lot of work?
<pitti> does macquarie use the SAN?
<infinity> wgrant: And then getting IS to sort syncproxy magic.
<pitti> after all, it has all the ddebs right now
<infinity> pitti: No, if it did, you wouldn't have to keep purging things you don't like.
<pitti> well, we deleted a fair number of them for space reasons, but we can remove them there after theh migration
 * infinity is annoyed that all those removed ddebs are just gone forever.
 * pitti looks at NBS.. http://people.canonical.com/~ubuntu-archive/nbs.html  --- c'mon, we can do that
<infinity> pitti: I dunno.  Removing one package sounds hard.
<pitti> I'll have a go at toonloop (needs porting)
<infinity> pitti: gnome-shell probably just needs a give-back, let me look.
<pitti> infinity: nope
<infinity> pitti: (I suspect it was fallout from clutter being broken)
<pitti> I'll ask jbicha about it in the afternoon
<pitti> no, already tried
<wgrant> infinity: LP can split the indices in about 10 lines of code.
<wgrant> infinity: And moving them back to the primary archive is a matter of deleting code.
<wgrant> Release file mangling is slightly harder, but a bit of awk never hurt anyone...
<infinity> pitti: Oh, it might need some GL->EGL love of its own.
<infinity> rsalveti: Do you love gnome-shell as much as you love clutter? ;)
<infinity> pitti: Anyhow, removing libcogl5 on arm* (once toonloop is fixed) would be fine regardless.  I suspect it's neither installable or runnable right now anyway.
<infinity> (gnome-shell, that is)
<pitti> yeah, presumably
<pitti> but I would at least have a go at toonloop; there's a new upstream release which might help
<pitti> or a trivial backport
<infinity> It's universe, I'd rather sync than carry a diff, if no one's actively watching the package.
<infinity> Which, if it's uninstallable/unbuildable, is probably the case.
<pitti> we are newer than debian already
<infinity> Oh.
<infinity> Fun.
<pitti> it it takes longer than 15 minutes, I'd probably just opt for removing it *shrug*
<infinity> It must have a user.
<Laney> ajmitch: did you get to looking at that haskell stuff?
<infinity> Someone had a pretty cogent rant about willy-nilly removals in Debian a while ago.
<infinity> "Just cause it's not worth your time, doesn't mean you aren't ruining someone else's day."
<wgrant> infinity: Ah
<infinity> pitti: Also, can I pretend that libical's testsuite failure is your fault, since it's in the desktop seed?
<wgrant> 13:37 < wgrant> broder: Sadly precise's sbuild needs libdpkg-perl, which is new in maverick. And new dpkgs don't obviously backport to hardy, which is what most of the buildds run :/
<pitti> infinity: yes, you can
<seb128> infinity, it's my fault in fact
<seb128> I was hopping Debian would fix it
<seb128> slackers
<infinity> wgrant: That's a self-solving problem when the buildds move to precise.
<wgrant> infinity: Ha ha ha hah hahdada
<infinity> wgrant: So, sometime in 2014.
<wgrant> infinity: Lucid supports ia64 and sparc
<wgrant> And Lucid doesn't die until 2015.
<infinity> wgrant: Yes, and?
<infinity> wgrant: I can keep the internal sbuild implementation for old buildds.
<wgrant> Does Lucid run on our ia64 and sparc buildds?
<wgrant> Ah
<infinity> wgrant: We have the power to work magic here. :P
<wgrant> That works too, I guess.
<Daviey> I don't know that ia64 and sparc were also given LTS status..
<wgrant> Daviey: We've never removed an arch post-release before.
<infinity> Daviey: "official" lts status and reality aren't the same thing, don't confuse them.
<micahg> Daviey: they're at least community supported for the duration
<wgrant> We didn't even have support for removing archs until I wrote it at the last minute for maverick. :/
<Daviey> wgrant: heh.. well, i think it needs to be a consideration.. check if those arches were declared long term.
<infinity> No, please dn't.
<infinity> don't*
<infinity> It's a headache.
<micahg> Daviey: no, they weren't
<Daviey> infinity: How is it a headache?
<micahg> Daviey: armel was supported but not LTS
<infinity> Daviey: You're thinking of it in the "I want to kill ia64 nao" sense.  But think of all the 5-year versus 18-month support statuses we have, and staggering dropping arches for no good reason?
<infinity> It's insanity.
<Daviey> infinity: I really fail to see the headache.. we just don't ship non-lts point release iso's.
<Daviey> infinity: No.. hardy still has the pool of desktop open.. doesn't mean it's 'supported'
<infinity> If someone uploads something to lucid, where PPC is no longer supported, do we still build it, but then employ black magic to publish it to old-releases?
<infinity> Daviey: Uhm, ISOs are something we can much more easily just not build.
<infinity> Daviey: And it's a disservice to anyone runinng lucid/ppc (hint: including IS) to just stop building new versions completely.
<Daviey> infinity: what if a sparc SRU ftbfs?  it's the same as it never being built.. ie, not published.
<micahg> Daviey: those ports were community ports from the beginning of Lucid, you can't just remove them
<infinity> Daviey: If it FTBFS, someone might care and fix it, someone might not.
<Daviey> micahg: I'm not suggesting they are removed.. i'm saying, if they are not LTS, they are not LTS :)
<infinity> Daviey: From the "every developer, even the ones Canonical pays, is a community member" perspective, I'd like to think that someone will be the uploader, but sometimes it won't be.
<micahg> Daviey: that only means something as far as canonical support goes
<infinity> Daviey: Err, you were suggesting they be removed.  I was here.
<Daviey> micahg: No, that isn't true..
<infinity> micahg: To be fair, we've now had community discussions about what LTS means (hence community flavours using the term).
<infinity> That said, the "whole community" doesn't agree to anything.
<Daviey> infinity: So.. if i want to SRU a fix for Hardy tomboy.. What will happen?
<infinity> And if I upload one of my packages as an SRU, I expect it to build on every arch.
<infinity> If it doesn't, I'll fix it.
<infinity> And if I'm told I can't have it on an arch that released with that release because someone else doesn't want me to, well.  I know a lot of four-letter words.
<micahg> Daviey: that's a server/desktop split, quite different that selective archs
<Daviey> No.. not at all.
<infinity> Daviey: What do you mean "what will happen"?
<infinity> Daviey: You can SRU tomboy all you like.
<micahg> Daviey: in one case you have no security support for your desktop, in the other case it's best effort
<Daviey> *IF* the arches mentioned were not declared LTS, it's *identical* to the Desktop / Server LTS length split.
<infinity> "LTS is over" doesn't mean "can't upload SRUs anymore", it means that there's no longer a *commitment* to provide SRUs.
<Daviey> infinity: If there was a better distinction between pool for desktop and server, the hardy desktop pool wouldn't still be available
<micahg> I doubt the SRU team would accept an SRU for hardy for a desktop package at this point
<Daviey> right!
<infinity> Daviey: That's a blatant lie, but sure.
<Daviey> infinity: How is it a lie?
<infinity> micahg: I would.  Maybe I should re-join.
<infinity> Daviey: Because it is.  If we broke the packages out, we wouldn't stop publishing them.
<micahg> Daviey: I explained the difference between the two
<infinity> Daviey: Your assumption is an assumption, but you stated it as fact.
<Daviey> This isn't a Canonical/Ubuntu support split.  As a project, we declare a shelf life for different parts of the project.  When that life is expired, the project shouldn't work on expired things.
<infinity> Daviey: Hahaha.
<Daviey> Note, that community flavours are pushing for LTS status.. It's irrelevant to Canonical.
<infinity> Daviey: "As a project", the LTS thing came from Canonical.  That's beginning to change a bit now, but that sure was true for hardy.
<infinity> Either way.  The distintion between "support commitment" and "actively blocking people from working on what they like" is one I'd rather not keep arguing about.
<infinity> If the SRU team rejects an SRU in a still-open release bcause it's on the "wrong" packageset, that's wrong, IMO.
<micahg> Daviey: arch specific retirement only makes sense in terms of active support since the uploads are still happening, it just switches from active commitment to best effort
<Daviey> infinity: well it happens :)
<infinity> Daviey: Example?
<Daviey> pitti: Have an example of an SRU that was nack'd for being Desktop, for an expired LTS?
<infinity> Daviey: And I don't mean rejecting a bug, I mean rejecting a fully-formed, I didn't have to do anything but accept it and mark is verification-needed, SRU.
<infinity> s/is/it/
<micahg> infinity: it's giving people false hope, we shouldn't be updating one part of the desktop when the rest was left to the bandits
<pitti> Daviey: I don't think it ever happened actually
<infinity> micahg: It's not false hope.  By that logic, we should never update a universe package, ever.
<Daviey> infinity: The cost in man hours for an SRU isn't cheap.. Creating a package and dput'ing is probably the cheapest part!
<infinity> micahg: Cause it's "false hope" that the rest of universe will be fixed.
<pitti> it depends on the nature of the change; if it's a truly critical data loss bug I might accept it
<Daviey> pitti: Really, i thought i saw it previously
<pitti> but in general I wouldn't
<micahg> infinity: with a universe package, there support for the main part of the system
<pitti> I even reject most maverick SRUs these days
<infinity> Good thing I accepted my own...
<Daviey> O_o
<Daviey> You are kidding me?
<pitti> then again we actually do accept lucid universe SRUs
<pitti> because lucid has a fairly large user base
<infinity> pitti: So, the policy is somewhat inconsistent. :P
<pitti> infinity: well, that's why we have a human SRU team and not automatic checks :)
<Daviey> pitti: So, if i upload a hardy SRU for tomboy, which fixes an issue where there might be loss of tomyboy notes, would you accept or reject it?
<pitti> we become more and more strict in what we accept over time
<micahg> pitti: re lucid SRUs> no reason not to at this point
<pitti> Daviey: at this point the probability of this is very small
<infinity> pitti: Okay, but when you say "reject an SRU", do you mean "tell the person to just use a newer release, because maverick is EOL soon, but let them argue why they need/want to do this fix" or "flat-out tell them that we don't do maverick SRUs"?
<pitti> Daviey: and I really need to see the concrete bug
<Daviey> pitti: I'm really suprised you'd even consider it, considering desktop hardy is dead.
<pitti> I just can't write down common sense, weighing risk/benefit and the effort/benefit ratios down in two lines
<pitti> Daviey: that's what I'm saying; the bar is very very high, and because it is, I don't remember such a case where it even happened
<infinity> Maybe the SRUs I do are weird cases, but the argument that it's more effort for the SRU team than the uploader is, in my case, very not true.
<infinity> And I don't like the idea of going to the trouble of fixing something to be told "no".
<pitti> infinity: in recent cases I didn't actually get any opposition; most people just said "I uploaded because I uploaded for lucid, too"
<pitti> but maverick survived with these bugs for 17 months
<Daviey> pitti: Right, but i mean - I was told that if the distinction betwee desktop and server was clearer, the pool for desktop of an expired LTS wouldn't still be published.
<pitti> anyone using maverick for that long either has learned to live with the bug, or has abandoned it long ago
<infinity> Daviey: Who told you that?
<Daviey> infinity: Might have been the security team.. i'd have to grep lgos.
<Daviey> logs
<infinity> Turns out that no one small team gets to make those decisions.  Thankfully.
<pitti> Daviey: right; I wish we could move it to old-releases, but that's not techincally possible AFAICS
<infinity> Or we'd have a mostly empty archive.
<infinity> In fact, if we had my way, we'd just ship enough for me to run mutt, irssi, and a compiler.
<Daviey> infinity: mutt or mutt-patched?
<pitti> but even if we had another openssl incident, we still wouldn't fix it in feisty or gutsy any more, even though there are still installations out there
<pitti> somewhere you have to draw the line
<infinity> Daviey: Sidebars are for the weak.
<Daviey> infinity: yeah, i only use them on the weekend.
<infinity> pitti: feisty and gutsy are completely EOL and no longer published.  That's a bit different.
<pitti> infinity: not really from the POV of an installed machine
<pitti> hardy kernel is still being updated, sure
<Daviey> pitti: well it is, because archive.ubuntu.com will not work for them :)
<pitti> but we still don't fix desktop-ish bugs any more
<infinity> pitti: And I think that while listing the support we *commit* to is important, it's silly to say "we shouldn't publish or ever update anything not listed as supported" or, as I say, we should just drop most of universe the day after release.
<pitti> infinity: yes, I agree
<pitti> but in practice it doesn't happen
<pitti> (which is good)
<Daviey> infinity: that is a silly example.. and not what i was suggesting at all
<infinity> Daviey: It's not silly at all.
<pitti> because any hardy desktop SRU that you do is an incredibly high effort for near-zero benefit
<micahg> infinity: that's not the point, the point is that the main env isn't supported anymore
<pitti> same for maverick
<infinity> Daviey: You're suggesting that once an 18-month package set in a 5-year release is EOL, it should be dropped (if it were technically feasible).
<Daviey> infinity: you are implying that i what i was suggesting is akin to dropping universe after release?
<Daviey> infinity: Yes!  That *is* what i am suggesting.
<infinity> Daviey: I'm suggesting that, by that logic, universe (except for the packagesets owned by derivatives who commited to support) should be dropped.
<micahg> infinity: well, at least my point :)
<Daviey> As a project, we declare the lifetime of a release, with given parameters.. after that date, having *any* updates, is nonsense.
 * micahg is beginning to see where infinity is going with this :)
<infinity> Daviey: We delcare exactly zero post-release support for universe, outside of derivative packagesets.
<pitti> well, I don't go as far as "nonsense"
<Daviey> infinity: You are being too accurate.. as a Supported server *will* include universe packages.
<pitti> but we need a damn good reason for doing them
<Daviey> But *willnot* include gnome. :)
<infinity> Daviey: I'm not being too accurate, you're being too focused on your own perceived problem and applying it too broadly.
<pitti> but really, where's the problem
<infinity> Daviey: At the end of the day, the status quo is fine.
<pitti> we are not exactly rejecting 10 hardy SRUs every day
<pitti> we hardly get any at all
<micahg> Daviey: yes, those groupings are desktop and server (who does what when is an implementation detail)
<infinity> Daviey: And the fact that we still build LTS updates for non-LTS arches is, also, fine.
<Daviey> pitti: You think it's a good use of the SRU team, and those validating to even consider an SRU for something we declared at the release point, will not be supported by either the project or Canonical?
<ogra_> and luckily that "problem" will be gone with 12.04 where desktop and server have the same lifetime
<infinity> ogra_: Nah, cause some desktops are only going 3 years.
<pitti> Daviey: as I said, if we actually had the problem of reviewing and rejecting hardy SRUs, I'd also stir some trouble; but we don't
<micahg> ogra_: yes, that's the one good thing about the synergy
<Daviey> infinity: this discussion started, as we were discussing dropping of two arches which we are not convinced were delcared LTS. Sparc and ia64
<pitti> in general, developer's interest in old releasese diminishes fast enough for that problem to fix itself just nicely
<infinity> ogra_: And unsupported arches are only 18 months.  And, and.  This is where Daviey gets his knickers in a twist.
<micahg> infinity: yes, but the archive as a whole is 5yr
<infinity> micahg: That's patently untrue.
<micahg> infinity: again who does what when is an implementation detail
<pitti> Daviey: but assuming that it was the case, then no, it's not a good use of the SRU team's time
<ogra_> infinity, but you still cant say "desktop isnt LTS anymore" ... there will likely be a few packages for derivatives that arent LTS, but still
<micahg> infinity: I mean as in community supported to the extent you can say anything is
<infinity> micahg: Sure, but that's true of the things Daviey thinks should be dropped too.  That was kinda my point.
<ogra_> and wrt arches ... if it builds it builds ... i doubt anyone will remove an arm binary from the archive just because
<infinity> micahg: We either drop all !packageset universe, or we let people SRU it if they want.  Architectures are the same.
<micahg> infinity: yes, which is why I said I see where you're going and stopped arguing with you for the most part :)
<ogra_> (and if it doesnt build and is actually still used the community will scream and likely also help)
<micahg> infinity: I still thing the server/desktop distinction makes sense pre-precise
<infinity> Daviey: Anyhow.  Things are fine.  This argument was pointless.  Go have a smoke and calm down.
<infinity> micahg: From a "support expectation" (and commitment) perspective, lots of these distinctions make sense.
<infinity> micahg: I think enforcing it at the archive level (and actively preventing people from scratching their own itch) is lunacy.
<infinity> And, I'll note, I SRU into older releases when I feel the urge and no one tells me no.  But maybe I'm a unique snowflake.  I dunno.
<micahg> infinity: scratching one's own itch makes sense where there's a base supported system
<Daviey> infinity: Oh i'm good.. I'd just rather pitti find out why the heck my right click doesn't work in precise, than work on expired releases :)
<infinity> micahg: There's a "base supported system" right up until we close the release to uploads.
<infinity> Daviey: You need a new mouse.
<pitti> Daviey: WFM :)
<infinity> Daviey: Works here.
<Daviey> infinity: You don't really accept your own SRU's do you?
<micahg> infinity: for servers, yes, but not for desktops, and I mean security support really :)
<infinity> Daviey: Oh, only one specific package, which has a disturbing policy exception.
<Daviey> pitti: I have a shiney silver laptop, with a fruit on the lid.. which seems less than happy :)
<infinity> Daviey: (But I did have other people test it)
<pitti> Daviey: oh, I thought these wouldn't have right mouse buttons in the first place :)
<infinity> Daviey: Oh, your problem is that you onle have one mouse button.
<Daviey> gah
<infinity> Damn, pitti beat me to it.
<infinity> s/onle/only/
 * ogra_ right clicks on Daviey on his arm netbook ... 
<infinity> http://img.chan4chan.com/img/2009-02-08/1234107430946.jpg
<ogra_> Daviey, works here, get better hardware ;)
<Daviey> heh
<Daviey> running this every hour or so, seems to work :)
<Daviey> $ grep -i rightclick ~/.bashrc
<Daviey> alias rightclick="xinput --set-prop 12 259 0"
<ogra_> wow, you make your rightclik work by running grep ? thats cool
 * ogra_ didnt know grep was that powerful
<Daviey> ogra_: it has architecture specific build options, and it's disabled for arm - as it can't handle it. :)
<ogra_> haha
 * infinity decides he needs a nap.
<pitti> I'm uploading a new ubuntu-defaults-builder
<infinity> pitti: Need it reviewed?
<pitti> our Italian friends want this for beta-2 to build their Italian Edition without oversizing
<pitti> the potential worst-case impact is breaking the Chinese Edition
<infinity> stgraber: When you wake up, we might need queuebot back.  pitti flooded it off the server. ;)
<pitti> oh, did it?
<infinity> 03:07 -!- queuebot [~queuebot@dakara.stgraber.org] has quit [Excess Flood]
<pitti> it only actually saw maybe 10% of the uploads
<infinity> pitti: Want to pastebin me a debdiff, and I'll review now before I go to sleep, and you can self-accept.
<pitti> infinity: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/ubuntu-defaults-builder/precise/revision/135
 * infinity doesn't feel like waiting for LP.
<infinity> pitti: I prefer debdiffs to be sure they're clean, but I'll take your word for it that you know how to build source packages and compare them. ;)
 * infinity looks at the bzr diff.
<pitti> infinity: the only other commit is http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/ubuntu-defaults-builder/precise/revision/136
<pitti> infinity: sure: http://paste.ubuntu.com/896271/
<infinity> pitti: That's an odd way to write that.
<infinity> pitti: Why not filter components first, and then construct the list in a loop?
<pitti> infinity: indeed, a --delete-apt-components woudl have been easier
<pitti> infinity: that would be even more code; but I'm open to clever ideas
<pitti> negating sets in posix shell isn't exactly elegant
<infinity> It's just a for/case loop to drop things out of the set, and then a for loop to construct the removal list with the remaining bits.
<infinity> echo | grep -v just feels icky.
<pitti> infinity: how do you drop things out of a set without echo | grep -v?
<Daviey> ev: Does server-ship *really* need whoopsie?
<pitti> infinity: I guess you can use join
<pitti> phone, bbl
<Daviey> elmo: Are you going to be unhappy if zsh isn't shipped on the server on-cd-archive?
<ev> Daviey: it would be nice if we had crash reporting across all Ubuntu products
<ev> Daviey: but I'm happy to fight you to the death if you disagree
<Daviey> ev: No, it's currently just in the on-cd-archive.. not installed..
<ev> oh, whoops
 * ev digs
<Daviey> ev: I also want the same, but trying to shave space off the cd for thigns that might be required at install time
<Daviey> oh no, you put it in server-ship and server
<Daviey> ev: forget i said anything :)
<ev> Daviey: always ;)
<didrocks> pitti: ok, so, FYI
<didrocks> pitti: we got some issues from yesterday
<didrocks> with some hangs on some hardware (~8 machines on more than 30 testers)
<didrocks> we workarounded it it
<didrocks> the hang is fixed on 7 machines on the 8
<didrocks> but, 1 of them (and the other getting the hang) sees graphical issues
<didrocks> not quite sure yet
<didrocks> but seems sandybridge on amd64 related
<didrocks> with distro build flags
<didrocks> some track is that it can be related to i915.i915_enable_rc6=1
<didrocks> on the kernel
<didrocks> but at the end, we have some machines with eventually graphical corruptions
<didrocks> seems to be a really few of them (not all sandybridge have that issue)
<didrocks> so, my proposal is still to release
<didrocks> opening a critical bug about that issue
<didrocks> put it on the release note
<didrocks> and ensuring the guys work on that at the top priority
<didrocks> (the graphical issue is triggered by compiz, we tried new compiz + old unity rebuild to confirm)
<tseliot> can anybody approve fglrx-installer and fglrx-installer-updates in precise, please? They are not on the cd image
<stgraber> infinity: fixed ;)
<stgraber> I should make the bot detect these and just show "150 language-packs" instead of showing every one of them
<ogra_> ++
<ogra_> doesnt the ML have such a function already ?
<ogra_> (-changes that is)
<infinity> ogra_: LP just special-cases launguage-pack* and doesn't send the announce to -changes.
<infinity> stgraber: queuebot not announcing at all would be perfectly fine and in line with that.
<ogra_> now that was a short nap !
<infinity> I had a shower first.
<infinity> Nap now.
<infinity> Bye. :P
<ogra_> sleep well
<stgraber> infinity: done
<ev> ^ would someone be so kind as to let that through
<pitti> didrocks: oh, I thought we disabled rc6 on sandybridge again?
<pitti> didrocks: I agree, it seems better to test the new versino on a bigger scale
<didrocks> pitti: not that, more experience showed it's not this case though
<didrocks> so it's ruled out
<didrocks> pitti: ok, I'm making the release now
<didrocks> pitti: do you want me to push things in on shot?
<pitti> on shot?
<didrocks> pitti: or wait that one is built before the other
<pitti> didrocks: just go ahead and upload to -proposed, I'll feed it through the queue
<pitti> didrocks: ah
<pitti> didrocks: they are build-dep'ing on each other, right?
<didrocks> right
<pitti> didrocks: so, just dump them all in and let depwait sort it out
<didrocks> so arch: matching issue
<pitti> it's -proposed, it won't break anyone's install
<didrocks> pitti: yeah, but we have the "â¦ is not installable"
<didrocks> and have to retry ;)
<pitti> ah
<didrocks> because of arch mistmatching
<pitti> didrocks: well, as you wish; whatever is easier/better for you
<didrocks> not sure how to keep the overhead low
<didrocks> pitti: ok, I'll push and poke you about what to accept
<pitti> didrocks: thanks
<didrocks> fixing some upstream files not disted in the tarball first
<pitti> crested and allspice returned to normal amd64 dity
<pitti> duty
<pitti> that was darn fast for a full langpack build
<pitti> tseliot: done
<cjwatson> wgrant,infinity: I fixed bin/* and .bashrc for the codelines/current -> production/launchpad change
 * cjwatson restarts all his screened lp_archive shells to get an updated $PATH
<wgrant> cjwatson: Thanks.
<didrocks> pitti: compiz is here ^
<pitti> yup, already looking at changelog :)
<pitti> didrocks: does it change anything in the packaging?
<pitti> aah, /me gets a debdiff on cocoplum
<didrocks> pitti: not that I can remember (apart some more distro-patch)
<pitti> right, not even a soname bump or so
<didrocks> no, there is an ABI break, but there is no soname to bump
<didrocks> it's the file mentionning the abi version
<didrocks> picked and creating a virtual package
<didrocks> (and packages that dep on compiz will dep on this virtual package as well)
<pitti> accepted
 * pitti hands didrocks the prize for the first-ever precise-proposed upload
<didrocks> \o/
<didrocks> thanks pitti ;)
<didrocks> uploaded libcompizconfig now, but we may want to wait for compiz to be built to avoid build to relauncher because of unsynced arch
<didrocks> pitti: there is a version bump here because sil2100 released an intermediate version in a testing ppa without ~ppa1 so it's for those transitions :)
<didrocks> pushing c-p-m now, need to wait on compiz and libcompizconfig (which is included inside compiz) to be built
<didrocks> compiz-plugins-extra incoming (build-dep on latest compiz and compiz-plugins-main)
<tseliot> pitti: thanks a lot!
<cjwatson> ev: done
<skaet> good morning
<stgraber> skaet: good morning
 * skaet sees that precise-proposed is now being used...  :)
<cjwatson> still only possible during freeze though
<cjwatson> didrocks: oh, damn, I'm really sorry, I missed what you said above
<didrocks> pitti: bamf and libunity can be accepted straight away
<cjwatson> compiz hasn't been published on armel/armhf yet :-/
<didrocks> cjwatson: no worry ;) will just need to ask for rebuilding on those arch :)
<cjwatson> I might be able to rescue this by scoring those builds through the floor
<didrocks> it's just to avoid having too many FTBFS
<cjwatson> too late, they've already started
<didrocks> and have to respawn the build
<didrocks> waow, that's fast
<cjwatson> so sorry, you'll have to reupload libcompizconfig - feel free to blame me
<didrocks> cjwatson: hum, why reupload?
<didrocks> cjwatson: the build-dep is correct
<cjwatson> oh, they have a build-dep, don't they
<didrocks> right
<cjwatson> ok, great
<didrocks> it's just that it will FTBFS
<didrocks> as -dev is published
<didrocks> but can't install the rest
<cjwatson> which is not a problem.  ok
<cjwatson> no, -dev is arch-dependent too
<cjwatson> compiz-dev | 1:0.9.7.2-0ubuntu1 | precise-proposed | amd64, i386, powerpc
<didrocks> cjwatson: oh that's fine then ;)
<didrocks> I remember they are some cases when I got FTBFS because of arch skew
<didrocks> it's just to avoid the amount of retry to have to be done, I always ensure the build-dep are correct
<didrocks> that*
<cjwatson> yep, they're going into dep-wait now
<didrocks> great :)
<didrocks> nux is safe to accept right away ^
<ev> cjwatson: cheers
<pitti> looking into bamf, nux, libunity
<didrocks> ok, just uploaded unity. It can be built once compiz-dev libcompizconfig0-dev and nux are built (libnux-2.0-dev is arch:any)
<didrocks> don't freak out on the inline patch, it's bzr merge ../upstream
<pitti> https://launchpad.net/ubuntu/+source/libcompizconfig/0.9.7.0~bzr428-0ubuntu6 is properly depwaiting, seems alright
<pitti> didrocks: ^
<didrocks> pitti: yeah, the isses comes on c-p-m IIRC if you install both, as then compiz-dev is pulling libcompizconfig0-dev back
<pitti> didrocks: does c-p-extra need compiz only, or also compizconfig?
<didrocks> circular dep on compiz
<didrocks> c-p-extra needs compiz, compizconfig and c-p-m
<pitti> didrocks: ah, good
<didrocks> so basically, libcompizconfig0-dev is dep on itself (because compiz-dev pulls it) to build
<didrocks> and then it's an nightmare for all plugins
<didrocks> I know that upstream wants to merge compiz and compizconfig at some point
<didrocks> dee and file lens are fine to accept whenever you want
<pitti> done
<ev> ^ hello again. I think this fixes the memory corruption bug in whoopsie.
<ev> And I would greatly appreciate an approval
<cjwatson> ev: personally I would have done the close (fd) in src/utils.c after the fd < 0 test, but it doesn't cause a real problem.  Otherwise seems fair enough - approved, thanks
<ev> cjwatson: for aesthetic reasons?
<ev> and cheers
<cjwatson> ev: saves a syscall that's going to fail anyway
<cjwatson> and saves your future self looking at strace and wondering what that EBADF is doing there :)
<ev> so something like http://paste.ubuntu.com/896490/ then?
<didrocks> so unity-lens-music and unity-lens-applications uploaded
<didrocks> u-l-m build-dep on latest dee FYI
<didrocks> thanks pitti ;)
<ev> oops, that upload was busted
<ev> I'll actually run it through pbuilder this time
<cjwatson> ev: yes
<cjwatson> s/pbuilder/sbuild/ :-P
<cjwatson> (doesn't bore you to death unpacking tarballs)
<pitti> didrocks: ah, libcompizconfig built on arms
<didrocks> nice ;)
<didrocks> you can start c-p-m and eventually unity if nux is built
<pitti> still needs publishing
<ev> cjwatson: hmm, I'll have to give that a try
<cjwatson> it's a bit more setup (not much more complex than pbuilder really, but you have to do it all over again); but mk-sbuild really helps and it's much more efficient thereafter with overlayfs
<ev> is the overlayfs stuff documented somewhere?
<ev> oh, mk-sbuild
<ev> gotcha
<ev> ^ :)
<ev> fixes the FTBFS
<cjwatson> ev: mk-sbuild does it out of the box; the configuration variable it uses is documented in schroot.conf(5)
<ev> cheers
<didrocks> ^ I expose in g-c-c the new options related to latest unity mutimonitor behavior, that's why I pushed it in -proposed as well (makes more sense to avoid "this option doesn't work" feedback ;))
<ogra_> skaet, how did bug 856988 end up assigned to ubuntu-arm (or why)
<ubot2`> Launchpad bug 856988 in gstreamer0.10 "totem cannot play quicktime file after upgrade to oneiric" [High,Confirmed] https://launchpad.net/bugs/856988
<ogra_> seesm to cleartly be an amd64 desktop bug
<skaet> ogra_ will look at after the meeting.
<ogra_> great, thanks !
<ogra_> oh, /me totally missed the meeting is running, sorry for disrupting...
<pitti> seb128: did yo hear anything about a new wallpaper by chance?
<seb128> pitti, no I didn't, I assume there is none?
<pitti> right, that's sorta my question; I guess I'll ask the design guys
<seb128> yeah, good diea
<seb128> idea
<pitti> ah, Cimi seems to be on it, nevermind
<pitti> kenvandine: Riddell says you should talk to shadeslayer about telepathy-qt4
<Riddell> cos there's a new version out and he wants it in
<Riddell> and the new version is out because of the farsight change
<kenvandine> Riddell, there isn't a new tarball yet
<kenvandine> i pinged upstream to get an eta on that
<Riddell> kenvandine: aah
<kenvandine> i saw the farstream port was merged in git though
<kenvandine> so i assume it is coming soon
<Riddell> kenvandine: http://lists.freedesktop.org/archives/telepathy/2012-March/006022.html
<Riddell> which I haven't read
<kenvandine> oh
<kenvandine> it is  out
<pitti> didrocks: oh, he's back!
<didrocks> yeah, just pushed unity-2d, which is the last of the family :)
<kenvandine> Riddell, oh.. the moved the releases url, damn
<pitti> erk, sorry, I realize this is -release; I meant to speak on #-desktop
<didrocks> build-dep on latest nux and libunity-core (unity)
<pitti> I reordered my IRC columns for the meeting
<didrocks> :)
<kenvandine> shadeslayer, do you want me to do the telepathy-qt update to 0.9.1 or are you doing it?
<pitti> didrocks: anyway, back on release topic
<pitti> didrocks: libcompizconfig built, nux publishing
<pitti> didrocks: I can do c-p-main now, right?
<didrocks> right!
<pitti> err, s/built/published/
<didrocks> once nux is there, you can go ahead with unity
<didrocks> (didn't see if g-c-c was accepted yet btw)
<pitti> didrocks: and the lenses should be fine now, too?
<didrocks> yeah, just the -music ones dep on latest dee
<didrocks> one*
<shadeslayer> kenvandine: feel free to do it
<shadeslayer> kenvandine: It was on my todo for tomorrow
<kenvandine> shadeslayer, ok
<shadeslayer> kind of on a coding kick right now :P
<kenvandine> shadeslayer, ok, i'm on it
<shadeslayer> awesome
<pitti> didrocks: ^ that doesn't depend on any nux & friends, right?
<didrocks> pitti: unity-2d?
<didrocks> 16:11:07    didrocks | build-dep on latest nux and libunity-core (unity)
<pitti> ah, ok
<didrocks> pitti: see why I regularly complain about ABI break and chain dependency? :-)
<didrocks> compiz -> libcompizconfig -> unity -> unity-2d is the longest chain
<didrocks> (but you can have libunity| nux -> unity -> (nux|) unity-2d)
<ogra_> juts merge all of it into one big package (like kde in the past) ;)
<didrocks> (and you can replace libunity by bamf as well in the schema, adding bamf-qtâ¦ :p)
<didrocks> or dee and add the lenses ;)
<didrocks> ogra_: all staticly linked? ;)
<didrocks> and then rewrite on go!
<ogra_> yay
<ogra_> thats the future !
<didrocks> do not forget the gconf backend fix as well (just pushed) ;)
<didrocks> compiz gconf backend
<pitti> didrocks: nux is published; triggering unity
<didrocks> great ;)
 * cjwatson giggles at http://raphaelhertzog.com/2012/03/23/people-behind-debian-joerg-jaspert/ - "I do want to train it to like pressing the M key, so little-Ganneff can deal with NEW all on its own (M being Manual reject)"
<cjwatson> I should do that
<stgraber> :)
<Laney> first word: "NACK"
<skaet> ogra_, re: 856988,  was a mistake on my part, was late, sorry.
<ogra_> skaet, great, thought so
<slangasek> ^^ that perl is the other half of bug #948848.
<ubot2`> Launchpad bug 948848 in mono "cil packages fail to uninstall on lucid->precise upgrade due to prerm script use of perl-modules via /usr/share/cli-common/gac-package-remove -> /usr/share/cli-common/runtimes.d/mono (Can't locate File/Basename.pm in @INC)" [High,Fix released] https://launchpad.net/bugs/948848
<slangasek> jibel will be happy to have it in, I think :)
<slangasek> oh, and I think the mono build on armel took out the buildd
<slangasek> who can stab that for me?
<slangasek> (I've spot-checked the build log twice now over a span of an hour and a half, and it doesn't look like it's progressed)
<slangasek> lamont: ^^ ?
<jibel> slangasek, I am happy \o/ thanks
<skaet> :)
<slangasek> jibel: then we'll be able to see the NEXT upgrade failure bug in the stack ;)
<brendand> skaet, ping
<skaet> hiya brendand
<brendand> skaet, we verified https://launchpad.net/bugs/888219 is fixed
<ubot2`> Launchpad bug 888219 in linux "[ThinkPad E420] Wifi is always soft blocked" [High,Confirmed]
<brendand> eh, wrong one. haha
<brendand> this one: https://launchpad.net/bugs/882253
<ubot2`> Launchpad bug 882253 in linux "[Thinkpad E520] SDHC card unable to be mounted" [High,Incomplete]
<brendand> skaet, the other one we are verifying now
<skaet> brendand,  good news.  :)
<skaet> apw,  ^
<skaet> Thank you.  :)
<apw> skaet, brendand, great, have marked 882253 as Fix Release in P
<brendand> skaet, apw - i'll ping you over the status of the E420 wifi bug if i get it by the end of the day
<skaet> thanks brendand
<cjwatson> pitti: ^- maybe you could look at localechooser, since we'd discussed that; that's the first half of the change, there's a corresponding change to ubiquity once that's in
<cjwatson> (also an FTBFS fix in ubiquity)
<pitti> cjwatson: sure, thank you
<cjwatson> pitti: any luck?
<cjwatson> sorry, just want to get ubiquity sorted
<pitti> sorry, waited a bit for diff, looking now
<cjwatson> ah, ok
<pitti> that looks spot-on, thanks
<slangasek> pitti, cjwatson: could either of you review the perl upload?
<pitti> cjwatson: so LOCALE_TRANSLATIONS is the language, and $LOCALE the region bit, right?
<pitti> slangasek: yep, can do; that was for the new conflicts:, I suppose
<cjwatson> pitti: right
<slangasek> pitti: exactly
<pitti> cjwatson: accepted
<pitti> slangasek: let's hope that apt's resolver groks that :)
<brendand> skaet, apw - yep, bug 888219 fixed too!
<cjwatson> great.  I'll prepare a new ubiquity the cheating way (I have the source package locally, no need to wait for it ...)
<ubot2`> Launchpad bug 888219 in linux "[ThinkPad E420] Wifi is always soft blocked" [High,Confirmed] https://launchpad.net/bugs/888219
<slangasek> pitti: if it doesn't, we can roll back and do the SRU that cjwatson didn't want
<pitti> mono-gac has a large dependency chain
<apw> skaet, i've closed 888219 off as Fix Released too
<mdeslaur> skaet, slangasek: can I upload a fix for bug #962378
<ubot2`> Launchpad bug 962378 in ca-certificates-java "multiarch broke circular dependency workaround" [High,Confirmed] https://launchpad.net/bugs/962378
<pitti> slangasek: anyway, it can't break installs, so I'm fine with accepting this now
<slangasek> pitti: also, can you do something about the broken armel build of mono?  It's stalled out
<cjwatson> it wasn't that large
<cjwatson> and it was mostly mono libraries, rather than anything involving perl
<pitti> slangasek: sorry, I can't; that's IS matter
<slangasek> mdeslaur: yes please
<slangasek> pitti: you can't kill the build and let it get picked up on another builder?
<pitti> that reminds me that I was to remind infinity to eventually implement the Cancel button for distro builders :)
<slangasek> ok
<pitti> slangasek: no, only for PPAs
<slangasek> infinity: wake up :P
<pitti> I can reassign builders
<mdeslaur> slangasek: thanks, done.
<pitti> and give back/prioritize, etc.
<pitti> or tell an amd64 builders to build i386 instead, or something
<pitti> but Cancel isn't implemented in the web UI
<pitti> slangasek: actually vanguard in #is should be able to
<skaet> mdeslaur, what slangasek says.  :)  thanks
<mdeslaur> skaet: thanks
<slangasek> pitti: wow, did you notice that my conflicts version comparison was wrong for 2 of 3 packages in that perl upload? :/
<slangasek> (I just noticed it now because I was going to edit the diff for submission to Debian)
<pitti> slangasek: argh Friday evening/hectic blindness :/
<slangasek> pitti: it shouldn't matter in practice since the only version the check is wrong for will soon be unavailable in the Ubuntu archive
<pitti> right
<pitti> *phew*
<pitti> missing ubuntu1
<pitti> ^ if someone coudl review this, didrocks will pay him a beer
<pitti> seb128: ugh @ indicator-appmenu "rewrite half of the code"
<pitti> seb128: how much testing did that get?
<didrocks> pitti: I'll pay you one as well!
<pitti> didrocks: c-p-main published
<didrocks> great ;)
<pitti> didrocks: accepting c-p-extra
<didrocks> yeah
<didrocks> thanks!
<pitti> still waiting for unity/armel for unity-2d
<pitti> didrocks: I need to leave in about 20 minutes, so someone else would need to do that then
<didrocks> and makes the pocket copy?
<pitti> that, too
<pitti> didrocks: you can also do it yourself
<pitti> didrocks: sru-release precise compiz unity whatnot...
<pitti> from lp:ubuntu-archive-tools
<didrocks> pitti: from cocoplum?
<didrocks> or my machine?
<pitti> didrocks: no, from your box
<pitti> lplib
<didrocks> ok, that will close the bugs as well, isn't it?
<pitti> didrocks: if you are uncomfortable with that, just tell someone here the list of packages
<pitti> they should all be copied in one go
<pitti> didrocks: yes
<didrocks> ok, and appearing on the ML I guess
<pitti> didrocks: they will appear twice
<pitti> didrocks: they appeared for -proposed already
<pitti> and they will appear again when copying, under the name of whoever runs the script
<didrocks> ok ;) I won't freak out then
<pitti> so do it yourself, otherwise you won't get all the bug count :)
 * didrocks rushes ;)
<didrocks> let's wait for unity armel to be fine
<didrocks> to start pocking for 2d :)
<pitti> that said, let me do it! that'll give me a nice jump in front of seb
<pitti> seb128: ah, saw your ping in -desktop
<didrocks> pitti: depends on how much beer you will pay me then! :)
<lamont> slangasek: anyone in webops is the new target for machine smackery
<slangasek> ok
<infinity> slangasek: Don't wanna.
<slangasek> oh, well all right then
<slangasek> also, #is is on it
<infinity> Oh, dang.  I just caught the tail end of that.
<infinity> Would have liked to see ps output from that machine before people started killing willy-nilly.
<didrocks> pitti: launchpad is seeing armel being built, can you poke unity-2d?
<pitti>     unity | 5.8.0-0ubuntu1 | precise-proposed | source, amd64, armel, armhf, i386, powerpc
<pitti> didrocks: accepted
<didrocks> thanks pitti :)
<didrocks> will wait for it to build/publish on every arch
<didrocks> and then do the publishing, I have the list here
<pitti> so, need to leave now, sorry
<pitti> didrocks: FYI, if you run sru-release, they will appear in https://launchpad.net/ubuntu/precise/+queue?queue_state=1
<pitti> didrocks: you will have to accept them from there to really get them copied
<pitti> didrocks: they will appear as syncs
<didrocks> pitti: ah ok, will do! :)
<pitti> good night everyone, have a nice weekend!
<pitti> didrocks: it tells you so, and the link, don't worry
<didrocks> have a good night and good week-end pitti, thanks again ;)
<didrocks> ok ;)
<seb128> re
<skaet> good night pitti.
<seb128> pitti, hey, it's not "half the code", it's an hundred line and pretty much easy code ;-)
<seb128> pitti, 'nighty
<micahg> pitti: cancel button in the archive UI is a bad idea unless they fix the you can't retry a canceled build issue
<infinity> micahg: There are two different "cancels", one of which kills builds, the other completely blacklists it.
<infinity> micahg: I don't really know who thought implementing the latter was a good idea. :P
<infinity> micahg: (The latter could have uses for a build that is known to break machines, or something, but it should be pretty clearly marked as dangerous, and available to a limited set of pepole)
<infinity> micahg: Anyhow, hooking up proper build abort semantics would be the softer version. :P
<didrocks> cjwatson: hum, I need to look at the sru-release script, it wants to copy to -updates
<didrocks> pitti: ^
<rsalveti> infinity: haha, not that much, but I can check
<rsalveti> infinity: what is the issue with gnome-shell?
<cjwatson> didrocks: mm, yeah.  you could cowboy http://paste.ubuntu.com/896797/ for now.
<infinity> rsalveti: Looks like more GL versus EGL hatred.
<rsalveti> infinity: ok, will take a look
<didrocks> cjwatson: right, hwat I just did :)
<didrocks> cjwatson: I'll have a cleaner version for later :)
 * cjwatson nods
<didrocks> cjwatson: thanks for confirming
<didrocks> ok, the queue didn't seem to yell, let me copy the other before syncing everyone in a row
<didrocks> ok, time to copy that to the Release pocket :)
<cjwatson> looks plausible enough to me
<cjwatson> all the binaries built in -proposed?
<didrocks> cjwatson: right, all were built (was waiting on unity-2d)
<didrocks> seems to have worked
<didrocks> just need a publisher round I guess?
<skaet> cjwatson, is that bulk of removeds the copy over from -proposed to -release?
<cjwatson> skaet: yes
<cjwatson> didrocks: yes
<didrocks> ok, I'll stay around and have a look to ensure all is fine/published :)
<slangasek> is this related to the most recent upgrade autotest failure involving compiz-core-abiversion-20120228, by chance?
<cjwatson> not sure why gnome-control-center and nux aren't listed as removed, but I'm going to assume that's a bot glitch since they're gone from the queue itself
<didrocks> slangasek: hum, I didn't see that one. We didn't get any unsync from what I know?
<didrocks> cjwatson: I guess so
<didrocks> slangasek: if people are using third party packages (like the wallitâ¦smothing package) from a ppa, there can have some ABI mismatch
<didrocks> if it's the automated upgrade tests, we have an issue, yeah :)
<slangasek> didrocks: this is the autotester
<slangasek> https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-main/63/ARCH=amd64,LTS=lts,PROFILE=main-all,label=upgrade-test/artifact/lts-main-all-amd64/apt.log
<didrocks> slangasek: wasn't aware about it, let me look
<slangasek>     Installing unity-common as Depends of unity
<slangasek>     unity:amd64 Depends on compiz-core-abiversion-20120228 [ amd64 ] < none > ( none ) can't be satisfied!
<slangasek> Broken unity:amd64 Depends on compiz-core-abiversion-20120228 [ amd64 ] < none > ( none )
<slangasek>   Considering compiz-core:amd64 20 as a solution to unity:amd64 12
<slangasek>   Holding Back unity:amd64 rather than change compiz-core-abiversion-20120228:amd64
<slangasek> the same error didn't happen with the previous test from 5 hours earlier
 * cjwatson wonders whether to put this linux-firmware upload on hold, given that it needs an associated linux upload to be effective
<didrocks> slangasek: apt-cache show unity=5.6.0-0ubuntu4 â¦ Depends: â¦ compiz-core-abiversion-20120228,
<cjwatson> and would need a d-i upload afterwards too
<didrocks> so the virtual package that unity picks is coherent with what is in the distro
<slangasek> didrocks: yes, but somehow apt thinks it shouldn't install it, whereas it had no problem doing so 5 hours earlier... assuming it's not the perl/mono change, I wonder what else has changed that caused this?
<didrocks> slangasek: yeah, it's really puzzlingâ¦ compiz-plugins-main-default was installed and dep on the same virtual package
<cjwatson> is telepathy-farstream urgent?  new upstream release, no bugs mentioned
<didrocks> slangasek: and the dep is compiz, compiz-core-abiversion-20120228, to ensure it tries to build one compiz first
<didrocks> s/build/install
<cjwatson> I'd appreciate somebody reviewing ubiquity - fixes build failure and a rls-p-tracking bug
<didrocks> slangasek: that process didn't change since natty
<infinity> cjwatson: I'll look at ubiquity.
<infinity> cjwatson: No opinions about the kernel thing, but if it's just a time concern, I can make sure i386 lands on roseapple (i386 is usually the bottleneck), which gets all arches in < 4h.
<cjwatson> I'm confused by that autotest log too
<cjwatson> infinity: I just figure that if we're not having another kernel upload for beta2 (an assumption), then there's no point
<didrocks> slangasek: I'll try to talk to mvo on Monday about it
<infinity> cjwatson: Why would it need a new kernel upload to take advantage of adding firmware?
<cjwatson> see the bug - the kernel module isn't in scsi-modules either
<infinity> Oh.  Check.
<cjwatson> bug 963306
<ubot2`> Launchpad bug 963306 in linux-firmware "Intel(R) C600 SAS Controller Driver is boot essential" [Undecided,Fix committed] https://launchpad.net/bugs/963306
<infinity> cjwatson: Yea, looked.
<slangasek> didrocks: well, I was hoping to have validation today that the mono+perl change is good :(
<didrocks> slangasek: yeah, I really have no clue why you get that suddenly
<didrocks> slangasek: the new release has a new ABI, but we are in the same state, with unity dep on the new abi and new vitual package
<didrocks> virtual*
<infinity> cjwatson: From my experience with tp-qt4, my guess is that the farstream sync is required for the tp-qt4 upload to be happy.
<cjwatson> if you know it, feel free to review :)
<infinity> cjwatson: (The tp-qt guys don't really understand backward compat as well as the tp-glib folks)
<cjwatson> maybe the autotester was operating on a half-complete proposed stage?
<didrocks> cjwatson: that can be an explanation
<didrocks> as there is a new ABI
<cjwatson> at the time it ran, it wouldn't have been all the way there
<didrocks> but the autotester has -proposed enabled?
<infinity> cjwatson: Yeah, sure, I'll take the two telepathy bits for review.
<cjwatson> it does
<didrocks> ah :)
<didrocks> slangasek: so you have your explanation ^
<cjwatson> I think largely as an accidental result of having lucid-proposed enabled in order to get upgrade code from there
<slangasek> oh
<slangasek> heh, ok
<cjwatson> you can see it in https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-main/63/ARCH=amd64,LTS=lts,PROFILE=main-all,label=upgrade-test/artifact/lts-main-all-amd64/main.log
<slangasek> right, cool - so a re-test should show something useful
<cjwatson> and it makes some sense that if you have lucid-proposed then you want precise-proposed
<cjwatson> right
<didrocks> the new compiz provides compiz-core-abiversion-20120305 as a virtual package
<slangasek> jibel: can you manually re-try the precise-upgrade-lucid-main on both archs?  The daily test failed because unity was temporarily uninstallable in precise-proposed
<didrocks> slangasek: yeah, new run should be safe now
<didrocks> phew, after a crazy week, finally nothing scarying at the end of it ;)
<infinity> cjwatson: This is basically just mirroring the localechoose change locally in localechooser-apply?  Trying to visually diff those two hurts. ;)
<didrocks> thanks cjwatson for finding the issue ;)
<cjwatson> infinity: yeah.  curse oem-config anyway.
<cjwatson> (it has to have a cloned version because it isn't operating on /target.  one day I should turn it into automatic seddery.)
<infinity> cjwatson: We really need to just do a better job of exporting target=/ all over the place.
<infinity> cjwatson: And accepted.
<cjwatson> ta
<cjwatson> yeah, some bits of d-i code support that, some don't
<cjwatson> needs some reunification by somebody really anal.
<infinity> I have a rectum.
<infinity> I'm not sure if I *really* have one.
<cjwatson> I thought you were a robot.
<infinity> I'm a poorly-designed robot.
<astraljava> At least you're considerably more intelligent than ubot2`, though.
<infinity> cjwatson: tp-farstream looks good, accepting that.
<infinity> cjwatson: I'll do tp-qt4 a bit later, when my brain's not being bent by p11-kit, or when I want another "break".
 * cjwatson nods
<slangasek> cjwatson: we're avoiding :any deps because of lucid->precise upgrades, right?
<cjwatson> yes
 * slangasek nods
<cjwatson> wine-gecko1.4 has "Recommends: wine1.4:any", I notice
<cjwatson> I forget exactly how fatal the parser error is ...
<slangasek> bug #962854
<ubot2`> Launchpad bug 962854 in gconf "Upgrade 11.10 to 12.04 failed on gconf2" [High,Confirmed] https://launchpad.net/bugs/962854
<slangasek> the gconf-service package provides both arch-dependent and arch-independent interfaces
<slangasek> and this is /after/ Np237 did extensive package splitting for multiarch :/
<cjwatson> does an approach like the one I suggested in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641614#25 work here?
<ubot2`> Debian bug 641614 in libidl "please convert to multiarch" [Normal,Open]
<slangasek> it should, though adding Yet Another Binary will make me sad
<cjwatson> an intermediate package which is Architecture: all and Multi-Arch: foreign, and whose sole purpose is to contain the dep that would otherwise be :any
<cjwatson> yeah :-/
<slangasek> you don't think the release upgrader apt mitigates this adequately?
<cjwatson> I don't think we can rely on that, and in any case germinate also doesn't understand :any at this point
<slangasek> I guess that would rather conclusively break 'apt-get' upgrades of the lucid desktop though
<slangasek> ah, ok
<cjwatson> (not that I expect the latter to be persuasive to Np237, but)
<slangasek> alright, we'll do it the ugly way
<cjwatson> I forget what its failure mode is; I was going to do something about it since we'll need it eventually, but I think I shelved it since all such deps had to be purged for precise anyway
<cjwatson> I think it just omits following those deps
<cjwatson> slangasek: wait, am I following your analysis correctly?  you're saying that the plugin has to be of the same arch as the rev-dep; wouldn't that imply gconf-service Multi-Arch: allowed, gconf2 Depends: gconf-service, not gconf-service:any?
<cjwatson> :any seems counterproductive
<slangasek> cjwatson: sorry, I said it the wrong way around - I mean that the /other/ revdeps would need to use gconf-service:any
<cjwatson> ah
<cjwatson> right, so you'd end up with a gconf-service-any binary or something as the intermediate
<slangasek> (basically, all other revdeps aside from gconf2 itself)
<rsalveti> infinity: lovely, there's one plugin using opengl directly by hand
<cjwatson> ok, so lots more packages to change, too
<rsalveti> infinity: that's specifically why they are using cogl and clutter, to avoid forcing one single opengl interface
<infinity> rsalveti: :(
<cjwatson> $ grep-aptavail -FPre-Depends,Depends gconf-service -nsPackage | wc -l
<cjwatson> 62
<cjwatson> eek
<rsalveti> but sometimes they break the rule, and break everyone not using gl
<cjwatson> ok, sort -u reduces to 31, still
<rsalveti> infinity: will check with linaro folks to see if we can port this plugin
<infinity> rsalveti: Sure.  Is it a plugin we can just conditionally disable on ARM for the time being, or is it something painfully central and useful?
<rsalveti> infinity: it's the shell-screen-grabber, maybe we can disable
<rsalveti> I'll take a look
<cjwatson> slangasek: I can't think of an analogous hack in the other direction, that would allow you to force same-arch for a dependency on an otherwise M-A: foreign package.  Can you?  That would allow confining the hack to a single package
<cjwatson> (in any case, squeeze's apt has the same problem, doesn't it?  and Debian doesn't have release-upgrader-apt)
<slangasek> nope, can't think of a way to do it the other way around
<cjwatson> I think there may just be a limit on how much it's possible to do in a single stable release cycle ...
<infinity> To be fair, M-A upgrades are generally fine if you don't enable a second arch on upgrade.
<infinity> It's our attempt to violently do so (because we wanted to be rid of ia32-libs) that makes it rough.
<slangasek> they wouldn't be if we started using dependencies that the old apt doesn't understand
<infinity> s/generally/always/
<slangasek> (not merely "can't satisfy", but *doesn't understand*...)
<infinity> slangasek: Well, there's that.
<infinity> I hadn't realised we'd gone down that path.  I missed reading scrollback here.
<infinity> What happened to the old Debian rule of not using new dpkg/apt features until stable+1? :P
<rsalveti> infinity: great, seems upstream has the fixes at the wayland branch, to actually be able to use opengles
<rsalveti> infinity: I'll try them and let you know how it goes
<infinity> rsalveti: Oh, shiny.
<cjwatson> infinity: we haven't (mostly)
<infinity> cjwatson: "mostly". ;)
<cjwatson> one exception which I think Scott Ritchie had promised to get rid of
<cjwatson> hmm, he's closed the bug, but it's still there
<infinity> rsalveti: If only every bug I was working on had an "oh look, upstream's already done the hard work for me" branch. :)
<slangasek> infinity: right, that's basically why I'm whining, because the new feature makes this clean(ish) and avoiding it is ugly
<slangasek> anyway, the path forward is clear from here
<infinity> slangasek: Well, we have (in the distant past) provided static dpkg/apt for Debian stable upgrades.  Though with no lovely frontend to inform users of that fact, just release notes that no one reads.
<infinity> I do remember them being by-hand jammed into the archive though.
<slangasek> yep
<rsalveti> infinity: haha, yeah, but still need to test and validate ;-)
<rsalveti> it can't be that easy
<infinity> rsalveti: Pessimist. ;)
<slangasek> skaet: what would you like to do with bug #876298?
<ubot2`> Launchpad bug 876298 in update-notifier "[FFe] [MASTER] We need to better handle external payloads (Flash, msttcorefonts) not being available." [Critical,Triaged] https://launchpad.net/bugs/876298
 * skaet looking
<skaet> slangasek,  is there any way the behavior will be worse than what happens now when failure happens (code not 100%).   Ideally I'd like to pull this into beta 2, so it can bake as long as possible, but it might be best just after beta 2.  How ready is it?
 * skaet thinks getting this in before release is a good idea,  just timing.
<slangasek> well, it's possible the behavior could be "worse" in the sense that we manage to fail to ever download flashplugin for the user and so flash doesn't work without the user knowing why
<slangasek> I don't think I want to push the code to the archive today - I'd like to iterate a bit more with mvo.
<skaet> slangasek,  ok,  lets aim for just after Beta 2 then,  I'll mark it approved.
<slangasek> skaet: ok, thanks
<micahg> skaet: will you take an upload for bug 958385 during the freeze (breaks on screen keyboard for xubuntu)
<ubot2`> Launchpad bug 958385 in onboard "Encoding mismatch when mousetweaks is missing" [Undecided,Fix committed] https://launchpad.net/bugs/958385
<skaet> micahg,  yes,  bug fixes are still welcome during the freeze, esp. early on.
<micahg> skaet: I won't get to this until the weekend
<skaet> micahg,  is it Xubuntu specific, or wider?
 * skaet thinks it looks wider...
<micahg> the bug is, the package is seeded in ubuntu and edubuntu as well
<micahg> skaet: ^^
<skaet> yes,  if we can be sure it won't cause regression on either of those,  I'm fine with pulling it on monday (or earlier).
<micahg> hmm, ok, will look for the fix over the weekend and see if it's likely to break stuff
<skaet> thanks micahg! :)
<jibel> slangasek, lucid main is running. I disabled -proposed too since release-upgrader-apt is in -updates now.
<slangasek> jibel: ok, cheers :)
<jbicha> rsalveti: thanks for working on the gnome-shell ARM build problem
<rsalveti> jbicha: np
<slangasek> ^^ addressing upgrade bug #962854
<ubot2`> Launchpad bug 962854 in gconf "Upgrade 11.10 to 12.04 failed on gconf2" [High,In progress] https://launchpad.net/bugs/962854
<slangasek> infinity: ^^ if you can look at the above at some point, would be appreciated; needs unapproved and binary new processing
<infinity> New packages?  Oh my.
<infinity> slangasek: I'll poke it when LP gets around to giving me a diff.
<infinity> I'll go find lunch while I wait. :P
<slangasek> okie
<infinity> Hrm, did someone review and approve the telepathy-qt4 that was on my TODO?
<infinity> Guess so.
<infinity> jdstrand: I have to know, what does hamster-indicator indicate?
<infinity> jdstrand: (And the part where the short description doesn't give me any clues might be a bug) :P
<slangasek> does syncpackage respect the freeze queue?
<cjwatson> yes
<slangasek> good-o
<cjwatson> there've been several syncs in the queue at various points just this freeze
 * cjwatson is perplexed by bug 961046 and agrees it's not terribly pretty - but I don't understand what criteria were used to tag it rls-mgr-p-tracking
<ubot2`> Launchpad bug 961046 in ubiquity "oem-config: Content of the slideshow shifted to the bottom right" [Medium,Triaged] https://launchpad.net/bugs/961046
<infinity> cjwatson: I dunno, that kind of user experience is pretty important to people.
<slangasek> rls-mgr-p-tracking is more of an incoming queue than anything else
<infinity> (Also, WTF?  How did that happen?)
<infinity> slangasek: gconf is through NEW.
<slangasek> infinity: cheers
<skaet> slangasek,  yes,  its an incoming/consider queue.   Most are there if high/critical and targetted against the release, found in the iso testing, etc.
<micahg> anyone opposed to a no change rebuild to change the suggests from cpio on libarchive1?
<micahg> nevermind, I"ll just wait until after beta freeze
<cjwatson> skaet: is there a set of rough criteria somewhere for removing that tag?
<cjwatson> infinity: I agree it's important, I just don't see it as RC in any sense
<skaet> cjwatson, for that one,  I've gone in and removed it, since it isn't judged high.
 * skaet needs a tag for those considered, but not making the rls-p-tracking list.
 * cjwatson nods
<cjwatson> at some point there are going to be some bugs we forget about though :)
<infinity> cjwatson: Well, given that it's still the oneiric slideshow anyway, I assume the artsy-fatsy folks will raise this again if it's an issue when they do precise stuff.
<cjwatson> not saying this is one of them, but
<infinity> artsy-fartsy, too.
<infinity> Oh, wait.  No, maybe that's a Pangolin.
<infinity> My brain's not all here.
<cjwatson> It was updated for 12.04 last week
<infinity> Yeah.
<infinity> Ignore me.
<infinity> Spending two hours looking at code to type end up typing a 1-line, 10-character fix has driven me off the deep end.
<infinity> s/type //
<slangasek> accepting p11-kit
<infinity> slangasek: \o/
<slangasek> infinity: thanks :)
<skaet> cjwatson,  aiming  for launchpad release high+critical = ( incoming U p-tracking U p-someoneelse )  then the searches that work can help me figure out gaps.
<cjwatson> p-tracking => rls-mgr-p-tracking or rls-p-tracking?
<skaet> p-incoming (rls-mgr-p-tracking)  p-tracking is rls-p-tracking.   maybe  p-nottracking, for other?
<cjwatson> Maybe we could just use the literal tag names rather than ambiguous abbreviations? :-)
 * cjwatson <- very confused now
<skaet> cjwatson,  yeah, the names this release were an evolutionary mistake
<skaet> and we missed a new tag.
<skaet> maybe for next release rls-q-incoming,   rls-q-tracking,  rls-q-nottracking - clearer?
<cjwatson> Only if the set of bugs it's worth applying rls-q-nottracking to is very strictly limited.  It would be pretty bad to have to tag a few hundred thousand bugs just to make sure nobody worries about them.
<skaet> cjwatson,  agreed, its just the state it goes in once one of the development teams or release team members have looked at the rls-q-incoming, and decided its not a priority for this release.
<cjwatson> Sounds like we might as well just remove the tag.
<skaet> am finding cases in the last search where folks have removed the rls-mgr-p-tracking tag, put on a rls-p-tracking tag, and then removed both.... which leaves me the fun of rediscovering it all over again.  :P
<cjwatson> It's in the bug history.
<cjwatson> It's not like it vanishes.
<skaet> yeah, and requires manual checking each time though.
<cjwatson> It's not searchable in bulk, but the entire point of rls-q-nottracking is that you don't search for it.
<cjwatson> It'd be pretty easy to lplib
<cjwatson> Although personally I'd find Ctrl-F in the browser easier ...
<cjwatson> I just don't really see the point of rls-q-nottracking unless it's in some category of bug that you'd be looking at as a source of rls-q-incoming bugs; in which case it might be worth spelling out those categories
<cjwatson> If possible
<cjwatson> Because maybe we should be removing the bugs from those as well if they aren't that important
<skaet> In LP advanced searches,  I can specify high & critical , and then remove all with tags rls-q-tracking,  rls-q-nottracking, rls-q-incoming,  and just find out those that haven't sorted,  without writing a script.
<cjwatson> So you're saying that "the set of bugs it's worth applying rls-q-nottracking to" (as I asked for above) is Priority high/critical?
<cjwatson> (or Importance or whatever it is)
<skaet> yes,  assuming they made it on the list q-incoming at some point.
<cjwatson> I guess I can run with that, although maybe if they don't matter they should be downgraded
<cjwatson> (Though, OK, package-specific priority != project priority)
 * skaet nods
<cjwatson> I think you're going to spend a lot of time trawling through large numbers of bugs if you do that though ...
<skaet> cjwatson,  by having these lists, the quality of my life has significantly improved this release, compared to past ones.
<skaet> :)
<cjwatson> mkay
 * skaet spent way, way,way too much time screen scraping and putting things in a spreadsheet and manually tracking to get the same type of info.
 * ScottK hurrumphs that if it's worthwhile it should be hard ....
#ubuntu-release 2012-03-24
 * skaet doesn't mind hard, just dislikes wasting time because tools aren't there to do the job.
 * infinity notes that writing tools is often a good solution to lacking tools.
 * skaet --> TGIF.
<slangasek> hmm, I guess if the lucid-main autotest still hasn't given us results after 3h30, that's a good sign
<slangasek> it only takes 2.5h to fail on mono :)
<infinity> slangasek: But what does it fail on at 3:45? ;)
<slangasek> we'll see!
<ScottK> libtelepathy-qt4-farsight2 can be removed due to NBS if someone is awake (infinity).  No rdepends left.
<infinity> ScottK: That was quick.
<ScottK> The only rdepend was the -dev from the same source.
<ScottK> Kind of a self-licking ice cream cone for NBS.
<infinity> A self... Licking... Ice cream cone?  Why does that metaphor somehow sound terribly dirty?
<infinity> ScottK: Removed.
<ScottK> Dunno.  Look in the mirror.
<ScottK> Thanks.
 * infinity is a bit shocked that the only thing on outdate.txt is the libical FTBFS.
<infinity> Oh, outdate_all is less pleasant.
<ScottK> Yes, but main looks pretty decent. Feel free to fix the LO FTBFS on armel.
<infinity> I'll let Jani do it, since he so LOVES libreoffice.
<slangasek> cjwatson: Daviey is reporting an issue with the d-i netboot images; it appears libcrypto is in the initramfs but libssl is not, so pulling the libssl-udeb doesn't work without also pulling the libcrypto-udeb... I think we want to respin d-i for this?
<infinity> slangasek: I don't follow the second half of that run-on sentence.
<slangasek> infinity: libcrypto in the initramfs is 1.0.0; libssl is not there; things trying to pull in libssl w/o libcrypto fail
<slangasek> so if we refresh the initramfs to contain current libcrypto matching the libssl in the archive, this goes away
<infinity> They probably shouldn't do that anyway, or you get image/component skew post-release too.
<infinity> But rebuilding is a quick fix.
<slangasek> well, ultimately it seems the problem is libssl1.0.0-udeb has wrong deps
<slangasek> Depends: libc6-udeb (>= 2.15), libcrypto1.0.0-udeb (>= 1.0.0)
<infinity> Needs to tighten that up?
<slangasek> yeah; there's a new symbol version
<infinity> That would fix it, then.
<infinity> Perhaps we should fix the actual bug. :P
<slangasek> that's also acceptable ;)
<infinity> A respin to freshen things afterward is a bad idea, but maybe after testing with an intentional skew to make sure the bug's fixed.
<infinity> s/is/isn't/
<infinity> libcrypto 1.0.0 libssl1.0.0 (>= 1.0.0)
<infinity> libssl 1.0.0 libssl1.0.0 (>= 1.0.0)
<infinity> udeb: libcrypto 1.0.0 libcrypto1.0.0-udeb (>= 1.0.0)
<infinity> udeb: libssl 1.0.0 libssl1.0.0-udeb (>= 1.0.0)
<infinity> Looks like the shlibs are just plain wrong across the board.
 * infinity fixes.
<infinity> Although.  Shouldn't dh_makeshlibs be working this magic without intervention?
 * infinity builds openssl so he can stop guessing.
<infinity> Nevermind, I can't read.  Fixing. :P
<slangasek> the symbols file is also entirely missing the new symbols
<slangasek> so that's bad too
<ScottK> BTW, if you look at component mismatches, the source/binary demotions for telepathy-farsight should be good to do.
<infinity> It shouldn't be.
<slangasek> infinity: "shouldn't"?
<infinity> slangasek: Yes.  Shouldn't.  What's mising?
<infinity> slangasek: I can't see how they could be missing and the build not fail.
<slangasek> infinity: dpkg-gensymbols doesn't require missing symbols to be treated as a failure, and it isn't by default
<ScottK> Actually, I think those can be removed.  Let me check.
<infinity> slangasek: No, I suppose not.  And the way it's used here is odd.
<infinity> slangasek: But I don't see how there could be symbols present in the library but not in the symbols file?
<infinity> slangasek: Barring a pretty massive bug in dpkg-gensymbols.
<slangasek> the symbols file isn't autogenerated
<infinity> Are we talking about the same one?
<infinity> The one in the binary package is.
<infinity> The one in the source package only has 6 lines.
<infinity> Anyhow, the shlibdeps thing is fixed.
<infinity> Huh, and I just got a ton of 1.0.1 symbols in debian/libssl1.0.0/DEBIAN/symbols
<infinity> And those are the only difference between that and my installed copy.
<slangasek> hmm
<infinity> I'm not actually sure how that's even possible, given that the thing I changed is after dpkg-gensymbols...
<infinity> Puzzling.
<infinity> Anyhow, is there a bug for the dependency thing?
<infinity> Ugh, and a clean target that doesn't clean.
<ScottK> slangasek or infinity: telepathy-farsight (src): libtelepathy-farsight-dev libtelepathy-farsight-doc libtelepathy-farsight0 libtelepathy-farsight0-dbg (binaries) should all be removed now.
<slangasek> none filed no
<infinity> Kay, one more test build to see if this magical appearance of symbols seems to be a recurring thing.
<infinity> And then I'll upload. :P
<infinity> (Either way, the shlibs will be fixed, which is the nastier bug, symbols files are optional anyway)
<infinity> Or I might be living in the past.  Are they still optional?
<slangasek> if the symbols file exists it will be used exclusively and the shlibs file is ignored.
<infinity> Well, the shlibdeps call in the package itself seemed to DTRT after I fixed the shlibs.
<infinity> But, the symbols file also magically fixed itself, so that's not much of a test.
<slangasek>         dpkg-gensymbols -Pdebian/libssl1.0.0/ -plibssl1.0.0 -c4
<slangasek> urk
<slangasek> that -c4 is exactly what should *not* let the package out the door without a complete symbols file
<infinity> slangasek: Well, a second try here, and it gave me all the 1.0.1 symbols again.
<infinity> slangasek: So, I'm kinda puzzled as to how it didn't before.
<slangasek> right, so why didn't it do that on the buildd
<slangasek> you see the broken .symbols in the package too, right?  It's not some local corruption of mine?
<infinity> Yeah, same here.
<slangasek> dpkg-shlibdeps: warning: debian/openssl/usr/bin/openssl contains an unresolvable reference to symbol CRYPTO_gcm128_release@OPENSSL_1.0.1: it's probably a plugin.
<slangasek> from the build log :/
<infinity> http://paste.ubuntu.com/897340/
<infinity> ^-- Diff from local to build.
<infinity> slangasek: And all I've changed is the dh_makeshlibs call on the *next* line, so I can't see how it would have changed the symbols file.
<infinity> slangasek: Though -c4 clearly won't do any good when debian/libssl.symbols is a template, not a full list.
<infinity> (I didn't even know you could wildcard/template until just now)
<slangasek> well, it would throw an error if there were any new symbols not matching those wildcards
<infinity> But there aren't.
<slangasek> (which should be safe enough, given those wildcards)
<infinity> And it won't whine if it's missing symbols that match the wildcards, which is the case on the buildd.
<infinity> For whatever moon-phase-induced reason.
<slangasek> hmm, that seems like a bug in dpkg-gensymbols though
<slangasek> -c1 is "fail if some symbols have disappeared".  There's a wildcard matching nothing.  Shouldn't that count?
<infinity> Maybe?
<infinity> I dunno.
<infinity> slangasek: It had this problem on every arch, it wasn't moon phase.
<infinity> slangasek: I'm going to revert my other fix and see if this is reproducible here.  But if it is, I'm not sure I'd understand why.
<slangasek> AIUI, the dpkg-gensymbols line only works as a sanity check
<slangasek> because dh_makeshlibs will call dpkg-gensymbols a second time
<slangasek> and overwrite
<infinity> Oh!
<infinity> And maybe it's blatantly ignoring symbols that are >> 1.0.0 because of the dep constraint.
<infinity> That seems like kinda weird behaviour.
<slangasek> yes, it does
<infinity> But explains what I'm seeing here with my shlibs fix magically fixing the symbols too.
 * slangasek nods
<infinity> Yeah, I'm going to just upload this and ponder the implications of debhelper and/or dpkg bugs later.
<infinity> Erk.
<infinity> Maybe not.
<infinity> Rebuilding 1.0.1-2ubuntu1 here still gets me a correct symbols file.
<infinity> So my computer's smarter than the buildds.
<infinity> Never a good sign.
<infinity> Time for a clean chroot.
<slangasek> any -j madness possible?
<infinity> I was -j2 here.
<infinity> But so are almost all the buildds.
<infinity> I could try not.
<slangasek> it's a pretty linear debian/rules
<infinity> Yeah.
<infinity> And the logs certainly seem to show it in order.
<infinity> I don't see the usual interleaving that says "something broke"
<infinity> It's weird what random greps turn up.
<infinity> test_buildd_recipe:         'archive_purpose': 'puppies',
<slangasek> infinity: the only thing I can think of that's different now is that libssl1.0.0 1.0.1 is going to be installed in the build chroot
<slangasek> whereas the first time around, it wasn't
<infinity> slangasek: So, a local build of the previous source in a clean buildd chroot still gives me all the 1.0.1 symbols.
<infinity> slangasek: Ahh, but my chroot does have 1.0.1 installed, yes.
<infinity> slangasek: Still, while I don't entirely understand what's wrong, every test here seems to imply that accepting the above package will "fix" things. :P
<infinity> Maybe the dh_makeshlibs isn't actually using the just-built library?
<infinity> Not seeing how that would happen either, though. :/
<infinity> slangasek: Bingo.
<slangasek> ?
<infinity> slangasek: lrwxrwxrwx 1 buildd buildd 37 Mar 24 04:17 ./debian/libssl1.0.0/usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 -> /lib/x86_64-linux-gnu/libssl.so.1.0.0
<infinity> absolute symlinks in the package, resolving to the system libraries.
<slangasek> ah
<infinity> Probably just need to -X those, since I'm pretty sure those links need to be absolute, per policy.
<infinity> Though it's been a while since I read that section.
<slangasek> pretty sure those links shouldn't be there at all
<infinity> Anything that crosses top-level dirs, right?
<slangasek> that's the idea
<slangasek> but why should /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 exist at all?  It's redundant
<infinity> I was about to say "for braindead upstreams that dlopen absolute paths", but they're never going to look in the multi-arch path anyway. :P
<slangasek> openssl (0.9.8g-15ubuntu2) jaunty; urgency=low
<slangasek>   * Move runtime libraries to /lib, for the benefit of wpasupplicant
<slangasek>     (LP: #44194). Leave symlinks behind in /usr/lib (except on the Hurd)
<slangasek>     since we used to set an rpath there.
<slangasek>  -- Colin Watson <cjwatson@ubuntu.com>  Fri, 06 Mar 2009 12:48:52 +0000
<slangasek> that reasoning no longer applies
<slangasek> we should just kill them
<infinity> Seems fair.
<slangasek> infinity: care to do the honors?
<infinity> Yup.
<infinity> Reject my current upload, plox.
<slangasek> rejecting previous upload
<infinity> Oh wow, the linking for the .so hurts.
<infinity> Anyhow, fixing the runtime links. :P
<infinity> Hrm.
<infinity> slangasek: Will the shlibs madness also follow the -dev links (which have the same issue)?
<infinity> slangasek: Or is *.so ignored?
<infinity>             /(\.so\.|\.so$)/ && -f $_ &&
<infinity> Looks like it'll trip up on the dev links too.
<infinity> So, need to at least -X those.
<slangasek> really?  odd
<infinity> Well, unless I can't read pcre.
<infinity>        -Xitem, --exclude=item
<infinity>            Exclude files that contain item anywhere in their filename or directory from being
<infinity>            treated as shared libraries.
<slangasek> oh, but isn't that what the -f $_ is for?
<infinity> ^-- Cause "anywhere" is useful...
<slangasek> i.e., this should never match symlinks
<infinity> Hrm.  If it never matches symlinks, then I still don't know how we got here. :P
<slangasek> yep
<slangasek> so I can reproduce the error by downgrading libssl10.0.
<slangasek> infinity: oh, but of course dh_makeshlibs only looks at the tmpdir of the current binary package
<slangasek> so dropping the compat /usr/lib symlinks is sufficient
<infinity> Oh, since it's only libssl1.0.0 we care about, the -dev will be ignored...
<infinity> Can you quickly confirm that by just removing them by hand and re-running dh_makeshlibs?
<slangasek> yes, confirmed
<infinity> Reuploaded.
<slangasek> (and perl's -f returns true for symlinks, probably by analogy with [, using stat vs. lstat; so that's that mystery explained)
<infinity> Yeah, makes sense.  test does the same.
<infinity> Oh, you just said that.
<slangasek> and that could also be a bug in dpkg-gensymbols
<infinity> Yeah, arguably.  Following symlinks seems inherently dangerous.
<infinity> Not only the package->system issue, but cross-package linking.
<infinity> You want the real library, not a ghost.
<slangasek> care to file a bug on dpkg?
<infinity> Later tonight, sure.  I'm currently multitasking between work and life (as of a few minutes ago)
<infinity> And I think life's about to win.
<infinity> By virtue of being slightly prettier.
<slangasek> ok :)
<infinity> Oh, that's why my upload isn't in the queue.
<slangasek> .upload in your way? :)
<infinity> No.
<infinity> */55
<infinity> We need to fix that.
<slangasek> ?
<infinity> It used to be a gap left for a security queue from dak->soyuz.
<infinity> So, the "no queue run at 55" thing is, like, 4 years obsolete?
<infinity> Feel free to fix lp_queue's crontab and ping a LOSA to mirror it to their deployment bits.
<infinity> (Or I'll do that later too)
<slangasek> it's not clear to me that won't give someone an aneurysm
<slangasek> so I'll pass for now :)
<infinity> Heh.
<infinity> Alright, I'll take care of it with webops later when I'm not distracted. ;)
<slangasek> whoo, lucid-main upgrade test succeeded on i386
<slangasek> (and failed on amd64... baby steps)
<slangasek> dpkg: unrecoverable fatal error, aborting:
<slangasek>  fork failed: Cannot allocate memory
<slangasek> heh
<infinity> slangasek: *raise brow*
<slangasek> it's not beta-critical
<slangasek> but obsolete conffiles are now being looked at by the auto upgrader
<slangasek> so I figured I'd shoot a couple
<infinity> slangasek: Oh, no, I was raising my brow at the "fork failed: Cannot allocate memory"
<slangasek> oh
<slangasek> well, clearly the amd64 upgrade went so well that the VM couldn't contain itself
<infinity> *snicker*
<infinity> Anyhow, since we need to enter respin city at some point anyway, and this looks correct, I'm accepting it.
<jibel> session failed to start with latest unity, great :/
<jibel> Can you respin ubuntu alternate. It failed because versions of gnome-control-center and gnome-control-center-data didn't match.
<bdrung> can someone look at the FFe request bug #963062?
<ubot2`> Launchpad bug 963062 in distro-info "[FFE] distro-info should have posix shell cmdline tool" [Medium,New] https://launchpad.net/bugs/963062
<tumbleweed> I suppose I can :)
<bdrung> tumbleweed: distro-info was written in many languages: python, haskell, shell, ...
<bdrung> maybe i will rewrite it i C one day :)
<bdrung> tumbleweed: btw, would requesting a FFe for lintian makes sense?
<tumbleweed> bdrung: sure, latest lintians are nice to have
<bdrung> tumbleweed: thanks. btw, why is there a timeframe given?
<tumbleweed> bdrung: so tha twe don't end up with a pile of approved FFes that haven't landed
<bdrung> k
<bdrung> tumbleweed: i would do it right now, but https://launchpad.net/debian/+source/distro-info is slow in grabbing the new version
<Daviey> bdrung: thanks for your work on distro-info, and splitting out the config.
<Daviey> tumbleweed: This FFe makes perfect sense.. To SRU the config file, a data source package just needs uploading, rather than rebuilding a binary(s)
<tumbleweed> Daviey: already approved
<Daviey> Top Banana
<bdrung> Daviey: you're welcome
<Daviey> cjwatson: Are you around?
<Daviey> cjwatson: I suspect d-i needs a rebuild, following the openssl bump...
<Daviey> main-menu[569]: (process:7356): wget.gnu: /lib/libcrypto.so.1.0.0:
<Daviey> version `OPENSSL_1.0.1' not found (required by /lib/libssl.so.1.0.0)
<Daviey> (seeing the same thing with curl aswell)
<slangasek> Daviey: are you still seeing that after the latest openssl upload?
<slangasek> the latest libssl1.0.0-udeb in the archive should now declare a correct dependency on libcrypto1.0.0-udeb (>= 1.0.1), meaning that both should be pulled in for you
<slangasek> (d-i should get a respin at some point, but that's an optimization rather than a bugfix)
<Daviey> slangasek: when was that published?
<Daviey> slangasek: I've been trying to work around it, by using a local udeb mirror.
<slangasek> Daviey: after we spoke last night :)
<infinity> Daviey: ~10 hours ago?
<Daviey> hmm
<Daviey> let me try it
<slangasek> 1.0.1-2ubuntu2
<infinity> Daviey: Please do.  This should fix the real bug.
<infinity> Daviey: (As in, libssl-udeb should now pull in libcrypto-udeb and override the mismatched one in the initrd)
<infinity> Daviey: Once you've proven that's true then, yeah, a d-i rebuild to freshen things is still a good plan at some point.
<Daviey> /var/log/apache2/access.log:2590:10.55.55.3 - - [24/Mar/2012:14:51:33 -0400] "GET /ubuntu/pool/main/o/openssl/libssl1.0.0-udeb_1.0.1-2ubuntu2_i386.udeb HTTP/1.1" 200 149682 "-" "Wget"
<Daviey> no dice
<Daviey> I did notice that if i anna-install'd wget-udeb by hand.. it *ddi* work
<Daviey> did*
<Daviey> so i'm not fully convinced it's just an optimzation
<infinity> So, we have a d-i bug here too perhaps.
<infinity> (Not "an it needs rebuilding" bug, but an "it's doing something wrong" bug)
<infinity> Hrm, who accepted linux-firmware?
<Daviey> right.. adding an early_command to install wget-udeb doesn't work.. but dropping to the console and anna-instaling after failure, makes it work
<infinity> How are you installing it with the early_command?
<infinity> Still anna-install?
<Daviey> yes
<infinity> Oh, but early.  I wonder if early is using lists local to the initrd, before we've updated to see what the interwebs have to offer.
<infinity> THough, then you'd be getting the old version.  Nevermind.
<infinity> Daviey: Anyhow, we can (and will) rebuild d-i, but could you file a bug about this behaviour?  It's obviously wrong.
<ScottK> bdrung: distro-info-data source accepted.
<Daviey> infinity: I've set the mirror/* to be my custom local forked archive
<infinity> Daviey: And undoing that and using the defaults gives the same issues?
<Daviey> infinity: yes
<infinity> Kay/
<infinity> Yeah, please file a bug.
<infinity> And now I'm just concerned that whoever accepted linux-firmware may force me to bump d-i floppy sizes again before I can rebuild it. :P
<Daviey> I wish i could work out why an ann-install in early is different to later stages
<infinity> If you'd prefer to track it down instead of filing a bug, that doesn't hurt my feelings either. ;)
<Daviey> infinity: you can chain packages in anna-install foo bar ?
<infinity> Daviey: I'm not much of an anna expert.
<infinity> And yes, anna allows multiple package arguments.
<infinity> (And by extension, anna-install, which is just a thin shim)
<Daviey> Would it be bad karma to do a d-i no-change-rebuild without speaking to Colin first?
<slangasek> no
<slangasek> sounds like infinity might be working on it though?
<Daviey> slangasek: Do you already have the source locally?
<slangasek> probably not any current source :)
<Daviey> infinity: are you?
 * Daviey pulls
<infinity> Daviey: See above.
<infinity> Daviey: It may well fail because of the new linux-firmware.
<infinity> Daviey: I'd rather make sure that's not true first.
<Daviey> infinity: Suggestions on how to debug that?
<infinity> Daviey: Sure, try to build locally for both amd64 and i386, if it works, we're good.  If it fails with "device full", it needs twiddling.
<infinity> Daviey: I was going to do this in a little bit.
<Daviey> Interesting, looking at the chanelog for the last debian-installer upload
<Daviey> It seems to be netboot failing, rather than cd
<infinity> "It"?
<Daviey> infinity: the issue i am seeing..
<Daviey> I need to reproduce the the latest daily.
<Daviey> infinity: confirmed, curl works from the current daily iso.. but *not* from netboot image.
<infinity> Well, we can definitely rebuild d-i to paper over it for now, but I'm curious about why anna-install hates you in early_command but not later.
<jdstrand> infinity: re hamster-indicater> hamster is a time tracking tool. it used to have something for gnome-panel; this gives that something back to unity
<jdstrand> infinity: that something is an indicator that allows you to see yuor current activity and how long you've been at it, along with methods to change tasks, etc
<jdstrand> infinity: it's quite handy and I've been using the indicator from the ppa for probably going on a year
<infinity> jdstrand: Kay.  Was mostly just curious, since the description was wildly unhelpful.  And also figured it might be something watching my CPU cores (ie: my system's hamsters).  :P
<jdstrand> heh
<bdrung> ScottK: thanks. should i sync distro-info 0.6 or wait until lp picks 0.7 up?
<jdstrand> the longer description is more helpful. I didn't ever notice how bad the short description is :)
<ScottK> bdrung: I'd wait for 0.7.
<jdstrand> it is essentially "echo $srcpkg" | sed 's/\-/ /' :)
<jdstrand> not the greatest
<infinity> jdstrand: Given that short descriptions shouldn't even mention the package, yeah, it's not ideal. ;)
<infinity> jdstrand: (though, in the case of glueish packages, it's hard to avoid, when perhaps what you want is "foo-indicator: add indicator support to foo, a utility that tracks your fooishness")
 * jdstrand nods
<jdstrand> I can fix it up once approved
<cjwatson> infinity: d-i mostly ignores versioned dependencies.  This is documented
<cjwatson> (doc/devel/modules.txt)
<cjwatson> Daviey: cdrom (daily ISO) vs. netboot differs because libcrypto1.0.0-udeb is in the netboot initrd but not in the cdrom initrd
<cjwatson> So this is simply that anna/libd-i doesn't do version checks.  It's intentionally reduced compared to a full dependency resolver; I doubt that we'll "fix" this.
<Daviey> cjwatson: if i anna-install libcrypto1.0.0-udeb from early_command, will it work around this?
<infinity> cjwatson: Hrm.  That seems to kinda negate the usefulness of having versioned deps in udebs then, especially in the post-release initrd/archive skew case.
#ubuntu-release 2012-03-25
<knome> is there any way to limit http://iso.qa.ubuntu.com/qatracker/milestones/210/builds to eg. xubuntu with get parameters?
<knome> stgraber, ^ ?
<knome> also, any idea why yesterdays builds of our desktop images appear at the tracker?
<infinity> knome: Not sure, but you can just click on "Products" to disable them all, and then turn on Xubuntu.
<knome> infinity, i know that :) i was just wondering because i wanted to *link* to the page but only with xubuntu images listed
<infinity> knome: Yeah, not sure if that's doable, but stgraber will know.
<knome> technically, it shouldn't be too hard to implement that for Q
<infinity> knome: As for why the most recent are in the tracker, dailies auto-post, and we haven't turned off the cronjobs yet.
<knome> (if it's not implemented already, i mean)
<infinity> (I imagine we'll go manual on Monday)
<knome> so, what should i test?
<infinity> You can smoketest and let us know if things are horribly broken.
<infinity> But we've had things like a new upstart and openssl (y'know, insignificant packages...) that would have required respins if we were in manual mode anyway.
<knome> heh
<infinity> I don't recommend doing deep end-to-end testing until we go manual, but quick smoketesting is always appreciated.
<knome> mmh.
 * knome zsyncs the xubuntu amd64 desktop
<infinity> (Of course, if you're bored and have time to waste, no one will turn down end-to-end testing, just saying that if you have better things to do and want to retain your sanity, you might want to hold off until we've turned off dailies)
<knome> heh
<knome> let's say i'd like to generally see what we look like, and i can do testing meanwhile :)
 * infinity nods.
<infinity> I haven't spun up a Xubuntu CD yet this cycle.
<infinity> I actually *run* Xubuntu, but my desktop is so customized that I have no idea what the Precise defaults are looking like.
<knome> you should. we tweaked pretty much everything in the graphical side ;)
<infinity> Speaking of, I really, really need to find the time to port the Human theme to GTK3.
<knome> new logo, new wallpaper, improved plymouth theme, improved lightdm theme
<infinity> (Yes, I use Human with Xubuntu, in a mad effort to recreate my GNOME2 experience from 5 years ago)
<knome> improved gtk theme... :)
<infinity> http://lucifer.0c3.net/~adconrad/xubuntu.png <-- See?
<infinity> I'm a creature of habit. :P
<knome> heh
<knome> http://temp.knome.fi/other/shot-20120325.png
<knome> i'm not giving up my panel layout either
<infinity> Heh.
<knome> but see, our new wallpaper graciously spans even 2 monitors! :)
<infinity> Fancy.
<infinity> Dear god, you run IRC black-on-white?
<infinity> Heathen!
<knome> that's our new default terminal color scheme
<knome> see how well that fits the theme in the other terminal window?
<knome> (the scrollbar BG is fixed for precise, btw)
<infinity> http://lucifer.0c3.net/~adconrad/terminals_should_be_black.png
<infinity> Crazy people and their light terminals.
<knome> ugghh, that's way too much contrast :)
<knome> either you have a bad monitor or you like to hurt your eyes
<infinity> I do a lot of computing in the dark.
<infinity> Bright screens hurt.
<knome> i didn't say "bright screen" :)
<knome> i said bad screen
<knome> actually, i said bad monitor
<knome> ;)
<infinity> Heh.
<infinity> Anyhow, speaking of the dark, I should sleep.
<infinity> Happy smoketesting.
<knome> heh, good night :)
<knome> and thanks, i'm sure i will have a superfluously happy time ;)
<Laney> any objections to approving the zsh ffe?
<Laney> (seeding)
<cjwatson> infinity: versioned deps in udebs aren't as useful as they look, no - but d-i's packaging system isn't meant to solve all the problems
<cjwatson> Daviey: better to just rebuild d-i
<ScottK> cjwatson: I assume you want this D-I upload in?
<skaet> Daviey, looks like server amd64 has gone oversize,  what can get removed?
<cjwatson> ScottK: yep, fixes libcrypto vs. libssl mismatch on server
<ScottK> OK.  Accepting.
<ScottK> DOne.
<cjwatson> thanks
<ScottK> No problem.  It was an easy diff to review ...
<cjwatson> :-)
<cjwatson> skaet: bug 545790 has had the rls-p-tracking tag removed, and should no longer be on http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html, but is
<ubot2> Launchpad bug 545790 in dpkg "package PACKAGE failed to install/upgrade: error writing to '<standard output>': Success" [High,Triaged] https://launchpad.net/bugs/545790
<skaet> cjwatson,  I'll ask it be regenerated properly on monday.   thanks.
<cjwatson> thanks
<Daviey> skaet: I am aware, i started trimming on Friday.. Will finish tommohrrowh
<skaet> Thanks Daviey.  :)
<Daviey> cjwatson: confirmed rebuild solved the issue, thanks.
<ScottK> accepted raptor
<stgraber> knome: it should be possible to implement but it's going to be a bit hackish :) the current filtering is done entirely with javascript + cookie
<stgraber> knome: and it's saved in the cookie which you likely won't want to see happen when giving people a link
<knome> stgraber, i see, but i don't think it's hackish :)
<phillw> stgraber: we may have a regression for WiFi. I've seen it and it has been mentioned. Not sure what to raise it against. http://ubuntuforums.org/showthread.php?t=1873477 seems the nearest for it. Can you let me know what to report it against please?
<phillw> https://www.facebook.com/groups/lubuntu.official/ has the screen shot
<stgraber> phillw: can you copy the screenshot somewhere public? I don't have a facebook account
<knome> stgraber, \o/
<stgraber> from what I can see on the forum, this might be a question for cyphermox
<phillw> stgraber: I'm just grabbing it & uploading it... a couple of minutes.
<phillw> stgraber: http://thesii.org/Screenshot.jpg
<phillw> sorry, it dodn't want to go the 1st time!
<stgraber> phillw: sounds like policykit/nm/... might be worth opening a bug against network-manager for now so it at least gets looked at
<phillw> stgraber: okies, I'll get a bug raised.
<phillw> bug 964705 created
<ubot2> Launchpad bug 964705 in network-manager "System policy prevents modification of network settings for all users" [Undecided,Confirmed] https://launchpad.net/bugs/964705
<infinity> cjwatson: So, even post-release, that means the answer is to rebuild d-i any time some archive/initrd skew like this happens?
<infinity> cjwatson: That just feels inelegant. :/
<cjwatson> infinity: Yes
<cjwatson> infinity: Normally kernel ABI bumps get to it first anyway.  This is the first time I can recall it being a problem.
<infinity> cjwatson: Fair enough.  Though, we've never had to worry about this ssl/crypto split before now, have we?  This is a fairly new addition.
<infinity> cjwatson: Though, I guess we don't be doing these sorts of libssl upgrades post-release.  Security fixes in libssl tend to be pretty surgically precise and non-disruptive.
<cjwatson> libssl/libcrypto have been split for years
<cjwatson> in udebs anyway
<cjwatson> Perhaps the addition is that somebody actually cares about libssl in udeb form now, rather than it being a niche thing
<infinity> cjwatson: Well, yeah, but I get the impression Daviey's use-case is new?  Maybe not.
<cjwatson> Newish, yeah
<cjwatson> But indeed, I'd find this kind of thing pretty ... surprising post-release
#ubuntu-release 2013-03-18
<darkxst> stgraber, are you able to add ubuntuGNOME to the dailies iso tracker?
<knome> release team: bluesabre just filed LP 1156555, can you look at it and preferably give an ACK for FFe? the reason for the completely new version is that the old version refuses to run on raring...
<ubot2> Launchpad bug 1156555 in Catfish "[FFe] New Catfish version" [Undecided,New] https://launchpad.net/bugs/1156555
<knome> if you need any more information, comment on the bug or ask bluesabre on irc.
<stgraber> highvoltage, knome, Riddell, ScottK, zequence, phillw, (whoever else I forgot): Please make sure any slideshow change is in lp:ubiquity-slideshow-ubuntu by Wednesday 21:00 UTC. I'll review and upload on Thursday before UIF.
<knome> stgraber, will do. cheers!
<phillw> stgraber: okies
<xnox> stgraber: there is a request from U1 team to update U1 slide, but it's not yet in patch form =) requested assets to update the slide, hopefully we will make it.
<stgraber> xnox: you can tell them that I'm not planning on granting them a UIFe this time around (the Ubuntu slideshow has always been updated post-freeze and it's starting to annoy me), so they have it by Wednesday 21:00 UTC or we ship without it
<highvoltage> stgraber: not sure if I'd have the final one done by then, but I'll have something that can at least represent 90%+ of the final slides
<highvoltage> hmm, actually I might be able to do a bit of it tonight as well
<xnox> stgraber: If only I news who to tell though. As for example is quetzal everywhere and not raring. I only have some artwork for the u1 page.
<stgraber> xnox: yeah, I'm e-mailing Dylan too, he's been doing most of the Ubuntu updates the past few cycles.
<stgraber> highvoltage: what I said for Ubuntu applies for flavours too, I really have no intention in granting UIFe for slideshow changes that do more than fix something critical
<stgraber> highvoltage: the main reason being that I want us to ship something that's more than 20% translated for a change
<cjwatson> public-private cdimage diff: 189 lines ...
<stgraber> cjwatson: wow, nice!
<stgraber> cjwatson: does that mean we have a python publish-release now?
<cjwatson> No, that's still in shell
<cjwatson> I didn't feel it necessary to block on converting the things that were already (largely) public
<cjwatson> I rewrote the grotty Chinese edition code in Python this morning though, getting rid of a pile of publication duplication
<stgraber> oh that's good, that one always felt weird to me
<stgraber> (though I was hoping we'd just get rid of it entirely after the last 12.04 point release, now that we have Kylin)
<cjwatson> I expect we can stop building it at some point, sure
<cjwatson> Probably oughta get PES consent
<zequence> stgraber: Yep. Ubuntu Studio is good. Thanks
<cjwatson> Exactly one logical change remaining (production-specific proxy configuration).  Time to get coffee supplies before tackling that
<bjf> infinity, i have a bunch of kernels i'd like to go from -proposed to -updates
<cjwatson> lp:ubuntu-cdimage is now identical to the deployed branch
<cjwatson> (woo)
<Laney> \o/
<cjwatson> I've e-mailed committers with details of changed procedures
<stgraber> cjwatson: awesome!
<ogra_> to sad janimo isnt around now ...
 * ogra_ remembers two years of moaning about private branches :)
<infinity> bjf: I have the technology to make that happen.
<infinity> ogra_: Jani's still around...
<ogra_> just not here, yeah
<ogra_> (see -devel)
 * xnox ponders what we will do with crap stuck in raring-proposed at release time? move it to s-proposed & declare raring-proposed for SRU from that point onwards?
<xnox> that is considering the s-series codename is public early enough.
<slangasek> well, we'd rather like to not have crap stuck in raring-proposed at release time
<xnox> like all of haskell =)
<xnox> the other alternative is to force migrate stuff......
<Laney> Er, or fix it?
<cjwatson> Yeah, I'd prefer to just make it a target to fix it all
<cjwatson> I don't think that's especially unachievable
<xnox> ok.
<micahg> xnox: I see worst case as removing what's left unfixed to allow migration as a last resort, no need to force anything, but it seems that it should be fixable without that
<Laney> I'd rather people helped than cook up schemes to deal with brokenness
<micahg> Laney: I think I can do both ;)
<Laney> :P
<stgraber> so jbicha reminded me of https://lists.ubuntu.com/archives/ubuntu-release/2012-December/002140.html, does anyone have an objection with me doing a no-change upload of lintian 2.5.11ubuntu2 as 2.5.11.0ubuntu1?
<xnox> Laney: despite trying a couple of times haskell FTBFS on armhf but not other arches still confuse me and I have no clue what to do with them. And I'm constantly put-off by accidently triggering a new wave of migrations.
<stgraber> I'm not too familiar with lintian's versioning in Debian, but looking at rmadison, it looks like any bugfix release on the current lintian would be 2.5.11.1 so 2.5.11.0 should be safe to use
<Laney> xnox: don't look at those - they are targets for removal on the bad arches (compiler bug usually)
<Laney> look at the ones that are bad on all arches
<Laney> if you don't upgrade any lower down library you'll be safe
<xnox> Laney: ack.
<cjwatson> stgraber: Or 2.5.11ubuntu13 would do, wouldn't it?
<stgraber> cjwatson: yep, that'd work too
<cjwatson> I'd suggest going for that as the more conservative option
<stgraber> fair enough, will re-upload as 2.5.11ubuntu13 then
<infinity> xnox: AFAIUI, ghc on armhf is still a bit goofy.
<Laney> correct
<Laney> vastly better than it was but still somewhat wonkalicious
<infinity> xnox: As far as "stuff stuck in proposed near release", I concur with everyone, that "just fix it" is the right thing to do, though if one or two things remain broken, emptying the pocket right before release would be the sane last resort.
<infinity> xnox: Force-migrating stuff is a non-option, IMO.
<infinity> xnox: Since what we're testing for release is the release pocket, not some random combination with proposed.
<jbicha> stgraber: can't you just do 2.5.11ubuntu13?
<jbicha> nm
<blitzkrieg3> Is there anything more I need to do in order to get bug 445872 suitable for SRU?
<ubot2> Launchpad bug 445872 in OEM Priority Project precise "disable-disconnect-notification option ignored" [High,In progress] https://launchpad.net/bugs/445872
<blitzkrieg3> Another network manager bug
<cjwatson> Laney: haskell-conduit/armhf doesn't seem to be in the usual run of ARM build failures.  Is it fixable?  It'd be nice to avoid removing it, since it has a lot of reverse-deps
<Laney> cjwatson: Hmm, that might be the same thing - just that loading modules in GHCi doesn't crash the whole thing, maybe
<Laney> let me try a test build
<cjwatson> I removed some of the easy ones just now
<Laney> persistent is an annoying stack, and llvm I think needs some porting
<Laney> agda I will solve via Debian when I get a chance to sort out its deps
<Laney> bah, it's definitely broken - I can't ghci Data.Conduit.Binary (interpreted) without getting that same error, but if I compile some of the source files it loads fine
 * Laney heads foodwards
<infinity> Laney: I suppose it's too much to ask that someone just fix the compiler? :/
<tgm4883> Is there something special that needs to be done in order to have arm builds in the repo? We've got arm builds apparently happening (see https://launchpad.net/ubuntu/+source/mythtv/2:0.26.0+fixes.20121118.340b5d4-0ubuntu1/+build/3994497 ) but they apparently never get copied over to http://archive.ubuntu.com/ubuntu/pool/multiverse/m/mythtv/
<xnox> tgm4883: armhf & powerpc are hosted separately, They are here: http://ports.ubuntu.com/ubuntu-ports/pool/multiverse/m/mythtv/
<tgm4883> xnox, slightly confusing, but good to know that it is working. Thanks
<xnox> tgm4883: less frequently architectures are hosted on ports, to make our primary (widely-mirrored) archive smaller.
<tgm4883> xnox, I suppose that makes sense
<xnox> tgm4883: same as cdimages.ubuntu.com and releases.ubuntu.com images are slip in a similar fashion.
<cjwatson> The layout is documented here: https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Architectures
<darkxst> stgraber, are you able to add ubuntuGNOME to the dailies iso tracker?
<stgraber> darkxst: I saw the last 10 pings or so, it's on my list ;)
<darkxst> stgraber, ok cool, thanks!
<xnox> the haskell transition tracker would look nicer as a graphviz .dot tree, as some of the lines are actually leaf-nodes despite being half-way in the dependency level #
<tumbleweed> xnox: have you seen Laney's haskall transition graphs? a list is much saner
<xnox> only this: http://people.canonical.com/~ubuntu-archive/transitions/ghc.html
<xnox> tumbleweed: links?
<ScottK> stgraber: since the new Unity stack is already sabdfl'ed in after UIF, I suspect slide show updates are pretty unavoidable.
<xnox> ScottK: there is no "unity" per se slides. and the u1 slide is updated with the "new spread" mockup ;-)
<ScottK> k
<xnox> (probably dash is the right terms instead of the spread....)
<stgraber> right, I checked that this morning, the new unity won't affect the slideshow.
<stgraber> and I'm not planning on accepting any extra text/slide after Thursday, so they'd have to go through the whole escalation again if they want that
<xnox> infinity: https://launchpad.net/~xnox/+archive/scratch/+build/4379839 why is panda building amd64?
<infinity> It's not.
<cjwatson> It's not a Panda
<infinity> That's a Xen guest.
<xnox> unless the names are confusing for giggles =)
<infinity> With a silly name.
<cjwatson> It can build any of i386/amd64/armhf
<xnox> ok, giggles then....
<stgraber> darkxst: Ubuntu GNOME added to the list of products on the tracker. Next daily build should show up on there.
<stgraber> darkxst: you'll want to talk to balloons to get some test cases setup though
<darkxst> stgraber, thanks
<darkxst> sure, will do
<balloons> darkxst, :-)
<darkxst> balloons, Hey, so too start off with can you just copy the install (auto-resize, entire disk and manual) testcases from Ubuntu Desktop
<balloons> darkxst, sure thing
<ScottK> infinity: Does making LTS -> Current a supported upgrade patch need a TB decision or can we JFDI?
<infinity> ScottK: It might need the weight of the TB to become project-wide policy though, honestly, if Foundations is on board, we have a pretty big lever to use on others.
<cjwatson> It kind of seems like a "we should suck less" thing, although it might not hurt to have a TB decision to point to when people say "this isn't supported"
<stgraber> ScottK: I think it's fine to JFDI and then have the release team do the job of advertising it as a supported upgrade path
<infinity> And I can't imagine anyone in Foundations being against it.
<cjwatson> (Which they always do)
<ScottK> We can take it as an implied result of the shortened support window ...
<infinity> Anyhow, I think we (Foundations and Release) can JFDI, tell the world about it, and *then* bring it to the TB to formalize if needed.
<cjwatson> We'll need QA, but I think we've discussed this with them ...
<infinity> We have.
<infinity> jibel was on board.
<infinity> And I think was already going to set things up?
<darkxst> balloons, also "Live Session" and Upgrade test cases
<cjwatson> Right, good
<xnox> ScottK: one thing to support it, another thing to enable the jumps in upgrade-manager / do-release-upgrade directly for the unsuspecting users.
<cjwatson> My argument here has always been that if we *don't* aggressively make upgrades to current from anything-supported work, then we just end up trying to put the pieces back together in a few months before the LTS
<infinity> Exactly.
<cjwatson> And history suggests that we find out about a lot of the problems when the first batch of not-us users upgrade
<infinity> We're doing ourselves a favour by doing it right in the first place.
<cjwatson> Obviously, not that we shouldn't continuously improve our ability to detect things in advance, but ...
<stgraber> right, we'll likely have to spend a tiny bit more resources to test this mess though, but that's mostly automated resources
<stgraber> the gain being much more reliable upgrades and less pain when we reach the next LTS
<infinity> stgraber: The resouces spent by testing all the upgrade paths pay for themselves when we don't have to fix the LTS in a mad rush.
<infinity> It's amazing the bitrot you get when people ignore a problem for 2 years.
<stgraber> infinity: sure, I'm just saying that on paper, we'll be spending more resources (money in hardware) testing all the combinations (because there will be double the tests to do) but that leads to a reduced human resource cost when preparing the LTS. So definitely worth it.
<infinity> doko: Speaking of opening new releases in PPAs, I won't be joining you for the 13.10 opening, since glibc 2.18 isn't released until June.
<infinity> stgraber: *nod*
<doko> infinity, I don't care about 13.10
<infinity> doko: ;)
<xnox> doko: cjwatson: i was hoping to open with boost1.53 by default.
<ScottK> xnox: First thing to a newer boost by default being a "good" idea is to get Debian to move to a newer default.  Go fix RC bugs so Wheezy gets released.
 * xnox goes to file ffe to sync boost1.53 into raring.
<xnox> ScottK: seriously I look at the current set of RC bugs and they either have lengthy debates on how to best fix it among a few DDs or they are mostly licensing/brokeness issues that have been around from a few releases back or security bugs.
<xnox> not much i can help with =(
<xnox> debian should just release.
<xnox> also i'm confused how security bugs are RC, considering that they will be finding and fixing CVEs all throughout wheezy's timespan anyway.
<ScottK> python3-defaults migrated to wheezy last night, so I'm ready ...
<Laney> infinity: I think that's a big "just". I've been trying to get someone to look at itâbeyond my skills and timeâbut no luck yet.
<infinity> Laney: Yeah, I know.  If I cared even remotely about ghc, I'd waste some weekends on it but, frankly, I don't.  I'd be just as happy punting haskell from the archive.
<Laney> Still, I'm continuing to hope and occasionally pester
<infinity> Then again, I'd be happy punting python too, so my opinions might not matter.
<Laney> I'm pleased that some people found some time/funding/whatever it was to get ghc to its current state on arm, TBH
<infinity> C, C++, Perl, make, and a POSIX shell are all I need.
<Laney> it was fairly dire before
<infinity> Laney: Well, with any luck, the armhf-specific bugs might get shaken out as a side-effect of people doing an arm64 port (which I assume someone will).
<infinity> Laney: Since, IIRC from Q, most of the compiler segfaults and miscompilations we're seeing were armhf-specific, and armel worked just fine.  So probably just some bad register arithmetic or similar.
<Laney> Hopefully it'll turn out to be something easy for someone who knows all that stuff
<infinity> Well, it's easy to stab in the dark at probably causes (and probably even be right), but a bit harder to fix since I don't know thing one about ghc.
<infinity> Really, what you need is someone who knows ARM things inside out to sit down with someone who knows GHC inside out, so person A can tell person B "your probablem is probably X", and person B can translate X to ghc-specific Y.
<infinity> s/probablem/problem/
<infinity> Could be as simple as the armhf port being vfpv3 instead of vfpv3-d16, thus making any call with enough arguments to overflow registers land said arguments in la-la land.
<Laney> Jani did fix some stuff around that before
<infinity> Which would explain why it only happens sometimes.
<Laney> I wonder if he has any brain state in that area left
<Laney> Bed. If I get some time tomorrow I'll chop this 589 line reproducer down some
<infinity> Laney: Is it something that reproduces a compiler segv, or something that causes the compiler to generate code that segvs?
<infinity> Laney: The former would be beyond what I can debug without knowing ghc really well, but the latter would be interesting to disassemble and go "oh, well, duh."
<Laney> It's something that the interpreter fails to load, which I reckon will turn out to be a very similar bug
<Laney> The general form of the problems is the former though - I haven't come across any programs that have compiled successfully then fail to work
<Laney> Also useful to note is that it's using an LLVM backend on armhf. It's not generating native code.
<Laney> Real bed.
<infinity> Oh, hrm, if it's using LLVM, I may well have a clue as to where the bug lies.
<infinity> I'll have to find a round tuit and poke later.
#ubuntu-release 2013-03-19
<jibel> infinity, cjwatson I did a quick verification last week and the auto-upgrade-test doesn't support the upgrade from an LTS to the current dev release out of the box. It upgrades to the latest stable. I'll spend more time on it this week.
<tkamppeter> CUPS 1.6.2 is out. It is a bugfix-only release. Can I upload it?
<seb128> tkamppeter, if it's only bug fixes and no new feature, yes
<tkamppeter> seb128, OK, so I will go ahead.
<seb128> tkamppeter, thanks
<jibel> infinity, cjwatson re upgrade from LTS to current dev release, I had a look and it's a bit counter-natural for the upgrader. Here are the changes required to allow this upgrade path:
<jibel> 1. Add raring to http://changelogs.ubuntu.com/meta-release-lts-development
<jibel> 2. in update-manager-core on Precise change the logic in UpdateManager/Core/MetaRelease.py lines 228-232 to consider the latest dev release as a valid upgrade instead of stopping at the first upgradable release (quantal)
<jibel> 3. in ubuntu-release-upgrader on Raring add DistUpgrade.cfg.precise with From=precise and To=raring in the Sources section
<jibel> With these changes I could upgrade a server image from precise to raring
<jibel> infinity, cjwatson I can force 1 and 3 with the upgrade-tester but not 2
 * cjwatson fixes the overnight build failure and respins
<cjwatson> jibel: that doesn't seem *too* awkward; shame it'll require an SRU
<rtg> I think the kernel armhf build has stalled. 18 hours seems like quite a lot. https://launchpad.net/ubuntu/+source/linux/3.8.0-13.23/+build/4379671
<cjwatson> You'll need to ask #webops (internal IRC)
<cjwatson> Could somebody look at NEWing tk8.5 and tcltk-defaults, so that I can move on with the ruby1.8 change based on those?
<cjwatson> Trying to unstick a fairly long chain of stuff
<seb128> cjwatson, looking
<cjwatson> thanks!
<seb128> yw ;-)
<ogra_> does this look ok for a seed change to add touch: http://paste.ubuntu.com/5628377/
<ogra_> ?
<cjwatson> Why Task-Seeds: ubuntu-minimal?
<ogra_> thats how the quantal image is currently built
<cjwatson> The effect of that is to incorporate entries from minimal directly into the ubuntu-touch metapackage
<cjwatson> Maybe, but it's wrong :)
<ogra_> standard has to much overhead i was told
<cjwatson> You shouldn't use Task-Seeds for things that already have their own metapackage
<cjwatson> minimal vs. standard is a different issue
<ogra_> oh, ok
<cjwatson> What I'm saying is that the Task-Seeds line shouldn't be there at all
<ogra_> yeah, got that, the STRUCTURE line is enough
<cjwatson> Other than that it looks fine to me
<ogra_> great, committing
<ogra_> and pushed ...
<cjwatson> Oh, one missing thing - you need to add touch to the inheritance of some other seed, probably supported
<cjwatson> Otherwise the packages in it won't be kept in main
<ogra_> not sure we want them in main yet
<ogra_> since the packages that are pulled in arent either
<cjwatson> Well - it's kind of invalid to have things in that seed collection that aren't inherited by supported
<ogra_> ok
<cjwatson> But I guess it might work temporarily
<cjwatson> Is there a project somewhere to get everything in touch MIRed?
<cjwatson> I mean, yes, adding touch to supported would trigger immediate component-mismatches for everything in it, so if you don't want that then it might not be the best idea
<Laney> I didn't think that touch in main was a goal for raring - is it?
<ogra_> you mean adding it to the last line in STRUCTURE right ?
<ogra_> Laney, well a goal was to have a regular overview
<ogra_> of whats missing etc
<ogra_> so component mistmatches might be a good tool here
<cjwatson> Maybe best leave it out of the last line in STRUCTURE for now
<ogra_> ok
<cjwatson> We need component-mismatches for other things, and if it isn't a target for raring then making it harder for ubuntu-archive to do other jobs isn't a good plan
<ogra_> we wont have everything merged by raring release
<ogra_> there are intrusive changes to such minor things like NM :)
 * cjwatson goes to update tasksel
<ogra_> which wont make it before release
<cjwatson> Not that it matters, but
<ogra_> ubuntu-meta will just magically pick it up without any intervention, right ?
 * ogra_ hasnt changed./added seeds in quite a while
<ogra_> ah, update.cfg ...
 * ogra_ remembers ...
<ogra_> hmm, but that wants main indeed
<cjwatson> Without main inclusion, I'd recommend a separate -meta source package
<ogra_> hmm well, after all it is supposed to end up on the same meta in the end
<ogra_> i would even go that far to claim that we'll have images containing touch and desktop at the same time at some point
<ogra_> (convergence)
<cjwatson> I'm not saying it should be in a separate source package permanently
<cjwatson> But for now, it will be easier
<ogra_> and lool and slangasek actually want me to start building images even of they fail
<cjwatson> As long as you keep ubuntu-touch-meta's version number lower, it won't be a painting-self-into-corner problem
<ogra_> (which i think makes no sense just to see whats missing)
<cjwatson> ubuntu-meta can just take over the binary once it moves to main
<cjwatson> (Yes, ubuntu-meta can technically produce a binary package in universe.  But getting germinate-update-metapackage to DTRT without breaking the other binary packages' dependencies is going to be a pain, and I don't think it's worth it)
<stgraber> just filed bug 1157227 whenever someone else on the release team has a few minutes to look at it. The main goal here is to get us closer to the final upstream release (currently on an alpha) so we can release 13.04 without having to worry too much about maintenance.
<ubot2> Launchpad bug 1157227 in lxc (Ubuntu) "[FFe] Get LXC 0.9~rc1 to replace the current 0.9~alpha1" [Undecided,New] https://launchpad.net/bugs/1157227
<Laney> I was looking at it
<Laney> let me build packages to see if my stuff continues to work ;-)
<lool> ogra_: well I've suggested that and you've pushed back; we didn't discuss the specifics, but yes, I think we could either build against the target seeds even if that fails and use the failures as a todo list, or we could create the seed with some of the missing packages as commented out and build semi-broken images
<lool> My main goal was to parallelize the efforts of getting the images building with the efforts of pushing stuff to raring
<cjwatson> It doesn't make any difference to image building whether ubuntu-touch is built from ubuntu-meta or ubuntu-touch-meta
<ogra_> lool, the issue is that it will spam component-mistmatches all the time (though as i understood that was said todo list)
<cjwatson> No, that also isn't affected by image building
<ogra_> no, but by moving the packages to the archive and main
<cjwatson> Since we've agreed not to add it to supported's inheritance list, it won't spam component-mismatches
<cjwatson> We could produce a separate mismatches report
<cjwatson> It wouldn't be the first time
<ogra_> quite some effort for just some weeks
<cjwatson> Some weeks spanning a release
<cjwatson> And component-mismatches is expected to be empty at release
<ogra_> well, S opens in what 6 weeks ?
<ogra_> i would just go with universe for now if lool and slangasek agree
<lool> ogra_: sure thing
<ogra_> instead of putting effort into creating separate reports etc
<cjwatson> Well, sure, I was just saying that having a bunch of stuff known-not-ready in component-mismatches across raring release isn't a viable option
<lool> ogra_: we don't need main/universe distinction, at least not in the short-term
<ogra_> right and i agree
<ogra_> i was just echoing what i understood i was supposed to do :)
<lool> yup
 * ogra_ creates ubuntu-touch-meta 
<cjwatson> Let me know if you need help with that
<cjwatson> Done it a few times now :)
<ogra_> i'll just grab xubuntu and fix it up
<Laney> stgraber: I still haz working containers, at least ;-)
<stgraber> Laney: good to hear ;)
<Laney> yeah, seems fine to me
<Laney> goferit
<stgraber> yay, thanks!
<cjwatson> ogra_: do you know what the jenkins hostname/IP address is for my WI in https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-cdimage-android-builds ?
<ogra_> yep
<ogra_> cjwatson, http://10.97.0.6:8080/job/ubuntu-touch-image
<cjwatson> ogra_: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt <cough>
<cjwatson> I probably need to look at why that's happening :)
<ogra_> cjwatson, more details are in my sync-phablet-images script
<ogra_> in ~ on nusakan
<cjwatson> Right
<ogra_> urlpath=$jenkinsurl/job/$project/$ver/artifact/archive
<ogra_> thats the relevant bit
<cjwatson> I'll fix up c-m after this call
<ogra_> hmm if you black/whitelist that anyway we could as well with the ubuntu-meta change
<cjwatson> Nah, easier to use the component-mismatches command-line option to exclude a seed
<ogra_> ah k
<cjwatson> ogra_: Ah, hmm, it's actually really tricky to exclude this from component-mismatches
<cjwatson> I've used '-e touch', but that only excludes things that are direct run-time/build-time dependencies - it doesn't help with the case of extra binaries from the same source which then pull in other (build-)dependencies
<ogra_> hmm
<cjwatson> And I'm not sure it's successfully excluding build-dependencies
<cjwatson> ogra_: Would it be possible to move this to a separate seed collection for now?
<cjwatson> I'm happy to set that up for you if you like
<cjwatson> (I'd need to have some involvement anyway)
<ogra_> sigh, yeah ... still i think its a waste of manpower for just a few weeks
<infinity> So is making c-m useless.
<ogra_> we'll merge them once S opens
<cjwatson> It's a bit of effort, but not horribly much, and I can see the point of convergence here
<cjwatson> I mean, I think in general having the definitions in seeds earlier rather than later is a good thing
<ogra_> infinity, right, i would rather postpone
<cjwatson> I'll just move it to a separate branch for now, then
<ogra_> having everything prepared to merge with a finger snip
<cjwatson> It'll be easy to move back later (though we might not get to keep the history of the seed)
<ogra_> ok, tell me the branch name for the meta then
 * ogra_ hates such throw away work
<ogra_> (regardless who does it ... it currently doesnt serve any purpose and will be thrown out before it gets useful)
<cjwatson> Does lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.raring look OK?
<infinity> ogra_: Branches are cheap, it's not really that much work.
<infinity> (Less work than the discussion that preceded it)
<ogra_> cjwatson, looks fine
<ogra_> infinity, heh
<ogra_> infinity, btw, i guess we need to sit down at some point and come up with something completely new for the ondemand script  .... it causes some havoc on phablet (my phone glows until i remove it and reboot for example)
<cjwatson> That said, the component-mismatches explosion wasn't as bad as I expected, which bodes well
<ogra_> well, its only ~60 packages
<cjwatson> I mean, still non-trivial work, but could be worse
<ogra_> and many are there already
<cjwatson> OK, so I've removed touch from ubuntu.raring again
<ogra_> yep, thanks
<infinity> ogra_: Your phone glows?  Neat.
<cjwatson> You'll want to adjust ubuntu-touch-meta
<cjwatson> I made sure ubuntu-touch.raring was mirrored in the standard location (http://people.canonical.com/~ubuntu-archive/seeds/) too
<ogra_> infinity, well ... :)
<cjwatson> ogra_: Do you know if 10.97.0.6 is also the host we'd need to prod with an ssh trigger?
<cjwatson> (I can ask Sergio if you're not sure)
<ogra_> i think thats where all the test image runs are, yeas
<ogra_> [i386] Loading seed lists...
<ogra_> * Checking out bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.raring/
<ogra_> * Checking out bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.raring/
<ogra_> ! Could not open supported from checkout of (any of):ile 30/36
<ogra_> hmm
<ubot2> ogra_: I am only a bot, please don't think I'm intelligent :)
<ogra_> that doesnt look happy
<ogra_> i guess i need to wipe supported from STRUCTURE
 * ogra_ does so and tries again
<cjwatson> ogra_: no
<cjwatson> ogra_: better to add an empty supported seed
<ogra_> ah
<cjwatson> the last seed has weird semantics
<ogra_> ok
<cjwatson> sorry, my bad for getting that wrong in the first place
<Laney> xnox: â ubuntu-quality@ too, perhaps?
<xnox> Laney: oh, i had no idea about ubuntu-quality@ not sure I am subscribed.
<Laney> I'm sure balloons can moderate it for you
<balloons> xnox, Laney i sure can moderate.. I'll forward if you don't want to crosspost xnox, but many on the list will be keen to read it
<xnox> balloons: ack, cool.
<xnox> balloons: and thanks.
<slangasek> ogra_: doesn't serve any purpose> it serves the purpose of making sure any phablet images we're building today have their definition where it should be - in Ubuntu, not in some out-of-the-way jenkins job definition.  Please do not underestimate the importance of this
<ogra_> slangasek, well, i'm nearly done anyway no worries ...
<ogra_> just waiting for the ./update script to finish and will upload the new meta
<ogra_> slangasek, i dont underestimate the importance but i think it could have waited four weeks
<slangasek> no, it can't
<ogra_> now its done though :)
<slangasek> four weeks is a LONG time
<xnox> stgraber: ubuntu slideshow - READY =)
<ogra_> hmm, i wonder why i dont seem to have any WI for creating the touch seed
<seb128> ogra_, not sure about touch, but you have one on https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-arm-reduce-footprint for the common/nexus seed
<ogra_> seb128, well i consider that obsolete/suspended atm
<ogra_> i just added one for touch
<seb128> ogra_, right, you can either recycle or it POSTPONED it
<ogra_> i'll postpone ... i guess it will come up for convergence again at some point
<seb128> right
<seb128> thanks
<ogra_> ubuntu-touch-meta-1.001 sits in NEW ... i would appreciate a review and pass :)
<cjwatson> looking
<ogra_> ah there it is
<ogra_> its completely empty atm .. "? Unknown touch package: ..." for all the packages ...
<ogra_> which should be right atm
<cjwatson> $ cat metapackage-map
<cjwatson> touch ubuntu-touch-touch
<ogra_> eek
<cjwatson> was fine when the seed collection was ubuntu
<ogra_> does the script add that ?
<cjwatson> needs a seed fix
<cjwatson> one moment
<ogra_> ah k
 * ogra_ wishes ./update wouldnt take ages ... it wrangles with an x86-android repo sync i'm running here
<cjwatson> you should drop override_dh_germinate_metapackage too
<stgraber> cjwatson: hey, do you happen to have a list of dependencies for run_test in lp:ubuntu-cdimage?
<cjwatson> ogra_: rejecting for both the above - could you re-update?  I've fixed the seeds
<ogra_> done
<ogra_> yep, running
<cjwatson> stgraber: should be just python-mock, plus python3 to run the python3 tests as well
<stgraber> cjwatson: actually, I just figured it out. It's: python-mock, python3, procmail, squashfs-tools and having your system use the GMT timezone
<cjwatson> oh, I forgot about procmail
<cjwatson> and yeah, squashfs-tools for test_check_installable
<cjwatson> GMT timezone is a bug
<cjwatson> what fails if you don't?
<stgraber> cjwatson: a bunch of string match fail
<stgraber> cjwatson: test_sync_lock_failure is one of them
<cjwatson> huh, let me see if I can reproduce that
<stgraber> cjwatson: there's basically a timestamp in the log file which contains the timezone abreviation
<stgraber> cjwatson: might be worth calling "date -u" or similar, to generate timezone neutral timestamps
<cjwatson> It's meant to but I obviously missed something
<cjwatson> I'll fix that, thanks
<cjwatson> It's already using time.gmtime(), so I think I just shouldn't have used %Z
<cjwatson> stgraber: r1140 fixes timezone handling; r1141 documents dependencies
<stgraber> cool, thanks
<stgraber> jbicha: next daily build of Ubuntu GNOME will be auto-published on the iso tracker.
<stgraber> there was a small bug in the publishing script (wrong product name) so the past couple of builds didn't publish
<ogra_> there we go, next try
<ogra_> i left ppc out btw ... i hope nobody minds :)
<cjwatson> stgraber: aha, thanks
<cjwatson> ogra_: LGTM
<ogra_> thx
<ogra_> yay
<dobey> was just reading the TB meeting logs from yesterday, and it looks like it was decided that support period would be 9 months starting with 13.04. is that correct, or still need votes/opinions from the absentee TB members?
<stgraber> that's correct
<stgraber> IIRC 3 members + chair is the minimum requirement for TB quorum and we had that yesterday. Anyway, the 3 other members indicated their support to the proposal by e-mail to the TB mailing-list before the meeting.
<cjwatson> Indeed.
<dobey> ok
<dobey> right, that's how i read the log. i just wanted to confirm. thanks :)
<ScottK> So I saw Bug 1157191 today and suddenly my ability to maintain state of PS generated FFe requests has collapsed.
<ubot2> Launchpad bug 1157191 in ubuntu-ui-toolkit (Ubuntu) "[FFe] API updates for MainView, PageStack and Tabs " [Medium,Confirmed] https://launchpad.net/bugs/1157191
<ScottK> seb128: Could we perhaps get a complete list of the stuff they still have to land?  It seems like it's something new every day.
<seb128> ScottK, I though there was an agreement/understanding that ubuntu-touch work in universe could go in without issue?
<seb128> slangasek, ^
<seb128> ScottK, that shouldn't impact on the release or on any flavor...
<ScottK> seb128: There was some discussion about a general FFe request for such things, but I've never seen the request.
<ScottK> Right.  That one's not particularly a problem.  It's just they keep coming.
<slangasek> seb128: right, what ScottK said... I think I was supposed to file the FFe request and dropped the ball, sorry about that
<ScottK> It'd be nice to get everything on the table and reviewed once.
<slangasek> wrt the new packages, it should all be done as a single blanket FFe
<seb128> slangasek, new like "not in the archive yet"? or like "new from this cycle that is under active work" (like the ui toolkit)?
<ScottK> But the blanket FFe should list them all, so we know what's approved already and what's not.
<seb128> ScottK, afaik the "only" 2 FFe from the #ps team are the scopes one (that sabdfl overruled) and the in-dash-payment one
<slangasek> seb128: new like "new this cycle for the touch stack and not touching any Ubuntu images"
<seb128> slangasek, ok, thanks
 * ScottK gives up and approves ALL the FFes.
<ScottK> Actually not, but am tempted.
<phillw> what is the actual size (disk space) of a full repo mirror as per https://launchpad.net/ubuntu/+archivemirrors and where should I head to for more details?
#ubuntu-release 2013-03-20
<cjwatson> phillw: I could probably compute it in time, but #ubuntu-mirrors probably has somebody who knows off the top of their head
<phillw> cjwatson: soz, it's about 700GB, but was not the question the person who asked me really meant. He meant that a lot of mirrors seem 'out of sync', to which your answer is the best as I did not know that the channel existed. Thanks for the link :)
<xnox> so i have run the archive-scanner and got an updated tarball of postprocessed .desktop files and icons.
<xnox> looking at app-install-data-ubuntu though, the layout is a bit different.
<xnox> am I correct to assume that I should more or less, update the menu-data/ subfolder with the tarball I got from the archive scan and that's the gist of it?
<xnox> stgraber: cjwatson ^^^
<stgraber> no idea, my knowledge goes as far as "ping mvo" for that one ;)
<xnox> stgraber: it's just i spotted menu-data-edubuntu that is all =)
<infinity> We've pretty miserably failed at knowledge sharing on how that all works.
<infinity> But if doing what you said produces a plausibly sane package that's kinda like the old one, that might be right. :P
<infinity> And it might really need a README.source
<Laney> right, I'd say ping mvo to help you walk through it and make damn sure it's documented well enough for someone else to do it next time
<Laney> you can use me to retrace your steps to see if we end up with the same thing
<infinity> Indeed, if Laney can do it, it's probably foolproof.
 * infinity ducks.
 * xnox goes to do validation / comparison.
<Laney> !coc | infinity
<ubot2> infinity: The Ubuntu Code of Conduct is a community etiquette document to which we ask all Ubuntu users to adhere | http://www.ubuntu.com/project/about-ubuntu/conduct  | For information on how to electronically sign the CoC, see https://help.ubuntu.com/community/SigningCodeofConduct | Watch http://static.screencasts.ubuntu.com/videos/2010/12/22/004-SigningCoC.ogv
<Laney> :P
<infinity> *cough*
<xnox> infinity: i believe Laney deserves to be slapped around a bit with something wet =)
<infinity> To be fair, the CoC leaves no room for good-natured ribbing, he's not wrong that I violated it.
<infinity> I just think the CoC is wrong. :P
 * Laney backs away slowly
<xnox> Laney: you did that and didn't get reminded about !coc
<Laney> I look forward to your trout in Oakland
 * xnox notes to check if Scottish Trout is O.K. with USA Customs and Border Protection 
<cjwatson> xnox: that's what I understand, but I've only ever driven this from the client side, never attempted to run the archive scanner.  There's a script for it which did the right thing last I checked without layout changes, so I'd tend to interpret a layout change as a sign of something being wrong
<cjwatson> I don't remember which of update-menu-data.sh and update-menu-data-from-file.sh I used
<xnox> cjwatson: right, that's correct. That script will take my generated tarball, the two are compatible.
<cjwatson> except that it appears to be producing unusual output :)
<xnox> it's just that there are a few more util scripts in the ubuntu package like: addKeywords.py addPopconData.py and I'm not sure if I should run it.
<xnox> cjwatson: oh, I was expecting .orig.tar.gz from the archive scanner, without the step of "importing" that into the ubuntu package.
<xnox> cjwatson: the import script & the archive-scanner tarball look like a matching pair with nothing unusual.
<cjwatson> the util scripts you refer to are run by pre-build.sh
<cjwatson> so use bzr bd -S
 * xnox did apt-get source, totally forgot about mvo's love for pre-build scripts & bzr-bd hooks
<bdmurray> could someone have a look at bug 1157721?
<ubot2> Launchpad bug 1157721 in Ubuntu CD Images "jigdo for ubuntu-12.04.2-alternate-amd64.jigdo file not found " [Undecided,New] https://launchpad.net/bugs/1157721
<cjwatson> looking
<cjwatson> (fwiw I get cdimage bugs in my inbox)
<bdmurray> ah, I'd forgotten about cdimage and the project changed on me
<cjwatson> anyway, duped, and unfixable
<xnox> commented on how this can actually be solved with redirects and launchpadlibrarian =)
<xnox> cjwatson: Why does archive.ubuntu.com Release file mentions all architectures and not just those that are on archive.ubuntu.com? Or Release.gpg can only be generated at the place that has no idea that we have archive/ports.ubuntu.com split?
<cjwatson> the latter
<xnox> ack.
<cjwatson> "unfixable" in the sense that it can't be fixed on cdimage alone, but needs infrastructure work elsewhere
<cjwatson> -> SEP
<xnox> ack.
 * xnox ponders how "helpful" is adding popcon data to the app-install-data given that there is no UI left to enable popcon....
<xnox> Is http://popcon.ubuntu.com/by_vote still our destination popcon? (me remembers vague talks that we stated submitting popcon data to debian instead....)
<TheDrums> xnox: Last I looked, popcon hasn't been updated for quite a while.
<darkxst> balloons, did you add those testcases yet for ubuntu GNOME?
<balloons> darkxst, yes
<balloons> http://iso.qa.ubuntu.com/qatracker/milestones/243/builds/40208/testcases
<darkxst> ah yes, now I see them
<darkxst> did you add upgrade ones?
<balloons> those products don't exist.. and in general, no reason to exist yet :-) You don't have a previous release
<darkxst> balloons, well we do have the previous unofficial release, but I am not sure how well upgrading will work from that
<stgraber> not too surprisingly at least one slideshow is broken in the current ubiquity-slideshow-ubuntu branch... good thing I asked to be ready 24h before the actual freeze :)
<robru> so this new gexiv2 has some new API that I suspect might break/regress some of the applications using it. assuming that I can confirm the breakage happens, what steps should I take to mitigate that before raring is released?
<Laney> you mean third party apps?
<robru> yeah
<Laney> robert_ancell checked the archive
<robru> there are a bunch of new apps that were ported to gexiv2 0.5 that probably aren't in the archive yet.
<robru> so basically, back in copenhagen I was encouraging people to port their python apps away from pyexiv2 towards gexiv2. at the time, gexiv2 was only used by shotwell, and yorba guys got a bit freaked out by the prospect of more people using gexiv2, so they did a major API cleanup sweep. I meant to pay closer attention to it, but it got away on me
<robru> I don't think any of the gexiv2 ports have actually landed yet, but I'm concerned that upstreams are going to be frustrated by this breakage as they attempt to land
<Laney> Possibly, but it would have happened sooner or later anyway
<Laney> At least it's not tied to the Raring schedule so they are able to update at a more leisurely pace
<Laney> and if it's what upstream wants to expose as their stable API then it's probably worth the pain now, given that the ports are still WIP
<robru> Laney, what I meant was, "I had the chance to work with yorba and reduce the impact of API breakage by writing some compatibility glue for them, but I totally blew it, and now I'm afraid that consumers of gexiv2 are gonna get burned by some API breakage hell"
<robru> I don't know what to do now ;-)
<Laney> Hah, well you can still work with them and get that in for S (which will presumably be the Ubuntu target for these ports)
<robru> I guess what I'll have to do is test some things out, see how bad the breakage really is. If it's really bad, what are the chances that I could still write that glue code, and then just have it as a distropatch on gexiv2?
<Laney> or ... work with the upstreams on the ports
<robru> is it too late to save raring? :-/
<Laney> depends how fast you can work ;-)
<robru> Laney, basically what would need to be done is to re-implement a couple python methods in GExiv2.py that used to be implemented in C code... so althought I'm writing "new" code, I'd really be restoring API that used to be there in 0.5. What kind of a deadline am I looking at for a patch like that?
<robru> Laney, maybe a dozen lines of python
<Laney> robru: well, I suppose we'd have to see it, but if it really will be that limited in scope then it should be fine for the next week or two (preferably before the beta freeze)
<robru> Laney, you made a good point about "what upstream wants to expose as their stable API", so maybe I'll just leave it as-is and work with gexiv2 consumers to adjust to the new API. ok, I'll have to do a bit of research now. thanks
<Laney> I think you'll have to do those adjustments anyway at some point as the compat API is presumably not going to be around forever
<robru> Laney, exactly. distropatching is extra effort for little gain
<Laney> If you decided to add it in S-series we could put the new gexiv2 in backports, BTW
<Laney> so these upstream PPAs or whatever would be able to make use of it for raring
<robru> Laney, good point also
<Laney> not sure I have a good answer for extras though
<bdmurray> the pending sru report has become empty
<Laney> seems to be there now
<RAOF> I totally did ALL THE SRUs yesterday :)
<xnox> Thanks for boost1.53, not sure who synced it =) beat me by 40minutes ;-)
<xnox> armhf still has another 2 hours to go =)
<xnox> ah, doko. Thanks. yeah we do need -2 for python FTBFS fixes.
#ubuntu-release 2013-03-21
<doko> xnox, do you already have an updated boost-defaults package?
<xnox> doko: not yet, working on it. i didn't do a -defaults update yet before =)
<xnox> doko: where would you want it uploaded?
<doko> xnox, ubuntu-toolchain-r/test ppa (but you can't upload there)
<xnox> doko: i'll give .changes url.
<xnox> doko: http://people.canonical.com/~xnox/repo/boost-defaults_1.53.0.0ubuntu1.dsc
<xnox> changes are near by as well.
<xnox> http://people.canonical.com/~xnox/repo/boost-defaults_1.53.0.0ubuntu1_source.changes
<xnox> i think it's correct & includes newly added modules, et al.
<ScottK> xnox: Please let's not update boost-defaults.
<ScottK> xnox: Don't you think changing the default boost version is some that ought not be done after feature freeze without some discussion, particularly when we picked at the START of the release cycle what boost we would use?
<ScottK> xnox: Also, if you're introducing 1.53, please take care to get rid of 1.50 at the same time.  We don't want more boost in the archive than we can help.
<infinity> ScottK: He's changing the boost defaults in the toolchain archive for the opening of 13.10.
<ScottK> infinity: changes says Distribution: raring
<infinity> Yes, because there's no Distribution: s-series yes.
<infinity> The toolchain PPA is all built against raring, but will be used to open the next release.
<ScottK> Also, that still should have some discussion as historically getting ahead of Debian on boost is fraught with pain.
<ScottK> Chasing version numbers is not a good reason to change.
<infinity> I won't disagree with those statements.
<infinity> xnox: Is there a valid reason for wanting to skip ahead of Debian with boost-defaults, or is it just shiny new versionitis?
<ScottK> I am considerably less panicked now that I know it's for S though.
<xnox> infinity: ScottK: doko, boost debian maintainers and I are discussing this. Indeed we are currently proposing a rebuild against boost1.53 and patches to debian & do it for s-series. Boost1.53 is in unstable already and the plan is to start boost transition as soon as new debian opens.
<xnox> infinity: it's shiny, new, non-borked C++11 which we need/want across the board in time for gcc-4.8 (with improved C++11 is due soonish http://gcc.gnu.org/ml/gcc/2013-03/msg00036.html )
<ubot2> gcc.gnu.org bug 2013 in c++ "g++ 2.96: typedefs + namespaces + inheritance == problem" [Normal,Resolved: fixed]
<xnox> ubot2: that was unhelpful =)
<ubot2> xnox: I am only a bot, please don't think I'm intelligent :)
<xnox> ta
<infinity> xnox: Fair enough.
<Daviey> bdmurray: hey, there is a 3rd (!) upload for ubuntu-geoip.. Would you mind taking a look at it?
<bdmurray> Daviey: sure
<xnox> infinity: please remove boost1.50 from raring, as we have 1.53 instead.
<xnox> bug 1158458
<ubot2> Launchpad bug 1158458 in boost1.50 (Ubuntu) "[RM] please remove boost1.50 from raring" [Low,Triaged] https://launchpad.net/bugs/1158458
<infinity> xnox: Has no rdeps?
<infinity> I guess I can look for myself.
<xnox> infinity: i couldn't find any....
<xnox> infinity: maybe remove these two as well? https://bugs.launchpad.net/ubuntu/+source/guile-1.6/+bug/1154491
<ubot2> Launchpad bug 1154491 in guile-db "Please remove guile-1.6 from the archive" [Low,Confirmed]
<dobey> hopefully the uploads i just managed to squeeze in aren't rejected :)
<xnox> i think at FF we did something like 1.5h of grace time =)
<dobey> yay
#ubuntu-release 2013-03-22
 * cjwatson accidentally adds images to the tracker with bogus dates, and fixes
<cjwatson> (Ubuntu precise alternate/desktop/server, if anyone's keeping track)
<seb128> can a python LGPL 3+ source import a LGPL2.1 .py or is that buggy?
<xnox> seb128: i think that's fine. one cannot copy it into their source tree and modify lgpl2.1 only and redistribute the whole thing under lgpl3 though ( i think that's the restriction)
<xnox> i.e. patches to lgpl2.1 .py should be licensed under lgpl2.1.
<seb128> xnox, can they copy it in the source, not modify it, and ship the source as LGPL3 ?
<xnox> seb128: yes, if they do not modify it.
<xnox> seb128: in debian/copyright, I'd suggest to spell out that file as lgpl2.1
<seb128> hum
<seb128> they did modify it
<seb128> they imported in source to port in to python3, the time upstream would review/include their patch
<seb128> so I guess that doesn't work?
<xnox> seb128: then those patches to that file only, should be licensed under 2.1 or (dual-license under 2.1 and 3)
<xnox> seb128: it's all fine, as long as 2.1 is still granted on those patches. One can link lgpl2.1, lgpl3 and gpl3 code together.
<seb128> xnox, how does that work, if you have sources that are lgpl2.1 (only, not "+") and lgpl3 ... what's the license of the binary?
<xnox> the combined work will get the combined licensed in that order.
<xnox> seb128: just lgpl2.1 by itself -> binary lgpl2.1, lgpl2.1 + 3 -> lgpl3, lgpl2.1 + 3 + gpl3 -> gpl3
<xnox> it's only gpl2-only which is incompatible with gpl3, lgpl2.1-only on the other hand is compatible.
 * seb128 opens http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility and look at it again
<seb128> xnox, thanks ;-)
<seb128> xnox, the tab says to transfert the code to GPLv3 in that case?
<xnox> seb128: https://www.gnu.org/licenses/quick-guide-gplv3.html
<xnox> is better.
<xnox> seb128: sure FSF is pushing everyone to v3 =)
<xnox> seb128: it would be easier if it was not modified.....
<seb128> xnox, right, well I'm reviewing ibus-cangjie in the sponsoring queue
<seb128> their source is LGPL3
<seb128> and they need python-canberra which is LGPL2.1
<seb128> or that one is not available for python3
<seb128> so they did copy it in source and ported it to python3
<xnox> thus clearly the only way they could have modified it, under lgpl2.1. Did they change the license headers?
<seb128> no they didn't
<seb128> xnox, but http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility says you can't ship LGPL2.1 code under LGPL3
<xnox> seb128: hence they are all golden -  all modifications to lgpl2.1 code are provided back under lgpl2.1
<seb128> so the project can't be redistributed this way
<seb128> or I read that wrong...
<xnox> seb128: sure but we are not releasing the project under LGPLv3, we are releasing it under mixed lgpl2.1 & 3 (e.g. linking only). The 2.1 bits are staying 2.1 bits, and just like before one is allowed to link against lgpl2.1 in lgpl3 one continious to do so.
<seb128> xnox, well, both got mixed in one process no? and the COPYING in that source says LGPL3
<xnox> seb128: plus a third-party cannot relicense code to a different. Look at that table the lower part "I want to use a library under LGPLv2.1 only" and it's OK across the board.
<seb128> xnox, ok with quite some cases where it says "you need to transfert the code to GPLv3"
<xnox> it doesn't matter if I use original lgpl2.1 library, or lgpl2.1 library with lgpl2.1 licensed patches library (they are the same).
<xnox> seb128: i'd be using the 'i want to use a library under"
<xnox> seb128: as they kept the library separate.
<xnox> seb128: that one does not have any convey for lgplv2.1
<seb128> ah, right
<xnox> seb128: take their patches & sponsor into our canberra package, unapply patches from their packages and upload \o/
<seb128> I was considering the python import of a copy as a code change
<seb128> ;-)
<seb128> that's an idea
<seb128> or just push the canberra guys to just take that patch and release and updated version
<xnox> seb128: python import is mostly equivalent of shared library linking, it's not for example static library or C++ template....
<seb128> except that's a modified copy in source
<seb128> so it's a bit the equivalent of copying the source of a shared lib, copying it inline, changing it, and linking against it for building your binary
<seb128> that's not really "using a library" at this point, it's "using the code of a library for your private benefit"
<xnox>  \o/ /o\
<seb128> anyway, I will wave hands and sponsor and see what the archive admin of the day think of the situation ;-)
<seb128> xnox, thanks for the discussion
<ScottK> seb128: re your comments in https://bugs.launchpad.net/ubuntu/+bug/1055435/comments/22 - I think it's fair to say that if the licensing is clear and it's in common licenses, a missing license is not a reason to reject a package, but I also think it's still a bug that should be fixed.  When was the discussion you refer to because I don't see it in my backscroll?
<ubot2> Launchpad bug 1055435 in ubuntu "[FFe][needs-packaging] new package classicmenu-indicator" [Wishlist,Fix committed]
<seb128> ScottK, on this channel, around 11am UTC between xnox and me
<seb128> oh, sorry
<seb128> I'm mixing bugs
<ScottK> OK.  Would you please comment again in that one.
<seb128> ScottK, sure
<seb128> ScottK, http://irclogs.ubuntu.com/2013/01/30/%23ubuntu-release.html#t12:29
<seb128> was the discussion
<seb128> some "recent" might not be that recent :p
<ScottK> Right.
<ScottK> "Of course, it might still be a good idea to contact upstream and get them to spell out the licensing more clearly in their tarball - I just don't think it's cause for rejection"
<ScottK> That aligns with my thinking on the matter.
<ScottK>  !rejected != bug free
<ubot2> ScottK: I am only a bot, please don't think I'm intelligent :)
<ScottK> Sigh.
<seb128> ScottK, sorry, what do you want me to add to the bug? I said that it's not a blocker and that they can upload and that it would still be good to have the issue fixed with the next upload
<ScottK> seb128: Your last comment says, in part, "the full license doesn't need to be included in the tarball as long as the intend is clear".
<seb128> well, I added "even if it would be good to have in a next update"
<seb128> but I can change that to a "please get it fixed for the next update"
<ScottK> I think that would be clearer.
<seb128> ScottK, https://bugs.launchpad.net/ubuntu/+bug/1055435/
<ubot2> Launchpad bug 1055435 in ubuntu "[FFe][needs-packaging] new package classicmenu-indicator" [Wishlist,Fix committed]
<seb128> comment #23
<seb128> works for you?
<ScottK> seb128: perfect.  Thanks.
<seb128> yw, thanks for pointing it out ;-)
<ScottK> no problem.
<cjwatson> infinity: Didn't our buildd chroot configuration use to preseed man-db/auto-update to false in the debconf database, to stop man-db bothering to update its database during builds?
<cjwatson> infinity: I certainly put that in there for the benefit of buildds
 * xnox ponders if mk-sbuild does that as well?!
<plars> cjwatson: psivaa just pointed out to me that the precise jobs are failing because report.html is just in pending, not in current
<plars> cjwatson: is it intentional that those are not copied over to current?
<plars> I thought it was just going to be a link actually
<plars> for example: http://cdimage.ubuntu.com/ubuntu-server/precise/daily/
<cjwatson> plars: not entirely intentional, but I'm going to have to regenerate those files - it can't be a simple copy/link because the set of architectures involved isn't necessarily the same
<cjwatson> plars: however, you could avoid the job failure by switching the jobs over to look at pending rather than current
<cjwatson> plars: which AIUI is the intention anyway
<plars> cjwatson: yes, indeed
<jamespage> Daviey, ^^ those are the correct new versions for openstack updates; I notice other versions of keystone, nova and cinder in the queue from +1 month ago - those can be rejected please.
<jamespage> Daviey, there is also a quantum fix that could also do with accepting if possible
<infinity> cjwatson: Probably not.  Happy to twiddle that when I refresh the chroots.
<bdrung> hi, what do you think about bug #1158845?
<ubot2> Launchpad bug 1158845 in Ubuntu "[FFe] Pseudo sync nemo 1.7.2-1 from Debian unstable (in NEW queue)" [Undecided,New] https://launchpad.net/bugs/1158845
<cjwatson> Laney: I'm working on haskell-cryptohash/powerpc - making progress, slightly to my surprise
<infinity> Oh hey, look at that, someone's logged into my machine.
<xnox> oh, is that how colin gets powerpc hw ? =)
 * xnox kept on imagining that there is a garage on greenend in cambridge full of machines of all architectures ever made.
<Daviey> jamespage: I think it will have to wait until Monday now.  Don't really want to do anything taxing right now :)
<cjwatson> fixed sha3; working on skein256
<jamespage> Daviey, thats fine
<jamespage> (thought that might be the case)
<infinity> xnox: Yeah, he's actually using two of my PPC machines right now...
<cjwatson> Laney: https://github.com/vincenthz/hs-cryptohash/pull/13 - I'm tempted to go ahead and upload that to Ubuntu; what do you think?
<cjwatson> obviously aiming to get it into experimental too once it's accepted upstream, but I'd like to get our transition chart cleaner
<olli> ScottK, ping
<ScottK> olli: Yes?
<olli> ScottK, thostr_ and I wanted to discuss FFe https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1154229 with you
<ubot2> Launchpad bug 1154229 in unity-scope-gdrive "[FFE] New Unity Dash" [Undecided,Triaged]
<olli> there are imho 3 issues that we'd need your opinion on
<ScottK> OK.
 * olli looks for his notes ;)
<olli> didrock's ppa has now the scopes changes as well as the in dash payments changes merged (now: for days)
<olli> in dash payments FFe https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1154176
<ubot2> Launchpad bug 1154176 in unity "[FFE] Add payment preview for music" [Undecided,Fix committed]
<olli> the ppa is building against the raring trunk automatically
<olli> and updating itself
<olli> we still show a few regressions in the integration suite compared to 12.10 results
<olli> which the team is working on
<olli> (#1^)
<olli> issue #2: due to these failing integration tests we didn't get the packages to the -validated ppa to get more community testing
<olli> we had a few brave ppl look at it, but not what we'd expect from a proper testing done by balloons
<olli> issue #3: we are feature complete, but the overall bug situation is not satisfying (see https://bugs.launchpad.net/unity/+bugs?field.tag=100scopes)
<olli> traditionally, we'd now argue with you to just get it in
<olli> and fix bugs later
<olli> but we'd like to break with that tradition in favor of the user experience
<olli> ScottK, the big question is what options (if any) do you see
<olli> thostr_, did I miss anything?
<thostr_> olli: no
<ScottK> I've expressed my opinion that we're well past feature freeze and things like this should have been landed already.
<ScottK> What you're telling me reinforces that opinion.
<olli> and there is nothing I can say against that, unfortunately
<ScottK> I'm not sure what you mean by breaking that tradition.
<olli> I don't want to pull the sabdfl card and just push it in the state it is at right now
<olli> for Monday
<olli> which was our targeted landing date
<ScottK> Then I'd suggest waiting until you think it's mature.
<thostr_> ... which means a couple of more days or bugfixing
<olli> I think the preferred solution is to figure out a date that works for you to land it in a mature state
<ScottK> If Mark says it goes in, it goes in, so make sure you're ready for that to happen.
<olli> I am not worried about the Mark side
<olli> just trying to work with you guys to resolve this situation in the best way
<ScottK> I think anything after the end of next week would be insane.
<ScottK> However, Mark routinely approves stuff I think is just crazy.
<ScottK> So I don't know what to tell you.
<olli> well, ok
<olli> we are hitting the Easter Holidays in Europe next week and I believe didrocks is gone (he is on the critical path for us to land it)
<cjwatson> Laney: I've just gone ahead.  I think this is a fairly obvious improvement - we should be able to overwrite it with a Debian package soon enough
<olli> ScottK, we might have hit didrocks' EOD already
<didrocks> not yet, writing an email to sum up today's status :)
<olli> ha
<ScottK> olli: I don't know what to tell you.  We have feature freeze for a reason and now you're running all over the kinds of problems that happen when it gets ignored.
<didrocks> ScottK: the thing is that we have some kind of raring + extension right now
<didrocks> which is the ppa
<didrocks> so, this is giving us a better feeling of what we are actually experiencing
<didrocks> and we rebase everytime we land an unity or any component that we touched in the distro
<ScottK> didrocks: I understand.  The 100 scopes/Unity next thing is already approved by Mark.
<didrocks> ScottK: I would really prefer that we land with a better quality state than what we had in the past
<ScottK> The new payments stuff is not.
<didrocks> meaning "shipping something half working"
<olli> ScottK, my last concern was that dumping it in on Thu and then have everybody gone over the long weekend might not be preferable
<didrocks> and then "upload everydays to fix things"
<didrocks> I would rather prefer delaying a little bit and be more proud of the first shot
<didrocks> does this make sense ^
<didrocks> ScottK: oh right, I've taken great care that we can revert the in dash payments
<didrocks> ScottK: no worry on that one :) just acting as Mark asked, to get it testing
<ScottK> Sure.
<didrocks> it will be reverted whenever we ship the 100scopes if there is no +1
<olli> sorry if I was ambigous on that one
<olli> good catch didrocks
<didrocks> no worry ;)
<didrocks> ScottK: so now I think we want to have your tought
<didrocks> is it better to ship it on a hurry
<didrocks> just to "meat the deadline" (meaning what was written in the FFe)
<ScottK> And I hate to sound like a broken record, but my answer to "when should we land this" is "two weeks ago before feature freeze".
<didrocks> knowing that we will have to rush and get things "somewhat ready" later
<didrocks> or just delaying
<ScottK> I think it'd be better to plan on landing a mature product by feature freeze.
<didrocks> ScottK: we all agree on this, we can't deny it :)
<didrocks> so delaying by a few days and ensuring that the first shot will make us more proud of the delivery
<ScottK> Right.
<olli> scottk that's out preference and if that's ok with you then we'd like to go that way
<ScottK> olli: Which way?
<olli> what didrocks just said: rather delay and have the experience we want
<olli> than to dump something now to meet the deadline
<infinity> olli: The bottom line is that you shouldn't knowingly ship broken code *and* if it's a new feature not already approved, you'll need to argue an FFe or sabdfl it in.  How the timing for all of that works isn't really up to us, we're not writing the code.
<infinity> olli: The deadling, as Scott said, is "two weeks ago", so you've already missed it.  So, if you're going to get something sabdfled in, please make sure it doesn't suck.
<infinity> s/deadling/deadline/
<didrocks> which will translate in favor of "wait for some additional days and get the first shot in a better shape"
<olli> infinity, alright, that's the statement I was hoping to get
<didrocks> (not telling awesome, but better)
<cjwatson> For things that haven't been sabdfled, "slip to next release" should be on the table.
<infinity> Absolutely, yes.
<ScottK> cjwatson: Absolutely.
<olli> no such things here though
<cjwatson> There absolutely is such a thing in Ubuntu.
<olli> here:=on my plate
<cjwatson> Oh, I see what you mean.
<cjwatson> OK.
<olli> alright, well, I wanted to reach out and do some better communication than in the past, thx infinity and scottk for your comments and help
<ScottK> Thanks.
<olli> I guess it's up to us now to deliver
<olli> and work on not having that type of conversation in 6mo
<ScottK> I think it's up to you to convince Mark if you think you've delivered.
<olli> Mark leaves that decision to me
<olli> so, I really wanted to make sure I don't screw up more with the release team
<ScottK> It takes him saying he's approved it for him to have approved it.
<olli> with an emphasis on "more"
<olli> ScottK, which is in place for 1154229, isn't it?
<ScottK> olli: Yes, but not for Bug #1154176
<ubot2> Launchpad bug 1154176 in Unity "[FFE] Add payment preview for music" [Undecided,Fix committed] https://launchpad.net/bugs/1154176
<olli> ScottK, true, that's a different story
<ScottK> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1154176/comments/13 in particular.
<ScottK> So none of the payment stuff has a sabdfl override at the moment.
<jtaylor> hi, I have a question concerning scilab
<jtaylor> we had it hanging in proposed because it fails to build with a new matio also in proposed
<ScottK> Fixing that doesn't need an FFe.
<jtaylor> now a few days ago someone uploaded a snapshot which has new features
<jtaylor> which ftbs
<jtaylor> should we remove the proposed version and instead fix what we have in release?
<jtaylor> or now its to late, skip the ffe and fix what is in proposed?
<ScottK> Fix what's in proposed unless that's somehow a lot harder.
<jtaylor> its probably easier
<jtaylor> k, thx just wanted to check
<jtaylor> thx
<olli> ScottK, ack at 1154176, will see if I can help that team
 * olli waves goodbye
<sconklin> is there anyone here who can kill some in-progress builds in the kernel PPA for me? I just uploaded a package that supercedes it and I want to free the build resources
<cjwatson> possibly.  links?
<sconklin> https://launchpad.net/~canonical-kernel-team/+archive/ppa?field.series_filter=lucid
<cjwatson> (in general #webops on internal irc is a quicker/better place to ask, but now that you've asked here ...)
<sconklin> 2.6.32-46.106
<cjwatson> oh, that's a devirt ppa?
<sconklin> 107 is uploading now
<sconklin> cjohnston: yes
<cjwatson> you have to ask webops then - we don't have a webby/api cancel mechanism for devirt ppas
<cjohnston> no
<cjohnston> ?
<sconklin> cjohnston: thanks
<sconklin> I meant cjohnston
<sconklin> autocomplete fail
<cjohnston> 1 + 2 + 3 + tab :-)
 * ogra_ guesses sconklin simply didnt read xnox' blog :)
<ogra_> (xchat got a cj<tab> fix) .... but you need to set it manually if you used xchat before already
<infinity> Huh.  I learned something new today.  Thanks, NEW queue.
<ogra_> no armhf ? :(
<infinity> (libcangjie1 immediately made me think of Kanji and, lo and behold, Cangjie and Kanji are etymologically related)
<infinity> ogra_: I let amd64 through early intentionally so linux-signed can build while I'm waiting on armhf.
<ogra_> ah
<ogra_> right, takes longer
<slangasek> infinity: is that a pinyin spelling?
<slangasek> apparently yes
<infinity> slangasek: Yeah, pretty much everything I know about Chinese I know from Japanese, so it's fun to see the parallels in anglicisation of matching concepts.
<ogra_> btw, do we now all have to learn chinese ?
<ogra_> to read code contribution comments and the like ?
<infinity> ogra_: You probably should have been doing so for the last decade or so, if you're keen on remaining relavant.
<infinity> relevant, too.
<slangasek> ogra_: æ²¡æ
<ogra_> argh
<infinity> If you threw in the character for "horse" again by accident, I'm not reading that.
<ogra_> ha !
<ogra_> now i know how no looks like
<ogra_> slangasek, thanks !
<slangasek> :)
<infinity> I don't even remember the phrase you munged in the meeting now.
<infinity> Was it just short a stroke?
<infinity> Whatever it was, it turned out rather.  Uhm.  Wrong.
<slangasek> yeah, it was short a stroke :)
<slangasek> å vs. é©¬
<infinity> Which IME are you using?
<infinity> Do we actually have something non-crap now?
<slangasek> ibus-pinyin
<slangasek> seems to work well enough
<slangasek> though kylin want to avoid ibus altogether in favor of fcitx, I don't know why :)
<infinity> I haven't looked at all of this for ~5y or so, since I lost any need to write in Japanese, but it was all pretty unfriendly back then compared to Windows, and Windows was bad enough.
#ubuntu-release 2013-03-23
<darkxst> slangasek, any chance of getting this sru approved? https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1128804
<ubot2> Launchpad bug 1128804 in mutter "Update mutter/gnome-shell to 3.6.3" [Medium,In progress]
<darkxst> will we get "Ubuntu Code Search" one day?
<cjwatson> Laney: FWIW I've reduced the conduit failure to this in ghci:
<cjwatson> Prelude> data Pipe l i o u m r = Done r
<cjwatson> *** Exception: Prelude.undefined
<cjwatson> (no exception on i386)
<cjwatson> don't have much more time to investigate today
<xnox> do we have server 12.04.2 images?
<bdrung> ScottK: more unhappy users about the new nautilus in raring: http://be-jo.net/2013/03/ubuntu-13-04-ein-kurzer-einblick/ (german)
<Laney> cjwatson: oh cool, good stuff about both
<Laney> thanks for spending some time on it
<Laney> FWIW I'm off for the next fortnight and plan to spend any computer time I get on this transition
<Laney> hipmunk is a matter of either using the standard library's new modifyIORef' or not importing it and using their function (definitions are identical)
<ScottK> bdrung: Once it's in the release pocket post-release, it can't be removed.  I think it's better to backport post-release so there's another 6 months to see if this fork is really going to be sustained or not before we're stuck with something that can't be gotten rid of.
<bdrung> okay
#ubuntu-release 2013-03-24
<cjwatson> Laney: I wonder if we should upload http://ftp-master.debian.org/new/haskell-publicsuffixlist_0.0.4-1.html for the sake of the currently-unbuildable haskell-http-conduit
<phillw1> cjwatson: who would be the best person to set up zsync on my mirror, or can we only have rsync?
<cjwatson> phillw1: you don't need to do any special setup for zsync - it operates by fetching a .zsync control file over HTTP
<cjwatson> phillw1: so any cdimage.u.c or releases.u.c mirror that serves HTTP will automatically serve zsync
<cjwatson> (since we generate the .zsync control files on the master)
#ubuntu-release 2014-03-17
<zequence> Hi. Got a package that would need to be uploaded soonish. It's a FFe, and doesn't show in the sponsors queue. It was uploaded to the archives once already, but was rejected due to some lintian warnings, which are gone now Bug: 946591
<ubot2> Launchpad bug 946591 in Ubuntu "[FFe] Add ubuntustudio-live to trusty repositories" [Undecided,Confirmed] https://launchpad.net/bugs/946591
<zequence> ^
<zequence> ..got it to show in the sponsors queue.
<dbarth> hi there
<dbarth> who has the ability to review this FFE: https://bugs.launchpad.net/webbrowser-app/+bug/1288743 ?
<ubot2> Launchpad bug 1288743 in webbrowser-app (Ubuntu) "[FFE] Support for online accounts in webapp-container" [Undecided,New]
<dbarth> it is to authorize the landing of a webbrowser-app change on /touch/, knowing that we have limited the binding to not affect the desktop release
<dbarth> (the feature is not active on the desktop, via a runtime check); and does not build-depend on universe to fit the desktop/main requirements
<dbarth> seb128: ping? can you help? (it's blocking us on the desktop as well)
<dbarth> who has the authority to examine the FFE above ^^
<seb128> dbarth, I'm not in the release team
<seb128> dbarth, https://launchpad.net/~ubuntu-release
<dbarth> seb128: i know, but who should i ask for something in between touch and desktop?
<seb128> dbarth, FFe are release team material, I just gave you the team on launchpad, it has the list of people
<seb128> but you are in the right channel
<seb128> they are just busy
<seb128> you are not the only one having a FFe request, there is quite some queue
<dbarth> i can imagine
<sergiusens> dbarth, my FFes have been open for a week; I think it's just a matter of time
<dbarth> sergiusens: one way or the other,yes, since we're doing time-based releases
<sergiusens> dbarth, I mean a matter of time until they get to it :-)
<dbarth> i know ;)
<Laney> There's quite a few FFes pending
<Laney> do any of the rest of you have time to look at some of them?
<cjwatson> dbarth: approved
<cjwatson> dbarth: hopefully I can get https://code.launchpad.net/~cjwatson/webbrowser-app/multiarch/+merge/211350 rolled in in exchange ;-)
<dbarth> cjwatson: \o/ thank you :)
<dbarth> let me check that one
<Laney> infinity: want to look at https://bugs.launchpad.net/ubuntu/+source/binutils-avr/+bug/1235748 ?
<ubot2> Launchpad bug 1235748 in binutils-avr (Ubuntu) "FFe: Sync binutils-avr 2.23.1-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed]
<infinity>  binutils-avr | 2.23.1-2 | trusty/universe  | source, amd64, arm64, armhf, i386, powerpc, ppc64el
<infinity> Laney: Looks already done?
<Laney> Oh, I didn't check that
<Laney> who didn't wait for the FFe?
<Laney> wait
<Laney> that one is ancient
<infinity> Yeah, that happened in October, not an FFe thing. :P
<Laney> Yeah, we probably ought to clean out the queue at some point. :P
<Laney> Daviey: If you're still interested in server (MAAS/Openstack) FFes there are a few in the queue
<Laney> I saw you replied to some already, so letting you know.
<cjwatson> infinity: libnss-mdns-i386 fauxpkged, though unfortunately it'll need a version bump each time nss-mdns is uploade
<cjwatson> d
<cjwatson> (I haven't done anything to the seeds, I'll let you figure that out)
<infinity> cjwatson: I intend to drop that package in an Ubuntu delta post-trusty anyway.
<cjwatson> cool
 * cjwatson looks at the build queues.  we can haz powerpc vms on some of the new hosts any time?
<infinity> cjwatson: It's only meant for smooth upgrades from lib32nss-mdns to libnss-mdns:i386, so has no use post-LTS.
<infinity> cjwatson: Twiddling VMs is on my TODO but, realistically, don't know if I'll have time this week.
<Daviey> Laney: ok, thanks - will take a look this evening. Travelling right now.
<Laney> Daviey: righto
<stgraber> infinity: I'm assuming fisher01 is the ppc64el livefs buildd? if so, something seems wrong with it, there are tasks stuck for a couple of days on nusakan.
<infinity> stgraber: Oh.  Derp, I forgot that was the livefs builder when I kept it offline for debugging.  I'll bring it back.
<infinity> stgraber: Should be happy now.
<stgraber> infinity: ok, I'll kill the remaining ssh processes on nusakan. I'm assuming you cleaned up any remaining livefs cruft on the buildd itself?
<infinity> stgraber: There probably isn't any to clean up.  Let me poke.
<infinity> I mean, unless it died in the middle of a build, but I doubt it.
<infinity> Yeah, I see no lock filed or anything.
<stgraber> ok, nusakan has been cleaned up, so things should start building again with the next cronned run
<psivaa> infinity: cjwatson: curious about why trusty server iso's are not in cdimage since the 13th if in case anyone pings me.. i see some armhf build failures
<psivaa> apologies if the info is in the backlog.. dint go that far back
<infinity> Sorry about that.  Just bad luck, I guess, that the 1 in 10 machines that blew up and showed off the IPC race also happened to be the livefs builder. :P
<stgraber> psivaa: probably the exact same issue we just fixed since that'd have held up publising of all core and server images.
<cjwatson> right
<cjwatson> so a whole <10 lines back in scrollback :)
<stgraber> psivaa: so they should be appearing nowish
<psivaa> stgraber: cjwatson: ack, thanks :)
<sergiusens> can someone please look at bug 129094 ?
<ubot2> Launchpad bug 129094 in Ubuntu "data CD will not mount and reason given is that I am not root" [Undecided,Invalid] https://launchpad.net/bugs/129094
<sergiusens> meh
<sergiusens> can someone please look at bug 1290944 ?
<ubot2> Launchpad bug 1290944 in phablet-tools (Ubuntu) "[FFe] standing freeze exception in trusty for Ubuntu Touch tools packages" [Undecided,Confirmed] https://launchpad.net/bugs/1290944
<sergiusens> latter not former
<stgraber> sergiusens: approved
<sergiusens> stgraber, thanks
<jdstrand> slangasek: hey, fyi, I was asked to alert you to bug #1293681 and bug #1290535
<ubot2> Launchpad bug 1293681 in oxide-qt (Ubuntu) "[MIR] oxide" [Undecided,New] https://launchpad.net/bugs/1293681
<ubot2> Launchpad bug 1290535 in webbrowser-app (Ubuntu) "[FFE] Webapps support for the new Oxide container" [Undecided,New] https://launchpad.net/bugs/1290535
<jdstrand> slangasek: there is nothing for you to do now. basically, we hope to land oxide in the archive this week
<jdstrand> slangasek: when that is done, webapps will transition to using oxide
<jdstrand> slangasek: I'll handle the MIR bits, so this is just a heads up that the webapps team will need the release team to comment on the FFe, probably next week
<jdstrand> dbarth: fyi ^
<dbarth> jdstrand: ok
<dbarth> thanks
<sergiusens> if a package was building fine for arm64 and then finally failed, would that block it in proposed?
<cjwatson> sergiusens: that depends on whether the version currently in trusty has an arm64 build
<cjwatson> sergiusens: https://wiki.ubuntu.com/ProposedMigration has the rules
<sergiusens> cjwatson, it does https://launchpad.net/ubuntu/+source/ubuntu-download-manager
<cjwatson> No it doesn't :)
<sergiusens> hmm it was depwait for saucy; not sure what the previous results were for trusty; but mandel is saying it used to work
<sergiusens> I trust you :-)
<cjwatson> depwait vs. failure doesn't matter
 * sergiusens checks wiki
<cjwatson> the point is it doesn't have binaries in the arhcive
<cjwatson> *archive
<sergiusens> right; so it was never in (for amr64)
<cjwatson> though that build doesn't look desperately far away from working
<sergiusens> nope
<mandel> sergiusens, cjwatson I don't know much about this, but I do have a ppa where it does build with no problems: https://launchpad.net/~ci-train-ppa-service/+archive/landing-006/+build/5661763
<cjwatson> that's amd64 not arm64
<sergiusens> yeah
<cjwatson> anyway, this should be fixed but it's no kind of blocker
<mandel> ah, sorry
<xnox> sergiusens: i mean, if it ever built, AAs have powers to remove binaries from arches and re-introduce them via copies. Which sometimes is done to unblock things (like last friday for qt5.2) so e.g. $ rmadison -S -s trusty ubuntu-download-manager is authoratative way to look up if binaries are or aren't in the achive and for which arches.
<mandel> cjwatson, sergiusens ok, so I'm stupid, and I don't think that qmake is placing the libs for arm64 in the correct place, I'll take a closer look
<xnox> sergiusens: if ever in doubt =)
<sergiusens> xnox, thanks, will add to my cheats
<infinity> mandel: Looks like that's the same issue on powerpc too.
<mandel> infinity, yes, I'm moving away from qmake due to this kind of things, but will fix both archs
<infinity> mandel: Well, surely the answer is for INSTALL_LIBDIR to be seeded by debian/rules with DEB_HOST_MULTIARCH instead of hardcoding it in common-project-config.pri
<infinity> Especially since this is wrong too: ARCH = $$system(uname -m)
<infinity> (Our i386 buildds are all x86_64, using uname to determine userspace ABI is never right.  Ever)
<mandel> infinity, I'm not a qmake expert so I have clearly make an error there, will fix it after dinner
<infinity> (The only reason that works for you is because we run our i386 builds under "linux32" to fake uname, but one shouldn't rely on that)
<infinity> mandel: Ahh and, indeed, LIBDIR is already preseedable in your .pri
<mandel> infinity, yes, I should just be seeding it in the rules and that should sort it out AFAIK
<slangasek> jdstrand: yes, dbarth mentioned that on here previously; I'll make sure to make time for FFe request processing between now and then
<jdstrand> slangasek: yes, he mentioned that. new info is that oxide should be in the archive soon. awesome, thanks! :)
<knome> stgraber, wait, what, where's your "UIF upload" commit for the slideshow?
<knome> ah, there it is.
<knome> stgraber, we are *missing* content for one slide (plus some minor uploads), about to land it in the next few hours. will you approve that UIFe? ;)
<stgraber> knome: sure, file a bug and I'll look at it. Since it'll likely only affect your own documentation and not anything shared with other teams, that shouldn't be a problem.
<knome> stgraber, was thinking of the same
<knome> stgraber, i only semi-accidentally even noticed the UIFe note, as i was just landing the first, but almost final version of that slide
<knome> talk about timing ;)
<stgraber> I figured that waiting till Monday after UIF would be good enough to catch all last minute changes, apparently not ;)
<stgraber> (Edubuntu was a bit late too, so you're not alone ;))
<knome> yeah, we were supposed to have this ready, but real life comes into the way, the person to write the script was in rome...
<robru> cjwatson, errrr, can you check on process-cpp? citrain somehow thinks it's in proposed, but I don't see it on any of excuses, launchpad, or even rmadison
<robru> cjwatson, oh nm, now I see it in rmadison
#ubuntu-release 2014-03-18
<JackYu> hi release team, who could help to review the FFE at bug #1293299?
<ubot2> Launchpad bug 1293299 in Ubuntu "[FFE]upload ubuntu-kylin-software-center into archive" [Undecided,Confirmed] https://launchpad.net/bugs/1293299
<jamespage> any release team members around? I could do with an opinion on the delay from upstream to bug 1278466
<ubot2> Launchpad bug 1278466 in ceph (Ubuntu Trusty) "[FFe] ceph firefly stable release" [High,New] https://launchpad.net/bugs/1278466
<jamespage> opinion/chat on options
<jamespage> stgraber, Laney, Daviey: any of you around to discuss how I dig us out of bug 1278466
<ubot2> Launchpad bug 1278466 in ceph (Ubuntu Trusty) "[FFe] ceph firefly stable release" [High,New] https://launchpad.net/bugs/1278466
<jamespage> ?
<sergiusens> can I get some eyes on https://bugs.launchpad.net/ubuntu/+bug/1290360 ?
<ubot2> Launchpad bug 1290360 in Ubuntu "[FFe] New Ubuntu Touch specific package: media-hub" [Undecided,New]
<Laney> jamespage: would it be bad to keep the current version?
<Laney> I'm not familiar with ceph, I'm afraid
<jamespage> Laney, well the current version is a stable release, but it won't get support for as long as the firefly release
<jamespage> Laney, hence the intent to ship with firefly; but upstream dates have slipped; they don't want to mark it for long term support until they are happy with it
<Laney> jamespage: Indeed, so the risk is shipping with a buggy version
<Laney> Daviey's suggestion of updating post-release might work if the SRU team thinks that is acceptable
<Daviey> jamespage: hey o/
<jamespage> Daviey, hey
<Daviey> jamespage: Could you respond to the options on the bug?
<jamespage> yes
<jamespage> Daviey, updated - also discussing with sage upstream who suggested the same approach re using the 0.78/0.79 releases as rc's (which in effect they are) for firefly
<Daviey> jameapage, thanks - reaponded
<jamespage> Daviey, I've asked sage to engage directly on that bug report
<Daviey> jamespage, great
<zequence> highvoltage: Hi. Did you do another upload of ubuntustudio-live, by any chance?
<highvoltage> zequence: yep, yesterday
<zequence> highvoltage: Ah, thanks :)
<highvoltage> zequence: you're welcome
<jdstrand> infinity: hey, I'd like you opinion on whether our pending apparmor upload needs a FFe
<jdstrand> infinity: basically, I went through sarnold's debdiff and believe that the new upstream release does not warrant a FFe
<jdstrand> infinity: in essence we are trimming some 80 patches and using an upstream version. the upstream version has refactoring, code, cleanups, some rewrites, etc, but no new features
<jdstrand> infinity: however, it does include a python rewrite of the user space tools
<jdstrand> infinity: which is the bit that I think is gray
<jdstrand> infinity: the current perl tools in 2.8.0 are a rather significant pile of poo
<jdstrand> infinity: the python tools are somewhat better, and work at least as well (except for two issues we will be fixing shortly)
<jdstrand> infinity: we want the python tools for the LTS cause they are supportable. the perl ones are not. ie, we might actually be able to do SRUs for trusty to make them better
<jdstrand> infinity: another thing to note is that the perl tools are highly broken right now
<jdstrand> infinity: so much so that people aren't really using them
<jdstrand> infinity: so my feeling is that the python tools, while a total rewrite, do not consitute a FFe because they offer no new functionality and are tested to work as well or better than the perl tools
<jdstrand> infinity: I should also mention that the tools aren't used on the images (though they are in the supported seed)
<jdstrand> infinity: bonus point> the python tools have something of a testsuite where the perl ones do not
<infinity> jdstrand: I think that does warrant an FFe, but I'm happy to grant a verbal one.  Are the python tools in feature parity with the perl ones?
<jdstrand> infinity: what are your thoughts on doing an FFe? I would argue 'no', but can understand the release team saying 'yes'
<jdstrand> infinity: yes
<infinity> I assume this is 'apparmor-utils'?
<jdstrand> yes
<infinity> Yeah, that's not seeded anywhere outside supported, so happy to not care about the language switch, etc.
<infinity> (If that was in the base system, we might have words...)
<jdstrand> sure
<infinity> jdstrand: If you guys have tested this all and have a high degree of confidence, I'm fine with it.
<jdstrand> I would've just filed an FFe in that case :)
<infinity> jdstrand: Are the any backward compat issues, or will this all work sanely with older kernels?
<jdstrand> infinity: ok, thanks! should I file a bug with that in it or not worry about it?
<jdstrand> infinity: all backward compatible
<infinity> jdstrand: No need for a bug, just point people at me if they ask.
<jdstrand> infinity: thanks for your help
<infinity> jdstrand: And if this is the upload that makes debhelper stop depending on python, even better. :P
<jdstrand> infinity: it is that upload :)
<infinity> jdstrand: \o/
<jdstrand> we are no targeting tomorrow
<jdstrand> s/no/now/
<infinity> jdstrand: Given the (actually, rather large) impact that has on build-deps for most of the archive, I'd probably support backporting that small change (the dep removal and doc/string change) to previous releases too.
<infinity> Though, if it was only in a non-LTS, meh, they're all gone soon anyway.
<infinity> And, yeah, that happened post-precise, so whatever.
<jdstrand> yeah
<infinity> Looks like it happened in saucy.
<infinity> I dunno, a backport of that small bit as an SRU might still be appreciated, so the behaviour is consistent.
<infinity> I'm guessing it's a whopping 3 or 4 lines.
<jdstrand> infinity: sorry it took so long btw-- we expected it to happen a bit ago, but then found some issues, UDS, etc. one of those things where we thought we were going to upload, then like "ah, we'll fix that', oh, and that :)
<jdstrand> it isn't much
 * jdstrand adds to todo
<infinity> jdstrand: I understand, I have a backlog of things for this cycle that all fit that profile.  Some will make it, many won't. :/
<jdstrand> yeah
<jdstrand> it's like that sometimes
<robru> infinity, cjwatson: ping about unity-chromium-extension in -proposed. Seems there's no chromium-browser for arm64, powerpc, and ppc64el. Should I limit the arches then, or are we expecting a powerpc chromium port shortly?
<infinity> robru: Or build-dep on chromium-browser, and let it sort itself.
<robru> infinity, excellent
<infinity> (Not quite ideal, as that's a heavy build-dep, but it ends up expressing what you want: only building on arches that have the package)
<robru> infinity, yes it's quite clever, much better than hard-coding arches.
<robru> thanks
<infinity> Sort of curious how you can have a testsuite that tests a browser extension without having the browser installed anyway. :)
<robru> infinity, oh yeah, that huge test suite that totally exists, yeah, that one is quite thorough. ;-)
<infinity> robru: Well, it *had* a testsuite. Just not clear on what it tests. :)
<infinity> robru: Anyhow, if you upload with the build-dep change, let me know.  I'll have to clear the crufty binaries out for it to migrate.
<robru> infinity, yeah, the tests for that one are very error prone and flaky, also difficult to set up the test environment. very manual, doesn't get run at build time.
<infinity> But I'd rather do that after you change it to not build there.
<robru> infinity, ok, doing an MP for that now. will have to rebuild & republish the silo. will ping you in an hour or so
<infinity> robru: The CI stuff may give you a grumpy face about it regressing on those arches.  Not sure how one forces that, but I assume you know how.
<robru> infinity, CI Train doesn't care about arch regressions, it's just -proposed that does that as far as I know
<infinity> Oh, handy.
<infinity> I guess.
<infinity> I'd like to think it cares enough to not copy things out when builds fail...
<robru> infinity, heh, nope. I publish stuff with certain arches failed all the time.
<infinity> Fun.
<robru> infinity, in fact we've been largely steamrolling over ppc64el, powerpc, and arm64 all along. It's only getting cleaned up now because cjwatson is working on it.
<infinity> robru: Oh, no, but you were steamrolling in the past because they weren't regressions.
<infinity> robru: My assumption was thet ci-train should care about regressions.
<infinity> robru: If it doesn't, that seems like a pretty fundamental flaw for something labelled CI.
<infinity> Anyhow, we'll see how your unity-chrome-thingee upload pans out.
<robru> infinity, hmm, maybe I'm not familiar with that part. When we check for "regressions", it's to do with test failures that didn't fail before. I never saw anything outside of -proposed that cared about arches.
<robru> infinity, let's just say, -proposed is part of CI process ;-)
<infinity> robru: Arguably the most important part, yes.  Though some other people who work hard on the other bits might disagree. :P
<cjwatson> robru: you weren't *able* to steamroller over them in the cases where they actually mattered; however the lack of qtdeclarative on those arches with Qt 5.0 meant you didn't see much of it
<robru> right
<cjwatson> ci-train does sort of care, it's just overrideable
<robru> infinity, this seems to be the expected result in the PPA, is it not? https://launchpad.net/~ci-train-ppa-service/+archive/landing-006/+sourcepub/4029222/+listing-archive-extra if so, please clear out those binaries like you said and I'll publish shortly
<infinity> robru: Publish away.
<robru> infinity, thanks!
#ubuntu-release 2014-03-19
<xnox> Laney: =))) i'll be that another person nagging about FFes, can you take a look at bug #1292458 and check if it at all requires FFe or not.
<ubot2> Launchpad bug 1292458 in plymouth (Ubuntu) "[FFe] a bunch of updates to plymouth" [Undecided,New] https://launchpad.net/bugs/1292458
<Laney> xnox: swap for you looking at that cmake patch
<xnox> Laney: there are a few changes, some bigger than others, but it is mostly code cleanup and long standing (upstart) bug fixing.
<xnox> Laney: the one building on the buildds? https://launchpad.net/ubuntu/+source/cmake/2.8.12.2-0ubuntu3 =)))
<Laney> damn
<Laney> swap for you reviewing libtimezonemap MPs!
<xnox> shoot, yeah, I have installer work to do before going away for a week.
 * xnox is not looking forward to trying to force ubiquity to use "Beijing and Montreal" instead of "Shanghai and Toronto"
 * Laney hands xnox dch --maintmaint
<xnox> Laney: *sigh* so in debian they tell me _not_ to use --maintmaint, and in ubuntu i should....
<xnox> Laney: the whole trailer line is pointless, we should have no name there, and only multi maintainer changelog lines.
<Laney> haha
<Laney> It'd have meant that I got emailed when you uploaded it :P
<Laney> anyway, I think those fixes are arguably bug fix
<xnox> Laney: but i had to maintain the information miss-balance to trick you into reviewing my FFe ;-)
<Laney> If that set of reviewers all approve it then do it
<Laney> or some decent subset of them anyway, what evs
<xnox> Laney: *evil* =) well jodh reviewed unofficially but pointed at cjwatson. slangasek is very busy at the moment. Right.
<xnox> ..
<xnox> infinity: ^ is an empty package =) just depends on sources of others and compiles toolchain for x86-bionic/android needed to start building x86 emulator images. (covered by touch FFe)
<xnox> with correct target component ^
<knome> stgraber, as promised: bug 1294619
<ubot2> Launchpad bug 1294619 in ubiquity-slideshow-ubuntu (Ubuntu) "[UIFe] Update the Ubiquity slideshow (Xubuntu)" [Undecided,New] https://launchpad.net/bugs/1294619
<knome> stgraber, subscribing the release team whatsoever. :)
<ginggs> Hi release team, anyone able to look at a FFe please? LP: #1289463
<ubot2> Launchpad bug 1289463 in starpu-contrib (Ubuntu) "[FFe] Merge nvidia-cuda-toolkit 5.5 from Debian, transition to libcuda 5.5" [Undecided,New] https://launchpad.net/bugs/1289463
<stgraber> knome: approved. Let me know when it's all done, I'll make sure your and zequence changes are all in there and will upload a new version.
<ScottK> I'll self reject ^^^
<knome> stgraber, we're done with xubuntu for good :)
<knome> stgraber, all of it is in the branch
<knome> want me to merge?
<stgraber> knome: yep, go ahead
<ScottK> Riddell: ^^^
<Riddell> awooga
<Riddell> thanks ScottK
<caribou> ScottK: what's wrong with the clamav ?
<ScottK> Uploaded for the wrong release.
<knome> stgraber, done
<caribou> ScottK: ah, ok
<mlankhorst> oops
<mlankhorst> did I upload that git snapshot to the archive? can it be removed? :P
<Riddell> mlankhorst: snapshot of what?
<mlankhorst> nm :
<Riddell> mlankhorst: "network manager" or "never mind"?
<mlankhorst> never mind :)
<mlankhorst> uploaded mesa to ubuntu instead of a testing ppa
<sergiusens> cjwatson, hey, can you take a look at https://bugs.launchpad.net/ubuntu/+bug/1290360 ?
<ubot2> Launchpad bug 1290360 in Ubuntu "[FFe] New Ubuntu Touch specific package: media-hub" [Undecided,New]
<seb128> stgraber, infinity, slangasek: can we get somebody reviewing https://launchpad.net/bugs/1293677 (sorry to ping but it feels like Laney has been picking up on most review and it feels wrong to keep piling on him because he has been responsive)
<ubot2> Launchpad bug 1293677 in indicator-sound (Ubuntu) "FFE: Export data to accounts service" [Undecided,New]
<infinity> How is this a desirable feature?
<infinity> Having media player access from a greeter is an information leak.
<infinity> It also means the greeter is reading the user's files.
<infinity> I don't like the security implications in that.
<infinity> jdstrand: Can you have someone in your team look at #1293677 and pronounce on whether or not it's crack?
<infinity> jdstrand: Seems pretty sketchy to me to have the greeter peeking in on users.
<infinity> (I realise this is pretty standard for phone lock screens, but phones are also traditionally single-user... And even then, it needs to be configurable to NOT do that)
<jdstrand> I think mdeslaur might've been involved in those conversations. mdeslaur? ^
<mdeslaur> I wasn't involved in those conversations, no
<jdstrand> hmm, I wonder what I was thinking of
 * jdstrand wasn't either
<mdeslaur> Is there a design for this documented somewhere?
<seb128> https://lists.launchpad.net/ubuntu-phone/msg06773.html
<jdstrand> I don't know-- my first hearing of this was 30 seconds before you
<seb128> do we go back to that discussion?
<seb128> that's for the phone and to have e.g the current playing song on the user lock screen
<jdstrand> I remember volume controls
<mdeslaur> seb128: is there a design document somewhere that we can review?
<seb128> well, unity8 wants to share stuff like what is playing
<seb128> notifications (I think)
<seb128> e.g what you would expect to be able to do on your phone from the lock screen
<mdeslaur> right, but lock screen != greeter
<seb128> on the phone not
<jdstrand> conceptually, I don't think this is a privacy issue cause if the music is playing, you can hear it
 * jdstrand is talking about displaying the info generally
<mdeslaur> right, but the bug mentions "controlling the media player"
<seb128> mdeslaur, we had that discussion on the desktop as well
<stgraber> jdstrand: it really depends on what's the scope of this, if you can skip songs from the greeter, then you can access information which you wouldn't see otherwise
<seb128> if a song is playing, should you be able to pause it from the lock screen?
<jdstrand> true
<seb128> oh, a ted_
<ted_> Woot!
<seb128> ted_, hey
<ted_> This IRC protocol is too complex
<jdstrand> but if you let it keep going, you'll eventually get to it :) that said, I could see how people would prefer that to be togglable
<seb128> so, people want a link to a design spec for the greeter, to see what info are going to end up there
<ted_> It's actually in the individual indicator specs.
<mdeslaur> the bug is kind of unclear on what exactly is involved from a technical point of vue...
<mdeslaur> ted_: can you add some links to the bug, perhaps, so we know what we're agreeing on?
<ted_> Sure. I mean are the MR's useful?
<ted_> Or is that TMI?
<ted_> For this one it's: Current Trackname, artist and album. Playername and icon. And volume/mute.
<mdeslaur> sure, you can add those...but is there a document that explains the transition to using the greeter as a lock screen? it seems to me to be a pretty odd thing to do, with insurmountable problems
<stgraber> jdstrand: ok, say moving back to the previously played song, that's not going to happen on its own ;)
<seb128> mdeslaur, you have been commenting/arguing on that discussion on the list :p
<jdstrand> stgraber: right, which is why I said I can understand why people might want it togglable
<ted_> mdeslaur, That mterry's domain, let me see if there's something overarching.
<mdeslaur> seb128: yes, I have been saying that the lock screen needs to be in the user session
<seb128> right
<mdeslaur> seb128: but I didn't follow the rest of the discussion
<seb128> seems there are pro&con for each side, but the leading opinion is that greeter=lock is better
<seb128> mterry and mpt tried to argue in that sense on the list
<seb128> well, I'm unsure that adding the framework to indicator-sound to put datas in accountsservice should hold on the outcome of the greeter discussion
<seb128> we already put stuff in a-s (e.g the background, or ringtone on the phone)
<seb128> those changes only refactor the code to allow doing that (and to be testable with another backend), they don't include the actual user of the framework to publish specific info
<mdeslaur> right, I don't mind commenting on a specific thing, such as indicator-sound putting stuff in accountsservice...it's further down the line that it's going to be complicated and there may be showstoppers
<mdeslaur> like, how are you going to make the greeter be able to _control_ the media player?
<seb128> right, I'm unsure the ubuntu-phone discussion came to a conclusion
<seb128> yeah, I agree
<seb128> the recent discussions made me thing that having the lock being in-session is maybe the best way
<seb128> that has issues as well (mostly code duplication)
<ted_> mdeslaur, So I think that if you've got issues you should try it, mterry is getting ready to land that. Instructions here: https://code.launchpad.net/~mterry/unity8/split/+merge/210664
<ted_> mdeslaur, For signaling back we're using unity-greeter-session-broadcast. http://bazaar.launchpad.net/~indicator-applet-developers/unity-greeter-session-broadcast/trunk.14.04/view/head:/README
<mdeslaur> ted_: ok, so the media player (or indicator-sound) is listening to broadcasts from the greeter on the system bus?
<ted_> mdeslaur, Correct
<ted_> mdeslaur, indicator-sound to be specific
<ted_> mdeslaur, It then translates that to MPRIS
<mdeslaur> ok, let me add that link to the bug, one sec
<mdeslaur> ted_: do you have the indicator-sound/accountsservice MR somewhere?
<seb128> mdeslaur, https://code.launchpad.net/indicator-sound/+activereviews
<ted_> mdeslaur, And the greeter broadcast: https://code.launchpad.net/~ted/unity-greeter-session-broadcast/sound-control/+merge/208894
<mdeslaur> ok, adding details to bug, one sec
 * infinity has only been skimming backscroll...
<infinity> mdeslaur: lockscreen in the user session is a huge broken no-no for desktop convergence, isn't it?  Unless the switch user bit still works sanely.
<mdeslaur> infinity: sure it can work, it just needs to bump you back to the real greeter or something
<mdeslaur> but there's two things here: 1- design, and 2- security...and a solution to both needs to be thought out
<mdeslaur> anyway, I'm commenting on the bug now
<infinity> ted_: How does any of this behave in a multi-user environment?  What if my roommate and I both lock the screen with an active playlist?  Does bouncing between our names on the greeter give us control to fight over each others' media players?
<infinity> mdeslaur: I'm less concerned about design from the FFe perspective (though I may have lots of opinions), but mostly concerned about security.
<mdeslaur> infinity: ok, go read my comment
<infinity> Phones that display every damned thing on the lock screen without the option to remove all the data are fundamentally broken.  We shouldn't follow down that path.
<ted_> infinity, Yes, but the reality is that today, on the desktop you both can't have the audio output. So it basically doesn't work unless logind changed the audio permissions based on the greeter.
<mdeslaur> it gets complicated once you want home directory encryption
<ted_> infinity, The way we end up getting around that on the phone is that the phablet user is in the audio group.
<mdeslaur> ugh
<ted_> The long term is that we'll have a subset of info on the lock screen. And options to reduce that subset.
<ted_> This is kinda the first use case (mostly due to staffing) but it's a long term design pattern.
<infinity> I'm cool with super-featurful and super-informative lockscreens, so long as I can turn every last bit of it off if I have a fine collection of tinfoil hats.
<mdeslaur> ted_, seb128: can you read my comment in the bug and see if I've adequately understood it?
 * ted_ refreshes
<mdeslaur> infinity: yes, I completely agree, there needs to be a privacy switch for that stuff, which I've required in the bug
<infinity> mdeslaur: And the assumption that "exposing song titles doesn't expose anything" isn't true.
<mdeslaur> (hidden or exposed in the gui, whatever design prefers)
<mdeslaur> infinity: well, if it's playing, it's minimal
<mdeslaur> infinity: if you name your songs after your ex-girlfriends, you may want to flip the privacy switch
<infinity> mdeslaur: You could have cool-song-from-my-girlfriend-anita.mp3 without ID3 tags playing, and the audio would be "Kickstart my Heart", but the info displayed is that you have a girlfriend named Anita.
<mdeslaur> infinity: yes, I agree
<ted_> infinity, Hopefully Anita is the only one reaching in your pocket to get your phone to find out ;-)
<infinity> (Also, your girlfriend Anita has horrible musical taste dude, seriously.  Motly Crue?)
<mdeslaur> just like you can have a wallpaper with personal information in it currently and it gets displayed in the greeter
<infinity> ted_: I do hope that's entirely a joke.  I've met too many people who assume "phones don't need security because they're always on your person".
<ted_> mdeslaur, Looks fine. I'm sure we do #1. I'll make sure to get #2 in.
<infinity> s/assume/assert/
<ted_> infinity, Yes, but generally they're more closely held devices than for instance a desktop in an office or server in the cloud.
<mdeslaur> ted_: that's just my 2c, you still need to convince infinity not to name his mp3 based on his mood
<infinity> mdeslaur: Well, #2 addresses my poor file naming schemes.
<ted_> infinity, That doesn't mean "no security" but it means the defaults can be different.
<infinity> So, assuming they do #2, I'm cool with it.
<infinity> ted_: Absolutely agreed that the *defaults* on phones can, and arguably should, be different.
<infinity> ted_: Just that they also need the facility to be locked down as hard as that corporate desktop.
<mdeslaur> just having the song titles leak outside of the encrypted home directory may be an issue for some people, so the privacy toggle switch is important there
<infinity> (And for Ubuntu, this is even more important, as we aim to make our phone our desktop and our desktop our phone)
<ted_> I do agree.
<infinity> Okay, bug commented on.
<ted_> Thanks folks. Will make sure they're addressed.
<mdeslaur> thanks ted_, infinity
<ted_> Also, there's an open question of url-dispatcher being in the Touch FFE. It was proposed by slangasek to no objection, but didn't get in the list.
<ted_> Can I just add it? Or do I need to do something there?
<ted_> I think it's just an administrative oversight, but didn't feel like I could just edit the list :-)
<infinity> ted_: Well, it's in a ton of desktop seeds, and an rdep of a bunch of indicators, but a restricted FFe demanding it doesn't break ABI would be fine by me.
<infinity> ted_: If you need to break ABI, I'd probably want a separate FFe filed with impact analysis.
<ted_> So, I agree, but I don't know how to express that, just "url-dispatcher (no ABI changes)" ?
<infinity> ted_: Works for me.
<ted_> infinity, Great, thanks!
<slangasek> ted_: proposed *by* me?
<ted_> slangasek, https://bugs.launchpad.net/ubuntu/+bug/1208989/comments/7
<ubot2> Launchpad bug 1208989 in Ubuntu "[FFe] standing freeze exception for Ubuntu Touch-specific packages" [Undecided,Confirmed]
<slangasek> ted_: when I made the comment in the bug log, it was in the context of "touch-specific"; this is now in the desktop seed
<ted_> slangasek, It is touch specific though, we don't *use* it on the desktop, it gets pulled in by converged indicators that use it on touch.
<ted_> I'd have to check, but I think only the lib gets pulled in, not the service.
<slangasek> yeah, just confirmed that
<slangasek> so if we're sure that lib isn't used except on touch, then yeah, that all sounds reasonable
<ted_> I'm reasonably certain that it isn't used, and if it is, it's a bug we should fix.
<ted_> Hmm, I could use the Upstart dbus bridge to file a recoverable errorâ¦ ;-)
<sergiusens> ted_, fwiw I was required to create separate items for things that were missed out from the list
<infinity> slangasek: Well, the lib is *linked* on the desktop, hence why I demanded they avoid breaking ABI. :P
<cjwatson> sergiusens: is this expected to be only on the phone for 14.04, or desktop too?
<sergiusens> cjwatson, only phone/tablet(touch), not desktop
<sergiusens> desktop is 14.10
 * sergiusens rephrases, desktop is a 14.10 target for media-hub
<cjwatson> sergiusens: ok, so this isn't really much to do with the ffe, but for my curiosity, in which direction does this make the qtmultimedia-opensource-src-touch thing better? :)
<sergiusens> cjwatson, we won't need it; so we can rid of that package for starters
<cjwatson> sergiusens: oh, and does this imply an ABI change for apps?
<sergiusens> jhodapp (not here) can provide the nitty details
<cjwatson> ok, I never actually knew what qtmultimedia-opensource-src-touch was for
<cjwatson> don't feel the need to drag them in - as I say it was just a curiosity thing
<sergiusens> cjwatson, they can work together
<sergiusens> what media hub does is provide a dbus interface to say 'play this'
<cjwatson> if it's for touch only for 14.04, I consider it essentially covered by bug 1282590 anyway, even though it's not explicitly on that list
<ubot2> Launchpad bug 1282590 in Ubuntu "[FFe] standing freeze exception in trusty for Ubuntu Touch-specific packages" [Undecided,Confirmed] https://launchpad.net/bugs/1282590
<sergiusens> ah, I was asked to create individual bug reports for the stuff that missed the list
<cjwatson> ok - well, I don't see anything to be concerned about here at least
<cjwatson> and there still seems to be adequate time to make it work if you're basically ready to land it
<sergiusens> it's ready to land
<cjwatson> confirmed the bug
<sergiusens> thanks
<rsalveti> cjwatson: qtmultimedia-opensource-src-touch is just a forked version that uses gst1.0 instead of gst0.10
<ScottK> rsalveti: Do you know when 1.0 support lands upstream?
<cjwatson> rsalveti: so how does media-hub obsolete that?  do we effectively go back to gst0.10; or is it using gst1.0 via some path other than qtmultimedia?
<rsalveti> ScottK: would need to check, last time I did there was still a lot of work to be done (just video playback was done, but camera had to be ported still)
<ScottK> I see.  Thanks.
<rsalveti> cjwatson: not using gst at all, we just need to change our video layer (qtvideo-node and others) to request video playback using media-hub, via dbus
<rsalveti> media-hub will still use gst1.0, but just at the server side
<cjwatson> yeah, that's what I meant
<cjwatson> so it's doing so not via qtmultimedia
<rsalveti> yeah
<cjwatson> and qtmultimedia isn't in the set we currently expose to apps?
<cjwatson> or will this be a 14.04-dev2?
<rsalveti> I think we might be exporting that api yeah, need to check first with the sdk team to see how we will do the transition
<cjwatson> rsalveti: ok, if we are then please let's coordinate that first and make sure Jamie and I are around when you're trying to land it
<rsalveti> cjwatson: sure
<sergiusens> it shouldn't be seeded anytime soon
<JackYu> hi release team, would you please review the FFE request at bug #1293299?
<ubot2> Launchpad bug 1293299 in Ubuntu "[FFE]upload ubuntu-kylin-software-center into archive" [Undecided,Confirmed] https://launchpad.net/bugs/1293299
<darkxst> do we need a UIFe for Ubuntu GNOME community wallpapers package?
#ubuntu-release 2014-03-20
<cjwatson> shadeslayer_: converting libbaloo* to multiarch would seem sane
<cjwatson> not much reason for new libraries not to be
<cjwatson> shadeslayer_: oh and s/funcationality/functionality/g in package descriptions
<jamespage> morning - could I get an ack from one of the release team to sync docker 0.9.0 over from Debian? I've built and tested it out locally and it looks good;
<Riddell> jamespage: if it has new features file a FFe bug request
<seb128> Riddell, infinity, slangasek, stgraber: could you review https://bugs.launchpad.net/ubuntu/+source/pango1.0/+bug/1288177 ? it has been waiting for a while (Laney can't review it since he filed it)
<ubot2> Launchpad bug 1288177 in pango1.0 (Ubuntu) "[FFe] Merge with Debian to add autopkgtest" [Undecided,New]
<jamespage> Riddell, done
<Riddell> seb128: approved
<Riddell> jamespage: bug no?
<jamespage> Riddell, sorry - bug 1295093
<ubot2> Launchpad bug 1295093 in docker.io (Ubuntu) "[FFe] Sync docker.io 0.9.0 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/1295093
<Laney> Riddell: ta
<cjwatson> Riddell: It looks like calligra and korundum need to be rebuilt against libokularcore3abi1
<cjwatson> looking at blockages in -proposed
<Riddell> cjwatson: thanks, we'll get on it
<cjwatson> Riddell: I'm looking at kdeplasma-addons - I have a fix that makes eigen2/ppc64el compile, but so far it's failed a number of tests (of the "obscure linear algebra" kind), so I'm not optimistic
<cjwatson> Riddell: I guess this goes back to why infinity was asking you about it, so I can try building kdeplasma-addons with eigen3 and see if that helps?
<Riddell> cjwatson: debian has an eigen3 patch for it, could you try building it with that patch on ppc64?
<Riddell> cjwatson: http://anonscm.debian.org/gitweb/?p=pkg-kde/kde-sc/kdeplasma-addons.git;a=blob;f=debian/patches/eigen3.patch;h=758b721821e30b5cf78d240e460fa0fe5bcae261;hb=HEAD
<seb128> Riddell, thanks
<cjwatson> Riddell: having odd unrelated-looking difficulties: http://paste.ubuntu.com/7125262/
<Riddell> cjwatson: um yes that is odd, all you did was add that patch?
<cjwatson> and libeigen2-dev [!ppc64el] -> libeigen3-dev
<cjwatson> could be porter-box-specific weirdness, something to do with a fat chroot
<cjwatson> I'd suggest sbuilding that on an architecture you have and uploading if it works, I think
<Riddell> yep, or we might just add a .install.ppc64el file which doesn't install the troublesome files, thanks cjwatson
<cjwatson> Riddell: right, that will work too although it seems like a suboptimal fallback
<cjwatson> FWIW eigen2 came up in the "should be removed since it's been removed from Debian, but can't due to Ubuntu-specific blockers" list
<Riddell> cjwatson: yeah, debian has a load of patches to port to eigen 3 but I'm reluctant to just take them because there's only been a couple submitted upstream and they both have issues
<Riddell> so we're sending them all upstream for review
<cjwatson> right
<cjwatson> sorry not to be able to help more, unfortunately I don't have a proper sbuild setup on ppc64el right now, just the porter box
<bregma> would I be able to expedite a review of #1293043 -- it contains Mir support we'd like to enable for Trusty
<infinity> bregma: Looks fine, syncing.
#ubuntu-release 2014-03-21
<Riddell> can I force mplayerthumbs through on arm64? mplayer not compiling saying "It seems nobody has ported MPlayer to your OS or CPU type yet."
<mlankhorst> port it ;-)
<Riddell> wibble
<cjwatson> Riddell: please can we stop building mplayerthumbs on arm64 if it's uninstallable, then
<cjwatson> and actually not sure that port would be terribly hard ... I think it might just be configure nonsense?
<cjwatson> let me see, this has enough rdeps that it would be worthwhile.  last I looked it was blocked by dependencies but apparently not any more.
<Riddell> cjwatson: mm yes we could just not build it you're right
<cjwatson> Riddell: I think it might not be hard to do a minimal port at this point, so please hold off a bit?
<cjwatson> Riddell: I'll let you know if I give up :)
<Riddell> cjwatson: gotcha
<cjwatson> Riddell: uploaded mplayer
<Riddell> oh nice, thanks cjwatson
<jamespage> please could I get a release team ack on #1 of bug 1287147
<ubot2> Launchpad bug 1287147 in juju-core (Ubuntu Trusty) "[FFe] juju-core 1.18/2.0" [High,New] https://launchpad.net/bugs/1287147
<jamespage> its not a stable release but it does move the version we have in 14.04 forwards and fixes some key bugs.
<pitti> hello
<pitti> any chance someone could ack the postgresql SRUs for all stables? (bug 1294006)
<ubot2> Launchpad bug 1294006 in postgresql-9.1 (Ubuntu Saucy) "New upstream microreleases 9.3.4, 9.1.13, 8.4.21" [Undecided,In progress] https://launchpad.net/bugs/1294006
<pitti> it's just a formality, it's got a MRE and has been done countless times already
<pitti> I'm happy to process them myself if the SRU team is okay with that
 * cjwatson finally disentangles the ruby-multi-xml build failure
<jamespage> Daviey, around? could you take a look at #1 on bug 1287147
<ubot2> Launchpad bug 1287147 in juju-core (Ubuntu Trusty) "[FFe] juju-core 1.18/2.0" [High,New] https://launchpad.net/bugs/1287147
<Daviey> jamespage: ok
<jamespage> Daviey, thanks :-)
<jdstrand> hey, so yesterday apparmor migrated even though click-apparmor and apparmor-easyprof-ubuntu autopkgtests failed (apparmor didn't declare a new (but common) python3-pkg-resources Depends which cause imports to fail in the autopkgtests)
<jdstrand> I fixed the issue, but wondered why apparmor migrated
<xnox> jdstrand: inspecting the logs http://paste.ubuntu.com/7130902/
<xnox> jdstrand: click-apparmor, lxc, apparmor-easyprof-ubuntu autopackage tests did run and finish successfully.
<xnox> jdstrand: from britney's point of view.
<xnox> jdstrand: from logs at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses/2014-03-20/
<jdstrand> xnox: that is probably for ubuntu2, which was the fix I uploaded
<jdstrand> xnox: ubuntu1 is what had the issue
<jdstrand> https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-apparmor-easyprof-ubuntu/
<jdstrand> #11 in the build history
<xnox> jdstrand: the logs i pasted to you are 2.8.0-0ubuntu38 -> 2.8.95~2430-0ubuntu1 from britney
<jdstrand> hmm
<jdstrand> that is weird cause jenkins gave me failure emails, is in red, says fail all over
<xnox> from yesterday 22:45:10 UTC -> 23:28:17 UTC
<jdstrand> Test Result (4 failures / +4)
<xnox> jdstrand: hm, chase up with jibel probably -> Do you have any other logs for above post-mortem?
<jdstrand> all the jenkins ones seem to be there
<jdstrand> jibel: hi! https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-apparmor-easyprof-ubuntu/ #11 corresponded with the 2.8.95~2430-0ubuntu1 aparmor upload yesterday. the autopkgtest failures didn't block migration (also see backscroll)
<jdstrand> jibel: I was curious why
<jdstrand> jibel: also note, click-apparmor autopkgtest failed in the same way
<xnox> jdstrand: jenkins failed ~ 22:52 UTC it seems, which well in time for 23:05 & 23:28 britney runs to say they FAILED.
<jdstrand> jibel: here is the click apparmor one: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-click-apparmor/ (#22 corresponds to the 2.8.95~2430-0ubuntu1 apparmor upload)
<jdstrand> jibel: not, from my end, this isn't critical-- I've resolved the issue, but want to know if I need to be doing something else or alert you to the issue
<jdstrand> xnox: thanks for looking at the logs
<jibel> jdstrand, xnox looking
<jamespage> Daviey, responded on that bug to your questions
<bdmurray> slangasek: fyi arges and I are working on the SRU queues since he missed yesterday
<slangasek> bdmurray: ah, ok
<bdmurray> in case you start in...
<stgraber> oops, forgot queuebot
<infinity> queuebot: Hi, we've missed you.
<bdmurray> slangasek: there is something that looks like a MRE for juju-core in the saucy queue.  Has the tech board talked about this at all?
<slangasek> bdmurray: no;  https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions has been kept up-to-date
<bdmurray> slangasek: okay
<slangasek> and the principle of MREs is that we don't need to do per-change SRU validation because upstream already QAs for us... I'm not sure I see why, for a project Canonical is upstream for, we wouldn't just do the QAing directly in the SRU process
<infinity> What does an MRE for juju-core even mean, when most of it isn't even in the archive? :/
#ubuntu-release 2014-03-22
<cyphermox> anyone around could allow dialer-app and messaging-app to transition to release despite their being uninstallable?
<cyphermox> ahah
<cyphermox> I mean uninstallable on just powerpc64el and arm64 :D
<xnox> cyphermox: that would be a regression as both messaging-app and dialer-app are currently present on those two arches in the release pocket.
<xnox> cyphermox: however the easiest solution is to fix and build qtdeclarative5-ubuntu-telephony0.1 on those two arches, which should be easy these days.
<cyphermox> I know they are already preset
<cyphermox> but they would also already not be installable on these two arches
<cyphermox> I would normally ask cjwatson who's aware of the situation
<cyphermox> I find it quite sad too, but this goes relatively deep
<cyphermox> qtdeclaractive... needs libusermetrics, which down the line needs valgrind, IIRC
<cyphermox> developers are supposed to be aware already that they need to fix this situation
<xnox> cyphermox: which is trivial to fix, making valgrind conditional.
<xnox> cyphermox: i'm half-way done, and uploading libusermetrics which should unblock all of above.
<xnox> cyphermox: we don't increase uninstallable count because of silly packages forcing to use valgrind unconditionally =)
<cyphermox> no, i understand your position, we were just already dealing with this in the above way
<cyphermox> https://launchpad.net/ubuntu/+source/libusermetrics/1.1.1+14.04.20140305-0ubuntu1
<cyphermox> libusermetrics should already ahve been ignoring valgrind had the change been done right *sigh*
<xnox> cyphermox: that's ok. I'll fix it and then respin the jobs.
<cyphermox> well, thanks then
<xnox> test building
<xnox> cyphermox: all tests failed locally, yet passing on buildds. https://launchpad.net/ubuntu/+source/libusermetrics/1.1.1+14.04.20140305-0ubuntu2 ppc64el is here, arm64 is rolling .debs ;-)
<cyphermox> xnox: awesome, thanks a lot
<cyphermox> guess I'll owe you a $drink
<cjwatson> xnox,cyphermox: I'd filed https://code.launchpad.net/~cjwatson/libusermetrics/valgrind-optional/+merge/211563 for this days ago, but it never got landed
<cjwatson> I've cleaned up image build failures
 * infinity bumps another off the ppc/uninst list.
<cjwatson> infinity: Oh, nice find.  I'm glad I didn't have to debug that directly.
<infinity> cjwatson: I filed the Debian bug, everything after that was passive updates from other people. :P
<infinity> cjwatson: Still fails miserably on 64-bit BE arches, but we don't ship any, so meh.
 * cjwatson sheds a tear for ppc64.
<cjwatson> Only one, mind.
<infinity> s390x was where I tested.
<infinity> But yeah.
<infinity> Until someone throws gobs of money and a sub-zero datacenter at us, I suspect we won't care much about s/390
<cjwatson> Does Red Hat have some hosting in Antarctica then?
<infinity> cjwatson: I suspect they don't host the kit at all, much like Debian doesn't.
<infinity> cjwatson: I could be wrong, of course, but I'm betting they just get time on something hosted by IBM.
<cjwatson> Mm, you may be right ...
<infinity> cjwatson: It just seems unlikely that RH would set up a DC with the power and hookups required for a water-cooled rack, but who knows.  People do a lot of things in the name of fun. :)
<infinity> (I'd totally hook it up to the washing machine hookups in my apartment!)
<cjwatson> Because what you want is an S/390 covered in weird smelly goop
<cjwatson> (I just repaired my washing machine ...)
<infinity> If you have weird smelly goop coming out of the taps hooked up to your washing machine, I think you may have found your problem.
<infinity> My taps just provide water. :P
<cjwatson> I was assuming that the washing machine hookups might also have washing machines nearby, and they seem to attract weird smelly goop in random crevices over time.
<infinity>  selinux-policy-dev : Depends: policycoreutils (>= 2.2.1) but it is not installable
<infinity> srsly?
<infinity> (arm64 and ppc64el)
<infinity> How did I not notice that before today?
<infinity> Bah, and all because of a symbols file update needed in setools.  Simple enough.
<xnox> cjwatson: *sigh* sorry.....
<xnox> cjwatson: i can't wait to do arm64be \o/ that should make up a little for not having ppc64 ;-)
 * doko slaps xnox
 * xnox "hit me baby one more time" =)
<ScottK> doko: It doesn't help if they like it.
<doko> liking is not enough
#ubuntu-release 2015-03-16
<elfy> good day - really not sure if this is even the right channel to bring these things, but xubuntu daily today, lubuntu and flexiondotorg_ says mate all failing to get far in to a boot, complaining of pwconv not being able to set the permission of /etc/passwd- to 0600 http://i.imgur.com/KaKMeIa.png
<infinity> elfy: #ubuntu-devel is probably the better place.
<infinity> elfy: Also, looks like a fun bug.  Has anyone investigated at all yet?
<elfy> infinity: I think that flexiondotorg_ has been talking to seb128
<flexiondotorg_> seb128 has gone.
<elfy> infinity: ack that - never really sure where is the best place to shout when dev release is a bit fubar'd
<infinity> elfy: Well, when we're working on milestones (or the release), bringing up critical bugs here isn't a bad plan but, in general, #ubuntu-devel is where you'll get a wider audience of people who both care and can help fix.
<elfy> infinity: ok - thanks :)
<elfy> flexiondotorg_: so is someone else in there looking?
<flexiondotorg_> elfy, infinity I listening. I'm the only looking into why its borked.
#ubuntu-release 2015-03-17
<tmpRAOF> Hey, doko - why is the gccgo 4.9.2 sync in the Trusty unapproved queue? The only âbugâ it seems to fix is enabling cgo on aarch64, and adding a feature seems a bit incongruous with a SRU :)
<doko> tmpRAOF, it's a fix to enable that ...
#ubuntu-release 2015-03-18
<tmpRAOF> doko: How can I usefully review this request? The diff between the two packages is huge (there's 42K changed lines in one of the debian patches alone), gccgo doesn't have a MRE, and enabling new features is generally against the purpose of SRUs.
<tmpRAOF> doko: So, I guess one question is why are we enabling cgo on aarch64 in an SRU?
<tmpRAOF> Ok. I'm going to leave the trusty queue at the same length as when I started processing it.
<tmpRAOF> BAh.
<doko> tmpRAOF, let me discuss this with slangasek, it's not urgent
<tmpRAOF> doko: As is evident from the way that gccgo update has sat in the queue since November 2014 :)
<tmpRAOF> Ok. Thanks.
<smoser> hey, can I get a manual override of failing systemd tests ?
<smoser> and let systemd through from proposed
<smoser> https://jenkins.qa.ubuntu.com/job/vivid-adt-systemd/ARCH=amd64,label=adt/121/consoleFull is the failure, versus https://jenkins.qa.ubuntu.com/job/vivid-adt-systemd/ARCH=amd64,label=adt/119/consoleFull is the pass.
<smoser> but something else changed. the failure fails on installation of upstart-bin
<smoser> when the pass never did the installation ("upstart-bin is already the newest version.")
<cjwatson> No, the failure was not on installation of upstart-bin.
<cjwatson> It clearly gets past that.
<smoser> ?
<cjwatson> It says "Processing triggers" etc. before it fails.
<smoser> something caused debconf prompt during installation of upstart-bin
<cjwatson> That isn't consistent with the log.
<smoser> the pass it never installed upstart-bin
<cjwatson> It gets past upstart-bin's postinst and into the libc-bin trigger.
<cjwatson> If it's a debconf prompt, it's in the libc-bin trigger, not in upstart-bin.
<cjwatson> But libc-bin.postinst doesn't use debconf.
<cjwatson> So I'm curious where this debconf theory comes from.
<smoser> cjwatson, http://paste.ubuntu.com/10620817/ ?
<smoser> maybe thats noise
<cjwatson> That's irrelevant.
<infinity> It is.  Minor chroot misconfiguration, but not the failure.
<cjwatson> Although it might be a good idea for the systemd test to use DEBIAN_FRONTEND=noninteractive.
<cjwatson> (In debian/tests/cmdline-upstart-boot)
<cjwatson> Given that this test is doing a reboot, and that pitti added that code, it seems likely to be a non-trivial interaction between the reboot logic, autopkgtest, and the testbed
<infinity> Didn't there used to be a big retry button on this jenkins UI somewhere?
<cjwatson> It's on d-jenkins.ubuntu-ci:8080, not on the public jenkins.
<apw> infinity, and only if you are logged in
<infinity> cjwatson: Yes, that's where I am.
<apw> top right and tiny iirc
<cjwatson> It's already been retried, though.
<infinity> Oh, wait.  http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-systemd/ <-- Build Now in the top left?
<cjwatson> Anyway, the retry facility is vivid-adt-systemd -> Build Now
<cjwatson> yeah
<cjwatson> I wonder what version of autopkgtest is being used here?
<cjwatson> jibel: ^-
<infinity> Jenkins makes me wonder if life as a serial killer would really be all that bad.
 * smoser was just thinking "wow, this jenkins is fast!". infinity you just need to use a very slow jenkins for a while, then you'll think its great.
<smoser> ok.. so i cannot rcreate failure on 'apt-get install upstart-bin' from -proposed. on a cloud image.
<cjwatson> smoser: But that's not where it's failing!  It's failing on the *reboot*.
<cjwatson> <VirtSubproc>: failure: timed out waiting for "login prompt on ttyS0"
<jibel> cjwatson, it uses git rev. 73ad9a5 which is from 14 days ago
<cjwatson> The test process requests a reboot after installing upstart-bin, it reboots, waits five minutes, never gets a login prompt.
<cjwatson> So my worry here about overriding this is that it is in fact indicating that the one-time boot with upstart isn't working, which would be bad.
<smoser> yeah. sorry for being dense. just tested that, and 'reboot' worked . system came back up, console had login prompt.
<cjwatson> But I'd suggest trying to reproduce this locally with adt-run.
<cjwatson> http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test
<smoser> yeah.
<cjwatson> Not that it's my decision any more, but overriding failing tests of our init daemon is a pretty scary thing to ask for.  What if some later failure is masked by this?
<jibel> cjwatson, it's a different revision than on other nodes.
<infinity> cjwatson: You're still a core-dev, you get to have opinions.
<cjwatson> Oh, sure, I just mean that I no longer get to commit overrides :)
<infinity> cjwatson: Oh, true, but that inability aligns with the correct course of action (doing nothing), so it all works out.
<cjwatson> Heh.
<cjwatson> jibel: Mm, I wonder if the changes since then would help.  There are some things related to rebooting, but I don't know if we're using /sbin/autopkgtest-reboot
<jibel> cjwatson, yes, I'm double-checking the configuration of the other nodes then will update it
<cjwatson> jibel: It's failed previously on aldebaran too.
<cjwatson> http://d-jenkins.ubuntu-ci:8080/view/Vivid/view/AutoPkgTest/job/vivid-adt-systemd/120/ARCH=amd64,label=adt/
<didrocks> smoser: cjwatson: seems to be a real regression/issue (maybe only in the testbed) anyway
<didrocks> I can reproduce it under adt-run here
<didrocks> tried latest autopkgtest, the one beforehand as well (last version where systemd passed with)
<didrocks> and they are all stuck when rebooting with upstart
<didrocks> other reboots are fine
<didrocks> I tried to not get the latest grub-legacy-ec2 update, still the same
<didrocks> so I get my cloud/adt image is after the regression went in though
<didrocks> (just tried the same test, commenting the grub changes to boot to upstart, and the reboot pass)
<smoser> didrocks, so you're saying that you can recreate pass of '219-4ubuntu5'  and failure of ' 219-4ubuntu6' ?
<didrocks> smoser: sorry, no, I meant this was already failing with 219-4ubuntu5 as well
<smoser> oh. no. you're saying with latest autopkgtest they both hang.
<smoser> right.
<didrocks> just it's not systemd, not autopkgtest, not grub-legacy-ec2
<didrocks> and only when rebooting with upstart
<didrocks> (I wonder why pitti is sedding in /boot/grub/menu.lst, or maybe some other tests don't pass under some testbed config as I just call update-grub on some other tests)
<didrocks> ok, only calling update-grub and rebooting doesn't fail, so what triggers the issue is line 75
<didrocks> the sed and updated default init cmdline are sane
<smoser> didrocks, line 75 where ?
<didrocks> smoser: debian/tests/cmdline-upstart-boot
<smoser>  /boot/grub/menu.lst isn't really read anywhere to my knowledge except for 'pvgrub' boot (on ec2 instances)
<didrocks> smoser: anyway, on my local adt, it's clearly the sed setting upstart by default which causes this issue at reboot
<didrocks> I just checked, /sbin/upstart is installed
<didrocks> and I didn't see anything especially related since last systemd upload to vivid being the define root cause of that issue
<didrocks> I guess another approach would be to take a cloud image a week old, and then, doing partial upgrades until finding the culpurit
<smoser> well, one thing that changed, although i'm not quite sure how it affected this
<didrocks> smoser: did you try to reboot on a cloud image using upstart?
<smoser> is that cloud images *had* init=/lib/systemd/init
<smoser> and now they do not.
<didrocks> the grub patches handles those situations and only add the overriden init= (and the config file looks good)
<smoser> right. i thought so too
<didrocks> smoser: do you have handy some week-old images? I think it worthes giving it a simple try
<smoser> didrocks, i'll look.
<smoser> so it does fail to boot.
<smoser> i can verify that. that taking current instance, adding 'init=/sbin/upstart' and rebooting fails
<didrocks> right
<smoser> http://paste.ubuntu.com/10621472/
<didrocks> smoser: do we have ttyS0 accessible?
<didrocks> as it seems it's what adt is using
<smoser> well that is from ttyS0
<didrocks> VirtSubproc.expect(term, b' login: ', 300, 'login prompt on ttyS0', â¦)
<didrocks> so, we don't have the login prompt?
<didrocks> smoser: just used a recent cloud image, and after switching to upstart, can't boot as well (qemu stays on "Booting from hard diskâ¦")
<smoser> didrocks, well, you need to look at console.
<smoser> serial
<smoser> probalby. i'lll look
<cjwatson> I wonder if the Upstart job for ttyS0 isn't in place
<cjwatson> That was traditionally set up by the installer if booting using Upstart
<cjwatson> systemd's autopkgtest might need to put it in place
<cjwatson> See http://bazaar.launchpad.net/~ubuntu-core-dev/finish-install/ubuntu/view/head:/finish-install.d/90console, presumably something similar somewhere for cloud images
<didrocks> the job is present in cloud image though
<smoser> cjwatson, its nto that.
<smoser> booted current systemd cloud instance. install upstart-bin, chnage grub to init=/sbin/upstart
<smoser> reboot
<smoser> then... cloud-init-nonet is blocking.
<smoser> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/cloud-init/vivid/view/head:/upstart/cloud-init-nonet.conf
<smoser> that normally gets hooked all through the /etc/network/if-up.d/upstart .
<smoser> so it seems that that isnt working
<didrocks> hum, latest ifupdown was uploaded quite a while agoâ¦
<smoser> well, udev fires events that call upstart net sutff... that calls /etc/network/if-up.d/upstart ..
<smoser> i suspect it is 'init_is_upstart;' in /etc/network/if-up.d/upstart
<cjwatson> Well, it doesn't have any non-Upstart logic past that
<cjwatson> And with systemd you surely aren't waiting for the "static-network-up" Upstart event
<cjwatson> Or "net-device-up"
<cjwatson> Oh, wait, I can't read
<cjwatson>    if [ -x /sbin/initctl ] && /sbin/initctl version 2>/dev/null | /bin/grep -q upstart; then
<cjwatson>        return 0
<cjwatson>    fi
<cjwatson> That should work if init=/sbin/upstart?
<smoser> thats what i think is failing
<smoser> but i'll test that.
<cjwatson> It would be perplexing for that to fail if pid 1 is upstart
<didrocks> it's not
<didrocks> I was looking at that
<didrocks> even if pid1 is systemd, this works if upstart-bin is installed
<cjwatson> Hm, yeah, that's kind of the wrong test when what we care about is pid 1, but it should be incorrect in a direction that's harmless here
<didrocks> yeah, it shouldn't matter for that case, it's just that it will have a wrong claim under systemd :)
<didrocks> so yeah, as you told, this shouldn't fail anywayâ¦
<smoser> so i commented out that 'if ! init_is_upstart'
<smoser> and still fails
<didrocks> yeah, at least, it makes sense
<smoser> right. but for some reason, it sure appears that static-network-up is not getting run
<smoser> indeed, it even looks like networking is just not coming up at all
<smoser> because even after those timeouts, the node isnt there.
<smoser> network wise.
<smoser> ok., this is silly.
<smoser> didrocks, http://paste.ubuntu.com/10621727/
<smoser> 'apt-get install upstart-bin' does not get 'upstart'
<smoser> which means none of that stuff is there.
<smoser> which just can't be expected to boot.
<smoser> jodh, ^
<smoser> and previously, when these things were passing.. upstart was installed
<smoser> ok. so essentially, the test used to work because 'upstart' was installed.
<didrocks> smoser: ahah, good catch! I was thinking the upstart package was way more empty (only the basic tools)
<didrocks> so, I guess we should move some jobs to -bin or a -common package
<smoser> test is bogus. or woudl require a lot more work to make it work.
<smoser> yeah.
<smoser> i'm guessing its /etc/init/upstart-udev-bridge.conf
<didrocks> well, the test doesn't want "upstart" itself to be installed, really, we want to try having systemd as default and having upstart that we can optionnally boot
<smoser> that was the "no network" issue
<didrocks> so yeah, moving the jobs would fix it
<infinity> Moving the jobs is "hard".
<smoser> right.
<infinity> We discussed redoing the split instead to match systemd.
<infinity> So, "upstart" would be jobs and binaries, and "upstart-sysv" would be the overlapping bits that make it boot by default.
<infinity> I might do that this afternoon.
<didrocks> infinity: I guess you are telling this because they all are conffiles, right?
<infinity> didrocks: Right.
<smoser> so... can we let that -proposed through ?
<didrocks> yeah, the upstart-sysv sounds better as matching what systemd has
<infinity> smoser: Yeah, now that it's been root-caused, we can let it through.
<didrocks> smoser: can you run all the other tests locally?
<didrocks> as this one was in the middle of the stack
<didrocks> I can deal with it if you prefer (but probably tomorrow for me)
<infinity> ubuntu-drivers-common being completely broken is fun too.
<smoser> ok. i'll run tests
<didrocks> thanks :)
<smoser> i can reasonably expect to run them on trusty ?
<smoser> didrocks, ^ as host.
<didrocks> smoser: oh sure, as long as you have a vivid adt cloud image
<smoser> right
<didrocks> and just comment the upstart test in debian/test/control
<didrocks> upstart*
<smoser> bah. didrocks doesnt seem to want to run on trusty
<smoser> http://paste.ubuntu.com/10621864/ and eventual hang
<smoser> http://paste.ubuntu.com/10621878/
<didrocks> smoser: argh, okâ¦ do you mind if I run them tomorrow morning? I'm finishing up another systemd issue and will wrap up then
<smoser> didrocks, yeah. i have a fix i want to get in to systemd also .
<smoser> for http://pad.lv/1432829
<ubot93> Launchpad bug 1432829 in resolvconf (Ubuntu) "resolvconf not updated correctly for interfaces configured in initramfs" [Undecided,New]
<didrocks> smoser: ok, I only gives debdiff against experimental (we are using a git here, having an ubuntu branch), but my patches are not as urgent as yours I guess (they just need to be in for vivid)
<bdmurray> cjwatson: How is regression detection done in http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_excuses.yaml?
<bdmurray> cjwatson: I ask as apport version 2.14.1-0ubuntu3.8 is failing but so did 2.14.1-0ubuntu3.7
<cjwatson> bdmurray: It's up to autopkgtest.py, but I think it's "has this test ever passed at all in this series"
#ubuntu-release 2015-03-19
<didrocks> infinity: with xorg-server 2:1.17.1-0ubuntu3, all other systemd autopkgtests are now passing (there were some failures with xorg starting), so I guess it's safe to override now
<didrocks> infinity: did you get any progress on the upstart package split?
<didrocks> smoser: FYI ^
<infinity> didrocks: I ended up sleeping (I'd been up for two days :/) instead of working on reworking upstart, but I should do that ASAP, if I can't find another sucker to do it, since the current split is pretty obviously wrong.
<didrocks> infinity: tell me if I can be of any help
<didrocks> I'm happy to deal with this (this afternoon/tomorrow morning)
<infinity> didrocks: Well, I wouldn't complain if someone competent (like you) did the work and asked me to review it, but I imagine you're just as busy as I am.
<didrocks> infinity: I'm fine, I succeeded to get some spare time for systemd-related work while pitti was away, so I'll be on it soonish and propose a fix to you
<infinity> didrocks: Awesome.  So, the way I see it, the split just needs to be inverted.  upstart should contain all the non-conflicting bits (including jobs), and upstart-sysv should handle the conflicting stuff.  With some appropriate Breaks/Replaces (And Conflicts/Replaces in the case of getting upstart to force off upstart-bin) in place for smooth transition.
<infinity> didrocks: And then a bit of mangling of other bits like livecd-rootfs and some seeds and the 'init' package to cope with the shuffle.
<infinity> didrocks: I can help hunt down the "other bits" part of that without too much effort on my end, I have a pretty good handle on all the things that will break.
<didrocks> infinity: makes sense, will do that upstart-sysv package and look at the seeds. I'll need you on the livecd-rootfs though
<didrocks> ok :)
<infinity> didrocks: Hrm, actually, we might have to suffer with an empty upstart-bin that depends on upstart (that would also make this a tiny bit smoother), so people who already don't have upstart installed don't get a weird non-upgrade path.
<infinity> didrocks: That could go away for V+1, since trusty didn't have the split.
<infinity> So, 14.04 -> 16.04 would be clean, it's just U->V that wouldn't be,.
<didrocks> infinity: yeah, at least, LTS to LTS would be easier for apt, we just need to ensure we remember to kill it in V+1
 * didrocks will put some comments in debian/control
<infinity> And let me get that systemd migrated...
<didrocks> thx!
<infinity> didrocks: Alright, I'm going to go hide in a hole and finish polishing up this glibc upload, but poke me when you have something plausibly sane, and we'll talk next steps.
<didrocks> infinity: sounds good, I'll start that either this afternoon or my tomorrow morning depending on what is still on my list. Good luck with glibc!
<smoser> didrocks, i realliy want/need to get my changes in so that iscsi boot works.
<smoser> what i'd like to do is just upload a new systemd with that change also, and a disabling of the test for upstart
<smoser> i'll open a bug, and point at the bug in the disabling.
<smoser> and then you fix that bug with your upstart work.
<smoser> didrocks, ping
<smoser> i really need my systemd changes in.. so what i'd like to propose is that I upload a systemd with my fix for http://pad.lv/1432829 . and with upstart test disabled.
<ubot93> Launchpad bug 1432829 in systemd (Ubuntu) "resolvconf not updated correctly for interfaces configured in initramfs" [High,Confirmed]
<smoser> I've opened bug 1434058 and will reference that in the disabling of those tests.
<ubot93> bug 1434058 in upstart (Ubuntu) "installation of upstart-bin and boot with init=/sbin/upstart does not fully boot" [Critical,Confirmed] https://launchpad.net/bugs/1434058
<smoser> you can fix upstart and reference that test.
<smoser> does anyone object to that ?
<infinity> smoser: Or maybe it migrated an hour ago?
<smoser> oh?
<didrocks> smoser: yeah, that was what our discussion was about
<didrocks> smoser: we discovered another issue btw when running the tests, so it worthed it (issue in xorg)
<smoser> "worthed it" ?
<didrocks> smoser: loosing my morning in running the adt tests manually
<smoser> so you overrode and let it through, right?
<didrocks> losing*
<didrocks> yeah, that's done
<smoser> ok.. but i still need the other fix.
<infinity> smoser: Yeah, after all the manual testing, I let it in.
<smoser>  as i've attached to bug http://pad.lv/1432829
<didrocks> smoser: can you try to batch your fixes? we tend to do few upload, but extensive testing generally with pitti
<infinity> smoser: If you need another upload, go for it.  We'll figure out what to do.
<ubot93> Launchpad bug 1432829 in systemd (Ubuntu) "resolvconf not updated correctly for interfaces configured in initramfs" [High,Confirmed]
<didrocks> smoser: also we put all of them in debian experimental first
<smoser> didrocks, ... the ubuntu package has a -XubuntuX version
<didrocks> smoser: yeah, we have an ubuntu branch
<smoser> so confused about debian/experiemental.
<didrocks> but as told yesterday, everything is in debian git
<didrocks> and we merge patches to experimental, when it makes sense for them
<didrocks> and then, remerge in the ubuntu branch
<didrocks> smoser: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/
<smoser> didrocks, right. i can give you a git branch that has that if you want.
<smoser> i have one locally
<smoser> and http://paste.ubuntu.com/10627333/ is what i want to upload
<smoser> i have not verified that the test will be disabled, but per doc/README.package-tests.rst in adt source:
<smoser>   Any unknown fields will cause the whole stanza to be skipped.
<didrocks> smoser: did you test extensively this config with manually setup network on a desktop machine?
<didrocks> the unconditional creation of /run/network did trigger a lot of unit failure on desktop in the past
<smoser> well, as it is right now, creation of that directory is pretty unconditional
<smoser> if any network device attach event happens (ie, you have a NIC)
<smoser> isn't it ? my change made it guaranteed, but the previous behavior was that any udev event would have created /run/network.
<didrocks> smoser: why don't you let udev creating it when needed then?
<didrocks> ah, the initramfs
<smoser> udev didn't create it. systemd did. when that job ran. but by its use of RntimeDirectory, its purged on first run of that job
<smoser> right.
<didrocks> smoser: yeah sounds good, as long as you tested it extensively with and without network-manager on a vivid desktop, that's fine to me (we have other network issue to fix anyway and pitti started to look at them)
<smoser> didrocks, ok. i'll install package here and do test on my laptop.
<smoser> i do see a bug in the current ifup@.service job
<smoser> if you have an interface described in /etc/network/interfaces, but it is not 'auto' or 'allow-hotplug', then the ifup@NIC job will fail.
<smoser> my changes fix that bug also.
<didrocks> smoser: yeah, I clearly remember that we had some issues in /etc/network regarding ifup@ units, but it's now too old for my small memory :) (we fixed it though IIRC)
<smoser> didrocks, sorry to bother you.. but one question. the file i'm installing is not executable when installed via package. what would be the rigth way to do that ?
<didrocks> smoser: hum weird, are you sure it's executable in the source tree? As we are using source format 3.0 (quilt), it shouldn't be an issue. Otherwise, you can chmod +x it in debian/rules, but ensure first it's executable in the source package I would say.
<smoser> it is not executable in the soruce tree.
<smoser> is that the right way to do it ? just to chmod it in debian/ ?
<didrocks> yeah, for source format 3.0, it's fine
<didrocks> (it's not a diff, so the perms are preserved)
<smoser> thanks
<davmor2> infinity: yelp is still showing the utopic help graphics any idea when that should change at all?
<davmor2> infinity: https://bugs.launchpad.net/ubuntu/+source/yelp/+bug/1434087 incase you need to band it around a bit :)
<ubot93> Launchpad bug 1434087 in yelp (Ubuntu) "Yelp in Vivid is still showing the Utopic Unicorn Image" [High,New]
<infinity> davmor2: Should change soon, ideally. :P
<infinity> Not sure where that content comes from...
<davmor2> infinity: jibel just asked me to give vivid desktop a quick tyre kicking in readiness for beta next week only 2 issues so far is that and there are 2 languages eng_uk and eng_us rather than just eng_uk that I installed :0
<davmor2> :)
<davmor2> so not too bad :)
<infinity> Looks like ubuntu-docs.
<infinity> davmor2: Two languages where?
<davmor2> infinity: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1434091
<ubot93> Launchpad bug 1434091 in indicator-keyboard (Ubuntu) "mini.iso install of ubuntu desktop selecting only ENG_UK gives me eng_us and eng_uk" [Undecided,New]
<infinity> Generally, when you install en, you get all the en variants, though I'm not sure about the keyboard indicator, and what it's meant to do.
<davmor2> infinity: keyboard should only show eng_uk it does on other installs
<davmor2> infinity: I pointed cyphermox at it anyway :)
<infinity> I don't even appear to have a keyboard indicator here.
<davmor2> infinity: hahahaha
<infinity> Maybe it only shows up if you have more than one input source defined.
<infinity> Hrm, nope, adding a second doesn't show it.  Weird.
<davmor2> infinity: shows here on a fresh install did you upgrade for a few distros?
<infinity> Yeah.
<infinity> Though, I don't think it should show by default unless you have multiple anyway, that would also be a bug if it does, IMO.
<davmor2> infinity: it show on my desktop all the time in utopic and vivid
<infinity> Ick.
<infinity> Well, if you're not finding more serious bugs yet, little bits of polish like that are easy to knock out.
<infinity> As for the unicorn, looks like ubuntu-docs hasn't seen an upload since utopic, so that would be why.  I assume there's an update in the works.
<smoser> didrocks, still around ?
<smoser> i'm ready to upload.
<jderose> infinity: is 14.04.2 --> 14.10 supposed to be a supported upgrade path? there are some serious issues with the xorg*utopic-lts packages in that they're not transitioning correctly during the upgrade
<infinity> jderose: In theory, yes.  mlankhorst might be more interested in specifics.
<infinity> jderose: Not that I'd consider it a common upgrade path, since people who want LTS+HWE aren't the sort that would be upgrading to every non-LTS release in between, but it should still be made to work.
<infinity> mlankhorst: Guess you never tested 14.04+HWE-U to 14.10 upgrades?
<jderose> the upgrade appears to work okay, but the first time you run apt-get upgrade after the reboot, there will be a bunch of wierdness with xorg packages
<jderose> running apt-get upgrade twice seems to get things back to correct state, but there may still be some subtle problems
<oSoMoN> could someone from the release team please review bug #1433141 (FFe request) and advise?
<ubot93> bug 1433141 in webbrowser-app (Ubuntu) "[FFe] Bottom-edge gesture to open tabs list in the browser application" [Undecided,New] https://launchpad.net/bugs/1433141
<mlankhorst> infinity: it' s not a supported upgrade path
<infinity> mlankhorst: According to whom?
<mlankhorst> infinity: the only supported path from 14.04 with lts stack is to the next lts
<infinity> mlankhorst: If you install 14.04, untick the "LTS only" box in software-properties, you'll get offered an upgrade to utopic.
<mlankhorst> odd..
<infinity> mlankhorst: Why would that be odd?
<mlankhorst> infinity: if you have the lts stack enabled you shouldn't upgrade to the next stable release..
<infinity> mlankhorst: 14.04 to 14.10 is a supported upgrade path, we did nothing to intentionally break that in point releases.
<mlankhorst> infinity: yes 14.04 without lts stack to 14.10 is a supported upgrade path
<mlankhorst> that was the case with precise too
<infinity> mlankhorst: Like I said above, I think it's rare that people using LTS+HWE would want to be upgrading to non-LTS releases, but it's certainly not something we prevent.
<mlankhorst> we should prevent it, if they want to upgrade they have to remove the HWE stack first
<infinity> mlankhorst: Instead of arguing about "supported", how hard would it be to just make it work the same way 14.04->16.04 is going to work?
<mlankhorst> and imagine you're on 14.04.3 and trying to upgrade to utopic, while your hardware is not supported in utopic yet..
<infinity> mlankhorst: Preventing it is harder than fixing it, I suspect.
<infinity> mlankhorst: 14.04.3 to utopic is a no-go because utopic will EOL before 14.04.3 comes out.
<infinity> mlankhorst: Only .2 has this overlap.
<mlankhorst> infinity: just rebuild xorg-lts-transitional from trusty..
<mlankhorst> and add a special case for libgbm
<infinity> mlankhorst: Could we do that?  I know it's easier to say "well, don't do that thing", but if it's in the "simple UI", it should generally work, telling people "that's not supported" after it breaks isn't helpful.
<infinity> mlankhorst: Optionally, we could SRU update-manager and software-properties with some hacks to not let people go non-LTS if there's an HWE stack installed, I guess.
<infinity> jderose: Was this something one of your customers managed to do to themselves, or more of an idle question and experimentation on your part?
<jderose> infinity: we haven't had problem reports from customers yet. this was be testing upgrades the nividia driver packages we deliver in our PPA... at first i thought i goofed
<jderose> but the upgrade is broken even without the nvidia driver
<infinity> jderose: Yeah, apparently "not supported", I was wrong.  Though I think we should either fix that or make it hard from the UI.
<jderose> mlankhorst: infinity: okay, thanks for the clarification (was catching up above)
<jderose> but to me if 14.04.2-->14.10 isn't supported (and is broken), the update manager really shouldn't offer it when you change "Notify me of a new Ubuntu version" to "For any new version"
<infinity> jderose: Right, that was what I was saying.  Either we should fix the upgrade, or neuter update-manager.
<infinity> jderose: Slightly less concerned about commandline upgrades, unless it's horribly broken, and your report sounded less "horribly" and more "annoyingly" broken.
<infinity> But, "annoyingly broken" for CLI users is "completely screwed" for GUI people.
<jderose> yeah, annoying and confusing for the experienced... but you can seemingly work around the issues without much trouble
<jderose> er, confusing for the inexperienced, that is
<smoser> can someone please ack my systemd upload that fails due to bug 1422681
<ubot93> bug 1422681 in upstart (Ubuntu) "split out upstart-sysv" [Undecided,Triaged] https://launchpad.net/bugs/1422681
<smoser> infinity, maybe?
<infinity> smoser: I'll have a poke.
<bdmurray> slangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/component-mismatches-uploader/+merge/253587
<smoser> infinity, thank you.
#ubuntu-release 2015-03-20
<didrocks> infinity: hey! I'm just starting to look at the upstart/upstart-bin/upstart-sysv separation. There is something I want to discuss with pitti before we go on on that topic
<didrocks> infinity: the issue is about the "halt/poweroff/rebootâ¦" bins
<didrocks> as if you boot with another init, you expect to have the right binaries used of course
<didrocks> and right now, they are in the upstart package and systemd-sysv
<didrocks> not sure this worth having halt.upstart for instance
<didrocks> so, it seems we need a wider discussion to see in which direction we should go
<Ukikie> Might want to take into consideration users that do init=/sbin/upstart (as this is easy with grub2 now)
<didrocks> Ukikie: that's exactly what we are talking about with this newer split
<didrocks> (and that's the reason why we did that grub2 patch)
 * Ukikie hides.
<didrocks> ;)
<oSoMoN> Good morning release team!
<oSoMoN> could someone please review bug #1433141 and advise? Itâs being validated by the QA team, will shortly be ready to land, but needs an ack from you
<ubot93> bug 1433141 in webbrowser-app (Ubuntu) "[FFe] Bottom-edge gesture to open tabs list in the browser application" [Undecided,New] https://launchpad.net/bugs/1433141
<bdmurray> slangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/phasing-link/+merge/253720
<bdmurray> infinity: it looks like it'd be a good idea to get dpkg version 1.17.24 into Vivid. What needs to happen for that?
<bdmurray> I'm referring to the "Disable dependency checks on trigger processing." change in it.
<infinity> bdmurray: I'll be merging it soon.
<bdmurray> infinity: okay, thanks!
<bdmurray> infinity: Do you think I should won't fix the bugs created by trigger loops?
<infinity> bdmurray: I think they're worth investigation.
<infinity> bdmurray: Not in utopic, but in trust->vivid (and, eventually, 14.04->16.04) upgrades, we should care.
<bdmurray> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776910 I was reading the last comment there
<ubot93> Debian bug 776910 in apt "apt: upgrade from wheezy to jessie breaks in the middle" [Grave,Open]
<bdmurray> Paragraphs 2 and 4
<infinity> bdmurray: Right, so what I mean by "we should care about trusty->vivid (and beyond)" is that we should only care about trigger cycle bugs found that are upgrading with dpkg 1.7.24 or higher.  Which, if guillem did this right, should be 0.
<infinity> bdmurray: But the feature may creep back in before 16.04, and we need to pay attention to that.
<infinity> bdmurray: I'll merge today, though, so we can see how this affects new bugs.
<infinity> bdmurray: Old ones, we can probably drop on the floor, if no one has the energy to re-test those upgrades.
<bdmurray> infinity: I don't think the dpkg version necessarily gets recorded in these apport reports so I'll fixes that.
<infinity> bdmurray: If we're not recording dpkg and apt version in all upgrade reports, that's a massive bug.
<infinity> bdmurray: And python-apt, if update-manager or ubuntu-release-upgrader was in play.
<bdmurray> python-apt will get caught in that case because its a dependency
<slangasek> bdmurray: this retrace failed with missing symbols for libsystemd0 and libflac8, which is pretty bad; are these known-missing ddebs? https://errors.ubuntu.com/oops/e3c5729c-cf0a-11e4-8e21-fa163e5bb1a2
<slangasek> bdmurray: also, that retrace failed, but neither systemd nor flac libs are in the stack so that's also bad :)
<bdmurray> slangasek: known to me yes
<slangasek> bdmurray: ah; libsystemd0 is in the list you sent me earlier, I see, but not libflac8.  Anyway, how can we debug the retracing failure, given that it seems unrelated to the missing symbols?  The crash in question was from testing libc from vivid-proposed on a vivid system, would that account for the retracer not knowing where to find the symbols?  And can we extract a core file for manual retraci
<slangasek> ng?
<slangasek> though libc6 itself wasn't listed as having missing symbols hmm
<slangasek> cjwatson: I've tried to enable arm64 builds for ubuntu-core, and it's failing with errors that look like a networking problem; would you know if there's anything particular to twombly that would prevent it from reaching ppas etc? https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/+build/23106
<bdmurray> infinity: new apport uploaded
<bdmurray> slangasek: I think we save cores for some failures to retrace let me double check
<infinity> slangasek: It can obviously reach PPAs, it did so earlier in the build log.
<slangasek> ah true enough
<slangasek> but it's still failing with networking failures
<infinity> Could have just been an intermittent hiccup.
<slangasek> could be; retrying
<slangasek> note fwiw that arm64 was the only arch that failed with this problem
<infinity> slangasek: It's going to fail anyway, that linux-image package doesn't exist.
<slangasek> well, that's ok
<slangasek> those are bugs that clearly belong to the image :)
<infinity> ... how does that work on any arch?
 * infinity scratches his head.
<infinity> Oh, wait.  linux-packages, not linux-flavours
<infinity> Yeah, that should work.
<infinity> I just can't read.
<elfy> cyphermox: re the com32 bug you just added to - did you mean 13.04 or 14.04?
<cyphermox> depends what you mean by what I mean?
 * infinity laughs.
<cyphermox> writing a live USB from vivid to 13.04 fails to properly start
<cyphermox> ... the splash will not show, you'll get that com32 erro
<elfy> is that because it's all completely EOL?
<elfy> unless you start fiddling with oldubuntu repos
<cyphermox> it's just an example of what versions to use, it's because they don't have the same structure for syslinux
<cyphermox> you could use 12.04
<elfy> ok :) just making sure ...
<cyphermox> I mention 13.04 and 13.10 because IIRC that's where the difference was introduced
<elfy> I did some tests so I could be sure that people could test jam Xubuntu recently - told them to install gnome-disks and use Disks ...
<cyphermox> the exact versions don't matter as long as you use an older version of Ubuntu to write a very recent USB (ie. precise writing vivid), or the other way around
<elfy> obviously all of those entailed a vivid image from trusty/utopic or vivid
<cyphermox> elfy: since the SRU is for utopic only so far (I haven't tested trusty in a VM here yet, the changes were a bit more complicated), you'll want to use a precise iso for writing
<elfy> and for Xubuntu you need to install one or the other ...
<cyphermox> I'm not sure I follow
<elfy> I'm rambling probably - we were after specific information - whatever you use to do USB stick has to be installed on Xubuntu - so I was looking for something that worked in all 3 scenario's
<elfy> I'll wander off again and not confuse the issue further ;)
<cyphermox> elfy: use dd if you're unsure
<cyphermox> isn't usb-creator installed on xubuntu?
<elfy> nope
<elfy> oh - actually might be - never use it personally
<elfy> cyphermox: didn't want to expose possible new people to getting dd wrong ...
<cyphermox> ok
<cyphermox> well yeah, getting it wrong is usually disastrous :)
<elfy> :)
<elfy> usb-creator's not on the manifest for us
<cyphermox> no, doesn't look like it's included
<cyphermox> might want to consider changing that :)
<elfy> why?
<elfy> I tell people to use Disks :)
<cyphermox> fair enough
<cyphermox> well you could still ask them to pull usb-creator-gtk when needed
<cyphermox> but if Disks works..
<cyphermox> does Disks do a full copy?
<elfy> cyphermox: for me at least I got positives using that when doing vivid images from 14.04/14.10/15.04
<elfy> restore image
<cyphermox> ok, sounds like it's probably nearly the same thing as dd... or running dd in the background
<elfy> doesn't make it very easy to deal with the stick afterwards - owned by root
<elfy> yep - seems so
<bdmurray> slangasek: so we don't save coredumps if RetraceOutdatedPackages is true and it is true if we are missing ddebs as apport mixes the two together
<slangasek> infinity: failed again with the same error.  not transient. https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/+build/23110
<slangasek> bdmurray: hmm ok
<bdmurray> We could start saving them though
<slangasek> davmor2: is your media-hub crash with https://errors.ubuntu.com/oops/e3c5729c-cf0a-11e4-8e21-fa163e5bb1a2 still available locally?
<slangasek> davmor2: or is the problem reproducible?
<slangasek> bdmurray: perhaps a good idea
<infinity> slangasek: Curious.  Investigating.
<slangasek> does also show the problem is not specific to a single arm64 builder
<infinity> slangasek: Yeah, going to reproduce it manually quickly to see WTF it's doing.
<slangasek> ok
<infinity> Oh, that traceback has the required info.
<infinity> I was just blind on the first reading.
<infinity> Or the first log had a less useful trace.
<infinity> softwareproperties.ppa.PPAException: 'Error reading https://launchpad.net/api/1.0/~snappy-dev/+archive/image: [Errno 110] Connection timed out'
<infinity> It's making API calls.
<infinity> On the one hand, "ew", on the other hand, can get IS to fix.
<slangasek> infinity: so you'll chase it up?
<infinity> slangasek: Already on it.
<slangasek> ta
<infinity> slangasek: So, there may or may not be a cowboy in place that may or may not work (feel free to test), but the larger issue now has a ticket, RT#79768
<infinity> slangasek: FWIW, I can make an 'openssl s_client' connection from that network to {api.,}launchpad.net:443 now, so it should work.
<infinity> slangasek: Hah, the api call worked and I bet it's now going to fail on contacting keyserver.ubuntu.com
<infinity> slangasek: Also, who thought this was a sane thing to do in an image build?
<wgrant> Ew
<wgrant> ew
<infinity> wgrant: Yes, ew.
<infinity> wgrant: I said that very same thing 14 minutes ago.
<infinity> Yup, there it goes failing on the keyserver.
<infinity>     Rename it to the more domain-specific EXTRA_PPAS (which is now a
<infinity>     space-separated sequence of <ppa-owner>/<ppa-name> pairs), and fetch
<infinity>     signing keys for those from Launchpad using python3-software-properties.
<infinity>  -- Colin Watson <cjwatson@ubuntu.com>  Mon, 19 May 2014 15:28:35 +0100
<infinity> wgrant: Hey, don't you employ that guy now? :)
<wgrant> Heh
<infinity> wgrant: You know, on second thought, the datacentre is probably the only place in the world where add-apt-repository isn't a massive security hole, so maybe it's not that "ew". :P
<infinity> wgrant: Speaking of, could we close that massive security hole by serving the actual public keys via https://api.lp.net instead of just fingerprints?
<infinity> (Sure, it still means trusting the lp.net SSL cert, but that beats a plain HTTP connection to a keyserver)
<wgrant> infinity: I thought the massive security hole was fixed years ago.
<wgrant> It's meant to now download into a temporary keyring by fingerprint, then verify the fingerprint before importing into the main keyring.
<infinity> wgrant: Verify it against what?
<darkxst> infinity, hey, can you bump space on gnome3-staging ppa up a bit? sitting at 92% currently
<wgrant> infinity: The fingerprint from the LP API.
<infinity> wgrant: Still vulnerable to a fingerprint collision, since it's not the actual public key we're getting via a secure source.
<wgrant> infinity: Fingerprint, not ID.
<wgrant> If someone manages to collide fingerprints the entire world is broken and we should probably just move into caves.
<infinity> wgrant: Oh, well, less bad then, certainly.
<infinity> wgrant: Still seems like an odd runaround, since I assume LP has knowledge of the keys somewhere anyway.
<wgrant> Colliding fingerprints requires a good SHA-1 preimage attack.
<wgrant> infinity: LP just uses keyserver.internal.
<wgrant> It doesn't store the keys themselves.
<infinity> wgrant: Oh.
<infinity> wgrant: Well, I guess ppamaster has them all, but yeah, just on disk.
<wgrant> Well, sure, but they're well-defended given that they're private keys...
 * infinity nods.
<wgrant> The appservers cannot see them!
<infinity> Right, if this has been sorted to use fingerprints, I care less.
<wgrant> https://launchpad.net/bugs/1016643
<ubot93> Launchpad bug 1016643 in apt (Ubuntu Precise) "add-apt-repository downloads gpg key in an insecure fashion" [High,Triaged]
<infinity> I just saw "whee, downloading a key by ID from an insecure source" and didn't like what I saw. :P
<wgrant> (really the bug is in gpg, which should allow secure retrieval)
<wgrant> That is, it should verify the fingerprint matches what it requested.
<infinity> We could also default to hkps instead of hkp.
<infinity> If we're already trusting Canonical SSL certs in this scenario for the LP API, then a cert on the keyserver would be the same level.
<wgrant> That provides no value except for preventing someone from watching what you're doing.
<wgrant> OpenPGP keys are cryptographically verifiable in other ways, and we should do that without relying on a secure transport.
<wgrant> If it requested by key ID from a secure keyserver, I could still upload a colliding key and it will trust it because HTTPS.
<infinity> Sure.  I'm definitely no cryptographer.
<infinity> But even a fingerprint is less good than the whole public key, one would assume.  Despite, as you say, it being hard to collide.
<wgrant> We can verify the fingerprint, and that is secure unless someone has a secret SHA-1 preimage attack, so we should do that.
<infinity> Oh, fair point on the ID collision.  keyserver.ubuntu.com is publically modifiable, I forget about that detail.
<wgrant> OpenPGP should probably grow SHA-256 fingerprints, though for ECC keys it could also probably print them directly.
<wgrant> But even MD5 isn't seriously broken for key fingerprinting purposes.
<infinity> Really, fingerprints seem more for human consumption than computers, though.
<wgrant> I wouldn't use it, but there are no huge known weaknesses so far.
<wgrant> The fingerprint is just the SHA-1 of the public key.
<wgrant> Just as we use the SHA-1 of Packages to verify it.
<infinity> I'll take your word on the collision-being-hard thing, since you've clearly read more than I have, but it just seems like simple logic that if you could give a computer the public key, you should, cause why intentionally weaken it, even if only by a little bit?
<wgrant> (except you don't usually compare Packages files, as they're OpenPGP-signed... by a key that your OS trusts or that you've verified the SHA-1 of!)
<wgrant> s/Packages files/Packages files' SHA-1s/
<wgrant> SHA-1 is becoming problematic for generic crytographic uses, but in this context it is a good many years away from being an issue.
<infinity> And fear of Sha1 is why all the Packages/Sources files now have Sha256, I thought. :P
<wgrant> Yes!
<wgrant> But that's because a collision attack is plausible there.
<wgrant> That's why modern keys use SHA-2 defaults for signatures that they generate.
<wgrant> MD5 is very vulnerable to collision attacks, and SHA-1 looks like it will fall soon.
<wgrant> But both are still fine against preimage and second-preimage attacks, and those aren't relevant for key fingerprints.
<infinity> I imagine this all relates to math I forgot somewhere in my early 20s.
<infinity> Intentionally.
<wgrant> Collision == choose two inputs that hash to one output
<infinity> Yes, I know. :P
<wgrant> Preimage == choose one input that hashes to the same as a given input
<wgrant> Second-preimage == choose one input that hashes to a given output
<wgrant> The infamous PS3 MD5 collision was only possible because they were able to choose most of the data in both inputs, and were able to guess everything they couldn't choose.
<infinity> Ahh, so the contention is that sha1 is vulnerable to accidental collisions just because the search space is small and the number of files in the world is large, but actually crafting an intentional and useful collision (like another PGP key) is still hard/impossible.
<wgrant> infinity: Not accidental collisions.
<wgrant> The contention is rather that collision attacks aren't relevant for public key fingerprints, since the attacker has no input into your public key (unless they compromise your RNG, in which case they probably have your private key anyway), so no collision attack is possible. Combine that with the very low risk of a practical SHA-1 (second-)preimage attack in the next couple of decades, and SHA-1 for
<wgrant> fingerprints looks not particularly fatal.
<wgrant> Certainly not something I'd pick today, but not a problem for a good long time.
#ubuntu-release 2016-03-21
<rbasak> infinity: any progress on mysql-5.7 NEW please?
<Odd_Bloke> Anyone around who could ACK gce-utils 1.3.3-0ubuntu2~15.10.0 in to partner proposed, and gce-utils 1.3.3-0ubuntu2 in to xenial's partner?
<flocculant> infinity: hey there :) what sort of timescale are you looking at for getting the ball rolling with Final Beta?
<flocculant> cyphermox: just so you know following our discussions re Xubuntu, I 'did' get xubuntu to upgrade from 14.04 in kvm and vbox (no time to look at hardware) but they all needed me to fiddle about with dpkg --configure after they all hung
<cyphermox> err ok
<cyphermox> I'll try again later then
<flocculant> cyphermox: just thought I would let you know - seems a bit daft to do so in 'our' channel when it's a global thing :)
<flocculant> cyphermox: what I couldn't quite get my head around was - they all appeared to hang in the terminal you can see at the /etc/gnome/defaults.list - but above each one was showing a different thing (the gui bit) not really sure which is the real current item there
<cyphermox> ok, but did the mouse cursor still move?
<rharper> Hi,  could someone look at this FFE for tgt, https://bugs.launchpad.net/ubuntu/+source/tgt/+bug/1555700
<ubot5> Launchpad bug 1555700 in tgt (Ubuntu) "[FFE] Please merge tgt 1.0.63 from Debian (unstable)" [Undecided,New]
<flocculant> cyphermox: nope - nothing at all - and it wasn't waiting for anything - I went to the market when one hung ...
<cyphermox> ok
<flocculant> rebooting I could either get to a recovery menu and dpkg fix from there, or let it boot then do that from a vt
<flocculant> this *is* just the lts to lts from update-manager, wily works as does from the image
<flocculant> just to be completely sure we're talking about the same thing :)
<infinity> rharper: So, the only upstream change is that bugfix in tgtd.c?
<infinity> rharper: I guess the FFe is for enabling the aio backend?
<rharper> infinity: sync a fix (drop patch) and enable AIO; yes
<infinity> rharper: Right, no FFe needed for the patchy bit, nor the upstream bugfix.
<infinity> rharper: As for the AIO thing, as you understand the code, what are the odds this could have a negative impact on users of other backends if the AIO stuff is broken?
<infinity> rharper: If you're 99% confident that the change is meaningless for people who don't use the feature, then I'm fine with adding it.
<rharper> infinity: ok;  re aio;  let me look a bit to be certain, libaio is standard stuff;  the question is has tgt had aio for quite some time and just not enabled it (and why);  debian recently added it
<infinity> rharper: Right, it's obviously been there longer upstream than in Debian, the question is how long and, more importantly, is it isolated enough to not blow up the world for non-AIO users if it sucks.
<infinity> rharper: The latter question being the interesting one.  I don't care if the feature it experimental and added last week if it has zero impact on people who don't use it.
<infinity> s/feature it/feature is/
<rharper> understood
<infinity> rharper: Feel free to copy and paste any of the above to the bug, FWIW, and if your conclusion is "yeah, it looks safe enough", no need to round-trip to me again, FFe approved if your best judgement says it's safe.
<rharper> infinity: will do; I need to confirm aio is only enabled via user choice (ie not default); if so then I'd say it's out of the way for anyone except those whom request it;
<infinity> rharper: And if you're less sure, a commitment of "we'll actively watch for explosions and either fix the issues or revert the aio addition", then also approved. :P
<infinity> rharper: With a caveat that "revert the aio addition" can only be a solution pre-release.  Once xenial is out the door, you're stuck supporting whatever features we released with.
<infinity> rharper: If you're okay with the above, go nuts.
<rbasak> infinity: any progress on mysql-5.7 NEW please? Note that I'm out from Friday through Wednesday next week (back on Thursday) so I'd really like to get things done before I go if possible.
<rbasak> infinity: I didn't think it'd take much NEW review because it's a version bump of an existing package (except for the soname bumping bits).
<infinity> rbasak: Yeah, it shouldn't be a hard review, I've just been dreadfully ENOTIME.
<rbasak> You and me both.
<rbasak> infinity: do you want to pass the review to someone else if available?
<rbasak> I can ask jgrimm to find me someone.
<infinity> rbasak: Any AA should do if, as you say, the debian/* delta is minimal and obviously correct.
<rbasak> The debian/* delta is unfortunately extensive, but I have broken it down for easy review if someone wants to follow along.
<infinity> rbasak: Ahh, well I'm hip-deep in glibc (and then the beta freeze) today, so if you find another AA willing to follow along, go for it.  It shouldn't block on me, that's for sure.
<rbasak> slangasek: ^^ available for a NEW review of src:mysql-5.7 please?
<mapreri> cjwatson: can I push for a couple of RM? #1556229 #1556226
<cjwatson> mapreri: not today, just finishing up
<mapreri> ok
<flexiondotorg> When will the archive freeze for final beta testing?
<infinity> flexiondotorg: Tonight.
<flexiondotorg> infinity, Oh, cool.
<flexiondotorg> Your tonight?
<flexiondotorg> How many hours from now?
<infinity> flexiondotorg: Yes, and not sure.
<flexiondotorg> OK
<yofel> could someone please try to hint breeze and breeze-icons together? breeze-icons takes over the old breeze-icon-theme package from breeze
<infinity> yofel: They should go together automatically if the package deps are correct.
<doko> meh,  mysql-5.7 accepted despite the build failures?
<infinity> doko: Blame your manager.
<infinity> armhf and s390x should be a matter of fixing the libnuma-dev build-dep.
<infinity> The arm64 failure looks more fun.
<slangasek> doko: well, someone accepted the source package that rbasak pinged me about earlier, so my queue accept command accepted binaries instead
<slangasek> also, why should the build failures stop the successful ones from being accepted?
<infinity> slangasek: So we don't get half a transition skewed across arches.
<infinity> slangasek: (SOVER bump in libmysqlclient)
<doko> slangasek, I looked at it, and found nothing wrong. however maybe I didn't look for FFe's
<slangasek> infinity: ah
<infinity> doko: They had an FFe, it was just waiting a source review, so if you were happy with it, all the ducks are in a row.
<infinity> But we need to fix the FTBFSes now. :P
<yofel> infinity: yeah, but I see no auto-hint... the old breeze has an exact version dep on breeze-icon-theme which was from the same source, the new one an unversioned one on the external same binary from breeze-icons.
<yofel> That installs fine, but the autohinter doesn't seem to see the connection
<yofel> or something else is going on that I'm not seeing
<infinity> yofel: Ahh, so no files moved between binary packages, it's just that the binary package migrated between sources?
<yofel> exactly
<infinity> Kay, it's possible britney's being a bit stupid about that.
<infinity> yofel: Hinted.
<yofel> thanks
<slangasek> heh, Arch: all pixfrogger build-depends: fenix-plugins-system, which only builds on 32-bit archs. I wonder if I should fix the package's arch affinity?
<infinity> slangasek: Seems like a good use for that header.
<infinity> Alright, so mysql/powerpc wants -latomic, s390x/armhf want fixed build-deps, arm64... I dunno.
<infinity> Maybe I'll delete the binaries from proposed while we sort this.
#ubuntu-release 2016-03-22
<rbasak> infinity: arch skew? I was offline before. Anything I need to do?
<rbasak> Looks like it failed on various archs for various reasons.
<rbasak> Skuggen: can you take a look please?
<rbasak> https://launchpad.net/ubuntu/+source/mysql-5.7/5.7.11-0ubuntu1
<rbasak> Missing libnuma-dev on armhf and s390x.
<rbasak> Undeclared __NR_epoll_wait in libevent on arm64.
<rbasak> "Native atomics support not found!" on powerpc.
<rbasak> Pretty spectacular!
<infinity> rbasak: I tihnk I have it all fixed except for powerpc.
<infinity> rbasak: That one's going to take teaching upstream that it's 2016 and porting from __sync to __atomic functions.
<infinity> Which I might do later tonight if bored enough.
<infinity> But first I need food and a brain break.
<cjwatson> With any luck Debian imports should be fixed after the next time the cron job finishes, typically in around three hours.
<cjwatson> (from now I mean)
<cjwatson> But we shall see.
<tsimonq2> out of curiosity, if one were to want a metapackage in the Ubuntu archives, is it too late in the release cycle? it's just a metapackage...
<slangasek> it is not in principle too late.  in practice you may be hard pressed to get AA time to look at the new packgae
<tsimonq2> but let's say it only pulls in like 15 packages and is part of a team that can endorse it?
<tsimonq2> like a flavor?
<tsimonq2> slangasek: ^
<slangasek> tsimonq2: only somewhat relevant.  The fact that it's a metapackage /suggests/ it will be an easy review and that increases your odds of an AA picking it up; but AA time is a scarce commodity in the latter part of the cycle
<tsimonq2> slangasek: how do I start this process?
<slangasek> tsimonq2: getting the package uploaded to the NEW queue
<slangasek> cjwatson: oops, devscripts is dep-wait on libuniversal-require-perl!  I have a suggestion on how to clear this dep-wait ;)
<cjwatson> slangasek: http://irclogs.ubuntu.com/2016/03/22/%23ubuntu-devel.html#t02:18
<cjwatson> slangasek: though I acknowledge your more basic point :)
<cjwatson> Hopefully tomorrow I won't have to spend a good chunk of the day on the phone to my ISP
<slangasek> hmm so now pixfrogger is built, but p-m also won't let it through because uninstallable on amd64
<slangasek> do we have a way to hint around that?
<infinity> You can force it and lower the installable count.  Which I'm not super keen on.
<infinity> A few releases back, cjwatson and I were intentionally converting things from all to arch-restricted where they had unsatisfiable deps.
<slangasek> infinity: we do have FauxPackages in britney1; would that do any good?
<infinity> slangasek: We could fill FauxPackages with a bunch of deps for arch:all packages, yes, but that's a bit gross once the list exceeds a handful.
<cjwatson> debmirror is working now on iron, but I think it's going to miss the stupid hardcoded five-minute time allocated for it to run before gina starts.
<cjwatson> I really must fix that.
<cjwatson> It might manage to make it in time to get unstable imported though, just miss experimental.
<stgraber> gah, who broke golang on powerpc again?
<stgraber> well, gccgo because no golang on it
<stgraber> mwhudson: around?
<slangasek> stgraber: perhaps related to the ongoing transition to enable versioned golang packages
<cjwatson> Ah, no, experimental is small so was processed quickly.
<stgraber> slangasek: yeah, I guess so
<stgraber> mwhudson: https://launchpadlibrarian.net/249534628/buildlog_ubuntu-xenial-powerpc.lxd_2.0.0~rc5-0ubuntu1_BUILDING.txt.gz
<stgraber> mwhudson: "No such file or directory" for the go command is a bit problematic :)
<cjwatson> Some things might end up being imported straight into stretch without going through sid from LP's point of view, which would be a bit odd.
<cjwatson> Hopefully not many.
<stgraber> let me see what we depend on right now, I had to change that stuff back and forth a few times in the past
<infinity> stgraber: gccgo stopped providing it as an alternative, so we could move to a go-defaults sort of world.  Looks like the second part isn't entirely sorted yet.
<stgraber> infinity: fun, so in the mean time go is busted on arches requiring gccgo?
<infinity> stgraber: Pretty sure golang-go is meant to provide the right links now that gccgo doesn't.   I think.
<infinity> stgraber: Poke mwhudson even harder, I'm sure he'll sort it when he wakes up.
<stgraber> yeah and we depend on golang-go because it's available on all arches and we were told that it would DTRT, apparently it doesn't anymore
<infinity> Oh, wait, he shold be "awake" now.  My clock is backwards.
<stgraber> isn't it like 5pm for him, he should still be working
<stgraber> or at least be awake :)
<infinity> stgraber: golang-go is the right thing, it's just mid-transition to a new world order.
<infinity> mwhudson: mwhudson mwhudson mwhudson mwhudson mwhudson mwhudson mwhudson
<infinity> stgraber: Ahh, yes, here's the problem.
<infinity> stgraber: https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1555856
<ubot5> Launchpad bug 1555856 in golang (Ubuntu) "move to per-Go-major version coinstallable packages" [Undecided,New]
<infinity> stgraber: It required changes in gccgo, golang, and the new golang-defaults.  But only gccgo was changed.
<infinity> stgraber: Resulting in this. :P
<mwhudson> infinity: hi
<mwhudson> yes, i was expecting some coordination on this
<infinity> mwhudson: Hi.  So, the GCC changes for this landed before everything else, and now stgraber's sad.
<stgraber> seems like a bit of a fail, surely this was meant to land together :)
<mwhudson> but doko apparently didn't think so, or didn't notice
<infinity> mwhudson: If golang-go on powerpc just a stub that depends on gccgo right now?
<mwhudson> yes
 * infinity wonders if we could stuff the symlinks in there to fix the current situation while we work on the grander plan.
<mwhudson> it will become an almost stub that depends on gccgo and ships a symlink when golang-defaults gets uploaded
<mwhudson> yeah, that would be doable
<infinity> I don't know what all needs linking.  You have a mapping somewhere?  I guess you must for golang-defaults.
<infinity> Not that I'm against us doing this correctly very soon, but it's been a looooong day, and I'd rather just see lxd build. :P
<mwhudson> https://git.launchpad.net/~mwhudson/+git/golang-defaults/tree/debian/golang-go.links.gccgo
<mwhudson> infinity: hacking up a change now
<mwhudson> is there a bug filed?
<infinity> mwhudson: Nope.
<infinity> Well, not that I know of.
<infinity> Just an angry little Swiss man.
<mwhudson> testing http://paste.ubuntu.com/15469992/ now
<stgraber> :)
<mwhudson> oh ffs quilt
<mwhudson> try http://paste.ubuntu.com/15469995/ instead
<mwhudson> first hunk for testing only, obv
<stgraber> that's much more readable :)
<infinity> mwhudson: I assume amd64 is your fake powerpc for local testing? :P
<mwhudson> yeah
<mwhudson> that didn't work
<stgraber> s/deb/debian/ ?
<infinity> mkdir -p deb/golang-go/usr/bin/go ? :P
<stgraber> well, that's wrong too ;)
<infinity> s/deb/debian/ and perhaps go shouldn't be a directory.
<stgraber> that's a lot of wrong for such a tiny diff :)
<infinity> stgraber: You try typing upside-down.
<stgraber> infinity: you managed it for a while :)
<infinity> mwhudson: Oh, also, -6, not -5 ...
<infinity> That really is a lot of wrong in a small diff.
<mwhudson> infinity: life is happening here
<infinity> mwhudson: I can only imagine. :)
<mwhudson> infinity, stgraber: ok http://paste.ubuntu.com/15470049/ should be non-hilariously broken
<infinity> mwhudson: That looks more plausibly correct indeed.
<infinity> mwhudson: Fire away.
 * stgraber test builds + test installs on powerpc
<mwhudson> infinity: one of you will have to do the actual launching
<infinity> mwhudson: Oh.  I'm sure we can manage that.
<stgraber> yeah, I'll sponsor once the test build is done
<infinity> stgraber: When you've confirmed it DTRT, sponsor away, and I'll accept.
<infinity> Jinx.
<mwhudson> i suspect you've both done one or two uploads
<infinity> mwhudson: Ish.
<stgraber> root@test:~/test# go version
<stgraber> go version go1.6 gccgo (Ubuntu 6-20160319-0ubuntu1) 6.0.0 20160319 (experimental) [trunk revision 234350] linux/ppc
<stgraber> root@test:~/test#
<stgraber> pretty
<mwhudson> \o/
<infinity> stgraber: What timezone are you in right now?
<stgraber> eastern
<stgraber> but mostly working pacific-ish
<infinity> stgraber: The latter was what I was asking.  Physical location is meaningless. :P
<infinity> stgraber: So, we're probably about lined up.  I guess we can both babysit lxd/lxcfs, and the last man standing can trigger the ubuntu-server build.
<stgraber> yep, hopefully the adt runners aren't too busy
<infinity> They're empty.
<infinity> stgraber: Oh, feel free to unblock both.  Your upload, you can do the paperwork.
<infinity> Err, unblock all three, I guess, including golang.
<infinity> If golang would be blocked.
<infinity> Maybe not.
<infinity> I dunno.
<stgraber> uploading
<stgraber> infinity: apparently none of them are in the big block of doom
<infinity> Huh.
<stgraber> that's convenient but also maybe a bit worrying
<infinity> That's a mistake.
<infinity> But okay.
<infinity> Oh.  I may have missed server in the block.
 * infinity fixes.
<stgraber> oh and I need to hint lxc through too, debci failed again, that testsuite is so racy...
<mwhudson> the blocks are based on binary package name, right?
<infinity> mwhudson: No, source.
<mwhudson> hm, then you may want to do something pre-emptive around the golang-1.6 gubbins
<infinity> golang's not on any media.
<mwhudson> oh right
<infinity> Ugh.  Am I really going to upload d-i three times today?  Yes, other Adam, I think you are.
 * mwhudson afk for a bit
<stgraber> pushed a skiptest for lxc (really need to get pitti to figure out wth is going on with the debci adt) and pushed an unblock for lxc, lxd, lxcfs and golang
<stgraber> so if I didn't screw up the version numbers, britney should be happy
<infinity> Alright, rebuilding the world except for lubuntu and server.
<infinity> And going to go watch some tee vee.
<infinity> Hrm.
<infinity> ubuntu-archive@snakefruit:~$ /home/ubuntu-archive/ubuntu-dev-tools/seeded-in-ubuntu zygrib
<infinity> /usr/lib/python2.7/dist-packages/lazr/__init__.py:19: UserWarning: Module devscripts was already imported from /home/ubuntu-archive/python/devscripts/__init__.pyc, but /usr/lib/python2.7/dist-packages is being added to sys.path
<infinity> stgraber: Any idea what that vomit's all about?
<infinity> (it's breaking auto-accept)
<stgraber> refresh ubuntu-dev-tools maybe? I'm not getting this on my system
<stgraber> oh, snakefruit is still 12.04, fun
 * stgraber fixes
<infinity> Erk.
<infinity> Shouldn't have done that pull.  Conflicts.
<Skuggen> infinity, rbasak: I'm up! What'd I miss?
<infinity> Skuggen: A bunch of build failures.  The only really interesting one is powerpc failing due to upstream using ancient __sync builtins instead of __atomic
<stgraber> infinity: are you fixing lpapicache.py now?
<Skuggen> infinity: This is still the current state? https://launchpad.net/ubuntu/+source/mysql-5.7/5.7.11-0ubuntu1
<stgraber> infinity: dropping that MERGE-SOURCE line should do the trick, but vi is telling me someone is busy editing it already :)
<infinity> stgraber: I was fixing. :P
<infinity> stgraber: Should be happy now I think.
<stgraber> infinity: well, good news, seeded-in-ubuntu is happy now
<infinity> Skuggen: No, I've got a WIP here, I'll play with it more tomorrow.
<stgraber> doesn't even need my gross workaround (configuring python-warning to hide all warnings)
<infinity> \o/
<stgraber> ^ was that an auto-accept?
<infinity> It was.
<stgraber> cool
<infinity> And lxd built.
<infinity> Things are coming together.
<stgraber> oh, apparently you were better at watching golang-go than I was, that thing took forever to publish
<Skuggen> infinity: Ah, nice. For the platforms that were/will be fixed, do you think you could make some notes of anything that needs to be fixed upstream?
<Skuggen> I know we're working on some of these platforms, but except arm64, which we just got, we don't really have the hardware
<infinity> Skuggen: http://paste.ubuntu.com/15470483/ <-- That should fix everything but powerpc.
<infinity> Skuggen: powerpc will be more involved, due to your using obsolete atomics.
<infinity> Skuggen: The WITH_LIBEVENT=system is (a) a saner packaging default anyway, but (b) necessary on arm64 because your bundled libevent is broken on arm64.
<stgraber> oh, guess I should drop edubuntu from the crontab (except for trusty)
<Skuggen> infinity: I'll pass it on, thanks
<infinity> stgraber: You guys have definitely decided it's dead?
<pishuilu> infinity: Hello, can you help me? approve the upload of ubuntukylin-default-settings package.
<infinity> pishuilu: I can indeed help.
<stgraber> infinity: for 16.04, yeah, then we're giving a chance for whoever to pick it up by 17.10 (so we can have a 18.04), if nothing happens by then, we'll start doing package removals
<pishuilu> infinity: Thank you.
<infinity> pishuilu: Is that's a ini-style file, your diff is wrong.
<infinity> pishuilu: You shouldn't have two stanzas for [com.canonical.Unity.Launcher]
<infinity> pishuilu: All the keys for that item should be in the same block.
<infinity> stgraber: Sadness.  The end of an era.
<pishuilu> infinity:  OK ,thank you. I change it now.
<stgraber> infinity: yeah, it's pretty sad though it's been just highvoltage and I for a few years now and we clearly don't have enough time to put in it, so we'd rather spend the little time we have to do the 14.04 maintenance than ship a broken 16.04 that we'd have to deal with for 5 years...
<infinity> stgraber: Yeahp, understood.  Would be good if you could find new blood.
<infinity> (ideally someone with an actual itch to scratch, like a school admin with a deployment)
<stgraber> yep
<infinity> It's so very hard maintaining software you don't actually use.
<infinity> stgraber: That reminds me that we (the TB) need to poll the rest of the flavours for their LTSness.
<stgraber> and yeah, we're both happy to sponsor the uploads of anyone who wants to take the project over, then once they understand how everything works, we'd make them Edubuntu Council member and that'd be the beginning of a new era. Whether that will happen, I have no idea though...
<infinity> stgraber: I think trusty worked out okayish with everyone being 3-5yrs, but some people clearly didn't understand how much work they were signing up for. :P
<stgraber> I had a couple of folks replying to my e-mail saying they'd be interested but are currently way too busy themselves (which isn't a great sign)
<stgraber> infinity: ah yeah, that's a good point. Maybe some folks don't want to maintain their stuff for 5 years anymore :)
<infinity> stgraber: Looks like that's all going to migrate, I'll watch an hour of TV and then trigger server before I crash.
<stgraber> infinity: yep, everything looks good
<pishuilu> infinity: Sorry, need to trouble you again. I upload ubuntukylin-default-settings package again.
<pishuilu> infinity: Are you still here?
<pishuilu> Hi everyone ,who can help me approving the upload of ubuntukylin-default-settings package? Thanks!
<pishuilu> Thanks!
<davmor2> cjwatson: I not it's not your realm anymore but you are the only person I can think of that might know. The EFI menu can it display info like the version of the distro so it isn't so black and uninformative
<davmor2> currently it just says the gnu grub version
<bdrung_work> hi, do i need a FFe for https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1560405 or can i just sync that bugfix release?
<ubot5> Launchpad bug 1560405 in ca-certificates-java (Ubuntu) "FFe: Sync ca-certificates-java 20160321 (main) from Debian unstable (main)" [High,New]
<cjwatson> davmor2: Maybe cyphermox can help you.
<davmor2> cjwatson: no worries he was going to be my next ping later on
<cyphermox> davmor2: an interesting question.
<davmor2> cyphermox: the reason I ask is if you have a bunch of install that menu give no indication of the version of ubuntu so it is the same from 14.04 through meaning you have to boot it so far to figure out if you have the right image
<rbasak> Skuggen: can I leave the powerpc FTBFS to between you and infinity to resolve please? I need to task switch.
<rbasak> Skuggen: are you happy for me to push infinity's other changes to Debian VCS?
<Skuggen> rbasak: I'm not sure how much I can be online this afternoon, since I'll be on the train for 6-7 hours, but I'll try to follow up on it
<Skuggen> The changes look fine for the Debian VCS, yeah
<cyphermox> davmor2: ok, so we'd need to come up with a simple graphical theme that replaces that version text with something else (like what's in .disk/info for instance)
<cyphermox> then we'd have the release name *and* which daily you're using
<flexiondotorg> cyphermox, I've found an RC issue in Ubuntu MATE. Working on it now. I will require a new package upload and iso rebuild
<flexiondotorg> Given the above, could you update ubuntu-mate-meta please, which include a trivial change.
<flexiondotorg> cyphermox, By RC, I mean Ubuntu MATE is uninstallable.
<cyphermox> ok
<flexiondotorg> The ubuntu-mate-meta update won't fix this issue. But does need doing at some point and now seem appropriate.
<cyphermox> well should it not wait until your fix lands?
<flexiondotorg> My fix will be in ubuntu-mate-welcome
<flexiondotorg> So please update ubuntu-mate-meta so that when new ubuntu-mate-welcome is uploaded everything is ready for an iso rebuild.
* Laney changed the topic of #ubuntu-release to: Released: Trusty 14.04.4, Wily 15.10 | Archive: beta freeze | Xenial Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<cyphermox> flexiondotorg: what change should I expect?
<flexiondotorg> cyphermox, uvcdynctrl is removed.
<cyphermox> ok
 * flexiondotorg thanks cyphermox while frantically knocking Welcome into shape.
<davmor2> cyphermox: nice so it is possible then, shall I write a bug up for it then?
<flexiondotorg> cyphermox, infinity Can you unblock mate-tweak, mate-dock-applet and mate-settings-daemon please?
<cyphermox> sorry, EACCESS
<flexiondotorg> cyphermox, What that comment for me? If so, I don't understand.
<cyphermox> I don't have permissions to do that ;)
<flexiondotorg> Ah.
<flexiondotorg> cyphermox, So if I've prepared a new ubuntu-mate-welcome, you can upload?
<flexiondotorg> cyphermox, If you're able - https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1560517
<ubot5> Launchpad bug 1560517 in ubuntu-mate-welcome (Ubuntu) "ubuntu-mate-welcome 16.04.6 released critical fix [dsc attached]" [Undecided,New]
<flexiondotorg> Laney, please can you unblock mate-tweak, mate-settings-daemon and mate-dock-applet?
<flexiondotorg> Laney, I've a release critical issue in ubuntu-mate-welcome, so need to rebuild anyway.
<flexiondotorg> Laney, infinity Ubuntu MATE is uninstallable. I've got a fix. Could one of you upload and unblock the update package please?
<Laney> flexiondotorg: In a minute
<flexiondotorg> Laney, Sure.
<Skuggen> infinity: We're working on a patch for the MySQL 5.7 build failure on powerpc
<Skuggen> Or rather we have a patch, but are testing it
<infinity> Skuggen: Oh, shiny.  Can I see?
<Skuggen> Right, sorry :D
<Skuggen> http://pastebin.ubuntu.com/15473221/
<ryeng> infinity: It still hasn't been reviewed, but testing is in progress. I'm not sure if I can find a powerpc to test on. At the moment I'm just forcing the use of __atomic on other platforms and running test on those.
<infinity> Skuggen: Shiny.  Only two comments: 1) __sync is deprecated, and you should be moving to prefer __atomic everywhere (once you've tested for regressions, etc), and 2) you'll need -latomic on some platforms (so need a 'MY_SEARCH_LIBS($symbol atomic LIBATOMIC)' at the top of configure.cmake.
<infinity> ryeng: Happy to build and review on a real machine.  And see above.
<Skuggen> For 1) I think it's just that since this is a bit of a rush-job with regards to review and testing it's a bit less risky to keep existing behavior when possibly
<ryeng> infinity: __atomic is too new to drop __sync. We need it to build on platforms with old GCCs.
<ryeng> infinity: But having both is an option.
<infinity> ryeng: Right, not suggesting you drop sync, just that you move to prefer atomic, once you've validated it.  Absolutely agree that validation doesn't happen in a day, and sticking with what you know is better for today.
<infinity> (That said, on newer GCCs, __sync is implemented using wrappers around __atomic anyway, so...)
<infinity> And highly recommended to switch to __atomic, since it gives you more control over memory ordering and such, which the __sync wrappers don't.
<ryeng> infinity: In future versions we'll switch to C++11 atomics.
<infinity> ryeng: \o/
<ryeng> infinity: The patch I've made now is based on a patch that did exactly as you suggested in 1). But the patch didn't make it into 5.7 before freeze ...
<ryeng> After that it was just dropped since __sync works and we didn't want to do that kind of fix after release without a good reason.
<infinity> ryeng: Right.  All sounds reasonable to me.
<jcastro> Hi! Our team needs help sorting out: https://bugs.launchpad.net/ubuntu/+source/charm-tools/+bug/1546776
<ubot5> Launchpad bug 1546776 in charm-tools (Ubuntu) "[FFe] charm-tools 2.0" [Undecided,New]
<wxl> any reason why lubuntu only has alternates for beta2?
<infinity> wxl: No idea.
<infinity> wxl: To be fair, desktop ones would be broken anyway, but lemme look.
<wxl> infinity: whatcha mean? ubiquity issues?
<infinity> wxl: *nd*
<infinity> nod, too.
<wxl> okie dokie.
<infinity> wxl: Generating a (broken) set anyway, so they don't get lost when it's time for a respin.
<wxl> infinity: thanks
<willcooke> hi release team.  I've just put a MP up for the slideshow (https://code.launchpad.net/~willcooke/ubiquity-slideshow-ubuntu/ubiquity-slideshow-ubuntu/+merge/289826) with updated screenshots and a slight change of text on one of the slides.
<willcooke> I'm emailing the translators mailing list right now
<willcooke> Can you tell me if I need a FFe for the updated slideshow?
<infinity> willcooke: Nope, slideshow is expected to land late.
<willcooke> thanks infinity
<willcooke> cyphermox, ^
<infinity> willcooke: In fact, we usually fix it ourselves when others fail to land it at all. :P
<willcooke> ha!
<willcooke> Hopefully this offsets all the other damage I've been doing ;)
<infinity> ;)
<cyphermox> willcooke: just being extra cautious, I'll merge it and upload now
<willcooke> cyphermox, would you double check it for me, just to be sure.  I /think/ I've got it all OK, but I was a bit worried about some of the sym links
<willcooke> I dont think I change anything, but ya know...
<cyphermox> yeah I was just checking...
<infinity> willcooke: There's a handy-dandy test script in the source.
<willcooke> also I noticed a lot of blurb was removed from the pot files
<willcooke> I used make pot and make test ubuntu :)
<willcooke> the test script is ace
<cyphermox> yay
<willcooke> oh
<willcooke> cyphermox, hold on a sec... I've just thought of something
 * infinity goes back to arguing with ubiquity.
<cyphermox> arguing?
<slangasek> I assume one argues with ubiquity by passing it different arguments on the commandline
<cyphermox> slangasek: do you prefer automatic or debug meat?
<slangasek> <blink>
<cyphermox> ubiquity can be automatic or debug
<slangasek> but "meat"?
<cyphermox> like chicken? white or dark meat?
<slangasek> you mean ubiquity isn't vegan!?
<infinity> I think it's cannibalistic.
<cyphermox> ubiquity definitely isn't vegan
<Skuggen> infinity: http://pastebin.ubuntu.com/15474163/ for your second comment. We don't have a box to test this on
<flexiondotorg> infinity, As rebuilds are going to happen anyway could you please unblock mate-tweak, mate-dock-applet and mate-settings-daemon?
<infinity> Skuggen: I can test sometime later.  A bit flat out right now.
<infinity> Skuggen: That's indeed what I had in mind.  I suspect that, with your other patch, should DTRT.
<infinity> Skuggen: (pointer to your other patch again?  I'm losing context rapidly)
<Skuggen> infinity: http://pastebin.ubuntu.com/15473221/
<infinity> Skuggen: Ta.
<infinity> Skuggen: I'll give them both a spin $later, when I'm not wrestling an installer.
<Skuggen> Sure thing, thanks :)
<Skuggen> We'll at least get some internal review on it, as well
<infinity> Skuggen: As written, it should be a 0-byte change to final binaries for arches with __sync.  Assuming all involved here can read and aren't missing something. :)
<Skuggen> I've been burned by that assumption before :D
<Skuggen> But yeah, it's not terribly complicated
<Logan> could someone please reject the plank syncs per the last comment in Bug 1558592?
<ubot5> bug 1558592 in plank (Ubuntu) "Sync plank 0.11.0-1 (universe) from Debian unstable (main)" [Wishlist,Fix committed] https://launchpad.net/bugs/1558592
<slangasek> Logan: it's suggested to hold it back; any reason not to let it sit in the unapproved queue for now?
<Logan> hmm, just in case someone approves it by accident, I guess
<slangasek> I mean, aside from the obvious risk of someone mis-accepting it, but I guess the risk depends on how long it'll take to fix bamf?
<Logan> right, that's true
<Logan> not sure what the timeline is for that
<infinity> Skuggen: Bah.  All went well on PPC until it got to storage/innobase also wanting __sync
<Skuggen> Gah
<infinity> Skuggen: The build (with link to log) for your amusement: https://launchpad.net/~adconrad/+archive/ubuntu/ppa/+build/9387908
<Skuggen> Guess we'll need a similar patch for innobase
<infinity> Skuggen: Looks like.  That's all new code, too.  I'd say something about new code using old prototypes, but I understand you have a company mandate to support people building your software on UNIXes all the way back to 1975. :P
<Skuggen> Yeah :)
<infinity> Skuggen: if it's any consolation, it looks like my stab-in-the-dark packaging fixes solved things for all the other arches.
<infinity> At least, none of them have failed yet. :P
<infinity> https://launchpad.net/~adconrad/+archive/ubuntu/ppa/+sourcepub/6224858/+listing-archive-extra
<Skuggen> infinity: I'm also seeing it used in the innodb_memcached plugin
<Skuggen> infinity: As far as I can see all the errors in that log
<Skuggen> Er, sorry. * can be traced to a single use of __sync
<infinity> Skuggen: Certainly, but then the build dies.  So hard to say where it goes when that one's fixed. ;)
<Skuggen> Yeah, storage/innobase/include/os0atomic.h has a bunch of __sync usage
<knome> infinity, i take it we're not going to see the base stuff for b2? :)
<infinity> knome: You might but it'll probably be shortly after. :/
<knome> infinity, it's ok; as long as we know what to expect. we're likely postponing the "official" base release until .1 so we can have a bit more time to test anyway
<infinity> knome: Well, it might Just Work.  Here's hoping.
<infinity> knome: But I'm obviously not going to penalise you for my lack of time.  If you want to release it with Final (if it's ready), let's do it.
<knome> likely not as it's this far away; we wanted this to be ready earlier because we want to make sure the quality is good, not because "we just want it" :)
<infinity> knome: Yup, understood.  Though, in theory, with the two base product just being cut down versions of their fatter brothers, it might not take much iteration.  We'll see.
<knome> at least in our case, it's not just "let's remove this and it's done", it's a bit more tweaking
<knome> but yeah, i understand what you are saying
<knome> you can tell that to our QA team though and see what they have to say ;)
<infinity> ;)
<infinity> QA people pretty much just shoot you for adding another product period, even if it's the same ISO renamed.
<infinity> Because exploding test matrices sucks.
<knome> sure, but they also do valuable work and it's sane that they require a certain amount of tests
<infinity> I need to go grab some $whatever_meal_this_is_maybe_breakfast_i_dunno while all my beta bugfixes build.
<knome> bon appetit!
<infinity> knome: I wasn't at all implying they're whining without cause.
<knome> :)
<Skuggen> infinity: We'll try to work out the innobase issues, hopefully make another patch :)
<infinity> Skuggen: My hero.
<infinity> Skuggen: The upshot of this is that moving to the new prototypes is the Right Thing to do anyway.  But no one likes being rushed on something like that either. :/
<Skuggen> Yeah, we (and by we I mean other people :P) are kind of patching this in the blind since we don't have the hardware to test on
<Ukikie> infinity: And right now, the current core images have a broken installer anyway. :P
<doko> why does golang-defaults (- to 2:1.6-1ubuntu3) show so many unsatisfiable Depends?
<slangasek> doko: main vs. universe
<slangasek> ?
<slangasek> yes - the existing golang binary is in main
<slangasek> this is xnox's recent change to make p-m respect component-mismatches, as announced on ubuntu-release
<doko> ohh, didn't hit reload
<doko> I'm not subscrubed to ubuntu-release
<doko> ok, promoting
<doko> hmm, subscribed by both server and foundations ...
<knome> doko, you should totally subscrub :P
<doko> slangasek, convince -server to subscribed?
<slangasek> doko: or I can just subscribe them?
<doko> sure, and I assume, we want foundations there too. golang-1.6, golang-defaults, and golang-1.6-race-detector-runtime
<slangasek> doko: done, for both teams
<doko> ta, promoted
#ubuntu-release 2016-03-23
<amjjawad> Hello infinity, how can we add the upgrade test cases to the tracker? http://iso.qa.ubuntu.com/qatracker/milestones/358/builds I don't think I have access to that kind of stuff ..
<infinity> amjjawad: Erm, honestly not sure.  I seem to always have someone else do it.
<infinity> stgraber: ^
<stgraber> infinity: they are manually added through the web UI
<stgraber> I can do it if you'd like
<stgraber> Admin -> Builds, tick as appropriate, put current timestamp as version and select milestone
<stgraber> added
<amjjawad> stgraber, many thanks :D thanks too infinity :D
<infinity> ^-- Best package name ever.
<slangasek> infinity: it's a paulwiseism
<tsimonq2> +1 infinity :D
<tsimonq2> !info check-all-the-things xenial-proposed
<ubot5> Package check-all-the-things does not exist in xenial-proposed
<tsimonq2> !info check-all-the-things
<ubot5> Package check-all-the-things does not exist in wily
<tsimonq2> huh, new package XD
<infinity> slangasek: Not surprising.
<nacc> it's an interesting package, for sure
<superm1> cyphermox: actually i'm wrong - mokutil 0.3 fixes this.  it uses efivar to create the variables which understands how to work with immutable variables
<superm1> that's the right way to fix it
<superm1> uploaded it and sitting in unapproved
<cyphermox> superm1: ok
<cyphermox> superm1: I can't approve stuff, I'm not old enough ;)
<superm1> heh
<cyphermox> (and also I'm busy cursing vistaprint and trying to finish wedding invites
<infinity> slangasek: You own mokutil in Debian, want to review that upload in the queue and confirm that it's the same orig you'll use so merges aren't a mess, etc?
<infinity> The actual code delta is fairly reasonable, once you filter out all the crap. :P
<superm1> there wasn't a watch file otherwise i would have used uscan to fetch it, so I just grabbed and renamed orig from https://github.com/lcp/mokutil/releases
<infinity> superm1: Yeahp, I'm sure that's fine, but since the Debian maintainer happens to be a member of the Ubuntu release team, I figured I'd let him do the honors. :)
<cyphermox> superm1: can we copypasta the mokutil magic so that fwupdate is happy too?
<superm1> cyphermox: i made fwupdate happy with some changes to it's install script
<cyphermox> oh, awesome, thanks
<superm1> sure
<infinity> tyhicks: Seriously?  *sigh*
<Skuggen> infinity: Patch for innobase and innodb_memcached
<Skuggen> http://paste.ubuntu.com/15477836/
<infinity> Skuggen: Lovely.  I'll use this to stress-test a PPC machine I just set up.
<tjaalton> oh f...
<tjaalton> could someone drop freeipa from the queue?
<tjaalton> was meant for a ppa :P
<infinity> tjaalton: It's kinda already accepted and built.
<tjaalton> but in new?
<tjaalton> and proposed
<infinity> Yeah, I can delete it from proposed.
<tjaalton> cool
<tjaalton> thx
<infinity> Skuggen: You win.
<infinity> Skuggen: If you want a log to pass back to folks, http://lucifer.0c3.net/~adconrad/mysql-powerpc.log
<infinity> Skuggen: I'll upload all of this to the archive shortly.
<Skuggen> Whooo
<infinity> Skuggen: Thanks for the quick turnaround.
<Skuggen> No problem. I'll pass it on :)
<Skuggen> I know we have some tests failing on platforms we don't normally test as well, but not entirely sure if those tests are in the main suite, so will wait for the results of it.
<infinity> Skuggen: Whatever testsuite is run at build time succeeded on all 7 arches.
<Skuggen> Hm, for some of the tests I know it's because some floating point calculations return slightly different results, so maybe those tests won't be run.
<infinity> Skuggen: ibm-long-double arches (ppc* and s390*) definitely give slightly different fastfp results from the rest of the world.
<infinity> Skuggen: But both passed here, so you must not be testing that at build time. :P
<infinity> Skuggen: http://launchpadlibrarian.net/249671602/mysql-5.7_5.7.11-0ubuntu1_5.7.11-0ubuntu2.diff.gz
<Skuggen> I don't think dep8 will run any more tests than what's run at build time. Though I have some input on making the test runs faster, in which case we could make it run more tests :)
<infinity> Skuggen: There's the final packaging diff, if you wanted to import that into your git tree.
<Skuggen> Thanks
<infinity> Skuggen: IMO, the ideal situation is for the build-time tests to be as complete as possible, and the dep-8 tests to just touch enough important bits to know it didn't explode (ie: try each backend driver, try the client tools, dump/load a DB, call it good)
<infinity> Skuggen: Since dep-8 is about making sure other deps don't break you at runtime, it's a) not really where deep unit testing belongs and b) run frequently, so 4h test runs suck.
<Skuggen> Yeah, true
<Skuggen> We tend to see failures there we don't see at build time, but in those cases it's usually a problem with the test, and not the package itself :)
<Skuggen> e.g. tests trying to write files in weird places
<Skuggen> Seems dep8 runs the same suite as build time
<infinity> Yeah, that's common, but not necessarily ideal. :)
<Skuggen> But that suite is fairly limited right now. I think it was cut back some time ago to reduce build time
<Skuggen> But if we can make it faster we could expand testing during builds
<infinity> I don't mind long builds, really.
<infinity> Not when there's a good reason, anyway.
<infinity> darkxst: Oops, I triggered a world rebuild right before I noticed you'd just done GNOME.  You'll get another one shortly. :P
<darkxst> infinity, ha ok, guess it will be the same atleast!
<darkxst> infinity, my respin (that you just trumped) is winning btw, so hopefully everything is good now, although of course something else will pop up
<flexiondotorg> cjwatson, I noticed something very strage with the archive.
<flexiondotorg> cjwatson, Yesterday I had some packages synced, one of them was mate-tweak 3.5.8.
<flexiondotorg> cjwatson, I saw is sitting in universe proposed.
<flexiondotorg> cjwatson, This morning mate-tweak 3.5.8 is no longer listed for proposed and only 3.5.7 is listed for xenial.
<flexiondotorg> I see the same behaviour with mate-dock-applet and mate-settings-daemon.
<cjwatson> flexiondotorg: How curious, seems to have lost the copies.  I'll dig.
<flexiondotorg> ty
<cjwatson> NotOneError in BinaryPackageBuildSet.getBySourceAndLocation, how, er, exciting :-/
<cjwatson> Which is indeed borne out by https://launchpad.net/ubuntu/+source/mate-tweak/3.5.8-1
<cjwatson> And those are the three packages where I noticed duplicate announcements to xenial-changes yesterday
<cjwatson> I reckon these were each synced by you and by barry, and perhaps accepted simultaneously or something
<flexiondotorg> cjwatson, I have no repository super powers.
<Laney> I accepted those
<Laney> using queue accept
<Laney> which probably would have accepted both queue entries
<cjwatson> flexiondotorg: syncing doesn't require superpowers, only upload permissions
<cjwatson> flexiondotorg: anyway I'm not saying it was your fault, I'm just trying to work out the exact history
<flexiondotorg> cjwatson, I don't have any of those either.
<cjwatson> flexiondotorg: Ah, Mirv sponsored it for you
<flexiondotorg> Yeah, I know you're not point the finger at me :-(
<flexiondotorg> Opps :-)
<flexiondotorg> I'm just explaining I didn't upload anything :-)
<doko> gcc-defaults-ports (1.149ubuntu2 to 1.150ubuntu1)
<doko> Maintainer: Debian GCC Maintainers
<doko> Section: universe/misc
<doko> 0 days old
<doko> Impossible dependency: gcc-defaults-ports -> gcc-5-cross-ports/amd64
<doko> Impossible dependency: gcc-defaults-ports -> gcc-5-cross-ports/i386
<doko> Depends: gcc-defaults-ports gcc-5-cross-ports
<doko> Valid candidate
<doko> this looks odd. it references gcc-5-cross-ports, but that is not part in update_excuses
<cjwatson> flexiondotorg: https://bugs.launchpad.net/launchpad/+bug/1560889 - I'm uploading rebuilds to work around this now, since that's by far the simplest option
<ubot5> Launchpad bug 1560889 in Launchpad itself "Accepting multiple identical syncs from unapproved creates SPR with duplicate BPBs" [Critical,Triaged]
<flexiondotorg> cjwatson, Thanks.
<flexiondotorg> cjwatson, I have an RC issue as well :-(
<flexiondotorg> cjwatson, Could you sponsor an upload for me please?
<cjwatson> flexiondotorg: no, sorry, need to go back to LP work
<flexiondotorg> cjwatson, OK.
<cjwatson> should be somebody else around who can
<cjwatson> (I mean, all the above is LP work, but YKWIM)
<flexiondotorg> Laney, I have an RC issue with Beta 2 image for Ubuntu MATE. Could sponsor and upload for me please?
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1560517
<ubot5> Launchpad bug 1560517 in ubuntu-mate-welcome (Ubuntu) "ubuntu-mate-welcome 16.04.6 released critical fix [dsc attached]" [Undecided,New]
<cjwatson> Laney: ^- penance for you
<Laney> k. ta
<Mirv> flexiondotorg: I managed to get your packages to explore corner cases of LP!
<flexiondotorg> Mirv, hah!
<flexiondotorg> cjwatson, Thanks for your help.
<bluesabre> good morning! would it be possible to release the above to the archive? fixes a FTBFS and gets our documentation to a final beta release ready state
<bluesabre> (xubuntu-docs)
<flexiondotorg> Ubuntu MATE needs some help please. We have complete uninstallable images.
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1560517
<ubot5> Launchpad bug 1560517 in ubuntu-mate-welcome (Ubuntu) "ubuntu-mate-welcome 16.04.6 released critical fix [dsc attached]" [Undecided,New]
<flexiondotorg> I'm testing upgrades right now.
<flexiondotorg> Laney, thanks for the help!
<LocutusOfBorg> mapreri, ^^^
<mapreri> LocutusOfBorg: cool
<LocutusOfBorg> not sure why the syncs goes in unapproved, but well, somebody is accepting fast :D
<mapreri> LocutusOfBorg: that was indeed weird, since the package is not seeded anywhere
<cjwatson> LocutusOfBorg: unapproved> because xenial is frozen
<cjwatson> that just lands everything in unapproved; the "not seeded" etc. logic is implemented by the auto-accept bot
<cjwatson> so that's also why you see "somebody" (a robot) accepting things quickly
<cjwatson> at least in some cases
<LocutusOfBorg> thanks
<LocutusOfBorg> :)
<flexiondotorg> cjwatson, Roughly how long will is take for accepted packages to transition from proposed to universe?
<cjwatson> flexiondotorg: category error.  proposed and universe are different axes
<mapreri> is this a good day to poke for a couple of RM?
<mapreri> #1556226 & #1556229
<cjwatson> flexiondotorg: if you mean proposed to release, I can't answer that, too many variables.  if nothing at all blocks them then probably an hour or two end to end, but it depends on lots of stuff
<flexiondotorg> cjwatson, Good enough for me. Thanks :-)
<flexiondotorg> Just working out when I maybe able to rebuild.
<davmor2> cyphermox, willcooke: so there might be issues with oem mode not completing enduser setup and the slide show for the enduser setup will look at it on hardware after to confirm though E:JUGGLINGTOOMANYBALLSTODAY
<davmor2> cyphermox: two for you https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1560940 and http://launchpad.net/bugs/1546317
<ubot5> Launchpad bug 1560940 in ubiquity (Ubuntu) "None matching mokutils passwords" [Undecided,New]
<ubot5> Launchpad bug 1546317 in ubuntu-mate "Accessibility indicator is missing from ubiquity-dm at the "Try Ubuntu" dialog" [High,Confirmed]
<superm1> davmor2: bug 1569040 may actually be resolved with the fix for bug 1560764
<ubot5> Error: Launchpad bug 1569040 could not be found
<ubot5> bug 1560764 in linux (Ubuntu) ""fails to request state" when trying to perform actions in mokutil" [Undecided,Confirmed] https://launchpad.net/bugs/1560764
<superm1> We discovered some kernel behavior change on immutable variables that make mokutil unable to write variables properly
<davmor2> superm1: could be then we'll see when things are fixed there if it fixes this too then
<superm1> Not sure which point the variable is written in Python though, so that might be a second issue :)
<apw> superm1, reading that bug you seem to be changing the way mokutils works to cope with the change; so there is nothing to do there /
<apw> superm1, kernel side ?  correct ?
<superm1> apw: yes shouldn't have to do anything kernel side unless mokutil 0.3 isn't accepted for xenial
<apw> superm1, heh well changing the kernel takes 2 days, so we'll not be doing that in time i suspect
<apw> superm1, anyhow, who is making the decision on that
<superm1> apw:  (per discussion with infinity last night) waiting on slangasek as he's Debian maintainer for mokutil
<apw> superm1, ack thanks, just in case we do have to do something
<superm1> Yeah that's why left a Linux task on so you are in the loop
<davmor2> slangasek: damn it I was close
<slangasek> superm1: could do with updating the text of the openssl exception in debian/copyright now that it's published upstream, but otherwise, looks good.  infinity accepting mokutil now
<balloons> infinity, are you aware of the new juju2 package trying to land in xenial?
<balloons> I wanted to make you aware and see if you had any questions / concerns
<slangasek> infinity: fyi, working through bug #1556241 now with mvo and cyphermox; this may only be affecting netboot installs today (because the seeded package is not yet in main therefore possibly only installed when doing a netboot install) and not require image respins, but I know that the ubuntu-snappy MIR is supposed to be getting finished this week...
<ubot5> bug 1556241 in ubuntu-snappy (Ubuntu) "installer sets "iface encf5f0 inet dhcp" although a static IP address was preseeded" [Critical,Triaged] https://launchpad.net/bugs/1556241
<coreycb> hello, can a release team member review the python-oslo.* and python-*client openstack dependency packages in the xenial review queue?
<coreycb> infinity, ^
<pitti> cyphermox: hey Mathieu, how are you?
<pitti> are there some beta critical things you need a hand with? I'll have about another hour today (not feeling too well), so if you have something reasonably small
<cyphermox> pitti: hey, I'm alright
<cyphermox> you?
<cyphermox> there's nothing that small
<cyphermox> the most critical thing that needs help is upgrades, I think
<pitti> cyphermox: ok, got some fever/infection since yesterday, going a bit slow; but I hope I'll be fully back tmw
<cyphermox> pitti: no worries, get well soon!
<pitti> cyphermox: any particular upgrade bugs to look into? these usually can still be looked into after the actual release
<cyphermox> pitti: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1555237
<ubot5> Launchpad bug 1555237 in ubuntu-release-upgrader (Ubuntu) "Upgrade from 14.04.4â 16.04 dies midway taking out the session." [Critical,In progress]
<flexiondotorg> Laney, cjwatson ubuntu-mate-welcome (and others) haven't been promoted to release yet. Am I being impatient or is their a problem with the package?
<flexiondotorg> *there
<cjwatson> needs manual unfreezing by a member of the release team
<cjwatson> you can see this on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-mate-welcome
<cjwatson> (I did say the timing depended on a lot of things ...)
<flexiondotorg> Laney, please can yu unfreeze ubuntu-mate-welcome, mate-tweak, mate-dock-applet, eom and pluma please.
<flexiondotorg> cjwatson, Yes, you did. I've used my time to do some testing for Ubuntu proper :-)
<flexiondotorg> Laney, and mate-settings-daemon
<cjwatson> (you don't want mate-settings-daemon too?)
<cjwatson> aha
<Laney> flexiondotorg: can you give me it in this format: unblock package1/version1 package2/version2 ... please?
 * Laney has a crisis and can't remember if that works with multiple packages per hint
<flexiondotorg> Laney, Wilco. One sec.
<flexiondotorg> Laney, unblock ubuntu-mate-welcome/16.04.6
<flexiondotorg> Laney, unblock mate-tweak/3.5.8-1build1
<flexiondotorg> Laney, unblock mate-dock-applet/0.70-1build1
<flexiondotorg> Laney, unblock mate-settings-daemon/1.12.1-2build1
<flexiondotorg> Laney, unblock  eom/1.12.2-2
<flexiondotorg> Laney, unblock pluma/1.12.2-2
<flexiondotorg> Laney, and thanks for helping.
<Laney> thx
<Laney> next time maybe pastebin would be easier for me to put in place :-)
<flexiondotorg> Laney, will do.
<Laney> pushed
<flexiondotorg> cjwatson, So are any packages automatically unfrozen right now?
<flexiondotorg> Laney, ty
<Laney> the block is for packages that are participating in this beta
<Laney> Things that get through it should be more or less the same as the ones that get auto accepted
<cjwatson> multiple packages per hint should work fine
<Laney> I didn't do it, out of fear of crashing britney :)
<Laney> there's only single-package hints in place currently
<slangasek> hmm, boost binary rejects?
<doko> slangasek, was me. mpi not building mpi
<cyphermox> jgrimm: rharper: slangasek: infinity: release team: I'm sponsoring rharper's multipath-tools merge; it may be nice to land in beta if the server images are otherwise respun.
<infinity> slangasek: Eek.  It was snappy writing that interfaces snippet?  Whee.
<AlbertA> Could somebody approve mir 0.20.3+16.04.20160322-0ubuntu1 ?
<slangasek> that is a question
<slangasek> infinity: ^^ fwiw I was just discussing this with kgunn.  It sounds like we do want to continue landing mir into xenial post-beta, but of course the lib is in all the images.  How do you want to play this?
<infinity> slangasek: I'd prefer to wait until after the beta so we don't keep respinning, unless there's a legitimately urgent reason it can't be tested from -proposed.
<infinity> slangasek: We can accept it, though, it should be blocked from migration.
<kgunn> thanks guys
<slangasek> infinity: I think the main issue is that the train treats a silo as not "landed" until it's in xenial (not xenial-proposed), which blocks further development.  A one day delay seems ok here, but is there a reason not to let it into xenial if we aren't explicitly respinning for it?
<slangasek> i.e. let it in xenial, let it get picked up or not with any subsequent respins
<infinity> slangasek: Well, it would make the source ISOs not match, but that's probably not the end of the world.
<balloons> infinity, can we talk about accepting juju2?
<lamont> infinity: plan is to upload some postfix love "sometime this week"... guessing you'd prefer that be "after beta ships", true?
<infinity> lamont: You can upload whenever, it just might stick in the queue for a day.
<infinity> balloons: We can talk about it.
<lamont> infinity: kewl
<ypwong> Laney, hi
<davmor2> infinity: just remember the answer is no, you give in to balloons once and he'll never stop ;)
<wxl> ooh did the d-i/ubiquity issues get fixed?
<teward> wxl: you mean with the keyboard selection?  or a different issue?
<teward> (there's several I'm aware of now)
<wxl> teward: well, any of the above :)
<infinity> wxl: The not starting one was fixed.
<teward> E: Ambiguous
<infinity> teward: What's the keyboard one?
<wxl> yay
<teward> infinity: cyphermox was going to look at it
<infinity> Kay.
<teward> let me grab the bugs again
<infinity> teward: d-i, ubiquity, or both?
<teward> infinity: different bugs on each, but similar issue on both
<teward> https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1559507
<ubot5> Launchpad bug 1559507 in debian-installer (Ubuntu) "Keyboard selection is missed" [High,Confirmed]
<teward> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1549529
<ubot5> Launchpad bug 1549529 in ubiquity (Ubuntu) "The keyboard is still installed as US-English even if another language is selected during the installation" [Undecided,Confirmed]
<teward> d-i one was discovered by phillw on the lubuntu alt images, confirmed by me on server, and forwarded to matsubara for the d-i stuff bevcause we can't complete test cases for server
<cyphermox> yeah, I'm going to look at console-setup; first try to reproduce this in d-i
<teward> (steps require us to manually selevct keyboard layout)
<infinity> teward: I just did a French ubiquity install, and got a horrible azerty keyboard out of it, so the second one seems to be fixed.
<flexiondotorg> Laney, cjwatson Thanks for you help today. The new Ubuntu MATE image appears to be working :-)
<infinity> cyphermox: This might have been fallout from locales merge stuff, since we leverage locales to guess keyboards.  The ubiquity bug certainly seems unreproducible here.
<cyphermox> right, but it still should be checked
<teward> infinity: egads, ouch.  I can't attest to the ubiquity GUI one; i can only attest to what i've confirmed - which is the server/lubuntu-alternate d-i stuff
<wxl> so there's a possibility that the keyboard issues affecting both d-i and ubiquity are related?
<infinity> Oh, but this bug was reported long before I changed the world.  Hrm.
<teward> infinity: at least since the 19th it's been an issue, and i saw it on the ISOs on the 21st, for the d-i item
<infinity> Right, okay, so not my issue, though my issue may have compounded it briefly.
<cyphermox> infinity: I agree ubiquity does what it should, testing d-i now
<infinity> cyphermox: Note that the ubiquity bug seems deeply concerned specifically with Swedish keyboards, maybe that's extra broken somehow.
<cyphermox> (well, anyway, various French keyboards work, and so does the hebrew one
<infinity> (or maybe it relates to which langpacks are and aren't preinstalled)
<Laney> Blame Gunnar
<cyphermox> dah
<cyphermox> Swedish was always a bit of an issue
<infinity> Agreed, but they make good meatballs.
<cyphermox> admittedly, I didn't try that one
<cyphermox> the keyboard, not the meatballs
<cyphermox> good thing I'm so good at languages I can't read
<cyphermox> oh
<cyphermox> is Svenska Swedish?
<infinity> Thankfully, driving ubiquity doesn't really require reading.
<infinity> Svenska is Swedish, yes.
<cyphermox> it's some sort of casper issue I think
<cyphermox> at least for ubiquity
<cyphermox> If i pick Svenska at gfxboot, I will be able to continue with the install with no issues
<infinity> cyphermox: If you pick it at gfxboot, casper creates the locale in the target before booting.
<cyphermox> yes
<cyphermox> and if you boot EFI, that won't happen
<infinity> cyphermox: If you don't, then I assume something else is meant to be responsible later.
<cyphermox> right
<infinity> That "something else" would be d-i/ubiquity, no?
<cyphermox> the key is in a message that pops up in Swedish, about XKBLAYOUT or something
<cyphermox> yeah
<cyphermox> console-setup isn't quite doing what it should
<cyphermox> still, I reassigned the ubiquity bug to casper, and will try on d-i now, and if both behave the same I'll make it all console-setup
<teward> cyphermox: note the observed d-i issue is if you skip auto detection, you end up with no ability to select anything - it just skips and goes onto the next step
<teward> fine if you are US/English format, poor if you're not.
<teward> and matsubara confirmed the issue exists, so it tends to be something of a very evil thing, in my (tiny) opinion
<infinity> No disagreement on the evil.  Might be post-beta evil, though, if the fix isn't immediately obvious.
<teward> infinity: indeed.  though, if not fixed in beta, it should definitely be fixed before final
<teward> otherwise we're going to have some very large complaints
<infinity> Quite.
<cyphermox> teward: I'm not worried about this kind of thing getting fixed
<teward> neither am I, just an observation :)
<cyphermox> oh look, console-setup is really borked
<cyphermox> (crap, that's really my fault too)
<cyphermox> but it's probably on console-setup that is broken and evil
<cyphermox> *only
<infinity> Well, that's something.
<cyphermox> indeed, it hasn't changed much since wily
<cyphermox> maybe it isn't console-setup after all
<barry> doko, release team.  what should we do about setuptools?  i guess first is to get dep8's passing.  can/should we unfreeze that once we do?
<barry> pex 1.1.4-1 should pass, so that's just python-pbh5tools and pbgenomicconsesnsus amd64
<doko> barry, what should be done?
<barry> doko: oh, i just mean unblock it: Not touching package due to block request by freeze (contact #ubuntu-release if update is needed)
<doko> barry, can't do that, I'm not in the release team
<barry> doko: i just pinged you because you uploaded the new version.  presumably we want 20.3.1-1 in xenial, right?
<doko> yes, wanted to have a recent version
<barry> doko: excellent.  i'll take a look at dep8 failures
<doko> slangasek, infinity: didn't get any reply on my gcc-defaults-ports issue (update_excuses). Depends: gcc-defaults-ports gcc-5-cross-ports, but gcc-5-cross-ports doesn't show up in update_excuses
<flexiondotorg> cyphermox, Hi
<flexiondotorg> I've been testing Ubuntu and Ubuntu MATE.
<flexiondotorg> Just about to create a new bug, oem-config doesn't complete.
<cyphermox> ok
<flexiondotorg> After the system is prepared, the user setup runs, at the end of user setup the desktop is not started. Just a black screen.
<flexiondotorg> Same results on Ubuntu and Ubuntu MATE.
<flexiondotorg> Also a11y indicator is missing from all installs.
<flexiondotorg> And the is not network on oem-config user setup.
<flexiondotorg> *there is no network
<superm1> flexiondotorg: possibly this: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1552621 ?
<ubot5> Launchpad bug 1552621 in ubiquity (Ubuntu) "Can't login to desktop autometically after oem-config is finished on OEM mode" [Undecided,Confirmed]
<flexiondotorg> superm1, Thanks. That is exactly the issue.
<slangasek> doko: gcc-defaults-ports - the dangling reference to gcc-5-cross-ports appears to be a britney bug, but the real problem is the error message above it, which I've never seen before.  Do these packages have cross-arch dependencies?
#ubuntu-release 2016-03-24
<stgraber> infinity: could you approve my lxc upload? it would make testing an upcoming lxd change easier for some of my users (they could pull it from proposed directly and we could run adt tests easily)
<infinity> stgraber: Looking.
<stgraber> it's a tiny change to fix broken bash completion but it also happens to free the "lxc" bash completion filename which lxd then must use itself, so our new lxd packages are effectively blocked on that tiny change right now :)
<stgraber> not completely sure why bash-completion behaves so differently between /etc and /usr/share but well
<infinity> https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/1538615 is a wild ride.
<ubot5> Launchpad bug 1538615 in unity-greeter (Ubuntu Trusty) "Cat causes login screen to hang" [Medium,Triaged]
<stgraber> thanks
<bluesabre> infinity: since you just so happen to be around, would you mind releasing https://launchpad.net/ubuntu/+source/xubuntu-docs/16.04.3 from -proposed?
<bluesabre> (pretty please) :)
<infinity> bluesabre: That would mean a respin of xubuntu and studio images, and we release tomorrow.  Is it urgently needed in the images?
<bluesabre> infinity: its not urgent, just a nice-to-have. At the same time, I do suppose our QA lead is currently asleep, so maybe I'll hold off until flocculant appears again
<infinity> bluesabre: Yeah, given that I'd like to release in just over half a day, I think I'd want approval from both Xubuntu/Studio to muck with their images.  Or, if another critical "breaks the world" bug needs to be fixed, I'll slip it in.
<infinity> bluesabre: Otherwise, it can wait a day. :)
<bluesabre> yup, and I can't speak for studio :)
<bluesabre> thanks!
<dax> infinity: is that a dup of https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1463112 ?
<ubot5> Launchpad bug 1463112 in unity (Ubuntu) "Cat sitting on keyboard crashes lightdm" [Medium,Confirmed]
<infinity> dax: Probably.
<dax> aww. the naming conflict between cat the shell thing and cat the little furry demons means that finding more dupes is less funny than expected
<infinity> Quite.
<infinity> I think I also once reported that the Unity lock screen wasn't cat-friendly.
<infinity> Though, I don't recall what my complaint was.
<infinity> Oh, I remember.  The first incarnation of the lock screen would wake up on keypress and if there was any input in the password field, would never go back to sleep.
<infinity> So a cat walking across the keyboard once would keep your monitor on all night.
<infinity> superm1: We seem to have no mythbuntu tests for Beta2.
<stokachu> damnit, can someone please cancel that openstack package out, was supposed to be xenial
<slangasek> why do so many packages seem to have problems with termios on powerpc+ppc64el only?
<slangasek> ah, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810907 explains
<ubot5> Debian bug 810907 in src:repsnapper "repsnapper: FTBFS on ppc64el: termios problems" [Serious,Open]
<slangasek> I wonder if that's a linux-libc-dev bug
<ypwong> Could someone from release team comment on https://bugs.launchpad.net/ubuntu/+bug/1546967 ?
<ubot5> Launchpad bug 1546967 in Linux Backports "[FFe] [needs-packaging] linux backports and related meta packages" [High,New]
<doko> slangasek, they should not have any cross-arch deps
 * apw reviews bug #1546967 with his kernel hat on
<ubot5> bug 1546967 in Linux Backports "[FFe] [needs-packaging] linux backports and related meta packages" [High,New] https://launchpad.net/bugs/1546967
<xnox> infinity, s390x all good, i am expecting that d-i and server iso and cloud images are going to be released.
<xnox> tested on all virtualisation modes
<ypwong> apw, if we change the version number to match ABI number, i think it suffice to just use x.x.x.y and no need to use x.x.x.y.z, right?
<ypwong> rationale is, if kernel updates from, let's say, 4.4.0-15.31 to 4.4.0-15.32, there should be no need to rebuild lbm
<apw> ypwong, well if you make it match it will be less confusing, you indeed do not need to rebuild unless x.x.x.y changes of course
<apw> ypwong, that said, we are not producing non-abi bumper kernels except in the case where they do not make it to -proposed (pretty much) so you will always have an abi bump
<apw> ypwong, so it _will_ change in the normal course every single kernel
<ypwong> apw, ok
<darkxst> this list seems somewhat incomplete http://iso.qa.ubuntu.com/qatracker/reports/defects
<darkxst> only 2 of the bugs reported against ubuntu GNOME images are listed there
<sil2100> Hello! For those that might be affected: I'll be disabling the system-image importer frequently in the nearest few hours as we're doing some rebuilds in the touch world
<rcj> infinity, cloud images are ready
<phid> apw: hi, we've made some changes for LBM according to your suggestions. The temporary development ppa can be found here: https://launchpad.net/~linux-backports-team/+archive/ubuntu/develope
<apw> phid, will have a look, the version number being a . not a - for the abi seems odd
<phid> apw: that's because it's native package now, from what I know linux-signed-generic uses same versioning rule
<apw> linux-signed (4.4.0-8.23) xenial; urgency=medium
 * davmor2 has a bone to pick with cyphermox and then slap him round the room with, additional drivers, I installed intel microcode and nvidia binary on a real machine no mokutils password request
<cyphermox> maybe you didn't have secureboot enabled?
<apw> not sure why intel microcode would need secure boot interactions, that is added to the initramfs and is signed by intel and validated by the cpu
<apw> and why would an nvidia driver matter for secureboot at the mok level
<ypwong> apw, we also looked at linux-generic/linux-signed-generic/linux-meta and their versions are like 4.2.0.34.37
<apw> if the kernel was enforcing correctly it would reject a vile binary driver after you installed it but the act of installing it has no interwction with mok does it
<apw> ypwong, yes meta is numbered differntly to signed
<davmor2> cyphermox: paste.ubuntu.com/15487077
<apw> thouhg that is as much legacy as anything else
<davmor2> cyphermox: also it triggered installing fwts from terminal
<davmor2> cyphermox: so it looks like it is just additional drivers
<davmor2> cyphermox: however it might be related to the control system not working if it triggers the window from there maybe
<ypwong> apw, ok, we will keep meta packages to use x.x.x.y.z and the packages that contain ko to use x.x.x-y.z
<apw> ypwong, yeah that is a confusing delta in our package, i am struggling to know why it matters
<apw> i guess it is as simple as native or not, hrm
<ypwong> yeah that was confusing at first so we used another versioning scheme
<apw> ypwong, i think in this case becuase your lbm modules are tied exactly to our binary version numbers, that matching exactly is good for keeping users from being confused
<apw> however stupid out names are :)
<doko> hmm, the re-run alias using snakefruit doesn't seem to work forme ... https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Re-running_tests
<superm1> apw: how does the kernel decide if it's behaving in enforcing mode for preventing unsigned kernel modules?
<apw> superm1, right now it does not, it will based on the mok settings
<superm1> apw: oh okay, that explains why it's worked so far with current xenial kernel still
<apw> superm1, right
<apw> we're working on that problem at the moment
<superm1> apw: do you have a WIP patch for this somewhere?
<apw> superm1, i do not, rtg is looking after that one
<superm1> rtg: anything you can share about it?
<ypwong> apw, packages using versions that match kernel are now in ppa
<infinity> superm1: *poke, poke*
<infinity> superm1: Still no myth testing on the tracker.
<stokachu> infinity: get my email? :)
<stokachu> i know you love us
<superm1> infinity: it's been happening (which is why there were 2 packages uploaded a little bit ago)
<superm1> found some odd stuff missing that caused interesting installation failures
<superm1> if you could accept those 2 in (mythtv, mythbuntu-meta) and respin i'll ask testers to retest with that and make sure to file some reusults
<stokachu> apw mind rejecting bigdata 1.0.0 now that 1.0.1 is there
<infinity> superm1: Kay.  Can do.  But hurry, release is today. :P
<superm1> infinity: kk :)
<superm1> what time is cutoff?
<infinity> superm1: My afternoonish/eveningish sometime.
<infinity> superm1: No hard time, other than I'd like to be done before 8pm Mountain.
<superm1> infinity: OK
<flexiondotorg> infinity, So that is 02:00 UTC right?
<apw> stokachu, if the previous one wasn't accepted you can reuse the version numbers ...
<stokachu> apw: ah ok didnt realize that
<infinity> flexiondotorg: Yeah, but I'm hoping we're done long before that.  That's just my "screw you all, I have plans this evening" cutoff. :P
<apw> stokachu, and rejected
<stokachu> thanks
<flexiondotorg> infinity, Sounds fair :-)
<davmor2> moves to release
<willcooke> davmor2, so your testing shows 5 critical bugs?
<davmor2> willcooke: well not just mine but yes
<willcooke> this page?  http://iso.qa.ubuntu.com/qatracker/milestones/358/builds/115348/testcases
<davmor2> yeap
<infinity> So, the accessibility thing sucks, but I'm not sure it's beta-critical.
<infinity> (obviously RC for final)
<davmor2> willcooke: that accessibility menu missing is a big one, the can't format swap issue is the next, the mokutils one I think is now understood but needs modifying,
<infinity> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1560973 looks a bit scary.
<ubot5> Launchpad bug 1560973 in grub2 (Ubuntu) "EFI booting Ubuntu image to grub removes existing boot entries and makes system unbootable" [Undecided,Confirmed]
<davmor2> infinity: tell that to the blind guy trying to install it, final beta is when people start to install and upgrade the two things you can't do right now
<infinity> Given we claim betas are "reasonably free from showstoppers".
<infinity> davmor2: I don't disagree that it sucks a lot.
<infinity> What I need to know is how deeply these bugs have been investigated, are there fixes in the queue, can we fix them quickly, will I have to push back beta by a day and swap a holiday?
<Laney> cyphermox reckoned that one was XP
<Laney> S 13 specific, maybe
<Laney> someone with different hardware could confirm that
<infinity> cyphermox: You have context on any of these bugs and care to enlighten me? :P
<davmor2> Laney: no it happens in kvm too
<Laney> write that on the bug please
<willcooke> The a11y one, TheMuso is aware and has a plan to fix, but he says it wont be ready before beta.
<willcooke> I agree its bad
<infinity> I agree it's bad too, but people could have tested a bit earlier to discover the badness.  Anyhow, I see some uploads in the queue from him.  I'd rather not respin the world to include those, especially if they're not complete yet.
<infinity> But if we must respin for other bits, we can try those bits too.
<davmor2> Laney, infinity: sorry I thought I did with the whole fedora explanation, the issue is that all the ubuntu install paths for uefi is landing on the same file names and same path the only change is the newer version of grub2 lists both version of ubuntu
<infinity> Sadly, most of these bug fixes will force a respin on all the flavours who've been marking their images ready over the last 24h. :P
 * knome grins
<willcooke> Laney, will you get a chance to look at this today:  https://bugs.launchpad.net/ubuntu/+source/unity-control-center/+bug/1546388
<ubot5> Launchpad bug 1546388 in unity-control-center (Ubuntu) "unity-control-center crashed with SIGSEGV in _cogl_check_extension()" [Medium,Confirmed]
<infinity> willcooke: Can I get you and slangasek to maybe triage these criticals together, and get managerial about throwing out assignments, and we can then examine the fallout and determine a plan forward for beta and post-beta?
<Laney> willcooke: It doesn't crash for me. I told $whoever earlier that they should talk to tjaalton.
<davmor2> I think the solution would be to have a the efi entry for shim.efi etc to be time stamped at install time and then that would make them unique
<willcooke> Laney,  oh, sorry, wrong link... https://bugs.launchpad.net/ubuntu/+source/libunity/+bug/1538471
<ubot5> Launchpad bug 1538471 in libunity (Ubuntu) "scope-runner-dbus.py assert failure: *** Error in `/usr/bin/python3': free(): invalid next size (fast): 0x0000000001ca17b0 ***" [Critical,Confirmed]
<willcooke> infinity, yeah, good plan.
<davmor2> Laney: me it works fine on my laptop here but on the installed hardware it breaks, I thought you were talking to the other guy who had gfx issues when you said that
<slangasek> infinity: where is the list of criticals?
<infinity> slangasek: http://iso.qa.ubuntu.com/qatracker/milestones/358/builds -- red bugs on Ubuntu Desktop amd64.
<infinity> willcooke: If there are others on your list not represented by those little red bugs, speak up.
<slangasek> infinity: thanks
<davmor2> slangasek: currently the only install that is flawless is netboot
<willcooke> the only other one I'm really concerned about is this upgrade issue, but it doesn't look like we're going to get a fix for that today
<slangasek> an upgrade issue should also not block the release of milestone images
<Laney> willcooke: Umm, well I've been fixing hidpi only-ubiquity mode which I also got asked to look at
<Laney> and then I should deploy some appstream generator fixes
<Laney> ...but I could do this instead...
<davmor2> infinity, slangasek: mokutils not trigging password on additional driver page no bug for that will be soon though got caught up in meetings and then the control center crasher
<slangasek> davmor2: need bug reports and pointers to them, please
<slangasek> mokutils seems to be bug #1560940?
<davmor2> slangasek: yeap I'll get on it now
<ubot5> bug 1560940 in ubiquity (Ubuntu) "None matching mokutils passwords" [Undecided,New] https://launchpad.net/bugs/1560940
<davmor2> slangasek: no that is in ubiquity this is on the installed system you get no password prompt when installing nvidia binary and intel microcode
<davmor2> slangasek: but that might be due to unity8 session downgrading pkcon
<Laney> willcooke: https://bugs.launchpad.net/ubuntu/+source/libunity/+bug/1538471/comments/25 <- says that pygobject is able to fix it - and pitti is a maintainer of that, so maybe he could help
<davmor2> willcooke: ^ is that a possible side effect?
<ubot5> Launchpad bug 1538471 in libunity (Ubuntu) "scope-runner-dbus.py assert failure: *** Error in `/usr/bin/python3': free(): invalid next size (fast): 0x0000000001ca17b0 ***" [Critical,Confirmed]
<davmor2> slangasek: bug 1546388
<ubot5> bug 1546388 in unity-control-center (Ubuntu) "unity-control-center crashed with SIGSEGV in _cogl_check_extension()" [Medium,Confirmed] https://launchpad.net/bugs/1546388
<slangasek> willcooke: ^^ davmor's u-c-c crasher bug wasn't on the iso tracker
<slangasek> Laney: pitti is sick today, out for rest of week
<Laney> slangasek: I know, but this one can wait IMO - certainly not beta critical anyway
<willcooke> slangasek, @ u-c-c crasher.  Not crashing for Laney or me, so I think it's ok to not block
<slangasek> ok
<davmor2> slangasek: https://bugs.launchpad.net/ubuntu/+source/mokutil/+bug/1561647
<ubot5> Launchpad bug 1561647 in mokutil (Ubuntu) "No prompt triggered when installing from additional drivers" [Undecided,New]
<willcooke> So I think the only blocker atm is https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1552539
<ubot5> Launchpad bug 1552539 in ubiquity (Ubuntu) "Ubiquity Erase Disk and Install Fails to create Swap Space" [Critical,Triaged]
<davmor2> slangasek: I'll check on the unity8 bit of it in a second but I'll need a fresh install to trigger it
<willcooke> davmor2, u8 is in universe, if it causes things to break then we shouldn't block the beta for it
<slangasek> davmor2: bug #1560973 - did you *reproduce* the failure that Laney describes?
<ubot5> bug 1560973 in grub2 (Ubuntu) "EFI booting Ubuntu image to grub removes existing boot entries and makes system unbootable" [Undecided,Confirmed] https://launchpad.net/bugs/1560973
<davmor2> willcooke: no that was just another bug but isn't critical slangasek asked if there was anything else, if it isn't unity8 then it might be more important
<willcooke> ah, soz
<davmor2> slangasek: I did I'm sure I commented on it if not I will now
<slangasek> davmor2: your comment describes a scenario in which you did *not* reproduce the bug. It does not say you reproduced the bug.
<slangasek> davmor2: if you reproduced the bug, please include information about what hardware you reproduced it on
<slangasek> Laney, davmor2: I have requested further info on LP: #1560973.  FTR this sounds to me like a firmware bug rather than a bug in Ubuntu, but will try to confirm that
<ubot5> Launchpad bug 1560973 in grub2 (Ubuntu) "EFI booting Ubuntu image to grub removes existing boot entries and makes system unbootable" [Undecided,Incomplete] https://launchpad.net/bugs/1560973
<slangasek> infinity: so far the only blocker bug that's been identified is the one willcooke mentioned, LP: #1552539, which seems to be a horrible interaction between systemd an ubiquity
<ubot5> Launchpad bug 1552539 in ubiquity (Ubuntu) "Ubiquity Erase Disk and Install Fails to create Swap Space" [Critical,Triaged] https://launchpad.net/bugs/1552539
<slangasek> all the others have been turfed, except for the UEFI boot one which still needs more info
<infinity> slangasek: I don't suppose it's reasonable to release note (and mention in the release announcement) that one might need to delete swap partitions before attempting an install?
<slangasek> willcooke: ^^ ?
<slangasek> if that's confirmed to work, that does seem ok to me for beat
<infinity> A quick ubiquity hack to walk /proc/swaps and swapoff anything that's not /dev/zram* would work, I imagine.
<slangasek> beta
<cherylj> hey guys, is there anything else you need from the team for Juju's FFE?  bug #1545913
<ubot5> bug 1545913 in juju-core (Ubuntu) "[FFe] juju-core 2.0" [Undecided,Confirmed] https://launchpad.net/bugs/1545913
<slangasek> cherylj: couldn't say; there's basically not going to be anyone looking at it until after the beta release is done today
<willcooke> slangasek, infinity - at this point I'm more in favour of a quick fix than a release note
<cherylj> thanks, slangasek.  I will check back later
<infinity> willcooke: I'm a fan of quick fixes too, just not the forced QA turnaround that results. :)
<slangasek> willcooke: "quick fix" does add another 4-6 hour turnaround
<superm1> infinity: ah crap, mysql-5.7 got pulled into mythtv's build and caused problem
<davmor2> slangasek: I've added the info from Laney's.  The issue as I see it is that there is no path or file name changes for boot/EFI/Ubuntu  so they always overide each other
<superm1> since it didn't pull in all the way
<infinity> superm1: Oh, bother.
<davmor2> slangasek: fedora is installed in boot/EFI/Fedora so the 2 show up in the UEFI menu
<infinity> superm1: I can delete mysql-5.7 from proposed and re-copy it in after a fresh mythtv build, if that's all you're blocking on.
<infinity> superm1: We probably want to wait for the result of this larger discussion about blockers anyway.
<superm1> infinity: yeah that's all right now
<slangasek> davmor2: you have *not* described reproducing the bug, you have described *not* reproducing the bug.  Can you reproduce Laney's bug, whereby booting the USB stick, and then removing it, leaves the system unbootable?
<superm1> infinity: after freeze is lifted i can sort out what needs to change to build against 5.7 properly
<infinity> superm1: I imagine once 5.7 completely replaces 5.6, the answer will be "very little", unless you have some hardcoded versioned deps somewhere.
<slangasek> davmor2: you are speculating about the cause of the bug.  What I need is confirmation that the bug is reproducible, and on what hardware
<superm1> yeah i am inclined to think you're right, the failure was looking for mysql/mysql.h and that failing
<infinity> superm1: Huh.  That shouldn't fail.  Sounds like a potential bug in the 5.7 packaging.  But even if it worked, you'd then end up with a dep on the new libmysqlclient, which would keep you stuck in proposed.
<infinity> superm1: Maybe the simplest thing here will be to slap your sources in a PPA that excludes -proposed in build-deps and then copy in the results.  Lemme look at doing that for you.
<Laney> slangasek: I don't understand what you're asking in the penultimate step I'm afraid
<davmor2> slangasek: for that I was using kvm give, it takes an hour or so to install fedora so give me some time
<Laney> slangasek: I don't explicitly add the USB stick to the options - it's preferred by the firmware's boot order when inserted
 * infinity alters his staging PPA to exclude proposed...
<slangasek> Laney: so you recovered the system by going into your firmware and choosing 'Add Boot Option', which is going to modify the contents of the nvram variable.  What I'm trying to see is, once the problem has been reproduced, can we then boot the USB stick again without having to modify the nvram variable, so that we can see what state it's in at that point
<slangasek> davmor2: if you are installing Fedora, you are wasting your time
<slangasek> davmor2: I am asking you if you can reproduce Laney's bug.  So doing something that you expect will not reproduce Laney's bug, then confirming that you have not reproduced Laney's bug, does not help me
<willcooke> slangasek, infinity - if the quick fix is not at all quick.  The +1 on the release note.  I'd like to do a bit of testing here quickly first....
<infinity> willcooke: The quick fix itself would be fairly quick, the turnaround for respinning all the flavours and retesting them is less quick.
<davmor2> slangasek: ah I was misunderstand so my comments then would be an additional bug, in that if you install 2 ubuntu systems side by side there is only one system listed in EFI.  Let me double check on Laney's bug now
<infinity> willcooke: That said, if we had some commitment from our side to spot-check all the flavours post-fix, I wouldn't be against it.  I just don't want to force all the community people who are "done" testing to start over on release day.
<slangasek> davmor2: ok.  please note that what Laney describes is his existing boot entries in firmware being wiped, /without/ installing Ubuntu.  He only booted to the bootloader
<willcooke> infinity, gotya - that makes sense
<Laney> There's not so many changes between pygobject 3.18 and 3.20, so I'm going to upload that
<Laney> (to change bugs a second)
<davmor2> Laney: slangasek so it doesn't happen on my Lenovo let me test on this xps 13 biab
<davmor2> Laney: on your xps 13 do you have bootx64.efi in /boot/efi/EFI/boot/ ?
<davmor2> slangasek: if the answer from Laney is no that is what the issue is by default the efi system looks for that file if it isn't there is doesn't see the harddrive and so you have to manually create an efi entry for it
<slangasek> davmor2: no, that is not the issue
<slangasek> davmor2: the issue Laney is describing is "I stuck an Ubuntu USB stick in my system, booted to the bootloader, and my firmware forgot how to boot my hard drive".
<slangasek> /boot/efi/EFI/boot/bootx64.efi is a workaround for /recovering/ from this
<davmor2> Laney: also what version of the bios are you on?
<davmor2> biab
<infinity> superm1: Okay, building mythtv in a clean PPA, we'll see if that goes better.
<superm1> Okay thanks
<flocculant> infinity: this swap bug - is that a major issue? I've had probably two people mention it to me in months and months - I can never confirm it - indeed I can't confirm it now either
<davmor2> slangasek, Laney: Right I remove my manual entry of /boot/efi/EFI/boot  I then rebooted in UEFI created the entry point to ubuntu that then boots with no issues, once I install the USB pendrive not it removes the previous Ubuntu entry I created which I assume is what Laney is seeing.  If I manually now add the file and folder back it doesn't remove the ubuntu entry
<davmor2> s/not it/now it
<davmor2> and the only entry I have is for the usb pendrive
<infinity> flocculant: It's a non-issue entirely on fresh disks, it's certainly an annoyance when reinstalling.
<davmor2> slangasek: so if Laney is missing that file that is likely to be the cause of the bug
<flocculant> infinity: not for me in vbox - ever
<infinity> flocculant: Huh.  Can't tell if you're lucky or others are unlucky.
<flocculant> and that's what the bug appears to be about
<flocculant> infinity: ha ha
<davmor2> slangasek: it is likely to only affect xps13 users to and some asus iirc
<davmor2> flocculant: are you installing on hardware? I don't see it in kvm only on real machines
<slangasek> davmor2: the /cause/ of the bug is buggy firmware.  The absence of /boot/efi/EFI/boot/bootx64.efi is not the cause of the bug; we do not install /boot/efi/EFI/boot/bootx64.efi, it would help if we did but it's not implemented and it's a workaround for the firmware bug
<davmor2> slangasek: agreed and if Laney is missing that file then his system will boot happily with a manually added entry pointing the the shim file but the minute he adds the pendrive it removes it.  If he has that file and this is still happening then it could be another issue altogether, But I can replicate his symptoms exactly with the file removed.  And I agree it is a workaround for buggy fw which iirc was on my
<davmor2> asus box and this xps13 box but not on my lenovo fw
<davmor2> anyway TEA has been call back in 30
<Laney> slangasek: Hope those are useful to you
<Laney> Will pop back briefly tomorrow morning to perform any other steps, otherwise will be off for a week
<Laney> (sorry!)
<flexiondotorg> infinity, flocculant Just reading the backlog.
<flexiondotorg> I've seen the swap issue on vms and hardware.
<infinity> flexiondotorg: Right, I don't think anyone's disputing that it's a bug.
<infinity> flexiondotorg: flocculant just seems to be the only person in the world who's never seen it.
<infinity> (lucky him)
<flocculant> davmor2: swap issue - never seen it - full stop, not in vb, kvm or hardware
<flocculant> ha ha
<flexiondotorg> However, in the last couple of days I've completed about 20 installs on hardware and VM for Ubuntu, Ubuntu MATE and Lubuntu.
<flexiondotorg> I've encunter the swap issue once.
<infinity> Methinks it might be slightly racy. :P
<infinity> The giant hammer fix I'm thinking of would work around whatever race is there, but not really solve the issue itself.
<flexiondotorg> infinity, I can be available to smoke test some image later if a respin is required, but not PowerPC because that takes ages.
<flocculant> I would too - but I'd only be able to if you forced the error everywhere so I could see it :)
<infinity> flexiondotorg: Given the types of changes we're discussing, I don't think much testing of PPC would be required, though confirming that they're still bootable would be worth doing before releasing them blind.
<flexiondotorg> infinity, Can I test boot one image from one flavour? Is that sufficient?
<flexiondotorg> For PPC.
<infinity> flexiondotorg: Not really.  The goal is to make sure the image wasn't mis-built, do we're not releasing a blob of useless bits masquerading as an ISO.
<infinity> s/do we're/so we're/
<flexiondotorg> OK. You're making me sad. But I'll test boot Lubuntu Desktop and Ubuntu MAT Desktop for PPC.
 * flexiondotorg glares at his USB DVD writer.
<flocculant> infinity: what sort of time scale are we talking about?
<infinity> flexiondotorg: Alright.  This is all still under the assumption that we intend to respin.  I'm leaving that up to slangasek and willcooke to make the final call.
<flexiondotorg> OK.
<infinity> flocculant: Realistically, if this drags on any longer today, *and* we decide we need to respin, we might delay the release to tomorrow.
<infinity> I'd rather get it right than rush it.
<flocculant> ok
<flocculant> yea for sure
<slangasek> Laney: thanks, yes, I take that as confirmation that this is the firmware doing something inappropriate
<flexiondotorg> Just so I'm clear, the only issues on the cards for fix and the swap creation and EFI corruption?
<flexiondotorg> *fixing are
<slangasek> flexiondotorg: only swap creation. We can't fix buggy firmware from Ubuntu, and the workaround isn't landing for beta
<infinity> slangasek: Okay, so that leaves the question of if "only swap creation" is worth fixing for beta, or just release noting.
<slangasek> infinity: I'm going to defer to willcooke
<infinity> Given it can only affect reinstalls, which are already a bit of a power user / QA tester thing to do.
<willcooke> so far I haven't been able to recreate it
<willcooke> trying again, and then considering blowing away my test machine
<infinity> Well, blowing away the test machine makes it 100% unreproducible. :)
<willcooke> :D
<willcooke> ship it!
<infinity> Since the bug has to do with existing swap being active when we try to smack it around.
<infinity> Or, as I understand it.
<rtg> superm1, I'm gonna start with https://lkml.org/lkml/2013/8/19/331 as a guide
<flexiondotorg> willcooke, Do a full disk encrpytion install. Then do a full disk not encrypted install over the top.
<flexiondotorg> Increases the odds of seeing it a little.
<cyphermox> is someone already looking at the swap issue?
<cyphermox> I mean, aside from me
<infinity> So... Release announcement including something like "In certain cases, the installation may halt on failure to create or reinitialise the swap partition.  The workaround for this is to delete pre-existing swap partitions before starting the installer."
<infinity> slangasek, willcooke: ^  +/-1
<willcooke> +1
<infinity> cyphermox: My simple workaround was going to be to walk /proc/swaps right before partitioning and swapoff anything that doesn't match /dev/zram*
<infinity> cyphermox: But finding the actual bug would be nicer.
<cyphermox> +1
<cyphermox> why are swaps even automatically getting added? should that not only happen at boot?
<slangasek> infinity: can we really say that this isn't the bug? isn't systemd working as designed, autoprobing swap?
<infinity> slangasek: It might be working as designed, yes.  I'm unsure myself.
<cyphermox> what about just making systemd not autoprobe swaps just for the installer?
<cyphermox> (ie, in casper or something)
<infinity> slangasek: If it is, indeed, doing what it's meant to here, and we decide its actions are Pure and Good and True, then installer partitioners indeed just need to handle swapoffing the world before partitioning.
<infinity> cyphermox: If systemd is autoprobing swap and making good use of it, restricting that from casper would cripple people who use livecds as, well, livecds.
<infinity> cyphermox: swapoffing in the installer would be the more friendly solution.
<cyphermox> infinity: heh
<cyphermox> you don't have swap on a CD
<cyphermox> they might have swap on the disk otherwise, but that's far from being certain ;)
<infinity> Well, yes.  But if they do have swap on disk, and we activate it, their live session just got (potentially) less crap.
<cyphermox> that said, if we can just swapoff the world before partitioning, that should be easy
<infinity> Why would we take the possibility for that away?
<stgraber> seems a bit odd to me that a live usb stick or live cd would start using a random partition on my hard drive just because it's got the right partition type
<cyphermox> ^ that
<infinity> stgraber: And indeed, that's the other argument. :)
<infinity> Which would then be a systemd bug full stop.
<stgraber> on an installed system that's fine, but if the goal of a live media is not to touch what's installed on disk, then what we're doing right now is pretty wrong
<slangasek> that would be the argument for it being a systemd bug, yes
<infinity> Cause you'd also expect the same from a dual-boot system (don't use the other OS's swap unless I said so, jerkface)
<cyphermox> it's not really such an issue anymore that I know, but slowlaris used to write the magical kernel crash dumps to its swap
<slangasek> doesn't matter if it's installed or live, random swap activation is either ok or not ok
<cyphermox> oh, hibernate ;)
<stgraber> oh yeah, also wouldn't the current behavior completely break an existing suspend to disk?
<infinity> STD writes a signature.
<infinity> I kinda hope any auto-activation is smart enough not to touch those.
<infinity> But also potentially broken, yes.
<cyphermox> well, let's see systemd then
<infinity> So, lots of open questions here for later.
<infinity> But for today, we're good with release-noting and release announce mentioning the issue?
<infinity> slangasek: Still waiting on your +1 on that.
<slangasek> infinity: yes, +1
<infinity> Alrighty.  Then I guess we're not respinning (except for myth, when I get superm1's fixes through), and I can pre-publish.
<infinity> cyphermox: I think that, even if we decide systemd is being dumb, it's probably right for partman to swapoff non-ram devices before trying to abuse the disk *anyway*.
<infinity> cyphermox: Then we can sort out if systemd's also being a jerk.
<cyphermox> yes
<cyphermox> assign the bug to me, I will need to rebuild ubiquity to fix keyboards anyway
<cyphermox> or, I expect I will
<infinity> cyphermox: I imagine the fix belongs in partman, not ubiquity, ubiquity just happens to be the only one that sees the bug because d-i boots with a shell-based init instead of something fancy like systemd.
<cyphermox> well, swapoffing yes
<cyphermox> but it needs to be pulled in to ubiquity anyway
<infinity> I feel bad about verbifying swapoff.  swapoffing sounds so awful.
<infinity> cyphermox: *nod*
<cyphermox> too late
<infinity> cyphermox: https://bugs.launchpad.net/ubuntu/+source/partman/+bug/1552539
<ubot5> Launchpad bug 1552539 in ubiquity (Ubuntu) "Ubiquity Erase Disk and Install Fails to create Swap Space" [Critical,Triaged]
<infinity> cyphermox: Assign away, I can never remember your LP UI, and too lazy to search right now.
<infinity> s/UI/UID/
<cyphermox> yeah, I meant to make my LP UID cyphermox after all, but PPAs and all.
<infinity> cyphermox: Meh, no one can love their PPAs that much, surely.
<cyphermox> it's not love, it's just laziness
<infinity> :)
<infinity> Well, if you ever delete all your PPAs, let me know, and I'll rename you. :P
<cyphermox> I suppose I could wipe everything later
<cyphermox> I will still need a PPA that can build everything though
<infinity> willcooke: Okay, so looks like the last thing I need from your team is a bit more i386 testing, and a signoff on both images being "good enough".
<willcooke> I'll do that now
<infinity> willcooke: And hopefully you and slangasek have sorted out assignment and blame for all the current bugs so we can fix them in the next week or so instead of forgetting until release week.
<willcooke> :)
<infinity> willcooke: Not being entirely facetious there.  We sometimes have a nasty habit of only remembering bugs during a testing cycle, which isn't the ideal time to fix them. :P
<willcooke> infinity, understood.  I have a spreadsheet
<infinity> superm1: Still waiting on those mythtv builds, but I'll ping you as soon as it's all copied over so you can ACK the binaries and we can unblock and get you rebuilt.
<infinity> superm1: Oh, looks like I have an hour or more to wait for armhf still.  I'll take lunch, and then get back to you.
<infinity> superm1: It's building in https://launchpad.net/~adconrad/+archive/ubuntu/staging/+packages FWIW.
<wxl> um, are we planning to release today?
<infinity> wxl: Yep.
<wxl> infinity: k, cool. just checking. :)
<infinity> wxl: If you feel like being helpful/annoying, you can chase people down to make sure their beta-2 pages are all existing and check the main ReleaseNotes for accurate links, etc.
<wxl> infinity: okie dokie
<infinity> (pretty sure it all points to 16.04/release right now when it should be 16.04/beta-2, for instance)
 * infinity goes on a quick hamburger hunt.
<davmor2> slangasek: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1561712 this is the new bug for the issue I though Laney was reporting.
<ubot5> Launchpad bug 1561712 in grub2 (Ubuntu) "EFI doesn't show multiple installs of the same operating system" [Undecided,New]
<davmor2> this isn't critical or anything
<davmor2> slangasek: it would just be nice to have
<slangasek> davmor2: that's going to be a wontfix
<davmor2> slangasek: why is that?
<slangasek> you get the boot menu from inside of grub, you won't have it at the UEFI level
<infinity> Or, more to the point, we're not going to install EFI/ubuntu-1, EFI/ubuntu-2, etc.  That way lies madness.
<davmor2> slangasek: fair enough
<infinity> There might be something we can do to refcount EFI/ubuntu, though, to at least avoid the "I installed two and deleted one, and now it's all gone" problem.
<infinity> Though I'm unsure how that would happen unless you actually use dpkg to uninstall grub-efi before deleting the OS you wanted to get rid of.
<davmor2> infinity: if you delete the partition to make use of the full hdd the entry point would nolonger exist right
<infinity> davmor2: If you delete the EFI partition all bets are off for your old EFI OSes anyway.
<infinity> That's not only something we can't fix, it's expected behaviour.
<davmor2> infinity: not the efi partition the os partition or is all of grub now stored in EFI partition
<infinity> The bit you're talking about is in the EFI partition...
<davmor2> infinity: for example |efi|16.04|swap|16.10| 16.10 is aweful so delete it and then have |efi|   16.04   |swap|
<davmor2> infinity: so that would keep the efi mount point from 16.10 but that would also pin point the 16.04 install too
<willcooke> meh - dont try and install 4 vms at the same time
<willcooke> davmor2, I'm going through the i386 test cases arm
<willcooke> atm
<wxl> infinity: yofel/kubuntu is kind of stuck with bug 1561051. if you have any suggestions to debug, please pass them yofel's way.
<ubot5> bug 1561051 in ubiquity (Ubuntu) "Ubiquity-DM dies on Kubuntu images" [Undecided,Confirmed] https://launchpad.net/bugs/1561051
<davmor2> willcooke: 4 at the same time is fine as long as the resources are low enough
<infinity> wxl: I'm afraid I have no clue.
<wxl> infinity: i figured as such. just thought i'd pass it on.
<yofel> I would already be happy if someone told me how ubiquity-dm is launched... I have no idea what "program" I'm supposed to pass to it
<wxl> infinity: asked them to either mark not-ready or to update the Beta2 page, which, at this point, seems cleaned up.
<infinity> yofel: I'm sure cyphermox can help you with some basic ubiquity-dm debugging tips.
<yofel> ok, thanks
<infinity> yofel: Does the live session (and ubiquity invoked from the desktop) work fine?
<infinity> yofel: If so, I'd suggest that unless you can fix this issue in the next hour or so, you release note that installs must be done from the desktop and we revisit tomorrow.
<yofel> yes (well, the widget that shows the icon is too small to properly show it, but you can start ubiquity)
<infinity> yofel: But if it's broken entirely, not releasing may be the only option. :/
<yofel> nah, we can release, we're just missing the language selection I think. The desktop also looks somewhat broken, but not unusable
<yofel> and the install itself went fine in my tests
<infinity> yofel: Kay.  I'll come back around to you in a bit when everything else seems ready, and we'll sort out some wording to throw in the Kubuntu section of the release announcement to warn people about breakage.
<yofel> thanks, I'll be around for a few more hours
<wxl> yofel: meanwhile, update the Beta2 page :)
 * infinity goes to finish his lunch.
<davmor2> slangasek, infinity, cyphermox: out of interest how do you get a tty from the ubiquity session or do you have to go to the desktop session?
<cyphermox> you can't right now, but we can fix that
<cyphermox> (in fact, I want to fix that, because it's annoying)
<davmor2> cyphermox: :)
<superm1> davmor2: it's a little hacky but if you open network manager settings and try to import a vpn configuration you can right click and hit "open in file manager", then in file manager browse to /usr/bin/ and double click gnome-terminal.real
<davmor2> cyphermox, willcooke: so I just tried all the options for the swap format issue and it affect all the automatic partitioning options on mac and lenovo so only lvm/encryptedlvm automatic installs work or manual partitioning
<davmor2> I'll add that info to the bug
<cyphermox> sounds about right. if you use LVM/encrypted all partitions are deleted, and with manual also all partitions end up getting replaced/deleted.
<willcooke> davmor2, if you're around for a bit, would appreciate an extra pair of hands on the i386 ISO tests
<willcooke> so we can mark them good enough
<davmor2> willcooke: Yeah I'm around till it's done I need to go for a walk in a bit for testing the phone cause walks along canal towpaths in wolverhampton aren't dangerous enough :)
<willcooke> that sounds like a terrible idea
<cyphermox> infinity: I confirm my keyboard selection fix for d-i
<cyphermox> ubiquity will still need more work though
<cyphermox> (or I didn't test it right, but whatever)
<davmor2> cyphermox: just confirming with no unity8 install secureboot enabled mokutil isn't trigger in additional drivers
<cyphermox> mmkay
<teward> cyphermox: there's a potential fix for the d-i keyboard issue?  (sorry just asking, i was looking for something in scrollback, saw your message)
<davmor2> cyphermox: does from the command line and shows the mokutil section in the installer just not on additional drivers
<cyphermox> there's a couple reasons why it might not be triggered, usually it's because the system isn't booted EFI; or SecureBoot is in a state where it won't actually check things, etc.
<cyphermox> davmor2: I'm not sure what you mean by additional drivers?
<davmor2> cyphermox: open the dash type additional drivers
<cyphermox> teward: as I said, console-setup; but that also needs a rebuild of d-i
<cyphermox> davmor2: ah, ok
<teward> ah, i see.
<davmor2> cyphermox: it is how you install binaries
<cyphermox> davmor2: that's quite annoying then, additional dirvers should be happy to ask debconf questions :(
<davmor2> cyphermox: for hardware
<davmor2> cyphermox: yes and ask I say if I install fwts in the cli it asks me straight away same system same setup no modifications
<davmor2> cyphermox: and nvidia definitely should trigger it
<flexiondotorg> slangasek, infinity, willcooke Is this being release noted? http://launchpad.net/bugs/1555237
<ubot5> Launchpad bug 1555237 in ubuntu-release-upgrader (Ubuntu) "Upgrade from 14.04.4â 16.04 dies midway taking out the session." [Critical,In progress]
<cyphermox> davmor2: yeah, I know what this is. please file a bug against additional drivers (software-properties, I think)
<teward> cyphermox: thanks for looking into it though :)
<davmor2> cyphermox: already filed it against mokutil so I'll just move that over and remove the unity8 concern I had
<davmor2> willcooke: to answer your question I can install nvidia and intel microcode with unity8 session installed :)
<willcooke> davmor2, thx
<willcooke> flexiondotorg, yes, should be.  I can add it now...
<davmor2> willcooke: still need to test amd on upgrade but obviously that needs upgrades to work
<willcooke> davmor2, yeah.  I'm doing the last few mandatory i386 tests now, and then I think we will mark it "good enough"
<davmor2> I got 3 on the go
<willcooke> btw - is there a wiki page just for final beta release notes or do I add to this page: https://wiki.ubuntu.com/XenialXerus/ReleaseNotes/
<davmor2> cyphermox: did you say there were bugs already for the broken OEM end user?
<cyphermox> yeah
<superm1> davmor2: bug 1552621 IIRC
<ubot5> bug 1552621 in ubiquity (Ubuntu) "Can't login to desktop autometically after oem-config is finished on OEM mode" [Undecided,Confirmed] https://launchpad.net/bugs/1552621
<cyphermox> also https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1508865
<ubot5> Launchpad bug 1508865 in ubiquity (Ubuntu) "oem-config: networking not enabled during user config" [High,Confirmed]
<wxl> willcooke: https://wiki.ubuntu.com/XenialXerus/Beta2
<willcooke> ahha! Thanks wxl
<davmor2> willcooke, cyphermox: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1561647
<ubot5> Launchpad bug 1561647 in software-properties (Ubuntu) "No mokutil prompt triggered when installing from additional drivers" [Undecided,New]
<cyphermox> davmor2: thanks
<superm1> infinity: it finished finally on that ppa
<superm1> infinity: when you copy it over don't forget to also let mythbuntu-meta out of proposed too
 * flexiondotorg wonders if people testing in VirtualBox and VMWare that LP: 1370707 is intended behaviour now?
<ubot5> Launchpad bug 1370707 in plymouth (Ubuntu) "Plymouth does not display the graphical boot splash" [Medium,Confirmed] https://launchpad.net/bugs/1370707
<flexiondotorg> Because that a blacklisted, to ensure a sane resolution is negotiated by X.
<flexiondotorg> Excuse the typing, I'm sat in pitch black room with no backlit keyboard.
<infinity> willcooke: ReleaseNotes is a living document, there isn't one for each milestone.
<jibel> willcooke, all the mandatory test cases are missing from the tracker for ubuntu deskktop apparently
<willcooke> infinity, creating the Ubuntu one now, copied from the main release notes and removing a bit and adding a bit.
<infinity> willcooke: Err, no.  Don't create an Ubuntu one. :)
<willcooke> undo undo
<infinity> willcooke: Just edit https://wiki.ubuntu.com/XenialXerus/ReleaseNotes
<infinity> willcooke: The flavours like to do whacky things, but Ubuntu just uses the main document and updates it as we go.
<jibel> willcooke, if you compare to http://iso.qa.ubuntu.com/qatracker/milestones/356/builds/112745/testcases the first section is missing
<wxl> hey hey now infinity, maybe YOU'RE the one doing whacky things XD
<infinity> wxl: Whackiness is in the eye of the beholder.
<willcooke> jibel, so it is
<doko> are autopkg tests for s390x turned off? didn't see any done when retrying tests
<willcooke> jibel, how do we make it come back?
<infinity> doko: The s390x queue is empty, that would seem to imply they're being run.
<doko> infinity, but if you look at update_excuses (ruby2.3), then you see the rebuilds missing)
 * flocculant ponders doing the not whacky thing with release notes in future ... 
<willcooke> ok, got the swap issue and worked around it
<infinity> flexiondotorg: The not whacky thing would just be to start at your "final location" with whatever milestone you start at, and keep editing it, instead of creating a new one for each milestone.
<infinity> Err
<jibel> willcooke, I readded the missing test suite
<infinity> flocculant: ^
<infinity> Too many fl nicks.
<jibel> willcooke, it's 5 more mandatory tests
<flexiondotorg> infinity, wha?
<willcooke> "thanks" jibel ;)
<infinity> flexiondotorg: Wrong fl.
<flexiondotorg> infinity :-)
<flocculant> infinity: yea - I got what you meant - I kind of build a draft through the cycle anyway
<jibel> willcooke, i'm checking non english installs in i386
<willcooke> thanks
<davmor2> willcooke: so the system settings issue looks like it might be an issue triggered from the dash, maybe. If I search for an element ie open dash and look for screen and open it from there then I get the crash opening system settings for the first time after that
<wxl> didn't we get an email from edubuntu saying they weren't participating in beta2?
<davmor2> wxl I think edubuntu just weren't releasing at all for 16.04 iirc
<wxl> davmor2: k. i'm going to mark them as "no" on /Beta2
<wxl> they're not in the milestones, so there ya go
<jibel> even keyboard detection is broken :(
<willcooke> davmor2, weird.  Just tried on my fresh 16.04 amd64 install from like 10 mins ago, and it works here.  Please open a bug anyway against u-s-s and we can take a look
<willcooke> oh btw - the genital warts thing is fixed
<popey> hah, i arrive and that's the first thing I see
<slangasek> that's... um... good news
<willcooke> :)
<davmor2> willcooke: there is already and apport bug for it let me dig it out
<popey> nice one willcooke
<davmor2> willcooke: https://launchpad.net/bugs/1546388
<ubot5> Launchpad bug 1546388 in unity-control-center (Ubuntu) "unity-control-center crashed with SIGSEGV in _cogl_check_extension()" [Medium,Confirmed]
<stokachu> can someone reject juju2
<flexiondotorg> willcooke, My daughter finally sleeps.
<flexiondotorg> What i386 test are remaining? I might be able to help with one.
<davmor2> flexiondotorg: none
<willcooke> flexiondotorg, thanks!  We're not doing too bad now
<flexiondotorg> willcooke, Daviey Heroic effort you two :-)
<flexiondotorg> Oops, davmor2. I meant you.
<davmor2> :)
<willcooke> wouldnt hurt to do a quick pass of a mandatory test
<knome> Daviey, don't worry, you are heroic as well!
<davmor2> willcooke: I've added a comment to it for when I triggered it.
<jibel> flexiondotorg, CJK input is not tested
<flexiondotorg> jibel, Not something I can help with :-(
<davmor2> flexiondotorg: you mean you are not fluent in Chinese Korean or Japanese?? Why
<flexiondotorg> davmor2, æ²¡æ
<davmor2> flexiondotorg: hahaha
<doko> stokachu, done
<infinity> doko: D'oh, beat me by half a second.
<doko> infinity, so any idea about the s390x issues?
<infinity> doko: Not sure right now what's up there.
 * flexiondotorg makes fish finger butty
<infinity> flexiondotorg: Makes... What now?
<flexiondotorg> superm1, Can we do anything to help test mythbuntu?
<flexiondotorg> Is an install in a VM good enough?
<superm1> flexiondotorg: waiting on infinity to re-spin with new packages
<flexiondotorg> infinity, Food of the Gods. Ask willcooke and popey ;-)
<flocculant> infinity: it's a very english thing I guess - you're not missing anything :p
<superm1> flexiondotorg: an extra test on VM would be helpful.  it will boot up confused that it doesn't have a backend anywhere near by, but that is fine
<infinity> superm1: Still need to get them through propose-migration, we'll get there.
<willcooke> flexiondotorg, \o/
<superm1> but testing with today's images without those packages leads to weird problems
 * infinity reads https://en.wikipedia.org/wiki/Fish_finger_sandwich and loses his appetite.
 * flexiondotorg is standing by. Someone ping me when a new mythbuntu image is available for testing
<slangasek> doko: the autopkgtest api unfortunately is not completely reliable at making sure either your test is scheduled or you get an error.  I haven't looked deeply at this, but I've seen re-run requests go missing before.  If you don't see the request on http://autopkgtest.ubuntu.com/running.shtml, and you don't see the result on the corresponding per-package page within 5 minutes, I recommend re-submi
<slangasek> tting the request
<davmor2> flocculant: you lie. Fish Fingers are food from the Cods easy mistake to make
<slangasek> doko: also, for most requests you shouldn't need to submit on snakefruit, you can do it directly from update_excuses nowadays?
<davmor2> flexiondotorg: ^ even
<davmor2> sorry flocculant
<flexiondotorg> Homemade tarate sauce. Winning
<doko> slangasek, not for building against -proposed, which is most of things I have to do
<slangasek> doko: ok, true
<doko> and this is one thing which probably should get more automating when to do tests against proposed
<slangasek> doko: what are your cases for that?  That workaround usually implies a missing versioned dep/breaks, and I worry about things slipping into xenial in a half-broken state
<slangasek> doko: well, fix the versioned deps/breaks and autopkgtest should DTRT for you, that should automate it
<infinity> slangasek: In the ruby case, the tests all use a common framework, so if the framework is broken in the release pocket, you're SOL.
 * flexiondotorg groans at "food of the cods" ;-)
<slangasek> infinity: fair.  but that's not the common case IME
<davmor2> flexiondotorg: hey it's late and true
<flexiondotorg> :-D
<infinity> slangasek: Indeed, no.  The other case would be where a specific bugfix has to happen in two packages in concert, but that doesn't imply that either breaks/conflicts with the previous versions, just that the previous ones were already broken. :P
<doko> slangasek, but this is true for every transition. you want to run all these tests using the version in -proposed
<infinity> slangasek: In most cases that aren't framework or multi-package fixes, I'd expect deps to get it right.
<wxl> infinity: imma gunna leave the rest of the chasing to you.
<willcooke> right, at this point I think I'm ready to say Desktop is good enough.
<slangasek> doko: ok, I concede the point. I believe this warrants a bug report against the infrastructure
<doko> ok, giving back for s390x
<willcooke> infinity, do I have to do anything to mark it as ready?
<wxl> willcooke: you mean "good enough for beta." ship it!
<willcooke> :D
<infinity> willcooke: Tick the two boxes, scroll to the bottom, and find "mark as ready"
<willcooke> exactly
 * popey belatedly concurrs that fish-finger buttys are nectar.
<infinity> popey: You people are weird.
<willcooke> I've got some pickled eggs downstairs
<popey> Correct.
 * infinity hugs his poutine.
<flocculant> pickled eggs are fine
<popey> *parp*
 * wxl fetches a barf bag.
<flocculant> indeed :)
<willcooke> infinity, sorry - can't find these boxes.  Where should I be looking, in the ISO tracker?
<infinity> willcooke: Yeah, the milestone page that lists all the ISOs.
 * flexiondotorg makes another fish finger butty, because one is never enough.
 * wxl does like nattÃµ, though
<infinity> willcooke: You tick the little boxes to the left of Ubuntu Desktop {amd64,i386}, scroll down, find "Mark as ready" in the dropdown box, and "update build status.
<stokachu> doko: thanks!
<infinity> willcooke: Traditionally, I do this for desktop after I see enough tests roll in because no one else seems to know where the buttons are.  If you're taking over that responsibility, yay. :)
<flocculant> ha ha
<willcooke> infinity, am I missing access to something perhaps, or just stupid (note *or*)   http://imgur.com/ZGcDNdl
<infinity> willcooke: Or not logged in?
<willcooke> yeah, am logged in
 * flexiondotorg wonders if I can make then ready?
<flocculant> willcooke: should look like http://i.imgur.com/iPxldFJ.png
<infinity> willcooke: Possibly an access issue, then.  You're listed as a contact for desktop, but perhaps that's not enough.
<infinity> stgraber: *poke*
<ogra_> willcooke, just talk to the desktop team manager to have him grant you prmission
<flocculant> infinity: I thought ' release team member'
<flocculant> at least that's how it works for flavours generally
<willcooke> ogra_, :p
<infinity> flocculant: Well, that's a bit of a misnomer too, since most of you aren't in ~ubuntu-release.
<ogra_> :)
<knome> infinity, xenial beta 2 ubuntu desktop images to ready?
<jibel> willcooke, I marked Ubuntu Desktop as ready
<flocculant> infinity: flavour release team
<wxl> ouch that's a burn
<willcooke> thanks jibel
<infinity> Ahh, there are groups in the tracker.  Of course there are.
<willcooke> \o/
 * wxl makes ~ubuntu-flavor-release to spite infinity 
<willcooke> *Thank you* everyone
<flocculant> :)
 * willcooke goes to look for a beer - brb
 * wxl should note that's also to spite flocculant since it's not flavoUr XD
 * flocculant hasn't far to look
<knome> flocculant, yeah, the beer is in your head already...
<slangasek> flavour flÄv
<flocculant> wxl: I ignore mad mispellings from the colonies
<wxl> wut wut slangasek
<flocculant> knome: hand :p
<wxl> flocculant: hehehe :)
<flocculant> :)
<infinity> slangasek: Did he really spell it with the diacritic?
<slangasek> infinity: no, nor with the onerous 'u'
<infinity> jibel: server ISO testing, is that auto-filled?
<infinity> jibel: Cause it's looking sparse on x86.
<infinity> (I'll do ppc* now)
<stgraber> infinity: access is done through SSO and Launchpad teams
<jibel> infinity, no it is not.
<jibel> let me quickly go through it
<stgraber> infinity: the sign-off name is just a text field so we know who to nag on IRC, it doesn't create any extra access
<infinity> stgraber: Kay.  So how do I know what teams are mapped to what?
<infinity> stgraber: Cause the drop-down list for product access lists pretty names that don't map to anything in my mind.
<stgraber> infinity: what matters is the owner field in http://iso.qa.ubuntu.com/admin/config/services/qatracker/products
<stgraber> infinity: desktop belongs to no drupal role, so that means only the release team has admin access to the product
<infinity> stgraber: Right, I found that.
<infinity> stgraber: Can't be only the release team, jibel can twiddle it.
<stgraber> well, release team and the qatracker developers
<stgraber> which does include jibel
<jibel> infinity, TBH I don't know for server. default tests pass but then everything more advanced is really red
<stgraber> so if we know to give admin access to other folks, we need a LP team with the right folks in it, then I can map that to a drupal role and we can use that role as the owner of the desktop product
<jibel> infinity, we'd need someone from the server team to approve the images. I cannot do it based only on the results of the automated tests, they are too bad
<infinity> jibel: It would be nice if that was reported to the tracker before release day. :/
<jibel> infinity, well, the server team is supposed to take care of its product
<jibel> infinity, I'll talk to matsubara
<willcooke> jibel, is the "Install third-party software for graphics.... etc etc" screen in the installer not being in French a known issue?
<willcooke> or rather, is it in English for you too?
<infinity> s/issue/feature/
<jibel> willcooke, yes it is untranslated
<willcooke> oki
<jibel> willcooke, some pages of the slideshow are also in english
<infinity> That should definitely be fixed before release.
<jibel> willcooke, and in the list of languages there are some fonts missing at the bottom of the list
<jibel> willcooke, the installer needs a review of the localization before release
<flexiondotorg> The languages is test had the same untranslated strings in Ubiquity.
<flexiondotorg> Where that install 3rd party stuff has been modified since 15.10.
 * willcooke makes a note to follow up next week
<infinity> jibel: Oh.  Do you have some pointers at the red tests?
<infinity> jibel: I bet it's because I didn't get around to getting postfix off the CD, so all the automated tests stall on postfix wanting to be configured. :/
<infinity> s/CD/default install/
<jibel> infinity, https://platform-qa-jenkins.ubuntu.com/view/ISO%20Installer/view/Xenial%20Server%20d-i/
<jibel> infinity, matsubara know there existence and has access to the instance and the code of the tests.
<jibel> their*
<rcj> infinity, should cloud images hold off on beta-2 publication?  if so, I'll check in after dinner and bedtime for the little one.
<infinity> rcj: You can publish whenever you like, really.  But if you want to do it when I announce, that'll be in a few hours, I think.
<rcj> infinity: I'm going to start so that I might take off some of tomorrow as planned (poorly planned)
<infinity> jibel: I'm having a hard time seeing the failures in those tests (I mean, other than the red ball...)
<jibel> infinity, I'll have a look with Max and Diogo tomorrow
<infinity> jibel: Sure, but release is today. ;)
<infinity> jibel: If basic install profiles work (as I just tested on ppc), I'd rather release an imperfect beta than no beta.
<slangasek> infinity: hmm. what pulled postfix in?  that seems worth a respin and autoretest...
<willcooke> I'm gonna go and get a couple of hours downtime. bbl.
<infinity> slangasek: mdadm.  I was working on a patch locally to drop the Recommends to a Suggests along with an update-mot.d snippet.
<infinity> slangasek: We could do the former without the latter for now, and I can add the snippet when it's done.
<infinity> (I'm in a unique position to test this, as I have RAID arrays in varying states of sadness because I'm terminally lazy about replacing disks)
<slangasek> infinity: that makes sense to me... probably with a tracking bug for the update-motd.d so it doesn't get lost?
<infinity> slangasek: Kay.  Can do.  I think there's a bug already, lemme go find it.
<infinity> Well, there's this: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1549319
<ubot5> Launchpad bug 1549319 in mdadm (Ubuntu) "server iso install prompts for postfix config" [Medium,Confirmed]
 * lamont supports getting postfix off the CD
<infinity> Right, that's the one I was thinking of.
<infinity> So, I'll reference that in the upload, but not close it.
<infinity> lamont: It'll still be on the CD, just not in the default install.  The latter is the oops.
<lamont> better
<infinity> slangasek: --^
<infinity> rcj: Note that this change would also change cloud images too, unless you've been manually working around it and not installing postfix...
 * infinity looks at a cloud image manifest.
<infinity> Yeah.  Has postfix in it.
<flocculant> infinity: so are we looking at hours for announce?
<cyphermox> I discussed mdadm weeks ago with smoser
<cyphermox> I thought he had already fixed this
<infinity> cyphermox: Yeah, and he discussed it with me, and we came up with a plan, and I took ownership because I can test it and he can't (as easily), and then it failed to happen before beta because derp.
<cyphermox> oh ok
<infinity> flocculant: Yeah.  A fair number of them, I'd say, if we're going to do a quick server respin.
<cyphermox> then he probably talked to you because he said you had some thoughts about the Recommends vs. Suggests for a mta
<lamont> smoser and I also talked about mdadm vs postfix, and yeah... that. Suggests: is right
<infinity> cyphermox: Yeah, I had conditions about dropping the Recommends, namely having another vaguely reasonably visible method of whining.
<infinity> (the motd thing)
<lamont> s/right/reasonable/
<cyphermox> makes sense
<infinity> So, will fix that later.  But the above upload changes the relationship at least.
<flocculant> infinity: oh right - thanks - just needed to know, I've been up for 19 hours now and am about 20 years too late for an all-nighter :p
<infinity> flocculant: I have no intention of preventing you from sleeping.
 * infinity self-reviews that mdadm.
<flocculant> ha ha
<infinity> I also might pretend that I don't notice that mdadm is on the lubuntu alternates, so I don't force them to re-test...
<infinity> slangasek: Want to review that post-upload and unblock if you think it's worth respinning server?  Kthx.
<slangasek> infinity: looking
<slangasek> infinity: yes, you appear to have spelled 'Suggests' correctly
<infinity> slangasek: It was hard, but I Googled.
 * infinity raises his brow.
<infinity> balloons: Well, that seems to raise the stakes a bit.  No more "we're shipping two versions, so can we put one in universe and pretend it doesn't suck"?
<stokachu> infinity: exactly
<stokachu> xenial == juju 2.0 with juju 1 in the ppa
<infinity> stokachu: Well, that just means the juju team needs to commit even harder to juju2 not sucking. :P
<jibel> infinity, I looked at the failures of server tests, the installation is successful but the post-installation tests are failing for various reasons. So either the server testsuite is unmaintained or there is a real problem
<stokachu> infinity: haha
<infinity> stokachu: Yeah, wasn't being sarcastic.
<infinity> jibel: That sounds a lot like test infra hating us.
<stokachu> infinity: you should wait for beta 3 then
<stokachu> or beta 10
<jibel> infinity, the test infra is fine otherwise the installation would fail too
<infinity> jibel: I mean the tests, sorry, not the actual infra behind them.
<jibel> infinity, right
<infinity> jibel: But if they all fail similarly, it would be some scaffolding they have in common.
<infinity> (Or some feature they're expecting on the installed system that isn't there anymore and they shouldn't be relying on)
<infinity> jibel: Anyhow, my perusal of them came to a similar conclusion that things seem to work for the bits I care about (ie: stuff installs).
<jibel> infinity, for example for tomcat the test checks if the deamon is running and it is not
<jibel> infinity, yes, the installer works
<jibel> no doubt about it
<infinity> jibel: I think we can probably agree we're in "good enough for a milestone" territory, but clearly someone needs to apply love to the automated testing and figure out what/where to lay blame.
<jibel> infinity, I'm fine with that
 * flexiondotorg snorts and wakes himself up.
<flexiondotorg> How goes things? Anything I can do to be useful?
<wxl> are we there yet?
<infinity> About to respin myth.
<wxl> oh my.
<infinity> Yeah.  Life's never simple, is it?
<wxl> guess nawt.
<infinity> slangasek: Before I go and respin server, do we have someone who knows how to smoketest s390x to make sure it didn't break?
<infinity> slangasek: I'm prepared to do the other 4.
<rcj> infinity, yes, postfix in cloud images
<infinity> rcj: Yeah, I checked the manifest and confirmed that.
<slangasek> infinity: I had in fact intended to forego the smoketesting on respin given the narrow scope of the change and the cumbersome nature of smoke testing
<slangasek> dannf: ^^
<infinity> rcj: If you want to respin after the new mdadm lands to remove postfix, shiny.  If not, meh.  I know most of your users don't use milestones anyway.
<slangasek> dannf: (fyi only and to give you the opportunity to disagree; if you and/or infinity feel strongly about this I will dig up instructions on how to test)
<infinity> slangasek: Well, I was going to boot/install/reboot smoke the 4 arches I can do quickly.  If you want to skip s390x based on those other 4 being tested and an assumption about reliability of our process, that's fair.
<infinity> Takes me ~15 to do x86*2 and ppc*2.
<dannf> slangasek: no disagreement
<rcj> infinity: most of our users don't care about milestones, we'll have a daily tomorrow :)
<infinity> s/15/15m/
<infinity> rcj: Right, that's what I figured.  Honestly not sure why you do milestones at all.
<Ukikie> FWIW, got an irssi bugfix incoming.
<slangasek> infinity: the most common boot path for this image is "rip it open on an ftp server and copy the kernel into the HMC", which I don't think mdadm is going to regress
<rcj> infinity, re-spin and delivery for cloud-images would be ~18 hours.  We'll have another significant point for testing once cloud-init changes land to give us sane cloudy behavior with systemd's "predictable" network interface names
<infinity> slangasek: No, true.  Maybe the only smoketest required is to tear open the ISO and verify it's an ISO with files in it. :P
<rcj> infinity, good point in time for us to get clouds to pay attention to the development release and make sure their stuff works. :)
<rcj> and we make sure that our new build/publication infra works before April ;)
<infinity> rcj: Heh, indeed.  Doing beta-2 is valuable, I more wonder why you participate in *every* milestone.
<infinity> rcj: You're the only Canonical/Ubuntu product that does.
<slangasek> yes, would be great if you stopped doing that ;)
<rcj> infinity, we're the base for other things like MAAS.  Juju gets to test on a 'milestone' which means ensuring their 'release' stream is functional, not just 'daily' stream generation and consumption.
<rcj> infinity, which is to say, eh.
<infinity> rcj: Oh, that's fair if they need one blessed image in the release stream to test against.
<rcj> and now we'll have folks running against beta-2 in the release stream until GA rather than using fresh daily images, but you can't win them all
<infinity> Quite.  That's the reason I hate milestones.  I love periodic test cycles, but kinda wish we would just throw away the results.
<infinity> ie: All gather around for a week and test the crap out of everything, but then tell users to keep testing dailies.
<infinity> And never actually "release" alpha/beta images.
<infinity> Cause that seems to encourage people to install old, buggy images.
<rcj> a little postfix breakage on package upgrades might be just enough to move people back to the daily stream
<rcj> Well, we could just tell cloud users to pick up the current daily and just use the release calendar to drive when we poke people to get extra eyes on things.
<infinity> slangasek: I wonder how hard it would be to turn "milestones" into "ISO testing weeks", and stop releasing milestones altogether.
<infinity> The testing bit is clearly important.  The released product is general not something we want people using for long.
<infinity> s/general/generally/
<rcj> infinity, slangasek: I'll bring this up with the team and we can pursue this further here in time for y-series development.
<infinity> Dear britney, please find mdadm and do stuff to it.  Kthx.
<infinity> rcj: Yeah, I think you guys are unique snowflakes here, since people generally use your frequent respins, even on a stable series.
<rcj> infinity, I sure hope they do :)
<infinity> rcj: I'm trying to sort out how to get the rest of the distro to a similar point.  The major sticking point is that "the media" likes having blessed images to review and write terrible things about.
<infinity> (or wonderful things)
<rcj> infinity, I'll bring this up at the next cloud sprint.  Our release notes entry might point at latest daily next time.
<stokachu> could i get a nod on conjure and bigdata? and juju-core too if possible :)
<infinity> stokachu: A nod, as in an acknowlegement that you uploaded them?  Nodding away.
#ubuntu-release 2016-03-25
<infinity> stokachu: A nod, as in an expedited review?  Not today.
<stokachu> infinity: still acceptable after final beta freeze?
<infinity> stokachu: Not even remotely acceptable, but I have a feeling someone's going to run off and get a sabdfl veto after I say that.
<infinity> stokachu: You could certainly save a round trip by getting one of those now.
<stokachu> infinity: i gotta be that guy :(
<infinity> stokachu: Not that this does *not* fit the existing juju SRU exception (which requires extensive migration testing and promises of both quality and stability), so a pretty darned good argument needs to be made for replacing a stable version with a beta that no one seems to trust enough to call final (and, indeed, people originally wanted to hide in universe due to said lack of trust).
<stokachu> infinity: ill just mention you said 'hello'
<infinity> *smirk*
<stokachu> maybe throw a <3 for good measure
<infinity> superm1: ^-- New myth builds.
 * flexiondotorg starts downloading mythbuntu i386
<flexiondotorg> Bear in mind I'm connected to the Internet via short wave radio so you lot may have downloaded and tested before I finish downloading.
<superm1> infinity: kk ,zsyncing shortly
<wxl> flexiondotorg: AX.25?
<superm1> flexiondotorg: you can zsync an ubuntu one into a mythbuntu one
<superm1> they're probably 25-35% the same?
<popey> that sounds like voodoo
<flexiondotorg> superm1, I did the zsync :-)
<superm1> popey: it does, but it works
<superm1> you can also zsync a 32 bit into a 64 bit
<superm1> they're quite a bit less alike
<slangasek> I'm surprised to hear that does anything useful
<slangasek> does that work because zsync is ISO filesystem aware?
<flexiondotorg> superm1, What does success look like?
<superm1> flexiondotorg: first boot can't find a backend because it's not yet configured when you do a VM install
<superm1> but you were able to install successfully
<superm1> (in a VM setting up a backend isn't gonna happen)
<Ukikie> Speaking of zsync, might be useful to add that patch that uses libcurl as the backend, so it can handle https.
<flexiondotorg> What type of install should I do?
<superm1> flexiondotorg: default one is fine
 * flexiondotorg went with default all the way.
<flexiondotorg> superm1, Is that Ubiquity or a forked Ubiquity?
<superm1> flexiondotorg: it's ubiquity with plugins
<flexiondotorg> Never knew that wa possible.
<superm1> forking would be an unmaintanable mess
<flexiondotorg> I'll have to investigate plugins.
<flexiondotorg> Are the plugins separate from the Ubiquity package?
<superm1> flexiondotorg: yeah we keep ours as part of the 'mythbuntu-live-autostart' package
<superm1> but other flavors have done it too
<flexiondotorg> Interesting.
<superm1> edubuntu did i'm pretty sure
<flexiondotorg> superm1, Install completed.
<flexiondotorg> Restarting.
<flexiondotorg> superm1, Right I have a message saying it can't connect to master backend.
<flexiondotorg> Which you say is normal for a VM.
<flexiondotorg> What do I do know to determine "stuff" works?
<superm1> flexiondotorg: well that's better than what was going on before
<superm1> my 64 bit in VM did just as well too now
<superm1> without having/being able to set up a backend supported hardware you shouldn't really be able to do too much more interesting really
<flexiondotorg> OK, so the fact it installed is the important thing.
<flexiondotorg> superm1, Smoke test complete then?
<superm1> flexiondotorg: yeah i would say so
<flexiondotorg> infinity, ^^^
<superm1> yeah 64 bit smoke test looks good as well on my end
<flexiondotorg> superm1, Better mark the ready because infinity has dinner plans or something :-)
<superm1> thanks for the help flexiondotorg
<flexiondotorg> superm1, My pleasure, and as always, I learned something in the process.
<flexiondotorg> ;-)
<superm1> flexiondotorg: if you've got interest in the plugins for ubiquity, come join #ubuntu-installer and you can ask questions
<infinity> slangasek: mdadm publishing to the release pocket now, will be respinning in 10m or so.
<flexiondotorg> superm1, Thanks. That is something I will absolutely be looking into for 16.10.
<slangasek> infinity: ok
<infinity> superm1: Going to mark some successful tests for those images and +1 them, then?
<superm1> Yes
<infinity> \o/
<wxl> we there yet?
<infinity> Nope.
<wxl> you sure we're going to release today? XD
<infinity> It'll happen tonight.  Just lots of grinding going on on cdimage right now.
<wxl> ok, well i'm going to head home. i'll check back later on
 * infinity nods.
<flexiondotorg> I'm sleeping on the sofa. Alarm set for 1 hour.
 * phillw to bed... take care, good people
<rcj> slangasek, can you review https://code.launchpad.net/~rcj/ubuntu-seeds/ubuntu.xenial_cloudimage-keyring/+merge/290099 ?
<rcj> blocking an image build here.
<stgraber> infinity: any reason why we can't drop the release block?
<slangasek> rcj: looking
<infinity> stgraber: Waiting until I smoketest a couple of the server ISOs.  If they look healthy, I'll drop the block.
<stgraber> infinity: ok, cool
 * infinity twiddles his thumbs and watches some QI.
<slangasek> rcj: merged. this touches the server seed, so I think requires a metapackage upload too?
<rcj> slangasek, oh, I'm not certain
<rcj> I will check
<slangasek> rcj: well, I guess it's not blocking your cloud image build, regardless
<infinity> It will need a new meta, yes.
<infinity> The old one was lacking the dep because the package didn't exist.
<slangasek> yes
<infinity> slangasek: You already regenerating, or shall I?
<slangasek> infinity: I'm on it
<flexiondotorg> infinity, Are you fmiliar with the podcast "There's no such thing as a fish?"
<rcj> slangasek, infinity: thanks
<infinity> Ohai.
 * infinity watches four copies of d-i race.
<infinity> I wish we still had UDS, so I could take up an hour-long plenary slot to just yell "DEBDIFF BEFORE YOU UPLOAD" at the crowd over, and over, and over again.
 * flexiondotorg was woken by shouting
<slangasek> oh if you insist
<slangasek> how about if I debdiff after reject?
<infinity> slangasek: Oh, that wasn't aimed at anyone in particular...
<infinity> *cough*
<slangasek> but those files were old and harmless
<slangasek> it said it in the name, see
<slangasek> (reuploaded)
<slangasek> infinity: and how's your Ballmer impression?
<infinity> slangasek: I don't pull off fat, out-of-touch rich dude very well.
<infinity> Mostly due to not being rich.
<infinity> slangasek: New server ISOs look good on the 4 arches I could test.
<slangasek> infinity: excellent
<infinity> Other than some nasty regression in either the ipr or ibm-vscsi driver...
<infinity> I've never had an x86 install beat ppc before.
<infinity> Feels weird.
<flexiondotorg> infinity, So are image being published now or is "other stuff" whirring?
<infinity> flexiondotorg: Working on publishing.
<stgraber> cyphermox: your no change rebuild looks like it contains a change :) (http://launchpadlibrarian.net/249836467/console-setup_1.108ubuntu11_1.108ubuntu12.diff.gz)
<infinity> stgraber: It's no change from a VCS perspective, I suspect.
<cyphermox> stgraber: there is no change; it always ends up rearranging this whenever you try to build that package
<stgraber> ok :) might be worth adding a |sort somewhere in there :)
 * flexiondotorg feeds the mice powering the publishing servers. 
<infinity> It's a lot of stuff to copy around and hash.
<flexiondotorg> :-)
<cyphermox> infinity: can I rebuild d-i for console-setup once it's done building or do you prefer to take care of it if there's some other stuff that needs to change in d-i?
<infinity> cyphermox: There'll be an ABI bump copied into proposed shortly, I'll catch it with that.
<cyphermox> ack
<cyphermox> that's why I was asking
<flexiondotorg> infinity, How are things progressing? Rough ETA?
<infinity> flexiondotorg: Pushing to mirrors.
<infinity> ETA is... When that's done.
<flexiondotorg> Pushing images or archive?
<infinity> images to cdimage frontends.
<flexiondotorg> Just interested in how the process works.
<flexiondotorg> And they are all cloudfront?
<infinity> Basically, we build the full tree on the master cdimage machine to look how we want it, then push to mirrors.
<infinity> No cloudfront for beta.
<flexiondotorg> How many mirrors approx?
<infinity> 4 or 5 cdimage frontends, hundreds of releases mirrors.
<flexiondotorg> OK. And the cdimage frontends only reflect the change when the mirrors have the new stuff?
<infinity> cdimage frontends == cdimage.ubuntu.com, releases mirrors == mirrors of releases.ubuntu.com all over the world.
<infinity> The latter don't matter deeply for this exercise (they matter a lot for final release).
<infinity> But yes, we're waiting for the cdimage frontends to reflect the massive amount of data I just tried to jam at all of them. :P
<flexiondotorg> :-)
<flexiondotorg> Is this self hosted servers or cloud providers?
<stgraber> cdimage.u.c is hosted by Canonical, releases.u.c is hosted by Canonical but also has a bunch of community supported mirrors (universities, ISPs, ...) and then there's cloudfront in front of releases.u.c at release time
<flexiondotorg> stgraber, Thanks.
<flexiondotorg> My day job is large scale server infrastructure. Hence my curiosity.
<infinity> flexiondotorg: These servers are impressive at a hardware level, but the actual mirroring infrastructure is simple as can be.  Just ssh triggers and rsync.
<flexiondotorg> infinity, You using the AES-NI accelerated ciphers for rsync/ssh?
<infinity> flexiondotorg: No, rsync isn't over ssh.
<flexiondotorg> OK
<infinity> flexiondotorg: The ssh trigger goes downstream, then the mirror responds by rsyncing plain from the master.
<flexiondotorg> Right.
<infinity> flexiondotorg: Since the archives and ISO bits are all signed (and all public), there's no need to slow it down over ssh.
<flexiondotorg> Quite.
<infinity> The process pretty much just saturates poor nusakan's (cdimage-master) single GigE link out while pushing to mirrors.
<infinity> Perhaps that machine could do with a 10G link, but we're not usually in a hurry to push. :P
<infinity> (And I'm not sure nusakan's disks could put a dent in a 10G link anyway)
<flexiondotorg> Yeah, more cost effective to LACP multiple GigE.
<flexiondotorg> We've looking a quad channel NVME for some server at work. For that, 10G makes more sense.
<cyphermox> flexiondotorg: fwiw, mate was just as affected by the keyboard issue as other releases (thankfully, otherwise it'd be even more complicated to debug)
<flexiondotorg> cyphermox, OK. Maybe I didn't understand how to reproduce the issue.
<cyphermox> oh, I should rebuild ubiquity too for the new console-setup. it's unlikely to change much, but at least that won't be an issue anymore -- easier to test
<infinity> Oh, FFS, no one made the XenialUpgrades page yet.
<infinity> cyphermox: Want to do me a favour and copy https://help.ubuntu.com/community/WilyUpgrades to https://help.ubuntu.com/community/XenialUpgrades with tweaks?
<cyphermox> sure
<cyphermox> infinity: done: https://help.ubuntu.com/community/XenialUpgrades
<cyphermox> UpgradeNotes will still need a'fixin, though
<infinity> Man, this mirror push is taking longer than I'd hoped.
<cyphermox> ^ only the rebuild for console-setup, that way monday I can hit the ground running, finish debugging console-setup-in-ubiquity, and hopefully fix the oem stuff that is broken, and things will start to be prettier
<cyphermox> oh, oops, wrong bug tags
<cyphermox> infinity: ^ feel free to reject tpm2-tss.
<cyphermox> or not, since there is no bug to close on the ubuntu side right now
<infinity> cyphermox: Too late.
<cyphermox> meh
<cyphermox> infinity: https://bugs.launchpad.net/ubuntu/+bug/1561834 for the FFE I talked about earlier.
<ubot5> Launchpad bug 1561834 in Ubuntu "[FFE] [needs-packaging] tpm2-tss and tpm2-tools" [Undecided,New]
<infinity> stgraber: Is that lxd->Breaks: lxc a file takeover?
<stgraber> infinity: yup
<infinity> stgraber: Then you're missing a Replaces.
<stgraber> infinity: doh
<stgraber> infinity: reject and I'll re-upload with the missing replaces
<infinity> stgraber: Done.
<cyphermox> infinity: updated your stock Reject messages?
<cyphermox> Derpy McDerpface ;)
<infinity> It was about time.
<infinity> And I was inspired by Boaty McBoatface.
<cyphermox> what's that?
<stgraber> really?
<infinity> The best thing that's happened this year, that's what.
<stgraber> infinity: hasn't quite happened yet, but I'm hopeful :)
<infinity> cyphermox: http://www.nytimes.com/2016/03/22/world/europe/boaty-mcboatface-what-you-get-when-you-let-the-internet-decide.html?_r=0
<cyphermox> hell yes!
<infinity> stgraber: Yeah, they'd better go through with it.  It's too good not to.
<cyphermox> stgraber: wanna review my FFE? :D
 * stgraber is looking forward to his second vdsl line next week, 10Mbit upload is starting to feel a bit slow...
<stgraber> cyphermox: for what package?
<cyphermox> tpm2-t{ools,ss}
<stgraber> cyphermox: sure
<cyphermox> new package
<stgraber> infinity: ^ new lxd, this one should suck a bit less
<infinity> stgraber: Sucking less is a good goal.
<stgraber> cyphermox: link?
<cyphermox> https://bugs.launchpad.net/ubuntu/+bug/1561834
<ubot5> Launchpad bug 1561834 in Ubuntu "[FFE] [needs-packaging] tpm2-tss and tpm2-tools" [Undecided,New]
<infinity> stgraber: Changelog says "start lxd.service after lxc-net.service", service file says "after lxc.server".  Which one's wrong?
<cyphermox> I wonder if the build logs go to /dev/null if I delete the PPA
<stgraber> infinity: ah yeah, I was lazy there :) I have a massive packaging patchset in git that's stacked over that upload which does change it from lxc.service to lxc-net.service and since both will technically work I didn't want to have to deal with the rebase :)
<stgraber> infinity: I'm happy to re-upload and deal with the rebase but both names will work and the next upload will switch it to lxc-net.service (which is a bit more right but effectively the same as far as timing goes)
<infinity> stgraber: Kay.  Just tell me this works as written, then. :P
<stgraber> works fine
<infinity> Check.
<stgraber> yay, a bit less fighting with git dpm for me :)
<stgraber> infinity: hmm, so I thought we said you didn't need a FFe for new packages, did that change or is cyphermox just not aware?
<stgraber> unseeded package that is
<cyphermox> I was not aware, I just checked the wiki
<stgraber> I think for a while we've applied the "adding stuff to the archive isn't causing a feature change" rule, but adding stuff late may not make it due to lack of time on the archive admin team (due to overlap with the release team)
<cyphermox> right
<cyphermox> well I obviously couldn't help anyway, can't review my own package
<infinity> Whoo, the rsyncs finally finished.
<infinity> Man, what a long day.
<infinity> slangasek: You around to moderate?
<slangasek> infinity: yes
<infinity> Then mail sent.
<infinity> flexiondotorg: Since you seem to be staying up out of some odd sense of self-loathing, it's released!
 * Kamilion sets loose the dogs of torrent
<slangasek> infinity: rejecting, s/Utopic/Xenial/ please
<infinity> slangasek: err, srsly?
<slangasek> either that or s/Utopic/Ubuntu/, not sure which you meant :)
<infinity> Hah.  No, that was probably a stray utopic.  I guess.  Or maybe I can't type Ubuntu.  I have no idea.
<infinity> I really like unicorns?
 * tsimonq2 pats infinity on the back for using the oxford comma :D
<infinity> slangasek: Try again?
<slangasek> "Xutopic Xerus"?
<slangasek> (kidding)
<infinity> *glare*
<slangasek> approved
 * infinity turns dailies back on before he long weekends.
 * Kamilion races to beat the http crowd for the i386 image... already seeding the amd64. http://puu.sh/nT6qc/63194dfb1a.png
<infinity> slangasek: So, the best part about that is that was a copy/paste from Wily Final Beta.
<stgraber> :)
<infinity> slangasek: Including the Utopic string. :P
<stgraber> ^ that's the lxdbr0 thing I mentioned earlier, well, stage 1 of that (all the scripts but not switching everyone over yet)
<stgraber> I tested it with a clean package install on xenial and on upgrade on xenial (to make sure it didn't switch over to the new bridge when it doesn't have to). Then did the same on trusty to test upstart as we upload all our xenial packages to trusty-backports too.
<infinity> stgraber: Too tired and headachey to review that, I'll grab it tomorrow if no one else does.
 * infinity closes the laptop and walks off.
<stgraber> infinity: fair enough, I'm EODing now too. Working tomorrow and Monday though so I'll try to keep the queue kinda reasonable given that I expect a lot of folks to be out at least one of the two days.
 * infinity opens the laptop again when he remembers it's his DLNA server, but vows to ignore IRC. :P
<stgraber> :)
<willcooke> I'm only seeing Server downloads, no Desktop images at all here:  http://cdimages.ubuntu.com/ubuntu/releases/16.04/beta-2/
<willcooke> also this picture 404s: http://cdimages.ubuntu.com/ubuntu/cdicons/list.png
<willcooke> is this just a wait-for-it-to-sync issue?
<lotuspsychje> willcooke: http://releases.ubuntu.com/16.04/
<willcooke> superm1, if you have release notes for Mythbuntu could you add a link here:  https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#Official_flavours
<stokachu> stgraber: fix the changelog
<stokachu> fixed*
<bladernr> Hey gang, just a quick question, is the beta announced last night the "final beta" or do you think there will be one more before RC?
<krytarik> bladernr: You mean like Beta 3? :P  Nope.
<lotuspsychje> bladernr: rc wont be published, now its waiting until final
<bladernr> krytarik: lotuspsychje thanks.  That's exactly what I needed to know :)
<sil2100> o/
<lotuspsychje> hey guys
<sil2100> Hello release team! We would like to poke about accepting the recent qtmultimedia upload - it's basically just a no-change rebuild as part of a ubuntu-touch landing
<sil2100> (no-op really)
<lotuspsychje> anyone know why the repos still have bumblebee, as we nog have nvidia-prime?
<lotuspsychje> *now
<jhodapp> anyone around that can accept qtmultimedia quickly as it's blocking a critical landing for ubuntu touch? (same as sil2100's request)
<stgraber> coreycb: do you have a FFe for python-pycadf, python-pyeclib and stevedore? they all seem to be major upstream releases that are only in experimental
<infinity> stgraber: Hey, if you want me to review that lxd, can I trade you for the cloud-init upload that makes my eyes bleed? :)
<stgraber> infinity: sure
<kenvandine> can someone please accept qtmultimedia ?
<infinity> kenvandine: Done 5 minutes before you asked, according to the bot.
<infinity> (You're welcome)
<kenvandine> infinity, thanks!
<kenvandine> i hadn't seen it from the bot and unity took a dive right after i asked :/
 * infinity goes back to long weekending for a while.
<kenvandine> infinity, enjoy!
<jderose> tjaalton: fyi, i got caught up putting out other fires for now, so it's going to be a bit till i can bisect xorg-server. so hopefully in the mean time you might feel that's a super fun thing to do :P
<stgraber> that cloud-init diff looked way scarier until I noticed that 80% of it was due to a svg file being removed :)
<flexiondotorg> infinity, Thanks for your help yesterday.
<flexiondotorg> Sorry I dropped off abruptly but it was 4am for me. I needed sleep.
<stgraber> infinity: have you been looking at lxd?
<tsimonq2> Fixed the FTBFS with libquvi in main, figuring out how to upload it and get it sponsored now, but works in my local schroot/sbuild setup.
<tsimonq2> nvm, build error this time :/
<tsimonq2> the underlying problem is that libquvi-scripts is in proposed, and my sbuild doesn't want to grab that from proposed although it takes other packages from proposed... https://launchpadlibrarian.net/240413333/buildlog_ubuntu-xenial-amd64.libquvi-scripts_0.9.20131130-1.1_BUILDING.txt.gz is the build log
<tsimonq2> !info libquvi-scripts
<ubot5> libquvi-scripts (source: libquvi-scripts): library for parsing video download links (Lua scripts). In component main, is extra. Version 0.4.21-2 (wily), package size 31 kB, installed size 253 kB
<tsimonq2> !info libquvi-scripts xenial
<ubot5> libquvi-scripts (source: libquvi-scripts): library for parsing video download links (Lua scripts). In component main, is extra. Version 0.4.21-2 (xenial), package size 31 kB, installed size 253 kB
<tsimonq2> !info libquvi-scripts xenial-proposed
<ubot5> Package libquvi-scripts does not exist in xenial-proposed
<tsimonq2> that's weird... 0.9.20131130-1.1 is the version in proposed...
<tsimonq2> *that* might be the problem...
<tsimonq2> https://launchpad.net/ubuntu/+source/libquvi-scripts/0.9.20131130-1.1 for reference
<tsimonq2> any help is appreciated :)
<tsimonq2> !info libquvi-scripts-0.9 xenial-proposed
<ubot5> libquvi-scripts-0.9 (source: libquvi-scripts): library for parsing video download links (Lua scripts). In component main, is extra. Version 0.9.20131130-1.1 (xenial-proposed), package size 43 kB, installed size 266 kB
<tsimonq2> aha
<tsimonq2> bug 1547395 is the culprit. libquvi trys to install libquvi-scripts-0.9, which has that error. I thought the fix would be to change the dependency to libquvi-scripts, but that's the version in release, so that wouldn't have worked...and this is why you always read the bugs on the FTBFS tracker! I just looked and the bug is listed there...
<ubot5> bug 1547395 in luasocket (Ubuntu) "MIR: new dependencies for libquvi-scripts / libquvi" [Undecided,New] https://launchpad.net/bugs/1547395
<tsimonq2> sorry for wasting your time :)
#ubuntu-release 2016-03-26
<roaksoax> howdy! I have a suspicion that squid3 is broken in https://launchpad.net/ubuntu/+source/squid3/3.5.12-1ubuntu1
<roaksoax> it is currently in proposed, but if it hits main it may break eveyrbody
<roaksoax> or maybe just a false alarm
<roaksoax> seems broken
<roaksoax> http://pastebin.ubuntu.com/15504467/
<infinity> roaksoax: You're not wrong.  See the blocking bug.  I was experimenting locally with fixing it.
<infinity> stgraber: If by "looking at lxd" you mean "passing out and sleeping the afternoon away", then yes.  That's what I was doing.
<stgraber> :)
<infinity> stgraber: You misspelled CIDR as CDR.  Also, wow, that shell function is something else.
<stgraber> infinity: well at least I did it consistently, I'm calling it with the typo too :)
<infinity> stgraber: Indeed. :)
<infinity> stgraber: Oh, nice, you have an inverse of the function as well.  I need to save these for later use.
<stgraber> :)
<infinity> And the inverse is spelled correctly. :P
<stgraber> yeah, we store cidr only in debconf (because it's 2016) but the script we use to bring the bridge up is stuck a decade ago so its config file needs it as a good old mask
<infinity> Well, that was obviously unreviewable according the general laws of code review, but nothing obviously broken jumped out.
<stgraber> and then since we want to be nice and load whatever the user wrote over the file we generated, we have to do the conversion the other way around when feeding debconf with whatever's in the file
<stgraber> infinity: yeah, took me about a week to get all that shit right, or at least sufficiently right that all my test cases passed :)
<stgraber> nice, now we just need to get the Juju folks to merge tych0's branch to support that thing and then we can flip the switch and stop having lxd pull all of lxc and lxcbr0 everywhere. That should shrink the server ISO and cloud images a bit and most importantly, those two won't have a lxcbr0 bridge around that most people won't use (and that's potentially masking some useful subnet)!
<infinity> stgraber: And yeah, "it's 2016" is usually my claimed excuse for preferring CIDR too, but the real reason is just that zero through thirty-two is a lot simpler than remembering the binary mask intervals.
<stgraber> yeah, not too bad so long as you deal with just /8, /16, /24 and /32 but anything else is a bit painful :)
<infinity> Quite.
<infinity> Most of my subnets are .224, .240, and .248, and counting backwards in binary hurts my brain.
<stgraber> well, I'm mostly dealing with IPv6 these days and I'm quite happy we have CIDR because as much as some network gear is trying to convince me that 2607:f2c0:f00f:2700:e88e:6217:1c70:5a55/ffff:ffff:ffff:ffff:0000:0000:0000:0000 is valid, it's really long and stupid
<infinity> Hahaha, yes.
<stgraber> (got a new VDSL modem which doesn't do CIDR for IPv6 and also doesn't do shortening, so :: didn't save me either, I had to type every single zero...)
<Logan> do completely new packages need an FFe? or will they just be reviewed in the NEW queue?
<Logan> also I feel like dogecoin should not be in Xenial for the same reasons as the bitcoin removal
<teward> Logan: I agree with your assessment, though I would expand that to include any cryptocurrency
<teward> (though I have no real say, I believe)
<infinity> Logan: Good catch.  Removed and blacklisted.
<teward> infinity: we don't have any other cryptocurrencies lying around do we?
<infinity> teward: Dunno.
<infinity> teward: A quick search on "coin" also pulls up cgminer and bfgminer, but I don't know enough about bitcoin to know if "miners" are as useless as wallets/client in the face of network changes.
<infinity> I certainly see no whiney Debian bugs about either one.
<teward> infinity: i don't think the miners are an issue, they only rely on hashing algos
<teward> rather than the actual cryptocurrencies
<teward> though i'm still partial to removing those because new mining hardware won't be caught by older miners
<teward> though that logic would apply to Trusty being removed completely from existence if we wanted every package (kernel) to support every new hardware
<teward> (this is what HWE stacks were for)
<infinity> Yeah, I don't think removing on those grounds would make sense.
<teward> mhm
<teward> at first glance into Unstable I don't see anything but bitcoin,litecoin,dogecoin
<teward> and if those are all removed and blacklisted, then we should be fine
<teward> and we leave the miners alone unless we find some big reason to remove
<infinity> Yeah, those are all blacklisted.
<teward> then I think we're all set :)
<Logan> infinity: thanks!
#ubuntu-release 2016-03-27
<infinity> slangasek: That ipmitool upload was redundant with the Debian upload that did s/c99/gnu99/
<infinity> slangasek: Neither or which seem to actually fix the problem...
<infinity> Or maybe I read the header wrong...
<infinity> slangasek: Well, the second one worked. :P
<infinity> But man that source is a mess.
<infinity> grep a build log for "implicit" and be prepared to cry.
<tsimonq2> infinity: aww come on, it's not THAT bad :D http://paste.ubuntu.com/15516741/
<tsimonq2> only 21 different lines... :D
<slangasek> infinity: so c99->gnu99 definitely didn't make getpass() available.  Somehow it worked on amd64 but not on s390x.
<slangasek> that change did fix other missing prototypes, but not this one - probably because getpass() is so crap
<slangasek> stokachu: I've looked at the conjure package in NEW; I think I'm going to reject it on the grounds that it has an unsatisfiable build-dependency on bundle-placer which I don't see anywhere
<slangasek> stokachu: (it has other issues too, which we can discuss when you're around; that's the only one that's a blocker)
<stokachu> slangasek: OK I can fix the build dep, what were the other issues
<slangasek> stokachu: debian/copyright's header seems to point to wrong things (upstream-name and source); you don't need a separate 'Files: debian/*' stanza if everything is under the same license and copyright holder; and there are some grammar fixes to be made to the package description in debian/control ("apt-installable"; "conjure's"; "Conjure, an interface to")
<slangasek> anyone know anything about the stack of ruby test failures in update_excuses?  infinity ?
<slangasek> (some way for me to give them back that would get them to clear?)
<infinity> I know nothing.  Is it still that gemspec thing?
<infinity> I had the impression that gem2deb 0.30.1 should have addressed that, but clearly not.
<infinity> Likely warrant real investigation rather than haphazard syncing and hoping.
<infinity> s/warrant/warrants/
#ubuntu-release 2017-03-20
<cpaelzer> I just learned that xnox enjoys some snow this week, it would be great if anybody else could take a look at sponsoring bug 1673491
<ubot5> bug 1673491 in libnl3 (Ubuntu) "[Zesty] libnl3 Segmentation fault in sriov environments" [Critical,New] https://launchpad.net/bugs/1673491
<cpaelzer> is prepared via bileto and for zesty
<apw> cpaelzer, looking
<apw> cpaelzer, ok punched publish
<cpaelzer> thanks, tracking proposed later then
<acheronuk> apw: hi. can akonadi 4:16.04.3-0ubuntu4 be removed from zesty proposed? that rebuild and patch update on an old version fails tests too badly, and the issue it was to solve is fixed elsewhere now anyway
<apw> acheronuk, and you are sure none of its reverse-depends have been uploaded since it hit -proposed
<acheronuk> apw: that is just our PIM stack and zanshin, and we have pushed no updates for those since
<apw> okies
<acheronuk> apw: thx :)
<apw> britney seems to agree that nothing is changed, so done
<apw> acheronuk, don't forget that that version is dead to you forever
<acheronuk> understood
<sil2100> rbasak: hey! I was wondering, did you do SRU reviews of syncs before? I wonder what's the best way of doing those
<sil2100> rbasak: the sru-review script doesn't seem to work
<apw> sil2100, you have to use queue fetch to get the package and diff it locally, then use sru-review --no-diff
<apw> sil2100, it is very annoying
<sil2100> Ah!
<sil2100> apw: thanks!
<sil2100> Looks like we might need to look into improving the sru-review tool for the future then
<apw> sil2100, there has long been talk of having diffs in launchpad for copies, so it has never happened
<sil2100> Would be useful, since we have this Bileto tool that operates on package synces that people out of the desktop/personal teams start using nowadays as well
<sil2100> So I would expect more and more SRUs with package copies around
<apw> sil2100, yep, though you get used to just diffing them out of the queue manually
<apw> sil2100, its the same idiom every time
<rbasak> sil2100: I have some tooling around our git workflow work that allows easier reviews from the queue. I'm not sure it'll work with syncs right now, but my plan is to spend effort on that tooling rather than on sru-review, etc.
<rbasak> I'd prefer to make the functionality in sru-review/release/accept available from my git queue viewing tool instead.
<Mirv> Trevinho: finally, my second try at fixing camitk now allowed qtbase to migrate to release pocket
<fossfreedom_> All: re the zesty universe package Terminix - upstream has changed its name to Tilix due to trademark issue.  Debian has apparently uploaded to unstable the newly renamed package. Should Ubuntu follow to resolve perceived trademark issue? http://www.mail-archive.com/debian-release@lists.debian.org/msg102587.html
<apw> fossfreedom_, cirtainly we should consider it depending how close the renamed version is to ours
<fossfreedom_> apw: same considerations as Debian - our Zesty version is v1.4.2 - Debian has 1.5.2 ... and have just uploaded "Tilix" at v1.5.4
<fossfreedom_> seems to be a large number of changes between ours and "Tilix" at v1.5.4
<tjaalton> could a release team member review 1671799? the -libinput issue dino99 reports doesn't seem to be a widespread issue, I can't repro it
<tjaalton> bug 1671799
<ubot5> bug 1671799 in xorg-server (Ubuntu) "FFe: xserver 1.19.3" [Undecided,Confirmed] https://launchpad.net/bugs/1671799
<sil2100> bdmurray: hey! I took the liberty to release your update-manager SRU from -proposed to -updates, since I wanted to review the other updates-* pair of SRUs in the queue
<slashd> hi SRU, I'm currently working on a case (no LP bug yet).... about an OpenSSL bug on new AMD CPU (Ryzen) release last Feb ... where the SHA Extension routine is not called on AMD Ryzen cores. My question is since this look like H/W enablement ... do you think this could be eligible for SRU in stable release such like Xenial ? or this will only be accepted for devel release ? This is a new CPU but Xenial is there for a
<slashd> couple of years still so maybe future Xenial user running Ryzen CPU may benefit on this eventually...
<apw> slashd, for me some new functionality like that is ok as long as it is very self-contained so easy to review and confirm is only used on the new h/w
<apw> one of our main goals is to avoid regressions
<slashd> apw, make sense, thanks for your input
<rbasak> The SRU policy does explicitly permit hardware enablement in an LTS IIRC, though I'd expect ~ubuntu-sru to be involved in mitigating risk and making the final risk decision, FWIW.
<apw> rbasak, right, it would have to be carefully considered once we can see what the diff actually is
<slashd> rbasak, apw ack, will communite the info with the proper group
<apw> with a much greater level of testing and scrutiny than a regular fix only sru
<slashd> apw, rbasak, FYI I have requested the new CPU from our partner to test
<slashd> in deep
<slashd> thanks apw, rbasak
<bdmurray> sil2100: thanks, did you look at the update-notifier upload?
<sil2100> bdmurray: yeah, will be finishing both in a moment, just got back from lunch
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (yakkety-proposed) [1:16.10.9]
<sil2100> bdmurray: both accepted just now
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (yakkety-proposed) [3.175.2]
<bdmurray> sil2100: thanks
-queuebot:#ubuntu-release- New source: retro-gtk (zesty-proposed/primary) [0.10.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: cinder (xenial-proposed/main) [2:8.1.1-0ubuntu1 => 2:8.1.1-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cinder (yakkety-proposed/main) [2:9.1.2-0ubuntu1 => 2:9.1.2-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-14.16] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-14.16]
-queuebot:#ubuntu-release- New binary: gnome-getting-started-docs [amd64] (zesty-proposed/universe) [3.24.0-1ubuntu1] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-trusty [amd64] (precise-proposed/main) [3.13.0-114.161~precise1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-114.161] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-69.90] (core, kernel)
<acheronuk> urgh
<tsimonq2> infinity: Hi. :)
<infinity> Guten Tag.
<tsimonq2> infinity: Sooo... it's Final Beta week?
<tsimonq2> :)
<infinity> Yeah, I know.  And I know that my alignment with UTC is a tiny bit off.  I'll send the freeze announcement this afternoovening.
<tsimonq2> Ok
<infinity> Just trying to test a final glibc upload before I do that, so I'm not breaking my own freeze. :P
<tsimonq2> infinity: I was just wondering what your plans are.
<tsimonq2> Gotcha.
<tsimonq2> infinity: But glibc is a minor package, right? Can't hurt to break the freeze on a package as little as that. </troll> :P
<tsimonq2> infinity: Image builds follow soon after that, correct?
 * infinity nods.
<infinity> Ish.
<tsimonq2> Ok, thanks :)
<Trevinho> Mirv: good one, thanks!
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.8.0-43.46~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: update-notifier (xenial-proposed/main) [3.168.3 => 3.168.4] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: update-manager (xenial-proposed/main) [1:16.04.5 => 1:16.04.6] (core)
-queuebot:#ubuntu-release- Unapproved: update-notifier (trusty-proposed/main) [0.154.1ubuntu2 => 0.154.1ubuntu3] (kubuntu, ubuntu-desktop, ubuntu-server)
 * infinity drops powerpc from all the flavour metas before the freeze.
<infinity> La la la.
#ubuntu-release 2017-03-21
-queuebot:#ubuntu-release- Unapproved: iscsitarget (trusty-proposed/universe) [1.4.20.3+svn499-0ubuntu2.1 => 1.4.20.3+svn499-0ubuntu2.2] (no packageset)
<Ionic> hey, I'm looking for the repository that holds the scripts that are used to build the official images served by releases.ubuntu.com
<infinity> Ionic: It's a muddy and complicated pipe of live-build (via livecd-rootfs) in launchpad-buildd, published by launchpad, followed by debian-cd, wrapped in cdimage.
<infinity> https://launchpad.net/ubuntu/+source/livecd-rootfs
<infinity> https://launchpad.net/ubuntu/+source/live-build
<infinity> https://code.launchpad.net/launchpad-buildd
<infinity> https://code.launchpad.net/launchpad
<infinity> https://code.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu
<infinity> https://code.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline
<Ionic> thanks infinity
<cyphermox> hmm, means I can retire this space heater. yay
<infinity> They make nice end tables.
<cyphermox> kind of heavy
<infinity> You move your end tables frequently?
<cyphermox> yup
<cyphermox> from end to end.
<infinity> Weirdo.
<cyphermox> sometimes I make forts, too
<infinity> A good blanket fort required heavy objects to weigh down the corners.
<infinity> s/required/requires/
<cyphermox> heh
* infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.5, Xenial 16.04.2, Yakkety 16.10 | Archive: final beta freeze | Zesty Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-welcome (zesty-proposed/universe) [17.04.7 => 17.04.8] (ubuntu-mate)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (xenial-proposed/main) [4.10.0-13.15~16.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mate-menu (zesty-proposed/universe) [17.04.2-0ubuntu1 => 17.04.2-0ubuntu2] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-artwork (zesty-proposed/universe) [17.04.6 => 17.04.7] (ubuntu-mate)
<flexiondotorg> Please unblock ubuntu-mate-welcome/17.04.8
<flexiondotorg> Please unblock mate-menu/17.04.2-0ubuntu2
<flexiondotorg> Please unblock ubuntu-mate-artwork/17.04.7
-queuebot:#ubuntu-release- Unapproved: gnome-logs (zesty-proposed/universe) [3.23.91-0ubuntu1 => 3.24.0-0ubuntu1] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: sound-juicer (zesty-proposed/universe) [3.23.90-0ubuntu1 => 3.24.0-0ubuntu1] (desktop-extra)
-queuebot:#ubuntu-release- Unapproved: update-manager (trusty-proposed/main) [1:0.196.22 => 1:0.196.23] (core)
-queuebot:#ubuntu-release- Unapproved: accepted mate-menu [source] (zesty-proposed) [17.04.2-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-welcome [source] (zesty-proposed) [17.04.8]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-artwork [source] (zesty-proposed) [17.04.7]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-logs [source] (zesty-proposed) [3.24.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted sound-juicer [source] (zesty-proposed) [3.24.0-0ubuntu1]
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Zesty Beta 2] (20101020ubuntu498) has been added
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Zesty Beta 2] (20101020ubuntu498) has been added
-queuebot:#ubuntu-release- Builds: Netboot armhf [Zesty Beta 2] (20101020ubuntu498) has been added
-queuebot:#ubuntu-release- Builds: Netboot i386 [Zesty Beta 2] (20101020ubuntu498) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Zesty Beta 2] (20101020ubuntu498) has been added
-queuebot:#ubuntu-release- Builds: Netboot s390x [Zesty Beta 2] (20101020ubuntu498) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- Unapproved: systemd (yakkety-proposed/main) [231-9ubuntu3 => 231-9ubuntu4] (core)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-trusty [amd64] (precise-proposed) [3.13.0-114.161~precise1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-114.161]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (xenial-proposed) [4.10.0-13.15~16.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-69.90]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.8.0-43.46~16.04.1]
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Zesty Beta 2] (20170321.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Zesty Beta 2] (20170321.1) has been added
-queuebot:#ubuntu-release- Unapproved: coturn (zesty-proposed/universe) [4.5.0.5-1 => 4.5.0.5-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted coturn [source] (zesty-proposed) [4.5.0.5-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected cgroup-lite [source] (yakkety-updates) [1.11ubuntu0.16.10.1]
-queuebot:#ubuntu-release- Unapproved: odin (zesty-proposed/universe) [2.0.2-0.3 => 2.0.3-0.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Zesty Beta 2] (20170321.1) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Zesty Beta 2] (20170321.1) has been added
-queuebot:#ubuntu-release- Unapproved: accepted odin [sync] (zesty-proposed) [2.0.3-0.1]
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- New: accepted ukui-session-manager [source] (zesty-proposed) [1.0.0]
-queuebot:#ubuntu-release- New binary: ukui-session-manager [amd64] (zesty-proposed/none) [1.0.0] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-session-manager [i386] (zesty-proposed/none) [1.0.0] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-session-manager [ppc64el] (zesty-proposed/none) [1.0.0] (no packageset)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- New binary: ukui-session-manager [s390x] (zesty-proposed/none) [1.0.0] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-session-manager [arm64] (zesty-proposed/none) [1.0.0] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-session-manager [armhf] (zesty-proposed/none) [1.0.0] (no packageset)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Zesty Beta 2] (20170321) has been added
-queuebot:#ubuntu-release- New: accepted ukui-menu [source] (zesty-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected ukui-session-manager [amd64] (zesty-proposed) [1.0.0]
-queuebot:#ubuntu-release- New: rejected ukui-session-manager [armhf] (zesty-proposed) [1.0.0]
-queuebot:#ubuntu-release- New: rejected ukui-session-manager [ppc64el] (zesty-proposed) [1.0.0]
-queuebot:#ubuntu-release- New: rejected ukui-session-manager [arm64] (zesty-proposed) [1.0.0]
-queuebot:#ubuntu-release- New: rejected ukui-session-manager [s390x] (zesty-proposed) [1.0.0]
-queuebot:#ubuntu-release- New: rejected ukui-session-manager [i386] (zesty-proposed) [1.0.0]
-queuebot:#ubuntu-release- New binary: ukui-menu [amd64] (zesty-proposed/none) [1.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ukui-session-manager [source] (zesty-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: ukui-session-manager [ppc64el] (zesty-proposed/none) [1.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-session-manager [amd64] (zesty-proposed/none) [1.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-session-manager [i386] (zesty-proposed/none) [1.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-session-manager [arm64] (zesty-proposed/none) [1.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-session-manager [s390x] (zesty-proposed/none) [1.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-session-manager [armhf] (zesty-proposed/none) [1.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gnome-dvb-daemon [sync] (zesty-proposed) [1:0.2.91~git20170110-2]
-queuebot:#ubuntu-release- New: accepted golang-github-google-certificate-transparency [amd64] (zesty-proposed) [0.0~git20160709.0.0f6e3d1~ds1-1]
-queuebot:#ubuntu-release- New binary: gnome-dvb-daemon [ppc64el] (zesty-proposed/universe) [1:0.2.91~git20170110-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-dvb-daemon [amd64] (zesty-proposed/universe) [1:0.2.91~git20170110-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-dvb-daemon [s390x] (zesty-proposed/universe) [1:0.2.91~git20170110-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-dvb-daemon [i386] (zesty-proposed/universe) [1:0.2.91~git20170110-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-dvb-daemon [arm64] (zesty-proposed/universe) [1:0.2.91~git20170110-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-dvb-daemon [armhf] (zesty-proposed/universe) [1:0.2.91~git20170110-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted ukui-screensaver [source] (zesty-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: ukui-screensaver [ppc64el] (zesty-proposed/none) [1.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-screensaver [amd64] (zesty-proposed/none) [1.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-screensaver [i386] (zesty-proposed/none) [1.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-screensaver [arm64] (zesty-proposed/none) [1.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-screensaver [s390x] (zesty-proposed/none) [1.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-screensaver [armhf] (zesty-proposed/none) [1.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: rejected ukui-control-center [source] (zesty-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: golang-github-cloudflare-cfssl [i386] (zesty-proposed/universe) [1.2.0+git20160825.89.7fb22c8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-cloudflare-cfssl [s390x] (zesty-proposed/universe) [1.2.0+git20160825.89.7fb22c8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-cloudflare-cfssl [ppc64el] (zesty-proposed/universe) [1.2.0+git20160825.89.7fb22c8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-cloudflare-cfssl [amd64] (zesty-proposed/universe) [1.2.0+git20160825.89.7fb22c8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-cloudflare-cfssl [armhf] (zesty-proposed/universe) [1.2.0+git20160825.89.7fb22c8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-cloudflare-cfssl [arm64] (zesty-proposed/universe) [1.2.0+git20160825.89.7fb22c8-1] (no packageset)
-queuebot:#ubuntu-release- New: rejected ukui-indicators [source] (zesty-proposed) [1.0.0-0ubuntu1]
<handsome_feng> Hi, Could someone in release team help to accept the FFe request: bug: #1663477, we need the FFe acked, Thank you!
<ubot5> bug 1663477 in Ubuntu "[FFe] UKUI desktop environment" [Wishlist,In progress] https://launchpad.net/bugs/1663477
-queuebot:#ubuntu-release- Unapproved: vala (zesty-proposed/universe) [0.34.6-1 => 0.34.7-1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- New: accepted ukui-desktop-environment [source] (zesty-proposed) [1.0.0]
-queuebot:#ubuntu-release- New binary: ukui-desktop-environment [amd64] (zesty-proposed/none) [1.0.0] (no packageset)
-queuebot:#ubuntu-release- New: accepted ukui-menu [amd64] (zesty-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-desktop-environment [amd64] (zesty-proposed) [1.0.0]
-queuebot:#ubuntu-release- New: accepted ukui-session-manager [amd64] (zesty-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-session-manager [armhf] (zesty-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-session-manager [ppc64el] (zesty-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-session-manager [arm64] (zesty-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-session-manager [s390x] (zesty-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-session-manager [i386] (zesty-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-screensaver [amd64] (zesty-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-screensaver [armhf] (zesty-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-screensaver [ppc64el] (zesty-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-screensaver [arm64] (zesty-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-screensaver [s390x] (zesty-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-screensaver [i386] (zesty-proposed) [1.0.0-0ubuntu1]
<caribou> Hi, when doing an SRU to a specific release, what's the rule regarding other releases ? i.e. if the but has been raised on Xenial, should Yakkety be systematically SRUed as well ?
<sil2100> caribou: hey, the fix should generally be targetted for all currently ongoing releases that the bug affects
<sil2100> Generally
<caribou> sil2100: ok, wasn't sure. I vaguely remember being told to only fix the release in which the bug was brought up
<caribou> sil2100: but makes more sense to fix it everywhere
<cpaelzer> Hi release (and SRU in particular) experts - I have uploaded a Yakkety libvirt SRU last week which is still in unapproved. Now I have the next Yakkety SRU ready, would it make sense to combine them?
<cpaelzer> and if yes what would be the right way to do so - reject one but accept the other which includes the first?
-queuebot:#ubuntu-release- Unapproved: libvirt (zesty-proposed/main) [2.5.0-3ubuntu4 => 2.5.0-3ubuntu5] (ubuntu-server, virt) (sync)
<cpaelzer> which not to be confused is a different one than the one just popping up on z-p unapproved :-)
<caribou> cpaelzer: my pick would be to ask for rejection of the previous one & bundle both together
<caribou> but I'm not an expert
<caribou> just playing one on T.V.
-queuebot:#ubuntu-release- New: accepted gnome-dvb-daemon [amd64] (zesty-proposed) [1:0.2.91~git20170110-2]
-queuebot:#ubuntu-release- New: accepted gnome-dvb-daemon [armhf] (zesty-proposed) [1:0.2.91~git20170110-2]
-queuebot:#ubuntu-release- New: accepted gnome-dvb-daemon [ppc64el] (zesty-proposed) [1:0.2.91~git20170110-2]
-queuebot:#ubuntu-release- New: accepted gnome-getting-started-docs [amd64] (zesty-proposed) [3.24.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-github-cloudflare-cfssl [arm64] (zesty-proposed) [1.2.0+git20160825.89.7fb22c8-1]
-queuebot:#ubuntu-release- New: accepted golang-github-cloudflare-cfssl [i386] (zesty-proposed) [1.2.0+git20160825.89.7fb22c8-1]
-queuebot:#ubuntu-release- New: accepted golang-github-cloudflare-cfssl [s390x] (zesty-proposed) [1.2.0+git20160825.89.7fb22c8-1]
-queuebot:#ubuntu-release- New: accepted gnome-dvb-daemon [arm64] (zesty-proposed) [1:0.2.91~git20170110-2]
-queuebot:#ubuntu-release- New: accepted gnome-dvb-daemon [s390x] (zesty-proposed) [1:0.2.91~git20170110-2]
-queuebot:#ubuntu-release- New: accepted golang-github-cloudflare-cfssl [armhf] (zesty-proposed) [1.2.0+git20160825.89.7fb22c8-1]
-queuebot:#ubuntu-release- New: accepted gnome-dvb-daemon [i386] (zesty-proposed) [1:0.2.91~git20170110-2]
-queuebot:#ubuntu-release- New: accepted golang-github-cloudflare-cfssl [ppc64el] (zesty-proposed) [1.2.0+git20160825.89.7fb22c8-1]
-queuebot:#ubuntu-release- New: accepted golang-github-cloudflare-cfssl [amd64] (zesty-proposed) [1.2.0+git20160825.89.7fb22c8-1]
<infinity> caribou: Depends on the nature of the bug.  If it's purely cosmetic/"polish", then it might be acceptable to only fix it in an LTS, and the devel series.
<infinity> caribou: But any actual, y'know, bug (ie: broken behaviour), if you fix it in X, but not Y, people upgrading from X to Y suffer a regression, which is Tres Wrong.
<caribou> infinity: k
-queuebot:#ubuntu-release- Unapproved: gcc-defaults-ports (zesty-proposed/universe) [1.160ubuntu1 => 1.166ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gcc-defaults (zesty-proposed/main) [1.165ubuntu3 => 1.166ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-defaults-ports [source] (zesty-proposed) [1.166ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-defaults [source] (zesty-proposed) [1.166ubuntu1]
-queuebot:#ubuntu-release- New binary: gcc-defaults-ports [amd64] (zesty-proposed/universe) [1.166ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gcc-defaults-ports [amd64] (zesty-proposed) [1.166ubuntu1]
-queuebot:#ubuntu-release- Unapproved: yaml-cpp (zesty-proposed/universe) [0.5.2-4 => 0.5.2-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted yaml-cpp [source] (zesty-proposed) [0.5.2-4ubuntu1]
-queuebot:#ubuntu-release- New: rejected gnome-games-app [source] (zesty-proposed) [3.23.91-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected retro-gtk [source] (zesty-proposed) [0.9.91-0ubuntu1]
-queuebot:#ubuntu-release- New binary: swarmkit [amd64] (zesty-proposed/universe) [1.12.0+git20170111.763.296fcfcf-1] (no packageset)
-queuebot:#ubuntu-release- New binary: swarmkit [ppc64el] (zesty-proposed/universe) [1.12.0+git20170111.763.296fcfcf-1] (no packageset)
-queuebot:#ubuntu-release- New binary: swarmkit [i386] (zesty-proposed/universe) [1.12.0+git20170111.763.296fcfcf-1] (no packageset)
-queuebot:#ubuntu-release- New binary: swarmkit [s390x] (zesty-proposed/universe) [1.12.0+git20170111.763.296fcfcf-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected libvirt [sync] (yakkety-proposed) [2.1.0-1ubuntu9.2]
-queuebot:#ubuntu-release- New binary: swarmkit [arm64] (zesty-proposed/universe) [1.12.0+git20170111.763.296fcfcf-1] (no packageset)
-queuebot:#ubuntu-release- New binary: swarmkit [armhf] (zesty-proposed/universe) [1.12.0+git20170111.763.296fcfcf-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libvirt (yakkety-proposed/main) [2.1.0-1ubuntu9.1 => 2.1.0-1ubuntu9.3] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: gnome-system-monitor (zesty-proposed/main) [3.23.92-0ubuntu1 => 3.24.0-0ubuntu1] (ubuntu-desktop)
<jbicha> I still have several GNOME 3.23.92>3.24.0 uploads to do. Since GNOME was in code freeze, many of these are just a version bump and translation updates
<jbicha> I don't need them in for Final Beta, but it's not a problem if I upload them to zesty now, right?
-queuebot:#ubuntu-release- Unapproved: horizon (xenial-proposed/main) [2:9.1.1-0ubuntu1 => 2:9.1.1-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: notmuch (zesty-proposed/main) [0.23.7-1ubuntu1 => 0.23.7-2ubuntu1] (core)
<LocutusOfBorg> little upstream fix for notmuch ^^ two lines changed
-queuebot:#ubuntu-release- Unapproved: cgroup-lite (yakkety-proposed/universe) [1.11 => 1.11ubuntu0.16.10.1] (no packageset)
-queuebot:#ubuntu-release- New source: ukui-control-center (zesty-proposed/primary) [1.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-control-center [source] (zesty-proposed) [1.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: ukui-control-center [amd64] (zesty-proposed/universe) [1.0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-control-center [ppc64el] (zesty-proposed/universe) [1.0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-control-center [i386] (zesty-proposed/universe) [1.0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-control-center [s390x] (zesty-proposed/universe) [1.0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-control-center [arm64] (zesty-proposed/universe) [1.0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-control-center [armhf] (zesty-proposed/universe) [1.0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mesa (zesty-proposed/main) [17.0.1-1ubuntu1 => 17.0.2-1ubuntu1] (core, xorg)
-queuebot:#ubuntu-release- New: accepted peony [source] (zesty-proposed) [1.0.0-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted ukui-control-center [amd64] (zesty-proposed) [1.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-control-center [armhf] (zesty-proposed) [1.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-control-center [ppc64el] (zesty-proposed) [1.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-control-center [arm64] (zesty-proposed) [1.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-control-center [s390x] (zesty-proposed) [1.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-control-center [i386] (zesty-proposed) [1.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: peony [ppc64el] (zesty-proposed/none) [1.0.0-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: peony [amd64] (zesty-proposed/none) [1.0.0-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: peony [s390x] (zesty-proposed/none) [1.0.0-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: peony [i386] (zesty-proposed/none) [1.0.0-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: peony [armhf] (zesty-proposed/none) [1.0.0-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New source: ukui-indicators (zesty-proposed/primary) [1.0.2-0ubuntu1]
-queuebot:#ubuntu-release- New binary: peony [arm64] (zesty-proposed/none) [1.0.0-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New: accepted ukui-indicators [source] (zesty-proposed) [1.0.2-0ubuntu1]
-queuebot:#ubuntu-release- New binary: ukui-indicators [amd64] (zesty-proposed/none) [1.0.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-indicators [ppc64el] (zesty-proposed/none) [1.0.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-indicators [i386] (zesty-proposed/none) [1.0.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-indicators [arm64] (zesty-proposed/none) [1.0.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-indicators [armhf] (zesty-proposed/none) [1.0.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukui-indicators [s390x] (zesty-proposed/none) [1.0.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (yakkety-proposed/main) [2.435.1 => 2.435.2] (desktop-core)
-queuebot:#ubuntu-release- New: accepted peony [amd64] (zesty-proposed) [1.0.0-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted peony [armhf] (zesty-proposed) [1.0.0-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted peony [ppc64el] (zesty-proposed) [1.0.0-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted peony [arm64] (zesty-proposed) [1.0.0-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted peony [s390x] (zesty-proposed) [1.0.0-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted peony [i386] (zesty-proposed) [1.0.0-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted ukui-indicators [amd64] (zesty-proposed) [1.0.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-indicators [armhf] (zesty-proposed) [1.0.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-indicators [ppc64el] (zesty-proposed) [1.0.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-indicators [arm64] (zesty-proposed) [1.0.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-indicators [s390x] (zesty-proposed) [1.0.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukui-indicators [i386] (zesty-proposed) [1.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: cross-toolchain-base-ports (zesty-proposed/universe) [5ubuntu1 => 10ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cross-toolchain-base (zesty-proposed/main) [12ubuntu1 => 17ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted cross-toolchain-base-ports [source] (zesty-proposed) [10ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cross-toolchain-base [source] (zesty-proposed) [17ubuntu1]
-queuebot:#ubuntu-release- New source: gnome-games-app (zesty-proposed/primary) [3.24.0.2-0ubuntu1]
<jbicha> feel free to reject the older gnome-games-app from zesty/new
-queuebot:#ubuntu-release- Unapproved: gcc-6 (zesty-proposed/main) [6.3.0-9ubuntu2 => 6.3.0-10ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-6 [source] (zesty-proposed) [6.3.0-10ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-chess (yakkety-proposed/universe) [1:3.22.0-1 => 1:3.22.0-1ubuntu1] (desktop-extra)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.8 => 2.408.9] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: peony (zesty-proposed/universe) [1.0.0-0ubuntu3 => 1.0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted peony [source] (zesty-proposed) [1.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: smplayer-themes (zesty-proposed/universe) [1:16.8.0-1 => 1:17.2.0-1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: smplayer (zesty-proposed/universe) [17.2.0~ds0-1 => 17.3.0~ds0-1] (ubuntukylin) (sync)
<LocutusOfBorg> please accept them ^^ they have to go with the same major versioning, and themes were outdated :)
<LocutusOfBorg> (not a big deal probably if they are out of sync, but there are two themes added or something like that)
<caribou> sil2100: fine then
<caribou> any archive admin in the room ? I've uploaded nfs-utils to Zesty on friday and I see no trace of it; should I just re-upload ?
<caribou> problem is that nfs-utils is seeded
<cjwatson> lp_queue/process-upload.log-20170319.gz:2017-03-17 13:51:14 INFO    Failed to parse changes file '/srv/launchpad.net/ubuntu-queue/incoming/upload-ftp-20170317-135044-001652/ubuntu/nfs-utils_1.2.8-9.2ubuntu2_source.changes': GPG verification of /srv/launchpad.net/ubuntu-queue/incoming/upload-ftp-20170317-135044-001652/ubuntu/nfs-utils_1.2.8-9.2ubuntu2_source.changes failed: Verification failed ...
<cjwatson> ... 3 times: ["(7, 58, u'No data')", "(7, 58, u'No data')", "(7, 58, u'No data')"]
<cjwatson> you should check that you actually signed the upload, and then reupload
<cjwatson> (it's also possible it was a transient keyserver failure)
<caribou> cjwatson: thanks for checking, I'll double-check the sig & re-upload
-queuebot:#ubuntu-release- Unapproved: nfs-utils (zesty-proposed/main) [1:1.2.8-9.2ubuntu1 => 1:1.2.8-9.2ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: gdk-pixbuf (zesty-proposed/main) [2.36.5-1 => 2.36.5-3] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: gnocchi (zesty-proposed/universe) [3.1.1-0ubuntu1 => 3.1.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnocchi [source] (zesty-proposed) [3.1.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: protobuf (zesty-proposed/main) [3.0.0-9ubuntu1 => 3.0.0-9ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-69.90~14.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: cheese (zesty-proposed/main) [3.22.1-1ubuntu1 => 3.24.0-0ubuntu1] (desktop-extra, kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-backgrounds (zesty-proposed/universe) [3.23.91-0ubuntu1 => 3.24.0-0ubuntu1] (desktop-extra, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: gnome-boxes (zesty-proposed/universe) [3.23.4.1-0ubuntu1 => 3.24.0-0ubuntu1] (desktop-extra)
-queuebot:#ubuntu-release- Unapproved: gnome-calculator (zesty-proposed/main) [1:3.23.92-0ubuntu1 => 1:3.24.0-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-clocks (zesty-proposed/universe) [3.23.90-0ubuntu1 => 3.24.0-0ubuntu1] (desktop-extra)
-queuebot:#ubuntu-release- Unapproved: gnome-desktop3 (zesty-proposed/main) [3.23.90-0ubuntu1 => 3.24.0-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: cups-filters (zesty-proposed/main) [1.13.4-1 => 1.13.4-1ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gnome-mines (zesty-proposed/main) [1:3.23.91-0ubuntu1 => 1:3.24.0-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-online-accounts (zesty-proposed/main) [3.23.92-0ubuntu1 => 3.24.0-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gtksourceview3 (zesty-proposed/main) [3.23.91-0ubuntu1 => 3.24.0-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: lightsoff (zesty-proposed/universe) [1:3.22.2-1 => 1:3.24.0-0ubuntu1] (desktop-extra)
-queuebot:#ubuntu-release- Unapproved: swell-foop (zesty-proposed/universe) [1:3.22.2-1 => 1:3.24.0-0ubuntu1] (desktop-extra)
-queuebot:#ubuntu-release- Unapproved: zenity (zesty-proposed/main) [3.22.0-1 => 3.24.0-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-initial-setup (zesty-proposed/universe) [3.23.92-0ubuntu1 => 3.24.0-0ubuntu1] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: evolution-data-server (zesty-proposed/main) [3.22.6-1ubuntu1 => 3.22.7-0ubuntu1] (ubuntu-desktop)
<rbasak> Tomorrow is my SRU rota day, but I'd like to participate in the server team's bug squashing party. Anybody up for a swap?
<rbasak> Or else I might try and juggle both tasks somehow.
<apw> rbasak: there will be other people around. i do some bits most days. go to your bug squashing party!
<bdmurray> rbasak: I can help or swap.
<bdmurray> slangasek: So what can we do about getting aptdaemon released to zesty / yakkety for bug 1623856?
<ubot5> bug 1623856 in aptdaemon (Ubuntu) "Scrolled Windows in update-manager are too small to read" [Low,In progress] https://launchpad.net/bugs/1623856
<bdmurray> It's held up for zesty due to autopkgtest regressions
-queuebot:#ubuntu-release- Unapproved: accepted gdk-pixbuf [sync] (zesty-proposed) [2.36.5-3]
-queuebot:#ubuntu-release- Unapproved: accepted mesa [source] (zesty-proposed) [17.0.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted smplayer-themes [sync] (zesty-proposed) [1:17.2.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted vala [sync] (zesty-proposed) [0.34.7-1]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [sync] (zesty-proposed) [2.5.0-3ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted smplayer [sync] (zesty-proposed) [17.3.0~ds0-1]
-queuebot:#ubuntu-release- Unapproved: accepted protobuf [source] (zesty-proposed) [3.0.0-9ubuntu2]
<slangasek> bdmurray: is it a regression vs. the version in zesty release?
-queuebot:#ubuntu-release- Unapproved: accepted cheese [source] (zesty-proposed) [3.24.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-system-monitor [source] (zesty-proposed) [3.24.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted notmuch [source] (zesty-proposed) [0.23.7-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-backgrounds [source] (zesty-proposed) [3.24.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nfs-utils [source] (zesty-proposed) [1:1.2.8-9.2ubuntu2]
<slangasek> bdmurray: I see the zesty version is marked 'badtest', we should do the same for the zesty-proposed version
<bdmurray> slangasek: I thought barry talked about it being abandoned etc
-queuebot:#ubuntu-release- New binary: gdk-pixbuf [amd64] (zesty-proposed/main) [2.36.5-3] (core)
-queuebot:#ubuntu-release- New binary: gdk-pixbuf [s390x] (zesty-proposed/main) [2.36.5-3] (core)
-queuebot:#ubuntu-release- Unapproved: accepted cups-filters [source] (zesty-proposed) [1.13.4-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-calculator [source] (zesty-proposed) [1:3.24.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-desktop3 [source] (zesty-proposed) [3.24.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-boxes [source] (zesty-proposed) [3.24.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-mines [source] (zesty-proposed) [1:3.24.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-clocks [source] (zesty-proposed) [3.24.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: gdk-pixbuf [ppc64el] (zesty-proposed/main) [2.36.5-3] (core)
<slangasek> bdmurray: yeah, if barry had checked the hints files, he would've seen this is not a regression.  Hinted now
-queuebot:#ubuntu-release- New binary: gdk-pixbuf [i386] (zesty-proposed/main) [2.36.5-3] (core)
<bdmurray> slangasek: ack, thanks I'll do the work for yakkety
-queuebot:#ubuntu-release- New binary: gdk-pixbuf [arm64] (zesty-proposed/main) [2.36.5-3] (core)
-queuebot:#ubuntu-release- Unapproved: accepted evolution-data-server [source] (zesty-proposed) [3.22.7-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-online-accounts [source] (zesty-proposed) [3.24.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted lightsoff [source] (zesty-proposed) [1:3.24.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted zenity [source] (zesty-proposed) [3.24.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-initial-setup [source] (zesty-proposed) [3.24.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted swell-foop [source] (zesty-proposed) [1:3.24.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gtksourceview3 [source] (zesty-proposed) [3.24.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted swarmkit [amd64] (zesty-proposed) [1.12.0+git20170111.763.296fcfcf-1]
-queuebot:#ubuntu-release- New: accepted swarmkit [armhf] (zesty-proposed) [1.12.0+git20170111.763.296fcfcf-1]
-queuebot:#ubuntu-release- New: accepted swarmkit [ppc64el] (zesty-proposed) [1.12.0+git20170111.763.296fcfcf-1]
-queuebot:#ubuntu-release- New: accepted swarmkit [arm64] (zesty-proposed) [1.12.0+git20170111.763.296fcfcf-1]
-queuebot:#ubuntu-release- New: accepted swarmkit [s390x] (zesty-proposed) [1.12.0+git20170111.763.296fcfcf-1]
-queuebot:#ubuntu-release- New: accepted swarmkit [i386] (zesty-proposed) [1.12.0+git20170111.763.296fcfcf-1]
-queuebot:#ubuntu-release- New: rejected gnome-games-app [source] (zesty-proposed) [3.23.91-0ubuntu1]
-queuebot:#ubuntu-release- New binary: gdk-pixbuf [armhf] (zesty-proposed/main) [2.36.5-3] (core)
-queuebot:#ubuntu-release- New: accepted gdk-pixbuf [amd64] (zesty-proposed) [2.36.5-3]
-queuebot:#ubuntu-release- New: accepted gdk-pixbuf [armhf] (zesty-proposed) [2.36.5-3]
-queuebot:#ubuntu-release- New: accepted gdk-pixbuf [ppc64el] (zesty-proposed) [2.36.5-3]
-queuebot:#ubuntu-release- New: accepted gdk-pixbuf [arm64] (zesty-proposed) [2.36.5-3]
-queuebot:#ubuntu-release- New: accepted gdk-pixbuf [s390x] (zesty-proposed) [2.36.5-3]
-queuebot:#ubuntu-release- New: accepted gdk-pixbuf [i386] (zesty-proposed) [2.36.5-3]
-queuebot:#ubuntu-release- Unapproved: aptdaemon (yakkety-proposed/main) [1.1.1+bzr982-0ubuntu16 => 1.1.1+bzr982-0ubuntu16.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: glibc (zesty-proposed/main) [2.24-9ubuntu1 => 2.24-9ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted glibc [source] (zesty-proposed) [2.24-9ubuntu2]
-queuebot:#ubuntu-release- Unapproved: gnome-chess (zesty-proposed/universe) [1:3.23.92.5-0ubuntu1 => 1:3.24.0-0ubuntu1] (desktop-extra)
<jbicha> please unblock gdk-pixbuf 2.36.5-3 for zesty
<jbicha> oh, it's held up by glib2.0's failing autopkgtests anyway
<jbicha> let me merge in Debian's latest libsecret test hackâ¦
-queuebot:#ubuntu-release- Unapproved: libsecret (zesty-proposed/main) [0.18.5-2ubuntu2 => 0.18.5-3.1ubuntu1] (kubuntu, ubuntu-desktop)
<jbicha> well the gdk-pixbuf bug doesn't affect installation so maybe I'll just release-note it
<tsimonq2> infinity: You have multiple relevant hats so I thought I might ask... does Core Dev automatically get ~ubuntu-sru-developers ?
<infinity> tsimonq2: Given that ~ubuntu-sru-developers has existed for a day, and I wasn't involved in the creation, I have no idea what it's even meant to be.
<wxl> infinity: but DUDE that's 24 *HOURS* XD
<infinity> tsimonq2: But it looks like it's a subset of core-dev's permissions.
<tsimonq2> infinity: Ah ok
<jbicha> please badtest ostree, no clue why its autopkgtest passed yesterday for the first time ever in Ubuntu but fails today
<infinity> jbicha: Better option, could it not run the test that appears to break on network oddities (or be fixed to work in that environment)?
<infinity> jbicha: But concur that it doesn't appear to be a regression, so will badtest that version for now.
<jbicha> it's basically synced with Debian, so I'd have to ask smcv about that
<infinity> Well, it's not ostree that't the problem, it's gnome-desktop-testing
<infinity> Which might be Simon's too.
<infinity> But yeah.  Should look into why that's full of hate.
<infinity> Or maybe it's the ostree g-d-t tests.  I dunno.
<infinity> Very curious that it passed briefly on 3 arches, though.
<infinity> I wonder what we did to our infra yesterday. :P
<doko> infinity: please could you override the failing linux autopkg test for binutils and gcc-6 and unblock them? somebody did that already with the last version this weekend
<infinity> doko: After the beta, yeah.
<doko> ohh, this week already ...
<infinity> Time flies, and we're getting old.
<infinity> Well, you're getting older. :P
#ubuntu-release 2017-03-22
-queuebot:#ubuntu-release- Unapproved: shim-signed (zesty-proposed/main) [1.23 => 1.27] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: shim (zesty-proposed/main) [0.9+1474479173.6c180c6-0ubuntu1 => 0.9+1474479173.6c180c6-1ubuntu1] (core) (sync)
<cyphermox> slangasek: ^
-queuebot:#ubuntu-release- Unapproved: lshw (zesty-proposed/main) [02.18-0.1ubuntu1 => 02.18-0.1ubuntu2] (core)
<slangasek> cyphermox: oh, right ;)
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [sync] (zesty-proposed) [1.27]
-queuebot:#ubuntu-release- Unapproved: accepted shim [sync] (zesty-proposed) [0.9+1474479173.6c180c6-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: meta-gnome3 (zesty-proposed/universe) [1:3.20+1ubuntu1 => 1:3.22+1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted meta-gnome3 [source] (zesty-proposed) [1:3.22+1ubuntu1]
<ypwong> rbasak, hi, bug 1511301 has been verified, can it be released to -updates soon?
<ubot5> bug 1511301 in fglrx-installer-updates (Ubuntu Trusty) "Failed to upgrade fglrx from 14.502 to 15.200 on Trusty." [High,Fix committed] https://launchpad.net/bugs/1511301
-queuebot:#ubuntu-release- Unapproved: criu (zesty-proposed/universe) [2.12-1ubuntu1 => 2.12-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted criu [source] (zesty-proposed) [2.12-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: lightdm (zesty-proposed/main) [1.21.5-0ubuntu1 => 1.22.0-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: meta-gnome3 (zesty-proposed/universe) [1:3.22+1ubuntu1 => 1:3.22+1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted meta-gnome3 [source] (zesty-proposed) [1:3.22+1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: lft (zesty-proposed/universe) [2.2-4ubuntu1 => 2.2-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted lft [sync] (zesty-proposed) [2.2-5]
-queuebot:#ubuntu-release- Unapproved: gfs2-utils (zesty-proposed/universe) [3.1.9-2 => 3.1.9-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gfs2-utils [source] (zesty-proposed) [3.1.9-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ladish (zesty-proposed/universe) [1+dfsg0-5ubuntu3 => 1+dfsg0-5.1] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: deluge (zesty-proposed/universe) [1.3.13+git20161130.48cedf63-1ubuntu1 => 1.3.13+git20161130.48cedf63-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted deluge [source] (zesty-proposed) [1.3.13+git20161130.48cedf63-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: orthanc-dicomweb (zesty-proposed/universe) [0.3+dfsg-1ubuntu1 => 0.3+dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted orthanc-dicomweb [sync] (zesty-proposed) [0.3+dfsg-2]
-queuebot:#ubuntu-release- Unapproved: snapd-glib (zesty-proposed/main) [1.7-0ubuntu1 => 1.8-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: python3.6 (zesty-proposed/universe) [3.6.1~rc1-1 => 3.6.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted python3.6 [source] (zesty-proposed) [3.6.1-1]
-queuebot:#ubuntu-release- Unapproved: libdrm (zesty-proposed/main) [2.4.75-1ubuntu1 => 2.4.75-2] (core, xorg) (sync)
<jamespage> please could the horizon package in the xenial unapproved queue be rejected - it need re-uploading with both orig.tar.gz's
<apw> jamespage, looking
-queuebot:#ubuntu-release- Unapproved: rejected horizon [source] (xenial-proposed) [2:9.1.1-0ubuntu2]
<jamespage> apw: ta
-queuebot:#ubuntu-release- Unapproved: nova (yakkety-proposed/main) [2:14.0.4-0ubuntu1 => 2:14.0.4-0ubuntu1.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sssd (trusty-proposed/main) [1.11.8-0ubuntu0.5 => 1.11.8-0ubuntu0.6] (ubuntu-desktop)
<jamespage> if there is a SRU team member around nova 2:14.0.4-0ubuntu1.1 in the queue for yakkety proposed corrects a regression in nova for 2:14.0.4-0ubuntu1
<jamespage> nice to get that in so we can complete verification testing pls :-)
<apw> jamespage, looking
-queuebot:#ubuntu-release- Unapproved: accepted nginx [source] (xenial-proposed) [1.10.3-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted nginx [source] (yakkety-proposed) [1.10.3-0ubuntu0.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (yakkety-proposed) [2:14.0.4-0ubuntu1.1]
<jamespage> apw: ta
<LocutusOfBorg> Laney, do you want to help me making perl migrate pleeeeease? :)
<LocutusOfBorg> autopkgtest for pinto/0.97+dfsg-4: amd64: Regression â» , armhf: Regression â» , i386: Regression â» , ppc64el: Regression â» , s390x: Regression â»
<LocutusOfBorg> this should be probably ignored, it is a warning thrown when importing a deprecated library
<Laney> http://autopkgtest.ubuntu.com/packages/p/pinto/zesty/amd64
<Laney> This looks bad for the new perl, doesn't it?
<LocutusOfBorg> it looks just a warning
<Laney> I think that could be fixed in the test
<Laney> Either whitelist the warning, or make it stop happening
<Laney> Also, beta freeze so you'll have to wait until after that anyway
<LocutusOfBorg> but there isn't a "new perl" not sure why it came out only now
<Laney> Maybe something else changed between the last run and now
<Laney> Either way, it seems fixable rather than ignoring all the tests
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-69.90~14.04.1]
<LocutusOfBorg> you mean pinto, right?
<Laney> I suppose that you could either say "yes, we know that it's deprecated, don't make that fail the test" (i.e. whitelist that message), or port whatever is using the deprecated library to the replacement that it talks about
<LocutusOfBorg> got the reason for the regression
<LocutusOfBorg> perl	5.24.1~rc4-1
<Laney> https://rt.cpan.org/Public/Bug/Display.html?id=104918
<LocutusOfBorg> perl	5.24.1-2ubuntu1
<LocutusOfBorg> so, the last good run was with an older rc perl version
<LocutusOfBorg> actualluy I'm not able to find where that test is run
<LocutusOfBorg> I don't understand that perl testsuite implementation
<Laney> LocutusOfBorg: They're autodep8 tests for which the runner is in the pkg-perl-autopkgtest package
<rbasak> apw, bdmurray, arges: I think we might all be doing SRUs today? Let's coordinate in here if we are.
<apw> rbasak, ack
<rbasak> I'm looking at some server team bug squashing today, so I'm off SRUs right now though I might do some ad-hoc.
<rbasak> I'll report in here if I do.
<LocutusOfBorg> Laney, so... something like "debian/tests/pkg-perl/SKIP?" https://sources.debian.net/src/pkg-perl-tools/0.36/autopkgtest/README.autopkgtest/
<Laney> LocutusOfBorg: I think you should be able to put the deprecation message in use-whitelist?
<LocutusOfBorg> so, echo "warning" > debian/test/pkg-perl/use-whitelist
<Laney> you probably have to put the actual message in there, but dunno
<LocutusOfBorg> yes sure
<Laney> should reproduce locally
<LocutusOfBorg> giving you credits for the fix, thanks
<LocutusOfBorg> All tests successful.
<LocutusOfBorg> Files=1, Tests=4,  2 wallclock secs ( 0.01 usr  0.00 sys +  1.87 cusr  0.08 csys =  1.96 CPU)
<LocutusOfBorg> so, ignoring systemd tests and we should be good to go
<LocutusOfBorg> (except for freeze)
<apw> LocutusOfBorg, presumably you can upload that to -proposed it just won't make it out
<LocutusOfBorg> already uploaded :)
-queuebot:#ubuntu-release- Unapproved: pinto (zesty-proposed/universe) [0.97+dfsg-4 => 0.97+dfsg-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted pinto [source] (zesty-proposed) [0.97+dfsg-4ubuntu1]
<Laney> LocutusOfBorg: thanks! that could probably be fwded too (maybe clone https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845807)
<ubot5> Debian bug 845807 in libterm-editoredit-perl "libterm-editoredit-perl: uses deprecated Any::Moose" [Normal,Open]
<LocutusOfBorg> Laney, already forwarded
<Laney> â¥
<LocutusOfBorg> thanks to you!
<LocutusOfBorg> #858439
<arges> looking at yakkety upload queue from the top
-queuebot:#ubuntu-release- Unapproved: accepted gnome-chess [source] (yakkety-proposed) [1:3.22.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (yakkety-proposed) [2.1.0-1ubuntu9.3]
-queuebot:#ubuntu-release- Unapproved: accepted cgroup-lite [source] (yakkety-proposed) [1.11ubuntu0.16.10.1]
<LocutusOfBorg> sigh slangasek apw linux-hwe-edge needs virtualbox changes before upload LP: 1674819
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (yakkety-proposed) [1.3.5]
<ubot5> Launchpad bug 1674819 in virtualbox (Ubuntu) "virtualbox-dkms 5.0.32-dfsg-0ubuntu1.16.04.2: virtualbox kernel module failed to build [error: too few arguments to function âget_user_pages_remoteâ]" [Undecided,New] https://launchpad.net/bugs/1674819
<apw> LocutusOfBorg, the hwe-edge package has virtualbox kernel bits from zesty so we we care if that fails ?
<apw> LocutusOfBorg, if we do that would imply we are lacking a Provides: or something ?
<LocutusOfBorg> maybe the person is trying to install it without having to?
<apw> possible, worth checking there is a provides on the linux-hwe-edge linux-image-* packages, if not that would be the cause and a fail
<LocutusOfBorg> cat linux-hwe-edge_4.10.0-13.15~16.04.2.diff |grep virtualbox-modules
<LocutusOfBorg> none
<LocutusOfBorg> well, the kernel is providing guest modules, not host modules
<arges> looking are percona release
-queuebot:#ubuntu-release- Unapproved: accepted iscsitarget [source] (trusty-proposed) [1.4.20.3+svn499-0ubuntu2.2]
<arges> apw: rbasak: ok calling it a morning. have fun with the rest of the SRUs : )
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (xenial-proposed/multiverse) [5.0.32-0ubuntu1.16.04.2 => 5.0.36-0ubuntu1.16.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox (xenial-proposed/multiverse) [5.0.32-dfsg-0ubuntu1.16.04.2 => 5.0.36-0ubuntu1.16.04.2] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: virtualbox-guest-additions-iso (xenial-proposed/multiverse) [5.0.32-0ubuntu1.16.04.2 => 5.0.36-0ubuntu1.16.04.2] (no packageset)
<LocutusOfBorg> apw, ^^ you might be the best candidate :D
<apw> LocutusOfBorg, i'll try and get to that in a little bit indeed
<rbasak> arges: thank you for your help!
<Sweet5hark> Hi, Im Bjoern and Im here to confess to the release team about libreoffice 1:5.3.1-0ubuntu2 in zesty-proposed.
<Sweet5hark> 1:5.3.0~rc3-0ubuntu1 as in zesty fails autopkgtests. 5.3.1 is a bugfix only release that was uploaded before the freeze as -0ubuntu1 with just a fix for failing autopkgtests in addition to upstream changes. It fixed them on amd64. Unfortunately, on i386 _another_ fix was needed on top of that to unbreak it there too. This was previously covered in 1:5.3.0~rc3-0ubuntu1. Thus -0ubuntu2 was uploaded and
<Sweet5hark> ran into the freeze. More details are in bug 1673790 (and the Debian bug linked therein).
<ubot5> bug 1673790 in libreoffice (Ubuntu) "bump LibreOffice to 5.3.1 on zesty and fix autpkgtest dependencies" [Undecided,Fix committed] https://launchpad.net/bugs/1673790
<Sweet5hark> Please advise on how to proceed.
<LocutusOfBorg> apw, I might need a little tweak
<jbicha> Sweet5hark: LO 5.3.1 will automatically migrate into zesty after Beta 2
-queuebot:#ubuntu-release- Unapproved: gnome-software (zesty-proposed/main) [3.22.7-0ubuntu1 => 3.22.7-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: nova (zesty-proposed/main) [2:15.0.1-0ubuntu1 => 2:15.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: virtualbox (xenial-proposed/multiverse) [5.0.32-dfsg-0ubuntu1.16.04.2 => 5.0.36-0ubuntu1.16.04.3] (ubuntu-cloud)
<Sweet5hark> jbicha: oh, good. Just wondered if there is anything left to clarify.
<Sweet5hark> jbicha: thanks for enduring that sponsoring btw ;)
<LocutusOfBorg> apw, providing virtualbox-modules building vboxdrv/ vboxnetflt/ vboxnetadp/ vboxpci/ woult fix this issue properly
<philroche> Hi, would someone on the Ubuntu Sponsors team be able to help SRUing a critical GCE bugfix please? LP:1668327 needs to be marked as critical and target Trusty, Xenial, Yakkety and Zesty. I have uploaded patches for all suites and was hoping I could land them all in -proposed today. Thanks https://bugs.launchpad.net/ubuntu/+source/gce-compute-image-packages/+bug/1668327
<ubot5> Ubuntu bug 1668327 in gce-compute-image-packages (Ubuntu) "Startup scripts get run when guest packages are updated" [Medium,Confirmed]
<LocutusOfBorg> philroche, .
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20160930-0ubuntu5~16.04.0 => 20160930-0ubuntu6~16.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (zesty-proposed/universe) [20160930-0ubuntu5 => 20160930-0ubuntu6] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (yakkety-proposed/universe) [20160930-0ubuntu5~16.10.0 => 20160930-0ubuntu6~16.10.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: manila-ui (zesty-proposed/universe) [2.7.0-0ubuntu1 => 2.7.1-0ubuntu1] (no packageset)
<LocutusOfBorg> philroche, ^^
-queuebot:#ubuntu-release- Unapproved: accepted manila-ui [source] (zesty-proposed) [2.7.1-0ubuntu1]
-queuebot:#ubuntu-release- New sync: sdpb (zesty-proposed/primary) [1.0-3]
<LocutusOfBorg> not sure philroche why you no MOTU/PPU
<philroche> LocutusOfBorg: Thank you. Still quite new so no PPU rights yet. Do I need to do anything further to get them in to -proposed?
<LocutusOfBorg> philroche, somebody in -release team reviewing them, they are in the queue
<philroche> Cool. Thanks
<LocutusOfBorg> being seeded and being zesty on beta freeze is not helping getting the fixes go
<LocutusOfBorg> https://launchpad.net/ubuntu/zesty/+queue?queue_state=1&queue_text=
<philroche> Understood, it wasn't good timing.
<philroche> LocutusOfBorg: Any chance you would have time to upload trusty too and target that bug to Trusty too?
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20160930-0ubuntu3~14.04.1 => 20160930-0ubuntu3~14.04.2] (ubuntu-cloud)
<LocutusOfBorg> like this? ^^ sorry for missing it
<philroche> LocutusOfBorg: Awesome. Thanks again
<LocutusOfBorg> thanks to youÃ¹
<tsimonq2> infinity: So the person responsible for updating the Lubuntu slideshow (to my surprise) for this new release hasn't done so yet. He's on it and he'll get it done ASAP, but how flexible are you with letting a slideshow package in?
-queuebot:#ubuntu-release- Unapproved: pcre2 (zesty-proposed/universe) [10.22-2 => 10.22-3] (no packageset) (sync)
<tsimonq2> infinity: (the person on the Lubuntu team that usually does these things, he's the artwork team guy)
<jibel> infinity, are you freezing the queue from now on to the release or from final freeze in 2 weeks?
-queuebot:#ubuntu-release- Unapproved: accepted pcre2 [sync] (zesty-proposed) [10.22-3]
<tsimonq2> jibel: For what it's worth, I think that's what he said in the announcement email (but I could be wrong).
<jibel> yeah, that's what I read too, but confirming it's really what it means
<jibel> :)
<jibel> there are tons of updates for unity8
<apw> there should be no major updates left, that is the point of freezes :-p
<apw> but they will get stuck in the queue and get reviewed more before they get out
<jibel> agreed but still :)
<tsimonq2> jibel: Wakeup call, WOAH, less than a month away!!!
<jibel> ...
<apw> jibel, it is meant to hurt from here on out :)
<tsimonq2> Not like I need to do anything for Lubuntu, all of our ducks are pretty much in a row, but still.
<jamespage> apw: well this is a little embarrasing - apparently I can't read names of patches when checking things in our git package build systems
<apw> jamespage, ?
<jamespage> apw: the SRU you acked for me earlier ftbfs - fixing and testing that now....
 * jamespage faceplants...
<apw> jamespage, ping me when it hits the queue
<jamespage> apw: ta
<jamespage> will do
-queuebot:#ubuntu-release- Unapproved: tftp-hpa (trusty-proposed/main) [5.2-7ubuntu3 => 5.2-7ubuntu3.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: tftp-hpa (yakkety-proposed/main) [5.2+20150808-1ubuntu1 => 5.2+20150808-1ubuntu1.16.10.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: tftp-hpa (xenial-proposed/main) [5.2+20150808-1ubuntu1 => 5.2+20150808-1ubuntu1.16.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted maas [source] (trusty-proposed) [1.9.5+bzr4599-0ubuntu1~14.04.1]
-queuebot:#ubuntu-release- Unapproved: lsvpd (zesty-proposed/main) [1.7.7-1ubuntu1 => 1.7.7-1ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: iscsitarget (xenial-proposed/universe) [1.4.20.3+svn502-2ubuntu4 => 1.4.20.3+svn502-2ubuntu4.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted lsvpd [source] (zesty-proposed) [1.7.7-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: nova (yakkety-proposed/main) [2:14.0.4-0ubuntu1.1 => 2:14.0.4-0ubuntu1.2] (openstack, ubuntu-server)
<jamespage> apw: ^^ that one - fully build tested this time - apologies for that
-queuebot:#ubuntu-release- Unapproved: accepted lshw [source] (zesty-proposed) [02.18-0.1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (yakkety-proposed) [2:14.0.4-0ubuntu1.2]
<apw> jamespage, ^
<jamespage> apw: ta
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (zesty-proposed) [20160930-0ubuntu6]
<LocutusOfBorg> Laney, sometimes testsuites don't start
<Laney> what does sometimes mean
<LocutusOfBorg> autopkgtestsuites are "test in progress" forever, I discovered for perl in armhf specially
<Laney> give me an example please
<LocutusOfBorg> I would wild guess it happened to ~10 packages in the total
<LocutusOfBorg> you mean, the package having that issue?
<LocutusOfBorg> let me check again, I didn't save them
<Laney> kind of hard to look without knowing where to look :)
<LocutusOfBorg> it was just to know if you were aware of such issue
<LocutusOfBorg> not to report it :)
<LocutusOfBorg> anyway, the browser should mark such armhf with a different colour, since I clicked them
<LocutusOfBorg> let me check the whole list
<LocutusOfBorg> http://autopkgtest.ubuntu.com/packages/liba/libanyevent-memcached-perl/zesty/armhf
<LocutusOfBorg> this one
<tsimonq2> chrisccoulson: I'm going to file a bug in a sec, but when you released that Firefox update into Xenial, it broke audio functionality in Lubuntu 16.04 LTS because it's alsa0only
<tsimonq2> *alsa-only
<LocutusOfBorg> I waited 4 days, the queue was empty, and it didn't run
<Laney> do this
<Laney> click the last log
<Laney> get to https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/armhf/liba/libanyevent-memcached-perl/20170322_080446_7bbce@/log.gz
<Laney> hack the URL to see the raw index
<Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/?format=plain&prefix=zesty/armhf/liba/libanyevent-memcached-perl/
<Laney> pick the second most recent one (in this case) https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/armhf/liba/libanyevent-memcached-perl/20170318_205505_4c98c@/log.gz
<Laney> -> there was a transient failure, which killed the run and was not reported as such
<LocutusOfBorg> yes, I retried a lot of that "connection failure" tests
<LocutusOfBorg> they were reported as bad and I just retried them
<LocutusOfBorg> so, it tried, it didn't report them correctly, so I didn't notice them
<LocutusOfBorg> interesting
<Laney> that is worth a bug on src:autopkgtest at debian
<Laney> and if you want to hack on it, probably making the apt install retry a few times in such cases
<LocutusOfBorg> I would like to avoid reporting such issue... I have not enough knowledge rather than copy-pasting the above chat :)
-queuebot:#ubuntu-release- Unapproved: hyantesite (zesty-proposed/universe) [1.3.0-1ubuntu1 => 1.3.0-1.1] (no packageset) (sync)
<LocutusOfBorg> I don't see any open bug wrt this issue
-queuebot:#ubuntu-release- Unapproved: accepted hyantesite [sync] (zesty-proposed) [1.3.0-1.1]
<tsimonq2> chrisccoulson: Actually, there's one already here: bug 1671273
<ubot5> bug 1671273 in firefox (Ubuntu) " PulseAudio requirement breaks Firefox on ALSA-only systems" [High,Confirmed] https://launchpad.net/bugs/1671273
<Laney> LocutusOfBorg: Nothing wrong with a bug saying "Tests fail with 'Temporary failure resolving ...' sometimes", and pasting the log
<chrisccoulson> tsimonq2, yeah, the fix for that is basically "install pulseaudio". We keep our builds very similar to upstream, and we're not going to be re-enabling an audio backend that nobody is maintaining
<LocutusOfBorg> let me try
<LocutusOfBorg> http://autopkgtest.ubuntu.com/packages/libc/libcpan-meta-requirements-perl/zesty/amd64
<LocutusOfBorg> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/libc/libcpan-meta-requirements-perl/20170319_021121_70ef6@/log.gz
<tsimonq2> chrisccoulson: Then could you please add pulseaudio as a hard dep? And maybe possibly reupload to all the stable releases? :)
<chrisccoulson> tsimonq2, AFAIK, no other application depends on the pulseaudio daemon. Applications only depend on the client library
<tsimonq2> chrisccoulson: Ah, ok.
<LocutusOfBorg> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/?format=plain&prefix=zesty/amd64/libc/libcpan-meta-requirements-perl
<LocutusOfBorg> ok no such log
<tsimonq2> chrisccoulson: Then I'll bring it up on the Lubuntu mailing list.
<Laney> LocutusOfBorg: I think you would protect basically all of the apt-get calls in https://anonscm.debian.org/git/autopkgtest/autopkgtest.git/tree/setup-commands/setup-testbed with a retry
-queuebot:#ubuntu-release- Unapproved: landscape-client (zesty-proposed/main) [16.03-0ubuntu2 => 16.03-0ubuntu3] (ubuntu-server)
<robru> Laney: ok I've decreased the frequency, please merge: https://code.launchpad.net/~robru/britney/+git/britney2-ubuntu/+merge/320270
<infinity> jibel: Same as it's been for releases for years now.
<jibel> infinity, yeah ignore me ... :)
<acheronUK> infinity: I have a KDE plasma bugfix/translation update to upload once it's had a few days testing via our ppas. do you want any warning of that being uploaded, or juts do it when ready? I ask as it's 39 packages
<infinity> acheronUK: Will warning make it not be 39 packages? :)
<infinity> acheronUK: (No, we don't need warning)
<acheronUK> infinity: no. I was just trying to be considerate
<acheronUK> infinity: ok. thanks
<infinity> Condideration noted.  Gold star will be applied to uploader chart.
<Laney> robru: now you've removed the "max_age = 5 if excuse.is_valid else 1" bit, which wasn't part of the problem
<slangasek> LocutusOfBorg: I see there are two virtualbox uploads in the xenial queue with different versions; any reason we shouldn't reject these and collapse into a single upload to not skipping version numbers?
<tsimonq2> infinity: Stable release regression that could really use your feedback to help fix: https://lists.ubuntu.com/archives/lubuntu-devel/2017-March/000994.html
<tsimonq2> infinity: Either way we go about fixing it breaks some rules, so I don't want to be on anyone's bad side, either. :P
<infinity> tsimonq2: Those proposed options need to be fleshed out a LOT before you can make an informed decision.
<tsimonq2> infinity: I know.
<tsimonq2> infinity: But it's broken and it needs a fix.
<tsimonq2> infinity: Sooooo... I CCed you on the email. What would you prefer we do? What do you suggest?
<infinity> tsimonq2: The first option is basically something undoable, IMO.  The code was almost certainly removed entirely (if it wasn't, you could just ask chrisccoulson to turn it back on), and maintaining a fork of firefox is a huge amount of work.
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox [source] (xenial-proposed) [5.0.36-0ubuntu1.16.04.2]
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox [source] (xenial-proposed) [5.0.36-0ubuntu1.16.04.3]
<tsimonq2> infinity: That's what I'm saying, and that's why I was against it. :P
<infinity> tsimonq2: The third option is also a bit ridiculous.  Forcing users to switch applications doesn't really work.  Sure, you can add chromium-browser to lubuntu-desktop, but then they'll just have two browsers instead of one, and they won't know why.
<infinity> tsimonq2: As for the "just use pulse" thing, well, there's no indication of what that entails.  If it was that simple, I'd expect you'd already be using it?
<infinity> tsimonq2: If it is a simple question of changing some build flags to enable some pulse support in lxde, then derp, do that.
-queuebot:#ubuntu-release- Unapproved: virtualbox (xenial-proposed/multiverse) [5.0.32-dfsg-0ubuntu1.16.04.2 => 5.0.36-0ubuntu1.16.04.2] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: bind9 (yakkety-proposed/main) [1:9.10.3.dfsg.P4-10.1ubuntu1.3 => 1:9.10.3.dfsg.P4-10.1ubuntu1.4] (core)
<tsimonq2> wxl: So, you were the release manager at the time, why was this decision made? ^
<robru> Laney: well if having mails go out on the first and second days is too soon and too often, it doesn't make a lot of sense to have a different threshold for whether or not the excuse is valid, does it?
<infinity> tsimonq2: Oh.  If it's just a question of "--enable-alsa", as the bug report suggests, why the long, rambling proposal?  This is just a firefox bug, and chrisccoulson should be asked nicely to DTRT.
<tsimonq2> infinity: If there are no technical limitations to just switching to Pulseaudio and calling it a day, what do you need from us to justify getting it in Xenial?
<robru> Laney: like, that was there to decide if we want to send mails either on the first day or the fifth day, but you say the first day is too soon, so why would we keep that? send mails maybe on the third day, maybe on the fifth day? what good does that serve? I just unified it to start sending mails on the third day for everything now
<infinity> tsimonq2: Your proposal made it sound like upstream removed the code, when it sounds like all they did was change the default configure flags, and Chris didn't notice?
<chrisccoulson> because we generally don't enable features that aren't enabled upstream. If they're not enabled upstream, they're untested, not part of their CI and generally break frequently. And it's been disabled for a reason (it's unmaintained, and making it impossible to improve the other audio backends)
<tsimonq2> That makes sense.
<tsimonq2> infinity: Hey, I could have rambled more than I did... :P
<chrisccoulson> re-enabling it might get you another release or 2 at best before someone needs to step up and do some serious maintenance of it
<tsimonq2> But that's besides the point...
<tsimonq2> infinity: And that is my option number 1 ^
<tsimonq2> infinity: (in my email)
<LocutusOfBorg> slangasek, it would be awesome
<Laney> robru: I didn't say (or I didn't mean to say) that sending on the first day is bad. I mean to say that sending emails very close together is bad.
<slangasek> LocutusOfBorg: ok, done ;)
<robru> Laney: anyway I like the new thing, it streamlines a corner case and by not sending on the first day it drops the need for the pluralization logic. please just merge as is? thx ;-)
<LocutusOfBorg> and reuploaded!
<infinity> chrisccoulson: Or, you could disable it when it breaks, instead of predicting the breakage?  Given the general uproar, perhaps someone will step up to maintain it upstream.
<tsimonq2> infinity: I'm a little uncomfortable with that approach. "disable it when it breaks" sounds evil... :P
-queuebot:#ubuntu-release- Unapproved: virtualbox (xenial-proposed/multiverse) [5.0.32-dfsg-0ubuntu1.16.04.2 => 5.0.36-0ubuntu1.16.04.2] (ubuntu-cloud)
<tsimonq2> infinity: But I guess it could work
<Laney> robru: Ok I'll ponder it overnight. We had decided before that 5 days was a nice amount of time to give people to crack on with transitions, but maybe we can compromise on 3 for everything.
<infinity> chrisccoulson: Firefox's unique SRU/security exception doesn't make it immune to rules about regressions, just somewhat more resilient.  This is clearly a regression with a fix.
<tsimonq2> infinity, chrisccoulson: Either way, if we take that approach, it needs another upload.
<tsimonq2> What infinity said... ;)
<chrisccoulson> the "fix" needs a commitment from somebody to take ownership of the code
<robru> Laney: thanks
<infinity> tsimonq2: Evil how?  "When it breaks" would be "when the configure switch stops working" or "when enabling it causes it to FTBFS".
<Laney> robru: Asked for your review on an email branch too, in case you didn't/don't see it. No rush though.
<tsimonq2> infinity: Evil when things don't get tested and people notice.
<tsimonq2> infinity: If we can be very careful to test this aspect until it does break, I'm fine.
<tsimonq2> infinity: But we need to pay careful attention to make sure ALSA support doesn't regress if we do re-enable it.
<robru> Laney: this one? https://code.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/+merge/319448 my review is on there already
<tsimonq2> infinity: Which, as chrisccoulson is sort of saying (correct me if I'm wrong), wouldn't be safe either way, as it's unmaintained upstream. We're shipping unmaintained functionality...
<robru> Laney: if there's some other one, I don't see it
<tsimonq2> infinity: But yes, things breaking in that way is *way* worse.
<Laney> robru: oh I had a timeout
<infinity> Large portions of Firefox go "unmaintained" for years until someone decides to care again.  We build a lot of that.  I don't buy the argument.
<infinity> But meh.
<tsimonq2> Oh, really?
<tsimonq2> Huh.
<LocutusOfBorg> Laney, https://bugs.debian.org/85846 :)
<ubot5> Debian bug 85846 in mutt "mutt: Mutt converts signed messages to quoted-printable" [Normal,Open]
<slangasek> LocutusOfBorg: this new upstream of virtualbox includes changes besides the kernel compatibility changes; there is no changelog in the upstream tarball.  How do we confirm that the other changes are "safe" bugfixes?
<LocutusOfBorg> Laney, https://bugs.debian.org/858465 :)
<ubot5> Debian bug 858465 in src:autopkgtest "autopkgtest fails with no error when apt fails to fetch packages "Tests fail with 'Temporary failure resolving ...'"" [Normal,Open]
<tsimonq2> infinity, chrisccoulson: So is it just going to be re-enabled?
<Laney> LocutusOfBorg: thx
<tsimonq2> infinity, chrisccoulson: I mean, what now?
 * Laney thought that was a hint about him borking emails
<LocutusOfBorg> slangasek, this is the third upload I do, they are just fixing regressions and stable stuff
<LocutusOfBorg> I'm almost completely confident about their testing and testsuite
<LocutusOfBorg> I can give you a changelog, hold on
<LocutusOfBorg> http://paste.ubuntu.com/24229715/
<slangasek> LocutusOfBorg: yes, but you also need to give the SRU team confidence of this - changelog or pointers to upstream testing or description of branch policy, please :)
<slangasek> thanks
<LocutusOfBorg> yes, well, I did such "big" updates a lot of times for xenial (.18 to .24 and then to .32)
<LocutusOfBorg> they were ways bigger then now, if you see, and exclude windows fixes, you will notice just a char encoding regression fixed on some usb devices with special chars
<LocutusOfBorg> and kernel fixes
<LocutusOfBorg> and crash fixes
<LocutusOfBorg> but I'll update the bug number
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox [source] (xenial-proposed) [5.0.36-0ubuntu1.16.04.2]
<infinity> chrisccoulson: So, I see no indication in the upstream bugs about intent to drop ALSA support or let it rot.  In fact, people go out of their way to mention over and over again that it's not removed, it's just not a part of the default build.
<infinity> chrisccoulson: If all we want is the default build, we may as well just bundle upstream's binary in a deb and call it done (note: sarcasm, that's very much not what I want, and we can do better)
<wxl> here here
<tsimonq2> wxl: Explain yourself. :P
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [source] (xenial-proposed) [5.0.36-0ubuntu1.16.04.2]
<LocutusOfBorg> slangasek, please ext-pack and guest additions too :)
<LocutusOfBorg> they share the same codebase
<wxl> tsimonq2: pulse does have a larger footprint than just alsa. i mean, it's not like you REMOVE alsa and exchange it with pulse. that's inconsistent with the lubuntu design criteria.
 * LocutusOfBorg leaves cheers
<wxl> tsimonq2: the last comment was in support of infinity's indication that alsa support *IS* still available and is maintained in firefox, so there's no reason not to have it in our packages.
<LocutusOfBorg> apw, please consider shipping virtualbox-modules in kernel too
<tsimonq2> wxl: Ok.
<tsimonq2> infinity, chrisccoulson: So any chance we can re-enable it and call it a day? ;)
<tsimonq2> :P
<wxl> tsimonq2: and actually also in support of infinity, when we made the switch from chromium to firefox, people upgrading did end up with two browsers. kind of sucked.
<tsimonq2> wxl: I see
<tsimonq2> Yeah, I think it's the best option to just re-enable it.
<wxl> still, not insurmountable
<wxl> i don't care if we go that route
<wxl> and even though pulse can tend to make things a little bit easier at times, i'm against forcing it on the user
<tsimonq2> wxl: So then why is it in the latest release of Lubuntu?
<tsimonq2> By default
-queuebot:#ubuntu-release- Unapproved: landscape-client (xenial-proposed/main) [16.03-0ubuntu2 => 16.03-0ubuntu2.16.04.1] (ubuntu-server)
<chrisccoulson> Sigh, there is a significant difference between "available" and "maintained", and I can assure you that it isn't maintained (firefox developers aren't maintaining code that's not part of their builds)
<wxl> tsimonq2: might want to check with gilir. maybe he did it to skirt around the "firefox bug"
<wxl> maybe we should call it firegate
<chrisccoulson> It's available to be maintained, so if you want to step up to do that, then great
<tsimonq2> I can't make that commitment.
<wxl> yeah me either
<wxl> i also don't remember anyone complaining about it
<wxl> so
<infinity> chrisccoulson: If it's your assertion that we don't build or link any code that doesn't have active upstream maintenance, there's a lot of the firefox tree you need to stop building.  The upstream configure default changed.  This is a regression in a stable release.  Please change it back.  If it breaks horribly at a later date, despite several other distros also enabling the feature, let's talk.
<wxl> maybe not actually an issue?
<tyhicks> infinity, wxl, tsimonq2: if chrisccoulson were to re-enable it in firefox builds, there's no way that he can be expected to fix future bugs in that portion of the code
<tyhicks> he simply doesn't have the time to sort out alsa issues and release security updates in a timely manner along with the oxide work that he does
<mapreri> May I have a suggestion on what to do with diffoscope's autopkgtest that timeouts on armhf?  I believe that even 10 minutes longer would be enough to have it pass, do you keep a manual list of timeouts that could be used to rise this one?
<tsimonq2> infinity, wxl, chrisccoulson: So what can we do about bugs that could arise in the future from re-enabling this?
<tsimonq2> Will one of us have to take a look and attempt to fix it, or is it really really complex code?
<infinity> tsimonq2: Realistically, any problem that arises won't be bit-rot in the scary parts, it'll be build failures due to the build system changing and someone forgetting to test the alsa build.  Other distros will almost certainly fix that quickly, the only problem is timing, ie: they might fix it three days after the upstream release, rather than before.
<tsimonq2> infinity: Ok, so given what tyhicks said, we're still ok to Ship It?
<chrisccoulson> other distros ship the ESR, so they're generally a few months behind us
<mdeslaur> infinity: well, the reason they disabled it is because they're adding 5.1 support and they can't add it to the alsa backend
<mdeslaur> not sure how trivial it will be to turn it back on once backends need to support 5.1
<infinity> tsimonq2: It's not my decision, per se (well, I could get into an upload war with Chris, but that never ends well).  I can, however, give a strong recommendation that we re-enable alsa, and if the build breaks, Chris can disclaim responsibility until someone else finds a patch to fix it.
<chrisccoulson> we'll re-enable it for now, but as tyhicks pointed out - that's not a committment from us to maintain this code
<infinity> mdeslaur: Again, that's just a question of defaults.  They want the out of the box experience to have simple 5.1 pass through.  Playback through alsa just won't do that.
<tsimonq2> infinity, chrisccoulson: Alright fair enough. Thanks for taking the time to talk about it!
<infinity> mdeslaur: I get the decision for the default build.  They don't want people to accidentally have a degraded experience that makes their product look crap.
<chrisccoulson> And code that isn't part of mozilla's build does bit-rot, and generally fairly quickly. I'm acutely aware of this from working on it for many years ;)
<tyhicks> from what chrisccoulson is saying, I can't imagine it continuing to work throughout the life of 16.04
<infinity> He's discounting the part where several other distros (including two whose users regularly build edge channels from source every day) are re-enabling it.
<infinity> Yes, fixes might lag a day or two behind upstream releases, but they'll be out there up until the code is entirely removed instead.
<wxl> this is certainly something we should document on the wiki and announce to lubuntu-users/devel, @tseliot
<wxl> ugh
<wxl> i mean tsimonq2
<infinity> Anyhow.  I need ice cream.  Which is totally an appropriate thing for a responsible adult to eat for lunch, and don't tell me otherwise.
<tsimonq2> infinity: What type?
<tsimonq2> infinity: I like cookie dough but I think regular vanilla is good.
<tsimonq2> :P
<tsimonq2> wxl: Later.
<tsimonq2> infinity made me want ice cream now. :P
<wxl> tsimonq2: and i still think we should consider switching back to chromium
-queuebot:#ubuntu-release- Unapproved: variety (xenial-proposed/universe) [0.6.0-1 => 0.6.0-1ubuntu1] (no packageset)
<wxl> or at least discuss it
-queuebot:#ubuntu-release- Unapproved: variety (yakkety-proposed/universe) [0.6.2-1 => 0.6.2-1ubuntu1] (no packageset)
<tsimonq2> wxl: I'm against that, but that discussion is for a different day and a different channel. ;)
<wxl> and we NEED to get pulse out
<tsimonq2> wxl: If sound breaks enough on Firefox, then yeah
<apw> philroche, hey... the yakkety gce-c-i-p was not built with an apporpriate -v so it has no bugs associated with it
-queuebot:#ubuntu-release- Unapproved: gnome-documents (zesty-proposed/universe) [3.23.91-0ubuntu1 => 3.24.0-0ubuntu1] (desktop-extra, ubuntugnome)
<apw> philroche, xenial look to be the same, though trusty is seemingly ok
<philroche> apw. Strange. how can I fix this?
<mapreri> apw: you have been the -release person for a while for me, do you think you can help me with:
<mapreri> [06:51:36 PM] <mapreri> May I have a suggestion on what to do with diffoscope's autopkgtest that timeouts on armhf?  I believe that even 10 minutes longer would be enough to have it pass, do you keep a manual list of timeouts that could be used to rise this one?
<apw> philroche, when you make the source pacakge you add -v<version in -updates> and the appropriate bits get added to the .changes file
<apw> mapreri, diffoscope testing takes too long ?
<mapreri> apw: only in armhf, apktool is very slow there for some reason
<apw> mapreri, lovely
<mapreri> we could run without apktool, but I would like to run it on the other archs, and also I would not like to do it within the test code (which would affect also non-autpkgtest and other distributions not having this timeout)
<mapreri> in fact, just not installing it is enough for the test to be skipped, but I don't know of a way to say "don't install apktool if armhf" within autopkgtest metadata.
<apw> mapreri, i think i can tell things that one is slow, looking now
<mapreri> apw: thank you, I appreciate whatever you can do :)
-queuebot:#ubuntu-release- Unapproved: virtualbox (xenial-proposed/multiverse) [5.0.36-0ubuntu1.16.04.2 => 5.0.36-dfsg-0ubuntu1.16.04.2] (ubuntu-cloud)
<apw> mapreri, trying to work out how to roll the change out, so it might take till tomorrow to work that out
<apw> mapreri, then we can retry it
<mapreri> oh, nice nice!
<mapreri> apw: so there is a list of timeout overrides somewhere? :)
<mapreri> apw: and I'm in no hurry at all, any time/day will be fine
<apw> mapreri, yeah there is a list, which i know how to update for the primary scaling stack bits, not for the arm* runners
<apw> mapreri, anyhow i have asked my guru and will let you know when i've got there
<mapreri> apw: greaat, thank you! â¥
<LocutusOfBorg> slangasek, ^^ please accept virtualbox, I renamed the tarball to version-dfsg
<LocutusOfBorg> (damn uupdate)
<LocutusOfBorg> virtualbox-* I mean
<slangasek> LocutusOfBorg: ok, checking
<LocutusOfBorg> ta
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [source] (xenial-proposed) [5.0.36-dfsg-0ubuntu1.16.04.2]
<LocutusOfBorg> thanks!
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [source] (xenial-proposed) [5.0.36-0ubuntu1.16.04.2]
<LocutusOfBorg> <2
<slangasek> that's a bit of a half-hearted response ;)
<nacc> heh
<LocutusOfBorg> virtualbox-guest-additions-iso? :)
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-guest-additions-iso [source] (xenial-proposed) [5.0.36-0ubuntu1.16.04.2]
<apw> slangasek, ohhhhh man
<LocutusOfBorg> <3
<LocutusOfBorg> now we are good
<LocutusOfBorg> :)
<slangasek> apw: are you bothered by the pun or by the inexact math? :)
<apw> slangasek, both in equal measure ...
<slangasek> :D
<apw> :-p
 * LocutusOfBorg leaves, for real :D thanks you all!
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (yakkety-proposed/universe) [20160930-0ubuntu5~16.10.0 => 20160930-0ubuntu6~16.10.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20160930-0ubuntu5~16.04.0 => 20160930-0ubuntu6~16.04.0] (ubuntu-cloud)
<philroche> apw: gce-c-i-p for yakkety and xenial has been reuploaded
<philroche> .. with the appropriate bits added to the .changes file as requested.
<apw> philroche, thanks
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (yakkety-proposed) [20160930-0ubuntu6~16.10.0]
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (xenial-proposed) [20160930-0ubuntu6~16.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (yakkety-proposed) [20160930-0ubuntu6~16.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (xenial-proposed) [20160930-0ubuntu6~16.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (trusty-proposed) [20160930-0ubuntu3~14.04.2]
-queuebot:#ubuntu-release- Packageset: Added linux-aws to kernel in xenial
-queuebot:#ubuntu-release- Packageset: Added linux-gke to kernel in xenial
-queuebot:#ubuntu-release- Packageset: Added linux-meta-aws to kernel in xenial
-queuebot:#ubuntu-release- Packageset: Added linux-meta-gke to kernel in xenial
-queuebot:#ubuntu-release- Packageset: Added linux-aws to kernel in yakkety
-queuebot:#ubuntu-release- Packageset: Added linux-gke to kernel in yakkety
-queuebot:#ubuntu-release- Packageset: Added linux-meta-aws to kernel in yakkety
-queuebot:#ubuntu-release- Packageset: Added linux-meta-gke to kernel in yakkety
-queuebot:#ubuntu-release- Packageset: Added linux-aws to kernel in zesty
-queuebot:#ubuntu-release- Packageset: Added linux-gke to kernel in zesty
-queuebot:#ubuntu-release- Packageset: Added linux-meta-aws to kernel in zesty
-queuebot:#ubuntu-release- Packageset: Added linux-meta-gke to kernel in zesty
-queuebot:#ubuntu-release- Unapproved: makedev (zesty-proposed/universe) [2.3.1-93ubuntu1 => 2.3.1-93ubuntu2] (lubuntu)
<infinity> cyphermox: Can you make sense of https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1675127 ?
<ubot5> Ubuntu bug 1675127 in ubiquity (Ubuntu) "ubiquity crashed with TypeError in __new__(): 'NoneType' object is not iterable" [Medium,New]
<lynorian> original reporter here and it is quite wierd conditions to trigger but I did get it to happen like three times
<lynorian> infinity, ^
<lynorian> plugging in to ethernet does not cause a problem and I did not get the crash on another laptop on the wifi setup page
<lynorian> the laptop I got the crash with did not have the problem of if I just plugged in ethernet
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: unity-settings-daemon (zesty-proposed/main) [15.04.1+16.10.20161003-0ubuntu1 => 15.04.1+17.04.20170322-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-themes-standard (zesty-proposed/main) [3.22.2-1ubuntu1 => 3.22.3-1ubuntu1] (ubuntu-desktop)
<jbicha> glib2.0/zesty autopkgtests finally passed; if you want to unblock gdk-pixbuf and glib2.0, I can respin Ubuntu GNOME and drop LP: #1665602 from the UG release notes
<jbicha> otherwise, not a big deal, they'll get the fix after beta freeze is lifted
<infinity> jbicha: That would trigger a world respin, if I wanted things in sync.  If you're okay with just noting that bug, that's less icky.
<jbicha> that's fine, the bugfix took a long time to finally get into Ubuntu, one more day won't hurt :)
<infinity> sakrecoer: There don't seem to be any test results for Studio for Beta2.  Is someone on that?
<wxl> infinity: you aren't anxious to publish already are you?
<infinity> jbicha: I assume that means I'll see results for gnome soonish? :)
<infinity> wxl: Not publishing until tomorrow, but I'll sleep better if I know things are ready. :P
<jbicha> yes, I'm working on it now
<wxl> lubuntu's almost done and i think i need to kick my kubuntu tester's some but as long as you're not doing it NOW, that' sok :)
<infinity> wxl: Yeah.  The testing board is looking promising.  Some minor bugs to address for Final, but nothing looks beta-critical, which is nice.  Maybe we'll actually ship our first RC spin for once.  That would be novel.
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: at-spi2-core (zesty-proposed/main) [2.22.0-5ubuntu3 => 2.22.0-5ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: xfce4-notifyd (zesty-proposed/universe) [0.3.5-1 => 0.3.6-0ubuntu1] (xubuntu)
<Ukikie> â Butfix release, entire changelog is in the upload.  Memleak fix, etc.  Biggest non-bugfix is translation updates.
<piem> howdy. i'm trying to find out why aubio is not being updated to the latest version from debian. it's been there in 'proposed' for quite a few weeks now
<piem> i've been pointed at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#aubio, so i'm poking here
<slangasek> piem: if you look at the reverse-depends, you'll see that ardour has an unsatisfiable dependency on xjadeo (>= 0.6.4).  Since this is an soname transition, the packages can't go in unless they're all consistently installable
<slangasek> xjadeo exists but is in multiverse
<slangasek> in Debian, xjadeo is in universe
<slangasek> s/universe/main/ :P
#ubuntu-release 2017-03-23
-queuebot:#ubuntu-release- Unapproved: gnome-todo (zesty-proposed/universe) [3.22.1-1 => 3.22.1-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-todo [sync] (zesty-proposed) [3.22.1-2]
<slangasek> looks like xjadeo in multiverse is a historical inaccuracy; promoting to universe now
<slangasek> piem: that's the first half of it; the second half is that, since this package is seeded on the ubuntustudio image and we're in beta freeze, we should only unblock it now in coordination with the ubuntustudio team
<piem> slangasek: i see. so there is something i could do to close #1639409? ... oh, did you just close it? :)
<piem> slangasek: understood, thanks. there is a bunch of tests in aubio, and they are run at build time. if i can help convincing someone from ubuntustudio to do that, i'd be glad to help
<slangasek> yeah, closing the bug now
<slangasek> krytarik: ^^ are you the best person to speak to letting aubio in right now?
<jbicha> there's quite a few ~ubuntu-archive bugs for when you get bored, like bug 1601953
<ubot5> bug 1601953 in mame (Ubuntu) "MAME should move from multiverse to universe" [Undecided,New] https://launchpad.net/bugs/1601953
<krytarik> slangasek: Well, I'm not in any official position in the Studio team - but I don't think we care much about something minor like that, given what all we ship, if it sounds sensible generally. :P
<krytarik> And piem just asked in our devel channel too - so Len might be bothered to give an official response.
<piem> krytarik: did you mean that you think 'we don't mind doing it' or 'we don't care about it'? certainly not minor to me, upstreamwise :P
<krytarik> piem: No, I mean the change might be major or minor to the package - but the package itself isn't something like e.g. Ardour or Krita to us.
-queuebot:#ubuntu-release- Unapproved: system-config-printer (zesty-proposed/main) [1.5.7+20160812-0ubuntu6 => 1.5.7+20160812-0ubuntu7] (kubuntu, ubuntu-desktop)
<piem> krytarik: sure, i got that, but that doesn't really answer my question. :-)
<slangasek> krytarik: except that ardour itself needs to be updated as part of the transition, so...
<slangasek> and that's an update from 1:50~dfsg-2 to 1:5.5.0~dfsg-1 which no one handled until now
<krytarik> I know - I was at the relevant bug report earlier.
<slangasek> infinity: systemd 232-20ubuntu1 is nearly ready to go wrt autopkgtests; how do you want to handle this vis-Ã -vis final beta?
<krytarik> slangasek, piem: Well, the versions of both packages sitting in -proposed currently are in Debian for 3 months now, and I don't see any new bugs reported on them - so I guess we should be good. :P
<sbeattie> Hi, not sure if there's an SRU person about. For bug 1668934, the percona-xtradb-cluster-5.6, percona-xtrabackup, and percona-galera-3 packages were promoted to (xenial|yakkety)-updates; they should also be pocket copied to the respective -security pockets; the packages were built in the ubuntu-security-proposed ppa to get binaries built with only -security enabled. (cc jamespage)
<ubot5> bug 1668934 in percona-xtradb-cluster-5.6 (Ubuntu Zesty) "percona-xtradb-cluster-5.6 5.6.34-26.19, percona-galera-3 3.19, percona-xtrabackup 2.3.7" [High,Fix released] https://launchpad.net/bugs/1668934
-queuebot:#ubuntu-release- Unapproved: pidgin-librvp (zesty-proposed/universe) [0.9.7cvs-1ubuntu1 => 0.9.7cvs-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted pidgin-librvp [sync] (zesty-proposed) [0.9.7cvs-1.1]
-queuebot:#ubuntu-release- Unapproved: scim-canna (zesty-proposed/universe) [1.0.0-4.2ubuntu2 => 1.0.0-4.3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted scim-canna [sync] (zesty-proposed) [1.0.0-4.3]
<tsimonq2> aaaaaa/or
<tsimonq2> Argh
<infinity> slangasek: Don't unblock anything.  I'll be removing the large block in the morning anyway.
<slangasek> infinity: copy
<infinity> slangasek: paste
<infinity> sakrecoer: Any news on UbuntuStudio Beta testing?
-queuebot:#ubuntu-release- Unapproved: ladish (zesty-proposed/universe) [1+dfsg0-5ubuntu3 => 1+dfsg0-5.1] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: gitlab (zesty-proposed/universe) [8.13.11+dfsg-3 => 8.13.11+dfsg-7] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gitlab [sync] (zesty-proposed) [8.13.11+dfsg-7]
-queuebot:#ubuntu-release- Unapproved: clutter-gtk (zesty-proposed/main) [1.8.2-1 => 1.8.2-2] (kubuntu, ubuntu-desktop) (sync)
<tsimonq2> Oh come on, don't interrupt my 3 AM hacking session stupid conflicts >__<
<tsimonq2>  build-essential : Depends: libc6-dev but it is not going to be installed or
<tsimonq2>                             libc-dev
<tsimonq2>                    Depends: g++ (>= 4:5.2) but it is not going to be installed
<tsimonq2> This is on Yakkety.
<tsimonq2> So I guess I'm using an LXD container. :/
<tsimonq2> Ha ha, I forgot to enable -updates, ignore me... :P
-queuebot:#ubuntu-release- Unapproved: systemd (zesty-proposed/main) [232-20ubuntu1 => 232-21ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: python-keyring (zesty-proposed/main) [10.1-1 => 10.3.1-1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: dockerpty (xenial-proposed/universe) [0.3.4-1build1 => 0.4.1-1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: dockerpty (xenial-proposed/universe) [0.3.4-1build1 => 0.4.1-1~16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-docker (xenial-proposed/universe) [1.8.0-0ubuntu1 => 1.9.0-1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-docker (xenial-proposed/universe) [1.8.0-0ubuntu1 => 1.9.0-1~16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: docker-compose (xenial-proposed/universe) [1.5.2-1 => 1.8.0-2~16.04.1] (no packageset)
<mwhudson> argh those ~16.10 versions for xenial :(
-queuebot:#ubuntu-release- Unapproved: python-docker (yakkety-proposed/universe) [1.8.0-0ubuntu1 => 1.9.0-1~16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: docker-compose (yakkety-proposed/universe) [1.5.2-1 => 1.8.0-2~16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: mustang (zesty-proposed/universe) [3.2.3-1 => 3.2.3-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted mustang [source] (zesty-proposed) [3.2.3-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubuntukylin-default-settings (zesty-proposed/universe) [1.3.17 => 1.3.18] (ubuntukylin)
<caribou> howdy, can someone reject the sssd upload on Trusty made yesterday ? Apparently the fix is failing verification on the other releases in -proposed
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Zesty Beta 2] has been marked as ready
<rbasak> caribou: done
<caribou> rbasak: thanks!
-queuebot:#ubuntu-release- Unapproved: rejected sssd [source] (trusty-proposed) [1.11.8-0ubuntu0.6]
<LocutusOfBorg> will some AA work on remove boost1.61 from zesty?
<LocutusOfBorg> the three reverse-deps are 1) fixed in branch 2) runtime deps for mir I can upload but I pinged the maintainer on -devel 3) a package that might probably disappear according to LP: #1640317
<LocutusOfBorg> http://people.canonical.com/~ubuntu-archive/transitions/html/boost1.62.html
<ubot5> Launchpad bug 1640317 in aethercast (Ubuntu) "FTBFS in zesty" [Critical,In progress] https://launchpad.net/bugs/1640317
<LocutusOfBorg> currently we have both boost1.61 and 1.62 in main :/
-queuebot:#ubuntu-release- Unapproved: gitlab-shell (zesty-proposed/universe) [3.6.6-3 => 3.6.6-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gitlab-shell [sync] (zesty-proposed) [3.6.6-4]
<mapreri> LocutusOfBorg: I'm working out mir in #ubuntu-mir, 0.26.2-1 will be done through bileto, then we can upload -2 switching the deps (and their next 0.26.3-1 will include the change).
<mapreri> or whatever version will be the next
<LocutusOfBorg> do you have a sponsor
<mapreri> yes, you :P
<LocutusOfBorg> lol so, ping in case
<mapreri> the other 2 still needs taking care, though
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-70.91] (core, kernel)
<LocutusOfBorg> one is fixed in trunk, so just upload
<LocutusOfBorg> the next upload will overwrite it
<mapreri> On another matter, why is imagemagick still stuck in proposed?
<LocutusOfBorg> emacs25
<LocutusOfBorg> arm64
<mapreri> emacs25 depends on imagegick
<mapreri> also the reverse?
<LocutusOfBorg> how can it migrate if reverse-deps can't migrate
<jbicha> mapreri: it's a library transition
<mapreri> jbicha: oh, didn't spot that.
<mapreri> why ubuntu doesn't do smooth transitions :|
<jbicha> because we don't want obsolete libraries lying around when we release every 6 months
<mapreri> the solution is a 6 months freeze! :>
<LocutusOfBorg> sure releasing once a year might be better, we don't have such need of new releases anymore
<LocutusOfBorg> I stopped updating my ubuntu twice an year some time ago, specially now that we have LTS
<mapreri> ? LTS have always been around
<LocutusOfBorg> one normal, one LTS, one normal, one LTS
<LocutusOfBorg> yes, but they were less stable than now, and supported for less years
<LocutusOfBorg> now that the infra-LTS releases are supported only for 9 months... I think even less users are using them
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Zesty Beta 2] has been marked as ready
<rbasak> One used to be able to jump up multiple non-LTS releases. Now if you go non-LTS you have to be on the treadmill. But that's not so bad; there's still a choice of two treadmills.
-queuebot:#ubuntu-release- Unapproved: maliit-framework (zesty-proposed/universe) [0.99.1+git20151118+62bd54b-0ubuntu13~2 => 0.99.1+git20151118+62bd54b-0ubuntu14] (ubuntu-qt-packages) (sync)
<Laney> robru: looks like we emailed everyone again, oops
-queuebot:#ubuntu-release- Unapproved: network-manager (zesty-proposed/main) [1.4.4-1ubuntu2 => 1.4.4-1ubuntu3] (kubuntu, ubuntu-desktop)
<mapreri> tbh, I think it's fine to send a reminder every week or so about stuck packages.
-queuebot:#ubuntu-release- Unapproved: qmenumodel (zesty-proposed/main) [0.2.11+17.04.20170110.1-0ubuntu1 => 0.2.12+17.04.20170316.1-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: qtmir (zesty-proposed/main) [0.5.1+17.04.20170307-0ubuntu1 => 0.5.1+17.04.20170320.1-0ubuntu1] (ubuntu-desktop, ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: qtubuntu (zesty-proposed/main) [0.64+17.04.20170308-0ubuntu1 => 0.64+17.04.20170320-0ubuntu1] (ubuntu-desktop, ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: qtmir-gles (zesty-proposed/universe) [0.5.1+17.04.20170307-0ubuntu1 => 0.5.1+17.04.20170320.1-0ubuntu1] (ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: qtubuntu-gles (zesty-proposed/universe) [0.64+17.04.20170308-0ubuntu1 => 0.64+17.04.20170320-0ubuntu1] (ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: unity-api (zesty-proposed/main) [8.4+17.04.20170223-0ubuntu1 => 8.6+17.04.20170317-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: unity8 (zesty-proposed/main) [8.15+17.04.20170308-0ubuntu1 => 8.15+17.04.20170321-0ubuntu1] (ubuntu-desktop, ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.8.0-44.47~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-44.47] (core, kernel)
<jbicha> mapreri: there was a proposal to send reminder emails every day(!)
<mapreri> jbicha: well, that might be a tad too eccessive :)
<Laney> mapreri: it was actually due to landing a branch which emails people at intervals :)
<mapreri> ^^
<Laney> maybe these were just the second reminders then
-queuebot:#ubuntu-release- Unapproved: system-config-printer (zesty-proposed/main) [1.5.7+20160812-0ubuntu6 => 1.5.7+20160812-0ubuntu8] (kubuntu, ubuntu-desktop)
<jibel> powersj, Hey, could you update the iso tracker with the results for ubuntu server http://iso.qa.ubuntu.com/qatracker/milestones/374/builds
<powersj> jibel: sure!
<jibel> powersj, thanks!
<robru> Laney: yeah i think it's expected to resend mails to everybody as it's been above the threshold time for resending mails anyway. It should settle down after the first round of mails
<Laney> nod
<davmor2> jibel, powersj: okay second install of server via netboot mini.iso and this is http://people.canonical.com/~davmor2/personal-screenshots/login.png the login I get
<davmor2> if I switch tty I get a proper prompt as do I if I login from ssh
<powersj> davmor2: let me try the netboot iso I don't normally test that one
<Laney> slangasek: bug #1672542 FYI
<ubot5> bug 1672542 in systemd (Ubuntu) "systemd 232-18ubuntu1 ADT test failure with linux 4.10.0-13.15" [Undecided,New] https://launchpad.net/bugs/1672542
<powersj> davmor2: what is the md5sum of your mini.iso? wanna make sure I'm downloading the same
-queuebot:#ubuntu-release- New sync: nama (zesty-proposed/primary) [1.208-1]
<davmor2> powersj: b2b5c9beb3512059b2d49af67237da62  Downloads/mini32.iso  d9b91090a6af37f6eb0f77e7a0f90c1e  Downloads/mini64.iso  I added the 32 and 64 or it overwrites the images :)
<powersj> davmor2: ok install started; you said 2nd install though, so install once and then install again and see if I get the black screen?
<davmor2> powersj: no installed amd64 failed there, installed i386 to double check it and it failed there too
<powersj> davmor2: oh ok, thx
<slangasek> Laney: ah, so it's genuinely regressed against new kernel?
<Laney> slangasek: seems so to me, warrants a deeper look
<slangasek> right
<powersj> davmor2: I get the blinking cursor was well with two messages about /dev/sda1 recovering journal and clean
<powersj> davmor2: file a bug and we can update the test tracker with the #
<davmor2> powersj: right and then if you switch tty everything is as expected and you can login as normal right?
<davmor2> powersj: will do
<powersj> davmor2: and yes changing tty gets me to a prompt that I can interact with and login
<powersj> and going back to tty1 then works as expected
<davmor2> I'm assuming plymouth isn't being killed
<davmor2> powersj: went for the lowest element so we can build up from it https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1675453
<ubot5> Ubuntu bug 1675453 in debian-installer (Ubuntu) "During d-i install of ubuntu-server from mini.iso I get no login prompt" [Undecided,New]
<powersj> davmor2: thanks for catching this and looking at those ISOs
<slangasek> Laney, robru, bdmurray, infinity: 5 minutes here for a coffee refresh, please
<robru> Ok
<bdmurray> slangasek: hopefully not in a microwave
<slangasek> bdmurray: grinding fresh beans
<davmor2> powersj: so just done a server install it isn't there so it looks like it is because the mini.iso/netboot will use plymouth and display the ubuntu and dots and that isn't being killed correctly
<davmor2> I'll update the bug
<slangasek> Laney, infinity, bdmurray: so certainly, for SRUs I think the earliest we want to email would be 10 days... because a Friday publication won't release until Monday
<bdmurray> slangasek: Maybe 11 then since it won't happen first thing on Monday
<slangasek> ok
<slangasek> and beyond that 11 day delay, do we think the same nag rules should apply?
<infinity> I'm somewhat lacking an opinion on this one.
<bdmurray> 11 + 5, then some more backing off?
<slangasek> I think my big concern is whether we're nagging the right person if we go after the uploader/sponsor
<slangasek> if the bugs are v-needed, v-failed, and the uploader can't do anything
<slangasek> aside from pass on the nag
<slangasek> but maybe that's appropriate anyway?
<bdmurray> if its v-needed they can act
<infinity> They're the one that sponsored it, they're responsible for it.
<Laney> I'm wondering if britney's the right thing for SRUs
<slangasek> uh
<Laney> If they're fixing bugs, then we can nag on bugs
<infinity> Well, britney's useful for SRUs, but agreed, maybe the britney MAIL isn't.
<Laney> Yes, for emailing
<slangasek> oh, for emailing, yes :)
<infinity> sru-report already has a bug-nagging facility.
<infinity> Which reaches more people than just the uploader.
<Laney> Might be that it's better to beef that up
<chrisccoulson> slangasek, I just noticed that the flash packages you approved last week are still in proposed. They're good to move to release
<Laney> Like, make sure the uploaders are subscribed and nag more often
<slangasek> chrisccoulson: remind me the full package name please so I can swap in context :)
<slangasek> adobe-flashplugin?
<bdmurray> Maybe the uploader is subscribed check should happen before accepting the SRU
<infinity> slangasek: yes.
<chrisccoulson> slangasek, that's the one :)
<bdmurray> That just seems like a reasonable change to the SRU process
<slangasek> bdmurray: or driven by the sru-review script itself
<bdmurray> Yeah, that's what I meant.
<slangasek> as in just subscribe them
<Laney> Sure, I'm just thinking that for nagging purposes, that's one way to get them to get the mails
<Laney> That part can happen at a few different times
<slangasek> so it seems like we should leave britney out of the SRU nagmail business for right now
<slangasek> and instead beef up the notifications in the sru tools
<slangasek> yes?
<robru> So did we agree then? Britney won't send nag mails for SRUs
<bdmurray> okay
<robru> Ok
<infinity> +1
<Laney> Ok, so can we talk about the backoff for the development series quickly before robru goes and changes it?
<robru> What about it?
<slangasek> ok
<Laney> you know what; I said on the MP :)
<slangasek> Laney: we weren't talking about changing the backoff however
<slangasek> only the date of the initial nag
<slangasek> s/date/delay/
<Laney> well, the algorithm as landed sends mail at 3, 6, 12 days
<Laney> the previous proposal was 1, 2, 4, ...
<Laney> I was arguing on the MP that this was too aggressive
<slangasek> I don't particularly care about the length of the backoff
<slangasek> I mean, I have my opinion, but I know there's not a consensus
<Laney> Good, because I agree that nagging and backing off is fine
<slangasek> but it really should start as soon as the package looks stuck - so 1 day, not 3
<Laney> I just don't think sending mail that frequently is fine :P
<infinity> I'm not sure how useful the first mail at 1 day is, but meh.
<slangasek> infinity: it's the 90% case
<infinity> 90% of what?
<slangasek> of all the things
<Laney> like I would probably say that there should be an interval of at least (say) 3 days between mailing about the same thing
<slangasek> 90%+ of uploads that need no intervention will have migrated within 24h
<robru> Ok but the thing is that the current algo does not make a distinction between "time of first nag" and "backoff frequency". If you set the first nag to 1 day you get 1, 2, 4, etc. Set it to day 3 and it's 3, 6, 12, etc
<Laney> and, that said, I would prefer if someone else reviewed the branch this time. :P
<infinity> Of all SRUs stuck for 1 day, how many will unstick without intervention?
<slangasek> infinity: not SRUs. we're on the devel series again
<slangasek> 90% of packages not migrated after 1 day require intervention
<infinity> Err, uploads.  Sorry.
<infinity> Didn't mean SRUs.
<slangasek> k
<slangasek> robru: so then the code needs fixed?
<infinity> Your statistics look suspiciously made-up. ;)
<infinity> Which might be fine for presidential tweets, but I dunno about here.
<robru> slangasek: no, your expectations need fixed because my code is really simple and elegant
<slangasek> infinity: that's why I only used one significant figure
<slangasek> robru: har
<Laney> robru: what do you know? how many days ago you last mailed?
<infinity> He knows how long it's been in proposed.
<Laney> there's a cache file too
<slangasek> chrisccoulson: adobeflashpluginpromoted
<robru> Laney: yeah it just compares the day off the last mail to the overall age and it's able to work out the decreasing frequency with a simple comparison. But the "day off first mail" and "frequency between mails" is basically the same number, can't change one without the other being affected
<Laney> once in the first year of school I wrote a story and forgot to put any spaces in between the words
<Laney> The teacher made me write the whole thing out again
-queuebot:#ubuntu-release- Unapproved: content-hub (zesty-proposed/main) [0.3+17.04.20170313-0ubuntu1 => 0.3+17.04.20170317.1-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: indicator-datetime (zesty-proposed/main) [15.10+17.04.20170309-0ubuntu1 => 15.10+17.04.20170322-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: indicator-power (zesty-proposed/main) [12.10.6+17.04.20170210-0ubuntu1 => 12.10.6+17.04.20170322-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: indicator-bluetooth (zesty-proposed/main) [0.0.6+17.04.20170207-0ubuntu1 => 0.0.6+17.04.20170322-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: indicator-network (zesty-proposed/main) [0.9.0+17.04.20170116-0ubuntu1 => 0.9.0+17.04.20170322-0ubuntu1] (ubuntu-desktop) (sync)
<chrisccoulson> slangasek, thanks :)
<infinity> robru: Make the first one be freqint^0, boom, 1 day.
-queuebot:#ubuntu-release- Unapproved: game-data-packager (zesty-proposed/multiverse) [48 => 49] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-app-launch (zesty-proposed/main) [0.10+17.04.20170310-0ubuntu1 => 0.11+17.04.20170321-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: url-dispatcher (zesty-proposed/main) [0.1+17.04.20170314-0ubuntu1 => 0.1+17.04.20170318-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: libertine (zesty-proposed/main) [1.7+17.04.20170313-0ubuntu1 => 1.7+17.04.20170320.1-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-system-settings (zesty-proposed/main) [0.4+17.04.20170301-0ubuntu1 => 0.4+17.04.20170317.2-0ubuntu1] (ubuntu-desktop) (sync)
<Laney> Omg
<Laney> Those packages are the "drop upstart" ones
<slangasek> Laney:HISTORICALLYACCURATELATININSCRIPTION
<infinity> Laney: !!!
-queuebot:#ubuntu-release- Unapproved: accepted game-data-packager [sync] (zesty-proposed) [49]
-queuebot:#ubuntu-release- Unapproved: iortcw (zesty-proposed/multiverse) [1.50a+dfsg1-2 => 1.50a+dfsg1-3] (no packageset) (sync)
<infinity> Is it my birthday?
<slangasek> infinity, robru: freqint^0 implies that we're exponential forever, rather than having a max interval which I believe we said should be 30 days
<slangasek> well, maybe it doesn't imply that
<robru> infinity: yeah there's no exponent in the code. What you describe would require having one corner case for "is this first mail ever"and then handling the general case differently. What i like about the current code is that there's no corner case, it handles all mails with the same code
-queuebot:#ubuntu-release- Unapproved: accepted iortcw [sync] (zesty-proposed) [1.50a+dfsg1-3]
<infinity> slangasek: The max interval is configured separately, and is currently 30.
<slangasek> robru: why is there no exponent in the code that is supposed to be doing exponential backoff?
<Laney> I'll go away and let you argue about the implementation now you know my opinion. :)
<Laney> thanks all!
<slangasek> Laney: thanks :)
<robru> slangasek: because math? I dunno man, somehow dividing by 2 resulted in the exponential frequency we observe. I'm not a mathemagician.
<robru> slangasek: seriously though: (age - sent_age) < min(MAX_FREQUENCY, age / 2.0)
<robru> I guess it's because age is on both sides of that comparison it has an exponential effect or something
<infinity> What you have isn't exponential, it's... Young Adam's math vocabulary failing.
<slangasek> right; that explains also why it's 2^n intsead of x^n :)
<infinity> But 3, 6, 12 isn't exponential.
<slangasek> infinity: exponential with a coefficient
<slangasek> a*2^n vs. b^n
<infinity> Ahh, fair.
<robru> right
<slangasek> anyway
<slangasek> robru: I don't care about a*2^n vs. b^n, but it does need fixed to start on day 1 :)
<robru> slangasek: right, so the easiest way to do that is just have it do 1, 2, 4, 8, 16, etc. if that's ok with you that'd be my preference in terms of simplicity. if you want 1, 3, 6, 12 then that throws a wrench in things
<slangasek> robru: and to respect Laney's requirement not to send the second mail right away on day 2
-queuebot:#ubuntu-release- Unapproved: landscape-client (yakkety-proposed/main) [16.03-0ubuntu2 => 16.03-0ubuntu2.16.10.1] (ubuntu-server)
<slangasek> robru: the code needs to meet both of the requirements that Laney and I have laid out
<slangasek> robru: so you'll need to lose the simplicity
<robru> slangasek: ok
<slangasek> robru: thanks :) still something you can get to today?
<robru> Laney: wait, your branch isn't merged?
<robru> slangasek: yeah I can do it today, will just take me a bit to figure out how to meet both of those requirements simultaneously
<Laney> robru: is now, was waiting for you to review :-)
<infinity> robru: After the fun math, if !sent && sent_age=0 && age>=24h, send?
<robru> infinity: yeah something like that. I'm going to spend a few minutes trying to think if I can futz the formula to keep it simple though. I hate corner cases
<infinity> robru: Then your coeffient just controls the frequency after the 1-day mail, but we always assume that the first is at a day.
<infinity> robru: Without rewriting it to let you leverage x^0, I think the corner-case is the simplest path.
-queuebot:#ubuntu-release- Unapproved: landscape-client (trusty-proposed/main) [14.12-0ubuntu0.14.04 => 14.12-0ubuntu5.14.04] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: transgui (zesty-proposed/universe) [5.0.1-4 => 5.0.1-4.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted transgui [source] (zesty-proposed) [5.0.1-4.1ubuntu1]
<flexiondotorg> infinity Do you (someone else) have an ETA for zesty beta 2 release?
<infinity> flexiondotorg: Today.
<infinity> flexiondotorg: If you're after exact times -- No.
<flexiondotorg> If you could release just after I've read betime stories with my daughter, that would be grand. Thanks :-)
<robru> slangasek: ok please merge: https://code.launchpad.net/~robru/britney/+git/britney2-ubuntu/+merge/320837
-queuebot:#ubuntu-release- Unapproved: curtin (zesty-proposed/main) [0.1.0~bzr470-0ubuntu1 => 0.1.0~bzr479-0ubuntu1] (ubuntu-server)
<flocculant> jibel: getting a drupal error at iso.qa PDOException: SQLSTATE[08006] [7] FATAL:
<jbicha> me too
<jibel> flocculant, jbicha I see it too: too many connections :/
<jibel> looking
<jibel> too many people testing zesty ;)
<davmor2> me too :'(
-queuebot:#ubuntu-release- Unapproved: transgui (zesty-proposed/universe) [5.0.1-4.1ubuntu1 => 5.0.1-4.1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted transgui [source] (zesty-proposed) [5.0.1-4.1ubuntu2]
<jibel> flocculant, davmor2 jbicha it should be better now.
<davmor2> yay back in
<flocculant> jibel: thanks :)
<flocculant> just needed to mark stuff ready - before I got told off :D
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (zesty-proposed/main) [2.439 => 2.440] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (zesty-proposed) [2.440]
-queuebot:#ubuntu-release- Unapproved: accepted juju-mongodb3.2 [source] (yakkety-proposed) [3.2.12-0ubuntu1~16.10]
-queuebot:#ubuntu-release- Unapproved: accepted juju-mongodb3.2 [source] (xenial-proposed) [3.2.12-0ubuntu1~16.04]
-queuebot:#ubuntu-release- Unapproved: mediascanner2 (zesty-proposed/universe) [0.112+17.04.20170302-0ubuntu1 => 0.112+17.04.20170322-0ubuntu1] (no packageset) (sync)
<bdmurray> slangasek: bug 1637290 is marked v-failed (by you) and rcj uploaded a new livecd-rootfs based upon the livecd-rootfs upload for that bug. Can livecd-rootfs be released even though that bug is v-failed?
<ubot5> bug 1637290 in shim (Ubuntu Yakkety) "Update to the signed 0.9+1474479173.6c180c6-0ubuntu1 shim binary from Microsoft" [Undecided,New] https://launchpad.net/bugs/1637290
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Zesty Beta 2] has been marked as ready
<slangasek> bdmurray: I don't have any recollection of livecd-rootfs being involved in the shim bug.  cyphermox ^^ ?
<slangasek> ah this is about a change in the names of the efi executables being installed
-queuebot:#ubuntu-release- Unapproved: pencil2d (zesty-proposed/universe) [0.5.4+git20170307.c5d8817+dfsg-1 => 0.5.4+git20170323.ec4712d+dfsg-1] (edubuntu) (sync)
<slangasek> bdmurray: looking deeper
-queuebot:#ubuntu-release- Unapproved: accepted bind9 [source] (yakkety-proposed) [1:9.10.3.dfsg.P4-10.1ubuntu1.4]
<cyphermox> bdmurray: I think the livecd-rootfs is unrelated, and you're looking at an old v-failed. The issue with livecd-rootfs back then was that it was doing extra copies of grub and shim instead of just running grub-install
<bdmurray> cyphermox: "old v-failed"? the bug either has the tag or doesn't.
<cyphermox> bdmurray: we already reverted the things that were broken
<cyphermox> the relevant grub is not in xenial/yakkety/trusty
<slangasek> bdmurray: which release are you looking at? xenial has no livecd-rootfs in -proposed currently, and yakkety only has the one I just uploaded
<cyphermox> slangasek: https://launchpad.net/ubuntu/+source/livecd-rootfs/2.435.1 ?
<slangasek> oh
<slangasek> not the one I just uploaded :P
<slangasek> right
<cyphermox> that package isn't verification-failed AFAICT
<cyphermox> (checking)
<slangasek> bdmurray: yes, this can be released
<slangasek> the code change just drops some redundant cp's that will begin to fail when the new shim package is SRUed
<bdmurray> okay, thanks!
<cyphermox> we need to re-upload to T and X though
<cyphermox> "Deleted in xenial-proposed on 2017-02-08 (Reason: Part of a failed SRU) "
<cyphermox> it doesn't need to block on the grub/shim changes of 1637290 though
-queuebot:#ubuntu-release- Unapproved: metacity (xenial-proposed/main) [1:3.18.7-0ubuntu0.2 => 1:3.18.7-0ubuntu0.3] (ubuntu-desktop)
<slangasek> cyphermox: was that code change landed in the xenial-proposed git branch?
<slangasek> looks like... no
<slangasek> sorry, I said git but I mean bzr
<cyphermox> I think there's been another SRU since in xenial-proposed, so it might have been overwritten?
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-70.91~14.04.1] (kernel)
<cyphermox> nah, wouldn't have been overwritten
-queuebot:#ubuntu-release- Unapproved: accepted variety [source] (yakkety-proposed) [0.6.2-1ubuntu1]
<cyphermox> slangasek: I'm doing to upload livecd-rootfs 2.408.9 again with the extra copies removed.
<cyphermox> (there is already a 2.408.9 in the queue)
<slangasek> cyphermox: ok.  Please commit it to lp:~ubuntu-core-dev/livecd-rootfs/xenial-proposed/ when you do :)
<cyphermox> yep, just about to
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Zesty Beta 2] has been disabled
<cyphermox> slangasek: done, the upload will still be claimed by rcj given all I really did was copy some changes he had initially done.
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.8 => 2.408.9] (desktop-core)
<slangasek> and old one rejected
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (xenial-proposed) [2.408.9]
<cyphermox> I'll clean up 1637290 to remove the tags and but things back to in progress?
<slangasek> sounds good to me
<cyphermox> we'll reuse the bug for the shim SRUs
<rcj> cyphermox: thanks
<cyphermox> rcj: I figure you might want to still list this for upload rights applications; and all I really did was merge things and review them
-queuebot:#ubuntu-release- Unapproved: mediaplayer-app (zesty-proposed/universe) [0.20.5+17.04.20161201-0ubuntu1 => 0.20.5+17.04.20170321.4-0ubuntu1] (no packageset) (sync)
<rcj> I have to put that together for cloud packages so it really will help
-queuebot:#ubuntu-release- Unapproved: accepted mediaplayer-app [sync] (zesty-proposed) [0.20.5+17.04.20170321.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-70.91~14.04.1]
-queuebot:#ubuntu-release- Unapproved: debian-installer (zesty-proposed/main) [20101020ubuntu498 => 20101020ubuntu499] (core)
 * tsimonq2 stretches and looks around
-queuebot:#ubuntu-release- Unapproved: rejected dockerpty [source] (xenial-proposed) [0.4.1-1~16.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected python-docker [source] (xenial-proposed) [1.9.0-1~16.10.1]
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Zesty Beta 2] has been updated (20170323)
-queuebot:#ubuntu-release- Unapproved: accepted iscsitarget [source] (xenial-proposed) [1.4.20.3+svn502-2ubuntu4.1]
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Zesty Beta 2] has been marked as ready
<robru> slangasek: if you get a sec: https://code.launchpad.net/~robru/britney/+git/britney2-ubuntu/+merge/320837
<Rosco2> infinity, thanks for testing Ubuntu Studio. Real life got in the way for me this time.
<Rosco2> Will work on some release notes
-queuebot:#ubuntu-release- Unapproved: accepted python-docker [source] (yakkety-proposed) [1.9.0-1~16.10.1]
-queuebot:#ubuntu-release- Unapproved: gtk+3.0 (xenial-proposed/main) [3.18.9-1ubuntu3.2 => 3.18.9-1ubuntu3.3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: cups (zesty-proposed/main) [2.2.2-1 => 2.2.2-1ubuntu1] (core)
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Zesty Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Zesty Beta 2] has been marked as ready
<infinity> Rosco2: Please make sure you have people test more between now and release, I just did a quick "is it broken?" smoketest.  You'll probably find bugs you want to fix if you test deeper.
-queuebot:#ubuntu-release- Builds: 38 entries have been added, updated or disabled
<infinity> Beta block dropped in proposed-migration.
<infinity> Publishing in progress.
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (zesty-proposed) [20101020ubuntu499]
<tsimonq2> infinity: \o/
-queuebot:#ubuntu-release- Unapproved: rejected metacity [source] (xenial-proposed) [1:3.18.7-0ubuntu0.3]
 * infinity goes on a short vacation while nusakan publishes the source ISOs.
<slangasek> robru: this isn't part of your change, but I question ignoring PolicyVerdict.REJECTED_TEMPORARILY being correct
<infinity> Temp rejects are only meant to happen while infra is catching up.
<infinity> Is a still-running autopkgtest the uploader's responsibility to chase down?
<slangasek> if autopkgtests have been "running" for 5 days, that means a request got lost
<infinity> slangasek: Sure, it clearly indicates a problem, but who's problem?
<infinity> whose.
<infinity> Stupid English.
<slangasek> infinity: REJECTED_TEMPORARILY means "we don't have results", not "the test is pending"
<slangasek> and test requests do go missing in autopkgtest
<infinity> slangasek: Pending and not results are the same thing from an uploader's perspective.
<infinity> If the test infra is hung, that's surely on us to investigate, not the uploader?
<slangasek> infinity: so are you taking responsibility for retrying all lost requests?
<infinity> (Or a request disappeared)
<infinity> Retrying lost tests can surely be cronnable.
<slangasek> and are you doing that?
<infinity> No.  We should.
<infinity> I'm just saying that's better managed on the infra side.
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (yakkety-proposed) [2.435.2]
<slangasek> and in the meantime, things continue to fall through the cracks
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.9]
<infinity> I suspect tasking someone with "please cron retries" will close the cracks a lot faster and more efficiently than expecting a few dozen uploaders to know what's gone wrong and who to poke to fix it repeatedly.
-queuebot:#ubuntu-release- Builds: 38 entries have been added, updated or disabled
-queuebot:#ubuntu-release- Builds: 38 entries have been added, updated or disabled
-queuebot:#ubuntu-release- Unapproved: bluedevil (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: breeze-grub (zesty-proposed/universe) [5.9.3-0ubuntu1 => 5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: breeze-plymouth (zesty-proposed/universe) [5.9.3-0ubuntu1 => 5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kactivitymanagerd (zesty-proposed/universe) [5.9.3-0ubuntu1 => 5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: breeze-gtk (zesty-proposed/universe) [5.9.3-0ubuntu1 => 5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kde-cli-tools (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: breeze (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
<tsimonq2> KDE bugfix release it looks like ^
<acheronuk> tsimonq2: yep
-queuebot:#ubuntu-release- Unapproved: kde-gtk-config (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdeplasma-addons (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: khotkeys (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kmenuedit (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kscreenlocker (zesty-proposed/universe) [5.9.3-0ubuntu1 => 5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ksysguard (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kwayland-integration (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kwrited (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libksysguard (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: oxygen (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdecoration (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kinfocenter (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ksshaskpass (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kwin (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: milou (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-discover (zesty-proposed/universe) [5.9.3-0ubuntu1 => 5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-nm (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-sdk (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kgamma5 (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kwallet-pam (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-desktop (zesty-proposed/universe) [4:5.9.3-0ubuntu3 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-pa (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kscreen (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
<robru> slangasek: yeah I'm not sure about that, that was added in by Laney. IIRC one of the last things pitti told me before leaving is that there's actually remarkably little difference between REJECTED_{TEMPORARILY,PERMANENTLY}. I'm not up to speed on what situations result in what types of rejects
-queuebot:#ubuntu-release- Unapproved: plasma-integration (zesty-proposed/universe) [5.9.3-0ubuntu1 => 5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libkscreen (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-workspace (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-workspace-wallpapers (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: powerdevil (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: systemsettings (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: polkit-kde-agent-1 (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: user-manager (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: sddm-kcm (zesty-proposed/universe) [4:5.9.3-0ubuntu1 => 4:5.9.4-0ubuntu1] (kubuntu)
<robru> slangasek: I can drop that condition if you want, makes no difference to me
<slangasek> robru: see discussion above w/ infinity
-queuebot:#ubuntu-release- Unapproved: accepted aptdaemon [source] (yakkety-proposed) [1.1.1+bzr982-0ubuntu16.1]
<robru> slangasek: right, cronning autopkgtest retries sounds like a good idea to me, not clear to me though if that means we should keep the condition of not mailing temp rejects or if we should drop that
<robru> slangasek: actually I'd like to drop it, from a code-simplicity perspective
<infinity> robru: If retries of temp_fail conditions are handles by "us" (via cron, and occasionally an infra person having to dig deeper), then bugging an uploader with "there's a problem, but someone else will resolve it" is pointless.
<infinity> s/handles/handled/
<infinity> And it's also noisy and annoying.
<infinity> Plus, there's no difference between "in progress" and "it got lost", from your POV, so anyone with a long test list will get bugged early.
<infinity> (*cough*me*cough*)
<robru> infinity: right, I agree with what you're saying, it's just not clear to me that "autopkgtest results got lost / in progress" is the only possibly temp reject scenario.
<slangasek> it's the only policy we have that returns tempfail AFAIK
<infinity> If there are other tempfails, I'd expect them to be in a similar "we're waiting on something" boat.  That's sort of the point of a tempfail.
<infinity> And telling the uploader "yeah, wait longer" is a good way to get them to ignore all future mails.
-queuebot:#ubuntu-release- Unapproved: diaspora-installer (zesty-proposed/multiverse) [0.6.3.0+debian2 => 0.6.3.0+debian4] (no packageset) (sync)
<robru> infinity: slangasek: AgePolicy and PiupartsPolicy both reference tempfail. I know we're not using Piuparts, not sure what the story with AgePolicy is
<infinity> "This email is to inform you that you've wasted 20 seconds of your day opening and reading this email."
-queuebot:#ubuntu-release- Unapproved: accepted qemu [sync] (xenial-proposed) [1:2.5+dfsg-5ubuntu10.10]
-queuebot:#ubuntu-release- Unapproved: landscape-client (zesty-proposed/main) [16.03-0ubuntu2 => 16.03-0ubuntu3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted diaspora-installer [sync] (zesty-proposed) [0.6.3.0+debian4]
<infinity> robru: AgePolicy is what Debian uses to not let things migrate before N days.  A classic case of tempfail used properly, and somewhere you'd not want to tell anyone about it. :P
<robru> fair enough
<tsimonq2> infinity: (20*200)/60 = Kubuntu people :P
<tsimonq2> That's how many wasted seconds
-queuebot:#ubuntu-release- New: accepted ibm-java80 [source] (xenial-proposed) [8.0.4.1-0ubuntu1]
<robru> infinity: slangasek: so sounds like you guys want to continue not mailing on tempfails? so you'll merge my branch as-is then?
<slangasek> still reviewing the branch
<robru> ok
<robru> thanks
<slangasek> +            sent = (age - sent_age) < min(MAX_FREQUENCY, (age / 2.0) + 0.5)
<infinity> I think not-mail-on-tempfail is the only sane policy.  I also agree with Steve that this means we need to step up resonsibility on the infra side for actually giving a crap about tempfails that aren't transient.
<slangasek> this line is irksomely non obvious in its intent
<infinity> Isn't there a global programming rule that any routine involving arithmetic more complicated than "x++" needs a comment to explain the input and expected output?
<robru> slangasek: I'm open to ideas for clarification. Do you just want a comment?
<slangasek> robru: what I really want is for you to stop trying to cram this into a single math expression
<slangasek> your test matches the implementation, but I fail to see why this is what we want
<robru> slangasek: I'm not sure what you mean by "cram this in", is there some other way than math to express an exponentially decreasing frequency?
<slangasek> +            1.0, 3.0, 7.0, 15.0, 31.0, 61.0, 91.0, 121.0, 151.0, 181.0
<robru> slangasek: this is exactly what you asked for. mail on the first day, then not the second day.
<infinity> That result seems fine to me.
<infinity> I agree that the expression itself is meaningless when read. :P
-queuebot:#ubuntu-release- New binary: ibm-java80 [ppc64el] (xenial-proposed/none) [8.0.4.1-0ubuntu1] (no packageset)
<robru> slangasek: what if I took the expression and broke it out into a couple variables with meaningful names? would that satisfy you? I'd really rather not change the formula itself at this point.
-queuebot:#ubuntu-release- Unapproved: accepted signon-ui [sync] (xenial-proposed) [0.17+16.04.20170116-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: metacity (xenial-proposed/main) [1:3.18.7-0ubuntu0.2 => 1:3.18.7-0ubuntu0.3] (ubuntu-desktop)
<slangasek> that's not actually exponentiation
<slangasek> well
<slangasek> I guess it's exponential on the delay
<slangasek> so yeah
<robru> slangasek: it is exponentiation, the exponent is just hidden because we're working backwards from the age to figure out the exponent.
<infinity> 1/2/4/8/16/32/32/32/32/32 was the original strawman, and it was determined that 2 is too close to 1, so indeed, his series works well enough.
<infinity> But it's hard to explain how he arrives at it.
-queuebot:#ubuntu-release- New binary: ibm-java80 [i386] (xenial-proposed/none) [8.0.4.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ibm-java80 [amd64] (xenial-proposed/none) [8.0.4.1-0ubuntu1] (no packageset)
<robru> it becomes clearer if you consider the deltas instead of the absolute number of days. it goes: mail after 1 day, after 2 days, after 4 days, after 8 days, etc. so you get mail on day 1, day 3 (1+2), day 7 (3+4), etc
<infinity> Indeed.
<infinity> My brain just got there too.
<infinity> So, yeah.  I'd be happy just with a comment explaining what it's meant to do.
<infinity> The +0.5 is a clever way of getting 1 out of 0, but rather non-obvious, for instance.
<infinity> (Well, of getting 1 out of 1 divided by 2, but yeah)
<slangasek> so what happens if we miss sending emails for a day?
<slangasek> say, because a package hit the age on exactly the right day that a freeze block was in place
<robru> slangasek: then what happens is the next time britney does run, it sees it's cache file, says "oh yeah, the last mail I sent is well before the defined cutoff" and then it sends a mail
<robru> slangasek: well freeze blocks don't get mailed.
<slangasek> robru: and then how long does it wait until the next mail is sent?
<slangasek> because now instead of sending at age=3, you've sent at age=4
<slangasek> and so if we save that to the cache, the next mail goes out on day 9 instead of on day 7
<slangasek> doesn't it?
<infinity> slangasek: It should send immediately when it's valid to send again.
<robru> slangasek: it follows the formula. refer to the test, the second test case that tests what happens when is_valid is True, it sends the first mail on day 5. This causes the frequency to change, but it still follows the same exponential decrease in frequency.
<robru> infinity: yes, it will send immediately as soon as it considers it valid, but delaying one mail delays all future mails too, because it goes by "how long ago the last one was sent" and not just based on the direct age of the package
<infinity> Yes, that's sane.
<infinity> Otherwise a 3 day freeze would result in you getting back-to-back mails.
<infinity> Which would be unhelpful.
<slangasek> infinity: except that it also changes the backoff rate
<infinity> slangasek: It doesn't change the rate, it just slides the dates?
<robru> slangasek: well, it's still exponential, it just has a larger coefficient in that case
<slangasek> because the backoff is being derived from age-last_sent_age
<robru> infinity: 5.0, 11.0, 23.0, 47.0, 77.0, 107.0, 137.0, 167.0, 197.0
<infinity> Oh, indeed.
<infinity> I see what you mean.
<infinity> So instead of 1<long freeze>2 4 8, you get 1<long freeze>4 8 16
<slangasek> right
<slangasek> which I don't think is what's wanted
<robru> slangasek: I don't think it matters? The point is that it's infrequent and decreasing in frequency?
<robru> slangasek: like I don't believe anybody ever said "it MUST email on day 1, 2, 4, 8, 16!". it's just "hey please not every day", so this isn't mailing every day.
<slangasek> I was never in favor of exponential backoff but I was ok with that as a compromise.  Now we have an exponential backoff that isn't even applied consistently.
<robru> slangasek: how about I just make it every 3 days, starting on day 1?
<infinity> No.
<infinity> Also, no.
<infinity> Literally everyone who knows how a mail filter works will ignore those in the first month.
<infinity> And those who don't will filter them by hand.
<infinity> But pretend they read them.
<infinity> The gap in the exponential backoff isn't ideal, but it's better than a consistent repetition.
<robru> infinity: I'm pretty sure everybody in the set of "ubuntu uploaders" can work out a mail filter, and will use a mail filter regardless of whether the emails are daily, weekly, or exponential-backoffly.
<infinity> robru: Then why have the feature? :P
<robru> infinity: literally because steve asked for it. I don't even care about this at all
<infinity> But no, I disagree with that assertion, at least as it applies to me.  With the backoff, I won't be inclined to filter the world, and if I forget about something for two weeks, boom, pie in the face.
<infinity> But being told every 3 days is just another thing I'll reflexively delete based on scanning the first few character of the subject line.
<infinity> proposed-migration would be the new Viagra.
<tsimonq2> infinity: For the past month I had no spam filter so I really relate to that. :P
<robru> infinity: slangasek: ok so I literally do not care what gets decided, but I need you two to come to an agreement so I can get this merged
<infinity> It doesn't need to be literally exponential or involve fancy math, given the number of integers we're talking here before the monthish cap, you could just hardcode "first mail at 1, second mail at 3, third mail at 7..."
<infinity> And to make Steve happy, if one or more of those is missed, you send one, and record all the missed ones as sent.
-queuebot:#ubuntu-release- New binary: ibm-java80 [s390x] (xenial-proposed/partner) [8.0.4.1-0ubuntu1] (no packageset)
<slangasek> right
<infinity> 1, 3, 7, 15, 31, it's 5 integers.
<robru> infinity: that's exactly the thing, though, is that you precisely cannot do that. britney isn't a long running process that can just have a list of integers to pop from when it needs. it's a script called periodically by cron and all I know is how long the package has been sitting in proposed, and i have to somehow workout backwards from that whether or not
<robru> it's been an appropriate length of time or not. you have to track when the last email was sent and then you have to subtract how long ago that was, and then math it up to create the pattern you want.
<infinity> Last mail was sent at three days, we're now at 8 days, you send a mail and claim you sent it at 7.  Last mail was sent at 3, it's now 18, you send a mail and claim it sent at 15.
<robru> what?
<slangasek> slightly different than what I had in mind, but yes
<infinity> There's no rule that the timestamps in your cache have to actually reflect reality.
<slangasek> knowing when the last mail was sent is enough to know what the interval should be until the next mail
<slangasek> but the interval should be 2^n instead of being based on the date the last mail was sent
<robru> slangasek: 1, 3, 7 IS 2^n
<robru> 2^n days in between mails
<robru> not "every 2^n day"
<slangasek> until the first time you miss a mail because of a block hint or an infrastructure outage
<slangasek> and then you're 1, 4, 9 or such
<robru> slangasek: ok, so if I change this to just have a fixed list of integer days, what's going to happen then is that if there's a delay sending one mail, it won't also delay all future mails, resulting in cases where mails can get "bunched up". the nice thing about the current implementation is that if there's a delay for any reason, future mails are also
<robru> delayed.
<infinity> Future mails being delayed is fine if you don't miss a step in the sequence.
<infinity> So you could record date sent and sequence number.
<robru> infinity: you can't "miss a step" in this sequence because there isn't a defined sequence. it just measures the age and increases the delay based on the age.
<infinity> Steve's concern is that if you miss the +4, then your next is +8 instead of +4
<robru> well that's not what happens.
<robru> there is no "you miss +4 so it goes to +8". what happens is, the formula works out what the appropriate delay should be, as a continuous function, for all possible values of daysold. so if the 4th mail is delayed by a couple hours, the fifth mail is also delayed by slightly more hours.
<slangasek> we are not in agreement that the delay it's calculating is appropriate.
<robru> there is no "oops +4 got lost so the next one isn't until +8". it just sends it when the function tips over the threshhold, which will be "the first possible run after whatever blocks are lifted"
<robru> slangasek: I really don't see why it matters whether a mail is sent on the 3rd day or the 4th day. I nominate this conversation for bikeshed of the year.
-queuebot:#ubuntu-release- Unapproved: shim (yakkety-proposed/main) [0.9+1465500757.14a5905.is.0.8-0ubuntu3 => 0.9+1474479173.6c180c6-1ubuntu1] (core) (sync)
<infinity> I logged into snakefruit, and I've completely forgotten why.
-queuebot:#ubuntu-release- Unapproved: shim (xenial-proposed/main) [0.8-0ubuntu2 => 0.9+1474479173.6c180c6-1ubuntu1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected docker-compose [source] (yakkety-proposed) [1.8.0-2~16.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected docker-compose [source] (xenial-proposed) [1.8.0-2~16.04.1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-artwork (zesty-proposed/universe) [17.04.7 => 17.04.8] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: shim-signed (yakkety-proposed/main) [1.21.3 => 1.27~16.10.1] (core)
-queuebot:#ubuntu-release- Unapproved: docker-compose (yakkety-proposed/universe) [1.5.2-1 => 1.8.0-2~16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (yakkety-proposed/main) [1.74 => 1.74.2] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (yakkety-proposed/main) [2.02~beta2-36ubuntu11 => 2.02~beta2-36ubuntu11.2] (core)
 * tsimonq2 smiles and patiently waits for Final Beta email
<cyphermox> ^ slangasek: yakkety shim update: grub2{-signed} is versioned this way because there was a .1 already before.
<slangasek> cyphermox: sure
-queuebot:#ubuntu-release- Unapproved: docker-compose (xenial-proposed/universe) [1.5.2-1 => 1.8.0-2~16.04.1] (no packageset)
<cyphermox> (in other words, everything is there for the yakkety shim update, and about to upload xenial's now)
<flexiondotorg> Apparently - http://www.omgubuntu.co.uk/2017/03/download-ubuntu-17-04-beta-2-release
<tsimonq2> flexiondotorg: They always jump the gun...
<tsimonq2> flexiondotorg: Always.
-queuebot:#ubuntu-release- Unapproved: grub2-signed (xenial-proposed/main) [1.66.8 => 1.66.9] (core)
-queuebot:#ubuntu-release- Unapproved: shim-signed (xenial-proposed/main) [1.19~16.04.1 => 1.27~16.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.8 => 2.02~beta2-36ubuntu3.9] (core)
<flexiondotorg> tsimonq2 I know.
-queuebot:#ubuntu-release- Unapproved: accepted docker-compose [source] (yakkety-proposed) [1.8.0-2~16.10.1]
<infinity> flexiondotorg: Meh, close enough.
-queuebot:#ubuntu-release- Unapproved: gobject-introspection (zesty-proposed/main) [1.51.5-1ubuntu1 => 1.52.0-0ubuntu1] (ubuntu-desktop)
* infinity changed the topic of #ubuntu-release to: Released: Xenial 16.04.2, Zesty Final Beta | Archive: post-beta denouement | Zesty Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
-queuebot:#ubuntu-release- Unapproved: activity-log-manager (zesty-proposed/main) [0.9.7-0ubuntu24 => 0.9.7-0ubuntu25] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: activity-log-manager (xenial-proposed/main) [0.9.7-0ubuntu23 => 0.9.7-0ubuntu23.1~xenial] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: activity-log-manager (yakkety-proposed/main) [0.9.7-0ubuntu23 => 0.9.7-0ubuntu23.1~yakkety] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: activity-log-manager (trusty-proposed/main) [0.9.7-0ubuntu14.1 => 0.9.7-0ubuntu14.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-photos (zesty-proposed/universe) [3.23.91-0ubuntu1 => 3.24.0-0ubuntu1] (desktop-extra, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: accepted keepalived [sync] (xenial-proposed) [1:1.2.19-1ubuntu0.2]
<robert_ancell> Can someone help get activity-log-manager 0.9.7-0ubuntu24  out of proposed? It's depwaiting on a s390x build but if you follow the dependency chain that stops at upstart which doesn't do s390x
-queuebot:#ubuntu-release- Unapproved: skalibs (zesty-proposed/universe) [0.47-1.1 => 0.47-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted skalibs [sync] (zesty-proposed) [0.47-1.1]
-queuebot:#ubuntu-release- Unapproved: accepted metacity [source] (xenial-proposed) [1:3.18.7-0ubuntu0.3]
<nacc> robert_ancell: did the dependency chain change somehow? ubuntu23 built on s390x?
-queuebot:#ubuntu-release- Unapproved: debian-installer (zesty-proposed/main) [20101020ubuntu499 => 20101020ubuntu500] (core)
<robert_ancell> nacc, I don't think anything changed from the a-l-m end
<robert_ancell> nacc, the previous version of a-l-m was compiled in Xenial, and upstart did have a s390x build then
<nacc> robert_ancell: oh i'm seeing that now
<nacc> robert_ancell: it would seem that activity-log-manager needs to not depend on that package on s390x then?
<infinity> robru: Didn't a ton of stuff just hit the queue to remove upstart deps from the desktop/touch chains?
<infinity> Err.
<infinity> robert_ancell: ^^
<robert_ancell> nacc, I wasn't sure if that information should be in the a-l-m package. It doesn't care itself about the architecture and none of the intermediate dependencies seem to have rules like that
<robert_ancell> infinity, yeah, I'd hope the a-l-m dependencies get fixed and then this problem wouldn't hit a-l-m itself
<infinity> robert_ancell: That would be my take.  This might shake itself out shortly.
<nacc> robert_ancell: right, it does seem like it's just a side-effect of other stuff going on right now
<robert_ancell> ok
<infinity> Removing upstart entirely was a goal for zesty.  We may or may not meet it, but we're definitely still trying.
<nacc> infinity: that's what i thought i read earlier too -- but not sure
<nacc> infinity: as to stuff just landing that chagned this
 * infinity nods.
<infinity> Well, "landing".  It may all need review.
<nacc> heh, but one of them is your upload infinity: https://launchpad.net/ubuntu/+source/unity-control-center/15.04.0+17.04.20170314-0ubuntu2
<nacc> do you get notifications when something is stuck in dep-wait too? or is that just a one-time thing?
<infinity> Well, you get notifications from britney of the failure to promote.
<infinity> Which you can track back to "oh, cause it never built".
<nacc> infinity: ah but in this case, it did get promoted to release
<nacc> infinity: i'm not sure why/how?
<nacc> i guess s390x doesn't really matter for desktop, maybe something knows that
<robert_ancell> I'm pretty sure it doesn't matter on desktop
<robert_ancell> Given unity-control-center doesn't have a package currently
<infinity> nacc: The binary wasn't there before, thus it was okay.
<nacc> infinity: oh i see
<infinity> We don't care if binaries build everywhere, we care if something *regresses*.
<nacc> infinity: right that makes sense
<nacc> infinity: sorry, i often forget that nuance :)
<infinity> That said, a ton of desktop stuff will magically build on s390x when the upstart removal is complete.
<nacc> right
<robert_ancell> On the flip side - we are holding back fixes from users on architectures that actually run desktops...
<robert_ancell> Note that a-l-m is usually only accessed through u-c-c
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (zesty-proposed) [20101020ubuntu500]
-queuebot:#ubuntu-release- Unapproved: gnome-themes-standard (zesty-proposed/main) [3.22.2-1ubuntu1 => 3.22.3-1ubuntu1] (ubuntu-desktop)
<infinity> robert_ancell: I won't "hold it back" long.  Just going to see how this upstart stuff shakes out, and either your update will Just Work, or I'll give it a nudge.
<robert_ancell> infinity, ok, thanks
-queuebot:#ubuntu-release- Unapproved: accepted kmenuedit [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kscreenlocker [source] (zesty-proposed) [5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ksysguard [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-documents (zesty-proposed/universe) [3.23.91-0ubuntu1 => 3.24.0-0ubuntu1] (desktop-extra, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: landscape-client (zesty-proposed/main) [16.03-0ubuntu2 => 16.03-0ubuntu3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: unity-settings-daemon (zesty-proposed/main) [15.04.1+16.10.20161003-0ubuntu1 => 15.04.1+17.04.20170322-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted kscreen [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted oxygen [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: makedev (zesty-proposed/universe) [2.3.1-93ubuntu1 => 2.3.1-93ubuntu2] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted ksshaskpass [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: nova (zesty-proposed/main) [2:15.0.1-0ubuntu1 => 2:15.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gnome-software (zesty-proposed/main) [3.22.7-0ubuntu1 => 3.22.7-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted content-hub [sync] (zesty-proposed) [0.3+17.04.20170317.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted indicator-datetime [sync] (zesty-proposed) [15.10+17.04.20170322-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted indicator-power [sync] (zesty-proposed) [12.10.6+17.04.20170322-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-app-launch [sync] (zesty-proposed) [0.11+17.04.20170321-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted url-dispatcher [sync] (zesty-proposed) [0.1+17.04.20170318-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted indicator-bluetooth [sync] (zesty-proposed) [0.0.6+17.04.20170322-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libertine [sync] (zesty-proposed) [1.7+17.04.20170320.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted indicator-network [sync] (zesty-proposed) [0.9.0+17.04.20170322-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-system-settings [sync] (zesty-proposed) [0.4+17.04.20170317.2-0ubuntu1]
<infinity> robert_ancell: ^-- Indeed, this above might unstick it.  You're depwait on unity-control-center, and u-c-c is depwait on indicator-datetime, which has an s390x build above.
<robert_ancell> \o/
-queuebot:#ubuntu-release- Unapproved: accepted qmenumodel [sync] (zesty-proposed) [0.2.12+17.04.20170316.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtmir [sync] (zesty-proposed) [0.5.1+17.04.20170320.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtubuntu [sync] (zesty-proposed) [0.64+17.04.20170320-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted unity8 [sync] (zesty-proposed) [8.15+17.04.20170321-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtmir-gles [sync] (zesty-proposed) [0.5.1+17.04.20170320.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted unity-api [sync] (zesty-proposed) [8.6+17.04.20170317-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtubuntu-gles [sync] (zesty-proposed) [0.64+17.04.20170320-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted clutter-gtk [sync] (zesty-proposed) [1.8.2-2]
-queuebot:#ubuntu-release- Unapproved: accepted libdrm [sync] (zesty-proposed) [2.4.75-2]
-queuebot:#ubuntu-release- Unapproved: accepted ladish [sync] (zesty-proposed) [1+dfsg0-5.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-keyring [sync] (zesty-proposed) [10.3.1-1]
-queuebot:#ubuntu-release- Unapproved: rejected ladish [sync] (zesty-proposed) [1+dfsg0-5.1]
-queuebot:#ubuntu-release- Unapproved: accepted pencil2d [sync] (zesty-proposed) [0.5.4+git20170323.ec4712d+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-photos [source] (zesty-proposed) [3.24.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted systemsettings [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted user-manager [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gobject-introspection [source] (zesty-proposed) [1.52.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-artwork [source] (zesty-proposed) [17.04.8]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-chess [source] (zesty-proposed) [1:3.24.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted lightdm [source] (zesty-proposed) [1.22.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libsecret [source] (zesty-proposed) [0.18.5-3.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-documents [source] (zesty-proposed) [3.24.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-themes-standard [source] (zesty-proposed) [3.22.3-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted makedev [source] (zesty-proposed) [2.3.1-93ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (zesty-proposed) [3.22.7-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (zesty-proposed) [2:15.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted landscape-client [source] (zesty-proposed) [16.03-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: libgweather (zesty-proposed/main) [3.24.0-0ubuntu1 => 3.24.0-0ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted at-spi2-core [source] (zesty-proposed) [2.22.0-5ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (zesty-proposed) [1.4.4-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-default-settings [source] (zesty-proposed) [1.3.18]
-queuebot:#ubuntu-release- Unapproved: accepted maliit-framework [sync] (zesty-proposed) [0.99.1+git20151118+62bd54b-0ubuntu14]
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-notifyd [source] (zesty-proposed) [0.3.6-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (zesty-proposed) [232-21ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kwayland-integration [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kwrited [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libksysguard [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-desktop [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-integration [source] (zesty-proposed) [5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-pa [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kwin [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted milou [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-nm [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libkscreen [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-discover [source] (zesty-proposed) [5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted bluedevil [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted breeze-gtk [source] (zesty-proposed) [5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted breeze [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kde-cli-tools [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted breeze-grub [source] (zesty-proposed) [5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kactivitymanagerd [source] (zesty-proposed) [5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted breeze-plymouth [source] (zesty-proposed) [5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kdecoration [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kde-gtk-config [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kgamma5 [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kinfocenter [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-sdk [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kdeplasma-addons [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kwallet-pam [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted khotkeys [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-workspace-wallpapers [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted polkit-kde-agent-1 [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted sddm-kcm [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-workspace [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted powerdevil [source] (zesty-proposed) [4:5.9.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libgweather [source] (zesty-proposed) [3.24.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted mediascanner2 [sync] (zesty-proposed) [0.112+17.04.20170322-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted unity-settings-daemon [sync] (zesty-proposed) [15.04.1+17.04.20170322-0ubuntu1]
#ubuntu-release 2017-03-24
-queuebot:#ubuntu-release- Unapproved: webkit2gtk (zesty-proposed/main) [2.15.92-1 => 2.16.0-1] (kubuntu, ubuntu-desktop) (sync)
<jbicha> https://launchpadlibrarian.net/312058096/webkit2gtk_2.15.92-1_2.16.0-1~ubuntu17.04.1.diff.gz
-queuebot:#ubuntu-release- Unapproved: gtk+3.0 (zesty-proposed/main) [3.22.11-0ubuntu1 => 3.22.11-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted activity-log-manager [source] (zesty-proposed) [0.9.7-0ubuntu25]
-queuebot:#ubuntu-release- Unapproved: accepted webkit2gtk [sync] (zesty-proposed) [2.16.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted gtk+3.0 [source] (zesty-proposed) [3.22.11-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: snapd-glib (zesty-proposed/main) [1.7-0ubuntu1 => 1.9-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: unity-settings-daemon (zesty-proposed/main) [15.04.1+17.04.20170322-0ubuntu1 => 15.04.1+17.04.20170322-0ubuntu1.1] (ubuntu-desktop)
<robert_ancell> unity-settings-daemon 15.04.1+17.04.20170322-0ubuntu1.1 fixes bug 1675612 which appeared in the previous release
<ubot5> bug 1675612 in unity-settings-daemon (Ubuntu) "zesty login screen is all black (with a cursor) [unity-settings-daemon: undefined symbol: gnome_settings_plugin_info_set_settings_prefix]" [Critical,New] https://launchpad.net/bugs/1675612
-queuebot:#ubuntu-release- Unapproved: snapcraft (zesty-proposed/universe) [2.27.1+17.04 => 2.28+17.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (zesty-proposed) [2.28+17.04]
-queuebot:#ubuntu-release- Unapproved: gwc (zesty-proposed/universe) [0.21.19~dfsg0-7 => 0.21.19~dfsg0-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gwc [source] (zesty-proposed) [0.21.19~dfsg0-7ubuntu1]
-queuebot:#ubuntu-release- Unapproved: apparmor (zesty-proposed/main) [2.11.0-2ubuntu2 => 2.11.0-2ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: rejected system-config-printer [source] (zesty-proposed) [1.5.7+20160812-0ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted system-config-printer [source] (zesty-proposed) [1.5.7+20160812-0ubuntu8]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.9]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (xenial-proposed) [1.66.9]
-queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (zesty-proposed) [2.11.0-2ubuntu3]
-queuebot:#ubuntu-release- Unapproved: makedev (trusty-proposed/main) [2.3.1-93ubuntu1 => 2.3.1-93ubuntu2~ubuntu14.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: makedev (xenial-proposed/main) [2.3.1-93ubuntu1 => 2.3.1-93ubuntu2~ubuntu16.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: makedev (yakkety-proposed/universe) [2.3.1-93ubuntu1 => 2.3.1-93ubuntu2~ubuntu16.10.1] (core, lubuntu)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.8.0-44.47~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-70.91]
-queuebot:#ubuntu-release- Unapproved: accepted shim [sync] (xenial-proposed) [0.9+1474479173.6c180c6-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: makedev (precise-proposed/main) [2.3.1-89ubuntu2 => 2.3.1-89ubuntu3] (core)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-44.47]
-queuebot:#ubuntu-release- Unapproved: rejected snapd-glib [source] (zesty-proposed) [1.8-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.8 => 2.02~beta2-36ubuntu3.9] (core)
-queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (xenial-proposed) [1.27~16.04.1]
-queuebot:#ubuntu-release- Unapproved: shim-signed (xenial-proposed/main) [1.19~16.04.1 => 1.27~16.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (xenial-proposed) [1.27~16.04.1]
-queuebot:#ubuntu-release- Unapproved: shim-signed (xenial-proposed/main) [1.19~16.04.1 => 1.27~16.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (xenial-proposed) [1.27~16.04.1]
-queuebot:#ubuntu-release- Unapproved: shim-signed (xenial-proposed/main) [1.19~16.04.1 => 1.27~16.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.9 => 2.02~beta2-36ubuntu3.9] (core)
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (xenial-proposed) [1.27~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (yakkety-proposed) [2.02~beta2-36ubuntu11.2]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (xenial-proposed) [2.02~beta2-36ubuntu3.9]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (xenial-proposed) [2.02~beta2-36ubuntu3.9]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (yakkety-proposed) [1.74.2]
-queuebot:#ubuntu-release- Unapproved: accepted shim [sync] (yakkety-proposed) [0.9+1474479173.6c180c6-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted unity-settings-daemon [source] (zesty-proposed) [15.04.1+17.04.20170322-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (yakkety-proposed) [1.27~16.10.1]
-queuebot:#ubuntu-release- Unapproved: shim-signed (yakkety-proposed/main) [1.21.3 => 1.27~16.10.1] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (yakkety-proposed/main) [2.02~beta2-36ubuntu11 => 2.02~beta2-36ubuntu11.2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (yakkety-proposed) [2.02~beta2-36ubuntu11.2]
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (yakkety-proposed) [1.27~16.10.1]
<ginggs> any ~ubuntu-archive members around to remove some universe packages please?
<apw> ginggs, you should just ask for what you want done, not if people are here
-queuebot:#ubuntu-release- Unapproved: grub2 (yakkety-proposed/main) [2.02~beta2-36ubuntu11.2 => 2.02~beta2-36ubuntu11.2] (core)
<ginggs> apw: i have a list of several bugs, i didn't want to spam the channel :)
<ginggs> LP: #167419 LP: #1671423 LP: #1671429
<ubot5> Launchpad bug 167419 in Inkscape "square/circle/polygon/spiral and linked offset misbehaviours" [High,Fix released] https://launchpad.net/bugs/167419
<ubot5> Launchpad bug 1671423 in kineticstools (Ubuntu) "Please remove i386 binaries" [Undecided,New] https://launchpad.net/bugs/1671423
<ubot5> Launchpad bug 1671429 in phyml (Ubuntu) "Please remove ppc64el and s390x binaries" [Undecided,New] https://launchpad.net/bugs/1671429
<ginggs> sorry first one was a typo, should be LP: #1671419
<ubot5> Launchpad bug 1671419 in htseq (Ubuntu) "Please remove armhf and s390x binaries" [Undecided,New] https://launchpad.net/bugs/1671419
<ginggs> LP: #1671431 LP: #1671451 LP: #1671452
<ubot5> Launchpad bug 1671431 in bedtools (Ubuntu) "Please remove armhf and s390x binaries" [Undecided,New] https://launchpad.net/bugs/1671431
<ubot5> Launchpad bug 1671451 in fitgcp (Ubuntu) "Please remove i386 binaries" [Undecided,New] https://launchpad.net/bugs/1671451
<ubot5> Launchpad bug 1671452 in iva (Ubuntu) "Please remove i386 binaries" [Undecided,New] https://launchpad.net/bugs/1671452
<ginggs> and i'd appreciate if someone would look at an FFe LP: #1672412 - should be straightforward
<ubot5> Launchpad bug 1672412 in wine-development (Ubuntu) "FFe: Merge wine-development 2.4-1 (universe) from Debian experimental (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1672412
<apw> ginggs, on that FFe i think the question about where does the current stable go if this is done is valid
<ginggs> apw, jbicha: the only reason debian are stuck with wine 1.8.7 instead of 2.0 is because of their freeze, i see no reason why we couldn't have wine-development 2.4+ and wine 2.0 in ubuntu
<apw> ginggs, and perhaps indeed that is also reasonable, but right now we have two stable releases (with daft names) and your ffe would mean we lose the newer of those
<ginggs> apw: i don't think we should be encouraging users who want the stable version to switch to wine-development
<apw> ginggs, no this is all a bit of a mess
<apw> because they almost cirtianly will, i am sure the first hit on google for "wine not working" will be to update to that, bound to be
-queuebot:#ubuntu-release- Unapproved: socklog (zesty-proposed/universe) [2.1.0-8 => 2.1.0-8.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: twoftpd (zesty-proposed/universe) [1.42-1 => 1.42-1.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted socklog [sync] (zesty-proposed) [2.1.0-8.1]
-queuebot:#ubuntu-release- Unapproved: accepted twoftpd [sync] (zesty-proposed) [1.42-1.1]
-queuebot:#ubuntu-release- Unapproved: uucpsend (zesty-proposed/universe) [1.1-4 => 1.1-4.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted uucpsend [sync] (zesty-proposed) [1.1-4.1]
-queuebot:#ubuntu-release- Unapproved: gitlab (zesty-proposed/universe) [8.13.11+dfsg-7 => 8.13.11+dfsg-8] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gitlab [sync] (zesty-proposed) [8.13.11+dfsg-8]
<tjaalton> Laney: re https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1671799 please have a look, it'll take a while to get these sorted through -proposed
<ubot5> Ubuntu bug 1671799 in xorg-server (Ubuntu) "FFe: xserver 1.19.3" [Undecided,Confirmed]
<acheronuk> apw or anyone else: could you badtest/skiptest etc the test on liqapt against polkit-kde-agent-1? https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#polkit-kde-agent-1
<acheronuk> that acc fail there is just it needing -fno-keep-inline-functions passed to GCC (change in gcc since last upload) rather than any actual fail to be concerned on
<acheronuk> something to tweak to fix next time a upload is needed for another reason, but probably not now with all re-tests against it's r-deps that brings
<flexiondotorg> Please unblock ubuntu-mate-artwork/17.04.8
<apw> flexiondotorg, ? that is in zesty-release ?
<Laney> right, there's no freeze @ proposed-migration
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.27.1 => 2.28] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapcraft (yakkety-proposed/universe) [2.27.1+16.10 => 2.28+16.10] (no packageset)
<Laney> wtf
<Laney> why are there now *three* kwin/ppc64el tests running?
-queuebot:#ubuntu-release- Unapproved: rickshaw (zesty-proposed/universe) [1.5.1.dfsg-1 => 1.5.1.dfsg-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted rickshaw [sync] (zesty-proposed) [1.5.1.dfsg-2]
<Laney> acheronuk: I'm killing yours
<flexiondotorg> apw Yes, it is. I wasn't seeing it in updates to the test machine. It has arrived now. Thanks.
<acheronuk> Laney: whoops. sorry
<acheronuk> Laney: could you also see my earlier request to skip the libqapt test for now? thx
<acheronuk> if you have time to look
<Laney> Not right now
<LocutusOfBorg> Laney, my bad sorry
<LocutusOfBorg> I didn't mean to run against proposed, so I triggered again without
<acheronuk> Laney: np. not urgent
<LocutusOfBorg> (I can't see the third one BTW)
<acheronuk> LocutusOfBorg: I guess already killed
<LocutusOfBorg> maybe, not sure how I could have triggered it
<acheronuk> LocutusOfBorg: you didn't. that was me :P
<acheronuk> should have check what was running 1st :/
<LocutusOfBorg> oh wondeerful! sometimes with my little android screen I misclick them :)
 * acheronuk shudders at the thought of the excuses page on android!
<LocutusOfBorg> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/armhf/w/wheel/20170323_235044_a755f@/log.gz
<LocutusOfBorg> Laney, ^^ wheel/armhf stuck again
<Laney> retry it
<Laney> that bug isn't going to get magically fixed
 * LocutusOfBorg finds difficult to generate a retry link when it is "running" :p
<Laney> retry-autopkgtest-regressions --state RUNNING
<LocutusOfBorg> lovely
<LocutusOfBorg> I waste a lot of time manually creating such links :)
<Laney> heh
<LocutusOfBorg> it is too silent, it exits without printing stuff
 * LocutusOfBorg looks at the code
<Laney> https://paste.ubuntu.com/24240035/
<LocutusOfBorg> ok missing cookie and running uppercase :)
<LocutusOfBorg> thanks
<Laney> you only need the cookie for passing the URLs into wget or whatever
<Laney> not if you just want to click them
 * LocutusOfBorg deletes the cookie
<LocutusOfBorg> I prefer to for i in `cat output` open them :p
-queuebot:#ubuntu-release- Unapproved: putty (zesty-proposed/universe) [0.67-2 => 0.67-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted putty [sync] (zesty-proposed) [0.67-3]
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (yakkety-proposed) [2.28+16.10]
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.28]
-queuebot:#ubuntu-release- Unapproved: accepted cups [source] (zesty-proposed) [2.2.2-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted landscape-client [source] (yakkety-proposed) [16.03-0ubuntu2.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted landscape-client [source] (xenial-proposed) [16.03-0ubuntu2.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (yakkety-proposed) [2.02~beta2-36ubuntu11.2]
<jbicha> ginggs: why don't you see if you can convert 'wine' to 2.0 *before* updating wine-development then?
<ginggs> jbicha: for simplicity, i would prefer to stick as close as possible to debian, i.e. wine 1.8.7-2 and wine-development 2.4-1 - but I don't see any reason why you should not convert wine-development 2.0 into wine 2.0, if you wanted to do that
<jbicha> ginggs: well you could ask jre to push wine 2.0 to wine/exp
<jbicha> I like staying close to Debian too; that's how we ended up wine 1.7 and wine-development 2.0 because that made the most sense there I think
<ginggs> jbicha: good idea :) i will ask jre - but i believe he is waiting on an unblock for wine 1.8.7-2
<ginggs> jbicha: for reference, debian bug #858371
<ubot5> Debian bug 858371 in release.debian.org "unblock: wine/1.8.7-2" [Normal,Open] http://bugs.debian.org/858371
<jbicha> since wine/exp is in use, maybe it could still be pushed to a Debian git branch?
-queuebot:#ubuntu-release- Unapproved: gst-libav1.0 (zesty-proposed/universe) [1.10.3-1 => 1.10.4-1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: gstreamer1.0 (zesty-proposed/main) [1.10.3-1 => 1.10.4-1] (desktop-core) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-bad1.0 (zesty-proposed/universe) [1.10.3-1ubuntu4 => 1.10.4-1ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-base1.0 (zesty-proposed/main) [1.10.3-1ubuntu1 => 1.10.4-1ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-ugly1.0 (zesty-proposed/universe) [1.10.3-1ubuntu1 => 1.10.4-1ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-good1.0 (zesty-proposed/main) [1.10.3-1ubuntu1 => 1.10.4-1ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gst-python1.0 (zesty-proposed/universe) [1.10.3-1 => 1.10.4-1] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-rtsp-server1.0 (zesty-proposed/universe) [1.10.3-1 => 1.10.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gst-rtsp-server1.0 [sync] (zesty-proposed) [1.10.4-1]
-queuebot:#ubuntu-release- Unapproved: gstreamer-vaapi (zesty-proposed/universe) [1.10.2-1build1 => 1.10.4-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gstreamer-editing-services1.0 (zesty-proposed/universe) [1.10.3-1 => 1.10.4-1] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gstreamer-vaapi [sync] (zesty-proposed) [1.10.4-1]
<Laney> who synced vaapi?
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/gstreamer-vaapi/+publishinghistory
<LocutusOfBorg> :)
-queuebot:#ubuntu-release- Unapproved: libqapt (zesty-proposed/universe) [3.0.2-0ubuntu4 => 3.0.2-0ubuntu5] (kubuntu)
<Laney> Waste of a build, and I had deliberately not synced it.
<Laney> It needs to be built after -bad.
<LocutusOfBorg> jbicha, ^^
-queuebot:#ubuntu-release- Unapproved: mir (zesty-proposed/main) [0.26.1+17.04.20170209.1-0ubuntu1 => 0.26.2+17.04.20170322.1-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: signon-ui (zesty-proposed/main) [0.17+17.04.20161109-0ubuntu1 => 0.17+17.04.20170320-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
<apw> Laney, it would be so nice if there was a block for those at the queue level, but expressed like the britney ones
<Laney> for what?
<apw> "i know this won't build don't let anyone sync it till that is fixed"
<Laney> meh, maybe, I could have put something into queuebot
<Laney> or people could not get involved in something that somebody else is clearly actively working on without consulting with that person
<apw> or that
<jbicha> yes, I'll try to ask first next time
<Laney> thx
<salem_> Hello. We are about to land a silo that will include a new package to the archive. Can anybody tell me what's the correct procedure to get someone to review the package for us? This is the branch: http://bazaar.launchpad.net/~phablet-team/mfw-plugin-irc/dummy-branch/files/head:/debian/
<apw> salem_, normally you tell us the silo i think
<salem_> apw, thanks! it's https://bileto.ubuntu.com/#/ticket/2629
<apw> salem_, any idea which of the packages are new ?
<salem_> apw, mfw-plugin-irc is the new one. But messaging-framework is now generating a new binary as well: mfw-plugin-dummy. Not sure if new binaries also require review.
<apw> salem_, they do
<Laney> hmm
<Laney> if a silo can clear a depwait of a package in the main archive on one arch, can I copy that source + binaries into the silo?
<Laney> that is, will it work to copy that package same back into zesty-proposed?
<Laney> s/package same/same package/ ...
<Laney> I guess I can just try it
<apw> Laney, as in will you be able to retry the broken one and copy it back ... i think i have done htat kind of thing in error and it tends to work, but i am no lp-db expert
<Laney> apw: Yeah, can you just copy some binaries back?
<Laney> but I figure that even if that doesn't work, the thing which clears the depwait will be copied and the build will happen again anyway
<apw> i think i removed it and copied it in again, but hmmmm
<apw> right, that would be more normal i guess, copy the bits to teh PPA, prove it fixes things, copy the fixed other package out, depwait clears in -proposed and that build builds
<Laney> well it'll be educational anyway :P
-queuebot:#ubuntu-release- Unapproved: accepted variety [source] (xenial-proposed) [0.6.0-1ubuntu1]
<apw> :)
<apw> my most educational experiences have been through accidents :)
-queuebot:#ubuntu-release- Unapproved: webbrowser-app (zesty-proposed/main) [0.23+17.04.20170310-0ubuntu1 => 0.23+17.04.20170321-0ubuntu1] (ubuntu-desktop, ubuntu-qt-packages) (sync)
<infinity> Laney: It can be done, yes.  Or you could just wait until the silo thing is copied to the archive and the arch builds there.  Unless it's blocking silo promotion, and you're trying to hack around that.
<Laney> infinity: Yeah, the silo's britney is crying
<slangasek> I feel like I should have an animated gif at the ready to go with that comment
<apw> i am sure there is an appropriate utube vidio
<infinity> Laney: It's going to be less about what the archive allows and more about what the silo machinery lets you do, but I guess you'll find out. :P
<infinity> (As in, I suspect silos won't allow you to "release" a package to the archive that has the same version as the archive)
<Laney> It thinks that the package is in the release pocket
<infinity> So it'll probably need an override on the silo side regardless of how you choose to solve it.
<Laney> so I guess that it won't copy it
<infinity> Laney: But the answer to the larger LP question is that, yes, you can copy things around willy-nilly and back again, as long as you make sure the binaries always follow you.  Once you end up with two binary builds for the same arch, it'll tell you to get stuffed.
-queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (xenial-proposed/main) [5.5.1+dfsg-16ubuntu7.2 => 5.5.1+dfsg-16ubuntu7.4] (kubuntu, qt5, ubuntu-desktop) (sync)
<camako> Hi Mir 0.26.2 (bug-fix release, ticket #2600) is in the 'UNAPPROVED' queue. What do I do to get it approved?
<Laney> camako: The queue is regularly reviewed, so it'll be considered soon
<camako> Laney, thanks
-queuebot:#ubuntu-release- Unapproved: accepted gst-libav1.0 [sync] (zesty-proposed) [1.10.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-base1.0 [source] (zesty-proposed) [1.10.4-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-ugly1.0 [source] (zesty-proposed) [1.10.4-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gstreamer-editing-services1.0 [sync] (zesty-proposed) [1.10.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-bad1.0 [source] (zesty-proposed) [1.10.4-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-python1.0 [sync] (zesty-proposed) [1.10.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted gst-plugins-good1.0 [source] (zesty-proposed) [1.10.4-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gstreamer1.0 [sync] (zesty-proposed) [1.10.4-1]
-queuebot:#ubuntu-release- Unapproved: accepted libqapt [source] (zesty-proposed) [3.0.2-0ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted signon-ui [sync] (zesty-proposed) [0.17+17.04.20170320-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mir [sync] (zesty-proposed) [0.26.2+17.04.20170322.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted webbrowser-app [sync] (zesty-proposed) [0.23+17.04.20170321-0ubuntu1]
<infinity> robru: Yo, you around?
<robru> infinity: hey
<infinity> robru: WTF is "Blocking because linux from the same PPA ~canonical-kernel-team/+archive/ubuntu/ppa is invalid" and how do I read that?
<apw> that is "not-english"
<robru> infinity: that means it's being grouped with other packages copied from that PPA.
<apw> robru, which ones
<infinity> robru: So, that has two problems: (1) assuming anything outside silo land is a one-ppa-per-landing scenario is wrong.
<infinity> robru: (2) the message tells me it's blocking on something that is a valid candidate (so, the message is probably wrong).
<robru> apw: you have to ctrl+f for that ppa to find them all
<infinity> robru: Yeah.  VERY VERY WRONG assumption.
<Laney> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#linux
<Laney> linux is blocking itself...
<infinity> robru: They stage all their kernels in a PPA.  Requiring linux-raspi2 to be ready before linux promotes is not sane.
<infinity> (Which is probably what's happening here, despite the error message being a lie)
<infinity> Who thought this was a good idea?
<infinity> Not all PPAs are disposable silos.
<infinity> And the kernel and security team were using theirs for landing long before silos came along. :P
<robru> infinity: well we worked this out with Steve as it was a big problem with bileto having tickets half migrate and half get stuck
<apw> robru, does that not all say they are only unhappy because 'self'
<infinity> robru: Sure, so only check bileto PPAs.
<infinity> (And also fix the error message, but that's less of a concern)
<robru> apw: yes, there's a bug in how it records the message so all the packages look to be blocked by themselves
<apw> robru, regardless of that and it not being appropriate for out PPA, all of those looks to be ok
<apw> oh no, i recind that, there is a block bug for raspi2
<infinity> All of what looks to be okay? :P
<infinity> apw: Exactly.  raspi2 is blocking master, which is why I'm currently yelling on IRC.
<apw> yeah for a moment i didn't notice that (cough) i have blocked it raspi2 too :)
<robru> infinity: of you're in a hurry, push a commit that stops Britney from loading sourceppapolicy, otherwise I'll push a real fix later
<infinity> robru: What will the fix look like?  A whitelist of LP users whose PPAs will be considered by the code (I think that would probably be sanest), or...?
<robru> infinity: yeah
<infinity> Kay.  If "later" can be today, I'm happy to wait on it, so the kernel PPA is an obvious production test case.
<infinity> It's not urgent that it release this hour, but releasing it before the weekend would be a Good Thing.
<robru> infinity: ok I'm just having breakfast, will start on that soon
<infinity> \o/
-queuebot:#ubuntu-release- Unapproved: cargo (zesty-proposed/universe) [0.16.0-0ubuntu1 => 0.17.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pcre3 (zesty-proposed/main) [2:8.39-2 => 2:8.39-3] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted cargo [source] (zesty-proposed) [0.17.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: thunderbird (zesty-proposed/main) [1:45.7.0+build1-0ubuntu1 => 1:45.8.0+build1-0ubuntu1] (mozilla, ubuntu-desktop)
<apw> robru, is there hint language to override that block, does an explict unblock fix it ?
<robru> apw: no, it's processed after hint policy
<apw> that is rather unfortunate
<apw> thoough an explicit unblock of which ever one of those is broke, would that make the set copestetic ?
-queuebot:#ubuntu-release- Unapproved: rejected landscape-client [source] (trusty-proposed) [14.12-0ubuntu4.14.04]
-queuebot:#ubuntu-release- Unapproved: accepted landscape-client [source] (trusty-proposed) [14.12-0ubuntu5.14.04]
<robru> infinity: https://code.launchpad.net/~robru/britney/+git/britney2-ubuntu/+merge/320976 here's a fix confirmed with tests, please merge
<jbicha> infinity: could you re-enable zesty daily iso builds?
<infinity> jbicha: Yep, getting there shortly.
<infinity> robru: An inverse test that tests, say, ~canonical-kernel-team/ or ~ubuntu-security-proposed/ to make sure no one derps up and blocks all PPAs again would be nice (at least, it looks like the tests only test the ci-train case, and maybe the empty/primary case?)
<infinity> robru: Otherwise, lgtm.
<robru> infinity: ok, added a test for ignoring other PPAs. please merge
<salem_> apw, if you need any other information regarding reviewing the new packages on silo 2629 please let me know.
<apw> salem_, sorry got called away, won't be able to sort that today
-queuebot:#ubuntu-release- Unapproved: screen (zesty-proposed/main) [4.5.0-3 => 4.5.0-3ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-welcome (zesty-proposed/universe) [17.04.8 => 17.04.9] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mate-dock-applet (zesty-proposed/universe) [0.76-0ubuntu1 => 0.77-0ubuntu1] (ubuntu-mate)
<salem_> apw, ok, do you know if there is any other admin who could do it for us? it's a very simple package.
-queuebot:#ubuntu-release- Unapproved: accepted tftp-hpa [source] (yakkety-proposed) [5.2+20150808-1ubuntu1.16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-dock-applet [source] (zesty-proposed) [0.77-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-welcome [source] (zesty-proposed) [17.04.9]
-queuebot:#ubuntu-release- Unapproved: accepted screen [source] (zesty-proposed) [4.5.0-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted pcre3 [sync] (zesty-proposed) [2:8.39-3]
-queuebot:#ubuntu-release- Unapproved: accepted tftp-hpa [source] (xenial-proposed) [5.2+20150808-1ubuntu1.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted tftp-hpa [source] (trusty-proposed) [5.2-7ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: gnome-dictionary (zesty-proposed/universe) [3.20.0-3 => 3.24.0-0ubuntu1] (desktop-extra)
<slangasek> cyphermox, jbicha: seems that shim-signed is now correctly erroring out if it needs to set up mok and has no input, but at least one ubuntu-gnome user is getting no debconf prompting when installing a driver? https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1675870
<ubot5> Ubuntu bug 1675870 in shim-signed (Ubuntu) "package shim-signed 1.27+0.9+1474479173.6c180c6-1ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New]
<cyphermox> fun
<jbicha> the iso he installed was dated March 21 but the shim-signed fix is from March 22, could he still have been running the old code?
<cyphermox> no, it shows it's 1.27
<cyphermox> here for some reason this is running in a non-interactive frontend
<cyphermox> my guess is it's additional drivers, and the way that's done doesn't get you a frontend because libgtk2-perl isn't installed and it's not falling back to Dialog because the terminal "window" isn't open when this installs.
<jbicha> that's during the Install itself isn't it? in the apt history log: Requested by ubuntu-gnome (999)
<cyphermox> it looks like it's in live but not done through the installer
<cyphermox> Commandline: aptdaemon role='role-commit-packages' sender=':1.452'
-queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-68-gef18b8ac-0ubuntu1 => 0.7.9-77-g4a2b2f87-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)
<jbicha> oh ok, so shim-signed was updated from the live iso but then he installed nvidia afterwards
-queuebot:#ubuntu-release- Unapproved: xfdashboard (zesty-proposed/universe) [0.6.0-0ubuntu2 => 0.6.1-0ubuntu1] (xubuntu)
-queuebot:#ubuntu-release- Unapproved: indicator-transfer-buteo (zesty-release/universe) [0.1+15.10.20151006-0ubuntu1 => 0.1+15.10.20151006-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted indicator-transfer-buteo [sync] (zesty-release) [0.1+15.10.20151006-0ubuntu1]
<Ukikie> xfdashboard is an unseeded bugfix: https://mail.xfce.org/pipermail/xfce/2016-December/035391.html "Fixed a typo in default application array which prevented the correct default applications to be set up when xfdashboard was started the very first time." (Xfce 12842)
-queuebot:#ubuntu-release- Unapproved: mir (zesty-proposed/main) [0.26.2+17.04.20170322.1-0ubuntu1 => 0.26.2+17.04.20170322.1-0ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gstreamer-vaapi (zesty-proposed/universe) [1.10.4-1 => 1.10.4-1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gstreamer-vaapi [source] (zesty-proposed) [1.10.4-1build1]
-queuebot:#ubuntu-release- Unapproved: mate-panel (zesty-proposed/universe) [1.18.0-0ubuntu1 => 1.18.0-0ubuntu2] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: gnome-sound-recorder (zesty-proposed/universe) [3.21.92-2 => 3.24.0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-sound-recorder [source] (zesty-proposed) [3.24.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (zesty-proposed/main) [3.24.0-0ubuntu1 => 3.24.0-0ubuntu2] (ubuntu-desktop)
#ubuntu-release 2017-03-25
-queuebot:#ubuntu-release- Unapproved: mate-desktop (zesty-proposed/universe) [1.18.0-0ubuntu1 => 1.18.0-0ubuntu2] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mate-settings-daemon (zesty-proposed/universe) [1.18.0-0ubuntu1 => 1.18.0-0ubuntu2] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: qtubuntu-print (zesty-proposed/universe) [0.1+17.04.20170301.2-0ubuntu1 => 0.1+17.04.20170324-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-system-settings (zesty-proposed/main) [0.4+17.04.20170317.2-0ubuntu1 => 0.4+17.04.20170324-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-printing-app (zesty-proposed/universe) [0.1+17.04.20170317-0ubuntu1 => 0.1+17.04.20170323-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-ui-extras (zesty-proposed/main) [0.2+17.04.20170301.2-0ubuntu1 => 0.3+17.04.20170323-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted qtubuntu-print [sync] (zesty-proposed) [0.1+17.04.20170324-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-printing-app [sync] (zesty-proposed) [0.1+17.04.20170323-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: scheme9 (zesty-proposed/universe) [2017.01.25-1 => 2017.01.25-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted scheme9 [source] (zesty-proposed) [2017.01.25-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: youker-assistant (zesty-proposed/universe) [2.0.7-0ubuntu2 => 2.2.7-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: indicator-china-weather (zesty-proposed/universe) [2.1.5-0ubuntu1 => 2.2.1-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: xscreensaver (zesty-proposed/universe) [5.34-2ubuntu1 => 5.36-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted xscreensaver [source] (zesty-proposed) [5.36-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: lirc (zesty-proposed/main) [0.9.4c-7 => 0.9.4c-8] (kubuntu, ubuntu-desktop) (sync)
<tsimonq2> infinity: Hey hey, you around?
#ubuntu-release 2017-03-26
-queuebot:#ubuntu-release- Unapproved: budgie-desktop (zesty-proposed/universe) [10.2.9-3ubuntu3 => 10.2.9-3ubuntu4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libdc0 (zesty-proposed/universe) [0.3.24~svn3121-4 => 0.3.24~svn3121-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libdc0 [source] (zesty-proposed) [0.3.24~svn3121-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (zesty-proposed) [0.1.0~bzr479-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (zesty-proposed) [0.7.9-77-g4a2b2f87-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mate-panel [source] (zesty-proposed) [1.18.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-settings-daemon [source] (zesty-proposed) [3.24.0-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: caja-dropbox (zesty-proposed/multiverse) [1.18.0-0ubuntu1 => 1.18.0-0ubuntu2] (ubuntu-mate)
#ubuntu-release 2018-03-19
<handsome_feng> Hi, Could someone in release team help to look into the ukwm in bionic new queue? It has been there for a long time. :( LP: #1740252
<ubot5`> Launchpad bug 1740252 in Ubuntu Kylin "[FFe] ukwm" [Critical,In progress] https://launchpad.net/bugs/1740252
<tsimonq2> slangasek: Could you look at ukwm when you have the chance? ^^^^^^
<slangasek> tsimonq2, handsome_feng: yes, I'll make some time for ukwm tonight or tomorrow if no one beats me to it; sorry it's been stalled so long
<tsimonq2> slangasek: Many thanks.
<handsome_feng> tsimonq2, slangesek: Thanks very much!
-queuebot:#ubuntu-release- Unapproved: akregator (artful-proposed/universe) [4:17.04.3-0ubuntu1 => 4:17.04.3-0ubuntu1.1] (kubuntu)
<tsimonq2> Laney: Question regarding bug 1654761. I have the implementation for seeing if manually submitted URLs match running tests done, but my next step is doing the same with queued tests. I'm a bit unclear on how I can call get_queue_info() in webcontrol/request/submit.py ... should I import the function directly in webcontrol/request.cgi? I'm a bit lost on where the import goes.
<ubot5`> bug 1654761 in Auto Package Testing "Make sure duplicate tests cannot be queued" [Undecided,In progress] https://launchpad.net/bugs/1654761
<tsimonq2> BTW, my WIP code lives here: https://git.launchpad.net/~tsimonq2/autopkgtest-cloud/+git/bug-1654761
<tsimonq2> But it says "should" so I have the ability to bump it without breaking policy.
<krytarik> tsimonq2: Might want to repeat that in the channel it was intended for. :P
<tsimonq2> krytarik: Er, yeah.
<tsimonq2> krytarik: Thanks.
<krytarik> No problem!
<tsimonq2> (For the curious, I'm referring to the comment I'm about to make in bug 1752733.)
<ubot5`> bug 1752733 in lxterminal (Ubuntu) "xiterm+thai is installed and set to x-terminal-emulator" [High,Triaged] https://launchpad.net/bugs/1752733
-queuebot:#ubuntu-release- New binary: ruby-flipper [amd64] (bionic-proposed/none) [0.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted ruby-flipper [amd64] (bionic-proposed) [0.13.0-2]
<estan> infinity: hey, c-blosc 1.14.2+ds1-1 now ready to be synced from unstable if you're up for it. it includes the fix for the ARM alignment debacle.
<estan> (the important thing it brings is still of course the format compat bug fix: https://bugs.launchpad.net/ubuntu/+source/c-blosc/+bug/1755380)
<ubot5`> Ubuntu bug 1755380 in c-blosc (Ubuntu) "[FFe] Please sync c-blosc 1.14.0+ds1-1 from debian unstable to bionic (1.11.1 has format incompat bug!)" [Undecided,Fix released]
<tsimonq2> slangasek: Can you please process this? https://launchpad.net/bugs/173297n
<ubot5`> Ubuntu bug 173297 in totem (Ubuntu) "after update XVID won" [Undecided,Fix released]
<tsimonq2> er
<tsimonq2> what
<tsimonq2> https://launchpad.net/bugs/1732970
<ubot5`> Ubuntu bug 1732970 in qtsystems-opensource-src (Ubuntu) "Remove cordova-ubuntu-3.4, qtfeedback-opensource-src, qtsystems-opensource-src from archive" [Undecided,New]
<tsimonq2> That. :)
<smb> slangasek, I am trying to fix some up (but since I cannot upload myself that always takes additional time). That other package we talked about here (tunneldigger). Question there is whether its worth fixing up
<apw> smb, tunneldigger has already been removed
<apw> smb, i think all of those are gone actually
<smb> apw, ah ok, I probably should look at current britney
<doko> apw: please ignore the linux autopkg tests on s390x. blocks binutils and gcc-*
<doko> well, if appropriate
<apw> doko, will look shortly
<xnox> apw, it would be nice if the linux-azure kernel migrated from bionic-proposed -> bionic https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1749771 currently blocking foundations from building a full set of cloud images
<ubot5`> Ubuntu bug 1749771 in Kernel Development Workflow "linux-azure: 4.15.0-1002.2 -proposed tracker" [Medium,In progress]
<apw> xnox, indeed
<doko> gcc-defaults-ports (1.173ubuntu1 to 1.174ubuntu3)
<doko> Maintainer: Debian GCC Maintainers
<doko> 0 days old
<doko> missing build on ppc64el: cpp-powerpc-linux-gnu, g++-multilib-powerpc-linux-gnu, g++-powerpc-linux-gnu, gcc-multilib-powerpc-linux-gnu, gcc-powerpc-linux-gnu, gccgo-multilib-powerpc-linux-gnu, gccgo-powerpc-linux-gnu, gcj-powerpc-linux-gnu, gdc-multilib-powerpc-linux-gnu, gdc-powerpc-linux-gnu, gfortran-multilib-powerpc-linux-gnu, gfortran-powerpc-linux-gnu, gobjc++-multilib-powerpc-linux-gnu, gobjc++-powerpc-linux-gnu, gobjc-multilib-powerpc-
<doko> linux-gnu, gobjc-powerpc-linux-gnu, pkg-config-powerpc-linux-gnu (from 1.173ubuntu1)
<doko> Not considered
<doko> because the powerpc packages are now built from the gcc-defaults source
<doko> I mean, I could remove them in the release pocket, but that would temporarily break some build dependencies
<apw> if gcc-defaults migrates first it will take over those binaries won't it ?
<apw> then that one ought to be migratable safely
<xnox> doko, that smells like it needs a britney hint, for the two to go together.
<xnox> and to be considered together
<apw> though it is considering there is no build so it won't consider it in that phase
<LocutusOfBorg> hello folks, I have an issue, I introduced vbox-hwe packages to comply with new hwe stacks, now people are reporting that the hwe packages are not upgraded to bionic
<LocutusOfBorg> how to solve? I mean, virtualbox-guest-x11-hwe should be changed to virtualbox-guest-x11 in the xenial/bionic move
<LocutusOfBorg> but in the future, a new virtualbox-hwe package will exist for bionic too
<LocutusOfBorg> what is the suggestion? make a fake virtualbox-hwe that is the same as virtualbox to make people upgrade smoothly?
<Laney> tsimonq2: if you can import it, that should be OK I think, or else maybe factoring out the amqp bits from browse.cgi would be nice
<xnox> LocutusOfBorg, hwe packages must exists in bionic release pocket
<xnox> LocutusOfBorg, even if they are simply meta-packages pointing at the non-hwe one for now.
<xnox> LocutusOfBorg, we are awaiting linux-meta-hwe for the same reasons.
<tsimonq2> Laney: Oh, meaning, just take the AMQP bits from browse.cgi that I need and then just use that data? That works.
<Laney> tsimonq2: Meaning put them in a common file and include it into browse and the other one
<Laney> Not copy and paste.
<LocutusOfBorg> xnox, makes sense, thanks
<tsimonq2> Laney: Oh, gotcha.
<tsimonq2> Laney: And I guess my original question relates to how to *actually* import it. Where might be the best spot if I wanted to just use the function from browse?
<ginggs> estan: c-blosc sync'd
<Laney> tsimonq2: Actually I don't know since it's a .cgi extension
<Laney> You have to do some weird thing with imp or something I think - probably splitting out is cleanest and then you can put the import at the top
<estan> ginggs: excellent, thanks. i will try it out from -proposed shortly, and report to https://bugs.launchpad.net/ubuntu/+source/c-blosc/+bug/1755380 (which was the original report in which i requested an FFE for 1.14.0).
<ubot5`> Ubuntu bug 1755380 in c-blosc (Ubuntu) "[FFe] Please sync c-blosc 1.14.0+ds1-1 from debian unstable to bionic (1.11.1 has format incompat bug!)" [Undecided,Fix released]
-queuebot:#ubuntu-release- New binary: ruby-flipper-active-record [amd64] (bionic-proposed/universe) [0.10.2-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted ruby-flipper-active-record [amd64] (bionic-proposed) [0.10.2-2]
-queuebot:#ubuntu-release- New: accepted fluidr3mono-gm-soundfont [sync] (bionic-proposed) [2.315-2]
<LocutusOfBorg> hello is it normal that we don't have a "request import" on launchpad anymore?
<LocutusOfBorg> I'm talking about https://code.launchpad.net/~videolan/vlc/+git/vlc
<apw> isn't that saying it is already in the queue ?
<xnox> apw, re: doko bug, one can force-migrate things via hints too, i guess.... to avoid removals / temporary breakage in archive.
<xnox> cause we do not want to raise uninstallable count in release pocket, as otherwise britney can go crazy and trade-migrate borken things
<apw> indeed
<apw> xnox, though this might simply be nbs in -proposed too
<xnox> looking at nbs, btw
<xnox> http://people.canonical.com/~ubuntu-archive/nbs.html -> iproute can be removed, as everything has alternative depends "iproute2|iproute"
<xnox> (otherwise iproute2 would not have migrated....)
<apw> doko, this gcc-defaults-ports -> gcc-defaults move, some of these binaries really are not being made by either any more, on ppc64el
<apw> doko, that s390x looks to be the same thing, hinted
<estan> ginggs: i've tested the c-blosc package in -proposed, it's looking good: https://bugs.launchpad.net/ubuntu/+source/c-blosc/+bug/1755380/comments/4
<ubot5`> Ubuntu bug 1755380 in c-blosc (Ubuntu) "[FFe] Please sync c-blosc 1.14.0+ds1-1 from debian unstable to bionic (1.11.1 has format incompat bug!)" [Undecided,Fix released]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (artful-proposed) [2.31.2+17.10]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.31.2]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.31.2~14.04]
<chrisccoulson> hi, can someone please approve my adobe-flashplugin partner uploads from last week?
<cjwatson> LocutusOfBorg: that just means an import is already queued
<cjwatson> as apw says
<cjwatson> LocutusOfBorg: we had a hardware failure on the machine that was doing most of the code import work, which produced a backlog; a replacement is now in service, and looking at our graphs it's almost finished demolishing the backlog
<cjwatson> was at around 4000 and now at 600
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (xenial-proposed/main) [4.15.0-13.14~16.04.1] (kernel)
<LocutusOfBorg> thanks, nice!
<LocutusOfBorg> btw, I was aware of the backlog, I was just wondering why the "button" disappeared. if being queued means that the button is not clickable, even more efficient :)
<LocutusOfBorg> yeah, "import now" is shown again in the web page, thanks!
-queuebot:#ubuntu-release- New sync: musescore-sftools (bionic-proposed/primary) [20180222-2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (xenial-proposed) [4.15.0-13.14~16.04.1]
<tsimonq2> Laney: So then what would I do after splitting out? ;)
<Laney> tsimonq2: Include the new file in both places and then use the functions
<tsimonq2> Laney: I guess my Python is bad enough that I'm wondering how I'd import it from submit.py if the new file would be in its parent directory, if that makes sense...
<tsimonq2> Laney: Meaning, do I put the new file in w/request or just in w/?
<tsimonq2> (I can figure out everything but this. ;) )
<Laney> tsimonq2: I think the sys.path will be okay since it's run from request.cgi in the top level, but if it's not you should be able to set it yourself
<Laney> That part should be testable locally
<tsimonq2> Laney: ok
<tsimonq2> Laney: That's why I want to be careful, because while I'm checking the majority of my code in the interactive console, I don't have a full setup here...
<Laney> tsimonq2: You should be able to set up a rabbitmq locally to connect to, and then use run-autopkgtest from lp:ubuntu-archive-tools to poke jobs into it
<Laney> If you set up a worker you can even run those jobs :-)
<tsimonq2> Laney: I'll give it a try. :)
<tsimonq2> Laney: Otherwise, how are my two commits looking so far? https://git.launchpad.net/~tsimonq2/autopkgtest-cloud/+git/bug-1654761/?h=remove-ability-to-duplicate-tests-in-queue
<ginggs> estan: bcolz autopkgtests failed (also in Debian) https://ci.debian.net/packages/b/bcolz/unstable/amd64/ does it need an update for the new c-blosc?
<Laney> tsimonq2: I'm busy at the minute, will review properly later on but the shape of them looks nice, good work
<tsimonq2> Laney: Sure, thanks.
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-13.14]
<doko> apw: which ones?
<apw> doko, i have not checked all of the ones in that list britney is whining about, but cirtainly the first one has only amd64/i386 binaries in proposed, which if it was coming out of gcc-default it would be there from that
-queuebot:#ubuntu-release- New: accepted musescore-sftools [sync] (bionic-proposed) [20180222-2]
-queuebot:#ubuntu-release- New binary: musescore-sftools [ppc64el] (bionic-proposed/none) [20180222-2] (no packageset)
-queuebot:#ubuntu-release- New binary: musescore-sftools [s390x] (bionic-proposed/none) [20180222-2] (no packageset)
-queuebot:#ubuntu-release- New binary: musescore-sftools [amd64] (bionic-proposed/none) [20180222-2] (no packageset)
-queuebot:#ubuntu-release- New binary: musescore-sftools [i386] (bionic-proposed/none) [20180222-2] (no packageset)
-queuebot:#ubuntu-release- New binary: musescore-sftools [armhf] (bionic-proposed/none) [20180222-2] (no packageset)
-queuebot:#ubuntu-release- New binary: musescore-sftools [arm64] (bionic-proposed/none) [20180222-2] (no packageset)
<Saviq> hey, what's the best way to get the Ubuntu release code in debian/rules? lsb_release isn't installed on the builders
 * Saviq â #ubuntu-devel, sorry for the noise
-queuebot:#ubuntu-release- New: accepted musescore-sftools [amd64] (bionic-proposed) [20180222-2]
-queuebot:#ubuntu-release- New: accepted musescore-sftools [armhf] (bionic-proposed) [20180222-2]
-queuebot:#ubuntu-release- New: accepted musescore-sftools [ppc64el] (bionic-proposed) [20180222-2]
-queuebot:#ubuntu-release- New: accepted musescore-sftools [arm64] (bionic-proposed) [20180222-2]
-queuebot:#ubuntu-release- New: accepted musescore-sftools [s390x] (bionic-proposed) [20180222-2]
-queuebot:#ubuntu-release- New: accepted musescore-sftools [i386] (bionic-proposed) [20180222-2]
-queuebot:#ubuntu-release- Unapproved: accepted flatpak [source] (artful-proposed) [0.8.9-0ubuntu0.1]
<infinity> estan: Second hurdle, the new c-blosc regresses bcolz: https://ci.debian.net/packages/b/bcolz/unstable/amd64/
<ginggs> infinity: he is aware, i updated the sync bug
<infinity> ginggs: Ahh, missed that in backscroll.
<xnox> infinity, please clean-up NBS libstd-rust-1.23, and then rustc 1.24.1 should migrate; on all arches btw ;-)
<xnox> NBS in bionic-proposed that is
<infinity> xnox: Thwacking.
<infinity> doko: Are you doing a gcc-defaults upload to match http://launchpadlibrarian.net/361173244/gcc-defaults-ports_1.174ubuntu1_1.174ubuntu2.diff.gz ?
<infinity> doko: (or reverting that change entirely, which I think would also be fine)
<bashfulrobot> How's everyones beta testing/feedback going?
<estan> infinity: yea, ginggs alerted me to it :( i could reproduce it with bcolz master and made an upstream report: https://github.com/Blosc/bcolz/issues/374
<estan> (same upstream author, so hopefully it's just something wrong with the tests. would think it careless if he's breaking his own downstream in a minor version :))
<slangasek> doko: are these various old gcc-N-cross packages really useful to carry?  Why do we need more than just the current default version?
<slangasek> doko: btw, are we ready to drop gcc-4.8 now?  annoyingly, debian/control for old gcc series is never cleaned up wrt binaries that it no longer ships, so 'reverse-depends src:gcc-4.8' is useless for figuring this out; but I think we may have finally dropped the remaining bits of the Ubuntu Touch stack that needed it
<slangasek> doko: https://paste.ubuntu.com/p/TS7FphQCK3/ and all the rest are alternatives.  So I think we can drop gcc-4.8 now
<slangasek> xnox: why does boost prefer libstdc++-4.8-dev over libstdc++-dev?
<slangasek> doko: LP: #1756972, I can pull the trigger or let you do it
<ubot5`> Launchpad bug 1756972 in gcc-4.8 (Ubuntu) "RM: gcc-4.8: no longer used" [Undecided,New] https://launchpad.net/bugs/1756972
<slangasek> doko: gcc-5 seems to have exactly two packages still using libgo7; maybe we should fix those and drop gcc-5 as well? (minica/s390x; pluginhook)
<jbicha> slangasek: LP: #1756871 should be an easy one to remove :)
<ubot5`> Launchpad bug 1756871 in libxfont1 (Ubuntu) "Please remove libxfont1 from Ubuntu" [Undecided,New] https://launchpad.net/bugs/1756871
<slangasek> jbicha: why are we removing it from Ubuntu if it hasn't been removed yet from Debian?
<jbicha> well we could wait a week or two for Debian if you wantâ¦
<jbicha> its last rdepends was fixed this weekend
<slangasek> jbicha: it's much more efficient to run process-removals against Debian removals rather than handle via individual launchpad bugs
<jbicha> the fact that it has Ubuntu revisions doesn't matter much for that?
<slangasek> jbicha: I always review the Ubuntu delta while running process-removals, and it's usually clear whether the delta represents a real committment to maintenance
<slangasek> in this case it's security updates, so clearly not
<slangasek> doko: minica, pluginhook uploaded (no-change rebuilds); gcc-5 is now free to go
<slangasek> doko: LP: #1756979 - though maybe this one should be handled via Debian removal?
<ubot5`> Launchpad bug 1756979 in gcc-5-cross (Ubuntu) "RM: gcc-5: no longer used" [Undecided,New] https://launchpad.net/bugs/1756979
-queuebot:#ubuntu-release- New source: virtualbox-hwe (bionic-proposed/primary) [5.2.8-dfsg-5ubuntu18.04.1]
<LocutusOfBorg> please accept virtualbox-hwe :) this is the upgrade path from xenial package
<slangasek> chrisccoulson: I'm looking around for the adobe-flashplugin uploads you mentioned and I'm not finding them in queues.  Can you point me to where they are, specifically?
<chrisccoulson> slangasek, oh, I just checked and someone approved them on thursday. Sorry about that :(
<chrisccoulson> they do need copying to the release pocket though (if you give me half an hour or so)
<slangasek> chrisccoulson: ack
<chrisccoulson> slangasek, ok, those are good to go
<slangasek> chrisccoulson: done
<chrisccoulson> slangasek, excellent, thanks!
-queuebot:#ubuntu-release- New source: virtualbox-hwe (bionic-proposed/primary) [5.2.8-dfsg-5ubuntu18.04.1]
<sil2100> C/quit
<sil2100> eh
<sil2100> ;)
<sil2100> o/
<tsimonq2> irssi!
<tsimonq2> :D
<tsimonq2> (maybe?)
<wxl>  /ctcp nick version
<wxl> :)
<wxl> but /quit's pretty universal across clients
<tsimonq2> wxl: He doesn't have a bouncer (*ahem*) so I dunno if that's info I can see. :)
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.17 => 2.02~beta2-36ubuntu3.18] (core)
#ubuntu-release 2018-03-20
<xnox> Is there an "updates-excuses" page generated for xenial?
<jbicha> xnox: um, just take the "bionic" pages and replace "bionic" with "xenial" ;)
<xnox> jbicha, replace what in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html ?
<jbicha> oh I use https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html
<xnox> ah
<jbicha> I didn't realize there was another version!
 * xnox is old school; the one for "devel" series was the original, the one and only.....
<xnox> jbicha, thanks!
<doko> infinity: why? we still need the powerpc cross build for ppc64el, and I didn't want to have -cross and -cross-ports packages in main
<doko> slangasek: let me copy these first to a PPA before removing them
<doko> ahh, I see what you mean
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.17 => 2.02~beta2-36ubuntu3.18] (core)
<doko> slangasek: what to do about the ant upload, and excuses complaining about the missing -gcj packages?
<slangasek> doko: fix your debian/control to stop referencing binaries you don't build?
<doko> $ grep gcj debian/control || echo no
<doko> no
<doko> slangasek: ^^^
<tsimonq2> infinity, chrisccoulson: I think it'd be great to get Firefox working on armv7l-bases systems again. Could I maybe get some eyes on bug 1711337, which claims to have a solution for that?
<ubot5`> bug 1711337 in firefox (Ubuntu) "Firefox crashes at start on armv7L after 55.0.1 update" [Undecided,Confirmed] https://launchpad.net/bugs/1711337
<infinity> doko: Meh.  Your package, mangle it as you see fit.  Doesn't make sense to me to have weird logic just to avoid having that source in main.
<doko> infinity: is that about ant?
<infinity> doko: No, the gcc-defaults versus gcc-defaults-ports thing.
<doko> ahh, ok
<doko> already fixed
<infinity> tsimonq2: I see no solution in that mess of a bug log.
<infinity> And LP also won't let me comment on it.  Grr.
<tsimonq2> infinity: Apparently, some build flags need to be enabled.
<tsimonq2> infinity: Don't shoot the messenger, I guess. :)
<infinity> tsimonq2: No.  That's someone shooting wildly in the dark.
<tsimonq2> infinity: Alright.
<infinity> tsimonq2: Those CFLAGS are literally what defines armhf as armhf.  They're the defaults.
<tsimonq2> infinity: TIL.
<tsimonq2> infinity: Thanks for the comment on the bug report.
<infinity> It only took 32 tries to post it.
<tsimonq2> I hope you're exaggerating. :P
<infinity> Not really.  I didn't count, so I'm extrapolating, but I don't think I'm far off.
<tsimonq2> Hah.
<infinity> Oh, AJAX log will tell me.  I was off by a factor of 2, apparently.  16 tries.
<tsimonq2> Wow.
<tsimonq2> infinity: Got your axe handy? bug 1745741
<ubot5`> bug 1745741 in pykde4 (Ubuntu Bionic) "RM: removed in Debian, working towards Qt 4 removal goal" [Medium,New] https://launchpad.net/bugs/1745741
<tyhicks> hello! could apparmor 2.12-4ubuntu1 be let through in bionic?
<tyhicks> I've fixed the docker.io test errors (not failures) with this upload: https://launchpad.net/ubuntu/+source/docker.io/17.03.2-0ubuntu4
<tyhicks> however, docker.io and golang 1.10 aren't compatible (https://github.com/moby/moby/pull/35739) so docker.io won't build now that golang 1.10 is in bionic
<tyhicks> I've asked mwhudson for guidance when he's around
<tyhicks> as for the snapd i386 test failure, it is failing on i386 on completely random tests that differ from test run to test run
<tsimonq2> tyhicks: Why let it through when all arches are FTBFS? :)
<tsimonq2> Er, I'm thinking of the wrong thing, aren't I?
<tyhicks> tsimonq2: that's docker.io that is FTBFS, not apparmor
<tsimonq2> Yeah.
<tyhicks> I've locally verified that my docker.io autopkgtest changes fix the docker.io test error that we were seeing
<tsimonq2> I updated https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure for the Alioth -> Salsa migration.
<tsimonq2> There might be other URLs that have Alioth-ish things.
<mwhudson> tyhicks: ugh well i have a docker upgrade to review & upload
<slangasek> doko: oh, I see, it's a case of arch: any NBS from a package that's now arch: all only.  Yeah, the only thing to be done is to manually remove the arch-dep binaries from the release pocket; done
-queuebot:#ubuntu-release- New binary: gnome-user-docs [amd64] (bionic-proposed/main) [3.28.0-0ubuntu2] (personal-gunnarhj, ubuntu-desktop)
<slangasek> tsimonq2: what's the story with libkf5kface? going nowhere fast in -proposed
<slangasek> acheronuk: ^^
<tsimonq2> slangasek: I dunno, I was more focused on nodejs, looking now.
<slangasek> tsimonq2: k.  also, ukwm accepted and I really hope someone didn't write that debian/copyright by hand.
<tsimonq2> Â¯\_(ã)_/Â¯
-queuebot:#ubuntu-release- New: accepted ukwm [source] (bionic-proposed) [1.1.7-0ubuntu1]
<tsimonq2> slangasek: While you're at it, bug 1745741 could use an axe.
<ubot5`> bug 1745741 in pykde4 (Ubuntu Bionic) "RM: removed in Debian, working towards Qt 4 removal goal" [Medium,New] https://launchpad.net/bugs/1745741
<tsimonq2> handsome_feng: ukwm accepted ^^^^^^
<slangasek> tsimonq2: done
<slangasek> tsimonq2, acheronuk: do you know what should be done with gpgmepp ?  Removed from unstable, but akonadi-import-wizard still build-depends on it
<tsimonq2> slangasek: Thanks
<slangasek> /<<PKGBUILDDIR>>/SurgSim/Blocks/DebugDumpBehavior.cpp:97:13: error: âcoutâ is not a member of âstdâ
-queuebot:#ubuntu-release- New binary: ukwm [s390x] (bionic-proposed/none) [1.1.7-0ubuntu1] (no packageset)
<tsimonq2> slangasek: I'll look too
<slangasek> ... yes, of course it's not
<slangasek> cout is not now, nor ever has been, a member of std
-queuebot:#ubuntu-release- New binary: ukwm [ppc64el] (bionic-proposed/none) [1.1.7-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukwm [i386] (bionic-proposed/none) [1.1.7-0ubuntu1] (no packageset)
<tsimonq2> slangasek: I *could* be wrong so I'll confirm this, but if I recall correctly, gpgmepp is an optional build dep and can be removed.
-queuebot:#ubuntu-release- New binary: ukwm [amd64] (bionic-proposed/none) [1.1.7-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukwm [arm64] (bionic-proposed/universe) [1.1.7-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ukwm [armhf] (bionic-proposed/universe) [1.1.7-0ubuntu1] (no packageset)
<tsimonq2> slangasek: It'd be cool to get this merged and uploaded, then kdesudo can be removed: https://code.launchpad.net/~tsimonq2/ubuntu-release-upgrader/port-away-from-kdesudo/+merge/341555
<handsome_feng> slangasek, tsimonq2: Thanks! \^O^/
<tsimonq2> slangasek: gpgmepp> https://launchpad.net/ubuntu/+source/akonadi-import-wizard/17.12.3-0ubuntu2 have fun
<tsimonq2> handsome_feng: :D
<nacc> tjaalton: do you know who would be responsibel for LP: #1756380 ?
<ubot5`> Launchpad bug 1756380 in intel-vaapi-driver (Ubuntu) "vaapi VP9 hardware decoding not working anymore in bionic" [Undecided,Confirmed] https://launchpad.net/bugs/1756380
<tsimonq2> slangasek: libkf5kface> imho it'd be better to just RM it. Debian has an open RC bug that's been there since October irt it not working with a transition that's already landed. No point in continuing to have it in -proposed imho.
<tsimonq2> slangasek: Mind sorting bug 1757043? This is a first... https://paste.ubuntu.com/p/T2rd985QRf/
<ubot5`> bug 1757043 in Ubuntu "Sync apper 1.0.0-1 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1757043
<tsimonq2> (Well, a first for *me*.)
<tsimonq2> slangasek: Reintroduction of civicrom (as previously discussed) incoming.
-queuebot:#ubuntu-release- New source: civicrm (bionic-proposed/primary) [4.7.30+dfsg-1ubuntu1]
<tjaalton> nacc: me probably
<slangasek> tsimonq2: akonadi-import-wizard - cheers.  apparently I overlooked that korganizer also build-depends on it.
<tsimonq2> slangasek: I'll do that too.
-queuebot:#ubuntu-release- New: accepted gnome-user-docs [amd64] (bionic-proposed) [3.28.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted ukwm [arm64] (bionic-proposed) [1.1.7-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukwm [i386] (bionic-proposed) [1.1.7-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukwm [s390x] (bionic-proposed) [1.1.7-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukwm [amd64] (bionic-proposed) [1.1.7-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukwm [ppc64el] (bionic-proposed) [1.1.7-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ukwm [armhf] (bionic-proposed) [1.1.7-0ubuntu1]
<mwhudson> tyhicks: orrr you could force docker.io to build with go 1.9 i guess (b-d on golang-1.9-go, add /usr/lib/go-1.9/bin to $PATH in d/rules)
<slangasek> tsimonq2: apper removed from blacklist; syncing it from there is up to you
<tsimonq2> slangasek: ack
<slangasek> doko: https://launchpad.net/ubuntu/+source/gcc-5-cross/32ubuntu1 - is that a 'no' on dropping gcc-5?
<slangasek> Laney: were you continuing to roll out the new-style lxd setup to the armhf runners? http://autopkgtest.ubuntu.com/packages/a/adql/bionic/armhf
-queuebot:#ubuntu-release- New sync: apper (bionic-proposed/primary) [1.0.0-1]
<tsimonq2> slangasek: ^^^^^
<doko> slangasek: I'd like to get this into a consistent shape first. we can discuss if we want to remove it, or move it into a PPA
<slangasek> doko: I'm not sure who it serves to worry about old and unused compilers <shrug>
<slangasek> if you want it in a ppa, I don't see why you wouldn't just move it to a ppa and sort it out there
<doko> because I don't see dak's hints and excuses
<doko> does it personally hurt you, or is it just your eyes?
<slangasek> doko: is the time your fellow developers spend scrolling past junk in update_excuses of no value?
<tsimonq2> *cough* merge pages
-queuebot:#ubuntu-release- New source: peruse (bionic-proposed/primary) [1.2+dfsg-1]
<doko> come on ... that's lame
<tsimonq2> slangasek: libkf5kface> I don't mean to pester, but do you want a bug for this, or can you just RM it? :)
<slangasek> tsimonq2: ah, bug preferred for that one please
<tsimonq2> slangasek: gpgmepp> https://launchpad.net/ubuntu/+source/korganizer/4:17.12.3-0ubuntu2
-queuebot:#ubuntu-release- New: accepted civicrm [source] (bionic-proposed) [4.7.30+dfsg-1ubuntu1]
<tsimonq2> slangasek: I don't think bug 1757051 needs to be an FFe. Agree/disagree?
<ubot5`> bug 1757051 in ubuntukylin-wallpapers (Ubuntu) "[FFe] Update ubuntukylin-wallpapers from 17.10.2 to 18.04.0" [Undecided,New] https://launchpad.net/bugs/1757051
-queuebot:#ubuntu-release- New source: virtualbox-hwe (bionic-proposed/primary) [5.2.8-dfsg-5ubuntu18.04.1]
-queuebot:#ubuntu-release- New binary: civicrm [amd64] (bionic-proposed/none) [4.7.30+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted civicrm [amd64] (bionic-proposed) [4.7.30+dfsg-1ubuntu1]
<infinity> tsimonq2: That's UIF, not FF.
<infinity> tsimonq2: And also limited to the flavour itself, so if they want to break it, all them.
<tsimonq2> infinity: But it's not a FFe. :P
<acheronuk> slangasek tsimonq2: yeah, gpgmepp deps should be cleaned out
<tsimonq2> (Or, doesn't need to be, rather.)
<tsimonq2> acheronuk: Kool.
<tsimonq2> handsome_feng: ^^^^ so you're fine to proceed with bug 1757051.
<ubot5`> bug 1757051 in ubuntukylin-wallpapers (Ubuntu) "[FFe] Update ubuntukylin-wallpapers from 17.10.2 to 18.04.0" [Undecided,New] https://launchpad.net/bugs/1757051
<tsimonq2> infinity: Anyway, thanks.
<handsome_feng> tsimonq2: So could you help to upload this package?
<tsimonq2> handsome_feng: Oh, absolutely.
<tsimonq2> handsome_feng: I thought you were a member of ~ubuntukylin-dev. :)
<handsome_feng> tsimonq2: I will apply for it :)
<tsimonq2> handsome_feng: Uploading now; I added the LP bug number to the changelog so you know when it migrates. :)
<handsome_feng> tsimonq2: Thanks! and could you help upload the ukui-window-switch? since the ukwm has been accepted. LP: #1741209
<ubot5`> Launchpad bug 1741209 in Ubuntu Kylin "[FFe] ukui-window-switch" [High,New] https://launchpad.net/bugs/1741209
<slangasek> doko: is it you that is promoting gstreamer1.0-gl to main while libgraphene-1.0-0 is still in universe?  (please don't; it breaks the daily image builds.)
<doko> slangasek: I think I did it yesterday, showing up in component mismatches
<slangasek> doko: ok.  it looks like there's an MIR that could use some assistance: https://bugs.launchpad.net/ubuntu/+source/graphene/+bug/1753581
<ubot5`> Ubuntu bug 1753581 in graphene (Ubuntu) "[MIR] graphene" [Undecided,New]
<doko> I'll have a look after the next session
-queuebot:#ubuntu-release- New sync: ruby-logging (bionic-proposed/primary) [2.2.2-1]
-queuebot:#ubuntu-release- New: accepted ruby-logging [sync] (bionic-proposed) [2.2.2-1]
-queuebot:#ubuntu-release- New binary: ruby-logging [amd64] (bionic-proposed/none) [2.2.2-1] (no packageset)
<handsome_feng> tsimonq2: I saw your messages in ubuntu-desktop, I know you are very busy now, so just go ahead with your own business and thanks again!  :)
<tsimonq2> handsome_feng: I'm doing a few things at once, don't worry about it. ;)
<tsimonq2> I'll review after I catch some Zs; I'm too tired to continue.
<tsimonq2> In the meantime, your package is still uploading. I'll leave it to upload; it's a pretty big one. :)
<tsimonq2> o/
<handsome_feng> tsimonq2: Thanks and take care of your body!
<tsimonq2> :)
-queuebot:#ubuntu-release- Unapproved: pulseaudio (xenial-proposed/main) [1:8.0-0ubuntu3.8 => 1:8.0-0ubuntu3.9] (core)
-queuebot:#ubuntu-release- New: accepted ruby-logging [amd64] (bionic-proposed) [2.2.2-1]
-queuebot:#ubuntu-release- New source: virtualbox-hwe (bionic-proposed/primary) [5.2.8-dfsg-5ubuntu18.04.1]
-queuebot:#ubuntu-release- New binary: ldc [ppc64el] (bionic-proposed/universe) [1:1.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ldc [i386] (bionic-proposed/universe) [1:1.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ldc [amd64] (bionic-proposed/universe) [1:1.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ldc [armhf] (bionic-proposed/universe) [1:1.8.0-1] (no packageset)
<sergiusens> Laney: hey there, I am having issues with upstream triggers of autopkgtests, they trigger fine, but they don't seem to report back (no idea where the issue is) e.g; https://github.com/snapcore/snapcraft/pull/2008 has a state of running, I saw them running on http://autopkgtest.ubuntu.com/running#pkg-snapcraft but then they just went away
<Laney> sergiusens: Some slight downtime atm due to gnupg dropping off the standard install
<sergiusens> Laney: so to line up events, is this issue from before yesterday?
<Laney> I think it happened last night
<Laney> sergiusens: oh ok, this is something different
<Laney> if you go to the raw index https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-snapcraft-daily/?format=plain&prefix=xenial/amd64/s/snapcraft/
<Laney> and pick one of the most recent results, e.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-snapcraft-daily/xenial/amd64/s/snapcraft/20180320_104915_9ee8b@/log.gz
<Laney> it's complaining about this patchelf dependency
<Laney> I'm not sure why that doesn't report back as a failure though
<sergiusens> Laney: doesn't autopkgtest run with -proposed enabled?
<sergiusens> Laney: patchelf (0.9-1~...) is in xenial-proposed. As a side comment, we have the same issue when trigerring from bionic https://github.com/snapcore/snapcraft/pull/2010
<sergiusens> Laney: like this one https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic-snappy-dev-snapcraft-daily/bionic/amd64/s/snapcraft/20180320_015341_d3827@/log.gz
<Laney> sergiusens: I kicked the status reporter, they are marked as failed now
<sergiusens> Laney: ty! Even more so, for the link with the list of runs; that solves a bunch of problems for me :-)
<Laney> and no, no proposed unless it's asked for as part of the request
<Laney> sergiusens: nice, you can replace plain with json too if you want to parse it for any reason
<sergiusens> Laney: so my followup question is, how to I get patchelf from -proposed in my xenial runs?
<Laney> it's been 10 days, so verify the SRU and get sil210_0 to release it ;-)
<Laney> 7*
<sergiusens> Laney: hah, I wanted to use our snapcraft autopkgtest as part of verification for that though
<Laney> oh, well... copy it to the PPA you're using?
<Laney> copy-package --from=ubuntu --to=\~snappy-dev/ubuntu/snapcraft-daily --from-suite=xenial-proposed --to-suite=xenial --include-binaries patchelf
<Laney> good news for snapcraft too is once I get armhf back online it'll be using stgraber's new secret sauce to hopefully make the tests work
<sergiusens> Laney: good deal, thanks!
<sergiusens> Laney: so the dns timeouts have been worked out?
<Laney> that's the hope
<Laney> we did a manual test run and it went through without timing out
<sergiusens> nice, I will keep an eye on it; was the fix in lxd itself?
-queuebot:#ubuntu-release- New source: virtualbox-hwe (bionic-proposed/primary) [5.2.8-dfsg-5ubuntu18.04.1]
<Laney> using a newer lxd and changing the networking setup a bit
<Laney> like using the upstream DNS server directly
<Laney> https://git.launchpad.net/autopkgtest-cloud/commit/?id=6979684bcc9a5c9425756e8910c00b251f4c2048
<sergiusens> this is good news; I am glad this was looked into :-)
<Laney> :>
<Laney> all back up now
<Laney> slangasek: all redeployed, turned out that changing the priority on gpg broke an assumption in autopkgtest so I took the chance to burn it to the ground and start again while fixing that
<xnox> apw, at https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1749771 and I have out of bound confirmation that stakeholder sign-off was done, is that bug ready to have "block-proposed" tag removed?
<ubot5`> Ubuntu bug 1749771 in Kernel Development Workflow "linux-azure: 4.15.0-1002.2 -proposed tracker" [Medium,In progress]
<xnox> apw, I am confused about brad adding "regression-testing-passed" tag, yet still having "Automated-testing: confirmed"
<tjaalton> does ubuntu care about "sourceless files", like shaders in intel-vaapi-driver? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867340
<ubot5`> Debian bug 867340 in i965-va-driver "Contains binary files without corresponding source" [Serious,Fixed]
<apw> xnox, regression-testing-passed is unrelated to automated-testing
<xnox> apw, ah! so i thought =)
<tjaalton> this split probably broke the driver, partially
 * xnox 's hunch was correct
<apw> xnox, it is related to regression-testing only
<xnox> tjaalton, is that shipped in restricted/multiverse?
<tjaalton> so I'm wondering if the split should be undone for bionic
<tjaalton> xnox: the driver isn't
<tjaalton> i65-va-driver-shaders is
<tjaalton> i965-
<apw> xnox, and you never remove the block-proposed tag, that is shanky's job
<apw> xnox, it is pending the ADT testing passing
<xnox> tjaalton, you may need AA review on that. E.g. we pushed linux-firmware into main. But i would hope we can keep shaders in restricted/multiverse (source-less should be fine)
<tjaalton> xnox: alright
<tjaalton> well, the option would be to un-split it and ship in restricted
<tjaalton> oh, the driver is in universe, so multiverse then
<tjaalton> weird, I thought it was seeded
<Mirv> I think the driver has not been, although it would naturally be better if it was as otherwise most people won't get hw acceleration. that's one of the first things I install on a new install.
-queuebot:#ubuntu-release- New: accepted apper [sync] (bionic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted ldc [armhf] (bionic-proposed) [1:1.8.0-1]
-queuebot:#ubuntu-release- New: accepted ldc [ppc64el] (bionic-proposed) [1:1.8.0-1]
-queuebot:#ubuntu-release- New: accepted ldc [amd64] (bionic-proposed) [1:1.8.0-1]
-queuebot:#ubuntu-release- New: accepted peruse [source] (bionic-proposed) [1.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ldc [i386] (bionic-proposed) [1:1.8.0-1]
<tjaalton> Mirv: iirc it's installed if the checkbox to install some codecs etc is checked
<tjaalton> Mirv: fyi, I have a package ready to go to multiverse/video
-queuebot:#ubuntu-release- New binary: peruse [s390x] (bionic-proposed/none) [1.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: apper [s390x] (bionic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: apper [i386] (bionic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: peruse [ppc64el] (bionic-proposed/none) [1.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: peruse [amd64] (bionic-proposed/none) [1.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: apper [ppc64el] (bionic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: peruse [i386] (bionic-proposed/none) [1.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: apper [amd64] (bionic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: peruse [arm64] (bionic-proposed/none) [1.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: peruse [armhf] (bionic-proposed/none) [1.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: apper [arm64] (bionic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: apper [armhf] (bionic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New source: pyxs (artful-proposed/primary) [0.4.1+dfsg1-0ubuntu1~17.10.0]
-queuebot:#ubuntu-release- New source: pyxs (xenial-proposed/primary) [0.4.1+dfsg1-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- New source: rax-nova-agent (artful-proposed/primary) [2.1.12-0ubuntu2~17.10.0]
-queuebot:#ubuntu-release- New source: rax-nova-agent (xenial-proposed/primary) [2.1.12-0ubuntu2~16.04.0]
<Mirv> tjaalton: great for the latter! and oh, ok for the former, I usually don't check the checkbox since at some point it installed restricted-extras which included things I don't want like ms truetype fonts.
<LocutusOfBorg> please apw sil2100 review virtualbox-hwe in bionic :(
<LocutusOfBorg> :)
<LocutusOfBorg> it is the same tarball of the already released one, so it should be a quick accept
-queuebot:#ubuntu-release- Unapproved: avahi (artful-proposed/main) [0.6.32-1ubuntu1 => 0.6.32-1ubuntu1.1] (core)
<coreycb> hello release team, bug 1757141 should unblock horizon and other openstack dashboards from proposed migration
<ubot5`> bug 1757141 in python-django-openstack-auth (Ubuntu) "[RM] Package needs to be removed in Bionic" [Undecided,New] https://launchpad.net/bugs/1757141
<tyhicks> mwhudson: thanks - I'll give that a shot
-queuebot:#ubuntu-release- Unapproved: avahi (xenial-proposed/main) [0.6.32~rc+dfsg-1ubuntu2 => 0.6.32~rc+dfsg-1ubuntu2.1] (core)
-queuebot:#ubuntu-release- Unapproved: avahi (trusty-proposed/main) [0.6.31-4ubuntu1.1 => 0.6.31-4ubuntu1.2] (core)
<sil2100> LocutusOfBorg: I might take a look at it a bit later - what is it's purpose in bionic?
<juliank> probably upgrades from xenial
-queuebot:#ubuntu-release- Unapproved: grub2-signed (xenial-proposed/main) [1.66.17 => 1.66.18] (core)
<LocutusOfBorg> sil2100, exactly, people having vbox-hwe in xenial, should move to vbox-hwe in bionic
<LocutusOfBorg> that right now it is just a new binary identical with the virtualbox, but in the future, will start tracking real hwe packages
<LocutusOfBorg> (right now it tracks the xserver-xorg-hwe-16.04 package)
<sil2100> Ok, that's what I thought then, I'll need a few more minutes before looking into that though
<slangasek> Laney: ok. was the DNS resolution failure I linked above before or after the redeploy, then?
<Laney> slangasek: I did it today
<slangasek> Laney: ack
<Laney> did someone clean up priority mismatches or something?
<apw> Laney, looks to be lots of bits on there to me
<Laney> apw: yeah, can't see the graph though
<slangasek> well, I hope someone didn't clean up priority-mismatches by promotions
<slangasek> those libs all need to be dropped back out; I talked to xnox about it
<xnox> hmmm
<xnox> slangasek, boost?
<slangasek> xnox: libunistring->harfgraphite->dns->freetype
<slangasek> or something
<xnox> ah, yes.
<xnox> i should totally do this asap.
<nacc> tjaalton: thanks for the updates on that bug; particularly noisy user
<coreycb> bdmurray: we should be all set to promote to updates for bug 1755027 and bug 1747065
<ubot5`> bug 1755027 in trove-dashboard (Ubuntu Artful) "[SRU] local_settings.py is world readable and contains passwords" [Critical,Fix committed] https://launchpad.net/bugs/1755027
<ubot5`> bug 1747065 in nova (Ubuntu Artful) " [SRU] pike stable releases" [Undecided,Fix committed] https://launchpad.net/bugs/1747065
<bdmurray> coreycb: and you wanted 1755027 expedited (released in less than 7 days) correct?
<coreycb> bdmurray: yes please if possible
-queuebot:#ubuntu-release- New sync: deepin-terminal (bionic-proposed/primary) [2.9.2-1]
-queuebot:#ubuntu-release- New sync: deepin-screenshot (bionic-proposed/primary) [4.0.11-1]
<tsimonq2> Can I get the apper binaries accepted please?
-queuebot:#ubuntu-release- New binary: mongodb [s390x] (bionic-proposed/universe) [1:3.4.7-1ubuntu3] (mozilla)
<cjwatson> tsimonq2: done
<tsimonq2> cjwatson: Thanks.
-queuebot:#ubuntu-release- New: accepted apper [amd64] (bionic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted apper [armhf] (bionic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted apper [ppc64el] (bionic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted apper [arm64] (bionic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted apper [s390x] (bionic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted apper [i386] (bionic-proposed) [1.0.0-1]
<slangasek> tsimonq2: you're going to file a bug on libkf5kface?
<tsimonq2> slangasek: I'll get to it as soon as I can, unless ofc you want to JFDI (the bug report won't say much).
<slangasek> tsimonq2: because this is a new upstream version not present in Debian of a package maintained by the kubuntu team, I would prefer an audit trail before I whack it
<tsimonq2> slangasek: bug 175720
<ubot5`> bug 175720 in memtest86+ (Ubuntu) "ELF image not installed anywhere, would be useful" [Undecided,Fix released] https://launchpad.net/bugs/175720
<tsimonq2> ger
<tsimonq2> bugg 175720
<tsimonq2> ...
<tsimonq2> I hate this keyboard
<tsimonq2> bug 175720
<tsimonq2> Ok, just add a 1 at the end, ugh...
<tsimonq2> Sorry
<slangasek> tsimonq2: only bug open on the package, very findable ;)
<tsimonq2> Hah.
<tsimonq2> True.
<tsimonq2> Thanks slangasek.
<acheronuk> slangasek: hi. I have new libqapt and Muon package manager release for KDE, but with these changes: https://mail.kde.org/pipermail/kde-announce-apps/2018-March/005433.html
<acheronuk> so nearly all bugfix, but one alleged 'feature' which you could argue the toss on
<slangasek> acheronuk: I am therefore not going to argue it - please go ahead
<acheronuk> slangasek: great. thank you
<tsimonq2> slangasek: Mind accepting peruse binaries?
<slangasek> tsimonq2: I was about to ping you asking why this has a -1 version number
<tsimonq2> slangasek: uhm wat
<slangasek> it's not a Debian sync and it has a -1?
<tsimonq2> Yeah I messed that up... shoot.
<slangasek> and why did an AA accept it in that state ;)
<tsimonq2> Â¯\_(ã)_/Â¯
<tsimonq2> It's the same thing that's going to go into Debian
<slangasek> except it's not synced from Debian, and it's not guaranteed to be accepted into Debian with identical contents
<slangasek> I: peruse: no-symbols-control-file usr/lib/x86_64-linux-gnu/libacbf.so
<tsimonq2> True.
<slangasek> so somebody accepted that, ah?
<tsimonq2> Â¯\_(ã)_/Â¯
<slangasek> W: peruse: appstream-metadata-in-legacy-location usr/share/appdata/org.kde.perusecreator.appdata.xml
<tsimonq2> I thought you were going to review it so we could discuss the best path forward for libacbf.so
<tsimonq2> i.e. if it's fine as is
<slangasek> well, I suggested that someone should find my previous reject message so I could remember what the actual reason was that I rejected it
<acheronuk> tsimonq2 would have got that email
<tsimonq2> I couldn't find it
<slangasek> k
 * acheronuk goes back to lurking
<slangasek> in any event, I don't know who accepted the source this time because there's no audit logs of that either
<tsimonq2> Maybe they thought I was just fakesyncing it.
<apw> doesn't sound like anything i was involved in
<tsimonq2> Anyway
<tsimonq2> slangasek: What now?
<slangasek> tsimonq2, acheronuk: this version still has the wrong lintian overrides about libacbf.so.  Please just drop these instead of suppressing lintian's correct complaints.
<slangasek> but I don't see anything here that should block binary NEW
<tsimonq2> slangasek: How would I go about fixing these correct complaints?
<tsimonq2> These are new errors to me.
-queuebot:#ubuntu-release- New: accepted peruse [amd64] (bionic-proposed) [1.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted peruse [armhf] (bionic-proposed) [1.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted peruse [ppc64el] (bionic-proposed) [1.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted peruse [arm64] (bionic-proposed) [1.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted peruse [s390x] (bionic-proposed) [1.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted peruse [i386] (bionic-proposed) [1.2+dfsg-1]
<slangasek> tsimonq2: it's a private module; it shouldn't be shipped in /usr/lib/<arch>/ but in /usr/lib/<arch>/<package>
<slangasek> and the source adjusted if necessary to find it there
<tsimonq2> OK.
<tsimonq2> I'll fix that.
<tsimonq2> Thanks slangasek.
-queuebot:#ubuntu-release- New binary: mongodb [amd64] (bionic-proposed/universe) [1:3.4.7-1ubuntu3] (mozilla)
<slangasek> tsimonq2, acheronuk: qt-gstreamer is stuck in -proposed because of ktp-call-ui and telepathy-logger-qt5; ktp-call-ui has a newer upstream version in unstable, should this be synced to fix?
<slangasek> (and telepathy-logger-qt5 is Ubuntu-specific with no revdeps)
<tsimonq2> Looking.
<slangasek> (and I've already filed a bug about telepathy-logger-qt5, LP: #1747605, so will probably axe that as soon as ktp-call-ui is sorted)
<ubot5`> Launchpad bug 1747605 in telepathy-logger-qt5 (Ubuntu) "telepathy-logger-qt5: not compatible with qt-gstreamer5" [Critical,New] https://launchpad.net/bugs/1747605
<tsimonq2> slangasek: uhm, ktp-call-ui is newer in Ubuntu? :)
<tsimonq2> !info ktp-call-ui
<ubot5`> Package ktp-call-ui does not exist in bionic
<tsimonq2> er
<tsimonq2> whatever
<slangasek> tsimonq2: oh sorry, I had only queried its status from an artful machine, oops
<tsimonq2> slangasek: The RC bug open in Debian looks relevant.
<tsimonq2> I'm on mobile and can take a look later unless acheronuk wants to.
<tjaalton> could someone ack/nack bug 1755717
<ubot5`> bug 1755717 in xcb-proto (Ubuntu) "FFE: xcb-proto/libxcb 1.13" [Undecided,New] https://launchpad.net/bugs/1755717
<acheronuk> !info kde-telepathy-call-ui
<ubot5`> kde-telepathy-call-ui (source: ktp-call-ui): KDE Telepathy UI for audio/video calls. In component universe, is optional. Version 17.12.3-0ubuntu1 (bionic), package size 186 kB, installed size 876 kB
<tsimonq2> Yeah.
<acheronuk> doing now
 * LocutusOfBorg does the ldc rebuilds
-queuebot:#ubuntu-release- New binary: mongodb [arm64] (bionic-proposed/universe) [1:3.4.7-1ubuntu3] (mozilla)
<mwhudson> tyhicks: that seems to have worked
<tyhicks> mwhudson: yes, it did - thanks for the suggestion!
<tyhicks> mwhudson: I left a big fat comment in debian/control so that you'll catch the hard-coded golang version and remember the debian/rules change when you bring bionic's docker.io back to artful and xenial
<tyhicks> (xenial will be obvious because it'll FTBFS since golang-1.9 doesn't exist)
<mwhudson> tyhicks: thanks
<slangasek> tsimonq2: "the RC bug open in Debian" - which package were you referring to with that?  no open RC bugs on ktp-call-ui
<tsimonq2> slangasek: https://bugs.debian.org/886943
<ubot5`> Debian bug 886943 in libtelepathy-qt5-0 "libtelepathy-qt5-0: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE" [Serious,Fixed]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.27 => 2.408.28] (desktop-core)
<slangasek> tsimonq2: ah; relevant in the sense that it would be nice to get that fixed by migrating the package currently in -proposed...
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.28]
<tsimonq2> slangasek: Yeah.
<tsimonq2> Heh.
<nacc> slangasek: i think fusionforge in bionic-proposed needs an AA nudge; I removed those plugins becasue they depend on a no longer packaged php packages
<slangasek> nacc: ack, NBS in -proposed requires manual attention; cleaning up now
<nacc> slangasek: thanks
<tsimonq2> For general recordkeeping I guess, I'll look into sbuild a bit later, but it needs a hard dep on lintian.
<tsimonq2> nodejs is going to need some work, help would be appreciated on that.
<tsimonq2> nodejs> Not too bad, just skimming things there's *maybe* ten packages with regressed autopkgtests.
<nacc> slangasek: thank you for the assist on fusionforge
<slangasek> nacc: n/p
<slangasek> nacc: always happy to delete php packages for you, binary or otherwise ;-)
<nacc> slangasek: heh
-queuebot:#ubuntu-release- New binary: ubuntukylin-wallpapers [amd64] (bionic-proposed/universe) [18.04.0] (ubuntukylin)
<tsimonq2> Can someone let that binary through? ^^^^
<tsimonq2> That took me *three* tries to upload.
<tsimonq2> 167 MB diff...
#ubuntu-release 2018-03-21
 * RAOF grumbles at yet another autopkgtest that now fails on s390x because machine-isolation has been enabled.
<xnox> muahahahahhaha
<xnox> RAOF, stop denying the truth! you envy big iron =)
<RAOF> xnox: Look, Canonical is absolutely welcome to buy me a Talos II workstation and I will care all the things about power8.
<RAOF> xnox: But you're not going to get me excited about big iron :P
<RAOF> (Or perhaps I'd be caring about Power9, which maybe shows you how much I currently follow that :gri
<RAOF> ð¸
<infinity> RAOF: IBM keeps promising me x86-competitive build-your-own POWER options.  When that actually happens, my next home server will be P9, I imagine.
<infinity> Well, that also depends on it not requiring the rotor from an Apache helicopter to keep it cool.
<RAOF> Heh.
<RAOF> Well, the Talos II has been in âPre-orders accepted!â state forâ¦ maybe a year now?
<infinity> I have faith.
<infinity> Ish.
<RAOF> âWhen that actually happensâ is an excellent qualifier :)
<infinity> The original plan was to sell bad yield CPUs with disabled cores at cut rate prices.
<infinity> But two things happened: their yields improved, and demand for P8 was significantly higher than they expected.
<infinity> So, good news for IBM, bad news for enthusiasts.
<RAOF> Eh. I'll just end up with 16+ cores of Ryzen in my next system.
<RAOF> That'll do.
<infinity> RAOF: Oh yes, I'm quite happy with all things Ryzen.
<infinity> RAOF: But I still want POWER just cause.
<infinity> RAOF: I may be old, but there's still a giddy hobbyist nerd hiding in here somewhere.
<RAOF> Heh.
-queuebot:#ubuntu-release- New source: ukui-window-switch (bionic-proposed/primary) [1.1.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: cross-toolchain-base-ports [amd64] (bionic-proposed/universe) [19ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: plymouth (artful-proposed/main) [0.9.2-3ubuntu17 => 0.9.2-3ubuntu18] (core)
<tsimonq2> FTR: bug 1757320.
<ubot5`> bug 1757320 in youker-assistant (Ubuntu) "Remove Qt 4 from the archive" [Medium,Confirmed] https://launchpad.net/bugs/1757320
<tsimonq2> I'll allow time for the dust to settle (people who are subscribed to the packages to react to it, confirm/deny it) but I plan on sending an email to ubuntu-release this week.
-queuebot:#ubuntu-release- New sync: golang-github-coreos-bbolt (bionic-proposed/primary) [1.3.1-coreos.5-1]
-queuebot:#ubuntu-release- New: accepted cross-toolchain-base-ports [amd64] (bionic-proposed) [19ubuntu2]
-queuebot:#ubuntu-release- New: accepted deepin-terminal [sync] (bionic-proposed) [2.9.2-1]
-queuebot:#ubuntu-release- New: accepted mongodb [amd64] (bionic-proposed) [1:3.4.7-1ubuntu3]
-queuebot:#ubuntu-release- New: accepted mongodb [s390x] (bionic-proposed) [1:3.4.7-1ubuntu3]
-queuebot:#ubuntu-release- New: accepted deepin-screenshot [sync] (bionic-proposed) [4.0.11-1]
-queuebot:#ubuntu-release- New: accepted mongodb [arm64] (bionic-proposed) [1:3.4.7-1ubuntu3]
-queuebot:#ubuntu-release- New: accepted golang-github-coreos-bbolt [sync] (bionic-proposed) [1.3.1-coreos.5-1]
-queuebot:#ubuntu-release- New: accepted ubuntukylin-wallpapers [amd64] (bionic-proposed) [18.04.0]
-queuebot:#ubuntu-release- New binary: deepin-screenshot [s390x] (bionic-proposed/none) [4.0.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-coreos-bbolt [amd64] (bionic-proposed/none) [1.3.1-coreos.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-screenshot [amd64] (bionic-proposed/none) [4.0.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-screenshot [i386] (bionic-proposed/none) [4.0.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-screenshot [arm64] (bionic-proposed/none) [4.0.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-screenshot [armhf] (bionic-proposed/none) [4.0.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-terminal [ppc64el] (bionic-proposed/none) [2.9.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-terminal [amd64] (bionic-proposed/none) [2.9.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-terminal [s390x] (bionic-proposed/none) [2.9.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-terminal [i386] (bionic-proposed/none) [2.9.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-terminal [arm64] (bionic-proposed/none) [2.9.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-terminal [armhf] (bionic-proposed/none) [2.9.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted deepin-screenshot [amd64] (bionic-proposed) [4.0.11-1]
-queuebot:#ubuntu-release- New: accepted deepin-screenshot [armhf] (bionic-proposed) [4.0.11-1]
-queuebot:#ubuntu-release- New: accepted deepin-screenshot [s390x] (bionic-proposed) [4.0.11-1]
-queuebot:#ubuntu-release- New: accepted deepin-terminal [arm64] (bionic-proposed) [2.9.2-1]
-queuebot:#ubuntu-release- New: accepted deepin-terminal [i386] (bionic-proposed) [2.9.2-1]
-queuebot:#ubuntu-release- New: accepted deepin-terminal [s390x] (bionic-proposed) [2.9.2-1]
-queuebot:#ubuntu-release- New: accepted deepin-screenshot [arm64] (bionic-proposed) [4.0.11-1]
-queuebot:#ubuntu-release- New: accepted deepin-terminal [amd64] (bionic-proposed) [2.9.2-1]
-queuebot:#ubuntu-release- New: accepted deepin-terminal [ppc64el] (bionic-proposed) [2.9.2-1]
-queuebot:#ubuntu-release- New: accepted deepin-screenshot [i386] (bionic-proposed) [4.0.11-1]
-queuebot:#ubuntu-release- New: accepted golang-github-coreos-bbolt [amd64] (bionic-proposed) [1.3.1-coreos.5-1]
-queuebot:#ubuntu-release- New: accepted deepin-terminal [armhf] (bionic-proposed) [2.9.2-1]
<LocutusOfBorg> hello guys, appport regressed in release (probably this is an ifra regression, not a release one?)... can autopkgtests be ignored?
<LocutusOfBorg> apport-valgrind creates a user specified sandbox and cache ... WARNING: /lib/x86_64-linux-gnu/libc.so.6 is needed, but cannot be mapped to a package
<LocutusOfBorg> ERROR: Cannot find package which ships ExecutablePath /bin/true
<LocutusOfBorg> this is a strange error TBH
<mwhudson> LocutusOfBorg: i remember unhelpfully slangasek saying something about that but no other details
<mwhudson> oh wait no there's not been a new glibc recently :)
<LocutusOfBorg> does anybody know where I can push changes I did to src:casper package? I fail to see how https://code.launchpad.net/~ubuntu-core-dev/casper/trunk can point to the right code
<acheronuk> LocutusOfBorg: I asked in here the other day where the current VCS was, as was told the VCS 'was the archive'
<LocutusOfBorg> nice!
-queuebot:#ubuntu-release- Unapproved: dovecot (artful-proposed/main) [1:2.2.27-3ubuntu1.3 => 1:2.2.27-3ubuntu1.4] (ubuntu-server)
<sil2100> rbasak: hey! Would you mind if I take a look at the systemd SRU in xenial and artful - releasing it if it's all good?
<sil2100> rbasak: didn't want to get in the way
<rbasak> sil2100: sure, thanks
<jbicha> please remove sambamba from bionic-proposed. 0.6.7-1 fails to build on i386 and we can just rebuild 0.6.6-1 instead to finish the ldc transition
<jbicha> LocutusOfBorg: unless you were working on fixing 0.6.7?
-queuebot:#ubuntu-release- Unapproved: accepted avahi [source] (trusty-proposed) [0.6.31-4ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted avahi [source] (xenial-proposed) [0.6.32~rc+dfsg-1ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted avahi [source] (artful-proposed) [0.6.32-1ubuntu1.1]
<LocutusOfBorg> jbicha, https://github.com/biod/sambamba/issues/344
<LocutusOfBorg> BTW, I would prefer to remove it on i386, or demote to proposed for some hours
<jbicha> demote what to proposed?
<LocutusOfBorg> I already disabled the assert in my ppa and the build went successfully, but since upstream is working on it, better wait
<LocutusOfBorg> sambamba
<LocutusOfBorg> btw tilix is sad because of apport regression in release
<jbicha> we could just wait a few days on sambamba/ldc transition then since upstream might have a fix soon
<LocutusOfBorg> but since the version is regressed in release (only in i386), I could even disable the assert and upload
<LocutusOfBorg> and then sync when the new version 0.6.8 is out
<LocutusOfBorg> uploaded, i386 makes little sense nowadays
<LocutusOfBorg> and the fix will come in a matter of hours (BTW this is segfaulting since years on i386 and nobody complained lol)
-queuebot:#ubuntu-release- Unapproved: rejected pulseaudio [source] (xenial-proposed) [1:8.0-0ubuntu3.9]
-queuebot:#ubuntu-release- Unapproved: rejected libnative-platform-java [source] (artful-proposed) [0.11-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted akregator [source] (artful-proposed) [4:17.04.3-0ubuntu1.1]
<LocutusOfBorg> apw, please ignore apport autopkgtests? so we can see ldc migrate?
<juliank> Laney, slangasek python-apt based autopkgtests currently fail on armhf because it sets APT::Default-Release somewhere in apt.conf[.d]. While we should eventually fix the tests, I don't know how many are affected (only update-manager and ubuntu-release-upgrader I know about). Can we get this changed so it does not set APT::Default-Release, but pins bionic to 990 using a preferences file?
<juliank> Then we can get ubuntu-release-upgrader migrate to release pocket again :)
<slangasek> LocutusOfBorg: I don't see any way that apport's tests regressing would be an infrastructure change; please check with bdmurray
<slangasek> juliank: I don't see any references to Default-Release in our cloud setup.  Does this come from lxd defaults?
<juliank> slangasek: I have no idea, but it seems to be set only on armfh
<slangasek> juliank: armhf is the only arch where our runners are in containers
<juliank> It's certainly not in my autopkgtest-build-lxd container
<juliank> but that's all I know, the rest is a mystery to me :)
<LocutusOfBorg> slangasek, but ignoring, is it a possibility? we will see some stuff migrate, and this is a "regreesed in release" situation
<juliank> Last time tests worked fine on armhf was 2018-03-18 12:57:05 UTC
<juliank> that is about two days ago
-queuebot:#ubuntu-release- Unapproved: accepted plymouth [source] (artful-proposed) [0.9.2-3ubuntu18]
<juliank> um, 3 days ago
<juliank> (well, with the old ubuntu-release-upgrader)
<slangasek> LocutusOfBorg: true, that is my rule, if it's regressed in release it should not be allowed to block.  Can I ask you to file a bug against the apport package about it, and I'll add the hint?
<LocutusOfBorg> sure!
<Laney> When we find out why this broke, we should see if we can make proposed-migration not miss the regression next time
<slangasek> quite
<Laney> slangasek: can you see if you can make the autopkgtest@lxd unit go away on autopkgtest-cloud-worker/3 please? :(
<Laney> I'm too incompetent to know how to do that
<slangasek> looking
<Laney> it's causing an error message to be mailed to me by the maintenance job
<slangasek> haha
<slangasek> if only other people could receive these mails
<Laney> that
<LocutusOfBorg> interesting, I'm finding the regression in some glibc stuff
<LocutusOfBorg> will update the bug
<slangasek> Laney: it only went away when I ran sudo rm /etc/systemd/system/autopkgtest-lxd-socat@.service && sudo systemctl daemon-reload (and maybe the first part of that command was not relevant)
<LocutusOfBorg> ok I'm pretty sure lxc regressed it
<slangasek> Laney: but also that leaves autopkgtest-lxd-socat@lxd-armhf-10.44.41.136.service behind as 'not-found' and I don't know why :P
<LocutusOfBorg> slangasek, https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1757470
<ubot5`> Ubuntu bug 1757470 in lxc (Ubuntu) "apport autopkgtests broken (valgrind error) LXC regression?" [Undecided,New]
<Laney> slangasek: autopkgtest-cloud/tools/cleanup-lxd produces empty output now, so I'm happy, thanks
<slangasek> ok
<slangasek> Laney: I'm unhappy that I still have a dangling unit, but if the scripts are clean, I won't fret overmuch ;)
<LocutusOfBorg> lxc migrated the exact day the test started failing, other differences are gcc-8 minor update and something similar, but lxc seems my best bet
<LocutusOfBorg> lets see the stuff migrate <3
<slangasek> LocutusOfBorg: lxc in bionic?  that isn't used on the infrastructure
<LocutusOfBorg> slangasek, I did a diff on artifacts.tar.gz
<LocutusOfBorg> why is it shown there then?
<slangasek> LocutusOfBorg: it's part of the base image. But the lxc version *in* the runner image is not part of the "infrastructure" of the runners, and I don't see anything in the apport package that implies it uses lxc
<LocutusOfBorg> oh got it
<LocutusOfBorg> sooooo, other differences are really not helping
<slangasek> sure, but please reassign the bug to the apport package
<slangasek> because that's where "ownership" of the issue needs to lie
<LocutusOfBorg> sure
<LocutusOfBorg> I see some seeds changed, can them be a problem? e.g. ubuntu-minimal and some ubuntu-* packages
<LocutusOfBorg> maybe they were indirectly needed
<LocutusOfBorg> is looking at both testbed-packages the right thing to do?
<LocutusOfBorg> or upstream-system-packages is the best place?
<slangasek> could be any of the above
<LocutusOfBorg> I'll let somebody else understand the problem, I'm really not much involved in such package
<slangasek> I'm working through the ruby re-promotions
<slangasek> (so hopefully nobody collides with me and causes package deletions :P)
-queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.18]
<nacc> slangasek: thank you (re: ruby)
<slangasek> nacc: promotions done
<nacc> slangasek: great; dpb1 --^
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.18]
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.18 => 2.02~beta2-36ubuntu3.18] (core)
-queuebot:#ubuntu-release- New binary: libgepub [ppc64el] (bionic-proposed/universe) [0.6.0-1] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: retro-gtk [i386] (bionic-proposed/universe) [0.14.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: retro-gtk [s390x] (bionic-proposed/universe) [0.14.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgepub [s390x] (bionic-proposed/universe) [0.6.0-1] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: retro-gtk [ppc64el] (bionic-proposed/universe) [0.14.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-terminal [ppc64el] (bionic-proposed/main) [3.28.0-1ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: gnome-terminal [s390x] (bionic-proposed/main) [3.28.0-1ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: libgepub [amd64] (bionic-proposed/universe) [0.6.0-1] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: retro-gtk [amd64] (bionic-proposed/universe) [0.14.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-terminal [amd64] (bionic-proposed/main) [3.28.0-1ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: retro-gtk [arm64] (bionic-proposed/universe) [0.14.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgepub [arm64] (bionic-proposed/universe) [0.6.0-1] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: libgepub [i386] (bionic-proposed/universe) [0.6.0-1] (ubuntugnome)
-queuebot:#ubuntu-release- New binary: gnome-terminal [armhf] (bionic-proposed/main) [3.28.0-1ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: gnome-terminal [arm64] (bionic-proposed/main) [3.28.0-1ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: retro-gtk [armhf] (bionic-proposed/universe) [0.14.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-terminal [i386] (bionic-proposed/main) [3.28.0-1ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: libgepub [armhf] (bionic-proposed/universe) [0.6.0-1] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: hdparm (artful-proposed/main) [9.51+ds-1 => 9.51+ds-1ubuntu0.1] (core)
-queuebot:#ubuntu-release- Unapproved: hdparm (xenial-proposed/main) [9.48+ds-1 => 9.48+ds-1ubuntu0.1] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.18 => 2.02~beta2-36ubuntu3.18] (core)
<coreycb> hello, can an archive admin please remove heat-api-cloudwatch binary package as well as the source package python-django-openstack-auth  and its corresponding binaries? note that horizon now provides the python-django-openstack-auth binary.
<slangasek> coreycb: heat-api-cloudwatch will get reaped after the new version of heat currently in -proposed migrates, and not before; you appear to have some autopkgtest regressions that you need to sort out http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#heat
<coreycb> slangasek: i have a new upload that sorts them out. forgot to drop heat-api-cloudwatch tests on the prior upload.
<slangasek> coreycb: python-django-openstack-auth , I would like a bug report filed against the package please (and please ping with the bug # when you have it)
<coreycb> slangasek: got it :) https://bugs.launchpad.net/ubuntu/+source/python-django-openstack-auth/+bug/1757141
<ubot5> Ubuntu bug 1757141 in python-django-openstack-auth (Ubuntu) "[RM] Package needs to be removed in Bionic" [Undecided,New]
<slangasek> ok :)
<coreycb> slangasek: thanks
<slangasek> that one is actually tricky because removing python-django-openstack-auth from bionic will immediately make horizon uninstallable
<slangasek> I think I'll force horizon first
<Trevinho> sil2100: hey, when you've a sec can you please check this SRU https://bileto.ubuntu.com/#/ticket/3190 ?
<coreycb> slangasek: we want to keep the horizon binary. i'm probably missing something with how you do it on your end.
<ahasenack> hi, sssd has a component mismatch (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sssd), the MIR was approved: https://bugs.launchpad.net/ubuntu/+source/http-parser/+bug/1638957
<ubot5> Ubuntu bug 1638957 in http-parser (Ubuntu) "[MIR] http-parser, dependency of sssd" [High,Fix committed]
<slangasek> coreycb: so, if I act on the removal request for python-django-openstack-auth, python-django-horizon immediately becomes uninstallable in bionic release, and then *hopefully*, becomes installable again with the next proposed-migration run.  Instead, I'm using a hint to force horizon to migrate, which will make only python-openstack-auth uninstallable, which we don't care about; and then I'll
<ahasenack> could someone please take a look at that?
<slangasek> remove python-django-openstack-auth when the dust settles
<slangasek> coreycb: more explanation than you care about, but hopefully satisfies you that I'm not accidentally nuking any horizon binaries
<slangasek> ahasenack: doing
<slangasek> ahasenack: done
<ahasenack> thanks a lot
<coreycb> slangasek: alright, thanks for the explanation!
<sil2100> Trevinho: hey! I'll check it tomorrow for sure, since that's the usual day when I do SRU work
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (xenial-proposed) [2.02~beta2-36ubuntu3.18]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (xenial-proposed) [2.02~beta2-36ubuntu3.18]
-queuebot:#ubuntu-release- New binary: gcc-7-cross-ports [i386] (bionic-proposed/universe) [14ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gcc-7-cross-ports [amd64] (bionic-proposed/universe) [14ubuntu1] (ubuntu-desktop)
<sergiusens> slangasek: any idea about this "E:The value 'bionic' is invalid for APT::Default-Release as such a release is not available in the sources". Getting it on and autopkgtest for armhf on bionic raised by apt_pkg on https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/armhf/s/snapcraft/20180321_183314_f654f@/log.gz
<sergiusens> also, really glad to see that the timeouts seem to be resolved!
<sergiusens> the same thing, tested from an upstream PR (base of the debsource) worked fine https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic-snappy-dev-snapcraft-daily/bionic/armhf/s/snapcraft/20180321_171551_4b0bb@/log.gz
<slangasek> sergiusens: this sounds like the same issue juliank raised earlier; but I don't know where that Default-Release setting comes from
-queuebot:#ubuntu-release- Unapproved: lshw (artful-proposed/main) [02.18-0.1ubuntu4 => 02.18-0.1ubuntu4.1] (core)
-queuebot:#ubuntu-release- Unapproved: lshw (xenial-proposed/main) [02.17-1.1ubuntu3.4 => 02.17-1.1ubuntu3.5] (core)
<juliank> slangasek: can you do the magic to enter the autopkgtest after a test failure?
<slangasek> juliank: yeah, just have to swap in the context.  Do you have a quick-to-fail one that you want me to try?
<juliank> slangasek: update-manager is about ~7min
<sergiusens> slangasek: this is not consistent as almost all our tests instrument this logic so more should have failed
<slangasek> # cat /etc/apt/apt.conf.d/autopkgtest-default-release
<slangasek> APT::Default-Release "bionic";
<slangasek> seems to be present since July 2017 in upstream autopkgtest git, so must be a side effect of a config change
-queuebot:#ubuntu-release- New: accepted gnome-terminal [amd64] (bionic-proposed) [3.28.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-terminal [armhf] (bionic-proposed) [3.28.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-terminal [ppc64el] (bionic-proposed) [3.28.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-terminal [arm64] (bionic-proposed) [3.28.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-terminal [i386] (bionic-proposed) [3.28.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnome-terminal [s390x] (bionic-proposed) [3.28.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgepub [arm64] (bionic-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted libgepub [i386] (bionic-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted libgepub [s390x] (bionic-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted libgepub [amd64] (bionic-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted libgepub [ppc64el] (bionic-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted libgepub [armhf] (bionic-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted retro-gtk [amd64] (bionic-proposed) [0.14.0-1]
-queuebot:#ubuntu-release- New: accepted retro-gtk [armhf] (bionic-proposed) [0.14.0-1]
-queuebot:#ubuntu-release- New: accepted retro-gtk [ppc64el] (bionic-proposed) [0.14.0-1]
-queuebot:#ubuntu-release- New: accepted retro-gtk [arm64] (bionic-proposed) [0.14.0-1]
-queuebot:#ubuntu-release- New: accepted retro-gtk [s390x] (bionic-proposed) [0.14.0-1]
-queuebot:#ubuntu-release- New: accepted retro-gtk [i386] (bionic-proposed) [0.14.0-1]
<slangasek> juliank: ok - this is an old commit but only recently merged upstream, and not merged into the tree on the kvm master.
<slangasek> juliank: so it came in as part of the redeploy of the lxd infra.  I'll sort out a revert
<slangasek> Laney: ^^ we are currently pointing directly at the autoimported upstream autopkgtest repo, which has now broken us.  I'm going to work through pointing instead at https://code.launchpad.net/~ubuntu-release/autopkgtest/+git/development
<sergiusens> slangasek: so do I also wait for your signal to retrigger?
<slangasek> sergiusens: or you can tell me what to retrigger once fixed
<sergiusens> slangasek: 2.40+18.04 	snapcraft/2.40+18.04
<sergiusens> http://autopkgtest.ubuntu.com/packages/s/snapcraft/bionic/armhf
#ubuntu-release 2018-03-22
<slangasek> sergiusens: retriggered and running; update-manager test has already passed, so that's a positive sign
<slangasek> u-r-u also passed
-queuebot:#ubuntu-release- New: accepted gcc-7-cross-ports [amd64] (bionic-proposed) [14ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-7-cross-ports [i386] (bionic-proposed) [14ubuntu1]
<slangasek> sergiusens: well, snapcraft 2.40+18.04 passed on armhf, but apparently not before being superseded by 2.40+18.04.1 in the archive?
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (xenial-proposed) [1.66.18]
<tsimonq2> slangasek: Can I please get your opinion on bug 1757350 when you're around?
<ubot5> bug 1757350 in etcd (Ubuntu) "Sync etcd 3.2.17+dfsg-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1757350
<slangasek> tsimonq2: bug claims a docker.io ftbfs as part of the rationale but docker.io was updated in bionic yesterday
<slangasek> someone might want to actually validate that the versions of the revdeps currently in Ubuntu build with the new etcd before syncing it
<tsimonq2> slangasek: Right, thanks; what about from a Release Team perspective (once things are sorted) irt needing an FFe?
<slangasek> tsimonq2: if you think it needs an FFe, make it an FFe request and we'll process it; otherwise, I don't have time just at the moment to read deeply enough to know if I think it needs an FFe
<tsimonq2> slangasek: ack
<tsimonq2> $ syncpackage --force -s unit193 xca
<tsimonq2> syncpackage: Source xca -> bionic/Proposed: current version 1.4.1-0ubuntu1, new version 1.4.1-1
<tsimonq2> syncpackage: Error: The checksums of the Debian and Ubuntu packages mismatch. A fake sync using --fakesync is required.
<tsimonq2> That's a new one.
<slangasek> a good reason not to create your own upstream tarballs without coordinating with Debian
 * tsimonq2 nods
<tsimonq2> So then what does "fakesync1" mean wrt the autosyncer?
<tsimonq2> Is it treated the same as "build1"?
<slangasek> I don't know offhand, I'd have to look at the code
<tsimonq2> OK
<slangasek> but it doesn't really matter given that every autosync of this package will fail until there's a new upstream version
<tsimonq2> :(
<tsimonq2> Ukikie: ^
<Ukikie> While it is my fault, I don't think I can be blamed too heavily for using the watchfile, which still matches.
<slangasek> heh, indeed
<slangasek> that counts as "coordinating with Debian", and who knows why Debian didn't coordinate with their own watchfile
<Ukikie> That is, pulled from Ubuntu, uscan --download-current-version and rechecked the sum, still matches.  I'm now wondering where Debian's is from..
<Ukikie> (And lastly, sha256 matches that of http://xca.hohnstaedt.de/xca/index.php/download \o/)
<Ukikie> It doesn't even match the tag?  Whaa..?  Sorry, I'll go contemplate elsewhere.
<Ukikie> Anyway, sorry about the mixup.
<tsimonq2> slangasek: Could you please thwack the plasma-widget-* packages assigned to ~ubuntu-archive? https://bugs.launchpad.net/~ubuntu-archive/+assignedbugs
<tsimonq2> Also, it'd be cool if I could get a c-cycle milestone to throw things at.
<slangasek> tsimonq2: the ones you've assigned are Ubuntu-only packages?
<tsimonq2> slangasek: Yes.
<tsimonq2> slangasek: Thanks.
<Laney> slangasek: ok, thanks
<Laney> I don't think I'll be very happy if we end up diverging :(
-queuebot:#ubuntu-release- Unapproved: rejected google-cloud-sdk [sync] (artful-release) [176.0.0-0ubuntu1]
<elbrus> Laney: slangasek: juliank: regarding debian bug 893754
<ubot5> Debian bug 893754 in autopkgtest "autopkgtest 5.1 "autopkgtest-default-release" breaks tests that exercise apt" [Normal,Open] http://bugs.debian.org/893754
<cjwatson> tsimonq2: auto-sync treats "ubuntu" substrings in versions specially (inhibiting syncing), but it doesn't care about any other version text.
<tsimonq2> cjwatson: ack
<juliank> elbrus: I just sent an email
<elbrus> juliank: reading
<elbrus> juliank: but it is python-apt specific?
<elbrus> as apt just works int that environment
<juliank> apt -o Dir should fail
<juliank> In general, it's all very fragile
<elbrus> what exactly is fragile?
<juliank> What happens is that if you change the root directory in apt by setting Dir, you still have the host's config files read, because you're setting Dir after they are read.
<juliank> Now apt tries to find the release you specified in the host apt.conf(.d), but cannot find it inside Dir's sources.list and errors out
<elbrus> my problem, why I went for APT::Default-Release is that it is agnostic for the delta between suite and codename
<elbrus> I don't want to detect if /etc/apt/sources.list is mentioning a suite or codename, and convert if required (as that means knowing all codenames)
<elbrus> therefor, the old method of using "release -a=" doesn't work anymore
<juliank> elbrus: It's the same as using "release bionic"
<juliank> without a= or n=
<elbrus> juliank: so I don't need the a= or n=?
<juliank> Right
<juliank> If you just write "release foo", it checks codename, suite, version. That's precisely what APT::Default-Release generates
 * juliank just learned that
<elbrus> so wouldn't python-apt still error out?
<juliank> No
<elbrus> what's the diff?
<juliank> The check for APT::Default-Release validity happens before it creates the pin
<juliank> #
<juliank> pins are not checked
<elbrus> great
<Laney> hey elbrus and juliank
<elbrus> juliank: can you update the documentation of apt_preferences when you touch it again?
<Laney> thanks for being responsive â¥
<elbrus> np (although I will be gone for a week after today)
<elbrus> hmm, I see an example without the a/n
<juliank> yeah, the manpage does not really document it well, but uses it
 * juliank writes a bug
 * elbrus wished he knew this a year ago
<elbrus> much headaches whould have been avoided
<juliank> elbrus: I only learned about that today as well :)
<elbrus> well, if you didn't know... ;)
<juliank> elbrus: though it's been that way since $forever
<elbrus> ack
<juliank> b2e465d6d3 (Arch Librarian      2004-09-20 16:56:32 +0000  59)       CreatePin(pkgVersionMatch::Release,"",DefRel,990);
<juliank> I mean, that was before bzr
<juliank> Author: jgg, Date: 2001-02-20 07:03:16 GMT, "Join with aliencode"
<Laney> apt's code always makes my head hurt a bit
 * elbrus never looked at it
<juliank> Laney: just dont read it
<Laney> juliank: write only coding
<Laney> :P
<elbrus> anyways, this probably means I'll have to remove an option from autopkgtest (and ci.debian.net / debci needs adaptation as well if so)
<elbrus> pain.
<Laney> it's just a different style to what I'm used to, doesn't lend itself to being read in my brain
<Laney> why does it?
<Laney> don't you replace the default-release with the pin and done?
<elbrus> it's an option now
<elbrus> to set the default-release
<juliank> well, and instead of writing that, write a pin file for the option?
<Laney> right
<elbrus> and ci.d.n uses it
<elbrus> see e.g. the top of https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-rqrcode-rails3/30123/log.gz
<elbrus> hmm, no it doesn't
<elbrus> nevermind
<elbrus> juliank: I guess I could do that
<elbrus> but question, if pinning doesn't need validation, why does APT::Default-Release?
<juliank> Because more people used that then people used pins?
<juliank> I don't know
<juliank> there is not always a reason for why things are the way they are
<elbrus> typically: history
<juliank> http://bugs.debian.org/407511
<ubot5> Debian bug 407511 in apt "apt: Wrong value for APT::Default-Release may cause unwanted " [Wishlist,Fixed]
<juliank> that was the discussion
<elbrus> I see
<elbrus> by the way, I'll copy this discussion to the bug (unless somebody objects)
<juliank> fine with me
<Laney> elbrus: something like https://paste.debian.net/1015983/ - untested, because I can't run the chroot tests for some reason
<Laney> feel free to start with that if you want to change it
<Laney> np on copying to the bug from me too
<Laney> +        with open(os.path.join(apt_dir, 'preferences.d', 'autopkgtest-fluffy-proposed')) as f: <- wrong filename
<elbrus> Laney: thanks, shorter than I feared
<elbrus> Laney: what is the error you get with the chroot? mounting error?
 * elbrus couldn't run the tests the other day either
<Laney> FileNotFoundError: [Errno 2] No such file or directory: 'chroot': 'chroot'
<elbrus> subprocess.CalledProcessError: Command '['mount', '-o', 'bind', '/dev', '/tmp/autopkgtest.test.ovy_j2uz/chroot/dev']' returned non-zero exit status 32.
<elbrus> hmm, different
<Laney> back shortly, doctors appointment
<elbrus> dear release managers; while I am here, another question
<elbrus> I am integrating autopkgtest policy in Debian's britney
<elbrus> Ubuntu has diverged a bit
<elbrus> are you interested in me keeping the support (well 95% or more) for Ubuntu in
<elbrus> or will you not merge again anyways?
<elbrus> there is a lot in there that is not needed for Debian
<elbrus> because in Debian, britney2 doesn't need to download anything
-queuebot:#ubuntu-release- New binary: python-daphne [amd64] (bionic-proposed/universe) [1.4.2-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted protobuf [source] (xenial-proposed) [2.6.1-1.3ubuntu1]
-queuebot:#ubuntu-release- New binary: protobuf [s390x] (xenial-proposed/main) [2.6.1-1.3ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: protobuf [ppc64el] (xenial-proposed/main) [2.6.1-1.3ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: protobuf [amd64] (xenial-proposed/main) [2.6.1-1.3ubuntu1] (kubuntu, ubuntu-desktop)
<sergiusens> sil2100: hello there! When you have time, mind letting LP: #1753482 into xenial-updates?
<ubot5> Launchpad bug 1753482 in patchelf (Ubuntu) "Please update to the newer version of patchelf in bionic" [Undecided,New] https://launchpad.net/bugs/1753482
<apw> elbrus, i personally would hope we would continue to merge, but i guess Laney is more likely to know for sure
<Laney> ah sorry
<Laney> I think the policies and infrastructure around autopkgtest are likely to stay a bit different
<apw> right, but pesumably where we can we would want to base on the debian base i assume
<Laney> last I heard Debian wanted to have it file rc bugs, and I'm not sure that amqp is used for the queues there - rather ci.d.n scans the archive or something
<Laney> sure
<sil2100> sergiusens: hey! Sure, it wasn't verified in the morning, good to see it done now
<sil2100> bdmurray: ^
<sil2100> sergiusens: released o/
<sergiusens> thanks! sil2100 I wanted to document it correctly before doing so :-)
-queuebot:#ubuntu-release- New binary: protobuf [arm64] (xenial-proposed/main) [2.6.1-1.3ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: aodh (artful-proposed/main) [5.0.0-0ubuntu2 => 5.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ceilometer (artful-proposed/main) [1:9.0.4-0ubuntu1 => 1:9.0.5-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cinder (artful-proposed/main) [2:11.0.2-0ubuntu1 => 2:11.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: designate (artful-proposed/main) [1:5.0.0-0ubuntu1 => 1:5.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: glance (artful-proposed/main) [2:15.0.0-0ubuntu1 => 2:15.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: gnocchi (artful-proposed/universe) [3.1.9-0ubuntu1 => 3.1.15-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: heat (artful-proposed/main) [1:9.0.2-0ubuntu1 => 1:9.0.3-0ubuntu1] (openstack, ubuntu-server)
<elbrus> Laney: no britney uses amqp (to file)
<elbrus> and ci.d.n just runs the tests requested by britney
<Laney> what's the difference then?
<elbrus> britney2 doesn't do any internet access
<elbrus> so doesn't contact swift (which we don't have)
<elbrus> instead it output the amqp to file and that file is uploaded to ci.d.n
<elbrus> then the results of ci.d.n are pulled in
<elbrus> in the initialization phase of britney run
<elbrus> and continue from there
<elbrus> I added a penalty/bounty system instead of gating (but gating is still my long term plan for Debian)
<elbrus> so that is still there, it's all optional
<elbrus> so with my current integration work nearly everything for Ubuntu is still in (at least, until commit 593acb2753)
<elbrus> I removed one or two items as it was not worth the effort to implement a proper option, but if Ubuntu is interested in merging again, we'll have to find a way
<elbrus> on top of my head, the retry URL is gone
<elbrus> the rest *should* still work
<elbrus> Paul Gevers master 7130136 autopkgtest lib/adt_testbed.py lib/autopkgtest_args.py tests/autopkgtest * Use apt pinning instead of APT::Default-Release * https://deb.li/3c7JG
<elbrus> I verified ^^ a bit, would be cool if somebody else could give it a spin
<elbrus> on britney, regarding the RC bug filing thing, that is just an intermediate solution for real regressions being caught by autopkgtesting (and requires manual work by somebody (= me for the time being)
<elbrus> my expectation is that if all works well, gating will follow soon, but that is not up to me
<elbrus> I believe the RT wants to get people off their fears first
-queuebot:#ubuntu-release- Unapproved: neutron (artful-proposed/main) [2:11.0.2-0ubuntu1.3 => 2:11.0.3-0ubuntu1] (openstack, ubuntu-server)
<elbrus> and Laney thanks for the patch, it seems to work
-queuebot:#ubuntu-release- Unapproved: accepted pymacaroons [source] (xenial-proposed) [0.12.0-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted dovecot [source] (artful-proposed) [1:2.2.27-3ubuntu1.4]
<Laney> elbrus: thanks for committing
<Laney> I'll try to make some time to look at your stuff at some point
-queuebot:#ubuntu-release- Unapproved: mistral (artful-proposed/universe) [5.0.0-0ubuntu1 => 5.2.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: icu [s390x] (bionic-proposed/main) [60.2-3ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: icu [ppc64el] (bionic-proposed/main) [60.2-3ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: icu [amd64] (bionic-proposed/main) [60.2-3ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: icu [i386] (bionic-proposed/main) [60.2-3ubuntu2] (core)
<sil2100> bdmurray: oh, as for SRU work: I didn't publish virtualbox into -updates today in the morning since the uploader was requesting a longer testing period
<sil2100> bdmurray: but I leave it up to you if you want to release it yourself or not
<sil2100> bdmurray: if anything I can always publish it Monday morning
-queuebot:#ubuntu-release- New binary: icu [armhf] (bionic-proposed/main) [60.2-3ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted apache2 [source] (xenial-proposed) [2.4.18-2ubuntu3.6]
<bdmurray> sil2100: I'd defer to the uploader
-queuebot:#ubuntu-release- New binary: icu [arm64] (bionic-proposed/main) [60.2-3ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: open-vm-tools (xenial-proposed/main) [2:10.0.7-3227872-5ubuntu1~16.04.2 => 2:10.2.0-3ubuntu0.16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<slangasek> elbrus: thanks for the quick fix for the Default-Release issue!  wrt britney, yes, we do prefer to be able to continue merging from Debian; certainly for autopkgtest gating it would be good to have the implementations track each other, even if there might be different options in use between the releases at any given time, because it's a pretty hairy policy which would benefit from us sharing
<slangasek> eyeballs
<slangasek> elbrus: gating directly on autopkgtest would really be a good idea, and https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=ubuntu-devel@lists.ubuntu.com;tag=autopkgtest has some more examples now of bugs of varying severities that were caught in Ubuntu but not in Debian testing
<slangasek> (I particularly like "your package broke ABI without soname; your revdeps autopkgtests noticed; the package got promoted to testing anyway")
-queuebot:#ubuntu-release- New: accepted python-daphne [amd64] (bionic-proposed) [1.4.2-1]
<elbrus> slangasek: ack on gating being the prefered solution
<elbrus> and great that you like to want to merge in principle
<elbrus> gives me more insentive to try and keep the code compatible with Ubuntu's implementation
<elbrus> I would recommend upstreaming more bugfixes though... (and the Debian RT team in getting better at merging them)
<elbrus> There are one or two commits in your repo that apply to Debian as well I think
<slangasek> quite possibly :/
<slangasek> infinity: how does one debug why http://people.canonical.com/~ubuntu-archive/priority-mismatches.html wants to pull in wrong things?  there's no detail like on component-mismatches saying why it's being promoted, and I'm having a hard time finding what thinks it should depend on build-essential. :P
<cjwatson> snakefruit:/home/ubuntu-archive/mirror/ubuntu-germinate/minimal_ubuntu_bionic_amd64 is the easiest place to look
<cjwatson> python3 Depends: dh-python Depends: dpkg-dev Recommends: build-essential, apparently
<slangasek> cjwatson: thanks
<cjwatson> So the proximate change is dh-python having started to depend on dpkg-dev recently, but python3's dep on dh-python is much longer-standing
<cjwatson> Is this essentially dh-python being unable to decide whether it's a runtime thing or a development thing?
<slangasek> possibly
<cjwatson> Or maybe python3's dep on dh-python is transitional
<cjwatson> Yeah, from 2013 when pybuild and dh_python3 were split out
<xnox> it should be dropped
<cjwatson> Arguably the right thing to do is to drop that dep now, but I bet it would still break a bunch of random builds
<slangasek> hmm, well, I'm not sure that transition has finished or if dropping it now will cause an increase in build failures - yeah
<slangasek> doko: ^^ opinions on the above?
<xnox> there is lintian tag for it
<cjwatson> Now if only we had a lintian runner for Ubuntu
<slangasek> xnox: do you know the tag name? (maybe in the form of a link to the lintian lab)
<xnox> https://lintian.debian.org/tags/python3-depends-but-no-python3-helper.html
<cjwatson> Also this is https://bugs.debian.org/893477
<ubot5> Debian bug 893477 in python3 "dh-python: New depencency (dpkg-dev) forces the installation of unwanted packages" [Important,Open]
<xnox> just 3 things....
<xnox> no wrong
<cjwatson> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718819 has a comment claiming 250 affected source packages
<ubot5> Debian bug 718819 in python3 "python3 has circular Depends on dh-python" [Important,Open]
<slangasek> xnox: hmm, the long description talks about debian/rules calling helpers, which is different than whether things directly build-depend on dh-python
<slangasek> well also
<slangasek> doko: why did dh-python need synced post-FF?
<cjwatson> It might be most expedient to just drop dh-python -> dpkg-dev to Suggests for bionic; not sure
<slangasek> I actually can't find anything in the debdiff that uses dpkg-dev
<slangasek> I'm just going to drop that relationship for now
<cjwatson> dpkg-architecture, apparently
<cjwatson> hm, but not in the debdiff, indeed
<slangasek> cjwatson: I didn't find dpkg-architecture in the debdiff LP gave me; was I looking wrong?
<slangasek> right
<cjwatson> yeah, it seems to just fetch it from the environment, but Helmut seems to claim in #892931 that it's required
<cjwatson> maybe he's just confused?
<LocutusOfBorg> bdmurray, sil2100 you can release if you want, I had an issue, but was related to an unrelated bug affecting some NVIDIA folks, and there is already a patch inside vbox
 * cjwatson follows up to that bug
<LocutusOfBorg> this is the bug I am referring to https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1751191
<ubot5> Ubuntu bug 1751191 in virtualbox (Ubuntu) "Using Vbox with 3D enabled, creates strange stuttering" [High,Confirmed]
<LocutusOfBorg> and old bug, that affects every vbox version, so not really a regression
<LocutusOfBorg> slangasek, https://autopkgtest.ubuntu.com/packages/apport/bionic/i386 it is safe again, please drop the hint :)
<slangasek> LocutusOfBorg: ok.  do you know what fixed it?
<LocutusOfBorg> nope sorry
<LocutusOfBorg> somebody on the bug pointed that they were fine
<LocutusOfBorg> let me debug it a little bit
<slangasek> k
<slangasek> tsimonq2: LP: #1757657 - being the Debian maintainer does not necessarily mean I assume responsibility for fixing bugs in the package in Ubuntu ;)
<ubot5> Launchpad bug 1757657 in heimdall-flash (Ubuntu) "Please port your package away from Qt 4" [Medium,Confirmed] https://launchpad.net/bugs/1757657
<LocutusOfBorg> btw please accept virtualbox-hwe in bionic
<LocutusOfBorg> it is providing an upgrade path for -hwe packages in xenial
<LocutusOfBorg> just glib2.0 has been updated in  the meanwhile and an unrelated library
<LocutusOfBorg> I still blame the img files, changed from adt-bionic-i386-apport-20180321-094604 to adt-bionic-i386-apport-20180321-235603
<LocutusOfBorg> maybe something on the "host" changed in the meanwhile?
<slangasek> not likely
<slangasek> if something changed in the image to fix it, that might be a smaller bisect of the packages
<slangasek> LocutusOfBorg: there seem to be a number of copies of virtualbox-hwe in source new; I assume you want them all rejected except the last
<slangasek> LocutusOfBorg: and why does this need to be a separate source package, vs. metapackages built from the main source package?
-queuebot:#ubuntu-release- New: rejected virtualbox-hwe [source] (bionic-proposed) [5.2.8-dfsg-5ubuntu18.04.1]
-queuebot:#ubuntu-release- New: rejected virtualbox-hwe [source] (bionic-proposed) [5.2.8-dfsg-5ubuntu18.04.1]
-queuebot:#ubuntu-release- New: rejected virtualbox-hwe [source] (bionic-proposed) [5.2.8-dfsg-5ubuntu18.04.1]
-queuebot:#ubuntu-release- New: rejected virtualbox-hwe [source] (bionic-proposed) [5.2.8-dfsg-5ubuntu18.04.1]
<LocutusOfBorg> sure, I need only the latest
<LocutusOfBorg> well, I will need a real vbox-hwe package as soon as bionic+1 is out
<LocutusOfBorg> right now the packaging is the same, except for the renamed binaries, and in the future, build-deps will point to hwe stuff
<slangasek> ok
<LocutusOfBorg> why should I diverge the main virtualbox packaging from debian, specially because I will need such separate one anyway?
<LocutusOfBorg> and yes, I just need the latest :)
<slangasek> so since there are no metapackages today for virtualbox in xenial, introducing them in the short term only to have them switch away from metapackages via SRU is not sensible
<slangasek> ack
<LocutusOfBorg> I have metapackages, probably
<LocutusOfBorg> I have that break/replace/provides triplet
-queuebot:#ubuntu-release- New binary: python-django-channels [amd64] (bionic-proposed/universe) [1.1.8.1-1] (no packageset)
<LocutusOfBorg> and now I have the same for bionic
<LocutusOfBorg> but I don't want people to switch from vbox-hwe to vbox and then to vbox-hwe again
<LocutusOfBorg> this seems to complicate my SRU for security and bugfixes (kernel upgrades and similar)
-queuebot:#ubuntu-release- New: accepted python-django-channels [amd64] (bionic-proposed) [1.1.8.1-1]
<LocutusOfBorg> and moreover, most of my work is based on the assumption that I have the same packaging across releases for both debian and ubuntu, I don't want to change that
<LocutusOfBorg> (whenever possible)
-queuebot:#ubuntu-release- Unapproved: lttng-modules (artful-proposed/universe) [2.9.0-1ubuntu3.1 => 2.9.0-1ubuntu3.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lttng-modules (xenial-proposed/universe) [2.8.0-1ubuntu1~16.04.4 => 2.8.0-1ubuntu1~16.04.5] (no packageset)
<slangasek> xnox: were there no existing consumers of libiculx.so.60 that the new libicu60 needs to declare Breaks: against?
<tsimonq2> slangasek: 1757657> But you'll address it in Debian I hope? :)
<tsimonq2> I mean, I can NMU, but you know the package better than I...
-queuebot:#ubuntu-release- Unapproved: nova (artful-proposed/main) [2:16.0.4-0ubuntu1 => 2:16.1.0-0ubuntu1] (openstack, ubuntu-server)
<slangasek> tsimonq2: I plan to eventually address it in Debian, yes; though I also no longer have the hardware to test this with
-queuebot:#ubuntu-release- Unapproved: accepted lshw [source] (artful-proposed) [02.18-0.1ubuntu4.1]
-queuebot:#ubuntu-release- Unapproved: accepted lshw [source] (xenial-proposed) [02.17-1.1ubuntu3.5]
-queuebot:#ubuntu-release- Unapproved: accepted hdparm [source] (artful-proposed) [9.51+ds-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted hdparm [source] (xenial-proposed) [9.48+ds-1ubuntu0.1]
<elbrus> Laney: what is the file size of state/results.cache in Ubuntu? (or bionic if the result is release specific)
<elbrus> do you ever rinse it from old results?
<xnox> slangasek, yes, there was.
-queuebot:#ubuntu-release- Unapproved: accepted aodh [source] (artful-proposed) [5.1.0-0ubuntu1]
<xnox> slangasek, and i did declare the one...
<slangasek> xnox: I don't see any new Breaks: in the libicu60 package in NEW
<slangasek> s/new//
 * xnox checks again
<xnox> slangasek, bah, so the one needed was "openttd (<= 1.7.1-1)" and I added it, in the wrong package.... i aded it on the libiculx60
<xnox> *sigh*
-queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (artful-proposed) [1:9.0.5-0ubuntu1]
<slangasek> xnox: ok. are you fixing now-ish, such that I can reject the current binaries and accept the next batch soon?
<slangasek> xnox: (or I could do the upload if you're not at keyboard)
<xnox> slangasek, i'll upload now
<slangasek> ok
-queuebot:#ubuntu-release- New: rejected icu [amd64] (bionic-proposed) [60.2-3ubuntu2]
-queuebot:#ubuntu-release- New: rejected icu [armhf] (bionic-proposed) [60.2-3ubuntu2]
-queuebot:#ubuntu-release- New: rejected icu [ppc64el] (bionic-proposed) [60.2-3ubuntu2]
-queuebot:#ubuntu-release- New: rejected icu [arm64] (bionic-proposed) [60.2-3ubuntu2]
-queuebot:#ubuntu-release- New: rejected icu [s390x] (bionic-proposed) [60.2-3ubuntu2]
-queuebot:#ubuntu-release- New: rejected icu [i386] (bionic-proposed) [60.2-3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (artful-proposed) [2:11.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted designate [source] (artful-proposed) [1:5.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted glance [source] (artful-proposed) [2:15.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted heat [source] (artful-proposed) [1:9.0.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (artful-proposed) [2:11.0.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: icu [s390x] (bionic-proposed/main) [60.2-3ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: accepted mistral [source] (artful-proposed) [5.2.2-0ubuntu1]
<bdmurray> coreycb: the gnocchi upload has a lot of removals to AUTHORS and Changelog - is that deliberate?
-queuebot:#ubuntu-release- New binary: icu [ppc64el] (bionic-proposed/main) [60.2-3ubuntu3] (core)
<coreycb> bdmurray: let's hold off on that until i find out
<coreycb> bdmurray: thanks for the uploads
-queuebot:#ubuntu-release- New binary: icu [arm64] (bionic-proposed/main) [60.2-3ubuntu3] (core)
<coreycb> bdmurray: ok let's reject that please
-queuebot:#ubuntu-release- New binary: icu [amd64] (bionic-proposed/main) [60.2-3ubuntu3] (core)
-queuebot:#ubuntu-release- New binary: icu [armhf] (bionic-proposed/main) [60.2-3ubuntu3] (core)
-queuebot:#ubuntu-release- New binary: icu [i386] (bionic-proposed/main) [60.2-3ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: python-oslo.context (xenial-proposed/main) [2.2.0-2 => 2.2.0-2ubuntu1] (kubuntu, openstack, ubuntu-desktop, ubuntu-server)
<xnox> slangasek, new icu is in
<slangasek> xnox: indeed
-queuebot:#ubuntu-release- New: accepted icu [amd64] (bionic-proposed) [60.2-3ubuntu3]
-queuebot:#ubuntu-release- New: accepted icu [armhf] (bionic-proposed) [60.2-3ubuntu3]
-queuebot:#ubuntu-release- New: accepted icu [ppc64el] (bionic-proposed) [60.2-3ubuntu3]
-queuebot:#ubuntu-release- New: accepted icu [arm64] (bionic-proposed) [60.2-3ubuntu3]
-queuebot:#ubuntu-release- New: accepted icu [s390x] (bionic-proposed) [60.2-3ubuntu3]
-queuebot:#ubuntu-release- New: accepted icu [i386] (bionic-proposed) [60.2-3ubuntu3]
-queuebot:#ubuntu-release- Unapproved: rejected gnocchi [source] (artful-proposed) [3.1.15-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (artful-proposed) [2:16.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.context [source] (xenial-proposed) [2.2.0-2ubuntu1]
<slangasek> hmmm ruby doing a lot of segfaulting on arm64? https://launchpad.net/ubuntu/+source/ohcount/3.1.0-1/+build/14240657
<tsimonq2> infinity, slangasek: Could I please get some more thwacking? https://is.gd/pRDB9
<tsimonq2> argh not again
<tsimonq2> https://is.gd/pRDB9o
<tsimonq2> that
<tsimonq2> slangasek: that Debian package> ack
<tsimonq2> Laney: bug 1758082> The Release Team might want to revoke their ACK now that Kubuntu is NACK.
<ubot5> bug 1758082 in ubiquity (Ubuntu) "[UIFe] Update ubiquity's Minimal Install page to match the spec" [Undecided,Confirmed] https://launchpad.net/bugs/1758082
<RAOF> It'd be convenient to get the Mir FFe (bug #1757952) approved soon; it should also be easy to approve :)
<ubot5> bug 1757952 in mir (Ubuntu) "FFe request for Mir 0.31.0.1" [Undecided,New] https://launchpad.net/bugs/1757952
<RAOF> (Mostly so that we don't have to support libmiral2 for the duration âº)
#ubuntu-release 2018-03-23
-queuebot:#ubuntu-release- Unapproved: docker.io (xenial-proposed/universe) [17.03.2-0ubuntu1~16.04.1 => 17.03.2-0ubuntu3~16.04.1] (no packageset)
<tsimonq2> slangasek: Finished my last round of initial triaging of the Qt 4 bugs; https://is.gd/pRDB9o should be good now for a while.
<slangasek> doko: ocrmypdf> your 5.5-2ubuntu1 didn't show much in the way of test failures because tesseract-ocr and ghostscript were missing from the build-dependencies... I added them and now I see what you mean (and regretted having done so).  Do you think it's better that I upload this package with this horrible testsuite that leaves dozens of tesseract processes spinning and eating CPU, or just leave
<slangasek> it as-is?
<slangasek> tsimonq2: will someone update the kubuntu seeds to drop ksaneplugin from 'supported'?
<tsimonq2> slangasek: I don't have access myself, but yes.
<tsimonq2> slangasek: processing> Many thanks.
 * slangasek nods
<slangasek> now I move on to debugging node-mapnik autopkgtest failures, and am reminded that the quoting rules for debian/tests/control are both undocumented and terrible
 * tsimonq2 doesn't want to have my name on nodejs anymore, make it go awaaaaaaaaaaay
<tsimonq2> :)
<tsimonq2> I mean, I'll follow through with this one, but... :/
-queuebot:#ubuntu-release- New binary: choqok [s390x] (bionic-proposed/universe) [1.6-1.isreally.1.6-2.1] (no packageset)
-queuebot:#ubuntu-release- New binary: choqok [ppc64el] (bionic-proposed/universe) [1.6-1.isreally.1.6-2.1] (no packageset)
-queuebot:#ubuntu-release- New binary: choqok [amd64] (bionic-proposed/universe) [1.6-1.isreally.1.6-2.1] (no packageset)
-queuebot:#ubuntu-release- New binary: choqok [i386] (bionic-proposed/universe) [1.6-1.isreally.1.6-2.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted choqok [amd64] (bionic-proposed) [1.6-1.isreally.1.6-2.1]
-queuebot:#ubuntu-release- New: accepted choqok [ppc64el] (bionic-proposed) [1.6-1.isreally.1.6-2.1]
-queuebot:#ubuntu-release- New: accepted choqok [i386] (bionic-proposed) [1.6-1.isreally.1.6-2.1]
-queuebot:#ubuntu-release- New: accepted choqok [s390x] (bionic-proposed) [1.6-1.isreally.1.6-2.1]
-queuebot:#ubuntu-release- New binary: choqok [arm64] (bionic-proposed/universe) [1.6-1.isreally.1.6-2.1] (no packageset)
-queuebot:#ubuntu-release- New binary: choqok [armhf] (bionic-proposed/universe) [1.6-1.isreally.1.6-2.1] (no packageset)
<tsimonq2> slangasek: Can you please RM src:gcompris? Scott K just removed from Debian, Debian bug 893464
<ubot5> Debian bug 893464 in ftp.debian.org "RM: gcompris -- RoQA; dead upstream, replaced by src:gcompris-qt" [Normal,Open] http://bugs.debian.org/893464
<tsimonq2> slangasek: (For future ref, does following Debian on package removals even when the package has a delta need a bug?)
<slangasek> tsimonq2: generally no bug needed, as long as I can figure out that the package isn't being maintained in Ubuntu
<tsimonq2> slangasek: OK cool.
-queuebot:#ubuntu-release- New: accepted choqok [arm64] (bionic-proposed) [1.6-1.isreally.1.6-2.1]
-queuebot:#ubuntu-release- New binary: mir [s390x] (bionic-proposed/main) [0.31.0.1-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New: accepted choqok [armhf] (bionic-proposed) [1.6-1.isreally.1.6-2.1]
-queuebot:#ubuntu-release- New: accepted virtualbox-hwe [source] (bionic-proposed) [5.2.8-dfsg-5ubuntu18.04.1]
-queuebot:#ubuntu-release- New binary: mir [ppc64el] (bionic-proposed/main) [0.31.0.1-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: mir [i386] (bionic-proposed/main) [0.31.0.1-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: mir [amd64] (bionic-proposed/main) [0.31.0.1-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: puma [s390x] (bionic-proposed/universe) [3.6.0-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: puma [i386] (bionic-proposed/universe) [3.6.0-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: puma [ppc64el] (bionic-proposed/universe) [3.6.0-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: puma [armhf] (bionic-proposed/universe) [3.6.0-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New: accepted puma [armhf] (bionic-proposed) [3.6.0-1ubuntu3]
-queuebot:#ubuntu-release- New: accepted puma [ppc64el] (bionic-proposed) [3.6.0-1ubuntu3]
-queuebot:#ubuntu-release- New binary: puma [amd64] (bionic-proposed/universe) [3.6.0-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New: accepted puma [i386] (bionic-proposed) [3.6.0-1ubuntu3]
-queuebot:#ubuntu-release- New: accepted puma [s390x] (bionic-proposed) [3.6.0-1ubuntu3]
-queuebot:#ubuntu-release- New binary: puma [arm64] (bionic-proposed/universe) [3.6.0-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New: accepted puma [amd64] (bionic-proposed) [3.6.0-1ubuntu3]
-queuebot:#ubuntu-release- New: accepted puma [arm64] (bionic-proposed) [3.6.0-1ubuntu3]
<slangasek> tsimonq2: on the nodejs front, is node-tape anything that's on your radar? Debian bug #893337
<ubot5> Debian bug 893337 in node-tape "node-tape: autopkgtest broken in new version" [Normal,Open] http://bugs.debian.org/893337
<tsimonq2> slangasek: Ah, I hadn't seen that; thanks.
-queuebot:#ubuntu-release- New binary: virtualbox-hwe [i386] (bionic-proposed/multiverse) [5.2.8-dfsg-5ubuntu18.04.1] (no packageset)
<tsimonq2> slangasek: Is that already badtested?
<slangasek> tsimonq2: it is not.
<tsimonq2> slangasek: Do you plan on badtesting it?
<slangasek> the version in -proposed has regressed the tess
<tsimonq2> Ah.
<slangasek> no
<tsimonq2> Gotcha.
<slangasek> (I plan on removing it from -proposed, if no one cares about it)
-queuebot:#ubuntu-release- New binary: mir [arm64] (bionic-proposed/main) [0.31.0.1-0ubuntu1] (desktop-core)
<tsimonq2> My vote is do it .
-queuebot:#ubuntu-release- New binary: mir [armhf] (bionic-proposed/main) [0.31.0.1-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: virtualbox-hwe [amd64] (bionic-proposed/multiverse) [5.2.8-dfsg-5ubuntu18.04.1] (no packageset)
<slangasek> tsimonq2: done.
<tsimonq2> slangasek: cool
<tsimonq2> slangasek: Can I please get "force-badtest node-class-utils/0.3.5-1" added to hints? It's regressed in release: http://autopkgtest.ubuntu.com/packages/n/node-class-utils
<tsimonq2> Thanks.
<tsimonq2> General note: sbuild should migrate now with this new upload.
<acheronuk> slangasek: ksaneplugin removed from Kubuntu supported
<slangasek> acheronuk: cheers
-queuebot:#ubuntu-release- New: accepted pyxs [source] (artful-proposed) [0.4.1+dfsg1-0ubuntu1~17.10.0]
-queuebot:#ubuntu-release- New: accepted pyxs [source] (xenial-proposed) [0.4.1+dfsg1-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- New binary: pyxs [amd64] (artful-proposed/none) [0.4.1+dfsg1-0ubuntu1~17.10.0] (no packageset)
-queuebot:#ubuntu-release- New binary: pyxs [amd64] (xenial-proposed/none) [0.4.1+dfsg1-0ubuntu1~16.04.0] (no packageset)
-queuebot:#ubuntu-release- New: accepted pyxs [amd64] (artful-proposed) [0.4.1+dfsg1-0ubuntu1~17.10.0]
-queuebot:#ubuntu-release- New: accepted pyxs [amd64] (xenial-proposed) [0.4.1+dfsg1-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- New: accepted rax-nova-agent [source] (artful-proposed) [2.1.12-0ubuntu2~17.10.0]
-queuebot:#ubuntu-release- New: accepted rax-nova-agent [source] (xenial-proposed) [2.1.12-0ubuntu2~16.04.0]
-queuebot:#ubuntu-release- New binary: rax-nova-agent [amd64] (artful-proposed/universe) [2.1.12-0ubuntu2~17.10.0] (no packageset)
-queuebot:#ubuntu-release- New binary: rax-nova-agent [amd64] (xenial-proposed/universe) [2.1.12-0ubuntu2~16.04.0] (no packageset)
-queuebot:#ubuntu-release- New: accepted rax-nova-agent [amd64] (artful-proposed) [2.1.12-0ubuntu2~17.10.0]
-queuebot:#ubuntu-release- New: accepted rax-nova-agent [amd64] (xenial-proposed) [2.1.12-0ubuntu2~16.04.0]
<cjwatson> slangasek: I guess I should technically ask for a feature freeze exception for versioned Provides support in germinate?  Though I've just deployed it on nusakan and I'm not sure changing it in the distro is risky by comparison :)
<sil2100> cjwatson: I guess it would be good to have that documented with an FFe ;)
<cjwatson> sil2100: repurposing https://bugs.launchpad.net/ubuntu/+source/germinate/+bug/1758004 for that then
<ubot5> Ubuntu bug 1758004 in Ubuntu on IBM z Systems "[Ubuntu 18.04] Error installing the "Basic Ubuntu Server"" [High,Triaged]
<cjwatson> I've diffed full germinate output before and after that change and confirmed that every resulting difference is correct
<cjwatson> (basically python{,3}-cffi-backend, some e2fsprogs transitional library packages dropping out, and some espeak packages dropping out because espeak-ng is now sufficient)
<cjwatson> (the last doesn't affect images, only extra output)
<sil2100> cjwatson: I approved the FFe o/ Thanks!
<sil2100> (oh well formallities)
<cjwatson> thank you
<LocutusOfBorg> jamespage, hello, can you please do a python-msgpack/msgpack-python switch and merge from debian?
<LocutusOfBorg> I can do it, but I have no way of testing the work
<LocutusOfBorg> see https://packages.qa.debian.org/p/python-msgpack/news/20180323T133924Z.html
<LocutusOfBorg> and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893844
<ubot5> Debian bug 893844 in borgbackup "borgbackup: upgrade of python3-msgpack creates version conflict" [Serious,Open]
<LocutusOfBorg> jamespage, something like that https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/8875622/+listing-archive-extra
<LocutusOfBorg> even if renaming the package makes my brain segfault for upgrade path
<jamespage> LocutusOfBorg: yes but won't be today...
<LocutusOfBorg> I can do it, I'm already testing the upgrade path
<LocutusOfBorg> that packaging should provide msgpack and python-msgpack so we should be safe
<LocutusOfBorg> but in case, I would like to do a no-change rebuild of reverse-deps to be safe
-queuebot:#ubuntu-release- New binary: ubuntu-wallpapers [amd64] (bionic-proposed/main) [18.04.0-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.39.3+really2.35 => 2.40] (no packageset)
<sergiusens> tjaalton: mind accepting ^
-queuebot:#ubuntu-release- New source: python-msgpack (bionic-proposed/primary) [0.5.4-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: xdg-user-dirs (xenial-proposed/main) [0.15-2ubuntu6 => 0.15-2ubuntu6.16.04.1] (core)
<tjaalton> sergiusens: where's artful?
<sergiusens> tjaalton: coming soon
<tjaalton> how soon :)
<tjaalton> I'm practically EOW
<sergiusens> 10'
<sergiusens> tjaalton: done
-queuebot:#ubuntu-release- Unapproved: snapcraft (artful-proposed/universe) [2.35+17.10 => 2.40+17.10] (no packageset)
<sergiusens> slangasek: mind accepting snapcraft into -proposed please? I think I might have missed Timo and his EOW warning
<slangasek> sergiusens: sure, I will look at it
<sergiusens> thank you very much
<slangasek> sergiusens: you're wanting to land this in -proposed before the current one is released to -updates?
<sergiusens> slangasek: if that is artful, yes, please pop 2.35+17.10  out of circulation; it will not even work on artful
<slangasek> ok
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (artful-proposed) [2.40+17.10]
-queuebot:#ubuntu-release- New sync: python-certbot-dns-cloudflare (bionic-proposed/primary) [0.22.0-1]
-queuebot:#ubuntu-release- Unapproved: neutron (artful-proposed/main) [2:11.0.3-0ubuntu1 => 2:11.0.3-0ubuntu1.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New sync: python-certbot-dns-dnsimple (bionic-proposed/primary) [0.22.0-1]
-queuebot:#ubuntu-release- New sync: python-certbot-dns-digitalocean (bionic-proposed/primary) [0.22.0-1]
-queuebot:#ubuntu-release- New sync: python-certbot-dns-google (bionic-proposed/primary) [0.22.0-1]
-queuebot:#ubuntu-release- New sync: python-certbot-dns-rfc2136 (bionic-proposed/primary) [0.22.0-1]
<tjaalton> slangasek: re nss-pem; the pkg I uploaded merges src:nss source in it, but maybe it would be best to do the other way round instead (nss-pem is <100k unpacked), though that might end up being a permanent diff to debian since I doubt mike would accept that either..
<tjaalton> "talk to upstream.." (which finally rejected it some years ago)
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.40]
<slangasek> tjaalton: hey, so, I was surprised when you said that was how you were handling nss-pem; I think duplicating the source of such a security-sensitive codebase as nss is not a great option
<slangasek> tjaalton: I understand that you can't use the existing nss package because the libraries/headers are not made public by the Debian maintainer
-queuebot:#ubuntu-release- Unapproved: neutron (xenial-proposed/main) [2:8.4.0-0ubuntu7.1 => 2:8.4.0-0ubuntu7.2] (openstack, ubuntu-server)
<slangasek> tjaalton: but I don't understand why we're considering that decision by the Debian maintainer binding for what Ubuntu does.  Why do we not take a decision to support these as public interfaces, regardless of what Debian has decided, and carry a delta?
<slangasek> it's not like we're creating our own shared libraries here... upstream is already shipping shared libraries, they just aren't shipped in /usr/lib
<tjaalton> slangasek: well nss-pem needs static libs, of non-public interfaces that haven't changed in many years
<tjaalton> sure we can carry a delta, if that's ok. but would that be packaging the headers/static libs on a separate package as proposed?
<tjaalton> feel free to drop current nss-pem and I'll create a proper one, and can upload nss too with the new pkg
<tjaalton> slangasek: put something in bug #1751140 so that it's not lost :)
<ubot5> bug 1751140 in nss (Ubuntu) "nss-pem needs additional headers, static libs to build" [Undecided,Triaged] https://launchpad.net/bugs/1751140
<slangasek> tjaalton: oh, these are interfaces that are currently not exposed at all in any of the shared objects, including those in /usr/lib/nss?
<tjaalton> not all no
<tjaalton> nssb can't be shared or there would be a circular dep
<slangasek> ok
<slangasek> let me ponder a bit more then
<tjaalton> i might have more in emails from the redhat folks, need to check later..
-queuebot:#ubuntu-release- Unapproved: accepted lttng-modules [source] (artful-proposed) [2.9.0-1ubuntu3.2]
<tjaalton> slangasek: there's one thing though that might help with the decision; redhat is actively replacing nss with openssl, but certmonger hasn't been ported yet but it will be, at some point
<tjaalton> so, could be the path of least effort is to provide only freeipa-client in the archive, and I'll put the rest in a ppa
<slangasek> tjaalton: well, if you choose to withdraw this from the archive, that certainly spares me from having to make any decision, true ;)
<tjaalton> just need to advise folks doing upgrades to enable the ppa
<slangasek> I don't think there's any obligation that you do this
<slangasek> I hate to encourage use of ppas
<tjaalton> well, for freeipa-server users..
<slangasek> and would rather figure out the right way to accept nss-pem
<tjaalton> sure
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (artful-proposed) [2:11.0.3-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (xenial-proposed) [2:8.4.0-0ubuntu7.2]
<LocutusOfBorg> [18:33:42] <LocutusOfBorg> please accept python-msgpack, it follows the same renaming that Debian did
<LocutusOfBorg> [18:33:49] <LocutusOfBorg> msgpack-python -> python-msgpack
<LocutusOfBorg> [18:33:54] <LocutusOfBorg> there aren't new binaries
<tsimonq2> infinity: Did you have any luck figuring out the critical Lubuntu install bug?
<tsimonq2> infinity: If not, might you have notes so I can take a look?
<slangasek> tsimonq2: pointer to this?
<tsimonq2> sec
<tsimonq2> slangasek: bug 1754174
<ubot5> bug 1754174 in ubiquity (Ubuntu) "[Lubuntu] "Install Lubuntu" fails with several commands not found and permission denied" [Critical,Confirmed] https://launchpad.net/bugs/1754174
<slangasek> ah that one's still around?
<tsimonq2> I guess so
-queuebot:#ubuntu-release- New binary: gcc-defaults-ports [amd64] (bionic-proposed/universe) [1.175ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gcc-defaults-ports [i386] (bionic-proposed/universe) [1.175ubuntu1] (ubuntu-desktop)
#ubuntu-release 2018-03-24
<tsimonq2> slangasek: Could you axe kdesudo? bug 1757682
<ubot5> bug 1757682 in kdesudo (Ubuntu) "Please port your package away from Qt 4" [Medium,Confirmed] https://launchpad.net/bugs/1757682
-queuebot:#ubuntu-release- New source: grub-legacy-ec2 (bionic-proposed/primary) [1:1]
<tsimonq2> slangasek: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1592405/comments/1 Do you happen to remember what version clobbered it?
<ubot5> Ubuntu bug 1592405 in plymouth (Ubuntu Bionic) "plymouth hook in initramfs needs font but doesn't Depend on it" [High,Triaged]
<xnox> tsimonq2, it may have been the merge I have done
<xnox> tsimonq2, to get the new upstream release in.
<xnox> tsimonq2, should i poke and try to look into this too?
<tsimonq2> xnox: You're more than welcome to; I'd certainly like to learn from this but if it's a quick solution, by all means, JFDI. :)
<tsimonq2> xnox: Hum, might it be that debian/initramfs-tools/hooks/plymouth is missing?
<xnox> tsimonq2, well, i'm trying to dig history, i'm pretty sure I was the one who _introduced_ using UbuntuMono font....
<tsimonq2> xnox: Heh, OK.
<xnox> tsimonq2, now I am confused. I think, this may only be using ubuntu font, post initramfs, and never in the initramfs.
<xnox> tsimonq2, and I do not see any attempts to have UbuntuFont in the initramfs.
<xnox> tsimonq2, but I do recall proposing to do that circa 2013/2014, but possibly there were concerns about "too large" file size.
<tsimonq2> xnox: I think it could be readdressed.
<tsimonq2> xnox: I wonder what the filesize difference might be.
<xnox> Ubuntu regular is 357k, we may want the Ubuntu Mono regular which is 209k
<tsimonq2> And right now, DejaVu is used?
<tsimonq2> I mean, for a 209k difference, I personally think it's a good idea.
<xnox> DeajuSerif + Sans are 381k + 758k
<tsimonq2> Ok, so if we *just* use Ubuntu Mono, then that's less size?
<tsimonq2> Or am I not seeing this right?
<xnox> supports less languages, but i'm not sure we support translations in the initramfs
<xnox> and we need to customize fonconfig conf file, in the initramfs
<xnox> but easy enough to special case that.
<xnox> cause, Ubuntu font is not "metric" compatible with Arial, unlike DejaVuSans
<tsimonq2> OK
<xnox> then again... this is plymouth and plymouth-text, not thesis typesetting
<tsimonq2> Hehe, right.
<tsimonq2> xnox: So is this something that you could JFDI pretty easily?
<xnox> tsimonq2, do you know if derivates plymouth themes also specify and use 'Ubuntu 11'? or just the Ubuntu one?
<xnox> aka lubuntu-logo, etc?
 * tsimonq2 looks at what Lubuntu does
<xnox> just need to write a "better" /etc/fonts/conf.d/60-latin.conf
<xnox> to be all ubuntu font family
<tsimonq2> xnox: Yeah no, this just specifies a module of "ubuntu-text"
<tsimonq2> (in Lubuntu's)
<xnox> lubuntu-logo should be the one splashy
<xnox> ubuntu-text, is the "serial non-quiet non-splash" version
<xnox> plymouth-theme-lubuntu-logo or like plymouth-theme-lubuntu-next-logo
<tsimonq2> Right.
<tsimonq2> But we also have just text packages.
<xnox> yeah, for text-only we don't do anything - no fancy fonts, no pango, no truetype, because we asume the user wants just the kernel font rendering.
<xnox> because the user wants it shmall
<xnox> tsimonq2, so it looks like at least lubuntu-font got forked, before 'Ubuntu 11' was added in the "ubuntu-logo" theme.
<xnox> so does not use that.
<xnox> A quick fix, is to stop using 'Ubuntu 11' in the ubuntu-logo theme =)
<xnox> or ship the ubuntu font, and force it to be used by default, and then there would be no need for it to be specified.
<tsimonq2> If it doesn't use too much resources, I'd argue for the latter.
<tsimonq2> I mean, if it introduces little to no size, even in cases where the user wants it small, if it's just 1/5 of a MB, it shouldn't be a big deal.
<xnox> when kernel modules are huge.
<tsimonq2> Right.
<tsimonq2> The kernel is kinda huge. :P
<tsimonq2> (In comparison.)
<tsimonq2> xnox: Oh, jbicha made a good point on the bug report.
<xnox> tsimonq2, this will need testing.
<xnox> hm?
<xnox> tsimonq2, yes, i did notice the transitional package dep already
<tsimonq2> OK, cool.
<tsimonq2> xnox: Would you like to take care of this (because I assume you know the codebase better) or should I?
<tsimonq2> I'm fine either way.
<tsimonq2> And indeed, testing will be needed.
<jbicha> the transitional font dep has been annoying me for a while, but I was not annoyed enough to touch plymouth ð
<tsimonq2> This might be a good occasion. :)
<xnox> jbicha, hahahhahaha
<xnox> tsimonq2, i'll do it all; but will need to do boot tests; so not right now, but soon.
<tsimonq2> xnox: Alright; I'll assign the bug to you. Thanks, and please keep me updated. :)
<tsimonq2> Er, you did already. Cool.
<slangasek> xnox: ah; I guess I was wrong about the initramfs hook having used the Ubuntu font previously?  I just checked the last version before the Debian merge (0.9.0-0ubuntu9 in vivid) had a dep on both fonts-dejavu-core and ttf-ubuntu-font-family, and only copied fonts-dejavu-core into the initramfs
<slangasek> xnox: so, it would be nice to get it using the Ubuntu font consistently (and dropping the need to pull dejavu in in this context), but re-adding the dejavu dep would apparently suffice to fix the regression
<tsimonq2> slangasek: Would you happen to know what's going on with armhf autopkgtest builders?
<tsimonq2> (I'm asking you because I hope you saw that the build you've triggered is also queued but not running. :P)
<slangasek> tsimonq2: nope, haven't looked; looking now
<tsimonq2> ack
<tsimonq2> lol @ someone uploading zfs-linux to Debian that was likely meant for Ubuntu
 * tsimonq2 shrugs, it happens I guess
<slangasek> tsimonq2: armhf sorted; looks like the lxd runners aren't entirely happy with the daily maintenance job, they likely would've started right about now on their own if I had done nothing
<slangasek> but that means they were down for 2 hours, unhelpfully
<tsimonq2> slangasek: ah ok
<tsimonq2> cool, thanks
<tsimonq2> slangasek: It'd be good to get a second opinion on node-cross-spawn
<tsimonq2> Its tests fail with the new nodejs, but the version we ship doesn't have upstream tests for nodejs 8.x.
<tsimonq2> We also ship a release that's a major version behind.
<tsimonq2> Ultimately the arm{hf,64} test failures are just timeouts.
<tsimonq2> I've been trying to set the timeout integers to be larger values in my PPA testing but have ultimately been unsuccessful so far.
<tsimonq2> I'll try some more, but if the situation doesn't improve, then I'm not sure what to do from there.
<tsimonq2> In fact, that sort of thing seems almost commonplace; we're shipping node modules with out-of-date versions which have failing tests that have been completely revamped upstream.
<tsimonq2> (I'm making a generalization, but still.)
<slangasek> tsimonq2: there are enough nodejs-triggered autopkgtests that fail only on arm64 and armhf that it makes it suspicious that there may be arch-specific regressions in our nodejs
<slangasek> tsimonq2: node-block-stream, node-commander, node-cross-spawn, node-liftoff - are these related?
<tsimonq2> slangasek: I haven't taken a close look but it's possible.
<tsimonq2> slangasek: node-liftoff seems to need timeout bumps like node-cross-spawn.
<tsimonq2> Doing, although it's a bit of a PITA because turnaround time for testing is 20 minutes minimum, and these tests stop as soon as there's one error. Sigh.
<tsimonq2> slangasek: I don't quite know what to make of node-block-stream.
<tsimonq2> slangasek: node-cross-spawn *should* be fixed now.
<tsimonq2> slangasek: And node-commander is kind of weird: AssertionError: expected '' to be 'SIGHUP\n'
<tsimonq2> slangasek: So while these are unrelated, it's weird that these only happen on *some* arches.
-queuebot:#ubuntu-release- New: accepted gcc-defaults-ports [amd64] (bionic-proposed) [1.175ubuntu1]
-queuebot:#ubuntu-release- New: accepted ubuntu-wallpapers [amd64] (bionic-proposed) [18.04.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted virtualbox-hwe [i386] (bionic-proposed) [5.2.8-dfsg-5ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted gcc-defaults-ports [i386] (bionic-proposed) [1.175ubuntu1]
-queuebot:#ubuntu-release- New: accepted virtualbox-hwe [amd64] (bionic-proposed) [5.2.8-dfsg-5ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted mir [amd64] (bionic-proposed) [0.31.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mir [armhf] (bionic-proposed) [0.31.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mir [ppc64el] (bionic-proposed) [0.31.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mir [arm64] (bionic-proposed) [0.31.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mir [s390x] (bionic-proposed) [0.31.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mir [i386] (bionic-proposed) [0.31.0.1-0ubuntu1]
<tsimonq2> slangasek: Actually, note-liftoff can be badtested.
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.31.2 => 2.32] (desktop-core, ubuntu-server)
<estan> ginggs: ping. bcolz 1.2.0+ds1-1 now ready to be synced from debian/incoming. should fix the autopkgtest failure of c-blosc 1.14.2+ds1-1.
<estan> ahem s/of c-blosc/with c-blosc/
<ginggs> estan: waiting for it to be picked up by launchpad https://launchpad.net/debian/+source/bcolz
<estan> ginggs: aha.
-queuebot:#ubuntu-release- New sync: deepin-movie-reborn (bionic-proposed/primary) [3.2.3-2]
<estan> ginggs: looks like the eagle landed ^ :)
<LocutusOfBorg> hello jbicha, I'm uploading a gtk+2.0 merge, because the current one is FTBFS in release pocket, probably your glib2 upload broke it?
<jbicha> LocutusOfBorg: sync meson
<jbicha> I mean unless I need yet another FFe for that
<jbicha> the Ubuntu diff can be dropped now
<ginggs> estan: infinity beat me to it
<jbicha> LocutusOfBorg: I mean you could merge glib2.0 if you want tooâ¦
<jbicha> LocutusOfBorg: I'm all confused. Let's start over. Do you have a build log for the gtk2 build problem?
<LocutusOfBorg> ok glib2.0 done
<LocutusOfBorg> jbicha, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages
<jbicha> you synced gtk2, why?
<LocutusOfBorg> this is a no change rebuild of the version in release
<LocutusOfBorg> jbicha, I didn't :) or better, I did just to avoid uploading the source tarball for the diff
<LocutusOfBorg> I have a connection that sucks a bit, I didn't make the sync build at all
<LocutusOfBorg> jbicha, do you see the symbols that have been dropped in the merge? http://launchpadlibrarian.net/361892471/gtk+2.0_2.24.32-1_2.24.32-1ubuntu1.diff.gz
<LocutusOfBorg> should I readd them in your opinion? g_cclosure_marshal_VOID__BOXED
<LocutusOfBorg> they are removed in the last patch that ubuntu applies
<LocutusOfBorg> they are coming from glib, and they shouldn't be there...
<LocutusOfBorg> not sure if this is a problem or not
<LocutusOfBorg> somebody from desktop team today  told me to just remove them
<LocutusOfBorg> because such symbols are inside glib2.0, and they shouldn't be in gtk2 (and gtk2 links glib2, so there is no runtime issue)
<jbicha> yes, they can be removed as I think that was a glib bug
<jbicha> y'all probably shouldn't have changed gtk_print_backend_set_password@Base 2.24.25-0ubuntu2 but since a newer version is in xenial maybe it doesn't matter so much
<jbicha> please push your changes to bzr  lp:~ubuntu-desktop/gtk/ubuntu
<jbicha> I believe we'll be switching to git for Chaotic Camel ( web link for bzr is https://code.launchpad.net/~ubuntu-desktop/gtk/ubuntu )
<jbicha> if y'all are really eager, you can merge gtk3 too :)
<LocutusOfBorg> "y'all probably shouldn't have changed gtk_print_backend_set_password@Base 2.24.25-0ubuntu2 but since a newer version is in xenial maybe it doesn't matter so much"
<LocutusOfBorg> this is *exactly* what I changed, but after I changed it back, because "better safe than sorry"
<LocutusOfBorg> sure, I'll push them
<jbicha> that symbol version was changed in the version pushed to bionic
<LocutusOfBorg> I know, but maybe reverse-deps complains if we don't rebuild?
<jbicha> hmm?
<LocutusOfBorg> I mean, ok  the lower bound is already satisfied
<jbicha> I'll probably have to do a gtk2 upload in unstable to drop the extra glib symbols
<LocutusOfBorg> thanks jbicha :)
<LocutusOfBorg> btw, I sync'd meson, just bugfixes, new tests and a bug I was hitting with libinput
<jbicha> thanks
<estan> ginggs: you guys have been my dream team through this :)
<jbicha> LocutusOfBorg: gtk2 builds fine in unstable. I guess I could mark those closure symbols as optionalâ¦ not really sure why Debian & Ubuntu are different there now
<slangasek> tsimonq2: what's the rationale for considering node-liftoff badtest?
<jbicha> LocutusOfBorg: gtk2 is one of the last Debian GNOME packages to use cdbs, I wonder if that helps explain the g_cclosure symbols? none of our other libraries have those symbols
<jbicha> LocutusOfBorg: https://launchpad.net/ubuntu/+source/meson/0.45.1-1/+build/14489818 (it was a binary upload in Debian :| )
-queuebot:#ubuntu-release- New binary: javatools [amd64] (bionic-proposed/universe) [0.63] (no packageset)
<LocutusOfBorg> jbicha, gtk2, the latest patch (ubuntu specific) is changing the file "./gtk/gtkmarshalers.list"
<LocutusOfBorg> so removing them manually I would say
<LocutusOfBorg> Debian has not this patch, so they appears there?
<jbicha> ok, the use-secrets-service patch?
<LocutusOfBorg> yes, this: +-VOID:POINTER,POINTER,POINTER,POINTER,STRING
<LocutusOfBorg> btw, doko any idea if you are building libphobos.a without fPIC?
<LocutusOfBorg>  /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/8/libgphobos.a(stdio.o): relocation R_X86_64_TPOFF32 against symbol `_D3std5stdio10readlnImplFPOS4core4stdc5stdio8_IO_FILEKAawE3std5stdio4File11OrientationZ1nm' can not be used when making a shared object; recompile with -fPIC
<LocutusOfBorg> this happens with meson
<Laney> LocutusOfBorg: we have a packaging branch for glib2.0 if you'd be so kind as to push there please
<LocutusOfBorg> link please? I'll be happy to push
<LocutusOfBorg> also, gtk3 uploaded
<jbicha> LocutusOfBorg: it's in the VCS fields in debian/control :)
<LocutusOfBorg> ok, lets do it tomorrow :)
<LocutusOfBorg> too late here
<LocutusOfBorg> I think I did also glib2.0, please don't shoot at me if I did import it wrong :)
 * LocutusOfBorg goes to sleep
#ubuntu-release 2018-03-25
<tsimonq2> slangasek: Regressed in release on arm*
<slangasek> tsimonq2: unfortunately, those retest logs show nodejs was installed from -proposed anyway despite not being requested
<tsimonq2> slangasek: Gah. How'd that happen? :/.
<slangasek> tsimonq2: not clear to me from the logs why it happened in this case
<slangasek> but I know of other cases where it could happen by design, which is why I was checking logs for versions
<tsimonq2> I didn't know that could happen, which is why I didn't bother...
<tsimonq2> I'll retry when I can; I'm feeling a bit sick so I might call it early tonight...
-queuebot:#ubuntu-release- New: accepted javatools [amd64] (bionic-proposed) [0.63]
-queuebot:#ubuntu-release- New: accepted deepin-movie-reborn [sync] (bionic-proposed) [3.2.3-2]
-queuebot:#ubuntu-release- New: accepted python-certbot-dns-digitalocean [sync] (bionic-proposed) [0.22.0-1]
-queuebot:#ubuntu-release- New: accepted python-certbot-dns-google [sync] (bionic-proposed) [0.22.0-1]
-queuebot:#ubuntu-release- New: accepted python-certbot-dns-cloudflare [sync] (bionic-proposed) [0.22.0-1]
-queuebot:#ubuntu-release- New: accepted python-certbot-dns-rfc2136 [sync] (bionic-proposed) [0.22.0-1]
-queuebot:#ubuntu-release- New: accepted python-certbot-dns-dnsimple [sync] (bionic-proposed) [0.22.0-1]
-queuebot:#ubuntu-release- New binary: python-certbot-dns-google [amd64] (bionic-proposed/universe) [0.22.0-1] (no packageset)
<doko> LocutusOfBorg: I'll have a look at libphobos
-queuebot:#ubuntu-release- New binary: deepin-movie-reborn [s390x] (bionic-proposed/universe) [3.2.3-2] (no packageset)
<doko> LocutusOfBorg, jamespage: why do you package msgpack 0.5.4 when 0.5.6 is available?
-queuebot:#ubuntu-release- New binary: deepin-movie-reborn [amd64] (bionic-proposed/universe) [3.2.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: deepin-movie-reborn [i386] (bionic-proposed/universe) [3.2.3-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-certbot-dns-google [amd64] (bionic-proposed) [0.22.0-1]
-queuebot:#ubuntu-release- New source: openjdk-lts (bionic-proposed/primary) [9.0.4+12-2ubuntu4]
-queuebot:#ubuntu-release- New: accepted openjdk-lts [source] (bionic-proposed) [9.0.4+12-2ubuntu4]
-queuebot:#ubuntu-release- New: accepted deepin-movie-reborn [amd64] (bionic-proposed) [3.2.3-2]
-queuebot:#ubuntu-release- New: accepted deepin-movie-reborn [s390x] (bionic-proposed) [3.2.3-2]
-queuebot:#ubuntu-release- New: accepted deepin-movie-reborn [i386] (bionic-proposed) [3.2.3-2]
<tsimonq2> I wonder if c-cycle could be created in Launchpad so I can start targeting bugs at it.
<tsimonq2> slangasek: Hum, what came out of the discussion wrt axing src:gcompris?
<tsimonq2> cjwatson: (you're in a more convenient timezone right now so...) could I please get node-define-property demoted to bionic-proposed? Debian bug 892656, https://launchpad.net/~tsimonq2/+archive/ubuntu/upload-testing/+sourcepub/8878227/+listing-archive-extra : it's FTBFS no-change rebuilding against only packages in release, and its failing autopkgtests are blocking nodejs' migration.
<ubot5> Debian bug 892656 in src:node-define-property "node-define-property: FTBFS and Debci failure" [Serious,Open] http://bugs.debian.org/892656
<tsimonq2> (dunno if "more convenient" is the right phrase but it works I guess :P)
<tsimonq2> Something might be wrong, this seems stuck: https://autopkgtest.ubuntu.com/running
<tsimonq2> I doubt many people are around right now but if someone is, it'd be good if that could be looked at.
<doko> Laney: there seems to be a bug for the openjdk-lts upload (just a source rename from openjdk-9, but building the same openjdk-9-* packages). the tests were started once the source was published, while all builds were still running
<LocutusOfBorg> doko, there is something weird on new releases, e.g. https://github.com/msgpack/msgpack-python/commit/da902f9c1d996fb461f1efef6487ef40d32d365a
<LocutusOfBorg> they are fixed in 0.5.6, but it is a risky move to update right now, specially because it broke already reverse-deps in Debian, and my upload is trying to fix the mess
<LocutusOfBorg> we can sync once debian updates it too
<LocutusOfBorg> if you want to update, you are free to do it, it is a trivial update, but I don't take responsibility for the breakage that might happen :)
<LocutusOfBorg> right now I want the package to have the same name as in Debian
<LocutusOfBorg> if you tell me "I accept only if you update", then I'll comply with the request
-queuebot:#ubuntu-release- New: accepted python-msgpack [source] (bionic-proposed) [0.5.4-0ubuntu2]
-queuebot:#ubuntu-release- New binary: binutils [i386] (bionic-proposed/main) [2.30-9ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: binutils [amd64] (bionic-proposed/main) [2.30-9ubuntu1] (core)
-queuebot:#ubuntu-release- New: accepted binutils [amd64] (bionic-proposed) [2.30-9ubuntu1]
-queuebot:#ubuntu-release- New: accepted binutils [i386] (bionic-proposed) [2.30-9ubuntu1]
-queuebot:#ubuntu-release- New sync: lexicon (bionic-proposed/primary) [2.1.21-1]
<tsimonq2> Evil ginggs is evil and synced nodejs again for me, in my name. :P
<tsimonq2> Although it'd be cool if the runners would unstick...
<tsimonq2> slangasek, Laney: autopkgtest runners need looking, if either of youare around.
-queuebot:#ubuntu-release- New binary: wxwidgets3.0 [s390x] (bionic-proposed/universe) [3.0.4+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: wxwidgets3.0 [ppc64el] (bionic-proposed/universe) [3.0.4+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: wxwidgets3.0 [i386] (bionic-proposed/universe) [3.0.4+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: wxwidgets3.0 [amd64] (bionic-proposed/universe) [3.0.4+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: wxwidgets3.0 [arm64] (bionic-proposed/universe) [3.0.4+dfsg-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: wxwidgets3.0 [armhf] (bionic-proposed/universe) [3.0.4+dfsg-2] (kubuntu)
<tsimonq2> autopkgtesters are still at a standstill
<tsimonq2> Queues are approaching 700 or 800 an arch
<tsimonq2> (and they've been this way for at least 10 hours...)
-queuebot:#ubuntu-release- New: accepted wxwidgets3.0 [amd64] (bionic-proposed) [3.0.4+dfsg-2]
-queuebot:#ubuntu-release- New: accepted wxwidgets3.0 [armhf] (bionic-proposed) [3.0.4+dfsg-2]
-queuebot:#ubuntu-release- New: accepted wxwidgets3.0 [ppc64el] (bionic-proposed) [3.0.4+dfsg-2]
-queuebot:#ubuntu-release- New: accepted wxwidgets3.0 [arm64] (bionic-proposed) [3.0.4+dfsg-2]
-queuebot:#ubuntu-release- New: accepted wxwidgets3.0 [s390x] (bionic-proposed) [3.0.4+dfsg-2]
-queuebot:#ubuntu-release- New: accepted wxwidgets3.0 [i386] (bionic-proposed) [3.0.4+dfsg-2]
<slangasek> tsimonq2: I don't see any evidence that the runners were at a standstill for any significant period; the internal graphs I'm looking at show ppc64el underperforming, but all archs are working through the backlog
<jbicha> slangasek: there are some oddities
<jbicha> for instance, the numbers are going down at https://autopkgtest.ubuntu.com/running but the currently running tests isn't accurate
<slangasek> not accurate how?
<jbicha> http://autopkgtest.ubuntu.com/packages/a/alt-ergo/bionic/amd64 should show a result for glib2.0 2.56.0-4ubuntu1
<ginggs> yup, and 'Recent run tests' http://autopkgtest.ubuntu.com/ seems out of date
<slangasek> well.  certainly the claim that there are only two currently running tests is inconsistent with the queues going down
<jbicha> not accurate > "there are more tests running right now that just node-commander"
<slangasek> recent run tests> I've never looked at the code for that (and hardly ever use the page); I'll try to figure out the problem with current status first
<slangasek> jbicha, ginggs, tsimonq2: the web node ran out of disk space.  queues were proceeding normally
<slangasek> hey wouldn't it be great if old kernels were autoremoved
<ginggs> slangasek: thanks
<jbicha> slangasek: some day we'll fix that autoremove kernel bug for good
<slangasek> jbicha: I'm basically trolling any Foundations folks who are reading, because fixing that bug is top of the list for this cycle
<jbicha> it was fixed multiple times already, right?
<slangasek> it was never fixed to where unattended-upgrades would also autoremove
<slangasek> that's the missing bit
<jbicha> ok cool
<jbicha> maybe you can review LP: #1758740 ?
<ubot5> Launchpad bug 1758740 in gnucash (Ubuntu) "FFe: Sync gnucash 1:2.7.6-1 (universe) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/1758740
 * mwhudson waves at slangasek so he doesn't think his troll was wasted
<slangasek> :)
<slangasek> doko: what's the story with gcj-jdk going NBS?  It's very much still used in bionic
<slangasek> doko: (and e.g. causes automake-1.15 autopkgtests to fail currently)
<ginggs> slangasek: re autopkgtest quoting rules in your upload of node-mapnik, do you know what changed? node-archy is affected too.
-queuebot:#ubuntu-release- New binary: gitlab-ci-multi-runner [i386] (bionic-proposed/universe) [10.5.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gitlab-ci-multi-runner [s390x] (bionic-proposed/universe) [10.5.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gitlab-ci-multi-runner [amd64] (bionic-proposed/universe) [10.5.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gitlab-ci-multi-runner [ppc64el] (bionic-proposed/universe) [10.5.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gitlab-ci-multi-runner [arm64] (bionic-proposed/universe) [10.5.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gitlab-ci-multi-runner [armhf] (bionic-proposed/universe) [10.5.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted gitlab-ci-multi-runner [amd64] (bionic-proposed) [10.5.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted gitlab-ci-multi-runner [armhf] (bionic-proposed) [10.5.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted gitlab-ci-multi-runner [ppc64el] (bionic-proposed) [10.5.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted lexicon [sync] (bionic-proposed) [2.1.21-1]
-queuebot:#ubuntu-release- New: accepted gitlab-ci-multi-runner [arm64] (bionic-proposed) [10.5.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted gitlab-ci-multi-runner [s390x] (bionic-proposed) [10.5.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted gitlab-ci-multi-runner [i386] (bionic-proposed) [10.5.0+dfsg-2]
#ubuntu-release 2019-03-18
-queuebot:#ubuntu-release- New binary: openjdk-13 [amd64] (disco-proposed/universe) [13~12-1] (no packageset)
<vorlon> Laney, juliank: heads up that triggering autopkgtests through the web api doesn't seem to be working; I haven't dug into it, I'm only noticing while trying to give back some perl-triggered tests
<vorlon> seems to be hanging talking to rabbit; trying to restart rabbit
<vorlon> ok that looks better
<ginggs> vorlon: the single python-scipy/1.2.1-0ubuntu1 test failure I see locally is definitely caused by matplotlib >= 3.0.0 - I want to upload 1.2.1-0ubuntu2 to switch back to gcc 8 on s390x, should I skip this test in the same upload?
<LocutusOfBorg> oSoMoN, hello, did you receive my messages?
<oSoMoN> LocutusOfBorg, good morning, I don't think so, when were they sent?
<LocutusOfBorg> [15:06:28] <LocutusOfBorg> anybody with an s390x or a bigger knowledge can help understanding why thunderbird is sad on s390x? (I see update output complaining wrt testsuite), new binary there
<LocutusOfBorg> [15:07:20] <LocutusOfBorg> trying: thunderbird
<LocutusOfBorg> [15:07:20] <LocutusOfBorg> skipped: thunderbird (6, 3, 2)
<LocutusOfBorg> [15:07:20] <LocutusOfBorg>     got: 35+0: a-7:a-5:a-5:i-5:p-4:s-9
<LocutusOfBorg> [15:07:20] <LocutusOfBorg>     * s390x: thunderbird-testsuite
<LocutusOfBorg> [15:38:17] <jbicha> LocutusOfBorg: thunderbird-testsuite depends on gnome-session which depends on gnome-shell which isn't available on s390x
<LocutusOfBorg> [15:39:03] <jbicha> maybe we shouldn't build thunderbird-testsuite on s390xâ¦
<LocutusOfBorg> oSoMoN, I send them with /msg command, not sure if you can read them now...
<LocutusOfBorg> anyway ^^
<LocutusOfBorg> we shouldn't build thunderbird-testsuite on s390x because it can't be installed?
<oSoMoN> LocutusOfBorg, thunderbird used to fail to build on s390x, but Rico recently worked out some patches that make the build succeed there
<oSoMoN> that would explain why this started to fail
<oSoMoN> that package appears to be mostly empty on s390x
<oSoMoN> oh, not just there, actually
<oSoMoN> I wonder if that package could simply be removed?
<oSoMoN> let me check
<oSoMoN> I see the following commit on 2015-08-17:
<oSoMoN> * Disable all of the testsuite related patches and don't install anything
<oSoMoN>   in to the testsuite package for now. The patches have all bit-rotted,
<oSoMoN>   we're not running any tests and nobody is driving that anymore
<oSoMoN> it looks like the package can safely be removed
<oSoMoN> chrisccoulson, what do you think? ^
-queuebot:#ubuntu-release- New: accepted openjdk-13 [amd64] (disco-proposed) [13~12-1]
<LocutusOfBorg> oSoMoN, debian removed the testsuite package too
<LocutusOfBorg> (not sure if they ever had it)
<LocutusOfBorg> and no reverse-deps, so it should be safe to go
<LocutusOfBorg> please bump debci hint...
<rbalint> seb128, juliank seb128: software-properties was a bit tricky because it could not be imported by git-remote-bzr to cross-check, but I committed the conversion script here: https://code.launchpad.net/~ubuntu-core-dev/+git/bzr-git-mass-convert/+ref/master
<rbalint> how about swithing it to git on wednesday?
<rbalint> master branch only, since older branches are out of date
<seb128> wfm
<jbicha> vorlon: some packages went missing when they were promoted from disco-proposed: I noticed epiphany-browser, ruby-pkg-config, simple-scan
-queuebot:#ubuntu-release- Unapproved: accepted indicator-application [sync] (cosmic-proposed) [12.10.1+18.10.20190308.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted indicator-application [sync] (bionic-proposed) [12.10.1+18.04.20190308.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected ggcov [source] (cosmic-proposed) [0.9+20190314-0ubuntu0.3]
-queuebot:#ubuntu-release- Unapproved: ggcov (bionic-proposed/universe) [0.9-20 => 0.9+20190314-0ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ggcov (cosmic-proposed/universe) [0.9-21 => 0.9+20190314-0ubuntu0.3] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [4.18.0-17.18~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [4.18.0-17.18~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [4.18.0-17.18~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [4.18.0-17.18~18.04.1]
<seb128> sil2100, bug #1637988, I saw that you accepted gvfs without libnfs which means the gvfs-backends binary from main in the SRU depends on an universe library
<ubot5> bug 1637988 in gvfs (Ubuntu Cosmic) "Enable the nfs backend" [Undecided,Fix committed] https://launchpad.net/bugs/1637988
<infinity> seb128: What's the point of the no-change upload in the queue?
<infinity> seb128: If the MIR is approved, we can just binary copy the one from release to updates and override it to main.
<seb128> infinity, when I asked here last week someone replied that libnfs couldn't be moved from universe to main in the release pocket and such we needed an uplaod
<seb128> ah
<infinity> The first is true, the second is not.
<seb128> then feel free to do that
<seb128> k, makes sense
<infinity> THe bug log implied the MIR was still in progress?
<infinity> So, no, I don't feel free to do that.
<seb128> which part?
<seb128> https://bugs.launchpad.net/ubuntu/+source/libnfs/+bug/1746598 was promoted in disco
<ubot5> Ubuntu bug 1746598 in libnfs (Ubuntu) "[MIR] libnfs" [Undecided,Fix released]
<infinity> YEs, and cosmic and disco have entirely different versions.  Committing to support from 3.0 onward doesn't retroactively apply to old ones.
<infinity> As for "which part", comment #14 of the bug you poked sil2100 with. :P
<seb128> ah, somewhat I did receive the email/see that comment
<sil2100> seb128: yeah, as per my comment on the bug, I accepted cosmic prematurely, it wasn't supposed to be accepted
<sil2100> seb128: since I was waiting for the MIR situation to be resolved
<seb128> well, as long as nobody move it to updates by error
<seb128> k
<seb128> did you ping security about it?
<infinity> Yeah, I'll reject the unnecessary rebuild from the queue.
<sil2100> I poked the MIR team and I think slashd today reminded the security team about it
<seb128> thx
<seb128> k, good
<infinity> And please, someone make sure that either 2.0 is MIRed for b/c, or if that fails, a solid argument for backporting 3.0 is made.
<infinity> (The former preferred)
-queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02+dfsg1-5ubuntu8.2 => 2.02+dfsg1-5ubuntu8.3] (core)
-queuebot:#ubuntu-release- Unapproved: rejected libnfs [source] (cosmic-proposed) [2.0.0-1~exp1ubuntu1]
<infinity> Oh, 3.0 adds NFSv4 support. :/
<infinity> If the argument for using libnfs in gvfs is wider interop, missing v4 kinda sucks.
<infinity> But I guess it's better than no NFS at all.
<infinity> And people who still run Solaris are probably used to living in the past.
<vorlon> jbicha: missing packages> do you want to feed me version numbers or point to the log where they went missing?
<seb128> vorlon, https://launchpad.net/ubuntu/+source/epiphany-browser/+publishinghistory for example?
<seb128>  	3.32.0-1ubuntu1 was
<seb128> Deleted on 2019-03-15 by Ubuntu Archive Robot
<seb128> moved to release
<seb128> but never made it there
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-47.50~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-47.50~16.04.1] (kernel)
<vorlon> seb128, jbicha: copied for the 3 packages mentioned
<Eickmeyer> vorlon: Had a chance to look at carla yet?
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.12 => 2.02-2ubuntu8.13] (core)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-47.50~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-47.50~16.04.1]
-queuebot:#ubuntu-release- Unapproved: grub2-signed (cosmic-proposed/main) [1.110.2 => 1.110.3] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (bionic-proposed/main) [1.93.13 => 1.93.14] (core)
<slashd> sil2100, infinity : security team suggest to upgrade libnfs from 2.0.0 to 3.0.0 in B/C due to sec issues and nasty bugs. Wearing your SRU hat, would you be okay with the proposition before any work start in that regard ? https://bugs.launchpad.net/ubuntu/+source/libnfs/+bug/1746598
<ubot5> Ubuntu bug 1746598 in libnfs (Ubuntu) "[MIR] libnfs" [Undecided,Fix released]
<slashd> 2.0.0 as-is will most likely be NACK by security team at first glance.
<slashd> seb128, ^ fyi
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (cosmic-proposed/main) [4.18.0-1014.14] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (cosmic-proposed/main) [4.18.0-1008.9] (kernel)
<seb128> slashd, thx
-queuebot:#ubuntu-release- New binary: ubuntu-mate-artwork [amd64] (disco-proposed/universe) [19.04.0] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: golang-1.6 (trusty-security/main) [1.6-0ubuntu1~14.04 => 1.6-0ubuntu1~14.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: golang-1.6 (trusty-updates/main) [1.6-0ubuntu1~14.04 => 1.6-0ubuntu1~14.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted golang-1.6 [sync] (trusty-security) [1.6-0ubuntu1~14.04]
-queuebot:#ubuntu-release- Unapproved: accepted golang-1.6 [sync] (trusty-updates) [1.6-0ubuntu1~14.04]
-queuebot:#ubuntu-release- New sync: pdfchain (disco-proposed/primary) [1:0.4.4.2-1]
<seb128> Could someone review ffe bug #1820259? It should basically be a no-op for disco since livepatch isn't used in that serie, but it's a pre-requirement for the bionic SRU
<ubot5> bug 1820259 in update-notifier (Ubuntu) "[FFe] Add a indicator to show the status of Livepatch" [Medium,In progress] https://launchpad.net/bugs/1820259
<coreycb> hello, can an archive admin take a look at masakari-monitors in the disco NEW queue?
-queuebot:#ubuntu-release- New: rejected pdfchain [sync] (disco-proposed) [1:0.4.4.2-1]
-queuebot:#ubuntu-release- New: accepted ubuntu-mate-artwork [amd64] (disco-proposed) [19.04.0]
#ubuntu-release 2019-03-19
-queuebot:#ubuntu-release- Unapproved: hollywood (cosmic-proposed/universe) [1.14-0ubuntu1 => 1.15-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1035.40] (kernel)
<seb128> could someone review/ack bug #1820259?
<ubot5> bug 1820259 in update-notifier (Ubuntu) "[FFe] Add a indicator to show the status of Livepatch" [Medium,In progress] https://launchpad.net/bugs/1820259
<seb128> it's basically a no-op for disco since livepatch isn't working on that serie and such the indicator is not showing
<seb128> but that's needed to do the SRU
<seb128> no-one? I already asked yesterday, that should be a trivial one to review :-/
<bluesabre> Release team, also looking for an ack on https://bugs.launchpad.net/ubuntu/+source/xubuntu-artwork/+bug/1820388 please :)
<ubot5> Ubuntu bug 1820388 in xubuntu-artwork (Ubuntu) " [UIFe] New wallpaper for Xubuntu 19.04" [Undecided,New]
<seb128> bluesabre, did you email the documentation/translation teams as described on https://wiki.ubuntu.com/FreezeExceptionProcess#UserInterfaceFreeze_Exceptions ?
<bluesabre> seb128, it doesn't require a change to the strings or the layout, it's just the wallpaper
<bluesabre> we have no documentation that features the wallpaper
<seb128> bluesabre, no screenshot of an xubuntu desktop on any documentation/website/etc?
<seb128> bluesabre, also the process described doesn't specify that those notifications are optionals
<sil2100> I can take a look at FFe's today
<sil2100> seb128: looking o/
<seb128> sil2100, thx!
<juliank> rbalint: I think even if the other branches are incomplete, it would be nice to import them and bring them up-to-date?
<juliank> (re software-properties)
<juliank> that said, are there any?
<juliank> I can't find them
<rbalint> juliank, there are trusty branches here: https://code.launchpad.net/ubuntu/+source/software-properties/+branches
 * juliank is more interested in xenial and bionic
<rbalint> juliank, those seem to be maintained only in uploads
<juliank> ack
<juliank> I'll probably go back in time and create git branches by importing the uploads then, so we have a basic working repo
<juliank> * basic working repo for SRUing
<rbalint> juliank, if the status quo is just using uploads then the usd imports provide a fine git base for it
<juliank> It's the status quo, but it's not what it should be
<juliank> :)
<rbalint> juliank, if we would like to do reviews, then a proper history would be better, but the imports can be done after the switch with master
<rbalint> juliank, i agree, but i don't find lp's git support comfortable enough to enforce people to do code reviews
<juliank> rbalint: it's not only for reviews, but also for personal wip tracking
<bluesabre> seb128, "Every change of the user interface (either a string or the layout)" would make it optional in this case. And yeah, no screenshots anywhere... since we're always late, we got rid of the offending screenshots years ago to make the process less painful for everybody
<rbalint> juliank, i usually just use short time branches on top of usd branches, but i prefer what you suggest
<bluesabre> sil2100, based on your comment on the previous release, https://bugs.launchpad.net/ubuntu/+source/xubuntu-artwork/+bug/1794978/comments/2, can we get an ack on https://bugs.launchpad.net/ubuntu/+source/xubuntu-artwork/+bug/1820388 ?
<ubot5> Ubuntu bug 1794978 in xubuntu-artwork (Ubuntu) "[UIFe] New wallpaper for Xubuntu 18.10" [Undecided,Fix released]
<ubot5> Ubuntu bug 1820388 in xubuntu-artwork (Ubuntu) " [UIFe] New wallpaper for Xubuntu 19.04" [Undecided,New]
-queuebot:#ubuntu-release- New source: python-octavia-lib (disco-proposed/primary) [1.1.1-0ubuntu1]
<bluesabre> :)
<rbalint> juliank, the problem is that if most people just upload the branches become outdated
<bluesabre> (sorry for the nagging, the whole team is stretched thin and most of the team has become inactive or busy with life)
<jamespage> ^^ octavia-lib above is a new dep for networking-ovn for this release - apologies for the late-ish new upload
<sil2100> bluesabre: let me take a look in a minute o/
<rbalint> juliank, i'm adding the old branches and upload a converted git snapshot shortly
<rbalint> juliank, we can recreate the few missing uploads in ubuntu/{bionic}
<rbalint> {bionic}
<rbalint> {bionic|xenial|disco}
<rbalint> (other keyboard :-\)
<doko> Laney: why is openjdk-8 triggering the fdroidserver test?
<Laney> dunno, I can't look because I'm at a sprint, sorry
<Laney> depends or build-depends and build-needed or testsuite-triggers
<doko> ahh
<Laney> there's one thing where if there's an alternate dependency I don't think we ensure that the right one is installed
<Laney> like a | b, triggered by b, we don't make sure that b gets put on the system and you could end up with a
<doko> ohh crap, I see ...
<Laney> might be that bug you filed yesterday?
<doko> yep
<doko> or maybe I should file that upstream as well ...
<Laney> not aware of any direct support for that
<Laney> dunno if debian does anything there, probably not
<juliank> rbalint: yes, that's not a problem
-queuebot:#ubuntu-release- Unapproved: gradle (bionic-proposed/universe) [4.4.1-5~18.04 => 4.4.1-5~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gradle (cosmic-proposed/universe) [4.4.1-5~18.10 => 4.4.1-5~18.10.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gradle [sync] (bionic-proposed) [4.4.1-5~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gradle [sync] (cosmic-proposed) [4.4.1-5~18.10.1]
<jibel> kenvandine, seeding core18 broke desktop image builds cf bug 1820840
<ubot5> bug 1820840 in livecd-rootfs (Ubuntu) "[Disco] Ubuntu Desktop fails to build - snap-tool download: failed to get details for 'core18' in 'stable/ubuntu-19.04' on 'amd64': No revision was found in the Store. " [Critical,Confirmed] https://launchpad.net/bugs/1820840
-queuebot:#ubuntu-release- Unapproved: icedtea-web (bionic-proposed/universe) [1.6.2-3.1ubuntu3 => 1.8-0ubuntu8~18.04] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: icedtea-web (cosmic-proposed/universe) [1.6.2-3.1ubuntu3 => 1.8-0ubuntu8~18.10] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted icedtea-web [sync] (bionic-proposed) [1.8-0ubuntu8~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted icedtea-web [sync] (cosmic-proposed) [1.8-0ubuntu8~18.10]
<seb128> One other FFe we would like to see reviewed sooner than later if possible
<seb128> https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1820850
<ubot5> Ubuntu bug 1820850 in gnome-shell (Ubuntu) "[FFe] Distro patch GNOME hi-dpi support for x11 sessions" [High,New]
-queuebot:#ubuntu-release- New source: wslu (bionic-proposed/primary) [2.0.0-0ubuntu2~18.04.0]
-queuebot:#ubuntu-release- New source: wslu (xenial-proposed/primary) [2.0.0-0ubuntu2~16.04.0]
-queuebot:#ubuntu-release- New source: wslu (cosmic-proposed/primary) [2.0.0-0ubuntu2~18.10.0]
<cpaelzer> there is an FFe without ack/nack for a while https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1450588 - I think the case is quite simple, and was wondering if someone on the release Team could take a look at it
<ubot5> Ubuntu bug 1450588 in rsyslog (Ubuntu) "[FFe] /var/log/dmesg No Longer Being Updated" [Undecided,New]
<cpaelzer> vorlon: how does FFe assignment usually work in the release team?
<cpaelzer> anything I can do better on FFEs to help the release team?
<vorlon> cpaelzer: I basically don't have the bandwidth to chase up FFe bugs that get filed, so I only look at ones I get pinged about here
<vorlon> cpaelzer: "nine releases ago"?
<vorlon> we really care about this? :)
<vorlon> cpaelzer: but also, your "better safe than sorry" position causes unnecessary drag for you
<vorlon> so does anyone know why the daily Ubuntu image build is failing trying to find a stalbe/ubuntu-19.04 channel for the core snap? that seems wrong
<jibel> vorlon, because the track stable/ubutnu-19.04 is not available for core18 which has been seeded yesterday. kenvandine and mvo are on it
<vorlon> ah
<Eickmeyer> vorlon, infinity, anyone else: still waiting for an archive admin to review carla. Sorry to be such a pest, but I was told to be persistent.
<Eickmeyer> apw: ^?
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1041.45] (kernel)
<kenvandine> vorlon, jibel: mvo has created the stable/ubuntu-19.04 track
<vorlon> Eickmeyer: it's on my list, but the copyright/license information is complex enough to be annoying and I was going to look at tooling as part of the review
<vorlon> kenvandine, jibel: so you don't think it's an error to require a separate track for the core snap?  I would've thought we should treat the base snap specially
<Eickmeyer> vorlon: Understood. Is this in danger of missing beta freeze, or would this be an exception?
<kenvandine> vorlon: perhaps... but this will at least unblock it
<vorlon> Eickmeyer: I don't think it's at risk
<vorlon> kenvandine: ... fixing livecd-rootfs would also do that.  or reverting the seeding, because why are we directly seeding a base snap?
<Eickmeyer> vorlon: Okay, cool. I'm asking because I'd like to get it into the archives and patched to the 2.0.0 final release that happened on Sunday. [more]
<kenvandine> i assume core was treated differently in the past
<vorlon> kenvandine: core was never seeded, snapd handled that internally
<Eickmeyer> I have the patches ready to go, but I don't want to push anything until it's in the archives so I can just update it myself.
<vorlon> but now core18 is seeded, so livecd-rootfs doesn't know it's special
<kenvandine> vorlon: yeah, it doesn't for core18
<vorlon> and looks for the channel
<kenvandine> core is still required
<kenvandine> since core18 doesn't provide snapd
<kenvandine> so core18 requires core
<vorlon> uh
<kenvandine> eventually there will be a snapd snap
<kenvandine> so core18 + snapd snap will mean we don't need core
<vorlon> there already is a snapd snap
<kenvandine> i don't think it's ready for us to use that way
-queuebot:#ubuntu-release- Unapproved: keystone (cosmic-proposed/main) [2:14.0.1-0ubuntu2 => 2:14.0.1-0ubuntu3] (openstack, ubuntu-server)
<coreycb> hi all, can we have a look at accepting masakari-monitors from the disco NEW queue? this is a new openstack package in support of VM HA.
<didrocks> sil2100: hey again, did you see yesterday jibel's ping about desktop-canary image? Could it be copied in people.canonical.com so that we have access to it?
<sil2100> didrocks: ah, probably missed it, you mean the one that got built through cdimage but not published anywhere?
<didrocks> sil2100: exactly! We wanted to have it accessible somewhere, like maybe on people.canonical.com or so
<sil2100> Let me look into that quickly after teh meeting
<didrocks> thx!
<vorlon> mvo, kenvandine: hey, so currently livecd-rootfs blindly seeds the core snap in snap_prepare() - I wonder if we should be adjusting that to know about core vs. core18+snapd
<sil2100> didrocks: hmmm, so I guess for that I'd need a current build to be succeeding
<sil2100> didrocks: I see the latest ubuntu-canary livefs build failed, do you know why by any chance?
<sil2100> didrocks: should I kick a new build with the EXTRA_PPAS?
<didrocks> sil2100:the one before worked though? The current one will fail as the normal desktop image due to the core18 thingy above ^
<vorlon> mvo, kenvandine: I definitely think it's wrong for us to need an /ubuntu-19.04 track for the core18 snap, and for us to be seeding based on this track in the desktop images
<sil2100> didrocks: ah, hmmmmmm
<vorlon> kenvandine: and mvo has suggested that it might be possible now to use the snapd snap instead of the core snap
<sil2100> Ok
<kenvandine> vorlon: it would be great
-queuebot:#ubuntu-release- Unapproved: rejected hollywood [source] (cosmic-proposed) [1.15-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (cosmic-proposed) [2:14.0.1-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted openconnect [source] (cosmic-proposed) [7.08-3ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted openconnect [source] (bionic-proposed) [7.08-3ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted grilo-plugins [source] (cosmic-proposed) [0.3.8-2ubuntu1.1]
<rharper> bdmurray: hi, we've completed sru verification on our cloud-init SRU here, https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1819067  ; would appreciate a look when you can
<ubot5> Ubuntu bug 1819067 in cloud-init (Ubuntu Disco) "cloud-init SRU: 18.5-21-g8ee294d5-0ubuntu1 -> 18.5-45-g3554ffe8-0ubuntu1" [Undecided,Fix committed]
<bdmurray> cyphermox: Could you add a test case for receiving the prompt to bug 564843?
<ubot5> bug 573276 in gnome-settings-daemon (Ubuntu) "duplicate for #564843 gnome-settings-daemon crashed with SIGSEGV in g_type_check_instance()" [Medium,Expired] https://launchpad.net/bugs/573276
<bdmurray> er bug 564853
<ubot5> bug 564853 in grub2 (Ubuntu) "Spurious conffile prompts for /etc/default/grub" [Undecided,Fix released] https://launchpad.net/bugs/564853
<bdmurray> rharper: if its done why is the disco task still open?
<rharper> lemme check; it should be released; but I need to check the disco  bits
<rharper> bdmurray: it's in disco;  we didn't mark the task done
<bdmurray> rharper: okay
<rharper> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1819038/comments/4
<ubot5> Ubuntu bug 1819038 in cloud-init (Ubuntu) "[FFe] New upstream snapshot" [Undecided,Triaged]
<rharper> bdmurray: for context
<bdmurray> rharper: shouldn't that one be fix released too?
<rharper> yes, yes it should
-queuebot:#ubuntu-release- Unapproved: rejected gtk+3.0 [source] (cosmic-proposed) [3.24.4-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted parted [source] (bionic-proposed) [3.2-20ubuntu0.2]
-queuebot:#ubuntu-release- Unapproved: rejected ggcov [source] (bionic-proposed) [0.9+20190314-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-vpnaas [source] (bionic-proposed) [2:12.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (bionic-proposed) [2:12.0.5-0ubuntu1]
#ubuntu-release 2019-03-20
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.20 => 2.02~beta2-36ubuntu3.21] (core)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (trusty-proposed/main) [2.208.16 => 2.208.17] (desktop-core)
<tjaalton> any archive admin still around? linux-signed-oem is in bionic NEW and blocking testing
<tjaalton> still/already
<tjaalton> vorlon, infinity: you're probably only ones that might be still awake :)
<RAOF> infinity: The thought occurs that we didn't go over accepting from binary-NEW in the archive admin training... ð
<RAOF> The packages tjaalton is talking about look like they're destined for the correct pockets, and lintian is reasonably happy with them. I think they're correct to accept, and I think that pushing the button on LP would do the right thing. (and presumably `queue accept`, too).
<RAOF> So, I would accept them; but I won't do that until you tell me that there isn't a necessary check I've missed.
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1035.40]
<infinity> RAOF: Oh, I caught a ping in another channel and sorted it.
<infinity> RAOF: We should talk binary NEW at some point, yeah, but for kernel stuff, "people who do kernel stuff are meant to handle it" is the rule of thumb.
<infinity> Looks like Lukasz just missed a step.
<tjaalton> right
-queuebot:#ubuntu-release- Unapproved: dpdk (bionic-proposed/main) [17.11.3-3~ubuntu0.18.04 => 17.11.5-0~ubuntu18.04.1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: dpdk (cosmic-proposed/main) [17.11.3-3 => 17.11.5-0~ubuntu18.10.1] (kubuntu, ubuntu-desktop, ubuntu-server)
<LocutusOfBorg> can anybody please kick them out?
<LocutusOfBorg> missing build on arm64: libceres-dev, libceres1 (from 1.13.0+dfsg0-2build1)
<LocutusOfBorg> missing build on ppc64el: libceres-dev, libceres1 (from 1.13.0+dfsg0-2build1)
<LocutusOfBorg> (probably colmap on ppc64el has to go too)
<LocutusOfBorg> debian already removed, not sure why nobody picked them up yet :)
<LocutusOfBorg> apw, maybe I can abuse of your time? I'm really trying to let something migrate from the proposed pocket
<LocutusOfBorg> I made a script that looks for stuff in proposed that has a new version in debian unstable, and I'm manually syncing what is fixed in Debian
-queuebot:#ubuntu-release- New binary: ruby-chromedriver-helper [amd64] (disco-proposed/universe) [2.1.0-6ubuntu2] (no packageset)
<LocutusOfBorg> this one should unblock lots of ruby proposed packages ^^
<LocutusOfBorg> not sure why it fails testsuite on pbuilder, and not on sbuild, some network restriction, there is an associated debian RC bug
<LocutusOfBorg> also, please remove freecad on armhf, already removed by debian
<LocutusOfBorg> also please bump debci hint to 2.0
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.18.0-1014.14~18.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: geogebra (bionic-proposed/universe) [4.0.34.0+dfsg1-4 => 4.0.34.0+dfsg1-6~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted geogebra [sync] (bionic-proposed) [4.0.34.0+dfsg1-6~18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (trusty-proposed/main) [4.15.0-1041.45~14.04.1] (kernel)
-queuebot:#ubuntu-release- New source: linux-restricted-modules (disco-proposed/primary) [5.0.0-8.9]
<apw> vorlon, ^ you are likley the most aware of that one
<oSoMoN> dear release team:Â I'm considering adding gstreamer1.0-gtk3 as a recommends of libreoffice-avmedia-backend-gstreamer to fix bug #1820062. libreoffice-avmedia-backend-gstreamer is in main, whereas gstreamer1.0-gtk3 is in universe, but its source package itself is in main (gst-plugins-good1.0). Is that acceptable, and would that require a FFe? (seb_128 suggested it would)
<ubot5> bug 1820062 in libreoffice (Ubuntu) "LibreOffice Impress embed video problem (libreoffice-gtk3)" [High,Confirmed] https://launchpad.net/bugs/1820062
<jamespage> bdmurray: hey - I revisited the testing of bug 1813807 - we had a bit of a test misconfiguration in terms of user setup which I've corrected
<ubot5> bug 1813807 in Ubuntu Cloud Archive pike "[SRU] ceph 12.2.11" [Medium,Triaged] https://launchpad.net/bugs/1813807
<jamespage> unrelated to the packages actually being SRU's but now resolved more generally
<bdmurray> jamespage: cool, I'll have a look
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.18.0-1014.14~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (cosmic-proposed) [4.18.0-1008.9]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1041.45]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (cosmic-proposed) [4.18.0-1014.14]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (trusty-proposed) [4.15.0-1041.45~14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted resolvconf [source] (cosmic-proposed) [1.79ubuntu10.18.10.3]
-queuebot:#ubuntu-release- Unapproved: accepted resolvconf [source] (bionic-proposed) [1.79ubuntu10.18.04.3]
-queuebot:#ubuntu-release- New: rejected intel-mediasdk [source] (disco-proposed) [18.4.1-0ubuntu1]
#ubuntu-release 2019-03-21
-queuebot:#ubuntu-release- Unapproved: iproute2 (bionic-backports/main) [4.15.0-2ubuntu1 => 4.18.0-1ubuntu2~ubuntu18.04.1] (core)
<oSoMoN> good morning
<oSoMoN> asking again a question that remained without an answer yesterday:
<oSoMoN> I'm considering adding gstreamer1.0-gtk3 as a recommends of libreoffice-avmedia-backend-gstreamer to fix bug #1820062. libreoffice-avmedia-backend-gstreamer is in main, whereas gstreamer1.0-gtk3 is in universe, but its source package itself is in main (gst-plugins-good1.0). Is that acceptable, and would that require a FFe? (seb_128 suggested it would)
<ubot5> bug 1820062 in libreoffice (Ubuntu) "LibreOffice Impress embed video problem (libreoffice-gtk3)" [High,Confirmed] https://launchpad.net/bugs/1820062
<oSoMoN> in fact it should be added as a recommend of libreoffice-gtk3, that's more correct (and that's what is done in debian now: https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/a7307bd4d2ab671a47573e8b9b8f78a295e223e5)
<oSoMoN> but the idea and implications are the same
<oSoMoN> Laney, sil2100: can you enlighten me? ^
-queuebot:#ubuntu-release- Unapproved: libunistring (bionic-proposed/main) [0.9.9-0ubuntu1 => 0.9.9-0ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: libidn (bionic-proposed/main) [1.33-2.1ubuntu1.1 => 1.33-2.1ubuntu1.2] (core)
<LocutusOfBorg> sil2100, ^^ sorry for reverting your libidn upload ^^
<Laney> oSoMoN: If it's fine to promote (should be), I think it should be fine to add those recommends - it's a couple of new sinks so shouldn't affect things that don't opt in to those
<Laney> obviously it'd be good to watch out for it being buggy in any way
<oSoMoN> Laney, do you reckon that warrants a FFe ?
<Laney> arguably, but feel free to just paste this into the bug I think
<Laney> maybe check with d_idrocks or another archive admin that they'd be OK with promoting the package first
<oSoMoN> didrocks, your opinion welcome ^
<sil2100> oSoMoN, Laney: since the source is in main I'd be fine to promote the binary to main if needed
<oSoMoN> ah, thanks sil2100
 * sil2100 checks the binary real quick
-queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu7.10 => 1:2.11+dfsg-1ubuntu7.11] (ubuntu-server, virt)
<didrocks> oSoMoN: sure, I can promote that package, I'm still warry about binary promotion because sometimes MIRs are about "we can promote that part, but not that part", and this is lost in time, but as we have a maintainer (you!), I'm ok with promoting :)
<didrocks> oSoMoN: just tell me when it hits proposed and I'll promote it
<oSoMoN> excellent, thanks
<sil2100> LocutusOfBorg: that's fine, I backported the fix from cosmic/disco since it was easier
<didrocks> it == libreoffice-gtk3
<LocutusOfBorg> sil2100, yes, I just see the overlinking as "regression", and now we have a proper fix by upstream I hope you can process both libidn and libunistring even if the end user won't be affected that much (meh, it will gain some size on his system!)
-queuebot:#ubuntu-release- New binary: pygnuplot [amd64] (disco-proposed/universe) [0.11.16-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-tesserocr [amd64] (disco-proposed/universe) [2.4.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: python-tesserocr [s390x] (disco-proposed/universe) [2.4.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: python-tesserocr [i386] (disco-proposed/universe) [2.4.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: python-tesserocr [armhf] (disco-proposed/universe) [2.4.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: python-tesserocr [ppc64el] (disco-proposed/universe) [2.4.0-4] (no packageset)
<LocutusOfBorg> I hope to solve the ruby madness in -proposed soon
<rbalint> sil2100, could you please take a look at the wslu packages in NEW ?
<rbalint> (in your sru cycles)
<sil2100> rbalint: is that for disco, or stable series?
-queuebot:#ubuntu-release- New: accepted pygnuplot [amd64] (disco-proposed) [0.11.16-2]
<rbalint> sil2100, for all stable releases
-queuebot:#ubuntu-release- New: accepted python-tesserocr [amd64] (disco-proposed) [2.4.0-4]
-queuebot:#ubuntu-release- New: accepted python-tesserocr [i386] (disco-proposed) [2.4.0-4]
-queuebot:#ubuntu-release- New: accepted python-tesserocr [s390x] (disco-proposed) [2.4.0-4]
-queuebot:#ubuntu-release- New: accepted python-tesserocr [armhf] (disco-proposed) [2.4.0-4]
-queuebot:#ubuntu-release- New: accepted ruby-chromedriver-helper [amd64] (disco-proposed) [2.1.0-6ubuntu2]
-queuebot:#ubuntu-release- New: accepted python-tesserocr [ppc64el] (disco-proposed) [2.4.0-4]
<sil2100> rbalint: on it!
-queuebot:#ubuntu-release- Unapproved: accepted iproute2 [source] (bionic-backports) [4.18.0-1ubuntu2~ubuntu18.04.1]
<sil2100> Laney: thanks!
<sil2100> abeato: ^
<abeato> sil2100, \o/
<Laney> ð
<LocutusOfBorg> please "decruft" knot-resolver ("libkres-dev, libkres9") NBS in proposed
<LocutusOfBorg> also, knot-resolver on arm64 has to go away (removed in debian too)
-queuebot:#ubuntu-release- New: accepted wslu [source] (cosmic-proposed) [2.0.0-0ubuntu2~18.10.0]
-queuebot:#ubuntu-release- New binary: wslu [amd64] (cosmic-proposed/none) [2.0.0-0ubuntu2~18.10.0] (no packageset)
-queuebot:#ubuntu-release- New: accepted wslu [source] (bionic-proposed) [2.0.0-0ubuntu2~18.04.0]
-queuebot:#ubuntu-release- New binary: wslu [amd64] (bionic-proposed/none) [2.0.0-0ubuntu2~18.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (cosmic-proposed/main) [2.37.4+18.10.1 => 2.38+19.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted wslu [source] (xenial-proposed) [2.0.0-0ubuntu2~16.04.0]
-queuebot:#ubuntu-release- New binary: wslu [amd64] (xenial-proposed/none) [2.0.0-0ubuntu2~16.04.0] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-144.170~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-144.170~14.04.1]
<leosilva> hi kstenerud, we have some CVEs that affects php7.2 and we were discussing if it is too late to update 7.2 to a whole new version for disco. What are your thoughts?
-queuebot:#ubuntu-release- New: accepted wslu [amd64] (bionic-proposed) [2.0.0-0ubuntu2~18.04.0]
-queuebot:#ubuntu-release- New: accepted wslu [amd64] (cosmic-proposed) [2.0.0-0ubuntu2~18.10.0]
-queuebot:#ubuntu-release- New: accepted wslu [amd64] (xenial-proposed) [2.0.0-0ubuntu2~16.04.0]
<kstenerud> leosilva: do you mean going to 7.3?
<kstenerud> or 7.2.16 (the latest)
<kstenerud> actually 7.2.17rc1 is latest
<leosilva> kstenerud: 7.2.16
<kstenerud> I can give it a go. 7.2.15 was a pain, but maybe 16 wasn't that big of a change...
<leosilva> kstenerud: cool, let me know if everything goes right, so I can steal your tarball for bionic and cosmic :)
<kstenerud> sure :)
<leosilva> tks!
-queuebot:#ubuntu-release- Unapproved: gradle (bionic-proposed/universe) [4.4.1-5~18.04.1 => 4.4.1-5ubuntu2~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gradle (cosmic-proposed/universe) [4.4.1-5~18.10.1 => 4.4.1-5ubuntu2~18.10] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (xenial-proposed/main) [1.66.20 => 1.66.21] (core)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-edge [amd64] (bionic-proposed/main) [4.18.0-1008.9~18.04.1] (kernel)
-queuebot:#ubuntu-release- New source: openjdk-11 (disco-proposed/primary) [11.0.3+4-1]
-queuebot:#ubuntu-release- New: rejected openjdk-11 [source] (disco-proposed) [11.0.3+4-1]
-queuebot:#ubuntu-release- New binary: gcc-9 [s390x] (disco-proposed/main) [9-20190321-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1010.12] (kernel)
-queuebot:#ubuntu-release- New: accepted gcc-9 [s390x] (disco-proposed) [9-20190321-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gradle [sync] (bionic-proposed) [4.4.1-5ubuntu2~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted gradle [sync] (cosmic-proposed) [4.4.1-5ubuntu2~18.10]
-queuebot:#ubuntu-release- New binary: gcc-9 [i386] (disco-proposed/main) [9-20190321-1ubuntu1] (core)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-edge [amd64] (bionic-proposed) [4.18.0-1008.9~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1010.12]
-queuebot:#ubuntu-release- Unapproved: health-check (bionic-proposed/universe) [0.02.09-1 => 0.02.09-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gcc-9 [i386] (disco-proposed) [9-20190321-1ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [4.15.0-1029.31] (kernel)
-queuebot:#ubuntu-release- Unapproved: libmbim (bionic-proposed/main) [1.14.2-2.1ubuntu1 => 1.18.0-1~ubuntu18.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: modemmanager (bionic-proposed/main) [1.6.8-2ubuntu1 => 1.10.0-1~ubuntu18.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libqmi (bionic-proposed/main) [1.18.0-3ubuntu1 => 1.22.0-1.3~ubuntu18.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected nova [sync] (bionic-proposed) [2:17.0.7-0ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (bionic-proposed) [2:17.0.9-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected swift [source] (bionic-proposed) [2.17.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: swift (bionic-proposed/main) [2.17.0-0ubuntu1 => 2.17.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted swift [source] (bionic-proposed) [2.17.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1029.31]
-queuebot:#ubuntu-release- Unapproved: plymouth (cosmic-proposed/main) [0.9.3-1ubuntu10 => 0.9.3-1ubuntu10.1] (core)
<vorlon> xnox: webkit2gtk v. sphinx?
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (cosmic-proposed) [2.02+dfsg1-5ubuntu8.3]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (cosmic-proposed) [1.110.3]
-queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02+dfsg1-5ubuntu8.3 => 2.02+dfsg1-5ubuntu8.3] (core)
-queuebot:#ubuntu-release- Unapproved: linux-firmware (bionic-proposed/main) [1.173.3 => 1.173.5] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: linux-firmware (cosmic-proposed/main) [1.175.1 => 1.175.3] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02+dfsg1-5ubuntu8.3 => 2.02+dfsg1-5ubuntu8.3] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (bionic-proposed) [2.02-2ubuntu8.13]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (bionic-proposed) [1.93.14]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.21]
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.13 => 2.02-2ubuntu8.13] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.21 => 2.02~beta2-36ubuntu3.21] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.13 => 2.02-2ubuntu8.13] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.21 => 2.02~beta2-36ubuntu3.21] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (xenial-proposed) [1.66.21]
<jbicha> vorlon: that's https://bugs.webkit.org/show_bug.cgi?id=195455 I guess we should have filed an Ubuntu bug for it too
<ubot5> bugs.webkit.org bug 195455 in WebKitGTK "REGRESSION [GTK] 2.23.92 ppc64el and s390x crashes" [Normal,New]
<vorlon> jbicha: sure; I was highlighting xnox on it because there was discussion during Foundations team meeting about the sphinx autopkgtest failures and what to do with them
<jbicha> I've made sure the webkitgtk upstream guys know about the bug
<jbicha> (I pinged them separately about it)
<xnox> jbicha, ok thank you. So to recap our meeting. We see that sphinx has autopkgtest, which tests that generated documentation has operatable js (which is arch:all) and it tests that, well everywhere. The docs are clearly fine, because it does pass on ![ppc64el s390x] and sphinx has not moved. So what should we do? make sphinx skip and/or report xfail on s390x/ppc64le for now?
<xnox> jbicha, or do we want to continue blocking webkit2gtk migration?
<xnox> jbicha, or do we want to remove webkit2gtk from ppc64le/s390x pending it's reinclusion?
<xnox> jbicha, or do we want to let webkit2gtk migrate, abeit knowngly broken on ppc64le/s390x?
<xnox> jbicha, i also noticed that webkit2gtk does not run unittests (even though, i believe it could do that) is that on purpose? ( as in are they like timing sensitive, non-passing, unreliable, etc?)
<xnox> jbicha, i was meant to write an email, but i guess we'll have to do that on irc now.
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (cosmic-proposed) [2.02+dfsg1-5ubuntu8.3]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (cosmic-proposed) [2.02+dfsg1-5ubuntu8.3]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (bionic-proposed) [2.02-2ubuntu8.13]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (xenial-proposed) [2.02~beta2-36ubuntu3.21]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (bionic-proposed) [2.02-2ubuntu8.13]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (xenial-proposed) [2.02~beta2-36ubuntu3.21]
-queuebot:#ubuntu-release- New binary: rustc [amd64] (disco-proposed/universe) [1.32.0+dfsg1+llvm-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [s390x] (disco-proposed/universe) [1.32.0+dfsg1+llvm-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [ppc64el] (disco-proposed/universe) [1.32.0+dfsg1+llvm-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [i386] (disco-proposed/universe) [1.32.0+dfsg1+llvm-1ubuntu1] (no packageset)
#ubuntu-release 2019-03-22
<jbicha> xnox: why the rush to ignore the regression?
<jbicha> Debian Buster needs the regression fixed too
<jbicha> sorry, I didn't realize that webkit2gtk was skipping dh_auto_test
<xnox> jbicha, there is no rush. it's just on our report it appeared as if "foundations responsible package sphinx, is preventing desktop package to migrate" it's entirely up to you when/how to deal with it =)
<jbicha> merge requests welcome if you figure it out
<xnox> jbicha, hence in our weekly call, we looked deeper into it.
<jbicha> *figure out dh_auto_test
<xnox> jbicha, and we hate to block people.
<jbicha> it's too bad webkit doesn't use git yet, someone could dig through https://trac.webkit.org/log/webkit/releases/WebKitGTK/webkit-2.24 ð¢
<xnox> ouch
-queuebot:#ubuntu-release- Unapproved: gnome-software (bionic-proposed/main) [3.28.1-0ubuntu4.18.04.8 => 3.28.1-0ubuntu4.18.04.9] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: rustc [armhf] (disco-proposed/universe) [1.32.0+dfsg1+llvm-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [arm64] (disco-proposed/universe) [1.32.0+dfsg1+llvm-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.37.4ubuntu0.1 => 2.38] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.37.4+18.04.1 => 2.38+18.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (cosmic-proposed/main) [2.37.4+18.10.1 => 2.38+18.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/main) [2.37.4~14.04.1 => 2.38~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected linux-firmware [source] (cosmic-proposed) [1.175.2]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (cosmic-proposed) [2.38+19.04]
-queuebot:#ubuntu-release- Unapproved: accepted snapd-glib [source] (cosmic-proposed) [1.47-0ubuntu0.18.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted snapd-glib [source] (bionic-proposed) [1.47-0ubuntu0.18.04.0]
-queuebot:#ubuntu-release- New binary: snapd-glib [s390x] (cosmic-proposed/main) [1.47-0ubuntu0.18.10.0] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: snapd-glib [amd64] (cosmic-proposed/main) [1.47-0ubuntu0.18.10.0] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: snapd-glib [ppc64el] (cosmic-proposed/main) [1.47-0ubuntu0.18.10.0] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted snapd-glib [source] (xenial-proposed) [1.47-0ubuntu0.16.04.0]
<LocutusOfBorg> please remove thunderbird testsuite package to let it migrate, NBS in proposed!
-queuebot:#ubuntu-release- New binary: snapd-glib [s390x] (bionic-proposed/main) [1.47-0ubuntu0.18.04.0] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: snapd-glib [amd64] (bionic-proposed/main) [1.47-0ubuntu0.18.04.0] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: snapd-glib [i386] (bionic-proposed/main) [1.47-0ubuntu0.18.04.0] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: snapd-glib [arm64] (cosmic-proposed/main) [1.47-0ubuntu0.18.10.0] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: snapd-glib [amd64] (xenial-proposed/main) [1.47-0ubuntu0.16.04.0] (no packageset)
-queuebot:#ubuntu-release- New binary: snapd-glib [ppc64el] (bionic-proposed/main) [1.47-0ubuntu0.18.04.0] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: snapd-glib [s390x] (xenial-proposed/main) [1.47-0ubuntu0.16.04.0] (no packageset)
-queuebot:#ubuntu-release- New binary: snapd-glib [armhf] (cosmic-proposed/main) [1.47-0ubuntu0.18.10.0] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: snapd-glib [ppc64el] (xenial-proposed/main) [1.47-0ubuntu0.16.04.0] (no packageset)
-queuebot:#ubuntu-release- New binary: snapd-glib [armhf] (bionic-proposed/main) [1.47-0ubuntu0.18.04.0] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: snapd-glib [powerpc] (xenial-proposed/main) [1.47-0ubuntu0.16.04.0] (no packageset)
-queuebot:#ubuntu-release- New binary: snapd-glib [i386] (xenial-proposed/main) [1.47-0ubuntu0.16.04.0] (no packageset)
<mvo> tjaalton: thanks for rejecting incorrect snapd upload some minutes ago - I had indeed mixed up the changelog version. sorry for that
-queuebot:#ubuntu-release- New binary: snapd-glib [arm64] (bionic-proposed/main) [1.47-0ubuntu0.18.04.0] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: snapd-glib [armhf] (xenial-proposed/main) [1.47-0ubuntu0.16.04.0] (no packageset)
<tjaalton> mvo: :)
<tjaalton> I noticed the correct one had just arrived on the queue
-queuebot:#ubuntu-release- New binary: snapd-glib [arm64] (xenial-proposed/main) [1.47-0ubuntu0.16.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (cosmic-proposed) [0.96-0ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (bionic-proposed) [0.96-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted plymouth [source] (cosmic-proposed) [0.9.3-1ubuntu10.1]
-queuebot:#ubuntu-release- Unapproved: accepted libxkbcommon [source] (bionic-proposed) [0.8.2-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New binary: libxkbcommon [amd64] (bionic-proposed/main) [0.8.2-1~ubuntu18.04.1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: accepted gvfs [source] (bionic-proposed) [1.36.1-0ubuntu1.3.1]
<ginggs> can we consider hint python-scipy and scikit-learn?  both autopkgtests pass for me locally on amd64
-queuebot:#ubuntu-release- New: accepted rustc [amd64] (disco-proposed) [1.32.0+dfsg1+llvm-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [armhf] (disco-proposed) [1.32.0+dfsg1+llvm-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [ppc64el] (disco-proposed) [1.32.0+dfsg1+llvm-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [arm64] (disco-proposed) [1.32.0+dfsg1+llvm-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [s390x] (disco-proposed) [1.32.0+dfsg1+llvm-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [i386] (disco-proposed) [1.32.0+dfsg1+llvm-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected linux-firmware [source] (bionic-proposed) [1.173.4]
-queuebot:#ubuntu-release- Unapproved: accepted glib2.0 [source] (bionic-proposed) [2.56.4-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xfwm4 [source] (bionic-proposed) [4.12.5-1ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.20]
-queuebot:#ubuntu-release- Unapproved: glib2.0 (bionic-proposed/main) [2.56.4-0ubuntu0.18.04.1 => 2.56.4-0ubuntu0.18.04.2] (core)
<Laney> tjaalton: thanks for glib2.0, but it failed to build on i386/s390x - would you be able to review this one quickly please? just two cherry-picks from upstream to fix that (https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3685/+packages shows they work)
<tjaalton> Laney: sure
<Laney> merci
-queuebot:#ubuntu-release- Unapproved: accepted glib2.0 [source] (bionic-proposed) [2.56.4-0ubuntu0.18.04.2]
<Laney> ð¤ 
-queuebot:#ubuntu-release- Unapproved: xdg-desktop-portal (bionic-proposed/universe) [1.0.3-0ubuntu0.1 => 1.0.3-0ubuntu0.2] (ubuntugnome)
<xnox> Laney, infinity, vorlon - it seems like htere was proxy error whilst trying to download squashfs out of a launchpad build....
<xnox> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/disco/daily-live-20190322.log
<xnox> https://launchpadlibrarian.net/416090788/livecd.ubuntu-server.installer.squashfs:
<xnox> 2019-03-22 07:54:09 ERROR 502: Proxy Error.
<xnox> should we like retry that whole build?
<xnox> can you like run the build without '--live' such that it redownloads existing squashfs, and remasters them?
<xnox> without installer.squashfs, we will really not installer today....
<xnox> anyway, requested the amd64 rebuild via the iso tracker
<LocutusOfBorg> vorlon, --> please remove thunderbird testsuite package to let it migrate, NBS in proposed! and then you can remove llvm-toolchain-4.0
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1816736
<ubot5`> Ubuntu bug 1816736 in thunderbird (Ubuntu) "llvm-toolchain-4.0: Remove from disco" [Undecided,Fix committed]
<Eickmeyer> vorlon: As beta freeze is Monday, may I check on the status of carla?
<LocutusOfBorg> doko, ^^ can you please remove llvm-toolchain-4.0 and let thundebird finally migrate?
<Laney> xnox has iso tracker rebuild permissions?
<Laney> TIL
<xnox> Laney, for some products only, ie. subiquity.
<Laney> so that build succeeded but one of the squashfses failed to download?
<xnox> Laney, the 22$ build yeah, livefs build is good, debian-cd download squashfs bad, failed to download 3 squashfs due to proxy error, and it simply carried on with rolling the .iso and claiming it's good enough
<Laney> bloop
<xnox> 22.1 looks good, in terms of download... let's wait and see what jenkins/utah tell us.
<vorlon> xnox: so the 20190322 build spit out an image but was missing a squashfs?  probably needs something fixed in ubuntu-cdimage to treat that as an error
<xnox> vorlon, right, i think i missfiled a bug report then. It should be against ubuntu-cdimage, let me retarget it
<xnox> vorlon, https://bugs.launchpad.net/ubuntu-cdimage/+bug/1821356
<ubot5`> Ubuntu bug 1821356 in Ubuntu CD Images "false positive builds server subiquity images" [Undecided,New]
<vorlon> LocutusOfBorg: thunderbird-testsuite, llvm-toolchain-4.0 sorted
<LocutusOfBorg> vorlon, <3
<LocutusOfBorg> doko, do you have a list of build failures similar to this one? https://bugs.launchpad.net/ubuntu/+source/prelude-lml/+bug/1803320 I want to fix them all
<ubot5`> Ubuntu bug 1803320 in prelude-lml (Ubuntu) "prelude-lml ftbfs in disco" [Undecided,Fix released]
<vorlon> Eickmeyer: carla: I'm planning to get to it today; if I don't, I'm off work after today for a week so you probably will want to grab another AA to look at it
<Laney> vorlon: you too?
<Laney> Guess autopkgtest is juliank and sil2100's for a week then :>
-queuebot:#ubuntu-release- Unapproved: grub2 (trusty-proposed/main) [2.02~beta2-9ubuntu1.16 => 2.02~beta2-9ubuntu1.17] (core)
<vorlon> indeed
<juliank> oh no
-queuebot:#ubuntu-release- New binary: prelude-lml [ppc64el] (disco-proposed/universe) [4.1.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: prelude-lml [s390x] (disco-proposed/universe) [4.1.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: prelude-lml [amd64] (disco-proposed/universe) [4.1.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: prelude-lml [armhf] (disco-proposed/universe) [4.1.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: prelude-lml [arm64] (disco-proposed/universe) [4.1.0-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: prelude-lml [i386] (disco-proposed/universe) [4.1.0-2ubuntu1] (no packageset)
<Eickmeyer> vorlon: Okay.
-queuebot:#ubuntu-release- New binary: gcc-9-cross [amd64] (disco-proposed/main) [4ubuntu1] (ubuntu-desktop)
<doko> LocutusOfBorg: no
-queuebot:#ubuntu-release- New: accepted gcc-9-cross [amd64] (disco-proposed) [4ubuntu1]
-queuebot:#ubuntu-release- New: accepted prelude-lml [arm64] (disco-proposed) [4.1.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted prelude-lml [i386] (disco-proposed) [4.1.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted prelude-lml [s390x] (disco-proposed) [4.1.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted prelude-lml [amd64] (disco-proposed) [4.1.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted prelude-lml [ppc64el] (disco-proposed) [4.1.0-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted prelude-lml [armhf] (disco-proposed) [4.1.0-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (bionic-proposed) [1:0.5.2.3]
-queuebot:#ubuntu-release- Unapproved: shadow (xenial-proposed/main) [1:4.2-3.1ubuntu5.3 => 1:4.2-3.1ubuntu5.4] (core)
-queuebot:#ubuntu-release- Unapproved: shadow (bionic-proposed/main) [1:4.5-1ubuntu1 => 1:4.5-1ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (trusty-proposed/main) [1.34.18 => 1.34.19] (core)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1001.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1001.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: shadow (xenial-proposed/main) [1:4.2-3.1ubuntu5.3 => 1:4.2-3.1ubuntu5.4] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (trusty-proposed) [2.02~beta2-9ubuntu1.17]
-queuebot:#ubuntu-release- Unapproved: shadow (bionic-proposed/main) [1:4.5-1ubuntu1 => 1:4.5-1ubuntu2] (core)
<mvo> sorry for the double upload of shadow - the first just contans "userdel --extrausers" but while going over the things we had to fix for Ubuntu Core I noticed there were some more fixes worth SRUing, hence the second update
-queuebot:#ubuntu-release- Unapproved: grub2 (trusty-proposed/main) [2.02~beta2-9ubuntu1.17 => 2.02~beta2-9ubuntu1.17] (core)
-queuebot:#ubuntu-release- Unapproved: rejected shadow [source] (xenial-proposed) [1:4.2-3.1ubuntu5.4]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (trusty-proposed) [1.34.19]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (cosmic-proposed) [1.175.3]
<ahasenack> hi release team, could someone please badtest autofs in disco? https://code.launchpad.net/~ahasenack/britney/autofs-badtest-cifs-bug/+merge/364988
<ahasenack> it's a real bug, but not yet fixed in the kernel we have
<ahasenack> or, if you prefer, I could change the autofs test to *not* use SMB3.11 when using cifs and a guest mount, but by having that test as is is what allowed us to find that bug
<vorlon> ahasenack: does the bug not represent a regression at runtime between autofs 5.1.2-4ubuntu2 and the new samba?
<ahasenack> vorlon: no
<ahasenack> vorlon: and I have proof
<ahasenack> autofs passwd with previous rc4 and 4.19 kernel
<ahasenack> fails with 5.0 kernel
<ahasenack> and I don't need autofs to show the bug
<vorlon> ahasenack: so if we retested autofs with the disco version of autofs, we'd see the same failure now that 5.0 is in?
<ahasenack> the autofs test is correctly failinh
<ahasenack> yes
<vorlon> ok
<ahasenack> I also have confirmation in the cifs-devel mailing list
<vorlon> it is preferable to retrigger the autopkgtests so that this is visible in the log; I'm doing this now
<ahasenack> vorlon: https://lore.kernel.org/linux-cifs/CANYNYEH3qVQA_05H-FeJdRgQe81O8gaULXuCGz42e_nKVgMnkg@mail.gmail.com/T/#m3bef710c4ec39be849f2684fbb85183f988dae38
<vorlon> retry-autopkgtest-regressions --blocks samba --no-proposed  | xargs -rn1 -P10 wget --load-cookies ~/.cache/autopkgtest.cookie -O-
<vorlon> ahasenack: yep, acceptable rationale, I just prefer it to be self-documenting on autopkgtest.u.c
<vorlon> so once those test results come in, I'll merge your hint
<ahasenack> vorlon: is this just a new run? What will be different in the log, other than you triggered it?
<ahasenack> vorlon: the samba dep8 tests also include a cifs mount test, but only an authenticated one, not a guest one. autofs tests both
-queuebot:#ubuntu-release- New binary: gcc-9-cross-ports [amd64] (disco-proposed/universe) [3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.16 => 237-3ubuntu10.17] (core)
<vorlon> ahasenack: what is different is --no-proposed, so that they are run against the devel version of samba instead of the -proposed version
<vorlon> ahasenack: but none of the results are showing up for me yet on the web ui :P
<ahasenack> vorlon: ah, ok
<ahasenack> vorlon: it's there now, or did you mean somewhere else? http://autopkgtest.ubuntu.com/packages/a/autofs/disco/amd64
<ahasenack> (I was afk, came back now)
<vorlon> ahasenack: heh, I was looking at ppc64el and s390x which are normally fastest to finish
<vorlon> but those just showed up too
<ahasenack> that surprised me today, seeing s390x finishing first
<vorlon> ahasenack: and hint added
<ahasenack> thanks!
<ahasenack> vorlon: I'll find some time to test the kernel patch provided in the list. They said it fixed it for them, but just that patch on our kernel doesn't fix it. They asked to test one of those for-next git branches kernel people have, which is ahead of ours
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (cosmic-proposed) [2.38+18.10]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.38+18.04]
-queuebot:#ubuntu-release- New: accepted gcc-9-cross-ports [amd64] (disco-proposed) [3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.38]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.38~14.04]
<vorlon> Eickmeyer: licensecheck disagrees with you about the license of source/modules/hylia/link/AudioEngine.* and source/modules/hylia/link/ableton/* in carla; your debian/copyright says they're BSL-1, licensecheck reports that they are GPL-2+
<vorlon> Eickmeyer: (this is by virtue of the stanza starting at line 48, which matches all files under that directory recursively, and is the most specific match for these files)
<vorlon> Eickmeyer: and you have conflicting declarations for source/modules/dgl/*, which is listed as both public-domain-with-attribution and ISC
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (trusty-proposed) [2.02~beta2-9ubuntu1.17]
#ubuntu-release 2019-03-23
<vorlon> Eickmeyer: and the stanza for source/modules/lilv/serd-0.24.0/tests/TurtleTests/LICENSE is wrong, it should be listed as the license for the other files in that directory, not for the LICENSE file itself ;)
-queuebot:#ubuntu-release- Unapproved: android-platform-tools-apksig (bionic-proposed/universe) [0.8-2~18.04 => 0.8-2ubuntu1~18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: android-platform-tools-apksig (cosmic-proposed/universe) [0.8-2~18.04 => 0.8-2ubuntu1~18.04] (no packageset) (sync)
<tdaitx> I would highly appreciate if anyone with the right powers want to approve android-platform-tools-apksig  0.8-2ubuntu1~18.04 copied from ppa:openjdk-11-transition/android-tools to bionic-proposed and cosmic-proposed
<tdaitx> the bug fix is https://launchpad.net/bugs/1821235 and it just updated the '-source 8' to '--release 8' so that java classes are actually compatible with openjdk 8 runtime
<ubot5`> Ubuntu bug 1821235 in android-platform-tools-apksig (Ubuntu) "java.lang.UnsupportedClassVersionError: com/android/apksigner/ApkSignerTool has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0" [Undecided,New]
<Eickmeyer> vorlon: I'll go ahead and make those fixes.
<Eickmeyer> vorlon: Eliminated the stanza at line 48, since the entire Hylia project is done by falktx as well. I don't know why it was attributed to Ableton AG.
<Eickmeyer> vorlon: As such, I also edited the stanza at line 10.
<Eickmeyer> vorlon: Pushed changes, however, as I realize you're on vacation, I'll have to bug others now.
<Eickmeyer> apw, infinity, RAOF, cjwatson stgraber? Anybody wanna take a crack at carla? It's in the NEW queue, but I just pushed changes to https://launchpad.net/carla for the copyright file errors vorlon mentioned above.
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1001.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1001.1]
<vorlon> Eickmeyer: one last discrepancy, source/modules/rtmidi shows up as MIT/X11 license but is not documented such in debian/copyright
<vorlon> Eickmeyer: otherwise, I've confirmed that all the licenses listed in the source are GPL-compatible, so this looks distributable; if you can fix that last missing copyright/license statement, I can re-sponsor and accept
<Eickmeyer> vorlon: I'm on it.
<Eickmeyer> vorlon: Done, tags pushed.
#ubuntu-release 2019-03-24
<tsimonq2> Nice, for perl to migrate, only its own autopkgtests need to pass, which are probably going to require a patch, that triggers all of the tests again. :P
 * tsimonq2 tries to repro the failure on porterboxes first.
<tsimonq2> "opening NDBM file failed: No such file or directory at -e line 1." I wonder why it was blindly retried three times. :P
<tsimonq2> ahhhh
<tsimonq2> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925179
<ubot5`> Debian bug 925179 in perl "perl: autopkgtest failures on arm64, ppc64el and s390x: NDBM backwards binary compatibility" [Important,Open]
<vorlon> coreycb: fyi, 'lintian masakari-monitors*changes' detects that the autopkgtests are broken because the test name in debian/tests/control doesn't match the name of the script in the directory
<vorlon> coreycb: init scripts, huh
<vorlon> coreycb: except not really init scripts, because they do nothing except define some variables...
<vorlon> coreycb: and debian/masakarimonitors_sudoers looks very wrong, there is no /usr/bin/privsep-helper in Ubuntu AFAICS
<tsimonq2> vorlon: https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/view/head:/ubuntu-release#L194 kick the can on python-scipy? It's the last thing blocking python-numpy and the failure is unrelated, in addition to there already being a hint for the version currently in devel-release. (The astropy-healpix pass hasn't showed up yet.)
<vorlon> tsimonq2: I haven't compared the failures for the old vs new versions of python-scipy, do they look the same? can we be confident that python-numpy isn't introducing any regressions?
<tsimonq2> vorlon: The failures on the python-scipy in proposed with and without python-numpy look to be the the same.
<Eickmeyer> vorlon: I know it's late, but I'm hoping you got my last message about having pushed the changes to carla you requested.
<vorlon> Eickmeyer: so, how did you determine that all of hylia is copyright falktx and not ableton?  Because the issue I pointed out was source/modules/hylia/link/AudioEngine.* and source/modules/hylia/link/ableton/* being BSL-1 vs. GPL-2+, and your change now lists all of source/modules/hylia/link/* as GPL-2+, including many files that licensecheck identified as BSL-1 licensed
<acheronuk> daily iso builds are not syncing again. i.e. building, but empty: http://cdimage.ubuntu.com/kubuntu/daily-live/20190324/
<acheronuk> oh. mcopy: File "::EFI/BOOT/mmx64.efi" not found
<acheronuk> hmm. livefs builds complete, but look borked
<acheronuk> actually not that
<Eickmeyer> vorlon: it was based on https://github.com/falktx/hylia. Iâll do some more investigation ASAP.
<Eickmeyer> vorlon: Fixed, tagged, pushed. Basically, I just now went into each file and verified the copyright line in the files. Hopefully this works better. I guess your previous message confused me.
<Eickmeyer> I realize you sent that last message at midnight, I was sound asleep. I hope it's not too late.
<Eickmeyer> I hope my fixes, rather, are not too late.
<acheronuk> cyphermox: on failing iso builds for all flavours: "mcopy: File "::EFI/BOOT/mmx64.efi" not found"
<acheronuk> I guess a result of your debian-installer upload a few days back?
<infinity> acheronuk: Fixing.
<mitya57> Has something happened to proposed migration? The last update_output.txt was generated 2019-03-24 03:35 +0000 which is 17 hours ago. And the packages are not migrating.
<mwhudson> mitya57: it doesn't seem like proposed migration itself is stuck but you're right it hasn't run in a while
<mwhudson> infinity: if you're still here can you poke? ^
<cjwatson> mitya57,mwhudson: There was an unscheduled LP frontend reboot around that time that apparently caused a few client programs to hang.  I've hit it with a suitable stick.
<mwhudson> cjwatson: thanks
#ubuntu-release 2020-03-16
<vorlon> RikMills: extra-cmake-modules and kconfig can't be removed from the whitelist, they're part of the build-dependency closure on i386 for things we do need to keep
<vorlon> RikMills: I'm looking at bringing in the new dependencies of lintian, but also it would appear this lintian is going to require an MIR
<vorlon> xnox: ^^ do you intend to follow through on an MIR for the new lintian deps?
-queuebot:#ubuntu-release- Packageset: Added libcpanel-json-xs-perl to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added libdevel-size-perl to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added libsereal-decoder-perl to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added libsereal-encoder-perl to i386-whitelist in focal
-queuebot:#ubuntu-release- Packageset: Added libjson-xs-perl to i386-whitelist in focal
<vorlon> RikMills: lintian should be installable now on i386
<RikMills> vorlon: thanks
<RikMills> what build depends on ecm and kconfig?
<RikMills> seb128: can you accept the nv-codec-headers binary?
<RikMills> seb128: also, enabling nvenc on ffmpeg. can you confirm as release-team that you do not consider this as requiring a FFe. since over cosmic upwards, this IS a new feature per se, but you can also see it as restoring a feature that was in bionic
<seb128> rikMills, hey, NEWing done now
<RikMills> :)
<seb128> rikMills, I'm not part of the r-t, it does sound like a feature to turn it on in ffmpeg though
-queuebot:#ubuntu-release- New: accepted nv-codec-headers [amd64] (focal-proposed) [9.1.23.1-0ubuntu1]
<RikMills> seb128: right. I need to sticky note on my monitor who is AA, who is release-team, and who is both
<RikMills> it is confusing ;)
<RikMills> sil2100 or Laney - can you offer advise on whether you consider this needs turning into a FFe? LP: #1810649
<ubot5> Launchpad bug 1810649 in ffmpeg (Ubuntu Focal) "Regression in Cosmic onwards: build ffmpeg 4 with external headers for NVENC" [Undecided,Triaged] https://launchpad.net/bugs/1810649
<seb128> Wimpress, ^
<seb128> rikMills, https://bugs.launchpad.net/ubuntu/+bug/1866709 is sort of a ffe request
<ubot5> Ubuntu bug 1866709 in Ubuntu " [needs-packaging] nv-codec-headers" [Wishlist,Fix committed]
<seb128> since the packaging is done now might make sense to rename it to ffe
<RikMills> can do it either way, but would have to be marked as affecting both packages
<RikMills> + if I am to sponsor the ffmpeg upload, I want release-team opinion on the ffmpeg upload
<sil2100> RikMills: ok, I think it would be best if this had an FFe, but I'd be +1 on approving it - could you rename the bug + document if you did a test-build and that it built? (logs maybe?)
<sil2100> RikMills: I'll approve it then
<RikMills> sil2100: thanks. Wimpress is driving this, so I will coordinate to get that done. he has a ppa somewhere with stuff prepared
<sil2100> RikMills: excellent, thanks! A link to the PPA would be enough o/
<RikMills> ok, I'll get that sorted this morning
<RikMills> sil2100: LP: #1810649
<ubot5> Launchpad bug 1810649 in ffmpeg (Ubuntu Focal) "[FFe] For Focal, build ffmpeg 4 with external headers for NVENC" [Undecided,Confirmed] https://launchpad.net/bugs/1810649
<xnox> vorlon:  can i unseed devscripts from "server-ship"? cause the classic d-i server iso pool is the only thing that is pulling devscripts & lintian into main.
<xnox> unless we want devscripts & lintian in main
<xnox> but like ubuntu-dev-tools are in universe
<sil2100> RikMills: awesome, approving o/
<RikMills> TY :)
<Wimpress> seb128: Thanks for the notification.
<Wimpress> RikMills: I'll be in touch a little later :-)
<RikMills> ok
<seb128> Wimpress, np!
-queuebot:#ubuntu-release- New: accepted node-debbundle-es-to-primitive [sync] (focal-proposed) [1.2.0+~1.1.4+~1.1.0+~1.1.0+~1.0.1+~1.0.2+~1.0.0+~1.0.1-2]
<cpaelzer> hi, can I get a ubuntu-release team member to merge a fix to my silly typo at https://code.launchpad.net/~paelzer/britney/hints-ubuntu-focal-pglogical-ticker/+merge/380705 ?
-queuebot:#ubuntu-release- New binary: node-debbundle-es-to-primitive [amd64] (focal-proposed/universe) [1.2.0+~1.1.4+~1.1.0+~1.1.0+~1.0.1+~1.0.2+~1.0.0+~1.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted node-debbundle-es-to-primitive [amd64] (focal-proposed) [1.2.0+~1.1.4+~1.1.0+~1.1.0+~1.0.1+~1.0.2+~1.0.0+~1.0.1-2]
-queuebot:#ubuntu-release- Unapproved: gcc-8 (bionic-proposed/main) [8.3.0-26ubuntu1~18.04 => 8.4.0-1ubuntu1~18.04] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-8-cross (bionic-proposed/main) [18ubuntu0.4 => 18ubuntu0.6] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-8-cross-ports (bionic-proposed/universe) [9ubuntu0.4 => 9ubuntu0.5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-8 (eoan-proposed/universe) [8.3.0-26ubuntu1~19.10 => 8.4.0-1ubuntu1~19.10] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-8-cross-ports (eoan-proposed/universe) [24ubuntu2 => 24ubuntu2.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-8-cross (eoan-proposed/universe) [31ubuntu2 => 31ubuntu2.1] (ubuntu-desktop) (sync)
<RikMills> sil2100: would you mind acking on the ffe bug and marking as triaged (assuming you can at the moment)
<sil2100> RikMills: did that already 45 mins ago!
<sil2100> ;)
<RikMills> sil2100: sorry. I got no email!
<RikMills> thanks
<RikMills> ah, as I never formally replied, I did not get subbed. sigh
<RikMills> even after all this time. LP still catches me out every so often!
-queuebot:#ubuntu-release- New sync: node-webassemblyjs (focal-proposed/primary) [1.9.0+dfsg-2]
<ahasenack> hi release team, if you have a moment, I'd love a review of the following FFes to bring back geoip support for bind9 in focal:
<ahasenack> https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1866875
<ubot5> Ubuntu bug 1866875 in bind9 (Ubuntu) "FFe: re-enable geoip support via libmaxminddb" [High,New]
<ahasenack> https://bugs.launchpad.net/ubuntu/+source/libmaxminddb/+bug/1867624
<ubot5> Ubuntu bug 1867624 in libmaxminddb (Ubuntu) "FFe: libmaxminddb update to 1.4.2 (MIR requirement)" [Undecided,New]
<ahasenack> https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1867150
<ubot5> Ubuntu bug 1867150 in nginx (Ubuntu) "FFe: nginx: demote bin:libnginx-mod-http-geoip" [Undecided,New]
-queuebot:#ubuntu-release- New binary: hud [s390x] (focal-proposed/universe) [14.10+17.10.20170619-0ubuntu3.1] (no packageset)
-queuebot:#ubuntu-release- New binary: hud [ppc64el] (focal-proposed/universe) [14.10+17.10.20170619-0ubuntu3.1] (no packageset)
<powersj> sil2100, if you are still around could you look at ahasenack FFEs above?
<sil2100> powersj: hey! Sure
<sil2100> Oh my, 3 FFes!
-queuebot:#ubuntu-release- New binary: hud [amd64] (focal-proposed/universe) [14.10+17.10.20170619-0ubuntu3.1] (no packageset)
 * RikMills finds another FFe
-queuebot:#ubuntu-release- New binary: hud [arm64] (focal-proposed/universe) [14.10+17.10.20170619-0ubuntu3.1] (no packageset)
<RikMills> LP: #1867136
<ubot5> Launchpad bug 1867136 in choqok (Ubuntu) "[FFE] Choqok 1.7 into focal" [Undecided,New] https://launchpad.net/bugs/1867136
-queuebot:#ubuntu-release- New binary: hud [armhf] (focal-proposed/universe) [14.10+17.10.20170619-0ubuntu3.1] (no packageset)
<RikMills> if any release tem could ack that ^ it would be appreciated
<RikMills> Simon seems to have gone dark for a bit, and I can't get a response from him under ffe delegation
<RikMills> it is not critical :)
<Laney> sil2100: hey, pinging you since it's your sru day today... I just got asked by upstream about mutter/eoan, wondering if we can chat about it
<Laney> there are a couple of bugs which are maybe/probably not fixed, so I don't feel great about marking them as v-done
<Laney> but there are *not* regressions ... so I'd like to release that mutter to -updates to give everyone else the rest of the fixes which are working
<Laney> any opinion?
<sil2100> Laney: hey! I was wonderng about it some time ago already, asked about what's up with LP: #1853357
<ubot5> Launchpad bug 1853357 in mutter (Ubuntu Eoan) "display (whole computer?) hangs when I attempt to use DisplayLink with Wayland" [Medium,Confirmed] https://launchpad.net/bugs/1853357
<Laney> ya, that's one of them
<Laney> the claim is that it's not fixed like we said it was
<Laney> which I can't disprove, so ... release and then re-open the eoan task?
<sil2100> hm, guess we could in theory release those and then switch them back to 'Confirmed'
<Laney> that's what I'd like to happen anyway :-)
<sil2100> How many such bugs would we have?
<sil2100> All the ones that are not verified?
<Laney> also bug #1859135
<ubot5> Error: Launchpad bug 1859135 could not be found
<Laney> also bug #1849135
<ubot5> bug 1849135 in mutter (Ubuntu Eoan) "Clicking Activities in the corner doesn't work" [Medium,Confirmed] https://launchpad.net/bugs/1849135
<sil2100> Laney: let me get back to you in a bit
<Laney> ok
 * sil2100 needs to handle the gcc-8 SRU first
<Laney> no worries
<Laney> apparently there's some problem with firefox that is fixed by this, and upstream are getting a lot of reports which is upsetting them :)
<sil2100> RikMills: I might not have enough cycles to take a look at it today sadly!
 * sil2100 looks at his today's TODO list with terror in his eyes
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8 [sync] (eoan-proposed) [8.4.0-1ubuntu1~19.10]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross [sync] (eoan-proposed) [31ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross-ports [sync] (eoan-proposed) [24ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8 [sync] (bionic-proposed) [8.4.0-1ubuntu1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross [sync] (bionic-proposed) [18ubuntu0.6]
<RikMills> sil2100: no problem
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross-ports [sync] (bionic-proposed) [9ubuntu0.5]
-queuebot:#ubuntu-release- New source: node-webpack (focal-proposed/primary) [4.30.0-7~ubuntu1]
<sil2100> Laney: released! And switched the two bugs back to 'New'
<Laney> sil2100: â¥ thanks
<kanashiro> hello, I've sync'ed some node packages from Debian to fix a src:jekyll's dependency issue, could someone please approve them for me? they are node-webassemblyjs and node-webpack
-queuebot:#ubuntu-release- Unapproved: fence-agents (bionic-proposed/universe) [4.0.25-2ubuntu1 => 4.0.25-2ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pacemaker (bionic-proposed/main) [1.1.18-0ubuntu1.1 => 1.1.18-0ubuntu1.2] (ubuntu-server)
<RikMills> vorlon: could you please consider approving LP: #1867136
<ubot5> Launchpad bug 1867136 in choqok (Ubuntu) "[FFE] Choqok 1.7 into focal" [Undecided,New] https://launchpad.net/bugs/1867136
<mwhudson> RikMills: he's not working today
<mwhudson> RikMills: of course he's not very good at not working but you still might get better results poking some other member of the release team
<RikMills> mwhudson: whaaaaaaaaaaaat? he is normally here 24/7 except when asleep!
<RikMills> I jest, but thanks for the info
<sarnold> he sleeps?
<RikMills> anyway, @release-team, I am unable to get a response from Simon under FFe delegation, so I have to fall back to old paradigm
<xnox> sarnold:  their alter-egos alternate sleep, yes.
<sarnold> xnox: ahhh that's how they do it :)
#ubuntu-release 2020-03-17
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-177.207] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-177.207]
<vorlon> who wants to sort out node-chokidar/amd64 for nodejs? (blocks icu)
<xnox> vorlon:  how bad is it that libicu depends on tzdata?
<vorlon> I don't know, what's the issue?
<vorlon> ruby-defaults isn't ready to go yet, is it?
<xnox> vorlon:  somehow i thought we have people removing tzdata, but i see that it is in minimal so should be fine.
<vorlon> it's not in the minimal images
<xnox> vorlon:  ..... because task:minimal != minimal images =)
<xnox> right
<vorlon> yep
<xnox> that's what i thought, but is libicu in the minimal images?
<vorlon> php7.4 also not a candidate yet
<vorlon> xnox: no, but if one installs something using it and doesn't also install tzdata, things are broken?
<vorlon> in principle you run the minimal images as a starting point for running workloads, and one of the supported ways of installing workloads is as debs, so
<xnox> vorlon:  no, but wrong out-of-date built-in timezone data is used
<xnox> for all the U_TIME apis
<xnox> i.e. i'm fixing the fact that php never gets tzdata updates
<xnox> https://launchpad.net/ubuntu/+source/tzdata/2019c-3ubuntu1 & https://launchpad.net/ubuntu/+source/icu/66.1-2ubuntu1
<vorlon> ok
<xnox> but now i'm not sure if Depends: tzdata is appropriate in this case or not
<xnox> on release day it doesn't matter, it will matter the first time we update tzdata
<vorlon> so it looks like the blockers for icu right now are webkit2gtk (which seb128 said he was going to take responsibility for), libical3, php7.4, ruby, and nodejs
<vorlon> xnox: it sounds appropriate to me
<xnox> all of the packages in that list smell! =)
<vorlon> nodejs is only one amd64-specific autopkgtest regression away
<xnox> vorlon:  given https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1863463 do you want to badtest that test, let it migrate, sync new nodejs, and do all of this again?
<ubot5> Ubuntu bug 1863463 in nodejs (Ubuntu) "Firefox 75 requires nodejs >= 10.19" [High,Confirmed]
<xnox> but i love how 10.19 ftbfs on all arches in debian
<vorlon> xnox: I don't want to sync new nodejs at all, I just want the icu transition through
<xnox> ack
<vorlon> (and I want the uploader to take responsibility for it, but, well)
<xnox> the first one or the second one?
<xnox> =)))))
<xnox> or both of them?
<vorlon> both ;P
<xnox> i fear all of horde stuff was not merged since bionic and needs merge to 3.10
-queuebot:#ubuntu-release- New: accepted hud [amd64] (focal-proposed) [14.10+17.10.20170619-0ubuntu3.1]
-queuebot:#ubuntu-release- New: accepted hud [armhf] (focal-proposed) [14.10+17.10.20170619-0ubuntu3.1]
-queuebot:#ubuntu-release- New: accepted hud [s390x] (focal-proposed) [14.10+17.10.20170619-0ubuntu3.1]
-queuebot:#ubuntu-release- New: accepted hud [arm64] (focal-proposed) [14.10+17.10.20170619-0ubuntu3.1]
-queuebot:#ubuntu-release- New: accepted hud [ppc64el] (focal-proposed) [14.10+17.10.20170619-0ubuntu3.1]
<xnox> Can arm64 be added to the Ubuntu Desktop product on isotracker? KeyError: "Product 'Ubuntu Desktop arm64' not found"
<Laney> okey
<Laney> should be there... perhaps?
<xnox> Laney:  or maybe I need to remove it from qa products? there is traceback in cd-build-logs, which doesn't fail the build but doesn't look tidy
<xnox> Laney:  i plan to submit iso tracker test results for the two arm64 laptops i have
<Laney> I think it's OK to post it there
<Laney> we'll see what happens after the next build
<xnox> tah!
<kanashiro> I've requested uploads of some node packages from Debian to fix a src:jekyll's dependency issue, could someone please approve them for me? they are node-webassemblyjs and node-webpack
<xnox> where did you request them?
<xnox> Laney:  do you have powers to commit to debian-cd? I want to land https://code.launchpad.net/~xnox/debian-cd/ux-review-uefi-labels/+merge/379769 which has been reviewed and has agreed wording with mpt and is now final.
<xnox> Laney:  and steve is afk today
<Laney> This isn't really the channel for making general sponsorship requests, BTW
<Laney> xnox: yeah, ok, let me look later
 * xnox slaps myself on the rist
 * xnox slaps myself on the wrist
<xnox> kanashiro:  where did you request them?
<kanashiro> xnox, I filed some sync requests and provided some patches, but those packages were already uploaded, I just need an approval because those are not in focal atm
<Laney> xnox: actually that was for kanashiro, yours is *slightly* more on topic
<kanashiro> Laney, it is not a sponsorship request, they are in NEW I think
<xnox> yeap they are https://launchpad.net/ubuntu/focal/+queue
<xnox> kanashiro:  you need an archive-admin for those, of which neither laney or I, are =(
<kanashiro> xnox, ok, thanks anyway
<kanashiro> but here is the right place to find archive-admins, right?
<Laney> yeah, I think they are supposed to respond to ubuntu-archive highlight (cf. the /topic)
<Laney> I don't know if they expect people to ping for each new review though, or wait until it's done
<kanashiro> I am just pinging because they are blocking some the other syncs I need, but ok, let's wait
<cjwatson> kanashiro: What's the dependency issue here?  I don't see any dependency on node-webassemblyjs in the current jekyll
<kanashiro> cjwatson, node-uglifyjs-webpack-plugin depends no node-webassemblyjs
<kanashiro> this is my next sync request
<cjwatson> kanashiro: How did https://launchpad.net/ubuntu/+source/jekyll/3.8.6+dfsg-3/+build/18759718 build then?
<cjwatson> (I'm assuming you're trying to upgrade something, and am mainly trying to get you to tell me what the overall goal here is)
<kanashiro> cjwatson, if you try to build jekyll now it will fail, I didn't investigate why it built previously
<kanashiro> it needs webpack which is provided by node-webpack
<cjwatson> Oh right, node-uglifyjs-webpack-plugin was removed
<cjwatson> So yes, if you're committing to getting this all the way through, I guess that's fine
<xnox> (indeed currently we try to make nodejs icu php ruby migrate)
<kanashiro> yes, I already sorted it out locally, just need to get those packages in the archive
-queuebot:#ubuntu-release- New: accepted node-webassemblyjs [sync] (focal-proposed) [1.9.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted node-webpack [source] (focal-proposed) [4.30.0-7~ubuntu1]
<cjwatson> I don't think these should interfere with any transitions in progress, since they're both new
<kanashiro> cjwatson, FYI my next step is: request a sync of node-uglifyjs-webpack-plugin and node-webpack
-queuebot:#ubuntu-release- New binary: node-webassemblyjs [amd64] (focal-proposed/universe) [1.9.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted node-webassemblyjs [amd64] (focal-proposed) [1.9.0+dfsg-2]
<xnox> hopefully they will help with autopkgtest regressions eventually
<kanashiro> they will fix at least jekyll's autopkgtest regression
-queuebot:#ubuntu-release- New sync: yagf (focal-proposed/primary) [0.9.5+repack1-1]
<xnox> vorlon:  Laney: any guidance on what review analysis you want for the s390-tools FFe for this codedrop diffstat https://paste.ubuntu.com/p/pB5TxkbMjs/ ?
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-92.93] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-92.93] (core, kernel)
<franksmcb> Can anyone get to this https://bugs.launchpad.net/bugs/1867714 supposed to be a bug report for ubiquity not starting on the current MATE ISO
<ubot5> Error: ubuntu bug 1867714 not found
<xnox> vorlon:  Laney: the genprotimg stuff is "new" and thus well can't regress. But the zipl/ stuff is effectively a refactor of the bootloader affecting all s390x substrates; interlined with bug fixes; and features; and whitespace changes; some dating to 2018 but only code-dropped released yesterday
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-92.93]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-92.93]
<Laney> xnox: I dunno, what's your existing testing strategy?
<xnox> Laney:  do line by line codereview + boot install test on our z13 (lpar, z/vm, kvm). But we have no access to do boot testing on z14 and z15.
-queuebot:#ubuntu-release- New sync: node-uglifyjs-webpack-plugin (focal-proposed/primary) [1.3.0-5]
-queuebot:#ubuntu-release- New source: what-is-python (focal-proposed/primary) [1]
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-43.36] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.3.0-43.36] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-43.36] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-43.36] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.3.0-43.36]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.3.0-43.36]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.3.0-43.36]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (eoan-proposed) [5.3.0-43.36]
<xnox> doko:  what-is-python uploaded into the New queue, please review if you like it or not.
<xnox> doko:  do feel free to like reject it, if you don't.
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [5.0.0-1034.35] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1033.34] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1059.63] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [5.0.0-1034.35]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1033.34]
<jamespage> please can the ceph SRU in the eoan-proposed UNAPPROVED queue be rejected - I need to fold in the security update that was just released
<jamespage> ditto on bionic-proposed - thanks!
-queuebot:#ubuntu-release- Unapproved: ceph (eoan-proposed/main) [14.2.4-0ubuntu0.19.10.2 => 14.2.7-0ubuntu0.19.10.1] (desktop-core, ubuntu-server)
<jamespage> I've uploaded revised version so the newer uploads are valid - please reject the older ones
-queuebot:#ubuntu-release- Unapproved: ceph (bionic-proposed/main) [12.2.12-0ubuntu0.18.04.5 => 12.2.13-0ubuntu0.18.04.1] (desktop-core, ubuntu-server)
<kanashiro> could someone approve node-uglifyjs-webpack-plugin in the focal NEW queue? It is needed to fix a src:jekyll's autopkgtest regression
<cjwatson> done
-queuebot:#ubuntu-release- New: rejected node-uglifyjs-webpack-plugin [sync] (focal-proposed) [1.3.0-5]
<kanashiro> thanks
<cjwatson> Uh what?  I accepted it
<cjwatson> Oh, because that version was previously in focal so the sync attempt failed, probably
<cjwatson> kanashiro: You'll need to upload a 1.3.0-5build1
<kanashiro> cjwatson, ack
<rafaeldtinoco> cjwatson: sorry for that, I did the syncpackage
<rafaeldtinoco> a question there.. if we do 1.3.0-5build1 theoretically eoan can have the same version
<rafaeldtinoco> if a build1 is made there
<rafaeldtinoco> correct ?
<rafaeldtinoco> should I do 1.3.0-5ubuntu0.20.04.1 instead ?
<rafaeldtinoco> kanashiro: would that ^ version work for u ?
<rafaeldtinoco> or ~ubuntu0.20.04.1
<rafaeldtinoco> sorry +ubuntu0.20.04
<rafaeldtinoco> just thinking in upgrade path =)
<rafaeldtinoco> 1.3.0-5 to 1.3.0-5ubuntu0.1 (SRU in Eoan) and 1.3.0-5ubuntu1 (Focal) would work
<kanashiro> rafaeldtinoco, I think node-uglifyjs-webpack-plugin will unlikely be rebuilt in eoan but yeah there is a chance, the version string you are proposing should work fine
<rafaeldtinoco> kanashiro: instead of a sync, i suggest we go for the later ^ if that works for u
<rafaeldtinoco> ahasenack: could u re-check this for me ? ^
<ahasenack> hm?
<rafaeldtinoco> kanashiro needs a "sync" from debian but eoan already has the version
<rafaeldtinoco> my suggestion is:
<rafaeldtinoco> 15:01 <rafaeldtinoco> 1.3.0-5 to 1.3.0-5ubuntu0.1 (SRU in Eoan) and 1.3.0-5ubuntu1 (Focal) would work
<rafaeldtinoco> to submit the source package in focal with 1.3.0-5ubuntu1
<rafaeldtinoco> leaving ubuntu0.xxx for eoan if ever needed
<ahasenack> so you want 1.3.0-5 in focal
<ahasenack> let's take this into #ubuntu-devel
<rafaeldtinoco> yep
-queuebot:#ubuntu-release- New source: node-uglifyjs-webpack-plugin (focal-proposed/primary) [1.3.0-5build1]
-queuebot:#ubuntu-release- New: accepted node-uglifyjs-webpack-plugin [source] (focal-proposed) [1.3.0-5build1]
-queuebot:#ubuntu-release- New binary: node-uglifyjs-webpack-plugin [amd64] (focal-proposed/none) [1.3.0-5build1] (no packageset)
<kanashiro> cjwatson, node-uglifyjs-webpack-plugin version 1.3.0-5build1 is in the NEW queue, could you please approve it?
-queuebot:#ubuntu-release- New: accepted node-uglifyjs-webpack-plugin [amd64] (focal-proposed) [1.3.0-5build1]
<kanashiro> ^ thanks!
<cjwatson> Yep, was on it :)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1059.63]
#ubuntu-release 2020-03-18
-queuebot:#ubuntu-release- Unapproved: libvirt (eoan-proposed/main) [5.4.0-0ubuntu5.1 => 5.4.0-0ubuntu5.2] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: linux-meta-oracle-5.0 (bionic-security/main) [5.0.0.1013.14 => 5.0.0.1013.14] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-meta-oracle-5.0 (bionic-updates/main) [5.0.0.1013.14 => 5.0.0.1013.14] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-oracle-5.0 [sync] (bionic-security) [5.0.0.1013.14]
-queuebot:#ubuntu-release- Unapproved: accepted linux-meta-oracle-5.0 [sync] (bionic-updates) [5.0.0.1013.14]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-92.93~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-92.93~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-92.93~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-92.93~16.04.1]
<cpaelzer> Hiho, what would we need to check if dbgsym packages are out of date?
<cpaelzer> he build is 4 days ago, it migrated 3 days ago https://launchpad.net/ubuntu/+source/qemu/1:4.2-3ubuntu2
<cpaelzer> https://launchpad.net/ubuntu/+source/qemu/1:4.2-3ubuntu2/+build/18833916 shows nothing odd in regard to dbgsym
<cpaelzer> never the less "apt-cache policy qemu-system-x86-dbgsym qemu-system-x86" tells me that the dbgsym are still on 1:4.2-3ubuntu1
<cpaelzer> might there be a part of the publishing infrastructure that needs a bump ?
<cpaelzer> ubuntu-archive ^^ ?
<locutus_> any AA please accept yagf from new queue, removed because of qt4 removal, now the new version is qt5
-queuebot:#ubuntu-release- Unapproved: linux-base (eoan-proposed/main) [4.5ubuntu2 => 4.5ubuntu2.1] (core)
-queuebot:#ubuntu-release- New: rejected yagf [sync] (focal-proposed) [0.9.5+repack1-1]
-queuebot:#ubuntu-release- Unapproved: linux-base (bionic-proposed/main) [4.5ubuntu1 => 4.5ubuntu1.1] (core)
-queuebot:#ubuntu-release- New binary: linux-base [amd64] (focal-proposed/main) [4.5ubuntu3] (core, i386-whitelist)
<cjwatson> 61833   Mar 12 /bin/sh -c ~/ddeb-retriever/ddeb-retriever --verbose >>/srv/ddebs.ubuntu.com/logs/ddeb-retriever.log 2>&1
<cjwatson> 61834   Mar 12  \_ /usr/bin/python3 /srv/ddebs.ubuntu.com//ddeb-retriever/ddeb-retriever --verbose
<cjwatson> cpaelzer: ^- unstuck
<cpaelzer> thank you cjwatson
<cjwatson> (i.e. killed that process on numen)
<cjwatson> Not sure why that got stuck - no obvious incident around then
<cjwatson> It got stuck at 16:47ish, some hours before the GS2 edge network incident
<cjwatson> cpaelzer: Also started up manually in screen since it was going to be an hour or so before it started for itself
<locutus_> did anybody wrongly move llvm-toolchain-10 to main? I can't parse the reason for it not migrating clang-tidy-10/amd64 unsatisfiable Depends: clang-tools-10 and similar
-queuebot:#ubuntu-release- New binary: linux-signed-oracle-5.0 [amd64] (bionic-proposed/main) [5.0.0-1014.19] (no packageset)
-queuebot:#ubuntu-release- Unapproved: linux-base (xenial-proposed/main) [4.5ubuntu1~16.04.1 => 4.5ubuntu1.1~16.04.1] (core)
<doko> locutus_: I did, but every new upload puts *every* binary package to main again
<locutus_> but why? the sync I did, didn't change binaries or add new stuff
<locutus_> so, why is stuff auto promoting? bug?
-queuebot:#ubuntu-release- New source: what-is-python (focal-proposed/primary) [1]
-queuebot:#ubuntu-release- New: rejected what-is-python [source] (focal-proposed) [1]
-queuebot:#ubuntu-release- New: accepted what-is-python [source] (focal-proposed) [1]
-queuebot:#ubuntu-release- New binary: what-is-python [amd64] (focal-proposed/none) [1] (no packageset)
-queuebot:#ubuntu-release- New: accepted what-is-python [amd64] (focal-proposed) [1]
<locutus_> doko, I didn't ask to reject yagf, but to accept it :)
<locutus_> the syncd package is now qt5
-queuebot:#ubuntu-release- New sync: yagf (focal-proposed/primary) [0.9.5+repack1-1]
<doko> locutus_: sorry, misread
-queuebot:#ubuntu-release- New: accepted yagf [sync] (focal-proposed) [0.9.5+repack1-1]
-queuebot:#ubuntu-release- New binary: yagf [s390x] (focal-proposed/universe) [0.9.5+repack1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: yagf [amd64] (focal-proposed/universe) [0.9.5+repack1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: yagf [ppc64el] (focal-proposed/universe) [0.9.5+repack1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: yagf [arm64] (focal-proposed/universe) [0.9.5+repack1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: yagf [armhf] (focal-proposed/universe) [0.9.5+repack1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (eoan-proposed/main) [5.3.0-1015.16] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1056.59] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1056.59]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (eoan-proposed) [5.3.0-1015.16]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle-5.0 [amd64] (bionic-proposed) [5.0.0-1014.19]
<locutus_> no problem thanks!
<ddstreet> cpaelzer fyi re: dbgsyms, you can always use pull-lp-ddebs
<cpaelzer> ddstreet: I have got them from the build page already
<cpaelzer> ddstreet: this was mostly to get the publishing fixed up
<ddstreet> ack
-queuebot:#ubuntu-release- New: accepted yagf [amd64] (focal-proposed) [0.9.5+repack1-1]
-queuebot:#ubuntu-release- New: accepted yagf [armhf] (focal-proposed) [0.9.5+repack1-1]
-queuebot:#ubuntu-release- New: accepted yagf [s390x] (focal-proposed) [0.9.5+repack1-1]
-queuebot:#ubuntu-release- New: accepted yagf [arm64] (focal-proposed) [0.9.5+repack1-1]
-queuebot:#ubuntu-release- New: accepted yagf [ppc64el] (focal-proposed) [0.9.5+repack1-1]
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-2build1 => 1.3.9-2build1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-2build1 => 1.3.9-2build1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-2build1 => 1.3.9-2build1] (core)
<vorlon> doko, xnox: why is what-is-python a separate source package instead of the binaries being provided by python3-defaults and python-defaults, and why are there python-dev packages which were not part of the design?
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (focal-proposed) [1.3.9-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (focal-proposed) [1.3.9-2build1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (focal-proposed) [1.3.9-2build1]
<doko> vorlon: why do you want to run triggers on those?
<vorlon> doko: I don't think moving code into suboptimal locations in the archive to avoid autopkgtest is a right thing to do
<doko> no, I mentioned that at least in a call that these might be necessary
<vorlon> "might be necessary" is not a decision that we're supporting it, why are we doing -dev packages?
<doko> and I think introducing a delta isn't the right thing either
<doko> because people expect to use python-config
<xnox> vorlon:  separate source package, because this stuff is weird, and short term.
<vorlon> xnox: so then someone has to remember to request removal of the weird, short-term package, instead of being able to figure out as part of our normal merge process that it can be dropped
<vorlon> doko: why do we care that "people expect" to use python-config?
<xnox> vorlon:  the Maintainer: will. Which is set to i
<doko> because software will fail to configure/build?
<vorlon> python-dev-is-python2-but-deprecated
<vorlon> this package should not exist
<vorlon> for sure
<doko> it should. of the same reason that python-is-python2-but-deprecated exists
<vorlon> we should not give users a package that lets them point python-config at python2
<vorlon> no, python-is-python2-but-deprecated (which is also not the binary package name from the spec) is for runtime compatibility
<doko> afk now, we can address this tomorrow in the meeing
<rbalint> vorlon, i've filed an ffe for systemd 245, please consider it LP: #1867972
<ubot5> Launchpad bug 1867972 in systemd (Ubuntu) " [FFe] Please accept systemd 245-2ubuntu1 to Focal" [Undecided,New] https://launchpad.net/bugs/1867972
-queuebot:#ubuntu-release- Unapproved: python-barbicanclient (bionic-proposed/main) [4.6.0-0ubuntu1 => 4.6.0-0ubuntu1.1] (openstack, ubuntu-server)
<blackboxsw> vorlon hiya if theres time can someone please review ack https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1866930 we have landed a branch with this support in tip of master for cloud-init
<ubot5> Ubuntu bug 1866930 in cloud-init (Ubuntu) "[FFe] ec2 add support for configuring secondary NICs and secondary ipv4 and ipv6 addresses" [High,Fix committed]
<blackboxsw> and we would like to queue an upload with that cherry pick into focal if we can
-queuebot:#ubuntu-release- New: accepted linux-base [amd64] (focal-proposed) [4.5ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted linux-base [source] (eoan-proposed) [4.5ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-base [source] (bionic-proposed) [4.5ubuntu1.1]
-queuebot:#ubuntu-release- New binary: linux-base [amd64] (eoan-proposed/main) [4.5ubuntu2.1] (core)
-queuebot:#ubuntu-release- New binary: linux-base [amd64] (bionic-proposed/main) [4.5ubuntu1.1] (core)
-queuebot:#ubuntu-release- New: accepted linux-base [amd64] (eoan-proposed) [4.5ubuntu2.1]
-queuebot:#ubuntu-release- New: accepted linux-base [amd64] (bionic-proposed) [4.5ubuntu1.1]
<Kamilion> just curious if the dh-python runtime warnings will be suppressed soon or not? #1863195
<vorlon> kanashiro: are you still working on the ruby transition?  I see a lot of unaddressed autopkgtest regresions; should I start removing packages?
<kanashiro> vorlon, I am still working on it. I just fixed 2 packages in Debian, waiting for them to land in unstable to request a sync; and other 3 I have fixes in Debian but in new major upstream releases, so I need to request a FFe
-queuebot:#ubuntu-release- Unapproved: apport (eoan-proposed/main) [2.20.11-0ubuntu8.6 => 2.20.11-0ubuntu8.7] (core)
-queuebot:#ubuntu-release- Unapproved: apport (bionic-proposed/main) [2.20.9-0ubuntu7.12 => 2.20.9-0ubuntu7.13] (core)
<vorlon> kanashiro: given that there are some 14 packages still showing regressions, how quickly do you think we'll have the rest sorted?  Note that ruby-defaults is also entangled with both the apt and icu transitions, which is mainly why I care
<kanashiro> vorlon, I want to get those packages which I already have fixes tomorrow, after that we can start to remove the remaining packages. Can I let you know on Friday? about the status
<vorlon> kanashiro: works for me
<kanashiro> great
<vorlon> rbalint: systemd-p11kit> oh dear
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [5.0.0-1035.37] (kernel)
#ubuntu-release 2020-03-19
<blackboxsw> Woot! Thanks vorlon for cloud-init!
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [5.0.0-1035.37]
-queuebot:#ubuntu-release- New binary: linux-signed-azure-5.3 [amd64] (bionic-proposed/main) [5.3.0-1016.17~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-5.3 [amd64] (bionic-proposed) [5.3.0-1016.17~18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (eoan-proposed/main) [5.3.0-1016.17] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: accepted linux-base [source] (xenial-proposed) [4.5ubuntu1.1~16.04.1]
-queuebot:#ubuntu-release- New binary: linux-base [amd64] (xenial-proposed/main) [4.5ubuntu1.1~16.04.1] (core)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (eoan-proposed) [5.3.0-1016.17]
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (eoan-proposed/main) [5.3.0-1012.13] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (eoan-proposed) [5.3.0-1012.13]
<LocutusOfBorg> doko, can you please do the llvm-toolchain-10 promotion to main magic?
<LocutusOfBorg> also coq and reverse-dependencies are dropped in armhf/s390x in debian, can any AA do the same? (also reverse-deps please
<LocutusOfBorg> NBS cleanup in proposed ^^ apw please?
<LocutusOfBorg> this makes the coq transition finish
<apw> LocutusOfBorg, of ?
<LocutusOfBorg> <LocutusOfBorg> apw, can I please have coq removed in some architectures? it follows a debian removal bug. it might come back, but maybe not in time for focal https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953408
<LocutusOfBorg> <ubot5> Debian bug 953408 in ftp.debian.org "RM: coq [armel armhf i386 mipsel mips64el s390x] -- ROM; FTBFS (mostly on 32bit architectures, or where ocaml has only a bytecode compiler)" [Normal,Open]
<LocutusOfBorg> <LocutusOfBorg> the list and reverse-deps is on that bug, basically coq armhf i386 s390x, with also prooftree why3 and libaac-tactics-ocaml
<ubot5> Debian bug 953408 in ftp.debian.org "RM: coq [armel armhf i386 mipsel mips64el s390x] -- ROM; FTBFS (mostly on 32bit architectures, or where ocaml has only a bytecode compiler)" [Normal,Open]
<LocutusOfBorg> the new coq is FTBFS there, it might come back but not in time for focal
<doko> LocutusOfBorg: no, it's demotions, and it's always reset when you upload a new llvm :-/
<LocutusOfBorg> but why?
<seb128> ubuntu-archive, anyone who would like to review https://code.launchpad.net/~seb128/ubuntu-archive-scripts/report-include-timezone/+merge/380301 ? should be trivial
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1075.80] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-base [amd64] (xenial-proposed) [4.5ubuntu1.1~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1075.80]
<sil2100> seb128: looking
<seb128> sil2100, thanks
<doko> apw, sforshee, is there a way to avoid the hundreds of messages in autopkg tests like: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-18-generic/modules.builtin.bin'
<apw> doko, that i think should be there; so likely yes
<doko> apw: ? so is there a way to avoid these?
<apw> doko: I believe there is, I suspect that says we are failing to package a new binary accelerator file
<doko> thanks for clarifying
<doko> seb128, Laney: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/libn/libnotify/20200313_112217_b01a0@/log.gz  is ignoreing stderr the right choice? or should the test be ignored?
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1044.49] (no packageset)
<sforshee> doko, apw: this isn't a kernel problem, and according to bug 1864992 it should be fixed
<ubot5> bug 1864992 in kmod (Ubuntu Eoan) "depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/lib/modules/5.4.0-14-generic/modules.builtin.bin'" [Medium,In progress] https://launchpad.net/bugs/1864992
-queuebot:#ubuntu-release- New binary: linux-signed-oracle-5.3 [amd64] (bionic-proposed/main) [5.3.0-1012.13~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1036.40] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1044.49]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1036.40]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle-5.3 [amd64] (bionic-proposed) [5.3.0-1012.13~18.04.1]
<tkamppeter> Hi, could someone have a look at bug 1865298, FFe for HPLIP, driver for newest HP printers?
<ubot5> bug 1865298 in hplip (Ubuntu) "[FFe] Request for update: HPLIP 3.20.3" [High,Confirmed] https://launchpad.net/bugs/1865298
<seb128> doko, (Laney), no, ignoring stderr wouldn't be right/would fix the issue, xvfb fails to start an xserver apparently so it's not a problem of stderr noise
<seb128> doko, sounds like a real issue
<ahasenack> hello release team, if someone has a moment and could please look at this FFe, it's the long tail of reintroducing geoip support in bind9 9.16: https://bugs.launchpad.net/ubuntu/+source/python-maxminddb/+bug/1867919
<ubot5> Ubuntu bug 1867919 in python-maxminddb (Ubuntu) "FFe: python-maxminddb 1.5.2 update (MIR requirement)" [Undecided,New]
<doko> apw, sil2100: please update the mailman hint to mailman/1:2.1.29-1ubuntu3  always failed
<doko> ruby-defaults now migratable, when ignoring autopkg tests (output_notest.txt)
<doko> kanashiro: ^^^
<apw> doko, done
<kanashiro> doko, good news
<doko> kanashiro: yesterday, we (xnox, rbalint, myself) chatted how we can help with the transition (because it's blocking some others). Do you have a status, or packages which need help?
<doko> LocutusOfBorg: filed https://bugs.launchpad.net/ubuntu/+source/coq/+bug/1868106. could you update that for focal?
<ubot5> Ubuntu bug 1868106 in coq (Ubuntu) "RM: coq [armhf i386 s390x] -- ROM; FTBFS (mostly on 32bit archs, or where ocaml has only a bytecode compiler)" [Undecided,New]
<kanashiro> doko, I also chatted about it with vorlon and we intend to start removing the remaining packages with autopkgtest regressions tomorrow, today I am working on chef (which I think it is an important package and we shouldn't remove it) and the other one that I am worried about is ruby-fakefs because it would remove many other packages. So when we get those 2 packages fixed I think we are good to go and request removals for the rest
<bdmurray_> sil2100: Could you have a look at my apport SRUs for 19.10 and 18.04?
<kanashiro> doko, btw I just got a patch to fix ruby-fakefs
<sil2100> bdmurray: sure! I didn't do queue reviews yet, wanted to finish up netplan/networking stuff - I'm good to start now
<ahasenack> sil2100: hi, pinging you just because you reviewed the previous FFes and have some context at least: https://bugs.launchpad.net/ubuntu/+source/python-maxminddb/+bug/1867919
<ubot5> Ubuntu bug 1867919 in python-maxminddb (Ubuntu) "FFe: python-maxminddb 1.5.2 update (MIR requirement)" [Undecided,New]
<ahasenack> you are nearing your eod, though
<rafaeldtinoco> someone mind force bad-test to ruby-gtk/all/ppc64el because of LP: #1868108 for kanashiro and I ? (ruby transition)
<ubot5> Launchpad bug 1868108 in ruby-gnome (Ubuntu Focal) "[autopkgtest][focal] ruby-gnome/3.4.1-2build1 class:TestWebKit2GtkWebView failure" [Undecided,Confirmed] https://launchpad.net/bugs/1868108
<sil2100> ahasenack: hey! I'll try to get to it after I do some SRU stuff
<ahasenack> sil2100: thanks a lot
<seb128> rafaeldtinoco, sil2100, don't badtest ruby-gnome, webkit is really busted on ppc64el and it's not a redherring
<seb128> I've a test fix in a ppa and I'm working with upstream on it
<tkamppeter> sil2100, are you working on FFe s today? Could you have a look at bug ld someone have a look at bug  1865298?
<ubot5> bug 1865298 in hplip (Ubuntu) "[FFe] Request for update: HPLIP 3.20.3" [High,Confirmed] https://launchpad.net/bugs/1865298
<sil2100> seb128: ACK
<seb128> thanks
<rafaeldtinoco> tku
<sil2100> tkamppeter: hey! I'll try to take a look at it as well after my meeting + SRU shift
<tkamppeter> OK, thanks.
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (eoan-proposed) [2.20.11-0ubuntu8.7]
<nael_n> seb128, you helped me on bug #1866565. It's been fixed upstream and the GNOME developers made a bugfix release (gedit-plugins 3.36.1). Can it be brought downstream in Ubuntu? Does it need to go through Debian? I'm not sure what's the next steps and how I can help
<ubot5> bug 1866565 in gedit-plugins (Ubuntu) "Enabling the embedded terminal plugin crashes GEdit and subsequently prevents GEdit to start b/c of missing key in GSettings schema" [Medium,Fix committed] https://launchpad.net/bugs/1866565
<seb128> nael_n, hey, first best to use #ubuntu-desktop or #ubuntu-devel, that's not a release issue
<seb128> nael_n, also that update is on our GNOME updates list for the cycle, we do updates in Debian for most GNOME packages so we will do it there, no need to do anything more from your side
<nael_n> OK thanks! That's good to hear. Channels noted!
-queuebot:#ubuntu-release- Unapproved: accepted drbd-utils [source] (bionic-proposed) [8.9.10-2ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (bionic-proposed) [2.20.9-0ubuntu7.13]
<LocutusOfBorg> doko, what is the action point from my side to LP:  #1868106 ?
<ubot5> Launchpad bug 1868106 in why3 (Ubuntu) "RM: coq [armhf s390x] -- ROM; FTBFS (mostly on 32bit archs, or where ocaml has only a bytecode compiler)" [Undecided,New] https://launchpad.net/bugs/1868106
<LocutusOfBorg> thanks for doing it
<hggdh> folks we have a regression on GRUB, 18.04. Please see bug 1868138
<ubot5> bug 1868138 in grub2 (Ubuntu) "18.04LTS upgrade of grub-common:amd64 FAILs in post-install; incorrectly REWRITES user's /etc/default/grub" [Medium,Triaged] https://launchpad.net/bugs/1868138
<seb128> juliank, chrisccoulson, SRUteam, ^
<chrisccoulson> huh, I don't see how the recent update could cause this - it doesn't touch anything that happens on install
<chrisccoulson> it looks like it's probably a bug that's been there for a while, and just triggered by the latest update
<chrisccoulson> the last upload to touch anything that runs on install was https://launchpad.net/ubuntu/+source/grub2/2.02-2ubuntu8.13
<chrisccoulson> seb128 ^
<chrisccoulson> I'm not sure what to do about that
<hggdh> prolly. If you change /etc/default/grub *after* the upgrade to add a continuation line, it works
<hggdh> point is, right now, users with continuation lines will fail to upgrade. The OP states they have 100+ servers
<seb128> chrisccoulson, right
<hggdh> I tested it on Azure, and it fails as reported. IDK how many Azure VMs would be in the same scenario, but I expect there will be a non-insignificant number (and on other clouds as well)
<seb128> hggdh, but why does it start being an issue now if that was introduce 2 revisions ago?
<hggdh> seb128: I frankly have no idea yet, trying to grab more data from OP. It may well be it has been lurking there since 8ubuntu13, but nobody upgraded.
<hggdh> nevertheless it is there now :-)
<hggdh> and dammit, I wrote the version wrong. it is, of course, 2.02-2ubuntu8.13
<chrisccoulson> I'm not sure what to do at the moment. This almost certainly isn't caused by the last upload, but a previous change that's been dormant until people applied updates with the recent upload
<chrisccoulson> I'll wait for juliank to respond
<juliank> Im not really here atm
<juliank> This is not a regression in this update in any case
<chrisccoulson> juliank, ah, no worries. Do you want me to escalate?
<juliank> And it's only one user?
<chrisccoulson> I don't know - I think hggdh has more insight there
<juliank> Continuation lines seem wrong to have in that file
<hggdh> juliank: I reproduced it
<juliank> If you add a continuation line between 8.14 and 8.15, you can remove the continuation line again
<juliank> A future update should probably handle that, but a continuation line here is not expected, and there's no point rolling it back as that's a non default unexpected thing
<hggdh> we have no current issues on Azure (to my knowledge), but this is rather new, and I am do not really expect people to pass tens of parameters to the kernel
<hggdh> juliank: it worked before per the OP. Also works if you add continuation lines after upgrading
<juliank> That does not sound correct
<juliank> You should see the same issue upgrading from 8.13 to 8.14 or 8.12 to 8.14
<hggdh> OP on previous version: looks like it's 2.02-2ubuntu8.13 .... ~ mid-Dec '19
<juliank> * to 8.13
<juliank> So they made a change in their files between those and that blew up after the upgrade
<Eickmeyer> Release team: The developer of Carla wants to get RC2 out shortly with a goal of final release on April 16th, the day before Final Freeze. What process do I need to go through to get the final release in before Final Freeze, such as exceptions?
<ahasenack> Eickmeyer: it's called a Feature Freeze Exception
<ahasenack> Eickmeyer: this is the process: https://wiki.ubuntu.com/FreezeExceptionProcess
<Eickmeyer> ahasenack: There are no new features between RC1 (in the repos) and final.
<ahasenack> Eickmeyer: you mean rc2?
<ahasenack> btw, I'm not in the release team, I just lurk here
<Eickmeyer> ahasenack: RC2 will be released shortly, but there are no new features between RC1 and RC2. Feature Freeze only applies to *features* not bug fixes.
<ahasenack> right
<ahasenack> so that is described in that page too
<Eickmeyer> I'm just concerned since final release will be a day before final freeze.
<ahasenack> "FeatureFreeze for bugfix-only updates"
<ahasenack> I think for final freeze only really critical uploads are accepted
<Eickmeyer> So, simply stating "bugfix-only upload" in the changelog should do the trick.
<ahasenack> https://wiki.ubuntu.com/FinalFreeze
<Eickmeyer> Yes, and I get that.
<Eickmeyer> Not my first rodeo.
<ahasenack> cool
<Eickmeyer> Perhaps I just wanted to warn the release team so that they know what I'm doing when I do the uploads as I have PPU on that package.
<ahasenack> it's good to check in here for that final release
-queuebot:#ubuntu-release- Unapproved: linux-firmware (eoan-proposed/main) [1.183.4 => 1.183.5] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: linux-firmware (bionic-proposed/main) [1.173.16 => 1.173.17] (core, kernel)
<rbalint> hi all, i've an open ffe for systemd 245.2, if you would like to give it a try please check out ppa:ci-train-ppa-service/3801
<rbalint> so far it looks good :-)
#ubuntu-release 2020-03-20
<kanashiro> vorlon, I created this bug to request a FFe for chef: https://bugs.launchpad.net/ubuntu/+source/chef/+bug/1868187
<ubot5> Ubuntu bug 1868187 in chef (Ubuntu) "[FFe] Sync version 15.8.25.3.gcf41df6a2-6 from Debian unstable" [Undecided,New]
<kanashiro> let me know if more information is needed
<tumbleweed> kanashiro: I know the story here, so easy to approve
<tumbleweed> kanashiro: need sponsorship?
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1036.40~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1036.40~16.04.1]
<LocutusOfBorg> hello, does anybody have a clue about https://bugs.launchpad.net/ubuntu/+source/unicode-data/+bug/1868242 ?
<ubot5> Ubuntu bug 1868242 in unicode-data (Ubuntu) "[Ffe] unicode-data" [Undecided,New]
<Laney> what kind of FFe is that?
<Laney> please flesh it out a bit and then I can take a look
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-5.3 [amd64] (bionic-proposed/main) [5.3.0-1015.16~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-5.3 [amd64] (bionic-proposed) [5.3.0-1015.16~18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.3 [amd64] (bionic-proposed/universe) [5.3.0-1015.16~18.04.2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [5.3.0-43.36~18.04.2] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [5.3.0-43.36~18.04.2] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [arm64] (bionic-proposed/main) [5.3.0-43.36~18.04.2] (kernel)
<LocutusOfBorg> Laney, I'm working on it yes
<doko> bdmurray (& sforshee): apport needs an autopkg test update for some kernel packaging reorganisation
<kanashiro> tumbleweed, great, and yes, I need sponsorship. Do you want to do it for me? Otherwise I can find someone else
<doko> LocutusOfBorg: frama-c is missing in the coq removal issue
<doko> which needs adjustment of creduce's build deps
<doko> kanashiro: which packages need syncs?
<kanashiro> doko, I just filed 2 sync requests: https://bugs.launchpad.net/bugs/1868250 and https://bugs.launchpad.net/bugs/186825
<ubot5> Ubuntu bug 1868250 in Ubuntu "Sync ruby-ffi-libarchive 1.0.0+-2 (universe) from Debian unstable (main)" [Wishlist,New]
<ubot5> Ubuntu bug 186825 in Checkbox "Command line options should support --delay" [Critical,Fix released]
<kanashiro> ruby-ffi-libarchive and ruby-train
<kanashiro> those are new packages
<kanashiro> the rest is here in the bug report: https://bugs.launchpad.net/ubuntu/+source/chef/+bug/1868187
<ubot5> Ubuntu bug 1868187 in chef (Ubuntu) "[FFe] Sync version 15.8.25.3.gcf41df6a2-6 from Debian unstable" [Medium,Confirmed]
<kanashiro> sorry, I linked the wrong bug for ruby-train, this is the right one: https://bugs.launchpad.net/bugs/1868251
<ubot5> Ubuntu bug 1868251 in Ubuntu "Sync ruby-train 3.2.20-2 (universe) from Debian unstable (main)" [Wishlist,New]
<kanashiro> doko, could you handle those uploads for me? Or do I need to find someone else?
-queuebot:#ubuntu-release- New sync: ruby-ffi-libarchive (focal-proposed/primary) [1.0.0+-2]
-queuebot:#ubuntu-release- New: accepted ruby-ffi-libarchive [sync] (focal-proposed) [1.0.0+-2]
<doko> syncpackage takes ages
-queuebot:#ubuntu-release- New binary: ruby-ffi-libarchive [amd64] (focal-proposed/none) [1.0.0+-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted ruby-ffi-libarchive [amd64] (focal-proposed) [1.0.0+-2]
<kanashiro> doko about the existent packages please start with ruby-mixlib-log
<kanashiro> some other packages depend on it
-queuebot:#ubuntu-release- New binary: ruby-train [amd64] (focal-proposed/universe) [3.2.20-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted ruby-train [amd64] (focal-proposed) [3.2.20-2]
<doko> kanashiro: synced
<kanashiro> doko, you mean the 2 new packages, right?
<doko> plus ruby-mixlib-log
<doko> sforshee, apw: there are bug reports like https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1868169.  I assume that will only change once kernels and drivers are rebuilt with 7.5?  who would take care about that?
<ubot5> Ubuntu bug 1868169 in gcc-defaults (Ubuntu) "Cannot build nvidia driver via dkms because compiler doesn't match kernel" [Undecided,Confirmed]
<kanashiro> thanks doko, I can handle the other packages with rafaeldtinoco
-queuebot:#ubuntu-release- Unapproved: s390-tools (focal-proposed/main) [2.12.0-0ubuntu2 => 2.12.0-0ubuntu3] (core)
<doko> kanashiro: let's continue, so that we are ready once steve is awake
<kanashiro> doko, I am already doing it with rafaeldtinoco
<kanashiro> it will be ready on time
<doko> ta
<sforshee> doko: yes, that's only fixed by having a kernel built with the same compiler version. The kernels in bionic-proposed are built with the new version, but unfortunately are not set to be released until Apr 6
<doko> sforshee: good enough for me
<sforshee> doko: seems that compiler version bumps ought be coordinated with the kernel team
<doko> sforshee: dude, that has been coordinated, since the Paris sprint ... and teward as well
<sforshee> the worst case could be much longer with 3-week sru cycles, and having to rebuild kernels mid-cycle is not cheap
<teward> doko I was poked?
<doko> I'm fine with waiting, so maybe we should leave some comment int the bugs
<doko> teward: your OK for 7.5 was not coordinated with the kernel team ;p
<teward> E:CONTEXTMISSING
<doko> sforshee: otoh, I think these checks are still from the time, when major GCC releases had version bumps in the minor version. Time to fix that?
<sforshee> doko: perhaps, I think that specific check comes from the nvidia packages and not the kernel itself
<doko> teward: sorry, I meant to ping trudd
<teward> All good
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (eoan-proposed) [1.183.5]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (bionic-proposed) [1.173.17]
<tjaalton> rafaeldtinoco: hi, your kmod upload(s) have two changes, only one of them has a bug on lp
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (eoan-proposed) [0.8.1-1ubuntu14.4]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (bionic-proposed) [0.7.5-1ubuntu16.9]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.3 [amd64] (bionic-proposed) [5.3.0-1015.16~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [arm64] (bionic-proposed) [5.3.0-43.36~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [5.3.0-43.36~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [5.3.0-43.36~18.04.2]
<rafaeldtinoco> tjaalton: lemme check
<kanashiro> ohai is taking so long to land in proposed
<doko> bryce: did you already ask for the demotion of php7.3 in -proposed? php-recode still pulls it into main
<rafaeldtinoco> tjaalton: thats because without the second it FTBFS
<rafaeldtinoco> I did not create a LP bug as it already has a debian bug and its a clean cherry-pick
<rafaeldtinoco> let me know if you want me to change it, i thought it was documented enough
<rafaeldtinoco> thanks for reviewing it
<tjaalton> ok, guess it's clear enough
<rafaeldtinoco> tku!
-queuebot:#ubuntu-release- Unapproved: accepted kmod [source] (eoan-proposed) [26-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted kmod [source] (bionic-proposed) [24-1ubuntu3.3]
<LocutusOfBorg> doko, adding it
<bdmurray> doko: I'll take care of apport today
<ahasenack> hi ubuntu-release, another FFe your way if you please: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1868272
<ubot5> Ubuntu bug 1868272 in bind9 (Ubuntu) "FFe: bind9 9.16.1 update" [Undecided,New]
<ahasenack> were it not for one change, the FFe wouldn't be required
<ahasenack> doko: that's the glibc question I asked yesterday ^
<bryce> doko, I've been working on clearing the remaining migration for php-defaults before doing that, but am not sure if that's absolutely required or not.  I can at least get the paperwork started on that.
<doko> bryce: there's no paperwork to do. I just don't understand what is pulling that binary package into main
<doko> in -proposed
<bryce> doko php-defaults?
<doko> bryce: 73ubuntu2 drops that package ...
<bryce> doko, hasn't finished migration yet
<bryce> doko, it's being held back by php-horde-* and a few other things
<doko> yeah, and somebody demoted it. now promoting php7.3 again
<doko> bryce: if you look at php-horde-*, please also look at php-tijsverkoyen-css-to-inline-styles
<doko> bryce: ahh, wait, you don't need to fix the autopkg tests for php7.3, they are ignored
<bryce> doko, I can take a look at php-tijsverkoyen-css-to-inline-styles
<doko> bryce: no, not needed
-queuebot:#ubuntu-release- New binary: chef [amd64] (focal-proposed/universe) [15.8.25.3.gcf41df6a2-1] (no packageset)
<Eickmeyer> Hey release team: I have a new FFe for you at bug 1868280
<ubot5> bug 1868280 in materia-gtk-theme (Ubuntu) "[FFe] [UIFe] Please update materia-gtk-theme to 20200320 (latest release)" [Undecided,New] https://launchpad.net/bugs/1868280
<bryce> doko, regarding php-horde I think best to remove - lp: #1868281
<ubot5> Launchpad bug 1868281 in php-horde (Ubuntu) "Please remove php-horde and php-horde-* from focal" [Undecided,New] https://launchpad.net/bugs/1868281
<teward> doko: re: php-horde does it have any rdeps?  If not, I'd remove because orphaned.  my 2 cents
<doko> teward: the problem is not to remove it, but to keep it removed if debian uploads new packages. so I assume blacklisting is the way to go ...
<teward> yep that'd need a sync blacklist
<teward> (same criterion because Orphaned and Removed Here)
<cjwatson> Hm?  Packages that have been removed aren't automatically auto-synced again without a human being in the loop
<cjwatson> auto-sync explicitly checks for previously Deleted publications if the package isn't currently in the target series
<rbasak> We can just remove from the release pocket anyway, can't we?
<rbasak> If they later migrate from proposed then that won't be a problem?
<rbasak> (I appreciate that technically that probably means a copy _to_ the proposed pocket before a deletion or whatevevr)
<doko> it will be a problem, because these are triggering autopkg tests again
<vorlon> cjwatson: I'm pretty sure I changed that behavior several years ago
<vorlon> to explicitly move the needle on the human cost of removing never-gonna-migrate packages from -proposed that might get fixed later in Debian
<cjwatson> vorlon: Huh, so you did
<cjwatson> Fair enough
-queuebot:#ubuntu-release- New binary: chef [amd64] (focal-proposed/universe) [15.8.25.3.gcf41df6a2-6] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [s390x] (focal-proposed) [2.12.0-0ubuntu3]
<LocutusOfBorg> doko, I no change rebuilt frama-c against new coq, is that enough for the removal process?
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/frama-c/20191204+calcium-0ubuntu2
<LocutusOfBorg> doko, seems frama-c is safe, because it depends on why3 without coq on the armhf and s390x archs   coq [amd64 arm64 ppc64 ppc64el sh4],
-queuebot:#ubuntu-release- Unapproved: accepted apr-util [source] (eoan-proposed) [1.6.1-4ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-keyring [source] (eoan-proposed) [18.0.1-1ubuntu1]
<kanashiro> I have some removal requests because of ruby 2.7 transition:
<kanashiro> https://bugs.launchpad.net/ubuntu/+source/sup-mail/+bug/1868311
<ubot5> Ubuntu bug 1868311 in sup-mail (Ubuntu) "[RM] Removal request of sup-mail/0.22.1-3 from Focal" [Undecided,New]
<kanashiro> https://bugs.launchpad.net/ubuntu/+source/ruby-session/+bug/1868312
<ubot5> Ubuntu bug 1868312 in ruby-session (Ubuntu) "[RM] Removal request of ruby-session/3.2.0-3 from Focal" [Undecided,New]
<kanashiro> https://bugs.launchpad.net/ubuntu/+source/ruby-puppetlabs-spec-helper/+bug/1868313
<ubot5> Ubuntu bug 1868313 in ruby-puppetlabs-spec-helper (Ubuntu) "[RM] Removal request of ruby-puppetlabs-spec-helper/2.6.2-1 from Focal" [Undecided,New]
<kanashiro> https://bugs.launchpad.net/ubuntu/+source/ruby-rspec-puppet/+bug/1868314
<ubot5> Ubuntu bug 1868314 in ruby-rspec-puppet (Ubuntu) "[RM] Removal request of ruby-rspec-puppet/2.7.8-1 from Focal" [Undecided,New]
<kanashiro> https://bugs.launchpad.net/ubuntu/+source/ruby-grape/+bug/1868318
<ubot5> Ubuntu bug 1868318 in ruby-grape (Ubuntu) "[RM] Removal request of ruby-grape/1.1.0-2 from Focal " [Undecided,New]
-queuebot:#ubuntu-release- New: accepted chef [amd64] (focal-proposed) [15.8.25.3.gcf41df6a2-1]
-queuebot:#ubuntu-release- New: accepted chef [amd64] (focal-proposed) [15.8.25.3.gcf41df6a2-6]
<kanashiro> vorlon, ruby-gnome autopkgtest is failing against ruby2.7 only on ppc64el, but it was failing with the same error log messages when triggered by webkit2gtk and now it is passing for webkit2gtk
<kanashiro> here is the upstream bug: https://github.com/ruby-gnome/ruby-gnome/issues/1389
<gitbot> ruby-gnome issue 1389 in ruby-gnome "load_uri(TestWebKit2GtkWebView::#load_uri) test failure with newer webkit" [Closed]
<kanashiro> could we just badtest it?
<vorlon> kanashiro: see changelog, https://launchpad.net/ubuntu/+source/webkit2gtk/2.28.0-1ubuntu2
<vorlon> I've already retried the test
<vorlon> it should clear
<kanashiro> ah great, thanks
#ubuntu-release 2020-03-21
-queuebot:#ubuntu-release- New binary: geocode-glib [i386] (focal-proposed/main) [3.26.2-2] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: geocode-glib [s390x] (focal-proposed/main) [3.26.2-2] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: geocode-glib [ppc64el] (focal-proposed/main) [3.26.2-2] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: geocode-glib [amd64] (focal-proposed/main) [3.26.2-2] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: geocode-glib [armhf] (focal-proposed/main) [3.26.2-2] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: geocode-glib [arm64] (focal-proposed/main) [3.26.2-2] (desktop-core, i386-whitelist)
<LocutusOfBorg> doko, dk-python sync?
-queuebot:#ubuntu-release- New: accepted geocode-glib [amd64] (focal-proposed) [3.26.2-2]
-queuebot:#ubuntu-release- New: accepted geocode-glib [armhf] (focal-proposed) [3.26.2-2]
-queuebot:#ubuntu-release- New: accepted geocode-glib [ppc64el] (focal-proposed) [3.26.2-2]
-queuebot:#ubuntu-release- New: accepted geocode-glib [arm64] (focal-proposed) [3.26.2-2]
-queuebot:#ubuntu-release- New: accepted geocode-glib [s390x] (focal-proposed) [3.26.2-2]
-queuebot:#ubuntu-release- New: accepted geocode-glib [i386] (focal-proposed) [3.26.2-2]
-queuebot:#ubuntu-release- New binary: wcc [amd64] (focal-proposed/universe) [0.0.2+dfsg-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted wcc [amd64] (focal-proposed) [0.0.2+dfsg-4ubuntu1]
<mparillo> We can enter bugs against daily images at https://iso.qa.ubuntu.com/, but it seems as if http://iso.qa.ubuntu.com/ renders better for me. (1) Can anybody duplicate this? (2) If so, is this expected? (3) If not, is there a launchpad.net component I should use to raise this?
<Eickmeyer> Can I please get some traction on bug 1868280? I don't want an incident happening like last release where a FFe request of mine went completely unanswered.
<ubot5> bug 1868280 in materia-gtk-theme (Ubuntu) "[FFe] [UIFe] Please update materia-gtk-theme to 20200320 (latest release)" [Undecided,New] https://launchpad.net/bugs/1868280
#ubuntu-release 2020-03-22
<xnox> Eickmeyer:  there is "report a problem with this website" at the bottom of it
<xnox> Eickmeyer:  something does look broken
<Eickmeyer> xnox: With regards to that bug?
<xnox> Eickmeyer:  bah
<xnox> Eickmeyer:  unping
<Eickmeyer> xnox: hehe
<xnox> mparillo:  there is "report a problem with this website" at the bottom of it
<xnox> mparillo:  and it does look odd
<mparillo> Sorry for not noticing that link at the bottom. And thanks for verifying, so I opened https://bugs.launchpad.net/ubuntu-qa-website/+bug/1868413
<ubot5> Error: ubuntu bug 1868413 not found
<mparillo> Ahh, not found because I marked it as a security bug.
<xnox> mparillo:  i do not believe it is security bug
<xnox> my browser, in debug console says:
<xnox> 205172
<xnox> bah
<xnox> Mixed Content: The page at 'https://iso.qa.ubuntu.com/' was loaded over HTTPS, but requested an insecure script 'http://iso.qa.ubuntu.com/sites/default/files/js/js_VaTlC5jNdxR2e4HzWsuiV1jhDftON6pzITcrr9IQmXA.js'. This request has been blocked; the content must be served over HTTPS.
<xnox> meaning, absolute urls are used for loading js, instead of relative, thus https is not used for js
<mparillo> And that script is used to access the CSS which is on HTTP. Security team considers this Medium, Triaged.
<mparillo> Thank you for your help.
<bluesabre> Hello Release Team! I just submitted a pair of UIFe for Xubuntu's themes that require no changes to documentation or translations. Would you mind acking https://bugs.launchpad.net/ubuntu/+source/elementary-xfce/+bug/1868457 and https://bugs.launchpad.net/ubuntu/+source/greybird-gtk-theme/+bug/1868459 ? Thanks a bunch.
<ubot5> Ubuntu bug 1868457 in elementary-xfce (Ubuntu) "[UIFe] elementary-xfce 0.15 for focal" [Wishlist,New]
<ubot5> Ubuntu bug 1868459 in greybird-gtk-theme (Ubuntu) "[UIFe] greybird-gtk-theme 3.22.12 for focal" [Wishlist,New]
<stgraber> would appreciate someone on ubuntu-release reviewing https://bugs.launchpad.net/ubuntu/+source/lxcfs/+bug/1867541
<ubot5> Ubuntu bug 1867541 in lxcfs (Ubuntu) "[FFe] LXCFS 4.0 LTS" [Undecided,New]
<stgraber> we have 4.0.1 released now and would be ready to upload something early in the week
<stgraber> also, if an ubuntu-archive member wouldn't mind reviewing that lxd-agent-loader package that's been sitting in New for the past 6 weeks or so, that'd be neat :)
<oibaf> Also suggesting https://bugs.launchpad.net/ubuntu/+source/pdfarranger/+bug/1867549
<ubot5> Ubuntu bug 1867549 in pdfarranger (Ubuntu) "FFe: Sync pdfarranger 1.4.2-1 (universe) from Debian sid (main)" [Undecided,Confirmed]
<oibaf> and https://bugs.launchpad.net/ubuntu/+source/warzone2100/+bug/1867552
<ubot5> Ubuntu bug 1867552 in warzone2100 (Ubuntu) "FFe: Sync warzone2100 3.3.0-2 (universe) from Debian sid (main)" [Undecided,New]
<oibaf> and https://bugs.launchpad.net/ubuntu/+source/ipset/+bug/1867551
<ubot5> Ubuntu bug 1867551 in ipset (Ubuntu) "FFe: Sync ipset 7.5-1~exp1 (main) from Debian experimental (main)" [Undecided,New]
<LocutusOfBorg> oibaf, the pdfarranger is syncd
<LocutusOfBorg> for ipset, please get in touch with seb128
<LocutusOfBorg> and warzone... meh it needs a RT member
<Eickmeyer> Can I please get some traction on bug 1868280? It's a simple theme update with no changes to documentation or translations. Just needs a simple Ack. teward and I can handle the rest.
<ubot5> bug 1868280 in materia-gtk-theme (Ubuntu) "[FFe] [UIFe] Please update materia-gtk-theme to 20200320 (latest release)" [Undecided,New] https://launchpad.net/bugs/1868280
<teward> *was pinged*
<Eickmeyer> teward: Didn't even know you were awake (yet).
<teward> if no exception freezes are affected here we can JFDI but wasn't sure if it needed a UIFe
<teward> been up all day Eickmeyer lol
<Eickmeyer> teward: Hydration does wonders. ;)
<Eickmeyer> teward: Considering it allows for compatiblity with gnome-shell, I really *want* to JFDI, but some clarification on whether or not it needs a UIFe would be nice.
<teward> yep
-queuebot:#ubuntu-release- New: accepted lxd-agent-loader [source] (focal-proposed) [0.1]
<cjwatson> stgraber: done.  you might want to subscribe to bug mail about it
<stgraber> cjwatson: will do, thanks!
-queuebot:#ubuntu-release- New binary: lxd-agent-loader [amd64] (focal-proposed/none) [0.1] (no packageset)
<cjwatson> stgraber: (https://bugs.launchpad.net/ubuntu/+source/lxd-agent-loader/+bug/1868496)
<ubot5> Ubuntu bug 1868496 in lxd-agent-loader (Ubuntu) "Wrong upstream information in debian/copyright?" [Undecided,New]
<stgraber> cjwatson: ah yeah, I was wondering about that. Technically those units are copy/pasted from driver_qemu.go in the upstream LXD repo, so we'll typically be doing changes in the upstream LXD repo before putting the same change in the package.
<cjwatson> stgraber: Ah.  Maybe a Comment field to clarify that then.
<stgraber> yeah, will do
-queuebot:#ubuntu-release- New: accepted lxd-agent-loader [amd64] (focal-proposed) [0.1]
<oibaf> LocutusOfBorg : grazie, all 3 packages are synced (strange I didn't get mail notifications), if possible please also sync this: https://bugs.launchpad.net/ubuntu/+source/pikepdf/+bug/1867504
<ubot5> Ubuntu bug 1867504 in pikepdf (Ubuntu) "Sync pikepdf 1.10.2+dfsg-1 (universe) from Debian unstable (main)" [Undecided,Confirmed]
