#ubuntu-release 2010-06-28
<ogasawara> cjwatson: not sure if you're up.  but just CC'd you on an email I got which would require what I consider a late kernel upload and wanted to get your thoughts.
<ogasawara> cjwatson: I also CC'd rick (as robbie is on holiday).  I wasn't sure who else on the release team to include.
<cjwatson> thanks, replied
<ara> morning
<ogra> cjwatson, so is there any chance we can pre-promote jasper-initramfs without MIR (alternatively i can set COMP to carry universe in livecd-rootfs as long as jasper is used)
<cjwatson> ogra: that doesn't seem necessary, since asac approved it about 20 minutes before you said that
<ogra> huh ?
 * ogra checks
<ogra> i only saw inprogress
<cjwatson> ogra: can you please seed it somewhere?
<ogra> sure, any preference on your side ?
<ogra> (else i'll just use supported)
<cjwatson> casper is in supported-installer-desktop; I'd use that
<cjwatson> (platform.maverick)
<ogra> oki
<ogra> hmm, why didnt i get the approved bugmail, weird
<cjwatson> I've promoted it
<ogra> thanks
<ogra> ok, seeded
<ogra> Keybuk, yo ...
<Keybuk> ogra: hey, how you doing?
<ogra> Keybuk, great, and yourself ?
<Keybuk> feeling a bit more rested now
<ogra> as usual i have a question ;) ... i need some hint on a udev rule ... if i add a rule like: KERNEL=="<mydevice>", ENV{ACL_MANAGE}="1" ... will mydevice be accessible for all local users by default ?
<ogra> or do i have to do anything additional
<Keybuk> it will be ACL managed
<Keybuk> but you still need rules as to what ACLs should be managed
<ogra> (it is for a specisl video decoding device on OMAP4 HW ... currently there is a rule that adds the device to the video group which is wrong imho)
<ogra> hmm, where do i set such rules ? consolekit ?
<Keybuk> PolicyKit I think
<Keybuk> I'm not entirely sure
<ogra> ok, thanks
<Keybuk> it might be implied
<ogra> i'll use mdz's recent blogpost ;)
<ogra> in case it doesnt work
<Keybuk> ie. there might be just one big "access local devices" policy
<ogra> i thought thats the default, but if there isnt i'll add a special PK rule
<ogra> thanks for the help :)
<Keybuk> I think it might be the default
 * ogra sees /lib/udev/rules.d/61-gnome-bluetooth-rfkill.rules ... i guess it is the default then
<ogra> seems to have the same syntax
<ogra> oh, i didnt notice i'm talking in -release, sorry for the noise, that was supposed to be in -devel :)
<ogra> lamont, acorn still has livecd-roofs 1.120 :(
<lamont> ogra: yeah - I figured that out.  It has 1.124 now, and upgrades everytime BuildLiveCD runs
<ogra> lamont, gracias
 * ogra tries another livefs build and prays that evolition isnt out of sync again
<lamont> good luck
<ogra> hmm, i wonder why it didnt return
<ogra> i still see BuildLiveCD in the processlist on antimony
<ogra> the log complained about missing genext2fs about 20min ago already
<ogra> which should have let it fail
<lamont> there's a build that started on acorn about 1.5 hrs ago
<ogra> right
<ogra> oh
<ogra> err
<lamont> 8 min ago was when genext2fs started in that run
 * ogra checks again if he chekced the right log
<ogra> oh man
 * ogra hangs head in shame
<ogra> i looked at the 20100626.1 log
<ogra> not at 28.1
<lamont> I always look in /latest. :-[
<lamont> ~buildd//LiveCD/maverick/ubuntu-netbook-omap/latest/livecd-20100628.1-armel-omap.out
<ogra> yeah, seems its all fine
<lamont> though to be fair, being on the machine makes it easier, what with wildcards and all that.
<ogra> i developed a habit to click in w3m recently instead of using the cursor
<ogra> makes me a lot less cautious
<lamont> Jun 28 06:18:40 mix libvirtd: 06:18:40.944: error : udevStrToLong_ui:73 : Failed to convert 'ff' to unsigned int#012
<lamont> well done, libvirt
<Riddell> result of today's kubuntu CD image:  "can't open /scripts/casper"
<cjwatson> let's see if it reproduces in Ubuntu; I'm 84% through an rsync
<cjwatson> if anyone processes NBS, please be very careful - it's incorrectly listing a bunch of -6 udebs for some reason
<cjwatson> (kernel)
<cjwatson> probably best leave it for a bit until it settles down
<cjwatson> yes, rather looks as though /scripts/casper isn't in the initramfs; I guess this is a regression due to new initramfs-tools
 * cjwatson goes to peer at the logs
<ogra> lamont, hmm, do you have any way to get more info about a livefs build than the log ? the log of my ext3 fs build seems to indicate it worked fine, but i got a failed message on antimony
<ogra> (and there seems to be no ext3 fs produced either)
<lamont> ogra: well, I have dmesg output and such, but basically just the log
<lamont> acorn?
<ogra> yeah
<lamont> dmesg says nothing
<cjwatson> ah, hm, I forgot to edit the seeds when we agreed to unhardcode casper from livecd-rootfs
 * cjwatson fixes
<ogra> lamont, i wonder if the fsck we do at the end tears down livecd.sh sine e2fsck has to exit nonzero
<ogra> bug 583317 enforces that
<ubot4> Launchpad bug 583317 in genext2fs (Ubuntu) "genext2fs creates revision 0 filesystems instead of revision 1 (affects: 1) (heat: 104)" [Undecided,Confirmed] https://launchpad.net/bugs/583317
<lamont> ew.  sounds like a trivial fix though,  yes?
<lamont> (slap an || true in place, maybe???_)
<ogra> just an || true ?
<ogra> yeah
<ogra> fixed and uploaded
<cjwatson> Riddell: starting a rebuild sequence now, which should fix this
<cjwatson> hm, aside from wubi being broken, I'll do that for tomorrow's builds
<cjwatson> hm, and I got it wrong anyway.  never mind, it'll work well enough for this set of builds and I'll back it out in favour of the right fix after that
<cjwatson> (it'll just break any jasper-requiring builds that happen between now and then)
<ogra> cjwatson, dont worry+
<ogra> i'm all manual still anyway and livecd-rootfs will take a while to be ready
<Riddell> cjwatson: must be about time for a freeze notice, should I send one to ubuntu-devel-announce?
<cjwatson> Riddell: I looked through recent history and they generally seemed to be first thing Tuesday morning
<cjwatson> Riddell: if you want to go early I don't desperately mind, though
<Riddell> ok I'll be patient
<cjwatson> build queues are pretty inconveniently long right now
<ogasawara> cjwatson, ttx: in the release team meeting last friday we agreed, "if on Wednesday bug 588861 is not fixed in kernel, then can ogasawara prepare the PPA and then ttx can release note the PPA, otherwise ttx to release note to dist-upgrade"
<ubot4> Launchpad bug 588861 in linux (Ubuntu Maverick) (and 4 other projects) ""pad block corrupted" error when trying to register an image with 2.6.34 kernel (affects: 1) (heat: 12)" [High,In progress] https://launchpad.net/bugs/588861
<ogasawara> cjwatson, ttx: we've already uploaded a kernel which contains the fix to our PPA
<ogasawara> cjwatson, ttx: do you want me to wait to upload the official kernel to the archive until immediately after Alpha2 is released?
<ogasawara> cjwatson, ttx: or would you prefer I upload the kernel sooner (ie now) so it's immediately available for people to dist-upgrade?
<ScottK> ogasawara: It might be nice to wait until the buildds aren't quite so clogged if it's not going to be accepted until after Alpha 2.
<ogasawara> ScottK: makes sense
<cjwatson> I think late Wednesday would be OK
<ogasawara> cjwatson: ack
#ubuntu-release 2010-06-29
<Riddell> 20100628.1 kubuntu desktop image is in reasonable shape
<Riddell> oversized though, a rebuild should fix that, I changed the seeds and meta package
<cjwatson> just langpacks, or more?
<ScottK> cjwatson: It was more.  We're trying to consolidate the desktop and netbook ISOs into a single image so it grew a bit.
<ogra> lamont, we have a "tiny" prob with BuildLiveCD ... seems somewheer there was introduced a var called SUBARCHARG that gets handed over to livecd.sh but is never set anywhere
<ttx> ogasawara: late wednesday sounds ok to me.
 * pitti waves hello
<pitti> cjwatson: so is it up to us to do alpha-2 again then? I didn't really talk about that with anyone so far
<pitti> I'll start with discussing the oversizedness
<cjwatson> I think so; I asked Keybuk if he could help out as well
<pitti> http://people.canonical.com/~ubuntu-archive/component-mismatches.txt *sigh*
<cjwatson> I've been looking at installability problems
<cjwatson> though I also have a grub2 bug I want to fix first, as it's on the list for 10.04.1
<pitti> cjwatson: ok, then do that, I'll start with poking c-m
<cjwatson> building some candidate lucid CDs as well
<cjwatson> might as well get started on that
<cjwatson> need to do something about omap kernel seeding
<cjwatson> not to mention what d-i should be built against
 * cjwatson wonders why current sparc kernel udebs are NBS
<ara> who is going to send the alpha 2 freeze announcement?
<cjwatson> oh, I'll do that now
<Keybuk> it's been quite a while since I've done any archive/release stuff
<pitti> hello Keybuk, how are you?
<Keybuk> not so bad, you?
<pitti> quite well, thanks
<cjwatson> ara: sent
<ara> cjwatson, thanks :)
<Riddell> kubuntu CDs need a rebuild, kubuntu-meta wasn't compiled in time on amd64 so it's still oversized there
<cjwatson> which CDs, alternate or desktop or both?
<Riddell> both
<cjwatson> in progress now
<Riddell> thanks
<cjwatson> I love this business of having a huge external disk to keep CD images on
<cjwatson> and virtual machines
<pitti> cjwatson: "huge external disk to keep CD images on" -> isn't that called "lillypilly"? I have one as well, quite nice :)
<pitti> erm, no, antimony I mean
<cjwatson> I have this bandwidth problem
<Keybuk> cjwatson: it could be worse, you could be on Virgin Media
<pitti> does anyone know how to call cd-size-analysis? With two .isos it gives empty output, and with list files it looks implausible
<pitti> and the code only calls isoinfo non ARGV[0]
<pitti> s/non/on/
<pitti> but at the same time it uses the package list parsing code on argv[0] and [1]
<pitti> this doesn't make sense to me
<pitti> cjwatson: is yuour lp-remove-package still actually runnign? you started it more than half an hour ago
<cjwatson> pitti: sorry, finished now
<pitti> cjwatson: thanks; killed netbook-launcher
<ogra> pitti, if that helps you, i think netbook-launcher-efl can become armel only but i guess that requires some seed fiddling
<pitti> ogra: not really; I was cleaning up component-mismatches and installatibliy
<ogra> ah
<pitti> now I'm wading through the 20 MB of fat that we grew since alpha-1
<ogra> i thought oversizedness
<pitti> I have a list of the new pacakges, which account for 6
<pitti> no idea where the other 14 come from
<cjwatson> Riddell: amd64 desktop build failed, BTW
<ogra> hrm, there is some gtk+ fallout atm
<ogra> at least i see it on armel
<Riddell> cjwatson: tsk
<ScottK> 4.4.90 isn't built on amd64 yet, so I'd have been a bit suprised if it worked.
<ScottK> Actually it's just now finishing on i386.
<ScottK> cjwatson: Would you please rescore kdeartwork kdeplasma-addons for amd64?  That should get everything we need for Alpha 2 images done.
<cjwatson> done (just did it on all arches)
<ScottK> Thanks.
<ScottK> There's a roughly zero percent chance of useful armel images for Kubuntu (of any flavor) for this milestone.
<ScottK> FYI
<ogra> ScottK, well, the arm team is happy if we make A2 at all since we completely redesigned the kind of images we build
<ogra> ScottK, on a sidenote all armel builds are disabled atm and i'll only enable ubuntu-netbook once we know it succeeds building, we can talk about kubuntu-netbook for A3
<ScottK> ogra: I understand.  Just wanted people know there was no point in even trying for that one.
<ogra> right, wont be tried
<Riddell> ScottK: actually the amd64 issue was all seb128's fault  "  libgtk2.0-bin: Depends: libgtk2.0-0 (>= 2.21.2-0ubuntu4) but 2.21.2-0ubuntu3 is to be installed"
<ogra> yeh
<ogra> same on armel
<seb128> right, and I just did another gtk upload
<seb128> sorry about that
<Riddell> we'll let you off seb128, but only because you're cute :)
<ogra> though i wasnt aware that kubuntu ships gtk
<seb128> lol
<Riddell> ogra: we try not to but openoffice seems to bring it in these days
<ScottK> Riddell: I think we want all of 4.4.90 on the alpha 2 images, so it's best to have it finished.
<ogra> ah
<ogra> Riddell, time to switch to the weboffice stuff we use on armel ;)
<ScottK> The would definitely help ISO sizing.
<ScottK> We could ship all kinds of games then.
<ogra> heh
<ogra> kubuntu - the new gamers distro
<Riddell> ScottK: plasma-netbook seems to be working on the kubuntu desktop images so I think we can not include kubuntu netbook in this alpha
<Riddell> well when I say working, it's got problems, but not due to the new pick-your-workspace magic
<ScottK> Riddell: Should we update kubuntu-netbook to be a transitional package then?
<Riddell> ScottK: yes can do
<pitti> cjwatson: FYI, I wrote a script "iso-deb-size-compare" which does what I need
<pitti> http://pastebin.com/Jzt2EgDq is the output
<pitti> oops, and now with correct total added size: http://pastebin.com/3MU8aQm6
<pitti> so, gnome-icon-theme, samba/smbclient, and ghostscript
 * pitti drops samba from ship *shrug*
<pitti> we have a nice auto-installer now
<ScottK> cjwatson: OOo is depwait on libtextcat-data-utf8 just on i386.  Since it's already built on amd64, it might make sense to pre-promote libtextcat-data-utf8 so we don't have version skew between the archs.
<pitti> the MIR says it's going away again, but I promote it now and milestone the bug
<ScottK> Sounds good.
<ara> do we have an eta to start seeing images to test in the iso tracker?
<cjwatson> I'm poking ev about a ubiquity upload, which I'd like to have first
<ttx> pitti, cjwatson: when are the first ubuntu-server A2 milestone candidates expected ?
<pitti> I'm off for 30 mins, bbl
 * ttx currently sees a 20100629.2
<Riddell> all of kde built now, kubuntu images can be made whenever
 * Riddell wonders what colin is editing in ./kubuntu/daily/20100629.1/.htaccess
<cjwatson> Riddell: bug 571852
<ubot4> Launchpad bug 571852 in ubuntu (and 1 other project) "poor description of .zsync download files on releases.ubuntu.com (affects: 1) (heat: 67)" [Undecided,Invalid] https://launchpad.net/bugs/571852
<pitti> for the records, I checked samba balooning, not much we can do; the executables themselves grew, binary debdiff empty
<pitti> we also checked gnome-icon-theme and figured out some 3 MB saving potential; Seb is on it
<pitti> still discussing ghostscript
<GrueMaster> Is someone watching the armel buildd's?  There are two currently building different versions of gtk+2.0 (0ubuntu4 and 0ubuntu5).
<GrueMaster> Same major release number.
<pitti> unfortunately we can't kill builds as buildd-admins, that needs someone with root access
<GrueMaster> On x86 hardware, this wouldn't be an issue.  But on the armel pool, these builds can take hours, even days.
<cjwatson> GrueMaster: lamont is the person you need to contact
<GrueMaster> ok.
<cjwatson> (as Ubuntu OSA)
<pitti> so, I removed almost all of the (very few) remaining langpacks, and with today's gnome-icon-theme, cups, and anthy uploads and samba ship dropping we should hopefully be back in size limit
<pitti> but we need to wait until the dailies tomorrow, oo.o is still building and will take a while
<pitti> oh, xserver-common grew from 0.1 to 1.1 MB due to the upstream changelog .. /me fixes
<slangasek> oh huh, samba was in ship?
<pitti> yes
<pitti> another "first against the wall" kind of removals
<pitti> in general, latest samba grew quite a bit
<slangasek> yes, known issue upstream :(
<pitti> oh, it's more than just general code growth?
<pitti> I debdiffed the binaries and hoped for some extra documentation etc., but it's really the executables themselves
<slangasek> it's a pathological lack of shared libraries
<smoser> hey all.  sorry to be a pain, but bug 599921 is currently blocking uec images builds.  I have to step out for several hours now. will check in later.
<ubot4> Launchpad bug 599921 in pyyaml (Ubuntu Maverick) (and 1 other project) "python-yaml 3.09-3 is not installable (affects: 1) (heat: 6)" [Critical,New] https://launchpad.net/bugs/599921
#ubuntu-release 2010-06-30
<cjwatson> CD builds on manual until the new ubiquity arrives
<slangasek> someone broke livecd.sh again
<ogra> already fixed and uploaded
<ogra> sorry for that
<ogra> it's waiting for the publisher
<slangasek> ok
 * ogra is working since 20h in a row and getting unconcentrated, i propbably shouldnt do uploads in that state 
<cjwatson> lamont: I forget the exact timings of the auto-upgrade; could you please make sure that the builders get upgraded to livecd-rootfs 1.129 once it's available?
<cjwatson> I'll want to do CD builds tomorrow once new ubiquity is available
<ogra> cjwatson, it gets upgraded to the latest on every run now
<ogra> automatically
<cjwatson> ogra: every publisher run?
<cjwatson> oh, every build?
<ogra> yes
<ogra> BuildLiveCD upgrades it before running livecd.sh
<cjwatson> thanks
<ScottK> cjwatson or Riddell: Look like getfem++ fell back into Universe somehow.  This will make kdeedu ubuildable (see depwait on powerpc)
<slangasek> ScottK: cf. Riddell's comment at the bottom of bug #512151
<ubot4> Launchpad bug 512151 in getfem++ (Ubuntu) "[MIR] getfem++ (affects: 1) (heat: 8)" [Undecided,Fix released] https://launchpad.net/bugs/512151
<ScottK> slangasek: OK.  In the mean time kdeedu is depwait on powerpc as a result of the demotion even though it's built everywhere else.  It'd be nice to at least get the builds finished first ....
<pitti> Good morning
<pitti> ScottK: I temporarily moved getfem++ back to main, will demote once kdeedu built
<pitti> cjwatson: so it seems that "the new ubiquity" did not arrive yet; I'm just going to respin an alternate to check how the CD size improved
<pitti> ok, that looks much better
<pitti> the alternates are well within size limit now (although they have almost no langpack)
<pitti> the xorg/anthy/cups/g-i-t fixes helped a lot
<ttx> good morning
<ara> morning ttx, all
<ara> mmm, no candidates images yet
<pitti> ara: I just spun some alternates
<pitti> for Ubuntu
<pitti> for a first smoke test
<ara> pitti, OK, I will start with those, are they ready yet?
<pitti> ara: yes, http://cdimage.ubuntu.com/daily/20100630/
<pitti> I might just as well post them to the tracker, and also build kubuntu etc.
<ara> pitti, cool, I will resync and will start smoke testing those
<ara> I will let you know ASAP if anything goes terribly wrong
<pitti> thanks!
<pitti> ara: tracker set up for a2, and ubuntu alternates posted
<pitti> other alternates building, will add them as they come in
<ara> pitti, thanks
 * pitti yays at http://cdimage.ubuntu.com/daily/20100630/report.html being empty
<pitti> seems that koffice is still unhappy, the rest of http://people.canonical.com/~ubuntu-archive/testing/maverick_probs.html is by and large the well known KDE arm breakage
<pitti> ara: which arch are you currently testing? I can give amd64 a shot here
<ara> pitti, I have started with amd64
<pitti> ok, I'll test amd64/OEM/german then
<ara> pitti, OK
<ara> pitti, mark it as started in the tracker, please
<pitti> done
<pitti> I posted ubuntustudio and server ISOs to the tracker
<pitti> xubuntu is uninstallable due to what looks like an old kernel (http://cdimage.ubuntu.com/xubuntu/daily/20100630/report.html)
<pitti> kubuntu is uninstallable as well (http://cdimage.ubuntu.com/kubuntu/daily/20100630/report.html)
<pitti> cjwatson: spinning desktops is still blocked on an ubiquity upload, right?
<pitti> I don't quite understand why the xubuntu alternate build saw linux-meta version 2.6.35.5.5; we are at .6.7
<pitti> meh, and I can't reproduce any of the kubuntu uninstallables in a clean maverick main-only chroot
<ara> pitti, maybe something was uploaded in the mean while?
<pitti> I didn't see an upload, but maybe something finished building for Kubuntu
<pitti> but then again my last apt-get update in the maverick chroot was about the same time as I triggered the cd build
<ara> pitti, in the tracker you posted ubuntu desktop i386, instead of the alternate
<pitti> oops, fixing
<pitti> done
<ara> thanks
<pitti> ara: oh, indeed the report date looks very strange: "Generated: Wed Jun 23 04:21:16 UTC 2010 "
<pitti> ^ from kubuntu 20100630
<pitti> weird, I triggered it around 7 UTC
 * pitti rebuilds
<cjwatson> Evan's just finishing up the u6y upload now
<cjwatson> I'll investigate Xubuntu
<pitti> but June 23 is quite old, and xubuntu's report looks even older, so I wonder how much we can trust those reports in the first place
<pitti> cjwatson: looks like a problem with old reports? xubuntu says "Generated: Tue Jun 22 09:07:15Z"
<pitti> 8 days ago we probably did have 2.6.35.5.5
<cjwatson> $ isoinfo -lR -i cdimage/www/full/xubuntu/daily/20100630/maverick-alternate-i386.iso | grep linux-generic
<cjwatson> -r--r--r--   7    0    0            4380 Jun 25 2010 [ 158967 00]  linux-generic_2.6.35.6.7_i386.deb
<cjwatson> ah, there was a partial build failure in there
<cjwatson> Possibly invalid template maverick-src-1.template
<cjwatson> make: *** [imagesums] Error 1
<pitti> ah, so it just kept copying the old reports?
<cjwatson> I'm not sure
<cjwatson> I'll look into it and sort it out
<pitti> cjwatson: affects ubuntu alternates as well
<pitti> cjwatson: thanks!
<pitti> I'll post xubuntu and kubuntu isos in the meantime
<pitti> ok, koffice should now be fully sorted out, everything works in my chroot
<pitti> next update of maverick_probs.html should have that fixed
<pitti> getfem++ demoted again as well (was just temporary to have kdeedu build on powerpc)
<cjwatson> pitti: ogra broke the reports, fixing
<cjwatson> syntax error in the preinstalled stuff
<pitti> with that, we just have kubuntu/arm and landscape left, I investigate landscape now
<pitti> cjwatson: ah, thanks
<cjwatson> sorry, NCommander broke them actually
<cjwatson> so all the report.html files are nonsense.  let me see if I can still regenerate them
<pitti> ah, landscape fixed as well, seems smart moved back into universe erroneously; re-promoted
<pitti> that should get i386/amd64 uninstallability pretty close to 0
<cjwatson> all report.html files updated
 * pitti syncs ledit to fix that installability as well
<pitti> cjwatson: \o/
<cjwatson> kubuntu-desktop still uninstallable
<cjwatson> due to kopete
<cjwatson> the xubuntu problem I mentioned still persists but must be breaking something else
<pitti> cjwatson: hm, kopete installs fine here; I'll have a look at this
<cjwatson> amd64 only
<pitti> I'm on amd64
<cjwatson> but yeah, in chdist too
<pitti> http://cdimage.ubuntu.com/kubuntu/daily/20100630.1/report.html has the same indeed
<pitti> on i386 as well
<cjwatson> audacity/amd64 uninstallable for ubuntustudio
 * cjwatson updates chdist for universe to have a look
<cjwatson> ok, that one is at least still real
<cjwatson> possibly *just* fixed
<cjwatson> rebuilding ubuntustudio
<cjwatson> https://launchpad.net/ubuntu/+source/ubiquity/2.3.0 BTW
<cjwatson> I just didn't want to have the lucid installer for another alpha release ...
<pitti> yay btrfs!
<pitti> cjwatson: so if all goes well we can trigger desktops in 2 h
<pitti> still puzzled by kopete, but I'll poke that further
<cjwatson> yup
<pitti> this doesn't happen to have a verbose mode to say why it's uninstallable?
<cjwatson> not that I know of
<cjwatson> you could unpack the CD, point chdist at its apt archive, and try chdist apt-get cd install
<pitti> plasma-scriptengine-ruby should now be the only i386/amd64 uninstallable left on http://people.canonical.com/~ubuntu-archive/testing/maverick_probs.html in the next run
<cjwatson> pitti: I can have a look at this in c. 30 minutes if you want
<cjwatson> (the kubuntu uninstallable)
<NCommander> cjwatson: what did I break?
<cjwatson> NCommander: [ ! "CDIMAGE_PREINSTALLED" ] instead of [ ! "$CDIMAGE_PREINSTALLED" ]
<pitti> cjwatson: that be great, thanks
 * NCommander gulps
<NCommander> cjwatson: oops :-/
<cjwatson> fixed now, no worries
<cjwatson> I recommend syntax highlighting - vim made the mistake really obvious because it was highlighted in a different colour from the other similar stuff on the same line
<pitti> cjwatson: I asked ccheney about the armel/oo.o breakage, but it looks far from trivial; I'd unseed it for armel for now, does that sound ok to you as well?
<pitti> (to make ubuntu-desktop installable on arm again0-
<pitti> s/0-/)/
<cjwatson> pitti: ok by me
<NCommander> pitti: the FTBFS ARM FTBFS isn't in OOo, java is segfaulting on a build-depend
<cjwatson> nothing armel/oo.o-ish is going to be fixable by Thursday anyway
<pitti> NCommander: right, but we don't fix it by tomorrow
<NCommander> pitti: ah right. I'll make sure that it gets looked at by someone as soon as A2 goes out the door.
<pitti> NCommander: cheers!
 * cjwatson jigdos dvd and kubuntu alternate in parallel; I'm sure that will help speed both up :P
 * ttx smoketests server ISOs
<pitti> hello ttx
<ttx> pitti: yo!
<ttx> also bug 599921 (that was preventing cloud images from being built) should be fixed now
<ubot4> Launchpad bug 599921 in pyyaml (Ubuntu Maverick) (and 3 other projects) "python-yaml 3.09-3 is not installable (affects: 1) (heat: 10)" [Critical,Fix released] https://launchpad.net/bugs/599921
<ttx> ScottK fixed it and I triggered a no-change rebuild
<pitti> eww, rebuilding ubuntu-meta adds bootchart and pybootchartgui by default
<pitti> this causes quite some slowdown, was that intentional?
<pitti> ah, was from cjwatson, r1714
<pitti> cjwatson: but the log doesn't say why it's included by default?
<cjwatson> it was to assist benchmarking, with the idea that it'd be removed before beta
<cjwatson> hm, why did I put that in desktop
<cjwatson> it'd be sufficient to have it in live-common I think
<cjwatson> but if you think we don't have space, feel free to nuke it
<pitti> also, pybootchartgui is a dependency, we don't need that explicitly
<pitti> cjwatson: oh, space is rather trivial; but it slows down boot, needs quite some CPU to generate the charts, and piles up lots of stuff in /var/log/
<cjwatson> it was mostly because there was somebody benchmarking live CD boots
<cjwatson> and it's hard to install bootchart in that context
<pitti> ah, for those
<pitti> cjwatson: I can move it to live-common then?
<cjwatson> I'm doing it
<pitti> ack
<cjwatson> done, go ahead and update -meta
<cjwatson> pitti: hm, so I can't reproduce the kubuntu cd uninstallability with apt-get
<cjwatson> oh, wait, I can
<pitti> cjwatson: -meta> doing, thanks
<cjwatson> kubuntu-desktop shows up as installable but kopete doesn't
<cjwatson> ah, kopete is only a Recommends so apt-get just skips it but britney checks it anyway
<cjwatson> it's a blacklist violation
<cjwatson>   libmediastreamer0: Depends: libavcodec52 (>= 4:0.6~svn20100505-1) but it is not installable or
<cjwatson>                               libavcodec-extra-52 (>= 4:0.6~svn20100505-1) but it is not installable
<pitti> ah, that explains why it doesn't turn up on maverick_probs
<cjwatson> Riddell: TB resolution of 2007-01-02 says that libavcodec* is not to be shipped on CDs.  Can it be arranged that kopete doesn't (indirectly) depend on it?
 * Riddell looks
<NCommander> cjwatson: what's the dependency chain? (I don't think kopete is directly pulling in libav*)
<Riddell> kopete -> libmediastreamer0 -> libavcodec52
<NCommander> oh, do'h
<pitti> ubiquity FTBFS
<pitti> install: cannot stat `d-i/source/apt-setup/finish-install.apt-cdrom-setup': No such file or directory
<pitti> ev: ^ missing bzr add or something like that?
<pitti> hm, no, it's an included package
<cjwatson> ev fixed it in trunk
<cjwatson> fixed xubuntu source cd building, possibly
 * ogra hugs slangasek and cjwatson for last nights help ... seems it worked http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/
<ogra> (needs some touching of make-web-indicies post A2)
<cjwatson> make-web-indices changes can be done now
<cjwatson> if there's time
<ogra> cjwatson, i still need to look at flash-kernel changes (which needed the image ready first) i'm fine to go with the current website for A2
<ttx> python-smartlib uninstallable blocks server install, investigating
<ttx> python-smartpm*
 * ttx mumbles something about uploading broken packages during freezes
<ttx> pitti: any idea why python-smartpm would be missing from the Server ISO, while it is a dependency of recently-uploaded landscape-common ?
<pitti> ttx: I repromoted it to main this morning
<pitti> ttx: should be fixed in the next rebuild
<pitti> ttx: does it break installation?
<pitti> ttx: I can respin the image if you want
<ttx> pitti: yes, landscape-client is installed by default
<ttx> pitti: yes, please
<pitti> ttx: sure, rebuilding
<ttx> thx!
<pitti> ttx: done, adding to tracker
<pitti> ttx: http://cdimage.ubuntu.com/ubuntu-server/daily/20100630.1/report.html looks good now
<pitti> ttx: sorry, reports were broken on the previous builds, so I didn't notice
<ttx> pitti: np, that's what smoketesting is for :)
<pitti> tracker updated
<pitti> ttx: will you/smoser add the EC2 ones?
 * ttx rsyncs and resmoketests
<ttx> pitti: smoser will do.
<pitti> good, thanks
 * cjwatson read that as "rockettests"
<pitti> for the record, I checked koreport uninstallability; doesn't break images and is just an obsolete package (replaced by koffice-libs0
<pitti> so http://people.canonical.com/~ubuntu-archive/testing/maverick_probs.html looks good enough now
<pitti> koreport removed due to NBS
<cjwatson> starting desktop builds now
<cjwatson> $ echo ubuntu; buildlive ubuntu && for-project ubuntu cron.daily-live; echo kubuntu; buildlive kubuntu && for-project kubuntu cron.daily-live; echo xubuntu; buildlive xubuntu && for-project xubuntu cron.daily-live; echo mythbuntu; buildlive mythbuntu && for-project mythbuntu cron.daily-live; echo ubuntu-netbook; buildlive ubuntu-netbook && for-project ubuntu-netbook cron.daily-live; echo kubuntu-netbook; buildlive ...
<cjwatson> ... kubuntu-netbook && for-project kubuntu-netbook cron.daily-live
<pitti> ah, publisher already done? thanks
<pitti> cjwatson: I hope kdenetwork builds in time
<pitti> cjwatson: if you didn't yet, perhaps move kubuntu a bit back?
<cjwatson> oh, er, can't really now
<cjwatson> it can just be repeated
<pitti> ok, it should fail early then
<lamont> cjwatson: BuildLiveCD (as ogra mentioned) now does a dist-upgrade of the target-suite's chroot prior to doing the build.  So you should always have the latest livecd-rootfs for each build you do
<cjwatson> ok, thanks
<pitti> I'm off for some 45 min for lunch; good time slot now until the desktops built
<ogra> cjwatson, i changed the crontab to include preinstalled omap images now but didnt switch it live since you are in manual anyway, can you trigger it once you switch back to autobuilding ?
<cjwatson> ogra: please edit the live crontab to match, but don't uncomment things
<cjwatson> unless that's what you mean you did
<ogra> cjwatson, yes, thats what i did
<ogra> i just didnt call the crontab command for it
<cjwatson> go ahead and trigger it, you can run it in parallel
<ogra> hmm, there are no comments in /srv/cdimage.ubuntu.com/etc/crontab
<ogra> no additional ones at least
<ogra> do i miss something ?
<cjwatson> that's not the live crontab.  'crontab -e' edits the live crontab.
<ogra> ah, crontab -l differs
<cjwatson> I just commented out the whole active chunk.
<ogra> yeah
<cjwatson> i.e. s/^/#
<ogra> to revert that, do you just edit it again or do you run crontab /srv/cdimage.ubuntu.com/etc/crontab ?
<cjwatson> I would only do the latter with care
<cjwatson> i.e. I'd diff first
<ogra> indeed
<cjwatson> do you want me to make this change to the live crontab?
<ogra> well, once you enable it again at least
<ogra> as long as autobuilding is off it doesnt matter
<cjwatson> I've edited it
 * ttx njoys fast dpkg again
<cjwatson> good
<pitti> darn, kdenetwork finished building 2 minutes too late
<cjwatson> pitti: re bug 600120, which mirror are you using?
<ubot4> Launchpad bug 600120 in openoffice.org-l10n (Ubuntu Maverick) (and 1 other project) "In Maverick Alpha 2, the langpacks are not downloaded during the installation (affects: 1) (heat: 10)" [High,Invalid] https://launchpad.net/bugs/600120
<pitti> cjwatson: I'm posting the images so far to the tracker, ok?
<cjwatson> yes please
<pitti> current ubuntu lives are within size limit \o/
<pitti> cjwatson: good question, let me boot my VM; if it autoselects, then I'd guess de.archive.u.c.
<cjwatson> de.archive.ubuntu.com could apparently do with catching up too
<cjwatson> so I think there's nothing to fix, we just need to wait a bit
<pitti> oh you mean it's fixed in the recent OO.o build?
<cjwatson> the openoffice.org-l10n upload from the start of this month that finally managed to build early this morning
<pitti> so in my chroot I have the current version 1:3.2.1~rc2-2ubuntu1
<cjwatson> of what package?
<pitti> openoffice.org-l10n-de
<pitti> checking VM now (still booting)
<cjwatson> check 'apt-cache policy' there before you update
<pitti> I wasn't going to update
<pitti> cjwatson: but wasn't that supposed to drop the language-support-* stuff at all?
<pitti> in my chroot I see
<pitti> Depends: openoffice.org-l10n-common (>= 1:3.2.1~rc2), openoffice.org-common (>= 1:3.2.1~rc2) | language-support-translations-de, openoffice.org-common (<< 1:3.2.1~rc2.1) | language-support-translations-de
<pitti> cjwatson: confirmed, de.a.u.c, and policy has 3.2.0-7ubuntu1
<pitti> so it's older indeed
<cjwatson> well, maybe the |-ed deps should go away, but that's not the cause of this bug and it's not urgent in any way (so shouldn't be milestoned)
<cjwatson> you were just seeing that as a side-effect of the whole thing being fundamentally uninstallable at the time
<pitti> apt-get install in VM still breaks, let me take a closer look
<pitti> cjwatson: ah, right; versioned dependency to oo.o-common breaks it
<pitti> that's why it's falling back to lang-support
<cjwatson> exactly
<pitti> switching to archive.u.c./update/install works
<pitti> right, so we can set that to "fix committed" perhaps and close it tomorrow?
<pitti> ah, saw you update now; WFM
<pitti> ubuntu and kubuntu
<pitti> ... posted to tracker
<pitti> will watch cdimage for progress on the others
<Riddell> pitti: kubuntu images not going to be final presumably? wrong kopete version
<pitti> Riddell: right
<pitti> but it'll take some time until we can respin, until Colin's build'em'all queue finishes
<pitti> Riddell: but since the livefs built, it should at least be installable for a quick smoketest?
<pitti> Riddell: kdenetwork just finished building after the current publisher ran, so it'll be at least another 1:40 hours until we can respin
<Riddell> ok thanks
<cjwatson> feel free to respin kubuntu any time it's convenient
<cjwatson> it can go in parallel with my current queue, which is past kubuntu now
<cjwatson> we'll probably need to respin Ubuntu for new Wubi too, so that Wubi actually works
<pitti> cjwatson: what package do we need to wait on for ^ this?
<cjwatson> none, it's fetched from people.c.c/~evand/ or some such
<pitti> ah; I didn't see anything relevant on -changes
<pitti> xubuntu desktops posted, please test
<cjwatson> slotting in an Ubuntu rebuild now
<pitti> cjwatson: so this ^ doesn't require a new livefs, just a new cron.daily-live?
<ev> assuming we're just talking about wubi, it does not need a livefs rebuild
<pitti> ev: thanks
<ev> sure thing
<cjwatson> oh, damn, I did a livefs rebuild anyway
<cjwatson> sorry
<cjwatson> they're faster than they used to be ...
<pitti> you can probably still ^C it?
<ev> haha
<cjwatson> ^C-ing livefs builds doesn't tend to be effective
<pitti> it should wait until the other ones (mythbuntu, netbook, etc.) are done anyway?
<cjwatson> they still keep running on the other side of the ssh trigger
<pitti> ah, right
<cjwatson> and no, I slotted in between mythbuntu and ubuntu-netbook
<cjwatson> is it a desperate matter to avoid a livefs rebuild?
<Daviey> mythbuntu won't be putting too much attention into A2 tests.. So that can be made a low priority.
<pitti> cjwatson: I wouldn't call it "desperate"; it's maybe 45 mins, not the end of the world
<cjwatson> Daviey: it's already built
<cjwatson> pitti: more like 25 now
<Daviey> cjwatson: super, thanks
<pitti> Daviey: right, they just landed; I'll post them anyway, perhaps someone is interested
<pitti> Daviey: if nobody tests them, we just don't announce them
<Daviey> pitti: we will test them, but not too focused on them
<cjwatson> I'll try to get DVDs built after all of this, though they tend to take longer
<smoser> so heres where we are on uec/ec2 images.  I've tested 20100629 build, and those tests went well.  They do have bug 596062 in them.
<ubot4> Launchpad bug 596062 in landscape-client (Ubuntu) "broken python-pycurl dependency (affects: 2) (dups: 2) (heat: 22)" [Medium,Fix released] https://launchpad.net/bugs/596062
<smoser> build 20100630.1 is publishing to ec2 right now.
<davmor2> cjwatson: the xubuntu cd's that just landed are they included
<davmor2> nuts
<davmor2> including the new wubi
 * davmor2 wonders why delete is so close to the enter key
<smoser> recently, publishing to the ap-southeast-1 region has been a sticky point.  amazon seems to not be able to meet demand for their services in that region, and I get "insufficient capacity" when trying to publish.  My publishing scripts don't handle that terribly well, so at the moment, the whole thing just fails without the option to resume.
<cjwatson> davmor2: no
<cjwatson> do I need to respin those too?
<davmor2> cjwatson: I'll try one for you asap and let you know
<cjwatson> well, wubi won't work
<cjwatson> that much is a given
<davmor2> cjwatson: if wubi won't work then it's worth respining the live cd's I would imagine
<smoser> the publish has been right around a 6 hour process, so if all goes well, the 20100630.1 build would be available ~ 17:45 UTC
<cjwatson> davmor2: ok, will do after this Xubuntu rebuild
<pitti> xubuntu respin for wubi would again just need a cron.daily-live, and thus can happen in parallel, right?
<pitti> 20100630.1 ubuntu desktops posted to tracker
<pitti> ubuntu netbook posted
<pitti> cjwatson: just to confirm, you didn't build ports (netbook armel etc.) yet, right?
<cjwatson> no
<cjwatson> xubuntu respin (no livefs rebuild) in progress
<cjwatson> kubuntu-netbook failed
<cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/kubuntu-netbook/20100630/livecd-20100630-i386.out
<cjwatson>   hplip: Depends: hplip-cups (= 3.10.5-3ubuntu1) but it is not installable
<pitti> hplip was just uploaded about an hour ago
<pitti> I guess i386/amd64 buildd desync?
<cjwatson> this was an i386 build
<cjwatson> hplip-cups is in universe
<pitti> ah, can promote
<cjwatson> I wonder why it's not listed for promotion
<pitti> package is ~ 350 kB and looks reasonable
<cjwatson> that's a good chunk of the MB we saved on X, presumably on most CDs ... but OK
<pitti> "Removed hpijs from Recommends: of hplip, as we already
<pitti>     require hplip-cups via Depends:, hpijs is not needed any more for using
<pitti>     HPLIP with all supported HP printers"
<cjwatson> ah, ok
<pitti> hpijs is 472 kB
<pitti> so I hope that'll go away then
<pitti> cjwatson: FYI, we'll need to respin netbook; didrocks is preparing a fix to make ubiquity actually appear in the menus
<pitti> (it's nowhere right now)
<ara> pitti, the desktops posted at the tracker (20100630.1) have everything now?
<ara> or are we expecting a respin?
<pitti> ara: should; I'm currently test-installing them in kvm
<pitti> but it shoudl have the new wubi
<cjwatson> k
<ara> pitti, OK, I think that those that are going to be respin (alternate?) should be marked as such in the tracker, so people know where to focus
<pitti> ara: oh, is something broken in the alternates?
<pitti> my previous test install went quite well (OEM/German/manual partitioning)
<ara> pitti, no, it isn't, I just thought they were going to be respin
<ara> maybe I misunderstood the conversation here
<ara> thanks
<pitti> I'm not aware that we need to; cjwatson, are you?
<pitti> alternates do not have wubi
<cjwatson> right, alternates should be fine
<cjwatson> ara: the OOo language pack problem you had was to do with the installer fetching stuff from the mirror, not off the CD image, so it doesn't require a respin to fix
<ara> nice, thanks all!
<Daviey> Hi!
<Daviey> http://cdimage.ubuntu.com/ubuntu-server/daily/20100630.1/maverick-server-amd64.iso <-- is that the correct A2 candiate?
<pitti> looks correct to me, Daviey
<Daviey> pitti: oddly, i just saw the python-yaml issue :/
<Daviey> failed to install at pkgsel due to dep problem with python-yaml.
<ara> Daviey, have you double checked that your iso has the same md5sum?
<Daviey> ara: 1908a53db7a727a1be65254fdf67ae9b  maverick-server-amd64.iso
<Daviey> yes.. i can try again..
<Daviey> ara: I'm actually doing it by creating a usb pendrive, using usb-creator-gtk.. not that it should matter :/
<pitti> pyyaml was just rebuilt today
<Daviey> pitti: i thought the spin happend after the rebuild
<Daviey> ?
<pitti> Daviey: can you check the pyyaml version on that CD?
<pitti> Daviey: that's what I thought as well
<Daviey> pitti: on it
<Daviey> pitti: 3.09.3... not the rebuild :S
 * pitti checks archive
<pitti> python3-yaml | 3.09-3build1 |      maverick | i386
<pitti> python3-yaml | 3.09-3build1 | maverick/universe | amd64, armel, ia64, powerpc
<pitti> urgh
<pitti> Daviey: I think i386 will work
 * pitti promotes
<Daviey> pitti: yeah.. amd64 is UEC's main candidate TBH
<pitti> promoted
<Daviey> Can we have a respin please :)
<pitti> so after the next publisher, at 1600 UTC, we can re-spin
<Daviey> ttx: ^^
<Daviey> pitti: Super, thanks!
<pitti> but I won't be here any more, need to leave in about 30 mins (my mother's bday today)
<ttx> hmmmm
<ttx> pitti: not sure about that
<pitti> cjwatson: are you still here in 1:20 for the server and netbook respins, or shall I do a sleep;build ?
<Daviey> ttx: I reckon pitti knows when his mother's birthday is! :)
<pitti> heh
<ttx> pitti: I tested amd64 and i386 alright
 * ttx checks
<Daviey> ttx: open the iso in file-roller, and navigate to the pool
<pitti> Daviey: where did it fail for you?
<Daviey> pitti: pkg selection, unable to select and install software
<pitti> Daviey | failed to install at pkgsel due to dep problem with python-yaml.
<pitti> that's with a particular task perhaps?
<Daviey> pitti: yes, UEC
<ttx> pitti: that package is also hit with basic installs
<Daviey> cloud-init was the package that depends on python-yaml in this instance
<pitti> ttx: so, if you need a respin, can you please ping cjwatson, Riddell, or slangasek to do it in 1:20 hours?
<ara> wow, ext4 d-i installation is soooo slow in my dell mini9, it looks like it is being written with a hummer and a chisel
<Daviey> pitti: will do
<ttx> pitti: yes
<Daviey> oh, you asked ttx.
<pitti> well, either of you :)
<pitti> but it will need 1:20 hours to actually promote into the archive
<ttx> I just want to understand why this only affects the UEC install
<pitti> ttx: presumably because other tasks don't depend on that package?
<Daviey> ara: Yes.. that bums us out aswell.. thanks to the fsync.
<ttx> pitti: the thing is... they do
<ttx> I hit that bug this morning in my testing, and I don't have it anymore
<pitti> magic
<Daviey> ttx: Hmm.. were you testing amd64 or i386
<Daviey> ?
<ttx> both
<Daviey> ttx: i can try a tradional server install using this if you want?
<ttx> I'm trying a UEC install now... and it seems to work alright
<Daviey> ttx: I checked the md5sum.. it matches :/
<pitti> eek -- "General error mounting filesystems. A maintenance shell will now be started"
<ttx> you checked the md5sum on your installation media ?
<Daviey> ttx: if you open your ISO.. can you check what python-yaml is in the pool?
<pitti> that's from a stock "use all disks" amd64 desktop install
<ttx> or the one from the file you think you put there ?
<GrueMaster> Morning.  I am going to be testing the new preinstalled image for Arm Beagleboard.  Today is our first image.  Since it is not in the tracker database yet (A3), how should I report test results?
<Daviey> ttx: no.. tested the .iso.. but the rebuild isn;'t in the .iso.. so so.
<ttx> hmm
<Daviey> ttx: I can burn it, and check the md5sum if you think.. but from where i'm sat.. if it's aint in the .iso, it aint gonna be on the disk :/
<ttx> Daviey: just wait for my install to complete, I may still hit the bug :)
<pitti> GrueMaster: I'm happy to add it, but first time I do that; where's the image? do you use standard build numbers for that?
<Daviey> ttx: Ok.. keep in mind that yaml rebuild wasn't moved over by AA's for amd64, only i386
<Daviey> pitti: just promoted amd64
<Daviey> pitti: Sorry, talking about you.. not to you :)
<GrueMaster> The images are at http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/.  Nust sure what you mean by build numbers, but they are yyyymmdd.b
<ttx> Daviey: you hit this on the CLC or the NC install ?
<Daviey> ttx: CLC
<Daviey> ttx: not tried a NC yet
<GrueMaster> I also have special instructions at http://testcases.qa.ubuntu.com/Install/ARM/PreinstalledImage
<ttx> Daviey: may I ask why you'd have cloud-init installed on that ?
<Daviey> ttx: I didn't do that..
<ttx> <Daviey> cloud-init was the package that depends on python-yaml in this instance
<Daviey> ttx: from the logs..
<Daviey> ttx: i've done no magic, other than a normal install
<ttx> ah, it's cloud-utils
<ttx> not cloud-init
<Daviey> ah yes, sorry
<ttx> I just hit it
<Daviey> \o/
<Daviey> ttx: but normal server install for amd64 worked for you?
<ttx> Daviey: yes
<ttx> Daviey: I suspect we picked up a workaround in the mean time
 * ttx grumbles
<ttx> all that good ISO testing lost
<ttx> Daviey: I guess you can now see the importance of that early, from ISO, testing
<ttx> doing it earlier would have avoided losing a few hours work
<ara> and that's why it is important, son
<ara> :P
<ttx> and doing it with netboots from archive state would not have caught that.
<Daviey> ttx: I started doing the test as soon as i was asked! :/
<ttx> Daviey: oh, it was not meant as a blame, more as a proof by example... you weren't so convinced
<pitti> ttx: not lost, it confirmed that there aren't other grave problems
<ttx> by the extra hassle of doing the install from ISO (instead of convenient netboot/archivestate)
<ttx> pitti: right :)
<Daviey> ttx: oh sure.
<pitti> ara, Daviey: if you test ubuntu desktops, confirming or denying bug 600244 would be appreciated
<pitti> I tested it two times with the same result
<ubot4> Launchpad bug 600244 in ubiquity (Ubuntu) "[Maverick alpha-2] boot failure on "use entire disk" install (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/600244
<Daviey> pitti: I'm a desktop dodger!
<pitti> Daviey: that's fine, just in case :)
<pitti> GrueMaster: I don't seem to be able to define new test cases in the tracker for the prebuilt images ("Sorry, this feature hasn't been reimplemented yet")
<pitti> GrueMaster: I'm afraid this needs some tracker superuser like stgraber with DB access to define new ones?
<GrueMaster> No problem.  I'll file a bug and get it for A3.
<ara> GrueMaster, I told you to send me the name of the images, cases and url so I could do it
<GrueMaster> Just wanted to know if there were an alternate method for me to use this time around.
<GrueMaster> I'll post results on a wiki page.  I'll let everyone know the location once I have one.
<ara> GrueMaster, if you send me that information, I can add them for you today
<GrueMaster> ara ok.
<cjwatson> pitti: I have an interview to run at that time, so won't be able to concentrate on respins
<ttx> pitti, smoser: does that promotion affect the cloud images as well ? should their generation be restarted in 60 min ?
<pitti> ttx: if they also depend on/ship that, then yes
<pitti> cjwatson: ok, I'll set up a timed build
<ttx> smoser: ^
<smoser> promotion ?
<cjwatson> ara: it should be faster in maverick than in lucid, but there is more to do I agree
<ttx> smoser: looks like the fixed pyyaml wasn't in the archive
<smoser> umm... the images built
<pitti> ttx: new server isos will build in 50 minutes
<Daviey> smoser: There was a problem with yaml amd64
<smoser> and they didn't *build* before.
<Daviey> smoser: you have built amd64 images?
<ttx> smoser: if the images work, then forget it
<smoser> i dont know that they work. but they built.
<Daviey> pitti: Thanks for that.
<smoser> before the fix to python-yaml and python-defaults, the images did not build.
<pitti> I need to run out for today now, sorry
<pitti> I'll get up early tomorrow morning
<ttx> pitti: go!
<Daviey> smoser: Can you confirm you have a built amd64 image?
<Daviey> smoser: The issue was only a problem with amd64, not i386
<smoser> i have: python-yaml 3.09-3build1 in both i386 and amd64 images that are built already and currently publishing to ec2
<ttx> Daviey: well, the build1 package was missing from both
<smoser> http://uec-images.ubuntu.com/maverick/20100630.1/ has those files now.
<Daviey> smoser: erm, http://uec-images.ubuntu.com/maverick/20100630.1/unpacked/maverick-server-uec-amd64.manifest
<Daviey> doesn't have build1 there
<Daviey> my bad
<Daviey> yes it does.
<smoser> :)
<ttx> smoser: your build process might not block on universe packages
<GrueMaster> ara:  Bug 600249.  Thanks.
<ubot4> Launchpad bug 600249 in ubuntu-qa-website "Need to add arm preinstalled images to the tracker database (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/600249
<stgraber> pitti: I'd need to check if I still have access ... last time I tried, IS didn't update the ssh access for the new box
<smoser> ttx, it pulls from universe if it needs to.
<ara> stgraber, I'm on it
<ttx> smoser: ok, that explains it
<ara> GrueMaster, the links will not work until alpha 3, but I can add the images to the list
<ttx> smoser: so your cloud images should be alright
<GrueMaster> That works for me.
<ara> GrueMaster, what name do you want the image to have in the tracker
<ara> ?
<GrueMaster> Who knows, we might even have this figured out by then.  :)
<ttx> Daviey: you'll still be around in 1 hour to validate the fixed ISO ?
<GrueMaster> Ubuntu Arm Daily Preinstalled
<GrueMaster> Or something like that.
<ara> GrueMaster, do I add 20100630.3 build to the tracker?
<GrueMaster> I think there will be a .4 in an hour.
<GrueMaster> Apparently the kernel cmdline is missing a root= parameter, failing bootup.
<ara> GrueMaster, ok, let me know when you want it added to the tracker. Other than that, everything is now set up
<GrueMaster> great, thanks.
<Daviey> ttx: Well depends how urgent, i was planning on leaving at 5:00 UTC, and coming back 2 hours later to carry on.. But if you consider this urgent, then i can postpone that.
<ttx> Daviey: should be alright. I just want to be sure there aren't any other blocker
<ttx> Daviey: you should have time to complete a basic test before 1700UTC
<Daviey> ttx: ok.. cool
<smoser> can someone populate the uec images tests with 20100630.1 please ?
<cjwatson> smoser: "Ubuntu Server UEC amd64" and "Ubuntu Server UEC i386"?  done
<cjwatson> pitti: bug 600244 may need an initramfs-tools cherry-pick which maks alerted me to earlier today
<ubot4> Launchpad bug 600244 in ubiquity (Ubuntu) "[Maverick alpha-2] boot failure on "use entire disk" install (affects: 2) (heat: 10)" [High,Triaged] https://launchpad.net/bugs/600244
<cjwatson> I'll have a look later
<cjwatson> I bet it's virtio-specific
<smoser> cjwatson, yes. thanks.
<ogra> hrm
<ogra> seems publishing of the preinstalled images stopped working just now
<ogra> http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100630.4/ seems empty
<ogra> but : cdimage@antimony:~$ ls -lh /srv/cdimage.ubuntu.com/www/full/ubuntu-netbook/ports/daily-preinstalled/20100630.4/|grep bz2
<ogra> -rw-rw-r-- 1 cdimage cdimage 523M 2010-06-30 16:29 maverick-preinstalled-netbook-armel+omap.img.bz2
<ogra> -rw-rw-r-- 1 cdimage cdimage 1.1M 2010-06-30 16:38 maverick-preinstalled-netbook-armel+omap.img.bz2.zsync
<cjwatson> might still be syncing, but you'd have to ask #is to confirm
<ogra> well, i'll wait a bit more first
<Riddelll> installed Kubuntu daily-live/20100630/  reboot said can't mount filesystems and dropped me to a shell
<cjwatson> bug 600244
<ubot4> Launchpad bug 600244 in ubiquity (Ubuntu) "[Maverick alpha-2] boot failure on "use entire disk" install (affects: 2) (heat: 12)" [High,Triaged] https://launchpad.net/bugs/600244
<cjwatson> anyone wants to beat me to debugging it, be my guest, I won't have time until about four hours from now
<shadeslayer> hi quick question,is btrfs a option for the file system in the new installer?
<cjwatson> as per the constraints in https://lists.ubuntu.com/archives/ubuntu-devel/2010-June/030918.html, yes it should be
<ttx> cjwatson: is the server ISO respin automatically triggered when the publisher is finished running ?
<ttx> the ISo tracker does not show "rebuilding" yet
 * ttx will be back in two hours to check status
<shadeslayer> cjwatson: this applies for Kubuntu as well
<GrueMaster> ara: 20100630.4 arm image is ready to be added to the tracker.
<ara> GrueMaster, ok, adding
<ara> GrueMaster, done: http://iso.qa.ubuntu.com/qatracker/test/4263
<GrueMaster> Thanks.
<smoser> slangasek, can you populate tracker from http://uec-images.ubuntu.com/maverick/20100630.1/
<smoser> please
<slangasek> smoser: done
<smoser> danke
<cjwatson> shadeslayer: should do
<cjwatson> ttx: I don't know, pitti was doing it.  Integration with the tracker isn't automated though
<shadeslayer> cjwatson: ok.. zsyncing iso
<cjwatson> ok, unexpectedly have some time now, I'll look at this mountall failure
<Daviey> cjwatson: Happen to know when 20100630.2 will show on cdimages.u.c?
 * Daviey hoped to try it before EoD'ing
<cjwatson> Daviey: if it's not there already, then there's something wrong with syncing and #is needs to be asked
<Daviey> cjwatson: Ah, it's there now \o/
<Daviey> thanks
<ttx> ara: could you promote the 20100630.2 server ISO to the test tracker ?
<ara> ttx, sure
<ara> ttx, done
<ttx> thx, notification received
<cjwatson> well, we'll certainly need new desktop CDs
<cjwatson> marked all desktops as rebuilding; uploading ubiquity 2.3.2
<cjwatson> oh, and netbook as well
<GrueMaster> I am unable to add any more bug numbers to http://iso.qa.ubuntu.com/qatracker/result/4263/695
<GrueMaster> (and I have plenty).
<smoser> ec2 tests have all been run except for those in ap-southeast-1 where there is low capacity.  amazon isn't able to provide virtual instances for me to test on.  other than that everything looks good.
 * cjwatson respins desktop/netbook world
<pitti> cjwatson: thanks for fixing 600244!
<cjwatson> obvious once I saw it, utterly obscure until I did ...
<cjwatson> Ubuntu desktop on tracker
<pitti> \o/
<cjwatson> err, somebody has attached 600244 to the alternate amd64 disk
<cjwatson> that's got to be a mistake
<pitti> I was just wondering about that
<pitti> but it's not an oem-config problem
<pitti> cjwatson: I removed the bug ref from there
<pitti> (funny that I can edit other people's results)
<pitti> "To mark a test as failed, you need to provide a bug number."
<pitti> bah, now I need to invent one
<pitti> ok, there
<pitti> one red bug less
<pitti> otherwise it seems the alternates hold together pretty well so far
<cjwatson> have you tested the alternate?
<cjwatson> I did but I think not the absolute most current version
<pitti> I did, amd64/OEM/manual partitioning/German
<cjwatson> ok
 * pitti waves good night, will get up earlier tomorrow to continue testing and brushing up the tech notes
<pitti> cjwatson: do you have the other desktops queued, or are there more problems to look into?
<cjwatson> $ echo ubuntu; buildlive ubuntu && for-project ubuntu cron.daily-live; echo ubuntu-netbook; buildlive ubuntu-netbook && for-project ubuntu-netbook cron.daily-live; echo kubuntu; buildlive kubuntu && for-project kubuntu cron.daily-live; echo kubuntu-netbook; buildlive kubuntu-netbook && for-project kubuntu-netbook cron.daily-live; echo xubuntu; buildlive xubuntu && for-project xubuntu cron.daily-live; echo mythbuntu; ...
<cjwatson> ... buildlive mythbuntu && for-project mythbuntu cron.daily-live
<pitti> ah, seems it's currently munching at netbook and kubuntu
<cjwatson> I might not stay up long enough to get those all onto the tracker though
<cjwatson> it's on kubuntu right now
<pitti> I can add the rest tomorrow morning
<cjwatson> that netbook build is somebody else's
<pitti> or perhaps slangasek can
<cjwatson> ogra's, by the looks of things
<pitti> but I'll check in the morning either way
<pitti> ah, -s omap
<cjwatson> UNE posted
<cjwatson> (oversized though)
<cjwatson> Kubuntu desktop posted
#ubuntu-release 2010-07-01
<ScottK> http://cdimage.ubuntu.com/kubuntu/ports/daily-live/current/ still has Lucid images too.
<cjwatson> fixed for next sync
<cjwatson> must fix that cdimage publication bug some day
<cjwatson> kubuntu-netbook and xubuntu on tracker
<cjwatson> mythbuntu should be done within half an hour or so, but I'm not going to wait up for it
<cjwatson> also, have queued up Ubuntu, Kubuntu, and Edubuntu DVD builds
<cjwatson> though I don't think alpha-2 should block on those getting tested
<GrueMaster> cjwatson: while you are updating iso.qa, could you kindly bump Ubuntu Arm Daily Preinstalled to 20100630.6?  Thanks.
<cjwatson> GrueMaster: done
<GrueMaster> thanks.
<GrueMaster> cjwatson: (or someone with admin access to iso.qa).  I am unable to add more bugs beyond the default 3 fields in http://iso.qa.ubuntu.com/qatracker/result/4290/695
<Riddelll> I'm afraid I'm travelling to akademy today so won't be able to test CDs, I've asked for volunteers so hopefully it'll happen
<pitti> Good morning
<pitti> cjwatson: Didier mentioned that he expected netbook to be heavily oversized
<pitti> cjwatson: it's actually not that bad any more with the recent package fixes, but we thought it'd be okay for alpha-2, since most folks are installing netbooks from USB sticks anyway (no CD drive)
<ttx> Good morning
<pitti> bonjour ttx
<ttx> pitti: amd64 server is oversized
<pitti> ttx: did that change over night?
<ttx> the last respin made it pass the limit, yes
<pitti> I have a script to compare two images
<ttx> pitti: could you have a look ?
<pitti> sure
<pitti> so, 30.1 was 694 MB, 30.2 is 701
<ttx> which sounds like a good inflation for just a build1
<pitti> le huh
<pitti> ttx: http://paste.ubuntu.com/457691/
<ttx> beeeh
<pitti> seems this suddendly started pulling in half the desktop
<pitti> please note that those are just differences > 200 kB
<pitti> sorry, no
<pitti> added packages are complete
<pitti> changed packages are just > 200 kB
<pitti> ttx: I blame yesterday's hplip
<pitti> do you ship that?
<ttx> yes
<pitti> it changed things quite heavily
 * ttx grumbles
<pitti> there's obviously some dependency problem here
<ttx> we should just blacklist it
 * ttx looks
<pitti> ttx: I think it might be the new python-notify dependency
<pitti> ttx: would you mind filing a hplip bug about that, milestone it, and assign to tkamppeter?
<ttx> I can do that. Though I always wondered why hplip was in server-ship in the first place
<pitti> you ship cups, and HP printers are rather popular
<pitti> but it should just ship the drivers, the desktopy bits should be separate
<ttx> do we need a quick workaround ? Or is tkamppeter around to fix it ?
<pitti> not sure whether he's awake yet
<pitti> ttx: so you could unseed hplip, or we just declare it a known bug and leave it oversized
<pitti> if you guys can test a respin again, I'm happy to respin, but it'd need to happen rather quickly
<ttx> how much time do we have to test ?
<pitti> this afternoon?
<pitti> we can prepare the notes in the meantime and finish testing the other images
<pitti> but we need some time to publish all the images and the announcement, etc.
<ttx> well, it's not as if so much testing was done overnight
<ttx> we're at 0/17 on amd64
<ttx> 6/17 on i386
<pitti> ttx: is there something in ship which we could drop?
<ttx> you mean, besides hplip ? :)
<pitti> i. e. that wouldn't require two publisher runs?
<pitti> ttx: like, we could drop postgresql-doc for alpha-2
<pitti> which should bring us below 700
<pitti> oh, hmm
<pitti> ttx: hplip is in the print-server task, and updating tasks takes two publisher
<pitti> hm, so is postgresql-doc
<pitti> why are all those duplicated?
<ttx> is postgresql-doc usually a recommends ?
<pitti> postgresql-doc is in the postgresql-server tasks, we can't easily drop it either
<pitti> i. e. not more cheaply than hplip
<ttx> the seed probably dates from a time when recommends were not installed by default
<pitti> I mean why is server-ship so crowded?
<pitti> it seems to duplicate everything in all the tasks
<pitti> which makes it hard to see which bits are _only_ in ship, i. e. not installed by any task
<ttx> looks like the duplication has been there for quite some time
<ttx> pitti: how much do we need to free ?
<ttx> there is a hplip -> sane-utils recommends but not sure that brings up enough
<pitti> ttx: if we do an upload, we can just as well drop the python-notify dependency
<pitti> which is a "more correct" thing to do
<ttx> pitti: I was thinking about blacklisting sane-utils to avoid it on the CD without changing packages -- but I don't know if that's possible
<pitti> ttx: some 1.5 MB, I think (how much to free)
<pitti> ttx: no, I don't think it is
<pitti> ttx: are you fine with a hplip upload and a respin?
<pitti> I can do the upload
<pitti> but would be nice if you could file the bug
<ttx> yes, if we have until 1500 UTC for ISO test coverage
<ttx> i'm filing the bug right now
<pitti> gets tight, but should be doable
 * pitti prepares hplip
<ttx> https://bugs.launchpad.net/ubuntu/+source/cups/+bug/600504
<ubot4> Launchpad bug 600504 in cups (Ubuntu) "Dependency on python-notify makes hplip unsuitable for servers (affects: 1) (heat: 6)" [Undecided,New]
<ttx> assigning to tkampetter and targeting to a3
<ttx> or to you on a2 ?
<pitti> tkamppeter/a3 is fine
<pitti> hplip uploaded
<pitti> I'll watch the build, and stall the publisher a bit if needed
<pitti> takes 12 mins to build, should make it
<pitti> oh argh
<pitti> amd64 builds linux and kdeedu
<pitti> but kdeedu is purging already
 * ttx wtaches the snail race
<pitti> kdeedu done now; c'mon crested, grab it
<pitti> there; should just about make it :)
 * ttx cheers
<ttx> you might have to stall the publisher a couple minutes
<pitti> ttx: hm, I could rebuild amd64 only, and keep i386 with the desktopy bits
<pitti> ttx: do you want a clean i386 respin as well? or keep the current one?
<ttx> hm, that's tricky
<ttx> on one hand I'd like to keep the already-performed tests
<ttx> on the other I'd like to have minimal difference between amd64 and i386
<ttx> is there a precedent for such arch-oriented respins ?
<pitti> we did that in the past, I think
<ttx> I prefer we do both -- I can make ISO testing happen by 1500 UTC
<pitti> sounds like a plan
<pitti> ttx: also, I guess you don't need to re-test each and every task
<ttx> hoping that last respin doesn't bring its own set of surprises
<pitti> some on i386, some on amd64 shoudl be enough for alpha-2
<pitti> especially not tasks which we didn't change since yesterday and which were arleady tested
 * ttx prepares a large softfreeze-respect-stick just in case
<pitti> hehe, please do :)
<ttx> hah, that's my first "Orthopedic Dog Beds" spam
 * ttx wonders about the success rate of that one.
<pitti> c'mon, purge faster
<pitti> publisher on manual
<pitti> there we go, publisher running, and back on auto
<pitti> this also caught the new kernel build, I hope that will go well
<cjwatson> fyi I won't be in action until a few hours from now - I start late on Thu due to baby sign language class
<pitti> cjwatson: I think I can handle it; see you later then
<ara> morning all
 * ara resyncs
<pitti> I did a desktop and a netbook install, and they work fine now \o/
<cjwatson> good, I'd done the install but couldn't wait up for it to reboot
<ara> you guys are talking about the ones that are posted?
<pitti> yes
<pitti> ttx: I set up a trigger to rebuild server ISOs as soon as the new hplip lands on the cdimage mirror
<pitti> back in 45 mins
<ttx> pitti: ok thanks
<ttx> ara: we should have new 20100701 server ISOs in a few, will need your help in promoting them to the tracker
<ara> ttx, sure, I'll be around :)
<ara> ttx, do you happen to know if kubuntu is going to be rebuilt?
<ttx> ara: I don't know
<cjwatson> rebuilt for anything in particular?
<ara> cjwatson, no, I was just wondering about the build number being lower than ubuntu and xubuntu desktop
<cjwatson> .1 rather than .2?
<cjwatson> that just means that there were fewer builds of kubuntu yesterday
<ara> I know, I just wanted to double check ;-)
<cjwatson> I respun everything containing ubiquity in sequence last night
<pitti> mythbuntu posted as well now, FTR
<ttx> pitti: server ISO still pending ?
<cjwatson> DVDs should I think be ready too
<cjwatson> haven't checked the tracker
<pitti> ttx: yes, I'm watching them
<pitti> cjwatson: will do
<pitti> DVDs added to tracker
<pitti> ttx: hm, not sure what's wrong -- but it seems that the publisher run somehow failed to publish it; the publisher finished minutes ago, but cocoplum still didn't update
<pitti> ttx: I'll continue to watch it, but might take a bit longer
<ttx> arh
<pitti> cjwatson: I'll rebuild ports, unless you are already?
<cjwatson> pitti: not doing so
<ara> mmm, Kubuntu Desktop looks like Kubuntu Netbook
 * ttx gets some coffee
<ttx> pitti: by "also caught the new kernel build" you mean the new i386 kernel that was just built ?
<ara> I guess I'll wait for Riddell
<pitti> ttx: yes
<ttx> pitti: that might make a case for a amd64-only rebuild
<ttx> at least they woud get the same kernel source
<ttx> s/rebuild/respin
<pitti> hplip was published in this publisher run
<pitti> very weird
 * ttx wonders if keeping the old i386 spin would not actually end up being closer to the new amd64 one
<pitti> ttx: the change in 6.9 was very small; do you have reason to believe that it's bad in any way?
<pitti> ttx: if you don't mind having all the desktop bits on i386, we could respin amd64 only, yes
<ttx> pitti: 6.9 actually fixes UEC
<pitti> ttx: so why wouldn't we want to pick that up?
<ttx> pitti: so we would have a fixed i386 and a broken amd64
<ttx> (UEC)
<ttx> pitti: ok, let's keep the original plan
<pitti> ttx: we can also wait another hour when the amd64 one is done (it's in the debhelper stage)
<ttx> ah! don't tempt me
<ttx> pitti: what would be the difference in ETA ? 15 vs. 75 min ?
<pitti> ttx: 40 vs. 100 min
<ttx> hm, I don't think we can afford that.
<ttx> I can use that hour for smoketesting and making sure they are good
<ttx> pitti: let's go for 40
<pitti> ttx: ack
<ttx> (I'll document the need to dist-upgrade, on amd64 only
<pitti> ttx: folks who install can upgrade to get the fixed kernel
<ttx> )
<pitti> ttx: cheers; you'll put it into "known issues" on the tech notes?
<ttx> yes
<pitti> merci
<ttx> pitti: if you have the URL of the maverick tech notes handy
<pitti> ttx: https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview
<ttx> I'll do it now
<ttx> thx
<pitti> ttx: cheers; please let me know when you are done, then I'll brush up the "what's new" bits for desktop
<pitti> ttx: btw, if you have anything worth mentioning for server, please add it
<ttx> ok
<ttx> pitti: done with the techoverview
<ttx> pitti: will think about what I can add for server without keeping the lock
<pitti> cheers
<pitti> ttx: I'm done with the first round, if you want to add stuff
<ttx> ok, ack
<ttx> done
<ara> ScottK, around?
<ttx> pitti: we are past your ETA, any new trouble ?
<ttx> (if yes, let's just stick with the oversized ISO, we are lacking time now)
<pitti> ttx: image is currently building
<pitti> it took until 3 minutes ago until the new hplip found its way to the cdimage mirror
<ttx> new ETA ~ 15 min ?
<pitti> more like 5
<pitti> "a watched archive never publishes" or so
<ttx> ok, let's live with that :)
<pitti> image build done; now mirroring to cdimage
<pitti> ttx: http://cdimage.ubuntu.com/ubuntu-server/daily/20100701/
<pitti> will hit in a minute or two
<pitti> maverick-server-amd64.iso       01-Jul-2010 10:03  694M
<pitti> yippie
<pitti> ttx: go wild :)
<ttx> ara: please promote to ISO tracker
<pitti> added to tracker
<pitti> ara: too late, I just did
<ttx> yay
<ara> pitti, thanks :D
 * ttx warms up his three test laptops
 * pitti sees ttx jumping around with six hands, controlling three laptops at once
<ara> if I had more HW, ya ha deedle deedle, bubba bubba deedle deedle dum
<pitti> kvm FTW?
<ttx> pitti: parellizing 6 installs on KVm tends to be slow
<pitti> erm, yes; I never do more than two
<ara> for me, running just 1 kvm makes my laptop almost useless for the rest of my daily tasks
<ara> sometimes I can't even read email
<pitti> erm, yes; I never do more than two
<pitti> sorry, -EFOCUS
<sbeattie> Is there a known issue about compcache's ramzswap kernel module failing to laod when booting the live cds?
<cjwatson> known in the sense that I'd noticed it, although I hadn't reported it anywhere
<cjwatson> it wasn't something I could fix straight away when I saw it, because the kernel interface changed - so best report and milestone (alpha-3) a bug about it
<cjwatson> file it on initramfs-tools and assign to me, please?
<sbeattie> ah, looking at dmesg, it's comlaining about an unknown parameter "disksize_kb"
<sbeattie> okay, will file.
<cjwatson> right, what can I most usefully do now?
<cjwatson> aha, I can test the i386 DVD, nobody's doing that
 * cjwatson tests btrfs via ubiquity while waiting
<pitti> https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview should be reasonably up to date now wrt. features, known issues, and general "alpha 2"ness
<ScottK> ara: Just passing through right now.  I should be around in a couple of hours.
<cjwatson> ubuntustudio tasks should be fixed; I'll check and remove
<cjwatson> poo, btrfs doesn't work in the desktop image
<cjwatson> no mkfs.btrfs
<ttx> we might want to add bug 599450 in there
<ubot4> Launchpad bug 599450 in linux (Ubuntu) "[apparmor] getattr handled incorrectly in 2.6.35-6.7 (affects: 2) (dups: 1) (heat: 18)" [High,New] https://launchpad.net/bugs/599450
<ttx> used to break the LAMP task, I'm in the process of reproducing with latest ISO
<pitti> cjwatson: so we need to seed it, and then teach oem-config and ubiquity to remove it (unless used)?
<cjwatson> no teaching required, it could just be handled the same way as all the other filesystems
<cjwatson> I'll file a bug
<pitti> just trying to understand what's necessary
<cjwatson> we'll need to relnote it for maverick
<pitti> I'll add it; I'll drop a stanza about that apparmor bug anyway
<cjwatson> one-liner in platform.maverick/live-common
<cjwatson> I'll take care of it
<pitti> ttx: this looks like it'd break cups in desktop as well
<ttx> pitti: sounds worthy of a TechnicalOverview note, then
<pitti> ttx: I'm adding it
<ttx> it's breaking mysql, according to zul -- I'm in the process of reproducing
<pitti> ttx: done (also mentioned MySQL); proofreading appreciated
<ttx> looking
<ttx> looks good
<ara> I get broken packages in kubuntu alternate i386
<ara> mmm, wrong iso
<ara> *sigh*
<ara> ok, the last build of kubuntu is not the candidate one
<cjwatson> hmm?
<cjwatson> 20100630 and 20100630.1 both have some broken packages
<cjwatson> I thought we'd dealt with that; did we just forget to respin?
<cjwatson> bah.  I'm going to respin kubuntu alt now
<doko> cjwatson, pitti: could you have a look at bug #600272 ? needed for the openjdk-6 uploads, needed for the firefox updates
<ubot4> Launchpad bug 600272 in ant (Ubuntu Karmic) (and 3 other projects) "ant fix to correctly build JAX-WS (affects: 1) (heat: 10)" [High,In progress] https://launchpad.net/bugs/600272
<cjwatson> ok
<cjwatson> doko: done
<pitti> cjwatson: I just went through the iso-testing bugs again, and the relevant ones are now documented in the tech notes
<pitti> cjwatson: it seems most images are ok, except for the untested kubuntu alternates and DVDs
<pitti> cjwatson: want me to start preparing the publishing?
<ScottK> ara: I'm around now.  I imagine from the scrollback your question got answered?
<pitti> (i. e. set it up, but not sync mirrors yet)
<ara> ScottK, well, it didn't, I didn't know who else to ask
<ScottK> ara: OK.  Go ahead then.
<ara> ScottK, in Desktop Live i386 Kubuntu, the live session shows as if it was the Netbook edition
<ara> is that expected?
<ScottK> ara: For small screens, yes.  We are trying to combine desktop and netbook into one image and do first run based on screen size.
<ara> ScottK, and once installed?
<ScottK> Once installed, there's an option in systemsettings to pick which you prefer.
<ScottK> Live/first run installed should be the same.
<ara> ScottK, ok, then why there are still  two images in the tracker?
<ScottK> ara: Because we didn't finish the consolidation yet.  I expect for Alpha 3 there won't be.
<ara> ScottK, OK, thanks for the explanation
<ScottK> You're welcome.
<cjwatson> pitti: yes please, I have a presentation followed by an interview, which makes it hard :-/
<pitti> ack
<pitti> cjwatson: for the record, I a-x'ed sync-mirrors
<cjwatson> thanks
<pitti> ttx, smoser: can you please publish the alpha-2 UEC images? (https://wiki.ubuntu.com/UEC/Images/Publishing)
<smoser> pitti, yeah. will-do.
<pitti> smoser: cheers
<pitti> ara: do you know if someone is testing kubuntu alternates, in particular the amd64 one?
<pitti> cjwatson: hm, do you know whether we usually publish-release DVDs?
<pitti> (we didn't for alpha-1)
<cjwatson> if they work
<pitti> cjwatson: ok, thanks
<ara> pitti, not that Im aware of, I will resync now and give it a try in VM
<ara> pitti, I cannot access the iso tracker at this moment, can you?
<pitti> no, indeed it's timing out for me as well
<ara> *sigh*
<seb128> launchpad doesn't respond either there
<pitti> jeesh, the interweb is broken
<pitti> ara: does rsync for you from cdimage?
<smoser> pitti, uec images are public and amazon's ami pages have been updated. http://uec-images.ubuntu.com/releases/maverick/alpha-2/
<pitti> it seems everythin http-ish might be down, but e. g. ssh works just fine forme
<pitti> smoser: nice, thanks
<ara> pitti, no, I was syncing kubuntu amd64 alternate, and now it is stalled
<pitti> oh, seems to be back?
<pitti> works again for me
<pitti> just joined the IS channel, they are on it
<lamont> oh hai
<pitti> ah, thanks to whoever tested kubuntu alternate
<pitti> hey lamont
<lamont> I have no idea which or how many builds failed from that...  reenabling the farm now
<pitti> ok, done with preparing the image publishing
<pitti> I'm waiting for kubuntu alternate amd64 confirmation
<pitti> bladernr_: hello! how is your kubuntu amd64 install? any problems with it?
<bladernr_> yeah
<bladernr_> fails at select and install software
<bladernr_> also, in VirtualBox at least, if I go from tty1 to tty2 to run a shell command, then go back to tty1, the installer screen doesn't redraw completely, so I get a bunch of vertical lines
<cjwatson> I see that in kvm from time to time; switching to tty2 and tty1 again usually clears it
<cjwatson> it's not an installer bug as such, must be a bug in either bogl-bterm or the kernel
<cjwatson> bladernr_: can I see the installer syslog please?
<pitti> bladernr_: uh, that's still with the 20100701 image? i386 was reported to work
<bladernr_> pitti:  actually, I have no idea... it is whatever was up as of yesterday, was this one of the respins?
<cjwatson> oh, yes, yesterday's had broken packages
<pitti> bladernr_: yes, it was respun today
<cjwatson> that's why we respun
<bladernr_> ahhh... then disregard my angst... it took me 14 hours to rsync the images yesterday so and I just heard of respins, but wasnt sure which ones were done
<bladernr_> thanks, I'll resync that and try again
<pitti> cjwatson: any other blocker from your side? I have the wiki page and email announcement prepared, images publish-release'd on antimony, and newz2000 standing by
<pitti> (just to re-sync on where we are)
<pitti> cjwatson: syncing mirrors now, since that'll take a while; in the unlikely case that kubuntu amd64 alternate is botched, re-syncing will be faster
<cjwatson> pitti: the baton is yours unless you desperately need it to be mine - I've been on the phone most of the afternoon
<pitti> cjwatson: ack
<pitti> cjwatson: that's fine, I have nothing particular on the evening (except an hour phone call), I'll be around for another 5 h at least
<Riddell> I am downloading maverick-alternate-amd64.iso if it still needs tested but it says it won't be done for 40 minutes
<pitti> Riddell: thanks
<Riddell> pitti: we're not doing dvds I take it?
<pitti> Riddell: if anyone tests them, we can publish them
<pitti> but I guess they aren't that interesting/important for a2, what do you think?
<Riddell> mm, at these download speeds that may not work for me
<Riddell> it's interesting only to know that it won't be a sudden headache for alpha 3 or beta
<ara> Riddell, I will start an amd64 test in 5 min
<Riddell> great
<bladernr_> pitti:  synced kubuntu alternate amd64 and redid, and still dies at "select and install software"
<bladernr_> trying one more time just to be sure...
<pitti> bladernr_: can you please rescue /var/log/syslog?
<pitti> bladernr_: on the iso there is a .disk/info which would have the timestamp
<bladernr_> pitti:  working on that, I'll let you know when I've got it.  FWIW, this is a VBox VM, not bare metal (my work laptop is my only bare metal 64bit machine)
<pitti> that's fine
<pitti> bladernr_: on 20100630.1 it was still broken: http://cdimage.ubuntu.com/kubuntu/daily/20100630.1/report.html
<pitti> bladernr_: but on 20100701 it should work (http://cdimage.ubuntu.com/kubuntu/daily/20100701/report.html)
<bladernr_> Kubuntu 10.10 "Maverick Meerkat" - Alpha amd64 (20100701)
<pitti> that looks right
<pitti> bladernr_: if you could switch to a terminal and check /var/log/syslog what it's failing on, that'd be great
<bladernr_> pitti:  oddly enough, this second run on that iso seems to be working :/ perhaps the first try (which was a vbox soft reset) cached the bad iso, while a power-down and restart re-read the data?
<bladernr_> but so far it is doing the software install... so far so good, at least...
<pitti> bladernr_: ah, thanks; seems we got two amd64 kubuntu testers now \o/
<pitti> so, time to continue then, I guess
<bladernr_> pitti:  I could have sworn that I posted the result here... anyway, worked fine on the second try.  Installation successful with one UI issue that I filed a bug for (600716)
<pitti> bladernr_: much appreciated, thanks for testing!
<bladernr_> moving on to the rest of the kubuntu alt 64 tests
<pitti> announcement sent -- folks, it's officially out
<pitti> thanks to all for helping with testing, bug triaging, fixing, and release engineering!
<cjwatson> fantastic, thank you so much
<cjwatson> I was expecting to have to do more of that than I in fact did, so sorry about that ...
<cjwatson> roll on having a dedicated RM again. :)
<pitti> cjwatson: don't worry, it was good teamwork
<pitti> cjwatson: thanks for another nice milestone release
<ttx> pitti, cjwatson: thanks for your help !
#ubuntu-release 2011-06-28
<micahg> would anyone have a problem if launchpad was more explicit about which Archive Admin does things (i.e. rejections or anything else which causes a notice to be sent that an archive admin did something)?
<ogra_> skaet, https://bugs.launchpad.net/bugs/747229
<ubot4> Launchpad bug 747229 in ubiquity (Ubuntu Oneiric) (and 2 other projects) "weird color change during oem-config debconf package removal step in serial installs (affects: 1) (heat: 12)" [Medium,New]
<doko> skaet, slangasek: bdmurray just points out, that the advanced search allows you to select the component (https://bugs.launchpad.net/ubuntu/+bugs?advanced=1)
<skaet> doko,  I use the advanced search capacity regularily.  It doesn't let you filter out tags.  (There is no Tags:  * not).
<bdmurray> skaet: you use -tag for that
<bdmurray> skaet: so -ftbfs
<doko> skaet: it's not a tag, there is an extra option for it
#ubuntu-release 2011-06-29
<hggdh> skaet: here it is: http://people.canonical.com/~cjwatson/packagesets
<skaet> thanks hggdh.
<micahg> that doesn't have all package sets (not sure what the actual question was)
<cjwatson> yes, use the API if you want actual current data rather than aspirational data
#ubuntu-release 2011-07-01
<skaet> hi all,   it looks like we're going to not have quorum for the release meeting today (due to the Dublin rally closing meetings),  so the release meeting today will be cancelled.     The agenda can be found at: https://wiki.ubuntu.com/ReleaseTeam/Meeting/2011-07-01.
<charlie-tca> Thank you
<Laney> is someone going to send a DIF announcement?
#ubuntu-release 2011-07-03
<Laney> it'd be nice if someone from ubuntu-archive processed the removal requests
<persia> I suspect nothing will happen until folk get over jet lag.
<persia> (unfortunately)
<Laney> no massive rush
#ubuntu-release 2012-06-25
<NCommander> sk
<NCommander> wn 23
<NCommander> argh
<ogra_> cjwatson, does that look right ? http://paste.ubuntu.com/1058761/
<ogra_> (or should the arm arches just be added to the bottom line of the file ?)
<cjwatson> ogra_: No, better not, as that would affect all flavours.  That patch looks fine to me, except please sort the architecture names in the second chunk
<ogra_> alphabetically ?
<cjwatson> Yes
<ogra_> k
<cjwatson> (Well, I suppose we could override it in all flavours, but ARM is probably still sufficiently special that it's better not to I think)
<ogra_> yeah, and flavours might not like the additional build time for their manual builds
<jibel> quantal server and alternate failed to install automatically due to a warning. I filed bug 1017398
<ubot2> Launchpad bug 1017398 in debian-installer "Quantal Server and alternate installation failed with error "Failed to retrieve InRelease"" [Undecided,New] https://launchpad.net/bugs/1017398
<cjwatson> Thanks
<cjwatson> Will fix once I have updated images handy
<Daviey> hah, i was just about to look into that myself.. Super!
<cjwatson> Yeah, sorry for delay, had a phone call, but on it
<cjwatson> jdstrand: So, I'm tantalisingly close to having Archive.copyPackage work for you guys - not quite there as I missed a piece in what got deployed this morning (so don't try to use the shiny new unembargo=True flag yet as it won't work), but nearly
<cjwatson> jdstrand: However, as it stands, the copies will land in the queue and require an archive admin to accept them, which I don't think will be acceptable
<cjwatson> jdstrand: Do you think it would be sufficient for this to fix bug 648611 and grant ubuntu-security queue admin on the security pocket (which realistically is basically the current policy, just implemented extremely oddly), which would require you to manually accept the copies; or do I need to fix bug 1006871 somehow as well?
<ubot2> Launchpad bug 648611 in launchpad "ubuntu-sru either have too much or too little permission as queue admins" [High,Triaged] https://launchpad.net/bugs/648611
<ubot2> Launchpad bug 1006871 in launchpad "Copying packages to -updates always goes through unapproved queue, even when copying user is privileged" [Low,Triaged] https://launchpad.net/bugs/1006871
<cjwatson> jdstrand: I'd like to kill off unembargo-package.py and the hack that lets you use Archive.syncSource ASAP, but obviously not at the cost of getting in the way of security updates
<jdstrand> cjwatson: not looking super-closely at the bugs-- if 648611 allows us to use to maintain our autonomy, I think that is fine. I've already added some output to our script for approving things and that is acceptable (if a mild nuisance)
<jdstrand> s/to use//
<jdstrand> that could have been a clearer sentence. aiui, fixing 648611 should be enough
<cjwatson> jdstrand: OK, thanks.  FWIW I do already have a branch up for review that adds sufficient API that the worst case would be that the script would have to poll for a minute or two until it can accept the copy for you
<jdstrand> cjwatson: so, I have a libreoffice and oo.o update that I plan to push today. would you like me to try to use copyPackage on it?
<jdstrand> cjwatson: (not for testing the unapproved bits, but the other parts)
<cjwatson> jdstrand: No, you can't yet
<jdstrand> ok
<cjwatson> "not quite there as I missed a piece in what got deployed this morning", as above
<cjwatson> The fix for that has been reviewed but needs to go through test suite, landing, QA, deployment
<jdstrand> oh, I quickly read that 648611 was said piece
<cjwatson> No, that one's separate
<cjwatson> The bit that was broken was that my initial attempt had a bug which caused mail notifications to crash after the restricted files were unrestricted, because they were trying to get at uncommitted librarian files
<cjwatson> So I'm moving the privacy update after mail notifications instead, since anything else is unspeakably cumbersome
<cjwatson> If you try to use copyPackage(unembargo=True) right now it'll just crash when trying to run the copy job
<jdstrand> I see
<cjwatson> That'll hopefully be fixed by tomorrow, depending on buildbot runtime and such
<jdstrand> cjwatson: thanks for all your work on this btw :)
<cjwatson> np, I will get considerable LP LoC credit out of it ;-)
<jdstrand> :)
<cjwatson> Not to mention the ability to actually understand the copy code once it's about half the size
<cjwatson> I'd be well up for you doing a test run once a fixed version is deployed; I guess that would at least be enough to remove unembargo-package.py, since you're only using that as a fallback right now
<cjwatson> And we can keep Archive.syncSource around until you have more self-service queue admin
<jdstrand> cjwatson: I'll be off Tu-Th, but feel free to ask mdeslaur to coordinate that with a member of my team
<cjwatson> OK, cool
<dobey> so, have we dropped the alpha freezes, or does the soft freeze happen at the end of today?
<skaet> dobey,  switch over to using -proposed will happen later today
<cjwatson> Where's the Launchpad branch for that?
<dobey> ok
<cjwatson> Or the ubuntu-archive-tools branch/commit
<skaet> cjwatson,  thought we'd follow the same pattern as A1
<skaet> issue?
<cjwatson> Absent code to direct (a) auto-syncs and (b) uploads to -proposed, it'll be ineffective
<cjwatson> This is in a relevant blueprint somewhere ...
<cjwatson> The pattern for A1 was for people to upload to -proposed basically on the honour system, which sort of works some of the time but is not desperately effective and is certainly cumbersome
<skaet> not as effective as we'd like,  but at least doesn't block some of the larger builds from progressing.
<cjwatson> So as long as that's understood, fine
<cjwatson> I thought you meant something stronger
<skaet> no,  very much understand our infrastructure is not in place yet for that.
<cjwatson> OK
<cjwatson> Hah, I was just getting ready to QA that
<cjwatson> less work for meeeee
<Daviey> stgraber: In the ISO tracker, "Quantal Alpha 2" and "Quantal Daily" should both be in the Testing state, right?
<Daviey> (I just created the A2 milestone)
<stgraber> Daviey: yep. Whenever cron is disabled on nusakan and you start building new images, I usually mark the daily milestone as archived or released so people don't try and look for dailies when we aren't building them
<Daviey> stgraber: ok, thanks.
<ScottK> seb128: ^^^ How's that for service?
<bjf> cjwatson, infinity, bug 1004556. who handles getting a package from -proposed to -updates?
<ubot2> Launchpad bug 1004556 in linux-armadaxp "linux-armadaxp: 3.2.0-1603.6 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1004556
<cjwatson> Periodic sweeps of pending-sru by archive admins
<cjwatson> The fact that the previous upload didn't have a tracking bug broke our processes so you didn't get it done
<cjwatson> Please include tracking bugs in future
<bjf> cjwatson, ack
<cjwatson> (In the changelog, that is)
<bjf> cjwatson, ack
<cjwatson> Looking now
<seb128> ScottK, that's excellent, thanks a lot ;-)
<cjwatson> bjf: Done
<bjf> cjwatson, many thanks
<Daviey> cjwatson: As bug 1017398 is fixed, re-spinning alternate and server make sense?
<ubot2> Launchpad bug 1017398 in debootstrap "Quantal Server and alternate automated installation failed with error "Failed to retrieve InRelease"" [Undecided,Fix released] https://launchpad.net/bugs/1017398
<cjwatson> Oh, sure
<cjwatson> Running now
<Daviey> oh, thanks.
<Daviey> (I wasn't asking you to do it, just checking if it should now be done.. but thanks muchly for doing it)
<cjwatson> I forgot you had nusakan access
<Daviey> cjwatson: kindly forget for the rest of the week. :)
<cjwatson> Ha
<cjwatson> No chance mate :)
 * xnox is reminded of the MIB red light tool
<skaet> ev,  cjwatson - does it make sense to put out WUBI images this milestone?   looks like the same problem we had in A1 is still there. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1009564
<ubot2> Ubuntu bug 1009564 in wubi "Quantal Ubuntu Wubi failed to install" [Critical,Confirmed]
<skaet> Daviey, ^
<Laney> ..
<cjwatson> I have no opinion on the matter
<Laney> err, no
<cjwatson> One way to form an opinion might be to try to find out whether only jibel is affected or whether it's widespread
<cjwatson> That bug only has one person marked as affected
<ev> skaet: seems like more of a question for the kernel team. I'd rather not kick the can down the road, but I'm not sure how much is involved in fixing it.
<skaet> balloons,  ^ do you know if anyone else has tested WUBI, and its not been makred.
<ev> but I agree with cjwatson that we should first see how much of an issue it is.
<balloons> not for alpha 2 to my knowlede
<Daviey> I think it's reasonable to ship it for the Alpha series, with a Potentially known issue on the Release notes, requesting further confirmation. No?
<balloons> although people weren't successful @ alpha 1
<balloons> remember :-)
<skaet> Daviey,   we didn't ship it for Alpha 1,  so getting more data right now seems prudent.
<Daviey> If we withhold something that we think could have issues, then we won't get the exposure to confirm it.
<skaet> balloons,  yeah its the alpha 1 data (or since then) we're trying to figure out about WUBI.   Was there any testing in last week's set?
<balloons> to wubi, none to my knowledge
<skaet> Daviey,  its more that if its still broke, and there isn't a fix likely, so we want to waste folks time....
<balloons> typically have to go ask for that :-)
<cjwatson> skaet: seems like we ought to verify the assumption in that first clause by getting somebody else to double-check
<skaet> balloons,  can you see if we find someone to help double check if the issue is still there?
<skaet> cjwatson,  yes
<balloons> yes, I'll ask to have it looked @ again
<skaet> thanks balloons
<ogasawara> skaet: v3.5-rc4 was released yesterday and we've already rebased our Quantal kernel.  I'd like to squeeze in an upload in time for A2.  When would be the latest we could upload?  The reason I ask is there is also a bugfix for arm I'm told is getting addressed and should be fixed by tomorrow.  Would an upload tomorrow morning be too late?
<skaet> ogasawara,  we'll switch over to using -proposed at 2100,  upload today would be better if possible, since the image testing will start tomorrow AM.   I suspect its going to be a case of upload when its ready, and we'll decide if we respin or not for it,  when its there.
<skaet> ogasawara,  is there a bug number for the arm fix?
<jibel> skaet, wubi r270 with disk image 20120625 is ok. Same system that was failing on A1.
<jibel> I'll update and close the bug report
<Daviey> ogasawara: can you comment if it's an ABI change?
<ogasawara> skaet: ack, I'll check with ppisati for a bug# and let you know
<ogasawara> Daviey: it will be an ABI bump
<Daviey> If the kernel goes via -proposed.. cjwatson, we'll need a d-i no-change rebuild, right?
<cjwatson> Daviey: Yes, though it doesn't strictly have to be in the same block migrated to release as the old ABI will stick around in NBS until d-i is done
<xnox> if anything e2fsprogs update raises, please do not hesitate to get in touch with me
<xnox> I would like some pieces of text to be included in the Apha 2 announce in relation to many updates in the filesystems stack
<xnox> Where / How do I submit these for inclusion?
<skaet> xnox,  please put them in the QuantalQuetzal/TechnicalOverview/Alpha2 wiki page
<xnox> skaet: ok, thanks
<xnox> skaet: it's not symlinked from the release schedule, will fix that as well.... unless it's done as an milestone release step on thursday?
<skaet> xnox,  link didn't go in to schedule until after its released,  but with the recent changes (ie. we are using TechnicalOverview/Alpha2 rather than just TechnicalOverview),  we can do it now.   Its a good idea.
<xnox> skaet: ok.
<xnox> skaet: Please spell check / technical language check https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Alpha2#Filesystem_Stack
<skaet> xnox,  will do when I tak my next pass over it.   Thanks!  :)
<xnox> skaet: you should subscribe to the page, to get spammed =))))
<skaet> xnox,  usually do,  just hadn't remembered yet.  Thanks for the reminder, done.
<skaet> :)
<xnox> skaet: ok, I'm done now for the day. Good luck rick-rolling & spinning the cd bundle =)
<bdrung> ScottK: desktop-file-utils is accepted in precise-proposed, but audacity not?
<ScottK> bdrung: Yes.  Do they have to go together?
<seb128> they don't, but having that specific issue resolved requires both sides
<bdrung> ScottK: it make sense to combine them
<seb128> it will not break anything having only desktop-file-utils though
<seb128> d-f-u specify which handle to pick if there are several options
<bdrung> seb128: but can it be tested without the patch for audacity?
<seb128> the audacity part adds audacity as an option
<ScottK> I had time to review one this morning and d-f-u was easy.
<seb128> bdrung, by hacking locally the audacity .desktop yes ;-)
<seb128> ScottK, that was still useful, the libreoffice bug has already been verification-done ;-)
<seb128> the audacity one can be confirmed later, the update has to stay a week in proposed anyway
<ScottK> Yeah.
<ScottK> Actually the audacity one is pretty easy too.  Accepting.
<ScottK> slangasek: speaking as a VERY new member of ubuntu-sru, I agree with your assessment about delegations.
<slangasek> ScottK: ack
<micahg> skaet: about the release announcement, shouldn't the stuff about making stuff uninstallable go before the other stuff in the list?  It seems to read that milestone bug fixes even if they make something uninstallable can go to the release pocket
 * micahg forgot if he mentioned this last time
<cjwatson> I assume that I should not run auto-syncs for a while
<skaet> cjwatson
<skaet> cjwatson,  yes that was going to be my request in the channel.
<skaet> micahg,   I'll post the rules on the pad, and put it in the order you indicate there.
<cjwatson> Easy enough to do
<cjwatson> Or not to do
<skaet> exactly.  :)
<skaet> thanks cjwatson.
#ubuntu-release 2012-06-26
<RAOF> I have the Launchpad permissions to copy the X stack from quantal-proposed to quantal; do I also have the authority?
<jibel> RAOF, can you look at bug 1017477 it breaks upgrade to Quantal with current X stack in quantal-proposed
<ubot2> Launchpad bug 1017477 in xserver-xorg-video-qxl "Precise to Quantal failed to upgrade with -proposed enabled: -qxl depends on xserver-video-abi-11 but -12 is in proposed" [High,New] https://launchpad.net/bugs/1017477
<infinity> A rebuild of qxl would fix that, I'm sure.
<RAOF> It would indeed.
<RAOF> I thought I'd done that. Thanks.
 * infinity throws one at proposed.
<RAOF> If you want to :)
<RAOF> Also, I didn't know we tested upgrades with -proposed enabled. Do we actually support that?
<infinity> RAOF: Done.
<RAOF> Ta muchly.
<infinity> RAOF: We don't support it, but it's a nice metric to have.
<RAOF> In return, I shall finish fixing the xf86-video-msm's build.
<infinity> Hrm, that's a fair bit of toolchain updating at the beginning of builds.  Time for me to refresh the chroots again, methinks.
<cjwatson> RAOF: I'm not sure whether you technically do, but please do this one anyway.  I was waiting to talk to somebody who knew about it. :-)
<cjwatson> (Once those video drivers are sorted, anyhow)
<RAOF> Oh, we seem to be missing fglrx, too, and while it is supposed to support 1.12 it segfaults on a 64bit server. Urgh.
<RAOF> Can we ignore the existence of proprietary blobs yet? :)
<infinity> RAOF: I don't use proprietary drivers, so clearly no one else does.
<Daviey> ogasawara: When are we expecting the next kernel upload?
<jibel> livefs for Ubuntu Desktop were built more than 1 hour ago but there's still no CD (and no cd log), can anyone look what's happening ?
<jibel> Daviey, ^
<cjwatson> It's waiting for armhf livefses to finish
<cjwatson> Wait
<jibel> it's me being impatient then :)
<cjwatson> Now that they're being built in the same run it blocks on them all
<Riddell> kde packages should now be in a state where images can be made, please add them to the queue
 * Daviey goes home.
<seb128> infinity, thanks for the g-s-d approval! ;-)
<infinity> seb128: NP.
<infinity> seb128: In the future, can you avoid setting "Fix Committed" when you upload to proposed?
<infinity> seb128: Our snazzy scripts do that when we accept, so it's a bit harder to track status if it's already in that state.
<seb128> infinity, hum?
<seb128> infinity, ok, I though we were meant to set to fix commited when uploaded, that's what I've been doing so far
<infinity> I suspect there are two entirely different workflows at play here.
<infinity> It's not world-ending if you track your bugs differently than I'm used to, just a bit confusing.
<seb128> infinity, would be good to have that documented one way or another in https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<infinity> And, to be fair, I'm not sure if the "proposed = committed, updates = released" thing is documented.
<infinity> (Which means "uploaded to proposed, but not accepted" is another state entirely, like "in progress")
<infinity> seb128: Yeah, let me open the wiki as a subtle reminder to myself, and I'll see about documenting something when I'm not asleep.
<seb128> infinity, I'm open to any workflow there, i.e using "in progress" for things waiting in the queue works for me
<seb128> infinity, thanks
<cjwatson> Yeah, that's what I do
<cjwatson> infinity: Looks like you should update your ubuntu-archive-tools to Brian's newest revision
<cjwatson> (for sru-accept)
<cjwatson> Actually, let me tidy that up a little more
<infinity> cjwatson: Hrm?  I'm out of date again? :P
<infinity> I really should cron that bzr pull.
<cjwatson> OK, done
<ogra_> hmm, did anyone plan to upload ubiquity before A2 ?
 * ogra_ would need the arm fixes 
<cjwatson> Hadn't but can do, shall I?
<ogra_> that would be great, yeah
<cjwatson> I'll send it to -proposed
<ogra_> thx
<jibel> there is a problem with external keyboard on alternate and server images. I filed bug 1017879
<ubot2> Launchpad bug 1017879 in debian-installer "External USB keyboard stops working when d-i starts" [Critical,New] https://launchpad.net/bugs/1017879
<Daviey> jibel: you rock my world.
<jibel> Daviey, in the cloud times, why would you want a keyboard on a server anyway.
<cjwatson> jibel: -> incomplete
<Daviey> jibel: i'm about to do a server install, with an integrated keyboard.. for giggles, i'll attach an external and reproduce
<jibel> cjwatson, I attached the output of lsmod during and after installation of a server image.
<cjwatson> I need it from a running desktop image, as I said on the bug ...
<cjwatson> Though I guess the post-installed config might be helpful, but it's usually easier if instructions are followed exactly
<cjwatson> Does the external keyboard work post-install?
<jibel> cjwatson, output from a running desktop image attached
<jibel> the keyboard works post-install
<Daviey> Confirmed that todays image doesn't work with external usb keyboard.
<cjwatson> Mostly waiting for my kernel trees to update in order to look at this
<cjwatson> Though it could be udev or d-i
<ogasawara> Daviey: we just received the omap3 patches we were waiting for, so I plan to apply those, quick test build/boot, then upload.  so I'm guessing upload eta is ~1hr from now.
<jbicha> are we waiting on the new atk until after Alpha 2? I'm just curious as the gnome-shell stack update needs it
<cjwatson> ogasawara: I haven't yet figured out whether this external USB keyboard problem is yours or mine
<seb128> jbicha, it's in quantal-proposed
<seb128> jbicha, you can upload new gnome-shell stack there as well
<Daviey> ogasawara: Super, looking forward to it.. Hopefully it will unblock i386 cloud images.
<jbicha> right, I did that, I was just checking if it would stay in -proposed for the next few days
<ogasawara> Daviey: indeed, smb filled me in just now for that
<Daviey> thanks
<seb128> jbicha, ok, I don't know about that, I guess you can make a case to move it to quantal if you want the new gnome-shell in for a2 though ;-)
<ogasawara> cjwatson: just catching up on that bug...
<jbicha> seb128: it's not a big deal to me, gnome-shell won't be on any official or unofficial A2 images AFAIK
<cjwatson> ogasawara: Could the problem be missing hid-generic in input-modules?  It hardly seems to do anything though
<ogasawara> cjwatson: I was just thinking the same
<cjwatson> usbhid is there, mac_hid is just for mouse button emulation
<ogasawara> jibel: when you insert the external keyboard, any messages show up in dmesg re: hid-generic?
<cjwatson> udev is identical between precise and quantal so surely not that
<cjwatson> rootskel's only had trivial changes
<jibel> ogasawara, when I plug the keyboard dmesg says: kernel: [    16.311471] usb 2-1.1 new low-speed USB device number 4 using ehci_hcd
<jibel> do you want me to try the same in a live session where keyboard works ?
<ogasawara> jibel: wouldn't hurt, although I think it is the culprit
<ogasawara> cjwatson: commit 8215d557e5f3a70e50e07c857d35c250fee62a73
<ogasawara> Author: Henrik Rydberg <rydberg@euromail.se>
<ogasawara> Date:   Mon Apr 23 12:07:07 2012 +0200
<ogasawara>     HID: Create a common generic driver
<ogasawara>     
<ogasawara>     Move the hid drivers of the bus drivers to a common generic hid
<ogasawara>     driver, and make it a proper module. This ought to simplify device
<ogasawara>     handling moving forward.
<ogasawara> cjwatson: that's new as of v3.5-rc1
<cjwatson> Right, but the actual code seems trivial; how does not having it break?
<ogasawara> cjwatson: so I'll add hid-generic to input-modules
<cjwatson> I assume I'm missing something so mostly trying to educate myself
<jibel> ogasawara, this is the output when I plug the keyboard with a live session: http://paste.ubuntu.com/1060722/
<ogasawara> jibel: thanks
<Riddell> Daviey: what's the status of alpha 2 candidates?
<Daviey> Riddell: need a rebuild when new kernel alnds
<Daviey> lands*
<Daviey> OTP
<Riddell> gotcha, thanks
<cjwatson> ogasawara: So yeah, from jibel's output adding that to input-modules looks right
<cjwatson> Daviey: We'll need a d-i upload too
<ogasawara> cjwatson: ack, my test build to confirm it's in the input-modules udeb is just finishing up, then I'll upload
<Daviey> \o/
<ScottK> That's all the 7 days +verified SRUs for today.
<apw> cjwatson, i assume the d-i versioning for master and lowlatency are separate ?
<apw> s/master/generic et al/
<cjwatson> d-i doesn't have lowlatency images so we don't care about that
<apw> ahh good point
<cjwatson> ubuntustudio d-i just uses generic
<cjwatson> or generic-pae or whatever
<stgraber> jibel: ^ fixed, though I think that list is a bit wrong... shouldn't it be amd64, amrhf+*, i386 and powerpc instead?
<stgraber> (my script just publishes all active products)
<jibel> ogasawara, cjwatson keyboard not working after completing 'check disk' on a desktop image is the same problem than bug 1017879 ?
<ubot2> Launchpad bug 1017879 in linux "External USB keyboard stops working when d-i starts" [Critical,Fix committed] https://launchpad.net/bugs/1017879
<cjwatson> Not as such
<cjwatson> Might be kind of vaguely similar
<cjwatson> But 1017879 is specific to d-i and "check disk" isn't
<cjwatson> The latter's probably hid-generic being missing from the list of HID modules in initramfs-tools
<jibel> ok, I'll file another report. What info do you need ?
<cjwatson> Nothing more
<cjwatson> Just need a bug number to close with the fix
<jibel> bug 1017991 filed
<ubot2> Launchpad bug 1017991 in initramfs-tools "Keyboard stops working after completing 'Check disk'" [Undecided,New] https://launchpad.net/bugs/1017991
<micahg> skaet: someone forgot to fix the topic in #ubuntu-devel and here for the freeze
<balloons> cjwatson, on bug https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1008717, is there any reason why the scrollbars would appear in the slideshow and then later disappear? At a certain point it seems like a redraw takes place
<ubot2> Ubuntu bug 1008717 in ubiquity "Ubiquity displays scrollbars inside of slideshow" [Medium,Triaged]
<cjwatson> Sorry, I don't know, maybe somebody else does
<cjwatson> On a call, but that's not an area I've touched much anyway
<cjwatson> jibel: Fix uploading now, untested
<xnox> balloons: pure guess: the translation is one line longer....
<xnox> based on the screenshots
<ogra_> balloons, they disappear for me as soon as i grab the window and move it
<ogra_> so yeah, there is a redraw ... and it pretty likely calculates a wrong size somewhere before the initial draw
<balloons> hmm.. glad I'm not the only one seeing such things :-)
* ChanServ changed the topic of #ubuntu-release to: Quantal A2 prep: please use -proposed during this soft-freeze | Quantal Quetzal 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 birdseed | melior malum quod cognoscis
<skaet> micahg,  topics updated,  thanks for the flag.
<Daviey> hmm.. how did that happen?
<stgraber> Daviey: you apparently forgot to turn off cron
<stgraber> Daviey: based on "crontab -l" (as cdimage)
<Daviey> stgraber: it is disabled now.. but i wasn't going to do it until all were built
<skaet> Daviey, have done #9 on th list now.
 * skaet just noticed checklist is still pointing to precise for launchpad UI.... fixing
<skaet> Daviey,  is there a plan for d-i upload and build after the kernel finishes?
<Daviey> skaet: tentative
<skaet> no ABI changes?
<Daviey> it's noted that it's required.
<Daviey> I'm normally more comfortable when cjwatson touches d-i.. but really, i suppose anyone can do it.
<Daviey> right now, i'm stopping for dinner.. I can't imagine much will change whilst i'm gone.
<skaet> Daviey,  ok,  have it a bit more explicit in the tracking.   If you're handling the d-i that's fine, otherwise we'll need to line that up.
<infinity> Once the kernels get bounced from proposed to release, I can do a quick d-i respin, if we don't also have other things d-i is waiting on.
<infinity> And yes, it's an ABI change.
<skaet> thanks infinity
<balloons> does anyone know about this? I've had this for several weeks now. And now it's preventing me from reporting iso testing bugs as well ;-( https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1013334
<ubot2> Ubuntu bug 1013334 in apport "apport could not connect to crash database" [Undecided,Confirmed]
<cjwatson> skaet,Daviey: I can take care of d-i this evening
<cjwatson> but I was waiting for the kernel to land, obv
<skaet> ev, ^ do you have other reports of bug 1013334 being seen by others?
<ubot2> Launchpad bug 1013334 in apport "apport could not connect to crash database" [Undecided,Confirmed] https://launchpad.net/bugs/1013334
<skaet> thanks cjwatson,  infinity has chimed in that he'd help.
<infinity> cjwatson: Kenrels will be "a while" still, I'm sure.
 * infinity ponders killing that gcc-snapshot on PPC and scoring it to oblivion.
<infinity> I wish I'd noticed it earlier.
<cjwatson> I need to do some LP QA later anyway, since I had a qa-bad so the deployment pipeline tomorrow gets complicated otherwise.
<stgraber> Daviey: Bryce uploaded xserver-xorg-input-synaptics to the release pocket by mistake. That package is seeded by pretty much everything so I guess it'd be best for it to finish building everywhere before the next respin
<infinity> I assume we're waiting on kernels anyway, which are much further off than synaptics.
 * Daviey returns
 * Daviey guesstimates another 2hrs on armhf
<seb128> ^ rejected that xkeyboard-config upload, we need to sort an issue
<infinity> Daviey: Another 4h on PPC (kernel got stuck behind a gcc-snapshot build I just killed), but only a few images ship PPC, so they could be strategically built last. :P
<infinity> Daviey: Oh, wait.  No.  Since the kernel is in proposed, we kinda need to wait for the PPC build to do the copy.
 * skaet --> dr. appt. will be online later.
<phillw> infinity: the ppc build for lubuntu is already in http://iso.qa.ubuntu.com/qatracker/milestones/222/builds ??
<infinity> phillw: There will be another when the new kernel lands (as there will be for everything).
<phillw> infinity: thanks, I'll tell the guys to hold fire on testing! When is A2 due to release?
<infinity> phillw: Oh, no, if people are testing, please let them test.
<infinity> phillw: If they find bugs, we want to fix them now, not in 8 hours, or 2 days.
<infinity> (Don't wait for the "final" image to test, cause then if it's broken, it's not the final image
<infinity> )
<phillw> infinity: respins that wipe out bug reports, drive the testers mad! It is for this reason the new qa tracker is supposed to keep a hold of them :) You make a concerted effort, validate all the mandatory tests, then some 'bright spark' puts a new release out and resests all tests to zero :P
<phillw> I'll alert them, instead to the fact there is a kernel release across everything, then log off so they don't "chew my head off" :)
<infinity> phillw: Yeah, that feature of the tracker is annoying, but the bug reports are still valid.
<infinity> phillw: And they don't go away.
<astraljava> infinity: Hi, and thanks for your work already for Studio! There's a minor glitch, though. bug #1018075
<ubot2> Launchpad bug 1018075 in ubuntustudio-meta "quantal still wants linux-lowlatency-pae on i386 even when that variant has gone away already" [Undecided,New] https://launchpad.net/bugs/1018075
<infinity> astraljava: Oh, indeed.  Can fix.
<astraljava> I have updated the seeds regarding headers.
<astraljava> infinity: Thanks so much!
<cjwatson> Needs to be fixed in livecd-rootfs, debian-cd, and cdimage.
<infinity> cjwatson: Yeahp.
<infinity> Also, need to drop the -pae from meta.  I hadn't noticed Andy had done the rename/dropping from the 3.5.0 upload.
<infinity> Oh, actually.
<infinity> Don't want to drop it, want to have transitional metapackages.
<infinity> Which will allow the rest of the machinery to work for now anyway.
<infinity> (Though it should all be fixed)
<cjwatson> https://dogfood.launchpad.net/ubuntu/precise/+queue?queue_state=2&queue_text=  hey, this actually looks sort of plausible
<stgraber> nice!
<infinity> cjwatson: Pretty.
<infinity> cjwatson: I assume they're still accepted as a unit with the build record?
<cjwatson> Yeah
<cjwatson> That's the effect of running the PCJ after accepting the sync in the unapproved queue
<cjwatson> Probably would be neater to have them in a single PackageUpload, but this way I got to reuse a giant pile of code from elsewhere
 * cjwatson tries publishing that
<infinity> astraljava: meta is fixed.  Other fixes can trickle in whenever, but are less urgent (as, for now, -lowlatency-pae will just pull in -lowlatency)
<phillw1> reverted back to 3G, WiFi is having a really bad hair day!
<astraljava> infinity: Many thanks!
<cjwatson> Harmless OOPS when copying the Rosetta translations over (which shouldn't be done anyway), but otherwise this works.  Yay.
<infinity> cjwatson: What was the reasoning behind debian-cd using generic for ubuntustudio alternates?
<cjwatson> It didn't seem worth d-i building lowlatency images.
<infinity> Oh, right.
<infinity> And lowlatecy doesn't do udebs.
<infinity> Derp.
<infinity> Check.
<cjwatson> I *think* it still installs ll on the target.
<infinity> Alright, lowlatency fixes committed to debian-cd and cdimage, don't pull them to production until -meta and livecd-rootfs agree (both of which were also uploaded, though the latter to -proposed, and now I'm wondering why I did that...)
<micahg> infinity: since it's not needed for alpha2 probably :0
<infinity> micahg: Kinda is.  The CDs no workie.
<micahg> infinity: the transitional package should fix that though
<infinity> micahg: Unless ubuntustudio isn't participating in A2.
<infinity> micahg: Oh, right, that's why I did livecd-rootfs to proposed.  Thanks. :P
<infinity> (brain... need... lunch)
<infinity> Anyhow, should someone accept livecd-rootfs, then cdimage/debian-cd need to be pulled in production to match.
<infinity> And vice-verse, for that matter. :P
<infinity> s/accept/copy/
<ScottK> What's the action when a package in -updates is found to have a regression (see Bug #1014570).
<ubot2> Launchpad bug 1014570 in bzr "bzr: Unable to sign commits: "no terminal at all requested"" [Unknown,Confirmed] https://launchpad.net/bugs/1014570
<ScottK> Squeeze jelmer until a fix pops out comes to mind, but I'd probably need help.
<ScottK> (nevermind the annoyance that the bug about the regression got file a week ago, but no one bothers to mention about it in any of the SRU bugs until just AFTER I copy it to updates.
<Daviey> ScottK: I don't think this situation is well described TBH.. As a user, i'd be frustrated that my workflow is regressed on the basis of fixing someone elses (i generally don't use an agent.)
<ScottK> Daviey: I agree.
<Daviey> ~2 more hours on powerpc linux build
<balloons> so confirmed respins of everything occurring yes? Can we update the notice board when it occurs please?
<Daviey> balloons: sorry, notice board?
<Riddell> Daviey: any kubuntu images on their way?
<Daviey> Riddell: kernel still not ready, so no
<Daviey> :(
<Riddell> righty ho
<Riddell> but you don't get to go to sleep until it is ready to go :)
<balloons> Daviey, sorry.. Yes, the notice board is on the isotracker
<cjwatson> infinity: I made a crontab change to cdimage, but just deployed it live since you said you didn't want the lowlatency fix rolled out yet
<cjwatson> but it's in bzr too
<cjwatson> (fixing precise livefses to build with -proposed, which I forgot when I made the other -proposed changes to precise earlier)
<infinity> cjwatson: Mmkay.
<infinity> cjwatson: When the kernel's ready to copy, I'll pick up the studio bits as well, and pull cdimage and debian-cd to match.
<slangasek> why does launchpad show a delta from 0.156.14.2 to 0.156.14.6 for update-manager, instead of from .14.5?  Is it because the latter versions were not yet published to -updates when .6 was uploaded to the queue?
<RAOF> slangasek: It's because .14.5 is in -security; that's the diff from what's currently in -updates
<slangasek> no, .5 is also in -updates
<infinity> slangasek: It's a diff from what was last in -proposed.
<slangasek> ok
<RAOF> That's what I meant :)
<infinity> slangasek: Known bug.
<slangasek> right-o
<infinity> slangasek: And stupidly annoying. :/
<Daviey> infinity: Are you pushing a d-i no-change?
<infinity> Daviey: No-change?  It's an ABI bump.
<infinity> Daviey: But yes, I'm doing a new d-i after I copy the kernel.
<Daviey> cjwatson: Why did you change livefses to build from proposed ?  Doesn't that make the landscape identical to release pocket?
<Daviey> Ie, inconsistent binaries across arches?
<Daviey> infinity: Okay, once that is published, do you want to kick off cd builds.. meaning i can go to bed? :)
<infinity> Daviey: For point-releases, we start with proposed, and move to updates as we get closer to release day.
<Daviey> infinity: Ah!  My bad, i thought cjwatson was talking about Quantal
<Daviey> I now see he mentioned precise.
<cjwatson> Correct.
<Daviey> slangasek: I think that was a bug i raised some time ago... bug 680911?
<ubot2> Launchpad bug 680911 in launchpad "Diff generation in the proposed pocket should consider the updates pocket even when there are previous proposed publications." [Low,Triaged] https://launchpad.net/bugs/680911
<slangasek> ah, so :)
<infinity> Turns out that syncpackage has the same bug.
<slangasek> right
<Daviey> I almost wet myself when i saw a diff of something i uploaded.. 1 line change turned into 100's :)
<cjwatson> May not be in the same place in syncpackage.  For uploads, try lib/lp/archiveuploader/nascentupload.py:NascentUpload.getSourceAncestry.
<cjwatson> I think.
<Daviey> infinity: To confirm, you are copying linux to release pocket, handling a d-i upload, then triggering respins?
<infinity> Daviey: Certainly the first two, but sure, I can do the latter as well.
<cjwatson> And yeah, as Julian says, there's a smarter pocket->list(pocket) map in lp.soyuz.adapters.archivedependencies
<infinity> cjwatson: Sorry, I meant the same misfeature, not necessarily the same bug.
<Daviey> infinity: Well, if you are happy to, it unblocks me on slumber.
<infinity> Daviey: Given that you're old enough to be in danger of wetting yourself while reading diffs, you probably need your sleep.
<cjwatson> There's a near-parallel in lp.soyuz.model.queue.
<cjwatson> Which *might* be what syncpackage ends up caring about; I haven't tracked all that down.
<Daviey> infinity: this beauty doesn't maintain itself.
<xnox> so we are still waiting for kernel.... me wants to test raid.... oh well. Will it be ready for European breakfast time?
<infinity> Daviey: It certainly appears not to, no.
<infinity> Daviey: Err, I mean.
<infinity> Daviey: Go sleep.
<Daviey> xnox: If all goes well, yes.
<xnox> Daviey: ok. I will go sleep then.
<Daviey> nn all
<Daviey> (thanks infinity)
<xnox> Daviey: good night =) me off as well
<infinity> cjwatson: Was the new ubiquity targetted at A2?
<infinity> cjwatson: Ahh, I see Oli mentioning he needs it for the ARM bits.  Grabbing that with the kernels, then.
#ubuntu-release 2012-06-27
<cjwatson> Yeah
<cjwatson> Are you doing d-i then?  I should probably make lunchboxes for tomorrow.
<infinity> cjwatson: I am.  Go do family stuff, crazy man.
 * infinity looks sideways at the seeds that still say 3.4.0-5
<infinity> ... because typing 'bzr up' is hard.
<infinity> Evidently, my seed fetching cronjob failed.
 * skaet back
<infinity> skaet: I pulled the studio fixes in from -proposed with the kernel.
<infinity> skaet: (It's all publishing right now, and then I'll upload d-i)
<skaet> infinity, thanks for the update.   was just working through the back scroll and wondering
<skaet> :)
<cjwatson> I suggest uploading d-i directly to quantal
<cjwatson> Otherwise you'll have to mess about copying files around by hand (for the last time ever)
<skaet> +1
<infinity> cjwatson: That was the plan.
<infinity> cjwatson: Hence why I'm waiting for the proposed->updates publishing run.
<cjwatson> Oh, I wonder if d-i needs munging for -updates still
<infinity> Err, proposed->release.
<infinity> La la la.
<cjwatson> Ah yes
<cjwatson> In that case that does make things simpler
<cjwatson> Otherwise you have to hack about with "USE_UDEBS_FROM_EXTRA ?= quantal-updates" or something
<infinity> Yeah.  We'll end up making that the default (well, s/updates/proposed/) in devel releases soon enough anyway.
<infinity> But not today.
<infinity> cjwatson: So, cute side-effect of doing a development in proposed and then moving things in batches.  The publisher sure is fast when it only has to touch leaf pockets.
<infinity> (I saw it finish around :15, and thought it had wrapped around, until I realised it was just that nothing had been published to -release in that round)
<cjwatson> Hah, yeah
<skaet> hmm... just checked crontab and it was still on,  ... fixed it now to be commented out.
<cjwatson> No, it was fine.
<cjwatson> It doesn't need to be changed in bzr.
<cjwatson> It was commented out in the live version.
<skaet> it wasn't comment out in live version - just checked, and then did it.
<cjwatson> Yes it was.
<skaet> *blink*
<infinity> skaet: The actual crontab was.  etc/crontab doesn't mean anything.
<cjwatson> Youo changed cetc/crontab, which isn't the lilve version.  The live version is printed by 'crontab -l'.
<infinity> (Except as a reference for what should be in crontab -l)
<cjwatson> (Sorry, lag)
<cjwatson> I checked earlier for something else.
<skaet> infinity, cjwatson,  crontab -l showed that it wasn't commented.   I did crontab -e and added comments to quantal bits.
 * skaet figures something weird is going on.
<cjwatson> I'm sorry, but you must have checked wrongly; I checked crontab -l literally 30 minutes ago.
<highvoltage> hi skaet
<cjwatson> (When I was doing PROPOSED=1 for precise builds)
<cjwatson> Well, maybe more like two hours ago, looking at it
<cjwatson> Anyway, whatever.  It's commented out everywhere it can plausibly be commented out now ;-)
<skaet> cjwatson, as long as its commented now, that's the main thing.
<skaet> highvoltage,  up late?
<highvoltage> skaet: well it's 21:17 here :)
<highvoltage> skaet: I was just wondering... as release manager, do you have the super powers to just create 2 weeks and insert it right here?
<highvoltage> skaet: like, today is the 26th of July, then there's a magic two weeks to do stuff in, and then it's 27th June?
<skaet> highvoltage,  :)  ok,  had you pegged in wrong time zone.   sorry.   and no I don't have the ability to create a time bubble and add it to the schedule (I wish!)
<skaet> :)
<highvoltage> aw :)
<cjwatson> Actually I'm very sorry, you're quite right
<cjwatson> I just looked back through my screen history and I was reading a diff backwards - it was indeed only commented in etc/crontab, not the live version
<cjwatson> skaet: So my apologies, I should have double-checked first before saying you were wrong
<skaet> cjwatson, no worries.   Thanks.
<cjwatson> (And my Internet went down at just the time I was trying to say that; obviously cursed)
<cjwatson> Would anyone care if I renamed some of the *.py scripts in ubuntu-archive-tools to names without *.py?
<cjwatson> I'll be careful about backreferences from the wiki and other scripts and suchlike, of course
<cjwatson> And I'll probably reluctantly leave edit_acl.py alone because other folks are used to it
<infinity> Kicking off preinstalled and live.  alternates waiting on d-i to be done building.
<infinity> cjwatson: Please ditch all the .pys, please and thankyou.
<cjwatson> s'what I thought.
<infinity> cjwatson: And if edit_acl.py has become an interface people script to, symlink it? :P
<infinity> (Though that breaks adding a space after tab completion..)
<cjwatson> Thought about it but don't really want to clutter the directory further
<infinity> cjwatson: Oh, before I start the desktop/DVD run (oh hi, cron, still having one in the pipe...)
<infinity> cjwatson: Do we still have any hybrids (ie: do I need to wait for d-i before I do those), or are they all live-only now?
<skaet> infinity, yeah.
<skaet> infinity,  was going to do the image kicking, but if you've got it covered,  thanks.
<cjwatson> I think they're all one or the other, but I also think that desktop images actually pick up their kernel from the d-i output still
<cjwatson> So it's best to wait
<skaet> infinity,  when I was cross checking https://launchpad.net/ubuntu/+source/initramfs-tools/0.103ubuntu0.1 - looks like no powerpc - expected?
<infinity> And am I blind, or is ubuntustudio not in the magical pipe?
<cjwatson> powerpc got a bit clogged earlier due to gcc-snapshot
<infinity> Yeah, I killed that snapshot build. :/
<skaet> infinity,  it needs to be added.
<infinity> skaet: No, not entirely expected, scored it up.
<skaet> it wasn't in A1,  so guess it got missed in the cross check earlier.
<skaet> s/it/ubuntu studio/
<cjwatson> Actually, screw it, I will rename edit_acl.py (to edit-acl) and symlink.  I'm sure people will get used to it.
<infinity> cjwatson: I'm used to it already.
<skaet> infinity,  save the logs with start and end timings for me please,  and paste bin the info.
<infinity> skaet: Sure.
<skaet> Thanks! :)
<infinity> cjwatson: Oh, hrm.  When you disabled powerpc all over, was that because royal was down, or broken somehow?
 * infinity just realised that it's still disabled, and royal seems up.
<cjwatson> It was down.
<infinity> Kay.  Looks alive now.
<infinity> Will revert that commit.
<cjwatson> I mean, it was also just hanging, but IS told me it would be down until it was recovered.
<cjwatson> Sounds sensible, thanks.  We can put it back if it hangs again.
<infinity> Well, maybe I'll do a quick test with core first, if there's a danger of it being sad.
<cjwatson> Worth checking.
<infinity> Except that powerpc doesn't normally build core.  Whatever.  It gets one today.
<infinity> (I still thikn it should be added anyway)
<skaet> infinity,  have added ubuntustudio to the pad,  please cross check and fix if needed. ;)
<micahg> I need unity-2d in the same publisher run or before the other 3 ^^^
<micahg> RAOF: can you let these out ^^
<RAOF> micahg: Sure. Is that a source+binary sync, or just a source sync; should I accept unity-2d first and wait for it to publish?
<infinity> RAOF: All together.
<infinity> RAOF: So, start at :04 ;)
<infinity> (or do it all right now)
<RAOF> Or let you flick the switch, as you're a real AA? :)
<infinity> RAOF: And they're source+binaries.
<infinity> Sure.
<RAOF> (And knows things like when the publisher actually runs and such)
<infinity> Oh, it's just accepting syncs, you can do that fairly atomicly. :P
<infinity> micahg: ^-- Should hitch a ride on a 4:03 train our of London.
<infinity> s/our/out/
<cjwatson> Hmm, ubiquity failed autopkgtest
<micahg> infinity: much thanks
<micahg> my notifications failed apparently
<infinity> cjwatson: And in code that was recently changed, no less.
<infinity> cjwatson: (Is it wrong to be shocked by a testsuite that appears to actually trip on introduced bugs?)
<cjwatson> Mm, not changed since 2.11.5 though
<cjwatson> I'm suspicious, doesn't seem to correspond to an obvious code bug; will need to reproduce locally I guess, or hope somebody else does it first :)
<skaet> infinity,  Hmm,  looks like the powerpc builds for core & ubuntu are failing.  "The following packages have unmet dependencies: evolution-data-server : Breaks: libebook-1.2-12 (< 3.4) but 3.2.3-0ubuntu7 is to be installed. "
<infinity> core wouldn't fail that way.
<infinity> (core failed earlier on initramfs-tools but was fine later)
<infinity> But if e-d-s is out of date on PPC, lame.
<infinity> It shouldn't be..
<jbicha> well, thunderbird (thunderbird-gnome-support) hasn't built in a while on PPC
<infinity> jbicha: Oh, right.  Yeah.
<jbicha> but armel has that same problem
<infinity> So, any desktop that includes tbird will be toast.
<infinity> jbicha: We don't build armel images.
<jbicha> oh
<infinity> skaet: Yeah, known issue, not going to worry about it.
<skaet> infinity,  ok.
<skaet> release note time.
<micahg> hrm, I'll talk to chrisccoulson about thunderbird, I thought we got a patch from BenC
<infinity> If we have a product that doesn't ship thunderbird, and does build PPC, that one will work. :P
<infinity> micahg: Yeah, I'm looking for the round tuits to fix armel.
<infinity> micahg: PPC looked more involved, though.  So, if Ben found the time, yay.
<micahg> jbicha: tell upstream to make their libraries properly co-installable :P
<skaet> infinity,  have the buildlive's  started off?  not spotting them in ps aux, but there seems to be a fair bit of stuff in flight, so may be missing them.
<infinity> skaet: It's all running.
<skaet> infinity,  coolio.  Thanks
<infinity> skaet: Or, was, until the alternates all finished.
<skaet> :)
<infinity> skaet: ps ax | grep buildlive
<infinity> Reading four screens of crap is not worth the effort.
<micahg> infinity: hrm, bug no haz patch for PPC :(
<infinity> micahg: I just honestly don't understand how and why upstream willfully breaks it with every release.
<infinity> micahg: I mean, they're getting patches fed to them from porters.  And stuff works.  And then I see, in the next release. "This isn't ported to your platform, lolz."
<infinity> Like, really?  What?
<micahg> infinity: well, it wasn't properly fixed until 15 IIRC
<jbicha> micahg: http://packages.qa.debian.org/e/evolution-data-server/news/20120619T171733Z.html
<jbicha> I don't understand their reasoning
<infinity> micahg: AIUI, the e-d-s and libe* problem is that the libraries need to talk to the server, and the server can only exist in one version.
<skaet> infinity, yeah, but since armhf is buildlive'ing now it wasn't conclusive.  ps aux | grep BuildLiveCD
<micahg> infinity: right, well, that can go back to what we were talking about in -devel before...
<infinity> micahg: So, while one could make the libraries coinstallable (they're properly SOVERed and all), there's no point, cause either the old or new would be broken.
<micahg> infinity: they don't have to break their client -> server interface every release
<infinity> micahg: But they have so much fun doing it.
<skaet> however, if you say you've started it,  that's conclusive.  :)
<micahg> as much fun as webkitgtk has revving glib deps
<infinity> micahg: Besides, this is from the people who brought you such stellar thinking as "hey, I bet copying the Outlook UI would be a really efficient way to not have users".
<infinity> micahg: And they were right.
<infinity> (Then again, Thunderbird's UI is a copy of the Exchange4/5 client, pre-Outlook, but hey, that one wasn't cluttered unusable mess...)
<infinity> s/wasn't/wasn't a/
<skaet> ok,  will clean up the specifics (20120627 vs 20120627.1) tomorrow on the upgrades, but they're on the tracker now at least
<skaet> infinity,  I can't think of anything else to double check, and since you've got the images a going,  I'll head to zzz now.   Thanks for your help this evening.
 * skaet --> zzz
<jbicha> infinity: do you want to promote libgxps now? I've uploaded a new evince that depends on it
<micahg> jbicha: robert_ancell just blew away your upload
<jbicha> oh, that's pretty cool
<micahg> jbicha: either you didn't push before upload or he overwrote it in bzr
<jbicha> the first, but it should be better now
<infinity> jbicha: Will do.
<jibel> wubi images have not been rebuilt to include the new kernel ?
 * Daviey checks in
<Riddell> could I get some more recent kubuntu arm images spun up?
<ogra_> Riddell, we switched ubuntu to live images, do you want live instead of preinstalled as well ?
<Riddell> ogra_: hum interesting
<Riddell> ogra_: why the change?
<ogra_> Riddell, to default to USB disk installs
<Riddell> ogra_: isn't that what it always was?
<ogra_> the preinstalled images, while awesome in the install process (unlkess you run into HW probs like you did) are simply having a horrid I/O
<ogra_> they dont really reflect the potential of an ubuntu desktop on the panda
<Riddell> ogra_: so what's the difference to the user?  you have to run a ubiquity install now?
<ogra_> Riddell, right, and it defaults to install to a USB disk
<ogra_> (you still need the SD as "bootfloppy", but it boots and runs a lot faster due to the better I/O on USB)
<Riddell> interesting
<Riddell> ogra_: well yes I think we want that for kubuntu too
<Riddell> any idea how we go about it?
<ogra_> Riddell, changing etc/default-arches in debian-cd on nusakan should suffice
<Riddell> mm, a machine I don't have access to
<ogra_> you are in cdimage, no ?
<Riddell> no
<ogra_> oh, i thought you were
<Riddell> ogra_: can you do it?
<ogra_> Riddell, yes, looking into it
<Daviey> cjwatson: slangasek seems to be the contact for Ubuntu Core.. Do you know who is tasked to work on it?
<cjwatson> Daviey: Generally infinity
<cjwatson> Daviey: But Ubuntu Core is basically just a tarball of the base system; it requires almost no specific work of its own
<Daviey> cjwatson: Gah, it's been broken for the last week.
<cjwatson> ?
<cjwatson> Ref?
<Daviey> https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-core-armhf/17/console
<cjwatson> So that looks like a jenkins bug to me; I wonder where I can find the script it's running
<cjwatson> W: Failed to fetch http://ports.ubuntu.com/ubuntu-ports/dists/quantal/Release  Unable to find expected entry 'main/binary---add-architecture'/Packages' in Release file (Wrong sources.list entry or malformed file)
<cjwatson> suspicious
<cjwatson> I bet it needs updating for new dpkg world
<Daviey> Ah.. might be https://launchpad.net/bugs/1017862
<ubot2> Ubuntu bug 1017862 in lxc "Migrate to dpkg --add-architecture to track foreign architecture in template lxc-ubuntu" [Undecided,Fix committed]
<Daviey> cjwatson: http://bazaar.launchpad.net/~ubuntu-server-iso-testing-dev/+junk/ubuntu-core/changes
<Daviey> jibel: You are tracking this issue, i assume?  Based on your last commit?
<Daviey> jibel: if so, can you retest based on your change being after the last failed job?
<cjwatson> Seems like a possibility, at least
<jibel> Daviey, it was introduced by the change in dpkg 1.16.2 and the new option --add-architecture
<jibel> I fixed it, but the result is not published obviously
<Daviey> jibel: can you not make jenkins retest it?
<ogra_> cjwatson, a quick review ? http://paste.ubuntu.com/1062293/ (switching kubuntu to live)
<Daviey> jibel: It would be good to check your change gives a green light, before investigating why we don't have a newer core image.
<jibel> Daviey, the test ran and is green but for some reason, it doesn't publish results to the public instance. I retried a publication, it says it's ok but the results are still not there
<jibel> Daviey, I must wait for the US to wake up, I don't have access to the public jenkins
<Daviey> jibel: how odd.. ok, if it's green on the backend jenkins, i am happy ;)
<Daviey> thanks jibel
<jibel> Daviey, https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-core-armhf_default/
<Daviey> jibel: ah, someone appended _default ?
<Daviey> jibel: Do you have ACL to hide the old one, the red dot will cause confusion
<cjwatson> ogra_: please sort architectures, and we need to keep the old kubuntu line as "maverick-precise"
<jibel> Daviey, yes, I filed an RT and asked for removal
<ogra_> oops, sorting, sorry
<cjwatson> ogra_: Otherwise that's OK
<cjwatson> Daviey: that seems kind of backwards, we need a current image to feed into jenkins surely?
<Daviey> cjwatson: Yes.. we seemed to think it was a testing issue, rather than an image issue, right?
<cjwatson> Anyhow, http://cdimage.ubuntu.com/ubuntu-core/daily/current/ all looks up to date to me
<cjwatson> Right, I was just confused by:  10:58 <Daviey> jibel: It would be good to check your change gives a green light, before investigating why we don't have a newer core image.
<Daviey> Which means, that re-testing the old image, should make it turn greem
<Daviey> green*
<Daviey> seems reasonable to re-test the old image to validate that theory
<Daviey> cjwatson: And the reason there wasn't a newer image in jenkins, is because ()just discovered) that _default was appended to the name
<cjwatson> *shrug* If you like.  Foundations isn't terribly bothered about any of this on the grounds that if anything else at all works then Ubuntu Core clearly works.
<Daviey> so it caused a new entry in jenkins.
<cjwatson> The jenkins stuff in question seems to be exercising multiarch more than specifically core, which is a good thing to do
<cjwatson> old image> how old?
<Daviey> https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-core-armhf/ .. renamed to https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-core-armhf_default/?
<Daviey> And that tested the most current image on cdimage.
<ogra_> Riddell, done ...
<cjwatson> I guess I don't understand why to retest - isn't quantal-core-armhf_default a current test, then?
<Riddell> ogra_: thanks!
<ogra_> someone should trigger a build for kubuntu now :)
<ogra_> (arm only livbe that is)
<ogra_> *live
<Riddell> yes please
<ogra_> (someone from the release team if possible :) )
<Daviey> cjwatson: I didn't know _default was the new test.. So i saw failure on the original.. Now the world is good, pending jibel's RT to get the orginal test noise removed.
<cjwatson> Daviey: righto, cool
<cjwatson> ogra_: Daviey's doing releng this release so ideally him.  It'll have to wait for the current precise build to finish though
<Daviey> sure
<ogra_> oh, there is an arm build going on ?
<ogra_> (note thats an arm only build kubuntu needs)
<cjwatson> precise builds are still cronned
<ogra_> ah, k
<Daviey> cjwatson: it's not locksafe?
<cjwatson> it is, but it will queue
<Daviey> right
<Daviey> So i won't cause damage if i trigger it now?
<cjwatson> you only get one livefs build per backend builder at any given time
<cjwatson> no
<Daviey> groovy.
<cjwatson> use ARCHES= to build only for armhf+whatever
<Daviey> ogra_: Can you justify on http://pad.ubuntu.com/ubuntu-release please?
<ogra_> Daviey, does that suffice ?
<Daviey> ogra_: thanks
<xnox> is mythbuntu participating in alpha2?
 * ogra_ wonders why there are no armhf+mx5 images
<ogra_> infinity, did you miss armhf+mx5 in your ARCHES list when firing off the build ?
<ogra_> i dont see a live image for it
<ogra_> hmm, and somehow the old preinstalleds arent removed
<ogra_> there are images from the 24th for omap and omap4 in daily-preinstalled
<apw> i assume we know that the slide show still says 12.04LTS and we don't care ?
<ogra_> it also still shows a pangolin at the wallpaper
<cjwatson> apw: There isn't a specific bug that I can find, but it generally takes a while to be updated for a new release and is known.
<apw> cjwatson, we so should make fake ones for the A1/A2s with pictures contributed "Hello Mum" etc
<ogra_> we had a dancing circle of developers once
<ogra_> people didnt like it
<apw> heh ..
<xnox> apw: well you can tweet fun crap and it will show up in the feed =) e.g. yesterday it was still looping that I joined core-dev team ;-)
<xnox> apw: I thought artwork is dropped at the UI freeze
<ogra_> heh, is it really recent ?
<ogra_> i.e. could you send messages to yourself while waiting ?
<apw> xnox, still is
<xnox> ogra_: it does pull it off the internet so yeah it should be live ;-)
<ogra_> heh, cool
<cjwatson> ogra_: That was an April Fool wasn't it?
<ogra_> now i'm finally considering a twitter account ...
<cjwatson> I vaguely remember the ruckus
<ogra_> finally a proper usecase !
<ogra_> cjwatson, yeah, with elmo sabdfl and mdz iirc
<xnox> ogra_: "spending time on twitter for cd testing"
<ogra_> heh
<cjwatson> God, that was like 2005
<ogra_> yeah, when we were young and innocent :)
<cjwatson> Young, anyway
<ogra_> haha
<Daviey> xnox: mythbuntu is not doing Quantal.. it's being built, but not released
<xnox> interesting
<apw> Daviey, for A2 or ever
<Daviey> apw: Ever
<xnox> given that CD are >700MB should we start thinking about bug 947546
<ubot2> Launchpad bug 947546 in usb-creator "booting from usb-creator live usb image fails self-test boot option" [Undecided,New] https://launchpad.net/bugs/947546
<cjwatson> Mythbuntu has gone to LTS-only
<Daviey> More effort is being put into precise overlay PPA's.
<Daviey> Not that i can really comment, i don't exactly pull my weight in that project anymore.
<xnox> what package needs teaching self-test off usb-stick?
<cjwatson> Um, not sure where that is.  Somewhere between usb-creator and lp:~ubuntu-cdimage/debian-cd/ubuntu probably
<cjwatson> The self-test option is presumably in usb-creator
<apw> man ... s/w center is 2.5m of my install
<Riddell> skaet: what was that bug page you showed at the release team meeting last week?
<skaet> Riddell, do you mean: http://reports.qa.ubuntu.com/reports/rls-mgr/rls-q-tracking-bug-tasks.html?
<skaet> minutes can be found on the https://wiki.ubuntu.com/ReleaseTeam/Meeting/2012-06-22 page.
<Riddell> skaet: aye that's the one, how does a bug end up on there?
<skaet> Riddell, when its targetted to the quantal series, it shows up there.
<Riddell> ah hah
<hyperair> how does the software centre handle arch:all packages that depend upon an arch:i386 package on architectures that don't support i386?
<hyperair> oops, wrong channel
<skaet> Riddell, those without access to accepting series, should use the "rls-q-incoming" tag to flag to the team's attention.
<ogra_> could someone fix the tracker to not point to preinstaleld arm images anymore ?
<ogra_> *preinstalled
<jibel> skaet, we need a new product on the tracker to track arm live
<skaet> jibel,  so it appears.
<skaet> ogra_ path to new images?
 * skaet figures ogra_ gets to write a nice long paragraph in the Technical Overview on this ;)
<ogra_> http://cdimage.ubuntu.com/daily-live/20120627/quantal-desktop-armhf+omap.img
<ogra_> etc
<ogra_> for omap, omap4 and mx5 please
<ogra_> ac100 stays preinstalled
<ogra_> skaet, yeah, planning to, still busy fiddling with the tests atm :)
<skaet> :)
<ogra_> note that this is currently only for desktop, server stays as is until the squashfs stuff is in x86 server
<skaet> ogra_ do you have the new test cases that need to go along with the arm live images?
<ogra_> nope
<ogra_> there are no arm specific tests to do
<ogra_> thats the purpose of switching to live image
<ogra_> (or one of them)
<ogra_> all general putrpose tests we do on x86 apply now
<ogra_> *purpose
<pgraner> skaet, ogra_:  I'll migrate the x86 tests over to arm and validate them this AM
<ogra_> pgraner, awesome !
 * pgraner digs out panda boards
<ogra_> note that there is a kernel issue ... works atm only on selected monitors
<ogra_> (now dont ask which ones :P ppsati seems the only person with fully working output)
<pgraner> ogra_, oh sweet
<ogra_> bug 1010009 has some info
<ubot2> Launchpad bug 1010009 in linux-ti-omap4 "omapdss fails to properly detect some monitors in quantal" [High,New] https://launchpad.net/bugs/1010009
<pgraner> ogra_, I've got 4 different brands/makes of hdmi monitors so hopefully one will work
<ogra_> (and workarounds that work for me but i.e. not for apw)
<apw> ogra_, remember i am testing the _wrong_ image cause the iso tracker tells you to test the wrong image, i'll repro with the right one
<apw> (once it has downloaded, yawn)
<ogra_> apw, i dont think the kernel changed between the two
<apw> ogra_, no i am sure the testing will end up with the same result, but its not valid to infer it sadly
<ogra_> right, just test it
<apw> ETA 3:04
 * stgraber grabs Edubuntu
 * highvoltage too
<skaet> Daviey,  can you update the iso tracker to remove those server images you don't want tested please.
<Riddell> alternate images are broken for me, they just show a blank screen after "loading additional components"
<cjwatson> Riddell: I'll have a look once they've downloaded
<cjwatson> Riddell: Kubuntu or Ubuntu?
<Riddell> cjwatson: both
<cjwatson> OK, I'll use Ubuntu since that'll be quicker for me to update
<highvoltage> stgraber: do we want an ARM alpha2 or are we going to keep that for alpha3?
<stgraber> highvoltage: no arm for a2, as I said, I don't want people to think we'll release for omap4
<highvoltage> ok
<Daviey> skaet: hmm, well.. Ubuntu Server amd64+mac .. has never been a release deliverable, but has always been there.
<Daviey> Should that go?
<skaet> Daviey,  if there isn't someone prepared to test it, yes
<Daviey> skaet: is having an empty entry worse than a disabled target?
<Daviey> I mean, if someone happens to test it, would be nice to have somewhere to capture it?
<skaet> Daviey,  "if someone" is not a plan.   Was it tested on any of the dailies or prior images?
<Daviey> skaet: I'm just stating that Canonical Server team will not be testing them, but i don't know what opportunistic testers will do.
<skaet> balloons, ^ is there anyone planning on testing the Ubuntu Server amd64+mac images that you're aware of?
<Daviey> skaet: James Page put out a call for testing this morning.. https://lists.ubuntu.com/archives/ubuntu-server/2012-June/006340.html
<Daviey> ogra_: Preinstalled armhf+ac100 .. is correct.. right?
<ogra_> Daviey, yep
<ogra_> looks perfect apart from missing mx5
<Daviey> ogra_: i've not got a cmd prompt back yet.. so it is probably still on the way
<ogra_> yep
<ogra_> its not a big loss to not have it though
<ogra_> we only have two people in the company with that HW and i dont know any community testers
<cjwatson> Riddell: Can't reproduce with Ubuntu alternate i386
<Riddell> drat
<cjwatson> Riddell: Was your test on i386?
<cjwatson> Riddell: And can you switch to tty4 and have a look at syslog there?
<cjwatson> (or tty2 for a shell)
<Riddell> yep
<cjwatson> Owt interesting?
<highvoltage> is there a bug open for the ubiquity radio boxes that look like tickboxes?
<highvoltage> (I'm adding it to the == Boot, installation and post-install == section)
<cjwatson> It's not ubiquity-specific; it came up on #-devel a few days ago
<cjwatson> I believe mpt said it'd take a couple of weeks to sort out
<stgraber> highvoltage: IIRC you're actually the one who started that discussion in #-devel a few days ago ;) mpt said it was a gtk3 bug/feature that broke it
<xnox> upstream made certain theming options private, which broke the theme. the workaround was applied to not use now hidden properties, but the real fix of bringing the theme back to normal is work in progress
<highvoltage> stgraber: yeah I remember, I understood that it was a css/gtk bug that only affects ubiquity... (at least as far as we can typically see in Ubuntu), but I'll test it in apps in an installed system as well on todays image
<highvoltage> stgraber: I just think it's worth mentioning that it's a bug, before people get enraged at a design team :)
<ogra_> pgraner, thnaks for the test cases on omap4, can we drop "live session" from the list ? we boot with only-ubiquity on the cmdline on these images so we go stright into the installer
<ogra_> geez, need to work on my typing today
<pgraner> ogra_, sure, I'm woking my way thru them now, I have to add bits and links on "how to boot"
<Riddell> cjwatson: tty4 says "ext3-fs (sda1) error: couldn't mount because of unsupported optional features (240)" followed by "ext4-fs (sda1): mounted filesystem with ordered data mode"
<Riddell> otherwise nothing unusual
<cjwatson> Doesn't seem related, unless you're booting off ext3/4
<cjwatson> (the installer that is)
<pgraner> ogra_, ok, no working monitors... I'm dead in the water atm
<ogra_> did you try one of the workarounds i mentioned on the bug ?
<balloons> skaet, amd64+mac server hmm.. no, not to my knowledge. That's a hard one to get, since mac testing is already so notorious
<balloons> I'll mention it
<Daviey> balloons: did you see the mail from James you were CC'd on.
<balloons> Daviey, yes I did
<Daviey> balloons: amd64+mac isn't a deliverable image.. but i'm hesitant to suggest it's removed from the tracker, as it's perfectly valid for people to want to test it and report failure.
<skaet> balloons, Daviey:    if no test results (or indications someone wants to test it),  I'll prune it from the list at 2100
<skaet> UTC
<balloons> Daviey, ahh.. It was a curveball to see it there
<Daviey> The benefit to removing it is that it creates 'less noise'.. and gives the ability to brag higher report coverage if it's removed.
<balloons> right, amd64 is the ONLY server image
 * skaet is quite willing to remove it earlier
<Riddell> cjwatson: install proceeding fine on my other machine
<Daviey> skaet: why so keen to remove it?
<Daviey> Why hasn't this been an issue in prior releases?
<infinity> ogra_: I didn't use ARCHES when building, so mx5 should have been included.
<infinity> ogra_: ubuntu-armhf-mx5 on celbalrai.buildd finished at 2012-06-27 04:48:35 (success)
<skaet> Daviey, this cycle the push is to reduce the images down to those most useful.   Trying to get focus of people willing to help test on the ones that will be most beneficial from bigger picture, and find the gaps that are important.
<ogra_> infinity, strange, i dont see it in daily-live
<infinity> ogra_: Hrm.  Curious.
<infinity> ogra_: Not awake enough yet to be REALLY curious.
<ogra_> the others are there
<ogra_> well, no hurry i guess
<ogra_> its just mx5
 * ogra_ is more eager to get the omaps working 
<balloons> skaet, Daviey yes I agree.. It's hard to ask someone to test something we have no plans on using
<ogra_> omap3 gives me a hard time atm
<ogra_> squashfs errors all over the place
 * ogra_ tries another SD
<infinity> ogra_: I'd help test, but I think booting a live session on my beagle will end in someone getting hurt.
 * infinity grumbles about 256M of RAM.
<ogra_> heh, well, i'm trying my other microSD now
<ogra_> get an XM !
<infinity> Those cost money!
<infinity> Would cut into my precious beer and shawarma budget.
<ogra_> heh
<ogra_> ask your manager !
<infinity> He's the one who gave me the crappy beagle. ;)
<ogra_> heh
<smoser> hi.. stgraber or anyone able to populate iso.qa.ubuntu.co tracker for alpha-2 cloud images ?
<smoser> from https://cloud-images.ubuntu.com/quantal/20120627/
<smoser> https://cloud-images.ubuntu.com/quantal/20120627/published-ec2-daily.txt
<stgraber> smoser: I can do that
<stgraber> thanks for linking the .txt, I usually have to spend a few extra seconds finding it ;)
<stgraber> running
<Riddell> who's on duty now?  Daviey? infinity?
<Riddell> two issues
<Riddell> [8]...https://launchpad.net/bugs/1018448 meta-kde-telepathy not installing needs kubuntu alternates respun
<ubot2> Ubuntu bug 1018448 in meta-kde-telepathy "0.4.0ubuntu2 can not install" [Undecided,Fix released]
<Riddell> [9] arm kubuntu live not existing, alternates made instead?
<skaet> Daviey, ^
 * ogra_ thinks these builds are still running 
<ogra_> Daviey gave me his cmdline and apparently that starts with an alternated buiold fo all arm images, sorry, i only saw that now
<ogra_> *alternate
<ogra_> ARCHES='armhf+ac100 armhf+mx5 armhf+omap armhf+omap4' for-project kubuntu cron.daily; ARCHES='armhf+ac100 armhf+mx5 armhf+omap armhf+omap4' buildlive kubuntu daily-live && ARCHES='armhf+ac100 armhf+mx5 armhf+omap armhf+omap4' for-project kubuntu cron.daily-live
<Riddell> mm yeah that could explain it
<ogra_> that should only have been: ARCHES='armhf+omap armhf+omap4' buildlive kubuntu daily-live && ARCHES='armhf+omap armhf+omap4'  for-project kubuntu cron.daily-live
<ogra_> so it might take several more hours
<ogra_> (one livefs build per subarch, 90min per build)
<ogra_> (serialized since we are waiting for buildd HW)
<ogra_> (i guess that measn the buildds are busy for another 6h or so)
<infinity> Speaking of...
<infinity> pgraner: Do you know what happened to that Mandabox that was meant to land in the DC and do magical things for me?
<pgraner> infinity, its with elmo
<ogra_> tell him to not take it out for shopping all the time then :)
<infinity> pgraner: Kay.  Is there a ticket for it that I can hound and/or add notes to?
<pgraner> infinity, no he was just supposed to "do it"
<pgraner> elmo, sup with the Mandabox?
<pgraner> ogra_, live test case removed
<ogra_> pgraner, thx !
<Daviey> Riddell: hey
<Riddell> Daviey: arm images in progress says ogra, but new alternates needed for kubuntu
<Daviey> ok
<ogra_> well, i was guessing they still build for the next few hours
<Daviey> ogra_: it is still in progress, yes
<ogra_> right
<Daviey> Hmm.. alt should be included as part of that, no?
<ogra_> yes, your call did build them before
<ogra_> for all arm arches ...
<ogra_> not that we support this though
<infinity> Daviey: We don't build ARM alternates.
<ogra_> infinity, we just did :P
<infinity> Daviey: Well, you do, apparently.
<Daviey> I like options.
<ogra_> sigh, live install on a beagle isnt fun
<infinity> ogra_: I think this move to live is probably also the sane time to discuss dropping beagle images and just keeping the d-i netbootish option for omap.
<ogra_> yeah, probably
<infinity> ogra_: I'd like to do the same for mx5, except that the mx5 kernel is in universe.  And wouldn't have a hope of being in main.
<ogra_> currently the omap image is the only one fully working though
<infinity> ogra_: Sure, but we'll fix omap4.
<ogra_> panda has the display issue, mx5 is nonexisting
<infinity> ogra_: I honestly want to cut things down so we only have one ARM desktop image as a shiny tech show-off.
<ogra_> and i didnt get around to even remotely think about testing ac100 yet
<infinity> ogra_: (Though, two images, since there's no sane way to do d-i on an ac100, but let's just pretend ac100 doesn't factor into this)
<ogra_> yeah, though for mx5 you probably want to keep preinstalled
<infinity> ogra_: Why?
<ogra_> because you cant build d-i
<ogra_> or would you want to drop it ?
<infinity> ogra_: Oh, sure.  Yeah, I mentioned the "if the kernel wasn't in universe" problem for mx5. :/
<ogra_> right, so lets keep ac100 and mx5 preinstalled
<infinity> ogra_: It might be time to sort out how to do a d-i-universe build (y'know, before archive reorg fixes all this).
<ogra_> mx5 probably just server
<ogra_> and omap just d-i
<infinity> ogra_: Cause scaling d-i netboot images to N targets is so much saner than doing a desktop image for lots.
<ogra_> though i would expect more community images soon
<infinity> ogra_: Sure, but I bet most community hacker types would be more than happy with d-i.
<ogra_> there are a ton of allwinner A10 devices swamping the market recently
<infinity> ogra_: They seem to be in the Debian world.
<ogra_> i doubt the edubuntu guys would like a d-i install for the upcoming edubuntu tablet
<ogra_> and i think especially comminuty images are rather for endusers than devs
<cjwatson> As we discussed the last time this came up, there's nothing aside from policy preventing d-i from building against universe, and either having the ac100 kernel artificially in main or building a d-i ac100 target against universe is better than duplicating the d-i build system
<ogra_> s/ac100/mx5/
<cjwatson> or s/ac100/mx5/ or whatever
<ogra_> :)
<infinity> cjwatson: Oh, I suppose given that it's not using the host's sources.list (except to magically determine the mirror to use), we could build universe-depending images easily enough, sure.
<infinity> cjwatson: And I think that's probably the way forward for all these unsupported community boards.
<infinity> d-i images take very little time, space, or effort to test.
<infinity> live desktop images for every weird board don't scale at all.
<Riddell> cjwatson: kubuntu problems, the ubiquity "try/install" screen doesn't show up and it just goes straight to a full desktop, also the oem-config tool doesn't run, could this be realated to adding lightdm to the images?
<cjwatson> Right, all it needs is for any specialised tools it needs to be in main.
<cjwatson> Riddell: No idea I'm afraid
<infinity> cjwatson: In the mx5 case, the only thing in universe is the kernel.
<cjwatson> Riddell: ubiquity's supposed to use its own display manager
<infinity> cjwatson: That will likely be true of any subarch we spin.
<cjwatson> Riddell: So I guess check whether ubiquity-dm is there and not broken somehow, maybe /var/log/installer/dm, maybe boot with --verbose to see what init thinks it's doing
<ogra_> so omap doesnt look good
<ogra_> i would appreciate if someone else could do a test install to rule out my HW
<infinity> ogra_: Right, so, in light of the above, I'm picturing: "only omap4" for any actual "images" (server, *-desktop, etc), and d-i for everything else, with the exception of also spinning an ubuntu-preinstalled for ac100, because that's the only sane way we have to install on an ac100.
<ogra_> right
<infinity> ogra_: What level of "not look good" is it?
<ogra_> well, and keep preinstalled as an option for community images
<infinity> ogra_: I'd rather not.
<ogra_> infinity, with the first three attempts i had constant squashfs errors
<infinity> ogra_: Heck, we should be able to do d-i on the ac100 too, someone just needs to figure out a sane way first.
<ogra_> after changing to my other microSD these are gone but it dies during copying ... and i get an oops and page allocation failure for ubiquity
<ogra_> and i also see kevent drop messages for eth0 in dmesg
<infinity> ogra_: Well, squash and paging errors pretty much sound like either bad media or bad hardware.
<ogra_> infinity, debian does, but its super user unfriendly
<ogra_> infinity, thats the reason i want someone else to test it too
<ogra_> but will need an XM
<infinity> ogra_: I'm not wildly concerned about user-friendly for community ports.  I dunno, maybe I'm a big jerk.  But community ports tend to be for people who like hacking and fiddling anyway.  If we wanted it to be for the mythical "Aunt Tilly", we'd have to put real QA effort behind it.
<ogra_> i will go on caring for ac100
<ogra_> and will keep preinstalled
<ogra_> *keep them
<ogra_> if you feel like also doing a d-i image, feel free, bit for ac100 i wont drop preinstalled
<infinity> Sure.  Just saying that we probably don't want to do any new preinstalled things.
<Daviey> Riddell: Are these issues things you want to drive to a fix for A2?
<ogra_> well, its likely the best for a tablet install
<Riddell> Daviey: no we'll release note them
<ogra_> or for other predefined HW
<Riddell> Daviey: won't be able to fix for A2
<ogra_> where you are bound to android partitioning etc
<infinity> ogra_: The ac100-style tarball installer may well be the best option for a tablet type thing.  Who knows.  If we ever end up supporting one.
<Daviey> Riddell: okay, so the ones coming off the press are close to being signed off for A2?
<ogra_> infinity, edubuntu will ... this cycle
<Daviey> balloons: Are you tracking anything else which is concerning for A2?
<infinity> ogra_: Though d-i would work just fine too.
<ogra_> infinity, and i think kubuntu too
<ogra_> (given the kubuntu guys work on the kernel for the edubuntu team)
<infinity> ogra_: And, in fact, one could duplicate the tarball-installer behaviour exactly (from the end-user perspective) with d-i netboot and a preseed.
<ogra_> yep, iirc that was the plan long ago
<balloons> Daviey, just messing about with a weird kernel regression.. nothing that would hold or impact alpha 2
<ogra_> we just didnt do it ...
<infinity> ogra_: Heh.  Yeah.
<ogra_> but i dont plan to do any new work on the ac100 bits beyond occasionally uploading a driver or kernel package
<infinity> ogra_: Anyhow, longterm versus shortterm and all that.  In the (very) short term, I think we should drop everything but omap4 and ac100 from our manifests and stop killing celbalrai for no good reason.
<ogra_> (and changing cmdline options if needded=
<Daviey> jamespage: you kicked off a full ec2 test, right?
<ogra_> infinity, at least until we get the mandacluster
<infinity> ogra_: In fact, I might go edit default-arches after breakfast.
<infinity> ogra_: Even with the Mandabox, I'm not sure the QA time is worth it.
<ogra_> well, keep omap for A2 ... if its really the only usable image
<ogra_> QA only looks at omap4 traditionally
<infinity> Yes, but "someone" needs to QA the others.
<ogra_> right, since tobin is gone thats usually me
<infinity> I did a lot of them for precise release.
<infinity> So, yes.  You and I. :P
<ogra_> right
<Riddell> Daviey: well lots of testing to go yet but yes
<Daviey> super.
<Riddell> ooh goody just what I wanted
 * Daviey goes afk, will be back later.
<infinity> ^-- Wrong pocket, rejecting and reuploading.
<stgraber> ^ (epoptes) is a new upstream micro release fixing a bunch of bugs and refreshing translations. All the changes are linked to bugs (though one is linked to a dupe of a fixed bug, sorry for the weirdness) but if whoever reviews it feels like we should have an MRE, I'll be happy to discuss it (and likely put my TB hat on).
<infinity> stgraber: An MRE isn't required, per se, it's just that without one, we require more rigorous review of the diff.
<infinity> stgraber: Is it actually reviewable? ;)
<stgraber> infinity: yeah, if you ignore the translations, it's very easy to review
<infinity> stgraber: Kay, then I see no reason for an MRE.
<infinity> stgraber: Micro-releases aren't de-facto "bad", just when the changeset is so enormous that no one wants to waste their time figuring out WTF it all does (I'm looking at you, Firefox)
<infinity> Well, FFox doesn't do "micro" anymore.  At least they've given up the fiction.
<infinity> s/Firefox/Libreoffice/ and the above whine stands. :P
<utlemming> skaet: ready to release Alpha-2 cloud images whenever your ready
<stgraber> ;) yeah, I think firefox/thunderbird/.. have an MRE where the M stands for Major instead of Micro ;)
<infinity> stgraber: Ffox/Tbird are more of a "head in the sand" exception.
<infinity> stgraber: I wasted months of my life backporting security fixes to mozilla codebases in the earlier days of Ubuntu before we just said "this is ridiculous".
<infinity> stgraber: Because half of their security fixes were complete rewrites of subsystems.  So, you'd have to sort out how to represent the whole mess with static functions, or backport the whole rewrite.  And die a little inside each time.
<stgraber> ;)
<skaet> utlemming, :)  good to know the images are ready, thanks.
<Daviey> utlemming: fancy validating http://iso.qa.ubuntu.com/qatracker/milestones/222/builds/17913/testcases/499/results before declaring them release ready? :)
<utlemming> Daviey: that failure in the test result is consistant with others that we've seen....I'm digging deeper just to be absolutely sure
<Daviey> utlemming: Okay, if it's either known, or expected.. can there be a bug or something to reference?
<Daviey> Even if the bug ends up being invalid, would be nice to be able track it.
<utlemming> Daviey: sure, I'll file the bug now
<Daviey> utlemming: thanks :)
<pgraner> ogra_, what the mkimage cmd line for the workaround in bug #1010009
<ubot2> Launchpad bug 1010009 in linux-ti-omap4 "omapdss fails to properly detect some monitors in quantal" [High,Confirmed] https://launchpad.net/bugs/1010009
<slangasek> ogra_: hey, so what's the display issue you mentioned on panda?  is that bug #1010009?
<ubot2> Launchpad bug 1010009 in linux-ti-omap4 "omapdss fails to properly detect some monitors in quantal" [High,Confirmed] https://launchpad.net/bugs/1010009
<pgraner> slangasek, yep thats it
<slangasek> ok
<ogra_> pgraner, mount SD to /mnt; cp /mnt/boot.scr ~/boot.script; .... drop the binary header from teh first line; make your edits; sudo mkimage -A arm -O linux -T script -n 'Ubuntu Boot Script' -d boot.script /mnt/boot.scr; unmount /mnt
<ogra_> (i think we have at least three different wikipages about this though)
<slangasek> ogra_, pgraner: I don't grok how this bug makes the omap4 image "unusable" though; surely it's still the correct testing target, even if the graphics come up at the wrong resolution by default?
<pgraner> ogra_, should have been in the bug, would really help out the testers
<ogra_> slangasek, it comes up with a non working framebuffer by default (black screen) and the workaround doesnt seem to work for everyone
<pgraner> slangasek, graphics won't come up unless you a) hack boot.scr or 2) boot wait for X to come up and hope it likes you monitor
<slangasek> ah
<ogra_> well, X was just a milestone i picked :)
<slangasek> right, ok - that's much worse than what I gleaned from the bug description, sorry
<ogra_> if you are through most of the boot process i would say
<balloons> Is missing fonts in the installer a known issue? https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1018524
<ubot2> Ubuntu bug 1018524 in ubiquity "Ubiquity installer doesn't properly display languages" [Undecided,New]
<ogra_> slangasek, well, beyond that the image is golden, its just that small wart :P
<ogra_> pgraner, yes, there wasnt much interaction on that bug at all, i was actually expecting us to have a completely new kernel from linaro for A2, else i would have worked more on it
<jibel> balloons, yes it is
<balloons> jibel, thanks.. feel free to dupe my bug :-)
<jibel> balloons, bug 1015483
<ubot2> Launchpad bug 1015483 in ubiquity "ubiquity-dm: 2 language names wrongly displayed (missing font?)" [High,New] https://launchpad.net/bugs/1015483
<pgraner> ogra_, what version of panda board are you working on?
<ogra_> pgraner, i have an ES and an older one, currently using the ES
<ogra_> (the other one is busy with testbuilds)
<ogra_> pgraner, added the above instructions to the bug
<pgraner> ogra_, the workaround is not working on two of my 4 monitors
<ogra_> well, i dont know what to say, it works on three of my monitors
<ogra_> (and we used that workaround in the past before ... on omap as well as on omap4, its not the first time we have display issues on these platforms)
<ogra_> pgraner, i use a HDMI->DVI cable plugged into the HDMI port on the panda and into DVI on the monitor
<pgraner> ogra_, trying on a A1 now
<ogra_> oh, and i verified that it all works fine with the precise kernel indeed
<pgraner> ogra_, nothing on the A1 either, and the monitors work with precise just tried and SD card with that on it :(
<ogra_> right
<ogra_> probably i'm justlucky to have this monitor
<ogra_> apw said it didnt work for him either
<ogra_> pgraner, so would you prefer to skip A2 ?
<ogra_> (which is a shame, i woked my ass off to get the live images into perfect shape, but seeing that i and paolo seem to be the only ones with usable displays i would actually vote for that)
<pgraner> ogra_, we won't get decent community testing but balloons can comment more
<ogra_> and the funny part is that paolo doesnt see it at all
<pgraner> slangasek, thoughts?
<slangasek> pgraner: what's the question?  whether to release it?
<ogra_> yes
<slangasek> I think having an image that works on some board/monitor combos is better than not having one
<ogra_> for me its good, for paolo as well, but for everyone with a non working monitor its completely unusable
<ogra_> k
<slangasek> and between now and tomorrow we can try to refine our understanding of what's actually affected, and release note it
 * ogra_ rephrased the bug title to "omapdss only works on some monitors in quantal " ;)
<pgraner> slangasek, ok I'm dumping all my info in the bug now
<slangasek> sounds good
<slangasek> I suppose I should get mine out and test it
<ogra_> slangasek, we know whats broken and we know we wont fix it
<ogra_> since we will switch to a complete new graphics stack with 3.5
<slangasek> right, it's clear that this isn't going to be fixed for A2
<ogra_> no, i mean its abandoned code we use in the current 3.4 kernel
<skaet> slangasek,  pgraner,  there's a release note in the TechnicalOverview for it now, but we can refine it as more data comes in.
<ogra_> omapdss vs omapdrm
<slangasek> so the point of release noting it is to let community folks know what's going on so they don't spin their wheels
<ogra_> right, there is a note
<slangasek> or waste time starting a test that they can predict will fail
<skaet> There is also a note pointing to the bug on the iso tracker.
<ogra_> you guys are behaving as if we would have to expect 100s of testers ... are we actually ?
<ogra_> (normally the arm images see at most one or two test results on the tracker, do we actually suddenly have such a big interested tester community that also has the HW ?)
<skaet> ogra_,  we'd like to get to the state of information where we can have 100's of testers.
<slangasek> ogra_: no, but we want community testing of our images, including ARM.  If we have three people try to test for A2, two of them hit this bug and one gets frustrated and doesn't come back, that's not good
<ogra_> skaet, yes, i know what we would like to :)
<slangasek> it's not that we *have* a large tester community, it's that we *need* to have a tester community and should make sure we're doing the right things to foster that
<ogra_> slangasek, yes, indeed, thats why there is a note, still all this discussion sounds like we would have a massive tester community
<ogra_> i totally agree
<slangasek> ogra_: nope - just that we should treat the ARM images in a manner that's appropriate for something that's going to be widely used by the community.  ARM isn't a second-class architecture
<ogra_> its just that in the last 3 years i work with arm nobody cared, i have to get used to the new reality ;)
<slangasek> you're in the big leagues now ;)
<ogra_> haha
<Daviey> I've heard of ARM, will be nice to see some hardware. :)
<slangasek> isn't your house full of ARM chips like mine is?
<slangasek> pgraner: does the video bug impact our ability to do test case validation?
<slangasek> I guess the automated stuff doesn't care, and the manual testing can be done by those whose setups happen to not be affected?
<pgraner> slangasek, if you hit it you can't do much at all
<slangasek> right, but not everyone hits it, so those not affected can still be validating the rest of the stack, no?
<ogra_> right
<ogra_> but you need to find these poor souls :)
<pgraner> slangasek, yea, I'm a bit discouraged with 4 monitors I can get it to work, workaround included :(
 * slangasek nods
<pgraner> slangasek, I'm just worried of a bad testing experience for a new tester who might not read the techoverview etc...
<slangasek> hmm
<slangasek> I agree we should be concerned about making sure testers have a good experience, but I think the release notes for the milestone should *always* be required reading
 * pgraner would agree... then there is reality *sigh*
<ogra_> hey, its just an alpha
<slangasek> well, particularly when we're talking about pre-release milestones
<ogra_> will be better next milestone
<slangasek> testers who aren't reading the release notes... are also probably not helping us improve the release
<slangasek> in general
<pgraner> ogra_, daily quality... never should we have a broken image like this....
<ogra_> hahahaha
<pgraner> balloons, are you directing your community testers to read the release/tech notes
<ogra_> to quote a colleague of mine:
<ogra_> ... then there is reality *sigh*
<pgraner> ogra_, that is the goal, if we don't find a fix soon then we should revert that image back to a working kernel until its fixed
<infinity> Daily quality is obviously the ultimate goal (and ARM shouldn't get a free pass there, not even a little bit), but I think that "completely changing the image format" might get some slack.
<balloons> pgraner, hmm.. I don't know that I've called specific attention to it. but they read that stuff :-) they scour for info anywhere they can get it
<skaet> we do mention it at the notice board on the iso tester....  for this bug.
<pgraner> balloons, prob should make it a "requirement" if at all possible
<skaet> which is where we're asking them to look for what's changed.   per their request for more info.
<pgraner> skaet, it prob should be on the notice board "Before testing read the Release Notes/Tech Overview <links>
<ogra_> pgraner, that will cause double the work than just leaving it dangling for a week until we have the new kernel
<skaet> pgraner,  we can do that.
<pgraner> ogra_, so your telling me we get to miss a week of testing?
<balloons> pgraner, sounds good. I'll feature the notes and call attention to outcomes as part of wrapping up the milestones
<balloons> not a bad idea
<balloons> I like the linking to release notes on the notice board
<skaet> (and I like the fact it will motivate people to add things there as we go, rather than waiting until the last minute ;) )
<ogra_> pgraner, well, as opposed to testing one release old crap and wasting a manweek to fixing a dead horse ...
<pgraner> ogra_, its not old crap... any testing we get is good, the daily will keep moving the only static bit is the kernel
<ogra_> pgraner, well, paolo has a 3.5 kernel in the drawer already ... its missing PM and frequency scaling etc, but has omapdrm working
<rickspencer3> ogra_, seriously, we should not have broken images out
<ogra_> i would rather like to see him working on it for two days more than waste his time on having him build a quantal package from a precise kernel
<ogra_> rickspencer3, thats a dream. ecpecially on arm wehere you have to wait months for a vendor fix etc
<rickspencer3> ogra_, it's not a dream, it's an expectation
<infinity> ogra_: If were waiting for a fix, we can revert.  That's the point being made.
<ogra_> infinity, if we can revert with a fingesnip i agree, if it takes a manweek to do so while we can have a fix in less than a week we should really not care
<ogra_> but i know i'm speaking to deaf ears with that
<infinity> ogra_: It doesn't take that long.  Upload old kernel with new ABI, change seeds and d-i.
<infinity> ogra_: If the fix were today, I'd agree.  But "in a week" often becomes "in a couple of weeks".
<ogra_> test if the kernel works at all with new userspace, find a bug, fix, test again blah
<infinity> If it doesn't work at all with new userspace, we have some upgrade issues to ponder. :P
<ogra_> well, i'm not the kernel team lead, i dont have anything to say about paolos time anyway :)
<ogra_> and i was actually planning to end my day 3h ago ... which i will do now
<highvoltage> have a good evening ogra_
<ogra_> (i just see that plan as a massive waste of developer resources)
<ogra_> highvoltage, ciao ...
<utlemming> Daviey: smoser and I just deep-dived on that particiliar failure and concluded it is transient. I've filed a bug against the test suite. The short story is that this looks like a transient failure, the longer story is that we can't definitively know since the test doesn't capture enough information to determine  the failure mode.
<skaet> ogra_, infinity, slangasek - given the controversy going on right now its probably better if we hold off on these images as part of the milestone.  We'll continue to document them, and point folks to the daily.
<skaet> s/these/ARM Desktop/
<slangasek> skaet: I think the root question remains whether the images as-is are usable enough to warrant releasing as an alpha.  I feel that they are, but I think pgraner and rickspencer3 disagree
<slangasek> regardless of whether we release the alpha, I agree that the video bug is severe enough that we ought to be worrying about how to get a kernel fix ASAP, rather than whenever-3.5-lands
<slangasek> ogasawara: is bug #1010009 on your radar currently?
<skaet> slangasek, yes,  getting the video bug fixed is the priority.
<ubot2> Launchpad bug 1010009 in linux-ti-omap4 "omapdss only works on some monitors in quantal" [High,Confirmed] https://launchpad.net/bugs/1010009
<skaet> slangasek,  the images will be available in the dailies right after, so those who are most interested in helping sort it and test can continue.
<rickspencer3> slangasek, I don't disagree
<rickspencer3> I don't know
<ogasawara> slangasek: it tis and ppisati was looking at it
<slangasek> ogasawara: ok
<rickspencer3> I just disagree that it's acceptable to let the quality for ARM images have a "free pass" from daily quality because it's "hard"
<skaet> +1
<slangasek> rickspencer3: yep, right with you on that one
<rickspencer3> I have no opinion on the releasability of the images as the stand today
<rickspencer3> tomorrow we should talk about what support the engineers working on ARM need to meet daily quality
<slangasek> releasability - that part's hard to judge because we don't have enough data yet on how many users are affected by the bug
<rickspencer3> you that in my opinion the alphas don't matter much
<Daviey> utlemming: ok, thanks for looking into it.  I wonder if you can reach out to Mr Page and see if we can include more data?
 * slangasek ndos
 * slangasek nods
<rickspencer3> my guidance would be to skip Alpha 2 and just focus on getting to a good quality daily asap
<rickspencer3> but it's not my call ;)
<balloons> this goes back to the alpha/beta discussion
 * balloons ducks
<Daviey> Perhaps i have missed the severity of this issue, but it doesn't seem to be an Alpha 2 milestone blocker in my mind.  It's a release note thing.
<balloons> I will say having more people on more hardware will help with this stuff -- this bug likely could have been found last week and fixed in time if we had folks messing with the images on a daily bassis
<Daviey> pgraner / ogra_ : Have you managed to identify when it 'last worked'?
<apw> pgraner, yes i have not been able to get a quantal A2 to show video on my panda, this is infinity's old one so he may know better what it is
<pgraner> apw: its most likey https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/1010009
<ubot2> Ubuntu bug 1010009 in linux-ti-omap4 "omapdss only works on some monitors in quantal" [High,Confirmed]
<apw> pgraner, yep ... whatever that is
<apw> how do i tell which panda i have ?
<pgraner> apw, its on a sticker on the bottom of the board
<infinity> apw: Sticker.
<infinity> apw: I think it was an A2.
<knome> if it hits you with the bamboo, he's the bad panda.
<apw> infinity, A1 it seems
<balloons> knome, +1
<infinity> apw: Or that.  Sure.
<infinity> apw: I dunno, it's never actually mattered what version they were before.
<apw> infinity, indeed, its not clear what if any difference it makes normally, not sure it does here either, i think its a monitor capability thing thats the issue
<infinity> apw: (And I suspect it still doesn't, this bug seems to hit every Panda, and the only thing that matters is what monitor you're (un)lucky enough to own.)
<stgraber> when was that bug introduced? I ran a daily build of last week on my panda and it worked fine here (might just be lucky :))
<infinity> stgraber: I get the impression it's been broken for the entire 3.4.0-2xx ABI.
<infinity> If that's NOT true, and it was recently introduced, backing it out should be cake.
<infinity> One would think.
<Daviey> Alpha 1 had the bug.
<infinity> Certainly less hassle than moving back to 3.2 temporarily.
<stgraber> infinity: ok, well, the setup I have here, definitely worked with 3.4.0-201.6 as that's what I used to test the Edubuntu build last week
<infinity> Daviey: Kay, good to know.  Then I'll stick with the assumption that it's just 3.4 in general.
<Daviey> infinity: although, oddly - hggdh and pgraner didn't see the bug in Alpha 1...  So it might not have complete failure across all setup.
<stgraber> infinity: if we need more tests, I'm happy to run an install test with that setup, though you'll loose access to your natty build machine while I do that :)
<apw> infinity, any idea how i'd test the framebuffer from a precise server install
<Daviey> pgraner is seeing it now, but didn't see it in Alpha 1.  ogra_ has seen it consistently?
<apw> (on that board)
<ogra_> rickspencer3, i said nothing about "hard" is said its a waste of manpower
<Daviey> which means that it might be different issues?
<ogra_> s/is/i/
<pgraner> infinity, I'm digging thru the images we have in the QA lab and see if I can find the image it breaks on
<slangasek> skaet: so how would you like to proceed with the ARM desktop images?  I think it's fine to not ship them for A2 if you think this makes them too broken to put out there
<slangasek> skaet: my only concern is to make sure we're still getting as much testing data as we can given the bugs we're living with
<ogra_> pgraner, we will need a precise kernel i think
<infinity> stgraber: I'm done with my natty build machine for now, if you want to do other things with your Panda.
<ogra_> pgraner, we havent tested any images before A1 (they werent installable or didnt build before that) and i logged that bug for A1
<pgraner> ogra_, ok, I'll dig back anyway to the start of A1 and go from there
<stgraber> ok, will download today's armhf+omap4 then and give it a go. Hopefully I'm one of the lucky ones where the display just works ;)
<skaet> slangasek,  They won't go out with A2.   I was marking them as not part of it,  but I'll undo it, so more results can be gathered.
<slangasek> skaet: ok, sounds good
<Daviey> pgraner: Can you retest http://iso.qa.ubuntu.com/qatracker/milestones/221/builds/16974/testcases/1169/results .. as ogra_ first saw it there.. but was clear for you and hggdh.. So a good watertest to see if something else has changed.
<stgraber> skaet: you noticed that you now have the "ready" flag on the tracker right?
<ogra_> oh, intresting !
<skaet> I agree that getting as much data as we can right now, and getting the images in a better state for the dailies should be the priority.
<pgraner> Daviey, yep, looking for the image now
 * ogra_ hadnt noticed that it worked for pgraner back then
<Daviey> pgraner: http://releases.ubuntulinux.jp/ubuntu-full/12.10/alpha-1/quantal-preinstalled-desktop-armhf+omap4.img.gz ?
<Daviey> what a crappy url
<stgraber> if we're lucky, my test install will fail, then we'll have just one week of changes to go through :)
<pgraner> Daviey, we keep em archived in the lab
<Daviey> http://cdimage.ubuntu.com/releases/12.10/alpha-1/quantal-preinstalled-desktop-armhf+omap4.img.gz better.
<ogra_> skaet, as i said, paolo has a 3.5 kernel that has not all features yet ... would just be a matter of uploading that and living with some regressions until that kernel is fixed, but seems rickspencer3 doesnt like that
<ogra_> i think that upload could happen tomorrow so that fridays images would be usable again
<skaet> ogra_ if we can get the daily usable on Friday that would be good.
<ogra_> skaet, well, not if he has to roll a kernel package from scratch tomorrow
<ogra_> thats my point
<skaet> ogra_,  I suspect this will be a motivating factor for improving the arm desktop story overall,  best path to how is going to be determined by foundations and kernel team.
<skaet> and getting arm dailies up to the same level we have for i386/amd64 can only be a good thing in the big picture.
<slangasek> ogra_: hmm, I don't think rickspencer3 said anything one way or the other about a 3.5 kernel that doesn't have all features
<slangasek> I guess one of us has misunderstood him :)
<infinity> Granted, shipping an omap4 kernel without power management enabled means PandESes need heatsinks.  Or they die.
<slangasek> I think the point is that the video bug shouldn't be allowed to linger unfixed for weeks, because that's incompatible with the goal of daily quality
<infinity> Just FYI.
<slangasek> ah
<slangasek> right, that's probably not a good thing then either
<slangasek> (I assumed new PM)
 * skaet --> dr. appt.  biab.
<stgraber> so, I seem to be one of the lucky ones, 20120627 boots fine here (kernel boot messages => upstart => ubiquity)
<infinity> stgraber: Or an unlucky one, from the POV of a software developer who likes to reproduce bugs.
<stgraber> infinity: well, at least we know that A2+samsung-tv seems to work ;)
<infinity> stgraber: AIUI, any monitor that isn't (and I quote) "broken" works fine.  The problem is that people may have underestimated how many modern monitors still qualify as that. :P
<stgraber> infinity: well, apparently pgraner is good at finding "broken" monitors ;)
<pgraner> stgraber, not finding... buying
<stgraber> even worse ;)
<cjwatson> ubiquity missing fonts for two languages - damnit, I'm sure I fixed that
<cjwatson> maybe it's pending an upload of something - I'll look later
<cjwatson> (I expect it's Tibetan and whatever the other new one is - i.e. not a regression in that sense, these are languages not previously offered for installation
<cjwatson> )
<Daviey> infinity / stgraber: FWIW, my HDMI 'monitor' has HDMI standard 1.1 , and the pandaboard support wants newer version than that.
<Daviey> Ie, sound over HDMI doesn't work with my monitor
<Daviey> It can't parse the table.. I raised a bug on it.
<balloons> ev, what is with the accessibility profile in wubi?
<balloons> It has several radio buttons for visibility and mobility aids, but they are generically named like. Visibility1, etc
<stgraber> Daviey: right, I think I've got at least 1.3 on all my monitors here, some might even be 1.4
<pgraner> Daviey, is there an easy way to tell from the monitor itself?
<Daviey> pgraner: no, there is a command to run
<Daviey> one moment
<Daviey> pgraner: parse-edid
<Daviey> sudo apt-get install read-edid
<Daviey> cat /sys/devices/omapdss/display0/edid | parse-edid
<Daviey> I'm not able to get native resolution, which the board supports, as it fails to parse the table.. bug 953491
<ubot2> Launchpad bug 953491 in linux-linaro "PB - Fails to display 1360x768, which is monitors native" [Undecided,New] https://launchpad.net/bugs/953491
<slangasek> cjwatson: Amharic and Sinhala, from the screenshots
<cjwatson> slangasek: huh, not new then
<stgraber> right, so queuebot doesn't know about status=4 :)
<stgraber> but it does now :)
<skaet> :)
<skaet> Daviey,  have started using the ready button to indicate which images are good to release.
<Daviey> skaet: satisfying to push?
<skaet> Daviey, yes.  We'll continue to gather results until tomorrow
<skaet> let me know if you disagree with any I've marked as ready
<Daviey> skaet: no, initial coverage seems to be pretty good.
<skaet> note:  I've not marked Ubuntu Server i386 as ready,  since you don't want to release it.
<Daviey> Can people still add results to 'ready' images?
<skaet> Daviey,  yes.   :)
<stgraber> skaet: oh, I supposed I should change publish-image-set.py to look for the new ready state as the list of things we want to publish
<Daviey> Then we can un-ready something if it goes bad. :)
<stgraber> *suppose
<skaet> Daviey,  yes,  mark it testing and it will "unready" it.
 * skaet just the tutorial from stgraber ;)
<stgraber> Daviey: that's the idea ;) it's going to lead to some new interesting release vocabulary for sure ;)
<skaet> stgraber,  yes,  having publish-image-set.py pull from the ready list would be logical.   :)
<Daviey> \o/
<skaet> Daviey,   we'll need to keep a close eye on this,  but am excited about this capacity coming on line.  :)
<skaet> thanks stgraber!  :)
<Daviey> hmm, why is queuebot:#ubuntu-release- Builds: Netboot amd64 [Quantal Alpha 2] has been updated (20101020ubuntu150) just shown
<balloons> skaet, I was still finishing my wubi testing! My result felt so meaningless when you marked it as ready
<balloons> heh, /sarcasm
<Daviey> infinity just did a d-i upload, ok
<infinity> Daviey: "just"?
<skaet> hold it,  why was there a d-i upload when we're in soft-freeze?
<Daviey> oh wait
<infinity> That was 20 hours ago. :P
<infinity> queubot's just having a spaz.
<Daviey>  -- Adam Conrad <adconrad@ubuntu.com>   Wed, 20 Jun 2012 15:52:08 -0600 .. confused me
<Daviey> Wed, June 15:52:08 -0600
 * skaet breathes again.
<Daviey> the numeral date is irrelevant
 * Daviey does wonder if infinity's clock is 7 days out?
<infinity> Daviey: No, I just didn't change the line in bzr from my previous revision.
 * infinity hates when every changelog commit changes the signature line.
<stgraber> infinity: nope, my script is just stupid and considers "ready" as missing from the tracker, so it reset the ready flag ;)
 * stgraber fixes
<stgraber> ok, it's clever now, won't mess with something that's already on the tracker
<skaet> :)
<stgraber> skaet: sent a merge proposal for ubuntu-archive-tools, just need to get an AA to review and merge
<balloons> skaet, ok, so other than ARM, what are we waiting/hoping for?
<skaet> Daviey, ^ since you're now trained....
<skaet> and have a vested interest in it working tomorrow ;)
<infinity> stgraber: Linky?
<stgraber> https://code.launchpad.net/~stgraber/ubuntu-archive-tools/pkgsets-improvements/+merge/112435 (diff still building)
<stgraber> diff is: http://paste.ubuntu.com/1063260/
<skaet> balloons,  waiting for results from the flavors to come in.
<infinity> stgraber: Your branch name seems a bit misleading. :P
<stgraber> infinity: oops
<stgraber> infinity: yeah
<skaet> balloons,  we're still missing the upgrade testing.
 * stgraber blames bzr
<balloons> skaet, yes, I asked for some results on that :-(
<Daviey> skaet: I'm yet to get my boy scout badge proving that i am trained.
<stgraber> infinity: let me get lp-propose-merge to actually propose the right branch...
<balloons> i like "real" upgrades during the testing to happen
<balloons> but we can always test Vm'd upgrades
<balloons> it's just default install stuff, so not as exciting
<infinity> stgraber: Whatever, I can fakemerge your 2-line patch. :P
<Daviey> stgraber: the diff is lacking tests.. maybe it's still generating? :)
<skaet> for A2,  knowing the default install stuff is working,  is good.
<stgraber> infinity: https://code.launchpad.net/~stgraber/ubuntu-archive-tools/add-ready-state/+merge/112437
<stgraber> slangasek: what was that option you wanted to add to lp-propose-merge? --with-my-fist? :)
<slangasek> stgraber: heh, pretty sure that was never a serious suggestion from me ;)
<stgraber> slangasek: it's on /Quotes, it must be serious :)
<infinity> stgraber: Appears to DTRT, committing.
<Daviey> gah, bzr: ERROR: These branches have diverged.  See "bzr help diverged-branches" for more information.
<Daviey> infinity: i hate you.
<infinity> Daviey: I'm blushing.
<infinity> I'm also hungry.
<infinity> Possibly related.
<slangasek> ok, I don't understand how mvo even managed to upload the update-manager SRU that's sitting in the queue
<Daviey> Okay, i'm mostly signing off.. I'll be back later to check scrollback
<slangasek> because I'm trying to re-export it from bzr to fix up a bug ref
<slangasek> and the source export consistently fails
<pgraner> slangasek, ogra_, Daviey: just had vanhoof try and it failed for him on A2 :(
<slangasek> hmm, ok
<skaet> good night Daviey
<Riddell> hmm any new kubuntu alternates on the way?
<Daviey> Riddell: i thought everything was good now?
<Daviey> Riddell: what images are you after?
<Riddell> Daviey: new alternates for kubuntu
<Riddell> [8]...https://launchpad.net/bugs/1018448 meta-kde-telepathy not installing needs kubuntu alternates respun
<ubot2> Ubuntu bug 1018448 in meta-kde-telepathy "0.4.0ubuntu2 can not install" [Undecided,Fix released]
<astraljava> Hi gang, Studio's i386 wasn't apparently re-spun(?) after the kernel fix. Is it too late now to request it, still?
<skaet> astraljava,  no,  we can respin.
<infinity> astraljava: Hrm, I did respin it.
<Daviey> astraljava: on it.
<skaet> Daviey, you handling respinning Kubuntu alternate too?
<Daviey> yeah
 * skaet goes back to sorting bugs
<astraljava> infinity: But I'm not seeing it in the current, but I also didn't see an email from cdimage about a failure.
<infinity> astraljava: 20120627 should have had the kernel fixes.
<infinity> Daviey: There shouldn't be reason to respin studio, unless 20120627 is broken somehow.
<infinity> Daviey: And if it is, I'd like to know how.
<astraljava> It's marked as ready.
<infinity> Oh, but 20120627 only has amd64...
 * infinity blinks.
<astraljava> Yep, something's off.
<astraljava> In the QA tracker, i386 is marked (ready).
<skaet> infinity when you did the rebuilds last night, did you have an old version from the pad of the rebuild scripts?
<infinity> ubuntustudio-dvd-i386 on cardamom.buildd finished at 2012-06-27 09:16:50 (success)
<infinity> skaet: No.
<infinity> skaet: If I had, neither arch would have shown up.
<skaet> infinity, yeah that timestamp is definitive.
 * skaet still wanting her pastebin of the times if its handy....
<infinity> Oh well, I don't have the inclination right now to sort out WTF.
<infinity> Daviey: If you wanna respin studio, go nuts.
<Daviey> k
<astraljava> Thanks guys!
<infinity> skaet: http://paste.ubuntu.com/1063303/ <-- Not really all that interesting except for "arm being on one machine sucks and we need to fix that (again)"
<skaet> thanks infinity.  :)
<cjwatson> skaet: is it not possible to (scriptably) work out all the timings from the existing log files?
<cjwatson> 'cos if it isn't, we should fix that, and then people wouldn't have to toss pastes around
<cjwatson> (then you could get historical information from cronned daily builds over time, etc.)
<skaet> cjwatson,  there were some bits missing before in terms of total time through,  but I agree that is the better approach.
<cjwatson> if you could have another go and find out exactly what's missing for you, I'd be happy to fix that
<skaet> cjwatson,  will study my notes in the next quiet time, and take you up on that offer.  ;)
<skaet> thanks!
<stgraber> yay, we now have two test results for amrhf+omap4 ;)
 * skaet thinking a lot more than 2 have run it this afternoon....  and should be recording their results.  :P
<slangasek> bdmurray: have you seen this update-manager test suite failure in test_html_uri_real ? sounds kinda like something you'd mentioned before
<slangasek> bdmurray: http://paste.ubuntu.com/1063315/
<bdmurray> slangasek: right I futzed with /etc/update-manager/release-upgrades
<bdmurray> slangasek: or that's what I recall
<slangasek> bdmurray: hrm; I'm building in a chroot that doesn't have that file
<slangasek> so perhaps that's the problem
<slangasek> aha; prompt=lts there fixes it
<bdmurray> right
<bdmurray> MetaRelease.py doesn't set a default for that I think
<bdmurray> but it does for the stuff in /etc/update-manager/meta-release
<bdmurray> so maybe sorting that out would help
<slangasek> sounds like it
<slangasek> not for this upload though, where I'm just trying to do a changelog tweak and reupload :/
<Daviey> So... Ubuntu Studio i386 still didn't show up
<infinity> Daviey: Depite it building, right?
<Daviey> correct
 * stgraber looks
<Daviey> ubuntustudio-dvd-i386 on cardamom.buildd starting at 2012-06-27 21:54:28 .. and relevant Success
<infinity> Yeah, and it's right there on the buildd.
 * infinity checks the cdimage log.
<stgraber> mv: cannot stat `/srv/cdimage.ubuntu.com/scratch/ubuntustudio/dvd/tmp/quantal-i386/CD1/casper/filesystem.kernel-lowlatency-pae': No such file or directory
<stgraber> make: *** [/srv/cdimage.ubuntu.com/scratch/ubuntustudio/dvd/tmp/quantal-i386/bootable-stamp] Error 1
 * stgraber reads some more
<infinity> stgraber: Bah, did I miss a spot?
<stgraber> infinity: tail on /srv/cdimage.ubuntu.com/log/ubuntustudio/quantaldvd-20120627.1.log :)
<infinity> Balls.
<stgraber> right, the rest looks clean, so it's just one more spot to update for the kernel stuff :)
<infinity> Daviey: fixed.
<infinity> stgraber: I'd fixed it in cdimage and debian-cd, but only pulled the former, not the latter.
<stgraber> hehe
<infinity> Daviey: Actually, don't try again.  I'll do it.
<stgraber> well, at least Daviey should be able to just rebuilt the .iso without the livefs, should be quite quick
<stgraber> or you
<Daviey> For those following at home, http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntustudio/quantal/dvd-20120627.1.log
<infinity> This one should work just dandily.
<infinity> Because I'm SMRT.
<Daviey> infinity: are you doing it?
<infinity> Daviey: Already building.
<Daviey> k
 * infinity grabs a smoke while that finishes.
<infinity> astraljava: Sorry about the confusion there.  I forgot to pull a revision from bzr last night for your kernel changes.
<astraljava> infinity: No worries, thanks for doing it now! :)
 * Daviey heads to bed
<infinity> astraljava: ^
<astraljava> Whee! You guys are super! :) A gazillion thanks!
<balloons> woot! a ubuntu studio image built!
<knome> oh my
<infinity> balloons: Well, amd64 was already built.  I just kinda effed up i386 last night, and fixed it today. :P
<balloons> haha -- don't have too much fun
<balloons> I'll see you all again in the morning
<knome> night balloons
#ubuntu-release 2012-06-28
<NCommander> Seems armhf+highbank fell off the ISO tracker
<NCommander> Can someone magic it back on?
<skaet> NCommander,  will do.   same pattern as arm+armadaxp?
<NCommander> Yeah
<NCommander> I'll run through the tests tonight to make sure everything is peachy
<infinity> NCommander: Everything's peachy except that it doesn't boot.
<NCommander> infinity: eh?
<infinity> NCommander: uboot bug, Rob Herring is on it.
<skaet> NCommander,  its up on the tracker now.   Let me know if something needs tweaking.
<NCommander> infinity: boots just fine as of last week, though you need to do a magic poke before invoking anything
<infinity> NCommander: Okay, sure, if you're poking initrd_high.
<infinity> NCommander: If that's your definition of success go to town. :)
<NCommander> infinity: it was in the oficial instructoins from Calxeda (with a note that it would be fixed so it would unnecessaary)
<infinity> NCommander: Evidently, not everyone got that memo.
 * cjwatson grows old and dies waiting for dogfood.lp.net QA.  Wanna go to bed.
<infinity> NCommander: Including Calxeda...
<infinity> NCommander: Since Rob just ran into it with the latest d-i and has been grumpily hunting the bug all day.
<NCommander> cjwatson: good things come to those who wait?
<NCommander> infinity: possibly we're getting bug confusion then; there was a known one where you had to do mw.l 800000 0 10000 to get the nitrd to load else the kernel goes off to lala land
<infinity> NCommander: Different bug.
<NCommander> !@#$#!
<cjwatson> NCommander: They'd better
<NCommander> infinity: ugh, yeah, the kernel blew up trying to decompress the ramdisk
<infinity> NCommander: Yup.
<NCommander> infinity: I *just* tried this with a precise kernel/ramdisk and it worked
 * NCommander grumbles
<infinity> NCommander: setenv initrd_high 0xffffffff
<infinity> NCommander: It's the size of the initrd.gz that triggers it.
<NCommander> infinity: thanks
<infinity> NCommander: End up with the stack overlapping the initrd.
<infinity> NCommander: Which, it turns out, is bad.
<NCommander> the kernel usually doesn't like that
<NCommander> infinity: that did the trick
<NCommander> thanks
<infinity> NCommander: cheers.  Happy testing.
<vanhoof> pgraner: Daviey, slangasek, ogra_, updated 1010009
<vanhoof> if you need any more specifics I have the sdcard waiting :)
<slangasek> vanhoof: could you note explicitly whether rebuilding boot.scr helped or didn't?  (I assume it didn't)
<vanhoof> slangasek: is my comment misleading?
<vanhoof> slangasek: no change in behaviour in all three scenarios
<vanhoof> stock, 1280, 1920
<slangasek> vanhoof: not so much misleading as hard for me to parse at a glance - feel free to chalk this up to a parser bug on my part and ignore :)
<slangasek> regardless, thanks for testing
<vanhoof> slangasek: no worries, will clarify, I can see where theres room for question
<vanhoof> slangasek: updated
<skaet> vanhoof,  can you update your results on the iso tracker too.
<vanhoof> skaet: certainly
<skaet> thanks!  :)
<vanhoof> I also have an original panda I can try as well
<vanhoof> but you'll lose me from IRC ;)
<vanhoof> *cough* great znc proxy *cough*
<astraljava> Hi gang, how much time do we have until release announcements?
 * cjwatson cheerfully deletes stuff from ArchiveAdministration
<ogra_> stgraber, oh, you did a successfull panda install ? could you comment on bug 1010009 ?
<ubot2> Launchpad bug 1010009 in linux-ti-omap4 "omapdss only works on some monitors in quantal" [High,Confirmed] https://launchpad.net/bugs/1010009
<stgraber> ogra_: commented
<skaet> good morning
<skaet> Daviey, jibel, ogra_, infinity -  do we have any results for the Netboot armhf+omap4?
<stgraber> skaet: if not, I can probably get you some result
<skaet> stgraber,  would appreciate knowing no surprises.   Thanks!
<stgraber> ok, will start an install before the 12.04.1 meeting then
<Daviey> super
<jibel> skaet, I don't
<jibel> skaet, https://wiki.ubuntu.com/QATeam/ReleaseReports/PreciseAlpha2TestReport
<jibel> oh sorry
<skaet> thanks for the report jibel.
<jibel> skaet, I'm sure you're interested by Quantal too
<jibel> https://wiki.ubuntu.com/QATeam/ReleaseReports/QuantalAlpha2TestReport
 * skaet laughs,  yup.
<skaet> The Quantal one is more handy,  no question.    Although the precise one is interesting for comparison purposes ;)
<skaet> jibel,  can you cross check the stats on the top of the report.   Not seeing Ubuntu Desktop there,  only highbank
<skaet> ?
<jibel> skaet, just saw that. checking
<Daviey> jibel: I was trying to find that earlier today!
<jibel> found the problem: build.status = 4
<jibel> skaet, the coverage includes everything that is not ready to be released, which makes it less useful
<jibel> I'm regenerating a new report
<skaet> jibel,  thanks.
<stgraber> cjwatson: so are we now properly building all our precise images with -proposed enabled? (I'm planning on mentioning it in the 12.04.1 meeting)
<cjwatson> stgraber: Not quite, I need to fix livecd-rootfs
<cjwatson> So livefses aren't yet being built with -proposed, unfortunately
<cjwatson> But I'll fix that by the end of the week
<jibel> skaet, https://wiki.ubuntu.com/QATeam/ReleaseReports/QuantalAlpha2TestReport
<jibel> I should probably split the list in ready/not ready
<Daviey> jibel: yes please
<jibel> -> A3
<Daviey> jibel: Is the script which generates this somewhere
<Daviey> ?
<jibel> Daviey, my junk
<Daviey> jibel: well, i wasn't commenting on the quality of your code.. just hoping you'd share it. :)
<jibel> it is not even in my junk, I'll commit it to the tracker branch
<ogra_> skaet, just fyi, seems paolo has a fix for the kernel that, even though it does get me a black screen instead of a splash when booting (which can take 5-10 min on arm for live images) ... i get the proper X resolution once the X server is up
<skaet> ogra_ that will be an improvement.  :)  Will he be aiming for including it in the next set of dailies?
<ogra_> well, i assume he will upload as soon as we have some more test results
<ogra_> i wouldnt upload it right now, after all it worked for me with the resolution on cmdline while it didnt work at all for others with the same panda model
 * skaet nods
<ogra_> so we should see if it works for pgraner, apw and vanhoof too first
<pgraner> ogra_, I'll check in about 30 min...
<ogra_> pgraner, great, see my comment to apw on #ubuntu-kernel
<stgraber> armhf+omap4 is taking quite a while to install as I don't have a local ports mirror (yet)
<skaet> ok,  thanks.
<stgraber> but the base system, partitioning, ... succeeded, just waiting for ubuntu desktop to install now ;)
<skaet> vanhoof,  can someone from your team do a sanity check on netboot for armadaxp?   NCommander did highbank yesterday.
<vanhoof> skaet: sure one sec
<ogra_> stgraber, urgh, you should just have done a minimal install :P
<stgraber> ogra_: so I thought after I pressed enter and saw the 30min ETA show up ;)
<stgraber> ogra_: though I'm guessing most other netboot install will be just base system, so checking that the archive is actually consistent and lets you install a desktop is still a good test
<ogra_> sure :)
<ogra_> just takes ages :)
<Daviey> astraljava, scott-work - updates for https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Alpha2 ?
<skaet> Daviey,  I've marked the images that look like they should be sane to publish, can you double check they match up with the data you know as well.
<skaet> balloons, jibel, ^
<skaet> utlemming,  please go ahead and publish your set now.
<skaet> jibel, does mvo still do https://wiki.ubuntu.com/UpgradeTestingProcess?  or do you do it now?   (if you do,  can you update the wiki page).
<jibel> skaet, why is lubuntu amd64 ready and not amd64+mac ?
<skaet> lubuntu amd64+mac had an additional crash,  and haven't gotten any data from that team to my pings, so seemed safest to leave it off.
<jibel> skaet, updated. update-manager -d broken, cdromupgrade without network untested
<skaet> thanks jibel
<jibel> skaet, they are affected by the same problem of broken combo boxes
<skaet> jibel,  so recommend is to leave both off?
<jibel> skaet, I don't know, it's up to the product manager
<skaet> jibel, yeah and the product manager hasn't provided input (or his delegate).   ok. leaving both off.
<jibel> but a decision for one will affect all lubuntu desktop images
<skaet> interesting,  i386 was looking solid.   oversite why that bug isn't on it?
<jibel> skaet, it should affect it too. let me test
<stgraber> ogra_: kernel blew up ;)
<ogra_> stgraber, how ?
 * apw reports that his broken panda is showing HDMI with ppisati's kernel
<stgraber> I have a whole bunch of tcp_recvmsg related oops
<cjwatson> skaet: Presumably either nobody tried manual partitioning, or they took a path through it that didn't hit that bug
<cjwatson> (Maybe keyboard navigation avoids it or something?  I haven't much looked into it.)
<skaet> cjwatson,  that would make sense.
<skaet> I've gone ahead and unmarked that image for release.
<skaet> so for Lubuntu,  just releasing the alternates.
<utlemming> skaet: publishing in progress
<jibel> keyboard navigation doesn't avoid it
<stgraber> so that armhf fail got me a nice 1GB of log file, mostly kernel oops ;) that explains why the system died of an OOM :)
<ogra_> hah
<stgraber> would be good if someone could confirm I'm not the only one getting all these oops though
<stgraber> because if it's a generic issue, then it's simply not possible to install desktop over netboot because of the running out of memory part of the problem :)
<stgraber> minimal system might be able to succeed before you run out of memory
<ogra_> stgraber, well, i dont get them here
<ogra_> though i installed my desktop from a live image ... probably there are differences to netboot that we havent found yet
<skaet> Daviey, I think the ones marked ready right now, are the ones we'll be going with for A2.   Can you start the publishing?
<jibel> skaet, without surprise same problem on i386 and after installation combo boxes do not work. So it affects alternate too.
<ogra_> stgraber, ddi you manually partition ?
<ogra_> *did
<skaet> jibel, understood,   undoing the publishing of them now as well.
<skaet> Daviey, ^
<ogra_> stgraber, by default i get a 386M swap partition on the live image, maybe yours is smaller ?
<Daviey> skaet: wait, did you just publish them?
<skaet> Daviey,  sorry,  meant to say marking them as ready to publish
<utlemming> skaet: cloud images published
<skaet> Thanks utlemming
<skaet> Daviey, can you please publish the images marked (ready) now?
<stgraber> ogra_: nope, it was automated partitioning, so it managed to dump a 950MB log file before dying :)
 * skaet will go and update the pages to reflect lubuntu won't be going out.
<Daviey> stgraber: what are these state changes?
<Daviey> skaet: Why isnt't lubuntu going out?
<skaet> Daviey, broken combo boxes problem and no guidance otherwise from lubuntu team.
<stgraber> Daviey: typically "has been updated" means either a new version or a state change from ready back to testing
<Daviey> stgraber: Well with yesterdays date, i assume it's back to testing
<Daviey> skaet: Who is the owner of lubuntu again
<Daviey> ?
<skaet> Daviey,  gilir - who's not on IRC that I can find.
<Daviey> skaet: I can't see what on https://wiki.ubuntu.com/QATeam/ReleaseReports/QuantalAlpha2TestReport makes it unsuitable for A1
<skaet> Daviey, ^ backscroll
<bjf> SRU folks: there are a number of kernels that are in -proposed and ready for -updates
<phillw> skaet: you have email :)
<jibel> Daviey, bug 1018533 which was reported on lubuntu ppc  and mac but affects every architecture of lubuntu and installed desktop.
<ubot2> Launchpad bug 1018533 in ubiquity "Cannot manually change partitions" [High,Triaged] https://launchpad.net/bugs/1018533
<jibel> and it is not in ubiquity gtk3 and can be worked around in whatever theme they use.
<jibel> s/ubiquity/ubiquity but
<skaet> phillw,  ok wil look.   Basically looking for go/no go from lubuntu perspective...
<phillw> skaet: I suspect, it is a bigger problem than just lubuntu :(
<phillw> if you look at the similar bugs in xubuntu & ubuntu.
<infinity> bjf: I'll have a poke.
<phillw> If ubiquity won't allow the install & the putting of grub where required, it'll have to be a NO-GO from us.
<bjf> infinity, danke
<skaet> phillw,  thanks.
<infinity> bjf: You weren't kidding about "a number".  Starting at hardy and working forward. ;)
<bjf> infinity, i get paid by the number of kernels produced
<Daviey> phillw: do you have an ETA?
<skaet> Daivey,  I think they've got all the results they're going to have at this point.   Something else you're asking for?
<infinity> bjf: Oh, hrm.  linux-ti-omap4 in oneiric doesn't have the Regression-testing task ticked off, but the comments seem to imply it should be.  Workflow oops, or is it not ready yet?
<bjf> infinity, i'll check on it
<infinity> bjf: bug #1012482
<ubot2> Launchpad bug 1012482 in kernel-sru-workflow "linux-ti-omap4: 3.0.0-1212.24 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/1012482
<infinity> bjf: I'll reject my copy for now, and we can act on it later, when you're sure. ;)
<bjf> infinity, it's just omap4, does anyone really care? :-)
<infinity> bjf: I'm sure someone does. :P
<Daviey> phillw: Hey!
<Daviey> phillw: Can you add a entry to the TechnicalOverview
<Daviey> phillw: https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Alpha2
<phillw> Daviey: I don't think there are any A2's for Lubuntu?
<infinity> bjf: Same story on ti-omap4/precise (bug #1013464), and we definitely care about that one. :)
<ubot2> Launchpad bug 1013464 in kernel-sru-workflow "linux-ti-omap4: 3.2.0-1415.20 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/1013464
<bjf> infinity: ack
<Daviey> phillw: huh?
<infinity> bjf: In both cases, there's a comment from John Johansen that says "looks good".  If that's meant to be a resounding "this kernel is awesome and provided me with free kittens", I imagine the tasks just need twiddling.
<Daviey> phillw: to clarify, you don't want Lubuntu to be part of Alpha2?
<bjf> infinity, LOL, that is the "security team signoff"
<infinity> bjf: Ahh.  Check.
<infinity> bjf: So, we really are still missing some sort of testing of those.  I'll leave them be, then.
<bjf> infinity: right, i'm hasseling QA
<infinity> bjf: Not sure who's meant to be doing ARM kernel testing, but they're clearly slacking. ;)
<bjf> infinity, i blame pgraner
<infinity> bjf: (There's an armadaxp in the pipe too that, while it's not aged enough yet anyway, could also use some testing).
<phillw> Daviey: with the problem of Ubiquity preventing an install on a stated partition, until that is resolved I'm not convinced that releasing an A2 is wise.
<bjf> infinity, yes QA is on the hook for that and have already been pinged about it
<infinity> bjf: Ideally, I'd like to see these things fully verified before they hit the 7d window, so we can grease this machine a bit better.
<infinity> bjf: (Though, it's sure a lot better than it used to be)
<bjf> infinity: i can only flog so hard
<phillw> Daviey: Julien is on the mailing list now. I await his decision.
<infinity> bjf: Alright, all done.  Except for all of Tim's linux-firmware uploads which never seem to get reviewed in a timely fashion.  Maybe I'll look at some of those.
<bjf> infinity: ack and thanks
<Daviey> phillw: We really need to know now TBJ
<Daviey> TBH
<gilir> phillw, the bugs doesn't seems lubuntu specific, except the gtk one which was (only ?) workarounded on ubuntu theme
<Daviey> phillw: I think we need to release A2 without Lubuntu based on the uncertainty, but can tag it on later as a post release update?
<gilir> phillw, but as A2 is not too much important for lubuntu (no major change), we can probably drop A2 if you are not confident
<phillw> gilir: I'm not confident. I think the ubiquity bug(s) affecting us, ubuntu & xubuntu need further looking into. 2 days for rc was not enough.
<gilir> Daviey, I'm not sure the issues lubuntu have are specific to us, but you can just drop A2 for lubuntu if it delayed the release and you are sure about the others ISO :)
<ScottK> phillw: It's just for manual partitioning, right?
<ScottK> If it's just manual partitioning, I'd release note it and then do the release.
<phillw> ScottK: AS I see, but I don't know if the xubuntu issue also affects lubuntu. We've not had time to check it. Nor the one affecting ubuntu.
<phillw> Yes, it seems just manual partitioning.
<ScottK> If it were me, I wouldn't let that stop the release.
<ScottK> (It's an Alpha)
<ScottK> As long as you document the limitation.
<skaet> gilir,  phillw - if you can add the work arounds to the TechnicalOverview/Alpha2 notes,  I'm ok with them going out if you want.   They've been well tested,  but folks need to know about the issues.
<ScottK> skaet: Looking at the testing report, Bug #1017172 seems somewhat scary.
<ubot2> Launchpad bug 1017172 in ubiquity "Grub installs to wrong drive" [Undecided,New] https://launchpad.net/bugs/1017172
<skaet> ScottK,  yes, that was one of the ones that gave me pause.   Counter is there's only one report, and a lot of other folks have tested
<skaet> and not seen issues
<phillw> for ubuntu also, I can't access the xubuntu one
<skaet> its not confirmed.
<gilir> skaet, I can add a workaround for the manual partitioner bug
<phillw> gilir: So, a release note & launch?
<ScottK> gilir: Excellent.
<gilir> skaet, for the wrong install with grub, it seems to affect only when you have 2 drives, which we doesn't test a lot in a vm :/
<phillw> after saturday, I can get back to testing, piglet has two hard drives :)
<Daviey> skaet: ubuntustudio amd64?
<skaet> gilir, yes, that should be mentioned,  as should recommedation in the overview section to stick with VMs possibly?
<Daviey> skaet: it's had no testing.
<skaet> Daviey,  no test results on it,  so don't know if there are surprises there or not.
<skaet> so, no publish for now.
<Daviey> skaet: ack
<gilir> skaet, fine with me, it's an alpha after all :)
<skaet> Daviey,  looks like we'll be publishing the lubuntu ones,  I'm going to "ready" them on the tracker now.
<skaet> gilir,  :) looks like we've got 2 threads going.  just to be clear,  you want us to publish the lubuntu ones,  right?
 * Daviey waits
<xnox> ubuntu server i386 not going to be release, correct?
<skaet> xnox,   yes,  we're not releasing i386 ubuntu server
<Daviey> yah
<gilir> skaet, yes please :) I'm finishing the note on the overview about the issues we mentionned
<skaet> Thanks gilir
<skaet> Daviey,  you should be good.
<skaet> gilir,  only one I held back was alternate powerpc, which had been marked as install failed on all tests.
<gilir> skaet, ok
<Daviey> utlemming / smoser: Confirm that Alpha 2 cloud images are published?
<utlemming> Daviey: confirmed
<utlemming> Daviey: I confirmed to skaet at 09:52 -06:00
<Daviey> utlemming: thanks
<smoser> https://cloud-images.ubuntu.com/releases/quantal/alpha-2/
<Daviey> skaet: Are you in contact with steve edwards?
<astraljava> skaet: You wanted info on Studio? Technicals: Xfce updated to 4.10 (from Xubuntu), kernel (lowlatency) updated to 3.5. No other real major package updates. I wasn't really expecting to see Studio on Alpha-2, so I didn't prepare a proper release note this time. Also, amd64 images were not tested.
<skaet> Daviey, yup.
<skaet> astraljava, could you add that to the TechnicalOverview page?
<astraljava> skaet: Xubuntu images can be released, no overly bad issues were found that would prevent them. I also saw that pleia2 handled the notes section, so do you need anything from us, still?
<astraljava> skaet: Yeah, sure.
<skaet> thanks astraljava,   for the confirmation on Xubuntu.
<skaet> astraljava,  the bug that we were worried about is: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1017172
<ubot2> Ubuntu bug 1017172 in ubiquity "Grub installs to wrong drive" [Undecided,New]
<astraljava> skaet: Studio bits updated. I have no further data on that bug, so cannot say if it's an isolated incident or a recurring issue. It wasn't mentioned in other cases, though, so need to do more research.
<skaet> Thanks astraljava  :)   let us know what you find.
<astraljava> Will do. Sorry I was a little late of schedule, hopefully the delay was not too frustrating.
<dobey> hey all. now that u1 has an MRE, is it best for me to make an "upgrade to X.Y.Z release" bug for all the packages we want to SRU to precise?
<stgraber> dobey: yeah, the SRUs will need a tracker bug and that sounds like a good title for it. Obviously, for any fixes you have in there that already has a matching LP bug, please link to it (to make it easier on users who want to figure out what changed)
<Daviey> also has the benefit of closing the bugs on publication :)
<dobey> stgraber: right, thanks; yeah i try to list all the bugs that affect ubuntu in the changelog as well anyway. :)
* ChanServ changed the topic of #ubuntu-release to: Quantal Quetzal Alpha 2 released! | Archive: open | Quantal Quetzal 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 birdseed | melior malum quod cognoscis
 * infinity begins to carefully copy stuff from -proposed to -release.
<skaet> thanks infinity :)
<skaet> please keep count.
<skaet> :)
<skaet> crontab has been turned back on for quantal dailies
<skaet> image posting to iso tracker has been reset to dailies
<skaet> iso tracker has had alpha 2 marked released, and daily moved back to testing.
<vanhoof> skaet: dannf just tested armadaxp+netboot and posted results for a2
<skaet> thanks vanhoof
<skaet> (and dannf!  :) )
<Daviey> skaet: all well in the world
<Daviey> ?
<skaet> Daviey,  alls well so far.  Thanks for all your help getting A2 out the door!  :)
<Daviey> super
<skaet> alpha 2 milestoned bugs now moved to alpha 3
<xnox> congrats! thank you all =)
<highvoltage> yay
<highvoltage> ah thanks for moving the edubuntu ones, skaet. I should've done it already actually :)
<xnox> infinity: are you copying everything, or are you using britney transitions?
<infinity> xnox: The former.  britney's not ready yet (though, this would have been a good test)
<infinity> xnox: But I'm doing it carefully and fixing build failures first. :P
<xnox> infinity: two of my uploads to proposed did FTBFS
<Laney> the horror
<infinity> xnox: Which two?
<xnox> infinity: avogadro & mongodb on arm-any
<infinity> xnox: avogadro is fine, it's never built on ARM before.
<infinity> xnox: (Though, fixing it would be nice, and I might do so "later")
<infinity> xnox: monogodb, on the other hand...
<xnox> mongodb - new upstream release introduces more non-arm pointer logic, so the smoke test segfaults. So our existing arm patch needs further fixing
<xnox> ... if only it was forwarded to debian or upstream in the first place.....
<infinity> If only.
<infinity> xnox: So, you seem to know what's going on, feel free to fix it.  Since it's your upload.
<infinity> xnox: *stare*
<xnox> infinity: avogadro please keep it as it is, as it's a nice reminder for me to get into C++ / GLES crap =)
<infinity> xnox: You'll probably find that fixing avogadro is pretty simple and doesn't actuallt require any C++, but sure.
<xnox> infinity: I was thinking to do +really-old-version-X.Y.Z upload =)
<xnox> for mongodb
<infinity> xnox: (First step will be not build-depending on libglew-dev on arm*, the second step will be fixing CMake to look for GLES as well as GL)
<infinity> xnox: I can just drop your mongodb from proposed, you don't need to do any ugly versioning.
<xnox> infinity: ok. thanks. (/me copies to the todo)
<infinity> xnox: Just upload a rebuild-only increment to release, if you want.
<xnox> infinity: yes please drop mongodb from proposed. that's the best.
<infinity> xnox: Done.
<Daviey> AHHHHHHHHH.. xnox, i hate +really :)
<xnox> infinity: player has implicit pointer conversion & the "let's parse our headers with a python script & regexp to generate swig bindings file, and rename all the functions and then compile swig binding" gave me a headacke
<xnox> so it has FTBFS on amd64
<Daviey> xnox: we had to do that for mysql a few releases ago.. made me cry
<xnox> Daviey: it's ok. it was uploaded to proposed and infinity dropped from proposed. So we are back to the previous revision without +really ;-)
<xnox> Daviey: it's ok. it was uploaded to proposed and infinity dropped *it* from proposed. So we are back to the previous revision without +really ;-)
<Daviey> \o/
<Laney> sucks to be the poor proposed users who got it :P
<xnox> Laney: it's unsupported unsupported pocket anyway, so who cares =)
<Daviey> Hmm, we do want to encourage proposed users.. not have them thinking they are running some dodgey PPA :)
<Laney> actually, the dev release -proposed is something we do /not/ want people to be using
 * Laney is trying to do something about this
<xnox> Laney: while you are here ;-) could you please chase up / sheppard an upload of nux?
<infinity> xnox: Eh?  What do you need a nux upload for?
<infinity> xnox: Was the one in proposed not shiny enough for you?
<xnox> the stuff in the bzr branch is fine. It's one of the last 10 packages holding boost1.46 in the archive & in main
<xnox> infinity: ooh, maybe the proposed one is shiny enough =)
<Laney> it just got uploaded
<xnox> great!
<Laney>  2.12.0-0ubuntu2 release, proposed (main) 10 minutes ago
<Laney> do keep up
 * xnox tracker is out of date ;-)
<Laney> the tracker doesn't look at proposed
<xnox> Laney: where is the new tracker? still on cjwatson overflow backlog?
<Laney> yeah
<xnox> ok.
<xnox> so everything is looking good.
<Laney> if you're boredâ¦
<Laney> â¦you can merge it up with trunk and see if it still works
 * xnox off to have Ð¿ÐµÐ»ÑÐ¼ÐµÐ½Ð¸
<xnox> dinner time ;-)
<Laney> we're missing a number of commits
<Laney> but I am aware there is at least one new dependency, so I'm avoiding it
<xnox> which branches with what? +junk with lp:tracker?
<xnox> lp:$project_name
<Laney> https://code.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/trunk
 * slangasek learns about pelmeni
<Laney> the upstream import
<Laney> merging with the to-be-deployed branch
<Laney> lp:ubuntu-transition-tracker, IIRC
<xnox> slangasek: dumplings with mean, which russians believe did *not* come from ukraine
<xnox> slangasek: dumplings with meat, which russians believe did *not* come from ukraine
<slangasek> heh
<xnox> slangasek: similar to perogies
<xnox> Laney: ok thanks.
<xnox> slangasek: what herritage is your last name?
 * Laney had ÐºÑÑÐ¸Ð½ÑÐ¹ ÑÐ°Ð»Ð°Ñ
<slangasek> xnox: ÄeskÃ½
<xnox> Laney: Ð¦ÐµÐ·Ð°ÑÑ?
<Laney> ÐÑÐ»Ð¾ Ð¾ÑÐµÐ½Ñ Ð²ÐºÑÑÐ½Ð¾.
 * Laney runs.
<infinity> You people and your funny alphabets.
<xnox> slangasek: ok. One of my friends from uni had a Czech father and a Slovak mother. It would wind her up if she heard "... so that makes you czechoslovak, right?!"
<slangasek> hahahaha
<slangasek> +1
<xnox> also grilled bagels with turkey patte =) nom nom
<cyphermox> slangasek, xnox: so, seems kind of similar to tortellinis?
<cyphermox> provided the filling is right and the shape, I guess
<xnox> cyphermox: kind of. they are bigger and the pastry is more bread like and less pasta like
<slangasek> cyphermox: don't ask me, they don't make those in Czechia :)
<cyphermox> xnox: very cool. /me takes a note to go out to find some east europian grocery store in Montreal sometime.
 * xnox UDS in Moscow, Russia =)
<infinity> Montreal probably has what you're looking for somewhere.  They do have a lot of delightful international cuisine.
<cyphermox> yeah, pretty sure. I walk past a slovakian butcher when I go to the office
<Laney> I was told that Russian visas for US and UK citizens mysteriously take a long time to get processed ...
<xnox> didn't get to see Montreal. Been to Nova Scotia though
<slangasek> Laney: yes, we're culturally inept at bribing officials ;)
<xnox> Laney: my house mate got it in 2 weeks time. but he used an online 'bribe' website which submits invintation letter to the embassy.
<xnox> the key is that for a russian visa is invitation letter from some company or person who (a) have a lot of income (b) will vouch and take responsibility for you
<xnox> it's doable, but hassle
<Laney> A French guy at uni is going to a summer school there, who were worried when they saw his UK email address
<xnox> you'd be surprised but russia has a large immigration problem, far worse than US/UK
<Laney> when they found out he was French it all became easier apparently :P
<xnox> russians love french
<xnox> half of our classical books are in half french - the language of aristocracy at the time.
 * xnox half of a half is a quarter
<xnox> infinity: can i copy stuff from -proposed to -release in the devel series or do I need magic AA cufflinks?
<slangasek> AA
<xnox> =(
<xnox> slangasek: but I do have AA road-side recovery membership!
<xnox> http://www.theaa.com/
<slangasek> that's one A short, around here
<infinity> Or a C short, here.
<Daviey> err.. Are you sure you need to be AA for that?
<infinity> I hope so.  Cause you can break things doing it.
<infinity> Like, archive things.
<xnox> oh, so *not* the British Automobile Association - the AA
 * xnox gotcha ;-)
<Daviey> infinity: what breakage are you expecting?
<xnox> Daviey: the same as we did, when there was no -proposed for the devel release
<infinity> Daviey: When things get copied before all arches are built and published, for instance, some things asplode.
<infinity> xnox: No, I mean actual archive/soyuz "oh, I didn't expect that" breakage.
<infinity> xnox: Not broken packages.
<Daviey> infinity: include_binaries= ?
<infinity> Daviey: include_binaries="stuffthathasn'tbuiltyet"?
<infinity> Daviey: Well done.
<Daviey> i highly suspect archive/soyuz expects this LP API behaviour, and i also suspect it works with not being an AA.
<infinity> I can't speak to the permissions, but I can tell you that you're wrong on the former point.
<infinity> Copying things around between pockets if the arches aren't in sync causes vaguely irreperable damage.
<infinity> (It can be fixed with some awful hackery, but.  Not fun)
<Daviey> infinity: if this is a real prospect, it needs to be better documented
<slangasek> where is it documented that anyone other than AAs should be copying packages between pockets?
<slangasek> or do you mean, documented for AAs?
<Daviey> slangasek: I agree the fact that you can, doesn't mean that you /should/.. but having a supported API call that allows non-AA's... sort of implies it's ok in my mind.
<Daviey> Therefore, if there is risk associated.. it should really be outlned
<slangasek> no, we should instead fix the acl
<slangasek> or fix the API to not allow buggy copying
<slangasek> instead of documenting it
<slangasek> but this is really cjwatson's turf :)
<Daviey> Sure.. I am interested in more detail of the potential risks here.
<xnox> fix the API is better, cause those who can upload into devel-release should also be able to copy from devel-proposed to devel-release
<xnox> instead of doing fake uploads ;-)
<Laney> I believe they can, and I believe that's what they are saying should not be possible
<Daviey> if there is not a published bianry, it won't copy it.. right?  So the worst case is surely that it's as if -proposed wasn;t used to stage in the first place, no?
<infinity> Daviey: No...
<infinity> Daviey: Because if proposed wasn't used to stage, you still have a build record in release.
<slangasek> xnox: I disagree; the whole point of having -proposed is to ensure archive installability, people should not be copying their own packages between pockets without coordination
<infinity> Daviey: And the binary will eventually show up, if it's not FTBFS because the source is broken.
<infinity> Daviey: Think dep-waits, slow buildd, etc.
<xnox> slangasek: ok. makes sense.
<Daviey> infinity: Well yes, but that really shouldn't be  vaguely irreperable damage.
<infinity> Daviey: And yet, it is.
<Laney> which binary upload wins?
<Daviey> Laney: the newer one will fail to upload.
<infinity> Daviey: Other than re-uploading a new source, or me copying the source BACK to the pocket it originated from.
<infinity> Daviey: And it has nothing to do with "which binary upload".  There will only be one.
<infinity> Daviey: And it won't work.
<infinity> Daviey: Cause it won't have source associated with it.
<Daviey> infinity: wait, why wouldn't it have a src?
<slangasek> because the process is copy to -release -> remove from -proposed
<infinity> Daviey: What he said.
<Daviey> Ah, well.. syncSource i don't think supports removing from the original
<Daviey> So.. it is clearly an issue
<ScottK> xnox: Also LP can't let devs copy from -proposed to -release in the development series without also allowing the same for all releases, which we definitely don't want (and fixing that is non-trivial according to our local launchpad developer, cjwatson).
<Laney> I understand the ACL of copyPackage to be the same as for normal uploading.
<Laney> (and the behaviour around stuff landing in queues)
<xnox> ScottK: Laney: ok thanks
<micahg> ScottK: that's not true, the dev release has different ACLs
<micahg> or rather a non-frozen release has different ACLs
<ScottK> True.
<ScottK> I guess I was thinking of distinguishing frozen from post-release.
<micahg> so, I can copy something to precise-release, but it'll land in unapproved like anything else I copy, but if I copy to quantal-release it'll go straight through
<Laney> Anyway it is the deleting part that makes this an AA-only task.
<micahg> AIUI at least
<slangasek> infinity: say, can I bother you to do NEW processing of sbsigntool?
<xnox> infinity: will you move avogadro from quantal-proposed to quantal-release or are you doing them in reverse alphabetical order? =))))
 * micahg would love some NEW/unapproved love for precise-backports when the AAs get a chance
<infinity> slangasek: Looking.
<slangasek> xnox: clearly avogadro's number hasn't come up yet
<infinity> xnox: It'll move when it moves.
<Daviey> Doesn't asking move it automatically to the bottom of the queue?
<xnox> ;)
<infinity> slangasek: Source and copyright look sane, fix the missing build-deps (pkg-config and openssl) and upload a new version, and I'm happy. :P
<slangasek> infinity: wat
<slangasek> openssl?
<infinity> Yeah.
<infinity> It calls it.
<slangasek> hmm
<slangasek> ok, let's fix
<infinity> openssl genrsa -out private-key.rsa 2048
<infinity> In the test suite.
<slangasek> infinity: reuploaded, same version number
<infinity> slangasek: Also fails with compilers that don't grok -m64
<infinity> slangasek: But I'm guessing that's less interesting to you.
<slangasek> infinity: it is currently less interesting to me, yes :)
<infinity> slangasek: Only in the testsuite, so easily fixed later.
 * infinity goes to find some lunch.
<dobey> can someone copy ubuntuone-client from quantal-proposed to quantal please?
<slangasek> hmmm, why did i386 build successfully?
<infinity> slangasek: Because i386's toolchain speaks -m64.  It just fails if you try to link to something it can't find.
<slangasek> dobey: infinity is working his way through the lot of them; I'd rather not jostle his elbow by getting in the middle now
<infinity> dobey: Already done, I just missed it on the first pass, eyes crossed. ;)
<slangasek> aha :)
<dobey> ah ok
<dobey> thanks
<infinity> slangasek: And you'll note it doesn't actually link anything (nostdlib).
<slangasek> infinity: right
<infinity> slangasek: I imagine jk made sure it worked on i386 after I ridiculued him for the previous i386 build failure I found. :P
<slangasek> I have no idea if he did or didn't
<infinity> Anyhow.  Late lunch and bank.  Back in a bit.
<slangasek> but it currently only handles signing of 64-bit PE files, so meh ;)
<slangasek> (I have half a patch here to correct that)
<cjwatson> So.  If you can upload to a suite, you can copy to it.  However, there are some restrictions on copying things like incompletely-built uploads.
<cjwatson> The restrictions amount to avoiding conflicts.
<infinity> Hahaha.  /usr/bin/ld: cannot represent machine `i386:x86-64'
<infinity> I guess fixing the -m64 thing doesn't get you anywhere in the testsuite. ;)
<cjwatson> One of the restrictions is that if there's already a needsbuild/building record in the archive you're copying to, or a built-but-not-published record, then you mayn't copy.
<cjwatson> Hm, actually, I'm not so sure about that.
<infinity> cjwatson: Sure, that doesn't fix the "copying something that isn't built on all arches yet" problem.
<infinity> cjwatson: Which, at last check, can only be fixed by copying the source back to the originating pocket, so the build can happen.
<cjwatson> Anyway, the answer is to improve the copy-conflict checker, not to forbid copies.
<cjwatson> Forbidding copies gets us back to the bad old days when archive admins had to do syncs.
<infinity> cjwatson: But we don't want to forbid copying incomplete sets, we want people to be forced to think about it.
<cjwatson> There's incomplete because stuff has failed, and incomplete because it isn't done yet.
<infinity> cjwatson: Failed isn't always failed.
<cjwatson> And if it's needsbuild, the build records can (in principle, not sure if Soyuz does this) be recreated for the new suite.
<infinity> cjwatson: (I just had to do two retries in proposed to fix two "failures")
<cjwatson> Anyway, what I'm working on at the moment is essentially moving everything over to new-style packagecopyjobs so that I can rip out a huge chunk of old copy code.
<infinity> Anyhow, when we move to using britney for this, it'll impose the "not built where it's built before" check anyway.
<cjwatson> Then the copy code might be approximately comprehensible and it will be more or less possible to improve it.
<cjwatson> (My current "remove delayed copies" branch removes well north of 1100 lines.)
<infinity> Though this issue still exists for SRUs and security, where people are mostly careful, but not always.
<cjwatson> Right.  But any situation where you can do something that breaks Soyuz (even if you're an AA) is a bug - the answer's usually to either fix it or forbid it selectively, not to lock down the operation
<cjwatson> And I think most of these situations are fixable
<infinity> Sure, that's the correct long-term answer, right now, I prefer asking people to be careful, which is easier with a smaller group of people.
<cjwatson> I don't even think it's desperately long-term.  If you can describe a copy bug in sufficient detail, I can very probably fix it in days.
<cjwatson> I'm pretty deep in the copy code right now.
<infinity> Well, the simple fix for this would be that a pocket copy of an incomplete set (and the reason for the incomplete really doesn't matter) should create build records in the target.
<cjwatson> Not quite that simple because you have to do something with existing builds too.
<infinity> cjwatson: What happens in the built-but-not-published state?
<cjwatson> You have to wait for publication.
<infinity> cjwatson: Do those get correctly copied, or missed?
<cjwatson> Forbidden.
<infinity> Kay, so that situation should just flat-out be forbidden.
<infinity> Which it isn't currently, I suspect.
<cjwatson> Which situation?
<infinity> proposed has builds ACCEPTED, and you try to copy source+binaries to another pocket.
<cjwatson> I believe that is forbidden.
<cjwatson>             if build_summary['status'] == BuildSetStatus.FULLYBUILT_PENDING:
<cjwatson>                 raise CannotCopy(
<cjwatson>                     "same version has unpublished binaries in the "
<infinity> Kay.  I guess I've never tried that, cause I know it's bad. ;)
<cjwatson>                     "destination archive for %s, please wait for them to be "
<cjwatson>                     "published before copying" %
<cjwatson>                     candidate.distroseries.displayname)
<infinity> Err.
<infinity> That error message sounds wrong.
<infinity> I can't speak to the code.
<cjwatson> This is lib/lp/soyuz/scripts/packagecopier.py:CopyChecker._checkArchiveConflicts, if you want to read through it.
<cjwatson> What's wrong with it?
<infinity> Unpublished binaries in the DESTINATION.  I'm talking about the source.
<cjwatson> Destination *archive*.
<infinity> Oh, right, I'm reading archive as pocket.
<cjwatson> I.e. sharing the same pool.
<infinity> Though, that then leads to the same issue for PPA->archive copies.
<micahg> infinity: I've gotten that error before when trying to copy to devel from $stable-security
<infinity> Which, I guess, is another kettle of... Whatever you put in kettles.
<cjwatson> It doesn't matter so much if the same source gets built twice for a PPA and an archive.
<cjwatson> In that case, you can have two .debs of the same name with different contents and who cares.
<cjwatson> Since they're in different pools.
<Daviey> cjwatson: The destination will have buildrecord for FTBFS/dep-wait scenarios, and satisfiable in -release to be given back if suitable, right?
<cjwatson> I think it's late.  I'm having trouble parsing that.
<infinity> Daviey: Currently, no, no new build records are automatically created.
<Daviey> i think it's late.  I had trouble typing that.
<infinity> (If that's what you were asking)
<cjwatson> infinity: Missing build records should be created in the destination.
<infinity> cjwatson: That's new then...
<cjwatson> (In fact, too many of them sometimes, because it doesn't honour P-a-s ...)
<infinity> cjwatson: Or, wait.  No, it might not be new, but it might not work.
 * infinity tries to remember.
<cjwatson> infinity: One of the confusions here is that missing builds are (I think) only created on the direct-copy path, not on the delayed-copy path.
<cjwatson> The delayed-copy path is what is currently used when copying private uploads to a public archive.
<Daviey> cjwatson: say, powerpc in -proposed are depwait or generally FTBFS.. But we are happy to copy to -release.. There is no reason that it wouldn't be treated as any other upload, 'rebuild button'.. right?
<cjwatson> I am getting rid of delayed copies to try to reduce the amount of stuff we have to follow.
<infinity> cjwatson: There was a case where some incomplete stuff was copied to updates, but tried to build against proposed, which failed miserably, cause the source wasn't in proposed anymore.
<infinity> cjwatson: And the "fix" was the copy the source back to proposed, retry, and copy back again.
<cjwatson> Daviey: It *should* get a new build record in release.
<Daviey> cjwatson: So, as a non AA.. What should happen about removing the publication from -proposed?
<infinity> Daviey: Anyhow.  Like I said above, when we move to doing the proposed->release stuff with britney for devel releases, you don't get to say "good enough" for new FTBFSes anyway. :P
<cjwatson> infinity: OK.  It would be worth trying that out on dogfood to see if it's still current.
<Daviey> infinity: we are moving to britney?
<infinity> Daviey: That's the plan.  I've been looking into it this week.
<cjwatson> Daviey: Non-AAs do nothing.  AAs periodically process pending-sru.html, which will list all such publications with cut-and-pasteable output for removal.
<cjwatson> Daviey: (You probably haven't noticed since I routinely process that a couple of times a day, and I may not be the only one.)
<infinity> You're not. :)
 * infinity does another batch.
<cjwatson> slangasek: installability/coordination> There's no point in forbidding copies when people can also simply upload directly.  The argument about coordination will make more sense when we get to the point where all uploads to quantal are automatically redirected to quantal-proposed.
 * skaet pays attention.
<slangasek> cjwatson: yes... though that's hopefully soon.  Anyway, fair point that this isn't policy that should live in the API then
<cjwatson> I haven't quite worked out how the permission model for that should look, but I guess it should have one ...
<cjwatson> I want delayed copies gone before we do that, otherwise my head really will explode. :-)
<slangasek> mmk :)
<cjwatson> Completely separate code path that does almost the same thing with subtly different semantics.  Honestly.
<cjwatson> It took me weeks to divine that it was mainly irrelevant and should die.
 * skaet has updated https://wiki.ubuntu.com/StableReleaseUpdates with the SRU team vanguards
<micahg> skaet: I think you mean RAOF instead of ROAF
 * skaet hugs micahg - thanks for catching that.
 * micahg wonders if the channel should have the AA and SRU vanguards in /topic
#ubuntu-release 2012-06-29
 * skaet thinks the channel topic is long enough, but is willing to have it added if others feel its important.
 * skaet --> EOD
<infinity> cjwatson: I'm sure you're asleep by now, but is there any reason why change-override no longer has any output to stdout?
<cjwatson> Erm.  It's supposed to.
<cjwatson> I wonder if I broke it.
<infinity> cjwatson: This just returns without doing anything (AFAICT)
<infinity> change-override -c universe cl-speech-dispatcher speech-dispatcher-doc-cs speech-dispatcher-festival speech-dispatcher-flite
 * cjwatson experiments.
<infinity> (Everything in i386 in that source landed in main, so there's an arch skew, I wonder if that relates?)
<micahg> infinity: in the mean time, can you poke precise for backports?
<cjwatson> Oh, hahaha
<infinity> Also, did someone make the NEW queue override handling worse than it used to be?
<cjwatson> Removed a *little* too much when moving stuff to a common module
<slangasek> skaet: vanguards> wasn't that supposed to be split out into a new page?
<slangasek> (http://wiki.ubuntu.com/SRUTeamProcess)
<infinity> Cause, my guess as to how the entire source landed in main is perhaps that someone NEWed its one new arch:all binary to main via the queue.  Which used to only act on the actually "new" binaries.
<cjwatson> Not aware that NEW override handling's been changed particularly.
<cjwatson> infinity: change-override r496 *cough*
<infinity> micahg: Sure.
<micahg> thanks
<skaet> slangasek,  yes, more to go onto that page though, and the 12.04.1 team was asking for pointers this morning, so I put it there for now.
 * skaet will move it.
<infinity> micahg: What am I poking?
<slangasek> skaet: ok
<micahg> infinity: NEW for 2 sources and unapproved for 1 (should all be at the top)
<infinity> True for the NEW ones anyway.
<micahg> infinity: jquery :)
<micahg> right, of course, people have the audacity to do work!
 * xnox ponders, how do archive admins 'process' their queue if https://bugs.launchpad.net/~ubuntu-archive/+subscribedbugs timesout
<infinity> Try harder until there's a hot cache of all the queries involved.
<infinity> And then curse people who write massive(ly inefficient) SQL-driven systems.
<cjwatson> xnox: lp-shell
<xnox> ok
<cjwatson> >>> ua = lp.people["ubuntu-archive"]
<cjwatson> >>> for task in ua.searchTasks():
<cjwatson> ...     print task.bug.id, task.bug.title
<xnox> cjwatson: can you merge aptitude or shall I upload the patch to fix FTBFS-gcc4.7, it's one of the last 7 packages in boost1.49 transition
<xnox> let me try that ;-)
<cjwatson> I told you, it's waiting for the pristine-tar xz fix
<xnox> sorry, forgot.
<cjwatson> Feel free to upload a non-merge patch in advance of that if you prefer
<xnox> ok. thanks. will do.
<infinity> cjwatson: Oh, haha.  I just read your change-override diff.
<infinity> cjwatson: Oops.
<cjwatson> Yeah, slightly aggressive refactoring
<micahg> and last thing keeping boost1.46 in main :)
<micahg> xnox: mpi-source can go now FWIW
<cjwatson> skaet: I can auto-sync again, yes?
<skaet> cjwatson,  auto-sync is good
<cjwatson> Cool
<xnox> micahg: true. but I wanted one bug and get rid of them together and not bother archive admins to much. or shall I split it...
<micahg> xnox: nah, don't need to split
<xnox> micahg: ok, one confirmed the other one incomplete?
<micahg> yeah, sounds good
<infinity> micahg: Can "go" as in "removed", or "to universe"?
<infinity> Cause the latter, we get told about without bugs.
<infinity> But I'm all for removing stuff. ;)
<micahg> infinity: the mpi-source has no more dependencies AFAICT
<micahg> the 1.46 mpi source that is :)
<infinity> Full source name?
<micahg> boost-mpi-source1.46
<micahg> bug #1019090
<ubot2> Launchpad bug 1019090 in boost-mpi-source1.46 "Please remove boost1.46 from Quantal" [Low,Confirmed] https://launchpad.net/bugs/1019090
<infinity> Removed.
<xnox> infinity: bug 1019096
<ubot2> Launchpad bug 1019096 in mongodb "please remove 1:2.0.4-1ubuntu2 mongodb armel only binaries from quantal" [Undecided,Confirmed] https://launchpad.net/bugs/1019096
<micahg> xnox: why would you do that?
<infinity> xnox: Erm, are you sure about that?
<infinity> xnox: Is this gcc 64-bit atomics?
<xnox> discussed with doko and folks from #linaro
<infinity> xnox: If so, it's waiting on a buildd kernel upgrade and it'll magically work again.
<xnox> current quantal gcc toolchain for armel does not define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
<xnox> is that the same?
<xnox> i'll check with doko again then.
<xnox> infinity: how would I find out about buildd kernel upgrades and things that will magically start working again?
<infinity> That should be defined...
<infinity> Since GCC uses software-driven atomics on older CPUs.
<infinity> I thought.
<infinity> Maybe I'm getting two issues confused.
<xnox> doko> xnox, pm215, ramana: it's only defined for armv7. armel in quantal is armv5
<xnox> <ramana> doko, that's bizarre. The sync primitives should be supported irrespective of the level of the architecture.
<xnox> <ramana> doko, on armv5 the sync primitives end up calling the kernel helper functions.
<xnox> <xnox> doko: i will leave the said package FTBFS on armel as a hint that it's a TODO item
<infinity> Yeah, exactly what ramana said.
<infinity> If it's not defined, that's probably a toolchain bug.
<xnox> so.... should I file a bug about it... or do you think doko got the hint from ramana?
<infinity> File a GCC bug and quote your IRC log there.
<infinity> Cause we have full GCC atomic support (with kernel helpers) and all ARM targets.
<infinity> Or, all the ones we care about.
<infinity> Though they won't *work* on armel until we upgrade the buildd kernels. :P
<infinity> But that's only an issue for testsuites and builds that run their own code.
<infinity> Since it compiles correctly, and runs in quantal just fine.
<xnox> ok
<xnox> mongodb does run their own code as smoke test.
<xnox> not going to disable the testsuite
<infinity> Sure, so it'll fail anyway, even with a fixed compiler, but we know the solution to that, and it's being worked on.
<infinity> Removing arches isn't the answer, fixing the bugs is.
<xnox> <doko> ramana, but gcc -march=armv5 -E -dM - </dev/null|grep SYNC
<xnox> prints nothing
<xnox> infinity: filed as bug 1019098
<ubot2> Launchpad bug 1019098 in mongodb "armel quantal please define sync primitives" [Undecided,Confirmed] https://launchpad.net/bugs/1019098
<xnox> helpful, it is against gcc-4.7 package as well
<infinity> xnox: Make sure some Linaro GCC hackers have it on their radar. :P
<infinity> xnox: If you've been talking to some.
<xnox> ok :P
<infinity> Michael Hope would be a good choice, if he's jumped into the conversation.
<infinity> He'll probably know straight up if it's a bug or a feature, and what to do about it.
<xnox> matthias vs linaro team
<infinity> (michaelh on IRC)
<xnox> ok, thanks.
<xnox> may I name you as a referral?
<infinity> Sure. :P
<infinity> He can hit me at the next Connect.
<infinity> It'll be grand.
<xnox> about pyopencl see bug 763457 as well
<ubot2> Launchpad bug 763457 in nvidia-graphics-drivers "please provide opencl-icd virtual package" [Medium,Confirmed] https://launchpad.net/bugs/763457
<cjwatson> zul: Rejecting one of the two python-cinderclient uploads in NEW while I look over the other one
 * ogra_ wonders if we cant do better than sending mails twice to -changes for every package that moved from $dev-proposed to $dev
<ogra_> especially since they are all signed by the same person now
<cjwatson> Yes, we probably can
<cjwatson> At some point
<ogra_> heh
<Daviey> ogra_: distributed procmail rules? :)
<ogra_> Daviey, well, i think we should fix that at the source :) save bytes !!
<ogra_> hmm, are live builds still on manual ?
<jibel> stgraber, quantal dailies have not been published to the tracker
<Daviey> jibel: I think i know why that is...
<Daviey> Hmm, i do not.
<Daviey> they should have been..
<stgraber> jibel: let me check quickly
<stgraber> /srv/cdimage.ubuntu.com/bin/post-qa: 95: /srv/cdimage.ubuntu.com/ubuntu-archive-tools/post-image-to-iso-tracker.py: not found
<stgraber> looks like Colin broke the script ;)
 * stgraber fixes
<stgraber> jibel: can you manually post them? or balloons? I don't see an easy way for me to rerun that part automatically
<stgraber> Daviey: fixed (FYI, that kind of failure typically gets logged at the end of the cd-build-log)
<Daviey> stgraber: thanks
<stgraber> cjwatson: I update post-qa after the rename of post-image-to-iso-tracker.py to post-image-to-iso-tracker (noticed when we got no daily on the tracker today ;)), are you aware of any other script that should be updated?
<stgraber> *updated
<jibel> stgraber, thanks you
<jibel> balloons, can you do the update ?
<cjwatson> stgraber: Oh, thanks, good point
<cjwatson> stgraber: I updated all the ones I remembered about ...
<ScottK> I just accepted a new SRU for bzr that fixes a regression from their microversion update.  Since this is a targeted change to fix a regression in a previous SRU, how long to we let it bake after verification before copying to -updates?
<skaet> ScottK,  good question.   Standard 7 days doesn't quite seem appropriate, since its a fix for a regression on an SRU.   How well validated is it?
<ScottK> None yet.  It's still building.  I just accepted it.
<xnox> skaet: it's a revert of affending patch. Such that the original 2 bugs that the patch was fixing should now be reopened for an SRU again.
<skaet> xnox,  good point,  we don't want to overlook that.
<ScottK> jelmer already reopened the original bug.
<skaet> ScottK,  once the fix is validated, and the original bugs are reopened,  we should probably get it released rather than waiting for the bake in period.   Only caveat, is with the holiday's approaching next week,  this sort of thing should be on Monday though, since coverage may be light for a good part of next week.
<skaet> (since we don't usually do it on Fridays)
<slangasek> ScottK, skaet: I would publish it as soon as it's been spot-tested and confirmed to fix the stated issue
<slangasek> Friday or not
<ScottK> Makes sense to me.
<skaet> slangasek, ok
<ScottK> It's built on i386.  I can test it.
<ScottK> Works.
<ScottK> slangasek: I verified it, so once it finishes building, I'll release it.
<slangasek> ScottK: sounds good
<Daviey> ScottK: If you accept it today, are you happy to be on point for (unlikely) regressions over the weekend?
<ScottK> Daviey: I'm always happy to deal with problems when I'm around.
<ScottK> (I don't think SRU team people in particular or developers in general should only worry about such significant issues like release regressions during certain hours).
<Daviey> ScottK: right.. the reason i ask is that in previous cycles there have been regressions introduced by SRU's over the weekend.. with nobody with access to deal with it.
<Daviey> squid was a good example
<Daviey> (Which is why i pushed for no SRU's on Friday's :)
<cjwatson> Access should be less of a problem these days
<cjwatson> Back then only Canonical employees could publish updates
<cjwatson> MIR team folks: would anyone object to me moving fonts-lklug-sinhala, fonts-sil-nuosusil, and fonts-ukij-uyghur to main without MIRs?  They're all installed by language-selector for various languages, and in particular moving fonts-lklug-sinhala to main is required to fix bug 1015483
<ubot2> Launchpad bug 1015483 in ubuntu-meta "ubiquity-dm: 2 language names wrongly displayed (missing font?)" [High,In progress] https://launchpad.net/bugs/1015483
<slangasek> mksh MIR> wtf
<infinity> cjwatson: I don't think anything more than a verbal "yeah, go for it" is required for font packages, as long as they're simple and (hopefully) unmodified from Debian so there's no maintenance burden.
<cjwatson> infinity: We have a few that are modified for "squeeze more into desktop" reasons, but these aren't among them.
<cjwatson> infinity: So is that a verbal "yeah, go for it"? :-)
<infinity> cjwatson: Yeah.  Go for it. :P
<cjwatson> Great, thanks.
<infinity> If we find a security bug in a font tomorrow, I'll be a sad panda.
<cjwatson> Oh, promoted the udebs and transitionals and such by mistake.  I'll demote them later.
<cjwatson> (Can't remember if rapid promotions/demotions are still a problem ...)
<infinity> I *think* it gets it right now, but I don't remember...
<infinity> And I always take the paranoid approach and wait a cycle.
 * slangasek works on kicking pdksh out of main
<infinity> We probably should sort out, one day, how much of our residual paranoia can go away, and what bugs still need fixing. :P
<cjwatson> Kind of what I've been doing :-)
<cjwatson> Ish
<infinity> slangasek: But, but, I'm sure it's the prefered shell for 1 in 20000 users.
<slangasek> infinity: that has nothing to do with why it's in main
<infinity> slangasek: rbuild-dep was my assumption, I hadn't looked yet.
<slangasek> yep
<slangasek> *spurious* rbuild-dep
<slangasek> wtf people
<cjwatson> You filed bug 180218, but I'm not entirely sure that's it.
<ubot2> Launchpad bug 180218 in launchpad "override mismatch race needs to be fixed" [High,Triaged] https://launchpad.net/bugs/180218
<cjwatson> stgraber: Testing a fix for livecd-rootfs and -proposed now
<cjwatson> I guess I'll need to SRU that in order to get it into the livefs build chroots
<cjwatson> infinity: You don't happen to know whether the livefs build chroots can get livecd-rootfs installed from -proposed, do you?
<cjwatson> It would save time.
<infinity> cjwatson: I'm sure it could be arranged.
<cjwatson> Can you do it or do I need to ask some bit of IS?
<infinity> cjwatson: But We could also just fast-track an SRU.
<cjwatson> I need to get an updated BuildLiveCD put in place anyway.
<cjwatson> infinity: Which raises the secondary question of whether the livefs build chroots have -updates switched on :-)
<infinity> cjwatson: It's a webops-ish thing.  And be sure to mention the BuildLiveCD thing explicitly, they need to jam that into puppet and let is propagate.
<infinity> cjwatson: I *think* we made sure they had updates on a while ago.  But memory's failing in my old age, and maybe that wasn't for precise.
<infinity> s/let is/let it/
<cjwatson> If this test build looks good then I might see if I can get somebody to do it for me before the week dies.
<cjwatson> Assuming I'm not dragged off for evening stuff before then.
<cjwatson> (I kind of promised stgraber/jibel it'd be done before EOW)
<stgraber> cjwatson: long weekend here, so I won't notice until Tuesday at least ;)
<infinity> stgraber: Oh hey, Canada Day is upon us, I hadn't even noticed.
<infinity> stgraber: Also, you're in Quebec.  You can't celebrate Canada Day.  Get your own holidays (of which you appear to have many).
<stgraber> infinity: well, it's your fault for not having Alberta day ;) I'm quite enjoying having two long weekends in a row, the Edubuntu todo list is getting much shorter thanks to that
<highvoltage> it will be my 3rd long weekend in a row.
<slangasek> oh bah, of course the things that use pdksh are using it under the name ksh, not pdksh
<slangasek> so yeah, not so spurious :(
<cjwatson> What on earth do things still need ksh for in this day and age?
<cjwatson> And are they all maintained by the mksh maintainer? :-)
<infinity> People actually script in ksh?
<slangasek> graphviz, shunit2 both reference ksh
<ScottK> bzr's out.
<slangasek> as to why, well...
<slangasek> ScottK: cheers
<infinity> Is it 1978?  Did I sleep on the wrong side of my flux capacitor?
<slangasek> infinity: so entertainingly, if you don't have pdksh the only part of graphviz that doesn't build is the ruby bindings
<infinity> slangasek: That seems like an acceptable sacrifice. :P
<infinity> slangasek: (But surely, the offending bit can be rewritten in POSIX sh instead)
 * slangasek hands infinity the knife
<infinity> slangasek: Like, with nearly zero effort.
<slangasek> more effort than I'm putting in today
<cjwatson> Riddelll: Hm, so do you know why Kubuntu currently has both kdm and lightdm installed?
<slangasek> let the MIR team sort it out :P
<infinity> Well, I have no issues with swapping pdksh and mksh in main and letting the status quo continue for Right Now, but fixing the rbuild-deps seems generally sane anyway.
<cjwatson> Riddelll: That's what's breaking ubiquity-dm - it's "start on (starting kdm or starting lightdm)" (among other things).  The lightdm job starts but does nothing because it isn't the default DM, but that's enough to let ubiquity start just after kdm starts, and then fail because kdm has already managed to start an X server.
 * infinity wonders if the ksh dependency is/was perhaps a bizarre side-effect of Sun's /bin/sh sucking so hard that they had to pick something else to be "cross-platform".
<infinity> It's amazing how many things in the UNIX world I can blame on Sun's /bin/sh, if I put my mind to it.
<slangasek> lamont: postfix decided to stop resolving names, your package is making my bug reports late for the Debian freeze :P
<ScottK> But since you can't report the bug on postfix, it seems like a fine situation for lamont.
<ScottK> cjwatson: I was busy with work this week, so I'm not sure, but I suspect Kubuntu is accidentally half-switched.  I believe there's an intent to switch.
<slangasek> ScottK: restarting postfix fixed it
<slangasek> which seems to imply it's well named
<ScottK> Meh.  No fun.
<cjwatson> ScottK: Right, if the job gets finished then I think this will stop being a problem.
<cjwatson> It's not ideal that it has this result, but it's pretty hard to fix.
 * ScottK wonders where Riddelll is today?
<cyphermox> hey; I'd like to use quantal-proposed to start the transition of evolution-data-server without making too many things uninstallable; is there any more coordination I should do than letting the release team know? ;)
<infinity> cyphermox: That's good enough for me.
<infinity> cyphermox: (Didn't we just break e-d-s two weeks ago?)
<cyphermox> (yes we did)
<cyphermox> infinity: ok. then that's a head's up to not take e-d-s from -proposed to -release just now, once I upload it
<micahg> cyphermox: please coordinate with chrisccoulson for thunderbird
<cyphermox> micahg: yes
<cyphermox> might just end up being monday or tuesday
<infinity> cyphermox: If you start it today, helpful community types (like me, with a different coloured hat) just may finish the transition for you.
<infinity> cyphermox: Well, with the possible exception of thunderbird.
<cyphermox> right, but I'm a little worried about breaking too many things on a friday afternoon
<infinity> Breaking things in proposed is entirely acceptable.
<infinity> FSVO "break".
<cyphermox> and I'm working on setting up the transition tracker locally to see what I'm doing along the way, too
<cyphermox> e.g. teaching it clumsily to care about proposed
<Laney> We need to teach the deployed instance to do this too. It amounts to catting the Packages/Sources files together and doing away with the in-ben download step, as cyphermox tested. :-)
<cyphermox> Laney: I'll have a script for you in a minute
<Laney> get cjwatson to give you the cron script and hack it into that :P
<cyphermox> I guess
<cyphermox> infinity: also, I was trying to ask chrisccoulson about thunderbird, hence why I said monday or tueday, when he's aware of my plan
<infinity> cyphermox: Fair enough.
<Laney> Looks like ubuntu-archive@lillypilly already has a mirror, so that's easier
<infinity> Laney: If by mirror, you mean the real thing.
<Laney> it's called mirror.
<Laney> /home/ubuntu-archive/mirror/ubuntu/dists/quantal/
<infinity> Oh, you mean the mirror of the archive.
<infinity> I thought you meant a "mirror" of the tracker.
<Laney> a mirror to check it's hair is OK today
<Laney> its
<Laney> I know the tracker lives there â that's why I was checking for a mirror :-)
<infinity> Yeah, yeah.  I'll stop being "helpful". ;)
<cyphermox> Laney: so I checked with zlib, it does seem like when you cat -proposed over -release, the -proposed version is the one that gets tracked
<Laney> cyphermox: yay
#ubuntu-release 2012-06-30
<infinity> Aww, crap, jumped the gun on the armel mass-give-back, mono isn't published yet.
<infinity> Curses.
<cjwatson> Disable all the armel builders until it is?
<infinity> Just did. :P
<infinity> Still, yay mono on armel.
<infinity> Just need to fix ghc this weekend, and the port's officially unbroken.
<infinity> Also, boost1.50 transition anyone? :)
<infinity> Hrm, so much for unbroken.  Looks like "gprbuild", whatever that is, hangs on armel.
<cjwatson> infinity: ^- care to have a look at that livecd-rootfs SRU?  I've filed an RT ticket to have BuildLiveCD upgraded
<infinity> cjwatson: Already looking.
<cjwatson> Goody
<cjwatson> I think I'll go back to bed :-)
<infinity> Enjoy.
<infinity> cjwatson: That seems a bit clunky.
 * infinity guesses there's no saner way to do this without invasively patching live-build.
<infinity> cjwatson: I'd probably be more inclined to add a sub-case to the LB_VOLATILE stuff in live-build and teach it about proposed.  But that's certainly more invasive for an SRU.  This should DTRT, I guess.
<infinity> cjwatson: You also didn't update BuildLiveCD to match, but I guess that's in the quantal package?
 * infinity looks.
<infinity> cjwatson: Accepted.  For the record, I think we should fix it differently in quantal, and I may commit a different set of fixes there later and push the live-build half to Debian.
<infinity> cjwatson: But your patch was far less invasive than what I think is the "right" fix.
<cjwatson> infinity: Right, it is kind of clunky.  I didn't trust myself to figure out how to extend the seventeen thousand places -updates is handled on a Friday evening / Saturday morning.  And yes, I didn't bother to do the BuildLiveCD update in precise.
<cjwatson> infinity: You're probably right in the longer term.
 * infinity decides that Colin waking up -- for the second time -- must be a sign that it's bed time in Canada.
<infinity> cjwatson: FYI, sigbin is the first (and only) Panda buildd running precise.  If you happen to know of something that explodes with cryptic messages about kernels too old and such, aim them there.
<infinity> (We should get the rest reinstalled with some level of automation next week)
<cjwatson> OK, not offhand but cool
<cjwatson> BTW I whined at #ca-internal about the software-center regression that's breaking builds
<cjwatson> https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/1019535
<ubot2> Ubuntu bug 1019535 in software-center "apt-xapian-index plugin broken with software-center 5.3.3; breaks quantal image builds" [Critical,New]
<slangasek> cjwatson: from what I can see, our hybrid ISOs don't have a GPT on them, right?  That being the case, what's the best (simplest) way for me to get an EFI-bootable USB stick?
<cjwatson> slangasek: hm, yes, at the moment we do EFI booting by way of multiple ISO9660 catalogs, which probably isn't very hybrid-friendly ... I guess we're going to need more Garrett magic, but in the meantime, I think you'll have to create a GPT by hand plus an EFI System Partition with a FAT filesystem on it, and put the loader in /EFI/BOOT/BOOTx64.EFI in that
#ubuntu-release 2012-07-01
<slangasek> cjwatson: yeah, that's what I wound up doing for this pass.  Is there some known Garrett magic for gpt-efi-hybridization?  I guess this requires sticking another partition on the end of the ISO?
<infinity> slangasek: Matthew's magic is all public (or mostly so?) AFAIK, but public doesn't necessarily make it "known". :P
#ubuntu-release 2013-06-24
<darkxst> we (Ubuntu GNOME) would like to opt-in for alpha1, what needs to be done for this to happen?
<tjaalton> any archive admin; pleae accept the uploads of mesa*, xserver-xorg-video-intel* to fix bug #1175533
<ubot2> Launchpad bug 1175533 in linux (Ubuntu Quantal) "[HSW] intel VGA driver i915 doesn't support new haswell graphics [8086:0a2e] " [Critical,In progress] https://launchpad.net/bugs/1175533
<tjaalton> the kernle & libdrm bits are there already
<tjaalton> *kernel
<cjwatson> I've temporarily sync-blacklisted the packagekit transition by request of jbicha (23:42 UTC above)
<cjwatson> Now, time to debug why force-autopkgtest isn't working
<infinity> cjwatson: Oh, if you're going to make the linux stuff get all forcey, let me upload d-i.
<infinity> cjwatson: Uploaded.  When you get the whole mess to migrate, don't forget to change the seeds.
<cjwatson> infinity: I tried forcing the autopkgtest bit of it at the weekend, but it didn't take for some reason
 * cjwatson nods
<infinity> cjwatson: And now that d-i/linux migration is way less predictable due to autopkgtest delays, I think it's time for my next upload to implement that hack I was going to do to make the seeds not need ABI knowledge.
<infinity> I'll do that after I've slept.
<cjwatson> Ah, there, I think it was just a hint permission bug
<cjwatson> jibel: Can you make out from your end why http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html still shows "autopkgtest for linux 3.9.0.7.8: RUNNING" in a few places?
<infinity> cjwatson: It got stuck due to linux's autopkgtest having a broken Depends:
<infinity> cjwatson: I think Andy's fixing that in the next upload, but it won't get unstuck on the current version unless jibel works some magic.
<cjwatson> infinity: Right, but shouldn't that have ended up as FAIL or something?
<infinity> cjwatson: Possibly, yeah.
 * cjwatson commits a bit more logging
<cjwatson> And forcing linux-signed/3.9.0-7.15
<cjwatson> ScottK: Curious about the kde4libs block; wouldn't proposed-migration's standard "wait until everything has built" have been enough there?
<cjwatson> Not that it's a huge problem if you're keeping an eye on it, I was just curious
<didrocks> infinity: hem, I don't even dare to ask more, but do you think you will have time for the unity SRU in raring? :)
<infinity> didrocks: Yeahp, can you bug me in ~6h? :)
<didrocks> infinity: will do :)
<jibel> cjwatson, correct, it should be marked as FAIL even if it timed out or in that case what adt-run considers an invalid 'Depends' field. I'll check what happened
<Laney> Lots of other tests seem to be stuck at RUNNING too
<Laney> e.g. the ones triggered by glib2.0
<cjwatson> Yeah, it'd be helpful to know which end of the channel this bug is at
 * Laney nods
<ScottK> cjwatson:  No.  I put it there so that it wouldn't migrate until the rest of the release was built (kde4libs could, in theory migrate as soon as it's built on all archs since it doesn't cause the older KDE packages to become uninstallable.
<ScottK> Not that it matters much since armhf is broken.
<ScottK> cjwatson: I did a lot of New processing for KDE package splits over the weekend (not quite done, but close).  Would you please re-run the packageset script.
<cjwatson> Yikes, it's been a while since I ran that.  It seems to want to put unity* into the Kubuntu packageset, which seems slightly odd
<ogra_> it's all about unification :)
<cjwatson> I think it's all about a seed bug.  Let me see ...
<doko> cjwatson, is the libreoffice autopkgtest failure still blocking migrations?
<cjwatson> doko: I was waiting for jibel to tell me if there was a problem at the Jenkins end before looking into that kind of thing
<cjwatson> (Because as far as proposed-migration is concerned the libreoffice test is still "RUNNING")
<Laney> I did poke Sweetshark about that failing this morning
<jibel> cjwatson, I found that the job that consumes test requests had been disabled, probably for a maintenance of the server last Saturday, and not re-enabled. I ran the script manually and that triggered tests for http://paste.ubuntu.com/5795363/
<jibel> I'm waiting for the admin to show up before re-enabling that cron job
<cjwatson> jibel: Ah, that looks relevant, thanks
<cjwatson> Hm, I should make force-autopkgtest operate on the tested package rather than on the triggering package
<jibel> as I don't know why it has been disabled in the first place
<cjwatson> (force-autopkgtest> done)
<cjwatson> ScottK: OK, fixed up seeds at least somewhat, and refreshed the packageset
<mlankhorst> can someone delete xorg-server in raring NEW? it will cause a regression in its current state
<Riddell> I think I'll force kde4libs into -release, it's currently blocked on arm but I don't see that getting fixed in time for alpha 1
<Riddell> also calligra and qtwebkit are the same
<cjwatson> Riddell: Will that render things above it uninstallable?
<smartboyhw> Riddell, and rekonq?:P
<Riddell> cjwatson: on arm but we can live without that for alpha 1
<cjwatson> smartboyhw: rekonq is collateral damage rather than failing in its own right
<cjwatson> Riddell: Hm, that will unfortunately make proposed-migration much more tolerant of mistakes
<cjwatson> There's a BIG stack behind kde4libs
<cjwatson> You're free to if you want but it's very unfortunate.
<cjwatson> Re auto-sync and possibly re-enabling it tomorrow morning; I assume we're just using a migration block for alpha 1, rather than disabling auto-sync and freezing harder?
<cjwatson> (unfortunate> as in, if it were me, I would prefer to hold kde4libs out of the saucy release pocket until it's been fixed on ARM)
<Laney> Is proposed-migration right to say that pango1.0's autopkgtest is still running? Looks like it completed a few hours ago.
<Laney> Also, shouldn't it be blocking on the failed LO test?
<Laney> it/glib2.0 & co
<seb128> infinity, did you get pinged again about the raring unity SRU? ;-)
<seb128> slangasek, ^ if you feel like doing some SRU work? (would be really good to unblock those fixes after > 1 month)
<infinity> seb128: Just now, by you. :)
<infinity> seb128: I'll get to it all today (I'll start on it now).
<slangasek> ok
<seb128> infinity, you are saying that for 1.5 weeks :p
<infinity> That's not true. :P
<seb128> don't make me grab my IRC logs ;-)
<seb128> infinity, thanks for looking at it today ;-)
<infinity> Last week was a mess, though.  I'll admit to that.
<slangasek> hey, the package has only been in the queue for 5 days, not 1.5 weeks ;)
<slangasek> infinity: a lot of treading water last week? ;p
<seb128> slangasek, right, because infinity looked at it a week ago and rejected the previous ones, because the original sources from the ppa expired
<infinity> slangasek: Hospital scares at the beginning of the week and then, yes, lots of floating away.
<infinity> slangasek: I'm fine, but friends and family aren't so lucky, and I've been running around helping.
<seb128> :-(
<seb128> infinity, hope things get better for your friends/family!
<infinity> seb128: Well, no one lost more than stuff.  Stuff's replaceable, though pricey.  Just lots of cleanup and cost evaluations and rebuilding and such.
<balloons> is kate the release manager for alpha1?
<infinity> There is no release manager, so no?
<balloons> infinity, ahh.. well I'm asking who is setting up the milestone on the tracker and managing builds
<infinity> balloons: stgraber, most likely.
<balloons> is stephane doing it all? ATM there is no milestone
<balloons> trying not to ping him on his holiday :-)
<infinity> balloons: It's a public holiday in Quebec, I assume he intends to get to it tomorrow.
<infinity> balloons: It all needs some love from him specifically anyway, since he's trialling the "flavours get to request rebuilds via the UI" bits.
<stgraber> balloons: I'll be managing builds, will also take care of the tracker, though I only plan to do that once the first flavour says they're ready and want to get a1 builds
<balloons> stgraber, I think lubuntu is chomping at the bits to get some builds (at least the testing side is, heh). Just wanted to confirm who was going to manage it so I could direct them properly
<balloons> ty stgraber and infinity
<Riddell> cjwatson: I'm trying to force kde4libs into -release but it seems to need something more than the single force line, do you know what?
<Riddell> will it need every kde app forced?
<cjwatson> Making the uninstallable count worse needs force-hint rather than force ...
<cjwatson> (possibly as well as)
<cjwatson> I'm still very concerned that this will destabilise proposed-migration in general, but hey
<cjwatson> 630 uninst, grief
<cjwatson> I hope you know what you're doing
<phillw> bdmurray: do you have 5 mins for a quick PM before the bugs section of ubuntu-clasroom start?
<ScottK>  cjwatson: thanks for the packageset refresh.
<ScottK> cjwatson: re forcing kde4libs - it's the victim of a gcc issue. there's not much between forcing it and skip Alpha 1.
<infinity> ScottK: Or do A1 with what's in the release pocket.  Or build kubuntu A1 against proposed.
<cjwatson> Riddell,ScottK: Just to confirm, are you OK with re-enabling auto-sync tomorrow morning as discussed on ubuntu-release, and relying on a migration block for your alpha needs?
<ScottK> what's in the release pocket isn't much different than raring
<Riddell> cjwatson: yep
<ScottK> cjwatson: I'm in favor of it.
<cjwatson> OK, thanks
<cjwatson> Will you folks either put the block in place before tomorrow morning (my time), then, or else drop me a mail with the correct block line(s)?
<Laney> ScottK: Maybe you could build it with gcc-4.7?
<Laney> (on armhf)
<infinity> Laney: That certainly would be a valid option.
<ScottK> good idea
<infinity> I do share Colin's concern about raising the uninstallables count so high that britney becomes much less effective for a while.
<Laney> Can you educate me as to the problem there? I don't think I understand how britney works in that regard.
<infinity> Well, britney's job is to make sure nothing gets worse after a migration.
<infinity> If things are already hideously broken, then you can introduce new breakage as long as you fix the same number of other breakages at the same time.
<infinity> Which isn't an ideal situation.
<infinity> Ideally, you want the release pocket to be in a "not broken" state, rather than an "as broken as before" state.
<infinity> But if you force something that causes hundreds of uninstallables, you have to be pretty careful to unwind the whole mess again, rather than spending the next month trading one break for another.
<Laney> So it gives you room to trade off breakage. I thought it just didn't allow you to break new things.
<Riddell> Laney: calligra is built with gcc 4.7 (cos you made it so) and it seems to have the same ICE
<infinity> Technically, it doesn't allow you to break new things, but when the case is that "everything that depends on Qt" is broken, that's a lot of wiggle room. :P
<infinity> s/Qt/kde4libs/
<Laney> Riddell: Actually I fat fingered that calligra change when I did it but we got away with it at the time
<Riddell> infinity: it seems to be either this or not do alpha 1 and I'd like to do an alpha
<Riddell> Laney: how do you mean?
<Laney> I set one of the wrong environment variables
<Riddell> export CXX=g++-4.7
<Riddell> that one?
<infinity> That only matters if the build calls CC at any point.
<infinity> Riddell: No, the one above, which should have been CC, not CPP.
<Laney> I think I set CPP instead of CC
<Laney> yeah.
<infinity> Anyhow, I don't see an ICE on calligra...
<infinity> /build/buildd/calligra-2.6.92/krita/image/kis_filter_weights_applicator.h:305:26: error: conversion from 'double' to 'const KisFixedPoint' is ambiguous
<infinity> Just a straight up error.
<infinity> Guessing a qreal-ish porting issue?
<Riddell> hum, I'm sure I remember seeing an ICE before
<infinity> Hrm, doesn't take kde4libs too long to fail on a Panda.  I'll test it with gcc-4.7 here.
<infinity> Erm, wait.  Did people retry kde4libs?
<infinity> "The bug is not reproducible, so it is likely a hardware or OS problem."
<infinity> That means gcc tried again and succeeded the second time, and maybe the Panda was just sad.
<ScottK> about 142 bazillion times
<infinity> Heh.  Alright.
<infinity> I'll try it with 4.7 here.
<ScottK> I even put the armhf buildds on manual briefly to make sure I retried it on each type of builder.  Failed on them all.
<infinity> Every time I test build on my Panda, I kick myself for not having spent the previous weekend reinstalling my mx6...
<infinity> ScottK: Each type?  There's only two, and they're basically the same.
<infinity> ScottK: Anyhow, if this test build passes here, I'll upload ASAP.
<ScottK> couldn't tell if it was two or three based on how they're listed.  in any case,  I hit a variety to be sure.
<infinity> But as for calligra, it's a straight up porting issue, not a GCC thing.
<ScottK> thanks
<infinity> (And this is another unfortunate problem with hinting away arch problems, people tend to start seeing the same problem everywhere and getting hint happy)
<infinity> The old "if all you have is a hammer" adage.
#ubuntu-release 2013-06-25
<infinity> Oh look.  Linux 3.10.
<infinity> apw: ^-- I'm assuming no one minds if we don't let that migrate until after the alpha?
<bjf> c'mon, what could go wrong?
<infinity> bjf: Nothing, the kernel team is perfect, and a beacon of light and hope to the world.
<bjf> infinity, exactly, we exhaustively tested it, there are no bugs in it
<infinity> bjf: Oh, if there are no bugs, then that's cool.
<bjf> but then, i only care about stable :-)
<didrocks> thanks a lot infinity :)
<apw> it seems rtg's upload yesterday missed the fix for the autopkgtest definitin
<apw> definition, should i fix and re-upload or shall we 'ignore' it as previously
<infinity> apw: That's okay, I wasn't planning on letting it migrate anyway, unless you really want to disrupt alpha1 with a brand new upstream.
<apw> infinity, heh no indeed
<infinity> apw: So, you have until thursday/friday to upload a new one if you want, no rush.
<apw> infinity, may as well upload a new one then, to confirm that autopkgtest sorts itself out
<apw> infinity, though i guess i don't want to ram the buildds ...
<infinity> apw: Meh, the buildds are fine, as long as you don't upload 8 kernels in an hour for 5-character fixes.
<apw> infinity, this will be one in an hour for a 10 character fix, sigh
<infinity> apw: You keep strange time.  Tim's upload was ~12h ago.
<apw> infinity, :)
<xnox> infinity: didrocks: that unity raring SRU have version numbers higher than saucy: libgrip, libcompizconfig0, libdecoration, compiz, g-c-c-u, ..... E.g. saucy has 0.3.6daily13.06.10-0ubuntu1, while raring-proposed now has 0.3.6daily13.06.19~13.04-0ubuntu1
 * xnox goes to figure out why my saucy box has raring-proposed enabled....
<didrocks> xnox: hum, that's a good point, I thought about same release day release and thus, this appending of ~13.04â¦
<didrocks> but yeah, there is a versionning issue in that case, I need to think about it
<xnox> didrocks: I mean the quick solution is to force release/bump version numbers in saucy.
<didrocks> xnox: well, we are going to have a release today once the tests failing are fixed
<xnox> didrocks: or have saucy bump "upstream" version number, with each ubuntu series.
<seb128> didrocks, including compiz?
<didrocks> xnox: bump it's difficult when you have 90 components to have upstream bumping their version and all them agrees :)
<didrocks> seb128: not today, but in the coming week normally
<seb128> cool
<didrocks> there is one regression with compiz trunk they need to fix
<didrocks> (Qt apps behind the top panel)
<seb128> I was not sure how much that one was on the "it works, don't touch it" state
<seb128> ;-)
<xnox> didrocks: hehe. Always encode "13.10" before date?
<seb128> yeah for even longer version number?
<didrocks> seb128: seems that would be the roadâ¦
<didrocks> xnox: thanks for the pointer, noting it and will deal with it
<xnox> didrocks: no worries, it's hardly the end of the world. We will have daily release before saucy goes out the door ;-) to make saucy higher again.
<seb128> didrocks, yeah, sort of make sense ... if we want shorter versions we should just drop the "<upstream>daily" part, but that's another "battle"
<didrocks> if only upstream fixed their tests everyday or their FTBFS, we won't have this issue
<didrocks> xnox: yep, I just want to avoid that issue if possible ^
<didrocks> seb128: I tried starting that one :)
<didrocks> seb128: but it's a very very long term plan :p
<infinity> didrocks: Well, unless the code in 0.3.6daily13.06.10-0ubuntu1 and 0.3.6daily13.06.19~13.04-0ubuntu1 somewhat match, those versions are meaningless anyway without an upstream bump of some sort on a new series.
<didrocks> infinity: they don't match, but that's why for SRUs you have ~13.04
<didrocks> so that you don't have in raring and saucy 2 0.3.6daily13.06.19-0ubuntu1
<didrocks> with different content
<infinity> But that's not what ~foo means.  It doesn't mean "this is completely different, but the same version". :P
<infinity> At least, not to most people.
<didrocks> infinity: well, suggestions welcomed :)
<infinity> I expect my 1.2.3-4 and 1.2.3-4~foo to be basically the same thing.
<didrocks> to cope with autobumping, upstream merger, and all those use case, with transitionning, having the same version in both saucy and raring
<infinity> If they're two different upstream branches, the upstream versions should really reflect that better.
<didrocks> while keeping when upstream doesn't bump to have raring > saucy
<didrocks> oupss <
<didrocks> infinity: go convince for those 90 components :p
<infinity> I don't see how that's hard...
<infinity> Surely, they're all versioned simply enough that one can bump at least a minor/micro or something.
<didrocks> infinity: please open a discussion with PS, I already tried itâ¦
<infinity> They used to bump versions on new series before this daily landing stuff...
<infinity> We got a new unity with every series.
<didrocks> infinity: unity, yeah, not for all components
<seb128> they should probably just do "serie.date"
<seb128> 13.10.06.25
<infinity> Yeah, if they don't care about strict and sane branch-based versioning, just using the series number would work.
<didrocks> seb128: well, you know I've already proposed that
<seb128> didrocks, right, that's why I wrote "that's another battle" ;-)
<didrocks> we could do the other way around, but the issue to do with <version>.<series> is that sometimes, they add a micro version (so an extra digit)
<seb128> didrocks, but eventually we will get there
<didrocks> seb128: I completely hope so :)
<infinity> didrocks: So, why is it <upstream>daily<date>~series intead of <upstream>daily<series>~date?
<infinity> didrocks: That wouldn't make me happy as far as versions being not-crack, but it would solve the ordering problem.  Cause saucy would always be >> raring.
<didrocks> infinity: because <series> wasn't thought at first, and you were complaining about version too long already :)
<didrocks> infinity: so that's why I only added it once we entered maintainance mode
<infinity> didrocks: Yeah, the versions are insane (and the "daily" string is redundant).
 * xnox thinks we are now past the point of caring of how long it is ;-)
<seb128> I think we all agree here on that
<infinity> didrocks: Heck, the date part itself might be pointless.
<didrocks> infinity: again, will be pleased with a solution dealing with upstream's realities
<infinity> didrocks: It could just be <upstream>+<series>.<int> where <int> is an integer that increments on every upload.  The date is encoded in the changelog, it doesn't need to be in the version.
<xnox> where int, is bzr revno
<infinity> xnox: Or that.
<didrocks> xnox: I prefer date, it's more meanfull, especially with feature branch that are running in parallel
<didrocks> xnox: otherwise, we won't be able to remerge
<xnox> infinity: the date does give _some_ alignment though - e.g. everything is up to date.
<didrocks> infinity: so you do expect that <upstream>+<series> to be different upstream content than <upstream>+<series+1>
<infinity> xnox: And that would be relevant, if the other 6000 packages on your system also showed the date in dpkg -l
<infinity> didrocks: No, I still think it's crack for upstream to not rev their versions, but as you say, I can't control that.
<xnox> infinity: touche
<infinity> didrocks: But it's saner for YOU to do <upstream>+<series> instead of <upstream>+<date> and tack series on as an afterthought, cause mine sorts correctly. :P
<infinity> Sadly, this probably can't be changed for raring now (though, dpkg --compare-versions may tell me otherwise, let's see...)
<didrocks> infinity: I tried with dpkg --compare-versions and it seems fine
<infinity> Oh, wait.  Yay.
<infinity> (base)adconrad@cthulhu:~$ dpkg --compare-versions 0.3.2+13.04 gt 0.3.2daily13.06 && echo Yes
<infinity> Yes
<infinity> So, yeah.  That could work quite nicely.
<didrocks> infinity: ok, I'll implement that then
<didrocks> let me try some other cases
<didrocks> with features branch in particular
<didrocks> (which have another versionning to deliver in a ppa, while still being compatible with distro once merged back)
<infinity> Fun.
<infinity> I don't envy your life.
<didrocks> isn't it? :)
<didrocks> ahah
<didrocks> if it works, I'll handle the transition the sanest possible way
<didrocks> this means that upstream shouldn't use + in the upstream versionning
<infinity> Also, I'd pay good money to stop having useless changelog entries that say "automatic snapshot".  Which could go away if the revno was in the version. :P
<didrocks> which isn't unreasonable to ask :)
<didrocks> infinity: well, we can add the revno in the version, but that would be in addition to the date
<didrocks> so I don't think you want it :p
<infinity> I was thinking instead of the date.
<infinity> But yeah, I don't want both.
<didrocks> not possible again because of feature branch
<infinity> Cuase I think date.date is CONFUSING.
<didrocks> having different revision meaning other things
<infinity> Well, if you use datestamps instead of dates-as-versions, it's a bit less confusing.
<didrocks> datestamps?
<didrocks> infinity: what about 0.3.2+13.04+13.06.03 for instance? (two +, but at least, more readable)
<infinity> Like, 0.3.6+13.04.20130627 is less confusing than 0.3.6+13.04.13.06.27 where we have a repeating thirteen dot oh something.
<didrocks> yeah, that as well
<didrocks> then still .1, .2, .3
<didrocks> if we rerelease the same day?
<infinity> Sure, yeah.  Same as we date stamp ISOs.
<didrocks> I'm good with this schema
<didrocks> let me ensure all corner cases are tackled
<didrocks> and I'll work on this this week
<infinity> I hate to bikeshed abot versions, but yeah, the current ones are wrong from sort order perspective, and just plain ugly. :)
<infinity> And the "daily" thing is off-putting, especially for SRUs.
<infinity> Nothing instills confidence in your stable updates like a daily snapshot. :)
<didrocks> infinity: well, at least, happy that we can come up with a better situation :) (the maintenance/SRU case was expected to be looked at in 14.04 TBH because of rolling)
<didrocks> infinity: well, on the contrary, we never had that much confidence thanks all the testing that is done automatically on a daily basis :)
 * didrocks wonders if there is a tool somewhere to convert a code name is stable release series version
<infinity> didrocks: I'm not saying that internally it's not better, just that externally, "daily" and/or "snapshot" are scary words. :)
<didrocks> yeah, I understand :)
<mlankhorst> didrocks: I failed to parse that sentence..
<infinity> didrocks: I don't know of a codename<->version converter, you might suggest to bdrung that distro-info could grow some arguments to do that, since it has the tables anyway.
<infinity> didrocks: Of course, you could write one with distro-info-data.
<infinity> didrocks: /usr/share/distro-info/ubuntu.csv has what you're after.
<didrocks> infinity: ah, excellent, yeah, will use that one, better than querying launchpad for that :)
<cjwatson> Riddell,ScottK: There seems to be no migration block yet?
<cjwatson> Or is somebody else doing it?
<Riddell> cjwatson: I'm wondering the best way to do it
<Riddell> cjwatson: i.e. best way to find the list
<Riddell> cjwatson: is getting the source packages from the germinate output the best?
<cjwatson> ScottK has done it in the past, I think.  I don't recall exactly what he did
<cjwatson> Might be a case of trawling through IRC logs ...
<cjwatson> http://irclogs.ubuntu.com/2012/12/05/%23ubuntu-release.html
<Riddell> ah yes, the .sources files would be easier
<cjwatson> http://irclogs.ubuntu.com/2012/12/05/%23ubuntu-release.html#t14:04
<cjwatson> Has what's actually a better option
<cjwatson> Take .manifest and .list from images, munge until you get a list of binary packages, map to corresponding source packages
<infinity> (You probably want to wait for the new kde4libs to finish and get through)
<infinity> Though, I guess you can unblock just that version after doing the generic block.
<Riddell> that was my next question, there's a bunch of things still needing to get in, does an unblock override a block?
<infinity> Yes.
<cjwatson> bzr di -c58 lp:~ubuntu-release/britney/hints-ubuntu   if you want the list for raring beta-1
<Riddell> cjwatson: that should be the block in place
<cjwatson> that was quick, thanks :)
<cjwatson> I'll watch it actually work once before starting auto-sync
<Riddell> cjwatson: what does it mean if an autopkgtest is running?
<Riddell> e.g. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kde-baseapps says autopkgtest for pango1.0 1.32.5-5ubuntu1: RUNNING
<cjwatson> vast confusion because I haven't worked it out yet
<Riddell> why does a test for pango affect kde-baseapps?
<cjwatson> I think it's a known problem with excessive following of virtual packages
<cjwatson> libpango1.0-doc Depends: www-browser, konqueror Provides: www-browser
<cjwatson> jibel mentioned that as a known issue when fixing the converse problem (deps on virtual packages not being noticed at all)
<cjwatson> looks like it might actually genuinely have been running and so should clear soon
<cjwatson> perhaps I should make force imply force-autopkgtest
<Laney> It was non-genuinely RUNNING but jibel was looking into that
<Laney> maybe this new run will clear it out indeed
<cjwatson> there was a run recently enough that it's plausible
<cjwatson> Anyway, force implies force-autopkgtest now
<cjwatson> Riddell: Could you please add versions to all your unblocks?  The syntax is "unblock SRC/VER"
<Riddell> cjwatson: ah gotcha
<cjwatson> unfortunately the bad syntax crashes proposed-migration - I should fix that
<Riddell> oops sorry
<cjwatson> I think I've fixed the crash now
<bdrung> didrocks: it would make sense to enhance distro-info to convert codenames into version and vice versa
<didrocks> bdrung: agreed, but in fact, it's independant of my problematic for dailies, thinking about it. I need to be able, when saucy is frozen to still daily release what will become t* content, but in the "next" ppa on saucy
<didrocks> cjwatson: btw, read the technical board meeting about name. It's great to have this "next" as a name proposal. However, I'm disappointed now to have use that name for this transitional between 2 release ppa (ubuntu-unity/next), as they are close by usage and we'll get confusion ;)
<bdrung> didrocks: distro-info needs to learn the freeze date for this use case
<didrocks> bdrung: yeah, that may be a possibility and having the target in debian/changelog (saucy or t* deduced from the version + freeze/release date)
<cjwatson> didrocks: mail technical-board@ please
<cjwatson> I will forget
<didrocks> cjwatson: not sure it worths mentionning TBH, an external ppa shouldn't infer the TB decision for distro
<didrocks> s/infer/impact/
<Riddell> infinity: you're a genius, kde4libs compiled
<cjwatson> I'm retrying some associated failed builds now
<Riddell> thanks
<Riddell> infinity: what kind of storage does that pandaboard have?  I tried on mine and it ran out of disk space (4GB SD card)
<StevenK> Riddell: I think they build onto USB drives
<didrocks> infinity: xnox: seb128: and here we go! http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/revision/330
<didrocks> I'll deploy that today
<cjwatson> schedule amended to move DIF to week 13; mail sent to ubuntu-release@; auto-sync running
<cjwatson> [Updating] requests (1.2.0-2 [Ubuntu] < 1.2.3-1 [Debian])
<cjwatson> oops, echan
<Riddell> hmm, arm fail https://launchpadlibrarian.net/143356647/buildlog_ubuntu-saucy-armhf.kamera_4%3A4.10.80-0ubuntu1_CHROOTWAIT.txt.gz
<cjwatson> better to link to the +build, then we can tell which builder it is
<cjwatson> heka
<cjwatson> reported to ops
<cjwatson> and heka on manual
<cjwatson> I've retried all heka's failures
<cjwatson> Anyone fancy processing click-package in NEW?
<mlankhorst> cjwatson: can you wipe xorg-server from raring unaccepted?
<cjwatson> mlankhorst: I'll have to give a reason, so if you can give me one, that'd be good
<mlankhorst> will regress
<mlankhorst> it needs another fix because a regression was found when it was uploaded to saucy, sec let me get bug #
<mlankhorst> hm doesn't seem to be one, but it broke nvidia prime support, unless another patch was also applied on top
<seb128> cjwatson, let me have a look
<cjwatson> $ queue -s raring-proposed -Q unapproved reject -m 'requested by mlankhorst; breaks nvidia-prime support' xorg-server
<cjwatson> will do well enough
<cjwatson> (done)
<mlankhorst> thanks
<skaet> stgraber,  cjwatson, infinity - my freenode password appears to need a reset - could one of you please edit the #ubuntu-release topic to indicate we're working towards Alpha 1 this week?
* cjwatson changed the topic of #ubuntu-release to: Ubuntu 13.04 and 12.04.2 released | Preparing Alpha 1 | Archive: open | Saucy Salamander 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
<cjwatson> there
<skaet> Thanks cjwatson :-)
<seb128> cjwatson, click-package NEWed (sorry for the delay, still debugging gtk at the same time)
<ogra_> clickedy click ...
* holmes.freenode.net changed the topic of #ubuntu-release to: Ubuntu 13.04 and 12.04.2 released | Archive: open | Saucy Salamander 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
<cjwatson> seb128: cool, thanks
<skaet> stgraber, my understanding from yesterday is you wanted to test the iso tracker will automatically create the milestone when the runs are triggered.   If that's not the case,  please let me know and I'll go in and add them now.
 * skaet figures that some of the flavors want to start testing
<stgraber> skaet: nope, what I said yesterday is that I'll create the milestone when the first flavour needs it
<stgraber> skaet: and so far nobody asked for their first alpha1 spin
<skaet> stgraber, ah, my misunderstanding.
<stgraber> skaet: also, can you provide me with a list of all products participating in the alpha1 so I can populate the manifest? currently all I have is a list of flavours
<skaet> stgraber,  assume the same products as are produced in the dailies for the flavors for now.    We've heard back from kubuntu, lubuntu, ubuntukylin, ubuntu gnome
<skaet> stgraber,  based on input from Riddell,  Kubuntu will just be desktop i386 and amd64 ( no active or other architectures this time around)
<stgraber> skaet: ok
<skaet> stgraber,  I'm worried that the process of requesting a build isn't well understood with the flavors right now,  the MilestoneProcess page still has reference to an initial set being produced, and then a mail out.
<xnox> stgraber: skaet: given that kde4libs on armhf got fixed, I thought there can be kubuntu+armhf something, unless we don't have any armhf kernel & X stacks left for a desktopy build.
<xnox> Riddell: ^
<skaet> Riddell, ^^ you
<stgraber> skaet: well, I quite clearly mentioned the new process as a reply to your e-mail to all flavour leads...
<skaet> s/you/you want ?/
<stgraber> skaet: and mentioned it here a few times too (and in #ubuntu-quality), so if people haven't read any of that, ... their bad
<skaet> stgraber,  yes. but given its Tuesday, and no requests have come in,  time to figure out the glitch
<Riddell> xnox: yeah but it's pretty low priority for alpha 1
<Riddell> xnox: also it won't work same as it didn't for 13.04, ubiquity don't work in that mode for some reason I'm yet to debug
<xnox> ack
<skaet> Riddell, are you waiting for anything, or do you want stgraber to kick the first set of builds off for your now?
<cjwatson> xnox: the armhf stack is still mid-build
<cjwatson> Though, admittedly, it should be sorted out by end of day or so
<Riddell> skaet: I think lots of kde bits still need to get into -release
<skaet> Riddell,  ack.
<Riddell> skaet: calligra, kate, kde-baseapps, kde-workspace, kmix, ktp-text-ui, pykde4, rekonq
<Riddell> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<skaet> thanks
<phillw> stgraber: has the fix for bug 1193526 hit the build area yet?
<ubot2> Launchpad bug 1193526 in ubiquity (Ubuntu) "Clicking "Install Xubuntu 13.10" in live session doesn't work." [Undecided,Fix released] https://launchpad.net/bugs/1193526
<gema> slangasek, cjwatson: hangout?
<cjwatson> yep, we're just finishing off a 1+!
<cjwatson> 1+1
<gema> cjwatson: ack
<stgraber> phillw: I'm only doing builds and publishing for this alpha1, so you'll have to track bugs and package version yourself this time around
<stgraber> phillw: (though I did take a look at that one and the answer is no, it's not in the release pocket yet)
<cjwatson> stgraber: ubiquity should have landed recently
<cjwatson> Yep, looks like last publisher run
<cjwatson> Several additions of python3-* I've noticed in binary NEW lately :)
<phillw> stgraber: hi, I'm sorry, you will have to be patient with me. I'm still learning (and my email system is currently down). We had the cron for lubuntu turned off last night. Can the images currently in 'daily' be copied over to 'alpha 1'. I'm not 100% sure if the ubiquity bug from the LiveCD warrants a re-spin of an alpha 1 for lubuntu, I'll ask the other testers this evening (we have a lubuntu meeting tonight). If it does, I'll mark the desktop
<cjwatson> phillw: I would say it probably does - it means you can't start the live installer from the desktop, which is pretty confusing
<stgraber> phillw: copied
<phillw> cjwatson: that is a moot point, as we have recently included ZRam to reduce the memory size of a desktop install from the CD. Launching a live session and then installing does seem counter intuitive. But, I'm the new boy here and will go with your recommendation.
<cjwatson> zram doesn't really seem related to me.  One thing I've learned is that, even if it seems counterintuitive to me, if the facility's provided then people will try it :)
<cjwatson> (I do think it's a useful facility; it lets you try the desktop out for a bit before deciding whether you want to install it.  That's why it's there)
<phillw> okies, then stgraber can you respin desktop & upgrade and just copy over the alternate images.
<stgraber> phillw: as I said earlier, I already copied everything. Please just mark those you want respin on the tracker
<phillw> thanks, will do :)
<phillw> stgraber: the upgrade ones aren't on there... are they handled differently?
<cjwatson> upgrade isn't a "respin" FWIW
<cjwatson> no spin involved :)
<phillw> thanks.
<phillw> stgraber: status updated
<cjwatson> it's just a marker every so often for people to submit upgrade tests
<seb128> could somebody let gnome-session migrate from proposed to release?
<seb128> the current release version segfaults if one of the autostart services fails to start which is letting some users without a working session
<seb128> the fix is a one liner, it would be good to get it in today rather than after a1
<cjwatson> it should happen automatically
<Laney> yeah, it's not blocked; see excuses
<cjwatson> I don't particularly know why it isn't frozen (Riddell, aren't we releasing Ubuntu GNOME on Thursday?), but it isn't
<seb128> ok, I was not sure how much is blocked with e.g Ubuntu GNOME
<cjwatson> Riddell: which images did you take as input for the block?
<stgraber> cjwatson: hmm, could it be that our lock file under /srv/cdimage.ubuntu.com/etc/.lock-build-image-set isn't per-architecture?
<cjwatson> stgraber: It's not meant to be
<cjwatson> Oh, I'm thinking of sem-
<Laney> I thought Riddell's block was just for Kubuntu
<cjwatson> argh
<cjwatson> wish that had been clear!
<cjwatson> Riddell: I thought you were acting for the release team and not just for Kubuntu
<knome> skaet, stgraber, cjwatson: if the xubuntu installer bug is fixed, we're in for A1
<skaet> thanks knome
<Laney> r188 commit message confirms that
<cjwatson> stgraber: I think it probably isn't per-architecture, no.  I didn't really expect that people would be building different arches for the same thing in parallel
<cjwatson> Sigh.  Can somebody get a block generated and in place ASAP before there's further interaction with auto-sync?
<cjwatson> knome: If you mean bug 1193526, it should be
<ubot2> Launchpad bug 1193526 in ubiquity (Ubuntu) "Clicking "Install Xubuntu 13.10" in live session doesn't work." [Undecided,Fix released] https://launchpad.net/bugs/1193526
<knome> cjwatson, i've no idea (i was just told there was some critical one), but i suppose it's that :)
<stgraber> cjwatson: so my code isn't terribly clever in that regard. I basically pull builds from the rebuild queue, get one per architecture, build that and start again, which means that I always set ARCHES=<single arch> even if I'm building the same product for multiple arches at the same time
<cjwatson> stgraber: Hm, that's not the expected model and it will be rather less efficient - is there any way you could aggregate instead?
<skaet> knome,  https://launchpad.net/bugs/1193526 is the one that Lubuntu was waiting on.
<ubot2> Ubuntu bug 1193526 in ubiquity (Ubuntu) "Clicking "Install Xubuntu 13.10" in live session doesn't work." [Undecided,Fix released]
<cjwatson> stgraber: That also means all the different architectures get different build IDs but the later ones will copy the earlier ones over - in fact, since they're published to the same directory, that's why lock-build-image-set *can't* be per-architecture
<cjwatson> stgraber: I think you need to fix this, sorry :)
<knome> skaet, ok :) that sounds "correct"
<jbicha> ubuntu-gnome doesn't have its own packageset yet if that's what you're using to figure out the blocks
<cjwatson> jbicha: the procedure was to grab .manifest and .list, collect binary packages, map to source packages
<cjwatson> so based on images not packagesets
<stgraber> cjwatson: hmm, yeah, ok, I'll have that be per-project then, will be less efficient from a buildd usage point of view though
<cjwatson> You don't need to go as coarse-grained as that - it can be per-project/series/image-type combination
<cjwatson> Which often winds up distributing fairly well since ARM often has different image-types
<cjwatson> $ bzr ci -m 'Make ubuntu/saucy/daily-live and ubuntu-server/saucy/daily current symlinks trigger-controlled on amd64 and i386.'
<cjwatson> plars: ^-
<cjwatson> Hopefully that should work as of the next run ...
<plars> cjwatson: awesome :)
<cjwatson> Oh, glib2.0 is blocked, that would need to be unblocked for gnome-session
<cjwatson> stgraber: Do you think unblocking glib2.0 is OK?
<cjwatson> with respect to builds in progress
<cjwatson> changelog looks reasonable though I haven't checked what's in the new upstream
<Laney> should be alright
<stgraber> cjwatson: there's currently no build in progress, I'm changing my script
<Laney> I wouldn't say I'm confident that my new autopkgtest will pass though :-)
<cjwatson> Hm, it's unfortunate that autopkgtests aren't run for blocked packages
<jbicha> I'd really like to have the new libsignon-glib for Ubuntu GNOME Alpha1; it's seeded by almost every flavor though
 * cjwatson unblocks
<cjwatson> (glib2.0)
<Laney> great, that means I don't have to figure out why gtk+3.0 claims to be blocked on glib2.0
<cjwatson> Presumably bumped shlibs?
<Laney> it's symbols and the deps don't seem to be versioned
<Laney> obviously missing something
<knome> skaet, FYI, elfy/hobgoblin is now the xubuntu QA lead and also part of the xubuntu release team, so feel free to turn to him if i'm not around
<knome> ^ same goes for all release team, but i think most of you know that already
<stgraber> running: http://paste.ubuntu.com/5799101/
<stgraber> cjwatson: so my code is very very stupid at the moment, it groups by project+build-type, builds the first, the goes to the next. I'll need to teach it about being able to run non-live builds in parallel and find cases where we have no arch overlap between two sets and so can be parallelized (I could also just start everything and not care, leaving the locks deal with the mess)
<cjwatson> You can start live builds in parallel too, if you like - they'll just block
<cjwatson> I think I've made proposed-migration start autopkgtests even for blocked packages now ...
<skaet> stgraber,  re your paste,   I thought Edubuntu wasn't participating.   Has this changed?
<stgraber> skaet: no, still not participating. Doesn't prevent us from triggering rebuilds through the tracker
<cjwatson> kde-workspace seems to have a real build failure on armhf
<cjwatson> (double vs. qreal, at a very brief glance?)
<stgraber> cjwatson: I think I'll update my code to go with the "just start everything in parallel and wait for things to settle", that's the most efficient thing I can do without having to add a ton of logic.
<cjwatson> Good, autopkgtests for packages that are only ineligible due to blocks seem to be working now
<cjwatson> stgraber: I think that was what I expected you to do :)
 * Laney just got an ENOSPC from jenkins when converting the image
<slangasek> "converting the image"?
<Laney> well, whatever it's doing when it says qemu-img: /dev/shm/adt/saucy-amd64-glib2.0-20130625_172110.nMTaJv.img: error while creating qcow2: No space left on device
<slangasek> is it Laney's fault that I'm receiving adt failure mails with ENOSPC?
<Laney> That can't be my fault :P
<cjwatson> Glad somebody's receiving them
<skaet> stgraber, ack.
<cjwatson> Hmm.  I wonder if failed autopkgtests are not being remembered properly
<cjwatson> 16:08:48.log:I: [Tue Jun 25 16:13:44 2013] - Requested autopkgtest for software-properties_0.92.21
<cjwatson> 16:08:48.log:I: [Tue Jun 25 16:14:07 2013] - Collected autopkgtest status for software-properties_0.92.21: RUNNING
<cjwatson> 17:09:16.log:I: [Tue Jun 25 17:12:53 2013] - Collected autopkgtest status for software-properties_0.92.21: FAIL
<cjwatson> But now no mention of it
<slangasek> jibel, retoaded: ^^ what's going on with space on jenkins?
<slangasek> e.g., https://jenkins.qa.ubuntu.com/job/saucy-adt-pango1.0/29/ARCH=amd64,label=adt/console
 * Laney has generated a massive block
<cjwatson> jibel: Am I meant to store pass/fail results retrieved from adt-britney collect and map them onto the requesting package myself?
<Laney> http://paste.ubuntu.com/5799165/
<cjwatson> I think I must be.  I do have all the state ...
<cjwatson> Laney: No way I'm reviewing that :)
<cjwatson> Do sort it though, please
<Laney> ok
<Laney> That's ubuntu-gnome lubuntu xubuntu. Did I miss any?
<Laney> kylin?
<skaet> kylin is participating
<Laney> ok, here goes
<retoaded> slangasek, it's not an issue with space on jenkins but in the shared memory on albali (where the job is being run).
<slangasek> retoaded: hmm, alright.  So is this being worked on, and can we expect these jobs to start running normally again soon?
<retoaded> slangasek, there is a build currently running on the jenkins node albali that is consuming a large portion of the memory. It started an hour and 40 minutes ago with no estimated time of completion.
<retoaded> When it completes the memory should be freed up.
<slangasek> hmm
<slangasek> will the adt jobs be retried automatically?
<retoaded> that would be more of a jibel question.
<retoaded> fwiw, i plan on heading over to 1SS later this afternoon and it might help this situation of I shut down albali and add more memory (it's on my list of to do's anyway)
<jibel> cjwatson, no, collect is supposed to do that
<jibel> slangasek, retoaded I'll take care of albali, jobs will be retried.
<slangasek> jibel: ok, thanks
<slangasek> jibel: is this a problem that we have to worry about recurring in the future?
<retoaded> jibel, do you want me to add another 32GB RAM to albali when I head over later today?
<cjwatson> jibel: I think what I mean is, is collect supposed to keep them around?  At the moment it seems to archive them once it considers the job done, but proposed-migration is going to keep trying as long as the triggering package is a candidate
<jibel> slangasek, no it's because I increased disk size of the VMs for libreoffice to the limit of what can be supported, I'll reduce it to again and do something specific for LO
<slangasek> ok
<rtg_> can the Nexus kernels be promoted ? I don't think they'll have an impact on any alpha milestones. linux-{grouper,maguro,mako,manta}
<infinity> rtg_: They don't have any blocks, AFAIK, they should auto-promote fine once they're all build and such.
<infinity> s/build/built/
<rtg_> infinity, k
<jbicha> can libsignon-glib be unblocked?
<stgraber> cjwatson: just landed an update to the self-rebuild code, we now have different status codes for: requested, queued, building, built, published and canceled (instead of just requested, building, published and canceled)
<stgraber> cjwatson: so the plan is for my script to run every couple of minutes, take anything in requested state moved them to queued and spawn the rebuild commands, then have the build code move it to building when it actually starts, built when its done building and the tracker will move to published once post-qa is done for the whole set.
<stgraber> that should give us proper per-product state and timing instead of the current rather vague "it's building" status which may take several hours depending on what else is going on on nusakan
 * stgraber gets back to adding the required code for the building and built status handling
<stgraber> to anyone who'll be getting the failure e-mail, yes I broke nusakan, fix in progress
<Laney> ^_^
 * Laney force-autopkgtests glib
<stgraber> looks like I fixed it or at least changed it in a way that takes longer to fail
<Laney> I'll finish packaging the proper test runner and upload that again some point soon
<infinity> stgraber: "... or at least changed it in a way that takes longer to fail"
<infinity> stgraber: Reminds me of every time I cheered while porting glibc 2.16/2.17 to freebsd and I thought I'd won.
<cjwatson> I see uninstallables are down to a happier level.
<infinity> cjwatson: I'm assuming making kde4libs build on armhf helped that a little.
<cjwatson> It took a stack above that too, but yes
<xnox> cjwatson: britney now handling removals as well? "Removing packages left in testing for smooth updates (2):"
<cjwatson> xnox: It thinks it does, but they don't actually get removed
<cjwatson> Not worth disabling the analysis step :)
<xnox> Ah... joy =)
 * cjwatson makes http://people.canonical.com/~ubuntu-archive/proposed-migration/log/ exist, for possibly easier debugging in some cases
<stgraber> cdimage people: I have now added the self-builds to cron, every 5min nusakan will look for new build requests and process them. If you see something going wrong, please disable from cron and ping me about it.
<cjwatson> (I don't recommend you stare at it unless you're debugging britney itself, or maybe hints or auto-package-testing - for ordinary package handling the update_excuses and update_output files should be enough
<cjwatson> stgraber: *shiver* :)
<cjwatson> )
#ubuntu-release 2013-06-26
<stgraber> I did a dozen of test builds keeping a very close look on the DB state on the tracker side and everything looked good (saw it going requested => queued => building => built => published) but I'm sure that didn't cover all of the weird corner cases we have :)
<cjwatson> Argh.  Typoed hint.
 * cjwatson corrects and reruns
<jbicha> I just dist-upgraded and I have packages from saucy-proposed but I don't have saucy-proposed enabled
<StevenK> jbicha: saucy-proposed is the staging area for uploads to saucy
<jbicha> specifically things like ubuntu-gnome-default-settings and libsignon-glib that should only be in -proposed still
<jbicha> StevenK: no, this is a bit different
<ScottK> jbicha: Are they actually in -proposed or where they just originally uploaded there?
<stgraber> jbicha: can you give us version numbers, that'd help figuring out what's going on
<jbicha> never mind, I misread; sorry about that
<stgraber> ok :)
<ScottK> cjwatson: I think all of KDE 4.11 beta 1 is in now, so if you could run the packageset script one more time, I think we'll be good.
<darkxst> stgraber, can you stop the ubuntu GNOME cron job, and fire a respin once casper 1.335 is published?
<stgraber> darkxst: cronjob is off. I have to leave now though (past midnight here) but if you are in ~ubuntu-gnome-release you should be able to request a rebuild directly from the tracker (go on the daily build page, tick your two entries and select the rebuild option at the bottom of the page)
<darkxst> stgraber, ok thanks, yes I am
<seb128> could somebody from the SRU team reject libgrip from raring-proposed? see https://bugs.launchpad.net/libgrip/+bug/1168370/comments/10
<ubot2`> Ubuntu bug 1168370 in libgrip raring "grip-test no longer responds to input" [Critical,In progress]
<infinity> seb128: s/reject/remove/ ?
<seb128> infinity, yes
<seb128> infinity, since it's buggy
<infinity> seb128: Gone.
<seb128> infinity, thanks
<Riddell> anyone able to try and spin some kubuntu images?
<xnox> Riddell: you should be able to do so yourself via iso tracker.
<xnox> "<stgraber> [04:03:14] ... you should be able to request a rebuild directly from the tracker (go on the daily build page, tick your two entries and select the rebuild option at the bottom of the page)"
<xnox> Riddell: ^
<ogra_> infinity, does that look ok to you ? http://paste.ubuntu.com/5800990/
<smartboyhw> xnox, so it automatically rebuilds?
<ogra_> no, only if you ask it to :)
<smartboyhw> ogra_, I mean when I click "Request a rebuild"
<smartboyhw> ....
<Laney> Self service is the idea
<Laney> I don't see that Riddell actually has permissions though, or see (or know if it's necessary to see) Kubuntu in the A1 milestone
 * Laney isn't up to speed with iso tracker wrangling
<tkamppeter> bug 1108719 is "verification-done" but the Raring version of the SRU is not passed to -updated. Can someone do this? Thanks.
<ubot2`> Launchpad bug 1108719 in cups (Ubuntu Raring) "usb crashed with SIGSEGV in opendir() -- USB ports are in BIOS disabled --> cupsd crashes every time" [High,Fix committed] https://launchpad.net/bugs/1108719
<xnox> tkamppeter: looking at http://people.canonical.com/~ubuntu-archive/pending-sru.html bug 1133794 from that sru is not yet verified.
<ubot2`> Launchpad bug 1133794 in lubuntu-meta (Ubuntu) "Printer not detected by system-config-printer 1.3.11 in Lubuntu 13.04" [Undecided,In progress] https://launchpad.net/bugs/1133794
<xnox> tkamppeter: please help verify that one, than it can be published to -updates.
<tkamppeter> xnox, I have commented on bug 1133794 so that the user complaining about the fix not having appeared can verify the SRU.
<ubot2`> Launchpad bug 1133794 in lubuntu-meta (Ubuntu) "Printer not detected by system-config-printer 1.3.11 in Lubuntu 13.04" [Undecided,In progress] https://launchpad.net/bugs/1133794
<Laney> tkamppeter: If you're able to reproduce you can do it yourself. It might make it go faster.
<cjwatson> Riddell: Should we drop calligra-dev from kubuntu-full's deps?  It's NBS.  Is there any replacement?
<cjwatson> I mean, we have to drop it, but should we remove it or change it ...
<Riddell> cjwatson: oh yes it disappeared in the debian merge
<Riddell> cjwatson: hey sorry for not adding the blocks for other flavours, that didn't click for some reason, did that mess things up?
<cjwatson> It's OK, I wasn't very clear.  I don't think anything very bad happened
 * Riddell removes calligra-dev
<Laney> I now have a script which generates blocks from seeded.json.gz that tumbleweed's script produces for seeded-in-ubuntu
<tumbleweed> Laney: glad to be useful
<cjwatson> ScottK: packageset> done
<ogra_> could some archive admin let ubuntu-touch-generic-initrd throug NEW please
<ogra_> cjwatson, oh, sorry, did i miss something in my RT ?
<cjwatson> ogra_: I usually find it expedites things to attach diff from old version and new version
<ogra_> ah, k
<ogra_> will do that next time
<ogra_> though i would have missed your stuff ... its several versions old and i dont know what actually is on the builder
<cjwatson> ogra_: I searched for all tickets mentioning "BuildLiveCD" in RT
<ogra_> ah
<JackYu> cjwatson, hi, 5 packages of UbuntuKylin were uploaded to Saucy, would you please release  them for Alpha 1?
<cjwatson> JackYu: specific source package names would help
<cjwatson> I'm not going to guess :)
<cjwatson> (I have to go out for a bit now, but anyone in ~ubuntu-release can unblock things)
<ScottK> cjwatson: Thanks.
<JackYu> cjwatson: indicator-china-weather, chinese-calendar, unity-china-music-scope, ubuntukylin-theme, ubuntukylin-default-settings
<JackYu> cjwatson: thanks:).
<stgraber> good morning
<JackYu> stgraber, good evening:)
<JackYu> cjwatson: after you release those packages, would you please respin UbuntuKylin image?
<smartboyhw> JackYu, actually, you can do it yourself.
<smartboyhw> JackYu, in http://iso.qa.ubuntu.com/qatracker/milestones/297/builds you tick the UbuntuKylin ones, then at the bottom select "Request for rebuild", then click "Update rebuild status"
<smartboyhw> ofc after the move:)
<JackYu> smartboyhw, yep, but when he finishes the release, I might be in the bed:)
<smartboyhw> JackYu, ...
<cjwatson> stgraber: Could you look at the unblocks JackYu requested, above?  I have a call now ...
<Laney> I'll do it
<cjwatson> thanks
<stgraber> Laney: thanks
<JackYu> Laney, thanks:)
<Laney> JackYu: Done. I'd have appreciated more detailed changelogs and not randomly altering/removing old changelog entries, BTW
<Laney> It's better to spell out bugs being fixed rather than "New upstream release (LP: #...)" IMO
<JackYu> Laney, I see. Would do it better:), thanks.
<Laney> cheers
<jbicha> could you unblock casper for ubuntu-gnome? I believe darkxst wanted it for a possible respin
<Riddell> cjwatson: kdepim is stuck in -proposed with a comment"From wrong source: kdepim-strigi-plugins 4:4.10.4-0ubuntu1"  kdepim-strigi-plugins is not in this version and I've removed the dep from kubuntu-meta do I need to do something more?
<Riddell> jbicha: will do
<Riddell> hmm kdepim/armhf is pending publication for 16 hours
<stgraber> Riddell: looking into that now
<Riddell> jbicha: done
<stgraber> Riddell: there appears to be a few older binaries in proposed that may confuse britney
<Riddell> stgraber: how do you see that?
<stgraber> kdepim-doc, kdepim-mobile, kdepim-mobileui-data and kdepim-strigi-plugins, all at version 4:4.10.4-0ubuntu1
<stgraber> Riddell: reading through Packages.gz
<stgraber> Riddell: I can remove that older version of kdepim from saucy-proposed if you want
<Riddell> stgraber: worth a shot
<stgraber> you should then only be left with the new one which hopefully will make it easier for britney (if not, we can always manually copy those)
<stgraber> ok, cleaned up
<cjwatson> Please don't manually copy.  If it still breaks I'll investigate
<cjwatson> kdepim/armhf being pending publication might well have been the cause
<cjwatson> Though I don't see a record of that
<cjwatson> ogra_: ubuntu-touch-generic-initrd> Don't you need something to undo the invoke-rc.d stub?  Also, you need to stub out /sbin/initctl too
<cjwatson> (For safety, and to match all the other code that does the same thing)
<ogra_> cjwatson, the chroot is thrown away
<cjwatson> Oh
<cjwatson> OK, but I think stubbing /sbin/initctl would still be a good idea.  Not necessarily for this upload
<ogra_> i only use the initrd.img from the update-initramfs call
<cjwatson> I think there are still a few things that poke initctl directly
<ogra_> ok, will add it
<cjwatson> Have a look at base-installer which does this
<ogra_> ok
<cjwatson> Sorry, not base-installer - debian-installer-utils
<cjwatson> It's in chroot-setup.sh
<ogra_> ok, thanks !
<ogra_> :)
<cjwatson> It installs a policy-rc.d, and carefully-faked start-stop-daemon and initctl instances - it doesn't stub invoke-rc.d
<ogra_> yeah, i remember i have used that code in ltsp-build-client about a century ago :)
<cjwatson> Um
<cjwatson> This isn't going to work anyway
<cjwatson> Builds don't have root
<cjwatson> You need to build-depend on fakechroot and use the debootstrap fakechroot variant, don't you?
<ogra_> hmm, it worked under fakeroot
<cjwatson> But you're not using fakeroot here
<ogra_> indeed
<cjwatson> You're calling build-initrd.sh in dh_auto_build, which is in the build phase
<ogra_> anything wrong with that ?
<cjwatson> The build phase doesn't run under fakeroot
<cjwatson> If you want fakeroot there, you need to explicitly invoke it
<cjwatson> How about I just accept this and you can watch it explode on the buildd :)
<ogra_> cjwatson, heh, thanks, i'll fix on the go
<cjwatson> (I mean, IMO you *should* be using the build phase for this as you're doing - you should just also be explicitly invoking fakeroot or whatever if you need it)
<ogra_> yeah
<cjwatson> ogra_ https://launchpad.net/ubuntu/+source/ubuntu-touch-generic-initrd/0.1/+build/4748632 - boom, though for a different reason (missing build-dep)
<stgraber> Riddell, cjwatson: britney still appears to be confused by kdepim
<cjwatson> ok, will investigate after foundations meeting
<Laney> is it NBS?
<Riddell> Laney: it builds fine
<Riddell> but " [FULLYBUILT] armhf - Pending publication "
<Riddell> soyuz is confused
<Riddell> if I just did another source upload would that fix it?
<Laney> where are you seeing that?
<Laney> kdepim-strigi-plugins was dropped in the latest upload
<Riddell> I'm also confused what's holding kde-workspace and kdeplasma-addons
<phillw> can lxession (*ubuntu4) be allowed into the alpha1 build (it's stuck in -proposed) it is a bugfix for bug 1190170
<ubot2`> Launchpad bug 1190170 in lxsession (Ubuntu) "no gui shutdown in lubuntu" [High,In progress] https://launchpad.net/bugs/1190170
<phillw> *lxsession*
<cjwatson> Riddell: please don't touch it until I've had a look
<cjwatson> Riddell: what URL are you seeing "[FULLYBUILT] armhf - Pending publication" at?
<Riddell> cjwatson: https://launchpad.net/ubuntu/+source/kdepim
<Riddell> expand the  4:4.10.80-0ubuntu1  version
<cjwatson> OK, I will have a look.  Please don't work around it until then as that may make it harder to analyse
<Riddell> ack
<Riddell> phillw: added unblock lxsession/0.4.9.2-0ubuntu4
<phillw> Riddell: thanks,  how long should i give it before marking the desktops for a re-spin?
<Riddell> phillw: wait until you get an accepted e-mail
<cjwatson> No
<cjwatson> No no no totally wrong :)
<cjwatson> Wait until 'rmadison -s saucy lxsession' says the version you want
<Riddell> phillw: ignore me, I'm totally wrong
<cjwatson> Accepted mails happen rather earlier
<cjwatson> They're when the copy action happens, before the publisher has started
<cjwatson> When rmadison says the version you want, the archive is guaranteed to be up to date from the POV of cdimage - well, mostly, one or two issues around parallel builds but the chances are excellent
<phillw> cjwatson: rmadison ?
<cjwatson> It's in the devscripts package
<phillw> sudo apt-get install devscripts (and then go find a wiki page?)
<cjwatson> install the devscripts package and then run the command I gave you.  I don't see why you need a wiki page to tell you how to copy and paste a command
<phillw> cjwatson: thanks, I mis read what you had typed. Sorry.
<Riddell> cjwatson: okular seems to have the same issue as kdepim
<Riddell> hmm that only built 2 hours ago maybe that's still working through
 * cjwatson tries to construct db queries that will tell him wtf is going on here
<cjwatson> getting nowhere with the api
<cjwatson> Riddell: asking for a db query now
<cjwatson> Riddell: So, the "Pending publication" is actually a *consequence* of this - you get that if the source is in release but the binaries for an architecture are still in proposed (because they built after the source was copied - in this case as a result of kde4libs/armhf being forced earlier)
<cjwatson> Now to attempt to work out why the partial-suite handling in britney isn't working here
<Riddell> aah
<cjwatson> I think I've got it; re-running
<cjwatson> Riddell: http://bazaar.launchpad.net/~ubuntu-release/britney/britney2-ubuntu/revision/343 did the trick
<cjwatson> It's copying now
<cjwatson> Looks like I just missed the publisher though
<Riddell> awooga, thanks cjwatson
<cjwatson> final: kdepim/armhf,libkipi/armhf,lxsession,okular/armhf
<cjwatson> (lxsession was already copied so ignore that)
<cjwatson> Oh, the publisher is overrunning considerably anyway
<cjwatson> thunderbird security update took ages to publish
<phillw> stgraber: just as the requested 'please let me know', I've just set all the desktop lubuntu series to re-spin.
<stgraber> phillw: ok, it looks like the automated respin process now works as expected, so I'll just check that it does for you too
<phillw> stgraber: thanks :)
<phillw> small hairy spheroids.... of course, the 'cannot shut down' affects also the shutting down after alternate. I'm requesting a re-spin.... Serves me right for being overly confident on the alternate :D
<Riddell> how do I do a rebuild?
<Riddell> I see on http://iso.qa.ubuntu.com/qatracker/milestones/297/builds  "Rebuilds" "Request a rebuild" but I've no idea what I'd be requesting a rebuild of
<Riddell> but looks like kubuntu should be good to build
<stgraber> Riddell: right, as you don't have any kubuntu build on this one yet, just go on the daily milestone, tick the ones you want and click request a rebuild
<stgraber> they'll build and those that are on the manifest will automatically show up on the alpha-1 milestone
<Riddell> groovy
<phillw> Riddell: it is pretty amazing what stgraber has done... Well, actually 'pretty amazing' is a massive understatement..
<Riddell> well he's a pretty amazing guy
<phillw> I've never doubted that from his work on the qa tracker that I'd seen; but he really has pulled the rabbit out of the magicians hat this time :)
<phillw> Riddell:  damn, he's good!
<Riddell> he gets the goods done
<phillw> cjwatson: that's a dirty trick :D The bug on the upgrade for lubuntu is fixed, but I could not ask for a respin as you said they only get respun every so often :P http://iso.qa.ubuntu.com/qatracker/milestones/297/builds I'm guessing stgraber has been re-fining the code for calling on respins? It's quite amazing what has already been done for A1's guys. Thanks.
<phillw> indeed he does, he is one of many un-sung heroes - I also know of the work he does on QA, where I'm more familiar territory; giving the link between the release managers (Some Devs, some QA / Bugs) is a massive step forward for the flavours.
<ScottK> cjwatson: Mail for you on ubuntu-release.
#ubuntu-release 2013-06-27
<cjwatson> ScottK: done, thanks
<darkxst> anyone able to review mozjs17 in the new queue? its really quite important for gnome-shell
<knome> hmm, why isn't ubuntu showing up in status.ubuntu.com? https://blueprints.launchpad.net/ubuntu/+spec/topic-saucy-flavor-xubuntu is the blueprint (and i can rename to -s- if that's needed)
<knome> *xubuntu
<jdstrand> apparmor 2.8.0-0ubuntu16 seems stuck in sauncy-proposed. everthing is built with nothing in NEW and I don't see anything listed in http://people.canonical.com/~ubuntu-archive/testing/saucy-proposed_probs.html. where else should I look to see what is going on?
<Laney> jdstrand: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<Laney> blocked for alpha 1 preparation
<jdstrand> thanks!
 * jdstrand jots down url
<jdstrand> Laney: I haven't been keeping up with that-- when will alpha 1 be done?
<jdstrand> Laney: (ballpark is fine)
<Laney> jdstrand: some time today; not sure exactly when
<jdstrand> ok, thanks :)
<xnox> jdstrand: i'd jot down just http://people.canonical.com/~ubuntu-archive/proposed-migration/ as one sometimes need to look into "update_output.txt" if something is a "valid candidate" but otherwise doesn't migrate.
<jdstrand> xnox: cool, thanks
<seb128> jdstrand, hey, have you seen my comment on https://bugs.launchpad.net/ubuntu/+source/libwebp/+bug/1186553 (no hurry for the MIR, just trying to get an estimate for when it will be reviewed)
<ubot2`> Ubuntu bug 1186553 in libwebp (Ubuntu) "[MIR] libwebp" [Undecided,New]
<cjwatson> ^- rename of click-package.  Sorry.  Not my idea.
<stgraber> cjwatson: I'll take a look
<stgraber> cjwatson: ^ looks good. I'm assuming you'll take care of removing the old source+binaries?
<cjwatson> Yeah
<cjwatson> Thanks
<skaet> stgraber,  ubuntukylin, ubuntu-gnome are both ready for publishing,   kubuntu should be finished in next couple of hours.  Still waiting to hear back from lubuntu though.
<stgraber> ok
<stgraber> ideally I'd like to do them all at once to avoid confusing people wrt to whether a1 is released or not (we don't have pre-publishing for those flavours so if I run the script they'll show up on cdimage immediately)
<skaet> stgraber,  fair enough.   Lets group kubuntu, ubuntukylin, ubuntu-gnome to start publishing in 2 hours from now.   We'll decide then what to do about lubuntu if we haven't heard back.
<skaet> phillw, ^
<skaet> Riddell, JackYu, jbicha, darkxst - ^
<skaet> stgraber, just heard from phillw,  looks like they'll be ready in 2 hours time as well.
<stgraber> ok
<phillw> ahh, I was just about to say I've updated the area with what we're releasing :) Desktop PPC is not going to be released and no-one has tested arm.
<jbicha> I think arb needs manual hinting since armhf & powerpc have been dropped
 * cjwatson looks
<cjwatson> I'll just remove the !x86 binaries, probably
<phillw> i've just been informed that the alternate PPC is also a no-go.
<cjwatson> jbicha: removed, should migrate after next publisher run
<stgraber> skaet: looks like all the products that will be part of a1 are ready to publish. Do you know if everyone's ready to push their announcements too? if so, I'll start publishing now, so with the usual delay caused by bittorrent, we should be done in the next 30-45min
<skaet> stgraber,   I've set the expectation for 30 minutes for now for it to start, based on the earlier feedback.
<skaet> Not heard any push back on that schedule, so lets let the last set of tests results come in.
<stgraber> skaet: well, lubuntu said they wouldn't release arm or powerpc and those are the only non-ready products on the tracker
<stgraber> anyway, I can wait 30min before publishing, but somebody else will have to monitor bittorrent then because I have a meeting in an hour and I doubt bittorrent will be done by then
<phillw> skaet: It's feeding time here, I'll get the release notes updated for lubuntu after food.
<skaet> phillw, ack.  let me know when you're done please in this channel.   thanks.
<stgraber> starting to publish now
<stgraber> note, ubuntu-gnome and ubuntu-kylin are both oversized, publishing anyway but you'll want to fix that by release or have us increase your image size
<stgraber> cjwatson: "for-project ubuntu publish-release source current src no alpha-1" is failing with "cdimage.tree.PublishReleaseException: No source daily for saucy on current!"
<stgraber> rest looks good, pushing to cdimage now
<jbicha> stgraber: UG saucy is actually about 80MB less than raring was and we should cut a few more 10s of MBs tomorrow :)
<skaet> thanks stgraber
<stgraber> rsync is done, please check that cdimage.ubuntu.com looks good
<skaet> Riddell, JackYu, phillw, jibcha, darkxst ^^
<phillw> skaet: https://wiki.ubuntu.com/SaucySalamander/Alpha1/Lubuntu :)
<skaet> stgraber,  links are all working to the Alpha 1 pages for me.
<skaet> Thanks phillw,  good timing.  :-)
<phillw> stgraber: lubuntu looks good :)
<jbicha> skaet: stgraber: thanks
<stgraber> I'm monitoring the torrents, so far none of them works, hopefully that'll change in the next 15min or so, if not I'll poke IS after my meeting in an hour or so
<skaet> stgraber,  ok, let me know what it looks like in 15 minutes
<skaet> stgraber,  removed those entries not marked as ready from the iso tracker,  and have closed the milestone now.
<stgraber> skaet: half the images are available on bittorent, looks like we need to wait a bit longer for the rest
<skaet> stgraber, ack.
<jbicha> cjwatson: arb is still stuck
<infinity> jbicha: Looking.
<infinity> jbicha: Looks like NBS in -proposed, poking this theory.
<jbicha> I see med-bio depends on arb but it's arch:all
<stgraber> skaet: they all started downloading now, so bittorrent is ready
<skaet> woot
<stgraber> that's all from my side, so just send the announcement when you're ready
 * skaet hits send on the announce
 * stgraber re-enables cron
<skaet> cjwatson, infinity - can you change the header on #ubuntu-release channel
<skaet> ?
<skaet> heh,  looks like the message is being held in moderator approval.... cjwatson, slangasek, infinity - can you oblige...
<skaet> ?
<slangasek> looking
* infinity changed the topic of #ubuntu-release to: Released: 13.10 Alpha 1, 13.04, and 12.04.2 | Archive: open | Saucy Salamander 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
<skaet> thanks infinity
<slangasek> approved
<infinity> jbicha: I'm not sure I understand why the arch-restriction for arb was put in place in the first place.
<infinity> jbicha: Oh, raxml.  I see.
<jbicha> infinity: the latest arb depends on raxml which has an arch-restriction which prevented it from migrating
<infinity> jbicha: Okay, better question, does raxml really need to be arch-restricted? :P
<jbicha> infinity: the Debian changelog points to bug 791321
<infinity> jbicha: Anyhow, stale armhf/powerpc binaries removed.
<ubot2`> Launchpad bug 791321 in raxml (Ubuntu) "raxml version 7.2.6-1 failed to build on armel" [Undecided,Fix released] https://launchpad.net/bugs/791321
<infinity> jbicha: Erm.  lolwut?  Arch-restricting because someone has -msse in their CFLAGS seems wrong. :P
<infinity> jbicha: Given that -msse means it also won't run on all i386 either.
<infinity> Oh, unless it absolutely NEEDS SSE.
<infinity> In which case, meh.
<Laney> all releasey and shizzle?
 * Laney removes the megablock
<Laney> Riddell: you might want to remove yours too
<cjwatson> stgraber: you need to build them first.  cron.source
<stgraber> cjwatson: ah good point, I apparently wrongly assumed we had those generated regularly. Doing a run now and will publish those under alpha1 once done.
<infinity> stgraber: We don't do them automagically because, except in a freeze, there's no sane way to guarantee that they match all the images from that day anyway, so it's really just a waste of resources.
<infinity> (This is likely true for soft-freeze milestones too, but meh, they get close enough)
<skaet> cjwatson, infinity, stgraber - normally we'd close a milestone after the release went out (as documented in the MilestoneProcess), but with it being now 13.06 - and it not being end of month.  its ambigous.  thoughts about whether to close or not?
<skaet> I did go in and close 13.05 as a target,  which was still open.
<stgraber> skaet: we'll just wait till end of month
<stgraber> cjwatson: so cron.source worked but the tree under www/full/source looks rather weird (it published under full/source/source/20130627/source), are there any environment variables or arguments I'm supposed to pass to have it publish to the right place?
<skaet> stgraber,   ok,  who? and where documented?   (since 13.05 was still open,  probably something needs to be written down ;-) )
<infinity> It should be done around the end of a month but, on the other hand, if people target things to the past, I suppose they get to keep that result. :P
<infinity> Writing it down will only help if it's a document someone reads.
<stgraber> was just about to say that ;)
<stgraber> it's not something we can tie to our milestone process so it's just something that people who have rights to do so should check every so often
<stgraber> it's not a big deal if a milestone isn't disabled for a few weeks, so long as it's all done by release time
<stgraber> (I usually tend to notice when targeting bugs, if I spot an expired milestone in the list I tend to go and disable it)
<skaet> stgraber, infinity - ok.  MilestoneProcess has been updated to remove the reference.
<stgraber> ^ I'll take that one
<bdmurray> although bug 1100586 has not been positively verified, I am inclined to release it as there are no regressions and it is a minimal patch
<ubot2`> Launchpad bug 1100586 in xserver-xorg-input-synaptics (Ubuntu Quantal) "unable to use Apple Wireless Trackpad" [High,Fix committed] https://launchpad.net/bugs/1100586
<ScottK> Just got rid of Riddell's Alpha 1 mega block.
<infinity> ScottK: Lovely.  The kernel team will be happy to hear that. :)
<Ursinha> infinity, StevenK, wgrant, are we meeting today? :)
<infinity> Ursinha: Yep.
<cjwatson> stgraber: I think it's just odd like that
<stgraber> cjwatson: well, publish-release fails to find it there so something's wrong somewhere
<Ursinha> !@!@#&*$#&*
<Ursinha> wgrant, StevenK, infinity, gah
<Ursinha> I'm sorry guys, I don't know wtf is going on
<Ursinha> sigh
<Ursinha> wgrant, what's the bug number?
<wgrant> Ursinha: https://bugs.launchpad.net/launchpad/+bug/1064895
<ubot2`> Ubuntu bug 1064895 in Launchpad itself "Translations processed in-band by the publisher" [Low,Triaged]
<Ursinha> thanks wgrant :)
<tumbleweed> what makes it onto the new source images? seeded packages?
<infinity> tumbleweed: Source images should be (barring bugs) the combination of all sources for all binaries found on all images.
<tumbleweed> ok, I assumed something like that from the size
 * tumbleweed teaches seeded-in-ubuntu not to fall over them
#ubuntu-release 2013-06-28
<cjwatson> stgraber: hm, yes, weird - well, I moved things around by hand for now and am publish-releasing now
<rbasak> facter 1.6.5-1ubuntu1.1 is in precise-proposed, approved and awaiting testing. Looks like I'll have to do it. I have another fix for facter in bug 986973 for which a fix has been identified, so I'd like to add that too. It'd be nice for me to test all of this at once, so can I just add another patch to a 1.6.5-1ubuntu1.2 and get that uploaded, and once approved test all the fixes at once?
<ubot2`> Launchpad bug 986973 in facter (Ubuntu) "Facter bug causes puppet to hang" [Medium,Triaged] https://launchpad.net/bugs/986973
<rbasak> ie. I guess I want to trump a version of facter that's already in precise-proposed but is verification-needed.
<Daviey> rbasak: I think doing both fixes in one upload is acceptable. Please do continue
<Daviey> rbasak: Please ping me when you upload the new one, so i can trump the status on the original
<rbasak> Daviey: OK, thanks.
<ogra_> could some archive admin unleash ubuntu-touch-generic-initrd from binary NEW ?
<ogra_> seb128, would you mind unbocking me ^^^ ?
<cjwatson> 12:15 -queuebot:#ubuntu-release- New: accepted ubuntu-touch-generic-initrd [armhf] (saucy-proposed) [0.2]
<cjwatson> somebody already did
<seb128> ogra_, /me "bocks" ogra_
<ogra_> oh
<seb128> great, less work for me ;-)
<ogra_> that kind of drowned in the noise, sorry
<seb128> ogra_, if you need something that was already one by somebody else, feel free to ping me :p
 * ogra_ notes down on his whiteboard on the wall 
<Laney> bockwurst
<ogra_> mustard ?
<xnox> somebody please accept shadow [armhf] which was slow to arrive to be accepted with the rest of them =)
<Laney> natÃ¼rlich
<StevenK> Laney: Nein, die Antwort ist falsch
<StevenK> (Am I close enough, ogra_?)
<ogra_> perfect !
<xnox> StevenK: Ja, alles ist klar!
<StevenK> Wonderbar!
<ogra_> though i hink Laney is right ... i would want mustard with my bockwurst
<seb128> Laney, nein, wiener schnitzel
 * xnox ponders about German as default language for ubuntu desktop 14.04. Look even seb128 speaks it!
<StevenK> Hmmm, Duolingo was using deutlich as clear, rather than klar
<Laney> I just looked up "chipolata" in German
<Laney> cocktailwÃ¼rstchen â¥
<seb128> lol
<ogra_> StevenK, i would translate "deutlich" more as "precise" than clear
<Laney> not sure that's an entirely correct translation though
<Laney> ...aaanyway
<ogra_> it is
<Laney> it doesn't appear to be the same thing
<ogra_> it is "mini bockwurst"
<Laney> cocktail sausages aren't the same as chipolatas
<Laney> but maybe you do indeed use the same word
<Laney> that might be enough OT for now :P
<ogra_> heh
<ogra_> dict translates chipolata with chipolata :)
<ogra_> ogra@chromebook:~$ cd branches/lovecd-rootfs
<ogra_> bash: cd: branches/lovecd-rootfs: No such file or directory
<ogra_> there are days where i like my typos :)
<xnox> ogra_: there is a similar eastern egg in android build system.
 * iulian wonders where the western egg is.
<ogra_> in ubuntu kylin indeed !
<iulian> That's still in east! :)
<ScottK> FYI, there are several KDE related libs that are NBS due to poor timing and things being forced: libkipi10, libmarblewidget15, libokularcore2abi1, and libsolidcontrol4abi2.  There are uploads of KDE SC 4.11 Beta 2 and the newest Digikam release planned for the next few days that will resolve these (I took care of the rest), so don't worry about rebuilds for those.  They'll resolve themselves shortly.
<ScottK> Actually, that's not quite true.  There's one package, contour that needs some porting.
<cjwatson> OK, thanks
<tseliot> infinity: hi, can you approve nvidia-settings-319-updates and nvidia-graphics-drivers-319-updates in Saucy NEW, please?
<jdstrand> hey, I just uploaded a new source (apparmor-easyprof-ubuntu). this is going to ship some data formerly in apparmor
<infinity> jdstrand: So, just a simple package split?
<jdstrand> infinity: yes-- out to a new source though
<infinity> jdstrand: Yeah, I got that part. :)
<jdstrand> (as opposed to what I did the other day with a new binary)
<jdstrand> right, so simple package split. I haven't uploaded the new apparmor yet, cause I wanted to have a dependency on apparmor-easyprof-ubuntu
<infinity> jdstrand: Did these templates previously ship in another package?
<infinity> Hrm, doesn't look like.
<jdstrand> infinity: yes, but in a different directory
<jdstrand> apparmor ubuntu16 in saucy should have those
<infinity> jdstrand: Yeah, I meant the exact paths (for breaks/replaces), not conceptually.
<jdstrand> err, apparmor-easyprof
<cjwatson> is having them both simultaneously installed bad?
<jdstrand> won't need a Breaks/Replaces in this case
<jdstrand> nope
<cjwatson> is having them removed from the first without the second being installed bad?
<jdstrand> the new apparmor I've yet to upload them won't happen to ship them, but there is no problem if it does
<infinity> I was assuming easyprof-ubuntu is a superset of easyprof and the former wants to depend on the latter, is that not true?
<jdstrand> apparmor-easyprof is going to lose all its ubuntu templates. it is going to Depends on apparmor-easypro-ubuntu
<jdstrand> to get them back again
<infinity> Oh, the dep's going that direction.  Kay.  Doesn't that seem backward?
<infinity> generic Depends specific means no one can take just generic without altering it.
<jdstrand> I considered both directions
<jdstrand> on the hand that you are referring to, it does seem backwards
<jdstrand> but on the other hand, dh_apparmor depends on apparmor-easyprof, and we are going to want these templates there. same will be said for the click package hook
<jdstrand> I guess I culd adjust the dh_apparmor (and future click) dependency to depend on apparmor-easyprof-ubuntu instead of apparmor-easyprof
<infinity> Well, I'm not wildly fussed.  It's just a bit downstream-hostile to have the dep this direction.  But it's more work to go the other way and fix up seeds/deps to make sure *we* always have what you want installed.
<jdstrand> but that is unfriendly to Debian
<infinity> I suppose if people just need to alter the one dependency, that's not a big deal.
<infinity> License: GPL-2
<infinity> ^-- Really?
<infinity> Not 2+ or 3?
<infinity> Oh, I geuss that comes from the original apparmor license mess.
<infinity> jdstrand: Do me a favour and upload that new apparmor nowish.  I'm NEWing this to main, and I don't want someone dropping it back out when nothing depends on it. :P
<jdstrand> infinity: yes, original licensing
<jdstrand> infinity: thanks!
<jdstrand> I have another change I need to test, then can upload
<infinity> Kay.
<infinity> I don't know how I lived without the lesspipe hook for debs before I found out about it...
<xnox> *_* for debs!
<infinity> xnox: It just triggers dpkg-deb -I and dpkg-deb -c, but it's wildly useful.
<xnox> infinity: I don't have it, is it in the archive?
<cjwatson> that is handy :)
<infinity> xnox: Of course you have it.  "less foo.deb"
<xnox> infinity: i get crazy binary output.
<infinity> xnox: Using a custom .${shell}rc that doesn't eval lesspipe?
<infinity> xnox: See /etc/skel/.bashrc for the lesspipe eval.
<cjwatson> He wouldn't be the only one with custom shell init files that date back years, although mine do at least eval lesspipe ...
<xnox> same here. same snippet is evaluated.
<cjwatson> (I have VCS history for mine back to 2002, and I think they originate in more like 1999 or so)
<infinity> I gave up on managing fancy custom shell inits when I realized that default was almost good enough now.
<infinity> And I just tack on DEBEMAL and DEB_BUILD_OPTIONS on new installs.
<xnox> infinity: I started pushing my minimal changes to ~/.bash_aliases such that I know I can take fresh ~/.bashrc any time.
<jdstrand> infinity: ok, uploaded. there may be another one later today, but that chouldn't concern you :)
<jbicha> today's Ubuntu GNOME daily image build failed, can I just use the iso tracker to request a rebuild?
<stgraber> yep
<phillw> Hi, a very quick question... Someone installs 10.04 via the netboot / mini.iso from, say, http://archive.ubuntu.com/ubuntu/dists/lucid/main/installer-i386/current/images/netboot/ and then drops a DE onto it. They will get no security updates for the DE, but they will they still get kernel updates?
<ScottK> phillw: Is the the security team's channel?
<ScottK> (or the kernel team's)
<phillw> ScottK: I'm not sure... the note is signed "On behalf of the Ubuntu Release Team,Adam Conrad "
<phillw> which I think is here?
<ScottK> True, but I don't understand what needs clarifying.
<phillw> But, i will go ask on kernel :)
<phillw> I think that they will, but as I'm updating a wiki page, I wanted to check :)
<ScottK> No publisher run this half hour?
<infinity> phillw: Which part of the EOL announcement wasn't clear?
<phillw> infinity: it is clear, my question was does an install via netboot get (i.e. have the repos) for server kernel updates which will continue for approx 18 months.
<infinity> phillw: Of course.  Of course, people could install from desktop media too, it's not like I reached through the internet and deleted everyone's ISOs when I sent the announcement.
<infinity> phillw: But, in either case, things are set up with -updates and -security turned on by default, and nothing changes.  We just stopped pushing updates for non-server stuff.
<phillw> infinity: thanks, I was 99% sure, but as I was clearing old releases out in readiness for 13.10, we keep 10.04 hanging around in lubuntu for legacy kit. :)
<phillw> it is quite clear that they do not get DE updates and they have to look after that them selves :)
<phillw> thanks for giving me the 100% :)
<infinity> cjwatson: Hrm.  I thought britney/autopkgtest was meant to trigger as soon as amd64 binaries were available?
<infinity> cjwatson: Looks to me like linux only triggered the eglibc test once it was available on all arches, rather than 6 hours earlier.
#ubuntu-release 2013-06-29
<phillw> yes, I know I'll get told off :) But, please hear me out.... I understand that there is not an 'ARM' team as such, for people interested in ARM - where should they head? (It's a genuine question as to how QEMU can work to give people a taste of ARM before spending 'real' money on the kit).
<stgraber> try #ubuntu-arm if that still exists
<infinity> That reminds me that I was going to do vexpress qcow images for people to spin up under qemu-system-arm.
<infinity> I wonder if I should produce those via cdimage infra and publish dailies, or just slap something on people.
<stgraber> infinity: do you need anything from outside the archive to build that? if not, it's probably worth publishing through cdimage
<infinity> stgraber: Shouldn't do, though I haven't done it yet.
<infinity> stgraber: And right now, I have a more pressing urge for a hamburger, some TV, and a long weekend.
<stgraber> infinity: fair enough :) Reminds me I need to go buy some beers, my fridge looks awfully empty of late...
 * phillw passes stgraber a 'good' bottle of red wine
<stgraber> wine, scotch and other stronger alcohols aren't the problem, I'm just out of beer :)
<phillw> str
<phillw> strgraber After all the years I've done as licensee, I'd not reccomend any beers that were not brewed locally.
 * infinity is really disappointed that "klines" is a line-drawing game instead of a KDE IRC client.
<infinity> ScottK: ^-- This needs to be fixed.
<ScottK> Sorry.
<ScottK> Oddly enough, there actually isn't an IRC client in the official KDE SC.
<ScottK> Back in KDE3 times there was, but it was horrible, no one used it, AFAIK it was never ported to KDE4, and I can't even remember what it was called.
<darkxst> can we get the size limit on ubuntu gnome images bumped up to 1GB to avoid oversized warnings?
<stgraber> darkxst: done
<darkxst> stgraber, thanks ;)
<stgraber> np
<StevenK> ScottK: Konversation ?
<ScottK> No.  That was the good one.
<ScottK> It's KDE extragear, not part of the core release.
<StevenK> KVirc, perhaps
<ScottK> No, also not core KDE.  Some people use that one.
<ScottK> I'm not sure we even bothered to package it.
<ScottK> It was that bad.
<infinity> I'm not convinced there are any GUI IRC clients for X that aren't bad.
<infinity> There's been one or two passably okay Win32 ones.
<infinity> But, for the most part, they're either featureless or hideous or, commonly, both.
<phillw> oooh, 13.10 :)
<ScottK> something's gone wronge.  http://people.canonical.com/~ubuntu-archive/NBS/ is empty.
#ubuntu-release 2013-06-30
<tumbleweed> Laney: ^ the bug isn't included, do you want it?
<ScottK> All the KDE upgrade NBS is resolved/gone.
<ScottK> infinity: Is there someone around you can poke to get this killed off: https://launchpad.net/ubuntu/+source/kile/4:2.1.3-2ubuntu1/+build/4757534
<Laney> tumbleweed: Not excessively bothered, but would be nice to have in future. Ta
#ubuntu-release 2014-06-23
<cjwatson> Our livefs builds are now all using Launchpad, except for ubuntu-touch for which I'll wait till I can double-check with ogra in the morning.
<cjwatson> I'll sort out trusty builds in the morning.  We can't quite use PROPOSED=1 yet, but that's one deployment away.
<cjwatson> But at least that means this milestone can have much quicker respin cycles if needed.
<stgraber> cjwatson: thanks for mentioning it, I completely forgot about alpha-1... Just sent the usual e-mail out to ubuntu-release and I'll be taking care of the rest tomorrow.
<xnox> cool!
<infinity> cjwatson: \o/
<apw> cjwatson, excellent, looking forward to T dailies to sidestep some install issues
<cjwatson> infinity: Do we have a list anywhere of which flavours intend to release with the trusty point release?
<infinity> cjwatson: Given that all of them have LTS status this time, the assumption would be "everyone" unless someone opts out.
<cjwatson> OK
<cjwatson> Done
<zul> can an archive admin put python3-tornado in main, python-tornado is in main and its blocking a new python-httpretty please?
<infinity> zul: Yeahp.
<zul> infinity:  thanks
<infinity> zul: Done (will publish in ~30m or something).
<zul> infinity:  thanks again
<infinity> zul: Did python3-oslotest too, which was blocking another of your uploads.
<zul> cool! thanks
<infinity> zul: Your python-sure upload seems to have missed the part where the binary packages also depend on -rednose...
<zul> infinity:  crap ill fix it up
<infinity> Makefile:	@nosetests -s --verbosity=2 tests --rednose
<infinity> zul: Looks like you'll need to fix that too.
<infinity> zul: Alternately, do an MIR for python-rednose?
<infinity> zul: Not sure it's worth carrying deltas for this.
<zul> infinity: yeah MIR would be best i think
<cjwatson> Hm.  So, we have a bit of a problem for trusty image builds.  (Running one right now to demonstrate it)
<infinity> cjwatson: Hrm?
<cjwatson> We added ${Signed-Kernel-Stem}-generic [amd64] to the live seed in quantal or so to support secure boot
<cjwatson> I had to hack up livecd-rootfs in precise post-release to deal with the fact that nothing updates tasks post-release (or even can update them, without regenerating Packages)
<cjwatson> In retrospect this should have been an alarm bell
<cjwatson> Because now the *-live tasks in trusty include linux-signed-image-3.13.0-24-generic etc.
<infinity> cjwatson: Fixable by extending ubuntu-chroot_headers_tidy.patch to do all kernel-related packages instead.
<cjwatson> As it happens livecd-rootfs expands the task manually because live-build removed support for it, so I guess we could make it filter out the kernels
<infinity> Oh, except that the new apt autoremove stuff will thwart us.
<cjwatson> And then add_package live linux-signed-generic
<cjwatson> I think I'd prefer to do this mangling in livecd-rootfs, probably
 * infinity nods.
<cjwatson> Of course I won't be able to verify an SRU until launchpad-buildd 123 is deployed now ...
<cjwatson> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/trusty/ubuntu/+build/57 should show the problem in a bit
<infinity> Err, wait, what do you mean about livecd-rootfs expanding the task manually?
<infinity>         add_task live "$LIVE_TASK"
<infinity> That doesn't look very manual...
<cjwatson> Look at the add_task function
<infinity> Oh.
<infinity> Derp.
<cjwatson> It's painfully manual :)
<infinity> Doesn't live-build just use apt-get install against the package lists?
<infinity> In which case "task support" would just mean adding a package named task^
<infinity> Anyhow, not that that solves your -signed problem...
<cjwatson> infinity: I think that didn't work for some reason; pretty sure I would have tried things like that before writing that add_task function :)
<cjwatson> It doesn't seem like the sort of thing that would have been my first resort
<infinity> cjwatson: Maybe you felt that file was suffering a shortage of backslashes.
<infinity> cjwatson: Any idea what's up with https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/precise/ubuntu-zh-cn/+build/56 ?
<infinity> cjwatson: Also, looks like buildlivefs is leaking locale environment.
 * stgraber begins to wonder if we may end up skipping alpha-1 entirely, so far nobody said they'd participate :)
<infinity> stgraber: I'll participate.  I'd like a freeze of the base system for ubuntu-core, please.
<cjwatson> infinity: poking webops.  wdym about buildlivefs?
<infinity> perl: warning: Setting locale failed.
<infinity> perl: warning: Please check that your locale settings:
<infinity> 	LANGUAGE = "en_GB:",
<infinity> cjwatson: That sort of business.
<xnox> smoser: ^ are ubuntu cloud images doing an alpha-1 ?!
<infinity> cjwatson: Nothing gives livefs builds the same LANG=C treatment that sbuild-package does.
<xnox> smoser: if yes, ask stgraber to freeze cloud images as well.
<stgraber> xnox: that'd be utlemming
<xnox> stgraber: oh, right.
<xnox> stgraber: as far as i recall, cloud images did do all milestones typically.
<infinity> cjwatson: It's entirely possible doing this over and over again in helpers is, of course REALLY STUPID, and we should just cleanse the environment once and for all at the top level of the daemon.
<utlemming> xnox: yes, we'll be doing an aplha-1
<stgraber> utlemming: mind replying to my e-mail then? :)
<smoser> good. thanks.
<stgraber> xnox: yeah, so did Kubuntu and Edubuntu, but things have been known to change and those milestones are opt-in, not opt-out :)
<utlemming> stgraber: done
<stgraber> utlemming: thanks
<shadeslayer> btw where can I find documentation to read update_output.txt from britney?
<cjwatson> shadeslayer: https://wiki.ubuntu.com/ProposedMigration
<shadeslayer> thx, I keep loosing that link
<cjwatson> infinity: http://paste.ubuntu.com/7690820/
<shadeslayer> cjwatson: btw we /might/ not require PPA handling on the cdimage site
<shadeslayer> *side
<infinity> cjwatson: kernels are 700, is that trying to read it as the buildd user?
<cjwatson> shadeslayer: ok ...
<infinity> cjwatson: Note that BuildLiveCD had:
<infinity>         for file in ${DIR}livecd.*; do
<infinity>                 sudo chown buildd ${file}
<infinity> To work around the issue.
<cjwatson> infinity: Could be.  live-build/auto/build applies chmod 644
<shadeslayer> KDE's desktop stuff might get montly bug fix releases, which I'll try to get MRE'd
<cjwatson> I'd rather fix this in ubuntu-defaults-image, I think
<cjwatson> It's pointless for the kernel to be 700 in image output
<cjwatson> Inside the image, sure
<infinity> 600, not 700.  Brain not on today.  But yeah.
<infinity> cjwatson: Hrm, we also lost the eatmydata usage when switching from BuildLiveCD to lp-buildd ... Intentional or accidental?
<infinity> cjwatson: On the SATA buildds (which is most of them), I suspect that'll make a difference.
<cjwatson> infinity: Was never deployed and I don't think it actually worked
<cjwatson> infinity: https://code.launchpad.net/~cjwatson/launchpad-buildd/livefs/+merge/193682 has a note about that
<infinity> cjwatson: Oh, that BuildLiveCD never went into puppet?  Kay.  Nevermind, then.
<cjwatson> I wouldn't be sad if you figured out how to make it work in lp-buildd, though
<infinity> cjwatson: Well, I'm not entirely convinced it helps a lot either.
<slangasek> AttributeError: 'NoneType' object has no attribute 'timeout'
<slangasek> ?
<cjwatson> Yeah, on my queue
<slangasek> ok
<cjwatson> slangasek,infinity: I've uploaded a fairly large stack of installer changes to precise at the request of CTS, to enable HTTPS support for 12.04.5.  Could somebody review?  The relevant packages are base-installer, debian-installer-utils, debootstrap, wget, choose-mirror, apt-setup, kickseed, rootskel (and debian-installer will need an upload too once the rest are in)
<cjwatson> These are all pretty straight backports; only choose-mirror required much in the way of adjustment
<infinity> cjwatson: I'll have a look.  d-i needs lts-trusty added too, which I was going to do today.
<cjwatson> Right.  Let me get my bits committed at least then.
<cjwatson> (done)
<arges> cjwatson: hi. For bug 833994, does debian-installer also need to be updated? (making sure it wasn't missed.) thanks
<ubot93> bug 833994 in rootskel (Ubuntu Precise) "debian-installer does not support https when using with preseed files" [Medium,In progress] https://launchpad.net/bugs/833994
<infinity> arges: It'll get updated anyway.
<arges> infinity: ok. so after stuff gets tested debian-installer may be updated I take it?
<infinity> arges: s/tested/built/
<arges> ah gotcha
<infinity> arges: Well, d-i's being uploaded for other reasons too, but yeah.
<wxl> stgraber: hey, i'm having some mailing list issues, but i did want to say that Lubuntu plans on participarting in all milestones
<wxl> (hah, 1m before 2100)
<wxl> oh wait, no i'm doing my math wrong. ignore me.
<stgraber> wxl: ok
<stgraber> wxl: yeah, you still had two hours to go :)
<jdstrand> I'm not sure if this will block the apparmor migration: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-unity-scopes-api/lastBuild/?
<jdstrand> but those failed builds have nothing to do with apparmor
<stgraber> wxl: I've setup the ISO tracker now and have disabled cron for lubuntu, so feel free to just trigger a daily image rebuild on iso.qa.ubuntu.com once you're ready to start testing for alpha1
<wxl> stgraber: forgive me for being the noob release manager, but how do i trigger this? through the tracker itself?
<stgraber> wxl: yes
<wxl> stgraber: i don't see any images on there to tell to rebuild. are they being manually copied over?
<stgraber> wxl: look in the daily milestone
<stgraber> wxl: you'll only see images show up in the alpha-1 milestone once you first build one
<wxl> ahhhh
<wxl> stgraber: it'll take me a bit. seems as if our fearless leader neglected to make my appointment to release manager official. :)
<stgraber> wxl: ok, in the mean time I can trigger builds for you if needed
<wxl> stgraber: that would be great actually
<cjwatson> arges: Yes, I just couldn't upload it before the other pieces were in.  I committed the fixes earlier.
<cjwatson> arges: Thanks for the reviews
<stgraber> wxl: do you want a first build to happen now or are you waiting for some stuff to land first?
<arges> cjwatson: no problem
<wxl> stgraber: naw first build now is fine
<stgraber> wxl: triggered
<wxl> stgraber: thx!!
<cjwatson> slangasek: http://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/revision/1413 should hopefully fix that - had forgotten that the build state is set in a separate and earlier transaction, although in retrospect it's obvious (since the build log takes time to fetch from the slave)
<cjwatson> stgraber: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/precise/edubuntu/+build/74 - do you happen to remember how ltsp-build-client got into the livefs build chroots?
<cjwatson> stgraber: I'd like something better than "hack a special case into launchpad-buildd's livefs build-dep install code", if we can manage it ...
<cjwatson> And ltsp-server seems a bit heavyweight to install for all builds
<stgraber> cjwatson: ltsp-build-client is a script in ltsp-server so no real ways around this
<stgraber> (it's not standalone, it actually depends on a ton of scripts and hooks that are part of ltsp-server)
<cjwatson> Sure, we have to get ltsp-server in there somehow, but I don't want to have to install all that stuff for every LP-based livefs build
<cjwatson> And I'd rather not have 'if self.project == "edubuntu-dvd" and self.arch_tag == "i386":' in launchpad-buildd
<stgraber> is that really that big a deal? I mean ltsp-server without its recommends is tiny
<stgraber> 76k and no only external dependency is debconf-utils (when trying an install on a clean trusty system)
<stgraber> s/no//
<cjwatson> If we can get away without its Recommends, maybe
<cjwatson> The alternative would be to invent a way for livefs jobs to specify additional build-deps
<stgraber> yeah, the recommends are only needed to actually run the stuff
<cjwatson> But maybe that's not worth it
<stgraber> well, except squashfs-tools but I suspect we already have that one right?
<cjwatson> We do, via livecd-rootfs
<stgraber> right, so installing with --no-install-recommends should only install ltsp-server itself then which I guess is reasonable
<cjwatson> OK.  I can't promise to have a fix deployed in time for this milestone though.  Maybe we need to revert Edubuntu to the old buildds temporarily
<stgraber> cjwatson: edubuntu is lts-only, we don't care :)
<cjwatson> Oh, you aren't doing this milestone?  OK
<stgraber> nope, we do random daily testing to make sure things aren't completely busted, but the next milestone testing we'll do for real will be 16.04 alpha-1
<cjwatson> Oh, fine, I'll just queue it up with other things then
<stgraber> wxl: hey, so the bot appears to be sleeping (I'll kick it) but your builds are done and publish on iso.qa.ubuntu.com now
<cjwatson> buildd deployments take a bunch of sysadmin effort
<wxl> stgraber: noticed, thank you :) sent a request for testers finally
<cjwatson> wubi/precise livefs build failure was wrong configuration; fixed and retrying
<ari-tczew> can someone rebuild this one? https://launchpad.net/ubuntu/+source/python-pecan/0.4.5-1/+build/6013254
#ubuntu-release 2014-06-24
<ScottK> opencv on arm64 now causes an ICE, which is a regression.  What's the best way to deal with that to get it to migrate?
<infinity> ScottK: disabling precompiled headers, probably.
<ScottK> Fun.  55 MB tarball.
<ScottK> At 42 kB/s
<ScottK> Double fun.
<ScottK> infinity: Would it be reasonable to override pykde being blocked on the apport jenkins failure?  The gtk front end failed too, so I'm pretty sure it's not pykde's fault.
<ScottK> infinity: Does your recommendation change if I say the upstream code in question is unchanged, so it's likely a gcc regression?
<infinity> ScottK: No, we know it's a GCC issue, but we've already disabled PCH in a few packages to move on for now.
<ScottK> Ok.
<ScottK> Got an example I can use to try and figure out how to do that?
<infinity> https://patches.ubuntu.com/w/wxwidgets3.0/wxwidgets3.0_3.0.1-1ubuntu1.patch
<infinity> Assuming you're lucky enough to have a configure switch for it.
<ScottK> It's CMake, but it looks like I do.
<ScottK> Thanks.
<ScottK> ENABLE_PRECOMPILED_HEADERS
<infinity> Kay.  So something more like this: http://launchpadlibrarian.net/177701306/sandboxgamemaker_2.7.1%2Bdfsg-2build2_2.7.1%2Bdfsg-2ubuntu1.diff.gz
<ScottK> Thanks.
<ScottK> That may be a tomorrow thing.  Suddenly I'm tired.
<mlankhorst> can someone accept llvm-toolchain-3.4 in utopic?
<mlankhorst> seems that llvm-3.4-tools is NEW
<infinity> mlankhorst: It's also FTBFS on all !x86, so I was in no rush to accept.
<mlankhorst> ah
 * mlankhorst looks
<infinity> mlankhorst: Due to this, I believe:
<infinity>   * Ship the compiler-rt static libraries in libclang-3.4-dev
<infinity> mlankhorst: But I didn't have the time to investigate how to unbreak it.
<mlankhorst> fun part is that it's not supposed to happen afaict
<mlankhorst> # Create this fake directory to make the install libclang-common-dev happy
<mlankhorst> # under the unsupported archs of compiler-rt
<mlankhorst> except libclang-3.4-dev takes a different source directory, weird stuff :/
<mlankhorst> infinity: https://mblankhorst.nl/etc/llvm-toolchain-3.4_3.4.2-3ubuntu2.debdiff ?
<infinity> mlankhorst: Maybe? :P
<infinity> mlankhorst: Give it a test-run on porter-powerpc, perhaps.
<mlankhorst> ok
<infinity> ^-- That was pre-reviewed by cjwatson, I didn't just pull a fast one.
<mlankhorst> infinity: yeah that llvm-toolchain-3.4 debdiff fixes the FTBFS on ppc
<infinity> mlankhorst: Uploading.
<michagogo> Question: does getting an SRU in before a point release change anything?
<michagogo> (For a universe package, that is)
<michagogo> In other words, would there be any specific value in bug 1314616 getting in before 12.04.5, or does it not matter?
<ubot93> bug 1314616 in bitcoin (Ubuntu) "[SRU] bitcoin to be maintained upstream in PPA: Replace distro archive "bitcoin" bitcoin with an empty dummy package" [Undecided,Confirmed] https://launchpad.net/bugs/1314616
<cjwatson> Doesn't much matter for things that aren't on images.
<michagogo> (Btw, do people regularly look at the list of things waiting to be sponsored?)
<michagogo> s/e /e that can sponsor/
<mlankhorst> there ya go :-)
<xnox> Laney: will desktop-next be doing an alpha-1?
<Laney> xnox: no
<xnox> ogra_: ubuntu-touch for alpha-1?! =)
<ogra_> huh ?
<Laney> we'd have replied to the thread if so
<xnox> ok.
<ogra_> xnox, lol, surely not :)
<mlankhorst> now we just need armhf :-)
<infinity> Wow, britney, seriously?
<infinity> cjwatson: Fun misfeature.  Since glibc was new source, britney totally didn't care that its binaries were out of date on some arches and migrated it prematurely.  Whee.
<mlankhorst> oops
<cjwatson> infinity: I guess that meant nothing was uninstallable in the interim
<infinity> cjwatson: True, was just a surprise that it didn't actually care about the binaries being out of date, since it deals with things as source package units.
<mlankhorst> yay llvm-toolchain-3.4 built
<jamespage> arges, any chance you could accept the neutron and cinder updates from jdstrand into trusty-proposed?
<jamespage> coreycb, ^^
<cjwatson> final: glibc/arm64
<cjwatson> so hopefully that's sorted out
<infinity> cjwatson: Yeah, my email implied as much.
<cjwatson> Email where?
<infinity> cjwatson: The duplicate ACCEPTED mail.
<cjwatson> Oh right
<arges> jamespage: I can (and was planning on) reviewing them today
<jamespage> arges, thankyou!
<arges> jamespage: was nova already taken care off (...looks)
<jamespage> arges, no - that's still in the queue as well
<arges> jamespage: ok yup its on my todo list today
<jamespage> arges, ++excellent
<cjwatson> That livecd-rootfs upload should sort out */trusty/amd64 livefs builds.  Then it's just Edubuntu to sort out.
 * stgraber looks
<cjwatson> Thanks
<stgraber> cjwatson: accepted. You were missing the usual SRU paperwork, but I guess the testcase is "just rebuild ubuntu gnome" so that's fine.
<cjwatson> Er, sorry, yeah.  I plan to switch trusty to PROPOSED=1 and see if it works
<cjwatson> Pretty much any vaguely normal flavour exhibits it
<cjwatson> I've actually tested it already using the new build-against-PPA facility
<arges> Hi. looking at the nova upload in trusty. A security update went in at ubuntu1.2, but the debdiff for ubuntu1.3 includes the changelog entry for the security update as well. Should I reject and request this be done against ubuntu1.2?
<arges> In addition to some other changelog mangling; not sure why that happened either.
<infinity> arges: I'm not sure I understand the question.  The debdiff contains 1.2 and 1.3 because LP is brain damaged, not because the uploader did anything wrong.
<infinity> arges: (It's a debdiff between proposed and proposed)
<infinity> arges: The changelog weirdness after that is a bit odd, I'll give you that.  Especially the part where it introduces a spelling error that wasn't there before. ;)
<arges> infinity: ok and in that case -proposed is in -updates, so I thought we'd get a debdiff between -updates and what the uploader is requesting
<infinity> arges: Yeah, LP's not that smart.  If you want the debdiff from updates, you'll get to do it yourself.
<arges> infinity: ok. and second... looking at cinder. I noticed the debdiff is against whats in -proposed; and the current -proposed never got accepted into updates. in that case shoudl we request a debdiff against whats in -update?
<infinity> arges: How do you propose to request this?
<infinity> arges: If you just mean you want someone to manually do it, you can just as easily do that yourself.  *shrug*
<arges>  infinity i can do it. I just want to make sure the upload is oK
<arges> infinity: so again, I can attribute this to LP oddness?
<infinity> arges: I think it's obvious what's going on in that cinder update, though.
<cjwatson> You can always attribute wrong debdiff to LP oddness.  It's always fine to download it yourself and debdiff manually against what rmadison reports for the suites you care about.
<infinity> arges: The previous upload was already accepted, and this just adds the security update 1-liner and the changelog bits.
<cjwatson> I mean completely wrong base for debdiff, of course.
<arges> infinity: yup yup. I'm just making sure I don't mess something up
<infinity> To be fair, the cinder debdiff isn't against the wrong base.
<infinity> arges: If I were being a pedant, I'd punt the nova one for the weird history mangling, but probably only because the change in attribution and the introduction of a new typo really irk me. :P
<infinity> Oh, actually, it also breaks the changelog format.
<arges> that's not good
<infinity>      exception when starting instances with libvirt LXC or XEN. (LP: #1297962)
<ubot93> Launchpad bug 1297962 in OpenStack Compute (nova) icehouse "[sru] Nova-compute doesnt start" [Medium,In progress] https://launchpad.net/bugs/1297962
<infinity>  
<infinity> - -- Chuck Short <zulcss@ubuntu.com>  Tue, 20 May 2014 12:04:39 -0400
<infinity> -
<infinity> ubot93: Not helpful.
<infinity>  nova (1:2014.1-0ubuntu1) trusty; urgency=medium
<infinity> arges: So, yeah, make chuck fix his mess there, IMO.
<arges> jamespage: zul ^^^ I'm going to reject nova because of changelog mangling. want to check it over before I do so?
<infinity> arges: But probably worth reviewing the rest of the upload first, and keeping a copy around, so you can enumerate all the bad, and debdiff old.dsc new.dsc when he reuploads to only see what was fixed instead of re-reviewing the whole thing.
<zul> arges:  go ahead ill fix it up and re-upload it
<arges> infinity: yup I have it local
<infinity> zul: I assume you can spot all the bad in http://launchpadlibrarian.net/177877395/nova_1%3A2014.1-0ubuntu1.1_1%3A2014.1.1-0ubuntu1.3.diff.gz and don't need it pointed out? :)
<infinity> zul: (In the changelog, that is)
<zul> infinity:  yeah
 * infinity needs to start stapling "debdiff before you upload" notes to everyone's foreheads.
<mlankhorst> but an upload generates the debdiff for you ;-)
<arges> infinity: so I re-constructed the cinder upload in trusty. the changelog jumps from 2014.1-0ubuntu1 to 2014.1.1-0ubuntu2. which skips 2014.1-0ubuntu1.1 (in -updates)
<infinity> arges: Yeah, I made that out from the debdiff.
<infinity> arges: The way it's done looks fine to me.
<arges> infinity: ok. I didn't know if it was necessary to have another changelog entry for 2014.1-0ubuntu1.1
<infinity> arges: Well, linear history is nice, but I get the impression that Jamie did 1.1 and 2 at the same time, and just did 2 as an addendum to 1, so it sort of makes sense to me.
<arges> infinity: yup, I can see that
 * arges goes and looks at teh rest of the diff : )
<infinity> arges: His 1-liner and weird changelog would be fine with me, anyway.  The rest of it might be scary. ;)
<infinity> (But openstack has an MRE, so as long as the diff doesn't look obviously broken, you're good)
<arges> well i already reviewed it last week anyway, so mostly it is a glance to ensure changelog matches the features in the usptream changelog / formatting wierdness / etc
<arges> also is bug 1185019 supposed to be private/emargoed still?
<arges> embargoed
<infinity> arges: I would hope not, since it's fixe released all over the place.
<arges> infinity: pinging jamie about it
<infinity> I can un-private it.
<infinity> Done.
<arges> infinity: hold on
<infinity> Hrm?
<arges> zul: ok, so the nova upload is against 2014.1-0ubuntu1.1 while 2014-1-0ubuntu1.2 is in proposed. I tried to reconstruct this using 1.1 and that patch didn't apply; also I notcied that d/p/libvirt-Handle-unsupported-host-capabilities.patch seemed to be dropped.
<zul> arges:  crap can you reject it one more time
<arges> : )
<ScottK> ksudoku has suddenly started FTBFS on armhf and I don't think it will get fixed for alpha1.  It's blocking a stack of other packages from transitioning via libkdegames.  I'd like to either force it or do a binary removal on the one arch.  It's got no rdepends.  Thoughts?
<cjwatson> It does have one rdepends: kdegames
<cjwatson> That seems a little tricky as you'd have to remove meta-kde/armhf
<ScottK> Oh.  Right.
<ScottK> I can fix that not to depend on it for armhf.
<ScottK> Easy enough.
<cjwatson> Right, I think if you do that temporarily it's fine to remove the no-longer-buildable binary
<ScottK> OK.  Thanks.
<ScottK> OK, that takes care of that one.
<ScottK> That worked.  The stack of packages around libkdegames migrated.
<cjwatson> Cool
<ScottK> Analitza built so that'll resolve two more depwaits on armhf.  I think kalzlium is good now too (waiting to see), so we're getting there.
<ScottK> So, it looks like between libav, cups, and gnutls the chances of something like a KDE release making it to the release pocket are nil.
<ScottK> Is anyone actively working on these?
<xnox> yes
<LocutusOfBorg1> xnox, do you have any timeline for libav? or do you need help? I cannot upload, but since the transition is already done in debian I hope the changes should be minimal
<LocutusOfBorg1> libavg should just need a sourceful upload in debian and a sync :)
<ScottK> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt looks rather scary for libav.
<xnox> LocutusOfBorg1: what do you mean "just a sourceful upload for libavg" it fails to build from source with libav10, no?
<LocutusOfBorg1> xnox, you are the maintainer right? did you miss this? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739664#34
<ubot93> Debian bug 739664 in src:libavg "libavg: FTBFS with libav 10" [Serious,Open]
<xnox> LocutusOfBorg1: yeah, i  did miss that.
<LocutusOfBorg1> wonderful to hear, I was afraid about some showstopper for the new release :)
<xnox> LocutusOfBorg1: that upstream release does not compile against libav10
<xnox> trying harder
<LocutusOfBorg1> :( sorry for that
<rtg> can someone just reject Precise openipmi 2.0.18-0.1ubuntu1 ?
<rtg> I think I messed it up
<stgraber> sure, always happy to reject stuff :)
<rtg> well, maybe not. config.guess and config.sub get generated during 'clean' which is the bulk of the diff
<rtg> perhaps I'll just come back to this tomorrow. EOD for me.
<stgraber> you may be able to trick it into not doing that so you only get the initscript diff but if you can't that's no big deal either, we're used to that kind of automagic spam
<rtg> stgraber, ok, if it looks good then please accept it.
<ScottK> I think all the Kubuntu stuff that will make it to the release pocket for Alpha 1 without some form of violence on the archive is there.
<ScottK> shadeslayer: ^^^
<stgraber> as I said in the e-mail this morning, I've got all the participating flavours already disabled in cron, so when you are ready, just trigger a build
<stgraber> I'll setup the block shortly too
<ScottK> Please ping here when you've set the block.  I may as well wait for that.
<stgraber> ScottK: done
<ScottK> stgraber: Thanks.
<ScottK> And then I managed to request the rebuild, so I think we're off and running.
<shadeslayer> ScottK: thx for getting everything in, it was a bank holiday here today
<ScottK> stgraber: We should probably have the upgrade milestone for Alpha 1 too.
<stgraber> ScottK: ah yeah, I'll add some of those
<ScottK> stgraber: Thanks.
<wxl> someone correct me if i'm wrong but the difference between amd64 and amd64+mac is that amd64 is uefi and amd64+mac is not, correct?
<wxl> i.e. as long as they didn't use uefi, a person with amd64 hardware could test amd64+mac?
<infinity> wxl: It's even more subtle than that.  amd64+mac is for booting CDs (but not USB sticks) on a specific generation of broken/weird Macs.
<wxl> infinity: my understanding is that there were some amd64 machines that suffered the same fate
<infinity> wxl: As for who can successfully boot it without breaking their non-Macs, I'm not entirely sure.
<wxl> infinity: do i also gather from your statement that on usb it works with amd64 and intel macs without problem? :)
<infinity> wxl: Yeah, if you don't use shiny spinny media, the regular amd64 image should work fine, even on the goofy Macs in question.
<wxl> infinity: oh now that's funny.
#ubuntu-release 2014-06-25
<cjwatson> ScottK: The transition tracker's a good deal easier to follow for this.  http://people.canonical.com/~ubuntu-archive/transitions/libav10.html
<ScottK> cjwatson: Can you tell why nepomuk-core shows up as bad?  AFAICT, it's OK (and has been rebuilt)
<ScottK> Thanks
<cjwatson> ScottK: That's I think the one false positive on the tracker, yes.
<ScottK> OK.
<cjwatson> ScottK: It's because there's a binary in utopic that's no longer built in utopic-proposed - nepomuk-core-ffmpegextractor
<cjwatson> ScottK: proposed-migration recognises that that will go away, but the tracker doesn't
<ScottK> I see.
<cjwatson> Everything else there makes sense.  I have most of the dvdstyler fix.
<ScottK> As far as I can tell between libav, cups, and gnutls there's no way for us to get an updated desktop in right now.
<cjwatson> And I was going to stare at opencv/arm64 ASAP (and mpv/ppc64el once I can get the hw I have access to to talk to ports.ubuntu.com again).
<ScottK> Fun.
 * ScottK needs to go find a wayard $child, so see you later.
<cjwatson> Yeah, it's a gnarly transition.  There'll be a couple of things at the end we can remove/demote.
<cjwatson> But I want to save that until the rest is done.
<infinity> cjwatson: opencv looks like it just needs an s/ifneq/ifeq/ logic inversion.
<infinity> cjwatson: Are you already playing with it, or shall I?
<infinity> cjwatson: Test-building on am1 now.
<rsalveti> can we unblock latest pulseaudio I pushed a few minutes ago? changes are touch specific (new pulseaudio droid module, that works on top of the audio hal)
<rsalveti> built finished fine and tests were also good, just blocked now due freeze
<ScottK> rsalveti: That lands on all the images.
<rsalveti> ScottK: I know, that's why I'm asking if it'd be possible to approve it
<ScottK> Sigh.
<ScottK> So we should respin all the images so your thing doesn't sit in proposed for a day and a half?
<rsalveti> did we already spin all the images? (sorry if I'm not following the release as usual here)
<rsalveti> that's why I asked here, fine if not approved as well
<rsalveti> doesn't hurt asking though
<ScottK> Yes.
<ScottK> We have candidate images.
<ScottK> Not too much tested yet, but they're there.
<ScottK> rsalveti: Are you doing much with pulseaudio?  I think we will need http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=2b85ae048970b7faa7505fd0cd4746541d1b09eb (although not for Alpha 1)
<rsalveti> that seems fine, want me to push that?
<hyperair> N.B. The ykpersonalize command will by default include -oappend-cr.  This will append CRLF (or typing ENTER) to the OTP, so that the dialog or web form is immediately submitted. If you do not want to have the form submitted after touching your Yubikey (e.g. a Nano sitting in your laptop), leave out the -oappend-cr switch.
<hyperair> crap middle click
<hyperair> whoops
<shadeslayer> mmm
<shadeslayer> Kubuntu still has 6 packages from 4.13.0 on the ISO
<shadeslayer> stgraber: ^^
<cjwatson> infinity: not as yet, had gone to bed
<infinity> cjwatson: Well, done now.
<cjwatson> Thanks
<xnox> vtk6 FTBFS on armhf is interesting - GL believes that GLdouble is double, yet Qt4 believes GLdouble is GLfloat.
<cjwatson> https://wiki.ubuntu.com/ARM/FTBFS#OpenGL_and_Qt_combination and the one below
<cjwatson> it's quite a common pattern
<xnox> right. and also not a regression from upload that's in release already. bah.
<infinity> cjwatson: That's the thing that was fixed in the infamous Qt5.2 ABI break, right?
<cjwatson> AIUI
<infinity> So, now we wait 5 years for everyone to port to Qt5, and we're saved.
<shadeslayer> anyone have a clue what the heck "Back" is http://imgur.com/X5wBZGf
<infinity> shadeslayer: If I had to guess, I'd say a bug. :)
<shadeslayer> ^_^
<shadeslayer> infinity: what would I report that against btw?
<infinity> gfxboot-something?  cjwatson knows that bit better than I.
<xnox> shadeslayer: infinity: well the bug is in new syslinux & the temporary fix we placed to get gfxboot working at all. I believe to many menus are now included by default hence "Back..." and "Help..." options which have not been there before.
<shadeslayer> xnox: OEM mode is missing too
<xnox> it's better that, than not having graphical boot at all.
<shadeslayer> https://bugs.launchpad.net/ubuntu/+source/syslinux/+bug/1334189
<ubot93> Launchpad bug 1334189 in syslinux (Ubuntu) "syslinux offers no OEM mode on Kubuntu Utopic Alpha 1" [Undecided,New]
<cjwatson> gfxboot-theme-ubuntu
<xnox> shadeslayer: i don't think it's a bug against syslinux though...
<cjwatson> I did a quick fix last week, haven't yet had time to tidy up everything that's left
<shadeslayer> ok, I've changed the affects
<cjwatson> Is it critical for alpha 1?
<infinity> I wouldn't imagine so.
<infinity> Unless Kubuntu's really stepping up their Alpha 1 requirements.
<xnox> shadeslayer: you should be able to still boot in OEM mode by manually typing the right cmdline arg...
<shadeslayer> Hm, nope, should be fine, just better have it documented then
<infinity> I think ours used to be "it boots, installs, and your computer doesn't set itself on fire and dive out the window".
<shadeslayer> xnox: yeah
<shadeslayer> infinity: words to live by
<shadeslayer> :P
<cjwatson> Well mostly I just wanted to know how rapidly I was dropping everything to investigate it :)
<cjwatson> It's probably not too hard to fix but would be a respin-world
<cjwatson> Now admittedly I'm sort of looking forward to finding out how fast we can do that now, but maybe shouldn't do it just 'cause :)
 * shadeslayer points out that Kubuntu is even oversized at the moment
<cjwatson> Meh
<cjwatson> The size limits are artificial now anyway :-/
<shadeslayer> cjwatson: hah, because of the new build infra ? :D
<cjwatson> Right
<shadeslayer> true :)
<cjwatson> It's probably doable inside two hours, depending on buildd load
<cjwatson> I'm working on the problems that cause occasional livefs failed-to-upload errors, BTW
<cjwatson> They aren't new (they happen from time to time on package builds too) but the rate is high enough with livefses to be worth sorting out
<infinity> cjwatson: Rate's pretty low with packages.  Perhaps relating to filesizes/timeouts?
<shadeslayer> xnox: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1334199
<ubot93> Launchpad bug 1334199 in ubiquity (Ubuntu) "ubiquity-kde fails to install Kubuntu in Spanish" [Undecided,New]
 * shadeslayer tries with other languages
<cjwatson> infinity: Probably, yes.  We've seen three so far with livefses, which is high considering the build count.
<cjwatson> infinity: But it's easy for the librarian client to retry.
<xnox> uploaded libavg, zoneminder, mediatomb. Also uploaded gnome-media-player the last package to transition from xine-lib -> xine-lib-1.2, such that xine-lib can be removed from the archive.
<xnox> fixed visp is in debian new.
<cjwatson> xnox: what's wrong with the visp no-change rebuild I just uploaded? :)
<xnox> cjwatson: haha =)
<xnox> if that works, then we are golden
<xnox> what's left? performous, dvdstyler, mpv/ppc64el, jitsi, mplayer?
<cjwatson> ah, rockne-06 can talk to ports.ubuntu.com now, so I might have a look at mpv
<cjwatson> I have dvdstyler in progress, mostly done, just need a bit more time to finish it
<infinity> cjwatson: porter-ppc64el no good?
<cjwatson> infinity: didn't want to potentially pollute its one chroot with -proposed
<infinity> cjwatson: Too late for that, all the porters have proposed enabled.
<cjwatson> ah, well, shrug
<infinity> But man, need to find a round tuit to mangle dd-schroot stuff for our porters.
<xnox> Ampelbein: can you please merge jitsi? or should I look into it?
<Ampelbein> xnox: Please do it, I sadly don't have time currently.
<xnox> Ampelbein: ok, thanks.
<cjwatson> infinity: Does https://launchpadlibrarian.net/178169679/buildlog_ubuntu-utopic-ppc64el.mpv_0.3.11-1_FAILEDTOBUILD.txt.gz imply that __APPLE_ALTIVEC__ is just broken on ppc64el?  It's causing bool to be defined to an altivec thing that apparently doesn't support being passed to the ! operator, which seems kind of busted
<ScottK> shadeslayer: The 4.13.2 stuff that isn't on the ISO is stuck behind other packages that there's no way to get migrated without violence to the archive.
<ScottK> You've got all you're going to get for Alpha 1.
<shadeslayer> ack
<infinity> cjwatson: Without looking, I'd have assumed that it implies an endian issue in disguise, but disabling Altivec and making IBM fix it is usually the simple way forward. :P
<shadeslayer> all proposed migration output said was it was due to the migration block
<shadeslayer> so I don't know why it really didn't migrate
<ScottK> It was all blocked in britney before the block was in place.
<shadeslayer> ScottK: right, but why? :)
<infinity> cjwatson: The following angry errors with "bool" and "int" in the same sentence sort of point to endian issues, since turning ints into bools and then flipping them backwards explodes spectacularly.
<ScottK> shadeslayer: Mostly due to the libav transition, but other not easily fixable stuff.
<xnox> cjwatson: i've yet to see altivec work on ppc64el. All codes that i've tried, even with patches from ibm folks didn't not compile, or didn't link, or had further ELFv2 dislikes.
<infinity> xnox: We have lots of altivec working on ppc64el.
<ScottK> Trust me, I fixed everything that was this week fixable yesterday.
<shadeslayer> aha
<cjwatson> infinity: wouldn't those be runtime errors?
<infinity> cjwatson: Well, not the incompat type error.  But yeah, the exclamation mark one is definitely a new one on me too. ;)
<cjwatson> I don't *think* it's endianness, it basically seems to be using BYTE_ORDER
 * infinity grabs the source.
<infinity> cjwatson: Where is this bool->altivec definition you speak of?
<cjwatson> infinity: /usr/lib/gcc/powerpc64le-linux-gnu/4.8/include/altivec.h
<xnox> infinity: hm, yeah looks like most things got fixed that i was stumbling upon.
<xnox> e.g. libav is build with altivec now, et.al.
<infinity> cjwatson: Oh!
<cjwatson> At least I think that's what it is; can't see what else would be inventing __vector __bool int
<shadeslayer> ScottK: do we still want to release the Active ISO's
<cjwatson> infinity: -mno-altivec does make it build, so let me know if you think I should just do that ...
<infinity> cjwatson: Go ahead.  I'm trying to figure out the weirdness here with a simple testcase, but my simple testcase might be too simple. :P
<xnox> Ampelbein: jitsi uploaded.
<infinity> cjwatson: Obviously something nastier at play here than just the altivec/bool combo, since this works fine: http://paste.ubuntu.com/7699872/
<cjwatson> infinity: Right, maybe try with SDL
<cjwatson> (uploaded)
<infinity> cjwatson: Although, suspiciously, the disassembly of building that with or without altivec is the same.
 * infinity scratches his head and thinks this isn't a rathole he should dive down right now.
<cjwatson> Oh, I see why vtk6 is showing up on the tracker.  Disentangling.
<cjwatson> (libvtk6 -> libvtk6.1 sub-transition, not cleared out of -proposed)
<cjwatson> dvdstyler fixed for libav 10 et al.  Judging from the Debian bug we'll probably end up demoting performous.
<cjwatson> mplayer's been removed from Debian, and mplayer2 Provides: mplayer, but we'll need to do something about the dependencies on mencoder
<infinity> cjwatson: A provides isn't good enough to force upgrades either.  Does mplayer2 not give me a transitional package?
<cjwatson> infinity: haven't checked, don't think so though
<infinity> cjwatson: Right, we'll want to fix that, I guess.
<cjwatson> I've taken to using mpv myself, but ...
<infinity> I use mplayer.  I wonder how much worse mplayer2 is.  I guess I'll find out really soon. :/
<infinity> I seriously wish this ffmpeg/libav battle of egos could be resolved.
<infinity> cjwatson: There's a d-i for you.  I reviewed your minimal changes in bzr, and they seem fine to me, if you want to review the rest.
<cjwatson> I assume the trusty stuff is mostly copy-and-pasted
<infinity> cjwatson: Some 'find | xargs sed $saucy > $trusty' sort of action, yeah.
<cjwatson> done
<infinity> (The actual shell was hideous, we'll just pretend the above covers it)
<xnox> bug #1334262
<ubot93> bug 1334262 in xine-lib (Ubuntu) "RM: xine-lib superseeded by xine-lib-1.2" [High,Confirmed] https://launchpad.net/bugs/1334262
<infinity> cjwatson: Hrm.  precise isn't building with PROPOSED=1 ... Is that because it's still broken, or because no one turned it on?
<infinity> (Noted because I was trying to sort out if I should change the seeds or not, and I guess the answer is 'not')
<cjwatson> infinity: It sure is
<cjwatson> I turned it on yesterday
<cjwatson> We might not have had a full build cycle yet
<infinity> Err, wait.  I re-learn this every point release, I think.  It's in a config file, not in crontab, isn't it? :P
<cjwatson> It's in cdimage/etc/config, yes
<infinity> Yeah, just found it with greppery.
<infinity> I don't know why I forget that every time.
<cjwatson> Worked better there than in crontab, in practice, but it used to be in the crontab
<infinity> cjwatson: Yeahp, makes more sense in a conffile, I'm just really crap at learning new tricks (says the man who still types -rfakeroot)
<cjwatson> :)
<infinity> cjwatson: Of course, I probably should have testbuilt that before I uploaded.  Want to take bets on if it'll fail on image size constraints or something?
<cjwatson> Pass :)
<infinity> wget-udeb surely adds a bit too.  I guess I'll play my favourite video game (watching build logs) and see. :P
<cjwatson> One of these days maybe I'll convert build logs to longpoll
<cjwatson> Although the "how many tabs can you have longpoll in" game might need to be fixed first ...
<cjwatson> (Which is a bit hard for me)
<ScottK> shadeslayer: No idea.
<shadeslayer> ScottK: kdelibs uploaded with security fix for trusty
<cjwatson> xine-lib removed
<stgraber> shadeslayer: not sure what you want me to do ...
<infinity> cjwatson: You should have taken the bet.
<infinity> mcopy -i./tmp/trusty-netboot/boot.img ./tmp/trusty-netboot/initrd.gz ::initrd.gz
<infinity> Disk full
<infinity> And I should have test-built, obviously.  *sigh*
<cjwatson> libavg will be synced; performous should be demoted to -proposed once we're otherwise ready; vtk6 sorted; nepomuk-core false positive; so it's just sorting out mplayer now, I think
<infinity> cjwatson: I'll fix and actually test-build this time.
<cjwatson> ta
<infinity> cjwatson: Hrm.  Should we be concerned about the python traceback vomit from help-to-gfxboot.py in those build logs?
<cjwatson> Slightly but not hugely.
<cjwatson> Translation breakage, but it should tolerate it.
<infinity> Oh, I guess it's been happening pretty much forever.
<cjwatson> Yeah
<cjwatson> Ah, my NBS removals have caused vtk6 and wxsvg to show up across the board on the libav10 tracker now.  They're both false positives for the same reason as nepomuk-core.
<infinity> cjwatson: Fixed d-i in the queue.
<infinity> -rw-rw-r-- 1 adconrad adconrad 1.7G Jun 25 09:24 debian-installer-images_20101020ubuntu136.19_amd64.tar.gz
<infinity> That's getting impressively large. :/
<infinity> slangasek: Want to review that 2-line debian-installer fix in the precise queue?
<cjwatson> infinity: I'll do it in a moment, sorry
<infinity> cjwatson: Oh, thanks.  Wasn't sure if you'd disappeared for the day.
<cjwatson> No, just some calls
#ubuntu-release 2014-06-26
<shadeslayer> can someone mark the kubuntu amd64 ISO's as ready?
<shadeslayer> Riddell: ^^
<shadeslayer> I'm running the final test on the i386
<infinity> shadeslayer: I can mark it.
<Riddell> I'll do it
<infinity> Or Riddell can. :)
<shadeslayer> cheers :P
<Riddell> done! (although I'll test it myself now to make sure I'm happy too)
<shadeslayer> heh :P
<shadeslayer> Riddell: I've not tested active btw
<Riddell> oh we're not releasing active
<Riddell> I'll stop that from building when it reaches the top of my todo
<shadeslayer> cheers
<shadeslayer> ScottK: mind accepting kajongg as well
<shadeslayer> or anyone else btw ^^
<shadeslayer> it fixes a bug where kajongg is not installable
<mlankhorst> can someone promote  the whole -lts-trusty stack?
<mlankhorst> and libdrm in saucy too
 * cjwatson notices bug 1327825.  I guess there aren't any d-i-based images in the alpha ...
<ubot93> bug 1327825 in debian-installer (Ubuntu) "Utopic mini.iso still using Trusty software sources" [Undecided,New] https://launchpad.net/bugs/1327825
<infinity> cjwatson: lubuntu, but perhaps untested.
<cjwatson> Actually that bug was about netboot.  cdrom-detect does need to be updated (doing now), but maybe it's overridden somehow for our images ...
<infinity> The string "trusty" doesn't show up in d-i, but might be some other udeb being grumpy.
<infinity> mirrors.h:	"trusty",
<infinity> cjwatson: Oh, looks like I found that after you. :P
<cjwatson> Yeah, I'm doing the usual three
<cjwatson> Unaccountably forgot this cycle
<infinity> cjwatson: Probably because you didn't do the switch this time, and you're the only one with that list in your head.
<cjwatson> Well except for NewReleaseCycleProcess :P
<infinity> cjwatson: Yeah, whoever did the new d-i probably wasn't reading that either. ;)
<infinity> cjwatson: A comment above build/config/common:DEBIAN_RELEASE in d-i that points out the other packages that need to be in sync might not go amiss.
<cjwatson> Yeah, will do
<xnox> i think i've only fixed one thing that was needed to make netboot images working, hoping that someone else would do the other bits, as i didn't know which ones they were and where to find it.
<xnox> and I always fail to find NewReleaseCycleProcess, somehow i can never remember that name.
<cjwatson> Yeah, you confused me, if you hadn't done it at all I'd have probably remembered :)
<cjwatson> Oh well, sorting now
<xnox> sorry
<xnox> or better i should learn / check for the future where all the other missing pieces are.
<xnox> "Merge cdrom-detect, choose-mirror, and iso-scan if necessary and update cdrom/suite and mirror/suite debconf templates to include a choice for the new release and update any previous default." if i remember right I did choose-mirror only.
<cjwatson> There's a comment in the d-i source now.
<cjwatson> You didn't do any of them.
<xnox> ha, that can't be good.
<cjwatson> All uploaded now, and I have a d-i upload to do in a bit anyway.
<infinity> cjwatson: Thanks for the comment.
<apw> that xorg-lts-transitional is the trusty end of the xorg-lts-trusty bits
<mlankhorst> I may be forced to move to trusty 'soon' :P
<Riddell> infinity: link for the announcement https://wiki.ubuntu.com/UtopicUnicorn/Alpha1/Kubuntu
<stgraber> Riddell: s/infinity/stgraber/ :)
<stgraber> Riddell: but noted, thanks
<Riddell> oh sure
<mlankhorst> hm the *-lts-trusty packages from 131816 still need to be promoted
<mlankhorst> infinity: can you take a look at promoting them? g2g!
<rtg> mlankhorst, bug arges. infinity is on vacation
<arges> mlankhorst: which packages?
 * arges reads backlog
<arges> mlankhorst: ok... looking at htis i'm not entirely sure of how the transitional package dependencies work. so I'm not entirely comfortable reviewing this
<stgraber> I'm planning on releasing alpha-1 in about 2 hours, so flavour leads, please give me your URLs and any extra text I should include!
<stgraber> I'm going to grab some lunch now and will do the usual announcement copy/pasting once I'm back
<Riddell> stgraber: "Kubuntu development is now focussing on the next generation of KDE Software, Plasma 5.  This is not yet stable enough for everyday use, so we are still shipping the Plasma 1 desktop on our image which has been updated to the latest version in the alpha."
<Riddell> or something like that
<Riddell> stgraber: freeze thawing any time soon?
<stgraber> Riddell: well, I was hoping to get some more feedback from the other leads on whether they're happy with what they've got now
<stgraber> I'm not seeing a whole lot of ready on the tracker...
<stgraber> utlemming: any ETA on cloud images readiness?
<stgraber> also, if there's someone from ubuntu gnome around, same question ^
<utlemming> stgraber: they are more or less ready, just waiting on the test suites to finish
<utlemming> stgraber: the images are all staged, and the test are looking good
<stgraber> dropping archive block as everyone appears ready
<JackYu> stgraber, please find release note of Ubuntu Kylin here, https://wiki.ubuntu.com/Ubuntu Kylin/1410-alpha-1-ReleaseNote
<utlemming> stgraber: okay, cloud images are ready
<stgraber> utlemming: what's the link for the alpha-1 images download? I'm pretty sure the one I have is wrong :)
<utlemming> stgraber: it will be http://cloud-images.ubuntu.com/releases/utopic/alpha-1/
<stgraber> utlemming: ok, good. I still had the uec stuff in my draft :)
<utlemming> stgraber: is iso.qa.ubuntu.com having issues? It taking forever to load :/
<stgraber> announcement: http://pad.ubuntu.com/utopic-alpha1
<stgraber> hmm, yeah, it's pretty slow...
<stgraber> utlemming: pinged IS as I've done all I can do on that box by myself and that doesn't appear to help...
<stgraber> flavour leads, once again, the link is at: http://pad.ubuntu.com/utopic-alpha1
<stgraber> I'll be publishing things as soon as the tracker feels like talking to me again and I'll push the announcement in about an hour
<stgraber> wxl, ScottK, Riddell, JackYu, utlemming: publishing in progress, please take a look at the announcement.
<utlemming> stgraber: cloud images are being made public now
<stgraber> utlemming: cool, thanks
<Riddell> stgraber: looks good
<Riddell> oh but wait!
<Riddell> there's not a topical quote at the top!
<stgraber> feel free to add one :)
<Riddell> that's the most important thing for an alpha 1 announce
<stgraber> cjwatson: FYI, cron.source still seems a bit buggy, I had to move things around and mangle the links by hand
<slangasek> stgraber: where do we stand on alpha-1?
<slangasek> I understand that there was some pushback regarding trying to get pulseaudio in due to the alpha-1 freeze
<stgraber> slangasek: the source isos took a while to build but they're done now. I just did a sync-mirrors, so waiting another 30min for torrent to catch up and I'll push the announcement
<slangasek> which doesn't make sense to me, as there's no requirement for alpha images to be in sync with the archive at release time
<stgraber> slangasek: the block has been gone for a while now so people can poush as they wish
<slangasek> stgraber: ok; so we're unfrozen and pa should be able to go in?
<slangasek> alright
<stgraber> slangasek: yeah, that didn't come from me, not sure who said that...
<slangasek> that was from ScottK yesterday
<slangasek> ok, looks like pulseaudio made it in once the block was out
<stgraber> announcement sent out
* stgraber changed the topic of #ubuntu-release to: Released: Trusty Final, Utopic Alpha 1 | Archive: Open | Utopic 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
<wxl> oh and i prefer tea not beer XD
<slangasek> stgraber: I dispute this Shel Silverstein lyrics credit :)
<slangasek> the Internet gives nothing authoritativve
<stgraber> Riddell: ^
<slangasek> well, ok, maybe it was Silverstein
<slangasek> apparently the provenance was lost by the time it got to me!
<cjwatson> stgraber: Yeah, it's been in the back of my mind for a while but I haven't had a chance to sit down and figure it out yet ...
#ubuntu-release 2014-06-27
<jibel> could someone from the SRU team review and approve update-manager and update-notifier in the unapproved queue of precise-proposed. It's bug 1333728
<ubot93> bug 1333728 in update-notifier (Ubuntu Precise) "update-manager should support HWE EOL transition" [Undecided,In progress] https://launchpad.net/bugs/1333728
<shadeslayer> could someone explain why bespin hasn't been migrated from proposed?
<cjwatson> shadeslayer: That cluster apparently makes kubuntu-full uninstallable
<cjwatson> Let me see if I can work out why
<shadeslayer> mmm
<shadeslayer> cjwatson: oddly enough, it doesn't say that in the output
<cjwatson> Yeah it does
<shadeslayer> it does?
<cjwatson> Right down at the bottom
<cjwatson> Trying easy from autohinter: kde-workspace/4:4.11.10-0ubuntu4 kde-style-qtcurve/1.8.14-3build1 kwin-style-crystal/2.2.1-2ubuntu2 bespin/0.r1552+nmu1build1 kdeartwork/4:4.13.2-0ubuntu2
<cjwatson> [...]
<cjwatson>     * i386: kubuntu-full
<shadeslayer> oh
<shadeslayer> I was only reading the bespin part and was quite confused
<cjwatson> Yeah, don't do that
<cjwatson> shadeslayer: kubuntu-full Depends: kde-workspace-data-extras, which is gone from kde-workspace in -proposed
<shadeslayer> ok, lemme fix that
<cjwatson> So either put back kde-workspace-data-extras or drop the dependency
<cjwatson> Maybe it should be just -data now?
<shadeslayer> it's a transitional package
<shadeslayer> so we need to update kubuntu-full now
<LocutusOfBorg1> cjwatson, and for libav transition? mplayer is the last I think
<cjwatson> Few other bits that didn't show up for one reason or another - I've been test-building mrpt
<zul> can an archive admin have a look at python-oslo.db its preventing keystone from building in our lab
<wxl> stgraber et al. could you please turn the cron job back on for the flavors that did alpha1?
#ubuntu-release 2014-06-28
<stgraber> wxl: oops, right, doing that now
<stgraber> wxl: done
#ubuntu-release 2014-06-29
<saiarcot895> Would adding multiarch support for a library qualify for a SRU?
<cjwatson> That would normally be pretty dubious, because adding multiarch support to libraries has often been known to break things further up the stack (normally things that are misbehaving in some way, but even so).  Unless it was quite an obscure library, I think we'd require a fairly high standard of proof.
<saiarcot895> cjwatson: True. Would the same thing apply if the maintainer thought he was adding multiarch support, but didn't really add support?
<cjwatson> Err, SRUs should normally be cherry-picks of selected fixes, not wholesale backports of updated packaging.
<cjwatson> If I saw an upload by that description, I'd probably reject it on the grounds that it clearly wasn't a minimal fix for whatever it was trying to fix.
<saiarcot895> And I wouldn't blame you.
#ubuntu-release 2015-06-22
<coreycb> Hi sru team, python-keystonemiddleware is in the utopic-proposed queue and could use a review when you have a moment
<stgraber> doing alpha-1 prep work now, will turn off cron for participating flavours, setup the milestone on the tracker and kick a first build
<stgraber> utlemmin`: you guys are tracking alpha-1 on cloud.qa.u.c right? nothing for me to publish on iso.qa.u.c
<utlemmin`> stgraber: correct, that is theplan
<stgraber> cool
<stgraber> cron disabled for participating flavors: mate, lubuntu, kylin and kubuntu
<stgraber> tracker is setup, I'm starting an initial build for each now
<stgraber> and build triggered, queuebot should be announcing them as they finish
<stgraber> at this point, I am NOT setting up a package block. Please let me know if your flavor needs it, for which package and for how long.
<wxl> whoa we have milestones on a monday?!
<infinity> wxl: No, but milestones don't start and end in a day.
<wxl> infinity: no, i mean we have milestone images for testing on a monday.
<boiko> hi, could anyone please check what is going on with telephony-service in the excuses page? It says there is a regression
<infinity> boiko: Retrying the boot test.
<boiko> infinity: thanks
#ubuntu-release 2015-06-23
<sil2100> Hello release team! I need to disable the system importer for a few minutes to do some copy-image operations without disruptions
<sil2100> ...and done, re-enabled again
<jamespage> arges, hey - I'd like to stick through oslo.messaging 1.8.3 as an SRU to vivid; it contains fixes only for rabbitmq and zeromq drivers - does that sound reasonable? it does *not* have a MRE
<arges> jamespage: so I think technically that's the Tech Board call. But if the SRU is bugfix only that seems reasonable. Also why isn't that package under the openstack MRE umbrella?
<jamespage> arges, https://bugs.launchpad.net/ubuntu/+source/oslo.messaging/+bug/1467959
<ubot93> Launchpad bug 1467959 in oslo.messaging (Ubuntu) "[SRU] update to 1.8.3" [Undecided,New]
<coreycb> RAOF, Hi, the latest openstack stable icehouse release is ready for sru review in the trusty-proposed queue.  there's also a smal python-keystonemiddleware sru in the utopic-proposed queue.
<jamespage> arges, MRE makes sense for this - I'll make an application to the TB alongside uploading this SRU.
<arges> jamespage: What other packages use oslo.messaging?
<jamespage> arges, just openstack
<jamespage> arges, we would run it through are standard -proposed validation testing - for both zeromq and rabbitmq
<arges> jamespage: i think given its isolated to openstack + it looks like bugfix only updates, I think this is a reasonable SRU. The MRE stuff would be helpful though in teh future to make any updates easier
<jamespage> arges, ack
<jamespage> arges, uploaded - emailing TB as well
<jamespage> between meetings :-)
<arges> jamespage: so productive
<coreycb> RAOF, can I also have python3-tempest-lib promoted to main?
<slangasek> infinity: have you seen that IS has asked about taking nusakan's /srv offline today to upgrade the space?  does that impact alpha-1 prep?
<slangasek> sil2100, robru, rsalveti: ^^ can you also let me know if this will interfere with phone or snappy work, to have no image generation between 2200 and 0000 UTC today?
<sil2100> slangasek: hey! The phone should be fine I suppose, I already did the image copies I needed and we don't need to build anything new
<sil2100> At least not today
<slangasek> sil2100: ok, thanks
<infinity> slangasek: It does, I've not gotten to my email yet.
<infinity> ... assuming I have email about that.
<wxl> what are these respins about?
<stgraber> wxl: what respin?
<wxl> stgraber: on lubuntu alternates
<stgraber> last build for lubuntu alternate was yesterday
<wxl> stgraber: true, but i didn't request itâ¦
<stgraber> that's the original build right after I setup the milestone
<wxl> huh, ok, didn't think so, but i'll take your word for it :)
<cjwatson> wxl: he mentioned it on this channel in advance
<stgraber> the .1 in the version is simply because there had been an automated (cronned) build earlier that day
<cjwatson> http://irclogs.ubuntu.com/2015/06/22/%23ubuntu-release.html#t17:18
<wxl> okie dokie
<wxl> sorry for harassing you guys :)
<stgraber> wxl: there's a link on the iso tracker page to see the build history for the milestone ("See removed and superseded builds too"). If you click that link, you'll see every build that ever made it to the milestone.
<stgraber> and in this case, you'd notice that there was only a single alternate build for lubuntu, so no respins
<utlemmin`> stgraber: it looks like we have a serious blocker for Alpha-1 -- EC2 instances do not boot https://bugs.launchpad.net/ubuntu/+bug/1468091
<ubot93> Launchpad bug 1468091 in Ubuntu "Ubuntu 15.04 Alpha-1 candidates do not boot in EC2" [Undecided,New]
<stgraber> oh, that's pretty bad indeed
<utlemmin`> stgraber: yup...I can't put my finger on the exact cause, but at first blush it looks like udev is not creating the /dev/disk/by-* targets for Xen block devices
<utlemming`> stgraber: at this point, Cloud Images are likely to miss Alpha-1.
<stgraber> utlemming`: ok
<stgraber> utlemming`: not much point releasing just on the other clouds I guess?
<utlemming`> stgraber: we could flag Azure and GCE and others, but with broken Xen, I would rather delay.
<stgraber> ok
<utlemming`> stgraber: we've confirmed that the issue is most likely systemd
<stgraber> so there's some hope for this to get fixed in time after all
<stgraber> systemd is a bit easier to update on short notice than a kernel
<stgraber> turning all cronjobs off on nusakan in preparation for a disk resize
<stgraber> pjdc: ^
<pjdc> stgraber: great, thanks
<stgraber> pjdc: looks like we've got nothing running on nusakan at the moment, so you can go ahead whenever you want
<stgraber> pjdc: I suspect most of us have shells open on /srv, so you'll probably have to kick all those ssh connections before you can umount
<pjdc> there are a few indeed
<infinity> stgraber: I'd hope it's not the kernel, since it's the wily kernel still.
<infinity> Err, vivid.
<infinity> The other wily.
<infinity> utlemming`: Do you have a console on a failed Xen instance that one can play with?
<infinity> utlemming`: I'm curious if the block devices are there at all, and if one can force udev to love them.
<pjdc> stgraber: all done
<stgraber> pjdc: perfect, re-enabling cron jobs now
<stgraber> and done
<slangasek> hum, so we didn't wait until 2200? :)
<slangasek> well I'm glad it came back up, since I didn't see any answer to my question about backups of keymatter :/
<infinity> Maybe someone decided on 2200 BST instead of 2200 UTC.
<infinity> pjdc: Not that I'm complaining, but only an extra 1T?
<pjdc> no, i jumped the gun on my own recognizance
<infinity> (I think I can clean out some bits anyway, so we're not at 73% anymore)
<infinity> Like... All of lucid.
<slangasek> pjdc: right; do you happen to be able to tell me what kind of backups we have of the irreplaceable bits on nusakan's /srv?  I fear the answer might be "none"
<pjdc> our impression in IS was that /srv was all recreatable - is that not the case?
<slangasek> hahahano
<slangasek> I was going to back up the gpg key directories before the maintenance window just in case, but that apparently came early ;)
<pjdc> good times
<infinity> I was pretty sure lamont and I had a discussion about signing key backups for ftpmaster and cdimage a few months ago, and he devised a plan.
<infinity> lamont: ^
<infinity> (devised and executed, I believe)
<pjdc> we have a new backup system in place but it's probably especially suited for key material
<pjdc> er, *not* especially suited
<infinity> pjdc: No, I mean, I think lamont did something very specific just for keys.
<slangasek> pjdc: the web trees are recoverable from the mirrors; the ftp mirror is obviously just a cache that will repopulate itself if needed; the code and config is all in bzr and I have it mirrored locally if nothing else
<infinity> pjdc: At least, we had discussions about how to do so.
<slangasek> but the keys are not recreatable, and not replaceable without people booking flights
<infinity> pjdc: Though, if this was done, but only documented in lamont's brain, that's about as good as not done.
<slangasek> so it would be good to have confirmation if there is a backup
<lamont> infinity: I have no recollection of this thing of which you speak
<slangasek> hah
<infinity> lamont: Excellent.  Way to be old.
<lamont> kids!
<infinity> lamont: We had a discussion ages ago (you started it) about good ways to backup ftpmaster and cdimage's signing keys to adelie, and I was pretty sure you even wrote something.
<infinity> lamont: The second half might be a lie, though.
<infinity> lamont: If you log our queries, you might even have evidence of this.  I do not. :/
<lamont> infinity: timeframe?
<infinity> lamont: This is where my own aging is problematic.  As has been pointed out by young kids like stgraber and wgrant, I often refer to last week as "months ago" and last year as "a few weeks back".
<lamont> ah, yes, time dialation
<lamont> that or hanging with the Doctor.
<lamont> infinity: I presume it would have been PM and cnaonical's srefver?
<infinity> lamont: Seems likely.
<lamont> discussion involving sycamore and nusakan in 2012-02-16
<infinity> lamont: That seems like a few too many months ago. :)
<infinity> lamont: Maybe "grep gpg adconrad*.log"?
<infinity> lamont: Since I think you were playing with code examples.
<infinity> lamont: Or this is all an elaborate (and super boring) dream.
<infinity> lamont: Which I wouldn't rule out.  I dream of some amazingly mundane things.
<lamont> I am finding nothing
<infinity> lamont: Huh.  Okay.  Chalk it up to me being weird.
<infinity> lamont: Or old age taking us both.  Pick one.
<lamont> I choose "3"
<pjdc> slangasek: infinity: i've created RT#82293 for the key backup
<slangasek> pjdc: thanks
<infinity> pjdc: Ta.
<RAOF> coreycb: Can do the SRU review; don't have the authority to promote python3-tempest-lib :)
#ubuntu-release 2015-06-24
<RAOF> coreycb: Would you like to roll in the neutron 1:2014.1.4-0ubuntu3 that's still waiting in the trusty-unapproved queue? That's the fix for lp: #1463844
<ubot93> Launchpad bug 1463844 in neutron (Ubuntu Utopic) "Missing logrotate configuration for vpn_agent and metering_agent" [Undecided,In progress] https://launchpad.net/bugs/1463844
<wgrant> RAOF: The SRU from https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1324391 has made python-pip uninstallable.
<ubot93> Launchpad bug 1324391 in python-pip (Ubuntu Trusty) "pip 1.5.4 import an invalid dependencies " [High,Fix released]
<wgrant> python-pip -> python-pip-whl -> python-requests-whl
<wgrant> And python-requests-whl is only in trusty-proposed.
<wgrant> So python-pip from trusty-updates is uninstallable.
<wgrant> setuptools and six also seem to be missing their -whl in -updates.
<RAOF> wgrant: Balls.
<wgrant> RAOF: Quite.
<wgrant> RAOF: I'm tempted to roll back -updated to -1ubuntu1, unless the other three SRUs are ready.
<wgrant> Though I don't know how the phased updater deals with the currently phased version vanishing.
<wgrant> infinity: ^^
<RAOF> Requests is ready, modulo an autopkgtest regression for neutron which may or may not be its fault.
<RAOF> As is six.
<RAOF> Hm. I'm tempted to let requests and six through; the neutron autopkgtest that they fail has never passed in trusty-updates, and there's a neutron SRU in unapproved that needs touching before acceptance and should get whatever autopkgtest fixes are necessary.
<wgrant> You don't think the new requests will break existing neutron deployments?
<RAOF> It doesn't appear to; the neutron autopkgtests pass until they die in apparently the same way they've been dying since Feb.
<RAOF> That said, killing -1ubuntu3 from updates seems like a good idea.
<wgrant> The phased updater successfully makes things disappear due to Soyuz bugs, so I suspect it will stop phasing something if it goes away.
<wgrant> So it's probably safe to delete -1ubuntu3 and restore -1ubuntu1 in its place.
 * RAOF would like it if his laptop didn't mysteriously hang and then no longer see the bluetooth device, but he.
<wgrant> Heh
<RAOF> Also: wtf? Where has my ipv4 gone?
<wgrant> Do you want me to do the remove-package + copy-package?
<RAOF> wgrant: Yes please.
<RAOF> wgrant: I can't reach launchpad for some reason.
<wgrant> That's a bit weird.
<RAOF> So, it would be nice if my laptop didn't choose this particular moment to become really flaky.
<wgrant> Picky.
<RAOF> I think *this* boot I have both bluetooth *and* ipv4 internet!
<RAOF> Have you done the remove+copy?
<wgrant> Yup, -1ubuntu1 is back in place.
<wgrant> Published, in fact.
<infinity> wgrant: The phased updater is bdmurray's baby, not mine, but if you're rolling back to a previously known-good version, just phase it to 100% out of the gate, and life should be fine.
<wgrant> infinity: My concern was that it might decide that 10% was good, so it would bump to 20% and supersede the old version.
<wgrant> But it hasn't done that yet, and the fact that it doesn't revive binaries after Soyuz eats them suggests that it isn't going to.
<infinity> wgrant: Yeah, I've never looked at the code, but it might be sort of smarter than that.  Or, as you hint, so dumb that it appears smart in this case.
<infinity> I should fix the eating binaries bug, though.
<infinity> I mean, not on the soyuz side, that's your mess.
<wgrant> I looked at the code once but didn't get past about line 50.
<infinity> But by getting around to triggering the world.
<wgrant> Because I died of XSS.
<infinity> <= One run per publisher pretty much guarantees avoiding the override bug.
<wgrant> Indeed.
<infinity> Well, until an AA overrides something in the same run as the phased updater does. :P
<infinity> But if an AA is overriding things in -updates, they've already messed up, and should be prepared to deal with the fallout.
<cjwatson> infinity: Looks like the Haskell transition got close enough to some relevant tipping point that it traded things off and disentangled itself from the nettle transition.  So, um, win?
<cjwatson> I suspect it was because the new GHC has GHCi on all Ubuntu architectures and so made various odds and ends installable on three more architectures, enough to balance out the incomplete transition.
<infinity> cjwatson: GHCi on all 6 arches?  Ooo.
<wgrant> We'd best add some more.
<cjwatson> OMG openstack python3ness
<cjwatson> presumably a long way to go ...
<sil2100> infinity: hey! I'm looking for someone with ubuntu-cdimage knowledge, as I don't know the code - both our touch images for vivid and wily failed building yesterday due to some qatracker milestone issues
<sil2100> infinity: could you help out?
<infinity> sil2100: The person you want for isotracker stuff is stgraber.  But lemme have a quick look before I go to bed.
<sil2100> infinity: thanks! The logs have some info: vivid/daily-preinstalled-20150624.log and wily/daily-preinstalled-20150624.log
<infinity> sil2100: Which project?
<sil2100> ubuntu-touch
<sil2100> Tried looking at the code, but it would probably take much longer for me to trace back to where it's getting all the milestone information from
<sil2100> And where it's used
<infinity> sil2100: So, that doesn't look like a failure... Just a failure to post to the tracker.
<sil2100> infinity: oh, is that normal?
<infinity> sil2100: I certainly see images here: http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20150624/
<sil2100> Yeah, the rootfs built correctly, but I thought it failed later in the build image steps
<infinity> sil2100: No, it's not normal for it to fail to post, but it's also not fatal.  And I assume you don't use the ISO tracker anyway.
<sil2100> infinity: ah, ok, thanks :)
<sil2100> Nevermind then!
<infinity> sil2100: Anyhow, you can probably bug stgraber to figure out why the tracker integration is breaking, but it shouldn't be harming you any, I wouldn't think, unless your tools rely on the tracker instead of hitting cdimage directly.
<cjwatson> component-mismatches-proposed fixed
<cjwatson> https://git.launchpad.net/germinate if you want the gory details
<coreycb> RAOF, yes, I'll roll in the neutron 1:2014.1.4-0ubuntu3 trusty updates, thanks!
<Riddell> anyone know why "marble,calligra,libkgeomap" won't transition? I can't work it out from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<cjwatson> Riddell: Given that the same packages are mentioned in transition groups further up, I think they're tangled in a larger transition
<cjwatson> Riddell: You can see them mentioned in the one starting "abiword,libwps,..."
<cjwatson> Riddell: micahg mentioned some status on that on #ubuntu-devel earlier today
<Riddell> mm thanks
<utlemming> infinity, stgraber: pitti's upload for udev (https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1468091) is confirmed to fix Cloud Images. If we can this promoted, I can trigger a new set of builds.
<ubot93> Launchpad bug 1468091 in systemd (Ubuntu) "[udev] Ubuntu 15.10 Alpha-1 candidates do not boot in EC2 with Xen" [Critical,Fix committed]
<Laney> cjwatson: if you've some time, can you maybe help execute his proposed solution?
<cjwatson> Laney: I don't
<cjwatson> (sorry)
<Laney> 'k
<coreycb> RAOF, arges: we have a new neutron 1:2014.1.5-0ubuntu1 in the trusty upload queue that includes the updates from neutron 1:2014.1.4-0ubuntu3.  can you review the most recent neutron 1:2014.1.5-0ubuntu1 and reject the other two that are in the unapproved queue?
<arges> coreycb: looking
<arges> coreycb: done
<coreycb> arges, thanks
<stgraber> sil2100: I'll take a look at the posting failure for touch
<mdeslaur> arges: the gtksourceview2 control file is automatically regenerated from control.in during build, the change wasn't a manual one
<mdeslaur> arges: can I re-upload them as-is?
<arges> mdeslaur: Yea makes sense, seems wierd it was dropping a name.
<mdeslaur> arges: yeah, it's odd
<mdeslaur> arges: do I have to re-upload them, or are they still available for you to release?
 * mdeslaur uploads them
<arges> mdeslaur: I can review from the Rejected queue... but re-uploading (As you've already done) is fine
<mdeslaur> thanks
<arges> sorry about the noise
<sil2100> stgraber: thanks! It's not anything serious though, I thought it is a real error by mistake
<stgraber> oh, that's one odd error
 * stgraber looks at tracker
<sil2100> Well, it's a real error, but not anything actually breaking image builds - that's what I meant
<stgraber> sil2100: so looks like somebody actually did disable those products on the tracker...
<stgraber> sil2100: but the log has since rotated so I can't see who
<stgraber> anyway, re-enabled
<sil2100> stgraber: oh, thanks o/
#ubuntu-release 2015-06-25
<Riddell> infinity: fixed I hope ^
<infinity> Riddell: Looks more reasonable to me.
<flexiondotorg> infinity, If possible I'd like to squeeze a package update in for the Alpha1.
<flexiondotorg> infinity, If I prepare the debdiff and tarball could your sponsor it?
<flexiondotorg> infinity, Fixes a bug raised in the ISO tracker.
<flexiondotorg> stgraber, See the above I message. Looks like you might be the right person to ask.
<infinity> flexiondotorg: I'm not really here, it's 4am for me.  Might want to find another sponsor who's slightly more awake (maybe Riddell can help you out).
<flexiondotorg> infinity, Sorry. Sleep well :-)
<flexiondotorg> Riddell, stgraber If submit the debdiff would you sponsor the upload so I can rebuild the Ubuntu MATE images?
<Riddell> flexiondotorg: ok
<flexiondotorg> Riddell, Many thanks. I'll ping you the LP in a bit. Just making the debdiff and testing.
<flexiondotorg> Riddell, https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1468725
<ubot93> Launchpad bug 1468725 in ubuntu-mate-artwork (Ubuntu) "ubuntu-mate-artwork 0.4.10 ISO tracker bugfix [debdiff attached]" [Undecided,New]
<flexiondotorg> Riddell, Thanks for helping, much appreciated.
<Riddell> hang on I haven't done it yet :)
<flexiondotorg> Riddell, Payment in advance ;-)
<Riddell> flexiondotorg: did you put your change into bzr?
<flexiondotorg> Riddell, Opps. One sec.
<flexiondotorg> Riddell, Pushed.
<Riddell> flexiondotorg: uploaded!
<flexiondotorg> Riddell, Thanks again. Will this go directly to the archive it will it have to be approved?
<Riddell> I guess there's a block on so it'll need to be unblocked
<Riddell> hmm no there's no block on
<Riddell> so it'll go in
<flexiondotorg> Riddell, Excellent.
<utlemming> Cloud Images are back on track...I'm running the tests through now.
<flexiondotorg> stgraber, Any idea when ubuntu-mate-artwork in wily-proposed will graduate to release?
<flexiondotorg> stgraber, I need to kick off a rebuild of the iso image with that package included.
<infinity> flexiondotorg: Should be all published to release now.
<flexiondotorg> infinity, Just checking....
<flexiondotorg> infinity, Yep, just dist-upgrade on my test box. Thanks.
<flexiondotorg> Riddell, Thanks for your help earlier. The one really obvious bug in Ubuntu MATE 15.10 Alpha 1 is fixed :-)
<flexiondotorg> infinity, I've requested rebuilds of Ubuntu MATE.
<coreycb> infinity, can you promote python3-warlock to main?
<infinity> coreycb: I can indeed.
<coreycb> infinity, thanks
<flexiondotorg> infinity, I requested rebuilds but haven't seen anything to indicate that something is happening. Is Ubuntu MATE building?
<infinity> flexiondotorg: It was last I looked.
<flexiondotorg> infinity, Yes, I've found the build logs. It's whirring :-)
<infinity> flexiondotorg: I still see livefs builds going at https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-mate
<flexiondotorg> Thanks infinity .
<infinity> flexiondotorg: Guessing that brownie doesn't have the fastest disk...
<flexiondotorg> infinity, I'd never seen that page before. Very useful. Thanks.
<infinity> wxl, Riddell, flexiondotorg: How are things looking from your end?  Looks like I'm taking over from stgraber today, as he's out sick.
<flexiondotorg> infinity, I'm just smoke testing the rebuilt isos.
<flexiondotorg> infinity, So far looks good.
<flexiondotorg> infinity, When do you want to release?
<infinity> flexiondotorg: When everyone's ready, ideally. :P
<infinity> flexiondotorg: But, the earlier, the better, cause I've been up all night.  Whee.
<Riddell> infinity: I've had 3 testers say it's good so I've marked as ready (1 is yet to put it on iso.qa)
<infinity> Riddell: Awesome, thanks.
<Riddell> infinity: https://wiki.ubuntu.com/WilyWerewolf/Alpha1/Kubuntu release page
<infinity> Riddell: Less fussed about people filling out pretty paperwork for alphas, but since you went to the trouble, I'll link it. ;)
<flexiondotorg> infinity, https://wiki.ubuntu.com/WilyWerewolf/Alpha1/UbuntuMATE
<infinity> wxl: *nudge*
<flexiondotorg> infinity, All set :-)
<infinity> flexiondotorg: Ta.
<infinity> So just waiting on lubuntu, then.
<flexiondotorg> infinity, Have the last vestiges of upstart been remove in 15.10?
<infinity> flexiondotorg: It's still there for user sessions, but we don't use it on boot anymore, if that's what you mean.
<flexiondotorg> infinity, User Sessions?
<flexiondotorg> infinity, I realise the boot process moved the systemd in 15.04 but in my testing of 15.10 alpha 1, it is measurably faster than 15.04.
<infinity> flexiondotorg: If it's faster, that could be some things moving from sysv init scripts to native units, or just general software improvements, who knows.
<flexiondotorg> infinity, Well boot is faster. But system performance is improved generally.
<infinity> flexiondotorg: As for user sessions, yes, some (many) desktop environments spawn an upstart --user that runs the DE and starts user services.  That should all be migrated in time too.
<flexiondotorg> infinity, Ah, that explains it.
<flexiondotorg> infinity, MATE uses systemd. Which is why I could find any trace of upstart in the boot/login trace.
<infinity> utlemming: While I'm waiting on wxl to wake up and tell me about lubuntu, how's life in cloudy land?
<utlemming> infinity: the tracker is not updated yet...but we're good to pull the trigger. Cloud Images are a go
<infinity> utlemming: Couldn't care less about the tracker, if you tell me they're good. :)
<utlemming> infinity: just tell when and I'll make Alpha-1 public
<utlemming> (for cloud images)
<infinity> utlemming: Kay.  Probably in a couple of hours, depending on lubuntu.
<davmor2> infinity: well cloudly land is like fog only much higher up ;)
<utlemming> infinity: ack...I have a conflict later this afternoon, but  either rcj or gaughen can handle the level pulling.
<infinity> utlemming: Or you can yank it early, if you don't care if it aligns with the announcement.  *shrug*
<wxl> infinity: good to go. marking them ready in 1m
<wxl> infinity: gotta get release notes together.
<infinity> wxl: Kay.  My announce email will point at https://wiki.ubuntu.com/WilyWerewolf/Alpha1/Lubuntu for you.
<wxl> sounds good infinity. thx
<infinity> wxl: Are you tested on PPC too, or skipping those?
<wxl> infinity: skipping. i leave them open for people to test but we don't intent to release any ppc except lts
<infinity> wxl: Check.
<wxl> infinity: dnoe
<teward> alpha one here we come XD
<infinity> Just spinning up source ISOs and waiting for torrents to be happy, then we're good to go.
<wxl> teward: well, depends on your vm
<wxl> oops wrong channel but yuou get the idea :)
<teward> wxl: i'll continue this in the right channel ;)
<wxl> heheh k
<bdmurray> In Launchpad is there a way to find the checksum for this package? https://launchpad.net/ubuntu/vivid/armhf/isc-dhcp-server-dbg/4.3.1-5ubuntu2.1
<infinity> bdmurray: In the UI, https://launchpadlibrarian.net/204021070/isc-dhcp_4.3.1-5ubuntu2.1_armhf.changes (linked from the build)
<infinity> bdmurray: But I'm sure the API knows too.
<bdmurray> infinity: I've figured it out from the API, was just trying to find in the UI.
<infinity> bdmurray: Right, from the UI, it's the "amhf build blah blah blah produced these files" link to get back to the build, then the .changes is there.
<infinity> bdmurray: Could probably use an "oh god, this UI is awful" bug, given that we go out of our way to present source hashes in a nice table on the SPR pages, but do nothing pretty for binaries.
<wxl> infinity: isn't 4.0 kernel coming this cycle?
<infinity> wxl: Yeah, it's in the kteam PPA, just ironing out a couple of last-minute wrinkles.  Should land early next week.
<wxl> infinity: thanks :)
<infinity> wxl: We tried last week and hit a bump or two and reverted to 3.19. :P
 * wxl nods
<wxl> understandable
<infinity> These source ISOs always take longer than I remember...
 * infinity twiddles his thumbs.
 * wxl moves this convo over to #lubuntu-devel
<infinity> utlemming: Okay, source is publishing now, torrents look good, I'll blat the announcement out in ~10m
<infinity> gaughen: ^
<gaughen> ahhhhhhhhhhhhhhhhhhhhh
<infinity> wxl, Riddell, flexiondotorg: ^
<wxl> infinity: almost done with release notes anyways
<infinity> gaughen: If you need more than 10m, let me know. :P
<flexiondotorg> infinity, Thanks!
<utlemming> infinity: CPC is sprinting, 10 minutes is fine
<infinity> utlemming: http://cloud-images.ubuntu.com/releases/wily/alpha-1/ seems 404ish.
<utlemming> infinity: yeah, it hasn't finished up yet. API calls to AWS are taking a bit longer today
<infinity> utlemming: Mmkay.  I can wait. :)
<infinity> utlemming: Ooo, I see (some) content.
<utlemming> infinity: yeah, just finished....you're good to send the email. rsync will catch up shortly
<utlemming> infinity: job is confirmed as complete
<infinity> utlemming: I can wait for rsync to finish, I'm not THAT impatient. :P
<flexiondotorg> infinity, Thanks for your help today.
<infinity> utlemming: Although, you seem to be rsyncing to sawo via some sort of bendy straw.
<utlemming> infinity: it would appear so...this is unsually slow
<infinity> utlemming: And you can't even blame the distro, lamont yanked ports off sawo just for you!
<lamont> "is yanking"
<infinity> Well, true.
<infinity> lamont: WHY SAWO SO SLOW
<lamont> waiting on a TTL expiry in china
<infinity> lamont: It appeard to be rsyncing utlemming's images at the speed of distracted toddler.
<lamont> not sure
<infinity> s/appeard/appears/
<utlemming> lamont: did jerff get its TOS rules adjusted recently?
<lamont> utlemming: I just pasted you a ps output that is likely relevant to your issue
<utlemming> lamont: yup, thanks
<bdmurray> slangasek: docker (SRU bug 1454719) was never added to the MicroReleaseExceptions page, it had 2 +1 so should be fine correct? Additionally, that SRU includes lots of build depends. Are those okay?
<ubot93> bug 1454719 in docker.io (Ubuntu Vivid) "docker.io update to 1.6.2" [Wishlist,Triaged] https://launchpad.net/bugs/1454719
<Odd_Bloke> infinity: ISTR some nonsense around libnettle; we have libnettle4 on our images but it's not (AFAICT) in the archive for wily.  Should that be the case, or did we build our image at an inopportune moment (where 4 and 6 were both around)?
<Odd_Bloke> infinity: (We do also have libnettle6 on there)
<utlemming> infinity: it looks good now
<infinity> Odd_Bloke: Try to remove it and see if anything goes with it?
<infinity> utlemming: Thanks, pushing the announcement.
<Odd_Bloke> infinity: libhogweed2, but we have libhogweed4.
<infinity> Odd_Bloke: Nothing else, though?
<Odd_Bloke> infinity: Nothing else.
<infinity> Odd_Bloke: If so, I have no idea how it ended up on your image unless you installed it explicitly.
<Odd_Bloke> Harumph.
<infinity> Odd_Bloke: Either way, it's gone now, so the next build can't pick it up, no matter how hard it tries.
<Odd_Bloke> Hmm, I can probably just ignore it then.
<infinity> Odd_Bloke: Oh, before it was removed, it might have been pulled in via a task, if you install with tasks.
<infinity> Odd_Bloke: But yeah, gone is gone, and it's been gone for a couple of hours, so whatever.  Life moves on.
<Odd_Bloke> Our testing picked up that it wasn't installable, so we'll catch it if it continues to be a problem. \o/
<Odd_Bloke> (Or if this happens with something else)
<Odd_Bloke> I think we do use tasks, but my memory of that part of our build process is currently swapped out to tape.
<infinity> Odd_Bloke: You kids today and your high speed storage.  Real men swap to paper.
* infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.2, Vivid 15.04, Wily Alpha 1 | Archive: wily open | Wily 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
<Odd_Bloke> s/paper/punchcards/
<infinity> Odd_Bloke: That was the implication, yes.
<Odd_Bloke> infinity: Did you have to Google for that Oscar Wilde quote, or do you just know them off the top of your head?
<infinity> Odd_Bloke: I'm a walking uncyclopedia.
<slangasek> bdmurray: docker was IIRC not a microrelease exception; but it should be documented somewhere, yes.  As for addition of build-deps, as long as those new build-deps are met in trusty...
#ubuntu-release 2015-06-26
<slangasek> bdmurray: sru-remove seems to want to unsubscribe sru-verification from the bugs, and I don't have access to do that.  Should the sru team be a member of sru-verification?
 * bdmurray looks
<bdmurray> I don't know what will happen with email in that case. sru-verification is subscribed to all SRU bugs but so is the SRU team...
<infinity> bdmurray: Pretty sure we'll only get one copy, if that's what you mean.
<bdmurray> infinity: yeah, that's what I was worried about.
<bdmurray> slangasek: so it seems like it'd be helpful for sru to be part of sru-verification.
<slangasek> bdmurray: ok. looks like you're an administrator, want to add sru to sru-verification? :)
<slangasek> alternatively, does it even make sense to have sru-verification subscribed anymore?  since they're by and large not the group doing the verifying
<bdmurray> slangasek: Oh, I guess the team was created before one could subscribe to tags in Launchpad. So there really isn't much need for the team anymore.
<bdmurray> People wanting to do verification could just subscribe to the v-needed tag.
#ubuntu-release 2016-06-27
<smb> Morning, I think someone needs to upload the signed grub2 updates to Trusty (proposed) still. Getting removal hints again
<flexiondotorg> infinity, Many thanks for working the weekend to fix iso.qa.
<mwhudson> thanks, whoever is dealing with my spam :-)
<not_roasted> hello friends.
<not_roasted> is there a documented "schedule" for SRUs or do they land somewhat dynamically? i.e. "when there's enough bug fixes worth committing to an SRU to release to go out to the wild"
<apw> mostly the latter, some packages have an announced schedule (such as the kernel)
<not_roasted> SRUs are different from that of point releases in the LTS cycle, yes?
<apw> point releases are a rollup of the current state including SRUs made into new images
<not_roasted> good deal
<not_roasted> we're getting hit with a bug that was just committed to the current "release" (I assume that means 16.10). It was mentioned it'll go there before the SRU for 16.04. Just curious so I can put it in my notes for the dept.
<not_roasted> thanks for the info :D
<apw> normally we would say development release or current stable release, so i am not sure which it means
<apw> if you have a bug number i could have a look see
<not_roasted> Sure. It's 1506744.
<not_roasted> post 55 at the very bottom mentions it.
<apw> not_roasted, ok that is talking about landing in yakkety right now, but that xenial SRUs (14.04 LTS) are coming
<not_roasted> you threw me off there... xenial... 14.04?
<not_roasted> (typo?)
<apw> 16.04 indeed
<not_roasted> ah, gotcha.
<apw> too many LTSs in my world :)
<not_roasted> ha, I believe it.
<not_roasted> thanks for the info, this helps. I'll put it in our notes and keep an eye out for the SRU.
<not_roasted> speaking of... is there a place I can "track" SRU releases? This particular bug is somewhat random to run into, so it may not be slam-dunk-obvious that it's been fixed unless I install a bunch of things without issue.
<not_roasted> track as in, get a notification, check a web site, etc to see it was released the day before or something?
<apw> not_roasted, you can ask for notifications for a specific bug, i don't think i know a way to know whatall else is changing other than looking at what gets updated directly when doing upgrades
<apw> not_roasted, though you can see hwats pending as they sit in <series>-proposed
<not_roasted> alright, sounds good. I'll do some digging then and check it out.
<not_roasted> thanks for the info apw. appreciate it!
<rbasak> infinity: with your Monday SRU team hat, please could you opine on bug 1569609? Or shall I ask nacc to provide a current upload, and the SRU team can consider it from the queue?
<ubot5> bug 1569609 in php7.0 (Ubuntu Xenial) "[SRU] microrelease exception for src:php7.0" [Wishlist,New] https://launchpad.net/bugs/1569609
#ubuntu-release 2016-06-28
<flexiondotorg> infinity, cyphermox Ubuntu MATE and Lubuntu are keen to have an 16.10 Alpha 1. Is that on the cards?
<LocutusOfBorg> hi, does anybody know how to make tidy-html5 migrate?
<LocutusOfBorg> does it need a MIR?
<LocutusOfBorg> second question: can anybody please demote mrpt to let opencv migrate? it has the same issues in Debian, and already 4 RC bugs that are preventing archs from building
<cjwatson> apw: ^- mind looking at live-build?
<apw> cjwatson, np
<cjwatson> apw: thanks
<infinity> flexiondotorg: I'll be on an airplane when A1 would be releasing, so it won't be me doing it.
<flexiondotorg> infinity, OK.
<infinity> stgraber: Did you want to take A1 as your usual "make sure the world isn't broken" thing?
<stgraber> infinity: that's this week right?
<stgraber> if so, I can take it, yeah
<stgraber> I'm travelling for the next month or so, but still home until Friday :)
<infinity> stgraber: It is this week, yes.
<infinity> stgraber: Soft freeze would be nowish. :P
<infinity> Well, in 1.25 hours.
<flexiondotorg> stgraber, I've recently uploaded a new ubuntu-mate-artwork package.
<infinity> stgraber: And thanks.
<flexiondotorg> So if you want to delay for a few hours, fine by me ;-)
 * infinity grabs his shotgun and goes coffee hunting.
<apw> infinity, what do you use, bean-bag rounds ?
<infinity> apw: Bird shot.  You wound the coffeebeast, and then bleed it into a mug.
<infinity> Nothing but the freshest coffee.
<apw> oh they normally use a bow and arrow for that kind of bleeding ...
<stgraber> infinity: ok, let me catch up on who's actually participating
 * stgraber sets up the tracker
<stgraber> so lubuntu, mate and kylin
<stgraber> Odd_Bloke, rcj: are you guys participating in alpha-1?
<gaughen> stgraber, we are not planning to participate
<stgraber> tracker setup done, turning off cron for the 3 affected flavors
<stgraber> gaughen: ok
<rcj> beat me to it
<stgraber> cron updated
<stgraber> will set the block in an hour
<stgraber> other than that, I'll do the publishing on Thursday, let me know if anyone needs anything else
<tsimonq2> thanks stgraber
<tsimonq2> flexiondotorg: ^
<flexiondotorg> tsimonq2, Thanks.
<flexiondotorg> stgraber, Thanks.
<flexiondotorg> stgraber, Ubuntu MATE would like to release the powerpc build too please.
<stgraber> flexiondotorg: looks like it's on the manifest so should be all good
<flexiondotorg> Thanks.
<flexiondotorg> stgraber, Looks like I'll need to upload one package later. Shall I just ping you to request an unblock?
<stgraber> flexiondotorg: yeah, or I can wait a bit to setup the block if you prefer
<flexiondotorg> Well, I'm going to need several hours. Maybe 6. So I don't want to hold others up.
<stgraber> applying the block now
<tjaalton> infinity: is 14.04.5 lts stack a thing on ppc64el?
<stgraber> freeze in place
<tjaalton> hm? i'm backporting xorg from xenial
<nacc> tjaalton: probalby not directed at you
<stgraber> tjaalton: wasn't talking to you :)
<tjaalton> ahh, gotcha :)
<nacc> stgraber: should /topic be adjusted then?
<stgraber> nacc: I don't think we really bother for alphas, because the archive isn't really frozen as it would later in the cycle and the list of packages that are affected won't fit in the topic :)
<nacc> stgraber: ah good point
<roadmr> hey folks! what's needed for https://launchpad.net/bugs/1590434 to be solved? we'd love to have that package landed to allow snapd to authenticate using macaroons
<ubot5> Launchpad bug 1590434 in golang-gopkg-macaroon.v1 (Ubuntu Xenial) "[SRU] Initial version as a snapd build-dep" [Undecided,New]
<infinity> tjaalton: We built previous stacks on all arches.
<infinity> tjaalton: Is there a reason we wouldn't do so with xenial?
<tjaalton> infinity: ok, well right now xserver ftbfs on ppc64el, haven't looked into it yet
<tjaalton> xenial xserver
<tjaalton> on trusty
 * infinity nods.
<infinity> It's probably something trivial, but good to know.
<infinity> Have a build log?
<tjaalton> yep
<tjaalton> https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging/+build/10183393/+files/buildlog_ubuntu-trusty-ppc64el.xorg-server-lts-xenial_2%3A1.18.3-1ubuntu2.2~trusty0.2_BUILDING.txt.gz
<tjaalton> ../../../../hw/kdrive/src/kinput.c:224:43: error: array subscript is above array bounds [-Werror=array-bounds]
<infinity> tjaalton: Curious.  Dropping to -O2 might fix it, but odd that gcc 4.8 seems to dislike you and 5.3 is fine in this regard.  (Well, not that odd, if you look at the number of bugs filed and fixed upstream WRT that particular warning)
<infinity> tjaalton: Did you ever get anywhere with the llvm-on-arm64 issue, or just opt for reverting to an older llvm?
<tjaalton> infinity: that proved to be a non-issue, as mesa doesn't b-dep llvm on arm64
<tjaalton> which probably is a bug of it's own
<infinity> tjaalton: Ahh, so letting it just be FTBFS is fine in that case, if a bit gross.  Kay.
<tjaalton> right
<tjaalton> had to revert a commit to let maxclients be configurable on xserver so that it doesn't depend on a newer coreproto, which breaks all earlier servers..
<tjaalton> but that's another non-issue I think, and safer this way
 * infinity nods.
<infinity> Sounds reasonable.
<infinity> So, assuming my -O2 stab in the dark fixes xorg on ppc64el, are we close to flooding the SRU queue with uploads?
<tjaalton> there's also the sru for libdrm which is kinda stuck on trusty. xenial got it already but I haven't tested it on trusty (a full backport with newer version plus a few added pci-id's that sru'd to xenial)
<tjaalton> and of course llvm
<tjaalton> and libxrandr & randrproto
<infinity> tjaalton: That's in proposed already, though, so shouldn't block other things uploading, I hope.
<infinity> (libdrm, that is)
<tjaalton> indeed
<tjaalton> was thinking ahead
<tjaalton> anyway, I could upload the randr stuff
<infinity> tjaalton: So, I'm off to DebConf on Thursday, I'd love to see the mess hit the queue before then, so I can get the ball rolling on dailies ASAP.
<tjaalton> where to put that -O2 so I can test on the ppa?
<infinity> tjaalton: Lemme grab the xorg-xenial source and fiddle with that briefly.
<tjaalton> once the xserver builds then all the drivers are go
<tjaalton> ok
<tjaalton> i reverted some systemd changes too, but it might not be enough
<tjaalton> at least it builds
<sergiusens> RAOF hey, can you let snapcraft (2.12) go, release its chains and let it escape into xenial-updates ?
<infinity> tjaalton: Can you try uploading something like this: http://paste.ubuntu.com/18050427/
<tjaalton> infinity: sure, uploaded
<infinity> tjaalton: Looks like that worked.
<tjaalton> oh goodie
<infinity> tjaalton: Normally, I'd go hunting for why the code sucks, but if gcc 5.3 considers it legal, I'm down with "meh, whatever, simple backport hack" instead.
<tjaalton> wfm
<infinity> tjaalton: So, was that the last thing blocking moving this show to the queue?
<infinity> tjaalton: If so, I look forward to uploads and some build order instructions tomorrow. :)
<tjaalton> infinity: yeah
<tjaalton> well, I could push something right now
<tjaalton> since you're up
<infinity> tjaalton: Sure, sooner beats later.
<infinity> tjaalton: I just assumed you might want to sleep or, I dunno, not be at work.  But your time, your call.
<tjaalton> i've sat on this for long enough :)
<tjaalton> and I'll take some time off later
<infinity> tjaalton: Sometime between now and 16.04.2, we should probably have a head-to-head and see if we can figure out how to make the HWE-X packaging less convoluted, given the decision to go to a rolling HWE stack.
<infinity> tjaalton: Might be a good opportunity to rethink some basic assumptions.
<infinity> tjaalton: But, another week/month.  Not today. :P
<tjaalton> right
<tjaalton> randrproto is first
 * infinity goes to find that lunch he keeps putting off.
<infinity> tjaalton: I'll be back in ~1hr to look at what's landed in my lap.
<tjaalton> I'll upload libxrandr too
<tjaalton> and then hit the sack
<infinity> tjaalton: Feel free to upload a bunch of stuff (and/or all of it), I don't think anyone other than I will be touching it tonight.
<tjaalton> indeed
<tjaalton> infinity: ok that's everything for now. build order; llvm -> mesa -> x11proto-randr -> libxrandr -> xserver
<tjaalton> i'll build the drivers tomorrow in the ppa for sanity checking
<infinity> tjaalton: Ta.
<tjaalton> and then test the upgrade
<RAOF> sergiusens: It's only been in xenial-proposed for a day; normally we'd wait 7 before promoting to -updates. Is there anything particularly urgent here?
#ubuntu-release 2016-06-29
<xnox> RAOF, https://wiki.ubuntu.com/StableReleaseUpdates#Snapcraft & https://wiki.ubuntu.com/SnapcraftUpdates
<xnox> at the moment snapcraft turn-around time is about 2 days.
<RAOF> xnox: Doesn't actually mention a lower xenial-proposed baking time (I'd read that as just âyes, you can SRU thisâ), but sure. :)
* infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.4, Xenial 16.04 | Archive: open | Yakkety 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
* infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.4, Xenial 16.04 | Archive: open | Yakkety 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
<flexiondotorg> stgraber, balloons There are very few test cases shown for the 16.10 Alpha 1 - http://iso.qa.ubuntu.com/qatracker/milestones/362/builds
<tsimonq2> yes, we need more to be able to properly test
<tsimonq2> nice catch flexiondotorg
<infinity> tjaalton: FYI: https://launchpad.net/ubuntu/+source/llvm-toolchain-3.8/1:3.8-2ubuntu3~trusty2
<tjaalton> infinity: ah, cool
<flexiondotorg> infinity, any chance you can add the test cases to the Alpha 1 iso tracker please?
<tjaalton> infinity: found a bug in xenial xserver, the dev package would pull newer coreproto which doesn't exist so relaxed that dep and will now test builds on the ppa.. but you can drop xserver from the queue
<flexiondotorg> Laney, cjwatson Can you recommend someone to sort the QA tracker for alpha 1 please?
<flexiondotorg> http://iso.qa.ubuntu.com/qatracker/milestones/362/builds
<flexiondotorg> No test cases and no way to mark isos ready.
<Odd_Bloke> flexiondotorg: stgraber is involved there, I believe.
<Laney> I can copy the latest builds there
<Laney> is http://iso.qa.ubuntu.com/qatracker/series/58/manifest right?
<flexiondotorg> Laney, yes, that looks correct to me.
<flexiondotorg> Thanks
<LocutusOfBorg> can anybody please demote mrpt to let opencv migrate when ready?
<LocutusOfBorg> it is FTBFS in debian too
<Laney> flexiondotorg: eet eez done
<flexiondotorg> Thanks.
<tsimonq2> \o/ thanks
<sergiusens> arges hey, good morning, I want to ask if you can open the floodgate for snapcraft 2.12 on xenial
<arges> sergiusens: i'll takea look
<sergiusens> arges thank you very much!
<LocutusOfBorg> when will the freeze block be removed?
<apw> LocutusOfBorg, normally things are aiming for thrusday releases ...
<LocutusOfBorg> ok tomorrow then
<LocutusOfBorg> I saw some building of alpha images
<LocutusOfBorg> thanks
<doko> LocutusOfBorg, you just touch virtualbox, how did you fix https://launchpad.net/ubuntu/+archive/test-rebuild-20160614/+build/10010135 ?
<LocutusOfBorg> doko, the usual fix, let me grab it
<LocutusOfBorg> http://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/tree/configure#n437
<LocutusOfBorg> patching here is fine
<doko> ta
<LocutusOfBorg> oh, the current configure should be fine for every gcc 5 and 6.1 :)
<LocutusOfBorg> yw
<LocutusOfBorg> the one in git I mean
<doko> hmm, this is strange ...
<LocutusOfBorg> e.g. http://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/debian/patches?id=260abfbcbf34a376eacbee2a21b8bb2a1f896260
<LocutusOfBorg> this patch should be fine
<LocutusOfBorg> doko, why do you have this issue?
<LocutusOfBorg> you want gcc-5.4 in xenial?
<LocutusOfBorg> I propose to SRU virtualbox then
<doko> LocutusOfBorg, can you prepare a SRU, and do a test build using the ubuntu-toolchain-r/ppa PPA?
<flexiondotorg> stgraber, Please can you unblock ubuntu-mate-welcome/16.10.5.1
<flexiondotorg> Currently sitting in proposed.
<LocutusOfBorg> doko, ok
<LocutusOfBorg> I will
<LocutusOfBorg> 5.0.24 is not syncd yet
<stgraber> flexiondotorg: done
<flexiondotorg> stgraber, ty
<stgraber> looking at fixing the testsuites but looks like a few flavors went and fixed it themselves, breaking the script
<stgraber> ok, removed all testsuites for yakkety and then copied xenial to yakkety again, that should do the trick
<doko> tjaalton, infinity: I set https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/1577734 to failed. wondering why this is not renamed. told you about it before ...
<ubot5> Launchpad bug 1577734 in x11proto-randr (Ubuntu Trusty) "Backport packages for 14.04.5 lts-xenial stack" [Undecided,New]
<infinity> tjaalton: Looks like I can't accept/build mesa until you've addressed doko's libllvm concerns.
<infinity> tjaalton: Since mesa ends up depending on it.
<tjaalton> doko: ok, that must've been ages ago..
<tjaalton> infinity: i'll fix it in a bit
<doko> tjaalton, and remove the Breaks: libllvm3.8v4 ...
<tjaalton> doko: so just rename the one binary?
<doko> tjaalton, yes
<doko> tjaalton, you have to do that for every backport of a new c++ lib version which had a library transition
<tjaalton> there shouldn't be others?
<doko> I don't know what else you backport ;p
<tjaalton> nothing in c++
<tjaalton> that bug should have the unrenamed bits, though libevdev might be added to the list
<tjaalton> silly autofolder thinks Reporter >> Assignee
<tjaalton> I didn't see the emails
<doko> done for today, afk now
<tjaalton> infinity: btw you can build the randr stuff now, proto first
<tjaalton> llvm uploaded
<infinity> Ta.
<tjaalton> afk ->
<flexiondotorg> infinity, Weird things are happening for the rebuild request for Ubuntu MATE isos.
<flexiondotorg> I kicked off a rebuild earlier.
<flexiondotorg> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-mate/yakkety/daily-live-20160629.log
<flexiondotorg> livefs has built but not new isos have appeared.
<flexiondotorg> Can you shed any light on this?
<flexiondotorg> infinity, Hmmm. amd64 is taking its time - https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/ubuntu-mate/+build/66978
<flexiondotorg> Normal?
<flexiondotorg> 2.5 hours so far creating the sqaushfs.
<slangasek> flexiondotorg: where do you get the 2.5 hours? that page says "started 1 hour ago"
<slangasek> oh, I guess you're looking at the timestamp, but the timestamp is UTC; so that's 1h27m ago
<slangasek> which is definitely long
<slangasek> flexiondotorg: I think we want to kill it and kick a new one
<flexiondotorg> [2016-06-29 17:07:42] lb_binary_rootfs
<flexiondotorg> P: Begin building root filesystem image...
<flexiondotorg> P: Preparing squashfs image...
<flexiondotorg> P: This may take a while.
<flexiondotorg> 17:07:42 ~= 2.5 hours ago.
<flexiondotorg> Just saw your backlog.
<flexiondotorg> OK.
<flexiondotorg> Shall I request a stop and rebuild request?
<wxl> 18-17 = 1 not 2? XD
<flexiondotorg> wxl, I was looking at local time 19:37
<wxl> flexiondotorg: silly bear. don't you know that utc is the only time? XD
<stgraber> canceled the build
<flexiondotorg> I do know UTC, I used to make avionic parts.
<stgraber> waiting for nusakan to notice then we can re-trigger
<flexiondotorg> stgraber, Thank you.
<stgraber> flexiondotorg: you should be able to trigger a new build
<flexiondotorg> stgraber, Thanks. Will do.
<mterry> I see gucharmap has a -proposed migration block?  "due to block request by freeze"
<apw> mterry, we are in alpha1 freeze
<mterry> apw, ah!  I hadn't looked at the yakkety calendar, didn't realize it was upon us already   :)
<apw> should lift tommorrow all things being equal
<slangasek> and why is this causing packages to be frozen?
<apw> it is a seeded packages block we are taliking about
<slangasek> stgraber: what generate-freeze-block command did you use to generate the current hint?  (could we please make it a habit of including the full command in the hint comment, for transparency?)
<stgraber>   109  ./generate-freeze-block ubuntukylin lubuntu ubuntu-mate >> ../hints-ubuntu//freeze
<stgraber> slangasek: ^
<slangasek> thx
<flexiondotorg> stgraber, slangasek Thanks for the help earlier. I've got new Ubuntu MATE images and been able to complete the testing :-)
<slangasek> flexiondotorg: spiff :)
<nacc> so the freeze also affects SRUs to xenial?
<slangasek> nacc: no
<nacc> slangasek: hrm, http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html "Not touching package due to block request by freeze (contact #ubuntu-release if update is needed)"
<nacc> that's for the php7.0 SRU
<nacc> slangasek: ah, and in that case, as well, does the SRU team need to manually approve the "new" binaries so they actually show up in -proposed?
<nacc> slangasek: or am i misreading the excuses output?
<cyphermox> slangasek: could you please unblock shim-signed? we should move forward on the shim-signed SRUs
<slangasek> nacc: stable releases are always frozen, and we don't use proposed-migration currently to propagate packages to -updates, so that output is true but irrelevant :)
<nacc> slangasek: oh ok :)
<mwhudson> slangasek: oh yeah, i was looking at that
<mwhudson> slangasek: it looks as if you _could_ use a hint to propagate a package to -updates
<mwhudson> but i don't know enough about how things are deployed to be sure
<cjwatson> mwhudson: We've long wanted to get there, but right now nothing will react to that hint and do the right copy.
<mwhudson> fair enough
<nacc> slangasek: sorry, was just a complete thinko on my part; but was i correct in that 'new' binary packages won't show up automatically (in the SRU process)? i'm specifically trying to test the php7.0 sru which brought in a new upstream version
<nacc> ah maybe it's just waiting to be copied still. /me will check in the AM
#ubuntu-release 2016-06-30
<slangasek> nacc: the 'new' queue for stable releases doesn't always get attention
<slangasek> nacc: binaries accepted now
<nacc> slangasek: ah ok, thanks!
<slangasek> cyphermox: unblocked (and fwiw, not a prereq for SRU)
<slangasek> mwhudson: yeah, what cjwatson says :)
<mwhudson> slangasek: hm, wait, won't it end up calling migrate-proposed?
<mwhudson> er promote-to-release rather, which i guess doesn't do the right thing
<slangasek> how do you mean?
<cyphermox> slangasek: not a prereq, but it ought to be in yakkety anyway.
<cyphermox> now, I go back to fighting inkscape to make pretty labels, sorry ;)
<mwhudson> slangasek: this is based on a weeks old memory of reading britney1-ubuntu, i'm probably talking nonsense
<slangasek> if option save_b1; then
<slangasek>   save b1
<slangasek> fi
<slangasek> if option save || option save_b2; then
<slangasek>   save b2
<slangasek> fi
<slangasek> mwhudson: ^^
<slangasek> mwhudson: and run-proposed-migration in lp:~ubuntu-archive/+junk/scripts
<slangasek> and currently promote-to-release would DTWT for non-devel series, and the HeidiResults file would also do things we don't particularly want
<slangasek> mwhudson: viz: http://people.canonical.com/~ubuntu-archive/pm-for-srus-scratch/xenial-HeidiResultDelta
<mwhudson> slangasek: that does look unfortunate
<slangasek> but tractable :)
<stgraber> For those flavors participating in alpha-1. I should be around a bit after 14:00 UTC tomorrow. Just a reminder that I only take care of publishing and dealing with images/tracker issues. Someone from the participating flavors should be writing the release announcement and send it once everything is ready.
<infinity> tjaalton: Yet another llvm upload: https://launchpad.net/ubuntu/+source/llvm-toolchain-3.8/1:3.8-2ubuntu3~trusty4
<infinity> tjaalton: That one seems to DTRT locally.
<tjaalton> infinity: bah, thx
<tumbleweed> 9/win 32
<LocutusOfBorg> please reject gambas3 from new
<LocutusOfBorg> thanks
<LocutusOfBorg> "please reject gambas3 from new" <-- not sure if you got it
 * LocutusOfBorg has a bad connection
<LocutusOfBorg> I stopped gambas3 builds, and I have the fixed package ready to upload
<apw> LocutusOfBorg, rejected
<LocutusOfBorg> <3
<LocutusOfBorg> I'm not sure why they have been removed from Ubuntu, but I don't want them back
<LocutusOfBorg> and I'll try to remove in Debian too
<LocutusOfBorg> leaving, thanks
<flexiondotorg> tsimonq2, I can try and draft a release announcement in the wiki.
<tsimonq2> flexiondotorg: that would be awesome. I guess I was ust asking who would send it?
<tsimonq2> *just
<flexiondotorg> It depends when the release happens.
<tsimonq2> flexiondotorg: wxl will be around after 10 AM Pacific Time, so 7 hours give or take
<tsimonq2> ruh roh, can someone confirm or deny bug 1596281? it's causing ISO test failures...
<ubot5> bug 1596281 in linux (Ubuntu) "the target drive is not found when connected via USB 3 while installing Lubuntu alternate" [Medium,Incomplete] https://launchpad.net/bugs/1596281
<tjaalton> infinity: things should be ready on my end, but getting weird dep errors trying to install lts-xenial on a chroot with trusty stack.. http://pastebin.com/P4T66YGq
<tjaalton> infinity: install works fine if I first install xserver core, then the rest
 * flexiondotorg is drafting Yakkety Yak Alpha 1 release announcement...
<tjaalton> infinity: if I leave xserver-xorg-lts-xenial out from the upgrade command, things go smoothly, and x-x-l-x can be installed later
<tjaalton> fwict the package looks the same as -wily
<flexiondotorg> tsimonq2, This page https://wiki.ubuntu.com/YakketyYak/
<flexiondotorg> Needs to look like this one - https://wiki.ubuntu.com/XenialXerus
<flexiondotorg> And I don't have the super powers.
<tsimonq2> oh okay flexiondotorg
<flexiondotorg> tsimonq2, I've just learned I need to be in the ~ubuntu-wiki-editors LP group.
<tsimonq2> flexiondotorg: well I'm an Ubuntu member so I'm in that already
<tsimonq2> but yes :)
<flexiondotorg> Yes, and I am reminded that I need to sort our Ubuntu Membership.
<flexiondotorg> tseliot, I've drafted the release announcement.
<tsimonq2> flexiondotorg: YakketyYak/Alpha1 has been created
<tsimonq2> flexiondotorg: what else do I need to create?
<tsimonq2> https://wiki.ubuntu.com/YakketyYak/
<flexiondotorg> tsimonq2, Thanks. I've jusy been made an ubunut-wiki-editor member. So hopefully I can update the pages.
<tsimonq2> great :)
<tsimonq2> flexiondotorg: I PMed you the link to the Google Document
<tsimonq2> flexiondotorg: if you wish, you can put MATE announcements on that document as well
<flexiondotorg> tsimonq2, Saw you comment on the Google Doc.
<flexiondotorg> Yes, I can email the release announcement.
<tsimonq2> alright :)
<tsimonq2> flexiondotorg: I left a suggestion as well
<flexiondotorg> Yep, done :-)
<Trevinho> Laney: it seems that autopkg tests now pass for unity8... Anything needed to unblock?
<Laney> Trevinho: Same link says it: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity
<Laney> Alpha 1 freeze
<Trevinho> ah... already... ok :)
<doko> stgraber, when do you expect the alpha1 release?
<flexiondotorg> Just waiting on Lubuntu to hit the Ready button...
<flexiondotorg> Ubuntu MATE and Kylin are all set.
<tsimonq2> flexiondotorg: I wish I could help you...
<flexiondotorg> I've drafted the release announcement email and sorted the wiki out with tsimonq2 :-)
<tsimonq2> Walter will be here soon to press the Lubuntu button, I've prepared everything else
<tsimonq2> doko, stgraber ^
 * stgraber waves
<tsimonq2> hello stgraber :)
<Laney> flexiondotorg: It's okay to unfreeze, right?
<tsimonq2> Laney: not yet
<tsimonq2> Laney: we haven't released yet
<Laney> so?
<Laney> you're not going to respin any images
<tsimonq2> flexiondotorg? stgraber? thoughts?
<flexiondotorg> Ubuntu MATE aren't. I doubt Kylin will.
<flexiondotorg> tsimonq2, I assume you've got no RC iso issues for an Alpha?
<tsimonq2> and Lubuntu not either
<flexiondotorg> There we are then :-)
<Laney> DONE
<wxl> stgraber: it looks like we're all ready to go on alpha 1. just need to coordinate with flexiondotorg to push out the announcement
<stgraber> cool, doing the publishing now then
<wxl> stgraber: thank you kindly :)
<stgraber> can someone please approve the lxd SRU above? ^ it's a tiny cherry-pick on top of the SRU I pushed yesterday to fix an issue smoser noticed
<stgraber> wxl: publishing is done except for the source images which are still building, but I wouldn't hold the announcement on those
<wxl> stgraber: ok, we'll get it going then. thanks for your help!
<wxl> flexiondotorg: go announce!
<flexiondotorg> wxl, Acknowledged :-)
<slangasek> stgraber: lxd accepted
<flexiondotorg> stgraber, wxl I won't announce yet. cdimage is empty - http://cdimage.ubuntu.com/ubuntu-mate/releases/16.10/alpha-1/
<stgraber> ah, could still be syncing
<stgraber> it's published on the source server and the mirrors were triggered but it may take a little while for them to get all the files
<flexiondotorg> I wait patiently :-)
<flexiondotorg> stgraber, Lubuntu was live on cdimage nearly 40 mins ago.
<stgraber> yeah, mate was the last one to get published
<tsimonq2> stgraber: what about Kylin?
<tsimonq2> hmm
<stgraber> kylin was first, so I'd expect it to be there, unless they all synced at the same time, in which case, they'll show up once rsync is done :)
<stgraber> yeah, rsync is still running for each of the frontend, I'll keep a look and tell you when it looks like they're done
<tsimonq2> alright stgraber, thanks :)
<flexiondotorg> thanks
<flexiondotorg> stgraber, tsimonq2 OK I see everything in place for Kylin and Ubuntu MATE.
<flexiondotorg> I'll send the email.
<tsimonq2> \o/
<stgraber> not all frontends are done syncing
<tsimonq2> stgraber: what are we waiting on?
<stgraber> tsimonq2: not all of the machines serving cdimage.ubuntu.com are done syncing, so some folks may not see the images yet
<tsimonq2> stgraber: alright thanks :)
 * flexiondotorg waits...
<flexiondotorg> The ubuntu-mate.org site publish caught that, and refused to go live :-)
<stgraber> still seeing 5 servers syncing data
<tsimonq2> stgraber: is there an ETA or a place we can see the progress or will you tell us when it's done?
<stgraber> I'll keep checking regularly, I've no idea what frontends those are or how far they are with syncing
<tsimonq2> alright thanks stgraber
<flexiondotorg> My email client is loaded and ready to fire.
 * flexiondotorg has a twitcher finger... ;-)
<stgraber> sync looks good
<flexiondotorg> Yay!
<flexiondotorg> Release email sent. Might need moderating because I am a pleb. Or was until a few hours ago.
<flexiondotorg> stgraber, Thanks for your help.
<stgraber> np
<flexiondotorg> tsimonq2, wxl Thanks for getting stuck in.
<flexiondotorg> Especially tsimonq2 who I think has been awake for 72 hours now ;-)
<stgraber> milestone marked as released and cron re-enabled
<wxl> thx so much stgraber
<wxl> and you too flexiondotorg
<wxl> and tsimonq2 too XD
<tsimonq2> XD wxl
<cyphermox> slangasek: ^ live-installer.
<slangasek> cyphermox: ta
<tsimonq2> flexiondotorg, wxl: http://fridge.ubuntu.com/2016/06/30/yakkety-yak-alpha-1-released/
<wolsen> bdmurray:
<wolsen> doh
<wolsen> bdmurray: looks like you are the vanguard for thursdays? any chance I can get bug 1374999 published to trusty-updates?
<ubot5> bug 1374999 in Ubuntu Cloud Archive "iSCSI volume detach does not correctly remove the multipath device descriptors" [Undecided,Confirmed] https://launchpad.net/bugs/1374999
<slangasek> wolsen: bdmurray is off today; let me look
<wolsen> ah thanks slangasek !
<slangasek> wolsen: according to http://people.canonical.com/~ubuntu-archive/pending-sru.html there are three other bugs in that nova SRU that have not yet been verified; they all need to be verified prior to publication
<wolsen> slangasek: ah gotcha, okay - I'll get on it, thanks!
<tsimonq2> oh yeah I forgot, < flexiondotorg> Especially tsimonq2 who I think has been awake for 72 hours now ;-) , no, but I've been up since 3 AM my time and it's 4 PM ;)
<nacc> re the test regression for xenial php7.0 on armhf, i'm not entirely seeing what is failing (and it's not failing on any other architectures). Is it possible to rerun it to see if it's a testbed issue? http://autopkgtest.ubuntu.com/packages/p/php7.0/xenial/armhf/
<slangasek> nacc: retriggered
#ubuntu-release 2016-07-01
<nacc> slangasek: thanks! i also just looked back at the logs for php7.0 and it seems it has failed this same way in the past a few times on the older version of php7.0 on armhf, so i'm not sure it's related to php7.0 itself (but not sure what it is related to either).
<nacc> slangasek: well, and it looks like it passed this time, thanks again!
<slangasek> nacc: right, seems to me the tests need verbosity++
<slangasek> something exited non-zero, but had nothing to say for itself
<nacc> slangasek: yeah, i think that's on my old todo list :)
<nacc> slangasek: if you have the time, can you also retrigger phpseclib -> php-horde-mapi tests for all archs? new php-horde-mapi has been SRU'd which should fix those regressions.
<slangasek> nacc: triggered; php-horde-mapi itself seems to also have some failing revdeps of its own (php-horde-activesync), have you looked at this one?
<LocutusOfBorg> doko, virtualbox in unapproved queue shortly
<LocutusOfBorg> ^^
<yofel> could someone please force-badtest plasma-framework on s390x? thanks
<apw> yofel, is there some background to that?
<yofel> apw: I need that in release so I can verify a fix for a xenial SRU I want to do (affecting the live images), and I really don't care about the tests currently
<apw> yofel, ok done
<yofel> apw: thanks!
<LocutusOfBorg> yeah ^^^ some more breakage for virtualbox
<nacc> slangasek: going to do that today, i think it's mysql related
<slangasek> yes, it does look it
<nacc> slangasek: yep, it's the same issue as a few others, fixing now
#ubuntu-release 2016-07-02
<Kamilion> uhhh, keyserver.ubuntu.com is 503ing for me...
<Kamilion> "No server is available to handle this request."
#ubuntu-release 2016-07-03
<infinity> slangasek: ubuntu-dev-tools verified on all releases during the DebConf keynote.  Do as you please with it.
<infinity> tjaalton: I can haz more lts-xenial uploads?
<tjaalton> infinity: yeah, I'll push the drivers
<infinity> tjaalton: Didn't you still need to reupload the xserver?
<infinity> tjaalton: Pretty sure you asked me to reject it and you never uploaded a new one.
<tjaalton> hmm, maybe
<tjaalton> done
<infinity> tjaalton: Looking.
<infinity> tjaalton: Does that revert mean that you should close the x11proto-core task on LP: #1577734 ?
<ubot5> Launchpad bug 1577734 in x11proto-core (Ubuntu Trusty) "Backport packages for 14.04.5 lts-xenial stack" [Undecided,New] https://launchpad.net/bugs/1577734
<tjaalton> it does
#ubuntu-release 2017-06-26
-queuebot:#ubuntu-release- New binary: haskell-http-link-header [amd64] (artful-proposed/universe) [1.0.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-http-link-header [ppc64el] (artful-proposed/universe) [1.0.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-http-link-header [i386] (artful-proposed/universe) [1.0.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-http-link-header [arm64] (artful-proposed/universe) [1.0.3-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-http-link-header [arm64] (artful-proposed) [1.0.3-2]
-queuebot:#ubuntu-release- New: accepted haskell-http-link-header [ppc64el] (artful-proposed) [1.0.3-2]
-queuebot:#ubuntu-release- New: accepted haskell-http-link-header [i386] (artful-proposed) [1.0.3-2]
-queuebot:#ubuntu-release- New: accepted haskell-cabal-install [s390x] (artful-proposed) [1.24.0.2-2]
-queuebot:#ubuntu-release- New: accepted haskell-http-link-header [amd64] (artful-proposed) [1.0.3-2]
<slangasek> jbicha: are you tracking the mapnik that you synced from experimental?  It has missing symbols relative to the previous version and regresses node-mapnik
<slangasek> (and probably more; but node-mapnik has the autopkgtest that notices)
-queuebot:#ubuntu-release- New binary: haskell-github [amd64] (artful-proposed/universe) [0.15.0-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-github [ppc64el] (artful-proposed/universe) [0.15.0-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-github [i386] (artful-proposed/universe) [0.15.0-1build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-github [amd64] (artful-proposed) [0.15.0-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-github [ppc64el] (artful-proposed) [0.15.0-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-github [i386] (artful-proposed) [0.15.0-1build1]
<Laney> slangasek: I do it frequently
<Laney> But not at the weekend ......
<Laney> slangasek: Are you interested in helping out, or something? You seem to be keeping an eye on this.
<LocutusOfBorg> hello, did anybody stop haskell autosync? btw slangasek great success :)
-queuebot:#ubuntu-release- New binary: paste [amd64] (artful-proposed/main) [2.0.3+dfsg-4ubuntu1] (ubuntu-desktop, ubuntu-server)
<LocutusOfBorg> btw why is ninja failing in that strange way? I would blame debhelper or similar...
<LocutusOfBorg> src:ninja-build, seems that debhelper is missing some target
<cjwatson> I see no evidence that haskell autosyncing is stopped
<LocutusOfBorg> I had to manually sinc ghc some minutes ago
<Laney> LocutusOfBorg: what happens if you rebuild in unstable now?
<Laney> 10.5 is there
<LocutusOfBorg> Laney, I finished 10 secoonds ago
<LocutusOfBorg> damn, same issue
<LocutusOfBorg> adding an empty override_dh_auto_install works, meh
<LocutusOfBorg> I'm opening an RC bug in debian
<LocutusOfBorg> or maybe I'll open it if you ask me, because it might be a debhelper bug
<Laney> seems likely that it is
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-82.105~14.04.1] (kernel)
<LocutusOfBorg> I'll ask in debian devel irc
<cjwatson> LocutusOfBorg: ghc> you're just impatient
<cjwatson> LocutusOfBorg: by about an hour or so
<LocutusOfBorg> ok, it was uploaded yesterday... anyway, even better
<cjwatson> LocutusOfBorg: didn't get imported into LP last night because of losing a race by a couple of minutes, which delayed it by six hours
<LocutusOfBorg> oh ok
-queuebot:#ubuntu-release- Unapproved: at-spi2-atk (xenial-proposed/main) [2.18.1-2ubuntu1 => 2.24.1-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected at-spi2-atk [source] (xenial-proposed) [2.24.1-0ubuntu1]
 * cjwatson finally gets round to proposing a crontab merge to fix said race.  Only been meaning to do that for about six year
<cjwatson> s
<LocutusOfBorg> cjwatson, <3
<LocutusOfBorg> lovely cron
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-82.105~14.04.1]
<jbicha> slangasek: yes I believe we just need a newer node-mapnik version, we can do that ourselves or wait a bit longer for Debian
-queuebot:#ubuntu-release- Unapproved: libinput (xenial-proposed/main) [1.2.3-1ubuntu1 => 1.6.3-1ubuntu1~16.04.1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: xorg-server (xenial-proposed/main) [2:1.18.4-0ubuntu0.2 => 2:1.18.4-0ubuntu0.3] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: xfonts-utils (xenial-proposed/main) [1:7.7+3ubuntu0.16.04.1 => 1:7.7+3ubuntu0.16.04.2] (core)
-queuebot:#ubuntu-release- Unapproved: mesa (xenial-proposed/main) [12.0.6-0ubuntu0.16.04.1 => 17.0.7-0ubuntu0.16.04.1] (core, xorg)
-queuebot:#ubuntu-release- New: accepted paste [amd64] (artful-proposed) [2.0.3+dfsg-4ubuntu1]
-queuebot:#ubuntu-release- New binary: rustc [amd64] (artful-proposed/universe) [1.17.0+dfsg2-7] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [s390x] (artful-proposed/universe) [1.17.0+dfsg2-7] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [i386] (artful-proposed/universe) [1.17.0+dfsg2-7] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (xenial-proposed) [0.1.0~bzr505-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: intel-microcode (xenial-proposed/restricted) [3.20151106.1 => 3.20170511.1~ubuntu16.04.0] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: intel-microcode (yakkety-proposed/restricted) [3.20160714.1 => 3.20170511.1~ubuntu16.10.0] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: intel-microcode (zesty-proposed/restricted) [3.20161104.1 => 3.20170511.1~ubuntu17.04.0] (ubuntu-desktop, ubuntu-server)
<rbasak> infinity: xnox: ^ who's reviewing these? Want me to do it? I don't see sil2100 here.
-queuebot:#ubuntu-release- New binary: rustc [arm64] (artful-proposed/universe) [1.17.0+dfsg2-7] (no packageset)
<xnox> rbasak, i review no, i applaud only =)
<rbasak> xnox: huh?
<xnox> rbasak, i'm just the uploader, and i have not pinged anybody to review it yet.
 * xnox translates ranglish to english
<rbasak> Ah
<rbasak> OK. Well then I'll take it.
<rbasak> xnox: not doing Trusty?
<xnox> rbasak, nope.
<xnox> rbasak, these new microcodes require early initramfs loading code; which is not in trusty. And I don't think intel-microcode is widely installed in trusty.
<xnox> rbasak, in xenial we have started automated intel-microcode installation with ubuntu-drivers
<rbasak> I see. Thanks.
<rbasak> xnox: in the past the intel-microcode SRU updated the dat file only. With your backport it has the effect of changing more, such as debhelper compat level and the initramfs-tools hook. Do you have an opinion on one approach over the other?
-queuebot:#ubuntu-release- New: accepted rustc [arm64] (artful-proposed) [1.17.0+dfsg2-7]
-queuebot:#ubuntu-release- New: accepted rustc [amd64] (artful-proposed) [1.17.0+dfsg2-7]
-queuebot:#ubuntu-release- New: accepted rustc [s390x] (artful-proposed) [1.17.0+dfsg2-7]
-queuebot:#ubuntu-release- New: accepted rustc [i386] (artful-proposed) [1.17.0+dfsg2-7]
<xnox> rbasak, i'd rather do wholesome backports. the changes are improve text output during initramfs generation. Pre-v4.4 handling of kernels is not as relevant on xenial, unless people boot trusty kernel (still)
<rbasak> xnox: that's not general SRU policy though :-/
<slangasek> Laney: well, I was working on transitions over the weekend, and the number of stuck tests that I was running across was significant enough that I batch retried, and 800 seemed a bit high.  Do you have some idea of the failure rate here, that would inform whether it's worth putting effort into the cause vs. just batch retrying on the regular?
<xnox> rbasak, this is hwe backport of binary blobs for restricted.
<rbasak> xnox: it is; however the packaging is not a binary blob.
<slangasek> Laney: but also, if you need someone else to hit the mass-retry button, I can certainly do that ;)
<Laney> slangasek: do you know what the problem was?
<xnox> rbasak, e.g. are nvidia packages backported piecewise, or just straight backports of the new upstream releases (and the new packaging)?
<slangasek> no clue
<Laney> it's not regular, at least not on that scale
<Laney> but there could be a systemic problem that hits at one time
<rbasak> xnox: I don't know. Is it?
<Laney> something like: the initial dist-upgrade fails
<xnox> rbasak, there is more room for error by modifying this; since one has to be careful and exclude packaging of the broken microcodes.
<rbasak> I can see that a wholesale packaging update might be necessary depending on the nature of the upstream blob update (eg. if old packaging cannot cope with it).
<ypwong> infinity, can you help us to review the xenial sru for fwupdate?
<slangasek> Laney: well, there had also been several big packages going through the system (nodejs, perl, ...), so it's possible 800 was in line with the overall error rate?  But I don't know how to even measure that error rate
<rbasak> In this case, isn't the packaging more closely tied to the Free bits, rather than the non-Free bits? The blob itself remains a blob all the way through to the hardware, no?
<xnox> zesty diff is smaller, since zesty base is newer thus that one looks a lot more like just the blob update
<rbasak> That statement sounds likely to be true, but I don't follow what point you're making there. I was reviewing the Xenial diff to start with.
<xnox> that's backwards no? =)
<xnox> yakkety all diffs are needed.
<Laney> slangasek: We have the information needed (exit code of autopkgtest) in a database, so it could be exposed on http://autopkgtest.ubuntu.com/statistics
<Laney> 800 at once is definitely more than I'd expect
<Laney> I suspect a package was failing to install or similar
<rbasak> I find it easier to start with the most invasive set of decisions. Then reviewing the smaller diffs is easy :)
<Laney> I pushed a change earlier that should result in more runs being recorded as failures (with version 'unknown') rather than being left in running state
<slangasek> Laney: you have an error code for these test requests that end up stuck in 'running'?  They don't seem to ever show up on the per-package pages
<Laney> It's because they fail too early for autopkgtest-web to know the current version, so it skips them
<slangasek> ah
<Laney> that's what my fix remedies
<xnox> rbasak, the initramfs hook updates are good / wanted in xenial; update from debhelper compat 7->9 is imho also good as we do want microcode package to build exactly the same way on all releases. And ideally we do want to update it on continious basis.
<Laney> well, it fakes up a version of 'unknown'
<xnox> not taking compat changes, creates more work and divergence
<slangasek> yeah, that seems like a good improvement :)
<Laney> so you should at least easily be able to browse them rather than having to surf swift via its API
 * xnox ponders if intel-microcode really should be a snap
<slangasek> makes the state more discoverable
<rbasak> xnox: perhaps so, but in that case should we not have those changes go through the usual SRU process with their own bugs, justifications, regression tests, etc?
<rbasak> xnox: and for the future "exactly the same way" / "update it on continious basis", I agree this might be what we want in general, but I think that should probably form an SRU exception that we want to formulate, review, approve, etc.
<xnox> rbasak, perhaps, but all of them are "backport the latest micocode package to stable releases" which is what the bug report in question is.
<xnox> rbasak, the bug here is not "cherrypick high-severety microcode updates only for Skylake"
<rbasak> OTOH this particular update we should probably just get through, and for that, I think minimising it to the blob update makes more sense, unless there's a particular reason why that can't be done or there's a specific reason it carries higher risk.
<xnox> my request here is for a wholesome backport to latest, not a targeted fix for just this one skylake HT bug.
<cjwatson> *wholesale
<rbasak> xnox: OK, but if you want to drive the more general bug, it'll end up in the slow lane.
<xnox> cjwatson, yes, checked dictionary.
<xnox> rbasak, it definately should be in the slow lane, with extra long phasing. I am expecting it will be in proposed for a month of so.
<xnox> rbasak, as we need to collect multiple possitive results on multiple CPU SKUs / Families.
<rbasak> I agree with extra long phasing and a long time in proposed. I was expecting though to be able to fast track a blob update (only) into proposed so users had somewhere official from which to get it (for opt-in updates).
<xnox> there are a lot of updates to a lot of microcodes, and any one of them can regress anything (to the point of graphics not working, or systems not booting)
<xnox> rbasak, that would diverge packages and create sru-only delta which i do not want to support, nor maintain, nor debug going forward.
<xnox> (delta vs debian)
<xnox> imho it is a mistake that we do not routinely update microcode packages, the way we e.g. update the hwe-kernels.
<rbasak> It's been done before. I'm not ruling out your longer term plans at all here. If those are successful, then any difficult maintainability point becomes moot.
<xnox> rbasak, given lack of dependencies it would be nice to copy down the .deb verbantim. but we will not do that.
<xnox> rbasak, please review yakkety/zesty, i think you will have less objections about those.
<xnox> rbasak, and i prefer for later releases be fix released, before even accepting xenial package.
<xnox> unless you object to s/7/9 in those too
<rbasak> AFAICT, either I need to accept the packaging changes on the basis that they are approved under current SRU policy (perhaps with approving whatever I need to that is within my remit), and so I can accept X/Y/Z subject to review this way, or I don't. I don't think it makes sense to accept Y/Z and not X on a policy basis. And if I did, but we later decided to do something different, that'd be even
<rbasak> more of a pain to manage in the future.
<rbasak> So I think ~ubuntu-sru needs to resolve what to do here first, if you want to include packaging changes in this update.
<rbasak> OTOH I'd accept a blob-only update into all three releases as I don't think there's any SRU policy question there, but you've said and given reasons as to why you don't want that.
<xnox> rbasak, right, my thinking behind this upload was that this is backport-published-to-updates-via-proposed-testing
<rbasak> That's a summary of my thinking right now. I'd like opinions from other ~ubuntu-sru if any are around please.
<xnox> i did not prepare these as classic SRUs.
<xnox> and backports minimise delta / changes, to only those neccessory to get something building on older release; no changes are required here, as debian too backports this package as far back as is reasonable.
<rbasak> The regression risk there though is for example that the delivery mechanism changes to something that older kernels cannot support.
<rbasak> OTOH, it seems unlikely to me that just updating the blobs would pose any difficulty for a system on which the delivery mechanism already works (and if it doesn't, that's a matter for a more specific SRU following the usual process).
<xnox> the risk of buggy microcodes / microcodes with regressions is much higher. The last delivery change was in the v3.13 kernels, and has not changed since.
<rbasak> "the risk of buggy microcodes / microcodes with regressions is much higher" - how so?
<xnox> (the requirement around built-in / non-builtin module is imho insignificant)
<rbasak> "The last delivery change was in the v3.13 kernels" - only because you specifically know that. What might you not know about that is in the same class of problems?
<xnox> rbasak, re:buggy microcode the infamous lock ellision update
<xnox> that needed newer glibc on the host too, to prevent it from using the now disabled lock ellision, resulting in crashes.
<xnox> e.g. one needed newer userspace glibc and the new microcode.
<xnox> that was non-obvious during the microcode update.
<xnox> because of lack of disclosures from intel
<rbasak> xnox: and how would backporting the latest packaging have avoided that, if that packaging didn't have the versioned dependency because we didn't know about it?
<xnox> it doesn't, due to lack of information. Therefore bisecting and cherrypicking individual microcode updates and/or cherrypicking changes does not reduce risk at all. The only way we can reduce risk is extensive in-the-field testing on multiple of microcode families and watch for regression bug reports.
<xnox> because we need positive tests that things are not broken horibbly on N latest cpu families. E.g. at least as far back as e.g. ivy bridge today.
<rbasak> xnox: fine, but it makes no difference to your example whether we backport the packaging or backport only the blogs.
<rbasak> *blobs.
<xnox> validation matrix explodes. I do not think we will be able to get comprehensive coverage for every cpu family, on every release series. therefore we will have to trust the validation from multiple releases.
<rbasak> I still fail to see how it would be different in your example whether we backport blobs or backport the packaging. The packaging made no difference to that situation.
<xnox> which is an argument for not doing these updates, and keep systems knowgly vulnerable.
<xnox> rbasak, if the packaging makes no difference, why should i be creating N versions of packaging, instead of maintaining one version of packaging?!
<xnox> =)
<xnox> and then debugging the case where the packaging did make a difference.
<rbasak> Because minimal changes to stable releases minimised regression risk, as the packaging includes interactions with other components (such as the kernel) where there is a non-zero risk of regression that can be mitigated by not changing it.
<rbasak> *minimises
<xnox> my understanding is that e.g. snapd, firefox, linux-hwe, cloud-archive  use a backport model of complete updates to latest upstream and packaging changes with minimal delta w.r.t. the version being backported. Rather than minimal delta w.r.t. each of the targetted releases.
<xnox> i understand not taking 99% of changes where the actual bugfix is a one-lines; i do not understand rejecting 1% of packaging changes, when 99% are all needed.
<rbasak> Yes, and each of those have a documented exception and individual policy. We don't currently have one of those for intel-microcode.
<xnox> where can i look at that?
<rbasak> And each of those has had the pros and cons considered on a case by case basis.
<rbasak> https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases
<xnox> ack thanks
<rbasak> Firefox isn't there. Technically it doesn't have an SRU exception AFAIK. It goes in via the security pocket, and the security team have their own polices.
<rbasak> Though in practice an SRU would probably be fine because we do it all the time anyway (because security).
<rbasak> I've written up what I think is the current situation in the bug. I'm EOD for now - I think from our discussion you're not in a hurry?
<slangasek> Depends: libsbml perl (not considered)
<slangasek> hmph
<slangasek> cjwatson: do you have any idea why auto-sync says dictem_1.0.4.orig.tar.gz content has changed, given that it arrived in Ubuntu via auto-sync?
<slangasek> libfile-sharedir-projectdistdir-perl/1.000008-1
<slangasek> which are worse, perl package names or perl package version numbers?
<infinity> slangasek: Because it did.
<slangasek> infinity: so Debian's orig.tar.gz changed?
<infinity> slangasek: dak is slack about maintaining the constraint if things are no longer on disk. :(
<slangasek> ah, so this was a package removal/readd?
<infinity> slangasek: Debian's original orig only existed briefly.  It went (accidentally, probably) native in 1.0.4-2, then back to non-native in -4
<infinity> slangasek: But we have a record of -1, and LP won't let you do that:
<infinity> slangasek: https://launchpad.net/ubuntu/+source/dictem/1.0.4-1
<infinity> slangasek: So, the only solution here would be to fake the sync using the orig from the -1 upload.
<slangasek> right
<infinity> slangasek: Not that it matters, given that -3 and -4 were no-ops, really.  Just the maintainer asserting his non-demise.
<infinity> (Well, they should be no-ops, according to the changelog.... Of course, the new orig might have made them excitingly different!)
-queuebot:#ubuntu-release- Unapproved: apport (zesty-proposed/main) [2.20.4-0ubuntu4.2 => 2.20.4-0ubuntu4.3] (core)
-queuebot:#ubuntu-release- Unapproved: apport (yakkety-proposed/main) [2.20.3-0ubuntu8.4 => 2.20.3-0ubuntu8.5] (core)
-queuebot:#ubuntu-release- Unapproved: apport (xenial-proposed/main) [2.20.1-0ubuntu2.7 => 2.20.1-0ubuntu2.8] (core)
<slangasek> Laney, infinity: I'm interested in your thoughts on https://bugs.launchpad.net/britney/+bug/1700668
<ubot5`> Ubuntu bug 1700668 in britney "make it easier to reset baseline for autopkgtests that regress in release" [Undecided,New]
-queuebot:#ubuntu-release- New sync: ocamlbuild (artful-proposed/primary) [0.10.1-1]
<xnox> ^ would unblock ocaml transition going further
<slangasek> not an autosync? :)
-queuebot:#ubuntu-release- New: accepted ocamlbuild [sync] (artful-proposed) [0.10.1-1]
<xnox> slangasek, from experimental
<slangasek> ah
-queuebot:#ubuntu-release- New binary: ocamlbuild [amd64] (artful-proposed/none) [0.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocamlbuild [ppc64el] (artful-proposed/none) [0.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocamlbuild [arm64] (artful-proposed/none) [0.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocamlbuild [s390x] (artful-proposed/none) [0.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocamlbuild [i386] (artful-proposed/none) [0.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocamlbuild [armhf] (artful-proposed/none) [0.10.1-1] (no packageset)
<xnox> slangasek, seems to me that all the bugs of failed to install/upgrade are filed against random package that happens to be the unlucky one to call insserv or run of disk space, etc.
<xnox> https://bugs.launchpad.net/ubuntu/+source/systemd/+bugs?field.searchtext=install%2Fupgrade&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
<xnox> trianging these is not fun.
<slangasek> xnox: experiencing the upgrade failures is also not fun; can we get rid of insserv yet?
<xnox> slangasek, my understanding is that we have and debian did too. but not in xenial?!
-queuebot:#ubuntu-release- New: accepted ocamlbuild [amd64] (artful-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted ocamlbuild [armhf] (artful-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted ocamlbuild [ppc64el] (artful-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted ocamlbuild [arm64] (artful-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted ocamlbuild [s390x] (artful-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted ocamlbuild [i386] (artful-proposed) [0.10.1-1]
<slangasek> right, it is gone, but still causes upgrade failures in xenial
<xnox> hm, my system seems to be broken
<slangasek> since insserv in xenial isn't integrated with systemd the way it was with upstart, I think the right fix is to SRU insserv to make it non-fatal
<xnox> I'm getting segfaults
<xnox> [661832.017428] schroot[30225]: segfault at 500000002 ip 00007fc0023262b8 sp 00007ffde3b7f060 error 4 in pam_cgfs.so[7fc002323000+6000]
<xnox> [657710.517534] pcscd[12977]: segfault at 10 ip 00007f7792767d44 sp 00007f778abc8e20 error 4 in libpthread-2.23.so (deleted)[7f779275e000+18000]
<xnox> that can't be good.
<xnox> slangasek, does systemd in xenial need any of the insserv orderings? and e.g. do we still use insserv orderings for e.g. shutdown?
 * xnox thought we didn't
<slangasek> xnox: that's what I'm saying, I don't believe it's meaningfully integrated with systemd at all
<slangasek> should be verified, but AIUI it's mostly pointless
<xnox> ack. let me add a trello card about that
<slangasek> (and so shouldn't be allowed to cause upgrade errors)
#ubuntu-release 2017-06-27
<ginggs> Would someone please 'force-badtest r-cran-surveillance/1.13.0-1' ?  The tests were broken in the release pocket by the upload of gdata/2.18.0-1
<tsimonq2> stgraber: I think we're still on for Alpha 1, can you set the archive freeze and spin up the images please?
<tsimonq2> stgraber: Or set something in iso.qa.ubuntu.com, rather.
<tsimonq2> stgraber: All of the participating flavors are indicated here: https://wiki.ubuntu.com/ArtfulAardvark/Alpha1
<acheronuk> tsimonq2: just need to quickly update kubuntu meta
<tsimonq2> acheronuk: ack
<acheronuk> will upload in a few secs when the script finishes
<tsimonq2> wfm
<acheronuk> tsimonq2: ???
<tsimonq2> acheronuk: works for me
<acheronuk> oh, right
<tsimonq2> yeah
<tsimonq2> lol
<tsimonq2> acheronuk: Either way I don't think stgraber is around.
<tsimonq2> My sleep schedule is erratic as it is...
 * acheronuk makes more coffee to wake up the acronym cells
<apw> normally the freezes are at around 1800 UTC
<apw> (or so it seems to me)
<tsimonq2> apw: *shrug*
<acheronuk> yeah, though would be just my luck to miss it if I assumed that
<apw> heh there is that
<tsimonq2> acheronuk: Good idea. *fetches coffee when it's almost 3 AM*
<acheronuk> oi! you should sleep sometime!
<tsimonq2> That's what the daytime is for. :P
<acheronuk> lol.... uploaded. so should be through in plenty of time
<rbasak> SRU team: second opinion on bug 1700373 please?
<ubot5`> bug 1700373 in intel-microcode (Ubuntu Zesty) "Please update microcode to version 20170511 on all supported platforms" [Undecided,In progress] https://launchpad.net/bugs/1700373
<apw> rbasak, oh any particular aspect?
<rbasak> apw: my comment 10
<rbasak> apw: on the full package backport vs blob only question.
<apw> rbasak, i would feel the same, that backporting the content ony would be my expectation, as delivery is local to the series
<apw> rbasak, pretty much i agree with your comment en-toto
<rbasak> apw: thanks. Mind if I comment on the bug?
<rbasak> (ie. quote you)
<rbasak> And xnox: ^ - do you want to keep driving this? We can either figure out an exception for intel-microcode with a commitment from a team for regular updates, or push a one-off blob update through, or both of those.
<apw> rbasak, feel free to quote me indeed
<rbasak> (an exception documented and approved in the usual way)
<rbasak> apw: thanks!
<jamespage> apw: morning
<jamespage> apw: any chance you could look at the keystone updates in UNAPPROVED for xenial and yakkety; the equivalent is already in zesty proposed
<apw> jamespage, will try and fit it in today ...
<jamespage> apw: ta
<Laney> slangasek: https://bugs.launchpad.net/auto-package-testing/+bug/1688516
<ubot5`> Ubuntu bug 1688516 in Auto Package Testing "No way to mark a test as 'accepted regression'" [Undecided,New]
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.26.4~14.04 => 2.26.6~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.26.4+16.10 => 2.26.6+16.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.26.4 => 2.26.6] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.26.4+17.04 => 2.26.6+17.04] (desktop-core, ubuntu-server)
<ginggs> Would someone please 'force-badtest r-cran-surveillance/1.13.0-1' ?  The tests were broken in the release pocket by the upload of gdata/2.18.0-1
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-123.172] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-58.63] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-83.106] (core, kernel)
 * apw eyes the snapds sideways
<xnox> the version numbers used are neat, with xenial getting the naked version number.
<apw> they are confusing and annoying :)
<apw> and backwards
<xnox> i find them perfectly reasonable, just like my intel-microcode backports.
<xnox> above are back and forward ports =)
<ogra_> yeah, the release with development focus actually has the plain versionn
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-83.106]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-58.63]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-123.172]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (yakkety-proposed) [2.26.6+16.10]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (zesty-proposed) [2.26.6+17.04]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (trusty-proposed) [2.26.6~14.04]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.26.6]
<apw> ^ rejecting per uploader, issue with artful needing a rework
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-83.106~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.8.0-58.63~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-83.106~14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.8.0-58.63~16.04.1]
<gaughen> slangasek - looks like cloud-init and nplan are reading to be pushed to the xenial archive. Would you handle it please?
<gaughen> slangasek, also would you look at klibc for trusty
<gaughen> fginther, ^^
<ginggs> Would someone please 'force-badtest r-cran-surveillance/1.13.0-1' ?  The tests were broken in the release pocket by the upload of gdata/2.18.0-1
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.11.0-9.14] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.11.0-9.14]
<slangasek> gaughen: looks like nplan/xenial has already been released (but not yakkety,zesty; so those are also done now)
<apw> erp, i wonder how that happened
<gaughen> I hear that bdmurray took care of nplan - thanks Brian!
<bdmurray> I didn't do yakkety or zesty because of the autopkgtest failures.
<slangasek> gaughen: cloud-init released; klibc released
<gaughen> slangasek, thank you! woot!
<slangasek> bdmurray: yeah, it's a known flaky test; I've marked it badtest now in the hints, and will pester for improvement for the next SRU
<gaughen> fginther, xnox ^^
<slangasek> bdmurray: related, LP: #1700668
<ubot5> Launchpad bug 1700668 in britney "make it easier to reset baseline for autopkgtests that regress in release" [Undecided,New] https://launchpad.net/bugs/1700668
<slangasek> Laney: in regards to your response on the bug, I am personally unconvinced this is the right level of stick to use for getting people to fix their autopkgtests.  How often do you enforce in a situation like this, vs. doing a bunch of analysis and then giving it a pass anyway?
<Laney> slangasek: Sometimes, and more often I fix things myself.
<Laney> Where is the stick at all?
<Laney> I think we're too far on the ignoring side ATM.
 * apw feels that too
<rbalint> apw: sil2100 told me you may had comments regarding the gce-compute-image-packages update #1700027
<rbalint> apw: but i was not around :-(. is there anything i should fix in the upload?
<slangasek> Laney: ok; but is it a better use of time to use the gate like this, vs. acknowledging that the gate failed (because the regression made it into devel) and then spending some time working through the backlog of failing autopkgtests more generally?
<ginggs> slangasek, Laney: seeing you are discussing autopkgtests, would you please consider 'force-badtest r-cran-surveillance/1.13.0-1' ? The tests were broken in the release pocket by the upload of gdata/2.18.0-1 - I don't think holding back r-base because of this gains us anything
<slangasek> rbalint: apw had concerns about the lintian warnings; but I think it was just this one, in which case it's ignorable because it's an NSS module? W: google-compute-engine-oslogin: package-name-doesnt-match-sonames libnss-oslogin2
<apw> slangasek, yes htat was the one
<slangasek> ginggs: yes, that's a great example, I saw your request last night and re-triggered against the release pocket, to confirm it was really a regression there before overriding, and now it takes a release team member's time again to act on that rather than it being automatic ;)
<slangasek> Laney: ^^ for your consideration
<slangasek> (and I'm adding the hint)
<slangasek> apw: I'm +1 on ignoring that warning because it's an nss module and sonames are superfluous there anyway; I haven't reviewed the rest of it so I'll defer to you if you want to accept
<ginggs> slangasek: thanks!
<ginggs> slangasek: just to be clear, does running the r-cran-surveillance tests with trigger r-cran-surveillance/1.13.0-1 run only against the release pocket?
<slangasek> ginggs: yes
<slangasek> ginggs: this trick fails if there is a newer version of the package itself in -proposed, but that's not the case here
<ginggs> slangasek: ah, ok
<slangasek> xnox: so this new version of ocaml seems to have changed something about int types that are exposed by default?  a bunch of build failures w/ int64, uint32 undefined...
-queuebot:#ubuntu-release- Unapproved: libvirt (zesty-proposed/main) [2.5.0-3ubuntu5.2 => 2.5.0-3ubuntu5.3] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: libvirt (xenial-proposed/main) [1.3.1-1ubuntu10.10 => 1.3.1-1ubuntu10.11] (ubuntu-server, virt)
<xnox> slangasek, i have noticed that. It seems that 4.04 is more strict than before, and e.g. these used to end up as warnings before, but are errors now. I have fixed some already by looking at the right/matching signature types in the headers.
<xnox> slangasek, it is a common case of "use C99 compliant uint32_t instead of weird uint32"
<xnox> i'm uploading rounds and fixing them. Many/most of round2 uploaded and fixed. round3 uploaded and yet to fix up.
<slangasek> xnox: ack
<xnox> there are 12 rounds in total =/
<slangasek> xnox: fwiw I've tended to prefer uploading them all in a go and sorting out the build failures on launchpad; ymmv
<xnox> slangasek, i semi do that. Imho it's a bit nicer to follow the installability chain. But meh. Feel free to pinch in if you wish, archive is the current state of the art together with http://people.canonical.com/~ubuntu-archive/transitions/html/html/ocaml.html
<slangasek> have looked at htslib autopkgtest regressions and punted them to the Debian maintainer
<xnox> i'll try to do levels 3 and 4 tomorow.
<xnox> yeah, i'm working on build-failures and instalability at the moment, then autopkgtests....
<slangasek> xnox: I filled my quota with ghc last week, I'm not touching the ocaml uploads right now ;)
<xnox> =)))))))
<xnox> i have never done ocaml before, so this is somewhat fun.
<slangasek> xnox: fishing for French citizenship, then?
<xnox> i love how it tangles into everything perl4caml camljava ocaml-libvirt =)
<xnox> slangasek, qui!
<xnox> slangasek, i don't need citizenship I can use one of my booklets to move there.
<xnox> I will be off to scouting trips to milan, barcelona, and prague. To check if they are any good.
<xnox> i only want to move to places i have permanent residence on arival, such that i don't need to naturalise yet again.
<slangasek> Laney: so in the case of the 34 regressed perl modules (whose cause I don't know), do you think I should have handled them differently than I did?
<slangasek> apw: are you good with google-compute-engine-oslogin now, or should I re-review it?
<ginggs> slangasek: would you 'force-badtest node-tap/8.0.0-4ubuntu2/armhf' please?  it was flaky in zesty too http://autopkgtest.ubuntu.com/packages/node-tap/zesty/armhf
<slangasek> ginggs: you just want it marked for artful, not zesty, right?  Yes, I had triggered a baseline test for that one yesterday and hadn't come back around to notice the result
<slangasek> (done)
<ginggs> slangasek: yes, for artful. thanks!
<jbicha> hi, can we demote metacity to universe now? the only rdepends is ubiquity but that's an alternate (and src:metacity is not present on Ubuntu's artful daily images)
<infinity> jbicha: Not until component-mismatches agrees.
<infinity> Err, wait.
<infinity> jbicha: It's in universe. :P
<infinity>  metacity | 1:3.25.1-1ubuntu2    | artful/universe | source, amd64, arm64, armhf, i386, ppc64el, s390x
<jbicha> oh, sorry about that, thanks :)
<bdmurray> infinity / slangasek: Could one of you review my apport uploads in the SRU queues? Its just a test fix.
<infinity> bdmurray: Yup.
<infinity> bdmurray: Which releases?
<infinity> bdmurray: Guess who didn't use -v when building?
<bdmurray> uh me?
<infinity> bdmurray: Yup.
<bdmurray> infinity: Okay, I'll handling the rejecting too then.
-queuebot:#ubuntu-release- Unapproved: apport (zesty-proposed/main) [2.20.4-0ubuntu4.2 => 2.20.4-0ubuntu4.3] (core)
-queuebot:#ubuntu-release- Unapproved: rejected apport [source] (zesty-proposed) [2.20.4-0ubuntu4.3]
<infinity> cpaelzer: I added some comments to your ntpd bug.  Also, bileto SRUs make me a sad panda.
-queuebot:#ubuntu-release- Unapproved: apport (yakkety-proposed/main) [2.20.3-0ubuntu8.4 => 2.20.3-0ubuntu8.5] (core)
-queuebot:#ubuntu-release- Unapproved: rejected apport [source] (yakkety-proposed) [2.20.3-0ubuntu8.5]
-queuebot:#ubuntu-release- Unapproved: apport (xenial-proposed/main) [2.20.1-0ubuntu2.7 => 2.20.1-0ubuntu2.8] (core)
-queuebot:#ubuntu-release- Unapproved: rejected apport [source] (xenial-proposed) [2.20.1-0ubuntu2.8]
<bdmurray> infinity: okay, should be fixed now
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (xenial-proposed) [2.20.1-0ubuntu2.8]
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (yakkety-proposed) [2.20.3-0ubuntu8.5]
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (zesty-proposed) [2.20.4-0ubuntu4.3]
<Laney> slangasek: Well, if 34 packages start failing at once that probably sounds like something to investigate and fix. But if you did, and you think that all those tests are bad, then it's correct.
<slangasek> Laney: it's perl, so 34 out of a couple hundred; and they regressed in the release pocket, so they're bad for reasons unrelated to either perl or the module package itself having regressed; and I have no idea about the perl auto-autopkgtesting stuff
<slangasek> do you think perl should block (and hold up other stuff in -proposed) because of a small percentage of tests that are broken because of a regression in the perl test infrastructure?
<slangasek> my argument is: once we've identified that the failed autopkgtest is not a regression in -proposed, what is the value of blocking packages which are not to blame in -proposed until this is fixed?
<Laney> ok, what's the path to getting these tests passing again?
<Laney> I think the fact that our infrastructure isn't fine grained enough to catch all regressions when they happen is unfortunate, and when we do get pointed to something that's gone wrong then somehow it should be looked at.
<Laney> If we'd have managed to catch the regressions at the right time there would be no question that there was a bug to be fixed
<Laney> Unfortunately we didn't, but we're still being told about a problem heere
<Laney> got to go, sorry
<slangasek> Laney: so, someone can investigate the perl automated test harness to understand why it broke, and whose fault it is that it's now broken, and fix either the harness or the tests.  But given that it has already regressed in devel, is there any reason that these should be a higher priority to fix, or more of a blocker, than any of the other failing autopkgtests in devel?
<slangasek> I certainly think that once the cause is identified, we should figure out a way to trigger tests for the test harness updates so we don't do the same in the future
<slangasek> Laney: what this comes down to, for me, is the sense that everything beyond the actual triggering of tests to get a baseline view - the log analysis and the setting the hints - was busywork; and while I could have opted to dig into the test failures instead to resolve them, which would have not been busy work, it also would have not been /priority/ work and would not have been a sensible path
<slangasek> towards my goal at the time, which was unblocking perl for migration
<xnox> slangasek, Laney, i think a lot of autopkgtest work that ubuntu does is futile, until debian starts to gate on autopkgtests failures too.
 * xnox did not follow all of the discussion
<slangasek> Laney: so I would like to explicitly decouple, as a policy, the work of getting transitions unstuck from -proposed from the work of improving the quality of tests in devel.  Unpicking transitions is already a lot of yak shaving, and I think having to debug tests in devel is a yak too far :)
<doko> xnox: should we propose an autopkg BoF for DebConf?
<xnox> slangasek, i guess we should be staging transitions in a silo?
<doko> please no ...
<xnox> doko, probably.
<slangasek> xnox, doko: the piece that's missing is a committment from the Debian release team to gate.  I think an email follow-up to debian-release is needed
<slangasek> as for staging in a silo, <shrug> not all transitions are going to happen that way
<slangasek> and it will trigger all the autopkgtests twice
<slangasek> and it doesn't fix anything about the problem I'm currently complaining about
<xnox> sure. but things would be easier if adt tests do pass for things synced from debian.
<xnox> and do not regress
<slangasek> xnox: here's an irrelevancy to distract you: should we change the autopkgtest interface from returning a boolean to returning a bitfield, so that packages can be fine grained about declaring success/failure, and we can ratchet individual tests separately?
<xnox> slangasek, at clearlinux.org QA team wrote a log analyzer to extract the results of many variety of test suite and report them in https://testanything.org/tap-specification.html and then they would monitor regressions of individual tests.
<xnox> thus the granularity tracking of regressions was down to asserts.
<slangasek> if there was a log analyzer that ensured I would never again have to traverse log files by hand guessing which of 'FAIL' / 'fail' / 'not ok' / 'bad' / 'ERROR' I needed to key on for a particular package, I would enjoy that
<xnox> it did support java, perl, python, php, R, the GNU thing, gcc etc.
<bdmurray> The linux autopkgtests are flaky and shouldn't be considered when looking at releasing an SRU correct?
<xnox> slangasek, does cooked rhubarb count as fruit?
<slangasek> bdmurray: generally so, yes.  I usually spot check the failures to be sure that it's not a real regression /this/ time, and get a little bit more annoyed in the process ;)
<slangasek> xnox: sure, why not
<xnox> slangasek, is it xavier approved? =)
<slangasek> xnox: haven't offered him any yet
<xnox> rhubarb compote hmmmm
<doko> bdmurray: your bot for the -done tags still triggers if there is a release specific tag and an unspecific tag. is this intended?
<doko> https://bugs.launchpad.net/bugs/1667407
<ubot5> Ubuntu bug 1667407 in coreutils (Ubuntu Xenial) " improve 2x-3x sha256sum performance on ppc64le due to current gcc optimization bug" [Undecided,Fix committed]
<bdmurray> doko: I saw that happen and probably not.
<slangasek> xnox: but not Chinese rhubarb
-queuebot:#ubuntu-release- Unapproved: gpaste (xenial-proposed/universe) [3.18.3-1 => 3.18.6-0ubuntu1] (no packageset)
#ubuntu-release 2017-06-28
<tsimonq2> Can someone on the release team please get the ball rolling for Alpha 1? infinity slangasek stgraber
<tsimonq2> i.e. put in archive blocks, spin up images on iso.qa.ubuntu.com
<tsimonq2> The timing is tight as it is...
<slangasek> tsimonq2: I'm EOD now and not available to follow through on all of this, but I can at least create the milestone on iso.qa.u.c right quick
<tsimonq2> slangasek: gracias
<stgraber> tsimonq2: crap, got stuck in meetings... I started preparing the release block then got interrupted...
<stgraber> will sort it out after dinner
<tsimonq2> stgraber: Ok, thanks :)
<tsimonq2> stgraber: Just wanted to make sure you didn't forget :)
<tsimonq2> (granted, I did ping you at 2 AM, so I exprected it to be a bit :P)
<tsimonq2> *expected
<tsimonq2> s/didn't forget/saw my message/ as well
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Artful Alpha 1] (20170628) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Artful Alpha 1] (20170628) has been added
<tsimonq2> I thought Xubuntu wasn't participating?
<stgraber> I don't think it is
<stgraber> I suspect slangasek setup the tracker but didn't change the series list
<stgraber> ok, done with the tracker I think
<stgraber> crontab updated, triggering an initial build
<stgraber> rebuild requested, builds should show up soon
<stgraber> going to figure out how to generate the right britney hint now
<stgraber> freeze in place
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Artful Alpha 1] (20170628) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Artful Alpha 1] (20170628) has been added
<tsimonq2> stgraber: \o/
<tsimonq2> stgraber: What about the other flavors?
<stgraber> they're supposed to be building
<stgraber> yeah, I see Launchpad building a bunch of stuff still
<tsimonq2> Ok cool
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Artful Alpha 1] (20170628) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Artful Alpha 1] (20170628) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Artful Alpha 1] (20170628) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Artful Alpha 1] (20170628) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Artful Alpha 1] (20170628) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Artful Alpha 1] (20170628) has been added
<tsimonq2> stgraber: Can we get Lubuntu Next as well?
<acheronuk> confusing artful hiding at bottom of page :/ http://iso.qa.ubuntu.com/qatracker
<stgraber> slangasek: so hmm, I seem to have broken britney with the freeze hint, just not sure how :)
<slangasek> stgraber: orly. looking
<stgraber> Traceback (most recent call last):
<stgraber>   File "/home/ubuntu-archive/proposed-migration/code/b2/britney.py", line 278, in __init__
<stgraber>     self.read_hints(self.options.hintsdir)
<stgraber>   File "/home/ubuntu-archive/proposed-migration/code/b2/britney.py", line 1081, in read_hints
<stgraber>     (x, package, hint2.version, hint2.user, hint2.days,
<stgraber> AttributeError: 'Hint' object has no attribute 'days'
<stgraber> the freeze hint was generated using the usual command and doesn't look wrong to me (looked at a few past ones to compare)
<slangasek> stgraber: because the freeze hint blocks linux, but apw already has a block for that, so britney bails on a message that's almost never used
<slangasek> stgraber: I've dropped linux from the hint, the next run should go
<stgraber> slangasek: thanks
<apw> slangasek, now that is an esoteric bug ...
<slangasek> apw: better or worse than "upstream tarball contains a patch not found in upstream git tag that breaks the library on armhf, but no one noticed because 'make check' is commented out without explanation in debian/rules"?
<tsimonq2> stgraber: bump on Lubuntu Next? :)
<apw> slangasek, heh that one should get some kind of prize ...
<stgraber> tsimonq2: I added it and triggered a rebuild which is in progress now
<tsimonq2> stgraber: Ok, thank you. :)
-queuebot:#ubuntu-release- New binary: curry-frontend [ppc64el] (artful-proposed/universe) [0.4.2-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: curry-frontend [amd64] (artful-proposed/universe) [0.4.2-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: curry-frontend [i386] (artful-proposed/universe) [0.4.2-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: curry-frontend [s390x] (artful-proposed/universe) [0.4.2-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted curry-frontend [amd64] (artful-proposed) [0.4.2-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted curry-frontend [ppc64el] (artful-proposed) [0.4.2-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted curry-frontend [i386] (artful-proposed) [0.4.2-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted curry-frontend [s390x] (artful-proposed) [0.4.2-5ubuntu1]
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop amd64 [Artful Alpha 1] (20170628.1) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop i386 [Artful Alpha 1] (20170628.1) has been added
-queuebot:#ubuntu-release- New binary: curry-frontend [arm64] (artful-proposed/universe) [0.4.2-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-bayespy [amd64] (artful-proposed/universe) [0.5.8-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-bayespy [amd64] (artful-proposed) [0.5.8-1]
-queuebot:#ubuntu-release- New: accepted curry-frontend [arm64] (artful-proposed) [0.4.2-5ubuntu1]
<slangasek> well I've never seen that before. https://launchpadlibrarian.net/322236698/upload_12676800_log.txt
<slangasek> INFO Upload was rejected:
<slangasek> INFO 	faustworks_0.5~repack0-3_amd64.buildinfo: Unknown section 'programming'
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [amd64] (artful-proposed) [20170622-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [armhf] (artful-proposed) [20170622-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [ppc64el] (artful-proposed) [20170622-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [arm64] (artful-proposed) [20170622-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [s390x] (artful-proposed) [20170622-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [i386] (artful-proposed) [20170622-0ubuntu1]
<apw> slangasek, i did not know we had a definative list ...
<tsimonq2> *scratches head*
<tsimonq2> slangasek: It was fine in Debian, no?
<slangasek> I assume so
 * tsimonq2 wonders if there's an Ubuntu-specific list that differs from Debian's
<tsimonq2> Because with Debian it's in the Policy Manual
<cjwatson> slangasek,tsimonq2,apw: there's a Section table in Launchpad which we generally try to keep in sync with Debian
<cjwatson> but AFAICS there isn't a "programming" section in Debian either?
<apw> cjwatson, hrm, well thats all a bit of a mess
<cjwatson> I'm just double-checking Debian
<apw> and syncing that is a "it should just happen in the background by magic" kind of thing its not something we need to be congniscent of
<cjwatson> No, it's something we have to do explicitly
<cjwatson> Very rare though
<cjwatson> So in this case it's just because faustworks has an incorrect Section in its debian/control
<cjwatson> Mostly doesn't matter but we do minimal validation on the buildinfo, so ...
<cjwatson> "programming" wouldn't be a sensible section to add - it would duplicate lots of other things
<cjwatson> I'll file a Debian bug on faustworks
<apw> cjwatson, thank you for investigating that for us
<cjwatson> https://bugs.debian.org/866202
<ubot5> Debian bug 866202 in faustworks "faustworks: incorrect section in debian/control Source" [Normal,Open]
-queuebot:#ubuntu-release- Unapproved: rejected intel-microcode [source] (xenial-proposed) [3.20170511.1~ubuntu16.04.0]
-queuebot:#ubuntu-release- Unapproved: rejected intel-microcode [source] (yakkety-proposed) [3.20170511.1~ubuntu16.10.0]
<Ukikie> https://deb.li/3utEj - master 7a24640 faustworks debian/control Switched section to 'devel'
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (vivid-proposed/main) [3.19.0-88.96] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (xenial-proposed/main) [4.10.0-26.30~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-26.30] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: accepted intel-microcode [source] (zesty-proposed) [3.20170511.1~ubuntu17.04.0]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (vivid-proposed) [3.19.0-88.96]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (xenial-proposed) [4.10.0-26.30~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-26.30]
-queuebot:#ubuntu-release- Unapproved: session-shortcuts (xenial-proposed/main) [1.2 => 1.2ubuntu0.16.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: session-shortcuts (zesty-proposed/main) [1.2 => 1.2ubuntu0.17.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: session-shortcuts (yakkety-proposed/main) [1.2 => 1.2ubuntu0.16.10.1] (ubuntu-desktop)
<cpaelzer> infinity: sorry for the late reply - I'm actually off today - sorry to make you a sad panda
 * cpaelzer has weird images in his head now
<cpaelzer> IIRC in Seville it was encouraged to use bileto to push SRUs and such - I remember xnox saying he even prefers it
<cpaelzer> now with robru gone things might be different (or they were different all the time just depending on person)
<cpaelzer> anyway sorry my little panda - I can surely dput/debdiff as usual if that is preferred
<cpaelzer> I'll ready your comments on the bug - once I'm back at work for real
<cpaelzer> thanks already to look at it
<apw> cpaelzer, heh xnox doesn't have to review them :)
<xnox> cpaelzer, the feedback from those was that the tooling is bad. E.g. sru-queue-pull for review does not follow syncs into the queue right, and launchpad doesn't generate diffs / downloadable artifacts from the queue the way it does for direct uploads.
<rbasak> "git ubuntu queue sync" :-)
<rbasak> I'm hoping to get it functional enough to superseded sru-* in the ned.
<rbasak> end
<rbasak> It supports downloading from queue syncs because cpaelzer kept doing that to me :-)
<apw> rbasak, yeah nice idea, but i don't want to have to change, i am a dinosaur :)
<Odd_Bloke> How often do the automated syncs from Debian in artful happen?
<apw> iirc it is every 6 hours
<LocutusOfBorg> Odd_Bloke, some times a day
<LocutusOfBorg> mostly after debian dinstalls
<sil2100> cpaelzer: reviewing bileto SRUs is actually quite easy if you just know how to use bileto
<cjwatson> Every six hours, as apw says.
-queuebot:#ubuntu-release- Unapproved: sssd (xenial-proposed/main) [1.13.4-1ubuntu1.5 => 1.13.4-1ubuntu1.6] (kubuntu, ubuntu-desktop, ubuntu-server)
<slangasek> bdmurray: I see LP: #1556653 flagged as a candidate for SRU removal, which you sponsored; do you want to nag someone to verify, or do the honors?
<ubot5> Launchpad bug 1556653 in ktp-text-ui (Ubuntu Xenial) "ktp-text-ui crashed with SIGSEGV in ~SharedPtr()" [Undecided,Fix committed] https://launchpad.net/bugs/1556653
<bdmurray> slangasek: How about we just remove it
<slangasek> bdmurray: doing
<slangasek> "Steve Langasek does not have permission to unsubscribe SRU Verification."
<slangasek> otherwise, done
<slangasek> acheronuk: I see there is still a stack of kde 5.9.5 SRUs in zesty-proposed with to we
<slangasek> acheronuk: with no verification (LP: #1687444); is someone going to follow through on those?
<ubot5> Launchpad bug 1687444 in plasma-desktop (Ubuntu Zesty) "Zesty SRU tracking bug for KDE's Plasma 5.9.5" [Wishlist,Fix committed] https://launchpad.net/bugs/1687444
-queuebot:#ubuntu-release- Unapproved: pptpd (xenial-proposed/main) [1.4.0-7ubuntu0.1 => 1.4.0-7ubuntu0.2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~16.04.1 => 0.7.9-153-g16a7302f-0ubuntu1~16.04.2] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (yakkety-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~16.10.1 => 0.7.9-153-g16a7302f-0ubuntu1~16.10.2] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~17.04.1 => 0.7.9-153-g16a7302f-0ubuntu1~17.04.2] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop amd64 [Artful Alpha 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Next Desktop i386 [Artful Alpha 1] has been marked as ready
#ubuntu-release 2017-06-29
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~16.04.1 => 0.7.9-153-g16a7302f-0ubuntu1~16.04.2] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (yakkety-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~16.10.1 => 0.7.9-153-g16a7302f-0ubuntu1~16.10.2] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~17.04.1 => 0.7.9-153-g16a7302f-0ubuntu1~17.04.2] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (xenial-proposed) [0.7.9-153-g16a7302f-0ubuntu1~16.04.2]
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (yakkety-proposed) [0.7.9-153-g16a7302f-0ubuntu1~16.10.2]
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (zesty-proposed) [0.7.9-153-g16a7302f-0ubuntu1~17.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (zesty-proposed) [0.7.9-153-g16a7302f-0ubuntu1~17.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (yakkety-proposed) [0.7.9-153-g16a7302f-0ubuntu1~16.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [0.7.9-153-g16a7302f-0ubuntu1~16.04.2]
<acheronuk> slangasek: I tried a couple of times to get people to do some verification, without much luck so far. I'll ask again.
<acheronuk> everyone seems more keen on trying the new and shiny Plasma 5.10!
<cpaelzer> apw: infinity: rbasak: ok I'll continue to testbuild via bileto then and might reference to it e.g. for dep8 test previews, but I'll submit "normally" then as I really do not want to cause you more work
<cpaelzer> infinity: thanks for bringing that up - I didn't realize that causes trouble further down the SRU chain
<LocutusOfBorg> please let openldap migrate, thanks (libreoffice:i386 testsuite sucks)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Artful Alpha 1] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Artful Alpha 1] has been marked as ready
<LocutusOfBorg> why is the debian autosync so slow today?
<apw> big perhaps
<LocutusOfBorg> I don't see new imports being processed since ~24h or something like that
<LocutusOfBorg> lets wait a new dinstall
<LocutusOfBorg> and I can't upload stuff in my ppa :s
<LocutusOfBorg> e.g. moka-icon-theme, is almost two days old now
<cjwatson> LocutusOfBorg: my fault for breaking the importer config while trying to enable buster imports, by the looks of things; William landed a fix last night
<cjwatson> I'll roll that out today
<LocutusOfBorg> oh ok :) I tried to wait, but I didn't see mentions on irclogs, so I decided to write it here, thanks for caring/fixing
<cjwatson> I didn't mention it because I didn't know about the breakage until this morning :)
<LocutusOfBorg> I mean other people in general :)
<apw> LocutusOfBorg, is what the channel is for ...
<cpaelzer> infinity: thanks for thinkin with me thourhg potential regressiosn of bug 1593907
<ubot5> bug 1593907 in ntp (Ubuntu Zesty) "ntpdate startup routine prevents ntp service from launching up on Ubuntu 16.04 server on system boot; manually starting ntp service works: [FIX in DESCRIPTION], just need to apply it and release a new version" [Undecided,In progress] https://launchpad.net/bugs/1593907
<cpaelzer> infinity: I updated the bug, but TL;DR I think what you brought up is not an issue
<cpaelzer> IMHO - ready to be "revisited" for sponsoring & SRU
<LocutusOfBorg> hello, where should I report builders kernels upgrade requests? :P
<LocutusOfBorg> I found the culprit for the libreoffice-i386 testsuite sadness, as well as the rustc ppc64el build failures and so on
<LocutusOfBorg> debian bug: #865303
<ubot5> Debian bug 865303 in src:linux "libreoffice: Libreoffice Java features crash with Linux 3.16.43-2+deb8u1" [Serious,Fixed] http://bugs.debian.org/865303
<LocutusOfBorg> apw, maybe I can prod you, but this is not really about the Ubuntu kernel, but rather the buildds installed one
 * apw passes that info on ...
<cjwatson> LocutusOfBorg: in what sense is the buildd-installed kernel not the Ubuntu kernel?
<cjwatson> LocutusOfBorg: (they're upgraded automatically and routinely from cloud images)
<cjwatson> arm64 is currently a special case IIRC but that doesn't seem to be what you're talking about
<LocutusOfBorg> yep, I found it, and my last retry has picked up the kernel in security pocket
<LocutusOfBorg> the latest one seems to be reverting somewhat the CVE patch
<LocutusOfBorg> not sure if the published kernel has an incomplete patch or what, debdiffs between ubuntu kernels is difficult
<sbeattie> LocutusOfBorg: it's converting from an early iteration of the fixes to the ones that were accepted upstream, which also should address the java issues that were seen.
<sbeattie> (well, earlier)
<apw> LocutusOfBorg, what sbeattie said ...
<LocutusOfBorg> sbeattie, I see that, but rustc is failing on ppc64el in the same way in debian, lets wait for their give-back
<cjwatson> LocutusOfBorg: next importer run should work
<LocutusOfBorg> thanks!
<LocutusOfBorg> Laney, for your happyness debian bug: #866389
<ubot5> Debian bug 866389 in release.debian.org "transition: perl 5.26" [Normal,Open] http://bugs.debian.org/866389
<LocutusOfBorg> :)
<Laney> LocutusOfBorg: noooooooooope
<Laney> why would that make me happy anyway?
<apw> Laney, lets hope LocutusOfBorg has mastered sarcasm
<Laney> I hope that's what it is
<Laney> but I don't get why it's directed at me :P
<LocutusOfBorg> Laney, I remember your happyness for the 5.24 transition, was driven by you IIRC
<apw> Laney, i assume it will blow up the ADT queues, which will make you happy
<LocutusOfBorg> and yes, sarcasm is intended :)
<infinity> cpaelzer: Ahh, calling it with '-g' must be 'new' (for some value of new, I'm clearly old).  Did you check that with large offsets, the initial start just slams the system into a more correct time, instead of attempt to adjtime it with a days-long drift?
<infinity> cpaelzer: If it does one hard settimeofday, then moves on to adjtime, I agree that ntpdate is entirely useless in that scenario.
<infinity> cpaelzer: (It used to be that you explicitly wanted a non-adjtime ntpdate call first, then ntpd to drift you to perfection).
<cpaelzer> infinity: the default is to slew time if under 128 ms but to step it if above that
<cpaelzer> the limit can be increased with -x (to drift higher amounts of delta), but the default should be 129 ms
<cpaelzer> so, TL;DR it should set it if the delta is huge
<cpaelzer> although to admit - I haven't tested it yet to verify how right the manpage is about that
<cpaelzer> infinity: I can do so and update the bug if you want
<infinity> cpaelzer: Would be nice to have peace of mind on that.
<cpaelzer> ok, will do so
<infinity> cpaelzer: Honestly, if ntpd's first run does the job of ntpdate, I almost feel like ntpd should provide/conflict ntpdate (and provide a /usr/bin/ntpdate that one-shots ntpd if it's not running, or something clever), for the few packages that depend on ntpdate for odd reasons.
<infinity> cpaelzer: But that's not worth doing in an SRU.  Having ntpdate effectively inert is fine too.
<cpaelzer> yeah but it is a nice suggestion for the further deprecation and dropping of ntpdate
-queuebot:#ubuntu-release- Unapproved: base-files (zesty-proposed/main) [9.6ubuntu13 => 9.6ubuntu13.1] (core)
<rbasak> kirkland: ^ need SRU information in the bug please
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20170523-0ubuntu1~16.04.0 => 20170622-0ubuntu1~16.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20170523-0ubuntu1~14.04.0 => 20170622-0ubuntu1~14.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (zesty-proposed/universe) [20170523-0ubuntu1~17.04.0 => 20170622-0ubuntu1~17.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (yakkety-proposed/universe) [20170523-0ubuntu1~16.10.0 => 20170622-0ubuntu1~16.10.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (yakkety-proposed) [20170609-0ubuntu1~16.10.0]
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (zesty-proposed) [20170609-0ubuntu1~17.04.0]
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (trusty-proposed) [20170609-0ubuntu1~14.04.0]
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (xenial-proposed) [20170609-0ubuntu1~16.04.0]
<rbasak> kirkland: ^ what happens on first login? That'll still be delayed, right? So the bug is being reduced in scope, but not being fixed entirely?
<rbasak> If the first login is before the timer has run for the first time, that is, which seems likely.
<kirkland> rbasak: true
<kirkland> rbasak: that's an easy fix, though, just one more line to add
<kirkland> rbasak: would you like me to fix that?
<kirkland> I think it would be a good idea, yeah
<rbasak> kirkland: yes please. Probably better for the SRU process to do it fewer times :)
-queuebot:#ubuntu-release- Unapproved: rejected base-files [source] (zesty-proposed) [9.6ubuntu13.1]
<slashd> bdmurray, sil2100 good day, could you please have a look at 'autofs' package currently in -proposed and copy it out to -updates ? It has reached the minimum aging period, bug in green in pending sru page, verification-done-$RELEASE has been done with detailed explanation.
<sil2100> slashd: I can take a look after the meeting
<slashd> sil2100, thanks
<kirkland> rbasak: okey doke...  base-files_9.6ubuntu13.2_source.changes uploaded to zesty-proposed
<sil2100> slashd: done!
<kirkland> rbasak: this ensures that the fix happens immediately (ie, not requiring a first run to establish the empty file)
<slashd> sil2100, thanks
<kirkland> rbasak: I've updated the SRU testing/documentation in the bug description, and the embedded patch
-queuebot:#ubuntu-release- Unapproved: base-files (zesty-proposed/main) [9.6ubuntu13 => 9.6ubuntu13.2] (core)
<kirkland> rbasak: and I've reset the status to in-progress
<kirkland> rbasak: anythign else?
<rbasak> kirkland: otp, will look in a bit. FWIW, we didn't burn 9.6ubuntu13.1. Can we tidier and use that? No need to wait for a reject before uploading.
<kirkland> rbasak: yeah, you're right, those .numbers are expensive, we really don't want to run out!
<kirkland> rbasak: done
<kirkland> rbasak: uploaded base-files_9.6ubuntu13.1_source.changes
<rbasak> Thanks. I like things all ordered and tidy :-)
 * rbasak suspects this might be one reason he's in ~ubuntu-sru.
<rbasak> kirkland: do you have an artful upload with that fix? I don't see it.
<kirkland> rbasak: yep
-queuebot:#ubuntu-release- Unapproved: base-files (zesty-proposed/main) [9.6ubuntu13 => 9.6ubuntu13.1] (core)
<kirkland> rbasak: ah, hang on a sec
<kirkland> rbasak: okay, pushed to artful
-queuebot:#ubuntu-release- Unapproved: rejected base-files [source] (zesty-proposed) [9.6ubuntu13.2]
<cpaelzer> infinity: btw I got to complete the ntp tests, all worked on xenial the way it should, to the -g which is default really adresses your concern
<rbasak> kirkland: http://paste.ubuntu.com/24982581/ are lines 59 and 60 still needed?
<kirkland> rbasak: no, technically we don't
<infinity> cpaelzer: My brain couldn't parse that sentence until I finally realized 's/to the/so the/' but yay, +1
<infinity> cpaelzer: You can either record that in the bug (might be nice for people doing archaeology) or I can just hide the comments with the concerns, but either way, that's all I need to go ahead with the SRU.
-queuebot:#ubuntu-release- New binary: kcptun [s390x] (artful-proposed/universe) [20170525+ds-1] (no packageset)
<infinity> cpaelzer: Thanks for humouring me on the matter.
-queuebot:#ubuntu-release- New binary: kcptun [ppc64el] (artful-proposed/universe) [20170525+ds-1] (no packageset)
<stgraber> tseliot: how's the alpha going?
<tseliot> stgraber: wrong person?
<stgraber> yup :)
<stgraber> tsimonq2: how's the alpha going?
<stgraber> there, that's better :)
-queuebot:#ubuntu-release- New binary: golang-github-confluentinc-confluent-kafka-go [amd64] (artful-proposed/universe) [0.9.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: stressant [amd64] (artful-proposed/universe) [0.4.1] (no packageset)
-queuebot:#ubuntu-release- New binary: kcptun [amd64] (artful-proposed/universe) [20170525+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kcptun [i386] (artful-proposed/universe) [20170525+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tmuxp [amd64] (artful-proposed/universe) [1.2.6-2] (no packageset)
<tsimonq2> stgraber: Hey, sorry, I took a nap
<tsimonq2> stgraber: Lubuntu and Kubuntu aren't done yet but Ubuntu Kylin is
<tsimonq2> stgraber: Any testing help is appreciated. :)
<stgraber> tsimonq2: well, I'm off today, so not going to be around for much else than doing the final publishing :)
<stgraber> (one of those trying to stay away from computer day off, not terribly succesful so far :))
<tsimonq2> stgraber: Ok :)
-queuebot:#ubuntu-release- New binary: kcptun [arm64] (artful-proposed/universe) [20170525+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kcptun [armhf] (artful-proposed/universe) [20170525+ds-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: apport (zesty-proposed/main) [2.20.4-0ubuntu4.3 => 2.20.4-0ubuntu4.4] (core)
-queuebot:#ubuntu-release- Unapproved: apport (yakkety-proposed/main) [2.20.3-0ubuntu8.5 => 2.20.3-0ubuntu8.6] (core)
-queuebot:#ubuntu-release- Unapproved: apport (xenial-proposed/main) [2.20.1-0ubuntu2.8 => 2.20.1-0ubuntu2.9] (core)
<tsimonq2> stgraber: How long do you anticipate being awake this evening?
<tsimonq2> (3 more to go, I'm just marking the done one as ready)
<stgraber> I'll be around for another 6-7 hours I expect
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Artful Alpha 1] has been marked as ready
<tsimonq2> stgraber: Ok, I thought you were in a European time zone?
<stgraber> nope, Canada, eastern
<tsimonq2> Oh, cool.
<tsimonq2> stgraber: I'm in Wisconsin, Central TZ fwiw
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [source] (zesty-proposed) [0.8.1-3ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (zesty-proposed) [20170622-0ubuntu1~17.04.0]
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [amd64] (zesty-proposed/universe) [20170622-0ubuntu1~17.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [ppc64el] (zesty-proposed/universe) [20170622-0ubuntu1~17.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [i386] (zesty-proposed/universe) [20170622-0ubuntu1~17.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [s390x] (zesty-proposed/universe) [20170622-0ubuntu1~17.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [armhf] (zesty-proposed/universe) [20170622-0ubuntu1~17.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [arm64] (zesty-proposed/universe) [20170622-0ubuntu1~17.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (yakkety-proposed) [20170622-0ubuntu1~16.10.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (xenial-proposed) [20170622-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [s390x] (xenial-proposed/universe) [20170622-0ubuntu1~16.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [i386] (yakkety-proposed/universe) [20170622-0ubuntu1~16.10.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [ppc64el] (yakkety-proposed/universe) [20170622-0ubuntu1~16.10.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [amd64] (yakkety-proposed/universe) [20170622-0ubuntu1~16.10.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [s390x] (yakkety-proposed/universe) [20170622-0ubuntu1~16.10.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [powerpc] (yakkety-proposed/universe) [20170622-0ubuntu1~16.10.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [amd64] (xenial-proposed/universe) [20170622-0ubuntu1~16.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [ppc64el] (xenial-proposed/universe) [20170622-0ubuntu1~16.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [i386] (xenial-proposed/universe) [20170622-0ubuntu1~16.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [powerpc] (xenial-proposed/universe) [20170622-0ubuntu1~16.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [armhf] (xenial-proposed/universe) [20170622-0ubuntu1~16.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [armhf] (yakkety-proposed/universe) [20170622-0ubuntu1~16.10.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [arm64] (yakkety-proposed/universe) [20170622-0ubuntu1~16.10.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [arm64] (xenial-proposed/universe) [20170622-0ubuntu1~16.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: libprelude [ppc64el] (artful-proposed/universe) [3.1.0-0.3] (no packageset)
-queuebot:#ubuntu-release- New binary: libprelude [s390x] (artful-proposed/universe) [3.1.0-0.3] (no packageset)
-queuebot:#ubuntu-release- New binary: libprelude [amd64] (artful-proposed/universe) [3.1.0-0.3] (no packageset)
-queuebot:#ubuntu-release- New binary: libprelude [i386] (artful-proposed/universe) [3.1.0-0.3] (no packageset)
-queuebot:#ubuntu-release- New binary: libprelude [armhf] (artful-proposed/universe) [3.1.0-0.3] (no packageset)
<tsimonq2> stgraber: Apologies for the delay. I'll mark Lubuntu as ready within the next 1-2 hours.
<stgraber> ok
#ubuntu-release 2017-06-30
<tsimonq2> Alright, all of the Lubuntu *amd64* images are marked as ready. Working on i386 right now.
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Artful Alpha 1] has been marked as ready
-queuebot:#ubuntu-release- New binary: libprelude [arm64] (artful-proposed/universe) [3.1.0-0.3] (no packageset)
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [amd64] (zesty-proposed) [20170622-0ubuntu1~17.04.0]
-queuebot:#ubuntu-release- New: accepted golang-github-confluentinc-confluent-kafka-go [amd64] (artful-proposed) [0.9.4-2]
-queuebot:#ubuntu-release- New: accepted kcptun [arm64] (artful-proposed) [20170525+ds-1]
-queuebot:#ubuntu-release- New: accepted kcptun [i386] (artful-proposed) [20170525+ds-1]
-queuebot:#ubuntu-release- New: accepted kcptun [s390x] (artful-proposed) [20170525+ds-1]
-queuebot:#ubuntu-release- New: accepted libprelude [arm64] (artful-proposed) [3.1.0-0.3]
-queuebot:#ubuntu-release- New: accepted libprelude [i386] (artful-proposed) [3.1.0-0.3]
-queuebot:#ubuntu-release- New: accepted libprelude [s390x] (artful-proposed) [3.1.0-0.3]
-queuebot:#ubuntu-release- New: accepted tmuxp [amd64] (artful-proposed) [1.2.6-2]
-queuebot:#ubuntu-release- New: accepted kcptun [amd64] (artful-proposed) [20170525+ds-1]
-queuebot:#ubuntu-release- New: accepted kcptun [ppc64el] (artful-proposed) [20170525+ds-1]
-queuebot:#ubuntu-release- New: accepted libprelude [armhf] (artful-proposed) [3.1.0-0.3]
-queuebot:#ubuntu-release- New: accepted stressant [amd64] (artful-proposed) [0.4.1]
-queuebot:#ubuntu-release- New: accepted kcptun [armhf] (artful-proposed) [20170525+ds-1]
-queuebot:#ubuntu-release- New: accepted libprelude [ppc64el] (artful-proposed) [3.1.0-0.3]
-queuebot:#ubuntu-release- New: accepted libprelude [amd64] (artful-proposed) [3.1.0-0.3]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [amd64] (yakkety-proposed) [20170622-0ubuntu1~16.10.0]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [armhf] (yakkety-proposed) [20170622-0ubuntu1~16.10.0]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [powerpc] (yakkety-proposed) [20170622-0ubuntu1~16.10.0]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [s390x] (yakkety-proposed) [20170622-0ubuntu1~16.10.0]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [arm64] (yakkety-proposed) [20170622-0ubuntu1~16.10.0]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [ppc64el] (yakkety-proposed) [20170622-0ubuntu1~16.10.0]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [i386] (yakkety-proposed) [20170622-0ubuntu1~16.10.0]
<stgraber> tsimonq2: have you heard from kubuntu?
<tsimonq2> stgraber: Yep
<tsimonq2> stgraber: Been chatting in #kubuntu-council (open channel fwiw)
<tsimonq2> stgraber: Teaching valorie how to mark things as ready :P
<tsimonq2> valorie: In fact, we should do this here.
<tsimonq2> valorie: What are you clicking?
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Artful Alpha 1] has been marked as ready
<tsimonq2> Ok THERE you go :P
<valorie> ha, now I can go to dinner in good conscience
<tsimonq2> valorie: So no i386?
<valorie> not now, with no tests
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Artful Alpha 1] has been marked as ready
<valorie> if my users come through.....
<tsimonq2> valorie: Ok, if we end up publishing before then, we can always publish i386 Kubuntu later :)
<valorie> ok
<tsimonq2> valorie: Enjoy your dinner :)
<valorie> muy buen
<tsimonq2> Just a couple more Lubuntu tests and we'll be golden, stgraber
<stgraber> tsimonq2: ok
 * tsimonq2 is doing them right now
<valorie> my upgrade went like butter
<tsimonq2> \o/
<mparillo> There were no i386 kubuntu tests until a few hours ago, but I see marius-nestor has passed two (probably the two most important)
<valorie> butter on a hot piece of fresh corn
<valorie> ooooo, nice
<valorie> ok, see you in a couple of hours
<valorie> marius rocks!
<mapreri> is there a random core-dev around who can do a no-change rebuild of src:audit against libprelude23 ?
<mapreri> (otherwise tomorrow I'll seek out my usual victims :P)
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [amd64] (xenial-proposed) [20170622-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [armhf] (xenial-proposed) [20170622-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [powerpc] (xenial-proposed) [20170622-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [s390x] (xenial-proposed) [20170622-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [arm64] (xenial-proposed) [20170622-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [ppc64el] (xenial-proposed) [20170622-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [i386] (xenial-proposed) [20170622-0ubuntu1~16.04.0]
<slangasek> mapreri: random core-devs are in #ubuntu-devel; in here you're stuck with the stochastic ones
<slangasek> (done)
<mapreri> ahah :D  thanks
<tsimonq2> One more test, stgraber :)
<tsimonq2> So < 30 mins
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Artful Alpha 1] has been marked as ready
<tsimonq2> stgraber: Press buttons please? :)
<tsimonq2> stgraber: (i.e. Alpha 1 is ready to be published)
<stgraber> ok
<tsimonq2> \oi/
<tsimonq2> *\o/
<tsimonq2> stgraber: I'm forgetting, how do I know when I can publish the announcement?
<stgraber> tsimonq2: I'll tell you
<tsimonq2> stgraber: Ok, cool :)
<stgraber> oh fun, I get to fix ubuntu-archive-tools as it doesn't know about Lubuntu Next
<tsimonq2> Oh, fun.
<stgraber> ok, I think I got it
<stgraber> lets try publishing
<valorie> stgraber: evidently our i386 testers didn't step up, so we won't be publishing it
<valorie> kubuntu I mean
<stgraber> yep
<tsimonq2> stgraber: How's everything looking?
<stgraber> waiting for the source ISO to finish building
<tsimonq2> Ok, cool.
<stgraber> and we have a source iso
<tsimonq2> \o/
<tsimonq2> What now?
<tsimonq2> Looks like the images might be published?
<stgraber> trying to get the damn source image to publish
<tsimonq2> Ah ok
<stgraber> ok, after messing with the filesystem long enough, the publishing script is doing something
<tsimonq2> \o/
<tsimonq2> stgraber: Are the download pages supposed to say "Daily Build"?
<stgraber> nope
<stgraber> they won't once I'm done
<tsimonq2> Ok cool
 * tsimonq2 becomes quiet, enough poking :P
<stgraber> content is good on nusakan, pushing to mirrors now
 * tsimonq2 stands by
<tsimonq2> stgraber: ...but the page still says "Daily Build," does it not?
<stgraber> that's because it's not synced yet
<stgraber> wait until I tell you it's done :)
<tsimonq2> You're right :))
<stgraber> tsimonq2: check now
<tsimonq2> stgraber: Yep I see, all good
<tsimonq2> stgraber: Are you verifying from my end or does that mean the mirrors are good? :P
<stgraber> from what I can tell, they're all done syncing
<tsimonq2> Ok cool :)
<tsimonq2> Sending email
<stgraber> I'm marking the alpha as released on the tracker, re-enabling cron and dropping the package freeze now
<tsimonq2> \o/
<tsimonq2> stgraber: Coulg I get my message to ubuntu-devel-announce approved?
<tsimonq2> *could
<stgraber> not by me :)
<stgraber> slangasek maybe
<stgraber> or infinity
<tsimonq2> ok
<slangasek> looking
<slangasek> Subject:  The very first Christian weight loss product available for purchase
<slangasek> ^^ that's you, right?
<stgraber> :)
<tsimonq2> lol
<tsimonq2> no
<stgraber> ok, all done on my side I think, if I forgot something, please yell :)
<slangasek> freeze hint dropped?
<stgraber> yup
<valorie> onward and upward to Alpha 2!
<tsimonq2> Thanks stgraber and slangasek, have a nice night and happy release :)
<valorie> hmmm, are there torrents?
<tsimonq2> valorie: Yes there are.
 * valorie ain't finding them anywhere
<valorie> zsync, metalink, etc.
<valorie> but not torrents
<tsimonq2> valorie: areyousureaboutthat http://cdimage.ubuntu.com/kubuntu/releases/artful/alpha-1/artful-desktop-amd64.iso.torrent
<valorie> I guess I didn't reload the page
<valorie> thanks my dear
<valorie> strange, all the torrent links come through as "artful-desktop-amd64.iso.torrent" etc.
<valorie> so I can only do kubuntu
<valorie> seed, I mean
<acheronuk> valorie: make sepetare kubuntu, ubuntu, xubuntu etc directories so you can save and seed each file that way?
-queuebot:#ubuntu-release- Unapproved: intel-microcode (yakkety-proposed/restricted) [3.20160714.1 => 3.20170511.1~ubuntu16.10.0] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-124.173] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: linux-signed-hwe (xenial-proposed/main) [4.8.0-58.63~16.04.1 => 4.10.0-27.30~16.04.2] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-hwe [sync] (xenial-proposed) [4.10.0-27.30~16.04.2]
-queuebot:#ubuntu-release- Unapproved: debian-installer (xenial-proposed/main) [20101020ubuntu451.10 => 20101020ubuntu451.11] (core)
<ahoneybun> infinity: maybe you could look at this: https://code.launchpad.net/~aaronhoneycutt/ubiquity-slideshow-ubuntu/artful/+merge/326115 ?
<ahoneybun> didn't know cyphermox_ was out on vac till now so it didn't get into alpha1
<ahoneybun> also there was a new ubiquity but there is not new release yet, I have a change for our (kubuntu) installer in there
<valorie> he didn't get that SDDM bug fixed or that fix pushed, either
<valorie> oh well, it's just OEM
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-124.173]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.10.0-27.30~16.04.2] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.10.0-27.30~16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (xenial-proposed) [20101020ubuntu451.11]
-queuebot:#ubuntu-release- Unapproved: debian-installer (xenial-proposed/main) [20101020ubuntu451.11 => 20101020ubuntu451.12] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (xenial-proposed) [20101020ubuntu451.12]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-59.64] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-59.64]
-queuebot:#ubuntu-release- New binary: asn1crypto [amd64] (artful-proposed/universe) [0.22.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-84.107~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-84.107] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-84.107~14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-84.107]
<mapreri> is there a way to trick some SRU guy into processing the debootstrap SRUs? :)
-queuebot:#ubuntu-release- Unapproved: rejected debootstrap [source] (zesty-proposed) [1.0.81ubuntu3.2]
<apw> ^ duplicate upload in the queue ...
<mapreri> mh
<mapreri> fancy ^^
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (zesty-proposed) [1.0.81ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (yakkety-proposed) [1.0.81ubuntu2.3]
<apw> mapreri, only back to xenial?
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (xenial-proposed) [1.0.78+nmu1ubuntu1.4]
<mapreri> apw: well, I went only that far as that's what I was interested it.  Surely adding one for trusty ain't hard if you feel like I should
<apw> mapreri, it would be nice for everything to be in sync me thinks
<alan_g> Is there someone around that can Ack ticket 2806 please?
<mapreri> apw: can you sponsor the upload if I prepare it now?
<apw> mapreri, sure
<apw> alan_g, ack ticket ?
<mapreri> trusty's debootstrap also misses stretch u.U
<alan_g> apw: ack the packaging changes & publish
<mapreri> apw: http://debomatic-amd64.debian.net/debomatic/trusty/pool/debootstrap_1.0.59ubuntu0.8/debootstrap_1.0.59ubuntu0.8_sourceupload.changes - Also please approve the trusty nomination on the bug (LP #1698686).
<ubot5> Launchpad bug 1698686 in debootstrap (Ubuntu Zesty) "debootstrap: learn about Debian buster" [Medium,Fix committed] https://launchpad.net/bugs/1698686
<mapreri> and I see the script added the 'verification-needed' tag, what should I do with that one?
<apw> mapreri, rather than the *-<series>-* ones ?
<mapreri> yeah
<mapreri> I mean, do I have to turn that into verification-done too, ignore it, ??
<apw> mapreri, good question ^^ bdmurray i think you know what the plan was with that
<mapreri> besides, probably the verification-$series-$status tags should be "registered" in lp as well, so they are suggested, etc.
-queuebot:#ubuntu-release- Unapproved: debootstrap (trusty-proposed/main) [1.0.59ubuntu0.7 => 1.0.59ubuntu0.8] (core)
<jbicha> mapreri: I'll add those tags
<mapreri> jbicha: ?
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (trusty-proposed) [1.0.59ubuntu0.8]
<apw> mapreri, ^ ok that is all of them in and building ... thank you
<mapreri> yay, thanks :)
<jbicha> mapreri: I updated the official bug tags
<mapreri> ah, cool
<mapreri> apw, bdmurray: typo in the automated message, there is a missing space:
<mapreri> change the tag from verification-needed-xenial to verification-done-xenial.If it does not fix
<bdmurray> mapreri, apw: The verification-needed tag is still added so there can be one tag to search for which will show all verification-needed bugs across all series.
<apw> bdmurray, that makes sense, is that going to be programatically removed when all the *-needed-* are gone ?
<bdmurray> This way the SRU verification team, if it becomes active, can find a pool of work.
<bdmurray> apw: I guess that'd make sense.
<apw> bdmurray, yeah it makes sense, and sense if we would scan for and kill them when not needed
<bdmurray> apw: Can you add that missing space? I'd have to submit an MP etc...
<bdmurray> apw: It's about line 355.
<apw> bdmurray, yep
<apw> bdmurray, fixed
-queuebot:#ubuntu-release- Unapproved: freeipmi (xenial-proposed/main) [1.4.11-1.1ubuntu3~0.16.04 => 1.4.11-1.1ubuntu4~0.16.04] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: freeipmi (zesty-proposed/main) [1.4.11-1.1ubuntu3 => 1.4.11-1.1ubuntu4~0.17.04] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: freeipmi (yakkety-proposed/main) [1.4.11-1.1ubuntu3~0.16.10 => 1.4.11-1.1ubuntu4~0.16.10] (ubuntu-desktop, ubuntu-server)
<alan_g> Is there someone around that can ack the packaging changes & publish ticket 2806 please?
<apw> alan_g, can you confirm nothing is using all these packages you are dropping
<apw> alan_g, also do you know you have lost an upload from slangasek, i assume it was a noop but you should check
<slangasek> apw: my mir upload was a no-change rebuild
<apw> slangasek, so i guess that is just changelog lossage ... alan_g so just the dropped packages
<alan_g> apw: confirmed
<slangasek> right, and I /think/ bileto is smart enough to not give you an error about dropping a no-change rebuild
<slangasek> but will refuse to let you clobber the distro bits otherwise
<didrocks> ci-train was able to do that, as bileto started from it, I think that feature sticked around
<apw> alan_g, ok ... clicked
<alan_g> thanks
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (zesty-proposed) [9.6ubuntu13.1]
<bdmurray> slangasek: Can you review my apport SRU uploads for XYZ?
<slangasek> bdmurray: yes
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (zesty-proposed) [2.20.4-0ubuntu4.4]
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (yakkety-proposed) [2.20.3-0ubuntu8.6]
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (xenial-proposed) [2.20.1-0ubuntu2.9]
<bdmurray> apw: Did you push your change to launchpad?
-queuebot:#ubuntu-release- Unapproved: accepted maas [source] (zesty-proposed) [2.2.0+bzr6054-0ubuntu2~17.04.1]
#ubuntu-release 2017-07-01
<apw> bdmurray, seems that tree has a strange push destination ... sigh, pushed now
<LocutusOfBorg> doko, I'm not sure about freetype merge, do you want to try it?
<acheronuk> could some please add 'force-badtest kdepim-addons/all/s390x' ?
<acheronuk> that can never pass now, as the test & build deps are unsatisfiable now on s390x, due to QtWebEngine dependant parts of KDE PIM not being buildable now on s390x
 * acheronuk looks at 3 'nows' on on sentence
<acheronuk> urgh
<acheronuk> in fact, that never passed, even when it was buildable! so old and new reason so badtest that on s390x
<slangasek> acheronuk: hint added; however, it is unclear to me why this kdepim-addons/s390x test was triggered, given that kdepim-addons produces no binaries on s390x, so that's probably a bug.  (I did have a hint for kdepim-addons/s390x in place already, and then I dropped it once things migrated
<slangasek> )
<acheronuk> slangasek: thanks. that puzzled me, but thought maybe I misunderstood how that worked
#ubuntu-release 2017-07-02
-queuebot:#ubuntu-release- New binary: fortune-zh [amd64] (artful-proposed/universe) [2.4] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-html2text [amd64] (artful-proposed/none) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-po-to-json [amd64] (artful-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-tool [amd64] (artful-proposed/none) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-omniauth-oauth2-generic [amd64] (artful-proposed/none) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-string-direction [amd64] (artful-proposed/none) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-validates-hostname [amd64] (artful-proposed/none) [1.0.7-1] (no packageset)
#ubuntu-release 2018-06-25
-queuebot:#ubuntu-release- New binary: nwchem [s390x] (cosmic-proposed/universe) [6.8+47+gitdf6c956-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nwchem [ppc64el] (cosmic-proposed/universe) [6.8+47+gitdf6c956-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nwchem [armhf] (cosmic-proposed/universe) [6.8+47+gitdf6c956-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nwchem [arm64] (cosmic-proposed/universe) [6.8+47+gitdf6c956-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nwchem [amd64] (cosmic-proposed/universe) [6.8+47+gitdf6c956-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted cnvkit [amd64] (cosmic-proposed) [0.9.3-2]
-queuebot:#ubuntu-release- New: accepted kore [arm64] (cosmic-proposed) [2.0.0-3]
-queuebot:#ubuntu-release- New: accepted kore [i386] (cosmic-proposed) [2.0.0-3]
-queuebot:#ubuntu-release- New: accepted kore [s390x] (cosmic-proposed) [2.0.0-3]
-queuebot:#ubuntu-release- New: accepted kore [arm64] (cosmic-proposed) [2.0.0-4]
-queuebot:#ubuntu-release- New: accepted kore [i386] (cosmic-proposed) [2.0.0-4]
-queuebot:#ubuntu-release- New: accepted kore [s390x] (cosmic-proposed) [2.0.0-4]
-queuebot:#ubuntu-release- New: accepted nwchem [arm64] (cosmic-proposed) [6.8+47+gitdf6c956-2]
-queuebot:#ubuntu-release- New: accepted nwchem [ppc64el] (cosmic-proposed) [6.8+47+gitdf6c956-2]
-queuebot:#ubuntu-release- New: accepted kore [amd64] (cosmic-proposed) [2.0.0-3]
-queuebot:#ubuntu-release- New: accepted kore [ppc64el] (cosmic-proposed) [2.0.0-3]
-queuebot:#ubuntu-release- New: accepted kore [armhf] (cosmic-proposed) [2.0.0-4]
-queuebot:#ubuntu-release- New: accepted nwchem [amd64] (cosmic-proposed) [6.8+47+gitdf6c956-2]
-queuebot:#ubuntu-release- New: accepted nwchem [s390x] (cosmic-proposed) [6.8+47+gitdf6c956-2]
-queuebot:#ubuntu-release- New: accepted kore [armhf] (cosmic-proposed) [2.0.0-3]
-queuebot:#ubuntu-release- New: accepted kore [ppc64el] (cosmic-proposed) [2.0.0-4]
-queuebot:#ubuntu-release- New: accepted kore [amd64] (cosmic-proposed) [2.0.0-4]
-queuebot:#ubuntu-release- New: accepted nwchem [armhf] (cosmic-proposed) [6.8+47+gitdf6c956-2]
-queuebot:#ubuntu-release- New: rejected qemu-ovmf-secureboot [source] (cosmic-proposed) [1.1.2-0ubuntu1]
<jibel> hi, builds of desktop ISO are still failing (bionic and cosmic) could someone have a look?
<jibel> sil2100, infinity ^^
<sil2100> jibel: hey! ACK, noted, I'll take a look after my SRU duties
<jibel> sil2100, thanks. The rootfs builds fine but it's the creation of the iso that fails.
<Trevinho> sil2100: could be added to the CI ppa team so that I can trigger rebuilds per arch?
-queuebot:#ubuntu-release- New source: haskell-derive (cosmic-proposed/primary) [2.6.3-3~build1]
<sil2100> Trevinho: ok
<sil2100> Trevinho: done - remember, this is great power so use it wisely!
<Trevinho> sil2100: sure, thanks
<Laney> coreutils (Accepted) # muhahaha
<Trevinho> sil2100: I'm won't touch much more than that
<LocutusOfBorg> please some AA accept haskell-derive? I manually uploaded it on ubuntu to speed up haskell rebuilds
<LocutusOfBorg> I didn't notice slangasek removed it in the meantime...
<cjwatson> .
-queuebot:#ubuntu-release- New: accepted haskell-derive [source] (cosmic-proposed) [2.6.3-3~build1]
-queuebot:#ubuntu-release- New binary: ceilometer [amd64] (cosmic-proposed/main) [1:10.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: networking-l2gw [amd64] (cosmic-proposed/universe) [1:13.0.0~a1~git2018062108.5517dc2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-derive [i386] (cosmic-proposed/none) [2.6.3-3~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-derive [ppc64el] (cosmic-proposed/universe) [2.6.3-3~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-derive [s390x] (cosmic-proposed/universe) [2.6.3-3~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-derive [amd64] (cosmic-proposed/universe) [2.6.3-3~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-derive [arm64] (cosmic-proposed/universe) [2.6.3-3~build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ceilometer [amd64] (cosmic-proposed) [1:10.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted networking-l2gw [amd64] (cosmic-proposed) [1:13.0.0~a1~git2018062108.5517dc2-0ubuntu1]
-queuebot:#ubuntu-release- New binary: haskell-derive [armhf] (cosmic-proposed/universe) [2.6.3-3~build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-derive [amd64] (cosmic-proposed) [2.6.3-3~build1]
-queuebot:#ubuntu-release- New: accepted haskell-derive [armhf] (cosmic-proposed) [2.6.3-3~build1]
-queuebot:#ubuntu-release- New: accepted haskell-derive [ppc64el] (cosmic-proposed) [2.6.3-3~build1]
-queuebot:#ubuntu-release- New: accepted haskell-derive [arm64] (cosmic-proposed) [2.6.3-3~build1]
-queuebot:#ubuntu-release- New: accepted haskell-derive [s390x] (cosmic-proposed) [2.6.3-3~build1]
-queuebot:#ubuntu-release- New: accepted haskell-derive [i386] (cosmic-proposed) [2.6.3-3~build1]
<sil2100> jibel: ok, I see it's because of the initrd
<sil2100> I'll try to fix that when I'm back home
<LocutusOfBorg> ta
<LocutusOfBorg> do we have some autopkgtestsuite armhf outage?
-queuebot:#ubuntu-release- New binary: networking-odl [amd64] (cosmic-proposed/universe) [1:13.0.0~b2-0ubuntu2] (no packageset)
<LocutusOfBorg> any AA, please kick haskell-conduit-combinators out? it has been removed in Debian already, and if my reverse-deps script is not failing, it should have no reverse-deps
<Laney> LocutusOfBorg: yes, caused by you
<Laney> the systemd in cosmic-proposed seems bad
<Laney> https://paste.ubuntu.com/p/mDMbnHVM8h/
<LocutusOfBorg> sigh
<Laney> I killed all the all-proposed jobs
<Laney> xnox: did you see that resolved thing?
<Laney> I don't know why it only started now
<xnox> Laney, no
<xnox> Laney, which one?
<Laney> see that pastebin ^
<Laney> it just started breaking on autopkgtest armhf for some reason
<Laney> can't have been the first time it ran there though
<xnox> Laney, huh, this was supposed to be fixed long time ago.... unless i backed out my patch, but upstream patch was not in yet
<LocutusOfBorg> I need -proposed for openmpi... :/ lets do the manual thing
<xnox> Laney, so yes, keyring setup stuff used to fail in containers... but it shouldn't any more.... for a while now.... looks like a regression
<xnox> Laney, yeah, patch is missing.
<xnox> systemd is bad =(
<Laney> :'(
<Laney> how did the armhf runs for systemd itself not break this though?
<Laney> LocutusOfBorg: good news that you found a bug :P
<xnox> Laney, i *cough* doubt it tests starting units as non-root.... and check that they actually are started. or like it didn't re-exec systemd whilst doing such a test....
<xnox> Laney, but, point taken, that it should have been caught.
<Laney> well it should have broken in the same way that these ones did?
<Laney> like install systemd, restart, download some stuff which is broken
<Laney> unless none of the tests install anything else
<Laney> so we don't test dns after rebooting into the new systemd
<xnox> maybe, the test that would have cought this is marked isolation-machine =/
<xnox> cause there is a test that checks that all systemd daemons are started and work fine
<Laney> a resolved smoke test would have got it I guess
<sil2100> hmmm
<sil2100> apw: hey! Maybe you'll have a better idea: we're seeing cosmic images not building correctly since the 15th of June - the reason for that is that the livefs build seems to generate an invalid empty-ish initrd
<sil2100> apw: and I saw that between the 14th and 15th the new kernel 4.15.0-23.25 appeared
<sil2100> apw: I'm seeing this in the livefs build logs since .23: "gzip: chroot/boot/initrd.img-4.15.0-23-generic: not in gzip format"
<infinity> sil2100: That's because of microcode.
<sil2100> apw: do you know where to look for more clues? Is this really some kernel thing or am I barking at the wrong tree?
<infinity> sil2100: Well, microcode-prepended initrd, combined with live-build trying to naively recompress.
<infinity> sil2100: I'll look at fixing that this afternoon.  I had a card for it, but didn't realise people were going to go and break things before I fixed them.
<sil2100> infinity: ah, ok ;) Thanks!
<infinity> sil2100: Err, which image are you seeing fail?
<infinity> Desktop seems to be building.
<sil2100> infinity: desktop, server, everything I guess
<sil2100> infinity: http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/cosmic/daily-live-20180625.log
<Laney> see cd-build-logs
<sil2100> There's an "ERROR WHILE BUILDING OFFICIAL IMAGES !!" while trying to lzcat the initrd
<infinity> Oh lolz.
<infinity> Okay, so debian-cd needs fixing too.
<infinity> Excellent.
<sil2100> At least because of cosmic images not building no one was angry at me not releasing the fix for ubiquity to make EFI systems bootable again
<sil2100> phew
<infinity> sil2100: Your first complaint was about livefs logs, though.  Which image was that?
<infinity> So I can open a browser tab with evidence for later.
<sil2100> infinity: well, since the 15th I noticed that livefs has an error when handling the initrd:
<sil2100> https://launchpadlibrarian.net/375866214/buildlog_ubuntu_cosmic_amd64_ubuntu_BUILDING.txt.gz <- if you search for "gzip: chroot/boot/initrd" you'll see it
<sil2100> infinity: I noticed it since it looks like the initrd that livefs spits out is only like 23 bytes long
<infinity> sil2100: Ahh, but non-fatal (which is a bug in a bug).  You'd implied that was causing the a failure.
<sil2100> Well, I assumed it is causing the error, or is like a symptom of the error
<sil2100> By 'the error' I meant the final images not being created
<sil2100> Non-fatal inded
<infinity> sil2100: But yes, what's happening is we build a nice, big, fat initrd, then naively pipe it through gunzip, capture the "output" of that (which is exactly 0 bytes on stdout), pipe that back to gzip, and congrats, you have an empty initrd.
<infinity> Give or take.
<infinity> The debian-cd bug is related, but differently fun.
<infinity> I'll poke both after I've done doctory things today.
<sil2100> geh!
<infinity> The simple fix for live-build is to stop recompressing the *&!!^& initrd and instead make the compression switch twiddly chroot/etc/initramfs-tools/thinger to set what we asked for.
<infinity> The fix for debian-cd probably involves being a bit more clever about the extraction it's looking for, or determining that it really doesn't need to be doing that in the first place.
<xnox> Laney, trying to merge v239 for cosmic now; it has all the right keyring bits....
<Laney> xnox: Sweet, I love higher numbers
<xnox> Laney, as long as they are not epochs ð
-queuebot:#ubuntu-release- Unapproved: nux (xenial-proposed/main) [4.0.8+16.04.20180613.1-0ubuntu1 => 4.0.8+16.04.20180622.2-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: xorg (xenial-proposed/main) [1:7.7+13ubuntu3 => 1:7.7+13ubuntu3.1] (core, xorg) (sync)
-queuebot:#ubuntu-release- Unapproved: nux (artful-proposed/universe) [4.0.8+17.10.20180613.3-0ubuntu1 => 4.0.8+17.10.20180623-0ubuntu1] (ubuntukylin) (sync)
-queuebot:#ubuntu-release- Unapproved: nux (bionic-proposed/universe) [4.0.8+18.04.20180613.5-0ubuntu1 => 4.0.8+18.04.20180622.2-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: xorg (artful-proposed/main) [1:7.7+19ubuntu3 => 1:7.7+19ubuntu3.1] (core, xorg) (sync)
-queuebot:#ubuntu-release- Unapproved: xorg (bionic-proposed/main) [1:7.7+19ubuntu7 => 1:7.7+19ubuntu7.1] (core, xorg) (sync)
<LocutusOfBorg> xnox, be careful if you merge 239... debian #902185 :)
<ubot5> Debian bug 902185 in udev "udev: fails to configure with systemd 238-5" [Serious,Open] http://bugs.debian.org/902185
<LocutusOfBorg> and also #902287
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (bionic-proposed) [1:3.28.1-0ubuntu1.18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted ibm-java80 [source] (xenial-proposed) [8.0.5.16-0ubuntu1]
<xnox> LocutusOfBorg, i know... if that was the only problem however....
-queuebot:#ubuntu-release- New: accepted libocxl [ppc64el] (bionic-proposed) [1.0.0-1~ubuntu18.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted broadcom-sta [source] (xenial-proposed) [6.30.223.271-3~16.04.3]
<xnox> Laney, so new systemd ftbfs for me, due to failing tests in dhcp client =/
<xnox> Laney, i'll check if i can ressurect the keyring stuff alone and upload v238 with keyring regression refixed again
<Laney> xnox: alrighty
<Laney> xnox: if you can fix the flaky i386 tests too that'd be good :P
-queuebot:#ubuntu-release- Unapproved: linux-firmware (xenial-proposed/main) [1.157.19 => 1.157.20] (core, kernel)
<xnox> Laney, is that like in the anecdote - "what color unicorn do you want?"
<xnox> Laney, https://some.ly/eMcgVIf/
<gaughen> Laney, always pick glitter as your unicorn color.
<Laney> gaughen wins
<Laney> I imagine xnox could decorate up a very pretty unicorn
 * Laney rides it into the next plenary
<xnox> Laney, i'm sure self-identifying as a unicorn knight is a thing.
 * xnox ponders if i broke my host.... v238 rebuilds also fail to rebuild now.
<gaughen> Laney, xnox would just put it in a onesie and be done.
<doko> remaining blocking autopkg tests for numpy: scipy and skimage
<ginggs> doko: skimage nearly there, debian #901377
<ubot5> Debian bug 901377 in src:skimage "skimage: FTBFS and Debci failure with NumPy 1.14" [Serious,Open] http://bugs.debian.org/901377
<ginggs> doko: scipy been FTBFS for a while, debian #896635
<ubot5> Debian bug 896635 in src:python-scipy "FTBFS with sphinx 1.7.2: exception: cannot import name 'Directive'" [Serious,Open] http://bugs.debian.org/896635
-queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [0.6.5.6-0ubuntu23 => 0.6.5.6-0ubuntu24] (no packageset)
<doko> ginggs: I'd ignore the scipy one for now, it's the docs only
<doko> and for skimage: "I think it doesn't matter because we still have a month until AUTORM"
-queuebot:#ubuntu-release- New binary: xfconf [ppc64el] (cosmic-proposed/universe) [4.13.4-1] (lubuntu, xubuntu)
-queuebot:#ubuntu-release- New binary: xfconf [s390x] (cosmic-proposed/universe) [4.13.4-1] (lubuntu, xubuntu)
-queuebot:#ubuntu-release- New binary: xfconf [i386] (cosmic-proposed/universe) [4.13.4-1] (lubuntu, xubuntu)
-queuebot:#ubuntu-release- New binary: xfconf [armhf] (cosmic-proposed/universe) [4.13.4-1] (lubuntu, xubuntu)
-queuebot:#ubuntu-release- New binary: xfconf [arm64] (cosmic-proposed/universe) [4.13.4-1] (lubuntu, xubuntu)
-queuebot:#ubuntu-release- New binary: xfconf [amd64] (cosmic-proposed/universe) [4.13.4-1] (lubuntu, xubuntu)
<Ukikie> Holding off the rebuilds until that gets accepted.
<ginggs> doko: yaroslav came along after that
<doko> let's hope for the upload ...
-queuebot:#ubuntu-release- New: accepted xfconf [amd64] (cosmic-proposed) [4.13.4-1]
-queuebot:#ubuntu-release- New: accepted xfconf [arm64] (cosmic-proposed) [4.13.4-1]
-queuebot:#ubuntu-release- New: accepted xfconf [armhf] (cosmic-proposed) [4.13.4-1]
-queuebot:#ubuntu-release- New: accepted xfconf [ppc64el] (cosmic-proposed) [4.13.4-1]
-queuebot:#ubuntu-release- New: accepted xfconf [i386] (cosmic-proposed) [4.13.4-1]
-queuebot:#ubuntu-release- New: accepted xfconf [s390x] (cosmic-proposed) [4.13.4-1]
-queuebot:#ubuntu-release- New: accepted radare2 [amd64] (cosmic-proposed) [2.6.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [armhf] (cosmic-proposed) [2.6.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [s390x] (cosmic-proposed) [2.6.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [arm64] (cosmic-proposed) [2.6.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted radare2 [ppc64el] (cosmic-proposed) [2.6.0+dfsg-1]
<doko> whoever accepted radare2 ... please fix the i386 build
<slangasek> doko: I accepted it, but why does that mean I should prioritize fixing this particular build?
<slangasek> ah, it starts a lib transition
<slangasek> ok, I'll have a look - but I don't think leaving things sitting in binary NEW is a particularly clear way of signalling that it needs work
<slangasek> oh, it's a library transition of a library with no revdeps ;)
<doko> looks like your lucky day ;-P
#ubuntu-release 2018-06-26
<Ukikie> Sorry for spamming the buildds, but figured "after hours" would be the best time.
-queuebot:#ubuntu-release- Unapproved: apt (bionic-proposed/main) [1.6.1 => 1.6.2] (core)
<LocutusOfBorg> slangasek, FYI I blame wrt radare2 this line 	buffer = r_str_replace (buffer, "get_pc_thunk.bx", "__getesp__", true);
<LocutusOfBorg> and this script http://launchpadlibrarian.net/374995584/radare2_2.4.0+dfsg-1_2.6.0+dfsg-1.diff.gz
<LocutusOfBorg> sed -e s,rdata,text, -e s,rodata,text, -e 's,get_pc_thunk.bx,__getesp__,g'
<LocutusOfBorg> but no, I don't want to fix it :) (and now my eyes are bleeding)
-queuebot:#ubuntu-release- New binary: thunar [s390x] (cosmic-proposed/universe) [1.8.1-0ubuntu1] (mythbuntu, xubuntu)
-queuebot:#ubuntu-release- New binary: thunar [ppc64el] (cosmic-proposed/universe) [1.8.1-0ubuntu1] (mythbuntu, xubuntu)
-queuebot:#ubuntu-release- New binary: thunar [amd64] (cosmic-proposed/universe) [1.8.1-0ubuntu1] (mythbuntu, xubuntu)
-queuebot:#ubuntu-release- New binary: thunar [i386] (cosmic-proposed/universe) [1.8.1-0ubuntu1] (mythbuntu, xubuntu)
-queuebot:#ubuntu-release- New binary: thunar [armhf] (cosmic-proposed/universe) [1.8.1-0ubuntu1] (mythbuntu, xubuntu)
-queuebot:#ubuntu-release- New binary: thunar [arm64] (cosmic-proposed/universe) [1.8.1-0ubuntu1] (mythbuntu, xubuntu)
-queuebot:#ubuntu-release- New: accepted networking-odl [amd64] (cosmic-proposed) [1:13.0.0~b2-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted thunar [arm64] (cosmic-proposed) [1.8.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted thunar [i386] (cosmic-proposed) [1.8.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted thunar [s390x] (cosmic-proposed) [1.8.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted thunar [amd64] (cosmic-proposed) [1.8.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted thunar [ppc64el] (cosmic-proposed) [1.8.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted thunar [armhf] (cosmic-proposed) [1.8.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: apt (artful-proposed/main) [1.5.1 => 1.5.2] (core)
-queuebot:#ubuntu-release- Unapproved: apt (xenial-proposed/main) [1.2.26 => 1.2.27] (core)
<xnox> Laney, new systemd is in; should have keyring stuff working; monitoring autopkgtests....
<Laney> xnox: thanks dear
-queuebot:#ubuntu-release- New binary: networking-bgpvpn [amd64] (cosmic-proposed/universe) [9.0.0~b2-0ubuntu3] (no packageset)
<ginggs> would someone please kick the octave-ltfat can along? 'force-badtest octave-ltfat/2.3.0+dfsg.1-1/arm64 octave-ltfat/2.3.0+dfsg.1-1/armhf' in ubuntu-release hints
<ginggs> and sextractor too 'force-badtest sextractor/2.19.5+dfsg-6/amd64' in vorlon hints
-queuebot:#ubuntu-release- Unapproved: gnome-shell (bionic-proposed/main) [3.28.1-0ubuntu2 => 3.28.2-0ubuntu0.18.04.1] (desktop-extra, mozilla, ubuntu-desktop)
<slangasek> ginggs: done for both
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.1-1ubuntu1 => 3.28.2-2~ubuntu18.04.1] (desktop-extra, ubuntu-desktop)
<sil2100> infinity: hey! Did you manage to get the cosmic images fixed re: microcode?
<ginggs> slangasek: thanks!
-queuebot:#ubuntu-release- Unapproved: aodh (bionic-proposed/main) [6.0.0-0ubuntu1 => 6.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cinder (bionic-proposed/main) [2:12.0.1-0ubuntu1 => 2:12.0.3-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: aptly [s390x] (cosmic-proposed/universe) [1.3.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: aptly [amd64] (cosmic-proposed/universe) [1.3.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: play.it [amd64] (cosmic-proposed/multiverse) [2.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: aptly [arm64] (cosmic-proposed/universe) [1.3.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: aptly [ppc64el] (cosmic-proposed/universe) [1.3.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: aptly [i386] (cosmic-proposed/universe) [1.3.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: python-furl [amd64] (cosmic-proposed/universe) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: aptly [armhf] (cosmic-proposed/universe) [1.3.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: pynac [s390x] (cosmic-proposed/universe) [0.7.19-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pynac [i386] (cosmic-proposed/universe) [0.7.19-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pynac [ppc64el] (cosmic-proposed/universe) [0.7.19-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pynac [amd64] (cosmic-proposed/universe) [0.7.19-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: neutron (bionic-proposed/main) [2:12.0.2-0ubuntu1 => 2:12.0.3-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: pynac [arm64] (cosmic-proposed/universe) [0.7.19-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pynac [armhf] (cosmic-proposed/universe) [0.7.19-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted aptly [amd64] (cosmic-proposed) [1.3.0-4]
-queuebot:#ubuntu-release- New: accepted aptly [armhf] (cosmic-proposed) [1.3.0-4]
-queuebot:#ubuntu-release- New: accepted aptly [ppc64el] (cosmic-proposed) [1.3.0-4]
-queuebot:#ubuntu-release- New: accepted play.it [amd64] (cosmic-proposed) [2.9.0-1]
-queuebot:#ubuntu-release- New: accepted pynac [arm64] (cosmic-proposed) [0.7.19-2]
-queuebot:#ubuntu-release- New: accepted pynac [i386] (cosmic-proposed) [0.7.19-2]
-queuebot:#ubuntu-release- New: accepted pynac [s390x] (cosmic-proposed) [0.7.19-2]
-queuebot:#ubuntu-release- New: accepted aptly [arm64] (cosmic-proposed) [1.3.0-4]
-queuebot:#ubuntu-release- New: accepted aptly [s390x] (cosmic-proposed) [1.3.0-4]
-queuebot:#ubuntu-release- New: accepted pynac [armhf] (cosmic-proposed) [0.7.19-2]
-queuebot:#ubuntu-release- New: accepted aptly [i386] (cosmic-proposed) [1.3.0-4]
-queuebot:#ubuntu-release- New: accepted pynac [ppc64el] (cosmic-proposed) [0.7.19-2]
-queuebot:#ubuntu-release- New: accepted pynac [amd64] (cosmic-proposed) [0.7.19-2]
-queuebot:#ubuntu-release- New: accepted python-furl [amd64] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- Unapproved: ceilometer (bionic-proposed/main) [1:10.0.0-0ubuntu1 => 1:10.0.1-0ubuntu0.18.04.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (bionic-proposed/main) [2:17.0.4-0ubuntu1 => 2:17.0.5-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: horizon (bionic-proposed/main) [3:13.0.0-0ubuntu1.1 => 3:13.0.1-0ubuntu1] (openstack, ubuntu-server)
<infinity> sil2100: Nope, I ended up stuck in waiting rooms a lot longer than anticipated.  Will tackle shortly.
<sil2100> infinity: thanks!
-queuebot:#ubuntu-release- New binary: haskell-bindings-uname [s390x] (cosmic-proposed/none) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-servant-client-core [s390x] (cosmic-proposed/none) [0.13.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bindings-uname [amd64] (cosmic-proposed/none) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bindings-uname [i386] (cosmic-proposed/none) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-servant-client-core [amd64] (cosmic-proposed/none) [0.13.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-servant-client-core [i386] (cosmic-proposed/none) [0.13.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bindings-uname [ppc64el] (cosmic-proposed/none) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-servant-client-core [ppc64el] (cosmic-proposed/none) [0.13.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bindings-uname [arm64] (cosmic-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-servant-client-core [arm64] (cosmic-proposed/universe) [0.13.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-bindings-uname [armhf] (cosmic-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-servant-client-core [armhf] (cosmic-proposed/universe) [0.13.0.1-1] (no packageset)
#ubuntu-release 2018-06-27
<LocutusOfBorg> please accept haskell-servant-client-core and haskell-bindings-uname from binnew queue!
<LocutusOfBorg> thanks!
-queuebot:#ubuntu-release- New: accepted haskell-servant-client-core [amd64] (cosmic-proposed) [0.13.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-servant-client-core [armhf] (cosmic-proposed) [0.13.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-servant-client-core [ppc64el] (cosmic-proposed) [0.13.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-servant-client-core [arm64] (cosmic-proposed) [0.13.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-servant-client-core [s390x] (cosmic-proposed) [0.13.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-servant-client-core [i386] (cosmic-proposed) [0.13.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-bindings-uname [amd64] (cosmic-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-bindings-uname [armhf] (cosmic-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-bindings-uname [ppc64el] (cosmic-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-bindings-uname [arm64] (cosmic-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-bindings-uname [s390x] (cosmic-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-bindings-uname [i386] (cosmic-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted networking-bgpvpn [amd64] (cosmic-proposed) [9.0.0~b2-0ubuntu3]
<LocutusOfBorg> ta
<LocutusOfBorg> thanks!
<infinity> sil2100: cosmic builds look happy now, will need to SRU for bionic and xenial.
<sil2100> infinity: \o/ thanks!
<infinity> sil2100: I'll prep those both for you before I wander off.
 * sil2100 goes off to see if his bootability-fixes work
<infinity> sil2100: We'll want to fasttrack them to unbreak point release prep.
<sil2100> infinity: sure, makes sense, I can review/accept them if needed
<infinity> Oh, hrm, I bet xenial also needs d-i cherry-picks for the kernel new world order.
<infinity> Whee.
<infinity> Well, one bug at time.
-queuebot:#ubuntu-release- Unapproved: update-notifier (bionic-proposed/main) [3.192.1.1 => 3.192.1.2] (ubuntu-desktop, ubuntu-server)
<LocutusOfBorg> if you don't want xorg-server to migrate, speak now, I think it will go in a run or two
<LocutusOfBorg> oh noes, maybe not now
<LocutusOfBorg> tjaalton, what do you plan to do for the missing -hwe xorg packages rebuilds?
<LocutusOfBorg> now xorg-server is candidate
<tjaalton> LocutusOfBorg: no rebuilds necessary
<tjaalton> LocutusOfBorg: wait, which release?
<LocutusOfBorg> Trying easy from autohinter: virtualbox/5.2.12-dfsg-3 virtualbox-hwe/5.2.12-dfsg-3ubuntu18.10.1 xorg-server/2:1.20.0-2ubuntu1 xserver-xorg-video-amdgpu/18.0.1-1build1 xserver-xorg-video-dummy/1:0.3.8-1build3 xserver-xorg-video-fbdev/1:0.5.0-1 xserver-xorg-video-geode/2.11.19-4 xserver-xorg-video-intel/2:2.99.917+git20171229-1build1 xserver-xorg-video-nouveau/1:1.0.15-3 xserver-xorg-video-openchrome/1:0.6.0-3build1
<LocutusOfBorg> xserver-xorg-video-qxl/0.1.5-2build2 xserver-xorg-video-vesa/1:2.3.4-1build4 xserver-xorg-video-vmware/1:13.3.0-2build1
<LocutusOfBorg>     * amd64: xmir-hwe-16.04, xorgxrdp, xserver-xorg-video-all, xserver-xorg-video-all-hwe-16.04, xserver-xorg-video-ast, xserver-xorg-video-ati, xserver-xorg-video-ati-dbg, xserver-xorg-video-ati-hwe-16.04, xserver-xorg-video-ati-hwe-16.04-dbg, xserver-xorg-video-mach64, xserver-xorg-video-mach64-dbg, xserver-xorg-video-mach64-hwe-16.04, xserver-xorg-video-mach64-hwe-16.04-dbg, xserver-xorg-video-neomagic, xserver-xorg-video-
<LocutusOfBorg> neomagic-hwe-16.04, xserver-xorg-video-r128, xserver-xorg-video-r128-dbg, xserver-xorg-video-r128-hwe-16.04, xserver-xorg-video-r128-hwe-16.04-dbg, xserver-xorg-video-radeon, xserver-xorg-video-radeon-dbg, xserver-xorg-video-radeon-hwe-16.04, xserver-xorg-video-radeon-hwe-16.04-dbg, xserver-xorg-video-savage, xserver-xorg-video-savage-hwe-16.04, xserver-xorg-video-siliconmotion, xserver-xorg-video-siliconmotion-hwe-16.04,
<LocutusOfBorg> xserver-xorg-video-sisusb, xserver-xorg-video-sisusb-hwe-16.04, xserver-xorg-video-tdfx, xserver-xorg-video-tdfx-hwe-16.04, xserver-xorg-video-trident, xserver-xorg-video-trident-hwe-16.04
<LocutusOfBorg> tjaalton, ^^ cosmic
<tjaalton> cosmic doesn't need nor should have -hwe-16.04
<LocutusOfBorg> so, somebody should ask to remove the package? :)
<tjaalton> so dunno what that is. nvidia-340 needs an update, it won't migrate before that happens
<LocutusOfBorg> nvidia-340 is updated already I would say
<LocutusOfBorg> I requested a new test
<LocutusOfBorg> xorg-server/2:1.20.0-2ubuntu1	2018-06-27 08:40:31 UTC	0h 04m 05s	costamagnagianfranco	pass
<tjaalton> no, it needs the latest upstream version
<LocutusOfBorg> but looking at update_output, it won't migrate even if candidate
-queuebot:#ubuntu-release- Unapproved: live-build (xenial-proposed/main) [3.0~a57-1ubuntu25.5 => 3.0~a57-1ubuntu25.6] (desktop-core)
<LocutusOfBorg> tjaalton, you sure? it is updated now
<LocutusOfBorg> since a week
<infinity> LocutusOfBorg: What missing hwe packages?
-queuebot:#ubuntu-release- Unapproved: live-build (bionic-proposed/main) [3.0~a57-1ubuntu34 => 3.0~a57-1ubuntu34.1] (desktop-core)
<tjaalton> oh ok
<LocutusOfBorg> infinity, I'm looking at the "notest" file https://people.canonical.com/~ubuntu-archive/proposed-migration/cosmic/
<tjaalton> infinity: xorg-lts-transitional should be removed from cosmic
<LocutusOfBorg> so, all of them should go away or be installable I would say
<infinity> Yes indeed it should.
<LocutusOfBorg> and with that, xorg can migrate
<tjaalton> actually there's a bug where I requested a bunch of video drivers to be removed
<infinity> tjaalton: Actually, to be fair, it shouldn't be removed, it should be updated to build hwe-18.04 stuff, probably.
<infinity> tjaalton: Not that hwe-18.04 stuff exists yet, but it will soon.
<tjaalton> okay
<LocutusOfBorg> so, still no magic today?
<infinity> C, D, E, and F should have an xorg-lts-transitional that provides hwe-18.04 for smooth upgrades from point releases of B.
<infinity> And then G starts all over with 20.04
<infinity> Unless I have an off-by-one there, but you know what I mean.
<infinity> No, that's right.
<tjaalton> y, z, a didn't have it
<infinity> Y, Z, A were buggy then. :P
<tjaalton> right :)
<infinity> Plus this is just easier than removing and reintroducing it every 2 years.
<infinity> And makes the upgrades testable along the way.
<tjaalton> sure
<tjaalton> I'll fix that
<infinity> Ta.
<tjaalton> someone *cough* should poke bug 1772588
<ubot5> bug 1772588 in xserver-xorg-video-trident (Ubuntu) "Remove obsolete X11 drivers from the archive" [Undecided,New] https://launchpad.net/bugs/1772588
<infinity> BUT MY TRIDENT CARD.
<tjaalton> I'll check status on geonde
<tjaalton> *geode
<infinity> Or is trident now in some generic kernel driver umbrella?
<tjaalton> it's a lot more than trident
<infinity> Oh wow.
<infinity> It sure is.
<infinity> All the input drivers?
<infinity> Don't we like to type and point at stuff?
<infinity> Ahh, maybe I should read the bug.
<tjaalton> not all of them, -libinput is used by default, -evdev and -synaptics are for backup. -wacom is also left as is
<infinity> I may have to digest this bug when I'm more awake to make sure I don't eff it up.
<infinity> Looks like it could use careful processing and review.
<tjaalton> sure
<infinity> I'm not convinced "no KMS support" is a good enough reason to drop a driver.
<infinity> If we're locally maintaining them because upstream is dead and no one is tracking server changes, that would be valid.
<tjaalton> fedora dropped them 5y ago
<tjaalton> they'll use fb/vesa as fallback
<infinity> If Fedora shipped a release called Beefy Miracle, would you do it too?
<infinity> Fedora pretty notoriously cares nothing about users who aren't their developer base.
<infinity> So, "Fedora did it" is not compelling.
<tjaalton> it's not like these would have any sort of hw accel anyway
<infinity> I know the trident one was actually pretty speedy for 2D drawing.
<infinity> Granted, who has 2D desktops anymore.
<infinity> So maybe that makes it moot.
<infinity> Anyhow, I'll mull it over tomorrow.
<tjaalton> and I'll fix the hwe pkg
<infinity> "The Geode LX is an i686 without PAE. It is still supported by the Linux kernel."
<infinity> And we dropped support for non-pae ages ago.
<infinity> So that answers that one.
<tjaalton> ahh, good
<infinity> (I mean, technically our userspace works fine with non-pae, but we don't ship any kernels that boot on it, and we don't "support" people installing with custom kernels, so...)
<infinity> That way may also lie compelling arguments for some of the really really old drivers.
<infinity> Like, the last trident card I had was VLB... And ISA before that.
<infinity> And anyone with an x86 system we support better be PCI or better.
<tjaalton> I think there were some thinkpads from 15y ago with a trident.. I have a T23 with a savage
<tjaalton> haven't booted it in years
<infinity> Oh right, Savage was a thing that happened.
<infinity> I was a riva128 early adopter, everyone other than nvidia and ATI/AMD has been dead to me since.
<infinity> Once you have working/fast OpenGL, it's hard to go back.
<infinity> Anyhow, I'm swaying myself.
<infinity> I think the only "old" driver we need to make sure to hang on to is matrox, cause SuperMicro STILL PUTS THEM ON SERVER BOARDS (even if I think people who run X on servers have a screw loose)
<infinity> And the Matrox stuff was actually kept current and KMSy, right?
<tjaalton> it's in the kernel yes
<infinity> sil2100: There are live-builds in the xenial and bionic queues, BTW.
<tjaalton> infinity: meaning it'll use xserver built-in modesetting driver on X
<infinity> tjaalton: Right, that sounds like a thing I knew at one time.
<tjaalton> the separate -mga driver was removed earlier
<infinity> I think I did that removal after you explained the above. :P
<infinity> It all sounds very familiar.
<tjaalton> heh, could be
<LocutusOfBorg> "I was a riva128 early adopter, everyone other than nvidia and ATI/AMD has been dead to me since." <-- me too <3 lovely card
<infinity> LocutusOfBorg: Strange to think they were the little underdog newcomer when we bought those, and now they're the behemoth throwing around monopolistic weight.
<infinity> Also, reminder to past self: buy nvidia stock in 1996.
-queuebot:#ubuntu-release- New binary: linbox [s390x] (cosmic-proposed/universe) [1.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linbox [ppc64el] (cosmic-proposed/universe) [1.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linbox [i386] (cosmic-proposed/universe) [1.5.2-1] (no packageset)
<LocutusOfBorg> linbox has only sagemath as reverse-dependency and sagemath is dep-waiting on it
-queuebot:#ubuntu-release- New binary: linbox [amd64] (cosmic-proposed/universe) [1.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linbox [armhf] (cosmic-proposed/universe) [1.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linbox [arm64] (cosmic-proposed/universe) [1.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linbox [amd64] (cosmic-proposed) [1.5.2-1]
-queuebot:#ubuntu-release- New: accepted linbox [armhf] (cosmic-proposed) [1.5.2-1]
-queuebot:#ubuntu-release- New: accepted linbox [ppc64el] (cosmic-proposed) [1.5.2-1]
-queuebot:#ubuntu-release- New: accepted linbox [arm64] (cosmic-proposed) [1.5.2-1]
-queuebot:#ubuntu-release- New: accepted linbox [s390x] (cosmic-proposed) [1.5.2-1]
-queuebot:#ubuntu-release- New: accepted linbox [i386] (cosmic-proposed) [1.5.2-1]
<xnox> Laney, i wonder if systemd broke things or armhf-runners had changes. it appears that autopkgtests no longer have XDG_SESSION_ID= set, on armhf.
<xnox> Laney, also there is another crash in unittests on armhf to investigate, otherwise it is the only regression left =(
<Laney> xnox: no changes from me
<xnox> Laney, ack. thanks.
<Laney> xnox: not really sure how this worked before to be honest
<Laney> we just use lxc exec I think
<xnox> hm...
-queuebot:#ubuntu-release- New binary: opencascade [s390x] (cosmic-proposed/universe) [7.3.0+dfsg1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: opencascade [i386] (cosmic-proposed/universe) [7.3.0+dfsg1-3] (no packageset)
<Laney> xnox: but it does seem to pass/fail with the old/new version
<Laney> you can make this happen locally
<Laney> autopkgtest --apt-upgrade --test-name logind --apt-pocket=proposed=src:systemd systemd --shell-fail -- lxd --debug autopkgtest/ubuntu/cosmic/amd64
<Laney> and remove the proposed bit
<Laney> brb
<xnox> Laney, yeah, thanks. will dig more into it. there have been changes in pam/logind stuff
-queuebot:#ubuntu-release- New binary: opencascade [ppc64el] (cosmic-proposed/universe) [7.3.0+dfsg1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: opencascade [amd64] (cosmic-proposed/universe) [7.3.0+dfsg1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: opencascade [armhf] (cosmic-proposed/universe) [7.3.0+dfsg1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: opencascade [arm64] (cosmic-proposed/universe) [7.3.0+dfsg1-3] (no packageset)
<LocutusOfBorg> any AA around to help haskell migrate?
<LocutusOfBorg> we are sooooooooooooooo close
<LocutusOfBorg> just few bits
<LocutusOfBorg> 1) remove agda on armhf (same issue in Debian, RC bug open) 2) kick haskell-conduit-combinators	(removed in Debian already) ghc-mod, gitit, all RC buggy
<LocutusOfBorg> 3) wait for dinstall, 4) enjoy
-queuebot:#ubuntu-release- New source: finalrd (cosmic-proposed/primary) [2]
<doko> LocutusOfBorg: does this mean that the armhf and s390x issues are fixed?
<LocutusOfBorg> yes
<LocutusOfBorg> did anybody kill autopkgtests?
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (xenial-proposed) [1.2.27]
<doko> LocutusOfBorg: removed agda. haskell-conduit-combinators still has rdeps
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (artful-proposed) [1.5.2]
-queuebot:#ubuntu-release- Unapproved: accepted apt [source] (bionic-proposed) [1.6.2]
<doko> removed ghc-mod and gitit as well
<doko> haskell-conduit-combinators is only removed in unstable, not testing
<doko> python-numpy migrated. hmm, no opemnpi dependencies?
<doko> LocutusOfBorg: did you have a look at the autopkg tests triggered by cmake?
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.1 => 237-3ubuntu10.2] (core)
-queuebot:#ubuntu-release- Unapproved: python2.7 (bionic-proposed/main) [2.7.15~rc1-1 => 2.7.15-0ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (bionic-proposed) [237-3ubuntu10.2]
-queuebot:#ubuntu-release- Unapproved: python2.7 (bionic-proposed/main) [2.7.15~rc1-1 => 2.7.15-0ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: rejected python2.7 [source] (bionic-proposed) [2.7.15-0ubuntu1]
<LocutusOfBorg> doko, not on top of my list, they need upstream patches
<LocutusOfBorg> on top now I have haskell migration
<LocutusOfBorg> and I don't get that conduit-combinators issue
<doko> it's the reverse build-depends
<LocutusOfBorg> it has no rdeps in unstable, and this is what makes it go in testing, unless something weird is going on
<doko> $ reverse-depends -b src:haskell-conduit-combinators
<doko> Reverse-Build-Depends-Indep
<doko> ===========================
<doko> * haskell-classy-prelude-conduit  (for libghc-conduit-combinators-doc)
<doko> * haskell-gitlib                (for libghc-conduit-combinators-doc)
<doko> Reverse-Build-Depends
<doko> =====================
<doko> * haskell-classy-prelude-conduit  (for libghc-conduit-combinators-prof)
<doko> * haskell-classy-prelude-conduit  (for libghc-conduit-combinators-dev)
<doko> * haskell-cryptonite-conduit    (for libghc-conduit-combinators-dev)
<doko> * haskell-gitlib                (for libghc-conduit-combinators-dev)
<doko> * haskell-gitlib                (for libghc-conduit-combinators-prof)
<LocutusOfBorg> yes, but they don't use it anymore
<LocutusOfBorg> in -proposed
<LocutusOfBorg> ./debian/changelog:  * Patch for no conduit-combinators.
<LocutusOfBorg> as I say, in proposed, nothing uses it anymore, and once haskell migrates, we should be fine
<doko> but removing these makes things uninstallable ...
<doko> slangasek: can these be forced in?
<LocutusOfBorg> what? uninstallable in release? and they become installable again once haskell migrates
<LocutusOfBorg> I don't get the point
<LocutusOfBorg> they should I would say :)
<LocutusOfBorg> otherwise how can haskell migrate?
<LocutusOfBorg> proposed pocket is ok to migrate
<LocutusOfBorg> (haskell-store-core is fixed now, waiting a publisher run)
<doko>     * amd64: libghc-conduit-combinators-dev, libghc-conduit-combinators-doc, libghc-conduit-combinators-prof, libghc-store-core-dev, libghc-store-core-doc, libghc-store-core-prof, libghc-store-dev, libghc-store-doc, libghc-store-prof
<doko>     * arm64: libghc-conduit-combinators-dev, libghc-conduit-combinators-prof, libghc-store-core-dev, libghc-store-core-prof, libghc-store-dev, libghc-store-prof
<LocutusOfBorg> store-core is fine
<doko> I can't hint these ...
<LocutusOfBorg> combinator has to go
<LocutusOfBorg> why? conduitcombinators is the one we are talking about
<LocutusOfBorg> remove conduit-combinators, wait publisher, profit
<slangasek> "remove" - is this a Debian removal?
<doko> slangasek: it's removed in unstable, kept in testing
<slangasek> doko: ok; so you are going to remove it?
<LocutusOfBorg> slangasek, yes, of course
<LocutusOfBorg> the package is now removed in unstable only, and will automagically remove from testing once haskell migrates
<LocutusOfBorg> reason is that it has no rdeps anymore in unstable
<LocutusOfBorg> same happens to cosmic
<ginggs> what prevents openmpi from migrating?
<LocutusOfBorg> gdal e.g. with vtk6
<ginggs> LocutusOfBorg: ta
<LocutusOfBorg> but gdal is mostly ready, at least candidate
<LocutusOfBorg> removing vtk6 from release for some days might make things better
<ginggs> removing it permanently might make things even better :)
<LocutusOfBorg> lol
<LocutusOfBorg> unfortunately britney is not smart enough to tell me if vtk6 is the only entangled package, but it should be
<LocutusOfBorg> so, removing it should make it go
<ginggs> oh osmcoastline
<LocutusOfBorg> already retried
<LocutusOfBorg> slangasek, ^^ can you do the vtk6 magic?
<doko> slangasek: sure, I can. but it doesn't feel like a clean way ...
<doko> done
<LocutusOfBorg> vtk6 will migrate with proj and gdal...
<LocutusOfBorg> hurray for haskell! <3
<LocutusOfBorg> doko, it is a clean way, just britney isn't smarter enough to understand that the breakage of the archive is not possible, because the migration makes it consistent again
<LocutusOfBorg> this happens with haskell, almost every transition we do (major)
 * LocutusOfBorg braces for impact!
<doko> well, gdal isn't ready
<LocutusOfBorg> gdal is candidate in a matter of minutes
<doko> and everything is ready with perl?
<LocutusOfBorg> doko, don't forget to remove haskell-conduit-combinators from -proposed pocket
<LocutusOfBorg> perl is candidate, once haskell is gone, I can look at it
<LocutusOfBorg> we need to break openmpi vs other 10 transitions to see what is missing
<doko> openmpi is ready
<LocutusOfBorg> or wait for stuff being candidate
<LocutusOfBorg> gdal is not ready yet, so I don't see what is missing
<LocutusOfBorg> mariadb is blocking
<LocutusOfBorg> we need to fix those:
<LocutusOfBorg>     * amd64: circlator, fheroes2-pkg, freefem++, ghemical, gridengine-client, gridengine-dev, gridengine-drmaa-dev, gridengine-drmaa1.0, gridengine-exec, gridengine-master, gridengine-qmon, groonga, groonga-bin, groonga-examples, groonga-httpd, groonga-munin-plugins, groonga-normalizer-mysql, groonga-plugin-suggest, groonga-server-common, groonga-server-gqtp, groonga-token-filter-stem, groonga-tokenizer-mecab,
<LocutusOfBorg> libdeal.ii-9.0.0, libdeal.ii-dev, libdrmaa1.0-java, libdrmaa1.0-ruby, libghemical-dev, libghemical5v5, libgroonga-dev, libgroonga0, librheolef-dev, librheolef1, libxdmf-dev, libxdmf3, mariadb-client, mariadb-client-10.1, mariadb-plugin-connect, mariadb-plugin-cracklib-password-check, mariadb-plugin-gssapi-client, mariadb-plugin-gssapi-server, mariadb-plugin-mroonga, mariadb-plugin-oqgraph, mariadb-plugin-spider,
<LocutusOfBorg> mariadb-plugin-tokudb, mariadb-server, mariadb-server-10.1, mariadb-server-core-10.1, python-xdmf, python3-xdmf, rapmap, rheolef, salmon, spades, toulbar2, varnish, varnish-modules
 * cyphermox facepalms; the haskell-cmark-gfm was so simple, doh
<doko> how did you get this list?
<LocutusOfBorg> update_output_notest.txt
<ginggs> hmm, freefem++ and libghemical appear in debian's transition tracker, but not ours https://release.debian.org/transitions/html/auto-openmpi.html vs https://people.canonical.com/~ubuntu-archive/transitions/html/openmpi3.html
<ginggs> same with rheolef
<ginggs> we have deal.ii, and it was uploaded after the transition started
<doko> the debian tracker includes the -dev package
<doko> and rheolef still depends on libopenmpi2. not sure why that's not catched
<doko> same for the others
<doko> probably because the library packages are missing in the affected lie
<doko> line
<ginggs> doko: i'll copy over from debian's config
<doko> ok
<doko> do you upload the tree packages too?
<doko> three
<ginggs> i can
<doko> muahhh, perl 5.28 transition on the horizon ...
<ginggs> i plan to wait for the tracker to update, then upload what is missing - unless there is more urgency?
<doko> well, we already know these three packages
<slangasek> LocutusOfBorg: sorry, what magic were you looking for on vtk6?
<ginggs> slangasek: locutus wanted temporary removal of vtk6 to allow openmpi to migrate
<ginggs> openmpi3 tracker updated: freefem++ rheolef xdmf and libghemical outstanding - i'll upload xdmf now
<ginggs> so xdmf has no direct Build-Depends on libopenmpi-dev, probably indirect through libhdf5-mpi-dev
<LocutusOfBorg> slangasek, please kick haskell-conduit-combinators out from proposed too, thanks
<LocutusOfBorg> removed in debian, and now with haskell migrated it makes no sense to keep it
<slangasek> LocutusOfBorg: quite, no reason to leave a ftbfs build4 package in -proposed only
<slangasek> ginggs, LocutusOfBorg: vtk6 has reverse-dependencies in cosmic, so... how was that supposed to work?
-queuebot:#ubuntu-release- Unapproved: ebtables (bionic-proposed/main) [2.0.10.4-3.5ubuntu2.18.04.1 => 2.0.10.4-3.5ubuntu2.18.04.2] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- New binary: libskk [s390x] (cosmic-proposed/universe) [1.0.3-1] (input-methods)
-queuebot:#ubuntu-release- New binary: libtorrent [s390x] (cosmic-proposed/universe) [0.13.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libskk [amd64] (cosmic-proposed/universe) [1.0.3-1] (input-methods)
-queuebot:#ubuntu-release- New binary: veusz [s390x] (cosmic-proposed/universe) [3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libskk [i386] (cosmic-proposed/universe) [1.0.3-1] (input-methods)
-queuebot:#ubuntu-release- New binary: ros-common-msgs [amd64] (cosmic-proposed/universe) [1.12.6-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libskk [ppc64el] (cosmic-proposed/universe) [1.0.3-1] (input-methods)
-queuebot:#ubuntu-release- New binary: xmlsec1 [amd64] (cosmic-proposed/main) [1.2.26-3] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: veusz [amd64] (cosmic-proposed/universe) [3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtorrent [ppc64el] (cosmic-proposed/universe) [0.13.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: veusz [i386] (cosmic-proposed/universe) [3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireshark [s390x] (cosmic-proposed/universe) [2.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtorrent [amd64] (cosmic-proposed/universe) [0.13.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtorrent [i386] (cosmic-proposed/universe) [0.13.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireshark [amd64] (cosmic-proposed/universe) [2.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireshark [ppc64el] (cosmic-proposed/universe) [2.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libskk [arm64] (cosmic-proposed/universe) [1.0.3-1] (input-methods)
-queuebot:#ubuntu-release- New binary: libskk [armhf] (cosmic-proposed/universe) [1.0.3-1] (input-methods)
-queuebot:#ubuntu-release- New binary: libtorrent [arm64] (cosmic-proposed/universe) [0.13.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtorrent [armhf] (cosmic-proposed/universe) [0.13.7-1] (no packageset)
#ubuntu-release 2018-06-28
-queuebot:#ubuntu-release- New binary: wireshark [i386] (cosmic-proposed/universe) [2.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireshark [armhf] (cosmic-proposed/universe) [2.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireshark [arm64] (cosmic-proposed/universe) [2.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmath-gsl-perl [s390x] (cosmic-proposed/universe) [0.39-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libmath-gsl-perl [amd64] (cosmic-proposed/universe) [0.39-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libmath-gsl-perl [ppc64el] (cosmic-proposed/universe) [0.39-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libmath-gsl-perl [i386] (cosmic-proposed/universe) [0.39-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libmath-gsl-perl [arm64] (cosmic-proposed/universe) [0.39-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libmath-gsl-perl [armhf] (cosmic-proposed/universe) [0.39-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [amd64] (cosmic-proposed) [0.39-2]
-queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [armhf] (cosmic-proposed) [0.39-2]
-queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [ppc64el] (cosmic-proposed) [0.39-2]
-queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [arm64] (cosmic-proposed) [0.39-2]
-queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [s390x] (cosmic-proposed) [0.39-2]
-queuebot:#ubuntu-release- New: accepted libmath-gsl-perl [i386] (cosmic-proposed) [0.39-2]
-queuebot:#ubuntu-release- New: accepted wireshark [amd64] (cosmic-proposed) [2.6.1-1]
-queuebot:#ubuntu-release- New: accepted wireshark [armhf] (cosmic-proposed) [2.6.1-1]
-queuebot:#ubuntu-release- New: accepted wireshark [ppc64el] (cosmic-proposed) [2.6.1-1]
-queuebot:#ubuntu-release- New: accepted wireshark [arm64] (cosmic-proposed) [2.6.1-1]
-queuebot:#ubuntu-release- New: accepted wireshark [s390x] (cosmic-proposed) [2.6.1-1]
-queuebot:#ubuntu-release- New: accepted wireshark [i386] (cosmic-proposed) [2.6.1-1]
-queuebot:#ubuntu-release- New: accepted opencascade [amd64] (cosmic-proposed) [7.3.0+dfsg1-3]
-queuebot:#ubuntu-release- New: accepted opencascade [armhf] (cosmic-proposed) [7.3.0+dfsg1-3]
-queuebot:#ubuntu-release- New: accepted opencascade [ppc64el] (cosmic-proposed) [7.3.0+dfsg1-3]
-queuebot:#ubuntu-release- New: accepted opencascade [arm64] (cosmic-proposed) [7.3.0+dfsg1-3]
-queuebot:#ubuntu-release- New: accepted opencascade [s390x] (cosmic-proposed) [7.3.0+dfsg1-3]
-queuebot:#ubuntu-release- New: accepted opencascade [i386] (cosmic-proposed) [7.3.0+dfsg1-3]
-queuebot:#ubuntu-release- New: accepted libtorrent [amd64] (cosmic-proposed) [0.13.7-1]
-queuebot:#ubuntu-release- New: accepted libtorrent [armhf] (cosmic-proposed) [0.13.7-1]
-queuebot:#ubuntu-release- New: accepted libtorrent [ppc64el] (cosmic-proposed) [0.13.7-1]
-queuebot:#ubuntu-release- New: accepted xmlsec1 [amd64] (cosmic-proposed) [1.2.26-3]
-queuebot:#ubuntu-release- New: accepted libtorrent [arm64] (cosmic-proposed) [0.13.7-1]
-queuebot:#ubuntu-release- New: accepted libtorrent [s390x] (cosmic-proposed) [0.13.7-1]
-queuebot:#ubuntu-release- New: accepted libtorrent [i386] (cosmic-proposed) [0.13.7-1]
-queuebot:#ubuntu-release- New: accepted ros-common-msgs [amd64] (cosmic-proposed) [1.12.6-3]
-queuebot:#ubuntu-release- New: accepted libskk [amd64] (cosmic-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted libskk [armhf] (cosmic-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted libskk [ppc64el] (cosmic-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted libskk [arm64] (cosmic-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted libskk [s390x] (cosmic-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted libskk [i386] (cosmic-proposed) [1.0.3-1]
<sil2100> eh, daily cosmic image failed to build
<Laney> it SURE did!
 * sil2100 was looking forward to it
<jibel> sil2100, https://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<jibel> sil2100, also bug 1779068
<ubot5> bug 1779068 in grub-installer (Ubuntu) "installation of cosmic 20180627.1 fails on removal of grub-pc-bin" [Critical,New] https://launchpad.net/bugs/1779068
<sil2100> jibel: yeah, that one's fixed now
<sil2100> jibel: that's why I was looking forward to the new image
<jibel> it's with ubuntu10 which should keep grub-pc-bin
<sil2100> jibel: yeah, but it was not enough
<sil2100> jibel: ubuntu11 is needed
<jibel> k
<Laney> Please to fix those perl component-mismatches
<Laney> There's some "rule" where they don't need MIRs
<Laney> (don't ask me for a reference)
<sil2100> I guess would be nice for someone from the MIR team to take a look
<sil2100> doko: ^
<Laney> not needed, but as you wish
<sil2100> I don't know the rules for this so if there's anyone else that knows those and can promote them, sure!
<doko> hmm, somebody demoted those three days ago, not sure why ...
<doko> promoted again
<sil2100> doko: thanks!
 * sil2100 will kick a new cosmic build in a bit
-queuebot:#ubuntu-release- Unapproved: cockpit (bionic-backports/universe) [170-1~ubuntu18.04.1 => 171-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (bionic-backports) [171-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [170-1~ubuntu16.04.1 => 171-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [171-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: ebtables (xenial-proposed/main) [2.0.10.4-3.4ubuntu2.16.04.1 => 2.0.10.4-3.4ubuntu2.16.04.2] (ubuntu-server)
-queuebot:#ubuntu-release- New: accepted veusz [amd64] (cosmic-proposed) [3.0-1]
-queuebot:#ubuntu-release- New: accepted veusz [s390x] (cosmic-proposed) [3.0-1]
-queuebot:#ubuntu-release- New: accepted veusz [i386] (cosmic-proposed) [3.0-1]
<LocutusOfBorg> jamespage, I'm going to fix python-taskflow to work with python-networkx 2.0
<LocutusOfBorg> there is a patch upstream...
-queuebot:#ubuntu-release- Unapproved: ebtables (artful-proposed/main) [2.0.10.4-3.5ubuntu2.17.10.1 => 2.0.10.4-3.5ubuntu2.17.10.2] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted python3-defaults [source] (bionic-proposed) [3.6.5-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python3-defaults [source] (artful-proposed) [3.6.3-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: partman-auto (bionic-proposed/main) [134ubuntu8 => 134ubuntu8.1] (core)
-queuebot:#ubuntu-release- Unapproved: partman-efi (bionic-proposed/main) [71ubuntu2 => 71ubuntu2.1] (core)
-queuebot:#ubuntu-release- Unapproved: grub-installer (bionic-proposed/main) [1.128ubuntu8 => 1.128ubuntu8.18.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8 => 2.02-2ubuntu8.1] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (bionic-proposed/main) [1.93 => 1.93.1] (core)
-queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.34.9.1 => 1.34.9.2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted ebtables [source] (bionic-proposed) [2.0.10.4-3.5ubuntu2.18.04.2]
<blackboxsw> sil2100: or bdmurray we've had a cloud-init SRU queued for a while that hasn't progressed to pending it's targeted to Xenial, Artful, Bionic.
<blackboxsw> it's affiliated with the following SRU bug https://bugs.launchpad.net/bugs/1777912
<ubot5> Ubuntu bug 1777912 in cloud-init (Ubuntu) "sru cloud-init (18.2-4-g05926e48-0ubuntu1) to (18.3-0ubuntu1)" [Undecided,New]
<blackboxsw> if there is time it'd be great to queue that
<blackboxsw> or rather, get it into proposed so I can start validation work
-queuebot:#ubuntu-release- Unapproved: accepted ebtables [source] (artful-proposed) [2.0.10.4-3.5ubuntu2.17.10.2]
<sil2100> blackboxsw: I guess that would have to be bdmurray, since I'm too tired now so I'll be probably EODing soon
<blackboxsw> sil2100: +1 yeah I figured looking at timestamps of backlog :)
<blackboxsw> take car
<blackboxsw> e
<bdmurray> blackboxsw: I've got a tab open
<blackboxsw> excellent good sir
-queuebot:#ubuntu-release- Unapproved: rejected ebtables [source] (xenial-proposed) [2.0.10.4-3.4ubuntu2.16.04.2]
<bdmurray> blackboxsw: bug 1770712 is missing a test case / SRU information but I won't block on it
<ubot5> bug 1770712 in cloud-init (Ubuntu Bionic) "It would be nice if cloud-init provides full version in logs" [Medium,Confirmed] https://launchpad.net/bugs/1770712
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (bionic-proposed) [18.3-0ubuntu1~18.04.1]
<bdmurray> slangasek: Could you review / merge https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/time-to-release/+merge/348100?
-queuebot:#ubuntu-release- Unapproved: ebtables (artful-proposed/main) [2.0.10.4-3.5ubuntu2.17.10.2 => 2.0.10.4-3.5ubuntu2.17.10.3] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ebtables (bionic-proposed/main) [2.0.10.4-3.5ubuntu2.18.04.2 => 2.0.10.4-3.5ubuntu2.18.04.3] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ebtables (xenial-proposed/main) [2.0.10.4-3.4ubuntu2.16.04.1 => 2.0.10.4-3.4ubuntu2.16.04.2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (artful-proposed) [18.3-0ubuntu1~17.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [18.3-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted ebtables [source] (bionic-proposed) [2.0.10.4-3.5ubuntu2.18.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted ebtables [source] (artful-proposed) [2.0.10.4-3.5ubuntu2.17.10.3]
-queuebot:#ubuntu-release- Unapproved: accepted ebtables [source] (xenial-proposed) [2.0.10.4-3.4ubuntu2.16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (bionic-proposed) [3.28.2-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (bionic-proposed) [3.28.2-2~ubuntu18.04.1]
<bdmurray> coreycb: Where is aodh 6.0.1 for cosmic?
<coreycb> bdmurray: that would be good, wouldn't it. i'll get that up soon.
<bdmurray> coreycb: are the other uploads squared away?
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (bionic-proposed) [3.192.1.2]
<coreycb> bdmurray: yes they're good
<bdmurray> coreycb: okay
<coreycb> bdmurray: i've just uplaoded aodh 6.0.1-0ubuntu2 to cosmic
<bdmurray> infinity: can you some SRU stuff to bug 1778811?
<ubot5> bug 1778811 in live-build (Ubuntu) "live-build doesn't work with multi-part initrds" [Undecided,Fix released] https://launchpad.net/bugs/1778811
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (bionic-proposed) [3:13.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (bionic-proposed) [2:17.0.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ceilometer [source] (bionic-proposed) [1:10.0.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (bionic-proposed) [2:12.0.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ostree (bionic-proposed/universe) [2018.4-2 => 2018.6-0ubuntu0.1] (ubuntugnome)
<infinity> bdmurray: If you can verb your sentences.
<infinity> bdmurray: (I'll fix up the bug later, not that it's a big deal given that the only person who's going to verify it is the uploader, who usually self-accepts CD build system stuff. :P)
<bdmurray> infinity: its like a madlib
<infinity> bdmurray: Been awake since yesterday, but I'll get you paperwork tonight.
<infinity> Not all here right now.
<infinity> Not really even half here.
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (bionic-proposed) [2:12.0.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted grub-installer [source] (bionic-proposed) [1.128ubuntu8.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (bionic-proposed) [1.34.9.2]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (bionic-proposed) [1.93.1]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (bionic-proposed) [2.02-2ubuntu8.1]
-queuebot:#ubuntu-release- Unapproved: accepted partman-auto [source] (bionic-proposed) [134ubuntu8.1]
-queuebot:#ubuntu-release- Unapproved: accepted partman-efi [source] (bionic-proposed) [71ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8 => 2.02-2ubuntu8.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted libjsyntaxpane-java [source] (bionic-proposed) [0.9.6~r156-6ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (xenial-proposed) [0.6.5.6-0ubuntu24]
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.1 => 2.02-2ubuntu8.1] (core)
#ubuntu-release 2018-06-29
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.14.2 => 18.04.14.3] (core)
<ginggs> would someone please 'force bad-test r-cran-curl/3.2-2build1/ppc64el r-cran-curl/3.2-2build1/s390x' ?  the flakiness spread from arm64 in vorlon's hints - but at least we now have a debian bug #902628
<ubot5> Debian bug 902628 in src:curl "curl: segfaults with http2 on libcurl 7.60.0" [Normal,Open] http://bugs.debian.org/902628
<sil2100> ginggs: on it in a minute
<ginggs> sil2100: ta!
<sil2100> ginggs: done now, yw!
<sil2100> bdmurray, slangasek: hey! I uploaded a new ubiquity to the bionic Unapproved queue which pulls in all the new d-i packages that have been pushed to -proposed
<sil2100> bdmurray, slangasek: could one of you review/approve that one once you have a moment?
<Laney> 9 more armhf runners online to help with the backlog there
-queuebot:#ubuntu-release- Unapproved: update-manager (bionic-proposed/main) [1:18.04.11.2 => 1:18.04.11.3] (core)
<bdmurray> sil2100: I'm out today
<sil2100> bdmurray: ok, thank
<sil2100> *thanks
-queuebot:#ubuntu-release- Unapproved: lxc (xenial-backports/main) [2.0.8-0ubuntu1~16.04.2 => 3.0.1-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- New source: lxc-templates (xenial-backports/primary) [3.0.0-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: lxcfs (xenial-backports/main) [2.0.8-0ubuntu1~16.04.2 => 3.0.1-0ubuntu2~16.04.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-backports/main) [2.21-0ubuntu3~16.04.2 => 3.0.1-0ubuntu1~16.04.1] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- New source: python3-lxc (xenial-backports/primary) [3.0.1-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (xenial-backports) [3.0.1-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (xenial-backports) [3.0.1-0ubuntu2~16.04.1]
-queuebot:#ubuntu-release- New: accepted lxc-templates [source] (xenial-backports) [3.0.0-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted python3-lxc [source] (xenial-backports) [3.0.1-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New binary: lxc [s390x] (xenial-backports/main) [3.0.1-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: lxc [amd64] (xenial-backports/main) [3.0.1-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: lxc [powerpc] (xenial-backports/main) [3.0.1-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- New: accepted lxc [amd64] (xenial-backports) [3.0.1-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted lxc [s390x] (xenial-backports) [3.0.1-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted lxc [powerpc] (xenial-backports) [3.0.1-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New binary: lxc [ppc64el] (xenial-backports/main) [3.0.1-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- New: accepted lxc [ppc64el] (xenial-backports) [3.0.1-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-backports) [3.0.1-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (xenial-proposed) [1.157.20]
<slangasek> ginggs, sil2100: fwiw it was not my understanding that the new r-cran-curl crashes were related to the original testing-only crash that I had previously hinted
<ginggs> slangasek: it definitely appeared flaky to me, and unrelated to the r-base upload
<ginggs> and it failed in release on at least one of the architectures
<slangasek> sil2100: ubiquity accepted; I would've been ok with you self-accepting since there are no changes aside from the udeb imports
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (bionic-proposed) [18.04.14.3]
<slangasek> ginggs: what I see in the history is that r-cran-curl/3.2-2/ppc64el started to fail its tests with new r-base which was only accepted into release because of the above hinting
<slangasek> so I don't think that was proper to hint as "flaky", but it's done now so it's correct for the hint to stay in place
<ginggs> it passed and failed on amd64 and arm64 against r-base in -proposed, and the upstream bug is "occasional segfaults"
<ahasenack> is the build farm overloaded, specifically the arm builders?
<ahasenack> apache2 has been running tests for more than 24h
<ahasenack> 756 packages in the cosmic arm queue, ok
<ahasenack> what does "huge" mean in the first column of the "queue lengths" tables? http://autopkgtest.ubuntu.com/running
<ahasenack> it's either ubuntu, huge, ppa, or upstream
<infinity> ahasenack: "huge" is a queue for packages that trigger a massive amount of rdep tests (like perl and glibc)
<ahasenack> ah
<infinity> ahasenack: So when a perl upload happens, the whole world doesn't get stuck behind it, as we pull more or less equally from the huge and ubuntu queues.
<ahasenack> do you know what the threshold number of rdeps is?
<infinity> It gets twiddled occasionally, I don't recall the current cutoff, but it's probably around 25 or 30 or something.
<ahasenack> ok
<ahasenack> so dozens probably
<ahasenack> I guess apache falls into that category then
<infinity> It might.
<infinity> In fact, it does.
<ahasenack> 48 rdeps
<infinity> The existence of different queues is entirely irrelevant right now, since literally everything is in 'huge' anyway. :P
<ahasenack> yep
<infinity> But what this means is that if something with 1 rdep is uploaded, it won't have to wait 18 hours to get tested.
<ahasenack> that's good
<infinity> ahasenack: As for the ARM queue in particular:
<infinity> 04:27 < Laney> 9 more armhf runners online to help with the backlog there
<ahasenack> nice
<infinity> And the queues do seem to be getting smaller, so we're going in the right direction.
<ahasenack> do we have that plotted somewhere?
<infinity> We should, but I don't think we do currently.
<ahasenack> ok
<infinity> I just hit "refresh" and the numbers shrunk. :P
<infinity> Which seemed like a good thing.
<ahasenack> well there's the weekend ahead of us
<ahasenack> should be done by monday hopefully
<infinity> Long weekend, even, in the greatest country in the world.
<cjwatson> PS please don't say "build farm" when you mean autopkgtests, it makes me sad :)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.33 => 2.408.34] (desktop-core)
-queuebot:#ubuntu-release- New binary: csv-mode [amd64] (cosmic-proposed/none) [1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libplacebo [i386] (cosmic-proposed/universe) [0.5.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: libplacebo [amd64] (cosmic-proposed/universe) [0.5.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: python-pytest-asyncio [amd64] (cosmic-proposed/none) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: easyloggingpp [amd64] (cosmic-proposed/universe) [9.96.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: easyloggingpp [s390x] (cosmic-proposed/universe) [9.96.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libplacebo [s390x] (cosmic-proposed/universe) [0.5.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: easyloggingpp [i386] (cosmic-proposed/universe) [9.96.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sshtunnel [amd64] (cosmic-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libplacebo [ppc64el] (cosmic-proposed/universe) [0.5.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: easyloggingpp [ppc64el] (cosmic-proposed/universe) [9.96.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libplacebo [arm64] (cosmic-proposed/universe) [0.5.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: glib-d [i386] (cosmic-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libplacebo [armhf] (cosmic-proposed/universe) [0.5.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: glib-d [amd64] (cosmic-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: easyloggingpp [arm64] (cosmic-proposed/universe) [9.96.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: easyloggingpp [armhf] (cosmic-proposed/universe) [9.96.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: glib-d [armhf] (cosmic-proposed/universe) [2.0.0-1] (no packageset)
#ubuntu-release 2018-06-30
-queuebot:#ubuntu-release- New binary: argon2 [amd64] (cosmic-proposed/main) [0~20171227-0.1] (core)
-queuebot:#ubuntu-release- New binary: argon2 [s390x] (cosmic-proposed/main) [0~20171227-0.1] (core)
-queuebot:#ubuntu-release- New binary: argon2 [ppc64el] (cosmic-proposed/main) [0~20171227-0.1] (core)
-queuebot:#ubuntu-release- New binary: argon2 [i386] (cosmic-proposed/main) [0~20171227-0.1] (core)
-queuebot:#ubuntu-release- New binary: argon2 [arm64] (cosmic-proposed/main) [0~20171227-0.1] (core)
-queuebot:#ubuntu-release- New binary: argon2 [armhf] (cosmic-proposed/main) [0~20171227-0.1] (core)
-queuebot:#ubuntu-release- New: accepted argon2 [amd64] (cosmic-proposed) [0~20171227-0.1]
-queuebot:#ubuntu-release- New: accepted argon2 [armhf] (cosmic-proposed) [0~20171227-0.1]
-queuebot:#ubuntu-release- New: accepted argon2 [ppc64el] (cosmic-proposed) [0~20171227-0.1]
-queuebot:#ubuntu-release- New: accepted argon2 [arm64] (cosmic-proposed) [0~20171227-0.1]
-queuebot:#ubuntu-release- New: accepted argon2 [s390x] (cosmic-proposed) [0~20171227-0.1]
-queuebot:#ubuntu-release- New: accepted argon2 [i386] (cosmic-proposed) [0~20171227-0.1]
-queuebot:#ubuntu-release- New: accepted glib-d [amd64] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted glib-d [i386] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted glib-d [armhf] (cosmic-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted easyloggingpp [amd64] (cosmic-proposed) [9.96.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted easyloggingpp [armhf] (cosmic-proposed) [9.96.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted easyloggingpp [ppc64el] (cosmic-proposed) [9.96.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libplacebo [amd64] (cosmic-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [armhf] (cosmic-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [ppc64el] (cosmic-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted easyloggingpp [arm64] (cosmic-proposed) [9.96.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted easyloggingpp [s390x] (cosmic-proposed) [9.96.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libplacebo [i386] (cosmic-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted easyloggingpp [i386] (cosmic-proposed) [9.96.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libplacebo [s390x] (cosmic-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted libplacebo [arm64] (cosmic-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted csv-mode [amd64] (cosmic-proposed) [1.7-1]
-queuebot:#ubuntu-release- New: accepted sshtunnel [amd64] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted python-pytest-asyncio [amd64] (cosmic-proposed) [0.8.0-1]
-queuebot:#ubuntu-release- Unapproved: bluedevil (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: drkonqi (bionic-proposed/universe) [5.12.5-0ubuntu0.1 => 5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kde-cli-tools (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kgamma5 (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kinfocenter (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kscreen (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: breeze (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kdeplasma-addons (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kmenuedit (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kactivitymanagerd (bionic-proposed/universe) [5.12.5-0ubuntu0.1 => 5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kscreenlocker (bionic-proposed/universe) [5.12.5-0ubuntu0.1 => 5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: khotkeys (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: ksshaskpass (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kwin (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: libksysguard (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: oxygen (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: plasma-discover (bionic-proposed/universe) [5.12.5.1-0ubuntu0.1 => 5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: plasma-nm (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: plasma-sdk (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: plasma-workspace (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: ksysguard (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: milou (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: plasma-integration (bionic-proposed/universe) [5.12.5-0ubuntu0.1 => 5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: plasma-vault (bionic-proposed/universe) [5.12.5-0ubuntu0.1 => 5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: kwrited (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: plasma-pa (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: plasma-desktop (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: plymouth-kcm (bionic-proposed/universe) [5.12.4-0ubuntu1 => 5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: powerdevil (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: systemsettings (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: polkit-kde-agent-1 (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: user-manager (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: sddm-kcm (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.6-0ubuntu0.1] (kubuntu) (sync)
#ubuntu-release 2018-07-01
<tsimonq2> Oh yay, a new Plasma.
<tsimonq2> :P
<tsimonq2> cjwatson: It seems you wrote the majority of `copy-package`... is there a reason `-y` doesn't automatically switch on `--skip-missing` as well? In my opinion it would make sense because if you
<tsimonq2> *you're just wanting it to proceed without confirming, you would assume that you're putting multiple packages or something in there.
<cjwatson> tsimonq2: I'm not really convinced; I prefer that sort of thing to be controlled independently, personally.
<tsimonq2> cjwatson: OK, thanks anyway.
#ubuntu-release 2019-06-24
-queuebot:#ubuntu-release- Unapproved: erlang-p1-tls (cosmic-proposed/universe) [1.0.23-2 => 1.0.23-2ubuntu0.1] (no packageset)
<acheronuk> seb128 Laney: filled out lmdb MIR bug as best I could based on previous examples. no doubt it needs some adjustment, but hopefully that is an ok starting point
<rbasak> wxl: the relevant policy documentation for that is https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases
<Laney> acheronuk: thx, link?
<Laney> I think I subscribed the team last week
<rbasak> wxl: the changes will need to be reviewed, so I suggest a tracking bug for the microrelease and a breakdown of the changes included if you want to do that
<acheronuk> Laney: LP: #1833745
<rbasak> wxl: together with documentation of how those policy criteria are met
<ubot5> Launchpad bug 1833745 in lmdb (Ubuntu) "[MIR] required new dependency of appstream" [Undecided,New] https://launchpad.net/bugs/1833745
<seb128> acheronuk, the MIR looks good to me , thx!
<seb128> well I mean the description, I'm not a MIR reviewer/didn't look at the package :)
<seb128> you can add in the description that desktop-packages is subscribed
<acheronuk> I understood :)
<acheronuk> seb128: I see desktop-packages under the 'may be notified'. is that good enough for this?
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (cosmic-proposed/main) [4.18.0-1022.22] (kernel)
<seb128> acheronuk, yes, the team is subscribed which is what the MIR process ask for, that's just how launchpad shows subscriptions
<acheronuk> updated then
<seb128> thx
<doko> apw: please could you check that kernels built with the new hardening flags build and run in eoan? no rush
<apw> doko, fun, thanks for the heads up
-queuebot:#ubuntu-release- Unapproved: accepted erlang-p1-tls [source] (cosmic-proposed) [1.0.23-2ubuntu0.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (cosmic-proposed) [4.18.0-1022.22]
<jamespage> morning - please can the ceph 13.2.6 uploads in the unapproved queues for cosmic and disco be rejected
<jamespage> the patch picked for https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1833079 is foobar
<ubot5> Ubuntu bug 1833079 in ceph (Ubuntu Eoan) "backport librbd librados py3 string encoding fixes" [High,In progress]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-153.180] (core, kernel)
 * apw looks a queuebot ... hello ?
 * apw notes he accepted that linux-signed binary New about 2m after it appeared; and yet ... queuebot has not noticed
<apw> oh she is gone
<apw> stgraber, is queuebot still in your balywick ?
<jamespage> thanks vorlon
-queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (disco-proposed) [2.13.2-9ubuntu6.1]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (bionic-proposed/main) [5.0.0-19.20~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [4.18.0-24.25~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-19.20] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [ppc64el] (bionic-proposed/main) [5.0.0-19.20~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [4.18.0-24.25~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.18.0-24.25] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-19.20] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.18.0-24.25] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (bionic-proposed) [5.0.0-19.20~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [4.18.0-24.25~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.18.0-24.25]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-19.20]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [ppc64el] (bionic-proposed) [5.0.0-19.20~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.18.0-24.25]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [4.18.0-24.25~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-19.20]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (disco-proposed) [1:19.04.16.6]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (cosmic-proposed) [1:18.10.11.9]
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-release-upgrader [source] (bionic-proposed) [1:18.04.34]
<sil2100> ddstreet: ^ I rejected the bionic upload due to unrelated noise in the upload, can you re-upload it without those unneeded changes?
<ddstreet> sil2100 that noise is intentional, see comment from bdmurray re: running pre-build.sh in #ubuntu-devel
<sil2100> ddstreet: I know that seems to happen from time to time for u-r-u, mostly because it has some symlinks to the host directories?
<ddstreet> sil2100 well i thought my chat with him was in u-devel, having trouble finding it in scrollback now
<sil2100> ddstreet: if Brian is fine with it then I'm fine with that as well then
<sil2100> Maybe it was -release?
<ddstreet> yep just found it, was last week wed in this channel
<ddstreet> june 19
<sil2100> ddstreet: ah, see it, but yeah, basically the mirrors.cfg and DistUpgradeVersion.py pieces are good, but there's also some other changes for just the bionic upload
<ddstreet> oh?  ok lemme check that, sorry
<sil2100> ddstreet: http://launchpadlibrarian.net/429506242/ubuntu-release-upgrader_1%3A18.04.33_1%3A18.04.34.diff.gz <- nothing serious (as mentioned in my rejection message), but still, a test sources.list got removed and a variable name changed
<ddstreet> sil2100 ah, apt_btrfs_snapshot.py
<ddstreet> that gets pulled in from the running system
<sil2100> Yeah
<ddstreet> that's also part of pre-build.sh:
<ddstreet> echo "copying apt_btrfs_snapshot.py for the upgrader tarball"
<ddstreet> cp /usr/lib/python3/dist-packages/apt_btrfs_snapshot.py DistUpgrade
<sil2100> I mean, the variable name change is a no-op, but I don't know if that sources.list wasn't used somewhere in the testing?
<sil2100> Since tests/data-sources-list-test/sources.list got dropped
<sil2100> bdmurray: ^
<ddstreet> that happened during pre-build.sh as well
<sil2100> bdmurray: do you remember if that file is used anywhere during testing?
<ddstreet> i looked at later releases, it's removed from those already in his last update apr 2019
<bdmurray> sil2100: iirc sources.list is copied to for every test so yes its used but it gets overwritten all the time
<ddstreet> last commit of that file in b-e: https://pastebin.ubuntu.com/p/pHnSjqsxZN/
<ddstreet> it's gone in all except b
<bdmurray> Right, I seem to recall make sure the cleanup of the tests worked so sources.list wasn't left over
<ddstreet> yep, i confirmed the step in pre-build.sh that runs 'xvfb-run nosetests3' removes the sources.list file
<teward> can someone provide a second set of eyes on some autopkgtest failures please?  I'm pretty certain the test is bad because of a Selenium / Chromium snap issue, and therefore the test is bad, but I want a second opinion...
<sil2100> ddstreet, bdmurray: ok then, let me accept it out of Rejected then
<sil2100> Thanks
<teward> kopano-webapp/3.5.6+dfsg1-1 failures on amd64, arm64, armhf, and i386.  I think those tests need to be marked as 'bad tests' if possible, 'cause a dependency inside there is either not compatible with the arch or just outright crashing...
<teward> (it's blocking nginx in proposed, currently, but from what I can tell on the logs it's literally a Chromium crashing problem.
<teward> and since it's snapped Chromium...)
<Laney> what's changed to make tzdata not be installed in my eoan schroot?
<Laney> I guess mozjs60 not {Build-,}Depending on it is technically a bug even in Debian (Priority: required), but ...
<cjwatson> I made livecd-rootfs install it in the buildd subproject again recently ...
<cjwatson> dunno if you're using that though
<teward> Laney: you could always amend your sbuild envs by adding it to the pristines manually
<Laney> I probably used mk-sbuild to build it
<stgraber> apw: yep
<apw> stgraber, she was on holiday for a bit
<teward> release team: can someone either failure-ignore or badtest the kopano-webapp test for armhf?  Since Chromium has moved to snaps, armhf is saying the system can't run snaps there.  Or at least, not the Chromium snap.  The remaining autopkgtest failures for kopano-webapp seem Chromium related, and Laney's looking at that since it's now been snapped.
<teward> https://bugs.launchpad.net/ubuntu/+source/kopano-webapp/+bug/1834052 is a bug about the autopkgtest failures, and is related.
<ubot5> Ubuntu bug 1834052 in kopano-webapp (Ubuntu) "autopkgtest failures: Chromium-Related in Tests" [Undecided,New]
<teward> armhf returns: error: system does not fully support snapd: apparmor detected but insufficient permissions to use it
-queuebot:#ubuntu-release- New: accepted ubuntustudio-menu-add [source] (eoan-proposed) [0.1]
-queuebot:#ubuntu-release- New binary: ubuntustudio-menu-add [amd64] (eoan-proposed/universe) [0.1] (no packageset)
<Eickmeyer> sil2100: Thanks!
<wxl> rbasak: does that hold true because we consider debian an upstream? the ultimate source did not do a microrelease.
<rbasak> wxl: no point going into semantics. The effect of what you're requesting is the same as an upstream microrelease, and so that policy section applies, IMHO.
<wxl> rbasak: well, devil's in the details. just being sure. works for me.
<rbasak> wxl: you have a few choices here.
<rbasak> wxl: you can cherry-pick a minimal fix which is the default SRU position.
<rbasak> wxl: or, if you want, you can "cherry-pick" all the changes, with regular SRU paperwork for each change, as long as each individually qualifies for SRU.
<rbasak> wxl: alternatively, the SRU microrelease policy allows the concession, under the documented terms, in a common case where that is onerous.
<wxl> rbasak: i think this suggestion that has been made to me was for the purposes of convenience, but i think ultimately it would be better if i just go default. thanks for the advice.
<rbasak> You're welcome. I hope that made it clear, and it sounds reasonable?
<wxl> absolutely!
<wxl> thanks a lot :)
-queuebot:#ubuntu-release- New: accepted ubuntustudio-menu-add [amd64] (eoan-proposed) [0.1]
<acheronuk> vorlon: thanks for qtbase/pinentry hint :)
<vorlon> rikmills: n/p
<teward> thanks to sil and the rest of the AAs for accepting ubuntustudio-menu-add - pretty sure that Eickmeyer is very happy about that :)
<Eickmeyer> teward: Not so much me, but OvenWerks. Also gives me another package under my belt. :)
<teward> :P
-queuebot:#ubuntu-release- Unapproved: linux-firmware (disco-proposed/main) [1.178.1 => 1.178.2] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: linux-firmware (cosmic-proposed/main) [1.175.5 => 1.175.6] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: linux-firmware (bionic-proposed/main) [1.173.7 => 1.173.8] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.18.0-25.26] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-54.58] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-20.21] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.18.0-25.26] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-54.58] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-20.21]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-20.21]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-20.21]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.18.0-25.26]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.18.0-25.26]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-54.58]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-54.58]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [4.15.0-1036.38] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1036.38] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1017.19] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1036.38]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1017.19]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1036.38]
-queuebot:#ubuntu-release- Unapproved: lighttpd (cosmic-proposed/universe) [1.4.45-1ubuntu3 => 1.4.45-1ubuntu3.18.10] (no packageset)
#ubuntu-release 2019-06-25
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1049.54] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1049.54]
-queuebot:#ubuntu-release- Unapproved: ceph (disco-proposed/main) [13.2.4+dfsg1-0ubuntu2 => 13.2.6-0ubuntu0.19.04.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ceph (cosmic-proposed/main) [13.2.4+dfsg1-0ubuntu0.18.10.1 => 13.2.6-0ubuntu0.18.10.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas (cosmic-proposed/main) [1:13.0.1-0ubuntu1 => 1:13.0.1-0ubuntu1.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas (disco-proposed/main) [1:14.0.0-0ubuntu1 => 1:14.0.0-0ubuntu1.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lighttpd (bionic-proposed/universe) [1.4.45-1ubuntu3 => 1.4.45-1ubuntu3.18.04] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.23 => 237-3ubuntu10.24] (core)
<rbasak> bdmurray, RAOF: ^ I'm just looking at lighttpd, as it's regression-update (complete HTTPS breakage with new OpenSSL AIUI)
<rbalint> RAOF, bdmurray: please accept the systemd to bionic in your sru cycles, the fix was already in -proposed once, it just got overwritten by an other upload
<rbalint> rbasak, if you feel like looking at systemd, too, that would be appreciated :-)
<rbalint> (i'm preparing the xenial fix, too)
-queuebot:#ubuntu-release- Unapproved: accepted lighttpd [sync] (bionic-proposed) [1.4.45-1ubuntu3.18.04]
-queuebot:#ubuntu-release- Unapproved: accepted lighttpd [source] (cosmic-proposed) [1.4.45-1ubuntu3.18.10]
<rbasak> rbalint: this one isn't regression-update I don't think?
<rbasak> I really need to get back to what I was doing ;-/
-queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (disco-proposed/universe) [5.12.2+dfsg-4ubuntu1 => 5.12.2+dfsg-4ubuntu1.1] (kubuntu, qt5)
<rbalint> rbasak, np, i thought you are just having some sru fun :-)
<xnox> rbasak:  bdmurray: well "not complete" just tlsv1.3 connections =)
<xnox> rbasak:  and thanks
<rbasak> xnox: all current browsers though, presumably?
<xnox> rbasak:  aha
<rbasak> xnox: thank you for the prompt fix :)
<rbasak> xnox: does this one need a skipping of the ageing period too?
<xnox> rbasak:  let me verify it first out of the archive.
<xnox> rbasak:  and yeah, i think so.
<rbasak> OK
<rbasak> Maybe bdmurray could provide a third review/opinion on that when he gets in
-queuebot:#ubuntu-release- Unapproved: friendly-recovery (disco-proposed/main) [0.2.39 => 0.2.39ubuntu0.19.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: friendly-recovery (xenial-proposed/main) [0.2.31ubuntu2 => 0.2.31ubuntu2.1] (core)
-queuebot:#ubuntu-release- Unapproved: friendly-recovery (bionic-proposed/main) [0.2.38ubuntu1 => 0.2.38ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: friendly-recovery (cosmic-proposed/main) [0.2.39 => 0.2.39ubuntu0.18.10.1] (core)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (cosmic-proposed/main) [4.18.0-1023.24] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-54.58~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-54.58~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (cosmic-proposed) [4.18.0-1023.24]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-54.58~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-54.58~16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1010.10] (core, kernel)
<ddstreet> rbalint i noticed your patch for lp #1771858, i wonder if i should just add that and re-upload, since my systemd in xenial-unapproved has been there almost a month
<ubot5> Launchpad bug 1771858 in snapd (Ubuntu) "/snap/bin not in default PATH for units, snapd should ship system-environment-generators to inject /snap/bin into $PATH" [Critical,Confirmed] https://launchpad.net/bugs/1771858
<rbalint> ddstreet, i'm waiting for review from xnox, but i'd be ok with that
<rbalint> ddstreet, why is is sitting there for so long?
<ddstreet> rbalint i have no idea why it's been in unapproved queue for a month
<rbalint> ddstreet, i also checked the packaging repo, but found no pending new commit for upload
<rbalint> ddstreet, well i poke sru vanguards every day when i have something in :-)
<ddstreet> yeah...i have been discouraged from doing that for my stuff
<ddstreet> so...
<ddstreet> it waits for a month :)
<rbalint> ddstreet, also could you please use the packaging repo, too, and file mps?
<ddstreet> rbalint my problem is it's not based on git ubuntu
<ddstreet> so it's a real pain to use
<ddstreet> and what's file mps?
<rbalint> ddstreet, file merge proposals
<ddstreet> ah mp the 'file' part confused me
<rbalint> ddstreet, 'git ubuntu' does not support multiple commits between package updates, thus is is only good for importing archive state then preparing uploads in one shot
<rbalint> ddstreet, not for preparing uploads together
<ddstreet> well that's not really true, you can stage as many separate commits on top of the git-ubuntu repo as you like
<ddstreet> then just rebase after it's released
<ddstreet> that's what i do
<rbalint> ddstreet, i use it as a reference, but prepare uploads on top of the packaging repo
<rbalint> ddstreet, how do you review and merge them to the team repo?
<ddstreet> you mean the ubuntu-core-dev repo?  i don't, that has to be merged from the released package
<ddstreet> i asked xnox about the u-c-d systemd repo and he suggested i just ignore it
<ddstreet> so i do
<rbalint> well, that's an interesting position
<vorlon> rbalint: last I checked, said repo is also currently out of date for eoan
<rbalint> xnox, if you want people to ignore the packaging repo whey do you list it in debian/control?
<vorlon> which annoyed me
<ddstreet> i'm not sure that having both the git-ubuntu repo, and a separate special repo with different history, is a good thing
<rbalint> vorlon, because people just upload
<vorlon> rbalint: when I looked, the people was xnox
<rbalint> vorlon, he may have had unpushed changes
<vorlon> rbalint: yes, e.g. the entire ubuntu-eoan branch which does not exist in the repo
<vorlon> :)
<marcustomlinson> vorlon: remember that libreoffice bionic sru you pushed back because of an incorrect -v option? Could you approve it now/soon? Pretty pleeeease :)
<vorlon> marcustomlinson: I do remember it but don't remember what release it was in
<vorlon> bionic?
<marcustomlinson> yeah
<rbalint> vorlon, i see eoan in the repo https://code.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/+git/systemd/+ref/ubuntu-eoan
<vorlon> 3 weeks have passed since? sorry about that
<marcustomlinson> vorlon: I don't like being a nag :P
<vorlon> marcustomlinson: I had meant to do it soon after, but hit EOD before getting to it
<vorlon> rbalint: hmm something's very strange here then, I don't see it with a git remote update
<rbalint> vorlon, 'git fetch --all' ?
<vorlon> rbalint: oh, that's not the remote I'm using, hmm, did this change?
<rbalint> vorlon, if you disclose your current remote i can tell :-)
<vorlon> rbalint: my previous remote was git+ssh://git.launchpad.net/~ubuntu-core-dev/+git/systemd
<rbalint> vorlon, it seems it moved but you can find the current in Vcs-Git
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (bionic-proposed) [1:6.0.7-0ubuntu0.18.04.7]
<vorlon> rbalint: yeah, confirmed
<rbalint> vorlon, lp terribly overcomplicated git repository naming and that does not help
<vorlon> rbalint: the uris were so similar my eyes skipped over when reading
<rbalint> vorlon, in the sru process imo it would be beneficial to check if the changes in unapproved are present in the packaging repository if there is any repo
<rbalint> ddstreet, xnox ack-ed my xenial change out of band, feel free to include it in your upload
<vorlon> rbalint: I'm not signing up to implement this, or to require additional round trips through the queue in the event that Vcs-* in an SRU contains stale data (and even in this example, systemd gets it wrong because the Vcs-Git doesn't say which is the correct branch).  But anybody could run their own checker against the SRU queue and yell at uploaders :)
<rbalint> vorlon, Vcs-Git: https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd -b ubuntu-bionic
<vorlon> like so, yes
<vorlon> is currently wrong in eoan
<rbalint> vorlon, if there is no interest in making having the commits in the repo there is no point in having repos
<rbalint> vorlon, because every core dev can happily ignore it
<vorlon> rbalint: I am interested, but reject the idea that SRU team be responsible for enforcing this
<vorlon> because compliance today is so terrible, including on devel series, and with my SRU team hat on I don't agree to accept the additional workload
<rbalint> vorlon, should not they vote or something?
<vorlon> I'm happy to put it on the SRU team agenda
<vorlon> (done, on agenda for next meeting)
<tsimonq2> Well, this could be solved once git-ubuntu has imported all of the repositories and the workflow is moving along with that. pull-lp-source could then yell about that. However, that day is not today.
<vorlon> rbalint: next meeting is in 3 weeks, so feel free to not block on SRU team doing this work ;)
<rbalint> tsimonq2, it could be solved without git-ubuntu importing anything
<tsimonq2> rbalint: Are you proposing a solution that does not require as much manual work as previously implied? :)
<rbalint> tsimonq2, Debian has an implementation that works ok https://qa.debian.org/cgi-bin/vcswatch?package=wireshark
<rbalint> tsimonq2, i'm not proposing inventing anything
<tsimonq2> rbalint: Ahh.
<rbasak> rbalint: what I'd like, in the long term, is to add checks for this kind of thing to "git ubuntu lint", and have a bot run that on MPs. Then it'd be minimal effort on both contributors and reviewers. I don't think it's worth imposing further checks now, until something like that is ready.
<rbalint> rbasak, having a bot linting .changes in the quenue seem to be a better direction
<rbasak> rbalint: example: submit an MP against the systemd git-ubuntu branches, and a bot will relay the lint warning that Vcs-Git appears to be valid, but the MP isn't against that branch.
<marcustomlinson> vorlon: just checking you're aware of a libreoffice-l10n package in the queue too?
<vorlon> marcustomlinson: I thought I had already accepted the -l10n one last time around
<rbalint> rbasak, this is not the problem
<vorlon> marcustomlinson: ok reviewing that also, thanks for pointing it out
<marcustomlinson> that was the problematic one
<rbalint> rbasak, also mps across not official packaging repos is fine
<bdmurray> xnox: Were you looking for a "speedy delivery" of lighttpd to -updates?
<rbasak> bdmurray: I believe he did, yes, based on earlier conversation here
<rbasak> 11:46 <xnox> rbasak:  and yeah, i think so.
<rbasak> In response to
<rbasak> 11:46 <rbasak> xnox: does this one need a skipping of the ageing period too?
<rbalint> rbasak, if there is an mp against the wrong branch it is usually pretty easy to spot
<rbalint> rbasak, since the diff is very different
<rbasak> rbalint: by "wrong branch" I meant "against git-ubuntu pkg/ubuntu/<foo>-devel" instead of "~ubuntu-core-dev/ubuntu/+source/systemd ubuntu-bionic"
<rbasak> That's a case where the diff would be identical.
<xnox> bdmurray:  yes can publish lighttpd. i prepared & verfied the sru; rbasak did the code review. i think we should publish the sru, last time i looked there was adt regressions (i retried them) and so far there were no comments from not-me that the update works.
<xnox> bdmurray:  well, it's green in bionic now, still one regression in cosmic
<rbasak> Perhaps we could wait for one person affected to confirm that the fix works?
<bdmurray> xnox, rbasak: the "codepath appears to still be the same-ish" didn't fill me with confidence. You two think its good?
<rbasak> bdmurray: the patch looked sane to me, but I didn't code-review in further detail than just examining the diff.
<rbasak> I didn't examine to consider edge cases, for example.
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice-l10n [source] (bionic-proposed) [1:6.0.7-0ubuntu0.18.04.7]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1010.10]
<bdmurray> I'll plan on releasing it later during the day to give some time for more feedback.
-queuebot:#ubuntu-release- Unapproved: golang-google-grpc (disco-proposed/universe) [1.6.0-3ubuntu0.19.04.1 => 1.6.0-3ubuntu0.19.04.2] (ubuntu-mate)
<tsimonq2> sil2100: ^ you were working on this at one point, sponsored.
<xnox> bdmurray:  green in both bionic and cosmic
-queuebot:#ubuntu-release- Unapproved: kylin-nm (disco-proposed/universe) [1.0.0-1 => 1.0.0-1ubuntu0.1] (ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: rpi.gpio (bionic-proposed/universe) [0.6.3-1ubuntu4 => 0.6.5-1ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-154.181] (core, kernel)
-queuebot:#ubuntu-release- Packageset: 73 entries have been added or removed
<bdmurray> The release upload queues have a lot of pending diffs, is there something going on with Launchpad?
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-154.181]
-queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (bionic-proposed/main) [3.28.1-0ubuntu1.2 => 3.28.1-0ubuntu1.3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.49 => 2.408.50] (desktop-core)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.18.0-1023.24~18.04.1] (kernel)
<cjwatson> bdmurray: the diff queue got stuck on Friday; we unstuck it this morning but it has a huge backlog as a result, which it is continuing to work through
<bdmurray> cjwatson: got it, thanks!
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.18.0-1023.24~18.04.1]
<cjwatson> I'm afraid I can't easily tell exactly how long the backlog is (need better metrics there), only that it's successfully processing jobs at the moment
 * rbasak plugs "git ubuntu queue sync", which for packages in main, allows for "git log -p -1" for a queue diff :)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (cosmic-proposed/main) [4.18.0-1015.16] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (cosmic-proposed) [4.18.0-1015.16]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1036.38~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1017.19~16.04.2] (kernel)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.50]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1036.38~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1017.19~16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-settings-daemon [source] (disco-proposed) [3.32.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1010.10] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1010.10]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (cosmic-proposed) [2:13.0.3-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu10.24]
#ubuntu-release 2019-06-26
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (disco-proposed) [1.178.2]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (cosmic-proposed) [1.175.6]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (bionic-proposed) [1.173.8]
<rbalint> rbasak could you please release cosmic's initramfs-tools today? there is a new one in unapproved and i'd also like to piggyback on it with LP: #1814355
<ubot5> Launchpad bug 1814355 in snapd (Ubuntu) "snapd remove /usr/local/bin from the PATH for all systemd unit (bionic SRU regression)" [High,Confirmed] https://launchpad.net/bugs/1814355
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (cosmic-proposed/main) [0.131ubuntu15.2 => 0.131ubuntu15.3] (core)
<xnox> https://launchpad.net/ubuntu/cosmic/+queue?queue_state=1&queue_text=initramfs-tools
<xnox> the one from 6 minutes ago, superseeds the unapproved upload from 11th of june
<rbasak> rbalint: I'm out this morning. I'll try and look this afternoon for you.
<rbalint> rbasak, thanks!
-queuebot:#ubuntu-release- Unapproved: linux-signed-hwe-edge (bionic-proposed/main) [5.0.0-19.20~18.04.1 => 5.0.0-19.20~18.04.1] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-hwe-edge (bionic-proposed/main) [5.0.0-19.20~18.04.1 => 5.0.0-19.20~18.04.1] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected linux-signed-hwe-edge [sync] (bionic-proposed) [5.0.0-19.20~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-hwe-edge [sync] (bionic-proposed) [5.0.0-19.20~18.04.1]
-queuebot:#ubuntu-release- Unapproved: linux-signed-hwe-edge (bionic-proposed/main) [5.0.0-19.20~18.04.1 => 5.0.0-19.20~18.04.1] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-hwe-edge [sync] (bionic-proposed) [5.0.0-19.20~18.04.1]
-queuebot:#ubuntu-release- Unapproved: linux-signed-hwe-edge (bionic-security/main) [5.0.0-19.20~18.04.1 => 5.0.0-19.20~18.04.1] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed-hwe-edge (bionic-updates/main) [5.0.0-19.20~18.04.1 => 5.0.0-19.20~18.04.1] (kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-hwe-edge [sync] (bionic-security) [5.0.0-19.20~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed-hwe-edge [sync] (bionic-updates) [5.0.0-19.20~18.04.1]
-queuebot:#ubuntu-release- Unapproved: linux-signed (disco-security/main) [5.0.0-20.21 => 5.0.0-19.20] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: linux-signed (disco-updates/main) [5.0.0-20.21 => 5.0.0-19.20] (core, kernel) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (disco-security) [5.0.0-19.20]
-queuebot:#ubuntu-release- Unapproved: accepted linux-signed [sync] (disco-updates) [5.0.0-19.20]
-queuebot:#ubuntu-release- New binary: jsonnet [s390x] (eoan-proposed/universe) [0.13.0+ds-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: jsonnet [amd64] (eoan-proposed/universe) [0.13.0+ds-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: jsonnet [ppc64el] (eoan-proposed/universe) [0.13.0+ds-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: jsonnet [i386] (eoan-proposed/universe) [0.13.0+ds-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: jsonnet [armhf] (eoan-proposed/universe) [0.13.0+ds-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: jsonnet [arm64] (eoan-proposed/universe) [0.13.0+ds-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (disco-proposed/main) [1:3.32.2-0ubuntu1 => 1:3.32.2-0ubuntu1.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1012.13] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1012.13]
-queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu21.21 => 229-4ubuntu21.22] (core)
<ddstreet> ubuntu-sru team, please reject my systemd upload in xenial unapproved queue from 1 month ago, i just re-uploaded with an additional patch from rbalint
-queuebot:#ubuntu-release- Packageset: Removed gnome-control-center from desktop-core in disco
-queuebot:#ubuntu-release- Packageset: Added gnome-control-center to ubuntu-desktop in disco
-queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (xenial-proposed) [229-4ubuntu21.22]
<apw> ddstreet, ^
<ddstreet> apw thanks, hopefully new uplaod won't be in unapproved for a month :)
<apw> changing systemd is always mentally challenging
<apw> its unreliable enough as it is
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.39.2 => 2.39.2ubuntu0.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.39.2ubuntu0.1]
<tsimonq2> [2019-06-26 16:36:21] lb_chroot_hooks
<tsimonq2> P: Begin executing hooks...
<tsimonq2> ...
<tsimonq2> AttributeError: 'Package' object has no attribute 'section'
<tsimonq2> Ooh, fun.
<tsimonq2> Who broke the archive? :P
 * tsimonq2 wonders if this is an apt issue.
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1045.50] (kernel)
<tsimonq2> It doesn't seem like it's an apt issue; reverting to an older version of apt in a PPA and then doing a test livefs build shows the same error.
<tsimonq2> (known good version of apt, that is)
<tsimonq2> Aha! https://launchpad.net/ubuntu/+source/python-apt/1.9.0 says "- Remove Package.section attributes" which is relevant because "pkg       is the python-apt Package object for this package"
<tsimonq2> vorlon, juliank: The latest update to python-apt broke apt-xapian-index by removing the (admittedly legacy) Package.section attribute. This is a problem because it's included by default on Lubuntu images (and probably more), and is causing the ISO build to fail. I see there being two potential solutions here: 1) Fix the apt-xapian-index build in eoan-proposed and fix apt-xapian-index itself
<tsimonq2> (either by doing Ubuntu-specific changes or via Debian in the bug I'm about to file); 2) Revert the commit removing those attributes in python-apt for now until 1) is in place.
<tsimonq2> 2) is easy for now, but I don't want to touch python-apt without talking to juliank first.
<tsimonq2> I'm absolutely exploring why this wasn't caught during p-m.
<tsimonq2> That will be another bug I file in Debian, because this should have been caught earlier.
<tsimonq2> Oh, it's orphaned. Coooool.
<tsimonq2> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931133 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931132
<ubot5> Debian bug 931133 in apt-xapian-index "apt-xapian-index: unusable after recent python-apt update due to usage of deprecated Package.section attribute" [Important,Open]
<ubot5> Debian bug 931132 in apt-xapian-index "apt-xapian-index: please enable autopkgtests" [Important,Open]
<teward> tsimonq2: > orphaned since 1243 days. < yeah probably not going to get fixed heh
<tsimonq2> teward: Become a DD and then adopt it. :P
<tsimonq2> Or a DM.
<teward> tsimonq2: no thanks I don't want it :P
<Eickmeyer> Can anybody shed light on why Studio's build failed? https://launchpadlibrarian.net/430720022/buildlog_ubuntu_eoan_amd64_ubuntustudio_BUILDING.txt.gz
<Eickmeyer> I don't know if it's related to tsimonq2's apt-xapian-index bug or not.
<tsimonq2> Eickmeyer: Yes it is.
<Eickmeyer> tsimonq2: kthx. :)
<wxl> ah they are similar with
<wxl> AttributeError: 'Package' object has no attribute 'section'
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-edge [amd64] (bionic-proposed/main) [4.18.0-1015.16~18.04.1] (kernel)
<wxl> https://salsa.debian.org/apt-team/python-apt/commit/fedd51be48be53d00d386c45eab8f63f462db202#faf51da27adfc87e2950af44dc159112540aed75_0_10
<wxl> * The `section` attribute has been removed from :class:`apt_pkg.Package`
<wxl>   and :class:`apt.package.Package`
<tsimonq2> Yeah, it's the same bug.
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-edge [amd64] (bionic-proposed) [4.18.0-1015.16~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1045.50]
<juliank> tsimonq2: We need to fix reverse depends. The python-apt change cannot be reverted, it is following apt's removal of that field
<juliank> Eickmeyer: I fixed that yesterday, but livecd-rootfs got stuck in proposed and pyython-apt migrated
<tsimonq2> juliank: ack
<juliank> If somebody could hint that ubuntu-image failure that's blocking livecd-rootfs, image building will be back on
<juliank> I don't have the repo on this machine, and finding it, branching it, and pushing it back seems like it's a lot of work right now :)
<Eickmeyer> juliank: ack, but can't do the hint.
<juliank> tsimonq2: I filed the other apt 1.9 migration bugs as normal in Debian, not important, as the move to unstable is still way off; I also attach patches to them all :)
<juliank> But maybe I missed some
<tsimonq2> juliank: ok, feel free to adjust my bug reports :)
<juliank> tsimonq2: If you see other such issues and forward them, it'd be nice if you could User: deity@lists.debian.org\nUsertags: apt-1.9.0 :)
<juliank> tsimonq2: I'll have a look at apt-xapian-index shortly and see if I can add static typing information, that could cover any future API breaks at least - though not sure when to run them yet, gotta work on a solution for automatic python type testing, as there are regressions due to mypy updates and semantic changes all the time :/
<tsimonq2> juliank: ack, thanks
<juliank> I added the usertag to your bug btw
<juliank> tracking list: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=deity@lists.debian.org;tag=apt-1.9.0
<tsimonq2> Sweet
<juliank> So, like PEP8 tests we don't want to run mypy tests during autopkgtests or build I think, as it can regress due to changes in mypy
<juliank> -> example: 0.710 complains if I re-define a variable with the same type, 0.670 does not
<juliank> the question is: if we don't want to do this, how can we ensure to catch type failures?
<juliank> OTOH, if the tests depend on mypy, a new mypy will only migrate after all tests are fixed, so maybe we are good?
<juliank> oh ffs, ubuntu-image fails in different places in different runs
<juliank> here's the hint: https://code.launchpad.net/~juliank/britney/hints-ubuntu--livecd-rootfs-2-598/+merge/369363
<juliank> skiptested livecd-rootfs upload as the ubuntu-image failure is super weird and i did not want to badtest it
<juliank> please merge!
 * juliank also retried it a second time and hopes either thing happens before the next image build
#ubuntu-release 2019-06-27
-queuebot:#ubuntu-release- New source: dpf-plugins (eoan-proposed/primary) [1.2-0ubuntu1]
<rikmills> inevitably, Kubuntu livefs build failed
<Laney> juliank: I merged it for you
<juliank> Laney: heh, vorlon also just badtested ubuntu-image, so we got livecd-rootfs unblocked twice now :)
<Laney> nice
<rikmills> juliank: kubuntu failed on apt-xapian-index, so we need a fix for that one as well as lubuntu
<juliank> So, apt-xapian-index is blocking {l,k}ubuntu
<juliank> and it has a proposed upload that ftbfs
<rikmills> ftbfs on its tests if I recall
<juliank> yup
<rbalint> sil2100, could you please consider accepting systemd sru to xenial? (thankd ddstreet for including my patch, too)
<juliank> rikmills: it's hilarious
<juliank> rikmills: the tests fail because it asserts that the index is up-to-date
<juliank> So, on first build(s), it uses a wrapped apt cache, which is only written to memory
<juliank> hence most plugins report no mtime, because they can't find the cache file
<juliank> then, we run on the full cache instead, and now the plugins can report an mtime because the cache file does exist now
<sil2100> rbalint: ACK
<juliank> I'm not sure how that ever worked
<Laney> a timeless phrase
<juliank> how come it builds on Debian?
<juliank> hahaha
<juliank> builds in sbuild, but not when running build manually in my full debian
 * rikmills sees the upload and thanks juliank :)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.39.2ubuntu0.1 => 2.39.2ubuntu0.2] (desktop-core, ubuntu-server)
<ginggs> sil2100: thanks for releasing coinor-ipopt sru!  is there a reason for cosmic and bionic being delayed?  i only see disco
<sil2100> ginggs: I'm releasing SRUs going per-series, so I'll get to it shortly ;)
<ginggs> sil2100: ok, thanks :)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.39.2ubuntu0.2]
<rbalint> sil2100, i also filed https://code.launchpad.net/~rbalint/britney/autopkgtest-bionic-hint/+merge/369390 to clear bionic's systemd
-queuebot:#ubuntu-release- Unapproved: youtube-dl (disco-proposed/universe) [2019.01.17-1 => 2019.01.17-1.1~ubuntu19.04.1] (ubuntu-budgie, ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: youtube-dl (bionic-proposed/universe) [2018.03.14-1 => 2018.03.14-1ubuntu18.04.1] (ubuntu-budgie, ubuntukylin)
<rikmills> juliank: thanks. Kubuntu iso is now ok. lubuntu's should be ok later on that evidence
<Eickmeyer> AAs: dpf-plugins (sponsored by teward) in NEW queue, awaiting review.
 * teward drops a bag of flaming cat poo onto Eickmeyer for the unnecessary ping
 * Eickmeyer teleports teward a gallon of coffee for his efforts
<teward> Eickmeyer: have some patience, meetings're going on :P
<Eickmeyer> teward: I see that, just wanted to get the message in here.
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (xenial-proposed) [229-4ubuntu21.22]
<vorlon> tjaalton: are you aware that the SRUs for LP: #1824111 are blocked by LP: #1831498 not being verified for mesa?
<ubot5> Launchpad bug 1824111 in OEM Priority Project "Backport packages for 18.04.3 HWE stack" [Critical,Confirmed] https://launchpad.net/bugs/1824111
<ubot5> Launchpad bug 1831498 in mesa (Ubuntu Disco) "radeonsi: GTK elements become invisible in some applications (GIMP, LibreOffice)" [Undecided,Fix committed] https://launchpad.net/bugs/1831498
<tsimonq2> juliank: Thanks, would you be able to QA upload to Debian?
<juliank> tsimonq2: I don't think there's a need for that right now, nobody is going to install that anyway
<tsimonq2> juliank: ack
<juliank> Like it's not for buster, it would go to experimental, and who's going to install that from there?
<juliank> But I should attach the diff to the bug so I don't forget :)
<tsimonq2> ok :)
<tsimonq2> THanks
-queuebot:#ubuntu-release- Unapproved: mutter (disco-proposed/main) [3.32.1-2ubuntu1~19.04.1 => 3.32.2+git20190626-1ubuntu1~19.04.1] (desktop-core, desktop-extra)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (bionic-proposed/main) [5.0.0-20.21~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [arm64] (bionic-proposed/main) [5.0.0-20.21~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [ppc64el] (bionic-proposed/main) [5.0.0-20.21~18.04.1] (kernel)
<ddstreet> sil2100 i like the new 'autopkgtest failed, please investigate' automated bug comments, but it seems like it is getting added to the bug before all the autopkgtests finish, even though it says 'all autopkgtests...have finished running'
<ddstreet> even the pending-sru page didn't have any failing autopkgtests listed when i first looked at it, and the proposed-migration page shows quite a few still running
<ddstreet> just an fyi
<Odd_Bloke> ddstreet: What about http://autopkgtest.ubuntu.com/?  (AFAIK the two things you referenced are generated on a cron schedule, so won't be current.)
<ddstreet> Odd_Bloke not even there; one of the tests showing up as failing on the proposed_migration page doesn't show the failed test
<ddstreet> or didnt yet when i checked
<ddstreet> Odd_Bloke oh, and the various still-running tests do show as actually still running at a.u.c/running
<sil2100> ddstreet: ah, yeah, good point! So the thing is that the autopkgtests have finished running, but the pending-sru page is only updated every n-hours or so
<ddstreet> sil2100 er, well they actually haven't finished running
<sil2100> ddstreet: oh, so it's a bug then, hm
<sil2100> Will look into that, it shouldn't be the case
<ddstreet> thnx
<tjaalton> vorlon: yes, infinity promised to test it ;)
<tjaalton> the other option would be to push 19.0.8
<tjaalton> the fix for 1831498 has been upstream since 19.0.4 or so
-queuebot:#ubuntu-release- New sync: ec2-instance-connect (eoan-release/primary) [1.1.9-0ubuntu3]
-queuebot:#ubuntu-release- New sync: ec2-instance-connect (disco-proposed/primary) [1.1.9-0ubuntu3~19.04.1]
-queuebot:#ubuntu-release- New sync: ec2-instance-connect (bionic-proposed/primary) [1.1.9-0ubuntu3~18.04.1]
-queuebot:#ubuntu-release- New sync: ec2-instance-connect (xenial-proposed/primary) [1.1.9-0ubuntu3~16.04.1]
-queuebot:#ubuntu-release- New: accepted ec2-instance-connect [sync] (eoan-release) [1.1.9-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted ec2-instance-connect [sync] (disco-proposed) [1.1.9-0ubuntu3~19.04.1]
-queuebot:#ubuntu-release- New: accepted ec2-instance-connect [sync] (bionic-proposed) [1.1.9-0ubuntu3~18.04.1]
-queuebot:#ubuntu-release- New: accepted ec2-instance-connect [sync] (xenial-proposed) [1.1.9-0ubuntu3~16.04.1]
-queuebot:#ubuntu-release- Unapproved: gnome-shell (disco-proposed/main) [3.32.1-1ubuntu1~19.04.1 => 3.32.2-2ubuntu1~ubuntu19.04.1] (desktop-core, desktop-extra, mozilla)
<Dmitrii-Sh> coreycb: verified https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-auth-mellon/+bug/1820279 for rocky and stein
<ubot5> Ubuntu bug 1820279 in libapache2-mod-auth-mellon (Ubuntu Cosmic) "[FFe] [SRU] build mellon with --enable-diagnostics to ease up SSO debugging" [High,Fix committed]
-queuebot:#ubuntu-release- New binary: ec2-instance-connect [amd64] (bionic-proposed/universe) [1.1.9-0ubuntu3~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: ec2-instance-connect [amd64] (xenial-proposed/universe) [1.1.9-0ubuntu3~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: ec2-instance-connect [amd64] (disco-proposed/universe) [1.1.9-0ubuntu3~19.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ec2-instance-connect [amd64] (xenial-proposed) [1.1.9-0ubuntu3~16.04.1]
-queuebot:#ubuntu-release- New: accepted ec2-instance-connect [amd64] (bionic-proposed) [1.1.9-0ubuntu3~18.04.1]
-queuebot:#ubuntu-release- New: accepted ec2-instance-connect [amd64] (disco-proposed) [1.1.9-0ubuntu3~19.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (bionic-proposed) [5.0.0-20.21~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [ppc64el] (bionic-proposed) [5.0.0-20.21~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [arm64] (bionic-proposed) [5.0.0-20.21~18.04.1]
-queuebot:#ubuntu-release- New binary: ec2-instance-connect [amd64] (eoan-release/universe) [1.1.9-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New: accepted ec2-instance-connect [amd64] (eoan-release) [1.1.9-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: gnome-shell (bionic-proposed/main) [3.28.4-0ubuntu18.04.1 => 3.28.4-0ubuntu18.04.2] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [4.18.0-25.26~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [4.18.0-25.26~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [4.18.0-25.26~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [4.18.0-25.26~18.04.1]
#ubuntu-release 2019-06-28
-queuebot:#ubuntu-release- New binary: json-c [amd64] (eoan-proposed/main) [0.13.1+dfsg-2] (core)
-queuebot:#ubuntu-release- New binary: json-c [s390x] (eoan-proposed/main) [0.13.1+dfsg-2] (core)
-queuebot:#ubuntu-release- New binary: json-c [i386] (eoan-proposed/main) [0.13.1+dfsg-2] (core)
-queuebot:#ubuntu-release- New binary: json-c [armhf] (eoan-proposed/main) [0.13.1+dfsg-2] (core)
-queuebot:#ubuntu-release- New binary: json-c [ppc64el] (eoan-proposed/main) [0.13.1+dfsg-2] (core)
-queuebot:#ubuntu-release- New binary: json-c [arm64] (eoan-proposed/main) [0.13.1+dfsg-2] (core)
-queuebot:#ubuntu-release- New binary: wlroots [amd64] (eoan-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wlroots [ppc64el] (eoan-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wlroots [i386] (eoan-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wlroots [s390x] (eoan-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wlroots [arm64] (eoan-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wlroots [armhf] (eoan-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted json-c [amd64] (eoan-proposed) [0.13.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted json-c [armhf] (eoan-proposed) [0.13.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted json-c [ppc64el] (eoan-proposed) [0.13.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted node-d3-scale-chromatic [amd64] (eoan-proposed) [1.3.3-1]
-queuebot:#ubuntu-release- New: accepted json-c [arm64] (eoan-proposed) [0.13.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted json-c [s390x] (eoan-proposed) [0.13.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted json-c [i386] (eoan-proposed) [0.13.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted wlroots [amd64] (eoan-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted wlroots [armhf] (eoan-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted wlroots [ppc64el] (eoan-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted wlroots [arm64] (eoan-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted wlroots [s390x] (eoan-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted wlroots [i386] (eoan-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New binary: sway [amd64] (eoan-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sway [ppc64el] (eoan-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sway [i386] (eoan-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sway [s390x] (eoan-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sway [arm64] (eoan-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sway [armhf] (eoan-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted sway [amd64] (eoan-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted sway [armhf] (eoan-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted sway [ppc64el] (eoan-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted sway [arm64] (eoan-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted sway [s390x] (eoan-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted sway [i386] (eoan-proposed) [1.1.1-1]
<Ukikie> Thanks for the above.
<cjwatson> np
-queuebot:#ubuntu-release- Unapproved: gnome-desktop3 (bionic-proposed/main) [3.28.2-0ubuntu1.3 => 3.28.2-0ubuntu1.4] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-desktop3 (disco-proposed/main) [3.32.1-1ubuntu1.1 => 3.32.1-1ubuntu1.2] (ubuntu-desktop)
<teward> archive admins, if you get two minutes, can you review dpf-plugins in Eoan NEW for the Ubuntu Studio team?  It was uploaded to NEW a couple days ago, and Studio's starting to be naggy about getting it looked at...
-queuebot:#ubuntu-release- Unapproved: creduce (bionic-proposed/universe) [2.8.0~20180422-1 => 2.10.0-1~18.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: creduce (disco-proposed/universe) [2.9~20190320-0ubuntu1 => 2.10.0-1~19.04] (no packageset)
<Trevinho> bdmurray: hey... I was wondering if there is a way to make apport to call some specific command when a program crash... I.e., in gnome-shell would be nice to call gjs_dumpstack to get the JS trace...
-queuebot:#ubuntu-release- Unapproved: ubuntu-docs (disco-proposed/main) [19.04.2 => 19.04.3] (desktop-core, personal-gunnarhj)
<bdmurray> Trevinho: https://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/apport/hookutils.py#L361 Yes, in an apport package hook you could call "command_output()" or "attach_root_command_output()".
<Trevinho> bdmurray: mh, so the thing here would be attaching to the process with gdb (in batch mode), call a method... does this apply?
<bdmurray> Trevinho: The apport package hooks run after the application has crashed and there already is a crash file so probably not.
<LocutusOfBorg> tsimonq2, are you working on fixing the reverse-deps of json-c? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904418
<ubot5> Debian bug 904418 in release.debian.org "transition: json-c" [Normal,Open]
<LocutusOfBorg> we have 6 packages FTBFS (now 5, because I just fixed one)
<LocutusOfBorg> where is unit193?
<Trevinho> bdmurray: eh, that is what i was wondering... Altough there's something that keeps the process there for tracing, so would be nice to be able to hook at that level
<Laney> The kernel gives the core file to apport, that's all
<cascardo> hey, so makedumpfile is stuck in eoan-proposed because s390x adt always fails. it has succeeded once, so it's not always-fail anymore
<cascardo> I have used some help with testing it on s390x and trying to find out why it always fails on s390x, but we couldn't figure it out
<cascardo> so, I would like to have it forced as a badtest
<Trevinho> Laney: mhmhmh, I'm quite sure there's something going on else, because for the time that the process is being analized is kept running, in fact normally when something crashes (i.e. the shell), I've all the time to attach manually to the process
<Laney> cascardo: seems sensible
<Laney> cascardo: interesting number of retries btw
<Laney> :P
-queuebot:#ubuntu-release- Unapproved: gdb (bionic-proposed/main) [8.1-0ubuntu3 => 8.1-0ubuntu3.1] (core)
<cascardo> Laney: yeah, I am still curious on how it passed, not sure if it's a particular system, so was just trying to get it to pass again
<cascardo> Laney: by the way, can you look at the tip at git://git.launchpad.net/~cascardo/autopkgtest-cloud  ?
<cascardo> trying to get makedumpfile to really be tested on ppc64el, instead of being sort of skipped
<Laney> cascardo: not right now, sorry, maybe vorlon or juliank?
<cascardo> vorlon: ^
<juliank> lgtm
<cascardo> juliank: I am not sure I have permissions to push there, would you?
-queuebot:#ubuntu-release- Unapproved: fonts-noto-cjk (disco-proposed/main) [1:20170601+repack1-3 => 1:20190409+repack1-0ubuntu0.19.04] (desktop-core, personal-gunnarhj)
-queuebot:#ubuntu-release- Unapproved: fonts-noto-cjk (cosmic-proposed/main) [1:20170601+repack1-3 => 1:20190409+repack1-0ubuntu0.18.10] (desktop-core, personal-gunnarhj)
<teward> can someone badtest the kopano-webapp autopkgtests please?  the chromium deb2snap transition is breaking the tests, and there's already a bug assigned.  (It blocks httpd, which includes Apache, Lighttp, and NGINX in proposed)
<teward> (xnox had requested as well for Apache)
-queuebot:#ubuntu-release- Unapproved: fonts-noto-cjk (bionic-proposed/main) [1:20170601+repack1-2 => 1:20190409+repack1-0ubuntu0.18.04] (desktop-core, personal-gunnarhj)
<juliank> cascardo: I don't either iirc
<juliank> It's for release team members only
<cascardo> juliank: no problem, I'll ping people on Monday if it's not applied by then, thanks for the review
-queuebot:#ubuntu-release- Unapproved: language-selector (disco-proposed/main) [0.194 => 0.194.1] (core, personal-gunnarhj)
-queuebot:#ubuntu-release- Unapproved: language-selector (bionic-proposed/main) [0.188.2 => 0.188.3] (core, personal-gunnarhj)
-queuebot:#ubuntu-release- Unapproved: libarchive (bionic-proposed/main) [3.2.2-3.1ubuntu0.3 => 3.2.2-3.1ubuntu0.3.1] (core)
-queuebot:#ubuntu-release- Unapproved: iputils (bionic-proposed/main) [3:20161105-1ubuntu2 => 3:20161105-1ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: docker.io (disco-proposed/universe) [18.09.5-0ubuntu1 => 18.09.7-0ubuntu1~19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: docker.io (cosmic-proposed/universe) [18.09.5-0ubuntu1~18.10.2 => 18.09.7-0ubuntu1~18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: docker.io (bionic-proposed/universe) [18.09.5-0ubuntu1~18.04.2 => 18.09.7-0ubuntu1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: docker.io (xenial-proposed/universe) [18.09.5-0ubuntu1~16.04.2 => 18.09.7-0ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: docker.io (disco-proposed/universe) [18.09.5-0ubuntu1 => 18.09.7-0ubuntu1~19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected docker.io [source] (disco-proposed) [18.09.7-0ubuntu1~19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (disco-proposed) [18.09.7-0ubuntu1~19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted youtube-dl [source] (disco-proposed) [2019.01.17-1.1~ubuntu19.04.1]
-queuebot:#ubuntu-release- Unapproved: docker.io (cosmic-proposed/universe) [18.09.5-0ubuntu1~18.10.2 => 18.09.7-0ubuntu1~18.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected docker.io [source] (cosmic-proposed) [18.09.7-0ubuntu1~18.10.1]
-queuebot:#ubuntu-release- Unapproved: docker.io (bionic-proposed/universe) [18.09.5-0ubuntu1~18.04.2 => 18.09.7-0ubuntu1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (cosmic-proposed) [18.09.7-0ubuntu1~18.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected docker.io [source] (bionic-proposed) [18.09.7-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted youtube-dl [source] (bionic-proposed) [2018.03.14-1ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (bionic-proposed) [18.09.7-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected docker.io [source] (xenial-proposed) [18.09.7-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: docker.io (xenial-proposed/universe) [18.09.5-0ubuntu1~16.04.2 => 18.09.7-0ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (xenial-proposed) [18.09.7-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted friendly-recovery [source] (disco-proposed) [0.2.39ubuntu0.19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted friendly-recovery [source] (cosmic-proposed) [0.2.39ubuntu0.18.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted friendly-recovery [source] (bionic-proposed) [0.2.38ubuntu1.1]
<tsimonq2> LocutusOfBorg: ack
-queuebot:#ubuntu-release- Unapproved: accepted friendly-recovery [source] (xenial-proposed) [0.2.31ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (disco-proposed) [1:3.32.2-0ubuntu1.1]
#ubuntu-release 2019-06-29
<tsimonq2> infinity, vorlon: Is there any particular reason armel is still listed as a buildable architecture in Launchpad? ESM doesn't build for armel and that was dropped in 2013. :P
<infinity> tsimonq2: Because precise still has armel, what ESM supports isn't relevant.
<infinity> tsimonq2: It'll disappear off the list (just like sparc, ia64, etc did) when no active suite includes the arch at all.
<tsimonq2> infinity: Ah, so it's not a manual process? Makes sense.
<LocutusOfBorg> hello, does anybody know why this package never got autsyncd?
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/google-compute-image-packages/+publishinghistory
<LocutusOfBorg> oh got it
<wxl> mdeslaur: looks like your usb-creator updates are no longer pending in the security team PPA. do we have a current repo somewhere now? context https://irclogs.ubuntu.com/2019/06/20/%23ubuntu-release.html#t13:27
#ubuntu-release 2019-06-30
-queuebot:#ubuntu-release- Unapproved: python-pygraphviz (bionic-proposed/universe) [1.4~rc1-1build2 => 1.4~rc1-1build2.1] (no packageset)
<mdeslaur> wxl: I guess this was the old repo: https://code.launchpad.net/~usb-creator-hackers/usb-creator/trunk
<mdeslaur> wxl: I can update it, give me a few minutes
<mdeslaur> wxl: repo updated
<bluesabre> Release upgrade question: We are replacing light-locker with xfce4-screensaver in Xubuntu for eoan. Since light-locker will continue to exist, would this file be what we would use to uninstall light-locker on upgrade from disco to eoan? https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/view/head:/data/DistUpgrade.cfg#L64
<Eickmeyer> bluesabre: I could be wrong, but you could actually put a "Conflits:" and "Replaces:" line in your debian/control file to force a removal of light-locker for people upgrading, if you wish to essentially depricate light-locker.
#ubuntu-release 2020-06-22
-queuebot:#ubuntu-release- New binary: dpdk [amd64] (groovy-proposed/main) [19.11.3-1] (ubuntu-server)
<cpaelzer> hi, chances are the arm builders are partially stuck in cleaning
<cpaelzer> I have in the past only seen this on other arches, but the view on https://launchpad.net/builders didn't change for quiite a while
<cpaelzer> if later on someone could give these a bump to make sure they are not stuck that would be great
<cpaelzer> sil2100: good morning, I've seen that you are on SRU duty today - I wanted to ask once you get to that if you could try to process qemu today. In particular for bug 1882774 which slowly but surely seems to be hit more widely
<ubot5> bug 1882774 in qemu (Ubuntu Focal) "issues with secondary VMX execution controls" [High,Triaged] https://launchpad.net/bugs/1882774
<cpaelzer> rbasak: as I pinged you for the same SRU to take a look at tonight ^^ FYI - as it only needs one of you :-)
<sil2100> cpaelzer: hey! Sure o/
-queuebot:#ubuntu-release- Unapproved: shadow (focal-proposed/main) [1:4.8.1-1ubuntu5 => 1:4.8.1-1ubuntu5.20.04] (core, i386-whitelist)
<RikMills> cpaelzer: builders look like buildd-manager has fallen over again. I have asked in #launchpad
-queuebot:#ubuntu-release- New binary: libqmi [s390x] (groovy-proposed/main) [1.26.0-0.1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libqmi [ppc64el] (groovy-proposed/main) [1.26.0-0.1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libqmi [arm64] (groovy-proposed/main) [1.26.0-0.1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: libqmi [armhf] (groovy-proposed/main) [1.26.0-0.1] (desktop-core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: ipe [s390x] (groovy-proposed/universe) [7.2.17-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dpdk [ppc64el] (groovy-proposed/main) [19.11.3-1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: dpdk [armhf] (groovy-proposed/main) [19.11.3-1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: dpdk [arm64] (groovy-proposed/main) [19.11.3-1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: ipe [arm64] (groovy-proposed/universe) [7.2.17-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ipe [armhf] (groovy-proposed/universe) [7.2.17-2] (no packageset)
<smb> apw, xenial/dahdi-linux is still blocked by that incorrectly treated as regr state of s390x failing (https://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#dahdi-linux)
-queuebot:#ubuntu-release- New binary: openscap [s390x] (groovy-proposed/universe) [1.2.17-0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: openscap [amd64] (groovy-proposed/universe) [1.2.17-0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: openscap [arm64] (groovy-proposed/universe) [1.2.17-0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: openscap [armhf] (groovy-proposed/universe) [1.2.17-0.1] (no packageset)
<cpaelzer> hi, due to finally resolving libbpf being available in Ubutnu the latest DPDK now built a few more (universe) packages likelibrte-pmd-af-xdp20.0 further a few PMDs around ifp/ipn
<cpaelzer> if an ubuntu-archive member is around I'd appreciate to accept that into Groovy from the new queue
<cpaelzer> when doing so - all of these new binaries will end up in universe even though the source is in main, not all binaries are
<cpaelzer> I thought I better mention, in case that is important when accepting from new
<cpaelzer> otherwise we will ahve a component mismatch for a few days until these packages will be demoted since nothing should hold them in main
<rbalint> doko, could you please drop r-cran-openmx and r-cran-semplot from groovy release pocket? they can stay in -proposed LP: #1884451
<ubot5> Launchpad bug 1884451 in r-cran-openmx (Ubuntu) "Please remove r-cran-openmx from groovy" [Undecided,New] https://launchpad.net/bugs/1884451
-queuebot:#ubuntu-release- New binary: ipe [ppc64el] (groovy-proposed/universe) [7.2.17-2] (no packageset)
<rbalint> ginggs, let's see first what happens when r-base is unlocked
<ginggs> rbalint: sure
-queuebot:#ubuntu-release- New binary: openscap [riscv64] (groovy-proposed/universe) [1.2.17-0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [s390x] (groovy-proposed/universe) [3.10.6+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: openscap [ppc64el] (groovy-proposed/universe) [1.2.17-0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: openscap [amd64] (groovy-proposed/universe) [1.2.17-0.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: openscap [s390x] (groovy-proposed/universe) [1.2.17-0.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: openscap [arm64] (groovy-proposed/universe) [1.2.17-0.1ubuntu1] (no packageset)
<juliank> oh um, I still have to bisect make on s390x to figure out what is breaking flatpak-builder
<juliank> this is the weirdest regression I've seen
<juliank> because it's echo to stdout failing with EPERM
<juliank> but if you echo to stderr first, it's fine, and it also only happens on s390x
<juliank> luckily it's easy to reproduce
-queuebot:#ubuntu-release- New binary: openscap [ppc64el] (groovy-proposed/universe) [1.2.17-0.1ubuntu1] (no packageset)
<juliank> but then make is packaged as 1.0 (native) with changes applied in .diff.gz, and it's a mess to bisect
-queuebot:#ubuntu-release- New binary: openscap [armhf] (groovy-proposed/universe) [1.2.17-0.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [amd64] (groovy-proposed/universe) [3.10.6+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (focal-proposed) [1:4.2-3ubuntu6.3]
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (eoan-proposed) [1:4.0+dfsg-0ubuntu9.8]
<cpaelzer> Thanks sil2100 !
<LocutusOfBorg> any ubuntu-archive can please NBS-proposed cleanup old binaries left on amd64: python-xmmsclient (from 0.8+dfsg-18.3ubuntu1)?
<LocutusOfBorg> it is now python3-xmmsclient :D
<sil2100> cpaelzer: yw!
<seb128> LocutusOfBorg, k, done now
<LocutusOfBorg> <3
<seb128> do we have a nbs-proposed report?
-queuebot:#ubuntu-release- New binary: petsc [amd64] (groovy-proposed/universe) [3.13.1+dfsg1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: openscap [riscv64] (groovy-proposed/universe) [1.2.17-0.1ubuntu1] (no packageset)
<LocutusOfBorg> seb128, https://people.canonical.com/~ubuntu-archive/nbs.html this one?
-queuebot:#ubuntu-release- New binary: petsc [s390x] (groovy-proposed/universe) [3.13.1+dfsg1-4] (no packageset)
<seb128> LocutusOfBorg, it doesn't include proposed, xmmsclient isn't listed
-queuebot:#ubuntu-release- Unapproved: postfix (focal-proposed/main) [3.4.10-1ubuntu1 => 3.4.13-0ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (focal-proposed) [3.9.1-1ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (eoan-proposed) [3.9.1-1ubuntu0.19.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (bionic-proposed) [3.9.1-1ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New binary: petsc [ppc64el] (groovy-proposed/universe) [3.13.1+dfsg1-4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: librsvg (focal-proposed/main) [2.48.2-1 => 2.48.7-1ubuntu0.20.04.1] (core, i386-whitelist)
<rbalint> could and archive-admin please drop r-cran-openmx and r-cran-semplot from groovy release pocket? they can stay in -proposed LP: #1884451
<ubot5> Launchpad bug 1884451 in r-cran-openmx (Ubuntu) "Please remove r-cran-openmx from groovy" [Undecided,New] https://launchpad.net/bugs/1884451
<seb128> rbalint, k
<coreycb> sil2100: hello, if you have any chance we have a couple of neutron SRUs we'd like to see if we can get reviewed for bug 1662324 and bug 1852221
<ubot5> bug 1662324 in neutron (Ubuntu Xenial) "linux bridge agent disables ipv6 before adding an ipv6 address" [Undecided,In progress] https://launchpad.net/bugs/1662324
<ubot5> bug 1852221 in neutron (Ubuntu Eoan) "ovs-vswitchd needs to be forced to reconfigure after adding protocols to bridges" [High,Triaged] https://launchpad.net/bugs/1852221
<rbalint> seb128, thanks!
<seb128> rbalint, np!
<rbalint> ddstreet, do you have systemd 245.4-4ubuntu3.1 commits to push to the ubuntu-focal branch or i should import the .dsc to queue fixes for next sru?
-queuebot:#ubuntu-release- New binary: qgis [s390x] (groovy-proposed/universe) [3.10.6+dfsg-1ubuntu1] (no packageset)
<sil2100> coreycb: hey! On it! Sorry, was rather over-committed during my previous shifts
<coreycb> sil2100: thanks!
<sil2100> coreycb: ok, the eoan one makes a sensible workaround, thanks o/
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (eoan-proposed) [2:15.0.2-0ubuntu1.2]
<seb128> sil2100, hey, could you also review gnutls28? (trivial diff, uploaded to focal/bionic/xenial)
<coreycb> thanks sil2100
<sil2100> seb128: sure o/
<seb128> thx
<sil2100> seb128: oh no! "There are no Launchpad bugs in the changelog!" when I tried to review the focal one
-queuebot:#ubuntu-release- Unapproved: cinder (focal-proposed/main) [2:16.0.0-0ubuntu0.20.04.1 => 2:16.1.0-0ubuntu1] (openstack, ubuntu-server)
<seb128> sil2100, oh, shrug, "lp: nnn" without #, thanks for catching that
<seb128> sil2100, reuploaded
-queuebot:#ubuntu-release- Unapproved: gnutls28 (focal-proposed/main) [3.6.13-2ubuntu1.1 => 3.6.13-2ubuntu1.2] (core, i386-whitelist)
<seb128> ^
<sil2100> o/
-queuebot:#ubuntu-release- Unapproved: rejected gnutls28 [source] (focal-proposed) [3.6.13-2ubuntu1.2]
<Laney> use dput-ng, then it won't let you upload those :>
-queuebot:#ubuntu-release- Unapproved: accepted gnutls28 [source] (focal-proposed) [3.6.13-2ubuntu1.2]
<seb128> Laney, ah; nice one
-queuebot:#ubuntu-release- Unapproved: accepted gnutls28 [source] (bionic-proposed) [3.5.18-1ubuntu1.4]
-queuebot:#ubuntu-release- Unapproved: aodh (eoan-proposed/main) [9.0.0-0ubuntu1 => 9.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted gnutls28 [source] (xenial-proposed) [3.4.10-4ubuntu1.8]
-queuebot:#ubuntu-release- New binary: qgis [ppc64el] (groovy-proposed/universe) [3.10.6+dfsg-1ubuntu1] (no packageset)
<seb128> sil2100, thanks!
<rbalint> ginggs, r-base is a valid candidate now, but update_output lists a lot of riscv64 packages and i'll work on other stuff in the next days :-\
-queuebot:#ubuntu-release- New binary: petsc [arm64] (groovy-proposed/universe) [3.13.1+dfsg1-4] (no packageset)
-queuebot:#ubuntu-release- New source: shim-canonical (groovy-proposed/primary) [1]
<LocutusOfBorg> rbalint, just in time for the new r-base in sid?
<LocutusOfBorg> unless somebody blacklists it...
<rbalint> LocutusOfBorg, at least with a much smaller version bump
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [source] (focal-proposed) [1.3.11-1~focal1]
<vorlon> we should certainly blacklist that for now
<vorlon> (done)
-queuebot:#ubuntu-release- Unapproved: accepted fwupd-signed [source] (focal-proposed) [1.27.1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-4ubuntu0.1 => 1.3.11-1~focal1] (core)
<sil2100> seb128: yw!
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-4ubuntu0.1 => 1.3.11-1~focal1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (focal-proposed/main) [1.3.9-4ubuntu0.1 => 1.3.11-1~focal1] (core)
-queuebot:#ubuntu-release- New binary: qgis [amd64] (groovy-proposed/universe) [3.10.6+dfsg-1ubuntu1] (no packageset)
<LocutusOfBorg> thanks
-queuebot:#ubuntu-release- New binary: petsc [armhf] (groovy-proposed/universe) [3.13.1+dfsg1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libomemo [amd64] (groovy-proposed/none) [0.6.2+git20200527.e3b212-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyfavicon [amd64] (groovy-proposed/none) [0.1.1+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: yanagiba [amd64] (groovy-proposed/none) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pyrle [amd64] (groovy-proposed/none) [0.0.31-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ffuf [amd64] (groovy-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ffuf [ppc64el] (groovy-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libomemo [ppc64el] (groovy-proposed/universe) [0.6.2+git20200527.e3b212-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-vega-datasets [amd64] (groovy-proposed/universe) [0.8+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ffuf [s390x] (groovy-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyrle [ppc64el] (groovy-proposed/universe) [0.0.31-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libomemo [s390x] (groovy-proposed/universe) [0.6.2+git20200527.e3b212-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyrle [s390x] (groovy-proposed/universe) [0.0.31-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ffuf [arm64] (groovy-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libomemo [arm64] (groovy-proposed/universe) [0.6.2+git20200527.e3b212-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ffuf [armhf] (groovy-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libomemo [armhf] (groovy-proposed/universe) [0.6.2+git20200527.e3b212-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyrle [arm64] (groovy-proposed/universe) [0.0.31-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pyrle [armhf] (groovy-proposed/universe) [0.0.31-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cinder (eoan-proposed/main) [2:15.1.0-0ubuntu1 => 2:15.2.0-1ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: libomemo [riscv64] (groovy-proposed/universe) [0.6.2+git20200527.e3b212-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: glance (eoan-proposed/main) [2:19.0.2-0ubuntu1 => 2:19.0.3-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: heat (eoan-proposed/main) [1:13.0.1-0ubuntu1 => 1:13.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: ffuf [riscv64] (groovy-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyrle [riscv64] (groovy-proposed/universe) [0.0.31-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: horizon (eoan-proposed/main) [3:16.1.0-0ubuntu1 => 3:16.2.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (eoan-proposed/main) [2:15.0.2-0ubuntu1.2 => 2:15.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nova (eoan-proposed/main) [2:20.2.0-0ubuntu1 => 2:20.3.0-0ubuntu1] (openstack, ubuntu-server)
<tjaalton> any kernel-reviewer available to promote focal:oem-5.6 to proposed? It's urgent for a Lenovo deadline
<tjaalton> and HP
-queuebot:#ubuntu-release- New binary: qgis [armhf] (groovy-proposed/universe) [3.10.6+dfsg-1ubuntu1] (no packageset)
<sergiusens> Laney: hey, was there a recent deploy to autopkgtest? I am getting 500s again when trying to trigger from GitHub PRs.
<sergiusens> recent, since week or two ago and now
<Laney> sergiusens: there's some kind of github outage affecting us atm
<Laney> I'm getting spammed about it
<Laney> githubstatus.com knows about it
<sergiusens> Laney: and now I do too! Thanks
-queuebot:#ubuntu-release- New binary: qgis [arm64] (groovy-proposed/universe) [3.10.6+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ffuf [riscv64] (groovy-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted pyrle [riscv64] (groovy-proposed) [0.0.31-2]
-queuebot:#ubuntu-release- New: accepted ffuf [arm64] (groovy-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted ffuf [s390x] (groovy-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted libomemo [armhf] (groovy-proposed) [0.6.2+git20200527.e3b212-1]
-queuebot:#ubuntu-release- New: accepted libomemo [riscv64] (groovy-proposed) [0.6.2+git20200527.e3b212-1]
-queuebot:#ubuntu-release- New: accepted pyrle [arm64] (groovy-proposed) [0.0.31-2]
-queuebot:#ubuntu-release- New: accepted pyrle [ppc64el] (groovy-proposed) [0.0.31-2]
-queuebot:#ubuntu-release- New: accepted python-vega-datasets [amd64] (groovy-proposed) [0.8+dfsg-1]
-queuebot:#ubuntu-release- New source: kwayland-server (groovy-proposed/primary) [5.19.1-0ubuntu1]
-queuebot:#ubuntu-release- New source: redkite (groovy-proposed/primary) [0.8.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ffuf [armhf] (groovy-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted libomemo [ppc64el] (groovy-proposed) [0.6.2+git20200527.e3b212-1]
-queuebot:#ubuntu-release- New: accepted pyrle [armhf] (groovy-proposed) [0.0.31-2]
-queuebot:#ubuntu-release- New source: add64 (groovy-proposed/primary) [3.9.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libomemo [arm64] (groovy-proposed) [0.6.2+git20200527.e3b212-1]
-queuebot:#ubuntu-release- New: accepted pyrle [s390x] (groovy-proposed) [0.0.31-2]
-queuebot:#ubuntu-release- New: accepted libomemo [s390x] (groovy-proposed) [0.6.2+git20200527.e3b212-1]
-queuebot:#ubuntu-release- New source: plasma-wayland-protocols (groovy-proposed/primary) [1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ffuf [amd64] (groovy-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted libomemo [amd64] (groovy-proposed) [0.6.2+git20200527.e3b212-1]
-queuebot:#ubuntu-release- New: accepted petsc [arm64] (groovy-proposed) [3.13.1+dfsg1-4]
-queuebot:#ubuntu-release- New: accepted petsc [ppc64el] (groovy-proposed) [3.13.1+dfsg1-4]
-queuebot:#ubuntu-release- New: accepted pyfavicon [amd64] (groovy-proposed) [0.1.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted qgis [amd64] (groovy-proposed) [3.10.6+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ffuf [ppc64el] (groovy-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted petsc [armhf] (groovy-proposed) [3.13.1+dfsg1-4]
-queuebot:#ubuntu-release- New: accepted pyrle [amd64] (groovy-proposed) [0.0.31-2]
-queuebot:#ubuntu-release- New: accepted petsc [amd64] (groovy-proposed) [3.13.1+dfsg1-4]
-queuebot:#ubuntu-release- New: accepted yanagiba [amd64] (groovy-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted petsc [s390x] (groovy-proposed) [3.13.1+dfsg1-4]
-queuebot:#ubuntu-release- New: accepted ipe [armhf] (groovy-proposed) [7.2.17-2]
-queuebot:#ubuntu-release- New: accepted openscap [amd64] (groovy-proposed) [1.2.17-0.1]
-queuebot:#ubuntu-release- New: accepted openscap [armhf] (groovy-proposed) [1.2.17-0.1]
-queuebot:#ubuntu-release- New: accepted openscap [riscv64] (groovy-proposed) [1.2.17-0.1]
-queuebot:#ubuntu-release- New: accepted qgis [s390x] (groovy-proposed) [3.10.6+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ipe [ppc64el] (groovy-proposed) [7.2.17-2]
-queuebot:#ubuntu-release- New: accepted openscap [ppc64el] (groovy-proposed) [1.2.17-0.1]
-queuebot:#ubuntu-release- New: accepted openscap [arm64] (groovy-proposed) [1.2.17-0.1]
-queuebot:#ubuntu-release- New: accepted openscap [s390x] (groovy-proposed) [1.2.17-0.1]
-queuebot:#ubuntu-release- New: accepted dpdk [arm64] (groovy-proposed) [19.11.3-1]
-queuebot:#ubuntu-release- New: accepted ipe [arm64] (groovy-proposed) [7.2.17-2]
-queuebot:#ubuntu-release- New: accepted dpdk [armhf] (groovy-proposed) [19.11.3-1]
-queuebot:#ubuntu-release- New: accepted dpdk [amd64] (groovy-proposed) [19.11.3-1]
-queuebot:#ubuntu-release- New: accepted ipe [s390x] (groovy-proposed) [7.2.17-2]
-queuebot:#ubuntu-release- New: accepted libqmi [armhf] (groovy-proposed) [1.26.0-0.1]
-queuebot:#ubuntu-release- New: accepted libqmi [s390x] (groovy-proposed) [1.26.0-0.1]
-queuebot:#ubuntu-release- New: accepted dpdk [ppc64el] (groovy-proposed) [19.11.3-1]
-queuebot:#ubuntu-release- New: accepted libqmi [ppc64el] (groovy-proposed) [1.26.0-0.1]
-queuebot:#ubuntu-release- New: accepted libqmi [arm64] (groovy-proposed) [1.26.0-0.1]
-queuebot:#ubuntu-release- New: accepted ipe [amd64] (groovy-proposed) [7.2.17-2]
-queuebot:#ubuntu-release- New: accepted libmbim [arm64] (groovy-proposed) [1.24.0-0.1]
-queuebot:#ubuntu-release- New: accepted libmbim [i386] (groovy-proposed) [1.24.0-0.1]
-queuebot:#ubuntu-release- New: accepted libmbim [riscv64] (groovy-proposed) [1.24.0-0.1]
-queuebot:#ubuntu-release- New: accepted libqmi [i386] (groovy-proposed) [1.26.0-0.1]
-queuebot:#ubuntu-release- New: accepted libmbim [amd64] (groovy-proposed) [1.24.0-0.1]
-queuebot:#ubuntu-release- New: accepted libmbim [ppc64el] (groovy-proposed) [1.24.0-0.1]
-queuebot:#ubuntu-release- New: accepted libmbim [armhf] (groovy-proposed) [1.24.0-0.1]
-queuebot:#ubuntu-release- New: accepted libqmi [amd64] (groovy-proposed) [1.26.0-0.1]
-queuebot:#ubuntu-release- New: accepted libmbim [s390x] (groovy-proposed) [1.24.0-0.1]
-queuebot:#ubuntu-release- New: accepted ruby-async-http [amd64] (groovy-proposed) [0.52.4-1]
-queuebot:#ubuntu-release- New binary: linux-signed-oem-5.6 [amd64] (focal-proposed/main) [5.6.0-1013.13] (no packageset)
-queuebot:#ubuntu-release- New binary: python-stem [amd64] (groovy-proposed/universe) [1.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nomad-driver-podman [amd64] (groovy-proposed/universe) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xmltooling [amd64] (groovy-proposed/universe) [3.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nomad-driver-podman [s390x] (groovy-proposed/universe) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xmltooling [s390x] (groovy-proposed/universe) [3.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nomad-driver-podman [arm64] (groovy-proposed/universe) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nomad-driver-podman [armhf] (groovy-proposed/universe) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xmltooling [arm64] (groovy-proposed/universe) [3.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: xmltooling [armhf] (groovy-proposed/universe) [3.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: xmltooling [ppc64el] (groovy-proposed/universe) [3.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nomad-driver-podman [ppc64el] (groovy-proposed/universe) [0.0.3-1] (no packageset)
#ubuntu-release 2020-06-23
-queuebot:#ubuntu-release- New binary: xmltooling [riscv64] (groovy-proposed/universe) [3.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-5.6 [amd64] (focal-proposed) [5.6.0-1013.13]
-queuebot:#ubuntu-release- New binary: libjson-rpc-common-perl [amd64] (groovy-proposed/universe) [0.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pytest-salt-factories [amd64] (groovy-proposed/universe) [0.10.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mindthegap [amd64] (groovy-proposed/universe) [2.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pychopper [amd64] (groovy-proposed/universe) [2.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-users [amd64] (groovy-proposed/universe) [0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syn-mid [amd64] (groovy-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syn-mid [arm64] (groovy-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-users [arm64] (groovy-proposed/universe) [0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syn-mid [armhf] (groovy-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-users [armhf] (groovy-proposed/universe) [0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mindthegap [s390x] (groovy-proposed/universe) [2.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-users [s390x] (groovy-proposed/universe) [0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syn-mid [s390x] (groovy-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: topcom [amd64] (groovy-proposed/universe) [0.17.8+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gri [arm64] (groovy-proposed/universe) [2.12.26-6] (no packageset)
-queuebot:#ubuntu-release- New binary: gri [ppc64el] (groovy-proposed/universe) [2.12.26-6] (no packageset)
-queuebot:#ubuntu-release- New binary: mindthegap [arm64] (groovy-proposed/universe) [2.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syn-mid [ppc64el] (groovy-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: topcom [s390x] (groovy-proposed/universe) [0.17.8+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gri [armhf] (groovy-proposed/universe) [2.12.26-6] (no packageset)
-queuebot:#ubuntu-release- New binary: mindthegap [ppc64el] (groovy-proposed/universe) [2.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gri [s390x] (groovy-proposed/universe) [2.12.26-6] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-users [ppc64el] (groovy-proposed/universe) [0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ace [s390x] (groovy-proposed/universe) [6.5.8+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: topcom [ppc64el] (groovy-proposed/universe) [0.17.8+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: topcom [armhf] (groovy-proposed/universe) [0.17.8+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ace [ppc64el] (groovy-proposed/universe) [6.5.8+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: topcom [arm64] (groovy-proposed/universe) [0.17.8+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ace [amd64] (groovy-proposed/universe) [6.5.8+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ace [armhf] (groovy-proposed/universe) [6.5.8+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-users [riscv64] (groovy-proposed/universe) [0.10.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ace [arm64] (groovy-proposed/universe) [6.5.8+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syn-mid [riscv64] (groovy-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mindthegap [riscv64] (groovy-proposed/universe) [2.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: topcom [riscv64] (groovy-proposed/universe) [0.17.8+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gri [riscv64] (groovy-proposed/universe) [2.12.26-6] (no packageset)
<cpaelzer> thanks for accepting dpdk from groovy-new whoever did it
<cpaelzer> as expected that accept pushed the new binaries to main as the source is in main
<cpaelzer> but as I wrote as heads up yesterday that isn't correct - they now show up in https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html
<cpaelzer> as Binary only movements to universe
<cpaelzer> If an ubuntu-archive member is around I'd appreciate demoting "librte-pmd-af-xdp20.0 librte-pmd-ipn3ke20.0 librte-rawdev-ifpga20.0" in groovy
<cpaelzer> that hopefully will then also unblock it in proposed migration where is is stuck due to these being considered a component mismatch
<RAOF> cpaelzer: Done.
-queuebot:#ubuntu-release- New binary: ace [riscv64] (groovy-proposed/universe) [6.5.8+dfsg-2] (no packageset)
<cpaelzer> thanks RAOF
<slyon> Hey! What is the best way to trigger a re-build of a package in groovy-proposed? The 'badger' armhf build failed, due to running out of memory. But version 2.0.3-1 is needed in order to satisfy the build/test dependencies... https://launchpad.net/ubuntu/+source/badger/2.0.3-1
<slyon> vorlon, badger is currently hinted as badtest, but I think this would not be needed anymore with 2.0.3-1 ^^^
<jibel> is anyone looking at libsane/libsane1? it's blocking groovy image builds.
<mwhudson> slyon: you get a core dev to retry it
<mwhudson> slyon: but is there any reason to think retrying it will work?
<slyon> mwhudson, It failed due to running out of memory... Which might have been related to overloaded armhf machines. This is why I think retrying might work
<mwhudson> slyon: err that's not how it works?
<mwhudson> slyon: the vms have the same ram size no matter the load, surely
<slyon> mwhudson, right... Let me figure out/fix the build via PPA. I'll be back here afterwards
<mwhudson> slyon: i mean, i'm happy to retry it, i just don't think it will help much
<mwhudson> (it's only a three minute build)
<slyon> mwhudson, thanks. your points are totally right. Let me figure out what is going on in detail before we proceed.
<Laney> jibel: see ubuntu-devel
<LocutusOfBorg> vorlon, FYI I have a util-linux merge ready, it is needed because of new binaries used in the archive, and autopkgtests fixes
<LocutusOfBorg> I can ppa it, or go for the archive whatever you prefer
<ginggs> rbalint: where in update_output do you see lots of riscv64 packages?
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-435 (bionic-proposed/restricted) [435.21-0ubuntu0.18.04.2 => 435.21-0ubuntu0.18.04.3] (no packageset)
-queuebot:#ubuntu-release- New source: oem-stella.cmit-abra-meta (focal-proposed/primary) [20.04~ubuntu2]
<LocutusOfBorg> meh, uploading :)
-queuebot:#ubuntu-release- New binary: util-linux [s390x] (groovy-proposed/main) [2.35.2-4ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: util-linux [ppc64el] (groovy-proposed/main) [2.35.2-4ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: util-linux [amd64] (groovy-proposed/main) [2.35.2-4ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: util-linux [armhf] (groovy-proposed/main) [2.35.2-4ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: util-linux [arm64] (groovy-proposed/main) [2.35.2-4ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: util-linux [i386] (groovy-proposed/main) [2.35.2-4ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: mindthegap [amd64] (groovy-proposed/universe) [2.2.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syn-mid [ppc64el] (groovy-proposed/universe) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mindthegap [s390x] (groovy-proposed/universe) [2.2.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syn-mid [s390x] (groovy-proposed/universe) [0.5.0-2] (no packageset)
<mwhudson> ubuntu-archive: if you're bored ... https://bugs.launchpad.net/ubuntu/+source/continuity/+bug/1884749
<ubot5> Ubuntu bug 1884749 in continuity (Ubuntu) "please remove continuity binary package" [Undecided,New]
-queuebot:#ubuntu-release- New binary: mindthegap [ppc64el] (groovy-proposed/universe) [2.2.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syn-mid [amd64] (groovy-proposed/universe) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syn-mid [armhf] (groovy-proposed/universe) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pychopper [amd64] (groovy-proposed/universe) [2.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syn-mid [arm64] (groovy-proposed/universe) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mindthegap [arm64] (groovy-proposed/universe) [2.2.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syn-mid [riscv64] (groovy-proposed/universe) [0.5.0-2] (no packageset)
<seb128> mwhudson, there was already no such binary in focal? https://launchpad.net/ubuntu/+source/continuity/0.0~git20200107.26c1120-1/+build/18570241
<mwhudson> seb128: i think it's been in proposed since before focal was released?
<seb128> mwhudson, https://launchpad.net/ubuntu/+source/continuity state that it was in focal proper
<seb128> it's weird
<mwhudson> seb128: but that was https://launchpad.net/ubuntu/+source/continuity/0.0~git20180216.d8fb858-1
<mwhudson> not git2020*
<seb128> ah
<seb128> mwhudson, k, done now
<mwhudson> seb128: thanks
<seb128> yw!
-queuebot:#ubuntu-release- New binary: mindthegap [riscv64] (groovy-proposed/universe) [2.2.2-2] (no packageset)
<mwhudson> seb128: the justification on the debian side seems a bit strange too https://salsa.debian.org/go-team/packages/continuity/-/commit/ed134750b8a3c8a6099909e8c604d5c92cf60cfa
<mwhudson> but oh well, don't care and going to bed
-queuebot:#ubuntu-release- New binary: nodejs [amd64] (groovy-proposed/universe) [12.18.0~dfsg-3ubuntu1] (kubuntu)
<mwhudson> seb128: um
<mwhudson> seb128: i wanted to remove the "continuity" *binary* packages
<mwhudson> from release
<mwhudson> not the continuity source package from proposed
<mwhudson> sorry if i should have been clearer
 * mwhudson zzz
<seb128> mwhudson, arg, my fault, I'll fix it, have a good night!
-queuebot:#ubuntu-release- New binary: nodejs [s390x] (groovy-proposed/universe) [12.18.0~dfsg-3ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: nodejs [ppc64el] (groovy-proposed/universe) [12.18.0~dfsg-3ubuntu1] (kubuntu)
<coreycb> RAOF: hello, would you be able to reject cinder from the eoan and focal unapproved queues please? we have some further updates to do with those.
<ginggs> ubuntu-archive: would someone please kick gff2aplot/2.0-13 and libgclib/0.11.9-1 from -proposed?  they break gffread in different ways and are blocking r-base migration
<seb128> coreycb, do you need RAOF to do that only or any archive admin? (he's probably eod now)
<coreycb> seb128: thanks for your reply. an archive admin would be fine.
-queuebot:#ubuntu-release- Unapproved: rejected cinder [source] (eoan-proposed) [2:15.2.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected cinder [source] (focal-proposed) [2:16.1.0-0ubuntu1]
<seb128> coreycb, ^
<coreycb> seb128: thanks (icey  fyi ^)
<coreycb> until we get os-brick sorted
<icey> coreycb: k
<seb128> ginggs, k, done
-queuebot:#ubuntu-release- Unapproved: gnome-desktop3 (focal-proposed/main) [3.36.2-0ubuntu2 => 3.36.3.1-0ubuntu1] (ubuntu-desktop)
<ginggs> seb128: thanks!
-queuebot:#ubuntu-release- New binary: nodejs [arm64] (groovy-proposed/universe) [12.18.0~dfsg-3ubuntu1] (kubuntu)
<ddstreet> rbalint sorry i was out yesterday; nope i don't have any patches queued up yet for systemd in focal, thnx for asking!
<rbalint> ddstreet, np, thanks, i'll import the .dsc then
<rbalint> ddstreet, i'd like to use the repo branches for queueing things for srus no not forget about fixes easily
<ddstreet> in ~ubuntu-core-dev?  that works for me, if you don't mind me pushing there to get them up to date when i have patch?
<ddstreet> it would be nice if git-ubuntu could somehow 'integrate' with offical git repos, not sure if rbasak is thinking of how that might be possible
<rbasak> It's sort of possible, but I'm not sure if there are fairly permanent negative implications so I've been avoiding advising about that
<rbasak> The problem is that the git-ubuntu branches must represent the single source of truth that is Launchpad for it to be useful, but that's not guaranteed in anything else that developers push to
<ahasenack> what does gbp do? It just trusts the vcs tags in d/control and adds an upstream branch for that?
-queuebot:#ubuntu-release- New binary: nodejs [armhf] (groovy-proposed/universe) [12.18.0~dfsg-3ubuntu1] (kubuntu)
<bdmurray> sil2100, Laney: Have you seen these groovy livefs build failures?
-queuebot:#ubuntu-release- Unapproved: haproxy (bionic-proposed/main) [1.8.8-1ubuntu0.10 => 1.8.8-1ubuntu0.11] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: open-vm-tools (focal-proposed/main) [2:11.0.5-4 => 2:11.1.0-2~ubuntu20.04.1] (edubuntu, ubuntu-cloud, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (focal-proposed) [2.45.1+20.04]
-queuebot:#ubuntu-release- Unapproved: glib-networking (bionic-proposed/main) [2.56.0-1 => 2.56.1-0ubuntu1] (ubuntu-desktop)
<Laney> bdmurray: yep, should be fixed
-queuebot:#ubuntu-release- Unapproved: gnome-calendar (focal-proposed/main) [3.36.1-1 => 3.36.2-0ubuntu1] (desktop-extra, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (focal-proposed/main) [1:3.36.2-0ubuntu1 => 1:3.36.3-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (focal-proposed/main) [1:0.8.1.1 => 1:0.8.4~0.20.04.1] (desktop-core, ubuntu-server)
<RikMills> vorlon: would you perhaps be able to look at plasma-wayland-protocal and kwayland-server in NEW? LP: #1883501 LP: #1884120
<ubot5> Launchpad bug 1883501 in Ubuntu Groovy "[needs-packaging] plasma-wayland-protocols" [Wishlist,Fix committed] https://launchpad.net/bugs/1883501
<ubot5> Launchpad bug 1884120 in Ubuntu Groovy "[needs-packaging] kwayland-server" [Wishlist,Fix committed] https://launchpad.net/bugs/1884120
<LocutusOfBorg> bdmurray, can you please try again? the colord fixed package migrated some seconds ago
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.45.1]
-queuebot:#ubuntu-release- Unapproved: rejected postfix [source] (focal-proposed) [3.4.11-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ccls [source] (focal-proposed) [0.20190823.6-1~ubuntu1.20.04.1]
-queuebot:#ubuntu-release- New binary: angelscript [s390x] (groovy-proposed/universe) [2.34.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.45.1+18.04]
-queuebot:#ubuntu-release- Unapproved: accepted evince [source] (focal-proposed) [3.36.5-0ubuntu1]
-queuebot:#ubuntu-release- New binary: angelscript [ppc64el] (groovy-proposed/universe) [2.34.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fdb [amd64] (groovy-proposed/universe) [2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: angelscript [amd64] (groovy-proposed/universe) [2.34.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libinfinity [s390x] (groovy-proposed/universe) [0.7.1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libinfinity [ppc64el] (groovy-proposed/universe) [0.7.1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: bgpq4 [s390x] (groovy-proposed/universe) [0.0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vsearch [ppc64el] (groovy-proposed/universe) [2.14.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libinfinity [amd64] (groovy-proposed/universe) [0.7.1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: bgpq4 [ppc64el] (groovy-proposed/universe) [0.0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libvdeslirp [s390x] (groovy-proposed/universe) [0.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libmatio [s390x] (groovy-proposed/universe) [1.5.17-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libvdestack [s390x] (groovy-proposed/universe) [0.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: babeltrace2 [s390x] (groovy-proposed/universe) [2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-shurcool-gopherjslib [amd64] (groovy-proposed/universe) [0.0~git20200209.30f639d-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpog [amd64] (groovy-proposed/universe) [0.5.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libvdestack [amd64] (groovy-proposed/universe) [0.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: persist-el [amd64] (groovy-proposed/universe) [0.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-injector [amd64] (groovy-proposed/universe) [0.18.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bgpq4 [amd64] (groovy-proposed/universe) [0.0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libvdeslirp [ppc64el] (groovy-proposed/universe) [0.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: phosh [s390x] (groovy-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: helpdev [amd64] (groovy-proposed/universe) [0.6.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libvdestack [ppc64el] (groovy-proposed/universe) [0.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: phoenix-firmware [amd64] (groovy-proposed/universe) [4.7.4+repack-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-rx [amd64] (groovy-proposed/universe) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: starpu [s390x] (groovy-proposed/universe) [1.3.4+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: phosh [amd64] (groovy-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vsearch [amd64] (groovy-proposed/universe) [2.14.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-packable [amd64] (groovy-proposed/universe) [1.3.14-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-av [amd64] (groovy-proposed/universe) [8.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: babeltrace2 [ppc64el] (groovy-proposed/universe) [2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: starpu [ppc64el] (groovy-proposed/universe) [1.3.4+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: babeltrace2 [amd64] (groovy-proposed/universe) [2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-jest [amd64] (groovy-proposed/universe) [24.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libvdeslirp [amd64] (groovy-proposed/universe) [0.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: phosh [ppc64el] (groovy-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bgpq4 [riscv64] (groovy-proposed/universe) [0.0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmatio [ppc64el] (groovy-proposed/universe) [1.5.17-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libmatio [amd64] (groovy-proposed/universe) [1.5.17-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libvdeslirp [riscv64] (groovy-proposed/universe) [0.1.0-2] (no packageset)
<vorlon> LocutusOfBorg: not much value in a util-linux merge if we can't get it building on riscv64?
<vorlon> slyon: there's not much need for dropping those hints, either; especially since it's a force-reset-test hint, it becomes a no-op once a newer version of the package has tests that start to pass
-queuebot:#ubuntu-release- New binary: angelscript [arm64] (groovy-proposed/universe) [2.34.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: starpu [amd64] (groovy-proposed/universe) [1.3.4+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: angelscript [armhf] (groovy-proposed/universe) [2.34.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: angelscript [riscv64] (groovy-proposed/universe) [2.34.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libinfinity [arm64] (groovy-proposed/universe) [0.7.1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: bgpq4 [arm64] (groovy-proposed/universe) [0.0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libinfinity [armhf] (groovy-proposed/universe) [0.7.1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: bgpq4 [armhf] (groovy-proposed/universe) [0.0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libvdeslirp [armhf] (groovy-proposed/universe) [0.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libvdeslirp [arm64] (groovy-proposed/universe) [0.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libvdestack [armhf] (groovy-proposed/universe) [0.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libvdestack [arm64] (groovy-proposed/universe) [0.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: openstructure [amd64] (groovy-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: astra-toolbox [amd64] (groovy-proposed/multiverse) [1.8.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: phosh [arm64] (groovy-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: phosh [armhf] (groovy-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: babeltrace2 [arm64] (groovy-proposed/universe) [2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-av [armhf] (groovy-proposed/universe) [8.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: babeltrace2 [armhf] (groovy-proposed/universe) [2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libmatio [arm64] (groovy-proposed/universe) [1.5.17-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libmatio [armhf] (groovy-proposed/universe) [1.5.17-4] (no packageset)
-queuebot:#ubuntu-release- New binary: starpu [arm64] (groovy-proposed/universe) [1.3.4+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: starpu [armhf] (groovy-proposed/universe) [1.3.4+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (focal-proposed) [15.2.3-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New binary: babeltrace2 [riscv64] (groovy-proposed/universe) [2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: qtwebengine-opensource-src (focal-proposed/universe) [5.12.8+dfsg-0ubuntu1 => 5.12.8+dfsg-0ubuntu1.1] (kubuntu)
-queuebot:#ubuntu-release- New binary: python-av [riscv64] (groovy-proposed/universe) [8.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libinfinity [riscv64] (groovy-proposed/universe) [0.7.1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libmatio [riscv64] (groovy-proposed/universe) [1.5.17-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted babeltrace2 [riscv64] (groovy-proposed) [2.0.1-2]
-queuebot:#ubuntu-release- New: accepted libmatio [riscv64] (groovy-proposed) [1.5.17-4]
-queuebot:#ubuntu-release- New: accepted starpu [arm64] (groovy-proposed) [1.3.4+dfsg-2]
-queuebot:#ubuntu-release- New binary: openscap [s390x] (groovy-proposed/universe) [1.2.17-0.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libinfinity [riscv64] (groovy-proposed) [0.7.1-4]
-queuebot:#ubuntu-release- New: accepted starpu [armhf] (groovy-proposed) [1.3.4+dfsg-2]
-queuebot:#ubuntu-release- New: accepted python-av [riscv64] (groovy-proposed) [8.0.1-1]
-queuebot:#ubuntu-release- New: accepted angelscript [arm64] (groovy-proposed) [2.34.0+ds-2]
-queuebot:#ubuntu-release- New: accepted angelscript [riscv64] (groovy-proposed) [2.34.0+ds-2]
-queuebot:#ubuntu-release- New: accepted babeltrace2 [arm64] (groovy-proposed) [2.0.1-2]
-queuebot:#ubuntu-release- New: accepted bgpq4 [arm64] (groovy-proposed) [0.0.6-1]
-queuebot:#ubuntu-release- New: accepted libinfinity [arm64] (groovy-proposed) [0.7.1-4]
-queuebot:#ubuntu-release- New: accepted libmatio [arm64] (groovy-proposed) [1.5.17-4]
-queuebot:#ubuntu-release- New: accepted libvdeslirp [arm64] (groovy-proposed) [0.1.0-2]
-queuebot:#ubuntu-release- New: accepted libvdestack [arm64] (groovy-proposed) [0.1.0-2]
-queuebot:#ubuntu-release- New: accepted openstructure [amd64] (groovy-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted phosh [armhf] (groovy-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted angelscript [armhf] (groovy-proposed) [2.34.0+ds-2]
-queuebot:#ubuntu-release- New: accepted babeltrace2 [armhf] (groovy-proposed) [2.0.1-2]
-queuebot:#ubuntu-release- New: accepted libinfinity [armhf] (groovy-proposed) [0.7.1-4]
-queuebot:#ubuntu-release- New: accepted libvdeslirp [armhf] (groovy-proposed) [0.1.0-2]
-queuebot:#ubuntu-release- New: accepted phosh [arm64] (groovy-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted starpu [amd64] (groovy-proposed) [1.3.4+dfsg-2]
-queuebot:#ubuntu-release- New binary: mindthegap [amd64] (groovy-proposed/universe) [2.2.2-2] (no packageset)
-queuebot:#ubuntu-release- New source: redkite (groovy-proposed/primary) [0.8.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: rust-syn-mid [s390x] (groovy-proposed/universe) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: util-linux [i386] (groovy-proposed/main) [2.35.2-4ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New: accepted astra-toolbox [amd64] (groovy-proposed) [1.8.3-1]
-queuebot:#ubuntu-release- New: accepted libmatio [armhf] (groovy-proposed) [1.5.17-4]
-queuebot:#ubuntu-release- New: accepted python-av [armhf] (groovy-proposed) [8.0.1-1]
-queuebot:#ubuntu-release- New binary: mindthegap [s390x] (groovy-proposed/universe) [2.2.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: util-linux [arm64] (groovy-proposed/main) [2.35.2-4ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New: accepted bgpq4 [armhf] (groovy-proposed) [0.0.6-1]
-queuebot:#ubuntu-release- New source: add64 (groovy-proposed/primary) [3.9.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libvdestack [armhf] (groovy-proposed) [0.1.0-2]
-queuebot:#ubuntu-release- New binary: rust-syn-mid [ppc64el] (groovy-proposed/universe) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted babeltrace2 [amd64] (groovy-proposed) [2.0.1-2]
-queuebot:#ubuntu-release- New: accepted bgpq4 [riscv64] (groovy-proposed) [0.0.6-1]
-queuebot:#ubuntu-release- New: accepted helpdev [amd64] (groovy-proposed) [0.6.10-1]
-queuebot:#ubuntu-release- New: accepted libmatio [ppc64el] (groovy-proposed) [1.5.17-4]
-queuebot:#ubuntu-release- New: accepted libvdeslirp [riscv64] (groovy-proposed) [0.1.0-2]
-queuebot:#ubuntu-release- New: accepted libvdestack [ppc64el] (groovy-proposed) [0.1.0-2]
-queuebot:#ubuntu-release- New: accepted phoenix-firmware [amd64] (groovy-proposed) [4.7.4+repack-1]
-queuebot:#ubuntu-release- New: accepted phosh [ppc64el] (groovy-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted python-av [amd64] (groovy-proposed) [8.0.1-1]
-queuebot:#ubuntu-release- New: accepted python-rx [amd64] (groovy-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted babeltrace2 [ppc64el] (groovy-proposed) [2.0.1-2]
-queuebot:#ubuntu-release- New: accepted libmatio [amd64] (groovy-proposed) [1.5.17-4]
-queuebot:#ubuntu-release- New: accepted libvdestack [amd64] (groovy-proposed) [0.1.0-2]
-queuebot:#ubuntu-release- New: accepted phosh [amd64] (groovy-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted python-injector [amd64] (groovy-proposed) [0.18.3-1]
-queuebot:#ubuntu-release- New: accepted starpu [ppc64el] (groovy-proposed) [1.3.4+dfsg-2]
-queuebot:#ubuntu-release- New: accepted vsearch [amd64] (groovy-proposed) [2.14.2-3]
-queuebot:#ubuntu-release- New binary: gri [arm64] (groovy-proposed/universe) [2.12.26-6] (no packageset)
-queuebot:#ubuntu-release- New binary: gri [ppc64el] (groovy-proposed/universe) [2.12.26-6] (no packageset)
-queuebot:#ubuntu-release- New binary: topcom [armhf] (groovy-proposed/universe) [0.17.8+ds-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-shurcool-gopherjslib [amd64] (groovy-proposed) [0.0~git20200209.30f639d-1]
-queuebot:#ubuntu-release- New: accepted node-jest [amd64] (groovy-proposed) [24.9.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-packable [amd64] (groovy-proposed) [1.3.14-1]
-queuebot:#ubuntu-release- New binary: ace [s390x] (groovy-proposed/universe) [6.5.8+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mindthegap [ppc64el] (groovy-proposed/universe) [2.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: topcom [s390x] (groovy-proposed/universe) [0.17.8+ds-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libvdeslirp [amd64] (groovy-proposed) [0.1.0-2]
-queuebot:#ubuntu-release- New: accepted starpu [s390x] (groovy-proposed) [1.3.4+dfsg-2]
-queuebot:#ubuntu-release- New binary: topcom [ppc64el] (groovy-proposed/universe) [0.17.8+ds-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted phosh [s390x] (groovy-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New binary: gri [armhf] (groovy-proposed/universe) [2.12.26-6] (no packageset)
-queuebot:#ubuntu-release- New: accepted angelscript [amd64] (groovy-proposed) [2.34.0+ds-2]
-queuebot:#ubuntu-release- New: accepted angelscript [s390x] (groovy-proposed) [2.34.0+ds-2]
-queuebot:#ubuntu-release- New: accepted bgpq4 [amd64] (groovy-proposed) [0.0.6-1]
-queuebot:#ubuntu-release- New: accepted bgpq4 [s390x] (groovy-proposed) [0.0.6-1]
-queuebot:#ubuntu-release- New: accepted libinfinity [amd64] (groovy-proposed) [0.7.1-4]
-queuebot:#ubuntu-release- New: accepted libinfinity [s390x] (groovy-proposed) [0.7.1-4]
-queuebot:#ubuntu-release- New: accepted libpog [amd64] (groovy-proposed) [0.5.3-1]
-queuebot:#ubuntu-release- New: accepted libvdeslirp [s390x] (groovy-proposed) [0.1.0-2]
-queuebot:#ubuntu-release- New: accepted mindthegap [riscv64] (groovy-proposed) [2.2.2-2]
-queuebot:#ubuntu-release- New: accepted rust-syn-mid [riscv64] (groovy-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted angelscript [ppc64el] (groovy-proposed) [2.34.0+ds-2]
-queuebot:#ubuntu-release- New: accepted bgpq4 [ppc64el] (groovy-proposed) [0.0.6-1]
-queuebot:#ubuntu-release- New: accepted libinfinity [ppc64el] (groovy-proposed) [0.7.1-4]
-queuebot:#ubuntu-release- New: accepted libvdeslirp [ppc64el] (groovy-proposed) [0.1.0-2]
-queuebot:#ubuntu-release- New: accepted persist-el [amd64] (groovy-proposed) [0.4+dfsg-1]
-queuebot:#ubuntu-release- New binary: libjson-rpc-common-perl [amd64] (groovy-proposed/universe) [0.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nomad-driver-podman [ppc64el] (groovy-proposed/universe) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xmltooling [arm64] (groovy-proposed/universe) [3.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: xmltooling [riscv64] (groovy-proposed/universe) [3.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted babeltrace2 [s390x] (groovy-proposed) [2.0.1-2]
-queuebot:#ubuntu-release- New: accepted libmatio [s390x] (groovy-proposed) [1.5.17-4]
-queuebot:#ubuntu-release- New: accepted vsearch [ppc64el] (groovy-proposed) [2.14.2-3]
-queuebot:#ubuntu-release- New binary: pytest-salt-factories [amd64] (groovy-proposed/universe) [0.10.7-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted fdb [amd64] (groovy-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- New binary: mindthegap [amd64] (groovy-proposed/universe) [2.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libvdestack [s390x] (groovy-proposed) [0.1.0-2]
-queuebot:#ubuntu-release- New binary: xmltooling [ppc64el] (groovy-proposed/universe) [3.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted bsdmainutils [amd64] (groovy-proposed) [12.1.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted bsdmainutils [armhf] (groovy-proposed) [12.1.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted bsdmainutils [ppc64el] (groovy-proposed) [12.1.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted bsdmainutils [s390x] (groovy-proposed) [12.1.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted bsdmainutils [arm64] (groovy-proposed) [12.1.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted bsdmainutils [riscv64] (groovy-proposed) [12.1.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted bsdmainutils [i386] (groovy-proposed) [12.1.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted ace [riscv64] (groovy-proposed) [6.5.8+dfsg-2]
-queuebot:#ubuntu-release- New: accepted mindthegap [amd64] (groovy-proposed) [2.2.2-2]
-queuebot:#ubuntu-release- New: accepted mindthegap [ppc64el] (groovy-proposed) [2.2.2-2]
-queuebot:#ubuntu-release- New: accepted pychopper [amd64] (groovy-proposed) [2.4.0-2]
-queuebot:#ubuntu-release- New: accepted rust-syn-mid [arm64] (groovy-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted rust-syn-mid [ppc64el] (groovy-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New source: cd-boot-images-amd64 (groovy-proposed/primary) [4]
-queuebot:#ubuntu-release- New binary: openscap [arm64] (groovy-proposed/universe) [1.2.17-0.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: openscap [ppc64el] (groovy-proposed/universe) [1.2.17-0.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: openscap [s390x] (groovy-proposed/universe) [1.2.17-0.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gri [riscv64] (groovy-proposed) [2.12.26-6]
-queuebot:#ubuntu-release- New: accepted mindthegap [s390x] (groovy-proposed) [2.2.2-2]
-queuebot:#ubuntu-release- New: accepted rust-syn-mid [armhf] (groovy-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New binary: openscap [amd64] (groovy-proposed/universe) [1.2.17-0.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: openscap [riscv64] (groovy-proposed/universe) [1.2.17-0.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted mindthegap [arm64] (groovy-proposed) [2.2.2-2]
-queuebot:#ubuntu-release- New: accepted rust-syn-mid [s390x] (groovy-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New binary: qgis [s390x] (groovy-proposed/universe) [3.10.6+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-syn-mid [amd64] (groovy-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New binary: openscap [armhf] (groovy-proposed/universe) [1.2.17-0.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ace [amd64] (groovy-proposed) [6.5.8+dfsg-2]
-queuebot:#ubuntu-release- New: accepted ace [armhf] (groovy-proposed) [6.5.8+dfsg-2]
-queuebot:#ubuntu-release- New: accepted ace [s390x] (groovy-proposed) [6.5.8+dfsg-2]
-queuebot:#ubuntu-release- New: accepted gri [armhf] (groovy-proposed) [2.12.26-6]
-queuebot:#ubuntu-release- New: accepted mindthegap [ppc64el] (groovy-proposed) [2.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-syn-mid [riscv64] (groovy-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted topcom [arm64] (groovy-proposed) [0.17.8+ds-1]
-queuebot:#ubuntu-release- New: accepted topcom [ppc64el] (groovy-proposed) [0.17.8+ds-1]
-queuebot:#ubuntu-release- New: accepted topcom [s390x] (groovy-proposed) [0.17.8+ds-1]
-queuebot:#ubuntu-release- New: accepted ace [arm64] (groovy-proposed) [6.5.8+dfsg-2]
-queuebot:#ubuntu-release- New: accepted gri [arm64] (groovy-proposed) [2.12.26-6]
-queuebot:#ubuntu-release- New: accepted mindthegap [riscv64] (groovy-proposed) [2.2.2-1]
-queuebot:#ubuntu-release- New: accepted topcom [armhf] (groovy-proposed) [0.17.8+ds-1]
-queuebot:#ubuntu-release- New: accepted ace [ppc64el] (groovy-proposed) [6.5.8+dfsg-2]
-queuebot:#ubuntu-release- New: accepted rust-users [riscv64] (groovy-proposed) [0.10.0-1]
-queuebot:#ubuntu-release- New: accepted gri [ppc64el] (groovy-proposed) [2.12.26-6]
-queuebot:#ubuntu-release- New: accepted topcom [riscv64] (groovy-proposed) [0.17.8+ds-1]
-queuebot:#ubuntu-release- New: accepted gri [s390x] (groovy-proposed) [2.12.26-6]
-queuebot:#ubuntu-release- New: accepted mindthegap [s390x] (groovy-proposed) [2.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-syn-mid [armhf] (groovy-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-syn-mid [s390x] (groovy-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-users [arm64] (groovy-proposed) [0.10.0-1]
-queuebot:#ubuntu-release- New: accepted rust-users [ppc64el] (groovy-proposed) [0.10.0-1]
-queuebot:#ubuntu-release- New: accepted topcom [amd64] (groovy-proposed) [0.17.8+ds-1]
-queuebot:#ubuntu-release- New: accepted mindthegap [arm64] (groovy-proposed) [2.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-syn-mid [ppc64el] (groovy-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-users [armhf] (groovy-proposed) [0.10.0-1]
-queuebot:#ubuntu-release- New: accepted rust-syn-mid [arm64] (groovy-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-users [s390x] (groovy-proposed) [0.10.0-1]
-queuebot:#ubuntu-release- New: accepted rust-users [amd64] (groovy-proposed) [0.10.0-1]
-queuebot:#ubuntu-release- New: accepted libjson-rpc-common-perl [amd64] (groovy-proposed) [0.11-1]
-queuebot:#ubuntu-release- New: accepted nomad-driver-podman [ppc64el] (groovy-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted pytest-salt-factories [amd64] (groovy-proposed) [0.10.7-1]
-queuebot:#ubuntu-release- New: accepted xmltooling [arm64] (groovy-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted xmltooling [riscv64] (groovy-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted mindthegap [amd64] (groovy-proposed) [2.2.2-1]
-queuebot:#ubuntu-release- New: accepted rust-syn-mid [amd64] (groovy-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted pychopper [amd64] (groovy-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted xmltooling [ppc64el] (groovy-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted nomad-driver-podman [amd64] (groovy-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted nomad-driver-podman [armhf] (groovy-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted python-stem [amd64] (groovy-proposed) [1.8.0-1]
-queuebot:#ubuntu-release- New: accepted xmltooling [armhf] (groovy-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted nomad-driver-podman [arm64] (groovy-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted xmltooling [amd64] (groovy-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted nomad-driver-podman [s390x] (groovy-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted xmltooling [s390x] (groovy-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted openscap [amd64] (groovy-proposed) [1.2.17-0.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted openscap [s390x] (groovy-proposed) [1.2.17-0.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted openscap [arm64] (groovy-proposed) [1.2.17-0.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted openscap [armhf] (groovy-proposed) [1.2.17-0.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted openscap [riscv64] (groovy-proposed) [1.2.17-0.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted openscap [ppc64el] (groovy-proposed) [1.2.17-0.1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [amd64] (groovy-proposed) [3.10.6+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [armhf] (groovy-proposed) [3.10.6+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [s390x] (groovy-proposed) [3.10.6+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [arm64] (groovy-proposed) [3.10.6+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [ppc64el] (groovy-proposed) [3.10.6+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted shadow [source] (focal-proposed) [1:4.8.1-1ubuntu5.20.04]
-queuebot:#ubuntu-release- Unapproved: fwupd-signed (bionic-proposed/main) [1.10~ubuntu18.04.4 => 1.10~ubuntu18.04.5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fwupd-signed (eoan-proposed/main) [1.10.3ubuntu1 => 1.10.3ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (bionic-proposed/main) [1.2.10-1ubuntu2~ubuntu18.04.5 => 1.2.13-0~bionic1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (eoan-proposed/main) [1.2.10-1ubuntu4.1 => 1.2.13-0~eoan1] (core)
-queuebot:#ubuntu-release- New binary: qdarkstyle [amd64] (groovy-proposed/universe) [2.8.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-applets [source] (focal-proposed) [3.36.4-0ubuntu1]
<rafaeldtinoco> vlan is currently being blocked by linux-riscv
<rafaeldtinoco> should I do anything there ?
-queuebot:#ubuntu-release- Unapproved: accepted glib2.0 [source] (focal-proposed) [2.64.3-1~ubuntu20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted libgphoto2 [source] (focal-proposed) [2.5.25-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (focal-proposed) [19.03.8-0ubuntu1.20.04]
-queuebot:#ubuntu-release- New binary: mplcursors [amd64] (groovy-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nanofilt [arm64] (groovy-proposed/universe) [2.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nanofilt [ppc64el] (groovy-proposed/universe) [2.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: prometheus-tplink-plug-exporter [amd64] (groovy-proposed/universe) [0.2.0+git20200622.cc4a731-1] (no packageset)
-queuebot:#ubuntu-release- New binary: prometheus-tplink-plug-exporter [s390x] (groovy-proposed/universe) [0.2.0+git20200622.cc4a731-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nanofilt [amd64] (groovy-proposed/universe) [2.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nanofilt [s390x] (groovy-proposed/universe) [2.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qdarkstyle [amd64] (groovy-proposed/universe) [2.8.1+ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nanofilt [armhf] (groovy-proposed/universe) [2.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: prometheus-tplink-plug-exporter [ppc64el] (groovy-proposed/universe) [0.2.0+git20200622.cc4a731-1] (no packageset)
-queuebot:#ubuntu-release- New binary: prometheus-tplink-plug-exporter [armhf] (groovy-proposed/universe) [0.2.0+git20200622.cc4a731-1] (no packageset)
-queuebot:#ubuntu-release- New binary: prometheus-tplink-plug-exporter [arm64] (groovy-proposed/universe) [0.2.0+git20200622.cc4a731-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nanofilt [riscv64] (groovy-proposed/universe) [2.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: prometheus-tplink-plug-exporter [riscv64] (groovy-proposed/universe) [0.2.0+git20200622.cc4a731-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (eoan-proposed) [2.45.1+19.10]
#ubuntu-release 2020-06-24
-queuebot:#ubuntu-release- Unapproved: autofs (focal-proposed/main) [5.1.6-2 => 5.1.6-2ubuntu0.1] (core)
-queuebot:#ubuntu-release- Unapproved: autofs (eoan-proposed/main) [5.1.5-1ubuntu1 => 5.1.5-1ubuntu2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted thermald [source] (focal-proposed) [1.9.1-1ubuntu0.2]
-queuebot:#ubuntu-release- New binary: deal.ii [s390x] (groovy-proposed/universe) [9.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deal.ii [amd64] (groovy-proposed/universe) [9.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: deal.ii [ppc64el] (groovy-proposed/universe) [9.2.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: autofs (bionic-proposed/main) [5.1.2-1ubuntu3.1 => 5.1.2-1ubuntu3.2] (core)
-queuebot:#ubuntu-release- New binary: libscgi-perl [amd64] (groovy-proposed/none) [0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nanofilt [amd64] (groovy-proposed/universe) [2.6.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: apbs [amd64] (groovy-proposed/universe) [3.0.0+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libopenshot-audio [s390x] (groovy-proposed/none) [0.2.0+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gftl [amd64] (groovy-proposed/none) [1.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nanofilt [s390x] (groovy-proposed/universe) [2.6.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: apbs [ppc64el] (groovy-proposed/universe) [3.0.0+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hsyaml-aeson [amd64] (groovy-proposed/universe) [0.2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nanofilt [ppc64el] (groovy-proposed/universe) [2.6.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: apbs [s390x] (groovy-proposed/universe) [3.0.0+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libhibernate-validator4-java [amd64] (groovy-proposed/universe) [4.3.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: apbs [arm64] (groovy-proposed/universe) [3.0.0+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: nanofilt [arm64] (groovy-proposed/universe) [2.6.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: openshot-qt [amd64] (groovy-proposed/universe) [2.5.1+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libopenshot-audio [armhf] (groovy-proposed/universe) [0.2.0+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: nanofilt [armhf] (groovy-proposed/universe) [2.6.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: apbs [armhf] (groovy-proposed/universe) [3.0.0+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libopenshot-audio [ppc64el] (groovy-proposed/universe) [0.2.0+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hsyaml-aeson [arm64] (groovy-proposed/universe) [0.2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hsyaml-aeson [ppc64el] (groovy-proposed/universe) [0.2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libopenshot-audio [arm64] (groovy-proposed/universe) [0.2.0+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: binutils (bionic-proposed/main) [2.30-21ubuntu1~18.04.3 => 2.30-21ubuntu1~18.04.4] (core)
-queuebot:#ubuntu-release- New binary: nanofilt [riscv64] (groovy-proposed/universe) [2.6.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: apbs [riscv64] (groovy-proposed/universe) [3.0.0+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libopenshot-audio [riscv64] (groovy-proposed/universe) [0.2.0+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hsyaml-aeson [riscv64] (groovy-proposed/universe) [0.2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xorg-server (focal-proposed/main) [2:1.20.8-2ubuntu2.1 => 2:1.20.8-2ubuntu2.2] (desktop-core, i386-whitelist, xorg)
<Laney> xnox: we should fix ubuntustudio/focal
<xnox> lamont:  what's up with it?
<xnox> lamont:  laaaaaaaaaaaaaaaaaaaaaaaaamont unping
<xnox> Laney:  hm?
<xnox> what's broken with it?
<xnox> I did recently install 20.04.0 of it.
<Laney> heh
<Laney> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/focal/ubuntustudio/
<xnox> oh
<xnox> Cannot handle more than one kernel for lowlatency (5.4.0-26-lowlatency
<xnox> hm
 * xnox ponders why it install many kernels
<xnox> Laney:  we did something wrong in focal GA =/ i think blacklists are incomplete, or something?
<xnox> # apt-cache show linux-headers-5.4.0-26-lowlatency | grep Task
<xnox> Task: ubuntustudio-desktop-core, ubuntustudio-desktop
<xnox> Laney:  we install -38-lowlatency, then later install task, and install -26-lowlatency without meta =(
 * xnox does not understand why linux-lowlatency has ubuntustudio task
<Laney> hmm
<xnox> Laney:  found it. opening a bug report.
<Laney> via ubuntustudio-lowlatency-settings?
<xnox> yes
<Laney> can see that chain
<xnox> https://bugs.launchpad.net/ubuntu/+source/ubuntustudio-meta/+bug/1884915
<ubot5> Ubuntu bug 1884915 in ubuntustudio-meta (Ubuntu) "ubuntustudio-default-settings recommends linux-lowlatency thus breaking ubuntustudio focal image building" [Undecided,New]
<xnox> and merge proposal
<xnox> Laney:  now, we can't drop the tasks from the focal release pocket, so for focal, i guess we need a hack in live-build to force remove that abi? or like maybe it can be done in livecd-rootfs?
-queuebot:#ubuntu-release- New binary: remmina [s390x] (groovy-proposed/main) [1.4.6+dfsg-2ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: remmina [ppc64el] (groovy-proposed/main) [1.4.6+dfsg-2ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: remmina [arm64] (groovy-proposed/main) [1.4.6+dfsg-2ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: remmina [armhf] (groovy-proposed/main) [1.4.6+dfsg-2ubuntu1] (ubuntu-desktop)
<LocutusOfBorg> hello, would it be possible to try a meson autopkgtest on a machine that has much more memory and see if the boost test passes? http://autopkgtest.ubuntu.com/packages/m/meson/groovy/amd64
<LocutusOfBorg> I marked as flaky, but the reason might be ENOMEMORY, according also to the Debian bug 963546 (and the fact that I can't reproduce it locally)
<ubot5> Debian bug 963546 in src:meson "meson: autopkgtest failures" [Serious,Open] http://bugs.debian.org/963546
<Laney> LocutusOfBorg: try building an autopkgtest vm with --ram-size=1536, that's what the instances have
<Laney> if you can reproduce, an MP adding it to big_packages would be ok
<Laney> xnox: I think no-change SRUing it after adding the blacklist should work no?
<ricotz> hello :), please accept the built nodejs packages - https://launchpad.net/ubuntu/+source/nodejs/12.18.0~dfsg-3ubuntu1
<LocutusOfBorg> I hope this is the way to deal with autopkgtests autopkgtest-build-lxd ubuntu-daily:groovy/amd64
<Laney> It's sufficient in most cases, but if you want to test OOM then use a VM
-queuebot:#ubuntu-release- New binary: primus-vk [ppc64el] (groovy-proposed/multiverse) [1.5-1] (no packageset)
<LocutusOfBorg> I don't remember where to download it...
<LocutusOfBorg> I know I should search for something called autopkgtest-groovy-amd64.img
<LocutusOfBorg> got it sudo autopkgtest-buildvm-ubuntu-cloud -v -r groovy -a amd64
-queuebot:#ubuntu-release- New binary: remmina [riscv64] (groovy-proposed/main) [1.4.6+dfsg-2ubuntu1] (ubuntu-desktop)
<Laney> (s/building/running/ !!!)
<LocutusOfBorg> sure :) the test is already running! I'll try if it fails to increase a little bit the memory to see if this is the case
-queuebot:#ubuntu-release- New binary: deal.ii [arm64] (groovy-proposed/universe) [9.2.0-1] (no packageset)
<LocutusOfBorg> not sure why Laney but it prints some more messages when ran locally
<LocutusOfBorg> https://paste.ubuntu.com/p/6425XPV3bT/
<LocutusOfBorg> xnox, ^^ does this ring any bell?
<LocutusOfBorg> I would blame boost for this
<LocutusOfBorg> lets see what happens with the other run I'm doing, but yes, probably is gcc that is running out of memory...
<Laney> add --shell-fail and look in dmesg
-queuebot:#ubuntu-release- Unapproved: sshguard (focal-proposed/universe) [2.3.1-1ubuntu1 => 2.3.1-1ubuntu1.1] (no packageset)
<LocutusOfBorg> yep :) unfortunately I pressed enter and everything was lost
<xnox> Laney:  no it will not, the 26 abi package is the broken one that has the Task:, and that's frozen in focal/ suite and is always visible.
<xnox> Laney:  live-build installs the task, not the metapackage right?
<Laney> livecd-rootfs expands the task based on what apt-cache dumpavail outputs
<xnox> which will forever have linux-image-5.4.0-26-lowlatency in dumpavail from the release pocket, as that package does not exist in -updates, and can never be rebuilt again.
<Laney> no
<Laney> https://paste.ubuntu.com/p/9TXCdCtS85/
<xnox> i think i must be talking about an issue from the morning
 * xnox is not sure what gnome-shell has to do with ubuntustudio FTBFS
<Laney> I'm showing you that the release pocket version isn't there
<Laney> so you can shadow stuff out in -updates
<xnox> if the binary package exists in both suites, yes.
<xnox> which is not true for kernel abi packages
<xnox> Laney:  https://paste.ubuntu.com/p/2QQ6ZMdsKH/
<xnox> -26- only exists in release, -37- only exists in updates, and both are available
<xnox> complete paste https://paste.ubuntu.com/p/ypDPDRqkdH/
<Laney> ah YEAH for the kernel specifically that's true
<xnox> Laney:  hm, if we fix seed, can we do binary copy of those abi packages from release to updates, such that it is published with a new task from updates pocket?
 * xnox guesses that will not work, because apt preffers the first instance of a package version and we list release suite first.
<Laney> I'm not sure what a good fix looks like
<Laney> hack in livecd-rootfs to remove it?
-queuebot:#ubuntu-release- New binary: petsc4py [s390x] (groovy-proposed/universe) [3.13.0-3] (no packageset)
<Laney> and maybe an assert in there to fail if any linux-image turn up in seeded tasks?
-queuebot:#ubuntu-release- New binary: petsc4py [ppc64el] (groovy-proposed/universe) [3.13.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc4py [armhf] (groovy-proposed/universe) [3.13.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc4py [arm64] (groovy-proposed/universe) [3.13.0-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted memcached [source] (eoan-proposed) [1.5.10-0ubuntu3.1]
<rbasak> bdmurray: dear SRU mentor, how do I handle people syncing things in SRUs from eg. Debian, such as budgie-extras?
<rbasak> The version will be fine, but I can't see if it's a source-only sync (OK I guess) or a binary sync (would be bad presumably).
<rbasak> And this method is not something in any documented process I know about - how would it work for SRU verification and the pending-sru report?
<rbasak> I keep seeing these, and I keep ignoring them, so I thought it's about time I asked.
<rbasak> (see budgie-extras in the Focal unapproved queue for example)
-queuebot:#ubuntu-release- Unapproved: update-notifier (trusty-proposed/main) [0.154.1ubuntu8 => 0.154.1ubuntu9] (kubuntu, ubuntu-desktop, ubuntu-server)
<Eickmeyer> xnox: I'm looking at your MP right now. Groovy hasn't been broken, it has been Focal. So, how does your fix for groovy fix the focal builds?
<Laney> it'll need to be backported...
<Eickmeyer> Laney: I understand, but wouldn't it be easier to do that in the focal branch of the seed?
<Laney> Usually you fix the development branch, and then backport the fix
<Eickmeyer> Then wouldn't it be better to drop the recommends in ubuntustudio-default-settings rather than to blacklist it in the seed?
<Eickmeyer> I'm just going based on the premise I've been told that blacklisting in the seed is bad.
-queuebot:#ubuntu-release- Unapproved: accepted chromium-browser [source] (focal-proposed) [83.0.4103.97-0ubuntu0.20.04.1]
<Eickmeyer> I mean, I'm not against this totally, I just want to make sure we're doing this right.
<Eickmeyer> I'm glad I'm finally getting some help fixing this (after several weeks of asking), but I'd just like some clarification.
<xnox> Eickmeyer:  Laney: not that.
<xnox> Eickmeyer:  any release pocket is broken at the moemnt.
<xnox> Eickmeyer:  the linux-*XX-* packages must not have any tasks
<Laney> "that"?
<xnox> Eickmeyer:  because after groovy goes GA, if we ever try to make a point release, it will fail to build, once there is a new kernel in -updates.
<xnox> Eickmeyer:  but the breakage comes from bad Task: * declaration, which ubuntustudio seeds generated on the linux-* packages, which they should not do.
<xnox> Eickmeyer:  i'm not yet sure how to fix this in focal, because a change of seeds in focal, will not undo the damage in the frozen focal/ suite
-queuebot:#ubuntu-release- Unapproved: accepted postfix [source] (focal-proposed) [3.4.13-0ubuntu1]
<Eickmeyer> xnox: So, what you're saying is that blacklisting this rather than dropping the recommends is the more-correct way to go?
<xnox> Eickmeyer:  i'm thinking to upload livebuild or live-cdrootfs to force remove the -26- abi kernel during ubuntustudio build as it has broken Tasks, which we can't remove, and said package must not be install on the iso.
<xnox> Eickmeyer:  i don't know why you have recommends there at all.
<Eickmeyer> xnox: I can drop that very easily.
<xnox> Eickmeyer:  no packages in the archive may depend on a linux flavour.
<xnox> Eickmeyer: why was it added? is it needed for calamares?
<xnox> Eickmeyer:  but i think the actual problem is generating Tasks on kernel abi packages
<Eickmeyer> xnox: No. It was added a long time ago for the grub menu prioritization (ubuntustudio-lowlatency-settings).
<xnox> separately, i'm thinking that maybe platform/ seed should be blacklist _all_ kernel abi packages
<xnox> such that none of the seeds can ever accidently generate Tasks: on them
<xnox> Eickmeyer:  why recommend something, that is manually installed for you anyway?
<Eickmeyer> But now that I think of it, -lowlatency-settings shouldn't recommend it anyhow.
<xnox> Eickmeyer:  or in otherwords, why recommend something, that can be removed?
<Eickmeyer> xnox: I don't know, it was a long time ago.
<xnox> =)
<xnox> Eickmeyer:  i didn't suggest dropping the Recommends, because i don't know how/why it is used. For pure cdimage.ubuntu.com based images it is redudant and broken.
<xnox> and we don't have d-i based installers anymore
<xnox> and studio is moving to calamares anyway
<Eickmeyer> Right. It doesn't matter for calamares at all.
<xnox> and we are implementing a grub flavour sorter in Ubuntu properly anyway, such that one will be able to declare GRUB_FLAVOUR priority list =)
<xnox> Eickmeyer: so instead of blacklist, you can drop the recommends and upload that into groovy
<xnox> Eickmeyer:  and i'll ponder about hacks to unbreak focal builds of ubuntustudio
<Eickmeyer> Ok. I can do that very easily.
<xnox> (neither dropping recommends, nor seed blacklist, nor rebuilds, alone will unbreak focal)
<Eickmeyer> Ok, so focal is broken at a foundational level at this point.
<Laney> 24/06 12:16:11 <Laney> I'm not sure what a good fix looks like
<Laney> 24/06 12:16:18 <Laney> hack in livecd-rootfs to remove it?
<Laney> 24/06 12:22:52 <Laney> and maybe an assert in there to fail if any linux-image turn up in seeded tasks?
<Laney> Feel like my input earlier was ignored / overlooked
 * xnox goes to re-read
<xnox> Laney:  sorry missed that.
<Laney> that's OK, that is all
<xnox> Laney:  something like that. platform/ blacklist, or like autopkgtest? ubuntu-archive-publishing overrides?
<Laney> I'd probably want Colin's input on where the blacklist should be implemented
<Laney> but we can add the guards into livecd-rootfs I think
<Laney> unless we're missing a legit case
<Eickmeyer> xnox, Laney: Fixes to ubuntustudio-default-settings uploaded. Should I reject the MP to the seed?
-queuebot:#ubuntu-release- New binary: petsc4py [riscv64] (groovy-proposed/universe) [3.13.0-3] (no packageset)
<xnox> Eickmeyer:  you can reject that, sure
<Eickmeyer> xnox: Done. I assume you're working on the focal breakage?
<Eickmeyer> BTW, sorry, that breakage, knowing what I know now, is my fault.
-queuebot:#ubuntu-release- Unapproved: accepted parted [source] (bionic-proposed) [3.2-20ubuntu0.3]
-queuebot:#ubuntu-release- Unapproved: accepted apache2 [source] (xenial-proposed) [2.4.18-2ubuntu3.15]
-queuebot:#ubuntu-release- New binary: remmina [ppc64el] (groovy-proposed/main) [1.4.6+dfsg-2ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: remmina [s390x] (groovy-proposed/main) [1.4.6+dfsg-2ubuntu2] (ubuntu-desktop)
<xnox> Eickmeyer:  I am sure you didn't intentionally uploaded something to break your own flavour =) so no harm on your part.
<xnox> from archive point of view, we should have better stuff to catch things like that, but it only breaks once every few years.
-queuebot:#ubuntu-release- New binary: remmina [arm64] (groovy-proposed/main) [1.4.6+dfsg-2ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: remmina [armhf] (groovy-proposed/main) [1.4.6+dfsg-2ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: remmina [riscv64] (groovy-proposed/main) [1.4.6+dfsg-2ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: primus-vk [amd64] (groovy-proposed/multiverse) [1.5-1] (no packageset)
<LocutusOfBorg> Laney, FYI confirmed
<LocutusOfBorg> [ 3874.578360] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-998.slice/session-c2.scope,task=cc1plus,pid=90806,uid=998
<LocutusOfBorg> [ 3874.578376] Out of memory: Killed process 90806 (cc1plus) total-vm:392820kB, anon-rss:349104kB, file-rss:344kB, shmem-rss:0kB, UID:998 pgtables:804kB oom_score_adj:0
<LocutusOfBorg> [ 3874.603197] oom_reaper: reaped process 90806 (cc1plus), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
-queuebot:#ubuntu-release- New binary: remmina [amd64] (groovy-proposed/main) [1.4.6+dfsg-2ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (focal-proposed) [20.04.15.1]
-queuebot:#ubuntu-release- New binary: petsc4py [amd64] (groovy-proposed/universe) [3.13.0-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: apport (focal-proposed/main) [2.20.11-0ubuntu27.3 => 2.20.11-0ubuntu27.4] (core, i386-whitelist)
<Eickmeyer> Ok, next issue, though somewhat related: I removed ubuntustudio-lightdm-theme from ubuntustudio-default-settings, and now for some reason it's holding up in update-excuses. Can we do something about that?
<Eickmeyer> xnox, Laney ^
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-390 (bionic-proposed/restricted) [390.132-0ubuntu0.18.04.1 => 390.138-0ubuntu0.18.04.1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-390 (focal-proposed/restricted) [390.132-0ubuntu2 => 390.138-0ubuntu0.20.04.1] (core, i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-390 (eoan-proposed/restricted) [390.132-0ubuntu0.19.10.1 => 390.138-0ubuntu0.19.10.1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-440 (bionic-proposed/multiverse) [440.59-0ubuntu0.18.04.1 => 440.100-0ubuntu0.18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-440 (focal-proposed/restricted) [440.82+really.440.64-0ubuntu6 => 440.100-0ubuntu0.20.04.1] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-440 (eoan-proposed/multiverse) [440.59-0ubuntu0.19.10.2 => 440.100-0ubuntu0.19.10.1] (no packageset) (sync)
<LocutusOfBorg> Laney, looks like I can't open a merge request, can you please check/grab from there if it looks sane to you? https://code.launchpad.net/~costamagnagianfranco/+git/autopkgtest-cloud/+ref/add-meson
-queuebot:#ubuntu-release- New binary: gftl [amd64] (groovy-proposed/universe) [1.2.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: kimageannotator [amd64] (groovy-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-findpython [amd64] (groovy-proposed/universe) [1.0.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-drf-spectacular [amd64] (groovy-proposed/universe) [0.9.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-odoc [amd64] (groovy-proposed/universe) [1.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-odoc [arm64] (groovy-proposed/universe) [1.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-rwikipathways [amd64] (groovy-proposed/universe) [1.6.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kimageannotator [s390x] (groovy-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-odoc [s390x] (groovy-proposed/universe) [1.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-odoc [armhf] (groovy-proposed/universe) [1.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kimageannotator [arm64] (groovy-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kimageannotator [armhf] (groovy-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gle-graphics [s390x] (groovy-proposed/universe) [4.2.5-8] (no packageset)
<xnox> Eickmeyer:  you need to highlight 'ubuntu - archive' as per topic, without spaces
-queuebot:#ubuntu-release- New binary: gle-graphics [amd64] (groovy-proposed/universe) [4.2.5-8] (no packageset)
-queuebot:#ubuntu-release- New binary: python-diagrams [amd64] (groovy-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kimageannotator [ppc64el] (groovy-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-odoc [ppc64el] (groovy-proposed/universe) [1.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1090.100] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (focal-proposed/main) [5.4.0-39.43] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1090.100]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (focal-proposed) [5.4.0-39.43]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [5.3.0-61.55~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [5.3.0-61.55~18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-108.109] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (focal-proposed/main) [5.4.0-1019.19] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (focal-proposed/main) [5.4.0-39.43] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-108.109] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (focal-proposed/main) [5.4.0-39.43] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-61.55] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (focal-proposed/main) [5.4.0-39.43] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (eoan-proposed) [5.3.0-61.55]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (focal-proposed) [5.4.0-39.43]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (focal-proposed) [5.4.0-39.43]
-queuebot:#ubuntu-release- New binary: linux-signed-oracle-5.3 [amd64] (bionic-proposed/main) [5.3.0-1027.29~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (focal-proposed) [5.4.0-1019.19]
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1062.67] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (focal-proposed) [5.4.0-39.43]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-108.109]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1062.67]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-108.109]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [arm64] (bionic-proposed/main) [5.3.0-61.55~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle-5.3 [amd64] (bionic-proposed) [5.3.0-1027.29~18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-azure-5.3 [amd64] (bionic-proposed/main) [5.3.0-1031.32~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: gle-graphics [ppc64el] (groovy-proposed/universe) [4.2.5-8] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-5.3 [amd64] (bionic-proposed) [5.3.0-1031.32~18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-5.3 [amd64] (bionic-proposed/main) [5.3.0-1029.31~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [arm64] (bionic-proposed) [5.3.0-61.55~18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-61.55] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.3.0-61.55]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-5.3 [amd64] (bionic-proposed) [5.3.0-1029.31~18.04.1]
-queuebot:#ubuntu-release- New binary: gle-graphics [arm64] (groovy-proposed/universe) [4.2.5-8] (no packageset)
<Eickmeyer> ubuntu-archive: I removed ubuntustudio-lightdm-theme from ubuntustudio-default-settings, and now for some reason it's holding up in update-excuses. Can we do something about that?
<bdmurray> Eickmeyer: I don't think "Valid candidate" translates to "holding up".
<bdmurray> It just means be patient.
<Eickmeyer> bdmurray: A while ago it was whining about a missing build. That's what spurred my comment.
-queuebot:#ubuntu-release- New binary: ocaml-odoc [riscv64] (groovy-proposed/universe) [1.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kimageannotator [riscv64] (groovy-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gle-graphics [amd64] (groovy-proposed) [4.2.5-8]
-queuebot:#ubuntu-release- New: accepted gle-graphics [ppc64el] (groovy-proposed) [4.2.5-8]
-queuebot:#ubuntu-release- New: accepted kimageannotator [riscv64] (groovy-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted ocaml-odoc [riscv64] (groovy-proposed) [1.5.1-1]
-queuebot:#ubuntu-release- New binary: mplcursors [amd64] (groovy-proposed/universe) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gle-graphics [arm64] (groovy-proposed) [4.2.5-8]
-queuebot:#ubuntu-release- New: accepted ocaml-odoc [ppc64el] (groovy-proposed) [1.5.1-1]
-queuebot:#ubuntu-release- New: accepted kimageannotator [ppc64el] (groovy-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted python-diagrams [amd64] (groovy-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted gftl [amd64] (groovy-proposed) [1.2.5-2]
-queuebot:#ubuntu-release- New: accepted kimageannotator [amd64] (groovy-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted kimageannotator [armhf] (groovy-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted ocaml-odoc [amd64] (groovy-proposed) [1.5.1-1]
-queuebot:#ubuntu-release- New: accepted ocaml-odoc [armhf] (groovy-proposed) [1.5.1-1]
-queuebot:#ubuntu-release- New: accepted petsc4py [amd64] (groovy-proposed) [3.13.0-3]
-queuebot:#ubuntu-release- New: accepted r-bioc-rwikipathways [amd64] (groovy-proposed) [1.6.1+dfsg-1]
-queuebot:#ubuntu-release- New binary: nodejs [amd64] (groovy-proposed/universe) [12.18.0~dfsg-3ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: nodejs [armhf] (groovy-proposed/universe) [12.18.0~dfsg-3ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: nodejs [s390x] (groovy-proposed/universe) [12.18.0~dfsg-3ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted gle-graphics [s390x] (groovy-proposed) [4.2.5-8]
-queuebot:#ubuntu-release- New: accepted kimageannotator [s390x] (groovy-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted ocaml-odoc [s390x] (groovy-proposed) [1.5.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-findpython [amd64] (groovy-proposed) [1.0.5-2]
-queuebot:#ubuntu-release- New binary: nodejs [ppc64el] (groovy-proposed/universe) [12.18.0~dfsg-3ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted kimageannotator [arm64] (groovy-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted python-drf-spectacular [amd64] (groovy-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New binary: qdarkstyle [amd64] (groovy-proposed/universe) [2.8.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ocaml-odoc [arm64] (groovy-proposed) [1.5.1-1]
-queuebot:#ubuntu-release- New binary: nodejs [arm64] (groovy-proposed/universe) [12.18.0~dfsg-3ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted deal.ii [arm64] (groovy-proposed) [9.2.0-1]
-queuebot:#ubuntu-release- New: accepted libopenshot-audio [riscv64] (groovy-proposed) [0.2.0+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted petsc4py [armhf] (groovy-proposed) [3.13.0-3]
-queuebot:#ubuntu-release- New: accepted petsc4py [riscv64] (groovy-proposed) [3.13.0-3]
-queuebot:#ubuntu-release- New: accepted primus-vk [amd64] (groovy-proposed) [1.5-1]
-queuebot:#ubuntu-release- New source: add64 (groovy-proposed/primary) [3.9.3-0ubuntu1]
-queuebot:#ubuntu-release- New source: plasma-wayland-protocols (groovy-proposed/primary) [1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted haskell-hsyaml-aeson [riscv64] (groovy-proposed) [0.2.0.0-2]
-queuebot:#ubuntu-release- New: accepted petsc4py [ppc64el] (groovy-proposed) [3.13.0-3]
-queuebot:#ubuntu-release- New: accepted primus-vk [ppc64el] (groovy-proposed) [1.5-1]
-queuebot:#ubuntu-release- New source: redkite (groovy-proposed/primary) [0.8.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted petsc4py [arm64] (groovy-proposed) [3.13.0-3]
-queuebot:#ubuntu-release- New source: kwayland-server (groovy-proposed/primary) [5.19.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted petsc4py [s390x] (groovy-proposed) [3.13.0-3]
-queuebot:#ubuntu-release- New: accepted apbs [arm64] (groovy-proposed) [3.0.0+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted apbs [ppc64el] (groovy-proposed) [3.0.0+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted haskell-hsyaml-aeson [arm64] (groovy-proposed) [0.2.0.0-2]
-queuebot:#ubuntu-release- New: accepted libopenshot-audio [arm64] (groovy-proposed) [0.2.0+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted libopenshot-audio [ppc64el] (groovy-proposed) [0.2.0+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted nanofilt [armhf] (groovy-proposed) [2.6.0-2]
-queuebot:#ubuntu-release- New: accepted openshot-qt [amd64] (groovy-proposed) [2.5.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted apbs [armhf] (groovy-proposed) [3.0.0+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted haskell-hsyaml-aeson [ppc64el] (groovy-proposed) [0.2.0.0-2]
-queuebot:#ubuntu-release- New: accepted nanofilt [arm64] (groovy-proposed) [2.6.0-2]
-queuebot:#ubuntu-release- New: accepted apbs [riscv64] (groovy-proposed) [3.0.0+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted nanofilt [riscv64] (groovy-proposed) [2.6.0-2]
-queuebot:#ubuntu-release- New: accepted libopenshot-audio [armhf] (groovy-proposed) [0.2.0+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted apbs [amd64] (groovy-proposed) [3.0.0+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted deal.ii [amd64] (groovy-proposed) [9.2.0-1]
-queuebot:#ubuntu-release- New: accepted gftl [amd64] (groovy-proposed) [1.2.5-1]
-queuebot:#ubuntu-release- New: accepted libhibernate-validator4-java [amd64] (groovy-proposed) [4.3.4-2]
-queuebot:#ubuntu-release- New: accepted libscgi-perl [amd64] (groovy-proposed) [0.6-1]
-queuebot:#ubuntu-release- New: accepted nanofilt [ppc64el] (groovy-proposed) [2.6.0-2]
-queuebot:#ubuntu-release- New: accepted apbs [s390x] (groovy-proposed) [3.0.0+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted haskell-hsyaml-aeson [amd64] (groovy-proposed) [0.2.0.0-2]
-queuebot:#ubuntu-release- New: accepted nanofilt [amd64] (groovy-proposed) [2.6.0-2]
-queuebot:#ubuntu-release- New: accepted deal.ii [ppc64el] (groovy-proposed) [9.2.0-1]
-queuebot:#ubuntu-release- New: accepted nanofilt [s390x] (groovy-proposed) [2.6.0-2]
-queuebot:#ubuntu-release- New: accepted libopenshot-audio [s390x] (groovy-proposed) [0.2.0+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted deal.ii [s390x] (groovy-proposed) [9.2.0-1]
-queuebot:#ubuntu-release- New: accepted nanofilt [armhf] (groovy-proposed) [2.6.0-1]
-queuebot:#ubuntu-release- New: accepted prometheus-tplink-plug-exporter [arm64] (groovy-proposed) [0.2.0+git20200622.cc4a731-1]
-queuebot:#ubuntu-release- New: accepted prometheus-tplink-plug-exporter [riscv64] (groovy-proposed) [0.2.0+git20200622.cc4a731-1]
-queuebot:#ubuntu-release- New: accepted nanofilt [arm64] (groovy-proposed) [2.6.0-1]
-queuebot:#ubuntu-release- New: accepted prometheus-tplink-plug-exporter [armhf] (groovy-proposed) [0.2.0+git20200622.cc4a731-1]
-queuebot:#ubuntu-release- New: accepted nanofilt [riscv64] (groovy-proposed) [2.6.0-1]
-queuebot:#ubuntu-release- Unapproved: rejected apport [source] (focal-proposed) [2.20.11-0ubuntu27.4]
-queuebot:#ubuntu-release- Unapproved: cinder (focal-proposed/main) [2:16.0.0-0ubuntu0.20.04.1 => 2:16.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-390 (bionic-proposed/restricted) [390.132-0ubuntu0.18.04.1 => 390.138-0ubuntu0.18.04.1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-390 (focal-proposed/restricted) [390.132-0ubuntu2 => 390.138-0ubuntu0.20.04.1] (core, i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-390 (eoan-proposed/restricted) [390.132-0ubuntu0.19.10.1 => 390.138-0ubuntu0.19.10.1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-440 (bionic-proposed/multiverse) [440.59-0ubuntu0.18.04.1 => 440.100-0ubuntu0.18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-440 (focal-proposed/restricted) [440.82+really.440.64-0ubuntu6 => 440.100-0ubuntu0.20.04.1] (i386-whitelist) (sync)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-440 (eoan-proposed/multiverse) [440.59-0ubuntu0.19.10.2 => 440.100-0ubuntu0.19.10.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: rejected nvidia-graphics-drivers-390 [sync] (focal-proposed) [390.138-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected nvidia-graphics-drivers-440 [sync] (focal-proposed) [440.100-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected nvidia-graphics-drivers-390 [sync] (eoan-proposed) [390.138-0ubuntu0.19.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected nvidia-graphics-drivers-440 [sync] (eoan-proposed) [440.100-0ubuntu0.19.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected nvidia-graphics-drivers-390 [sync] (bionic-proposed) [390.138-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected nvidia-graphics-drivers-440 [sync] (bionic-proposed) [440.100-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected nvidia-graphics-drivers-390 [sync] (bionic-proposed) [390.138-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected nvidia-graphics-drivers-390 [sync] (eoan-proposed) [390.138-0ubuntu0.19.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected nvidia-graphics-drivers-440 [sync] (bionic-proposed) [440.100-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected nvidia-graphics-drivers-440 [sync] (eoan-proposed) [440.100-0ubuntu0.19.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected nvidia-graphics-drivers-390 [sync] (focal-proposed) [390.138-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected nvidia-graphics-drivers-440 [sync] (focal-proposed) [440.100-0ubuntu0.20.04.1]
<coreycb> hello, please can an archive admin reject nova, neutron, heat, horizon, glance, and aodh from the eoan unapproved queue? with EOL around the corner we're going to upload those straight to the train cloud archive.
-queuebot:#ubuntu-release- Unapproved: bash (focal-proposed/main) [5.0-6ubuntu1 => 5.0-6ubuntu1.1] (core, i386-whitelist)
<bdmurray> coreycb: don't you mean an SRU team member as its eoan
-queuebot:#ubuntu-release- Unapproved: rejected aodh [source] (eoan-proposed) [9.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected heat [source] (eoan-proposed) [1:13.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected neutron [source] (eoan-proposed) [2:15.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected glance [source] (eoan-proposed) [2:19.0.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected nova [source] (eoan-proposed) [2:20.3.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected horizon [source] (eoan-proposed) [3:16.2.0-0ubuntu1]
<bdmurray> rbasak: I rejected budgie-extras
-queuebot:#ubuntu-release- Unapproved: rejected budgie-extras [sync] (focal-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- Unapproved: apport (focal-proposed/main) [2.20.11-0ubuntu27.3 => 2.20.11-0ubuntu27.4] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (focal-proposed/main) [1:20.04.19 => 1:20.04.20] (core)
-queuebot:#ubuntu-release- New binary: libopenshot [s390x] (groovy-proposed/universe) [0.2.5+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: opensaml [s390x] (groovy-proposed/universe) [3.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: opensaml [ppc64el] (groovy-proposed/universe) [3.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libopenshot [armhf] (groovy-proposed/universe) [0.2.5+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: opensaml [amd64] (groovy-proposed/universe) [3.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: opensaml [arm64] (groovy-proposed/universe) [3.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: opensaml [armhf] (groovy-proposed/universe) [3.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libopenshot [arm64] (groovy-proposed/universe) [0.2.5+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gftl-shared [amd64] (groovy-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gftl-shared [s390x] (groovy-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gftl-shared [ppc64el] (groovy-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gftl-shared [arm64] (groovy-proposed/universe) [1.0.7-1] (no packageset)
#ubuntu-release 2020-06-25
-queuebot:#ubuntu-release- New binary: opensaml [riscv64] (groovy-proposed/universe) [3.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libopenshot [riscv64] (groovy-proposed/universe) [0.2.5+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gftl-shared [riscv64] (groovy-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: budgie-extras (focal-proposed/universe) [1.0.1-2 => 1.0.2-0ubuntu1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: packetsender [s390x] (groovy-proposed/none) [6.2.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libopenshot-audio [amd64] (groovy-proposed/universe) [0.2.0+dfsg1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: packetsender [ppc64el] (groovy-proposed/none) [6.2.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: packetsender [amd64] (groovy-proposed/none) [6.2.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: packetsender [arm64] (groovy-proposed/none) [6.2.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: packetsender [armhf] (groovy-proposed/none) [6.2.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: packetsender [riscv64] (groovy-proposed/universe) [6.2.6-2] (no packageset)
<rbasak> bdmurray: thanks. Any situation where a sync like that would be acceptable?
<Laney>  LocutusOfBorg: You definitely can make MPs against autopkgtest-cloud. I think if you push to a place without '+git' it would let you.
<Laney> I'll look though.
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (focal-proposed/main) [5.4.0-1019.19] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (focal-proposed) [5.4.0-1019.19]
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (focal-proposed/main) [5.4.0-40.44] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (focal-proposed) [5.4.0-40.44]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (focal-proposed/main) [5.4.0-1019.19] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (focal-proposed) [5.4.0-1019.19]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-109.110] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.3.0-62.56] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-62.56] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-109.110] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-62.56] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-109.110]
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-62.56] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-109.110]
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (focal-proposed/main) [5.4.0-40.44] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.3.0-62.56]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.3.0-62.56]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (focal-proposed) [5.4.0-40.44]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.3.0-62.56]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (eoan-proposed) [5.3.0-62.56]
<LocutusOfBorg> thanks Laney :) https://code.launchpad.net/~costamagnagianfranco/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/386374
<ginggs> ubuntu-archive: would someone please remove vtk7/7.1.1+dfsg2-4ubuntu3/riscv64 binaries from -release? it's blocking the r-base transition. the rebuild stalled, and now retrying hits the bsdextrautils mess. it should build fine once that is resolved
<LocutusOfBorg> alternatively, we can remove bsdmainutils from groovy proposed pocket, not sure which one is best ^^
<ginggs> why not both? :)
<ginggs> \o/
<seb128> ginggs, it seems to have a bunch of rdepends, we can't just remove it like that
<LocutusOfBorg> also bsdmainutils?
<ginggs> seb128: thanks :(
<LocutusOfBorg> seb128, if we remove it, we can retry the vtk7 build and live happy
<cpaelzer_> sil2100: rbasak: would one of you be able to today shed soem SRU-light onto open-vm-tools in focal-unapproved?
<seb128> ginggs, sorry :/
<cpaelzer_> This has an external deadline somewhen late in July, but I'm off in July quite a bit - so in case anything comes up I might be unavalilable and it will delay further
<cpaelzer_> therefore starting to process it soon would be very helpful
<seb128> LocutusOfBorg, removing something from proposed doesn't break the archive so is probably best
<LocutusOfBorg> can you please do it then?
<LocutusOfBorg> we can copy it back once vtk7 is built and migrates with r-* stuff
<seb128> ^ ubuntu-archive, anyone is having an objection to do that?
<seb128> or not only ubuntu-a :p
<apw> seb128, if none of its reverse-depends are in -proposed removing something from there sounds tollerable
<seb128> apw, do you know of an easy way to check that?
<apw> seb128, no :)
<seb128> :(
<apw> some kinds of reverse-depends | rmadison combo i guess
<seb128> right...
<LocutusOfBorg> for i in `reverse-depends -r groovy src:bsdmainutils |grep \* |cut -f 2 -d " "`; do rmadison -u ubuntu -s groovy-proposed $i; done
<LocutusOfBorg> is that what you want?
<LocutusOfBorg> or we might disable the failing test on util-linux and reupload so it builds on riscv64
<LocutusOfBorg> it might be even easier
<LocutusOfBorg> in the meanwhile we fix it
<seb128> LocutusOfBorg, right, I don't feel comfortable removing bsdmainutils without more data on the impact, maybe someone on +1 rotation can help there
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [amd64] (bionic-proposed/main) [5.4.0-40.44~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [s390x] (bionic-proposed/main) [5.4.0-40.44~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [ppc64el] (bionic-proposed/main) [5.4.0-40.44~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [arm64] (bionic-proposed/main) [5.4.0-40.44~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [amd64] (bionic-proposed) [5.4.0-40.44~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [ppc64el] (bionic-proposed) [5.4.0-40.44~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [arm64] (bionic-proposed) [5.4.0-40.44~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [s390x] (bionic-proposed) [5.4.0-40.44~18.04.1]
-queuebot:#ubuntu-release- Unapproved: vagrant (focal-proposed/universe) [2.2.6+dfsg-2ubuntu2 => 2.2.6+dfsg-2ubuntu3] (ubuntu-cloud)
<cjwatson> bsdmainutils> wouldn't it be sufficient to fix the bsdextrautils ftbfs on riscv64, get it through NEW with the new binary in main, then retry man-db builds?
<cjwatson> unless the vtk7 ftbfs is something other than the typical interaction with man-db that broke a bunch of things
<cjwatson> the uname 2.6 test in util-linux didn't look like it was likely to make much sense on riscv64 anyway
<LocutusOfBorg> cjwatson, yes https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4114/+packages
<cpaelzer_> sil2100: I pinged this morning if there would be a chance to SRU look at open-vm-tools but got no reply so far, too busy today?
<cpaelzer_> I also pinged rbasak but it turns out he it off today
-queuebot:#ubuntu-release- New: accepted remmina [arm64] (groovy-proposed) [1.4.6+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted remmina [ppc64el] (groovy-proposed) [1.4.6+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted remmina [s390x] (groovy-proposed) [1.4.6+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted remmina [arm64] (groovy-proposed) [1.4.6+dfsg-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted remmina [ppc64el] (groovy-proposed) [1.4.6+dfsg-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted remmina [s390x] (groovy-proposed) [1.4.6+dfsg-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted remmina [armhf] (groovy-proposed) [1.4.6+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted remmina [amd64] (groovy-proposed) [1.4.6+dfsg-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted remmina [riscv64] (groovy-proposed) [1.4.6+dfsg-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted remmina [riscv64] (groovy-proposed) [1.4.6+dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted remmina [armhf] (groovy-proposed) [1.4.6+dfsg-2ubuntu2]
-queuebot:#ubuntu-release- New: accepted nodejs [amd64] (groovy-proposed) [12.18.0~dfsg-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted nodejs [armhf] (groovy-proposed) [12.18.0~dfsg-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted nodejs [s390x] (groovy-proposed) [12.18.0~dfsg-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted nodejs [arm64] (groovy-proposed) [12.18.0~dfsg-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted nodejs [ppc64el] (groovy-proposed) [12.18.0~dfsg-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted util-linux [amd64] (groovy-proposed) [2.35.2-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted util-linux [armhf] (groovy-proposed) [2.35.2-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted util-linux [ppc64el] (groovy-proposed) [2.35.2-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted util-linux [arm64] (groovy-proposed) [2.35.2-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted util-linux [s390x] (groovy-proposed) [2.35.2-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted util-linux [i386] (groovy-proposed) [2.35.2-4ubuntu1]
<LocutusOfBorg> why has util-linux been accepted?
<LocutusOfBorg> bileto 4114 is almost ready to land
-queuebot:#ubuntu-release- New binary: linux-signed-kvm [amd64] (focal-proposed/main) [5.4.0-1018.18] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-kvm [amd64] (focal-proposed) [5.4.0-1018.18]
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1048.52] (kernel)
<seb128> LocutusOfBorg, sorry it's me who approved it but the queue has no context or info, I just accepted a bunch of binNEW builds because that's what we usually do...
<seb128> LocutusOfBorg, does it create any issue? it's not going to use more builder time since it was already built
<vorlon> LocutusOfBorg: why building in bileto instead of the archive? using bileto silos is generally opaque to anyone trying to work on this in the archive
<vorlon> and why is there a bumped version of vtk7 in that silo
<vorlon> and how is it building anyway on riscv64 when the version in the archive dep-wait because bsdextrautils isn't available
<LocutusOfBorg> seb128, it didn't harm to be honest
<LocutusOfBorg> vorlon, the version in bileto had a "fixed util-linux"
<LocutusOfBorg> and now I uploaded in the archive too, so meh, that bileto is useless
<LocutusOfBorg> and I used bileto because I had now way to know if the test disable on riscv64 was "correct on first shot" and using the archive for riscv64 tests is sad, and ppa don't have it
<LocutusOfBorg> (btw the fix was correctly on first attempt, Murphy's law did the job here)
<LocutusOfBorg> if you have a way to test riscv64 specific fixes, please tell me :)
-queuebot:#ubuntu-release- New binary: dnsdbq [amd64] (groovy-proposed/none) [2.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-mergedict [amd64] (groovy-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: httpx [amd64] (groovy-proposed/none) [0.12.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: speaklater [amd64] (groovy-proposed/none) [1.3-4] (no packageset)
-queuebot:#ubuntu-release- New binary: pykeepass [amd64] (groovy-proposed/none) [3.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: elementpath [amd64] (groovy-proposed/none) [1.4.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-tomlkit [amd64] (groovy-proposed/none) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libldac [amd64] (groovy-proposed/none) [2.0.2.3+git20180726-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-redisearch-py [amd64] (groovy-proposed/none) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: audmes [amd64] (groovy-proposed/none) [0+git20200429-1] (no packageset)
-queuebot:#ubuntu-release- New binary: aerc [s390x] (groovy-proposed/none) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dnsdbq [s390x] (groovy-proposed/none) [2.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-redux [amd64] (groovy-proposed/none) [4.0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: audmes [s390x] (groovy-proposed/none) [0+git20200429-1] (no packageset)
-queuebot:#ubuntu-release- New binary: requirement-parser [amd64] (groovy-proposed/none) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dpaste [amd64] (groovy-proposed/none) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: aerc [amd64] (groovy-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dpaste [s390x] (groovy-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: prometheus-openstack-exporter [amd64] (groovy-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jsofa [amd64] (groovy-proposed/universe) [0~20190722-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qbs [s390x] (groovy-proposed/universe) [1.16.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: aerc [ppc64el] (groovy-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: audmes [ppc64el] (groovy-proposed/universe) [0+git20200429-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dnsdbq [ppc64el] (groovy-proposed/universe) [2.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dpaste [ppc64el] (groovy-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libldac [ppc64el] (groovy-proposed/universe) [2.0.2.3+git20180726-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dnsdbq [riscv64] (groovy-proposed/universe) [2.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libldac [riscv64] (groovy-proposed/universe) [2.0.2.3+git20180726-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qbs [ppc64el] (groovy-proposed/universe) [1.16.0-2] (no packageset)
<vorlon> LocutusOfBorg: testing riscv64-specific fixes: https://people.ubuntu.com/~wgrant/riscv64/
-queuebot:#ubuntu-release- New: accepted aerc [ppc64el] (groovy-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted dnsdbq [ppc64el] (groovy-proposed) [2.1.1-2]
-queuebot:#ubuntu-release- New: accepted dpaste [ppc64el] (groovy-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted libldac [riscv64] (groovy-proposed) [2.0.2.3+git20180726-1]
-queuebot:#ubuntu-release- New: accepted audmes [ppc64el] (groovy-proposed) [0+git20200429-1]
-queuebot:#ubuntu-release- New: accepted libldac [ppc64el] (groovy-proposed) [2.0.2.3+git20180726-1]
-queuebot:#ubuntu-release- New: accepted dnsdbq [riscv64] (groovy-proposed) [2.1.1-2]
-queuebot:#ubuntu-release- New: accepted qbs [ppc64el] (groovy-proposed) [1.16.0-2]
-queuebot:#ubuntu-release- New: accepted aerc [amd64] (groovy-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted audmes [s390x] (groovy-proposed) [0+git20200429-1]
-queuebot:#ubuntu-release- New: accepted dpaste [amd64] (groovy-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted jsofa [amd64] (groovy-proposed) [0~20190722-1]
-queuebot:#ubuntu-release- New: accepted prometheus-openstack-exporter [amd64] (groovy-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted requirement-parser [amd64] (groovy-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted aerc [s390x] (groovy-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted dpaste [s390x] (groovy-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted qbs [s390x] (groovy-proposed) [1.16.0-2]
-queuebot:#ubuntu-release- New: accepted dnsdbq [s390x] (groovy-proposed) [2.1.1-2]
-queuebot:#ubuntu-release- New: accepted node-redux [amd64] (groovy-proposed) [4.0.5-1]
-queuebot:#ubuntu-release- New: accepted audmes [amd64] (groovy-proposed) [0+git20200429-1]
-queuebot:#ubuntu-release- New: accepted elementpath [amd64] (groovy-proposed) [1.4.4-1]
-queuebot:#ubuntu-release- New: accepted libldac [amd64] (groovy-proposed) [2.0.2.3+git20180726-1]
-queuebot:#ubuntu-release- New: accepted python-mergedict [amd64] (groovy-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted python-tomlkit [amd64] (groovy-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New binary: qbs [amd64] (groovy-proposed/universe) [1.16.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted dnsdbq [amd64] (groovy-proposed) [2.1.1-2]
-queuebot:#ubuntu-release- New: accepted pykeepass [amd64] (groovy-proposed) [3.2.0-1]
-queuebot:#ubuntu-release- New: accepted speaklater [amd64] (groovy-proposed) [1.3-4]
-queuebot:#ubuntu-release- New: accepted httpx [amd64] (groovy-proposed) [0.12.1-1]
-queuebot:#ubuntu-release- New: accepted python-redisearch-py [amd64] (groovy-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted gftl-shared [riscv64] (groovy-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted packetsender [amd64] (groovy-proposed) [6.2.6-2]
-queuebot:#ubuntu-release- New: accepted packetsender [armhf] (groovy-proposed) [6.2.6-2]
-queuebot:#ubuntu-release- New: accepted packetsender [riscv64] (groovy-proposed) [6.2.6-2]
-queuebot:#ubuntu-release- New: accepted libopenshot-audio [amd64] (groovy-proposed) [0.2.0+dfsg1-3]
-queuebot:#ubuntu-release- New: accepted packetsender [ppc64el] (groovy-proposed) [6.2.6-2]
-queuebot:#ubuntu-release- New: accepted packetsender [arm64] (groovy-proposed) [6.2.6-2]
-queuebot:#ubuntu-release- New: accepted packetsender [s390x] (groovy-proposed) [6.2.6-2]
-queuebot:#ubuntu-release- New: accepted gftl-shared [amd64] (groovy-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted gftl-shared [ppc64el] (groovy-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted libopenshot [arm64] (groovy-proposed) [0.2.5+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted opensaml [arm64] (groovy-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted opensaml [riscv64] (groovy-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted gftl-shared [arm64] (groovy-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted libopenshot [riscv64] (groovy-proposed) [0.2.5+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted gftl-shared [s390x] (groovy-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted opensaml [armhf] (groovy-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted libopenshot [armhf] (groovy-proposed) [0.2.5+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted mplcursors [amd64] (groovy-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted nanofilt [ppc64el] (groovy-proposed) [2.6.0-1]
-queuebot:#ubuntu-release- New: accepted opensaml [ppc64el] (groovy-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted prometheus-tplink-plug-exporter [ppc64el] (groovy-proposed) [0.2.0+git20200622.cc4a731-1]
-queuebot:#ubuntu-release- New: accepted libopenshot [s390x] (groovy-proposed) [0.2.5+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted opensaml [amd64] (groovy-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted prometheus-tplink-plug-exporter [s390x] (groovy-proposed) [0.2.0+git20200622.cc4a731-1]
-queuebot:#ubuntu-release- New: accepted nanofilt [amd64] (groovy-proposed) [2.6.0-1]
-queuebot:#ubuntu-release- New: accepted opensaml [s390x] (groovy-proposed) [3.1.0-2]
-queuebot:#ubuntu-release- New: accepted nanofilt [s390x] (groovy-proposed) [2.6.0-1]
-queuebot:#ubuntu-release- New: accepted qdarkstyle [amd64] (groovy-proposed) [2.8.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted prometheus-tplink-plug-exporter [amd64] (groovy-proposed) [0.2.0+git20200622.cc4a731-1]
-queuebot:#ubuntu-release- New: accepted qdarkstyle [amd64] (groovy-proposed) [2.8.1+ds1-2]
-queuebot:#ubuntu-release- New binary: dnsdbq [arm64] (groovy-proposed/universe) [2.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: audmes [arm64] (groovy-proposed/universe) [0+git20200429-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dnsdbq [armhf] (groovy-proposed/universe) [2.1.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: audmes [armhf] (groovy-proposed/universe) [0+git20200429-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libldac [arm64] (groovy-proposed/universe) [2.0.2.3+git20180726-1] (no packageset)
<RikMills> vorlon LocutusOfBorg with new util-linux in proposed, I amd gettign several build fails with:
<RikMills> --   Package 'libcryptsetup', required by 'mount', not found
<LocutusOfBorg> mmm interesting
-queuebot:#ubuntu-release- New binary: aerc [arm64] (groovy-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dpaste [riscv64] (groovy-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: aerc [armhf] (groovy-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libldac [armhf] (groovy-proposed/universe) [2.0.2.3+git20180726-1] (no packageset)
-queuebot:#ubuntu-release- New binary: audmes [riscv64] (groovy-proposed/universe) [0+git20200429-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dpaste [arm64] (groovy-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: aerc [riscv64] (groovy-proposed/universe) [0.3.0-1] (no packageset)
<vorlon> RikMills: that's a literal 'libcryptsetup'?  that's clearly the wrong package name :/
<RikMills> LocutusOfBorg: libmount-dev should depend on libcryptsetup-dev?
<RikMills> vorlon: yeah, less than helpful
<RikMills> things that build fine before util-linux pubished to proposed, now fail with that
<RikMills> 'Build with libcryptsetup-dev to enable dm-verity (Closes: #951048)'
<vorlon> ah
<RikMills> so yes, I guess the mount -dev package needs that
<vorlon> I can upload the fix
<RikMills> ty :)
<vorlon> but this means it only impacts things that are using libmount-dev, not the mount package itself, phew
-queuebot:#ubuntu-release- New binary: qbs [armhf] (groovy-proposed/universe) [1.16.0-2] (no packageset)
<RikMills> yep
<vorlon> was fixed in Debian in 2.35.2-6 fwiw
<RikMills> ah. nice
<RikMills> vorlon: would you perhaps have time to look at plasma-wayland-protocals and kwayland-server in NEW? LP: #1883501 LP: #1884120
<ubot5> Launchpad bug 1883501 in Ubuntu Groovy "[needs-packaging] plasma-wayland-protocols" [Wishlist,Fix committed] https://launchpad.net/bugs/1883501
<ubot5> Launchpad bug 1884120 in Ubuntu Groovy "[needs-packaging] kwayland-server" [Wishlist,Fix committed] https://launchpad.net/bugs/1884120
<RikMills> I cannot land new upstream plasma without those :(
-queuebot:#ubuntu-release- New: accepted aerc [riscv64] (groovy-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted dpaste [arm64] (groovy-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted audmes [riscv64] (groovy-proposed) [0+git20200429-1]
-queuebot:#ubuntu-release- New: accepted qbs [armhf] (groovy-proposed) [1.16.0-2]
<RikMills> Andy Whitcroft was going to try to look this week, but is too busy :/
-queuebot:#ubuntu-release- New: accepted aerc [arm64] (groovy-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted audmes [arm64] (groovy-proposed) [0+git20200429-1]
-queuebot:#ubuntu-release- New: accepted dnsdbq [arm64] (groovy-proposed) [2.1.1-2]
-queuebot:#ubuntu-release- New: accepted dpaste [riscv64] (groovy-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted libldac [armhf] (groovy-proposed) [2.0.2.3+git20180726-1]
-queuebot:#ubuntu-release- New: accepted aerc [armhf] (groovy-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted dnsdbq [armhf] (groovy-proposed) [2.1.1-2]
-queuebot:#ubuntu-release- New: accepted audmes [armhf] (groovy-proposed) [0+git20200429-1]
-queuebot:#ubuntu-release- New: accepted libldac [arm64] (groovy-proposed) [2.0.2.3+git20180726-1]
-queuebot:#ubuntu-release- New: accepted qbs [amd64] (groovy-proposed) [1.16.0-2]
<vorlon> Eickmeyer: why is redkite useful to have in the archive?  It's a GUI toolkit that nothing else in the archive or the NEW queue uses; and the packaging is non-standard, with only a static lib (no shared lib) and named as 'redkite' instead of 'libredkite-dev' as would be expected
<vorlon> Eickmeyer: the add64 package description could use some improvement; 'Add64 is the result of my experiments [...]' package descriptions shouldn't be in the first person
-queuebot:#ubuntu-release- New: accepted add64 [source] (groovy-proposed) [3.9.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-oslo.policy (focal-proposed/main) [3.1.0-0ubuntu1 => 3.1.0-0ubuntu1.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: add64 [ppc64el] (groovy-proposed/none) [3.9.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: add64 [s390x] (groovy-proposed/none) [3.9.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: add64 [amd64] (groovy-proposed/universe) [3.9.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: add64 [arm64] (groovy-proposed/universe) [3.9.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: add64 [armhf] (groovy-proposed/universe) [3.9.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: software-properties (focal-proposed/main) [0.98.9 => 0.98.9.1] (core)
-queuebot:#ubuntu-release- New binary: add64 [riscv64] (groovy-proposed/universe) [3.9.3-0ubuntu1] (no packageset)
<vorlon> Eickmeyer: in fact, there is a lintian warning about this use of first-person
-queuebot:#ubuntu-release- New: accepted add64 [amd64] (groovy-proposed) [3.9.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted add64 [armhf] (groovy-proposed) [3.9.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted add64 [s390x] (groovy-proposed) [3.9.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted add64 [arm64] (groovy-proposed) [3.9.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted add64 [ppc64el] (groovy-proposed) [3.9.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted add64 [riscv64] (groovy-proposed) [3.9.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: nginx [s390x] (groovy-proposed/main) [1.18.0-3ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: nginx [ppc64el] (groovy-proposed/main) [1.18.0-3ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: nginx [amd64] (groovy-proposed/main) [1.18.0-3ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: nginx [armhf] (groovy-proposed/main) [1.18.0-3ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: nginx [arm64] (groovy-proposed/main) [1.18.0-3ubuntu1] (ubuntu-server)
<LocutusOfBorg> thanks vorlon for fixing it
-queuebot:#ubuntu-release- New binary: nginx [riscv64] (groovy-proposed/main) [1.18.0-3ubuntu1] (ubuntu-server)
<ricotz> please retry https://launchpad.net/ubuntu/+source/firefox/78.0+build1-0ubuntu1
<ricotz> this got hit by the libmount-dev issue
<ricotz> LocutusOfBorg, ^
<Eickmeyer> vorlon: redkite is a GUI toolkit that is a prerequisite for another package I'm trying to bring in.
<LocutusOfBorg> oh lol already done before looking at irc
<Eickmeyer> vorlon: I'll fix Add64, please reject.
<LocutusOfBorg> I'm going to give a mass retry
<Eickmeyer> vorlon: I didn't get the lintian warning about it, so that surprises me. I do see that you accepted it anyhow. I'll fix with the next verison, it's actively developed.
<Eickmeyer> vorlon: As for redkite... should I just rename the binary package as "libredkite-dev"?
<Eickmeyer> vorlon: Back to Add64, I maintain the same package in Fedora, so I'm on top of it.
<vorlon> Eickmeyer: yes, please name the package libredkite-dev.  What is going to be using redkite?
<Eickmeyer> vorlon: A plugin called geonkick which is a kick drum synthesizer-type plugin.
<Eickmeyer> Possibly more down the road.
<vorlon> ok
<seb128> vorlon, hey, to enable an extra package on i386 should we have the discussion on the discourse topic for record purpose etc? or is it fine to just add one directly to the whitelist?
-queuebot:#ubuntu-release- New binary: rust-sequoia-openpgp [amd64] (groovy-proposed/universe) [0.17.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sequoia-openpgp [ppc64el] (groovy-proposed/universe) [0.17.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sequoia-openpgp [s390x] (groovy-proposed/universe) [0.17.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: cmake-format [amd64] (groovy-proposed/universe) [0.6.10-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-xdg-desktop-entry [amd64] (groovy-proposed/universe) [0.1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-xdg-desktop-entry [ppc64el] (groovy-proposed/universe) [0.1.1.1-1] (no packageset)
<seb128> vorlon, I'm about to drop for the day but I was asking for gamemode (https://bugs.launchpad.net/ubuntu/+source/gamemode/+bug/1883253/comments/3), if you reply here I will read the log tomorrow
<ubot5> Ubuntu bug 1883253 in gamemode (Ubuntu) "no Multi-Arch support" [Low,Fix released]
<seb128> (using that bug ^ would also work to discuss the topic)
<seb128> but calling it a day for now, night
-queuebot:#ubuntu-release- New binary: haskell-xdg-desktop-entry [arm64] (groovy-proposed/universe) [0.1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-xdg-desktop-entry [armhf] (groovy-proposed/universe) [0.1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-xdg-desktop-entry [s390x] (groovy-proposed/universe) [0.1.1.1-1] (no packageset)
<Eickmeyer> vorlon: Were you going to reject redkit?
<Eickmeyer> *redkite
<vorlon> Eickmeyer: I'll reject the current one due to the binary package name, yes
<Eickmeyer> vorlon: Ok. I'll ask teward to upload a new version that's already fixed in git.
-queuebot:#ubuntu-release- New: rejected redkite [source] (groovy-proposed) [0.8.1-0ubuntu1]
<teward> Eickmeyer: dont expect any movement until the weekend on it from me.  Busy with stuff at the apartment tomorrow all day and not online
<teward> (took a work day off too heh)
<Eickmeyer> teward: Thats's OK.
#ubuntu-release 2020-06-26
-queuebot:#ubuntu-release- New binary: rust-sequoia-openpgp [arm64] (groovy-proposed/universe) [0.17.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sequoia-openpgp [armhf] (groovy-proposed/universe) [0.17.0-5] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-xdg-desktop-entry [riscv64] (groovy-proposed/universe) [0.1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: shibboleth-sp [s390x] (groovy-proposed/universe) [3.1.0+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: shibboleth-sp [ppc64el] (groovy-proposed/universe) [3.1.0+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: shibboleth-sp [amd64] (groovy-proposed/universe) [3.1.0+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: shibboleth-sp [arm64] (groovy-proposed/universe) [3.1.0+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: shibboleth-sp [armhf] (groovy-proposed/universe) [3.1.0+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: shibboleth-sp [riscv64] (groovy-proposed/universe) [3.1.0+dfsg1-2] (no packageset)
<LocutusOfBorg> seb128, hello, can we please move libmount1-udeb to main?  libmount1-udeb | 2.35.2-5ubuntu2      | groovy-proposed/universe/debian-installer | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
<LocutusOfBorg> looks like the new eject-udeb provided by util-linux needs it...
<LocutusOfBorg> I don't know why we don't get this on the report...
<LocutusOfBorg> (this makes util-linux progress)
-queuebot:#ubuntu-release- Unapproved: linux-base (bionic-proposed/main) [4.5ubuntu1.1 => 4.5ubuntu1.2] (core)
-queuebot:#ubuntu-release- Unapproved: linux-base (eoan-proposed/main) [4.5ubuntu2.1 => 4.5ubuntu2.2] (core)
-queuebot:#ubuntu-release- Unapproved: linux-base (focal-proposed/main) [4.5ubuntu3 => 4.5ubuntu4] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: linux-base (xenial-proposed/main) [4.5ubuntu1.1~16.04.1 => 4.5ubuntu1.2~16.04.1] (core)
<seb128> LocutusOfBorg, hey, done now
<tjaalton> LocutusOfBorg: your vbox upload for focal is newer than what's in groovy
<tjaalton> -1ubuntu1.20.04.1 > -1
<LocutusOfBorg> tjaalton, damn, will fix :)
<LocutusOfBorg> what do you prefer? 0ubuntu1.20.04? or ~ubuntu1.20.04? I admit I prefer the latter form
<juliank> ubuntu1~20.04?
<juliank> bionic has  5.2.18-dfsg-2~ubuntu18.04.5 and others
<juliank> groovy is  6.1.10-dfsg-1 so I'd go with  6.1.10-dfsg-1~ubuntu20.04.1
<juliank> or  6.1.10-dfsg-0ubuntu20.04.1
<juliank> but the 1~ is clearer
<LocutusOfBorg> yep, I agree
<LocutusOfBorg> tjaalton, done
-queuebot:#ubuntu-release- Unapproved: virtualbox (focal-proposed/multiverse) [6.1.6-dfsg-1 => 6.1.10-dfsg-1~ubuntu1.20.04.1] (ubuntu-cloud)
<LocutusOfBorg> can anybody from ubuntu-archive please delete gajim-rostertweaks https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963604 ?
<ubot5> Debian bug 963604 in ftp.debian.org "RM: gajim-rostertweaks -- ROM; not maintained upstream" [Normal,Open]
<LocutusOfBorg> it is the last blocker for gajim migration
<LocutusOfBorg>     * amd64: r-bioc-rwikipathways
<LocutusOfBorg> this is the only one for r-base migration
<LocutusOfBorg> but it is not in release pocket, why does it complain?
<LocutusOfBorg> vorlon, ^^ hint maybe?
<LocutusOfBorg> we are soooooooooo close for the big migration
<ginggs> ubuntu-archive: could we please remove r-bioc-rwikipathways from -proposed?  it looks like it was uploaded to debian in February and only cleared NEW now, and wants the old bioconductor
<ginggs> The following packages have unmet dependencies:
<ginggs>  r-bioc-rwikipathways : Depends: r-api-bioc-3.10
<RikMills> sil2100: would you perhaps have time to look at plasma-wayland-protocals and kwayland-server in NEW? LP: #1883501 LP: #1884120
<ubot5> Launchpad bug 1883501 in Ubuntu Groovy "[needs-packaging] plasma-wayland-protocols" [Wishlist,Fix committed] https://launchpad.net/bugs/1883501
<ubot5> Launchpad bug 1884120 in Ubuntu Groovy "[needs-packaging] kwayland-server" [Wishlist,Fix committed] https://launchpad.net/bugs/1884120
<RikMills> I cannot land new upstream plasma without those :(
-queuebot:#ubuntu-release- Unapproved: rejected virtualbox [source] (focal-proposed) [6.1.10-dfsg-1ubuntu1.20.04.1]
<seb128> ginggs, r-bioc-rwikipathways removed now
<seb128> LocutusOfBorg, ^
-queuebot:#ubuntu-release- Unapproved: rejected linux-base [source] (focal-proposed) [4.5ubuntu4]
-queuebot:#ubuntu-release- Unapproved: linux-base (focal-proposed/main) [4.5ubuntu3 => 4.5ubuntu3.1] (core, i386-whitelist)
<ginggs> seb128: thanks!
<LocutusOfBorg> thanks seb128 ! I'm also trying to no-change rebuild, I can reupload once everything migrates
<LocutusOfBorg> no change rebuild didn't happen to be effective
<LocutusOfBorg> *fingers crossed*
<ahasenack> is somebody looking at the gcc-10 ftbfs in groovy-proposed?
<xnox> LocutusOfBorg: seb128: all udebs are being demoted... But if things are not migrating it means things are still in flux.
<LocutusOfBorg> xnox, I don't care too much right now, I just want to know how good / bad is util-linux, we can demote them later
<LocutusOfBorg> seb128, libmount1-udeb/amd64 unsatisfiable Depends: libselinux1-udeb (>= 3.0)
<LocutusOfBorg> can you please do the magic again?
<LocutusOfBorg> vorlon, autopkgtest for wcstools/3.9.6-1: amd64: Pass, arm64: Pass, armhf: Pass, i386: Regression â» , ppc64el: Pass, s390x: Pass
<LocutusOfBorg>  can you please do the i386 magic? its not built anymore there
<seb128> LocutusOfBorg, sorry but what action do you need to resolve there?
<coreycb> tjaalton: hello, if you have a moment would you be able to review software-properties in the focal unapproved queue?
<LocutusOfBorg> seb128, libselinux1-udeb move to main?
<seb128> LocutusOfBorg, but xnox said that all udeb are being moved to universe?
<seb128> xnox, has that been done and waiting on publisher or what is the eta?
<xnox> seb128:  an AA needs to process the demotions.... see all the source&binary movements to universe at https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html and https://people.canonical.com/~ubuntu-archive/component-mismatches.html
<xnox> seb128:  from anna to zipl-installer
<xnox> seb128:  d-i in proposed is an empty html page, removing d-i from release pocket will need 3 rebuilds to clean up all the version links, and we are still currently using d-i tarball to build amd64 iso, but there is merge proposal to fix that. But otherwise d-i & udebs have not been usable in groovy since shortly after opening.
<xnox> seb128:  i have a bug open against launchpad to start building groovy with noudebs profile, to stop building them.
<seb128> LocutusOfBorg, where did you see that error? those binaries are not showing on the component mismatch reports
<xnox> seb128:  excuse from britney libmount1-udeb/amd64 unsatisfiable Depends: libselinux1-udeb (>= 3.0)
<xnox> seb128:  on util-linux, because britney checks installability / components missmatch.
<seb128> xnox, why isn't component mismatch catching those?
<xnox> seb128:  because udebs that are in main, still depend on libmount1-udeb, hence libmount1-udeb still needs to be in main.
<xnox> even if they are up for demotion.
<seb128> but it should list libselinux1-udeb to promote then?
<xnox> hmmm true
<xnox> or not, because components missmatches is smarter, and does things over complete closure.
<seb128> LocutusOfBorg, I've promoted since it seems to shorter path to unblock things
<xnox> seb128:  tah.
<xnox> seb128:  hopefully on the next run, libselinux1-udeb will be up for demotion with util-linux-udeb too.
<seb128> right
<seb128> I will keep an eye for those
<LocutusOfBorg> thanks for doing it
<LocutusOfBorg> MIGRATING thanks you all!
<LocutusOfBorg> please remove the r-base block (I did copy-package now)
<seb128> wooot :)
<seb128> thanks and well done LocutusOfBorg ginggs and others
<LocutusOfBorg> :D
<LocutusOfBorg> please remove the r-base block (I did copy-package now)
<seb128> you need someone from the release team for that I think?
<LocutusOfBorg> seb128, how do you feel about doing https://bugs.launchpad.net/debian/+source/node-srs/+bug/1885299 ?
<ubot5> Ubuntu bug 1885299 in node-srs (Ubuntu) "node-srs: kick out from groovy" [Undecided,New]
-queuebot:#ubuntu-release- New binary: barbican-tempest-plugin [amd64] (groovy-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: cinder-tempest-plugin [amd64] (groovy-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: keystone-tempest-plugin [amd64] (groovy-proposed/universe) [0.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ironic-tempest-plugin [amd64] (groovy-proposed/universe) [2.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: manila-tempest-plugin [amd64] (groovy-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: designate-tempest-plugin [amd64] (groovy-proposed/universe) [0.8.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: octavia-tempest-plugin [amd64] (groovy-proposed/universe) [1.4.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted designate-tempest-plugin [amd64] (groovy-proposed) [0.8.0-2]
-queuebot:#ubuntu-release- New: accepted octavia-tempest-plugin [amd64] (groovy-proposed) [1.4.0-2]
-queuebot:#ubuntu-release- New: accepted manila-tempest-plugin [amd64] (groovy-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted barbican-tempest-plugin [amd64] (groovy-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted ironic-tempest-plugin [amd64] (groovy-proposed) [2.0.0-2]
-queuebot:#ubuntu-release- New: accepted shibboleth-sp [amd64] (groovy-proposed) [3.1.0+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted shibboleth-sp [armhf] (groovy-proposed) [3.1.0+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted cinder-tempest-plugin [amd64] (groovy-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted shibboleth-sp [arm64] (groovy-proposed) [3.1.0+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted keystone-tempest-plugin [amd64] (groovy-proposed) [0.4.0-2]
-queuebot:#ubuntu-release- New: accepted shibboleth-sp [riscv64] (groovy-proposed) [3.1.0+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted haskell-xdg-desktop-entry [arm64] (groovy-proposed) [0.1.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-xdg-desktop-entry [ppc64el] (groovy-proposed) [0.1.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-xdg-desktop-entry [s390x] (groovy-proposed) [0.1.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-sequoia-openpgp [armhf] (groovy-proposed) [0.17.0-5]
-queuebot:#ubuntu-release- New: accepted shibboleth-sp [s390x] (groovy-proposed) [3.1.0+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted haskell-xdg-desktop-entry [armhf] (groovy-proposed) [0.1.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-sequoia-openpgp [arm64] (groovy-proposed) [0.17.0-5]
-queuebot:#ubuntu-release- New: accepted haskell-xdg-desktop-entry [riscv64] (groovy-proposed) [0.1.1.1-1]
-queuebot:#ubuntu-release- New: accepted shibboleth-sp [ppc64el] (groovy-proposed) [3.1.0+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted cmake-format [amd64] (groovy-proposed) [0.6.10-2]
-queuebot:#ubuntu-release- New: accepted rust-sequoia-openpgp [amd64] (groovy-proposed) [0.17.0-5]
-queuebot:#ubuntu-release- New: accepted rust-sequoia-openpgp [s390x] (groovy-proposed) [0.17.0-5]
-queuebot:#ubuntu-release- New: accepted haskell-xdg-desktop-entry [amd64] (groovy-proposed) [0.1.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-sequoia-openpgp [ppc64el] (groovy-proposed) [0.17.0-5]
<vorlon> LocutusOfBorg: thanks, gajim-rostertweaks removed
<vorlon> ginggs, seb128: should r-bioc-rwikipathways have needed anything more than a no-change rebuild to get it built against the new ABI?
<vorlon> LocutusOfBorg: wcstools/i386 hinted (and some others)
<RikMills> vorlon: no, they retried a rebuid somewhere and it picks up a hardcoded ABI from the description file or similar.
<vorlon> RikMills: lovely, ok
<vorlon> xnox: you want these udeb-only packages moved to universe, not removed from the archive?
-queuebot:#ubuntu-release- Unapproved: accepted linux-base [source] (focal-proposed) [4.5ubuntu3.1]
<xnox> vorlon:  i want them all removed.
-queuebot:#ubuntu-release- Unapproved: accepted linux-base [source] (eoan-proposed) [4.5ubuntu2.2]
<xnox> vorlon:  but not sure if i am meant to file lots of RM requests....
-queuebot:#ubuntu-release- Unapproved: accepted linux-base [source] (bionic-proposed) [4.5ubuntu1.2]
-queuebot:#ubuntu-release- Packageset: Removed libgit2 from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed mbedtls from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed python-toml from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added gamemode to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added libmetrics-any-perl to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added libtest-memorygrowth-perl to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added libtest-metrics-any-perl to i386-whitelist in groovy
-queuebot:#ubuntu-release- Unapproved: accepted linux-base [source] (xenial-proposed) [4.5ubuntu1.2~16.04.1]
<vorlon> xnox: I would accept one bug report with lots of tasks
<xnox> vorlon: ok!
-queuebot:#ubuntu-release- New binary: shibboleth-resolver [ppc64el] (groovy-proposed/universe) [3.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: shibboleth-resolver [s390x] (groovy-proposed/universe) [3.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: shibboleth-resolver [amd64] (groovy-proposed/universe) [3.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: shibboleth-resolver [arm64] (groovy-proposed/universe) [3.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: shibboleth-resolver [armhf] (groovy-proposed/universe) [3.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: shibboleth-resolver [riscv64] (groovy-proposed/universe) [3.1.0-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted shibboleth-resolver [amd64] (groovy-proposed) [3.1.0-3]
-queuebot:#ubuntu-release- New: accepted shibboleth-resolver [armhf] (groovy-proposed) [3.1.0-3]
-queuebot:#ubuntu-release- New: accepted shibboleth-resolver [arm64] (groovy-proposed) [3.1.0-3]
-queuebot:#ubuntu-release- New: accepted shibboleth-resolver [riscv64] (groovy-proposed) [3.1.0-3]
-queuebot:#ubuntu-release- New: accepted shibboleth-resolver [ppc64el] (groovy-proposed) [3.1.0-3]
-queuebot:#ubuntu-release- New: accepted shibboleth-resolver [s390x] (groovy-proposed) [3.1.0-3]
<LocutusOfBorg> vorlon, wrt r-bioc-rwikipathways, please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963749
<ubot5> Debian bug 963749 in src:r-bioc-rwikipathways "r-bioc-rwikipathways: non-installable in sid" [Serious,Open]
<LocutusOfBorg> if you have some spare cycle, please have a look at this: https://bugs.launchpad.net/debian/+source/node-srs/+bug/1885299 ?
<ubot5> Ubuntu bug 1885299 in node-srs (Ubuntu) "node-srs: kick out from groovy" [Undecided,New]
<LocutusOfBorg> python-tornado can migrate if we kick out two packages already out from Debian testing: 1) https://packages.qa.debian.org/b/bdfproxy.html bug #905782 2) https://packages.qa.debian.org/m/mitmproxy.html bug: #905782.
<ubot5> bug 905782 in MariaDB "Assertion `pageno < ((1ULL) << 40)' failed at ma_pagecache.c:3438: pagecache_read or table corruption on INSERT into a ucs2 table" [Undecided,Fix released] https://launchpad.net/bugs/905782
<LocutusOfBorg> can anybody please give me an hint about what is missing for bsdmainutils to migrate? the britney output looks strange...
<LocutusOfBorg> same for primus-vk
<xnox> vorlon:  https://bugs.launchpad.net/ubuntu/+source/anna/+bug/1885338
<ubot5> Ubuntu bug 1885338 in zipl-installer (Ubuntu) "RM: debian-installer components" [Undecided,New]
<xnox> vorlon:  did you add more tasks to it?
<vorlon> xnox: no
<xnox> hm
<xnox> vorlon:  cause debian-installer is on the list, but i'd like to keep it in main.
<vorlon> yeah I didn't put it there and also haven't removed it
<xnox> also cd-boot-images is on the list, but is not really a udeb thing, and has it's own rm bug
<vorlon> yeah, and initramfs-tools-devices has nothing to do with d-i
<vorlon> and ndisc6 builds debs
<vorlon> so...
<xnox> vorlon:  reading my automation i have them there.
<xnox> something is wrong.
<vorlon> k
<xnox> i guess i should seed debian-installer back in.
<xnox> vorlon:  ok, double checked things by hand, looks fine now.
<xnox> vorlon:  you didn't remove grub-installer and installation-guide => any particular reason?
<xnox> I removed these bug tasks:
<xnox> no longer affects:	debian-installer (Ubuntu)
<xnox> no longer affects:	initramfs-tools-devices (Ubuntu)
<xnox> no longer affects:	libnss-extrausers (Ubuntu)
<xnox> no longer affects:	ndisc6 (Ubuntu)
<xnox> which were false.
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-5.3 [amd64] (bionic-proposed/main) [5.3.0-1030.32~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (eoan-proposed/main) [5.3.0-1031.32] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle-5.3 [amd64] (bionic-proposed/main) [5.3.0-1028.30~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-5.6 [amd64] (focal-proposed/main) [5.6.0-1018.18] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (eoan-proposed/main) [5.3.0-1028.30] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1091.101] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle-5.4 [amd64] (bionic-proposed/main) [5.4.0-1019.19~18.04.1] (no packageset)
<RikMills> vorlon: would you perhaps have time to look at plasma-wayland-protocals and kwayland-server in NEW? LP: #1883501 LP: #1884120
<ubot5> Launchpad bug 1883501 in Ubuntu Groovy "[needs-packaging] plasma-wayland-protocols" [Wishlist,Fix committed] https://launchpad.net/bugs/1883501
<ubot5> Launchpad bug 1884120 in Ubuntu Groovy "[needs-packaging] kwayland-server" [Wishlist,Fix committed] https://launchpad.net/bugs/1884120
<RikMills> I have plasma ready to land that needs those
#ubuntu-release 2020-06-27
<vorlon> RikMills: yep, it's actually been in my stack for a little bit
-queuebot:#ubuntu-release- New: accepted plasma-wayland-protocols [source] (groovy-proposed) [1.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: plasma-wayland-protocols [amd64] (groovy-proposed/none) [1.0-0ubuntu1] (no packageset)
<vorlon> RikMills: debian/copyright looks inaccurate on kwayland-server; the upstream license notices say LGPL 2.1 or 3 or any other version accepted by KDE e.V., but debian/copyright says LGPL 2.1 or later
<vorlon> RikMills: oh n/m, you're only saying LGPL-2.1+ for the packaging
-queuebot:#ubuntu-release- New: accepted kwayland-server [source] (groovy-proposed) [5.19.1-0ubuntu1]
<RikMills> vorlon: thank you! yeah, sorry for multiple pings then...
<RikMills> great. non x86 builders look a bit stuck
<RikMills> don't think I will be landing that tonight then
<RikMills> vorlon: thanks again, and good night!
-queuebot:#ubuntu-release- New binary: plasma-wayland-protocols [riscv64] (groovy-proposed/universe) [1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyside2 [s390x] (groovy-proposed/universe) [5.15.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyside2 [ppc64el] (groovy-proposed/universe) [5.15.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pyside2 [armhf] (groovy-proposed/universe) [5.15.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: plasma-wayland-protocols [ppc64el] (groovy-proposed/universe) [1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: plasma-wayland-protocols [arm64] (groovy-proposed/universe) [1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: plasma-wayland-protocols [s390x] (groovy-proposed/universe) [1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: plasma-wayland-protocols [armhf] (groovy-proposed/universe) [1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (eoan-proposed) [5.3.0-1031.32]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-5.6 [amd64] (focal-proposed) [5.6.0-1018.18]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (eoan-proposed) [5.3.0-1028.30]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-5.3 [amd64] (bionic-proposed) [5.3.0-1030.32~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle-5.3 [amd64] (bionic-proposed) [5.3.0-1028.30~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1048.52]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1091.101]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle-5.4 [amd64] (bionic-proposed) [5.4.0-1019.19~18.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (eoan-proposed/main) [5.3.0-1030.32] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (focal-proposed/main) [5.4.0-1020.20] (core, kernel)
-queuebot:#ubuntu-release- New binary: pyside2 [riscv64] (groovy-proposed/universe) [5.15.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (eoan-proposed) [5.3.0-1030.32]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (focal-proposed) [5.4.0-1020.20]
-queuebot:#ubuntu-release- New binary: pyside2 [amd64] (groovy-proposed/universe) [5.15.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [s390x] (groovy-proposed/universe) [3.10.7+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [ppc64el] (groovy-proposed/universe) [3.10.7+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-rwikipathways [amd64] (groovy-proposed/universe) [1.8.3+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.3 [amd64] (bionic-proposed/universe) [5.3.0-1030.32~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: openblas [ppc64el] (groovy-proposed/universe) [0.3.9+ds-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: qgis [amd64] (groovy-proposed/universe) [3.10.7+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure-4.15 [amd64] (bionic-proposed/main) [4.15.0-1091.101] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure-5.4 [amd64] (bionic-proposed/main) [5.4.0-1020.20~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1063.68] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure-5.3 [amd64] (bionic-proposed/main) [5.3.0-1032.33~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1091.101~16.04.1] (kernel)
<RikMills> if someone is about to accept the plasma binaries in new, it would be appreciated :)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-4.15 [amd64] (bionic-proposed) [4.15.0-1091.101]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-5.4 [amd64] (bionic-proposed) [5.4.0-1020.20~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1063.68]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure-5.3 [amd64] (bionic-proposed) [5.3.0-1032.33~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.3 [amd64] (bionic-proposed) [5.3.0-1030.32~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1091.101~16.04.1]
-queuebot:#ubuntu-release- New binary: openblas [arm64] (groovy-proposed/universe) [0.3.9+ds-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: qgis [armhf] (groovy-proposed/universe) [3.10.7+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [arm64] (groovy-proposed/universe) [3.10.7+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: openblas [amd64] (groovy-proposed/universe) [0.3.9+ds-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: bepasty [amd64] (groovy-proposed/none) [0.5.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: orcania [s390x] (groovy-proposed/universe) [2.1.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: orcania [arm64] (groovy-proposed/universe) [2.1.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: orcania [armhf] (groovy-proposed/universe) [2.1.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: orcania [ppc64el] (groovy-proposed/universe) [2.1.0-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted bepasty [amd64] (groovy-proposed) [0.5.0-2]
-queuebot:#ubuntu-release- New: accepted orcania [armhf] (groovy-proposed) [2.1.0-4]
-queuebot:#ubuntu-release- New: accepted orcania [s390x] (groovy-proposed) [2.1.0-4]
-queuebot:#ubuntu-release- New: accepted orcania [arm64] (groovy-proposed) [2.1.0-4]
-queuebot:#ubuntu-release- New: accepted orcania [ppc64el] (groovy-proposed) [2.1.0-4]
-queuebot:#ubuntu-release- New: accepted openblas [amd64] (groovy-proposed) [0.3.9+ds-3]
-queuebot:#ubuntu-release- New: accepted openblas [ppc64el] (groovy-proposed) [0.3.9+ds-3]
-queuebot:#ubuntu-release- New: accepted r-bioc-rwikipathways [amd64] (groovy-proposed) [1.8.3+dfsg-1]
-queuebot:#ubuntu-release- New: accepted openblas [arm64] (groovy-proposed) [0.3.9+ds-3]
-queuebot:#ubuntu-release- New: accepted pyside2 [amd64] (groovy-proposed) [5.15.0-1]
-queuebot:#ubuntu-release- New: accepted pyside2 [armhf] (groovy-proposed) [5.15.0-1]
-queuebot:#ubuntu-release- New: accepted pyside2 [riscv64] (groovy-proposed) [5.15.0-1]
-queuebot:#ubuntu-release- New binary: orcania [amd64] (groovy-proposed/universe) [2.1.0-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted pyside2 [ppc64el] (groovy-proposed) [5.15.0-1]
-queuebot:#ubuntu-release- New: accepted pyside2 [s390x] (groovy-proposed) [5.15.0-1]
-queuebot:#ubuntu-release- New binary: orcania [riscv64] (groovy-proposed/universe) [2.1.0-4] (no packageset)
#ubuntu-release 2020-06-28
-queuebot:#ubuntu-release- New binary: ldns [ppc64el] (groovy-proposed/universe) [1.7.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ldns [s390x] (groovy-proposed/universe) [1.7.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ldns [arm64] (groovy-proposed/universe) [1.7.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ldns [armhf] (groovy-proposed/universe) [1.7.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ldns [amd64] (groovy-proposed/universe) [1.7.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ldns [riscv64] (groovy-proposed/universe) [1.7.1-2] (no packageset)
<RikMills> if someone is about to accept the plasma binaries in new, it would be appreciated :)
<enyc> hrrm, long standing GTK bugs with touchscreens still exist in ubuntu 20.04  making (just for starters) cinnamon menus unusable by touch activation on  ubuntu-cinnamon-20.04 ....  wondering what is the best route to get unability/qua/etc team to work out where/how to report the right underlying gtk bug properly ?   -- it really needs others with touch to confirm....
-queuebot:#ubuntu-release- New binary: qgis [riscv64] (groovy-proposed/universe) [3.10.7+dfsg-1ubuntu1] (no packageset)
<LocutusOfBorg> vorlon, https://launchpad.net/ubuntu/+source/pocketsphinx/0.8.0+real5prealpha+1-11ubuntu1 can this go on i386 too? ffmpeg wants it
-queuebot:#ubuntu-release- New binary: nettle [amd64] (groovy-proposed/main) [3.6-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: nettle [armhf] (groovy-proposed/main) [3.6-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: nettle [ppc64el] (groovy-proposed/main) [3.6-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: nettle [arm64] (groovy-proposed/main) [3.6-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: nettle [s390x] (groovy-proposed/main) [3.6-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: nettle [i386] (groovy-proposed/main) [3.6-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: nettle [riscv64] (groovy-proposed/main) [3.6-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Packageset: Removed abi-compliance-checker from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Removed api-sanity-checker from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added libinih to i386-whitelist in groovy
-queuebot:#ubuntu-release- New binary: ulfius [arm64] (groovy-proposed/universe) [2.6.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ulfius [armhf] (groovy-proposed/universe) [2.6.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ulfius [s390x] (groovy-proposed/universe) [2.6.7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ulfius [ppc64el] (groovy-proposed/universe) [2.6.7-2] (no packageset)
