#ubuntu-release 2010-08-02
<pitti> good morning
<ttx> Server CD oversized again. I suggest dropping "hplip" in the print-server seed
<ttx> cjwatson, pitti, slangasek: comments from release team welcome ^
<pitti> ttx: currently busy with unbreaking dpkg, will look later
<pitti> ttx: but sure, please go ahead
<ttx> done.
<charlie-tca> I need someone to kick the server for the Xubuntu daily images
<ttx> Current server ISO fails after formatting with "Kernel override 'linux-server' not present"
<charlie-tca> How do we fix it?
<ttx> Found kernels: ''
<ttx> charlie-tca: it's a separate issue
<ttx> (was not meant as an answer to you, sorry :)
<charlie-tca> Oh, okay
<charlie-tca> My error is - W: Failed to fetch file:/srv/cdimage.ubuntu.com/ftp-universe/dists/maverick/main/binary-amd64/Packages.bz2  Hash Sum mismatch
<ttx> hmm, looks like my issue comes from uninstallable lvm2
<ttx> hm, or not.
<ttx> no, that's a separate issue
<cjwatson> pitti: what's wrong with dpkg?
<pitti> cjwatson: it's fixed now
<cjwatson> pitti: yes, but I uploaded dpkg so I'm interested
<pitti> cjwatson: dpkg-builddeb crashed, which caused everything to FTBFS
<pitti> cjwatson: bug 612457
<ubot4> Launchpad bug 612457 in dpkg (Ubuntu Maverick) (and 1 other project) "1.15.8.2 regression: dpkg-deb segfaults (affects: 1) (heat: 8)" [Critical,Fix released] https://launchpad.net/bugs/612457
<pitti> I had it in the #devel topic, but removed it again
<cjwatson> odd, I did test it with a double-build I'm sure :-/
<pitti> cjwatson: it used an sprintf() to fill an exactly allocated buffer without accounting for the extra NUL byte that sprintf() writes
<pitti> that triggered the stack protector
<cjwatson> I assume I can drop the workaround patches on the next merge
<pitti> cjwatson: right, you can
<pitti> cjwatson: I just needed it to get _that_ new dpkg built
<pitti> i. e. it's the PATH setting in debian/rules
<pitti> cjwatson: landed safely in NY?
<cjwatson> charlie-tca: I've kicked a rebuild (without looking very hard)
<cjwatson> ttx: full log?
<cjwatson> pitti: yep, actually was training across from IL
<pitti> cjwatson: train? over the Atlantic?
<cjwatson> IL - i.e. Chicago
<pitti> ah, Illinois, not Ireland, sorry :)
<cjwatson> pitti: thanks for fixing that dpkg bug
<pitti> cjwatson: you're welcome; was a fun morning :)
<ttx> cjwatson: I wonder how best I can capture that
<pitti> release-wise, I got the uninstallables on i386/amd64 all fixed except for lbm, but we got a new abi anyway
<charlie-tca> cjwatson: thank you
<pitti> still fighting against CD overflows, and we have almost no langpack to chop off any more
<ttx> cjwatson: pastebinning full log...
<ttx> cjwatson: http://pastebin.ubuntu.com/472183/
<ttx> cjwatson: I can rerun it in English if need be.
<ttx> there are a few translated messages in there, but they don't seem to apply to the issue directly.
<cjwatson> apt-cdrom is unhappy; I'll have a look when I get to the venue and can update my images
<ttx> cjwatson: ok, let me know if you want a bug about it, and if yes, under which package I should file it.
<pitti> ok, I found three main culprits for the CD size explosion since alpha-2
<pitti> we started to ship git (+6.3 MB), checkbox now copies example-contents data (+6 MB), and ttf-unfonts-core balooned from 12.4 to 20 MB
<pitti> so let's wade through that
<pitti> sbeattie: do you have commit access to checkbox?
<pitti> cr3 seems offline
<pitti> sbeattie: I'd like to throw out the 6 MB of duplicated data files and instead add an example-contents dependency
<pitti> ttf-unfonts and git (via gettext) sorted out
<pitti> so if someone feels like it, he can trigger a CD respin in about an hour, to see where we are
<pitti> (I need to leave in about 15 mins)
<pitti> otherwise tomorrow's dailies should be fine
<cjwatson> apw: how did your investigations with VT handoff and plymouth go?
<cjwatson> pitti: I think best hold off on respins for a bit, since we're mid-kernel-ABI yet again
<pitti> cjwatson: I won't do respins, I need to leave now
<pitti> cjwatson: right now we are still consistently at -13 I think
<cjwatson> yep
<pitti> cjwatson: I pinged apw about whether -14 is for a3; if so, we need lmb and meta (and then of course seeds and di)
<apw> cjwatson, i committed the kernel bits.  i didn't bottom out on how to fix plymouth starting up too early
 * pitti waves good bye then, see you tomorrow
<apw> pitti, yep -14 is meant for a3, and i am assuming ogasawara will upload those shortly (today)
<cjwatson> pitti: I just switched d-i to -14
<cjwatson> and seeds
<pitti> cjwatson: ah, thanks
<cjwatson> apw: I didn't think plymouth starting up early was a problem; I thought we agreed it should be running across the KMS switch, and redraw?
<cjwatson> apw: any progress on getting the bootloader/kernel bit of the interface upstream?  I don't want to put it in grub until that
<apw> not as yet, i was tied up last week finding and fixing some major races in framebuffer setup, which was preventing the new code from being testalbe
<apw> cjwatson, as for plymouth redrawing, yes it should, and with all the patches in we can now survive it occuring, but plymouth isn't doing anything about the switch as yet
<cjwatson> is there an event it can spot now?  I guess the uevent for the new framebuffer appearing?
<apw> yeah there is a new frambuffer appearing message
<slangasek> ttx: hplip> really?  why would you drop support for HP printers?  If you're going to drop printing support, wouldn't you prefer to drop it all?
<ttx> slangasek: why would we ship only HP drivers ?
<slangasek> ttx: what do you mean, "only"?
<ttx> I think hplip can be installed after the print server, *if* you happen to have an HP printer
<slangasek> ttx: all the other packages in that seed are /also/ drivers
<slangasek> so HP printers will be the only ones /not/ working out of the box, AFAICS
<ttx> slangasek: hmm, you mean, the HP printers that require hplip
<ttx> slangasek: but dropping it all might make sense as well
<ttx> it's just that hplip pulls really crappy stuff on the server CD, like sane-backends or libgphoto2
<ttx> because you get much more than a printer driver...
<slangasek> ah
<slangasek> yes, sane-backends doesn't seem like a... sane thing to pull in via the printer seed
<ttx> slangasek: but i'm open to all suggestions. I don't care so much either way :)
<slangasek> so I understand why you would want to trim the seed, I just think doing it this way disadvantages HP printers
<ttx> slangasek: most of the others end up being pulled by cups recommends
<ttx> (like hpijs)
<slangasek> ah
<ttx> hplip notably deosn't, which makes it an easier removal.
<slangasek> interesting, perhaps I should try removing hplip and testing whether printing still works
<ttx> we could have a longer discussion on the pertinence of the print-server task
<slangasek> (but can't do this week, because my printer is 3500 miles away and I won't be able to confirm whether paper was spit out ;)
<ttx> slangasek: for A2 hplip was also the reason why the server CD was oversized, through some abusive depends
<ttx> so I figured I could just get rid of the troublemaker :P
<slangasek> no, java is the reason the CD was oversized, but I guess you don't want to cull that ;P
<slangasek> (hplip was there first! ;)
<ttx> slangasek: you as in me, or you as in the server team ?
<slangasek> :-)
 * ttx wonders if hplip is on the desktop ISO
<ttx> I seem to remember it showed up in the server packages because we were the only one to seed it
<slangasek> Task: ubuntu-desktop, print-server, kubuntu-desktop, kubuntu-netbook, edubuntu-desktop, xubuntu-desktop, ubuntu-netbook
<ttx> another bug in http://ubuntuserverpkgsetreview.appspot.com/?offset=260 then
<slangasek> well, I'm looking at lucid; perhaps it's changed in maverick, though that would be odd
<slangasek> ttx: no, that page lists it as being in the desktop-common seed :)
<ttx> slangasek: that page is supposed to ignore stuff that is seeded otherwise :)
<slangasek> ah
<ttx> or maybe it's just ignored when it's seeded in standard/minimal
<ogasawara> apw, cjwatson: hrm, seems I don't have the permissions to upload linux-backports-modules-2.6.35
<ttx> slangasek: anyway, feel free to restore hplip in the seed if you find a better way to recover 5Mb
<ogasawara> apw: I've got the package on zinc, could you try re-signing and uploading?
<slangasek> ttx: if the drivers are all in hpijs, perhaps we don't need hplip at all; I'll do some testing next week to follow up
<ttx> slangasek: fyi the server ISO is uninstallable right now, see my discussion with cjwatson ~3 hours ago
<slangasek> ttx: apt-cdrom - ack
<slangasek> I'll keep cjwatson supplied with coffee until it's fixed
<ogasawara> apw: tgardner is uploading lbm for me
<cjwatson> ogasawara: you should have permissions now
<ogasawara> cjwatson: thanks
<cjwatson> ttx: currently looking like an apt bug, but I'm still investigating
<cjwatson> apt-cdrom finds the right directories but then apparently drops them
<ogasawara> when an archive admin has a moment, could I get the linux (armel) and linux-backports-modules-2.6.35 (i386 and amd64) accepted from the New queue
<Riddell> ogasawara: doing now
<Riddell> running kernel-overrides will take an hour though
<cjwatson> I'm already running kernel-overrides
<cjwatson> so you can save some time by ctrl-c'ing it ;-)
<cjwatson> it's up to irda-modules here
<Riddell> cjwatson: is kernel-overrides still needed?  seems like everything is in main
<cjwatson> well, it is now because I just ran it :)
<cjwatson> it all gets dumped into universe by default
<cjwatson> accepted linux, anyway
<Riddell> yes but in general it's a very slow way of putting the binaries into main, it's faster to copy and paste the binary package names and put them into a single queue override command
<cjwatson> sure; although the slowness is a Launchpad bug ...
<Riddell> I wonder if there's an actual bug open for that
<cjwatson> I filed one several years ago, I think
 * Riddell accepts linux-backports-modules
<charlie-tca> no kernel found in defined APT sources - xubuntu alternate 386
<charlie-tca> That's bad, right?
<cjwatson> charlie-tca: bug 612665
<ubot4> Launchpad bug 612665 in apt (Ubuntu Maverick) (and 1 other project) "apt-cdrom architecture match always fails (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/612665
<cjwatson> ttx: ^- that's yours too
<charlie-tca> thank you
<pitti> ah, seems the kernel abi transition is done, wonderful
<pitti> I'll build a new set of ubuntu alternates to see where we are size-wise
<ScottK> No publisher run this hour?
<sbeattie> can one of the archive admins please take care of the phpbb3 package that's in binary NEW? It's been there since last week.
#ubuntu-release 2010-08-03
<wgrant> cjwatson, Riddell: Why's it so slow (the script is not public, AFAICT)?
<Riddell> sbeattie: is it needed for a paticular reason?  if not it' my archive day tomorrow and I'll probably get to it.  nobody else is doing regular New processing so it's not unusual for things to be stuck for a week
<Riddell> wgrant: because the soyuz queue command is slow and it runs it once for each binary package
<wgrant> Well, it seems like kernel-overrides could be optimised to call it fewer times.
<wgrant> Making it quicker to start is unfortunately not easy :/
<wgrant> Yay Zope.
<sbeattie> Riddell: it's not strictly necessary, but the security team has some tracking scripts that whinge when package sources disappear from the archive.
<sbeattie> Riddell: tomorrow is fine.
<Riddell> wgrant: on my archive admin days a significant amount of my time is spent waiting for the queue command, it's probably one reason why I'm the only active archive admin left
<wgrant> Riddell: Do you normally need to do per-binary overrides, or would the current web UI suffice?
<wgrant> Making that quicker isn't terribly difficult.
<Riddell> never used the web UI, didn't know one existed
<ScottK> Riddell: That's what I have to use.
<wgrant> Riddell: https://launchpad.net/ubuntu/maverick/+queue
<wgrant> Doesn't let you do per-binary overrides, but is otherwise not bad.
<ScottK> It is however, unreliable.
<ScottK> It's not at all rare to get timeouts on it, particularly when doing multiple packages.
<Riddell> it would help a bit if binarie were put into the component their source is in by default
<wgrant> If you have complaints, tell us (or maybe just me)!
<wgrant> It's not deliberately painful, and a lot of things are easily fixed.
<ScottK> wgrant: When it fails, I retry a few times and if it's consistent, I complain.
<wgrant> ScottK: Right, we know about the timeouts.
<wgrant> It's the other issues that seem to also be causing real problems that I'm worried about.
<ScottK> Functionally, the lack of per binary overrides is the main thing I miss.
<ScottK> wgrant: Speaking of timeout issues, Error ID: OOPS-1675E1545 is not rare on https://launchpad.net/ubuntu/+source/kde4libs/+publishinghistory
<ubot4> https://lp-oops.canonical.com/oops.py/?oopsid=1675E1545
<ScottK> Retry worked (as it often does).
<cjwatson> wgrant: the problem is that if you call queue on a bunch of binary packages then it takes O(N^2) time
<cjwatson> which is stupid
<cjwatson> so you have to trade off the cost of repeatedly executing queue against the cost of having it override N times as many times as it needs to
<cjwatson> bug 241129
<ubot4> Launchpad bug 241129 in soyuz "'queue override' command scales at O(n^2) with the number of packages on the commandline (affects: 1) (dups: 1) (heat: 4)" [Medium,Triaged] https://launchpad.net/bugs/241129
<wgrant> cjwatson: Hm, that's pretty awesome.
<pitti> Good morning
<ttx> slangasek: the server ISO is under size now, with hplip still in there, so we could revert the hplip seed change
<ttx> amd64 is at 699 Mb though
<ttx> I'd still want to try out at alpha3 how usable is print-server without hplip
<pitti> finally! compiz installable again; now waiting for the ecore/edje/elementary stuff to become installable, then we can trigger some images
<pitti> in fact, after this publisher run finishes we can trigger amd64/i386 images
<pitti> alternates and desktops triggered for all flavours
<pitti> first images posted to tracker
<pitti> ara: ^ FYI
<ara> pitti, great, thanks!
<ogra> pitti, do i get in your way if i fire off an armel build ?
<Riddell> smoke testing today's kubuntu daily live, seems in reasonable shape, installs fine
<pitti> ogra: doesn't work yet
<pitti> ogra: we still need some time to sort out the giant FTBFS mess of the new e* stack
<pitti> ogra: but if you have an image without netbook-launcher, go ahead of course
 * pitti binNEWs edje
<pitti> ogra: FYI, in 1.5 hours I can retry "elementary", so around 18:00 CEST we hopefully have installable arm again
<pitti> ara, Riddell, all: all alternate builds posted
<pitti> ttx: ^ server, too
<pitti> smoser: can you please add the UEC images to the tracker, too?
<ttx> pitti: ack
<pitti> ubuntu/kubuntu-netbook posted, too
<pitti> Riddell: ^ FYI
<smoser> pitti, i've never added anything to the tracker myself.
<pitti> smoser: ah, who does that usually, for the URC images?
<smoser> slangasek, will usually do the UEC images, ara has done them before though. slangasek has a script which takes something like http://uec-images.ubuntu.com/server/maverick/20100803.1/published-ec2-daily.txt as input
<pitti> Riddell: oops, just saw the kubuntu-meta upload; I guess you want a rebuild for that?
<ttx> pitti: note that server will need to be respinned to get the last eucalyptus in, should land eod today.
<pitti> ttx: sure
<pitti> ttx: I'm just happy that after all this wrangling with soyuz and cd space, we even have buildable CDs now, so I wanted to build them now before everything breaks all over again :)
<pitti> but no problem to do respins
<pitti> ttx: first smoketest appreciated, though
<ttx> of course
<Riddell> pitti: kubuntu netbook? that doesn't exist any more
<pitti> Riddell: hm, why do we still build them then?
<Riddell> I thought we didn't
<pitti> Riddell: ok, I can take them off the tracker and remove them from the cronjb
<Riddell> they are commented out in the crontab
<Riddell> pitti: we're still waiting for the last KDE 4.5.0 packages to get published, I'd also like the packagekit update and of indeed the meta packages on there
<pitti> Riddell: ok; can I ask you to trigger a respin once that's done? my afternoon is full of meetings, and I have a presentation to give at 1400 UTC, too
<Riddell> yes I can do that
<pitti> Riddell: cheers
<pitti> Riddell: ok, so I'll ignore the current kubuntu desktop build
<pitti> i. e. not add it to tracker
<ScottK> libmail-dkim-perl depends on libdigest-sha-perl, which is in Universe.  It has an approved MIR from some time ago (Bug #243306).  I'm not sure why that doesn't show up on the problems page, but would someone please promote libdigest-sha-perl.
<ubot4> Launchpad bug 243306 in libdigest-sha-perl (Ubuntu) "MIR for libdigest-sha-perl (heat: 4)" [Undecided,Fix released] https://launchpad.net/bugs/243306
<ogra> pitti, sigh, asac promised to be careful :P
<pitti> ogra: well, he had the entire stack synced, and it has very sloppy build deps
<pitti> but we are almost through now, just two more hours :)
<ogra> pitti, i know, i wouldnt have acked the sync right before A3 if i had known it needs the whole stack new
<pitti> let's just hope that it'll actually work :)
<ogra> we're far from being ready with the settings and i had planned to adjust them until A3
<pitti> oh, hmm
<pitti> netbook-launcher-efl needs a rebuild, too
<pitti> against the -06 ABI
<pitti> it currently depends on *-05
<pitti> ogra: ^ mind uploading that?
<ogra> i thought asac pulled a new upstream version in
<pitti> https://edge.launchpad.net/ubuntu/+source/netbook-launcher-efl/+changelog
<pitti> last upload is from April
<ogra> afaik that was the whole reason for doing the syncs of the efl stack
<pitti> maybe he's planning to
<pitti> -> #u-desktop
<ogra> thats what i understood
<davmor2> pitti: wubi is broken still.  Drops straight into grub shell on first boot after installing on windows side
<slangasek> ttx: revert the seed change> your call :)
<ttx> slangasek: I'll keep it that way. We can revert for beta :)
<ScottK> slangasek: If you have a moment, would you please promote libdigest-sha-perl?  See channel scrollback from ~2 hours ago for details.
 * Riddell builds Kubuntu CDs
<smoser> slangasek, when you get a minute, can you populate iso tracker with http://uec-images.ubuntu.com/server/maverick/20100803.1/published-ec2-daily.txt
 * Riddell builds kubuntu CDs again
<Riddell> smoser: added please check I got that right http://iso.qa.ubuntu.com/qatracker/build/ubuntuserver/all
<smoser> did you do it by hand ?
<Riddell> how else do you do it?
<smoser> slangasek, has a script.  and the serial numbers are supposed to be the ami ids :-(
<smoser> slangasek, how about providing me with that script, so next time i ask someone else i can say "use this, its easier"
<Riddell> ScottK: libdigest-sha-perl moved to main
<slangasek> smoser: the script isn't done yet, it still has to be edited for each new milestone; I'm working on fixing that today
<smoser> slangasek, thanks. i didn't mean to pester. only to save other people time and heartache
<slangasek> smoser: it's not pestering, this is something I've needed to get done for a couple of months now to eliminate myself as SPOF :)
<Riddell> new kubuntu CDs up, added to tracker
<charlie-tca> Can we have the xubuntu Desktop images added to the tracker?
<pitti> Riddell: yippie
<pitti> charlie-tca: looking
<charlie-tca> Thanks
<pitti> charlie-tca: sorry, had an afternoon full of meetings, got a bit sidetracked from the release stuff
<charlie-tca> no problem
<charlie-tca> I ran some anyway
<pitti> done
<charlie-tca> Thank you
<Riddell> is there such a thing as SRU freeze for 10.04.1?
<pitti> Riddell: yes, there is
<pitti> Riddell: we had to inflict it so that we can test CDs built from -proposed for a while
<Riddell> pitti: so that's still in place?
<pitti> yes, it is
<Riddell> pitti: where was that announced?
<pitti> Riddell: shoudl have been during the sprint
<seb128> it was not announced
<Riddell> that seems rather a problem
<seb128> Riddell, right, thanks to the lack of r-m I guess but that should be fixed rsn
<slangasek> smoser: AMIs posted; script finished; lp:~ubuntu-archive/ubuntu-archive-tools/trunk/post-amis-to-iso-tracker.py
<smoser> slangasek, thanks.
<slangasek> pitti: ^^
<pitti> slangasek: thanks
<smoser> regarding the amis... well, we're re-spinning :)
<smoser> but the script is great.
<slangasek> pitti: sure!  sorry it took so long
<slangasek> smoser: 'sok, really easy to post the new ones when they're ready ;)
<pitti> slangasek: did you meet Kate yet? say hello from me
<slangasek> pitti: I did - you know Kate?
<pitti> slangasek: not yet :)
<slangasek> heh :)
<pitti> but let's say, I'm not at all unhappy about getting back a RM
<slangasek> right :)
<pitti> good night everyone
<pitti> no -efl tody, so no arm images
<ScottK> Riddell: Thanks.
#ubuntu-release 2010-08-04
<smoser> slangasek, or pitti can someone post http://uec-images.ubuntu.com/server/maverick/20100803.2/ to tracker ?
<smoser> slangasek, wrote lp:~ubuntu-archive/ubuntu-archive-tools/trunk/post-amis-to-iso-tracker.py to aid in doing that. it takes input from http://uec-images.ubuntu.com/server/maverick/20100803.2/published-ec2-daily.txt
<slangasek> smoser: done
<smoser> gracias
<smoser> can someone (slangasek?) populate the UEC images for iso testing ? use 20100803.2
<pitti> Good morning
 * pitti promotes liblauncher to main, so that we can build the new -efl
<pitti> ogra: ^ FYI
<pitti> darn, 2 minutes after publisher
<ttx> pitti: do you have the keys to nominate UEC images into the ISO testing tracker ? They are still missing...
<ttx> "Ubuntu Server UEC amd64" and "Ubuntu Server UEC i386"
<ttx> we want them to point to 20100803.2
<pitti> oh, I thought slangasek did that last night
<ttx> he did the EC2 ones
<ttx> not the "UEC" flavour
<pitti> hm, so I never did that, but let's have a look at Steve's new script
<ttx> there is no publication to do, just an entry to the ISo tracker
<ttx> (but I have no idea how to trigger that)
<pitti> ttx: so how do I get the AMI numbers?
<ttx> there is no AMI number for the UEC cloud images
<pitti> ah, os it's literally just 20100803.2 ?
<ttx> I think so -- it's the tarballs that are at the bottom of http://uec-images.ubuntu.com/server/maverick/20100803.2/
<ttx> I just need the entries on the tracker so that we can register test results -- they just need to say "20100803.2"
<ttx> test cases describe where to find them
<pitti> ttx: ok, sorry for the confusion; how is that?
<ttx> so it should really just be two SQL entries
<ttx> \o/
<ttx> perfect !
<ttx> I might bug you in a few to bump the build score for eucalyptus (when it is uploaded) so that we respin at the earliest possible
<ttx> Daviey is still running a few tests
<pitti> sure
<pitti> ttx: buildds are idle, though
<Daviey> within an hour, it should be uploaded
<Daviey> pitti: Hmm.. i tried a PPA build and that seems to be doing badly.. been uploaded +25mins, wait time let est. 24mins
<pitti> right, PPAs are clogged
<pitti> let me know if you need a PPA build score bump
<Daviey> it would help :)
<pitti> I just looked at the ubuntu builders
<pitti> Daviey: url?
<Daviey> https://edge.launchpad.net/~davewalker/+archive/uec-devel/+build/1903331
<pitti> done
<pitti> next in line now
<Daviey> \o/
<Daviey> thanks
<ttx> pitti: got a question for you. the new eucalyptus adds a recommends:tgt, a mir was filed and accepted for tgt. If we rush build->publish->respin would tgt be blocked in component-mismatches and not reach the cd ?
<pitti> ttx: no, recommends just get ignored
<pitti> they would appear in c-m, but wouldn't render it uninstallable
<ttx> ok
<ttx> arh.
<ttx> apparently there is another one for which MIR wasn't processed yet
<ttx> https://bugs.edge.launchpad.net/ubuntu/+source/libcrypt-openssl-x509-perl/+bug/609992
<ubot4> Launchpad bug 609992 in libcrypt-openssl-x509-perl (Ubuntu Maverick) (and 1 other project) "[MIR] libcrypt-openssl-x509-perl (affects: 1) (heat: 432)" [Wishlist,New]
<ttx> pitti: so it would not reach the CD ?
<pitti> ttx: no
<pitti> oh, is that a dependency?
<ttx> no it's a recommend as well
<ttx> Daviey: right ?
<pitti> ttx: I can pre-promote it, looks relatively harmless
<ttx> pitti: that would be great.
 * pitti does and updates the bug
<Daviey> ttx: yes
<Daviey> pitti: I just pinged lool, asking for a MIR review
<Daviey> I assume he's be working shortly.. hopefully he'll be able to look at it.
<ttx> pitti: since the tgt mir was accepted, is there any way to pre-approve it so that it's accepted on the CD as well ?
<pitti> "accepted" == "approved"?
<pitti> ttx: can do, yes
<ttx> https://bugs.launchpad.net/ubuntu/+source/tgt/+bug/594372
<ubot4> Launchpad bug 594372 in tgt (Ubuntu Maverick) (and 7 other projects) "MIR: tgt (affects: 1) (heat: 85)" [Medium,Fix released]
<pitti> ttx: ah, sure
<pitti> "released"? oh
<pitti> so, it's released now, promoted
<Daviey> \o/
<pitti> right in time for this publisher
<ttx> hm, looks like I shouldn't have fixreleased it
<ttx> we should have waited for the dependency to show up
<ttx> pitti: ok, so now if we upload the new eucalyptus that has those new recommends, build/.publish/respin, the CD should magically get all of those without further human interaction ?
<pitti> right
<ttx> cool, thx
<ttx> pitti: ok, uploaded, "Start in 4 seconds" for the last minute or so
<pitti> buildds are very slow again unfortunately
<ttx> https://launchpad.net/ubuntu/maverick/+source/eucalyptus/2.0~bzr1218-0ubuntu1
<pitti> I mean, the queue builder to actually assign a build to a buildd
<ttx> ah, ok
<pitti> ttx: how long does it build?
<ttx> ~20 min
<pitti> ah, should be fine
<ttx> yep
<pitti> we have 40 mins until next publisher
<wgrant> pitti: That slowness should be pretty much fixed in a week, FWIW.
<wgrant> Although some of it will remain until the next LP release.
<pitti> wgrant: ooh!
<pitti> wgrant: do you know what causes it?
<pitti> some days ago they were fast again, and now they are back to slow; I didn't quite see a pattern there
<wgrant> It's possible it won't get merged in time, but it should.
<pitti> there is no large build queue right now
<wgrant> pitti: It's mostly to do with the number of builds that have finished since the last scanning cycle.
<pitti> well, PPAs have, but they are always full anyway
<wgrant> A few days ago most of the PPA builders were gone, so there weren't many builds finishing.
<wgrant> So it scanned quickly.
<pitti> aah
<pitti> right, that was it
<wgrant> But now there are lots of builds finishing, and the upload processor takes ~15s per upload, and runs synchronously.
<wgrant> So then it doesn't scan for ages... leaving time for lots more builds to finish.
<ttx> pitti, Daviey: packages built, willbe picked up by next publisher run
<Daviey> \o/
<pitti> nice
<ttx> time for coffee, then !
<pitti> ttx: so, once they are published, I'll rebuild server ISOs and re-post
<pitti> ttx: do we also need to update the UEC/EC2 images?
<ttx> pitti: no
<ttx> only the ISO
<ttx> the ISOs
<pitti> ok
<Daviey> pitti: If you notice it's published before I do, would you be kind enough to ping me please? :)
<pitti> Daviey: I set up a trigger to respin server ISOs as soon as it's published
<pitti> Daviey: but if you need to do anything in between, I can stop it and ping you instead
<Daviey> pitti: oh, interesting.. it's not a curl + grep + if statement + ./spin_cd.sh .. is it? :)
<pitti> Daviey: something like that, yes
<Daviey> nice :)
<pitti> it checks antimony's local mirror
<pitti> $ wait-for-package eucalyptus-cloud_2.0~bzr1218-0ubuntu1 && for-project ubuntu-server cron.daily
<Daviey> ahh.. much better :)
<ttx> pitti: 20100804.1 is up on cdimage, could you bump the ISo testing tracker reference ?
<pitti> ttx: already at it
<pitti> http://cdimage.ubuntu.com/ubuntu-server/daily/20100804.1/
<pitti> ttx: UEC, too?
<ttx> no
<pitti> Daviey: ^
<ttx> just ISO/amd6' and ISO/i386
<pitti> ttx: done
<ttx> pitti: thanks !
<Daviey> ah, super - thanks
<ttx> hm, the UEC install fails. Missing tgt deps on CD
<ttx> libibverbs1 librdmacm1 libconfig-general-perl
<ttx> grumble
<pitti> meh
<ttx> pitti: looks like those also need to be cleared, they are in https://bugs.launchpad.net/ubuntu/+source/tgt/+bug/594372
<ubot4> Launchpad bug 594372 in tgt (Ubuntu Maverick) (and 7 other projects) "MIR: tgt (affects: 1) (heat: 85)" [Medium,Fix released]
<Daviey> ttx: Hmm
<Daviey> i got the same results
<ttx> Daviey: they have not been promoted yet, only tgt was
<pitti> ttx: right after publisher start :-/
<ttx> arh :)
 * pitti promotes
<Daviey> :(... pitti, did those depends show in CM?
<pitti> yes
<ttx> pitti: it needs to be picked up by a publisher run ? arh!
<pitti> I now verified that those three don't have any further universe depends
<pitti> sorry, but http://people.canonical.com/~ubuntu-archive/component-mismatches.txt is a real mess right now, not easy to see what's relevant
<pitti> a lot needs to be fixed in packages themselves
<Daviey> wow, just looked at CM.. it's huuuuge
<ttx> pitti: so ETA is like... 90min ?
<pitti> ttx: more like 2 hours
<ttx> ok
<Daviey> pitti / ttx: I trust the ant CM won't be an issue?
<pitti> no, most there aren't
<ttx> pitti: could we mark the two ISO entries as "rebuilding" so that nobody wastes any ISo tseting effort ?
<pitti> report.html on the cdimage directories is the interesting part
<pitti> ttx: sure
<pitti> done
<ttx> great
<pitti> http://cdimage.ubuntu.com/ubuntu-server/daily/20100804.1/report.html
<pitti> right
<pitti> sorry, we should have checked that right away
<ttx> no problem, I didn't intend to do that much testing over lunch hour anyway :)
 * Daviey has some admin he should be doing anyway.. :)
<Daviey> pitti: Thanks for sorting that out.
<pitti> let's see who wins first - netbook armel or server :)
<pitti> looks like they could both make it at the same time now
<Daviey> ttx: Is that likely to put us oversize?!
<ttx> there is some risk
<pitti> on amd64, could be
<ttx> for some reason hplip is still in there
 * Daviey files a remove from archive bug report.. that'll teach it a lesson! ;)
<ttx> I wonder why though
<ttx> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.maverick/print-server shows it's no longer in the seed
<Daviey> ttx: is hplib on both i386 and amd64, or you've only seen it on amd64?
<ttx> bah
<ttx> Ubuntu.Maverick server-ship seed
<ttx> it was in duplicate places
<Daviey> ttx: If you can modify the seed before this is spun, then we should be ok on size?
<ttx> I can modify the seed, not sure if that will be taken into account in time for the spin though
<ttx> pitti: ^ ?
<Daviey> pitti: Does the spin process re-germinate?
<pitti> the publisher runs germinate
<ttx> ok, lets try this then
<pitti> but ship doesn't have a Task: header
<pitti> so I think this should get effective immediately on CD image build
<pitti> ttx: do the server-ship seed change now, and I'll rebuild a test image to verify that hplip is gone
<pitti> Task: ubuntu-desktop, kubuntu-desktop, kubuntu-mobile, kubuntu-netbook, edubuntu-desktop, xubuntu-desktop, ubuntu-netbook
<pitti> it seems gone from the print-server task, anyway
<pitti> that's the bit which needs 2 publishers
<ttx> changed, committed and pushed
 * ttx greps for hplip to make sure it's really dead now
<ttx> pitti: in unrelated news I'll soon polish and propose an alternative chart for the work-items-tracker
<ttx> it skips weekend days and concentrates on work done and velocity
<pitti> ah, nice
<ttx> see before: http://people.canonical.com/~ttx/before.svg
<ttx> and after: http://people.canonical.com/~ttx/after.svg
<ttx> it looks better in cases where work items keep being added during the subcycle
<pitti> but isn't that what you should avoid usually?
<ttx> in agile, I'd say yes
<pitti> it would stop showing you when you have to postpone stuff or involve more people because you are running behind
<ttx> since feature creep is bad
<pitti> running over trend line has been very useful
<pitti> showing it, I mean
<ttx> well, my graph still shows that
<ttx> if you don't postpone enough, the dotted line will look unrealistic
<ttx> this one avoids you having to reset the trends line after you postpone stuff
<Daviey> ttx: burn up chart :)
<ttx> it concentrates on your velocity, which is hard to derive from the before.svg
<ttx> pitti: anyway, it should be opt-in
<ttx> the default should still be the "regular" one
<pitti> I guess I first need to convince Clint Byrum to reduce the per-user charts
<pitti> they take awfully long
<ttx> heh, I'm not surpised by that
<ttx> not even surprised
 * ttx goes to lunch while the publisher sleeps
<ttx> pitti: how did your  test image rebuild go ? No more hplip ?
<pitti> building now; sorry, was looking at n-l-efl
<ttx> ok, back in ~1h
<pitti> ttx: http://cdimage.ubuntu.com/ubuntu-server/daily/20100804.2/
<pitti> looks good
<pitti> 682M amd64
<pitti> publisher done \o/
<pitti> so, one more publisher to go to for the tgt dependencies to propagate to main
<Daviey> pitti: splendid!
<ara> pitti, ogra: are these two builds supposed to be in the tracker?
<ara> Netboot arm dove (20100803)  	0/1  	None  		
<ara> download info Netboot arm imx51 (20100803)
<pitti> ara: no
<pitti> ara: still fighting to get netbook-laucher-efl built
<ogra> we still build them, but they are not tracker worthy
<pitti> ara: ETA 2.5 h
<pitti> ara: the current images are uninstallable
<ogra> pitti, add another 2-2.5h for the image builds
<pitti> oh, oops; I accounted .5 h
<pitti> so, 4.5 h then
<ara> pitti, ok, thanks for the update, can you mark them as "rebuilding" so people don't get confused?
<ogra> well, the armel buildds have USB disks
<pitti> ogra: that's quite long -- I thought image builds would by and large need IO, and not much CPU
<ogra> dont expect high speed :)
<pitti> ara: I didn't think I added them in the first place?
<pitti> ara: ah, sorry; "netboot"
<pitti> I misread as "netbook"
<ara> :D
<ogra> netboot should vanish from the tracker completely
<pitti> ara: done
<pitti> ogra: no netboot for arm?
<pitti> ok, I can disable them
<ara> pitti, thanks
<pitti> ogra: done
<ogra> pitti, as long as they dont break d-i buiulds i'm happy to keep them building, but they dont need to be on the tracker
<pitti> FTR, I went to all the red bugs and triaged/commented them; wubi and offline OEM are broken, the rest looks good so far
<pitti> ev: if you have some minutes, could you have a look at bug 613288 and bug 600578? do we need any further information?
<ubot4> Launchpad bug 613288 in ubiquity (Ubuntu) "wubi installation failed - boot configuration store could not be opened (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/613288
<ubot4> Launchpad bug 600578 in wubi "installer drops into grub shell after rebooting from windows. (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/600578
<pitti> (they might be duplicates, but hard to say for me)
<pitti> ev: especially the latter confuses me -- I thought wubi would always start right out of windows, and not touch grub etc.?
<ara> pitti, it does add an entry in the grub menu, so it looks like another partition, when it is not
<ara> http://blog.cyphermox.net/2010/06/wubi-installing-ubuntu-inside-windows.html
<pitti> ara: ah, thanks
 * pitti never saw it
<pitti> then again, I just ordered a new laptop, which will come with the unavoidable win 7
<pitti> so for the first time in years I will actually have an otherwise useless windows to test those bits :)
<ara> :)
<pitti> I'm out for a quick lunch; can't do anything for the next 40 mins anyway
<ara> enjoy your meal!
<pitti> re
<pitti> ara: I did, thanks
<pitti> ttx: ok, tgt seems happy again, triggering images
<ttx> pitti: heh, holding my breath :)
 * ara -> lunch
<ttx> pitti: published, looks ok at first glance
<ttx> pitti: if they look ok to you too, please promote to ISO tracker
<pitti> ttx: http://cdimage.ubuntu.com/ubuntu-server/daily/20100804.3/report.html looks spotless
<pitti> so it should be fine
<pitti> ttx: congrats, you won the race against netbook/armel :)
<ttx> yay
<ttx> server wins again
<pitti> added to tracker
<ttx> thx
<pitti> ttx: anything new in server-land which should be mentioned on https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview ?
<ttx> pitti: I'll have to think about that. smoser will probably have a blurb abour kernel upgrades in cloud images
<charlie-tca> pitti: Can we have a note that Xfce4 was upgraded to the current 4.6.2 release?
<charlie-tca> Also, the systray bug is gone in Xubuntu. Should I update the notes?
<pitti> charlie-tca: oh, that bug is still open
<pitti> charlie-tca: I'm currently editing some GNOME parts, but please do afterwards; I'll ping you
<charlie-tca> Thanks
<pitti> charlie-tca: please go ahead
<charlie-tca> Thank you
<Daviey> ttx: Trying the new iso now
<ttx> Daviey: I'm on topology1 as well
<Daviey> ttx: I just noticed it was published, so you have a head start
 * Daviey contemplates a cron job to check for new ISO's and email him.
<ttx> Daviey: you mean you are not subscribed to the new candidates yet ?
<davmor2> pitti: was the log I added to the wubi bug any use to you?
<pitti> davmor2: not sure; I pinged ev about it
<pitti> davmor2: it didn't show any error, anyway
<Daviey> ttx: The subscribe button on iso.qa.ubuntu.com doesn't seem to work
<ttx> ara: ^ ?
<davmor2> Daviey: are you logged in?
<Daviey> It's showing that i am.
<Daviey> i can try cycling
<davmor2> Daviey: hang on a second
<davmor2> Daviey: it's working here
<ttx> Daviey: so the all-in-one installs now
<Daviey> http://iso.qa.ubuntu.com/qatracker/test/4389 -> hit Subscribe -> nothing shows in "My Subscriptions"
<ttx> Daviey: rebooting to see if it starts
<davmor2> Daviey: have you selected the test to subscribe to the checkbox on the right?
<Daviey> ttx: groovy.. is it worth me replicating that... ISO has just finished burning
<Daviey> davmor2: err, "no comment"... /me sulks away thinking about moaning to mpt about usability :)
<ttx> Daviey: registration fails, might be the bug you ran into
<davmor2> Daviey: you need to select the tests with the checkboxes and then click on subscribe.  The person icon will change to colour when you click on subscribe
<Daviey> ttx: In that case, i'll give it a spin
<Daviey> see if i get the same result
 * ttx reboots to see if that's transient
<ttx> I'm pretty sure it is
<davmor2> Daviey: At the time it was the only it could be setup, there are possibly better ways now
<Daviey> davmor2: Oh aye.. i just thought i could go to the page and hit subscribe.. I've mastered it now :)
<Daviey> Thanks davmor2
<davmor2> Daviey: np's
<ttx> Daviey: beh, it looks very brittle
<Daviey> ttx: Did it work that time?
<ttx> no
<ttx> crptic "can't register, log in through admin interface and check cloud status" error message
<Daviey> Hmm.. i saw that before
<ttx> that's a useless catchall error.
 * pitti tries a btrfs install from desktop
<pitti>  netbook-launcher-efl : Depends: libevas-svn-05-engines-x but it is not installable
<pitti> gar, what now??
<pitti> ogra: ^ not our day
<pitti> it's libevas-svn-06-engines-x now
 * pitti pings asac
<ttx> Daviey: we should move that discussion to #ubuntu-server
<Daviey> agreed
<ogra> pitti, hmm
<pitti> ogra: I uploaded a fix
<ogra> just a dependency issue i guess ?
<pitti> yes
<pitti> hardcoded -05- abi in depends:
<ogra> yeah
<ev> pitti: replied to both Wubi bugs.  I'm going to be a bit difficult to reach today as Debconf is going on a field trip and the hotel wifi is spotty at best.  Give me a ring on my cell if any further issues arise.
<pitti> ev: ah, thanks; I just documented it for now, I don't think we shold block the release on it
<pitti> ev: enjoy debconf!
<pitti> ev: ah, thanks for the replies
<ev> sure thing, and thanks!
<pitti> ah, btrfs desktop install works flawlessly, great job cjwatson/ev
<highvoltage> whohoo!
<pitti> ogra: do we need bug 600478 for alpha-3 really?
<ubot4> Launchpad bug 600478 in livecd-rootfs (Ubuntu Maverick) (and 2 other projects) "livecd.sh should remove foreign subarch headers during livefs build (affects: 1) (heat: 127)" [Medium,Confirmed] https://launchpad.net/bugs/600478
<pitti> ogra: the description makes it sound like an optimization thing, so we could also defer it?
<ogra> yeah
<ogra> fine for post A3
<pitti> ogra: also, bug 605972
<ubot4> Launchpad bug 605972 in jasper-initramfs (Ubuntu Maverick) (and 1 other project) "Need to set hostname to ubuntu during first boot. (affects: 1) (heat: 246)" [Medium,New] https://launchpad.net/bugs/605972
<ogra> yeah
<pitti> ogra: this sounds a bit strange -- isn't that something that should be done server-side on image cration?
<ogra> that could be done at creation time too, but given that jasper functions similar to casper the logical solution would be to set it the same way
<ogra> its cosmetic anyway and you only see the buildd hostname if you swithc to a console while oem-config runs
<pitti> ogra: ah, oem-config will fix it, too
<ogra> i was actually planning to fix both before A3 but that was at a time when i thought i'd have images on monday :P
<pitti> ok, moving to beta then, thanks for the heads-up!
<ogra> thanks for notifying :)
<pitti> ogra: bug 600359 looks more serious -- sounds like it could seriously break armel boots?
<ubot4> Launchpad bug 600359 in ureadahead (Ubuntu Maverick) (and 1 other project) "ureadahead generating oom messages during boot. (affects: 2) (heat: 16)" [Medium,Confirmed] https://launchpad.net/bugs/600359
<pitti> perhaps we should disable ureadahead on armel as a workaround, WDYT?
<pitti> or isn't it that common?
<ogra> well, it doesnt break but kills the splash
<ogra> its common on all beagle C series boards (256M)
<pitti> ah, it could kill just about anything, no?
<ogra> on the XM (512M) i havent seen it yet since we have more serious errors there
<ogra> (cant boot at all atm due to MMC issues)
<ogra> i havent seen it on the omap4 boards and i suspect it also wont happen on the XM once we can verify
<ogra> (i had actually hoped tim gardners fix would make it go away)
<pitti> ogra: that's what I initially thought, but I asked on the bug, and it still seems to happen
<ogra> right
<pitti> ogra: I'll move bug 605831 to beta as well then?
<ogra> yeah
<ogra> unlikely that we get it fixed today
<pitti> ogra: sorry for all those pings, but I'm cleaning up teh alpha-3 checklist to ensure that we didn't forget anything really serious
<ogra> yeah, dont worry, i usually do that on friday before the release team meeting
<ogra> just ping away as needed :)
<davmor2> pitti: I've added a reply to ev, with set debug=all inplace it's still droping straight into grubshell with no text other than the standard Gnu Grub Shell info.
<pitti> davmor2: thanks
 * pitti looks at https://bugs.edge.launchpad.net/ubuntu/maverick/+bugs?field.searchtext=&orderby=status&field.milestone%3Alist=27561 and is much more satisfied now
 * pitti release-notes the last one
<ogra> pitti, btw, seems n-l-efl is in the archive now
<ogra> so we should be able to build images
<pitti> ogra: yay!
<pitti> http://people.canonical.com/~ubuntu-archive/testing/maverick_probs.html
<pitti> it indeed just dropped from there
<pitti> ogra: it still needs a bit to propagate to syncproxy etc.
<ogra> i see it on ports already
<pitti> oh, nice
 * pitti checks on antimony
<pitti> ogra: ARCHES='armel+omap armel+omap4' daily-preinstalled running
<ogra> thanks !
<pitti> so, this will take 2.5 h?
<ogra> guessed, i just changed the build scripts to speed them up
<pitti> ok; I need to leave at 19:30
<pitti> so it might just about make it on time
<pitti> so that I can add it to the tracker
<ogra> it used to be 3.5h should be 2 or max 2.5
<pitti> but I guess more people can
<ogra> right
<ogra> i think GrueMAster can take care for that
<ogra> he will also do most of the testing
<ogra> so dont worry, arm team will take care
 * ogra goes afk and tries to find something better than waiting for images
<ScottK> Riddell: According to rmadison, when you promoted libdigest-sha-perl yesterday, you promoted the binaries, but not the source ...
<Riddell> ScottK: rmadison is quite right, fixed
<pitti> ttx, Daviey: TBH I don't quite understand bug 613033; should this be release-noted?
<ubot4> Launchpad bug 613033 in eucalyptus (Ubuntu Maverick) (and 2 other projects) "eucalyptus-cloud: cloud fails to start on separate install (affects: 1) (heat: 6)" [Critical,Triaged] https://launchpad.net/bugs/613033
<Daviey> pitti: I would say it does.. basically if you have a topology of having all componets (except nodes) on one server, and then other servers just being nodes - we are ok
<Daviey> If you split the components (which should be supported), we are running into problems
<Daviey> ttx, Has gone home for the delay, and i'm reluctant to speak on his behalf on this.  What is the deadline that you need the text by?
<Daviey> s/delay/day/
<pitti> Daviey: tomorrow around noon in Europe
<pitti> i. e. in about 18 hours?
<Daviey> oh.. that is ok then.. I'll catch up with ttx when he's back online, although he'll probably see this scrollback
<Daviey> either way.. i'm sure he'll be around before then
<GrueMaster> ara: ping - can you add http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100804/ images to the ubuntu arm testing for Alpha 3?  Not sure why it isn't there.
<pitti> GrueMaster: wow, did it already build?
<pitti> must have finished minutes ago
<GrueMaster> Apparently.  I was getting worried we wouldn't have an image to test.
<pitti> GrueMaster: so did we; it took more than a day to get this installable :)
<pitti> GrueMaster: added to tracker
<GrueMaster> thanks.
<pitti> good night everyone, and happy testing!
<ScottK> Riddell: Thanks.
<GrueMaster> Grrr.  Ok, we have Beagleboard ARM Image Testing on iso.tracker but not Pandaboard.  Need one for Pandaboard (omap4).
<lamont> there will be a brief disturbance in the armel buildd world shortly.  shouldn't last very long
<GrueMaster> ???  Care to elaborate?
<pitti> GrueMaster: hm, I did add an omap4 image, didn't I?
<GrueMaster> Here's what I am seeing:  http://iso.qa.ubuntu.com/qatracker/test/4392
<GrueMaster> No actual testcases.
<pitti> ooh
<pitti> let's see whether I can do that
<GrueMaster> If I knew how, I'd fix it myself.
<GrueMaster> I'll make it a point to bring up at the QA sprint.
<lamont> armel buildds are back online/auto
<pitti> GrueMaster: better now? (first time I added one)
<pitti> (DSL reconnect, I might have missed some messages)
<GrueMaster> Looks right.  Thanks.
<ttx> pitti: yes, should be releasenoted
<ttx> We'll come up with something tomorrow morning, based on the current state of affairs
<pitti> ttx: sonne bien, merci Monsieur
 * ttx crawls back in his cave
<pitti> argh, forgot about DVDs
 * pitti builds
<highvoltage> hi! could we get a re-spin of the Edubuntu DVD iso?
<highvoltage> our build failed due to a bug in the artwork package and we'd like to have an alpha 3 release :)
<pitti> highvoltage: already queued
<pitti> Ubuntu DVD finished, posted to tracker
<highvoltage> pitti: thanks!
<pitti> highvoltage: I'll go to bed now, so I won't be able to add it to the tracker
<pitti> if someone else here can, that'd be great; otherwise I'll do that tomorrow morning
<GrueMaster> pitti: Give me the steps and I can try to add it.
<highvoltage> pitti: ok!
<pitti> GrueMaster: you are logged into the ISO tracker?
<GrueMaster> yes
<pitti> GrueMaster: Administration menu part, "Add a build set"
<GrueMaster> ok
<pitti> GrueMaster: first section ther is edubuntu
<GrueMaster> yes, I see it, along with check boxes.
<pitti> GrueMaster: mark the two DVD builds, scroll down, enter "20100805" (or whichever) as the version number, and press "add build(s)"
<pitti> GrueMaster: you need to check the build number on cdimage.ubuntu.com/..
<GrueMaster> Roger that.  Will do, thanks.
<highvoltage> thanks pitti, sleep well. you'll get your beer at UDS :)
<pitti> good night everyone!
<pitti> highvoltage: :)
<stgraber> just got an e-mail from antimony saying that the edubuntu failed because the server ran out of disk space
<GrueMaster> doh!
#ubuntu-release 2010-08-05
<elmo>                       1.6T  1.6T  408M 100% /srv
<elmo> cjwatson: slangasek ogra Riddell ^--
<elmo> (antimony)
<NCommander> elmo: I'm looking at antimony right now
<ScottK> Once that's solved, it would also be appreciated if someone would respin Kubuntu powerpc live.
<highvoltage> And a respin of Edubuntu too please (which seems to have, in part at least, caused the low space problem :))
<NCommander> highvoltage: ScottK: will do, although I'm not quite sure what became a runaway bloated wreck
<NCommander> Looks like the problem is images aren't getting properly purged ...
<pitti> Good morning
<pitti> uh
<pitti> I'll clean up antimony a bit
<pitti> /dev/cciss/c1d0p1      65G  8.6G   56G  14% /
<pitti> hmm
<pitti> oh, /srv
<NCommander> pitti: yeah, its not pretty. I have some idea of things that can be deleted, but it just looks like we plain ran out of disk space :-/
<pitti> I cleaned up logs, and I am currently cleaning scratch/
<NCommander> pitti: ah, yeah, I wanted to talk to some people before I started deleting stuff :-)
<pitti> but there were no old images indeed
<pitti> there is one RT pending to archive the old maverick alpha-1 images
<pitti> and I'll need to move the alpha-2 ones to old-images/, too, and have them archived
<pitti> elmo: ^ FYI
 * pitti hopes that scratch/*/*/tmp/* is really temporary enough to be able to wipe it, but looks like it
<pitti> it has tons of lucid-src etc.
<pitti>                       1.6T  1.5T   83G  95% /srv
<pitti> there, slightly better
 * pitti reruns edubuntu dvds
<pitti> highvoltage: argh
<pitti> update-alternatives: error: alternative path /usr/share/edubuntu-artwork/home/index.html doesn't exist.
<pitti> dpkg: error processing edubuntu-artwork (--configure):
<pitti>  subprocess installed post-installation script returned error exit status 2
<pitti> highvoltage: yesterday's DVD live fs build failed
<pitti> highvoltage: last one that works is from August 1
<pitti> so I'll produce a DVD from that one for now
<NCommander> pitti: scratch has nothing persistant in it, at least on my local build
<pitti> http://cdimage.ubuntu.com/edubuntu/dvd/20100805/
<pitti> highvoltage: ^
 * pitti builds a mythbuntu, should work better now
<ara> morning!
<pitti> hello ara, how are you?
<pitti> ara: we got two late strugglers, edubuntu DVD (now posted), and mythbuntu
<pitti> ara: do you have some time to give the edubuntu one a spin? I can try mythbuntu
<ara> pitti, sure, resyncing now
<pitti> I hope someone (Riddell?) can test Kubuntu DVD i386
<ttx> o/
 * ttx still feels very bad, so I'll enter minimal mode today
<pitti> hello ttx
<pitti> ttx: uh, get well soon -- ubuflu?
<ttx> pitti: unclear. Got headache, throat hurting, eyes are red
<ttx> looks like our ISO testing is in good shape this time
<ttx> so it's just a matter of writing up the release notes
<ttx> and server should be ready
<GrueMaster> pitti: From what I understood, the recent edubuntu build failed because antimony ran out of disk space.
<pitti> GrueMaster: right; I cleaned up this morning and rebuilt; posted now
<GrueMaster> Ok.
<ara_> I am still resyncing edubuntu
<ttx> pitti: TechnicalOverview edited
<pitti> ttx: merci Monsieur
<ttx> hmm
<ttx> I'll refactor my "new features"
<pitti> ttx: merge the two headings into one?
<ttx> yep
<pitti> ttx: oh, while you are at it, would you mind to fix the <a href stuff in cloud-init to be a proper wiki link?
<ttx> ok
<ttx> done
<pitti> I'm off for about two hours for some errands
<pitti> mythbuntu still failed to build, and the rest should be posted and working
<pitti> for the Canonicalizens, please call my mobile if there are urgent questions
<pitti> ara: thanks for the edubuntu test
<ara> pitti, working on the installation one for i386, and will start amd64 soom
<ara> s/soom/soon
<Daviey> pitti, We are having some problems with mythtv in maverick.  Trying to work with upstream to resolve it, we do have a patch that claims to resolve it; but it's not clean and requires more testing.
<pitti> Daviey: does that break installation?
<pitti> or can it be fixed post-install?
<Daviey> pitti, Unfortunately I personally haven't had the time to test this ISO.
<Daviey> I will give it a spin after some further UEC testing.
<Riddell> pitti: downloading kubuntu i386 dvd now, although it'll be a couple of hours at least before test is done
 * Daviey notes a time/people resource issue.
<Riddell> win 10
<Riddell> tsk
<pitti> Riddell: no, latest ist win 7, I think :)
<davmor2> Riddell, pitti:  I missed the start of the conversation I got win7 if you guys have an issue
<ara> pitti, the edubuntu i386 installation finished, but went uncommonly slow, I will have a look to the logs
<pitti> davmor2: just kidding
<davmor2> pitti: okay cool
<Riddell> although if you had win 10 that would be handy
<ttx> pitti: you're all set for Alpha3 wrt server ? Doctor said: stay away from computers and let your uveitis heal itself
<pitti> ttx: I think so; thanks a lot for testing and the notes
<ttx> pitti: np, that's my job :)
 * ttx disappears to take more meds
<pitti> GrueMaster, ogra: any luck with the arm preinstalled images?
<ogra> just started here, didnt GrueMaster report on the isotracker ?
<pitti> not yet
<pitti> ah, it's marked as "started"
<ogra> ah, weird
<ogra> looks like the panda installation (omap4) is good
<ara> Riddell, have you started with Kubuntu DVD i386?
<highvoltage> pitti: eek! (thanks)
<pitti> highvoltage: but seems the 0801 build is still working
<highvoltage> pitti: is that too old to use for an alpha 3 release?
<pitti> highvoltage: works for me; it's just two days difference
<pitti> highvoltage: you might still have the -13 kernel, but *shrug*, people can upgrade
<Riddell> ara: just about to boot it up
<ara> Riddell, ok, great, I will resync another image then
 * ara -> lunch
<highvoltage> the edubuntu dvd description on the tracker just needs to be updated to 20100801 instead of 20100805
<highvoltage> ara: ^^ is that your department? :)
<pitti> highvoltage: oh, oops
<pitti> that might be a little tricky
<pitti> last time I tried it, it only wanted upwards counting
 * pitti tries to fiddle
<highvoltage> pitti: it's not really a big deal, but it is kind of weird seeing that a failed build passed 2/2 tests :)
<pitti> highvoltage: erm, why?
<pitti> highvoltage: http://cdimage.ubuntu.com/edubuntu/dvd/20100805/
<pitti> I actually copied the build number from cdimage, so it seems to be alright?
<highvoltage> pitti: oh, my bad! I understood that it failed
<pitti> highvoltage: the livefs is from 0801, right
<highvoltage> ah, I see
<pitti> ara, Riddell: I went through the bugs, and I didn't see any total failures; I think I documented all serious ones on https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview#Known%20issues now
<pitti> highvoltage: ^
<pitti> how are things looking from your side? I'd like to start publishing the images
<highvoltage> pitti: I'll add the edubuntu details to that page
<pitti> highvoltage: ah, please do
<Riddell> pitti: added bug 613574 to known issues
<ubot4> Launchpad bug 613574 in kdebase-workspace (Ubuntu) "kdm times out on live cd (affects: 2) (heat: 12)" [Undecided,Confirmed] https://launchpad.net/bugs/613574
<pitti> Riddell: is that only when you log out of the live session? or does it affect the autostart as well?
<Riddell> pitti: it's when the live session starts
<pitti> uh
<pitti> Riddell: starting ubiquity works, though?
<pitti> that indeed sounds rather serious
<Riddell> yes
<pitti> Riddell: do you want to postpone, or release with this?
<Riddell> you can follow the failsafe X prompts and it starts fine so I'll just make it obvious in the kubuntu.org announcement
<pitti> weird that it didn't come up in the other test results
<Riddell> it doesn't affect running from USB, presumably that's fast enough not to trigger the timeout
<pitti> ah
<pitti> we had 4 reported successes
<Riddell> and it won't affect virtual machines either
<pitti> elmo: FYI, to free 42 GB from antimony, RT#40165 should help
<pitti> smoser: can you please publish the UEC images to uec-images.ubuntu.com for alpha-3?
<ara> sorry, I was at luch
<ara> lunch, even
<pitti> ara: you're having lunch!?!?!
 * pitti hugs ara
<ara> Riddell, highvoltage: what happened with edubuntu?
<smoser> pitti, are you saying make all that public now ?
<ara> I meant, pitti
<pitti> smoser: yes; they all look good, don't they?
<ara> the tests I did for edubuntu are not worth it, then?
<highvoltage> ara: we have an old livefs in a new spin (the one that you tested), so we're going with that
<highvoltage> ara: they are!
<pitti> ara: no, why? thanks a lot for testing them, otherwise we wouldn't have made it in time
<highvoltage> (worth it, that is)
<pitti> right, they are a few days old, but as long as they install and work, that's fine
<ara> pitti, ah, ok, the message about changing to 20100801 confused me
<pitti> heck, all the other images are also out of date now, people didn't stop uploading :)
<smoser> yes, pitti. i will publicize.
<highvoltage> ara: apologies for letting my confusion spill over to you :)
<ara> highvoltage, :)
<highvoltage> ara: and thanks again for your testing work, you rock
<pitti> cjwatson, slangasek: FYI, last night I cobbled together http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/annotate/head%3A/publish-image-set.py, which makes it a lot easier to do the publish-release bits; I added it to the MilestoneProcess wiki page
<highvoltage> pitti: stgraber figured out what went wrong yesterday, the build that you triggered did actually work, but it was saved to edubuntu instead of edubuntu-dvd
<highvoltage> pitti: so it ended up here: http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/edubuntu/ instead of here: http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/edubuntu-dvd/
<highvoltage> not a problem but at least it solves the mystery :)
<pitti> ah, ok
<pitti> ogra: hm, you don't happen to know how to invoke publish-release for the preinstalled omap images?
<pitti> I tried ARCHES='armel+omap armel+omap4' for-project ubuntu publish-release daily-live ../ubuntu-netbook/daily-live/20100804 netbook no alpha-3
<pitti> but that doesn't work
<smoser> pitti, thats done.
<pitti> ogra: seems we didn't publish them before either
<smoser> i still have to update the ami pages on amazon, but will do that shortl
<smoser> y
<pitti> smoser: thanks
<highvoltage> pitti: btw, are you release manager for this cycle? (sorry if I missed the memo :) )
<pitti> highvoltage: not officially
<pitti> highvoltage: we finally got an official release manager now, though \o/
<highvoltage> cool :)
<pitti> I guess she'll say hello here soon, but she's at debconf, meeting Colin and Steve
<pitti> ogra: sorry, I can't figure it out; can we publish the armel preinstalled ones later on?
<cjwatson> pitti: you rang?
<pitti> cjwatson: hello
<pitti> cjwatson: I have tried in vain for ages to publish http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100804/
<pitti> cjwatson: but I can't figure out the correct rune, it seems
<pitti> ARCHES='armel+omap armel+omap4' for-project ubuntu bash -ex ~/bin/publish-release daily-preinstalled ../ubuntu-netbook/ports/daily-preinstalled/20100804 preinstalled-netbook no alpha-3
<pitti> cjwatson: ^ that's the last one I tried
<cjwatson> I can probably manage to guess it, modulo debconf wifi
<pitti> cjwatson: I added some img.gz extensions to publish-release,but it doesn't help
<pitti> so perhaps I'll revert that again
<cjwatson> leave what you already have in place, and I'll work from there
<pitti> ok, thanks
<pitti> cjwatson: did we ever publish those before?
<cjwatson> my guess is not
<cjwatson> can you pastebin the output from that bash -ex run?
<pitti> I can't remember it either
<pitti> cjwatson: hang on
<pitti> cjwatson: http://paste.ubuntu.com/473517/
<pitti> once I've got it, I'll add it to publish-image-set.py
<Riddell> pitti: KDE Platform 4.5.0 got delayed incase you didn't get the memo so any references to it should call it a release candidate now
<pitti> Riddell: ah, will change the notes, thanks
<pitti> Riddell: seems you beat me to it
<smoser> pitti, ec2 is published now. http://ubuntu-ec2-maverick-i386.notlong.com/ and http://ubuntu-ec2-maverick-amd64.notlong.com/ and http://uec-images.ubuntu.com/releases/maverick/alpha-3/
<cjwatson> pitti: fixed with a stupid, stupid fudge
<cjwatson> namely: mkdir /srv/cdimage.ubuntu.com/www/full/daily-preinstalled
<cjwatson> (pending something more sensible)
<pitti> ah, so it was just that daily-p/../ bit
<cjwatson> so that's published now
<pitti> cjwatson: yay you
<cjwatson> it hasn't done anything to HEADER.html
<cjwatson> somebody will need to mangle make-web-indices
<pitti> ok, so I'll edit that manually for now
<pitti> cjwatson: what was the command you used to publish?
<pitti> cjwatson: hm, were was it published to?
<pitti> cdimage@antimony:~/cdimage/www$ diff -u <(cd ../www.prev/full && find | sort) <(cd full && find | sort) |grep ports
<pitti> -> nothing
<ogra> pitti, sorry, was out for a while, no, i have never published and preinstalled images yet
<ogra> s/and/any/
<cjwatson> pitti: oh, er
<pitti> cjwatson: oh, I see
<pitti> it put it into releases/maverick/alpha-3/
<cjwatson> that's what your command asked for :)
<pitti> cjwatson: ok, so which one did I really want?
 * pitti doesn't have documentation how to publish ports
 * pitti moves it over manually now
<cjwatson> oh, I was still figuring it out
<cjwatson> in a talk here so brain cycles are limited
<cjwatson> I think you're meant to use publish-release ubuntu-netbook/ports/daily-preinstalled or some such
<pitti> cjwatson: ok, I'll play around with that after the syncing and release is done, for the next time (and will restore it afterwards)
<cjwatson> ok, sorry to be only semi-available
<pitti> cjwatson: np; I'll fudge through the rest; thanks for coming online, and sorry for disturbing!
<GrueMaster> pitti: I have updated iso.tracker with info on both omap and omap4 image testing results.
<GrueMaster> I'm sure there are more bugs to find, but I only had one day to test, and these systems are a bit more sluggish than x86.
<pitti> GrueMaster: thanks; if it installs and boots at all, that's "good enough" at this point
 * pitti presses the final release button
<GrueMaster> Oh.  Then I'll remark it as passed in that case.
<GrueMaster> fixed.
<pitti> ok, thanks everyone!
<pitti> I'm quite tired, I'll call it a day for today
<GrueMaster> Heh.  My day just started.  Have a good evening.
<ogra> pitti, awesome job, thanks a lot for the hard work !
#ubuntu-release 2010-08-06
<lamont> slangasek: awake?  I'm thinking I'm going to roll new chroot tarballs in the morning, fyi
<ScottK> lamont: Do you have ia64 hardware you could do a Maverick test build with?
<ScottK> I'm curious if llvm-2.7 will, in fact, build on ia64.  Clamav currently embeds a copy and it builds fine.  If I'm ever to have any hope of using the system llvm, it'll need to build on ia64 (or ia64 dies).
<ara> morning!
<lamont> ScottK: yes
<ScottK> Was there a give-back of the failed builds from the glib explosion?
<ScottK> lamont: Debdiff from the current llvm-2.7 package in Maverick http://pastebin.com/5px9VdJ9
#ubuntu-release 2010-08-07
<Hoober> sweet
<Hoober> hi guys
<Hoober> and girls
<Hoober> well
<Hoober> !help
<ubot4> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<Hoober> !all
<ubot4> Factoid 'all' not found
<Hoober> !announce
<ubot4> Factoid 'announce' not found
<Hoober> !channel
<ubot4> Factoid 'channel' not found
<Hoober> !say
<ubot4> Factoid 'say' not found
<Hoober> !hoober ? ubot4
<ubot4> Factoid 'hoober ? ubot4' not found
#ubuntu-release 2010-08-08
<stgraber> I'd appreciate it if someone from ubuntu-cdimage could merge the patch from bug 592316 so we can do more testing on that before beta
<ubot4> Launchpad bug 592316 in edubuntu-meta (Ubuntu) "Edubuntu Live DVD Should Include OEM Installation Mode (affects: 1) (heat: 8)" [Medium,Triaged] https://launchpad.net/bugs/592316
#ubuntu-release 2011-08-01
<jibel> no desktop today and alternate fails to install : system-config-printer-common : Depends: python-packagekit but it is not installable
<jibel> submitting a bug
<jibel> bug 819267
<ubot4> Launchpad bug 819267 in system-config-printer (Ubuntu Oneiric) (and 1 other project) "Oneiric desktop image failed to build and alternate failed to install: system-config-printer-common : Depends: python-packagekit but it is not installable (affects: 1) (heat: 6)" [Critical,Triaged] https://launchpad.net/bugs/819267
<skaet> jibel,  ack.
<superm1> hey can an archive admin please help look at mythbuntu-lightdm-theme in NEW?  It is intended for a3. thx
<jibel> skaet, a fixed for 819267 has been uploaded. we'll wait for unity components to be uploaded, built and published and we can respin the images.
<jibel> skaet, that's something like in 3 hours.
<skaet> jibel,  thanks for the update,  I'm tempted to trigger a respin before unity,  so we have a set of images and can narrow down any failures incase there is something else lurking.
<skaet> NCommander, slangasek, ^^,  FYI.
<stgraber> skaet: if you do, can you wait for ltsp and ldm to publish so I can at least validate that LTSP indeed works again?
<skaet> stgraber,  sure,  if they're uploaded already.   what's the ETA?
<seb128> skaet, respins will not work until system-config-printer is not upload, built and published
<seb128> skaet, so you need to wait at least an hour (or 2 if till doesn't catch the next publisher run with his upload)
<jibel> skaet, ETA for s-c-p is 16:00UTC at best
<skaet> seb128, jibel,  thanks.   Thought it was uploaded,  ok,  will start a fresh set when those pieces are in place
<skaet> seb128, njpatel, who's uploading the newest drop of unity?   what's the outlook on that?
<njpatel> skaet, me and just testing the stack now and releasing
<seb128> skaet, njpatel is supposed to roll the tarballs, didrocks to do the packaging
<didrocks> (as usual I would say :))
<skaet> :)  ok   just checking.  :)
<seb128> yeah, we have no impacting holidays in those teams atm ;-)
<stgraber> skaet: they've been uploaded 30min ago, so should be published soon
<skaet> didrocks, njpatel - can you let me know before the unity upload happens.   Want to make sure we've got the images building again before we add unity to the mix.
<njpatel> sure
<didrocks> skaet: will do
<jibel> skaet, any news from gilir about lubuntu ? there is still no alternate and most recent desktop image is a week old.
<skaet> jibel,  no haven't heard an update.
<skaet> gilir,  how is lubuntu looking?   are we going for alternates this time around?
<ScottK> skaet: Could we get a respin of the Kubuntu live images?  They failed today, but I think the reason is fixed now.
<skaet> ScottK,  kicked off now
<didrocks> skaet: so, I have libunity-misc, nux, unityâ¦ but this ask for a rebuild of unity-2d, which fails right now
<NCommander> didrocks: unity-2d is FTBFS or?
<didrocks> NCommander: it will with the new release of unity
<didrocks> as it deps on unity right now
<skaet> didrocks,  please hold off on upload until all the pieces build,  we're still waiting to get working images.
<didrocks> checking
<didrocks> skaet: when the images will finish their rebuild?
<ScottK> skaet: Thanks.
<skaet> didrocks, I'm not seeing some pieces, yet, so probably a couple of hours.
<didrocks> skaet: please keep me updated, it's getting late there (I'm always starting really early) :)
<skaet> didrocks, will do once you've got all the pieces ready,  we'll make a decision.
<NCommander> skaet: I'm looking into the livefs failure now
<skaet> NCommander, thanks!  see comments from jibel on the bug 819267
<ubot4> Launchpad bug 819267 in system-config-printer (Ubuntu Oneiric) (and 1 other project) "Oneiric desktop image failed to build and alternate failed to install: system-config-printer-common : Depends: python-packagekit but it is not installable (affects: 1) (heat: 8)" [Critical,Fix released] https://launchpad.net/bugs/819267
<NCommander> stgraber: both ldm and ltsp are now published, can you see if LTSP is fixed?
<stgraber> NCommander: I know the package works on an installed system. I need an ISO build to confirm that the d-i plugin works too
<NCommander> stgraber: your next in the queue while kubuntu comes up
<skaet> jibel, ^^
<didrocks> skaet: dx failed to sync their APIâ¦
<didrocks> skaet: I'm fixing their work, once againâ¦
<skaet> didrocks,  ack :P
<NCommander> stgraber: alternates are building, you should have them in a bit
<stgraber> NCommander: ok, thanks
<jibel> didrocks, how long will it take ?
<didrocks> jibel: well, building a new unity right now after reverting a commit
<jibel> skaet, NCommander , if next build includes system-config-printer (1.3.5+20110801-0ubuntu1) and we have no news from didrocks before 1800UTC we can respin alternate and desktop.
<didrocks> do a respin anyway
<didrocks> nux needs to be built and published for unity to be built
<jibel> didrocks, ack.
<didrocks> then, unity needs to be built and published before unity-2d can be built
<didrocks> so it will take 3 hours
<didrocks> at least
<skaet>  jibel,  Ncommander has started started rebuild of alternates that will include the system-config-printer  (1.3.5+20110801-0ubuntu1)
<skaet> live to follow as well.
<NCommander> alternate rebuild complete, its just publishing now. I just kicked the live build
<jibel> skaet, ok thanks
<NCommander> stgraber: hot images, get your nice hot alternate images: http://cdimages.ubuntu.com/daily/20110801.1/
<slangasek> NCommander: should these be posted to the ISO tracker?  (And do you have access to post them there?)
<NCommander> slangasek: I don't have access to the tracker, but at the moment, I think we're just trying ot make sure everything builds; we're not even in milestone freeze ATM
<slangasek> fair enough
<didrocks> NCommander: skaet: jibel: ok, all is fine now with the revert
<didrocks> tell me when I can proceed the upload
<skaet> NCommander, slangasek,  actually we announce soft freeze was supposed to be 1200 UTC today in last week's release meeting, but it probably should have been broadcast by u-d-a mail as well.
<NCommander> didrocks: once this spin finishes, then unity shold be uploade
<didrocks> NCommander: do you have an ETA? I would like to take some french air :)
<didrocks> fresh*
<skaet> :)
<NCommander> didrocks: probably 30-40 minutes?
<didrocks> NCommander: ok, enough time for me to run then
<NCommander> didrocks: feel free to upload
<NCommander> skaet: live images built
<didrocks> NCommander: thanks, doing :)
<skaet> ScottK,  kubuntu live images available as well.
<ScottK> Just saw them.  They landed slightly oversized, so I'm going to see if I can fix that.
<NCommander> skaet: just noticed that the ubuntu live images are oversized, taking a look at where they can take a diet
<skaet> NCommander,  if you spot some low hanging fruit,  cool,  but they're pretty much expected to be oversized until beta.  lots of transitions going on.
<NCommander> if they're expected to be oversize (and that's acceptable for A3), then that's foine
<skaet> hiya gilir,  how are the lubuntu images - do you need a respin today as well?   Also, are we going to get alternates?
<NCommander> skaet: the NBS list is scary
<charlie-tca> Please don't break xubuntu images in all these fixes :)
 * charlie-tca thinks "undersize and working, whew!"
<skaet> NCommander - yeah,  inadvertent sync from Debian last week effect.
<skaet> charlie-tca,  do you want me to post the current xubuntu daily images so the testing can start,  if these are working?
<charlie-tca> I am checking to make sure first
<skaet> charlie-tca, goodness.   Let me know what you want done.
<skaet> ScottK,  similarily - if the Kubuntu ones, look reasonable,  I'll post.
<gilir> skaet, yes, an update should be fine :) But I still don't know where to look at to see why lubuntu images are not updated since 25
<NCommander> skaet: I'm attacking the uninstallability list at the mpment so we might have a chance at ARM images
<skaet> slangasek,  can you help gilir ^^ ?
<skaet> NCommander,  sounds good.
<skaet> gilir,  ok,  I'll start of the builds and we'll see what happens.
<gilir> skaet, thanks :)
<ScottK> skaet: Is 700MB still considered oversize?
<ScottK> http://cdimages.ubuntu.com/kubuntu/daily-live/current/ says it is, but I thought we decided different.
<skaet> ScottK, good question,  am not sure when the transition over was supposed to happen,  and the scripts are probably over due to be scrubbed.
<ScottK> So I can consider 700MB OK for now?
<skaet> ScottK,  ok by me, rest are showing up as oversized,  but I think its your call at this point until we get clarification from pitti.
<NCommander> Sc	my understanding was still 700MiB
<NCommander>  sorry, lap
 * micahg thought it was 703.something
<skaet> slangasek,  do you remember when we were supposed to go up to 703?  and what the preconditions were?
<charlie-tca> skaet: we have a change to xubuntu-default-settings that went through to remove the Guest session from lightdm
<micahg> https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-great-cd-debate
<charlie-tca> If we have to respin for anything, that should be in the respin, otherwise, I can just release note it
<charlie-tca> Let's go ahead and put the images on the tracker as they are.
<skaet> charlie-tca, will do.  we'll be respining a full set tonight to pick up the unity upload.
<skaet> so you have some choice ;)
<charlie-tca> That's pick up the change for me too then. No point running these
<skaet> ok,  won't post then.
<charlie-tca> Thank you
<ScottK> skaet: Looks to me like slangasek investigated and 703.something is the actual limit.
<skaet> ScottK,  hmm... trying to figure out why it still says: [vorlon] Further investigate feasibility of increasing CD limit to 703.125 MiB: TODO then.
<ScottK> Agreed.
<ScottK> Maybe he'll tell us.
 * skaet nods
<skaet> gilir,  slangasek,  lubuntu images appear to not be in the cron job - someone's edit last week must have have accidentally removed them.
<slangasek> skaet, ScottK: I was still working on chasing down all possible reasons why we might want to stick with the lower limit; the trail is rather cold
<slangasek> looking at lubuntu
<ScottK> slangasek: So AFAYK, 703 is OK?
<slangasek> skaet, gilir: I don't see lubuntu in the master crontab in bzr; what time of day was this scheduled for (or what time do we want it scheduled for)?
<slangasek> ScottK: yes, AFAIK
<ScottK> skaet: ^^^
<skaet> slangasek, ScottK,  ack.
<ScottK> skaet: I think we ought to go with 703 for Alpha 3 and see how it goes.
<skaet> slangasek,  not sure when lubuntu was scheduled for by cjwatson originally.   go ahead and choose,  we'll adjust as needed after A3 is out.
<skaet> slangasek, gilir,  have kicked off lubuntu daily-live build.
<ScottK> skaet: Would you please do another Kubuntu live for i386 only in ~40 minutes (after the current publisher run finishes)?
<NCommander> ScottK: I'll get it
<slangasek> skaet: lubuntu builds added to the crontab
<skaet> slangasek,  thank you.  :)
<ScottK> NCommander: Thanks.  Actually I need amd64 too since amarok is out of date there.
<gilir> skaet, slangasek, thanks :)
<stgraber> I uploaded a new edubuntu-meta just now. It's not a requirement for alpha-3 (seeds haven't been changed, just a refresh) but if I wanted it uploaded so it might have a chance to get in anyway.
<ScottK> We aren't actually frozen yet for Alpha 3, are we?
<chrisccoulson> i was just about to ask the same question ;)
<skaet> ScottK,  chriscoulson, Freeze was scheduled for 1200 UTC today,  however we haven't sent out announce yet.
<ScottK> Why are we freezing early?
<skaet> ScottK,  so much churn from the inadvertent debian import last week,  want to make sure we have a chance to get things fixed up again.
<skaet> unity was also running late as well.
<ScottK> That would mean the opposite of freezing to me.
<ScottK> BTW, the python-dbus/python-qt4 fallout from the sync is fixed.
<chrisccoulson> i guess now would be an inappropriate time to upload the latest firefox beta then ;)
<skaet> Trying to ratchet down the rate of unexpected changes.
<skaet> chrisccoulson, yes.
<skaet> please hold off until after we get these images sorted.  ;0
<skaet> :) even...
<skaet> ScottK,  please go ahead and upload the python-dbus/python-qt4 fixes.  :)
<ScottK> skaet: They are done and in the archive already.
<skaet> ScottK,  great! :)
<NCommander> ScottK: kubuntu respin kicked
<ScottK> NCommander: Thanks.
<stgraber> skaet, jibel: LTSP failed, quite likely due to transition to /run. Working on a fix now.
<skaet> stgraber,  thanks!
<skaet> ScottK,  kubuntu powerpc images failing to build.  Are you going to try for them this release?
<skaet> s/release/milestone/
<micahg> BTW, aisleriot is going to be broken in alpha3 (affects, Ubuntu, Xubuntu, Edubuntu)
<NCommander> first set of iso images are in the tracker
<skaet> micahg, is there a bug number?
<micahg> bug 813428
<ubot4> Launchpad bug 813428 in ubuntu (and 1 other project) "[needs-packaging] aisleriot (affects: 1) (heat: 242)" [Wishlist,Incomplete] https://launchpad.net/bugs/813428
<micahg> it used to be part of gnome-games
<slangasek> huh, why is it a "broken" rather than "missing" then?
<micahg> old binaries still exist :)
<slangasek> ah
<stgraber> skaet: uploaded the new ltsp. I did a quick test manually applying these changes and install worked here.
<skaet> stgraber,  ok,  as soon as it publishes,  either myself or NCommander (depends who's around),  will kick off a rebuild to check.
<stgraber> ok, thanks
<superm1> skaet, i'll need to upload a new mythbuntu-meta yet once mythbuntu-lightdm-theme is out of NEW
<superm1> and mythbuntu will need a respin after that
<skaet> superm1,  ok,  just let me or NCommander know when its ready to spin.
<superm1> ok, just waiting on an AA for now
<micahg> NCommander: for future reference, you might want to update that first paragraph of the freeze e-mail to say something about seeded instead of main, the bottom of the e-mail already does
<ScottK> skaet: Yes.  Still waiting for stuff to build (re powerpc)
<ScottK> skaet: We're going to need to respin all the Kubuntu images for kdepim anyway.
<skaet> ScottK,  ok, will mark them as for rebuild.   what is ETA on kdepim?
<ScottK> skaet: Building now.
<skaet> superm1,  kirkland will have a look at mytbuntu-lightdm-theme for us.
<superm1> thanks kirkland
<superm1> i'll get the meta uploaded shortly then
<kirkland> superm1: np;  poke me again once the binaries are there too
<superm1> kirkland, looks like they're there already :https://launchpad.net/ubuntu/+source/mythbuntu-lightdm-theme/0.7/+build/2661334
 * skaet -> dinner,  will check back later tonight.
<kirkland> superm1: done!
<ScottK> skaet: https://launchpad.net/ubuntu/+source/kdepim/4:4.7.0-0ubuntu1 finished and through New is what we need.  I'll try and look in on it later tonight.
#ubuntu-release 2011-08-02
<superm1> mythbuntu-meta is finished publishing, can someone respin mythbuntu now?
<slangasek> superm1: looking
<slangasek> superm1: building
<skaet> ScottK ok.   If the overnight builds don't pick up the right pieces, let me or NCommander know in the morning and we'll respin.
<ScottK> OK.
<ScottK> NCommander: Any ideas what causes http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/kubuntu/current/livecd-20110801.1-powerpc.out
<GrueMaster> Looks like a last minute upload of unity has once again clobbered the ubuntu-armel desktop images right before release testing.  Will need a respin so I have something to test tomorrow.
<mvo> good morning! how much of a problem is CD size at this point? I have a app-install-data upload, but it adds some new icons so it will be a bit bigger  (~1mb in the deb)
<didrocks> mvo: we are not in a good shape AFAIK :/ +8 MB yesterday
<mvo> didrocks: ok, thanks! I will wait then
<mvo> and not upload new app-install-data for now
<didrocks> mvo: are those new app desktop icons? just curious :)
<mvo> yeah, app icons plus new desktop files
<didrocks> I guess there is no real alternative thenâ¦
<mvo> well, we can use the a2 data, not *that* much has changed
<mvo> and I can upload right after a3
<seb128> didrocks, what 8mb where?
<didrocks> seb128: oneiric-desktop-amd64.iso  (712M for i386), but if we finally go for 703M, it's a little less
<seb128> didrocks, oh, I though you were mentioning an increase of 8mb in use
<seb128> yeah, that's nothing new
<didrocks> oh no, don't get scared :-)
<seb128> we will win 8mb once we got a chinese CD
<seb128> get
<didrocks> yeah, but still problematic for other language respin as they will still add some to the official image
<didrocks> (and so, won't fit in a CD)
<didrocks> but let's see pitti to come back :)
<seb128> well I discussed it with pitti before his holidays
<seb128> he said that the next option for him would be to consider to go back to rhythmbox and drop mono from the CD
<seb128> but let's see
<didrocks> that's an unfortunate time, but yeah, that would make sense
<seb128> didrocks, well there are still potential wins
<seb128> like dropping synaptic from the CD
<mvo> â¦
<mvo> indeed
<mvo> what was missing again? software-properties?
<didrocks> seb128: is it that big? I was thinking last time you discussed it it wasn't a huge win?
<seb128> didrocks, 750k
<seb128> which is not to ignore
<didrocks> yeah, still worth it then
<didrocks> right :)
<seb128> mvo, need to check, but at least update-notifier
<jibel> Good morning
<jibel> edubuntu, kubuntu (excepted dvd), kubuntu mobile, mythbuntu, ubuntuu-server and ubuntu studio posted to the tracker
<didrocks> hey jibel!
<seb128> mvo, gnome-codec-install as well but you said that one might not be needed nowadays, it's on my "to test" list
<seb128> hey jibel
<jibel> Hello didrocks
<jibel> Salut seb128
<jibel> Guten morgen mvo
<mvo> seb128: yeah, I think gnome-codec-install should be superseeded with the session installer
<mvo> good morning jibel
<seb128> mvo, I will try that today
<mvo> thx
<seb128> mvo, update-notifier depends on synaptic for the "update index" and some other things we don't use in ubuntu since we don't have a systray
<seb128> mvo, not sure if we could drop synaptic to a suggest or something
<jibel> didrocks, bug 817896
<ubot4> Launchpad bug 817896 in unity-2d (Ubuntu Oneiric) (and 1 other project) "unity-2d-places crashed with SIGSEGV in QDeclarativePropertyPrivate::initProperty() (affects: 17) (dups: 17) (heat: 150)" [High,Confirmed] https://launchpad.net/bugs/817896
<mvo> seb128: indeed, we should simply make it call aptdaemon via dbus and make it a or-depends
<jibel> on a fresh install, login to Unity-2d and click on the launcher in
<didrocks> jibel: hum, I was using this version and never got this crash, can you try something?
<didrocks> jibel: like apt-get update && apt-get upgrade
<didrocks> as you will get latest unity-2d
<didrocks> and then reloading it and try the same thing?
<didrocks> (the code in the launcher/place connect changed there)
<didrocks> jibel: can you come on #ayatana? I just pinged Kaleo about it
<jibel> Ubuntu Desktop and Alternate posted to the tracker
<jibel> netboot posted too
<jibel> No ubuntu dvd ?
<jibel> xubuntu desktop|alternate 20110802 posted
<didrocks> jibel: so, I have a new unity-2d built and tested there
<didrocks> fixing the 2 bugs
<didrocks> should I push?
<jibel> didrocks, bug 819727
<ubot4> Launchpad bug 819727 in compiz (Ubuntu) "[Intel 945GME] Compiz crashes on startup (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/819727
<jibel> I'll try to reproduce
<didrocks> jibel: omer is just telling that he has some issue on intel on #ayatana
<didrocks> jibel: maybe the same
<didrocks> works well there on nvidia
<didrocks> skaet: jibel: NCommander: so, new unity-2d release ready with the fix for two bugs: https://launchpad.net/unity-2d/+milestone/3.8.14.1, please tell me once I can upload it
<jibel> bugbug 819739
<jibel> bug 819739
<ubot4> Launchpad bug 819739 in nux (Ubuntu Oneiric) (and 3 other projects) "compiz crashed with SIGSEGV in nux::IOpenGLVertexShader::IOpenGLVertexShader() (affects: 1) (heat: 10)" [Critical,Confirmed] https://launchpad.net/bugs/819739
<jibel> (once is enough :))
<seb128> jibel, do you get this bug?
<jibel> seb128, yes
<seb128> bug #819667 as well
<ubot4> Launchpad bug 819667 in nux (Ubuntu) (and 2 other projects) "compiz crashed with SIGSEGV in nux::IOpenGLVertexShader::IOpenGLVertexShader() (affects: 1) (heat: 10)" [Critical,New] https://launchpad.net/bugs/819667
<seb128> njpatel, ^
<jibel> master is bug 819739
<ubot4> Launchpad bug 819739 in nux (Ubuntu Oneiric) (and 3 other projects) "compiz crashed with SIGSEGV in nux::IOpenGLVertexShader::IOpenGLVertexShader() (affects: 2) (dups: 1) (heat: 20)" [Critical,Confirmed] https://launchpad.net/bugs/819739
<seb128> didrocks, ^ just fyi in case you didn't read
<jibel> seb128, we were talking about it on #ayatana
<didrocks> seb128: we discussed about it on #ayatana
<didrocks> damn, too slow!
<didrocks> basically, jay's
<seb128> didrocks, it's somewhat looking similar to the glew 1.6 issue
<seb128> weird
<jibel> there are many duplicates coming in.
<seb128> yeah, you that broken on all intel I can see that
 * didrocks gives a look at nux trunk
<didrocks> I see some AsmShader change
<didrocks> for "mem leak fixing"
<seb128> didrocks, https://code.launchpad.net/~vanvugt/ubuntu/natty/nux/fix-785118/+merge/64275
<seb128> you mean?
<seb128> didrocks, well, let jay debug it, he replied on ayatana
<didrocks> seb128: yeah, I was about it doing that :)
<seb128> it's a bit weird that this commit would be driver specific
<seb128> well I don't know enough about GL to say, I will let the pros work it out ;-)
<didrocks> seb128: from my very limited understanding, there are two kind of shaders
<didrocks> those used on intel/ATI, and those used on nvidia
<didrocks> (and that's different files), so it can maybe affect only those
<didrocks> but it's a rough guess, let's wait for ay :)
<seb128> yeah, he seems to have a clue about the issue
<ScottK> Did anyone here retry kdepim on armel?
<ScottK> It restarted 4 hours ago and I'd like to find out why.
<ScottK> Are we worrying about dvds this milestone?
<stgraber> I always do (though that's limited to Edubuntu in my case ;))
<ScottK> The last Kubuntu dvd livefs failed due to gcj installability.
<ScottK> No idea if it's been fixed.
<jibel> skaet, ^ ? I asked the same question for ubuntu this morning
<utlemming> jamespage: are you around?
<jamespage> utlemming: sure am
<utlemming> so we have a fresh batch of AMI's that we built for Alpha3 using the new live-build stuff. It was suggested that we ask you to run a quick small scale test on them. Could we impose upon you to do so?
<jamespage> utlemming - sure - do you have a specific build number to test?
<utlemming> jamespage: :( we just found a bug that renders this build not so good -- so we have to rebuild first
<skaet> Good morning all.
<jamespage> utlemming: OK so I'll get things setup ready to go
<utlemming> jamespage: thank you much
<skaet> ScottK, jibel,  yes, we're trying for DVD unless there is some blocker on them.
<ScottK> Someone ought to look into the gcj installability issue and see if it's fixed.
<didrocks> hey skaet! did you see my ping about unity-2d?
<skaet> didrocks,  yup,  go ahead and upload
 * didrocks does
<skaet> faster we get these bugs fixed the better.
<didrocks> skaet: seems there is a big issue with intel driver on unity (not 2d) from nux. jay is looking at it
<skaet> didrocks,  re: nux.  thanks - keep me up to date.   BTW - did you see GrueMaster's post?   do any of these fixes make the ARM images work?
<skaet> or is that still pending?
<didrocks> skaet: hum, no I didn't see that post, what is it?
<skaet> <GrueMaster>  Looks like a last minute upload of unity has once again clobbered the ubuntu-armel desktop images right before release testing.  Will need a respin so I have something to test tomorrow.
<skaet> didrocks,  do I just need to kick off the armel builds,  or is there a bug that needs to be fixed.   I can't tell from his message.
<didrocks> skaet: it's just that the armel builder was screwed yesterday evening, so a give back had to be done this morning
<didrocks> and nux finished to build
<GrueMaster> Morning, skaet.  Still no armel images.
<GrueMaster> I think jani was looking at it, let me check.
<didrocks> skaet: the builder wasn't ok yesterday at midnight (my time) when I looked at them
<didrocks> unity is now built, so just have to wait for the new unity-2d to be built
<GrueMaster> great
<skaet> didrocks,  re: nux if it tests out sane (and fixes the bug) please upload,  and I'll kick off a set of rebuilds as soon as they publish.
<didrocks> however, with nux needed an upload once the intel issue fixed, this will still take timeâ¦
<didrocks> skaet: sure, let me get more info, a fix was under work half an hour ago
<skaet> didrocks, thanks!  let me know the ETA on starting off the rebuilds.
<didrocks> skaet: trying to get some inffoâ¦
<didrocks> info*
<skaet> ScottK,  kicked off a Kubuntu DVD build.   There were some 20110801 images that were built late in the day yesterday (UTC time)- was there a problem with those,  or they just didn't get published?
<ScottK> Thanks.
<ScottK> Dunno, the mail I got today said gcj was uninstallable on the dvds
<micahg> skaet: someone uploaded gnumeric without goffice, this will break xubuntu and lubuntu if a respin happens, should I upload goffice now?
<charlie-tca> skaet: ^ ^
<skaet> micahg,  yes please
<micahg> skaet: k, thanks
<charlie-tca> Thank you, micahg and skaet
<ScottK> micahg: Someone was angelabad.  You might want to have a conversation with him about freezes.
<micahg> ScottK: I know, this is also why MOTU shouldn't be able to upload stuff in seeds :)
<ScottK> No, this is why it needs to be obvious in the tools what's in seeds and MOTU need to pay attention to it.
<micahg> k, fair enough
<micahg> but I will send an e-mail
<micahg> is there an archive admin that can sync goffice 0.8.17-1?  if not, I'll use syncpackage
<superm1> charlie-tca, did you see 819617 on xubuntu too?  I expect you should have..
<charlie-tca> broken icon, yes. But I do get an internet connection here
<charlie-tca> I haven't tried with wireless yet
<superm1> do you actually see items for the ethernet connection to turn on and off in that list though?
<superm1> if i just plug in a cable it "works", but the U/I doesn't have anything in it regarding the connection
<charlie-tca> no, I don't have items like eth0 in there, I have edit connections and connection info
<superm1> okay so same situation there then
<charlie-tca> Okay, I will add it to my tracker bugs
<micahg> AA no longer needed by me, Riddell did the sync
<charlie-tca> superm1: thanks for that one. I haven't been paying attention to it because my connection works
<skaet> micahg, Riddell - thanks!
<ScottK> My powerpc seed changes way overshot the mark and will have to be reverted.
<ScottK> That'll require a respin for the new meta.
<NCommander> didrocks: feel free to upload unity-2d;
<didrocks> NCommander: done already :)
<didrocks> and nux as well :)
<NCommander> ah
<NCommander> then I shall smack the manual rebuild button in a little bit
<didrocks> NCommander: yeah, wait for nux, I would say, it will be the longest
<skaet> NCommander,  good morning.  Thanks,  will turn the rebuild trigger over to you.
<skaet> ScottK,  Kubuntu DVD's posted
<ScottK> skaet: OK.  Getting CD size fixed for powerpc is my current priority.
<ScottK> Just uploaded a new kubuntu-meta.  Once that's built/published I'll want a kubuntu live powerpc respin to see if it fits now.
<ScottK> NCommander: kubuntu-meta on powerpc is built.  Could I have a kubuntu live (powerpc only) respin in ~80 minutes?
<charlie-tca> superm1: got all the devices in an install of alpha3, but not on live session
<superm1> charlie-tca, oh weird.
<charlie-tca> Have to think it has something to do with lightdm not working for us yet
<charlie-tca> We don't get a default session and we do not get the list of users anymore.
<superm1> you need to install accountsservice for the list of users
<NCommander> ScottK: not a problem, one respin, hgold the onions in 60 minutes from this point
<ScottK> Even 45 would work.
<ScottK> Thanks.
<didrocks> NCommander: I think nux is published now (at least i386 and amd64)
<micahg> seb128: was there anything specific in the gnome-games upload that was need?  it's seeded in xubuntu as well
<micahg> (i.e. do we need a respin for something in it)
<seb128> micahg, there was a depends missing which made a game on the CD not start
<seb128> but it's only a game
<seb128> i.e sudoku
<micahg> yeah, we have that one..
<seb128> gnome-sudoku
<micahg> charlie-tca: ^^
<seb128> but having a game not working in an alpha is not the end of the world
<seb128> not sure it's worth a respin by itself
<seb128> I uploaded so it's picked if there is a respin for another reason
<micahg> seb128: there are other things as well that we've been considering
<micahg> seb128: thanks
<seb128> yw
<charlie-tca> skaet: I am going to upload a new xubuntu-meta for alpha3 and ask for a respin. Is that okay?
<skaet> charlie-tca,  yes,  go ahead.
<skaet> NCommander,  what order are the rebuilds working in?
<charlie-tca> Thank you, skaet
<charlie-tca> NCommander: will need a respin of Xubuntu images in 1.5 hours
<charlie-tca> NCommander: I am told to hold off on that until we get the changes done for sure.
 * skaet appreciates "for sure" with careful testing ;)
<skaet> didrocks, seb128 - NCommander must have stepped away and I'm not seeing activity on the image builder.   Are we good from your perspective now to respin the images,  or still waiting for something?
<seb128> skaet, sorry I was away for dinner
<seb128> skaet, yes, everything is ok from the desktop side
<skaet> seb128,  no worries.
<skaet> ok,  starting the respinning of ubuntu desktop now
<seb128> thanks
<skaet> NCommander,  FYI:   have kicked off:
<skaet> echo building ubuntu daily; for-project ubuntu cron.daily;
<skaet> echo building ubuntu daily-live; buildlive ubuntu daily-live && for-project ubuntu cron.daily-live;
<skaet> echo building ubuntu server; for-project ubuntu-server cron.daily
<skaet> echo building ubuntu daily-preinstalled (x86); buildlive ubuntu daily-preinstalled && for-project ubuntu cron.daily-preinstalled;
<skaet> echo building ubuntu dvd; buildlive ubuntu-dvd dvd && for-project ubuntu cron.dvd;
<skaet> echo building ubuntu core; buildlive ubuntu-core ubuntu-core; build-livecd-base ubuntu-core;
 * NCommander isback from lunch
<GrueMaster> skaet: I hear we are respinning armel server?  What changed?
<SpamapS> Is it alright to upload minor stuff to universe right now?
<micahg> SpamapS: you can upload stuff that isn't seeded
<skaet> GrueMaster,  if server images posted right now are good, we won't repost them.   Basically just redoing the full set to pick up all the changes on desktop.
<SpamapS> micahg: heh.. are we finally going to start using the proper terms now? :)
<GrueMaster> Ok, that's what I thought.  No show stoppers on server that I have seen.
 * SpamapS is almost done w/ RAID1 tests on amd64 server
<GrueMaster> I understand the need for desktop respin (unity-2d, etc).
<micahg> SpamapS: there are 4 derivatives seeded from universe, so I hope so :)
<SpamapS> micahg: and how does one see, easily, whether something is seeded? (Though I'd be shocked if my current upload were seeded)
<micahg> I check tasks on binaries, but that's not entirely foolproof
<SpamapS> Need something like rmadison for that
<charlie-tca> Can we respin all xubuntu images, please?
<skaet> charlie-tca, will do.
<skaet> stgraber,  I'm assuing edubuntu wants a respin too?
<micahg> gilir, superm1: FYI, chromium was just uploaded
<stgraber> skaet: yep. I haven't even tested the current build anyway :)
<skaet> stgrber, charlie-tca - ok, both flavors marked for rebuild.
<charlie-tca> Thank you
<charlie-tca> Hopefully, got a couple of those bugs nailed this time
<skaet> charlie-tca, :)  yup.  fingers crossed.   All the pieces uploaded & published or are we waiting for some last bits?
<charlie-tca> micahg: all done, right?
<micahg> yeah, it was published an hour ago
<skaet> Ubuntu Alternate 20110802.1 now posted (i386, amd64, amd64+mac, powerpc)
<ScottK> NCommander: I don't see any evidence the powerpc rebuild finished?
<ScottK> slangasek: The binaries for smokekde all landed in Universe for armel and powerpc.  They are in component mismatches for demotion, but perlkde is now FTBFS on armel/powerpc waiting for them.
<ScottK> Could you promote them for now and we'll sort it out once we're done building all the bindings?
<ScottK> (or any other archive admin who happens to be around)
<ScottK> Actually, I think demoting perlkde source is the better solution.
<ScottK> I shouldn't have accepted it into Main.
<jibel> skaet, alternate i386|amd64 are ok. nux fix tested and verified on real hardware.
<skaet> jibel, \o/
<skaet> ScottK,  do you just need powerpc rebuild, or do you want a fresh set of all Kubuntu images?
<ScottK> skaet: Just powerpc for now.
<ScottK> No point in doing them all until I get that one to fit.
<jibel> \o_
 * jibel will raise the other hand once desktop images are verified
<skaet> jibel,  looks like desktop's off the builder,  posting now.
<skaet> jibel,  ubuntu desktop 20110802.1 now published (i386, amd64,  amd64+mac, powerpc).
<jibel> ack
<jibel> bug 819609 is a regression
<ubot4> Launchpad bug 819609 in lightdm (Ubuntu Oneiric) (and 3 other projects) "Oneiric live CD boots to login screen (affects: 5) (heat: 24)" [High,Triaged] https://launchpad.net/bugs/819609
 * SpamapS drums fingers as RAID1 volumes rebuild.. slowly...
<jibel> skaet, I'll keep my hand low.
<jibel> bug 819609
<ubot4> Launchpad bug 819609 in lightdm (Ubuntu Oneiric) (and 3 other projects) "Oneiric live CD boots to login screen (affects: 6) (heat: 30)" [High,Triaged] https://launchpad.net/bugs/819609
<jibel> not that one
<jibel> bug 820036
<ubot4> Launchpad bug 820036 in casper (Ubuntu Oneiric) (and 1 other project) "User can not start ubiquity from a live session (affects: 1) (heat: 6)" [Critical,New] https://launchpad.net/bugs/820036
<skaet> jibel,  ack.
<skaet> slangasek, can you look at bug 820036?
<ubot4> Launchpad bug 820036 in casper (Ubuntu Oneiric) (and 1 other project) "User can not start ubiquity from a live session (affects: 1) (heat: 6)" [Critical,New] https://launchpad.net/bugs/820036
<slangasek> ScottK: perlkde demoted, per your last comment
<slangasek> skaet: ah, I'll have a look, not sure how much headway I'll make
<slangasek> anyone in #ubuntu-installer right now?
<slangasek> might be a desktop bug anyway, for that matter
<skaet> stgraber, ^^ can you have a look at this and help us figure it out?
<stgraber> skaet: yep, let me grab a desktop image. Should be able to start poking at it in the next 30min
<skaet> stgraber,  thanks!
<stgraber> skaet: not sure if someone aleady told you but the version numbers on iso.qa.u.c are wrong so the download links fail
<skaet> stgraber, nope didn't know that.
 * skaet looking
<stgraber> there's an extra 0 in there
<stgraber> I guess the easiest is to change the version number directly in the DB to avoid loosing results
<jibel> stgraber, it could be a regression of what cjwatson fixed in bug 797669
<ubot4> Launchpad bug 797669 in user-setup (Ubuntu Oneiric) (and 5 other projects) "No autologin on live session with lightdm (affects: 1) (heat: 70)" [High,Fix released] https://launchpad.net/bugs/797669
<jibel> skaet, stgraber I'll fix the version number. no big deal
<skaet> jibel,  thanks!
<jibel> and both bugs 819609 and 820036 are probably linked
<ubot4> Launchpad bug 819609 in lightdm (Ubuntu Oneiric) (and 3 other projects) "Oneiric live CD boots to login screen (affects: 7) (dups: 1) (heat: 40)" [High,Triaged] https://launchpad.net/bugs/819609
<ubot4> Launchpad bug 820036 in casper (Ubuntu Oneiric) (and 1 other project) "User can not start ubiquity from a live session (affects: 1) (heat: 6)" [Critical,New] https://launchpad.net/bugs/820036
<stgraber> yeah, sounds like some casper scripts not running or not doing what they should. Should have a desktop iso in the next 5 minutes if rsync continues at this rate
<ScottK> slangasek: Thanks.
<utlemming> ping slangasek or skaet
<skaet> yup utlemming?
<utlemming> so it looks like we have a good EC2 build of 20110802.2
<utlemming> can we enable iso tracker for them?
<skaet> utlemming,  yes please.
<utlemming> skaet: actually according to smoser, I need to ask one of you to do that for me :)
<utlemming> I don't know if I have rights to do it
<stgraber> jibel: ubiquity starts fine here
<skaet> utlemming.  fair enough.   We usually get a link from smoser to where the images are.
<stgraber> jibel: with 20110802.1 amd64
<utlemming> ah...one minute
<stgraber> jibel: I got the lightdm prompt, logged in as "ubuntu" with no password. Clicked on Install ubuntu and got ubiquity
<jibel> stgraber, oh, was I logged as guest maybe. let me try again.
<stgraber> jibel: yeah, I don't think the guest user is part of the admin/sudo group so it won't be able to start ubiquity
<stgraber> ubuntu/<no password> is the usual livecd user and the one that will be used whenever lightdm does autologin :)
<stgraber> ok, so from what I quickly checked the problem is that we don't have a /etc/lightdm/lightdm.conf so Colin's casper script won't configure autologin
<jibel> stgraber, phew, that's it. I must have clicked on guest. Thanks for double checking.
 * skaet breaths a sigh of relief.....
<skaet> Thanks stgraber. :)
<slangasek> right, I was just about to ask why it wasn't auto-logging here :)
<stgraber> skaet: no prob. Now trying to figure out where /etc/lightdm/lightdm.conf went...
<stgraber> I have it on my system but don't on the livefs...
<utlemming> skaet: here's the link http://uec-images.ubuntu.com/oneiric/20110802.2
<skaet> thanks utlemming
<utlemming> :) thank you
<stgraber>   * debian/lightdm.conf:
<stgraber>     - Removed, no longer needs configuration
<stgraber> I guess that explains it...
<skaet> ScottK, the kubuntu desktop powerpc image is posted now
<stgraber> ok, I "think" I have a "fix".
<ScottK> Thanks.
<ScottK> Dropping OOo off powerpc saved over 70MB.
<ScottK> skaet: If you could do i386 and amd64 now, I think we're good.
<skaet> ScottK,  queued up for after Edubuntu and Xubuntu
<stgraber> skaet: I'm guessing we want lightdm autologin fixed for alpha-3? (just to confirm before I upload a new casper)
<skaet> stgraber, yes please
<ScottK> Thanks.
<stgraber> skaet: uploaded (tested as well as you can test a livefs casper script...)
<jibel> slangasek, stgraber skaet NCommander : quick A3 testing status before going to meet morpheus
<jibel> apart from 819609 other notable issues with A3
<jibel> bug 819904
<ubot4> Launchpad bug 819904 in casper (Ubuntu Oneiric) (and 1 other project) "Shutdown doesn't works in live session (affects: 5) (dups: 1) (heat: 20)" [High,Confirmed] https://launchpad.net/bugs/819904
<jibel> bug 819616 (maybe regression ?)
<ubot4> Launchpad bug 819616 in ubiquity (Ubuntu Oneiric) (and 1 other project) "automatic login was not enabled even though checked in the installation (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/819616
<jibel> Other bugs reported are "known issues that should be fixed before FF" or cosmetic issues
<jibel> good night everyone. Let me know if there are images to post tomorrow morning European time.
<skaet> Thanks jibel
<skaet> will leave a post in this and the testing channel if there are likely to be images waiting for you to come online.
<skaet> Ubuntu DVD 20110802.1 (i386,amd64) posted
<ScottK> skaet: We'll need Kubuntu DVD on i386, amd64 at some point too.
<skaet> ScottK, ack
<skaet> utlemming,  uec images posted now to the tracker.
<utlemming> skaet: much thanks
<GrueMaster> What's the scoop on Ubuntu-armel-desktop?
<stgraber> disappearing for a while. Feel free to SMS/call me on my cell if I screwed up the casper upload (hopefully I didn't :))
<slangasek> GrueMaster: at last look it was failing due to unity non-installability; has that been fixed?
<skaet> thanks stgraber,  when you get a chance could you look at the others that jibel mentioned above?
<GrueMaster> I don't know, but I will shortly.  I'm doing a netinstall with ubuntu-desktop selected.
<GrueMaster> Grr.  Looks like I'm seeing a dependency issue on linux-headers-omap.
<slangasek> blah, why is the subarch name still in the livefs logfile directory name
<slangasek> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/ubuntu-omap/20110802/livecd-20110802-armel.out - unity uninstallable
<GrueMaster> sigh.
<slangasek> but maybe it's built since then, checking
<slangasek> NCommander: have you looked at this already, by chance?
<GrueMaster> he's out apparently.
<slangasek> last build attempt was before unity built
<slangasek> will retry
<GrueMaster> ok, thanks.
<skaet> slangasek,  there may be some still building.
<skaet> Ncommander started of a set before he left.
 * skaet goes to look closer
<slangasek> ah
<slangasek> yep, there they are
<superm1> stgraber, for the casper upload, it doesn't fix derivatives
<superm1> only standard ubuntu
<superm1> the situation won't be any worse for derivatives though at least
<skaet> slangasek,  yeah but they haven't triggerer from what I can tell.
<skaet> slangasek, NCommander,  have disabled the crontab,  so we don't have to deal with cross effects for now.
 * slangasek nods
<SpamapS> Hrm, why was server re-spun?
<skaet> SpamapS, was respinning all of the Ubuntu images, and did that one as well.   Since testing on the existing one hadn't gotten too far,  Daviey and hggdh said they'd pick it up.
<SpamapS> just wondering if the respin affects my almost done RAID1 test. :-P
<SpamapS> I really don't want to do it again.. it takes 2 hours :-P
<skaet> SpamapS,  don't think it should,  mostly it was to pick up desktop changes.
<GrueMaster> SpamapS: Try doing a raid on a Panda with USB drives.  Especially given bug 709245.
<ubot4> Launchpad bug 709245 in linux-ti-omap4 (Ubuntu Oneiric) (and 3 other projects) "panda: USB disk IO slow (affects: 7) (dups: 1) (heat: 46)" [High,Confirmed] https://launchpad.net/bugs/709245
<skaet> skaet,  but probably prudent to double check the package lists, and confirm no package that was useful for the test was affected.
<skaet> SpamapS, ^^ even
<NCommander> skaet: we should probably have a cron-disable script :-/
<SpamapS> skaet: talking to yourself.. and its only a3? We'll have to schedule a spa visit for you after b1 ;)
<skaet> NCommander,  heh,  feel free to write one in your spare time... contributions welcome.
<skaet> SpamapS, lol,  indeed.
 * skaet is quite fond of spa visits :)
<NCommander> SpamapS: its just the sign of a release manager becoming a veteran. Mental trama andall that
<skaet> lol,  yeah its been an interesting sort of day.  :)
<charlie-tca> Well, at least it's Tuesday this time
 * skaet is very glad we froze yesterday.  :)
<NCommander> Meh, wish we could sort the alpha 3 tagged bugs by priority
 * NCommander is going through the list
<micahg> NCommander: using advanced search you should be able to
<skaet> Edubuntu DVD 20110802.1 is now posted
<skaet> charlie-tca,  Xubuntu now building
<NCommander> bah my build script failed
<skaet> NCommander, what happened with those ARM builds from earlier?
<skaet> heh
 * NCommander had an unexpected linebreak
<charlie-tca> Thanks!
<NCommander> all the buildlive parts ran so it shouldn't take long to actually build everything
<skaet> NCommander,  coolio.  Post here and #ubuntu-testing as they emerge and get added.
<skaet> NCommander,  I've got Ubuntu preinstall building now.
<NCommander> skaet: don't run the buildlive part, that completed successfully
<skaet> NCommander, its been running for a couple of hours right now... so the buildlive may be from that.  Not sure.
<SpamapS> skaet: how do I determine the packages that were changed between 20110802 and 20110802.1 ?
<NCommander> SpamapS: grab the manifest from 802 and 802.1 and run diff
<SpamapS> NCommander: danke
<SpamapS> looks good.. nothing remotely related to the RAID test
<hggdh> SpamapS: so you have RAID covered, correct?
<SpamapS> hggdh: amd64 .. yes. :-P
 * hggdh high-fives SpamapS
<hggdh> oops
<SpamapS> nearly done
<SpamapS> This test is.. ridiculously long
 * hggdh high-2.5s SpamapS
<SpamapS> did find one bug
<SpamapS> which I introduced myself.. :-P
<hggdh> which one?
<hggdh> LOL
<SpamapS> bug 820111
<ubot4> Launchpad bug 820111 in mdadm (Ubuntu) "boot degraded question is asked twice (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/820111
<SpamapS> Probably need sto be fixed for b1
<hggdh> SpamapS: good to know, when I run raid for the i386 (unless you are willing to? ;-)
#ubuntu-release 2011-08-03
<hggdh> of course, I run it under KVM
<SpamapS> I do too
<SpamapS> would love to figure out how to record what I do, and have it re-played
<hggdh> there is a way, with the KVM tester
<SpamapS> and of course, I don't even get to post my result because its a new build. :-P
<hggdh> but it is a pain to set up, and a change on D-I borks it
<SpamapS> thats ok
<SpamapS> would only have to re-do it once when d-i changes right?
<hggdh> yes
<SpamapS> I *hate* this test
<SpamapS> Hate it.
<hggdh> correct is HATE
<SpamapS> but its super important.. as our mdadm quality is still very low. :-P
<hggdh> it is the most painful of them all
<SpamapS> so, should I submit my result on the 20110802.1 build page or just be happy that I have a bug to fix?
<hggdh> if there is no change relating to RAID, I would say go ahead and submit it
<SpamapS> ok, EOD for me.. have fun w/ i386 ;)
<slangasek> ubuntu-server arm image failing to build?
<NCommander> slangasek: ugh. something went pear-shaped, probably due to the racing builds (which caused the download-preinstall-filesystems to partially fail)
<NCommander> slangasek: once everything dies down, I'll redo the build CD image with the last live filesystem that successfully built
<skaet> charlie-tca, xubuntu alternate (20110802.1) amd64 + i386 posted.
<charlie-tca> Thanks!
<skaet> NCommander,   am about to call it an evening now,  will leave sorting out the ARM images and Kubuntu rebuilds in your hands.  :)
<NCommander> cya
<NCommander> Kubuntu 20110803 amd64/i386/powerpc posted
<ScottK> Thanks.
<ScottK> skaet: Started on Kubuntu overview: https://wiki.kubuntu.org/OneiricOcelot/Alpha3/Kubuntu
<ScottK> NCommander: I need Kubuntu armel respun since it's out of date for a bunch of stuff.
<NCommander> ScottK: the entire armel batch of images are semi-fubared, we got a race between the manual builds and the crontba
<ScottK> NCommander: OK.  No rush then.
<NCommander> which caused several things to break
<NCommander> I'm working on that :-/
<ScottK> As long as they are on the list, I'm happy.
<NCommander> Completing the ubuntu and ubuntu-server preinstalls  now from the buildd explosion earlier tonight
<NCommander> ScottK: kubuntu still needs a rebuild which I'm kicking off now
<NCommander> ScottK: looks like Kubuntu Mobile built successfully so I'm posting that now
<NCommander> ScottK: does x86 Kubuntu Mobile also need a respin (its show 080202011)
<NCommander> er
<NCommander> 20010802
<NCommander> ...
<ScottK> Thanks
<NCommander> ScottK: I think you missed my question above
<ScottK> I did.
<ScottK> What was the question NCommander?
<NCommander> ScottK: does x86 Kubuntu Mobile need a respin?
<ScottK> I see it.
<ScottK> Hmmm.
<ScottK> There was a QA web page that showed if an image had out of date pacakges.
<ScottK> NCommander: I'm not sure, but I'd respin it just to be safe it there's no others that need doing.
<NCommander> right, its not a big issue since the x86 builders are idle right now
<NCommander> so kicked
<ScottK> Thanks.
<ScottK> Burning my Kubuntu i386 usb stick right now.
<NCommander> Ubuntu ARM preinstalls are up
<stgraber> superm1: just saw your comment on derivatives. Isn't 15autologin used by any derivative using lightdm? My understanding was that this should write a lightdm.conf with autologin turned on for everyone using lightdm which should at least give you a working live session?
<stgraber> skaet: I'll have a look through the others tomorrow morning (as well as updating TechnicalOverview on the wiki for Edubuntu, sorry for not doing it yet)
<superm1> stgraber, the syntax changed in the latest lightdm release
<superm1> so the syntax it's using to correct derivatives isn't correct
<superm1> oh and derivatives will already have a lightdm.conf if they are changing anything with lightdm (theme en/dis guest, default session)
<mvo> is a base-files upload appropriate that fixes a conffile prompt or should I rather wait for after a3 with that?
<jibel> bug 820284
<ubot4> Launchpad bug 820284 in ubiquity (Ubuntu Oneiric) (and 1 other project) "Oneiric DVD 20110802.1 i386 failed to install: /usr/lib/ubiquity/target-config/30accessibility: 41: log_end_msg: not found (affects: 1) (heat: 6)" [Critical,New] https://launchpad.net/bugs/820284
<jibel> only on i386 DVDs
<jibel> ev, ^
<ev> jibel: I've uploaded casper 1.274 to fix this.
<smoser> anyone around who can answer...
<smoser> is there any reason that I should not go through with testing 20110802.2 AMIs ?
<stgraber> good morning
<stgraber> superm1: right, derivatives who already ship /etc/lightdm/lightdm.conf will get a login screen (as the sed expressions won't apply either)
<stgraber> I haven't checked but Edubuntu should be fine as we haven't customized lightdm yet
<ScottK> Kubuntu is still using KDM, so not affected.
<charlie-tca> xubuntu will need a desktop respin for bug 820284
<ubot4> Launchpad bug 820284 in ubiquity (Ubuntu Oneiric) (and 3 other projects) "Oneiric DVD 20110802.1 i386 failed to install: /usr/lib/ubiquity/target-config/30accessibility: 41: log_end_msg: not found (affects: 1) (heat: 6)" [Critical,Invalid] https://launchpad.net/bugs/820284
<skaet> good morning all
<stgraber> good morning skaet
 * skaet working through the backscroll
<skaet> stgraber,  any uploads pending on the bugs highlighted before I start off the rebuilds?
<stgraber> skaet: I'm still syncing my images at the moment so no upload pending on my side at the moment
<stgraber> lightdm will most likely be broken for mythbuntu/xubuntu. I can have a look at fixing that if that's something we want for alpha-3
<stgraber> (it's going to show a login box for any derivative shipping with a /etc/lightdm/lightdm.conf)
<skaet> smoser,  not aware of any issues,  most of the churn is on desktop side.
<skaet> charlie-tca, looks like you've need a respin for the Xubuntu,  do you want to wait and see if stgraber can fix the lightdm issue?  or should I go ahead and respin and pick up the current fixes?
<charlie-tca> Sure, we can wait, but my desktop images are un-installable at this time
<stgraber> charlie-tca: can you paste the content of your /etc/lightdm/lightdm.conf?
<charlie-tca> in a fresh install?
<stgraber> charlie-tca: the one in your live environment
<charlie-tca> sure
<skaet> mvo, can you give me the bug number?
<superm1> stgraber, http://paste.ubuntu.com/657949/ is the one in mythbuntu
 * skaet has started off Ubuntu DVD rebuild
<stgraber> ok, I'm tempted to just overwrite the lightdm.conf file in all cases. That should be good enough for alpha-3 and as lightdm isn't actually visible to the user, it's not really important what theme it'd be using
<stgraber> superm1, charlie-tca: makes sense?
<superm1> stgraber, hm probably does make sense i guess
<charlie-tca> I just found it, deep in /usr/share/xubuntu
<charlie-tca> That will re-enable guest logins, though?
<superm1> well only if someone logs out from the live session
<charlie-tca> okay
<stgraber> nope, my config disables guest login
<charlie-tca> works for me, then. The only change I see is disabling guest login
<stgraber> as it's done with casper, that's just going to affect your live environment. Post-install you'll be back to using whatever your usual lightdm.conf is
<charlie-tca> Xubuntu lightdm.conf is at http://paste.ubuntu.com/657955/
<superm1> there is still a ubiquity bug with when it tries to modify lightdm.conf too for autologin still
<charlie-tca> Okay
<superm1> so that will still be busted
<stgraber> superm1: what happens in that case? Just no autologin post-install or something worse?
<superm1> no autlogin post install yeah
<stgraber> skaet: new casper uploaded
<mvo> skaet: https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/820233 is the bug
<ubot4> Launchpad bug 820233 in base-files (Ubuntu) "conffile prompt during natty -> oneiric upgrade (affects: 2) (heat: 10)" [High,In progress]
<skaet> stgraber,  thanks
<superm1> stgraber, and actually the bug is user-setup for installer.  it's doing the same thing casper used to.
<skaet> mvo, since the fix is ready,  go ahead and upload.  we'll pick it up on the same respin as stgraber's latest upload
<stgraber> superm1: ok, except that the same trick won't work for user-setup as we probably want to keep the lightdm.conf they ship
<stgraber> superm1: I guess the fix will be to create lightdm.conf if it doesn't exist, make sure whoever ships a lightdm.conf has the autologin value in there but commented and then modify user-setup to sed these
<superm1> stgraber, yeah.  so somehow or another all the smarts has to get written in sh.
<superm1> that's a good enough solution i think
<skaet> ScottK,  are we looking like we'll need any Kubuntu respins today, or are your images looking good?
<ScottK> skaet: I don't know of any Kubuntu specific issues that would drive respins.  If Ubuntu is respinning for 820284 then perhaps we need to too.
<ScottK> I'd like to pick up mvo's conffile fix too.  I know that affects Kubuntu because I hit it myself.
<mvo> ok, sorry for the delay, I can upload it now
<skaet> mvo,  let meknow the package version for it, so I can monitor and kick things off as soon as it publishes.
<mvo> subject: [ubuntu/oneiric] base-files 6.4ubuntu4 (Accepted)
<skaet> ok, looks like casper and base-files are published now,   will start the respinning:  ubuntu-desktop, edubuntu-dvd, xubuntu-desktop, kubuntu-desktop, ubuntu-dvd, kubuntu-dvd
<skaet> stgraber, superm1, charlie-tca, ScottK, ^^ have I missed any that need a rebuild?
<charlie-tca> not here
<charlie-tca> well, not any missed here
<charlie-tca> mythbuntu working?
<skaet> mythbuntu desktop is affected by one of the casper fixes, so yes it should probably be added to the list.   superm1 - are all the necessary pieces in place to do a respin of mythbuntu?
<skaet> NCommander,  builds started off,  in this order:
<skaet> echo building ubuntu daily-live; buildlive ubuntu daily-live && for-project ubuntu cron.daily-live; echo building edubuntu dvd; buildlive edubuntu-dvd dvd && for-project edubuntu cron.dvd; echo building xubuntu daily-live; buildlive xubuntu daily-live && for-project xubuntu cron.daily-live; echo buiding kubuntu daily-live; buildlive kubuntu daily-live && for-project kubuntu cron.daily-live; echo building ubuntu dvd
<skaet> ; buildlive ubuntu-dvd dvd && for-project ubuntu cron.dvd; echo building kubuntu dvd; buildlive kubuntu-dvd dvd && for-project kubuntu cron.dvd
<skaet> superm1,  ^^ let me know if mythbuntu is ready to be added to the respin list?
<superm1> nothing left to add for mythbuntu respin
<superm1> wasn't planning to fix anything else
<skaet> superm1,  ok  I'll queue it up and mark that its being respun.
<charlie-tca> skaet: Xubuntu encrypted LVM fails. It won't accept any password as correct to let me login to the computer
<charlie-tca> and it can be release noted.
<skaet> charlie-tca, thanks.
<jibel> skaet, slangasek , stgraber charlie-tca : DVD 20110803 i386 fails to install. 820284 is fixed but ubiquity stops at "configuring target system"
<jibel> I'll replay the installation in debug mode and file a bug with the logs
<stgraber> jibel: ok. I'll go grab some lunch and can look at that when I'm back if nobody else does it first (ev? :))
<charlie-tca> Thanks, jibel
<skaet> thanks jibel, stgraber
<skaet> ubuntu desktop (20110803) has been posted
<skaet> gilir,  do you want a respin to pick up the bug fixes that have gone in last night and this morning or are you good to release with the images you have?
<jibel> bug 820485
<ubot4> Launchpad bug 820485 in ubiquity (Ubuntu Oneiric) (and 1 other project) "ubiquity stops installation at 'Configuring target system' (affects: 1) (heat: 6)" [Critical,New] https://launchpad.net/bugs/820485
<skaet> ev, stgraber,  ^^ could one of you look into this?
<gilir> skaet, no it's good for me, unless security fixes of last upload of chromium are really needed in the alpha
<skaet> gilir,  should be fine then.   alphas are work in progress, and security fixes can be picked up on updates.  :)
<micahg> gilir: it's the standard type of exploits, and there will be another round in 2 weeks, so I don't think it's worth respinning for
<gilir> micahg, skaet ok thanks :)
<charlie-tca> superm1: I finally found where the missing icons come into things. If Xubuntu is installed, and the first xubuntu session is picked at login, the icons are missing and network manager icon doesn't give the connections.
<charlie-tca> If the second Xubuntu session is selected, everything works as expected
<superm1> charlie-tca, hm that still doesn't seem to make sense.
<charlie-tca> It's because if the first Xubuntu session is picked, it uses Xfce defaults instead of Xubuntu. If the second session is picked, it defualts properly
<charlie-tca> technical part:
<charlie-tca> XDG_CONFIG_DIRS end up containing /etc/xdg/xdg-default/ instead of /etc/xdg/xdg-xubuntu
<charlie-tca> and can not be reset, even if the other session is picked on next login
<superm1> by that logic, it shouldn't happen on mythbuntu though because we don't have the 'default' session option though.
<superm1> eg no symlink /usr/share/xsessions to default.desktop
<jibel> skaet, stgraber , desktop images 20110803 fails with the same error then DVD, 20110802.1 were ok.
<skaet> jibel,  thanks for letting us know.
<charlie-tca> superm1: That's the only time xubuntu has those missing icons and missing info in network manager
<superm1> does nm-applet actually care about XDG_CONFIG_DIRS?
<superm1> grep'ing the source I don't see references to it
<charlie-tca> I don't know. I just know if they pick the right session for us, they get all the icons and info
<seb128> superm1, not sure but glib,gtk do care
<seb128> superm1, it might be using glib functions which care
<superm1> ah
<stgraber> skaet: I'll have a look
<stgraber> jibel: what's the hostname of the box running the iso tracker again?
<skaet> Thanks stgraber.
<stgraber> jibel: also, your log shows the last action was running ma-apply (migration assistant). Do you also have Windows in that VM?
<ScottK> skaet: Any idea how long until we'll see Kubuntu live images?
<jibel> stgraber, limequat
<jibel> stgraber, and there was no Windows in that VM and I choose to install on the whole disk
<skaet> stgraber,  the edubuntu dvd is off the builders,  is it worth posting?
<skaet> ScottK,  Xubuntu's building and Kubuntu live is right after.    See posted list above ^^
<ScottK> What's that in time?  roughly?
<stgraber> skaet: if ubiquity is broken somehow, probably not
<highvoltage> stgraber: can you jog my memory about wubi? is there anything we need to do to have it on the dvd?
<stgraber> highvoltage: I need some artwork done and then have a branch merged by ev (currently just on my laptop)
<stgraber> highvoltage: I can send you the specs for the 2-3 images we need
<stgraber> highvoltage: lp:~edubuntu-dev/wubi/edubuntu-support what we need is the various images in data/images/Edubuntu*
<highvoltage> stgraber: ok, will do that tomorrow
<highvoltage> stgraber: ah I see it's just simple logos, I'll do it now
<stgraber> jibel: running the same install here, hopefully I'll find something
<stgraber> highvoltage: yep, the .ico is probably the same as our favicon, the two others need a bit more work but still quite easy to do I guess
<stgraber> jibel: ok, stuck at the same point. Now trying to figure out what's wrong
<NCommander> skaet: thats a heck of a lot of builds
<skaet> NCommander, yeah and we'll be rebuilding them likely, based on what stgraber finds out.
<stgraber> jibel: can you do a quick test for me?
<stgraber> jibel: remove /usr/lib/ubiquity/target-config/50gkd-caps before running ubiquity and see if that "fixes" it
<NCommander> skaet: sounds like its going to be another long day of rebuilds
<skaet> NCommander,  server images and lubuntu are pretty much set at this time.   waiting to hear back on ARM,  alternates seem ok.  but desktops and dvd have picked up a snag.
<NCommander> which snag?
<stgraber> skaet: I'm 90% sure gnome-keyring is the problem. It got uploaded yesterday and introduces a new ubiquity target-config plugin doing a setcap call in the target.
<stgraber> skaet: removing it seems to make ubiquity work again though gnome-keyring will most likely be broken post-install. I'll poke cyphermox to try and get a fix for that script
<NCommander> oh
<NCommander> that snag
<NCommander> I saw it in the bug list :-/
<skaet> stgraber, ok, please go ahead and revert it.
<skaet> we can release document it.
<stgraber> cyphermox: ping?
<highvoltage> stgraber: added it, not sure how it will look in wubi, but I'll try it out at some point
<stgraber> highvoltage: I can send you a wubi.exe if you have a machine to test it on
<highvoltage> stgraber: I'll see the artwork if I run it under wine right?
<stgraber> guess so
<highvoltage> yes please send it, lets see what it does
<utlemming> jamespage: ping
<GrueMaster> skaet: No critical issues on the arm desktop images that would require a respin.
<stgraber> highvoltage: http://www.stgraber.org/download/wubi.exe
 * skaet hugs GrueMaster 
<skaet> GrueMaster, thanks, that's good news.  :)
<GrueMaster> Well, not to say there aren't issues.  Just nothing preventing release.  :P
<highvoltage> stgraber: that seems to be an ubuntu one (I just get the ubuntu branding)
<skaet> heh,  caveats appreciated.  :)
<highvoltage> stgraber: (ah sorry I had to choose edubuntu first)
<skaet> charlie-tca,   do you want me to post the xubuntu as it comes off the builders or is it likely affected by gnome-keyring?
<charlie-tca> no point in posting it. If Ubuntu won't install...
 * skaet nods
<charlie-tca> gonna be a long day today
<skaet> charlie-tca, are the xubuntu alternates in reasonable shape?
<charlie-tca> well, as long as no one uses encrtyption
<charlie-tca> encryption?
<charlie-tca> If the only thing that fails is encrypting the drive, I will go with it
<stgraber> skaet: just talked to cyphermox on the phone. I'll try a potential fix quickly, if that doesn't work I'll revert the code in gnome-keyring and upload it
<skaet> stgraber, thanks!
<NCommander>  /win 38
<NCommander> bah
<GrueMaster> Am I wrong to assume that the pool is frozen during release?  I am having issues reporting bugs because of obsolete packages on images built this morning.
<GrueMaster> NCommander: Everyone knows that the correct answer is 42 for the /win.  :P
 * NCommander stabs GrueMaster 
<NCommander> GrueMaster: its soft freeze, so only seeded packages are frozen, and even then its only at teh point where its a gentlemans agreement keeping everything in place
<skaet> GrueMaster, its a soft freeze for main and seeded universe.
<skaet> heh,  what Ncommander said.
<cyphermox> stgraber: any idea why setcap would hang like this ?
<cyphermox> it certainly didn't when I tested the script in a live session
<stgraber> cyphermox: I'm finishing the test when directly using chroot. It looks good, I'll just need to run a getcap to make sure it worked.
<stgraber> cyphermox: my guess is that in-target does some weird stuff with stdin/stdout, debconf or similar stuff that setcap doesn't like or that ends up locking the install process somehow
<cyphermox> oh
 * cyphermox stabs in-target
<stgraber> skaet, cyphermox: Replacing by a simple call to chroot worked fine. getcap confirms that cap_ipc_lock+ep is set
<cyphermox> thanks
<stgraber> I'll upload a new gnome-keyring in a few minutes
<skaet> stgraber,  thanks.   Let me know what version to look for from the publisher.
<stgraber> cyphermox: is there a separate packaging branch for gnome-keyring or are you using the UDD one for that package?
<stgraber> skaet: Uploading gnome-keyring_3.1.1-0ubuntu4_source.changes: done.
<skaet> stgraber thanks!
<cyphermox> stgraber: lp:~ubuntu-desktop/gnome-keyring/ubuntu; but it contains some 3.1.4 stuff
<stgraber> cyphermox: can I let you merge what I pushed to the UDD branch into the ~ubuntu-desktop branch?
<stgraber> jibel: btw, ubuntu desktop i386 with the new gnome-keyring package installs and boots fine here!
<stgraber> now to finally try Edubuntu and update the TechnicalOverview
<cyphermox> stgraber: sure.
<stgraber> cyphermox: thanks
<charlie-tca> I have held off on updating until I know I will have something
<skaet> charlie-tca, is there an issue with the xubuntu alternates as well?
<charlie-tca> I am keeping them
<charlie-tca> I won't have an encrypted install working
<jibel> stgraber, sorry dinner time. I'm back.
<skaet> jibel,  we're waiting for the gnome-keyring fix to build and publish,  then will be kicking off the desktop and DVD builds again.
<stgraber> jibel: if you want to do some testing while waiting for the new builds, just updating gnome-keyring in the livefs should work fine
<jibel> skaet, I was reading the backlog. Thanks for the summary :)
<skaet> :)
<ScottK> Looks like the new Kubuntu images are up.
<skaet> ScottK, 20110803.1 Kubuntu Desktop published to iso tracker.
<skaet> heh
<skaet> yeah
<ScottK> Great.
<skaet> ScottK, if they look sane,  I'll respin the Kubuntu DVD's while we're waiting for the gnome-keyring fix to get published.
<jibel> stgraber, ok trying that now.
<jibel> stgraber, do I need another test with  50gkd-caps disabled too, I assume that's needless now
<GrueMaster> skaet: I hear there is a respin in the works?
<stgraber> jibel: nah, updating gnome-keyring will give you a fixed 50gkd-caps
<skaet> GrueMaster,  for images with the bad gnome-keyring update in them.
<skaet> GrueMaster, wasn't planning on respinning ARM images unless you indicate it was necessary.
<GrueMaster> What is the issue?  And does it affect arm?
<GrueMaster> Ok, thanks.
<GrueMaster> That was what I was wondering.
<GrueMaster> Make sure everyone knows not to respin armel.  All the testing is extremely manual and time consuming at this point, so if I don't benefit from a respin, I don't want it.
<GrueMaster> Closer to final release would be understandable to ensure everything is in sync.
 * skaet nods
<skaet> NCommander, ^^ ,  FYI.  :)
 * ScottK reads "Make sure ... respin ... armel." Got it.
<ScottK> ;-)
<ScottK> skaet: "Sane" requires an install, right?
 * ScottK is starting one.
<skaet> ScottK,  yup.   or a check that you don't have gnome-keyring_3.1.1-0ubuntu3 in your manifest.
<ScottK> That should be pretty easy
<skaet> jibel, stgraber, NCommander,  gnome-keyring_3.1.1.-0ubuntu4 has published,  have kicked off Ubuntu desktop rebuild.
<ScottK> libgnome-keyring0	3.1.4-0ubuntu1
<ScottK> That's not it, right?
<skaet> ScottK,  doesn't look like it to me,  but cyphermox is the expert.
<ScottK> skaet: Assuming that doesn't worry you, I think we're good.
<cyphermox> ScottK: I don't think you should have 3.1.4-0ubuntu1 yet :/
<ScottK> skaet: If you've got a slot open now, I'd go ahead and do the DVD respin then.
<skaet> NCommander and I will be standing by.   Will kick off the Kubuntu DVDs when the next slot occurs.
<skaet> Ubuntu Desktop building now.
<cyphermox> nevermind, that's fine
<skaet> Would like to confirm its sane, before starting off Edubuntu and Xubuntu.
<ScottK> That's what is says in http://cdimages.ubuntu.com/kubuntu/daily-live/current/oneiric-desktop-i386.manifest
<stgraber> skaet: I'm doing a quick test of Edubuntu by manually updating the current image
<skaet> stgraber,  that would be appreciated. :)
<cyphermox> ScottK: that looks fine
<jibel> stgraber, ubuntu desktop amd64 installs and boots with gnome-keyring 3.1.1-0ubuntu4
<ScottK> Was there an issue earlier with hanging at the "Detecting file systems ... 100%" point?
<charlie-tca> Configuring target system... was
<charlie-tca> I don't remember one at Detecting file systems...
<ScottK> I think I got one.
<ScottK> Oh, no.  Just really slow
<ScottK> Nevermind.
<NCommander> right no ARM respins
<NCommander> gotit
<stgraber> skaet: just finished a first edit of TechnicalOverview of edubuntu. I'll re-update once I actually tested it :)
<skaet> stgraber,  thanks!   (and fair enough ;) )
<ScottK> skaet: I got a good install from the current Kubuntu Desktop image, so I think we're on track.
<skaet> ScottK,  excellent.   NCommander has started off the Kubuntu DVD builds.   Ubuntu desktop is about to be published...
<skaet> jibel, stgraber, NCommander, Ubuntu Desktop 20110803.1 posted
<NCommander> DVD builds almost done
<skaet> NCommander Kubuntu DVD builds almost done,  Ubuntu and Edubuntu still pending.  yes?
<NCommander> xubuntu kicked
<NCommander> brb
<ev> skaet: here now.  Apols, was out all evening.
<ev> Where can I be of help?
<skaet> ev,  thanks for checking in!  stgraber sorted issue.
<ev> awesome
<skaet> :)
<GrueMaster> Not sure how I missed it, distraction from multitasking probably.  Netinstall fails on omap (beagleXM). Bug 820621. Can be worked around, but very annoying.
<ubot4> Launchpad bug 820621 in debian-installer (Ubuntu) "netinstall fails to make omap system bootable during install (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/820621
<skaet> GrueMaster, my preference is that since there's a workaround to document it for now.  But would like NCommander's opinion (since he'll be the one staying up late spinning image ;) )
 * NCommander looks at the bug
<GrueMaster> Not an image to respin per-say.
<NCommander> looks like f-k-i is wrong
<NCommander> checking
<skaet> ScottK,  NCommander,   Kubuntu DVD 20110803.1 posted.
<ScottK> Thanks.
<NCommander> GrueMaster: grumble, its a f-k-i bug, boot.script doesn't get created
<GrueMaster> so...fix it.  :P
<NCommander> GrueMaster: I'm sorely tempted to let it slide for A3 with a note saying OMAP3 netboot images are broken
<NCommander> uploading f-k this close to release is probably a bad idea
<ScottK> NCommander: GrueMaster was saying earlier he was anxious to retest all the armel images.
<GrueMaster> I actually have no problem with that.  It isn't too difficult to manually fix, and this is still alpha.
<ScottK> GrueMaster: Did you get a chance to look at the Kubuntu images?  It would be really appreciated if you could.
 * GrueMaster fires flaming toads at ScottK
 * ScottK has toad for dinner.
<NCommander> ScottK: well it won't directly require a respin; to update f-k in preinstalls would require an ubiquity bug, but f-k-i is only part of netinstalls
<ScottK> Hmmm crunchy.
<GrueMaster> sigh.  No, but I can.
<ScottK> GrueMaster: Thanks.
<NCommander> skaet: I'm going to let this slide for A3, and release note it
<ScottK> NCommander: I think for an Alpha it's perfectly fine to release not.
<ScottK> e
<skaet> NCommander,  fair enough.
<NCommander> bug information updated
<NCommander> thus noted
<ScottK> Our new package manager for Kubuntu defaults to allowing untrusted packages to be installed.  Ugh.
<ScottK> skaet: If we end up respinning Kubuntu for any reason, I definitely want to fix Bug #820638
<ubot4> Launchpad bug 820638 in muon (Ubuntu Oneiric) (and 1 other project) "Muon defaults insecure (affects: 1) (heat: 258)" [Critical,Triaged] https://launchpad.net/bugs/820638
<ScottK> The fix is a one liner, so it's just a matter of if there's a target.
<skaet> ScottK,  ah that answers the question I was about to ask.
<skaet> ScottK,  if you want it in,  after the rest of the desktop/DVDs are in,  we can do the builds.   Will you have enough testers available to check out the images in that window before release?
<ScottK> It's the testers that are the problem.
<ScottK> We just don't have that many.  Otherwise I'd respin without hesitation.
 * GrueMaster resembles that remark.
<GrueMaster> Ok.  "lack of" testers is the problem.  :P
<skaet> ScottK,  your call.   We can probably have images ready before tomorrow morning Europe.  Unfortunately Ubuntu desktop & DVD will be in test mode as well then.
<ScottK> Let's leave it.
<ScottK> GrueMaster: Yes, lack of, sorry.
<skaet> ScottK,  ok.
<skaet> stgraber, Edubuntu DVD 20110803.1 now posted
#ubuntu-release 2011-08-04
<skaet> charlie-tca, Xubuntu Desktop 20110803.2 posted
<charlie-tca> along with both alternates again ...
<charlie-tca> Thanks, skaet
<charlie-tca> can the alternate tests be carried forward? the images did not change
<skaet> charlie-tca, if the manifests are the same,  or close enough,  should be fine.
<charlie-tca> exact match
<skaet> charlie-tca,  should be fine then.
<charlie-tca> Thanks
<skaet> charlie-tca, sorry it was an oversite that the alternates got spun again.
<charlie-tca> I figured it had to be. No problem, I just don't have enough hours to run all the tests again
<charlie-tca> um, after all this stuff today, Xubuntu live session does *not* auto-login
<skaet> superm1,  mythbuntu images posted
<skaet> mythbuntu 20110804
<skaet> NCommander,  I'm going to head to dinner now,  when Ubuntu DVD emerges,  please announce it here and #u-testing.
<NCommander> will do
<skaet> NCommander, thanks!
<NCommander> charlie-tca: ugh, do the images still work, or this an actual blocker?
<GrueMaster> Finally, kubuntu-armel images downloaded - testing commencing.
<GrueMaster> Wow, this is much slower than Natty.
<GrueMaster> ScottK: Not going to be able to put a full effort into the Kubuntu arm images unfortunately.  I'm getting them to boot no problem, but I won't be able to run through all the apps like I did in Natty.
<GrueMaster> So far, the install is doing well, and no major issues (aside from extreme slowness on 8G Class 10 SD).  I'll try to run a net install later next week onto a USB drive to do a little more thorough beating.
<NCommander> ubuntu-dvd is built
<charlie-tca> back from dinner and starting installs now
<charlie-tca> for Xubuntu
<ScottK> GrueMaster: Thanks. Anything you can do is appreciated.
<charlie-tca> pretty sure I will not be able to do all the install tests tonight on xubuntu
<charlie-tca> will have to finish tomorrow
<charlie-tca> still trying to get the first one done to see if it is working now
<charlie-tca> skaet, jibel, NCommander : Xubuntu desktop images fail
<charlie-tca> Configuring target system... stuck
<charlie-tca> manifest shows gnome-keyring3.1.1-0ubuntu4
<charlie-tca> I don't think we can publish the alpha3 milestone for Xubuntu
<charlie-tca> skaet, jibel, NCommander : please do NOT publish Xubuntu alpha3. The images are broken and will not install
<charlie-tca> getting a bug number
<charlie-tca> bug 820731
<ubot4> Launchpad bug 820731 in ubiquity (Ubuntu) "Oneiric Ocelot Xubuntu Desktop images fail to install (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/820731
<ScottK> skaet: Kubuntu is looking good.  We still have more testing to get done, but no show stoppers so far.  If you can find a volunteer to do some Wubi testing for us, that'd be great as I don't think we have anyone who can do it.
<ScottK> I don't think it's essential for Alpha 3, but it'd nice to hit it on at least one image.
<ScottK> We could stand some amd64+mac help too, but I think I know someone who might be able to do that.
<NCommander> charlie-tca: k, I'll tell skaet not to publish
<ScottK> NCommander: Do you know of anyone who can do wubi testing?
<NCommander> nope
<ScottK> OK.  Thanks.
<jibel> charlie-tca, skaet I can't reproduce 820731 and xubuntu 20110803.2 installs and boots fine.
<jibel> charlie-tca could you double check the checksums of the images you tested ?
<jibel> Ubuntu DVDs 20110804 are on the tracker but http://cdimage.ubuntu.com/dvd/20110804/ is empty
<stgraber> skaet: rsync is pretty slow here. I'll need another hour and a half to download Edubuntu...
<nigelb> stgraber: plz send more bandwidth? :)
<stgraber> I found some old images around, running zsync on them now, hopefully it'll be faster
<stgraber> download speed wasn't too bad, I was getting a pretty stable 1MB/s on a 10Mb/s internet but I'm downloading DVD images...
<skaet> good morning all
<charlie-tca> good morning
<skaet> stgraber,  you have the extra time.
<skaet> jibel, charlie-tca - what's the latest with the Xubuntu images?
<charlie-tca> I can' t get them to work at all, jibel can' t get them to fail
<mdeslaur> gah, swig2.0 in universe now has a swig package that superseded the swig1.3 package in main
<slangasek> stgraber, ev: can you confirm that fixing the xubuntu autologin problem requires another (simple) reupload of casper?
<slangasek> seems to affect mythbuntu as well
<stgraber> skaet: edubuntu is ready for release
<stgraber> slangasek: simple upload of casper won't do it
<stgraber> slangasek: it might fix mythbuntu though
<skaet> stgraber: *\o/*  very glad to hear it.   :)
<skaet> ScottK,  can you put the updates for Kubuntu in the https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview
<skaet> ?
<stgraber> skaet, slangasek: New casper uploaded
<slangasek> stgraber: what else is needed to fix xubuntu, then, if casper is insufficient?
<stgraber> this should fix autologin for environments where lightdm.conf already exists as a symlink and where "ubuntu" as a session exists
<stgraber> slangasek: lightdm currently tries to run the "ubuntu" session, that doesn't exist with xubuntu
<slangasek> ah
<stgraber> slangasek: bug 806408
<ubot4> Launchpad bug 806408 in xubuntu-default-settings (Ubuntu) (and 1 other project) "After xubuntu upgrade or installation, default session on greeter must be xubuntu (affects: 2) (heat: 24)" [Medium,Triaged] https://launchpad.net/bugs/806408
<skaet> superm1,  how do the mythbuntu images look?   are we good to release?
<superm1> all that we were waiting on was whatever happened on the casper thing
<superm1> we don't get a lot of people to pick up until beta usually though, so i'm fine release noting it if it's not figured out
<skaet> superm1,  thanks.   ok, we'll release then.
<seb128> skaet, I've added some desktop items to the technicaloverview, tremulox will still add some software center notes and I think we are good
<skaet> seb128,  Thank you.  :)
<jibel> seb128, do you think bug 815077 should be release noted? It has been reported many times.
<ubot4> Launchpad bug 815077 in indicator-session (Ubuntu) (and 1 other project) "restart is missing from SessionMenu (affects: 57) (dups: 8) (heat: 288)" [Medium,Confirmed] https://launchpad.net/bugs/815077
<seb128> jibel, hum, it seems worth adding to the notes yes
<seb128> jibel, can you do it?
<jibel> seb128, sure, I'll do
<charlie-tca> skaet: added bugs to release notes
<seb128> jibel, thanks
<skaet> charlie-tca, thank you.!
<jibel> Daviey, bug 820111 -> release notes ?
<ubot4> Launchpad bug 820111 in mdadm (Ubuntu Oneiric) (and 1 other project) "boot degraded question is asked twice (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/820111
<ScottK> skaet: I'll be at my computer in a little over an house.
<skaet> ScottK,  thanks.
 * Laney lends ScottK a grappling hook
<ScottK> I think Kubuntu is good on i386, amd64, and armel.
<ScottK> House / Hour
<ScottK> Android autocorrect FTL.
<jibel> skaet, Ubuntu is good, release notes reviewed and updated.
<skaet> jibel,  thanks.    I've updated the QA tracker to remove the builds we're not shipping with.   Could you please review it and https://wiki.ubuntu.com/OneiricOcelot/ReleaseImageContacts to make sure it matches your understanding as well.
<skaet> ?
<jibel> k
<skaet> stgraber,  has anyone done a sanity test on Edubuntu dvd i386,  am noticing it isn't marked as tested.
<stgraber> skaet: I tested LTSP live, the live environment and I just finished an install
<jibel> skaet, I'll remove powerpc and amd64+mac from the tracker, ok ?
<stgraber> rebooting now to do one more test and I'll mark it as good
<skaet> jibel,  yes.  I thought I got them already... guess I switched windows.  :P
<jibel> :)
<skaet> thanks stgraber
<skaet> thanks jibe
<skaet> jibel even.  :)
<cyphermox> jibel, it's late now but xubuntu amd64 on bare metal worked here
<jibel> cyphermox, thanks for confirming.
<stgraber> skaet: done
<skaet> stgraber,  goodness.   Thank you.
<jibel> charlie-tca, cyphermox test passed ^
<charlie-tca> why won't they pass for me?
<charlie-tca> Do I have two bad computers?
<charlie-tca> both images worked here monday
<cyphermox> there has to be something special... where was it failing?
<charlie-tca> bug 820731
<skaet> NCommander, slangasek - the images for release are:
<ubot4> Launchpad bug 820731 in casper (Ubuntu) "Oneiric Ocelot Xubuntu Desktop images fail to install (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/820731
<skaet> lubuntu cd (i386, amd64)
<skaet> mythbuntu cd (i386, amd64)
<skaet> edubuntu dvd (i386, amd64)
<skaet> kubuntu cd (i386, amd64)
<skaet> kubuntu alternate (i386, amd64)
<skaet> kubuntu dvd (i386, amd64)
<skaet> kubuntu arm (omap, omap4)
<skaet> netboot (i386, amd64, omap4)
<skaet> ubuntu server (i386, amd64)
<skaet> ubuntu cloud (cloud32, cloud64)
<skaet> ubuntu core (arm)
<skaet> ubuntu preinstall (omap3, omap4)
<skaet> ubuntu cd (i386, amd64)
<skaet> ubuntu alternate (i386, amd64)
<skaet> ubuntu dvd (i386, amd64)
<skaet> NCommander, slangasek, jibel, stgraber, ScottK, smoser, Daviey,  please advise if any of these ^^ don't match your expectations.
<chrisccoulson> is it ok to upload stuff now? :)
<skaet> chrisccoulson, hold off for a couple of hours please.  :)
<chrisccoulson> skaet, ok, no problem
<smoser> skaet, above, 'cloud' should probably be better named 'cloud-images'
<smoser> or 'cloudimg'
<smoser> to differenciate cloud-host from cloud-guest
<slangasek> skaet: do you know if they're all marked correctly in the tracker such that publish-image-set.py should DTRT?
<NCommander> skaet: I should have a kubuntu preinstall inthere and ubuntu-server
<slangasek> smoser: is "cloud-images" anything more than uec/ec2 with a new name?
<skaet> slangasek,  I hope between me and jibel we've got them all now.  But please double check.  Lots of last minute churn.
<NCommander> \/win 40
<smoser> slangasek, in no way shape or form
<smoser> cloud-images == nothing more than uec/ec2 with a new name
<slangasek> right
<slangasek> marking xubuntu as failed on iso.qa so the publisher script DTRT
<skaet> NCommander,  ubuntu server preinstall(omap3, omap4)
<jibel> skaet, does ubuntu preinstall (omap3, omap4) include server and desktop ?
<NCommander> skaet: rightsorry, relooked at the list and its all there. eyes are play tricks
<NCommander> jibel: its a separate desktop and server image
<skaet> NCommander, kubuntu preinstall (omap3, omap4)
<jibel> NCommander, that is why I ask, it is not clear from the list above.
<skaet> jibel, yeah it was an oversite tnot to make it explicit.  :)
<slangasek> well this is fun, 'bzr update' is failing with an error about trying to write to the branch :P
<jibel> k
<slangasek> skaet: tracker shows netinstall images from 20110729 for armel; are those meant to be published or not?
<slangasek> I'm not sure where these images are anyway, there doesn't seem to be anything on antimony
<GrueMaster> slangasek: netinstall images are only rebuilt when D-I is, not daily.
<skaet> slangasek,  I was just looking at them too....
<slangasek> GrueMaster: oh, then these should be named 'netboot' like the existing i386/amd64 ones
 * skaet nods
<slangasek> no?
<GrueMaster> yep
<skaet> is the omap3 one ok?
<slangasek> who has access to fix those names?
<skaet> jibel,  can you fix the names?
<GrueMaster> omap3 (omap) is broken.  It leaves the image unbootable.
<skaet> GrueMaster, so we're only to publish omap4 one correct?
<GrueMaster> I'd ask NCommander.  If the fix can be pushed withpout changes to the image (i.e a package fix pulled during install), then we can publish it.
<GrueMaster> He knows the exact nature of the breakage.
<skaet> NCommander,  ^^ netboot omap4 to be released or not?
<GrueMaster> omap4 is good.  Don't confuse the two.
<GrueMaster> netboot omap is the one in question.
<NCommander> skaet: what gruemaster said
<GrueMaster> NCommander: Can you fix the omap boot.scr creation issue w/o changing the netboot image?
<skaet> NCommander, Gruemaster thanks.
<skaet> Ok,  revised list (based on what I'm seeing in QA tracker) now is:
<jibel> skaet, done
<skaet> edubuntu dvd (i386, amd64)
<skaet> kubuntu alternate (i386, amd64)
<skaet> kubuntu desktop cd (i386, amd64)
<skaet> kubuntu desktop arm (omap3, omap4)
<skaet> kubuntu dvd (i386, amd64)
<skaet> kubuntu arm (omap3, omap4)
<skaet> lubuntu cd (i386, amd64)
<skaet> mythbuntu cd (i386, amd64)
<skaet> netboot (i386, amd64, omap4)
<skaet> ubuntu alternate (i386, amd64)
<skaet> ubuntu core (arm)
<skaet> ubuntu desktop cd (i386, amd64)
<skaet> ubuntu desktop preinstall (omap3, omap4)
<skaet> ubuntu dvd (i386, amd64)
<skaet> ubuntu server (i386, amd64)
<skaet> ubuntu server preinstall (omap3, omap4)
<skaet> ubuntu cloud images (cloud32, cloud64)
<skaet> NCommander,  can you please start the publishing off for the above.
<NCommander> skaet: the script doesn't work for me I'm getting IOError
<NCommander> debugging it but until thats done ...
<slangasek> NCommander: pastebin me a full python backtrace?
<skaet> NCommander,  ack.  Lots for me to do in the interim... ;)
<NCommander> slangasek: http://paste.ubuntu.com/658775/
<slangasek> NCommander: mmk... no http proxy in the way either?
<NCommander> none
<slangasek> NCommander: grab a network trace with wireshark to see what's going on?
<NCommander> slangasek: I just ran it on another machine and it worked
<slangasek> alrighty
<NCommander> so my laptop foobared
<slangasek> so there are still two images on there that the script doesn't know how to handle yet: Kubuntu Desktop Arm, Ubuntu Core armel
<slangasek> we might as well get those sorted in the script, so we don't have to do it by hand next time as well...
<NCommander> yeah
<NCommander> ugh
<slangasek> actually, the first one is another case of inconsistent naming on the tracker
<GrueMaster> What is the difference between Kubuntu Arm and Kubuntu Desktop Arm?  I don't even see a Kubuntu Arm listed.
<NCommander> was publish-release modified to handle the tgz of ubuntu-core?
<slangasek> jibel: can Kubuntu Desktop Arm (omap) be renamed to Kubuntu Desktop armel+omap on the tracker, please, and likewise for omap4?
<slangasek> GrueMaster: no difference; it might be more correct to call this 'Kubuntu Preinstalled'?
<slangasek> ah, the publisher code actually assumes that any armel images are preinstalled
<slangasek> and maps 'Desktop' to 'preinstalled-desktop'
<slangasek> so that's fine
<GrueMaster> We also have kubuntu mobile.  I would say keep it at Kubuntu Desktop Arm, same as we have for Ubuntu Desktop
<GrueMaster> ok
<slangasek> it still needs fixing to Kubuntu Desktop armel+$subarch
<jibel> slangasek, done
<slangasek> jibel: thanks :)
<slangasek> now to teach the script about Ubuntu Core
<GrueMaster> Ah, that looks good.
 * slangasek whines at the inconsistent directory layout of ubuntu-core
<slangasek> I don't think publish-release is going to be able to handle this at all
<GrueMaster> inconsistent?
<slangasek> yes
<slangasek> convention is $project/daily-$imagetype/$date
<slangasek> ubuntu-core is using $project/$date
<davmor2> slangasek: it's been like that for ever :D possibly due to there only being Ubuntu on the first release
<GrueMaster> So it needs a ./daily/$DATE format.  I see.  Kind of adds an unneeded layer for now, but for future...
<NCommander> skaet: did we spin a source image?
<slangasek> davmor2: no, this is a new image called ubuntu-core which is defying the convention
<slangasek> "ubuntu-core" != "ubuntu"
<slangasek> :)
<davmor2> slangasek: Ah okay
<NCommander> slangasek: publish-release is probably going to break miserably
<GrueMaster> davmor2: Think of ubuntu-core as an SOC independent extremely minimal chroot environment.
<slangasek> GrueMaster: well, I need to get this fixed up to even be able to run the publishing scripts for it.  But first I want to figure out where ubuntu-core images are being *generated*, since it doesn't seem to be part of the public cdimage repo
<slangasek> ah no, just looking in the wrong place
<slangasek> found it
<GrueMaster> Ask infinity.
<GrueMaster> ok
<NCommander> slangasek: we need a source image rebuild, last rebuild was 20110707
<NCommander> slangasek: you won't happen to know the arcanic ruins for that offhand
<NCommander> ^- skaet
<slangasek> NCommander: I thought it was always built as part of the alternate CD build
<NCommander> I thought it was a separate set of ruins. Either way, the image is horribly out of date
<slangasek> where do you even see it?
<NCommander> ~/cdimage/www/full/source/current/source/*
<NCommander> the publish-image-set list has source on there which is why I checked to see if its been rebuilt
<slangasek> hmm, that's not how it was being built last time I turned the crank
<NCommander> the crank obviously has been changed :-/
<slangasek> and someone didn't save the crank info in the authoritative crontab :)
<NCommander> ECRACKNOTFOUND
<NCommander> er
<NCommander> should be CRANK but it kinda works either way
<slangasek> there's a bin/cron.source; I'll try running it
<NCommander> slangasek: k
<GrueMaster> Doesn't follow naming conventions either.  http://cdimage.ubuntu.com/source/current/source/.  Should be http://cdimage.ubuntu.com/source/current/.  Also, natty images shouldn't be in the daily dir.
<NCommander> GrueMaster: source images are rarely used in the internet age
<NCommander> GrueMaster: we forgot to publish them with natty release and the bug didn't come until 2 months later :-/
<GrueMaster> I know, but if we are building cdimages for them, they should at least conform to standards.
<NCommander> GrueMaster: agreed
<NCommander> slangasek: i got a source-20110804.log, looks like that was the right cran
<NCommander> *crank
<NCommander> I'll publish everything else why we're waiting
 * skaet nods
<ScottK> skaet: Those match my expectations.  Please save the Kubuntu Desktop images for powerpc and amd64+mac as I have potential testers for them and we may be able to release them late.
<slangasek> ScottK: how "late"?  Do you want us to leave the cronjob disabled for kubuntu desktop for a few days?
<ScottK> slangasek: Please.  The amd64+mac tester is traveling to the desktop summit right now.
<slangasek> ok
<slangasek> skaet, NCommander: ^^ so we leave kubuntu desktop disabled in cron after release
<skaet> ScottK, I deleted them from the iso tester after your indication we wouldn't be publishing,  but I'll see if they can be re-added.  (after we put the release out).
<skaet> slangasek,  ack.  :)
<ScottK> skaet: Thanks.  As long as we have the images somewhere, I think the ISO tracker is less important.
<ScottK> skaet: Looking at tech overview now.
<NCommander> slangasek: we're ignoring oversize for this cycle, due to transtitions?
<skaet> NCommander,  yes
 * NCommander is reconfirming
<slangasek> skaet: what transitions are in progress that we should be leaning on immediately post-release?
<skaet> slangasek, probably we should get together with cjwatson and pitti early next week, and do some prioritization/leaning.   We knew we would be oversized right now.
<slangasek> ok
<skaet> slangasek,  also need to get decision about USB/DVD image made.
<slangasek> USB/DVD?
<skaet> shrink down DVD to 1.5G
<slangasek> right
<slangasek> did we ever actually decide *what* we want to cut to get it there?
<slangasek> I think that was the problem; we had a wide ranging discussion at UDS that identified lots of things that were expendable, but no firm decision on what to keep and what to cut
<NCommander> slangasek: with the expect of source, we're published
<slangasek> NCommander: and -core?
<NCommander> er,expection of core and source:-)
<skaet> NCommander,  let me know when its started showing up on the mirrors.
<NCommander> skaet: I haven't ran sync mirrors yet, still waiting for source to build
<NCommander> slangasek: core going to require significant changes to publish-release to publish
<slangasek> rather, I need to change the daily build scripts for it, munge the existing tree, and then teach publish-release about it using the existing model
<NCommander> that works too, although sounds timeconfusingly annoying
<slangasek> it's the right way around
<ScottK> skaet: Kubuntu bits in the tech overview.
<slangasek> ah, infinity co-opted build-livecd-base to do the ubuntu-core building, hum
<smoser> skaet, slangasek cloud-images are ready. If i am not around, please ping utlemming and he can push the release button.
<skaet> ScottK,  just scanned through.  Looks good,  thanks.
<smoser> if *that* fails, then call my cell.
<skaet> smoser,  you can start pushing the button now.
<skaet> rest are going out.
<smoser> well then, button being pushed.
<skaet> Announce will happen when the mirrors are showing them.
<smoser> utlemming, i have the above ^
<utlemming> k
<slangasek> skaet, smoser: I think we're probably ready to pull the lever on cloud, no?
<slangasek> ah yes, so you said :)
<smoser> its being pulled.
<skaet> :)
<slangasek> yay
<NCommander> \o/
<NCommander> source is done, publishing
<slangasek> publish-image-set taught about Ubuntu core images
<skaet> Thanks slangasek!
<NCommander> slangasek: thecommand itself doesn'twork
 * NCommander kicks his space
<NCommander> cdimage@antimony:~/cdimage$ ARCHES='armel' for-project ubuntu publish-release daily-preinstalled 20110802 preinstalled-core no alpha-3
<NCommander> No daily for oneiric armel on 20110802!
<slangasek> NCommander: yeah, these ubuntu-core images have been built in a way that defies all the conventions
<NCommander> great
<slangasek> do we *have* to release these with alpha3?  Can I kick it back to infinity and make him do it over? :P
<NCommander> it shouldn't really be preinstall
<NCommander> it should be rootfs
<slangasek> I think that's a gratuitous name difference
<NCommander> and ++ slangasek's idea
<NCommander> slangasek: generally when I think of preinstall, I think of an all in one solution; not some assembly required like I think with core :-P
<Daviey> skaet: Everything on track for server iso's?
<NCommander> slangasek: its not the only rootfs ship we've shipped Kubuntu Mobile was a rootfs on N900 and shipped as daily-live
<skaet> Daviey,  yes,  smoser's pushed the button to publish cloud image,  we've pushed out server
<skaet> Daviey,  waiting for them to be picked up, visible, etc. now.
<smoser> https://cloud-images.ubuntu.com/releases/oneiric/alpha-3/
<NCommander> skaet: I haven't pushed sync-mirrors, nothing should push out until I do
 * skaet makes a note to update a link in the TechOverview.
<Daviey> skaet / smoser: good cookies.
<Daviey> skaet: I already did earlier :)
<skaet> Thanks Daviey !  :)
<slangasek> NCommander: kubuntu-mobile-11.04-preinstalled-mobile-armel+omap4.img.gz <-- not a rootfs tarball, at least
<NCommander> it was a rootfs:-P
 * NCommander scurvies out of sight
<NCommander> slangasek: stillnot happy publishing core despite the name change
<charlie-tca> Did anyone find a reason I can't install the Xubuntu desktop images?
<slangasek> NCommander: yep, I've constructed a for-project commandline by hand now; am going back to adjust publish-image-set accordingly
<slangasek> NCommander: so ubuntu-core/releases now exists, so I guess everything's good now?
<slangasek> the source image is built too
<NCommander> slangasek: yeah, just need to sanity and cross-check
<NCommander> charlie-tca: bah, you didn't want Xubuntu A3 published, did you due to the broken image?
<charlie-tca> right
<charlie-tca> Until we find why it is not installing on hardware
<NCommander> Oh good
<NCommander> I had enough forsight to delete it out of the tracker last night which caused it not to publish
<slangasek> charlie-tca: how is it failing?
<NCommander> Carry on :-)
<Daviey> smoser / utlemming: Can one of you two drive getting the updated template/theme for cloud-images.* .. lacking branding!
<charlie-tca> it hangs at "Configuring target system" on both 32bit and 64bit computers
<charlie-tca> slangasek: bug 820731
<ubot4> Launchpad bug 820731 in casper (Ubuntu) "Oneiric Ocelot Xubuntu Desktop images fail to install (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/820731
<slangasek> skaet: we have an action item for infinity (or someone) to clean up the publishing of ubuntu-core images; the current publishing is a complete bodge repurposing a script that wasn't meant to be used this way, and the filenames are (IMHO gratuitously) different from any other images we've built before which means they either need to have their names changed or publish-release needs to be extended to know about them
<skaet> slangasek,  yup agree.
<slangasek> (would really prefer the former; it's not scalable to have publish-release work with every filename under the sun)
<slangasek> fortunately, this is why we have alphas so we get these issues shaken out before beta ;)
<NCommander> slangasek: right, so I'm doing the final cross-check and we still have edubuntu and desktop A2 release folders
<Daviey> charlie-tca: Isn't gnome-power-manager being deprecated?
<NCommander> should I bring death to them?
<charlie-tca> I don't know. Xubuntu doesn't use it
<skaet> slangasek,  indeed it is.   Will add it to the actions on the weekly agenda so it gets tracked there, but we'd best follow up offline.
<charlie-tca> casper should not require gnome-power-manager
<slangasek> NCommander: yes, those directories should be moved to ~/cdimage/old-images/{releases,edubuntu/releases}/oneiric
<charlie-tca> Daviey: casper should be generic, shouldn't it?
<slangasek> Daviey: s/deprecated/rendered worthless by GNOME upstream design decisions/, ITYM :P
<Daviey> charlie-tca: ack, sure is a bug - looks like bdmurray identified the location.
<Daviey> slangasek: :D
<NCommander> k
<NCommander> old images cleared out
<charlie-tca> How do I get that fixed now?
<NCommander> with the exception of ubuntu-core old ones
<slangasek> NCommander: in what sense is ubuntu-core an exception?
<NCommander> skaet: slangasek bah, edubuntu dvd never made it onto the tracker! its untested AFAIK
<slangasek> did you mean xubuntu maybe?
<NCommander> slangasek: it has old those folders ofold builds
<Daviey> Would seeding gnome-power-manager in Xubuntu cause any problems for A3?
<slangasek> NCommander: ok - but you weren't actually clearing out old dailies or anything.  just making sure :)
<charlie-tca> Direct conflict with xfce4-power-manager, yes
<slangasek> NCommander: I see edubuntu dvd on the tracker just fine
<skaet> NCommander,  edubuntu DVD has been tested by stgraber,  and he's signing off on the images.
<NCommander> bah
 * NCommander shutsup
<NCommander> right, I'm idiot
<NCommander> ignore me
<skaet> NCommander,  much rather you ask if something seems like an anomoly.  :)
<stgraber> edubuntu definitely was on the tracker, I even left comments for each of the tests ;)
<slangasek> is everything published to our satisfaction?  Time to hit 'sync-mirror' (if you haven't already, NCommander?)
<NCommander> slangasek: looks good to me, the diff is in/tmp/diff if you want to review
<NCommander> slangasek: BTW, do you know how to edit the cdimage.u.c./netboot page? Its out of date
<slangasek> NCommander: edit by hand
<NCommander> k
<slangasek> NCommander: pass on reviewing the diff, TL;DR :)
<NCommander> slangasek: I'llpost the index.html diff,the tree diff is already up
<NCommander> slangasek: http://paste.ubuntu.com/658839/
<GrueMaster> Erm, http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/ has no files anymore.
<NCommander> GrueMaster: it will get fixed when I smack the sync-mirror script
<slangasek> GrueMaster: rather, I suspect they're still syncing
<slangasek> they weren't in ubuntu-core/daily-preinstalled before, but ubuntu-core/*... since they've moved, they have to resync
<slangasek> NCommander: http://cdimage.ubuntu.com/netboot/oneiric/ might have the wrong list of images?
<NCommander> slangasek: http://paste.ubuntu.com/658841/
<NCommander> slangasek: just finished that :-)
<GrueMaster> Not sure that they are preinstalled.
<slangasek> (like the non-existent 'versatile' one)
<slangasek> NCommander: ack
<NCommander> are we finally ready to hit sync-mirror?
<slangasek> GrueMaster: well, as said above, the ubuntu-core images that have been published are currently a total bodge; we can rename them for the next milestone once we get some clarity around what they're supposed to be / do
<slangasek> NCommander: yes
<NCommander> crank turned
<persia> slangasek, What sort of clarity are you seeking?
<NCommander> persia: thats a loaded question if I've ever seen one :-P
<slangasek> persia: so if these images really need to use completely different filenames (rootfs.tar.gz instead of one of the many other already-recognized types), then someone needs to take care of adding support to publish-release et al. for this; and the current daily publishing that abuses publish-livecd-base instead of using publish-daily like all the others means that bits of the directory structure are missing, and image rotation isn't happ
<slangasek> ... publish-release doesn't know how to deal with it
<slangasek> so the differences in how these images are handled vs. the existing ones need to be accounted for
<persia> slangasek, Ah, right.  Yeah, the names were sadly broken.  Filetype is correct, but the rest of the name is not.
<NCommander> laptop battery is about to go poof, brb
<slangasek> persia: also, there's the question of whether we think these should be published as cdimage.u.c/releases/oneiric/$milestone/ubuntu-core-*, or cdimage.u.c/ubuntu-core/releases/oneiric/$milestone/ubuntu-core-*, or releases.u.c/releases/oneiric/ubuntu-core-*
<persia> I've never really understood how the decisions for any of those options were taken.
<slangasek> rough consensus :)
<persia> By ~ubuntu-cdimage, or some other group?
<jibel> Kubuntu Desktop (amd64+mac|powerpc) 20110803.1 restored on tracker
<slangasek> persia: I think it's ubuntu-release with input from TB as well as Canonical IS on questions of feasibility
<ScottK> jibel: Thanks.
<persia> slangasek, Ah, that makes sense.  Thanks.
 * NCommander drums his fingers while waiting for the sync to finish
<NCommand1r> my VPS just went to uber-slow mode :-(
<NCommand1r> slangasek: did you get my ping?
<NCommand1r> also, any chance I can slip away for 30m and grab lunch?
<NCommand1r> I'm going ot grab lunch. I have my phone on me and will be on Mobile IRC if needed
<slangasek> NCommand1r: I believe we're done now, so enjoy your lunch :)
<slangasek> skaet: ^^ AFAIK everything's published
<Daviey> soft-freeze thawed now?
<ScottK> Yes.
<Daviey> Groovy.
<jbicha> hi, very minor thing but the title for http://cdimage.ubuntu.com/releases/oneiric/alpha-3/ says Daily Build
<jbicha> the alpha 2 page has it correct
<skaet> jbicha,  you're seeing mirroring effects.
<skaet> I was having it too.
<jbicha> skaet: thanks
<skaet> np.
<skaet> all,  Alpha 3 is now released.
<Daviey> \o/
<slangasek> jbicha: is it fixed with a shift-reload?
<slangasek> ah, no, it's still out there
<Daviey> Shows Alpha 3 for me.
<slangasek> skaet: what does IS say the current max disk footprint for cdimage is?
<skaet> NComander,  slangasek, stgraber, charlie-tca - very much appreciate your help with getting this one out the door!  Thank you!!
<skaet> slangasek,  1 T,  they're about to move to a 2T system.
<skaet> they were waiting until we got this release out.
<charlie-tca> I feel like I didn't do so much this time.
<slangasek> skaet: hrm, that doesn't sound right; we've never been above 600GB
<skaet> slangasek,  I'm going from memory of a conversation - will double check.
<slangasek> jbicha: can you still reproduce the "Daily Build" problem?
<jbicha> slangasek: no, thanks
<slangasek> cool
<slangasek> I'm not 100% certain it's fixed, so if you (or anyone else) sees it again, please let me know
<bdmurray> Does anybody happen to know what Natty has no datereleased using the API?
<slangasek> no idea what that references; I only know about release dates for milestones in LP, not series
<skaet> ScottK,  there's a fair amount of kubuntu/*/hardy/ space being used on cdimage,  can it go to old-images?
<ScottK> skaet: Yes.
<skaet> ScottK,  thanks
<infinity> slangasek: Sorry about not thinking about releases publishing with ubuntu-core beforehand.  Will fix a bit more permanently when I get home (and argue with people about naming, if they feel the need to bikeshed)
<slangasek> infinity: ack and thanks :)
<infinity> slangasek: Want to mail me a grumpy reminder about it?  I'm about to pass out, then spend a day on trains and planes, so who knows if I'll remember the last few hours. :P
<slangasek> infinity: sent
<slangasek> you can tell it's a grumpy reminder because I only have one smiley in the body
<infinity> slangasek: :P
#ubuntu-release 2011-08-05
<ScottK> slangasek: It looks like I was wrong about smokekde.  It needs to be in Main.  If you could move it back to Main then I could build korundum on powerpc and armel and then we could give component mismatches a chance to get unconfused.
<ScottK> The one last source package was the (I'm pretty sure) the piece I was missing.
<ScottK> KDE has gone to over 80 source packages now, so it's taking some getting used to.  This is all code that's been in Main before.
<slangasek> ScottK: ack, repromoted
<ScottK> slangasek: Thanks.
<charlie-tca> to further the frustration of yesterday, the images from today are working on the same hardware
<skaet> charlie-tca, is there a manifest diff between the two?   might give a clue.
<charlie-tca> no, the old images have been removed
<charlie-tca> There were two casper uploads since the alpha3 image, one must have fixed it
<charlie-tca> I stand by my decision to not release. I still think that was a good thing
<skaet> charlie-tca,  its why we have Alpha's,  so we can figure out this sort of thing before betas.  ;)
<charlie-tca> heh, yeah
<charlie-tca> It just really frustrates me that it would not install for three days, and today it works
<charlie-tca> but, I guess that is why I "test", too
<charlie-tca> Otherwise, it might have gone out, to frustrate a lot more people
<skaet> yup,  that's why getting these images tested before they go out is very important to me.
<skaet> would like to make sure we have 100% coverage on all the ones that ship,  but for alphas its not a hard rule.   Key is to make it easier for developers and testers to find and fix things before the betas.  :)
<charlie-tca> This is true.
<ScottK> skaet: Sorry I missed the meeting.  The short version for Kubuntu is we had a Good Alpha 3 and don't have a lot of suprise issues to deal with.
<ScottK> Not switching to Light DM seemed to make things easier ....
<charlie-tca> yeah
<charlie-tca> I could see that
<ScottK> It was an easy decision for us since the KDE front end is still not written.
<charlie-tca> Apparently, lightdm works great if you use Ubuntu only.
<ScottK> Of course.
<charlie-tca> They seem to have forgotten the rest of us, though
<ScottK> Hopefully the stack of Alpha 3 bugs will help fix that.
<charlie-tca> That would be nice
<charlie-tca> skaet is on top of them, too
<ScottK> infinity: I don't suppose there's any chance of getting adare resurrected today so powerpc has some hope of keeping up?
<skaet> ScottK, thanks.  One thing I was curious about is what's the outlook for Kubuntu mx5 and n900 images before FF?
<ScottK> I need to check in on mx5 stuff.
<ScottK> n900, probably not, but it'll be tech preview grade again, so I don't see an issue with FFe for it.
<ScottK> I suspect for mx5 it'd make sense just to do headless/server this cycle and then see about more images later.  It's easy enough to add $DESKTOP if you want one and it's less testing that way.
<skaet> just don't want n900 landing too late, and us scrambling to get the tools ready to publish the images.
<skaet> re: mx5,  fair 'nuf.
<skaet> ScottK,  before I head out,  do you want kubuntu's crontab enabled this weekend at somepoint?  or leave it until monday.
<skaet> ?
<ScottK> skaet: Please leave it until Monday.  powerpc testing is going on right now and mac+amd64 is still promised.
<ScottK> We should be able to add some more images to the release.
<skaet> ScottK,  sounds good.   Will do.
<skaet> (or rather,  will leave it alone ;) )
<ScottK> Great.  Have a nice weekend.
#ubuntu-release 2011-08-06
<infinity> ScottK: You want lamont, I don't do physical buildd abuse anymore
<ScottK> OK.  I gather he's on vacation, I thought you might for old time's sake ...
<infinity> ScottK: I would if I had access to do so.  I'm not with IS anymore.
<infinity> ScottK: But I can poke around when I'm back from my long weekend, if no one's made it happy yet.
<ScottK> Thanks.
<ScottK> slangasek: Based on http://iso.qa.ubuntu.com/qatracker/result/6221/1011 I'd like to release the current Kubuntu Desktop powerpc image (I've added a warning about the limited testing to the Kubuntu tech overview).
<ScottK> I was hoping you might be able to turn the knobs for this.
<ScottK> skaet and/or jibel: I'd like to make sure the bug in http://iso.qa.ubuntu.com/qatracker/test/6219 gets added to the Alpha 3 bugs.  It looks to me like an imporant one not to lose track of.
#ubuntu-release 2012-07-30
<stgraber> that's going to clear the SRU report quite a bit ;)
<ScottK> Yes.  Yes it is.
<stgraber> commented some more on libart-lgpl to try and remind everyone of what's expected for a multi-arch change in -updates (though the same test should happen in the dev release, really...)
<ScottK> Thanks.
<micahg> ScottK: regressions in the security pocket, need to be fixed in the security pocket (unless the security team doesn't want to fix them)
<micahg> err..unless the security team doesn't want them fixed that way
 * micahg guesses in this case it doesn't make much difference
 * micahg is referring to the cacti lucid SRU for onlookers
<infinity> I was curious.
<infinity> So, why not just drop the SRU and reupload it as a security update? :)
<infinity> (Assuming it's sane)
<micahg> infinity: that would work, but I don't know if it's worth it in this case (shouldn't make a difference), will leave it up to mdeslaur and jdstrand
<tkamppeter> hi, it is about the CUPS SRU.
<seb128> tkamppeter, hey, what about it?
<tkamppeter> I got verifications for 5 of 6 bugs. For one bug, bug 973270 it seems that the original reporter went away.
<ubot2> Launchpad bug 973270 in cups "Printer does not provide REQUIRED job history." [High,Fix committed] https://launchpad.net/bugs/973270
<tkamppeter> The bug is fixed by adding the ipp14 backend, the same fix as for the verified bug 945028.
<ubot2> Launchpad bug 945028 in cups "network printing via LiveBox: cups-ipp-missing-validate-job" [High,Fix committed] https://launchpad.net/bugs/945028
<tkamppeter> The OP of bug 973270 has at least given positive feedback when I asked him to try the ipp14 solution via my PPA.
<ubot2> Launchpad bug 973270 in cups "Printer does not provide REQUIRED job history." [High,Fix committed] https://launchpad.net/bugs/973270
<tkamppeter> So can we simply move cups to -updates then? This would improve the 12.04.1 a lot.
<tkamppeter> seb128, ^^
<tkamppeter> Anyone has read my messages above?
<tumbleweed> generally speaking, we don't need the original reporter to verify the SRU. Anyone can
<tkamppeter> tumbleweed, problem here is that it is hardware-dependent, so only someone with a Samsung ML-3710ND (or Samsung with same buggy IPP implementation) can veryfy this fix.
<tkamppeter> tumbleweed, due to not getting an answer here (I do not have such a Samsung to verify) I suggest to promote the SRU to -updates based on the other 5 bugs which are all verified.
<tkamppeter> The fix for this one bug is the same as the fix for the verified bug 945028.
<ubot2> Launchpad bug 945028 in cups "network printing via LiveBox: cups-ipp-missing-validate-job" [High,Fix committed] https://launchpad.net/bugs/945028
<tkamppeter> tumbleweed, therefore the fix cannot be taken out of the SRU, we simply consider it the fix for bug 945028.
<ubot2> Launchpad bug 945028 in cups "network printing via LiveBox: cups-ipp-missing-validate-job" [High,Fix committed] https://launchpad.net/bugs/945028
<infinity> tkamppeter: Based on the fact that it (a) fixes another bug, and that (b) the general fix (thought not this build) was tested previously, it seems reasonable, but are there any scary regression potentials for that particular part of the update on other hardware?
<infinity> tkamppeter: If it's pretty isolated to specific hardware that was already broken, I wouldn't have any issues with being somewhat lax on the one unverifiable bug.
<tkamppeter> There are no regression potentials at all, as all other hardware (automatic setup) uses the standard ipp backend. The fix is the addition of an extra backend which needs to get selected manually.
<tkamppeter> infinity, ^^
<infinity> tkamppeter: Check, that's comforting.
<infinity> tkamppeter: I'll look into it more when I do my SRU run later today, then.  Thanks for the heads-up.
<infinity> tkamppeter: Can you try to summarise this conversation (especially the bit about the backen having no regression potential due to being a manual selection) in the unverified bug?
<tkamppeter> infinity, We will add instructions to the Release Notes of 12.04.1 to manually select ipp14 in case of "bad" hardware. How do I propose an item for the Release Notes?
<infinity> tkamppeter: Hrm, is there no way the UI can present it as an option somehow? :/
<infinity> tkamppeter: I mean, release notes are fine and all, but the average person who has issues with their printer probably doesn't read release notes.
<tkamppeter> infinity, bug 973270 updated.
<ubot2> Launchpad bug 973270 in cups "Printer does not provide REQUIRED job history." [High,Fix committed] https://launchpad.net/bugs/973270
<infinity> tkamppeter: Thanks.
<tkamppeter> infinity, currently there is no intuitive GUI way to select the backend. There appear entries in system-config-printer, but they do not tell for what 1pp14 is good for.
<infinity> tkamppeter: They can't be annotated some pleasant way?
<tkamppeter> infinity, it would require patching system-config-printer and the patch would add new UI strings which will not have a translation.
<infinity> (Sorry, printing on Linux isn't my forte, I don't own a printer, and the only people I know who have a printer run Windows but, for instance, I poke at possible drivers for my parents' printer and get "HP LJ6 (PS), HP LJ6 (PCL5), HP LJ6 (PCL6)", etc, etc.  They're not pleasantly-named to non-technical users, but the choice is there, at least.
<CareBear\> is now a good time to try to get libusb updates into the next release? :)
<ScottK> micahg: OK.
<stgraber> infinity: for bug 1021293, our only proper way of testing the fix is to upload a new ubiquity with the refreshed source package, if I do that and confirm that the fix indeed works, are you happy to accept both debian-installer-utils and ubiquity when debian-installer-utils reaches the 7 days mark?
<ubot2> Launchpad bug 1021293 in ubiquity "Ubuntu 12.04 install stalls when doing apt-get upgrade" [High,In progress] https://launchpad.net/bugs/1021293
<stgraber> I believe we might have some more ubiquity fixes coming so I don't really want to see ubiquity stuck for 7 days in proposed when the only delta is a source package refresh
<infinity> stgraber: If it's just a refresh of d-i-u, I'm happy to see them go in together, absolutely.
<infinity> stgraber: Just remind the SRU-on-duty who accepts d-i-u of this conversation, if it's not me. :P
<stgraber> ok :)
<stgraber> will upload ubiquity shortly then
<infinity> stgraber: You know, if ubiquity is pretty much the only way to verify the d-i-u fix anyway, I'd push the whole mess in today, if you can do some test installs and verify solidly.
<infinity> stgraber: Oh, but it needs the accountservice thing too, right?
<stgraber> nope, accountservice is another fix for the same bug, any of the two fix should work
<infinity> Ahh.
<infinity> Yeah, reading the bug log.
<stgraber> the accountservice SRU is for people who are using the original 12.04 media without updating ubiquity
<infinity> So, they're not interdependant.
<stgraber> right
<infinity> Right, then I stand by my previous statement.  Get me a ubiquity that's smoke-tested to do ubiquity-ish things, and is well-tested to fix the bug, and the waiting period matters less to me.
<infinity> It's not like anyone actually tests installers from proposed enough to make the waiting period mean anything.
<stgraber> right :)
<stgraber> hmm, looks like the source refresh (using -proposed) will also pick up the calxeda enablement
<stgraber> (base-installer 1.122ubuntu7.1 and flash-kernel 2.28ubuntu42.2)
<infinity> stgraber: That should all be no-ops for ubiquity anyway.
<infinity> stgraber: Since we don't use ubiquity on that platform.  If you just double-check the diffs to make sure the platform-specific bits are guarded.
<infinity> (Or I can when you upload)
<stgraber> yeah and they are marked verification-done anyway
<infinity> Well, they're v-done for d-i.  No one's made sure they don't break ubiquity somehow. :P
<infinity> But they really shouldn't, unless Michael did something silly.
<infinity> And, actually, we're not building *any* ARM desktop images for 12.04.1 are we?
<infinity> So, it's not really a big deal anyway. :P
<stgraber> indeed
 * infinity goes back to watching TV until his day starts officially.
<brendand> stgraber, infinity - for the d-i-u fix what are you guys looking for? would installing the 12.04.1 daily be sufficient verification?
<stgraber> brendand: not quite, you need a new ubiquity (I'm working on that), then take an old daily, update just ubiquity and go through the install
<brendand> stgraber, how to update just ubiquity?
<stgraber> brendand: drop to a shell, apt-get update, apt-get install ubiquity ubiquity-frontend-gtk
<stgraber> well, after adding -proposed
<brendand> stgraber, when and where do you drop to the shell?
<stgraber> infinity: ubiquity uploaded. Diff looked sane, delta is arm-specific except for d-i-u (as expected), though not all of the arm delta is highbank-specific, there's also a change for omap3/omap4 kernel handling with the linaro kernels (but nothing that looked wrong)
<stgraber> brendand: before starting the install
<stgraber> anyway, it's a trivial SRU verification for someone who knows what to look for, so I'll do it as soon as my new ubiquity is accepted and built
<cjwatson> brendand: Yeah, if you want to test this properly then you need to start with 12.04(.0) and upgrade ubiquity - otherwise you have a new accountsservice and don't encounter the bug
<cjwatson> Although testing with a more current daily might be good for regression analysis
<cjwatson> Daviey: How did things go with the new squashfs-based server CD last week?
<cjwatson> I'd have looked in on it but I was knocked offline.
<stgraber> can someone please reject the ubiquity in precise-proposed? (missing bug reference)
<stgraber> pushing a new one now
<ScottK> stgraber: Done.
<stgraber> thanks
<Daviey> cjwatson: it looks swell!
<Daviey> cjwatson: I noticed that report.html is skewed.. and there was something else trivial (escaped me atm)
<Daviey> but yeah, it looks great!  So thanks mucly
<infinity> cjwatson: Your statement about accountservice would be true if it were fixed, but that's still in the queue. ;)
<infinity> cjwatson: (Though that will probably change today, I guess)
<stgraber> infinity: if you have a sec to look at that ubiquity upload, it'd be appreciated. I'm kind of hoping for it to be published and ready for testing post-lunch here.
<cjwatson> Daviey: Yeah, I was meaning to attack the installability report
<infinity> stgraber: I'll poke in a sec.
<cjwatson> Cool
<ScottK> infinity: The amavisd-new SRU in queue fixes a problem that will cause 10.04 -> 12.04 upgrade failures, so it'd be really nice to get that in soon.
<Laney> SRU people: Do you mind if multiple SRUs are tracked in the same bug if they are tied together?
<infinity> Laney: If it's all addressing the same bug, multiple tasks on the one bug are just fine.
<Laney> tidy
<ScottK> Thanks infinity .
<infinity> NP.
<Laney> leave transmageddon for now, still got bug wrangling to do
<infinity> Laney: Sure, I'll look at it next week. ;)
<Laney> I'm sure other people process SRUs too :P
<infinity> I'll be sure to let them know not to!
<infinity> RAOF, ScottK, SpamapS, bdmurray, slangasek: Laney doesn't want anyone to process his SRUs, ever.
<infinity> Laney: There. ;)
 * ScottK makes a note.
<Laney> poison supplier copenhagen
<Laney> whoops, this isn't google!
 * infinity starts building immunities to Danish poisons.
<cjwatson> https://code.launchpad.net/~cjwatson/launchpad/copy-auto-approve/+merge/117299 so close ...
<highvoltage> /win 23
<stgraber> infinity: there you go, that's bug 1021293 verified
<ubot2> Launchpad bug 1021293 in accountsservice "Ubuntu 12.04 install stalls when doing apt-get upgrade" [High,In progress] https://launchpad.net/bugs/1021293
<Laney> utouch stuff was removed before the new things built?
<micahg> hrm? why does Firefox have new binaries?
<highvoltage> Laney: hmm, is utouch stuff coming to the archives?
<Laney> highvoltage: It's Canonical's multitouch stuff
<Laney> has been around for some time
<Laney> just seems to be a slightly abrupt transition
<skaet> Laney,  there's some renaming going on.   Its probably a transitory side-effect.
<Laney> skaet: I see that :-)
 * skaet experimenting with building precise from proposed images before adding to cron job
<micahg> ah, the new Firefox binaries from -security were never seen in -proposed, /me files bug
<micahg> Bug #1031027
<ubot2> Launchpad bug 1031027 in launchpad "new binaries seen in -updates/-security hit binary NEW in -proposed" [Undecided,New] https://launchpad.net/bugs/1031027
<infinity> Laney: I removed the sources, not the binaries...
<infinity> micahg: Pretty sure that bug already existed.
<micahg> infinity: couldn't find it :)
<micahg> feel free to dupe
<Laney> infinity: I don't see it in Packages
<Laney> and I noticed because of the ubuntustudio daily image build failure
<Laney> (libgrip0 uninstallable)
<infinity> Erk.  Maybe the remove-package --source-only thing doesn't work? :/
<infinity> Dangit.
<Laney> Oh well. Accept it and we can transition stuff.
<infinity> Can't until it's built everywhere.
<infinity> Thanks, firefox.
<infinity> *sigh*
<infinity> Checked command history, I definitely removed only source.  And terminal log claimed it was doing that too.
<infinity> Not sure if I blame the API utility, or the API itself.
<Laney> staging is a fine playground
<stgraber> infinity: and you didn't get a failure e-mail from LP? (with the new async stuff, the "yay it worked" from the client doesn't mean much anymore...)
<infinity> stgraber: Removals aren't async, are they?
<infinity> stgraber: But it's clearly not a failure.  It worked "too well". :P
<Laney> I don't see that you can just remove source.
<Laney> requestDeletion
<Laney> Delete this source and its binaries.
<infinity> Well, the old tool used to be able to, but it didn't use the API.
<infinity> So, if the API can't, Colin shouldn't have pretended it could in the help text. :)
<Laney> Looking at the source, it certainly tries to.
<Laney> hah, comment in LP's source:
<Laney>         # Special deletion method for the api that makes sure binaries
<Laney>         # get deleted too.
<infinity> GAH.
<infinity> Well, bug #1031061 at any rate.
<ubot2> Launchpad bug 1031061 in ubuntu-archive-tools "remove-package --only-source doesn't do as advertised" [Undecided,New] https://launchpad.net/bugs/1031061
<Laney> ITYM source-only
<infinity> Laney: That, yes.  I actually used -S, used the long form in the bug title to avoid ambiguity.  Clearly failed. ;)
<infinity> Fixed.
<slangasek> infinity: do you know offhand what launchpad is using to generate Packages files?  is it apt-ftparchive?
<slangasek> apt-ftparchive appears to mangle package descriptions that contain leading whitespace
<elmo> slangasek: it is
 * slangasek nods
<slangasek> thanks
<infinity> slangasek: Yes.
 * slangasek wonders why copy-package seems to be working only intermittently for him in partner
<slangasek> oh, or perhaps it's working but dropping things in unapproved without telling me and without me noticing ;)
#ubuntu-release 2012-07-31
<RAOF> The xorg-server that's about to land in quantal-proposed should not be copied out of there until the rest of the stack has been uploaded and built.
<RAOF> But no one would do that, anyway, because until that happens it'll be obvious that the archive won't be installable :)
<tkamppeter> Yesterday I discussed the CUPS SRU with infinity because the SRU has 5 of 6 bugs verified and the reporter of the remaining bug does not answer. The conclusion is what I have written in comment #79 of bug 973270. Infinity wanted to pass cups to -updates. He did not do so (forgotten?). Can someone pass the CUPS SRU to -updates?
<ubot2> Launchpad bug 973270 in cups "Printer does not provide REQUIRED job history." [High,Fix committed] https://launchpad.net/bugs/973270
<tkamppeter> seb128, are you in the release team?
<seb128> tkamppeter, no, why?
<tkamppeter> seb128, yesterday I have talked with infinity here about the CUPS SRU and he told me that he wanted to move it to -updates but he did not do so.
<tkamppeter> Anyone of the release team around here?
<tkamppeter> infinity, hi
<tkamppeter> cjwatson, hi
<cjwatson> I'm in a coffee shop today, can't do anything particularly complex
<cjwatson> In any case *please* don't send me contentless pings :)
<tkamppeter> cjwatson, yesterday I have talked with infinity here about the CUPS SRU and he told me that he wanted to move it to -updates but he did not do so.
<tkamppeter> cjwatson, can you move it to -updates?
<cjwatson> I'd rather leave that to infinity if he already has context - my net access here is very slow and it will be difficult to go through bugs.  infinity said "I'll look into it more", not "I'll do it".
<cjwatson> So I don't want to jump into the middle of that if he just got interrupted thinking about it.
<zul> can an archive admin please review python-django-compressor, python-django-appconf, and python-warlock it will make horizon installable again (and ill buy them a beer when I see them next)
<zul> they have been sitting in binary-new for a while
<cjwatson> zul: Why not licence debian/* under the same terms as the upstream source, which is recommended practice?
<zul> cjwatson: oh i wasnt aware of that, i can fix that up though
<cjwatson> python-django-compressor looks like it needs to mention the Apache 2.0 licence of rjsmin.py in debian/copyright to
<cjwatson> o
<cjwatson> zul: oh, and typo in debian/rules, "get-orig-soruce"
<skaet> cjwatson,  would you mind reviewing http://paste.ubuntu.com/1120535/?
<cjwatson> but that lot's minor, so accepting -django-compressor
<zul> cjwatson: ill fix that up in the next upload
<cjwatson> skaet: could I have a diff against the current crontab?
<skaet> cjwatson,  sure,  doing
<cjwatson> skaet: also, we should never be using ARCHES= in crontab
<cjwatson> it's hard to maintain and etc/default-arches should be sufficient
<skaet> cjwatson, http://paste.ubuntu.com/1121384/
<cjwatson> zul: for python-warlock using the same licence as upstream is even more important because Apache-2.0 and GPL-2 are incompatible
<zul> cjwatson:  do you want to reject it do i can update it?
<cjwatson> zul: it barely scrapes through as distributable because debian/* is GPL-2+, and Apache-2.0 and GPL-3 are compatible - but still, better to keep it simple
<cjwatson> so this isn't a reject, but a licence change in -0ubuntu2 would be good, IMO
<zul> cjwatson: ack
<cjwatson> skaet: sorry, I should have said - diff -u is basically always lots easier to read than plain diff
<cjwatson> old-style diffs are there for compatibility but they're awful :)
<skaet> cjwatson,  no worries,  here you go: http://paste.ubuntu.com/1121396/
<cjwatson> skaet: as far as I can make out, the ARCHES= bits there are equivalent to http://paste.ubuntu.com/1121399/ in etc/default-arches
<cjwatson> I think people have said that changing default-arches is a bit awkward because we can't easily see the state at release, but hey, it's in bzr
<cjwatson> and then drop the ARCHES= throughout and it should be a more readable diff
<cjwatson> "buildlive kubuntu dvd precise" needs to be "buildlive kubuntu-dvd dvd precise" so that it puts the right bits in the squashfs
<skaet> cjwatson,   sorry,   didn't make the changes between the two version,  just did the diff -u,  I'll work on adding the ARCHES to the defaults,  just wanted to see if there was something else that needed fixing...  (which there appears to be ;) )
<cjwatson> right.  I think the diff I pasted should be fine for that
<cjwatson> I don't see any other problems :)
<cjwatson> coo, xorriso supports mac/efi hybrids now
<cjwatson> I wonder if I can get us onto that for quantal
<skaet> cjwatson,  the changes to etc/default-arches matches expectations.    ARCHES pulled, kubuntu-dvd added.   http://paste.ubuntu.com/1121414/
<cjwatson> skaet: great.  looks good to me now.
<cjwatson> shall I just commit my default-arches changes directly since I have them here?
<skaet> thanks cjwatson,   yes,  please commit your default-arches,  will save me recreating it.
<skaet> I'll upload after you finish
<cjwatson> skaet: done
<skaet> cjwatson,  new  version committed and pushed,  now at 1475
<cjwatson> skaet: cool, pulled.  do you know why the mythbuntu quantal daily build is commented out in the live crontab but not in bzr?
<ogra_> just fyi, i just changed the boot code for omap/omap4 in debian-cd and run a server testbuild now
<ogra_> ah, done already, that was faster than i thought, ignore the noise :)
<skaet> cjwatson,  hmm,  oversite from A3.   They aren't participating the milestones,  but daily should be turned back on.   (not releasing with 12.10, but participating in 12.04.1)
<cjwatson> OK, odd that live and bzr were ever allowed to get out of sync though, even so
<cjwatson> maybe it would be simpler to arrange for mythbuntu dailies not to be posted to the tracker for quantal, so that we can leave the dailies enabled and not worry about them?
<stgraber> I don't know the details but maybe they want the dailies to post to the daily milestone on the tracker, but not to any "real" milestone
<cjwatson> mm, trickier because cdimage doesn't know the current milestone (it lets u-a-t worry about that)
<cjwatson> ah well, not important for now
<dpm> hi, is there anyone from the SRU team who can sponsor jbicha's ubuntu-docs upload to precise-proposed? We need this upload to be able to prepare the language packs for 12.04.1, and any help would be appreciated. Here's the associated bug
<dpm> bug 1019441
<ubot2> Launchpad bug 1019441 in ubuntu-translations "Please update the ubuntu-docs Precise package with translations for 12.04.1" [High,Triaged] https://launchpad.net/bugs/1019441
<stgraber> dpm: why do you need someone from the SRU team to sponsor an upload?
<dpm> stgraber, I'm not familiar with the process, so if it's not the SRU team, then whoever who can sponsor the upload would do :)
<stgraber> dpm: yeah, anyone with upload rights can do it. I'm taking a quick look now
<dpm> excellent, thanks stgraber!
<stgraber> dpm: failed to build locally but might be a problem with my environment, pushing to a PPA for test build, if that works I'll push to quantal + precise-proposed
<dpm> stgraber, thanks. Would you mind keeping me up to date on how it goes? Once ubuntu-docs is in precise-proposed, I'd like to start building the language packs tomorrow, so that they can be ready by the 2nd.
<stgraber> dpm: well, you'll need an SRU team member to approve it to -proposed before that, the queue for that is almost 30 packages long last I checked, so might need some direct poking to get it processed before the others
<dpm> ok, gotcha
<tkamppeter> infinity, hi
<jdstrand> fyi, I'm dealing with the kde component mismatches
<babyface_> jamespage, hi James
<babyface_> jamespage, for bug:https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1028453,  it failed the test job in jenkins many days, when will it be fixed?
<ubot2> Ubuntu bug 1028453 in ubuntu-meta "Quantal Ubuntu Server minimal install oversized" [High,Confirmed]
<infinity> tkamppeter: Relax, man. ;)
<babyface_> anybody know why there are no builds for  quantal desktop ?
<stgraber> let me check
<babyface_> stgraber,  ok thanks.
<stgraber> cron job is there, so it might be that it failed, checking the logs
<infinity> livefs builds went fine.
<stgraber> yeah, livefs looks good but debian-cd never ran
<stgraber> at least, I don't see a daily-live log for 20120731
<infinity> well, Colin and Oli were both fiddling with debian-cd yesterday.
<infinity> Or today, or whatever.
<stgraber> ok, I'll try to re-run just the debian-cd part of the build, see what happens...
<stgraber> running
<babyface_> thanks guys.  normallyï¼ how long will it take to finish the build ï¼
<stgraber> should just be a few minutes as I'm not rebuilding the livefs, just the .iso
<babyface_> stgraber, ack. thanks.
<infinity> stgraber: The complete lack of logfile at all is a bit weird.
<infinity> stgraber: And the reason is because buildlive is still running. :P
<infinity> 21663 ?        S      0:00 ssh -n -o StrictHostKeyChecking no -o BatchMode yes buildd@royal.buildd /home/buildd/bin/BuildLiveCD -l -A powerpc -d quantal lubuntu
<stgraber> that's lubuntu
<infinity> Oh, so it is.
<infinity> Mentally filtered the 'l'
<stgraber> hehe :)
<infinity> But... No logfile seems nearly impossible to manage, with the set of files that have been edited recently.
<infinity> Maybe I'm missing an interim edit where someone briefly broke the world at just the wrong time.
 * infinity shrugs.
<stgraber> the only logical explenation would be a messed up crontab at the time the build started, anything else should have sent a failure e-mail (either debian-cd or cron)
<stgraber> hmm, though MAILTO isn't set in the crontab, so I'm not exactly sure who would be notified of a failure (that's not handled by one of the other e-mail)
<infinity> It would be in ubuntu-archive's spool.
<infinity> Err, in cdimage's.
<stgraber> which appears to be empty... odd
<infinity> It's not empty.
<infinity> But it certainly has no failure mails after the livefs build.
<stgraber> oh, is "mail" lying to me (or it's just me not remembering how that stuff works ;))
<infinity> Oh, wait.
<infinity> I didn't scroll far enough up. :P
<infinity> lockfile: Sorry, giving up on "/srv/cdimage.ubuntu.com/etc/.lock-build-image-set-ubuntu-daily-live"
<infinity> Another image set is already building!
<skaet> ?
<infinity> So, stale lock from someone fiddling, I assume.
<infinity> Mystery solved.
<stgraber> oh, fun, apparently "mail -u cdimage" isn't the same as "mail"... go figure
<infinity> I just read the spool raw with 'less'.
<stgraber> that works too ;)
<jbicha> hi, could an AA handle bug 1031416 for me?
<ubot2> Launchpad bug 1031416 in ubuntu "Please remove mess from the blacklist & sync mess 0.146-2 (multiverse) from Debian non-free" [Wishlist,Confirmed] https://launchpad.net/bugs/1031416
<stgraber> babyface_: built
<babyface_> stgraber, got it. thanks.
<infinity> jbicha: Will do.
<jbicha> infinity: thank you
<skaet> stgraber, infinity - have synched the crontab up with the version in cdimage/etc/crontab that contains the precise daily builds now.
<infinity> Hrm?
<infinity> precise daily builds were already running.
<infinity> Or, so my mail told me.
<skaet> infinity,  not for all the images on the manifest for 12.04.1
<skaet> and some of the archs that were showing up on the precise dailies  weren't needed either, and just consuming arm/powerpc cycles for no reason.
<skaet> cjwatson made some changes to the default-arches file earlier as well, as part of this.
 * infinity sees that.
<skaet> so,  it should all nicely match the 12.04.1 manifest now.
 * stgraber prepares for the easiest MIR ever, zram-config
<stgraber> infinity: hmm, did you notice all the install failure bugs against zram-config?
<infinity> stgraber: Erm.  I don't even understand how it's possible that people upgrading from oneiric are upgrading zram-config, when it didn't exist previously...
<infinity> stgraber: Probably doesn't help that some of them are mix-and-matching it with some random PPA package.
<ogra_> why does it suddenly show up on main images and needs a MIR ?
<infinity> ogra_: It's not being pulled in by anything...
<infinity> stgraber: Why is it being MIRed?
<stgraber> ogra_,infinity: I want to depend on it from ltsp-client
<ogra_> right, the only image actually using it is ac100
<ogra_> stgraber, ah !
<stgraber> ogra_: we discussed it at the LTSP session at UDS, we killed the compcache code a while back but never replaced that by the zram equivalent
<infinity> stgraber: Well, I have a mail from the "random PPA zram package" guy about trying to consolidate them.
<infinity> stgraber: But I think both should go away, and we should fix the zram bits in initramfs-tools (which I didn't know existed when I did zram-config)
<stgraber> that'd work too
<ogra_> oh, i remember
<stgraber> at least until we try to get rid of the initramfs ;)
<stgraber> (which isn't likely to ever happen for LTSP considering how much stuff we do in the initramfs ;))
<infinity> Well, I could pull it out of initramfs and turn it into a hybrid hook.
<infinity> (ie: something that runs from either initramfs or the base system, but not both)
<infinity> I dunno.  I haven't put much thought into it, since it "just works" for me.
<infinity> The problems for people with conflicting packages are obvious, but some of the bug reports don't seem to fall into that category, so a bit of investigation here might be worthwhile.
<stgraber> yeah, it also "just works" here and I'm pretty sure it'll also just work for LTSP without causing extra bug reports as it's a pretty well controlled environment (auto generated chroot that people usually don't mess with)
<infinity> Does ltsp rely on tmpfses in any meaningful way?
<stgraber> yeah
<infinity> I might have hit a curious kernel bug here where swapping a tmpfs to zram causes explosions.
<stgraber> as in, we don't have persistent storage and use tmpfs for everything ;)
<infinity> I need to figure out a solid reproducer so I can debug and lay blame.
<infinity> But if what I suspect is happening is happening, that could be a bit of a blocker for you.
<stgraber> yeah, I can see some people finding this annoying ;)
<stgraber> so far I've been mostly using zram on my swap-less systems which tend to have a lot of RAM and not using much tmpfs, thin clients are kind of the opposite of that, so booting a 64MB thin client might be interesting ;)
<infinity> Yeah.  I have a ton of RAM, but I eat it all for tmpfs builds.
<infinity> And I can't be positive without a controlled test case, but I *think* my oopses and panics are hitting at around the point where the tmpfs would be swapping.
<infinity> Which would be when the kernel then tries to free some RAM for zram, so it can swap the tmpfs.
<infinity> Whch all should work, in theory, but...
<infinity> So many moving parts.
<infinity> Maybe I can boot with MEM=$something_small and try to get a solid reproducer.
<infinity> But that sounds like something I don't want to do today. :P
<jbicha> aw, android-tools looked kinda useful
<infinity> https://bugs.launchpad.net/ubuntu/+source/zram-config/+bug/956859 is weird too.
<ubot2> Ubuntu bug 956859 in zram-config "zram-config terminates with status 2. zram swaps not enabled" [Undecided,Confirmed]
<infinity> Waitaminute.
<infinity> stgraber: I wonder if some/many of the upgrade bugs are due to people loading the zram module manually, perhaps in something like /etc/modules.
<infinity> stgraber: Would explain the "using defaults" sort of message in the above bug.
<stgraber> yeah, so I guess you may want to check for zram being already loaded in pre-start and "echo 'something vaguely useful' && stop" if that's the case
<stgraber> should be better than failing
<infinity> Hrm.
<infinity> Also could be people without /usr mounted?
<infinity> (I use free(1) in the init job, which is in /usr/bin)
<infinity> But... Runlevel [2345] should guarantee /usr, surely.
<infinity> Meh.  Anyhow, I should look at the PPA package, consolidate any good ideas he has, and add a Conflict to the package, at least.
<ScottK> Publisher broken?
<ScottK> Installation-guide has been pending for an hour.
<ScottK> There it is.
<infinity> ScottK: It's running.  Could have just been a slow run.
<ScottK> Asking must have been the fix.
<ScottK> OK.
<ScottK> Very slow.
<ScottK> Thanks for checking.
 * ScottK was waiting for that because he's wanting to figure out how much of the K* stuff coming back into Main is real.
<slangasek> I'm very puzzled by https://launchpad.net/ubuntu/+source/installation-guide/20100518ubuntu6
<slangasek> published in precise in April; published in quantal 2 minutes ago?
<slangasek> infinity: yes, runlevel [2345] guarantees /usr; and quantal forward, "out of the initramfs" will also guarantee it
<ScottK> It got demoted and repromoted
<slangasek> ah, ok
<ScottK> No idea why that happened, but C-M got very noisy and some of it seems related.
<micahg> I think jdstrand was trying to demote that
<jdstrand> I mentioned earlier I was working on that
<jdstrand> I had to bail because of poxml in kdesdk. I filed a bug on it
<ScottK> What bug?
<micahg> jdstrand: why should installation-guide make a difference, it has no reverse dependencies
<ScottK> micahg: Isn't it used in D-I?
<micahg> oh, is it?
<jdstrand> micahg: it is seeded in platform.quantal/supported-installer-common
<micahg> hrm, /me kicks seeded-in-ubuntu
<ScottK> Even better, fix it.
<jdstrand> I didn't notice that myself and thought I was ok, then saw the report and put everything back until bug #1031478 can be fixed
<ubot2> Launchpad bug 1031478 in installation-guide "Drop Build-Depends on poxml" [Wishlist,Triaged] https://launchpad.net/bugs/1031478
<micahg> ScottK: I fear the issue is server side
<jdstrand> not to worry, I will put it all back
<ScottK> micahg: Face your fear and step into it.
<ScottK> jdstrand: Thanks.  I'll ignore C-M for awhile then.
<jdstrand> I thought about just removing the seed entry, but then thought about the network-less installs
<micahg> ScottK: I'd rather have someone else fix it now rather than waiting on me for a month
<micahg> tumbleweed: ^^ can you have a look at seeded-in-ubuntu not showing stuff in supported-installer-common?
<tumbleweed> sure. That sounds like something I just need to tell it to look at
<micahg> jdstrand: alternatively, if poxml doesn't have interdependencies on the rest of kdesdk, it could be packaged separately (might be acceptable to Debian as well)
<ScottK> micahg: It's part of KDE.
<ScottK> It won't be acceptable to split the source in Debian, I can guarantee you.
<micahg> ScottK: right, but it's a tool usable outside of KDE as well
<ScottK> micahg: Yes.  So is everything that's not part of the libs/workspace.
<micahg> ah, the binary is already usable without the bulk of stuff, so it's just a main/universe issue which needs to go away, nevermind :)
<ScottK> It's a separate binary package, so from a Debian perspective there's zero incentive to split the source and it's a maintenance burden.
<ScottK> Yeah.
<ScottK> slangasek: So are you the partner repo dude now or just the guy that didn't duck fast enough when Skype needed doing?
<slangasek> ScottK: I'm "the partner repo dude", and I'm also still trying to find a patsy for skype ;)
<skaet> ogra_,  http://paste.ubuntu.com/1122227/  <-- this address the concern you raised last month?
<skaet> slangasek, infinity,  also in that diff is updating the make-web-indices to indicate that mythbuntu and ubuntustudio were approved for LTS.
<slangasek> skaet: the latter makes sense to me.  the former I'll let ogra_ speak on
<skaet> slangasek,  thanks.
<ogra_> skaet, yeah, looks fine to me
<skaet> thanks ogra_.
<ogra_> your dev machine is actually called ubuntu ? :)
<tumbleweed> micahg: to make it appear, it looks like we need to parse a lot more of germinate-output. It's currently only looking at the supported seed's file. Not its dependency tree (I'm not at all familiar with germinate)
<micahg> tumbleweed: hrm, no idea here
<skaet> ogra_  just doing this on one of my test machines, since it was handy. :)
<ogra_> heh
 * ogra_ is finally done soldering our magic USB cables to autoboot the pandas
<ogra_> phew
#ubuntu-release 2012-08-01
<jbicha> stgraber: ubuntu-docs should build on precise now
<jbicha> sorry for the delay
<stgraber> jbicha: ok, looking now
<stgraber> jbicha: uploaded
<jbicha> looks around for an SRU team member to accept ubuntu-docs
<ScottK> bdmurray: "sru-release: comment on bugs when releasing packages to -updates and unsubscribe the SRU team from those bugs" <-- don't we want to be subscribed in case of regression comments?
<ScottK> jbicha: I'll look.
<jbicha> ScottK: thanks
<ScottK> jbicha: Needs the bug foo in https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template before it can be accepted.
<ScottK> Need to have some way of knowing if it passes muster.
<jbicha> aw, I hoped I could slide one by :|
<ScottK> I'd suggest the test case is verifying selected updates are present.  Just to make sure the right thing got uploaded. You could give a couple of examples.
<ScottK> jbicha: I went ahead and accepted based on you'll fix the bug.  Please don't let me down.
<jbicha> I'm working on it, language packs have their own separate validation process though
<ScottK> Sure, but we still have to have something.
<ScottK> OK.  I think that's enough damage to the SRU queue for one night.
<ScottK> Whoever's doing stuff with the queue, it'd be nice to get the python2.7 SRU accepted...
<ScottK> Easy diff , test case, and everything.
<infinity> ScottK: I admit nothing.
<ScottK> infinity: Thanks for nothing then.
<infinity> ScottK: ;)
<stgraber> hmm, who accepted lxc into -proposed?
<stgraber> 0.7.5-3ubuntu61 should have been copied to -updates with sysvinit before letting 0.7.5-3ubuntu62 in...
<stgraber> as it now reset the testing period of lxc and so when sysvinit will be copied (in 2 days), it's going to break lxc for all precise users
<stgraber> though the fix in 0.7.5-3ubuntu62 is quite trivial, so I guess the regression testing period for that one can be shorten and both sysvinit and lxc still be released at the same time
<ScottK> stgraber: It was me.  If you don't want something accepted, I guess I don't know why you uploaded it.
<stgraber> I didn't upload it
<stgraber> I uploaded 0.7.5-3ubuntu61
<ScottK> I see.  Who uploaded that?
<ScottK> (62)
<stgraber> probably hallyn
<ScottK> IIRC that's correct, now that you mention it.
<ScottK> hallyn: I guess my comment should have been directed at you.  If there's an existing package in -proposed and you upload a new one, that should probably mean you want the existing SRU replaced.
<stgraber> the new upload also didn't use -v so the bug list for the package on pending-sru is also wrong (doesn't list bug 974584). I'll make sure to manually track the lxc SRU and nag whoever's on duty when sysvinit reaches 7 days and both should be copied
<ubot2> Launchpad bug 974584 in sysvinit "Semaphores cannot be created in lxc container" [High,Fix committed] https://launchpad.net/bugs/974584
<stgraber> I'm testing 0.7.5-3ubuntu62 now to make sure it actually works as expected
<stgraber> ScottK: I commented in bug 974584, so hopefully whoever is on SRU duty will notice and copy both. In theory that should be during bdmurray's shift so I should be around.
<ubot2> Launchpad bug 974584 in sysvinit "Semaphores cannot be created in lxc container" [High,Fix committed] https://launchpad.net/bugs/974584
<ScottK> Great.  Sorry for the confusion.
<bdrung> hi. vlc is in -proposed since one week without someone reporting a regression (lp: #1025713). is it time to get it into -security/-updates?
<cjwatson> brendand: http://people.canonical.com/~ubuntu-archive/pending-sru.html says (a) lots of bugs still verification-needed and (b) 7-day aging period not quite up
<cjwatson> er
<cjwatson> bdrung: ^-
<jdstrand> cjwatson: are you actively looking at installation-guide? I have an untested preliminary patch to use xml2po from gnome-doc-utils. I'm happy to let you do it, but I can also do it
<cjwatson> jdstrand: Yes, I've just uploaded a fix
<jdstrand> sweet, that'll save me some time
<jdstrand> cjwatson: thanks!
<cjwatson> jdstrand: It didn't actually need poxml at all really since we don't ship any translations
<jdstrand> even better
<cjwatson> Which has been vaguely on my to-do list since warty and therefore will probably never happen ;-)
<jdstrand> hehe
<cjwatson> Sorry to steal the bug but I needed to update i-g anyway :)
<jdstrand> cjwatson: no, that is totally fine. I only spent about 20 minutes on it last night
<bdrung> cjwatson: VLC has a preliminary MRE
 * cjwatson has no context except what's on the web page :)
<cjwatson> (internet-poor at the moment)
<bdmurray> ScottK: regarding sru-release that is what was discussed in the sru team call and the comment includes information regarding reporting a new bug and tagging it regression-updates a tag to which SRU team members can or are subscribed
<ScottK> bdmurray: OK.  Thanks.
<balloons> do we normally only retain the last milestone images?
<balloons> I mean to say, I can't download alpha one from quantal using http://cdimage.ubuntu.com/releases/quantal/
<balloons> only alpha 3 is listed
<slangasek> balloons: correct
<slangasek> the images still exist, but aren't on the website anymore
<balloons> slangasek, interesting..it would just be a link right?
<slangasek> how do you mean?
<slangasek> the images are not on the server that provides the website
<slangasek> they get archived off
<balloons> ahh..
<balloons> ok, so if I wanted to see if we regressed on an issue from alpha2 -> alpha 3, what do I do?
<slangasek> good question
<slangasek> so this is ringing bells with me, that there was some previous discussion about keeping the milestone images around longer
<slangasek> but I don't remember who I had that conversation with and what the outcome was
<ogra_> we should keep them public until release really
<slangasek> we never have because of space considerations on the webservers
<ogra_> yep, i understand the tech reason :) just saying
<balloons> :-) yes, space is a concern
<balloons> but I think the milestones are worth keeping about.. at least during the dev cycle of the current release
<ogra_> though iirc rick suggested in the "no more freezes" thread that we should actually keep all daily images around in that scenario ...
<slangasek> balloons: yes, we did not have room to do that at all
<slangasek> I don't know if we have room now
<ogra_> so there should at least be more HW in the pipe for providing such a setup
<slangasek> pgraner: was it you that was asking about keeping multiple milestone images around during the devel cycle?
<slangasek> whatever discussion we had about this didn't translate to an update on the milestone process
<balloons> Well, I think we could possibly get some help for hosting if needed..
<balloons> slangasek, atm, if I wanted an alpha 2 image, does it exist anywhere?
<slangasek> it exists but isn't somewhere you can get to it
<slangasek> I can cheat and repost it temporarily to cdimage.u.c, I think
<slangasek> balloons: http://cdimage.ubuntu.com/releases/quantal/alpha-2/ shortly
<Daviey> s3 storage would be perfect for this :)
<balloons> slangasek, if we had a mirror willing to host, could we provide official gpg and md5's for the images and link out to the mirror do you think?
<balloons> slangasek, :-) ty
<skaet> slangasek,  Laney and I talked about leaving A2
<slangasek> skaet: well, I didn't get the memo ;)
<jdstrand> fyi, I'm back to tending to kde in component-mismatches
<skaet> slangasek,   if space permits,  I'm +1 on keeping all the milestones up and accessible during the cycle.   We do need to change the checklists on the subject though ;)
<ogra_> at least we should keep $current_milestone-1
<ogra_> not sure having A1 around makes sense if we are at A3 already
<skaet> ogra_   thought we were going to keep $current_milestone-1 around, but it appears glitch happened.   in terms  older ones - possibly useful to narrow down when a bug may bug may have been introduced, but am not fussed if we don't either.
<ogra_> yeah
<balloons> I'm not sure how the no alpha's or milestones discussion goes with this, but having those points in time to help pinpoint issues is useful. In this case, I want to check out alpha 2
<balloons> ogra_ I'm sure can speak to it.. pinning down things like kernel regressions it's helpful to have old versions around to see when the regression started for testing :-)
<ogra_> balloons, indeed, but yu wont have the iterations between the milestones around anyway and A1 is traditionally pretty crappy
<ogra_> ("just good enough to have the installer work" usually)
<skaet> ogra_,   traditions have been changing...   your ARM bias is showing   ;)
<ogra_> nah, has nothing to do with arm but with achievability without losing actual development time
<balloons> :-) I want all the milestones, to help ensure we given the community the tools needed to help us test; specifically when we have regressions. It is very often the case people encounter problems with a specific milestone that didn't previously exist, but without the images it's harder to verify and pin that down..
<ogra_> it usually takes the time before A1 to actually even make the bits installable and get the installer in initial shape for a new release
<balloons> obviously automagically iterating through daily images for regression testing would be amazing.. heh, we should start somewhere
<ogra_> there is no time to make it shiny at that point of the cycle
<ogra_> if you want it better, A1 should be released at A2 time
<ogra_> ro we should double up the amount of developers :)
<ogra_> *or
<balloons> ogra_, lol, double devs.. that would make it take until alpha 3!
 * skaet just updated https://wiki.ubuntu.com/MilestoneProcess checklist to make it explicit to keep prior milestone around. 
<balloons> thanks everyone!
#ubuntu-release 2012-08-02
<jdstrand> cjwatson: hi! can you help explain something with http://people.canonical.com/~ubuntu-archive/component-mismatches.txt? so, 'kate' is rescuing kate-dbg even though I put kate in universe. kate is seeded, but it is in kubuntu (according to platform.quantal, ubuntu.quantal and kubuntu.quantal)
<jdstrand> cjwatson: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.quantal/rdepends/ALL/kate simply says 'Extra seed'
<infinity> jdstrand: You left the source in main for some reason?
<jdstrand> cjwatson: I can say that a newer kate was uploaded and then I changed the override before it was built, but change-override still overrode the binaries that were already built
<jdstrand> infinity: the source needs to be in main for katepart. I am trying to demote kate the binary so I can demote kde-runtime
<jdstrand> but kate doesn't pull in kde-runtime during the build and certainly shouldn't pull in kate-dbg
<infinity> jdstrand: -dbg rescuing comes from source packages, I suspect.
<jdstrand> infinity: that seems... odd since the source package would have to depend on itself, no?
<infinity> jdstrand: Eh?
<jdstrand> I mean, the build of the kate source package produces kate-dbg (which I am also trying to demote)
<infinity> Yes, the build of the source package produces the dbg, and the source package is in main, hence the debug wants to be in main.
<infinity> Since the dbg generally (and definitely in this case) contains debug symbols for stuff in main.
<jdstrand> that would explain what is happening, but is that valid?
<infinity> More importantly, why does katepart need to be in main at all?
<jdstrand> if a normal non-dbg package is in universe, it can depend on stuff in main
<jdstrand> infinity: well, unravelling kde dependencies has proved... difficult
<jdstrand> iirc, it is needed by something that is needed by kdelibs5
<jdstrand> so I was doing baby steps
<infinity> You mean kdelibs5-plugins, not kdelibs5
<jdstrand> which actually ended up being pre-teen steps
<infinity> And it's libkhtml5 and libkio5 pulling in the plugins.
<infinity> As recommends.
<infinity> That could be fixed.
<jdstrand> infinity: well, what I mean is that the farther back I went the harder it became
<jdstrand> that's fine, and I will probably try to do that
<infinity> I suspect dropping both those recommends to suggests would fix it all.
<jdstrand> *but*, shouldn't a dbg package be demotable when its corresponding source is in main?
<infinity> Maybe.
<jdstrand> that seems reasonable to me-- but I feel I may lack a deeper understanding
<infinity> Well, in my world, -dbg packages shouldn't exist, but that's not going to happen. :P
<jdstrand> heh
<infinity> If they do exist, though, you do kinda expect your debug symbols to be available in the same component.
<infinity> And if you want the debug symbols for katepart, you need kate-dbg.
<jdstrand> I would say you would expect them to be in a component that must also be installed
<jdstrand> a >= as opposed to a =
<infinity> Erm.  Come again?
<infinity> What component "must also be installed" with main?
<jdstrand> source in universe and dbg in main, no. source in main dbg in universe, ok
<infinity> There's main.  And, uhm.  Main.
<infinity> Honestly, splitting binaries across main/universe is ridiculous anyway, and I can't wait for archive reorg to finish.
<jdstrand> you can't run a system with only universe enabled
<infinity> jdstrand: This has nothing to do with universe, katepart is in main.
<infinity> jdstrand: Therefor, katepart's debug symbols should be in main.
<infinity> jdstrand: katepart's debug symbols are in kate-dbg.
<jdstrand> ok, so you are saying that kate-dbg provides the symbols for kate *and* katepart. I was thinking only kate, which was demoted
<jdstrand> that makes more sense
<infinity> Yeah, it's debug symbols for the whole source package.
<jdstrand> *sigh*
<jdstrand> I'll have to look farther up the chain then
 * jdstrand fixes the mismatches for now
<jdstrand> cjwatson: nm
<jdstrand> infinity: thanks!
<infinity> Anyhow, dropping those Recommends to Suggests (on the plugins) would solve the issue, let kate fall out of main completely, and would have zero negative impact on kubuntu, since kde-runtime has a hard dep on kdelibs5-plugins anyway.
<jdstrand> infinity: fyi, seems the report should have said 'Rescued from katepart' rather than 'Rescued from kate', but, meh)
<infinity> jdstrand: No, cause it's rescued from the source package.
<infinity> jdstrand: It's a bit hard to decipher when the source produces a binary by that name, I suppose, but once you've seen it a few times, you know what's up.
<infinity> jdstrand: "rescued" are always a source->binary relationship.
<infinity> jdstrand: As in "this source is in main for other reasons, so we're pulling in its debug, docs, whatever"
<jdstrand> 'Rescued from kate:src'? anyhoo, not something I'm going fix and now that I know I don't need it fixed
 * jdstrand did not know "rescued" are always a source->binary relationship before now, but takes note
<jdstrand> infinity: again, thanks
<infinity> In almost all cases, it's doing the right thing.  In this weird corner case, I can see how an override of some sort might be nice, but...
<infinity> Dropping the Recommends is a bigger win anyway.
<infinity> So, let's eat some buildd time and just do that.
<infinity> It punts a bunch more k* stuff out of main.
<jdstrand> yes, I wanted to do that. I got a ton of stuff out yesterday due to an unneeded dep on poxml in the installation-guide
<infinity> Honestly, I think the only thing the main/universe split has had a positive effect on is teaching us what "recommends" *really* means.
<infinity> See libwebkit->gst* as another fine example.
<jdstrand> heh
<infinity> People using Recommends to pull in everything under the sun are generally wrong.
<infinity> And a library recommening plugins (which is the case with kde4libs here), is about as silly as python or perl recommending all their extensions.
<infinity> No point having plugins, if you tell people they always want them installed. :P
<jibel> Quantal Wubi images contains Precise since last Tuesday
<jibel> bug 1031961
<ubot2> Launchpad bug 1031961 in wubi "install LTS instead of Quantal starting from build 20120731.2" [Critical,Confirmed] https://launchpad.net/bugs/1031961
<infinity> jibel: As in, wubi.exe is downloading from a precise path, or it's downloading from a quantal path, but the rootfs is actually precise?
<jibel> infinity, it downloads the right image for Quantal eg http://cdimage.ubuntu.com/wubi/current/amd64.tar.xz but the content of the disk image is Precise
<infinity> Oh, hrm.
<infinity> I think I see the bit to blame.
<infinity> Actually, wait.  What's the path used for precise?
<jibel> infinity, there is none apparently. It should be http://cdimage.ubuntu.com/wubi/precise/ isn't it ?
<infinity> It probably should be, yes.  That's the problem. :P
<infinity> Looking into it.
<infinity> jibel: Should be fixed now.  I think I'll spin a precise and a quantal wubi to make sure.
<infinity> jibel: Will you be around to quickly verify both quantal and precise are sane for me later?
<infinity> jibel: (Well, precise might fail due to the subirectory, actually, if precise's wubi.exe doesn't know to look there... But you can at least verify for me that quantal is still quantal after I do a precise build)
<jibel> infinity, I can check the content of the images, but cannot install with wubi. I'm in a sprint and don't have any windows machine with me.
<jibel> infinity, but let me know when I can do the verification, I'll try to find a victim.
<infinity> jibel: current/ should be quantal again.
<jibel> infinity, ack
<infinity> jibel: precise is re-spinning, and should, I hope, land in wubi/precise/current instead. :P
<ScottK> jdstrand: Was polkit-kde-1 on the list of packages you were messing with (It's in c-m again)?
<jdstrand> ScottK: it was, and I am still poking at fixing this stuff
<ScottK> OK.  I'll leave it be then.
<jdstrand> yikes, the new kde upload undid a lot of my work
<jdstrand> well, I'll try to sort it
<infinity> Oh, FFS, the world is uninstallable due to a libexttextcat SOVER transition that breaks due to a -data package dependency.
<infinity> And by "the world", I mean libreoffice.
<ScottK> jdstrand: I'd suggest coordinating with Riddell  on it (I'm focused on a precise point release ATM).
<jdstrand> I'm trying to do non-invasive stuff with no impact
<Riddell> what what?
<jdstrand> I will most certainly do so if I am doing crazy stuff
<jdstrand> Riddell: I've been fiddling with overrides is all
<jdstrand> if I can't manage non-intrusive changes, I'll put stuff back
<skaet> ev, ping?
<skaet> Riddell,   can you check that the Kubuntu images for Precise 12.04.1 are the expected ones showing up on the iso tracker now?
 * Riddell looks
<Riddell> skaet: yes I agree
<skaet> Thanks Riddell,    will you be testing contact point this time around?
<Riddell> skaet: yep can do
<skaet> Riddell, coolio.   :)     When can we get a preliminary testing pass set of results to confirm no "egg on face" type of issues have cropped up with them?    Don't want to be respinning after final freeze, if at all possible.
<infinity> Feh, so I guess I'm going to upload a new libreoffice.
<infinity> At least I have the bandwidth for it.
<infinity> But do I test build first or not.  Hrm.
<Riddell> skaet: when are you wanting them?  is there an expected release day?
<tseliot> can anybody reject cedarview-drm-drivers (in precise-proposed) please?
<smartboyhw> How to?
<tseliot> only if you're an archive admin ;)
<smartboyhw> No, I
<smartboyhw> am not
<skaet> Riddell,  initial set of test runs to make sure no surprises in the manditory tests this next week would be good, as well as checking/updates to images size.   Final freeze (and ideally last set of images will be on  8/16,   release on 8/23)
<smartboyhw> I am responsible for QA...
<infinity> tseliot: With pleasure.
<tseliot> infinity: thanks
<infinity> tseliot: What did you break this time? :P
<tseliot> infinity: there was a leftover which prevented the package from calling update-grub-gfxpayload. Nothing fancy, really ;)
<Riddell> skaet: oh no rush then, shouldn't be a problem
<infinity> tseliot: Kay.  Also, -vaapi-driver didn't get uploaded to match the new snapshot of drm and graphics.  Is that an issue?
<tseliot> infinity: let me check with janimo
<infinity> tseliot: https://launchpad.net/ubuntu/precise/+queue?queue_state=0 to see the current state of affairs.
<tseliot> infinity: janimo says there were no changes for the vaapi package
<infinity> jibel: Hrm, I'm undecided if those builds should go in /wubi/precise or /precise/wubi.  They're in the latter for now, though.
<janimo> infinity, I had no idea there was an old cedarview-graphics package in NEW too
<infinity> janimo: Well, there isn't anymore. ;)
<janimo> infinity, otoh the vaapi package is that one from june
<tseliot> infinity: I've just re-uploaded cedarview-drm-drivers
<janimo> infinity, I wish there was no graphics there anymore :D
<infinity> janimo: Yes, hence why I asked, since all the other June snapshots got updated to a July one, but not poor vaapi.
<janimo> infinity, it is due to that not needing an update. Intel does not update all 3 components every drop
<jibel> infinity, depends if wubi is considered a flavor or a variant of Ubuntu
<janimo> so it is slightly more confusing but otherwise indep like other X/vaapi drivers
<infinity> jibel: My gut is variant, and that /precise/wubi is correct.
<infinity> jibel: Since it really is just an Ubuntu desktop filesystem and all.
 * ogra_ considers wubi an insanity 
<smartboyhw> I thought Wubi was great!
<infinity> jibel: Anyhow, I suspect that the precise-proposed wubi.exe has no clue how to find it, no matter where I put it, so that's fun. :P
<stgraber> infinity: /precise/wubi sounds good as it's technically part of the "ubuntu product" (same seeds and stuff as daily/daily-live/dvd/...)
<infinity> jibel: One bridge at a time, though.  At least it's not overwriting the quantal image. :P
<skaet> tseliot, cedarview-drm-drivers is a bit late,  hardware updates should have been uploaded couple of weeks ago.   What testing has been done?
<jibel> infinity, agree, and it's an improvement :)
<infinity> skaet: They've been uploaded repeatedly, and gone through a fair bit of NEW review.
<tseliot> skaet: yes, I applied the changes suggested by slangasek and re-uploaded
<skaet> infinity, tseliot - thanks.
<janimo> skaet, same with the other cedarview packages
<janimo> uploaded before July the 19th :)
<janimo> the testing was mostly done in HWE/OEM
<skaet> thanks janimo :)
<janimo> skaet, np :)
<infinity> Oh, crap, I didn't notice Sweetshark had targetted that libreoffice to quantal-proposed until just now. :/
<infinity> Which means we get to wait for all arches before I can unbreak x86.
<infinity> *sigh*
<infinity> I suspect that's less than ideal.  Maybe I should re-upload to -release.
<micahg> infinity: well, the issue is that libextttextcat should've gone to -proposed and not broken the world
<infinity> micahg: That's nice, but less helpful. :P
<micahg> infinity: maybe once x86 is finished, copy to -release and kill all the remaining -proposed builds
<infinity> It's only an hour in, which is about the turnaround I'd have for copying to -release anyway.
<micahg> infinity: right, but at least you'd have i386/amd64 not skewed
<infinity> micahg: Yeah, but I can get that by just reuploading.
<infinity> micahg: In the same amount of time.
<infinity> And without manual intervention.
<micahg> infinity: no guarantees on it
<infinity> micahg: No guarantees on what?
<micahg> arch synchronization between amd64/i386 w/out using proposed
<infinity> It doesn't matter, it's all uninstallable anyway.
<micahg> hrm, that's a good point
<micahg> infinity: I'd say go for it then :0
<slangasek> infinity: have you communicated to Sweetshark about what went wrong here, so that he knows for next time?
<infinity> slangasek: In which sense?  The mistargeting of the upload, or the uninstallability of the world?
<infinity> slangasek: The former wasn't something wrong, per se, I should have checked before I sponsored it, and the latter was the fault of whomever synced libexttextcat, not Sweetshark.
 * micahg brought up both issues in -desktop about 3 hours ago
<slangasek> infinity: "should have checked before sponsored it" - sure, and Sweetshark also should have prepared it for the correct target :)
<micahg> infinity: well, sweetshark promised that syncing libexttextcat wouldn't break anything :)
<infinity> slangasek: He already had it prepped for "an eventual upload to proposed", I don't think he was aware of the urgent need for a library transition until I brought it up. :P
<slangasek> k
<infinity> micahg: Ahh, I only saw that seb128 synced it, we need a better blame mechanism. ;)
<infinity> micahg: If it was on Sweetshark's say-so, I take it all back, blame the LibO maintainer! ;)
<micahg> hehe
<micahg> no, in the end, the responsibility is that of the uploader
<infinity> (That said, most people do seem to be blissfully unaware of the lib/-data breakages that occur on SONAME transitions, since they're so used to libraries normally being able to soft-transition)
<micahg> indeed, but I thought we had test infrastructure for this stuff :)
<infinity> It's a lesson you tend to only need to learn once, mind you.
<seb128> we have?
<micahg> seb128: couldn't the test lab be set up to test newer versions of dependencies?
<seb128> dunno
<seb128> you say we have, which is different from "coudn't ...3
<micahg> right, I keep mixing reality and fantasy for some reason :-/
<micahg> well, we have the infrastructure, it's just not configured to do it yet AIUI
<seb128> same difference, there is no easy way to check that
<stgraber> bdmurray: heya. sysvinit just reached 7 days in -proposed and as far as I'm concerned is good to go to -updates, when copying, please remember to pull lxc at the same time
<stgraber> bdmurray: lxc is marked as 1 day old as the SRU period was reset after another fix was added. Accepting sysvinit without lxc would break containers. The extra lxc fix is trivial and has been verified, so skipping the validation period is fine.
<slangasek> stgraber: are there appropriate Breaks: between the packages, so that the upgrade is guaranteed to happen in sync on the user's system too?
<stgraber> slangasek: nope and that wouldn't have worked in this case as the problem is when the old lxc debootstraps a container with the new sysvinit
<slangasek> ok
<bdrung> vlc is in -proposed since eight days without someone reporting a regression (lp: #1025713). is it time to get it into -security/-updates? Not all bugs are verified, but vlc has a preliminary MRE
<seb128> bdrung, MRE doesn't give you an exception of getting bugs verified
<seb128> bdrung, it just means the SRU will be accetped
<seb128> bdrung, once accepted it needs to follow the rules, all bugs need to be verified
<bdrung> seb128: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions says "For MRE packages only, it can generally be assumed that bugs claimed to be fixed have actually been fixed upstream, and it is not necessarily to manually independently verify them."
<bdrung> and "When the preceding steps have been done, the headline bug (only) should be marked verification-done "
<seb128> bdrung, hum, ok, that's not my experience, I guess the SRU team needs to coment
<slangasek> seb128, bdrung: actually, that's *exactly* what an MRE gives you...
<slangasek> you don't need per-bug verification if there's already been upstream validation - the latter being a prerequisite for an MRE
<slangasek> the problem is our process doesn't flag MRE packages in a useful way :)
<seb128> slangasek, hum ok, so SRU team has been pickier then should have with GNOME SRUs
<slangasek> seb128: perhaps it would help to reference the MRE in the bugs referenced in the SRU changelog
<seb128> slangasek, noted
<slangasek> stgraber: did jodh talk to you about having a fix for bug #980917 now?
<ubot2> Launchpad bug 980917 in upstart "Failed to create pty - disabling logging for job" [Medium,Triaged] https://launchpad.net/bugs/980917
<slangasek> stgraber, seb128: we're past the freeze deadline; would you want this upstart change to go into .1 still?
<stgraber> slangasek: yes, he did. He apparently got stuck in a UDD mess and was still trying to get something uploadable.
<slangasek> (personally, I'm not sure it's worth it... upstart has never worked well without an initramfs so it's not really a regression vs. 10.04, so I don't see a reason to bend the rules wrt the freeze)
<stgraber> slangasek: there's technically still 50min to go before the freeze, but I don't consider this critical to get in the point release as it's not affecting a (well) supported setup
<slangasek> stgraber: jodh is past EOD and the fix is still being iterated, I'm not going to rush this :)
<stgraber> so having it land in -proposed once it's unfrozen would be good enough for me
 * slangasek nods
<bdmurray> stgraber: is there anything special about resolvconf in -proposed?
<stgraber> bdmurray: nope. It was verification-failed and I made it verification-done a few minutes ago as the fix technically works, just not for all the cases I thought it'd
<ScottK> Is the "stable/release team" different than ubuntu-release?
<bdrung> skaet: are unseeded package affected by the 12.04.1 preparation?
<skaet> ScottK,  yes,  couple of members on stable release team that aren't in release team and visa versa.
<ScottK> OK.  Who are the stable release team?
<skaet> https://launchpad.net/~ubuntu-sru
<ScottK> OK.  Then the terminology threw me.
<skaet> bdrung,  we'll be trying to ratchet down the rate of change while we stabilize, so case by case for the unseeded packages.   Discuss in this channel with the SRU team if there's a compelling reason a fix can't wait.
<ScottK> skaet: Does having stuff in queue, but not accepted hurt anything?
<skaet> ScottK,  sorry,  probably should have added "Updates" in there, now that I'm looking at the definition.
<skaet> ScottK,  doesn't hurt in principle,  key is keeping the accepts down unless very good reason.
<ScottK> So I don't see why we should block uploads.
<slangasek> skaet: why would we care about the rate of change of unseeded packages? I would expect these to be processed as normal since they have no impact on the .1 images
<bdrung> skaet: i have nothing urgent. is it better to wait uploading stuff to -proposed or will it just be hold back until after the release of 12.04.1?
<slangasek> bdrung: please keep uploading
<bdrung> thanks
<bdrung> then i have to excuse to debug wxwidgets
<skaet> ScottK,  slangasek,  yes,  you're correct.
<micahg> skaet: just an FYI, I'll probably push the webkit from -proposed to -security/-updates on Monday
<stgraber> bdrung: wxwidges is seeded I believe, so yeah, upload what you want, but if it's seeded it won't be accepted into -proposed until we start building images from -updates
<skaet> micahg,  ok.  thanks for the head's up.
<micahg> umm, it just says Desktop Infrastructure Freeze on the interlock page, not seeded freeze...
<bdmurray> how does the freeze affect reviewing what's in the precise queue?
<bdrung> stgraber: right, it's seeded on kubuntu. wow, even vlc is seeded. i need to be careful.
<slangasek> bdmurray: I had understood that we're not supposed to accept seeded packages into precise-proposed unless they're targeted for .1 and discussed here first
<micahg> would be nice if seeded-in-ubuntu worked for LTS releases as well :)
<slangasek> however, if 'stable/release team' == ~ubuntu-sru, apparently we just talk to ourselves ;)
<ScottK> skaet and stgraber: I'd suggest making an exception for the mythtv SRU that's about to land.
<bdrung> micahg: why does seeded-in-ubuntu does not work for LTS?
<stgraber> ScottK: yeah, we have a bug for that, but it needs an MRE from the TB first (e-mail was sent to the list)
<micahg> bdrung: it only works for the dev release ATM AIUI
<bdmurray> slangasek: what about ones uploaded before the freeze?
<stgraber> bdmurray: anything uploaded before 21:00 UTC today should be processed as normal
<stgraber> bdmurray: anything uploaded after 21:00 UTC needs an exception
<bdmurray> okay great so slangasek will approve my update-manager tomorrow
<slangasek> or I could look at it now
<ScottK> bdrung: I don't think wx is really seeded.  It's in Universe so it can't be in a Kubuntu seed for precise.
<bdrung> ScottK: seeded-in-ubuntu wxwidgets2.8
<stgraber> ScottK: it's seeded in edubuntu
<bdrung> and ubuntustudio
<ScottK> bdrung: Clearly it's at least partially incorrect because it's not seeded in Kubuntu in precise.
<micahg> as I said, it's only for the dev release
<ScottK> It would be nice if one could specify what release to use for seeded-in-ubuntu.
<ScottK> OK.
<micahg> tumbleweed: ^^
 * bdrung pokes tumbleweed.
<micahg> anyways, it's only supported in kubuntu, so that's not on an image
<micahg> in quantal even that is
<micahg> awesome, binary NEW with no relevant changelog..../me wonders if it's that pocket bug (looks like it)
#ubuntu-release 2012-08-03
<tumbleweed> ScottK: that'll require a data format change, but yes, I see it would be useful
<ScottK> Thanks.
<cjwatson> SRU team folks will want to update ubuntu-archive-tools; this makes it so that you don't have to manually accept copies to -updates any more
<tumbleweed> would it be possible to have the sru copies into -updates show up in -changes with the original uploader?
<seb128> @SRU team: unity is verified, but 2 of the bugs have been set back from verification-done to verification-needed because software-center used the same bug references
<seb128> what's the standard way to deal with that? setting them back to -done would make unity green but screw s-c in a symmetric manner
<cjwatson> tumbleweed: probably - please file an LP bug
<tumbleweed> cjwatson: sure
<infinity> tumbleweed: Aww, but I like the inflated stats.
<infinity> seb128: Just talk to whomever's SRU day it is, and make them aware of the situation.
<infinity> (And yes, using tags, which aren't task-specific, for this is really annoying)
<seb128> slangasek, ^ it's your SRU day I think ;-)
<infinity> seb128: Oh, but it's Friday, we don't release on Fridays.
<infinity> seb128: So, remind me on Monday. :P
<seb128> you don't release on fridays? is that a new rule?
<infinity> Yeah, newish.
<seb128> I had the opposite discussion with slangasek a month ago
<infinity> I'm not sure slangasek believes in the "no one's around to fix it if you break it" theory.  But many of the rest of us appear to, and overruled him. :P
<seb128> when I said "can I get a review before thursday evening, I want that SRU out this week and would prefer avoid friday's landing" and he replied "why would friday be an issue for an SRU, they are supposed to be tested"
<infinity> Erm, a "review" implies it was going from unapproved->proposed?
<seb128> though maybe in my case it was a new SRU to be accepted in proposed
<seb128> not a move to -updates
<infinity> We do that, but not releases to -updates.
<seb128> ok
<seb128> slackers!
<seb128> ;-)
<infinity> You'll note it's the manager who ended up on the short shift. ;)
<infinity> Sneeeaky.
<cjwatson> Daviey: Any chance you could chase down bug 1002248?  The build failures are getting annoying
<ubot2> Launchpad bug 1002248 in mythbuntu-default-settings "[quantal] xfce4-utils is deprecated in 4.10" [Undecided,Fix committed] https://launchpad.net/bugs/1002248
<Daviey> cjwatson: wilco
<cjwatson> thanks
<cjwatson> In https://blueprints.launchpad.net/ubuntu/+spec/other-q-freeze-use-of-proposed I have a work item as follows: "ensure that builds to CURRENT/SUPPORTED distroseries get a build score bump over DEVELOPMENT/FROZEN DSes"
<cjwatson> Does anyone remember why this was?  I can see arguments either way, and in any event it's surprising that a spec about use of -proposed in the development series would be calling for the development series to be deprioritised
<cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-buildds-usage "Adjust the score for frozen series" was IIRC calling for the priorities of builds in frozen series to be raised
<cjwatson> Either way, I'm confused
<ScottK> Guessing, since I wasn't there, it seems reasonable that -proposed for the development release shouldn't have the same bump as for earlier release as I can't think of any reasons that are applicable.
<ScottK> For post-release propose, you want things built quickly since people run with -proposed and and you want to avoid breaking systems and it's the exact opposite for the development release.
<ScottK> For post-release you might have an urgent bug that needs to get built and out the door right away.  For the development release, if that was the case you probably wouldn't be in -proposed.
<tumbleweed> yeah, once everything goes into -proposed, stable's -proposed loses its slight advantage
<SpamapS> https://bugs.launchpad.net/ubuntu/precise/+source/php5/
<SpamapS> Can I get an ACK to go ahead and sponsor that debdiff in (for bug 1014044) for precise-proposed ?
<ubot2> Launchpad bug 1014044 in php5 "PHP5-FPM not reporting errors to web server (nginx)" [Medium,In progress] https://launchpad.net/bugs/1014044
<SpamapS> bug 1006738 is the more important fix
<ubot2> Launchpad bug 1006738 in php5 "php5-fpm segfaults with error 4 in libc-2.15.so" [High,In progress] https://launchpad.net/bugs/1006738
<stgraber> SpamapS: looking
<SpamapS> both really straight forward patches
<stgraber> the second bug is missing the usual rationale/testcase/regression potential
<stgraber> also, are these affecting default installs? (the main criteria for something to be considered for 12.04.1)
<ScottK> For server it's part of the lamp task.
<ScottK> So it could be default install.
<ScottK> Depends on exactly what you mean by default.
<SpamapS> php5-fpm is not part of that task IIRC
<SpamapS> Its sort of "the new way" that people are running php
<ScottK> Oh.
<stgraber> and the first one seems to be nginx specific (based on the title)
<SpamapS> its not
<SpamapS> any webserver using php5-fpm for fastcgi serving of php will suffer
<SpamapS> As far as the test case/reg potential for the segfault.. I'm working on extracting that from the upstream bug report
<babyface_> jamespage,  precise-server-ec2-daily are failing .  http://10.98.0.1:8080/view/Precise/view/ISO%20Testing/job/precise-server-ec2-daily/168/
<slangasek> infinity: I didn't think I was actually being all that subtle about it ;)
<slangasek> seb128: but yeah, as infinity says, we'll publish SRUs to -proposed on friday but not release them to -updates
<seb128> slangasek, ok, makes sense
<dpm> hi all, I've uploaded the language packs for the upcoming 12.04.1 release, which are now in the unapproved queue. Generally pitti takes care of approving them, but he's away. Could someone help me approving them so that they land in precise-proposed? https://launchpad.net/ubuntu/precise/+queue?queue_state=1
<stgraber> ^ as been approved as an exception, so please review even if it was uploaded after the deadline
<stgraber> *has
<dpm> stgraber, sorry, I just jumped into the channel, are you referring to the langpacks, or something else?
<stgraber> dpm: yeah, that comment was for the langpacks so the SRU team knows that they should review it even if it was uploaded after 21:00 UTC yesterday
<dpm> anyone around to do the langpacks review?
<stgraber> slangasek: ^ (according to the schedule, it's your day ;))
<slangasek> yes
<slangasek> dpm, stgraber: you're not actually expecting any review of these, right?  since they're quite unreviewable
<slangasek> i.e., you just need them accepted, yes?
<stgraber> slangasek: yeah, just having them accepted should be enough. IIRC the common problems with the langpacks are missing packages but we'll have that checked with the first Edubuntu build (as it includes all the langpacks)
 * slangasek watches to see what the API client does with 820 langpack accepts in one call
<dpm> slangasek, pitti generally accepts them after having manually tested one or two of them, which I did as well (running the -ca one now without any noticeable regression)
<slangasek> dpm: right, I'll consider that good enough
<dpm> cool, thanks
<slangasek> now it's just a matter of seeing whether the api client explodes ;)
<stgraber> slangasek: I see that one also landed in New, so I guess that one will need accepting + promoting
<infinity> stgraber: overriding and accepting, you mean. :P
<stgraber> infinity: indeed
<infinity> (I took care of the ones in NEW)
<stgraber> ^ hmm, wondering if something weird happened on LP or if it's just queuebot getting confused ;)
<infinity> stgraber: Maybe queuebot's having issues with the massive langpack-ridden queue?
<slangasek> ok, langpacks being accepted now, after tweaking the queue script to not be O(n^2)
<slangasek> (https://code.launchpad.net/~vorlon/ubuntu-archive-tools/queue-item-scaling/+merge/118166)
<infinity> stgraber: What's the heuristic for "approved"?  Is it actually checking a state, or is it looking for a lack of state (ie: no longer in unapproved, and also not rejected)?
<stgraber> infinity: it's returning that if the package is no longer in Unapproved and .status != "Rejected"
<stgraber> so yeah, if it only gets a partial set out of LP for some reason, it'd mark them as accepted
<infinity> stgraber: Right, that matches the above behaviour for me, then.
<infinity> stgraber: I'm guessing it's timing out or otherwise failing to load the massive queue, so things are being "removed", and then "readded" when the next run succeeds.
 * ScottK resists the temptation to fix slangasek's grammar in the commit message.
<stgraber> infinity: well, if it was actually getting a timeout, it wouldn't do anything and would dump it to the log. The weird thing is that it doesn't seem to timeout.
<infinity> stgraber: Is this one of those datasets that "pages" in the API, and you're not paging to the end?
<infinity> ScottK: Not a fan of ironic use of poor grammar?
<stgraber> I'm currently assuming I'm getting all of them in a single call, but it could be that it's not the case
 * stgraber checks the doc for series.getPackageUploads(status=queue)
<ScottK> infinity: Are you sure it was ironic?
<infinity> ScottK: Knowing slangasek, it almost certainly was.
<ScottK> Sure, but it's more fun to ignore that.
<infinity> ScottK: Well, even if he wasn't a language nut, he's also in PDX, and everyone there does everything ironically.  It's a bylaw.
<slangasek> ScottK: it's not in the commit message, just in the mp ;)
<ScottK> OK.
<ScottK> You know how much I use merge proposals.  I thought they were the same.
<stgraber> mute queue unapproved precise-proposed
<stgraber> will unmute once the langpacks are all gone :)
<skaet> :)
<slangasek> ScottK: I would of course never do bad grammar somewhere /permanent/
<ScottK> ;-)
<infinity> I'm pretty sure I've used "don't work so good" in changelogs.
<slangasek> ok, langpacks all accepted
<stgraber> unmute queue unapproved precise-proposed
<slangasek> anyone know anything about the firefox in precise-proposed new?
<ScottK> Similar to the one in oneiric/natty proposed New as well.
<ScottK> IIRC micahg  knows about it.
<slangasek> I'm having trouble finding any binaries that are actually new in those uploads
<slangasek> so have no idea why they're in the new queue
<slangasek> micahg: ^^?
<stgraber> slangasek: if you have some time to review unapproved, can you start with live-build and debian-installer?
<micahg> slangasek: it's to fix a regression, it should make it into the point release
<infinity> slangasek: Anything installed via "apt-get install task^" is considered manual.
<slangasek> how unfortunate
<infinity> slangasek: That's vaguely by design (and why we use tasks instead of installing the metapackages), but it has some drawbacks, like having the initial set of headers be manual, while all subsequent ones are auto.
<slangasek> that implies libraries that are part of tasks will never be correctly autoremoved
<infinity> slangasek: It's also unfortunate for libraries.
<infinity> slangasek: Yeah.
<slangasek> and explains behavior I've seen myself in the past :)
<slangasek> anyway, accepted now
<infinity> slangasek: The reasoning was that we don't want all of ubuntu-desktop to be autoremoved if you remove the metapackage, but the library behaviour is irksome.
<slangasek> yeah, I understand
<infinity> (The real solution is probably to not have transitive dependencies in tasks, but that's a Really Hard Problem to solve)
<stgraber> infinity: I pushed the matching seed change now that d-i got in -proposed
<infinity> stgraber: Danke.
<infinity> stgraber: You missed one omap4.
<infinity> stgraber: (I tend to just use "echo supported-installer-common installer | xargs sed -i -e 's/oldabi/newabi/g'" for those changes, since computers are much better at this than my old eyes)
<stgraber> infinity: gah... fixed
<stgraber> slangasek, infinity: cyphermox and I have been trying to get a network-manager upload to the archive (quantal) but it's being silently dropped apparently
<stgraber> is there some log you can access to check what's going on or should I poke #launchpad-ops?
<infinity> stgraber: "Silenty dropped" usually implies "so broken that it can't effectively reject it".
<stgraber> infinity: debdiff: http://paste.ubuntu.com/1127603/
<stgraber> .changes: http://paste.ubuntu.com/1127607/
<infinity> The diff is less interesting than the actual source and changes.
<cyphermox> there's nothing special about it ;)
<infinity> It could also be that poppy is having a hissy fit.  Are you uploading via sftp or ftp?
<cyphermox> ftp
<stgraber> ftp
<cyphermox> stgraber tries too
<cyphermox> ah
<cyphermox> I could try over sftp
<infinity> sftp goes through an entirely different set of machinery.
<cyphermox> alright
<infinity> Though, it's usually the one that's broken. :P
<cyphermox> hehe
<cyphermox> fwiw I tried via chinstap too, but that didn't change a thing
<infinity> I see a bunch in the failed queue.  Sec.
<infinity> With zero indication as to why.  Swell.
<cyphermox> oh yay
<slangasek> ahhh why is queuediff totem showing me a diff between 3.0.1 (in the queue) and 3.3.4 (nowhere near)?
<stgraber> slangasek: I also noticed that the LP diff seems to diff against rejected uploads too (like it did with base-files)
<slangasek> sigh
<infinity> cyphermox: So, are you sure you used a key that's in the Ubuntu keyring?
<infinity> cyphermox: (I note you have two keys in LP, you signed the package with the newer one)
<cyphermox> yes. the same key as all uploads i've ever done
<infinity> Kay.
<cyphermox> just tried over sftp; we'll see
<stgraber> infinity: that was my first guess and why I asked cyphermox for the source so I could try to sign it myself and upload it
<cyphermox> infinity: also, I would have received a rejection message in that case, no?
<dpm> ok, time to call it a day. Thanks slangasek and stgraber for taking care of the language packs
<stgraber> infinity: interestingly, the exact same source and changes uploaded to a PPA get accepted just fine
<dpm> have a great weekend everyone!
<stgraber> cyphermox: IIRC, no, invalid GPG key is a silent reject
<cyphermox> heh, well, I've been using the same as usual anyway
<infinity> Yeah, I re-signed for kicks, and mine also failed.  Time to take this to lp-ops.
<slangasek> network-manager hasn't managed to end up in some crazy unusable packageset, has it?
<cyphermox> crazy unusable packageset?
<cyphermox> NM is uploadable by core, desktop, and network-manager IIRC
<slangasek> yes, that's how it's meant to be configured
<slangasek> I'm asking if something has gone wrong: )
<cyphermox> not that I know of ;)
<cyphermox> I wouldn't know where else to look for issues there than edit_acl.py; which reports http://paste.ubuntu.com/1127635/
<cyphermox> looks right
<stgraber> edit-acl looks happy (in both core and network-manager + generic component upload rights in main)
<cyphermox> infinity: did you already bring it up or should I?
<infinity> cyphermox: https://oops.canonical.com/?oopsid=OOPS-3ec836710bf79c21af430a2f88cbfc0d
<ubot2> https://lp-oops.canonical.com/oops.py/?oopsid=3ec836710bf79c21af430a2f88cbfc0d
<infinity> cyphermox: Hope that helps. :P
<cyphermox> oh yay
<micahg> can someone please deNEW the firefox SRU in natty/oneiric?
<slangasek> micahg: done - sorry, it slipped my stack
<micahg> slangasek: no problem, thanks, now I can comment in the bug :)
<cjwatson> yay, copy-report works from lillypilly
<cjwatson> https://launchpad.net/ubuntu/+source/libapache-mod-security/+publishinghistory
<jdstrand> \o/
<jdstrand> you scared me for a second. I only just pocket copied that a bit ago :)
<cjwatson> I trust you didn't copy it to -updates too, and that was indeed a valid test of my machinery
<jdstrand> indeed
<jdstrand> regular 'ol copy to -security
<jdstrand> or is it ol'?
<cjwatson> dropping the d at the end not some random letter at the start, I trust
<cjwatson> anyhow, that means copy-package.py can die die die
<jdstrand> woohoo!
<cjwatson> though I get annoying mail about the copies; must fix that ...
<cjwatson> Maybe it should not send e-mail when copying between two pockets in the same archive
<micahg> it's a nice audit trail
<micahg> at least for -proposed -> -updates
<cjwatson> Which you didn't have before anyway
<cjwatson> At least, copy-package.py never sent mail
<cjwatson> You can see the difference in https://lists.ubuntu.com/archives/oneiric-changes/2012-August/thread.html
<cjwatson> If you want a proper audit trail, isn't +publishinghistory better?
<micahg> sure, but that requires more work AIUI
<cjwatson> Hm?
<micahg> it shows who copies between proposed and updates?
<cjwatson> Yes
<infinity> And, some day, +publishinghistory may actually tell me who did what.
<cjwatson> Oh, no
<cjwatson> It should
<micahg> heh
<cjwatson> Please file a bug
<infinity> I think it probably fits in with the queue audit trail bug.
<cjwatson> Still, I don't buy that you suddenly need an audit trail that you never had for the -security => -updates autocopies
<cjwatson> infinity: That's more general; I'd prefer a separate one for this
<cjwatson> LP already stores this information, so it's just a UI matter of exposing it
<micahg> cjwatson: oh, for those we don't need it, it's more useful to see who promoted what to updates
<infinity> Which is probably just cargo-culting, then, from how it displays who requested deletions?
<cjwatson> >>> pubs[0]
<cjwatson> <source_package_publishing_history at https://api.launchpad.net/1.0/ubuntu/+archive/primary/+sourcepub/2595496>
<cjwatson> >>> pubs[0].creator
<cjwatson> <person at https://api.launchpad.net/1.0/~ubuntu-archive-robot>
<cjwatson> ^- example
<cjwatson> infinity: I'd need to test, but I rather expect it's about as hard as http://paste.ubuntu.com/1127996/
<micahg> Bug #1032857
<ubot2> Launchpad bug 1032857 in launchpad "+publishinghistory should show who did the copies" [Undecided,New] https://launchpad.net/bugs/1032857
<micahg> I think as a side note, it's nice to see on -changes when SRUs are promoted
<infinity> cjwatson: Looks complicated. :P
 * cjwatson wonders also why oneiric-changes got two mails
<cjwatson> And natty-changes
<cjwatson> Doubtless a null copy, but that shouldn't have sent mail
<cjwatson> Maybe I should reduce the frequency to hourly as a temp workaround ...
<micahg> weirdly, one had content and one didn't
<cjwatson> Or maybe copy-report can do a better check for that
<cjwatson> Yes, hence my thesis that the second was a null copy
<cjwatson> i.e. there was already a pending SPPH in -updates from the first one
<cjwatson> but the publisher hadn't completed yet
<cjwatson> And indeed I got an OOPS
<infinity> Yeah, the publisher is dead slow today.  Langpack days hurt.
<micahg> ah
<infinity> And libreoffice translation tarballs too.
<infinity> All things translations. :P
<cjwatson> Ah, it's basically bug 1023372
<ubot2> Launchpad bug 1023372 in launchpad "Direct-copying an already-published package OOPSes" [Critical,Triaged] https://launchpad.net/bugs/1023372
<cjwatson> Ish
#ubuntu-release 2012-08-04
<cjwatson> OK, MP raised for the publishinghistory improvement above
<cjwatson> And I've installed a workaround in copy-report to try to avoid those null copies
<wgrant> cjwatson: I'm pretty sure there's an existing bug for that
<wgrant> cjwatson: Also, that's buggy
<wgrant> cjwatson: Look at the markup in the test you added :)
<cjwatson> I looked for an existing bug and couldn't find one
<wgrant> Maybe I'm thinking of sponsor
<wgrant> So
<cjwatson> Maybe it's too late at night, but what's wrong with the markup?
<wgrant> I'd do <tal:message condition="context/creator">by <span tal:replace="structure context/creator/fmt:link" /></tal:message> or so
<wgrant> It's escaped
<cjwatson> ... oh, that escaping isn't introduced by extract_text is it?
<cjwatson> I assumed it was doctest insanity
<wgrant> No
<wgrant> TAL is stupid
<wgrant> You declare in the template whether a string is safe
<wgrant> Rather than declaring in the string that the string is safe
<cjwatson> Something like yours is what I started with and then I tried to imitate the surroundings
<cjwatson> I'll put it back
<wgrant> Don't imitate surroundings in LP
<wgrant> They're usually wrong.
<wgrant> Ah, yeah, I see your original diff
<wgrant> The other places do it because there's no sensible fmt:link
<wgrant> Or they ignore that there is one
<wgrant> I'm not quite sure what that template has against IArchive's fmt:link.
<cjwatson> Ah, bug 851047
<ubot2> Launchpad bug 851047 in launchpad "The PPA page and distro publishing details pages don't correctly show where a package was copied from" [High,Triaged] https://launchpad.net/bugs/851047
<cjwatson> Should I just try to fix this all at once?
<cjwatson> Micah's single case was easyish ...
<wgrant> cjwatson: Might as well. Even better if you show sponsor too, although I can't see a bug.
<wgrant> Both should be pretty trivial
<wgrant> The hardest bit is identifying the tests
<wgrant> and ec2 will do that easily :)
<wgrant> If slowly...
<cjwatson> I managed to blow the monthly limit on the cloud computing policy last month
<cjwatson> Roll on LP tests in Canonistack
<wgrant> Hm, you should talk to someone about that. We're advised to file it under misc, since it's essential and anyone who's doing anything violates it.
<wgrant> Now
<wgrant> I'm just thinking
<wgrant> +publishinghistory doesn't show any people at the moment, does it?
<wgrant> So adding even one is probably going to make it time out.
<wgrant> Fortunately, preloading this is roughly two lines if you can identify the views that render lots of these.
<cjwatson> BinaryPublishingRecordView (though at least this part of the change is a no-op there) and SourcePublishingRecordView
<wgrant> Yeah, those are the only two I can think of
<cjwatson> That's from grep for that template
<wgrant> The foreign keys you care about are all in the easy directly, fortunately.
<wgrant> s/directly/direction/
<wgrant> You don't have to deal with cachedproperties. Just load the objects into the global storm cache.
<cjwatson> Just in initialize?
<wgrant> Right. You'll probably want to use lp.services.bulk.load_related to grab the ancestor, and then getPrecachedPersonsFromIds or whatever it is to grab the creator and sponsor.
<cjwatson> OK.  Tomorrow I think.
<cjwatson> Thanks.
<wgrant> Yeah.
<wgrant> If you need any help, I'm happy to as always.
<slangasek> wgrant: is this why +publishinghistory is now timing out for me? :)
<wgrant> slangasek: No. Do you have an OOPS ID?
<wgrant> It's unbatched, so packages with insane numbers of uploads will always time out.
<wgrant> And have always timed out.
<slangasek>  OOPS-9f81eb12c92b5d31bf2cdff106cade84)
<ubot2> https://lp-oops.canonical.com/oops.py/?oopsid=9f81eb12c92b5d31bf2cdff106cade84
<slangasek> oh, really?
<slangasek> I've never seen timeouts before
<wgrant> It's better than it used to be, since it's not pulling down tens of megabytes of changelogs from the DB any more
<wgrant> Wow
<wgrant> 700ms of DB time, 5s of Python
<wgrant> I suspect you were just fairly unlucky, but let's see...
<wgrant> (since it loads for me)
<cjwatson> slangasek: the above discussion between wgrant and me is of a patch that hasn't landed
<slangasek> ok :-)
<slangasek> I wouldn't have expected it to land so fast, but figured I should check
<wgrant> Maybe by the end of the year we'll be deploying stuff an hour after we think of it, but not yet :)
<slangasek> bdmurray: so I found your dist-upgrader-all directories; ubuntu/dists/precise-updates/main/dist-upgrader-all/ instead of ubuntu/dists/precise/main/dist-upgrader-all/
<slangasek> bdmurray: are you saying that the precise-updates ones aren't being used?
<slangasek> if so we probably have to manually copy... and put that on the pile of things to fix before we lose cocoplum shells ;)
<cjwatson> slangasek: Uh, I fixed that recently
<infinity> slangasek: The updates ones absolutely should be used, if that's not happening, we should fix the broken bits, not copy stuff into release...
<slangasek> cjwatson: which part?
<wgrant> Yeah, you're not going to convince LP to poke the release pocket
<cjwatson> automatic copying from precise-proposed to precise-updates
<wgrant> You'll have to fix u-m
<slangasek> right
<infinity> cjwatson: It's in updates.
<cjwatson> Yeah, I didn't fix u-m, but that's what should be done.
<cjwatson> Taking away our lp_publish access might be a good way to stop us being tempted to do that kind of thing. :)
<wgrant> Yes :)
<wgrant> slangasek: Does the page work for you now? I suspect you just had bad luck that time
<wgrant> It's sitting at about 90% of the timeout for me, mostly because there's so many uploads
<wgrant> We really should batch it, but there was resistance from you guys last time we tried ('09)
<cjwatson> So the upgrade tool URL is in the meta-release file
<infinity> Does mvo still hold all the keys to that?
<cjwatson> http://changelogs.ubuntu.com/meta-release and friends
<slangasek> there was resistance from cjwatson in particular to batching, yes
<slangasek> I defer to him :)
<cjwatson> Probably
<slangasek> wgrant: page is timing out for me consistently
<cjwatson> It would take mvo about a minute to fix it
 * infinity nods.
<cjwatson> batching> Well, the thing I objected to at the time was difficulty of searching
<cjwatson> But, at the time, there wasn't an API worth mentioning
<infinity> We might want to de-SPOF mvo on the meta-release stuff sometime.
<infinity> It's not hard to fix, but it often seems to need fixing in a hurry (not this time, obviously).
<cjwatson> I think nowadays it'd be fine to batch that and punt to the API for searchability
<cjwatson> So consider my historical resistance withdrawn
<slangasek> it's possible bdmurray has access to metarelease
<wgrant> It's a very batchable page, because the core query to determine the contents is indexed, ordered and fairly quick.
<slangasek> but he's EOD too :)
<slangasek> anyway, I've taken that to email
<cjwatson> I'd certainly rather it be batched than time out.
<cjwatson> And the more we upload stuff, the more it times out for important packages.
<wgrant> Yup
<cjwatson> Fairly inevitably.
<wgrant> You ignored that argument last time :P
<cjwatson> I didn't ignore it, I just didn't consider it dominating
<infinity> He clearly didn't maintaing anything important before.
<infinity> Nor maintain.
<cjwatson> We don't need to grep through +publishinghistory for stuff nearly so often now
<slangasek> stgraber: the edubuntu-artwork SRU references a bug not marked as fixed in quantal?
<stgraber> slangasek: let me check, I'm 90% sure that was fixed earlier in quantal
<stgraber> slangasek: right, was fixed in 12.06.3
<slangasek> stgraber: ok.  I'm assuming you're ok with having this for .1, for edubuntu?
<slangasek> (was uploaded before the deadline, anyway)
<ScottK> slangasek: Looks to me like the compiz SRU should be failed/removed already since it FTBFS on arm*.
<stgraber> slangasek: yep, I discussed it with jocarter before he uploaded.
<infinity> ScottK: I'd concur with that.
<stgraber> yeah, it should at least be marked as failed and probably removed. I can do some poking next week to figure out whether they had any critical bugs that need to be fixed for 12.04.1 or if they can wait till after the point release.
<infinity> stgraber: Fixing the FTBFS shouldn't be rocket science for them, I'm sure.
<infinity> stgraber: But releasing a skewed compiz is a non-starter, IMO.
<infinity> stgraber: So, there shouldn't even be a "well, if it fixes some critical bugs..." consideration.
<stgraber> infinity: well, I haven't looked at the diff but I remember ogra_ complaining quite a bit about the work needed to update the arm patches that sit on top of the compiz code.
<stgraber> infinity: so yeah, skewed compiz is definitely a non-starter, I'm just wondering if we can have something fixed early enough (Monday/Tuesday) or if we can just postpone the compiz change until after we released 12.04.1
<slangasek> there's at least one targeted compiz bug
<slangasek> so, it shouldn't be promoted as-is, but I think we should try to get a fixed version
<slangasek> bug #1032902 opened
<ubot2> Launchpad bug 1032902 in compiz "compiz 1:0.9.7.8-0ubuntu1.3 FTBFS in precise-proposed on armel, armhf" [Critical,Triaged] https://launchpad.net/bugs/1032902
<slangasek> infinity: ^^ if you happen to have some time this weekend, this mdadm SRU would be nice to have reviewed and (hopefully) accepted; it fixes the regression found in the previous one
<infinity> slangasek: Diff looks like it should do (or, rather, not do) what it advertises...
<asomething> Hi all. I've got a regression in precise-proposed. The package is indicator-weather. There is a fix in the queue. I'd appreciate it if someone could accept the new package or at least nuke the old one until someone can accept the new one.
<asomething> The regression is tracked in lp: #1032887
<asomething> and the original bug that the SRU intended to fix is lp: #964365
<asomething> version with regression: 11.11.28-0ubuntu1.1; fixed version: 11.11.28-0ubuntu1.2
#ubuntu-release 2012-08-05
 * micahg wonders if infinity or ScottK are available to take care of the -proposed regression asomething mentioned above
<infinity> micahg: Sure.  I'm going to re-upload it with -v, so it snags the previous -proposed bugs as well, otherwise it looks fine.
<micahg> infinity: you want me to do that so you can accept?
<infinity> micahg: I've already reviewed it, if my source matches his, I think I can let it slide and accept. :P
<micahg> ok
<micahg> infinity: well, it just looks bad on the changes list, that's all
<infinity> micahg: Not really, since the -changes list has no idea who accepted. :P
<infinity> Anyhow, already re-uploaded an identical version with a more complete .changes
<micahg> oh, right, that's another bug..
<micahg> no audit trail for accepts I mean
<infinity> Yeah, it's been "in progress" for months.
 * infinity wonders if sru-accept removes all the regression tags, or if I'll have to do that by hand.
<infinity> Hrm, looks like it doesn't.
 * infinity wonders if perhaps it should...
<infinity> Though, that messed with multi-package bugs.
<infinity> Tags being attached to the bug instead of the taks make this all really messy. :/
#ubuntu-release 2013-07-29
<micahg> I would prefer if there were only one version of mozjs in the archive, truthfully, it doesn't matter since it's not supportable in any event
<darkxst> micahg, that is basically impossible
<micahg> darkxst: what is impossible?
<darkxst> well only having the new mozjs
<micahg> is stuff still not ported 8 months after release?
<darkxst> couchdb uses invalided syntax as a core feature, so they can't port to mozjs17 without breaking every user extension ever written
<micahg> as I said, in truth, it doesn't matter, since it's not supportable from a security standpoint
<darkxst> I am not aware of any othere projects that have ported, but so far Fedora and the crazy rolling distros are the only ones to have packaged mozjs
<darkxst> ^mozjs17
 * micahg wonders if this should move somewhere else, -motu?
<darkxst> micahg, ok
<chrisccoulson> infinity, i don't. like firefox, it's something i have very little time for these days :/
 * slangasek moves gdbserver to main
<jibel> when i386 and amd64 images are being smoketested, checksums in http://cdimage.ubuntu.com/daily-live/current/ doesn't correspond to the images available in this directory
<jibel> checksums are from the 29th but i386 and amd64 images are from the 28th
<jibel> which makes checksum validation possible only if pending and current are in sync
<xnox> jibel: but smoketesting should be done on /pending/ images where checksums do match, no?!
<jibel> xnox, right, but during that time images in current are "invalid"
<jibel> xnox, and pending is mainly for smoketesting, current for any other test on "known good" images
<xnox> jibel: yes. /current/ can be a mix of images, but there is only one checksums file at the moment. I guess we do need per image checksums and/or signatures....
<infinity> We have per-image checksums, in said file.
<infinity> It's just a bug if it's not being generated correctly, not something that needs reengineering.
<jibel> I guess checksums files in current are a copy from pending, not regenerated from the actual content of current
<xnox> jibel: the checksums under http://cdimages.ubuntu.com/daily-live/20130728/ and http://cdimages.ubuntu.com/daily-live/20130729/ are correct.
<xnox> jibel: so one can lookup build timestamp, then go to full url to fetch static checksum file and verify against it.
<jibel> xnox, but http://cdimage.ubuntu.com/daily-live/current/ are not
<cjwatson> jibel: They're supposed to be regenerated ...
<infinity> jibel: Indeed, that appears to be the case.
<cjwatson> xnox: You don't need to be a support firewall here :)
<infinity> cjwatson:
<xnox> cjwatson: =) ack.
<cjwatson> If it's broken, we should fix it
<infinity> cdimage@nusakan:~/cdimage/www/full/daily-live/current$ md5sum -c MD5SUMS
<infinity> saucy-desktop-amd64+mac.iso: OK
<infinity> saucy-desktop-amd64.iso: FAILED
<infinity> saucy-desktop-armhf+omap4.img: OK
<infinity> saucy-desktop-i386.iso: FAILED
<infinity> saucy-desktop-powerpc.iso: OK
<infinity> md5sum: WARNING: 2 computed checksums did NOT match
<cjwatson> infinity: Right, I'll have a look
<jibel> thank you
<cjwatson> Perplexing.  This is absolutely meant to work.
<cjwatson> However I have children screaming in the background so you'll have to wait a bit until my concentration isn't shredded. :-/
<cjwatson> slangasek: Back when you disabled zh_CN images in favour of UbuntuKylin (cdimage r1274), did you intentionally disable them for precise too?  That seems odd since UbuntuKylin postdates precise.
<slangasek> cjwatson: I don't recall this being intentional
<cjwatson> slangasek: OK, putting them back then, thanks
<infinity> Hrm, uploading glibc only triggered 19 tests.  I wonder if our rdep handling is incorrect, or if our test coverage of C/C++ projects is really that abysmal.
<ScottK> If a package in Debian moves from main to non-free and is autosync'ed, does that move get tracked and it goes to multiverse?
<ScottK> ibm-3270 is the package that has me thinking the answer is "no".
<cjwatson> ScottK: Sadly not.
<ScottK> OK.  In this particular case, I think it's OK as Debian was being overly pedantic.
<xnox> infinity: sorry for being so out of date =)
<cjwatson> jibel: I *think* I have fixed this.  Not completely sure as it's a pain to test.  Tomorrow's attempt should tell us
<jibel> cjwatson, thanks, I'll tell you if it is still occurring tomorrow.
<infinity> xnox: S'ok, it reminded me to poke the current binutils transition with some additional uploads. :)
<infinity> (It should be good to go now, once those two build)
<infinity> This whole (near)instant upload queue business is making me feel all velocitized.
<infinity> Funny how we can write gobs of code for fancy features, but the ones that impact us the most seem to be really simple.
 * infinity is going to find some lunch and, when he gets back, wrangle the linux/d-i/seeds/germinate mess into submission so he never has to edit for ABI bumps EVAR AGAIN.
<Ursinha> slangasek, cjwatson, release team call?
<cjwatson> infinity: https://code.launchpad.net/~cjwatson/launchpad-buildd/fix-abort/+merge/177003 should be worth another look; I tweaked upgrade-config.
<infinity> cjwatson: Hah.  Way to complicate the code to serve your anal-retension. ;)
<cjwatson> I contemplated writing a general parser
<cjwatson> Briefly
<infinity> Well, it's a standard ini syntax, there are a bazillion parsers out there.  But adding a dep just for the postinst is silly.
<cjwatson> Parser/order-preserving-reserialiser, I mean
<infinity> The postinst is generally silly to start with.
<cjwatson> It's probably possible with just the Python stdlib, I just couldn't be bothered :)
<infinity> Reading it didn't do much for my sanity, but it seems to work as advertised.
<infinity> Ahh, and thank you for r61
<infinity> cjwatson: And thanks for the subtle hint in there that buildd-slave-example.conf is wildly out of date.  I brought it up to date in trunk now.
<infinity> cjwatson: Maybe that should just be autogenerated by a Makefile from template.conf
<infinity> cjwatson: And, of course, I went and committed things before I took your MP, cause I'm SMRT.
<infinity> cjwatson: Want to rebase to trunk, and then I'll pull your MP in?  It looks as good as I can tell from reviewing without running (and I saw it running).
<stokachu> im in the process of getting package sosreport included into main, however, when i attempt to add it to a seed file (cloud-image) it gives me a readonly transport error during the commit. is this a permissions thing for my account?
<stokachu> bzr: ERROR: Cannot lock LockDir(chroot-94282704:///~ubuntu-core-dev/ubuntu-seeds/ubuntu.saucy/.bzr/branch/lock): Transport operation not possible: readonly transport
<jbicha> stokachu: you need to be a member of that team to push to the team's branches
<stokachu> jbicha: i was trying to push it under my account is that not possible this way?
<stokachu> and then open an MP to have it reviewed
<jbicha> what command were you using to push?
<stokachu> i tried variations but the one i thought was right is: bzr push lp:~adam-stokes/ubuntu-core-dev/ubuntu-seeds/ubuntu.saucy
<stokachu> similar to how i alter packages
<stokachu> im trying to do #5 on this list : https://wiki.ubuntu.com/MainInclusionProcess
<jbicha> stokachu: I think you need to leave out the "ubuntu-core-dev" part
<stokachu> jbicha: ok that allowed me to push to my account
<stgraber> stokachu: bzr push lp:~adam-stokes/ubuntu-seeds/ubuntu.saucy should work (~<username>/<project>/<branch name>)
<stokachu> now that its pushed how do i tell bzr commit i want to update the commit for that branch
<stokachu> i tried bzr commit :parent
<stgraber> ah yeah, just do a push with --remember
<stokachu> ok lemme try that
<stgraber> then after that, any "bzr push" should just use the right location automatically
<stokachu> so that allows me to push automatically but the bzr commit still fails for some reason
<stgraber> ah, is that a bound branch?
<stokachu> yea i did a bzr checkout
<stokachu> i got that from the changing the seeds document
<stokachu> https://wiki.ubuntu.com/SeedManagement#Changing_the_Seeds
<stokachu> should i do a bzr branch instead?
<stgraber> you can just bzr bind :push
<stgraber> that should change the source/target of the bind
<stgraber> or just bzr unbind if you want to turn the branch into a standard unbound branch
<stokachu> stgraber: sweet! that works
<cjwatson> infinity: Thanks.  I should probably leave it until the preliminary master side (buildstatus-aborted) is reviewed, though, because landing this without that preparatory work would be bad.
<infinity> cjwatson: Well, landing it is fine, as long as we don't request a rollout to -cat prematurely. :P
<infinity> cjwatson: That's entirely up to us, IS doesn't pull without a request.
<infinity> cjwatson: And I'd rather have it landed than sitting in a topic branch forever.  But up to you.
<barry> oops. i made a typo in a changelog i didn't catch until i uploaded.
<infinity> barry: I guess you get to fix it retroactively in the next upload.
<infinity> barry: Unless it was an SRU, then I can reject it.
<cjwatson> infinity: Hopefully won't be long.  I just wanted to avoid confusing anyone with a -buildd branch that doesn't work with LP devel.
<cjwatson> (Not least myself.)
<barry> infinity: i caught it before i uploaded the sru one!  it may be a while before i upload a new version in saucy ;)
<barry> (it's one character s/2/3/ ;)
<barry> i guess i could just do a +1 upload to overwrite it
<infinity> Why bother?
<barry> only that it would be misleading/confusing for someone reading the changelog (the entry implies it fixes things in a python2 env, really it fixes things in a python3 env)
<infinity> barry: Not world-ending.  Which package was this?
<barry> infinity: command-not-found
<infinity> Yeah.  Meh.
<barry> infinity: it's easy enough to ignore ;)
<infinity> I'm already ignoring it.
<infinity> Watch me ignore.
<infinity> LA LA LA.
<barry> ignoring what?
<infinity> Who said that?
<barry> is this mic on?
<infinity> (Thanks folks, we're here all week.  Try the fish.)
<barry> tip your waiters, waitresses, and mindless ubuntu developers
<barry> well, at least i got it right in the sur
<barry> *sru
#ubuntu-release 2013-07-30
<cjwatson> infinity: I notice you're using subprocess.check_output in buildrecipe now.  Doesn't launchpad-buildd need to stick to features that were in Python 2.5 until we upgrade off lucid?
<cjwatson> Er, hardy I mean
<cjwatson> lucid had 2.6; subprocess.check_output is new in 2.7
<cjwatson> infinity: Also, did you intentionally drop the "apt-get clean" from debian/launchpad-buildd.cron.daily?  The commit message didn't mention it.
<infinity> cjwatson: Oh, I didn't realize check_output was new.  Bother.
<infinity> cjwatson: And yes, I dropped the pointless apt-get clean.  lp-buildd has no business dealing with the host's apt.
<infinity> cjwatson: Do you have a pre-2.7 recommendation for check_output-like functionality?
<infinity> cjwatson: Hrm, os.popen.read, perhaps?
<cjwatson> God, no, don't use os.popen.
<infinity> cjwatson: *smirk*
<cjwatson> subprocess.Popen(stdout=subprocess.PIPE).communicate()[0] is probably the best answer
<infinity> cjwatson: I'm just looking for a quick-n-dirty backtick equivalent, not the most robust and complex subprocess control setup evar.
<cjwatson> Though it wouldn't hurt to assign the Popen object to a variable so that you can check .returncode after calling .communicate.
<infinity> Python amuses me.  The number of times I hear "oh god, don't use that method", when something shinier comes along, why don't they just rewrite the old to use the new, rather than point and laugh at you for using the wrong thing? :P
<cjwatson> So maybe something along the lines of http://paste.ubuntu.com/5928451/, entirely untested.
<cjwatson> Well, it's more that os.popen is lower-level.
<infinity> That's certainly more unreadable.  Progress. ;)
<infinity> cjwatson: I'm struggling to see what's wrong with low-level.  What could be lower-level than forking another process and checking its output?
<infinity> Pretty sure that $() isn't all that fancy and high-level.
<cjwatson> The above paste really is wrong.  One moment.
<infinity> But, meh.
<infinity> (I was going to just use os.popen and comment out the "this should actually be this, when we have 2.7+" line)
<cjwatson> http://paste.ubuntu.com/5928455/ - better.
<cjwatson> infinity: You're saying this to the guy who got fed up of doing that in C and wrote libpipeline ...
<infinity> I wish I hadn't deleted all my hardy chroots.
<infinity> But I don't wish that hard enough to recreate them.
<cjwatson> I suspect the real reason os.popen is deprecated rather than fixed is a combination of (a) hard to make cross-platform (b) interfaces that take strings as commands rather than lists are fundamentally evil
<cjwatson> (Although maybe (a) is wrong since the documentation says it works on Windows.)
<infinity> cjwatson: A string is perfectly reasonable if you're passing it to "sh -c", but that returns to the "not cross-platform".
<infinity> Maybe there's a cmd.exe -c equivalent (or some functionality provided by rundll or something)
 * infinity shrugs.
<cjwatson> Interfaces that take strings are the root of many security holes.
<infinity> Programmers who don't do input validation are the root of many security holes.
<infinity> Anyhow.  Doesn't matter to me either way.  And I'm too sick to have religious debates.
<infinity> cjwatson: If that pastebinned diff works as a quick copy-and-paste-and-replace-the-chroot-path-with-a-string snippet, commit away.
<infinity> And given the hasty addition of PIPE to your import in the second try, I assume you did actually test it. ;)
<infinity> cjwatson: I actually started out with basically that (since Popen was already imported), got lost when various stdout=PIPE examples blew up in my face, and never get to the point of learning until now that PIPE was a thing I needed to import.
<infinity> s/get/got/
<cjwatson> I usually spell it subprocess.PIPE, which is clearer, but I was going with the prevailing style here.
<cjwatson> Committed.
<phillw> Hi folks, just a quick note to say that the links at http://iso.qa.ubuntu.com/qatracker/milestones/254/builds/37582/downloads are reporting 404
<cjwatson> That's hardly surprising
<cjwatson> We only keep daily builds around for a couple of days
<cjwatson> iso.qa.ubuntu.com is not a persistent way to get at images after they've finished their testing cycle
<cjwatson> Ubuntu 12.04.2 server amd64 is here: http://releases.ubuntu.com/12.04.2/
<phillw> cjwatson: thanks colin, I need to re-grab it.
#ubuntu-release 2013-07-31
<psivaa> infinity: cjwatson: for the uninstallable packages listed in the report.html in precise  cdimage, reported bug #1206860 to account the smoke failure
<ubot2`> Launchpad bug 1206860 in xf86-input-wacom-lts-raring (Ubuntu Precise) "xserver-xorg-input-all-lts-raring are unintstallable with precise alternate images" [Undecided,New] https://launchpad.net/bugs/1206860
<infinity> psivaa: Already noted at http://people.canonical.com/~ubuntu-archive/testing/precise-proposed_probs.html
<cjwatson> Also e-mailed to us daily
<cjwatson> Feel free to have a tracking bug if it helps you but we don't need one and it's quite plausible we'll forget to close it ...
<psivaa> infinity: cjwatson: ack, i am doing the both :)
<infinity> I'll remember in this case, cause I'm about to fix it.
<cjwatson> (i.e. it's actually slightly worse for us to have a tracking bug than not, for things in the report)
<psivaa> cjwatson: agreed, but without a tracking bug the smoke dashboard will be red with 0% pass rate with no bugs tagged
<cjwatson> psivaa: Ideally there'd be some other way to log an explanation of what's happening
<psivaa> cjwatson: yes, but on the other side we have a daily image that's not installable. so a bug can only accompany that imho :)
<psivaa> if it's a known bug or not is a separate issue
<rbasak> apache2-prefork-dev 2.2.22-6ubuntu5 appears to be in saucy, built from the apache2 source. How do binary packages get removed when they're no longer relevant?
<rbasak> (apache2-dev 2.4.6-2ubuntu1 now replaces/provides apache2-prefork-dev and it's in saucy too)
<xnox> rbasak: an Archive admin removes them by hand, following output from a report http://people.canonical.com/~ubuntu-archive/nbs.html
<xnox> rbasak: if ofcourse it's time to do it / safe to do.
<rbasak> I see - thanks
<rbasak> This is bug 1206114. I'm not sure if it's causing a problem, but it certainly complicates things a bit.
<ubot2`> Launchpad bug 1206114 in apache2 (Ubuntu) "Package apache2-prefork-dev broken in Saucy" [Undecided,New] https://launchpad.net/bugs/1206114
<rbasak> AFAICT, there is a solution, the build isn't picking it.
<infinity> rbasak: If all those deps reported on the nbs report are actually || deps, we can remove the package.  I'll look.
<infinity> rbasak: The build has no reason to pick the other option until the first is gone.
<xnox> rbasak: nothing wrong with apache2 package, instead the reported should follow apache2.4 guidelines on how to port modules / extensions / webapps.
<infinity> Sleep didn't work out for me anyway. :/
<rbasak> :-/
<infinity> rbasak: And, the first hit there is broken.  libapache2-authcookie-perl build-depends on apache2-prefork-dev, clearly still needs transitioning.
<infinity> I imagine the rest are similar.
<xnox> rbasak: nothing should build-dep on apache2-frefork-dev with apache2.4, as that will not work with new style packaging.
<rbasak> I don't understand this fully. Why is a package that build-depends on something that is now a virtual package broken?
<xnox> commented on the bug report.
<cjwatson> There's a Provides, so only ones with versioned build-deps must be transitions
<cjwatson> ed
<rbasak> Thanks xnox
<cjwatson> But when I last looked at that in NBS, there was at least one versioned build-dep still in place
<infinity> rbasak: It's a real package too, until we remove it.
<cjwatson> And Provides doesn't satisfy versioned relationships
<rbasak> Ah
<infinity> cjwatson: oh, I didn't realise apache2-dev now provided it.
<infinity> That helps a little bit.
<xnox> rbasak: i was trying to say, that even if apache2-dev would be installed i daubt the package would build anyway =)
<rbasak> xnox: right, I got that part :)
<xnox> =) ok.
<rbasak> I was just confused by the build-dep breaking things
<infinity> So, mod-mime-xattr has a versioned build-dep.
<rbasak> Or more that the archive state broke the build-dep even though it looked OK to me. I didn't understand that provides couldn't provide it in this case.
<cjwatson> The package in that bug will very likely need transitioning, certainly, so I'd be inclined to agree with that not being a valid bug in apache2 even though we should sort this out.
<infinity> rbasak: Provides can't provide versioned build-deps (so mod-mime-xattr needs fixing), and while provides sure can provide apache2-prefork-dev, the real package (that's still in the archive) will be preferred.
<cjwatson> No properly transitioned package is affected by this.
<infinity> But odds are that everything on the NBS list needs transitioning to the new world order anyway.
<infinity> Oh, as Colin said.
<rbasak> I follow now. Thanks!
<rbasak> xnox: could you respond to bug 1206114 please? I get the impression that: 1) removing the old binary won't help anyway, since he's using a versioned dependency; 2) we don't seek compatibility between release in this way, instead preferring to fix the packages; 3) if he wants that change, he should petition the Debian maintainer; but I'd prefer someone else to tell me that I'm being accurate.
<ubot2`> Launchpad bug 1206114 in apache2 (Ubuntu) "Package apache2-prefork-dev broken in Saucy" [Undecided,New] https://launchpad.net/bugs/1206114
<infinity> rbasak: Done.  I may have been a bit harsh, but his tone rubbed me the wrong way. :/
<doko> infinity, do you take care about the other binutils-gold issues too?
<infinity> doko: I haven't started looking at reverse-build-conflicts yet (other than rebootstrapping fpc, which I already did, and fixing glibc), but that's next on my list.
<infinity> doko: And I need to make yade no longer ftbfs for that one to be fixed.
<infinity> Hopefully, the build-conflict list isn't terribly long.
<infinity> doko: I know we're also carrying some deltas in some KDE packages to remove -fuse-ld=gold because it was previously not understood.  Now that we're carrying that patch to gcc, we can back those out, but I need to find them (not critical, though, they'll just keep building with bfd, which works fine).
<doko> thanks. binutils-gold wasn't very helpful with cross builds either
<infinity> doko: Were you planning on backporting the -fuse-ld patch to previous GCC versions too, or have it only work in >= 4.8?
<doko> it should be there
<infinity> Oh, cool.  I hadn't checked.
<doko> but distro specific
<infinity> Yeah, I know gcc-4.7 used to choke on the option, but RH carried the patch in their 4.7
<infinity> Which is why I asked.
<infinity> (saucy-amd64)root@cthulhu:~# zgrep '^Build-Conflicts:.*binutils-gold' /var/lib/apt/lists/*Sources | wc -l
<infinity> 21
<infinity> I guess that's not unmanageable.
<infinity> doko: Erm, most of them are yours: http://paste.ubuntu.com/5933849/
<rbasak> infinity: thanks
<infinity> doko: gcc-4.8 being a false positive because it's wrong in -release but fixed in -proposed, but I suspect all the rest still need fixing.
<infinity> And Laney's already fixed xpdf.
<doko> yes, the cross packages are not a priority for now
<infinity> Sure, just pointing out that other than a few stragglers (and I'm chasing them all down), the rest are GCC or based on GCC packaging.
<infinity> But I'll make sure all the !gcc stuff is fixed.  The others will annoy you in the next rebuild test if you forget to fix them before then. ;)
<sergiusens> Ursinha: hey, long time no talk! I have a launchpad question for you, why can't I link https://launchpad.net/phablet-image-info/i9100/+setbranch to https://code.launchpad.net/~i9100-image-dev/phablet-image-info/i9100
<Ursinha> sergiusens, hey, let me see
<Ursinha> sergiusens, wild guess: it seems that project isn't set to use codehosting in launchpad (which is weird because you have branches there hehe)
<Ursinha> sergiusens, are you admin of that project?
<sergiusens> Ursinha: dholbach is I think...
<sergiusens> Ursinha: oh, I am admin
<ogra_> sergiusens, haha
 * ogra_ has a deja vu ... i had the same moment of surprise this morning
<sergiusens> ogra_: wanted to do the same thing?
<sergiusens> :-)
<ogra_> heh, no, but discovered that we're all admins
#ubuntu-release 2013-08-01
<infinity> cjwatson: Hrm, did someone fix something, eglibc triggered a LOT more than 19 tests this time.
<cjwatson> infinity: Not I
<infinity> jibel: Is there a way for mortals to retry autopkgtest runs?
<jibel> infinity, yes there is, you will need a VPN Access to the QA Lab, then go to http://10.98.0.1:8080/view/Saucy/view/AutoPkgTest/ , select the job you want to restart and click on "Build"
<jibel> (if jenkins UI can be considered for mere mortals)
<infinity> Yeah, I'm not sure that internal Canonical VPNs count as "mere mortal" access for a community project. :P
<infinity> But I'll get access to that sometime.
<infinity> jibel: For now, can you retry eglibc/i386?  That failure is probably a timing issue with kvm being crap.
<infinity> (And certainly isn't due to any changes in the source)
<jibel> infinity, eglibc restarted
<infinity> jibel: And the chromium-browser failures look suspiciously more infrastructure related than packaging related.  Though, it's hard to tell.
<jibel> I'll look at chromium, qengho sent me an email about it last night.
<xnox> what's the minimum delay between: dput ftp-master and package appearing in launchpad.net/debian/+source/package (and thus available for syncing)? or shall I be naughty and dput the same .dsc into ubuntu as well
<StevenK> xnox: The source has to be published in Debian, the mirror pulse has to occur to ftp.uk, then LP's mirror has to update and finally we have to scan it and import new sources.
<StevenK> So, it's like six hours or something
<xnox> StevenK: ok, my current strategy is to write down a post-it note for the next day. I need to think of something better. I wonder if syncpackage can accept md5sum of the dsc to sync, and thus I could just cron it.
<StevenK> xnox: You can probably check for existance via the API every hour or something
<StevenK> You know the details
<xnox> StevenK: sure. thanks. At least I know the ballpark delay now.
<StevenK> xnox: Six hours might be the median delay, I'm not sure.
<cjwatson> I think it's near the upper limit.
<cjwatson> (Now.  Things used to be misaligned so it was worse.)
<StevenK> I remember sitting down with bigjools a while ago and changing the times so they were after dinstall not an hour beforehand.
<cjwatson> https://code.launchpad.net/~cjwatson/launchpad/series-alias/+merge/178103   that was rather harder than I expected
<infinity> cjwatson: You keep picking the "easy" tasks that take hundreds of lines to solve...
<cjwatson> Yes, quite
<jibel> infinity, eglibc is back to green
<infinity> jibel: \o/
<xnox> 6 hours on the dot since debian accept email to http://pad.lv/d/abi-compliance-checker i wonder if I had impeccable timing =)
<xnox> \o/
<didrocks> xnox: isn't it? :)
<ogra_> bah ... someone synces debootstrap
<ogra_> *synced
<cjwatson> What's wrong with that?
<cjwatson> I did.
<cjwatson> (And then the auto-syncer did.)
<ogra_> cjwatson, that my chromebook uses  raring and i have to pull it manually :) ...
<ogra_> no worries ... i'm just pointlessly moaning :)
<cjwatson> saucy chroot?
<cjwatson> Or upgrade to saucy, surely it just works :)
<ogra_> yeah
<ogra_> but then i lose my hacked up graphics driver config ... getting unity to run in the chromebook isnt easy
<ogra_> i just wget'd and installed it
<infinity> cjwatson: Does something magical need to happen for a retried test to be noticed by britney, or should I just force past it (the retry was successful).  In this case, eglibc.
<knome> SRU team, can you look at bug 1207493?
<ubot2`> Launchpad bug 1207493 in xubuntu-docs (Ubuntu) "Documentation does not match shipped system version (11.10 shipped with 12.04)" [High,New] https://launchpad.net/bugs/1207493
#ubuntu-release 2013-08-02
<jbicha> could you retry the gtk+3.0 and gvfs autopkgtests? apparently they were triggered before the i386 gtk+3.0 binary had been fully published
<jbicha> and notify-osd, software-properties, evolution-data-server
<xnox> Can ubuntu-themes please let through? it's being held by firefox autopkgtest that is failing
<xnox> autopkgtest for firefox 23.0~b10+build1-0ubuntu1: FAIL
<xnox> Please de-new multi-arched tcl8.6 (following suite of the default tcl8.5) https://launchpad.net/ubuntu/saucy/+queue?queue_state=0&queue_text=tcl
<cjwatson> infinity: Retries *ought* to be collected automatically
<cjwatson> Hm, gtk+3.0 doesn't seem to have been though
<cjwatson> jibel: ^- Do you know why adt-britney still thinks gtk+3.0 is running?
<cjwatson> There's a .result file with a pass at the proper version, AFAICS
<jibel> cjwatson, I think I fixed gtk+3.0 earlier this morning, the only running I see in excuses are
<jibel> autopkgtest for postgresql-9.1 9.1.9-2bzr1: RUNNING (Jenkins: public, private)
<jibel> autopkgtest for php5 5.5.1+dfsg-1ubuntu1: RUNNING (Jenkins: public, private)
<jibel> for tzdata
<jibel> cjwatson, where do you see gtk+3.0 is running?
<jibel> s/I think//
<cjwatson> $ cat saucy-proposed_amd64_gtk+3.0; echo
<cjwatson> {"status": {"i386": "RUNNING", "amd64": "RUNNING", "all": "RUNNING"}
<cjwatson> [...]
<cjwatson> in ~ubuntu-archive/proposed-migration/autopkgtest/data/adt/saucy-proposed/amd64/
<cjwatson> And in excuses, gtk+3.0 is listed as FAIL, which is also wrong but differently
<cjwatson> The most recent test at that version passed and that was several hours ago
<cjwatson> chrisccoulson: Any chance of either fixing or removing the firefox autopkgtests?
<cjwatson> xnox: firefox tests forced for now
<xnox> cjwatson: thanks.
<seb128> cjwatson, on -devel earlier: <chrisccoulson> seb128, jibel, i can't reproduce it here. and from looking at the log, it doesn't look like it even gets to the point of starting the test harness
<infinity> cjwatson: The retry for eglibc doesn't seem to have been picked up, it's still FAIL.
<chrisccoulson> seb128, cjwatson, see last comment in #ubuntu-devel ;)
<xnox> https://jenkins.qa.ubuntu.com/job/saucy-adt-ubiquity/128/ARCH=i386,label=adt/console is very odd, it failed, but it is testing 2.15.13 adt tests against 2.15.12 installed package.
<xnox> which is expected to fail, but obsolete package version is being tested.
<xnox> jibel: cjwatson: ^ mirror delays again?!
<cjwatson> xnox: not my fault
<jibel> xnox, it's my fault. I'm stepping through the workflow to find where it should wait, and where test states get out of sync
<ogra_> Setting up python3.3-minimal (3.3.2-3ubuntu1) ...
<ogra_>   File "/usr/lib/python3.3/site.py", line 232
<ogra_>     if hasattr(os, "getgid") and hasattr(os, "getegidify         # check process gid == effective gid
<ogra_> hmfp ...
<ogra_> (last ubuntu touch image build ^^^)
<ogra_> weird, and there were no changes to python
<cjwatson> ogra_: it's obvious panda damage again
<cjwatson> just retry
<ogra_> yeah, i'm not sure if i shouldnt ask for a reboot first
<cjwatson> I wouldn't bother
<ogra_> k
 * ogra_ retires
<cjwatson> I was actually just in the process of catching up on #ubuntu-touch to see if you were already discussing this before telling you
<cjwatson> infinity: How goes the Calxeda install, anyway? :)
<ogra_> ++
<ogra_> :)
<infinity> cjwatson: See #is.
<cjwatson> Hm, right
#ubuntu-release 2013-08-04
<phillw> Hi good people, is apt-get easy link for such areas as https://help.ubuntu.com/community/RestrictedFormats going to be made working again, or do we need to remove it from the wiki pages and use the terminal command only?
<stgraber> phillw: that's not an #ubuntu-release question so you're unlikely to get an answer here
<phillw> stgraber: as it was answered here last time with words to the effect "It's broken and not really going to get repaired", where should I ask?
<stgraber> phillw: #ubuntu-devel or whoever actually works on that feature (maybe the software-center folks?)
<phillw> stgraber: thanks, I'm wearing my 'wiki head', if the page needs changing, it will be done. I'll go ask on #ubuntu-devel. As ever, thank-you for time in answering.
#ubuntu-release 2014-07-28
<zequence> Hi. Could someone help me understand why ubuntustudio-meta has been stuck in -proposed for such a while?
<zequence> I tried installing it, and it seemd to work fine
<zequence> The Ubuntu Studio ISO is failing to build without our updated meta
<zequence> ..ah, libav needs to be promoted first
<zequence> or?
<zequence> Am I reading this correctly? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntustudio-meta
<xnox> zequence: yes, we are still battling with libav migration - see updates on ubuntu-release about the progress on that.
<xnox> (mailing list that is)
<zequence> xnox: Thanks
<cjwatson> zequence: Right, please don't mess with this for the moment :)
<cjwatson> zequence: The full gory details are in update_output.txt (update_excuses.html is just the first stage), but can be a bit tricky to read.  See https://wiki.ubuntu.com/ProposedMigration
<Saviq> slangasek, hey, when you're around, we'd like to NEW qtmir and qtmir-android from silo 6 please
<jibel> infinity, are builds of Precise images disabled? there is no new build since last week (22nd)
<mvo_> could someone please reject the update-manager in the precise-proposed queue (.17 ?) I need to do another update
<infinity> jibel: Ahh, yeah, they were disabled to avoid contention with trusty.  I'll turn 'em back on this morning.
<jibel> infinity, thanks!
<infinity> cjwatson: Don't forget a new grub2-signed to match that grub2 in precise.  Doesn't look like that's been consistently happening.
<cjwatson> Right, will sort that out today
<infinity> cjwatson: How would you feel about switching to the kernel method of versioning there (ie: signed is identical to unsigned, and then can magically build-dep and fail hard when not built against the right version)?
<infinity> cjwatson: I know your original intent was to allow iterating signed indepedently, but I suspect the days of fine-tuning the packaging are over.
<infinity> cjwatson: And it's way less confusing to see if they match by checking versions instead of build logs or upload dates.
<infinity> (or binary versions, I guess, since you encode it there)
<cjwatson> I'd be fine with that, but I don't really want to go reorganising it today
<cjwatson> (i.e. lack of time)
<infinity> Oh, yeah, I didn't mean go do that or I won't accept your upload. ;)
<infinity> It was more me volunteering to change it if you didn't object.
<cjwatson> If you're feeling enthusiastic then by all means please do
<cjwatson> We can always iterate independently by appending something, if we need to
<infinity> cjwatson: I can make the version parser stop at a "+", so if we really need to iterate, it would ignore +1
<infinity> ... assuming grub2 never has + in its version.
<cjwatson> Not very safe
<cjwatson> (It has in the past)
<cjwatson> But you could make it stop at "+signed"
<cjwatson> (say)
<mvo_> thanks infinity
<stgraber_> slangasek: I delegated testing and release of Edubuntu 14.04.1 to highvoltage so no, I wasn't planning on being around for it (I was actually offline up until about an hour ago)! :)
<highvoltage> stgraber: there wasn't any problems with the release, at least
<highvoltage> stgraber: you probably should just sync the new image to your server so that I can add it back on the downloads page again
<stgraber> highvoltage: oh right, I'll do that later today. Thanks for taking care of everything else!
<highvoltage> stgraber: np, we should take some time to discuss 14.10 again when you've caught up and we both have some time
<mvo_> could someone please approve xorg-lts-transitional from precise-proposed to precise-updates? not having it breaks lts upgrades from 12.04+hwe-trusty and it just adds a bunch of transitional packages
<barry> infinity: looks like zope.security is still not getting promoted :(  i suppose i botched the transition of python-zope.security-untrustedpython, but how can we fix or override that?
<infinity> barry: Lemme look.
<infinity> barry: Oh, pitti never removed the NBS from -proposed.
<barry> infinity: ah
<infinity> Fixing.
<infinity> barry: Should be okay after a publisher run.
<barry> infinity: awesome, thanks
 * infinity goes to lie down for an hour, not feeling so hot this morning.
<arges> cjwatson: hello. rtg is looking for help getting the linux uploads in the utopic new queue accepted. I don't mind doing it, but just wanted to ask if there was anything specific I need to check before clicking accept.
<ScottK> IIRC overrides on kernel uploads are special.
<ScottK> infinity would know as well.
<xnox> arges: are you archive admin these days as well?
<xnox> arges: i thought you were SRU only.
<xnox> so you are. =) interesting.
 * xnox notes down to bug arges next time =)
<arges> xnox: well, its only for limited cases (kernel stuff), not for general use
<cjwatson> arges: Use kernel-overrides from u-a-t
<cjwatson> Beyond that it's pretty turnkey
<arges> cjwatson: ok so the linux* binaries here: https://launchpad.net/ubuntu/utopic/+queue?queue_state=0&queue_text= . I click accept, then I need to change-override them back to main
<arges> ( just reviewing so i don't mess it up
<cjwatson> No no no no no no no
<cjwatson> Use kernel-overrides first
<arges> cjwatson: this is why i asked. Ok so which kernel-overrides options, should i be using. Or are the defaults setup to target new uploads in the development queue?
<cjwatson> Right, so for ordinary kernels in utopic you basically just want "kernel-overrides 3.14.0-1" or whatever the new ABI is
<cjwatson> It'll print a bunch of dots as it works through the existing overrides and copies them over
<cjwatson> Then I'd suggest "queue info linux | less" and make sure everything's in main
<cjwatson> Then "queue accept linux"
<cjwatson> You need different options to k-o if you're dealing with a source package other than linux, or for other series
<arges> cjwatson: makes sense. In this case I think I got it. I'll take care of this one then
<arges> Thanks
<cjwatson> Cool, thanks
<cjwatson> oh yes of *course* now there's a protobuf-c transition as well
<cjwatson> it was in danger of being too simple
<doko> =)
<xnox> cjwatson: i'm doing abiword / libwps+friends
<xnox> cause i think that's in the mix now as well.
<cjwatson> Isn't that just held back by autopkgtests or similar?
<cjwatson> Ah, no, I see
<doko> cjwatson, any particular package you want some help?
<cjwatson> doko: I don't think there's too much left now ...
<cjwatson> Just this libwps/etc. stuff, and I'm fixing criu and crtools
<doko> ok, looking at libps
<doko> wps even
<barry> infinity: \o/ zope.security (4.0.1-1ubuntu2) utopic; urgency=medium
<cjwatson> doko: well, xnox said he was doing those ...
<doko> oh, fine
<xnox> doko: well i'm deep in abiword, you can pick something else. E.g. inkscape, or like libreoffice no change rebuild.
<doko> going back to toolchain issues
<xnox> =))))
<cjwatson> we need a libreoffice build?!  ffs
<cjwatson> hate hate
 * xnox failed at tricking doko into libreoffice TIL
<xnox> ISO C++ forbids declaration of 'parameter' with no type  =>>>> well, can't you just do it anyway please?! =)
<slangasek> Saviq: silos bypass the NEW queue (which is a bug), which is why I pre-reviewed the qtmir packages and signed off on them
<cjwatson> slangasek: only for binaries
<doko> xnox, I'm behind that =)
<slangasek> ah
<slangasek> Saviq: then what cjwatson said; in which case someone needs to upload it so I can process it in NEW? :)
<Saviq> slangasek, yeah, we need it to be in distro before the silo lands anyway, as we need a new ubuntu-touch-meta
<cjwatson> haha, good luck with that
<cjwatson> that's now blocked on the megatransition of doom
<slangasek> mm? "in distro before the silo lands"?
<cjwatson> oh wait maybe it isn't
<slangasek> what's the megatransition of doom?
<cjwatson> just a dependency removal, shouldn't get stuck
<cjwatson> libav etc.
<Saviq> slangasek, we need a new seed, which can only be built after qtmir{,-gles} is in the archive
<xnox> slangasek: gnutls, libav, wps, cdr, libwpg, libvisio, libwps, and so on and so worth
<Saviq> slangasek, I was thinking you guys could just bincopy from silo
<cjwatson> Saviq: that's what publishing a silo is
<slangasek> Saviq: "you guys" - that's exactly what the citrain does, why does the "publish" button not work here for you?
<Saviq> slangasek, it does, just didn't want a separate silo, but if that's what we need then we just need a bincopy into a different sil
<Saviq> o
<Saviq> and land that
<cjwatson> why do you need a separate silo?
<cjwatson> you can build extra stuff in a silo even after it's published
<cjwatson> or if it's just ubuntu-touch-meta, that's usually just uploaded directly anyway
<Saviq> cjwatson, but I can't land the silo before I get new ubuntu-touch-meta in there, which I can't generate before qtmir is in archive
<cjwatson> well sure you can
<slangasek> Saviq: why can't you land the silo?
<cjwatson> you can just make the changes by hand
<Saviq> cjwatson, right, that I can do
<cjwatson> or you can temporarily point update.cfg at a PPA in addition to the archiv
<cjwatson> nothing wrong with that
<cjwatson> e
<Saviq> cjwatson, hmm I was told otherwise
<cjwatson> you were told wrong
<Saviq> ok then, let's see
<cjwatson> just make sure to undo the update.cfg change before building the source package
<cjwatson> personally I'd probably just edit the relevant files directly and make sure it all matches, but either way
<slangasek> I also still don't see why you need to update the meta package to land the other pieces
<slangasek> if landing this breaks the image because some essential component will fall out of the image, then something other than the metapackage should surely have been depending on it
<cjwatson> Yeah
<cjwatson> I was assuming that you just needed a metapackage addition in order to test the whole thing; but yes, if it's for the reason slangasek suggests, then that would be a bad reason
<Saviq> cjwatson, slangasek, so... this whole situation is because of the -android and -desktop packages that are built from qtmir and qtmir-gles (there's a respective problem with qtubuntu as well)
<Saviq> cjwatson, slangasek, neither is really a good default, as it depends on where you install
<slangasek> ok
<slangasek> so the metapackage is used to pick the default
<Saviq> slangasek, yes
<slangasek> yeah, that's reasonable
<cjwatson> xnox: Actually, libwps etc. is a separate transition, amazingly
<slangasek> sorry for being slow on the uptake
<cjwatson> xnox: IF you don't entangle it by uploading anything else
<Saviq> slangasek, no worries, I had to clear my head on that as well
 * Saviq prepares a meta
<cjwatson> xnox: I think this all has some chance of clearing once criu and crtools are built and once p-m notices the re-run marble autopkgtest
<xnox> cjwatson: calligra not in it?
<cjwatson> Oh, maybe it is
<cjwatson> Of course, calligra is hidden by the marble failure
<cjwatson> How depressing
<xnox> we really should tackle this mess with full force. cause it's been way too long.
<cjwatson> Yeah, we should get this done before a2 freezes otherwise the probability of success diminishes further
<cjwatson> I'll see if I can no-change rebuild libreoffice somehow
<ScottK> Did librevenge get promoted?
<xnox> ScottK: looks like it's in main to me.
<cjwatson> Yeah
<cjwatson> calligra builds now, it's just stuck on other things
<cjwatson> The recent KDE update didn't help
<xnox> abiword uploaded, taking inkscape
<xnox> doko: did you just DDOS all buildds, thus it's pointless in trying to resolve this migration of doom?! =)
<slangasek> DDOS how?
<xnox> slangasek: all gcc's got uploaded or something.
<ScottK> At least three.
<xnox> thus my humble universe uploads are to start never =)
<cjwatson> digikam uploaded (for megatransition)
<infinity> arges, cjwatson: kernel-overrides is obsolete as of precise (at least for master), all the bianries are in main, all the time.
<cjwatson> well it potentially fixes section and priority ...
<infinity> Which also means the queue gets it right for Tim's uploads to the archive.
<arges> infinity: i was wondering why they were all already in main
<infinity> cjwatson: If section and prio are wrong, I make Andy and Tim fix it in the packaging. ;)
<cjwatson> there is that
<arges> infinity: did running kernel-overrides break anything then? or was it a noop?
<infinity> arges: I'm assuming it told you what it was doing.
<infinity> I haven't used it literally in years, I don't recall what it does.
<cjwatson> no-op at worst.
<arges> Yea, it didn't mention much other than the names/versions of the packages and printing some dots on the screen. But checking queue info showed that they were still in main before and afterward
<arges> infinity: so I assume that I forgot to accept the linux-signed package, and you just did that?
<infinity> arges: Aye.
<arges> noted
<xnox> britney is useless with all the arch-skew, so hopefully powerpc catches up by tomorrow.
<infinity> xnox: Err, really?  Building libreoffice with bundled libs? :(
<infinity> xnox: That's not how you transition.
<xnox> infinity: just the mini small ones. Sweetshark has rc4 ready which builds those as system shared libs.
<xnox> infinity: but it FTBFS at the moment.
<xnox> infinity: and we want to transition the doom pile, preferably without fixing new libreoffice upstream FTBFS.
<infinity> xnox: I don't want anyone to take this as a cue to start doing that more.
<infinity> xnox: Why couldn't libreoffice have just rebuilt against the current versions of those libs?
<infinity> xnox: It's an upload either way.
<xnox> infinity: because next upstream release was ported and tested against the new versions, 4.2 was not.
<infinity> Feh.  Well, that new upstream better come along soon.
<xnox> infinity: it was meant to be ready last week, but slipped into this week instead.
<xnox> infinity: but colin and I hope to get the transition of doom in before alpha2 freeze =)
<xnox> and hence without 4.3 final.
<xnox> the longer we keep this mess the more smaller transitions get intertweened into it.
<infinity> xnox: I'm going to cancel that LibO PPC build and aim it at sagari later.  Don't panic when you get the fail mail. :P
<xnox> infinity: alright, thanks. I'll go back to reading 50 shades of gray
<infinity> ...
<infinity> Don't.  It's awful.
<infinity> Not the content, but the grammar.
<cjwatson> xnox: I'd suggested skipping the NBS for now; did you miss that message?
<infinity> Well, the content is laughable too.
<cjwatson> laughable and abusive.
<cjwatson> infinity: are you aiming LibO at sagari now?  I see it on manual
<infinity> cjwatson: Yes.
<cjwatson> ok, thanks
<xnox> infinity: cjwatson: well, I found quotes from the parody funny and even the parody will get the movie (50 sheds of gray) and i'm sure i'll be dragged into watching them all, so i figured i should read them.
<xnox> cjwatson: skipping the NBS would help, but it might all migrate by itself tomorrow or just require smaller things to be built.
<slangasek> 50 sheds of gray?  Are these bikesheds?
 * skellat remembers he was once a librarian and worries over the state of "literature" these days
<RAOF> Gah! The version of gnome-do in 14.04 fails to build from source :(
<bluesabre> gnome-don't
<bluesabre> :)
<cjwatson> Hm, autopkgtest execution queue rather backed up
<slangasek> so what's the right way to fix the seed interdependencies?
<cjwatson> Ideally, this should be detected at runtime rather than relying on fragile alternatives
<cjwatson> I'm not sure how this can be fixed at the seed level
<slangasek> no way to make touch-core inherit from desktop|touch-android, then :-)
<cjwatson> Not so much :)
<xnox> slangasek: https://twitter.com/50ShedsofGrey   for quotes.
<xnox> RAOF: i did mention that in malta.... =)
<RAOF> xnox: I clearly forgot :/
#ubuntu-release 2014-07-29
<xnox> "I've stopped using it, once it started to perpetually FTBFS with new monos"
<RAOF> Of course, some of this was because the 0.95.1-1 upload which fixed this sat in pkg-cli-apps git for 6 months waiting to be uploaded.
<RAOF> I probably responded that I'd fixed that.
<RAOF> Just hadn't shepherded it through to the distro :(
<xnox> =(((((((((
 * RAOF wonders what others think about a 0.95.1 âSRUâ :)
<slangasek> RAOF: sorry, your project begins with "g" and "o", but there are too many letters in the middle for us to sign off on this SRU exception
<slangasek> and ends with "o", I mean
 * xnox thinks of no SRUs for odoo -> yes!
<infinity> slangasek: ^
<infinity> cjwatson: ^--- And this one's for you.
<slangasek> infinity: there ya go
<ginggs> arges, RAOF: nvidia-graphics-drivers-* have been sitting in Trusty unapproved queue for some time now, would someone take a look, please?
<xnox> soyuz rejected https://launchpad.net/ubuntu/+source/llvm-toolchain-snapshot/1:3.5~svn213451-1ubuntu1/+build/6211716 and i don't understand why =(
<cjwatson> https://launchpad.net/ubuntu/utopic/i386/clang-3.5
<xnox> oh.
<xnox> right.
<wgrant> Yeah, that.
<cjwatson> looks like doko synced over the top of your change
<cjwatson> so then retrying wouldn't have worked
<xnox> i think llvm-toolchain-snapshot should be removed then, no?
<xnox> (until at least a 3.6 snapshot is available)
<cjwatson> oh a different source is it
<cjwatson> dunno
<xnox> i guess it will just end up in nbs, cause llvm-toolchain-3.5 package version are >> llvm-toolchain-snapshot.
<xnox> here it comes!
<doko> xnox, are you working on llvm-toolchain-3.5?
<xnox> doko: yes, i'm compiling one on porter now.
<doko> xnox, please disable lldb on ppc64el
<xnox> enabled gold, disabled lldb since clearly broken.
<xnox> doko: yes =)
<xnox> built, tests running & docs building
<doko> ^^^ please could somebody review this?
<arges> ginggs: i can take a look
<cjwatson> infinity: ^-
<infinity> Ta.
<ginggs> arges: thanks!
<arges> ginggs: so i actually started taking a look at it, I'm not much of an expert on nvidia packaging etc. Reading up there was some concern about multi-arch aware issues, is that still a problem?
<arges> ginggs: and also should bug 1317528 be a duplicate of 1247736 ?
<ubot93> bug 1317528 in nvidia-graphics-drivers-331-updates "Packages nvidia-libopencl1-... don't provide libopencl-1.1-1 and libopencl-1.2-1, making some packages uninstallable" [Undecided,Confirmed] https://launchpad.net/bugs/1317528
<ginggs> arges: no, we need to add libopencl1-1.1-1 at some point, but right now there is nothing in the archive that needs libopencl-1.1-1 to be installable
<doko> arges, ginggs: while you are at it ... there is acomponent mismatch in this package, bumblebee
<ginggs> doku: i don't follow
<arges> doko: i wish i knew more about nvidia/bumblebee stuff, but I was merely reviewing the nvidia-graphics-drivers-* update in the SRU queue : )
<jamespage> can someone explain to me why the mongodb upload I did for utopic is still in proposed? it looks OK from the migration_excuses report...
<cjwatson> excuses is just stage one
<cjwatson> update_output.txt says:
<cjwatson> trying: mongodb
<cjwatson> skipped: mongodb (30 <- 34)
<cjwatson>     got: 39+0: i-39
<cjwatson>     * i386: mongodb, python-loofah
<cjwatson> meaning "the new version is uninstallable" (and so is python-loofah, but that's probably just because it Depends: mongodb)
<cjwatson> Quite why that is I'm not completely certain
<jamespage> cjwatson, ah
<rbasak> jamespage: mongodb 1:2.6.3-0ubuntu3 depends on mongodb-dev, which was built by mongodb but is no longer, and doesn't exist in utopic-proposed. I'm not sure if that's intended; could that be your problem?
<rbasak> Or would mongodb-dev end up NBS but still in Utopic?
<cjwatson> Oh, mongodb-dev went away?  Right, that would explain it
<cjwatson> While a migration would cause NBS to remain until manually cleared, proposed-migration defaults to assuming that all NBS are cleared when calculating its answers
<rbasak> Useful to know - thanks
<cjwatson> Occasionally we'd override that.  Generally I prefer not to
<arges> cjwatson: hey, how does the urgency field affect uploads in Ubuntu? i'm reviewing a package (nova) where the patch modifies the urgency from medium to high... should i reject and ask for it to remain the same?
<cjwatson> arges: negligible
<xnox> arges: it gives a tiny build score bump. Each urgency is per upload, so only the top one matters. The default these days is medium.
<cjwatson> it makes like a tiny difference to the build priority
<cjwatson> I don't see why you'd patch this, though
<cjwatson> The urgency is per-changelog-entry
<cjwatson> You wouldn't patch an old one
<arges> i guess from an SRU perspective should I ask that it be changed back to 'medium' before accepting?
<cjwatson> no
<cjwatson> as long as it's an entirely new changelog with urgency=high, who cares
<cjwatson> I might whinge about patching an existing changelog entry
<arges> yea, its only in the new entry
<infinity> I've uploaded SRUs with urgency=critical
<infinity> arges: So, if it's in the new entry, it's not being "changed", that's just the urgency set for that specific upload.
<infinity> arges: Nothing wrong with that, even if it's a feature LP users almost never use.
<arges> Ok
<arges> thanks!
<Laney> I'm pushing the freeze block a bit earlier than I said because I'm going out for dinner here at GUADEC
<cjwatson> no skin off my nose, we got libav in ;-)
<Laney> I got the migration emails - good work :-)
<cjwatson> update_output is in danger of making sense again
<Laney> respins going
<Laney> stgraber: I forgot if I have to update the manifest or not
<cjwatson> looks like rebuild-requests does everything in parallel - good
<Laney> stgraber: Would you be able to do that for me if so? Nobody replied so assuming the same as A1
 * Laney is off, ttyl
<stgraber> Laney: if it's the same as a1, no changes are needed to the manifest
<slangasek> that's some rapid-fire NEWing
<slangasek> is that intentional?
<cjwatson> I don't know about qtmir/qtmir-gles.  For binaries I routinely wave through new binaries from Debian syncs
<cjwatson> With basically just a cursory override check and a bit of automation to ensure they're really from Debian
<slangasek> right
<slangasek> baloo-kf5, python-idna, qtmir were accepted near-simultaneously though
<slangasek> and were not Debian syncs
<phanimahesh> Any idea why http://changelogs.ubuntu.com/meta-release-lts hasn't been updated with 14.04.1?
<phanimahesh> Prolly everyone's asleep, hoping someone will pick the message.
<phanimahesh> teward, mhall119: Pinging you to make sure someone gets the message, you're one of the few faces familiar to me here. Please look at it when you guys wake up.
<mhall119> thanks phanimahesh, I'll poke somebody about it
<robru> is anybody around to force unity-system-settings through despite the arch regression?
<Saviq> ubuntu-system-settings
<Saviq> FWIW â this only worked before because there was a missing Depends that would have caused this to happen some time ago already
<Saviq> and the reason is it depends (indirectly) on Mir, which is not available on the other arches
<phanimahesh> mhall119: nm, was doing routine sysadm tasks planning to upgrade and found that my servers aren't detecting new lts release. That led me there.
<phanimahesh> Thanks. :)
<Saviq> kgunn, our hands are tied, we need someone here to pick this up, /me logs off for dinner, back later to a hopefully resolved situation
<kgunn> Saviq: ta
<kgunn> and thanks for pointing out
<robru> stgraber, slangasek: anybody around? ^^
<slangasek> phanimahesh, mhall119: http://changelogs.ubuntu.com/meta-release-lts hasn't been updated because we're awaiting infinity's confirmation that we're ready to enable the upgrades
#ubuntu-release 2014-07-30
<pitti> hello all
<pitti> any idea why systemd is blocked for promotion? I closed the block-proposed bug yesterday (bug 1346199) as it's now ready to land and past traincon-0
<ubot93> bug 1346199 in systemd "Needs testing in -proposed: systemd 208" [High,Fix released] https://launchpad.net/bugs/1346199
<pitti> i. e. there's still a release team blocker for it
<pitti> oh wait, that's just the general alpha-2 freeze I suppose
<infinity> pitti: Self-diagnosing developers.  I like it.  We need more like you.
<pitti> infinity: you mean people with the nasty habit of only seeing the solution *after* asking? :-)
<pitti> 'cause that happens to me all the time, annoyingly
<infinity> pitti: That happens to all of us.  I think it's the act of asking that kicks the brain into better diagnostic modes.
<infinity> pitti: I'm almost positive cjwatson now has a habit if delaying any response to me by half an hour to make sure I actually want an answer, rather than just wanting someone to ask to trick myself into finding the answer. :P
<infinity> pitti: For me, I think it's the split second when I hit <enter> on a question where I think "wait, is this going to make me look like an idiot?... IT SURE IS", and then the answer comes to me.
<pitti> infinity: I'm glad I'm not the only one to embarass oneself :)
<infinity> cjwatson: base-files and livecd-rootfs could use a quick once-over for precise.
<infinity> stgraber: Or you, if you're around, since this is your point release.  Not sure what timezone you're in, or if you're around.
<cjwatson> let me delay that for half an hour so you can decide whether you really need them
<pitti> infinity: oh, and when would be a good time for my daily nag about postgresql SRUs?
<infinity> cjwatson: Lollerfrigginskates.
<infinity> pitti: Oh, perhaps nowish.  Which release(s)?
<pitti> infinity: lucid, precise, trusty
<pitti> IOW, "all"
<infinity> *nod*
<infinity> Looking.
<pitti> quite nice to have a time with no supported non-LTS releases :)
<infinity> pitti: Yeah.  Won't last.  But I guess it'll recur for the three month period after each LTS.
<pitti> ROLLING RELE*cough* *cough*
<infinity> pitti: Bad pitti.  No biscuit.
 * pitti sobs
<infinity> pitti: Hrm.  The 8.4/lucid warning probably belongs in NEWS, not changelog.  Also, it would be less sketchy if you suggested people upgrade to 12.04/14.04 before suggesting that, if they must run lucid, they upgrade to non-archive packages.
<pitti> infinity: ah, I thought of apt-listchanges
<pitti> infinity: but I can reupload with adding that to NEWS too
<infinity> pitti: The default apt-listchanges config only shows NEWS.
<infinity> pitti: People (like me, and probably you) have to actually reconfigure to show changelogs.
<pitti> "Consider upgrading to Ubuntu 12.04 LTS or 14.04 LTS, or upgrading to PostgreSQL 9.x from http://apt.postgresql.org/"
<pitti> better?
<pitti> FWIW, that's really the place that we send all people to who need backports; these are officialy supported by upstream, and maintained by Christoph and me with a nice CI and QA
<infinity> pitti: Yeah.  Or maybe even "Consider upgrading to PostgreSQL 9.x on Ubuntu 12.04 LTS or 14.04 LTS or, if you must stay on lucid, the PostgreSQL 9.x packages from http://apt.postgresql.org/"
<infinity> pitti: Since precise has 8.4 as well...
<infinity> pitti: I don't doubt that they're well-supported, but they still don't have our seal of approval, per se, plus any chance to get people off lucid is one worth taking. :P
<pitti> infinity: yeah, as an upgrade shim; in trusty, the equivalent postgresql-9.1 only builds -plperl, but we didn't think of that yet in precise
<pitti> heh, yes
<infinity> pitti: Also, don't want to seem too sky-is-falling about it.  No more upstream support and point releases, but our security team will still patch psql 8.4 until lucid EOL.
<infinity> pitti: Which is probably worth mentioning, so people don't panic.
<pitti> infinity: http://paste.ubuntu.com/7903085/
<pitti> proposed debian/postgresql-8.4.NEWS
<infinity> pitti: That looks reasonable, but I'd move the last line above the paragraph instead of below.  Good(ish) news before bad.
<infinity> pitti: I almost missed it, cause I wanted to stop reading halfway through the paragraph that implied I was no longer supported. ;)
 * infinity runs to the store for a beverage while you reupload.
<pitti> http://paste.ubuntu.com/7903102/ ?
<pitti> infinity: ^ better?
<pitti> infinity: ^
<infinity> pitti: Much better, thanks.
<infinity> pitti: And precise doesn't need the same warning?  Is the psql 8.4 there neutered to only be useful for upgrading?
<pitti> infinity: yes, when you upgrade to precise you get a big fat warning that 8.4 is unsupported and only for upgrades, and it's in universe
<pitti> infinity: pretty much the only requirement there is that the version number must be bigger than lucid's
 * infinity nods.
<pitti> so that you don't lose plperl after upgrades (darn libperl5.x not being installable in parallel)
<infinity> Eww, psql imports a copy of tzdata?
<infinity> Tell me it doesn't use that on Debian/Ubuntu.
<pitti> infinity: no, it doesn't
<pitti> infinity: we've configured with --system-tzdata (or so) for the last 10 years (or more?)
<infinity> Oh, good.  Cause gross.
<pitti> infinity: well, not all target platforms of postgresql have that, so it's a configure option
<pitti> (or provide updates to it regularly)
<infinity> Keeping on top of tzdata updates is the bane of my existence, I can't imagine trying to track embedded copies.
<infinity> pitti: In trusty, you drop 5 patches, but the changelog only explains 2 (or 3, I guess).
<pitti> -60-pg_regress_socketdir.patch
<pitti> -61-extra_regress_opts
<pitti> -62-pg_upgrade-test-in-tmp
<pitti> -63-pg_upgrade-test-bindir
<pitti> those are the four patches which explicitly used /tmp/ for pg_regress, which is now solved in a better way upstream
<pitti> the fifth is dropping 04-configure-tcl8.6 which has its own changelog entry
<infinity> Ahh, kay.  Reading the fourth hinted at that.  The naming just didn't imply it related to the changelog entry.
<infinity> Good enough for me.
<pitti> infinity: cheers!
<pitti> infinity: you're still looking at trusty/9.1, I suppose?
<infinity> pitti: Oh, no, didn't notice there were two trusty versions.
<infinity> pitti: Could be because you messed up the tasks on the bug. :P
<pitti> infinity: oui, je suis dÃ©solÃ©
<pitti> infinity: we always need the previous major version as an upgrade shim for -plperl (see above)
<pitti> so that you can use the pacakges from the old release for upgrading (but not install the old version any more)
<infinity> pitti: Done.
<pitti> cheers
<infinity> wgrant: Does anyone know Malone well enough to fix that bug/misfeature where deleting a series task from a bug means you can never re-add it?
<pitti> infinity: so for trusty the SRU verification is now a single "build" click in jenkins on the trusty-adt-postgresql-9.3 job; want this for older releases, too!
<pitti> well, lucid will EOL in 7 months, one less problem
<infinity> pitti: However you want to do your validation in a way that you feel would satisfy your MRE obligations and your users. :P
<wgrant> infinity: Hm, are you sure that's not fixed/
<pitti> infinity: well, running the postgresql-common test suite is what I do manually as well
<infinity> wgrant: Positive.
<pitti> infinity: there's nothing which requires particular brain powers about it
<infinity> wgrant: https://bugs.launchpad.net/ubuntu/+source/postgresql-9.1/+bug/1348176/+nominate
<ubot93> Launchpad bug 1348176 in postgresql-9.3 "New upstream microreleases 9.3.5, 9.1.14, 8.4.22" [Undecided,Fix committed]
<infinity> wgrant: Note the empty list.
<infinity> wgrant: But some tasks don't have all three series'.  In fact, none of them do.
<wgrant> infinity: So, I think there's a workaround, but it's slightly awful. Let me test on staging.
<pitti> oh, would it perhaps help to delete the stable tasks for all others as well, would it then reappear in +nomiate?
<infinity> pitti: No.
<infinity> pitti: Pretty sure I've tried that in the past.
<wgrant> It's a side effect of bug #110195.
<ubot93> bug 110195 in launchpad "Nominating a bug for a distro series affects all package tasks for that distro" [Critical,Triaged] https://launchpad.net/bugs/110195
 * wgrant is trying the workaround.
<infinity> wgrant: If the workaround is an API workaround, it's academically interesting, but mostly useless.
<wgrant> infinity: It's not.
<infinity> If you can coax the web ui into letting one re-add a deleted task, that would be interesting.
<wgrant> Come on staging, you can do it...
<pitti> an API workaround would work for fixing a particular bug, too
<infinity> pitti: Sure, I just mean in general, it's not something most people will do.
<pitti> *nod*
<infinity> For all its warts and weird design decisions, this is probably the only bug in Malone that really annoys me on a regular basis.
<infinity> The rest, I've just learned to live with, given an "at least it's not bugzilla" attitude.
<wgrant> OK, so there *is* a way through the UI, but it's not pretty.
<wgrant> The ability to renominate is restored if you delete a task for the target that you want to nominate.
<wgrant> Due to #110195, the target is always a DistroSeries, not a SourcePackage.
<wgrant> Since you have tasks for each relevant series on that bug, you could remove the package name from each task, delete its series task which is now on the DistroSeries rather than the SourcePackage, set the package name again, and then move onto the next package.
<wgrant> Eventually you'll have deleted a task for each DistroSeries, and all will be open for nomination.
<pitti> wgrant: happy to do that, if I don't end up with having no tasks at all
<wgrant> Heh, if we get into that situation then I'll just hack the DB :)
 * pitti takes a deep breath and tries
<wgrant> Just make sure that any task you delete doesn't mention a source package.
<pitti> ack
<pitti> wgrant: so, step 1 on bug 1348176: I should now be able to delete teh ubuntu/precise task, and get back precise nomination?
<ubot93> bug 1348176 in postgresql-9.3 "New upstream microreleases 9.3.5, 9.1.14, 8.4.22" [Undecided,Fix committed] https://launchpad.net/bugs/1348176
<wgrant> pitti: Yep.
<pitti> wgrant: thanks muchly, that worked!
<pitti> infinity: how does that look now? :-)
<wgrant> Comment #9 makes good use of the inline status changes...
<infinity> pitti: Much better!
<stgraber> infinity: I'm back to my usual timezone (if you can call it that), so back to Montreal. I assume you got all the reviews you wanted by now?
<infinity> stgraber: Yeahp.
<infinity> bdmurray: I think we're ready to flip the precise->trusty upgrde toggle.
<jibel> infinity, there is still bug 1348067
<ubot93> bug 1348067 in update-manager "update-manager crashed with TypeError: pulse() takes exactly 1 argument (2 given)" [High,In progress] https://launchpad.net/bugs/1348067
<jibel> for desktop users
<jibel> u-m crashes immediately when the user press 'upgrade'
<infinity> slangasek: ^
<infinity> bdmurray: Belay that...
<slangasek> hmm
<bdmurray> I just saw that on errors this morning
<bdmurray> seems only to effect 12.04 fwiw
<infinity> bdmurray: Any idea what's going on there?  mvo's abandoned us for a week. ;)
<bdmurray> I'll have a look
<bdmurray> infinity: there's an upload in the precise queue already for it
<bdmurray> https://launchpadlibrarian.net/180904636/update-manager_1%3A0.156.14.16_1%3A0.156.14.17.diff.gz
<infinity> Oh, shiny.  The bug didn't imply there was.
<bdmurray> infinity: really? 6. install update-manager from precise-proposed
<infinity> jibel: If I review and accept that, how soon can you turn around a verification?
<infinity> bdmurray: I assumed that was jibel being optimistic about a fix happening. :)
<bdmurray> heh
<bdmurray> I've put a link to the errors bucket in the bug too
<jibel> I can do that later today
<jibel> infinity, ^
<infinity> jibel: Awesome.  If you could verify the other two bugs fixed in the upload in passing (they looks simpler than your bug), that would be helpful to expedite it.  If not, we'll hunt someone else down.
<jibel> meh, I've a test VM ready with lts-trusty but not lts-saucy :(
<jibel> infinity, I'll do the verification too
<infinity> jibel: You're my hero.
<jibel> infinity, I verified the 3 SRU of update-manager in Precise. It's successful, for bug 1349400 I verified that *-lts-trusty:i386 replaced *-lts-saucy:i386 and there is a display after upgrade and a reboot. Steps 4 and 7 "verify that it work/doesn't work" do not mean anything.
<ubot93> bug 1349400 in update-manager "hwe-support-status --show-replacements needs to deal with multiarch libs" [Medium,Fix committed] https://launchpad.net/bugs/1349400
<doko> mlankhorst, online?
#ubuntu-release 2014-07-31
<slangasek> Laney: fyi, I'm unblocking init-system-helpers to get init de-essentialed, as this is causing issues for people debootstrapping.  It should have no impact on images, so I don't believe any respin is required
<infinity> jibel: Awesome, thanks.
<mlankhorst> doko: pong
<Laney> hrm, where are the lubuntu alternates?
<Laney> iso tracker thinks they are rebuilding
<Laney> but nusakan doesn't
 * Laney tries again
<ypwong> could anyone help to migrate ubuntukylin-default-settings 1.2.1 from proposed to release?
<ypwong> we'd like to build a new image based on this version.
<Laney> ypwong: you want this to be in alpha 2?
<ypwong> Laney: yes we want to use in alpha2, the current version is buggy
<Laney> this handling looks a bit shaky to me
<ypwong> 1.2.0 makes the image failed to build
<shadeslayer> cjwatson: any news of the Plasma 5 ISO ? :)
<cjwatson> shadeslayer: I sent you a message last night asking for a detail for that ...
<shadeslayer> ah yes, I just saw that, moment
<shadeslayer> https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/next
<cjwatson> right, thanks, let me see
<cjwatson> shadeslayer: which architectures?
<shadeslayer> cjwatson: amd64 and i386 please
<Laney> ypwong: do you think this feature is essential?
<Laney> PRETTY_NAME="Ubuntu Kylin Kylin Kylin Kylin Utopic Unicorn (development branch)"
<Laney> That's from reinstalling the package a few times :)
<cjwatson> shadeslayer: and this is a live CD format, and I can call it "kubuntu-plasma5"?
<shadeslayer> yep
<cjwatson> shadeslayer: is there already a task or metapackage or something?  where are the seeds?
<shadeslayer> seeds https://code.launchpad.net/~kubuntu-dev/ubuntu-seeds/kubuntu-plasma5.utopic
<shadeslayer> metapackage is kubuntu-plasma5-desktop
<Laney> where can I find evidence from the lubuntu alternate build I just ran?
<Laney> I don't see any output from it
<shadeslayer> link to dsc https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/next/+files/kubuntu-plasma5-meta_1.0%7Eppa7.dsc
<cjwatson> Laney: you running it directly on nusakan?
<Laney> yeah
<shadeslayer> I am unsure if there's a task in there, checking
<cjwatson> Laney: cdimage/log/lubuntu/utopic/
<cjwatson> shadeslayer: there won't be, but I'll use a metapackage
<shadeslayer> ok
<Laney> cjwatson: right, no log there for today
<cjwatson> only the primary archive gets tasks, so pretend I wasn't silly enough to mention that
<cjwatson> Laney: command line?
<shadeslayer> cjwatson: we're using the kubuntu-live task + kubuntu-plasma5-desktop for building ISOs on our side
<shadeslayer> which has worked so far
<Laney> for-project lubuntu cron.daily
<cjwatson> shadeslayer: hm, don't like that
<shadeslayer> cjwatson: oh ?
<cjwatson> shadeslayer: but I guess it will sort of work as long as you don't change the wrong things
<cjwatson> shadeslayer: the kubuntu-live task is generated under the assumption that kubuntu-desktop is installed
<shadeslayer> ah I see
<cjwatson> it's not actually strictly valid to use it without
<cjwatson> but you might be close enough to get away with it
<shadeslayer> \o/
<cjwatson> so let me chase down the seventy gazillion things I need to tweak here
<shadeslayer> ^^ I can understand :D
<Laney> ypwong: I'll unblock it on a "better than now" basis, but this should be revisited
<ypwong> laney: thanks, I'll ask happyaron to take a look at the bug you found
<cjwatson> shadeslayer: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/utopic/kubuntu-plasma5 exists, livefs build logs will eventually show up there
<shadeslayer> \o/
<shadeslayer> cjwatson: thanks alot! :D
<cjwatson> wonder if I need to adjust extra_ppas for the new reference format
<cjwatson> I guess we'll find out
<Laney> oh wait
<Laney> I was looking at the end, and all daily-live- logs are sorted after all daily- ones.
<Laney> Missing debootstrap-required init
<cjwatson> ah, I hadn't quite gone to look yet :)
<cjwatson> huh, I thought that was being fixed
<cjwatson> maybe priority
<cjwatson> $ change-override -p optional -y init
<cjwatson> Laney: try again after the next publisher run finishes
<Laney> ta
<cjwatson> (not the one currently in progress)
<Laney> what happened here?
<cjwatson> init was imported from Debian with the priority set in the package
<cjwatson> debootstrap automatically adds anything with priority required/important
<cjwatson> and debian-cd has a sanity check to make sure that everything wanted by debootstrap is actually on the image
<Laney> ah right, was missing the last piece of knowledge
<cjwatson> it doesn't come up often so it's a bit obscure
<xnox> cjwatson: i dropped essential, but not required.
<xnox> =/
<cjwatson> xnox: not within your power anyway, priorities are always overridden
<cjwatson> once it's in the archive it doesn't much matter what the package says
<xnox> right.
<xnox> cjwatson: essential bit as well?
<cjwatson> no that's up to the package
<cjwatson> shadeslayer: what's a suitable display name for the flavour?  just "Kubuntu Plasma 5"?
<shadeslayer> Riddell: ^^
<Riddell> yep
<shadeslayer> cjwatson: all 7 gazillion things adjusted ? :D
<cjwatson> sigh, patience
<cjwatson> I'm working on it
<cjwatson> but busy morning, preparing to go away
<cjwatson> and needed to wait for my livecd-rootfs upload to migrate anyway
<shadeslayer> cjwatson: roger :)
<cjwatson> cdimage stuff theoretically done
<shadeslayer> cjwatson: where are you off to for your vacation?
<cjwatson> just 1.5 days in Birmingham
<cjwatson> family
<shadeslayer> ah I see :)
<cjwatson> come on publisher, give me livecd-rootfs in release so that I can try a test-build so that I can go on holiday
<ogra_> heh, i guess you need patience ...
<cjwatson> yup
<ogra_> my lxc-android-config upload last night took ~3h
<ogra_> (from upload to archive)
<cjwatson> the publisher is very slow at the moment because an important and large column in the Launchpad database is having to be widened to 64 bits
<ogra_> ah, i was suspecting the KDE overload ;)
<cjwatson> no
<cjwatson> it seems to have pushed the DB server over the edge of a performance cliff
<Laney> ah, was wondering - I've been spamming rmadison for kylin
<cjwatson> we've been waiting for new DB servers to be plugged in for a while now ...
<cjwatson> Laney: it's there now
<Laney> so it is
<cjwatson> attempting to build kubuntu-plasma5 now, but scalingstack is actually a bit busy for once :)
<cjwatson> this is attached to a virt PPA so it needs to be built on virt builders
<cjwatson> so just as well scalingstack's been deployed since it wouldn't have worked on the old builders
<cjwatson> (live-build and hardy weren't friends)
<cjwatson> argh, timeout, seriously
<cjwatson> shadeslayer: sorry, I think I'm stuck on a firewall issue, so will have to wait until early next week
<shadeslayer> alrighty
<shadeslayer> cjwatson: I'll continue using my hacked up orchrestration for ISO's till then
<shadeslayer> does the job decently well, even though ubiquity ends up on the final installation
<cjwatson> hopefully it's mostly there on my side
<cjwatson> it just needs to talk to the Launchpad API to fetch the signing key for your PPA, and I think that the scalingstack builders don't currently have firewall access for that
<cjwatson> but no time to fix now before I leave
<shadeslayer> okie dokie
<Laney> cjwatson: looks like the priority change wasn't enough
<cjwatson> Laney: I think it just needed another publisher run or something.  the cdimage mirror doesn't have the priority change
<cjwatson> (gone)
<Laney> where is the mirror?
<Laney> (bye!)
<Laney> oh, found it
<Laney> ypwong: your images are up, testing welcome
<ypwong> Laney: yep, I have informed QA to do that
<Laney> thanks
<shadeslayer> anyone have a clue why https://launchpad.net/ubuntu/+source/kxmlgui/5.0.0-0ubuntu1/+build/6205249 doesn't build?
<shadeslayer> https://launchpad.net/ubuntu/+source/ktextwidgets/5.0.0-0ubuntu1 < seems to have built for armhf
<xnox> shadeslayer: rmadison -S libkf5textwidgets-dev says it's not published for armhf.
<xnox> shadeslayer: last archive publish was 11:56:42 UTC yesterday....which looks wrong.
<xnox> ..
<xnox> why does http://archive.ubuntu.com/ubuntu/dists/devel-proposed/Release says trusty-proposed ?!
<xnox> build finished at 12:33, last armhf publish was at 13:07 should be there by now...
<Laney> Riddell: you guys testing A2?
<Laney> who does lubuntu these days?
<Riddell> Laney: yes, come across a bug with installing in !english that I spent some time looking at, will do the rest of the tests now
<Riddell> Laney: and I should appologise for grumping at you on ubuntu-release mailing list the other day, that was uncalled for
<Laney> Riddell: did you?
<Riddell> oh if you didn't notice then never mind :)
<Laney> :P
<Laney> apology accepted anyway :-)
<Laney> stgraber: how are the product owners set on the iso tracker?
<shadeslayer> thx xnox
<Laney> I'm trying to find out what 'lubuntu release' maps to
<Laney> because it's not ~lubuntu-release :-)
<Riddell> ~lubuntu-dev ?
<stgraber> Laney: lubuntu-product-managers
<Laney> ty
<Laney> wxl: it seems to be you
<Laney> you guys organising testing of A2?
<Laney> ah, I see some results now
<utlemming> stgraber: where are the alpha-2 release notes hiding these days?
<utlemming> Alpha-2 Cloud Images are affected by bug #1350522
<ubot93> bug 1350522 in linux "EC2 kernel crash due to vmalloc" [High,Confirmed] https://launchpad.net/bugs/1350522
<stgraber> Laney: ^
<Laney> stgraber: Didn't start any, where are the A1 ones?
<stgraber> I don't believe we had any, just an announcement and then some per-product ones
<Laney> Yep, thought so
<Laney> utlemming: Feel free to make UtopicUnicorn/Alpha2/UbuntuCloudImages or something and I'll link to it
<utlemming> Laney: ack
<didrocks> seb128: if you have a minute ^
<seb128> didrocks, sure
<didrocks> thanks!
<Riddell> Kubuntu es bueno â
<Laney> sehr gut
 * Laney cribs from A1's release announcement
<Laney> wxl: Riddell: utlemming: ypwong: Let me know a link to include if you have one
<Laney> Also if you want to change the text
<Riddell> https://wiki.ubuntu.com/UtopicUnicorn/Alpha2/Kubuntu
<Laney> cheers
<utlemming> Laney: http://cloud-images.ubuntu.com/releases/utopic/alpha-2 will be the cloud image link
<Laney> utlemming: ya, got that one, I meant a release notes type thing
<utlemming> Laney: oh, right....
<Laney> I just did s/1/2/ on the URLs basically
<Laney> ... ready when you are ...
<Laney> utlemming: ypwong: wxl: I'm out for a bit, would appreciate you testing/readying
<Laney> I'll be back in a few hours
<utlemming> Laney: I'm good to go
<Laney> awesome
<Laney> just waiting for lubuntu/kylin
<xnox> Laney: are images done / no more respins? if that's the case, can you please lift the freeze?
<wxl> Laney: sorry been a bit out of it due to rl issues. we've started testing on a2?
<wxl> Laney: out of it as i said. i see that the release is scheduled to come out. we have full tests with no issues on desktop amd64/i386 but that's it. suggestions?
<pfsmorigo_> infinity: hi, maybe you can help me. I got an email saying that 12.04 has a swapcount=1 parameter in the kernel options and not in 14.04. Do you aware of it? Do you know why it was removed?
<pfsmorigo_> (if it was removed after all)
<infinity> pfsmorigo_: I'm going to need more context than that.
<infinity> pfsmorigo_: On the kernel commandline, in an fstab mount line, elsewhere?
<infinity> pfsmorigo_: Anyhow, I see no such options being used on my 12.04 systems, so I'm not sure how we could have stopped using something we weren't using.
<infinity> pfsmorigo_: Unless the argument is that the kernel stopped listening to that option when he supplies it himself?
<pfsmorigo_> infinity: I guy here complained... "Do you know why on Ubuntu 14.04,  swapcount is disabled by default? It is enabled by default on 12.04."
<pfsmorigo_> infinity: seems that it was an option hat used to be set in grub.cfg and know isn't anymore
<infinity> pfsmorigo_: No.
<infinity> pfsmorigo_: It was never in grub.cfg
<infinity> pfsmorigo_: A quick googling suggest that maybe he's trying to play with memory.memsw.* variables, which are only exposed in swapcount=1, which is new in newer kernels.
<pfsmorigo_> infinity: ok, good point
<pfsmorigo_> infinity: makes sense
<infinity> pfsmorigo_: In which case, he probably just wants to add "swapcount=1" to GRUB_CMDLINE_LINUX in /etc/default/grub, run sudo update-grub and reboot.
<pfsmorigo_> infinity: yep, I suggested that
<pfsmorigo_> infinity: tks man
<Laney> wxl: you can just release those if you want to
<Laney> wxl: just mark those ones as ready
<Laney> xnox: going to now, was hoping to hear back from the stragglers first
<Laney> out for another couple of hours, hopefully will hear back from kylin then
<Laney> wxl: I'll mark these two images as ready and you can just have an alpha with those
<wxl> Laney: works thanks
<Laney> blerg
<Laney> I'll wait until tomorrow morning for kylin on the basis that it'll still be Thursday somewhere ...
<JackYu> Laney, sorry for our delay. Expected to be done in half hour:)
#ubuntu-release 2014-08-01
<wxl> hopefully this is not too late but i just marked lubuntu alternate amd64/i386 as ready for alpha2
<pitti> infinity: I just uploaded an SRU for bitcoin in precise; any idea why it landed in NEW?
<pitti> https://launchpad.net/ubuntu/precise/+queue?queue_state=0
<pitti> wgrant: ^
<pitti>  bitcoin  | 0.3.24~dfsg-1 | precise/universe | source
<pitti>  bitcoind | 0.3.24~dfsg-1 | precise/universe | amd64, armel, armhf, i386, powerpc
<pitti> is that because it doesn't exist in any other release?
<pitti> but I suppose accepting it in NEW won't put it into UNAPPROVED, like that it's just not visible to the SRU team
<wgrant> pitti: Totally new override code was deployed a few hours ago, so probably a regression there. Investigating now -- please don't touch it just yet.
<pitti> wgrant: thanks; no, I won't -- if I would accept it it would already go into -proposed, and I'm not in ~ubuntu-sru any more
<infinity> Definitely a regression.
<infinity> wgrant: HEY, YOUR CODE HAS A REGRESSION.
<infinity> wgrant: YOU WANTED ME TO TELL YOU.
<infinity> wgrant: THIS IS ME NOTICING.
<wgrant> Ahh
<wgrant> It's the resurrections-must-hit-NEW case going wrong.
<wgrant> The most recent precise pub is a rejected SRU that is now Deleted.
<wgrant> So it sees the most recent pub is Deleted and decides it needs NEWing again.
<wgrant> I guess in this case I should look for non-Deleted ones first.
<wgrant> infinity: Opinions on precedence for binaries? We need to fall back to other archs and also to deleted pubs, but in which order should the combinations be tried?
<wgrant> Like, should an amd64 binary fall back to i386's overrides before a deleted amd64 pub?
<pitti> I think "yes", from my POV
<pitti> in general it's really awkward to have builds for different arches be in different components
<pitti> and I'm inclined to say that every such case is queue pilot error instead of deliberate
<infinity> wgrant: arch-before-deleted, I'd say.  Since arches should match in the Ubuntu case anyway.
<infinity> wgrant: We don't tend to mismatch.
<infinity> wgrant: We *can*, but we don't, cause it breaks our tiny little AA minds (and some of our tools).
<infinity> We should probably revisit that some day, so we can do different arch priorities, but yeah, we don't today.  Today, we override the tools instead of the pubs.
<wgrant> infinity: That's where I was leaning to as well, yeah.
<wgrant> The only thing that can sanely differ is priority, I guess.
<wgrant> And who cares if that goes slightly wrong.
<Riddell> Laney: did alpha 2 get released? I see nothing on ubuntu-devel-announce?
<Laney> Riddell: no, kylin hadn't readied before I had to leave
<Laney> let me check on it now
<Laney> yes, looks good, doing it
<Riddell> gotcha
<Laney> jamespage: do you know if anyone other than utlemming can publish cloud images?
<jamespage> Laney, rcj can as well but they are both not around until later
<jamespage> Laney, prob smoser as well
<Laney> ha
<jamespage> again +3 hrs or so
<Laney> sure, don't really want to wait for that
<Laney> I'll just say "will shortly be available"
<Laney> syncing out now
<jamespage> Laney, ack
<Laney> jamespage: ah, maybe they're already done: http://cloud-images.ubuntu.com/releases/utopic/alpha-2/
<jamespage> Laney, awesome
<jamespage> that does look to be the case
<Laney> so all good
<Laney> move along people, nothing to see here
* Laney changed the topic of #ubuntu-release to: Released: Trusty Final, Utopic Alpha 2 | 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
<pitti> the new debhelper is being held back in -proposed by the new broken gem2deb version in -proposed, but it's not the new debhelper's fault; can you please hint this?
<smoser> Laney, i can.
<smoser> and, yeah, rcj.
<Laney> smoser: It'd be good to have someone in the eu who can do it too
<smoser> Laney, talk to utlemming to get someone on that team.
<Laney> utlemming: consider yourself talked to :-)
<Chipaca> seb128: please re-review https://code.launchpad.net/~chipaca/gsettings-ubuntu-touch-schemas/just-the-touch-settings/+merge/228317
<seb128> Chipaca, k
<Nivex> Curiosity is getting the better of me. What's the blocker for do-release-upgrade from 12.04.4 to 14.04.1 ?
<wgrant> pitti, infinity: That NEW bug is fixed on prod now.
<utlemming> Laney: working on that question today, incidently.
#ubuntu-release 2014-08-02
<cjwatson> shadeslayer: Could you arrange for (at least) kio-extras in ppa:kubuntu-ppa/next to be rebuilt against libexiv2-13, and plasma-nm to be rebuilt against libopenconnect3?  This causes https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/utopic/kubuntu-plasma5/+build/3112
<cjwatson> shadeslayer: You can hopefully have images once that's sorted :)
#ubuntu-release 2014-08-03
<shadeslayer> cjwatson: ack
<shadeslayer> cjwatson: done :)
#ubuntu-release 2015-07-27
<flexiondotorg> Laney, I saw your post. I did take 2 days off work in the end.
<flexiondotorg> So all set for this week.
<flexiondotorg> Riddell, Thanks for your feedback about ubuntu-mate-welcome.
<flexiondotorg> Riddell, I've put a new release together. Would you be kind enough to action it for me? https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1478323
<ubot93> Launchpad bug 1478323 in ubuntu-mate-welcome (Ubuntu) "ubuntu-mate-welcome 1.0.1 release [debdiff attached]" [Undecided,New]
<teward> can someone on the SRU team review/accept https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1314740 into proposed so it can be tested?  It's awaiting acceptance, and is a fairly major bug since the init script can fail to find the pidfile information in quite a lot of cases...
<ubot93> Launchpad bug 1314740 in nginx (Ubuntu Trusty) "[SRU] init script pid parsing has failure cases" [Medium,In progress]
<sil2100> Hello release team! I'll have to disable the rc-proposed images in s-i and also possibly the importer itself for short periods of time
<balloons> infinity or slangasek, any thoughts on why wubi.exe is still on the images?
<infinity> balloons: Because we hate ourselves and our users.  I'm pretty sure there was a better reason, but I can't think of it right now.
<slangasek> I thought it had to do with wubi.exe being the autorun interface for stuff other than actually installing in wubi loopback mode
<infinity> slangasek: That sounds about right.
<balloons> :-p I seem to remember something similar. But it's still scary to see
#ubuntu-release 2015-07-28
<Laney> flexiondotorg: Setting up the milestone and kicking a rebuild now, FYI
<Laney> rebuild-requests is taking a suspiciously long time to complete
<flexiondotorg> Laney, Thanks.
<Laney> ah, it waits for the rebuilds - okay then
<lordievader> Oeehh, Alpha2 images
<flexiondotorg> Laney, Could you do me a favour and update the ubuntu-mate seeds/tasks please?
<Laney> flexiondotorg: Update from where?
<flexiondotorg> Laney, https://code.launchpad.net/~ubuntu-mate-dev/ubuntu-seeds/ubuntu-mate.wily
<didrocks> flexiondotorg: you want to update ubuntu-mate-meta?
<flexiondotorg> didrocks, Yes please.
<didrocks> flexiondotorg: doing
<Laney> I'm doing it
<didrocks> ah :)
<flexiondotorg> Laney, Thanks for doing.
 * didrocks avoided heat \o/
<flexiondotorg> didrocks, Thanks for offering :-)
<didrocks> yw!
<Laney> flexiondotorg: rev #11 does a little bit more than its message suggests...
<didrocks> flexiondotorg: I still must say that beer and curry sounds weird :)
<didrocks> flexiondotorg: (just listened to that episod while doing my daily run)
<Laney> flexiondotorg: Also note that the tasks are generated from the seeds directly; you're asking to update the metapackage. :)
<flexiondotorg> Laney, So it also removes some commented stuff for ibus. That has never featured.
<flexiondotorg> Laney, And adds ubuntu-mate-welcome
<flexiondotorg> Laney, Yes I forgot my teminology.
<flexiondotorg> didrocks, Beer good. Curry good. Beer + Curry = Better :-)
<Laney> Task is what you see in (e.g.) apt-cache show $package
<wxl> um, why isn't lubuntu in alpha 2?
<ianorlin> I don't think the dialies have built yet for today
<wxl> we're not even in the manifest from what i can tell
<Laney> Why would you be?
<Laney> You never replied to the email.
<wxl> Laney: i never got an email
<ianorlin> oops
<Laney> https://lists.ubuntu.com/archives/ubuntu-release/2015-July/003322.html
<Laney> Not too late.
<wxl> wth
<Laney> You want in?
<wxl> yes please
<wxl> just trying to figure out why i didn't get any of those emails
<Laney> buildin
<Laney> g
<wxl> huh i do get digests so maybe i just missed it
<wxl> turned digest mode off
<wxl> sorry for the hassle, Laney
<Laney> No worries
<flexiondotorg> Laney, can you help me identify why ubuntu-mate-artwork is stuck in wily-proposed please?
<slangasek> udisks2 in trusty-proposed seems to have regressed its own test suite; this means, for instance, that we don't have valid test results for the parted SRU which we would want to release for 14.04.3.  Should the udisks SRU be removed, and the autopkgtests rerun?
<infinity> slangasek: I released the parted SRU anyway, based on some manual investigation.  But yeah, something should be done about udisks2, probably.  The sea of red in trusty autopkgtests in general is still something we need to get under control. :/
<slangasek> infinity: well, udisks2 is removed now, so we could have gotten those autopkgtest results for parted... but ok
<slangasek> it's actually not much of a sea anymore, I think - seems to be confined to a few SRUs, all of which surely need investigation
<infinity> slangasek: I dunno.  All the red on gtk+3.0 for instance is probably not all GTK's fault (if any is).
<slangasek> perhaps not, but it still needs investigated and not just ignored
<cyphermox> infinity:  ^ ubiquity is in the queue
<infinity> slangasek: Yeah, I'm not touching that one anyway. :P
<slangasek> heh
<infinity> cyphermox: Ta.
<infinity> slangasek: That GTK bug looks like something I'd like fixed for the point release, mind you, but no one's touched it for verification in almost a month, so my hopes aren't high.
<infinity> seb128: ^? :)
 * infinity side-eyes that "2014 bit" key in the python3.4 upload.
<infinity> Apparently, numeric dyslexia is contagious.
<seb128> infinity, slangasek, I tried to ping bdmurray/the SRU team on #ubuntu-devel about that gtk update like 4 times
<seb128> to get it approved
<seb128> nobody ever ponged
<infinity> seb128: Err, wat?
<seb128> but yeah, please unblock it if you can
<infinity> seb128: "approved" how?
<infinity> seb128: It's been in -proposed for a month.
<lordievader> stgraber: Hey, since the Kubuntu team is away at Akademy this week I am doing the lead for Alpha2. However I have not yet received admin rights, could you grant me these?
<infinity> cyphermox: Accepted.
<seb128> infinity, sorry, looking through logs it looks like we had the same issue for the previous SRU which got approved after a while, so seems we are back to having the same discussion for every update :-/
<seb128> http://irclogs.ubuntu.com/2015/05/27/%23ubuntu-devel.html#t13:01
<infinity> seb128: I'm not talking about the autpkgtest issues, that's on us to sort out, for the most part.
<infinity> seb128: I'm talking about the bug itself having 0 activity since the upload.
<seb128> infinity, ah, ok, I picked up your "<infinity> slangasek: I dunno.  All the red on gtk+3.0 for instance is probably not all GTK's fault (if any is)."
<seb128> which made me react
<seb128> because it has been an issue for the previous SRU already and finding somebody to unblock the validated SRU took ages
<infinity> seb128: Ahh, yeah, no.  I'm just concerned about the lack of verification/testing.
<seb128> anyway, going to chase somebody to verify the new one
<seb128> thanks for pointing it out
<infinity> seb128: We're well aware that the autopkgtest for SRUs is less than perfect. :/
<infinity> doko: Do you care that your python3.4 changelog parrots the same typo from the upstream commit (s/1024/2014/), or would you prefer it reflect reality?
<infinity> doko: I'm happy (though amused) to accept it as-is, but maybe you'd like it to not be silly.  Up to you if you want to reupload.
<doko> don't care
<infinity> Kay.
<bdmurray> infinity: https://code.launchpad.net/~brian-murray/+junk/ubuntu-archive-scripts I removed utopic references from the ubuntu-archive scripts
<Logan> infinity: want to accept my gnuradio SRU uploads for Trusty and Vivid? I can assure you they build properly :)
<Logan> very harmless change, just removing an unneeded build dependency so it can build on armhf too
#ubuntu-release 2015-07-29
<infinity> Logan: No, but it seems someone else just did.
<Logan> ah, but I wanted the infinity stamp on it :(
<RAOF> Logan: Trusty's done; would you kindly add the bug reference to vivid?
<Logan> oh, did I not nominate it for Vivid? awks
<RAOF> No, you didn't include the bug in the changelog.
<Logan> OH
<Logan> do I need to bump the version?
<infinity> No.
<RAOF> No.
<infinity> Rejected versions aren't "used up".
<Logan> I figured
<Logan> RAOF: ^ thanks!
<infinity> RAOF: Probably poor form to accept mesa-lts-vivid/trusty, but not the matching mesa/vivid.
<RAOF> infinity: Hm. Didn't notice that one.
<infinity> RAOF: For HWE backports, I tend to verify that the origin exists in the archive before accepting the backport.
<infinity> RAOF: Since it's a bit backwards the other way. :)
<RAOF> :)
<infinity> RAOF: (pls fix, since you have context from the first review)
<RAOF> Doing so now.
<jamespage> if there is a sru team member around the horizon in trusty proposed addresses a regression introduced with the last update
<jamespage> https://bugs.launchpad.net/ubuntu/+source/horizon/+bug/1476417
<ubot93> Launchpad bug 1476417 in horizon (Ubuntu Trusty) "[SRU] FloatingIpManager in neutron.py missing is_supported method" [Critical,Triaged]
<jamespage> I'd like to get that out asap as horizon is quite broken in trusty right now
<infinity> jamespage: Looking.
<jamespage> infinity, thankyou
<infinity> jamespage: Accepted.  If it's critical, feel free to turn around a quick verification with some indication of reasonable regression testing, and we can fasttrack the promotion to updates.
<jamespage> infinity, on that now
<infinity> jamespage: Well, ideally wait for the binaries to spit out. ;)
<jamespage> indeed
<jamespage> infinity, (or any other sru team member): I've worked through the horizon webui as both an end-user and a admin user - fix for bug 1476417 tests out OK and causes no regressions that I can see
<ubot93> bug 1476417 in horizon (Ubuntu Trusty) "[SRU] FloatingIpManager in neutron.py missing is_supported method" [Critical,Fix committed] https://launchpad.net/bugs/1476417
<jamespage> if we can get that released today much appreciated
<Laney> flexiondotorg: You dropped ubuntu-mate-wallpapers-common but stuff depends on it
<Laney> didn't notice that, partially my bad
<tseliot> can an admin approve nvidia-graphics-drivers-352 and nvidia-graphics-drivers-352-updates in wily NEW, please?
<tseliot> they belong in "restricted"
<infinity> tseliot: I'll be looking at those later, but first you need to fix your nvidia-* trusty SRUs for me.
<infinity> tseliot: Note the comment on the bug, you got your conflicts/replaces wrong (the old packages provide a different virtual package than the one you replace in the new ones)
<tseliot> infinity: ok, let me check that
<tseliot> infinity: what bug report did you use for that comment?
<infinity> tseliot: The one mentioned in the SRUs?
<infinity> tseliot: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-346/+bug/1465706
<ubot93> Launchpad bug 1465706 in nvidia-settings (Ubuntu Trusty) "SRU: New upstream releases of nvidia for 14.04.3" [High,In progress]
<infinity> tseliot: Comment #7
<infinity> tseliot: Easily visually verifiable that nvidia-opencl-icd-331 doesn't provide the package that the newer ones are replacing.
<tseliot> infinity: ok, thanks
<infinity> tseliot: If you can fix that up ASAP, we can re-verify and get it all sorted today.
<tseliot> infinity: sure
<tseliot> infinity: is it ok if I add opencl-icd to conflicts/replaces and keep the new virtual package?
<infinity> tseliot: Yeahp.
<tseliot> infinity: ok
<Laney> flexiondotorg: fixing the LO icon deps in your metapackage, since that's also uninstallable on arm64 and ppc64el
<tseliot> infinity: actually, I've just remembered that I removed that conflicts/replaces in 331 to fix LP: #1247736 . My guess is that the user who reported the problem was using an nvidia-opencl-icd-331 (331.38-0ubuntu7 ?) that is older than what is available in trusty updates (331.113-0ubuntu0.0.4). You can see the difference here: http://paste.ubuntu.com/11958577/
<ubot93> Launchpad bug 1247736 in nvidia-graphics-drivers-304-updates (Ubuntu Trusty) "[SRU] nvidia-opencl-icd-* should not conflicts/replaces on opencl-icd" [Undecided,Confirmed] https://launchpad.net/bugs/1247736
<infinity> tseliot: Hrm?
<infinity> tseliot: It either need to conflict/replace that virtual package, *or* needs versioned conflict/replaces on the older nvidia-opencl-icd-331{,-updates} packages.
<infinity> tseliot: If the opencl-icd conflict is a bug, then do the latter.
<infinity> tseliot: If you're overwriting files, you need to express that.
<tseliot> infinity: yes, the latter seems like the only option
<infinity> tseliot: I assume nvidia-opencl-icd-331{,-updates} >> 340 are actually empty packages?
<infinity> So you can just conflict/replace against those (<< 340)
<tseliot> infinity: yes, those are empty transitional packages
<tseliot> good point
<tseliot> I introduced that change in 331.38-0ubuntu7.1
<infinity> (<< 340) is easier to type. :P
<tseliot> right
<tseliot> :)
<infinity> And also more obviously correct to a human reviewing, like me. :P
<tseliot> I assumed admins were superhuman beings ;)
<tseliot> infinity: something like this should work, right? http://paste.ubuntu.com/11958630/
<infinity> tseliot: That looks reasonable, yeahp.
<infinity> tseliot: x however many packages need that fix.
<infinity> 2, 4, I dunno, the nvidia stuff seems to multiply.
<tseliot> infinity: right, it's not my fault though ;)
<tseliot> infinity: I should debuild with -v to include the diff from the previous release in -proposed too, right?
<infinity> tseliot: Ideally, yes.
<tseliot> infinity: ok, good
<tseliot> infinity: I'm going to add unversioned conflict/replaces for 304 and 304 updates, since, apparently, I've never fixed 1247736 in trusty for these packages
<flexiondotorg> infinity, Are you on duty?
<infinity> flexiondotorg: I'm barely awake, so I guess it depends on what you're asking.
<flexiondotorg> infinity, Sleep well :-)
<flexiondotorg> Laney, So ubuntu-mate-wallpapers-common should not have been dropped. I'll check my sources and see what happened there.
<flexiondotorg> Laney, Thanks for steering me in the right direction.
<Laney> np
<flexiondotorg> Laney, I've found the issue. ubuntu-mate-common was erroneously removed in a commit.
<flexiondotorg> Laney, I'll can raise a new debdiff bug for ubuntu-mate-artwork. Should I rev the version in the resubmission?
<tseliot> infinity: ok, uploaded
<Laney> flexiondotorg: yes, it's already uploaded so we need a new version
<flexiondotorg> OK, understood. Sorry I messed this up. Any chance you'd be able to sponsor the new upload when I submit it?
<Laney> sure
<flexiondotorg> Laney, because I'd really need this in Alpha 2. I appreciate I'll need to issue a rebuild at some point.
<flexiondotorg> Laney, Thanks very much. I'll go and make the debdiff.
<infinity> tseliot: Were 346* the only ones with the bug?
<infinity> tseliot: Both accepted.  Please re-verify, including testing the broken upgrade path you just fixed, so we can get these in.
<lordievader> stgraber: You around?
<stgraber> lordievader: sorta
<lordievader> Did you see my message of yesterday?
<tseliot> infinity: thanks, I will re-verify that. As for the other packages, 340 has transitional packages for 331, so it should be ok. Installing 340-updates over (non -updates) 331 will probably fail though.
<flexiondotorg> Laney, sorry for the delay. Here is the ubuntu-mate-artwork debdiff. Thanks for helping.
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1479352
<ubot93> Launchpad bug 1479352 in ubuntu-mate-artwork (Ubuntu) " ubuntu-mate-artwork 0.4.12 new nelease [debdiff attached] " [Undecided,New]
<flexiondotorg> didrocks, If you're not too busy could you sponsor this upload please?
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1479352
<ubot93> Launchpad bug 1479352 in ubuntu-mate-artwork (Ubuntu) " ubuntu-mate-artwork 0.4.12 new nelease [debdiff attached] " [Undecided,New]
<flexiondotorg> didrocks, I really need this so I can rebuild the Ubuntu MATE 15.10 Alpha images.
<flexiondotorg> didrocks, Laney is aware of this but I'm guessing he got busy.
<didrocks> flexiondotorg: hey, I didn't download the package yet, but there is no .install? You copy them in the right dir yourself in debian/rules?
<flexiondotorg> didrocks, The .install for ubuntu-mate-artwork-common was present in 0.4.11
<didrocks> ah, you just forgot the declaration in debian/control
<flexiondotorg> didrocks, But the entry in debian/control got nuked by an erroneous commit.
<flexiondotorg> So, 0.4.12 just reinstates the control entry that should have been there all long.
<flexiondotorg> didrocks, Thanks for looking :-)
<didrocks> flexiondotorg: yw! doing a quick build before uploading :)
<flexiondotorg> didrocks, Cool.
<Laney> go didrocks
<Laney> flexiondotorg: I was having lunch.
<flexiondotorg> Laney, well I know you're busy.
<flexiondotorg> Laney, I done some smoke test for Ubuntu MATE.
<flexiondotorg> Laney, But I want to rebuild and make sure this artwork and meta package stuff is all good too.
<Laney> 'k
<flexiondotorg> Laney, I assume that ubuntu-mate-meta will automatically promote from proposed when ubuntu-mate-artwork 0.4.12 is in the relese pocket?
<Laney> laney@nightingale> rmadison -swily,wily-proposed ubuntu-mate-meta                                                                                                                                    ~ ubuntu-mate-meta | 1.127 | wily/universe | source
<Laney> laney@nightingale>                                                                                                                                                                                   ~
<Laney> it already did
<flexiondotorg> Laney, Ah, great.
<flexiondotorg> Laney, Thanks.
<didrocks> flexiondotorg: sponsored, and kudos for the trailing comma after the last depends :)
<flexiondotorg> didrocks, I found wrap-and-sort :-)
<flexiondotorg> didrocks, Thanks for helping out.
<didrocks> oh, wrap-and-sort is adding the trailing comma? NICE! :)
<didrocks> yw
<flexiondotorg> wrap-and-sort -t -a
<Laney> haha
<didrocks> I swear I didn't add the -t option to it. But that would have been the case if I thought about it |o|
<jamespage> infinity, any chance you can release the horizon fixup (bug 1476417) to updates? it LGTM
<ubot93> bug 1476417 in horizon (Ubuntu Trusty) "[SRU] FloatingIpManager in neutron.py missing is_supported method" [Critical,Fix committed] https://launchpad.net/bugs/1476417
<jamespage> pretty please :-)
<flexiondotorg> Laney, ubuntu-mate-artwork 0.4.12 is now in the released pocket :-)
<flexiondotorg> Laney, If I rebuild the iso images will the build pick up that new version? Or is there something else I need to wait for?
<Laney> flexiondotorg: If rmadison shows you the new version in wily then it'll get that
 * flexiondotorg goes to learn what rmadison is and how to use it.
<Laney> I gave you an example line just there ^^^
 * flexiondotorg knows rmadison. Whoa.
<Laney> It queries a remote machine to tell you about package versions
<flexiondotorg> Laney, Thanks. rmadison still shows 0.4.10. So I'll wait.
<Laney> nod
<infinity> jamespage: Done.
<flexiondotorg> Riddell, wxl How is your 15.10 Alpha 2 testing going?
<lordievader> flexiondotorg: Speaking for Riddell, good :) tested lots yesterday, no crucial problems found.
<flexiondotorg> lordievader, Excellent. I've found myself in the same happy situation with Ubuntu MATE. One note worthy issue but noth critical :-)
 * flexiondotorg makes mental note to contact lordievader tomorrow.
<lordievader> I do have one problem though, since the Kubuntu team is away at Akademy I volunteerd to do the lead on this one. But as of yet I do not have the rights to make the image ready... :(
<infinity> lordievader: You can just tell Laney your images are ready and he can mark them.
<lordievader> Oke, I will remember that. Going to test some more tommorow. Thanks :)
<flexiondotorg> lordievader, Looks like I could also make you image as ready when you get to that point :-)
<lordievader> Ah, cool. Then I'll bug one of you two tommorow about it ;)
<lordievader> flexiondotorg: ^
<flexiondotorg> lordievader, Sure, no problem :-)
<flexiondotorg> lordievader, I owe Riddell a favour or three
<lordievader> :)
<jderose> infinity: seems something is a bit off in the *lts-vivid X bits still https://bugs.launchpad.net/system76/+bug/1479524
<ubot93> Launchpad bug 1479524 in totem (Ubuntu) "Totem Crashes at launch from missing libwayland-egl" [Undecided,Confirmed]
<jderose> that's with todays 14.04.3 daily ISO, sha1sum 61afb95256980077b41415f2986ee75d2b3222cd
<infinity> jderose: So something has an undeclared dep?  Lovely.
<infinity> tjaalton: Around?
<infinity> jderose: So, (minus version bumps, obviously), this is the delta from .2 to .3: http://paste.ubuntu.com/11962290/
<infinity> jderose: Pretty clearly missing that one library, but I assumed this was intentional on the part of the X maintainers, so we'll have to sort out why. :P
<jderose> infinity: gotcha. while i have you, do you know why there is no "libegl1-mesa-drivers-lts-vivid" package to replace "libegl1-mesa-drivers-lts-utopic"? is this deliberate or a goof?
<infinity> So, looks like libopenvg1-mesa and libegl1-mesa-drivers legitimately no longer exist in the new mesa.
<infinity> But libwayland-egl1-mesa-lts-vivid definitely exists, it's just that nothing pulls it in.
<infinity> jderose: newer mesa Provides mesa-drivers.
<infinity> jderose: So, I guess whatever was in that package was pulled in.
<jderose> infinity: so something that truly does depend on libwayland-egl1-mesa-lts-vivid hasen't properly declared it as such... and after that's fixed, it will fix the ISO manifest automatically?
<jderose> gotcha, thanks
<infinity> And it was drivers that depended on wayland, so I guess that dependency needs to move around a bit.
<jderose> (i don't know much about the ISO building process BTW, so sorry if that's a dumb/obvious question)
<jderose> ah, gotcha
<infinity> jderose: Yeah, this isn't something we should hack around in the ISO mastering process, if a package is legit missing a dep, we should fix it. :)
<jderose> agreed :)
<infinity> A bit curious that this wasn't an issue with vivid, though...
<infinity> Unless the backport broke the deps a bit.
 * infinity goes to look at the vivid manifest.
<infinity> Hrm, *something* pulled it in in vivid.
<infinity> Wait.  I've confused myself.
<infinity> Ahh, it's pulled in incidentally in vivid by gtk depending on it.
<infinity> Which clearly won't be true in trusty.
<infinity> jderose: Can you reproduce that bug and verify that installing libwayland-egl1-mesa-lts-vivid fixes it?
<jderose> infinity: sure, just a sec...
<jderose> infinity: yup, `apt-get install libwayland-egl1-mesa-lts-vivid` fixes it
<infinity> jderose: Alright.  We'll either get it fixed in mesa, or I'll pull some tricks, but we'll figure it out.
<jderose> infinity: awesome, thanks! :)
<infinity> tjaalton: When you pop your head in, please have a look at https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1479524
<ubot93> Launchpad bug 1479524 in mesa-lts-vivid (Ubuntu Trusty) "Totem Crashes at launch from missing libwayland-egl" [Undecided,Confirmed]
<infinity> RAOF: Or you ---^
<infinity> Oh, hrm.  I used to install libegl1-mesa-drivers manually for lts-utopic.  Maybe you'll both tell me I should just install this manually now instead.
 * infinity grumps and admits that's probably the answer he'll be given.
<infinity> But we'll see.
<ari-tczew> There are a lot of packages related to KDE, which have been _not_ yet migrated from -proposed. e.g. kf5unitconversion, is there any blacklist for such packages?
<cjwatson> That seems to fail Occam's Razor
<infinity> Also, I don't see kf5unitconversion in proposed...
<infinity> So you might need to be a bit more specific.
<infinity> kunitconversion?
<cjwatson> Much easier to actually look at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<ari-tczew> infinity: yes, kunitconversion, sorry
<cjwatson> Regression in the kdelibs4support autopkgtest
<cjwatson> Dunno if that actually has anything to do with kunitconversion, I haven't unpicked that; but it would probably be easier to make the tests pass than to invent conspiracy theories about blacklists :-)
<infinity> cjwatson: Conspiracies are more fun.
<jderose> infinity: when you say "I used to install libegl1-mesa-drivers manually for lts-utopic", do you mean as per the instructions here - https://wiki.ubuntu.com/Kernel/LTSEnablementStack
<cjwatson> There is the facility to block packages, but if that were in use then you would see it logged on the above page
<cjwatson> https://wiki.ubuntu.com/ProposedMigration has overall documentation
<jderose> infinity: or do you mean in terms of the ISO mastering
<cjwatson> Oh, and there are a bunch of other problems, because kunitconversion needs ki18n and that has a couple of other autopkgtest regressions
<infinity> jderose: I mean for the livefs mastering.
<infinity> cjwatson: I thought you were sleeping.
<cjwatson> I sure am, I type by telepathy.
<jderose> infinity: okay, gotcha. just to make sure i'm understanding things correctly, totem should in fact depend on libwayland-egl1-mesa[-lts-*], either directly or indirectly, right? like if you installed from the server ISO, the expectation is that `apt-get install totem` would do something sane, in theory yield a workable totem install?
<infinity> jderose: I doubt it's totem itself that's trying to load that library.
<infinity> jderose: Odds are it's mesa's fault.
<infinity> jderose: Oh, you did say "or indirectly".  So, yeah, I'd imagine that mesa has an undeclared dependency there because someone was trying to be overly clever with a package split and didn't notice the consequence. :P
<infinity> jderose: Alternate fix would be to make whatever's dl()opening that library be more conditional and less violently faily.
<infinity> Anyhow, the band-aid solution might just be for me to pre-install it, as I did for mesa-plugins in .2
<infinity> We'll see.
<infinity> jderose: I'll have a healthy argument with the X folks and have it fixed -- one way or another -- by tomorrow.
<jderose> infinity: okay, gotcha. for me the ISO/livefs build process is still much mystery sauce, so i'm just trying to understand things a bit better. thanks for graciously humoring my questions! :D
<infinity> jderose: In an ideal world where all packages behave, the livefs build process should just be "apt-get install ubuntu-minimal ubuntu-standard ubuntu-desktop" && take package list && "apt-get install ubuntu-live" && take new package list, so we have install/live diff, compress and ship.
<infinity> jderose: The world isn't always entirely ideal.  But we aim for it. :P
<jderose> infinity: thanks for the pseudo-code there... that hugely, hugely helped me understand the process.
<jderose> and it's good to have ideals to strive for, even if you don't always reach them :)
 * jderose catches the bus
<bdmurray> Could somebody have a look at my apport SRU in the vivid queue?
<infinity> bdmurray: What's the magic word?
<infinity> bdmurray: Pretty sure your bug ref is bogus.
<bdmurray> infinity: hmmph, thanks
<teward> infinity: could you please do me a favor and take a look at the nginx sru in the trusty queue?  That's a fairly-easy-to-reproduce bug, and init failing because it can't parse pidfile is *bad*... no rush, though, i'm fine waiting for a few days longer, since I use the nginx PPAs on my trusty systems.  others, unfortunately, are still hit by this.
<teward> if you're busy i'll wait :0
<infinity> teward: Can you fix your changelog to remove the trailing " *\n"?
<infinity> teward: Not that that's a problem, but it's icky and shows a lack of attention to detail. :P
<infinity> teward: Also, the reference to "debian/control:" seems wrong, that's not the file you changed...
<bdmurray> infinity: I've reuploaded apport.
<teward> infinity: reject, i'll reupload
<teward> infinity: i'll make those fixes :)
<teward> ehhh, i don't need to increment the version again do I, given that it was rejected...?
 * teward may have made a failure if it needs another version number bump >.<
<bdmurray> teward: No, you don't need to the bump the version since it was never published.
<infinity> teward: You d... What he said.
<teward> bdmurray: that's what i thought, but i've failed in the past :)
<teward> the headache of staring at ESXi's command line, coupled by manually rebuilding two VMs is draining my brain :)
<teward> that one should look better
#ubuntu-release 2015-07-30
<teward> thank you for the accept :)
<infinity> teward: Thanks for addressing my nitpicking. :P
<teward> infinity: i quite like it when people point out my minor failures
<teward> it makes me realize why i say i shouldn't code after being jerked around left right up and down by work
<teward> :P
<infinity> teward: For the record, that's not about "ugh, your changelog sucks", but more about "always debdiff and read carefully before upload".  The same sort of careful review of why your changelog sucks tends to also apply to carefully reviewing the rest of the diff, IME.
<teward> mhm
<teward> oh you know what, that hit at the same time as we had servers going BOOM in the server room, no wonder i didn't catch those mistakes :/
 * teward shrugs
<teward> infinity: i still don't mind when my minor mistakes are pointed out - makes me pay more attention in the future :)
<teward> at least it's not a 'HEY THIS IS UNTESTED WHY DID YOU UPLOAD IT' situation
<teward> (which has happened once)
<jackyu> Hi, release team, Help: we can not update the status on Wily Alpha 2 of Ubuntu Kylin. It stays on re-building, we want to Cancel it.
<infinity> jackyu: I can fix that.
<jackyu> infinity, great, thanks^
<infinity> jackyu: Did you want a fresh build?  That's the simplest way to fix it.
<jackyu> infinity, yes!
<infinity> jackyu: Right.  Fresh build coming up, then.
<teward> infinity: thanks on helping with that SRU and getting to proposed.  verification-done but i'mma let it sit
 * teward isn't too worried about it :P
<jackyu> infinity, Actually, we updated a package that results in the block problem. So we want to build a fresh one.
<infinity> jackyu: There's a fresh build in progress right now.
<jackyu> infinity, Great~
<infinity> jackyu: ^
<jackyu> âº
<tjaalton> infinity: the right answer would be to allow mesa backports as is, of course :)
<tjaalton> i'm on holiday, btw
<tjaalton> and don't know what (meta) pgk should depend on the wayland bits.. but if you did it manually last time then do so again, and leave a bug for the next time
<tjaalton> ?
<infinity> tjaalton: It wasn't the backport that introduced the issue, it's "broken" the same way in vivid and wily. :P
<infinity> tjaalton: It's just accidentally working in V and W because libgtk and libsdl happen to depend on libwayland-egl, so it's pretty hard to not have it installed.
<infinity> tjaalton: But yeah, I can work around it in livecd-rootfs for now.  But it's still a bug. :P
<infinity> tjaalton: As for what package should depend on it, it should be whatever is dlopen()ing it unconditionally.  Which is probably libegl-mesa.
<infinity> tjaalton: If that behaviour isn't intentional, that should be fixed, IMO.
<jamespage> infinity, thankyou
<tjaalton> infinity: right, i'll check it out when i get back. assign the bug to me so i don't forget
<infinity> tjaalton: Done.
<infinity> RAOF: You around?
<RAOF> infinity: Yo.
<infinity> RAOF: Too late, I got pitti to cover.
<RAOF> How are you online both when I get up and just before I stop work?
<infinity> RAOF: Magic.
<tseliot> infinity: any progress on approving nvidia-graphics-drivers-352-updates and nvidia-graphics-drivers-352 in wily?
<infinity> tseliot: I've been flat out on point release stuff, sorry.
<tseliot> infinity: no problem
<Laney> flexiondotorg: How's the hassling going?
<flexiondotorg> Ubuntu MATE looking good.
<flexiondotorg> Kubuntu looking good.
<flexiondotorg> No feedback from Lubuntu.
<flexiondotorg> wxl, How is the Alpha 2 testing progressing?
<infinity> According to the tracker, they look good on !powerpc, though they've not marked ready.
<Laney> I got happyaron to find out about Kylin
<Laney> They've been doing hardcore through-the-night QAing
<flexiondotorg> Laney, I've marked Ubuntu MATE as ready.
<flexiondotorg> Laney, I'll start drafting release announcements in a little while.
<Laney> Thanks
<Laney> Enjoy the crushing burden of finding a suitable quote
<flexiondotorg> Laney, quote?
<Laney> All the best release announcements start with an appropriate quotation. :)
<Laney> (it is optional)
<flexiondotorg> Laney, easy ;-)
<flexiondotorg> wxl, lordievader Can you please add your release note or link to them here please - https://wiki.ubuntu.com/WilyWerewolf/Alpha2
<infinity> Laney: Bah, I gave up that tradition ages ago, in favour of instead embedding subliminal messages in headers.
<lordievader> I suppose http://cdimage.ubuntu.com/kubuntu/releases/wily/alpha-2/ will become available once it is released?
<cjwatson> lordievader: that's how it works, yeah
<lordievader> flexiondotorg: Updated :)
<flexiondotorg> lordievader, Thanks.
<infinity> lordievader: Are the kubuntu images ready, BTW?  I can mark for you, since I happen to be on the page...
<lordievader> infinity: Yes, mark them ready :)
<Laney> infinity: Cue many man hours wasted by Ubuntu watchers poring over your emails
<infinity> lordievader: ^
<lordievader> \o/
<lordievader> infinity: Thank you :D
<infinity> Well, now, there's a package name.
<lordievader> I wonder what it does...
<infinity>  thefuck    - spelling corrector of console commands
<Laney> rcj: Cloud image verification on track?
<infinity> https://github.com/nvbn/thefuck
<lordievader> Hihi, interesting.
 * infinity accepts that with vigor.
<infinity> Laney: Lemme know when your soft lock on the archive is up, so I can let the kernel migrate.
<xnox> infinity: .. at least that package is not written in nodejs....
<infinity> xnox: No, but all bets are off when your README contains a gif.
<infinity> xnox: And a gif of terminator, no less.
<xnox> infinity: enough of internets for today....
 * xnox hobbles downstrairs on crutches to get pain killers
<Laney> infinity: 'kay - hoping the remaining flavours wake up soon
<flexiondotorg> lordievader, Are you ready to mark Kubuntu images as ready?
<infinity> flexiondotorg: Already done.
<flexiondotorg> infinity, Thanks.
<lordievader> flexiondotorg: ;)
 * flexiondotorg was looking at Kylin.
<rcj> Laney, cloud images are ready
<Laney> rcj: great
<Laney> flexiondotorg: ^ fyi - they don't use the tracker
<rcj> Laney, correct
<flexiondotorg> rcj, Great.
<flexiondotorg> Laney, yup I got that :-)
<Laney> getting there
<flexiondotorg> Working on release announcement. Nearly done.
<Laney> w00t
<rcj> Laney, flexiondotorg: Do you have an outlook for the release?  I need to grab some breakfast.
<flexiondotorg> rcj, Do you mean timing?
<rcj> flexiondotorg, yeah
<flexiondotorg> Well, 16:00 was the plan.
<flexiondotorg> rcj, Just Lubuntu to go.
<flexiondotorg> wxl, ^^^^^^^^^^^^^
<Laney> I'm going to get lunch in a minute so at least 1 hour
<rcj> flexiondotorg, Laney: thx
<flexiondotorg> Laney, OK. I've just eaten.
<flexiondotorg> But someone put a beer in my hand.
<Laney> The horror
<infinity> flexiondotorg: If lubuntu doesn't show up on time, I'd make an executive decision based on their tests to releast amd64+i386 and skip powerpc.
<infinity> flexiondotorg: If I were you, anyway.
<flexiondotorg> infinity, Thanks for the pro tip :-)
<infinity> Aaaand, hopefully that's the last time I touch livecd-rootfs for another 6 months.
<cjwatson> bluff
<flexiondotorg> Laney, I've tried chasing Lubuntu in various channels. No feedback as yet.
<Laney> flexiondotorg: Give them until 5pm then execute the plan
<flexiondotorg> Laney, OK.
<flexiondotorg> Laney, you're actually releasing the images right?
<Laney> Oui
<flexiondotorg> Laney, perfect.
 * flexiondotorg goes to get a Whiskey.
<flexiondotorg> wxl Are the Lubuntu Alpha 2 images good to go? What about the PowerPC images? Do you want to include those?
<Laney> I don't think we're going to respin anything now
<Laney> infinity: go get all kernelly
<infinity> Mmmm, kernelly.
 * Laney gets all e-d-sy
 * Laney screams and goes to redirect the old ci-train dashboard to the new one
<jderose> infinity: do you plan to respin the 14.04.3 daily iso today with your totem/libwayland-egl-whatever fix?
<flexiondotorg> Laney, I got word from Lubuntu.
<Laney> secret word
<Laney> was it good word?
<Laney> or bad word? bird?
<doko> slangasek, infinity, Laney: can we turn on the approve queue for wily tomorrow morning, while preparing for the GCC ppa copy to the archive?
<flexiondotorg> Laney. Lubuntu do not want the PowerPC images releasing. The i386 and amd64 are good to go.
<flexiondotorg> Laney, I can't mark the Lubuntu images ready in the tracker.
<Laney> flexiondotorg: No worries, I can. Thanks!
<flexiondotorg> Laney, Those that can (from Lubuntu) are not available.
<slangasek> doko: by this, you mean freezing the archive?
<doko> slangasek, yes
<doko> I mean, manually accepting unaffected packages is fine
<slangasek> doko: can you clarify why you want this?  is it because you're worried about packages in this list having other uploads during the window?
<slangasek> an archive freeze is extra work for the release team, so would like to understand why it's needed
<doko> slangasek, I want to avoid having debian packages synced merged with 5 as the default before we make 5 the default
<doko> because then, we have to redo these transitions
<slangasek> doko: so gcc 5 will be made the default in Debian before it's made the default in Ubuntu?
<slangasek> I thought this ppa was going to be published tomorrow
<doko> yes, need the buildds to catch up rebuilding the qt5 stack
<slangasek> doko: I don't understand; you mean you're waiting to publish gcc5 to Ubuntu until the qt5 stack is rebuilt?
<doko> slangasek, yes, rebuild what is in silo16 in silo39, so we depend on the renamed libraries
 * flexiondotorg awaits further instruction from Laney
<Laney> flexiondotorg: I'm going to start publishing in 2 minutes
<infinity> doko: If you're just worried about autosyncs, we can disable the cronjob.
<flexiondotorg> Laney, What does that mean exactly?
<Laney> Making the ISOs exist in their final locations
<flexiondotorg> Right OK.
<Laney> Generating torrents, etc
<infinity> doko: But if you want the release team to approve every upload, it's vaguely non-trivial for us to know what an "affected" package is.
<flexiondotorg> OK, and when that is done you'll poke me to send the email?
<doko> infinity, ok with the autosyncs then
<infinity> doko: Sure.  Disabling autosyncs can be easily done.  Just let us know when.
<Laney> flexiondotorg: Yup
<slangasek> doko: ok, so the library package renames from seb128 are still in flight, and you're wanting to wait for these to finish before landing any of it to -proposed?  couldn't we publish silo16 immediately, follow through on the renames in silo39, and publish silo39 immediately to -proposed once it's also done?
<slangasek> doko: the only negative impact I see is that partial upgrades will be broken in the meantime inside -proposed, and we don't care about that
<Laney> rcj: Go for cloud image publishing when you're ready
<Laney> rcj: Syncing the rest out over the next hour-ish
<rcj> Laney, excellent
<doko> slangasek, I copied sources without binaries from 16 to 39, so these are different, and then will fail to copy from silo39
<doko> so maybe copy 39 first, and then 16, and you'll see the rejects what was already copied from 39
<slangasek> hmm
<slangasek> doko: so are all the packages copied to 39 that need to be?
<doko> slangasek, no, not yet. working on it ...
<doko> I hoped that the lib renames would be done today, but they are not yet
<slangasek> ok
<slangasek> seb128: how are you coming with the lib renames?
<doko> slangasek, http://pad.ubuntu.com/gcc-5-transition
<Laney> has nusakan been upgraded or something?
<Laney> ISTR checksumming taking ages before
<slangasek> Laney: certainly not
<slangasek> nusakan is unupgradeable
<slangasek> doko: what are you meaning to show me with that pad?
<Laney> It is already peak machine
<doko> slangasek, what is pending
<slangasek> Laney: no, it's in a maintenance dead-end until we migrate services to juju
<slangasek> doko: which part of that tells me what's pending?
<doko> cwidget - FTBFS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792681
<doko> google-perftools - FTBFS with gcc 5 (test failures)
<doko> libept - pitti; current version FTBFS in wily (Debian #788770), synced 1.0.13
<doko> qca2
<doko> snappy - check with the snappy team/mvo?
<doko> tagcoll2 - doko
<ubot93> Debian bug 792681 in src:cwidget "cwidget ftbfs with GCC 5" [Normal,Open]
<doko> zeitgeist
<ubot93> Debian bug 788770 in src:libept "libept: FTBFS in FindPkgConfig.cmake: No cmake_minimum_required command is present." [Serious,Fixed] http://bugs.debian.org/788770
<doko> I'm working on tagcoll2
<slangasek> doko: and all the libraries *not* on that list, which are included in silo 16, have been transitioned in silo 39?
<Laney> flexiondotorg: Image should start appearing on http://cdimage.ubuntu.com momentarily
<doko> slangasek, no, still rebuilding
<Laney> flexiondotorg: Takes a short while from here for the torrents to start working
<flexiondotorg> Laney, Is that a go for send the email?
<Laney> Probably wait until they're all available
<flexiondotorg> OK
<Laney> I probably wouldn't wait for all torrents to start working - usually just check one to see if the seed box is still alive
<Laney> but all HTTP downloads, sure
<cjwatson> Laney: checksumming> I improved the code a while back
<cjwatson> it does a better job of reusing the checksums that are already there nowadays
<slangasek> doko: "still rebuilding", but uploaded, yes?  that's the thing I'm asking
<Laney> cjwatson: Ah right - much appreciated
<cjwatson> Laney: the relevant change was probably the python rewrite, since it was bloody hard to get the logic right in shell :)
<cjwatson> er, yw
<cjwatson> ye
<slangasek> doko: I only show three packages currently building in silo 39
<doko> slangasek, can't yet copy. waiting on the armhf build. the packages don't have versioned b-d's
<slangasek> doko: can't copy what?
<slangasek> I'm just asking the status of the library package renames
<doko> can you call me? I don't understand you ...
<cjwatson> slangasek: reading the tea-leaves, qtbase-opensource-src is still building in silo 39 on armhf and so things on top of that in the stack can't start to build yet
<cjwatson> I think that is what doko means, apologies if I'm wrong
<slangasek> doko: have the source packages, that need renamed, all been uploaded to the silo?
<doko> slangasek, yes, but still left: libept, cwidget ("only" aptitude needs it), google-perftools, libept (currently doing it myself), qca2, snappy, zeitgeist
<cjwatson> doko: snappy> not the snappy team/mvo, since it's not that snappy
<doko> yes, I know, but we needed it
<slangasek> doko: thanks, that's what I wanted to confirm
<cjwatson> sure, just saying that arbitrarily giving it to the snappy team is not exactly fair
<doko> that was pitti's mistake in the etherpad, but I made the same when I asked mvo to work on it ;)
<flexiondotorg> Laney, no sign of Ubuntu Kylin or Ubuntu MATE on cdimage yet.
<Laney> still rsyncing
<flexiondotorg> k
<Laney> flexiondotorg: good now?
<flexiondotorg> Yep :-)
<Laney> 'k, my work here is done
 * Laney puts cron back on
<flexiondotorg> Laney, so I ping them email?
<Laney> If you're happy, I'm happy
<ogra_> uh, oh
<ogra_> who removed the comment in front of the vivid snappy image build line in nusakans crontab ?
<flexiondotorg> Laney, email sent but awaiting moderation :-(
<cjwatson> flexiondotorg: *clickety* no it's not
<flexiondotorg> cjwatson, Thanks.
<ogra_> (we definitely dont want daily vivid builds for snappy, that has been commented since vivid release day i think)
<Laney> flexiondotorg: Want to do the honours with the topic in here? :-)
<Laney> ogra_: You going to put it back...?
<ogra_> Laney, well, we seem to have a new process, i need a cdimage tree on this machine first ...
<Laney> so it should be uncommented?
<ogra_> i would appreciate if someone with am already set up tree could revert it
<ogra_> no, it shoudl be commented
<ogra_> we only want manual builds for vivid
<flexiondotorg> Laney, If you can give me super powers for a moment, sure.
<ogra_> (but want to have the line there as reference)
<Laney> flexiondotorg: You can do it, we're not +t in here
<flexiondotorg> OK
* flexiondotorg changed the topic of #ubuntu-release to: Released: Trusty 14.04.2, Vivid 15.04, Wily Alpha 2 | 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
<flexiondotorg> Laney thanks for your help today.
<Laney> flexiondotorg: thank *you*
 * ogra_ hugs Laney 
<ogra_> thanks !!
<flexiondotorg> lamont, yw
<flexiondotorg> Laney, yw
<bdmurray> infinity: could you fully phase the iproute2 SRU for trusty?
<infinity> bdmurray: Sure.
<infinity> bdmurray: Done.
<pleia2> I'm wondering if it's time to close down http://release-blog.ubuntu.com/ ?
<pleia2> since it went to the planet, I didn't used to replicate the fridge.ubuntu.com posts to the planet, but it's not being updated anymore so I've started replicating again
<slangasek> doko: snappy, surely this is a bug that this is in the seed at all
<slangasek> none of the revdeps are anything that should be in the seed
<pleia2> still, I check every release to see if release-blog has been updated just in case, and I'd rather not do that anymore :)
<bdmurray> infinity: thanks
<doko> slangasek, already built
<doko> argh, https://launchpadlibrarian.net/213120954/buildlog_ubuntu-wily-amd64.qtbase-opensource-src_5.4.2%2Bdfsg-2ubuntu2.1_BUILDING.txt.gz
<infinity> pleia2: Yeah, it's fairly dead.
<slangasek> pleia2: it's still documented as part of https://wiki.ubuntu.com/MilestoneProcess, so I wonder why that's being missed
<infinity> slangasek: It's been intentionally missed for years, but no one pulled it from the process page, I guess.
<slangasek> infinity: errm
<slangasek> I don't mind if the blog is dropped; I do mind if the checklist is ignored and no one bothers to update it :)
<slangasek> interesting, there's a thing called leveldb which is used by thumbnailer-service and depends on the other snappy
<slangasek> what are the odds
<slangasek> ok no bug here
<infinity> slangasek: I see no mention of it on *Process pages, I don't know what you're talking about.
<infinity> And I'm going to go "nap".
<infinity> flexiondotorg: I've always found that Tesla quote hilariously ironic.
<flexiondotorg> infinity, :-)
<infinity> No thrill that can go through the human heart?  Really dude?  Not even, I dunno, 240 volts?
<flexiondotorg> infinity, It was the Tesla quote or,
<flexiondotorg> "I am Groot" - Groot
<doko> Laney, thanks for paying attention what is in silo16 ... now merging my evolution-data-server changes
<Laney> hey doko, don't be angry, I'm going to do it
<Laney> (you can if you want though)
<doko> Laney, already done
<seb128> slangasek, http://pad.ubuntu.com/gcc-5-transition has the renames remaining
<slangasek> check
<doko> Laney, see https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+sourcepub/5267586/+listing-archive-extra
<doko> please don't update -proposed until we copy these ... and maybe another soname bump is needed
<Laney> doko: I'm hoping e-d-s migrates tonight... don't want to be entangled with gcc really
<doko> the hope with you may be
<bdmurray> arges, infinity, slangasek: Has an SRU team member talked to ubuntu kylin about their software-center SRU?
<slangasek> I have not
<slangasek> doko: do you have an estimate of how long it will take to get the rest of silo 39 built?
<slangasek> doko: trying to schedule the image testing with jibel, so that we can get this stack validated and moved on from -proposed as quickly as possible
<slangasek> and of course there's no sense in scheduling this for a time when we won't yet be able to build images
<doko> slangasek, building images means that all package have to be installable, which I suppose won't yet be possible
<doko> that was not the plan. and if you want to do that, then freeze the archive. the noise costs more and more time
<arges> bdmurray: i haven't
<robru> infinity: can you NEW review this packaging please? http://bazaar.launchpad.net/~unity-api-team/persistent-cache-cpp/devel/files
<slangasek> doko: those packages have to be installable at some point, in order for them to migrate to wily; my question was if you can estimate how long it will take to get them built, I guess the answer is no?
<doko> slangasek, I'm currently working up the qt5 stack. Mirv told me some rough order, so lets see how far this goes. In parallel I'll rebuild the phone stack. so maybe I can give you an answer in 3-4h
<slangasek> ok
<bdmurray> infinity: did you see my ping about ubuntu-archive-scripts and utopic? https://code.launchpad.net/~brian-murray/+junk/ubuntu-archive-scripts
#ubuntu-release 2015-07-31
<doko> slangasek, copied everything to 39, still building. will look at the ftbfs tomorrow. 16 should be obsolete
<sil2100> Hello release team! We need an archive admin to preNEW review a new package before publishing it through the train
<doko> sil2100, what is this? sounds scary before we copy the gcc5 silo
<michi> doko: Itâs code that is in thumbnailer at the moment. We are unbundling it so it becomes reusable.
<michi> Nothing depends on it right now.
<sil2100> https://code.launchpad.net/~unity-api-team/persistent-cache-cpp/devel <- here is the whole packaging + code
<michi> sil2100: Itâs been reviewed and passed already.
<michi> Check the comments in the âPassedâ column for silo 51 here: https://trello.com/b/AE3swczu/qa-testing-requests-for-questions-ping-ubuntu-qa-on-ubuntu-ci-eng
<doko> michi: but you don't plan to update thumbnauler now?
<michi> doko: Correct.
<doko> looking
<michi> We are leaving thumbnailer alone until the dust settles
<michi> sil2100: You need to click on the silly speech bubble to see the comments.
<doko> hmm, it's not in the NEW queue ... https://launchpad.net/ubuntu/wily/+queue?queue_state=0
<sil2100> It's not NEWed yet, we're required to get a preNEW review before pushing it
<sil2100> I can publish that to the NEW queue tho if you prefer
<doko> ahh, sorry, can't help with this
<michi> sil2100: Itâs not important for this to go in dokoâs PPA. I just want to get the package accept so we (and others) can eventually start using it.
<doko> jibel, did slangasek talk to you yesterday?
<jibel> doko, he didn't
<doko> jibel, he proposed that you could be able to do an image build using the landing39 ppa. not sure how fast you could do that
<doko> does this make sense?
<doko> otoh, it may fail, because we didn't yet rebuild anything for the renamed libraries
<jibel> doko, what would be the difference between an image built from wily + ppa 39 and an image built from proposed on ppa 39 is copied?
<jibel> once*
<doko> jibel, wily + ppa39 definitely won't work at this point. I think he meant proposed + ppa39
<jibel> doko, if everything is installable building from the PPA can be an option
<doko> jibel, sure, that would be good to know
<doko> jibel, assuming you would work on this, when could such a test be finished?
<jibel> doko, for today it's a bit late notice. Time to build an image I won't have any tester left
<doko> ok, then let's do it without it
<doko> the copy
<slangasek> doko, jibel: I did not propose doing an image build using the landing-039 ppa; I was only asking how long we expected it to take for all the packages to build.  The plan for getting a test image is to build against -proposed once the phone stack is coherent there, which is a daunting prospect in itself
<jibel> slangasek, makes sense. That was my understanding of your discussion with doko yesterday.
<jderose> infinity: totem is launching fine and dandy in today's 14.04.3 daily... thanks! :D
<infinity> jderose: Good deal.
<infinity> jderose: I'm not happy with my "fix", but it was the same hack we used for .2, and no one complained there either. :P
<infinity> (Well, similar, not identical, or I would have noticed the bug)
<jderose> infinity: guess adding one line to debian/control for the appropriate mesa package is too hard :P
<jderose> for someone, not you, of course :)
<infinity> jderose: Well, one first needs to figure out where "appropriate" is, then the investigation of WTF that's needed at all (it probably should be a conditional load, and it's a bit broken), then a full SRU verification to get it in.  And the guy responsible is on vacation. :P
<infinity> jderose: So, a hack works for now.  If a later SRU fixes it better, no one will notice. :P
<jderose> infinity: gotcha... and i'm just being a little ornery anyway :P
<slangasek> so, if ofono-qt and maliit-framework have made their way into wily, does that mean they didn't actually need g++ rebuilds, or is something broken...
<infinity>  Depends: libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), libqt5core5a (>= 5.2.0), libqt5dbus5 (>= 5.0.2), libstdc++6 (>= 4.1.1)
<infinity> So, unless something has broken shlibs or a broken symbols file, I'd say no rebuild was needed.
<infinity> Given that qt5core didn't have a package name change, that would imply its rdeps don't need a rebuild...
<infinity> Ditto for qt5dbus.
<infinity> No idea if my inference is actually correct, mind you, but people seemed to be taking the rename thing seriously, so...
<infinity> Of course, given that libstdc++6 deps seem to be (correctly) generated from symbol availability, rather than a hardcoded shlib, that also means the tracker "good" string was a bogus lie.
<infinity> Since anything that didn't actually need a transition will be listed as "bad" no matter how many times you rebuild it.
<infinity> slangasek: Any objections about me fasttracking that apt/trusty SRU (and releasing on a Friday, oh noes!) once I've re-run all my testcases against the archive build and confirmed it's not broken?
<infinity> slangasek: It's the only SRU blocking me turning off -proposed in the trusty dailies, which I'd like to do to (a) unblock the kernel team, and (b) have the images over the weekend be a better representation of the final 14.04.3 builds.
<slangasek> infinity: I'm afraid my brain misses context for the apt SRU
<infinity> https://launchpad.net/ubuntu/+source/apt/1.0.1ubuntu2.9
<slangasek> and 1429041 was the preivous SRU?
<infinity> Yeah.
<slangasek> (and is the test case from there part of the build-time testsuite?)
<infinity> It's not.  I need to learn the apt testsuite and submit two tests upstream, for both these regressions.
<infinity> But, for now, I have manual tests to confirm both.
<infinity> Manual tests all passed on my test binary built at home, just need to re-run them on the archive build.
<infinity> THough, if the results differ, we have much bigger problems. :P
<slangasek> infinity: ok, looked at the patch and it's clearly limited to things that are Never-MarkAuto-Sections (which seems like a good thing to say in the Regression Potential bit?) so if you've tested that it does what you need for the point release I'm ok with fast-tracking
<infinity> slangasek: Right, re-running tests now.  Well, reruning the 1429041 tests.  The actual bug I was fixing is v-done based on the kylin livefs not being completely busted anymore.
<infinity> (They remove ubuntu-desktop as part of their build, which is what exposed the regression)
<infinity> slangasek: Alright.  Bug spammed with much testing output.  It all looks good to me.  Want to double-check to see if I'm stupid before I release?
<infinity> Next week, I'll have to fix this in wily, vivid, and I suspect also precise (haven't tested there yet).
<infinity> Err, I am stupid.  My test removed the wrong package on the second pass.
 * infinity redoes that bit.
<infinity> slangasek: Okay.  Now all good.  :P
<infinity> slangasek: Oh.  You seem to be away, according to your IRC client.  I'll trust my own testing on this one. :P
#ubuntu-release 2015-08-01
<infinity> bdmurray: Since you reviewed/accepted the gtk+2.0 upload to precise, can you do the same for trusty?  I assume the context is sort of fresh in your mind.
<darkxst> infinity, we are still blocked on bug 1466290, any chance you can take a look over that?
<ubot93> bug 1466290 in gnome-online-accounts (Ubuntu) "Update to 3.16" [Medium,New] https://launchpad.net/bugs/1466290
<slangasek> can anyone explain to me why python-pbr shows up in the python3 transition tracker?  it has neither a build-depend on python3-all-dev nor a dependency on python3 << 3.5... http://people.canonical.com/~ubuntu-archive/transitions/html/python3.3-5.html
<slangasek> oh, sorry, was looking at the vivid version
<slangasek> still, it build-depends on python3-all-dev but doesn't depend on python3 (<< 3.5), so I'm not sure why it shows as 'bad'
<slangasek> oh, there we go, depends: python3.4
<Logan> slangasek: Ben can be a mystery sometimes :/
<slangasek> Logan: in this case I just hadn't read the ben rules completely because I assumed I knew what they were, and then found that python-pbr has some amazingly broken packaging :)
<infinity> slangasek: Less urgently, there are the matching apt SRUs for vivid and precise ^
<infinity> slangasek: And wily is in proposed.
#ubuntu-release 2015-08-02
<Logan> are we still not uploading stuff because of GCC 5?
<Logan> jk, I see the followup email
<xnox> publisher is so slow.
<xnox> i'm so used to per-build publisher we are running in koji.
<slangasek> well, it took a bit for ben to finish running, but there are transition trackers up now for each of the gcc5-induced package name changes that seb128 prepped last week. http://people.canonical.com/~ubuntu-archive/transitions/
<doko> slangasek, icu is missing
<slangasek> hmm checking
<slangasek> doko: icu had no package name change in landing-039
<doko> libicu52 -> libicu55
<slangasek> sure
<doko> already had that in landing-019
<slangasek> so I haven't tried to capture those yet
<doko> or 16
<doko> icu: libicu52 -> libicu55. Only partial rebuilds for now
<doko> boost1.58: 1.55 -> 1.58, only partial rebuilds for now
<doko> apt: libapt-pkg4.12 -> libapt-pkg4.16. only partial rebuilds for now
<doko> process-cpp: libprocess-cpp2 -> libprocess-cpp3
<doko> net-cpp: libnet-cpp1 -> libnet-cpp2
<doko> dbus-cpp: libdbus-cpp4 -> libdbus-cpp5
<doko> libphonenumber: libphonenumber6 -> libphonenumber7
<doko> trust-store: libtrust-store1 -> libtrust-store2
<doko> unity-scopes-api: libunity-scopes3 -> libunity-scopes1.0
<doko> these were the ones already done in 16
<slangasek> yes.  there are a lot more library transitions that still need to be tracked besides the v5 ones
<slangasek> I'm saying that the v5 ones have transition trackers up - so people can start claiming those and working through them
<doko> ok
<slangasek> I'm also working through what's wrong with qtdeclarative5-ubuntu-ui-extras0.2 still, so we can get test images build against -proposed for touch
<slangasek> (needs to be done today, to let the testing happen on schedule)
<doko> what do you see?
<slangasek> right now I just get a build failure from apt saying ' ubuntu-touch : Depends: qtdeclarative5-ubuntu-ui-extras0.2 but it is not going'
<slangasek> 'to be installed'
<doko> ahh, libexiv2-13v5,
<doko> reuploading
<slangasek> ?
<slangasek> don't
<slangasek> I already did that once
<doko> ohh
<slangasek> doko: I can investigate this one, I was meaning to let people know I was doing so
<doko> slangasek, it's hard-coded dependency :-/
<slangasek> yes, I started to suspect this
<slangasek> I already fixed one of those last night
<doko> why don't they use shlibs:Depends?
<doko> anyway, I'm fixing it, and filing a bug report
<slangasek> they do use shlibs:Depends; I'm just about to dput
<slangasek> you can go work on another corner ;)
<doko> ok, fine =)
<slangasek> I see that some of the libraries with v5 name changes already have complete transitions, they're "only" blocked by gcc-5 now, which is pretty nice
<slangasek> what are the prerequisites for dropping the blocker bug for gcc-5?
<slangasek> 1) positive results from phone testing
<slangasek> 2) batch uploads of the remaining library package name changes?
<doko> not sure about 2. at some point, we probably don't care anymore about the renaming?
<slangasek> doko: I'm intending to batch upload the remaining libraries this week
<slangasek> I don't know if seb128 has any scripts that I should leverage, but if not I'll script something up.  should only take a couple of hours for the scripting and a couple of days for the uploads ;)
<doko> slangasek, can you avoid to rename those where debian decided not to rename? or else we'll carry a delta forever
<doko> I don't think he finished the script
<slangasek> doko: well, I think I pointed out that the rename can be reverted and the delta can be dropped immediately after the wily release
<doko> ok
<slangasek> doko: if you have a list of source packages that I should blacklist because we know Debian won't change the name, that would certainly simplify
<slangasek> but I expect this to be a small minority of packages
<slangasek> ubunt-ui-extras published, reattempting test image
<doko> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libstdc%2B%2B-cxx11;users=debian-gcc@lists.debian.org
<slangasek> there's still an x86-specific issue regarding qtmir-android et al if anyone wanted to look at that; otherwise I'll look later
<doko> would need looking at the closed issues
<slangasek> doko: if you can give me a list of source packages to blacklist, I'll take it.  But I'm not going to sift through the closed bugs right now to figure out which ones were closed without name change
<doko> ok, I'll do that tomorrow
<xnox> slangasek: i'm not sure if i did cgal mygui & console-bridge
<xnox> i rebuild them v5-less at first, then with proper v5 in place, but it might be too early one.
<xnox> see last commits on transition tracker and/or new queue
#ubuntu-release 2016-08-01
<slangasek> LocutusOfBorg: ^^ accepted; as far as future LTS syncing, the release schedule for the point releases is knowable in advance, you can always just pre-upload them and let them sit in dep-wait until the rest of the LTS stack is available
<LocutusOfBorg> thanks slangasek, it has sit in my ppa in dep-wait for some time, and I though it was fine to upload when it was buildable...
<LocutusOfBorg> next time I'll upload it before thanks
<Mirv> ^ libwfut and eris are syncs from Debian that used to be in Ubuntu before being removed as part of the GCC 5 transition.
<Mirv> now requested in the sponsoring queue
 * apw is handling ^
<Laney> meh
<Laney> https://launchpadlibrarian.net/276128735/buildlog_ubuntu-yakkety-amd64.adwaita-icon-theme_3.20-3ubuntu1_BUILDING.txt.gz -> gtk-3-examples -> libgtk-3-0 -> libgtk-3-common -> adwaita-icon-theme (>= 3.20)
<Laney> I could build in a PPA without proposed and copy binaries over - it's arch:all
<Laney> someone scream if that is terrible
<Laney> done, no point in screaming now
<Mirv> is there some GTK related issue with proposed, I'm getting https://launchpadlibrarian.net/276121156/buildlog_ubuntu-yakkety-amd64.uim_1%3A1.8.6+gh20160630.0.c408e95-1build1_BUILDING.txt.gz ?
<Mirv> just related to what Laney said and mentioning gtk
<Mirv> or is that adwaita fixing the issue?
<Laney> i think so
<Laney> wait for it to publish out
 * Laney is running watch -n30 rmadison -s -Syakkety-proposed adwaita-icon-theme
<Mirv> great
<Laney> s/-s -S/-S -s/
<Laney> sssssssSSSSSSSSSSsssssSSssssSssssSSSsssS
<davmor2> infinity: are we not working to a .5 release this week on the tracker? I assume we use daily for now right?
 * Mirv fixes poppler in proposed
<Mirv> FYI I'm waiting for some investigation / whitelist of failing autopkgtests for a handful of KDE packages, and also waiting similarly for Unity 8, and then Qt 5.6 / KDE transition to release pocket should be possible (or at least nearer to possible)
<apw> davmor2, yes, there should be .5 this week
<tjaalton> infinity: what was crufty with my xorg-lts-xenial upload? I don't see anything here
<tjaalton> on my tree
<tjaalton> infinity: oh the merge conflict stuff.. hmm maybe I cleaned those after upload then
<tjaalton> don't see then on that upload though
<tjaalton> them
<infinity> tjaalton: I reuploaded... The one in the rejected queue is quite a bit different than the one I uploaded.
<infinity> davmor2: Do some testing with dailies please, yes.  I'll upload base-files (no need to file that bug :P), create the milestone and spin RCs after I've napped.
<tjaalton> infinity: got it, didn't delete the unrenamed crap from the git tree once copying over the scripted result
<infinity> pitti: Did you sprint take into account an attempt to clean up `reverse-depends -b src:upstart`?  Would be nice to fix all that, so people stop doing misguided things like removing s390x binaries. :P
<davmor2> infinity: I decided to test the apps on the live session instead and makes sure they all open and close and save stuff :)  go sleep dude
<pitti> infinity: actually we have the opposite problem: many things depend on upstart without saying so
<infinity> pitti: Well, both are bad, clearly. ;)
<pitti> infinity: ah no, we didn't look at build deps
<pitti> infinity: tedg and I looked at porting ubuntu-app-launch
<pitti> so that is part of that
<infinity> pitti: To be fair, I think we'll have to fix the "s390x" bugs at some point anyway, cause they're not s390x bugs, they're "upstart's testsuite fails on xenial kernel" bugs, and s390x just happened to be the only buildds running xenal during that cycle.
<pitti> but https://code.launchpad.net/~ted/unity/systemd-unit./+merge/300584 does not yet  drop the build dep
<infinity> If we ever try to SRU upstart in xenial, it'll explode on all arches.
<xnox> not funny
<infinity> xnox: Not funny, but true. :/
<infinity> xnox: I can reproduce the testsuite failures on my laptop.  Well, some of them.
<pitti> infinity: but at least the libupstart-dev deps can't be dropped yet until we  finish the transition
<tsimonq2> infinity: hey, any chance you'll get to take a look at those PRs? sorry for poking you, it would just be great to get it done and over with
<infinity> tsimonq2: Perhaps after 14.04.5 happens.  I have priorities.
<tsimonq2> infinity: alright, sounds good
<infinity> pitti: If you're still around, a base-files landing in trusty that needs a quick review.
<infinity> pitti: ^-- And there it is.
<pitti> infinity: I wait a bit until it becomes diffy
<infinity> pitti: Kay.  I'm going on a coffee run, hoping it's built by the time I get back. ;)
<pitti> infinity: (accepted)
<infinity> pitti: Ta.
<dmj_s76> infinity: I found a couple issues with 14.04.5 regarding nvme drives as well as nvidia cards with the proprietary drivers
<infinity> dmj_s76: Regressions?
<dmj_s76> infinity: bad ones
<infinity> cyphermox: ^-- You know anything about changes to nvme handling between 14.04.4 and 14.04.5?
<dmj_s76> with the daily iso, after you install onto an nvme drive, you get dumped to an initramfs prompt
<infinity> dmj_s76: proprietary drivers, we can do very little about.
<infinity> dmj_s76: To be clear, that's *not* an issue with 14.04.4?
<dmj_s76> infinity: That's correct
<infinity> dmj_s76: Kay.  Is there a bug?
<infinity> dmj_s76: If so, can we get some debugging info from .4 and .5?  dmesg, lsmod, name of device it's installing to, blah blah?
<dmj_s76> infinity: Was just about to file bugs, but wanted to signal a heads up first
<infinity> dmj_s76: Is this d-i (ie: server ISO) or ubiquity (desktop/live)?
<xnox> dmj_s76, uefi or bios?
<dmj_s76> ubiquity.  I haven't verified with server yet.
<dmj_s76> currently testing on uefi systems
<dmj_s76> may affect bios, but I haven't checked yet
<dmj_s76> separately, various (all?) versions of the nvidia proprietary driver result in an infinite login loop
<dmj_s76> that's a regression from 14.04.4 as well
<xnox> hmmm.... does nvidia in 14.04.5 match the right x-server bits and kernel?
<infinity> It's meant to.
<infinity> Alberto claimed it works.
<infinity> His claim may have been incorrect. :P
<apw> there are cirtainly dkms packages which at least build for that combination
<apw> dmj_s76, your efi systems, are they secure boot enabled ?
<dmj_s76> apw: We disable secureboot
<apw> are these the uber new nvidia ones ?  though i thought we pulled in something for those for you
<dmj_s76> I'm testing on both nvidia 9 series (maxwell) and nvidia 10 series (pascal)
<dmj_s76> ...you did pull new nouveau support that fixes pascal
<dmj_s76> ...into 16.04.1
<dmj_s76> What I'm seeing now, is that nouveau works fine on the maxwell systems (970M and 980), but the moment you install nvidia, you can't get past the login screen
<infinity> dmj_s76: Disabled SB from the BIOS, you mean, or the module signature validation disabling thing?
<infinity> apw: I assume that patchset it meant to ignore bad/no sigs if SB is entirely disabled.  I hope.  Did we test that? :P
<infinity> s/it meant/is meant/
<infinity> apw: Or were we so focussed on MOK variables that we didn't think of that?
<apw> infinity, as i remember things they are both the same in the kernel both mean "off"
 * infinity might need to slap some USB storage into his nvidia desktop to do some testing.
<infinity> Though my card is ancient, so if it's a driver bug, I doubt I'll trip it.
<infinity> But if it's something *we* broke..
<infinity> Oh.  Wait.  My desktop is also ancient and not EFI.
<infinity> Derp.
<infinity> Ahh, but my old laptop is EFI and nvidia.
<ogra_> infinity, hmm, when i select proposed in my snap builds i dont actually end up with proposed in the toplevel sources.list ... i assume lp-buildd somehow stores that in a different place ?
<ogra_> i was trying to add something like:
<ogra_> ifneq ($(shell grep $(RELEASE)-proposed /etc/apt/sources.list),)
<ogra_> ENV += PROPOSED=1
<ogra_> endif
<ogra_> to my ubuntu-core makefile
<infinity> ogra_: I don't know what "select proposed" means in this context.
<ogra_> (indeed that would have to be finer grained)
<infinity> ogra_: Pointer to the UI you're looking at?
<ogra_> https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core
<ogra_> if you click "request builds" (at the bottom) there is an archive selection pulldown
<infinity> ogra_: pocket for automatic builds?
<ogra_> defaulting to Updates
<dmj_s76> infinity: It's disabled from the BIOS
<ogra_> if i select Proposed there i assume that proposed shows up somewhere in my build env
<davmor2> infinity, jibel: good news I finished testing all the apps installed by default, they all open, close and do stuff as expected woohoo moving onto actual installs now
<ogra_> but grepping for it in the build logs there seems to be no trace unless i manually add PROPOSED=1 to my ENV var ... (then i get proposed only inside the live-build chroot
<infinity> dmj_s76: Can you try running "sudo update-secureboot-policy" and see if that magically makes it happy after reboot and fiddling?
<ogra_> )
<infinity> ogra_: That sounds like a bug on Colin's part.
<ogra_> ah, right ... he seems to be off today (i pinged him in #snappy before)
<infinity> ogra_: Oh, wait.  Are you doing automatic builds, or one-off?
<ogra_> infinity, nowadays i do them through an lp-lib scripts, but they dont change no matter how i trigger them ...
<ogra_> proposed never shows up ... neither in manual, nor in automatic, nor in lp-lib triggered ones
<infinity> ogra_: When you trigger via the API, it's like asking for a one-off build.  You have to specify the right pocket.
<ogra_> right, i do that
<infinity> ogra_: How?  Show me the code.
<ogra_> infinity, ok, shade your eyes ... http://bazaar.launchpad.net/~snappy-dev/ubuntu-core-snap/trunk/view/head:/cron-scripts/lp-build-ubuntu-core thats the api code
<ogra_> when i change line 68 to "Proposed" i dont see any change in the build logs
<ogra_> but it really doesnt matter how i trigger the build ...
<ogra_> they all behave the same
<ogra_> should launchpad-buildd actually mangle the sources.list ?
<ogra_> to add -proposed ?
<infinity> Yes.
<infinity> This is clearly a bug, if it's not working.
<ogra_> ok
<infinity> For example, this is how I build a livefs in a PPA with proposed: lp.load("/~ubuntu-cdimage/+livefs/ubuntu/trusty/xubuntu").requestBuild(archive="/~adconrad/+archive/ubuntu/ppa",distro_arch_series="/ubuntu/trusty/amd64",pocket="Proposed")
<infinity> Which is basically your code, but s/livefs/snap/
<infinity> So, if it's not making the outer chroot have proposed for you, someone screwed up.
<infinity> Or you can't spell "proposed"
<infinity> Pick one.
<ogra_> it works fine if i export PROPOSED=1 in the live-build call ... so i'll go with that for the moment ... it is just nasty having to change the tree every time i want to toggle it
<infinity> Right, you shouldn't have to do that. ;)
<infinity> Plus, you want proposed in the *outer* chroot if you're testing against a proposed livecd-rootfs, etc.
<ogra_> indeed, i was trying to get the info dynamically from the outer chroot
<infinity> Which is the point of specifying the pocket.
<infinity> Or, one point.
<ogra_> which is why i sumbled over the issue
<ogra_> *stumbled too
<infinity> So, double-check all your spelling and make sure you're reading your build logs right, and when you're sure you're not doing something Colin will smack you for, report a bug and get grumpy. ;)
<ogra_> heh
<xnox> ogra_, for cloud images i recall having to specify proposed multiple times, in json build config _and_ the target ppa
<xnox> sources
<dmj_s76> infinity: no, running update-secureboot-policy from the root recovery terminal doesn't fix it (the nvidia issue)...nvme can't get to recovery mode
<ogra_> xnox, yeah, but then the GUI option in the lp page is pointless ...
<infinity> xnox: That's patently untrue.  cloud-images are just livefs builds.  If you have to specify it more than once, it's because you specified it wrong the first time. :)
<infinity> dmj_s76: Did that give you a mokutil thing on reboot, etc?
<xnox> infinity, so if the target of the livefs build is a ppa, it must have proposed enabled. as far as i can tell, and then pocket=Proposed needs to be specified in the requestBuild too.
<xnox> at least that did the trick for me, way back when i was fiddling with cloud images for s390x
<infinity> xnox: Oh, yes.  But no json needed there...
<infinity> xnox: That's just about archives.
<infinity> ogra_: xnox does make a point.  The archive you're specifying, what pockets does it build against?
<ogra_> uh, main only i think
<infinity> pockets...
<xnox> true. json was for ext4 or some weird thing. all i remember it was annoying =)
<infinity> Not components. :)
<infinity> ogra_: If it's a PPA, they usually default to updates.
<infinity> I think.
<dmj_s76> infinity: hrm...no, actually
<ogra_> "Default (security dependencies and recommended updates)." is checked
<infinity> Right, updates.
<infinity> ogra_: Change that to proposed and try again.
<ogra_> hmm, i dont really want the packages in there to build against proposed
<infinity> ogra_: I know, just change it and do a test build and change it back.
<ogra_> i just want proposed packages in the resulting image
<ogra_> k
<infinity> ogra_: If that test build does as you expect, then we at least understand the behaviour.  And you can either do your builds in a proposed PPA versus an updates PPA, or we can figure out a way to poke the PPA deps via the API at build time.
<ogra_> https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core/+build/2263 ...
 * ogra_ twiddles thumbs
<ogra_> i love doing test builds on ppc64el ... nobody uses them in snappy and they are faster than anything :)
<infinity> Bah.  Didn't see the apt output in the logtail.  Now I have to wait. :)
<ogra_> it takes less than 10min
<infinity> ogra_: Those IBM disk controllers are reasonably impressive (in response to your comment on speed)
<infinity> I mean, the CPUs are no slouch either, but this is mostly disk.
<ogra_> yeah
<dmj_s76> infinity: There ought to be no secureboot anything going on here.
<infinity> Entertaining side note, the storage subsystem of the s390x mainframes is just a POWER system with the same RAID controllers in it as those ppc64el machines. ;)
<ogra_> heh
<ogra_> well, i'd use s390x builds for testing if i had that arch in my snap setup yet :)
<ogra_> but ppc64el is equally good for that purpose
<ogra_> they are both exotic in the snappy world :)
<ogra_> and it is done ...
<ogra_> aaand i see proposed *everywhere* !
<xnox> infinity, so we can use our mainframe as ubuntu ppc64el builders too?
<xnox> nice
<ogra_> so yeah ... obviously the PPA setup is at fault
<xnox> ogra_, it works now?
<ogra_> xnox, well, the outer build chroot shows proposed on apt update ... so yeah ... that was what i was missing
<ogra_> my prob is that i dont want the packages in the PPA i use to build against proposed ...
<infinity> xnox: Only if you can figure out how to install Ubuntu on the storage server and still have it serve slices to the mainframe. :P
<infinity> ogra_: Right, so the quick fix is to have two PPAs.  Build your packages in your updates PPA, copy them to the proposed PPA, and build updates snaps in A and proposed snaps in B.
<infinity> ogra_: The better solution is asking William or Colin if there's a way to set PPA deps per-build via the API and, if not, if they can give us a way.
<ogra_> yeah, something like that ... but it is a bit sad ... the GUI option should actually override that imho
<ogra_> (and simply add proposed to the sources.list when i select it)
<infinity> ogra_: And I agree, this misfeature is dangerously close to a bug.
<xnox> i think there is json to enable arbitrary repos for the "inner build"
<xnox> but i can't remember it anymore
<infinity> ogra_: Building things this way isn't heavily tested yet, so it might just be a bug.
<xnox> need to dig into livebuild lp:lp code
<ogra_> xnox, forcing the inner build to proposed isnt my issue ... i wanted to cleverly read the info from the outer build so i dont need to change the code every time
<ogra_> techincally i can build wnat i want today
<infinity> ogra_: (ie: it's mostly just been used for one-off livefs testing, and the people who do that a lot probably have the "right" pockets in their PPA and never noticed the issue)
<ogra_> yeah
<infinity> ogra_: So, yeah.  File a bug, let's talk it over with the LP folks, but you have a workaround for now at least.
<ogra_> right
<cyphermox> infinity: nvme: well we know dmj_s76 has filed a bug about nvme in general, which probably needs SRUing
<xnox> cyphermox, but apperantely 14.04.5 regressed vs 14.04.4 and we did nothing there, no?
<cyphermox> no
<infinity> This is what he claims...
<dmj_s76> cyphermox: two separate issues
<infinity> Would be nice to get to the bottom of this.
<cyphermox> I wouldn't be able to tell if it regressed, I would expect not
<infinity> Ideally today.
<xnox> horum
<xnox> i have nvme laptop.
<dmj_s76> cyphermox: the existing bug applies to bios installs and the ubiquity graphical installer
<infinity> cyphermox: Can you work with him to get a bunch of debugging info from .4 and .5 and see WTF is going on, or at least try to make sense of it?
<xnox> it's not full system backed up. I don't even know how to do that for a windows & ubuntu dual install.
<infinity> xnox: dd
 * xnox ponders if i can try tripple-boot
<dmj_s76> the issue in 14.04.5 is separate and applies to successful installs, which get past brub
<dmj_s76> *grub
<xnox> infinity, that laptop's nvme is a handy 1TB drive =) so i need a spare 1TB somewhere else.
<infinity> xnox: That must have cost a bit.
<dmj_s76> xnox: wow, that's a sweet nvme
<xnox> 1 700 old pounds
<infinity> Ouch.
<dmj_s76> Mine's a 512 GB
<cyphermox> dmj_s76: please make sure you have a bug for each individual issue so we can make sense of it all
<xnox> it has ininity tiny bazel 4k touch screen too, 17"
<infinity> Yeah, I thought my 1TB SATA 850 Pro was expensive and fancy, but you've got me beat for extravagant spending. :P
<xnox> well 1 700 is for the whole laptop. Just 1TB alone, i can't remember how much it was.
<xnox> but then i blagged discount of dell.com/uk chat function (after abandoning shopping cart 3 days in a row)
<xnox> (cause they track that)
<infinity> Though, in real-world use (not synthetic benchmarks), I wonder how much your nvme really outperforms my sata SSD.
<xnox> it doesn't feel any faster than server grade SSDs
<xnox> but 1TB on a laptop is nice.
<infinity> Yeahp, I enjoy my 1TB SSD.
<dmj_s76> Depends on if you're doing a bunch of IO intensive stuff
<infinity> My data is goldfish-like, I never need the space, but as soon as I have it, it's full. :/
<dmj_s76> It's nice for manipulating GB+ images for instance
<infinity> Oh, FFS Lenovo.
<infinity> I don't think my old Thinkpad can disable SB.
<infinity> That has to be against spec.
<apw> infinity, really? i am supprised
<cyphermox> which device?
<infinity> t420s
<infinity> Maybe they didn't think it necessary, since you can bypass it entirely by switching to Legacy BIOS mode.
<cyphermox> weird. X230s could
<cyphermox> where you disable SB, you can put it in Setup mode.
<cyphermox> s/disable/configure/
<cyphermox> or enable CSM support, which can't allow SB.
<infinity> I literally don't have the Secure Boot menu option that I see on screenshots from the **30 series.
<cyphermox> well, it used to not be under Secure Boot specifically
<infinity> And that's definitely against spec.
<xnox> infinity, my old Gauja laptop hid the SB menu inside the "disk password" sub menu
<dmj_s76> cyphermox: do you expect this nvme->initramfs issue will be an ubiquity issue or another package?
<cyphermox> if it's after you've installed, then it's another package
<infinity> Oh, I wonder if it's the inverse, that it doesn't support SB at all.
 * infinity tests theory.
<infinity> The **30 series might have been the first that was SB-enabled.
<infinity> If this experiment goes sideways, I guess I'll be stuck playing in qemu.
<infinity> ovmf makes me want to stab myself.
 * xnox derp. got +mac, not -amd64.iso
<xnox> ok doing UEFI, no secure boot, trusty desktop install
<xnox> with nvme
<infinity> Doing the same, minus nvme.
<infinity> Well, unsure about secureboot.  Could be on, could be off, LENOVO WON'T TELL ME!
<infinity> But the kernel will, later. :P
<infinity> Maybe.
<xnox> is your test machine with nvidia?
<infinity> It is.
<infinity> Pretty old, but nvidia nonetheless.
<infinity> (Well, intel/nvidia optimus mojo, but I have it set to nvidia-only to avoid confusion)
<dmj_s76> xnox: nvidia shouldn't matter too much wrt the nvme issue
<infinity> After typing on the new Lenovo keyboard for a couple of years, the old keyboard feels really weird.
<xnox> install finished, restarting
<xnox> omg upstart
<apw> dmj_s76, which kernel module supports your nvme drive ...
<xnox> it may or may not restart =) it is ovmf after all
<xnox> dmj_s76, confirming drops to initramfs
<xnox> in kvm-qemu with uefi and ovmf
<dmj_s76> It's a samsung 950 pro...
<xnox> i didn't bother seting up nvram storage for variables, but that should not matter, after manually selecting nvme drive in the uefi shell to boot grubx64 it drops to initramfs
<xnox> apw, cyphermox - there is no nvme.ko in the initramfs
<dmj_s76> lspci reports that it uses the 'nvme' module
<cyphermox> xnox: ok?
<xnox> also
<xnox> (initramfs) modinfo nvme
<xnox> modinfo: cna't open '/4.4.0-31-generic/': No such file or directory
<xnox> should't that be like -> /lib/modules/4.4.... ?
<xnox> i recall we were patching something rather to include nvme by default
<xnox> did that make it back to trusty?
<apw> xnox, well it worked in .4 i think we were told
<xnox> apw, sure, but .5 installer is now built with xenial stack
<xnox> no? hence it's all different again.
<apw> xnox, right but nvme in the initramfs is an initramfs-tools thing normally
<xnox> I see copy_modules_dir kernel/drivers/nvme in xenial initramfs-tools
<xnox> but not in trusty
<apw> xnox, indeed ... which would imply .4 would not have worked either
<infinity> apw: Or maybe they used a different driver in 4.2
<xnox> apw, infinity - https://anonscm.debian.org/cgit/kernel/initramfs-tools.git/commit/?id=fe30453892d21ed20014e48f597be2a79ac99d26
<xnox> infinity, i think at one point it changed to subdir from just nvme.ko
<xnox> i do recall uploading that fix into initramfs-tools and saying we will have to backport that to "$foo" or some such
<infinity> apw: We should probably sync the driver list from xenial back to trusty (or, rather, add any missing ones, not remove any).
<infinity> apw: Any chance I could get you to look at that before you clock out?
<xnox> can't remember if that $foo was trusty or $clear-linux
<apw> infinity, yeah will have a look if they are in the same form, if so then it should be easy
<xnox> i guess i can boot that system as -sda
<xnox> update initramfs with that one line in
<xnox> reboot with nvme again to check it's all good
<infinity> xnox: Yep.
<xnox> because i need to run to beach volleyball in the rain soon
<infinity> It was probable in the block subdir before.
<infinity> Derpy derp.
<xnox> ah comment is nice
<xnox> nvme moves to its own directory in Linux 4.4, so include modules
<xnox> from there.
<infinity> Yep.
<infinity> That explains the regression.
<infinity> But worth a check of all changes to the module list between trusty and xenial to see if we're missing anything else too.
<apw> ugg they are in utterly differnt forms
<infinity> apw: That one spot isn't.
<infinity> apw: But yeah, the big lists might be problematic.
<cyphermox> xnox: sounds like you have a fair handle on this, can I ignore that initramfs issue and focus on the other nvme bug with ubiquity?
<xnox> with copy_modules_dir a following pokemon appeared in the initramfs
<infinity> cyphermox: I think so, yeah.
<xnox> kernel/drivers/nvme/host/nvme.ko
<xnox> rebooting to test
<xnox> umount: invalid option -- 'R' ->>>> argh!
<cyphermox> xnox: you mean "Arrr!"
<davmor2> cyphermox: I've told you before Ubuntu-Pirate isn't an official release
<cyphermox> killjoy.
<xnox> it boots
<infinity> xnox: \o/
<xnox> infinity, do i have a bug number for sru upload?
 * xnox makes one
<xnox> voila there is one
<xnox> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1608622
<ubot5> Launchpad bug 1608622 in initramfs-tools (Ubuntu) "14.04.5 drops to initramfs prompt during boot with nvme drive" [Undecided,New]
<infinity> xnox: I have apw trying to reconcile the whole module list, not just nvme.
<infinity> xnox: If he fails at that, we'll just fix this one bug. :P
<infinity> dmj_s76: What's the nvidia behaviour you see?
<xnox> i recall that was the only thing i had to fix.
<infinity> dmj_s76: I can confirm the driver sucking here, though not sure if it's the same as your suck.
<cyphermox> could it be a SB issue?
<infinity> xnox: The only thing you had to fix... In trusty?
<infinity> xnox: Or xenial?
<infinity> xnox: Cause they've diverged a lot. :P
<xnox> trying to remember
<infinity> cyphermox: module loads fine, so no.
<cyphermox> kay, just checking
<infinity> cyphermox: compiz explodes spectacularly on login.
<cyphermox> ah
<cyphermox> that's not a regression
<xnox> infinity, ^ above is just cherrypick copy_modules nvme
<cyphermox> well
<infinity> cyphermox: It's not?
<cyphermox> infinity: nevermind, I was thinking of something else
<dmj_s76> infinity: Are you getting a reboot loop?
<dmj_s76> *login loop
<dmj_s76> (not reboot)
<infinity> dmj_s76: No, I'm getting compiz freezing hard after login.
<infinity> dmj_s76: But could be the same thing, behaving differently on different cards.
<infinity> dmj_s76: To confirm, X starts, lightdm is fine, you can login, then world explodes?
 * xnox the world does not explode in kvm/qemu after fixed initramfs hook as per above sru
 * xnox is out for volleyball
<dmj_s76> infinity: I suspect so...on mine, when I login, there's a yucky crashy behavior for a split second, then back to lightdm
<infinity> dmj_s76: Right.  So, yours might just recover better from the same thing.  Maybe.
<dmj_s76> What driver are you using?
<infinity> dmj_s76: That's the 352 driver?
<dmj_s76> I've experienced this issue with 352 and 367
<dmj_s76> and 361
<infinity> Nothing newer than 352 exists in trusty, afaict.
<dmj_s76> infinity: We package 361 (and soon 367) for hardware compatibility.
<infinity> tjaalton: Remember when tseliot told us that this HWE-X + nvidia thing was tested?  Was that a lie?
<dmj_s76> ...at first I thought it might be some packaging quirk, but it's hitting 352 the same way.
<tjaalton> infinity: I don't know?
<infinity> tjaalton: Do you have nvidia hardware to help test and get to the bottom of this?
<infinity> tjaalton: Cause it sure looks broken to two of us...
<tjaalton> i have an old 8600gt somewhere
<tjaalton> but a logfile would be nice to see
<tjaalton> if it crashes back to lightdm
<dmj_s76> tjaalton: which logs would you like?
<infinity> Mine hardlocks.  But dmj_s76 gets a nice loop, so he might be helpful.
<tjaalton> dmj_s76: /var/log/Xorg.0.log.old
<tjaalton> pastebinit
<infinity> And dmesg, perhaps.
<infinity> I get the same breakage with 340 and 352.  Highly suspect.
<tjaalton> is the dkms built?
<infinity> Built, and it loads.
<infinity> Well, it loads manually.
<infinity> Hard to say if it loads automatically, because locked computer. ;)
<tjaalton> the system hangs hard?
<infinity> With 352, I get the nvidia logo, though, which I'm pretty sure won't happen unless the module loaded.
<infinity> And compiz draws a bit of purple.
<tjaalton> yeah, think so
<infinity> And then explodes.
<infinity> Yeah, hung hard.  Can't VT switch or anything.
<infinity> Well.
<infinity> Display hung hard.
<infinity> I should install sshd to see if it's otherwise alive.
 * infinity reboots again.
<infinity> tjaalton: Alright, machine not hung, just display.
<tjaalton> good
<infinity> tjaalton: Xorg logs don't seem angry in any way. :/
<infinity> I wonder if compiz/unity got updates that don't work for some reason.
<infinity> Oh, and Xorg is eating a core.
<infinity> Go, X, go.
<tjaalton> nothing in dmesg either?
<tjaalton> pastebin xorg log anyway if it has some ideas
<infinity> Hrm, it finally gave me a no screens found.
<infinity> Though, still also hung and spinning 100%.
<infinity> Brilliant.
<dmj_s76> ...just got the logs...
<infinity> http://paste.ubuntu.com/21791021/
<tjaalton> [    63.862] (EE) NVIDIA(GPU-0): EVO Push buffer channel allocation failed
<tjaalton> and so on
<tjaalton> nothing on dmesg?
<infinity> Ooo, I got fun stuff after the server terminated.
<dmj_s76> http://paste.ubuntu.com/21791328/
<infinity> Because of a soft lockup, no less...
<infinity> http://paste.ubuntu.com/21791383/
<dmj_s76> old xorg log: http://paste.ubuntu.com/21791403/
<apw> infinity, do we have a bug for the nvme issue ?
<tjaalton> dmj_s76: 367.35? is that in trusty?
<infinity> apw: We do.
<infinity> tjaalton: It's not.
<tjaalton> ok so just testing
<tjaalton> that gets further though
<dmj_s76> dmesg: http://paste.ubuntu.com/21791516/
<dmj_s76> tjaalton: yes...14.04.5
<infinity> apw: 12:16 < infinity> And then explodes.                                                                12:16 < infinity> Yeah, hung hard.  Can't VT switch or anything.                                    12:16 < infinity> Well.                                                                             12:16 < infinity> Display hung hard.                                                                12:16 < infinity> I should install sshd to ...
<infinity> ... see if it's otherwise alive.                             12:16  * infinity reboots again.                                                                    12:21 < infinity> tjaalton: Alright, machine not hung, just display.                                12:21 < tjaalton> good                                                                              12:22 < infinity> tjaalton: Xorg logs don't seem angry in any way. :/                  ...
<infinity> ...              12:22 < infinity> I wonder if compiz/unity got updates that don't work for some reason.             12:23 < infinity> Oh, and Xorg is eating a core.                                                    12:23 < infinity> Go, X, go.                                                                        12:23 < tjaalton> nothing in dmesg either?                                                          12:24 < tjaalton> pastebin ...
<infinity> ... xorg log anyway if it has some ideas                                     12:25 < infinity> Hrm, it finally gave me a no screens found.                                       12:25 < infinity> Though, still also hung and spinning 100%.                                        12:25 < infinity> Brilliant.                                                                        12:25 < dmj_s76> ...just got the logs...                               ...
<infinity> ...                              12:25 < infinity> http://paste.ubuntu.com/21791021/                                                 12:27 < tjaalton> [    63.862] (EE) NVIDIA(GPU-0): EVO Push buffer channel allocation failed        12:27 < tjaalton> and so on                                                                         12:27 < tjaalton> nothing on dmesg?                                                                 12:27 < ...
<infinity> ... infinity> Ooo, I got fun stuff after the server terminated.                                 12:28 < dmj_s76> http://paste.ubuntu.com/21791328/                                                  12:28 < infinity> Because of a soft lockup, no less...                                              12:28 < infinity> http://paste.ubuntu.com/21791383/                                                 12:28 < dmj_s76> old xorg log: ...
<infinity> ... http://paste.ubuntu.com/21791403/                                    12:28 < apw> infinity, do we have a bug for the nvme issue ?                                        12:29 < tjaalton> dmj_s76: 367.35? is that in trusty?                                               12:29 < infinity> apw: We do.                                                                       12:29 < infinity> tjaalton: It's not.                                      ...
<infinity> ...                          12:29 < tjaalton> ok so just testing                                                                12:29 < tjaalton> that gets further though                                                          12:29 < dmj_s76> dmesg: http://paste.ubuntu.com/21791516/
<infinity> GAH.
<infinity> apw: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1608622
<ubot5> Launchpad bug 1608622 in initramfs-tools (Ubuntu) "14.04.5 drops to initramfs prompt during boot with nvme drive" [Undecided,New]
<infinity> Bloody buffer...
<infinity> dmj_s76: No, he meant is that driver in trusty, and it's not. :P
<davmor2> infinity: you hate use right? Spammer! ;)
<tjaalton> hmm, do you have linux-signed installed?
<tjaalton> for the lts-xenial kernel
<infinity> tjaalton: Yep.
<dmj_s76> oh...okay
<tjaalton> infinity: could it break something? or is the dkms signed somehow?
<dmj_s76> yeah, the driver's from our ppa
<dmj_s76> think we needed 361+ for the nvidia 9 series
<infinity> tjaalton: The module loads, so I have a hard time blaming that.
<tjaalton> right
<tjaalton> makes sense
<infinity> tjaalton: But I can do a fresh install in BIOS mode and see if we get confusing results.
<tjaalton> dmj_s76: your xorg log looks perfectly fine to me
<infinity> I swear, if this works in BIOS mode, I'll be very angry and very confused.
<infinity> So it better not.
<tjaalton> yeah don't think that would help
<infinity> Still, ticking off all the boxes.
<infinity> Still not positive dmj_s76 and I are seeing the same bug, but it's highly suspicious that two (wildly different) nvidia machines are both showing hatred for trusty.5
<infinity> And on a multi-year spread of upstream driver versions, too. :/
<dmj_s76> yeah, from 340 through last month's 367
<tjaalton> are the nvidia versions same as on xenial?
<infinity> tjaalton: xenial has 361, trusty has 352.
<tjaalton> no I mean 352 minor version
<infinity> tjaalton: The 340 versions are similar, but would need to diff to see if they're identical.
<infinity> tjaalton: 352 literally doesn't exist in xenial, it's a transitional package to 361.
<tjaalton> oh I see, right
<infinity> Honestly, I'd rather everyone just use nouveau anyway, but I guess that response on the bug reports won't win me friends. :P
<dmj_s76> infinity: Much as I'd like to be able to use and promote open drivers for nvidia, our customers would scream bloody murder
<infinity> dmj_s76: Well, they're pretty useless for serious 3D use, sadly.
<infinity> But plymouth is prettier!
<infinity> And that's what counts.
<dmj_s76> laptop folk would complain about 1 hour batter life and scientific computing would complain about cuda not working
<infinity> dmj_s76: Oh, you're an s76 guy.  Where's my usual s76 tester extraordinaire?
<infinity> Whose name now escapes me...
<dmj_s76> Jason
<infinity> jderose, that's right.
<dmj_s76> He's still here, just doing some R&D in addition to testing now.  I joined a couple months ago so we could expand our capabilities.
<dmj_s76> Jason and I are friends from Novacut days.
<infinity> Well, tell him I fear change, and because of him I'm having a panic attack.
<infinity> And he owes me.
<infinity> (Not really, but maybe I can guilt him into a free beer)
<dmj_s76> I think he'll join you for that beer
<tjaalton> infinity: do you have  xserver-xorg-legacy-lts-xenial installed?
<infinity> tjaalton: Okay, good news, it sucks just as hard in BIOS mode, so it's not EFI/SB related, at least.
<infinity> tjaalton: And, uhh... Dunno.  Need to reboot again after this fresh install froze.
<infinity> Cause I forgot sshd. ;)
<tjaalton> hehe
<infinity> tjaalton: The bit that weirds me out is that lightdm comes up fine.
<tjaalton> oh right
<cyphermox> dmj_s76: will you be able to test the ubiquity fix for installing to nvme?
<dmj_s76> cyphermox: gladly
<infinity> tjaalton: No legacy-lts-xenial
<infinity> tjaalton: Should I?
<tjaalton> doesn't hurt to try
<infinity> tjaalton: I would, but it's uninstallable. ;)
<tjaalton> oh
<tjaalton> hrm
<davmor2> infinity, tjaalton: are there any issues on amd or is it just nvidia? and I assume we are talking 14.04.5 rather than 16.10 right?
<tjaalton> davmor2: no issues on amd since fglrx doesn't work on .5
<infinity>  xserver-xorg-legacy-lts-xenial : Breaks: x11-common (< 1:7.7+10~) but 1:7.7+1ubuntu8.1 is to be installed
<infinity> tjaalton: ^
<tjaalton> yeah
<davmor2> tjaalton: ouch I can see people bitching about that as they had fglrx in place on trusty :(
<tjaalton> force-install it now to see if it helps
<infinity> Those people shouldn't be reinstalling with the xenial stack, then.
<tjaalton> davmor2: that's on release notes
<infinity> No one's forcing them to.
<tjaalton> right
<infinity> Well.
<infinity> That's not entirely true.
<tjaalton> though upgrading to it from lts-foo breaks as well
<infinity> Sadly, if you're on the utopic/vivid/wily stacks, we will effectively force you to upgrade by dropping support for them. :/
<infinity> tjaalton: Does the whole amdgpupro thing or whatever not work for 14.04.5?
<davmor2> tjaalton: indeed I'm not too concerned but there will be a mile of press on it because people don't read release notes ;)
<infinity> I know fglrx is dead, but the new thing seems reasonably not awful.
<davmor2> infinity: hahahaha
<infinity> Evidently, I'm wrong. :P
<infinity> Anyhow, I'm going to wait for the ubiquity nvme fix, then spin a bunch of RCs, then we can argue about nvidia some more.
<infinity> Since it's only shipped on two images, and shouldn't block general testing.
<infinity> But the whole situation is disconcerting.
<infinity> I guess I should try xenial on this laptop and be sure it works.
<infinity> Then get to diffing.
<dmj_s76> long as we get everything shiny for the final iso, I'm happy
<tjaalton> infinity: probably does, but the packaging is not opensouced yet aiui
<tjaalton> davmor2: well I blogged about it months ago
<tjaalton> infinity: oh actually, -legacy is not needed at all
<tjaalton> on trusty
<infinity> tjaalton: Kay... Why would it be needed on xenial and not trusty if it's the same userspace code?
 * infinity boggles.
<tjaalton> the wrapper is still shipped by x11-common and systemd is not there
<infinity> Oh.
<infinity> I wanted the second part of that to make sense.
<infinity> But I'd be happier if I just didn't read it.
<tjaalton> logind support
<infinity> tjaalton: If you want to queue up a change to remove the uninstallable package, go nuts, but don't bother uploading.
<tjaalton> not actually used by ubuntu yet, since lightdm doesn't support it
<infinity> tjaalton: That'll go fine in a post-point-release SRU, or we can upload it this week if we find another issue to upload for (ie: if it's X's fault that nvidia is sad)
<tjaalton> err I'm mixing things.. logind and non-root X are somewhat related, but the latter is not used
<infinity> non-root X?  But how am I supposed to keylog?
<tjaalton> install the legacy wrapper ;)
<tjaalton> wait, I have a nvidia-based AIO-machine sitting on my desk :D
<tjaalton> I'll test .5 on it tomorrow
<tjaalton> and harass tseliot
<tjaalton> it's a hybrid, but maybe that counts
<bdmurray> infinity: I uploaded update-manager with HWE support to the trusty SRU queue. ^^  Would you mind having a look at it?
<infinity> bdmurray: Erk.  That'll be a pain to review.  I should go find the equivalent precise upload, I guess, and see how similar they are.
<bdmurray> infinity: they aren't similiar because of the split between update-manager / ubuntu-release-upgrader in Trusty and a redesign of update-manager.
<bdmurray> infinity: additionally, I fixed some bugs in the precise code.
<infinity> bdmurray: Fun.
<infinity> bdmurray: Of course, this doesn't need to be on the ISOs, so I guess I can take my time here.
<infinity> (It can be released in a week or two without dire consequence)
<bdmurray> infinity: As I understand things the support for the HWE stack on Trusty is ending on the 4th.
<bdmurray> https://wiki.ubuntu.com/1404_HWE_EOL
<infinity> bdmurray: Well, it's already ended, more or less.  There was no utopic/wily kernel upload this cycle.
<infinity> bdmurray: But still, this doesn't need to be on the ISO, it can land after the ISOs spin.
<infinity> As in, people installing from the ISO get the xenial stack anyway, it's people upgrading that need these bits.
<bdmurray> Right, okay.
<infinity> So, I'll try to wrap my brain around it a bit later.  And accept if it looks good.  And we can test from proposed and stress it a bit.
<infinity> And release after the ISOs are tested and out.
<dmj_s76> cyphermox: So initial testing with your lates ubiquity nvme line looks good
<dmj_s76> I've verified that it works well with nvme drives on 14.04.4 and yakkety
<dmj_s76> not .5 for obvious initramfs reasons
<infinity> tjaalton: nvidia-340 (same upstream version) works fine in xenial.  So.  Whee.
 * infinity goes to stab himself in the face for lunch.
<dmj_s76> I should get lunch too...dig into nvidia after
<tjaalton> infinity: yeah :/
<xnox> apw, nice one! there are many
#ubuntu-release 2016-08-02
<davmor2> infinity, jibel: no netboot on 14.04.5
<jibel> davmor2, in the tracker?
<davmor2> jibel: yeap
<highvoltage> Edubuntu 14.04.5 LTS version 20160802 testing completed and marking as ready.
<tjaalton> where does i965-va-driver get it's Section? it shows universe/oldlibs, while the package source has Section: video
<apw> tjaalton, if it is genuinly not from the package, then it may have overrides in te archive
<tjaalton> apw: yeah..
<tjaalton> guess I can add ubuntu-archive to the bug
<tjaalton> https://bugs.launchpad.net/ubuntu/+source/intel-vaapi-driver/+bug/1603199
<ubot5> Launchpad bug 1603199 in intel-vaapi-driver (Ubuntu) "i965-va-driver shouldn't be in oldlibs" [Undecided,New]
<LocutusOfBorg> please accept libtest2-suite-perl, this way I can make also libgraphviz-perl migrate
<LocutusOfBorg> will trusty receive any lts-yakkety stack?
<LocutusOfBorg> in case, please reject https://launchpad.net/ubuntu/trusty/+queue  virtualbox-lts-yakkety (source)
<LocutusOfBorg> I followed the advice "upload and we accept when the stack is uploaded", but I didn't check if the stack was on the todo
<apw> LocutusOfBorg, it will in time, but that is not ready yet for sure
<LocutusOfBorg> ok, so lets leave it in the queue
<LocutusOfBorg> and accept when the other stuff is ready
<LocutusOfBorg> so I don't have complainst about "hey vbox is not installable"
<tjaalton> LocutusOfBorg: no, trusty won't
<Sarvatt> no it wont get a lts-yakkety release, it stops at the next lts (xenial)
<LocutusOfBorg> because no more point releases, right?
<tjaalton> because there is xenial
<LocutusOfBorg> so, please reject virtualbox-lts-yakkety from trusty queue
<LocutusOfBorg> pitti, ^^ :)
<tjaalton> done
<LocutusOfBorg> <3
<apw> oh yeah, derp
<slangasek> so, why has the iso tracker just (yesterday) added tags to a bunch of ancient bugs?
<slangasek> seem to all be from tests done in 2012, so looks like they can be ignored
<dmj_s76> infinity: Any progress on the Nvidia front?
<rbasak> infinity: looks like the Ubuntu server 14.04.5 test URLs from http://iso.qa.ubuntu.com/qatracker/milestones/365/builds/127727/downloads are wrong, and need "trusty/" inserted after "daily/".
<rbasak> powersj: ^
<powersj> rbasak, after or before daily?
<rbasak> Oh sorry, before.
<yofel> what would be an easy way to force-badtest all kde packages in proposed? like, permanently? Some tests are known-broken, some tests are regularly building with unsupported package combinations, or different versions across architectures, ...
<yofel> or please at least badtest kwin marble kde-cli-tools libkscreen kdepim-runtime kxmlgui extra-cmake-modules kconfigwidgets okteta akonadi-search kidentitymanagement kdelibs4support kwayland libkscreen
<yofel> so that qt 5.6 isn't stuck on kde
<Mirv> release team ^ ok from my side too, plus add to the list: kde-baseapps
<Mirv> unity8 fix should land soon so tomorrow we could see if we could get the migration to happen
<infinity> yofel: What's the point of having tests if none of them work? :/
<infinity> yofel: And "unsupported package combinations" shouldn't happen.  If it can happen in testing, it can happen for users too.  ie: your dependencies are wrong.
<infinity> tjaalton: Did you and tseliot get a chance to look at the nvidia issues?
<dmj_s76> I can confirm that the initramfs-tools related nvme bug is fixed in the latest iso, and the nvidia login-loop issue remains.
<infinity> dmj_s76: The other nvme bug should be fixed too (the ubiquity one).
<dmj_s76> infinity: I'll put one of the nvme drives in a bios machine and let you know the results
<yofel> infinity: it's not that none work, but some don't and some testbeds are broken (we mostly got the autopkgtest stuff from debian and don't know what to do with it)
<yofel> infinity: after a closer look the package versions are actually ~ok this time - at least inside a package set, but I still see tests where some architectures build for a new version, and some for the old one, which makes all latter architectures useless to me
<yofel> and then there's the tests that run on architectures that I cannot even debug even if I wanted...
<yofel> it's not that I consider the tests a bad thing, but they're kind of in the way if there's nobody that will fix them
<jbicha> speaking of unusual combinations from autopkgtest, there's bug 1606983
<ubot5> bug 1606983 in Auto Package Testing "test triggered from depwait package" [Undecided,New] https://launchpad.net/bugs/1606983
<infinity> Weird.  pitti may have been playing.
<Mirv> yeah Kubuntu has huge amount of tests but if they don't have people to fix the inherited-from-Debian tests, they should be overridden if casual look at them and manual testing doesn't reveal any functionality problems in the said packages (and that has been done)
<Mirv> this time around there is actually less failing autopkgtests that than in some previous releases
<infinity> We've had (nearly) all of them passing in the past, which is why britney's upset now.
<infinity> It only blocks on regressions.
<infinity> But I'll look a bit later.
<dmj_s76> infinity: cyphermox: I can confirm that nvme installs now work in bios mode using default partitioning!
<dmj_s76> tested on latest 14.04.5 iso
<tjaalton> infinity: tseliot is looking into it
<infinity> tjaalton: Kay.  Time's a factor. :)
<infinity> tjaalton: (I can delay the point release for this if I have to, but I'd prefer not to)
<tjaalton> yeah he knows
<slangasek> infinity: do you suppose it's a bug that we have /var/log/apt/history.log in the liveCD's squashfs?
<slangasek> (it does happen to have ultimately come in handy for identifying the install media used in a number of bug reports against shim-signed, where the rest of the data included was lacking...)
<infinity> slangasek: It's perhaps an itty bitty bit of wasted space, but I'm not sure I'd see it as a bug.  As you say, it's (very) occasionally useful for debugging, and it'll get rotated into oblivion on an installed system.
<infinity> slangasek: Call it an accidental feature? :P
<slangasek> infinity: well, I would prefer bug reports that actually show me the version of the install media, instead of having to reverse-engineer this based on dates in that log :)
<infinity> slangasek: Do they not generally include that?  apport ones, that is.
<infinity> slangasek: Anyhow, I have no strong feeling either way.  It's technically a live-build bug any time it leaves cruft behind that isn't needed for the live or target system, but I also don't have the patience to hunt down every 3k file that we've missed.  Feel free to fix it if you want. :)
<slangasek> infinity: they're meant to, but at least for some of these bugs where the install itself is failing (so, before installer logs are copied over), seems not
<slangasek> bdmurray: ^^ do you know if apport is meant to know how to report the install image version in a case of a package installation failure before the install is done (e.g., bootloader)?
<infinity> It certainly could, if it doesn't currently.
<slangasek> at a random guess, the apport that triggers is in the context of the target chroot, so doesn't see the install media at all at that point?
<infinity> I wouldn't think so.
<slangasek> no?
<slangasek> it's not a kernel crash handle
<infinity> Oh, maybe.  I'm not sure how segv handlers resolve in that context.
<slangasek> it's a dpkg package handle
<infinity> Oh.
<infinity> Then perhaps it would be the chroot one.
<infinity> In which case, the fix would be for us to copy the media info immediately after copying the squashfs.
<infinity> Rather than at the end, with the logs.
 * slangasek nods
<infinity> (does it annoy anyone else that, in the context of storage, "media" has become both plural and singular?)
<infinity> We should copy the MEDIUM info right after the squashfs. :P
<slangasek> it doesn't bother me at all, because I don't recognize it to be true ;-)
<infinity> slangasek: No?  Do you ever say "what medium did you use to install that?"
<slangasek> infinity: yes ;)
<infinity> If so, you're rare. :P
<infinity> ("What medium did you use?" ... "I didn't, I used the large.  Took forever to download.")
<cyphermox> infinity: don't mix things up, I keep having mediums call me at home.
#ubuntu-release 2016-08-03
<jbicha> please mark Ubuntu GNOME 14.04.5 ready for amd64 i386
<Mirv> please consider the autopkgtest overriding of the package list gotten from Kubuntu so that we could see about migrating Qt and KDE to release pocket today (we're waiting for silo 73's Unity 8 fix to land only)
<Mirv> to recap: akonadi-search extra-cmake-modules kconfigwidgets kde-baseapps kde-cli-tools kdelibs4support kdepim-runtime kidentitymanagement kwayland kwin kxmlgui libkscreen marble okteta
<Mirv> I guess no release team members around this hour now that pitti is away?
<Mirv> anyway, I've filed bugs for the failing KDE's tests in case some Kubuntu member would want to look at them at some point: https://bugs.launchpad.net/bugs/+bugs?field.tag=kf524
<tjaalton> infinity: we have a theory of the nvidia breakage.. revert of the maxclients patch (aka avoid newer coreproto which would break older servers). I'll try to rename coreproto for this and revert the patch
<handsome_feng> Hi, @cjwatson, I'm the member of Ubuntu Kylin, the ubuntukylin-14.04.5-amd64 iso lack of the casper/filesystem.manifest-remove file , can you help to fix this ?
<davmor2> infinity, cyphermox, jibel: I think there might be a small issue for 14.04 if someone install with the mac image in that there is no upgrade candidate for 16.04 I think, I'm going to confirm it today though
<infinity> davmor2: I see no reason why that would be true.
<infinity> davmor2: The amd64 and amd64+mac images have identical contents, it's only the bootloader bits that differ.
<infinity> handsome_feng: Err, what?
<infinity> tjaalton: Keep me posted...
<infinity> tjaalton: If we can come up with a workable fix, I'd like to respin ASAP during EU daytime.
<infinity> tjaalton: I'm backwards timezoned just for this. :P
<tjaalton> infinity: I'm staging crap on x-staging
<infinity> tjaalton: Kay.
 * infinity goes to download a kylin ISO to see what handsome_feng is on about.
<davmor2> infinity: yeah the issue I see is if it is looking for amd64+mac image on 16.04 there isn't one I am only guessing though it is just I don't get the there is an upgrade dialogue popup on start up on mac but am everywhere else
<infinity> davmor2: Upgrade in update-manager has nothing to do with ISOs.
<handsome_feng> infinity: http://cdimage.ubuntu.com/ubuntukylin/trusty/daily-live/current/trusty-desktop-amd64.list
<davmor2> infinity: cool as I say I'll dig into some more to try and figure out why it isn't happening
<infinity> davmor2: Just timing?  The check is cronned.
<infinity> handsome_feng: Weird.
<handsome_feng> infinity: casper/filesystem.manifest-remove  disappeared
<infinity> handsome_feng: Very weird.
<infinity> handsome_feng: We can just respin amd64 so you can test it.
<infinity> handsome_feng: There will be a full respin "soon" anyway for the X/nvidia issue.  But I'll do yours right now for the manifest thing.
<infinity> But also, WTF. :P
<handsome_feng> infinity: Thank you very much ! :)
<Laney> Mirv: I did those, enjoy
<Mirv> thank you Laney, now we'll wait for QA's unity8 silo still
<davmor2> infinity, jibel, cyphermox: Phew sorted it out, it was because the wifi wasn't enabled because of having to install the driver so that meant there was no connection when the cron job checked for updates which is why it didn't trigger before I'm a happy bunny again now :)
<tjaalton> infinity: nvidia works without the revert in xserver, so now I just need to make x11proto-core-dev-lts-xenial installable somehow..
<infinity> tjaalton: Since you have to reupload X stuff for this, can you also remove the broken -legacy package in the process?
<infinity> tjaalton: (Low prio compared to fixing nvidia, obviously)
<tjaalton> sure
<tjaalton> infinity: bah, adding C/R/P: x11proto-core-dev isn't enough.. refuses to replace
<tjaalton> packages have versioned depends, and we don't have versioned provides
<infinity> Not in trusty, no.
<tjaalton> hmm
<tjaalton> maybe add stuff to the trusty coreproto, import that only in the lts-xenial xserver
<infinity> Bundle it with the xserver and use -I?
<tjaalton> or that
<infinity> It can't be big.
<infinity> That seems the most "sensible", FSVO.
<infinity> It guarantees nothing but the xserver will ever pull it in.
<infinity> And no user will install it by accident.
<tjaalton> right
<tjaalton> it's just Xpoll.h
<infinity> Or package it as lts-thingee, but in a different include subdir, and build-dep on it and, again, use -I
<infinity> Oh, if it's literally one file, yeah...
<tjaalton> http://pastebin.com/qK6Xhy7i
<infinity> Just bundle it in debian/exclude, and use CFLAGS+=-Idebian/include, IMO.
<infinity> I can diff it against the xenial version, call it good, and accept.
<infinity> debian/include even.
<infinity> Wow, brain.
<tjaalton> hehe
<tjaalton> infinity: server builds, I'll test that if the other drivers now need a rebuild..
<infinity> tjaalton: Ugh.  I hope not.
<infinity> tjaalton: But if they do, so be it.  At least the reviews will be simple. :P
<tjaalton> yeah
<infinity> tjaalton: OOI, how do you reliably test if the drivers need rebuilding?
<infinity> (And why would they, as long as no external ABI has changed?)
<LocutusOfBorg> the boost fun started?
<tjaalton> infinity: just a quick test that things work. the nvidia driver complained about a missing symbol
<LocutusOfBorg> oh, i386 sandess
<LocutusOfBorg> doko, syncing boost
<LocutusOfBorg> this should fix the i386 sadness
<infinity> tjaalton: Ahh, I guess you can write an Xorg.conf that loads all the drivers, despite not having their hardware installed?
<infinity> tjaalton: And see if they asplode?
<ginggs> LocutusOfBorg: see boost 1.61.0+dfsg-2 for i386 fix
<infinity> ginggs: He knows, hence "syncing boost, this should fix the i386 sadness"
<xnox> nothing started
<flocculant> infinity: when do you need trusty .5 marked by?
<infinity> flocculant: There's going to be a respin, so...
<infinity> flocculant: But I'll need it all happy and signed off by US Thursday morning (so, EU Thursday afternoon, ish)
<infinity> flocculant: Earlier is better, of course.
<infinity> flocculant: Anyhow, world will respin once this X bug is sorted. :/
<flocculant> infinity: oh great ... what's the respin for?
<flocculant> oh nvm - should look up ...
<infinity> flocculant: X backport hates nvidia binary drivers.
<infinity> flocculant: Which, unfortunately, too many people use for me to ignore.
<flocculant> infinity: ok - tests we've done are just vm ones anyway
<flocculant> unlikely we'll get real hardware tests done
<flocculant> and yea ack that :)
<flocculant> I can try and get at least one hardware test here - with nvidia card
<LocutusOfBorg> ginggs, I already syncd a while ago, and so far so good
<infinity> flocculant: I'm not fussed about how you test, per se.  You guys should know by now that my bar for flavours is "does it boot, install, and reboot successfully", and any bugs beyond that are up to your discretion to care or not.
<LocutusOfBorg> doko syncd boost ~7 minutes before the -2 was picked up by lp
<LocutusOfBorg> lol
<flocculant> infinity: yea ofc - depends on when it's respun as to whether I'll get time to do a hardware one
<infinity> flocculant: *nod*
 * flocculant goes back to his woefully short lunch break 
<infinity> flocculant: To be fair, if you've done a reasonable amount of testing on the current image, knowing what's changing in the next (xserver, and possibly grub) lets you focus your testing if you want to.
<flocculant> infinity: given that it was all vm's - everything was fine
<rbasak> infinity: meet powersj, our new (replacement) QA person. He's done the mandatory and run-once tests for server for 14.04.5. I see one bug but I suspect that's fallout in the archive from samba's major version bump security update. Perhaps the test case needs updating.
<infinity> rbasak: Mmkay.  I'm considering letting a grub update in.  If I do, there'll be a server respin with all the desktops.
<infinity> powersj: So, be prepared to have to do some re-testing.  Doing *all* the tests on a respin isn't strictly necessary, but boot/install/reboot certainly is.
<rbasak> powersj is UTC-6.
<rbasak> (fyi)
<infinity> rbasak: So, next door to me?  Kay.
<infinity> rbasak: But, arguably, he sleeps normal hours.
<rbasak> Different country :)
<infinity> rbasak: I meant next door, timezone-wise.  I can't help it if people live in the wrong country. :)
<rbasak> :-)
<jbicha> infinity: maybe your clock is in the wrong country! :)
<infinity> jbicha: I can never figure out what country my clock is in.
<infinity> jbicha: It's often just drifting in some uninhabited part of an ocean.
<rbasak> Technically there's always Antarctica.
<infinity> rbasak: Well, both poles, and I'm closer to the other one.  But despite it making some geometric sense to do so, poles don't observe all timezones at once. :)
<infinity> Although, if arctic standard time was, in fact, all times at once, that might explain the Santa speed problem.
<infinity> He can deliver to all the boys and girls because he exists at all points in the time-space continuum.
<infinity> Go, Santa.
<rbasak> I think it would depend on your longitude. Perhaps your house is on a pole, so you shift longitudes (and therefore timezone) by walking into the kitchen, etc. That would explain quite a bit :)
<infinity> Still doesn't explain how he can eat so many cookies, though...
 * rbasak understands that it doesn't actually work like that, but whatever
<infinity> rbasak: It doesn't, but I now want to build my summer home directly on a pole, pie-shaped, with 24 rooms.
<infinity> Err, by "pie-shaped", I mean "round, with pie-sliced rooms", but you got that.
<infinity> Shame it wouldn't really have the correct effect with the sun, because of the tilt.
<rbasak> Depends on how big your house is.
<rbasak> Though walking to the kitchen might take you a while then. You'd probably want to have a few extra bedrooms, kitchens and bathrooms on the way.
<tjaalton> infinity: intel at least is still quite happy. and none of the drivers import resource.h from xserver-xorg-dev
<infinity> tjaalton: I'm going to extrapolate that resource.h is the only header that includes that proto header?
<tjaalton> it's the one that got ResourceClientBits() added in 1.18
<infinity> Kay.
<tjaalton> nvidia uses it for "something"
<tjaalton> probably just to piss on us
<infinity> Heh.
<tjaalton> so, I'll upload this one, -legacy-lts-xenial is gone as well
<infinity> tjaalton: Alright, let's go for the least invasive change we can, and make it happen.  I'd like it if you could test loading all the drivers (that must be doable, at least to the point where they probe and bail), before we decide we're good.
<tjaalton> ok
<infinity> tjaalton: I assume it should just be a matter of specifying each driver, starting X, and checking the log that it loaded, found no cards, and failed?  It's been years since I wrote an X.conf, though. :P
<tjaalton> yeah should be simple, writing it now
 * infinity goes to test that grub SRU so he can slip it in.
<tjaalton> infinity: yeah, they all load
<infinity> tjaalton: Excellent.
<infinity> tjaalton: Upload away.  And thanks.
<infinity> tjaalton: Looks good.  Accepted.
<infinity> tjaalton: I was going to whine about the lack of bug ref, but (a) I don't recall anyone filing a bug for the issue and (b) I have a test setup here to verify, so meh.
<tjaalton> right, haven't seen a bug either
<infinity> Ooo.  The rain seems to have stopped for a few minutes, going to use this window to make a breakfast/coffee run.
<infinity> Will verify and promote that X when I get back, and then respin $world.
<infinity> davmor2: Can you try to get the word out to lazy flavours that we're, like, doing a point release?  A few haven't done any tests yet.
<davmor2> infinity: I might be able to there is a listing somewhere of who to ping I'll dig it out after and start pinging them
<infinity> davmor2: Also, if you haven't been reading backscroll, there'll be a (hopefully final) respin in an hour or two.
<davmor2> infinity: what's wrong with x now?
<infinity> davmor2: A bad revert broke nvidia.
<davmor2> jibel: ^
<davmor2> infinity: see and then the devs wonder why I hate them, they keep breaking stuff ;)
<infinity> davmor2: That's our job.
<davmor2> infinity: no that's just it breaking it is my job not theirs ;)  Their job is fixing all the things I break :D
<infinity> davmor2: Nope.  It's our job to break, your job to discover, and our job to fix. :)
<infinity> If we didn't do the first bit, the next two wouldn't be necessary, and half of us and all of you would be out of jobs.
<davmor2> infinity: hahaha
<davmor2> infinity: can we have netboot added to the tracker too please
<infinity> davmor2: If I can remember how to do that manually.  Not that I pay attention to what the tracker says about it anyway...
<infinity> (Since it's already "released" and has been for a week)
<davmor2> infinity: 14.04.5 has been released for a week what ;)
<infinity> davmor2: No, netboot has.  Netboot is in no way tied to milestones.  At all.
<infinity> davmor2: It's just a product of debian-installer builds.
<infinity> davmor2: But there it is.
<davmor2> infinity: ta
<davmor2> infinity: is that safe to test now while I wait for the other images?
<infinity> davmor2: Yeah, it's not changing.
<davmor2> infinity: awesome
<davmor2> flocculant: ^ respin for xorg \o/
<infinity> tjaalton: Okay, nvidia-352, nvidia-340, nouveau, and intel tested on this laptop with the new X, all looks good.  nvidia-304 doesn't work (the really old one), but that's not X's fault, looks like it's incompatible with the kernel.
<powersj> infinity, o/
<powersj> infinity, I saw you and rbasak discuss a possible new respin, what mailing list should I be on to be notified of that?
<infinity> ubuntu-release@, perhaps.
<powersj> great thx
<davmor2> infinity: how's it coming?
<infinity> davmor2: Waiting on the publisher, respins will commence in about 30m.
<infinity> Or less.
<infinity> (or your pizza's free)
 * davmor2 makes the internet for the builders slower free pizza sounds fun
<davmor2> netboot 64 done moving onto 32
<tjaalton> infinity: excellent, tseliot says his doesn't work but I guess it's still the wrong (old) version :)
<tjaalton> afk ->
<tseliot> infinity: err... I never seem to get notifications about drivers failing to build...
<flocculant> davmor2: yea - knew it was happening :)
<flocculant> infinity: for your info - at the end of the yak cycle akxwi-dave is taking over for me - at least for one cycle - he'll carry on being in here (though I'll not be absent - just being lazy)
<flocculant> he's in our release team now too btw
<infinity> tseliot: It builds, it doesn't insert.
<tseliot> infinity: do you happen to have the exact error?
<infinity> tseliot: Lemme look.
<infinity> tseliot: "Unknown symbol mtrr_del" (and mtrr_add on the next line)
<tseliot> infinity: ok, it looks familiar, thanks
<infinity> tseliot: Anyhow, 352 and 340 work.  But I assume some old cards need 304.
<infinity> (Though, I'd also assume people with ancient cards aren't gaming or running blender and probably mostly use nouveau, but...)
<tseliot> infinity, tjaalton: also, the new X works here now
<tseliot> it should be a quick fix (304)
<tseliot> infinity: yes, the patch is already in xenial. I'll backport that
<infinity> tseliot: Ta.
<jbicha> powersj: at http://iso.qa.ubuntu.com/ if you click through to a test case page, you can subscribe to all the test cases for a flavor
<jbicha> and it should send you an email when a new image is ready for testing
<powersj> jbicha, awesome thx
<tseliot> infinity: the packages are in -proposed. Here's the SRU: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-304-updates/+bug/1609460
<ubot5> Launchpad bug 1609460 in nvidia-graphics-drivers-304-updates (Ubuntu) "SRU: nvidia-304 can't be loaded with the lts-xenial kernel" [High,In progress]
<infinity> tseliot: Yep, just waiting for the diff to be generated.
<tseliot> infinity: great, thanks
<Mirv> Laney: could you override plasma-framework and unity8 still? p-f has known old bug on s390x, and unity8 autopkgtest fix is slightly delayed but it's pretty minor in all of the test suite and the landing will happen pretty soon. we'd like to ease up people's lives by getting the proposed transition done
<infinity> Oh my.  14.04.5 to 16.04.1 upgrade sure doesn't work right.
<infinity> Gah, and that's why,
<infinity> tjaalton: You didn't do the transitional packages from lts-xenial -> xenial.
<tjaalton> infinity: oh?
<infinity> (xenial-amd64)root@nosferatu:~# apt-cache search x*lts-wily | wc -l
<infinity> 101
<infinity> (xenial-amd64)root@nosferatu:~# apt-cache search x*lts-xenial | wc -l
<infinity> 20
<infinity> Seems suspect.
<infinity> (Those 20 are the kernel transitional packages)
<tjaalton> so xenial needs something
<infinity> Yes, xenial needs the lts-xenial equivalent of those lts-wily transitionals.
<infinity> Which I would have assumed would have made it in the release pocket, since we already knew the name of the backport stack, but oh well. :P
<infinity> It can be an SRU.
<davmor2> infinity: I hope that's not another issue now :(
<infinity> davmor2: Nothing that affects the 14.04.5 ISO.
<davmor2> phew
<infinity> davmor2: It's a fix needed in xenial for upgrades *from* 14.04.5
<tjaalton> hrm, I need to put this in git
<infinity> tjaalton: The failure mode it pretty spectacular too.  I somehow end up with x-driver-*-all removed, and no more input drivers.  Get lightdm, and no input devices, which basically means "hung machine" to any normal user. :P
<infinity> (like, it'd be better if it broke so bad that X didn't start)
<infinity> Oh well.  Fun bugs are fun.
<tjaalton> ok, I'll fix that
<infinity> Ta.
<infinity> Should trivially work if the transitionals are there, I believe.
<infinity> It just really doesn't without them.
<infinity> tjaalton: Would be nice to get this one landed before I release tomorrow.  Cause you just know the first thing people are going to do after the install a fresh 14.04.5 is click on the "upgrade to 16.04 available" button. :P
<infinity> Because people aren't smart.
<tjaalton> yean on it now
<tjaalton> *yeah
<tjaalton> the transitionals are only for x86?
<infinity> We built the stack for all arches, so transitionals should be too.
<infinity> Did we screw that up for u/v/w?
<tjaalton> not historically
<tjaalton> yep
<infinity> Oh well.  Can fix that in a second pass.
<infinity> Clearly not enough people have noticed to complain.
 * infinity takes a break while the world burns^Wbuilds.
<DJones> Just a quick question, should http://changelogs.ubuntu.com/meta-release show the 16.04.1 release rather than just 16.04
<DJones> So that 14.04.4 users would be shown that there is new release available to upgrade to?
<infinity> DJones: They get shown there's a new release, but yes, the version should be bumped.
<DJones> Just had somebody asking in #ubuntu when the release would become available for upgrade, so wondered if it wasn't being offered yet because of that
<infinity> DJones: It's definitely being offered, I literally just tested that on a 14.04 machine.
<DJones> Right, no worries, must have been a PEBKAC moment for the user
<infinity> DJones: Well, the check is cronned, and might be both weekly and staggered, so not everyone sees it right away.
<infinity> DJones: To avoid crippling the world.
<DJones> Right, that would explain it
<DJones> infinity: Thanks for the info & update
<Laney> Mirv: Why not do a unity8 with just the fix we need for the tests?
<Laney> I'm tired of unity8 needing so much hand holding, we should be able to do better there
<tgm4883> Can we turn off Mythbuntu Trusty ISOs
<Laney> Mirv: plasma-framework is already ignored, AFAICS
<dmj_s76> infinity: Do the X fixes in the new RCs pertain to the nvidia issue?
<apw> dmj_s76, the latest respin was for nvidia i believe yes
<dmj_s76> good...I'll test when it's ready
<dmj_s76> appears to still be yesterday's isos
<apw> from the list of builds queubot has reported i don't see Ubuntu Desktop yet
<Mirv> Laney: since there's a huge silo which has seen a lot of QA. it was supposed to land today but seems not. there's one plasma-framework test that is not ignored at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#plasma-framework
<Mirv> Laney: we can also wait for it still, this was just an idea to not wait for it since there's no big benefit as such from waiting
<Laney> Mirv: I'm saying it would have been simpler for the distro if the test fix was uploaded separately rather than entangled in a huge silo
<Laney> I bumepd plasma-frameworks
<Mirv> I agree. it just tends to be that there are so many teams needing unity8 landings, that at the velocity of the landings and their QA take and the deadlines that are wanted to be met, they put many little things like yakkety autopkgtests fix to be part of a bigger feature landing.
<Mirv> the only problem here is that QA found another thing in that feature to be fixed..
<Mirv> Laney: thanks for the plasma-framework bump, that leaves unity8 as the only excuses page blocker
<tjaalton> infinity: there haven't been transitional packages for virtualbox-guest-dkms et al in the past
<tjaalton> wonder if there should
<flocculant> infinity: managed a hardware trusty with nvidia card
<davmor2> yay finally
<tjaalton> infinity: keep finding more and more lts-transitional bugs..
<tjaalton> infinity: the diff would look like this http://pastebin.com/jLe4jtSK
<tjaalton> with a placeholder for virtualbox
<tjaalton> infinity: uploaded, review it from the queue..
<chrisccoulson> I've got a firefox update to publish via the security pocket - do I need to wait until 14.04.5 is done?
<stgraber> hmm, why is Edubuntu still marked as rebuilding
<Rosco2> Ubuntu Studio too
<doko> who's doing autopkg test sanity work while pitti is on vacation?
<stgraber> infinity: any idea what's going on here? https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/trusty/edubuntu/+build/71453
<LocutusOfBorg> can anybody please retry curl/systemd autopkgtestsuite?
<LocutusOfBorg> "You submitted an invalid request: You are not allowed to upload systemd or curl to Ubuntu, thus you are not allowed to use this service."
<LocutusOfBorg> but I did upload curl! :)
 * stgraber cancels the Edubuntu build and re-triggers
 * stgraber cancels the ubuntu studio one too
<zequence> stgraber: Thanks :)
<Rosco2> stgraber, Thanks - I was just logging in to do it
<zequence> stgraber: We had an error with the amd64 build, it seems (we got the report to our mail list at 21:10). How's the Edubuntu builds coming along?
<dmj_s76> infinity: I'm going to test some more, but I believe today's iso fixes the nvidia login loop
<stgraber> zequence: our images are supposedly still building, I see one of yours succeeded and the other one is still going
<stgraber> all 3 building images are at the fdupes step. This does seem to take a while typically, will start worrying if none of them finish within 30min or so
<stgraber> it could be an I/O problem on scalingstack causing this to be super slow for some reason, but we'll see
<stgraber> (not seeing any report of scalingstack issues anywhere, so hoping those rebuilds will work)
<zequence> Only mentioning because we got the build fail log after you had retriggered.
<stgraber> what's the version on that build failure e-mail?
<stgraber> what's building now is 20160803.1
<stgraber> if the e-mail is about 20160803, then just ignore
<zequence> Ah, ok
<stgraber> doesn't look like things are stuck so far, just slow. Edubuntu 32bit is finishing now.
<Rosco2> Studio 64 bit still sitting on fdupe step
<stgraber> they all seem to have moved on to something else now, so still making progress
<jbicha> please mark Ubuntu GNOME ready for amd64 i386
<flocculant> jbicha: done
<infinity> chrisccoulson: Unless it's urgent, I'd prefer you hold off until tomorrow.
<chrisccoulson> infinity, that's fine, there's nothing particularly urgent in https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox/#firefox48, and it's too late in the evening for me to do it now :)
#ubuntu-release 2016-08-04
<infinity> tgm4883: Have you started testing myth for trusty yet?
<tgm4883> infinity: no, I asked earlier if that could be dropped
<tgm4883> infinity: we've never supported ISOs past LTS+1.1
<infinity> tgm4883: Err.  You certainly have in the past.  Including all of the trusty point releases to date.
<infinity> So, not sure about "never". :P
<tgm4883> infinity: Sorry, let me clarify. Our policy is to support LTS releases up to the first point release of the next LTS
<infinity> tgm4883: Part of being LTS kinda implies signing up for this.
<infinity> tgm4883: Right, .5 is the last one, which coincides with next.1, and is rather important to exist.
<tgm4883> infinity: I thought that was up to the flavor
<tgm4883> infinity: ah ok
<infinity> tgm4883: We don't do more after .5
<tgm4883> well I guess I'll download then
<infinity> tgm4883: Anyhow, I was asking because you ship nvidia-304, which I was about to release, which would trigger a respin. :P
<tgm4883> so I should wait then?
<infinity> tgm4883: I'm happy to test one arch if you test the other, after I've respun.  If you can wait that long.
<infinity> (I don't know what tz you live in...)
<tgm4883> I should be able to do them both fairly quickly
<tgm4883> I'm in PST
<infinity> Ahh, kay.  Cool.
<infinity> Then yeah, let me finish testing nvidia, promote it, and respin you.
<infinity> Should be about 2h at the most, hopefully less.
<wxl> infinity: /ctcp <nick> time next time you want to find someone's tz :)
<infinity> wxl: Not always reliably true.
<infinity> wxl: My client is often in UTC. :P
<infinity> (Though, not right now)
<wxl> bah
<tgm4883> infinity: well then let me state now that I'd like to drop all future release ISOs (16.10 and on)
<infinity> And when I'm traveling, I don't change my client's TZ either...
<wxl> alright alright, you win
<wxl> (as always)
<infinity> tgm4883: Right, 16.10+, no more myth? (well, 18.04+, since you're LTS-only anyway)
<infinity> tgm4883: I can go disable you in crontab for devel now.  Won't go deleting anything, in case you decide to change your minds in 6mo.
<tgm4883> infinity: correct. I'll point people to xubuntu and have them install/configure from there. We don't have the manpower to really fix all the issues we have with new ISOs (meaning issues that spring up from LTS releases, not point releases)
<tgm4883> We had a tough time doing it for 16.04
<infinity> tgm4883: The elegant solution might be for myth/xu/studio to combine forces and have nice package selection at the end of the install to customize.
<infinity> tgm4883: And one single ISO for all XFCE based installs.
<tgm4883> Hmm, that's not a bad idea
<infinity> tgm4883: I think studio already has package selection plugins for ubiquity, so that might not be much effort.
<tgm4883> We've got package selection stuff for ubiquity as well
<infinity> Probably the same plugins. :)
<infinity> So, yeah.
<infinity> Turning that into a super-XFCE installer might be smart.
<infinity> If the xubuntu people are down.
<infinity> Or just combine myth and studio.
<infinity> tgm4883: All tested and released, will respin ASAP once the packages hit disk on ftpmaster.
<infinity> tgm4883: Oh, and myth for 16.10+ is disabled now.
<tgm4883> thanks
<tgm4883> ping me when the ISOs are ready
<infinity> Will do.
<infinity> yofel: Is anyone smoketesting the kubuntu/14.04.5 ISOs?
<infinity> zequence: No one seems to have touched studio/14.04.5 testing.
<krytarik> infinity: We have, at least i386 - before the respin finally landed.
<infinity> krytarik: Well, more results on the current ISO would be nice. :)
<infinity> (or any...)
<krytarik> infinity: There are plans to do some later in the day, yes.
<infinity> tgm4883: ^^ there are yours.
<tgm4883> infinity: yep, already grabbing it
<infinity> tgm4883: Ta.
<Mirv> can someone please run on snakefruit: retry-autopkgtest-regressions -s yakkety --ci-train-silo 073 --ci-train-ticket 1575 --all-proposed
<Mirv> so that we get slightly better autopkgtest coverage as long as that silo hasn't landed and the huge amount of source packages are only in proposed (the only blocker is unity8 now)
<apw> Mirv, looking
<apw> Mirv, and done
<Mirv> thank you
<Mirv> Saviq: ^ proposed tests running again
<yofel> infinity: not yet, I'm trying to wrap up some quick tests
<Saviq> Mirv, thanks, could you recycle https://requests.ci-train.ubuntu.com/static/britney/ticket-1575/landing-073-vivid/excuses.html too?
<infinity> yofel: Ta.
<Mirv> Saviq: I did already, running
<Saviq> Mirv, ah ok thanks :)
<acheronuk> infinity: a few basic tests of kubuntu/14.04.5 ISOs done in VirtualBox. about all I can do I'm afraid. have reported results
<infinity> acheronuk: All I'm looking for is boot/install/reboot -> did the right thing, computer didn't explode.
<infinity> acheronuk: Obviously, you guys can hold yourselves to a higher standard, but that's my minimum for "will I release your image". :P
<acheronuk> infinity: ok. what I did should be useful then. great :)
<infinity> acheronuk: Anyone going to do the same for i386?
<acheronuk> infinity: ok. I shall try
<infinity> Ta.
<acheronuk> infinity: done. reported. hope that helps
<infinity> acheronuk: Thanks.
<Laney> Hrm
<Laney> Looks like gir1.2-ubuntu-app-launch-2 was removed on yakkety/s390x, but it has rdeps, and those rdeps have rdeps
<mvo> infinity: do you know if there is a way to trigger the autopkgtest for snapd (for the SRU of snap-confine ) again? i.e. http://autopkgtest.ubuntu.com/packages/s/snapd/xenial/amd64/ the topmost will probably work against 2.11
<tseliot> can an archive admin reject nvidia-graphics-drivers-367 in NEW, please? (some archs fail)
<apw> tseliot, done
<tseliot> apw: thanks!
<Laney> Someone should reject that apt - juliank synced it to -updates
<apw> Laney, !
<LocutusOfBorg> and accept python-tornado, just an added -doc binary :)
<apw> infinity, i assume you are not expecting an apt sync to anywhere ...
 * apw rejects the -updates one ...
<Laney> nice one
<Laney> sync to -proposed for an SRU should be okay, assuming the tools can cope with it
<Laney> which they probably can these days, because CI train
<Laney> But me no SRU team
<tsimonq2> could someone mark Lubuntu 14.04.5 amd64 and i386 (NOT PowerPC yet) as ready please?
<bdmurray> infinity: Wily still shows as supported in LP
<LocutusOfBorg> thanks to whoever accepted it
<dmj_s76> infinity: Testing with nvidia and nvme seems good to me
<infinity> bdmurray: I know.  I need to clean it up a bit first.
<infinity> apw: Would have been expecting it to proposed, not updates.
<apw> infinity, there is another one now to -proposed, i left that for your perusal
<apw> (to xenial-proposed)
<infinity> apw: *nod*
 * infinity tries to wake up.
<apw> (i did reject the -updates one)
<infinity> tjaalton: Oh, not sure if you noticed, but I cleaned up your xorg-lts-transitional a bit (and then made my own stupid AA mistakes and reuploaded a no-change version bump, derp)
<infinity> tjaalton: For the record, it's really, really, really hard to see an s/v/w/ typo.  Please never do that again. :)
<infinity> (Seriously, I was writing test scripts and scratching my head, and COULD NOT FIGURE OUT why the vmware bit wasn't working right)
<infinity> Friggin' wmware.
<Odd_Bloke> What a nightwmvare.
<tsimonq2> hehehehe
<tjaalton> infinity: oh hell :p
<Mirv> FYI there would be a chance now to migrate Qt, KDE and half the world to release pocket with the new unity8 8.14+16.10.20160803-0ubuntu1 in yakkety-proposed. feel free to guide/hint things for that do become a reality, I guess some hinting might be required for things to migrate together. one list of source package names trying to migrate is
<Mirv> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-024/+packages + https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-041/+packages combined
<Mirv> unless of course boost or GCC6 somehow block it. anyway, everyone would be pretty happy to see the migration happening
<Mirv> and we know already that unity8 doess pass autopkgtest with proposed (unless some flakiness kicks in): https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety-ci-train-ppa-service-landing-073/yakkety/amd64/u/unity8/20160804_105904@/log.gz
<Mirv> I can only check in 12h myself
<dmj_s76> infinity: changes to the xorg-lts-transitional package since yesterday's iso
<dmj_s76> ?
<infinity> dmj_s76: That's in xenial, not trusty.
<infinity> dmj_s76: But yes, fixes to make 14.04.5 -> 16.04.1 upgrades work correctly.
<dmj_s76> ...ah, right, misread that
<dmj_s76> good, we like fixes that make upgrades work right, reduces support calls
<infinity> dmj_s76: As people who field a lot of front line user pain, we'd be happy if you escalate upgrade bugs to us.
<infinity> dmj_s76: Some other retailers who shall not be named are less helpful, and give us bug reports like "upgrades sometimes break, we suggest you don't let users upgrade, ever".
<infinity> tgm4883: Any reason I shouldn't mark myth ready?
<tgm4883> infinity: nope, I tested the ISOs and marked them passed yesterday.
<utlemming> y
<tgm4883> infinity: is there somewhere else I'm supposed to mark them ready?
<infinity> tgm4883: You can tick the iso and then "mark as ready" at the bottom, though that requires specific perms, which you may or may not have.  Give it a try.
<utlemming> sorry....keyboard typo :)
<infinity> tgm4883: (Note how everyone but you is bold)
<tgm4883> infinity: I'm possibly on the wrong page, looking at http://iso.qa.ubuntu.com/qatracker/milestones/365/builds/127923/testcases I don't see any way to do it
<tgm4883> nor on the http://iso.qa.ubuntu.com/qatracker/milestones/365/builds page
<infinity> tgm4883: It would be the builds page, so I guess you don't have the perms.  That's cool, I'll do it.
<infinity> tjaalton: And an update-manager-driven 14.04.5 -> 16.04.1 upgrade just now went flawlessly, even with an evil nvidia blob installed, I call it good.
 * ogra_ sighs ... who is sitting on the arm builders ? 
<infinity> They could use a little cleanup.
 * infinity goes to play.
<ogra_> well, i'll give up for the day ... the builders are lying though ... they tell me "starting in 1h" since 5h or so ...
<tjaalton> infinity: nice, a bit tight schedule-wise though ;)
<tjaalton> and :/
<infinity> tjaalton: Also, wmware. >:(
<infinity> WMWARE.
<infinity> ARGH.
<ogra_> virtual windowmanagers ?
<infinity> ogra_: http://launchpadlibrarian.net/276685150/xorg-lts-transitional_3%3A11_3%3A12.diff.gz <-- See the diff to gencontrol at the end.  It took me like 2 hours to spot the s/v/w/ bug.
<ogra_> argh !
<ogra_> thats super nasty
<infinity> Ran it through -x ... Was half convinced I'd found a bash bug.
<infinity> Stupid font making v and w look so similar to blind people.
<tjaalton> infinity: too easy to typo :)
<infinity> tjaalton: Please make future typos more obvious. :)
<tjaalton> :P
<doko> who can I convince to override the libreoffice autopkg test, triggered by gcc-6? it doesn't make things worse
<doko> same for the one triggered by boost-defaults
<robru> Can somebody investigate this unity-scope-click failure? It's holding up unity8 which is holding up Qt which is holding up a pile of phone stuff that everybody is waiting for http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#unity8
<robru> Segfault, which means nothing to me. Is this a gcc6 thing or boost?
<infinity> robru: You'd probably be better off asking the scope-click developers.
<robru> Bah
<bdmurray> jdstrand: the last click-reviwers-tools SRU had a meta bug like bug 1584231.  This upload doesn't have one and I feel like it should.
<ubot5> bug 1584231 in click-reviewers-tools (Ubuntu Yakkety) "update to 0.43 (aka, support 'confinement' field in snap v2 yaml)" [High,Fix released] https://launchpad.net/bugs/1584231
<jdstrand> bdmurray: are you saying you want me to create one and reupload?
<bdmurray> jdstrand: Let's check with another SRU team member.  infinity, slangasek?  I'm of the opinion that the click-reviewers-tools upload should have a metabug regarding the new version similar to the previous SRU.  What do you think?
 * jdstrand notes that for all issues fixed that had a bug he added the SRU paperwork
<infinity> jdstrand: That ld.so check is oddly amd64-specific.
<infinity> jdstrand: And the concern is that there are changes that don't have a bug, so there should be some other bug describing why we want those and what's up.
<infinity> extra_files=['/usr/lib/x86_64-linux-gnu/libmvec.so,libmvec.so'] is also fairly amd64-specific.
<jdstrand> if you want to do file a bug and reupload, I can
<bdmurray> And what the test plan is to ensure there are not any regressions.
<jdstrand> infinity: that is the testsuite
<jdstrand> it's a mocked file
<infinity> Ahh.
<infinity> Kay.
<slangasek> bdmurray: certainly, any SRU should have /either/ a metabug for the whole update, including testplan etc., /or/ a bug for each included change with testplan etc.  Are you saying this upload has bugs for some of the changes but not all?
<jdstrand> slangasek: that is what he is saying and what he is saying is true
<slangasek> ok
<slangasek> then "metabug" seems the most straightforward path for getting this SRU done
<jdstrand> ok
<slangasek> bdmurray: btw, please note that shim-signed has corresponding uploads for the other releases, maybe it's easiest to process these as a batch
<bdmurray> slangasek: Okay, I usually try and do that but missed the other tasks for some reason.
<slangasek> maybe the tasks were not created by the uploader :-)
<bdmurray> slangasek: there's an existing SRU of shim-signed waiting for verfication in Precise.  LP: #1574727
<ubot5> Launchpad bug 1574727 in shim (Ubuntu Xenial) "[SRU] Enforce using signed kernels and modules on UEFI" [Undecided,New] https://launchpad.net/bugs/1574727
<slangasek> bdmurray: right, I had gotten some feedback out of channel suggesting that the verification process on that one didn't work... I'd say we can leave precise as-is for right now
<dmj_s76> infinity: Are we expecting a release today or?
<infinity> dmj_s76: Yeah, it's pushing to mirrors.
<infinity> dmj_s76: Patience.
<infinity> dmj_s76: Plenty of Thursday left in the day. ;)
<dmj_s76> yeah, sorry to bug on that one, just wanted to know we can stage things properly to offer it tomorrow.
<infinity> dmj_s76: Ubuntu x86 ISOs should already be on releases.u.c
<infinity> Syncing the world takes a bit longer. ;)
<dmj_s76> ah...wasn't there several minutes ago
<infinity> dmj_s76: I'm magic.
* infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.5, Xenial 16.04.1 | 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
#ubuntu-release 2016-08-05
<Mirv> ok I guess the GCC6 is now causing autopkgtest problems, so long Qt, KDE migration. but unity8 itself would now pass autopkgtests, which was the last blocker before.
<flocculant> infinity: doesn't look like yak iso's built last night - or at least those which I'd expect to see a version dated 05 at this time
<Mirv> but could you somehow hint that always the latest unity8 would be used for autopkgtest? for example http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src uses the current release pocket version which cannot be installed with the new qtbase.
<Mirv> because otherwise even though eg unity-scope-click wouldn't segfault (gcc6? new boost?) the whole excuses page wouldn't be green because of the old unity8 results
<Mirv> of course, if you'd think it's acceptable, just allow Qt, KDE migrate to release pocket regardless of the new transition problems
<Mirv> among else unity-scope-click did pass before
<Mirv> now one of the tests segfault
<Mirv> anyway, feedback/help welcome, the Qt/KDE won't migrate by itself ever regardless, some hinting will be required
<infinity> flocculant: Oh, right, I need to reenable cron.  I had it off to not mess with my release.
<flocculant> :D
<flocculant> I thought it might have been something like that
<infinity> flocculant: Fixed.
<flocculant> infinity: thanks - have a more relaxing day today :)
<infinity> flocculant: I'm taking Friday off, so it better be relaxing.
<flocculant> \o/
<flocculant> infinity: have a great weekend then
<LocutusOfBorg> anybody working on ghc transition?
<Mirv> hi! Qt and KDE could migrate, but I need archive admin help
<jbicha> AAs, you can reject the older numix-gtk-theme
<Mirv> 1. qml-module-qtpositioning would need promoted to main so that qtlocation5-examples would work: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtlocation-opensource-src
<Mirv> 2. some more s390x binary removals would be needed that pitti was doing a lot because of the upstart problem: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtpurchasing-opensource-src and http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-system-settings
<Mirv> seb128: ^ can you help?
<Laney> plasma-workspace needs NBS removed too
<xnox> Mirv, hm, confused. britney says libpay2 is not satisfyable on s390x, yet it is built there....
<xnox> Mirv, it is less work not to remove s390x....
<seb128> Mirv, sorry but not atm, using my other laptop/doing some debugging and I don't have easy access to the acl from there, maybe later when I'm back at my desk
<xnox> huh, built but not available
<Laney> it's been removed
<Laney> https://launchpad.net/ubuntu/yakkety/s390x/libpay2
<xnox> why?
<Mirv> xnox: I remember pitti mentioning something about links, maybe the fact that it was binary copied from a PPA
<seb128> whoever decided to delete upstart on s390x would have better fixed the build
<xnox> slangasek, what does ANAIS stand for
<seb128> it's costing way more effort to deal with the things that keep getting blocked that it would have been to fix the build
<Laney> architecture not allowed in source
<Mirv> xnox: so there is a big list of reverse dependencies removed (but not all yet as shown), because upstart on s390x did not get fixed but removed instead
<Laney> in this case it build-depends on libubuntu-app-launch2-dev
<Laney> which is not present on s390x
<xnox> to be fair we all do have better things to deal with then chasing ubuntu-app-launch on s390x, but i see how much churn such a removal is causing.
<xnox> maybe we (I) should have listened to steve in the beginning and like not compile upstart on s390x at all
<Laney> that's just broken because of upstart isn't it?
<xnox> Laney, disable upstart testsuite on s390x, upload, live happily ever after?
<Laney> heh
<seb128> somebody (Steve?) said that the issue was no s390x though but building on xenial builders
<Mirv> kernel issue if I recall
<xnox> seb128, infinity did
<seb128> and that it's going to bite other archs if we need to SRU a fix to xenial
<xnox> so maybe we do need to fix upstart
<seb128> so somebody needs to fix upstart eventually anyway
<Laney> anyway
<Laney> the removal hasn't been followed through to the end
<Laney> so now we have issues like this
<xnox> but i don't get this claim.... aren't our virtual builders running xenial?
<seb128> well now, but at the time the xenial upstart was built it was on older builders it seems
<xnox> 3.13.0-92-generic
<seb128> rebuild today wouldn't work
 * Laney tests that claim
<Laney> https://launchpad.net/~laney/+archive/ubuntu/ppa/+build/10568298
<xnox> i wonder why cloud-builders are not using xenial cloud images as base
<xnox> for buildds
<xnox> cjwatson, ^ or is the move gonna happen only after trusty is end of live?
<xnox> how about using hwe xenial kernel in the trusty cloud image?
<Mirv> anyway, it'd be nice if an archive admin could promote the qml-module-qtpositioning , NBS remove plasma-workspace and then remove the packages being discussed if/when upstart isn't going to be fixed soon still
<Mirv> that would be removal of libqt5purchasing5 qtpurchasing5-dev ubuntu-system-settings on s390x, or something else/more?
<Mirv> I wonder if didrocks would be around if seb128 might not have time at the moment
<Laney> Check they have a build-dep which will prevent the binaries coming back the next time
<Mirv> ok, checking
<Mirv> yes for qtpurchasing packages, they can't be built on s390x anymore thanks to pitti's removals
<Mirv> however ubuntu-system-settings would reappear on next build, something would need to be done about that
<Mirv> not sure about the preferred action there, could simply state u-s-s not to build on s390x
<Laney> add a build-dep on upstart or ual or something
<Mirv> right that'd be easiest, I can propose that for the next u-s-s landing
<Mirv> I think US archive admins would be online soon, hopefully they can help with those actions above if Europeans don't have time to. I will do the u-s-s MP and check back later if there's anything else to help with, but it'd be a nice present to everyone to get the migration going (or at least closer to being reality)
<Mirv> made the MP https://code.launchpad.net/~timo-jyrinki/ubuntu-system-settings/stop_s390x_problems_depend_on_upstart/+merge/302143
 * xnox uploaded upstart into PPA with a testsuite fix
<Laney> :-o
<Laney> is it a fix or a workaround? :P
<xnox> let's wait to see if it works
<xnox> non-system non-session (so upstart pretending to act like pid 1, but running as pid whatever and non-root) fails to connect to dbus when told so whilst stuck processing and spawning system jobs and generates loads of "failed to start plymouth" and what not
<xnox> that test case only tries to call "initctl version" to check that upstart connects to session dbus when asked
<xnox> changed test-suite to spawn upstart with "--no-startup-event" such that upstart in such configuration is simply spawned and connects to dbus, but doesn't try to mess with anything else
<xnox> makes the tests pass on my machine at least, previously failing.
<xnox> https://launchpadlibrarian.net/277265629/upstart_1.13.2-0ubuntu28_1.13.2-0ubuntu29.diff.gz
<Mirv> or hmm would apw still be around?
<Mirv> anyhow, I'd propose trying to get Qt & KDE migrated today with the actions above, and if there is some hope with upstart start re-enabling the chain of s390x next week
<xnox> hm, somethings wrong build on amd64 done, still pending on s390x
<xnox> still fails on s390x
<slangasek> Mirv: qtpurchasing/s390x binaries removed from yakkety-proposed; qml-module-qtpositioning promoted to main
<slangasek> was there anything else?
<Laney> slangasek: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#plasma-workspace NBS
<slangasek> removed
<sil2100> Wooo \o/
<sil2100> Let's see if we have more problems down the stack now
<Laney> can't imagine this will be the end of the story
<Laney> but it'll be clearer
<Mirv> slangasek: sil2100: hi, thanks! there was also ubuntu-system-settings/s390x removal http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-system-settings
<Mirv> and then a relook at update_output.txt probably
<Mirv> although u-s-s is actually not strictly required for the transition I think
<Mirv> since it does not depend on the private Qt ABI. I might be wrong too. more help with parsing excuses&output would be welcome.
<slangasek> Mirv: if I delete ubuntu-system-settings/s390x now, what prevents it from coming back again?
<slangasek> does it have any build-dependencies on s390x NBS packages?
<Laney> he just made a MP to add that
<Laney> a synthetic BD on upstart, or equivalent
<Laney> slangasek: ^-
<slangasek> ok
<sil2100> Yeah, I reviewed that change, so it's just a matter of getting that MP released
<Mirv> I just think that's not necessarily the current remaining blocker but something else is, as u-s-s should not be a required part of the transition
 * Mirv -> shopping
<Mirv> (neither is mediascanner, scopes-api etc)
<Mirv> sil2100: slangasek: can you check if something should be simple hinted a bit more to migrate together? if I look at update_output.txt and the last occurence of qtbase including Trying easy from autohinter section, it claims relatively little amount of packages "uninstallable" (or the per architecture list), but for example gammaray, plasma-desktop, plasma-workspace can be installed together
<Mirv> all of KDE needs to go in, as parts of it depend on Qt private 5.6 ABI and all of Frameworks / Plasma release in proposed depends on each other to go together
<Mirv> there are some in the lists though that do not need to migrate together with Qt/KDE
<Mirv> the combined set of packages that I know need to mostly go in together is the list of source names at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-011/+packages + https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-041/+packages
<Mirv> others not so
<Mirv> anyway, even if I would have more time I think I cannot think of anything else myself, I can install everything required in my yakkety-proposed while some unrelated stuff like lubuntu-qt-desktop has problems (lubuntu meta depends on Laney / tedg 's click breaking / packagekit upgrade I think)
<Laney> It'll be a bit irksome if you get entangled with that one
<Laney> finally ubuntu-release-upgrader is running, now samba has settled down
<slangasek> Mirv: looks to me like the current problem is autopkgtests still running for plasma-workspace
<k1l_> hi. there is an issue with users wanting to upgrade from the EOL 15.04 right now. regular upgrade doesnt work and EOL upgrade with old-releases isnt activated yet. see bug #1609796
<ubot5> bug 1609796 in update-manager-core (Ubuntu) "cant upgrade EOL 15.04" [Undecided,New] https://launchpad.net/bugs/1609796
<k1l_> running do-release-upgrade -d works, strangely, but i doubt that is the planned way to upgrade the 15.04 now
<slangasek> infinity, bdmurray: ^^ I guess that's because 15.10 had the EOL switch flipped?
<infinity> Erk, yeah, it's not been mirrored yet.
<infinity> I guess I can flip it back until that's sorted.
<infinity> slangasek: Reverted.   Will sort it all out on Monday.
<infinity> slangasek: Although, the bug report is more than just old-releases mirroring, we really *should* be supporting vivid->xenial, so probably need some SRUs to address that too.
<bdmurray> ubuntu-release-upgrader has DistUpgrade.cfg files that allow upgrading from W -> X or T -> X.  We could add more I guess.
<infinity> Anyhow, it should be okayish with the revert for now, we can sort the proper solution.
<bdmurray> infinity: did you update the changelogs server too?
<k1l_> ok, just tested my 15.04 vbox install and the do-release-upgrade now works.
<infinity> bdmurray: Yep.
 * infinity goes back to not being here, and wondering why he didn't buy a bunch of USB-C cables with his new phone.
<k1l_> imho there should be a decision if there should be a non-LTS upgrade path overstepping some releases. iirc there were some issues when 14.10 went EOL, too.
<infinity> k1l_: Yes, I think the right answer is that we should always support upgrades to the next LTS directly, but that means testing those upgrade paths, not just flipping a switch and hoping. :)
<k1l_> yeah. but when 14.10 goes EOL there is no next LTS :/ imho there are some points of upgrade through that 4 years timeframe that need to have a rethink.
<k1l_> we had lots of users in #ubuntu wanting to go from 14.04(.X) to 15.10. but the releases inbetween were EOL already.
<bdmurray> I thought the work I did in bug 1497024 should have allowed that.
<ubot5> bug 1497024 in update-manager (Ubuntu Vivid) "release upgrades should jump over unsupported releases" [High,Fix released] https://launchpad.net/bugs/1497024
<k1l_> bdmurray: ok. than maybe there is just some needed clarification on what upgrade-path is supported on what situation. in #ubuntu there were a lot of issues with the jumping over releases so most supporters told to do EOL-upgrades.
<bdmurray> k1l_: where would you want to see that clarification?
<k1l_> bdmurray:  on the upgrade pages in the help or wiki dokumentation? so we have something to show people what the designed and tested upgradeplan is.
<slangasek> Mirv: so, plasma-workspace autopkgtests are failing on all archs, that's not going to migrate on its own
<slangasek> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#plasma-workspace
<yofel> slangasek: please badtest those, 2 of those test try to open windows that need to be closed by hand
<yofel> I'll patch those out of the next upload
<slangasek> yofel: done, thanks
#ubuntu-release 2016-08-06
<Mirv> slangasek: yofel: there is still _something_ blocking...
<LocutusOfBorg> hi cjwatson slangasek I'm trying to sort out haskell, I'm still noob on this transition, so please don't shoot at me ;)
<Mirv> hi archive admins, can you remove gammaray-dbg plese (old binaries): http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gammaray
<Mirv> trying installing all of the amd64: packages in update_output.txt, that's the last one that has problems from the packages that are required to migrate. however there are more packages in there like lxqt, language packs and meta packages that have eg samba problems, I'm not sure if those other problems prevent Qt & KDE
<Mirv> even though not preventing installations in my testing, also needed are removing libkf5activitiesexperimentalstats1 http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#plasma-desktop and plasma-sdk-dbg http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#plasma-sdk
<Mirv> (if any archive admin is around during the weekend)
<cjwatson> xnox: RT#92640
<ari-tczew> hey, could someone take a look on https://launchpad.net/ubuntu/+source/glusterfs/3.8.1-1ubuntu1/
<ari-tczew> I guess there's something hanging on
<ari-tczew> (builders)
#ubuntu-release 2016-08-07
<Mirv> repeating my Saturday's request for example if RAOF comes online before my Monday morning. please remove from yakkety: gammaray-dbg libkf5activitiesexperimentalstats1 plasma-sdk-dbg - see https://irclogs.ubuntu.com/2016/08/06/%23ubuntu-release.html#t06:33 for excuses links
<Mirv> of course anything else spotted preventing Qt and KDE migration welcome, those are the ones still easily found from excuses page
<doko> Mirv, removed, but only removed from yakkety-proposed
<doko> update_output says something about "info: broken arch run for mips64el". maybe disable that?
#ubuntu-release 2017-07-31
-queuebot:#ubuntu-release- Unapproved: gnome-logs (zesty-proposed/universe) [3.24.1-0ubuntu1 => 3.24.2-0ubuntu0.1] (ubuntugnome)
<apw> slangasek, well even if the kernel i have just promoted would have helped with binutils ... the fact it has now been uploaded again negates any benefit there
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.11.0-12.17] (core, kernel)
<apw> (i assume)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.11.0-12.17]
<apw> slangasek, ok confirmed with adam ... a no change rebuild uploaded for that
<xnox> slangasek, i see a lot of s390x: regression but so far they are due to uninstallable test depends, i'm retrying those with all-proposed to see actual failures =/
<xnox> retriggered all perl regressions on s390x with the right triggers and all-proposed=1 will check back the status of that.
<doko> xnox: hmm, why just s390x?
<xnox> "<slangasek> xnox: there appear to be a couple of genuine regressions on s390x autopkgtests with perl 5.26" to find these
<xnox> slangasek, also do backdoor runs with all-proposed actually achieve anything w.r.t. britney? as everything still needs to have the right triggers to get the status updated for the right combo, no? or does all-proposed tests update any status of any tests?
<xnox> using script from ubuntu-archive-tools i get requests that list _both_ triggers and all-proposed.
-queuebot:#ubuntu-release- Unapproved: base-files (xenial-proposed/main) [9.4ubuntu4.4 => 9.4ubuntu4.5] (core)
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (xenial-proposed) [9.4ubuntu4.5]
<xnox> I fixed http://autopkgtest.ubuntu.com/packages/ruby-httpclient =) it failed adt tests because of proxies set in the environment =)
<ginggs> anyone have any ideas about eigensoft autopkgtest failure on amd64 http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#openblas ?  Removing autopkgtest-satdep:amd64 because I can't find eigensoft:amd64
<nacc> ginggs: have you retried it? i see the one for perl at the same version of eigensoft passed
<ginggs> nacc: i have retried it
<slangasek> apw: -12 is the kernel we're after for binutils, not -11 :)
<slangasek> apw: no change rebuild of the kernel in the archive?  weird :)
<slangasek> xnox: you seem to have been looking at something different than I was.  I was talking about the autopkgtest failures shown under perl itself that were s390x-specific
<slangasek> xnox: I have already done all the retriggers and there were s390x-specific failures, what I'm looking for here is analysis
<slangasek> ginggs: you and me both, then?  The eigensoft autopkgtest is failing because for some reason the runner is failing to find packages that are in multiverse, despite a log file showing that it's downloaded the Packages file
<slangasek> eigensoft was not the only example of this, and it's amd64-only
<slangasek> Laney: ^^ do you have any insight here?
<xnox> slangasek, ah.
 * xnox goes to look again
<slangasek> xnox: it's also possible that something changed in between my last retry and yours, since now there are zero s390x-specific failures listed <shrug> :)
<slangasek> fwiw my approach here has been "work through the pile on perl, to get perl considered as a candidate; then work through the revdeps"
<slangasek> we only have "interesting" autopkgtests failing now with the new perl - cacti, and all the databases
 * xnox ponders if those have any users
<xnox> *giggle*
<apw> slangasek, yeah that one was prepped in a -security compatible PPA ie missed binutils ... we need to change our proceedures for queueing uploads for devel specificially
<apw> slangasek, so that they are built in a ppa which has -proposed enabled
<slangasek> (not counting auto-multiple-choice, which I fixed in -proposed but FTBFS because of TeX; arename, which is currently rerunning; libchi-perl, which I've bugged Debian; libtest-aggregate-perl, which I've just removed)
<slangasek> apw: ah indeed
<slangasek> xnox: oh, and there are test regressions against systemd; what do we do about those?
<slangasek> (I assume systemd/{amd64,i386} will pass against new perl if we just run it with the right version)
<xnox> slangasek, it seems to me that boot-smoke is not reliable in containers; thus i should blacklist to run only on full VMs / machines.
<xnox> and there is an extra armhf regression which i thought is fixed (because it is fixed on arm64) bot alas that didn't fix it on armhf.
<slangasek> xnox: so am I waiting for a new upload of systemd?
<nacc> ginggs: hrm, i don't know, sorry
<slangasek> nacc: see my reply to ginggs
<nacc> slangasek: ah sorry, i missed that!
<nacc> slangasek: yeah that does seem like an oddity
<xnox> slangasek, si senior
<slangasek> xnox: k.  one of the failing revdeps of systemd is unity8 still, so there's also that to drill into
<xnox> slangasek, rm pay-service; rm ubuntu-push; rm unity8
<xnox> https://bugs.launchpad.net/ubuntu/+source/pay-service/+bug/1707680
<ubot5> Ubuntu bug 1707680 in pay-service (Ubuntu) "RM: obsolete product" [Undecided,Triaged]
<xnox> slangasek, full updated with the chain https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1707680
<ubot5> Ubuntu bug 1707680 in pay-service (Ubuntu) "RM: obsolete product" [Critical,Triaged]
<slangasek> xnox, infinity: how is this apt SRU supposed to DTRT when the corresponding unattended-upgrades piece does not appear to have landed in SRU?
<slangasek> xnox, infinity: I am concerned that by half-landing we have in fact regressed the distribution of downloads throughout the day
<slangasek> which if true is critical and needs reverted
<xnox> slangasek, we disucssed this in detail
<xnox> slangasek, unattended-upgrades fixes are independant of the apt-timers fixes.
<xnox> slangasek, this apt update does the right thing, w.r.t. timers. With current, or future unattended upgrades.
<xnox> slangasek, the split of apt-timer into update step and upgrade step is the only critical piece, that the current apt in proposed resolves.
<xnox> slangasek, it is critical, as there are affected partners w.r.t. timers.
<xnox> there will be unattended-upgrades SRU in the future, which is decoupled from apt SRUs.
<slangasek> xnox: ok, have satisfied myself that the unattended-upgrade piece is separate, thanks
<slangasek> (what I don't understand is why you need to call unattended-upgrade --download-only at all, if the updates are already being handled in the previous section with 'apt-get -y -d dist-upgrade')
<slangasek> xnox: hmmm except I find APT::Periodic::Download-Upgradeable-Packages "0"; in grep: /etc/apt/auth.conf: Permission denied
<slangasek> no, not there
<slangasek> in /etc/apt/apt.conf.d/10periodic
<slangasek> xnox: how did you confirm that updates were actually downloaded when apt-daily.service ran, as opposed to being downloaded at 6am?
<xnox> slangasek, i did not check that in my test, because my container was up to date with respect to security updates. Let me downgrade things, to make that happen.
<xnox> 1) downgrade package 2) clean caches 3) manually start apt-daily.service 4) verify that it download things
<slangasek> xnox: yes please
<slangasek> without that check, my reading of the code has me wary that w/o the unattended-upgrades fix we are indeed going to be doing all the downloads at 6
<xnox> right, it is tricky, as the code above unatteded-upgrades should do ~= apt-get --download-only
<xnox> but not obvious.
<slangasek> xnox: yes, that's what the code does, but only if /configured/ to do so, using a flag that is set to 0 by default in apt
<slangasek> AFAIK we were not using that code path at all and were only using unattended-upgrades; so now, since the u-u piece hasn't landed, we're a no-op in apt-daily.service and doing all the downloads in apt-daily-upgrade.service (AIUI)
<xnox> slangasek, and we would have saved so much time, if we would have assumed that you are right.
<xnox> downgraded systemd to release pocket, because there is a systemd in security pocket.
<xnox> wiped all the apt periodic timers
<xnox> launched apt-daily.service -> it did not download anything
<xnox> launchped apt-daily-upgrade.service, no-block, with watch -d over /var/cache/apt/archives/, and noticed how systemd and libsystemd0 got downloaded, (installed), and removed from the cache.
<xnox> so yeah, apt lists are downloaded randomly, but the heavy downloads are done at 6am.
<xnox> so we really need unattended-upgrades SRU too
<xnox> slangasek, it would fix the customer problem, but regress the IS concern.
<infinity> The unattended-upgrades --download-only thing is trivial, isn't it?  Can we JFDI?  Or should we revert apt?
<xnox> well there is a pending unattended-upgrades SRU from steve
<xnox> oh no, that is in updates
 * xnox is blind
-queuebot:#ubuntu-release- Unapproved: gnome-applets (zesty-proposed/universe) [3.22.0-2ubuntu0.1 => 3.22.0-2ubuntu0.2] (desktop-extra, edubuntu)
<xnox> infinity, slangasek: so we would need - https://github.com/mvo5/unattended-upgrades/commit/2e5deed4a3ef77fb0dcc02525eb32ed134b98a91 and https://github.com/mvo5/unattended-upgrades/commit/f26edb4425e488d7acdb825b0b6e8e327d2d51e6
<xnox> is that landable? shall I prepare SRUs and test it?
<slangasek> xnox: yes to those commits; apt also needs a versioned breaks: against unattended-upgrades
<slangasek> infinity: ^^
<infinity> slangasek: Cat's out of the bag a bit on the versioned Breaks.  People who already upgraded won't benefit, and the next round of upgrades would bring in unattended-upgrades.
<infinity> slangasek: (and it doesn't technically "break" it, just gives you behaviour that's not perfectly ideal)
<infinity> slangasek: But we can delete that update right now if you'd prefer it not go out to more people yet.
<slangasek> infinity: "the next round of upgrades" - except that people may or may not install all of the updates together, and what if at a later date there's an updated apt in the security pocket
<slangasek> infinity: the fact that this is all in -updates rather than -security leaves me confident that we don't need to revert anything if unattended-upgrades will happen ASAP
<slangasek> but it does need to be in a coherent state before the point release
<infinity> slangasek: Sure, I'm all for pushing out the u-a fix quickly.
<xnox> u-a for Apgrades =)
<infinity> slangasek: I was arguing that the versioned breaks doesn't buy us much at this point.
<slangasek> infinity: yes, it's not a huge benefit and the versioned breaks don't even matter for the point release, but I think we should follow through on it all the same
<infinity> xnox: The download-only commits indeed look trivial.  I can haz?
<infinity> slangasek: Perhaps.  Though you're then asking for a time bomb on the next apt security update, unless someone copies u-a over there today.
<xnox> infinity, sure. but later tonight. I'm like need to go to volleyball in 8minutes.
<infinity> xnox: Okay, maybe I'll pick it up, then.  Or get $someone to, so I can do the review.
<xnox> infinity, i'll be back in like 3h or so to do it.
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~16.04.2 => 0.7.9-233-ge586fe35-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<slangasek> infinity: the alternative would be a time bomb that on the next apt security update, we regress unattended-upgrades behavior again for all the u-u security-only users (i.e. everyone with the default 16.04 config) and spike the load on archive.u.c
<infinity> slangasek: Yeah.  I'm not convinced more than 3 users actually run security-only (though, indeed, most people run security-only-automatic, as it were).
<slangasek> infinity: millions of cloud instances by default :)
<infinity> slangasek: They're the latter, but not the former.
<slangasek> right
-queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~17.04.2 => 0.7.9-233-ge586fe35-0ubuntu1~17.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<smoser> can someone NACK both of my cloud-init uploads ?
<smoser> i want to update the changelogs a bit
<jdstrand> infinity: I meay be weird and 1 of the 3, but I've been known to run security only on a machine or two
<slangasek> smoser: done
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (zesty-proposed) [0.7.9-233-ge586fe35-0ubuntu1~17.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (xenial-proposed) [0.7.9-233-ge586fe35-0ubuntu1~16.04.1]
<infinity> jdstrand: You're weird.
<slangasek> :)
<infinity> jdstrand: I dunno.  mdselaur and I have discussed it many times, usually in the context of "oh, look at that bug that's existed for the last 2 months for anyone who's security-only, and literally zero people reported it".
<jdstrand> I never claimed otherwise :P
<infinity> jdstrand: And while I'm aware that we have millions of users who don't report bugs, I'd also suspect that the sort of paranoid people who would deliberately choose tha tconfiguration would also have a higher representation in the "users that actually file bugs" cross-section.
<jdstrand> I agree it is likely a small number and me as an example is obviously anecdotal
<jdstrand> but, I do understand the desire and suspect there are enough to continue to support security only, which was really the only reason I brought it up
<jdstrand> obviously I don't have any hard data
<infinity> Yeah, we have something close to zero data.
<infinity> Which is why we've not brought up the inverse seriously either.
<infinity> THough we privately discuss "hey, maybe 18.04 should merge the security and updates pockets".
<jdstrand> I suspect Dustin might be able to get something slightly better than anecdotal data for at least UA customers
 * jdstrand shrugs
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (xenial-proposed/main) [0.90ubuntu0.6 => 0.90ubuntu0.7] (desktop-core, ubuntu-server)
<slangasek> infinity: ^^ unattended-upgrades for review at your convenience
<slangasek> xnox: I've also updated the test case to mention the 'manually trigger apt-daily.service' bit, please check that I have expressed this correctly
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (zesty-proposed/main) [0.93.1ubuntu2.2 => 0.93.1ubuntu2.3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: linux (artful-proposed/main) [4.11.0-12.18 => 4.11.0-12.18] (core, kernel)
<slangasek> xnox: unity8 out.  are we now unblocked wrt the Qt transition?
<slangasek> tsimonq2: ^^ are all of the ubuntu-touch qt packages gone that *you're* expecting to see removed in order to unblock Qt?
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~16.04.2 => 0.7.9-233-ge586fe35-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~17.04.2 => 0.7.9-233-ge586fe35-0ubuntu1~17.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~16.04.2 => 0.7.9-233-ge586fe35-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapcraft (zesty-proposed/universe) [2.31+17.04 => 2.33+17.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.31 => 2.33] (no packageset)
<sergiusens> infinity: hi. Mind taking a look at those two? ^
-queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~17.04.2 => 0.7.9-233-ge586fe35-0ubuntu1~17.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<xnox> slangasek, slight adjustment to the test case #1 remove periodic stamp files #2 after apt-daily.service systemd should be downloaded, but not upgraded. starting apt-daily-upgrade should upgrade it only /without/ downloading.
<xnox> slangasek, you have unattended-upgrades in progress are you preparing the srus? /me checks the queue.
<xnox> ah, it is.
<xnox> looking good.
<xnox> uploaded into artful, to fix the bugs there. and to test it there.
<xnox> if and when infinity accepts unattended-upgrade i'll test it.
<Laney> slangasek: Just want to say that I'm at a conference, so very limited ability to investigate stuff atm
<slangasek> Laney: ack (DebConf?)
<Laney> suggest trying it locally and seeing if it reproduces (commandline at the top, tweak that)
<Laney> if so, then you have somewhere to start from to debug
<Laney> no, GUADEC --- but will be at Debconf from Wednesday
<slangasek> Laney: I didn't try the exact commandline, but fwiw it seems to only have trouble finding the multiverse packages on amd64, not on other archs... I will have a look though
<Laney> yeah, not sure ottomh, sorry :(
<slangasek> no worries
<slangasek> gcc: error: unrecognized command line option '-mno-red-zone'; did you mean '-fno-regmove'?
<slangasek> now, if someone could explain to me why git bisect of ffmpeg on s390x gives me *that* gem... :P
<slangasek> mm that may not be the actual failure, n/m
<slangasek> anyway, merge commits for git bisect == teh suck
<xnox> yeah, people should use nice and linear history.
<nacc> heh
<xnox> slangasek, more removals https://bugs.launchpad.net/ubuntu/+bugs?field.tag=u8rm those that are trianged are good to go, to help towards removing UOA
<xnox> not sure about the Qt5.6 removals.
<xnox> i think we will not be able to remove ubuntu-ui-toolkit, until the mir kiosk people drop content-hub.
<xnox> Saviq, what's the status around keeping content-hub? and can it be made to not depends on ubuntu-ui-toolkit or some such? (via libertine i think)
<xnox> or rather i mean make libertine not depend on content-hub, such that we can remove liberitne.
<xnox> looking at https://bugs.launchpad.net/ubuntu/+bugs?field.tag=qt5.6
<xnox> i think there are circular dependenices around libertine.
<xnox> libertine and content-hub build-depend on each other.
#ubuntu-release 2017-08-01
<tsimonq2> slangasek: afair it was something along the lines of ubuntu-ui-toolkit (not sure if the first word is correct, it was ui-toolkit
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (xenial-proposed) [0.90ubuntu0.7]
<tsimonq2> )
<tsimonq2> slangasek: So let me look
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (zesty-proposed) [0.93.1ubuntu2.3]
<tsimonq2> slangasek: Nope, still need ubuntu-ui-toolkit to be removed :)
<tsimonq2> slangasek: In any case, I'll get back to you in a bit about what else (if there is anything else)
-queuebot:#ubuntu-release- Unapproved: accepted linux [amd64] (artful-proposed) [4.11.0-12.18]
-queuebot:#ubuntu-release- New binary: ruby-retriable [amd64] (artful-proposed/universe) [3.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: sphinxcontrib-websupport [amd64] (artful-proposed/universe) [1.0.1-1] (no packageset)
<slangasek> tsimonq2: ubuntu-ui-toolkit has a substantial number of revdeps still
<tsimonq2> slangasek: Looking at these reverse dependencies, all of them seem to be Unity 8-related.
<slangasek> possibly, but they still need to be gone through one at a time
<tsimonq2> What would be the best way to proceed? File a removal bug against each package?
-queuebot:#ubuntu-release- New: accepted ruby-retriable [amd64] (artful-proposed) [3.0.1-2]
-queuebot:#ubuntu-release- New: accepted sphinxcontrib-websupport [amd64] (artful-proposed) [1.0.1-1]
<slangasek> tsimonq2: ultimately, yes; please coordinate with xnox on this
<tsimonq2> slangasek: sure, thanks
<tsimonq2> xnox: What would you like to do irt ubuntu-ui-toolkit revdep removal (because we need ubuntu-ui-toolkit removed for Qt to successfully migrate)
<tsimonq2> ?
<tsimonq2> (that's a question, it gets a question mark :P)
<Saviq> xnox: AFAIK, we don't need content-hub, we should get rid of it across the board, but might wanna confirm with willcooke as to what the plan is for secure data transfer between snaps
-queuebot:#ubuntu-release- Unapproved: xorg-server (xenial-proposed/main) [2:1.18.4-0ubuntu0.3 => 2:1.18.4-0ubuntu0.4] (desktop-core, xorg)
<xnox> tsimonq2, i do not have confirmation about a number of things in that rev-deps list. Last time I discussed them, they have been requested to be kept in the archive.
<xnox> Saviq, i shall write an email about it, to have an email confirmation.
<Saviq> kk
<infinity> xnox: Oh good, you're awake.  Can you verify that unattended-upgrades thing?
<xnox> infinity, yes.
<infinity> xnox: My hero.
<tsimonq2> xnox: Ok, I'll look into seeing how hard it would be to update ubuntu-ui-toolkit for the new Qt
<xnox> infinity, it did the right thing on xenial. will check zesty now.
<xnox> bug updated w.r.t. tags for xenial.
<infinity> xnox: xenial's all I care about right now, so thanks. :P
<sil2100> ;p
<infinity> xnox: Though you seem to have lied about the tags. ;)
<infinity> xnox: Anyhow, released for xenial, you can fix the tags to match reality. :P
<xnox> bah
<xnox> infinity, it was pending me to click the green tick. seems to have edited the tags but didn't submit them.
 * xnox goes to find coffee
<infinity> Heh.
<xnox> also maintainer scripts generated by deb-systemd-invoke shit is broken in zesty.
<xnox> and/or systemd.
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (xenial-proposed/main) [4.11.0-12.17~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (xenial-proposed) [4.11.0-12.17~16.04.1]
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base powerpc [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop amd64 [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop i386 [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Xenial 16.04.3] (20170801) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Xenial 16.04.3] (20170801) has been added
<LocutusOfBorg> seriously? new perl?
<teward> LocutusOfBorg: where have you been the past month lol
<teward> that's been causing hellish things for a while now heh
<LocutusOfBorg> teward, where have you been?
<LocutusOfBorg> I *did* sync it
<LocutusOfBorg> I'm talking about the -5 autoimported update
<teward> ah, ok.
<LocutusOfBorg> :)
<teward> LocutusOfBorg: i'm not awake, sue me.
 * teward chugs his fifth coffee of the day
<LocutusOfBorg> lol no problem dear, I wasn't really clear in the first sentence
<LocutusOfBorg> and having thousand of tests rerun makes me sad and grumpy :p
<LocutusOfBorg> btw I did sync it less than a week ago :)
<LocutusOfBorg> doko, what happens with gcc switch now?
<doko> what should happen?
<LocutusOfBorg> will you wait for perl to transition or will you pull the trigger?
<LocutusOfBorg> (to finish I mean)
<LocutusOfBorg> Laney, sorry but I see lots of "test in progress" and no test running (or queued) what is that?
<teward> LocutusOfBorg: ah, well a couple weeks ago nginx updates got hung by the Perl stuff, was that your sync/upload as well?
<LocutusOfBorg> yep
<LocutusOfBorg> we tried to make that transition smooth, but I/we apparently failed
<LocutusOfBorg> hopefully somebody will have a look at autopkgtests not running
 * LocutusOfBorg leaves
<jdstrand> fyi tyhicks and sbeattie> the apparmor upload fixes the autopkgtest issues and update_excuses is fine for it (no regressions), but it isn't (yet) being considered because of the perl in -proposed that hasn't migrated yet
<tyhicks> jdstrand: that should be fine because, IIRC, the kernel tests enable -proposed
<infinity> Not without some trickery, no.
<infinity> But that can be done where needed.
<jdstrand> infinity: it isn't needed. it's fine if it flows in whenever perl does
<jdstrand> infinity: thanks though
<jdstrand> well, for some definitionof 'whenever' :)
<tyhicks> -proposed is enabled for the kernel tests
<tyhicks> Get:45 http://ftpmaster.internal/ubuntu artful-proposed/main amd64 apparmor amd64 2.11.0-2ubuntu10 [495 kB]
<tyhicks> (from https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/amd64/l/linux/20170729_223227_2ecb4@/log.gz)
<jdstrand> yeah. I looked at the logs apw gave and saw I needed to have proposed enabled, which brought in a more sensitive podchecker, etc, etc
<apw> tyhicks, isnt that because apparmor is updated and a trigger on the test?
<tyhicks> apw: ah, that is probably true
<apw> though in that log it seems that all-proposed is enabled, which seems unexpected to me
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Xenial 16.04.3] (20101020ubuntu451.14) has been added
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Xenial 16.04.3] (20101020ubuntu451.14) has been added
-queuebot:#ubuntu-release- Builds: Netboot armhf [Xenial 16.04.3] (20101020ubuntu451.14) has been added
-queuebot:#ubuntu-release- Builds: Netboot i386 [Xenial 16.04.3] (20101020ubuntu451.14) has been added
-queuebot:#ubuntu-release- Builds: Netboot powerpc [Xenial 16.04.3] (20101020ubuntu451.14) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Xenial 16.04.3] (20101020ubuntu451.14) has been added
-queuebot:#ubuntu-release- Builds: Netboot s390x [Xenial 16.04.3] (20101020ubuntu451.14) has been added
<sergiusens_> apw: if you are around, mind looking at snapcraft 2.33 waiting to be approved into {xenial|zesty}-proposed ?
<apw> sergiusens_, sure
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (zesty-proposed) [2.33+17.04]
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.33]
<apw> sergiusens_, ^
<slangasek> yay, autopkgtests for mariadb-10.1 fixed themselves upstream in Debian
<slangasek> xnox: new systemd upload still pending?
<xnox> slangasek, preparing, and it should resolve snapd not starting in lxd containers.
<xnox> (and maybe even fix systemd->snapd autopkgtests on armhf/s390x)
<xnox> slangasek, are you desparate to unblock migrations?
<slangasek> xnox: not desperate, just wondering about timeline
<xnox> ok. also it seemed to have lost test results for amd64/i386 - it claimed still running without any results recorded anywhere, and nothing in running. I retriggered that by hand.
<xnox> is that normal to loose results and claim they are still running?
<xnox> and that did not seem to work.
<slangasek> aaaaand perl got a new revision uploaded in Debian.  yay.
<xnox> slangasek, why it says "autopkgtest for systemd/234-2ubuntu1" triggered by systemd/234-2ubuntu1 claims to be "Test in progress" but it is nowhere on amd64 and i386.
<xnox> unless it just got around to do them
<xnox> http://autopkgtest.ubuntu.com/running#pkg-systemd
<xnox> says that i requested it.
<xnox> but running for 1h34m that cannot be right.
<xnox> You are in emergency mode. After logging in, type "journalctl -xb" to view
<xnox> system logs, "systemctl reboot" to reboot, "systemctl default" or ^D to boot
<xnox> into default mode.
<xnox> Press Enter for maintenance
<xnox> (or press Control-D to continue):
<xnox> that does not seems right =(
<apw> xnox, systemd broken again perhaps ?
<slangasek> yes maybe the reason you're not getting systemd test results is because you broke everything ;)
<xnox> lovely
<xnox> it did pass on the one architecture that matters - ppc64el =)
<xnox> so on s390x NetworkManager-wait-online.service fails to complete, within 10s, after 5 reboots.
<xnox> but that has timeout 30.
<slangasek> Laney: could you document on https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure how to remove tests from the queue?
<slangasek> ... also, what happened to all of the perl-triggered tests that britney thinks are "in progress" :P
<Laney> slangasek: ok, on thursday, but for now - filter-amqp on autopkgtest-cloud-worker/0; see shell history
<slangasek> Laney: cool,t hanks
<Laney> if you want to document it based on that, feel free
<Laney> no clue what happened to the tests
<Laney> bos01 had a sad but that seems to have sorted itself
<Laney> can't explain lcy01/lgw01
<slangasek> yeah, I'll requeue the lot
<Laney> mmm
<Laney> there was a rabbitmq upload around the time
<Laney> that's suspicious
<Laney> update applied*
<slangasek> applied on the runners?
<Laney> on the rabbitmq server
<Laney>    Active: active (running) since Tue 2017-08-01 11:27:48 UTC; 8h ago
<apw> oh man, they can't have flushed the lot, can they?
<Laney> I can't prove it but the timing is interesting at least
<Laney> the queues are durable so the messages should have survived a restart
<slangasek> so I have retry-autopkgtest-regressions running, it says a lot of things, and http://autopkgtest.ubuntu.com/running doesn't show any queues filling up
<slangasek> Laney: how do you know about the rabbitmq server upgrade?
<slangasek> (i.e. which thread should I pull for details)
<slangasek> now for comparison, the one test I queued using run-autopkgtest from snakefruit apparently *did* start
<Laney> I just triggered apt/zesty using request.cgi
<Laney> it's there
<slangasek> oh
<slangasek> I should read my wget output
<slangasek> expired token, lalala
<Laney> so, sounds like a bug on rabbitmq-server might be in order maybe
<Laney> would be nice if someone could try to reproduce that
<slangasek> Laney: bug for having dropped the queue?
<Laney> nod
<slangasek> right
<Laney> 'durable' queues (of which these are) are supposed to survive restarts of the broker
<slangasek> where can I see details about the upgrade that happened?
<Laney> unit rabbitmq-server/0
<slangasek> ah so this was unattended-upgrades, not IS
<slangasek> got it
<Laney> yeah
<Laney> IS-mandated unattended upgrade though ;)
<Laney> (it was a security update, so applying it is fair enough)
<Laney> seems like queues are filling up again - got a train to catch a flight to Montreal in ~12h, so I'm going to duck out
<Laney> see you on the other side
 * slangasek waves
<slangasek> /var/lib/rabbitmq/mnesia/rabbit@juju-prod-ues-proposed-migration-machine-1 looks like cruft (Sep 7 2016)
<slangasek> hngh, retry-autopkgtest-regressions does not order its requests very sensibly.  apparently we are going to completely fill the s390x queue before looking at any other archs. :P
<apw> slangasek, it has also dropped them all on the ubuntu queue rather than the original huge
<slangasek> apw: yeah, I know; retry-autopkgtest-regressions doesn't have a twiddle for that
<slangasek> apw: but also my carefactor is low because almost everything in p-m is currently blocked behind the perl migration anyway
<slangasek> apw: if you're going to tell me that I've broken linux migration I'll probably have a sad about that
<apw> slangasek, well i assume we are still queueing things, but there is no way now to get results for anything without perl clearing the queues, kernel included
<apw> i suspect we want those bulk retries to always go to huge, but as you say no twiddle
<slangasek> apw: I've just finished the queuing.  According to my browser's string count on http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_excuses.html there should be about 13k all told
<apw> slangasek, lets see how much of this mess clears over night i guess
<apw> slangasek, and i will look to add the --huge twiddle in the morning, as i think as that queue is clear i could use it
<slangasek> apw: based on the last perl upload, I'd guess only about a third :P
<slangasek> apw: quite so :)
<xnox> the most well tested perl ever.
<xnox> is there actually any point in perl adt tests? i thought it all runs unit tests, and all of them run during build too, no?
<slangasek> xnox: the first time around certainly caught a number of regressions w/ 5.26
<xnox> ok.
<slangasek> and there were still a handful of outstanding regressions that needed handled, which now I need to wait for a queue to see again what their status is
-queuebot:#ubuntu-release- New binary: libglvnd [ppc64el] (artful-proposed/universe) [0.2.999+git20170201-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libglvnd [s390x] (artful-proposed/universe) [0.2.999+git20170201-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libglvnd [amd64] (artful-proposed/universe) [0.2.999+git20170201-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libglvnd [i386] (artful-proposed/universe) [0.2.999+git20170201-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libglvnd [armhf] (artful-proposed/universe) [0.2.999+git20170201-4] (no packageset)
#ubuntu-release 2017-08-02
<xnox> slangasek, boot-smoke tests, after a few reboots detects that network-manager fails to start. thus i am suspecting the new network-manager is toast.
<xnox> Aug 02 00:59:46 normal nm-online[473]: Error: Could not create NMClient object: Timeout was reached
<xnox> bdmurray, is that similar to what whoopsie saw ^
<xnox> cause e.g. it looks like NetworkManager-wait-online.service is affected
<slangasek> xnox: was the new nm toast before?
<xnox> as per autopkgtest.ubuntu.com it did manage to pass with old systemd.
<slangasek> then what makes it toast now?
<xnox> as far as i can see, it is racy, and when NetworkManager.service claims the bus, it is not yet ready to take connections, thus NetworkManager-wait-online.service fails.
<xnox> i'm not sure if this is normal in unpriviledged container, but with network-manager installed, it boots degraded.
<xnox> also i'm not sure if this is a valid test at all, to install network-manager and expect the system to boot non-degraded. i guess it is, even if NM is not managing anything.
<xnox> also rtkit-daemon and systemd-hostnamed fail.
<bdmurray> xnox: no
-queuebot:#ubuntu-release- Unapproved: cockpit (zesty-backports/universe) [146-1~ubuntu17.04.1 => 147-1~ubuntu17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [146-1~ubuntu16.04.1 => 147-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [147-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (zesty-backports) [147-1~ubuntu17.04.1]
-queuebot:#ubuntu-release- New: accepted libglvnd [amd64] (artful-proposed) [0.2.999+git20170201-4]
-queuebot:#ubuntu-release- New: accepted libglvnd [i386] (artful-proposed) [0.2.999+git20170201-4]
-queuebot:#ubuntu-release- New: accepted libglvnd [s390x] (artful-proposed) [0.2.999+git20170201-4]
-queuebot:#ubuntu-release- New: accepted mythtv [arm64] (artful-proposed) [2:29.0+fixes.20170728.696806310a-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mythtv [i386] (artful-proposed) [2:29.0+fixes.20170728.696806310a-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mythtv [s390x] (artful-proposed) [2:29.0+fixes.20170728.696806310a-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libglvnd [armhf] (artful-proposed) [0.2.999+git20170201-4]
-queuebot:#ubuntu-release- New: accepted mythtv [amd64] (artful-proposed) [2:29.0+fixes.20170728.696806310a-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mythtv [ppc64el] (artful-proposed) [2:29.0+fixes.20170728.696806310a-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libglvnd [ppc64el] (artful-proposed) [0.2.999+git20170201-4]
-queuebot:#ubuntu-release- New: accepted mythtv [armhf] (artful-proposed) [2:29.0+fixes.20170728.696806310a-0ubuntu1]
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Xenial 16.04.3] has been marked as ready
<xnox> cyphermox, infinity - https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1708096 =(
<ubot5> Ubuntu bug 1708096 in The Ubuntu-power-systems project "Ubuntu16.04.3 Installation fails for JFS file system" [High,New]
<infinity> xnox: Might be the prep-finddev (or whatever it is) thing not being clever enough.  Probably has nothing to do with jfs.
<xnox> infinity, i have a deja vu that it was fixed before with similar bug title.
<infinity> xnox: Probably more likely to be the multi-disk setup.  But I'll give it a spin on a VM and see.
<xnox> e.g. https://bugs.launchpad.net/ubuntu/+source/partman-prep/+bug/1630017
<ubot5> Ubuntu bug 1630017 in partman-prep (Ubuntu) "Ubuntu 16.10 installation with root as JFS file system fails" [High,Incomplete]
<xnox> which is incomplete.
<infinity> "grub-install: error: unknown filesystem."
<infinity> Oh.
<infinity> Maybe our grub isn't built with jfs support?
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (xenial-proposed) [2:13.1.4-0ubuntu2]
<infinity> Not sure why we support installing to jfs anyway.  Even IBM spent year advocating xfs over jfs (and they WROTE jfs).
<infinity> s/year/years/
<cjwatson> jfs isn't in the signed image, but that shouldn't affect grub-install
<cjwatson> (nor POWER ...)
<cjwatson> AFAIK the jfs module is built unconditionally
<cjwatson> my bet would be an endianness bug
<cjwatson> or something like that
<infinity> The bug looks even more whacky in that second one.
<infinity> Things randomly dying and/or OOMing, but only with root on jfs.
<cjwatson> to debug GRUB, I'd suggest making a loop fs on a real system of the right arch, and playing around with grub-fstest
<cjwatson> (probably not actually endianness since ppc64el == x86 on that score)
<infinity> cjwatson: If it's the same as the second bug above, I don't think it's grub at all, grub's just a victim.
<infinity> Though, endianness bugs in an IBM-authored filesystem on ppc64el wouldn't be weird either.
<infinity> Since there's a whole lot of ppc64 == be that's needed to be cleaned up.
<cjwatson> yeah, I didn't look at all closely
<cjwatson> the GRUB JFS module wasn't written by IBM
<cjwatson> and it does appear to have at least some endian handling
<cjwatson> but yeah, could be a bug in the filesystem that grub-install is running from, and as you say it's just a victim
<sil2100> infinity: if anything, I'll be doing some test runs for mythubuntu in some moments, just mentioning so not to duplicate testing too muchy
<infinity> sil2100: Is "muchy" a Trump word?
<infinity> sil2100: I look forward to you test results, bigly.
<sil2100> If it is then Trump is strange
<sil2100> (almost done with the changelog as well)
<xnox> infinity, ok, i shall request logs and if it is OOMing for the report, they really should fix that.
<infinity> xnox: I think OOMing was a suspicion of cyphermox's, but perhaps not the actual case.
<infinity> xnox: Still, the original bug report lacks anyone actually finding a cause.
<xnox> ok, but we do need logs from the installer. thus it is fair to request installer logs in the new bug report, and mark it incomplete.
<xnox> cause we do need to see which system it is, how much memory it has, if there are OOM in syslog or not.
<xnox> and the new one lacks details too.
<infinity> The new one has logs.
<infinity> win 18
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (xenial-proposed) [0.7.9-233-ge586fe35-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (xenial-proposed) [1:16.04.8]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (trusty-proposed) [1:0.196.24]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (zesty-proposed) [1:17.04.5]
-queuebot:#ubuntu-release- Unapproved: accepted libapache2-mod-auth-pgsql [source] (xenial-proposed) [2.0.3-6.1ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted libapache2-mod-auth-pgsql [source] (trusty-proposed) [2.0.3-6ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted gtk+2.0 [source] (zesty-proposed) [2.24.31-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted libapache2-mod-auth-pgsql [source] (zesty-proposed) [2.0.3-6.1ubuntu0.17.04.1]
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Xenial 16.04.3] has been marked as ready
<sergiusens> apw: hey, ubuntu-image adt tests are failing on the snapcraft upload, which are not related to the snapcraft upload, sil2100 just told me there is an ubuntu-image upload which is unreviewed still which would fix it, since I fancy green results, is there a change you can accept it into -proposed? (1.1 has the fix)
<sil2100> Yeah, it seems that in the CVE quick-fix we made we missed adding fakeroot to the test deps
<sil2100> The new 1.1 that's in the queue should be good for everything
<sil2100> There's already a 1.1 in -proposed but it's busted because of other reasons ;p
<sil2100> So the re-upload is meant to fix the world
<cyphermox> infinity: xnox: OOMing as the cause of JFS fails? I don't remember enough
<cyphermox> oh, I see
<sil2100> apw, sergiusens: the ubuntu-image in the queue should be rather straightforward to review as 1.1 was already been reviewed and accepted once, this is the same changes + an autopkgtest skipped
<cyphermox> cjwatson: IIRC, not endianness either, IIRC; I was also able to install with JFS on ppc64el; as I recall it only crashed for the reporter, and possibly only when multipath is in play
<cyphermox> infinity: I think this matches what you saw? ^
<clivejo> how often is artful sync'ed with debian?
<sil2100> infinity: oh, didn't know security could still push new packages to -updates/-security during the freeze - or is the webkit2gtk upload release-critical?
<apw> sil2100, security has a life of its very own
<infinity> sil2100: Yeah, they never pay attention to my freezes.
<infinity> sil2100: But we'll just pretend that didn't happen, unless there's a reason to respin.
<sil2100> ;p
<cjwatson> clivejo: every six hours
<rbasak> arges: o/
<rbasak> arges: I was about to start looking at SRUs. Realised I was still marked away.
-queuebot:#ubuntu-release- Unapproved: accepted gtk+2.0 [source] (xenial-proposed) [2.24.30-1ubuntu1.16.04.2]
<rbasak> arges: shall I leave it to you for a while?
<clivejo> do new packages go into Ubuntu new queue or bypass it?
<cjwatson> clivejo: auto-synced new source packages bypass the new queue; the resulting binary packages require a semi-automatic rubber stamp
<clivejo> cool :)
-queuebot:#ubuntu-release- New binary: syslog-ng [ppc64el] (artful-proposed/universe) [3.10.1-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: syslog-ng [s390x] (artful-proposed/universe) [3.10.1-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: syslog-ng [amd64] (artful-proposed/universe) [3.10.1-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: syslog-ng [i386] (artful-proposed/universe) [3.10.1-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: syslog-ng [arm64] (artful-proposed/universe) [3.10.1-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: syslog-ng [armhf] (artful-proposed/universe) [3.10.1-3ubuntu1] (no packageset)
<slangasek> sil2100: lp:~sil2100/ubuntu-archive-tools/plus-sign-review, you made this code change locally and empirically tested that it fixed sru-review for gtk+2.0 (which is now no longer in the queue)?
<sil2100> slangasek: yes, used it to review it, tried a few others in the queue to see if the debdiffs are downloadable - works
<sil2100> I don't see a reason for the quote() there, but maybe I don't know the full story
<slangasek> sil2100: yeah, '+' is the only legal char in a package name that *might* be url encoded
<slangasek> sil2100: merged, thanks
<sil2100> slangasek: thanks for the review!
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (zesty-proposed/main) [1:0.4.22 => 1:0.4.22.1] (desktop-core, ubuntu-server)
<cjwatson> sil2100,slangasek: I have filled in the archaeology that you were missing :)
<cjwatson> (no changes required, you just may be interested)
<slangasek> cjwatson: righty-o
<cjwatson> some day I must get my job title changed to Programmer-Archaeologist
<sil2100> ;)
<slangasek> Raiders of the Lost Archive
<bdmurray> arges: Can you update your version of ubuntu-archive-tools to get the changes to sru-review?
-queuebot:#ubuntu-release- New binary: libjwt [ppc64el] (artful-proposed/universe) [1.8.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libjwt [s390x] (artful-proposed/universe) [1.8.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dtksettings [s390x] (artful-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dtksettings [amd64] (artful-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libjwt [amd64] (artful-proposed/universe) [1.8.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-coloredlogs [amd64] (artful-proposed/universe) [7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-dropbox [amd64] (artful-proposed/universe) [8.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mathgl [ppc64el] (artful-proposed/universe) [2.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libjwt [i386] (artful-proposed/universe) [1.8.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mathgl [s390x] (artful-proposed/universe) [2.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dtksettings [arm64] (artful-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libjwt [armhf] (artful-proposed/universe) [1.8.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libjwt [arm64] (artful-proposed/universe) [1.8.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mathgl [armhf] (artful-proposed/universe) [2.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mathgl [amd64] (artful-proposed/universe) [2.4.1-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pollinate (xenial-proposed/main) [4.23-0ubuntu1~16.04.1 => 4.25-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: mathgl [i386] (artful-proposed/universe) [2.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mathgl [arm64] (artful-proposed/universe) [2.4.1-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: pollinate (trusty-proposed/main) [4.23-0ubuntu1~14.04.2 => 4.25-0ubuntu1~14.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: gcc-7-cross-ports [i386] (artful-proposed/main) [3ubuntu2] (ubuntu-desktop)
<slangasek> "only" 1500 autopkgtests in the queue on amd64
<apw> slangasek, just over 8.6k en-toto
<slangasek> that's good progress, hey; I estimated things'd be clogged until Friday
-queuebot:#ubuntu-release- New binary: gcc-7-cross-ports [amd64] (artful-proposed/main) [3ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted dtksettings [amd64] (artful-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted dtksettings [s390x] (artful-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted libjwt [arm64] (artful-proposed) [1.8.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libjwt [i386] (artful-proposed) [1.8.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libjwt [s390x] (artful-proposed) [1.8.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted mathgl [arm64] (artful-proposed) [2.4.1-2]
-queuebot:#ubuntu-release- New: accepted mathgl [i386] (artful-proposed) [2.4.1-2]
-queuebot:#ubuntu-release- New: accepted mathgl [s390x] (artful-proposed) [2.4.1-2]
-queuebot:#ubuntu-release- New: accepted python-dropbox [amd64] (artful-proposed) [8.0.0-1]
-queuebot:#ubuntu-release- New: accepted dtksettings [arm64] (artful-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted libjwt [armhf] (artful-proposed) [1.8.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted mathgl [amd64] (artful-proposed) [2.4.1-2]
-queuebot:#ubuntu-release- New: accepted mathgl [ppc64el] (artful-proposed) [2.4.1-2]
-queuebot:#ubuntu-release- New: accepted libjwt [amd64] (artful-proposed) [1.8.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted mathgl [armhf] (artful-proposed) [2.4.1-2]
-queuebot:#ubuntu-release- New: accepted libjwt [ppc64el] (artful-proposed) [1.8.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted python-coloredlogs [amd64] (artful-proposed) [7.1-1]
<xnox> somehow my all proposed test is installing new systemd, but old udev.
-queuebot:#ubuntu-release- New binary: node-libs-browser [amd64] (artful-proposed/none) [2.0.0-1] (no packageset)
<slangasek> heh
<xnox> slangasek, systemd and udev do not depend on each other, although both are priority important. In debian, udev is statically linked against libsystemd-private instead of dynamically to avoid a hard-dep between udev and systemd.
<xnox> is it ok to dynamically link udev against libsystemd-private, and thus make a hard dep between bin:udev and bin:systemd? I believe bin:libudev1 should be unaffected by the change.
<xnox> also, i think I need to change debian/tests/control to include udev everywhere. As testing new systemd with old udev makes no sense to me.
<xnox> also i do not believe the two are truelly independant.
<xnox> so the only test that failed for me on amd64 is boot-and-services which said that udevamd version is wrong 233 vs 234.
<xnox> i ran the tests as:
<xnox> autopkgtest -B systemd --apt-pocket=proposed --shell --shell-fail -ddd -- qemu ./adt-artful-amd64-cloud.img
<xnox> hmm... missed --apt-upgrade
<slangasek> xnox: I don't understand why you would need to do this when they are from the same source package and should be affected by the same apt pin
<slangasek> is udev oddly blacklisted in the autopkgtest infra?
<xnox> no idea. but, none of the debian/tests/control tests specify udev at all, only systemd. thus in theory we are not testing udev at all. thus all the apt mark pins stuff doesn't specify anything for udev.
<slangasek> a
<slangasek> ah
<xnox> usually one does @ thing which means all built binaries.
<xnox> i am thinking it is prudent to put udev into all the paragraphs in debian/tests/control, in addition to systemd.
<slangasek> well, why does having the mismatch cause things to fail?
<slangasek> if it causes things to fail because you actually are testing udev, then I guess you should depend on udev
<xnox> udevadm --version reports wrong thing
<xnox> there is test to make sure that udevadm --version matches the version specified in systemd.pc pkg-config file.
<slangasek> right, then the test should dep on udev :)
 * xnox wonders if we ever managed to migrate new major systemd version without an override
<xnox> also it uses nested kvm =/
<xnox> however, i do have green on ppc64el and s390x now =) so all arches i care about are perfect =)
<nacc> xnox: i think i figured out the open-iscsi failure in a-p, there's a test to see if iscsid has started, and it will fail with the new systemd constraints on directories existing indicating iscsi is actually in use. Seems reasonable to just drop that test, right? I'm asking smoser about it as well, to be sure
<mwhudson> is that because the tests skip on those arches?
<xnox> but about shared link stuff, typically we do have both systemd and udev running, and linking libsystemd-private dynamically may reduce the size of udev binary. I shall check that.
<xnox> nacc, which tests are these? the ones in src:open-iscsi ? and yes makes sense to drop it.
<xnox> nacc, or the tests should setup the test bed, to make iscsi daemon _in_use_ and check that it is autostarted on reboot.
<xnox> no?
 * xnox ponders if that is at all possible to do within a scope of a single machine.
<xnox> export and mount something on the same host?!
<nacc> xnox: yeah, dep8 in open-iscsi
<nacc> xnox: yeah, it uses nested kvm, i think, to do that
<nacc> xnox: so we could defer the test until the iscsi disks are setup and then see if in the nested it is running/startable/stoppable
#ubuntu-release 2017-08-03
<nacc> xnox: i'll see if that's doable and if not just disable the test for now so it can propogate
<xnox> yeah, and there is reboot command support in dep8 as well, if you want to like 1) [ -z "$ADT_REBOOT_MARK" ] && setup disks, and then later [ -n "$ADT_REBOOT_MARK" ] && check that daemon is autostarted and running.
<xnox> with reboot between the two.
<nacc> xnox: thanks, that's handy
<xnox> nacc, we can override the test results for open-iscsi to propagate, but that's best to have a fixed test....
<nacc> xnox: ack, i'll try and get it fixed by EOW
<xnox> mwhudson, there are now smart ExecStartPre= shell script in the systemd unit to bail out when not-needed / setup
<xnox> slangasek, https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1708313
<ubot5> Ubuntu bug 1708313 in systemd (Ubuntu) "PrivateNetwork=yes fails in lxc1 armhf on arm64 kernel" [Undecided,New]
<xnox> not I ?! =)
<sergiusens> slangasek: long shot, but can I get snapcraft 2.33 into xenial-updates and zesty-updates? the armhf test failure for snapcraft proper is just timeouts (ran twice already, squid.internal timeout in different tests) and the ubuntu-image ones are test errors in ubuntu-image proper (sil mentioned those are fixed in 1.1)
<slangasek> sergiusens: xenial-updates is currently frozen for point release; snapcraft seems safe since it shouldn't impact images but I'll just highlight infinity to double-check
<slangasek> checking ubuntu-image; I'm going to re-test with -proposed u-i + snapcraft so it's clear from the log
<slangasek> xnox: why should PrivateNetwork fail there?  it's just containers
<sergiusens> thanks slangasek
<xnox> slangasek, it is a good point. but also i don't know how our armhf infra is setup.
<xnox> slangasek, is it priviledged or unpriviledged lxc1? what is the host? are there any config overrides that punch things through?
<slangasek> hmm
<xnox> at the moment i setup straight up lxc1 artufl armhf container on an artful arm64 host
<slangasek> all good questions
<xnox> but i suspect the host may not be xenial, and i'm debugging obsolete software not matching production.
<slangasek> "may not be xenial" - I would expect it is. don't the logs report the kernel version?
<xnox> the logs report armhf kernel....
<slangasek> the armhfness is a lie
<xnox> testing everything in lxc1 on an old kernel/host with new binaries inside makes a lot of sense when one is developing that for the arm64 android phones.
<slangasek> I don't know if it fakes the version?
 * xnox wants armhf testing to move to lxd
 * xnox wants arm64 lxd testing added, given we do have arm64 hosts hooked up in adt
 * xnox wants arm64 kvm testing added - but this might be trickier to do
<xnox> slangasek, given we are not doing as much phone testing, i am suspecting our armhf and arm64 testing went downhill.
<slangasek> I haven't seen evidence of this in general
<slangasek> arm64 will be VMs, not containers, when the RTs finish
<xnox> ok.
<xnox> moving armhf from lxc to lxd?
<xnox> that should be easy, given how reliable s390x lxd is.
<xnox> no?
<slangasek> that part I don't know
<slangasek> xnox: on the autopkgtest side, the infra believes it is using lxd for armhf, not lxc.  kernel is 4.4 on xenial.
<xnox> slangasek, how old/new lxd? from release and/or backports?
<slangasek> xnox: 2.0.9
<slangasek> which I guess means we're a little behind
<xnox> slangasek, so trusty?
<slangasek> xnox: no, xenial-updates-1
<xnox> ah, ok.
-queuebot:#ubuntu-release- New: accepted gcc-7-cross-ports [amd64] (artful-proposed) [3ubuntu2]
-queuebot:#ubuntu-release- New: accepted node-libs-browser [amd64] (artful-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted syslog-ng [arm64] (artful-proposed) [3.10.1-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted syslog-ng [i386] (artful-proposed) [3.10.1-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted syslog-ng [s390x] (artful-proposed) [3.10.1-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-7-cross-ports [i386] (artful-proposed) [3ubuntu2]
-queuebot:#ubuntu-release- New: accepted syslog-ng [armhf] (artful-proposed) [3.10.1-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted syslog-ng [amd64] (artful-proposed) [3.10.1-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted syslog-ng [ppc64el] (artful-proposed) [3.10.1-3ubuntu1]
<xnox> slangasek, on artful host, launching artful armhf lxd container says armv8l in uname -a
<xnox> slangasek, about stalled amd64/i386 systemd adt tests - can i get a juju log? or like nova console log of the instances running the test?
<xnox> or ssh backdoor into them? i think pitti did open up a connection into those machines by hand before.
<xnox> running adt tests here on xenial host, with qemu runner, using artful cloud-image as base - passes.
<xnox> did that with amd64, todo with i386.
<xnox> ..
<xnox> i just got hashsum missmatch in ftpmaster.internal
<xnox> http://paste.ubuntu.com/25230244/
<xnox> this is wow.
<slangasek> xnox: sorry, it's dinner time here.  I can look at this later in the evening
<xnox> i should sleep too
 * xnox goes to drink some tea to calm down
<infinity> xnox: Our buildds and autopkgtest hosts are booted with 'compat_uts_machine=armv7l' on the cmdline.
 * apw had forgotten that thing exists
<infinity> apw: If we could come up with a sane way to boot armv7 images in scalingstack, we could ditch the silly hack.
<infinity> Maybe I should find some "free time" (ha ha ha) for that.
 * apw giggles at infinity
<infinity> jbicha: ubuntu-gnome/xenial seems to have 0 testing so far.
<stgraber> xnox: hmm, uname -m not showing the right personality is weird, we don't see that behavior on x86
<stgraber> ah, just found apw's kernel patch. Feels pretty weird that linux32 on aarch64 otherwise gives you the exact same as linux64...
<jbicha> infinity: sorry, I'll take a look in the morning
<apw> stgraber, i thought it gave you something else, just the 32bit form of the hardware, not the form our 32bit images are optimised for
<stgraber> oh, it does indeed
<stgraber> you get aarch64 for 64bit and armv8l for 32bit
<stgraber> root@1ss-arm64:~# uname -a
<stgraber> Linux 1ss-arm64 4.4.0-75-generic #96-Ubuntu SMP Thu Apr 20 09:56:48 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
<stgraber> root@1ss-arm64:~# setarch linux32 -- uname -a
<stgraber> Linux 1ss-arm64 4.4.0-75-generic #96-Ubuntu SMP Thu Apr 20 09:56:48 UTC 2017 armv8l armv8l armv8l GNU/Linux
<apw> right, just unfortuantly we are armv7 optimised
<infinity> Has less to do with optimisation.
<apw> s/optimised/targetted/
<infinity> And more to do with Stupid Software doing Stupid Things when building and seeing a uname it doesn't know.
<stgraber> it can get even more confusing though :)
<infinity> This is why i686 "stalled" on i686 too.
<infinity> Despite us now being up to i786 (or i868 for Core, I've lost track) according to Intel.
<stgraber> root@blah:~# uname -a
<stgraber> Linux blah 4.11.0-10-generic #15-Ubuntu SMP Thu Jun 29 15:07:09 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
<infinity> 886...
<stgraber> root@blah:~# setarch linux32 -- uname -a
<stgraber> Linux blah 4.11.0-10-generic #15-Ubuntu SMP Thu Jun 29 15:07:09 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
<stgraber> that's on an arm64 system that doesn't support the 32bit personality
<infinity> stgraber: Right, and that's correct.
<infinity> Well, more correct would be setarch bubbling up a "that personality no exist" error, but whatever.
<stgraber> yeah, I'd expect an error :)
<stgraber> oh, the kernel does do the right thing, it's just setarch being useless :)
<stgraber> personality(PER_LINUX32)                = -1 EINVAL (Invalid argument)
<infinity> Right.
<infinity> I still think it was a mistake for ARM to not require v7 compat in v8, but oh well.
<infinity> It's an even larger headache than v7 not requiring NEON.
<infinity> Mistakes, though, why learn from them?
<slangasek> sergiusens: ubuntu-image+snapcraft looking a bit better now in zesty, two passes, two xfails, and one fail (ppc64el)
<slangasek> infinity: how frozen is xenial-updates, could snapcraft be released or no?
<slangasek> (non-image-affecting)
<infinity> slangasek: non-image-affecting is fine.
<xnox> infinity, about that. to get "armhf" images booting in scaling stack, all we need is a regular arm64-uefi-firmware image with arm64 kernel and armhf userspace and compat_uts_machine=armv7l. slap together and done. we will still not be able to test armhf kernels in adt, but at least we will gain all the isolation-machine tests
 * xnox assumes arm64 images are uefi images in scaling stack. if not mimic whatever arm64 images have for a bootloader.
<xnox> basically use multiarch technology and tools
<wgrant> xnox, infinity: You can also construct an armhf image that boots an armhf kernel directly, without using UEFI, but it's a bit messy.
<slangasek> yes, arm64 images are uefi
<wgrant> Last time I tried it it required using images that masqueraded as AMIs and AKIs, so I got ovmf working instead, but direct kernel boot does work on bos01.
<infinity> xnox: My point wasn't to boot armhf-on-arm64, I want armhf-on-armhf.  But I'd rather drop armhf entirely, given a perfect world.
<xnox> infinity, sure. armhf-on-arm64 kvm is better than lxd for adt testing. armhf-on-armhf does sound backwards.
<xnox> to kill armhf, do we need an armv8l port then? or whatever the tag is?
<xnox> also what is the point of i386 if joules edison and galileo got axed, and even that were 64-bit capable.
-queuebot:#ubuntu-release- New binary: behave [amd64] (artful-proposed/universe) [1.2.5-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- New binary: te923con [i386] (artful-proposed/universe) [0.6.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: te923con [s390x] (artful-proposed/universe) [0.6.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: te923con [ppc64el] (artful-proposed/universe) [0.6.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: te923con [amd64] (artful-proposed/universe) [0.6.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: te923con [arm64] (artful-proposed/universe) [0.6.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: te923con [armhf] (artful-proposed/universe) [0.6.1-1ubuntu1] (no packageset)
<sil2100> infinity: let me pick up netboot amd64 images now for some testing
<infinity> sil2100: Not super concerned about netboot testing, it's not really coupled to the ISOs and point release (despite evidence to the contrary).
<sil2100> infinity: ok, I'll move to -GNOME then
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Xenial 16.04.3] has been marked as ready
<sil2100> Ubuntu GNOME looking fine on amd64, giving a quick spin of i386 now
<LocutusOfBorg> hello, not sure if tsimonq2 already requested that, but please force badtest
<LocutusOfBorg> fpc/3.0.2+dfsg-2 on amd64 (zesty)
<LocutusOfBorg> libreoffice/1:5.3.1-0ubuntu2 i386 (zesty=
<LocutusOfBorg> we tried them with themself as trigger
<LocutusOfBorg> and the failed
<tsimonq2> LocutusOfBorg: I didn't say something yet, thank you :)
<infinity> LocutusOfBorg: libreoffice failing might be a kernel issue.
<infinity> apw: There was some talk that those fixes for the fixes for the fixes still didn't fix libreoffice, right?
<tsimonq2> infinity: But it's not a gtk+2.0 issue, correct? (that's what triggered the test)
<infinity> tsimonq2: Sure, but force-badtest would also be a lie.
<infinity> tsimonq2: You can say "this shouldn't hold up gtk" without saying "please ignore the test forever".
<tsimonq2> infinity: "this shouldn't hold up gtk" :P
<LocutusOfBorg> infinity, yes, I agree, I'm following the Debian bug too
<tsimonq2> infinity: Regardless, the point in asking is to make sure that the SRU can migrate properly.
<LocutusOfBorg> ok, well, so ignore it only once is the correct request? I agree this shouldn't be forced forever
<LocutusOfBorg> I see libreoffice blacklisted on s390x not sure what does it mean
<tsimonq2> infinity (cc apw): This isn't just a Zesty issue from what I can tell, it seems to be a Xenial issue as well.
<infinity> LocutusOfBorg: Nah, just informing an SRU team member that it's not a gtk regression should be fine.  I mean, we'll mentally ignore it, but no need to commit anything to infra, since britney doesn't drive migrations in SRUs... yet.
<infinity> tsimonq2: And yes, we know.
<LocutusOfBorg> oh ok, so they are not blocking? really nice!
<tsimonq2> infinity: Alright, just covering my bases. :)
<tsimonq2> +1 LocutusOfBorg
<LocutusOfBorg> I mean, not so nice but meh
<tsimonq2> Yeah, I don't know about nice but maybe convenient is the better word. :P
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base powerpc [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Xenial 16.04.3] has been marked as ready
<sil2100> infinity: GNOME i386 looks good as well, marked as so some minutes ago
<infinity> sil2100: Shiny.
<sil2100> infinity: anything else needs testing? I don't see anything that's not-touched besides netboot
<infinity> sil2100: I think we're getting down to just paperwork and me asking computers to do things that take a very long time.
-queuebot:#ubuntu-release- New binary: budgie-wallpapers [amd64] (artful-proposed/universe) [17.10] (no packageset)
<sil2100> infinity: sweet, the changes for .3 look ok or should I work some more on those?
<infinity> sil2100: I'll look in a bit.
<infinity> sil2100: But if it looks kinda like a list of bugs, I'll probably not have complaints.
<infinity> sil2100: Looks reasonable to me.
<sil2100> infinity: if there's anything I can help, just poke! We'll be going out for lunch in a moment but I'll be back soonish
-queuebot:#ubuntu-release- New binary: ganeti [i386] (artful-proposed/universe) [2.15.2-10] (no packageset)
-queuebot:#ubuntu-release- New binary: ganeti [ppc64el] (artful-proposed/universe) [2.15.2-10] (no packageset)
-queuebot:#ubuntu-release- New binary: ganeti [amd64] (artful-proposed/universe) [2.15.2-10] (no packageset)
-queuebot:#ubuntu-release- New binary: ganeti [s390x] (artful-proposed/universe) [2.15.2-10] (no packageset)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Xenial 16.04.3] has been marked as ready
<apw> sil2100, do you want these ubuntu-image things in the queue accpted over what is in -proposed ?
-queuebot:#ubuntu-release- New binary: ganeti [arm64] (artful-proposed/universe) [2.15.2-10] (no packageset)
-queuebot:#ubuntu-release- New: accepted behave [amd64] (artful-proposed) [1.2.5-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted ganeti [amd64] (artful-proposed) [2.15.2-10]
-queuebot:#ubuntu-release- New: accepted ganeti [i386] (artful-proposed) [2.15.2-10]
-queuebot:#ubuntu-release- New: accepted ganeti [s390x] (artful-proposed) [2.15.2-10]
-queuebot:#ubuntu-release- New: accepted te923con [arm64] (artful-proposed) [0.6.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted te923con [i386] (artful-proposed) [0.6.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted te923con [s390x] (artful-proposed) [0.6.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted budgie-wallpapers [amd64] (artful-proposed) [17.10]
-queuebot:#ubuntu-release- New: accepted ganeti [ppc64el] (artful-proposed) [2.15.2-10]
-queuebot:#ubuntu-release- New: accepted te923con [armhf] (artful-proposed) [0.6.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted ganeti [arm64] (artful-proposed) [2.15.2-10]
-queuebot:#ubuntu-release- New: accepted te923con [ppc64el] (artful-proposed) [0.6.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted te923con [amd64] (artful-proposed) [0.6.1-1ubuntu1]
<doko> looking at gcc-7-cross-ports in update_excuses.html: why is the ppc64el build listed as missing
<doko> and the cross compilers seem to be installable as well
<infinity> doko: The uninstallable stuff might be component mismatches.  Not sure about the ppc64el thing.
<doko> ahh, yes, demoting
<doko> gcc-7-cross-ports is kept in main because of the need of powerpc on ppc64el
<infinity> doko: Erm, the ppc64el thing is because you didn't bump versions.
<infinity> Why the second one didn't fail to upload is a mystery I'd rather not think about.
<doko> hmm, I removed the binaries before uploading the second one ...
<infinity> That would be why it didn't fail to upload.
<infinity> Also, ick.
<doko> anyway, doing the 7.2 release candidate today
<infinity> doko: Binaries (and sources) should never, ever, ever re-use versions in the archive.  Things go nutty.
<infinity> Totally an LP bug that it even let that happen.
<infinity> cjwatson: ^
<cjwatson> I'm pretty surprised that was allowed, certainly.  Please file.
<cjwatson> And don't pull that sort of binary-removal stunt again.
<infinity> doko: Yes.  Pretty please don't remove a file because it conflicts with another you want with different contents. :P
<infinity> doko: Files in the history of an archive must be unique.
<cjwatson> I guess it's possible we only explicitly check that for sources.
<doko> infinity: ack
<infinity> cjwatson: Things fail to upload all the time for that reason.  Or does it maybe only check published binaries, rather than all of history?
<cjwatson> infinity: Do you happen to remember an example?
<infinity> I suspect doko's own package is an example (though, not sure how far back I'd have to go to find it).
<infinity> But yes, we get builds failing to upload due to binary version conflicts (and also version downgrades).
<cjwatson> Version conflicts are different.
<infinity> Different than... A version conflict?
<cjwatson> I'm not saying there are no checks on binary uploads, just that I suspect the same-version-different-contents check is absent.
<infinity> We may be saying the same thing, sort of?
<infinity> I mean, a build with a version already published will reject.  Unless it's a copy (thus same contents).  But a build with a version that's historically been used but not currently published will, apparently, accept.
<infinity> Or, that seems to describe what I've seen.
<cjwatson> Does it actually reject, or just crash during publication?
<cjwatson> I see plenty of "Version older than that in the archive" rejections in recent history, but nothing that's obviously a version-conflict rejection.
<infinity> I think doko's gcc-cross packages have rejected in the past for this same reason.
<infinity> Cause they really should encode more version info than they do.
<infinity> It's entirely possible this one rejected and he did the removal and then retried the build. :P
<cjwatson> Ah, https://launchpad.net/ubuntu/+source/gcc-6-cross-ports/20ubuntu4/+build/12555755 is an example.
<infinity> Yup.
<cjwatson> Missed it because it's done in lp.soyuz.model.queue:PackageUpload rather than in archiveuploader.
<cjwatson> So right, that's basically a last-ditch check against stuff that hasn't been removed.
<cjwatson> Might be interesting to see what would break if we just removed the "AND bpph.dateremoved IS NULL" condition from that query.
<cjwatson> Possibly a performance disaster, not sure.
<cjwatson> So yeah, removal successfully hammered the upload through to the point where it failed later.  And it might have failed even more disastrously depending on how it interacted with https://bugs.launchpad.net/launchpad/+bug/238826 ..
<ubot5> Ubuntu bug 238826 in Launchpad itself "Death-row misbehave on binary collision" [Low,Triaged]
<infinity> cjwatson: It's almost certainly failed pretty hard already, because a-f cache.
<infinity> (as in, the sums in Packages are probably for the old files)
<cjwatson> Quite possibly.
<infinity> Because a-f makes the entirely reasonable assumption that archive members are unique. :P
<cjwatson> doko: Is this a thing you've done in the past?  Because if so we may need to audit the archive.
<doko> cjwatson: no, afaicr. in the past we had failing builds on one or two archs, whith other archs succeeding, and then the version skew for the binaries
<doko> for the next upload
<doko> the skew goes away with the next gcc-7 upload, and all cross builds succeeding
<cjwatson> I don't understand why that would result in version skew.  Wouldn't you bump all the versions in sync?
<doko> no, it's looking at the binaries found in the archive
<doko> if I hardcode that, then I usually forget to bump the number for a new upload :/
<infinity> doko: It really needs to tack on the version of the gcc-cross package as well, so it remains unique per build.
<cjwatson> Ah, so retrying -cross-ports with a different base toolchain or something
<infinity> doko: As in, the "cross1" at the end could be "cross20ubuntu5" or something for gcc-6-cross-ports_20ubuntu5
<doko> infinity: yeah, but then you had a version number like -12ubuntu1cross5ubuntu2 ...
<doko> ugly
<infinity> doko: Shorten "Ubuntu" to "u" and it's not the worst.
<infinity> I mean, they're ugly regardless. :P
<infinity> And shorten "cross" to "c" or "x"
<infinity> -12ubuntu1x5u2
<apw> and it looks like a disk name in solaris
<infinity> In Debian, it's be a nice short -12x5
<infinity> Hahaha.
<sil2100> apw: yes :)
<xnox> what is solaris?
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Xenial 16.04.3] has been marked as ready
<doko> the kiosk seed is pulling in qtubuntu. is this expected?
<doko> http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<jbicha> doko: looks like yes: https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.artful
<doko> jbicha: but all the -cpp packages are unmaintained, aren't they?
<infinity> I was under the impression pretty much that whole dep tree is unmaintained.
<doko> xnox: ^^^
<xnox> doko, yes kiosk seed pulling in qtubuntu is expected.
<xnox> and alan_g is on the hook to minimise deps.
<xnox> (alan_g and co)
<xnox> they have requested that in a bug report, mentioned in the seed text.
<alan_g> Saviq: FYI ^^
<xnox> the graph is nice: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg this may be a useful guide on as to what to drop.
<Saviq> we're cutting off at platform-api
<xnox> whoop whoop =)
<Saviq> as in, we won't depend on that, soon
<Saviq> so that graph will look much nicer
<xnox> doko, infinity ^
<Saviq> the other fruit is content-hub, which we need to cut off in qtubuntu, too, and are already on it
<doko> looks like the debian perl team is busy updating everything ...
<xnox> doko, helpful. stop the importer?! =)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop amd64 [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop i386 [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Xenial 16.04.3] has been marked as ready
-queuebot:#ubuntu-release- Builds: 39 entries have been added, updated or disabled
-queuebot:#ubuntu-release- New binary: fwupd [ppc64el] (artful-proposed/main) [0.9.6-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: fwupd [amd64] (artful-proposed/main) [0.9.6-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: fwupd [s390x] (artful-proposed/main) [0.9.6-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: fwupd [i386] (artful-proposed/main) [0.9.6-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: fwupd [arm64] (artful-proposed/main) [0.9.6-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: fwupd [armhf] (artful-proposed/main) [0.9.6-0ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- New binary: linux [s390x] (artful-proposed/main) [4.11.0-13.19] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (vivid-proposed/main) [3.19.0-90.98] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-30.34] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-30.34]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (vivid-proposed) [3.19.0-90.98]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (xenial-proposed/main) [4.11.0-13.19~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-89.112] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-89.112~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.10.0-30.34~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (xenial-proposed) [4.11.0-13.19~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-89.112]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.10.0-30.34~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-89.112~14.04.1]
* infinity changed the topic of #ubuntu-release to: Released: Xenial 16.04.3, Zesty 17.04 | Archive: open | Artful Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
-queuebot:#ubuntu-release- New binary: linux [ppc64el] (artful-proposed/main) [4.11.0-13.19] (core, kernel)
-queuebot:#ubuntu-release- New source: mozjs52 (artful-proposed/primary) [52.2.1-1~git1]
<teward> is there a reason https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1595096 has just sat on the sponsoring list for eternity and never been looked at?
<ubot5> Ubuntu bug 1595096 in postfix (Ubuntu Xenial) "cannot create multi postfix instance by postmulti command" [Medium,In progress]
<teward> in queue as of 3/25/2017
<teward> jgrimm: ^ cc
<nacc> teward: not especially
<nacc> teward: i think the sponsorship queue is a bit behind for server
<nacc> i believe i have a pilot session next week
<teward> nacc: "behind" I think is an understatement - this is 5 months since last activity... just saying.
<teward> (and this is breaking my experimenting with postfix heh)
<teward> i'll do a power user hack for now and compile an updated package in a PPA, but...
-queuebot:#ubuntu-release- New binary: linux [i386] (artful-proposed/main) [4.11.0-13.19] (core, kernel)
<teward> (at least NGINX updates get handled real quickly... oh wait, that's my uploads... nevermind :P)
<nacc> teward: feel free to bump in the bug and we should see it in the triage rota
<teward> bumped :p
<nacc> teward: thanks
<nacc> teward: i'm guessing hte debdiff probably needs updating too, but that's ok
-queuebot:#ubuntu-release- New binary: linux [arm64] (artful-proposed/main) [4.11.0-13.19] (core, kernel)
<teward> nacc: indeed, but I'm happy to do that if needed.
<teward> because i want this working :P
<nacc> teward: :)
<jgrimm> teward, nacc.  as far i know its ready to go, had just been waiting for sponsors to get around to it
<nacc> jgrimm: +1 agreed
<teward> which is "never" if you don't prod them every so often :P
<jgrimm> template including how to test for sponsor so should be easy enough nacc. let me know if you have questions
<teward> 5 months is infinite lagtime.
<jgrimm> teward, :)
<teward> (in the IT world anyways)
<nacc> jgrimm: yep, i saw that
<teward> jgrimm: I had a habit before I got PPU rights - I always bothered sponsors every week until they uploaded my things, esp. if it's critical.  Now for nginx, I just upload and wait for the SRU teams :P
-queuebot:#ubuntu-release- New binary: linux [amd64] (artful-proposed/main) [4.11.0-13.19] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: nvme-cli (xenial-proposed/universe) [0.5-1ubuntu0.1 => 0.5-1ubuntu0.2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux [armhf] (artful-proposed/main) [4.11.0-13.19] (core, kernel)
-queuebot:#ubuntu-release- New binary: git-lfs [ppc64el] (artful-proposed/none) [2.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-approvals-go-approval-tests [amd64] (artful-proposed/none) [0.0~git20170712.0.c1e747e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-chzyer-readline [amd64] (artful-proposed/none) [1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lua-mode [amd64] (artful-proposed/universe) [20151025-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-aliyun-aliyun-oss-go-sdk [amd64] (artful-proposed/none) [1.5.0+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-hashicorp-go-rootcerts [amd64] (artful-proposed/none) [0.0~git20160503.0.6bb64b3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-cheekybits-is [amd64] (artful-proposed/none) [0.0~git20150225.0.68e9c06-1] (no packageset)
-queuebot:#ubuntu-release- New binary: git-lfs [amd64] (artful-proposed/none) [2.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: git-lfs [s390x] (artful-proposed/none) [2.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: inflection [amd64] (artful-proposed/none) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: org-mode [amd64] (artful-proposed/universe) [9.0.9+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: git-lfs [i386] (artful-proposed/none) [2.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: more-itertools [amd64] (artful-proposed/none) [3.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-glendc-gopher-json [amd64] (artful-proposed/none) [0.1.0+git20170414.0.dc47430-1] (no packageset)
-queuebot:#ubuntu-release- New binary: backdoor-factory [amd64] (artful-proposed/none) [3.4.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-gophercloud-gophercloud [amd64] (artful-proposed/none) [0.0~git20170728.0.0118feec-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-tdewolff-test [amd64] (artful-proposed/none) [0.0~git20170115.0.a7cf99a-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-declarative-option [amd64] (artful-proposed/none) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-denverdino-aliyungo [amd64] (artful-proposed/none) [0.0~git20170721.0.80ceb80-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-go-playground-validator.v8 [amd64] (artful-proposed/none) [8.18.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-opentracing-opentracing-go [amd64] (artful-proposed/none) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-rash-alt [amd64] (artful-proposed/none) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: astral [amd64] (artful-proposed/none) [1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-uber [amd64] (artful-proposed/none) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-errbase [amd64] (artful-proposed/none) [0.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-test-xml [amd64] (artful-proposed/none) [0.1.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-declarative [amd64] (artful-proposed/universe) [0.0.9-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted astral [amd64] (artful-proposed) [1.4-1]
-queuebot:#ubuntu-release- New: accepted golang-github-denverdino-aliyungo [amd64] (artful-proposed) [0.0~git20170721.0.80ceb80-1]
-queuebot:#ubuntu-release- New: accepted golang-github-tdewolff-test [amd64] (artful-proposed) [0.0~git20170115.0.a7cf99a-1]
-queuebot:#ubuntu-release- New: accepted ruby-declarative [amd64] (artful-proposed) [0.0.9-1]
-queuebot:#ubuntu-release- New: accepted ruby-rash-alt [amd64] (artful-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted ruby-uber [amd64] (artful-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted backdoor-factory [amd64] (artful-proposed) [3.4.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-go-playground-validator.v8 [amd64] (artful-proposed) [8.18.1-1]
-queuebot:#ubuntu-release- New: accepted ruby-test-xml [amd64] (artful-proposed) [0.1.8-1]
-queuebot:#ubuntu-release- New: accepted golang-github-opentracing-opentracing-go [amd64] (artful-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted ruby-errbase [amd64] (artful-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted git-lfs [amd64] (artful-proposed) [2.2.1-1]
-queuebot:#ubuntu-release- New: accepted git-lfs [ppc64el] (artful-proposed) [2.2.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-aliyun-aliyun-oss-go-sdk [amd64] (artful-proposed) [1.5.0+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-cheekybits-is [amd64] (artful-proposed) [0.0~git20150225.0.68e9c06-1]
-queuebot:#ubuntu-release- New: accepted golang-github-glendc-gopher-json [amd64] (artful-proposed) [0.1.0+git20170414.0.dc47430-1]
-queuebot:#ubuntu-release- New: accepted golang-github-hashicorp-go-rootcerts [amd64] (artful-proposed) [0.0~git20160503.0.6bb64b3-1]
-queuebot:#ubuntu-release- New: accepted lua-mode [amd64] (artful-proposed) [20151025-2]
-queuebot:#ubuntu-release- New: accepted org-mode [amd64] (artful-proposed) [9.0.9+dfsg-3]
-queuebot:#ubuntu-release- New: accepted git-lfs [i386] (artful-proposed) [2.2.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-approvals-go-approval-tests [amd64] (artful-proposed) [0.0~git20170712.0.c1e747e-1]
-queuebot:#ubuntu-release- New: accepted golang-github-gophercloud-gophercloud [amd64] (artful-proposed) [0.0~git20170728.0.0118feec-1]
-queuebot:#ubuntu-release- New: accepted more-itertools [amd64] (artful-proposed) [3.2.0-2]
-queuebot:#ubuntu-release- New: accepted git-lfs [s390x] (artful-proposed) [2.2.1-1]
-queuebot:#ubuntu-release- New: accepted inflection [amd64] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-chzyer-readline [amd64] (artful-proposed) [1.4-1]
-queuebot:#ubuntu-release- New: accepted ruby-declarative-option [amd64] (artful-proposed) [0.1.0-1]
#ubuntu-release 2017-08-04
<slangasek> ffmpeg autopkgtests fail on armhf because of a SIGBUS in the NEON assembly.  kill me now
<slangasek> ah, no upstream runtime detection of NEON support; that makes it easy, disable NEON support at buildtime. :P
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (zesty-proposed) [0.7.9-233-ge586fe35-0ubuntu1~17.04.1]
-queuebot:#ubuntu-release- New binary: golang-github-matryer-try [amd64] (artful-proposed/universe) [1+git20161228.6.9ac251b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-tdewolff-buffer [amd64] (artful-proposed/universe) [1.0.0+git20170115.7.df6253e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-opentracing-contrib-go-stdlib [amd64] (artful-proposed/universe) [0.0~git20170528.48e4d76-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-representable [amd64] (artful-proposed/universe) [3.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-tdewolff-strconv [amd64] (artful-proposed/universe) [1.0.0+git20160427.0.3e8091f-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted fwupd [amd64] (artful-proposed) [0.9.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted fwupd [armhf] (artful-proposed) [0.9.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted fwupd [ppc64el] (artful-proposed) [0.9.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-github-matryer-try [amd64] (artful-proposed) [1+git20161228.6.9ac251b-1]
-queuebot:#ubuntu-release- New: accepted golang-github-tdewolff-buffer [amd64] (artful-proposed) [1.0.0+git20170115.7.df6253e-1]
-queuebot:#ubuntu-release- New: accepted linux [amd64] (artful-proposed) [4.11.0-13.19]
-queuebot:#ubuntu-release- New: accepted linux [armhf] (artful-proposed) [4.11.0-13.19]
-queuebot:#ubuntu-release- New: accepted linux [ppc64el] (artful-proposed) [4.11.0-13.19]
-queuebot:#ubuntu-release- New: accepted ruby-representable [amd64] (artful-proposed) [3.0.4-1]
-queuebot:#ubuntu-release- New: accepted fwupd [arm64] (artful-proposed) [0.9.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted fwupd [s390x] (artful-proposed) [0.9.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-github-tdewolff-strconv [amd64] (artful-proposed) [1.0.0+git20160427.0.3e8091f-1]
-queuebot:#ubuntu-release- New: accepted linux [i386] (artful-proposed) [4.11.0-13.19]
-queuebot:#ubuntu-release- New: accepted fwupd [i386] (artful-proposed) [0.9.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted linux [arm64] (artful-proposed) [4.11.0-13.19]
-queuebot:#ubuntu-release- New: accepted golang-github-opentracing-contrib-go-stdlib [amd64] (artful-proposed) [0.0~git20170528.48e4d76-1]
-queuebot:#ubuntu-release- New: accepted linux [s390x] (artful-proposed) [4.11.0-13.19]
-queuebot:#ubuntu-release- New: accepted mozjs52 [source] (artful-proposed) [52.2.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted mozjs52 [source] (artful-proposed) [52.2.1-1~git1]
<teward> jgrimm: fun fact your patch builds without issue.  Let's see if installation still works :p
-queuebot:#ubuntu-release- New binary: mozjs52 [ppc64el] (artful-proposed/universe) [52.2.1-1~git1] (no packageset)
-queuebot:#ubuntu-release- New binary: mozjs52 [i386] (artful-proposed/universe) [52.2.1-1~git1] (no packageset)
-queuebot:#ubuntu-release- New binary: mozjs52 [s390x] (artful-proposed/universe) [52.2.1-1~git1] (no packageset)
-queuebot:#ubuntu-release- New binary: mozjs52 [amd64] (artful-proposed/universe) [52.2.1-1~git1] (no packageset)
-queuebot:#ubuntu-release- New binary: mozjs52 [armhf] (artful-proposed/universe) [52.2.1-1~git1] (no packageset)
<tumbleweed> f/win 32
-queuebot:#ubuntu-release- New binary: mozjs52 [arm64] (artful-proposed/universe) [52.2.1-1~git1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-tdewolff-parse [amd64] (artful-proposed/universe) [2.1.0+git20170712.30.e4ac711-1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.11.0-13.19] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.11.0-13.19]
-queuebot:#ubuntu-release- New: accepted golang-github-tdewolff-parse [amd64] (artful-proposed) [2.1.0+git20170712.30.e4ac711-1]
-queuebot:#ubuntu-release- New: accepted mozjs52 [arm64] (artful-proposed) [52.2.1-1~git1]
-queuebot:#ubuntu-release- New: accepted mozjs52 [i386] (artful-proposed) [52.2.1-1~git1]
-queuebot:#ubuntu-release- New: accepted mozjs52 [s390x] (artful-proposed) [52.2.1-1~git1]
-queuebot:#ubuntu-release- New: accepted mozjs52 [amd64] (artful-proposed) [52.2.1-1~git1]
-queuebot:#ubuntu-release- New: accepted mozjs52 [ppc64el] (artful-proposed) [52.2.1-1~git1]
-queuebot:#ubuntu-release- New: accepted mozjs52 [armhf] (artful-proposed) [52.2.1-1~git1]
<slangasek> Laney: I'm seeing a distinct lack of ppc64el runners; if I restart the systemd units they fail the same way; not sure what's going on, I see some output from cloud-init but I don't see anything show up in 'nova list' and it ultimately reports a 'testbed failure'
-queuebot:#ubuntu-release- Unapproved: gnome-flashback (zesty-proposed/universe) [3.22.1-0ubuntu1 => 3.22.1-0ubuntu1.1] (edubuntu)
-queuebot:#ubuntu-release- New binary: sidplay-libs [ppc64el] (artful-proposed/universe) [2.1.1-15ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: sidplay-libs [amd64] (artful-proposed/universe) [2.1.1-15ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: sidplay-libs [s390x] (artful-proposed/universe) [2.1.1-15ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: sidplay-libs [i386] (artful-proposed/universe) [2.1.1-15ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: sidplay-libs [arm64] (artful-proposed/universe) [2.1.1-15ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: sidplay-libs [armhf] (artful-proposed/universe) [2.1.1-15ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: golang-github-tdewolff-minify [i386] (artful-proposed/universe) [2.1.0+git20170802.25.b6ab3cd-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-tdewolff-minify [ppc64el] (artful-proposed/universe) [2.1.0+git20170802.25.b6ab3cd-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-tdewolff-minify [amd64] (artful-proposed/universe) [2.1.0+git20170802.25.b6ab3cd-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-tdewolff-minify [armhf] (artful-proposed/universe) [2.1.0+git20170802.25.b6ab3cd-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-tdewolff-minify [arm64] (artful-proposed/universe) [2.1.0+git20170802.25.b6ab3cd-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-tdewolff-minify [s390x] (artful-proposed/universe) [2.1.0+git20170802.25.b6ab3cd-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gvfs (xenial-proposed/main) [1.28.2-1ubuntu1~16.04.1 => 1.28.2-1ubuntu1~16.04.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted golang-github-tdewolff-minify [amd64] (artful-proposed) [2.1.0+git20170802.25.b6ab3cd-1]
-queuebot:#ubuntu-release- New: accepted golang-github-tdewolff-minify [armhf] (artful-proposed) [2.1.0+git20170802.25.b6ab3cd-1]
-queuebot:#ubuntu-release- New: accepted golang-github-tdewolff-minify [ppc64el] (artful-proposed) [2.1.0+git20170802.25.b6ab3cd-1]
-queuebot:#ubuntu-release- New: accepted sidplay-libs [amd64] (artful-proposed) [2.1.1-15ubuntu1]
-queuebot:#ubuntu-release- New: accepted sidplay-libs [armhf] (artful-proposed) [2.1.1-15ubuntu1]
-queuebot:#ubuntu-release- New: accepted sidplay-libs [ppc64el] (artful-proposed) [2.1.1-15ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-github-tdewolff-minify [arm64] (artful-proposed) [2.1.0+git20170802.25.b6ab3cd-1]
-queuebot:#ubuntu-release- New: accepted golang-github-tdewolff-minify [s390x] (artful-proposed) [2.1.0+git20170802.25.b6ab3cd-1]
-queuebot:#ubuntu-release- New: accepted sidplay-libs [i386] (artful-proposed) [2.1.1-15ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-github-tdewolff-minify [i386] (artful-proposed) [2.1.0+git20170802.25.b6ab3cd-1]
-queuebot:#ubuntu-release- New: accepted sidplay-libs [s390x] (artful-proposed) [2.1.1-15ubuntu1]
-queuebot:#ubuntu-release- New: accepted sidplay-libs [arm64] (artful-proposed) [2.1.1-15ubuntu1]
<tsimonq2> Thank you, whoever approved sidplay-libs
<tsimonq2> Hey Release Team! Could someone let indicator-sound-gtk2 migrate? It's depwait on s390x, but that would have happened regardless of when it was uploaded after the s390x port became official because ido-gtk2 is FTBFS on only s390x and it looks fairly difficult to fix...
-queuebot:#ubuntu-release- Unapproved: maas (xenial-proposed/main) [2.2.0+bzr6054-0ubuntu2~16.04.1 => 2.2.2-6099-g8751f91-0ubuntu1~16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: maas (zesty-proposed/main) [2.2.0+bzr6054-0ubuntu2~17.04.1 => 2.2.2-6099-g8751f91-0ubuntu1~17.04.1] (ubuntu-server)
<infinity> tsimonq2: What makes you think s390x has anything to do with it not migrating?
<infinity> tsimonq2: (And, in fact, it migrated just fine)
<tsimonq2> infinity: Because I expected Britney to not let it migrate, but I guess I was wrong.
<tsimonq2> infinity: I guess my comment was a bit premature, apologies.
<xnox> it only cares about regressions..... thus if something is bad on s390x it stays bad on s390x. We do not require that everything works everywhere.
<tsimonq2> xnox: Ah, gotcha.
<tsimonq2> I didn't know that.
<tsimonq2> Now I do. :)
<infinity> tsimonq2: Think of the environment where britney "grew up".
<infinity> tsimonq2: At some points in Debian's history, there have been 11 release arches.
<infinity> tsimonq2: If "FTBFS on an arch where it's never built before" needed manual intervention, we'd have all gone insane by now.
<tsimonq2> infinity: That's a fair point.
<slangasek> infinity: good thing britney saved us from going insane
<Laney> slangasek: some kind of ongoing incident
<slangasek> lovely
<infinity> Laney: Are you referring to scalingstack, or our descent into madness?
<slangasek> infinity: scalingstack
<slangasek> I don't know what incident this is, but Laney was typey-typey in the byobu; maybe when he's done he can explain to me how he connected the dots
<Laney> first I checked journalctl -u <some bos01 failed unit> -e
<Laney> and saw that the last lines were about failing to resolve ftpmaster.internal
<Laney> to me that sounds like scalingstack is having a sad time of life
<slangasek> oh; I hadn't seen that previously
<Laney> so I went and looked in IS channels
<Laney> and sure enough they were talking about bos01
<slangasek> ok
<Laney> :)
<Laney> actually it was still not completely fixed even when they thought it was, but should be now-ish
<slangasek> right, I guess the ftpmaster.internal issue was knock-on to what I saw last night and I should've just escalated to  immediately
<slangasek> to IS
<slangasek> "nova not workie, halp"
<xnox> slangasek, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#util-linux
<xnox> can nplan/i386 test be overriden? lack of this util-linux blocks s390x image builds in artful due to chmem/lsmem conflict between util-linux and s390-tools.
<xnox> actually that will do nothing
<xnox> as s390-tools is not considered and entagled with perl
<xnox> migrate perl then override nplan/i386
<slangasek> xnox: better than asking me if it can be overridden is to tell me why it should
<slangasek> xnox: (in terms of why it's right to override the test, not just why it's useful to you to do so)
<slangasek> xnox: I see you've requested a retry for it, which I can hope would get done today
<slangasek> infinity: should the lubuntu alternate xenial exclusion be committed to the ref crontab?
-queuebot:#ubuntu-release- New binary: gcc-defaults [ppc64el] (artful-proposed/main) [1.171ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: gcc-defaults [s390x] (artful-proposed/main) [1.171ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: gcc-defaults [arm64] (artful-proposed/main) [1.171ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: gcc-defaults [armhf] (artful-proposed/main) [1.171ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: gcc-defaults [amd64] (artful-proposed/main) [1.171ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: gcc-defaults [i386] (artful-proposed/main) [1.171ubuntu1] (core)
-queuebot:#ubuntu-release- New: accepted gcc-defaults [amd64] (artful-proposed) [1.171ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-defaults [armhf] (artful-proposed) [1.171ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-defaults [ppc64el] (artful-proposed) [1.171ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-defaults [arm64] (artful-proposed) [1.171ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-defaults [s390x] (artful-proposed) [1.171ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-defaults [i386] (artful-proposed) [1.171ubuntu1]
-queuebot:#ubuntu-release- Unapproved: indicator-sound-gtk2 (zesty-proposed/universe) [12.10.0.1-0ubuntu5 => 12.10.0.1-0ubuntu5.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted juju-mongodb3.2 [source] (zesty-proposed) [3.2.15-0ubuntu1~17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted juju-mongodb3.2 [source] (xenial-proposed) [3.2.15-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted samba [source] (zesty-proposed) [2:4.5.8+dfsg-0ubuntu0.17.04.5]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (zesty-proposed) [1.1+17.04ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-image [source] (xenial-proposed) [1.1+16.04ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (zesty-proposed) [2:15.0.6-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted maas [source] (zesty-proposed) [2.2.2-6099-g8751f91-0ubuntu1~17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted maas [source] (xenial-proposed) [2.2.2-6099-g8751f91-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-logs [source] (zesty-proposed) [3.24.2-0ubuntu0.1]
<slangasek> xnox: did you still need runner logs for debugging the systemd failures?
-queuebot:#ubuntu-release- New binary: r-cran-ttr [ppc64el] (artful-proposed/none) [0.23-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ttr [s390x] (artful-proposed/none) [0.23-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-mustermann [amd64] (artful-proposed/universe) [1.0.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ttr [amd64] (artful-proposed/none) [0.23-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ttr [i386] (artful-proposed/none) [0.23-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gsl [ppc64el] (artful-proposed/main) [2.4+dfsg-3] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gsl [s390x] (artful-proposed/main) [2.4+dfsg-3] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gsl [i386] (artful-proposed/main) [2.4+dfsg-3] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: r-cran-ttr [armhf] (artful-proposed/universe) [0.23-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ttr [arm64] (artful-proposed/universe) [0.23-2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gsl [amd64] (artful-proposed/main) [2.4+dfsg-3] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gsl [arm64] (artful-proposed/main) [2.4+dfsg-3] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gsl [armhf] (artful-proposed/main) [2.4+dfsg-3] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted gsl [amd64] (artful-proposed) [2.4+dfsg-3]
-queuebot:#ubuntu-release- New: accepted gsl [armhf] (artful-proposed) [2.4+dfsg-3]
-queuebot:#ubuntu-release- New: accepted gsl [ppc64el] (artful-proposed) [2.4+dfsg-3]
-queuebot:#ubuntu-release- New: accepted gsl [arm64] (artful-proposed) [2.4+dfsg-3]
-queuebot:#ubuntu-release- New: accepted gsl [s390x] (artful-proposed) [2.4+dfsg-3]
-queuebot:#ubuntu-release- New: accepted gsl [i386] (artful-proposed) [2.4+dfsg-3]
-queuebot:#ubuntu-release- New: accepted r-cran-ttr [amd64] (artful-proposed) [0.23-2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ttr [armhf] (artful-proposed) [0.23-2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ttr [ppc64el] (artful-proposed) [0.23-2-1]
-queuebot:#ubuntu-release- New: accepted ruby-mustermann [amd64] (artful-proposed) [1.0.0-3]
-queuebot:#ubuntu-release- New: accepted r-cran-ttr [arm64] (artful-proposed) [0.23-2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ttr [s390x] (artful-proposed) [0.23-2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ttr [i386] (artful-proposed) [0.23-2-1]
#ubuntu-release 2017-08-05
<infinity> slangasek: Probably, yes.
<slangasek> infinity: will you commit it or shall I?
<slangasek> fwiw I've uploaded postgresql-common with a fix for the perl+postgresql autopkgtest regression.  I think it pans out to have been a regression in postgresql-common itself, and only the -proposed version of pgsql-common satisfies the test deps coherently
<slangasek> so once that settles we should be able to retry all those tests
<infinity> slangasek: I'll do it now.
<slangasek> infinity: k
<infinity> slangasek: Done.
<slangasek> oh, cpaelzer apparently already submitted a bug against postgresql-common in Debian, but did not get a fix uploaded; sigh
-queuebot:#ubuntu-release- New binary: ruby-mustermann-grape [amd64] (artful-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New source: libdazzle (artful-proposed/primary) [3.25.5-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected libdazzle [source] (artful-proposed) [3.25.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ruby-mustermann-grape [amd64] (artful-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New binary: core-memoize-clojure [amd64] (artful-proposed/universe) [0.5.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs-ivy [amd64] (artful-proposed/universe) [0.9.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: data-priority-map-clojure [amd64] (artful-proposed/universe) [0.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-fswrap [amd64] (artful-proposed/universe) [1.0.1-0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: sjacket-clojure [amd64] (artful-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tools-namespace-clojure [amd64] (artful-proposed/universe) [0.2.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: isa-support [amd64] (artful-proposed/universe) [1] (no packageset)
-queuebot:#ubuntu-release- New binary: isa-support [armhf] (artful-proposed/universe) [1] (no packageset)
-queuebot:#ubuntu-release- New binary: isa-support [i386] (artful-proposed/universe) [1] (no packageset)
-queuebot:#ubuntu-release- New binary: stencil-clojure [amd64] (artful-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: abiword [ppc64el] (artful-proposed/universe) [3.0.2-3] (desktop-extra)
-queuebot:#ubuntu-release- New binary: abiword [s390x] (artful-proposed/universe) [3.0.2-3] (desktop-extra)
<tsimonq2> yay, abiword!
-queuebot:#ubuntu-release- New binary: abiword [i386] (artful-proposed/universe) [3.0.2-3] (desktop-extra)
-queuebot:#ubuntu-release- New binary: abiword [amd64] (artful-proposed/universe) [3.0.2-3] (desktop-extra)
-queuebot:#ubuntu-release- New binary: abiword [arm64] (artful-proposed/universe) [3.0.2-3] (desktop-extra)
-queuebot:#ubuntu-release- New binary: abiword [armhf] (artful-proposed/universe) [3.0.2-3] (desktop-extra)
-queuebot:#ubuntu-release- New: accepted abiword [amd64] (artful-proposed) [3.0.2-3]
-queuebot:#ubuntu-release- New: accepted abiword [armhf] (artful-proposed) [3.0.2-3]
-queuebot:#ubuntu-release- New: accepted abiword [ppc64el] (artful-proposed) [3.0.2-3]
-queuebot:#ubuntu-release- New: accepted stencil-clojure [amd64] (artful-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted abiword [arm64] (artful-proposed) [3.0.2-3]
-queuebot:#ubuntu-release- New: accepted abiword [s390x] (artful-proposed) [3.0.2-3]
-queuebot:#ubuntu-release- New: accepted abiword [i386] (artful-proposed) [3.0.2-3]
-queuebot:#ubuntu-release- New: accepted core-memoize-clojure [amd64] (artful-proposed) [0.5.9-1]
-queuebot:#ubuntu-release- New: accepted emacs-ivy [amd64] (artful-proposed) [0.9.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted isa-support [armhf] (artful-proposed) [1]
-queuebot:#ubuntu-release- New: accepted python-fswrap [amd64] (artful-proposed) [1.0.1-0.1]
-queuebot:#ubuntu-release- New: accepted tools-namespace-clojure [amd64] (artful-proposed) [0.2.11-1]
-queuebot:#ubuntu-release- New: accepted data-priority-map-clojure [amd64] (artful-proposed) [0.0.7-1]
-queuebot:#ubuntu-release- New: accepted isa-support [i386] (artful-proposed) [1]
-queuebot:#ubuntu-release- New: accepted isa-support [amd64] (artful-proposed) [1]
-queuebot:#ubuntu-release- New: accepted sjacket-clojure [amd64] (artful-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New binary: tools-analyzer-jvm-clojure [amd64] (artful-proposed/universe) [0.7.1-3] (no packageset)
<LocutusOfBorg> hello, can I copy the qt stuff from 2819?
<LocutusOfBorg> Laney, I tried to update ben on transition tracker
<LocutusOfBorg> please let me know if anything break
<LocutusOfBorg> libpng1.6 can migrate if you ignore libreoffice/1:5.3.4-0ubuntu1 on s390x
<LocutusOfBorg> I'll copy from 2819 once everything is built https://blueprints.launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2819/+packages
<acheronuk> oooooh :) ^^^
<LocutusOfBorg> (unless somebody shouts at me, with gcc switching this is the best timing)
<tsimonq2> I'm pretty happy too, acheronuk :)
 * acheronuk whispers.....
<tsimonq2> lol
<LocutusOfBorg> mmm can anybody please point me at ben global.conf file? I think we are missing the base-url keyword inside it and this makes the link in "transitions" page broken
<LocutusOfBorg> not sure how you call the ben instance on the server
<LocutusOfBorg> (if somebody can try the new ben, just to be sure everything is ok would be nice)
-queuebot:#ubuntu-release- New binary: ruby-google-api-client [amd64] (artful-proposed/universe) [0.13.1-1] (no packageset)
<LocutusOfBorg> I'm pushing that button
<acheronuk> button pushing 'failed'
<doko> what's wrong with the matching of the package name in http://people.canonical.com/~ubuntu-archive/transitions/html/libgfortran.html ?
<tsimonq2> Someone with knowledge of the CI train, can someone land a ticket if there's packages that are ftbfs on arches but that's expected?
<tsimonq2> LocutusOfBorg tried landing 2819 but that's blocking it...
<tsimonq2> Oh
<tsimonq2> Wait nvm
<tsimonq2> Ignore me :)
-queuebot:#ubuntu-release- New binary: libundead [amd64] (artful-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-udatetime [ppc64el] (artful-proposed/none) [0.0.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libundead [i386] (artful-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-quantmod [amd64] (artful-proposed/none) [0.4-10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rss-bridge [amd64] (artful-proposed/none) [2017-08-03-1] (no packageset)
-queuebot:#ubuntu-release- New binary: racket-mode [amd64] (artful-proposed/none) [20170617+0+g9c5bcb7-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-udatetime [s390x] (artful-proposed/none) [0.0.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-udatetime [i386] (artful-proposed/none) [0.0.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-udatetime [amd64] (artful-proposed/none) [0.0.12-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libundead [armhf] (artful-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-udatetime [arm64] (artful-proposed/universe) [0.0.12-1] (no packageset)
<tsimonq2> Nevermind on my nevermind. I'm making up my mind. ;)
<tsimonq2> On ticket 2819, in this build log, qtwebengine is expected to be FTBFS: https://bileto.ubuntu.com/log/2819/publish/6/info/
<tsimonq2> How would we go about removing those builds or at least overriding it? I can't find docs on how to do this anywhere...
<slangasek> doko: do you maybe want to hold off on the no-change rebuilds for dropping python3.5 until things are migratable?
<doko> slangasek: too late, they are done, and most of them already migrated
<slangasek> heh
<slangasek> well, the amd64 autopkgtest queue is starving the i386 autopkgtest queue (again, as usual)
<slangasek> and as I was telling mwhudson, we can't really trigger retries of tests that have gone missing while there's a backlog, without making the backlog worse
<slangasek> (maybe both of these bugs need to be prioritized)
<doko> maybe we should stop the import for a few days? but then you won't get the gcc-7 fixes either
<slangasek> looking at the queue, it's mostly not the importer right now
<Laney> why are tests going missing?
<doko> I think I call it a day.I'll pester people tomorrow to get binutils/gcc migrated ...
#ubuntu-release 2017-08-06
<slangasek> Laney: don't know, he didn't name any
<slangasek> Laney: so if you look at the 'in progress' for python3-defaults revdeps, there are several 'in progress' on archs that have nothing in the queue
<slangasek> e.g. numba (all archs), and the ever popular onioncircuits (all archs)
<slangasek> doko: new pillow regresses skimage...
<slangasek> doko: linux/s390x autopkgtest failure seems to be a genuine regression with new binutils+gcc (failure to rebuild kernel with gcc-7)
<slangasek> Laney: one cause of the "missing" tests is p-m marking as 'test in progress' tests for packages that have new versions uploaded after the current package that is supposedly being tested; it appears to get confused and considers the package's self-test as an "in progress" test, but when it finishes the result is (correctly) only attached to that package
-queuebot:#ubuntu-release- New binary: rss-bridge [amd64] (artful-proposed/universe) [2017-08-03-3] (no packageset)
-queuebot:#ubuntu-release- New binary: gdcm [ppc64el] (artful-proposed/universe) [2.8.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gdcm [s390x] (artful-proposed/universe) [2.8.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gdcm [i386] (artful-proposed/universe) [2.8.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gdcm [armhf] (artful-proposed/universe) [2.8.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gdcm [arm64] (artful-proposed/universe) [2.8.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gdcm [amd64] (artful-proposed/universe) [2.8.2-1] (no packageset)
<infinity> slangasek: Nitpicking, but it's "failure to build zfs with the new toolchain".  Meaningless nit, since we ship zfs with our kernel. :P
<infinity> apw: ^-- Can someone have a look at that?
<infinity> apw: Fairly good chance it's a ZFS bug, not a compiler bug.
<doko> would have been nice if that had been test built before at least once ... and it had: https://launchpad.net/ubuntu/+archive/test-rebuild-20170706-gcc7/+build/13003300
-queuebot:#ubuntu-release- New binary: py3status [amd64] (artful-proposed/universe) [3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: soapysdr [amd64] (artful-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: soapysdr [ppc64el] (artful-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: soapysdr [i386] (artful-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: soapysdr [s390x] (artful-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (zesty-backports/universe) [147-1~ubuntu17.04.1 => 148-1~ubuntu17.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: soapysdr [arm64] (artful-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: soapysdr [armhf] (artful-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (zesty-backports) [148-1~ubuntu17.04.1]
-queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [147-1~ubuntu16.04.1 => 148-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [148-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted py3status [amd64] (artful-proposed) [3.5-1]
-queuebot:#ubuntu-release- New: accepted soapysdr [arm64] (artful-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted soapysdr [i386] (artful-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted soapysdr [s390x] (artful-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted soapysdr [amd64] (artful-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted soapysdr [ppc64el] (artful-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted soapysdr [armhf] (artful-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted gdcm [amd64] (artful-proposed) [2.8.2-1]
-queuebot:#ubuntu-release- New: accepted gdcm [armhf] (artful-proposed) [2.8.2-1]
-queuebot:#ubuntu-release- New: accepted gdcm [ppc64el] (artful-proposed) [2.8.2-1]
-queuebot:#ubuntu-release- New: accepted gdcm [arm64] (artful-proposed) [2.8.2-1]
-queuebot:#ubuntu-release- New: accepted gdcm [s390x] (artful-proposed) [2.8.2-1]
-queuebot:#ubuntu-release- New: accepted gdcm [i386] (artful-proposed) [2.8.2-1]
-queuebot:#ubuntu-release- New: accepted rss-bridge [amd64] (artful-proposed) [2017-08-03-1]
-queuebot:#ubuntu-release- New: accepted rss-bridge [amd64] (artful-proposed) [2017-08-03-3]
-queuebot:#ubuntu-release- New: accepted r-cran-quantmod [amd64] (artful-proposed) [0.4-10-1]
-queuebot:#ubuntu-release- New: accepted ruby-google-api-client [amd64] (artful-proposed) [0.13.1-1]
-queuebot:#ubuntu-release- New: accepted racket-mode [amd64] (artful-proposed) [20170617+0+g9c5bcb7-2]
-queuebot:#ubuntu-release- New: accepted tools-analyzer-jvm-clojure [amd64] (artful-proposed) [0.7.1-3]
-queuebot:#ubuntu-release- New: accepted python-udatetime [amd64] (artful-proposed) [0.0.12-1]
-queuebot:#ubuntu-release- New: accepted python-udatetime [i386] (artful-proposed) [0.0.12-1]
-queuebot:#ubuntu-release- New: accepted python-udatetime [s390x] (artful-proposed) [0.0.12-1]
-queuebot:#ubuntu-release- New: accepted python-udatetime [arm64] (artful-proposed) [0.0.12-1]
-queuebot:#ubuntu-release- New: accepted python-udatetime [ppc64el] (artful-proposed) [0.0.12-1]
<doko> slangasek: ack skimage, my priorities are currently to get transitions ready entangled with perl (currently I look at gsl)
<doko> the toolchain should be ready, minus failing linux and libreoffice autopkg tests
<doko> and I'm looking at a gfortran regression, not terminating to build ...
-queuebot:#ubuntu-release- New binary: core-match-clojure [amd64] (artful-proposed/universe) [0.2.2-1] (no packageset)
<Soul_Sample> Hey! I cannot update from 16.04 to 16.10. I switched the prompt from lts to normal, but I still get "No releases found" when I try to upgrade. Any ideas?
<sary> Salutations!
<PaulW2U> Soul_Sample: you should probably take this to #ubuntu but 16.10 is no longer supported - see https://lists.ubuntu.com/archives/ubuntu-announce/2017-July/000223.html
<Soul_Sample> PaulW2U: I did ask there and was referred here. I know it's not supported, but can't I still upgrade to that, and then subsequently to 17.04? I know it's not the cleanest upgrade process, but it's the most convenient I have right now
<sary> ah. so there is no meta-release for 16.10!
<Soul_Sample> sary: looks like it, I just found a couple of posts with similar problems from 14.04. There has to be a way to update this, still
<Soul_Sample> sary: I think I found the problem! just a sec
<Soul_Sample> sary: I found the meta-release file on my disk and it referred to kde-neon that I've tried almost a year ago. so I removed the file and reinstalled the ubuntu-release-upgrade package and now it's upgrading to zesty
<Soul_Sample> sary: this will probably break everything now, but whatever I'll fix it :D
<sary> Soul_Sample: Yay! good catch .. you could've does something like this http://paste.ubuntu.com/25254813/
<Soul_Sample> yup, probably a better solution. I can't imagine what will happen now when it skips from 16.04 to 17.04. But let's see!
<sary> but that's not clean nor recommended either..
<Soul_Sample> or maybe it's deliberate for 16.04.3
<sary> I bet it will go fine.. if using do-release-upgrade , am not sure if the GUI would break during the upgrade or not!
<Soul_Sample> oh well, if it falls apart I'll do a clean install. it's long overdue anyway, considering what I've done to this one
<Laney> slangasek: Could that be that you didn't requeue RUNNING-ALWAYSFAIL when we had the incident earlier in the week?
<Laney> I don't see any results for systemd/234-2ubuntu2; /me looks
<apw> Laney, i ma pretty sure he said he used --status RUNNING
<Laney> yah
<Laney> well there's this systemd thing that's holding it up anyway
<doko> infinity: https://launchpadlibrarian.net/332154072/buildlog_ubuntu-artful-amd64.theseus_3.3.0-5ubuntu1_BUILDING.txt.gz
<doko>    dh_builddeb
<doko> Can't use an undefined value as an ARRAY reference at /usr/bin/dh_builddeb.pkgbinarymangler line 138.
<doko> ahh, pkgbinarymangler ...
<doko> no, that's the diverted one
<doko> also seen when building altree
<doko> tsimonq2: ^^^ that looks to be introduced by the debhelper merge
<doko> also: https://launchpad.net/ubuntu/+source/thepeg/1.8.0-3build1/+build/13205523
<tsimonq2> doko: Yep, that's on my radar
<tsimonq2> doko: In fact, I'll look into it right now...
<Laney> http://paste.ubuntu.com/25255390/
<Laney> that's the systemd failure
<Laney> shortly I'll try to make those into real failures so it doesn't loop forever ...
<tsimonq2> doko: Getting an upload sponsored (he's downloading it now) that should fix the problem. I tested it locally with theseus and it works fine.
<tsimonq2> (I tested it with sbuild and adding my PPA as a dep)
<tsimonq2> doko: Uploaded.
<tsimonq2> doko: There, I can confirm that my fix works. Apologies for the breakage, I'll test it more next time before getting it uploaded.
<doko> tsimonq2: ta, now which autopkg tests fails because of that ...
<doko> hmm, why is http://people.canonical.com/~ubuntu-archive/transitions/html/gsl.html still showing gnuastro?
<LocutusOfBorg> did I break ben?
<LocutusOfBorg> I updated ben yesterday
<doko> sponsored a broken debhelper today, why not ben yesterday? ;-P
<tsimonq2> doko: I don't know, excuses hasn't updated yet :P
<tsimonq2> doko: Hey now, he also sponsored the fixed one! :P
<tsimonq2> doko: Oh, and I also am responsible for ben. It's talking about updating lp:ubuntu-transition-tracker. idk, maybe I broke ben too. Just my luck today... ^_^
<LocutusOfBorg> doko, I did spend more than a week fixing it, and I failed
<LocutusOfBorg> moreover, it broke ddeb generation, not the normal build
<LocutusOfBorg> so double fail in testing :)
<doko> shit happens
<LocutusOfBorg> sorry for that, completely my fault
<LocutusOfBorg> I'm trying to setup an irc bounceer right now
<LocutusOfBorg> I waited for the weekend, to avoid broken things around when people uploads stuff :)
<tsimonq2> doko: Sure it does, I'm just wondering how it'll look on my MOTU app in a week :P Just saying... >__> ... <__<  :)
<tsimonq2> LocutusOfBorg: my name is on it, I'll claim responsibility
<tsimonq2> But hey, it's done now.
<LocutusOfBorg> doko, I can revert ben on bzr, if you can restart the instance
<tsimonq2> Poor ben
<LocutusOfBorg> I really want the new feature that ben got since the last 5 years :)
<LocutusOfBorg> specially the "partial" and the new fixed links
<LocutusOfBorg> btw, xnox your systemd upload made a little bit the infrastructure sad
<LocutusOfBorg> You are in emergency mode. After logging in, type "journalctl -xb" to view
<LocutusOfBorg> system logs, "systemctl reboot" to reboot, "systemctl default" or ^D to boot
<LocutusOfBorg> into default mode.
<LocutusOfBorg> Press Enter for maintenance
<LocutusOfBorg> (or press Control-D to continue):
<LocutusOfBorg> this is on autopkgtest server
<LocutusOfBorg> triggers: ['systemd/234-2ubuntu2', 'python3-defaults/3.6.1-0ubuntu3', 'perl/5.26.0-5']
<LocutusOfBorg> slangasek, ^^ you requested some similar trigger too, maybe we should delete them?
<LocutusOfBorg> doko, seems that stuff is disappearing from tracker
<LocutusOfBorg> so ben might be not broken
<LocutusOfBorg> I'm blaming your ben file :)
 * LocutusOfBorg copies the debian ben into your one
<slangasek> Laney: not requeuing alwaysfail wouldn't be causing migration delays
<Laney> that is correct, but I didn't understand the stated problem to be such
<LocutusOfBorg> tsimonq2, just to be clear, I was your sponsor, I signed the upload, so the fault is mine.
<LocutusOfBorg> one day you will be MOTU, and you will get blamed for stuff that your sponsorees will break
<LocutusOfBorg> :)
<lan3y> ok, some failures of systemd are rolling in now thanks to my fix
<lan3y> bah
-queuebot:#ubuntu-release- New binary: polygen [amd64] (artful-proposed/none) [1.0.6.ds2-16] (no packageset)
-queuebot:#ubuntu-release- New binary: at-at-clojure [amd64] (artful-proposed/none) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: java-classpath-clojure [amd64] (artful-proposed/none) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: weechat-el [amd64] (artful-proposed/universe) [0.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: bdfproxy [amd64] (artful-proposed/none) [0.3.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: java-jmx-clojure [amd64] (artful-proposed/none) [0.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lazymap-clojure [amd64] (artful-proposed/none) [3.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cheshire-clojure [amd64] (artful-proposed/none) [5.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-wither [amd64] (artful-proposed/none) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: medley-clojure [amd64] (artful-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: math-combinatorics-clojure [amd64] (artful-proposed/none) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: math-numeric-tower-clojure [amd64] (artful-proposed/none) [0.0.4-1] (no packageset)
#ubuntu-release 2018-07-30
-queuebot:#ubuntu-release- New: accepted emacs-non-dfsg [amd64] (cosmic-proposed) [1:25.2+1-3]
-queuebot:#ubuntu-release- New: accepted emacs [armhf] (cosmic-proposed) [1:25.2+1-8]
-queuebot:#ubuntu-release- New: accepted emacs [ppc64el] (cosmic-proposed) [1:25.2+1-8]
-queuebot:#ubuntu-release- New: accepted emacs [amd64] (cosmic-proposed) [1:25.2+1-8]
-queuebot:#ubuntu-release- New: accepted emacs [s390x] (cosmic-proposed) [1:25.2+1-8]
-queuebot:#ubuntu-release- New: accepted emacs [i386] (cosmic-proposed) [1:25.2+1-8]
-queuebot:#ubuntu-release- New binary: emacs [arm64] (cosmic-proposed/universe) [1:25.2+1-8] (no packageset)
-queuebot:#ubuntu-release- New: accepted emacs [arm64] (cosmic-proposed) [1:25.2+1-8]
-queuebot:#ubuntu-release- Unapproved: appstream-glib (xenial-proposed/main) [0.5.13-1ubuntu5 => 0.5.13-1ubuntu6] (desktop-core)
-queuebot:#ubuntu-release- New source: gnome-shell-extension-gsconnect (cosmic-proposed/primary) [11+wip2018.07.26-0ubuntu1]
-queuebot:#ubuntu-release- New source: astroid2-for-python3 (cosmic-proposed/primary) [1.6.5-1isupstream201ubuntu1]
-queuebot:#ubuntu-release- New: accepted astroid2-for-python3 [source] (cosmic-proposed) [1.6.5-1isupstream201ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (xenial-proposed) [2.21.63.7]
<LocutusOfBorg> AA ping wrt the points of some days ago :)
<LocutusOfBorg> 2) flint-arb and sagemath removals on armhf (they might come back eventually if somebody fixes the armhf aligment issues, there is a new release out that is going in debian new soon, but sagemath needs porting 3) kick out from release the following packages php-net-ldap2 php-net-ldap3 simpleid-ldap php-mochery and enjoy the phpunit migration (and symphony is now testsuite fixed!)
<LocutusOfBorg> php-defaults is sad because of phpunit not migrating, and also lots of other stuff
-queuebot:#ubuntu-release- Unapproved: libguestfs (bionic-proposed/universe) [1:1.36.13-1ubuntu3 => 1:1.36.13-1ubuntu3.1] (no packageset)
<apw> LocutusOfBorg, looking
<apw> LocutusOfBorg, is there a bug associated with (2) ?
<LocutusOfBorg> apw, no bug, but I can open an RC in debian if you want...
<LocutusOfBorg> btw I tried upstream patches, and nothing worked. it might come back with the new release, this is why I didn't bothered to fix it
<apw> i was just looking for an ubuntu bug to put my findings in
<LocutusOfBorg> https://github.com/fredrik-johansson/arb/issues/233#issuecomment-408414130
<gitlab-bot> fredrik-johansson issue 233 in arb "testsuite failure on arm*" (comments: 5) [Open]
<LocutusOfBorg> also, camitk question still stands, and my opinion that itk4 should build on amd64 and i386 still stands too...
<LocutusOfBorg> we can't ship stuff with broken code, specially for scientific applications.
<LocutusOfBorg> if testsuite fails, drop package, or fix code
<LocutusOfBorg> and nobody wants to fix ITK stuff
<apw> LocutusOfBorg, ok (2) confirmed and done
<LocutusOfBorg> ack thanks!
-queuebot:#ubuntu-release- New: accepted gnome-shell-extension-gsconnect [source] (cosmic-proposed) [11+wip2018.07.26-0ubuntu1]
-queuebot:#ubuntu-release- New binary: gnome-shell-extension-gsconnect [amd64] (cosmic-proposed/universe) [11+wip2018.07.26-0ubuntu2] (no packageset)
<apw> ^ ? those have different source and binary versions
<apw> oh ... just working fast, ubuntu1 FTBFSd
<didrocks> yep ;) you don't compile js, but it still build gresources :p
<didrocks> didn't spot that until the FTBFS
<didrocks> hadn't*
<didrocks> (also, addressing other demands from Seb on this followup upoad)
<didrocks> upload*
<acheronuk> apw or any other AA: could you please remove the dropped kdepim-doc binary if that is what it is saying here: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kmail
<apw> acheronuk, where did the files go ?
<acheronuk> apw: it was a transitional package. they ended up in kmail package itself AFAIK
<acheronuk> I thought dropped transitional packages just went 'poof' on their own, but maybe not
<apw> no i would not expect them to, in this context
<apw> they should become autoinstalled and unreferenced on a local system on upgrade
<apw> i assume they were transitional in bionic already
<acheronuk> they were
<LocutusOfBorg> apw, news for 3)? :)
<sil2100> Everyone happy with stuff in xenial-updates? I will be spinning .5 RCs in a moment if no one's unhappy
<apw> sil2100, as far as i am aware we are good
<sil2100> Ok, spinning candidates o/
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Xenial 16.04.5] (20180730.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Xenial 16.04.5] (20180730.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Xenial 16.04.5] (20180730.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Xenial 16.04.5] (20180730.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base powerpc [Xenial 16.04.5] (20180730.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Xenial 16.04.5] (20180730.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Xenial 16.04.5] (20180730.1) has been added
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Xenial 16.04.5] (20101020ubuntu451.25) has been added
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Xenial 16.04.5] (20101020ubuntu451.25) has been added
-queuebot:#ubuntu-release- Builds: Netboot armhf [Xenial 16.04.5] (20101020ubuntu451.25) has been added
-queuebot:#ubuntu-release- Builds: Netboot i386 [Xenial 16.04.5] (20101020ubuntu451.25) has been added
-queuebot:#ubuntu-release- Builds: Netboot powerpc [Xenial 16.04.5] (20101020ubuntu451.25) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Xenial 16.04.5] (20101020ubuntu451.25) has been added
-queuebot:#ubuntu-release- Builds: Netboot s390x [Xenial 16.04.5] (20101020ubuntu451.25) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Xenial 16.04.5] (20180730.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Xenial 16.04.5] (20180730.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Xenial 16.04.5] (20180730.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Xenial 16.04.5] (20180730.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Xenial 16.04.5] (20180730.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Xenial 16.04.5] (20180730.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Xenial 16.04.5] (20180730) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Xenial 16.04.5] (20180730) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Xenial 16.04.5] (20180730.1) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Xenial 16.04.5] (20180730.1) has been added
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop amd64 [Xenial 16.04.5] (20180730.1) has been added
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop i386 [Xenial 16.04.5] (20180730.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Xenial 16.04.5] (20180730.1) has been added
-queuebot:#ubuntu-release- Unapproved: accepted linux-base [sync] (trusty-proposed) [4.5ubuntu1~14.04.1]
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Xenial 16.04.5] (20180730.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Xenial 16.04.5] (20180730.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Xenial 16.04.5] (20180730.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Xenial 16.04.5] (20180730.1) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Xenial 16.04.5] (20180730) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Xenial 16.04.5] (20180730) has been added
<coreycb> infinity: sil2100: hello, if you have a chance can you take a look at keepalived for bionic (verification-done) and xenial (unapproved queue)?
<sil2100> I will be doing my SRU shift in a bit
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Xenial 16.04.5] (20180730) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Xenial 16.04.5] (20180730) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Xenial 16.04.5] (20180730.1) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Xenial 16.04.5] (20180730) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Xenial 16.04.5] (20180730) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Xenial 16.04.5] (20180730.1) has been added
<LocutusOfBorg> apw, seems like you didn't drop sagemath binaries on armhf?
<LocutusOfBorg> oh noes, the problem is another one: sagetex is trying to run armhf tests but fails because sagemath can't be installed... what to do here?
<apw> that is just how it is, if sagemath doesn't exist there
<LocutusOfBorg> yes. but shouldn't autopkgtest understand this now?
<LocutusOfBorg> or is an hint needed?
<apw> why would they, they arn't telepathic
<apw> it used to work, it no longer does
<LocutusOfBorg> autopkgtest might see that the binary is NBS and not return error
<LocutusOfBorg> but I get this is mostly impossible
<apw> well it depends if it being NBS is deliberate or not
<LocutusOfBorg> this is why I get this is hard
<apw> i thin this is going to be hint central, and likely one with a can to kick for the forseeable
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Xenial 16.04.5] has been updated (20180730.2)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Xenial 16.04.5] has been updated (20180730.2)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Xenial 16.04.5] has been updated (20180730.2)
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Xenial 16.04.5] has been updated (20180730.2)
-queuebot:#ubuntu-release- Builds: Ubuntu Base powerpc [Xenial 16.04.5] has been updated (20180730.2)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Xenial 16.04.5] has been updated (20180730.2)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Xenial 16.04.5] has been updated (20180730.2)
-queuebot:#ubuntu-release- Unapproved: glib2.0 (xenial-proposed/main) [2.48.2-0ubuntu3 => 2.48.2-0ubuntu4] (core)
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Xenial 16.04.5] has been updated (20180730.1)
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Xenial 16.04.5] has been updated (20180730.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Xenial 16.04.5] has been updated (20180730.2)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Xenial 16.04.5] has been updated (20180730.2)
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Xenial 16.04.5] has been updated (20180730.2)
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Xenial 16.04.5] has been updated (20180730.2)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Xenial 16.04.5] has been updated (20180730.2)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Xenial 16.04.5] has been updated (20180730.2)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Xenial 16.04.5] has been updated (20180730.2)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Xenial 16.04.5] has been updated (20180730.2)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Xenial 16.04.5] has been updated (20180730.1)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Xenial 16.04.5] has been updated (20180730.1)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Xenial 16.04.5] has been updated (20180730.2)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Xenial 16.04.5] has been updated (20180730.2)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Xenial 16.04.5] has been updated (20180730.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Xenial 16.04.5] has been updated (20180730.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Xenial 16.04.5] has been updated (20180730.2)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Xenial 16.04.5] has been updated (20180730.2)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Xenial 16.04.5] has been updated (20180730.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Xenial 16.04.5] has been updated (20180730.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Xenial 16.04.5] has been updated (20180730.2)
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop amd64 [Xenial 16.04.5] has been updated (20180730.2)
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop i386 [Xenial 16.04.5] has been updated (20180730.2)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Xenial 16.04.5] has been updated (20180730.2)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Xenial 16.04.5] has been updated (20180730.2)
-queuebot:#ubuntu-release- New binary: r-cran-processx [s390x] (cosmic-proposed/universe) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ar [s390x] (cosmic-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-ros-comm [s390x] (cosmic-proposed/universe) [1.14.2+ds1-5] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dns-parser [ppc64el] (cosmic-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-idna [s390x] (cosmic-proposed/universe) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ar [ppc64el] (cosmic-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-openssl-sys [s390x] (cosmic-proposed/universe) [0.9.33-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dns-parser [s390x] (cosmic-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-extradistr [s390x] (cosmic-proposed/universe) [1.8.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-remove-dir-all [s390x] (cosmic-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-processx [ppc64el] (cosmic-proposed/universe) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-idna [ppc64el] (cosmic-proposed/universe) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tarlz [s390x] (cosmic-proposed/universe) [0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-walkdir [s390x] (cosmic-proposed/universe) [2.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-ros-comm [ppc64el] (cosmic-proposed/universe) [1.14.2+ds1-5] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-openssl-sys [ppc64el] (cosmic-proposed/universe) [0.9.33-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-remove-dir-all [ppc64el] (cosmic-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-extradistr [ppc64el] (cosmic-proposed/universe) [1.8.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-walkdir [ppc64el] (cosmic-proposed/universe) [2.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tarlz [ppc64el] (cosmic-proposed/universe) [0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ar [amd64] (cosmic-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dns-parser [amd64] (cosmic-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ar [i386] (cosmic-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dns-parser [i386] (cosmic-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-idna [i386] (cosmic-proposed/universe) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sha2-asm [amd64] (cosmic-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-idna [amd64] (cosmic-proposed/universe) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand [amd64] (cosmic-proposed/universe) [0.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-openssl-sys [amd64] (cosmic-proposed/universe) [0.9.33-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-remove-dir-all [amd64] (cosmic-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tarlz [i386] (cosmic-proposed/universe) [0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-openssl-sys [i386] (cosmic-proposed/universe) [0.9.33-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-remove-dir-all [i386] (cosmic-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-processx [amd64] (cosmic-proposed/universe) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sha2-asm [i386] (cosmic-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-walkdir [i386] (cosmic-proposed/universe) [2.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-processx [i386] (cosmic-proposed/universe) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-termion [i386] (cosmic-proposed/universe) [1.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-ros-comm [i386] (cosmic-proposed/universe) [1.14.2+ds1-5] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-walkdir [amd64] (cosmic-proposed/universe) [2.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-ros-comm [amd64] (cosmic-proposed/universe) [1.14.2+ds1-5] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-termion [amd64] (cosmic-proposed/universe) [1.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tarlz [amd64] (cosmic-proposed/universe) [0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-extradistr [amd64] (cosmic-proposed/universe) [1.8.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-processx [arm64] (cosmic-proposed/universe) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ar [arm64] (cosmic-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ar [armhf] (cosmic-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-extradistr [i386] (cosmic-proposed/universe) [1.8.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-processx [armhf] (cosmic-proposed/universe) [3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-ros-comm [armhf] (cosmic-proposed/universe) [1.14.2+ds1-5] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dns-parser [arm64] (cosmic-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-ros-comm [arm64] (cosmic-proposed/universe) [1.14.2+ds1-5] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dns-parser [armhf] (cosmic-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-idna [armhf] (cosmic-proposed/universe) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-idna [arm64] (cosmic-proposed/universe) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-extradistr [arm64] (cosmic-proposed/universe) [1.8.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-openssl-sys [armhf] (cosmic-proposed/universe) [0.9.33-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-openssl-sys [arm64] (cosmic-proposed/universe) [0.9.33-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand [arm64] (cosmic-proposed/universe) [0.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-remove-dir-all [arm64] (cosmic-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-extradistr [armhf] (cosmic-proposed/universe) [1.8.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-remove-dir-all [armhf] (cosmic-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-termion [armhf] (cosmic-proposed/universe) [1.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-walkdir [arm64] (cosmic-proposed/universe) [2.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tarlz [arm64] (cosmic-proposed/universe) [0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-walkdir [armhf] (cosmic-proposed/universe) [2.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tarlz [armhf] (cosmic-proposed/universe) [0.4-1] (no packageset)
<tsimonq2> slangasek: Could ovito please be demoted to -proposed?
<tsimonq2> It hasn't been in testing since Jan and it's FTBFS with the latest Qt and ffmpeg.
-queuebot:#ubuntu-release- New: accepted r-cran-extradistr [amd64] (cosmic-proposed) [1.8.9-1]
-queuebot:#ubuntu-release- New: accepted r-cran-extradistr [armhf] (cosmic-proposed) [1.8.9-1]
-queuebot:#ubuntu-release- New: accepted r-cran-extradistr [ppc64el] (cosmic-proposed) [1.8.9-1]
-queuebot:#ubuntu-release- New: accepted r-cran-processx [amd64] (cosmic-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-processx [armhf] (cosmic-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-processx [ppc64el] (cosmic-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted ros-ros-comm [amd64] (cosmic-proposed) [1.14.2+ds1-5]
-queuebot:#ubuntu-release- New: accepted ros-ros-comm [armhf] (cosmic-proposed) [1.14.2+ds1-5]
-queuebot:#ubuntu-release- New: accepted r-cran-extradistr [arm64] (cosmic-proposed) [1.8.9-1]
-queuebot:#ubuntu-release- New: accepted r-cran-extradistr [s390x] (cosmic-proposed) [1.8.9-1]
-queuebot:#ubuntu-release- New: accepted r-cran-processx [i386] (cosmic-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted ros-ros-comm [arm64] (cosmic-proposed) [1.14.2+ds1-5]
-queuebot:#ubuntu-release- New: accepted r-cran-extradistr [i386] (cosmic-proposed) [1.8.9-1]
-queuebot:#ubuntu-release- New: accepted r-cran-processx [s390x] (cosmic-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-processx [arm64] (cosmic-proposed) [3.1.0-1]
-queuebot:#ubuntu-release- New: accepted ros-ros-comm [i386] (cosmic-proposed) [1.14.2+ds1-5]
-queuebot:#ubuntu-release- New: accepted ros-ros-comm [s390x] (cosmic-proposed) [1.14.2+ds1-5]
-queuebot:#ubuntu-release- New: accepted rust-ar [arm64] (cosmic-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ar [i386] (cosmic-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ar [s390x] (cosmic-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-dns-parser [arm64] (cosmic-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-dns-parser [i386] (cosmic-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-dns-parser [s390x] (cosmic-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-idna [arm64] (cosmic-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted rust-idna [i386] (cosmic-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted ros-ros-comm [ppc64el] (cosmic-proposed) [1.14.2+ds1-5]
-queuebot:#ubuntu-release- New: accepted rust-ar [armhf] (cosmic-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-dns-parser [amd64] (cosmic-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-dns-parser [ppc64el] (cosmic-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-idna [armhf] (cosmic-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted rust-idna [s390x] (cosmic-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted rust-ar [amd64] (cosmic-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-dns-parser [armhf] (cosmic-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-idna [ppc64el] (cosmic-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted rust-ar [ppc64el] (cosmic-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-idna [amd64] (cosmic-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted rust-openssl-sys [amd64] (cosmic-proposed) [0.9.33-1]
-queuebot:#ubuntu-release- New: accepted rust-openssl-sys [armhf] (cosmic-proposed) [0.9.33-1]
-queuebot:#ubuntu-release- New: accepted rust-openssl-sys [ppc64el] (cosmic-proposed) [0.9.33-1]
-queuebot:#ubuntu-release- New: accepted rust-remove-dir-all [amd64] (cosmic-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted rust-remove-dir-all [armhf] (cosmic-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted rust-remove-dir-all [ppc64el] (cosmic-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted rust-walkdir [amd64] (cosmic-proposed) [2.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-walkdir [armhf] (cosmic-proposed) [2.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-walkdir [ppc64el] (cosmic-proposed) [2.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-openssl-sys [arm64] (cosmic-proposed) [0.9.33-1]
-queuebot:#ubuntu-release- New: accepted rust-openssl-sys [s390x] (cosmic-proposed) [0.9.33-1]
-queuebot:#ubuntu-release- New: accepted rust-remove-dir-all [i386] (cosmic-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted rust-walkdir [arm64] (cosmic-proposed) [2.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-openssl-sys [i386] (cosmic-proposed) [0.9.33-1]
-queuebot:#ubuntu-release- New: accepted rust-remove-dir-all [s390x] (cosmic-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted rust-remove-dir-all [arm64] (cosmic-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted rust-walkdir [i386] (cosmic-proposed) [2.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-walkdir [s390x] (cosmic-proposed) [2.1.4-1]
-queuebot:#ubuntu-release- New: accepted tarlz [arm64] (cosmic-proposed) [0.4-1]
-queuebot:#ubuntu-release- New: accepted tarlz [i386] (cosmic-proposed) [0.4-1]
-queuebot:#ubuntu-release- New: accepted tarlz [s390x] (cosmic-proposed) [0.4-1]
-queuebot:#ubuntu-release- New: accepted tarlz [amd64] (cosmic-proposed) [0.4-1]
-queuebot:#ubuntu-release- New: accepted tarlz [ppc64el] (cosmic-proposed) [0.4-1]
-queuebot:#ubuntu-release- New: accepted tarlz [armhf] (cosmic-proposed) [0.4-1]
<slangasek> tsimonq2: done
-queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu21.3 => 229-4ubuntu21.4] (core)
<xnox> sil2100, ^
<xnox> http://launchpadlibrarian.net/380890254/systemd_229-4ubuntu21.3_229-4ubuntu21.4.diff.gz
<xnox> or slangasek
<sil2100> Reviewing
<sil2100> All good, accepting
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (xenial-proposed) [229-4ubuntu21.4]
-queuebot:#ubuntu-release- Unapproved: debian-installer (xenial-proposed/main) [20101020ubuntu451.25 => 20101020ubuntu451.26] (core)
<tsimonq2> slangasek: Thank you.
-queuebot:#ubuntu-release- New binary: r-cran-callr [amd64] (cosmic-proposed/universe) [2.0.4-1] (no packageset)
<xnox> uploading \o/
<tsimonq2> slangasek: This is confusing me a little bit... I removed the kdepim-doc transitional package in the latest Cosmic kmail upload, and excuses says it's missing a binary, even though it's migrated before with the QtWebEngine dep.
<tsimonq2> slangasek: Either way, could you please poke?
<tsimonq2> slangasek: ( https://launchpad.net/ubuntu/+source/kmail/4:17.12.3-0ubuntu2 http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kmail for ref)
<slangasek> tsimonq2: yeah, that's non-obvious behavior; because kdepim-doc is arch: all, it's actually published on all architectures, so since the new version in -proposed has no new build on ppc64el and s390x at all, p-m sees that kdepim-doc "should" still be available on these two archs
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (xenial-proposed) [20101020ubuntu451.26]
<slangasek> tsimonq2: I think removing the binary package (which basically just means, unpublishing) on those two archs should be enough to let p-m figure it out from here
<tsimonq2> slangasek: ah, ack, thanks.
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Xenial 16.04.5] has been updated (20101020ubuntu451.26)
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Xenial 16.04.5] has been updated (20101020ubuntu451.26)
-queuebot:#ubuntu-release- Builds: Netboot armhf [Xenial 16.04.5] has been updated (20101020ubuntu451.26)
-queuebot:#ubuntu-release- Builds: Netboot i386 [Xenial 16.04.5] has been updated (20101020ubuntu451.26)
-queuebot:#ubuntu-release- Builds: Netboot powerpc [Xenial 16.04.5] has been updated (20101020ubuntu451.26)
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Xenial 16.04.5] has been updated (20101020ubuntu451.26)
-queuebot:#ubuntu-release- Builds: Netboot s390x [Xenial 16.04.5] has been updated (20101020ubuntu451.26)
-queuebot:#ubuntu-release- New: accepted r-cran-callr [amd64] (cosmic-proposed) [2.0.4-1]
-queuebot:#ubuntu-release- New: accepted rust-rand [arm64] (cosmic-proposed) [0.5.4-1]
-queuebot:#ubuntu-release- New: accepted rust-sha2-asm [i386] (cosmic-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted rust-termion [armhf] (cosmic-proposed) [1.5.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rand [amd64] (cosmic-proposed) [0.5.4-1]
-queuebot:#ubuntu-release- New: accepted rust-termion [amd64] (cosmic-proposed) [1.5.1-1]
-queuebot:#ubuntu-release- New: accepted rust-sha2-asm [amd64] (cosmic-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted rust-termion [i386] (cosmic-proposed) [1.5.1-1]
-queuebot:#ubuntu-release- New: accepted gnome-shell-extension-gsconnect [amd64] (cosmic-proposed) [11+wip2018.07.26-0ubuntu2]
-queuebot:#ubuntu-release- New binary: rust-filetime [amd64] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-filetime [i386] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-filetime [armhf] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-unicode-data [amd64] (cosmic-proposed/universe) [0~20180730+gitca26ee35-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted finalrd [source] (cosmic-proposed) [2]
-queuebot:#ubuntu-release- New: accepted node-unicode-data [amd64] (cosmic-proposed) [0~20180730+gitca26ee35-1]
-queuebot:#ubuntu-release- New: accepted rust-filetime [armhf] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-filetime [amd64] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-filetime [i386] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New binary: finalrd [amd64] (cosmic-proposed/none) [2] (no packageset)
-queuebot:#ubuntu-release- New: accepted finalrd [amd64] (cosmic-proposed) [2]
#ubuntu-release 2018-07-31
<doko> cleaned up ros-ros-common and ros-geometry2 binaries, blocking qt
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Ubuntu Base powerpc [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- New binary: r-cran-pkgbuild [amd64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop amd64 [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop i386 [Xenial 16.04.5] has been updated (20180731)
<tsimonq2> Mythbuntu?
<tsimonq2> That got a 16.04 release?
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Xenial 16.04.5] has been updated (20180731)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Xenial 16.04.5] has been updated (20180731)
<bdmurray> slangasek: I've uploaded glib2.0 to the xenial queue to fix that 14.04 upgrade bug
 * tsimonq2 raises red flags.
<tsimonq2> Found a regression that I had to fix at one point in the Lubuntu images, on the latest Xenial daily.
<tsimonq2> Bug report/fix incoming.
<tsimonq2> tl;dr is "unsafe swap space detected" is a false positive; can't easily find it but I'm still looking.
<tsimonq2> Here we go: https://git.launchpad.net/ubiquity/commit/?id=7778c7f82c37fc4e22e7409fc1ff4a9dc9447bb9
<tsimonq2> C'mon, sil2100 isn't on IRC... ;)
<tsimonq2> Er, I barked up the wrong tree there.
<tsimonq2> bug 1759732
<ubot5> bug 1759732 in partman-crypto (Ubuntu Bionic) "[Lubuntu] Having zram support means that encrypted LVM installs don't work" [Critical,Fix released] https://launchpad.net/bugs/1759732
<tsimonq2> Can a Core Developer please approve my nomination for Xenial?
<tsimonq2> The above bug now has a sponsorable debdiff.
<tsimonq2> I need to go to bed, but if some kind soul could help me out, that would be great :)
<slangasek> bdmurray: reviewing.  are there any other packages that need fixing for this?
<slangasek> tsimonq2: how is that a regression?  Is it specific to the hwe kernel on trusty?
-queuebot:#ubuntu-release- Unapproved: accepted glib2.0 [source] (xenial-proposed) [2.48.2-0ubuntu4]
-queuebot:#ubuntu-release- New binary: libhtml-escape-perl [s390x] (cosmic-proposed/none) [1.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ats2-lang [amd64] (cosmic-proposed/universe) [0.3.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhtml-escape-perl [ppc64el] (cosmic-proposed/universe) [1.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhtml-escape-perl [amd64] (cosmic-proposed/universe) [1.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vanguards [amd64] (cosmic-proposed/universe) [0.1.1+git20180727.67539be-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhtml-escape-perl [i386] (cosmic-proposed/universe) [1.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhtml-escape-perl [arm64] (cosmic-proposed/universe) [1.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libhtml-escape-perl [armhf] (cosmic-proposed/universe) [1.10-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted vanguards [amd64] (cosmic-proposed) [0.1.1+git20180727.67539be-1]
-queuebot:#ubuntu-release- New: accepted ats2-lang [amd64] (cosmic-proposed) [0.3.11-1]
-queuebot:#ubuntu-release- New: accepted libhtml-escape-perl [arm64] (cosmic-proposed) [1.10-1]
-queuebot:#ubuntu-release- New: accepted libhtml-escape-perl [i386] (cosmic-proposed) [1.10-1]
-queuebot:#ubuntu-release- New: accepted libhtml-escape-perl [s390x] (cosmic-proposed) [1.10-1]
-queuebot:#ubuntu-release- New: accepted libhtml-escape-perl [amd64] (cosmic-proposed) [1.10-1]
-queuebot:#ubuntu-release- New: accepted libhtml-escape-perl [ppc64el] (cosmic-proposed) [1.10-1]
-queuebot:#ubuntu-release- New: accepted libhtml-escape-perl [armhf] (cosmic-proposed) [1.10-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pkgbuild [amd64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New binary: ros-geometry2 [amd64] (cosmic-proposed/universe) [0.6.2-6.1~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometry2 [s390x] (cosmic-proposed/universe) [0.6.2-6.1~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometry2 [ppc64el] (cosmic-proposed/universe) [0.6.2-6.1~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometry2 [i386] (cosmic-proposed/universe) [0.6.2-6.1~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometry2 [arm64] (cosmic-proposed/universe) [0.6.2-6.1~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometry2 [armhf] (cosmic-proposed/universe) [0.6.2-6.1~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: dpdk [ppc64el] (cosmic-proposed/main) [17.11.3-3] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: r-cran-pkgload [s390x] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pkgload [amd64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pkgload [ppc64el] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pkgload [arm64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pkgload [i386] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pkgload [armhf] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dpdk [arm64] (cosmic-proposed/main) [17.11.3-3] (kubuntu, ubuntu-desktop, ubuntu-server)
<tjaalton> infinity: ping re: dropping the obsolete x drivers, one month later :)
-queuebot:#ubuntu-release- New binary: dpdk [i386] (cosmic-proposed/main) [17.11.3-3] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: dpdk [amd64] (cosmic-proposed/main) [17.11.3-3] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted ros-geometry2 [amd64] (cosmic-proposed) [0.6.2-6.1~build1]
-queuebot:#ubuntu-release- New: accepted ros-geometry2 [armhf] (cosmic-proposed) [0.6.2-6.1~build1]
-queuebot:#ubuntu-release- New: accepted ros-geometry2 [ppc64el] (cosmic-proposed) [0.6.2-6.1~build1]
-queuebot:#ubuntu-release- New: accepted ros-geometry2 [arm64] (cosmic-proposed) [0.6.2-6.1~build1]
-queuebot:#ubuntu-release- New: accepted ros-geometry2 [s390x] (cosmic-proposed) [0.6.2-6.1~build1]
-queuebot:#ubuntu-release- New: accepted ros-geometry2 [i386] (cosmic-proposed) [0.6.2-6.1~build1]
-queuebot:#ubuntu-release- New: accepted r-cran-pkgload [amd64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pkgload [armhf] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pkgload [ppc64el] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pkgload [arm64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pkgload [s390x] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pkgload [i386] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted dpdk [amd64] (cosmic-proposed) [17.11.3-3]
-queuebot:#ubuntu-release- New: accepted dpdk [i386] (cosmic-proposed) [17.11.3-3]
-queuebot:#ubuntu-release- New: accepted dpdk [arm64] (cosmic-proposed) [17.11.3-3]
-queuebot:#ubuntu-release- New: accepted dpdk [ppc64el] (cosmic-proposed) [17.11.3-3]
<jibel> tsimonq2, I verified the unsafe swap issue and the problem exists since the first release of lubuntu 16.04 including .4. So not a regression
<acheronuk> doko: arch have a ffmpeg4 patch for transcode. https://git.archlinux.org/svntogit/community.git/tree/trunk?h=packages/transcode
<acheronuk> had you been looking at that or similar?
<doko> acheronuk: no
<acheronuk> doko: ok. if no one else does, may try that later if I have time
<acheronuk> thanks
<doko> please do
<acheronuk> doko: ack. hopefully I can get strigi (FTBFS with ffmpeg4) removable from the archive later as well. assuming kde4libs rebuilds and tests ok
<acheronuk> doko: tried, but that patch has too many rejected hunks I'm not sure how to correctly resolve myself :/
-queuebot:#ubuntu-release- New binary: libspatialaudio [s390x] (cosmic-proposed/universe) [0.3.0+git20180730+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpqxx [ppc64el] (cosmic-proposed/universe) [6.2.4-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libspatialaudio [ppc64el] (cosmic-proposed/universe) [0.3.0+git20180730+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpqxx [s390x] (cosmic-proposed/universe) [6.2.4-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libpqxx [amd64] (cosmic-proposed/universe) [6.2.4-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libspatialaudio [i386] (cosmic-proposed/universe) [0.3.0+git20180730+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpqxx [i386] (cosmic-proposed/universe) [6.2.4-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libspatialaudio [amd64] (cosmic-proposed/universe) [0.3.0+git20180730+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libspatialaudio [armhf] (cosmic-proposed/universe) [0.3.0+git20180730+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpqxx [arm64] (cosmic-proposed/universe) [6.2.4-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libspatialaudio [arm64] (cosmic-proposed/universe) [0.3.0+git20180730+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpqxx [armhf] (cosmic-proposed/universe) [6.2.4-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted libpqxx [amd64] (cosmic-proposed) [6.2.4-3]
-queuebot:#ubuntu-release- New: accepted libpqxx [armhf] (cosmic-proposed) [6.2.4-3]
-queuebot:#ubuntu-release- New: accepted libpqxx [ppc64el] (cosmic-proposed) [6.2.4-3]
-queuebot:#ubuntu-release- New: accepted libpqxx [arm64] (cosmic-proposed) [6.2.4-3]
-queuebot:#ubuntu-release- New: accepted libpqxx [s390x] (cosmic-proposed) [6.2.4-3]
-queuebot:#ubuntu-release- New: accepted libpqxx [i386] (cosmic-proposed) [6.2.4-3]
-queuebot:#ubuntu-release- New: accepted libspatialaudio [amd64] (cosmic-proposed) [0.3.0+git20180730+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted libspatialaudio [armhf] (cosmic-proposed) [0.3.0+git20180730+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted libspatialaudio [ppc64el] (cosmic-proposed) [0.3.0+git20180730+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted libspatialaudio [arm64] (cosmic-proposed) [0.3.0+git20180730+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted libspatialaudio [s390x] (cosmic-proposed) [0.3.0+git20180730+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted libspatialaudio [i386] (cosmic-proposed) [0.3.0+git20180730+dfsg1-1]
<cascardo> hey, I have a crash upload sitting on the bionic-proposed unapproved queue
<cascardo> any progress there is appreciated  :-)
<tsimonq2> slangasek, jibel: Fine, not a *regression*, but still a release critical bug in my opinion.
<jibel> tsimonq2, it's been there since .0 and there is a simple workaround by disabling swap before installation
-queuebot:#ubuntu-release- New binary: bind9 [s390x] (cosmic-proposed/main) [1:9.11.4+dfsg-3ubuntu1] (core)
<tsimonq2> jibel: Which is out of the question for people who choose "Install Lubuntu" on boot.
-queuebot:#ubuntu-release- New binary: bind9 [ppc64el] (cosmic-proposed/main) [1:9.11.4+dfsg-3ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: ubiquity (xenial-proposed/main) [2.21.63.7 => 2.21.63.8] (core)
-queuebot:#ubuntu-release- New binary: bind9 [i386] (cosmic-proposed/main) [1:9.11.4+dfsg-3ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: bind9 [amd64] (cosmic-proposed/main) [1:9.11.4+dfsg-3ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: bind9 [armhf] (cosmic-proposed/main) [1:9.11.4+dfsg-3ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: bind9 [arm64] (cosmic-proposed/main) [1:9.11.4+dfsg-3ubuntu1] (core)
<sil2100> RAOF[m], rbasak: for today and tomorrow - remember that we're basically working on xenial .5 right now so please do not release anything into xenial-updates this week
<rbasak> ack
-queuebot:#ubuntu-release- Unapproved: evolution-data-server (bionic-proposed/main) [3.28.3-0ubuntu0.18.04.1 => 3.28.5-0ubuntu0.18.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: evolution (bionic-proposed/universe) [3.28.1-2 => 3.28.5-0ubuntu0.18.04.1] (ubuntukylin)
<bdmurray> slangasek: I didn't find any other packages that needed a Pre-Depends for dpkg in the SRUs that we did. I also did a bug search of foundations packages and didn't find any there either. I'm still looking though.
<bdmurray> slangasek: I've verified the glib2.0 16.04 SRU
<sil2100> No publishing please!
<sil2100> I didn't snapshot the archive yet
<slangasek> tsimonq2: the .5 point release is an SRU roll-up that's meant to give users install media that includes the final hwe stack for the series.  You have the discretion as flavor lead to opt not to participate in the point release; you don't have the discretion to hold up the .5 timeline for a non-regression bug
<slangasek> sil2100: ^^
<tsimonq2> Do I have the discretion to delay the point release for Lubuntu only? So, release all other flavors, then respin immediately after and release on Monday?
<tsimonq2> slangasek: ^
<tsimonq2> If so, I opt for that.
-queuebot:#ubuntu-release- Unapproved: bcmwl (xenial-proposed/restricted) [6.30.223.271+bdcom-0ubuntu1~1.3 => 6.30.223.271+bdcom-0ubuntu1~1.3] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: bcmwl (xenial-updates/restricted) [6.30.223.271+bdcom-0ubuntu1~1.3 => 6.30.223.271+bdcom-0ubuntu1~1.2] (kubuntu, ubuntu-desktop) (sync)
<sil2100> Not sure if that's feasible, what we release should be in the snapshot we do for a given point-release which means all images should have the same set of changes
<sil2100> For common packages
<tsimonq2> Well, if further SRU releases on Thursday are delayed the hour or two for Lubuntu to respin, I'm fine with taking the chance that it will be the final spin to release.
<tsimonq2> So, it should be no different.
<tsimonq2> If I'm forced to choose between releasing on Thursday and not releasing though, I guess I'll release, but I won't be particularly happy about it, especially because I have a patch in hand.
<slangasek> this requires changes to a udeb that's in every image; we won't allow skew between flavors in a point release because of the snapshotting question, and we won't respin all images for a non-regression
<tsimonq2> So I guess my only option is to release as-is, isn't it? :/
-queuebot:#ubuntu-release- Unapproved: chromium-browser (xenial-updates/universe) [68.0.3440.75-0ubuntu0.16.04.1 => 67.0.3396.99-0ubuntu0.16.04.2] (ubuntu-desktop) (sync)
<tsimonq2> If we need a global respin for any other reason, please ping me...
<sil2100> tsimonq2: yeah, sorry about that - I know it would be good to have the bug fixed but there was really a lot of time to get it done
<tsimonq2> :( ok
<sil2100> It's on my for-respin list for sure
<tsimonq2> Thanks.
-queuebot:#ubuntu-release- Unapproved: accepted bcmwl [sync] (xenial-updates) [6.30.223.271+bdcom-0ubuntu1~1.2]
-queuebot:#ubuntu-release- Unapproved: accepted chromium-browser [sync] (xenial-updates) [67.0.3396.99-0ubuntu0.16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted bcmwl [sync] (xenial-proposed) [6.30.223.271+bdcom-0ubuntu1~1.3]
<tsimonq2> sil2100: Heck, I'd even be willing to do Lubuntu 16.04.5.1...
<sil2100> ;)
<tsimonq2> Â¯\_(ã)_/Â¯
-queuebot:#ubuntu-release- New binary: openstack-cluster-installer [amd64] (cosmic-proposed/universe) [2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-globset [s390x] (cosmic-proposed/none) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-url [s390x] (cosmic-proposed/universe) [1.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-globset [ppc64el] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-url [ppc64el] (cosmic-proposed/universe) [1.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-avast-retry-go [amd64] (cosmic-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-atty [amd64] (cosmic-proposed/universe) [0.2.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-atty [i386] (cosmic-proposed/universe) [0.2.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-chrono [i386] (cosmic-proposed/universe) [0.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tar [amd64] (cosmic-proposed/universe) [0.4.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-globset [i386] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tempfile [amd64] (cosmic-proposed/universe) [3.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tar [i386] (cosmic-proposed/universe) [0.4.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-chrono [amd64] (cosmic-proposed/universe) [0.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-url [amd64] (cosmic-proposed/universe) [1.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-globset [amd64] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-atty [armhf] (cosmic-proposed/universe) [0.2.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-url [i386] (cosmic-proposed/universe) [1.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-chrono [armhf] (cosmic-proposed/universe) [0.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-globset [arm64] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-globset [armhf] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tar [armhf] (cosmic-proposed/universe) [0.4.16-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-url [arm64] (cosmic-proposed/universe) [1.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-url [armhf] (cosmic-proposed/universe) [1.7.1-1] (no packageset)
<ahasenack> why is the bind9 status in migration still "missing binary"? It's been built for 4h now.
<ahasenack> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#bind9
-queuebot:#ubuntu-release- Unapproved: catfish (bionic-proposed/universe) [1.4.4-1 => 1.4.6-0ubuntu0.18.04.1] (ubuntustudio, xubuntu)
<ahasenack> is it because the soname changed, and some packages became "new"?
<ginggs> ahasenack: yup
<ginggs> see bottom of https://launchpad.net/ubuntu/+source/bind9/1:9.11.4+dfsg-3ubuntu1
<ginggs> ahasenack: and https://launchpad.net/ubuntu/cosmic/+queue?queue_state=0
<ahasenack> that changelog looks wrong, it's like the whole history of the package
<ahasenack> probably the wrong -v was used when preparing the changes file
<ginggs> ahasenack: it's a thrilling read!
<ahasenack> except I did just the tip :)
<ahasenack> I'll rebuild isc-dhcp in a ppa with that bind candidate
<ahasenack> it's an rdep
-queuebot:#ubuntu-release- New: accepted rust-atty [armhf] (cosmic-proposed) [0.2.11-1]
-queuebot:#ubuntu-release- New: accepted rust-globset [amd64] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-globset [armhf] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-url [arm64] (cosmic-proposed) [1.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-url [i386] (cosmic-proposed) [1.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-chrono [armhf] (cosmic-proposed) [0.4.5-1]
-queuebot:#ubuntu-release- New: accepted rust-tar [armhf] (cosmic-proposed) [0.4.16-1]
-queuebot:#ubuntu-release- New: accepted rust-globset [arm64] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-url [armhf] (cosmic-proposed) [1.7.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-avast-retry-go [amd64] (cosmic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-atty [amd64] (cosmic-proposed) [0.2.11-1]
-queuebot:#ubuntu-release- New: accepted rust-chrono [amd64] (cosmic-proposed) [0.4.5-1]
-queuebot:#ubuntu-release- New: accepted rust-globset [i386] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-globset [s390x] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-tar [i386] (cosmic-proposed) [0.4.16-1]
-queuebot:#ubuntu-release- New: accepted rust-url [amd64] (cosmic-proposed) [1.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-url [s390x] (cosmic-proposed) [1.7.1-1]
-queuebot:#ubuntu-release- New: accepted openstack-cluster-installer [amd64] (cosmic-proposed) [2]
-queuebot:#ubuntu-release- New: accepted rust-chrono [i386] (cosmic-proposed) [0.4.5-1]
-queuebot:#ubuntu-release- New: accepted rust-tar [amd64] (cosmic-proposed) [0.4.16-1]
-queuebot:#ubuntu-release- New: accepted rust-url [ppc64el] (cosmic-proposed) [1.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-atty [i386] (cosmic-proposed) [0.2.11-1]
-queuebot:#ubuntu-release- New: accepted rust-tempfile [amd64] (cosmic-proposed) [3.0.3-1]
-queuebot:#ubuntu-release- New: accepted rust-globset [ppc64el] (cosmic-proposed) [0.4.1-1]
<ahasenack> hi, could an archive admin take a look at the bind9 upload when able? The soname of libdns got bumped. isc-dhcp is the only rdepends, and it builds fine with the new bind
<ahasenack> ppa: https://launchpad.net/~ahasenack/+archive/ubuntu/bind-merge-9.11.4/+packages
<ahasenack> and some tests I did: upgrading cosmic's bind/isc to the ppa builds: https://pastebin.ubuntu.com/p/q6skHdzpB3/
<ahasenack> and upgrading just bind, leaving isc-dhcp without a rebuild, also works: https://pastebin.ubuntu.com/p/zkw8nzryYV/
-queuebot:#ubuntu-release- New: accepted bind9 [amd64] (cosmic-proposed) [1:9.11.4+dfsg-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted bind9 [armhf] (cosmic-proposed) [1:9.11.4+dfsg-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted bind9 [ppc64el] (cosmic-proposed) [1:9.11.4+dfsg-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted bind9 [arm64] (cosmic-proposed) [1:9.11.4+dfsg-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted bind9 [s390x] (cosmic-proposed) [1:9.11.4+dfsg-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted bind9 [i386] (cosmic-proposed) [1:9.11.4+dfsg-3ubuntu1]
<ahasenack> thanks!
-queuebot:#ubuntu-release- Unapproved: console-setup (bionic-proposed/main) [1.178ubuntu2.3 => 1.178ubuntu2.4] (core)
<infinity> bdmurray: ^-- We probably want this before meta-release-lts flips.
<slangasek> ok wtf why do my uploads of scilab 6.0.1-4ubuntu1 keep getting rejected without any email notification?
<infinity> slangasek: Unsigned?
<slangasek> infinity: nope
<slangasek> infinity: (even if I were that dumb, which I am, dput is not)
<infinity> slangasek: Curiously, I see a reject on the 18th for scilab_6.0.1-1ubuntu2.dsc, as well as two today for scilab_6.0.1-4ubuntu1.dsc
<infinity> I wonder if there's something just inherently broken with scilab. :P
<bdmurray> infinity: okay, I'm not sure that gnome-menus / libc6 ordering change is going to be quick
<infinity> bdmurray: That's unfortunate.
<bdmurray> infinity: Aren't you physically close to julian?
<infinity> bdmurray: Yes, but it's also 3am.
<infinity> bdmurray: And tomorrow, he'll be off day tripping.
<bdmurray> Ah, well then.
<ahasenack> hi, for the ocfs2-tools s390x test failure, here is a badtest mp to update the pkg version of the existing hint: https://code.launchpad.net/~ahasenack/britney/ocfs2-tools-hints-1.8.5-5ubuntu1/+merge/351928
<infinity> slangasek: So, according to the logs, both your uploads were rejected silently for "No public key".  Meaning either something went goofy with the lp<->keyserver connectivity, or you used the wrong key.
<slangasek> uhm
<slangasek> I have only one key online
<infinity> slangasek: Quite possibly the former.
<infinity> slangasek: Okay, it hated that one too.
<infinity> slangasek: And you seem to be the only person it hates today.
<infinity> slangasek: So, I'm not buying lp<->keyserver outage.
<slangasek> >_<
<slangasek> my key has not changed
<infinity> gpg: Signature made Tue Jul 31 15:03:10 2018 UTC using RSA key ID 21B2133D
<infinity> That's very much not the key you have registered in LP.
<infinity> Just sayin'.
<slangasek> infinity: it's the subkey which is always the one being used
<infinity> Oh, hah.
<infinity> gpg: requesting key 21B2133D from hkp server keyserver.internal
<infinity> gpg: mpi too large for this implementation (32492 bits)
<infinity> gpg: read_block: read error: invalid packet
<slangasek> ...
<infinity> That's some solid behaviour.
<infinity> I think this is the part where you go whine in #is
<infinity> While I get some sleep.
<stgraber> IS switched keyservers yesterday evening I believe
<stgraber> I remember seeing a discussion with wgrant about switching keyserver.internal to the new machine (and implementation?), so that'd explain it
-queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [18.3-9-g2e62cb8a-0ubuntu1~18.04.1 => 18.3-9-g2e62cb8a-0ubuntu1~18.04.2] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [18.3-9-g2e62cb8a-0ubuntu1~16.04.1 => 18.3-9-g2e62cb8a-0ubuntu1~16.04.2] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ipmitool (xenial-proposed/universe) [1.8.16-3ubuntu0.1 => 1.8.16-3ubuntu0.2] (no packageset)
<blackboxsw> RAOF[m]: we have a regression-proposed fix uploaded as unapproved for cloud-init's current SRU into xenial and bionic  we are hoping to replace the -proposed with 18.3-9-g2e62cb8a-0ubuntu1~16.04.2.... and I guess dropping the SRU into artful-proposed as it is now end of life.
-queuebot:#ubuntu-release- Unapproved: freshplayerplugin (xenial-proposed/multiverse) [0.3.4-3ubuntu0.1 => 0.3.9-0ubuntu0~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: freshplayerplugin (bionic-proposed/multiverse) [0.3.5-1ubuntu7 => 0.3.9-0ubuntu1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-jira [amd64] (cosmic-proposed/universe) [1.0.10-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-filepath [amd64] (cosmic-proposed/universe) [0.7-1] (no packageset)
#ubuntu-release 2018-08-01
<RAOF[m]> 406279
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [18.3-9-g2e62cb8a-0ubuntu1~16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (bionic-proposed) [18.3-9-g2e62cb8a-0ubuntu1~18.04.2]
<blackboxsw> much thanks
<blackboxsw> RAOF[m]: what's the [m] mean? (for future reference)
<blackboxsw> hadn't seen that suffix before
<RAOF[m]> blackboxsw: It means I haven't quite got the Matrix bridge to set my correct nick yet :)
<blackboxsw> ha!
 * blackboxsw was guessing "mobile" or "moderator"
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-settings [source] (bionic-proposed) [18.04.6]
<_hc> rbasak:
<_hc> circling back about fdroidserver SRU for bionic https://bugs.launchpad.net/ubuntu/+source/fdroidserver/+bug/1758196
<ubot5> Ubuntu bug 1758196 in fdroidserver (Ubuntu) "[SRU] backport fdroidserver 1.0.9-1 from cosmic to bionic" [Undecided,Confirmed]
<_hc> it has a debdiff with the changelog-only change for bionic, from cosmic/testing
<_hc> I didn't see a way for me to upload that to bionic-proposed as a DD, I have no official Ubuntu status
<rbasak> _hc: o/
<rbasak> _hc: I'm only supposed to either sponsor or SRU-review but not both. So we need to find someone else who can sponsor. I've been asking in #ubuntu-motu but haven't found anyone yet :-/
<_hc> o/
<rbasak> It's on my list though.
<_hc> I see, thanks!
<_hc> interesting to see how different the Ubuntu workflow is from Debian
<rbasak> _hc: as a DD you should be able to get upload access for your packages in Ubuntu without too much difficulty if you're interested.
<_hc> interesting, yeah, sure
<rbasak> _hc: not quite as I remembered it, sorry: https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess#Debian_Developers_applying_for_Per-Package_upload_rights
<rbasak> For the first package you need to ask for PPU rights
<rbasak> (which is a standard Ubuntu thing, not special for DDs; I guess the reason is because you need to be aware of Ubuntu release processes etc)
<rbasak> _hc: but if you're interested, we do try to encourage DDs taking care of their packages in Ubuntu directly as much as possible.
<_hc> one of these days, I'll find the time to do the PPU process, can't happen right now tho
<apw> _hc, a quick look says your version number is suspect, as that would be higher than cosmic, 1.0.9-1~18.04.1 would be fine i think
<rbasak> np. It's on my plate to find you a sponsor and get this landed
<_hc> apw: ok, changing now
<_hc> thanks
<_hc> done
-queuebot:#ubuntu-release- Unapproved: fdroidserver (bionic-proposed/universe) [1.0.2-1 => 1.0.9-1~18.04.1] (no packageset)
<rbasak> ^ thanks for sponsoring. I'll SRU-review this now.
<apw> rbasak, ping me if you have trouble
<rbasak> ack
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: accepted fdroidserver [source] (bionic-proposed) [1.0.9-1~18.04.1]
<rbasak> _hc, apw: ^ thanks
<rbasak> _hc: to set expectations for the future, please note that microrelease has a specific meaning for Ubuntu according to https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases "If all of the changes are appropriate for an SRU by the criteria above" so this won't necessarily be possible in the future unless you continue to be careful about the specific upstream changes that land.
<rbasak> (bugfixes are fine; feature changes need to go through a different process; just because upstream classify something as a bugfix and not a feature by putting it into a microrelease doesn't mean that Ubuntu will concur)
<ahasenack> hi, could someone please force badtest ocfs2-tools: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ocfs2-tools
<ahasenack> here is the mp: https://code.launchpad.net/~ahasenack/britney/ocfs2-tools-hints-1.8.5-5ubuntu1/+merge/351928
<ahasenack> with the reasoning
<LocutusOfBorg> apw, please point 3? :)
-queuebot:#ubuntu-release- New binary: ros-actionlib [amd64] (cosmic-proposed/universe) [1.11.14-3ubuntu1] (no packageset)
<_hc> thanks for the review and getting fdroidserver to the next step!  I'll test it once the build lands.
<_hc> in terms of the microreleases, I've been doing those with my Debian hat on, I imagine the criteria are similar
<_hc> basically, i've been finding new mass test cases, then fixing bugs from that process.  It is amazing how many crazy things people do when building Android APKs
<_hc> and we've got to parse it all
<infinity> _hc: s/ when building Android APKs//
<infinity> _hc: If there's a way to break software, humans will find it.  And developers will find it twice as fast.
<infinity> I miss the days where "don't do that, then" was considered a reasonable response to a bug report. :P
<tsimonq2> sil2100: Are you on debconf time or western world time?
<tsimonq2> The international date line means that you could be almost a day ahead of me. :P
<Trevinho> sil2100: hey, although you added me to the group for managing ci-ppa, it looks like i cant push sources there... ("The signer of this package has no upload rights to this distribution's primary archive"), which is true... but I thought that it would mean getting sponsored at publish time no?
<tsimonq2> Trevinho: Do you have a copy of the email? (I assume you used dput.)
<tsimonq2> Are you in ~ubuntu-dev otherwise?
<Trevinho> tsimonq2: I'm not there in fact, but at the same time I think I was mistyping the cmd (no setting the PPA url :-D)
<Trevinho> thus was correct... and sorry for bothering :)
<sil2100> ;)
<sil2100> tsimonq2: I'm on my regular EU timezone, sometimes slightly moved towards the US one because of the point-release
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base powerpc [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Xenial 16.04.5] has been marked as ready
<tsimonq2> sil2100: Ah. I didn't think EU people moved to a US timezone for point releases, only the other way around.
<infinity> tsimonq2: People do whatever they need to do to get things done, there's no formal process.
<infinity> (usually when I'm driving, the process is "don't sleep")
 * apw worries for the lamppost
<tsimonq2> infinity: Ah, makes sense.
<sil2100> Yeah, no process for that, just staying around to get things done
<keepguessing> I do not see Bionic listed here. http://changelogs.ubuntu.com/meta-release-lts
<keepguessing> when would it be available. Is there some bug/issue blocking it?
<infinity> keepguessing: There are a couple of things still being worked on to make sure the upgrade is as smooth as it can be.
<keepguessing> infinity: can you point me to the issues or a way to track this?
<infinity> keepguessing: Not sure there's a public bug to track the ubuntu-release-upgrader work in progress.  But it'll be ready when it's ready.
<keepguessing> infinity: ok thanks.
-queuebot:#ubuntu-release- New binary: golang-github-graph-gophers-graphql-go [amd64] (cosmic-proposed/universe) [0.0~git20180609.bb97385-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-matryer-is [amd64] (cosmic-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicase [ppc64el] (cosmic-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zhcon [amd64] (cosmic-proposed/universe) [1:0.2.6-13] (no packageset)
-queuebot:#ubuntu-release- New binary: puppet-module-puppetlabs-haproxy [amd64] (cosmic-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicase [s390x] (cosmic-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbson-xs-perl [ppc64el] (cosmic-proposed/universe) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicase [amd64] (cosmic-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicase [i386] (cosmic-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbson-xs-perl [i386] (cosmic-proposed/universe) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-pzhin-go-sophia [amd64] (cosmic-proposed/universe) [0.0~git20180715.8bdc218-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbson-xs-perl [amd64] (cosmic-proposed/universe) [0.4.3-1] (no packageset)
<ahasenack> hi, my bind9 upload, which bumped the soname, also needs a debian-installer rebuild (ppa at https://launchpad.net/~ahasenack/+archive/ubuntu/bind-merge-9.11.4/+packages). Would someone sponsor this for me? https://pastebin.ubuntu.com/p/HPVtSzkPK7/
-queuebot:#ubuntu-release- New binary: rust-unicase [arm64] (cosmic-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbson-xs-perl [arm64] (cosmic-proposed/universe) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicase [armhf] (cosmic-proposed/universe) [2.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbson-xs-perl [armhf] (cosmic-proposed/universe) [0.4.3-1] (no packageset)
<blackboxsw> infinity: do you know if I remove regression-proposed tag on an SRU process bug once I've validated and provided verification-done-<series> tags?
<blackboxsw> or do I leave the regression-proposed tag in place even though all verification is now done?
<blackboxsw> namely on this bug https://bugs.launchpad.net/cloud-init/+bug/1784685
<ubot5> Ubuntu bug 1784685 in cloud-init "Oracle: cloud-init openstack local detection too strict for oracle cloud" [High,Fix committed]
<rbasak> blackboxsw: AIUI, regression-proposed is for a new bug filed against a package in -proposed reporting a regression. The original tracking bug would just be verification-failed, which would get removed when the SRU replacement lands in -proposed. The extra regression-proposed bug would get marked Fix Committed/Released, but would never be untagged since the bug was for something that had regressed
<rbasak> in proposed. But no need to file a separate bug just for the sake of it. Only if someone actually wants to report it somewhere, etc.
-queuebot:#ubuntu-release- Unapproved: maas (xenial-proposed/main) [2.3.0-6434-gd354690-0ubuntu1~16.04.1 => 2.3.4-6508-g4f77e30-0ubuntu1] (ubuntu-server)
<ginggs> ahasenack: debian-installer sponsored
<ahasenack> ginggs: thanks a lot
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-terminal [source] (bionic-proposed) [0.8.7.4-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (bionic-proposed) [3.28.1-0ubuntu4.18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-menus [source] (bionic-proposed) [3.13.3-11ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted lttng-modules [source] (bionic-proposed) [2.10.5-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted aodh [source] (bionic-proposed) [6.0.1-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (bionic-proposed) [3.28.3-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected gnome-shell [source] (bionic-proposed) [3.28.3-0ubuntu0.18.04.2]
-queuebot:#ubuntu-release- New binary: libqaccessibilityclient [s390x] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libqaccessibilityclient [ppc64el] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-pzhin-go-sophia [amd64] (cosmic-proposed/universe) [0.0~git20180715.8bdc218-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libqaccessibilityclient [i386] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libqaccessibilityclient [amd64] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-python-qt-binding [amd64] (cosmic-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vulkan-headers [amd64] (cosmic-proposed/universe) [1.1.77-1] (no packageset)
-queuebot:#ubuntu-release- New binary: yaha [i386] (cosmic-proposed/universe) [0.1.83-1] (no packageset)
-queuebot:#ubuntu-release- New binary: yaha [amd64] (cosmic-proposed/universe) [0.1.83-1] (no packageset)
-queuebot:#ubuntu-release- New binary: yaha [s390x] (cosmic-proposed/universe) [0.1.83-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-shinythemes [amd64] (cosmic-proposed/universe) [1.1.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: isc-kea [s390x] (cosmic-proposed/universe) [1.4.0.P1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: suitesparse [s390x] (cosmic-proposed/main) [1:5.3.0+dfsg-1] (edubuntu, kubuntu, ubuntu-desktop, ubuntugnome)
-queuebot:#ubuntu-release- New binary: yaha [ppc64el] (cosmic-proposed/universe) [0.1.83-1] (no packageset)
-queuebot:#ubuntu-release- New binary: isc-kea [ppc64el] (cosmic-proposed/universe) [1.4.0.P1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: suitesparse [ppc64el] (cosmic-proposed/main) [1:5.3.0+dfsg-1] (edubuntu, kubuntu, ubuntu-desktop, ubuntugnome)
-queuebot:#ubuntu-release- New binary: suitesparse [amd64] (cosmic-proposed/main) [1:5.3.0+dfsg-1] (edubuntu, kubuntu, ubuntu-desktop, ubuntugnome)
-queuebot:#ubuntu-release- New binary: pari [s390x] (cosmic-proposed/universe) [2.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: isc-kea [amd64] (cosmic-proposed/universe) [1.4.0.P1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: pari [ppc64el] (cosmic-proposed/universe) [2.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libqaccessibilityclient [arm64] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libqaccessibilityclient [armhf] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pari [amd64] (cosmic-proposed/universe) [2.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: suitesparse [arm64] (cosmic-proposed/main) [1:5.3.0+dfsg-1] (edubuntu, kubuntu, ubuntu-desktop, ubuntugnome)
-queuebot:#ubuntu-release- New binary: suitesparse [armhf] (cosmic-proposed/main) [1:5.3.0+dfsg-1] (edubuntu, kubuntu, ubuntu-desktop, ubuntugnome)
-queuebot:#ubuntu-release- New binary: isc-kea [i386] (cosmic-proposed/universe) [1.4.0.P1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: pari [i386] (cosmic-proposed/universe) [2.11.0-1] (no packageset)
#ubuntu-release 2018-08-02
-queuebot:#ubuntu-release- New binary: suitesparse [i386] (cosmic-proposed/main) [1:5.3.0+dfsg-1] (edubuntu, kubuntu, ubuntu-desktop, ubuntugnome)
-queuebot:#ubuntu-release- New binary: isc-kea [armhf] (cosmic-proposed/universe) [1.4.0.P1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: isc-kea [arm64] (cosmic-proposed/universe) [1.4.0.P1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: yaha [arm64] (cosmic-proposed/universe) [0.1.83-1] (no packageset)
-queuebot:#ubuntu-release- New binary: yaha [armhf] (cosmic-proposed/universe) [0.1.83-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pari [arm64] (cosmic-proposed/universe) [2.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pari [armhf] (cosmic-proposed/universe) [2.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pari [amd64] (cosmic-proposed) [2.11.0-1]
-queuebot:#ubuntu-release- New: accepted pari [armhf] (cosmic-proposed) [2.11.0-1]
-queuebot:#ubuntu-release- New: accepted pari [ppc64el] (cosmic-proposed) [2.11.0-1]
-queuebot:#ubuntu-release- New: accepted pari [arm64] (cosmic-proposed) [2.11.0-1]
-queuebot:#ubuntu-release- New: accepted pari [s390x] (cosmic-proposed) [2.11.0-1]
-queuebot:#ubuntu-release- New: accepted pari [i386] (cosmic-proposed) [2.11.0-1]
-queuebot:#ubuntu-release- New: accepted isc-kea [amd64] (cosmic-proposed) [1.4.0.P1-3]
-queuebot:#ubuntu-release- New: accepted isc-kea [armhf] (cosmic-proposed) [1.4.0.P1-3]
-queuebot:#ubuntu-release- New: accepted isc-kea [ppc64el] (cosmic-proposed) [1.4.0.P1-3]
-queuebot:#ubuntu-release- New: accepted isc-kea [arm64] (cosmic-proposed) [1.4.0.P1-3]
-queuebot:#ubuntu-release- New: accepted isc-kea [s390x] (cosmic-proposed) [1.4.0.P1-3]
-queuebot:#ubuntu-release- New: accepted isc-kea [i386] (cosmic-proposed) [1.4.0.P1-3]
-queuebot:#ubuntu-release- New: accepted yaha [amd64] (cosmic-proposed) [0.1.83-1]
-queuebot:#ubuntu-release- New: accepted yaha [armhf] (cosmic-proposed) [0.1.83-1]
-queuebot:#ubuntu-release- New: accepted yaha [ppc64el] (cosmic-proposed) [0.1.83-1]
-queuebot:#ubuntu-release- New: accepted yaha [arm64] (cosmic-proposed) [0.1.83-1]
-queuebot:#ubuntu-release- New: accepted yaha [s390x] (cosmic-proposed) [0.1.83-1]
-queuebot:#ubuntu-release- New: accepted yaha [i386] (cosmic-proposed) [0.1.83-1]
-queuebot:#ubuntu-release- New: accepted suitesparse [amd64] (cosmic-proposed) [1:5.3.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted suitesparse [armhf] (cosmic-proposed) [1:5.3.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted suitesparse [ppc64el] (cosmic-proposed) [1:5.3.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted suitesparse [arm64] (cosmic-proposed) [1:5.3.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted suitesparse [s390x] (cosmic-proposed) [1:5.3.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted suitesparse [i386] (cosmic-proposed) [1:5.3.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-shinythemes [amd64] (cosmic-proposed) [1.1.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted vulkan-headers [amd64] (cosmic-proposed) [1.1.77-1]
-queuebot:#ubuntu-release- New: accepted ros-python-qt-binding [amd64] (cosmic-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted python-jira [amd64] (cosmic-proposed) [1.0.10-2]
-queuebot:#ubuntu-release- New: accepted libqaccessibilityclient [amd64] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted libqaccessibilityclient [armhf] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted libqaccessibilityclient [ppc64el] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted libqaccessibilityclient [arm64] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted libqaccessibilityclient [s390x] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted libqaccessibilityclient [i386] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted libbson-xs-perl [amd64] (cosmic-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted libbson-xs-perl [armhf] (cosmic-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted libbson-xs-perl [ppc64el] (cosmic-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted libbson-xs-perl [arm64] (cosmic-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted libbson-xs-perl [i386] (cosmic-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted golang-github-graph-gophers-graphql-go [amd64] (cosmic-proposed) [0.0~git20180609.bb97385-2]
-queuebot:#ubuntu-release- New: accepted golang-github-pzhin-go-sophia [amd64] (cosmic-proposed) [0.0~git20180715.8bdc218-1]
-queuebot:#ubuntu-release- New: accepted puppet-module-puppetlabs-haproxy [amd64] (cosmic-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-filepath [amd64] (cosmic-proposed) [0.7-1]
-queuebot:#ubuntu-release- New: accepted rust-unicase [arm64] (cosmic-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-unicase [i386] (cosmic-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-unicase [s390x] (cosmic-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-matryer-is [amd64] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted ros-actionlib [amd64] (cosmic-proposed) [1.11.14-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted rust-unicase [armhf] (cosmic-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted zhcon [amd64] (cosmic-proposed) [1:0.2.6-13]
-queuebot:#ubuntu-release- New: accepted golang-github-pzhin-go-sophia [amd64] (cosmic-proposed) [0.0~git20180715.8bdc218-2]
-queuebot:#ubuntu-release- New: accepted rust-unicase [ppc64el] (cosmic-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-unicase [amd64] (cosmic-proposed) [2.1.0-1]
-queuebot:#ubuntu-release- New binary: golang-github-machinebox-graphql [amd64] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-machinebox-graphql [amd64] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted ipmitool [source] (xenial-proposed) [1.8.16-3ubuntu0.2]
-queuebot:#ubuntu-release- Unapproved: accepted console-setup [source] (bionic-proposed) [1.178ubuntu2.4]
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot i386 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- New binary: libxcrypt [s390x] (cosmic-proposed/universe) [1:4.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libxcrypt [amd64] (cosmic-proposed/universe) [1:4.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libxcrypt [ppc64el] (cosmic-proposed/universe) [1:4.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libxcrypt [i386] (cosmic-proposed/universe) [1:4.1.1-1] (no packageset)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- New binary: libxcrypt [arm64] (cosmic-proposed/universe) [1:4.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libxcrypt [armhf] (cosmic-proposed/universe) [1:4.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libxcrypt [amd64] (cosmic-proposed) [1:4.1.1-1]
-queuebot:#ubuntu-release- New: accepted libxcrypt [armhf] (cosmic-proposed) [1:4.1.1-1]
-queuebot:#ubuntu-release- New: accepted libxcrypt [ppc64el] (cosmic-proposed) [1:4.1.1-1]
-queuebot:#ubuntu-release- New: accepted libxcrypt [arm64] (cosmic-proposed) [1:4.1.1-1]
-queuebot:#ubuntu-release- New: accepted libxcrypt [s390x] (cosmic-proposed) [1:4.1.1-1]
-queuebot:#ubuntu-release- New: accepted libxcrypt [i386] (cosmic-proposed) [1:4.1.1-1]
-queuebot:#ubuntu-release- New binary: mutter [s390x] (cosmic-proposed/main) [3.29.90-1] (desktop-extra, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mutter [ppc64el] (cosmic-proposed/main) [3.29.90-1] (desktop-extra, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mutter [i386] (cosmic-proposed/main) [3.29.90-1] (desktop-extra, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mutter [amd64] (cosmic-proposed/main) [3.29.90-1] (desktop-extra, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mutter [armhf] (cosmic-proposed/main) [3.29.90-1] (desktop-extra, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mutter [arm64] (cosmic-proposed/main) [3.29.90-1] (desktop-extra, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted mutter [amd64] (cosmic-proposed) [3.29.90-1]
-queuebot:#ubuntu-release- New: accepted mutter [armhf] (cosmic-proposed) [3.29.90-1]
-queuebot:#ubuntu-release- New: accepted mutter [ppc64el] (cosmic-proposed) [3.29.90-1]
-queuebot:#ubuntu-release- New: accepted mutter [arm64] (cosmic-proposed) [3.29.90-1]
-queuebot:#ubuntu-release- New: accepted mutter [s390x] (cosmic-proposed) [3.29.90-1]
-queuebot:#ubuntu-release- New: accepted mutter [i386] (cosmic-proposed) [3.29.90-1]
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Xenial 16.04.5] has been marked as ready
<sil2100> Flavours! Please mark your 16.04.5 isos as ready in the isotracker o/
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop amd64 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Mythbuntu Desktop i386 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot armhf [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot powerpc [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Netboot s390x [Xenial 16.04.5] has been marked as ready
<sil2100> Wimpress: hey! Can I mark MATE as ready?
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Xenial 16.04.5] has been marked as ready
<sil2100> ...all mandatory tests are green, so assuming ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Xenial 16.04.5] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Xenial 16.04.5] has been marked as ready
<sil2100> Preparing for .5 release
<sil2100> ...publishing ongoing
-queuebot:#ubuntu-release- Unapproved: gnome-software (bionic-proposed/main) [3.28.1-0ubuntu4.18.04.2 => 3.28.1-0ubuntu4.18.04.3] (ubuntu-desktop)
<popey> sil2100: Ubuntu MATE images are ready.
<sil2100> popey: phew, thanks! Since I marked it myself already
<popey> hah :)
<sil2100> (would suck if someone from MATE actually said: "wait, we're not ready")
<sil2100> Anyway, guess 16.04.5 is released, will send out the announcement
<sil2100> Big thanks to everyone participating! (and to infinity for making sure I didn't do any bloopers)
-queuebot:#ubuntu-release- New binary: mailscripts [amd64] (cosmic-proposed/none) [0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [s390x] (cosmic-proposed/universe) [2.18.22+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [ppc64el] (cosmic-proposed/universe) [2.18.22+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: nautilus (bionic-proposed/main) [1:3.26.3-0ubuntu4 => 1:3.26.4-0~ubuntu18.04.1] (ubuntu-desktop)
<jibel> Thanks sil2100 for driving this release!
-queuebot:#ubuntu-release- New binary: qgis [i386] (cosmic-proposed/universe) [2.18.22+dfsg-1] (no packageset)
* sil2100 changed the topic of #ubuntu-release to: Released: Xenial 16.04.5, Bionic 18.04.1 | Archive: open | Cosmic 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 | melius malum quod cognoscis
-queuebot:#ubuntu-release- New binary: qgis [amd64] (cosmic-proposed/universe) [2.18.22+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Builds: 39 entries have been added, updated or disabled
-queuebot:#ubuntu-release- New binary: qgis [armhf] (cosmic-proposed/universe) [2.18.22+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [arm64] (cosmic-proposed/universe) [2.18.22+dfsg-1] (no packageset)
<xnox> so what is left in qt/xorg transition =)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-154.204] (core, kernel)
<LocutusOfBorg> xnox, ffmpeg being candidate e.g.
<infinity> sil2100: \o/
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-154.204]
<acheronuk> LocutusOfBorg: fun! https://people.canonical.com/~ubuntu-archive/transitions/html/html/ffmpeg.html
<acheronuk> lots of old stuff, already patched to hell to work with previous ffmpeg releases
<acheronuk> xnox LocutusOfBorg: I tried looking for some fixes for a few of those, but hit stuff that doesn't apply ok or I don't understand well enough so far
<acheronuk> strigi can be removed from the archive. it's only now a dep/build dep for amarok in -release. amarok in -proposed is build without it
<acheronuk> *built
<acheronuk> well, removed as part of the migration I guess
<LocutusOfBorg> some of them have bugs with patches in debian
<acheronuk> in terms of xorg xserver-xorg-video-ati still depends on xorg-video-abi-23 from -release
-queuebot:#ubuntu-release- New binary: pyopengl [amd64] (cosmic-proposed/universe) [3.1.0+dfsg-2] (no packageset)
<tsimonq2> Thanks sil2100 <3
<tsimonq2> xnox: I intend to find out and go at fixing it... :P
-queuebot:#ubuntu-release- Unapproved: gcc-5 (xenial-proposed/main) [5.4.0-6ubuntu1~16.04.10 => 5.4.0-6ubuntu1~16.04.11] (core)
<tsimonq2> sil2100: VLC verification is done; could you please release bug 1774067?
<ubot5> bug 1774067 in vlc (Ubuntu Bionic) "[SRU] Update to bugfix release 3.0.3 in Bionic" [Medium,Fix committed] https://launchpad.net/bugs/1774067
<tsimonq2> (bionic-proposed -> bionic-updates vlc)
<tsimonq2> sil2100: nvm, mdeslaur is copying to -security and it will automatically go to -updates.
-queuebot:#ubuntu-release- Unapproved: rejected nodejs [source] (bionic-proposed) [8.10.0~dfsg-2ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (bionic-proposed/main) [1:18.04.21 => 1:18.04.22] (core)
<sil2100> tsimonq2: good!
<sil2100> \o/
<tsimonq2> Hey sil2100 :)
<tsimonq2> slangasek, sil2100: Now that 16.04.5 is out of the door, I would like to know what it would take to do a 16.04.5.1 release for Lubuntu to fix the encrypted LVM issue next week.
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-ubuntu-dock (bionic-proposed/main) [0.9.1 => 0.9.1ubuntu18.04.1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- New binary: freeipmi [s390x] (cosmic-proposed/main) [1.5.7-2ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: freeipmi [ppc64el] (cosmic-proposed/main) [1.5.7-2ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: freeipmi [arm64] (cosmic-proposed/main) [1.5.7-2ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: freeipmi [armhf] (cosmic-proposed/main) [1.5.7-2ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: freeipmi [amd64] (cosmic-proposed/main) [1.5.7-2ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: freeipmi [i386] (cosmic-proposed/main) [1.5.7-2ubuntu1] (ubuntu-desktop, ubuntu-server)
<Trevinho> when you've a sec, please dequeue https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3338.1/+packages this from SRU :)
<fossfreedom> jbicha, apparently #ubuntu-desktop is read-only for non-devs - so sorry - I'll ping you here...
<fossfreedom> I've looked at the 3.90 mutter in cosmic
<fossfreedom> it looks like the API/ABI change has fundamentally broken background displays in budgie-desktop src/meta/screen.h has been deleted
<fossfreedom> so cannot recompile currently.
<tsimonq2> fossfreedom: You just need to be registered with freenode.
<tsimonq2> (Which you really should be either way.)
<fossfreedom> tsimonq2, registered?  you mean the ubuntu member cloak stuff?  yes that has been done
<slangasek> tsimonq2: I'm sorry, I thought I communicated that a per-flavor point release was not an option
<tsimonq2> slangasek: OK, I misunderstood. No problem, thanks.
<tsimonq2> fossfreedom: hmm
-queuebot:#ubuntu-release- New: accepted freeipmi [amd64] (cosmic-proposed) [1.5.7-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted freeipmi [armhf] (cosmic-proposed) [1.5.7-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted freeipmi [ppc64el] (cosmic-proposed) [1.5.7-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted pyopengl [amd64] (cosmic-proposed) [3.1.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted freeipmi [arm64] (cosmic-proposed) [1.5.7-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted freeipmi [s390x] (cosmic-proposed) [1.5.7-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted freeipmi [i386] (cosmic-proposed) [1.5.7-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted mailscripts [amd64] (cosmic-proposed) [0.2-2]
-queuebot:#ubuntu-release- New: accepted qgis [arm64] (cosmic-proposed) [2.18.22+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [i386] (cosmic-proposed) [2.18.22+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [s390x] (cosmic-proposed) [2.18.22+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [amd64] (cosmic-proposed) [2.18.22+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [ppc64el] (cosmic-proposed) [2.18.22+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [armhf] (cosmic-proposed) [2.18.22+dfsg-1]
#ubuntu-release 2018-08-03
-queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.3-1~ubuntu18.04.1 => 3.28.3-2~ubuntu18.04.1] (desktop-extra, ubuntu-desktop)
<acheronuk> LocutusOfBorg: boost 1.67 also looks entangled with ffmpeg https://people.canonical.com/~ubuntu-archive/transitions/html/html/boost1.67.html
-queuebot:#ubuntu-release- Unapproved: gnome-shell (bionic-proposed/main) [3.28.2-0ubuntu0.18.04.1 => 3.28.3-0ubuntu0.18.04.2] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: dpdk (bionic-proposed/main) [17.11.2-1ubuntu0.1 => 17.11.3-3~ubuntu0.18.04] (kubuntu, ubuntu-desktop, ubuntu-server)
<LocutusOfBorg> ./vorlon:force-badtest mariadb-10.1/1:10.1.29-6 mariadb-10.1/1:10.1.29-6build2 mariadb-10.1/1:10.1.29-6ubuntu2
<LocutusOfBorg> please update the hint to 1:10.1.34-1
<LocutusOfBorg> xnox, wrt btrfs-tools, why don't fix curtin instead of introducing a delta?
<doko> stokachu: I'm looking at your kubernetes upload in NEW. how will you handle dependencies on the kubernetes binaries (all the rdeps). which ones are there?
<doko> so just replacing the existing package isn't good enough
-queuebot:#ubuntu-release- New: rejected kubernetes [source] (cosmic-proposed) [1.0]
<doko> ^^^: replied in the bug report
<rbasak> Please could someone remove php-mockery and php-net-ldap2 from the release pocket? They've both been removed from testing. I think php-defaults will migrate then? LocutusOfBorg had named a few others but they're not on the list now. I'm not sure if I'm missing something, but that at least would be progress.
<rbasak> Additionally php-mockery has an outstanding RM in Debian
<rbasak> Uh, s/php-defaults/phpunit/
<rbasak> Once phpunit is though I'll look at php-defaults.
<xnox> doko, stokachu - kubernetes was removed from ubuntu on purpose, i think it should just be rejected.
<xnox> https://launchpad.net/ubuntu/+source/kubernetes/+publishinghistory
<xnox> kubernetes is provided as CDK on ubuntu.... We provide kuberneted differently and don't need two, per Beret (lp:~dean)
<LocutusOfBorg> rbasak, php-net-ldap2 requires removals of php-net-ldap3 and simpleid-ldap too
<doko> xnox: so just blacklist?
<rbasak> LocutusOfBorg: oh I see, thanks.
<xnox> doko, i don't know if blacklists prevent uploading into NEW.... ask AAs about that.
<rbasak> So we need removals from the release pocket of: php-mockery php-net-ldap2 php-net-ldap3 simpleid-ldap
<cjwatson> blacklists don't prevent uploading to NEW
<LocutusOfBorg> rbasak, there is a new php7.2 that might be merged too, but I stopped php work because of the above
<xnox> stokachu, did you see https://www.ubuntu.com/kubernetes ? we have kubernetes build for local deployment, with/without nvidia gpu support, images on GKE and even local GKE too....
<rbasak> LocutusOfBorg: I agree - best to try and get this proposed backlog cleared as much as possible first.
<rbasak> (unless merging would actually help with the backlog)
<LocutusOfBorg> it wont :)
-queuebot:#ubuntu-release- New sync: metro-policy (cosmic-proposed/primary) [2.7.2-1]
-queuebot:#ubuntu-release- New sync: jws-api (cosmic-proposed/primary) [1.1-1]
-queuebot:#ubuntu-release- New sync: saaj-ri (cosmic-proposed/primary) [1.4.1-1]
-queuebot:#ubuntu-release- New: accepted jws-api [sync] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted saaj-ri [sync] (cosmic-proposed) [1.4.1-1]
-queuebot:#ubuntu-release- New: accepted metro-policy [sync] (cosmic-proposed) [2.7.2-1]
-queuebot:#ubuntu-release- New binary: jws-api [amd64] (cosmic-proposed/universe) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: metro-policy [amd64] (cosmic-proposed/universe) [2.7.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: saaj-ri [amd64] (cosmic-proposed/universe) [1.4.1-1] (no packageset)
<apw> rbasak, LocutusOfBorg, looking at (3) ie those demotions
-queuebot:#ubuntu-release- New: accepted jws-api [amd64] (cosmic-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted saaj-ri [amd64] (cosmic-proposed) [1.4.1-1]
-queuebot:#ubuntu-release- New: accepted metro-policy [amd64] (cosmic-proposed) [2.7.2-1]
-queuebot:#ubuntu-release- New binary: tinyxml2 [s390x] (cosmic-proposed/universe) [6.2.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: iptables-persistent [amd64] (cosmic-proposed/universe) [1.0.7] (no packageset)
-queuebot:#ubuntu-release- New binary: libx86emu [amd64] (cosmic-proposed/universe) [2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-reticulate [s390x] (cosmic-proposed/none) [1.9+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: virtualpg [ppc64el] (cosmic-proposed/none) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libx86emu [i386] (cosmic-proposed/universe) [2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: virtualpg [s390x] (cosmic-proposed/none) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tinyxml2 [ppc64el] (cosmic-proposed/universe) [6.2.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-vue-hot-reload-api [amd64] (cosmic-proposed/none) [2.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-reticulate [ppc64el] (cosmic-proposed/none) [1.9+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: tinyxml2 [amd64] (cosmic-proposed/universe) [6.2.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: tinyxml2 [i386] (cosmic-proposed/universe) [6.2.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-sil-alkalami [amd64] (cosmic-proposed/none) [1.100-1] (no packageset)
<apw> rbasak, LocutusOfBorg, done, LocutusOfBorg sorry i didn't get to it the other day
<rbasak> apw: np. Thanks!
-queuebot:#ubuntu-release- New binary: r-cran-reticulate [i386] (cosmic-proposed/universe) [1.9+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: snapper-gui [amd64] (cosmic-proposed/universe) [0git.960a94834f-1] (no packageset)
-queuebot:#ubuntu-release- New binary: virtualpg [i386] (cosmic-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: virtualpg [amd64] (cosmic-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-reticulate [amd64] (cosmic-proposed/universe) [1.9+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-clap [amd64] (cosmic-proposed/universe) [2.32.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-clap [i386] (cosmic-proposed/universe) [2.32.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcommons-jexl3-java [amd64] (cosmic-proposed/universe) [3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libx86emu [armhf] (cosmic-proposed/universe) [2.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libcommons-jexl3-java [amd64] (cosmic-proposed) [3.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-reticulate [i386] (cosmic-proposed) [1.9+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-reticulate [s390x] (cosmic-proposed) [1.9+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-reticulate [amd64] (cosmic-proposed) [1.9+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-reticulate [ppc64el] (cosmic-proposed) [1.9+dfsg-1]
-queuebot:#ubuntu-release- New: accepted fonts-sil-alkalami [amd64] (cosmic-proposed) [1.100-1]
-queuebot:#ubuntu-release- New: accepted iptables-persistent [amd64] (cosmic-proposed) [1.0.7]
-queuebot:#ubuntu-release- New: accepted node-vue-hot-reload-api [amd64] (cosmic-proposed) [2.3.0-1]
-queuebot:#ubuntu-release- New: accepted snapper-gui [amd64] (cosmic-proposed) [0git.960a94834f-1]
-queuebot:#ubuntu-release- New binary: tinyxml2 [arm64] (cosmic-proposed/universe) [6.2.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: tinyxml2 [armhf] (cosmic-proposed/universe) [6.2.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted tinyxml2 [amd64] (cosmic-proposed) [6.2.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted tinyxml2 [armhf] (cosmic-proposed) [6.2.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted tinyxml2 [ppc64el] (cosmic-proposed) [6.2.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted tinyxml2 [arm64] (cosmic-proposed) [6.2.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted tinyxml2 [s390x] (cosmic-proposed) [6.2.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted tinyxml2 [i386] (cosmic-proposed) [6.2.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted libx86emu [amd64] (cosmic-proposed) [2.0-1]
-queuebot:#ubuntu-release- New: accepted libx86emu [i386] (cosmic-proposed) [2.0-1]
-queuebot:#ubuntu-release- New: accepted libx86emu [armhf] (cosmic-proposed) [2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-clap [amd64] (cosmic-proposed) [2.32.0-1]
-queuebot:#ubuntu-release- New: accepted rust-clap [i386] (cosmic-proposed) [2.32.0-1]
<oSoMoN> can someone review/merge https://code.launchpad.net/~osomon/britney/hints-ubuntu-libreoffice/+merge/352293 for me, please?
<oSoMoN> (La_ney says he can't right now)
<doko> oSoMoN: could you look at making the arm64 autopkg test more reliable?
-queuebot:#ubuntu-release- New binary: virtualpg [arm64] (cosmic-proposed/universe) [1.0.2-1] (no packageset)
<oSoMoN> doko, it doesn't look like it's failing often, but sure I can have a look, would you mind filing a bug to track this?
<doko> the package is owned by the desktop team
-queuebot:#ubuntu-release- New binary: virtualpg [armhf] (cosmic-proposed/universe) [1.0.2-1] (no packageset)
<oSoMoN> doko, yes, but anyone is welcome to file bugs against it
-queuebot:#ubuntu-release- New: accepted virtualpg [amd64] (cosmic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted virtualpg [armhf] (cosmic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted virtualpg [ppc64el] (cosmic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted virtualpg [arm64] (cosmic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted virtualpg [s390x] (cosmic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted virtualpg [i386] (cosmic-proposed) [1.0.2-1]
<LocutusOfBorg> thanks apw no problem, we are all busy :)
<LocutusOfBorg> rbasak, will you do the php7.2 job?
<rbasak> LocutusOfBorg: I intend to though I don't want to commit right now. I'd like to get php-defaults migrated first and am looking into those currently.
<rbasak> I think I'd like some further removals. Is it OK for anything not in testing to be removed in principle, if there aren't any other complications?
<rbasak> (not in testing because of a blocking bug that got it removed)
<LocutusOfBorg> rbasak, I think it is ok, I asked this question weeks ago
<LocutusOfBorg> and yes, I agree with you about everything :)
<stokachu> xnox, yea i know about that page, why?
<xnox> stokachu, that's how one install kubernetes on ubuntu... that's why we removed the package from the archive
<xnox> stokachu, why did you upload kubernetes to NEW?
<stokachu> xnox, yes, but the powers that be wanted a kubernetes deb package
<stokachu> that points to snap install ..
<xnox> stokachu, oh, the thing you uploaded is a wrapper?
<stokachu> xnox, yea
<xnox> stokachu, but why? apt install kubernetes -> these days has a builtin support that can install a snap by doing that.
<xnox> stokachu, e.g. juliank is adding all that "install snaps with apt" thing
<stokachu> xnox, like i said, this request came from higher up
<stokachu> like at the top
<xnox> stokachu, cool, need an ack from Beret
<stokachu> xnox, ok, thanks
<xnox> stokachu, cause that's as high as i look up to =)
<stokachu> xnox, fair enough :D
<Beret> +1
<xnox> awesome, infinity, doko - apperantly i'm wrong, and we will ship a deb that wraps snap install k8s or some such
<doko> Beret: that puts some burden on the archive regarding rdeps. who's supposed to handle that?
<juliank> that will look a bit strange with the apt snap integration I guess
 * juliank has not seen it, but I expect to see a message telling me that it's also available as a snap while it's installng the snap from a maintainer script
<Beret> where's the link to the LP bug
<Beret> ?
<Beret> doko, this is the same thing that we did with openstack
<Beret> were you could apt install openstack
<Beret> which was effectively a gateway to processes allowing you to install openstack
<doko> Beret: I doubt that. we have all openstack dependencies in the archive. but the debian kubernetes package is not just a *dependency* package
<Beret> right...
<Beret> no one said it was
<Beret> and unlike kubernetes, we do in fact have debs of openstack in the archive
<xnox> Beret, and juliank's work in apt will soon make $ apt search kubernetes; apt install kubernetes -> find the snap, and install the snap.
<juliank> It's a clever hack for now. Could potentially replace it with a more clever hack in the future, if I get apt hook support bi-directional, the snap hook could just install the snap directly, and skip the whole deb thing
<xnox> Beret, without kubernetes deb in the archive
<juliank> More eventually than soon IMO
<stokachu> that's pretty cool juliank
<stokachu> oh, still a little ways out?
<juliank> Yeah
<juliank> We can currently call methods inside hooks, but hooks can't call into apt
<juliank> They communicate via JSON-RPC and I have not implemented proper JSON support in apt yet, nor proper JSON-RPC server support
<stokachu> so we'll have some sort of apt server we query?
<juliank> Well, the apt process starts the hooks, and provides them a socket to talk with it
<stokachu> ah ok
<juliank> There might be a standalone apt server mode too
<juliank> it's definitely a consideration
<stokachu> nice
<juliank> I understand the rdep concern the deb has - if debs depend on it, that's bad
<juliank> or well, suboptimal
<juliank> I mean, I'd sort of like having debs be able to depend on snaps
<juliank> But I'm not sure if Depends-Snap and Build-Depends-Snap make a whole lot of sense, so if we get rdeps in the archive, we might not be able to migrate them, if we get nicer apt integration
<juliank> Though, well, they could just Depend: snapd and run snap install k8s in preinst
<juliank> or postinst
<juliank> So from my perspective it makes sense; if (when?) we get more advanced apt hooks we can reconsider it
-queuebot:#ubuntu-release- Unapproved: libreoffice (xenial-proposed/main) [1:5.1.6~rc2-0ubuntu1~xenial3 => 1:5.1.6~rc2-0ubuntu1~xenial4] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libreoffice-l10n (xenial-proposed/main) [1:5.1.4-0ubuntu1 => 1:5.1.6~rc2-0ubuntu1~xenial4] (ubuntu-desktop)
<oSoMoN> doko, FYI bug #1785262
<ubot5> bug 1785262 in libreoffice (Ubuntu) "arm64 autopkgtests are flaky" [Medium,Triaged] https://launchpad.net/bugs/1785262
<ahasenack> hi, can someone review and apply this please? https://code.launchpad.net/~ahasenack/britney/ocfs2-tools-hints-1.8.5-5ubuntu1/+merge/351928
<oSoMoN> similar request for https://code.launchpad.net/~osomon/britney/hints-ubuntu-libreoffice/+merge/352293, please
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-132.158~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-132.158] (core, kernel)
<bdmurray> How could I get a good diff for the libreoffice SRU in the xenial queue? I run out of disk space trying to do it locally.
<bdmurray> slangasek: ^^
<slangasek> bdmurray: yeesh I'm not sure.  use a porter box?
<slangasek> LocutusOfBorg: so, nobody's fixing the mariadb-test mess?
<bdmurray> slangasek: ah, that worked
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-132.158~14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-132.158]
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (xenial-proposed) [1:5.1.6~rc2-0ubuntu1~xenial4]
-queuebot:#ubuntu-release- New binary: cbatticon [s390x] (cosmic-proposed/universe) [1.6.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: backward-cpp [amd64] (cosmic-proposed/universe) [1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cbatticon [ppc64el] (cosmic-proposed/universe) [1.6.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: delly [ppc64el] (cosmic-proposed/universe) [0.7.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: glslang [ppc64el] (cosmic-proposed/universe) [6.2.2596-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-frankban-quicktest [amd64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: delly [s390x] (cosmic-proposed/universe) [0.7.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: glslang [s390x] (cosmic-proposed/universe) [6.2.2596-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cbatticon [i386] (cosmic-proposed/universe) [1.6.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: delly [i386] (cosmic-proposed/universe) [0.7.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gamemode [amd64] (cosmic-proposed/universe) [1.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-instrument-control [ppc64el] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-doctrine-event-manager [amd64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-doctrine-reflection [amd64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-fansi [s390x] (cosmic-proposed/universe) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cmake [s390x] (cosmic-proposed/universe) [0.1.31-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-core-foundation-sys [s390x] (cosmic-proposed/universe) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: debian-policy [amd64] (cosmic-proposed/universe) [4.2.0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: glslang [amd64] (cosmic-proposed/universe) [6.2.2596-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-doctrine-persistence [amd64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cmake [ppc64el] (cosmic-proposed/universe) [0.1.31-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-encoding-rs-io [s390x] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: emacs-jedi [amd64] (cosmic-proposed/universe) [0.2.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-fansi [ppc64el] (cosmic-proposed/universe) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-instrument-control [s390x] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-commoncrypto-sys [s390x] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cbatticon [amd64] (cosmic-proposed/universe) [1.6.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pilon [amd64] (cosmic-proposed/universe) [1.22+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-fansi [amd64] (cosmic-proposed/universe) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ranger [ppc64el] (cosmic-proposed/universe) [0.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-commoncrypto-sys [i386] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-core-foundation-sys [ppc64el] (cosmic-proposed/universe) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crossbeam-epoch [s390x] (cosmic-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-foreign-types [ppc64el] (cosmic-proposed/universe) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fs2 [ppc64el] (cosmic-proposed/universe) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-home [ppc64el] (cosmic-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: glslang [i386] (cosmic-proposed/universe) [6.2.2596-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-fansi [i386] (cosmic-proposed/universe) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-commoncrypto-sys [ppc64el] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-encoding-rs-io [ppc64el] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fs2 [s390x] (cosmic-proposed/universe) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-itertools [s390x] (cosmic-proposed/universe) [0.7.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: puppet-module-designate [amd64] (cosmic-proposed/universe) [13.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crossbeam-epoch [ppc64el] (cosmic-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-home [s390x] (cosmic-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ranger [s390x] (cosmic-proposed/universe) [0.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-foreign-types [s390x] (cosmic-proposed/universe) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: delly [amd64] (cosmic-proposed/universe) [0.7.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ranger [amd64] (cosmic-proposed/universe) [0.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cmake [i386] (cosmic-proposed/universe) [0.1.31-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crossbeam-epoch [amd64] (cosmic-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ignore [ppc64el] (cosmic-proposed/universe) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-itertools [ppc64el] (cosmic-proposed/universe) [0.7.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libz-sys [s390x] (cosmic-proposed/universe) [1.0.18-1] (no packageset)
-queuebot:#ubuntu-release- New binary: puppet-module-voxpupuli-corosync [amd64] (cosmic-proposed/universe) [5.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-commoncrypto-sys [amd64] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ignore [s390x] (cosmic-proposed/universe) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cmake [amd64] (cosmic-proposed/universe) [0.1.31-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libz-sys [ppc64el] (cosmic-proposed/universe) [1.0.18-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crossbeam-epoch [i386] (cosmic-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-core-foundation-sys [amd64] (cosmic-proposed/universe) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-foreign-types [amd64] (cosmic-proposed/universe) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fs2 [i386] (cosmic-proposed/universe) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nom [ppc64el] (cosmic-proposed/universe) [4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-encoding-rs-io [amd64] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-home [i386] (cosmic-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fs2 [amd64] (cosmic-proposed/universe) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nom [s390x] (cosmic-proposed/universe) [4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ranger [i386] (cosmic-proposed/universe) [0.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-itertools [i386] (cosmic-proposed/universe) [0.7.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-quote [s390x] (cosmic-proposed/universe) [0.6.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spi-tools [s390x] (cosmic-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-itertools [amd64] (cosmic-proposed/universe) [0.7.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-serde-ignored [s390x] (cosmic-proposed/universe) [0.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-jobserver [amd64] (cosmic-proposed/universe) [0.1.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-instrument-control [amd64] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-foreign-types [i386] (cosmic-proposed/universe) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ignore [i386] (cosmic-proposed/universe) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-serde-ignored [ppc64el] (cosmic-proposed/universe) [0.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-core-foundation-sys [i386] (cosmic-proposed/universe) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-quote [ppc64el] (cosmic-proposed/universe) [0.6.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ignore [amd64] (cosmic-proposed/universe) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spi-tools [ppc64el] (cosmic-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-dicom [s390x] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-fits [s390x] (cosmic-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-lssa [s390x] (cosmic-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-home [amd64] (cosmic-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-quote [amd64] (cosmic-proposed/universe) [0.6.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-serde-ignored [i386] (cosmic-proposed/universe) [0.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sharness [amd64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-fits [ppc64el] (cosmic-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-encoding-rs-io [i386] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-quote [i386] (cosmic-proposed/universe) [0.6.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-image-acquisition [s390x] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-socket2 [amd64] (cosmic-proposed/universe) [0.3.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nom [amd64] (cosmic-proposed/universe) [4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-dicom [ppc64el] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-fits [amd64] (cosmic-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-level-set [s390x] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-vibes [ppc64el] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libz-sys [amd64] (cosmic-proposed/universe) [1.0.18-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nom [i386] (cosmic-proposed/universe) [4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-socket2 [i386] (cosmic-proposed/universe) [0.3.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spi-tools [i386] (cosmic-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-doctest [amd64] (cosmic-proposed/universe) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-lssa [ppc64el] (cosmic-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libz-sys [i386] (cosmic-proposed/universe) [1.0.18-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spi-tools [amd64] (cosmic-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-image-acquisition [ppc64el] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-serde-ignored [amd64] (cosmic-proposed/universe) [0.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-vibes [s390x] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-fuzzy-logic-toolkit [amd64] (cosmic-proposed/universe) [0.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-mvn [amd64] (cosmic-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-optics [amd64] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-lssa [i386] (cosmic-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: transmission-el [amd64] (cosmic-proposed/universe) [0.12.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-ncarray [amd64] (cosmic-proposed/universe) [1.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-dicom [i386] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-instrument-control [i386] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-vibes [amd64] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-image-acquisition [amd64] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-secs3d [amd64] (cosmic-proposed/universe) [0.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-bsltl [amd64] (cosmic-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-cgi [amd64] (cosmic-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-image-acquisition [i386] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-fits [i386] (cosmic-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-level-set [ppc64el] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-lssa [amd64] (cosmic-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-dicom [amd64] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-level-set [i386] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cbatticon [arm64] (cosmic-proposed/universe) [1.6.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-vibes [i386] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cbatticon [armhf] (cosmic-proposed/universe) [1.6.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-level-set [amd64] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: delly [armhf] (cosmic-proposed/universe) [0.7.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: delly [arm64] (cosmic-proposed/universe) [0.7.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-fansi [armhf] (cosmic-proposed/universe) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-instrument-control [armhf] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pymca [amd64] (cosmic-proposed/universe) [5.3.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-fansi [arm64] (cosmic-proposed/universe) [0.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php7.3 [ppc64el] (cosmic-proposed/universe) [7.3.0~alpha3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ranger [armhf] (cosmic-proposed/universe) [0.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ranger [arm64] (cosmic-proposed/universe) [0.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cmake [armhf] (cosmic-proposed/universe) [0.1.31-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cmake [arm64] (cosmic-proposed/universe) [0.1.31-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pymca [i386] (cosmic-proposed/universe) [5.3.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-commoncrypto-sys [arm64] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-commoncrypto-sys [armhf] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-core-foundation-sys [armhf] (cosmic-proposed/universe) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-core-foundation-sys [arm64] (cosmic-proposed/universe) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crossbeam-epoch [armhf] (cosmic-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-encoding-rs-io [arm64] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-crossbeam-epoch [arm64] (cosmic-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-encoding-rs-io [armhf] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-foreign-types [arm64] (cosmic-proposed/universe) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-foreign-types [armhf] (cosmic-proposed/universe) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-home [arm64] (cosmic-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fs2 [arm64] (cosmic-proposed/universe) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-home [armhf] (cosmic-proposed/universe) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fs2 [armhf] (cosmic-proposed/universe) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ignore [arm64] (cosmic-proposed/universe) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-itertools [arm64] (cosmic-proposed/universe) [0.7.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-itertools [armhf] (cosmic-proposed/universe) [0.7.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-jobserver [arm64] (cosmic-proposed/universe) [0.1.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ignore [armhf] (cosmic-proposed/universe) [0.4.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libz-sys [arm64] (cosmic-proposed/universe) [1.0.18-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libz-sys [armhf] (cosmic-proposed/universe) [1.0.18-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nom [arm64] (cosmic-proposed/universe) [4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-nom [armhf] (cosmic-proposed/universe) [4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-quote [arm64] (cosmic-proposed/universe) [0.6.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-serde-ignored [armhf] (cosmic-proposed/universe) [0.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-serde-ignored [arm64] (cosmic-proposed/universe) [0.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-quote [armhf] (cosmic-proposed/universe) [0.6.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spi-tools [arm64] (cosmic-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-socket2 [armhf] (cosmic-proposed/universe) [0.3.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spi-tools [armhf] (cosmic-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: glslang [armhf] (cosmic-proposed/universe) [6.2.2596-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-dicom [armhf] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-dicom [arm64] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: glslang [arm64] (cosmic-proposed/universe) [6.2.2596-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php7.3 [amd64] (cosmic-proposed/universe) [7.3.0~alpha3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-fits [armhf] (cosmic-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-fits [arm64] (cosmic-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-image-acquisition [armhf] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-image-acquisition [arm64] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-lssa [arm64] (cosmic-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-vibes [arm64] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-lssa [armhf] (cosmic-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-vibes [armhf] (cosmic-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-level-set [arm64] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-level-set [armhf] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php7.3 [arm64] (cosmic-proposed/universe) [7.3.0~alpha3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php7.3 [i386] (cosmic-proposed/universe) [7.3.0~alpha3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php7.3 [armhf] (cosmic-proposed/universe) [7.3.0~alpha3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pymca [arm64] (cosmic-proposed/universe) [5.3.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pymca [armhf] (cosmic-proposed/universe) [5.3.2+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-cmake [amd64] (cosmic-proposed) [0.1.31-1]
-queuebot:#ubuntu-release- New: accepted rust-cmake [ppc64el] (cosmic-proposed) [0.1.31-1]
-queuebot:#ubuntu-release- New: accepted rust-commoncrypto-sys [amd64] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-commoncrypto-sys [ppc64el] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-core-foundation-sys [amd64] (cosmic-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-core-foundation-sys [ppc64el] (cosmic-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-crossbeam-epoch [ppc64el] (cosmic-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted rust-cmake [i386] (cosmic-proposed) [0.1.31-1]
-queuebot:#ubuntu-release- New: accepted rust-commoncrypto-sys [i386] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-core-foundation-sys [i386] (cosmic-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-crossbeam-epoch [s390x] (cosmic-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted rust-cmake [s390x] (cosmic-proposed) [0.1.31-1]
-queuebot:#ubuntu-release- New: accepted rust-core-foundation-sys [s390x] (cosmic-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-commoncrypto-sys [s390x] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-cmake [arm64] (cosmic-proposed) [0.1.31-1]
-queuebot:#ubuntu-release- New: accepted rust-commoncrypto-sys [arm64] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-core-foundation-sys [arm64] (cosmic-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-crossbeam-epoch [amd64] (cosmic-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted rust-crossbeam-epoch [armhf] (cosmic-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted rust-serde-ignored [amd64] (cosmic-proposed) [0.0.4-1]
-queuebot:#ubuntu-release- New: accepted rust-serde-ignored [ppc64el] (cosmic-proposed) [0.0.4-1]
-queuebot:#ubuntu-release- New binary: cbatticon [amd64] (cosmic-proposed/universe) [1.6.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-dicom [i386] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-instrument-control [i386] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-cmake [armhf] (cosmic-proposed) [0.1.31-1]
-queuebot:#ubuntu-release- New: accepted rust-core-foundation-sys [armhf] (cosmic-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-crossbeam-epoch [i386] (cosmic-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New: accepted rust-serde-ignored [s390x] (cosmic-proposed) [0.0.4-1]
-queuebot:#ubuntu-release- New binary: octave-image-acquisition [amd64] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-optics [amd64] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: puppet-module-designate [amd64] (cosmic-proposed/universe) [13.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-commoncrypto-sys [armhf] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-serde-ignored [i386] (cosmic-proposed) [0.0.4-1]
-queuebot:#ubuntu-release- New binary: octave-ncarray [amd64] (cosmic-proposed/universe) [1.0.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-encoding-rs-io [ppc64el] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-crossbeam-epoch [arm64] (cosmic-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New binary: octave-secs3d [amd64] (cosmic-proposed/universe) [0.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: glslang [i386] (cosmic-proposed/universe) [6.2.2596-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-serde-ignored [arm64] (cosmic-proposed) [0.0.4-1]
-queuebot:#ubuntu-release- New binary: octave-fuzzy-logic-toolkit [amd64] (cosmic-proposed/universe) [0.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-serde-ignored [armhf] (cosmic-proposed) [0.0.4-1]
-queuebot:#ubuntu-release- New binary: transmission-el [amd64] (cosmic-proposed/universe) [0.12.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-libz-sys [amd64] (cosmic-proposed) [1.0.18-1]
-queuebot:#ubuntu-release- New: accepted rust-libz-sys [armhf] (cosmic-proposed) [1.0.18-1]
-queuebot:#ubuntu-release- New: accepted rust-libz-sys [ppc64el] (cosmic-proposed) [1.0.18-1]
-queuebot:#ubuntu-release- New binary: debian-policy [amd64] (cosmic-proposed/universe) [4.2.0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-instrument-control [s390x] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-doctrine-persistence [amd64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-libz-sys [arm64] (cosmic-proposed) [1.0.18-1]
-queuebot:#ubuntu-release- New: accepted rust-libz-sys [s390x] (cosmic-proposed) [1.0.18-1]
-queuebot:#ubuntu-release- New binary: php-doctrine-event-manager [amd64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-libz-sys [i386] (cosmic-proposed) [1.0.18-1]
-queuebot:#ubuntu-release- New binary: php-doctrine-reflection [amd64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-instrument-control [ppc64el] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-nom [amd64] (cosmic-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-nom [ppc64el] (cosmic-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-quote [amd64] (cosmic-proposed) [0.6.3-1]
-queuebot:#ubuntu-release- New: accepted rust-quote [armhf] (cosmic-proposed) [0.6.3-1]
-queuebot:#ubuntu-release- New: accepted rust-quote [ppc64el] (cosmic-proposed) [0.6.3-1]
-queuebot:#ubuntu-release- New: accepted rust-socket2 [amd64] (cosmic-proposed) [0.3.7-1]
-queuebot:#ubuntu-release- New: accepted rust-socket2 [i386] (cosmic-proposed) [0.3.7-1]
-queuebot:#ubuntu-release- New binary: delly [ppc64el] (cosmic-proposed/universe) [0.7.8-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-nom [i386] (cosmic-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-quote [arm64] (cosmic-proposed) [0.6.3-1]
-queuebot:#ubuntu-release- New: accepted rust-quote [s390x] (cosmic-proposed) [0.6.3-1]
-queuebot:#ubuntu-release- New binary: cbatticon [i386] (cosmic-proposed/universe) [1.6.8-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-nom [s390x] (cosmic-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-socket2 [armhf] (cosmic-proposed) [0.3.7-1]
-queuebot:#ubuntu-release- New: accepted rust-quote [i386] (cosmic-proposed) [0.6.3-1]
-queuebot:#ubuntu-release- New binary: gamemode [amd64] (cosmic-proposed/universe) [1.2-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-foreign-types [amd64] (cosmic-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted rust-foreign-types [ppc64el] (cosmic-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted rust-fs2 [amd64] (cosmic-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted rust-fs2 [ppc64el] (cosmic-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted rust-home [amd64] (cosmic-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-home [armhf] (cosmic-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-home [ppc64el] (cosmic-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-nom [arm64] (cosmic-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New binary: octave-image-acquisition [ppc64el] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-foreign-types [i386] (cosmic-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted rust-fs2 [i386] (cosmic-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted rust-home [arm64] (cosmic-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-home [s390x] (cosmic-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New binary: spi-tools [amd64] (cosmic-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-foreign-types [s390x] (cosmic-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted rust-home [i386] (cosmic-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted rust-fs2 [s390x] (cosmic-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted rust-nom [armhf] (cosmic-proposed) [4.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-foreign-types [arm64] (cosmic-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted rust-fs2 [arm64] (cosmic-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted rust-ignore [amd64] (cosmic-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted rust-ignore [ppc64el] (cosmic-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted rust-itertools [amd64] (cosmic-proposed) [0.7.8-1]
-queuebot:#ubuntu-release- New: accepted rust-itertools [ppc64el] (cosmic-proposed) [0.7.8-1]
-queuebot:#ubuntu-release- New binary: octave-dicom [ppc64el] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-lssa [s390x] (cosmic-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-foreign-types [armhf] (cosmic-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted rust-ignore [i386] (cosmic-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted rust-itertools [i386] (cosmic-proposed) [0.7.8-1]
-queuebot:#ubuntu-release- New binary: octave-fits [ppc64el] (cosmic-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-fs2 [armhf] (cosmic-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted rust-itertools [s390x] (cosmic-proposed) [0.7.8-1]
-queuebot:#ubuntu-release- New: accepted rust-ignore [s390x] (cosmic-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New binary: sharness [amd64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-ignore [arm64] (cosmic-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New: accepted rust-itertools [arm64] (cosmic-proposed) [0.7.8-1]
-queuebot:#ubuntu-release- New binary: octave-dicom [s390x] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-image-acquisition [s390x] (cosmic-proposed/universe) [0.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-ignore [armhf] (cosmic-proposed) [0.4.3-1]
-queuebot:#ubuntu-release- New binary: octave-fits [s390x] (cosmic-proposed/universe) [1.0.7-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-itertools [armhf] (cosmic-proposed) [0.7.8-1]
-queuebot:#ubuntu-release- New binary: rust-encoding-rs-io [i386] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-encoding-rs-io [amd64] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-encoding-rs-io [armhf] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-encoding-rs-io [ppc64el] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-encoding-rs-io [arm64] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-encoding-rs-io [s390x] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-encoding-rs-io [i386] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted octave-level-set [amd64] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted octave-level-set [armhf] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted octave-level-set [ppc64el] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted octave-lssa [amd64] (cosmic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted octave-lssa [armhf] (cosmic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted octave-lssa [ppc64el] (cosmic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted octave-level-set [arm64] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted octave-level-set [s390x] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted octave-lssa [i386] (cosmic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted octave-level-set [i386] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted octave-lssa [s390x] (cosmic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted octave-lssa [arm64] (cosmic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted octave-image-acquisition [amd64] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted octave-image-acquisition [armhf] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted octave-image-acquisition [ppc64el] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted octave-image-acquisition [arm64] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted octave-image-acquisition [s390x] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted octave-image-acquisition [i386] (cosmic-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-fansi [amd64] (cosmic-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-fansi [armhf] (cosmic-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-fansi [ppc64el] (cosmic-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ranger [amd64] (cosmic-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ranger [armhf] (cosmic-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ranger [ppc64el] (cosmic-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-fansi [arm64] (cosmic-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-fansi [s390x] (cosmic-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ranger [i386] (cosmic-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-fansi [i386] (cosmic-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ranger [s390x] (cosmic-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ranger [arm64] (cosmic-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted octave-dicom [amd64] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted octave-dicom [armhf] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted octave-dicom [ppc64el] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted octave-doctest [amd64] (cosmic-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New binary: cbatticon [ppc64el] (cosmic-proposed/universe) [1.6.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: glslang [ppc64el] (cosmic-proposed/universe) [6.2.2596-1] (no packageset)
-queuebot:#ubuntu-release- New source: jboss-annotations-1.2-api (cosmic-proposed/primary) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted octave-dicom [arm64] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted octave-dicom [s390x] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New binary: cbatticon [s390x] (cosmic-proposed/universe) [1.6.8-1] (no packageset)
-queuebot:#ubuntu-release- New source: vaultlocker (cosmic-proposed/primary) [1.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted octave-dicom [i386] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New source: hvac (cosmic-proposed/primary) [0.5.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: backward-cpp [amd64] (cosmic-proposed/universe) [1.4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted glslang [amd64] (cosmic-proposed) [6.2.2596-1]
-queuebot:#ubuntu-release- New: accepted glslang [armhf] (cosmic-proposed) [6.2.2596-1]
-queuebot:#ubuntu-release- New: accepted glslang [ppc64el] (cosmic-proposed) [6.2.2596-1]
-queuebot:#ubuntu-release- New: accepted glslang [arm64] (cosmic-proposed) [6.2.2596-1]
-queuebot:#ubuntu-release- New: accepted glslang [s390x] (cosmic-proposed) [6.2.2596-1]
-queuebot:#ubuntu-release- New: accepted glslang [i386] (cosmic-proposed) [6.2.2596-1]
-queuebot:#ubuntu-release- New: accepted octave-fits [ppc64el] (cosmic-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted octave-instrument-control [amd64] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted octave-instrument-control [s390x] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted octave-vibes [s390x] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted octave-fits [s390x] (cosmic-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted octave-vibes [ppc64el] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted octave-instrument-control [ppc64el] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted octave-bsltl [amd64] (cosmic-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted octave-fits [amd64] (cosmic-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted octave-fits [armhf] (cosmic-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted octave-fuzzy-logic-toolkit [amd64] (cosmic-proposed) [0.4.5-1]
-queuebot:#ubuntu-release- New: accepted octave-instrument-control [i386] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted octave-ncarray [amd64] (cosmic-proposed) [1.0.4-1]
-queuebot:#ubuntu-release- New: accepted octave-secs3d [amd64] (cosmic-proposed) [0.0.1-1]
-queuebot:#ubuntu-release- New: accepted octave-vibes [arm64] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted octave-vibes [i386] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted octave-cgi [amd64] (cosmic-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted octave-fits [i386] (cosmic-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted octave-mvn [amd64] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted octave-vibes [amd64] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted octave-fits [arm64] (cosmic-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted octave-optics [amd64] (cosmic-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted octave-instrument-control [armhf] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted octave-vibes [armhf] (cosmic-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- Unapproved: ibm-java80 (xenial-proposed/partner) [8.0.5.16-0ubuntu1 => 8.0.5.17-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted emacs-jedi [amd64] (cosmic-proposed) [0.2.7-1]
-queuebot:#ubuntu-release- New: accepted puppet-module-designate [amd64] (cosmic-proposed) [13.1.0-1]
-queuebot:#ubuntu-release- New: accepted sharness [amd64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted pilon [amd64] (cosmic-proposed) [1.22+dfsg-1]
-queuebot:#ubuntu-release- New: accepted transmission-el [amd64] (cosmic-proposed) [0.12.1-1]
-queuebot:#ubuntu-release- New: accepted puppet-module-voxpupuli-corosync [amd64] (cosmic-proposed) [5.0.0-1]
-queuebot:#ubuntu-release- New: accepted spi-tools [amd64] (cosmic-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted spi-tools [armhf] (cosmic-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted spi-tools [ppc64el] (cosmic-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted spi-tools [arm64] (cosmic-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted spi-tools [s390x] (cosmic-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted spi-tools [i386] (cosmic-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted cbatticon [amd64] (cosmic-proposed) [1.6.8-1]
-queuebot:#ubuntu-release- New: accepted cbatticon [armhf] (cosmic-proposed) [1.6.8-1]
-queuebot:#ubuntu-release- New: accepted cbatticon [ppc64el] (cosmic-proposed) [1.6.8-1]
-queuebot:#ubuntu-release- New: accepted cbatticon [arm64] (cosmic-proposed) [1.6.8-1]
-queuebot:#ubuntu-release- New: accepted cbatticon [s390x] (cosmic-proposed) [1.6.8-1]
-queuebot:#ubuntu-release- New: accepted cbatticon [i386] (cosmic-proposed) [1.6.8-1]
-queuebot:#ubuntu-release- New: accepted backward-cpp [amd64] (cosmic-proposed) [1.4-1]
-queuebot:#ubuntu-release- New: accepted delly [amd64] (cosmic-proposed) [0.7.8-1]
-queuebot:#ubuntu-release- New: accepted delly [armhf] (cosmic-proposed) [0.7.8-1]
-queuebot:#ubuntu-release- New: accepted delly [ppc64el] (cosmic-proposed) [0.7.8-1]
-queuebot:#ubuntu-release- New: accepted golang-github-frankban-quicktest [amd64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted php-doctrine-persistence [amd64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted debian-policy [amd64] (cosmic-proposed) [4.2.0.1]
-queuebot:#ubuntu-release- New: accepted delly [i386] (cosmic-proposed) [0.7.8-1]
-queuebot:#ubuntu-release- New: accepted php-doctrine-event-manager [amd64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted delly [arm64] (cosmic-proposed) [0.7.8-1]
-queuebot:#ubuntu-release- New: accepted php-doctrine-reflection [amd64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted delly [s390x] (cosmic-proposed) [0.7.8-1]
-queuebot:#ubuntu-release- New: accepted gamemode [amd64] (cosmic-proposed) [1.2-2]
-queuebot:#ubuntu-release- New binary: renderdoc [ppc64el] (cosmic-proposed/universe) [1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: renderdoc [amd64] (cosmic-proposed/universe) [1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: renderdoc [arm64] (cosmic-proposed/universe) [1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: freeipmi (bionic-proposed/main) [1.4.11-1.1ubuntu4 => 1.4.11-1.1ubuntu4.1] (ubuntu-desktop, ubuntu-server)
<raidensnake> sorry to bother you but who can i speak to in relation to an inten hd audio fix.
<raidensnake> intel*
<raidensnake> there isn't a version for bionic
<raidensnake> I'm refering to the package to fix intel cherrytrail audio
<raidensnake> https://code.launchpad.net/~ubuntu-audio-dev/+archive/ubuntu/alsa-daily/+packages
<slangasek> raidensnake: you would want to contact the people that are members of that team; it seems like tjaalton who is in this channel might be able to help, otherwise you can try contacting the team by email through launchpad
<lotuspsychje> tnx :p
-queuebot:#ubuntu-release- New binary: libthread-pool [i386] (cosmic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: virtualpg [ppc64el] (cosmic-proposed/universe) [2.0.0~rc0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libthread-pool [s390x] (cosmic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: virtualpg [s390x] (cosmic-proposed/universe) [2.0.0~rc0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libbioparser-dev [amd64] (cosmic-proposed/none) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: virtualpg [amd64] (cosmic-proposed/universe) [2.0.0~rc0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libthread-pool [amd64] (cosmic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: virtualpg [i386] (cosmic-proposed/universe) [2.0.0~rc0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: virtualpg [arm64] (cosmic-proposed/universe) [2.0.0~rc0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libthread-pool [arm64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: virtualpg [armhf] (cosmic-proposed/universe) [2.0.0~rc0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libthread-pool [armhf] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
#ubuntu-release 2018-08-04
-queuebot:#ubuntu-release- New: accepted php7.3 [amd64] (cosmic-proposed) [7.3.0~alpha3-1]
-queuebot:#ubuntu-release- New: accepted php7.3 [armhf] (cosmic-proposed) [7.3.0~alpha3-1]
-queuebot:#ubuntu-release- New: accepted php7.3 [ppc64el] (cosmic-proposed) [7.3.0~alpha3-1]
-queuebot:#ubuntu-release- New: accepted php7.3 [arm64] (cosmic-proposed) [7.3.0~alpha3-1]
-queuebot:#ubuntu-release- New: accepted php7.3 [i386] (cosmic-proposed) [7.3.0~alpha3-1]
-queuebot:#ubuntu-release- New: accepted pymca [amd64] (cosmic-proposed) [5.3.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted pymca [armhf] (cosmic-proposed) [5.3.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted pymca [arm64] (cosmic-proposed) [5.3.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted pymca [i386] (cosmic-proposed) [5.3.2+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libbioparser-dev [amd64] (cosmic-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted libthread-pool [amd64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted libthread-pool [armhf] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted libthread-pool [s390x] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted virtualpg [arm64] (cosmic-proposed) [2.0.0~rc0-1]
-queuebot:#ubuntu-release- New: accepted virtualpg [i386] (cosmic-proposed) [2.0.0~rc0-1]
-queuebot:#ubuntu-release- New: accepted virtualpg [s390x] (cosmic-proposed) [2.0.0~rc0-1]
-queuebot:#ubuntu-release- New: accepted libthread-pool [arm64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted virtualpg [amd64] (cosmic-proposed) [2.0.0~rc0-1]
-queuebot:#ubuntu-release- New: accepted virtualpg [ppc64el] (cosmic-proposed) [2.0.0~rc0-1]
-queuebot:#ubuntu-release- New: accepted libthread-pool [i386] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted virtualpg [armhf] (cosmic-proposed) [2.0.0~rc0-1]
-queuebot:#ubuntu-release- New: accepted renderdoc [amd64] (cosmic-proposed) [1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted renderdoc [ppc64el] (cosmic-proposed) [1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted rust-jobserver [arm64] (cosmic-proposed) [0.1.11-1]
-queuebot:#ubuntu-release- New: accepted renderdoc [arm64] (cosmic-proposed) [1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted rust-jobserver [amd64] (cosmic-proposed) [0.1.11-1]
-queuebot:#ubuntu-release- New binary: rampler [ppc64el] (cosmic-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rampler [s390x] (cosmic-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rampler [amd64] (cosmic-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rampler [armhf] (cosmic-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rampler [arm64] (cosmic-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rampler [i386] (cosmic-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rampler [amd64] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted rampler [armhf] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted rampler [ppc64el] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted rampler [arm64] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted rampler [s390x] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted rampler [i386] (cosmic-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New binary: golang-github-jhoonb-archivex [amd64] (cosmic-proposed/none) [0.0+20170409-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-curl-sys [s390x] (cosmic-proposed/none) [0.4.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libssh2-sys [ppc64el] (cosmic-proposed/none) [0.2.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-curl-sys [ppc64el] (cosmic-proposed/none) [0.4.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libssh2-sys [s390x] (cosmic-proposed/none) [0.2.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libgit2-sys [s390x] (cosmic-proposed/none) [0.7.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-tmc-scp [amd64] (cosmic-proposed/none) [0.0+20170825-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-curl-sys [arm64] (cosmic-proposed/none) [0.4.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libgit2-sys [amd64] (cosmic-proposed/none) [0.7.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libgit2-sys [i386] (cosmic-proposed/none) [0.7.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libssh2-sys [amd64] (cosmic-proposed/none) [0.2.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libssh2-sys [i386] (cosmic-proposed/none) [0.2.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-curl-sys [amd64] (cosmic-proposed/none) [0.4.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libgit2-sys [arm64] (cosmic-proposed/none) [0.7.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libssh2-sys [arm64] (cosmic-proposed/none) [0.2.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-curl-sys [i386] (cosmic-proposed/none) [0.4.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spyder-kernels [amd64] (cosmic-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libgit2-sys [ppc64el] (cosmic-proposed/none) [0.7.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-curl-sys [armhf] (cosmic-proposed/none) [0.4.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libssh2-sys [armhf] (cosmic-proposed/none) [0.2.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libgit2-sys [armhf] (cosmic-proposed/none) [0.7.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: netgen [s390x] (cosmic-proposed/none) [6.2.1804+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: netgen [ppc64el] (cosmic-proposed/none) [6.2.1804+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: netgen [amd64] (cosmic-proposed/universe) [6.2.1804+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: netgen [i386] (cosmic-proposed/universe) [6.2.1804+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: netgen [armhf] (cosmic-proposed/universe) [6.2.1804+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: netgen [arm64] (cosmic-proposed/universe) [6.2.1804+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-libgit2-sys [amd64] (cosmic-proposed) [0.7.7-1]
-queuebot:#ubuntu-release- New: accepted rust-libgit2-sys [armhf] (cosmic-proposed) [0.7.7-1]
-queuebot:#ubuntu-release- New: accepted rust-libgit2-sys [ppc64el] (cosmic-proposed) [0.7.7-1]
-queuebot:#ubuntu-release- New: accepted rust-libgit2-sys [arm64] (cosmic-proposed) [0.7.7-1]
-queuebot:#ubuntu-release- New: accepted rust-libgit2-sys [s390x] (cosmic-proposed) [0.7.7-1]
-queuebot:#ubuntu-release- New: accepted rust-libgit2-sys [i386] (cosmic-proposed) [0.7.7-1]
-queuebot:#ubuntu-release- New: accepted netgen [amd64] (cosmic-proposed) [6.2.1804+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted netgen [armhf] (cosmic-proposed) [6.2.1804+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted netgen [ppc64el] (cosmic-proposed) [6.2.1804+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted spyder-kernels [amd64] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted netgen [arm64] (cosmic-proposed) [6.2.1804+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted netgen [s390x] (cosmic-proposed) [6.2.1804+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted netgen [i386] (cosmic-proposed) [6.2.1804+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-jhoonb-archivex [amd64] (cosmic-proposed) [0.0+20170409-1]
-queuebot:#ubuntu-release- New: accepted rust-libssh2-sys [amd64] (cosmic-proposed) [0.2.8-1]
-queuebot:#ubuntu-release- New: accepted rust-libssh2-sys [armhf] (cosmic-proposed) [0.2.8-1]
-queuebot:#ubuntu-release- New: accepted rust-libssh2-sys [ppc64el] (cosmic-proposed) [0.2.8-1]
-queuebot:#ubuntu-release- New: accepted golang-github-tmc-scp [amd64] (cosmic-proposed) [0.0+20170825-1]
-queuebot:#ubuntu-release- New: accepted rust-libssh2-sys [i386] (cosmic-proposed) [0.2.8-1]
-queuebot:#ubuntu-release- New: accepted rust-libssh2-sys [arm64] (cosmic-proposed) [0.2.8-1]
-queuebot:#ubuntu-release- New: accepted rust-libssh2-sys [s390x] (cosmic-proposed) [0.2.8-1]
-queuebot:#ubuntu-release- New: accepted rust-curl-sys [amd64] (cosmic-proposed) [0.4.8-1]
-queuebot:#ubuntu-release- New: accepted rust-curl-sys [armhf] (cosmic-proposed) [0.4.8-1]
-queuebot:#ubuntu-release- New: accepted rust-curl-sys [ppc64el] (cosmic-proposed) [0.4.8-1]
-queuebot:#ubuntu-release- New: accepted rust-curl-sys [arm64] (cosmic-proposed) [0.4.8-1]
-queuebot:#ubuntu-release- New: accepted rust-curl-sys [s390x] (cosmic-proposed) [0.4.8-1]
-queuebot:#ubuntu-release- New: accepted rust-curl-sys [i386] (cosmic-proposed) [0.4.8-1]
-queuebot:#ubuntu-release- New binary: rust-git2 [s390x] (cosmic-proposed/universe) [0.7.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-git2 [amd64] (cosmic-proposed/universe) [0.7.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-git2 [ppc64el] (cosmic-proposed/universe) [0.7.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-git2 [i386] (cosmic-proposed/universe) [0.7.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-store [amd64] (cosmic-proposed/universe) [0.4.3.2-5] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-store [i386] (cosmic-proposed/universe) [0.4.3.2-5] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-store [s390x] (cosmic-proposed/universe) [0.4.3.2-5] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-store [ppc64el] (cosmic-proposed/universe) [0.4.3.2-5] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-git2 [arm64] (cosmic-proposed/universe) [0.7.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-git2 [armhf] (cosmic-proposed/universe) [0.7.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-store [arm64] (cosmic-proposed/universe) [0.4.3.2-5] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-store [armhf] (cosmic-proposed/universe) [0.4.3.2-5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: man-db (bionic-proposed/main) [2.8.3-2 => 2.8.3-2ubuntu0.1] (core)
-queuebot:#ubuntu-release- New: accepted haskell-store [amd64] (cosmic-proposed) [0.4.3.2-5]
-queuebot:#ubuntu-release- New: accepted haskell-store [armhf] (cosmic-proposed) [0.4.3.2-5]
-queuebot:#ubuntu-release- New: accepted haskell-store [ppc64el] (cosmic-proposed) [0.4.3.2-5]
-queuebot:#ubuntu-release- New: accepted haskell-store [arm64] (cosmic-proposed) [0.4.3.2-5]
-queuebot:#ubuntu-release- New: accepted haskell-store [s390x] (cosmic-proposed) [0.4.3.2-5]
-queuebot:#ubuntu-release- New: accepted haskell-store [i386] (cosmic-proposed) [0.4.3.2-5]
-queuebot:#ubuntu-release- New: accepted rust-git2 [amd64] (cosmic-proposed) [0.7.5-1]
-queuebot:#ubuntu-release- New: accepted rust-git2 [armhf] (cosmic-proposed) [0.7.5-1]
-queuebot:#ubuntu-release- New: accepted rust-git2 [ppc64el] (cosmic-proposed) [0.7.5-1]
-queuebot:#ubuntu-release- New: accepted rust-git2 [arm64] (cosmic-proposed) [0.7.5-1]
-queuebot:#ubuntu-release- New: accepted rust-git2 [s390x] (cosmic-proposed) [0.7.5-1]
-queuebot:#ubuntu-release- New: accepted rust-git2 [i386] (cosmic-proposed) [0.7.5-1]
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.0-1 => 1.1.0-2] (desktop-core)
-queuebot:#ubuntu-release- New binary: imbalanced-learn [amd64] (cosmic-proposed/none) [0.3.3-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.0-2 => 1.1.0-2] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.0-2 => 1.1.0-2] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.0-2 => 1.1.0-2] (desktop-core)
#ubuntu-release 2018-08-05
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.17.0-7.8] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.17.0-7.8] (core, kernel)
-queuebot:#ubuntu-release- New source: fwupd-signed (cosmic-proposed/primary) [1.0]
-queuebot:#ubuntu-release- New binary: rust-grep [s390x] (cosmic-proposed/none) [0.1.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep [amd64] (cosmic-proposed/none) [0.1.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep [ppc64el] (cosmic-proposed/none) [0.1.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep [i386] (cosmic-proposed/none) [0.1.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python3-aiosasl [amd64] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep [armhf] (cosmic-proposed/universe) [0.1.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-grep [arm64] (cosmic-proposed/universe) [0.1.9-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.0-4 => 1.1.0-4] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.0-4 => 1.1.0-4] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.0-4 => 1.1.0-4] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.0-4 => 1.1.0-4] (desktop-core)
-queuebot:#ubuntu-release- New binary: libreoffice-dictionaries [amd64] (cosmic-proposed/main) [1:6.1.0~rc2-1] (personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: fwupdate [armhf] (cosmic-proposed/main) [12-2] (core)
-queuebot:#ubuntu-release- Unapproved: fwupdate (cosmic-proposed/main) [12-1 => 12-2] (core)
-queuebot:#ubuntu-release- Unapproved: fwupdate (cosmic-proposed/main) [12-1 => 12-2] (core)
-queuebot:#ubuntu-release- Unapproved: fwupdate (cosmic-proposed/main) [12-1 => 12-2] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.0-4 => 1.1.0-6] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.0-6 => 1.1.0-6] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.0-6 => 1.1.0-6] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.0-6 => 1.1.0-6] (desktop-core)
-queuebot:#ubuntu-release- New: accepted imbalanced-learn [amd64] (cosmic-proposed) [0.3.3-1]
-queuebot:#ubuntu-release- New: accepted python3-aiosasl [amd64] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-grep [arm64] (cosmic-proposed) [0.1.9-1]
-queuebot:#ubuntu-release- New: accepted rust-grep [i386] (cosmic-proposed) [0.1.9-1]
-queuebot:#ubuntu-release- New: accepted rust-grep [s390x] (cosmic-proposed) [0.1.9-1]
-queuebot:#ubuntu-release- New: accepted libreoffice-dictionaries [amd64] (cosmic-proposed) [1:6.1.0~rc2-1]
-queuebot:#ubuntu-release- New: accepted rust-grep [armhf] (cosmic-proposed) [0.1.9-1]
-queuebot:#ubuntu-release- New: accepted rust-grep [amd64] (cosmic-proposed) [0.1.9-1]
-queuebot:#ubuntu-release- New: accepted rust-grep [ppc64el] (cosmic-proposed) [0.1.9-1]
-queuebot:#ubuntu-release- New binary: poezio [i386] (cosmic-proposed/none) [0.11+git20180331-1] (no packageset)
-queuebot:#ubuntu-release- New binary: poezio [s390x] (cosmic-proposed/none) [0.11+git20180331-1] (no packageset)
-queuebot:#ubuntu-release- New binary: poezio [ppc64el] (cosmic-proposed/universe) [0.11+git20180331-1] (no packageset)
-queuebot:#ubuntu-release- New binary: poezio [amd64] (cosmic-proposed/universe) [0.11+git20180331-1] (no packageset)
-queuebot:#ubuntu-release- New binary: poezio [arm64] (cosmic-proposed/universe) [0.11+git20180331-1] (no packageset)
-queuebot:#ubuntu-release- New binary: poezio [armhf] (cosmic-proposed/universe) [0.11+git20180331-1] (no packageset)
<tsimonq2> infinity: It seems you made a typo in your latest Ubiquity commit: https://git.launchpad.net/ubiquity/commit/?id=cdb7dbed2342862efece06f35e26cb8294ee7f9f
<tsimonq2> deb-src http://archive.ubnutu.com/ubuntu cosmic-updates main
<tsimonq2> I would Just Fix It but ENOPERMISSIONS.
-queuebot:#ubuntu-release- New binary: boohu [ppc64el] (cosmic-proposed/none) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: boohu [s390x] (cosmic-proposed/none) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: boohu [arm64] (cosmic-proposed/none) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: yubikey-manager [amd64] (cosmic-proposed/none) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: boohu [armhf] (cosmic-proposed/none) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: boohu [amd64] (cosmic-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: boohu [i386] (cosmic-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.0-7 => 1.1.0-7] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.0-7 => 1.1.0-7] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.0-7 => 1.1.0-7] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.0-7 => 1.1.0-7] (desktop-core)
#ubuntu-release 2019-07-29
-queuebot:#ubuntu-release- Unapproved: lubuntu-default-settings (bionic-proposed/universe) [0.54.2 => 0.54.3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu3 => 2.04-1ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: libinput (bionic-proposed/main) [1.10.4-1 => 1.10.4-1ubuntu0.18.04.1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: grub2 (eoan-proposed/main) [2.04-1ubuntu3 => 2.04-1ubuntu3] (core)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1016.18]
<LocutusOfBorg> vorlon, you tested python3 tests against itself, and it failed... can we hint it for some days to let e.g. ncurses migrate or is somebody going to fix testsuites?
<LocutusOfBorg> AssertionError: 'Ubuntu' != 'Fedora'
<LocutusOfBorg> I agree that Ubuntu is not Fedora, yes python, thanks for telling that to me :)
<LocutusOfBorg> actually that test failed since the begin... meh
<LocutusOfBorg> looks like an ssl-related failure...
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [4.15.0-1038.40] (kernel)
-queuebot:#ubuntu-release- New source: backport-iwlwifi-dkms (eoan-proposed/primary) [7906-0ubuntu1]
<sil2100> LocutusOfBorg: I'm looking at that one today, will try to resolve it one way or the other
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1048.55] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1012.12] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1013.13] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1038.40]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1013.13]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1048.55]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1012.12]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (eoan-proposed) [2.04-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (eoan-proposed) [2.04-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: dkms (xenial-proposed/main) [2.2.0.3-2ubuntu11.7 => 2.2.0.3-2ubuntu11.8] (kubuntu, ubuntu-desktop)
<ginggs> would someone please 'force-badtest python-sparse/0.2.0-1/i386' ? - it has regressed in release
<ginggs> also please 'force-badtest satpy/0.16.1-1'
-queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (xenial-proposed) [2.2.0.3-2ubuntu11.8]
<LocutusOfBorg> can anybody please process https://bugs.launchpad.net/ubuntu/+source/flower/+bug/1838213 ?
<ubot5> Ubuntu bug 1838213 in twitter-bootstrap (Ubuntu) "remove twitter-bootstrap from eoan" [Undecided,New]
<LocutusOfBorg> and also, arthemis changed from arch:any to arch:all, please drop NBS proposed "missing build on arm64: artemis (from 17.0.1+dfsg-1)Â£"
<LocutusOfBorg> reverse-depends should take care of debian/tests/control too, because otherwise lots of python2 dropped packages will have testsuite failures, e.g. python-ceilometerclient
<LocutusOfBorg> it migrates because the old python2 package is still in the archive?
-queuebot:#ubuntu-release- Packageset: Added dpf-plugins to ubuntustudio in eoan
-queuebot:#ubuntu-release- Packageset: Added ubuntustudio-menu-add to ubuntustudio in eoan
<ahasenack> tjaalton: hi there
<ahasenack> tjaalton: thoughts on sssd 2.2?
<ahasenack> they jumped from 1.16 to 2.0, 2.1 and now 2.2?
<ahasenack> ops, wrong channel
<ahasenack> -> #ubuntu-devel
-queuebot:#ubuntu-release- Unapproved: neutron (bionic-proposed/main) [2:12.0.6-0ubuntu2 => 2:12.0.6-0ubuntu3] (openstack, ubuntu-server)
<coreycb> sil2100: infinity: hi there, by any chance can we fast-track neutron 2:12.0.6-0ubuntu3 into bionic-proposed and bionic-updates (with testing of course)? it fixes a regression in 2:12.0.6-0ubuntu1 and 2:12.0.6-0ubuntu2.
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (disco-proposed) [3.32.2+git20190711-2ubuntu1~19.04.1]
<sil2100> coreycb: hey! I can take a look at the neutron upload
<coreycb> sil2100: thanks!
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (bionic-proposed) [2:12.0.6-0ubuntu3]
<sil2100> coreycb: ok, accepted - since this is basically a -updates regression and a reintroduction of a patch invalidly dropped, let's think about getting this out faster
<sil2100> coreycb: can you also run some sanity-tests on the package, besides the required bug verification that the reporter will perform?
<coreycb> sil2100: thanks. yes i can do that, no problem.
<vorlon> LocutusOfBorg: looks to me like a fixed python3.7 is in -proposed now
<sil2100> vorlon: I uploaded the same fix for 3.8 some hour ago
<sil2100> The packages are still building
<vorlon> sil2100: huzzah, thanks
-queuebot:#ubuntu-release- Unapproved: cinder (disco-proposed/main) [2:14.0.0-0ubuntu1 => 2:14.0.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: horizon (disco-proposed/main) [3:15.0.0-0ubuntu1 => 3:15.1.0-0ubuntu1] (openstack, ubuntu-server)
<LocutusOfBorg> vorlon, if you have spare time (sigh, I know you are all overbusy), please process the last 4 bugs https://bugs.launchpad.net/~ubuntu-archive/+bugs?orderby=-id&start=0
<LocutusOfBorg> they should be all good, I checked reverse-deps and other stuff
-queuebot:#ubuntu-release- Unapproved: nova (bionic-proposed/main) [2:17.0.10-0ubuntu2 => 2:17.0.11-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: neutron (bionic-proposed/main) [2:12.0.6-0ubuntu3 => 2:12.1.0-0ubuntu1] (openstack, ubuntu-server)
<LocutusOfBorg>  I think passing from "neutral" to "failure" is wrong, in dh-cargo context. if some new package was "bd-uninstallable" doesn't mean it should be good when build deps are in place
<LocutusOfBorg> Laney, ^^ do you agree?  e.g. http://autopkgtest.ubuntu.com/packages/r/rust-doc-comment/eoan/amd64
-queuebot:#ubuntu-release- Unapproved: cockpit (disco-backports/universe) [198-1~ubuntu19.04.1 => 199-1~ubuntu19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (disco-backports) [199-1~ubuntu19.04.1]
-queuebot:#ubuntu-release- Unapproved: cockpit (bionic-backports/universe) [198-1~ubuntu18.04.1 => 199-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (bionic-backports) [199-1~ubuntu18.04.1]
<bdmurray> LocutusOfBorg: E117 is about "indentation" - notice the n before the first d.
-queuebot:#ubuntu-release- Unapproved: logwatch (bionic-proposed/main) [7.4.3+git20161207-2ubuntu1 => 7.4.3+git20161207-2ubuntu1.1] (ubuntu-server)
#ubuntu-release 2019-07-30
-queuebot:#ubuntu-release- Unapproved: ruby2.5 (bionic-proposed/main) [2.5.1-1ubuntu1.4 => 2.5.1-1ubuntu1.5] (kubuntu, ubuntu-desktop, ubuntu-server)
<Ukikie> \o/
<LocutusOfBorg> sorry bdmurray I fixed 4 packages and left one n in one of them...
<LocutusOfBorg> feel free to correct!
<Laney> LocutusOfBorg: we treat neutral like pass at the minute, which is not ideal
<Laney> but nobody's gotten around to updating our copy of britney yet to have better handling there
<Laney> ...
<Laney> sil2100: I'll try to look this week btw (sorry for slow reply, was travelling back from .br)
<Laney> but need to get some of GNOME 3.33.4 out really, so I have to work on that first
<Laney> keep uncovering transitions and sub-transitions so it's a bit slow
<sil2100> Laney: sure thing! Yeah, I can imagine that - anyway, thanks and good luck o/
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-56.62~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-56.62~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-158.186] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-56.62~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-158.186]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-56.62~16.04.1]
<LocutusOfBorg> please hint alt-ergo/*/armhf because it is not built there anymore
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-23.24] (core, kernel)
<LocutusOfBorg> please hint coyote/2019.02.25-1/ppc64el, regressed in release
<LocutusOfBorg> apw, ^^ can you pleeease do the two hints?
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [5.0.0-23.24~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-23.24] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [5.0.0-23.24~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [arm64] (bionic-proposed/main) [5.0.0-23.24~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [5.0.0-23.24~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [5.0.0-23.24~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [arm64] (bionic-proposed) [5.0.0-23.24~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-23.24]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-23.24]
<sil2100> LocutusOfBorg: eh, are you actually testing the changes you are releasing to ubuntu-image?
<sil2100> LocutusOfBorg: because your latest upload will make the pep8 tests fail, since now there's 3 E501 line too long errors
<sil2100> It's always best to submit one upload that fixes all issues than 5 uploads in a row
<apw> LocutusOfBorg, alt-ergo appears to be attempting to build on armhf and fialing ?
<sil2100> Especially that all it needs is running 'tox' on the source to see if the tests are clean
<LocutusOfBorg> sil2100, I did test it
<LocutusOfBorg> yes apw
<LocutusOfBorg> it has been removed from Debian/armhf
<apw> that isn't the same as no-longer-built-on-armhf
<apw> but it has not been removed in the version we have
<LocutusOfBorg> apw, update_excues is not complaining about "missing build on armhf"...
<LocutusOfBorg> sil2100, you right, I ran flake8 . --count --select=E9,F63,F72,F82 --show-source --statistics
<LocutusOfBorg> instead of flake8 . --count --show-source --statistics
<LocutusOfBorg> I was focusing on the failing test...
<LocutusOfBorg> apw, autopkgtest for gazebo/9.6.0-2: amd64: Pass, arm64: Regression â» , armhf: Regression â» , i386: Pass, ppc64el: Regression â» , s390x: Always failed
<LocutusOfBorg> same here, it is an NBS now
<apw> LocutusOfBorg, it is FTBFS on armhf, i assume it was not an architecture in the old version
<LocutusOfBorg>  alt-ergo | 1.30+dfsg1-2         | disco/universe         | source, amd64, arm64, armhf, i386, ppc64el, s390x
<LocutusOfBorg>  alt-ergo | 1.30+dfsg1-2         | eoan/universe          | source, amd64, arm64, i386, ppc64el, s390x
<rbalint> my ppa's s390x libnfs tests on eoan don't show up, while i think one aready finished (tried running it several times) https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-rbalint-scratch3/?format=plain
<LocutusOfBorg> apw, it was I guess, sorry but I don't follow you :)
<rbalint> submit succeeded, am i doing it in the wrong way?
<apw> LocutusOfBorg, it is all just a lot inconsistent with the world
<LocutusOfBorg> rbalint, what is the line you do to trigger it?
<LocutusOfBorg> apw, I think the new version has been removed from archive, the old one recopied before release, but without armhf
<LocutusOfBorg> does it sound right?
<LocutusOfBorg> rbalint your test is still running? http://autopkgtest.ubuntu.com/running
<rbalint> LocutusOfBorg, two is running, but i think i started 3
<rbalint> LocutusOfBorg, also i submitted the first around 12 hours ago
<LocutusOfBorg> it's dead jim :)
<rbalint> LocutusOfBorg, :-)
<rbalint> LocutusOfBorg, now only one is running, maybe there is something with copying the results
<rbalint> LocutusOfBorg, start line https://autopkgtest.ubuntu.com/request.cgi?release=eoan&arch=s390x&package=libnfs&ppa=rbalint/scratch3&trigger=valgrind/1:3.15.0-1ubuntu1&trigger=libnfs/3.0.0-2ubuntu1~rbalint1
<LocutusOfBorg> looks good to me
<rbalint> it started the job fine, i just can't see the results
<rbalint> LocutusOfBorg, i think i found the issue, a bad systemd is getting in from the ppa
<rbalint> this should fix the reboot, i still should have got the logs even when the testbed fails to reboot
<Laney> something in the dependencies or the PPA is making the test machine fail to come up and autopkgtest usually blames itself there rather than the maintainer
<Laney> I can fix it so you get blamed :-)
<rbalint> Laney, hm, interesting options
<Laney> done, you should start to see results soon
<rbalint> Laney, thanks, but if the machines fail to come up very often due to issues unrelated to packages i'm ok with keeping them configured that way
<Laney> it's a per package switch
<Laney> if you triggered with systemd this would already have happened
<rbalint> Laney, so i got it for libnfs?
<Laney> but PPAs always fulfil dependncies so you can get a bit unlucky there
<Laney> yes
<Laney> it basically assumes most packages aren't likely to break the boot themselves
<LocutusOfBorg> can rbalint be blamed also for my faults ð?
<Laney> but clearly some do have that capacity
<Laney> you see, rbalint was trying to test his packages before putting them in the archive
<Laney> so he wins here :-)
<rbalint> :-D
<LocutusOfBorg> my problem is not about missing testing, is about bad testing :D
<ginggs> would someone please 'force-badtest python-sparse/0.2.0-1/i386' ? - it has regressed in release
<ginggs> also please 'force-badtest satpy/0.16.1-1'
<apw> LocutusOfBorg, coyote isn't even in release to regress there
<apw> ginggs, python-sparse seems to need 'six' to migrate if i am reading the testing right
<ginggs> apw: ah i see LocutusOfBorg tested those together, i can do that for the new scipy
<apw> ginggs, that one is less obvious but worth a shot; let me know
<didrocks> LocutusOfBorg: I'm crossing finger for this upload of ubuntu-image to pass ;) I want to unblock grub2 :p
<rbalint> RAOF, bdmurray: could you please release ubuntu-meta to disco in your sru cycles?
<LocutusOfBorg> didrocks, I did upload for that reason...
<LocutusOfBorg> force-badtest python-asdf/2.3.2-2/s390x <-- apw can you please bump that hint? 2.3.3-1 is the current version
<LocutusOfBorg> autopkgtest for coyote/2019.02.25-1: amd64: Pass, arm64: Pass, armhf: Pass, i386: Pass, ppc64el: Regression â» , s390x: Pass
<LocutusOfBorg> apw, ^^ not sure why but autopkgtests things this is a regression=
<didrocks> LocutusOfBorg: yeah, I bet ;) still 20 minutes to go, let's see
<LocutusOfBorg> didrocks, it is fine
<LocutusOfBorg> I tested on ppa
<didrocks> ah great, thanks for this! :)
<LocutusOfBorg> the first failure was tested with pep8, but I introduced another because I tested only that specific code
<LocutusOfBorg> the second one was tested with ppa
<ginggs> apw: http://autopkgtest.ubuntu.com/packages/p/python-sparse/eoan/i386 passed when triggered with six \o/
<apw> ginggs, that is a thing at least
<ginggs> apw: did you look at satpy?  it seems to have regressed in release on all archs
<apw> ginggs, i did not, is that a six consumer by any chance
<ginggs> apw: hmm, yes
<apw> ginggs, so perhaps a retest of something against that just in case it is a slew of the same thing
<ginggs> apw: trying now, thanks
<LocutusOfBorg> didrocks, enjoy your new grub
<didrocks> LocutusOfBorg: yep, got the email ;)
<bdmurray> rbalint, RAOF: I've released ubuntu-meta
<RAOF> Thanks! I'm at the roadmap sprint, so a bit less SRUy than my normal Wednesday ð
<ginggs> apw: triggering with six didn't help the satpy tests
-queuebot:#ubuntu-release- Unapproved: rejected ruby2.5 [source] (bionic-proposed) [2.5.1-1ubuntu1.5]
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1019.21~16.04.1] (kernel)
<slashd> sil2100, can you look at makedumpfile in excuse page for ppc64el. seems like it doesn't find a crashdump in /var/crash and fails, but it doesn't seem related to the change I have sponsored, since same problem with eoan-proposed version -1 : http://autopkgtest.ubuntu.com/packages/m/makedumpfile/eoan/ppc64el
<slashd> vorlon, ^ since you also have an uploaded affected by that makedumpfile failure ^
<gpiccoli> slashd, hi o/
<slashd> sil2100, vorlon : could it be an infra issue ?
<Laney> ginggs: not sure why six would fix that, looks like a change in pygac to me and you need to supply a config file now
<Laney> hopefully an easy fix
<sil2100> slashd: hm, indeed it looks like a constant failure for both old and new version
<sil2100> slashd: not sure if infra version, maybe something changed in its dependencies (kernel?) that causes this failure
<slashd> sil2100, indeed
<slashd> sil2100, possibly, hard to test without local testing ;/
<slashd> and I don't have access to the failing arch
<slashd> sil2100, what i can tell with the data we have is that the change I have upload have nothing to do with this failure.
<slashd> gpiccoli, ^ fyi
<Laney> slashd: sure you do (canonistack-bos01)
<gpiccoli> Tnx slashd
<gpiccoli> Laney, indeed we have that machine, I'm gonna try to reproduce the failure there
<slashd> gpiccoli, Laney thanks
<gpiccoli> But I guess Eric's comment is accurate, if we are failing the current proposed version and the latest one (already released), it's not something introduced by the change proposed
<slashd> sil2100, how do you want to proceed ? us testing locally first ? and see how it goes ? or ignore the failure since we know it was there before my upload ?
<gpiccoli> if we could possibly do it in parallel, that'd be amazing!
<slashd> gpiccoli, right the failure can be worked on separately IMHO
<gpiccoli> agreed =)
<sil2100> slashd: I would say we should first try to investigate the failure, see what could have caused the issue, fill in a bug and if it's not something we can easily figure out or fix, hint it
<sil2100> slashd: maybe we could get someone from the kernel team to take a look?
<gpiccoli> sil2100, cascardo is the kdump guy, he's PTO for now, I'll take a look and sync with him
<slashd> gpiccoli, sil2100 sound good thanks guys
<ginggs> Laney: ack, yes, and I saw your comments  in #debci
<Laney> not related to the particular failure itself, but we should have caught it
<sil2100> gpiccoli, slashd: thanks!
-queuebot:#ubuntu-release- New binary: node-rollup-plugin-alias [amd64] (eoan-proposed/universe) [1.5.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted librsync [s390x] (eoan-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted node-rollup-plugin-alias [amd64] (eoan-proposed) [1.5.2-1]
-queuebot:#ubuntu-release- New: accepted golang-go.opencensus [amd64] (eoan-proposed) [0.22.0-1]
-queuebot:#ubuntu-release- New: accepted librsync [arm64] (eoan-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted librsync [i386] (eoan-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted librsync [amd64] (eoan-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted librsync [ppc64el] (eoan-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted librsync [armhf] (eoan-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New binary: plasma-discover [amd64] (eoan-proposed/universe) [5.16.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: plasma-discover [i386] (eoan-proposed/universe) [5.16.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: plasma-discover [s390x] (eoan-proposed/universe) [5.16.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: plasma-discover [ppc64el] (eoan-proposed/universe) [5.16.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted aodh [source] (disco-proposed) [8.0.0-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted spice-html5 [source] (disco-proposed) [0.1.7-3ubuntu0.19.04.1]
-queuebot:#ubuntu-release- New binary: plasma-discover [arm64] (eoan-proposed/universe) [5.16.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: plasma-discover [armhf] (eoan-proposed/universe) [5.16.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted snapd-glib [source] (disco-proposed) [1.49-0ubuntu0.19.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted snapd-glib [source] (bionic-proposed) [1.49-0ubuntu0.18.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-flashback [source] (disco-proposed) [3.30.0-1ubuntu6.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-flashback [source] (bionic-proposed) [3.28.0-1ubuntu1.4]
-queuebot:#ubuntu-release- Unapproved: accepted nss [source] (disco-proposed) [2:3.42-1ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: accepted nss [source] (bionic-proposed) [2:3.35-2ubuntu2.4]
-queuebot:#ubuntu-release- Unapproved: accepted nss [source] (xenial-proposed) [2:3.28.4-0ubuntu0.16.04.7]
-queuebot:#ubuntu-release- Unapproved: accepted libblockdev [source] (disco-proposed) [2.20-7ubuntu0.1]
<coreycb> bdmurray: if you have a moment, we've regression tested bug 1838263 successfully. since it fixes a regression I'd like to see if we can get it to -updates asap. frickler was going to test but wasn't able to get machines today. it's just adding a patch back that was inadvertently dropped, so personally i think we're good on testing.
<ubot5> bug 1838263 in neutron (Ubuntu Bionic) "[SRU] Fix neutron 2:12.0.6-0ubuntu1 queens regression" [Critical,Fix committed] https://launchpad.net/bugs/1838263
<bdmurray> coreycb: Isn't comment #5 in bug 1838263 the same as comment #2 in bug 1830341? The point being if the tests let this through before is it really a good test?
<ubot5> bug 1838263 in neutron (Ubuntu Bionic) "[SRU] Fix neutron 2:12.0.6-0ubuntu1 queens regression" [Critical,Fix committed] https://launchpad.net/bugs/1838263
<ubot5> bug 1830341 in nova (Ubuntu Bionic) "[SRU] queens stable releases" [High,Fix committed] https://launchpad.net/bugs/1830341
<coreycb> bdmurray: that's a fair point. part of regression testing is to verify base functionality isn't regressed, but agree it didn't catch this one.
<bdmurray> coreycb: I've gone ahead and released it
<coreycb> bdmurray: thanks
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1019.21~16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1019.21] (kernel)
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (disco-proposed) [2:14.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1019.21]
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (disco-proposed) [3:15.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted logwatch [source] (bionic-proposed) [7.4.3+git20161207-2ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted libinput [source] (bionic-proposed) [1.10.4-1ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New binary: node-react [amd64] (eoan-proposed/universe) [16.2.0-3build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-default-settings [source] (bionic-proposed) [0.54.3]
-queuebot:#ubuntu-release- Unapproved: accepted libarchive [source] (bionic-proposed) [3.2.2-3.1ubuntu0.4]
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-340 [source] (bionic-proposed) [340.107-0ubuntu0.18.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted spice-html5 [source] (xenial-proposed) [0.1.4-1ubuntu1.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (xenial-proposed) [0.96.20.9]
#ubuntu-release 2019-07-31
-queuebot:#ubuntu-release- Unapproved: dpdk (bionic-proposed/main) [17.11.5-0~ubuntu18.04.1 => 17.11.6-0~ubuntu18.04.1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: dpdk (disco-proposed/main) [18.11-6 => 18.11.2-1ubuntu0.19.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: octomap [s390x] (eoan-proposed/universe) [1.9.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: octomap [amd64] (eoan-proposed/universe) [1.9.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: octomap [i386] (eoan-proposed/universe) [1.9.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: octomap [ppc64el] (eoan-proposed/universe) [1.9.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: octomap [arm64] (eoan-proposed/universe) [1.9.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: octomap [armhf] (eoan-proposed/universe) [1.9.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: debian-installer (bionic-proposed/main) [20101020ubuntu543.9 => 20101020ubuntu543.10] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (bionic-proposed) [20101020ubuntu543.10]
<RikMills> plasma-discover binary new is just us catching up with how debian did a slight swerve, and named the snap and flatpak backends in different way
<RikMills> if anyone is looking soon...
-queuebot:#ubuntu-release- Unapproved: horizon (disco-proposed/main) [3:15.1.0-0ubuntu1 => 3:15.1.0-0ubuntu1.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: horizon (disco-proposed/main) [3:15.1.0-0ubuntu1 => 3:15.1.0-0ubuntu1.1] (openstack, ubuntu-server)
<RikMills> infinity et al. are we seeing a 18.04.3 tomorrow as scheduled?
<infinity> RikMills: It was delayed due to kernel issues, but a notice wasn't sent (yet) for reasons.  You can expect RCs tonight or tomorrow, though, with a release next week if all goes well.
<RikMills> infinity: ok. thanks. people on some social media had noticed that there were no RCs, so where asking
<RikMills> *were
<RikMills> I must admit I had forgotten!
<Eickmeyer> AAs: raysession is sourceNEW sitting, waiting for a review. Can anyone give it a review? Should be easy.
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1038.40] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1038.40]
<LocutusOfBorg> mmm how can an old binary can in the archive without corresponding sources?
<LocutusOfBorg> rmadison -u ubuntu python3-tempest python-tempest -s eoan
<LocutusOfBorg>  python3-tempest | 1:19.0.0-4 | eoan/universe | all
<LocutusOfBorg>  python-tempest  | 1:19.0.0-2 | eoan/universe | all
<LocutusOfBorg> apw, ^^ somebody copied a binary from disco to eoan without the source I would say
<LocutusOfBorg> please remove that old cruft package
<LocutusOfBorg> this should make python-stestr migrate
<LocutusOfBorg> also this one  python-oslotest | 1:3.7.1-0ubuntu1 | eoan/universe | all
<Odd_Bloke> LocutusOfBorg: To be clear, you're asking about python-tempest, not python3-tempest too, right?
<cjwatson> That's just NBS.  It shows up on https://people.canonical.com/~ubuntu-archive/nbs.html
<cjwatson> And it hasn't been processed yet because there are still several packages that declare Build-Depends on it
<cjwatson> apw: ^- so don't do LocutusOfBorg's request, IMO
<cjwatson> Unless I've missed something
<apw> cjwatson, indeed
<cjwatson> Looks to me more like some bits further up the OpenStack client stack need to be fixed
<cjwatson> e.g. trying to migrate python-cinderclient causes python-congressclient to be uninstallable, and there doesn't seem to be a newer version of that
<cjwatson> Hm no, maybe not quite that
<cjwatson> It might need an easy hint for a batch of things that remove py2 support to all go in together?
<cjwatson> *Sometimes* this sort of thing requires removing a package early to let everything else migrate, but I think that's going to be clunky here
<Eickmeyer> AAs: raysession is sourceNEW sitting, waiting for a review. Can anyone give it a review? Should be easy.
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1038.40~16.04.1] (kernel)
<Eickmeyer> AAs: raysession is sourceNEW sitting, waiting for a review. Can anyone give it a review? Should be easy.
<Eickmeyer> AAs: raysession is sourceNEW sitting, waiting for a review. Can anyone give it a review? Should be easy.
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1038.40~16.04.1]
#ubuntu-release 2019-08-01
-queuebot:#ubuntu-release- Unapproved: ruby2.5 (bionic-proposed/main) [2.5.1-1ubuntu1.4 => 2.5.1-1ubuntu1.5] (kubuntu, ubuntu-desktop, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby2.5 (bionic-proposed/main) [2.5.1-1ubuntu1.4 => 2.5.1-1ubuntu1.5] (kubuntu, ubuntu-desktop, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: s390-tools (eoan-proposed/main) [2.10.0-0ubuntu1 => 2.10.0-0ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: rejected ruby2.5 [sync] (bionic-proposed) [2.5.1-1ubuntu1.5]
-queuebot:#ubuntu-release- Unapproved: accepted ruby2.5 [sync] (bionic-proposed) [2.5.1-1ubuntu1.5]
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Bionic 18.04.3] (20190801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Bionic 18.04.3] (20190801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Bionic 18.04.3] (20190801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Bionic 18.04.3] (20190801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Bionic 18.04.3] (20190801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Bionic 18.04.3] (20190801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Bionic 18.04.3] (20190801) has been added
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-24.25] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-24.25] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-24.25] (core, kernel)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Bionic 18.04.3] (20190801) has been added
<lotuspsychje> good morning to all
<lotuspsychje> are there known bugs on the 5.0.0-23-generic, 2 volunteers at #ubuntu-discuss experience resolution/and or backlight troubles on desktop
<lotuspsychje> on bionic hwe
<apw> lotuspsychje, nothing known no ...
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-24.25]
<apw> lotuspsychje, bring bugs to #ubuntu-kernel
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-24.25]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-24.25]
<lotuspsychje> ok tnx apw we will investigate more then
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Bionic 18.04.3] (20190801) has been added
<rbalint> kenvandine, could you please verify LP: #1795959 on xenial? the package just aged enough
<ubot5> Launchpad bug 1795959 in ubuntu-meta (Ubuntu Xenial) "[FFe] Seed xdg-desktop-portal-gtk" [Medium,Fix committed] https://launchpad.net/bugs/1795959
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [5.0.0-24.25~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [5.0.0-24.25~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [arm64] (bionic-proposed/main) [5.0.0-24.25~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1012.12~18.04.2] (kernel)
<rbalint> hi, is this known? : Err:6 http://archive.ubuntu.com/ubuntu eoan/main ppc64el Packages 404  Not Found [IP: 91.189.88.162 80]
<cjwatson> rbalint: That is normal and has always been the case
<cjwatson> rbalint: ppc64el lives on ports
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1012.12~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [arm64] (bionic-proposed) [5.0.0-24.25~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [5.0.0-24.25~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [5.0.0-24.25~18.04.1]
-queuebot:#ubuntu-release- Unapproved: dkms (bionic-proposed/main) [2.3-3ubuntu9.4 => 2.3-3ubuntu9.5] (kubuntu, ubuntu-desktop)
<LocutusOfBorg> sil2100, ^^ can you please approve that one? the last upload is a regression-update one :/
<LocutusOfBorg> (I just discovered on one of my severs! and the fix works)
<sil2100> LocutusOfBorg: hey! Let me take a look in a moment ;)
<LocutusOfBorg> thanks!
<kenvandine> rbalint: will do!
<kenvandine> rbalint: done
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [s390x] (eoan-proposed) [2.10.0-0ubuntu1]
-queuebot:#ubuntu-release- New source: zsys (eoan-proposed/primary) [0.1]
-queuebot:#ubuntu-release- Unapproved: ibus (bionic-proposed/main) [1.5.17-3ubuntu4 => 1.5.17-3ubuntu5] (input-methods, kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.2.0-10.11] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1017.19] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.2.0-10.11] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.2.0-10.11] (core, kernel)
<Eickmeyer> Any AA out there to quickly review raysession in NEW?
<vorlon> source package reviews are never quick
<Eickmeyer> Well, compared to some of my past packages, this one should be relatively easy.
-queuebot:#ubuntu-release- New: accepted octomap [arm64] (eoan-proposed) [1.9.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted octomap [armhf] (eoan-proposed) [1.9.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted octomap [amd64] (eoan-proposed) [1.9.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted octomap [ppc64el] (eoan-proposed) [1.9.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted octomap [i386] (eoan-proposed) [1.9.0+dfsg-2]
-queuebot:#ubuntu-release- New: accepted octomap [s390x] (eoan-proposed) [1.9.0+dfsg-2]
<tjaalton> any AA, please ack xrdp-hwe-18.04 from the NEW queue
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Bionic 18.04.3] (20190801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Bionic 18.04.3] (20190801) has been added
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.2.0-10.11]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.2.0-10.11]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.2.0-10.11]
<RikMills> if anyone can look at binary new, plasma-discover is just us catching up with how debian did a slight swerve, and named the snap and flatpak backends in different way
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1017.19]
-queuebot:#ubuntu-release- New binary: debian-multimedia [amd64] (eoan-proposed/universe) [0.7ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: android-platform-build [i386] (eoan-proposed/universe) [1:8.1.0+r23-3] (no packageset)
-queuebot:#ubuntu-release- New binary: django-pagination [amd64] (eoan-proposed/universe) [1.0.7-3] (no packageset)
-queuebot:#ubuntu-release- New binary: cfitsio [s390x] (eoan-proposed/universe) [3.470-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: configparser [amd64] (eoan-proposed/universe) [3.5.0b2-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: cfitsio [i386] (eoan-proposed/universe) [3.470-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: contextlib2 [amd64] (eoan-proposed/main) [0.5.5-3] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: android-platform-build [amd64] (eoan-proposed/universe) [1:8.1.0+r23-3] (no packageset)
-queuebot:#ubuntu-release- New binary: cfitsio [armhf] (eoan-proposed/universe) [3.470-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: liblouisutdml [s390x] (eoan-proposed/main) [2.7.1-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: android-platform-build [armhf] (eoan-proposed/universe) [1:8.1.0+r23-3] (no packageset)
-queuebot:#ubuntu-release- New binary: liblouisutdml [amd64] (eoan-proposed/main) [2.7.1-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: cfitsio [amd64] (eoan-proposed/universe) [3.470-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: erlang-metrics [s390x] (eoan-proposed/universe) [2.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cfitsio [arm64] (eoan-proposed/universe) [3.470-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: rust-cairo-rs [s390x] (eoan-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-p1-mqtree [s390x] (eoan-proposed/universe) [1.0.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gio [s390x] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: android-platform-build [arm64] (eoan-proposed/universe) [1:8.1.0+r23-3] (no packageset)
-queuebot:#ubuntu-release- New binary: liblouisutdml [arm64] (eoan-proposed/main) [2.7.1-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: haskell-first-class-families [s390x] (eoan-proposed/universe) [0.5.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: liblouisutdml [ppc64el] (eoan-proposed/main) [2.7.1-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: rust-cairo-rs [amd64] (eoan-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-metrics [amd64] (eoan-proposed/universe) [2.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gio [amd64] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-filepattern [s390x] (eoan-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wcwidth [amd64] (eoan-proposed/universe) [0.1.7+dfsg1-5] (no packageset)
-queuebot:#ubuntu-release- New binary: caftools [s390x] (eoan-proposed/multiverse) [2.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-p1-mqtree [amd64] (eoan-proposed/universe) [1.0.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-first-class-families [amd64] (eoan-proposed/universe) [0.5.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-inspection-testing [s390x] (eoan-proposed/universe) [0.4.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-raw-strings-qq [s390x] (eoan-proposed/universe) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-validity-containers [s390x] (eoan-proposed/universe) [0.3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-metrics [i386] (eoan-proposed/universe) [2.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-heaps [s390x] (eoan-proposed/universe) [0.3.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-time-manager [s390x] (eoan-proposed/universe) [0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-p1-mqtree [armhf] (eoan-proposed/universe) [1.0.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cairo-rs [armhf] (eoan-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-microspec [s390x] (eoan-proposed/universe) [0.2.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-p1-mqtree [i386] (eoan-proposed/universe) [1.0.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-b2sdk [amd64] (eoan-proposed/universe) [1.0.0~rc1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-html-proofer [amd64] (eoan-proposed/universe) [3.11.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-sop-core [s390x] (eoan-proposed/universe) [0.4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cairo-rs [arm64] (eoan-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-pythonjsonlogger [amd64] (eoan-proposed/universe) [0.1.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-metrics [arm64] (eoan-proposed/universe) [2.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-first-class-families [i386] (eoan-proposed/universe) [0.5.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-jekyll-include-cache [amd64] (eoan-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gio [i386] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-metrics [armhf] (eoan-proposed/universe) [2.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cairo-rs [i386] (eoan-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-jekyll-commonmark [amd64] (eoan-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-p1-mqtree [arm64] (eoan-proposed/universe) [1.0.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-jekyll-github-metadata [amd64] (eoan-proposed/universe) [2.12.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-jekyll-optional-front-matter [amd64] (eoan-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-jekyll-redirect-from [amd64] (eoan-proposed/universe) [0.15.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-jekyll-seo-tag [amd64] (eoan-proposed/universe) [2.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-sassc [amd64] (eoan-proposed/universe) [2.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-jekyll-avatar [amd64] (eoan-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-jekyll-paginate-v2 [amd64] (eoan-proposed/universe) [1.9.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-jekyll-titles-from-headings [amd64] (eoan-proposed/universe) [0.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-jekyll-last-modified-at [amd64] (eoan-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gio [arm64] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-jekyll-remote-theme [amd64] (eoan-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-first-class-families [arm64] (eoan-proposed/universe) [0.5.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-gio [armhf] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zynaddsubfx [amd64] (eoan-proposed/universe) [3.0.5-1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: haskell-first-class-families [armhf] (eoan-proposed/universe) [0.5.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-inspection-testing [amd64] (eoan-proposed/universe) [0.4.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: zynaddsubfx [i386] (eoan-proposed/universe) [3.0.5-1] (ubuntustudio)
-queuebot:#ubuntu-release- New binary: haskell-heaps [amd64] (eoan-proposed/universe) [0.3.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-telegram-bot-api [amd64] (eoan-proposed/universe) [1.3.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-heaps [i386] (eoan-proposed/universe) [0.3.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-sop-core [i386] (eoan-proposed/universe) [0.4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-time-manager [i386] (eoan-proposed/universe) [0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-validity-containers [i386] (eoan-proposed/universe) [0.3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-inspection-testing [i386] (eoan-proposed/universe) [0.4.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-validity-containers [amd64] (eoan-proposed/universe) [0.3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-time-manager [amd64] (eoan-proposed/universe) [0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: caftools [amd64] (eoan-proposed/multiverse) [2.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-sop-core [amd64] (eoan-proposed/universe) [0.4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: caftools [i386] (eoan-proposed/multiverse) [2.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-nox [amd64] (eoan-proposed/universe) [2019.5.30-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-heaps [arm64] (eoan-proposed/universe) [0.3.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-validity-containers [arm64] (eoan-proposed/universe) [0.3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-time-manager [arm64] (eoan-proposed/universe) [0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-validity-containers [armhf] (eoan-proposed/universe) [0.3.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-heaps [armhf] (eoan-proposed/universe) [0.3.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-inspection-testing [arm64] (eoan-proposed/universe) [0.4.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: caftools [arm64] (eoan-proposed/multiverse) [2.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-sop-core [arm64] (eoan-proposed/universe) [0.4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: caftools [armhf] (eoan-proposed/multiverse) [2.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-time-manager [armhf] (eoan-proposed/universe) [0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: cfitsio [ppc64el] (eoan-proposed/universe) [3.470-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: haskell-inspection-testing [armhf] (eoan-proposed/universe) [0.4.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-sop-core [armhf] (eoan-proposed/universe) [0.4.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: starpu-contrib [amd64] (eoan-proposed/multiverse) [1.3.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Bionic 18.04.3] (20190801) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Bionic 18.04.3] (20190801) has been added
<wxl> when are we estimating release of 18.04.3?
<vorlon> wxl: next Thursday (as discussed today on #ubuntu-devel, but not yet announced; --> infinity)
<wxl> vorlon: thanks!
-queuebot:#ubuntu-release- New: accepted caftools [arm64] (eoan-proposed) [2.0.2-2]
-queuebot:#ubuntu-release- New: accepted cfitsio [ppc64el] (eoan-proposed) [3.470-1]
-queuebot:#ubuntu-release- New: accepted haskell-inspection-testing [arm64] (eoan-proposed) [0.4.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-sop-core [arm64] (eoan-proposed) [0.4.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-time-manager [armhf] (eoan-proposed) [0.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-validity-containers [armhf] (eoan-proposed) [0.3.1.0-1]
-queuebot:#ubuntu-release- New binary: android-platform-build [arm64] (eoan-proposed/universe) [1:8.1.0+r23-3] (no packageset)
-queuebot:#ubuntu-release- New binary: liblouisutdml [arm64] (eoan-proposed/main) [2.7.1-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: rust-gio [s390x] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted caftools [armhf] (eoan-proposed) [2.0.2-2]
-queuebot:#ubuntu-release- New: accepted haskell-inspection-testing [armhf] (eoan-proposed) [0.4.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-validity-containers [arm64] (eoan-proposed) [0.3.1.0-1]
-queuebot:#ubuntu-release- New binary: haskell-first-class-families [s390x] (eoan-proposed/universe) [0.5.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-heaps [armhf] (eoan-proposed) [0.3.6.1-1]
-queuebot:#ubuntu-release- New: accepted starpu-contrib [amd64] (eoan-proposed) [1.3.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted haskell-sop-core [armhf] (eoan-proposed) [0.4.0.0-1]
-queuebot:#ubuntu-release- New binary: liblouisutdml [ppc64el] (eoan-proposed/main) [2.7.1-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted caftools [amd64] (eoan-proposed) [2.0.2-2]
-queuebot:#ubuntu-release- New: accepted haskell-first-class-families [armhf] (eoan-proposed) [0.5.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-heaps [i386] (eoan-proposed) [0.3.6.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-inspection-testing [i386] (eoan-proposed) [0.4.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-sop-core [i386] (eoan-proposed) [0.4.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-time-manager [arm64] (eoan-proposed) [0.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-validity-containers [amd64] (eoan-proposed) [0.3.1.0-1]
-queuebot:#ubuntu-release- New: accepted node-telegram-bot-api [amd64] (eoan-proposed) [1.3.3-1]
-queuebot:#ubuntu-release- New binary: android-platform-build [armhf] (eoan-proposed/universe) [1:8.1.0+r23-3] (no packageset)
-queuebot:#ubuntu-release- New binary: configparser [amd64] (eoan-proposed/universe) [3.5.0b2-2] (kubuntu)
-queuebot:#ubuntu-release- New: accepted caftools [i386] (eoan-proposed) [2.0.2-2]
-queuebot:#ubuntu-release- New: accepted haskell-inspection-testing [amd64] (eoan-proposed) [0.4.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-time-manager [amd64] (eoan-proposed) [0.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-validity-containers [i386] (eoan-proposed) [0.3.1.0-1]
-queuebot:#ubuntu-release- New binary: cfitsio [i386] (eoan-proposed/universe) [3.470-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: liblouisutdml [amd64] (eoan-proposed/main) [2.7.1-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: rust-cairo-rs [ppc64el] (eoan-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-heaps [arm64] (eoan-proposed) [0.3.6.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-time-manager [i386] (eoan-proposed) [0.0.0-1]
-queuebot:#ubuntu-release- New binary: contextlib2 [amd64] (eoan-proposed/main) [0.5.5-3] (ubuntu-server)
-queuebot:#ubuntu-release- New: accepted haskell-sop-core [amd64] (eoan-proposed) [0.4.0.0-1]
-queuebot:#ubuntu-release- New binary: liblouisutdml [s390x] (eoan-proposed/main) [2.7.1-1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted python-nox [amd64] (eoan-proposed) [2019.5.30-1]
-queuebot:#ubuntu-release- New: accepted erlang-p1-mqtree [arm64] (eoan-proposed) [1.0.3-2]
-queuebot:#ubuntu-release- New: accepted haskell-heaps [amd64] (eoan-proposed) [0.3.6.1-1]
-queuebot:#ubuntu-release- New: accepted ruby-jekyll-github-metadata [amd64] (eoan-proposed) [2.12.1-1]
-queuebot:#ubuntu-release- New: accepted ruby-jekyll-optional-front-matter [amd64] (eoan-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-jekyll-redirect-from [amd64] (eoan-proposed) [0.15.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-jekyll-seo-tag [amd64] (eoan-proposed) [2.6.1-1]
-queuebot:#ubuntu-release- New: accepted ruby-sassc [amd64] (eoan-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-gio [armhf] (eoan-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted zynaddsubfx [i386] (eoan-proposed) [3.0.5-1]
-queuebot:#ubuntu-release- New binary: plasma-discover [amd64] (eoan-proposed/universe) [5.16.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted haskell-first-class-families [arm64] (eoan-proposed) [0.5.0.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-jekyll-last-modified-at [amd64] (eoan-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-jekyll-remote-theme [amd64] (eoan-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-gio [arm64] (eoan-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New source: backport-iwlwifi-dkms (eoan-proposed/primary) [7906-0ubuntu1]
-queuebot:#ubuntu-release- New binary: plasma-discover [s390x] (eoan-proposed/universe) [5.16.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New source: rtl8821ce (eoan-proposed/primary) [5.2.5.2.1.30816.20190425-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ruby-jekyll-avatar [amd64] (eoan-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-jekyll-titles-from-headings [amd64] (eoan-proposed) [0.5.1-1]
-queuebot:#ubuntu-release- New binary: plasma-discover [i386] (eoan-proposed/universe) [5.16.4-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: rust-gio [ppc64el] (eoan-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ruby-jekyll-paginate-v2 [amd64] (eoan-proposed) [1.9.4-1]
-queuebot:#ubuntu-release- New source: raysession (eoan-proposed/primary) [0.7.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted zynaddsubfx [amd64] (eoan-proposed) [3.0.5-1]
-queuebot:#ubuntu-release- New: accepted caftools [s390x] (eoan-proposed) [2.0.2-2]
-queuebot:#ubuntu-release- New: accepted django-pagination [amd64] (eoan-proposed) [1.0.7-3]
-queuebot:#ubuntu-release- New: accepted erlang-metrics [armhf] (eoan-proposed) [2.5.0-1]
-queuebot:#ubuntu-release- New: accepted erlang-p1-mqtree [i386] (eoan-proposed) [1.0.3-2]
-queuebot:#ubuntu-release- New: accepted haskell-first-class-families [i386] (eoan-proposed) [0.5.0.0-1]
-queuebot:#ubuntu-release- New: accepted python-b2sdk [amd64] (eoan-proposed) [1.0.0~rc1-1]
-queuebot:#ubuntu-release- New: accepted ruby-html-proofer [amd64] (eoan-proposed) [3.11.1-1]
-queuebot:#ubuntu-release- New: accepted ruby-jekyll-include-cache [amd64] (eoan-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-cairo-rs [armhf] (eoan-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-gio [i386] (eoan-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted contextlib2 [amd64] (eoan-proposed) [0.5.5-3]
-queuebot:#ubuntu-release- New: accepted erlang-p1-mqtree [amd64] (eoan-proposed) [1.0.3-2]
-queuebot:#ubuntu-release- New: accepted haskell-sop-core [s390x] (eoan-proposed) [0.4.0.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-jekyll-commonmark [amd64] (eoan-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-cairo-rs [i386] (eoan-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New binary: erlang-p1-mqtree [ppc64el] (eoan-proposed/universe) [1.0.3-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted erlang-metrics [arm64] (eoan-proposed) [2.5.0-1]
-queuebot:#ubuntu-release- New: accepted python-pythonjsonlogger [amd64] (eoan-proposed) [0.1.11-1]
-queuebot:#ubuntu-release- New binary: erlang-metrics [ppc64el] (eoan-proposed/universe) [2.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-first-class-families [amd64] (eoan-proposed) [0.5.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-cairo-rs [arm64] (eoan-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted erlang-metrics [amd64] (eoan-proposed) [2.5.0-1]
-queuebot:#ubuntu-release- New: accepted erlang-p1-mqtree [armhf] (eoan-proposed) [1.0.3-2]
-queuebot:#ubuntu-release- New: accepted haskell-heaps [s390x] (eoan-proposed) [0.3.6.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-microspec [s390x] (eoan-proposed) [0.2.1.3-1]
-queuebot:#ubuntu-release- New: accepted haskell-time-manager [s390x] (eoan-proposed) [0.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-gio [amd64] (eoan-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted erlang-metrics [i386] (eoan-proposed) [2.5.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-inspection-testing [s390x] (eoan-proposed) [0.4.2.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-validity-containers [s390x] (eoan-proposed) [0.3.1.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-filepattern [s390x] (eoan-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New binary: haskell-first-class-families [ppc64el] (eoan-proposed/universe) [0.5.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-raw-strings-qq [s390x] (eoan-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-cairo-rs [amd64] (eoan-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted wcwidth [amd64] (eoan-proposed) [0.1.7+dfsg1-5]
-queuebot:#ubuntu-release- New: accepted erlang-metrics [ppc64el] (eoan-proposed) [2.5.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-first-class-families [ppc64el] (eoan-proposed) [0.5.0.0-1]
-queuebot:#ubuntu-release- New: accepted erlang-p1-mqtree [ppc64el] (eoan-proposed) [1.0.3-2]
-queuebot:#ubuntu-release- New: accepted android-platform-build [arm64] (eoan-proposed) [1:8.1.0+r23-3]
-queuebot:#ubuntu-release- New: accepted erlang-metrics [s390x] (eoan-proposed) [2.5.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-first-class-families [s390x] (eoan-proposed) [0.5.0.0-1]
-queuebot:#ubuntu-release- New: accepted liblouisutdml [ppc64el] (eoan-proposed) [2.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-cairo-rs [s390x] (eoan-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-gio [s390x] (eoan-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted cfitsio [amd64] (eoan-proposed) [3.470-1]
-queuebot:#ubuntu-release- New: accepted liblouisutdml [arm64] (eoan-proposed) [2.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-gio [ppc64el] (eoan-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted erlang-p1-mqtree [s390x] (eoan-proposed) [1.0.3-2]
-queuebot:#ubuntu-release- New: accepted rust-cairo-rs [ppc64el] (eoan-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted android-platform-build [amd64] (eoan-proposed) [1:8.1.0+r23-3]
-queuebot:#ubuntu-release- New: accepted android-platform-build [i386] (eoan-proposed) [1:8.1.0+r23-3]
-queuebot:#ubuntu-release- New: accepted cfitsio [armhf] (eoan-proposed) [3.470-1]
-queuebot:#ubuntu-release- New: accepted cfitsio [s390x] (eoan-proposed) [3.470-1]
-queuebot:#ubuntu-release- New: accepted liblouisutdml [amd64] (eoan-proposed) [2.7.1-1]
-queuebot:#ubuntu-release- New: accepted android-platform-build [armhf] (eoan-proposed) [1:8.1.0+r23-3]
-queuebot:#ubuntu-release- New: accepted cfitsio [i386] (eoan-proposed) [3.470-1]
-queuebot:#ubuntu-release- New: accepted liblouisutdml [s390x] (eoan-proposed) [2.7.1-1]
-queuebot:#ubuntu-release- New: accepted cfitsio [arm64] (eoan-proposed) [3.470-1]
-queuebot:#ubuntu-release- New: accepted configparser [amd64] (eoan-proposed) [3.5.0b2-2]
<vorlon> Eickmeyer: I see on raysession that debian/copyright lists GPL-2.0+ as the license.  However, in all of the source tree there is only a single python file that lists a copyright header and states that it is GPL-2.0+, and that file doesn't even have the same author as listed in debian/copyright
<vorlon> Eickmeyer: so what is the basis for believing this is released under GPL-2.0+ as opposed to GPL-2.0?
<vorlon> teward: ^^
<vorlon> Eickmeyer: also, since the copyright holder of ./src/shared/jacklib.py is NOT listed in debian/copyright, that's a GPL violation, and will need to be fixed
<teward> Project as a whole would be why the license rationale was used
<teward> rather than individual authorships
<vorlon> that is not a valid rationale
<teward> Not saying it is
<teward> I fast read unfortunatey
<teward> Let me catch up
<teward> E:4hrsSleep, No Energy
<vorlon> I'm also currently checking to see if the debs this outputs have sane dependencies; it looks to me like they'll be missing the proper dep on the python interpreter
<Eickmeyer[m]> At a Dr appointment will get back to you.
 * vorlon nods
<teward> Now see i asked these questions and the team said it met the runtime deps thing.  As for GPL-2.0+ justifications ask Eickmeyer they said they had the copyrights in line at the time of upload.
<vorlon> "the team"?
<teward> and they did most of the package work afaict
<teward> Studio Team
<teward> Remember: 4 hours sleep my speech isnt coherent as much today
<vorlon> ok well they appear to be mistaken
<vorlon>  Depends: python3-liblo, python3-pyqt5
<vorlon> the lintian overrides here are wrong and must be removed
<vorlon> and the python3 dep added
<vorlon> because the programs in usr/bin do nothing except exec the scripts under usr/share which the lintian override claims "are not meant to be executable"
<teward> *yawns* bleh i need more sleep... think i need to be hypercritical in my analysis of the Studio Teamâs work now - disable overrides and read through the overrides and the reasoning for it as well as others
-queuebot:#ubuntu-release- New: rejected raysession [source] (eoan-proposed) [0.7.2-0ubuntu1]
<teward> vorlon: i think i see why they didnt add the dep though because rdeps of runtime deps pull in the interpreter
<teward> But i agree with you
<vorlon> yes, it will be pulled in indirectly, but one shouldn't rely on that
<teward> *yawns* I am going to go find the largest mountain dew I can obtain to wake up.
<teward> I think theres an unopened 2Liter in the fridge
<teward> vorlon: can you do me a solid and check the github url in the debian/watch file?
<teward> for that package
<teward> and provide it.  cant from this phone
<teward> want to verify license stuffs
<teward> now that I have downed a 20oz of mountain dew and am on another one
<teward> https://github.com/Houston4444/RaySession/blob/master/COPYING  vorlon: gpl2 license defined here for the project overall, which is the justification I believe for GPL2
<teward> upstream anyways.  agreed violation by not listing the jacklib copyright though
<teward> Agreed the 2.0+ is wrong too
<teward> Sorrry playing catchup lol
<vorlon> teward: right, sounds like we're on the same page
<teward> yep.  still playing catchup right now on 50 tasks.
<teward> including this.  and not having enough sleep doesnt help :P
<Eickmeyer> teward, vorlon: not pushed yet, but I added a stanza for jacklib.py (which is 2.0+ from what I can tell), but since, other than that, I know that this project is by a single author, and used the COPYING file accordingly. If 2.0+ is wrong, then what is it?
-queuebot:#ubuntu-release- New: accepted plasma-discover [amd64] (eoan-proposed) [5.16.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-discover [armhf] (eoan-proposed) [5.16.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-discover [ppc64el] (eoan-proposed) [5.16.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-discover [arm64] (eoan-proposed) [5.16.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-discover [s390x] (eoan-proposed) [5.16.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-discover [i386] (eoan-proposed) [5.16.4-0ubuntu1]
<teward> Eickmeyer: ==2.0
<teward> 2.0 isnt 2.0+
<Eickmeyer> OK, will fix.
<Eickmeyer> teward, vorlon: Also, with out the lintian-overrides, even with the python3 dep, it was throwing warnings like crazy, hence the overrides. Why would that be?
<vorlon> don't know without digging into ti
<vorlon> it
<vorlon> were they the same warnings?
<Eickmeyer> Yes.
<teward> Because you arent lintian compliant, vorlon exampled you such a case
<teward> Of binaries just executing usr/share scripts and such which is bad.
<Eickmeyer> Ok, commented-out the overrides, fixed the copyright, rechecking.
<Eickmeyer> Ok, no warnings this time. Must've done something right. Â¯\_(ã)_/Â¯
<Eickmeyer> teward: pushed.
<teward> I will look tomorrow.  Been in all day meetings and trainings and had only 4hrs sleep last night only reason awake is a buttload of mountain dew.
<teward> So sleeep is requires
<teward> Bleh so tired i cant type xD
-queuebot:#ubuntu-release- New binary: budgie-extras [i386] (eoan-proposed/universe) [0.9.0-1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: budgie-extras [s390x] (eoan-proposed/universe) [0.9.0-1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: budgie-extras [amd64] (eoan-proposed/universe) [0.9.0-1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: budgie-extras [ppc64el] (eoan-proposed/universe) [0.9.0-1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: budgie-extras [arm64] (eoan-proposed/universe) [0.9.0-1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: budgie-extras [armhf] (eoan-proposed/universe) [0.9.0-1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- New binary: haskell-type-errors [amd64] (eoan-proposed/universe) [0.2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-type-errors [s390x] (eoan-proposed/universe) [0.2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-type-errors [ppc64el] (eoan-proposed/universe) [0.2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted budgie-extras [amd64] (eoan-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted budgie-extras [armhf] (eoan-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-type-errors [amd64] (eoan-proposed) [0.2.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-type-errors [s390x] (eoan-proposed) [0.2.0.0-1]
-queuebot:#ubuntu-release- New: accepted budgie-extras [arm64] (eoan-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-type-errors [ppc64el] (eoan-proposed) [0.2.0.0-1]
-queuebot:#ubuntu-release- New: accepted budgie-extras [ppc64el] (eoan-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted budgie-extras [i386] (eoan-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New binary: haskell-type-errors [i386] (eoan-proposed/universe) [0.2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted budgie-extras [s390x] (eoan-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New binary: haskell-type-errors [arm64] (eoan-proposed/universe) [0.2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-type-errors [armhf] (eoan-proposed/universe) [0.2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-type-errors [arm64] (eoan-proposed) [0.2.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-type-errors [i386] (eoan-proposed) [0.2.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-type-errors [armhf] (eoan-proposed) [0.2.0.0-1]
-queuebot:#ubuntu-release- New binary: python-zipp [amd64] (eoan-proposed/universe) [0.5.2-2] (no packageset)
<vorlon> infinity: I think https://bugs.launchpad.net/dkms/+bug/1828948 might be a blocker for the point release, to have working dkms in
<ubot5> Ubuntu bug 1828948 in dkms (Ubuntu Bionic) "OBSOLETE_BY in DKMS.CONF does not work" [High,In progress]
<cyphermox> LocutusOfBorg: your dkms upload for bionic still missing a small fix
<cyphermox> I am uploading it
<cyphermox> (cf. bug 1838245)
<ubot5> bug 1838245 in DKMS "dkms script is missing function find_module" [Undecided,In progress] https://launchpad.net/bugs/1838245
-queuebot:#ubuntu-release- Unapproved: rejected dkms [source] (bionic-proposed) [2.3-3ubuntu9.5]
-queuebot:#ubuntu-release- Unapproved: dkms (bionic-proposed/main) [2.3-3ubuntu9.4 => 2.3-3ubuntu9.5] (kubuntu, ubuntu-desktop)
<LocutusOfBorg> cyphermox, I think both solutions works, I like your one :)
<LocutusOfBorg> it is more coherent with the other dkms code :D
<cyphermox> LocutusOfBorg: oh, well that part was lazy more than anything
<cyphermox> LocutusOfBorg: the issue was the logic of the || return 0 which should be &&return 0
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Bionic 18.04.3] (20190801) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Bionic 18.04.3] (20190801) has been added
-queuebot:#ubuntu-release- New: rejected rtl8821ce [source] (eoan-proposed) [5.2.5.2.1.30816.20190425-0ubuntu1]
-queuebot:#ubuntu-release- New binary: rabbitvcs [amd64] (eoan-proposed/universe) [0.17.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: welle.io [amd64] (eoan-proposed/universe) [2.0~beta1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: welle.io [s390x] (eoan-proposed/universe) [2.0~beta1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: welle.io [i386] (eoan-proposed/universe) [2.0~beta1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: welle.io [arm64] (eoan-proposed/universe) [2.0~beta1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: welle.io [armhf] (eoan-proposed/universe) [2.0~beta1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: welle.io [ppc64el] (eoan-proposed/universe) [2.0~beta1-1] (no packageset)
#ubuntu-release 2019-08-02
-queuebot:#ubuntu-release- New: accepted node-react [amd64] (eoan-proposed) [16.2.0-3build1]
-queuebot:#ubuntu-release- New binary: node-react-audio-player [amd64] (eoan-proposed/universe) [0.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted debian-multimedia [amd64] (eoan-proposed) [0.7ubuntu1]
-queuebot:#ubuntu-release- New: accepted node-react-audio-player [amd64] (eoan-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New: accepted rabbitvcs [amd64] (eoan-proposed) [0.17.1-2]
-queuebot:#ubuntu-release- New: accepted welle.io [arm64] (eoan-proposed) [2.0~beta1-1]
-queuebot:#ubuntu-release- New: accepted welle.io [i386] (eoan-proposed) [2.0~beta1-1]
-queuebot:#ubuntu-release- New: accepted welle.io [s390x] (eoan-proposed) [2.0~beta1-1]
-queuebot:#ubuntu-release- New: accepted python-zipp [amd64] (eoan-proposed) [0.5.2-2]
-queuebot:#ubuntu-release- New: accepted welle.io [armhf] (eoan-proposed) [2.0~beta1-1]
-queuebot:#ubuntu-release- New: accepted welle.io [amd64] (eoan-proposed) [2.0~beta1-1]
-queuebot:#ubuntu-release- New: accepted welle.io [ppc64el] (eoan-proposed) [2.0~beta1-1]
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Bionic 18.04.3] (20190802) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Bionic 18.04.3] (20190802) has been added
<bluesabre> oh, 18.04.3 is here
<bluesabre> :)
-queuebot:#ubuntu-release- Unapproved: partman-base (bionic-proposed/main) [192ubuntu1 => 192ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: partman-base (disco-proposed/main) [206ubuntu1 => 206ubuntu1.1] (core)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Bionic 18.04.3] (20190802) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Bionic 18.04.3] (20190802) has been added
-queuebot:#ubuntu-release- New binary: python-importlib-metadata [amd64] (eoan-proposed/universe) [0.18-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-importlib-metadata [amd64] (eoan-proposed) [0.18-2]
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Bionic 18.04.3] (20190802) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Bionic 18.04.3] (20190802) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Bionic 18.04.3] (20190802) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Bionic 18.04.3] (20190802) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Bionic 18.04.3] (20190802) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Bionic 18.04.3] (20190802) has been added
 * infinity looks sideways at those builds.
<infinity> I said I'd do them tonight, I guess someone got impatient?
<vorlon> is it because dailies weren't turned off in cron?
<vorlon> the timing is rather spread out, looking like the regular jobs rather than a manual batch
-queuebot:#ubuntu-release- New binary: r-cran-ggbeeswarm [amd64] (eoan-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lasso2 [i386] (eoan-proposed/universe) [1.2-20-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-packrat [amd64] (eoan-proposed/universe) [0.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pan [i386] (eoan-proposed/universe) [1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-sodium [amd64] (eoan-proposed/universe) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lasso2 [amd64] (eoan-proposed/universe) [1.2-20-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pan [amd64] (eoan-proposed/universe) [1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-sodium [i386] (eoan-proposed/universe) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lasso2 [s390x] (eoan-proposed/universe) [1.2-20-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-polycor [amd64] (eoan-proposed/universe) [0.7-9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ggdendro [amd64] (eoan-proposed/universe) [0.1-20+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-sodium [s390x] (eoan-proposed/universe) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pan [s390x] (eoan-proposed/universe) [1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lasso2 [arm64] (eoan-proposed/universe) [1.2-20-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pan [armhf] (eoan-proposed/universe) [1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lasso2 [armhf] (eoan-proposed/universe) [1.2-20-1] (no packageset)
<infinity> infinity: Well, sure, but it also means someone created the milestone in the tracker, which I was going to do, like, now. :P
<infinity> Err.
<infinity> vorlon: ^
 * infinity shrugs.
-queuebot:#ubuntu-release- New binary: r-cran-pan [arm64] (eoan-proposed/universe) [1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-sodium [armhf] (eoan-proposed/universe) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-sodium [arm64] (eoan-proposed/universe) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-lasso2 [ppc64el] (eoan-proposed/universe) [1.2-20-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pan [ppc64el] (eoan-proposed/universe) [1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-sodium [ppc64el] (eoan-proposed/universe) [1.1-1] (no packageset)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Bionic 18.04.3] (20190802) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Bionic 18.04.3] (20190802) has been added
-queuebot:#ubuntu-release- Unapproved: rejected horizon [source] (disco-proposed) [3:15.1.0-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (bionic-proposed) [2.3-3ubuntu9.5]
-queuebot:#ubuntu-release- New: accepted r-cran-sodium [ppc64el] (eoan-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ggdendro [amd64] (eoan-proposed) [0.1-20+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lasso2 [armhf] (eoan-proposed) [1.2-20-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pan [arm64] (eoan-proposed) [1.6-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pan [ppc64el] (eoan-proposed) [1.6-1]
-queuebot:#ubuntu-release- New: accepted r-cran-sodium [arm64] (eoan-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-sodium [s390x] (eoan-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lasso2 [arm64] (eoan-proposed) [1.2-20-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pan [armhf] (eoan-proposed) [1.6-1]
-queuebot:#ubuntu-release- New: accepted r-cran-sodium [armhf] (eoan-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lasso2 [ppc64el] (eoan-proposed) [1.2-20-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pan [s390x] (eoan-proposed) [1.6-1]
-queuebot:#ubuntu-release- New: accepted r-cran-ggbeeswarm [amd64] (eoan-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lasso2 [i386] (eoan-proposed) [1.2-20-1]
-queuebot:#ubuntu-release- New: accepted r-cran-packrat [amd64] (eoan-proposed) [0.5.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pan [i386] (eoan-proposed) [1.6-1]
-queuebot:#ubuntu-release- New: accepted r-cran-sodium [amd64] (eoan-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lasso2 [amd64] (eoan-proposed) [1.2-20-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pan [amd64] (eoan-proposed) [1.6-1]
-queuebot:#ubuntu-release- New: accepted r-cran-sodium [i386] (eoan-proposed) [1.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-lasso2 [s390x] (eoan-proposed) [1.2-20-1]
-queuebot:#ubuntu-release- New: accepted r-cran-polycor [amd64] (eoan-proposed) [0.7-9-1]
-queuebot:#ubuntu-release- Unapproved: accepted chrony [source] (disco-proposed) [3.4-1ubuntu1.1]
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Bionic 18.04.3] has been updated (20190802)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Bionic 18.04.3] has been updated (20190802)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Bionic 18.04.3] has been updated (20190802)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Bionic 18.04.3] has been updated (20190802)
-queuebot:#ubuntu-release- Unapproved: rejected snapd-glib [source] (xenial-proposed) [1.48-0ubuntu0.16.04.0]
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Bionic 18.04.3] has been updated (20190802)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi2 [Bionic 18.04.3] has been updated (20190802)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Bionic 18.04.3] has been updated (20190802)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Bionic 18.04.3] has been updated (20190802)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Bionic 18.04.3] has been updated (20190802)
-queuebot:#ubuntu-release- New binary: r-cran-rsconnect [amd64] (eoan-proposed/universe) [0.8.13-1] (no packageset)
<tjaalton> vorlon: bug 1838245 is verified, maybe worthy of fast-tracking it to updates?
<ubot5> bug 1838245 in DKMS "dkms script is missing function find_module" [Critical,In progress] https://launchpad.net/bugs/1838245
<apw> tjaalton, as a regression in -updates it looks pretty valid to do that
<tjaalton> right
<LocutusOfBorg> apw, since people are reporting dkms issues to virtualbox too, what about releasing also it?
<apw> LocutusOfBorg, in bionic ?
<LocutusOfBorg> #1835576
<LocutusOfBorg> yes
<LocutusOfBorg> LP: #1835576
<ubot5> Launchpad bug 1835576 in virtualbox-hwe (Ubuntu Bionic) "virtualbox-guest-dkms-hwe 5.2.18-dfsg-3~ubuntu18.04.3 fails to build on 5.0 based kernels [In function âVBoxGuest_RTR0MemUserIsValidAddrâ: error: macro "access_ok" passed 3 arguments, but takes just 2]" [Medium,Fix committed] https://launchpad.net/bugs/1835576
<apw> infinity, ^
<LocutusOfBorg> we got a few verifications done
<apw> (as we are in freeze for hte point release)
<infinity> apw: If it's not on media, I don't have a lock on it.
<infinity> apw: (as for dkms, +1)
<LocutusOfBorg> this is a serious regression for vbox users, the dkms module doesn't build with hwe kernel
<LocutusOfBorg> next time please ping *before* updating the kernel so we can push changes together :D
<apw> infinity, point, ack
<apw> LocutusOfBorg, assume we are updating it every three weeks on the cadance ...
<infinity> Isn't autopkgtesting meant to catch this sort of thing?
<apw> infinity, as far as i know it passed so that is confusing
<apw> infinity, oh unless it have never worked, that is possible; hmmm
<apw> infinity, anyhow i am inclined to say if it didn't work before, and is at least building, that releaseing it even on a friday is worth the risk
<infinity> Probably, yes.
<infinity> And it may well have "never worked" for 5.x, but I would assume it worked for 4.x, so maybe there's a regression tracking issue?
<apw> infinity, possibly indeed, i'll have to get a minion looking
<LocutusOfBorg> apw, I mean from 4 to 5
<LocutusOfBorg> not minor releases, dkms modules breaks with major updates
<LocutusOfBorg> (at least usually)
<apw> infinity, though it was a continuation of the same package, so it ought to have been caught
<LocutusOfBorg> just FTR, also this wifi driver is bad with the new hwe kernel
<LocutusOfBorg> https://launchpadlibrarian.net/434586587/rtl8812au_4.3.8.12175.20140902+dfsg-0ubuntu12~ubuntu18.04.1_source.changes
<LocutusOfBorg> I got reports from friends about this issue
<LocutusOfBorg> we should probably fix/test dkms reverse-dependencies *before* releasing the kernel :D
<apw> LocutusOfBorg, we are meant to, and the results i was given said that they were ... so that is a problem
<apw> LocutusOfBorg, the second bug is not verified, is that something that is easy
<apw> to do ?
<LocutusOfBorg> apw, yes it works
<LocutusOfBorg> I tested both guest-dkms and dkms but I forgot to update the second one
<LocutusOfBorg> apw, I don't know but...
<LocutusOfBorg> autopkgtest for virtualbox/5.2.18-dfsg-2~ubuntu18.04.5: amd64: Always failed, arm64: Always failed, armhf: Always failed, i386: Always failed, ppc64el: Always failed, s390x: Always failed
<LocutusOfBorg> autopkgtest for virtualbox-hwe/5.2.18-dfsg-3~ubuntu18.04.3: amd64: Always failed, arm64: Always failed, armhf: Always failed, i386: Always failed, ppc64el: Always failed, s390x: Always failed
<LocutusOfBorg> for linux/meta-hwe
<LocutusOfBorg> why is that?
<infinity> The britney statuses are lies.  You need to look at the kernel team's matrix for the real view.
<infinity> https://people.canonical.com/~kernel/status/adt-matrix/
<infinity> https://people.canonical.com/~kernel/status/adt-matrix/bionic-linux-meta-hwe.html
<infinity> And that definitely shows the regressions there.
<infinity> Some someone messed up.
<apw> infinity, indeed
<infinity> And in more than just the two we're talking about.
<apw> infinity, we'll get them sorted before release if at all possible
<infinity> apw: Please and thanks. :/
<infinity> apw: "Before release" isn't the concern even, it's people just apt upgrading right now, and their dkms modules suddenly asploding.
<apw> infinity, there is that indeed
<infinity> For non-boot/network-critical stuff, it's maybe slightly less urgent, but still super annoying when dkms bombs out with a build failure on upgrade.
<apw> infinity, i am inclined to release the virtualbox updates as soon as they are verified correctly
<infinity> +1
<LocutusOfBorg> apw, I did verify it
<apw> that sorts two of them, the others i suspect we have fixed already in later series so its 'not hard'
<LocutusOfBorg> btw please also accept rtl8812au if possible, so we have another dkms fix
<apw> LocutusOfBorg, the other bug ...https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1805651
<ubot5> Ubuntu bug 1805651 in virtualbox-hwe (Ubuntu Bionic) "VBoxNetNAT is missing suid bit" [Undecided,Fix committed]
<LocutusOfBorg> -rwsr-sr-x root/root    157776 2019-04-18 07:30 ./usr/lib/virtualbox/VBoxNetNAT
<apw> LocutusOfBorg, rigt but it is not marked so in the bug
<apw> so the tools say "no-releasy"
<LocutusOfBorg> sorry!
<LocutusOfBorg> I probably fixed in a previous sru
<apw> LocutusOfBorg, does not the 4.3.8.12175.20140902+dfsg-0ubuntu8.1 in -proposed already cover the 5.0 compatibility for rtl8812au ?
<LocutusOfBorg> apw, they are patches on top of that version
<LocutusOfBorg> they are needed but they need more patches for the new kernels
<apw> LocutusOfBorg, so i think we can release the one underneath to fix the issues that an official installation would need
<apw> LocutusOfBorg, and yours over the top to fix the next kernels coming down the pie
<apw> pipe
<apw> and indeed that is one of the options r-basak suggeted ok
<apw> i have minions making sure that one is confirmed
<LocutusOfBorg> apw, the only person who reported a regression was indeed a dkms failure https://bugs.launchpad.net/ubuntu/+source/virtualbox-hwe/+bug/1835576/comments/22
<ubot5> Ubuntu bug 1835576 in virtualbox-hwe (Ubuntu Bionic) "virtualbox-guest-dkms-hwe 5.2.18-dfsg-3~ubuntu18.04.3 fails to build on 5.0 based kernels [In function âVBoxGuest_RTR0MemUserIsValidAddrâ: error: macro "access_ok" passed 3 arguments, but takes just 2]" [Medium,Fix committed]
<LocutusOfBorg> so, vbox safe to go
<apw> LocutusOfBorg, do the other ones go with it, the ext-pack and additions-iso
<apw> LocutusOfBorg, or can they wait till monday safely
-queuebot:#ubuntu-release- New binary: r-cran-qpdf [s390x] (eoan-proposed/universe) [1.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mvnfast [s390x] (eoan-proposed/universe) [0.2.5+dfsg-1] (no packageset)
<LocutusOfBorg> apw, all together
<LocutusOfBorg> guest-additions contains the same dkms fixes, but they install in the oracle way
<LocutusOfBorg> ext-pack is tied with a specific vbox version
<LocutusOfBorg> so, release virtualbox virtualbox-hwe virtualbox-ext-pack and virtualbox-guest-additions-iso please :)
-queuebot:#ubuntu-release- New binary: r-cran-gridgraphics [amd64] (eoan-proposed/universe) [0.4-1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-logging [amd64] (eoan-proposed/universe) [0.9-107-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-tufte [amd64] (eoan-proposed/universe) [0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-hsaur3 [amd64] (eoan-proposed/universe) [1.0-9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-qpdf [amd64] (eoan-proposed/universe) [1.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-qpdf [i386] (eoan-proposed/universe) [1.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mvnfast [amd64] (eoan-proposed/universe) [0.2.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-qpdf [armhf] (eoan-proposed/universe) [1.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mvnfast [i386] (eoan-proposed/universe) [0.2.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-qpdf [arm64] (eoan-proposed/universe) [1.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mvnfast [arm64] (eoan-proposed/universe) [0.2.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mvnfast [armhf] (eoan-proposed/universe) [0.2.5+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-qpdf [ppc64el] (eoan-proposed/universe) [1.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mvnfast [ppc64el] (eoan-proposed/universe) [0.2.5+dfsg-1] (no packageset)
<Laney> no delay announcements, and then two come along at once :P
-queuebot:#ubuntu-release- New binary: libmaus2 [amd64] (eoan-proposed/universe) [2.0.611-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmaus2 [i386] (eoan-proposed/universe) [2.0.611-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmaus2 [ppc64el] (eoan-proposed/universe) [2.0.611-1] (no packageset)
#ubuntu-release 2019-08-03
-queuebot:#ubuntu-release- New binary: qgis [s390x] (eoan-proposed/universe) [3.4.10+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [i386] (eoan-proposed/universe) [3.4.10+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [ppc64el] (eoan-proposed/universe) [3.4.10+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmaus2 [arm64] (eoan-proposed/universe) [2.0.611-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [amd64] (eoan-proposed/universe) [3.4.10+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmaus2 [armhf] (eoan-proposed/universe) [2.0.611-1] (no packageset)
<tsimonq2> infinity: Is there any chance you'd let us have bug 1812594 in -updates early so we can get it in for the point release?
<ubot5> bug 1812594 in lubuntu-default-settings (Ubuntu Bionic) "Lubuntu 18.04 mistakenly sets the default lock problem to lxlock instead of light-locker" [Medium,Fix committed] https://launchpad.net/bugs/1812594
<tsimonq2> infinity: Or when it's released on Wednesday I could respin. ;P
<tsimonq2> Er, Tuesday.
<infinity> tsimonq2: We can push it out Monday before RCs spin up.  Remind me then.
<tsimonq2> infinity: Will do, thanks.
<infinity> tsimonq2: OOI, why was the solution not "install lxlock"?
<tsimonq2> infinity: We don't want to have to maintain two session lockers. :P
<infinity> Oh, I guess light-locker is in your desktop seed, so pretty much always there.  Kay.
<infinity> Just saw the shell script's attempt to DTRT based on what's installed, and figured the flexibility might be wanted.
<tsimonq2> Fair enough, thanks for checking.
-queuebot:#ubuntu-release- New binary: qgis [armhf] (eoan-proposed/universe) [3.4.10+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [arm64] (eoan-proposed/universe) [3.4.10+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-rsconnect [amd64] (eoan-proposed/universe) [0.8.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ragout [i386] (eoan-proposed/universe) [2.1.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: virulencefinder [amd64] (eoan-proposed/universe) [0.0+git20190402.4812325-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ragout [amd64] (eoan-proposed/universe) [2.1.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ragout [s390x] (eoan-proposed/universe) [2.1.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ragout [arm64] (eoan-proposed/universe) [2.1.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ragout [armhf] (eoan-proposed/universe) [2.1.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ragout [ppc64el] (eoan-proposed/universe) [2.1.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ragout [armhf] (eoan-proposed) [2.1.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ragout [ppc64el] (eoan-proposed) [2.1.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libmaus2 [armhf] (eoan-proposed) [2.0.611-1]
-queuebot:#ubuntu-release- New: accepted qgis [arm64] (eoan-proposed) [3.4.10+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rsconnect [amd64] (eoan-proposed) [0.8.15-1]
-queuebot:#ubuntu-release- New: accepted ragout [arm64] (eoan-proposed) [2.1.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ragout [s390x] (eoan-proposed) [2.1.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [amd64] (eoan-proposed) [3.4.10+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ragout [amd64] (eoan-proposed) [2.1.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted virulencefinder [amd64] (eoan-proposed) [0.0+git20190402.4812325-1]
-queuebot:#ubuntu-release- New: accepted qgis [armhf] (eoan-proposed) [3.4.10+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ragout [i386] (eoan-proposed) [2.1.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libmaus2 [amd64] (eoan-proposed) [2.0.611-1]
-queuebot:#ubuntu-release- New: accepted libmaus2 [i386] (eoan-proposed) [2.0.611-1]
-queuebot:#ubuntu-release- New: accepted qgis [i386] (eoan-proposed) [3.4.10+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [s390x] (eoan-proposed) [3.4.10+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mvnfast [ppc64el] (eoan-proposed) [0.2.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libmaus2 [arm64] (eoan-proposed) [2.0.611-1]
-queuebot:#ubuntu-release- New: accepted qgis [ppc64el] (eoan-proposed) [3.4.10+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-qpdf [ppc64el] (eoan-proposed) [1.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted libmaus2 [ppc64el] (eoan-proposed) [2.0.611-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mvnfast [arm64] (eoan-proposed) [0.2.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-hsaur3 [amd64] (eoan-proposed) [1.0-9-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mvnfast [amd64] (eoan-proposed) [0.2.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mvnfast [i386] (eoan-proposed) [0.2.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-qpdf [arm64] (eoan-proposed) [1.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-qpdf [i386] (eoan-proposed) [1.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-logging [amd64] (eoan-proposed) [0.9-107-1]
-queuebot:#ubuntu-release- New: accepted r-cran-qpdf [amd64] (eoan-proposed) [1.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-tufte [amd64] (eoan-proposed) [0.5-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mvnfast [armhf] (eoan-proposed) [0.2.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-qpdf [armhf] (eoan-proposed) [1.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-gridgraphics [amd64] (eoan-proposed) [0.4-1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-qpdf [s390x] (eoan-proposed) [1.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mvnfast [s390x] (eoan-proposed) [0.2.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rsconnect [amd64] (eoan-proposed) [0.8.13-1]
-queuebot:#ubuntu-release- New binary: erlang-p1-yconf [i386] (eoan-proposed/universe) [0.2019.07.18-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-p1-yconf [s390x] (eoan-proposed/universe) [0.2019.07.18-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-p1-yconf [amd64] (eoan-proposed/universe) [0.2019.07.18-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-p1-yconf [ppc64el] (eoan-proposed/universe) [0.2019.07.18-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-p1-yconf [arm64] (eoan-proposed/universe) [0.2019.07.18-1] (no packageset)
-queuebot:#ubuntu-release- New binary: erlang-p1-yconf [armhf] (eoan-proposed/universe) [0.2019.07.18-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pdftools [amd64] (eoan-proposed/universe) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pdftools [s390x] (eoan-proposed/universe) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pdftools [ppc64el] (eoan-proposed/universe) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pdftools [i386] (eoan-proposed/universe) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-multidimbio [amd64] (eoan-proposed/universe) [1.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pdftools [armhf] (eoan-proposed/universe) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pdftools [arm64] (eoan-proposed/universe) [2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: starpu [s390x] (eoan-proposed/universe) [1.3.2+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: starpu [amd64] (eoan-proposed/universe) [1.3.2+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: starpu [ppc64el] (eoan-proposed/universe) [1.3.2+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: starpu [i386] (eoan-proposed/universe) [1.3.2+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: starpu [arm64] (eoan-proposed/universe) [1.3.2+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: starpu [armhf] (eoan-proposed/universe) [1.3.2+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc [amd64] (eoan-proposed/universe) [3.11.3+dfsg1-1~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc [s390x] (eoan-proposed/universe) [3.11.3+dfsg1-1~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc [ppc64el] (eoan-proposed/universe) [3.11.3+dfsg1-1~build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted erlang-p1-yconf [arm64] (eoan-proposed) [0.2019.07.18-1]
-queuebot:#ubuntu-release- New: accepted erlang-p1-yconf [ppc64el] (eoan-proposed) [0.2019.07.18-1]
-queuebot:#ubuntu-release- New: accepted erlang-p1-yconf [armhf] (eoan-proposed) [0.2019.07.18-1]
-queuebot:#ubuntu-release- New: accepted erlang-p1-yconf [amd64] (eoan-proposed) [0.2019.07.18-1]
-queuebot:#ubuntu-release- New: accepted erlang-p1-yconf [s390x] (eoan-proposed) [0.2019.07.18-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pdftools [amd64] (eoan-proposed) [2.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pdftools [armhf] (eoan-proposed) [2.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pdftools [ppc64el] (eoan-proposed) [2.2-1]
-queuebot:#ubuntu-release- New: accepted starpu [amd64] (eoan-proposed) [1.3.2+dfsg-3]
-queuebot:#ubuntu-release- New: accepted starpu [armhf] (eoan-proposed) [1.3.2+dfsg-3]
-queuebot:#ubuntu-release- New: accepted starpu [ppc64el] (eoan-proposed) [1.3.2+dfsg-3]
-queuebot:#ubuntu-release- New: accepted erlang-p1-yconf [i386] (eoan-proposed) [0.2019.07.18-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pdftools [arm64] (eoan-proposed) [2.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-pdftools [s390x] (eoan-proposed) [2.2-1]
-queuebot:#ubuntu-release- New: accepted starpu [i386] (eoan-proposed) [1.3.2+dfsg-3]
-queuebot:#ubuntu-release- New: accepted r-cran-multidimbio [amd64] (eoan-proposed) [1.1.1-1]
-queuebot:#ubuntu-release- New: accepted starpu [arm64] (eoan-proposed) [1.3.2+dfsg-3]
-queuebot:#ubuntu-release- New: accepted r-cran-pdftools [i386] (eoan-proposed) [2.2-1]
-queuebot:#ubuntu-release- New: accepted starpu [s390x] (eoan-proposed) [1.3.2+dfsg-3]
-queuebot:#ubuntu-release- New binary: petsc [i386] (eoan-proposed/universe) [3.11.3+dfsg1-1~build1] (no packageset)
 * LocutusOfBorg starts the haskell transition
-queuebot:#ubuntu-release- New binary: petsc [arm64] (eoan-proposed/universe) [3.11.3+dfsg1-1~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc [armhf] (eoan-proposed/universe) [3.11.3+dfsg1-1~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc [s390x] (eoan-proposed/universe) [3.11.3+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc [amd64] (eoan-proposed/universe) [3.11.3+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc [i386] (eoan-proposed/universe) [3.11.3+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc [ppc64el] (eoan-proposed/universe) [3.11.3+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc [arm64] (eoan-proposed/universe) [3.11.3+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: petsc [armhf] (eoan-proposed/universe) [3.11.3+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-raw-strings-qq [amd64] (eoan-proposed/universe) [1.1-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: lutok [arm64] (eoan-proposed/universe) [0.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lutok [armhf] (eoan-proposed/universe) [0.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lutok [s390x] (eoan-proposed/universe) [0.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lutok [amd64] (eoan-proposed/universe) [0.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: php-easyrdf [amd64] (eoan-proposed/universe) [0.9.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lutok [i386] (eoan-proposed/universe) [0.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lutok [ppc64el] (eoan-proposed/universe) [0.4+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fonts-inter [amd64] (eoan-proposed/universe) [3.3-1] (no packageset)
-queuebot:#ubuntu-release- New source: xfce4-panel-profiles (eoan-proposed/primary) [1.0.9-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted fonts-inter [amd64] (eoan-proposed) [3.3-1]
-queuebot:#ubuntu-release- New: accepted lutok [ppc64el] (eoan-proposed) [0.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted lutok [amd64] (eoan-proposed) [0.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted lutok [armhf] (eoan-proposed) [0.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted lutok [s390x] (eoan-proposed) [0.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted petsc [armhf] (eoan-proposed) [3.11.3+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted petsc [ppc64el] (eoan-proposed) [3.11.3+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted lutok [arm64] (eoan-proposed) [0.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted petsc [arm64] (eoan-proposed) [3.11.3+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted php-easyrdf [amd64] (eoan-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New: accepted lutok [i386] (eoan-proposed) [0.4+dfsg-1]
-queuebot:#ubuntu-release- New: accepted petsc [i386] (eoan-proposed) [3.11.3+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted petsc [amd64] (eoan-proposed) [3.11.3+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted petsc [s390x] (eoan-proposed) [3.11.3+dfsg1-1]
#ubuntu-release 2019-08-04
-queuebot:#ubuntu-release- New binary: slepc [i386] (eoan-proposed/universe) [3.11.2+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc [s390x] (eoan-proposed/universe) [3.11.2+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc [amd64] (eoan-proposed/universe) [3.11.2+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc [ppc64el] (eoan-proposed/universe) [3.11.2+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc [arm64] (eoan-proposed/universe) [3.11.2+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: slepc [armhf] (eoan-proposed/universe) [3.11.2+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted slepc [amd64] (eoan-proposed) [3.11.2+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted slepc [armhf] (eoan-proposed) [3.11.2+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted slepc [ppc64el] (eoan-proposed) [3.11.2+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted slepc [arm64] (eoan-proposed) [3.11.2+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted slepc [s390x] (eoan-proposed) [3.11.2+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted slepc [i386] (eoan-proposed) [3.11.2+dfsg1-1]
-queuebot:#ubuntu-release- New binary: haskell-microspec [amd64] (eoan-proposed/universe) [0.2.1.3-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pcict [s390x] (eoan-proposed/none) [0.5-4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ordinal [s390x] (eoan-proposed/none) [2019.4-25-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-dune [i386] (eoan-proposed/none) [1.6.2-4] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-dune [s390x] (eoan-proposed/none) [1.6.2-4] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-dune [ppc64el] (eoan-proposed/none) [1.6.2-4] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-dune [amd64] (eoan-proposed/none) [1.6.2-4] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pcict [arm64] (eoan-proposed/none) [0.5-4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ordinal [ppc64el] (eoan-proposed/none) [2019.4-25-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-dune [armhf] (eoan-proposed/none) [1.6.2-4] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pcict [armhf] (eoan-proposed/none) [0.5-4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ordinal [arm64] (eoan-proposed/none) [2019.4-25-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pcict [ppc64el] (eoan-proposed/none) [0.5-4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-dune [arm64] (eoan-proposed/none) [1.6.2-4] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ordinal [armhf] (eoan-proposed/none) [2019.4-25-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mets [s390x] (eoan-proposed/none) [1.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mets [ppc64el] (eoan-proposed/none) [1.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ordinal [amd64] (eoan-proposed/none) [2019.4-25-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pcict [amd64] (eoan-proposed/none) [0.5-4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-ordinal [i386] (eoan-proposed/none) [2019.4-25-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-pcict [i386] (eoan-proposed/none) [0.5-4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mets [amd64] (eoan-proposed/universe) [1.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mets [i386] (eoan-proposed/universe) [1.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: taurus [amd64] (eoan-proposed/universe) [4.5.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mets [arm64] (eoan-proposed/universe) [1.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-mets [armhf] (eoan-proposed/universe) [1.2.5-1] (no packageset)
<enyc> LocutusOfBorg: houston we have a problem
<enyc> LocutusOfBorg: a Linux-mint-19.1-cinnamon-64bit  (largely ubuntu 18.04 package base)  installed, working, system,   with virtualbox virtualbox-qt virtualbox-dkms virtualbox-guest-additions-iso virtualbox-ext-pack  ....
<enyc> LocutusOfBorg: now, offered the set of virtualbox updates to 5.2.32 via updata-manager, fine
<enyc> LocutusOfBorg: but,  'upgrading' the -ext-pack  gives errors,  checksum of the accept-license-agreement  is wrong
<enyc> LocutusOfBorg: rather than gracefully asking for updated agreement to be re-agreed, etc
<enyc> LocutusOfBorg: i could do more tests on actual 18.04 VMs etc, i don't (think) this is mint-specific-issue though.
<Eickmeyer> Looks like FTB on the Studio DVD. Is this a global problem?
<Eickmeyer> enyc: Doesn't matter, we don't support Mint. Try a stock Ubuntu install and see if the problem exists.
<enyc> Eickmeyer: indeed, looking now,  but I mention it as LocutusOfBorg was doing the 5.2.18 -> 5.2.32, interested in feedback,  and may waynt ot know iuickly if repeated uprgrade issue.
<Eickmeyer> enyc: The reason for my mentioning is that we don't know what Mint adds or subtracts inside their repos, so, unfortunately, the feedback isn't great unless it's from stock Ubuntu.
<enyc> Eickmeyer: its quite clearly the stock ubuntu package and the upbade LocutusOfBorg propared and i tested diffeently before,  gone to full release
<Eickmeyer> enyc: No, I mean in terms of other libs and deps. Nothing to do with the package itself.
<enyc> Eickmeyer: hrrm, how do i get the 5.2.18-dfsg-2~ubuntu18.04.5 version in apt ?   --   apt-get install virtualbox=5.2.18-dfsg-2~ubuntu18.04.5  and similarly for virtualbox-qt  virtualbax-dkms  fine
<enyc> Eickmeyer: BUT  virtualbox-guest-additions-iso  and virtualbox-ext-pack  won't work to get 5.2.18[...] via that trick ;-(
<enyc> packages.ubuntu.com/virtualbox  would suggest that bionic gcame with weird old versions 5.2.10  5.2.11 ...   but i'm quite sure I had 5.2.18 via bionic-updates before
<enyc> [testing this in ubuntu-MATE 18.04 official release/variant install]
<enyc> eventualyl, found in http://gb.archive.ubuntu.com/ubuntu/pool/multiverse/v/virtualbox-ext-pack/
<LocutusOfBorg> enyc, I'll have a look tomorrow morning
<enyc> LocutusOfBorg: testing now ;p  upgrading  virtualbox + dkms + -ext-pack + guest-additions- + -qt
<enyc> LocutusOfBorg: hrrm and and upgrade via apt-get at cli worked successfully ......
<enyc> so, unclear ;p
<enyc> mgiht only go wrong if you've had older, older, versions installed, then upgrade to 5.2.18 then upgrade to 5.2.32  or something ;p
<enyc> or, possibly, only faulty with particular update-managers, or something
<LocutusOfBorg> nice to know...
<LocutusOfBorg> lets hope people will open bug reports in case!
-queuebot:#ubuntu-release- New source: ibus-avro (eoan-proposed/primary) [1.1-0ubuntu1]
<enyc> LocutusOfBorg: i might be able to fish somethinga out of apt term logs on machine it faied...
-queuebot:#ubuntu-release- New binary: biobambam2 [i386] (eoan-proposed/universe) [2.0.95-1] (no packageset)
-queuebot:#ubuntu-release- New binary: biobambam2 [ppc64el] (eoan-proposed/universe) [2.0.95-1] (no packageset)
-queuebot:#ubuntu-release- New binary: biobambam2 [amd64] (eoan-proposed/universe) [2.0.95-1] (no packageset)
#ubuntu-release 2020-07-27
-queuebot:#ubuntu-release- New binary: x264 [s390x] (groovy-proposed/universe) [2:0.160.3011+gitcde9a93-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: x264 [ppc64el] (groovy-proposed/universe) [2:0.160.3011+gitcde9a93-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New: accepted golang-github-viant-assertly [amd64] (groovy-proposed) [0.5.4-1]
-queuebot:#ubuntu-release- New: accepted phoc [amd64] (groovy-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted phoc [armhf] (groovy-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted phoc [riscv64] (groovy-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted pidcat [amd64] (groovy-proposed) [2.1.0-3]
-queuebot:#ubuntu-release- New: accepted phoc [arm64] (groovy-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted phoc [s390x] (groovy-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted phoc [ppc64el] (groovy-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted python-itemadapter [amd64] (groovy-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted x264 [amd64] (groovy-proposed) [2:0.160.3011+gitcde9a93-2]
-queuebot:#ubuntu-release- New: accepted x264 [armhf] (groovy-proposed) [2:0.160.3011+gitcde9a93-2]
-queuebot:#ubuntu-release- New: accepted x264 [ppc64el] (groovy-proposed) [2:0.160.3011+gitcde9a93-2]
-queuebot:#ubuntu-release- New: accepted x264 [s390x] (groovy-proposed) [2:0.160.3011+gitcde9a93-2]
-queuebot:#ubuntu-release- New: accepted x264 [arm64] (groovy-proposed) [2:0.160.3011+gitcde9a93-2]
-queuebot:#ubuntu-release- New: accepted x264 [riscv64] (groovy-proposed) [2:0.160.3011+gitcde9a93-2]
-queuebot:#ubuntu-release- New: accepted x264 [i386] (groovy-proposed) [2:0.160.3011+gitcde9a93-2]
-queuebot:#ubuntu-release- New binary: golang-github-francoispqt-gojay [s390x] (groovy-proposed/universe) [1.2.13-4] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-francoispqt-gojay [amd64] (groovy-proposed/universe) [1.2.13-4] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-francoispqt-gojay [ppc64el] (groovy-proposed/universe) [1.2.13-4] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-francoispqt-gojay [arm64] (groovy-proposed/universe) [1.2.13-4] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-francoispqt-gojay [armhf] (groovy-proposed/universe) [1.2.13-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted golang-github-francoispqt-gojay [amd64] (groovy-proposed) [1.2.13-4]
-queuebot:#ubuntu-release- New: accepted golang-github-francoispqt-gojay [armhf] (groovy-proposed) [1.2.13-4]
-queuebot:#ubuntu-release- New: accepted golang-github-francoispqt-gojay [arm64] (groovy-proposed) [1.2.13-4]
-queuebot:#ubuntu-release- New: accepted golang-github-francoispqt-gojay [ppc64el] (groovy-proposed) [1.2.13-4]
-queuebot:#ubuntu-release- New: accepted golang-github-francoispqt-gojay [s390x] (groovy-proposed) [1.2.13-4]
-queuebot:#ubuntu-release- New: accepted golang-github-francoispqt-gojay [armhf] (groovy-proposed) [1.2.13-3]
<vorlon> rolling back hlint, which has a new build-dep on a package that's ftbfs on multiple archs
-queuebot:#ubuntu-release- New binary: golang-github-lucas-clemente-quic-go [amd64] (groovy-proposed/universe) [0.17.2-1] (no packageset)
<LocutusOfBorg> thanks vorlon !
<LocutusOfBorg> I was here to ask for it :D
<LocutusOfBorg> vorlon, for cyrus-imapd, can you please add a link to this bug? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966114
<ubot5> Debian bug 966114 in src:cyrus-imapd "src:cyrus-imapd: Mail::JMAPTalk version 0.15 required--this is only version 0.13 at ./Cassandane/Cyrus/JMAPCore.pm" [Serious,Open]
<LocutusOfBorg> I would like to remember that the sadness is related to code fetched randomly over internet
-queuebot:#ubuntu-release- New: accepted binutils-bpf [source] (groovy-proposed) [0ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-10-cross-mipsen [ppc64el] (groovy-proposed) [2+c1ubuntu2]
-queuebot:#ubuntu-release- New: accepted golang-github-lucas-clemente-quic-go [amd64] (groovy-proposed) [0.17.2-1]
-queuebot:#ubuntu-release- New: accepted gcc-10-cross-mipsen [amd64] (groovy-proposed) [2+c1ubuntu2]
-queuebot:#ubuntu-release- New: accepted gcc-bpf [source] (groovy-proposed) [0ubuntu1]
-queuebot:#ubuntu-release- New binary: binutils-bpf [s390x] (groovy-proposed/none) [0ubuntu1] (no packageset)
<smb> Could someone have a look at unapproved queue for iproute2 in bionic? Thanks
-queuebot:#ubuntu-release- New binary: binutils-bpf [ppc64el] (groovy-proposed/none) [0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: binutils-bpf [amd64] (groovy-proposed/none) [0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted binutils-bpf [amd64] (groovy-proposed) [0ubuntu1]
-queuebot:#ubuntu-release- New: accepted binutils-bpf [s390x] (groovy-proposed) [0ubuntu1]
-queuebot:#ubuntu-release- New: accepted binutils-bpf [ppc64el] (groovy-proposed) [0ubuntu1]
-queuebot:#ubuntu-release- New binary: binutils-bpf [arm64] (groovy-proposed/none) [0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted binutils-bpf [arm64] (groovy-proposed) [0ubuntu1]
<LocutusOfBorg> jdstrand, hello, looks like apparmor is really sad and regressed testsuite in release... do you have any idea?
<LocutusOfBorg> vorlon, can we please have apparmor hinted so gsoap transition can finish? I did a self test to confirm https://autopkgtest.ubuntu.com/packages/a/apparmor/groovy/arm64
<LocutusOfBorg> this makes also apache2 and tor migrate, finally ^^
<Laney> ok I pushed that linux policy
<Laney> should be able to drop the force hint
-queuebot:#ubuntu-release- Unapproved: backport-iwlwifi-dkms (bionic-proposed/universe) [7906-0ubuntu4~18.04.1 => 7906-0ubuntu4~18.04.2] (no packageset)
<Laney> lrm is still going to need fixing for the new nvidia in groovy though
<sil2100> tsimonq2: hey! Could you verify the ubuntu-drivers-common SRU for focal today?
<sil2100> tsimonq2: whoops, ignore me
<sil2100> Argh, no tseliot here?
<xnox> Laney:  yes, that's fine. I'm not quite sure what's the right way to write the patch though. Let me try doing something, and like write extensive comments about it.
<xnox> Laney:  ghostbusters => which ones? original or remake?
<Laney> xnox: read the rest of the backlog first, I ended up writing a LinuxPolicy
<Laney> remake
<xnox> Laney:  yeah, i saw that now. I looks good. But i wonder if that would catch everything.
<xnox> I'm thinking about linux - linux-restricted-modules - nvidia vector of uninstallability
<xnox> and yes lrm thing.
<Laney> apw wanted it to maybe consider lrm too
<Laney> I can't tell if that is a real problem
<Laney> because it's all borked atm anyway
<Laney> :<>
<Laney> anyway that should be a matter of extending the find_meta thing to work for lrm too, and adding a test
<xnox> apw:  vorlon: Laney: nvidia 440 rolled to 450 in groovy. Can we please force migrate l-r-m packages for all the flavours? or i guess please respin all the kernels in groovy with 450 nvidia?
<Laney> so there is a place to contribute if you want :>
<xnox> Laney:  thanks =)
<Laney> force sounds wrong, that would make uninstallables, fixing sounds right -> kernel people
<apw> xnox, :<
-queuebot:#ubuntu-release- New binary: icu [s390x] (groovy-proposed/main) [67.1-3ubuntu1] (core, i386-whitelist)
<xnox> Laney:  we kind of need to get the all out by wednesday evening.
<xnox> *them
<xnox> apw:  Laney: vorlon: or we can rollback nvidia-440 back to 440, instead of 450.
<Laney> apply your flames to apw
<xnox> then we will "just" need to rebuild the lrm modules to fake up the provides/depends like we had at focal release day.
-queuebot:#ubuntu-release- New binary: icu [ppc64el] (groovy-proposed/main) [67.1-3ubuntu1] (core, i386-whitelist)
<xnox> apw:  bjf: it really feels like lack of v5.4 uploads to groovy is hindering groovy development. And "copy-up" does not work, as they are not installable in groovy.
-queuebot:#ubuntu-release- New binary: icu [amd64] (groovy-proposed/main) [67.1-3ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: icu [i386] (groovy-proposed/main) [67.1-3ubuntu1] (core, i386-whitelist)
<Laney> is it hard / impossible to spin lrm only for 450?
<apw> xnox, indeed, we should have had a 5.5 long ago ... sigh
<apw> Laney, cannot just do lrm, we need to rebuild the master kernel to change the version
<Laney> nod
<xnox> Laney:  lrm vendorizes signatures that are generated suring "linux" build.
<xnox> or like generates the right deps / meta packages.
<apw> xnox, we will have a think about what we should do ... likely rather than copy forward we need to have a forward rebuilt-derivative
<xnox> right, yes.
<xnox> apw:  cause we don't have v5.5 gcp/aws/etc yet, right? (nor do we want to?)
<xnox> apw:  or somehow make 450 available in focal-proposed, such that 450 compatible packages are generated there too.
<apw> xnox, yeah it is asking a lot to do all the intermediates
<apw> xnox, yeah, will think and propose something
<xnox> or downgrade / remove 450 from groovy for now.
<xnox> to let kernels migrate
-queuebot:#ubuntu-release- New binary: gcc-bpf [s390x] (groovy-proposed/universe) [0ubuntu1] (no packageset)
<apw> lots of options i guess, though ... sigh
<xnox> https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-450/450.57-0ubuntu2 => or "just" remove the 440 transitionals that are build by 450?
<xnox> acutally i don't think the kernels are uninstallble, as we should have both 440 from 440, and 440 from 450 builds published in the archive, and the ones from 440 build should resolve the install time deps, no?
<xnox> (as in remove 440 binary .deb, without actually reuploading 450)
 * apw wonders if the dominator will undo the domination
<xnox> apw:  you might will have to copy from groovy, back to groovy the 440 binary packages build by 440
-queuebot:#ubuntu-release- New binary: gcc-bpf [ppc64el] (groovy-proposed/universe) [0ubuntu1] (no packageset)
<apw> xnox, indeed
<xnox> to complete the ressurection ritual.
-queuebot:#ubuntu-release- New binary: gcc-bpf [amd64] (groovy-proposed/universe) [0ubuntu1] (no packageset)
 * apw wonders if we should just not copy LRM forward at all
<xnox> will make kernels not migrate
<xnox> will regress daily groovy ubiquity installer
<xnox> will break secureboot with nvidia for canonical devs
<apw> ok, well thinking hat on, we needs osmething a bit more reliable than what we have
-queuebot:#ubuntu-release- New binary: icu [armhf] (groovy-proposed/main) [67.1-3ubuntu1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: icu [arm64] (groovy-proposed/main) [67.1-3ubuntu1] (core, i386-whitelist)
<Laney> at least coordination with tseliot when bumping the nvidia series ...
<xnox> apw:  can i please have 5.4.0-42.46 based upload of linux-riscv into groovy-proposed? missmatches linux-libc-headers are still preventing to rebootstrap rust compiler. Or when will the 5.4.0-42.46 based linux-riscv be spun up in focal-proposed?
<xnox> apw:  has the fix for linux-libc-headers to be built from src:linux instead of src:linux-riscv been committed for the next sru?
-queuebot:#ubuntu-release- New binary: gcc-bpf [armhf] (groovy-proposed/universe) [0ubuntu1] (no packageset)
 * xnox ponders if i should try to troll the kernel team trello boards to find answers
<apw> doubt that will help you
-queuebot:#ubuntu-release- New binary: gcc-bpf [arm64] (groovy-proposed/universe) [0ubuntu1] (no packageset)
<Laney> xnox: apw: I wonder if demote-to-proposed nvidia-graphics-drivers-450 && copy-back 440 would work
<Laney> probably wouldn't be that nice to existing groovy/nvidia users though
<apw> no indeed, i think we likely should be rebuilding them or something
<Laney> yeah ok
-queuebot:#ubuntu-release- New: accepted gcc-bpf [amd64] (groovy-proposed) [0ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-bpf [armhf] (groovy-proposed) [0ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-bpf [s390x] (groovy-proposed) [0ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-bpf [arm64] (groovy-proposed) [0ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-bpf [ppc64el] (groovy-proposed) [0ubuntu1]
<xnox> sil2100:  verified the two oem packages in the proposed. One is really good - everything works. The other one, has OEM suites published, but they currently do not contain anything (i.e. not even an OEM meta to upgrade to)
<xnox> but they are good enough to release to updates; and ship on ISOs; they will not break installing on those SKUs.
-queuebot:#ubuntu-release- New binary: icu [riscv64] (groovy-proposed/main) [67.1-3ubuntu1] (core, i386-whitelist)
<sil2100> xnox: thanks!
-queuebot:#ubuntu-release- New: accepted wireguard-linux-compat [amd64] (xenial-proposed) [1.0.20200611-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted wireguard [arm64] (xenial-proposed) [1.0.20200513-1~16.04.1]
-queuebot:#ubuntu-release- New: accepted wireguard [i386] (xenial-proposed) [1.0.20200513-1~16.04.1]
-queuebot:#ubuntu-release- New: accepted wireguard [ppc64el] (xenial-proposed) [1.0.20200513-1~16.04.1]
-queuebot:#ubuntu-release- New: accepted wireguard [amd64] (xenial-proposed) [1.0.20200513-1~16.04.1]
-queuebot:#ubuntu-release- New: accepted wireguard [powerpc] (xenial-proposed) [1.0.20200513-1~16.04.1]
-queuebot:#ubuntu-release- New: accepted wireguard [armhf] (xenial-proposed) [1.0.20200513-1~16.04.1]
-queuebot:#ubuntu-release- New: accepted wireguard [s390x] (xenial-proposed) [1.0.20200513-1~16.04.1]
-queuebot:#ubuntu-release- New: accepted icu [amd64] (groovy-proposed) [67.1-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted icu [armhf] (groovy-proposed) [67.1-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted icu [ppc64el] (groovy-proposed) [67.1-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted icu [s390x] (groovy-proposed) [67.1-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted icu [arm64] (groovy-proposed) [67.1-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted icu [riscv64] (groovy-proposed) [67.1-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted icu [i386] (groovy-proposed) [67.1-3ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (focal-proposed/main) [1:0.8.4~0.20.04.1 => 1:0.8.4~0.20.04.2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (focal-proposed/main) [1:0.8.4~0.20.04.1 => 1:0.8.4~0.20.04.2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-drivers-common [source] (focal-proposed) [1:0.8.4~0.20.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (focal-proposed) [1:0.8.4~0.20.04.2]
<dgadomski> hey sil2100, could you please take a look at systemd in x/b queues and nss in b/f queues?
-queuebot:#ubuntu-release- Unapproved: mutter (focal-proposed/main) [3.36.4-0ubuntu0.20.04.1 => 3.36.4-0ubuntu0.20.04.2] (desktop-core, desktop-extra)
-queuebot:#ubuntu-release- Unapproved: mutter (focal-proposed/main) [3.36.4-0ubuntu0.20.04.1 => 3.36.4-0ubuntu0.20.04.2] (desktop-core, desktop-extra)
<Trevinho> sil2100: hey, could you please help with the gnome-shell SRU for focal? I've also uploaded another mutter version that fixes a regression in proposed
-queuebot:#ubuntu-release- Unapproved: debootstrap (focal-proposed/main) [1.0.118ubuntu1.1 => 1.0.118ubuntu1.2] (core)
-queuebot:#ubuntu-release- Unapproved: debootstrap (bionic-proposed/main) [1.0.95ubuntu0.6 => 1.0.95ubuntu0.7] (core)
<vorlon> xnox: ghc migrated... so what's next
<LocutusOfBorg> vorlon, please apparmor hint?
<LocutusOfBorg> icu and protobuf transition are next, and looks like they are both ongoing
<vorlon> LocutusOfBorg: done (but also, I don't see baseline retests across all archs?)
<LocutusOfBorg> don't we usually just retry on one arch to see if it regresses in release?
<LocutusOfBorg> thanks for doing it
<xnox> vorlon:  icu! in progress.
<LocutusOfBorg> btw, Laney looks like autopkgtests are really sad because of machine meh, e.g. https://autopkgtest.ubuntu.com/packages/a/anbox/groovy/amd64
<LocutusOfBorg> and lots of unknown...
<vorlon> LocutusOfBorg: no, I retry /all/ failures to verify they're reproducible in the release pocket, which in principle is what should be done automatically and also spares me having to actually look at build logs before setting hints
<vorlon> xnox: icu? what happened to libffi?
<xnox> vorlon:  libffi => upstream still is not committing to abi.
<vorlon> ok
<xnox> vorlon:  doko doesn't want to do libffi without upstream commit on an abi
<xnox> vorlon:  also icu will probably trigger bits of ghc too!
<Laney> LocutusOfBorg: merci, will look
<vorlon> xnox: yes, I see that it does :/
<LocutusOfBorg> Laney, a toi!
<xnox> level1 of https://people.canonical.com/~ubuntu-archive/transitions/html/icu67.html uploaded
<xnox> I am expecting lots of gcc-10-by-default fallout
<vorlon> levels blah
<xnox> vorlon:  boost.
<xnox> vorlon:  it has to come before one rebuilds things that depend on boost-regexp
<vorlon> will they misbuild if you don't? or will they ftbfs?
<sil2100> dgadomski, Trevinho: let me see what can be done!
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (focal-proposed) [1.0.118ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: chromium-browser (focal-proposed/universe) [83.0.4103.97-0ubuntu0.20.04.1 => 84.0.4147.89-0ubuntu0.20.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted debootstrap [source] (bionic-proposed) [1.0.95ubuntu0.7]
-queuebot:#ubuntu-release- New binary: json-c [amd64] (groovy-proposed/main) [0.14+dfsg-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: json-c [i386] (groovy-proposed/main) [0.14+dfsg-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: json-c [s390x] (groovy-proposed/main) [0.14+dfsg-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: json-c [ppc64el] (groovy-proposed/main) [0.14+dfsg-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: json-c [arm64] (groovy-proposed/main) [0.14+dfsg-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: glusterfs [s390x] (groovy-proposed/universe) [8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: json-c [armhf] (groovy-proposed/main) [0.14+dfsg-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: glusterfs [amd64] (groovy-proposed/universe) [8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sope [s390x] (groovy-proposed/universe) [4.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: shadowsocks-v2ray-plugin [s390x] (groovy-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: shadowsocks-v2ray-plugin [amd64] (groovy-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: spyne [amd64] (groovy-proposed/universe) [2.13.15-0.1] (no packageset)
-queuebot:#ubuntu-release- New binary: json-c [riscv64] (groovy-proposed/main) [0.14+dfsg-1] (core, i386-whitelist)
-queuebot:#ubuntu-release- New binary: sope [amd64] (groovy-proposed/universe) [4.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted glusterfs [amd64] (groovy-proposed) [8.0-1]
-queuebot:#ubuntu-release- New: accepted json-c [riscv64] (groovy-proposed) [0.14+dfsg-1]
-queuebot:#ubuntu-release- New: accepted shadowsocks-v2ray-plugin [s390x] (groovy-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted sope [s390x] (groovy-proposed) [4.3.2-1]
-queuebot:#ubuntu-release- New: accepted json-c [armhf] (groovy-proposed) [0.14+dfsg-1]
-queuebot:#ubuntu-release- New: accepted sope [amd64] (groovy-proposed) [4.3.2-1]
-queuebot:#ubuntu-release- New: accepted shadowsocks-v2ray-plugin [amd64] (groovy-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted spyne [amd64] (groovy-proposed) [2.13.15-0.1]
-queuebot:#ubuntu-release- New: accepted glusterfs [s390x] (groovy-proposed) [8.0-1]
-queuebot:#ubuntu-release- New: accepted json-c [arm64] (groovy-proposed) [0.14+dfsg-1]
-queuebot:#ubuntu-release- New: accepted json-c [ppc64el] (groovy-proposed) [0.14+dfsg-1]
-queuebot:#ubuntu-release- New: accepted json-c [amd64] (groovy-proposed) [0.14+dfsg-1]
-queuebot:#ubuntu-release- New: accepted json-c [s390x] (groovy-proposed) [0.14+dfsg-1]
-queuebot:#ubuntu-release- New: accepted json-c [i386] (groovy-proposed) [0.14+dfsg-1]
<vorlon> xnox, tseliot, apw: I concur that we need to roll back nvidia-450 to let the kernel through; can someone confirm for me what version of nvidia-440 is the one we want in the release pocket right now?
-queuebot:#ubuntu-release- New binary: flint [s390x] (groovy-proposed/universe) [2.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: glusterfs [ppc64el] (groovy-proposed/universe) [8.0-1] (no packageset)
<apw> nvidia-graphics-drivers-440 440.100-0ubuntu0.20.04.1
<apw> vorlon, that is what it appears to have in the dkms-versions; let me double check it has not been updated
<vorlon> apw: in groovy? I see 440.100-0ubuntu1 published there
<apw> vorlon, as you know tseliot claims that the version has to be 'very' close
<apw> vorlon, but that indeed must be the same userspace
<vorlon> apw: but I don't see that 440.100-0ubuntu0.20.04.1 was previously published in groovy at all
<vorlon> apw: is that really the version we require?
<apw> vorlon, sorry i am not being clear, i believe the version you mentioned is close enough to match
<vorlon> was the kernel in groovy-proposed a binary copy from focal?
<vorlon> ok
<apw> vorlon, yes, a copy-forward
<vorlon> ok
-queuebot:#ubuntu-release- New binary: flint [amd64] (groovy-proposed/universe) [2.6.1-1] (no packageset)
<vorlon> xnox, apw: nvidia-graphics-drivers-450 demoted back to proposed, nvidia-graphics-drivers-440 self-copied back to restore older versions of binaries, afaiu that's all that's required, so let me know if there are other issues
<apw> vorlon, thanks
<vorlon> xnox: looks like this icu transition has entangled with nodejs which is going nowhere fast
-queuebot:#ubuntu-release- New binary: flint [ppc64el] (groovy-proposed/universe) [2.6.1-1] (no packageset)
<tumbleweed> re2 will too
<vorlon> well, rebuilding the other revdeps of re2 then
<vorlon> /<<BUILDDIR>>/clickhouse-18.16.1+ds/dbms/src/Interpreters/addMissingDefaults.h:23:35: error: âstringâ is not a member of âstdâ
<vorlon> ok boomer
<tumbleweed> :P
-queuebot:#ubuntu-release- New binary: flint [armhf] (groovy-proposed/universe) [2.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: flint [arm64] (groovy-proposed/universe) [2.6.1-1] (no packageset)
<hellsworth> hey release folks, libreoffice-base is missing from a fresh groovy install of the latest daily iso build
<hellsworth> however if i do a minimum install and then install libreoffice, libreoffice-base gets installed just fine
<hellsworth> so there's some issue with the install from an iso
<vorlon> hellsworth: libreoffice-base is the database component of libreoffice, it has not been installed by default for a very long time
<vorlon> (probably since before it was named 'libreoffice')
<vorlon> we install libreoffice-{calc,impress,math,writer} as part of the default desktop, not -base
<hellsworth> i could have sworn base was there by default but maybe i've done so many installs of libreoffice that i just expect it to be there
<vorlon> Laney: last britney run crashed with a python backtrace, ~ubuntu-archive/proposed-migration/log/groovy/2020-07-27/17:32:29.log
<Laney> seems so, the next one worked, wonder what that's about
<Laney> maybe some defensive logging would be in order
<Laney> someone might want to move the nvidia-440 tests to the non huge queue
<Laney> I would but I'm not on a proper device
-queuebot:#ubuntu-release- New binary: flint [riscv64] (groovy-proposed/universe) [2.6.1-1] (no packageset)
<xnox> vorlon:  but i think lrm is still not installable. I will see if i need to create bileto ppa, set it to groovy-release copy all the kernels into it, and rebuild lrm against the package version of nvidia-graphics-drivers-440 as seen in groovy. As it's different to the version number in focal.
<xnox> vorlon:  than copy lrm builds back, and then migrate them over.
<Laney> xnox: it looks ok on https://people.canonical.com/~ubuntu-archive/proposed-migration/update_output_notest.txt ?
<xnox> Laney:  awwww! yeah!
<xnox> i must have been still looking at stale output!
<Laney> ok nvidias requeued
<Laney> will purge the old ones
<Laney> then bed time!
<Laney> (holy moly @ new nodejs)
<vorlon> apw: looks like kernel-packages subscriber is missing from the newer nvidia-graphics-drivers packages http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html#unsubscribed
<apw> vorlon, hrmmm, not ideal
<Laney> ah it crashed with that message again
<Laney> will look into that tomorrow
<vorlon> xnox: apw asserts that the versions should be compatible; and I only see autopkgtests blocking on update_excuses
<xnox> nodejs should be a strictly confined snap
<xnox> vorlon:  ack
<apw> vorlon, hopfully i have sorted out the subscriptions
<vorlon> I: [2020-07-27T23:38:03+0000] - valid != valid_excuses. valid - valid_excuses: {'linux-5.7/5.7.0-15.16'}
<vorlon> kerneeeeeelllllll
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (focal-proposed) [3.36.4-1ubuntu1~20.04.1]
<mwhudson> vorlon: just remove it!
#ubuntu-release 2020-07-28
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Focal 20.04.1] has been updated (20200728)
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Focal 20.04.1] has been updated (20200728)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Focal 20.04.1] has been updated (20200728)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Focal 20.04.1] has been updated (20200728)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Focal 20.04.1] has been updated (20200728)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Focal 20.04.1] has been updated (20200728)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Focal 20.04.1] has been updated (20200728)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Focal 20.04.1] has been updated (20200728)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Focal 20.04.1] has been updated (20200728)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200728)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Focal 20.04.1] has been updated (20200728)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Focal 20.04.1] has been updated (20200728)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Focal 20.04.1] has been updated (20200728)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Focal 20.04.1] has been updated (20200728)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Focal 20.04.1] has been updated (20200728)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200728)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200728)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200728)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Focal 20.04.1] has been updated (20200728)
-queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (bionic-proposed) [1:11.1-1ubuntu7.10]
-queuebot:#ubuntu-release- Unapproved: libpcap (bionic-proposed/main) [1.8.1-6ubuntu1.18.04.1 => 1.8.1-6ubuntu1.18.04.2] (core)
<LocutusOfBorg> xnox, should we do a boost-icu transition too?
<LocutusOfBorg> The following packages have unmet dependencies:
<LocutusOfBorg>  liblucene++0v5 : Depends: libboost-regex1.71.0-icu66
<LocutusOfBorg> this happens in poedit
<LocutusOfBorg> in the meanwhile I'm rebuilding lucene++
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (focal-proposed/main) [1:0.8.4~0.20.04.2 => 1:0.8.4~0.20.04.3] (desktop-core, ubuntu-server)
<Laney> some of the lxd-armhf machines are borked, will destroy & re-create them
<Laney> (might just do them all, that'll be quicker)
<Laney> a job to do this on a rolling basis would be neat if anyone wants a fun task ...
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (focal-proposed) [1:0.8.4~0.20.04.3]
<Trevinho> SRU team ping: can you please check mutter and shell in focal queue?
-queuebot:#ubuntu-release- New: accepted flint [amd64] (groovy-proposed) [2.6.1-1]
-queuebot:#ubuntu-release- New: accepted flint [armhf] (groovy-proposed) [2.6.1-1]
-queuebot:#ubuntu-release- New: accepted flint [riscv64] (groovy-proposed) [2.6.1-1]
-queuebot:#ubuntu-release- New: accepted flint [arm64] (groovy-proposed) [2.6.1-1]
-queuebot:#ubuntu-release- New: accepted flint [s390x] (groovy-proposed) [2.6.1-1]
-queuebot:#ubuntu-release- New: accepted flint [ppc64el] (groovy-proposed) [2.6.1-1]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.44 => 2.525.45] (desktop-core)
<doko> xnox: is the icu tracker correct? asc migrated, but still shows as bad
-queuebot:#ubuntu-release- New binary: r-bioc-rsubread [s390x] (groovy-proposed/universe) [2.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-rsubread [ppc64el] (groovy-proposed/universe) [2.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-rsubread [amd64] (groovy-proposed/universe) [2.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-rsubread [arm64] (groovy-proposed/universe) [2.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-bioc-rsubread [riscv64] (groovy-proposed/universe) [2.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New source: raspberrypi-userland (groovy-proposed/primary) [0~20200520+git2fe4ca3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rtl8821ce (focal-proposed/universe) [5.5.2.1-0ubuntu3 => 5.5.2.1-0ubuntu4~20.04.2] (no packageset)
<Laney> Looks like it got the levels wrong wrt boost, probably something to do with the provides
-queuebot:#ubuntu-release- Unapproved: backport-iwlwifi-dkms (bionic-proposed/universe) [7906-0ubuntu4~18.04.1 => 7906-0ubuntu4~18.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: backport-iwlwifi-dkms (focal-proposed/universe) [8324-0ubuntu3~20.04.1 => 8613-0ubuntu1~20.04.1] (no packageset)
<LocutusOfBorg> can we please wait a little bit with icu/boost rebuilds?
<LocutusOfBorg> I'm mostly over with protobuf/re2 transition
<LocutusOfBorg> oh damn, clichouse is entangling them already :/
<LocutusOfBorg> and node-re2 is entangling with nodejs hurray
<Laney> we can probably boot those out
<Laney> will do that
-queuebot:#ubuntu-release- Unapproved: gnome-boxes (focal-proposed/universe) [3.36.5-0ubuntu1 => 3.36.5-0ubuntu2] (desktop-extra)
<Laney> LocutusOfBorg: done, now get protobuf to go
<LocutusOfBorg> thanks, I'm trying to figure out gnss-sdr, and compiz on s390x
<LocutusOfBorg> Laney, also gnss-sdr can be kicked out? because it needs boost/icu to build...
<Laney> looks ok
<LocutusOfBorg> I'll try to fix again once gnuradio publishes
<LocutusOfBorg> btw, mir autopkgtest looks suspiciously related to icu/boost
<LocutusOfBorg> or maybe just a slow answer
<Laney> they have #ubuntu-mir iirc, might have more luck there
<Laney> gnss-sdr gone
<Laney> so just compiz/s390x, and that has rdeps
<Laney> (but probably questionable value ...)
<vorlon> apw: component-mismatches says we want to promote linux-5.7, which also does not have a kernel-packages subscriber
<apw> vorlon, that one is just about dead i believe, and will be removed rather
<apw> sforshee, ^ you are moving off -5.7 right?
<sforshee> apw: right
<apw> sforshee, how long before it can be wacked
<sforshee> apw: it should be ok to go ahead and remove it I think
<apw> sforshee, that had a non-overlapping synthetic udeb didn't it ?
<apw> oh but the primary kernl package probabally provides things
<apw>  Provides: efi-modules, ext3-modules, ext4-modules, kernel-image, squashfs-modules
<apw> ok confirmed, i believe this is why those things are trying to pull it into main, even though there is something in main which already provides them; in that sense a false positive
<apw> and also it is safe to remove them because there is other provision
<xnox> apw: is that in groovy, or some other suite?
<apw> groovy-proposed
<xnox> apw:  hm, there should be nothing that tries to pull them in =/
<xnox> oh
<xnox> yes
<xnox> yes it will.
<apw> partman's udebs depend on some of the provides:
<xnox> apw:  until we implement building with `noudeb` profile and remove all the udebs.
<xnox> apw:  also `partman-base` should have been removed from groovy
<xnox> (the rest of partman-* was)
<apw> anyhow, we should ignore component-missmatch-proposed's desire to pull it in, and i believe it safe to remove; and i will do that in a bit
<xnox> yeap
<vorlon> Laney: so I added a block linux-5.7 to work around the tracebacks and let things migrate; feel free to twiddle that as necessary for debugging
<LocutusOfBorg> why the hell is cura-engine still installing both old and new protobuf in autopkgtests? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/c/cura-engine/20200728_140842_89b0d@/log.gz
<LocutusOfBorg> it fails because we can't have both
<LocutusOfBorg> :/
<Laney> vorlon: ah, I think I fixed it, will drop that
<vorlon> Laney: ok, cheers
-queuebot:#ubuntu-release- Unapproved: zita-ajbridge (focal-proposed/universe) [0.8.2-1 => 0.8.4-1ubuntu0.20.04.1] (ubuntustudio)
<Eickmeyer> ^ bug 1889146
<ubot5> bug 1889146 in zita-ajbridge (Ubuntu Focal) "[SRU] Loss of USB device causes zita-ajbridge to run cpu at 100% and hang" [High,Confirmed] https://launchpad.net/bugs/1889146
<Laney> I'm going to try rolling back sysdig, new one looks like it's broken on armhf
<LocutusOfBorg> Laney, thanks!
<xnox> vorlon:  i am now wondering if most of my binNMUs that I uploaded were all wrong.
<xnox> i can't seem to find a bunch of them, and some have migrated cause they managed to build against 66 icu.
<Laney> LocutusOfBorg: cura-engine needs a trigger on libarcus, want to do that?
<xnox> separate thing
<LocutusOfBorg> I think I just did that
<Laney> neat, it passed
<bryyce> is there something I can do to help remove the remaining php-horde-* bits?  (see lp: #1880776)  There's a couple handfuls of packages on excuses like php-horde-activesync, php-horde-core, etc.
<ubot5> Launchpad bug 1880776 in php-horde (Ubuntu) "Please blacklist and remove php-horde and php-horde-* from groovy (and future releases)" [Undecided,New] https://launchpad.net/bugs/1880776
<xnox> vorlon:  hm https://launchpad.net/ubuntu/+source/0ad/0.0.23.1-4ubuntu4/+build/19741761 what's going on =( no build log?!
<Laney> I think there's an outage of sorts going on at the minute which cjwatson is working on
<cjwatson> Indeed
<LocutusOfBorg> Laney, we need also a gazebo trigger
<Laney> I've hinted that and something else, it's some apt weirdness getting the right versions of boost-icu installed
<LocutusOfBorg> done, hopefully
<Laney> took ages fiddling around in a vm and made it pass in the end
<LocutusOfBorg> I think gazebo just needed an hint without boost inside
<Laney> so I added a skiptest ...
<Laney> well if yours works, good :-)
<LocutusOfBorg> now we are waiting for the outage to finish
<LocutusOfBorg> compiz build looks sad
<Laney> just the outage mentioned above, should hopefully unstick itself when that's fixed
<Laney> I think it's going to come down to just mir remaining
<LocutusOfBorg> mir is "fixed"
<LocutusOfBorg> I mean, test disabled in s390x
<LocutusOfBorg> btw I *think* sysdig removal was not correct, better hint on armhf
<LocutusOfBorg> ERROR: "__aeabi_uldivmod" [/var/lib/dkms/sysdig/0.26.7/build/sysdig-probe.ko] undefined!
<LocutusOfBorg> well, I see no div in the diff between .4 and .7
<LocutusOfBorg> probably a new kernel module added?
<Laney> we'll see
<xnox> doko:  fixed up icu67 tracker, it was wrong. Will take a little bit for it to republish.
<Laney> LocutusOfBorg: I think you confused mir and compiz
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/mir/1.7.1-0ubuntu7
<LocutusOfBorg> Laney, ^^
<LocutusOfBorg> needs riscv64 to finish build
<LocutusOfBorg> and compiz is fixed on s390x
<Laney> I know, that doesn't say disabled test on s390x
<LocutusOfBorg> yep :)
<Laney> soooooo
<LocutusOfBorg> + * Linux 5.6 kernels no longer include the old 32-bit timeval
<LocutusOfBorg> + * structures. But the syscalls (might) still use them.
<LocutusOfBorg> sysdiag might have regressed in this
-queuebot:#ubuntu-release- Unapproved: rejected backport-iwlwifi-dkms [source] (bionic-proposed) [7906-0ubuntu4~18.04.2]
<Laney> it seems moderately active upstream, if you wanted to look there might be a commit
-queuebot:#ubuntu-release- Unapproved: rejected libpcap [source] (bionic-proposed) [1.8.1-6ubuntu1.18.04.2]
<bdmurray> How many double uploads can one SRU queue have?
<bdmurray> jamespage: There are 2 uploads of openvswitch in the bionic SRU queue. Is there one that you prefer? The diffs are substantially different in size.
-queuebot:#ubuntu-release- Unapproved: accepted libpcap [source] (bionic-proposed) [1.8.1-6ubuntu1.18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted iproute2 [source] (bionic-proposed) [4.15.0-2ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted pam [source] (bionic-proposed) [1.1.8-3.6ubuntu2.18.04.2]
<Eickmeyer> RAOF or bdmurray: Could we get a quick look at the zita-ajbridge upload for bug 1889146? This fixes a regression causing 100% CPU usage.
<ubot5> bug 1889146 in zita-ajbridge (Ubuntu Focal) "[SRU] Loss of USB device causes zita-ajbridge to run cpu at 100% and hang" [High,In progress] https://launchpad.net/bugs/1889146
-queuebot:#ubuntu-release- Unapproved: accepted zita-ajbridge [source] (focal-proposed) [0.8.4-1ubuntu0.20.04.1]
<Eickmeyer> Thanks!
-queuebot:#ubuntu-release- Unapproved: flash-kernel (bionic-proposed/main) [3.98ubuntu11~18.04.1 => 3.98ubuntu11~18.04.2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted flash-kernel [source] (bionic-proposed) [3.98ubuntu11~18.04.2]
<ddstreet> bdmurray hello, got a request to review the systemd upload in bionic, it's been there for 20 days
<ddstreet> it fixes the bugs listed in the changelog (including a FTBFS on arm64), and also there's a new issue that requires a rebuild after kmod is accepted, for LP: #1889297
<ubot5> Launchpad bug 1889297 in systemd (Ubuntu Bionic) "Bionic: debian-installer FTBFS because udev-udeb depends on libkmod2 not libkmod2-udeb" [High,In progress] https://launchpad.net/bugs/1889297
<ddstreet> so the kmod patch is needed first, before systemd is accepted
<ddstreet> mfo is working on the kmod revert i believe
<bdmurray> ddstreet: so there is nothing for me to do yet?
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.45]
-queuebot:#ubuntu-release- Unapproved: icingaweb2 (bionic-proposed/universe) [2.4.1-1 => 2.4.1-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected icingaweb2 [source] (bionic-proposed) [2.4.1-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted rabbitmq-server [source] (bionic-proposed) [3.6.10-1ubuntu0.4]
-queuebot:#ubuntu-release- Unapproved: accepted ntp [source] (bionic-proposed) [1:4.2.8p10+dfsg-5ubuntu7.2]
<ddstreet> bdmurray i thought mfo had already uploaded kmod, but looks like not, so no nothing yet. sorry.
<mfo> ddstreet, bdmurray: yup, kmod is not yet uploaded.  it's waiting on PPA builders. :/ as soon as that is finished and tested i'll upload.  thanks.
<mfo> oh, sending the msg did help. builders started! :D
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.policy [source] (bionic-proposed) [1.33.1-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted postfix [source] (bionic-proposed) [3.3.0-1ubuntu0.3]
-queuebot:#ubuntu-release- Unapproved: accepted postfix [source] (xenial-proposed) [3.1.0-3ubuntu0.4]
-queuebot:#ubuntu-release- Unapproved: accepted icingaweb2 [source] (bionic-proposed) [2.4.1-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted backport-iwlwifi-dkms [source] (bionic-proposed) [7906-0ubuntu4~18.04.2]
<LocutusOfBorg> vorlon, please once built everywhere, rollback pokerth 1.1.2-1build9 to pokerth 1.1.2-1build8 thanks
<LocutusOfBorg> protobuf is ready for migration
<LocutusOfBorg> (see backlog, we were holding back some packages to avoid protobuf entangling with icu/nodejs/re/boost
<LocutusOfBorg> )
-queuebot:#ubuntu-release- Unapproved: kmod (bionic-proposed/main) [24-1ubuntu3.4 => 24-1ubuntu3.5] (core)
<mfo> bdmurray, just uploaded kmod to bionic, if you have a chance. thanks!
<mfo> it needs to build/be avail before systemd.
<xnox> i would call it critical for the bionic point release
<bdmurray> xnox: which it? systemd or kmod?
<xnox> bdmurray:  both, they are related =)
<xnox> "ressurect kmod-udeb, make systemd's udebs use kmod-udebs again"
<bdmurray> Okay, I've somewhere to be shortly but will try and look at it later this evening
<vorlon> LocutusOfBorg: how can protobuf be ready to go? dnsdist is tied to both protobuf and re2
<mfo> xnox, i believe you're aware, but just in case, please note that systemd in bionic's upload queue has more changes than the systemd debdiff attached in LP#1889297 (which was more of a "no change rebuild" w/ just a fix to arm64 FTBFS), if that's the one you looked at recently.
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Focal 20.04.1] has been updated (20200728.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Focal 20.04.1] has been updated (20200728.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Focal 20.04.1] has been updated (20200728.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Focal 20.04.1] has been updated (20200728.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Focal 20.04.1] has been updated (20200728.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Focal 20.04.1] has been updated (20200728.1)
#ubuntu-release 2020-07-29
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Focal 20.04.1] has been updated (20200728.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Focal 20.04.1] has been updated (20200728.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200728.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Focal 20.04.1] has been updated (20200728.1)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200728.1)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Focal 20.04.1] has been updated (20200728.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Focal 20.04.1] has been updated (20200728.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Focal 20.04.1] has been updated (20200728.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Focal 20.04.1] has been updated (20200728.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Focal 20.04.1] has been updated (20200728.1)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200728.1)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200728.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Focal 20.04.1] has been updated (20200728.1)
<LocutusOfBorg> vorlon, will fix dnsdist
<LocutusOfBorg> can you please rollback pokerth?
<jamespage> bdmurray: the later one - check the details on the bug referenced
<Laney> let me do a couple, I think we can get protobuf + re2 through with a couple of surgical tweaks
<LocutusOfBorg> looks like somebody is rolling back pokerth and gazebo, thanks
<LocutusOfBorg> I'm preparing dnsdist in bileto
<Laney> ok
<Laney> nobody touch anything, let's see what all of those did
<Laney> pretty please
<tjaalton> how unethical is it to review a package from the sru queue that I sponsored?
<seb128> tjaalton, easy to workaround by pinging someone else from the SRU team
<tjaalton> yes, so there's rtl8821ce-dkms for focal
<apw> tjaalton, if you are sponsoring a package it is assumed the uploader is not yet trusted to be the first eyes, this makes you the first eyes; the general theory behind the sru queue is there should be two eyes, the uploader/sponsor and the accepting sru-team member
<apw> tjaalton, so self-review is generally frowned upon outside exceptional circumstances; but asking someone explicitly to do so when it would not get done because it is your day etc is normal there
<LocutusOfBorg> xnox, frogatto needs another rebuild, because riscv64 didn't pick the new boost
<tjaalton> apw: yep, exactly as I thought so I haven't done that
<LocutusOfBorg> Laney, ð
<LocutusOfBorg> you can copy-back stuff if you want :D
<LocutusOfBorg> maybe after a publisher run
<Laney> ah good
<Laney> ok, I will put the things back shortly
<LocutusOfBorg> I wasn't aware re2 was ready to go, I was preparing a dnsdist with only protobuf on bileto to disentangle them
<LocutusOfBorg> I should have also finally fixed dkms sadness
<LocutusOfBorg> will look at gnss-sdr now
<LocutusOfBorg> thanks rbalint :) (wrt glibc)
<Laney> that should do it, hopefully
<Laney> others can have fun massaging boost/icu/node
-queuebot:#ubuntu-release- Unapproved: zsys (focal-proposed/main) [0.4.6 => 0.4.7] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected openvswitch [source] (bionic-proposed) [2.9.6-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New binary: ifenslave [amd64] (groovy-proposed/universe) [2.10ubuntu2] (no packageset)
<xnox> LocutusOfBorg:  fun.
<ginggs> would someone please remove nvidia-graphics-drivers-tesla-450 from proposed and add it to sync-blacklist ?
-queuebot:#ubuntu-release- Unapproved: accepted rpcbind [source] (xenial-proposed) [0.2.3-0.2ubuntu0.1]
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1066.71] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted smart-notifier [source] (focal-proposed) [0.28-6~ubuntu20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-desktop-icons [source] (focal-proposed) [20.04.0-3~ubuntu20.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1066.71]
-queuebot:#ubuntu-release- Unapproved: bcache-tools (focal-proposed/main) [1.0.8-3 => 1.0.8-3ubuntu0.1] (edubuntu, i386-whitelist, ubuntu-server)
<dannf> fyi, there's 2 extraneous "/focal" subdirs in the zsync link for arm64/server-live http://iso.qa.ubuntu.com/qatracker/milestones/414/builds/218103/downloads
-queuebot:#ubuntu-release- Unapproved: smokeping (focal-proposed/universe) [2.7.3-2 => 2.7.3-2ubuntu20.04.1] (no packageset)
<Laney> ginggs: can you file a bug for paper trail please?
<Laney> dannf: fixed
<dannf> Laney: thx!
<ginggs> Laney: I will if you really want, but if you look in the sync-blacklist.txt you'll see the previous versions are there with a comment
<Laney> ginggs: ah ok, that seems fine then
<ginggs> Laney: thanks :)
-queuebot:#ubuntu-release- New binary: rust-enum-iterator [amd64] (groovy-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libsystemd [amd64] (groovy-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-enum-iterator [s390x] (groovy-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (focal-proposed) [3:18.3.2-0ubuntu0.20.04.2]
-queuebot:#ubuntu-release- New binary: rust-enum-iterator [ppc64el] (groovy-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libsystemd [s390x] (groovy-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libsystemd [ppc64el] (groovy-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-enum-iterator [arm64] (groovy-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-enum-iterator [armhf] (groovy-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libsystemd [arm64] (groovy-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libsystemd [armhf] (groovy-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted rasdaemon [source] (focal-proposed) [0.6.5-1ubuntu1.1]
-queuebot:#ubuntu-release- New binary: rust-enum-iterator [riscv64] (groovy-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted apache2 [source] (xenial-proposed) [2.4.18-2ubuntu3.16]
<LocutusOfBorg> Laney, some autopkgtest outage? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/m/makedumpfile/20200729_141830_4829c@/log.gz
<Laney> I don't think so, probably more likely to be to do with that package, feel free to try it yourself locally
<LocutusOfBorg> ack!
<LocutusOfBorg> crash                PASS
<LocutusOfBorg> autopkgtest [17:04:08]: @@@@@@@@@@@@@@@@@@@@ summary
<LocutusOfBorg> crash                PASS
<LocutusOfBorg> qemu-system-x86_64: terminating on signal 15 from pid 32114 (/usr/bin/python3)
<LocutusOfBorg> Laney, ^^
<LocutusOfBorg> this is how I ran it sudo autopkgtest --shell-fail --apt-upgrade makedumpfile_1.6.7-3ubuntu1.dsc -- qemu --ram-size=1536 ~/autopkgtest-groovy-amd64.img
<LocutusOfBorg> and looks like working correctly here
-queuebot:#ubuntu-release- Unapproved: accepted kmod [source] (bionic-proposed) [24-1ubuntu3.5]
<Laney> k, dunno, sorry I'm busy working on something else, maybe someone from the kernel team wants to look
<Laney> can't debug random failures right now
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (focal-proposed) [0.8.3-1ubuntu12.3]
-queuebot:#ubuntu-release- New binary: gnss-sdr [s390x] (groovy-proposed/universe) [0.0.13-1~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnss-sdr [ppc64el] (groovy-proposed/universe) [0.0.13-1~build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: debian-installer (focal-proposed/main) [20101020ubuntu614 => 20101020ubuntu614.1] (core)
-queuebot:#ubuntu-release- New binary: gnss-sdr [amd64] (groovy-proposed/universe) [0.0.13-1~build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: debian-installer (bionic-proposed/main) [20101020ubuntu543.15 => 20101020ubuntu543.16] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (focal-proposed) [20101020ubuntu614.1]
<xnox> apw:  bjf: i see there is linux kernel in xenial-proposed. Is that kernel for xenial point release, and it will be out soon?
<xnox> will it be out by 13th of August?
<bjf> xnox, it was my understanding that the xenial-updates kernel is for the .7 release. sil2100 ^ ?
-queuebot:#ubuntu-release- New binary: gnss-sdr [arm64] (groovy-proposed/universe) [0.0.13-1~build1] (no packageset)
<bjf> apw, ^ (xnox query)
<bjf> xnox, i do appreciate you thinking i still know any of this
<xnox> apw:  bjf:  i must rebuild d-i against a kernel, to vendorize fixed grub.
<xnox> apw:  bjf: thus i must have no kernel in -proposed.
<xnox> apw:  bjf: so either linux should be removed from xenial-proposed, or it must migrate to updates, for me to rebuild d-i for the .7 release.
<cjwatson> You could probably build it in a PPA with suitable dependencies set, and also a following wind
<xnox> cjwatson:  i can, and i've done that before. But fiddly. Plus this is missmatch of expectations.
<xnox> apw:  bjf: please confirm which one of the two kernels you want in xenial .7
<apw> xnox, I can withdraw the current kernel from -proposed if needed
-queuebot:#ubuntu-release- New: accepted rust-enum-iterator [amd64] (groovy-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-enum-iterator [armhf] (groovy-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-enum-iterator [riscv64] (groovy-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-libsystemd [amd64] (groovy-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-libsystemd [armhf] (groovy-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-libsystemd [s390x] (groovy-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-enum-iterator [arm64] (groovy-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-enum-iterator [s390x] (groovy-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-libsystemd [ppc64el] (groovy-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-enum-iterator [ppc64el] (groovy-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-libsystemd [arm64] (groovy-proposed) [0.1.0-1]
<apw> klebers: ^^ which xenial kernel would you prefer in the point release
-queuebot:#ubuntu-release- New: accepted glusterfs [ppc64el] (groovy-proposed) [8.0-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-rsubread [arm64] (groovy-proposed) [2.2.5-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-rsubread [riscv64] (groovy-proposed) [2.2.5-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-rsubread [amd64] (groovy-proposed) [2.2.5-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-rsubread [s390x] (groovy-proposed) [2.2.5-1]
-queuebot:#ubuntu-release- New: accepted r-bioc-rsubread [ppc64el] (groovy-proposed) [2.2.5-1]
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Focal 20.04.1] (20101020ubuntu614.1) has been added
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Focal 20.04.1] (20101020ubuntu614.1) has been added
-queuebot:#ubuntu-release- Builds: Netboot armhf [Focal 20.04.1] (20101020ubuntu614.1) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Focal 20.04.1] (20101020ubuntu614.1) has been added
-queuebot:#ubuntu-release- Builds: Netboot s390x [Focal 20.04.1] (20101020ubuntu614.1) has been added
<sil2100> xnox: the one in -updates is the kernel we want
<sil2100> apw: ^
<sil2100> At least that came out from my discussions with klebers, the -proposed one wasn't prepared with images in mind
<xnox> apw: please remove linux from xenial-proposed temporarily, for me to rebuild d-i, and let that migrate to updates. Then resurrect xenial proposed kernel.
<sil2100> xnox: I guess you can build d-i in a PPA without -proposed enabled and then bin-copy?
<xnox> apw:  effectively d-i upload is security upload.
<xnox> sil2100:  i can do that too, but it makes review harder.
<xnox> apw:  i guess removal is pain, and bileto is pain, but i guess bileto ppa is less pain overall.
<sil2100> True, but if you use bileto, this should not be that bad! I guess it's up to apw at this point, as I don't know how problematic it will be
<xnox> apw: bjf: klebers: building d-i in bileto against updates only. should not require removing any kernels.
<sil2100> xnox: ping me when you have something ready! Or if you need any help with those
<sil2100> I'm at your service
<xnox> ddstreet:  https://bugs.launchpad.net/ubuntu/bionic/+source/systemd/+bug/1881972 & https://bugs.launchpad.net/ubuntu/bionic/+source/systemd/+bug/1832754 test cases need improvement. It is now blocking building & releasing debian-installer security update.
<ubot5> Ubuntu bug 1881972 in systemd (Ubuntu Bionic) "systemd-networkd crashes with invalid pointer" [Medium,Incomplete]
<ubot5> Ubuntu bug 1832754 in systemd (Ubuntu Bionic) ""shutdown[1]: Failed to wait for process: Protocol error" at shutdown or reboot and hangs." [Medium,Incomplete]
<xnox> sil2100:  bileto didn't help, becuase d-i itself encodes -proposed. purging that, testbuilding, if good will upload.
<sil2100> Crap
<xnox> sil2100:  it's not critical
<vorlon> we still have the option of removing the kernel from -proposed and then readding
<vorlon> xnox: d-i build failure: because grub2 signed artifacts are only accepted for focal-proposed and not for focal-updates
<vorlon> I don't recall this having been a thing but it seems I need to accept them in focal-updates also
<vorlon> (or else manually copy from focal-proposed to focal-updates)
<vorlon> cjwatson: ^^ do you recall what the intent has been here?
<xnox> vorlon:  i am at the same conclusion
<xnox> http://archive.ubuntu.com/ubuntu/dists/focal-updates/main/uefi/grub2-amd64
<xnox> http://archive.ubuntu.com/ubuntu/dists/xenial-updates/main/uefi/grub2-amd64/
<xnox> are both out of date
<vorlon> Binary files focal-proposed/5.4.0-42.46/vmlinuz-5.4.0-42-generic.efi.signed and focal-updates/5.4.0-42.46/vmlinuz-5.4.0-42-generic.efi.signed differ
<ddstreet> rbalint_ xnox can you review the patches for lp #1832754; it's unlikely i will be spending time to try to figure out a specific reproducer
<ubot5> Launchpad bug 1832754 in systemd (Ubuntu Bionic) ""shutdown[1]: Failed to wait for process: Protocol error" at shutdown or reboot and hangs." [Medium,In progress] https://launchpad.net/bugs/1832754
<vorlon> so it seems re-signing is the existing procedure
<xnox> vorlon:  sigh
<xnox> vorlon:  it would be nice if signing used audit logs of signatures created. And reuse existing sigs, if one gets re-requested.
<apw> vorlon: we have to resign as they are not copied with the debs. resigning is idempotent so is ok
<apw> if we don't then when proposed is purged we don't have a full set in -updates
<vorlon> apw: if it were idempotent, my diff command wouldn't have reported a difference
<vorlon> the signatures are different (possibly due to date stamps), and that increases the amount of crypto material that could potentially be used to attack the key
<vorlon> xnox: accepted now for -updates, all series
<xnox> tah
<xnox> apw:  vorlon: we could make them idempotent / reproducible. I.e. if they used the changelog date of the source build. Or like include the timestamp in the tarball that one wants to use.
<apw> vorlon: hrm, now why do I think they are meant to come out the same ... odd
<vorlon> apw: it is /merely/ a doubling of the number of signed artifacts, which are already quite numerous, so maybe it's not worth worrying about in practice
<vorlon> xnox: having signature dates be manipulatable via the changelog, WHAT COULD GO WRONG
<xnox> vorlon:  inside the signing tarball.
<vorlon> still :)
<xnox> vorlon:  or like take the timestamp of the thing one build.
<xnox> vorlon:  surely it's /trippling/ because -proposed, -updates, -security?
<vorlon> xnox: possibly
<xnox> vorlon:  keeping track of all signatures made, and reusing for the same signature for the same binary => also sounds dubious.
-queuebot:#ubuntu-release- New binary: gnss-sdr [riscv64] (groovy-proposed/universe) [0.0.13-1~build1] (no packageset)
<cjwatson> vorlon: I do not.  We should probably arrange to copy the signature but I'd have to check (and am EOW)
<bdmurray> vorlon: Should the grub updates be phasing?
<xnox> bdmurray: yes
<xnox> bdmurray: as per normal.
<sil2100> So how are you proceeding? Are we pulling out the kernel from xenial-proposed?
<xnox> sil2100: no, not yet.
<xnox> sil2100:  i had pizza, and signatures were not published. retried focal build waiting for it to pass.
<xnox> sil2100: retries of xenial in bileto, without proposed in either source code and the build still seems to fail. SO not sure what's going on, maybe i got my numbers wrong.
<xnox> sil2100:  so if you look at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4171/+packages
<xnox> you can see that it build fine on all architectures, but amd64
<xnox> what's missing / wrong about it?
<xnox> focal d-i now built fine!
<xnox> oooooh
<xnox> i wonder if our signing is all wrong in xenial
<xnox> aha
<xnox> apw:  last time we built xenial the kernel-signed-image-4.4.0-142-generic-di_4.4.0-142.168_amd64.udeb package had ./boot/vmlinuz-4.4.0-142-generic.efi.signed
<xnox> apw: whereas kernel-signed-image-4.4.0-186-generic-di_4.4.0-186.216_amd64.udeb ships ./boot/vmlinuz-4.4.0-186-generic and kernel-signed-image-4.4.0-187-generic-di_4.4.0-187.217_amd64.udeb ships ./boot/vmlinuz-4.4.0-187-generic
<xnox> apw: klebers: is that intentional that signing got changed and rename in xenial since .6 release?
<apw> xnox, yes... the names changed with the drive to only booting signed kernels, and thus there only being signed kernels
<xnox> apw:  klebers: i can backport changes to support '.signed'-less things in d-i.
<apw> xnox, we used to have vmlinuz and vmlinuz.efi
<apw> .signed
<apw> and grub picked the right one, now ... we only have vmlinuz
<xnox> cool. test building.
-queuebot:#ubuntu-release- Unapproved: network-manager-applet (focal-proposed/main) [1.8.24-1ubuntu2 => 1.8.24-1ubuntu3] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: debian-installer (xenial-proposed/main) [20101020ubuntu451.28 => 20101020ubuntu451.29] (core)
<xnox> vorlon:  ^ the above d-i should hopefully build fine in xenial.
<xnox> or bdmurray or sil2100
<vorlon> looking
<vorlon> accepted
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (xenial-proposed) [20101020ubuntu451.29]
<sil2100> o/
<vorlon> xnox: all grub2-triggered autopkgtests passed
<xnox> horay.
<xnox> vorlon:  d-i in focal is odd in britney
<xnox> debian-installer-udebs/amd64 has unsatisfiable dependency
<xnox> debian-installer-udebs/arm64 has unsatisfiable dependency
<xnox> but what is it? does britney know aobut udebs?
<sil2100> hm
<sil2100> Wonder which dependency britney considers unsatisfiable
<xnox> vorlon:  sil2100: what needs doing to get d-i in xenial & focal released to updates?
<xnox> we don't have automated tests for d-i do we.... do we manually test them first?
<sil2100> xnox: usually we build -proposed based images to test those, but then again, I guess we could just publish them to -updates and simply re-spin the candidate images
<sil2100> As there is no risk of breakage
<sil2100> (other than on the new images)
<sil2100> xnox: let me release those into -updates, focal looks fine so I'll proceed with that one
<sil2100> (and I can then spin up the images)
<sil2100> focal done
-queuebot:#ubuntu-release- New binary: iotjs [ppc64el] (groovy-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnss-sdr [s390x] (groovy-proposed/universe) [0.0.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnss-sdr [amd64] (groovy-proposed/universe) [0.0.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: iotjs [amd64] (groovy-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnss-sdr [ppc64el] (groovy-proposed/universe) [0.0.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: iotjs [s390x] (groovy-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: iotjs [riscv64] (groovy-proposed/universe) [1.0-2] (no packageset)
#ubuntu-release 2020-07-30
-queuebot:#ubuntu-release- New binary: iotjs [arm64] (groovy-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: iotjs [armhf] (groovy-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnss-sdr [arm64] (groovy-proposed/universe) [0.0.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnss-sdr [armhf] (groovy-proposed/universe) [0.0.13-1] (no packageset)
<xnox> ddstreet: no more things to do ATM. We have point releases to ship! Or why does 1832754 must be fixed on the point release media?
<sil2100> Ok, I'll be kicking the .1 release candidate images now before going to sleep
<xnox> ð
-queuebot:#ubuntu-release- New binary: agda [amd64] (groovy-proposed/universe) [2.6.1-1] (no packageset)
<xnox> sil2100: vorlon: I wonder if for bionic we could accept "no change rebuild" of systemd with a version number that does not supersed the full-sru in the unapproved queue. Such that kmod migrates, and such that bionic d-i can be built.
<sil2100> xnox: that sounds reasonable I must say - I didn't check what exact fixes are in the systemd upload in Unapproved, but seeing that the test case is hard to establish for at least one of the fixes there, maybe it's better to go this way
-queuebot:#ubuntu-release- New binary: agda [ppc64el] (groovy-proposed/universe) [2.6.1-1] (no packageset)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200730)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Focal 20.04.1] has been updated (20200730)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200730)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Focal 20.04.1] (20200730) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Focal 20.04.1] (20200730) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Focal 20.04.1] has been updated (20200730)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Focal 20.04.1] has been updated (20200730)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Focal 20.04.1] has been updated (20200730)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Focal 20.04.1] has been updated (20200730)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Focal 20.04.1] has been updated (20200730)
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200730)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Focal 20.04.1] has been updated (20200730)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Focal 20.04.1] has been updated (20200730)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Focal 20.04.1] (20200730) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Focal 20.04.1] has been updated (20200730)
-queuebot:#ubuntu-release- New binary: agda [s390x] (groovy-proposed/universe) [2.6.1-1] (no packageset)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200730)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Focal 20.04.1] has been updated (20200730)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Focal 20.04.1] has been updated (20200730)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Focal 20.04.1] has been updated (20200730)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Focal 20.04.1] has been updated (20200730)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Focal 20.04.1] has been updated (20200730)
-queuebot:#ubuntu-release- New binary: gnss-sdr [riscv64] (groovy-proposed/universe) [0.0.13-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libgtextutils [riscv64] (groovy-proposed/universe) [0.7-7] (no packageset)
-queuebot:#ubuntu-release- New binary: libgtextutils [ppc64el] (groovy-proposed/universe) [0.7-7] (no packageset)
-queuebot:#ubuntu-release- New binary: gnucap-python [ppc64el] (groovy-proposed/universe) [0.0.2-1.2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnucap-python [riscv64] (groovy-proposed/universe) [0.0.2-1.2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnucap-python [amd64] (groovy-proposed/universe) [0.0.2-1.2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgtextutils [amd64] (groovy-proposed/universe) [0.7-7] (no packageset)
-queuebot:#ubuntu-release- New binary: gnucap-python [s390x] (groovy-proposed/universe) [0.0.2-1.2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgtextutils [s390x] (groovy-proposed/universe) [0.7-7] (no packageset)
-queuebot:#ubuntu-release- New binary: libgtextutils [arm64] (groovy-proposed/universe) [0.7-7] (no packageset)
-queuebot:#ubuntu-release- New binary: gnucap-python [arm64] (groovy-proposed/universe) [0.0.2-1.2] (no packageset)
-queuebot:#ubuntu-release- New binary: gnucap-python [armhf] (groovy-proposed/universe) [0.0.2-1.2] (no packageset)
-queuebot:#ubuntu-release- New binary: libgtextutils [armhf] (groovy-proposed/universe) [0.7-7] (no packageset)
-queuebot:#ubuntu-release- Unapproved: apport (focal-proposed/main) [2.20.11-0ubuntu27.4 => 2.20.11-0ubuntu27.5] (core, i386-whitelist)
-queuebot:#ubuntu-release- New: accepted gnucap-python [amd64] (groovy-proposed) [0.0.2-1.2]
-queuebot:#ubuntu-release- New: accepted gnucap-python [armhf] (groovy-proposed) [0.0.2-1.2]
-queuebot:#ubuntu-release- New: accepted gnucap-python [riscv64] (groovy-proposed) [0.0.2-1.2]
-queuebot:#ubuntu-release- New: accepted libgtextutils [amd64] (groovy-proposed) [0.7-7]
-queuebot:#ubuntu-release- New: accepted libgtextutils [armhf] (groovy-proposed) [0.7-7]
-queuebot:#ubuntu-release- New: accepted libgtextutils [riscv64] (groovy-proposed) [0.7-7]
-queuebot:#ubuntu-release- New: accepted gnucap-python [arm64] (groovy-proposed) [0.0.2-1.2]
-queuebot:#ubuntu-release- New: accepted gnucap-python [s390x] (groovy-proposed) [0.0.2-1.2]
-queuebot:#ubuntu-release- New: accepted libgtextutils [ppc64el] (groovy-proposed) [0.7-7]
-queuebot:#ubuntu-release- New: accepted gnucap-python [ppc64el] (groovy-proposed) [0.0.2-1.2]
-queuebot:#ubuntu-release- New: accepted libgtextutils [s390x] (groovy-proposed) [0.7-7]
-queuebot:#ubuntu-release- New: accepted libgtextutils [arm64] (groovy-proposed) [0.7-7]
-queuebot:#ubuntu-release- New: accepted gnss-sdr [amd64] (groovy-proposed) [0.0.13-1]
-queuebot:#ubuntu-release- New: accepted gnss-sdr [armhf] (groovy-proposed) [0.0.13-1]
-queuebot:#ubuntu-release- New: accepted gnss-sdr [riscv64] (groovy-proposed) [0.0.13-1]
-queuebot:#ubuntu-release- New: accepted gnss-sdr [amd64] (groovy-proposed) [0.0.13-1~build1]
-queuebot:#ubuntu-release- New: accepted gnss-sdr [ppc64el] (groovy-proposed) [0.0.13-1~build1]
-queuebot:#ubuntu-release- New: accepted gnss-sdr [s390x] (groovy-proposed) [0.0.13-1~build1]
-queuebot:#ubuntu-release- New: accepted gnss-sdr [arm64] (groovy-proposed) [0.0.13-1]
-queuebot:#ubuntu-release- New: accepted gnss-sdr [s390x] (groovy-proposed) [0.0.13-1]
-queuebot:#ubuntu-release- New: accepted gnss-sdr [riscv64] (groovy-proposed) [0.0.13-1~build1]
-queuebot:#ubuntu-release- New: accepted gnss-sdr [ppc64el] (groovy-proposed) [0.0.13-1]
-queuebot:#ubuntu-release- New: accepted gnss-sdr [arm64] (groovy-proposed) [0.0.13-1~build1]
-queuebot:#ubuntu-release- New: accepted ifenslave [amd64] (groovy-proposed) [2.10ubuntu2]
-queuebot:#ubuntu-release- New: accepted iotjs [arm64] (groovy-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted iotjs [ppc64el] (groovy-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted iotjs [s390x] (groovy-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted iotjs [amd64] (groovy-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted iotjs [riscv64] (groovy-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted iotjs [armhf] (groovy-proposed) [1.0-2]
<xnox> !regression-alert bug #1889509 on xenial
<ubot5> bug 1889509 in grub2 (Ubuntu) "grub boot error : "symbol 'grub_calloc' not found" [Undecided,Confirmed] https://launchpad.net/bugs/1889509
<ubot5> xnox: I am only a bot, please don't think I'm intelligent :)
<xnox> chrisccoulson: did you see above?
<xnox> sil2100: can we pause phasing of grub2 on Xenial?
<xnox> cpc-help are Xenial images failing testing on aws?
<chrisccoulson> xnox, ack
<xnox> Not sure who else can pause phasing. Or if there is bug report / tag way to do it.
<xnox> Laney: apw: seb128: cjwatson: are you able to pause phasing of grub2/grub2-signed on Xenial please?
<seb128> I'm not in the SRU team and doesn't know how that works sorry
<seb128> sil2100 maybe could help there?
<seb128> also that's not going to fix people using apt, we should maybe just remove the update from -updates?
<seb128> or -security rather
<seb128> (would unattendeed-upgrade respect the pausing?)
<xnox> It's not in -security yet
<xnox> seb128: demote to proposed could be done.
<xnox> grub2 & grub2-signed
<chrisccoulson> so these are people using legacy bios who have grub installed to more than one disk, and only one grub image gets updated?
<xnox> In AWS cloud??
<Laney> I can demote it
<Laney> phasing doesn't help for clouds does it?
<xnox> We have dpkg questions to install grub legacy to more than one disk/partition.
<xnox> Laney: it does not.
<Laney> so yeah :p
<seb128> I vote for demoting to proposed
<Laney> what's the bug reference?
<seb128> is that impacting only xenial?
<seb128> Laney,  bug 1889509
<ubot5> bug 1889509 in grub2 (Ubuntu) "grub boot error : "symbol 'grub_calloc' not found" [Undecided,Confirmed] https://launchpad.net/bugs/1889509
<Laney> oh yeah I see it up there, thanks
<seb128> np!
<chrisccoulson> xnox, just looking at the comments on https://askubuntu.com/questions/1263125/how-to-fix-a-grub-boot-error-symbol-grub-calloc-not-found
<chrisccoulson> having modules and the grub kernel go out of sync seems the only plausible way for this to happen
<Laney> I'll do xenial, please confirm about other releases
<seb128> comment #3 state
<seb128> Same bug on Ubuntu 20.04 pro in Azure.
<seb128> https://askubuntu.com/questions/1263125/how-to-fix-a-grub-boot-error-symbol-grub-calloc-not-found is 20.04
<xnox> It means that Trusty ESM is probably affected too
<xnox> I am confused how it could go out of sync.
<seb128> xnox, chrisccoulson, should we demote to proposed on all series?
<Laney> "Demoting packages to xenial-updates-proposed"
<Laney> yeaaahhhhh no
<chrisccoulson> seb128, I'm not sure. given the bugs that this update addresses have a fair amount of press coverage, this is going to be, uhm, interesting
<xnox> seb128: new installs, new Ami, are not affected. Upgrades are.
<chrisccoulson> and EFI is unaffected
<seb128> chrisccoulson, we need maybe to pull more people in to take a decision
<Laney> I'll just remove it, it can be copied back to proposed by anyone if they want
<Laney> or re-released or whatever
<seb128> Wimpress, ^ help please
<xnox> Laney: right.
<xnox> It is being phased. It is regression alert, we should pause phasing.
<xnox> Which yeah, means demote to proposed.
<chrisccoulson> xnox, I assume they've gone out of sync because they've got the grub kernel installed to the MBR on more than one device, and grub-install only updated one of them (just a guess)
<Laney>  https://paste.ubuntu.com/p/XGH6bGWc5r/ confirm
<xnox> I'd like to figure out what's wrong on AWS and fix that.
<seb128> chrisccoulson, but yeah, it's going to be 'interesting' but probably less an issue than us bricking stack of machines in a stable update
<Laney> please
<xnox> Laney: looks good to me.
<cjwatson> xnox: That's not a regression
<xnox> cj
<chrisccoulson> hi cjwatson
<cjwatson> xnox: Every time GRUB changes significantly we get a flurry of reports along these lines; it's because of timebomb local configuration errors
<cjwatson> xnox: You know about the interface between GRUB's core image and modules?
<cjwatson> xnox: Part of GRUB lives in a "core image" at the start of the boot disk, and part of it lives in modules on the /boot file system.  They're supposed to be updated in sync by grub-install.  If those two things get out of sync, and if the interface between the core image and the modules change (which can happen on any update - there's no interface stability guarantee there), then you'll see ...
<cjwatson> ... this type of problem.
<Laney> ah ok, not removing then :>
<cjwatson> xnox: This happens on improperly configured BIOS systems
<xnox> It's fragile, our cloud images don't know which device they will be booted on, and when one upgrades them they get bricked. But we kind of supply both pieces, no?!
<cjwatson> xnox: The standard fix is "sudo dpkg-reconfigure grub-pc"
<cjwatson> xnox: Sure, there are problems here (hard to fix ones), but treating them as blocking a critical security update is totally wrong practice
<xnox> I wonder if we have ever had it done right on AWS, such that AMIs can survive grub upgrade.
<cjwatson> xnox: They're not actually related to the update as such
<cjwatson> xnox: Any GRUB change that introduced a new core image symbol that modules need would encounter something similar on such misconfigured systems
<xnox> Ok
<chrisccoulson> we should probably add another section to the knowledgebase article
<cjwatson> xnox: So certainly if we've been shipping cloud images in a state where the GRUB packaging doesn't know where to install GRUB, that's obviously a problem that we need to fix, but it must have been around forever and hit previously on multiple occasions
<Laney> can you see the problem before you restart?
<xnox> cjwatson: I recall seeing extensive cloud-init change to "fix grub state" which broke since AWS move to nvme drives.
<chrisccoulson> cjwatson, would you be able to do that? (adding another bit to the "Recovery" section of https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass)
<cjwatson> xnox: grub-pc.postinst has countermeasures that try to spot the installation device not being present.  It's possible those are somehow not working, or something else
<cjwatson> chrisccoulson: No, I'm on leave until Monday
<chrisccoulson> cjwatson, aha, no worries
<chrisccoulson> sorry :)
<cjwatson> Wittering on IRC is easy
<chrisccoulson> let me try to recreate a broken configuration and then I'll try to go through the steps of recovering it
<cjwatson> (And ideally we'd work out a change to move the target grub-install device to a proper configuration file rather than it living in debconf)
<cjwatson> (Would still have to be packaging-specific, and I'd need to review it because we need to agree any approach along those lines between Debian and Ubuntu.  But it's a long-standing wart)
<xnox> Laney: chrisccoulson: execute dpkg-reconfigure grub-pc on bios booted machines after update is applied, but before reboot is a good thing to do. Either harmless, or will prevent boot failure. For one to double check that the right drives are configured for boot.
<chrisccoulson> xnox, yeah, ideally I'd like to walk through the process on a broken configuration before updating the knowledgebase article
<cjwatson> And obviously I don't have a veto on you deciding to pull a security update due to cloud image upgrade problems; I just want to make sure that people properly understand the nature of the problem
<xnox> cjwatson: juliank was working on installing to multiple ESPs and pc-bios partitions and keeping them all in sync. But I am not sure if all our desires are complete there. Including like autodetecting all the grubs and updating them all.
<cjwatson> xnox: Full autodetection sounds like an approach I would veto in Debian, because it would potentially trash existing disks that *shouldn't* have their boot sectors touched
<Laney> could you get this via unattended-upgrades and get timebombed without being aware of it?
<xnox> Yeah, I need CPC help on this. To see if we are building our aws images wrong. Should be reproducible by downgrading to release too.
<cjwatson> xnox: But it depends on the details
<xnox> Laney: yes one will. And the timebomb is the duration since last grub2 update we pushed, or since one installed. Whichever is shorter.
<sil2100> Laney: not yet, as unattended-upgrades only pull in -security IIRC (and it's in -updates only for now), but I guess it would be possible once it lands in security
<xnox> cjwatson: right.
<xnox> sil2100: oh yes!
<sil2100> eh
<cjwatson> There's some code in grub-pc.postinst that tries to scan for existing grub2 boot sectors (for the purpose of upgrading from grub legacy), but it's very difficult to do
<cjwatson> xnox: No, it's the duration since the last update that changed core/modules ABI
<cjwatson> (May happen to be the same in this case, but not necessarily)
<xnox> Right. Most grub SRUs we shipped change like things in grub-mkconfig rather than anything substantial in the bios core.
<cjwatson> The other situations that tend to produce this are more easily ascribed to user error (although admittedly the requirements are not very well documented; but at least they tend to correspond to something the user did)
<cjwatson> Replacing a disk, or a bad cloning process
<Laney> I was obtusely getting at writing something down on the wiki not being sufficient for those systems
<cjwatson> I struggled with improving the situation here for literally years
<cjwatson> It's really hard to get right without breaking other things
<cjwatson> Not to say that it can't be improved, but nobody should expect it to have a quick or easy solution IMO
<cjwatson> BIOS sucks
<cjwatson> In the absence of a monolithic image the way we have on UEFI (which of course has other problems, and which often doesn't fit on BIOS systems anyway), probably the only robust way to do much better is to figure out how to scan for a best guess at the device that needs to have grub-install run on it.  Even then it will likely break some people with fiddly multibooting setups who will be super ...
<cjwatson> ... vocal about it
 * cjwatson out
 * xnox ponders if we can copy symbols into every module, which are not in the "core" ABI that we define per series, or some such.
<cjwatson> argh
<xnox> aka make core to be "stable" yet make all modules have all the symbols they need too
<cjwatson> you're going to stop me being out if you propose crazy ideas :P
<Wimpress> seb128: I'm reading the backlog...
<cjwatson> also, no, there's also no guarantee that core/modules won't change in ways that aren't visible at the ABI level
<xnox> I'll go talk to cpc, to ensure they have testcases to test that after image is booted, the dpkg/grub/etc know and will update the right cores on the right places.
<cjwatson> desynced core and modules may break, and copying symbols around won't fix that
<cjwatson> they must be in sync
<juliank> xnox, cjwatson vorlo n also does not want full autodetection, just fallback if we can't find configured targets
<juliank> Just installing to any random disk you attached was not the idea
<xnox> ack
<cjwatson> Right.  Probably won't fix every situation, but is a bit safer
<cjwatson> (ways that aren't visible at the ABI level: e.g. IIRC the recent security update changed the return type of some functions too, and that isn't visible in C ABIs.  Just an example)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-11 [s390x] (groovy-proposed/universe) [1:11.0.0~+rc1-1] (no packageset)
<xnox> chrisccoulson:  commented on the bug report and askubuntu. All mentions there were about "how to unbrick your boot this one time" none of them had long-term advice on fixing up / doing dpkg-reconfigure grub-pc to apply thing ever after to all the right drives.
 * xnox ponders if grub-install should offer "do you want to add this device to grub-pc debconf for automatic updates?
<apw> write a random uuid into the saved block of grub stage1 and record that for finding later
-queuebot:#ubuntu-release- New binary: llvm-toolchain-11 [ppc64el] (groovy-proposed/universe) [1:11.0.0~+rc1-1] (no packageset)
<Laney> http://autopkgtest.ubuntu.com/running
<Laney> what is going on with all those KDE packages
<Laney> "Start lintian"
<Laney> ?!
<ddstreet> xnox sil2100 you can't do a no-change-rebuild of systemd in bionic because it FTBFS, which is one of the bugs fixed in the upload that's been waiting for review for 22 days
<ddstreet> LP: #1886197
<ubot5> Launchpad bug 1886197 in systemd (Ubuntu Bionic) "FTBFS in b due to libseccomp change" [High,In progress] https://launchpad.net/bugs/1886197
<xnox> ddstreet: thanks for pointing this out!
<Laney> RikMills: are you here? can you look into these kubuntu autopkgtest hangs please?
<Laney> I'm thinking of uploading pkg-kde-tools to drop the lintian run in the meantime
<Laney> yes, I'm going to do that
<Laney> just quickly testing with one example that it actually fixes the problem
<Laney> bah, if you pass .debs to autopkgtest it doesn't use them for build-needed
<sil2100> xnox, ddstreet: let me review what's in that systemd upload right now
<xnox> Laney: autopkgtest is so silly!
<Laney> <PATCHES WELCOME>
<xnox> Laney:  blame pitti!
<sil2100> ddstreet: in case this upload gets accepted, how fast will you be able to get all the bugfixes verified?
<Laney> I employed a clever use of sleep to ssh in and dpkg -i the dep
<Laney> autopkgtest would have to be quite determined to undo that ...
<xnox> chrisccoulson:  Odd_Bloke: rick_h: rcj reports that AWS AMIs prior to 29th of April had cloud-init with cc_grub_dpkg run-once module that incorrectly specified /dev/sda to debconf, instead of nvmen0 to debconf.
<xnox> On xenial, that didn'g go out until June 28th
<xnox> so AMIs prior to cut-off dates have wrong cc_grub_dpkg executed.
<xnox> Odd_Bloke:  rick_h: can we push out cloud-init sru, that calls ds-identify, checks for AWS & nvme, and clears the state of cc_grub_dpkg / triggers a rerun of it via maintainer scripts somehow?
<xnox> Odd_Bloke:  rick_h: can you confirm when the fixes landed in cloud-init xenial...groovy?
<rcj> I grabbed AWS AMI (us-west-2) ami-0813245c0939ab3ca which was released on 2020-04-29 because I wanted to be on the other side of the cloud-init cc_grub_dpkg patch https://git.launchpad.net/cloud-init/commit/cloudinit/config/cc_grub_dpkg.py?id=fc07d633f7cb694423349a2c4b10c91c4b4981a2
<rcj> I used an m5a.large instance because it's nitro-based and will have a root on nvme
<sil2100> grrr systemd SRUs
<xnox> rcj:  is there any vendor metadata we can push out?
<rcj> xnox: Haven't we had reports of issues with 20.04 Pro in azure? (re: your suggestion to check ds-identify for aws)
<rcj> xnox: how do you mean?  what are you thinking?
<xnox> rcj:  please check backscroll. I remember somebody callling 20.04 PRO but not sure which cloud and which place. Maybe it was lp bug report?!
<ddstreet> sil2100 i can verify all the reproducable bugs today, there are fixes for lp #1881972 and lp #1886115 which are reproducable by the bug reporter, though the former has already been verified by the bug reporter and the latter is a trivial clearly correct patch
<ubot5> Launchpad bug 1881972 in systemd (Ubuntu Bionic) "systemd-networkd crashes with invalid pointer" [Medium,In progress] https://launchpad.net/bugs/1881972
<ubot5> Launchpad bug 1886115 in systemd (Ubuntu Bionic) "libseccomp 2.4.3-1ubuntu3.18.04.2 causes systemd to segfault on boot" [Medium,In progress] https://launchpad.net/bugs/1886115
<xnox> rcj:  to pubhlish vendor-metadata in the cloud to do one-off re-configure of cc_grub_dpkg
<rcj> xnox: azure pro image is mentioned in https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889509/comments/3
<ubot5> Ubuntu bug 1889509 in grub2 (Ubuntu) "grub boot error : "symbol 'grub_calloc' not found" [Undecided,Confirmed]
<rcj> xnox: nope, there is no vendor metadata service like that.
<ddstreet> and lp #1832754 which also is not reproducable by me but a clearly correct patch
<ubot5> Launchpad bug 1832754 in systemd (Ubuntu Bionic) ""shutdown[1]: Failed to wait for process: Protocol error" at shutdown or reboot and hangs." [Medium,In progress] https://launchpad.net/bugs/1832754
<xnox> rcj:  sad about lack of vendor metadata
<xnox> rcj:  the azure pro => is it nvme issue too?
<xnox> rcj: Odd_Bloke: rick_h: are there any instructions we can add to "fix" clouds? I.e. "$ sudo cloud-init run-one cc_grub_dpkg"
<rcj> xnox: I haven't gotten there yet to check things out
<xnox> To the knowledge base article.
<rcj> xnox: are you editing?  Wasn't clear if that was telling me what you're doing or asking me to do it.
<sil2100> ddstreet: ok, thanks - too bad the reporter of LP: #1832754 seems to have went silent
<ubot5> Launchpad bug 1832754 in systemd (Ubuntu Bionic) ""shutdown[1]: Failed to wait for process: Protocol error" at shutdown or reboot and hangs." [Medium,In progress] https://launchpad.net/bugs/1832754
<RikMills> Laney: have you any idea what changed in last 48hrs? I uploaded new kde plasma Tuesday, and its tests had no problem
<xnox> Odd_Bloke:  rick_h: opened cloud-init bug, https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1889555 please check if it is feasiable to add maintainer scripts, to call cc_grub_dpkg, again, once-only, upon upgrade of cloud-init package.
<ubot5> Ubuntu bug 1889555 in cloud-init (Ubuntu Groovy) "cc_grub_dpkg was fixed to support nvme drives, but didn't clear the state of cc_grub_dpkg and didn't rerun it on upgrades" [Undecided,New]
<xnox> juliank:  chrisccoulson: cjwatson: on AWS, rcj has identified that despite debconf saying to install grub-pc onto /dev/sda, non-interactively, grub-install onto /dev/sda fails (as it does not exist), and yet the package is configured fine. At this point, it is fair to assume that the device in debconf database is wrong/has been renamed (i.e. should have been nvmen0) and yet we configured
<xnox> grub-pc/grub-pc-bin and upgraded all modules that are now missmatched from core. Imho grub package configuration should at this point fail and rollback to the old modules.
<xnox> such that there is no missmatch between the core on the nvme & modules on disk.
<cjwatson> I think untag me at this point unless you have a patch against the Debian source tree for me to review :)
<juliank> xnox: it should reprompt you if the device has gone missing
<juliank> that's what the efi code does
<juliank> but then I copied the EFI code from the bios code
<cjwatson> I just wanted to give context for what it was supposed to do - I'm not going to debug the Ubuntu postinst
<juliank> so i find this confusing
<cjwatson> (I agree, it's definitely supposed to prompt you, there's a whole swathe of code specifically for that)
<xnox> =)))))
<xnox> rcj:  https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1889555
<ubot5> Ubuntu bug 1889555 in cloud-init (Ubuntu Groovy) "cc_grub_dpkg was fixed to support nvme drives, but didn't clear the state of cc_grub_dpkg and didn't rerun it on upgrades" [Undecided,New]
<xnox> jdstrand_:  at this point i don't think we should push grub2 to security pocket, until at least after we either have cloud-init fix or grub maintainer fix.
<rcj> xnox: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889556
<ubot5> Ubuntu bug 1889556 in grub2 (Ubuntu) "grub-install failure does not fail package upgrade (and does not roll back to matching modules)" [Undecided,New]
<xnox> sil2100:  vorlon: the above does not block spinning new media / shipping existing grub.
<xnox> sil2100:  vorlon: but imho we should pause phasing / not push this update to security. until we either have grub2 postinst fix, or cloud-init fix.
<Odd_Bloke> rcj: xnox: Good morning, I'm catching up on scrollback.
<xnox> Odd_Bloke:  tl;dr https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889556 & https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1889555 are good summaries. Old cloud-init, bites us, on nvme, months later, when we try to push out grub2 update.
<ubot5> Ubuntu bug 1889556 in grub2 (Ubuntu Groovy) "grub-install failure does not fail package upgrade (and does not roll back to matching modules)" [Undecided,New]
<ubot5> Ubuntu bug 1889555 in cloud-init (Ubuntu Groovy) "cc_grub_dpkg was fixed to support nvme drives, but didn't clear the state of cc_grub_dpkg and didn't rerun it on upgrades" [Undecided,New]
<xnox> Odd_Bloke:  and at the same time, grub2 maintainer scripts appear to ignore non-existence of boot devices.
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu10.42]
<sil2100> xnox: ACK, yeah, sounds nasty
<xnox> sil2100:  vorlon: but imho we should pause phasing / not push this update to security. until we either have grub2 postinst fix, or cloud-init fix.
<sil2100> ddstreet: accepted, quick verification would be very useful as we want this for .5!
<sil2100> xnox: ok, I can look into stopping the phasing
<xnox> sorry for the dupe post
<xnox> sil2100:  yes please.
<Odd_Bloke> xnox: rcj: I'm not 100% I understand the severity of the issue here: from the cloud-init bug filed it sounds like "this has been broken for years but was recently fixed" but the urgency with which we are talking about it right now suggests to me that we've in some way regressed something, and I can't tell what that is.
<xnox> Odd_Bloke: many grub updates do not change ABI. And upgrades work correctly on non-nvme cloud init instances.
<rcj> Odd_Bloke: All images launched with a cloud-init earlier than the fix for (LP: #1877491) will fail to reboot after grub is installed
<ubot5> Launchpad bug 1877491 in cloud-init "cc_grub_dpkg: determine idevs in a more robust manner with grub-probe" [Undecided,Fix committed] https://launchpad.net/bugs/1877491
<xnox> Odd_Bloke: when grub on nvme was fixed in cloud-init, it was not fixed for existing instances, only for newly launched ones.
<rcj> Odd_Bloke: reports have been seen from AWS, Azure, and MAAS in bug #1889509
<ubot5> bug 1889509 in grub2 (Ubuntu) "grub boot error : "symbol 'grub_calloc' not found" [Undecided,Confirmed] https://launchpad.net/bugs/1889509
<xnox> Odd_Bloke: thus #1877491 is still unfixed on nvme.
<xnox> Odd_Bloke: and we are pushing incompatible ABI grub-pc security update for trusty to Xenial.
<xnox> Odd_Bloke: do you want a hangout?
<Odd_Bloke> So are we saying the fix we landed for bug 1877491 has not fixed this issue everywhere it could (or should) have?  Or are we saying that that fix is causing this issue?
<ubot5> bug 1877491 in cloud-init "cc_grub_dpkg: determine idevs in a more robust manner with grub-probe" [Undecided,Fix committed] https://launchpad.net/bugs/1877491
<Odd_Bloke> (To be clear, I'm just ensuring I understand the issue, I'm not trying to be defensive about it!)
<xnox> Odd_Bloke: "has not fixed everywhere it could"
<xnox> Odd_Bloke: i.e. when fixing bug in run-once modules, one should be considering to add maintainer scripts to rerun / fixup the broken piece via maintainer scripts. In general. But this one in particular.
<rcj> Odd_Bloke: The issue being that cc_grub_dpkg is frequency once-per-instance and the fix for 1877491 didn't force that to re-run
<rcj> Leaving running instances or new instances booted from older images and updated unfixed.
<rcj> xnox: how does phasing work with cloud mirrors?  Will it have any effect?
<xnox> rcj:  zero =)
<sil2100> rcj: phasing basically only relates to the UI upgraders
<rcj> yeah, I expected that was the answer from everything I knew but I wanted explicit confirmation
<rcj> thx
<sil2100> Since this *is* a security update btw., was the security team ok with stopping the phasing?
<xnox> sil2100:  that was discussed as contingency, yes.
<Odd_Bloke> In general, we will not apply new behaviour to running instances on upgrade, but then again it's rare that the new behaviour is required for instances to continue functioning.
<xnox> sil2100:  plus even applying these updates is insufficient. one has to apply dbxupdate, which we cannot push out yet.
<xnox> sil2100:  so even if one can fetch all the packages it's not enough.
<xnox> Odd_Bloke:  correct, that's a judgement call. In affect, at the moment, on nvme based instances it's a ticking time bomb. And it has now ticked to zero =)
<xnox> so very case by case issue.
<xnox> Odd_Bloke: but we know how to fix it automatically, and if we push out cloud-init sru to fix things up for people. we can push out grub2 to security, and nobody will be affected and can continue to install updates unattended and reboot.
<Odd_Bloke> xnox: If we push grub2 out to -security but cloud-init only goes to -updates, do we have a problem?
<xnox> Odd_Bloke:  yes, because grub2 will be autoinstalled within 24h by unattended-upgrades, where as cloud-init will not.
<xnox> Odd_Bloke:  hence ideally this cloud-init SRU should be built against security pocket, and push out to security pocket, wihtout USN.
<xnox> Odd_Bloke:  effectively this is denial of service, as reboot makes instance fall off the internet / fail to boot.
<Odd_Bloke> That would be a major bump of cloud-init version in -security (well, there are none in -security, so -release): from 0.7.7~bzr1212-0ubuntu1 to 20.2-45-g5f7825e2-0ubuntu1~16.04.1 on xenial.
<Odd_Bloke> (That's just an observation: I don't know what the consequences of that would be off-hand.)
<xnox> Ouch
<xnox> Did nvme instances exist back then?
<xnox> We can add in grub2 that in breaks cloud-init << version-that-fixes-nvme-in-maintainer-script
<xnox> That should cause to pull & install cloud-init from updates.
<xnox> Or hold off grub security unattended upgrade
<Odd_Bloke> xnox: That sounds like a solution to me, I don't really know enough about the "expected" behaviour of -security for this sort of case, so I can't really approve/disapprove though. :p
<seb128> xnox, or lead to grub being removed *g*
<Odd_Bloke> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1336855 <-- apparently not the first time we've dealt with something like this!
<ubot5> Ubuntu bug 1336855 in cloud-init (Ubuntu Utopic) "[SRU] non-interactive grub updates broken for /dev/xvda devices on Cloud-Images/Cloud-init" [Critical,Fix released]
<sil2100> argh, crash in change-override call for phasing reset, ouchy
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1046.47] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1046.47]
<chrisccoulson> I've just read through the scrollback but it's not clear to me yet what action we're going to take
<Odd_Bloke> xnox: OK, so are you looking at that postinst change, or shall I start taking a look?
<xnox> Odd_Bloke:  we need cloud-init fix irrespective of grub2 changes.
<xnox> Odd_Bloke: if you have something that was used for similar issue before, yes please reuse that.
<Odd_Bloke> chrisccoulson: So I think that we can make the postinst change to cloud-init and release that to -updates; this should mean (perhaps with grub dependency changes to force installation first?) that instances configured with -updates (i.e. most of them) should be fixed.  The question of how to fix -security-only instances is still open, from my POV.
<xnox> db_set grub-pc/install_devices "$parent_dev"
<Laney> I think if you want to avoid a wholesale update in -security then a cherry pick of the fix itself would be better than anything involving Breaks or whatever
<xnox> +           grub-install $parent_dev ||
<xnox> +              echo "WARNING! Unable to fix grub device mismatch. You may be broken."
<xnox> are the key / right pices.
<xnox> Odd_Bloke:  db_set & grub-install are the right things to do.
<Odd_Bloke> xnox: So you think we should use those directly in the postinst, rather than executing the cloud-init module?
<xnox> Odd_Bloke:  up to you. whichever way.
<xnox> Odd_Bloke:  imho, it is cleaner to re-execute the module. But I don't know if that's easy/safe to do.
<xnox> versus by-hand handling.
<chrisccoulson> Odd_Bloke, thanks
<xnox> Odd_Bloke:  we know that what module does is good and correct.
<xnox> chrisccoulson:  we need to push dpm trees to the correct repository now, no?
<xnox> chrisccoulson:  did you push tags to repo we used in the ppa?
<chrisccoulson> xnox, I didn't. There is already a tag in the repo for the version number we released
<chrisccoulson> (I have just pushed the latest version of the branch though)
<xnox> chrisccoulson:  ack thanks.
<xnox> juliank:  pushing current focal branch to focal-devel; pushing chrisccoulson's branch as focal-security. Somehow we'll need to reconcile the two and merged them into one true focal.
<juliank> xnox: ack
<juliank> xnox: I can have a go at that on Monday
<chrisccoulson> xnox, thanks
<chrisccoulson> Is there anything I'm needed for at the moment?
<xnox> chrisccoulson:  not really
<Odd_Bloke> rcj: xnox: Does this summary look correct? https://paste.ubuntu.com/p/h9qdZfbCbc/
<xnox> Odd_Bloke:  yes.
<xnox> Odd_Bloke:  you can also mention that "yes, it's also a bug that grub completes package upgrade, when it knows that it failed to update core. That is being addressed separately too, but forces interactive intervention."
<xnox> "cloud-init can fix this for nvme drives non-interactively"
<Odd_Bloke> xnox: And that's LP: #1889556, right?
<ubot5> Launchpad bug 1889556 in grub2 (Ubuntu Groovy) "grub-install failure does not fail package upgrade (and does not roll back to matching modules)" [Undecided,New] https://launchpad.net/bugs/1889556
<xnox> Odd_Bloke:  yes.
<jdstrand> xnox: ack
<LocutusOfBorg> xnox, did you open the merge request? https://gitlab.haskell.org/ghc/ghc/-/issues/18445
<jdstrand> xnox: I'll be sure to coordinate with rcj, xnox and chrisccoulson before doing anything
<jdstrand> not sure why I said 'xnox' rather than 'you' there...
<rcj> Odd_Bloke: I would say this is broader than "NVMe instances", it would be anywhere that cloud-init incorrectly configured grub install-devices.  I say this because we have reports of Azure and MAAS (raid was mentioned) that I haven't dove into.
<RikMills> Laney: is there any way to test that a build is being done in a test runner rather than a normal archive buildd?
<Laney> I dunno, README.package-tests.rst documents some variables but I'm not sure what's set at build-needed time
-queuebot:#ubuntu-release- New binary: llvm-toolchain-11 [amd64] (groovy-proposed/universe) [1:11.0.0~+rc1-1] (no packageset)
<Laney> this feels like the wrong way to solve it though, I would rather see a fix that figures out why it's hanging and resolves that
<RikMills> I agree. I don't have time to investigate at the moment though
<rcj> Odd_Bloke: I mention the scope because a solution might need to look at debconf to see if install-devices are valid rather than looking to see if we're booted on NVMe
<xnox> jdstrand:  me myself and I are not offended.
<jdstrand> hehe :)
<Laney> we've started pushing poor old snakefruit over the edge
<Laney> load average 14
<Odd_Bloke> xnox exists only in the first and third persons.
<Odd_Bloke> rcj: Right, I would be a little hesitant to apply this so broadly when we only know about this case.
<Odd_Bloke> (The original change itself was motivated by AWS Nitro instances, I believe, not by a more generally understood issue.)
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-11 [amd64] (groovy-proposed) [1:11.0.0~+rc1-1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-11 [s390x] (groovy-proposed) [1:11.0.0~+rc1-1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-11 [ppc64el] (groovy-proposed) [1:11.0.0~+rc1-1]
<rcj> Odd_Bloke: Sure, but 1889509 mentions Azure and MAAS so we have a bit more to understand here.
<Odd_Bloke> rcj: Ack, had missed that one.
<rcj> and with maas I think I saw RAID
<vorlon> xnox: breaks from grub2 in security won't cause unattended-upgrades to pull cloud-init from updates, it will only cause unattended-upgrades to hold back grub2
<Odd_Bloke> rcj: I guess I'm a little hesitant to use "install-devices are valid", because if a user has changed that then we probably shouldn't be touching it.
-queuebot:#ubuntu-release- New source: sup-mail (focal-proposed/primary) [1.0-3~0ubuntu20.04.1]
<Odd_Bloke> But we could potentially do "install-devices is /dev/sda and invalid"?
<Odd_Bloke> rcj: I also have a very vaguely defined worry about corner cases where the install-devices are not present when we upgrade or something like that; put another way, I don't know if "an absent install-devices implies it is invalid" is universally true.
<rcj> Yeah, and we're stepping across into grub's domain tbh.  If grub needs it to be valid during install/upgrade then it needs to ensure it's right.  So for the NVMe bug that was fixed without touching existing config we should, as you're suggesting, find a way to correct that debconf.
<rcj> I'm just worried that there is a larger problem space where cloud-init isn't/wasn't setting grub install-devices to a valid device.
<Odd_Bloke> Yep, I share that worry.
<cyphermox> can you really always say /dev/sda is your install-devices? it's unlikely to be valid across the board when the image runs
<rcj> Odd_Bloke: but really a fix for bug #1889556 will catch the issue during grub-install, rollback grub to something that still reboots, and we'll get apport data to fix those places that cloud-init hasn't gotten debconf right (if additional situations do exist)
<ubot5> bug 1889556 in grub2 (Ubuntu Groovy) "grub-install failure does not fail package upgrade (and does not roll back to matching modules)" [Undecided,Confirmed] https://launchpad.net/bugs/1889556
<rcj> cyphermox: You absolutely can't say /dev/sda is your install device universally and cloud-init cc_grub_dpkg module looks to get it set correctly in debconf for grub on first boot.
<cyphermox> yeah, that's what I was trying to say
<Odd_Bloke> rcj: Right, so long as we have a backstop like that then I think we're fine with the more targetted fix?
<rcj> Odd_Bloke: Yeah, thanks for rubber ducking with me.
<rcj> I'm not sure who the duck is
<sil2100> xnox: oh, actually, now that we have systemd in bionic-proposed, let me review and accept your debian-installer!
<rcj> Odd_Bloke: Can you think of other distros that need to know about this because they use cloud-init?  deb-based distros but is there something similar for the rpm-based folks?
<rcj> A question that probably better fits #cloud-init..
 * rcj walks down the hall to #cloud-init
<xnox> sil2100:  horay!
-queuebot:#ubuntu-release- New binary: linux-signed-oem-5.6 [amd64] (focal-proposed/main) [5.6.0-1021.21] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (groovy-proposed) [1.3.11-2]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (groovy-proposed) [1.3.11-2]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (groovy-proposed) [1.3.11-2]
-queuebot:#ubuntu-release- New: accepted linux-signed-5.7 [amd64] (groovy-proposed) [5.7.0-15.16]
-queuebot:#ubuntu-release- New: accepted linux-signed-5.7 [s390x] (groovy-proposed) [5.7.0-15.16]
-queuebot:#ubuntu-release- New: accepted linux-signed-5.7 [ppc64el] (groovy-proposed) [5.7.0-15.16]
<vorlon> rbalint_: google-compute-engine-oslogin: deprecated debhelper version in a new package?
<sil2100> xnox: hm hm hmmm! So, for 18.04.5 it is the time when we switch the hwe kernels from 5.3 to 5.4
<sil2100> While your d-i upload is still using the 5.3 kernel
<sil2100> xnox: you want to reupload with the version from https://launchpad.net/ubuntu/+source/linux-meta-hwe-5.4 ;) ?
-queuebot:#ubuntu-release- New: accepted google-compute-engine-oslogin [source] (groovy-proposed) [20200507.00-0ubuntu1]
-queuebot:#ubuntu-release- New source: telegraf (groovy-proposed/primary) [1.15.1+ds1-0ubuntu1]
<LocutusOfBorg> sergiodj, ^^
<sergiodj> LocutusOfBorg: thanks!
<xnox> sil2100:  please reject
<xnox> sil2100:  hmmmm
<xnox> is that the right package name i wonder.
<xnox> apw:  is linux-meta-hwe-5.4 intentional? or should it be https://launchpad.net/ubuntu/+source/linux-meta-hwe ? i.e. did we give up on '-5.4' or not?
<xnox> sil2100:  i thought we tried linux-5.4 and then dropped that.
<xnox> klebers:  ^^^^
<Odd_Bloke> xnox: When the cloud-init module runs during postinst, we get this when trying to run debconf-set-selections: debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable
<Odd_Bloke> Does this mean we'll need to handle this "manually" using db_get/db_set, or is there another way around it?
<klebers> xnox, the meta package name really changed to linux-meta-hwe-5.4
<sil2100> xnox: yeah, that's the new style, man!
<klebers> xnox, that's the source pkg name, but the binary meta is the same
<sil2100> Welcome to 2020!
<vorlon> xnox: "Once singed with the archive key" - while I can see the parallel to cattle branding, you might want to fix the typo in the package description
<sil2100> ;)
-queuebot:#ubuntu-release- Unapproved: rejected debian-installer [source] (bionic-proposed) [20101020ubuntu543.16]
-queuebot:#ubuntu-release- New: accepted shim-canonical [source] (groovy-proposed) [1]
<xnox> vorlon:  i am confused
<vorlon> xnox: signed, not singed
<xnox> vorlon:  what's the typo, and where did i make it?
<vorlon> xnox: in the shim-canonical package
<xnox> vorlon:  thanks for reviewing that without context =) weeks later
<vorlon> xnox: my pleasure
<xnox> klebers:  thank, thanks a lot!
<Laney> If you enjoyed the service ubuntu-archive provided today, please leave us a 5* review on Google Maps
<xnox> Odd_Bloke:  you must use db_get/db_set; do ensure you run without set -e; or correctly handle _all_ return codes form debconf calls. i.e. thing slike 10 30 etc.
<Odd_Bloke> ;.;
<xnox> Odd_Bloke:  if things are easy i just dput them; it's only the hard bugs that i talk about; file bugs; do "collaboration" =)
-queuebot:#ubuntu-release- New binary: shim-canonical [arm64] (groovy-proposed/universe) [1] (no packageset)
<Odd_Bloke> xnox: You're saying you're collaborating against me? ;)
<Beret> I believe that would be "conspiring" :)
-queuebot:#ubuntu-release- New binary: shim-canonical [amd64] (groovy-proposed/universe) [1] (no packageset)
-queuebot:#ubuntu-release- New: accepted agda [amd64] (groovy-proposed) [2.6.1-1]
-queuebot:#ubuntu-release- New: accepted agda [s390x] (groovy-proposed) [2.6.1-1]
-queuebot:#ubuntu-release- New: accepted agda [ppc64el] (groovy-proposed) [2.6.1-1]
<Odd_Bloke> xnox: So the previous time we did something like this (i.e. https://github.com/canonical/cloud-init/blob/ubuntu/devel/debian/cloud-init.postinst#L193-L199) we performed a grub-install immediately after updating debconf; do you think we should do the same here, so that if we've misconfigured things there's an immediate indicator?
<xnox> Odd_Bloke:  yes.
<xnox> Odd_Bloke:  some people have already installed new grub. And if they install cloud-init sru, they do need debconf fix + re-grub-install.
<xnox> (installed new grub, but no yet rebooted)
<xnox> sil2100:  pc gadget for amd64&i386 has been rebuild with boothole fixed grub, for uc16 and uc18. Without bumping editions.
<xnox> sil2100:  can you respin uc16 & uc18 beta channel images? or are they built daily?
<sil2100> xnox: those are built daily if anything
<sil2100> (we do dailies of both edge and beta images)
<sil2100> You want me to kick those now anyway?
<xnox> sil2100:  well it needs to be passed over to Cert right? and then i want to promote those gadgets to stable, as soon as fresh images are tested good with it.
<Odd_Bloke> xnox: rcj: I'm going to grab lunch now, here's a rough initial implementation of the postinst change: https://paste.ubuntu.com/p/h8rjJTnFfY/ please let me know what you think!
<rcj> Odd_Bloke: sounds like xnox is collaborating at you pretty intensively
<rcj> Odd_Bloke: I don't know how nvme enumeration works and if you could ever have nvme# without having nvme0 (re: line 26 in your patch)
<rcj> Odd_Bloke: I agree that cloud-init install shouldn't exit 0 but you might elaborate from "You may be broken" to say what may be broken and how to check.  "You may be unable to reboot.  Consider running 'sudo dpkg-reconfigure grub-pc' to set a install device"
<rcj> which is pretty wordy
 * rcj -> lunch
<rcj> Odd_Bloke: Looks good overall, just had those 2 bits of feedback.
<xnox> Odd_Bloke:  i love your elisp one-liner there
-queuebot:#ubuntu-release- New binary: haskell-hgettext [s390x] (groovy-proposed/universe) [0.1.31.0-7] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hgettext [amd64] (groovy-proposed/universe) [0.1.31.0-7] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hgettext [ppc64el] (groovy-proposed/universe) [0.1.31.0-7] (no packageset)
<xnox> Odd_Bloke:  the function should take "$2" like the other fixers, and you want to dpkg --compare-versions with 20.2-95 such that any upgrades from less than 20.2-95 will trigger executing this code on upgrade to this version of cloud-init only once.
<xnox> Odd_Bloke:  there is no need to run this code on every cloud-init package install / upgrade, going forward.
-queuebot:#ubuntu-release- Unapproved: landscape-client (xenial-proposed/main) [16.03-0ubuntu2.16.04.7 => 16.03-0ubuntu2.16.04.8] (ubuntu-server)
<Laney> I'm going to run out of time, was going to kill all of the stuck kubuntu tests once pkg-kde-tools finished publishing
<Laney> but it's not done that
<Laney> if someone wants to, it's the things that have stalled on "=== Start lintian"
<Laney> kill those once pkg-kde-tools ubuntu2 is available in release
<Laney> otherwise they should eventually timeout :/
<Laney> (kill the autopkgtest processes on the cloud worker, that is)
-queuebot:#ubuntu-release- New binary: haskell-hgettext [arm64] (groovy-proposed/universe) [0.1.31.0-7] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-hgettext [armhf] (groovy-proposed/universe) [0.1.31.0-7] (no packageset)
<Odd_Bloke> xnox: Yep, hence the TODO at the top of the function; thanks for the invocation!  Any other comments?
<Odd_Bloke> xnox: Do you mean `20.2-45`?
<xnox> Odd_Bloke: groovy has 20.2-94. I could have launched an old instance and dist-ugpraded to groovy by now, and still be broken.
<xnox> Odd_Bloke:  and upgrades "worked" because we have not broken grub core <-> modules abi, until just now in groovy.
<xnox> hence upgrading from less than 20.2-95 should trigger the fixer.
<Odd_Bloke> Aha, right, had forgotten another upload to groovy happened since the SRU (I wonder who uploaded that Â¬.Â¬); thanks!
<xnox> do use that comparison that treats empty/zero version number as infinity. such that on first-time install of cloud-init the fixer is not triggered.
-queuebot:#ubuntu-release- Unapproved: s390-tools (groovy-proposed/main) [2.12.0-0ubuntu5 => 2.12.0-0ubuntu6] (core)
-queuebot:#ubuntu-release- New binary: haskell-hgettext [riscv64] (groovy-proposed/universe) [0.1.31.0-7] (no packageset)
-queuebot:#ubuntu-release- Unapproved: debian-installer (bionic-proposed/main) [20101020ubuntu543.15 => 20101020ubuntu543.16] (core)
<Odd_Bloke> xnox: rcj: Updated proposal: https://paste.ubuntu.com/p/HQZZcWDRDQ/ Note that there is one "XXX" comment in there that I would appreciate your opinions on.
<Odd_Bloke> I think this is close enough that I'll open up a PR with it; that will give us somewhere to actually keep review comments.
<xnox> Odd_Bloke:  i would skip that paragraph.
<xnox> Odd_Bloke:  fetch grub_cfg_dev; fetch corect_idef; compare and key off that.
<xnox> Odd_Bloke:  cause grub_cfg_dev might be xenvhda thing, despite booting of nvme actually for example.
<xnox> Odd_Bloke:  and we still need to correct from vda to nvme
<xnox> Odd_Bloke:  it is strictly redundant. and limits amounts of things we could fix.
<Odd_Bloke> xnox: Under what circumstances would it be xvda?
<Odd_Bloke> The old cloud-init code would default to /dev/sda if it didn't find any appropriate devices.
<rcj> Odd_Bloke: I don't have high enough confidence in my knowledge of the original bug to say if your check on line 35 does match the comment before it.  But given your statement as I typed this, then yes.
<Odd_Bloke> (By appropriate I mean: in the hard-coded set of paths it considered.)
<Odd_Bloke> So I believe if it's /dev/xvda, then when this instance was first booted, /dev/xvda was present.
<rcj> right
<rcj> I just whinged thinking about the instance resize feature and whether cloud-init detects that as a new instance (and will re-run cc_grub_dpkg) or nto.
<Odd_Bloke> "instance resize" being "move from one instance type to another"?
<apw> xnox, linux-hwe-5.4> nominally the first linux-hwe in a cycle is linux-hwe, the others are linux-hwe-<version> because they overlap; like right now hwe@4.15, hwe@5.0, hwe@5.3 and hwe@5.4 are all alive in bionic for various reasons
<Odd_Bloke> (And therefore possibly changing the root disk from being presented at /dev/xvda to /dev/nvme... ?)
<rcj> yeah
<rcj> or /dev/xvda to /dev/sda
<Odd_Bloke> rcj: xnox: https://github.com/canonical/cloud-init/pull/514/
<gitbot> canonical issue (Pull request) 514 in cloud-init "debian/cloud-init.postinst: fix NVME grub install device on upgrade" [Open]
<mwhudson> sil2100: just releasing subiquity to stable now, not sure when you're next planning on rolling images
<Odd_Bloke> Also: currently this isn't scoped to only run on AWS (which I don't think it should be), but that means that we need to make sure we're considering other potential use cases.
<rcj> Agreed
<rcj> I think the checks are good
<xnox> Odd_Bloke:  this is not just xenial....
<vorlon> xnox: should gfxboot-theme-ubuntu be removed from groovy?
<vorlon> hmm ubuntu-defaults-builder depends on it
<vorlon> but does that work
<xnox> ubuntu-defaults-builder does not work
<hggdh> rcj: I added data from one VM in bug 1889505
<vorlon> joy
<ubot5> bug 1889505 in Mahara "Behat: create import_export_skins feature" [Undecided,New] https://launchpad.net/bugs/1889505
<xnox> vorlon:  mwhudson: https://code.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/+merge/388423 it's looking not that bad. I'll grab chocolate, and then want to test postinst change, and then test this preinst.
<hggdh> dammit. Me an my typing... 1889509
<mwhudson> argh *now* i'm releasing a new subiquity to stable
<mwhudson> oh hm previous version was just missing the tag not so bad
<mwhudson> xnox: is that code all copy-pasted from postinst?
<mwhudson> is there some way to not duplicate it?
<mwhudson> i guess preinst can't depend on stuff
<xnox> mwhudson:  copy-pasted postinst, only some thing tweaked, i.e. no " || true" around db_input towards the end.
<mwhudson> hnngh
<xnox> mwhudson:  i cannot "source /var/lib/dpkg/info/grub2-pc.postinst" because it will, well, execute it.
<mwhudson> can the copy pasting happen at package build time?
<xnox> mwhudson:  shell_vendor_function blah?!
<mwhudson> well it's called preinst.in so clearly some sed is happening to it already
<xnox> mwhudson:  yes, it's vendored into every type of grub-$PLATFORM
<mwhudson> dunno just thinking aloud
<xnox> hence see all the @PACKAGE@
<vorlon> xnox: reviewed with comments
<Odd_Bloke> xnox: Did I say it was just xenial?
<rcj> hggdh: Thank you, we're reproducing and debugging
<Odd_Bloke> xnox: rcj: rick_h: I'm EODing now.  The status of https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1889555 is that we have a PR for xenial open at https://github.com/canonical/cloud-init/pull/514; once that is in a good state, I'll forward-port it to the other releases.  rcj and I have discussed testing, so I also have a plan for what to do with that tomorrow.
<gitbot> canonical issue (Pull request) 514 in cloud-init "debian/cloud-init.postinst: fix NVMe grub install device on upgrade" [Open]
<ubot5> Ubuntu bug 1889555 in cloud-init (Ubuntu Groovy) "cc_grub_dpkg was fixed to support nvme drives, but didn't clear the state of cc_grub_dpkg and didn't rerun it on upgrades" [Undecided,In progress]
<rcj> Odd_Bloke: In azure the root is on /dev/sda and it fails on the reboot.  We'll have more tomorrow.
<Odd_Bloke> rcj: Exciting!
<patviafore> hggdh: thank you for the info, I'm working with rcj on this issue too, and we were able to reproduce the issue
<patviafore> Odd_Bloke: see https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889509/comments/24 for more information about /dev/sda failing the reboot
<ubot5> Ubuntu bug 1889509 in grub2 (Ubuntu) "grub boot error : "symbol 'grub_calloc' not found" [High,Confirmed]
<xnox> Odd_Bloke:  sorry, i'm confused about cloud-init versions then.
<xnox> vorlon:  on efi systems, do we install grub onto /dev/sda or onto /dev/sda14 (the pc-bios partition)?
 * mwhudson squints at that question
<vorlon> xnox: /dev/sda, I believe
<vorlon> because we install to mbr
<vorlon> and IIRC then the pc-bios extra space is there for making sure there's room for stage1.5 in a way that doesn't interfere with gpt
<vorlon> now, what should I make of the fact that grub-pc/install_devices is empty on my eoan-installed EFI system
<vorlon> I guess that means we had an installer bug
<vorlon> xnox: seen my mp review?
<mwhudson> vorlon: do you have grub-pc installed and/or a bios_grub partition?
<mwhudson> oh eoan probably defaulted to mbr partition tables
<sil2100> mwhudson: hey! Thanks!
<sil2100> I'll kick the subiquity images in a moment
<xnox> vorlon:  so that's what i'm thinking about too.
<xnox> vorlon:  do we care about changing this behaviour when booted under efi?
<xnox> vorlon:  imho invalid/empty grub-pc/installed_devices are not that critical if one booted in efi mode.
<xnox> i timed out
<xnox> mwhudson:  vorlon: https://code.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/+merge/388423 & https://code.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/+merge/388432
<xnox> postinst tested and is good
<xnox> preinst not tested, review feedback addressed.
<xnox> oooh let me merge both and upload into a ppa i guess, to test tomorrow.
<mwhudson> sil2100: great
<xnox> sil2100:  https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=debian-installer
-queuebot:#ubuntu-release- Unapproved: fwupd (groovy-proposed/main) [1.4.5-1 => 1.4.5-1] (core)
-queuebot:#ubuntu-release- Unapproved: fwupd (groovy-proposed/main) [1.4.5-1 => 1.4.5-1] (core)
<vorlon> mwhudson: xnox: proposal: inop the grub-pc postinst as an immediate hotfix because grub-pc is not affected by the security vulnerability
-queuebot:#ubuntu-release- Unapproved: fwupd (groovy-proposed/main) [1.4.5-1 => 1.4.5-1] (core)
<mwhudson> vorlon: makes sense i think
<mwhudson> vorlon: a consequence of this
<vorlon> because we can programmatically solve the case that grub is pointing at non-existent disks; we cannot programmatically solve the problem of grub pointing at an existent but wrong disk
<mwhudson> vorlon: is that someone who has grub that is already out of date will "upgrade" to the new grub but in fact not get a new grub
<mwhudson> but well
<mwhudson> so long as we fix this with priority it lets the security fix get out immediately and seems a reasonable compromise
<mwhudson> although i'm not really aware of the ins and outs of the problem
<vorlon> mwhudson: we could inop it only when upgrading from a limited set of versions
<xnox> what does "inop" mean?
<mwhudson> xnox: i assume "make inoperable", i.e. put "exit 0" at the top of it or something
<vorlon> yeah
<xnox> vorlon:  mwhudson: that's buggy.
<mwhudson> vorlon: not sure that really makes any difference
<vorlon> not quite at the top
<xnox> vorlon:  mwhudson: it means new modules on disk, old core in mbr = fail to boot
<vorlon> mwhudson: well if you have N-1 grub, then the new grub gives you nothing you need
<mwhudson> when was the last grub sru
<vorlon> for grub-pc
<xnox> vorlon:  did you mean exit 1 in grub-pc preinst?
<vorlon> xnox: no? new modules are only written to /boot/grub by grub-install
<vorlon> so we avoid calling grub-install from grub-pc.postinst in the security version when upgrading
<xnox> hangon, how come things fail to boot then?
<vorlon> they fail to boot when we /are/ calling grub-install and grub-install fails, after copying the modules
<xnox> grub-install fails to install core to /dev/sda because it doesn't exist, then copies all modules to /boot anyway?
<mwhudson> yeah wait
<vorlon> yes, it copies the modules first
<mwhudson> oh
<vorlon> that's a thing we need to fix
<mwhudson> maybe it shouldn't do that
<vorlon> indeed it shouldn't
<vorlon> but that's grub C code and maybe we shouldn't rush that as a hotfix
<xnox> so postinst should back up /boot first.
<mwhudson> yeah
<xnox> and if things fail, roll it back.
<vorlon> anyway, strace from rcj of a particularly weird failure from grub-install on azure http://paste.ubuntu.com/p/QqYMwZsBbf/
<vorlon> xnox: but this is what we already discussed fixing in grub-install, to make it do things in sensible order?
<mwhudson> so let's call version of grub from last week N
<mwhudson> if someone has version N installed on a bios system, upgrades to N+1, we don't call grub-install -> no consequences, the changes in N+1 make no difference
<mwhudson> if someone has version N-1 installed, they will "upgrade" to N+1 but not actually get the changes from N-1 to N
<mwhudson> do we care?
<xnox> if they have it installed, it will boot.
<xnox> we only care to call grub-install upon "install" really, not upgrades.
<vorlon> untrue
<vorlon> we do care about calling it in the general case on upgrade
<mwhudson> yeah it shouldn't break their system but it will mean they think they have fixes that they do not
<xnox> we only care to call grub-install upon "install" really, not in-series security upgrade of efi.
<vorlon> the latter, yes
<xnox> there are bugs in grub-pc too which are addressed by this security vulnerability
<xnox> but we don't care.
<xnox> cause it allows arbitrary code execution anyway
<vorlon> exactly
<mwhudson> this is totally fine for focal because this is the first sru
<xnox> so we know can kicking down the road is bad, and this time we will really kick it far enough
<xnox> vorlon:  i especially want inop for trusty-esm.
<mwhudson> the last sru to bionic that wasn't strictly efi related was over a year ago
<mwhudson> and xenial about 9 months ago
<xnox> and the weird azure => don't they boot in efi mode anyway?
<vorlon> only gen2 vms
<mwhudson> so yeah, fine with vorlon's plan so long as we do actually do preinsty things soon
<vorlon> 16 SRUs of grub2 in bionic, and none of them do anything interesting to the grub-pc binary bits
<xnox> vorlon:  https://paste.ubuntu.com/p/rHhWzd792x/
<vorlon> xnox: you're calling that from inside a function, shouldn't that be return 0?
<xnox> vorlon:  not a function
<mwhudson> vorlon: no he's not?
<xnox> vorlon:  ignore bogus annotation from git
<vorlon> heh ok
<xnox> i'm down with uploading that.
<xnox> it will unlock us publishing security update on monday
<vorlon> xnox: I don't want us skipping all the rest of the configuration bits, only the grub-install
<xnox> vorlon:  i did one laser eye surgery already!
 * xnox squits harder
 * xnox squints harder
<vorlon> xnox: I can work on the patch + upload
<chrisccoulson> Is the "skip grub-install on upgrade" a temporary thing? (sorry, I've not read through the whole scrollback)
<vorlon> xnox: I would add it to the conditional on line 541 (on the focal branch)
<vorlon> chrisccoulson: I think we will want to leave it in place for all future SRUs because we don't have a reliable way to ensure grub-install on BIOS doesn't go wrong
<chrisccoulson> vorlon, yeah, that seems reasonable
#ubuntu-release 2020-07-31
<xnox> vorlon:  https://paste.ubuntu.com/p/6jHRmjjwZ8/
<xnox> vorlon:  i like 541, but i don't know how far back it exists.
<xnox> and i guess xen doesn't matter as it should just work
<xnox> if we do that, we will need not to do the cloud-init stuff either.
<vorlon> xnox: I want to do https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/commit/?id=5bb3139fbef5b43b07146d3bfc951e4a0c2ff24e
<vorlon> the cloud-init stuff will still matter for dist-upgrades
<vorlon> which are unlikely in the cloud, but supported
<xnox> vorlon:  i am confused.
<xnox> vorlon:  i thought you meant https://paste.ubuntu.com/p/jd5c8p64Pd/
<xnox> vorlon:  why would you want to ever run grub-install of grub-pc on upgrades?
<vorlon> xnox: I want to fix the problem that a security update is borking you.  But as I said, in the general case, we do still /want/ to have the newer grub written to disk on upgrades, but because of the abi break it's prudent to limit it to release upgrades
<xnox> we /want/ but cannot do so.
<xnox> you will brick everyone on dist-upgrade then.
<vorlon> this solves the present problem and kicks the can on the question of handling the failures on release upgrade due to abi changes
<vorlon> xnox: we've already done that in the past
<xnox> because this SRU has changed abi for everyone.
<chrisccoulson> if grub-install is never executed when upgrading grub-pc, is there a risk of other parts that are upgraded going out of sync (eg, grub.cfg depending on new commands)
<vorlon> yes there is
<vorlon> or incompatible filesystem support
<xnox> chrisccoulson:  update-grub is still called, using the new tooling.
<vorlon> if you have old grub, and you do something to upgrade your filesystem, and you don't get new grub, you could also be sunk
<xnox> vorlon:  i'd still want you to make your new case to be elif where i show mine.
<vorlon> xnox: fair
<chrisccoulson> xnox, yeah, that's an issue isn't it - calling update-grub with the new tooling without calling grub-install (not this time around, but maybe in a future update)
<xnox> vorlon:  https://paste.ubuntu.com/p/k2Jqt5yWyg/ or some such. Makes it a lot easier to review / update / backport.
<xnox> vorlon:  a vendor kept on asking if we will continue to support bios.
 * xnox ponders
<xnox> it's unsupportable already
<vorlon> xnox: :P
<vorlon> xnox: https://code.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/+merge/388437
<mwhudson> vorlon: test "$wubi_device" oh boy
<vorlon> mwhudson: ignore ignore ignore
<vorlon> lalalal
<vorlon> a
<sbeattie> haha, saw that too, and cried.
<vorlon> mwhudson: I mean, aside from the fact that I need to fix the syntax ;)
<vorlon> (done)
<mwhudson> vorlon: oh i hadn't got as far as syntax yet :)
<vorlon> mwhudson: yeah that was a mis-edit of the previous attemp
<vorlon> t
<mwhudson> vorlon: approvedz
<mwhudson> vorlon: i presume you have similar changes for bionic, xenial?
<mwhudson> and uh trusty?
<vorlon> mwhudson: will do, with adjusted version numbers; but those are not in git I guess :/
<mwhudson> yes i was assuming you'd remember the version numbers :)
<mwhudson> and hm the branches start with disco it seems?
<xnox> i am confused about "ge" still.
<mwhudson> also bios is bad
<vorlon> xnox: greater than or equal to the version in the release pocket
<mwhudson> also also is there a bug for "pls to be not installing modules until after writing the mbr"
<xnox> which means "any focal version" or "downgrade from groovy"
<xnox> and screw downgrade people
<vorlon> xnox: if you're downgrading, you're presumably on the other side of the ABI change
<vorlon> at least for focal
<xnox> this is safe in-series, ship it.
<vorlon> ok
<vorlon> bdmurray: around?
<Bashing-om> vorlon: xnox: Confirmation: old AMD bios system - apt policy grub-pc >> Installed: 2.02-2ubuntu8.16
<Bashing-om> No issues seen here.
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu26.1 => 2.04-1ubuntu26.2] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (focal-proposed/main) [1.142.3 => 1.142.4] (core)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Focal 20.04.1] has been updated (20200730.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Focal 20.04.1] has been updated (20200730.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Focal 20.04.1] has been updated (20200730.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Focal 20.04.1] has been updated (20200730.1)
<bdmurray> vorlon: yeah
<vorlon> bdmurray: grub2, grub2-signed in focal, I could use an SRU reviewer
<vorlon> to keep me honest
<bdmurray> okay
<bdmurray> honesty is good
<bdmurray> why does the debdiff look so weird?
<vorlon> does it?
<bdmurray> or the changelog specifically
<vorlon> is it diffing against the wrong target?
<vorlon> hmm
<vorlon> I based this on the git branch which I assumed was up-to-date
<vorlon> chrisccoulson: ^^
<vorlon> bdmurray: please reject and I'll reupload
<bdmurray> will do
-queuebot:#ubuntu-release- Unapproved: rejected grub2-signed [source] (focal-proposed) [1.142.4]
-queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (focal-proposed) [2.04-1ubuntu26.2]
<vorlon> xnox: ^^ you synced the focal branch over?  somehow it doesn't contain the debian/2.04-1ubuntu26.1 tag and doesn't match the archive contents
<chrisccoulson> oh, huh, I updated the changelog right before uploading the last version to add all of the CVE references, but didn't commit those to git
<vorlon> ah
<chrisccoulson> vorlon, the tag is missing because the 2.04-1ubuntu26.1 version was already used and tagged for a SRU that wasn't uploaded
<vorlon> well
<vorlon> nuke those tags from orbit
<vorlon> :P
<chrisccoulson> I thought I'd pushed the proper changelog (but just without the tag though)
<mwhudson> NoMoreSourcePackages pls
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu26.1 => 2.04-1ubuntu26.2] (core)
<vorlon> bdmurray: ^^
<chrisccoulson> yeah, that looks better :)
<bdmurray> vorlon: looking
<bdmurray> vorlon: so there will be a better upload coming and this is a stop gap?
<vorlon> bdmurray: there will be further improvements to make grub-pc behave better on upgrades between releases
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (focal-proposed) [2.04-1ubuntu26.2]
<bdmurray> vorlon: where is the signed version? or should I rescue the old one
<bdmurray> yeah that would make sense
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu26.2 => 2.04-1ubuntu26.2] (core)
<vorlon> bdmurray: the old grub2-signed is fine, yeah
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu26.2 => 2.04-1ubuntu26.2] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.16 => 2.02-2ubuntu8.17] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (bionic-proposed/main) [1.93.18 => 1.93.19] (core)
-queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (bionic-proposed) [2.02-2ubuntu8.17]
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.16 => 2.02-2ubuntu8.17] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.26 => 2.02~beta2-36ubuntu3.27] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (xenial-proposed/main) [1.66.26 => 1.66.27] (core)
-queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (bionic-proposed) [2.02-2ubuntu8.17]
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.16 => 2.02-2ubuntu8.17] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (bionic-proposed) [2.02-2ubuntu8.17]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (focal-proposed) [2.04-1ubuntu26.2]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (focal-proposed) [2.04-1ubuntu26.2]
-queuebot:#ubuntu-release- Unapproved: rejected grub2-signed [source] (bionic-proposed) [1.93.19]
-queuebot:#ubuntu-release- Unapproved: grub2-signed (bionic-proposed/main) [1.93.18 => 1.93.19] (core)
-queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.27]
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.26 => 2.02~beta2-36ubuntu3.27] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (bionic-proposed) [1.93.19]
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.17 => 2.02-2ubuntu8.17] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.27]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (xenial-proposed) [1.66.27]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (bionic-proposed) [2.02-2ubuntu8.17]
<vorlon> mwhudson: still around at all?
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.27 => 2.02~beta2-36ubuntu3.27] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.27 => 2.02~beta2-36ubuntu3.27] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.17 => 2.02-2ubuntu8.17] (core)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-5.6 [amd64] (focal-proposed) [5.6.0-1021.21]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (bionic-proposed) [2.02-2ubuntu8.17]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (xenial-proposed) [2.02~beta2-36ubuntu3.27]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (xenial-proposed) [2.02~beta2-36ubuntu3.27]
-queuebot:#ubuntu-release- Unapproved: rejected mutter [source] (focal-proposed) [3.36.4-0ubuntu0.20.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (bionic-proposed) [20101020ubuntu543.16]
<LocutusOfBorg> can anybody please accept s390-tools from unapproved? needed for json-c transition
<LocutusOfBorg> also, please kick ntopng out from release pocket? its bd uninstallable due to ndpi
<LocutusOfBorg> out from debian testing
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-440-server [i386] (bionic-proposed) [440.95.01-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New: accepted haskell-hgettext [amd64] (groovy-proposed) [0.1.31.0-7]
-queuebot:#ubuntu-release- New: accepted haskell-hgettext [armhf] (groovy-proposed) [0.1.31.0-7]
-queuebot:#ubuntu-release- New: accepted haskell-hgettext [riscv64] (groovy-proposed) [0.1.31.0-7]
-queuebot:#ubuntu-release- New: accepted haskell-hgettext [arm64] (groovy-proposed) [0.1.31.0-7]
-queuebot:#ubuntu-release- New: accepted haskell-hgettext [s390x] (groovy-proposed) [0.1.31.0-7]
-queuebot:#ubuntu-release- New: accepted haskell-hgettext [ppc64el] (groovy-proposed) [0.1.31.0-7]
<LocutusOfBorg> vorlon, with ntopng kicked out from release (we should keep it in proposed, so it builds once ndpi is fixed in debian and syncs), and the s390-tools accept from unapproved, json-c should be fine to go
<xnox> mwhudson:  sil2100: new subiquity image regressed on s390x https://bugs.launchpad.net/subiquity/+bug/1889749
<ubot5> Ubuntu bug 1889749 in Ubuntu on IBM z Systems "No longer able to do zFCP/SCSI multipath installations on focal image '20200730.1'" [Critical,New]
<xnox> Laney:  https://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html is out of date, last generate yesterday?
<xnox> sil2100:  grub2-signed & grub2 are ready for release to updates in xenial, bionic, focal
-queuebot:#ubuntu-release- New source: agda-stdlib (groovy-proposed/primary) [1.3-1~build1]
-queuebot:#ubuntu-release- Unapproved: debian-installer (bionic-proposed/main) [20101020ubuntu543.16 => 20101020ubuntu543.17] (core)
<xnox> sil2100: bdmurray: vorlon: fix for FTBFS of s390x d-i in bionic uploaded ^
<Odd_Bloke> xnox: vorlon: I saw mention of potentially not needing the cloud-init fix; should I continue working on it, or do we categorically no longer need it?
<xnox> Odd_Bloke: we absolutely need it now.
<xnox> Odd_Bloke: grub is only a cludge, and will delay breaking machines until after release upgrade.
<xnox> Odd_Bloke: cloud init fix can unbreak some clouds to correctly upgrade to new grub.
<xnox> and not fail release upgrade.
-queuebot:#ubuntu-release- Unapproved: accepted bcache-tools [source] (focal-proposed) [1.0.8-3ubuntu0.1]
<xnox> Odd_Bloke: however the grub cludge makes cloud-init fix not time sensitive, as much.
<xnox> We are choosing to skip grub-install for security update, but will call it on release upgrade.
<Odd_Bloke> xnox: Thanks!
-queuebot:#ubuntu-release- Unapproved: accepted smokeping [source] (focal-proposed) [2.7.3-2ubuntu20.04.1]
<Odd_Bloke> xnox: My next Q: does that affect whether or not we need to release a cloud-init fix to -security?
<xnox> Odd_Bloke: we are choosing to not call grub-install in -security, thus cloud-init can simply go to -updates.
<xnox> (note this is all about grub-pc, the efi signed stuff is upgraded, as that's the point of this security update)
-queuebot:#ubuntu-release- Unapproved: accepted network-manager-applet [source] (focal-proposed) [1.8.24-1ubuntu3]
<sbeattie> xnox: FYI, there will at least need to be a respin of grub2 before it can go into security, as the ones in proposed were built with -updates enabled, and so at least a no-change rebuild will be needed for -security.
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (focal-proposed) [2.20.11-0ubuntu27.5]
<Odd_Bloke> xnox: "we are choosing to not call grub-install in -security" <-- as a rule going forward, or just for this grub upload?  If the latter, then folks running -security will run into this next time around (or on release upgrade?), no?
<xnox> vor
<xnox> vorlon: why did you direct upload instead of copy?! :-)
<xnox> sbeattie: let me prepare that then.
<xnox> Odd_Bloke: until we fix grub-install to at least rollback and not fail to install core; yet update to incompatible modules in /boot.
<xnox> Od
<xnox> Odd_Bloke: as we break machines, intentionally, and know it, and carry on.
<Odd_Bloke> xnox: -security-only users who would be fixed by the cloud-init upload still wouldn't get new grubs because their install_devices will still be incorrect.  Or will upgrades of grub fail in a way that's very obvious (and should therefore prompt users to fix install_devices themselves)?
<xnox> Odd_Bloke:  once cloud-init fix is out, we can order to have new cloud-init configured first on release-upgrades.
<xnox> Odd_Bloke: or, when we fix up grub-install => things will fail, but ensure that system remains bootable & rebootable.
<xnox> Odd_Bloke:  when we have better/proper grub-install we will push it to security too, i think.
<Odd_Bloke> xnox: Right, it sounds like we will ensure the system remains bootable & rebootable, but with the cloud-init fix we could do better for some systems (in that they would both remain (re)bootable, but also get new grub updates).
<Odd_Bloke> (I'm not asserting that the cloud-init fix must go to -security, just making sure I understand what, if any, gap we'll be leaving if it doesn't.)
<xnox> yeap yeap yeap
<ahasenack> hello ubuntu-archive, are you fine with also promoting adcli and realmd to main in focal? Their MIRs were approved (and done) for groovy. The versions in focal are identical. https://code.launchpad.net/~ahasenack/ubuntu-seeds/+git/ubuntu-seeds/+merge/388428
<ahasenack> maybe now just before the 20.04.1 is not the best time (or is it?)
<paride> xnox, so new trip to candidate for subiquity?
<xnox> paride: yeah, pushing buttons to make a new edge build.
<xnox> once jfh tests it from edge, will promote it to release.
<xnox> paride:  i guess we can trigger edge jenkins jobs too, once i publish it to edge?
<paride> xnox, yes you can trigger the -smoke-edge jobs
<paride> but  it just tests the default install case
<xnox> it's ok.
<xnox> they are currently building.
<ahasenack> ubuntu-archive, hi, can you please remove sssd from groovy-proposed that I just synced? I wanted to sync ldb and samba first, and sssd later
<ahasenack> or is it too late
<ahasenack> it's still building for all but s390x: https://launchpad.net/ubuntu/+source/sssd/2.3.1-1
 * ahasenack tries cancelling the other builds
<paride> sil2100, do you think we can add a 18.04.5 milestone to the ISO tracker?
<paride> or is it still too early?
<paride> the 20200731.1 bionic images look good
<paride> well we probably want the new subiquity there too, even if there's no s390x
<paride> but the d-i images should be fine
<sil2100> paride: I think it's too early, wanted to add it once we start building candidates
<paride> ack
<bdmurray> sil2100: I have a "dumb" fix for bug 1889449 but I'm also working on a better one. Do you have a timeline in mind that I should be done by?
<ubot5> bug 1889449 in ubuntu-release-upgrader (Ubuntu) "18.04 to 20.04.1 upgrade on raspberry pi removes too many kernel meta packages" [Undecided,New] https://launchpad.net/bugs/1889449
<xnox> paride: new subiquity in edge, please kick edge jobs off.
<paride> xnox, done already, all passed on bionic amd64 and focal amd64 ppc64el s390x
<paride> I checked the snap build id to make sure the jobs ran using the edge snap
<sil2100> paride: thanks for the testing!
<sil2100> bdmurray: I guess the deadline would be next week when we release .1 and enable upgrades, but I guess the earlier the better
<sil2100> Let me take a look at what you proposed
<sil2100> bdmurray: I don't know the mechanics of the blacklist_removal.cfg - that only affects release upgrades?
<bdmurray> sil2100: here's my dumb fix https://pastebin.ubuntu.com/p/sskcZsQ2Kp/
<bdmurray> sil2100: yes, removal_blacklist.cfg is a part of the dist-upgrader tarball and is only used during the dist upgrade process
<bdmurray> and here's the better fix https://pastebin.ubuntu.com/p/GxF2QHhrJT/
<bdmurray> It didn't do what I wanted yesterday but I was missing the third change there
<bdmurray> I'm gonna test the better fix shortly
<xnox> paride: thinking to release to stable. But did not hear from Frank yet
<xnox> ok jfh says it's good
<xnox> sil2100:  new subiquity published with regression fix, so live-server could be respun.
<xnox> (or well, ready to respin, whenever you want)
<paride> sil2100, if you do, I
<paride> sil2100, if you do, let me know and I'll submit results before EOD
<paride> xnox, can we tell which subiquity went into an image from the image build logs?
<sil2100> Yay, I'll have to respin everything now!
<sil2100> People will be really happy
<sil2100> bdmurray: hm, the 'better' fix looks okay from the look of it, though I still wonder why is the new metapackage marked for autoremoval anyway
<xnox> paride:  yes, if you click on the livefs build, and then click on build log of that, one can see subiquity revision in the log.
<xnox> paride:  we really should fix the manifests to include subiquity revision id in the manifest.
<Odd_Bloke> rcj: xnox: vorlon: One thing I don't think I've fully understood: is the intent to never grub-install on upgrade of grub-pc systems again, or is that a stopgap while we implement reliable grub-install on such systems?
<xnox> Odd_Bloke:  it's a stop gap.
<xnox> Odd_Bloke:  intent is to call grub-install, and rollback when it is unsuccessful.
<Odd_Bloke> xnox: OK, cool, thanks!
<vorlon> xnox, Odd_Bloke: I disagree, actually.  The fact that we can never reliably know on BIOS systems that the disk we've installed the bootloader to is the actual boot disk means the ABI break is always a foot-gun, and I think we should avoid applying this to users' systems from grub-pc for the lifetime of these releases and only deal with it during release upgrades
<vorlon> the other changes to make grub-install more resilient are still relevant, but I don't think it's an either-or
<Odd_Bloke> vorlon: "always a foot-gun" because we could "successfully" install to /boot and /dev/sda and then the system boots from /dev/sdb and hits the incompatibility anyway, you mean?
<vorlon> Odd_Bloke: exactly
<xnox> Odd_Bloke:  there is no protocol to tell us off what we booted, and where things should be.
<xnox> Odd_Bloke:  another example is degraded raid, yes installing on sda sdb sdc is correct, and yes sdc is missing, and sdb has incompatible core, and yes all of them should be updated. etc.
<sbeattie> vorlon: that means never being able to SRU a bugfix for bios users again in these releases.
<sbeattie> (which may be an okay tradeoff)
<xnox> sbeattie:  most of our bugfixes are around generating grub.cfg though.
<sbeattie> okay. just want to make sure the implications are understood.
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200731)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200731)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200731)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Focal 20.04.1] has been updated (20200731)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Focal 20.04.1] has been updated (20200731)
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Focal 20.04.1] has been updated (20200731)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Focal 20.04.1] has been updated (20200731)
<Odd_Bloke> If we did hit a circumstance where we did need to SRU a bugfix for bios users that did require a `grub-install` then we could presumably handle "undisabling" it at that time too?
<Odd_Bloke> (Feasibly such a bugfix might only apply to a subset of bios systems, so we could conditionally `grub-install` or whatever; we will know better once confronted with such an issue.)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Focal 20.04.1] has been updated (20200731)
-queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Focal 20.04.1] has been updated (20200731)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Focal 20.04.1] has been updated (20200731)
<Odd_Bloke> vorlon: So should I drop https://github.com/canonical/cloud-init/pull/514/files#diff-0a6a3bac6b74050d52c36391345e3838R316 from the cloud-init postinst I'm working on?
<gitbot> canonical issue (Pull request) 514 in cloud-init "debian/cloud-init.postinst: fix NVMe grub install device on upgrade" [Open]
<Odd_Bloke> Or should I still call `grub-install` because it will be a noop when appropriate?
-queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Focal 20.04.1] has been updated (20200731)
-queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Focal 20.04.1] has been updated (20200731)
-queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Focal 20.04.1] has been updated (20200731)
-queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Focal 20.04.1] has been updated (20200731)
-queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Focal 20.04.1] has been updated (20200731)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Focal 20.04.1] has been updated (20200731)
-queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Focal 20.04.1] has been updated (20200731)
-queuebot:#ubuntu-release- New binary: pygame-sdl2 [amd64] (groovy-proposed/universe) [7.3.5-1] (no packageset)
<sil2100> vorlon: hey! So there's that very old shim-signed in bionic-proposed, which is being pulled in by ubiquity when I try to update the sources
-queuebot:#ubuntu-release- New binary: pygame-sdl2 [s390x] (groovy-proposed/universe) [7.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pygame-sdl2 [ppc64el] (groovy-proposed/universe) [7.3.5-1] (no packageset)
<vorlon> sil2100: that one is effectively verification-failed; there is a fix in the unapproved queue. are you ok with me accepting the new one, or should I just delete the old one?
<vorlon> Odd_Bloke: how sure can you be that grub-install is called for the right target?
<vorlon> sbeattie: yeah, I understood that implication; we could revisit the question if it came up that we did need an SRU to fix the grub-pc binary bits, but aside from a couple of long-past xenial SRUs, we don't have a history of doing this
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Focal 20.04.1] has been updated (20200731)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Focal 20.04.1] has been updated (20200731)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Focal 20.04.1] has been updated (20200731)
-queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Focal 20.04.1] has been updated (20200731)
<xnox> vorlon:  even if sure of target, it may not be successful as we see in the other cloud.
<Odd_Bloke> vorlon: This is basically running the "determine the correct install_device" logic that cloud-init runs at first boot, only on systems with an NVMe disk (to target AWS Nitro instances), and only if the current value is /dev/sda (cloud-init's previous default).
-queuebot:#ubuntu-release- New binary: pygame-sdl2 [armhf] (groovy-proposed/universe) [7.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pygame-sdl2 [arm64] (groovy-proposed/universe) [7.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pygame-sdl2 [riscv64] (groovy-proposed/universe) [7.3.5-1] (no packageset)
<sforshee> vorlon: could you approve the linux signing tarballs for groovy? Not sure if there's anyone else still around today who is willing to touch those
<Odd_Bloke> vorlon: Honestly, I am wondering if we need to do anything in cloud-init for existing instances, if we never plan to rely on what they have set in grub-pc/install_devices.
<xnox> Odd_Bloke:  wait "never plan to rely on what they have set in grub-pc/install_devices" is not true. we absolutely rely on that to be correct during do-release-upgrade and will attempt installing grub-pc into the devices listed there.
<xnox> Odd_Bloke:  so we do want those corrected for nitro instances.
<xnox> Odd_Bloke:  but you may choose to skip calling grub-install on them, when correcting that.
<Odd_Bloke> xnox: And we shouldn't/won't just be prompting people to select the correct install device at do-release-upgrade time?
<Odd_Bloke> I guess where I'm at is: either we trust this determination (and therefore can grub-install immediately) or we don't (and therefore shouldn't use it for do-release-upgrade either).
<Odd_Bloke> And the correct value could have changed by the time a `do-release-upgrade` occurs.
<Odd_Bloke> So if we won't need it until then, it seems to me that it would make most sense to wait until then to determine it.
<xnox> Odd_Bloke:  we know that sda on nitro nvme instances is wrong, that must be corrected.
<xnox> Odd_Bloke:  such that user is not asked about it.
<paride> sil2100, submitted all the results for focal server 20200731
<Odd_Bloke> xnox: vorlon: I'm a couple of hours away from EOW, and I'm out on Monday: can the cloud-init change wait until mid-next-week, or should I be looking to hand it off to someone to keep pushing it on Monday?  (My feeling currently is that it can wait, given the grub change making its way out.)
<vorlon> Odd_Bloke: I believe the grub change that's been uploaded is a complete mitigation for the problems we've seen
<vorlon> sforshee: I don't see any linux signing tarballs pending for groovy?
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (groovy-proposed) [1.4.5-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (groovy-proposed) [1.4.5-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (groovy-proposed) [1.4.5-1]
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [s390x] (groovy-proposed) [2.12.0-0ubuntu6]
<sforshee> vorlon: someone else must have approved them
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (groovy-proposed/main) [5.8.0-12.13] (core, kernel)
<vorlon> sforshee: well I don't see any mentioned by the bot in the past day either
<sforshee> huh, that's odd
 * cjwatson wonders if Foundations are ever planning to send any of this grub maintainer script hackery to Debian so that it can at least be discussed more widely
<cjwatson> or just carry on diverging ever further in Ubuntu
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (groovy-proposed/main) [5.8.0-12.13] (core, kernel)
<bryyce> there are 4 php-horde packages needing blacklisted, could an ubuntu-archive admin merge https://bazaar.launchpad.net/~bryce/+junk/sync-blacklist-php-horde/revision/772 for me?
<bryyce> (LP: #1880776)
<ubot5> Launchpad bug 1880776 in php-horde (Ubuntu) "Please blacklist and remove php-horde and php-horde-* from groovy (and future releases)" [Undecided,New] https://launchpad.net/bugs/1880776
-queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu7.29 => 1:2.11+dfsg-1ubuntu7.30] (ubuntu-server, virt)
<vorlon> cjwatson: that would be... ideal, yes
<vorlon> bryyce: I was unclear on the rationale for why we blacklisted php-horde again given that the packages that were coming from Debian are maintained again.  Is this really intended to be a permanent blacklist? cpaelzer's comment suggests it might not be
<vorlon> bryyce: anyway, merged in keeping with the existing ones
<vorlon> why is retry-autopkgtest-regressions trying (and failing) to parse yaml related to a snap-triggered test?
<vorlon> (when run with -s bionic)
<bryyce> vorlon, thanks for merging it, sorry about the lack of clarity, yes it was intended to be a permanent block
<vorlon> bryyce: what's the rationale of making it permanent, if it's maintained again in Debian?
<bryyce> vorlon, rationale is that it has a small userbase (per Josh's review), and it is comprised of a very large number of packages with widely varying upstream maintenance support, which has resulted in lots of effort required on our end to resolve migration conflicts
<vorlon> bryyce: ok
<vorlon> thanks :)
<bryyce> the rationale's also documented on the bug report for posterity
<vorlon> rbalint_: the recent changes from lp:~rbalint/ubuntu-archive-tools/retry-intermittent appear to cause retry-autopkgtest-regressions to fail when there are snap-triggered autopkgtests running
-queuebot:#ubuntu-release- New binary: gvm-libs [s390x] (groovy-proposed/universe) [11.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gvm-libs [arm64] (groovy-proposed/universe) [11.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gvm-libs [ppc64el] (groovy-proposed/universe) [11.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gvm-libs [armhf] (groovy-proposed/universe) [11.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gvm-libs [riscv64] (groovy-proposed/universe) [11.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gvm-libs [amd64] (groovy-proposed/universe) [11.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ospd [amd64] (groovy-proposed/universe) [2.0.1-1] (no packageset)
#ubuntu-release 2020-08-01
-queuebot:#ubuntu-release- New: accepted gvm-libs [amd64] (groovy-proposed) [11.0.1-1]
-queuebot:#ubuntu-release- New: accepted gvm-libs [armhf] (groovy-proposed) [11.0.1-1]
-queuebot:#ubuntu-release- New: accepted gvm-libs [riscv64] (groovy-proposed) [11.0.1-1]
-queuebot:#ubuntu-release- New: accepted gvm-libs [arm64] (groovy-proposed) [11.0.1-1]
-queuebot:#ubuntu-release- New: accepted ospd [amd64] (groovy-proposed) [2.0.1-1]
-queuebot:#ubuntu-release- New: accepted gvm-libs [ppc64el] (groovy-proposed) [11.0.1-1]
-queuebot:#ubuntu-release- New: accepted gvm-libs [s390x] (groovy-proposed) [11.0.1-1]
-queuebot:#ubuntu-release- New: accepted pygame-sdl2 [arm64] (groovy-proposed) [7.3.5-1]
-queuebot:#ubuntu-release- New: accepted pygame-sdl2 [ppc64el] (groovy-proposed) [7.3.5-1]
-queuebot:#ubuntu-release- New: accepted pygame-sdl2 [s390x] (groovy-proposed) [7.3.5-1]
-queuebot:#ubuntu-release- New: accepted pygame-sdl2 [amd64] (groovy-proposed) [7.3.5-1]
-queuebot:#ubuntu-release- New: accepted pygame-sdl2 [riscv64] (groovy-proposed) [7.3.5-1]
-queuebot:#ubuntu-release- New: accepted pygame-sdl2 [armhf] (groovy-proposed) [7.3.5-1]
-queuebot:#ubuntu-release- New binary: gvmd [ppc64el] (groovy-proposed/universe) [9.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gvmd [s390x] (groovy-proposed/universe) [9.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ospd-openvas [amd64] (groovy-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gvmd [arm64] (groovy-proposed/universe) [9.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gvmd [armhf] (groovy-proposed/universe) [9.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gvmd [amd64] (groovy-proposed/universe) [9.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gvmd [riscv64] (groovy-proposed/universe) [9.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gvmd [amd64] (groovy-proposed) [9.0.1-1]
-queuebot:#ubuntu-release- New: accepted gvmd [armhf] (groovy-proposed) [9.0.1-1]
-queuebot:#ubuntu-release- New: accepted gvmd [riscv64] (groovy-proposed) [9.0.1-1]
-queuebot:#ubuntu-release- New: accepted gvmd [arm64] (groovy-proposed) [9.0.1-1]
-queuebot:#ubuntu-release- New: accepted ospd-openvas [amd64] (groovy-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted gvmd [ppc64el] (groovy-proposed) [9.0.1-1]
-queuebot:#ubuntu-release- New: accepted gvmd [s390x] (groovy-proposed) [9.0.1-1]
<LocutusOfBorg> please accept agda-stdlib from new queue, it fixes agda uninstallability (its something in sync with Debian)
-queuebot:#ubuntu-release- New sync: agda-stdlib (groovy-proposed/primary) [1.3-1]
<LocutusOfBorg> the autosync script didn't work because I had uploaded an 1.3-1~build1 in Ubuntu, to let agda migrate before autosync
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (groovy-proposed) [5.8.0-12.13]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (groovy-proposed) [5.8.0-12.13]
<LocutusOfBorg> is it possible to drop orthanc-dicomweb on riscv64 please? it can't build due to missing new nodejs requirements
<LocutusOfBorg> ubuntu-archive ^^
<LocutusOfBorg> xnox, ^^ since you are driving boost transition
<enyc> Hrrm will start here (pleose point me where else which bug or xorg or devel channel to go to...)  r.e. 20.04 xorg corruption fun
<enyc> On older AMD64 with ATI "RS480" onboard graphics,  is somehow broken by 20.04 (or mint20), fine on 18.04 and debian-10-buster.  Get all this Corrupted display (mouse cursor ok).  LOGIN screen fine.   Cinnamon and XFCE exactly the same.
<enyc> Have installed old linux-firmware, old kernel, old x.org package set (including video drivers, 'radeon' et. al),  removed mesa accell,  tried all those....  There seems to be something in some OTHER Ubuntu 20.04  changes....
<enyc> There ar emany "screen corruption" in 20.04  sort of vague posts / reports about,  just wondered if it was a known problem-area that not narrowed-down!
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [5.3.0-65.59] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1067.72] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [5.3.0-65.59]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1067.72]
<vorlon> locutusofborg: orthanc-dicomweb/riscv64 removed, thanks
<locutusofborg> vorlon, please accept agda-stdlib from new queue?
<locutusofborg> and also, what about pushing out from release ntopng ? its the last rebuild blocker for json-c
<locutusofborg> (we have some autopkgtest sadness and one entanglement)
-queuebot:#ubuntu-release- New binary: ace [s390x] (groovy-proposed/universe) [6.5.10+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ace [ppc64el] (groovy-proposed/universe) [6.5.10+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ace [amd64] (groovy-proposed/universe) [6.5.10+dfsg-2] (no packageset)
<vorlon> locutusofborg: well, you wouldn't need to ask if you had just let it be autosynced... anyway, agda-stdlib accepted now
-queuebot:#ubuntu-release- New: rejected agda-stdlib [source] (groovy-proposed) [1.3-1~build1]
-queuebot:#ubuntu-release- New: accepted agda-stdlib [sync] (groovy-proposed) [1.3-1]
-queuebot:#ubuntu-release- New binary: agda-stdlib [amd64] (groovy-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ace [arm64] (groovy-proposed/universe) [6.5.10+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ace [armhf] (groovy-proposed/universe) [6.5.10+dfsg-2] (no packageset)
#ubuntu-release 2020-08-02
-queuebot:#ubuntu-release- New binary: ace [riscv64] (groovy-proposed/universe) [6.5.10+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: agda-stdlib [amd64] (groovy-proposed/universe) [1.3-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted ace [arm64] (groovy-proposed) [6.5.10+dfsg-2]
-queuebot:#ubuntu-release- New: accepted ace [riscv64] (groovy-proposed) [6.5.10+dfsg-2]
-queuebot:#ubuntu-release- New: accepted agda-stdlib [amd64] (groovy-proposed) [1.3-2]
-queuebot:#ubuntu-release- New: accepted ace [armhf] (groovy-proposed) [6.5.10+dfsg-2]
-queuebot:#ubuntu-release- New: accepted agda-stdlib [amd64] (groovy-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted ace [amd64] (groovy-proposed) [6.5.10+dfsg-2]
-queuebot:#ubuntu-release- New: accepted ace [s390x] (groovy-proposed) [6.5.10+dfsg-2]
-queuebot:#ubuntu-release- New: accepted ace [ppc64el] (groovy-proposed) [6.5.10+dfsg-2]
 * enyc meows, and looks back... hrm nobody pointed me to right channel
 * enyc asked in #ubuntu-bugs about the general screen-corruption not able to track down to package yet........
