#ubuntu-release 2010-07-05
<lamont> how much pleading do I need to do to have bind9 synced from debian?
<cjwatson> lamont: no pleading, just use requestsync
<lamont> ta
<lamont>         mailserver_host = os.getenv('UBUSMTP') or os.getenv('DEBSMTP') or 'fiordland.ubuntu.com'
<lamont> that makes me cry
<lamont> because apparently looking up the MX host is hard?
<ScottK> lamont: Patches welcom.
<ScottK> ...e.
<elmo> ScottK: or, you know, we could just drop fiordland.ubuntu.com from DNS ;-P
<ScottK> That would work too.  Since I've got severl local MTAs availalbe, it's not a real question for me.
<lamont> ScottK: who is the recipient on the email?
<lamont> because there's no reason it couldn't just look up the MX list and use it...
<ScottK> Agreed.
#ubuntu-release 2010-07-08
<ScottK> cjwatson or slangasek: Would one of you please arrange to kill the kubuntu-netbook ISO build on i386 and to switch the armel kubuntu-netbook build to kubuntu (desktop)?  It seems we've successfully combined the images into one now.
<cjwatson> ScottK: which armel subarchitecture(s)?
<cjwatson> ScottK: and should it be "preinstalled" rather than "live", as ubuntu-netbook now is?
<ScottK> cjwatson: Whichever ones are being built.  I didn't follow all the Maverick changes on sub-archs.
<ScottK> cjwatson: I've no idea on preinstalled.
<ScottK> "Like ubuntu-netbook" sounds reasonable though.
<cjwatson> mkay, I'll just make them match up
<ScottK> Thanks.
<ScottK> Are there ISO tracker changes needed or is it automagic based on what images get built?
<cjwatson> I think the tracker will need to be changed, but I don't know how to do that
<cjwatson> stgraber: ^- ?
<ScottK> Thanks.
<cjwatson> cdimage change made and deployed
<cjwatson> I may need to clean up some stale images at some point
<ScottK> cjwatson: Thanks.  That should ease testing next time around.
<slangasek> more massaging may be needed to get a preinstalled kubuntu-netbook image to build correctly on armel
<cjwatson> yeah, I'm not sure about that, ogra would probably know better?
 * slangasek nods
 * ScottK is all ears.
<ScottK> KDE is currently broken on armel anyway, so it's not urgent.
 * ScottK gives NCommander a kick in the shins.
<NCommander> what the heck did I do this week :-P
 * NCommander already got dumped in a lake by Riddell 
<NCommander> cjwatson: it should "just work", just add the crontables to build the kubuntu-netbook image with -f ext2, and then use cron.port-dailys_preinstalled
<cjwatson> that's what I did except -f ext3 to match ubuntu-netbook
<ScottK> cjwatson: Except we want desktop, not netbook for Kubuntu.
<NCommander> ScottK: same thing in pratice
<ScottK> that's the goal.
<cjwatson> uh, I missed that bit
<cjwatson> so you want armel omap/omap4 preinstalled kubuntu-desktop?
<ScottK> cjwatson: Yes.  We're doing away with the netbook image entirely.  Netbook/Desktop will get autoselected at first run based on screen size.
<cjwatson> mkay, done
<ScottK> cjwatson: Thanks.
<ScottK> lamont: Of course, just a few hours after I hit retry, there was another upload of qt4-x11, so it might make sense to shoot https://launchpad.net/ubuntu/+source/qt4-x11/4:4.7.0~beta1+git20100706-0ubuntu1/+build/1856835 in the head to make room for something more useful.
<lamont> ScottK: which builder, if you know?
<lamont> meh. /me looks
<ScottK> lamont: cushaw
<lamont> smacked
<ScottK> Thanks.
<ogra> i think kubuntu-netbook shoudl just work as preinstalled image, you just need to copy the crontab line ... the prob is that one single build takes 2.5h
<ScottK> ogra: Won't take that long now since it will fail.
<ogra> well, then we should wait until NCommander is done with fixing kde :)
<ogra> i'll tell him to ping me for a testbuild once its ready, if that succeeds i'll add a cron entry
<ScottK> NCommander: That'll be done tomorrow, right?
<ScottK> ;-)
<ogra> lol
<ogra> i'm in a call with him in 10 min, i'll ask him
<ScottK> It's already a great relief that qt4-x11 died on armel because lamont killed it and he doesn't have to fix that too.
#ubuntu-release 2010-07-09
<NCommander> ScottK: I know why bindings are broken, I just am not sure how to proper fix
<mvo> slangasek: thanks a bunch for the aptitude merge!
<mvo> slangasek: it appears you prepared the upload in bzr but did not upload just yet, correct? is it because of the missing google-mock? or is there another reason?
<slangasek> mvo: I'm still preparing it, google-mock is the last outstanding issue, yes
<slangasek> mvo: should be finished today and uploaded
<mvo> slangasek: many thanks. I did request a sync for gtest so google-mock should build now
<slangasek> but it's still in universe; do you plan to MIR?
<slangasek> I was going to ignore that for right now in order to get it built
<mvo> google-mock has build on i386 already, nice
<mvo> I can do the MIRs early next week, that should be trivial as its just the testing stuff (gtest and google-mock AFAICS)
<slangasek> mvo: aptitude uploaded; happy to revert the latest google-mock-disabling change once the MIR is approved
<mvo> slangasek: sweet, thanks
#ubuntu-release 2010-07-11
<stgraber> ScottK, cjwatson: I would need to check if I now have access to the new host of the iso tracker. I've been requesting access for a while now but with no news so far.
<stgraber> elmo, lamont: Where is the ISO tracker now ? I just looked on quandong and the DB seems to be the one we had two days before Lucid's release so I'm guessing it's not back on that box yet.
#ubuntu-release 2011-07-04
<jibel> cjwatson, no installable alternate and server images today. bug 805342
<ubot4> Launchpad bug 805342 in debian-installer (Ubuntu Oneiric) (and 1 other project) "libc6 failed to install on d-i based images with error 'A copy of the C library was found in an unexpected directory '/lib/x86_64-linux-gnu/libc-2.13.so' (affects: 1) (heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/805342
<cjwatson> ok
<charlie-tca> Xubuntu desktop images are failing to build, error in messages (no error log for two days):
<charlie-tca> W: Failure trying to run: chroot /build/chroot dpkg --force-depends --install /var/cache/apt/archives/libc6_2.13-8ubuntu2_amd64.deb
<charlie-tca> also, Xubuntu 64bit alternate shows no updates to the image since July 1, and it should. It shows the image being built everyday, but no updates to it. No errors in log.
<ogra_> charlie-tca, i think cjwatson uploaded a fix for that today
<ogra_> (see the libc changelog)
<charlie-tca> Okay, that works. Why am I not getting any changes on the 64bit alternate, though?
<ogra_> seems it was a general breakage between libc and debootstrap
<cjwatson> charlie-tca: can you give me a particular package and version that should have been updated since July 1?
<cjwatson> and yes, I fixed eglibc
<cjwatson> note I'm on holiday tomorrow, so probably want to get all this kind of CD build system stuff fixed today for alpha 2 :-)
<charlie-tca> I will have to go looking. It just seems wrong that i386 updates everyday, but 64bit has not changed at all
<jibel> cjwatson, if you're on holiday tomorrow could you respin alternate with the new eglibc so I can test it today ?
<cjwatson> charlie-tca: well, uh, as far as I can tell that is simply not true
<seb128> speaking of new eglibc bug #805154 seems due to it
<ubot4> seb128: Bug 805154 on http://launchpad.net/bugs/805154 is private
<seb128> "gdm-simple-slave crashed with SIGSEGV in _nss_compat_getpwnam_r() "
<cjwatson> seb128: now that part is not my problem, try doko perhaps
<cjwatson> jibel: ok
<jibel> thanks
<cjwatson> charlie-tca: changes from 20110703 to 20110704 on amd64:
<cjwatson> +/pool/main/a/app-install-data-ubuntu/app-install-data_0.11.10.1_all.deb
<cjwatson> +/pool/main/o/openbsd-inetd/openbsd-inetd_0.20091229-1ubuntu1_amd64.deb
<cjwatson> +/pool/main/p/pppoeconf/pppoeconf_1.20ubuntu1_all.deb
<seb128> cjwatson, heh, I didn't mention your name there nor suggested it was yours ;-)
<cjwatson> +/pool/main/s/software-center/software-center_4.1.7_all.deb
<seb128> doko, ^
<cjwatson> (corresponding - lines for older versions too, deleted for brevity)
<cjwatson> charlie-tca: this exactly matches i386
<charlie-tca> I am sorry. My last zsync did update it
<seb128> ups, I though that was #ubuntu-devel sorry about that
<doko> seb128: why is it private? how can you reproduce it?
<micahg> when is alpha 2 freeze?
<micahg> oh, nvm, found it
#ubuntu-release 2011-07-05
<pitti> so, time for milestone freeze
<stgraber> wow, Edubuntu built today! /me starts downloading
<pitti> stgraber: it already built on Saturday ;)
<stgraber> ah right, I started downloading it at the hotel before leaving. Wanted to continue at the airport but there wasn't free wifi and then Sunday's build failed :)
<jibel> can I start publishing images to the tracker ?
<pitti> jibel: not the ubuntus yet, please; I need to rebuild them for the new lightdm
<pitti> bug 802271 is a sucker for testing
<ubot4> Launchpad bug 802271 in lightdm (Ubuntu Oneiric) (and 1 other project) "Characters sent to tty1 (affects: 9) (dups: 2) (heat: 60)" [Critical,Triaged] https://launchpad.net/bugs/802271
<pitti> jibel: supposedly fixed with the latest lightdm that just made it into oneiric
<jibel> pitti, saw that but I never been able to reproduce, standing by.
<pitti> I'm currently running an alternate amd64 smoketest
<pitti> jibel: oh? it's 100% reproducible in kvm for me
<pitti> jibel: anyway, I think there's no rush
<pitti> jibel: if you could start with posting kubuntu?
<pitti> mythbuntu and u-studio also don't seem to use lightdm
<stgraber> please don't post edubuntu as we're also using lightdm. I'm doing a bit of smoke testing on the current build anyway and might have some other things to fix (will know in ~45min)
<pitti> right, ubuntu/edubuntu/xubuntu use lightdm
<pitti> once my alternate test install is finished, I'll check if I still get the lightdm bug, and upgrade to the new version
<pitti> jibel: bug 791883 might spoil Kubuntu, I'm unsure about how widespread it is
<ubot4> Launchpad bug 791883 in ubiquity (Ubuntu Oneiric) (and 3 other projects) "ubi-console-setup.py:set_keyboard() gets error 141 (crashes) in Kubuntu (affects: 1) (heat: 125)" [High,Confirmed] https://launchpad.net/bugs/791883
<pitti> jibel: I don't get the lightdm race in a KVM install either
<pitti> but when booting the desktop CD
<pitti> so I'll just rebuild teh ubuntu desktops, check if it's fixed there now
<pitti> and if so, rebuild xubuntu/edubuntu
<stgraber> I'll need to upload a new edubuntu-live for Edubuntu, so please wait for the rebuild.
<pitti> today's ubuntu alternate installs fine
<pitti> stgraber: ok, please prod me
<ogra_> hmpf
<ogra_> arm fails builds on compiz/unity
<pitti> ogra_: ?
<ogra_> usual archive skew i guess
<stgraber> also, for some reason lightdm didn't work properly when booting Edubuntu... My VM got to vt1 which was running a getty as it's supposed to. Doing a ps showed an X server running on some other vt. Switching to it crashed X (apparently). To get a working Live session, I then had to do a "sudo start lightdm".
<stgraber> not sure if that's what you'd get with bug 802271 affecting a livecd
<ubot4> Launchpad bug 802271 in lightdm (Ubuntu Oneiric) (and 1 other project) "Characters sent to tty1 (affects: 9) (dups: 2) (heat: 60)" [Critical,Triaged] https://launchpad.net/bugs/802271
<stgraber> or if that was something completely different
<pitti> stgraber: that's exactly this issue, yes
<pitti> current lightdm is supposed to fix it
<pitti> but needs confirmation
<pitti> stgraber: I get the same when booting ubuntu desktop live in kvm
<ogra_> argh
<ogra_> unity ftbfs
<stgraber> ok cool, so hopefully with that fix + the new edubuntu-live we should have something that's pretty good (rest looks good for now).
<ogra_> The following packages have unmet dependencies:
<ogra_>  libnux-1.0-dev : Depends: libnux-1.0-0 (= 1.0.2-0ubuntu1) but it is not going to be installed
<ogra_> E: Broken packages
<ogra_> hmm, might be a timing issue
 * ogra_ gives back
<stgraber> oh, interesting: apport-unpack, "NameError: name 'apport' is not defined" :)
<stgraber> pitti: I guess you should do s/apport.fatal/fatal/g in apport-unpack. Want a patch for that?
 * ogra_ gives back ppc too, seems to have the same issue
<stgraber> oh, why is gdm still on edubuntu's dvd? that can't be good :)
<ogra_> fix your seeds :)
<stgraber> stgraber@castiana:~/data/vm/iso$ grep -r gdm ~/data/code/seeds/edubuntu.oneiric/
<stgraber> stgraber@castiana:~/data/vm/iso$
<ogra_> whhee
<stgraber> argh, sabayon hard-depends on it...
<pitti> stgraber: fixed in trunk, thanks!
<ogra_> k, looks like unity will build on both platforms ..
 * stgraber starts poking at sabayon...
<stgraber> pitti: edubuntu should be good for a rebuild when both edubuntu-live and sabayon are done building and published
<pitti> stgraber: thanks; added tabs for their build pages
<pitti> stgraber: hm, sabayon building too long
<pitti> stgraber: so I'll rebuild the edubuntu CDs at 1200 UTC
<stgraber> ok, sounds good
<stgraber> I'm off for lunch anyway (till ~ 11:00 UTC)
<pitti> stgraber: still in Europe?
<stgraber> yep, in Switzerland for two weeks
<pitti> jibel: http://cdimage.ubuntu.com/daily-live/20110705.1/ arrived; I'm testing this for the lightdm VT issue
<jibel> pitti, ok, syncing
<pitti> jibel: yay, this fixes it for me
<jibel> \o/
<pitti> jibel: I added the Ubuntu desktops and the upgrade/netboot bits to the iso tracker now
<pitti> I'll rebuild alternate and xubuntus now
<jibel> pitti, thanks
<pitti> jibel: can you do a smoketest of the desktops for installation?
<jibel> pitti, sure
<pitti> and then in 1.5 hours edubuntu
<jibel> smoketest is running. time to prepare some lunch. back in a bit
<pitti> jibel, Daviey: do you know what the name of http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/20110705/ should be?
<pitti> I don't find an entry like "Ubuntu Server Preinstalled (armel)" in the iso tracker
<pitti> or is that "Ubuntu Headless armel+omap3"?
<pitti> ah no, this has its own dir (http://cdimage.ubuntu.com/ubuntu-headless/daily-preinstalled/) and is fairly out of date
<ogra_> pitti, i guess tobin is a bit behind, healdess was renamed to server last week
<ogra_> tracker was likely not updated yet
<ogra_> pitti, ignore headless
<pitti> so should we rename the headless thing to server in the iso tracker?
<ogra_> yes
<ogra_> i would have loved to keep headless until we have a chicken subarch ... but the others disagreed :P
<ogra_> so now its all server :)
<pitti> hm, I can't actually remove/rename products
<ogra_> then put it under headless and GrueMaster can solve it if he is up, i think he can change names
<pitti> jibel, stgraber: ^ do you know how to do this? apparently I can add a new product "Ubuntu Server armel+omap3" (same for omap4), but I'd like to remove the headless cruft, too
<ogra_> if he doesnt, he at least knows who can
<pitti> ok, fair enough
<jibel> pitti, I'll do, this can only be done with an update in the database
<pitti> jibel: thanks
<ogra_> (its not like A2 is tomorrow, no hurry :) )
<pitti> ogra_: I remove http://cdimage.ubuntu.com/ubuntu-headless/ then
<pitti> as it's confusing now
<ogra_> yep
<pitti> gone
<jibel> ogra_, is it a new product or a rename of headless ? from bug 805811 it is not clear
<ubot4> Launchpad bug 805811 in ubuntu-qa-website "Need to update the arm image list for Alpha 2 (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/805811
 * pitti lunch &
<ogra_> let me check
<ogra_> jibel, what was headless before is now server ...
<ogra_> what was netbook before is now desktop
<ogra_> in the first case nothing but the name changed, in the second case we actually changed seeds
<ogra_> hedless and netbook are definitely dead
<jibel> ogra_, ok I'll update the names of the products on the tracker. thanks.
<pitti> I'll remove ubuntu-netbook/ from cdimage, too
<ogra_> only the dailies please :)
 * ogra_ isnt sure there are any releases under the direcrtory tree
<pitti> http://cdimage.ubuntu.com/ubuntu-netbook/daily-preinstalled/
<pitti> ogra_: apparently not
<ogra_> then go for it
<pitti> only three dailies from June
<ogra_> http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/ has them
<jibel> pitti, desktop amd64 is ok, I get bug 791139 with i386 running on VBox on an amd64 host.
<ubot4> Launchpad bug 791139 in ubiquity (Ubuntu) "When booting from an ISO, a shell is displayed for 2 min before the graphics environment starts (affects: 1) (heat: 129)" [Medium,Confirmed] https://launchpad.net/bugs/791139
<pitti> jibel: ah, I don't get that on my amd64 system with kvm
<pitti> ogra_: hm, unity built on armel, but is still uninstallable on http://people.canonical.com/~ubuntu-archive/testing/oneiric_probs.html; do you know why?
<pitti> some compiz issue?
<stgraber> pitti: ok, apparently both sabayon and edubuntu-live are built and published. Should be good for an edubuntu rebuild.
<pitti> yep, triggering
<stgraber> thanks!
<pitti> xubuntu dailies are almost done
<pitti> ubuntu/xubuntu alternates posted
<pitti> xubuntu desktop posted
<pitti> cjwatson: do you have an idea how widespread the kubiquity crash in bug 791883 is?
<ubot4> Launchpad bug 791883 in ubiquity (Ubuntu Oneiric) (and 3 other projects) "ubi-console-setup.py:set_keyboard() gets error 141 (crashes) in Kubuntu (affects: 1) (heat: 125)" [High,Confirmed] https://launchpad.net/bugs/791883
<pitti> does ubiquity just need a rebuild against xkb-data, like console-setup? or more involved changes?
<pitti> ubuntu daily-preinstalled failed to build
<ogra_> hmm, i did get empty failure mail
<ogra_> pitti, hmm, linux-omap4 ...
<ogra_> do we miss a meta upload ?
<pitti> perhaps?
<pitti> kubuntu preinstalled failed as well (at least on sycamore; annonaceae still busy)
<ogra_> same issue
<ogra_> omap 3 should build
<pitti> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/ubuntu-omap/ doesn't seem to have the current logs yet
<pitti> ogra_: where did you see the failure?
<ogra_> tim is on it, there was a kernel upload on the 21st
<pitti> ok, great
<ogra_> on sycamore directly
<ogra_> w3m from antimony
<pitti> ogra_: did annonaceae.buildd for ubuntu preinstalled have a different problem then?
<pitti> that's omap3, right?
<ogra_> did that fail too ?
 * ogra_ checks mail
<pitti> ah, found the log
<ogra_> oh, right
<Ursinha> 321
<pitti> still compiz-core breaking unity < 4.2.0
<Ursinha>    ;
<Ursinha> erm, sorry
<ogra_> pitti, likely missed the publisher
<pitti> so presumably kubuntu on omap3 should have a real chance
<pitti> ogra_: so I'll wait for the meta-omap upload before triggering another build
<ogra_> heh, if there are no other package issues, yeah
<ogra_> omap4, but yeah
<pitti> nux, compiz, unity appear current in madison
<pitti> so yes, probably a publisher race condition
<ScottK> pitti: Are you driving the bus for Alpha 2?
<pitti> ScottK: yes
<ScottK> For Kubuntu we're considering giving Alpha 2 a pass.
<ScottK> Getting our KDE packaging reworked for KDE 4.7 still isn't quite complete and we have an unresolved ubiquity-kde crasher that means you can't install from the live CD.
<ScottK> So the benefit of Kubuntu Alpha 2 ISOs would be, probably, not a lot and testing them will distract people from getting some of this stuff fixed.
<ScottK> Thoughts on this?
<ScottK> pitti: ^^^
<pitti> ScottK: seems entirely reasonable from my POV; that should be the call of the Kubuntu developers really, for whom I consider you one of the best representatives :)
<pitti> ScottK: I pinged Colin about the ubiquity crash earlier on, but I suppose he's on holiday
<ScottK> I know maco has tried to get it sorted, but AFAIK didn't get a solution yet.
<pitti> ScottK: do you want me to disable the kubuntu images in the tracker, or still leave them there for interested parties?
<ScottK> I'd say leave them for now.
<ScottK> Maybe a miracle will occur in the next 24 hours ...
<pitti> not unheard of!
<pitti> ogra_: ah, linux-meta-ti-omap4 build in accepted; so we can spin in 1.5 hours
<ogra_> great
 * ogra_ crosses fingers nux is fine
<pitti> stgraber: bah, edubuntu failed for some reason (http://cdimage.ubuntu.com/edubuntu/dvd/20110705.1/), checking
<pitti> hash sum mismatch in apt
 * pitti tries again
<pitti> ScottK: ironically the omap3 image http://cdimage.ubuntu.com/kubuntu/daily-preinstalled/20110705/ built just fine :)
<ScottK> :-)
<pitti> ScottK: circumventing the installer does have its advantages apparently
<stgraber> pitti: at least the livefs looks good, that's usually a good start
<pitti> stgraber: right, I think the hash sum mismatch is an old and common problem
<pitti> stgraber: I'm just restarting the iso build, not the live fs build
<stgraber> ok, good. That's the "fast" part of our build process :)
<pitti> faster, anyway (still taking some 15 minutes)
<pitti> stgraber: worked now
<stgraber> yeah!
<pitti> stgraber: still being mirrored; added to tracker now
<stgraber> thanks. I'll start rsyncing as soon as they're done mirroring
<pitti> amd64 is there
<skaet> FYI: https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview appears to have been deleted over the weekend.   Am working with IS to restore it.
<pitti> hey skaet
<pitti> eww
<pitti> skaet: some piece of good news to compensate: LP can actually look for "bugs which do not have this tag"
<skaet> hiya pitti,  yeah,  nice thing to start the week of with :P
<skaet> nice news is always welcome
<pitti> skaet: so I made up an actually useful alpha-2 bug list
<skaet> :)
<pitti> https://bugs.launchpad.net/ubuntu/oneiric/+bugs?field.milestone%3Alist=39141&field.tag=-ftbfs
<pitti> http://iso.qa.ubuntu.com/qatracker/ is still having way too few red bugs; apparently this milestone's big disaster is still waiting to be discovered
<skaet> From the backscrolls,  looks like Kubuntu isn't going out.
<GrueMaster> Morning.  I notice that the iso.qa.ubuntu.com only lists netboot arm omap for armel.  While I am fine only testing that, I don't think it is all we have.  :P
<ogra_> GrueMaster, headless were dropped, and i thought jibel added server
<GrueMaster> No server, no dektop.  Only netboot for omap (not omap4).
<pitti> GrueMaster: omap3 kubuntu built
<pitti> GrueMaster: still waiting for the linux-meta-ti-omap package to publish until any omap4 image will actually build
<ogra_> GrueMaster, desktop are both broken atm
<pitti> and this morning's omap3 desktop failed due to unity (shoudl also be fixed now)
<GrueMaster> ok
<ogra_> server omap3 should exist though
<pitti> GrueMaster: will do a spin in an hour, when the meta package is on the mirrors
<GrueMaster> Why am I not surprised.
<pitti> server on iso tracker is blocked on jibel or someone with DB access to rename the product
<GrueMaster> btw, I am experiencing a 1.5s lag on irc.  Not sure why yet.
 * Daviey ponders.
<skaet> https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview has been restored.
<pitti> yay
<pitti> skaet: I'll see to adding some desktop news there
<pitti> unity 2d, umask 002, thunderbird, deja-dup, etc.
<skaet> thanks pitti!  :)
<pitti> skaet: but maybe not before tomorrow morning; have desktop team meeting coming up soon, and still fiddling with images and archive consistency
<pitti> sounds ok?
<skaet> it still needs some of the old bugs pruned out of it (and new ones added of course)
<skaet> pitti,  tomorrow morning your time is fine.  Thanks!
 * skaet goes and cleans out the old bugs now then.
<skaet> Daviey,  ogra_ - I'll go make the structural changes now to reflect we're not doing headless, but rather ubuntu server for arm.   Can you put the overview info in to your sections by 1300 UTC?
<Daviey> skaet: 1300 UTC today?
<ogra_> or yesterday ?
<ogra_> :P
<ogra_> (obviously not today)
<Daviey> ogra_: Do you think this is one for NCommander to attack?
<ogra_> he is on vacation
<Daviey> slack.
<Daviey> ogra_: Should i have a punt, or are you over it?
<skaet> Daviey, ogra_ 1300 UTC tomorrow.
<ogra_> well, i dont have much to say apart from headles being server now and netboot existing
<Daviey> Ah! perfect
<skaet> sorry,  should have been more explicit.
<Daviey> ogra_: has netboot instructions been documented?
<pitti> bug 805811, FTR
<ubot4> Launchpad bug 805811 in ubuntu-qa-website "Need to update the arm image list for Alpha 2 (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/805811
<ogra_> Daviey, i dont think so ...
<ogra_> but i'm not sure
<ogra_> probably GrueMaster knows more ?
<ogra_> NCommander didnt tell me about docs yet
<Daviey> ogra_: Can you or GrueMaster check into that, and i'll try to tackle the tech overview and link to those docs.
<GrueMaster> Daviey: Not yet for arm.  I was hoping they were for x86/amd64.
<GrueMaster> It is on my todo for A2, so it will get done today or tomorrow.
<Daviey> GrueMaster: Ah, the experience is idential to /normal/ platforms?
<GrueMaster> Yes.  Should be identical.
<Daviey> splendid
<GrueMaster> ignore the cdrom image.
<stgraber> doh, Edubuntu still has gdm on the cd... /me investigates
<GrueMaster> For now, use either the boot.img-fb or boot.img-serial and flash it to SD, then boot.  More work needs to be done for PXE boot.
 * GrueMaster starts hunting for the elusive morning coffee.
<stgraber> hmm, I don't get it. The only thing "aptitude why" gives me is a suggest from some package. Must be something else...
<Daviey> GrueMaster: yeah, it was the PXE experience i was hoping was documented... i thought that was what would differ.
<stgraber> oh fun, and apparently it's only on the 64bit CD. i386 is fine...
<stgraber> s/CD/DVD/g
<GrueMaster> Daviey: Well, pxe only started happening last Thursday at the rally.
<Daviey> (/me is most excited about this.)
<stgraber> pitti: as amd64 built a bit before i386 and only amd64 ships gdm I'm tempted to think it's just a race condition and a rebuild of Edubuntu livefs will be enough to get rid of gdm. I'm currently running germinate locally to make sure.
<jibel> GrueMaster, I added the arm desktop and server products to the tracker. I need testcases, do I keep the same than for previous headless and netbook ?
<stgraber> pitti: ok, I'm not great at playing with germinate but I couldn't find any reason for gdm to be installed (nothing in the seeds, no depends/recommends and it doesn't show up when installing edubuntu-desktop on a clean system). Can you start yet another rebuild of edubuntu?
<stgraber> I'm testing i386 for now as it seems fine (at least it doesn't ship gdm :))
<GrueMaster> jibel: yes, they should be the same for now.
<jibel> GrueMaster, k
<stgraber> pitti, skaet: I disabled Edubuntu DVD amd64 as the current build has both lightdm and ldm so we're never going to ship that ;)
<pitti> stgraber: does it actually work, though? /etc/X11/default-display-manager should say which one actually gets started
<stgraber> pitti: nope, I get a shell instead of a working session :)
<stgraber> gdm is running on some vt but not on the one I see when the DVD starts
<stgraber> so the user may get a working session by switching vt or by killing gdm + starting lightdm
<pitti> stgraber: ok, so we'll rebuild?
<pitti> I'm in a meeting now
<stgraber> pitti: let me just poke at i386 for 5 minutes
<stgraber> pitti: yep, I triple-checked that i386 works as expected (as in, installs), so please start a rebuild whenever you've time.
<pitti> stgraber: weird; so we missed a publisher cycle somehow?
<pitti> I started it well after the one that published the new sabayon
<stgraber> pitti: I'm really not sure. I have the right version of sabayon on amd64 too but "aptitude why" can't tell me why gdm is on there
<stgraber> pitti: and it's not on i386 and not mentioned anywhere in the seeds...
<pitti> stgraber: I can just trigger a rebuild
<pitti> stgraber: if it's still failing, nothing is lost except for some buildd entropy
<stgraber> pitti: that'd be great. If I still get gdm on amd64 after a rebuild I'll wait for Colin who should be back tomorrow :)
<pitti> stgraber: running
<stgraber> thanks!
<pitti> stgraber: would you mind adding it to the tracker if it lands? I'll probably be AFK when it finishes (~ 1 hour)
<stgraber> pitti: sure, will do.
<pitti> thanks
<stgraber> skaet: btw, don't worry if you see "bug 0" popping up somewhere. I had to give a bug number to be able to mark the image as broken (and didn't have a LP bug number as it was a race in the build process ;)).
<ubot4> stgraber: Bug 0 on http://launchpad.net/bugs/0 is private
<stgraber> ubot4: nah, it's not private, it just can't exist ;)
<ubot4> stgraber: Error: I am only a bot, please don't think I'm intelligent :)
<highvoltage> oh I just assumed bug 0 was something like "sabdfl isn't ruler of the world yet" :)
<ubot4> highvoltage: Bug 0 on http://launchpad.net/bugs/0 is private
<jibel> GrueMaster, arm server and netinstall added to the tracker
<GrueMaster> Thanks.  We'll have to make adjustments to the netboot section, but that can wait until I have a testplan.  Not A2 critical.  For now, if it works, ship it.  :P
<jibel> pitti, When arm desktop images are ready, there are now 2 products called Ubuntu Desktop armel+omap and omap4
<GrueMaster> Yes, I am painfully aware of it.
<GrueMaster> Ubuntu & Kubuntu.
<pitti> jibel: oh, thanks! you updated the db for headless->server and netbook->desktop?
<pitti> then I'll reflect the changes in the image release script
<jibel> pitti, no I added new products and copied the testcases and links to the images, otherwise that was a mess.
<pitti> jibel: can you remove the old products then?
<skaet> stgraber,  ack ;)
<GrueMaster> jibel: For A3, we should give the entire arm list an overhaul.  The testcases should closely match the testcases for x86/amd64 where possible.  The only differences should be in the install process.
<GrueMaster> Can I ping you next week to go over the list?
<jibel> pitti, you need to remove them completely from the db ? The release script does screen scraping or does it access the db ?
<pitti> jibel: no, but the "add image" list becomes longer and longer, and we shouldn't pile up old cruft there
<pitti> jibel: we do screen scraping
<stgraber> jibel: btw, never remove a product or testcase from the DB
<pitti> is there db access?
<stgraber> jibel: just set the right state to whatever value means "removed" (yeah I'm not logged in the DB :))
<jibel> stgraber, sure, I just make them 'invisible' to the users
<GrueMaster> Removing a product would be bad.  YOu would lose all test history.
<stgraber> jibel: yeah :) Just wanted to make sure we don't end up having some DB inconsistency ;)
<jibel> pitti, i'll check the code, but I'm not sure I can hide something from that list.
<pitti> jibel: ok; if it's causing problems, don't bother
<pitti> I just thought it'd be straightforward to rename
<jibel> heh straightforward doesn't match with isotracker
<stgraber> jibel: heh ;) we just need someone to write a descent admin interface. IIRC I wrote some place holders for where it should be :)
<GrueMaster> I like the way it is.  Keep the community guessing.  They'll never know what we're testing.  Muahaha.
<skaet> jibel, pitti - in the pruning,  remember we're going to need to release 10.04.3, 10.04.4 images ;)
<jibel> GrueMaster, no problem to review the list next week.
<GrueMaster> cool
<pitti> GrueMaster, jibel: I added server omaps to the tracker
<pitti> although they might be affected by the bad kernel meta package as well?
<GrueMaster> I have server images for 0705.
<pitti> skaet: ok, can you take over from here? time to make/have dinner, and EOD
<pitti> actually, it's time to kick off ubuntu armel builds again
<pitti> I'll do that still
<skaet> heh
<skaet> I was just about to ask which are still pending at this point.
<pitti> kubuntu preinstalled are built for omap3, but not added to the tracker, as omap4 is missing, and kubuntu asked to skip a2
<pitti> skaet: edubuntu dvd building, amd64 needs test that lightdm comes up properly
<pitti> and then added to tracker
<pitti> skaet: ubuntu daily-preinstalled building now, needs adding to tracker when done
 * skaet nods
<pitti> that's what I have
<pitti> the rest is testing, and uncovering the major breakage that we always used to have
<skaet> thanks.
<skaet> :)
<pitti> so, see you tomorrow!
<pitti> I'll be online again around 0430 UTC
<skaet> have a good evening.    :)
<pitti> thanks
<stgraber> yeah! no more gdm on the new edubuntu build :)
<skaet> stgraber,   ok to post?
<skaet> stgraber,  hmmm...  no still seems to be building.  what were you testing?
<skaet> heh,  ok, am seeing it now...
<skaet> stgraber,  edubuntu dvds posted.
<stgraber> skaet: I was monitoring the build logs at http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/edubuntu-dvd/20110705.2/
<stgraber> skaet: thanks for posting them!
<skaet> stgraber,  thanks for the updates to the release notes.  :)
 * skaet heads out for lunch,  biab
<GrueMaster> Looks bad for omap images (not omap4, just Beagle/BeagleXM).  u-boot script issues and kernel segfault early during boot.  Filing bugs now.
<GrueMaster> Not fixable for A2.
<skaet> GrueMaster, ack.
<skaet> GrueMaster, ogra_ ubuntu daily pre-installed (omap, omap4) added to the tracker.
<GrueMaster> Just saw them.  Pulling now.
<jdstrand> skaet: hi! so, I just filed bug #806167 and bug #806166. these bugs can wait until after alpha-2 is released, however, if you are respinning the server ISOs anyway, I'd be happy to upload
<ubot4> Launchpad bug 806167 in qemu-kvm (Ubuntu Oneiric) (and 1 other project) "CVE-2011-2212 (affects: 1) (heat: 258)" [Medium,In progress] https://launchpad.net/bugs/806167
<ubot4> Launchpad bug 806166 in qemu-kvm (Ubuntu Oneiric) (and 1 other project) "CVE-2011-2512 (affects: 1) (heat: 258)" [Medium,In progress] https://launchpad.net/bugs/806166
<skaet> jdstrand, thanks for the heads up.  No respins planned at this point, but we're still collecting initial test data...   Will let you know if a spin looks likely.
<jdstrand> skaet: okie dokie
<skaet> :)
<skaet> ScottK, have updated https://wiki.ubuntu.com/OneiricOcelot/ReleaseImageContacts to indicate there won't be A2 images for Kubuntu this time around.
<GrueMaster> skaet: We have more failures, now on omap4.  related to bug #791552.  Will update iso tracker soon.
<ubot4> Launchpad bug 791552 in linux-ti-omap4 (Ubuntu Oneiric) (and 9 other projects) "No USB support on Armel (affects: 1) (heat: 14)" [Undecided,Fix released] https://launchpad.net/bugs/791552
<GrueMaster> Doesn't look good for armel images this release.
<skaet> GrueMaster, urgh
<skaet> GrueMaster, will you be updating the status on 791552?  (Fixed released --> ??)
<ogra_> seems all our kernels are broken :(
<GrueMaster> Yes, as soon as I test Paulo's test kernel.
<ScottK> skaet: OK.  If that should somehow change, I'll let you know.
#ubuntu-release 2011-07-06
<pitti> Good morning
<pitti> GrueMaster, skaet: hm, you used "Ubuntu ARM Preinstalled omap{3,4}" in the tracker? Isn't that what "Ubuntu Desktop armel+omap{,4}" is nowadays?
<pitti> or yet another image?
<GrueMaster> No, probably should be desktop.
<pitti> ok, thanks
<pitti> so "Ubutu ARM Preinstalled" is obsolete indeed
 * pitti is currently trying to update publish-image-set.py accordingly
<GrueMaster> I'm off to bed.  See you in ~8 hours.
<pitti> see you!
<pitti> jibel: bonojur
<pitti> bonjour, rather
<pitti> jibel: I have a question for you in bug 791159
<ubot4> Launchpad bug 791159 in ubiquity (Ubuntu) "OEM Install: No launcher or desktop shortcut to prepare for shipping (affects: 1) (heat: 120)" [Medium,New] https://launchpad.net/bugs/791159
<jibel> Guten Morgen pitti
<jibel> it is fixed
<pitti> jibel: nice, thanks for confirming
<jibel> you're welcome
<pitti> jibel: do you think bug 804655 is important enough to warrant a respin? it should properly fall back to 2d on these devices
<ubot4> Launchpad bug 804655 in mesa (Ubuntu) "r300 loading instead of r300g (affects: 3) (heat: 16)" [High,Confirmed] https://launchpad.net/bugs/804655
<pitti> but I'm not sure how much we want people to test the 3d live bits on ati
<pitti> with the new gallium drivers
<pitti> skaet: I updated https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview with the desktop news, and what I think are noteworthy bugs
<jibel> pitti, I'm not sure how critical it is for a2. 2d fallback should work and isn't there a way to force r300g loading ?
<pitti> I don't think it's critical
<pitti> I don't know how to force r300g, RAOF would know
<jibel> and that would require a respin of all the images. I don't think we have time for this.
<pitti> *nod*
<pitti> we used to respin on Wednesdays, but unlike previous times we actually have little reason to
<pitti> back in ~ 30 mins
<ogra_> pitti, so we have a chance of getting a new kernel for omap4 that could make the images work ... apw is just doing a testbuild for me
 * cjwatson yawns
<apw> ogra_: it seems the omap3 kernel already has the fix we are testing so should be unaffacted (assuming there are images for that even)
<ogra_> yes, omap3 just segfaults
<apw> quality
<ogra_> USb is fine i suppose ... not that we were able to boot far enough to verify though
<cjwatson> pitti: anything in particular I should be looking at?
<apw> everyone happy for me to upload this fixed ti-omap4 (only) kernel, is tested by ogra_
<ogra_> go ! :)
<cjwatson> incidentally, I thought that bug 791883 was fixed now, I just hadn't closed the remaining task because I wanted to test it properly
<ubot4> Launchpad bug 791883 in ubiquity (Ubuntu Oneiric) (and 3 other projects) "ubi-console-setup.py:set_keyboard() gets error 141 (crashes) in Kubuntu (affects: 1) (heat: 125)" [High,Confirmed] https://launchpad.net/bugs/791883
<pitti> hey cjwatson, good morning; how are you?
<pitti> apw: please go ahead
<cjwatson> not bad, thanks
<apw> pitti: ogra_: on it thanks
<ogra_> pitti, even though it wont fix the broken omap3 kernel, could you let u-boot out of new, will be at least one bug less on the images
<pitti> cjwatson: some Kubuntu test installs went through without mentioning this, indeed; was that hard to reproduce, or did it happen every time?
<ogra_> (so it ends up on the respin)
<cjwatson> pitti: every time
<cjwatson> it's probably dead now, I'll just double-check locally
<pitti> cjwatson: other than that, I'm still waiting for the major disaster to happen
<pitti> cjwatson: bug 782507 would be in your camp, although it's far from being a blocker
<ubot4> Launchpad bug 782507 in partman-auto (Ubuntu) "Installation creates a new swap partition (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/782507
<pitti> cjwatson: thanks
<pitti> ogra_: that is u-boot-linaro?
<ogra_> yep
<ogra_> seems it adds one or two ne arches (so produces new binaries)
<pitti> looks fine; I'll put them into universe for now, as most binaries are
<cjwatson> 782507> also hardly new!  that's been the case since warty
<ogra_> yeah
<pitti> whee
<ogra_> no need for main
<pitti> ogra_: done
<ogra_> thx :)
<pitti> so I'll wait for the usb-enabled omap4 kernel, then we can at least release the omap4 bits
<ogra_> right
<pitti> cjwatson: ah, we only have kubuntu alternate results, the desktop ones are just for live session
<ogra_> at least server would be good, if desktop has issues i'm happy to leave it out
<pitti> cjwatson: but Kubuntu wants to skip a2 anyway
<cjwatson> my Kubuntu desktop test install (image from last Friday, so not suitable for iso.qa reporting) is past the point of the previous crash
<cjwatson> I'll close out that bug when rsync is done and I can restart firefox more easily
<jibel> pitti, cjwatson , I can not reproduce 791883 anymore with latest images. It was 100% reproducible.
<pitti> jibel: thanks for confirming
<cjwatson> right.  I expected it to be fixed, so good.
<cjwatson> as I say, will close shortly
<jibel> pitti, I changed bug 781076 to critical. it affects i386 upgrades, I got it on wubi i386 and xubuntu i386 upgrades and it leaves the system in a very bad state.
<ubot4> Launchpad bug 781076 in doc-base (Debian) (and 2 other projects) "package doc-base 0.9.5ubuntu2 failed to install/upgrade: Byte order is not compatible at ../../lib/Storable.pm (affects: 35) (dups: 37) (heat: 304)" [Unknown,Unknown] https://launchpad.net/bugs/781076
<pitti> jibel: ok, thanks
<jibel> bug 806349
<ubot4> Launchpad bug 806349 in ubiquity (Ubuntu Oneiric) (and 1 other project) "OEM Install fails with - KeyError: "The cache has no package named 'python2.6-minimal'" - without network connection. (affects: 1) (heat: 8)" [High,Triaged] https://launchpad.net/bugs/806349
<stgraber> pitti, skaet: Edubuntu is completely tested and good to be released for alpha-2. We have quite a few critical bugs but nothing that'll be fixed in time for a respin.
<cjwatson> jibel,pitti: 806349 fixed in bzr; does it justify a respin?
<stgraber> cjwatson: Hi! Is it possible that the switch to live-build changed the content of sources.list in the livefs? One of the Edubuntu ubiquity plugins now fail because sources.list doesn't contain any deb-src entry
<stgraber> cjwatson: bug 806428
<cjwatson> I think I deliberately left that turned off
<ubot4> Launchpad bug 806428 in edubuntu-live (Ubuntu Oneiric) (and 1 other project) "Missing detailed package selection step in Oneiric (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/806428
<pitti> re
<cjwatson> (live-build completely rewrote the sources.list handling, and I decided not to re-enable that particular bit because it makes a fairly significant difference to CD size)
<pitti> cjwatson: not from my POV; I don't think OEM install has a lot of actual value in alpha-2 (aside from testing that it works); WDYT?
<pitti> documenting the workaround (install with network) seems sufficient to me
<cjwatson> I'm OK with that, it's just not my milestone to drive :-)
<stgraber> I'm not sure I actually need deb-src for what I want to do. As python-apt should be able to generate the list of binary packages generated from a given source package without needing Sources.
<stgraber> mvo: ^
<pitti> stgraber: would take some computation -- you'd need to iterate over all binary packages, get their source package, and build a map out of that
<pitti> stgraber: it's not 100% correct during development releases due to NBS, and FTBFS, though
<stgraber> pitti: indeed, though I guess in this case we'd prefer using a bit more CPU than re-introducing deb-src in the live environment
<pitti> space wise, yes :)
<cjwatson> stgraber: changing it would involve something like http://paste.ubuntu.com/638874/ with some suitable comment
<cjwatson> but if you can avoid it, that would be good
<cjwatson> (that's in livecd-rootfs)
<stgraber> cjwatson: oh, now that I think of it :) Can you turn deb-src back on only for Edubuntu? :)
<stgraber> I have around 2GB of free space on these images so I don't really care :)
<cjwatson> well, that's what that diff does
<stgraber> oh, that link was for edubuntu I guess?
<cjwatson> yes
<cjwatson> do you want to reassign that bug to livecd-rootfs, or do you want to keep it?
<stgraber> that step is slow enough to load as it's, so I'll just re-assign to livecd-rootfs and ship Edubuntu with deb-src then
<cjwatson> ok, committed
<cjwatson> I'll upload now if you want
<cjwatson> ?
<stgraber> would be great. We're not going to respin for that but if for some reason we do get a respin it'd be nice to have.
<cjwatson> done
<pitti> stgraber: http://paste.ubuntu.com/638875/ takes 2 seconds here
<pitti> stgraber: but I guess the live-build fix is still better, if you don't care about the size
<cjwatson> I would do both fixes if it's feasible
<cjwatson> more robust that way
<stgraber> yep, I'll make a note to catch the exception from apt_pkg and use pitti's code in that case
<pitti> stgraber: note that the map values are Package objects, not names; I just quickly threw this together to see how long the iteration takes
<pitti> cjwatson: 806349 release-noted
<pitti> cjwatson: do we actually want to publish the amd64+mac images? I thought so, I fixed published-image-set.py accordingly
<cjwatson> yes please
<cjwatson> (though not to releases.u.c, once we get far enough along to be doing that)
<charlie-tca> ubuntustudio is failing for libc6; the images failed to build yesterday
<charlie-tca> They probably need a respin; I am looking at the logs right now to see what happened
<charlie-tca> E: Some index files failed to download, they have been ignored, or old ones used instead.
<charlie-tca> make: *** [apt-update] Error 100
<charlie-tca> server errors?
<charlie-tca> W: Failed to fetch file:/srv/cdimage.ubuntu.com/ftp-universe/dists/oneiric/main/binary-i386/Packages.bz2  Hash Sum mismatch
<stgraber> that's for the cd build right? not livefs?
<charlie-tca> The images are no good for alpha2, and need to be respun
<pitti> charlie-tca: looks like it just needs a respin then; I've seen this happen several times
<stgraber> if so, edubuntu had the same thing yesterday, a respin of just the cd would fix it
<charlie-tca> That's the ubuntustudio images, they are live only
<charlie-tca> rather, alternate only
<pitti> charlie-tca: I added 20110704 to the tracker yesterday; that's not enough for a2?
<charlie-tca> That image won't install
<charlie-tca> That fails for the libc6 bug that got fixed
<charlie-tca> They will need a re-spin to get an image that works
<pitti> charlie-tca: you mean "live only" == "alternate only", right?
<pitti> charlie-tca: running another build
<charlie-tca> yeah, They have alternate images only
 * pitti marks for rebuild in tracker
<charlie-tca> Thanks, pitti
 * skaet takes a sip of tea, and starts into the backscroll..
<skaet> hiya pitti,   I see ubuntu studio is rebuilding.  Any others likely to need it?
<pitti> charlie-tca: added to tracker, built now
<pitti> hey skaet
<pitti> skaet: yes, the omap4 images
<charlie-tca> Thank you
<pitti> skaet: they are waiting for https://launchpad.net/ubuntu/+source/linux-ti-omap4/2.6.38-1309.14/+build/2611421
<pitti> skaet: they should take ~ 8 hours, plus another hour publisher, so the kernel should be published in about 5 or 6 hours
<pitti> skaet: can you trigger the ubuntu desktop/server ARM images then?
<skaet> pitti,  sure, can do,  as long as they give me the signal its ready.
<pitti> skaet: was already tested from a PPA
<skaet> pitti, good to know.   thanks.
<doko> cjwatson, pitti: when do you expect the alpha2 tomorrow? asking I want to start the test rebuild before the unfreeze
 * micahg has noticed that the soft freeze has almost seemed meaningless this time around
<pitti> doko: still waiting for the new omap4 kernel, the other images seem fine to me
<pitti> doko: so I expect that we'll have all a2 images in some 12 hours
<pitti> skaet: ^ does that sound ok to you?
<pitti> doko: how does that affect a test rebuild?
<doko> would like to have something as consistent as possible
<pitti> mythbuntu posted
<pitti> doko: so better start it right now?
<skaet> pitti,  doko,   Just to double check, are the test rebuilds replacing images in the archive, or just going to doko's sandbox?
<doko> skaet: test rebuilds never reach the archive
<skaet> doko,  coolio.  then since we're not hearing any requests for rebuilds, go ahead with i386/amd64.   Hold off on the arm ones until we get the next set of images posted though.
<pitti> we can always reserve an arm buildd should another urgent upload come up
<pitti> skaet: still need anything from me? I need to leave for Taekwondo in some 5 mins
<skaet> pitti,   thanks.   Will keep an eye on those arm kernels.
<pitti> thanks
<pitti> so, see you tomorrow!
<skaet> jdstrand,  since it looks like we'll need to respin images server image for arm,  does it make sense to upload those CVEs you were mentioning yesterday?
<jdstrand> skaet: I'd be happy to upload the fixes for them, yes ;)
<jdstrand> skaet: is now a good time?
<skaet> jdstrand,  yup, nows a good time
 * skaet has a couple more hours to wait for that kernel to emerge....
<jdstrand> skaet: done (0.14.0+noroms-0ubuntu8)
<skaet> jdstrand, thanks!
<jdstrand> skaet: thank you for remembering me :)
<cjwatson> wgrant: was there any progress with rolling out germinate-lubuntu?
<skaet> arm kernel build done (took 8 hours, 21 minutes);  now waiting for publisher before kicking off those arm builds..
<ogra_> yay
<skaet> :)
<smoser> slangasek, can you populate uec images iso testing results for 20110706 ?
<smoser> http://uec-images.ubuntu.com/server/oneiric/20110706/
<smoser> or anyone other than slangasek can do that also. i believe cjwatson has.
<slangasek> smoser: having a look
<pitti> so, mythbuntu is out, too
<pitti> skaet: yay, omap4 kernel built
<pitti> skaet: ah, you are already building the new armel images apparently?
<skaet> pitti,  yup
<pitti> cool
<pitti> skaet: can you please add them as "Ubuntu Desktop armel+...", not "Ubuntu ARM ..."? the latter is deprecated, and the image release script now assumes the former
<skaet> will do.
<skaet> smoser,  I've set up the tester so results can be recorded, but the images still need to be populated.   Script is missing some info (where to put the northeast images)
 * GrueMaster is standing by for new omap4 images.
 * skaet is glad GrueMaster is standing by,  but they're still building.  Desktop should emerge first.
<GrueMaster> ok
<skaet> smoser,  was able to get the script to run,  can you confirm the right bits are in place?
<slangasek> smoser: sorry, had a power outage here just as I started working on the AMI postings.  Looks like someone else has gotten to it?
<skaet> slangasek,  took an attempt,  think its correct.  but would appreciate you or smoser confirming it.
<slangasek> skaet: well, /something/ is posted, so provided you ran the script I trust that it's correct :)
<slangasek> (I'm not going to try to compare a dozen AMI IDs by hand :-)
<skaet> :)
<skaet> script was run,
<skaet> GrueMaster, Ubuntu Desktop armel+omap4 (20110706) posted
<skaet> ogra_, ^
<GrueMaster> ok
<GrueMaster> skaet: Are you respinning armel server too?
<skaet> yup, about to start
<GrueMaster> Could you also trigger netboot to respin?  That will be the fastest and I need it for other testing as well.
<skaet> GrueMaster, just started off the server while you were typing.   Will queue up netboot next then.
<GrueMaster> ok.
<charlie-tca> skaet: updates done on https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview
<skaet> charlie-tca, thank you! :)
<skaet> GrueMaster, ogra_ omap4 server image posted
<GrueMaster> Thanks.  Hope it fairs better than desktop.
<GrueMaster> I'm seeing massive ext3-fs errors during fs resize stage.
<skaet> GrueMaster, ack.  :(
<GrueMaster> Looks like jasper failed to resize.  It resized the filesystem, but not the underlying partition.
<GrueMaster> I'll experiment a little before calling it a total loss.
<skaet> GrueMaster, I'm going to break for dinner.   infinity has triggered a netboot rebuild,  so it should be emerging.
<GrueMaster> yep.
<GrueMaster> Have fun.  I will be breaking in a couple of hours.
<skaet> I'll check back here after I get some food.   Let me know what you find (/me keeping fingers crossed).
#ubuntu-release 2011-07-07
<GrueMaster> skaet: Latest update:  omap4 server passes with minor issues (mainly error message about no monitor), netboot is running now, and desktop is experiencing issues.
<GrueMaster> On desktop, one flash card fails to resize.  On another, oem-config fails to run.  Still need to look into, but wife is demanding to go out for dinner & shopping.  Will stay up to debug when I get back.
<skaet> thanks GrueMaster.   netboot image for omap4 has been added to the iso tracker.
<GrueMaster> skaet: I updated the netboot test status, thanks for adding it.
<skaet> Thanks GrueMaster. :)
<GrueMaster> On the desktop, I am still seeing some oddities, but it may be SD card related.  Testing now on a few different cards.
<pitti> Good morning
<skaet> Good morning pitti
<skaet> was just about to call it a night.
<pitti> good news about arm server
<pitti> the desktop one sounds worrying, though
<pitti> OOI, why does it have to resize a file system? I thought it's a pre-install, and you just copy it to an sdcard or usb stick?
<pitti> skaet: anything I should be looking out for?
<pitti> I'll go through the iso tracker again and make sure to document errata
<skaet> Thanks pitti.  I've bounced you a spreadsheet that should summarize whats in the release notes vs. iso tracker.
<skaet> Probably need a pass of the A3 milestoned bugs, to cross check for those common things, that lots are finding, but weren't reported from the iso testing.   Some are already in the notes, but I haven't done the pass there yet.
<skaet> The https://wiki.ubuntu.com/OneiricOcelot/ReleaseImageContacts
<pitti> skaet: note that I deliberately left out the more obscure or highly hw dependent bug reports from the tech notes
<skaet> has the 2 ? marks on the arm side for A2 that need to be decided.    Other than that, it should have the set of images we're publishing spelled out, so worth a cross check with the publishing scripts.
<pitti> for something like "X freeze" we really want users to file new bug reports
<pitti> skaet: a3 bugs> good idea, will do
<skaet> pitti,  re: obscure/highly dependent - ack.   If I've added some you think fall into that category,  feel free to remove :)
<skaet> and on that note,  I'll call it a night...  talk to you in my timezone's morning.  ;)
<pitti> skaet: good night then!
<pitti> skaet: I might already be travelling then
<pitti> but I'll leave status notes
<GrueMaster> night skaet.
<GrueMaster> Morning pitti
<GrueMaster> On the preinstalled images, they are only 2G in size (pre-gzip).  When you dd it to an SD card, they are still only 2G.  To take full advantage of the SD without knowing the size of the SD during image build, ogra has a script that on first boot determines the true size of the SD and expands the root filesystem to fill it.
<pitti> hey GrueMaster, how are you?
<pitti> I see
<GrueMaster> The issues I am seeing on the desktop could be related to size of SD, or just the cards I have.
<GrueMaster> tired.
<pitti> thanks for the heads-up
<pitti> GrueMaster: curious that it doesn't affect server, though
<pitti> I suppose it does the same thing?
<GrueMaster> Yea, doubly troubling, as the boot partition is identical, and the software stack is the same (until you add the desktop bits).
<GrueMaster> I'd like to fail the image, but I am not sure what to file a bug against on the desktop image.
<GrueMaster> The issue I see now is oem-config crashing during system configuration.  But it appears to be a race in flash-kernel.  No logs, so no way to really know what it is.
<GrueMaster> but I have seen an issue with flash-kernel not working properly.  It usually fails trying to unmount the boot partition after writing.
<pitti> GrueMaster: interesting, does umount by itself fail as well? that's small enough to strace
<GrueMaster> no.  Works fine.
<GrueMaster> And flash-kernel doesn't always fail.
<pitti> hm, -EBUSY then?
<GrueMaster> Possibly.
<GrueMaster> Could be a busy/timeout conflict.
<GrueMaster> Coupled with the general SD performance issues we have.
<pitti> GrueMaster: do you think we shoudl document this as possible failure and release omap4, or skip them altogether?
<GrueMaster> I'm going to file a race condition bug against flash-kernel and add it to the tracker.
<GrueMaster> Tomorrow, I will try installing desktop from netboot, just to be able to test the rest of the apps.
<GrueMaster> Nothing in the desktop image has been tested this cycle as of yet, and I am getting very uncomfortable with that.
<pitti> GrueMaster: as I need to prepare the released images in the next 6 hours, do you think we shuold rather publish them for interested folks to try?
<GrueMaster> Sure.  More eyes never hurt.
<pitti> or keep them "internal" until confirmed to work?
<pitti> ok, doing that then
<GrueMaster> And this appears to be timing related, so I would really appreciate more eyes.
<GrueMaster> Hmm.  But already filed.  Makes my life much easier.
<GrueMaster> *Bug
<GrueMaster> Bug 779410
<ubot4> Launchpad bug 779410 in flash-kernel (Ubuntu) "package initramfs-tools 0.98.8ubuntu3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 (affects: 5) (dups: 3) (heat: 91)" [Undecided,New] https://launchpad.net/bugs/779410
 * pitti release-notes that
<GrueMaster> Ok, added the but to the tracker as serious.
<pitti> "ARM Desktop installations sometimes crash during the OEM configuration step or upgrades, due to a race cond
<pitti> ition in flash-kernel. (Bug:779410)"
<pitti> does that sound appropriate?
<GrueMaster> and since I can no longer distringuish a but from a bug, I am calling it a day.
<GrueMaster> Sounds good.
<pitti> GrueMaster: sleep well, and thanks for keeping up with the mess!
<GrueMaster> heh.  It's my job, it's what I do.  :P
<pitti> skaet: all alpha-2 bugs moved to alpha-3, sent mail to u-release@ about the script for this
<pitti> cjwatson: hm, according to https://wiki.ubuntu.com/OneiricOcelot/ReleaseImageContacts the amd64+mac images shouldn't be released for alpha-2
<cjwatson> pitti: sigh, as if they're significantly different ... has nobody tested them then?
<pitti> cjwatson: oh, they are tested
<pitti> perhaps the '-' just means that they aren't a requirement
<pitti> I'm happy to release them, just wondered why the wiki page has this
<pitti> I'll release them anyway, I think; they work, and can't hurt to have them (if we have the space)
<cjwatson> if they've been tested, I'm having real trouble seeing why we wouldn't release them
<pitti> *nod*; might just be an oversight
<mvo> is it ok at this point if I upload a new perl that hopefully fixes a upgrade issue with doc-base ? I guess its fine, just want to doublecheck
<pitti> mvo: yes, the soft freeze is lifted
<pitti> mvo: oh, it's a perl issue?
<mvo> thanks!
<pitti> thanks to you!
<jibel> pitti, cjwatson , oversized amd64+mac images are untested. Because usb-creator can not create a UFI bootable USB  (bug 702283) and images can not be burn to CD.
<jibel> I can not tell more since I don't have the hardware to test it on.
<ubot4> Launchpad bug 702283 in usb-creator (Ubuntu) "usb-creator doesn't create EFI-bootable USB sticks (affects: 4) (heat: 31)" [Undecided,Confirmed] https://launchpad.net/bugs/702283
<pitti> jibel: http://iso.qa.ubuntu.com/qatracker/test/5917 has 4/4 cases, though
<jibel> pitti, right, 4 failures
<pitti> ah, ok
<pitti> hm, so the tracker overview doesn't actually use different colors for pass/fail?
<pitti> "4/4" in green is a bit misleading then :)
<pitti> or does the brown (4) count the failures?
<pitti> jibel: so burning on DVD isn't an option? don't they boot?
<jibel> pitti, I thought it was. I'll ask chadadavis when he's online.
<jibel> to answer your question brown count for failures. but I agree green is totally misleading.
<pitti> smoser: can you please publish the EC2 alpha-2 images to uec-images.ubuntu.com?
<pitti> smoser: UEC, not EC2
<Daviey> pitti: utlemming is doing it first thing when he starts today.
<pitti> ah, thanks
<jibel> skaet, bug 791454 added to release notes
<ubot4> Launchpad bug 791454 in mdadm (Ubuntu Oneiric) (and 1 other project) "RAID1 Test Failed: Device need to be readded manually (affects: 1) (heat: 10)" [High,Confirmed] https://launchpad.net/bugs/791454
<pitti> skaet: current status: all releasable images published, download links for cdimage on https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview confirmed to work
<pitti> skaet: uec still needs to be published
<pitti> skaet: I'm happy with https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview now, might still need some language corrections here and there
<ogra_> i updated the arm bits on that page
<ogra_> (some spelling and grammar review would be nice)
<pitti> I did some light grammar fixes, but as another German I only get so far, of course :)
<nigelb> Spellings look good, but I didn't have the patience to read for grammar :D
<barry> i'm supposed to be patch piloting today, but it's alpha2 day, so should i refrain from uploading?
<pitti> barry: freeze is lifted, go wild
<barry> \o/
<pitti> barry: the images are set
<barry> pitti: thanks.  i guess those are the benefits of westward living :)
<pitti> barry: or, the benefits of not having to rebuild images four times for a change :)
<barry> :-D
 * ogra_ notices that pitti doesnt speak for arm :)
<pitti> ogra_: we only had one rebuild for arm :)
<ogra_> well, yeah, we would have needed more to get all images though :)
<skaet> good morning
<pitti> hey skaet
<skaet> heya pitti, looks like things are humming along nicely,  what's left?
<skaet> thanks for the script, and getting the a2 bugs moved. :)
<jibel> good morning skaet
<ogra_> hey skaet
<pitti> skaet: uec image publishing, and all the announcements
<pitti> skaet: I'd appreciate if you could give the TechOverview an once-over for grammar/spelling
<skaet> pitti,  will do.
 * skaet reading
<pitti> skaet: ok, need to leave; as I said, please SMS me when you need me to get online
<skaet> thanks pitti,  will do.
<pitti> skaet: good luck with the release!
<skaet> Thanks for all your efforts pitti - nice state to wake up to.  :)
<skaet> jibel, do we have all of the key bugs mentioned now in the release from your perspective?
<skaet> s/release/technical overview/
<jibel> yes, I reviewed your doc, compared my list and the tech overview and it is all there.
<skaet> jibel,  great!  Thank you.  :)
<skaet> ogra_, just reviewed comments on the arm images - so we're going out with that desktop omap4 one.   I think we probably should put some comments into the release notes (bug?) about the fact that arm3 ones aren't working.   Thoughts?
<ogra_> skaet, nope, desktop wont make it and yes, omap3 needs a note, i thought there was one in the known issues
<ogra_> for desktop bug 779410 is in the known issues
<ubot4> Launchpad bug 779410 in flash-kernel (Ubuntu) "package initramfs-tools 0.98.8ubuntu3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 (affects: 5) (dups: 3) (heat: 36)" [Undecided,New] https://launchpad.net/bugs/779410
 * ogra_ thought he had seen something for the omap3 stuff too ...
<ogra_> skaet, so do you want me to put notes directly in the arm section =
<ogra_> ?
<skaet> ogra_, yes please
<skaet> that seems a reasonable way of handling it.
<skaet> Daviey, utlemming - what's the status of the Cloud images being published?
<utlemming> skaet: just pulled the trigger now, ETA 10 minutes
<skaet> utlemming, :)  excellent.  Thank you.  :)
<utlemming> skaet: done
<skaet> :)
<Daviey> win
<skaet> Alpha 2 is now released. :)
<micahg> hi, skaet, I was wondering if you no longer want any universe bugs milestoned, or just the whole bunch of ftbfs bugs
<ScottK> micahg: Various people milestone bugs for various reasons, I don't think you should do a mass un-milestone of Universe bugs.
<skaet> micahg, problem was the ftbfs bugs from universe being marked high and milestoned was choking out meaningful information for the rest of the release.  Compromise that seemed to offend the least was to unmilestone the ftbfs, but leave the priority alone.
<micahg> skaet: ok, I had one non-ftbfs bug get unmilestoned as well, but I can fix that one, thanks!
<micahg> ah, I see now, it was tagged ftbfs, but that part has been resolved
<skaet> hmm... wonder if there are a few others like that.   I'll make a note to mention it in the release meeting.  Thanks for letting me know what happened.
<pitti> skaet: hello
<skaet> hiya pitti
<pitti> skaet: *wave* how is it going?
<skaet> pitti,  release is out,  all calm so far,  just doing the bookkeeping, and preping for tomorrow's meeting.
<pitti> yay you
<skaet> pitti,  thank you.
<pitti> great!
<skaet> nice bit of team work by everyone involved actually.
 * skaet likes getting releases out without drama and tension ;)
<skaet> pitti,  re: 10.04.3 - possibility of picking up a new kernel image has occured (regression fix found for crash).   Am investigating impact, so that may be on the discussion list tomorrow
<ScottK> Wouldn't that be Monday's meeting?
<skaet> we don't have a SRU meeting scheduled for next monday (every other week),  but if this goes through, and given we've cancelled the last couple,  probably worth holding a special one.
<ScottK> OK
<pitti> good night everyone
#ubuntu-release 2011-07-08
<doko> ScottK, pitti, seb128: please don't process the kde stuff in NEW within the next two hours
<pitti> doko: acknowledged
<pitti> (I don't do regular NEWing anyway)
<doko> who is? will start the test rebuild first
 * pitti looks at https://wiki.ubuntu.com/ArchiveAdministration
<pitti> apparently jdstrand today
<pitti> jdstrand: ^
<doko> ok, thanks
<jdstrand> doko, pitti: ack, but I am off today anyway
<charlie-tca> Can someone kick the server hard for me? All Xubuntu images failed to build today
<charlie-tca> desktop errors:
<charlie-tca> W: Failed to fetch file:/srv/cdimage.ubuntu.com/ftp-universe/dists/oneiric/main/binary-i386/Packages.bz2  Hash Sum mismatch
<charlie-tca> E: Some index files failed to download, they have been ignored, or old ones used instead.
<charlie-tca> make: *** [apt-update] Error 100
<charlie-tca> Sorry, alternate log errors above.
<charlie-tca> Desktop image has no log today
<charlie-tca> livefs failure by email:
<charlie-tca> W: Failure trying to run: chroot /build/chroot dpkg --force-depends --install /var/cache/apt/archives/libc6_2.13-9ubuntu1_i386.deb
<charlie-tca> Why am I getting the same failure for the LiveFS that I got the day before the alpha2 candidates were built?
<charlie-tca> cjwatson: ^  ^  any idea?
<cjwatson> don't know, haven't had time to debug it yet.  it's affecting all images.
<cjwatson> perhaps you could look into it?
<cjwatson> I've scheduled a Xubuntu alternate rebuild
<charlie-tca> Thank you
<charlie-tca> Somebody throw the wrong switch and cause everything to revert ?
<cjwatson> that seems overly simplistic
<cjwatson> there's no evidence as yet that it's the same thing, merely that it has similar symptoms; somebody needs to debug it
<charlie-tca> I was afraid of that
<charlie-tca> I honestly don't know how, but I will be patient, as long as I know you are aware of it.
<cjwatson> see if you can reproduce it with a bare debootstrap, then look at the logs inside the half-completed chroot
<tumbleweed> charlie-tca: yeah I was running into those this morning. mkdir /var/run before you debootstrap
 * tumbleweed hasn't got around to writinga  decent bug report :)
<cjwatson> so what's changed?  (it's definitely not the same thing as before; I just looked at the eglibc diff.)
<cjwatson> ah, base-files 6.3ubuntu3
<cjwatson> hooray for semi-coordinated start of /run transition.  in that case if I were you I would just not expect coherent images until it's done.
<tumbleweed> it loooks like we're behind debian in /run transition
<cjwatson> creating /var/run is probably the wrong answer
<cjwatson> we want to end up on /run
<tumbleweed> cjwatson: yaeh, that was my quick solution to get a working chroot
<tumbleweed> IIRC there were broken permissions on /var/lock too
<cjwatson> https://launchpad.net/ubuntu/oneiric/+source/base-files/6.3ubuntu3
<tumbleweed> right
<charlie-tca> I got the same results on the alternate image respin; no image
<cjwatson> there is an image
<cjwatson> http://cdimage.ubuntu.com/xubuntu/daily/20110708.1/
<charlie-tca> Then I wasn't patient.
<charlie-tca> cjwatson: Thank you again. I got in to big a rush, and it wasn't quite there when I looked
<slangasek> cjwatson: base-files in Debian still ships /var/run; you think this isn't the right thing to do?
<cjwatson> slangasek: don't know, it was Keybuk's change :-)
<cjwatson> I guess I don't mind that being smoothened in base-files
<slangasek> ah; you'd said "creating /var/run is probably the wrong answer"
<cjwatson> I meant as a hack in debootstrap
<cjwatson> minimum-diff from Debian where we can, as usual, seems like the right answer since they're already in progress on this
 * slangasek nods
<skaet> Spamaps, cjwatson;   could one of you copy the new lucid kernel into -proposed?  would like to get qa and cert testing started on it,  so we can see if wecan use it for 10.04.3.
<cjwatson> I think I'm done for the day ...
<skaet> ttps://bugs.launchpad.net/ubuntu/+source/linux/+bug/807175
<skaet> hiya brendand,  looks like the kernel's built and ready, but we're needing to get someone to copy it into -proposed.
<brendand> skeat - cool. i'll be waiting for the certification-testing task to go to confirmed
<cjwatson> skaet: I thought you had the necessary permissions
<cjwatson> (I'd have to look up how to do it just as much as you, I expect)
<skaet> cjwatson, possibly,  not sure.  I can look it up and try too.
<cjwatson> you should do, it just requires being an archive admin
<skaet> ok,  will give it a shot.   Spamaps is on holiday here, so that fall back isn't in place.
<skaet> brendand,  I'm getting errors when running the script,  so will probably need to wait until one of the more experienced folk is around to help.
<brendand> skaet - no panic
<skaet> thanks
<bdmurray> alpha2 is still an active milestone
#ubuntu-release 2011-07-09
<slangasek> bdmurray: fixed
<bdmurray> slangasek: thanks
<charlie-tca> bug 808009 for Xubuntu alternate images failing to install today
<ubot4> Launchpad bug 808009 in debian-installer (Ubuntu) "libindicator6 : Breaks: libindicator3 (<= 0.3.90-0ubuntu1) but 0.3.22-0ubuntu2 is to be installed (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/808009
#ubuntu-release 2012-07-02
<ogra_> hmm, whats that update-apt-xapian-index issue in the image builds ?
<Laney> bug #1019581
<ubot2> Launchpad bug 1019581 in software-center "update-apt-xapian-index crashed with ImportError in /usr/share/apt-xapian-index/plugins/software-center.py: cannot import name index_name" [Critical,Confirmed] https://launchpad.net/bugs/1019581
<ogra_> ah
<jibel> ogra_, I just pinged mvo on #ubuntu-desktop
<ogra_> we really should have a variable to skip it
<ogra_> so you can temporary build images without updated index
<cjwatson> jibel: I just nagged on #ca-internal too
<cjwatson> ogra_: I considered that but it seems entirely possible that this breaks some upgrades too, so I didn't want to work around it and help to take it off the radar
<cjwatson> Can't be that hard to just fix
<ogra_> indeed ...
<ogra_> hmm, seems i forgot to disable kubuntu preinstalled builds
<ogra_> did someone just disable them in bzr ? i get a merge conflict
<ogra_> (looks like /srv/cdimage.ubuntu.com/etc/crontab was hacked directly or some such
<ogra_> )
<ogra_> ... hmm, and wasnt installed with the crontab command at all
<cjwatson> I'm pretty sure Daviey did that a few days back
<ogra_> hmpf
<cjwatson> merge conflict> you mean when trying to pull into /srv/cdimage.ubuntu.com?
<ogra_> right
<cjwatson> Are you on top of it or do you need help disentangling it?
<ogra_> i removed the kubuntu preinstalled line while the tree has it manually commented and seemingly uncommitted
<ogra_> well, just editing it in the tree and a bzr resolved should do, no ?
<cjwatson> For the time being, yes
<ogra_> k
<cjwatson> I usually check 'diff -u etc/crontab <(crontab -l)' rather than just blindly overwriting the live copy
<cjwatson> Because it's very common to only comment out the live copy during milestone prep
<ogra_> yep
<ogra_> hmm, thats quite a big diff
<cjwatson> That's just "uncomment lots"
<cjwatson> Let me resolve some of it
<ogra_> yes
<ogra_> well, i'm just pulling the original crontab into the tree here
<cjwatson> Try that
<cjwatson> etc/crontab should never have been edited locally in the first plac
<cjwatson> e
<ogra_> right, i know
<cjwatson> Either commit to bzr, or do it just in 'crontab -e' for temporary stuff, not a weird halfway house
<cjwatson> committer: CD Image <cdimage@nusakan>
<ogra_> well, it shouldnt have gotten into that condition in the first place
<cjwatson>   fix etc/crontab conflict (please dont edit directly on nusakan, or at least commit it to the tree)
<cjwatson> The irony hurts.  Please edit on your local system not on nusakan
<ogra_> yes, that was me
<ogra_> how can i, i dont get the conflict over here
<cjwatson> Good grief, scp exists
<cjwatson> Can I resolve this?
<ogra_> yes, i'll keep my fingers off it
<cjwatson> I realise this isn't your fault but I want to carefully get this back to a sane state ...
<ogra_> so how would you do it (for the next time) ? scp the whole tree from /srv/cdimage to your local machine and discard your existing working tree ?
<cjwatson> Heck no
<cjwatson> 1443 should never have been committed; that should have been reverted on nusakan instea
<ogra_> then i dont get it
<cjwatson> d
<cjwatson> If it's already edited locally on nusakan, then you can edit there for the purpose of undoing things or resolving the conflict, but you must never commit on nusakan
<cjwatson> You can copy the file back locally to commit
 * ogra_ is irritated ... 
<ogra_> so there was a change on nusakan that wasnt committed ... usually i get an uncommitted changes error here, and bzr would refuse to go on with the merge ... why didnt that happen here
<cjwatson> Because it was only not committed in the working tree you were pulling into
<cjwatson> Not the tree you were running merge in
<ogra_> it merged and created the conflict .. that shouldnt be possible
<ogra_> oh, stacked trees
<ogra_> *lightbulb*
<cjwatson> It's all resolved now.
<ogra_> thx
 * ogra_ wonders why ac100 initrds are suddenly built with lzma
<rbasak> What's the quantal publishing interval now? 20 minutes?
<cjwatson> 30
<cjwatson> It starts at :03 and :33
<rbasak> Thanks
<cjwatson> (FWIW, not that this is well-known or anything, but I believe anyone in Canonical can check out lp:lp-production-crontabs now and the times are there)
<cjwatson> cocoplum-lp_publish in particular
<rbasak> It seems I can - thanks.
<xnox> last daily image is from 29th, long weekend for the CD-building? (this is daily-live/quantal/amd64)
<cjwatson> xnox: bug 1019581
<ubot2> Launchpad bug 1019581 in software-center "update-apt-xapian-index crashed with ImportError in /usr/share/apt-xapian-index/plugins/software-center.py: cannot import name index_name" [Critical,Fix released] https://launchpad.net/bugs/1019581
<cjwatson> broke image builds all weekend
<cjwatson> I whined about it on Saturday morning but nobody relevant was aruond
<cjwatson> *around
<Laney> and you can see why they failed if you look at the livefs build logs, for example http://people.canonical.com/~ubuntu-archive/livefs-build-logs/quantal/ubuntu/20120702/livecd-20120702-amd64.out
<xnox> cjwatson: Laney ok thanks
<mvo> cjwatson: should be fixed now
<mvo> sorry for the breakage
<cjwatson> ta
<cjwatson> Oops, didn't catch that in time ...
<cjwatson> mute queue new quantal-release
<mterry> Hello!  Would someone mind pushing a few packags from quantal-proposed to quantal for me?   update-manager, ubuntu-release-upgrader, and update-notifier source packages
<cjwatson> unmute queue new quantal-release
<cjwatson> mterry: done
<mterry> cjwatson, thanks!
<mterry> Is there any reason aisleriot is in main still?  It's not seeded anymore
<seb128> mterry, it's not? it was still on the CD for precise I though
<seb128> mterry, did we drop it since?
<mterry> seb128, I just ran seeded-in-ubuntu, but I thought it had been dropped in precise, so I might be wrong here
<mterry> seb128, yup, still recommended by ubuntu-desktop
<seb128> mterry, cool
<mterry> seb128, seeded-in-ubuntu's got some 'splaining to do
<Laney> We should drop it though.
<Laney> Nobody's going to work to get guile-2.0 into main
<Laney> seb128: ^^^
<Laney> (plus guile-2.0 FTBFS on arm)
<tumbleweed> hrm, it's in the manifest
 * tumbleweed looks at why seeded-in-ubuntu got that wrong
<Laney> tumbleweed: it's not wrong
<Laney> https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.quantal/view/head:/desktop#L119
<Laney> oh, false /negative/
<Laney> because it depwaits?
<seb128> Laney, or we should got back to the old version
<tumbleweed> ah, one of those
<tumbleweed> we should display a warning for that, as it's a known issue
<seb128> Laney, if it depwaits we can just delete the source and reupload the old version ;-)
<seb128> without having to tweak
<Laney> really?
<Laney> the source would be published, no?
<seb128> Laney, yes, pitti did that one beofre
<seb128> once
<cjwatson> Err
<cjwatson> If you can that's a Soyuz bug and I find it quite doubtful
<seb128> Laney, soyuz doesn't check for that
<cjwatson> I would really very much prefer that you did not do that
<Laney> I remember going backwards but I can't remember why it was ok
<micahg> the source being published isn't a problem, it's the binaries that are an issue (you just can't use the same version again)
<Laney> there are no binaries.
<seb128> right
<seb128> cjwatson, hum k, it was handy though :p
<cjwatson> Please just be explicit and bump the version forward if you're going to revert
<Laney> maybe it hadn't been published yet or something
<micahg> that's why totem is precise didn't have a crazy version number
<cjwatson> explicit is better than implicit
<micahg> *in
<seb128> micahg, yes
<Laney> ah, it was even cjwatson wot done it last time
<micahg> cjwatson: why should it matter if a source was published?  that's just used for uploading new sources, as long as there were no binaries, there's no apt/dpkg issue
<cjwatson> haha, ref?
<Laney> https://launchpad.net/ubuntu/+source/totem/+publishinghistory
<seb128> cjwatson, https://launchpad.net/ubuntu/+source/totem/+publishinghistory
<seb128> 2012-01-10 01:10:17 CET 	Deleted 	Precise 	release 	main 	gnome 	3.3.4-0ubuntu1~precise1
<seb128> 2012-01-13 12:37:39 CET 	Superseded 	Precise 	release 	main 	video 	3.0.1-0ubuntu13
<seb128> cjwatson, 3.3.4 was uploaded by error and never built
<cjwatson> micahg: I'm aware of that, there are all sorts of things inside Soyuz and in API scripts that make stronger assumptions about ordering that are reasonable as long as people aren't playing silly buggers
<seb128> pitti deleted the source and we reuploaded 3.0.1 which worked
<Laney> wasn't pitti
<seb128> oh, I though it was
<Laney> expand "deleted" and you can see
<seb128> sorry
<cjwatson> Hah, right, I wouldn't do that again
<seb128> heh
<cjwatson> But I guess that means it works at least sometimes
<micahg> cjwatson: I guess that's the "trouble" of knowing the code :)
<cjwatson> Indeed
<seb128> Laney, well anyway I guess we are good to do a new.is.really.old upload
 * Laney would still prefer to replace it with sgt-puzzles or nethack :P
<cjwatson> Laney++
<cjwatson> I guess that the above hack mostly worked because things tend to do archive.getPublishedSources()[0]
<cjwatson> So it ends up being most recent by upload order
<cjwatson> All this stuff is in code I'm not convinced anyone gets right though, which is a reason I'm newly wary of it
<cjwatson> The other day I discovered three different implementations of roughly the same ancestry detection logic, none of which I entirely agreed with
<cjwatson> infinity: https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1019514 passed my test, FWIW
<ubot2> Ubuntu bug 1019514 in livecd-rootfs "Need to be able to generate images with -proposed in sources.list" [High,Fix committed]
 * infinity checks the log.
<infinity> 0 upgraded, 0 newly installed, 0 to remove and 18 not upgraded.
<infinity> ^-- This would probably take some live-build hacking, but an upgrade post-debootstrap would be a good idea.
<infinity> cjwatson: Maybe not critical for proposed testing, but would seem the right thing to do for actual point-releases, so -security and -updates packages are installed on the image.
<infinity> cjwatson: Oh, never mind, that happens later in the log.  I guess someone thought of this already. :P
<infinity> cjwatson: Looks good, then.
<infinity> cjwatson: Fast-tracking it through.  Thanks for the test output.
<cjwatson> Great, thanks.  And as you say.
#ubuntu-release 2012-07-03
<micahg> RAOF: can you copy chromium to precise-security as well?
<RAOF> micahg: It wasn't already? Urgh.
 * micahg didn't see it on the list
<xnox> whoever synced sinfo, thank you.
<xnox> infinity: was that you? ^
<micahg> xnox: 'twas jbicha on 6/30
<xnox> thanks jbicha for sinfo sync
<xnox> micahg: ok, but how did you find out? =)
<micahg> xnox: quantal-changes :)
<xnox> micahg: lp lists it here: https://launchpad.net/~jbicha/+synchronised-packages but not
<xnox> https://launchpad.net/ubuntu/+source/sinfo/0.0.46-1
<xnox> =(
 * xnox should start subscribing to quantal-changes....
<micahg> xnox: https://lists.ubuntu.com/archives/quantal-changes/2012-June/003787.html
<slangasek> xnox: has ev brought you my DVI cable? :)
<xnox> slangasek: nope =) will get him tomorrow
<slangasek> ev: take my DVI cable to work with you! :)
<RAOF> slangasek: At your leisure, could I get your opinion on https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/978012
<ubot2> Ubuntu bug 978012 in e2fsprogs "Please SRU micro bug fix release of e2fsprogs 1.42.4-3ubuntu1 (main) from Quantal (main)" [High,Confirmed]
<xnox> slangasek: RAOF needs more work from me
<slangasek> RAOF: as long as you understand that "my leisure" is likely to only be 18 hours or so from now
<xnox> after my recent experience with mdadm...
<xnox> sru
<RAOF> slangasek: That's fine; I just want to get it on your radar.
<jbicha> xnox: yeah, it would be nice if LP would list who requested the sync on that version page
<micahg> jbicha: there's already a bug for that
<xnox> micahg: "there is an app for that" vs "there is a bug for that"
 * xnox *sigh*
<micahg> jbicha: bug 861488
<ubot2> Launchpad bug 861488 in launchpad "Mention sync requester on package version page" [High,In progress] https://launchpad.net/bugs/861488
<infinity> RAOF: I looked at it when it was first filed, and the rationale all seemed sensible then.  Haven't revisited it, though.
<RAOF> infinity: Agreed, except possibly for the "makes my life easier" bit. It's just a sizable chunk of diff for a critical package.
<infinity> RAOF: Yeah, give this one to me.  I was watching it earlier, but didn't notice Ted's updated comments more recently.
<infinity> RAOF: I'm in a reasonable position to review, though.
<RAOF> infinity: Excellent.
<RAOF> This is an outcome I was hoping for.
<tjaalton> RAOF: howdy ho, I've uploaded a new upstream microrelease (ugh) of libmusicbrainz to precise-proposed. the current version became obsolete when Musicbrainz changed their web api after precise release :/
<tjaalton> bug 1005075
<ubot2> Launchpad bug 1005075 in libmusicbrainz "Libmusicbrainz fails to parse metadata after recent MusicBrainz API update" [High,In progress] https://launchpad.net/bugs/1005075
<tjaalton> the fix was in the 4.0.3 release, but it depended on other stuff from the earlier bugfix snapshots
<tjaalton> so little reason to backport
<RAOF> Hurray for web APIs
<tjaalton> yeah
<RAOF> Race of the jobqueues: will libmusicbrainz get a launchpad diff before alioth has processed my SSH key?
<tjaalton> I'm afraid the diff looks scarier than it actually is
<tjaalton> since the package has the api docs in it too
<tjaalton> most of it is in schema & tests
<tjaalton> actual source changes aren't that huge :)
<micahg> RAOF: ^^
<RAOF> Ack.
<RAOF> tjaalton: You don't happen to know if any rdepends will FTBFS if they use deprecated functions?
<tjaalton> RAOF: the only one is sound-juicer, I'll try to rebuild it
<tjaalton> all others still use libmb3
<RAOF> tjaalton: Also, how sure are you this doesn't break ABI?
<tjaalton> RAOF: I take upstream's word for it :)
<tjaalton> sound-juicer built fine
 * RAOF is not going to take upstream's word that they've managed to somehow not break their C++ ABI  âº
<RAOF> Especially since they've added fields to classes and changed some signatures.
<tjaalton> ok, if you can add a comment there and I'll ask andy to reply
<tjaalton> would that suffice?
<RAOF> I'd prefer diffing the set of exported symbols, but I'm not sure what tools we have to ensure C++ ABI.
<tjaalton> me neither
<RAOF> Commented.
<tjaalton> thanks
<ev> slangasek: will have to do it tomorrow. I didn't see your message until just now.
<tjaalton> RAOF: andy replied, so looks like it is safe abi wise
<xnox> ev: well I didn't forget my NERF gun, so watch out ;-)
<ev> hahaha
<ogra_> hmm, no images and no build failure mails is worrying
<infinity> ogra_: No images and no failures usually means things are still building.
<infinity> ogra_: (Which seems likely, given the number of BuildLiveCDs I see)
<cjwatson> Poor celbalrai.
<xnox> =)
<infinity> Yeah,
<infinity> Also, I'm not seeing --f ext4 on those precise builds.
<infinity> I suspect the if [ "$IMAGE_TYPE" = "daily-preinstalled" ]; bit isn't doing what it was meant to.
<ogra_> infinity, we only have one preinstalled image left
<infinity> ogra_: Not in precise.
<ogra_> well, apart from server
<ogra_> oh
<ogra_> right
<infinity> Methinks you broke that.
<ogra_> did i ?
<infinity> Well, I see 3 precise builds going, and none of them has -f ext4
<ogra_> oh, i might actually
<ogra_> well, the server building in quantal, not the precise builds
<infinity> Actually, how is that broken?
 * infinity scratches his head.
<infinity> Those are buildlive daily-live processes.
<infinity> Not daily-preinstalled.
<ogra_> server ?
<ogra_> there should be a server preinstalled build
<ogra_> which my recent changes to etc/default-arches accidentially disable
<infinity> Not server.
<ogra_> *                       daily-preinstalled      maverick-precise        armel+omap armel+omap4
<ogra_> that should cover it
<infinity> mx5, omap4, omap currently.  All precise/ubuntu.
<infinity> We shouldn't even have precise armhf builds at all, according to crontab.
<infinity> Well, we wouldn't, if they weren't being triggered as daily-live jobs.
<ogra_> looking at etc/default-arches i dont see how thats possible
<infinity> cdimage@nusakan:~/cdimage$ bin/default-arches ubuntu daily-live precise
<infinity> amd64 amd64+mac i386 powerpc
<infinity> Certainly seems to DTRT.  So, WTF triggered all those builds?
<infinity> The timing of them matches with the precise daily-live cronjob.
<infinity> Bother.
<ogra_> well, the quantal buildlive run is only 1h earlier
<ogra_> are yousure it is not that one ?
<infinity> I'm sure.
<ogra_> weird
<infinity> The quantal one also spawned a BuildLiveCD.
<infinity> Which is, y'know, quantal.
<infinity> And an hour earlier. :P
<ogra_> yeah yeah
<infinity> Meh, I should be sleeping, not trying to reason at 4am.
<psivaa> apw, ping
<psivaa> cjwatson, apw, I can not find amd64 and i386 desktop images in cdimage.u.c. Any idea why and where they are? :)
<apw> psivaa, for which release
<psivaa> apw,sorry for quantal
<psivaa> apw, http://cdimage.ubuntu.com/daily-live/current/
<infinity> He's not wrong, they seem to have walked away.
<apw> psivaa, indeed they seem to be missing, i assume they failed to build last night
<infinity> If they failed to build, it would copy the images from the previous day.
<infinity> This is something more insidious.
<psivaa> apw, ack, but i would have thought in that case the latest successful image be present there
<cjwatson> Normally it is.
<cjwatson> I think it's just been failing for long enough that they got expired.
<psivaa> apw, infinity, cjwatson ack and thanks :)
<cjwatson> And yet the livefs build here was fine.
<infinity> It's not just livefs.
<infinity> The whole world is missing x86.
<infinity> server/daily, for instance.
<cjwatson> Ah, I see
<infinity> But thank god we have powerpc builds of everything.  We're saved.
<cjwatson> no entry data.tar.gz in archive
<cjwatson> debian-cd isn't too clever
<infinity> Trying to unpack a goofy .deb?
<cjwatson> data.tar.xz
<infinity> Or, rath... Yeah.
<infinity> grub?
<cjwatson> Probably syslinux.
<infinity> (or some other bootloa..)
 * cjwatson goes to attempt to modernise that code.
 * infinity tries once more to nap.
<cjwatson> Should be fixed.  Trying an updated build now.
<slangasek> ev: ok ;)
<jbicha> could someone let libzapojit through the new queue? it's needed for gnome-documents
<gema> cjwatson: the smoke testing failed on the new build, not sure why, though
<gema> cjwatson: https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-desktop-amd64_default/71/console
<gema> cjwatson: that'd be 20120703.1
<ogra_> it seems it tries to quit smoking
<ogra_> so many broken pipes
<cjwatson> Having trouble making sense of that :)
<cjwatson> Does it fail manually?
<ogra_> stdout not available somehow ?
<gema> cjwatson: it does, look at bug 1020574
<ubot2> Launchpad bug 1020574 in ubiquity "installing ubuntu on virtualbox" [Critical,Confirmed] https://launchpad.net/bugs/1020574
<cjwatson> OK, approaching end of day but I'll see if I can have a quick look
<gema> cjwatson: haven't tried HW, though
<gema> cjwatson: I don't blame you for not being able to make sense of that log, I have trouble as well, there are more logs that may be interesting on jenkins , though
<gema> cjwatson: https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-desktop-i386_default/55/artifact/55/test-results/
<cjwatson> Might as well reproduce locally
<gema> cjwatson: plugininstall.py seems to give a systemerror
<gema> cjwatson: 32: Broken pipe
<cjwatson> Yeah, I can see that
<gema> haha, I am glad I am looking in the right place :D
<cjwatson> But as ogra_ suggests that implies some file descriptor or other going away but is very very unspecific
<ogra_> and it could be anywhere down the chain
<cjwatson> My guess would be an apt/python-apt regression from the uploads on 2012-06-29, but it will need disentangling
<infinity> jbicha: Out of curiosity, do you do a large number of manual syncs to pad the numbers, or because you can't wait for the autosyncs? :)
<jbicha> infinity: most of my syncs weren't autosyncable because they had Ubuntu changes
<infinity> jbicha: Ahh.  There just seems to be a lot of them. ;)
<seb128> infinity, hey!
<seb128> infinity, will you do a round of SRU reviews today since you were off yesterday? ;-)
<jbicha> yeah, I grabbed the easier ones, there won't be near as many for a while
<infinity> seb128: I might do a few.  What's on your hitlist?
<seb128> infinity, gwibber, apport (follow up for the current version which is failing verification), software-center and ubuntu-sso-client (they fix some of the top reported issues on errors.ubuntu.com), ubuntuone-client
<seb128> infinity, check with bdmurray maybe before doing review, I tried to nudge him about some of those as well earlier ;-)
<infinity> bdmurray: ^
<bdmurray> seb128: software center has a couple of bugs not fixed in quantal afaict see #ubuntu-devel
<seb128> can we stop being religious about those?
<seb128> I'm sure mvo will do an upload to quantal soon enough with the fixes in the Vcs
<bdmurray> oh I see the bugs do have upstream branches attached
<seb128> doh, one day I will stop doing ctrl-R on xchat text entry
<bdmurray> heh
<infinity> Hrm.  sru-accept's '-s' switch doesn't seem to work as advertised.
<cjwatson> How so?
<infinity> Erm.
<infinity> Nevermind.
<infinity> Brain and eyes disagreeing.
<cjwatson> OK :)
<infinity> I want -p PACKAGE, but I'm so used to -s/S being for SOURCEPKG.
<infinity> La la la.
<cjwatson> Ah, yeah.  Let's use long options for everything. :-P
<infinity> Entertainingly, this give me a URL of ubuntu/+source/None/1.2.3-1
<infinity> SMRT.
<bdmurray> infinity: I fixed the none url thing what revno are you on?
<infinity> bdmurray: The current.
<infinity> bdmurray: Oh.
<infinity> bdmurray: Current NOW, wasn't on the first accept. :P
<bdmurray> infinity: ah ha
<infinity> bdmurray: What will it do if I call it without -p now? :)
<bdmurray> infinity: not give a url for the build
<infinity> Ahh.
<infinity> So, given that we only expect sru-accept to be called by people with queue privs (right?), can we not make it actually do the accepting too?  Which would then let us just feed series/packagename, and not have to specify version, cause it can yank it from the queue, and do the accept?
<infinity> (This also would make it feel more in line with sru-release)
<slangasek> infinity: accepting my packages before I've even written the proper SRU blurbs? :)
<infinity> slangasek: Quick, what's the regression potential?
<infinity> slangasek: OH GOD, HOW DO I TEST?!
<slangasek> infinity: see bug description for the answer
<infinity> slangasek: I think we're covered.
<infinity> slangasek: On the other hand, testing this could be a problem.
<slangasek> 1) go back in time; start mysqld
<infinity> slangasek: Unless you set up a fake stratum-1 server as your upstream and set your clocks back.
<slangasek> alternatively, 1) fake a leap second, yeah
<infinity> Though, in one of the lkml threads, there was a quick PoC for faking the leap second, I think.
<infinity> So, no need to involve ntp.
<infinity> Assuming you consider the synthetic test to be equivalent.
<slangasek> ah, can you lay your hands on the relevant mail and stick a pointer in the bug description?
<slangasek> I do consider the synthetic test equivalent, provided it triggers the futex-spinning issue in the first place
<infinity> Should do.  Let me see if I can dig it up.  It was attached to the new-and-improved kernel patch.
 * slangasek hehs, noticing that the one machine he has mysqld running on doesn't seem to be affected... except mythbackend
<infinity> https://lkml.org/lkml/2012/7/3/37
 * infinity slaps that in the bug.
<slangasek> ta
<infinity> It's under your Test Case bit now.
<stgraber> "Dear Mr. Graber, During the night of 30.06.2012 to 01.07.2012 our internal monitoring systems registered an increase in the level of IT power usage by approximately one megawatt. The reason for this huge surge is the additional switched leap second which can lead to permanent CPU load on Linux servers." <- is what I got this morning from my DC hosting provider :)
<infinity> stgraber: Nice.
 * slangasek raises an eyebrow
<elmo> stgraber: herzner?
<slangasek> presumably that's not a 1MW increase in your personal power usage :)
<infinity> Given that we've already been down this road a few years ago, this seems like a bit of egg-on-face situation for Linux in general.
<infinity> RedHat having to amend their "we fixed it" announcements with "no, really, we mean it this time" is fun.
<stgraber> elmo: yeah
<elmo> stgraber: http://imgur.com/a/ykoup/noscript <-- pics because it happened
<slangasek> well, the architecture of how we're handling leap seconds on Linux is fundamentally wrong... the kernel and filesystems should be keeping time with a monotonically incrementing time_t, and it should be glibc's problem to fix up the display :P
<highvoltage> wait what
<slangasek> *all* the problems we have with leap seconds are a result of this architecture bug
<highvoltage> that's not really an increase of a megawatt then? it just went over a megawatt?
<infinity> elmo: That graph was a lot more impressive before I realise it wasn't based at 0.
 * highvoltage is dissapointed
<infinity> slangasek: To be fair, we do what POSIX tells us to do WRT time_t.
<infinity> slangasek: Not that that's necessarily right.
<tumbleweed> we disobey posix, quite happily, elsewhere
<slangasek> infinity: which part of POSIX?
<infinity> slangasek: I do appreciate the Google solution to the problem, though.  I wonder if they've upstreamed that and I can toggle it in my ntp.conf.
<slangasek> tumbleweed: not really
<tumbleweed> not in such a fundamental way, sure
<cjwatson> infinity: do the accepting - I'll do that once I've got a bit more of my queue API work landed
<slangasek> tumbleweed: the kernel adheres quite closely to POSIX, and so does glibc
<micahg> awesome, just have aptitude SIGSEGV on me :)
 * micahg taps foot for fix for ntp issue :)...
<infinity> slangasek: If I recall, the POSIX definition of "seconds since the epoch" doesn't actually match with real seconds (ie: doesn't account for leap seconds), but is rather just a function of number of days since the epoch, times 86400.
<slangasek> infinity: ah, cute
<slangasek> so yeah, can we fix POSIX kthx
<cjwatson> infinity: which should actually be in a couple of days
 * infinity crosses his eyes trying to double-check the version comparison of "5.0.0ubuntu20.10.04.6".
<micahg> BTW, I don't think it's related to mysql/java processes, I seem have crashes all over the place (thunderbird, firefox, aptitude)
<micahg> s/related/limited to/
<infinity> micahg: Oh, it's not directly related to either.
<slangasek> bdmurray: how does bug #1020529 fit as a dupe of bug #887892?
<ubot2> Launchpad bug 1020529 in udev "package udev 173-0ubuntu4.2 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1 (dup-of: 887892)" [Undecided,New] https://launchpad.net/bugs/1020529
<ubot2> Launchpad bug 887892 in udev "lucid->oneiric upgrades fail udev upgrade: unrecognized option '--convert-db'" [High,Fix released] https://launchpad.net/bugs/887892
<infinity> micahg: It's just that some things tickle the bug more reliably than others. :P
<slangasek> bdmurray: is that maybe a typoed bug #?
 * micahg manually grabs base-files to hopefully end this nightmare
<slangasek> bdmurray: (bug #937196 seems more likely)
<ubot2> Launchpad bug 937196 in apt "10.04 LTS -> 12.04 upgrade failed: ifupdown depends on upstart and initscripts but they are not configured" [High,Confirmed] https://launchpad.net/bugs/937196
<infinity> slangasek: That same output is in the term log for the first bug.
<bdmurray> slangasek: there is a pattern for <re key="VarLogDistupgradeApttermlog">unrecognized option '--convert-db'</re>
<infinity> micahg: Have you been intentionally letting it spin until we pushed out a fix?
<micahg> infinity: sort of :)
<infinity> micahg: If so, thanks for being a guinea pig?
<slangasek> bdmurray: ah, ok - I had only looked at VarLogDistupgradeTermlog
 * infinity fixed all his systems when he first noticed it.
<infinity> Though, while all the servers I admin had the issue, the hilarious bit is that I noticed it first on my laptop.  Because it was burning my knee.
 * slangasek wonders why VarLogDistupgradeTermlog and VarLogDistupgradeApttermlog are even separate files
<infinity> True story.
<infinity> I don't know, I just wish I could consistently click on them and have them always do the same thing.
<stgraber> for some reason my laptop was the only system I admin not to be affected, my current guess is that the ifupdown ntpdate hook triggered soon after the leap second was added, updating the system time properly
<infinity> Some zipped, some not, open in browser, open file-roller, hurts my brain.
<infinity> stgraber: Or your laptop doesn't run ntp?
<infinity> stgraber: Most don't.
<infinity> (why mine does was examined shortly after the bug hit me, and ntp is now uninstalled)
<slangasek> a computer without ntp? heresy
<infinity> slangasek: I stopped to think about just how useful ntp probably isn't on a machine that spends ~50% of the day suspended, and.. Well.  Yeah.
<infinity> Bye, ntpd.
<stgraber> infinity: oh, I thought I had ntp running on that one too but apparently not, that explains it then
<slangasek> infinity: but then how will the system know what time it is when it wakes up!
<infinity> slangasek: ntpdate?  Also, batteries? ;)
<stgraber> might have ntpd back on there soon though as I'm moving back to using kerberos (well, samba4) for authentication and well, kerberos is still picky about time...
<infinity> slangasek: ntpdate gets me close enough, I'm sure, and if the all-magical HPET timer is so crap that it can't keep consistent time over the 2 or 3 hours between naps, I think this machine has bigger problems.
<infinity> stgraber: Yeah, krb's a sticking point.  I don't use it internally.
<slangasek> yes, kerberos is meant to be used topically
<infinity> So, for me, consistent time on my laptop is just about time not going backward, and generally going forward at a sane rate.  The hardware can handle that.
<infinity> (I hope)
<stgraber> infinity: is your laptop using UTC then? (otherwise the going backward part might still happen ;))
<infinity> stgraber: It's UTC at the hardware level, like any sane UNIX machine.
<infinity> stgraber: Timezones are purely for display purposes.  Unless you're DOS.
<slangasek> see above re: monotonic clocks :P
<infinity> slangasek: Yeah.  There was a good write-up somewhere about your complaint.  Maybe I'll find it again later.
<stgraber> infinity: right, DST isn't messing with the system time, just with everything else :)
<infinity> slangasek: We even *have* the right timezone sets (though we don't use them) for adding the :60 second instead of repeating :59, but it's due to the internally inconsistent POSIX "hey, what exactly is time_t anyway?" issues that we don't.
<slangasek> grmble
<slangasek> so
<slangasek> seriously
<slangasek> how do we get POSIX fixed?
<infinity> Time machine.
<infinity> Except, then you'll go into an infinite loop.
<infinity> *rimshot*
<slangasek> :P
<slangasek> cjwatson: efilinux uploaded
 * infinity runs to the store to caffeinate.
<mvo> seb128, bdmurray: right, let me double check the state of quantal, but its either in bzr or already in quantal and maybe the bug did not get closed for some reason :/
<bdmurray> mvo: being in bzr was good enough for me this time
<seb128> mvo, hey, thanks ... aptdaemon SRU testing, did you find anyone? Sorry to be nagging about it but it's in proposed for 19 days
<infinity> stgraber: I just got a conffile prompt from netbase about /etc/services... In an sbuild chroot.  I have a hard time believing I modified it by hand.
<stgraber> infinity: hmm, I didn't get that on my test upgrades, any chance you saved the delta?
<infinity> stgraber: It was in an overlay, so yeah, the original state is still around.
<infinity> stgraber: I'll poke you with details once I'm done doing what I was actually doing.
<stgraber> ok
<mvo> seb128: I know, gary is on vac right now and I didn't find time yet, I will try again tomorrow
<mvo> seb128: and no worries, its not naging, its important :)
<seb128> mvo, thanks
 * mvo hugs seb128
 * seb128 hugs mvo back
<mvo> bdmurray: thanks a lot
<slangasek> infinity: schroot itself has an annoying tendency to overwrite /etc/services as part of the chroot setup
<slangasek> it does /etc/services, /etc/protocols, and a few other things
<infinity> slangasek: Oh, that seems silly.
<slangasek> yes, I agree
<slangasek> I've taken to just blindly hammering the enter key when they come up
<slangasek> feel free to respond more productively than I have, by filing a bug or something :)
<infinity> Well, for sbuild builds, it just skips the conffile prompt anyway.
<infinity> But why it's replacing it at all is a mystery.
<slangasek> nss something something
<slangasek> /etc/schroot/default/nssdatabases
<slangasek> honestly, why would anyone think there are relevant differences in /etc/protocols between host and guest
<infinity> Or services, in 99% of cases.
<infinity> And, yet, it doesn't copy nsswitch.conf
<infinity> Which one would think might be more useful.
 * infinity shrugs.
 * infinity just edits that file and moves on with life.
<slangasek> except that nsswitch.conf requires additional package installations
<slangasek> so copying that would be even MORE insane
<infinity> slangasek: Perhaps, yes. :)
<infinity> Well, copying it by default would be insane.
<infinity> Perfectly sane to have a commented-out suggestion in there.
<infinity> "If you use nss-db to keep the base system and chroots in sync, install it in your chroots, and uncomment the following mess"
<infinity> Or something.
<infinity> Anyhow.  I don't do that anymore.
<slangasek> Daviey: glance SRU has been pending verification for 20 days; is anyone responsible for validating these fixes?  (bugs #981332, #983829, #980872)
<ubot2> Launchpad bug 981332 in glance "Content-Length and Transfer-Encoding are mutually exclusive HTTP headers" [Undecided,In progress] https://launchpad.net/bugs/981332
<ubot2> Launchpad bug 983829 in glance "[sru] notify_kombu incorrect message format for logging" [Undecided,In progress] https://launchpad.net/bugs/983829
<ubot2> Launchpad bug 980872 in glance "[sru] 'unhashable type' when sending notifications via Qpid" [Undecided,In progress] https://launchpad.net/bugs/980872
<slangasek> Daviey: similar situation for keystone (bugs #959294, #998137)
<ubot2> Launchpad bug 959294 in keystone "[SRU] Can't delete users" [Undecided,Fix committed] https://launchpad.net/bugs/959294
<ubot2> Launchpad bug 998137 in keystone "[SRU] Keystone user tenant membership not always removed" [Undecided,Fix committed] https://launchpad.net/bugs/998137
<Daviey> slangasek: Yes.. we waited for all of the openstack sru's to get accepted before pursing it.  Then, because nova had a pending security update, that was made the priority
<slangasek> hmm, ok
<Daviey> We wanted to make sure the process was sound, and will target the rest this week
<slangasek> ok cool
<Daviey> nova was undoubtedly the hardest, so these should be easier
<slangasek> anyone want to smoke test the libreoffice SRU on armhf?
<slangasek> (bug #919659)
<ubot2> Launchpad bug 919659 in libreoffice "SRU LibreOffice 3.5.4 for precise (was: Can't open/save document or spreadsheet with password, when mozilla profile has an absolute path)" [High,Fix committed] https://launchpad.net/bugs/919659
 * slangasek squints.  why am I getting a wrong (sbin-less) path in my schroots all of a sudden?
<infinity> slangasek: bug #984390 ?
<ubot2> Launchpad bug 984390 in shadow "$PATH is taken from login.defs not /etc/environment" [Medium,Triaged] https://launchpad.net/bugs/984390
<slangasek> infinity: how is shadow at all involved in running of schroot?
<infinity> slangasek: Does it not su to your user?
<infinity> (Or some equivalent)
<slangasek> infinity: this worked before the latest schroot upgrade
<slangasek> so whatever it's doing, it's doing something new and argh
<infinity> Oh.  Hrm.  See, I'd never noticed one way or the other.
<infinity> slangasek: And, wait.  Which schroot upgrade?
<slangasek> looks like schroot calls setuid directly
<slangasek> infinity: the one on 29Jun
<slangasek> I'm /assuming/ it's the schroot update that was to blame
<infinity> slangasek: In quantal?  I'm running precise's schroot and have no sbin in my path when I schroot.
<slangasek> really?
<infinity> Really.
<slangasek> I'm sure I always had it
<slangasek> I would've noticed this long before now if I didn't
<infinity> (base)adconrad@cthulhu:~$ echo $PATH
<infinity> /home/adconrad/build/ubuntu-archive-tools:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
<infinity> (base)adconrad@cthulhu:~$ schroot
<infinity> (quantal-amd64)adconrad@cthulhu:~$ echo $PATH
<infinity> /home/adconrad/build/ubuntu-archive-tools:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
<slangasek> yeah, and what's that lightdm junk in there, too :P
<infinity> You may have been setting it explicitly in your .bashrc before?
<slangasek> no
<infinity> (Which is why my schroot PATH helpfully has ubuntu-archive-tools in it, but no sbin...)
<Laney> still WFM
<Laney> (quantal-amd64)root@raleigh:/srv/home/laney# echo $PATH
<Laney> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
<slangasek> I actually am appending a few things to my path in .bashrc, and that part's working; but the base path is wrong and wasn't before
<slangasek> Laney: when doing schroot as non-root?
<infinity> Laney: Non-root is the key.
<Laney> oh, yes. Silly c-r.
<Laney> Does NOT wfm!
<infinity> Although, that X11-having path isn't the one from login.defs either.
<infinity> Cause what we needed was this bug in a new flavour.
<slangasek> oh, har
<slangasek> X11, wtf
<slangasek> which is not in *any* file under /etc, host or guest
<infinity> slangasek: I think it might be a compiled-in default for pam_env.
<slangasek> I'll hear no more of this calumny
<infinity> I wonder if we could perhaps set PATH in a few more places, just to spice up our lives a bit.
<slangasek> so this path is hard-coded in schroot
<infinity> Hahaha.
<infinity> Well, that's not new, then.
<infinity> Since it's equally broken here.
<slangasek> yeah, it's not
<slangasek> but it only started becoming an issue for me
<infinity> But why doesn't even "su - adconrad" from a root schroot session DTRT?
<slangasek> so something else changed
<infinity> I'd expect that to get the readenv=1 from pam.d/su
<slangasek> er, but wait, it *is* new
<infinity> Oh, no, that goes back to the shadow bug.
<infinity> Derp.
<slangasek> ah, no, just code moving around
<slangasek> grr
<infinity> slangasek: Erm, so I'm reading sbuild-auth.cc... Did someone really just reimplement su there, instead of just effin' calling the chroot's version?
<slangasek> dunno
<infinity> (which would still break for us, due to our bug, but at least it would be broken in one place and would, like, start a PAM sessions and stuff)
<slangasek> schroot is also pamified
<slangasek> but it doesn't call pam_env :P
<infinity> Oh, the pam bits must be elsewhere, then.
<infinity> Or, I'm looking at an sbuild-specific chunk.
<infinity> Cause I'm half asleep.
<infinity> No, cause that's where the path comes from.
<slangasek> well, it's possible that it's willfully not calling pam for some reason
<infinity> Why is half this source called "sbuild-"?
<infinity> I don't want to play anymore.
<cyphermox> infinity: like we discussed Friday; we'll start uploading evolution-data-server 3.5 to proposed; along with empathy, folks, gtkhtml, evolution and other things that could make things not install
<infinity> cyphermox: Cheers, thanks for the heads-up.
<infinity> cyphermox: Go forth and break proposed.
<infinity> cyphermox: Have you got a thunderbird to go with it?
<cyphermox> the only thing that will be missing will be thunderbird, which chrisccoulson said would maybe upload tomorrow
<cyphermox> aye
<cyphermox> evolution still doesn't work though :/
<cyphermox> sorry, that was meant for #u-desktop ;)
<infinity> slangasek: Are you sure the "pam support" isn't just for outside the chroot?
<slangasek> infinity: no?
<infinity> cyphermox: No one uses evolution anymore, I'll just remove it from the archive.
<cyphermox> that would take a load off my shoulders ;)
<slangasek> infinity: I'm not sure what distinction you're drawing.  schroot never runs in the chroot.
<infinity> slangasek: Well, yes, I suspect that's the problem.  If it's just cleaning the environment up and then dumping you unceremoniously in a setuid()/chroot(), we never get to set up a PAM session *in* the chroot, which would seem ideal.
<infinity> slangasek: (When I do chroots by hand, this is why I "chroot chroot/ su -")
<slangasek> I don't agree that's ideal at all
<infinity> slangasek: But the distinction I was making was that it probably uses PAM to auth that you're allowed to do the things you want to do, not to set up your session.
<slangasek> I don't want it to be running pam modules from *inside* the chroot
<infinity> slangasek: No?  I'd be curious as to why not.  I want my chroot session to be from the target dist, not some random mishmash of inner and outer madness.
<infinity> slangasek: At least, in a "wipe the environment" mode, which is, I think schroot's default?
<slangasek> because I don't want to have to *configure* things inside the chroot, that's busywork
<infinity> They all kinda Just Work anyway, unless you have an odd setup.
<infinity> But fair enough.
<infinity> ("schroot -u root su - slangasek" should, for instance, do what you expect)
<infinity> Or vorlon, whatever your local user is. :P
<infinity> Where "what you expect" is "not have X11 in the path, but unfortunately pull the PATH from login.defs" :P
<infinity> In my little world, that behaviour (not the shadow bug, but the "su -" behaviour) should be the default.  But I dunno.  Clearly, a contentious topic.
<infinity> Pretty sure that's more or less how the old skool dchroot behaved, before people decided it needed rewriting to be 100 times more clever.
<ScottK> Isn't it well established though that your world is a strange place?
<ScottK> ;-)
<slangasek> ok, I've downgraded now to precise schroot and get the same behavior, so grr
<slangasek> I *know* this was working previously
<slangasek> and it's a consistent behavior change in all my chroots, so it's something that's changed in the host, not the guest
<infinity> slangasek: Well, my entire base system on this machine is precise, so it's either something that also changed in an SRU, or... You're going slowly insane. ;)
<slangasek> infinity: confirmed, I'm going slowly insane
 * slangasek checks to verify that mountall will autosync from unstable, whe
<slangasek> +e
 * slangasek eyes the MIR explosion
<slangasek> (c-m, rather)
<Daviey> slangasek: For a change, it would be nice if it wasn't the server team causing explosions
<Daviey> but hey, better now, than week before release :)
#ubuntu-release 2012-07-04
<slangasek> true... :)
<infinity> Daviey: You could just stop causing them. ;)
<Daviey> infinity: lets just re-ship dapper :)
<infinity> I liked dapper.
<infinity> I wouldn't mind woody either.
<infinity> Daviey: Why does celery need to depend on an issue tracker?
<Daviey> infinity: i highly suspect it does not actually NEED it.  I think it's for the docs generation, to include better marked up issues.
<Daviey> infinity: either way, i think we can do without it.
<Daviey> infinity: I hope it doesn't try to grab data from the various BTS's.. because then it's a total don't need
<Daviey> infinity: why does this scream alarm bells? http://pb.daviey.com/Fo0Z/
<micahg> tumbleweed: ^^ there you go :)
<micahg> cjwatson: it would be awesome if precise-backports could get some love today (1 NEW, 3 Unapproved)
<cjwatson> micahg: fair enough; let me see what I can do
<tumbleweed> micahg: thanks :)
<cjwatson> Laney: Doesn't tickr need to be backported to {natty,oneiric}-backports as well?  Otherwise the lucid backport violates ordering.
<cjwatson> micahg: Cleared precise-backports; tickr (just above) is the only remaining queue entry
<Laney> cjwatson: AIUI the Lucid-Maverick upgrade path is gone.
<Laney> so the only way out is via precise
<cjwatson> Hmm
<cjwatson> I guess that's a reasonable point but it still seems kind of weird
<Laney> I suppose it is, but it makes life easier
<xnox> hmmm... you can still upgrade via http://old-releases.ubuntu.com/
<Laney> not in a supported way
<Laney> I wouldn't be surprised if there were SRUs/security updates in a similar situation
<cjwatson> grr, it's been a long time since I checked that stable installer images were up to date with kernels
<infinity> cjwatson: Should we be revving them on every SRU ABI bump?  I can trivially keep an eye on that, since I do many/most of the kernel SRU AA faff.
<cjwatson> Generally yes
<cjwatson> I seem to have neglected to create branches for oneiric and precise so far
<Daviey> Is there any way this can be caught automatically?  Humans suck.
<cjwatson> Sigh, all I was trying to do this morning was some SRU verification catchup
<infinity> Daviey: It could be fairly trivially added to the SRU report.
<infinity> I've been waiting on some highbank-related SRUs to land before I bothered touching d-i in precise, since it needs some backporty fun.
<Daviey> infinity: good thought.
<infinity> But I guess just revving the ABI for the status quo works for now.
<Daviey> infinity: I suspect there will another highbank SRU shortly.
<infinity> Daviey: I didn't mean the kernel, I meant other supporting bits.
<cjwatson> ... and the build failures start rolling in ...
<infinity> cjwatson: That's comforting.
<cjwatson> Oh, hardy/lpia didn't build last time round either.  Meh then.
 * cjwatson ignores
<cjwatson> And didn't build in hardy-release.
<infinity> I'm not convinced lpia ever had a user.
<Daviey> cjwatson: erm, Dell Mini 10 shipped with lpia?
<cjwatson> Daviey: I'm not arguing; what statement of mine are you disputing?
<Daviey> bah. sorry cjwatson - 10:15 < infinity> I'm not convinced lpia ever had a user.
<Daviey> the nicks cjwatson and infinity are clearly too similar.
<Laney> oh look, is that a package for ben?
<xnox> Laney: yeap!
 * xnox loves ;-)
<xnox> Laney: time to file bugs and feature requests! =))))
<Laney> xnox: I know, I synced it :P
<cjwatson> infinity: could you review debian-installer/oneiric-proposed?  I'm generally happy to self-review trivial API bumps under prior agreement, but the first in each series needs a little more work to enable post-release pockets
<infinity> cjwatson: Sure.  I just got an aneurysm listening to a particle physicist explain the Higgs Boson using the Paparazzi as a metaphor.
<cjwatson> I'll have one for precise-proposed coming in a bit, too.
<iulian> infinity: Exciting day, isn't it? :)
<infinity> cjwatson: Matches previous release->proposed bumps, looks good to me.
<infinity> cjwatson: Oh, before you release precise-proposed, I want to backport a fix.
<cjwatson> *blink* to the build system?
<cjwatson> But sure, backport away, I'm done with it otherwise
<infinity> cjwatson: bug #1010708
<ubot2> Launchpad bug 1010708 in eilt "create armadaxp netboot directory and move files into it" [Low,Confirmed] https://launchpad.net/bugs/1010708
<cjwatson> ah
<cjwatson> I can just backport that for you if you like
<infinity> Already done.
<cjwatson> Oh, you don't have CIA set up for that branch, OK
<infinity> Oh, I do.
<infinity> I haven't committed yet.
<cjwatson> Let me push first ...
<infinity> And you have no changelog yet.
<infinity> Ahh. ;)
<cjwatson> (I wasn't bound, by mistake)
<cjwatson> Done now
<infinity> Alright, you review mine, I'll review yours? :P
<cjwatson> Looks clearly correct to me
<infinity> Ditto.
<infinity> If your debdiff matches 'bzr diff -r1681..' consider it reviewed.
<infinity> I should nap. ;)
<cjwatson> Yeah, it does
<cjwatson> (Except for some extra noise in build/config/armhf/, because debdiff follows that symlink but bzr diff doesn't)
<xnox> import cable release coordination: slangasek and infinity I have received the cable from ev
<xnox> s/import/important/
<infinity> cjwatson: Right.
<infinity> cjwatson: Oh, are we having a short-staffed meeting today, or skipping it?
<cjwatson> Short-staffed
<infinity> (Given the US holiday, plus doko may already be in flight, etc)
<infinity> Kay.
<infinity> I'll set an alarm. ;)
<infinity> 'Night.
<cjwatson> Sleep well
<infinity> cjwatson: Might want to sru-accept that too, for the bug.
 * infinity really sleeps now.
<cjwatson> Oh yes
<cjwatson> Done
<davmor2> cjwatson: are the mini iso's still being spun I want to get this machine on Quantal but can't with ubiquity so though I'd give mini iso a spin rather than download alternate (if it is still being made)
<cjwatson> Of course
<cjwatson> They're a product of debian-installer builds
<davmor2> cjwatson: cool I'll grab one of those then thanks :)
<doko> infinity, still here, leaving tomorrow at 4:30am
<zul> slangasek: afaik adam_g is validating glance/keystone but he has the day off today
<ogra_> infinity, hmm, still no mx5 images ?
<infinity> ogra_: Don't look at me, you're the one who's been doing the images. ;)
<ogra_> well, i didnt do anything specific to mx5
<ogra_> ubuntu                  daily-live              quantal-                amd64 amd64+mac armhf+mx5 armhf+omap4 armhf+omap i386 powerpc
<ogra_> thats what we have in default-arches
<infinity> I see a successful livefs build.
<ogra_> but somehow only omap and omap4 come out of this
 * infinity checks cd logs.
<ogra_> and yeah, seems to be successfull, there is no mail
<infinity> No script to make CDs bootable for armhf+mx5 ...
<infinity> And, indeed, mx5 has a post-boot, but no boot.
<ogra_> Making the binary CDs bootable ...
<ogra_> No script to make CDs bootable for armhf+mx5 ...
<ogra_> make: *** [/srv/cdimage.ubuntu.com/scratch/ubuntu/daily-live/tmp/quantal-armhf+mx5/bootable-stamp] Error 1
<ogra_> bah, you were faster :P
<ogra_> hmm, just a cp boot-armhf+omap boot-armhf+mx5 and adjusting the SUBARCH var should be enough
<infinity> Does it really do nothing?
<ogra_> it copies kernel and initrd  around iirc
<ogra_> ah, only the kernel
<infinity> Ahh, yeah, that should do, then.
<infinity> Shall I?
<infinity> Actually, SUBARCH and FLAVOUR are obviously not being used anyway.
<infinity> Given that omap4 is a symlink to omap. :P
<ogra_> oh, right, thats from an older iteration
<infinity> So, we could probably just add more symlinks.
<infinity> Although...
<infinity> It claims to be looking in SUBARCH/cdrom/ ...
<infinity> Does that mean the omap4 images have omap kernels copied to them, but no one's noticed because post-boot fixes it all anyway? :P
<ogra_> which is a bit nonsense ... given we store in arch+subarch
<ogra_> rrrright ...
<ogra_> we shouldnt tell paolo that he uploades unused omap4 kernels since two years then ;)
<infinity> Indeed.
<cyphermox> ^^ software-properties: ported to python3; needs cloud-init and orchestra to adjust Depends for the right package that carries add-apt-repository now. working on it.
<ogra_> well, i think the link is sufficient
<ogra_> seems to work with omap4
<infinity> ogra_: Yeah, I'm trying to trace *why* it works for omap4 before I do it. ;)
<davmor2> cjwatson: well that worked I now have a Quantal install :)
<cjwatson> Cool
 * ogra_ notices that jibel had an "ulimate" morning this morning ... oh my, so many duplicates
<infinity> ogra_: So, entertainingly, I was right.  The boot script is copying the omap3 d-i kernel/initrd for both flavours.  And then we just overwrite it in post-boot. :P
<ogra_> lol, ok
<ogra_> we should just drop the code then
<infinity> ogra_: So, yeah.  Just copying or symlinking it will "work" for mx5 too, but some day, we should tear out the useless.
<ogra_> i think that script stems originially from my very first live image attempts
<infinity> ogra_: I don't want to do too much culling right now, cause I'll get cut-happy, and I haven't slept.
<ogra_> back then it was actually split in two and the first one created the partition image
<cjwatson> Oh man, API queue is so much faster than the LP script
<ogra_> infinity, go to bed, i'll care
<infinity> ogra_: That works for me.
<ogra_> :)
<infinity> cjwatson: That makes up for kernel NBS removals taking half an hour. ;)
 * ogra_ wonders if ubiquity should be able to work on a serial port if the right preseeding is set 
<cjwatson> infinity: It's a tradeoff between startup time and API request time
<ogra_> (i know oem-config works but never tried ubiquity itself)
<cjwatson> Each individual request is slower, but if you run something that only needs a couple of requests, that's utterly dominated by the 10+-second startup time of execute_zcml_for_scripts or whatever it is
<cjwatson> If I can ever figure out how to make status=["Published", "Pending"] work then that would help too
<infinity> cjwatson: Yeah, the startup time of those LP scripts was abysmal, no argument here.
<infinity> cjwatson: And now that remove-package outputs often enough for me to not get bored, I don't really care that it's slow on large sets.
<infinity> If there's anything programmers are good at, it's watching scrolling text in their peripheral vision.
<cjwatson> It's a bit annoying that there's no way to make a bulk query for a load of package names.
<cjwatson> That might be easy to add if I ever get bored (not likely).
<infinity> Anyhow.  I completely failed to nap before the meeting, despite a valiant effort to do so, so I might go flip a coin between passing out for a bit or heavy caffeination.
<infinity> If I don't come back, the former won.
<infinity> If I never come back, the latter may have won.
<Laney> bah, struck again by bug #888665
<ubot2> Launchpad bug 888665 in launchpad "Backports can't build-depend on other backports" [Critical,Triaged] https://launchpad.net/bugs/888665
<Laney> after figuring out the wobbly stack of backports required to get ben to lucid
<micahg> cjwatson: thanks for clearing precise-backports
<Laney> I suppose I can apply a wobbly patch for precise instead to avoid having to backport tyxml
<slangasek> zul: glance/keystone> ok, cool
<slangasek> zul: I also have the day off today ;)
<zul> slangasek: enjoy your pouring tea in your boston harbor day :)
<jamespage> please could the binary NEW packages for libunwind be accepted into quantal - ta
<stgraber> after a few succesful tries, I've now updated nusakan to build Edubuntu DVD for i386, amd64 and armhf+omap4 daily. We've cut around 30-45min of our build time with another change this cycle so I won't change the cron as it should still fit. We can always update later on if that's a problem.
<highvoltage> nice.
<phillw> stgraber: I just caught the end of your meeting. The Lubuntu-QA team are always 'up' for a challenge in helping another team out. Feel free to give us a poke. https://wiki.ubuntu.com/Lubuntu/Testing
#ubuntu-release 2012-07-05
 * infinity grumbles about people packaging new libraries without multi-arching them.
<phillw> infinity: I know little apart from a 1 hour session of multi-arching an rpm (Red Hat course), but I do agree with you 100%.
<infinity> phillw: RedHat doesn't do multiarch, I suspect we're talking about two different things.
<phillw> infinity: okies, I was thinking about when I did the building of an .rpm (similar to a .deb)
<infinity> phillw: Yes, I know what RPM is. ;)
<phillw> lol
<infinity> phillw: But "mutliarch" refers to coinstallable packages from different architectures based on unique paths.  RedHat doesn't do that.
<infinity> So, I assume you were perhaps referring to "making it build on more than one arch", which many RH/Fedora people never bother to think about (since they have a "primary arch / everyone else we don't care about" split), but it sort of the status quo for Debian and Ubuntu.
<phillw> reminder to self... leave the devil of the details to the devils :) I was just trying to get a better understanding of how these things are done.
<phillw> infinity: in the brief hour I had on it, we could chose to build i386, X64 or for both. It's not a big part of the RHCE course, we just need to be aware of the difference of building for one arch, and the use of multiarch as per .prm
<phillw> *rpm*
<Daviey> cjwatson: Hey, does sharand still belong in multiverse ?
<cjwatson> Daviey: well, it's in Debian non-free; unless we have some reason to care I'd rather they moved it first
 * ogra_ glares at nusakans processlist
<Daviey> cjwatson: ah, i see.. I just saw references of the licence change..
<ogra_> cdimage   6104  6101  0 08:31 ?        Ss     0:00 /bin/sh -c DIST=precise for-project ubuntu cron.daily; PROPOSED=1 buildlive ubuntu daily-live precise && DIST=precise for-project ubuntu cron.daily-live
<ogra_> ...
<ogra_> dimage   5494  5480  0 08:42 ?        S      0:00 ssh -n -o StrictHostKeyChecking no -o BatchMode yes buildd@celbalrai.buildd /home/buildd/bin/BuildLiveCD -l -A armhf -s mx5 -p -d precise ubuntu
<ogra_> ...
<cjwatson> Yeah, AFAICS that made it distributable but not free
<ogra_> why the heck is it building precise live images :/
<cjwatson> in general?  because we will care about a point release in the near future
<ogra_> well, i only see mx5 atm
<cjwatson> for mx5?  that is a little confusing
<ogra_> massively, yes
<ogra_> see the line above
<ogra_> ogra@nusakan:~/branches/cdimage-private$ CDIMAGE_ROOT=/srv/cdimage.ubuntu.com/ ALL_DISTS=precise bin/default-arches ubuntu daily-live precise
<ogra_> amd64 amd64+mac i386 powerpc
<ogra_> seems ok though
<cjwatson> Yeah, I'm just digging now
<ogra_> really bad is that it runs 1h after the quantal live build starts ... so it will block the whole until all arm builds are done
<cjwatson> I'm fixing it now
<ogra_> what is it ?
 * ogra_ is bothered that he couldnt find a cause
<cjwatson> DIST isn't passed through to default-arches
<ogra_> ouch
<cjwatson> Because the buildlive interface is anomalous and takes it on the command line
<cjwatson> I think I'm just going to regularise the buildlive interface
<ogra_> yeah
<cjwatson> Though I guess I could just set DIST earlier
<cjwatson> actually yeah, that would work
<ogra_> shouldnt BuildLiveCD set it ?
<ogra_> or is that to late
<cjwatson> er that's the next layer down and doesn't help
<ogra_> ah, k
<cjwatson> FWIW the way I investigated this was to make a copy of buildlive and add 'echo "$ARCHES"; exit 0' just after sourcing config
<cjwatson> then I could sh -x it
<ogra_> ah !
 * ogra_ *again* didnt think  of -x
<ogra_> damned
<cjwatson> yeah, well, it only helps if you have a version that won't go on and build stuff :)  hence the temp copy
<cjwatson> fixed now; although I do think we need to rebalance the builders again - what happened to different subarches being on different livefs builders?
<cjwatson> I guess that died when we shifted off the beagle kennels
<ogra_> there is nothing to rebalance with
<ogra_> we only have celbalrai atm
<ogra_> i was told elmo works on getting another mandabox up though
<ogra_> and that we should get balanced builders from that setup then
<ogra_> not sure where that stands
<cjwatson> fair enough
<Daviey> cjwatson: Do you have some capacity today to look at squashfs for server?
<cjwatson> Daviey: maybe; how far have you guys got so far without me?
<Daviey> cjwatson: It feels barely off the starting block.. i was doing debug builds on nectarine.. but when tested, it didn't seem to provide useful info, or find the squashfs.. but did have it on the image.
<Daviey> cjwatson: Can we cover again what changes you thought were required.
<Daviey> (it's only really me been working on it)
<cjwatson> In that case I might as well JFDI I guess
<cjwatson> although *nectarine*?  why that?
<cjwatson> it shouldn't be involved
<cjwatson> DYM nusakan?
<cjwatson> I see http://people.canonical.com/~ubuntu-archive/livefs-build-logs/quantal/ubuntu-server/latest/livecd-20120704-amd64.out
<cjwatson> we'll need to substitute live-installer for bootstrap-base, which is a bit tricky to do without committing all image builds to it; I might do some kind of temporary hack in cdimage for that
<cjwatson> huh, why did that end up in NEW - it was already in -proposed
<cjwatson> oh, blast, I didn't realise that was part of a transition of some kind
 * cjwatson peers
<cjwatson> I hate this crappy half-use of proposed
<cjwatson> OK, this is crazy, there's no way that actually dropping python-software-properties can work in the short term given some of its rdepends (cloud-init, packagekit-backend-apt, ubuntu-orchestra-client-juju) - I'll revert the packaging to produce both
<seb128> cjwatson, cyphermox said those just need their depends adapted
<seb128> cjwatson, he said he would chase people down today, he couldn't yesterday (4th of july)
<cjwatson> I'm going to revert it anyway for now to make things smoother
<cjwatson> not convinced of the correctness of the end of this port either given that some files have pretty fatal pyflakes errors
<cjwatson> in any case there's no reason to do a rough transition when a smooth one is possible
<Daviey> < cjwatson> DYM nusakan?
<Daviey> yes, sorry.
<cjwatson> Daviey: do you have a decision on what you want to be in the squashfs?  I assume that server being what it is you probably don't want to ship everything on the CD in the squashfs and would like some other things to be shipped as debs?
<ogra_> is ubiquity-dm known to have any issues atm ? on omap images i end up in a live session (and get an apport popup for ubiquity-dm)
<cjwatson> Daviey: and do you want broadly the same set of packages to be on the converted image, one way or another?
<stgraber> ogra_: not sure it's known, but I see that here too (omap4)
<ogra_> k
 * ogra_ doubts he can run an install on a beagle if the live session already ate all my ram
<stgraber> ogra_: installing will fail anyway because of ubiquity exploding when installing langpacks
<ogra_> ah, crap, k
 * ogra_ pulls a netboot image then
<ogra_> (and dont tell rick :P )
<Daviey> cjwatson: Yes.. just server in the squashfs, server-ship still as debs.. is that possible?
<cjwatson> should be
<cjwatson> first attempt produced a tiny image so I obviously got things wrong
<ogra_> geez, on a begle the netboot installer on fb really hurts my eyes ...  somehow the beagle interprets violet backgrounds as bright neon pink
<cjwatson> ogra_,infinity: do you think I'm OK to add the server seed onto the ubuntu-server preinstalled images, as a side-effect of what Daviey's asking for?  i.e. http://paste.ubuntu.com/1076482/
<Daviey> cjwatson: I managed to create a 400MB image IIRC
<ogra_> cjwatson, well, i think we would like to drop preinstalled for server once Daviey is done ... and switch arm to the new installation too
<ogra_> so it shouldnt really matter
<ScottK> cjwatson: I recall advice from you not to worry overmuch about packages that weren't useful in Ubuntu, but were sync'ed from Debian because it wasn't worth the trouble to maintain the blacklist.  Now that the blacklist is more self service (for me anyway, I don't recall who can access it), is there a problem with being more expansive about stuff we remove (specifically in this case chkconfig, which doesn't work with upstart and won't)?
<cjwatson> who> ~ubuntu-archive.  That's probably OK - just try to keep blacklisting to stuff that will never be useful, rather than that is a bit busted at the moment
<ScottK> OK.  Thanks.
<cjwatson> In particular there's no need to blacklist for fakesyncs or already-removed-from-Debian or such - though you probably aren't in the habit of doing that since you've only used the new sync/removal tools
<ScottK> Right.  No, I haven't.
<tumbleweed> cjwatson: talking of fakesyncs, do you do them when auto-sync reports that they need to be done?
<tumbleweed> or do we have a report listing teh packages out of sync because of tarball mismatches
<cjwatson> tumbleweed: I just do them
<cjwatson> It dodesn't list them separately but I generally notice
<tumbleweed> as long as tehy aren't going unnoticed, that's what matters
<cjwatson> Let me do a final auto-sync for quantal just to check
<infinity> cjwatson: If preinstalled sticks around, no, that change would be "wrong", IMO.
<infinity> cjwatson: At least, I assume that "server" is being added to the squash build as the removable "live" part?
<infinity> cjwatson: If not, then Daviey needs a talking to, cause not every server install in the world should have apache and mysql by default.
<ogra_> in the preinstalled case i really dont care
<ogra_> assuming we actually drop them anyway
<infinity> ogra_: If it sticks around, I do. :P
<infinity> ogra_: If the server live experiment works out, then yeah, we'll drop preinstalled and switch to that.
<infinity> (At which point, I won't care)
<ogra_> well, right, but the initial idea of offering people a minimal dev system through the arm server images is moot anyway
<infinity> ?
<ogra_> the download is to big, most people use netinst anyway
<ogra_> and i dont really know any actual "server" users
<infinity> Oh.  I thought you meant it wasn't "minimal" enough, which it is.
<infinity> But yeah, the image is large.
<ogra_> right, and because it is large we can as well preinstall some server apps
<ogra_> i wouldnt mind
<infinity> I would.
<infinity> And it violates a longstanding Ubuntu policy.
<ogra_> to have useful bits preinstalled ?
<ogra_> honestly i think though that we should probably drop server completely and resort to netinst
<ogra_> (for arm that is)
<cjwatson> infinity: server isn't what you think it is
<cjwatson> infinity: are you thinking of server-ship?
<cjwatson> the server seed is what we install by default on servers
<ogra_> doesnt server define a set of apps that get installed ?
<cjwatson> go and look :)
<infinity> cjwatson: Oh, I misplaced my ^
<infinity> Note, selecting 'serverstats' for regex '^server'
<infinity> ^-- That doesn't end well.
<cjwatson> hah
<infinity> cjwatson: In that case, yeah, it should match on preinstalled, for all that it doesn't matter much either way.
<ogra_> oh, it does install additional apps ... !
<ogra_> 10 of them :P
<infinity> Yeah.
<ogra_> right, thats fine i guess
<infinity> Hasn't kirkland been gone long enough that we can drop byobu from the server seed now? ;)
<ogra_> though i would still like to drop arm server images :)
<infinity> ogra_: I'd like to drop pretty much all ARM images other than our "demo" desktop image for the blessed platform of the week (which is still omap4 right now).
<infinity> ogra_: But we've had this discussion.
<ogra_> indeed
<infinity> And given that netboot is the server experience we're giving people with real server hardware, it seems silly to offer something different for people without.
<ogra_> yeap
<infinity> We really should discuss this with a broader group of people before I just go mad and turn all the images off.
<ogra_> we should, i'll prepare a mail for tomorrow to ubuntu-devel
<ogra_> (and will ping the eilt people about it)
<ogra_> lets see what the feedback is
<infinity> Pass it by me before you send it?
<ogra_> sure, np
<infinity> I'll pass it through my "nutty German" filter. ;)
<infinity> *duck*
<ogra_> haha
<stgraber> cjwatson: ^ there you go
<ScottK> Does this mean ABI compatibility is hard: http://www.technolog.msnbc.msn.com/technology/technolog/why-some-your-recently-updated-iphone-ipad-apps-are-crashing-864534
<Daviey> cjwatson: What is the current status of the squashfs.. is there anything i can help with?
<Daviey> ScottK: Is that why we opted out of it? :)
<infinity> cjwatson: Hrm.  I just accidentally removed a package without a comment.  I'd perhaps argue that remove-package shouldn't allow that.
<infinity> cjwatson: Thoughts?
<slangasek> infinity: I thought remove-package /didn't/ allow that...?
<infinity> slangasek: The LP version might not have, the API one sure just did.
<slangasek> cute
<cjwatson> Daviey: I ran out of time today but will continue tomorrow; I've done some necessary seed mangling, need to get the correct set of seeds onto the image
<cjwatson> stgraber: ust> thanks
<cjwatson> infinity: feel free to fix the client to prevent that - or submit an LP branch to prevent it if you feel enthusiastic
<cjwatson> though pretty sure the former will be quicker :)
<Daviey> cjwatson: thanks muchly.. if i can help, please do ask.
<infinity> cjwatson: Yeah, fixing the client seems reasonable for now.  I'm not sure the API should flat-out block it anyway (though maybe it should).
<cjwatson> Daviey: it shouldn't be *desperately* hard from here
<cjwatson> Daviey: but I've blocked out a couple of hours for it on my calendar anyway to try to make sure I don't forget
<Daviey> cjwatson: really appreciate your effort on it.
<Daviey> cjwatson: I'd like to work out where i was being daft tho.
<cjwatson> main thing was probably making sure that the image has live-installer.udeb on it rather than bootstrap-base.udeb
<cjwatson> at a guess
<cjwatson> which is not entirely obvious, but I have a hack in place to let me produce images that way
<Daviey> ah!
<Daviey> that probably explains why it simply wedged with no useful debug
<cjwatson> right
<cjwatson> hopefully tomorrow it'll be debug-into-existence territory
<Daviey> heh
<cjwatson> but I must sleep now
<Daviey> thanks cjwatson !
<cjwatson> three LP branches landing in parallel now that should give us the final bits of API queue
<cjwatson> then I get to remove 2000 or so lines of code once that's deployed :)
#ubuntu-release 2012-07-06
<infinity> RAOF: I know it's not your "day", but if you could look at the ruby1.9.1 I popped into precise-proposed, that would be lovely.  Should be the easiest review EVER.
<RAOF> infinity: No worries.
<RAOF> Maaaate.
<infinity> Hahaha.
<infinity> Thorpie says you're fully sick.
<RAOF> Incidentally - ruby needs not just a separate source for each major version, not just a separate source for each minor version, but a separate source for each *nano* version?
<RAOF> That's some high-stability language design, there.
<micahg> RAOF: they had to do something to stand out from PHP
<micahg> infinity: you feel like reviewing stuff in precise-backports NEW?
<infinity> RAOF: It's kinda special.
<infinity> micahg: I can quickly look before I sleep.
<micahg> infinity: not worth losing sleep over
<infinity> Laney: Your backport of ben in precise-backports claims in the changelog that it's for lucid. :P
<infinity> Laney: pls to reupload.  kthx.
<infinity> micahg: Done.
<micahg> infinity: thanks
<RAOF> Dear launchpad: FASTER!
<infinity> RAOF: Diff's there now. :P
<RAOF> Huh. I wonder why queuediff isn't picking it up.
<infinity> Dear queuebot, why did you just claim two of those were rejects?
<infinity> And again... WTF?
<infinity> linux 3.2.0-27.42 in precise (Cannot copy DDEBs to a primary archive)
<infinity> Did someone twiddle the kernel PPA?
<Laney> infinity: there you go. well spotted
<ogra_> grr
<ogra_> still no armhf+mx5 images
<xnox> ogra_: for the release meeting - foundations team "broke dpkg & fix it; broke ubiquity/daily-cds & fix it"
<xnox> =)))
<ogra_> heh, i can totally commit to the latter one as well :)
<ogra_> (with the addition of arm indeed)
<xnox> =)))))))
<ogra_> Making the binary CDs bootable ...
<ogra_> Running tools/boot/quantal/boot-armhf+mx5 1 /srv/cdimage.ubuntu.com/scratch/ubuntu/daily-live/tmp/quantal-armhf+mx5/CD1
<ogra_> ls: cannot access mx5/cdrom/vmlinuz*: No such file or directory
<ogra_> GAH !!!
<ogra_> infinity, so the copying of the omap kernel apparently is necessary in debian-cd, seems there is no mx5 one to copy around :P
<xnox> =)))))))))))))))
<cjwatson> oh blast, I had even read the conversation about why linux was rejected
<Daviey> cjwatson: Hey, Can i check in on the status of the squashfs fun?
<cjwatson> mostly distracted today by helping to fix a critical bug in ubiquity; but last status is that I uploaded livecd-rootfs to fix up the squashfs contents a bit, and was waiting for that to publish before trying again
<cjwatson> considering something like http://paste.ubuntu.com/1077995/ to fix the pool contents
<cjwatson> hm, that's not right though ...
<jibel> Can we have a new set of desktop images with ubiquity 2.11.9. We'd want to get them tested before the week end.
<cjwatson> jibel: not before it's published :)
<cjwatson> you'll have them as fast as it's actually possible
<jibel> cjwatson, thanks :)
<Daviey> cjwatson: Ok, super.. thanks
<cjwatson> -rw-rw-r-- 1 cdimage cdimage 614772736 Jul  6 13:29 /srv/cdimage.ubuntu.com/scratch/ubuntu-server/daily-live/debian-cd/i386/quantal-live-i386.raw
<cjwatson> more sensible size now at least
<cjwatson> rebuilding the squashfs to get the server task in there
<cjwatson> then I'll try new ISOs which might be worth me testing
<cjwatson> though I guess I can rsync this one in advance ...
<Daviey> cjwatson: that sounds dandy... separately, is it vialble to expose the squashfs on cdimage?
<cjwatson> possible but why?
<Daviey> cjwatson: mirror to deployment servers for netbooting
<cjwatson> Daviey: ok - it's certainly easy enough if there's a reason, since we already do it for http://cdimage.ubuntu.com/livecd-base/current/
<Daviey> cjwatson: hah
<infinity> ogra_: Well, err, copying none around is the sane thing to do.  But yes, s/omap/mx5/ would break. :P
<jdstrand> infinity: hey, when you have a moment, can you bin deNEW ufw and put python-ufw in main? This should be the last of me pestering you for a while :)
<cjwatson> so, there's a new queue tool in lp:ubuntu-archive-tools now, which you're welcome to try out
<cjwatson> some caveats
<cjwatson> making override-source/override-binary work is awaiting the next Launchpad deployment
<infinity> By which, you mean, it doesn't do the one thing I use q on cocoplum for? ;)
<cjwatson> fetch looks like it works, but actually doesn't (it fetches the .changes correctly, and a load of error pages for everything else) - I have a branch up for review to fix that
<cjwatson> yeah, well, it should do by Monday :)
<cjwatson> the rest of the tool should work barring trivial UI glitches like showing all the dates as "TODO"
<cjwatson> mostly I just wanted to get it committed so that I wouldn't have to refer to a pastebin in my QA plans
<cjwatson> if you fancy doing things like improving tools to accept things for themselves rather than sending you to the web UI, that should be possible with the same API
<cjwatson> though in most cases that will currently involve polling until the copy job actually gets processed
<cjwatson> usual script/API performance tradeoff, much faster to start up, takes a bit longer per item to walk down the queue
<cjwatson> I plan at some point to fix some of queue's more idiotic long-term UI warts
<cjwatson> so don't start scripting around its output or anything, use the API if you're going to do that :)
<infinity> Mmkay.  I have no immediate plans to fix anything, except for small cosmetic annoyances.
<infinity> Oh, I committed the "must provide a comment" fix to remove-package, did you have a look at that for sanity?
<infinity> Or for style, even.  I can never decide how to do nested quotes in Python.  '/"/"""/\" ... So many options.
<cjwatson> infinity: looks fine, though I tweaked for line length
<infinity> Picky. ;)
<infinity> Thanks.
<infinity> My terminals default to 100 chars wide (for bizarre reasons), so I tend to be insensitive to 80char limits sometimes.
<cjwatson> nested quotes - whatever, I might have ended up with """ at some point but if there's only one of ' and " inside it makes sense to use the other one
<infinity> jdstrand: Done.
<infinity> cjwatson: Your partman-target SRU.  Why only address /var/lib/{mythtv,mysql}?
<infinity> cjwatson: Isn't /var/lib in general user state we don't want to lose?
<jdstrand> infinity: thanks!
<infinity> cjwatson: I assume the same issue would hit postgres, and other packages?
<infinity> cjwatson: Or, rather, if you're trying to get a sane start point, perhaps you want to be inclusive rather than exclusive (ie: clear out dpkg and apt, but leave unknown stuff in /var/lib alone?)
<cjwatson> infinity: I've never been at all happy with this entire system, so don't look at me to justify it :P
<cjwatson> infinity: we want to avoid leaving around previously packaged but unowned files that will never be cleaned up
<cjwatson> or that will confuse packages on the new system
<cjwatson> maybe a rewrite would look at dpkg files state on the old system as some kind of cue or something, but there are lots of unowned files.  hard to get right in shell.  not sure about whitelisting /var/lib, there's a fair bit of other stuff in there ...
<cjwatson> for instance, I don't think whitelisting /var/lib/binfmts/ would go well
<cjwatson> or /var/lib/initramfs-tools/, that seems like it'd create some confusion
<infinity> cjwatson: Hrm, perhaps.  Well, this is an improvement over the current situation, in that it fixes the specific bug, I guess.
#ubuntu-release 2012-07-07
 * Elbrus is working on bug 914746 and thinks it is regression from bug 906773
<ubot2> Launchpad bug 914746 in cacti "cacti SNMP verbose query PHP error" [Undecided,Fix released] https://launchpad.net/bugs/914746
<ubot2> Launchpad bug 906773 in cacti "CVE-2011-4824 SQL injection issue in auth_login.php" [Medium,Fix released] https://launchpad.net/bugs/906773
<Elbrus> did I register this correctly in the later bug?
 * Elbrus is creating a debdiff now, and will test this in his test environment, both before and after the very small fix
#ubuntu-release 2013-07-01
<doko> cjwatson, infinity: do you know what is going on with the pycode-browser build? it seems to be progressing, but what exactly does it do? not many packages with +2d build time ...
<StevenK> Maybe it builds libreoffice internally to process some docs ...
<cjwatson> infinity: autopkgtest> Hm.  You probably want Jean-Baptiste to debug that - proposed-migration delegates most of that stuff to adt-britney.
<cjwatson> doko: First I've heard of it
<cjwatson> doko: It only took two minutes to build in raring
<cjwatson> Has TeX got exponentially slower or something?
 * ogra_ still scratches his head over copy_exec ... rolling an initrd on the builder omits all the linked libs of adbd while they get pulled in during a local build inside a chroot  http://paste.ubuntu.com/5813896/  vs  https://launchpadlibrarian.net/143820277/buildlog_ubuntu-saucy-armhf.ubuntu-touch-generic-initrd_0.5_UPLOADING.txt.gz
<ogra_> (in both cases there are no virtual filesystems mounted inside the chroot)
<doko> cjwatson, hmm, it's an endless loop
<JackYu> cjwatson: hi, may I know how did you customize the content of buttons 'Try Ubuntu' and 'Install Ubuntu' when installing? I remember you changed it to 'Install UbuntuKylin' and 'Try UbuntuKylin'.
<JackYu> cjwatson: we are trying to customize the buttons locally.
<cjwatson> I don't remember specifically but that change is unlikely to help you in making more invasive customisations, since I expect all I did was arrange for the images to properly know that they were called UbuntuKylin
<doko> cjwatson, seen in unstable too, filed issue, and leaving that as is for now
<cjwatson> ok
<JackYu> cjwatson, well, thanks:)
<cjwatson> adam_g: is bug 1188788 meant to still be open for saucy?
<ubot2`> Launchpad bug 1188788 in quantum (Ubuntu) "Meta bug for tracking Openstack 2013.1.2 Stable Update" [Undecided,New] https://launchpad.net/bugs/1188788
<xnox> Please accept above upstart ^ as it fixes a regression currently in raring-proposed version of upstart (1.8-0ubuntu1.1) bug 1195955
<ubot2`> Launchpad bug 1195955 in upstart (Ubuntu Raring) "Setting up upstart (1.8-0ubuntu1.1) ... dpkg: error: unknown option --compare-version" [High,Triaged] https://launchpad.net/bugs/1195955
<xnox> fix committed in lp:ubuntu/upstart and will be part of the eminent 1.9 release.
<xnox> (upload).
<jbicha> hi, could Ubuntu GNOME get an isolinux screen like Kubuntu's? http://www.thecodingstudio.com/?linux&release=Kubuntu%2013.04
<cjwatson> Yeah, I was going to take care of that
<jbicha> I wonder if the other flavors would be interested in doing that too
<cjwatson> I think most of the other flavours have already stated an explicit preference one way or the other
<cjwatson> I just never got round to checking with Ubuntu GNOME
<jbicha> we were using the other thing because a purple boot screen just didn't make sense; black will work though
<cjwatson> jbicha: Um
<cjwatson> jbicha: What I understood from darkxst was that it was about showing the icon while waiting for a keypress, not about the colours
<cjwatson> What *exactly* are you asking for here?
<jbicha> where does the color come from? I just didn't want a purple version since we currently use blue for plymouth & the desktop wallpaper
<cjwatson> 2013-06-26.log:15:18 <cjwatson> darkxst: so, I'm not sure what you mean about only getting the text-based screen - do you mean that you want the same kind of behaviour that's in Ubuntu where you just get an icon until you press a key?
<cjwatson> 2013-06-27.log:00:43 <darkxst> cjwatson, yes basically, apparently the text-based menu is not accessible for screen-readers
<cjwatson> So it looks like the two of you are actually asking for different (but non-conflicting) things
<jbicha> the Kubuntu screenshot showed a black background for the press-a-key-for-a11y-and-more screen
<cjwatson> I can certainly fix up the colours however you like
<cjwatson> You'd actively prefer black to blue?
<jbicha> oh, we should probably do the same blue as our grub/plymouth-text then; I didn't know how hard it was to customize the screen
<cjwatson> Hm, I can't find where Kubuntu sets it to black ...
<cjwatson> jbicha: If you want to change colours, I'll need modified versions of the ubuntu.pcx and ubuntu.png files in lp:~ubuntu-cdimage/debian-cd/ubuntu, taking care to preserve the same image size, bit depth, and positioning
<cjwatson> Ah, Kubuntu does it by way of kubuntu-blank.pcx there
<cjwatson> Crude but effective :)
<jbicha> yeah I'm happy with taking the easy route for now by just copying what Kubuntu does :)
<cjwatson> Disregard the ubuntu-touch build failure just now - dealing with it
<cjwatson> jibel: there seem to be loads of autopkgtests stuck in RUNNING again - is that known?
<doko> heh, wanted to ask that too this morning, and forgot ...
<doko> cjwatson, I do want to remove gdc-4.4, gdc-v1, and every binary built using these (e.g. a7xpg) on powerpc and armhf.  D v2 with libphobos is only supported on ix86 for now
<jibel> cjwatson, there has been failures yesterday, but pitti restarted the tests, that should have unstuck autopkgtests. I'm checking what is wrong.
<cjwatson> doko: So I make that  a7xpg gunroar ii-esu mu-cade parsec47 plplot projectl tatan titanion torus-trooper tumiki-fighters val-and-rick xmbc.  All of those are OK except for plplot, which has further rdeps and where D is only a fairly insignificant part; could you instead change that to only use D on architectures where it's supported?  (Part of the necessary changes are there already.)
<cjwatson> s/xmbc/xbmc/
<cjwatson> (Those are source package names rather than binaries.)
<doko> cjwatson, ok, updating plplot
<cjwatson> jbicha: So, yeah, I can't do this purely by cloning from Kubuntu, because I need a version of the images with a matching colour background
<cjwatson> (as mentioned above)
<cjwatson> You might as well do that with whichever colours you actually want
<doko> plplot (5.9.9-5ubuntu1) saucy; urgency=low
<doko>   * Adjust PYTHON_LIBRARY for multiarch Python.
<doko>   * Disable the Ada and D bindings for now, as they won't build.
<doko>  -- Colin Watson <cjwatson@ubuntu.com>  Thu, 30 May 2013 13:47:48 +0100
<doko> ;-P
<cjwatson> Indeed, that's why I knew it was partly done
<cjwatson> But I probably didn't bother disabling the build-dep
<cjwatson> When I did that, the D bindings didn't even build on x86, never mind anything else
<cjwatson> And I thought it likely that your reaction would be "please send a patch" :-)
<doko> ok
<doko> heh
<cjwatson> If you actually care about D, by all means see if the bindings build on x86 now ...
<doko> am I known for that?
<cjwatson> You're known for not wanting to necessarily maintain all the strange corners of the toolchain entirely by yourself ;-)
<doko> looking at that.
<doko> well, yes, ibuklaw is doing this
<doko> and had done a first attempt at upstreaming
<doko> bah, plplot fails for other reasons ...
<doko> [ 18%] Building CXX object bindings/qt_gui/pyqt4/CMakeFiles/plplot_pyqt4.dir/sipplplot_pyqt4cmodule.cpp.o
<doko> In file included from /scratch/packages/tmp/plplot-5.9.9/debian/build_tmp/bindings/qt_gui/pyqt4/sipplplot_pyqt4cmodule.cpp:7:0:
<doko>  #include <sip.h>
<doko>                  ^
<doko> compilation terminated.
<doko> ScottK, ^^^ ? any idea?
<ScottK> No.
<ScottK> I've had to rebuild most all of the sip4 using packages in both Debian and Ubuntu and haven't seen anything like that.
<rsalveti> infinity: hey, if around, mind accepting ^ (amd64 one will take a while still), this is to provide a new libandroid-properties and libhybris-utils to support getting/setting android properties
<rsalveti> stgraber: slangasek: anyone able to help with ^? seems infinity is not around today
<slangasek> rsalveti: happy to help, I have a work item expressing my interest in helping with NEW processing for this and no one has taken me up on it ;) lookin now
<rsalveti> slangasek: cool, thanks
<slangasek> interesting, why is libandroid-properties the only lib with its own binary package when all the others are in a single 'libhybris' binary?
<slangasek> the libandroid-properties1 looks correct per se, but it's probably worth understanding whether we should expect further package splitting or anything
<rsalveti> slangasek: basically because the split will happen when I rebase from upstream again
<slangasek> ok
<rsalveti> and would need changes at the other touch related packages as well
<slangasek> will the upstream rebase bring new sonames?
<rsalveti> will do the rebase after we officially move to the flipped images
<slangasek> ack
<rsalveti> slangasek: not that I know
 * slangasek looks blankly at ubuntu-archive-tools, which wants him to reauthorize
<slangasek> ... and fails to launch the browser
<slangasek> rsalveti: accepted
<rsalveti> slangasek: thanks!
<infinity> rsalveti: National holiday here in Canada, but glad vorlon got you sorted.
<slangasek> infinity: happy Canadian Cinco de Mayo
<infinity> slangasek: Uno Julyo.
<slangasek> infinity: primer de julio, close enough ;)
<bdmurray> cjwatson: could you re-review https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/phased-updater/+merge/171142?
<infinity> slangasek: :P
#ubuntu-release 2013-07-02
<slangasek> infinity: harmoney suggests that Canada Day should be renamed Cinq Mai on principle
<RAOF> Looks like that hybris upload generates packages with broken dependencies ;(
<RAOF> Oh, no. It's because Mir's armhf build infrastructure is stupid.
<rbasak> Daviey: ^^ - as we discussed last week, this trumps 1.6.5-1ubuntu1.1 in precise-proposed and I'll verify both bugs at once.
<tseliot> can an admin approve nvidia-graphics-drivers-319-updates in saucy please?
<tseliot> before linux 3.10 breaks the drivers it's supposed to replace
<ogra_> hmm, cadejo doesnt look happy ...
 * ogra_ sees 6 builds piled up on nusakan
<ogra_> P: Begin building root filesystem image...
<ogra_> Segmentation fault
<ogra_> Segmentation fault
<ogra_> P: Begin unmounting filesystems...
<ogra_> bah, sigh
<ogra_> (thats from the running build (lubuntu-ac100) )
 * ogra_ goes to ask IS to reboot 
<cjwatson> thanks
<ogra_> bah, no vanguard
<ogra_> lacking a vanguard i filed RT #62834
<psivaa> ogra_: cjwatson: is the above ^ the reason for saucy server images being delayed than usual?
<ogra_> psivaa, only affects armhf
<psivaa> ogra_: ok, thanks. just was curious
<cjwatson> psivaa: Yes
<psivaa> cjwatson: OK, thanks :)
<cjwatson> ogra_: (ubuntu-server builds armhf)
<ogra_> oh, indeed
<ogra_> cjwatson, shouldn't the ssh processes die if cadejo is rebooted ?
<ogra_> (the dangling ones on nusakan i mean)
<cjwatson> ogra_: They may only notice after some kind of timeout
<ogra_> ah, k
<cjwatson> Which should be five minutes
<cjwatson> Well, five minutes plus a bit, maybe
<ogra_> yeah, no hurry :)
<cjwatson> Actually it looks like fifteen minutes
<cjwatson> ServerAliveInterval=300 (due to BatchMode=yes) * ServerAliveCountMax=3
 * ogra_ finds it funny that zips are rsyncable just fine, but if a zip contains a tgz that was build --rsyncable this causes a complete download
<doko> infinity, cjwatson: I see libc++ in main, but no MIR. was this promotion intended? clang itself is fortunately still in universe
<ogra_> cjwatson, the .md5sum looks fine
<ogra_> (not to mention that sergiusens uploaded the change to SHA256SUM tonight though :) )
<cjwatson> doko: ?  https://launchpad.net/ubuntu/+source/libc%2B%2B/+publishinghistory says universe
<cjwatson> And all binaries still in universe too according to rmadison
<cjwatson> ogra_: Great
<cjwatson> ogra_: I am more than happy to drop the .md5sum generation code on request ;-)
<ogra_> bah, but rsync gets me weird results with the sumlink in place
<ogra_> *sym
<cjwatson> use -L
<ogra_> thx
<doko> cjwatson, ahh, in proposed component mismatches
<doko> o libc++: libc++-dev libc++1 libc++abi-dev libc++abi1
<doko>    [Reverse-Depends: Rescued from libc++, libc++-dev, libc++abi-dev]
<doko>    [Reverse-Recommends: libgmp-dev (MAIN)]
<doko> and apparently there is a bug, just flagging that as a dep on libc, not libc++
<cjwatson> doko: Oh, I thought you meant currently in main, not scheduled for promotion
<cjwatson> doko: Hmm
<doko> was confused myself. and still can't see where libgmp-dev gets this recommends ...
<doko> ahh, it does have Recommends: libstdc++-dev
<cjwatson> ambiguous virtual?
<doko> which is only provided by libc++-dev
<cjwatson> It's provided by libstdc++6-4.7-dev too
<cjwatson> But evidently germinate has to guess
<cjwatson> Let's see where I can insert a hint
<doko> maybe because the 4.8 packages is now libstdc++-4.8-dev, not having the soname in the package name?
<cjwatson> germinate couldn't care less about that
<stgraber> cjwatson: hey, so it looks like I'll need simg2img on nusakan in order to build the hardware dependent .tar.xz, wanted to check what's the standard process there. That tool is part of android-tools-fsutils which was introduced in raring, should I get that backported to precise in some IS PPA or just push a copy of the binary for now?
<cjwatson> stgraber: I don't mind if you use a local copy temporarily to unblock yourself, but please RT to get it into precise-cat
<cjwatson> (and installed on nusakan of course)
<stgraber> cjwatson: ok, I'll use a local copy for now, then check that a simple backport works and if it does, ask that IS does that in precise-cat.
<infinity> Hrm, looks like Chuck got impatient and decided that apache2 transition was happening NOW?
<infinity> zul: I hope you were prepared to actually do the whole apache2 transition, not just the merge...
<zul> infinity:  i am
<seb128> infinity, to be fair doko has been spending the day chasing people about their merges/build issues...
<seb128> infinity, that was one of those
<doko> infinity, better do it now than later. there is so much stuff in -proposed ...
<infinity> doko: It was something several of us were intentionally keeping an eye on until Debian had progressed a bit further with it.
<infinity> Lots of stuff in proposed isn't necessarily world-ending.
<bdmurray> cjwatson, slangasek: is there more reviewing of the phased-updater code to be done?
<cjwatson> Sorry, I dropped the ball slightly - I'll get to it by tomorrow morning latest
<bdmurray> cjwatson: no problem, I guess we are still waiting on someone reviewing your merge proposal anyway
<cjwatson> Afraid so
 * cjwatson pokes gently
<slangasek> which merge proposal?
<cjwatson> https://code.launchpad.net/~cjwatson/launchpad/copy-set-phase/+merge/170775
<cjwatson> I just poked about it on #launchpad-dev
<slangasek> ah, that one
<slangasek> so presumably you want someone other than me to review it ;)
<cjwatson> It probably ought to be an LP reviewer :)
<cjwatson> doko: Were you still going to do those gdc-v1 binary removals?
<doko> cjwatson, ok, doing. although plplot currently ftbfs
<doko> yeah, ruby stuff now building agian ...
<stgraber> mute queue
<queuebot> Added mute entry: ['#ubuntu-release', 'queue']
<stgraber> mute
<queuebot> ['#ubuntu-release', 'queue']
<stgraber> unmute queue
<queuebot> Removed mute entry: ['#ubuntu-release', 'queue']
<stgraber> (was testing a small fix to make queuebot reply with privmsg when interacting with a user and only use notice for actual notifications)
#ubuntu-release 2013-07-03
<tjaalton> halp, need someone to approve mesa & mesa-lts-quantal
<mlankhorst> HALPPP PLXX
<infinity> On it.
<tjaalton> :)
<tjaalton> thanks
<tjaalton> I'll do the same for raring
<infinity> mesa-lts-quantal's changelog history seems to have gotten mangled.
<tjaalton> we don't care about that
<tjaalton> it's scripted
<tjaalton> the changelog should have everything via the quantal "upstream"
<tjaalton> the latest one just adds ~preciseN
<mlankhorst> sec
<tjaalton> of course this is the first time I'm on this, so could have messed things
<mlankhorst> you did mess up
<mlankhorst> :P
<tjaalton> damn
<tjaalton> how?
<mlankhorst> tjaalton: https://launchpadlibrarian.net/144071101/mesa-lts-quantal_9.0.3-0ubuntu0.3~precise1_9.0.3-0ubuntu0.4~precise1.diff.gz
<mlankhorst> that's why lts-pkg-rename takes an argument to the old stack dir
<tjaalton> oh
<mlankhorst> but just fix it up manually
<tjaalton> so you did have those
<tjaalton> *keep
<mlankhorst> yeah, just the ones in release, the ubuntu0.3 one never left NEW so I don't care about it
<mlankhorst> but you wiped the original LP bug entry
<tjaalton> the diff doesn't show 0.3
<tjaalton> oh I see
<mlankhorst> still shows up in the changes file though, so meh..
<tjaalton> I'll merge that too then
<infinity> What do you mean "0.3 never left NEW"?
<tjaalton> infinity: ok I'll fix it up
<infinity> It's in -proposed.
<tjaalton> it's in NEW
<infinity> Oh, it's in binary NEW, sure.
<infinity> I can fix that. :P
<mlankhorst> hehehe
<tjaalton> you could fix xserver-xorg-video-intel-lts-quantal still being there :)
<mlankhorst> yeah I hate this stuff
<tjaalton> I'll fix the changelog and reupload, feel free to reject the current one
<mlankhorst> dual-level changelogs suck
<tjaalton> right, two steps to bug the archive admins
<tjaalton> that too
<mlankhorst> infinity: xxv-intel-lts-raring is in unapproved, can you accept it too?
<infinity> mesa-lts-raring also seems to have a vaguely confused changelog, but maybe that one's unavoidable, I dunno.
<mlankhorst> sadly no way out
<mlankhorst> it had to close the original bug too
<tjaalton> ok new version uploaded
<tjaalton> meh, mesa 9.1.4 needs an sru bug
<doko> cjwatson, removed all the binaries built with gdc-v1 on powerpc. except for plplot, which ftbfs for qt reasons currently
<doko> and cleaned up the lib*-ruby binaries
<cjwatson> armhf too?
<doko> there were none
<doko> that was gcc-4.4 based
<xnox> infinity: https://launchpad.net/ubuntu/+source/gnuradio/3.6.5.1-1ubuntu1/+build/4766558 is dead, can that build be done on the fast one? (sagari?!)
<infinity> xnox: I don't imagine speed will help it much, but it could be tried.
<cjwatson> doko: There are certainly some out-of-dates on armhf from the set of packages we were talking about.
<infinity> xnox: Retried on sagari.  Good luck.  Maybe I should bump the timeout back up a bit.  That said, a build that produces no output for 60m isn't ideal.
<xnox> infinity: it only took 27minutes to build on amd64....
 * xnox likes the build score of 99999999
<jbicha> who should I ask politely to review mozjs17 in new?
<Laney> hmm
<Laney> Could it be that proposed-migration is forgetting about failed tests?
<Laney> I just uploaded glib2.0 and some rdep autopkgtests definitely did fail - colord and firefox are two examples. They were on excuses as FAILED but now they're not there.
<ScottK> Did someone override the results?
<Laney> firefox is, yeah, but not colord as far as I can see
<Laney> wait, I can't remember which way around the force-footests are
<ScottK> Did you see the new way to do it (-release)
<Laney> I only know force-badtest force-skiptest
<ScottK> Thos.
 * Laney nods
<ScottK> Those even
<ScottK> badtest means skip that test for all cases since the test is bad.
<Laney> OK, so firefox is skipped then
<ScottK> skiptest means don't trigger tests for this package, skip them because we want it in -release ASAP.
<Laney> but still colord.
<ScottK> Dunno
<ScottK> Maybe it's bug.  Not sure how cjwatson tested it.
<Laney> Not gonna complain if it lets it migrate. ;-)
<jibel> Laney, "forgotten failed" is a bug. I have a fix that will be pushed tomorrow morning.
<ScottK> Laney: Quick, upload today.
<slangasek> Laney: forgetting failed tests> yes, cjwatson mentioned something about that today
<slangasek> right, jibel said already
<Laney> slangasek: yeah, jibel just confirmed
<Laney> :-)
#ubuntu-release 2013-07-04
<micahg> if an AA has a minute, Bug #1187435 is blocking abiword from migrating to the release pocket
<ubot2`> Launchpad bug 1187435 in sugar-write-activity-0.86 (Ubuntu) "Please remove pyabiword" [Wishlist,Confirmed] https://launchpad.net/bugs/1187435
<tjaalton> is there a way to push an update to -updates quicker than letting it linger on -proposed for one week?
<RAOF> tjaalton: Yeah, you can prod SRU people to release it sooner if you can justify (a) why it's safe and (b) why it's urgent.
<tjaalton> it's bug 1197316
<ubot2`> Launchpad bug 1197316 in mesa (Ubuntu Raring) "GPU hang with Haswell GT3" [Undecided,In progress] https://launchpad.net/bugs/1197316
<tjaalton> kinda urgent now that the new pci-id additions got through :)
<tjaalton> also, an IHV wants it yesterday..
<tjaalton> the quantal ones are urgent, raring bumps the version too
<tjaalton> so that can bake in until the piglit tests are done
<RAOF> I wish that people would actually comment when they set "verification-done"
<tjaalton> acelan did
<tjaalton> I added a new tag for raring
<RAOF> No, he just set "verification-done-quantal" without making any comment.
<tjaalton> refresh
<RAOF> At least as far as I can tel.
<RAOF> :)
<tjaalton> maybe should've tagged precise though, that's my bad
<RAOF> Yay!
<tjaalton> or, the tagging doesn't actually work with all these combos :)
<tjaalton> but it's essentially the same package, even though not run on quantal
<RAOF> Ok, those changes seem sensible enough. How much testing has that package got so far?
<infinity> s/package/package set/ as I assume it also need the new xvideo-intel?
<tjaalton> not this bug
<tjaalton> infinity: ^
<infinity> But, the other bug?
<tjaalton> it's two bugs, this one was "caused" by updates for bug 1175533
<ubot2`> Launchpad bug 1175533 in linux (Ubuntu Quantal) "[HSW] intel VGA driver i915 doesn't support new haswell graphics [8086:0a2e] " [Critical,In progress] https://launchpad.net/bugs/1175533
<RAOF> s/caused/exposed by/
<tjaalton> right, 9.0.3 needed these backports
<infinity> Okay, but no one's re-verified that bug with the new packages.
<tjaalton> and 9.1.4 for raring includes both the new pci-id's and the GT3 enablement work
<tjaalton> the quantal backports have been verified
<tjaalton> by hwe
<infinity> I like the theory, but I see no evidence of that on the bug log.
<infinity> Not since the new packages were accepted last night by me.
<tjaalton> well you accepted -intel yesterday, so it's only mesa now that needs an update on quantal :)
<infinity> "I verified this once, then things got changed again" doesn't quite qualify.
<tjaalton> and mesa-lts-quantal
<infinity> Especially when update A caused regression B.
<tjaalton> it wouldn't work without the new intel
<infinity> I kinda want to see it all well-tested again in the current state, not something hand-wavy.
<tjaalton> these were tested with -proposed
<infinity> They were tested BEFORE they built.
<infinity> ie: with the previous versions.
<tjaalton> how so?
<infinity> The last action on 1175533 is on June 27th.
<infinity> Then I accepted a new mesa.
<tjaalton> oh you mean that
<tjaalton> hmm so the -intel was binary new for proposed
<tjaalton> http://paste.ubuntu.com/5842611/
<tjaalton> this is what he had installed
<tjaalton> plus kernel -36
<infinity> And the binary new Intel stuff too, yeah.  I only accepted that yesterday.
<tjaalton> oh libdrm needs a shove too
<infinity> So, it can't have been tested before.
<tjaalton> so it's easy, accept them all together :)
<infinity> I can do that, I just want to make sure all the bugs addressed have all had some solid verification with current versions.
<infinity> And that there's been at least some attempt at regression testing on perhaps more than one specific HWE platform.
<tjaalton> I can ask acelan to update 1175533 too
<infinity> (I'd like to think both these things are true, but I see little evidence of either)
<tjaalton> and I can test them on another haswell
<tjaalton> non-gt3
<infinity> Kay.  Please do.
<infinity> And get me a complete package list that needs to go in on both precise and quantal in one shot.
<infinity> And make sure all the referenced bugs appear to have been addressed in some fashion.
<infinity> And I'll happily promote the lot early.
<tjaalton> sure, thanks!
<tjaalton> well the kernel probably will have it's own schedule but should happen later this week anyway
<RAOF> tjaalton: That code doesn't only hit haswell, though? infinity might be happier if sandybridge and ivybridge get some regression-testing, too?
<infinity> tjaalton: And please do the matching raring bits ASAP too, since I'm about to switch the precise dailies to the raring stack. :P
<tjaalton> RAOF: right, I'll boot my laptop with 12.04..
<tjaalton> sandybridge
<infinity> tjaalton: Kernel's just waiting on Cert, everything else is done, so they may be released by me tomorrow.  You could try to light a fire there and ask what's up.
<tjaalton> infinity: yeah, I'll get that done today
<tjaalton> infinity: we asked bjf and nothing should be blocking it afaik
<infinity> tjaalton: Like I said, they're blocked on Cert testing.
<infinity> (Which has nothing to do with bjf)
<tjaalton> hmm
<tjaalton> ok I'll ask someone from cert then :)
<infinity> tjaalton: spineau is the one who appears to have taken the tasks.
<brendand> tjaalton, we aim to get the bugs updated by thursday of the testing week
<infinity> tjaalton: See http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html
<brendand> tjaalton, that's today
<infinity> brendand: Ahh, you're listening in.  Hi. :)
<brendand> infinity, just dropping some eaves
<infinity> brendand: If they get updated during EUR work hours, I can promote during my NA day, which would make me happy.
<brendand> infinity, actually i'm not marshalling that testing this week, but the person who is is in France, so yes it should happen by end of Europe day
<tjaalton> oh ok cool
<infinity> brendand: Yeah, I noticed it was spineau.  Though, he hasn't claimed all the kernels, just some of them (according to the bugs, anyway).
<infinity> brendand: If you want to look into if some of them got "lost", that would be nice. :)
<infinity> brendand: Looks like they're all in progress except for linux/raring.
<infinity> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1191955
<ubot2`> Ubuntu bug 1191955 in Kernel SRU Workflow "linux: 3.8.0-26.38 -proposed tracker" [Medium,In progress]
<tjaalton> infinity: if you want to switch stacks, you probably want to accept the lts-raring backports as well then, aiui those have been in proposed for a loong time now, 36 days in fact
<brendand> infinity, we did start testing that - it looks almost finished
<infinity> tjaalton: I'll be building the dailies from -proposed initially anyway, but yeah, that's the ultimate plan, obviously.
<brendand> infinity, if you're interested, bookmark this: http://people.canonical.com/~hwcert/sru-testing/current/
<infinity> I might have to add a link to that on the bottom of sru-workflow, so I don't lose it.
<infinity> brendand: And thanks.  I'll check the state of the world in the morning and hope for a pleasant surprise. :)
<infinity> tjaalton: So, that should handle the kernel side.  Just get me whatever verification and regression testing I need for the mesa/X bits, and poke me for my morning.
<tjaalton> infinity: ok, cool
<infinity> tjaalton: /msg if you don't want me to lose it in a haze of morning pre-coffee madness. :)
<tjaalton> it's what, 0:26AM there now?
<infinity> 01:26
<tjaalton> alright
<tjaalton> I'll get it done and ping, react when ready :)
<jibel> cjwatson, I push r211 of adt-britney. collect now returns all the latest results, and should not forget previous status. Just in case, I added option -n to revert to the previous behavior and show only freshly collected results.
<cjwatson> jibel: Great, thanks
<Laney> Does britney consider Breaks for uninstallability?
<seb128> or asked different "if the new xorg-server Breaks: unity (<< to-be-uploaded)", will britney stop it to migrate to saucy while unity is not updated?
<cjwatson> Laney,seb128: only if some package depends on both xorg-server and unity, or if unity depends on xorg-server
<cjwatson> proposed-migration doesn't (and can't) require everything to be coinstallable
<Laney> cjwatson: Yeah. I thought maybe it would see that the situation is worse (i.e. that they were coinstallable and now are not) and care about that.
<cjwatson> Nope, that gets into NP-complete hell very quickly.
<Laney> Right, and it might not necessarily be a problem
<cjwatson> Indeed.
<Laney> Do we have a fauxpkg (I think that's the right term) for ubuntu-desktop et al?
<infinity> cjwatson: "some package" does depend on xorg-server and unity, it's called ubuntu-desktop.
<Laney> wait, that's not even necessary
<cjwatson> Then that ought to do it.
<Laney> yeah
<Laney> I thought they were recommends, but checked and they are not
<cjwatson> (I'm sick.  All you get from me today is the stuff most deeply embedded into my consciousness.  Sadly that appears to include the fundamental workings of britney)
<Laney> Yeah, a fauxpkg for the ubuntu-desktop /task/ was probably what I was thinking of
<cjwatson> jibel: Great, this is working (cf. xorg-server -> firefox).  So now it's just the fix for virtual package handling, I think?
 * cjwatson goes to announce this
<jibel> cjwatson, yes virtual packages and the retry command.
<cjwatson> The first is workaroundable by forcing occasionally, so I won't block announcing on that
<cjwatson> Sent to u-d-a
 * cjwatson sticks a chdist-mainonly command in lillypilly:/home/ubuntu-archive/bin/ and removes the -mainonly chdist configs
<cjwatson> should speed up archive-reports
<micahg> cjwatson: can you look at Bug #1187435 is blocking abiword from migrating to the release pocket
<ubot2`> Launchpad bug 1187435 in sugar-write-activity-0.86 (Ubuntu) "Please remove pyabiword" [Wishlist,Confirmed] https://launchpad.net/bugs/1187435
<jbicha> please promote the activity-log-manager binary to main
<infinity> jbicha: Done.
<mlankhorst> !!
#ubuntu-release 2013-07-05
<cjwatson> Image builds failed today due to a complex interaction between software-center and a python-configparser package pulled in by a new dependency from python-configglue.  I'm mailing Barry for advice
<Laney> seems to be bug #1038429 fwiw
<ubot2`> Launchpad bug 1038429 in software-center (Ubuntu) "update-software-center crashed with order (MRO) for bases SafeConfigParser, object in __new__()" [Medium,Confirmed] https://launchpad.net/bugs/1038429
<Laney> there's some analysis in there
<cjwatson> Oh, I didn't expect it to be that far back in history
<Laney> It just happens now for everyone because python-configglue gets pulled in by something but I guess the bug was always present
<Laney> was going to ask dobey to take a look
<cjwatson> Be my guest :)
<cjwatson> i386 builders down briefly while I rebootstrap lua-ldoc/lua-penlight
<cjwatson> back on auto (bah, still fails)
<xnox> Thank you for accepting gcc-arm-linux-androideabi, whoever that was =)
<stgraber> xnox: oh, does that mean we'll soon be building our android bits in the archive?
<xnox> stgraber: yeah, as soon as we work out a sensible way to ship binary blobs. I'm thinking to have: android-src package, which ships android-src. Then per-device binary blob packages for each of the 4 devices. And then a package which builds images for all four using: cross-toolchain above, android-src, binary-blob package.
<xnox> stgraber: once cross-toolchain is ported to use cynogenmod sources instead of linaro sources, it will to start to build-depend on android-src.
<xnox> that way keeping up android copyright would be easier, by having only one place to do so.
<xnox> stgraber: but it does mean, that arch:all gnupg-android package can be added to gnupg package right now ;-)
<xnox> and parted.
<stgraber> cool
<sergiusens> xnox: the blobs don't necesarily need to be in the build tree as long as they are installed later
<xnox> sergiusens: that's nice! i had the plan that ready-to-flash .zips / .img are build in the package. If binary blobs are needed to be added later, what should the .deb ship? just the tree of build: system/ recovery/ boot/ ?
<xnox> from out/product/....
<sergiusens> xnox: that's my plan for community builds... $OUT/system + boot (which ogra today mangles in cdimage to make it an ubuntu one) are the device.zip, then we need recovery.img
<xnox> sergiusens: is recovery.img generic or also has blobs?
<ogra_> sergiusens, yeah, we need to find a way to replace the initrd before zipping
<sergiusens> xnox: I don't recall what was in boot/, will need to check
<cjwatson> sergiusens: boot isn't mangled, although system.zip is
<cjwatson> well, *-touch-armhf.zip
<cjwatson> and *-system-armel+*.zip
<sergiusens> cjwatson: I though ogra grabbed boot.img which is in thesystem-armel-*. zip
 * sergiusens hasn't checked the code yet
<ogra_> i replace boot.img with a zip -u
<ogra_> (-u for update)
<cjwatson> sergiusens: It's all in cdimage code now, not in ogra's home dir any more ... and the boot.img is wgetted from foo.bootimg-* on the livefs builder, no cdimage-side mangling of that part
<cjwatson> *-system-armel+*.zip is mangled to insert the right boot.img
<cjwatson> https://bazaar.launchpad.net/+branch/ubuntu-cdimage/view/head:/lib/cdimage/build.py#L418  add_android_support and build_livecd_base functions
<ogra_> right
<ogra_> and the mangling should move into the android build
<ogra_> so cdimage doesnt need to do it
<ogra_> (we just need some feedback from prters first before we can do that)
<ogra_> *porters
<xnox> ogra_: so is the plan to have: android-src package, with common sources. Plus 4-per-device packages with binary blobs for each, build-dep on android-src & android-cross-toolchain, building final zips/images an ok plan?
<ogra_> (flipping the ports is way harder than nexus ... since we have no HW usually)
<xnox> .... since the binary-blob packages will need to be in restricted/multiverse
<ogra_> xnox, i'm not sure we can actually rely on common sources ... i'm not so sure how much build option mangling per device we have for the android core
<ogra_> so we would probably still have one package per arch
<ogra_> and yeah one additional package for the blobs
<ogra_> (per subarch again)
<xnox> ogra_: android-src - just ships the equivalent of the repo-checkout under /usr/src/. We do need to build it fully for each device.
<ogra_> ah, so you were talking about source, i was referring to binary
<xnox> ogra_: well, something like the gcc-4.7-source and binutils-source packages. They are binary packages, but they ship pure source code.
<xnox> ogra_: specifically to decouple per-device builds.
<ogra_> ok
<xnox> (per-arch / cross-arch etc)
<ogra_> well i would like to end up with something like android-rootfs-$subarch_$version.deb which pulls in android-blobs-$subarch_$version.deb
<ogra_> no matter how we get there :)
<ogra_> the livefs-builder can then merge their contents into a zip
<xnox> ogra_: not sure that would be possible..... what do you expect in the android-rootfs*.deb?
<ogra_> everything that isnt a blob ?
<xnox> ah, no zips.
<ogra_> well or tar.xz or whatever stephane needs :)
<xnox> ogra_: ok, i need to poke at unflipped images =)
<ogra_> xnox, essentiually i need to produce something like the current device specific zip in the end
<xnox> ogra_: i thought i'd be generating: android-rootfs-with-bloby-$subarch_$version.deb which has like ramdisk.img, recovery.img, userdata.img, system.img
<xnox> ack.
<ogra_> but licensing might force us to have that split into two
<ogra_> i would prefer if you could do it like that ... but i doubt that works licensing wise
<xnox> well, that deb would be in multiverse =)
<ogra_> unless we push the whole stuff into restricted ... but that would kind of violate what restricted is for
<ogra_> thats why i thought "rootfs -> universe", "blobs -> restricted" ... and easily installable alongside so that they form the content of a zip
<cjwatson> restricted is proprietary hardware support; Android objects don't seem particularly against its spirit?
<ogra_> i wouldnt like to bring multiverse into play at all
<ogra_> cjwatson, well, the whole android rootfs ?
<cjwatson> Oh, right, no, that would be a bit much
<ogra_> yeah
<ogra_> thus the split
<ogra_> xnox, there is a per device "proprietary.txt" (or similar, cant rememebr the exact name) that actually defines whats a blob ... based on that we should be able to have a restricted package
<ogra_> everything thats not in there should go into an android-rootfs-$subarch package into universe
<ogra_> (or ven main if we actually want to support it)
<xnox> ogra_: I'm not sure how zips are assembled / .img files created. Cause then we would want a wrapper available to generate normal .zip / .img files.
<xnox> after both .debs are installed.
<ogra_> xnox, dont worry about the zips get me a package with the content of /system in it (including /system/boot/ramdisk.img) and separate the blobs into an extra package, i'll care for the rest
<ogra_> the generation of the zips or tarxz or whatever we will use in the end can happen on the livefs builder as part of the image build
<sergiusens> xnox: ogra_ I guess what you want from the vendor branches is the specific makefiles without the PRODUCT_COPY files
<ogra_> what i would like is something that contains /usr/lib/android-rootfs-$subarch/system ...
<ogra_> in a deb
<ogra_> sergiusens, right
<sergiusens> xnox: where is all your stuff to check out? is it in your xnox branch in phablet.ubuntu.com?
<ogra_> hmm, we would probably also want /usr/lib/android-rootfs-$subarch/recovery (containing the recovery subdir from the out dir of the build tree)
<xnox> sergiusens: what do you mean? =)))) so far I only have two .git repos for the cross-toolchain on github, not yet moved to phablet.u.c. And yet to start doing above beast of a "lets-package-android"
<sergiusens> xnox: I mean in other words that I want your setup to see what's going on :-)
<ogra_> xnox, wow, it only took you half a day to assemble the copyright file ? how did you manage that ?
<xnox> sergiusens: ah, sure. I can give you my manifest, that's pushed to phablet.ubuntu.com
<ogra_> even a licensecheck over only one subarch generates a 4MB mess for me here (not to mention the 100s of completely unlicensed files in the tree)
<xnox> sergiusens: so far, i'ts people/xnox branch of the manifest repo with only changes to use system-wide toolchain, instead of prebuilt one.
<xnox> sergiusens: next up, I need to start using native host toolchain. next up debian/ folder will be added.
<rsalveti> hopefully the boot and recovery doesn't bring any binary in place
<rsalveti> otherwise we might need to create them differently
<xnox> sergiusens: where / how is the export tarball generated?
<ogra_> well they are sourc eat some point :)
<ogra_> *at
<rsalveti> I mean the binary blobs (hal, etc)
<ogra_> boot.img shouldnt
<ogra_> not sure about recovery though
<ogra_> is there networking support in recovery usually ?
 * ogra_ didnt think there was
<ogra_> thats the only thing i could imagine needing blobs
<ogra_> hmm, unless ... how does recovery access the framebuffer
<rsalveti> I'm worried about fb and input
<ogra_> well, fb usues pixelflinger usually, i dont thing that needs any EGL
<ogra_> but i might be wrong, clearly an assumption :)
<sergiusens> let me check
<xnox> ogra_: on a more imminent point, can we move current builds to the toolchain now in the archive? I have patches for android-build to check/use system-wide toolchain, I can test them a bit and push. But then the toolchain needs to be installer wherever the build is run.
<rsalveti> xnox: can you send us the needed patch so we can review and test?
<ogra_> xnox, i think rsalveti and serguiens have scripts that pull the kernels into the build, should work similar for the toolchain
<rsalveti> yes, we just need changes to make the android build system to use them during build time
<ogra_> right
<sergiusens> ogra_: xnox: I just checked manta and there is no prop bits in recovery, going to build latest maguro et.al. and just check to be sure
<sergiusens> xnox: regarding $OUT/boot, was that supposed to be $OUT/root ?
<sergiusens> $OUT/root is the android-ramdisk in the boot.img btw (for original android)
<xnox> sergiusens: probably. I'm fuzzy with names =)
<xnox> whichever they are, excluding userdata
<ScottK> wireshark is currently blocked from migrating to -release due to netexpect.  That will FTBFS with the current wireshark (I filed #714535 in Debian with no response from the maintainer).  Would the reasonable thing to do for now be to remove the netexpect binaries to wireshark can migrate?  Note: there are security issues fixed in the wireshark upload.
<infinity> ScottK: Posting it to the new API would be the sanest thing to do.
 * ScottK <-- not a C programmer.
 * ScottK would prefer to not leave the open vulnerabilities in saucy in the mean time.
<infinity> Most of the changes look reasonably straightforward.
<infinity> Let me wake up a bit, and I'll see if it's not too much effort to fix.
<ScottK> Thanks.
<ScottK> You could even upload an NMU and let it sync ...
<infinity> ScottK: If the security issues are hugely urgent enough to not let it sit in proposed, we could also backport the patches to 1.8.7 in the security PPA and copy directly to the release pocket.
<ScottK> I didn't investigate the details.
<ScottK> Every wireshark release has something.
<infinity> "The NetworkExpect source code is maintained in a Subversion repository. This repository is currently not available to the community, but this may change depending on the interest from the community."
<infinity> Grr.
<infinity> So, it *could* be fixed upstream, but I can't tell.  Fun.
<infinity> ScottK: Uploaded and patch submitted to the Debian maintainer.  It builds.  No idea how well it works.
<ScottK> infinity: Thanks.
 * ScottK doesn't really care much for netexpect, so as long as it builds and unblocks wireshark, I'm happy.
<infinity> Well, my assumption is that upstream has already fixed this anyway, but due to having a closed VCS, I have no way of telling.
<infinity> (Their history seems to show they track wireshark API changes fairly actively)
<infinity> Put one small tick in the "Open > Free" column.
<micahg> infinity: any chance I can get you to unblock abiword by doing some removals?
<infinity> micahg: I looked at that briefly.  It's not removed from Debian, only from testing.
<micahg> infinity: and?
<infinity> cjwatson: Did you ever get anywhere with magic demotion scripts, or should I just do a manual copy of a few things down to proposed?
<micahg> I didn't say blacklist :), if it gets fixed, we can resync
<infinity> micahg: And, I'd rather demote than delete.
<micahg> hrm?  demote??
<jbicha> infinity: I believe pyabiword is very broken
<infinity> Oh, I suppose demotion won't work if it wouldn't cause uninstallables and get re-promoted immediately.  I think what's holding it out of testing is RC bugs.
<micahg> ys
<jbicha> it needs to be rebuilt against abiword (which isn't too difficult) but I'd rather see it removed
<micahg> well, it's not a simple rebuild as the upstream source needs to be patched for the 3.0 ABI, but pyabiword upstream seems very dead as you mentioned in the removal bug
<infinity> jbicha: Well, it also knocks out all those sugar-* packages.
<jbicha> infinity: the ones that don't work anyway?
<micahg> it's just 4 and if someone cares enough to fix them, we can add them back
<infinity> Meh.
 * infinity removes.
<micahg> thanks
<micahg> and if someone really cares if it gets fixed later, we can always backport
<infinity> Done.
<ScottK> Is +1 maint still a thing?  I don't recall it mentioned recently.
<infinity> It is, but we don't seem to have formal staffing/rotations this cycle.
<slangasek> we were meant to; if that didn't happen, it's been an oversight
<slangasek> https://wiki.ubuntu.com/PlusOneMaintenanceTeam suggests we're a bit understaffed on it this cycle.
<infinity> I got a whopping 1 volunteer this cycle.
<slangasek> then we need people to be voluntold
<infinity> Yeah, quite possibly.
<infinity> I don't think we need the 3-per-month of the past cycles, but more than just me wouldn't hurt my feelings. :P
<xnox> infinity: python3 -c "import minions from Despicable.Me.2; plus_one.add(minions)"
<infinity> xnox: Has someone been to the movies recently? :P
 * xnox =))))))))))))))))))))))
<infinity> I dated a girl who had a stuffed Minion plushie in her bed.  I should have married her.
<xnox> http://youtu.be/ioKl3d1e_ug
 * xnox has a stuffed stich
#ubuntu-release 2013-07-06
<Noskcaj> When would be the best time to discuss the creation of ubuntu iso magnet links?
<Noskcaj> what happened to the dailys for Ubuntu, Gnome and kylin. all are frozen
<Noskcaj> edubuntu might be too
<stgraber> it appears the two last dailies failed to build because of a xapian related crash
<Noskcaj> ok.
<Noskcaj> What happened to Ubuntu Desktop Preinstalled armhf+nexus7 ? i assume it's been canceled?
<cjwatson> the cause of the broken dailies is fixed, so the next runs should work
<cjwatson> (software-center)
<cjwatson> armhf+nexus7 indeed discontinued in favour of ubuntu-touch etc.  http://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/revision/1261
<Noskcaj> cjwatson, thanks for the info. two more questions: 1. Why is armhf+nexus7 still on the tracker? 2. When is the best time to discuss the inclusion of magnet link downloads?
<cjwatson> tracker> stgraber better person to ask about that
<cjwatson> magnet> I looked at that when you last asked.  There doesn't seem any compelling reason for us to create them, not least because half the point of them seems to be that anyone can create the links if they have the file checksums.
<Noskcaj> ok
<cjwatson> Feel free to file a wishlist bug on ubuntu-cdimage if you really want them, but you should expect to have to do the work
<TheDrums> Magnets are basically links to torrents, they are the sum of the torrent info.
<cjwatson> I have no particular interest in setting them up
<stgraber> Noskcaj: apparently nobody bothered to remove the entry from the tracker... I'll do that now
<Noskcaj> stgraber, thanks
#ubuntu-release 2013-07-07
<smartboyhw> Guys, is there any way to view the Components of an app when I'm running it?
<smartboyhw> i.e. if I click on that button, it shows me the name and such
<smartboyhw> In QtCreator that is
<smartboyhw> Oops, wrong channel, sorry Release Team
<smartboyhw> #ubuntu-touch is right under #ubuntu-release
<Laney> Do we have some kind of etiquette on altering the hints of other rt members? Or JFDI?
<Laney> W: [Sun Jul  7 21:56:55 2013] - Overriding force-badtest[firefox] = ('23.0~b2+build1-0ubuntu1', 'laney', 'None') with ('22.0~b6+build1-0ubuntu1', 'cjwatson', 'None')
<cjwatson> I'd say JFDI when it's obvious like that
<cjwatson> (and, heh, that's sort of a misfeature ...)
<Laney> yeah...
<Laney> I was also thinking that versionless force-*test would be nice but perhaps having to update it all the time will lead to social pressure to get the things fixed
 * micahg wonders if queuebot is awake, python-warlock hit binary NEW without a peep
<stgraber> micahg: just kicked it, it probably didn't like an answer from LP and the queue monitoring thread got stuck
#ubuntu-release 2014-06-30
<mlankhorst> why is all of *-lts-trusty still in -proposed?
<apw> that block of updates is (i believe) prerequisite for the EOL messaging for lts backports
<mlankhorst> yeah
<mlankhorst> cjwatson: ? :P
<mlankhorst> could you promote those packages please? urgently needed now
<cjwatson> er, let me see
<cjwatson> mlankhorst: OK, promoting now, hopefully I got them all
<mvo> is there a chance that someone looks at the preicse-proposed uploads for update-manager/update-notifier? its important for the HardwareEnablement
<mlankhorst> thanks
<mlankhorst> cjwatson: looks good, i think you missed libdrm from saucy though (for updating from precise to saucy)
<cjwatson> You didn't tell me about that :)
<cjwatson> Copied now
<mlankhorst> ty
<Laney> I forgot -v in the first one of those
<cjwatson> w/g 24
<cjwatson> sorry
<shadeslayer> cjwatson: would be awesome if you could reply to https://lists.ubuntu.com/archives/ubuntu-release/2014-June/002925.html
<shadeslayer> so we can move forward with the ISO stuff
<Laney> Would somebody please see what they think of Gunnar's licensing claims in https://bugs.launchpad.net/ubuntu/+bug/1314402 ?
<ubot93> Launchpad bug 1314402 in Ubuntu "Please upload skype-translation to the archive" [Wishlist,In progress]
<rbasak> Laney: I did wonder about that. It seems to be quite common to me that upstream don't have their ducks in a row and then want to fix the licence when distributions want it - not just for this project.
<rbasak> So I wondered to what level Debian ftpmasters or Ubuntu needs it. Sufficient for upstream just to claim it, or should distributions be auditing upstream changes to make sure that all previous contributors accept a licence change (or disambiguation if no previous licence was explicit)
<ogasawara> When someone has a chance, could we get update-notifier and update-manager approved in the queue for Precise?
<ogasawara> mvo and I would appreciate it so that we can begin advanced HWE stack EOL notifications
<Laney> rbasak: Yes it's definitely fairly common that upstream hasn't thought through / understood licensing stuff until one of the distros comes along.
<Laney> It's one of the values that distros bring
<rbasak> Definitely. But if there's previous ambiguity, and upstream fixes it on request, then should distributions require an audit on that change to make sure that the licence change was authorised by all copyright holders?
<rbasak> Because if so, then some upstreams may forever be in limbo.
<rbasak> And if that becomes the majority of unpackaged new software, then that's a problem.
<Laney> We trust what they say
<Laney> In this case we know some more about the history though
<LocutusOfBorg1> argh
<LocutusOfBorg1> flex depends from cm-super-minimal
<LocutusOfBorg1> and cm-super-minimal is in universe
<LocutusOfBorg1> :(
<LocutusOfBorg1> won't build on i386
<Laney> https://bugs.launchpad.net/ubuntu/+source/cm-super/+bug/1328509
<ubot93> Launchpad bug 1328509 in pfb2t1c2pfb (Ubuntu) "[MIR] cm-super, build dependency of gdb-doc" [Undecided,Fix committed]
<Laney> It can be promoted
<infinity> Laney: Promoting.
<Laney> Ta
<LocutusOfBorg1> thanks
<LocutusOfBorg1> infinity, will this build be automatically restarted? https://launchpad.net/ubuntu/+source/flex/2.5.39-8/+build/6118522
<infinity> Yes.
<LocutusOfBorg1> thanks infinity now it is built ;)
#ubuntu-release 2014-07-01
<jibel> Hi, could someone review and approve update-manager and update-notifier in precise-proposed unapproved queue? It's required for HWE EOL notifications
<jibel> RAOF, arges ^
 * RAOF looks
<RAOF> jibel: Hm. Won't be able to accept update-manager until the existing SRU is verified - bug
<RAOF> bug #1311396
<ubot93> bug 1311396 in update-manager (Ubuntu Trusty) "broken translations results in traceback in new release notification" [Undecided,Confirmed] https://launchpad.net/bugs/1311396
<RAOF> Feel free to test that and mark it as verified :)
<jibel> RAOF, thanks, I verify it.
<jibel> +'ll
<RAOF> jibel: Am I right in observing that the update-notifier update should be dependent on the update-manager update? It looks like the update-notifer script unconditionally calls hwe-support-status, which is added in the new update-manager, right?
<jibel> RAOF, you're right. let me ask mvo to join this channel.
<RAOF> Just upload with an appropriately versioned Depends and it should be fine.
<RAOF> Hey mvo!
<mvo> RAOF: hi, thanks for your review of update-notifier
<mvo> RAOF: I'm happy to add the dependency, but iirc (need to double check) it was done in a way that even without update-manager-core it would still work fine
<mvo> i.e. it would just ignore this part
<RAOF> It looked to me like it didn't check whether the file existed and just called it; that would generate an error message somewhere, right?
<RAOF> mvo: It calls â/usr/bin/hwe-support-status || trueâ; that's going to error if /usr/bin/hwe-support-status doesn't exist, right?
<mvo> RAOF: yeah, there is || true that prevents damage and it won't be part of the user visible output, but I agree that for correctness it makes sense to add the dpenency
<RAOF> It'll certainly help in testing :)
<RAOF> Since you can't usefully test without the dependency.
<mvo> *cough* yes. sorry for that, I will re-upload
<ogra_> could some archive admin NEW dbus-property-service ?
<seb128> ogra_, done
<apw> it looks like libgtop2 2.30.0-0ubuntu1 just migrated but this migrating seems to have ripped a versioned libgtop-2.0.so.7 out from under unity7 which no longer starts; i am wondering why britney didn't stop that
<apw> plus could someone else confirm my diagnosis
<apw> specificially bamfdaemon seems to be linked to it and no longer starts, which seems to be fatal to unity7
<apw> (read, i have a blank desktop)
<Laney> apw: looks true from the package list
<seb128> shrug
<Laney> file list
<apw> i suggest upgrading is a bad idea right now
<seb128> can you mention it on -devel where the people who did the merge/upload are as well?
<seb128> apw, how would have britney stopped that?
<seb128> we don't have autopkgtests checking that unity runs
<Laney> If there were any tests
<Laney> like testing bamf works or something
<seb128> right
<apw> seb128, hmmm well, i assume something else was done wrong which means it could not detect it, and i think you are suggesting that the binaries are -7 cause they contained abi 7 and should have changed to -10 and did not, if they had, britney would have had a chance
<seb128> right, if they had renamed the binary we would have no issue
<seb128> the old abi would still be around and britney would have stopped the migration until everything is ported to 10
<Laney> Transitions at the archive level are moving dependencies from one package (containing the old SONAME) to another (containing the NEW)
<Laney> But if you forget to rename then you just have the new one and the archive seems to be all in order
<apw> seb128, yep, i am not blaming britney that is for sure, i was wonderng how we got there, and user error is the answer
<Laney> Better test coverage would have helped
<apw> yes that is true indeed
<seb128> well, what we need is autopilot tests integration in britney/autpkgtests
<seb128> we have plenty of those for unity
<seb128> they just don't run there
<apw> so nearly enough :)  anyhow, sounds like it is getting sorted, thanks for your prompt help
<seb128> yw, thanks for pointing it out!
<seb128> revert uploaded
<apw> it is probabally worth scoring up the lagging arm64 build for this revert given its effects: https://launchpad.net/ubuntu/+source/libgtop2/2.30.0.is.2.28.5-0ubuntu1/+build/6145810
<cjwatson> can't make it go faster without cancelling builds
 * cjwatson cancels the most recently started build, will retry it in a sec
<ogra_> seb128, can i have a binary NEW for dbus-property-service too ?
<apw> cjwatson, thanks, it seemed to keep moving out to 10m again every time i looked
<cjwatson> Building now
<seb128> ogra_, done
 * ogra_ hugs seb128 
<ogra_> thanks !!
<seb128> yw! ;-)
<seb128> that was an easy one
<mvo> jibel: I wonder if we simply should reject updatemanager in precise-proposed for #1311396 to unblock the SRU for the HWE stack
<jibel> mvo, I agree, the SRU should be against the langpacks anyway since there is no other change in update-manager, isn't it?
<mvo> jibel: yes
<mvo> so could a archive admin please remove update-manager  1:0.156.14.14 from precise-proposed ? so that we can upload a new .15 with a import HWE update?
<cjwatson> jibel,mvo: removed
<mlankhorst> cjwatson: can you accept xorg-lts-transitional ?
<cjwatson> where?
<mlankhorst> trusty
<jibel> cjwatson, thanks. Can you approve update-manager 1:0.156.14.15 in precise ?
<cjwatson> mlankhorst: done
<mlankhorst> ty
<cjwatson> jibel: doesn't it need to be rebased against .13?
<mlankhorst> I'll make a backup and try to upgrade tomorrow :p
<jibel> mvo, ^
<jibel> cjwatson, .14 was a change in the translations which come from LP, but better wait for mvo's answer
<cjwatson> sure, but if I removed it that must be because it made things worse, right?
<cjwatson> otherwise it was unnecessary to remove it
<mvo> cjwatson: its like jibel said, the diff between 13->14 are only po files. I expected that translations.lp would import them from my upstream upload but apparently it didn't :/ it does not make anything worse, I just asked for removal to speed up the process
<cjwatson> oh, so there was no need to remove really then
<cjwatson> ok, have to go to the bike shop, will have a look later
<mvo> thanks
<mlankhorst> bdmurray: hm why is https://bugs.launchpad.net/ubuntu/+source/xorg-server-lts-raring/+bug/1246384 not a dpkg bug? seems to me that dpkg fails to remove all files for xserver-common-lts-raring before the postrm hook runs..
<ubot93> Launchpad bug 1246384 in xorg-server-lts-raring (Ubuntu) "xserver-common-lts-raring does not always get correctly removed." [High,Confirmed]
<mvo> and sorry for the confusion about the rmeoval
<barry> infinity: question: why is zope.interface in depwait when python3-zope.event is available in utopic?  https://launchpad.net/ubuntu/+source/zope.interface/4.1.1-2/+build/6144343
<stgraber> barry: because python3-zope.event isn't in main
<barry> stgraber: gah
<barry> stgraber: okay, thanks, i missed that.  MIRing
<arges> Whats the protocol with sru-releasing packages that I've uploaded or accepted? Do I need to get another person to do the final check?
<arges> anyway, I would sru-release pacemaker/corosync for precise; but I'm not sure if I should get another person to do that since I sponsored both
<slangasek> arges: sponsor+accept+sru-release, ok.  prepare upload+accept+sru-release, not ok :)
<arges> slangasek: so the diffrence is, is it a patch i wrote?
<slangasek> arges: the difference is whether you can count yourself as a second set of eyeballs
<arges> slangasek: yea that's what i want to avoid. I like having multiple sets of eyes on any change
<slangasek> arges: I'm saying the rule of thumb should be that there are at least two sets of eyeballs on the package, the preparer and the SRU team member.  I think it's fine to sru accept a change that you sponsored, provided you're really just sponsoring and not extensively revising
<arges> slangasek: gotcha.
<popey> hello! is it possible to get marco, mate-session-manager, mate-desktop-environment synced from debian?
<popey> If so, is there some paperwork I need to fill in?
<cjwatson> requestsync(1)
<cjwatson> But, err, we don't appear to have an Ubuntu delta to any of those?
<popey> grr
<cjwatson> They're all in utopic at the same versions as in unstable
<cjwatson> So nothing to sync
<popey> 1.8.0 vs 1.8.1?
<popey> 1.8.1-3 vs 1.8.1-4?
<cjwatson>  mate-session-manager     | 1.8.1-3               | sid              | source, amd64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc
<popey> I'm going by packages.d.o vs packages.u.c
<cjwatson> Oh come on those were just uploaded today :)
<cjwatson> They'll auto-sync
<popey> oh, i wasn't aware of that
<popey> i thought it was all manual, sorry.
<cjwatson> Very much automated
<popey> Yay!
<popey> thanks
<cjwatson> Before Debian import freeze, anything that doesn't have an Ubuntu delta is auto-synced, basically
<cjwatson> (There are a few exceptions)
<popey> ah, got it.
<cjwatson> lp:ubuntu-archive-tools auto-sync has the full logic should you ever be unfortunate enough to need to investigate
#ubuntu-release 2014-07-02
<cjwatson> popey: Looks like those packages you were asking about were auto-synced last night.
<popey> super, thanks cjwatson
<jibel> Could someone approve update-manager 1:0.156.14.15 in precise-proposed?
<shadeslayer> hmmm, how's the libav transition going?
<jibel> cjwatson, ^ would you have time to review/approve update-manager in precise today? we need it for testing hwe eol notifications.
<cjwatson> jibel: doing
<jibel> cjwatson, thank you
<ChrisTownsend> cjwatson: Hi!  You are the SRU vanguard today, correct?
<ChrisTownsend> cjwatson: If you saw my previous ping, no need to respond.
<cjwatson> http://people.canonical.com/~ubuntu-archive/component-mismatches.html  new toy
<cjwatson> (also priority, architecture)
<cjwatson> also the next build of http://people.canonical.com/~ubuntu-archive/nbs.html should have a graph
<cjwatson> if anyone knows how to make YUI's numeric axes work more sensibly, let me know
<utlemming> infintiy, cjwatson: are either of you around?
<utlemming> infinity, cjwatson: due to bug #1336855 and the recent Grub SRU for 12.04 anyone running an HVM instance on AWS will lose their instance on reboot.
<ubot93> bug 1336855 in cloud-init (Ubuntu) "[SRU] non-interactive grub updates for 12.04 break on AWS" [Critical,Confirmed] https://launchpad.net/bugs/1336855
<infinity> utlemming: fun.
<utlemming> infinity: yup...and if there is a grub update for 14.04, they'll get burned too
<utlemming> infinity: do you have any guidance how to dig out of this hole?
<utlemming> infinity: I am leary to put the logic into cloud-init since cloud-init doesn't have a grub dependency
<infinity> utlemming: Erm, but the bug is in cloud-init?
<utlemming> infinity: right. So what happens is one first boot cloud-init sets a debconf selection for grub-pc "install_devices". Since it doesn't know to look at /dev/xvda and /dev/xvda, grub tries to install to /dev/sda (which is what the images originally had).
<infinity> utlemming: Isn't it as simple as making that 1-line change to cc_grub_dpkg.py?
<utlemming> infinity: nope. Because that module only runs once.
<utlemming> infinity: and then there is the race condition of a user who updates grub and then cloud-init
<infinity> utlemming: Then the bug log seems to lie.
<utlemming> infinity: adding a better, clarifying comment
<utlemming> infinity: clarified the bug
<infinity> utlemming: I'm confused how you got in this state in the first place.  Wouldn't have the first run of cloud-init created a broken grub config straight up and this has been wrong since day 1?
<utlemming> infinity: the cloud image build process installs grub by hand, since we can't build the images in AWS.
<infinity> utlemming: That doesn't really answer my question. :)
<infinity> utlemming: Any kernel or grub upgrade would have broken this, so what introduced the bug, and how long has it been broken?
<utlemming> infinity: that part I am unsure of. But AWS just reported it. It has been broken since day one. Not having looked, I would guess that grub changed something such that the bits installed on disk don't work with the stuff in /boot/grub.
<infinity> utlemming: So, if we really wanted to make this smooth, we could SRU cloud-init with the 1-line fix, and have it conditionally re-run 'cloud-init-cfg grub-dpkg' in its postinst on upgrade from known-broken versions, *and* re-upload a grub SRU with Breaks: cloud-init (<< new_version), forcing cloud-init to upgrade before grub.
<infinity> utlemming: I'm not sure having this leak into the grub packaging is really worth the hassle, but if you always want upgrades to work, I'm not sure there's a cleaner way.
<utlemming> infinity: I _did_ start to go down that path, but had an issue with the fact that 'cloud-init-cfg grub-dpkg' runs debconf-set-selection, which runs into a debconf lock
<infinity> utlemming: Oh, I guess you could re-run grub-install on cloud-init postinst in the same condition that you run cloud-init-cfg grub-dpkg
<infinity> utlemming: There should only be a lock if you're running it in a part of your postinst that happens to be debconfy?
<utlemming> infinity: the cloud-init postinst is debconf'd, yes
<infinity> utlemming: Sure, but not the WHOLE postinst. :)
<infinity> utlemming: If nothing else, there's some convenient imaginary whitespace before or after the bits that are.
<utlemming> infinity: lol, okay, I'll look at doing that
#ubuntu-release 2014-07-03
<cjwatson> I think the Haskell transition is finally only about a day off completion
<cjwatson> (Just waiting for a couple more Debian publisher cycles)
<cjwatson> Should make update_output rather a lot more readable
<shadeslayer> cjwatson: I think you forgot to move some packages from -proposed to -release wrt https://bugs.launchpad.net/ubuntu/+source/kde4libs/+bug/1327591
<ubot93> Launchpad bug 1327591 in kde4libs (Ubuntu Trusty) " SRU tracking bug for KDE SC 4.13.2" [Undecided,Fix committed]
<cjwatson> shadeslayer: Just kajongg?  It wasn't seven days old at the time, though it is now
<shadeslayer> cjwatson: http://paste.ubuntu.com/7742182/
<cjwatson> Er, I don't know, please analyse that :)
<cjwatson> If it's kde4libs, that's listed on pending-sru as having unverified bug 1332064
<ubot93> bug 1332064 in kde4libs (Ubuntu Utopic) "[CVE-2014-3494] KMail/KIO POP3 SSL MITM Flaw" [Undecided,Fix released] https://launchpad.net/bugs/1332064
<shadeslayer> cjwatson: http://paste.ubuntu.com/7742189/
<cjwatson> But that's Fix Released so not sure
<shadeslayer> sounds about right I guess
<cjwatson> No, I mean analyse it and tell me which sources are missing
<cjwatson> Anyway, I think I can release kde4libs, so I guess that'll help
<shadeslayer> cjwatson: well, I uploaded 4.13.2 , then I uploaded 4.13.1 + security fix, which closed the bug, and then I uploaded 4.13.2 + security fix
<cjwatson> (done)
<shadeslayer> which is why the bug is verification done
<shadeslayer> thanks, lets see what happens
<infinity> It took three people to do this?
<infinity> platform-api (2.1.0+14.10.20140702-0ubuntu1) utopic; urgency=low
<infinity>   [ Alberto Aguirre ]
<infinity>   * Bump Mir dependencies to 0.4.0.
<infinity>   [ Cemil Azizoglu ]
<infinity>   * Bump Mir dependencies to 0.4.0.
<infinity>   [ Kevin Gunn ]
<infinity>   * Bump Mir dependencies to 0.4.0.
<infinity>  -- Ubuntu daily release <ps-jenkins@lists.canonical.com>  Wed, 02 Jul 2014 02:11:11 +0000
<stgraber> infinity: they split the work, one character each :)
<wxl> sheesh busy day for the queue
<cjwatson> wxl: That's just normal auto-sync traffic
<cjwatson> Not especially busier than other auto-sync events
#ubuntu-release 2014-07-04
<cjwatson> Right.  I think the next publisher/proposed-migration cycle will propagate haskell-*.  After that I'll stop the publisher for a bit, because it's a large enough set of packages that it may not manage to copy atomically in the usual time available between proposed-migration and publisher, which would be bad.
<cjwatson> Oh, damn, maybe not, there's an out-of-date on powerpc :(
<cjwatson> I bet that will involve a bunch of rebuilds up the stack ...
<zul> can someone tell me why oslo-config is stuck in proposed?
<Laney> You removed python-oslo.config-doc and python3-oslo.config
<cjwatson> Because it's hit a corner case that needs manual handling
<Laney> zul: The diff looks weird. Did you start from an old package?
<cjwatson> I'll sort it out
<cjwatson> Oh, yeah, if you didn't remove those packages intentionally ...
<zul> Laney:  i did
<cjwatson> As it happens neither has reverse-dependencies, but it does seem odd to remove them
<cjwatson> zequence_: Did you intend for audio-core and desktop-minimal to be new ubuntustudio-* metapackages?  It would be nice if somebody could upload ubuntustudio-meta every now and then ...
<infinity> I imagine he'd upload it more often if he had PPU rights (isn't he still applying for that?)
<DalekSec> infinity: He's just going for the ubuntustudio-* packages I think, not the packageset.
<infinity> DalekSec: Sure, I would expect that to include the meta, though.
<DalekSec> Yep, just hasn't gotten it yet.
<infinity> Yeah, he asked me to advocate him, but I really haven't sponsored much of his uploads.
<infinity> I guess I could give a character reference. :P
<DalekSec> Ah, so if one wants upload rights, one should bother as many different people as one can. :D
<infinity> Ideally not.
#ubuntu-release 2014-07-05
<zequence_> cjwatson: I've been trying to get upload rights for those myself, in which case I would do that promptly. There's no panic yet, as we have barely summed up our feature specs.
<zequence_> cjwatson: Any chance we could get some help on getting that new ISO built? I would change the seeds, but don't want to mess things up.
<infinity> cjwatson: Does LP: #1334616 need fixing in trusty too, or are none of our trusty images affected?
<ubot93> Launchpad bug 1334616 in livecd-rootfs (Ubuntu Precise) "Try harder to make sure that kernel output is world-readable" [High,In progress] https://launchpad.net/bugs/1334616
<cjwatson> infinity: We don't build any trusty images using ubuntu-defaults-image, so I decided I didn't care all that much
<infinity> cjwatson: Fair enough.  A bit of a trap if someone tries to use livecd-rootfs/trusty to do that, but I guess not a big deal for official images.
<infinity> (And I'm unconvinced anyone successfully uses it outside the DC)
<infinity> Well, anyone other than you and I.
<cjwatson> infinity: Lots of livefs build failures in various places complaining about uninstallable kernels.  Are overrides wrong or something?
<cjwatson> (I haven't looked in detail ...)
<cjwatson> zequence: Yep, I'll have a go at it in the coming week
#ubuntu-release 2014-07-06
<infinity> cjwatson: Oh, if the failures are in proposed, that's totally expected.  Will fix.
<infinity> cjwatson: proposed got rolled back to make way for a security update.
<cjwatson> infinity: Aha
<infinity> cjwatson: Fixing that now.  Just got home.
<infinity> cjwatson: Fixed for the next publisher run.
<cjwatson> Ta
<infinity> cjwatson: I still can't decide if being able to copy deleted packages back in to a series is "wrong", but it sure is handy.
<wgrant> It's both, as we've found on several occasions!
<infinity> wgrant: Well, it's handy enough, that I think we probably want to preserve the behaviour in the redesign.
<wgrant> Oh most certainly.
<wgrant> It's wrong in a lot of ways, but also invaluable.
#ubuntu-release 2015-06-29
<Odd_Bloke> Do we have an EOL date for utopic yet?
<coreycb> infinity, would you be able to review  the oslo.messaging sru in the trusty queue?  we're waiting on that before testing the recent stable icehouse release in proposed.
<mdeslaur> Odd_Bloke: hrm, july 23rd I guess
<mdeslaur> infinity: We need to send out the Utopic EoL notice
 * cjwatson massively speeds up http://people.canonical.com/~ubuntu-archive/testing/ and http://people.canonical.com/~ubuntu-archive/testing-ports/ generation
<cjwatson> rewrote the uninstallability analysis on top of dose-debcheck
<cjwatson> hopefully will cause that to block other archive jobs less often
<cjwatson> apw: ^-
<cjwatson> 7m23s -> 17s for the wily ports job given current data
<apw> cjwatson, woh now that is some saving in time ...
<cjwatson> quite how extreme it is depends on the number of uninstallables; it's not quite as dramatic for primary, but still
<apw> cjwatson, even if it only saved that time on wily, thats a fair chunk of an hour right there, worth your time for sure
<infinity> mdeslaur: I'm only doing 21d notice for 9mo releases (but, yeah, that's coming up).
<mdeslaur> infinity: cool, great
#ubuntu-release 2015-06-30
<tseliot> infinity: hey, can you approve nvidia-graphics-drivers-346, nvidia-graphics-drivers-346-updates, nvidia-graphics-drivers-340, nvidia-graphics-drivers-340-updates in New (trusty-proposed), please?
<tseliot> infinity: or tjaalton won't be able to review them for the SRU
<coreycb> RAOF, arges: can one of you review  the oslo.messaging sru in the trusty queue?  we're waiting on that before testing the recent stable icehouse release in proposed.
<arges> coreycb: its almost midnight in his tz, so I'll take a look
<coreycb> thanks arges
<sil2100> Dear release team, could you discard the network-manager upload that just happened to vivid? Thanks ;) Version 0.9.10.0-4ubuntu15.1.4
<sil2100> This should have landed in the overlay instead...
<cyphermox> slangasek: thanks ^
<slangasek> cyphermox: no problem
<slangasek> sil2100: done
<rbasak> Please can someone reject docker.io from utopic and vivid unapproved, as we have replacements to supercede them that fix a couple of additional issues we found? Leave trusty though - that one is good to go.
<slangasek> rbasak: done
<rbasak> Thank you!
<bdmurray> slangasek: thinking about the sru-verification team and sru-remove I think the easiest thing is to just add ubuntu-sru to sru-verification as the other option (not using the team anymore) would require a fair bit more work (fixing tools, unsubscribing the team from existing bugs, some documentation updates)
<slangasek> bdmurray: ack
<bdmurray> the other option makes sense, but doesn't seem worth the effort right now
<bdmurray> slangasek: I've invited ubuntu-sru to the sru-verification team
<slangasek> bdmurray: accepted, thanks
#ubuntu-release 2015-07-01
<doko> Laney, are you able to setup a transition tracker?
<Laney> doko: Yes, ~ubuntu-transition-trackers is the relevant team.
<doko> Laney, for libstdc++6 (not yet starting, but I would like to get an idea ...) I assume the goal would be dependencies on libstdc++6 (>= 5)
<Laney> doko: Could you supply a .ben file please? lp:~ubuntu-transition-trackers/ubuntu-transition-tracker/configs has examples
<doko> Laney, how can I test ben files?
<Laney> you can set ben up locally (it's in the archive), or we can iterate on the running installation
<doko> hmm, can't find an example which uses versions ...
<Laney> http://people.canonical.com/~ubuntu-archive/transitions/html/r-base.html ?
<doko> how do I write libstdc++6 without version information, just add a $?
<doko> Laney: http://paste.ubuntu.com/11804485/
<cjwatson> ($|,) IIRC
<cjwatson> You need to escape the literal () there
<doko> yep, http://paste.ubuntu.com/11804499/
<cjwatson> And the .*) or .*\) is kinda pointless, that just asserts lack of syntax error :)
<doko> http://paste.ubuntu.com/11804509/
<Laney> doko: cjwatson: lunch calls, feel free to push it
<doko> not a member
<cjwatson> doko,Laney: committed
<doko> thanks. when will it show up?
<cjwatson> next run
<cjwatson> should be under half an hour or so
<cjwatson> probably less, it's already 10min since the last run
<rbasak> How do I go about getting an answer from the release team about nginx? And is this something that is within the mandate of the relese team or does it need to go to the TB?
<doko> cjwatson, Laney: can I add exclusions for packages where I know they are not needed?
<cjwatson> doko: You can add .package conditions to is_good, I suppose, or just ignore them
<cjwatson> doko: http://ben.debian.net/#_query_language
<Laney> That r-base one has exclusions
<cjwatson> oh yeah, is_affected is a better place to put them
<doko> please could somebody accept the cross toolchain updates for trusty? just building from the sources of the accepted binutils and gcc-4.8 packages
<doko> please could somebody look at python3 for trusty?
<sil2100> Hello release team! I'm looking for an archive admin to ACK the renamed binary packages due to the API/ABI bump
<sil2100> https://ci-train.ubuntu.com/job/ubuntu-landing-013-2-publish/62/artifact/platform-api_packaging_changes.diff
<sil2100> slangasek, infinity: ^ (sorry for the direct ping)
<slangasek> sil2100: would prefer a pointer to the silo, not the raw diff
<slangasek> s/silo/dashboard entry/
<sil2100> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-013 <- here's the silo PPA for instance
<sil2100> http://people.canonical.com/~platform/citrain_dashboard/#?q=ubuntu%2Flanding-013
<sil2100> Dashboard entry
<slangasek> sil2100: jenkins shows packaging_changes diffs for 5 packages in that silo, have the others already been signed off?
<sil2100> slangasek: yes, I checked those, they're sane and for packages in the universe, mostly those changes are for the bump
<slangasek> ok
<slangasek> heh, somebody should clean up the dummy transitional packages in there
<slangasek> sil2100: acked, publishing
<sil2100> Thanks! :)
<slangasek> RAOF: it looks like you accepted shim-signed into precise-proposed yesterday?  there's a shim sync that needs to go with that (and shim and shim-signed syncs for all the other releases)
<RAOF> slangasek: Ok. I accepted shim-signed into precise-proposed because it wasn't documented as requiring shim, and it had an obvious bug and way of tracking it. How are we tracking the shim sync (and the shim-signed syncs for other releases)?
#ubuntu-release 2015-07-02
<slangasek> RAOF: because it's a binary sync, there's no room for SRU bugs to be added; so it's out-of-process
<RAOF> slangasek: Fair enough. I guess you shepherd it through?
<slangasek> I can, yes
<RAOF> I was more thinking the post-acceptance shepherding, but that's good too :)
<slangasek> :)
<RAOF> slangasek: Oh, thinking of binary syncs - trusty-unapproved has a unity-control-center sync from a landing PPA. I went to review it, but as far as I can tell the source is inaccessible to me (the landing PPA has had all its contents wiped many times over since that sync was proposed).
<RAOF> I presume that launchpad has the relevant bits refcounted somewhere; do you know how to access them to do a review?
<slangasek> RAOF: if I'm not mistaken, you can do a 'queue fetch' to grab the source?
<cjwatson> I'm not even sure it's processable any more in that case
<slangasek> you just can't get a diff
<cjwatson> Copies aren't properly refcounted, which is part of the slightly-amorphous "Soyuz queue redesign" item on the LP stakeholders agenda
<cjwatson> But you can try "queue fetch"; if that doesn't work the sync is probably dead
<cjwatson> And somebody should poke the CI Train folks and/or the silo owner for allowing that silo to be cleaned in advance of the sync being processed
<slangasek> robru: ^^ the silo process should already provide guidance regarding this case, I think?
<infinity> Yeah, they're aware of this.  They often prod directly for reviews when silo space is getting low.
<infinity> So someone cleared that one by accident, I'd guess.
 * RAOF learns about the queue tool
<robru> slangasek: what are we talking about? An sru? If the silo isn't present it was likely freed or abandoned...
<cjwatson> I can't check the citrain logs for who did it, since I think it was before the last redeployment
<RAOF> So, queue only seems to be able to grab the _source.changes; is it expected to grab the full source package?
<slangasek> robru: yes, an SRU; silos aren't meant to be freed before the SRU is accepted, I believe?
<cjwatson> RAOF: Yes, but it's not going to be able to here.  The only thing to do is to reject it.
<infinity> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-001/+packages?field.name_filter=unity-control-center&field.status_filter=&field.series_filter=
<infinity> It might still be there, however.
<cjwatson> Hm, really?
 * cjwatson looks
<cjwatson> That's just a historical record, no still-present files attached.
<infinity> Nope, it's dead.
<infinity> Yeah.
<robru> slangasek: RAOF: yeah the silo should not have been freed. If the silo is gone if say just skip it, is the landers responsibility to make a new silo
<slangasek> robru: I mean: it's important that the silo not be freed for an in-process SRU until the SRU is accepted; and I believe this is the understood process already
 * slangasek nods
<infinity> RAOF: Reject it, it's all you can do.
<RAOF> Yeah, I could find the build logs, but they had no active links.
<RAOF> infinity: Already done.
<RAOF> Also, yay for learning about the queue command.
<RAOF> That's going to make processing SRU syncs much nicer!
<cjwatson> As far as Soyuz internals go, the unapproved copy is basically not a lot more than an archive, series, package name, and version
<robru> RAOF: what silo was this? It's been over a month since i freed an SRU due to being low on silos
<cjwatson> robru: ubuntu/landing-001
<RAOF> robru: silo 001
<slangasek> having queue diffs for syncs would be nicer yet, but yes, 'queue' does in a pinch :)
<cjwatson> And this is basically the same reason that proper queue diffs for copies are currently a hard problem
<robru> Hmmmmmmm yeah i think it was me that freed that one, strange you guys are just noticing now.
<RAOF> slangasek: Well, my previous method was to go to the relevant PPA and fiddle around to wget the links. :)
<infinity> queue diffs will come with soyuz redesign.  Feel free to put more pressure on people outside Foundations to understand the importance of that. :P
<cjwatson> LP would have to basically process the first half of the copy to track down the publications involved
<infinity> RAOF: wget?  Not even dget?  Heathen.
<RAOF> infinity: Last time I tried it, dget fails from PPAs because of annoying url reasons?
<infinity> RAOF: Also, depending on your bandwidth, you still might want to navigate-and-dget/wget, since "queue fetch" will grab the *entire* copy, including binaries.
<cjwatson> queue fetch --source
<cjwatson> HTH
<RAOF> Learning all round!
<infinity> Oh, yeah, there are some LP pages that fail miserably at dget.
<robru> slangasek: i freed that one back when we only had 30 silos and there was a huge crunch. It'll need to be redone unfortunately.
<robru> Whoever was on charge of that did a poor job of following through with it, i freed it because it sat on a silo for 2 months
<cjwatson> infinity: The thing is that it's almost impossible to communicate to people without doing the "write up requirements properly" part of the redesign.  I hear that you and William were making some progress on that ...
<infinity> cjwatson: We were making progress on scheduling a time to make progress on it...
<infinity> cjwatson: We might need to form a committee to help find a time.
<cjwatson> Ha.  Pls to be doing it soon so that I stop having to indirectly fend off annoyed stakeholders who think it's too high up our agenda :P
<infinity> cjwatson: I was kinda hoping you and little Willy would flesh it out without much need for input from me, since you've been on both sides of the fence and know what sucks, and he knows how it needs to be unsucked.
<cjwatson> I'm happy to try to help, but every time I ask I hear you have the baton :)
<cjwatson> So if it's OK to have a go at it on the principle that the best way to get answers on the internet is to produce something incorrect, then sure
<infinity> cjwatson: Hah.  I trust you not to be Lennart.
<slangasek> robru: right; so not that it's a common occurence, but when those silos get freed it's probably a good idea to follow up with the sru team and have us remove it from the queue at the same time, or else nag us into processing it from the queue so it /doesn't/ have to get freed prematurely
<robru> slangasek: yeah fair point. I try to never do that but we were really crunched at the time and there was a big push to get some landings in for whatever milestone was happening at the time
<RAOF> Hey super release friends! Does anyone have the policies for what we can upload to landing PPAs destined for vivid-overlay?
<RAOF> Specifically - the Mir landing PPA needs a new glmark2 with some changes required to build against the new Mir. Can we be lazy and just upload the wily glmark2 (which has those changes, plus some others), or do we need to do the sensible thing and add a minimal patch to update it?
<RAOF> For bonus points - where is this documented? âº
<infinity> RAOF: The Ubuntu Release Team has zero influence over the phone overlay PPA.
<RAOF> Grr
<infinity> RAOF: Arguably, the whole point of it is to circumvent things that ubuntu-release and ubuntu-sru policy would forbid. :P
 * RAOF thinks you can drop the âArguablyâ :P
<infinity> RAOF: Anyhow, looking at how people have been doing vivid-overlay/wily dual landings, I'd assume that "just use the wily version with a backport version number and a rebuild" would probably be fine, if the changes aren't drastic.
<RAOF> Eh, sure. Why not. Substantially less than half of it changed :)
<rbasak> How do I go about getting an answer from the release team about nginx? And is this something that is within the mandate of the relese team or does it need to go to the TB?
<mdeslaur> could python-django be migrated please, the two test failures were failing before
<kickinz1> infinity: any eta for docker.io sru?
<infinity> kickinz1: I'm out until Monday.  If I get bored, I might look, but otherwise, you'll want another SRU person, or to bug me next week.
<kickinz1> infinity, OK, sorry.
<balloons> infinity, do we have an official EOL date for utopic? I haven't seen it, and it should be soon yes?
<Odd_Bloke> balloons: FYI, "16:00:35 < infinity> kickinz1: I'm out until Monday."
<balloons> Odd_Bloke, ty
<Riddell> anyone know what's stopping ktp-* from transitioning? it all installs fine for me
<Laney> Riddell: At least ktp-call-ui krfb (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt search for "Trying easy from autohinter: telepathy-logger)
#ubuntu-release 2015-07-03
<rbasak> infinity, Daviey, Laney, Riddell, ScottK, tumbleweed, slangasek, stgraber: opinion on nginx request please? Not had an answer from anyone yet :-(
<rbasak> (skaet and pitti don't appear to be online)
<rbasak> I'd prefer for you to send me up to the TB if that is what is required.
<Daviey> rbasak: that was just what i was thinking. Writing a response now
<rbasak> Thank you!
<darkxst> infinity, can you take at my comments re webkit2gtk-4.0 mess on bug 1466290? Its highly unlikely that a proper transition can happen anytime soon
<ubot93> bug 1466290 in gnome-online-accounts (Ubuntu) "Update to 3.16" [Undecided,Fix released] https://launchpad.net/bugs/1466290
<ogra_> *sniff* ... there goes the unicorn ...
<infinity> ogra_: You still have three weeks to enjoy its fluffy goodness.
<ogra_> heh, i left it behind already :)
<infinity> So did I, obviously, but I still use the unicorn wallpaper.
<infinity> It was actually quite nice.
<ogra_> yeah, finally something to replace the heron :P
<infinity> adconrad@nosferatu:~$ dpkg -S Unicorn
<infinity> ubuntu-wallpapers-utopic: /usr/share/backgrounds/Utopic_Unicorn__by_Bedis_ElAchÐche.jpg
<ogra_> kwwii's best work :)
<infinity> That one.
<infinity> Looks really nice on an LCD with good color saturation.
<ogra_> yeah
<cjwatson> I use that one too
<Daviey> infinity: meh, the rest of us just use warty-final-ubuntu.png
<Laney> I hate unicorns now, since *that* picture
<infinity> Laney: don't tell msm.
<cjwatson> Laney: You clearly need to read http://www.tor.com/2013/09/24/equoid/, nice fluffy harmless unicorn story [*]
<cjwatson> [*] may be a lie
<infinity> I don't want to click on that, do I?
<Laney> It's quite long - I'll postpone the end of my life as I know it until over the weekend. :)
<cjwatson> It's safe for work, just not for brain.
<cjwatson> (Also a Cold Comfort Farm parody, in part)
#ubuntu-release 2015-07-04
<tumbleweed> jamespage: python-testtools is getting a good few packages caught up in -proposed, thanks to ADT failures
#ubuntu-release 2016-07-04
<LocutusOfBorg> pretty please kick dpkg out of -proposed? :)
<LocutusOfBorg> rationale: debian bug 829542
<ubot5> Debian bug 829542 in dpkg-dev "dpkg-dev: dpkg-buildpackage misses import of Dpkg::Control::Info" [Grave,Fixed] http://bugs.debian.org/829542
<LocutusOfBorg> :( fixed dpkg doesn't build because of broken dpkg
<pitti> I removed the faulty dpkg
<LocutusOfBorg> <3
<jamiebennett> Can anyone unblock the golang-gopkg-macaroon package in the upload queue? - https://launchpad.net/ubuntu/xenial/+queue
<pitti> jamiebennett: done
<jamiebennett> thanks pitti !
<pitti> the SRU team does not regularly look at NEW
<pitti> so this needs special prodding
<ogra_> infinity, hmm, does the extra_ppas value on https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/ have anything to say ? (note that nusakan actually invokes EXTRA_PPAS=snappy-dev/image)
<infinity> extra_ppas [u'ubuntu-foundations-team/ubuntu-core-system-image']
<ogra_> right
<ogra_> thats dead beef
<infinity> That should be fixed?
<ogra_> i'll soon switch to snappy-dev/edge ...
<infinity> ogra_: Deleted.
<ogra_> thx
<ogra_> i assume it had no influence on builds anyway ... only vivid in there
 * infinity nods.
<ogra_> infinity, another thing is that i'm supposed to build a preinstalled server image for dragonboard ... but the bootloader bits will be legally problematic i fear
<ogra_> (i got something booting locally, but have no idea hoiw i should package the binary blobs needed for it)
<ogra_> the blobs come from http://builds.96boards.org/releases/dragonboard410c/linaro/rescue/latest/dragonboard410c_bootloader_emmc_linux-40.zip
<ogra_> and there is a little-kernel i use at http://git.linaro.org/landing-teams/working/qualcomm/lk.git
<ogra_> (i guess the latter is fine, its just linux ... )
<ogra_> oh, the blobs actually got updated to v50
<ogra_> infinity, http://paste.ubuntu.com/18449924/ ... specifically 1.2  section ii
<infinity> ogra_: We have a kernel in the archive.
<infinity> ogra_: But yeah, the firmware is problematic.
<ogra_> infinity, right
<ogra_> (i wonder how3 linaro can actually offer it like that)
<infinity> ogra_: That's a 404.
<infinity> Oh, -50
<ogra_> yeah ... http://builds.96boards.org/releases/dragonboard410c/linaro/rescue/latest/dragonboard410c_bootloader_emmc_linux-50.zip
<ogra_> my link was old
<ogra_> but see the pastebin, thats the license
<ogra_> line 34-37 are the interesting ones i guess
<ogra_> to me that reads like: you can distribute it as part of an image, but not as a package in the archive
<infinity> That seems sufficiently free for multiverse.
<ogra_> oh,. ok
<infinity> Nah, a package in the archive is still part of a larger project (Ubuntu).
<ogra_> oh
<ogra_> great ... i'll package it up then
<infinity> I think that's the same license that dragonboard-firmware has already.
<infinity> Or whatever it's called.
<ogra_> never heard of that :)
<infinity> https://launchpad.net/~p-pisati/+archive/ubuntu/embedded
<ogra_> yeah
#ubuntu-release 2016-07-05
<plashenkov> RAOF: Hello, Chris, there is a âverification-doneâ issue here: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1574693 Please could you release it to updates? Or, if it is currently not possible, when it could be released?
<ubot5> Launchpad bug 1574693 in gtk+3.0 (Ubuntu Xenial) "No shadows under menus on Unity." [Undecided,Fix committed]
<RAOF> plashenkov: That's been in -proposed for 4 days; standard proceedure is to let it bake in -proposed for 7 days before it's a candidate for promotion to -updates.
<RAOF> plashenkov: (See also: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure )
<RAOF> plashenkov: The 7-day baking period can be waived if there's an âobviously-safeâ (HAH) patch and/or the bug fixed is super-important. It doesn't look like this bug qualifies for that?
<plashenkov> RAOF: I.e. it will take longer period?
<RAOF> plashenkov: Yeah. Unless there's some particular reason why it should be pushed out quicker it'll become a valid candidate to promote to -updates in 3 days.
<plashenkov> RAOF: Well, okay. I look forward :)
<lordievader> Good morning
<jamespage> pitti, hey - can we move forward on the sru under bug 1585660 now?
<ubot5> bug 1585660 in ceph (Ubuntu Xenial) "[SRU] ceph 10.2.2" [High,New] https://launchpad.net/bugs/1585660
<jamespage>  I'd like to get that rolling through the process
<jamespage> (apologies if that duped - bad network connection)
<jamiebennett> Can someone give me feedback on the SRU for ubuntu-core-launcher 1.0.34 - https://bugs.launchpad.net/ubuntu/+source/ubuntu-core-launcher/+bug/1593396 ? There are a number of fixes that we are waiting on so I'm keen to see it progress.
<ubot5> Launchpad bug 1593396 in ubuntu-core-launcher (Ubuntu Xenial) "[SRU] 1.0.34" [Undecided,New]
<mwhudson> jamiebennett: it's a tangent but is there a plan to start uploading that as a non-native package?
<mwhudson> jamiebennett: i'm probably going to upload that as 1.0.34-1 to debian tomorrow and as there's no ubuntu in the package version i think autosync will try to copy it over your package...
<jamiebennett> mwhudson: For non-native, it is something we are planning for later, yes
<mwhudson> jamiebennett: also you're probably not the person to complain to about this, but where did the tarball for the package in https://launchpad.net/ubuntu/yakkety/+queue come from? it doesn't seem to match the release on https://github.com/snapcore/snap-confine/releases
<mwhudson> (i think maybe the one in the upload queue is a straight git export and the one on github is the output of some 'make dist' type thing?)
<jamiebennett> mwhudson: I'm not sure. You could ping mvo if you need an answer.
<mwhudson> jamiebennett: yeah, i thought the same and just did in #snappy :-)
<flocculant> infinity: now that balloons wandered off I'm never really sure who to mention things to, but I've confirmed this in us and Ubuntu, not confirmed in lubuntu but I think they've not built latest yet > bug 1599174
<ubot5> bug 1599174 in ubiquity (Ubuntu) "dpkg seg fault warning during install" [Undecided,Confirmed] https://launchpad.net/bugs/1599174
 * balloons would say "floated"
<flocculant> ha ha
<infinity> flocculant: Lovely. :/
<flocculant> yup
<flocculant> thought I'd best tell someone ;)
<infinity> Wish you hadn't, since it's likely my fault. :P
<flocculant> infinity: ha ha
<flocculant> though I can at least tell you that dpkg doesn't appear to affect installed systems - as I got it ~6 hours ago locally and have installed/updated *things* since
<flocculant> *that* dpkg
<seb128> willcooke, ^ that looks like the issue you hit earlier trying the daily
 * willcooke reads
<willcooke> yeah, looks like it
<seb128> good, I was about to download a daily to see if I had the issue/confirm it was one thing we need to look at, seems I don't
<seb128> need to
<willcooke> same deal, ok in lubuntu not ok in Ubuntu
<flocculant> willcooke: lubuntu hasn't built yet *today*
<willcooke> h
<willcooke> ha
<tsimonq2> flocculant: huh?
#ubuntu-release 2016-07-06
<slangasek> arges: hi, can I get some support in expediting SRU for bug #1596638?
<ubot5> bug 1596638 in lsb (Ubuntu Xenial) "python2 cannot import lsb_release on yakkety and now xenial" [Critical,Triaged] https://launchpad.net/bugs/1596638
<arges> slangasek: ok i'll take a look in a bit
<slangasek> arges: ta
<slangasek> this is a critical SRU regression
<arges> slangasek: did it get fixed in yakkety?
 * slangasek re-promotes the various perl modules that were in main through wily and are being pulled back in via the new licensecheck package
<slangasek> arges: it's in yakkety-proposed now
<arges> ok reviewing lsb/xenial now
<jamiebennett> mwhudson: We talked about snap-confine SRU yesterday, can you help to push this through please?
<jamiebennett> Any anyone else from the release team today?
<jamiebennett> Happy to field questions
<Ukikie> !info snap-confine unstable
<ubot5> snap-confine (source: snap-confine): Support executable to apply confinement for snappy apps. In component main, is optional. Version 1.0.34-1 (unstable), package size 23 kB, installed size 69 kB
<mwhudson> jamiebennett: i can get it in to the queue at least, i'm not on the SRU team
<mwhudson> jamiebennett: is there an SRU bug?
#ubuntu-release 2016-07-07
<RAOF> jamiebennett: I'm an SRU team member; if you coordinate with mwhudson about an SRU bug & upload, I'm happy to review.
<tjaalton> infinity: I hadn't noticed you acked the lts drivers already, so I've no uploaded the last missing bit, xorg-lts-xenial..
<infinity> tjaalton: Danke.
<infinity> tjaalton: Is that the list bit?
<tjaalton> last, yes
<infinity> Err, yes.  last. :P
<infinity> I'll review it this morning, flip the dailies over, and people can get to testing, hopefully.
<tjaalton> there's an image building for an oem team right now, with this from the ppa
<Laney> Ttrying nto load that site
<Laney> argh
<doko> python-cryptography (1.3.1-2 to 1.4-1)
<doko> Maintainer: Tristan Seligmann
<doko> 13 days old
<doko> python-cryptography/amd64 unsatisfiable Depends: python-cffi-backend-api-min (<= 9729)
<doko> python-cryptography/amd64 unsatisfiable Depends: python-cffi-backend-api-max (>= 9729)
<doko> are we not able to handle versioned provides?
<infinity> Possibly not.
<doko> which package to file an issue?
<infinity> Not sure if we have a project to track britney issues.
<infinity> Odd are we just need to merge with Debian, unless this package is stuck there too.
<doko> yes, migrated
<cjwatson> infinity: should be a merge, yes
<cjwatson> possibly a complicated one
<cjwatson> that support was added in Debian relatively recently
<infinity> pitti: Could you look into merging britney from Debian, so we can haz versioned provides support?
<pitti> infinity: yeah, that's been on my list for a while; they dropped the RDEPENDS list though, I need to see whether there's a replacement (I think there is)
<pitti> infinity: that's because of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-cryptography ?
<infinity> pitti: Yeah.
<pitti> we have such an enormous delta, that's going to take some effort
<pitti> maybe I should convert our bzr branch to git first, so that I can do some sensible rebasing; would you mind moving to git?
<infinity> pitti: All for it.
<infinity> tjaalton:
<infinity> -Package: xserver-xorg-video-all
<infinity> +Package: xserver-xorg-video-all-lts-xenial
<infinity>  Architecture: any
<infinity>  Depends:
<infinity>   xserver-xorg-video-amdgpu [!hurd-any !kfreebsd-any !s390x],
<infinity> - xserver-xorg-video-ati [!hurd-any !s390x],
<infinity> - xserver-xorg-video-fbdev [!s390x],
<infinity> + xserver-xorg-video-ati-lts-xenial [!hurd-any !s390x],
<infinity> + xserver-xorg-video-fbdev-lts-xenial [!s390x],
<infinity> tjaalton: What's wrong with that first depends line?
<tjaalton> ha
<infinity> tjaalton: input has similar issues.
<infinity> tjaalton: For synaptics.
<tjaalton> and can drop kbd/mouse
<infinity> tjaalton: Drop or not, doesn't matter, since it's arch-qualified to oblivion.
<infinity> tjaalton: Rejected for the other two issues, though.
<tjaalton> true
<pitti> infinity: awesome, bzr fast-export crashes on a UnicodeDecodeError *sigh*
<infinity> pitti: Watch me be shocked.
<tjaalton> infinity: uploaded a new one
<infinity> tjaalton: Ta.
<infinity> pitti: I hope your infra is happy today, I'm going to copy over a glibc to -proposed in a few minutes.
<pitti> infinity: yes, it is
<pitti> infinity: not for long :)
<infinity> Heh.
<infinity> I can upload perl and kdelibs too, if that will help?
<pitti> infinity: please, and new pythons
 * pitti goes to clean up the armhf runners then
<pitti> infinity: one s390x machine is AWOL again (10.100.0.12), it would help if you could resussitate that?
<infinity> cpaelzer: ^
<infinity> pitti: I keep forgetting how.  I'm a bad mainframe user.
<cpaelzer> infinity: ? ... reading
<cpaelzer> infinity: I won't have the logins needed but you surely have - let me try to help sorting out what needs to be done :-)
<cpaelzer> infinity: I guess you want to log into the z/VM host and "restart" it, that means knowing the disk it is bootet from and ipling from it - is that what you want to do?
<infinity> cpaelzer: Probably? :P
<cpaelzer> infinity: ok, let me try how far I get without asking you for passwords to foundation/LP machines
<infinity> I thought you bounced it for pitti last time.  Maybe it was xnox.
<pitti> yes, usually xnos, and sometimes tinoco
<cpaelzer> they both have the logins needed for your z/VM host
<infinity> I might.  But not sure.
<infinity> I have a logon here for something. ;)
<infinity> Not the right something.
<cpaelzer> steps that have to be taken: 1. find which guest that IP belongs to - it was (?intentionally?) not added to the systemz HW doc
<infinity> So maybe we want an xnox or tinoco.
<cpaelzer> I guess it is LM120C (C=12)
<cpaelzer> then log into the z/VM Host and IPL it from there - yes you want one of the two
<cpaelzer> and you can ask them that they share the logins with me so I can help another day if you have trouble early in the day
<cpaelzer> infinity: well if you sign it off I can ask them, but I'd need some sort of authorized ack for that request
<cpaelzer> not to say I could shred all your disks, but at least I couldn't read them - so it's safe
<infinity> cpaelzer: If all you ever do is handle reboot requests, I'm sure I can trust you to do that. :P
<cpaelzer> lol
<infinity> tjaalton: That looks more plausibly correct.
<tjaalton> infinity: great, thx
<infinity> pitti: I'm curious how you're killing yours.  Other than the posixtestsuite vs. kernel thing, I've not been able to kill my z/VM buildds.
<infinity> pitti: And I sure try.
<pitti> heh, I wish I'd know
<pitti> as soon as it dies, I have no access to it whatsoever
<pitti> but we did install kerneloops back then
<infinity> And no reasonable logging to see what it was doing right before death?
<pitti> maybe it left a pile of poo somewhere
<pitti> well, we do have the worker logs, so we know which test ran
<pitti> but that's not very insightful, as it happens with several different ones which also run fine at other times
<infinity> Irksome.
<pitti> infinity: https://git.launchpad.net/~ubuntu-release/+git/britney2-ubuntu \o/
<pitti> (just a straight import, no rebase/merge yet -- I'll start that after lunch)
<infinity> [ubuntu/yakkety-proposed] glibc 2.23-1ubuntu1 (Accepted)
<infinity> pitti: ^-- Enjoy.
<teward> would it be far-fetched to presume July 22nd is the EOL date for 15.10?
<teward> going by 9 months' time, and the date of its initial release
<infinity> teward: Might be a bit later than that, but ish.
<teward> infinity: just trying to ballpark it - over on Ask Ubuntu I have a habit of trying to give 1 months notice about the EOL date :p
<infinity> teward: I give 3 weeks.
<infinity> For non-LTS.
<teward> ack
<infinity> Usually.
<infinity> I suppose I could cut this one down a bit.
<infinity> But I think I'll EOL on the 28th.
<infinity> Which means an announce todayish.
 * infinity goes copy-and-pasting.
<teward> heh
#ubuntu-release 2016-07-08
<cyphermox> ~ ooga booga ~ raising yet another shim backport.
<cyphermox> slangasek: ^
<slangasek> cyphermox: copy :)
<yofel> could someone please look at the SRU upload for bug 1560404 in xenial-proposed? I would like to have that on the 16.04.1 images
<ubot5> bug 1560404 in plasma-framework (Ubuntu Xenial) "Live session desktop uses to small folder view widget " [High,Triaged] https://launchpad.net/bugs/1560404
<LocutusOfBorg> slangasek, thanks! you can ask here if you want a speedy answer about the yakkety packages removals, I guess I fixed the reverse-deps
<apw> yofel, that upload seems to have a possibly spurious change to the changelog dates for an older entry ?
<LocutusOfBorg> "fixed" in the meaning that they have to go :)
<yofel> apw: ups, checking
<flocculant> stgraber: the iso tracker doesn't appear to be updating bugs e.g. a bug reported against entire disk doesn't show up in the list of bugs, also when you do put something in against a test it shows the No Info about this bug if you mouseover
<yofel> apw: ah right, that was me not doing the previous upload properly from git. Could you let that pass? ^^
<apw> yofel, so that is the correct date now (for some definition of correct) ok
<yofel> right
<apw> yofel, done
<yofel> apw: thanks!
<infinity> slangasek: Can you verify (or get someone to verify) your d-i in trusty-proposed, so I can do some pre-point-release bits on top?
<stgraber> flocculant: the bug update task was stuck so I restarted it, then it blew up on some private bug or something. I added a bit of code to skip in such situations and it's running again now.
<flocculant> stgraber: cheers :)
<stgraber> flocculant: looks like we have bug info again
<flocculant> \o/
<flocculant> stgraber: thanks - have a good weekend :)
<slangasek> infinity: verification done
<infinity> slangasek: Ta.
#ubuntu-release 2016-07-09
<flocculant> seems the download links for xenial on the tracker are wrong - not sure what's going to be wanted for testing prior to .1 release of that - bug 1600458
<ubot5> bug 1600458 in Ubuntu QA Website "Xenial daily download links on QA Tracker are broken" [Undecided,New] https://launchpad.net/bugs/1600458
#ubuntu-release 2017-07-03
-queuebot:#ubuntu-release- Unapproved: golang-1.6 (xenial-proposed/main) [1.6.2-0ubuntu5~16.04.2 => 1.6.2-0ubuntu5~16.04.3] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted asn1crypto [amd64] (artful-proposed) [0.22.0-1]
-queuebot:#ubuntu-release- New: accepted fortune-zh [amd64] (artful-proposed) [2.4]
-queuebot:#ubuntu-release- New: accepted ruby-html2text [amd64] (artful-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-po-to-json [amd64] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted ruby-tool [amd64] (artful-proposed) [0.2.3-1]
-queuebot:#ubuntu-release- New: accepted ruby-omniauth-oauth2-generic [amd64] (artful-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted ruby-validates-hostname [amd64] (artful-proposed) [1.0.7-1]
-queuebot:#ubuntu-release- New: accepted ruby-string-direction [amd64] (artful-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- Unapproved: mythtv (zesty-proposed/multiverse) [2:0.28.0+fixes.20170206.03f4403-0ubuntu3 => 2:0.28.0+fixes.20170206.03f4403-0ubuntu3.1] (mythbuntu)
-queuebot:#ubuntu-release- New binary: dj-database-url [amd64] (artful-proposed/none) [0.4.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: tryton-modules-stock-shipment-measurements [amd64] (artful-proposed/none) [4.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted dj-database-url [amd64] (artful-proposed) [0.4.2-2]
-queuebot:#ubuntu-release- New: accepted tryton-modules-stock-shipment-measurements [amd64] (artful-proposed) [4.4.0-1]
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.26.4~14.04 => 2.26.7~14.04~ppa1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (trusty-proposed) [2.26.7~14.04~ppa1]
<apw> ^ intended for a different archive
<ginggs> many armhf autopkgtests are failing since Friday evening with "dpkg: dependency problems prevent configuration of ubuntu-minimal: ubuntu-minimal depends on udev; however:  Package udev is not configured yet." they appear as  "autopkgtest for <package>/unknown: armhf: Regression" on update_excuses
<ginggs> I've retried many of them and they pass
<apw> ginggs, well that is something
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-28.32] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-28.32]
<jamespage> Hi SRU team - this bug
<jamespage> https://bugs.launchpad.net/ubuntu/+source/keystone/+bug/1649616
<ubot5> Ubuntu bug 1649616 in keystone (Ubuntu Yakkety) "Keystone Token Flush job does not complete in HA deployed environment" [High,In progress]
<jamespage> still needs review for proposed entry into xenial and yakkety pretty please
<apw> jamespage, i think i have let you down on that one a couple of times ...
-queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (yakkety-proposed) [2:10.0.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted keystone [source] (xenial-proposed) [2:9.3.0-0ubuntu2]
<apw> jamespage, ^ ok done
<jamespage> apw: thanks!
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.11.0-10.15] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.11.0-10.15]
-queuebot:#ubuntu-release- Unapproved: mythtv (xenial-proposed/multiverse) [2:0.28.0+fixes.20160413.15cf421-0ubuntu2 => 2:0.28.0+fixes.20160413.15cf421-0ubuntu2.16.04.1] (mythbuntu)
-queuebot:#ubuntu-release- Unapproved: mythtv (yakkety-proposed/multiverse) [2:0.28.0+fixes.20160413.15cf421-0ubuntu2 => 2:0.28.0+fixes.20160413.15cf421-0ubuntu2.16.10.1] (mythbuntu)
<ahasenack> hi, can someone please accept my nominations for https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1701073 ?
<ubot5> Ubuntu bug 1701073 in samba (Ubuntu) "CVE-2017-2619 regression breaks symlinks to directories" [High,In progress]
<ginggs> ahasenack: done
<ahasenack> thx
<mdeslaur> ahasenack: don't SRU that, I'll do it as a security regression fix
<ahasenack> mdeslaur: oh?
<mdeslaur> ahasenack: I have another CVE to fix at the same time also
<ahasenack> mdeslaur: I see, timeline?
<mdeslaur> ahasenack: this week? I can work on it tomorrow
<mdeslaur> ahasenack: is that ok?
<ahasenack> mdeslaur: checking
<ahasenack> I think it's ok
<ahasenack> this was filed as a result of a support case
<ahasenack> dkettman: mdeslaur is saying he can pick up the bug this week
<ahasenack> mdeslaur: the other cve, is it embargoed?
<dkettman> Great!
<mdeslaur> ahasenack: CVE-2017-9461
<ahasenack> again symlinks
<mdeslaur> yeah
<ahasenack> mdeslaur: I didn't nominate it for trusty because samba isn't affected there because of the older kernel
<ahasenack> mdeslaur: feel free to include it, though, if it makes things easier
<mdeslaur> ahasenack: I'll be adding it anyway
<ahasenack> the samba code definitely has the bug, it's just not triggered there
<mdeslaur> yeah
<mdeslaur> ahasenack: thanks for figuring out the fix, etc.
<ahasenack> np
<ahasenack> I'll unassign myself
<ahasenack> dkettman: mdeslaur ^ ok?
<mdeslaur> ahasenack: sure
<dkettman> ahasenack: Works for me
<dkettman> mdeslaur: ahasenack: Thanks both of you for the assist!
<mdeslaur> ahasenack: you can assign me instead if it's a support case
<mdeslaur> dkettman: np!
<xnox> is it acceptable to demote to proposed some ocaml packages for transition?
<xnox> e.g. I do not think i will be able to fix some things, and there is no more upstreams for them (since like 2008)
-queuebot:#ubuntu-release- Unapproved: mythtv (yakkety-proposed/multiverse) [2:0.28.0+fixes.20160413.15cf421-0ubuntu2 => 2:0.28.0+fixes.20160413.15cf421-0ubuntu2.16.10.2] (mythbuntu)
-queuebot:#ubuntu-release- Unapproved: intel-microcode (yakkety-proposed/restricted) [3.20160714.1 => 3.20170511.1~ubuntu16.10.0] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: intel-microcode (xenial-proposed/restricted) [3.20151106.1 => 3.20170511.1~ubuntu16.04.0] (ubuntu-desktop, ubuntu-server)
#ubuntu-release 2017-07-04
-queuebot:#ubuntu-release- New binary: sundials [s390x] (artful-proposed/universe) [2.5.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: sundials [ppc64el] (artful-proposed/universe) [2.5.0-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted sundials [ppc64el] (artful-proposed) [2.5.0-4]
-queuebot:#ubuntu-release- New: accepted sundials [s390x] (artful-proposed) [2.5.0-4]
-queuebot:#ubuntu-release- New binary: sundials [arm64] (artful-proposed/universe) [2.5.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: sundials [armhf] (artful-proposed/universe) [2.5.0-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted sundials [arm64] (artful-proposed) [2.5.0-4]
-queuebot:#ubuntu-release- New: accepted sundials [armhf] (artful-proposed) [2.5.0-4]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (zesty-proposed) [3.24.2-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: rejected apt [source] (yakkety-proposed) [1.3.7]
-queuebot:#ubuntu-release- Unapproved: rejected mythtv [source] (yakkety-proposed) [2:0.28.0+fixes.20160413.15cf421-0ubuntu2.16.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected apt [source] (yakkety-proposed) [1.3.8]
<apw> ^ 3 duplicate in the queue
-queuebot:#ubuntu-release- Unapproved: accepted sudo [source] (zesty-proposed) [1.8.19p1-1ubuntu1.2]
<apw> tjaalton, it looks like your sudo fix for LP: #1686803 got lost in yakkety with the upload of a security update.
<ubot5> Launchpad bug 1686803 in sudo (Ubuntu Yakkety) "sudo returns exit code 0 if child is killed with SIGTERM" [Undecided,New] https://launchpad.net/bugs/1686803
<tjaalton> apw: bah, noone cares at this point :)
<tjaalton> I think
<apw> tjaalton, bah that should be: bug #1607666
<ubot5> bug 1607666 in sudo (Ubuntu Yakkety) "sudo fails with host netgroup returned from freeipa" [Undecided,Fix committed] https://launchpad.net/bugs/1607666
<tjaalton> looks like it wouldn't get verified anyway
 * apw idly wonders how long yakkety has before EOL
<apw> tjaalton, well it did in xenial and zesty i assume, and is released in those i think
<apw> so we are left i in a bit of a muddle
<flocculant> morning - -running artful with kernel from -proposed, seem to have an issue with alsa and that kernel, can't report issue with ubuntu-bug (proposed I assume) not sure of best way to proceed (reported at least to alsa)
<flocculant> apw: Ubuntu 16.10 will reach end of life on Wednesday, July 20, 2017
<tjaalton> apw: I think it's fine to wontfix it, the guy says they don't deploy yakkety so can't test it
<tjaalton> zesty got the new upstream version
-queuebot:#ubuntu-release- Unapproved: accepted sudo [source] (yakkety-proposed) [1.8.16-0ubuntu3.3]
-queuebot:#ubuntu-release- Unapproved: accepted sudo [source] (xenial-proposed) [1.8.16-0ubuntu1.5]
-queuebot:#ubuntu-release- Unapproved: accepted telegram-desktop [source] (zesty-proposed) [1.0.29-1ubuntu1.17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted postfix [source] (zesty-proposed) [3.1.4-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted postfix [source] (yakkety-proposed) [3.1.0-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: systemd (yakkety-proposed/main) [231-9ubuntu5 => 231-9ubuntu6] (core)
<sil2100> jamespage: hey!
<jamespage> sil2100: hello
<sil2100> jamespage: I'm looking at releasing some of the packages that we have in -proposed - was looking at the ones frome LP: #1696139
<ubot5> Launchpad bug 1696139 in neutron-fwaas (Ubuntu Zesty) "[SRU] ocata stable releases" [Undecided,New] https://launchpad.net/bugs/1696139
<sil2100> jamespage: my question here is - do we need for all of them to be released at once?
<jamespage> sil2100: ideally yes as we tested proposed, rather than individual parts
<sil2100> jamespage: ok, in that case would you be able to test/get someone to test the two bugs that are still not verified? LP: #1649616 and LP: #1675088
<ubot5> Launchpad bug 1649616 in keystone (Ubuntu) "Keystone Token Flush job does not complete in HA deployed environment" [High,In progress] https://launchpad.net/bugs/1649616
<ubot5> Launchpad bug 1675088 in horizon (Ubuntu Zesty) "Restrict permissions on Openstack installation" [Medium,Triaged] https://launchpad.net/bugs/1675088
<sil2100> jamespage: once those are marked as verified I'll be able to flush the whole stack from -proposed at once
<sil2100> Thanks!
<sil2100> (those two bugs were included in the uploads of heat and keystone along with the 'new upstream release' bug)
<jamespage> sil2100: that matches my expectations!
<sil2100> jamespage: could you give me a ping once those two bugs are green?
<jamespage> sil2100: can do
<LocutusOfBorg> autopkgtest for apt/unknown: armhf: Regression â»
<LocutusOfBorg> WTF? armhf, you so sad
<apw> LocutusOfBorg, retry it, i am starting to think we have a sad runner in the pool
<apw> have not had a chance to investigate it yet
<LocutusOfBorg> apw, I already retried them, I'm having a look about how it goes
<apw> i had a lot of those over the weekend i think it was, and retried them and most came out ok
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (trusty-proposed) [20170622-0ubuntu1~14.04.0]
<LocutusOfBorg> wonderful, I'll keep retry/check then
<LocutusOfBorg> not a good timing to upload perl :(
<LocutusOfBorg> queues were empty
<LocutusOfBorg> apw, can we have libreoffice/i386 forced bad? I don't like that "ignore/retry" continuous kick
<LocutusOfBorg> testsuite sucks, and wasting power cycles for that is just useless
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [amd64] (trusty-proposed/universe) [20170622-0ubuntu1~14.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [ppc64el] (trusty-proposed/universe) [20170622-0ubuntu1~14.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [i386] (trusty-proposed/universe) [20170622-0ubuntu1~14.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [arm64] (trusty-proposed/universe) [20170622-0ubuntu1~14.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [powerpc] (trusty-proposed/universe) [20170622-0ubuntu1~14.04.0] (ubuntu-cloud)
<LocutusOfBorg> doko, hello, do you want me to upload ghc building with bfd on arm64?
-queuebot:#ubuntu-release- New binary: gce-compute-image-packages [armhf] (trusty-proposed/universe) [20170622-0ubuntu1~14.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [amd64] (trusty-proposed) [20170622-0ubuntu1~14.04.0]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [armhf] (trusty-proposed) [20170622-0ubuntu1~14.04.0]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [powerpc] (trusty-proposed) [20170622-0ubuntu1~14.04.0]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [arm64] (trusty-proposed) [20170622-0ubuntu1~14.04.0]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [ppc64el] (trusty-proposed) [20170622-0ubuntu1~14.04.0]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [i386] (trusty-proposed) [20170622-0ubuntu1~14.04.0]
-queuebot:#ubuntu-release- Unapproved: smartshine (zesty-proposed/universe) [0.36-0ubuntu2 => 0.36-0ubuntu2.17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: smartshine (xenial-proposed/universe) [0.36-0ubuntu2 => 0.36-0ubuntu2.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: smartshine (trusty-proposed/universe) [0.36-0ubuntu2 => 0.36-0ubuntu2.14.04.1] (no packageset)
<sil2100> Hello! Looking at the zesty NEW queue, I see someone approved the new gce-compute-image-packages binary for amd64 but not for all the other arches - does anyone know why it's like that?
<sil2100> The xenial and yakkety binaries got accepted for all arches, same for trusty
<LocutusOfBorg> apw, please make doxygen and freetype migrate? hinting libreoffice/i386 should be enough
<LocutusOfBorg> gstreamer, pango, cairo
<LocutusOfBorg> all of them waiting for that libreoffice
-queuebot:#ubuntu-release- Unapproved: accepted freeipa [source] (zesty-proposed) [4.4.3-3ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted libepoxy [source] (zesty-proposed) [1.3.1-1ubuntu1.17.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted libepoxy [source] (xenial-proposed) [1.3.1-1ubuntu0.16.04.2]
-queuebot:#ubuntu-release- Unapproved: xorg-server-hwe-16.04 (xenial-proposed/main) [2:1.18.4-1ubuntu6.1~16.04.1 => 2:1.19.3-1ubuntu1~16.04.1] (no packageset)
<Saviq> hi team, we got an email about mir/miral being stuck in artful-proposed for a few days now, are we in Alpha1 freeze or so?
<apw> Saviq, nope
<Saviq> any idea why those don't migrate then http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_excuses.html#mir ?
<jbicha> Saviq: thanks for asking, you need to rebuild unity-system-compositor
<jbicha> after that page, there's https://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_output.txt
<jbicha> which is a bit hard to read
<Saviq> yeah, I can't parse that, sorry :D
<cjwatson> https://wiki.ubuntu.com/ProposedMigration has some advice on learning how to do so
<apw> Saviq, from the huge list of things which are broken by those promoting, i assume they are creating an ABI break and you have not rebuilt everything that uses those ?
<cjwatson> also, if the problem is that we're in a freeze, then update_excuses will say so explicitly
<apw> http://paste.ubuntu.com/25018646/
<apw> Saviq, ^ those are the relevant bits
<Saviq> yup, thanks
<jbicha> Saviq: I recommend rebuilding unity-system-compositor, that might be all you need
<Saviq> jbicha, yeah I'm not sure that should happen, we'll look into it, thanks
<jbicha> Saviq: libmirserver43 was bumped to 44 so everything that depends on 43 needs to be rebuilt
-queuebot:#ubuntu-release- Unapproved: accepted hw-detect [source] (xenial-proposed) [1.117ubuntu2.2]
<apw> Saviq, what jbicha said ... unity-system-compositor is linked against libmirserver43 so is broken if that mir migrates
<jbicha> qtmir and qtmir-gles too
-queuebot:#ubuntu-release- Unapproved: accepted hw-detect [source] (yakkety-proposed) [1.117ubuntu3.1]
<Saviq> yeah, I'm not sure why those weren't part of that upload, we'll take care of that, thanks
-queuebot:#ubuntu-release- Unapproved: rejected apt [source] (xenial-proposed) [1.2.23]
<Trevinho> Hey, can someone from the SRU team promote https://launchpad.net/ubuntu/+source/unity-control-center/15.04.0+16.04.20170214-0ubuntu1 ?
<Trevinho> As it's blocking the upcoming SRU
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (xenial-proposed) [1.13.4-1ubuntu1.6]
<slashd> vtapia ^
<slashd> sil2100, doing SRU today related work today ?
<slashd> doing SRU related work today lol
-queuebot:#ubuntu-release- Unapproved: lxcfs (xenial-proposed/main) [2.0.7-0ubuntu1~16.04.1 => 2.0.7-0ubuntu1~16.04.2] (edubuntu, ubuntu-server)
<sil2100> slashd: yes, a bit, I didn't have time yesterday + the US guys are off
<sil2100> But I'm finishing in a bit
<slashd> sil2100, ok I'll ping the vanguard tomorrow then
<sil2100> slashd: what's up? You need some action on something?
<slashd> sil2100, was wondering if you could move multipath-tools from trusty-proposed to trusty-updates, if everything look good to you. I checked and everything lgtm
<sil2100> I was looking at that today, need to remind myself what were my thoughts about that one
<slashd> Note that pending SRU still shows LP:  	1687004 has not verified, but it is, it simply that we did it a couples minutes ago and it didn't refresh the page yet.
<sil2100> One moment
<ubot5> Launchpad bug 1687004 in multipath-tools (Ubuntu Trusty) "multipath crash generating core dump" [Medium,Fix committed] https://launchpad.net/bugs/1687004
<sil2100> Ah
<slashd> sil2100, sure
<sil2100> Ok, yeah, probably wasn't verified back then
<slashd> sil2100, yeah that was probably it, there is no clear way to reproduce it, as mentioned it is base on dump analysis
<slashd> but knowing Rafael he did a lot of testing using valgrind, etc ....
<slashd> sil2100, they are both mark as green now in pending SRU
<sil2100> Will take care of that one in a minute
<slashd> sil2100, much appreciated
<slashd> sil2100, and sorry for the changelog lp thing, I have took a note for next time.
<slashd> re: sssd ^
<sil2100> slashd: no worries, I didn't expect it to cause any issues with the tooling, but I guess it should be good now
<slashd> sil2100, ack
<sil2100> slashd: multipath-tools released o/
<slashd> sil2100, thanks for this last minute request
<slashd> tinoco, ^^
<sil2100> np!
<tinoco> tau =)
<tinoco> tku =)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-85.108] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: lxcfs (yakkety-proposed/main) [2.0.7-0ubuntu1~16.10.1 => 2.0.7-0ubuntu1~16.10.2] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: lxcfs (zesty-proposed/main) [2.0.7-0ubuntu1~17.04.1 => 2.0.7-0ubuntu1~17.04.2] (edubuntu, ubuntu-server)
<slashd> Hi, Does someone with upload rights in devel release who has some cycle to sponsor a debdiff https://launchpadlibrarian.net/326769765/artful-ksh_93u+20120801-3.2.debdiff ? Once in Artful, I can sponsor the SRU myself.
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-85.108]
<mitya57> slashd, the correct version number would be 93u+20120801-3.1ubuntu1
<mitya57> Otherwise, will upload to artful now.
<slashd> mitya57, much appreciated, you'll do the correction or want me to re-generate a new debdiff ?
<mitya57> I will do.
<slashd> mitya57, thanks much
<mitya57> slashd, uploaded.
<slashd> mitya57, thanks you very much
<slashd> mitya57, you were right about the version, I think I misread when I saw, it I was under the impression it was ubuntu3.1, thanks for catching this
<slashd> need some glasses
<slangasek> xnox: do you know why udev is failing to configure on armhf for autopkgtests? (e.g. http://autopkgtest.ubuntu.com/packages/l/lazarus/artful/armhf)
<infinity> slangasek: Going to assume it's less to do with armhf and more to do with lxd.
<slangasek> infinity: s390x didn't show the problem, and this is certainly a regression in the behavior
<infinity> slangasek: s390x is lxc, not lxd, just to be confusing.
<slangasek> ah right
<slangasek> well anyway. still a behavior regression :)
<infinity> Not saying it's not a problem, just guessing it's not arch-specific.
<slangasek> and nagios3 autopkgtest is failing cross-arch because Error: The new file apt.cfg does not exist!
<xnox> slangasek, hahahahah elipsised logs are useful - Jul 04 12:23:38 autopkgtest-lxd-qemhph systemd[1]: systemd-udevd.service: Faiâ¦ed
<xnox> slangasek, also why is that calling invoke-rc.d on ubuntu?! initscript udev?!
<xnox> wtf.
<xnox> what is this?! 2004?
<xnox> slangasek, there is also an upgrade bug where open-vm-tools tries to call udevadm trigger or settle and that is not allowed whilst udev is upgrading. that is from trusty->xenial do-release-upgrade of EC2 instance.
<xnox> slangasek, do we do cloud lts-lts upgrade testing in all the clouds?
<slangasek> xnox: invoke-rc.d is the policy interface and always has been
<slangasek> lts-lts upgrade testing in "all the clouds" - I'm sure not
<xnox> sorry for rebooting my irc bouncer.
#ubuntu-release 2017-07-05
<LocutusOfBorg> https://launchpad.net/ubuntu/zesty/+queue apw not sure if you or somebody else, but gce-compute-images have been only accepted for amd64
<apw> LocutusOfBorg, was not me who accepted the zesty pile, but i can look at fixing that
<LocutusOfBorg> thanks
<apw> LocutusOfBorg, likely happened because this package was arch all before this update
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [arm64] (zesty-proposed) [20170622-0ubuntu1~17.04.0]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [i386] (zesty-proposed) [20170622-0ubuntu1~17.04.0]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [s390x] (zesty-proposed) [20170622-0ubuntu1~17.04.0]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [armhf] (zesty-proposed) [20170622-0ubuntu1~17.04.0]
-queuebot:#ubuntu-release- New: accepted gce-compute-image-packages [ppc64el] (zesty-proposed) [20170622-0ubuntu1~17.04.0]
<LocutusOfBorg> thanks! I was wondering why of such situations, this makes sense
<LocutusOfBorg> doko, ping wrt ghc, should I upload the arm64 bfd switch? do you think this can be sane?
<LocutusOfBorg> hello, wrt python-3to2, please remove it from the archive, I don't want it to slow the python transition, I requested removal in Debian some seconds ago
<LocutusOfBorg> https://bugs.debian.org/867264
<ubot5> Debian bug 867264 in ftp.debian.org "RM: python-3to2 -- ROM; FTBFS" [Normal,Open]
-queuebot:#ubuntu-release- New binary: lrslib [ppc64el] (artful-proposed/universe) [0.62-2] (no packageset)
-queuebot:#ubuntu-release- New binary: lrslib [s390x] (artful-proposed/universe) [0.62-2] (no packageset)
-queuebot:#ubuntu-release- New binary: lrslib [amd64] (artful-proposed/universe) [0.62-2] (no packageset)
-queuebot:#ubuntu-release- New binary: lrslib [i386] (artful-proposed/universe) [0.62-2] (no packageset)
-queuebot:#ubuntu-release- New binary: lrslib [armhf] (artful-proposed/universe) [0.62-2] (no packageset)
-queuebot:#ubuntu-release- New binary: lrslib [arm64] (artful-proposed/universe) [0.62-2] (no packageset)
<didrocks> any ideas why qtquickcontrols-opensource-src wants to migrate back to main? All dependencies "rescued from" are in universe as listed on http://people.canonical.com/~ubuntu-archive/component-mismatches.html, and nothing is pulling directly to any seed: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.artful/all only universe componentsâ¦
<didrocks> I'm probably missing something obvious
-queuebot:#ubuntu-release- Unapproved: ksh (trusty-proposed/universe) [93u+20120801-1 => 93u+20120801-1ubuntu0.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ksh (yakkety-proposed/universe) [93u+20120801-2 => 93u+20120801-2ubuntu0.16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ksh (xenial-proposed/universe) [93u+20120801-2 => 93u+20120801-2ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ksh (zesty-proposed/universe) [93u+20120801-2 => 93u+20120801-2ubuntu1] (no packageset)
<didrocks> it's pulled in main due to qtdeclarative5-examples, which I demoted, but from both links, we can see that this package is rescued by its source package?
<didrocks> I don't really understand why and how, we do have quite some source packages in main with only some of its binary package in universe
<didrocks> cjwatson: xnox: any idea on what I'm missing? ^
<xnox> didrocks, probably Build-Using is pulling it in.
<xnox> didrocks, i have a patch to germinate to show that in components-missmatches but it is pending review and merge from infinity / cjwatson
<xnox> didrocks, that's one known thing. Let me check again if there is anything else there.
<didrocks> xnox: shouldn't that be shown in apt-cache show *-exmamples?
<xnox> is it not simply seeded?!
<xnox> horum.
<xnox> didrocks, your assesment appears to be right. i'm not sure why report is showing what it does. unless the report is stale or something.
<didrocks> xnox: it's refreshed, beforehand it was showing up qtdeclarative5-examples (MAIN) before I demoted it
<didrocks> and it added its own line
<didrocks> so, yeah, quite puzzled
<didrocks> (and no, not seeded as you can see in the /all page, it's rescued by the source package)
<xnox> i give up, i do not know.
 * didrocks doesn't feel alone anymore ;)
<didrocks> let's see once cjwatson is around if he has a better idea
<didrocks> thanks for looking at it xnox!
<infinity> didrocks: It's because of qtdeclarative5-examples
<infinity> didrocks: Demoting it didn't magically make it not want to be in main. :P
<didrocks> infinity: but why does it want to be in main? It's rescued by its source package
<infinity> didrocks: Yes.  Because the source is in main, and:
<infinity> supported: * Extra-Include: *-dbg *-debug *-dev *-doc *-docs *-gcj gir1.2-* *-examples
<didrocks> oh, didn't know about this regexp
<didrocks> shouldn't it be written then as seeded in same way in the supported? (by its source package, ok)
<infinity> didrocks: Note directly under that line are a bunch of exceptions for things we don't want to pull in for $reasons.
<infinity> didrocks: So if you feel those examples packages aren't worth having in main because they pull in too many deps or whatever, you can add an Extra-Exclude in that block.
<infinity> And I should porbably go clean that up and audit it some day.
<didrocks> infinity: yeah, sounds like the best approach! I'll add it to that list to go on on our demotion
<didrocks> infinity: yeah, the list is getting long :)
<infinity> didrocks: If you do extra-exclude qtdeclarative5-examples, please add a comment or commit message (or both) that explain why (it was pulling in qtquickcontrols-opensource-src, which we don't want).
<didrocks> thanks for the explanation! I never noticed this Extra-Include and thought -dbg/-dev/-doc rules were hardcoded somewhere
<didrocks> infinity: as always ;)
<slashd> rbasak, good day, I want to push a patch in Artful for open-iscsi, but it seems like a previous upload is blocked "Not considered" for 56 days ... reason : a couples of unsatisfiable Depends. What can be done to unblock me ?
<slashd> mdeslaur^
<infinity> slashd: Follow LP: #1689963 closely, I imagine.
<ubot5> Launchpad bug 1689963 in open-isns (Ubuntu) "[MIR] open-isns" [Undecided,New] https://launchpad.net/bugs/1689963
<infinity> slashd: Ahh, and it looks like it's pretty much a done deal.
<slashd> infinity, reading
<infinity> slashd: cyphermox is on VAC unfil next week, but I'm sure he'll get to it when he's back.  Or if it's urgent, you could ask doko to put a bow on it.
<slashd> infinity, it's not critical but I doubt we can wait until next week, I'll ping doko and see what can be done, thanks infinity much appreciated
<infinity> slashd: Why can't it wait *to migrate* until next week?
<infinity> slashd: If this is an "I want to upload to artful first so I can SRU the same fix" thing, the fix having migrated isn't a prereq for the SRU upload.
<rbasak> I was about to say. It makes no sense to block an SRU because of an unrelated proposed migration issue. Unless I'm missing something, it'd be OK to put the fix into artful-proposed and proceed with an unrelated-to-the-migration-failure SRU I think.
<infinity> (Though, taking responsibility to make sure it *does* migrate is)
<slashd> rbasak, infinity, yes I want to push the change in devel release to start the SRU
<infinity> slashd: Right.  So do that.
<infinity> Upload early, upload often.
<infinity> That's the devel series mantra.
<slashd> infinity, ack thanks
<Trevinho> arges, rbasak: could you please promote unity-control-center in xenial-proposed to updates? SRU is verified and i'd like to land a new one soon
<slashd> rbasak, thanks as well
<rbasak> Trevinho: looking
<Trevinho> thanks
<rbasak> Trevinho: seen comment 25?
<ahasenack> hi, could someone please accept my nomiations in this bug? https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1560429
<ubot5> Ubuntu bug 1560429 in squid3 (Ubuntu) " squid3: segfault when ftp passive mode is not available" [Medium,In progress]
<rbasak> ahasenack: done
<ahasenack> thx
<seb128> rbasak, Trevinho, do we really need to block xenial fixes on yakkety, zesty is current stable and should be what matters
<ahasenack> rbasak: when this bug was filed, the devel distro was affected, but that's not the case anymore. What should I do with the "(ubuntu)" task, which nowadays represents artful? zesty and artful have the fix already
<rbasak> seb128: I was wondering that. I was just asking about the comment - not aware of any particular SRU policy on this.
<ahasenack> delete it, or find out when it was fixed and mark it fix released with a comment?
<rbasak> Best not to delete tasks to avoid hitting an Launchpad bug. Mark Invalid if necessary instead. If the bug was since fixed in the development release, then change that to Fix Released. Add a task for Zesty if necessary, though if that's immediately going to be Fix Released then there's little point unless there some other reason (clarity in communication, etc).
<ahasenack> ok
<apw> rbasak, you can get those tasks back iirc, using launchpadlib ...
-queuebot:#ubuntu-release- Unapproved: xf86-input-mtrack-hwe-16.04 (xenial-proposed/universe) [0.3.1-1build1~16.04.1 => 0.3.1-1build2~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-evdev-hwe-16.04 (xenial-proposed/main) [1:2.10.2-1ubuntu1~16.04.1 => 1:2.10.5-1ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-libinput-hwe-16.04 (xenial-proposed/universe) [0.19.0-1ubuntu0.1~16.04.1 => 0.25.0-0ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-void-hwe-16.04 (xenial-proposed/universe) [1:1.4.1-1build2~16.04.1 => 1:1.4.1-1build3~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xf86-input-wacom-hwe-16.04 (xenial-proposed/main) [1:0.33.0-0ubuntu1~16.04.1 => 1:0.34.0-0ubuntu2~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-synaptics-hwe-16.04 (xenial-proposed/main) [1.8.3-1ubuntu1~16.04.1 => 1.9.0-1ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-input-joystick-hwe-16.04 (xenial-proposed/universe) [1:1.6.2-1build4~16.04.1 => 1:1.6.3-1build1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-amdgpu-hwe-16.04 (xenial-proposed/main) [1.1.2-1~16.04.1 => 1.3.0-0ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-ati-hwe-16.04 (xenial-proposed/main) [1:7.7.1-1~16.04.1 => 1:7.9.0-0ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-dummy-hwe-16.04 (xenial-proposed/main) [1:0.3.7-1build5~16.04.1 => 1:0.3.8-1build1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-geode-hwe-16.04 (xenial-proposed/universe) [2.11.18-2~16.04.1 => 2.11.19-2~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-mach64-hwe-16.04 (xenial-proposed/universe) [6.9.5-1build2~16.04.1 => 6.9.5-1build3~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-nouveau-hwe-16.04 (xenial-proposed/main) [1:1.0.12-2~16.04.1 => 1:1.0.14-0ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-qxl-hwe-16.04 (xenial-proposed/main) [0.1.4-3ubuntu3~16.04.1 => 0.1.5-2build1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-savage-hwe-16.04 (xenial-proposed/universe) [1:2.3.8-1ubuntu3~16.04.1 => 1:2.3.9-1ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-sisusb-hwe-16.04 (xenial-proposed/universe) [1:0.9.6-2build5~16.04.1 => 1:0.9.7-1build1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-trident-hwe-16.04 (xenial-proposed/universe) [1:1.3.7-1build2~16.04.1 => 1:1.3.8-1build1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-vmware-hwe-16.04 (xenial-proposed/main) [1:13.1.0-2ubuntu3~16.04.1 => 1:13.2.1-1build1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-fbdev-hwe-16.04 (xenial-proposed/main) [1:0.4.4-1build5~16.04.1 => 1:0.4.4-1build6~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-neomagic-hwe-16.04 (xenial-proposed/universe) [1:1.2.9-1build2~16.04.1 => 1:1.2.9-1build3~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-r128-hwe-16.04 (xenial-proposed/universe) [6.10.1-1~16.04.1 => 6.10.2-1build1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-tdfx-hwe-16.04 (xenial-proposed/universe) [1:1.4.6-1build2~16.04.1 => 1:1.4.7-1build1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-intel-hwe-16.04 (xenial-proposed/main) [2:2.99.917+git20160706-1ubuntu1~16.04.1 => 2:2.99.917+git20170309-0ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-siliconmotion-hwe-16.04 (xenial-proposed/universe) [1:1.7.8-1ubuntu6~16.04.1 => 1:1.7.9-2ubuntu1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-openchrome-hwe-16.04 (xenial-proposed/universe) [1:0.3.3+git20160310-1~16.04.1 => 1:0.5.0-3build1~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-vesa-hwe-16.04 (xenial-proposed/main) [1:2.3.4-1build2~16.04.1 => 1:2.3.4-1build3~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xorg-hwe-16.04 (xenial-proposed/main) [1:7.7+13ubuntu4~16.04.2 => 1:7.7+16ubuntu3~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected xorg-hwe-16.04 [source] (xenial-proposed) [1:7.7+16ubuntu3~16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected xorg-server [source] (xenial-proposed) [2:1.18.4-0ubuntu0.3]
-queuebot:#ubuntu-release- Unapproved: rejected xorg-server-hwe-16.04 [source] (xenial-proposed) [2:1.19.3-1ubuntu1~16.04.1]
<rbasak> seb128, Trevinho: is there any reason Yakkety can't be verified? Seems a waste of everybody's time to do it twice, and we do still support Yakkety, no?
<seb128> rbasak, I'm downloading a yakkety iso now, but that's what seems the waste of time to me
-queuebot:#ubuntu-release- Unapproved: xorg-server-hwe-16.04 (xenial-proposed/main) [2:1.18.4-1ubuntu6.1~16.04.1 => 2:1.19.3-1ubuntu1~16.04.1] (no packageset)
<Trevinho> rbasak: mh, actually I think it's the same xenial thing, so I'll mark it properly
<seb128> Trevinho, don't
<Trevinho> seb128: ok
<seb128> Trevinho, did you suggest just tagging it as verified on yakkety without actually testing i there or did I understand you not correctly?
<seb128> rbasak, downloading iso, installing yakkety, reproducing, upgrading, testing the SRU, that's going to take me an hour, that's a waste for a serie which is neither LTS nor current and has probably not much desktop users left
<rbasak> seb128: if it's a waste, then we need to make the decision either to EOL Yakkety now, or halt all Yakkety SRUs now, or decide why in this case we don't want to SRU this to Yakkety for some other reason, etc.
<infinity> rbasak: My general rule of thumb is that cosmetic/"polish" changes only need to go to devel and the stable series' you care to fix, but real behavioural bug fixes can't skip supported releases.
<Trevinho> seb128: bug #1639507 as per Laney's word isn't fixed, but it's fine to mark it verified. So I would follow the same policiy for yakkety. Not for the other one tho
<ubot5> bug 1639507 in unity-control-center (Ubuntu Yakkety) "unity-control-center in installed software is listed with wrong icon and title" [Medium,Fix committed] https://launchpad.net/bugs/1639507
<infinity> Because someone upgrading from xenial to yakkety shouldn't be subject to a functional regression.
<seb128> rbasak, well it's the issues with SRUs delays, when that SRU was started in february it was making sense, we were far enough from zesty
<infinity> But yes, yakkety also EOLs in just over two weeks, so there's some fudge factor there for people to use their best judgement about how to spend their time.
<Trevinho> infinity: sure... It's even true that the stack at that level is pretty much the same, so I expect no much difference
<rbasak> Trevinho: AIUI, that discussion was about the definition of the bug being fixed, rather than about verification of the fix for the definition decided upon.
-queuebot:#ubuntu-release- Unapproved: xorg-hwe-16.04 (xenial-proposed/main) [1:7.7+13ubuntu4~16.04.2 => 1:7.7+16ubuntu3~16.04.1] (no packageset)
<seb128> Trevinho, right about that issue, it's not fixed but also not a regression so it's fine
<slashd> rbasak, mdeslaur has uploaded the open-iscsi as discussed, and it is "Not Considered" in the update_excuse page "open-iscsi (2.0.873+git0.3b4b4500-14ubuntu17 to 2.0.874-2ubuntu2) " did I miss something ? or it's just a matter for SRU to unblock it ?
<slashd> unsatisfiable Depends:  ^
<infinity> slashd: Didn't we literally just discuss this?
<slashd> infinity, maybe I miss something, but my understanding was that mdeslaur could upload the package anyway right ? and that it won't be caught by the MIR ?
<infinity> slashd: He can (and did) upload it.  That doesn't change that it won't migrate until the MIR is complete.
<infinity> slashd: What we said was that this shouldn't block you doing your SRUs.
<slashd> infinity, gotcha ok, sorry I miss that bit, so we are all good, I was under the impression it would skip it or something. While it is still Not Considered in Artful, can I start the upload in Stable release ?
<infinity> slashd: Why would it skip checking if it was installable?  That's the whole point of proposed-migration.
<infinity> slashd: And yes, as we said, you can upload your SRUs now.
<slashd> infinity, great thanks, sorry about that, but I prefer to make sure before doing a mistake.
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.26.4 => 2.26.8] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.26.4+16.10 => 2.26.8+16.10] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.26.4+17.04 => 2.26.8+17.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.26.4~14.04 => 2.26.8~14.04] (no packageset)
 * apw looks at snapd(s) ^^
<ahasenack> hi, could I get someone to sponsor this upload for me please? https://bugs.launchpad.net/ubuntu/+source/openvpn-auth-ldap/+bug/1602813
<ubot5> Ubuntu bug 1602813 in openvpn-auth-ldap (Ubuntu Zesty) "openvpn-auth-ldap causing segfault on network timeout" [Medium,In progress]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (zesty-proposed) [2.26.8+17.04]
<nacc> ahasenack: it's on my queue for today
-queuebot:#ubuntu-release- Unapproved: rejected borgbackup [source] (xenial-proposed) [1.0.10-2~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.26.8+16.10]
<ahasenack> thx
<nacc> ahasenack: you need it sponsored for all 4, right?
<ahasenack> nacc: yes
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.26.8~14.04]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.26.8]
<nacc> ahasenack: i wonder when/if we should start reconsidering sru for yakkety
<nacc> ahasenack: as it goes eol in ~ 2 weeks
<apw> nacc, well there is no point in accepting anything with less than 8 days to go
<nacc> apw: ack, that's what i meant :)
<ahasenack> 2w > 8d?
<nacc> apw: i just want to make sure i consider the versioning correctly in the case of somone getting an update in xenial, but then upgrading to yakkety (and thus the version being earlier w/o the sru there) before it goes eol, then upgrading to z.
<apw> nacc, right you need to consider the version in yakkety in that sense
<ahasenack> the bug has been open for a year, would be a shame to not close it for y
-queuebot:#ubuntu-release- Unapproved: gwakeonlan (xenial-proposed/universe) [0.5.1-1.1 => 0.5.1-1.1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected gwakeonlan [source] (xenial-proposed) [0.5.1-1.1ubuntu0.1]
<nacc> ahasenack: right, but y itself is about to be closed
-queuebot:#ubuntu-release- Unapproved: accepted gwakeonlan [source] (xenial-proposed) [0.5.1-1.1ubuntu0.1]
<nacc> ahasenack: so it's a cost/benefit tradeoff, as i have to review it and then the sru team has to review it :)
<nacc> apw: yep, thanks
<ahasenack> this would be easier if there was a clear cut date in the ubuntu release table for sus
<ahasenack> srus*
<ahasenack> EOL: X
<ahasenack> last day for SRU: Y
<rbasak> That's a good idea.
<nacc> +1
<ahasenack> otherwise, of course we will be tempted to not do SRUs for a release if we are "getting close" to its EOL
<rbasak> At least unless there's some exceptional reason.
<ahasenack> "close" is subjective in this case
<nacc> ahasenack: yeah, i'm just considering 7 days is how long something bakes in y-p
<nacc> ahasenack: and so you're only going to have the fix for about a week before the release goes eol :)
<nacc> ahasenack: which doesn't seem particularly relevant ... user is better off just upgrading to z with the fix there
<ahasenack> well, it's a segfault
<nacc> ahasenack: that is to say, i'm comfortable (hand-waving versioning for a moment) if the y solution is: upgrade to z because you have to in two weeks anyways
<nacc> rbasak: thoughts?
<rbasak> Depending on the bug, I think it's reasonable to set Won't Fix for Yakkety on that basis. In principle anyway.
<nacc> rbasak: right
<rbasak> From earlier today: 15:14 <infinity> But yes, yakkety also EOLs in just over two weeks, so there's some fudge factor there for people to use their best judgement about how to spend their time.
<rbasak> From earlier today: 15:14 <infinity> But yes, yakkety also EOLs in just over two weeks, so there's some fudge factor there for people to use their best judgement about how to spend their time.
<nacc> ahasenack: i'm also going off the eol announcement e-mail having just come out, which makes it feel like we're in the 'getting close' window more explicilty
<rbasak> From earlier today: 15:14 <infinity> But yes, yakkety also EOLs in just over two weeks, so there's some fudge factor there for people to use their best judgement about how to spend their time.
<rbasak> From earlier: 15:14 <infinity> But yes, yakkety also EOLs in just over two weeks, so there's some fudge factor there for people to use their best judgement about how to spend their time.
<jbicha> honestly, given the number of unapproved SRUs in the queue, new yakkety ones will likely just not be able to make it in time unless they fix Really Serious issues
<rbasak> Argh
<rbasak> Sorry
<ahasenack> well, it's your call guys
<nacc> jbicha: right, that was also my thinking
<ahasenack> that's what sponsoring is for
<nacc> ahasenack: understood, you just prompted me to think about this
<ahasenack> I did my job weeks ago :)
<jbicha> xenial has 60 unapproved SRU candidates and zesty has 17 so it's difficult for the SRU team to keep up :|
<nacc> jbicha: yep
-queuebot:#ubuntu-release- Unapproved: ntp (trusty-proposed/main) [1:4.2.6.p5+dfsg-3ubuntu2.14.04.10 => 1:4.2.6.p5+dfsg-3ubuntu2.14.04.11] (core)
<apw> xenial to be fair is prep for the point release i believe
-queuebot:#ubuntu-release- Unapproved: accepted mythtv [source] (zesty-proposed) [2:0.28.0+fixes.20170206.03f4403-0ubuntu3.1]
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-85.108~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-85.108~14.04.1]
<ahasenack> slangasek: hi, if I could have our opinion on something
<ahasenack> slangasek: I have this patch (https://bugs.launchpad.net/ubuntu/+source/openvpn-auth-ldap/+bug/1602813/comments/0) provided by the user in the bug description
<ubot5> Ubuntu bug 1602813 in openvpn-auth-ldap (Ubuntu Zesty) "openvpn-auth-ldap causing segfault on network timeout" [Medium,In progress]
<ahasenack> he signs it with his name, but no email. His launchpad id hides his email and is a generic name (foxpass-dev)
<ahasenack> how should I give credit for this in the patch dep3 header?
<ahasenack> I used:
<ahasenack> Original-Author: Aaron Peschel https://launchpad.net/~foxpass-dev
<ahasenack> (n/m the Original bit)
<slangasek> ahasenack: that seems reasonable to me; I don't have the dep3 schema memorized, but I'd say anything that's permitted is ok
<ahasenack> slangasek: it expects an email
<ahasenack> "This field can be used to record the name and email of the patch author (...)"
<slangasek> that seems vague to me :-)
<ahasenack> and so not future-proof :)
<ahasenack> it gives an example, though, the classical First Last <foo@example.com>
<slangasek> if you use a non-email value, and nothing crashes, LGTM
<ahasenack> I can't be sure that nothing will crash
<ahasenack> definitely nothing should crash on bad input
<ahasenack> but we know better
<slangasek> not much parses these
<slangasek> you could feed it through dep3changelog and see what happens :)
<ahasenack> worst case, another bug to fix? :)
-queuebot:#ubuntu-release- Unapproved: iscsitarget (xenial-proposed/universe) [1.4.20.3+svn502-2ubuntu4.1 => 1.4.20.3+svn502-2ubuntu4.2] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-communications [ppc64el] (artful-proposed/none) [1.2.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-communications [i386] (artful-proposed/none) [1.2.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-communications [s390x] (artful-proposed/none) [1.2.1-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted iscsitarget [source] (xenial-proposed) [1.4.20.3+svn502-2ubuntu4.2]
-queuebot:#ubuntu-release- New binary: octave-communications [amd64] (artful-proposed/none) [1.2.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-communications [arm64] (artful-proposed/none) [1.2.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-communications [armhf] (artful-proposed/none) [1.2.1-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted lrslib [amd64] (artful-proposed) [0.62-2]
-queuebot:#ubuntu-release- New: accepted lrslib [armhf] (artful-proposed) [0.62-2]
-queuebot:#ubuntu-release- New: accepted lrslib [ppc64el] (artful-proposed) [0.62-2]
-queuebot:#ubuntu-release- New: accepted octave-communications [amd64] (artful-proposed) [1.2.1-3]
-queuebot:#ubuntu-release- New: accepted octave-communications [armhf] (artful-proposed) [1.2.1-3]
-queuebot:#ubuntu-release- New: accepted octave-communications [ppc64el] (artful-proposed) [1.2.1-3]
-queuebot:#ubuntu-release- New: accepted lrslib [arm64] (artful-proposed) [0.62-2]
-queuebot:#ubuntu-release- New: accepted lrslib [s390x] (artful-proposed) [0.62-2]
-queuebot:#ubuntu-release- New: accepted octave-communications [i386] (artful-proposed) [1.2.1-3]
-queuebot:#ubuntu-release- New: accepted lrslib [i386] (artful-proposed) [0.62-2]
-queuebot:#ubuntu-release- New: accepted octave-communications [s390x] (artful-proposed) [1.2.1-3]
-queuebot:#ubuntu-release- New: accepted octave-communications [arm64] (artful-proposed) [1.2.1-3]
-queuebot:#ubuntu-release- Unapproved: accepted mythtv [source] (xenial-proposed) [2:0.28.0+fixes.20160413.15cf421-0ubuntu2.16.04.1]
-queuebot:#ubuntu-release- Unapproved: openvpn-auth-ldap (trusty-proposed/universe) [2.0.3-5.1 => 2.0.3-5.1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openvpn-auth-ldap (yakkety-proposed/universe) [2.0.3-6.1 => 2.0.3-6.1ubuntu0.16.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openvpn-auth-ldap (xenial-proposed/universe) [2.0.3-6.1 => 2.0.3-6.1ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openvpn-auth-ldap (zesty-proposed/universe) [2.0.3-6.1 => 2.0.3-6.1ubuntu0.17.04.1] (no packageset)
<infinity> ahasenack: To add to the bikeshed, I'd put the URL ref in ().  Since RFC person records / addresses are in the form "Name Name Name (Comment Comment Comment) <email@drre.ss>"
<infinity> ahasenack: So, you'd have Name and Comment, but no address, which seems reasonable.
<ahasenack> good to know
<nacc> infinity: oh good point
<nacc> ahasenack: sorry for all the noise on it, but i think it's a good discussion to have and get agreement on :)
-queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu17 => 229-4ubuntu18] (core)
-queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (xenial-proposed) [2.0.7-0ubuntu1~16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (yakkety-proposed) [2.0.7-0ubuntu1~16.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (zesty-proposed) [2.0.7-0ubuntu1~17.04.2]
-queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu5 => 2.02~beta3-4ubuntu6] (core)
#ubuntu-release 2017-07-06
<nacc> ahasenack: and it would be good to put the conclusion on the wiki page
<slangasek> Laney: "You submitted an invalid request: freedombox-setup/0.10 is not published in artful" seems an unexpected result for http://autopkgtest.ubuntu.com/request.cgi?release=artful&arch=armhf&package=freedombox-setup&trigger=freedombox-setup/0.10
<slangasek> Laney: any insight?
<nacc> slangasek: hrm, why does update_excuses say freedombox-setup/unknown?
<jbicha> we've had problems with unknown armhf autopkgtests since Friday
<nacc> jbicha: ah ok, i wasn't aware, sorry
<jbicha> retrying works most of the time
<nacc> slangasek: fwiw, i don't believe that retrigger will end up succeeding (I don't see why it's invalid) because mod-gnutls hasn't built on non-amd64 for some time
<jbicha> it's ok, I don't think there's anything tracking the armhf problem yet
-queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu6 => 2.02~beta3-4ubuntu6] (core)
<slangasek> nacc: ah, is mod-gnutls the source of the problem?  thanks, that was non-obvious why things were showing uninstallable.  Still, I don't think that explains freedombox-setup showing as "not published"
<slangasek> nacc, jbicha: fwiw the "/unknown" is the result of Laney's fix to make early-aborted autopkgtests show up in the index instead of disappearing into the void, so is not necessarily a sign of armhf runners having regressed (these are the tests that previously would have shown up indefinitely as 'In progress')
-queuebot:#ubuntu-release- Unapproved: mythtv (yakkety-proposed/multiverse) [2:0.28.0+fixes.20160413.15cf421-0ubuntu2 => 2:0.28.0+fixes.20160413.15cf421-0ubuntu2.16.10.1] (mythbuntu)
-queuebot:#ubuntu-release- Unapproved: rejected mythtv [source] (yakkety-proposed) [2:0.28.0+fixes.20160413.15cf421-0ubuntu2.16.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted mythtv [source] (yakkety-proposed) [2:0.28.0+fixes.20160413.15cf421-0ubuntu2.16.10.1]
-queuebot:#ubuntu-release- New: accepted libinput [amd64] (xenial-proposed) [1.6.3-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted libinput [armhf] (xenial-proposed) [1.6.3-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted libinput [powerpc] (xenial-proposed) [1.6.3-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted libinput [s390x] (xenial-proposed) [1.6.3-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted libinput [arm64] (xenial-proposed) [1.6.3-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted libinput [ppc64el] (xenial-proposed) [1.6.3-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New: accepted libinput [i386] (xenial-proposed) [1.6.3-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xfonts-utils [source] (xenial-proposed) [1:7.7+3ubuntu0.16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server-hwe-16.04 [source] (xenial-proposed) [2:1.19.3-1ubuntu1~16.04.1]
<slashd> good day sil2100, do you have some cycle to approve the upload of 'ksh' in Trusty ? https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=ksh
<slashd> sil2100, I'm re-sending my message, since I just notice you quit/join
<slashd> good day sil2100, do you have some cycle to approve the upload of 'ksh' in Trusty ? https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=ksh
<sil2100> slashd: hey! I can try looking into that after lunch if that's ok :)
<ogra_> sil2100, when you decided to pick the gross hack for ubuntu-image that classic snaps are, you already gave up on the elegance bit ;) (just read your PR commit) ... I woulldnt care about elegance anymore ;)
<slashd> sil2100, sure thank you
<jibel> Hi, there is no desktop image today. Can someone have a look? There is a livefs but the ISO failed to build
<sil2100> ogra_: yeah, but this involves ugly things happening in the part-install of snapcraft.yaml ;p Like, moving lib files around
<sil2100> jibel: let me take a look
<jibel> sil2100, thanks
<ogra_> sil2100, as long as you dont copy them over system libs outside of the snap (which classic can actuallly do as well)
-queuebot:#ubuntu-release- Unapproved: python-cinderclient (xenial-proposed/main) [1:1.6.0-2 => 1:1.6.0-2ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: s390-tools (xenial-proposed/main) [1.34.0-0ubuntu8.2 => 1.34.0-0ubuntu8.4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: s390-tools (zesty-proposed/main) [1.37.0-0ubuntu3 => 1.37.0-0ubuntu3.1] (core)
-queuebot:#ubuntu-release- Unapproved: s390-tools (yakkety-proposed/main) [1.36.1-0ubuntu2 => 1.36.1-0ubuntu2.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (trusty-proposed/main) [2.2.12-0ubuntu1~14.04.1 => 2.2.14-0ubuntu1~14.04.1] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (xenial-proposed/main) [2.2.12-0ubuntu1~16.04.1 => 2.2.14-0ubuntu1~16.04.1] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (zesty-proposed/main) [2.2.12-0ubuntu1~17.04.1 => 2.2.14-0ubuntu1~17.04.1] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (yakkety-proposed/main) [2.2.12-0ubuntu1~16.10.1 => 2.2.14-0ubuntu1~16.10.1] (ubuntu-cloud, ubuntu-server)
<jbicha> slangasek: oh, that makes sense for the armhf autopkgtests, it is a nice improvement to have the retry buttons at least :)
-queuebot:#ubuntu-release- New binary: gnome-control-center [amd64] (artful-proposed/main) [1:3.24.2-0ubuntu3] (edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- New: rejected gnome-control-center [amd64] (artful-proposed) [1:3.24.2-0ubuntu3]
-queuebot:#ubuntu-release- New binary: gnome-control-center [amd64] (artful-proposed/main) [1:3.24.2-0ubuntu4] (edubuntu, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: accepted ksh [source] (trusty-proposed) [93u+20120801-1ubuntu0.14.04.1]
-queuebot:#ubuntu-release- New: accepted gnome-control-center [amd64] (artful-proposed) [1:3.24.2-0ubuntu4]
<slangasek> infinity: these xenial image build failure emails that look like a partially-broken x stack, is that known and in progress in -proposed right now?
-queuebot:#ubuntu-release- Unapproved: borgbackup (xenial-proposed/universe) [1.0.7-0ubuntu1.16.04.1 => 1.0.10-2~16.04.1] (no packageset)
<infinity> slangasek: Yep, drivers will go in this morning and should fix it.
-queuebot:#ubuntu-release- New binary: tpm-tools [ppc64el] (artful-proposed/universe) [1.3.9.1-0.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: tpm-tools [s390x] (artful-proposed/universe) [1.3.9.1-0.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: tpm-tools [amd64] (artful-proposed/universe) [1.3.9.1-0.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: tpm-tools [i386] (artful-proposed/universe) [1.3.9.1-0.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: tpm-tools [arm64] (artful-proposed/universe) [1.3.9.1-0.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ksh [source] (yakkety-proposed) [93u+20120801-2ubuntu0.16.10.1]
<ahasenack> hi, can someone please accept my xenial nomination for https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1664566 ? Thanks
<ubot5> Ubuntu bug 1664566 in sssd (Ubuntu) "sssd_krb5_locator_plugin.so is not loaded (installed at wrong path)" [Undecided,Fix released]
-queuebot:#ubuntu-release- Unapproved: accepted ksh [source] (xenial-proposed) [93u+20120801-2ubuntu0.16.04.1]
<rbasak> chiluk: regarding intel-microcode, did you see the discussion in ubuntu-release@ and in the bug? I see the same issues. It's not a minimal cherry-pick.
<chiluk> rbasak: looking
<chiluk> rbasak you are going to have to be more specific I have seen all the discussion...
<rbasak> chiluk: for example, why is debhelper compat being bumped?
<chiluk> it is but we have sufficient version in xenial so I considered it a non-issue
<nacc> ahasenack: done
<ahasenack> thx
<rbasak> chiluk: I don't think you understood my point in the thread then? These are unnecessary packaging changes.
<chiluk> rbasak: the functionality change of depending on the newer version when the underlying isn't changing should be a non-issue
<rbasak> chiluk: no, the compat level changed. That's different from just depending on a newer version. That's specifically *asking* for different behaviour.
<chiluk> rbasak: they might be unnecessary packaging changes, but in my opinion on a blanket pull-back like this, I think it's more appropriate to stay close to the new version than to start ripping out stuff because it's "new"
<rbasak> chiluk: we had this discussion already on the thread. Three members of the SRU team, the only ones who opined, have asked for either a minimal cherry-pick of only the blob update and nothing else, or a full documented exception for ongoing backports. I'd expect the latter to include a comprehensive testing plan. In this case that'd require different CPU types, etc, IMHO.
<chiluk> rbasak... If you want Henrique is commenting in the public bug we could ask him
<rbasak> chiluk: why is a minimal blob update so difficult?
<rbasak> chiluk: see Trusty for an example of it being done in the past.
-queuebot:#ubuntu-release- Unapproved: rejected intel-microcode [source] (xenial-proposed) [3.20170511.1~ubuntu16.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted ksh [source] (zesty-proposed) [93u+20120801-2ubuntu1]
<chiluk> rbasak I don't remember seeing that consensus was reached.
-queuebot:#ubuntu-release- Unapproved: rejected intel-microcode [source] (yakkety-proposed) [3.20170511.1~ubuntu16.10.0]
<chiluk> but if we must I'll pull back just the blobs...
<rbasak> chiluk: https://bugs.launchpad.net/ubuntu/+source/intel-microcode/+bug/1700373/comments/27
<ubot5> Ubuntu bug 1700373 in intel-microcode (Ubuntu Yakkety) "intel-microcode is out of date, version 20170511 fixes errata on 6th and 7th generation platforms" [Undecided,Confirmed]
<chiluk> yeah I missed the ML thread... all my subscriptions got dropped when I lost my canonical.com email address.
<LocutusOfBorg> cjwatson, sorry, is armhf real hardware or qemu stuff?
<LocutusOfBorg> because I'm tracing down notmuch failures and I see in my qemu ptrace is giving unsupported syscall
<chiluk> thanks rbasak for alerting me to that thread... There's a lot of background discussion that I was missing.. I'll investigate more thoroughly later today...*(meetings).
<slangasek> LocutusOfBorg: it is real hardware
<LocutusOfBorg> thanks
<LocutusOfBorg> nice, so I can't debug on my machine notmuch failures because I use qemu
<LocutusOfBorg> and there is no porterbox in Ubuntu
<LocutusOfBorg> and for some reasons gdb+Ubuntu+notmuch sucks
<LocutusOfBorg> "sucks much"
<rbasak> "I should also mention that we will be following Debian's lead and not updating this for Trusty." -- who is "we" there, please?
<rbasak> chiluk: ^
<rbasak> Is that an Ubuntu Foundations team discussion? Or if not, which team?
<rbasak> s/discussion/decision/
<slangasek> LocutusOfBorg: what is the failure?
<slangasek> I don't see any notmuch waiting to migrate
<LocutusOfBorg> slangasek, I had to disable testsuite on armhf
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/notmuch/0.24.2-2
<LocutusOfBorg> slangasek, illegal instruction
<LocutusOfBorg> https://launchpadlibrarian.net/327045619/buildlog_ubuntu-artful-armhf.notmuch_0.24.2-2ubuntu7_BUILDING.txt.gz
<LocutusOfBorg> in my ppa there is the debug in the instruction
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+files/notmuch_0.24.2-2ubuntu7.dsc
<LocutusOfBorg> something smells like a glibc issue?
-queuebot:#ubuntu-release- Unapproved: accepted skiboot [source] (yakkety-proposed) [5.3.3-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted skiboot [source] (xenial-proposed) [5.1.13-0ubuntu3]
-queuebot:#ubuntu-release- New binary: gmime [amd64] (artful-proposed/main) [3.0.1-2] (core)
-queuebot:#ubuntu-release- New binary: gmime [ppc64el] (artful-proposed/main) [3.0.1-2] (core)
-queuebot:#ubuntu-release- New binary: gmime [s390x] (artful-proposed/main) [3.0.1-2] (core)
-queuebot:#ubuntu-release- New binary: gmime [armhf] (artful-proposed/main) [3.0.1-2] (core)
-queuebot:#ubuntu-release- New binary: libratbag [s390x] (artful-proposed/universe) [0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gmime [arm64] (artful-proposed/main) [3.0.1-2] (core)
-queuebot:#ubuntu-release- New binary: libratbag [amd64] (artful-proposed/universe) [0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gmime [i386] (artful-proposed/main) [3.0.1-2] (core)
-queuebot:#ubuntu-release- New binary: libratbag [ppc64el] (artful-proposed/universe) [0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libratbag [i386] (artful-proposed/universe) [0.9-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-daiquiri [amd64] (artful-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-coverage-test-runner [amd64] (artful-proposed/universe) [1.13.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-bitcoinlib [amd64] (artful-proposed/none) [0.7.0-1] (no packageset)
<infinity> doko: Hrm, LocutusOfBorg just disabled the notmuch testsuite on armhf due to it throwing SIGILL.  That sounds fishy.
<infinity> doko: (Well, disabling the testsuite because it's doing its job is very fishy, but I mean the SIGILL could perhaps relate to new toolchain)
-queuebot:#ubuntu-release- New binary: qbs [s390x] (artful-proposed/universe) [1.8.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qbs [ppc64el] (artful-proposed/universe) [1.8.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gmime [amd64] (artful-proposed) [3.0.1-2]
-queuebot:#ubuntu-release- New: accepted gmime [armhf] (artful-proposed) [3.0.1-2]
-queuebot:#ubuntu-release- New: accepted gmime [ppc64el] (artful-proposed) [3.0.1-2]
-queuebot:#ubuntu-release- New: accepted libratbag [amd64] (artful-proposed) [0.9-1]
-queuebot:#ubuntu-release- New: accepted libratbag [ppc64el] (artful-proposed) [0.9-1]
-queuebot:#ubuntu-release- New: accepted python-bitcoinlib [amd64] (artful-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted python-daiquiri [amd64] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted qbs [s390x] (artful-proposed) [1.8.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gmime [arm64] (artful-proposed) [3.0.1-2]
-queuebot:#ubuntu-release- New: accepted gmime [s390x] (artful-proposed) [3.0.1-2]
-queuebot:#ubuntu-release- New: accepted libratbag [s390x] (artful-proposed) [0.9-1]
-queuebot:#ubuntu-release- New: accepted qbs [ppc64el] (artful-proposed) [1.8.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gmime [i386] (artful-proposed) [3.0.1-2]
-queuebot:#ubuntu-release- New: accepted python-coverage-test-runner [amd64] (artful-proposed) [1.13.1-1]
-queuebot:#ubuntu-release- New: accepted libratbag [i386] (artful-proposed) [0.9-1]
-queuebot:#ubuntu-release- New binary: dolfin [ppc64el] (artful-proposed/universe) [2016.2.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [s390x] (artful-proposed/universe) [2016.2.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: qbs [amd64] (artful-proposed/universe) [1.8.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qbs [i386] (artful-proposed/universe) [1.8.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [amd64] (artful-proposed/universe) [2016.2.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [i386] (artful-proposed/universe) [2016.2.0-4] (no packageset)
<doko> infinity: we currently only have new binutils
<infinity> doko: Yes.  Which could very well be responsible for generating bad instructions.
-queuebot:#ubuntu-release- New: accepted tpm-tools [amd64] (artful-proposed) [1.3.9.1-0.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted tpm-tools [i386] (artful-proposed) [1.3.9.1-0.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted tpm-tools [s390x] (artful-proposed) [1.3.9.1-0.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted tpm-tools [arm64] (artful-proposed) [1.3.9.1-0.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted tpm-tools [ppc64el] (artful-proposed) [1.3.9.1-0.2ubuntu1]
-queuebot:#ubuntu-release- New binary: dolfin [armhf] (artful-proposed/universe) [2016.2.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: dolfin [arm64] (artful-proposed/universe) [2016.2.0-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted dolfin [amd64] (artful-proposed) [2016.2.0-4]
-queuebot:#ubuntu-release- New: accepted dolfin [armhf] (artful-proposed) [2016.2.0-4]
-queuebot:#ubuntu-release- New: accepted dolfin [ppc64el] (artful-proposed) [2016.2.0-4]
-queuebot:#ubuntu-release- New: accepted dolfin [arm64] (artful-proposed) [2016.2.0-4]
-queuebot:#ubuntu-release- New: accepted dolfin [s390x] (artful-proposed) [2016.2.0-4]
-queuebot:#ubuntu-release- New: accepted dolfin [i386] (artful-proposed) [2016.2.0-4]
-queuebot:#ubuntu-release- New: accepted qbs [amd64] (artful-proposed) [1.8.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qbs [i386] (artful-proposed) [1.8.1+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (artful-proposed) [2.02~beta3-4ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (artful-proposed) [2.02~beta3-4ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted xf86-input-mtrack-hwe-16.04 [source] (xenial-proposed) [0.3.1-1build2~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-void-hwe-16.04 [source] (xenial-proposed) [1:1.4.1-1build3~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-nouveau-hwe-16.04 [source] (xenial-proposed) [1:1.0.14-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-trident-hwe-16.04 [source] (xenial-proposed) [1:1.3.8-1build1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-vmware-hwe-16.04 [source] (xenial-proposed) [1:13.2.1-1build1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xf86-input-wacom-hwe-16.04 [source] (xenial-proposed) [1:0.34.0-0ubuntu2~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-qxl-hwe-16.04 [source] (xenial-proposed) [0.1.5-2build1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-dummy-hwe-16.04 [source] (xenial-proposed) [1:0.3.8-1build1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-vesa-hwe-16.04 [source] (xenial-proposed) [1:2.3.4-1build3~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-evdev-hwe-16.04 [source] (xenial-proposed) [1:2.10.5-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-amdgpu-hwe-16.04 [source] (xenial-proposed) [1.3.0-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-fbdev-hwe-16.04 [source] (xenial-proposed) [1:0.4.4-1build6~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-synaptics-hwe-16.04 [source] (xenial-proposed) [1.9.0-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-intel-hwe-16.04 [source] (xenial-proposed) [2:2.99.917+git20170309-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-ati-hwe-16.04 [source] (xenial-proposed) [1:7.9.0-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-siliconmotion-hwe-16.04 [source] (xenial-proposed) [1:1.7.9-2ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-tdfx-hwe-16.04 [source] (xenial-proposed) [1:1.4.7-1build1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-sisusb-hwe-16.04 [source] (xenial-proposed) [1:0.9.7-1build1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-mach64-hwe-16.04 [source] (xenial-proposed) [6.9.5-1build3~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-openchrome-hwe-16.04 [source] (xenial-proposed) [1:0.5.0-3build1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-savage-hwe-16.04 [source] (xenial-proposed) [1:2.3.9-1ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-neomagic-hwe-16.04 [source] (xenial-proposed) [1:1.2.9-1build3~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-r128-hwe-16.04 [source] (xenial-proposed) [6.10.2-1build1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-joystick-hwe-16.04 [source] (xenial-proposed) [1:1.6.3-1build1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-video-geode-hwe-16.04 [source] (xenial-proposed) [2.11.19-2~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xserver-xorg-input-libinput-hwe-16.04 [source] (xenial-proposed) [0.25.0-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted xorg-hwe-16.04 [source] (xenial-proposed) [1:7.7+16ubuntu3~16.04.1]
-queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (zesty-proposed/main) [5.7.1+dfsg-2ubuntu4~1 => 5.7.1+dfsg-2ubuntu4~1.17.04.1] (kubuntu, qt5, ubuntu-desktop)
#ubuntu-release 2017-07-07
-queuebot:#ubuntu-release- Unapproved: appstream-glib (zesty-proposed/main) [0.6.9-1 => 0.6.9-1ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: appstream-glib (xenial-proposed/main) [0.5.13-1ubuntu4 => 0.5.13-1ubuntu5] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: gnome-software (xenial-proposed/main) [3.20.1+git20170524.0.ea2fe2b0-0ubuntu0.16.04.1 => 3.20.5-0ubuntu0.16.04.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: haskell-alsa-core [ppc64el] (artful-proposed/universe) [0.5.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-attoparsec-iso8601 [ppc64el] (artful-proposed/universe) [1.0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-alsa-core [s390x] (artful-proposed/universe) [0.5.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-store-core [ppc64el] (artful-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-attoparsec-iso8601 [s390x] (artful-proposed/universe) [1.0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-store-core [s390x] (artful-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-aproba [amd64] (artful-proposed/universe) [1.0.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-has-unicode [amd64] (artful-proposed/universe) [2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-alsa-core [amd64] (artful-proposed/universe) [0.5.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-attoparsec-iso8601 [amd64] (artful-proposed/universe) [1.0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: mockldap [amd64] (artful-proposed/universe) [0.2.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-alsa-core [i386] (artful-proposed/universe) [0.5.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-attoparsec-iso8601 [i386] (artful-proposed/universe) [1.0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-gauge [amd64] (artful-proposed/universe) [2.7.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-store-core [amd64] (artful-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-store-core [i386] (artful-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-alsa-core [armhf] (artful-proposed/universe) [0.5.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-attoparsec-iso8601 [armhf] (artful-proposed/universe) [1.0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-alsa-core [arm64] (artful-proposed/universe) [0.5.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-attoparsec-iso8601 [arm64] (artful-proposed/universe) [1.0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-store-core [arm64] (artful-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-store-core [armhf] (artful-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-alsa-core [amd64] (artful-proposed) [0.5.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-alsa-core [armhf] (artful-proposed) [0.5.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-attoparsec-iso8601 [amd64] (artful-proposed) [1.0.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-attoparsec-iso8601 [armhf] (artful-proposed) [1.0.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-store-core [amd64] (artful-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-store-core [armhf] (artful-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted mockldap [amd64] (artful-proposed) [0.2.8-1]
-queuebot:#ubuntu-release- New: accepted node-gauge [amd64] (artful-proposed) [2.7.4-1]
-queuebot:#ubuntu-release- New: accepted haskell-alsa-core [arm64] (artful-proposed) [0.5.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-attoparsec-iso8601 [arm64] (artful-proposed) [1.0.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-store-core [arm64] (artful-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted node-aproba [amd64] (artful-proposed) [1.0.4-2]
-queuebot:#ubuntu-release- New: accepted haskell-alsa-core [i386] (artful-proposed) [0.5.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-store-core [i386] (artful-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-attoparsec-iso8601 [i386] (artful-proposed) [1.0.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-alsa-core [ppc64el] (artful-proposed) [0.5.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-attoparsec-iso8601 [ppc64el] (artful-proposed) [1.0.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-store-core [ppc64el] (artful-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted node-has-unicode [amd64] (artful-proposed) [2.0.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-alsa-core [s390x] (artful-proposed) [0.5.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-store-core [s390x] (artful-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-attoparsec-iso8601 [s390x] (artful-proposed) [1.0.0.0-1]
-queuebot:#ubuntu-release- Unapproved: ntp (xenial-proposed/main) [1:4.2.8p4+dfsg-3ubuntu5.5 => 1:4.2.8p4+dfsg-3ubuntu5.6] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ntp (yakkety-proposed/main) [1:4.2.8p8+dfsg-1ubuntu2.1 => 1:4.2.8p8+dfsg-1ubuntu2.2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ntp (zesty-proposed/main) [1:4.2.8p9+dfsg-2ubuntu1.1 => 1:4.2.8p9+dfsg-2ubuntu1.2] (ubuntu-server)
<tsimonq2> Morning release team! I got an email that the Lubuntu Xenial Daily build is FTBFS, and it seems to be because of a dependency problem with the HWE stack.
<tsimonq2> Is this something I need to be concerned about, or will it resolve itself?
<tsimonq2> Here's the exact dep problem if anyone is interested: http://paste.ubuntu.com/25037516/
<apw> tsimonq2, reporting it is good, likely it is teathing issue as i believe those are being wriggled in at the moment
<tsimonq2> apw: Reporting as I have just done, or should I file a bug somewhere?
<apw> tsimonq2, i think that is good enough
<tsimonq2> apw: Ok
<apw> infinity, tjaalton ^
<tsimonq2> apw: Ah ok, I didn't know who the HWE people were.
<tjaalton> ?
<tjaalton> tsimonq2: what's the problem?
<tsimonq2> tjaalton: https://irclogs.ubuntu.com/2017/07/07/%23ubuntu-release.html#t06:37 :)
<tjaalton> freenode cut me off
<tsimonq2> Ah ok
<tjaalton> tsimonq2: don't depend on -intel
<tsimonq2> tjaalton: Oh? Why not?
<tjaalton> because it's not compatible with hwe xserver
<tsimonq2> tjaalton: Lubuntu images don't follow recommends, and afair that was needed to fix some graphics issues on some Intel graphics cards.
<tsimonq2> Ok... so how do I still get this functionality?
<tjaalton> dunno why you didn't have issues with .2
<tsimonq2> These issues are just popping up with yesterday's builds.
<tjaalton> |xxvi-hwe-16.04
<tsimonq2> ?
<tjaalton> if you insist on using intel
<tjaalton> you need to fix the dep
<tsimonq2> Ok. Thanks for your time.
<apw> tjaalton, thanks :)
<tjaalton> nw, i'm glad these got in :)
<tjaalton> tsimonq2: though, if you had no issues with .2 maybe some builds were just missing
<tsimonq2> tjaalton: Oh?
<tjaalton> so wait until the next run?
<tsimonq2> tjaalton: Sure
-queuebot:#ubuntu-release- New binary: django-auth-ldap [amd64] (artful-proposed/universe) [1.2.12+dfsg-1] (no packageset)
<jibel> desktop images failed to build again this morning. Could someone have a look?
<jibel> infinity, ^
<tsimonq2> jibel: Would it happen to be because of the same dep error I described above?
<tsimonq2> jibel: i.e. http://paste.ubuntu.com/25037516/
<tsimonq2> s/error/problem/ is better wording. :)
<jibel> tsimonq2, I don't think so. The squashfs builds successfully but the ISO fails
<tsimonq2> jibel: Ah ok.
<tsimonq2> jibel: Just thought I'd ask. :)
-queuebot:#ubuntu-release- New binary: deja-dup [ppc64el] (artful-proposed/main) [34.4-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: deja-dup [s390x] (artful-proposed/main) [34.4-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: deja-dup [amd64] (artful-proposed/main) [34.4-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: deja-dup [i386] (artful-proposed/main) [34.4-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: deja-dup [armhf] (artful-proposed/main) [34.4-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: deja-dup [arm64] (artful-proposed/main) [34.4-0ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted deja-dup [amd64] (artful-proposed) [34.4-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted deja-dup [armhf] (artful-proposed) [34.4-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted deja-dup [ppc64el] (artful-proposed) [34.4-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted deja-dup [arm64] (artful-proposed) [34.4-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted deja-dup [s390x] (artful-proposed) [34.4-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted deja-dup [i386] (artful-proposed) [34.4-0ubuntu3]
<infinity> jibel: For artful?
<jibel> infinity, yes artfl
<jibel> +u
<infinity> Oh, hrm.  Neat.
<infinity> And by "neat", I mean "WTF".
<jibel> that's a way to say it
<infinity> jibel: How long has it been failing?  I've been head down in xenial crap all week.
<jibel> infinity, yesterday
<jibel> infinity, 20170706 is the first build that failed
<infinity> I wonder if I can blame the new apt somehow.
<infinity> Oh.
<infinity> Or we could blame someone overexhuberantly demoting isolinux to universe.
<infinity> WE KINDA USE THAT A LITTLE BIT.
<tsimonq2> apw, tjaalton: Yeppp, a simple ISO rebuild fixed it.
<apw> infinity, that sounds a little unexpected!
<tsimonq2> infinity: WAIT WHAT...
<tjaalton> tsimonq2: cool
<infinity> apw: Looks like it was never explicitly seeded, so something probably stopped accidentally pulling it in.
<infinity> I'll just seed it.
<apw> heh a good plan indeed
<jibel> infinity, blame didrocks I suppose
<jibel> infinity, he's cleaning the desktop seed to remove unity
<infinity> jibel: It was never seeded.  I think it was just accidentally in main due to being an rdep of $something.
<infinity> And it isn't anymore.
<apw> infinity, i think that have been syslinux-themes-ubuntu
<apw> -> syslinux-themes-ubuntu-xenial -> isolinux
<infinity> Oh, do we not do that anymore?
<apw> seems not as of 5th, which is about right timing wise
<infinity> Yeah.
<infinity> I meant "do we not use those themes anymore".
<infinity> I kinda thought that's what was responsible for making the ISO boot screen (for BIOS) pretty.
<infinity> Oh, no, that's gfxboot-theme-ubuntu
<infinity> Confusing.
<ogra_> yeah, but everyone dooes that ...
<ogra_> ugliness sticks out nowadays :)
<infinity> jibel: Alright, isolinux seeded and re-promoted.  Should resolve itself, but I'll probably test a bit later to be sure.
-queuebot:#ubuntu-release- Unapproved: rejected fwupdate [source] (xenial-proposed) [0.5-2ubuntu5]
<infinity> This is where I wish overrides had an audit trail, though.
<infinity> I don't blame didrocks for not knowing that unseeding themes would drop isolinux out of main, but I totally blame the AA who blindly followed component-mismatches without questioning "hey, do we use that thing?"
<tsimonq2> infinity: But isn't he an AA?
<infinity> tsimonq2: Your failure was xenial-specific, and had to do with the xserver and drivers being mismatched.  Should have been fixed 10 hours ago or so.
<infinity> tsimonq2: Sure, but that doesn't mean he's the one who demoted the package.
<tsimonq2> infinity: Yep, fixed by a rebuild.
<tsimonq2> infinity: Fair.
<tsimonq2> infinity: Just thought I'd point it out. :)
<infinity> Hence "I wish there was auditing".
<infinity> LocutusOfBorg: Oh good, you're around again.  Mind if I yell at you?
<infinity> LocutusOfBorg: "The testuite fails with a SIGILL, I guess I should disable it and let a miscompiled package migrate" is not the correct train of thought. :P
<infinity> LocutusOfBorg: proposed-migration isn't a video game, it was very much doing its job there.
<LocutusOfBorg> infinity, yell at me whenever you want :)
<infinity> LocutusOfBorg: Consider yourself yelled at.
<LocutusOfBorg> I'll read soon(TM)
<LocutusOfBorg> :)
<infinity> LocutusOfBorg: But seriously, please don't treat migration as a game where the object is to get stuff through at any cost.  Bugs being caught is WHY it's there.
<LocutusOfBorg> oh, can I give you some background?
<LocutusOfBorg> :)
<LocutusOfBorg> at the time I disabled that, after talking with bremner, the reasons were multiple for disabling it:
<LocutusOfBorg> it didn't fail locally, bremner told that gdb on arm* is usually broken a lot, and also in debian that testsuite is disabled on many architectures
<LocutusOfBorg> at that time we had a newer gdb in Ubuntu, so we were confident about a gdb regression, and we agreed on looking at it after stretch
<infinity> LocutusOfBorg: Didn't fail locally in what environment?
<LocutusOfBorg> armhf* probably was on some qemu stuff, so the testsuite was not reliable too much
<infinity> LocutusOfBorg: armhf is not built on qemu, it's built on real hardware, in both Debian and Ubuntu.
<LocutusOfBorg> sorry infinity I can't recall exactly what I did, but I remember talking here with Colin and Matthias IIRC
<LocutusOfBorg> infinity, I think back in those days it was, or maybe it was only for ppas, the way I had to do testing
<LocutusOfBorg> now it should be real hw everywhere I presume
<infinity> LocutusOfBorg: "Those days"?  You disabled the testsuite yesterday...
<LocutusOfBorg> nah
<LocutusOfBorg> everytime I try a force-sync and disable it again after talking with bremner
<infinity> Ahh.  Is it always a SIGILL?
<LocutusOfBorg> that sigkill has been discovered only yesterday, look at publish log
<cjwatson> Just for the record I didn't say "sure, go ahead and disable the testsuite", so don't invoke my name for this
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/notmuch/+publishinghistory
<LocutusOfBorg> cjwatson, I didn't say that :) you helped me understanding why ppas and official builders were different
<cjwatson> Right, but you kind of implied it.
<LocutusOfBorg> sorry, this wasn't in my intentions
<infinity> LocutusOfBorg: Okay, "it's been broken like this forever" is more reasonable.  That's not at all how I read backscroll.
<infinity> LocutusOfBorg: I saw "I investigated this and found a SIGILL, and decided to let it through anyway".
<cjwatson> It is true that at one point there were terrible bad times when we were running armhf PPA builds in qemu and lots of things exploded.  Not been that way for a couple of years.
<cjwatson> Well, at least a year.  I lose track of dates.
-queuebot:#ubuntu-release- New binary: ceph [ppc64el] (artful-proposed/main) [12.1.0-0ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/notmuch/0.22.1-3ubuntu2
<LocutusOfBorg> this was when I disabled it, so am I partly forgiven? :P
<LocutusOfBorg> it was when emacs has been promoted to main, and notmuch too
<LocutusOfBorg> anyway, I want to fix that bug if there is one, how can I do it?
<LocutusOfBorg> I don't have real hw
<LocutusOfBorg> and if this is a bug in gcc/glibc, I really don't know where to start
-queuebot:#ubuntu-release- New binary: ceph [i386] (artful-proposed/main) [12.1.0-0ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
<cjwatson> By the date of that upload, all the old armhf PPA qemu nonsense had been dead for at least six months.
<cjwatson> So let's discard that as even possibly relevant.
<infinity> LocutusOfBorg: Figuring out what the illegal instruction is would be helpful.
<infinity> LocutusOfBorg: It won't have anything to do with glibc.
<infinity> LocutusOfBorg: It *could* have something to do with gcc.
<infinity> LocutusOfBorg: But more likely, it's the code itself making bad assumptions.
<LocutusOfBorg> if you read #debian-devel I told bremner mostly the same things (he is upstream)
<LocutusOfBorg> and the answer was "I don't care about possible code bugs that debian didn't spot"
<LocutusOfBorg> I told about possible difference in optimization levels
<LocutusOfBorg> I even tried to pick gdb from debian, but my armhf qemu sucks
<LocutusOfBorg> really, this wasn't a "lets disable and live happy"
<LocutusOfBorg> I spent days in trying to figure it out
<infinity> LocutusOfBorg: Right, you're slightly more off the hook for yesterday's upload given the "it's been broken forever" thing.
<infinity> LocutusOfBorg: Like I said, it appeared from backscroll that it was a regression, not "same bug, different day".
<infinity> SIGILL in Ubuntu and not Debian is curious, though.  I *think* Debian still builds on real armv7 hardware, and ours being armv8 is teeeechnically missing one instruction.  But it's one instruction no one should be using.
<infinity> (And it's an instruction that was optional in v7, it's just that everyone opted into including it for backward compat with v... 5?)
<LocutusOfBorg> if you read devel, we tried on different porterboxes too
<LocutusOfBorg> e.g. abel
<LocutusOfBorg> and yeah, abel is v7
<infinity> Yeah, it's an ArmadaXP.
<LocutusOfBorg> I work sometimes with i.MX6 hw, but it is yocto based, so I don't have an easy way to port the same toolchain
<infinity> Well, also v7.
<LocutusOfBorg> ough
<LocutusOfBorg> right
<LocutusOfBorg> so, do you have any advice for me? or can you help in some way?
<infinity> I have neither advice nor time right now.  But I'm also less grumpy knowing that this has been known for ages, and isn't a regression.
<LocutusOfBorg> ages? this is a regression since yakkety, so not really ages :)
<cjwatson> LocutusOfBorg: it sounds like the next step is figuring out which instruction is involved; you can get that out of siginfo_t in a signal handler (though there might be easier ways)
<LocutusOfBorg> but how can I trigger this in a ppa build?
<cjwatson> LocutusOfBorg: if you get something like that that dumps out relevant information, you could experiment via a PPA
<LocutusOfBorg> mmm let me google around :D
<cjwatson> patch the relevant binary to install a signal handler?  or if you think it might show up in system logs then you just need a || handler in shell somewhere
<LocutusOfBorg> the testsuite runs in a shell script, so I might intercept it there
<LocutusOfBorg> let me try, awesome
-queuebot:#ubuntu-release- New binary: ceph [s390x] (artful-proposed/main) [12.1.0-0ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: fifechan [ppc64el] (artful-proposed/universe) [0.1.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fifechan [s390x] (artful-proposed/universe) [0.1.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fifechan [i386] (artful-proposed/universe) [0.1.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fifechan [amd64] (artful-proposed/universe) [0.1.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fifechan [arm64] (artful-proposed/universe) [0.1.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fifechan [armhf] (artful-proposed/universe) [0.1.4-2] (no packageset)
<didrocks> infinity: yeah, sorry for unseeding. I didn't demote it though (as I was unsure about the -ubuntu one). I also noticed somebody demoted a lot of binary packages only movement, where I was analyzing the non source + all binaries movements. Makes it harder to keep the list of things to work on known (I hope that the current binary-only demotion will be kept that way) :/
<infinity> jibel: Fresh builds worked, FYI.
<didrocks> thanks infinity
-queuebot:#ubuntu-release- New binary: django-auth-ldap [amd64] (artful-proposed/universe) [1.2.13+dfsg-1] (no packageset)
<jibel> infinity, thanks
-queuebot:#ubuntu-release- New: accepted django-auth-ldap [amd64] (artful-proposed) [1.2.12+dfsg-1]
-queuebot:#ubuntu-release- New: accepted fifechan [arm64] (artful-proposed) [0.1.4-2]
-queuebot:#ubuntu-release- New: accepted fifechan [i386] (artful-proposed) [0.1.4-2]
-queuebot:#ubuntu-release- New: accepted fifechan [s390x] (artful-proposed) [0.1.4-2]
-queuebot:#ubuntu-release- New: accepted fifechan [amd64] (artful-proposed) [0.1.4-2]
-queuebot:#ubuntu-release- New: accepted fifechan [ppc64el] (artful-proposed) [0.1.4-2]
-queuebot:#ubuntu-release- New: accepted fifechan [armhf] (artful-proposed) [0.1.4-2]
-queuebot:#ubuntu-release- New binary: ceph [amd64] (artful-proposed/main) [12.1.0-0ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: ceph [armhf] (artful-proposed/main) [12.1.0-0ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
<slangasek> infinity: any recent changes to the debian-cd repo that might explain this build failure for artful server on amd64+i386?
<slangasek> infinity: http://pastebin.ubuntu.com/25039610/
<jibel> slangasek, infinity fixed this this morning. isolinux was not seeded and missing.
<jibel> there was the same error for desktop
<slangasek> ok
<slangasek> I'll just respin then and see
<slangasek> powersj: http://cdimage.ubuntu.com/ubuntu-server/daily/20170707.1/artful-server-amd64.OVERSIZED
-queuebot:#ubuntu-release- New binary: ceph [arm64] (artful-proposed/main) [12.1.0-0ubuntu1] (kubuntu, ubuntu-desktop, ubuntu-server)
<powersj> ouch on the 5th it was right at 700mb
<slangasek> well, the good news is that it's built
<slangasek> the bad news is that it's 30MB larger? :)
<powersj> haha yep
-queuebot:#ubuntu-release- New: accepted ceph [amd64] (artful-proposed) [12.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ceph [armhf] (artful-proposed) [12.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ceph [ppc64el] (artful-proposed) [12.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted django-auth-ldap [amd64] (artful-proposed) [1.2.13+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ceph [arm64] (artful-proposed) [12.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ceph [s390x] (artful-proposed) [12.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ceph [i386] (artful-proposed) [12.1.0-0ubuntu1]
<slangasek> what fresh craziness is this from pkg-perl-autopkgtest? Not installing the package, then failing the test because the package isn't installed? :P http://autopkgtest.ubuntu.com/packages/libc/libcompress-raw-bzip2-perl/artful/amd64
<powersj> slangasek: http://paste.ubuntu.com/25039944/ looks like bunch of new packages were pulled onto the ISO
<slangasek> well that's interesting
<powersj> adwaita-icon-theme -- that's useful for server ;)
<slangasek> I'm not seeing why any of that is pulled in
<jbicha> server-ship depends on kerneloops-daemon, kerneloops provides kerneloops-daemon, kerneloops recommends kerneloops-applet
<jbicha> I suggest dropping that recommends then
<slangasek> heh, quite
<slangasek> was kerneloops newly seeded?
<jbicha> no, but the kerneloops packging was changed: https://launchpad.net/ubuntu/+source/kerneloops/0.12+git20140509-6ubuntu1
<slangasek> jbicha: well, kerneloops was also in powersj's 'added' list, not 'updated'
<jbicha> yes because of the provides
<slangasek> ok, so the Provides: kerneloops-daemon was previously missing
<slangasek> and kerneloops-daemon was a separate package name through zesty
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (yakkety-proposed/universe) [1.0+16.10ubuntu1.1 => 1.1+16.10ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (zesty-proposed/universe) [1.0+17.04ubuntu1.1 => 1.1+17.04ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (xenial-proposed/universe) [1.0+16.04ubuntu1 => 1.1+16.04ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libvirt (zesty-proposed/main) [2.5.0-3ubuntu5.2 => 2.5.0-3ubuntu5.3] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: libvirt (xenial-proposed/main) [1.3.1-1ubuntu10.10 => 1.3.1-1ubuntu10.11] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: accepted maas [source] (yakkety-proposed) [2.2.0+bzr6054-0ubuntu2~16.10.1]
-queuebot:#ubuntu-release- Unapproved: accepted maas [source] (xenial-proposed) [2.2.0+bzr6054-0ubuntu2~16.04.1]
-queuebot:#ubuntu-release- New binary: klaus [amd64] (artful-proposed/universe) [1.2.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-googleauth [amd64] (artful-proposed/universe) [0.5.1-2] (no packageset)
#ubuntu-release 2017-07-08
-queuebot:#ubuntu-release- Unapproved: variety (xenial-proposed/universe) [0.6.0-1ubuntu1 => 0.6.0-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: variety (zesty-proposed/universe) [0.6.3-2 => 0.6.3-2ubuntu1] (no packageset)
<LocutusOfBorg> hello cjwatson, wrt your advice, I spent the whole evening trying to catch signals, adding the code, and the bash traps, and nothing relevant has been spotted
<LocutusOfBorg> however, I did put the test under strace, and something interesting is here
<LocutusOfBorg> https://launchpadlibrarian.net/327521245/buildlog_ubuntu-artful-armhf.notmuch_0.24.2-2ubuntu14_BUILDING.txt.gz
<LocutusOfBorg> between BEGIN OUTPUT and END OUTPUT
<LocutusOfBorg> rt_sigaction(SIGSEGV, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0xf6f54071}, NULL, 8) = 0
<LocutusOfBorg> write(17, "\nProgram received signal SIGILL,"..., 74) = 74
<LocutusOfBorg> is this what you requested?
<LocutusOfBorg> infinity, ^^ :)
<LocutusOfBorg> if you think I'm on the right track, I'll continue debugging :D
<LocutusOfBorg> I'll be afk, so lets continue on monday, have a nice sunday! :)
#ubuntu-release 2017-07-09
-queuebot:#ubuntu-release- New binary: ruby-mocha [amd64] (artful-proposed/universe) [1.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmicrohttpd [ppc64el] (artful-proposed/universe) [0.9.55-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmicrohttpd [amd64] (artful-proposed/universe) [0.9.55-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmicrohttpd [s390x] (artful-proposed/universe) [0.9.55-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmicrohttpd [i386] (artful-proposed/universe) [0.9.55-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmicrohttpd [arm64] (artful-proposed/universe) [0.9.55-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libmicrohttpd [armhf] (artful-proposed/universe) [0.9.55-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted klaus [amd64] (artful-proposed) [1.2.1-3]
-queuebot:#ubuntu-release- New: accepted libmicrohttpd [arm64] (artful-proposed) [0.9.55-1]
-queuebot:#ubuntu-release- New: accepted libmicrohttpd [i386] (artful-proposed) [0.9.55-1]
-queuebot:#ubuntu-release- New: accepted libmicrohttpd [s390x] (artful-proposed) [0.9.55-1]
-queuebot:#ubuntu-release- New: accepted ruby-mocha [amd64] (artful-proposed) [1.2.1-1]
-queuebot:#ubuntu-release- New: accepted libmicrohttpd [amd64] (artful-proposed) [0.9.55-1]
-queuebot:#ubuntu-release- New: accepted libmicrohttpd [ppc64el] (artful-proposed) [0.9.55-1]
-queuebot:#ubuntu-release- New: accepted libmicrohttpd [armhf] (artful-proposed) [0.9.55-1]
-queuebot:#ubuntu-release- New: accepted ruby-googleauth [amd64] (artful-proposed) [0.5.1-2]
#ubuntu-release 2018-07-02
<ginggs> xnox: libboost-python1.65-dev seems to be missing a libboost_python-py37.so symlink
<ginggs> xnox: and similar in libboost-mpi-python1.65-dev
<ginggs> xnox: and I think libboost-mpi-python1.65 misses the python 3.7 version of mpi.so
-queuebot:#ubuntu-release- Unapproved: intel-microcode (artful-proposed/main) [3.20180425.1~ubuntu0.17.10.1 => 3.20180425.1ubuntu0.17.10.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: intel-microcode (xenial-proposed/main) [3.20180425.1~ubuntu0.16.04.1 => 3.20180425.1ubuntu0.16.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: intel-microcode (trusty-proposed/main) [3.20180425.1~ubuntu0.14.04.1 => 3.20180425.1ubuntu0.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: amd64-microcode (artful-proposed/main) [3.20180524.1~ubuntu0.17.10.1 => 3.20180524.1ubuntu0.17.10.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: intel-microcode (bionic-proposed/main) [3.20180425.1~ubuntu0.18.04.1 => 3.20180425.1ubuntu0.18.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: amd64-microcode (xenial-proposed/main) [3.20180524.1~ubuntu0.16.04.1 => 3.20180524.1ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: amd64-microcode (bionic-proposed/main) [3.20180524.1~ubuntu0.18.04.1 => 3.20180524.1ubuntu0.18.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: amd64-microcode (trusty-proposed/main) [3.20180524.1~ubuntu0.14.04.1 => 3.20180524.1ubuntu0.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: update-notifier (bionic-proposed/main) [3.192.1.2 => 3.192.1.3] (ubuntu-desktop, ubuntu-server)
<didrocks> I'm reject it ^ going, to reupload with -v
-queuebot:#ubuntu-release- Unapproved: rejected update-notifier [source] (bionic-proposed) [3.192.1.3]
-queuebot:#ubuntu-release- Unapproved: update-notifier (bionic-proposed/main) [3.192.1.2 => 3.192.1.3] (ubuntu-desktop, ubuntu-server)
<didrocks> and here is the version debugged thanks to jibel fixing previous SRU attempt (which is in -proposed), it should override it ^
-queuebot:#ubuntu-release- Unapproved: fpc (bionic-proposed/universe) [3.0.4+dfsg-18 => 3.0.4+dfsg-18ubuntu1] (no packageset)
<didrocks> bdmurray: hey! When you got time, mind having a look at the update-notifier SRU which is a followup on the previous one to fix one issue? ^
<xnox> ginggs, sure, but why would that be a problem?!
<xnox> ginggs, it's not the default version
<xnox> ginggs, do you have FTBFS examples of packages that build-dep on boost-python-dev and somehow fail to compile for v3.7?
<ginggs> xnox: https://launchpad.net/ubuntu/+source/minieigen/0.50.3+dfsg1-5ubuntu1
<xnox> ginggs, looking
<xnox> ginggs, thanks.
<xnox> ginggs, most likely this will not be fixed with bootst1.65 fyi, but only with 1.67
<ginggs> ginggs: i think this might be the fix https://salsa.debian.org/debian/boost/commit/b97cc7d9596638c5cb13d58702660d85dcb354ca
<ginggs> xnox: ^ i mean :)
<ginggs> xnox: and i've just seen gio committed some things for mpi python recently too
<xnox> ginggs, please do not touch boost.
<xnox> ginggs, and all that is still wrong =) but differently =)
<ginggs> xnox: i wasn't planning to, that's why i highlighted you :)
<LocutusOfBorg> for your happyness, please remove llvm-toolchain-3.7 from cosmic
<LocutusOfBorg> slangasek, ^^ doko ^^ (ghc is now migrated, and Debian removed it already=
<sil2100> juliank: hey, any reason why you changed the intel-microcode package versioning scheme?
<juliank> sil2100: I'm not sure. So the versioning scheme so far has been because we started with ~ubuntu0.18.04.1, but now it went to ubuntu1
<juliank> so I just started replacing ubuntu1 with 0.<release>.1
<sil2100> juliank: well, currently in bionic-security/-updates there's ~ubuntu0.18.04.1
<juliank> I even considered ubuntu1~18.04.1
<sil2100> juliank: so I'd expect the next version with only debian changes be ~ubuntu0.18.04.2 if anything
<sil2100> juliank: since basically your changes are adding on top of what's currently in bionic
<sil2100> juliank: right now the version numbers will be changing from 3.20180425.1~ubuntu0.18.04.1 to 3.20180425.1ubuntu0.18.04.1, which seems a bit confusing
<sil2100> Since even though it's a higher version, in theory it looks like a re-release of the same thing
<juliank> I agree
<juliank> I just figured I
<juliank> I already built them like this so I just uploaded them.
<juliank> But I can extract and change the version and rebuild it
<juliank> sil2100: In practice, I'd prefer to have ubuntu1~18.04.1 and friends (backport-style uploads), but I don't really care a lot
<ginggs> xnox: and woo https://launchpad.net/ubuntu/+source/woo/1.0+dfsg1-2ubuntu2  - not woo! \o/
<xnox> ginggs, yes, it is unforunate that new boost is not ready yet. but what can we do, we do need to start gcc & python transitions.
<xnox> ginggs, doko and I, are aware of the timelines of transitions =/
<doko> well, still waiting a little bit with GCC
<sil2100> juliank: I'd prefer to have consistency with what's in the archive, instead of people making mistakes thinking they didn't really get an upgrade
<juliank> sil2100: well, reject the SRUs then and I'll reupload them with different version numbers
<juliank> sil2100: there are 8 in total, amd64,intel and bionic,artful,xenial,trusty
-queuebot:#ubuntu-release- Unapproved: rejected amd64-microcode [source] (artful-proposed) [3.20180524.1ubuntu0.17.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected amd64-microcode [source] (bionic-proposed) [3.20180524.1ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected amd64-microcode [source] (xenial-proposed) [3.20180524.1ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected intel-microcode [source] (artful-proposed) [3.20180425.1ubuntu0.17.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected intel-microcode [source] (xenial-proposed) [3.20180425.1ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected intel-microcode [source] (bionic-proposed) [3.20180425.1ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected amd64-microcode [source] (trusty-proposed) [3.20180524.1ubuntu0.14.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected intel-microcode [source] (trusty-proposed) [3.20180425.1ubuntu0.14.04.1]
<didrocks> sil2100: hey, do you mind replacing current update-notifier with the new one in unapproved? It's fixing an issue jibel spotted when testing the SRU (the fix is already in cosmic)
<sil2100> didrocks: looking
<didrocks> thx ;)
<didrocks> should be an easy diff :p
<sil2100> didrocks: looks good - there's a typo in the changelog s/patch/path but nothing needing a re-upload, all clear ;)
<didrocks> sil2100: oupsss ;) thanks!
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (bionic-proposed) [3.192.1.3]
 * sil2100 reviews the new KDE plasma stack
<Laney> hey, go oldest first!
<didrocks> thanks sil2100 for u-n ;)
<acheronuk> sil2100: they should all have at least translation updates this time I hope. I left out the ones with just version bump
<acheronuk> sil2100: thanks
-queuebot:#ubuntu-release- Unapproved: amd64-microcode (trusty-proposed/main) [3.20180524.1~ubuntu0.14.04.1 => 3.20180524.1~ubuntu0.14.04.2] (no packageset)
<juliank> sil2100: OK, reuploaded, I hope I did not mess up things :)
<sil2100> Laney: I can't see the oldest because of all the KDE syncs!
-queuebot:#ubuntu-release- Unapproved: amd64-microcode (artful-proposed/main) [3.20180524.1~ubuntu0.17.10.1 => 3.20180524.1~ubuntu0.17.10.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: amd64-microcode (bionic-proposed/main) [3.20180524.1~ubuntu0.18.04.1 => 3.20180524.1~ubuntu0.18.04.2] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: intel-microcode (trusty-proposed/main) [3.20180425.1~ubuntu0.14.04.1 => 3.20180425.1~ubuntu0.14.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: intel-microcode (xenial-proposed/main) [3.20180425.1~ubuntu0.16.04.1 => 3.20180425.1~ubuntu0.16.04.2] (ubuntu-desktop, ubuntu-server)
<juliank> queuebot still has 8 notifications to go
<sil2100> Laney: blame acheronuk !
-queuebot:#ubuntu-release- Unapproved: intel-microcode (artful-proposed/main) [3.20180425.1~ubuntu0.17.10.1 => 3.20180425.1~ubuntu0.17.10.2] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: amd64-microcode (xenial-proposed/main) [3.20180524.1~ubuntu0.16.04.1 => 3.20180524.1~ubuntu0.16.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: intel-microcode (bionic-proposed/main) [3.20180425.1~ubuntu0.18.04.1 => 3.20180425.1~ubuntu0.18.04.2] (ubuntu-desktop, ubuntu-server)
<sil2100> juliank: thanks! :)
<juliank> well, there the notifications are
<sil2100> I need to get rid of these bazillion packages from the queue for my well-being, as they make me feel depressed
-queuebot:#ubuntu-release- Unapproved: accepted bluedevil [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted breeze [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted drkonqi [sync] (bionic-proposed) [5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kactivitymanagerd [sync] (bionic-proposed) [5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kde-cli-tools [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kdeplasma-addons [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kgamma5 [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted khotkeys [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kinfocenter [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kmenuedit [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kscreen [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kscreenlocker [sync] (bionic-proposed) [5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted ksshaskpass [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted ksysguard [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kwin [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kwrited [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted libksysguard [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted milou [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted oxygen [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-desktop [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-discover [sync] (bionic-proposed) [5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-integration [sync] (bionic-proposed) [5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-nm [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-pa [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-sdk [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-vault [sync] (bionic-proposed) [5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-workspace [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plymouth-kcm [sync] (bionic-proposed) [5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted polkit-kde-agent-1 [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted powerdevil [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted sddm-kcm [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted systemsettings [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted user-manager [sync] (bionic-proposed) [4:5.12.6-0ubuntu0.1]
 * Laney sheds a tear for the autopkgtest queues
-queuebot:#ubuntu-release- Unapproved: mdadm (bionic-proposed/main) [4.0-2ubuntu1.1 => 4.1~rc1-3~ubuntu18.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted intel-microcode [source] (bionic-proposed) [3.20180425.1~ubuntu0.18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted amd64-microcode [source] (bionic-proposed) [3.20180524.1~ubuntu0.18.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted intel-microcode [source] (artful-proposed) [3.20180425.1~ubuntu0.17.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted amd64-microcode [source] (artful-proposed) [3.20180524.1~ubuntu0.17.10.2]
-queuebot:#ubuntu-release- Unapproved: accepted intel-microcode [source] (xenial-proposed) [3.20180425.1~ubuntu0.16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted amd64-microcode [source] (xenial-proposed) [3.20180524.1~ubuntu0.16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.34]
<sil2100> juliank: ok, so those are now all more-or-less ok - I'm accepthing them all but a thing to note: some old changelog entries for xenial and trusty have been modified, like some dates changed in the 'sig (...)' entries - but I'm not blocking on that
<sil2100> Since changelogs are changelogs
-queuebot:#ubuntu-release- Unapproved: accepted intel-microcode [source] (trusty-proposed) [3.20180425.1~ubuntu0.14.04.2]
<juliank> sil2100: yeah, they were mismerged previously
<juliank> Well in the last update I think
<juliank> because Debian changed them
<juliank> *updated
-queuebot:#ubuntu-release- Unapproved: accepted amd64-microcode [source] (trusty-proposed) [3.20180524.1~ubuntu0.14.04.2]
-queuebot:#ubuntu-release- New binary: golang-github-disposaboy-jsonconfigreader [amd64] (cosmic-proposed/none) [0.0~git20171218.5ea4d0d-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpqxx [s390x] (cosmic-proposed/universe) [6.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpqxx [ppc64el] (cosmic-proposed/universe) [6.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: codec2 [s390x] (cosmic-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: codec2 [ppc64el] (cosmic-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libsass [s390x] (cosmic-proposed/universe) [3.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: codec2 [i386] (cosmic-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-awalterschulze-gographviz [amd64] (cosmic-proposed/none) [2.0+git20180607.da5c847-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-dsnet-golib [amd64] (cosmic-proposed/none) [0.0~git20171103.1ea1667-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-jpillora-backoff [amd64] (cosmic-proposed/none) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-aleksi-pointer [amd64] (cosmic-proposed/none) [1.0.0+git20180620.11deede-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-hashicorp-go-hclog [amd64] (cosmic-proposed/none) [0.0~git20180402.69ff559-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-burntsushi-locker [amd64] (cosmic-proposed/none) [0.0~git20171006.a6e239e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mitchellh-go-testing-interface [amd64] (cosmic-proposed/none) [0.0~git20171004.a61a995-1] (no packageset)
-queuebot:#ubuntu-release- New binary: codec2 [armhf] (cosmic-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-soniah-gosnmp [amd64] (cosmic-proposed/none) [1.9+git20180420.bcf840d-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libsass [ppc64el] (cosmic-proposed/universe) [3.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-smira-flag [amd64] (cosmic-proposed/none) [0.0~git20170926.695ea5e-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpqxx [armhf] (cosmic-proposed/universe) [6.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpqxx [arm64] (cosmic-proposed/universe) [6.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libsass [amd64] (cosmic-proposed/universe) [3.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vkd3d [amd64] (cosmic-proposed/universe) [1.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libprotocol-irc-perl [amd64] (cosmic-proposed/none) [0.12-2] (no packageset)
-queuebot:#ubuntu-release- New binary: vkd3d [s390x] (cosmic-proposed/universe) [1.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-ros-comm-msgs [amd64] (cosmic-proposed/universe) [1.11.2-9] (no packageset)
-queuebot:#ubuntu-release- New binary: libdist-zilla-plugin-metaprovides-package-perl [amd64] (cosmic-proposed/none) [2.004003-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vkd3d [ppc64el] (cosmic-proposed/universe) [1.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: vkd3d [i386] (cosmic-proposed/universe) [1.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: codec2 [amd64] (cosmic-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-vbatts-go-mtree [amd64] (cosmic-proposed/none) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtest-http-localserver-perl [amd64] (cosmic-proposed/none) [0.63-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-mkrautz-goar [amd64] (cosmic-proposed/none) [0.0~git20150919.282caa8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libnet-dns-resolver-mock-perl [amd64] (cosmic-proposed/none) [1.20171219-1] (no packageset)
-queuebot:#ubuntu-release- New binary: codec2 [arm64] (cosmic-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libtangence-perl [amd64] (cosmic-proposed/universe) [0.24-2] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-syncthing-notify [amd64] (cosmic-proposed/universe) [0.0~git20180626.cdf89c4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libpqxx [i386] (cosmic-proposed/universe) [6.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libpqxx [amd64] (cosmic-proposed/universe) [6.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libsass [armhf] (cosmic-proposed/universe) [3.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libsass [arm64] (cosmic-proposed/universe) [3.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libsass [i386] (cosmic-proposed/universe) [3.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pike8.0 [s390x] (cosmic-proposed/universe) [8.0.610-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bottleneck [s390x] (cosmic-proposed/universe) [1.2.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pike8.0 [i386] (cosmic-proposed/universe) [8.0.610-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pike8.0 [amd64] (cosmic-proposed/universe) [8.0.610-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pike8.0 [ppc64el] (cosmic-proposed/universe) [8.0.610-1] (no packageset)
-queuebot:#ubuntu-release- New binary: vkd3d [armhf] (cosmic-proposed/universe) [1.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: vkd3d [arm64] (cosmic-proposed/universe) [1.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: bottleneck [ppc64el] (cosmic-proposed/universe) [1.2.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bottleneck [i386] (cosmic-proposed/universe) [1.2.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bottleneck [amd64] (cosmic-proposed/universe) [1.2.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pike8.0 [arm64] (cosmic-proposed/universe) [8.0.610-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pike8.0 [armhf] (cosmic-proposed/universe) [8.0.610-1] (no packageset)
<slangasek> LocutusOfBorg: llvm-toolchain-3.7 removed, cheers
<LocutusOfBorg> lovely! thanks!
-queuebot:#ubuntu-release- New binary: bottleneck [armhf] (cosmic-proposed/universe) [1.2.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted codec2 [amd64] (cosmic-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted codec2 [armhf] (cosmic-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted codec2 [ppc64el] (cosmic-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted codec2 [arm64] (cosmic-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted codec2 [s390x] (cosmic-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted codec2 [i386] (cosmic-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-aleksi-pointer [amd64] (cosmic-proposed) [1.0.0+git20180620.11deede-1]
-queuebot:#ubuntu-release- New: accepted golang-github-burntsushi-locker [amd64] (cosmic-proposed) [0.0~git20171006.a6e239e-1]
-queuebot:#ubuntu-release- New: accepted golang-github-dsnet-golib [amd64] (cosmic-proposed) [0.0~git20171103.1ea1667-1]
-queuebot:#ubuntu-release- New: accepted golang-github-jpillora-backoff [amd64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-mkrautz-goar [amd64] (cosmic-proposed) [0.0~git20150919.282caa8-1]
-queuebot:#ubuntu-release- New: accepted golang-github-soniah-gosnmp [amd64] (cosmic-proposed) [1.9+git20180420.bcf840d-1]
-queuebot:#ubuntu-release- New: accepted golang-github-vbatts-go-mtree [amd64] (cosmic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted libnet-dns-resolver-mock-perl [amd64] (cosmic-proposed) [1.20171219-1]
-queuebot:#ubuntu-release- New: accepted libpqxx [arm64] (cosmic-proposed) [6.1.0-1]
-queuebot:#ubuntu-release- New: accepted libpqxx [i386] (cosmic-proposed) [6.1.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-awalterschulze-gographviz [amd64] (cosmic-proposed) [2.0+git20180607.da5c847-1]
-queuebot:#ubuntu-release- New: accepted golang-github-hashicorp-go-hclog [amd64] (cosmic-proposed) [0.0~git20180402.69ff559-1]
-queuebot:#ubuntu-release- New: accepted golang-github-smira-flag [amd64] (cosmic-proposed) [0.0~git20170926.695ea5e-1]
-queuebot:#ubuntu-release- New: accepted libdist-zilla-plugin-metaprovides-package-perl [amd64] (cosmic-proposed) [2.004003-1]
-queuebot:#ubuntu-release- New: accepted libpqxx [armhf] (cosmic-proposed) [6.1.0-1]
-queuebot:#ubuntu-release- New: accepted libpqxx [s390x] (cosmic-proposed) [6.1.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-disposaboy-jsonconfigreader [amd64] (cosmic-proposed) [0.0~git20171218.5ea4d0d-1]
-queuebot:#ubuntu-release- New: accepted golang-github-syncthing-notify [amd64] (cosmic-proposed) [0.0~git20180626.cdf89c4-2]
-queuebot:#ubuntu-release- New: accepted libpqxx [ppc64el] (cosmic-proposed) [6.1.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-mitchellh-go-testing-interface [amd64] (cosmic-proposed) [0.0~git20171004.a61a995-1]
-queuebot:#ubuntu-release- New: accepted libprotocol-irc-perl [amd64] (cosmic-proposed) [0.12-2]
-queuebot:#ubuntu-release- New: accepted libpqxx [amd64] (cosmic-proposed) [6.1.0-1]
-queuebot:#ubuntu-release- New: accepted libsass [amd64] (cosmic-proposed) [3.5.4-1]
-queuebot:#ubuntu-release- New: accepted libsass [armhf] (cosmic-proposed) [3.5.4-1]
-queuebot:#ubuntu-release- New: accepted libsass [ppc64el] (cosmic-proposed) [3.5.4-1]
-queuebot:#ubuntu-release- New: accepted libtangence-perl [amd64] (cosmic-proposed) [0.24-2]
-queuebot:#ubuntu-release- New: accepted pike8.0 [amd64] (cosmic-proposed) [8.0.610-1]
-queuebot:#ubuntu-release- New: accepted pike8.0 [armhf] (cosmic-proposed) [8.0.610-1]
-queuebot:#ubuntu-release- New: accepted pike8.0 [ppc64el] (cosmic-proposed) [8.0.610-1]
-queuebot:#ubuntu-release- New: accepted ros-ros-comm-msgs [amd64] (cosmic-proposed) [1.11.2-9]
-queuebot:#ubuntu-release- New: accepted libsass [arm64] (cosmic-proposed) [3.5.4-1]
-queuebot:#ubuntu-release- New: accepted libsass [s390x] (cosmic-proposed) [3.5.4-1]
-queuebot:#ubuntu-release- New: accepted pike8.0 [arm64] (cosmic-proposed) [8.0.610-1]
-queuebot:#ubuntu-release- New: accepted pike8.0 [s390x] (cosmic-proposed) [8.0.610-1]
-queuebot:#ubuntu-release- New: accepted libsass [i386] (cosmic-proposed) [3.5.4-1]
-queuebot:#ubuntu-release- New: accepted pike8.0 [i386] (cosmic-proposed) [8.0.610-1]
-queuebot:#ubuntu-release- New: accepted libtest-http-localserver-perl [amd64] (cosmic-proposed) [0.63-1]
-queuebot:#ubuntu-release- New: accepted vkd3d [amd64] (cosmic-proposed) [1.0-4]
-queuebot:#ubuntu-release- New: accepted vkd3d [armhf] (cosmic-proposed) [1.0-4]
-queuebot:#ubuntu-release- New: accepted vkd3d [ppc64el] (cosmic-proposed) [1.0-4]
-queuebot:#ubuntu-release- New: accepted vkd3d [arm64] (cosmic-proposed) [1.0-4]
-queuebot:#ubuntu-release- New: accepted vkd3d [s390x] (cosmic-proposed) [1.0-4]
-queuebot:#ubuntu-release- New: accepted vkd3d [i386] (cosmic-proposed) [1.0-4]
-queuebot:#ubuntu-release- New binary: bottleneck [arm64] (cosmic-proposed/universe) [1.2.1+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted bottleneck [amd64] (cosmic-proposed) [1.2.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted bottleneck [armhf] (cosmic-proposed) [1.2.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted bottleneck [ppc64el] (cosmic-proposed) [1.2.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted bottleneck [arm64] (cosmic-proposed) [1.2.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted bottleneck [s390x] (cosmic-proposed) [1.2.1+ds1-1]
-queuebot:#ubuntu-release- New: accepted bottleneck [i386] (cosmic-proposed) [1.2.1+ds1-1]
-queuebot:#ubuntu-release- New binary: golang-github-smira-commander [amd64] (cosmic-proposed/universe) [0.0~git20140515.f408b00-1] (no packageset)
<tsimonq2> slangasek: Can I please get ANAIS cleanup on seafile-client? It now deps on qtwebengine which is !ppc64el and !s390x.
<slangasek> tsimonq2: seafile-client done
<tsimonq2> slangasek: Thanks.
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.33 => 2.408.35] (desktop-core)
#ubuntu-release 2018-07-03
-queuebot:#ubuntu-release- New: accepted pmdk [source] (cosmic-proposed) [1.4-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted packagekit [source] (bionic-proposed) [1.1.9-1ubuntu2.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.33.1+18.04ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (artful-proposed) [2.33.1+17.10ubuntu1]
-queuebot:#ubuntu-release- New binary: pmdk [amd64] (cosmic-proposed/universe) [1.4-0ubuntu1] (no packageset)
<tsimonq2> Harumph.
<tsimonq2> https://launchpadlibrarian.net/376840028/buildlog_ubuntu_cosmic_amd64_lubuntu_BUILDING.txt.gz
<tsimonq2> xnox: Your rsyslog update likely broke this.
<tsimonq2> er
<tsimonq2> I can't read dates, apparently.
<tsimonq2> Nevermind, although your help in figuring this out would be appreciated.
<flocculant> appears to be affecting Xubuntu as well
<tsimonq2> It should, theoretically, affect all images 20180702 and on.
<flocculant> yea
<flocculant> mate failed an hour ago
<tsimonq2> Theoretically, Cosmic debootstraps should also fail.
<tsimonq2> Trying to repro now.
<tsimonq2> Oh, that worked.
<slangasek> tsimonq2, flocculant: I poked at it all afternoon and haven't managed yet to reproduce it locally.  A debootstrap doesn't fail in a normal environment, including using a fully up-to-date cosmic to debootstrap cosmic.
<slangasek> maybe it's reproducible specifically in the container environment used in launchpad; I am lacking documentation on how to reproduce that environment locally
<slangasek> cjwatson: ^^ I missed your presentation at the sprint, so I don't know how to reproduce the current failures affecting all cosmic livefs builds
<flocculant> slangasek: thanks for the info :)
<tsimonq2> slangasek: Thanks
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.33.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-report [source] (bionic-proposed) [1.2.0~bionic]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu10.2]
<LocutusOfBorg> can we please blacklist this test? http://autopkgtest.ubuntu.com/packages/p/pinentry/cosmic/i386
<LocutusOfBorg> it passed once, I don't know why, but it is obviously flaky
-queuebot:#ubuntu-release- Unapproved: gnome-twitch (bionic-proposed/universe) [0.4.1-2 => 0.4.1-3~bionic1] (no packageset)
<xnox> tsimonq2, it was failing for a while (debootstrap, under live build)
<xnox> tsimonq2, i've seen that before, but never managed to reproduce, or figure out what's wrong with rsyslog =/
<xnox> tsimonq2, i can upload a better bootstrapable rsyslog anyway, just in case.
<LocutusOfBorg> [10:50:05] -queuebot/#ubuntu-release- Unapproved: gnome-twitch (bionic-proposed/universe) [0.4.1-2 => 0.4.1-3~bionic1] (no packageset)
<LocutusOfBorg> who is doing this stuff?
<LocutusOfBorg> seb128, ^^ isn't such versioning wrong?
<LocutusOfBorg> why did we stop using release numbers (that are guaranteed to be incremental)?
<LocutusOfBorg> tsimonq2, ^^ this was also your question :)
<cjwatson> slangasek,tsimonq2,xnox: I've reproduced it locally
<cjwatson> https://paste.ubuntu.com/p/DdsyhR4DvD/
<xnox> cjwatson, thanks.
<xnox> it is coming from systemd-tmpfiles.
<cjwatson> I was just about to say
<cjwatson> I have the debootstrap wreckage here if you want me to investigate anything
<xnox> cjwatson, well, does /var/spool/rsyslog exist =) and would running the upgraded postinst, closer to the old one work? this one:
<xnox> cjwatson, http://paste.ubuntu.com/p/TnGw7QxdwF/
<cjwatson> Both of the directories it's complaining about exist.  I suspect that the ENOENT is on /proc/self/fd/5, not those directories
<xnox> ack, so the fix i uploaded now, should "work".
<xnox> because proc is not mounted?!
<xnox> reading tmpfiles.c in systemd it is.... odd....
<xnox> open an fd with fancy flags; and then chmod not the path we ask... but /proc/self/fd/$fd .... why it does it that way, i don't know.
<cjwatson> I think /proc must indeed be unmounted, but why
<cjwatson> debootstrap bug maybe?
<cjwatson> debootstrap changed 22 hours ago in cosmic
<cjwatson> I don't really feel that working around a debootstrap bug in rsyslog is likely to be correct
<xnox> cjwatson, i've seen this sort of failure, on and off, ever since trying to migrate the new debootstrap in cosmic.
<cjwatson> p.s. "paper over" not "pepper over" :)
<xnox> e.g. livecd-rootfs autopkgtest, triggered by new debootstrap, was showing above symptoms (failing to configure rsyslog a few times in a row, until fail)
<cjwatson> hmm, there's stuff in the diff about lxc detection
<xnox> cjwatson, =)))) oh really, world changed here. I thought everybody loves italian ground pepper =)
<cjwatson> debootstrap 1.0.105 just doesn't mount /proc and /sys if it's running inside lxc, wtf
<cjwatson> so you should be able to reproduce this simply by running debootstrap on cosmic inside a lxd container
<xnox> fun
 * cjwatson tries to work out what henrich@ was thinking
<cjwatson> maybe something about unprivileged containers
<xnox> well, in schroot = apt install rsyslog systemd; umount /proc; dpkg-reconfigure rsyslog => does the fail too. Imho it is valid for rsyslog to be configurable without /proc mounted.
<cjwatson> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731802
<ubot5> Debian bug 731802 in debootstrap "debootstrap: Doesn't work in LXC containers" [Normal,Fixed]
<cjwatson> let's see if I can reproduce it with a plain unstable container and debootstrapping sid, 'cause then I can file it as a Debian bug and make it henrich@'s problem :P
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.17.0-4.5] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.17.0-4.5] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.17.0-4.5]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.17.0-4.5]
 * Ukikie looks at https://salsa.debian.org/installer-team/debootstrap/merge_requests/13
<gitlab-bot> Debian Installer issue (Merge request) 13 in debootstrap "Use $container to detect systemd-nspawn and lxc-libvirt (Closes: #902350)" (comments: 5) [Merged]
<cjwatson> it's in that general area, yes
<seb128> LocutusOfBorg, no, the version is not wrong, the only requirement afaik is that "bionic_version < bionic_sru_version <= cosmic_version"
<seb128> LocutusOfBorg, you can argue that ~artful < ~zesty and such codenames are not the best
<seb128> LocutusOfBorg, but for that bionic specific SRU I don't think there is any issue, out of trying to be pedentic
<LocutusOfBorg> seb128, I'm not arguing this works in this case, but better not "advertise" such choices, because they won't work with LTS (e.g. trusty, xenial)
<LocutusOfBorg> so, better avoid them and use the general versioning that always works :)
<seb128> LocutusOfBorg, you use the versions you want, it's your choice :)
<LocutusOfBorg> sure :)
-queuebot:#ubuntu-release- Unapproved: unity-settings-daemon (bionic-proposed/universe) [15.04.1+18.04.20180413-0ubuntu1 => 15.04.1+18.04.20180413-0ubuntu1.1] (mythbuntu)
<seb128> LocutusOfBorg, if you think a consistent versioning should be enforced for SRU I'm not against it, but the correct people to talk about that is the SRU team to get them to agree and update the SRU guidelines
<rbasak> Personally I'd prefer to always be followed except when an exception is really required. For consistency.
<rbasak> Uh, https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging to always be followed
<rbasak> Consistency = easier onboarding for new developers
<rbasak> Not sure if this case is exactly on that page, but for the same principle of consistency, I much prefer using release numbers instead of codenames because release names always work and are therefore more consistent.
<seb128> wfm and makes sense, but ideally it should be documented as the preferred option on the SRU documentation
<seb128> otherwise you can't expect people to follow it
<rbasak> My plan is to push on this more once "git ubuntu lint" reaches 1.0, since then people will have tooling to help them follow it.
<rbasak> because release _numbers_ always work
<rbasak> Yeah - right now I'm not particularly enforcing anything. I reluctantly accept version strings I'm not particularly happy with but that have been acceptable historically.
<seb128> well, it would hurt to hint on the recommend/preferred versioning on the wiki
<seb128> you would probably have more uploads in line with what you prefer
<rbasak> I agree, but it's effort to drive consensus within the SRU team on that before I can edit the page.
<seb128> I pick randomnly because we don't have a documented preferred way but I would follow it if we had one
<rbasak> I want to expend that effort, but I was deferring it to do it when I can recommend a lint tool to go along with it.
<rbasak> The SRU page does recommend https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging, no?
<seb128> rbasak, that's SecurityTeam
<rbasak> It's linked from the SRU procedure.
<rbasak> IMHO, that's a recommendation
<seb128> "which can be used for SRUs." doesn't really hint it's one
<seb128> or maybe it's just my english not being good
<seb128> to me it sounds more like a "btw, that's one option which some people are using"
<seb128> not "that's the one we would prefer you to use"
<rbasak> Hmm, OK.
<rbasak> Perhaps asking the SRU team to make it more obviously and formally a recommendation would be easier to drive.
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (bionic-proposed) [2.02-2ubuntu8.1]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (bionic-proposed) [2.02-2ubuntu8.1]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-25.27~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-25.27~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-25.27~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-25.27~16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-25.27] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-25.27] (core, kernel)
<Trevinho> sru team, could you please check the SRU queue for nux + xorg packages please? :)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-25.27]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-25.27]
-queuebot:#ubuntu-release- Unapproved: keepalived (bionic-proposed/main) [1:1.3.9-1build1 => 1:1.3.9-1ubuntu0.18.04.1] (ubuntu-server)
<slangasek> xnox: "livecd-rootfs autopkgtest triggered by new debootstrap was showing above symptoms" so the new debootstrap was fixed enough to make the autopkgtests pass, but nothing else? cute.
<Laney> I thought the livecd-rootfs tests were all isolation-machine?
<cjwatson> I just filed the debootstrap bug upstream - will give you the bug number once I have it
<cjwatson> Laney: that wouldn't be LXD, right?
<Laney> No but maybe they set up a container or something on their own
<Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/amd64/l/livecd-rootfs/20180623_123249_4c7a4@/log.gz xnox is probably referring to e.g. this one
<cjwatson> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902924
<ubot5> Debian bug 902924 in debootstrap "debootstrap: doesn't mount /proc when building chroot inside LXD container" [Important,Open]
<cjwatson> I'll leave any mitigation up to other people - that's hopefully enough analysis to be going on with
<Laney> 1.104 was enough to fix the tests anyway
<slangasek> infinity: where are you at with LP: #1766513?
<ubot5> Launchpad bug 1766513 in ubuntu-dev-tools (Ubuntu Artful) "RM: pkg-create-dbgsym: obsolete, debhelper conflicts" [High,Triaged] https://launchpad.net/bugs/1766513
<xnox> slangasek, basically systemd-tmpfiles is stupid, and fails without /proc mounted.
<xnox> slangasek, is alternative explanation =)
<slangasek> right, well, /proc should not be un-mounted
<sil2100> infinity: hey! The bionic images seem to fail to build due to the initrd being busted - could you get the same fixes that you did for cosmic into bionic as well?
 * sil2100 has bad luck and everytime he needs a new image for testing it just fails to build
<acheronuk> sil2100: is the live-build in the bionic unapproved queue not said fix?
<sil2100> acheronuk: good catch o/
<sil2100> I guess I'll review that
<acheronuk> :)
<sil2100> infinity: ^
-queuebot:#ubuntu-release- Unapproved: nova (bionic-proposed/main) [2:17.0.5-0ubuntu1 => 2:17.0.5-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted live-build [source] (bionic-proposed) [3.0~a57-1ubuntu34.1]
<sil2100> infinity: approved if anything
<sil2100> o/
-queuebot:#ubuntu-release- Unapproved: nplan (xenial-proposed/universe) [0.32~16.04.5 => 0.32~16.04.6] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-backports/main) [3.0.1-0ubuntu1~16.04.1 => 3.0.1-0ubuntu1~16.04.2] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- New binary: cakephp [amd64] (cosmic-proposed/universe) [2.10.11-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-backports) [3.0.1-0ubuntu1~16.04.2]
-queuebot:#ubuntu-release- Unapproved: nova (xenial-proposed/main) [2:13.1.4-0ubuntu4.2 => 2:13.1.4-0ubuntu4.3] (openstack, ubuntu-server)
<m0x90> Hello, I noticed that the amd64 package linux-image-4.15.0-24-generic-dbgsym is not in http://ddebs.ubuntu.com/pool/main/l/linux-hwe/. Instead only an unsigned one is present.
<sarnold> thishttp://ddebs.ubuntu.com/pool/main/l/linux-hwe/linux-image-4.15.0-24-generic-dbgsym_4.15.0-24.26~16.04.1_arm64.ddeb ?
<m0x90> sarnold: that's arm64, not amd64
 * sarnold fails
<m0x90> :)
<sarnold> well... buy a cavium? :D
<sarnold> (hahaha yeah, right, like they'd make it easy to buy one ..)
<infinity> m0x90: http://ddebs.ubuntu.com/pool/main/l/linux-signed-hwe/
<sarnold> 2.8KB? seems kinda smallish for debug symbols
<infinity> sarnold: It almost certainly just depends on the -unsigned one. :P
<infinity> Since signed/unsigned are the same binary, modulo attached signature.
<sarnold> aha :) thanks infinity :)
-queuebot:#ubuntu-release- Unapproved: installation-guide (bionic-proposed/main) [20160121ubuntu4 => 20160121ubuntu4.1] (core)
-queuebot:#ubuntu-release- Unapproved: rejected nplan [source] (xenial-proposed) [0.32~16.04.6]
<m0x90> infinity: thanks! do you know why it would be released unsigned just for amd64? trying to understand the rational so I can break some install scripts consistently :)
<infinity> m0x90: All the kernels built from the linux (or, in this case, linux-hwe) source are unsigned.  They're only labelled "unsigned" if there's also a "signed" version produced from linux-signed.
<infinity> Although, I thought we changed that entirely...
<infinity> Now that I think about it.
<infinity> Ahh, yeah, the placement of those files on ddebs is just a server side archive bug. :P
<infinity> I think.
<infinity> m0x90: Really, relying on file paths is your bug, though.
<infinity> m0x90: There's a reason this stuff is accessible via apt.
<infinity> m0x90: File paths shouldn't be a thing you assume.
<infinity> m0x90: Also, if you're hardcoding paths, I assume you're also doing something evil with wget/curl, which means you're not verifying signatures and could be MITMed.
<infinity> m0x90: Always better to fetch your packages via apt.
<m0x90> infinity: fair, just wanted to understand the difference between archs
-queuebot:#ubuntu-release- New binary: libnumbertext [s390x] (cosmic-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libnumbertext [ppc64el] (cosmic-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: zoneminder [s390x] (cosmic-proposed/universe) [1.30.4+dfsg1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: zoneminder [ppc64el] (cosmic-proposed/universe) [1.30.4+dfsg1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libnumbertext [i386] (cosmic-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libnumbertext [amd64] (cosmic-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libnumbertext [arm64] (cosmic-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: zoneminder [arm64] (cosmic-proposed/universe) [1.30.4+dfsg1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: zoneminder [armhf] (cosmic-proposed/universe) [1.30.4+dfsg1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libnumbertext [armhf] (cosmic-proposed/universe) [1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: zoneminder [i386] (cosmic-proposed/universe) [1.30.4+dfsg1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: zoneminder [amd64] (cosmic-proposed/universe) [1.30.4+dfsg1-4] (no packageset)
#ubuntu-release 2018-07-04
-queuebot:#ubuntu-release- New: accepted zoneminder [amd64] (cosmic-proposed) [1.30.4+dfsg1-4]
-queuebot:#ubuntu-release- New: accepted zoneminder [armhf] (cosmic-proposed) [1.30.4+dfsg1-4]
-queuebot:#ubuntu-release- New: accepted zoneminder [ppc64el] (cosmic-proposed) [1.30.4+dfsg1-4]
-queuebot:#ubuntu-release- New: accepted zoneminder [arm64] (cosmic-proposed) [1.30.4+dfsg1-4]
-queuebot:#ubuntu-release- New: accepted zoneminder [s390x] (cosmic-proposed) [1.30.4+dfsg1-4]
-queuebot:#ubuntu-release- New: accepted zoneminder [i386] (cosmic-proposed) [1.30.4+dfsg1-4]
-queuebot:#ubuntu-release- New: accepted libnumbertext [amd64] (cosmic-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted libnumbertext [armhf] (cosmic-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted libnumbertext [ppc64el] (cosmic-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted libnumbertext [arm64] (cosmic-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted libnumbertext [s390x] (cosmic-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted libnumbertext [i386] (cosmic-proposed) [1.0-2]
-queuebot:#ubuntu-release- New: accepted cakephp [amd64] (cosmic-proposed) [2.10.11-1]
-queuebot:#ubuntu-release- New: accepted pmdk [amd64] (cosmic-proposed) [1.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-github-smira-commander [amd64] (cosmic-proposed) [0.0~git20140515.f408b00-1]
-queuebot:#ubuntu-release- Unapproved: accepted live-build [source] (xenial-proposed) [3.0~a57-1ubuntu25.6]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.15.0-1015.15] (kernel)
-queuebot:#ubuntu-release- Unapproved: bluez (bionic-proposed/main) [5.48-0ubuntu3 => 5.48-0ubuntu3.1] (ubuntu-desktop)
<LocutusOfBorg> any AA around please?
<LocutusOfBorg> kick forge out from the world! RC buggy in Debian, delaying cmake migration, can't build, testsuite broken and so on
-queuebot:#ubuntu-release- New binary: pulseaudio [s390x] (cosmic-proposed/main) [1:12.0-1ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: pulseaudio [amd64] (cosmic-proposed/main) [1:12.0-1ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: pulseaudio [ppc64el] (cosmic-proposed/main) [1:12.0-1ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: pulseaudio [i386] (cosmic-proposed/main) [1:12.0-1ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: pulseaudio [arm64] (cosmic-proposed/main) [1:12.0-1ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: pulseaudio [armhf] (cosmic-proposed/main) [1:12.0-1ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: unity-settings-daemon (xenial-proposed/main) [15.04.1+16.04.20160701-0ubuntu1 => 15.04.1+16.04.20160701-0ubuntu2] (ubuntu-desktop)
<infinity> LocutusOfBorg: The autopkgtests only regress with cmake.  That looks suspicious to me.
<infinity> LocutusOfBorg: (Yes, I agree it's RC buggy due to the FTBFS, but that's not the autopkgtest issue)
<infinity> LocutusOfBorg: http://autopkgtest.ubuntu.com/packages/f/forge/cosmic/amd64
<infinity> LocutusOfBorg: Oh, I see.  It's cmake causing new failures by spewing warnings to stderr. :P
<LocutusOfBorg> yes, the syntax for searching for opengl has changed
<LocutusOfBorg> :)
<LocutusOfBorg> and I also fixed the same for glbinding and glfoodon'tremember
<infinity> LocutusOfBorg: "My package has changed, so all rdeps that haven't changed should be removed instead of fixed" is not really how we do things.
<LocutusOfBorg> "My package has changed, so all rdeps that haven't changed should be removed if they are already RC buggy, can't be easily and fixed"
<LocutusOfBorg> :)
<infinity> LocutusOfBorg: As in, this regression was cause by cmake, not by forge.
<infinity> s/cause/caused/
<LocutusOfBorg> I fixed 2/3 packages (by allowing stderr btw)
<infinity> Allowing stderr doesn't seem to be the right fix.
<LocutusOfBorg> infinity, trust me, the "fix" should really come from upstream
<infinity> ...?
<LocutusOfBorg> I tried hard but failed, that keyword is used mostly everywhere, and I presume once new cmake deprecates it, upstream will be forced to fix
<ginggs> "A new upstream version is available: 1.0.2-ft, you should consider packaging it."
<infinity> Yeah, upstram might have a fix to cherrypick.
<LocutusOfBorg> infinity, that CMP0037 is really difficult to "fix"
<LocutusOfBorg> it requires a refactoring of the cmake system for glbindings and glother
<LocutusOfBorg> last time I checked forge there was nothing easily pickable
<infinity> But even if they don't, I'm also not keen on cmake spamming stderr.
<infinity> Or, arguably, the package fix should have been to add -Wno-dev to the cmake calls.
<infinity> Instead of suppressing stderr entirely.
<LocutusOfBorg> oh.... something new to learn for the future
<LocutusOfBorg> thanks!
<infinity> It was right there in the log?
<infinity> "This warning is for project developers.  Use -Wno-dev to suppress it.
<infinity> "
<infinity> Anyhow, I sycned the experimental version, which of course still has the FTBFS, and removed the release pocket version, so you're free and clear for now.
<infinity> The above was just me being whiney that this isn't really the best way to "fix" things.
<infinity> (It was a leaf package, so whatever, being a bit handwavy right now)
<infinity> Fixing the FTBFS, mind you, looks trivial.
<infinity> In fact, upstream fixed it by not including the whiney header. :P
<infinity> https://github.com/arrayfire/forge/commit/63e4a2037e42c00554a26de2355d962f91a9ab20
<infinity> https://github.com/arrayfire/forge/commit/befa265294fd9ff679dece7874c1de50fea97b25
<LocutusOfBorg> lets do an unstable upload of the experimental version
<LocutusOfBorg> ghislain is somewhat MIA in Debian, I'm really tired of fixing up his stuff
<LocutusOfBorg> I'm more inclined to remove stuff that nobody is caring anymore
<ginggs> LocutusOfBorg: https://debconf17.debconf.org/talks/10/
<ginggs> spoiler alert: it's a dustbin
-queuebot:#ubuntu-release- New binary: forge [ppc64el] (cosmic-proposed/universe) [1.0.1-2~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: forge [s390x] (cosmic-proposed/universe) [1.0.1-2~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: forge [i386] (cosmic-proposed/universe) [1.0.1-2~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: forge [arm64] (cosmic-proposed/universe) [1.0.1-2~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: forge [armhf] (cosmic-proposed/universe) [1.0.1-2~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: forge [amd64] (cosmic-proposed/universe) [1.0.1-2~build1] (no packageset)
<LocutusOfBorg> loooooooool
<LocutusOfBorg> please accept forge? :)
<LocutusOfBorg> the autosyncd package is already coming in
-queuebot:#ubuntu-release- New: accepted forge [amd64] (cosmic-proposed) [1.0.1-2~build1]
-queuebot:#ubuntu-release- New: accepted forge [armhf] (cosmic-proposed) [1.0.1-2~build1]
-queuebot:#ubuntu-release- New: accepted forge [ppc64el] (cosmic-proposed) [1.0.1-2~build1]
-queuebot:#ubuntu-release- New: accepted forge [arm64] (cosmic-proposed) [1.0.1-2~build1]
-queuebot:#ubuntu-release- New: accepted forge [s390x] (cosmic-proposed) [1.0.1-2~build1]
-queuebot:#ubuntu-release- New: accepted forge [i386] (cosmic-proposed) [1.0.1-2~build1]
-queuebot:#ubuntu-release- New: accepted pulseaudio [amd64] (cosmic-proposed) [1:12.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted pulseaudio [armhf] (cosmic-proposed) [1:12.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted pulseaudio [ppc64el] (cosmic-proposed) [1:12.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted pulseaudio [arm64] (cosmic-proposed) [1:12.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted pulseaudio [s390x] (cosmic-proposed) [1:12.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted pulseaudio [i386] (cosmic-proposed) [1:12.0-1ubuntu1]
<LocutusOfBorg> people, openmpi is getting closer to migrate, with the ~10 transitions...
<LocutusOfBorg> maybe we can disable autosync for a day or two?
<LocutusOfBorg> disabling autosync, and some work will make a lot of stuff go in testing, e.g. blender/boost/perl/magics++/vtk*/openmpi/gdal/hhvm/jelloc and lots more
 * Laney fixes python-pyproj
<LocutusOfBorg> ./vorlon:# requires its own version of mariadb-test, that binary package now owned by mariadb-10.2.
<LocutusOfBorg> ./vorlon:force-badtest mariadb-10.1/1:10.1.29-6
<LocutusOfBorg> slangasek, ^^ please update to 29-6build2?
<LocutusOfBorg> cjwatson, please disable autosync? :)
<cjwatson> not me today sorry
<LocutusOfBorg> ok, if somebody can help ^^ :)
 * LocutusOfBorg tries hard on qgis
-queuebot:#ubuntu-release- Unapproved: gvfs (bionic-proposed/main) [1.36.1-0ubuntu1 => 1.36.1-0ubuntu1.1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.1 => 2.525.2] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.33 => 2.408.36] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (xenial-proposed) [2.408.35]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.2]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (bionic-proposed) [1:18.04.11.3]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.36]
<Laney> juliank: sil2100: Either of you fancy investigating the 'in progress' arm64 tests for mariadb-10.1?
<Laney> The machines hang in the postinst for mariadb-server-10.1 and then time out
<Laney> but that doesn't happen if you boot one and manually install it
<Laney> even with the pinning copied out of an autopkgtest VM
<sil2100> Laney: yeah, I guess it's about time for some ADT work from our side - for a reminder could you create a card on the autopkgtest board and assign it to both of us? One of us will pick it up this week
<Laney> ok if that will actually remind you, sure
<Laney> it's blocking mariadb from being a candidate which affects in progress transitions
<Laney> done ð
<sil2100> Thanks, I'll look into that tomorrow since today I'm already full
<Laney> sure
<Laney> it's probably not the only blocker for that transition
-queuebot:#ubuntu-release- Unapproved: accepted bluez [source] (bionic-proposed) [5.48-0ubuntu3.1]
-queuebot:#ubuntu-release- New binary: gnucash [amd64] (cosmic-proposed/universe) [1:3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnucash [ppc64el] (cosmic-proposed/universe) [1:3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnucash [i386] (cosmic-proposed/universe) [1:3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnucash [arm64] (cosmic-proposed/universe) [1:3.2-1] (no packageset)
<slangasek> LocutusOfBorg: yes, disabling autosync
<ginggs> slangasek: thanks!
<slangasek> LocutusOfBorg: why do we need to hint mariadb-10.1 still?  why hasn't it been superseded by mariadb-10.2 in cosmic, or else the mariadb-test takeover reverted?
<LocutusOfBorg> slangasek, sorry I don't know, but it should be still needed
<LocutusOfBorg> because tests are against mariadb10-2 and so 10.1 fails
<LocutusOfBorg> we don't have two test packages, one for 10.1 and one different for 10.2, so the old one should be "uninstallable" right now
<LocutusOfBorg> but I'm not the maintainer, so please ask him in case, because I have mostly zero knowledge on the topic
<slangasek> LocutusOfBorg: I'm inclined to suggest mariadb-10.1 should be removed from cosmic rather than being perpetually untestable.  Meanwhile, I'll bump the hint.
<LocutusOfBorg> lovely thanks! I'll let mariadb maintainers answer on the topic (and yes, remove it from my point of view should be the right thing=
<LocutusOfBorg> damn, I did a qgis build in pbuilder and it was good
<LocutusOfBorg> and sbuild in launchpad fails... I was mostly sure it was because of parallel builds...
<ginggs> slangasek: I noticed armci-mpi says missing build on armhf, not valid candidate - could you remove the armhf binaries from release please?
<tsimonq2> slangasek: Could you please remove qtgamepad-opensource-src from cosmic-proposed? It was meant to go to Experimental ( https://tracker.debian.org/news/968815/accepted-qtgamepad-everywhere-src-5111-2-source-into-experimental/ ) and it would be much better if it went with the Qt transition so it could be built against the properly-versioned libraries.
<tsimonq2> ( https://bileto.ubuntu.com/#/ticket/3291 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902263 for ref)
<ubot5> Debian bug 902263 in release.debian.org "transition: qtbase-opensource-src" [Normal,Open]
#ubuntu-release 2018-07-05
<tsimonq2> xnox: What's up with that debootstrap / rsyslog bug?
<tsimonq2> I'd like to test some changes I made with the Lubuntu Cosmic daily that only show up on a new ISO build... I'm willing to contribute some time to help with the fix if that's what we're waiting on :)
<tsimonq2> Laney: I believe I worked with you on this: https://code.launchpad.net/~tsimonq2/autopkgtest-cloud/+git/bug-1654761/+merge/348972
<tsimonq2> As I mention in there, the specifics we discussed aren't really fresh in my mind anymore, unfortunately, but I'm cleaning up my assigned bugs and I want to drive it to completion.
<tsimonq2> (as mentioned, this is bug 1654761)
<ubot5> bug 1654761 in Auto Package Testing "Make sure duplicate tests cannot be queued" [Undecided,In progress] https://launchpad.net/bugs/1654761
<slangasek> tsimonq2: what's the problem with leaving qtgamepad-everywhere-src where it is, given that it's dep-wait?
<tsimonq2> slangasek: It's a bit cleaner; I don't have a compelling reason for why it needs to go *now*.
<slangasek> tsimonq2: I don't see why it would need to go at all, vs. just building at a later date when its build-deps are satisfiable
<tsimonq2> slangasek: Either way, it'll be superseded. You make a good point; it won't hurt.
<slangasek> also, looks like xnox worked around the debootstrap failure in rsyslog, and now things fail differently
<tsimonq2> Oh?
<slangasek> today's image build logs seem to fail later, post-bootstrap
<tsimonq2> terminate called after throwing an instance of 'std::runtime_error'
<tsimonq2>   what():  random_device::random_device(const std::string&)
<tsimonq2> Aborted (core dumped)
<tsimonq2> ah
 * tsimonq2 tries to repro locally
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.33.1ubuntu1 => 2.33.1ubuntu2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: budgie-extras (bionic-proposed/universe) [0.4.4-0ubuntu1 => 0.4.4-0ubuntu1.1] (personal-fossfreedom, ubuntu-budgie)
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.33.1+18.04ubuntu1 => 2.33.1+18.04ubuntu2] (desktop-core, ubuntu-server)
<tsimonq2> infinity, slangasek: Speaking of cleaning up stuff, could I please get some more eyes on this, and get it merged if it looks good? https://code.launchpad.net/~tsimonq2/debian-cd/lubuntu-cosmic-changes/+merge/345792
<tsimonq2> From the discussion we had on May 22nd, we're going to go with having a "Start Lubuntu" option with a single desktop icon first, and down the road I'll look at implementing "maybe-ubiquity"-like features (with the rename from ubiquity to generic names like planned).
<tsimonq2> calamares-settings-ubuntu 3 should add the desktop icon.
<infinity> tsimonq2: You got NOTRYONLYDO backwards.  And I think there were two if blocks that could be replaced by it (which was why I argued for it)?
<infinity> tsimonq2: I mean, maybe the intend of the Yodaism wasn't clear, but it was for images that have 1 install option, instead of both an install and a try (hence "no try") :P
<tsimonq2> infinity: Looking.
<tsimonq2> infinity: So you're saying, throw NOTRYONLYDO in kubuntu*, lubuntu, and ubuntu-server and keep the change to "if [ "$NOTRYONLYDO" = "true" ]; then" as-is?
<infinity> tsimonq2: Set it true for the special cases, and test for != true.
<infinity> tsimonq2: I might be wrong about the second if statement, can't find it in a quick scan.
<tsimonq2> infinity: Isn't the end result of what I have the same?
<infinity> tsimonq2: The end result is the same, but the variable name makes no sense the way you have it.
<tsimonq2> infinity: Ah, gotcha. I'll fix, sec.
<infinity> tsimonq2: Also the more stylistic nit-pick that setting variables explicitly for special cases is better than implicitly in the catch-all (IMO).
<infinity> But mostly, just the inverted meaning is confusing.
<infinity> The people who crusade against LOC would disagree with me on the style thing, but I prefer self-documenting code to "elegance" via removing two lines.
<tsimonq2> infinity: Better?
<tsimonq2> (I personally prefer the style of, "Oh, these three are special. If it isn't special, set the env var in the catch-all.")
<infinity> tsimonq2: I suppose it also depends on what the var gets used for, what the default actually is, etc.
<tsimonq2> Right.
<infinity> But I think this is clearer that it's "weird" to have a single-option boot menu, and you should ask for it.
<infinity> Whereas the way you had it, any newly-added case would be single-option by default unless they dug up the magic var.
<tsimonq2> Ah, true.
<infinity> (Also fixable by setting it outside the case block, then re-setting it inside)
<infinity> But that's overkill here.
<infinity> This looks better indeed.
<tsimonq2> Great.
<tsimonq2> infinity: I don't mean to nag, but did you plan on merging it? :P
<Laney> tsimonq2: thx
<tsimonq2> Laney: Thank *you*. :)
<Laney> I'm on the way to guadec but I'll see if I can
<tsimonq2> Great, let me know.
<tsimonq2> (I hear AlmerÃ­a is great; Akademy was there one of those past years but I didn't get to go. :( )
<valorie> great, historic, HOT
<valorie> also the journey there and back is.... indirect
<valorie> I think if I went again I would drive from Barcelona down the coast
<tsimonq2> valorie: If I recall correctly, Laney is in $somewhere_in_Europe so it might be easier for him.
<valorie> can't think of anywhere else in Europe I'd want to drive
<tsimonq2> (Please don't hurt me, I don't get involved in British politics about who or what is technically in Europe. <3)
<valorie> tsimonq2: nothing goes directly to Almeria
<tsimonq2> valorie: Ah.
<valorie> it's sort of in a corner or so
<infinity> tsimonq2: I'll merge it, just working on waking up. :P
<tsimonq2> infinity: Are you participating in GUADEC funness too? :P
<valorie> infinity: ðµ
<infinity> tsimonq2: I don't GUADEC, no.
<tsimonq2> valorie: I think it's sort of funny how GUADEC organizers decided to do the conf in the same location as Akademy last year. :P
<tsimonq2> infinity: Gotcha.
<tsimonq2> infinity: No problem.
<tsimonq2> (I'm about to go to bed myself.)
<valorie> oh, we trade good places to have confs all the time
<infinity> GUADEC and Akademy should have been combined as a freedektop.org conf long ago.  Might have encouraged more colab on common interfaces.
<valorie> the local teams are skilled and handle everybody
<tsimonq2> Hahahahahaha.
<valorie> infinity: oh, we tried and tried, believe me
<tsimonq2> XD
<valorie> my first big conf was Desktop Summit in Berlin
<infinity> valorie: Not implying people haven't tried, just that it should have worked. :P
<valorie> completely agree
<tsimonq2> valorie: Define "big conf".
<valorie> at least the phone people are all cooperating these days
<tsimonq2> Mhhhhh.
<tsimonq2> In one part of the stack.
<valorie> Akademy is..... sometimes bigger, sometimes smaller than LFNW
<tsimonq2> Gotcha.
<valorie> Desktop Summit was twice as big
<tsimonq2> To be fair, I only have LFNW and SELF as reference points. :P
<valorie> right, and it would be good to have GNOME and KDE cooperating lower in the stack more than we do
<tsimonq2> But something the size of LFNW but with people working in the same Linux project? Wow.
<valorie> believe me, I've talked to lots of GNOME devels about this, one to one
<tsimonq2> valorie: Well, there's systemd. :P
<tsimonq2> systemd is going to become so big one day it has its own permanent conference center...
<valorie> lennart is sort of his own show
<tsimonq2> "systemd-conferenced, now complete with half the booths being duct-taped to the ceiling."
<tsimonq2> Anyway, I should go to bed.
<tsimonq2> Nice chatting valorie and infinity.
<valorie> niters here too
<LocutusOfBorg> Laney, hello, am I right thinking you are trying to sort out mariadb-10.1 autopkgtests?
<LocutusOfBorg> I'm doing qgis, the last big transition blocker
<Laney> No
<Laney> I asked some others to look
<LocutusOfBorg> ok fine for me
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.33.1+18.04ubuntu2]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-26.28] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1016.16~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-26.28] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.33.1ubuntu2]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1016.16~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted installation-guide [source] (bionic-proposed) [20160121ubuntu4.1]
-queuebot:#ubuntu-release- Unapproved: accepted aodh [source] (bionic-proposed) [6.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted fpc [source] (bionic-proposed) [3.0.4+dfsg-18ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-twitch (bionic-proposed/universe) [0.4.1-2 => 0.4.1-2ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected gnome-twitch [source] (bionic-proposed) [0.4.1-3~bionic1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-twitch [source] (bionic-proposed) [0.4.1-2ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: hedgewars (bionic-proposed/universe) [0.9.24.1-dfsg-2 => 0.9.24.1-dfsg-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gnucash [amd64] (cosmic-proposed) [1:3.2-1]
-queuebot:#ubuntu-release- New: accepted gnucash [i386] (cosmic-proposed) [1:3.2-1]
-queuebot:#ubuntu-release- New: accepted gnucash [arm64] (cosmic-proposed) [1:3.2-1]
-queuebot:#ubuntu-release- New: accepted gnucash [ppc64el] (cosmic-proposed) [1:3.2-1]
<LocutusOfBorg> folks, qgis is a sad no-go because of sip4 doing segfault in code generation
<LocutusOfBorg> what is your opinion wrt kicking it out to proposed, while we debug the issue?
<LocutusOfBorg> also kicking mariadb-10.1 out to proposed might make the ~15 transitions land, and then leave time for autosync and fixes for the two above
<LocutusOfBorg> Segmentation fault
<doko> LocutusOfBorg: please ask cpaelzer about mariadb/mysql
<Laney> Don't duplicate, I've asked juliank and sil2100 to get some information first
<LocutusOfBorg> nice to try to debug a sip failure due to new python...
-queuebot:#ubuntu-release- Unapproved: accepted dm-writeboost [source] (xenial-proposed) [2.2.6-1~16.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted bcmwl [source] (xenial-proposed) [6.30.223.271+bdcom-0ubuntu1~1.3]
<rbasak> Laney, LocutusOfBorg: are you talking about jemalloc or something else?
<rbasak> I don't see jemalloc in http://people.canonical.com/~ubuntu-archive/transitions/
<ginggs> rbasak: nobody set up a tracker for it, but it is in transition https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#jemalloc
<sil2100> mwhudson: hey! The latest bionic subiquity server images are erroring out during installation having some touble with installing the kernel, looks like probably related to the kernel 'revert' that happened recently - could you take a look?
<rbasak> ginggs: thanks. I'm aware. I'm more wondering who's working on it to coordinate, as I have a volunteer to help.
<LocutusOfBorg> rbasak, I look at qgis, nothing else
<LocutusOfBorg> yes, we need help in mariadb-10.1 testsuite running forever
<LocutusOfBorg> together with qgis they are the last blockers
<rbasak> LocutusOfBorg: to make sure I understand, you mean the last blockers for the jemalloc transition?
<LocutusOfBorg> jmalloc and other 14 transitions
<tjaalton> infinity: ping re purging old xorg drivers, it doesn't make sense for me to update the transitionals pkg before it's clear what drivers remain :)
-queuebot:#ubuntu-release- Unapproved: gnome-disk-utility (bionic-proposed/main) [3.28.1-0ubuntu1 => 3.28.3-0ubuntu1~18.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted nplan [source] (xenial-proposed) [0.32~16.04.6]
-queuebot:#ubuntu-release- Unapproved: gnome-control-center (bionic-proposed/main) [1:3.28.1-0ubuntu1.18.04.2 => 1:3.28.2-0ubuntu0.18.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: kio-gdrive (bionic-proposed/universe) [1.2.2-0ubuntu1 => 1.2.4-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: evolution-data-server (bionic-proposed/main) [3.28.1-1ubuntu1 => 3.28.3-0ubuntu0.18.04.1] (ubuntu-desktop)
<acheronuk> seems update_excuses and anything else on people.canonical.com is currently down
<slangasek> indeed
<slangasek> seems to be a frontend problem, since the machines are up
<slangasek> acheronuk: fixed
<acheronuk> slangasek: yep. I was just on the sysadmin channel asking. and the content, quote "relies on another server being up that had an issue"
<LocutusOfBorg> can anybody please kick haskell-store out from release and see the magic happen again?
<LocutusOfBorg> it doesn't build, leaf package requires sourceful upload
<LocutusOfBorg> (you can keep it in proposed, I presume it will be fixed in some days, but it will require a new transition, so better keep this one land)
<LocutusOfBorg> there is no RC in debian, because they are slow in rebuilds and they didn't catch the failure yet
<LocutusOfBorg> (but I forwarded the issue on #-haskell debian channel)
 * LocutusOfBorg leaves
-queuebot:#ubuntu-release- New binary: qgis [s390x] (cosmic-proposed/universe) [2.18.21+dfsg-1ubuntu1] (no packageset)
<tsimonq2> infinity: About that MP... :P
-queuebot:#ubuntu-release- New binary: qgis [ppc64el] (cosmic-proposed/universe) [2.18.21+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [amd64] (cosmic-proposed/universe) [2.18.21+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [i386] (cosmic-proposed/universe) [2.18.21+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [arm64] (cosmic-proposed/universe) [2.18.21+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: squashfs-tools (bionic-proposed/main) [1:4.3-6 => 1:4.3-6ubuntu0.18.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: netplan.io (bionic-proposed/main) [0.36.2 => 0.36.3] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (trusty-proposed/main) [1.34.16 => 1.34.17] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: shim-signed (trusty-proposed/main) [1.32~14.04.2 => 1.33.1~14.04.1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: grub2 (trusty-proposed/main) [2.02~beta2-9ubuntu1.14 => 2.02~beta2-9ubuntu1.15] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: shim (trusty-proposed/main) [0.9+1474479173.6c180c6-1ubuntu1 => 13-0ubuntu2] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: squashfs-tools (xenial-proposed/main) [1:4.3-3ubuntu2.16.04.1 => 1:4.3-3ubuntu2.16.04.2] (core)
-queuebot:#ubuntu-release- Unapproved: squashfs-tools (trusty-proposed/main) [1:4.2+20130409-2ubuntu0.14.04.2 => 1:4.2+20130409-2ubuntu0.14.04.3] (core)
-queuebot:#ubuntu-release- New binary: qgis [armhf] (cosmic-proposed/universe) [2.18.21+dfsg-1ubuntu1] (no packageset)
<mwhudson> well i can confirm the pending bionic live-server iso fails to install
<mwhudson> but the way it does so makes it look like the archive is busted?
<mwhudson> apt-get install linux-generic failing doesn't look good?
<mwhudson> infinity, slangasek: halp, am confused
<mwhudson> ohh
<slangasek> mwhudson: is this related to the kernel revert for the regression?
<mwhudson> slangasek: yes it must be, but i'm also confused
<mwhudson> slangasek: although i just realized that the livefs is built from proposed but doesn't have proposed in etc/apt/sources.list
<slangasek> well
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (xenial-proposed) [17.03.2-0ubuntu2~16.04.1]
<mwhudson> which seems likely to lead to confusion?
<slangasek> that's probably better than the alternative
<mwhudson> yes
<mwhudson> probably
<mwhudson> but it is going to lead to this sort of thing
<slangasek> in this case, we are trying to use the daily image to actually test an SRU, so having it build not from proposed doesn't help
<mwhudson> anyway the fix is just to wait for linux-meta to migrate and build a new iso right?
<slangasek> unsure.  why is linux-generic not installable in this combination?  is it because the image doesn't include linux-generic, only linux-image-generic or such?
<slangasek> (should subiquity be not installing linux-generic? should the image be shipping linux-generic?)
<mwhudson> i am not completely sure
<mwhudson> whaaat apt-cache does not work on read-only media?
<mwhudson> ffs
<mwhudson> biab
<sarnold> apt-policy?
-queuebot:#ubuntu-release- New: accepted qgis [amd64] (cosmic-proposed) [2.18.21+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [armhf] (cosmic-proposed) [2.18.21+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [ppc64el] (cosmic-proposed) [2.18.21+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [arm64] (cosmic-proposed) [2.18.21+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [s390x] (cosmic-proposed) [2.18.21+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [i386] (cosmic-proposed) [2.18.21+dfsg-1ubuntu1]
<mwhudson> oh
<mwhudson> ah no the image does have proposed in its sources.list
<mwhudson> ah so i think proposed is just inconsistent?
<mwhudson> https://launchpad.net/ubuntu/bionic/amd64/linux-image-4.15.0-26-generic <- no packages
<mwhudson> slangasek: ^
<mwhudson> slangasek: https://launchpad.net/ubuntu/+source/linux-signed/4.15.0-26.28 <- NEW review pls? :)
<mwhudson> at least the initd looks correct wrt microcode
#ubuntu-release 2018-07-06
<slangasek> new review> hmmm I guess we're very far outside the boundaries of the kernel SRU process if that didn't get done automatically
<slangasek> mwhudson: NEW done
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.15.0-1015.15]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-26.28]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-26.28]
<mwhudson> slangasek: hurrah
<doko> apw: linux-gcp has old binaries in proposed
<doko> LocutusOfBorg: haskell-store ftbfs. old qgis binaries removed
<ginggs> doko: [20:14:38] <LocutusOfBorg> can anybody please kick haskell-store out from release and see the magic happen again?
<doko> ahh, ok
<doko> slangasek: ^^^ I think this needs a manual hint again, once the haskell-store haskell-stack reomvals are published
<LocutusOfBorg> <3
<LocutusOfBorg> while waiting for mariadb autopkgtests being fixed, I'll sync qgis
<LocutusOfBorg> and haskell  is gone! thanks doko!
<juliank> Laney: So, what happened to mariadb-10.1 arm64? Does this still need investigating? I don't see any timing out issues in the page at http://autopkgtest.ubuntu.com/packages/m/mariadb-10.1/cosmic/arm64 - it just fails to find packages there
<juliank> well, maybe it did not go in there
<juliank> Forgot about it yesterday
<LocutusOfBorg> Laney, sorry for bothering, can you please have a look or give me hint about pinetry testsuite failing?
<LocutusOfBorg> autopkgtest for pinentry/1.1.0-1build2: amd64: Pass, arm64: Regression â» , armhf: Pass, i386: Regression â» , ppc64el: Always failed, s390x: Regression â»
<LocutusOfBorg> it fails on arm64 i386 s390x, and I blame some autopkgtestsuite /dev wrong binding or permission
<LocutusOfBorg> reasons for this are: 1) I can't reproduce on pbuilder i386 environment, 2) they seems to have been started failing without code changes
<LocutusOfBorg> so, something in the infrastructure might have changed in the meanwhile...
<LocutusOfBorg> I blame /proc or tty issues :)
<apw> doko, ta
<LocutusOfBorg> can anybody please tell me why gphoto2 is sad for britney?
<LocutusOfBorg> indeed, somebody accepted libcdk5 when it was not built everywhere, so gphoto2 has  been built against the old version on some slow architectures
<LocutusOfBorg> rebuild issues
<LocutusOfBorg> *ed
<doko> no
<LocutusOfBorg> Get:61 http://ftpmaster.internal/ubuntu cosmic/universe armhf libcdk5-dev armhf 5.0.20161210-5build1 [250 kB]
<doko> libcdk5 depends on the perl version in proposed
<LocutusOfBorg> doko, look at arm64 log
<LocutusOfBorg> trust me, I setup an arm64 chroot just to look :)
<LocutusOfBorg> in fact, britney in the big hint, shows gphoto2 only on arm* and somewhere else, not on amd64 i386 and elsewhere
<doko> maybe that too, but it won't migrate
<LocutusOfBorg> it will
<LocutusOfBorg> perl is candidate
<LocutusOfBorg> in the big hint, only mariadb is blocking now
<LocutusOfBorg>     * amd64: mariadb-client, mariadb-client-10.1, mariadb-plugin-connect, mariadb-plugin-cracklib-password-check, mariadb-plugin-gssapi-client, mariadb-plugin-gssapi-server, mariadb-plugin-mroonga, mariadb-plugin-oqgraph, mariadb-plugin-spider, mariadb-plugin-tokudb, mariadb-server, mariadb-server-10.1, mariadb-server-core-10.1
<LocutusOfBorg> this is what is currently blocking
<LocutusOfBorg> and arm* has     * arm64: gphoto2, mariadb-client-10.1, mariadb-plugin-connect, mariadb-plugin-cracklib-password-check, mariadb-plugin-gssapi-client, mariadb-plugin-gssapi-server, mariadb-plugin-mroonga, mariadb-plugin-oqgraph, mariadb-plugin-spider, mariadb-server-10.1, mariadb-server-core-10.1
<Laney> juliank: Unless there are results on excuses, yes, it needs investigating.
<Laney> LocutusOfBorg: This reproduces using an autopkgtest-buildvm-ubuntu-cloud build i386 image
<LocutusOfBorg> Laney, do you have a command to reproduce? or is somebody working on that?
<LocutusOfBorg> this is really the last stopper
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-backports/main) [3.0.1-0ubuntu1~16.04.2 => 3.0.1-0ubuntu1~16.04.3] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-backports) [3.0.1-0ubuntu1~16.04.3]
-queuebot:#ubuntu-release- New source: boost1.67 (cosmic-proposed/primary) [1.67.0-0ubuntu1]
<juliank> I just launched a mariadb autopkgtest and got it hanging
<juliank> it starts a mysqld and then just hangs in there
<juliank> It's waiting inside a mutex inside libjemalloc2
<juliank> says Backtrace stopped: previous frame inner to this frame (corrupt stack?)
<juliank> though
<LocutusOfBorg> :/
<juliank> There's only one thread, how can that pthread_mutex lockup????
<LocutusOfBorg> juliank, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871446 ?
<ubot5> Debian bug 871446 in src:jemalloc "jemalloc: FTBFS on hurd-i386: aligned_alloc test hangs" [Wishlist,Open]
<LocutusOfBorg> I'm trying to see if upstream has fixes https://github.com/jemalloc/jemalloc/compare/5.1.0...dev
<juliank> LocutusOfBorg: I think we can just add arm64 to the blacklist in debian/rules and try again
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.15.0-1016.16] (kernel)
<juliank> Laney: Any idea how to get a PPA in there?
<juliank> In the commandline launching autopkgtest
<juliank> I could just upload to proposed, but if it does not work, we just spent a lot of cycles retesting all mariadb rdeps
<LocutusOfBorg> juergh, they are empty, proposed proposed please, migration! :)
<LocutusOfBorg> juliank, ^^ autopkgtest queue is empty
<LocutusOfBorg> build queue daemons too...
<LocutusOfBorg> and lots is waiting for this
<juliank> LocutusOfBorg: OK
<juliank> I have to leave anyway
<juliank> So I uploaded it
<juliank> https://launchpad.net/ubuntu/+source/mariadb-10.1/1:10.1.29-6ubuntu1
<juliank> Start in 55 minutes
<juliank> Build score:3260 (What's this?)
<juliank> is what LP says
<juliank> now it's 28 mins
<juliank> so it should start soon
<juliank> :D
<LocutusOfBorg> yep! thanks for doing it!
<LocutusOfBorg> I hope we can end this stuff today
<LocutusOfBorg> bad juliank is bad :)
<LocutusOfBorg> let me reupload
<LocutusOfBorg> you didn't remove libjemalloc-dev from b-d on arm64 :o
<juliank> LocutusOfBorg: hmm?
<juliank> Shouldn't matter
<LocutusOfBorg> yep, true
<LocutusOfBorg> I hope :)
<LocutusOfBorg> if the switch is good
 * LocutusOfBorg goes AFK, and waits for the magic to happen again hopefully
<juliank> Seems like servers are busy
<juliank> I mean, one is building, not sure what the others are doing
<LocutusOfBorg> https://launchpad.net/builders
<LocutusOfBorg> cleaning, probably means some "hey lets do something on infra, like changing bits"
<juliank> I was looking for that page!
<juliank> :D
<LocutusOfBorg> but they have empty queues, so it should start soon, they don't disable all the infra usually
<juliank> we should just cancel everything elswe
<juliank> :D
<LocutusOfBorg> loooooool
<LocutusOfBorg> cancel everything, let mariadb build, and then retry
<LocutusOfBorg> (btw mariadb is now building everywhere)
 * LocutusOfBorg leaves for train
<juliank> OK
<cjwatson> LocutusOfBorg: no, "cleaning" is usually that a VM reset crashed at some point
<cjwatson> (if it's for more than a few minutes)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.15.0-1016.16]
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1010.13] (kernel)
<bdmurray> I forget is there some tool to rerun a bunch of autopkgtests?
<acheronuk> bdmurray: retry-autopkgtest-regressions in ubuntu-archive-tools bzr repo?
<bdmurray> This is for an SRU, so not cosmic.
-queuebot:#ubuntu-release- Unapproved: installation-guide (bionic-proposed/main) [20160121ubuntu4.1 => 20160121ubuntu4.2] (core)
<acheronuk> bdmurray: optional arguments: -s SERIES, --series SERIES: Ubuntu series (default: cosmic)
<acheronuk> that implies can be used for other than the dev series, though I admit I have not tried
-queuebot:#ubuntu-release- Unapproved: accepted evolution-data-server [source] (bionic-proposed) [3.28.3-0ubuntu0.18.04.1]
<acheronuk> seems to give me a retry list that corresponds to regressions on http://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (bionic-proposed) [1:3.28.2-0ubuntu0.18.04.1]
<bdmurray> acheronuk: Cool, I try it out
-queuebot:#ubuntu-release- Unapproved: accepted gnome-disk-utility [source] (bionic-proposed) [3.28.3-0ubuntu1~18.04.1]
<bdmurray> coreycb: Is your nova sru for bionic meant to supersede the existing one?
<coreycb> bdmurray: that should probably wait until nova clears from proposed
-queuebot:#ubuntu-release- Unapproved: partman-auto (xenial-proposed/main) [134ubuntu1.2 => 134ubuntu1.3] (core)
<bdmurray> coreycb: okay
-queuebot:#ubuntu-release- Unapproved: grub-installer (bionic-proposed/main) [1.128ubuntu8.18.04.1 => 1.128ubuntu8.18.04.2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted squashfs-tools [source] (bionic-proposed) [1:4.3-6ubuntu0.18.04.1]
<wxl> is there a reason we don't have a mini.iso for 18.10?
-queuebot:#ubuntu-release- Unapproved: rejected python2.7 [source] (bionic-proposed) [2.7.15-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted squashfs-tools [source] (xenial-proposed) [1:4.3-3ubuntu2.16.04.2]
<wxl> oh nevermind i found it
<ginggs> the iso, or the reason?
-queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (bionic-proposed) [0.36.3]
<jdstrand> bdmurray: thanks for processing the squashfs-tools srus! I'm not sure how the queue is managed, but if you could also look at the trusty one, that would be great (curiously, that is actually the most important one atm since this is for the snap store and its still on trusty)
<jdstrand> it's*
-queuebot:#ubuntu-release- Unapproved: accepted partman-auto [source] (xenial-proposed) [134ubuntu1.3]
<bdmurray> jdstrand: For some reason I forget about that release. ;-)
<jdstrand> bdmurray: I had a suspicion it might not be looked at as often :)
<bdmurray> jdstrand: Well, I should have noticed the bug task.
-queuebot:#ubuntu-release- Unapproved: accepted squashfs-tools [source] (trusty-proposed) [1:4.2+20130409-2ubuntu0.14.04.3]
<jdstrand> bdmurray: thanks!
-queuebot:#ubuntu-release- New binary: libseccomp [s390x] (cosmic-proposed/main) [2.3.3-3ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: libseccomp [ppc64el] (cosmic-proposed/main) [2.3.3-3ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: libseccomp [i386] (cosmic-proposed/main) [2.3.3-3ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: libseccomp [amd64] (cosmic-proposed/main) [2.3.3-3ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: libseccomp [armhf] (cosmic-proposed/main) [2.3.3-3ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: libseccomp [arm64] (cosmic-proposed/main) [2.3.3-3ubuntu1] (core)
<juliank> LocutusOfBorg: so, it turns out the build of mariadb failed on arm64 with test suite issu
<juliank> mariabackup: malloc.c:2401: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.
<juliank> nice
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1010.13]
<juliank> so, I'm not sure what's happening there
<juliank> I'm off now, so if somebody wants to play more with mariadb-10.1, please do so
-queuebot:#ubuntu-release- Unapproved: rejected grub-installer [source] (bionic-proposed) [1.128ubuntu8.18.04.2]
-queuebot:#ubuntu-release- Unapproved: grub-installer (bionic-proposed/main) [1.128ubuntu8.18.04.1 => 1.128ubuntu8.18.04.2] (core)
<slangasek> well for my part, I was just considering removing it to let the transition through
<slangasek> and also grumbling at the packages that depend on mariadb* instead of default-mysql*
<slangasek> but the mariadb -> hoel -> glewlwyd -> * dependency chain is annoying
<slangasek> juliank: what hanging tests were you trying to fix on arm64 with this upload?  because 1:10.1.29-6build2 built successfully on arm64, and mariadb-10.1's autopkgtests are force-badtest
<juliank> slangasek: the mariadb-10.1 ones, they are always in progress
<juliank> They don't get to the state where the force badtest takes effect
<slangasek> juliank: ah.  well, that's a bug in the infrastructure then, which I'm happy to route around with a different hint
<slangasek> I'm rolling back to -6build2, and will see about hinting this through
<juliank> slangasek: ok.
-queuebot:#ubuntu-release- New binary: aodh [amd64] (cosmic-proposed/main) [6.0.1-0ubuntu3] (openstack, ubuntu-server)
<LocutusOfBorg> slangasek, <3
<LocutusOfBorg> I don't see the whole migrating, lets wait some more time
<LocutusOfBorg> in the meanwhile I'm trying to understand if that test is good to fail
<LocutusOfBorg> juliank, my wild guess is:
<LocutusOfBorg> # Ignore test suite exit code on unstable platforms
<LocutusOfBorg> ifeq ($(DEB_HOST_ARCH),$(filter $(DEB_HOST_ARCH), mips mipsel mips64el alpha powerpc sh4 hurd-i386 sparc64 kfreebsd-i386 kfreebsd-amd64))
<LocutusOfBorg> it seems to contain all the architectures where jmalloc is disabled (and some more). I don't think this is a "coincidence" :)
<LocutusOfBorg> slangasek, did you already place the hint?
<slangasek> LocutusOfBorg: no, I haven't identified anything yet that needs hinting.  Currently I see that mariadb-10.1 arm64 is 'Test in progress (always failed)', which should definitely not block; and catci and dbconfig-common have previous test runs that failed, which I'm now retrying.
<LocutusOfBorg> slangasek, retrying makes the test hang
<slangasek> (failed due to uninstallable test deps, not due to anything with test hangs)
<LocutusOfBorg> but it will hang, like it did the last few days
<slangasek> what will hang?
<LocutusOfBorg> and it doesn't hang on my qemu
<slangasek> I'm not looking at hung tests here
<LocutusOfBorg> postinst of mariadb
<LocutusOfBorg> seems that mysql has issues with a racy mutex in jmalloc
<LocutusOfBorg> this is why juliank disabled jmalloc on arm64
<LocutusOfBorg> my proposal is to 1) ignore tests there and force mariadb-10.1 and then 2) reupload mariadb-10.1 with jmalloc disabled on arm64 and tests ignored because of what I wrote above
<LocutusOfBorg> so we can re-enable autosync, and do octave transition during the weekend
<LocutusOfBorg> I uploaded a "fixed" mariadb in my ppa some seconds ago, this one should make tests pass
<LocutusOfBorg> if juliank analized correctly the situation :)
 * LocutusOfBorg goes to sleep
-queuebot:#ubuntu-release- Unapproved: ndiswrapper (xenial-proposed/universe) [1.60-3~ubuntu16.04.2 => 1.60-3~ubuntu16.04.3] (no packageset)
<slangasek> LocutusOfBorg: so, what I currently see in mariadb-10.1 autopkgtest results does not show any hung tests blocking the package.  Only some straight up failures of reverse-dependencies' tests, and a lost test result for slurm-llnl.
-queuebot:#ubuntu-release- Unapproved: xtables-addons (xenial-proposed/universe) [2.12-0.1~16.04.2 => 2.12-0.1~16.04.3] (no packageset)
<LocutusOfBorg> slangasek, hanging test won't appear on the page :/
<LocutusOfBorg> slangasek, Setting up mariadb-server-10.1 (1:10.1.29-6build2) ...
<LocutusOfBorg> your retries seems to be all stuck there
<LocutusOfBorg> after the timeout, they will be killend and no log shown on result page
<LocutusOfBorg> if you want to see tests not hanging, trying this mariadb might be the solution https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+delete-packages
<LocutusOfBorg> but I prefer it being hinted and fixed later
<slangasek> LocutusOfBorg: hanging tests absolutely show on update_excuses as 'Test in progress'
<slangasek> and the only one in that state is slurm-llnl, which if that's the hung test in question, no one has said
<slangasek> tests killed during dep setup ought to still be reported, and it's a bug if not.  But ok, now I understand that what we're talking about here is mariadb-10.1 causing hangs in autopkgtests of other packages
<LocutusOfBorg> [00:34:20] <slangasek> LocutusOfBorg: hanging tests absolutely show on update_excuses as 'Test in progress' <-- true in general, in this case they were reported as "bad" because dependencies weren't installable due to the old common ubuntu1 mariadb package still being around :)
<LocutusOfBorg> btw slangasek the bug is really in jmalloc code probably, or maybe a bad mutex in mariadb that shows up only on arm64
<LocutusOfBorg> dbconfig-common will fail exactly with the same hang
<LocutusOfBorg> and also cacti
<LocutusOfBorg> not sure what happens there, and I can't reproduce locally
<slangasek> ok
<LocutusOfBorg> we might really blame infra :p (easy answer, but consider it a joke)
<LocutusOfBorg> disabling jmalloc was a good try, and I'm pretty sure the package in my ppa won't hang
<LocutusOfBorg> I can try a test tomorrow morning, if the package publishes tonight
<slangasek> so, I've added the hints now; would of course prefer mariadb-10.1 fixed, so I'm looking forward to the results of your ppa test
<LocutusOfBorg> I don't like disabling testsuite on arm64, but testing reverse deps seems to be a superior test
<LocutusOfBorg> (and probably the test failure is related to some test that requires jmalloc being enabled))
-queuebot:#ubuntu-release- Unapproved: v4l2loopback (xenial-proposed/universe) [0.9.1-4 => 0.9.1-4ubuntu0.1] (no packageset)
<LocutusOfBorg> https://autopkgtest.ubuntu.com/request.cgi?release=cosmic&arch=arm64&package=cacti&ppa=costamagnagianfranco/locutusofborg-ppa&trigger=mariadb-10.1/1:10.1.29-6ubuntu2
<LocutusOfBorg> this might be the query to run :)
-queuebot:#ubuntu-release- Unapproved: dahdi-linux (xenial-proposed/universe) [1:2.10.2~dfsg-1ubuntu2 => 1:2.10.2~dfsg-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: oss4 (xenial-proposed/universe) [4.2-build2010-5ubuntu1~14.04.1 => 4.2-build2010-5ubuntu1~16.04.2] (no packageset)
<slangasek> chrisccoulson: seems the libgit2 you synced from experimental is not compatible with current libgit2-glib.  did you get emails telling you that your sync was stuck in -proposed?
<sarnold> something he said elsewhere.. "hmmm, https://launchpad.net/ubuntu/+source/libgit2-glib needs fixing" "it actually needs porting to the latest libgit2, which hasn't happened upstream"
#ubuntu-release 2018-07-07
<slangasek> sarnold: well, in fact I just build libgit2-glib 0.26.4 against the new libgit2 here
<slangasek> no porting required for the new libgit2, just porting of the packaging
<slangasek> sarnold: no, my mistake, I'm apparently running 'debuild -S' and not noticing
<sarnold> slangasek: dang, "no work necessary" would probabl yhave been a nice gift for chrisccoulson :)
<slangasek> sarnold: and if it involved a one-liner patch, what kind of gift is that? :)
<sarnold> slangasek: hrm, it might seem a bit small if we try to give it together, I guess I'll have to find something else to give him.. :)
<sarnold> slangasek,chrisccoulson, should python3.5 have 'leaked' to trusty? https://launchpad.net/ubuntu/+source/python3.5
<tsimonq2> slangasek: gilir is no longer a member of the Lubuntu project; I noticed that he's still CCed on Lubuntu ISO FTBFS emails but it would be good to know if there's anything else to clean up.
<tsimonq2> Ref: https://lists.ubuntu.com/archives/lubuntu-devel/2018-May/001181.html
<tsimonq2> Oh yay, so the image still fails, but it's something actually somewhat tackleable.
<tsimonq2> Errors encountered while processing: <a bunch of cups and printer stuff>
-queuebot:#ubuntu-release- New: accepted aodh [amd64] (cosmic-proposed) [6.0.1-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted libseccomp [amd64] (cosmic-proposed) [2.3.3-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted libseccomp [armhf] (cosmic-proposed) [2.3.3-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted libseccomp [ppc64el] (cosmic-proposed) [2.3.3-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted boost1.67 [source] (cosmic-proposed) [1.67.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libseccomp [i386] (cosmic-proposed) [2.3.3-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted libseccomp [arm64] (cosmic-proposed) [2.3.3-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted libseccomp [s390x] (cosmic-proposed) [2.3.3-3ubuntu1]
<doko> nice, openmpi finally migrated ...
<doko> slangasek: please re-enable the auto-imports from debian again
<doko> jbicha: time for some mass uploads again ;)
-queuebot:#ubuntu-release- New binary: boost1.67 [s390x] (cosmic-proposed/universe) [1.67.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: boost1.67 [ppc64el] (cosmic-proposed/universe) [1.67.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: boost1.67 [i386] (cosmic-proposed/universe) [1.67.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: boost1.67 [amd64] (cosmic-proposed/universe) [1.67.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave [s390x] (cosmic-proposed/universe) [4.4.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: octave [amd64] (cosmic-proposed/universe) [4.4.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: octave [i386] (cosmic-proposed/universe) [4.4.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: octave [ppc64el] (cosmic-proposed/universe) [4.4.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: boost1.67 [armhf] (cosmic-proposed/universe) [1.67.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: boost1.67 [arm64] (cosmic-proposed/universe) [1.67.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave [arm64] (cosmic-proposed/universe) [4.4.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-actionlib [amd64] (cosmic-proposed/universe) [1.11.14-2] (no packageset)
<LocutusOfBorg> slangasek, mariadb without jmalloc seems to be not hanging anymore
<LocutusOfBorg> lets upload
<LocutusOfBorg> *please enable autosync* :)
<LocutusOfBorg> doko, is boost 1.62 syncable?
<LocutusOfBorg> if fpermissive was a build fix, debian has a python3.7 patch... lets sync
 * LocutusOfBorg did sync some perl leaf packages, and sphinx, so we don't waste autopkgtests time when autosync opens again
-queuebot:#ubuntu-release- New binary: ros-angles [amd64] (cosmic-proposed/universe) [1.9.11-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-ros [amd64] (cosmic-proposed/universe) [1.14.4-2] (no packageset)
<Laney> LocutusOfBorg: The normal command: autopkgtest --apt-upgrade --shell-fail --apt-pocket=proposed=src:pinentry pinentry -- qemu autopkgtest-cosmic-i386.img
-queuebot:#ubuntu-release- New binary: geoclue-2.0 [i386] (cosmic-proposed/main) [2.4.10-1ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: geoclue-2.0 [s390x] (cosmic-proposed/main) [2.4.10-1ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: geoclue-2.0 [ppc64el] (cosmic-proposed/main) [2.4.10-1ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: geoclue-2.0 [amd64] (cosmic-proposed/main) [2.4.10-1ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: geoclue-2.0 [armhf] (cosmic-proposed/main) [2.4.10-1ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: geoclue-2.0 [arm64] (cosmic-proposed/main) [2.4.10-1ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted geoclue-2.0 [amd64] (cosmic-proposed) [2.4.10-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted geoclue-2.0 [armhf] (cosmic-proposed) [2.4.10-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted geoclue-2.0 [ppc64el] (cosmic-proposed) [2.4.10-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted geoclue-2.0 [arm64] (cosmic-proposed) [2.4.10-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted geoclue-2.0 [s390x] (cosmic-proposed) [2.4.10-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted geoclue-2.0 [i386] (cosmic-proposed) [2.4.10-1ubuntu1]
-queuebot:#ubuntu-release- New sync: julia (cosmic-proposed/primary) [0.6.3-3]
<slangasek> LocutusOfBorg: autosync reenabled
<tsimonq2> nwin 44
<tsimonq2> whoops
<tsimonq2> infinity: Bump on merging that MP.
-queuebot:#ubuntu-release- New sync: kitty (cosmic-proposed/primary) [0.11.2-3]
-queuebot:#ubuntu-release- New binary: concordance [amd64] (cosmic-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: liblouis [s390x] (cosmic-proposed/main) [3.6.0-2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: liblouis [ppc64el] (cosmic-proposed/main) [3.6.0-2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: liblouis [amd64] (cosmic-proposed/main) [3.6.0-2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: granite [amd64] (cosmic-proposed/universe) [5.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: granite [i386] (cosmic-proposed/universe) [5.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: liblouis [arm64] (cosmic-proposed/main) [3.6.0-2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: liblouis [armhf] (cosmic-proposed/main) [3.6.0-2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: granite [ppc64el] (cosmic-proposed/universe) [5.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: liblouis [i386] (cosmic-proposed/main) [3.6.0-2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: granite [arm64] (cosmic-proposed/universe) [5.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: granite [armhf] (cosmic-proposed/universe) [5.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-ghdiff [amd64] (cosmic-proposed/universe) [0.4-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-ronn [amd64] (cosmic-proposed/universe) [0.7.3-5.1] (no packageset)
-queuebot:#ubuntu-release- New binary: pydicom [amd64] (cosmic-proposed/universe) [1.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-ros-comm [s390x] (cosmic-proposed/universe) [1.14.2+ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bitflags [s390x] (cosmic-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bitflags [amd64] (cosmic-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bytecount [i386] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-markdown-math [amd64] (cosmic-proposed/universe) [0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bytecount [amd64] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-byteorder [amd64] (cosmic-proposed/universe) [1.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-byteorder [s390x] (cosmic-proposed/universe) [1.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dtoa [amd64] (cosmic-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bitflags [i386] (cosmic-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-byteorder [i386] (cosmic-proposed/universe) [1.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dtoa [s390x] (cosmic-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bytecount [s390x] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cfg-if [s390x] (cosmic-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pywws [amd64] (cosmic-proposed/universe) [18.6.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dtoa [i386] (cosmic-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-either [s390x] (cosmic-proposed/universe) [1.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-getopts [amd64] (cosmic-proposed/universe) [0.2.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-getopts [s390x] (cosmic-proposed/universe) [0.2.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hex [i386] (cosmic-proposed/universe) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cfg-if [amd64] (cosmic-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fnv [s390x] (cosmic-proposed/universe) [1.0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-glob [s390x] (cosmic-proposed/universe) [0.2.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-either [amd64] (cosmic-proposed/universe) [1.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-httparse [amd64] (cosmic-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-getopts [i386] (cosmic-proposed/universe) [0.2.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-either [i386] (cosmic-proposed/universe) [1.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-glob [amd64] (cosmic-proposed/universe) [0.2.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hex [amd64] (cosmic-proposed/universe) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-httparse [i386] (cosmic-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-is-match [s390x] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lazy-static [i386] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-num-traits [i386] (cosmic-proposed/universe) [0.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fnv [i386] (cosmic-proposed/universe) [1.0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hex [s390x] (cosmic-proposed/universe) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lazy-static [amd64] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-glob [i386] (cosmic-proposed/universe) [0.2.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-num-traits [amd64] (cosmic-proposed/universe) [0.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-httparse [s390x] (cosmic-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-ros-comm [i386] (cosmic-proposed/universe) [1.14.2+ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fnv [amd64] (cosmic-proposed/universe) [1.0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-is-match [i386] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-itoa [i386] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lazy-static [s390x] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libc [s390x] (cosmic-proposed/universe) [0.2.42-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pkg-config [s390x] (cosmic-proposed/universe) [0.3.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-safemem [i386] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-semver-parser [amd64] (cosmic-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cfg-if [i386] (cosmic-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-itoa [amd64] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libc [i386] (cosmic-proposed/universe) [0.2.42-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-safemem [amd64] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-semver-parser [s390x] (cosmic-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-is-match [amd64] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-num-traits [s390x] (cosmic-proposed/universe) [0.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-itoa [s390x] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-safemem [s390x] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-ros-comm [amd64] (cosmic-proposed/universe) [1.14.2+ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sha1 [amd64] (cosmic-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-slab [amd64] (cosmic-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-serde [s390x] (cosmic-proposed/universe) [1.0.66-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ucd-util [amd64] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sha1 [i386] (cosmic-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pkg-config [amd64] (cosmic-proposed/universe) [0.3.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-serde [i386] (cosmic-proposed/universe) [1.0.66-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shell-escape [amd64] (cosmic-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shell-escape [s390x] (cosmic-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-slab [s390x] (cosmic-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-width [amd64] (cosmic-proposed/universe) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-utf-8 [amd64] (cosmic-proposed/universe) [0.7.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-utf8-ranges [amd64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pkg-config [i386] (cosmic-proposed/universe) [0.3.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shell-escape [i386] (cosmic-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ucd-util [i386] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-utf-8 [i386] (cosmic-proposed/universe) [0.7.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sha1 [s390x] (cosmic-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-xid [i386] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-slab [i386] (cosmic-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libc [amd64] (cosmic-proposed/universe) [0.2.42-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-serde [amd64] (cosmic-proposed/universe) [1.0.66-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-normalization [amd64] (cosmic-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-width [s390x] (cosmic-proposed/universe) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-xid [s390x] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-utf8-ranges [s390x] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-void [s390x] (cosmic-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-winapi-build [i386] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-winapi-i686-pc-windows-gnu [i386] (cosmic-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-winapi-x86-64-pc-windows-gnu [i386] (cosmic-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-semver-parser [i386] (cosmic-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-normalization [s390x] (cosmic-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-utf-8 [s390x] (cosmic-proposed/universe) [0.7.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-winapi-build [amd64] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-winapi-x86-64-pc-windows-gnu [amd64] (cosmic-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ucd-util [s390x] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-void [i386] (cosmic-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sweed [i386] (cosmic-proposed/universe) [3.2.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-xid [amd64] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-winapi-i686-pc-windows-gnu [amd64] (cosmic-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fusioninventory-agent [amd64] (cosmic-proposed/universe) [1:2.4.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-ros-comm [ppc64el] (cosmic-proposed/universe) [1.14.2+ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-normalization [i386] (cosmic-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-utf8-ranges [i386] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-winapi-i686-pc-windows-gnu [s390x] (cosmic-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sweed [amd64] (cosmic-proposed/universe) [3.2.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libencode-base58-perl [amd64] (cosmic-proposed/universe) [0.01-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-width [i386] (cosmic-proposed/universe) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-winapi-x86-64-pc-windows-gnu [s390x] (cosmic-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bitflags [ppc64el] (cosmic-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sweed [s390x] (cosmic-proposed/universe) [3.2.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-winapi-build [s390x] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcode-tidyall-plugin-uniquelines-perl [amd64] (cosmic-proposed/universe) [0.000003-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bytecount [ppc64el] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cfg-if [ppc64el] (cosmic-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-either [ppc64el] (cosmic-proposed/universe) [1.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcode-tidyall-plugin-yamlfrontmatter-perl [amd64] (cosmic-proposed/universe) [1.000001-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dtoa [ppc64el] (cosmic-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-byteorder [ppc64el] (cosmic-proposed/universe) [1.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-void [amd64] (cosmic-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fnv [ppc64el] (cosmic-proposed/universe) [1.0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-glob [ppc64el] (cosmic-proposed/universe) [0.2.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-httparse [ppc64el] (cosmic-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-getopts [ppc64el] (cosmic-proposed/universe) [0.2.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hex [ppc64el] (cosmic-proposed/universe) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-is-match [ppc64el] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lazy-static [ppc64el] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-num-traits [ppc64el] (cosmic-proposed/universe) [0.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-itoa [ppc64el] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libc [ppc64el] (cosmic-proposed/universe) [0.2.42-1] (no packageset)
-queuebot:#ubuntu-release- New binary: anbox [amd64] (cosmic-proposed/multiverse) [0.0~git20180612-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-safemem [ppc64el] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sha1 [ppc64el] (cosmic-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pkg-config [ppc64el] (cosmic-proposed/universe) [0.3.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-semver-parser [ppc64el] (cosmic-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-serde [ppc64el] (cosmic-proposed/universe) [1.0.66-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-slab [ppc64el] (cosmic-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shell-escape [ppc64el] (cosmic-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ucd-util [ppc64el] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-normalization [ppc64el] (cosmic-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-xid [ppc64el] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-width [ppc64el] (cosmic-proposed/universe) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-utf-8 [ppc64el] (cosmic-proposed/universe) [0.7.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-void [ppc64el] (cosmic-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-winapi-i686-pc-windows-gnu [ppc64el] (cosmic-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-utf8-ranges [ppc64el] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-winapi-x86-64-pc-windows-gnu [ppc64el] (cosmic-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-winapi-build [ppc64el] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-fluids [amd64] (cosmic-proposed/universe) [0.1.72-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sweed [ppc64el] (cosmic-proposed/universe) [3.2.1+dfsg-1] (no packageset)
#ubuntu-release 2018-07-08
-queuebot:#ubuntu-release- New binary: rust-bitflags [arm64] (cosmic-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bitflags [armhf] (cosmic-proposed/universe) [1.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: odb-api [amd64] (cosmic-proposed/universe) [0.18.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bytecount [armhf] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bytecount [arm64] (cosmic-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-ros-comm [armhf] (cosmic-proposed/universe) [1.14.2+ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cfg-if [armhf] (cosmic-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cfg-if [arm64] (cosmic-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-byteorder [arm64] (cosmic-proposed/universe) [1.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dtoa [arm64] (cosmic-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-either [arm64] (cosmic-proposed/universe) [1.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-byteorder [armhf] (cosmic-proposed/universe) [1.2.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-either [armhf] (cosmic-proposed/universe) [1.5.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-dtoa [armhf] (cosmic-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-ros-comm [arm64] (cosmic-proposed/universe) [1.14.2+ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fnv [armhf] (cosmic-proposed/universe) [1.0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-getopts [armhf] (cosmic-proposed/universe) [0.2.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-glob [armhf] (cosmic-proposed/universe) [0.2.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hex [armhf] (cosmic-proposed/universe) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-httparse [armhf] (cosmic-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-is-match [armhf] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-fnv [arm64] (cosmic-proposed/universe) [1.0.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-glob [arm64] (cosmic-proposed/universe) [0.2.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-httparse [arm64] (cosmic-proposed/universe) [1.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-getopts [arm64] (cosmic-proposed/universe) [0.2.17-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-is-match [arm64] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-hex [arm64] (cosmic-proposed/universe) [0.3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-itoa [arm64] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lazy-static [armhf] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-itoa [armhf] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libc [arm64] (cosmic-proposed/universe) [0.2.42-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-num-traits [arm64] (cosmic-proposed/universe) [0.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pkg-config [arm64] (cosmic-proposed/universe) [0.3.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-safemem [arm64] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-semver-parser [arm64] (cosmic-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sha1 [arm64] (cosmic-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shell-escape [arm64] (cosmic-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-lazy-static [arm64] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-num-traits [armhf] (cosmic-proposed/universe) [0.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-safemem [armhf] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sha1 [armhf] (cosmic-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-libc [armhf] (cosmic-proposed/universe) [0.2.42-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-semver-parser [armhf] (cosmic-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pkg-config [armhf] (cosmic-proposed/universe) [0.3.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-serde [arm64] (cosmic-proposed/universe) [1.0.66-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shell-escape [armhf] (cosmic-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-slab [armhf] (cosmic-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ucd-util [armhf] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-width [armhf] (cosmic-proposed/universe) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-serde [armhf] (cosmic-proposed/universe) [1.0.66-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ucd-util [arm64] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-xid [arm64] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-slab [arm64] (cosmic-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-width [arm64] (cosmic-proposed/universe) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-normalization [arm64] (cosmic-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-xid [armhf] (cosmic-proposed/universe) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-utf-8 [armhf] (cosmic-proposed/universe) [0.7.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-normalization [armhf] (cosmic-proposed/universe) [0.1.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-utf-8 [arm64] (cosmic-proposed/universe) [0.7.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-utf8-ranges [arm64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-void [arm64] (cosmic-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-winapi-build [arm64] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-winapi-i686-pc-windows-gnu [arm64] (cosmic-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-winapi-x86-64-pc-windows-gnu [arm64] (cosmic-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-utf8-ranges [armhf] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-winapi-build [armhf] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-winapi-x86-64-pc-windows-gnu [armhf] (cosmic-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-void [armhf] (cosmic-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-winapi-i686-pc-windows-gnu [armhf] (cosmic-proposed/universe) [0.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lubuntu-artwork [amd64] (cosmic-proposed/universe) [1.4] (lubuntu)
-queuebot:#ubuntu-release- New binary: sweed [arm64] (cosmic-proposed/universe) [3.2.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sweed [armhf] (cosmic-proposed/universe) [3.2.1+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: anbox [armhf] (cosmic-proposed/multiverse) [0.0~git20180612-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-serde [arm64] (cosmic-proposed) [1.0.66-1]
-queuebot:#ubuntu-release- New: accepted rust-shell-escape [arm64] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-slab [arm64] (cosmic-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ucd-util [arm64] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-normalization [arm64] (cosmic-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-width [arm64] (cosmic-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-xid [arm64] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-utf-8 [arm64] (cosmic-proposed) [0.7.2-1]
-queuebot:#ubuntu-release- New: accepted rust-utf8-ranges [arm64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-void [arm64] (cosmic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-serde [armhf] (cosmic-proposed) [1.0.66-1]
-queuebot:#ubuntu-release- New: accepted rust-slab [armhf] (cosmic-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-normalization [armhf] (cosmic-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-xid [armhf] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-utf8-ranges [armhf] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-winapi-build [arm64] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-winapi-i686-pc-windows-gnu [arm64] (cosmic-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-winapi-x86-64-pc-windows-gnu [arm64] (cosmic-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-shell-escape [armhf] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-width [armhf] (cosmic-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted rust-void [armhf] (cosmic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-winapi-i686-pc-windows-gnu [armhf] (cosmic-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ucd-util [armhf] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-winapi-build [armhf] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-utf-8 [armhf] (cosmic-proposed) [0.7.2-1]
-queuebot:#ubuntu-release- New: accepted rust-winapi-x86-64-pc-windows-gnu [armhf] (cosmic-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted ros-ros-comm [arm64] (cosmic-proposed) [1.14.2+ds1-2]
-queuebot:#ubuntu-release- New: accepted rust-glob [arm64] (cosmic-proposed) [0.2.11-1]
-queuebot:#ubuntu-release- New: accepted rust-hex [arm64] (cosmic-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted rust-httparse [arm64] (cosmic-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-is-match [arm64] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-itoa [arm64] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-lazy-static [arm64] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-libc [arm64] (cosmic-proposed) [0.2.42-1]
-queuebot:#ubuntu-release- New: accepted rust-num-traits [arm64] (cosmic-proposed) [0.2.5-1]
-queuebot:#ubuntu-release- New: accepted rust-pkg-config [arm64] (cosmic-proposed) [0.3.11-1]
-queuebot:#ubuntu-release- New: accepted rust-getopts [armhf] (cosmic-proposed) [0.2.17-1]
-queuebot:#ubuntu-release- New: accepted rust-hex [armhf] (cosmic-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted rust-is-match [armhf] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-lazy-static [armhf] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-num-traits [armhf] (cosmic-proposed) [0.2.5-1]
-queuebot:#ubuntu-release- New: accepted rust-safemem [arm64] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-semver-parser [arm64] (cosmic-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted rust-sha1 [arm64] (cosmic-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-glob [armhf] (cosmic-proposed) [0.2.11-1]
-queuebot:#ubuntu-release- New: accepted rust-itoa [armhf] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-pkg-config [armhf] (cosmic-proposed) [0.3.11-1]
-queuebot:#ubuntu-release- New: accepted rust-semver-parser [armhf] (cosmic-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted rust-httparse [armhf] (cosmic-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-safemem [armhf] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-libc [armhf] (cosmic-proposed) [0.2.42-1]
-queuebot:#ubuntu-release- New: accepted rust-sha1 [armhf] (cosmic-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-bitflags [arm64] (cosmic-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted rust-bytecount [arm64] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-byteorder [arm64] (cosmic-proposed) [1.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-cfg-if [arm64] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-dtoa [arm64] (cosmic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted rust-either [arm64] (cosmic-proposed) [1.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-fnv [arm64] (cosmic-proposed) [1.0.6-1]
-queuebot:#ubuntu-release- New: accepted rust-getopts [arm64] (cosmic-proposed) [0.2.17-1]
-queuebot:#ubuntu-release- New: accepted rust-utf8-ranges [ppc64el] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-winapi-build [ppc64el] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-bitflags [armhf] (cosmic-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted rust-byteorder [armhf] (cosmic-proposed) [1.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-dtoa [armhf] (cosmic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted rust-fnv [armhf] (cosmic-proposed) [1.0.6-1]
-queuebot:#ubuntu-release- New: accepted rust-void [ppc64el] (cosmic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-winapi-x86-64-pc-windows-gnu [ppc64el] (cosmic-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-bytecount [armhf] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-either [armhf] (cosmic-proposed) [1.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-winapi-i686-pc-windows-gnu [ppc64el] (cosmic-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-cfg-if [armhf] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-utf-8 [ppc64el] (cosmic-proposed) [0.7.2-1]
-queuebot:#ubuntu-release- New: accepted rust-bitflags [ppc64el] (cosmic-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted rust-byteorder [ppc64el] (cosmic-proposed) [1.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-dtoa [ppc64el] (cosmic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted rust-fnv [ppc64el] (cosmic-proposed) [1.0.6-1]
-queuebot:#ubuntu-release- New: accepted rust-glob [ppc64el] (cosmic-proposed) [0.2.11-1]
-queuebot:#ubuntu-release- New: accepted rust-httparse [ppc64el] (cosmic-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-itoa [ppc64el] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-libc [amd64] (cosmic-proposed) [0.2.42-1]
-queuebot:#ubuntu-release- New: accepted rust-num-traits [ppc64el] (cosmic-proposed) [0.2.5-1]
-queuebot:#ubuntu-release- New: accepted rust-safemem [ppc64el] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-bytecount [ppc64el] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-either [ppc64el] (cosmic-proposed) [1.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-hex [ppc64el] (cosmic-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted rust-lazy-static [ppc64el] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-pkg-config [ppc64el] (cosmic-proposed) [0.3.11-1]
-queuebot:#ubuntu-release- New: accepted rust-serde [amd64] (cosmic-proposed) [1.0.66-1]
-queuebot:#ubuntu-release- New: accepted rust-sha1 [ppc64el] (cosmic-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-slab [ppc64el] (cosmic-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-normalization [i386] (cosmic-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-normalization [s390x] (cosmic-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted rust-cfg-if [ppc64el] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-is-match [ppc64el] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-semver-parser [ppc64el] (cosmic-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted rust-shell-escape [ppc64el] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-normalization [ppc64el] (cosmic-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-width [ppc64el] (cosmic-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-xid [ppc64el] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-utf-8 [s390x] (cosmic-proposed) [0.7.2-1]
-queuebot:#ubuntu-release- New: accepted rust-utf8-ranges [s390x] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-void [i386] (cosmic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-getopts [ppc64el] (cosmic-proposed) [0.2.17-1]
-queuebot:#ubuntu-release- New: accepted rust-serde [ppc64el] (cosmic-proposed) [1.0.66-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-width [i386] (cosmic-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-xid [s390x] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-void [amd64] (cosmic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-winapi-build [amd64] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-winapi-i686-pc-windows-gnu [s390x] (cosmic-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-winapi-x86-64-pc-windows-gnu [i386] (cosmic-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New binary: boost1.67 [amd64] (cosmic-proposed/universe) [1.67.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: boost1.67 [ppc64el] (cosmic-proposed/universe) [1.67.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-libc [ppc64el] (cosmic-proposed) [0.2.42-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-width [s390x] (cosmic-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted rust-void [s390x] (cosmic-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-winapi-x86-64-pc-windows-gnu [amd64] (cosmic-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New binary: boost1.67 [i386] (cosmic-proposed/universe) [1.67.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New source: finalrd (cosmic-proposed/primary) [2]
-queuebot:#ubuntu-release- New binary: octave [amd64] (cosmic-proposed/universe) [4.4.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: octave [ppc64el] (cosmic-proposed/universe) [4.4.0-3] (no packageset)
-queuebot:#ubuntu-release- New source: qemu-ovmf-secureboot (cosmic-proposed/primary) [1.1.2-0ubuntu1]
-queuebot:#ubuntu-release- New binary: rust-num-traits [s390x] (cosmic-proposed/universe) [0.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-ucd-util [ppc64el] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-winapi-build [s390x] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New binary: boost1.67 [s390x] (cosmic-proposed/universe) [1.67.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave [i386] (cosmic-proposed/universe) [4.4.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-ros-comm [amd64] (cosmic-proposed/universe) [1.14.2+ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pkg-config [i386] (cosmic-proposed/universe) [0.3.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-safemem [i386] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-semver-parser [amd64] (cosmic-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-serde [s390x] (cosmic-proposed/universe) [1.0.66-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-sha1 [i386] (cosmic-proposed/universe) [0.6.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-utf8-ranges [i386] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New source: jboss-annotations-1.2-api (cosmic-proposed/primary) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: rust-pkg-config [amd64] (cosmic-proposed/universe) [0.3.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-unicode-width [amd64] (cosmic-proposed/universe) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-lazy-static [s390x] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-num-traits [s390x] (cosmic-proposed) [0.2.5-1]
-queuebot:#ubuntu-release- New: accepted rust-pkg-config [i386] (cosmic-proposed) [0.3.11-1]
-queuebot:#ubuntu-release- New: accepted rust-safemem [i386] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-semver-parser [amd64] (cosmic-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New binary: octave [s390x] (cosmic-proposed/universe) [4.4.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shell-escape [i386] (cosmic-proposed/universe) [0.1.4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-itoa [i386] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-pkg-config [amd64] (cosmic-proposed) [0.3.11-1]
-queuebot:#ubuntu-release- New: accepted rust-safemem [s390x] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-semver-parser [s390x] (cosmic-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted rust-serde [s390x] (cosmic-proposed) [1.0.66-1]
-queuebot:#ubuntu-release- New: accepted rust-sha1 [i386] (cosmic-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-shell-escape [amd64] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-shell-escape [s390x] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New binary: rust-serde [i386] (cosmic-proposed/universe) [1.0.66-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-libc [s390x] (cosmic-proposed) [0.2.42-1]
-queuebot:#ubuntu-release- New: accepted rust-semver-parser [i386] (cosmic-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted rust-sha1 [amd64] (cosmic-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-shell-escape [i386] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-slab [i386] (cosmic-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ucd-util [amd64] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-ucd-util [s390x] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-width [amd64] (cosmic-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-xid [i386] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New binary: rust-ucd-util [amd64] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-serde [i386] (cosmic-proposed) [1.0.66-1]
-queuebot:#ubuntu-release- New: accepted rust-slab [amd64] (cosmic-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ucd-util [i386] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-xid [amd64] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-utf-8 [i386] (cosmic-proposed) [0.7.2-1]
-queuebot:#ubuntu-release- New: accepted rust-winapi-build [i386] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-winapi-i686-pc-windows-gnu [i386] (cosmic-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-either [i386] (cosmic-proposed) [1.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-fnv [i386] (cosmic-proposed) [1.0.6-1]
-queuebot:#ubuntu-release- New: accepted rust-pkg-config [s390x] (cosmic-proposed) [0.3.11-1]
-queuebot:#ubuntu-release- New: accepted rust-slab [s390x] (cosmic-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-utf-8 [amd64] (cosmic-proposed) [0.7.2-1]
-queuebot:#ubuntu-release- New: accepted rust-winapi-i686-pc-windows-gnu [amd64] (cosmic-proposed) [0.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-fnv [amd64] (cosmic-proposed) [1.0.6-1]
-queuebot:#ubuntu-release- New: accepted rust-glob [amd64] (cosmic-proposed) [0.2.11-1]
-queuebot:#ubuntu-release- New: accepted rust-glob [s390x] (cosmic-proposed) [0.2.11-1]
-queuebot:#ubuntu-release- New: accepted rust-hex [s390x] (cosmic-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted rust-httparse [s390x] (cosmic-proposed) [1.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-is-match [s390x] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-sha1 [s390x] (cosmic-proposed) [0.6.0-1]
-queuebot:#ubuntu-release- New: accepted rust-utf8-ranges [amd64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-getopts [s390x] (cosmic-proposed) [0.2.17-1]
-queuebot:#ubuntu-release- New: accepted rust-hex [amd64] (cosmic-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted rust-is-match [i386] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-itoa [s390x] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-lazy-static [i386] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-num-traits [amd64] (cosmic-proposed) [0.2.5-1]
-queuebot:#ubuntu-release- New: accepted rust-safemem [amd64] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-unicode-normalization [amd64] (cosmic-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted rust-glob [i386] (cosmic-proposed) [0.2.11-1]
-queuebot:#ubuntu-release- New: accepted rust-itoa [amd64] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-libc [i386] (cosmic-proposed) [0.2.42-1]
-queuebot:#ubuntu-release- New: accepted rust-cfg-if [amd64] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-dtoa [s390x] (cosmic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted rust-either [s390x] (cosmic-proposed) [1.5.0-1]
-queuebot:#ubuntu-release- New: accepted rust-getopts [amd64] (cosmic-proposed) [0.2.17-1]
-queuebot:#ubuntu-release- New: accepted rust-hex [i386] (cosmic-proposed) [0.3.2-1]
-queuebot:#ubuntu-release- New: accepted rust-getopts [i386] (cosmic-proposed) [0.2.17-1]
-queuebot:#ubuntu-release- New: accepted rust-bitflags [amd64] (cosmic-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted rust-bitflags [s390x] (cosmic-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted rust-bytecount [i386] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-byteorder [amd64] (cosmic-proposed) [1.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-byteorder [s390x] (cosmic-proposed) [1.2.3-1]
-queuebot:#ubuntu-release- New: accepted rust-dtoa [amd64] (cosmic-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted rust-bitflags [i386] (cosmic-proposed) [1.0.3-1]
-queuebot:#ubuntu-release- New: accepted rust-bytecount [s390x] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-cfg-if [s390x] (cosmic-proposed) [0.1.4-1]
-queuebot:#ubuntu-release- New: accepted rust-bytecount [amd64] (cosmic-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted rust-byteorder [i386] (cosmic-proposed) [1.2.3-1]
-queuebot:#ubuntu-release- New: accepted boost1.67 [amd64] (cosmic-proposed) [1.67.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted boost1.67 [armhf] (cosmic-proposed) [1.67.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted boost1.67 [ppc64el] (cosmic-proposed) [1.67.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted boost1.67 [arm64] (cosmic-proposed) [1.67.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted boost1.67 [s390x] (cosmic-proposed) [1.67.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted boost1.67 [i386] (cosmic-proposed) [1.67.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libcode-tidyall-plugin-uniquelines-perl [amd64] (cosmic-proposed) [0.000003-1]
-queuebot:#ubuntu-release- New: accepted libencode-base58-perl [amd64] (cosmic-proposed) [0.01-1]
-queuebot:#ubuntu-release- New: accepted python-ghdiff [amd64] (cosmic-proposed) [0.4-2]
-queuebot:#ubuntu-release- New: accepted libcode-tidyall-plugin-yamlfrontmatter-perl [amd64] (cosmic-proposed) [1.000001-1]
-queuebot:#ubuntu-release- New: accepted python-markdown-math [amd64] (cosmic-proposed) [0.6-1]
-queuebot:#ubuntu-release- New: accepted python-fluids [amd64] (cosmic-proposed) [0.1.72-1]
-queuebot:#ubuntu-release- New: accepted concordance [amd64] (cosmic-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted kitty [sync] (cosmic-proposed) [0.11.2-3]
-queuebot:#ubuntu-release- New: accepted octave [arm64] (cosmic-proposed) [4.4.0-3]
-queuebot:#ubuntu-release- New: accepted octave [ppc64el] (cosmic-proposed) [4.4.0-3]
-queuebot:#ubuntu-release- New: accepted julia [sync] (cosmic-proposed) [0.6.3-3]
-queuebot:#ubuntu-release- New: accepted octave [i386] (cosmic-proposed) [4.4.0-3]
-queuebot:#ubuntu-release- New: accepted octave [amd64] (cosmic-proposed) [4.4.0-3]
-queuebot:#ubuntu-release- New: accepted octave [s390x] (cosmic-proposed) [4.4.0-3]
-queuebot:#ubuntu-release- New: accepted fusioninventory-agent [amd64] (cosmic-proposed) [1:2.4.1-2]
-queuebot:#ubuntu-release- New: accepted pywws [amd64] (cosmic-proposed) [18.6.3-1]
-queuebot:#ubuntu-release- New: accepted lubuntu-artwork [amd64] (cosmic-proposed) [1.4]
-queuebot:#ubuntu-release- New: accepted pydicom [amd64] (cosmic-proposed) [1.1.0-2]
-queuebot:#ubuntu-release- New: accepted liblouis [amd64] (cosmic-proposed) [3.6.0-2]
-queuebot:#ubuntu-release- New: accepted liblouis [armhf] (cosmic-proposed) [3.6.0-2]
-queuebot:#ubuntu-release- New: accepted liblouis [ppc64el] (cosmic-proposed) [3.6.0-2]
-queuebot:#ubuntu-release- New: accepted liblouis [arm64] (cosmic-proposed) [3.6.0-2]
-queuebot:#ubuntu-release- New: accepted liblouis [s390x] (cosmic-proposed) [3.6.0-2]
-queuebot:#ubuntu-release- New: accepted liblouis [i386] (cosmic-proposed) [3.6.0-2]
-queuebot:#ubuntu-release- New: accepted granite [amd64] (cosmic-proposed) [5.0+ds-2]
-queuebot:#ubuntu-release- New: accepted granite [armhf] (cosmic-proposed) [5.0+ds-2]
-queuebot:#ubuntu-release- New: accepted granite [ppc64el] (cosmic-proposed) [5.0+ds-2]
-queuebot:#ubuntu-release- New: accepted granite [arm64] (cosmic-proposed) [5.0+ds-2]
-queuebot:#ubuntu-release- New: accepted granite [i386] (cosmic-proposed) [5.0+ds-2]
-queuebot:#ubuntu-release- New: accepted ros-ros-comm [amd64] (cosmic-proposed) [1.14.2+ds1-2]
-queuebot:#ubuntu-release- New: accepted ros-ros-comm [i386] (cosmic-proposed) [1.14.2+ds1-2]
-queuebot:#ubuntu-release- New: accepted ros-ros-comm [s390x] (cosmic-proposed) [1.14.2+ds1-2]
-queuebot:#ubuntu-release- New: accepted sweed [arm64] (cosmic-proposed) [3.2.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted sweed [i386] (cosmic-proposed) [3.2.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted sweed [s390x] (cosmic-proposed) [3.2.1+dfsg-1]
-queuebot:#ubuntu-release- New binary: kitty [ppc64el] (cosmic-proposed/none) [0.11.2-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted ros-ros-comm [armhf] (cosmic-proposed) [1.14.2+ds1-2]
-queuebot:#ubuntu-release- New: accepted sweed [amd64] (cosmic-proposed) [3.2.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted sweed [ppc64el] (cosmic-proposed) [3.2.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ros-ros-comm [ppc64el] (cosmic-proposed) [1.14.2+ds1-2]
-queuebot:#ubuntu-release- New binary: kitty [i386] (cosmic-proposed/none) [0.11.2-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted sweed [armhf] (cosmic-proposed) [3.2.1+dfsg-1]
-queuebot:#ubuntu-release- New: accepted anbox [amd64] (cosmic-proposed) [0.0~git20180612-1]
-queuebot:#ubuntu-release- New: accepted odb-api [amd64] (cosmic-proposed) [0.18.0-2]
-queuebot:#ubuntu-release- New: accepted ros-angles [amd64] (cosmic-proposed) [1.9.11-3]
-queuebot:#ubuntu-release- New: accepted ruby-ronn [amd64] (cosmic-proposed) [0.7.3-5.1]
-queuebot:#ubuntu-release- New: accepted anbox [armhf] (cosmic-proposed) [0.0~git20180612-1]
-queuebot:#ubuntu-release- New: accepted ros-ros [amd64] (cosmic-proposed) [1.14.4-2]
-queuebot:#ubuntu-release- New: accepted ros-actionlib [amd64] (cosmic-proposed) [1.11.14-2]
-queuebot:#ubuntu-release- New binary: kitty [amd64] (cosmic-proposed/none) [0.11.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: kitty [arm64] (cosmic-proposed/none) [0.11.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: kitty [armhf] (cosmic-proposed/none) [0.11.2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: julia [ppc64el] (cosmic-proposed/universe) [0.6.3-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted kitty [amd64] (cosmic-proposed) [0.11.2-3]
-queuebot:#ubuntu-release- New: accepted kitty [armhf] (cosmic-proposed) [0.11.2-3]
-queuebot:#ubuntu-release- New: accepted kitty [ppc64el] (cosmic-proposed) [0.11.2-3]
-queuebot:#ubuntu-release- New: accepted kitty [arm64] (cosmic-proposed) [0.11.2-3]
-queuebot:#ubuntu-release- New: accepted kitty [i386] (cosmic-proposed) [0.11.2-3]
-queuebot:#ubuntu-release- New binary: julia [arm64] (cosmic-proposed/universe) [0.6.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: julia [amd64] (cosmic-proposed/universe) [0.6.3-3] (no packageset)
-queuebot:#ubuntu-release- New binary: julia [i386] (cosmic-proposed/universe) [0.6.3-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted julia [amd64] (cosmic-proposed) [0.6.3-3]
-queuebot:#ubuntu-release- New: accepted julia [i386] (cosmic-proposed) [0.6.3-3]
-queuebot:#ubuntu-release- New: accepted julia [arm64] (cosmic-proposed) [0.6.3-3]
-queuebot:#ubuntu-release- New: accepted julia [ppc64el] (cosmic-proposed) [0.6.3-3]
<LocutusOfBorg> Laney, where do I download the img file to open?
<LocutusOfBorg> (I'm reading the documentation)
<LocutusOfBorg> autopkgtest-build-* fails :/
<Laney> LocutusOfBorg: Use autopkgtest-buildvm-ubuntu-cloud
<Laney> That's what I did
<Laney> You've never done this before?
<Laney> autopkgtest-buildvm-ubuntu-cloud --arch i386 -r cosmic --verbose
<tsimonq2> Laney: Bump on https://code.launchpad.net/~tsimonq2/autopkgtest-cloud/+git/bug-1654761/+merge/348972 :)
<Laney> tsimonq2: I'm away, I told you that I think
<tsimonq2> Laney: Right, sorry.
<Laney> No worries
<Laney> The tab is open, but it might be a week or so
<zhsj> hi, I file a remove request at https://bugs.launchpad.net/ubuntu/+source/anbox/+bug/1780655 I hope I'm doing right
<ubot5> Ubuntu bug 1780655 in anbox (Ubuntu) "RoM: please remove this from ubuntu, doesn't work" [Undecided,New]
-queuebot:#ubuntu-release- New binary: rust-regex-syntax [s390x] (cosmic-proposed/none) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-string-cache-shared [s390x] (cosmic-proposed/none) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shlex [s390x] (cosmic-proposed/none) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-vec-map [s390x] (cosmic-proposed/none) [0.8.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-winapi [s390x] (cosmic-proposed/none) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-regex-syntax [amd64] (cosmic-proposed/universe) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-vec-map [i386] (cosmic-proposed/universe) [0.8.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shlex [amd64] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-regex-syntax [i386] (cosmic-proposed/universe) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-string-cache-shared [amd64] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-vec-map [amd64] (cosmic-proposed/universe) [0.8.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shlex [i386] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-string-cache-shared [i386] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-winapi [amd64] (cosmic-proposed/universe) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-regex-syntax [ppc64el] (cosmic-proposed/universe) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-winapi [i386] (cosmic-proposed/universe) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shlex [ppc64el] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-string-cache-shared [ppc64el] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-winapi [ppc64el] (cosmic-proposed/universe) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-vec-map [ppc64el] (cosmic-proposed/universe) [0.8.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-regex-syntax [arm64] (cosmic-proposed/universe) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-regex-syntax [armhf] (cosmic-proposed/universe) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shlex [arm64] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-shlex [armhf] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-string-cache-shared [armhf] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-vec-map [armhf] (cosmic-proposed/universe) [0.8.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-string-cache-shared [arm64] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-winapi [armhf] (cosmic-proposed/universe) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-vec-map [arm64] (cosmic-proposed/universe) [0.8.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-winapi [arm64] (cosmic-proposed/universe) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: monero [amd64] (cosmic-proposed/universe) [0.12.3.0~dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: monero [i386] (cosmic-proposed/universe) [0.12.3.0~dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: monero [armhf] (cosmic-proposed/universe) [0.12.3.0~dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-regex-syntax [amd64] (cosmic-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-regex-syntax [armhf] (cosmic-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-regex-syntax [ppc64el] (cosmic-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-regex-syntax [arm64] (cosmic-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-regex-syntax [s390x] (cosmic-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-regex-syntax [i386] (cosmic-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-shlex [amd64] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-shlex [armhf] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-shlex [ppc64el] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-string-cache-shared [amd64] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-string-cache-shared [armhf] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-string-cache-shared [ppc64el] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-vec-map [amd64] (cosmic-proposed) [0.8.1-2]
-queuebot:#ubuntu-release- New: accepted rust-vec-map [armhf] (cosmic-proposed) [0.8.1-2]
-queuebot:#ubuntu-release- New: accepted rust-vec-map [ppc64el] (cosmic-proposed) [0.8.1-2]
-queuebot:#ubuntu-release- New: accepted rust-winapi [amd64] (cosmic-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted rust-shlex [arm64] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-shlex [s390x] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-string-cache-shared [i386] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-vec-map [arm64] (cosmic-proposed) [0.8.1-2]
-queuebot:#ubuntu-release- New: accepted rust-vec-map [s390x] (cosmic-proposed) [0.8.1-2]
-queuebot:#ubuntu-release- New: accepted rust-winapi [armhf] (cosmic-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted rust-winapi [ppc64el] (cosmic-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted rust-shlex [i386] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-string-cache-shared [s390x] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-winapi [arm64] (cosmic-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted rust-winapi [s390x] (cosmic-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted rust-string-cache-shared [arm64] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-winapi [i386] (cosmic-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted rust-vec-map [i386] (cosmic-proposed) [0.8.1-2]
#ubuntu-release 2019-07-01
-queuebot:#ubuntu-release- Unapproved: accepted ubuntustudio-installer [source] (disco-proposed) [0.04~19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted qtbase-opensource-src [source] (disco-proposed) [5.12.2+dfsg-4ubuntu1.1]
<LocutusOfBorg> hello archive admins, how do you feel about kicking out from release captagent and opensips?
<LocutusOfBorg> opensips is RC buggy and doesn't build with json-c
<LocutusOfBorg> #904660 and #918393 (opensips has the same bug with FTBFS in launchpad)
<LocutusOfBorg> captagent has #876301 #891532.
<LocutusOfBorg> I mostly fixed everything else, json-c might even migrate today, if I can get rid of syslog-ng failures on i386 and s390x
<LocutusOfBorg> they both have no reverse-deps and are out of buster
-queuebot:#ubuntu-release- Unapproved: rejected qtbase-opensource-src [source] (bionic-proposed) [5.9.5+dfsg-0ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: qtbase-opensource-src (bionic-proposed/main) [5.9.5+dfsg-0ubuntu2.1 => 5.9.5+dfsg-0ubuntu2.3] (kubuntu, qt5, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected qtbase-opensource-src [source] (bionic-proposed) [5.9.5+dfsg-0ubuntu2.3]
-queuebot:#ubuntu-release- Unapproved: accepted qtbase-opensource-src [source] (bionic-proposed) [5.9.5+dfsg-0ubuntu2.3]
-queuebot:#ubuntu-release- Unapproved: python-eventlet (disco-proposed/main) [0.24.1-0ubuntu3 => 0.24.1-0ubuntu3.1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1011.11] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1011.11]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.18.0-1024.25~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (cosmic-proposed/main) [4.18.0-1024.25] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.18.0-1024.25~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (cosmic-proposed) [4.18.0-1024.25]
-queuebot:#ubuntu-release- Unapproved: accepted lvm2 [source] (bionic-proposed) [2.02.176-4.1ubuntu3.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted lvm2 [source] (xenial-proposed) [2.02.133-1ubuntu10.1]
-queuebot:#ubuntu-release- Unapproved: accepted fonts-noto-cjk [source] (disco-proposed) [1:20190409+repack1-0ubuntu0.19.04]
-queuebot:#ubuntu-release- Unapproved: language-selector (disco-proposed/main) [0.194 => 0.194.1] (core, personal-gunnarhj)
-queuebot:#ubuntu-release- Unapproved: rejected language-selector [source] (disco-proposed) [0.194.1]
-queuebot:#ubuntu-release- Unapproved: accepted language-selector [source] (disco-proposed) [0.194.1]
-queuebot:#ubuntu-release- Unapproved: language-selector (bionic-proposed/main) [0.188.2 => 0.188.3] (core, personal-gunnarhj)
<LocutusOfBorg> where is the right place to report an issue with the diff generation?
<LocutusOfBorg> lots of packages on LP are diff from foo to foo+1 (pending)
-queuebot:#ubuntu-release- Unapproved: s390-tools (eoan-proposed/main) [2.9.0-0ubuntu3 => 2.9.0-0ubuntu4] (core)
<rbasak> LocutusOfBorg: #launchpad, though IIRC there was some talk about diffs being known to be behind
<LocutusOfBorg> ack thanks
<LocutusOfBorg> wow, s390x-tools went in unapproved... do we have freeze?
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1050.55] (kernel)
<rbasak> LocutusOfBorg: https://irclogs.ubuntu.com/2019/06/25/%23launchpad.html#t20:49 - it was a while ago
<LocutusOfBorg> rbasak, seriously one week to recover for the worker? interesting, I would have expected it to be stuck again instead
<rbasak> LocutusOfBorg: of course this is my opportunity to plug git-ubuntu through which you can get arbitrary diffs as you need :)
<rbasak> LocutusOfBorg: maybe. With Launchpad I don't know - I'm just the messenger.
-queuebot:#ubuntu-release- Unapproved: rejected language-selector [source] (bionic-proposed) [0.188.3]
<LocutusOfBorg> rbasak, opening a webpage while you are waiting for a package to build is faster :D
<LocutusOfBorg> I mean, I already have it open
<LocutusOfBorg> but yes, I do manual debdiff for now
<cjwatson> I'm not sure why this keeps going wrong.  We've had it stall a few times recently
<cjwatson> It's supposed to have resource limits
<cjwatson> Also monitoring doesn't seem to be firing
-queuebot:#ubuntu-release- Unapproved: accepted fonts-noto-cjk [source] (bionic-proposed) [1:20190409+repack1-0ubuntu0.18.04]
-queuebot:#ubuntu-release- Unapproved: accepted language-selector [source] (bionic-proposed) [0.188.3]
<cjwatson> LocutusOfBorg: It's running again now, but I guess I'll have to keep an eye on it and look into the stalls
<cjwatson> Any individual debdiff generation is supposed to be limited to no more than 10 minutes and 10 GiB of output
<cjwatson> Unless something is installing a signal handler for SIGALRM behind our backs, but I can't think what would be doing that sort of thing
<LocutusOfBorg> cjwatson, I can be your human checker
<LocutusOfBorg> :)
<cjwatson> Not anywhere near as effectively as I can when I have a window tailing the log :)
<cjwatson> But thanks for letting us know
<LocutusOfBorg> I hope it doesn't waste too much time! I prefer to waste mine ;)
<LocutusOfBorg> thanks for having a look
<cjwatson> The problem is that all you can tell is whether a given debdiff has or has not been generated; particularly in the case of a backlog, this isn't a good proxy for whether the system is doing anything
-queuebot:#ubuntu-release- Unapproved: zfs-linux (bionic-proposed/main) [0.7.5-1ubuntu16.4 => 0.7.5-1ubuntu16.6] (core)
-queuebot:#ubuntu-release- Unapproved: rejected zfs-linux [source] (bionic-proposed) [0.7.5-1ubuntu16.6]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (bionic-proposed) [0.7.5-1ubuntu16.6]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1050.55]
<juliank> sil2100: We can remove the lvm2 upload from xenial, it turns out it was not needed and does not do anything
<juliank> The broken code is in there, but we don't use it, we pass --disable-udev-systemd-background-jobs and it never gets inserted in the binary
<sil2100> juliank: huh, I guess that's good then!
<sil2100> juliank: yeah, I can drop the SRU in that case, as long as you are 100% sure that's the case
<juliank> sil2100: I am
<sil2100> juliank: ok, let me proceed with that after the DMB meeting
<vorlon> anyone know what broke today's image builds?
<Laney> some networking thing
<Laney> should be fixed now
<vorlon> ok
<seb128> vorlon, hey, do you know who might know about unmkinitramfs and multiparts initrd (and maybe utah), I've been told that ubuntu desktop ISO promotion isn't happening since early june because of it and I'm trying to figure out who is the right person that can fix that now
<vorlon> seb128: "I've been told" - who said this is the reason?  Do you have a link?
<vorlon> (link to the failing tests, which don't get published to the iso tracker, so I can never find them again since the results are push)
<seb128> vorlon, jibel wrote earlier "	it uses the wrong version of unmkinitramfs which doesn't support multipart initrds" but I didn't manage to get more details out of him (yet)
<vorlon> ok
<vorlon> powersj: ^^ we may need an upgrade to the unmkinitramfs in place on the utah testbed
<jibel> vorlon, that's fine, it broke because the compression format of the initrd changed to lz4 which was not installed on the server.
<vorlon> right
<vorlon> yes, I had a conversation about that w/ xnox once already
<jibel> it's green again now and images have been promoted
<vorlon> oh
<vorlon> \o/
<seb128> jibel, so it's fixed now? (sorry dropped from IRC so maybe I missed some status update you might have posted, though I didn't see any on irclog)
<seb128> vorlon, ok, sorry for the noise then, looks like we just failed at circulating the status update then
<jibel> and I added email notification when jobs are failing so don't wait several days to notice a failure
<seb128> who is getting them now?
<jibel> me for a couple of days, just to make sure it doesn't spam my mailbox, then whoever you want
<vorlon> powersj: ^^ sounds like it's handled, please ignore the ping
<xnox> i wanted to say "multipart initrd have been supported for a while, since we included microcode early since a long time now" but yeah lz4 would have needed a manual install of a package.
<Eickmeyer> sil2100: Thanks for the SRU on ubuntustudio-installer. Yes, you're correct, the test case is very simple for verification. That said, tested, tagged "verification-done-disco". Was simple to verify. :)
<sil2100> \o/
<LocutusOfBorg> anybody please accept s390-tools, its a no-change rebuild
<LocutusOfBorg> whenever convenient, wrt freeze :)
-queuebot:#ubuntu-release- New binary: zfs-linux [s390x] (eoan-proposed/main) [0.8.1-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: zfs-linux [amd64] (eoan-proposed/main) [0.8.1-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: zfs-linux [ppc64el] (eoan-proposed/main) [0.8.1-1ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: zfs-linux [i386] (eoan-proposed/main) [0.8.1-1ubuntu1] (core)
<LocutusOfBorg> btw I would appreciate some bison folks, helping me understand https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931302 ?
<ubot5> Debian bug 931302 in src:syslog-ng "syslog-ng: FTBFS on i386 and s390x" [Serious,Open]
-queuebot:#ubuntu-release- New: accepted jsonnet [amd64] (eoan-proposed) [0.13.0+ds-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted jsonnet [armhf] (eoan-proposed) [0.13.0+ds-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted jsonnet [ppc64el] (eoan-proposed) [0.13.0+ds-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted jsonnet [arm64] (eoan-proposed) [0.13.0+ds-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted jsonnet [s390x] (eoan-proposed) [0.13.0+ds-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted jsonnet [i386] (eoan-proposed) [0.13.0+ds-1ubuntu1]
-queuebot:#ubuntu-release- New binary: zfs-linux [arm64] (eoan-proposed/main) [0.8.1-1ubuntu1] (core)
<cjwatson> LocutusOfBorg: https://code.launchpad.net/~cjwatson/launchpad/more-robust-debdiff-timeout/+merge/369535 may help (not expecting you to review it, just FYI)
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [s390x] (eoan-proposed) [2.9.0-0ubuntu4]
<tsimonq2> infinity, vorlon: I would be curious to see the technical details related to removing the i386 arch from the archive. I have what I'd consider a smaller version of the wider archive set up with some PPAs (different PPAs acting as pockets) for Lubuntu's CI, and I'd like to remove i386 builds.
<tsimonq2> I'm considering whether I should a) hint everything in, so the "release pocket" builds supersede all uploads with i386 builds, b) remove i386 builds from everything in the "proposed" and "release" pockets and hope Britney doesn't freak out, c) b, + removing it from the arches Britney cares about.
<tsimonq2> I know it can be done a few ways, but I'm curious to see what the actual archive is doing so I can understand why the decision was made.
<tsimonq2> Perhaps I am misunderstanding the timeline on the final removal, too. So, for whenever it is.
<tsimonq2> @kc2bez: I bumped the Calamares changelog in ci/stable, fwiw.
<vorlon> tsimonq2: have you seen the announcement amending the plan?  The specifics of what will be removed are TBD in consultation with the community. https://ubuntu.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts
<tsimonq2> vorlon: My understanding was that this was going to be done via an 18.04 LXD container.
<tsimonq2> However, I've been corrected off-channel; only a few libraries will remain, yes?
<vorlon> how many libraries remain is TBD
<tsimonq2> My original question wasn't specific to i386 as much as it is working the tooling, and how y'all plan on doing that part of it.
<tsimonq2> For at least some of the packages.
<tsimonq2> (Well, am I correct to say a majority of packages in e.g. Universe will be removed?)
<vorlon> TBD ;)
<tsimonq2> ok :)
<vorlon> we're currently gathering data to make an initial proposal of what we think needs to be kept in order to support the use cases identified in the discourse threads etc
<vorlon> to support them natively on Ubuntu 19.10+, that is
<vorlon> and that will have a public discussion
<vorlon> and then this may translate into some sort of whitelist in launchpad
<tsimonq2> Let me ask a more specific question then; when we do decide to remove packages, are the involved AAs simply going to go one by one and just remove the i386 binaries from devel-release?
<vorlon> probably not one-by-one
<tsimonq2> I guess I'm curious to see how it was done in the past with, let's say, armel.
<vorlon> powerpc for a more recent example
<tsimonq2> Fair.
<vorlon> but I don't think I was directly involved in the dropping, so couldn't say how it was done
<vorlon> those might've both been dropped at the opening of the cycle rather than mid-cycle which might(?) have made it easier
<tsimonq2> What I'm going to do in my mini-archive (with PPAs) is, I'll remove i386 from arches Britney cares about, kick off a nightly, then kick off a Britney run, which should supersede all builds in the "release" PPA with builds that don't have i386.
<tsimonq2> That would make sense.
<tsimonq2> Oh, so in the archive, that would just mean a good amount of cruft is there. I thought I've seen a cleanup script for that. That'd make sense.
<ginggs> vorlon tsimonq2: I assumed it would have been cleaner to bootstrap i386 from scratch with only the packages we want, hence my question some days ago about bumping the baseline
<ginggs> I hoped that might make i386 less quirky
<ginggs> and be perform better; last time I tried i386 on a netbook, a video call in google hangouts was a slideshow
<ginggs> (it turned out the netbook in question actually supported amd64, but was shipped with win7 32-bit)
<cjwatson> tsimonq2: There's no prior art for this.  All previous architecture drops have been done for an entire architecture at a time, not part of it, and we did the actual removal with manual SQL.
<cjwatson> It is not clear that that will be the best approach here.  My instinct is that it won't be, but we'll see.
<cjwatson> For example, dropping powerpc was done using https://paste.ubuntu.com/p/3bp4xsbVPM/ (repasting from internal pastebin) after removing the architecture from the series.
-queuebot:#ubuntu-release- Unapproved: anki (disco-proposed/universe) [2.1.8+dfsg-1 => 2.1.8+dfsg-1ubuntu0.19.04.1] (no packageset)
#ubuntu-release 2019-07-02
<tsimonq2> cjwatson: That looks fun (and dangerous).
<tsimonq2> Thanks.
<LocutusOfBorg> thanks cjwatson appreciated!
-queuebot:#ubuntu-release- New binary: zfs-linux [armhf] (eoan-proposed/main) [0.8.1-1ubuntu1] (core)
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-430 (bionic-proposed/primary) [430.26-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: apache2 (bionic-proposed/main) [2.4.29-1ubuntu4.6 => 2.4.29-1ubuntu4.7] (ubuntu-server)
<tseliot> sil2100: hi, can you help with nvidia^ ,  please? It's in NEW
-queuebot:#ubuntu-release- Unapproved: apache2 (cosmic-proposed/main) [2.4.34-1ubuntu2.1 => 2.4.34-1ubuntu2.2] (ubuntu-server)
<Laney> I'm putting the gnome-shell FauxPackage back - it's still required for eoan and hopefully doesn't break xenial any more after the fix to fauxpkg.py
<cascardo> Laney: can you look at git://git.launchpad.net/~cascardo/autopkgtest-cloud today ?
<cascardo> just adding makedumpfile to the list of big packages for ppc64el
<Laney> sure, nobody did that already?
<Laney> done
-queuebot:#ubuntu-release- New: accepted zfs-linux [amd64] (eoan-proposed) [0.8.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted zfs-linux [armhf] (eoan-proposed) [0.8.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted zfs-linux [ppc64el] (eoan-proposed) [0.8.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted zfs-linux [arm64] (eoan-proposed) [0.8.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted zfs-linux [s390x] (eoan-proposed) [0.8.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted zfs-linux [i386] (eoan-proposed) [0.8.1-1ubuntu1]
<Laney> https://people.canonical.com/~ubuntu-archive/proposed-migration/log/eoan/2019-07-02/14:49:06.log "W: skipping gnome-shell/s390x as it is already in Packages_s390x"
<Laney> HMMMMMM, that doesn't look quite right
<sil2100> tseliot: sure! Just need a minut
<tseliot> sil2100: thanks!
<Laney> k, hopefully fixed ...
-queuebot:#ubuntu-release- Unapproved: accepted apache2 [source] (cosmic-proposed) [2.4.34-1ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: accepted apache2 [source] (bionic-proposed) [2.4.29-1ubuntu4.7]
<sil2100> tseliot: is there any automated tests certification could run against the new nvidia packages for additional validation?
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-430 [source] (bionic-proposed) [430.26-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-430 [amd64] (bionic-proposed/multiverse) [430.26-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-430 [i386] (bionic-proposed/multiverse) [430.26-0ubuntu0.18.04.1] (no packageset)
<Laney> OK yes, the fauxpkg.py fix seems to have worked
<sil2100> Laney: \o/
<sil2100> Laney: thanks for that, I saw it and felt relieved
<Laney> well... the last xenial run did crash but hopefully that was before my fix
<Laney> Â¬_Â¬
<teward> time to check timestamps lol :P
 * Laney is waiting for a new run
 * sil2100 is waiting as well
<sil2100> Should I publish something to xenial real fast ;p?
 * sil2100 looks for something to review
<teward> sil2100: I mean, we could publish a "hello-world-ng" that contains nothing useful just for kicks :P
<teward> but i'm sure we wouldn't want to do that :p
 * Laney just ran it manually
<Laney> ah BAH it did crash
<sil2100> :<
<Laney> what's happened here?!?!?!
<Laney> don't quite get it yet...
<Laney> https://people.canonical.com/~ubuntu-archive/proposed-migration/log/xenial/2019-07-02/16:16:41.log
<Laney> that W: at the top clearly says it was skipped
<Laney> ahhhh it ends up in xenial-proposed still, despite that
<Laney> OK, seems better...
<tseliot> sil2100: no, sorry, we don't have any such thing
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (disco-proposed) [13.2.6-0ubuntu0.19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas [source] (disco-proposed) [1:14.0.0-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron-fwaas [source] (cosmic-proposed) [1:13.0.1-0ubuntu1.1]
<teward> what's the process for a no changes rebuild in bionic-updates of nginx?  (Upstream finally told me it wouldn't hurt to rebuild now that we're on OpenSSL 1.1.1)
<teward> is it just pushing a "no change rebuild"?
<teward> (that's the only bit i'm unclear of)
<cjwatson> Yes, it's just an SRU with changelog-only changes
<cjwatson> Current version is 1.14.0-0ubuntu1.2, so bump to 1.14.0-0ubuntu1.3
<cjwatson> Otherwise follow normal SRU rules
-queuebot:#ubuntu-release- Unapproved: accepted gnome-settings-daemon [source] (bionic-proposed) [3.28.1-0ubuntu1.3]
-queuebot:#ubuntu-release- Unapproved: accepted golang-google-grpc [source] (disco-proposed) [1.6.0-3ubuntu0.19.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted kylin-nm [source] (disco-proposed) [1.0.0-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (disco-proposed) [3.32.2+git20190626-1ubuntu1~19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (disco-proposed) [3.32.2-2ubuntu1~ubuntu19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-desktop3 [source] (disco-proposed) [3.32.1-1ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-desktop3 [source] (bionic-proposed) [3.28.2-0ubuntu1.4]
-queuebot:#ubuntu-release- New binary: firefox [i386] (eoan-proposed/main) [68.0+build1-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: firefox [amd64] (eoan-proposed/main) [68.0+build1-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: firefox [s390x] (eoan-proposed/main) [68.0+build1-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-docs [source] (disco-proposed) [19.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted python-eventlet [source] (disco-proposed) [0.24.1-0ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: accepted anki [source] (disco-proposed) [2.1.8+dfsg-1ubuntu0.19.04.1]
<RAOF> Ok! My house is expected to loose power today in about 15 minutes for about 8 hours. My server obviously won't be running during that time ð
<RAOF> I'll hop on IRC from my backup laptop from a coffee shop, but I'll be less available than usual. Feel free to ping for SRU issues if I'm here, though!
 * tsimonq2 slides RAOF a coffee
<teward> cjwatson: that's what I assumed but never hurts to confirm :)  thanks.
#ubuntu-release 2019-07-03
-queuebot:#ubuntu-release- New binary: firefox [armhf] (eoan-proposed/main) [68.0+build1-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: libfm-qt (disco-proposed/universe) [0.14.1-0ubuntu2 => 0.14.1-0ubuntu2.1] (lubuntu)
<RikMills> sil2100: fair warning, I have a Plasma SRU coming (today if I have time), but by the end of the week if not. really want to get that in the 18.04.3 release on August 1st
<sil2100> RikMills: ok, thanks for the heads up
-queuebot:#ubuntu-release- Unapproved: gnome-desktop3 (bionic-proposed/main) [3.28.2-0ubuntu1.4 => 3.28.2-0ubuntu1.5] (ubuntu-desktop)
<Laney> ^- if someone has time, that's a brown paper bag upload because I uploaded a FTBFSing one previously :(
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-21.22] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-21.22] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-21.22] (core, kernel)
<apw> Laney, looking
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-21.22]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-21.22]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-21.22]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-desktop3 [source] (bionic-proposed) [3.28.2-0ubuntu1.5]
<Laney> thanks <3
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-155.182] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-155.182]
-queuebot:#ubuntu-release- New binary: firefox [arm64] (eoan-proposed/main) [68.0+build1-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: aptdaemon (xenial-proposed/main) [1.1.1+bzr982-0ubuntu14 => 1.1.1+bzr982-0ubuntu14.1] (kubuntu, ubuntu-desktop)
<juliank> ^ finally a working test suite for aptdaemon/xenial, woohoo. and frontend locking support, ofc
<juliank> :)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-55.60] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.18.0-26.27] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.18.0-26.27] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-55.60] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.18.0-26.27]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.18.0-26.27]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-55.60]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-55.60]
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1018.20] (kernel)
<jamespage> afternoon/morning
<jamespage> could the nova in disco-proposed be accepted into -updates please - I've checked through the associated 4 bug reports and the verification appears to be complete
<jamespage> we have another updated in the UNAPPROVED queue that I'd like to get accepted after that's all in
-queuebot:#ubuntu-release- Unapproved: ruby2.3 (xenial-proposed/main) [2.3.1-2~16.04.12 => 2.3.1-2~ubuntu16.04.13] (kubuntu, ubuntu-desktop)
<jamespage> also please can nova 	2:17.0.10-0ubuntu1 be rejected in the UNAPPROVED queue for bionic; the point release is included with 	2:17.0.10-0ubuntu2 which is also pending acceptance into proposed
<jamespage> bdmurray: bug 1830341 somehow had lost ubuntu-sru as a subscriber - could the uploads in bionic/UNAPPROVED for nova, horizon, heat and cinder be accepted into proposed so we can complete testing
<ubot5> bug 1830341 in nova (Ubuntu Bionic) "[SRU] queens stable releases" [High,Triaged] https://launchpad.net/bugs/1830341
<jamespage> coreycb, sahid: ^^
<coreycb> jamespage: thanks. i think we were blocked on the nova ssl verfication but if that's tested now then +1.
<jamespage> yeah I think that was the last piece of the puzzle; we need to get better about not stacking multiple SRU's on the same package; things get tangled
<coreycb> jamespage: thanks for doing that :)
<coreycb> jamespage: it'd be tough to not stack SRUs with nova
<coreycb> we'd have a long chain of SRUs at times blocked on previous ones
<coreycb> jamespage: the problem we hit with that one is some of the charms didn't support disco
<jamespage> ack
-queuebot:#ubuntu-release- Unapproved: landscape-client (cosmic-proposed/main) [18.01-0ubuntu4.2 => 18.01-0ubuntu4.3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: landscape-client (disco-proposed/main) [18.01-0ubuntu7 => 18.01-0ubuntu7.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: landscape-client (xenial-proposed/main) [16.03-0ubuntu2.16.04.6 => 16.03-0ubuntu2.16.04.7] (ubuntu-server)
<xnox> sil2100:  apw: should we forward copy 21.22 from disco-proposed to eoan-proposed?
<xnox> src:linux
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-430 [amd64] (bionic-proposed) [430.26-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-430 [i386] (bionic-proposed) [430.26-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1018.20]
-queuebot:#ubuntu-release- Unapproved: ubuntu-report (bionic-proposed/main) [1.3.1 => 1.3.2] (no packageset)
<apw> xnox, it will happen as part of my processing yes
<xnox> apw:  ack
<xnox> apw:  just eager to consume all the kernels =)
<xnox> the fresh kernel is always better
<apw> sigh
<infinity> Define "better".
<ogra> less worn out ... glossy surface ?
<infinity> Reflective, even?
<ogra> yeah but be careful its a fingerprint magnet !
<bdmurray> jamespage: I'll have a look today
<infinity> bdmurray: Oh, small wrist slap.  You releases libreoffice yesterday, but not libreoffice-l10n.  They need to be lockstep.
<infinity> (fixed this morning)
<bdmurray> infinity: whoops, I'd meant to revisit that. Doesn't sru-release have some do these packages together check?
 * rbasak was about to mention that
<rbasak> Packages tha need to be in lockstep should be in the list in sru-review now
<infinity> s/review/release/?
<infinity> RELEASE_TOGETHER_PACKAGE_GROUPS
<rbasak> Oh yes, sru_release, sorry.
<rbasak> sru-release
<bdmurray> Okay, so we should add lo and lo-l10n then?
<infinity> Should do.
<infinity> More scarily, why do the linux groups not include -signed?
<bdmurray> infinity: Can you do that otherwise it'll be an MP from me.
<infinity> I can.
<bdmurray> thanks
<rbasak> infinity: because the person who wrote the check didn't know the complete list.
<infinity> rbasak: Check.  Fixed that now.
<rbasak> Thanks!
<mdeslaur> infinity: hi! it's cosmic EoL announcement day tomorrow
<infinity> mdeslaur: And there shall be fireworks.
<infinity> I've asked the entire USA to celebrate.
<mdeslaur> infinity: oh! good idea! :)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1013.14] (no packageset)
-queuebot:#ubuntu-release- New binary: firefox [ppc64el] (eoan-proposed/main) [68.0+build1-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted firefox [amd64] (eoan-proposed) [68.0+build1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted firefox [armhf] (eoan-proposed) [68.0+build1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted firefox [ppc64el] (eoan-proposed) [68.0+build1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted firefox [arm64] (eoan-proposed) [68.0+build1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted firefox [s390x] (eoan-proposed) [68.0+build1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted firefox [i386] (eoan-proposed) [68.0+build1-0ubuntu1]
<bdmurray> jamespage: I don't see a heat in the bionic unapproved queue. Additonally, there are 2 novas. Does the newer one supersede the older one?
<jamespage> bdmurray: re nova yes 0ubuntu2 supercedes 0ubuntu1
<jamespage> coreycb: can you check on heat for me? otp
-queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (bionic-proposed) [2:12.0.7-0ubuntu1]
<coreycb> jamespage: checking
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (bionic-proposed) [3:13.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected nova [source] (bionic-proposed) [2:17.0.10-0ubuntu1]
<coreycb> jamespage: bdmurray: i'm guessing those never got sponsored for sahid's queens SRU 1830341
<coreycb> i'll follow up with sahid on those
<sahid> coreycb: if you can have a look of the neutron update to 14.0.2
<sahid> https://code.launchpad.net/~sahid-ferdjaoui/ubuntu/+source/neutron/+git/neutron
<sahid> https://launchpad.net/~sahid-ferdjaoui/+archive/ubuntu/disco-stein/+build/17217415
<sahid> coreycb: about SRU 1830341, i think heat is missing
<bdmurray> coreycb: also something is horribly wrong with the neutron upload in bionic unapproved as I just had 100 tabs opened in my browser
<bdmurray> coreycb: https://launchpadlibrarian.net/429060544/neutron_12.0.6-0ubuntu2_source.changes
<bdmurray> neat the Changes: goes back to precise
<apw> bdmurray, a -v which doesn't exist causes that kind of thign
-queuebot:#ubuntu-release- Unapproved: rejected neutron [source] (bionic-proposed) [2:12.0.6-0ubuntu2]
<bdmurray> apw: I never made that kind of mistake so wouldn't know. ;-)
<bdmurray> plenty of others though
<apw> bdmurray, i am sure i have made most of them in spades
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (bionic-proposed) [2:17.0.10-0ubuntu2]
<coreycb> bdmurray: strange, taking a look
<teward> bdmurray: are you OK with me SRU-verifying https://bugs.launchpad.net/ubuntu/+source/anki/+bug/1825722 as it's easy to verify if it works or not?  (THank you for accepting it into proposed by the way for its SRU, hope you and the rest of the SRU team didn't mind me JFDI with regards to that bug xD)
<ubot5> Ubuntu bug 1825722 in anki (Ubuntu Disco) "Anki fails to start because QWebEngineView is not defined (missing import)" [High,Fix committed]
<teward> or would you prefer to wait for the reporters to get back?
-queuebot:#ubuntu-release- Unapproved: neutron (bionic-proposed/main) [2:12.0.6-0ubuntu1 => 2:12.0.6-0ubuntu2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- New: rejected dpf-plugins [source] (eoan-proposed) [1.2-0ubuntu1]
<coreycb> bdmurray: i've uploaded neutron to bionic unapproved
<coreycb> sahid: 14.0.2 looks good. builds ok right?
<bdmurray> teward: While not ideal its always okay for the SRU uploader to verify the SRU.
<teward> bdmurray: ack.  In this case I can tell you it either "runs" or "doesn't" so :P  (Not a fan of the wildcard import, but it's that or a string of about 10 other imports...)
<teward> i'll leave it, if it doesn't get motion by end of next week I'll prod it :)
-queuebot:#ubuntu-release- Unapproved: rejected percona-toolkit [source] (xenial-proposed) [2.2.16-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (bionic-proposed) [2:12.0.6-0ubuntu2]
<bdmurray> coreycb, jamespage: let me know if heat shows up
<sahid> coreycb: yep i shared the link
<sahid> https://launchpad.net/~sahid-ferdjaoui/+archive/ubuntu/disco-stein/+build/17217415
<coreycb> sahid: ah great, sorry i missed that
<sahid> no worries :)
-queuebot:#ubuntu-release- Unapproved: neutron (disco-proposed/main) [2:14.0.1-0ubuntu1 => 2:14.0.2-0ubuntu1] (openstack, ubuntu-server)
<coreycb> sahid: jamespage: bdmurray: the heat 10.0.3 release tarball isn't available so i think we should move on without it for now. i've asked in  #openstack-stable and #openstack-heat about it. seems they've done the right things to tag it and get it released.
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [4.15.0-1037.39] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1037.39] (no packageset)
-queuebot:#ubuntu-release- Unapproved: neutron (disco-proposed/main) [2:14.0.1-0ubuntu1 => 2:14.0.2-0ubuntu1] (openstack, ubuntu-server)
<coreycb> bdmurray: we have nova and neutron uploads in the disco unapproved queue if you want to take a look. for neutron the most recent super duper one superseeds the other 2 that are in the queue.
-queuebot:#ubuntu-release- Unapproved: dkms (bionic-proposed/main) [2.3-3ubuntu9.3 => 2.3-3ubuntu9.4] (kubuntu, ubuntu-desktop)
<bdmurray> coreycb: And they supersede the nova and neutron that are already in -proposed and unverified?
<coreycb> bdmurray: neutron will supersede what's in proposed but nova 2:19.0.0-0ubuntu2.3 in proposed should be ready to release first as it's verified
<bdmurray> coreycb: Ah bug 1808951 was tagged incorrectly.
<ubot5> bug 1808951 in tripleo "python3 + Fedora + SSL + wsgi nova deployment, nova api returns RecursionError: maximum recursion depth exceeded while calling a Python object" [High,Triaged] https://launchpad.net/bugs/1808951
<coreycb> bdmurray: ah yeah i see
-queuebot:#ubuntu-release- Unapproved: dkms (disco-proposed/main) [2.6.1-4ubuntu2.1 => 2.6.1-4ubuntu2.2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New source: dpf-plugins (eoan-proposed/primary) [1.2-0ubuntu1]
<teward> ^ contains the fixes requested by sil
<Eickmeyer> ^ details in bug 1829562
<ubot5> bug 1829562 in Ubuntu Studio "[Needs Packaging] DPF-Plugins for Eoan" [Medium,Fix committed] https://launchpad.net/bugs/1829562
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (disco-proposed) [2:19.0.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected neutron [source] (disco-proposed) [2:14.0.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected neutron [source] (disco-proposed) [2:14.0.1-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (disco-proposed) [2:14.0.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1037.39]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1013.14]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1037.39]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [source] (xenial-proposed) [0.8.3-0ubuntu5]
#ubuntu-release 2019-07-04
-queuebot:#ubuntu-release- New binary: pyfribidi [s390x] (eoan-proposed/universe) [0.12.0+repack-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pyfribidi [amd64] (eoan-proposed/universe) [0.12.0+repack-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pyfribidi [i386] (eoan-proposed/universe) [0.12.0+repack-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pyfribidi [ppc64el] (eoan-proposed/universe) [0.12.0+repack-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pyfribidi [arm64] (eoan-proposed/universe) [0.12.0+repack-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pyfribidi [armhf] (eoan-proposed/universe) [0.12.0+repack-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted pyfribidi [amd64] (eoan-proposed) [0.12.0+repack-2]
-queuebot:#ubuntu-release- New: accepted pyfribidi [armhf] (eoan-proposed) [0.12.0+repack-2]
-queuebot:#ubuntu-release- New: accepted pyfribidi [ppc64el] (eoan-proposed) [0.12.0+repack-2]
-queuebot:#ubuntu-release- New: accepted pyfribidi [arm64] (eoan-proposed) [0.12.0+repack-2]
-queuebot:#ubuntu-release- New: accepted pyfribidi [s390x] (eoan-proposed) [0.12.0+repack-2]
-queuebot:#ubuntu-release- New: accepted pyfribidi [i386] (eoan-proposed) [0.12.0+repack-2]
-queuebot:#ubuntu-release- Unapproved: mesa (disco-proposed/main) [19.0.2-1ubuntu1.1 => 19.0.8-0ubuntu0~19.04.1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: bluedevil (bionic-proposed/universe) [4:5.12.7-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: breeze-gtk (bionic-proposed/universe) [5.12.7-0ubuntu0.1 => 5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: drkonqi (bionic-proposed/universe) [5.12.7-0ubuntu0.1 => 5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kde-cli-tools (bionic-proposed/universe) [4:5.12.7-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdeplasma-addons (bionic-proposed/universe) [4:5.12.7-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kinfocenter (bionic-proposed/universe) [4:5.12.7-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kscreen (bionic-proposed/universe) [4:5.12.7-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: breeze (bionic-proposed/universe) [4:5.12.7-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kde-gtk-config (bionic-proposed/universe) [4:5.12.5-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kmenuedit (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kactivitymanagerd (bionic-proposed/universe) [5.12.7-0ubuntu0.1 => 5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kscreenlocker (bionic-proposed/universe) [5.12.7-0ubuntu0.1 => 5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: khotkeys (bionic-proposed/universe) [4:5.12.7-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ksshaskpass (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kwallet-pam (bionic-proposed/universe) [4:5.12.7-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kwrited (bionic-proposed/universe) [4:5.12.6-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libksysguard (bionic-proposed/universe) [4:5.12.7-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ksysguard (bionic-proposed/universe) [4:5.12.7-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libkscreen (bionic-proposed/universe) [4:5.12.4-0ubuntu1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kwin (bionic-proposed/universe) [4:5.12.7-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: milou (bionic-proposed/universe) [4:5.12.7-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: mesa (bionic-proposed/main) [19.0.2-1ubuntu1.1~18.04.1 => 19.0.8-0ubuntu0~18.04.1] (core, xorg)
-queuebot:#ubuntu-release- Unapproved: plasma-desktop (bionic-proposed/universe) [4:5.12.7-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-nm (bionic-proposed/universe) [4:5.12.7-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-sdk (bionic-proposed/universe) [4:5.12.7-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-workspace (bionic-proposed/universe) [4:5.12.7-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: powerdevil (bionic-proposed/universe) [4:5.12.7-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: user-manager (bionic-proposed/universe) [4:5.12.7-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: oxygen (bionic-proposed/universe) [4:5.12.7-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-pa (bionic-proposed/universe) [4:5.12.7-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plymouth-kcm (bionic-proposed/universe) [5.12.7-0ubuntu0.1 => 5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-discover (bionic-proposed/universe) [5.12.7-0ubuntu0.1 => 5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: systemsettings (bionic-proposed/universe) [4:5.12.7-0ubuntu0.1 => 4:5.12.8-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-vault (bionic-proposed/universe) [5.12.7-0ubuntu0.1 => 5.12.8-0ubuntu0.1] (kubuntu)
<RikMills> sil2100: hi, Plasma for bionic now in queue
 * RikMills hides
<jibel> Could someone review ubuntu-report in bionic/unapproved queue?
<sil2100> RikMills: uh oh, ok!
<sil2100> jibel: suar
<jibel> thank you
<sil2100> RikMills: did you use bileto or something for staging the packages?
<sil2100> I see this time those are not syncs, hm
<sil2100> jibel: ok, so this basically feels like a new feature, but on the other hand I can understand why you'd want this SRUed
<sil2100> jibel: anyway, let me accept that
<RikMills> sil2100: not bileto, no
<RikMills> if your prefer them built and synced, I can do that
<sil2100> RikMills: no, that's fine
<RikMills> ok
<sil2100> I noticed people generally don't like Bileto, but I do find it convenient, since then I have all the diffs in one place to review, along with the exact list of packages - but this is okay as well
<sil2100> Especially for big things like this
<Laney> Trevinho made an MP for sru-review to handle bileto syncs btw
<Laney> https://code.launchpad.net/~3v1n0/ubuntu-archive-tools/sru-review-bileto-support/+merge/364193
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-report [source] (bionic-proposed) [1.3.2]
 * Laney is going to dump a gstreamer stack into the queue via bileto later ð
<Trevinho> Laney: get that tool feature in :P
<Laney> I'm not in the right team to merge it
<Trevinho> yeah, but you can do politics xD
<Laney> that's what I'm doing :-)
<sil2100> For such 'many packages' uploads Bileto is still very useful, very convenient ;)
<RikMills> sil2100: I thought I recalled someone complaining about syncs and having to go to bileto for the diffs. otherwise, I would have done it there
 * RikMills should have asked!
<Trevinho> yep, stack uploads is just the best way
<Laney> right, well there ^ is an improvement that should make it easier for all SRU team members to review bileto syncs
<apw> Laney, pththt, that isn't a fix for sync, just for billetto on the presumption the diff is accurate
 * apw stamps his foot impetulantly
<Laney> so you'd reject a fix until it works for any sync?
<Trevinho> people were not trusting the diffs it generated... IIRC. But I think those people should instead check the bileto code and if something is wrong, just expose the problems. Not trusting without checking isn't the way imho
<apw> Laney, no, just doing my impetulant stamping because i want a proper fix
 * sil2100 trusts the Bileto diffs since why shouldn't he
<apw> Trevinho, if you can't trust the diff one has to generate your own diff to 'check'
<sil2100> RikMills: yeah, people generally don't like syncs ;p But for me, when reviewing big batch SRUs like these, it's actually very convenient
<Laney> when has it generated a wrong diff?
<Trevinho> apw: sure... I mean, those who don't trust it, just can check. Not blaming a tool
<Trevinho> Laney: I think never... But changes sometimes are not accepted easily
<sil2100> RikMills: anyway, will get to reviewing that in a bit
<Trevinho> I mean, if it didn't work so far, in the past years we've uploaded thousands of random code lines in the archives
<Trevinho> millions... billions... worldsss
<RikMills> sil2100: thank you
<apw> and if i have to do that i have the same problem that i had before
<sil2100> Well, to be fair, I don't see a reason not to trust the Bileto generated diffs, the source is available and it's deployed under trusted and IS-controlled environment
<sil2100> I mean, I wouldn't bet any of my limbs on the correctness of the diffs as it's been ages since I looked at the code, but at the moment of writing by Robert it seemed correct ;p
<apw> sil2100, indeed, likely it is ok, i *stamp* still *stamp* want *stamp* sync support *pout*
<sil2100> apw: oh yes! That we want moar
-queuebot:#ubuntu-release- Unapproved: sane-backends (bionic-proposed/main) [1.0.27-1~experimental3ubuntu2 => 1.0.27-1~experimental3ubuntu2.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted finalrd [source] (bionic-proposed) [3~ubuntu18.04.0]
-queuebot:#ubuntu-release- New binary: finalrd [amd64] (bionic-proposed/none) [3~ubuntu18.04.0] (no packageset)
-queuebot:#ubuntu-release- New: accepted finalrd [amd64] (bionic-proposed) [3~ubuntu18.04.0]
-queuebot:#ubuntu-release- Unapproved: gstreamer-vaapi (bionic-proposed/universe) [1.14.4-1~ubuntu18.04.1 => 1.14.5-0ubuntu1~ubuntu18.04.1] (no packageset)
<sahid> coreycb: o/ about cinder 12.0.7 it should be OK now
<sahid> https://code.launchpad.net/~sahid-ferdjaoui/ubuntu/+source/cinder/+git/cinder
<sahid> https://launchpad.net/~sahid-ferdjaoui/+archive/ubuntu/bionic-queens/+build/17220986
<sahid> jamespage: ^
<xnox> apw:  i think in eoan we need an "easy" hint to try together "linux linux-meta linux-signed linux-restricted-modules debian-installer"
<xnox> i don't see them all tried together, and "linux linux-meta linux-signed" alone without "linux-restricted-modules debian-installer" will not migrate
<xnox> all are valid candidates otherwise.
<ogra> xnox, wasnt there a linux-modules now too (i just recently noticed all relevant metadata (config, System.map) is now i there)
<xnox> ogra:  linux-modules source package does not exist in ubuntu.
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1018.20~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1012.12] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1012.12]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1018.20~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted breeze [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted breeze-gtk [source] (bionic-proposed) [5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kscreenlocker [source] (bionic-proposed) [5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kwin [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted libkscreen [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kinfocenter [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kscreen [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted libksysguard [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-pa [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-workspace [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted bluedevil [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted drkonqi [source] (bionic-proposed) [5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kactivitymanagerd [source] (bionic-proposed) [5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kde-cli-tools [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kde-gtk-config [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted khotkeys [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-desktop [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-sdk [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kdeplasma-addons [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-vault [source] (bionic-proposed) [5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted ksshaskpass [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted ksysguard [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kwallet-pam [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kwrited [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted milou [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted oxygen [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-discover [source] (bionic-proposed) [5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-nm [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted plymouth-kcm [source] (bionic-proposed) [5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted powerdevil [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted systemsettings [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted user-manager [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kmenuedit [source] (bionic-proposed) [4:5.12.8-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: pulseaudio (disco-proposed/main) [1:12.2-2ubuntu3 => 1:12.2-2ubuntu3.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (trusty-proposed/main) [10ubuntu0.14.04.3 => 19.5.1~ubuntu14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: tzdata (bionic-proposed/main) [2019a-0ubuntu0.18.04 => 2019b-0ubuntu0.18.04] (core)
-queuebot:#ubuntu-release- Unapproved: tzdata (xenial-proposed/main) [2019a-0ubuntu0.16.04 => 2019b-0ubuntu0.16.04] (core)
-queuebot:#ubuntu-release- Unapproved: tzdata (cosmic-proposed/main) [2019a-0ubuntu0.18.10 => 2019b-0ubuntu0.18.10] (core)
-queuebot:#ubuntu-release- Unapproved: tzdata (disco-proposed/main) [2019a-1 => 2019b-0ubuntu0.19.04] (core)
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (disco-proposed) [2019b-0ubuntu0.19.04]
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (cosmic-proposed) [2019b-0ubuntu0.18.10]
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (bionic-proposed) [2019b-0ubuntu0.18.04]
-queuebot:#ubuntu-release- Unapproved: accepted tzdata [source] (xenial-proposed) [2019b-0ubuntu0.16.04]
#ubuntu-release 2019-07-05
<RikMills> sil2100: thank you for the plasma reviews :) commented on the SRU bug about the only rdep test fails.
<sil2100> RikMills: yay, thanks ;)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-55.60~16.04.2] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-55.60~16.04.2] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-55.60~16.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-55.60~16.04.2]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (cosmic-proposed/main) [4.18.0-1016.17] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1037.39~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (cosmic-proposed) [4.18.0-1016.17]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1037.39~16.04.1]
-queuebot:#ubuntu-release- Unapproved: mu-editor (disco-proposed/universe) [1.0.2+dfsg-2 => 1.0.2+dfsg-2ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gst-libav1.0 (bionic-proposed/universe) [1.14.4-0ubuntu1~ubuntu18.04.1 => 1.14.5-0ubuntu1~18.04.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-bad1.0 (bionic-proposed/universe) [1.14.4-1ubuntu1~ubuntu18.04.1 => 1.14.5-0ubuntu1~18.04.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-base1.0 (bionic-proposed/main) [1.14.4-1ubuntu1.1~ubuntu18.04.1 => 1.14.5-0ubuntu1~18.04.1] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-ugly1.0 (bionic-proposed/universe) [1.14.4-1~ubuntu18.04.1 => 1.14.5-0ubuntu1~18.04.1] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-rtsp-server1.0 (bionic-proposed/universe) [1.14.4-1~ubuntu18.04.1 => 1.14.5-0ubuntu1~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gstreamer-vaapi (bionic-proposed/universe) [1.14.4-1~ubuntu18.04.1 => 1.14.5-0ubuntu1~ubuntu18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-plugins-good1.0 (bionic-proposed/main) [1.14.4-1ubuntu1~ubuntu18.04.1 => 1.14.5-0ubuntu1~18.04.1] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: gstreamer-editing-services1.0 (bionic-proposed/universe) [1.14.4-1~ubuntu18.04.1 => 1.14.5-0ubuntu1~18.04.1] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: gst-python1.0 (bionic-proposed/universe) [1.14.4-1~ubuntu18.04.1 => 1.14.5-0ubuntu1~18.04.1] (ubuntustudio) (sync)
-queuebot:#ubuntu-release- Unapproved: gstreamer1.0 (bionic-proposed/main) [1.14.4-1~ubuntu18.04.1 => 1.14.5-0ubuntu1~18.04.1] (desktop-core, ubuntu-server) (sync)
<Laney> queue -Q unapproved -s bionic-proposed -m "superseded by a bileto copy" reject 21131216
<Laney> ^- if anyone would be so kind
<doko> was it intended to run all glibc triggered autopkg tests again?
<Laney> again?
<doko> the glibc upload was 16 days ago, but test were apparently retriggered
<doko> eoan	1635	2227	2235	1777	2143	1965
<doko> infinity: ^^^ ?
<Laney> oh, interesting
<Laney> there's no requester for them though
<Laney> right, proposed-migration requested those
<Laney> Which would indicate that it forgot about its previous state
<doko> what does this mean?
<doko> ugh
<Laney> I would say that the most likely thing that happened is that an archive admin removed the state file
<Laney> the other possibility is that they weren't requested before, because there was an FTBFS or something
<doko> not that many
<doko> I assume infinityand apw worked silently, doing these after the kernel update for the autopkg testers?
<Laney> I mean http://autopkgtest.ubuntu.com/packages/3/389-ds-base/eoan/amd64
<doko> ahh wait, no. these were triggered once the amd64 and i386 builds succeeded.
<Laney> that doesn't have a glibc/2.29-0ubuntu3 from the date of upload
<Laney> so I change my opinion and say that some condition just cleared
 * apw didn't do anything he is aware of to the testers or any data
<doko> right, the glibc build succeeded
<doko> on amd64 and i386
<doko> so somebody updated kernels on the *buildds*
<Laney> you should be able to see that at the top of a build log
-queuebot:#ubuntu-release- Unapproved: rejected gstreamer-vaapi [source] (bionic-proposed) [1.14.5-0ubuntu1~ubuntu18.04.1]
<apw> doko, oh, yes, there was a regression in glibc test suite triggered by a vdso bug in xenial; which got fixed
<apw> doko, so the buildds got updated (as they do regularly) to the latest kerenl; which would mean the glibc tests could pass again
<apw> and perhaps retriggering them would make sense; but i don't know how that was done
<doko> yep, and binutils and gcc-* already migrated
<doko> good
<doko> no blocker anymore for the gcc-defaults change
<cjwatson> We updated the buildds manually to the -proposed kernel, last night
<cjwatson> I didn't specifically retrigger any builds following that, although infinity might have done
<cjwatson> This was just buildd kernels, not autopkgtest units
<Laney> That makes sense: the tests were triggered by proposed-migration because the builds completed
<Laney> thx for the reject apw
<apw> ahh tests in the build succeeded so the builds actually completed; so bau
<coreycb> sahid: hey sort of on the right track there with cinder but the real error is "dh_missing: usr/etc/cinder/resource_filters.json exists in debian/tmp but is not installed to anywhere"
-queuebot:#ubuntu-release- Unapproved: tmux (bionic-proposed/main) [2.6-3ubuntu0.1 => 2.6-3ubuntu0.2] (ubuntu-server)
<coreycb> jamespage: do you think we can get rid of openstack-resource-agents?
<doko> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html doesn't see any updates
<Laney> Looks like one of the archive-reports processes has hung
 * Laney zap
<infinity> Looks like Laney got there half a second before me. :P
 * infinity goes to find a taco instead.
<Laney> Happy to have helped facilitate tacoage
<Laney> https://people.canonical.com/~ubuntu-archive/proposed-migration/log/eoan/2019-07-05/20:59:21.log <- running now
#ubuntu-release 2019-07-06
-queuebot:#ubuntu-release- New binary: bolt [amd64] (eoan-proposed/main) [0.8-2~sync1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: bolt [s390x] (eoan-proposed/main) [0.8-2~sync1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: bolt [i386] (eoan-proposed/main) [0.8-2~sync1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: bolt [ppc64el] (eoan-proposed/main) [0.8-2~sync1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: bolt [arm64] (eoan-proposed/main) [0.8-2~sync1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: bolt [armhf] (eoan-proposed/main) [0.8-2~sync1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted bolt [amd64] (eoan-proposed) [0.8-2~sync1]
-queuebot:#ubuntu-release- New: accepted bolt [armhf] (eoan-proposed) [0.8-2~sync1]
-queuebot:#ubuntu-release- New: accepted bolt [ppc64el] (eoan-proposed) [0.8-2~sync1]
-queuebot:#ubuntu-release- New: accepted bolt [arm64] (eoan-proposed) [0.8-2~sync1]
-queuebot:#ubuntu-release- New: accepted bolt [s390x] (eoan-proposed) [0.8-2~sync1]
-queuebot:#ubuntu-release- New: accepted bolt [i386] (eoan-proposed) [0.8-2~sync1]
<LocutusOfBorg> sorry is it normal that bolt-tests have been accepted in main?
<LocutusOfBorg> they want umockdev promoted...
#ubuntu-release 2019-07-07
<doko> looks like there are no autopkg tests running
<doko> at least the numbers don't go down
<Laney> They'd lost connection to rabbitmq without noticing it or something like that, restarted & working again
#ubuntu-release 2020-06-29
-queuebot:#ubuntu-release- Unapproved: libvirt (focal-proposed/main) [6.0.0-0ubuntu8.1 => 6.0.0-0ubuntu8.2] (ubuntu-server, virt)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (eoan-proposed/main) [5.3.0-1032.33] (core, kernel)
-queuebot:#ubuntu-release- Packageset: Added pocketsphinx to i386-whitelist in groovy
<vorlon> wgrant: hmm, self-copying pocketsphinx after adding it to the i386 packageset seems to be having no effect on creating a build record
<vorlon> wgrant: oh. I was missing -b, possibly why
<vorlon> wgrant: yah there we are
<vorlon> LocutusOfBorg: ^^ so pocketsphinx/i386 is building now
-queuebot:#ubuntu-release- New: accepted ulfius [arm64] (groovy-proposed) [2.6.7-2]
-queuebot:#ubuntu-release- New: accepted ulfius [ppc64el] (groovy-proposed) [2.6.7-2]
-queuebot:#ubuntu-release- New: accepted ulfius [armhf] (groovy-proposed) [2.6.7-2]
-queuebot:#ubuntu-release- New: accepted ulfius [s390x] (groovy-proposed) [2.6.7-2]
-queuebot:#ubuntu-release- New: accepted ldns [riscv64] (groovy-proposed) [1.7.1-2]
-queuebot:#ubuntu-release- New: accepted nettle [arm64] (groovy-proposed) [3.6-1]
-queuebot:#ubuntu-release- New: accepted nettle [i386] (groovy-proposed) [3.6-1]
-queuebot:#ubuntu-release- New: accepted nettle [riscv64] (groovy-proposed) [3.6-1]
-queuebot:#ubuntu-release- New: accepted nettle [amd64] (groovy-proposed) [3.6-1]
-queuebot:#ubuntu-release- New: accepted nettle [ppc64el] (groovy-proposed) [3.6-1]
-queuebot:#ubuntu-release- New: accepted nettle [armhf] (groovy-proposed) [3.6-1]
-queuebot:#ubuntu-release- New: accepted nettle [s390x] (groovy-proposed) [3.6-1]
-queuebot:#ubuntu-release- New: accepted ldns [amd64] (groovy-proposed) [1.7.1-2]
-queuebot:#ubuntu-release- New: accepted ldns [armhf] (groovy-proposed) [1.7.1-2]
-queuebot:#ubuntu-release- New: accepted ldns [s390x] (groovy-proposed) [1.7.1-2]
-queuebot:#ubuntu-release- New: accepted orcania [riscv64] (groovy-proposed) [2.1.0-4]
-queuebot:#ubuntu-release- New: accepted ldns [arm64] (groovy-proposed) [1.7.1-2]
-queuebot:#ubuntu-release- New: accepted orcania [amd64] (groovy-proposed) [2.1.0-4]
-queuebot:#ubuntu-release- New: accepted ldns [ppc64el] (groovy-proposed) [1.7.1-2]
<amurray> sil2100: can you please let me know if there is anything else you need from me to progress the libseccomp SRU (LP #1876055)?
<ubot5> Launchpad bug 1876055 in systemd (Ubuntu Eoan) "SRU: Backport 2.4.3-1ubuntu3 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base and test suite robustness" [Undecided,New] https://launchpad.net/bugs/1876055
<sil2100> amurray: hey! Looking in a moment :)
<RikMills> sil2100: would you have a sec to accept the plasma binaries in groovy New? I would like to land plasma 5.19 today, waiting in bileto, which needs them
<RikMills> when they are in, there will some more built, after which it can land
<sil2100> RikMills: ok, I don't have the context here so please bear with me here: it's expected that this is an arch: any package, right? Asking since I only see a .cmake file in the arch-dependent directory - is that cmake file arch-specific always?
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-435 [source] (bionic-proposed) [435.21-0ubuntu0.18.04.3]
<RikMills> sil2100: yes, it goes in for example /usr/lib/x86_64-linux-gnu
-queuebot:#ubuntu-release- New: accepted plasma-wayland-protocols [amd64] (groovy-proposed) [1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-wayland-protocols [armhf] (groovy-proposed) [1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-wayland-protocols [riscv64] (groovy-proposed) [1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-wayland-protocols [arm64] (groovy-proposed) [1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-wayland-protocols [s390x] (groovy-proposed) [1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-wayland-protocols [ppc64el] (groovy-proposed) [1.0-0ubuntu1]
<RikMills> sil2100: thanks
<sil2100> yw!
<RikMills> when they publish hopefully kwayland-server should build and get its new binaries
 * RikMills glares at plasma for making new required sources at the bottom of the build stack!
<LocutusOfBorg> thanks vorlon !
<sil2100> amurray: done! Actually, I only pushed those to -updates for now, but maybe I should also release it to -security? Didn't want to override your processes!
<LocutusOfBorg> sorry vorlon I forgot about this: https://launchpad.net/ubuntu/+source/sphinxbase/0.8+5prealpha+1-10
-queuebot:#ubuntu-release- New binary: kwayland-server [s390x] (groovy-proposed/universe) [5.19.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kwayland-server [amd64] (groovy-proposed/universe) [5.19.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kwayland-server [ppc64el] (groovy-proposed/universe) [5.19.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kwayland-server [arm64] (groovy-proposed/universe) [5.19.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kwayland-server [armhf] (groovy-proposed/universe) [5.19.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: systemd (eoan-proposed/main) [242-7ubuntu3.9 => 242-7ubuntu3.11] (core) (sync)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (eoan-proposed) [5.3.0-1032.33]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [sync] (eoan-proposed) [242-7ubuntu3.11]
-queuebot:#ubuntu-release- New binary: kwayland-server [riscv64] (groovy-proposed/universe) [5.19.1-0ubuntu1] (no packageset)
<Laney> I'm merging my focalisation branches to debian-cd/ubuntu-cdimage
<Laney> if any weird stuff happens it might be due to that, feel free to point me at it
<Laney> focal *compatibility* but they will be running on the existing machine which is xenial
<RikMills> sil2100: if you would be kind enough to let the kwayland-server binaries in now they have built, I can land my plasma ticket :)
<seb128> hum, why is http://autopkgtest.ubuntu.com/packages/libi/libinih/groovy/i386 listing a result from decembre done on focal?
<sil2100> RikMills: looking in a moment o/
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-418-server (bionic-proposed/primary) [418.152.00-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-418-server (focal-proposed/primary) [418.152.00-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-440-server (bionic-proposed/primary) [440.95.01-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-440-server (focal-proposed/primary) [440.95.01-0ubuntu0.20.04.1]
<sil2100> RikMills: ok, sanity checked those and they looked fine, approved
<RikMills> \o/
<RikMills> sil2100: ty :)
-queuebot:#ubuntu-release- New: accepted kwayland-server [amd64] (groovy-proposed) [5.19.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwayland-server [armhf] (groovy-proposed) [5.19.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwayland-server [riscv64] (groovy-proposed) [5.19.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwayland-server [arm64] (groovy-proposed) [5.19.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwayland-server [s390x] (groovy-proposed) [5.19.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kwayland-server [ppc64el] (groovy-proposed) [5.19.1-0ubuntu1]
<amurray> sil2100: I can do -security - thanks again :)
<Laney> seb128: every package has that, we copy the old state over at the start of each cycle
<seb128> Laney, ah ok, that makes sense I guess, I pciked another random one and it didn't seem to have it (http://autopkgtest.ubuntu.com/packages/g/glade/groovy/i386) but maybe a bad pick example
<Laney> ð¨ new cdimage branches are merged/pulled now ð¨
<Laney> seb128: we only need to do that if there's a pass result otherwise you can't get a 'regression' state
<seb128> Laney, ah ok, thanks for the explanations
<coreycb> sil2100: hello, if you happen to have any cycles we have a couple of updates in the focal unapproved queue for software-properties, cinder and python-oslo.policy.
<mdeslaur> Laney: hi! Eoan goes EoL on jul 17th, we usually send out a notice a month before, would you be the one that would do it?
<mdeslaur> let me find an example
<mdeslaur> Laney: like this: https://lists.ubuntu.com/archives/ubuntu-security-announce/2019-July/004996.html
-queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (bionic-proposed) [1:11.1-1ubuntu7.9]
<Laney> mdeslaur: yeah we know, sarnold has been pinging about it too :) https://wiki.ubuntu.com/EndOfLifeProcess says to do it at 14 days, that's what we've been planning on
<mdeslaur> Laney: ah, cool, thanks!
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-5.4 [amd64] (bionic-proposed/main) [5.4.0-1019.19~18.04.2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [5.3.0-62.56~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [5.3.0-62.56~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [arm64] (bionic-proposed/main) [5.3.0-62.56~18.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: accepted bash [source] (focal-proposed) [5.0-6ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: linux-restricted-modules-hwe (bionic-proposed/restricted) [5.3.0-62.56~18.04.1 => 5.3.0-62.56~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Packageset: Added sphinxbase to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added ltrace to i386-whitelist in groovy
<vorlon> LocutusOfBorg: turns out pocketsphinx build-depends: sphinxbase which build-depends: libblas-dev, liblapack-dev, strace, ltrace none of which are available on i386 today and two of which are on the "hell no" list
<vorlon> LocutusOfBorg: so we'll need a better solution for getting ffmpeg to build
-queuebot:#ubuntu-release- New source: golang-github-gcp-guest-logging-go (groovy-proposed/primary) [0.0~git20200113.6cbb518-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: orocos-kdl (focal-proposed/universe) [1.4.0-7build2 => 1.4.0-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-5.7 [s390x] (groovy-proposed/universe) [5.7.0-9.10] (no packageset)
<coreycb> hello, please can an SRU team member reject cinder from the focal unapproved queue? The security team is going to sponsor the upload as it contains a CVE fix.
-queuebot:#ubuntu-release- New binary: linux-signed-5.7 [amd64] (groovy-proposed/universe) [5.7.0-9.10] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-5.7 [ppc64el] (groovy-proposed/universe) [5.7.0-9.10] (no packageset)
<rbasak> ^ done
-queuebot:#ubuntu-release- Unapproved: rejected cinder [source] (focal-proposed) [2:16.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: casper (focal-proposed/main) [1.445 => 1.445.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: python-opcodes [amd64] (groovy-proposed/universe) [0.0~git20180424.6e2b0cd-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libopenshot-audio [amd64] (groovy-proposed/universe) [0.2.0+dfsg1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libopenshot-audio [s390x] (groovy-proposed/universe) [0.2.0+dfsg1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libopenshot-audio [arm64] (groovy-proposed/universe) [0.2.0+dfsg1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libopenshot-audio [armhf] (groovy-proposed/universe) [0.2.0+dfsg1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libopenshot-audio [ppc64el] (groovy-proposed/universe) [0.2.0+dfsg1-4] (no packageset)
#ubuntu-release 2020-06-30
-queuebot:#ubuntu-release- New binary: libopenshot-audio [riscv64] (groovy-proposed/universe) [0.2.0+dfsg1-4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: simple-scan (focal-proposed/main) [3.36.0-0ubuntu1 => 3.36.3-0ubuntu0.20.04.0] (ubuntu-desktop)
<cpaelzer> hi ubuntu-archive we unfortunately have an update-regression bug in bionuc-updates
<cpaelzer> it passed through all regression tests and -proposed without being spotted and now needed 12 days to surface, which might mean it is not as bad as I'm thinking atm
<cpaelzer> but never the less I wanted to ask - since we can't stop/hold it in proposed anymore - is there any way for ubuntu-archive to remove the current 1:2.11+dfsg-1ubuntu7.27 version from -updates in favor of the former .26?
<cpaelzer> we are already working on a fix, and if it turns out to take longer than 12h to send a fix to -unapproved we will send a revert
<cpaelzer> but if there is something an AA could do to reduce the number of people consuming the broken version in between that please let me know
<RAOF> I believe we can set the phasing on the bad update to 0%, which should prevent anyone else from getting the update.
<RAOF> I have not done that before, though. What is the package?
-queuebot:#ubuntu-release- New binary: ros-roscpp-core [s390x] (groovy-proposed/universe) [0.7.2-4] (no packageset)
<cpaelzer> RAOF: hi, the package is qemu 1:2.11+dfsg-1ubuntu7.27  as in https://launchpad.net/ubuntu/+source/qemu/1:2.11+dfsg-1ubuntu7.27
-queuebot:#ubuntu-release- New binary: de4dot [amd64] (groovy-proposed/universe) [3.1.41592.3405-2] (no packageset)
<cpaelzer> I wasn't sure if phasing still plays a role after it reached 100%, but yeah if that works that would be an awesome help to bridge the gap a bit
-queuebot:#ubuntu-release- New binary: ros-roscpp-core [amd64] (groovy-proposed/universe) [0.7.2-4] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-roscpp-core [ppc64el] (groovy-proposed/universe) [0.7.2-4] (no packageset)
 * RAOF believes that `change-override --percentage=0` will be the relevant rune.
-queuebot:#ubuntu-release- New binary: ros-geometric-shapes [s390x] (groovy-proposed/universe) [0.7.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-roscpp-core [arm64] (groovy-proposed/universe) [0.7.2-4] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-ros-comm [s390x] (groovy-proposed/universe) [1.15.7+ds1-2] (no packageset)
<RAOF> cpaelzer: What is the package? You've listed the version, but not the actual package name :)
<cpaelzer> I did "qemu"
-queuebot:#ubuntu-release- New binary: ros-ros-comm [amd64] (groovy-proposed/universe) [1.15.7+ds1-2] (no packageset)
<cpaelzer> I guessed you want source package names
<cpaelzer> if you want binary names let me generate a list for you
-queuebot:#ubuntu-release- New binary: ros-ros-comm [ppc64el] (groovy-proposed/universe) [1.15.7+ds1-2] (no packageset)
<RAOF> `qemu` is enough.
-queuebot:#ubuntu-release- New binary: ros-geometric-shapes [ppc64el] (groovy-proposed/universe) [0.7.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-roscpp-core [armhf] (groovy-proposed/universe) [0.7.2-4] (no packageset)
<RAOF> Hm. There may be a little bit of a delay in my IRC bouncing :)
 * RAOF struggles to find the relevant policy page for this.
<cpaelzer> I only know where to check if what we do actually works - which would be https://people.canonical.com/~ubuntu-archive/phased-updates.html and https://launchpad.net/ubuntu/bionic/amd64/qemu
-queuebot:#ubuntu-release- New binary: ros-geometric-shapes [amd64] (groovy-proposed/universe) [0.7.0-3] (no packageset)
<RAOF> Hm. Does anything have versioned depends on any of those packages?
<cpaelzer> no
<cpaelzer> this didn't introduce anything that is important to other packages, so no versioned depends
-queuebot:#ubuntu-release- New binary: ros-geometric-shapes [arm64] (groovy-proposed/universe) [0.7.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-ros-comm [arm64] (groovy-proposed/universe) [1.15.7+ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometric-shapes [armhf] (groovy-proposed/universe) [0.7.0-3] (no packageset)
<cpaelzer> RAOF: but chances are that after reaching 100% it can not be turned down again maybe?
-queuebot:#ubuntu-release- New binary: ros-ros-comm [armhf] (groovy-proposed/universe) [1.15.7+ds1-2] (no packageset)
<RAOF> I mean, it won't help anybody who has already installed it, but we can de-phase it .
<RAOF> I'm just trying to think of any reason why de-phasing it would be worse than not de-phasing it.
<cpaelzer> internally there are versioned depends - of one binary in he package to another one - could that cause issues?
<RAOF> It shouldn't; that would only be an issue if one of the binary packages wanted to be upgraded.
<RAOF> And the packages are still installable, they just won't be picked up by update-manager et al.
<RAOF> cpaelzer: phasing set to 0%; the next run of phased-updates should list it there.
<cpaelzer> like if someone updated binary A but not B version-depending on A. Then after dephasing the user could not install B as it depends on "former A". But people could revert the version of A then and be good. Should (tm) be no issue
<cpaelzer> thanks RAOF
<cpaelzer> I'll recheck in 30 min what the status of this reports
<RAOF> ubuntu-archive: I could have sworn we had documentation for handling regressions in -updates, but can't seem to find it. Maybe it should be linked from https://wiki.ubuntu.com/ArchiveAdministration?
<cpaelzer> RAOF: I did add the regression-update tag to the bug, if that means anything to the process overall
<RAOF> cpaelzer: I look forward to reviewing a fixed package in -unapproved, so we can actually fix this for the people who have already got the update :)
<cpaelzer> oh yeah rafaeldtinoco is already workign on that since a few hours
<RAOF> I don't actually know where the regression-update tag ends up triggering!
-queuebot:#ubuntu-release- New binary: ros-roscpp-core [riscv64] (groovy-proposed/universe) [0.7.2-4] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-ros-comm [riscv64] (groovy-proposed/universe) [1.15.7+ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometric-shapes [riscv64] (groovy-proposed/universe) [0.7.0-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu7.27 => 1:2.11+dfsg-1ubuntu7.28] (ubuntu-server, virt)
<cpaelzer> RAOF: bdmurray: after further checking bug 1885419 I've uploaded a revert to .27 into bionic-unapproved. rafaeldtinoco is assigned to re-evaluate the fix with some more time, hence the revert for the time being.
<ubot5> bug 1885419 in qemu (Ubuntu Bionic) "QEMU crash using virtio-scsi with iothread" [Critical,In progress] https://launchpad.net/bugs/1885419
<cpaelzer> Thanks again RAOF for the phasing changes, but since we need a few days the revert is the right way to remove the issue from bionic for the time being
<cpaelzer> RAOF: bdmurray: if one of you could help to process that into -proposed I'd appreciate
<RAOF> On it.
<cpaelzer> thank you RAOF
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (bionic-proposed) [1:2.11+dfsg-1ubuntu7.28]
<RAOF> Yup, that's a clean revert. Accepted into -proposed.
<RAOF> cpaelzer: We'll be able to skip the usual 7 days aging in -proposed for that. I'll probably be asleep when that's built & published everywhere, so feel free to ping someone else to let it through once you verify it fixes the regression and do some sanity checking.
<cpaelzer> thank you RAOF
<cpaelzer> Once it is built I'll verify and then ping bdmurray I guess as he's on SRU duty today as well and more likely to be around at that time
<cpaelzer> thanks for letting me know that we can skip/shorten the usual 7 days on this case
<apw> RAOF: I think that document is for kitten killers that need more than a revert
<apw> RAOF: but normally we can delete and reinstate the previous one, and get a fix in quick
 * cpaelzer *sniff* kitten killers made me cry a bit
<RAOF> apw: Delete, as in remove from -updates?
<apw> RAOF: if it is known bad yes, it can be removed, and the previous version copied back in
<apw> that doesn't help those already affected
<RAOF> Huh. Ok, duly noted for future reference.
<apw> it isn't ideal in any sense
<RAOF> Do we have some sort of document of âthere's a regression in -updates? Here's what can be doneâ?
-queuebot:#ubuntu-release- Unapproved: nova (focal-proposed/main) [2:21.0.0-0ubuntu0.20.04.1 => 2:21.0.0-0ubuntu0.20.04.2] (openstack, ubuntu-server)
<sil2100> RAOF, apw: what revert are we talking about?
<RAOF> qemu
<RAOF> Bug #1885419
<ubot5> bug 1885419 in qemu (Ubuntu Bionic) "QEMU crash using virtio-scsi with iothread" [Critical,Fix committed] https://launchpad.net/bugs/1885419
<sil2100> Ouch
<sil2100> And we were already playing so safe with that one...
<cpaelzer> yeah, I looked back and wondred what we could have doen better
<cpaelzer> but other than having twice as much HW&People for testing to reach further with the automated tests nothing comes to my mind
<apw> these things are often unavoidable, sadly
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [source] (bionic-proposed) [5.2.42-dfsg-0~ubuntu1.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [source] (bionic-proposed) [5.2.42-1~ubuntu1.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-guest-additions-iso [source] (bionic-proposed) [5.2.42-1~ubuntu1.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (bionic-proposed) [5.2.42-dfsg-0~ubuntu1.18.04.1]
<jibel> hi, could someone remove old binaries that prevent ubiquity 20.10.7 from migrating https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubiquity
<xnox> oem-config-check oem-config-udeb specifically from groovy-release
<xnox> ubuntu-archive ^
<seb128> k
<cpaelzer> RAOF: bdmurray: sil2100: rbasak: the revert-SRU for bug 1885419 has built and is verified. Referring to the former "We'll be able to skip the usual 7 days aging in -proposed for that." I wanted to ask if one of you is around atm to do that?
<ubot5> bug 1885419 in qemu (Ubuntu Bionic) "QEMU crash using virtio-scsi with iothread" [Critical,Fix committed] https://launchpad.net/bugs/1885419
<seb128> xnox, jibel, removed
<jibel> thanks
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-5.4 [amd64] (bionic-proposed) [5.4.0-1019.19~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [arm64] (bionic-proposed) [5.3.0-62.56~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [5.3.0-62.56~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [5.3.0-62.56~18.04.1]
<rbasak> cpaelzer: that looks fine. Are you satisfied that qemu is working generally OK from bionic-proposed - not just the specific crash being fixed?
-queuebot:#ubuntu-release- New binary: ros-interactive-markers [s390x] (groovy-proposed/universe) [1.12.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-urdf [s390x] (groovy-proposed/universe) [1.13.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-urdf [amd64] (groovy-proposed/universe) [1.13.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-vision-opencv [s390x] (groovy-proposed/universe) [1.15.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-diagnostics [s390x] (groovy-proposed/universe) [1.9.4+ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-robot-state-publisher [s390x] (groovy-proposed/universe) [1.15.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometry2 [s390x] (groovy-proposed/universe) [0.7.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-diagnostics [amd64] (groovy-proposed/universe) [1.9.4+ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometry2 [ppc64el] (groovy-proposed/universe) [0.7.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-urdf [ppc64el] (groovy-proposed/universe) [1.13.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-diagnostics [ppc64el] (groovy-proposed/universe) [1.9.4+ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-interactive-markers [ppc64el] (groovy-proposed/universe) [1.12.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-robot-state-publisher [amd64] (groovy-proposed/universe) [1.15.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-vision-opencv [amd64] (groovy-proposed/universe) [1.15.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-robot-state-publisher [ppc64el] (groovy-proposed/universe) [1.15.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometry2 [amd64] (groovy-proposed/universe) [0.7.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-opencv-apps [s390x] (groovy-proposed/universe) [2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-interactive-markers [amd64] (groovy-proposed/universe) [1.12.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometry2 [armhf] (groovy-proposed/universe) [0.7.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-urdf [armhf] (groovy-proposed/universe) [1.13.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-vision-opencv [armhf] (groovy-proposed/universe) [1.15.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-opencv-apps [ppc64el] (groovy-proposed/universe) [2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-vision-opencv [ppc64el] (groovy-proposed/universe) [1.15.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-vision-opencv [arm64] (groovy-proposed/universe) [1.15.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometry2 [arm64] (groovy-proposed/universe) [0.7.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-robot-state-publisher [armhf] (groovy-proposed/universe) [1.15.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-interactive-markers [armhf] (groovy-proposed/universe) [1.12.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-actionlib [s390x] (groovy-proposed/universe) [1.13.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-opencv-apps [amd64] (groovy-proposed/universe) [2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-robot-state-publisher [arm64] (groovy-proposed/universe) [1.15.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-diagnostics [armhf] (groovy-proposed/universe) [1.9.4+ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-perception-pcl [s390x] (groovy-proposed/universe) [1.7.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-actionlib [ppc64el] (groovy-proposed/universe) [1.13.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-interactive-markers [arm64] (groovy-proposed/universe) [1.12.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-diagnostics [arm64] (groovy-proposed/universe) [1.9.4+ds1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-urdf [arm64] (groovy-proposed/universe) [1.13.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-actionlib [amd64] (groovy-proposed/universe) [1.13.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-perception-pcl [amd64] (groovy-proposed/universe) [1.7.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-perception-pcl [ppc64el] (groovy-proposed/universe) [1.7.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-opencv-apps [armhf] (groovy-proposed/universe) [2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-opencv-apps [arm64] (groovy-proposed/universe) [2.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-actionlib [arm64] (groovy-proposed/universe) [1.13.1-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-actionlib [armhf] (groovy-proposed/universe) [1.13.1-3] (no packageset)
<cpaelzer> rbasak: from what I've tested it works as the one before
<cpaelzer> rbasak: which was the intention
<cpaelzer> rbasak: I haven't done multiple hours of tests as it is literally the same code as .26 was - only difference would be toolchain at compile time
<cpaelzer> but even that is only a few weeks different, as qemu gets updates frequently
<rbasak> cpaelzer: OK I'll release, thanks. Mind pasting that into the bug please? I just asked in the bug for fear that you'd lose my ping.
<cpaelzer> sure
<cpaelzer> there was a wave of bot posts here that scrolled a lot :-)
<rbasak> That was my thought exactly :)
<cpaelzer> rbasak: stated on the bug
-queuebot:#ubuntu-release- New binary: ros-perception-pcl [arm64] (groovy-proposed/universe) [1.7.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-perception-pcl [armhf] (groovy-proposed/universe) [1.7.1-2] (no packageset)
<cpaelzer> thank you rbasak
-queuebot:#ubuntu-release- New binary: ros-urdf [riscv64] (groovy-proposed/universe) [1.13.2-2] (no packageset)
<juliank> I guess best to ask here, but it seems that http://cdimage.ubuntu.com/daily-live/current/ is weirdly mixed
<juliank> amd64 iso is from 09 build, arm64 iso from 29 buildf
<juliank> metalink from 18th
<juliank> cjwatson vorlon, Laney: ^ to tag a random set of cdimage people from different teams :)
<juliank> pending seems I guess better
<juliank> metalink is still from 18th
-queuebot:#ubuntu-release- New binary: ros-diagnostics [riscv64] (groovy-proposed/universe) [1.9.4+ds1-2] (no packageset)
<cjwatson> not me :)
-queuebot:#ubuntu-release- New binary: ros-interactive-markers [riscv64] (groovy-proposed/universe) [1.12.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-vision-opencv [riscv64] (groovy-proposed/universe) [1.15.0+ds-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-geometry2 [riscv64] (groovy-proposed/universe) [0.7.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-robot-state-publisher [riscv64] (groovy-proposed/universe) [1.15.1-3] (no packageset)
<Laney> amd64 stuff is because it hasn't passed smoke testing since then (that's a jibel thing)
<Laney> dunno about metalink, vorlon and xnox were doing some work there, should be dropped?
<jibel> juliank, amd64 images haven't been installable for a while
<juliank> ok
<jibel> it "should" be fixed once ubiquity 20.10.7 migrates
<juliank> jibel: I'd need older images anyway, I'm trying to figure out why cpufreq scaling governor changed from powersave to performance between focal release and groovy 2020-06-09 image.
<juliank> jibel: CPUs in groovy are running at maximum turbo all the time :/
<Laney> that's why all our metrics look so great!
<juliank> heh Laney
<juliank> my fans don't turn off anymore
<juliank> they used to not run
<juliank> but with changing the governor back I'm at least at 51C now instead of 56C
<juliank> and ok I just stopped spotify and Inow down to 1 GHz and 45C
<juliank> from 3 GHz mostly and 50C
<juliank> wtf
<juliank> ah aplay triggers that too
-queuebot:#ubuntu-release- New binary: ros-opencv-apps [riscv64] (groovy-proposed/universe) [2.0.1-2] (no packageset)
<apw> juliank, the governer defaults to performance because that improves boot time, and iirc then there is a systemd unit to flip it to powersave
<xnox> Laney:  let me check re:metalink, it was incomplete, then i fixed it up, yet it's still there....
<juliank> apw: ok, then this unit seems to have stopped working or went away in groovy I suppsoe
<Laney> xnox: I suppose old ones are not pruned, given the date
 * Laney is writing python 2 :(
<xnox> Laney:  ah! yes! it got copied up.
-queuebot:#ubuntu-release- New binary: ros-actionlib [riscv64] (groovy-proposed/universe) [1.13.1-3] (no packageset)
<xnox> Laney:  so yeah, need purging
<xnox> so code is right, just needs manual cleanup
 * xnox doesn't know how to fix cdimage tree to "unpublish" things, or like "do not copy this one up"
<xnox> Laney:  but yes, .metalink files should not be published
<juliank> apw: thansk for the pointer, systemd/system/ondemand.service is gone in groovy
<apw> xnox, ^
<juliank> ddstreet removed this config
<xnox> rbalint:  ^^^^
<juliank> * Remove Ubuntu-specific ondemand.service
<juliank> xnox: rbalint is not in here, let's move to #-devel
<xnox> apw:  bjf: I wonder if that is causing "fans constantly on, even in idle" that e.g. Beret is experiencing too
<Laney> xnox: It feels preferred to get cdimage to stop copying this around to me
<apw> xnox, seems plausible
<xnox> juliank:  well, it was removed in debian too
<xnox> ah, yes by ddstreet
<xnox> &> #ubuntu-devel
<apw> xnox, perhaps because they changed the kernel there
<Laney> take the systemd thing to devel and we can talk about metalink in here
<Laney> pleaseeeee
<juliank> yes
<xnox> Laney:  do you know which bits of the code do copy up stuff?
<Laney> xnox: not right now
<Laney> i'm going to refuel and then we can look
<xnox> Laney:  maybe it's just https://paste.ubuntu.com/p/nMCSBnB22W/
-queuebot:#ubuntu-release- New binary: ros-perception-pcl [riscv64] (groovy-proposed/universe) [1.7.1-2] (no packageset)
<Beret> xnox, I'm intrigued
<Beret> what'd I miss?
<Beret> ah
<Beret> I read up
<Beret> are we not flipping the governor?
<Beret> (wow that was fun to type)
-queuebot:#ubuntu-release- New binary: linux-signed-bluefield [arm64] (focal-proposed/universe) [5.4.0-1004.6] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libseccomp (bionic-proposed/main) [2.4.3-1ubuntu3.18.04.2 => 2.4.3-1ubuntu3.18.04.3] (core)
-queuebot:#ubuntu-release- Unapproved: libseccomp (focal-proposed/main) [2.4.3-1ubuntu3.20.04.2 => 2.4.3-1ubuntu3.20.04.3] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: libseccomp (eoan-proposed/main) [2.4.3-1ubuntu3.19.10.2 => 2.4.3-1ubuntu3.19.10.3] (core)
-queuebot:#ubuntu-release- Unapproved: libseccomp (xenial-proposed/main) [2.4.3-1ubuntu3.16.04.2 => 2.4.3-1ubuntu3.16.04.3] (core)
<juliank> Beret: we moved the discussion to #devel and are tracking this in bug 1885730
<ubot5> bug 1885730 in systemd (Ubuntu) "Bring back ondemand.service or switch kernel default governor for pstate - pstate now defaults to performance governor" [Undecided,New] https://launchpad.net/bugs/1885730
<Laney> xnox: taking a peeksie
<coreycb> bdmurray: hello, if you happen to have cycles in your rota I'd like to see if we could get software-properties and python-oslo.policy into focal-proposed.
-queuebot:#ubuntu-release- New: accepted ros-actionlib [arm64] (groovy-proposed) [1.13.1-3]
-queuebot:#ubuntu-release- New: accepted ros-actionlib [riscv64] (groovy-proposed) [1.13.1-3]
-queuebot:#ubuntu-release- New: accepted ros-geometry2 [riscv64] (groovy-proposed) [0.7.2-2]
-queuebot:#ubuntu-release- New: accepted ros-opencv-apps [riscv64] (groovy-proposed) [2.0.1-2]
-queuebot:#ubuntu-release- New: accepted ros-perception-pcl [armhf] (groovy-proposed) [1.7.1-2]
-queuebot:#ubuntu-release- New: accepted ros-robot-state-publisher [riscv64] (groovy-proposed) [1.15.1-3]
-queuebot:#ubuntu-release- New: accepted ros-vision-opencv [riscv64] (groovy-proposed) [1.15.0+ds-2]
-queuebot:#ubuntu-release- New binary: libopenshot-audio [arm64] (groovy-proposed/universe) [0.2.0+dfsg1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: libopenshot-audio [s390x] (groovy-proposed/universe) [0.2.0+dfsg1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: python-opcodes [amd64] (groovy-proposed/universe) [0.0~git20180424.6e2b0cd-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted ros-actionlib [armhf] (groovy-proposed) [1.13.1-3]
-queuebot:#ubuntu-release- New: accepted ros-interactive-markers [riscv64] (groovy-proposed) [1.12.0-3]
-queuebot:#ubuntu-release- New: accepted ros-perception-pcl [riscv64] (groovy-proposed) [1.7.1-2]
-queuebot:#ubuntu-release- New binary: libopenshot-audio [amd64] (groovy-proposed/universe) [0.2.0+dfsg1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-5.7 [amd64] (groovy-proposed/universe) [5.7.0-9.10] (no packageset)
-queuebot:#ubuntu-release- New: accepted ros-diagnostics [riscv64] (groovy-proposed) [1.9.4+ds1-2]
-queuebot:#ubuntu-release- New: accepted ros-urdf [riscv64] (groovy-proposed) [1.13.2-2]
-queuebot:#ubuntu-release- New: accepted ros-perception-pcl [arm64] (groovy-proposed) [1.7.1-2]
-queuebot:#ubuntu-release- New binary: libopenshot-audio [armhf] (groovy-proposed/universe) [0.2.0+dfsg1-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted ros-actionlib [amd64] (groovy-proposed) [1.13.1-3]
-queuebot:#ubuntu-release- New: accepted ros-actionlib [s390x] (groovy-proposed) [1.13.1-3]
-queuebot:#ubuntu-release- New: accepted ros-diagnostics [armhf] (groovy-proposed) [1.9.4+ds1-2]
-queuebot:#ubuntu-release- New: accepted ros-geometry2 [armhf] (groovy-proposed) [0.7.2-2]
-queuebot:#ubuntu-release- New: accepted ros-interactive-markers [armhf] (groovy-proposed) [1.12.0-3]
-queuebot:#ubuntu-release- New: accepted ros-opencv-apps [arm64] (groovy-proposed) [2.0.1-2]
-queuebot:#ubuntu-release- New: accepted ros-perception-pcl [amd64] (groovy-proposed) [1.7.1-2]
-queuebot:#ubuntu-release- New: accepted ros-perception-pcl [s390x] (groovy-proposed) [1.7.1-2]
-queuebot:#ubuntu-release- New: accepted ros-robot-state-publisher [armhf] (groovy-proposed) [1.15.1-3]
-queuebot:#ubuntu-release- New: accepted ros-urdf [armhf] (groovy-proposed) [1.13.2-2]
-queuebot:#ubuntu-release- New: accepted ros-actionlib [ppc64el] (groovy-proposed) [1.13.1-3]
-queuebot:#ubuntu-release- New: accepted ros-geometry2 [arm64] (groovy-proposed) [0.7.2-2]
-queuebot:#ubuntu-release- New: accepted ros-opencv-apps [amd64] (groovy-proposed) [2.0.1-2]
-queuebot:#ubuntu-release- New: accepted ros-perception-pcl [ppc64el] (groovy-proposed) [1.7.1-2]
-queuebot:#ubuntu-release- New: accepted ros-urdf [arm64] (groovy-proposed) [1.13.2-2]
-queuebot:#ubuntu-release- New binary: nginx [amd64] (groovy-proposed/main) [1.18.0-3ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: nginx [armhf] (groovy-proposed/main) [1.18.0-3ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: nginx [riscv64] (groovy-proposed/main) [1.18.0-3ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: qgis [ppc64el] (groovy-proposed/universe) [3.10.7+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ros-diagnostics [arm64] (groovy-proposed) [1.9.4+ds1-2]
-queuebot:#ubuntu-release- New: accepted ros-opencv-apps [armhf] (groovy-proposed) [2.0.1-2]
-queuebot:#ubuntu-release- New: accepted ros-vision-opencv [ppc64el] (groovy-proposed) [1.15.0+ds-2]
-queuebot:#ubuntu-release- New binary: nginx [ppc64el] (groovy-proposed/main) [1.18.0-3ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: qgis [s390x] (groovy-proposed/universe) [3.10.7+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ros-interactive-markers [arm64] (groovy-proposed) [1.12.0-3]
-queuebot:#ubuntu-release- New binary: nginx [arm64] (groovy-proposed/main) [1.18.0-3ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New: accepted ros-robot-state-publisher [arm64] (groovy-proposed) [1.15.1-3]
-queuebot:#ubuntu-release- New binary: nginx [s390x] (groovy-proposed/main) [1.18.0-3ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- New: accepted ros-diagnostics [amd64] (groovy-proposed) [1.9.4+ds1-2]
-queuebot:#ubuntu-release- New: accepted ros-geometry2 [amd64] (groovy-proposed) [0.7.2-2]
-queuebot:#ubuntu-release- New: accepted ros-geometry2 [s390x] (groovy-proposed) [0.7.2-2]
-queuebot:#ubuntu-release- New: accepted ros-interactive-markers [ppc64el] (groovy-proposed) [1.12.0-3]
-queuebot:#ubuntu-release- New: accepted ros-opencv-apps [s390x] (groovy-proposed) [2.0.1-2]
-queuebot:#ubuntu-release- New: accepted ros-robot-state-publisher [ppc64el] (groovy-proposed) [1.15.1-3]
-queuebot:#ubuntu-release- New: accepted ros-urdf [ppc64el] (groovy-proposed) [1.13.2-2]
-queuebot:#ubuntu-release- New: accepted ros-vision-opencv [arm64] (groovy-proposed) [1.15.0+ds-2]
-queuebot:#ubuntu-release- New: accepted ros-diagnostics [ppc64el] (groovy-proposed) [1.9.4+ds1-2]
-queuebot:#ubuntu-release- New: accepted ros-interactive-markers [amd64] (groovy-proposed) [1.12.0-3]
-queuebot:#ubuntu-release- New: accepted ros-robot-state-publisher [amd64] (groovy-proposed) [1.15.1-3]
-queuebot:#ubuntu-release- New: accepted ros-vision-opencv [amd64] (groovy-proposed) [1.15.0+ds-2]
-queuebot:#ubuntu-release- New: accepted ros-geometry2 [ppc64el] (groovy-proposed) [0.7.2-2]
-queuebot:#ubuntu-release- New: accepted ros-robot-state-publisher [s390x] (groovy-proposed) [1.15.1-3]
-queuebot:#ubuntu-release- New: accepted ros-opencv-apps [ppc64el] (groovy-proposed) [2.0.1-2]
-queuebot:#ubuntu-release- New: accepted ros-vision-opencv [armhf] (groovy-proposed) [1.15.0+ds-2]
-queuebot:#ubuntu-release- New: accepted ros-diagnostics [s390x] (groovy-proposed) [1.9.4+ds1-2]
-queuebot:#ubuntu-release- New: accepted ros-geometric-shapes [armhf] (groovy-proposed) [0.7.0-3]
-queuebot:#ubuntu-release- New: accepted ros-interactive-markers [s390x] (groovy-proposed) [1.12.0-3]
-queuebot:#ubuntu-release- New: accepted ros-ros-comm [armhf] (groovy-proposed) [1.15.7+ds1-2]
-queuebot:#ubuntu-release- New: accepted ros-roscpp-core [riscv64] (groovy-proposed) [0.7.2-4]
-queuebot:#ubuntu-release- New: accepted ros-urdf [s390x] (groovy-proposed) [1.13.2-2]
-queuebot:#ubuntu-release- New: accepted ros-geometric-shapes [arm64] (groovy-proposed) [0.7.0-3]
-queuebot:#ubuntu-release- New: accepted ros-ros-comm [arm64] (groovy-proposed) [1.15.7+ds1-2]
-queuebot:#ubuntu-release- New: accepted ros-urdf [amd64] (groovy-proposed) [1.13.2-2]
-queuebot:#ubuntu-release- New: accepted ros-geometric-shapes [riscv64] (groovy-proposed) [0.7.0-3]
-queuebot:#ubuntu-release- New: accepted ros-vision-opencv [s390x] (groovy-proposed) [1.15.0+ds-2]
-queuebot:#ubuntu-release- New: accepted ros-ros-comm [riscv64] (groovy-proposed) [1.15.7+ds1-2]
-queuebot:#ubuntu-release- New: accepted ros-geometric-shapes [amd64] (groovy-proposed) [0.7.0-3]
-queuebot:#ubuntu-release- New: accepted ros-geometric-shapes [s390x] (groovy-proposed) [0.7.0-3]
-queuebot:#ubuntu-release- New: accepted ros-ros-comm [ppc64el] (groovy-proposed) [1.15.7+ds1-2]
-queuebot:#ubuntu-release- New: accepted ros-roscpp-core [arm64] (groovy-proposed) [0.7.2-4]
-queuebot:#ubuntu-release- New: accepted ros-geometric-shapes [ppc64el] (groovy-proposed) [0.7.0-3]
-queuebot:#ubuntu-release- New: accepted ros-ros-comm [s390x] (groovy-proposed) [1.15.7+ds1-2]
-queuebot:#ubuntu-release- New: accepted ros-ros-comm [amd64] (groovy-proposed) [1.15.7+ds1-2]
-queuebot:#ubuntu-release- New: accepted ros-roscpp-core [armhf] (groovy-proposed) [0.7.2-4]
-queuebot:#ubuntu-release- New: accepted de4dot [amd64] (groovy-proposed) [3.1.41592.3405-2]
-queuebot:#ubuntu-release- New: accepted libopenshot-audio [riscv64] (groovy-proposed) [0.2.0+dfsg1-4]
-queuebot:#ubuntu-release- New: accepted ros-roscpp-core [ppc64el] (groovy-proposed) [0.7.2-4]
-queuebot:#ubuntu-release- New: accepted libopenshot-audio [ppc64el] (groovy-proposed) [0.2.0+dfsg1-4]
-queuebot:#ubuntu-release- New: accepted ros-roscpp-core [s390x] (groovy-proposed) [0.7.2-4]
-queuebot:#ubuntu-release- New: accepted ros-roscpp-core [amd64] (groovy-proposed) [0.7.2-4]
<bdmurray> coreycb: noted
-queuebot:#ubuntu-release- Unapproved: rabbitmq-server (bionic-proposed/main) [3.8.2-0ubuntu1~ubuntu18.04.1 => 3.6.10-1ubuntu0.3] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rabbitmq-server (xenial-proposed/main) [3.5.7-1ubuntu0.16.04.3 => 3.5.7-1ubuntu0.16.04.4] (ubuntu-server)
<vorlon> juliank, Laney: yeah, metalink should be dropped, we landed changes to stop its generation but I didn't clean up the current tree
<Laney> right, I'll look into it
<Laney> I just finished upâ¢ the script to copy all the swift objects from the current to the new tenants
<vorlon> ok, thanks!
<Laney> this could take a while
<Laney> s/tenants/tenant/
<Laney> thanks wendigo for requiring me to write it in python 2
<xnox> did you see => Laney:  maybe it's just https://paste.ubuntu.com/p/nMCSBnB22W/
<xnox> i geuss you are still in python
<xnox> i geuss you are still in python2
<xnox> that is
<Laney> xnox: yeah sorry, I got distracted by ^- script, filing ticket cf ubuntu-devel and then looking for real
<Laney> nah, python thing is running now
<Laney> xnox: it's not that bit, these appear in the daily dirs too and they're not symlinks
<Laney> looking for where they are copied from
<Laney> ah is that a hardlink?
<Laney> yes
-queuebot:#ubuntu-release- Unapproved: im-config (focal-proposed/main) [0.44-1ubuntu1 => 0.44-1ubuntu1.1] (desktop-core, input-methods, personal-gunnarhj)
<Laney> xnox: ok, hopefully should fix itself over time ...
-queuebot:#ubuntu-release- New binary: rhonabwy [amd64] (groovy-proposed/universe) [0.9.11-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rhonabwy [s390x] (groovy-proposed/universe) [0.9.11-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rhonabwy [arm64] (groovy-proposed/universe) [0.9.11-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rhonabwy [armhf] (groovy-proposed/universe) [0.9.11-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rhonabwy [ppc64el] (groovy-proposed/universe) [0.9.11-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted casper [source] (focal-proposed) [1.445.1]
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (focal-proposed) [0.98.9.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-oslo.policy [source] (focal-proposed) [3.1.0-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted sshguard [source] (focal-proposed) [2.3.1-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted autofs [source] (focal-proposed) [5.1.6-2ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted autofs [source] (eoan-proposed) [5.1.5-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted autofs [source] (bionic-proposed) [5.1.2-1ubuntu3.2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-calendar [source] (focal-proposed) [3.36.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-desktop3 [source] (focal-proposed) [3.36.3.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: quassel (bionic-proposed/universe) [1:0.12.4-3ubuntu1.18.04.1 => 1:0.12.4-3ubuntu1.18.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: quassel (focal-proposed/universe) [1:0.13.1-3ubuntu2 => 1:0.13.1-3ubuntu2.1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted linux-signed-bluefield [arm64] (focal-proposed) [5.4.0-1004.6]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (focal-proposed) [3.36.1-0ubuntu0.20.04.0]
-queuebot:#ubuntu-release- Unapproved: rejected rapid-photo-downloader [source] (focal-proposed) [0.9.24-0ubuntu0.20.04.1]
<vorlon> Laney: by chance, have you looked at the tools in ubuntu-archive-tools that use update_excuses.yaml?
<vorlon> (and is it really necessary to change to .xz at the same time, as opposed to providing both compressed and uncompressed?)
<bdmurray> I wonder if I've written ".yaml-parsing" code in ubuntu-archive-tools...
<vorlon> ugh the new yaml uses 'verdict' as a key under autopkgtest to report the decision of the policy on whether or not the package can be promoted.  When every other key under autopkgtest: is a package name, and 'verdict' is a valid package name
<vorlon> who did this
-queuebot:#ubuntu-release- Unapproved: rejected jackd2 [source] (focal-proposed) [1.9.14-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New binary: lua5.4 [s390x] (groovy-proposed/none) [5.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: go-gir-generator [s390x] (groovy-proposed/none) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lua5.4 [amd64] (groovy-proposed/none) [5.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted go-gir-generator [s390x] (groovy-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted lua5.4 [s390x] (groovy-proposed) [5.4.0-1]
-queuebot:#ubuntu-release- New: accepted rhonabwy [arm64] (groovy-proposed) [0.9.11-2]
-queuebot:#ubuntu-release- New: accepted rhonabwy [ppc64el] (groovy-proposed) [0.9.11-2]
-queuebot:#ubuntu-release- New: accepted lua5.4 [amd64] (groovy-proposed) [5.4.0-1]
-queuebot:#ubuntu-release- New: accepted rhonabwy [armhf] (groovy-proposed) [0.9.11-2]
-queuebot:#ubuntu-release- New: accepted rhonabwy [amd64] (groovy-proposed) [0.9.11-2]
-queuebot:#ubuntu-release- New: accepted rhonabwy [s390x] (groovy-proposed) [0.9.11-2]
-queuebot:#ubuntu-release- New: accepted libopenshot-audio [amd64] (groovy-proposed) [0.2.0+dfsg1-4]
-queuebot:#ubuntu-release- New: accepted libopenshot-audio [armhf] (groovy-proposed) [0.2.0+dfsg1-4]
-queuebot:#ubuntu-release- New: accepted python-opcodes [amd64] (groovy-proposed) [0.0~git20180424.6e2b0cd-3]
-queuebot:#ubuntu-release- New: accepted libopenshot-audio [arm64] (groovy-proposed) [0.2.0+dfsg1-4]
-queuebot:#ubuntu-release- New: accepted libopenshot-audio [s390x] (groovy-proposed) [0.2.0+dfsg1-4]
-queuebot:#ubuntu-release- New binary: go-gir-generator [amd64] (groovy-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: perfmark-java [amd64] (groovy-proposed/universe) [0.21.0+ds-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lua5.4 [ppc64el] (groovy-proposed/universe) [5.4.0-1] (no packageset)
<RAOF> Hm. As far as I can tell, apport is showing up on component-mismatches because apport-gtk has a dependency on x-terminal-emulator, and whatever is producing component-mismatches is picking terminator as the thing which satisfies that dependency.
-queuebot:#ubuntu-release- New binary: go-gir-generator [ppc64el] (groovy-proposed/universe) [2.0.2-1] (no packageset)
<RAOF> *I* thought that packages depending on a virtual package were expected to have a dependency "$REAL_PACKAGE | $VIRTUAL_PACKAGE" in part to prevent this sort of thing?
-queuebot:#ubuntu-release- New binary: go-gir-generator [arm64] (groovy-proposed/universe) [2.0.2-1] (no packageset)
<bdmurray> IIRC part of this is due to i386 and xnox had an idea of how to fix component-mismatches
-queuebot:#ubuntu-release- New binary: go-gir-generator [armhf] (groovy-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lua5.4 [arm64] (groovy-proposed/universe) [5.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lua5.4 [armhf] (groovy-proposed/universe) [5.4.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (focal-proposed) [1:3.36.3-0ubuntu1]
#ubuntu-release 2020-07-01
-queuebot:#ubuntu-release- New: accepted go-gir-generator [armhf] (groovy-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted lua5.4 [armhf] (groovy-proposed) [5.4.0-1]
-queuebot:#ubuntu-release- New: accepted lua5.4 [arm64] (groovy-proposed) [5.4.0-1]
-queuebot:#ubuntu-release- New: accepted go-gir-generator [amd64] (groovy-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted go-gir-generator [ppc64el] (groovy-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted perfmark-java [amd64] (groovy-proposed) [0.21.0+ds-1]
-queuebot:#ubuntu-release- New: accepted go-gir-generator [arm64] (groovy-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted lua5.4 [ppc64el] (groovy-proposed) [5.4.0-1]
<vorlon> RAOF, bdmurray: in fact, $real | $virtual wouldn't help here because there are no implementations of x-terminal-emulator left in main on i386
<vorlon> and apport-gtk is installable on our full architectures, but component-mismatches doesn't know how to dtrt on i386 (which is, to not promote i386 binaries that are dependencies of arch: all packages)
-queuebot:#ubuntu-release- New binary: iddawc [ppc64el] (groovy-proposed/universe) [0.9.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: iddawc [s390x] (groovy-proposed/universe) [0.9.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: iddawc [amd64] (groovy-proposed/universe) [0.9.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: iddawc [armhf] (groovy-proposed/universe) [0.9.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: iddawc [arm64] (groovy-proposed/universe) [0.9.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-peachpy [amd64] (groovy-proposed/universe) [0.0~git20200303.f189ad2-3] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-moby-sys [amd64] (groovy-proposed/universe) [0.0~git20200630.9e8d3ad-1] (no packageset)
<tjaalton> rbasak: hi, if you're doing sru queue cleanup today, mind having a look at xorg-server for focal, it's got a high-priority bugfix for lenovo
<RAOF> Hm. Does running process-removals take more than 2 hours (and then die with a timeout) for other AAs?
<tjaalton> glade (groovy/i386) probably needs to be badtested
<Laney> vorlon: yeah I talked to elbrus / ivodd about that 'verdict' thing, apparently there's an opportunity to break the format and fix that coming up
<Laney> something something going eol something I forgot the details
<Laney> I've fixed retry-autopkgtest-regressions, let me commit that and make a merge proposal
-queuebot:#ubuntu-release- New: accepted iddawc [amd64] (groovy-proposed) [0.9.5-2]
-queuebot:#ubuntu-release- New: accepted iddawc [armhf] (groovy-proposed) [0.9.5-2]
-queuebot:#ubuntu-release- New: accepted iddawc [s390x] (groovy-proposed) [0.9.5-2]
-queuebot:#ubuntu-release- New: accepted iddawc [arm64] (groovy-proposed) [0.9.5-2]
-queuebot:#ubuntu-release- New: accepted iddawc [ppc64el] (groovy-proposed) [0.9.5-2]
<Laney> good job I tried a stable series run just now ð¬
<ginggs> would someone please review https://code.launchpad.net/~ginggs/britney/hints-ubuntu-python-pybedtools-armhf-v2/+merge/386661 and https://code.launchpad.net/~ginggs/britney/hints-ubuntu-python-loompy/+merge/386663 ?
-queuebot:#ubuntu-release- Unapproved: rejected libfprint [source] (focal-proposed) [1:1.90.2+tod1-0ubuntu1~20.04.1]
<rbasak> bdmurray: would you mind processing awscli in Eoan please, seeing as you did the other series? Did you miss that one?
<rbasak> tjaalton: ack. I'll try to get to it.
<tjaalton> rbasak: cool, thanks
-queuebot:#ubuntu-release- New: accepted nginx [amd64] (groovy-proposed) [1.18.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted nginx [armhf] (groovy-proposed) [1.18.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted nginx [riscv64] (groovy-proposed) [1.18.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [amd64] (groovy-proposed) [3.10.7+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [armhf] (groovy-proposed) [3.10.7+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [riscv64] (groovy-proposed) [3.10.7+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted nginx [arm64] (groovy-proposed) [1.18.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted nginx [s390x] (groovy-proposed) [1.18.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [ppc64el] (groovy-proposed) [3.10.7+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted nginx [ppc64el] (groovy-proposed) [1.18.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [s390x] (groovy-proposed) [3.10.7+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [arm64] (groovy-proposed) [3.10.7+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted golang-github-moby-sys [amd64] (groovy-proposed) [0.0~git20200630.9e8d3ad-1]
-queuebot:#ubuntu-release- New: accepted python-peachpy [amd64] (groovy-proposed) [0.0~git20200303.f189ad2-3]
-queuebot:#ubuntu-release- Unapproved: accepted haproxy [source] (bionic-proposed) [1.8.8-1ubuntu0.11]
-queuebot:#ubuntu-release- Unapproved: rejected open-vm-tools [source] (focal-proposed) [2:11.1.0-2~ubuntu20.04.1]
-queuebot:#ubuntu-release- Unapproved: open-vm-tools (focal-proposed/main) [2:11.0.5-4 => 2:11.1.0-2~ubuntu20.04.1] (edubuntu, ubuntu-cloud, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted open-vm-tools [source] (focal-proposed) [2:11.1.0-2~ubuntu20.04.1]
-queuebot:#ubuntu-release- New binary: open-vm-tools [amd64] (focal-proposed/main) [2:11.1.0-2~ubuntu20.04.1] (edubuntu, ubuntu-cloud, ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-drivers-common [source] (focal-proposed) [1:0.8.4~0.20.04.1]
<cpaelzer> hi ubuntu-archive - the current open-vm-tools SRU that we try to get resolved in time before 20.04.1 has added a new plugin and therefore shows up at the Focal NEW queue now
<cpaelzer> https://launchpad.net/ubuntu/focal/+queue?queue_state=0&queue_text=
<cpaelzer> I'd highly appreciate if one could take a look - accept if ok or get in touch with me if not
<seb128> cpaelzer, does the plugin need to go to main?
<cpaelzer> no
<cpaelzer> it has no deps pulling it there
<cpaelzer> to check you can see how it is in groovy
<cpaelzer> it will be the same in focal
<seb128> cpaelzer, k, binNEWed now
-queuebot:#ubuntu-release- New: accepted open-vm-tools [amd64] (focal-proposed) [2:11.1.0-2~ubuntu20.04.1]
<cpaelzer> thanks you seb128
<seb128> cpaelzer, np!
-queuebot:#ubuntu-release- Unapproved: ibus (focal-proposed/main) [1.5.22-2ubuntu2 => 1.5.22-2ubuntu2.1] (desktop-core, i386-whitelist, input-methods)
-queuebot:#ubuntu-release- New binary: rootlesskit [s390x] (groovy-proposed/universe) [0.9.5+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rootlesskit [amd64] (groovy-proposed/universe) [0.9.5+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rootlesskit [ppc64el] (groovy-proposed/universe) [0.9.5+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rootlesskit [arm64] (groovy-proposed/universe) [0.9.5+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rootlesskit [armhf] (groovy-proposed/universe) [0.9.5+ds1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rootlesskit [riscv64] (groovy-proposed/universe) [0.9.5+ds1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: wslu (focal-proposed/main) [2.3.6-0ubuntu1 => 2.3.6-0ubuntu2~20.04.0] (core)
-queuebot:#ubuntu-release- New: accepted rootlesskit [amd64] (groovy-proposed) [0.9.5+ds1-1]
-queuebot:#ubuntu-release- New: accepted rootlesskit [armhf] (groovy-proposed) [0.9.5+ds1-1]
-queuebot:#ubuntu-release- New: accepted rootlesskit [riscv64] (groovy-proposed) [0.9.5+ds1-1]
-queuebot:#ubuntu-release- New: accepted rootlesskit [arm64] (groovy-proposed) [0.9.5+ds1-1]
-queuebot:#ubuntu-release- New: accepted rootlesskit [s390x] (groovy-proposed) [0.9.5+ds1-1]
-queuebot:#ubuntu-release- New: accepted rootlesskit [ppc64el] (groovy-proposed) [0.9.5+ds1-1]
-queuebot:#ubuntu-release- New: accepted cd-boot-images-amd64 [source] (groovy-proposed) [4]
-queuebot:#ubuntu-release- New binary: cd-boot-images-amd64 [amd64] (groovy-proposed/none) [4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted qtwebengine-opensource-src [source] (focal-proposed) [5.12.8+dfsg-0ubuntu1.1]
-queuebot:#ubuntu-release- New: accepted cd-boot-images-amd64 [amd64] (groovy-proposed) [4]
<LocutusOfBorg> ROOTFS_BOOTSTRAP_INSTALL
<LocutusOfBorg> oops sorry
<rbasak> tjaalton: xorg-server: not fixed in Groovy? That is usually a requirement. And "Regression POtential" needs filling out according to https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<rbasak> tjaalton: please also explain the impact to users
<tjaalton> rbasak: glade test on i386 has been failing
<tjaalton> not due to this
<tjaalton> and ubuntu-release-upgrader was broken, fixed now.. after these it should migrate
<rbasak> tjaalton: ah, so Fix Committed? The bug says New.
<tjaalton> hmm maybe so
<rbasak> tjaalton: I still need the SRU information properly documented please.
<rbasak> [Regression potential]
<rbasak> should be low at this point
<tjaalton> modifying
<rbasak> ^ that is simply not acceptable
 * rbasak needs to run - hopefully back later
-queuebot:#ubuntu-release- Unapproved: rapid-photo-downloader (focal-proposed/universe) [0.9.22-0ubuntu1 => 0.9.24-0ubuntu0.20.04.1] (ubuntustudio)
<vorlon> ginggs: hi, what prompted the rebuild of haskell-hopenpgp again?  Since the haskell transition is now critical path for some other stuff (xnox's libffi transition), I'd rather see us hold further haskell module transitions than continue chasing our tails
<vorlon> Laney: you mentioned fixing retry-autopkgtest-tools and raising an MP, I don't see one yet?
-queuebot:#ubuntu-release- Unapproved: accepted awscli [source] (eoan-proposed) [1.18.69-1ubuntu0.19.10.1]
<Laney> vorlon: I wanted to fix sru-report too
<Laney> but.................. stupid stable run didn't finish yet
<Laney> so ok, you can have r-a-r on its own :>
<vorlon> ok :)
<vorlon> yeah sru-report takes a while to run :P
<Laney> I mean a run of new proposed-migration on a stable series
<vorlon> ah
<Laney> it kept crashing with proxy errors from swift so I made it more robust against that
<Laney> but yeah, going to be tomorrow for me
<Laney> thanks for the pre-warning that the report itself is stil
<ginggs> vorlon: did you mean to ping me about haskell-hopenpgp ?
<vorlon> ginggs: oops, I misread the changelog, sorry
<ginggs> vorlon: np
<vorlon> but also in the meantime I've worked out that it appears to be haskell-nettle itself that haskell-hopenpgp appears to be built against the wrong version of :/
<Eickmeyer> bdmurray: Reuploaded rapid-photo-downloader with the correct bug for the SRU.
-queuebot:#ubuntu-release- New binary: nvidia-settings-tesla-418 [ppc64el] (groovy-proposed/none) [418.113-3] (no packageset)
<xnox> ginggs:  vorlon: it's ugly, and there was some riscv64 babysitting to do
-queuebot:#ubuntu-release- New binary: nvidia-settings-tesla-418 [amd64] (groovy-proposed/none) [418.113-3] (no packageset)
<xnox> ginggs:  vorlon: what i can tell, is that haskell-rank2classes was only available on 2 arches, yet became a dependency of haskell-incremental-parser . I unbroke rank2classes, but now it has to jump 20 dependency levels in the transition tracker, kicking off an avelache of abi transitions of anything that used incremental-parser
<ginggs> xnox: not me :)
<xnox> haskell-rank2classes was not obvious as uninstallable, because -release was installable, and -proposed was FTBFS
<xnox> i wish transition tracker showed version skew of installability
<xnox> becuase FTBFS in -proposed is not a green tick for installable column.
<xnox> haskell-incremental-parser is level 14, so not too bad
<xnox> ginggs:  yeah, i was going to chip away at it, between conference calls
<ginggs> xnox: i mean v.orlon pinged me by mistake, but have you seen this? https://people.debian.org/~nomeata/binNMUs-haskell.txt
<ginggs> maybe we need to run that for ubuntu
<xnox> ginggs:  i have not.
<xnox> ginggs:  i don't know what it means =/ can it be run against ubuntu? but ignore i386? does that say what needs binNMU?
<xnox> i mostly just work off https://people.canonical.com/~ubuntu-archive/transitions/html/ghc.html
<vorlon> xnox: I can't work out why haskell-bytestring-show is shown as broken on the list, it tests as installable to me
<ginggs> would someone please review https://code.launchpad.net/~ginggs/britney/hints-ubuntu-python-pybedtools-armhf-v2/+merge/386661 and https://code.launchpad.net/~ginggs/britney/hints-ubuntu-python-loompy/+merge/386663 ?
<vorlon> oh or maybe I'm currently failing to test it in a groovy env :/
<vorlon> ok, abi change in one of the ghc provides that didn't get picked up yet for rebuilds; doing now
<xnox> https://bugs.launchpad.net/ubuntu/+source/viking/+bug/1885727 ubuntu-archive will help nettle transition
<ubot5> Ubuntu bug 1885727 in viking (Ubuntu) "RM viking uninstallable build-depends holding up transitions" [Undecided,Triaged]
-queuebot:#ubuntu-release- Unapproved: rejected nfs-utils [source] (bionic-proposed) [1:1.3.4-2.1ubuntu5.3]
-queuebot:#ubuntu-release- Unapproved: rejected nfs-utils [source] (eoan-proposed) [1:1.3.4-2.5ubuntu2.1]
<vorlon> rolling back haskell-patience in order to let haskell-chell build
<vorlon> also rolling back haskell-ansi-terminal for the same reason
<xnox> ubuntu-archive https://bugs.launchpad.net/ubuntu/+source/cd-boot-images/+bug/1883799 can be actioned now
<ubot5> Ubuntu bug 1883799 in cd-boot-images (Ubuntu) "RM superseded by -$arch arch:all packages" [Low,Triaged]
-queuebot:#ubuntu-release- Unapproved: less (focal-proposed/main) [551-1 => 551-1ubuntu0.1] (core, i386-whitelist)
#ubuntu-release 2020-07-02
-queuebot:#ubuntu-release- New binary: libsis-jhdf5-java [ppc64el] (groovy-proposed/universe) [19.04.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: neutron (focal-proposed/main) [2:16.0.0-0ubuntu0.20.04.1 => 2:16.0.0-0ubuntu0.20.04.2] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: python-eventlet (focal-proposed/main) [0.25.1-2build1 => 0.25.1-2ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (focal-proposed) [1.3.11-1~focal1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (focal-proposed) [1.3.11-1~focal1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (focal-proposed) [1.3.11-1~focal1]
<ginggs> would someone please review https://code.launchpad.net/~ginggs/britney/hints-ubuntu-python-pybedtools-armhf-v2/+merge/386661 and https://code.launchpad.net/~ginggs/britney/hints-ubuntu-python-loompy/+merge/386663 ?
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (focal-proposed) [2.20.11-0ubuntu27.4]
<xnox> vorlon:  i made a mistake.
<xnox> ubuntu-archive please RM haskell-ansi-wl-pprint 0.6.9-2build1 from proposed
<xnox> such that rebuild of .8 can be uploaded, to hopefully get co-installable ghc stack
<Laney> eek, focal runs of the new proposed-migration are crashing
<Laney> let me see ...
<seb128> xnox, removed
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (focal-proposed) [1:20.04.20]
<xnox> ubuntu-archive pleasee RM https://bugs.launchpad.net/ubuntu/+source/haskell-regex-tdfa-text/+bug/1886038 blocking ghc transition
<ubot5> Ubuntu bug 1886038 in haskell-regex-tdfa-text (Ubuntu) "RM haskell-regex-tdfa-text deprecated" [Critical,Triaged]
<sil2100> xnox: looking o/
<sil2100> xnox: looks legit, proceeding
<LocutusOfBorg> sil2100, do you think we can remove a couple of haskell libraries on riscv64?
<LocutusOfBorg> e.g. haskell-token-bucket
-queuebot:#ubuntu-release- Unapproved: accepted less [source] (focal-proposed) [551-1ubuntu0.1]
<xnox> LocutusOfBorg:  no, we should not.
<xnox> LocutusOfBorg:  let it be, or i was thinking to upload and make the test suite not be that time sensitive on riscv. It's not running on real hardware to expect accurate clock to get 10 Hz right
<LocutusOfBorg> please upload on debian, we don't want all the delta on haskell packages
<LocutusOfBorg> its easy, all the libs are in a single git repo
<xnox> LocutusOfBorg:   most of debian haskell is currently FTBFS and not installable as a whole, we are trying to revert a few packages to make ghc migratable.
<xnox> LocutusOfBorg:  plus riscv64 is not releasable arch in debian? did it regress there too?
<xnox> seb128:  so 8 rebuild is failing to upload into groovy-proposed, because https://launchpad.net/ubuntu/+source/haskell-ansi-wl-pprint/0.6.9-2 supposedly is there.
<xnox> not sure if i need to wait for a publishing cycle, or if the superseeded https://launchpad.net/ubuntu/+source/haskell-ansi-wl-pprint/0.6.9-2 needs to be removed from groovy-proposed (is that even a thing?!)
<LocutusOfBorg> xnox, if you disable tests on riscv64 its fine in debian too, even if just a port arch
<seb128> xnox, bah, fixed now. I removed 0.6.9-2build1 earlier but since that failed to build the 0.6.9-2 binaries were not superseeded, and removing 0.6.9-2build1 didn't remove them with it
-queuebot:#ubuntu-release- Unapproved: openldap (eoan-proposed/main) [2.4.48+dfsg-1ubuntu1.1 => 2.4.48+dfsg-1ubuntu1.2] (ubuntu-server)
<seb128> xnox, https://launchpad.net/ubuntu/+source/haskell-ansi-wl-pprint/0.6.8.2-2ubuntu1 working now
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox [source] (focal-proposed) [6.1.10-dfsg-1~ubuntu1.20.04.1]
-queuebot:#ubuntu-release- Unapproved: openldap (bionic-proposed/main) [2.4.45+dfsg-1ubuntu1.5 => 2.4.45+dfsg-1ubuntu1.6] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: openldap (xenial-proposed/main) [2.4.42+dfsg-2ubuntu3.8 => 2.4.42+dfsg-2ubuntu3.9] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-ext-pack [source] (focal-proposed) [6.1.10-1~ubuntu1.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-guest-additions-iso [source] (focal-proposed) [6.1.10-1~ubuntu1.20.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (focal-proposed) [6.1.10-dfsg-1~ubuntu1.20.04.1]
<sil2100> tjaalton: hey! You around? I was looking at the xorg-server focal SRU - I think it's good-ish, but I see there's a leftover patch in the main source directory
<sil2100> tjaalton: looks like xfree86-add-drm-modes-on-non-GTF-panels.patch is both in debian/patches and in the root directory
<sil2100> tjaalton: could you re-upload with it cleaned up?
<tjaalton> oh man
<tjaalton> sil2100: sure..
<tjaalton> *.patch is in .gitignore
<tjaalton> ...
<tjaalton> sil2100: uploaded
<sil2100> \o/
<sil2100> :)
-queuebot:#ubuntu-release- Unapproved: xorg-server (focal-proposed/main) [2:1.20.8-2ubuntu2.1 => 2:1.20.8-2ubuntu2.2] (desktop-core, i386-whitelist, xorg)
<arnatious> sil2100 got a moment for a newbie SRU/packaging question?
<sil2100> arnatious: hey! Sure
<arnatious> sil2100: https://bugs.launchpad.net/ubuntu/+source/python-flake8/+bug/1883175 is the bug in question
<ubot5> Ubuntu bug 1883175 in python-flake8 (Ubuntu) "missing support for python3.8 language features" [Undecided,New]
<sil2100> oSoMoN: hey! Looking at the librsvg SRU for focal right now - I see that the get/set_dpi_x/y symbols got removed but the ABI didn't get bumped
<arnatious> Basically a set of linters got left behind at 3.7 when python got bumped to 3.8 in focal
<sil2100> oSoMoN: is it safe? Won't this break existing applications? Shouldn't the soname be bumped?
<arnatious> sil2100: The package and its two dependencies are updated to a correct version, fixing the issue, in groovy-proposed
<sil2100> arnatious: ah, you mean for instance that python-flake8 is still 3.7.9 etc?
<arnatious> sil2100: yeah, it and its two dependencies are the 3.7.9 version
<arnatious> sil2100: a version that supports 3.8 just made it into groovy-proposed, I don't know the first thing about packaging though so following the packaging/SRU guides fell apart at
<arnatious> "To stage an upload, follow the usual process" https://wiki.ubuntu.com/StableReleaseUpdates#Staging_an_upload
<sil2100> arnatious: ok, so this does seem like it would warrant a backport from groovy to focal
<arnatious> sil2100 right - but backports don't go to everyone by default right?
<sil2100> arnatious: ah, by 'backport' I mean an SRU backport, not the 'backports' backport ;) Sorry for being a bit confusing
<sil2100> arnatious: so there are cases where we allow backporting new upstream releases of packages as SRUs for stable series, if there is enough rationale for it
<arnatious> sil2100 ah yeah that's what I was going for
<sil2100> arnatious: how it's done is usually the packaging person taking the latest version that we want to backport, add on top of it a new changelog entry with a version number that's lower than the backported version (so in case of python-flake8 that could be for instance 3.8.3-1~20.04.1 or similar), opening an SRU bug (as per the SRU process), linking it in the changelog entry and uploadng to focal
<arnatious> sil2100: gotcha, I have the bug filled up already, should I take the debs of the 3 packages and follow https://ubuntu-packaging-guide.readthedocs.io/en/latest/ubuntu-packaging-guide/fixing-a-bug.html ?
-queuebot:#ubuntu-release- Unapproved: spl-linux (bionic-proposed/universe) [0.7.5-1ubuntu2.1 => 0.7.5-1ubuntu2.2] (no packageset)
<xnox> LocutusOfBorg:  https://hackage.haskell.org/package/chell looks odd, because chell-quickcheck was not updated, and it appears to be in git as "three packages"
<xnox> LocutusOfBorg:  how do i package all three things from https://github.com/typeclasses/chell ? instead of just chell, without chell-quickcheck?
<xnox> LocutusOfBorg:  or upsstream should have released chell-quickcheck and chell-hunit too?
<oSoMoN> sil2100, hey, thanks for looking into the librsvg SRU! I *think* the symbol changes are safe and do not require a soname change, but I'll triple check and will comment on the bug
-queuebot:#ubuntu-release- Unapproved: rejected xorg-server [source] (focal-proposed) [2:1.20.8-2ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (focal-proposed) [2:1.20.8-2ubuntu2.2]
<seb128> sil2100, hey, could you move bug #1876286 to updates? quite some users are waiting on it and it was verified by several users (but they didn't change the tag so it missed your round earlier)
<ubot5> bug 1876286 in gnutls28 (Ubuntu Focal) "Evolution reports "Error performing TLS handshake: Internal error in memory allocation."" [High,Fix committed] https://launchpad.net/bugs/1876286
<sil2100> arnatious: I think that makes sense, yes! If you need those changes sponsored, subscribe ubuntu-sponsors to the bug and (I guess best) attach the debdiffs for the packages to the bug
<sil2100> seb128: looking! When I was doing publishing the tags weren't switched yet
-queuebot:#ubuntu-release- Unapproved: rejected glib-networking [source] (bionic-proposed) [2.56.1-0ubuntu1]
<seb128> sil2100, right, I switched them today, the users who tested didn't do it
<oSoMoN> sil2100, https://bugs.launchpad.net/ubuntu/+source/librsvg/+bug/1884326/comments/5
<ubot5> Ubuntu bug 1884326 in librsvg (Ubuntu Focal) "SRU the current 2.48.7 stable update" [High,Incomplete]
<sil2100> oSoMoN: excellent, thanks for the investigation!
<LocutusOfBorg> xnox, why do you need them?
<LocutusOfBorg> and yes, I guess they should have released 3 packages
<LocutusOfBorg> but if you want to join #debian-haskell, even better
<LocutusOfBorg> and on package-plan you can see why cell is sad
<LocutusOfBorg> https://salsa.debian.org/haskell-team/package-plan/-/blob/master/packages.txt
<LocutusOfBorg> and lots of new ghc libraries are waiting debian/new queue
-queuebot:#ubuntu-release- Unapproved: accepted librsvg [source] (focal-proposed) [2.48.7-1ubuntu0.20.04.1]
<seb128> sil2100, thanks!
<sil2100> seb128: I see the xenial failed ADT tests are now good, releasing that as well!
<seb128> sil2100, thanks! and yeah, amurray fixed those tests in the glib-networking security update (I rejected the bionic SRU in the queue for that then since it was superseeded by that upload)
<arnatious> sil2100: should I attach the debdiff between 3.8.3-1 and 3.8.3~20.04.1
<arnatious> sil2100: or should I attach between the one currently in focal, i.e. between 3.7.9-3 and 3.8.3~20.04.1
<arnatious> I'm guessing the latter
<xnox> LocutusOfBorg:  well, it's blocking ghc migration. So i either need to remove the now FTBFS chell-quick.... or i need a new one.
<sil2100> arnatious: against the current one in focal, yes :)
<xnox> LocutusOfBorg:  if it's unused, why is it in debian & ubuntu? =)
<LocutusOfBorg> I don't remember honestly but package_plan should contain why it was packaged and who needs it
<LocutusOfBorg> in any case, if we move the conversation to #debian-haskell, we can avoid headaches!
-queuebot:#ubuntu-release- New binary: linux-signed-5.7 [s390x] (groovy-proposed/universe) [5.7.0-14.15] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-5.6 [amd64] (focal-proposed/main) [5.6.0-1019.19] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-5.7 [amd64] (groovy-proposed/universe) [5.7.0-14.15] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-5.7 [ppc64el] (groovy-proposed/universe) [5.7.0-14.15] (no packageset)
<arnatious> sil2100: uploaded the three debdiffs, anything else I need to do?
<sil2100> arnatious: did you subscribe ubuntu-sponsors?
<sil2100> Someone will try getting to those and sponsoring them for you - also, you can try poking someone directly for sponsorship too!
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-5.6 [amd64] (focal-proposed) [5.6.0-1019.19]
<arnatious> sil2100: brian's bot did the subscribing for me
<arnatious> sil2100: I don't need to push anything with bazaar or dput anything now do I?
<sil2100> arnatious: do you have upload rights to Ubuntu?
<arnatious> sil2100: uh I mean I'm in the Canonical team if that grants anything but have never touched packaging before
<sil2100> arnatious: that's not enough! ;) To upload to the Ubuntu archive you have to be an ubuntu-core-dev or motu
<sil2100> arnatious: anyway, now this should be in theory enough - you can try poking around people with upload rights to sponsor those for you
<sil2100> And then I can review them from the SRU queue
<arnatious> sil2100: Hmm badger jdstrand you say?
<jdstrand> arnatious: someone from ubuntu-sponsors will review the debdiffs and upload on your behalf in due course. if this is an emergency, let's take the conversation elsewhere and we can discuss if I should pivot to this and sponsor for you
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-418-server [source] (focal-proposed) [418.152.00-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-440-server [source] (focal-proposed) [440.95.01-0ubuntu0.20.04.1]
<vorlon> xnox: do you know why the tracker says haskell-optparse-applicative is broken, but I can install it in a groovy env here?
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-418-server [amd64] (focal-proposed/none) [418.152.00-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-418-server [amd64] (focal-proposed) [418.152.00-0ubuntu0.20.04.1]
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-440-server [amd64] (focal-proposed/multiverse) [440.95.01-0ubuntu0.20.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-440-server [amd64] (focal-proposed) [440.95.01-0ubuntu0.20.04.1]
<xnox> vorlon:  not for me.
<xnox> apt install ghc libghc-optparse-applicative-dev libghc-optparse-applicative-prof libghc-optparse-applicative-doc
<xnox> libghc-optparse-applicative-dev : Depends: libghc-ansi-wl-pprint-dev-0.6.9-16270 but it is not installable
<vorlon> ah I probably failed to update apt indices after ansi-wl-pprint was rebuilt
<vorlon> thanks
<xnox> vorlon:  needs rebuild against downgraded haskell-ansi-wl-pprint such that it uses 0.6.8 again?
<vorlon> yeah
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-440-server [source] (bionic-proposed) [440.95.01-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-440-server [i386] (bionic-proposed/none) [440.95.01-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-440-server [amd64] (bionic-proposed/none) [440.95.01-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-418-server [source] (bionic-proposed) [418.152.00-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-440-server [amd64] (bionic-proposed) [440.95.01-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-418-server [i386] (bionic-proposed/none) [418.152.00-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: nvidia-graphics-drivers-418-server [amd64] (bionic-proposed/none) [418.152.00-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-418-server [amd64] (bionic-proposed) [418.152.00-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-418-server [i386] (bionic-proposed) [418.152.00-0ubuntu0.18.04.1]
<vorlon> sil2100, Laney: opinions on https://code.launchpad.net/~vorlon/ubuntu-archive-tools/close-EOL-bugs/+merge/386770 ?
<vorlon> (and dear God, why was there no tool for this previously? I don't need to be closing 290 bug tasks by hand)
<vorlon> bdmurray: ^^ also you :)
<vorlon> bdmurray: also, is this entry in the EOL checklist still accurate? "Update submit.py in https://code.launchpad.net/~daisy-pluckers/daisy/trunk to reject crashes from the EoL release, which will also increment a counter for that specific release e.g. unsupported.eol_raring."
<vorlon> bdmurray: ah, the code moved to utils.py, so I'll fix the checklist
<bdmurray> vorlon: yeah
<vorlon> bdmurray: and do we have a script somewhere that unsubscribes teams from packages which are no longer in main or restricted for supported releases?
<bdmurray> vorlon: I'd add a comment saying something about just closing the end of life release task not the bug in general.
<vorlon> bdmurray: in the code?
<bdmurray> yes
<vorlon> """Close out remaining open bug tasks in Launchpad for an EOL series."""
<vorlon> is that not sufficient?
<bdmurray> bug.add_comment()
<bdmurray> or something like that
<vorlon> oh, you mean adding a comment to the bug
<bdmurray> I found this in my home dir https://pastebin.ubuntu.com/p/8G5Tkkfn4v/
-queuebot:#ubuntu-release- New binary: build-essential [amd64] (groovy-proposed/main) [12.8ubuntu3] (core, i386-whitelist)
<bdmurray> lpl_common is from ubuntu-qa-tools
<vorlon> bdmurray: added code to post a comment; how's that?
<vorlon> bdmurray: seems like that could trade lpl_common for launchpadlib, and be added to ubuntu-archive-tools?
<vorlon> bdmurray: oh but this also doesn't calculate what packages the teams need to be unsubscribed from :/
<bdmurray> vorlon: ah, you've said so many words I couldn't retain them all
<bdmurray> I'd expand EOL rather than using "jargon".
<vorlon> bdmurray: fixed
<vorlon> rolling back haskell-vector-space to let haskell-vector-space-points build
<vorlon> rolling back haskell-concurrent-output, because the -proposed version needs the newer haskell-ansi-terminal that was rolled back
<vorlon> huh haskell-vector-space-points still ftbfs, so bringing haskell-vector-space back
-queuebot:#ubuntu-release- New: accepted linux-signed-5.7 [amd64] (groovy-proposed) [5.7.0-14.15]
-queuebot:#ubuntu-release- New: accepted linux-signed-5.7 [s390x] (groovy-proposed) [5.7.0-14.15]
-queuebot:#ubuntu-release- New: accepted linux-signed-5.7 [ppc64el] (groovy-proposed) [5.7.0-14.15]
<xnox> ubuntu-archive "Notice(queuebot): New binary: build-essential [amd64] (groovy-proposed/main) [12.8ubuntu3] (core, i386-whitelist)" for being able to use mk-sbuild --target riscv64
-queuebot:#ubuntu-release- New: accepted build-essential [amd64] (groovy-proposed) [12.8ubuntu3]
#ubuntu-release 2020-07-03
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-63.57] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-63.57] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-63.57] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.3.0-63.57] (core, kernel)
-queuebot:#ubuntu-release- New binary: ruby-valid-email [amd64] (groovy-proposed/universe) [0.1.3-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ipxe (focal-proposed/main) [1.0.0+git-20190109.133f4c4-0ubuntu3 => 1.0.0+git-20190109.133f4c4-0ubuntu3.1] (ubuntu-desktop, ubuntu-server)
<vorlon> rolling back haskell-tasty-hunit, knock-on effect of rolling back haskell-tasty, which was rolled back due to haskell-ansi-terminal
-queuebot:#ubuntu-release- Unapproved: libpcap (bionic-proposed/main) [1.8.1-6ubuntu1.18.04.1 => 1.8.1-6ubuntu1.18.04.2] (core)
-queuebot:#ubuntu-release- Unapproved: xorg-server-hwe-18.04 (bionic-proposed/main) [2:1.20.8-2ubuntu2.1~18.04.1 => 2:1.20.8-2ubuntu2.2~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: zimlib [amd64] (groovy-proposed/universe) [6.1.3-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: zimlib [ppc64el] (groovy-proposed/universe) [6.1.3-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: zimlib [armhf] (groovy-proposed/universe) [6.1.3-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: zimlib [s390x] (groovy-proposed/universe) [6.1.3-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: zimlib [arm64] (groovy-proposed/universe) [6.1.3-4ubuntu1] (no packageset)
<LocutusOfBorg> please accept zimlib, it has only two reverse-dependencies already build-dep waiting for it
<LocutusOfBorg> easy transition
-queuebot:#ubuntu-release- New binary: zimlib [s390x] (groovy-proposed/universe) [6.1.3-4ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: zimlib [amd64] (groovy-proposed/universe) [6.1.3-4ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: zimlib [ppc64el] (groovy-proposed/universe) [6.1.3-4ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: zimlib [arm64] (groovy-proposed/universe) [6.1.3-4ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: zimlib [armhf] (groovy-proposed/universe) [6.1.3-4ubuntu2] (no packageset)
<LocutusOfBorg> sad slow riscv is sad slow
<LocutusOfBorg> wgrant, any ETA for some non-qemu hardware? half of the patches are "hey increase timeouts" and they are not really upstreamable
-queuebot:#ubuntu-release- New binary: zimlib [riscv64] (groovy-proposed/universe) [6.1.3-4ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.3.0-63.57]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.3.0-63.57]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.3.0-63.57]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (eoan-proposed) [5.3.0-63.57]
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (eoan-proposed/main) [5.3.0-1029.31] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (eoan-proposed/main) [5.3.0-1031.33] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (eoan-proposed) [5.3.0-1031.33]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (eoan-proposed) [5.3.0-1029.31]
-queuebot:#ubuntu-release- New: accepted libsis-jhdf5-java [ppc64el] (groovy-proposed) [19.04.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted nvidia-settings-tesla-418 [ppc64el] (groovy-proposed) [418.113-3]
-queuebot:#ubuntu-release- New: accepted zimlib [amd64] (groovy-proposed) [6.1.3-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted zimlib [armhf] (groovy-proposed) [6.1.3-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted zimlib [s390x] (groovy-proposed) [6.1.3-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted zimlib [arm64] (groovy-proposed) [6.1.3-4ubuntu2]
-queuebot:#ubuntu-release- New: accepted zimlib [ppc64el] (groovy-proposed) [6.1.3-4ubuntu2]
-queuebot:#ubuntu-release- New: accepted zimlib [s390x] (groovy-proposed) [6.1.3-4ubuntu2]
-queuebot:#ubuntu-release- New: accepted nvidia-settings-tesla-418 [amd64] (groovy-proposed) [418.113-3]
-queuebot:#ubuntu-release- New: accepted zimlib [arm64] (groovy-proposed) [6.1.3-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted zimlib [amd64] (groovy-proposed) [6.1.3-4ubuntu2]
-queuebot:#ubuntu-release- New: accepted zimlib [riscv64] (groovy-proposed) [6.1.3-4ubuntu2]
-queuebot:#ubuntu-release- New: accepted ruby-valid-email [amd64] (groovy-proposed) [0.1.3-3]
-queuebot:#ubuntu-release- New: accepted zimlib [armhf] (groovy-proposed) [6.1.3-4ubuntu2]
-queuebot:#ubuntu-release- New: accepted zimlib [ppc64el] (groovy-proposed) [6.1.3-4ubuntu1]
<tjaalton> sil2100: hi, there's now a hwe backport of the xserver update from yesterday, if you don't mind giving it a nudge. I was told that it's also needed in bionic..
<LocutusOfBorg> cjwatson, can you please have a look? I know you are busy, but stuff like ndpi is keeping syncd over and over, with logs increasing on each run
<LocutusOfBorg> https://bazaar.launchpad.net/~costamagnagianfranco/ubuntu-archive-tools/sync/revision/1332
<sil2100> tjaalton: oh
<sil2100> tjaalton: ok
<cjwatson> LocutusOfBorg: wrong link maybe?
<cjwatson> LocutusOfBorg: But anyway, sorry, I really don't have brain-space for this today
<cjwatson> There are hopefully others who can, except that you specified exactly me as the reviewer for some reason?
-queuebot:#ubuntu-release- New binary: libkiwix [ppc64el] (groovy-proposed/universe) [9.2.2+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libkiwix [s390x] (groovy-proposed/universe) [9.2.2+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libkiwix [amd64] (groovy-proposed/universe) [9.2.2+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libkiwix [armhf] (groovy-proposed/universe) [9.2.2+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: libkiwix [arm64] (groovy-proposed/universe) [9.2.2+dfsg-3] (no packageset)
<LocutusOfBorg> cjwatson, https://code.launchpad.net/~costamagnagianfranco/ubuntu-archive-tools/sync/+merge/374390
<LocutusOfBorg> cjwatson, you suggested the implementation to me :)
<cjwatson> LocutusOfBorg: OK - sorry, I can't really, please find another archive admin
<cjwatson> I know, but still
<LocutusOfBorg> no problem, I hope vorlon can pick this up then :)
<LocutusOfBorg> we have lots of noise in the auto sync script, this fixes it up
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server-hwe-18.04 [source] (bionic-proposed) [2:1.20.8-2ubuntu2.2~18.04.1]
<LocutusOfBorg> vorlon, short story: auto-sync doesn't sync stuff if the same version has been deleted from the destination archive. the problem is: it looks only for the current release, instead of the whole archive history. so, stuff like "ndpi" removed in focal, are trying to be copied over and over, with lots of poisoning in the log
-queuebot:#ubuntu-release- Unapproved: rejected openldap [source] (bionic-proposed) [2.4.45+dfsg-1ubuntu1.6]
-queuebot:#ubuntu-release- Unapproved: rejected openldap [source] (xenial-proposed) [2.4.42+dfsg-2ubuntu3.9]
-queuebot:#ubuntu-release- Unapproved: rejected openldap [source] (eoan-proposed) [2.4.48+dfsg-1ubuntu1.2]
<slashd> tjaalton, vorlon: Could you please promote 'sosreport' from -proposed to -updates in B/E/F if your time permit ?
<slashd> LP: #1884293 ^^
<ubot5> Launchpad bug 1884293 in sosreport (Ubuntu Focal) "Update to maintenance release v3.9.1" [Medium,Fix committed] https://launchpad.net/bugs/1884293
<tjaalton> slashd: no promotions on a friday
<slashd> tjaalton: all good, will circle back next week
<slashd> tjaalton: might be worth documenting the no promotions on Friday in the SRU process: https://wiki.ubuntu.com/StableReleaseUpdates (Sorry if it's already there but I couldn't find it)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp-5.3 [amd64] (bionic-proposed/main) [5.3.0-1031.33~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp-5.3 [amd64] (bionic-proposed) [5.3.0-1031.33~18.04.1]
-queuebot:#ubuntu-release- Unapproved: openldap (focal-proposed/main) [2.4.49+dfsg-2ubuntu1.2 => 2.4.49+dfsg-2ubuntu1.3] (i386-whitelist, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: openldap (bionic-proposed/main) [2.4.45+dfsg-1ubuntu1.5 => 2.4.45+dfsg-1ubuntu1.6] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: openldap (xenial-proposed/main) [2.4.42+dfsg-2ubuntu3.8 => 2.4.42+dfsg-2ubuntu3.9] (ubuntu-server)
<vorlon> LocutusOfBorg: can't look today; do you want to mark me as a reviewer on the MP so I can look later without it getting lost?
-queuebot:#ubuntu-release- New binary: dav1d [amd64] (groovy-proposed/none) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-proc-macro-error-attr [amd64] (groovy-proposed/none) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: collada2gltf [amd64] (groovy-proposed/none) [20140924-6] (no packageset)
-queuebot:#ubuntu-release- New binary: flatbuffers [amd64] (groovy-proposed/universe) [1.11.0+dfsg1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: collada2gltf [s390x] (groovy-proposed/universe) [20140924-6] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-proc-macro-error-attr [s390x] (groovy-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dav1d [s390x] (groovy-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dav1d [arm64] (groovy-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dav1d [armhf] (groovy-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: collada2gltf [armhf] (groovy-proposed/universe) [20140924-6] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-proc-macro-error-attr [armhf] (groovy-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-proc-macro-error-attr [arm64] (groovy-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: collada2gltf [arm64] (groovy-proposed/universe) [20140924-6] (no packageset)
-queuebot:#ubuntu-release- New binary: collada2gltf [ppc64el] (groovy-proposed/universe) [20140924-6] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-proc-macro-error-attr [ppc64el] (groovy-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: dav1d [ppc64el] (groovy-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: starpu-contrib [amd64] (groovy-proposed/multiverse) [1.3.4+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: starpu-contrib [ppc64el] (groovy-proposed/multiverse) [1.3.4+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: dav1d [riscv64] (groovy-proposed/universe) [0.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: collada2gltf [riscv64] (groovy-proposed/universe) [20140924-6] (no packageset)
#ubuntu-release 2020-07-04
-queuebot:#ubuntu-release- New binary: rust-proc-macro-error-attr [riscv64] (groovy-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: arm-compute-library [arm64] (groovy-proposed/universe) [19.11-1] (no packageset)
-queuebot:#ubuntu-release- New binary: arm-compute-library [armhf] (groovy-proposed/universe) [19.11-1] (no packageset)
<LocutusOfBorg> vorlon, done
<tjaalton> slashd: it's a wikipage ;)
<LocutusOfBorg> please accept libkiwix thanks!
-queuebot:#ubuntu-release- New binary: opencc [amd64] (groovy-proposed/universe) [1.1.1+git20200624+ds2-1] (i386-whitelist, input-methods)
-queuebot:#ubuntu-release- New binary: opencc [ppc64el] (groovy-proposed/universe) [1.1.1+git20200624+ds2-1] (i386-whitelist, input-methods)
-queuebot:#ubuntu-release- New binary: opencc [armhf] (groovy-proposed/universe) [1.1.1+git20200624+ds2-1] (i386-whitelist, input-methods)
-queuebot:#ubuntu-release- New binary: opencc [s390x] (groovy-proposed/universe) [1.1.1+git20200624+ds2-1] (i386-whitelist, input-methods)
-queuebot:#ubuntu-release- New binary: opencc [arm64] (groovy-proposed/universe) [1.1.1+git20200624+ds2-1] (i386-whitelist, input-methods)
-queuebot:#ubuntu-release- New binary: gnome-getting-started-docs [amd64] (groovy-proposed/main) [3.36.2-0ubuntu1] (personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-user-docs [amd64] (groovy-proposed/main) [3.36.2+git20200704-0ubuntu1] (personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: opencc [riscv64] (groovy-proposed/universe) [1.1.1+git20200624+ds2-1] (i386-whitelist, input-methods)
-queuebot:#ubuntu-release- Unapproved: knot (bionic-proposed/universe) [2.6.5-3 => 2.6.5-3ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: knot (focal-proposed/universe) [2.7.8-1 => 2.7.8-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ubuntu-docs (focal-proposed/main) [20.04.2 => 20.04.3] (desktop-core, personal-gunnarhj)
-queuebot:#ubuntu-release- Unapproved: gnome-user-docs (focal-proposed/main) [3.36.1-0ubuntu1 => 3.36.2+git20200704-0ubuntu0.1] (personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-getting-started-docs (focal-proposed/main) [3.36.1-0ubuntu1 => 3.36.2-0ubuntu0.1] (personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted arm-compute-library [arm64] (groovy-proposed) [19.11-1]
-queuebot:#ubuntu-release- New: accepted collada2gltf [amd64] (groovy-proposed) [20140924-6]
-queuebot:#ubuntu-release- New: accepted collada2gltf [armhf] (groovy-proposed) [20140924-6]
-queuebot:#ubuntu-release- New: accepted collada2gltf [riscv64] (groovy-proposed) [20140924-6]
-queuebot:#ubuntu-release- New: accepted arm-compute-library [armhf] (groovy-proposed) [19.11-1]
-queuebot:#ubuntu-release- New: accepted collada2gltf [ppc64el] (groovy-proposed) [20140924-6]
-queuebot:#ubuntu-release- New: accepted collada2gltf [arm64] (groovy-proposed) [20140924-6]
-queuebot:#ubuntu-release- New: accepted collada2gltf [s390x] (groovy-proposed) [20140924-6]
-queuebot:#ubuntu-release- New: accepted dav1d [amd64] (groovy-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted dav1d [armhf] (groovy-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted dav1d [riscv64] (groovy-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted dav1d [arm64] (groovy-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted dav1d [s390x] (groovy-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted dav1d [ppc64el] (groovy-proposed) [0.7.1-1]
-queuebot:#ubuntu-release- New: accepted libkiwix [amd64] (groovy-proposed) [9.2.2+dfsg-3]
-queuebot:#ubuntu-release- New: accepted libkiwix [armhf] (groovy-proposed) [9.2.2+dfsg-3]
-queuebot:#ubuntu-release- New: accepted libkiwix [arm64] (groovy-proposed) [9.2.2+dfsg-3]
-queuebot:#ubuntu-release- New: accepted libkiwix [ppc64el] (groovy-proposed) [9.2.2+dfsg-3]
-queuebot:#ubuntu-release- New: accepted libkiwix [s390x] (groovy-proposed) [9.2.2+dfsg-3]
-queuebot:#ubuntu-release- New: accepted rust-proc-macro-error-attr [amd64] (groovy-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-proc-macro-error-attr [armhf] (groovy-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-proc-macro-error-attr [riscv64] (groovy-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-proc-macro-error-attr [arm64] (groovy-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-proc-macro-error-attr [s390x] (groovy-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-proc-macro-error-attr [ppc64el] (groovy-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted starpu-contrib [amd64] (groovy-proposed) [1.3.4+dfsg-3]
-queuebot:#ubuntu-release- New: accepted starpu-contrib [ppc64el] (groovy-proposed) [1.3.4+dfsg-3]
-queuebot:#ubuntu-release- New binary: opencc [ppc64el] (groovy-proposed/universe) [1.1.1+git20200624+ds2-2] (i386-whitelist, input-methods)
-queuebot:#ubuntu-release- New binary: opencc [s390x] (groovy-proposed/universe) [1.1.1+git20200624+ds2-2] (i386-whitelist, input-methods)
-queuebot:#ubuntu-release- New binary: elpa-transient [amd64] (groovy-proposed/universe) [0.2.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: opencc [arm64] (groovy-proposed/universe) [1.1.1+git20200624+ds2-2] (i386-whitelist, input-methods)
-queuebot:#ubuntu-release- New binary: opencc [amd64] (groovy-proposed/universe) [1.1.1+git20200624+ds2-2] (i386-whitelist, input-methods)
-queuebot:#ubuntu-release- New binary: elpa [s390x] (groovy-proposed/universe) [2019.11.001-3] (no packageset)
-queuebot:#ubuntu-release- New binary: opencc [armhf] (groovy-proposed/universe) [1.1.1+git20200624+ds2-2] (i386-whitelist, input-methods)
-queuebot:#ubuntu-release- New binary: xiphos [arm64] (groovy-proposed/universe) [4.2.1+dfsg1-1] (mozilla)
-queuebot:#ubuntu-release- New binary: elpa [ppc64el] (groovy-proposed/universe) [2019.11.001-3] (no packageset)
-queuebot:#ubuntu-release- New binary: xiphos [armhf] (groovy-proposed/universe) [4.2.1+dfsg1-1] (mozilla)
-queuebot:#ubuntu-release- New binary: elpa [amd64] (groovy-proposed/universe) [2019.11.001-3] (no packageset)
-queuebot:#ubuntu-release- New binary: xiphos [amd64] (groovy-proposed/universe) [4.2.1+dfsg1-1] (mozilla)
-queuebot:#ubuntu-release- New binary: xiphos [s390x] (groovy-proposed/universe) [4.2.1+dfsg1-1] (mozilla)
-queuebot:#ubuntu-release- New binary: xiphos [ppc64el] (groovy-proposed/universe) [4.2.1+dfsg1-1] (mozilla)
-queuebot:#ubuntu-release- New binary: elpa [arm64] (groovy-proposed/universe) [2019.11.001-3] (no packageset)
-queuebot:#ubuntu-release- New binary: elpa [armhf] (groovy-proposed/universe) [2019.11.001-3] (no packageset)
-queuebot:#ubuntu-release- New binary: opencc [riscv64] (groovy-proposed/universe) [1.1.1+git20200624+ds2-2] (i386-whitelist, input-methods)
#ubuntu-release 2020-07-05
-queuebot:#ubuntu-release- New: accepted elpa-transient [amd64] (groovy-proposed) [0.2.0-3]
-queuebot:#ubuntu-release- New binary: elpa [riscv64] (groovy-proposed/universe) [2019.11.001-3] (no packageset)
-queuebot:#ubuntu-release- New binary: xiphos [riscv64] (groovy-proposed/universe) [4.2.1+dfsg1-1] (mozilla)
-queuebot:#ubuntu-release- New: accepted elpa [arm64] (groovy-proposed) [2019.11.001-3]
-queuebot:#ubuntu-release- New: accepted elpa [riscv64] (groovy-proposed) [2019.11.001-3]
-queuebot:#ubuntu-release- New: accepted xiphos [ppc64el] (groovy-proposed) [4.2.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted xiphos [s390x] (groovy-proposed) [4.2.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted elpa [armhf] (groovy-proposed) [2019.11.001-3]
-queuebot:#ubuntu-release- New: accepted xiphos [riscv64] (groovy-proposed) [4.2.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted opencc [riscv64] (groovy-proposed) [1.1.1+git20200624+ds2-2]
-queuebot:#ubuntu-release- New: accepted elpa [amd64] (groovy-proposed) [2019.11.001-3]
-queuebot:#ubuntu-release- New: accepted elpa [s390x] (groovy-proposed) [2019.11.001-3]
-queuebot:#ubuntu-release- New: accepted opencc [arm64] (groovy-proposed) [1.1.1+git20200624+ds2-2]
-queuebot:#ubuntu-release- New: accepted opencc [s390x] (groovy-proposed) [1.1.1+git20200624+ds2-2]
-queuebot:#ubuntu-release- New: accepted xiphos [arm64] (groovy-proposed) [4.2.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted elpa [ppc64el] (groovy-proposed) [2019.11.001-3]
-queuebot:#ubuntu-release- New: accepted opencc [armhf] (groovy-proposed) [1.1.1+git20200624+ds2-2]
-queuebot:#ubuntu-release- New: accepted xiphos [armhf] (groovy-proposed) [4.2.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted opencc [amd64] (groovy-proposed) [1.1.1+git20200624+ds2-2]
-queuebot:#ubuntu-release- New: accepted xiphos [amd64] (groovy-proposed) [4.2.1+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted flatbuffers [amd64] (groovy-proposed) [1.11.0+dfsg1-2]
-queuebot:#ubuntu-release- New: accepted opencc [arm64] (groovy-proposed) [1.1.1+git20200624+ds2-1]
-queuebot:#ubuntu-release- New: accepted opencc [ppc64el] (groovy-proposed) [1.1.1+git20200624+ds2-1]
-queuebot:#ubuntu-release- New: accepted opencc [s390x] (groovy-proposed) [1.1.1+git20200624+ds2-1]
-queuebot:#ubuntu-release- New: accepted opencc [amd64] (groovy-proposed) [1.1.1+git20200624+ds2-1]
-queuebot:#ubuntu-release- New: accepted opencc [riscv64] (groovy-proposed) [1.1.1+git20200624+ds2-1]
-queuebot:#ubuntu-release- New: accepted opencc [armhf] (groovy-proposed) [1.1.1+git20200624+ds2-1]
-queuebot:#ubuntu-release- New: accepted opencc [ppc64el] (groovy-proposed) [1.1.1+git20200624+ds2-2]
-queuebot:#ubuntu-release- New binary: dh-virtualenv [amd64] (groovy-proposed/universe) [1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sambamba [amd64] (groovy-proposed/universe) [0.7.1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: sambamba [arm64] (groovy-proposed/universe) [0.7.1-4] (no packageset)
-queuebot:#ubuntu-release- New binary: viking [s390x] (groovy-proposed/universe) [1.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: viking [ppc64el] (groovy-proposed/universe) [1.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: viking [amd64] (groovy-proposed/universe) [1.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: viking [arm64] (groovy-proposed/universe) [1.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: viking [armhf] (groovy-proposed/universe) [1.8-1] (no packageset)
<xnox> ubuntu-archive i did an suite copy from focal to groovy-proposed, to trigger riscv64 build in groovy which succeeded. But now the publishing records look funny. I think https://launchpad.net/ubuntu/+source/govendor/1.0.9+ds1-1 should only be published in groovy-release, for all 7 arches, and not exist in groovy-proposed
-queuebot:#ubuntu-release- New binary: malcontent [amd64] (groovy-proposed/none) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: malcontent [s390x] (groovy-proposed/none) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: malcontent [arm64] (groovy-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: malcontent [armhf] (groovy-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: malcontent [ppc64el] (groovy-proposed/universe) [0.8.0-1] (no packageset)
