#ubuntu-release 2010-08-24
<ogasawara> I'm hoping to get clarification re BetaFreeze on https://wiki.ubuntu.com/MaverickReleaseSchedule ... I assume I should refrain from uploading packages after Thurs Aug 26 in preparation for Beta, correct?
<skaet> ogasawara,  unless robbiew agrees otherwise,  yup,  please refrain from uploading packages after Aug 26 (Beta Freeze).
<ogasawara> skaet: perfect, thanks.
<slangasek> lamont: is hubbard broken?  http://launchpadlibrarian.net/54252536/buildlog_ubuntu-maverick-armel.linux-linaro_2.6.35-1003.7_FAILEDTOBUILD.txt.gz
<slangasek> syntax error at /home/buildd/.sbuildrc line 32, near ")"
<lamont> slangasek: actually, yes it was.  sigh.
 * lamont does a few retries
<ScottK> slangasek: I found a tester for KNR on armel for 10.04.1, so we may get to release that yet.
<ogra> ScottK, it is installable ?
<highvoltage> ScottK: would that run on a beagleboard?
<ogra> ScottK, i thought there are still FTBFS that hold it up
<ScottK> highvoltage: It runs on whatever 10.04 runs on.
<ogra> oh
<ogra> 10.04
<ogra> ignore this blind old man :P
<ScottK> ogra: Yes.  Maverick is still busted.
<ogra> highvoltage, yes, as our ubuntu-netbook images do
<slangasek> lamont: ta
<slangasek> ScottK: ok, cool.  Any idea of a timeline?
<ScottK> slangasek: Hopefully today (FSVO today)
<lamont> slangasek: oh hey, say hi to allspice
<slangasek> looks like nutmeg to me
<lamont> launchpad.net/builders
<slangasek> ack :)
#ubuntu-release 2010-08-25
<ogasawara> cjwatson: would it be possible to get the linux-2.6.35-19.25 kernels (amd64, i386, armel) in the New queue processed?
<cjwatson> yup
<ogasawara> thanks
<cjwatson> one sec
<cjwatson> ogasawara: done
<ogasawara> thank you
<cjwatson> could somebody look at grub-rescue-efi-amd64 in NEW for me, please?
<cjwatson> ... actually, might be a good idea to wait for its i386 build to show up
 * cjwatson notes linux-mvl-dove bumping from 2.6.32-204 to 2.6.32-409, and gives up trying to understand its versioning logic
<bjf> cjwatson: that mvl-dove version looks odd to me as well, i'm dbl checking it
<cjwatson> I accepted it, but you can always reupload I guess
<bjf> cjwatson: it's a .32 based kernel, however we just seeded a new topic branch for it in maverick and so the abi numbers are a different range
<bjf> cjwatson: if that makes any sense
<micahg> can I get an FFe for bug 623722
<ubot4> Launchpad bug 623722 in sqlite3 (Ubuntu) "[FFe] Please sync sqlite3 3.7.2-1 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New] https://launchpad.net/bugs/623722
<cjwatson> bjf: the entire business of namespacing ABI numbers makes no sense to me anyway, given that every package's version numbers live in a different namespace :-)
<bjf> cjwatson: you'd have to ask tgardner or apw, i don't understand the need
<lamont> cjwatson: it was a long twisty maze of ZOMFG to get where the kernel package names are... and we revisit it from time to time to simplify it and get right back where we are
<lamont> at least for linux-image-*
<bjf> cjwatson: at uds-n we can all sit in the kernel room (the bar) and discuss it
<lamont> btw, molybdenum is i386 buildd #5, but will be disappearing again tomorrow london for a while before reappearing
 * ScottK noticed the lack of ia64 and sparc build records.  Nice.
<lamont> ScottK: crafting the SQL to make maverick "didn't happen" for them is underway, but will take a while.
<lamont> meanwhile,  the queue length for those architectures won't hit zero
<ScottK> Right.  Figured revising history was a little harder than stopping the future from happening.
<cjwatson> bjf: I asked at the time ;-)
<lamont> cjwatson: it's the result of a brainnumbing set of requirements
<micahg> is anyone around to grant FFes?
<cjwatson> micahg: granted
<micahg> cjwatson: thanks, you have time for one more?
<cjwatson> maybe :)
<cjwatson> 17:20 <cjwatson> could somebody look at grub-rescue-efi-amd64 in NEW for me, please?
<micahg> bug 553269
<ubot4> Launchpad bug 553269 in mediatomb (Debian) (and 1 other project) "[FFe][needs-packaging] MediaTomb 0.12.1 (affects: 5) (heat: 30)" [Unknown,New] https://launchpad.net/bugs/553269
<cjwatson> OK, the i386 build is there now, so I could do with an archive admin looking at the above
<cjwatson> micahg: ok, commented on the bug
<micahg> cjwatson: thanks
<micahg> cjwatson: I plan on updating Debain before RC freeze and syncing
 * micahg joined pkg-multimedia
<micahg> just figured since we have the freeze, better to get us up to date first
<micahg> cjwatson: if you like I can get Debian updated first and sync, but that'll be another 2 weeks or so
<cjwatson> why does it take an extra two weeks to do an upload to Debian?
<micahg> cjwatson: I need to update the standards and learn how to use pkg-multimedia git
<micahg> normally it wouldn't
<micahg> I didn't want to risk missing it in maverick
<cjwatson> as long as the .orig.tar.gzs match up and the packaging is being done mostly in sync, it shouldn't be too bad
<Laney> I've uploaded snapshots from Debian VCSen in the past, that's an option
<micahg> cjwatson: I used uupdate, so it's the upstream tarball, I'll use the same one to update pkg-multimedia
<Riddell> cjwatson: grub-rescue-efi-amd64 accepted
<cjwatson> Riddell: thanks!
#ubuntu-release 2010-08-26
<ogasawara> skaet: I've just sent email to the team re my action item from last weeks release meeting ("ogasawara to track grub gfxpayload=keep for Natty pre-work")
<ogasawara> skaet: do you want me to mark that as DONE for friday's release meeting, or would you prefer that I not edit that page?
<skaet> ogawawara, go ahead and edit it, to mark it done.  :)  thanks!
<ScottK> It would be convenient if someone would process NBS to make the list a little more accessible.
<ogasawara> ogra: around?  I wanted to raise bug 613855 here with the release team in order to get a beta freeze exception to upload a new kernel.
<ogra> ogasawara, sure i am :)
<ogra> see my last reply on the ML
<ubot4> Launchpad bug 613855 in linux (Ubuntu Maverick) (and 1 other project) "omap3 beagle XM MMC card always comes up readonly (affects: 1) (heat: 256)" [Undecided,Confirmed] https://launchpad.net/bugs/613855
<ogasawara> ogra: yep, just read it.
<ogasawara> skaet, robbiew: around?  some last minute patches just came in to resolve 613855.  This however would require us uploading a new kernel.
<robbiew> ogasawara: hey
<ogasawara> skaet, robbiew: https://lists.ubuntu.com/archives/kernel-team/2010-August/012421.html captures the meat of the reason for needing a beta freeze exception.
 * robbiew reads
 * robbiew is reminded that he needs to send the Freeze announcement as well
<robbiew> heh
<robbiew> ogasawara: seems fine to me
<ogasawara> robbiew: cool, I'll prepare an upload then.  Thanks.
<robbiew> ogasawara: yep...and I'll prepare the Freeze announcement...heh
<ogasawara> heh
 * skaet notes timing of freeze announcements to her "future todo lists... " ;)
<ogra> ogasawara, gah, why did you ask robbiew ? now he remembers the announcement !
<robbiew> heh
<persia> This was not a good thing.  A few more hours would have pleased everyone
<ogasawara> my bad
<robbiew> persia: it's okay...I got some other things in the pipeline before I get to the Freeze Announcment ;)
<persia> It's a handy thing that those who send release announcements tend to be in deep negative timezones.
<rsalveti> ogasawara: thanks for pushing the xm fixes :-)
<ogasawara> rsalveti: np.  just finishing up a quick test build before I upload.
<rsalveti> cool
 * ogra cries about losing another buildd for 16h ... but you cant have everything i guess :)
 * ScottK senses a need for another upload of qt4-x11 and qt4-qws just to make ogra feel better.
<ogra> grrr
<ScottK> :-)
<ogra> we're only 78 packages and 13h behind :)
<GrueMaster> Just imagine if someone were to fix openjdk & rebuild openoffice.
<ogra> and have no working images yet
<ogra> GrueMaster, OO.o is hogging one buildd already
<ogra> luckily the maverick upload failed today else we would have one buildd less
<ogra> since linaro and TI started using our buildds too the situation got really bad ... we urgently need more armel builders
<ogra> but what else is new
 * ogra will propose that packages get a maximum size limit at some point :P
<GrueMaster> Anything I can do to help with the Dove-X0 and Babbage I have that are consuming electrons to blink lights?
<ogra> if its more than 1M big you have to split ... muhahaha
<ogra> i doubt lamont can make use of them at your house :)
<GrueMaster> He just needs to add their ipv6 addresses to the table.
<slangasek> heh
<robbiew> persia: ogra: buuurrrrrrrr...it's getting cold in here :P
<robbiew> freeze is on :)
<ogra> crap, i''ll need a ton of freeze exceptions
<ogra> we dont even have booting images yet, so we cant apply the pending fixes
<robbiew> ogra: perhaps you can create a Master Freeze Exception request
<robbiew> ogra: it's armel...who uses that anyway
<robbiew> lol
<robbiew> joking of course
<ogra> something like that, i need to figure out where we stand first, i applied some fixes already but we need to wait for oem-config to work again ... so i'm somehat depending on the next ubiquity upload
<ogra> robbiew, only the vendors ;)
<ogra> and indeed us poor developers :)
<robbiew> ogra meet ev, ev meet ogra
<robbiew> lol
<ogra> lol
<ogra> he knows i'm waiting
<ScottK> ogra: If you can make a bug of what you need uploaded to get to beta (a list) and when you expect to have it, I don't mind approving a set of changes at once.
<ogra> i would have done an upload but there were lots of changes in the works when our fix  entered the tree so i felt i'd better wait
<ogra> ScottK, well, i need images first to see whats needed, i know one -settings package for sure but thats trivial
<ScottK> OK.
<ogra> for the other packages we need to go step by step through the breakage
<ScottK> Just seeing if we could minimize the paperwork.
<ogra> and we at least still have some time for that
 * ogra would love to but that requires to know whats broken in advance 
<ogra> as soon as i do i'll file the necessary bit, probably as a list
<ScottK> robbiew and skaet: Historically the beta freeze only applies to seeded packages.  We don't have a way to just freeze those, so all packages need manual approval, but we just push the unseeded Universe packages through without review.  I'm expecting we'll do that again.
<robbiew> ack
 * skaet makes note of this too...
<ScottK> cjwatson: Can we have the release bot?
<ev> can someone approve ubiquity 2.3.8?
<slangasek> looks like someone just has
<slangasek> someone else is working on the queue, then?  ScottK?
<Riddell> I approved it
<Riddell> we discussed it in -install
<slangasek> ok
 * Riddell away until monday afternoon
<slangasek> Riddell: have a good weekend!
 * ScottK looked at a couple of things, but isn't processing the queue.
#ubuntu-release 2010-08-27
<slangasek> ScottK: bit of NBS processing done; all these kernels makes the recommended commandline too long to cut'n'paste at one go, so I'll do another run a bit later, but that should help make it more readable
<ScottK> slangasek: Thanks.
<ScottK> Wahoo!  KDE 4.5 built on armel for the first time ....
 * persia cheers upstream.
<GrueMaster> Does anyone know why ubiquity-frontend-gtk-2.3.8 is not building for armel?  It is blocking image builds.
 * persia looks, and suggests #ubuntu-devel as a better forum for that class of question in general
<persia> Oh, it built.  Just waiting to be published (https://launchpad.net/ubuntu/+source/ubiquity/2.3.8/+build/1935852)
<persia> Should be out in a bit.
<GrueMaster> ok.  Not sure how the process works.  Since all of the packages come from the same source, I thought they would go at the same time.
<persia> So, the source gets processed (NEW/Unaccepted/Accepted), and then gets added to the build queues.  The buildds pull from the build queues whenever they have time (some architectures are faster than others).  When a build finishes, it gets processed (NEW/Unaccepted/Accepted), and then gets published, after which it gets mirrored, after which you can grab it.
<persia> Since the buildd queues are all different lengths, and the buildds different speeds, there are often differences between the publication time for different architectures.  This can lead to issues on amd64, armel, and powerpc when there are package relationships between arch:all and arch:any binary packages.  But the assumption is that most folks run i386, where it just works.
<GrueMaster> Ok.  All run by cron jobs I would assume.
<persia> No.
<persia> publication is on cron.  If a package gets caught in NEW or Unaccepted, it's a manual action to get it out (either source or binary).  builds are queued as soon as the sources are processed (I believe this used to be cron, but got changed to avoid the 3-hour delay between upload and availability)
<GrueMaster> Hmm.  Well, too much to consume before bed.  I'll manually pull it and install.  Want to see if I can make forward progress before bed.
<persia> OK.  I'd expect it to be on ports in ~15 minutes.
<ev> KDE ubiquity is busted on today's daily-live.  Seems to be a privileges thing; looking into it.
<KE1HA> ev:  saw that on a couple other daily's as well. was told it could be the Artwork uploads doing it.
<ev> KE1HA: older KDE ones?
<KE1HA> not older ones no, from today.
<KE1HA> today being 26th :-)
<ev> heh, indeed
<ev> which ones, specifically?
<KE1HA> Xub and UB alts
<KE1HA> amd64
<ev> alts?  Alternates?
<KE1HA> Yes
<ev> ubiquity is not on the alternate CDs
<KE1HA> I know.
<KE1HA> was the same issue though.
<ev> how so?
<KE1HA> Hmm good question, I tryng to remember who told be this as said same thing happening on Ubiq iso too.
<KE1HA> I stopped testing on the 3rd failed ISO
<KE1HA> ev I can't remember who it was, ... that's gonna bug me, it was a developer though, I know that.
<ev> what was the exact error you were seeing?
<ev> and was this during, or post-install?
<KE1HA> I had to try and switch mirrors, and the apt portion failed.
<KE1HA> It was during install, never made it to the end.
<ev> KE1HA: not sure who told you it was the same bug, but it definitely was not.
<ev> the bug I'm describing prevents ubiquity from even starting.  It never makes it to apt-setup.
<KE1HA> He didn't say it was Bug per say, but he said it was due to the updates with Artwork.
<KE1HA> If yours ins't starting at all, probably unrelated I suppose.
<ev> indeed
<cjwatson> ScottK: on its way.  I was out yesterday.
<cjwatson> oh, needs some work cocoplum-side to make it useful
<cjwatson> persia: s/Unaccepted/Unapproved/g in your explanation above, FWIW
<cjwatson> ctrl-c'ing the bot to avoid flooding the channel until such time as language packs are out of the queue
<persia> cjwatson, Right.  Thanks for the correction.
<cjwatson> can people please STOP NBSing old kernels before d-i has been updated to use the new ones?!
<cjwatson> I'm getting kind of fed up of spending time debugging problems that turn out to be due to this.
<cjwatson> (bug 624915)
<ubot4> Launchpad bug 624915 in linux (Ubuntu Maverick) (and 3 other projects) "maverick kvm guests not seeing virtio disks (affects: 1) (heat: 6)" [High,Invalid] https://launchpad.net/bugs/624915
<persia> Is there a way to update the NBS script to detect that d-i still needs the kernels?
<cjwatson> pretty hard
<cjwatson> maybe the people who like to blindly apply its output could do that
<persia> heh.  Right.  Doesn't sound worth it to look into the hard bits.
<cjwatson> I'm sure it's possible since there's a udeb manifest in the archive
<cjwatson> under dists/maverick/main/installer-*/
<ogra> can someone let jasper through please (it fixes a hard hang of the omap4 images)
<cjwatson> Has somebody been removing old CD build logs from antimony?
<cjwatson> Please don't ever do that in future.  Whoever you are, you've made it impossible for me to investigate the exact set of circumstances leading up to bug 597734.
<ubot4> Launchpad bug 597734 in debian-installer (Ubuntu) "kernel version mismatch between debian-installer and CD-ROM (affects: 1) (heat: 54)" [Undecided,New] https://launchpad.net/bugs/597734
<ScottK> cjwatson: Thanks for the bot.
<ScottK> ogra: All the armel build failures for KDE are (finally) fixed.  Once there is room in the queue, it would be good to try and spin an armel image (understanding it's not the priority)
<ogra> ScottK, i thought that already happened
<ScottK> ogra: Maybe it did.  I didn't look.
 * ogra saw someone paste a url somewhere 
<ogra> http://cdimage.ubuntu.com/kubuntu-mobile/ports/daily-preinstalled/current/
<ogra> (will still be broken until someone approves my jasper-initramfs upload)
 * ScottK pushes the big red button.
<ScottK> ogra: Accepted.
<ogra> sweet, thanks
<GrueMaster> omap only?  No omap4?
<GrueMaster> or is it still building?
<ogra> GrueMaster, if omap userspace works for kde and we know that omap4 kernel/bootloader work in ubuntu we currently save buildd time, i'll enable omap4 builds after beta for kubuntu
<ogra> nobody out there can test omap4 atm
<GrueMaster> ok
<GrueMaster> well, me (assuming we get our images working again).
<ScottK> ogra: We don't have an armel image for Kubuntu desktop yet.
<ScottK> http://cdimage.ubuntu.com/kubuntu/ports/daily-live/current/
<ogra> i think NCommander enabled something in the crontab that just wasnt built yet
 * lamont has been shuffling buildds amd64->i386 and back to flush the langpack queue faster
<ScottK> ogra: Cool.  I thought he was just working on the kubuntu-mobile stuff, but we'll see.
<jdstrand> hey, so avahi is sitting in binary new since it is a merge from Debian. it does not reference a bug-- has someone from ubuntu-release ack'd it?
<jdstrand> err, a merge and has a new binary
<seb128> it was uploaded  before the freeze not sure it needs a ack from binaries waiting there?
<seb128> ie it got blocked in binnew as any packaged having new binaries
<jdstrand> well, the version is 0.6.27-2ubuntu1 and we currently have 0.6.25-1ubuntu6
<jdstrand> so we seem to be in a gray area, and I thought I'd ask
<ScottK> Given how long it's sat, having it sit until after beta may not be a bad idea.  Technically it doens't need a freeze exception though.
<jdstrand> ScottK: because of the timing of the upload?
<jdstrand> ScottK: ie, it technically doesn't need one because of the timing of the upload?
<seb128> jdstrand, well we can't refuse the binaries for maverick
<seb128> if we don't want the new version we will need to downgrade the source
<jdstrand> seb128: I wasn't suggest refuse the binaries. I was curious about the beta freeze
<jdstrand> seb128: and perhaps waiting to accept until after, like ScottK said
<seb128> seems there is a soname change so we might as well wait
<seb128> not my call
<seb128> on one side we might want to test the new version in beta
<jdstrand> right, mine either, hence the question here :)
<ScottK> jdstrand: Yes.  Because of the timing of the upload.
 * jdstrand nods
<jdstrand> ScottK: can you look at https://wiki.ubuntu.com/ArchiveAdministration#Archive%20Administration%20and%20Freezes and tell me if it is accurate. I looked at https://wiki.ubuntu.com/FreezeExceptionProcess and it wasn't clear
<jdstrand> ScottK: specifically for the universe/multiverse bits
<ScottK> jdstrand: I'm about to head out for a while.  I'll try and have a look later.
<jdstrand> ScottK: thanks
<ev> I'd greatly appreciate it if someone could review and accept the freeze exception for the ubiquity upload I just did.  Bug 625472
<ev> Without it, KDE users wont be able to install from the desktop CD.
<ubot4> Launchpad bug 625472 in ubiquity (Ubuntu) "Beta freeze exception for 2.3.9 (affects: 1) (heat: 8)" [Undecided,Fix committed] https://launchpad.net/bugs/625472
<ScottK> ev: Looks good.
<ScottK> Downside risk is nil in any case.
<ScottK> Just going to double check with sistpoty since he commented in the bug.
<sistpoty> ScottK: actually, I always forget about the exact uid handling, so I wrote a test program... however that actually fails at the setegid(1000)... still not too sure why. so seteuid(0) and setegid(0) seems to do the right thing
<ScottK> sistpoty: Are you OK if I accept it then?
<sistpoty> ScottK: sure, just go ahead
<ScottK> sistpoty: Thanks.  Would you please mark the bug approved.
<sistpoty> (and sorry, for not getting my test program right in the first place)
<ScottK> I think it delayed things by a full four minutes, so the consequences are pretty severe....  ;-)
<sistpoty> heh :)
<ScottK> ev: It's in.
 * ScottK isn't reviewing ^^^
 * sistpoty tries to be invisible
<ScottK> jdstrand: I agree it doesn't look quite right (incomplete update when motu-release and ubuntu-release were combined).
<ScottK> sistpoty: Would you please read through https://wiki.ubuntu.com/FreezeExceptionProcess and see what you think of the Universe/Multiverse specific things we need to keep?
<slangasek> wrt avahi which came up for discussion earlier, the only revdeps of libavahi-core6 in main are from the same source package
<sistpoty> ScottK: sure, will do
<ScottK> Thanks.
<slangasek> so I think it'd be fine to take this now rather than waiting to post-beta
<ScottK> slangasek: If you think so, then I'd say go ahead.
<GrueMaster> ScottK: The maverick-preinstalled-desktop-armel+omap.img is missing the vfat partition.  This is a bad image.
<ScottK> OK.  How do we fix that?
 * ScottK looks around for ogra.
<GrueMaster> I'm going to try to hack it together with our netbook image to see if it works.  Beyond that, it's an ogra thing.
<ScottK> Thanks.
<GrueMaster> I should be able to dd the netbook image on, then overwrite the rootfs with the kubuntu one.
<sistpoty> ok, got a few points that I'll try to reword. However I'm unsure about: "FeatureFreeze for bugfix-only updates"
<sistpoty> the section seems to imply that bugfix only updates are only suitable for universe/multiverse, but I think practice differs... make that section general for all packages?
<ScottK> sistpoty: The difference is that in Universe/Multiverse we had a historical practice of requiring a bug to be filed to document it.
<ScottK> I think we can drop that now.
<sistpoty> *nod*
<ScottK> I think there ought to be some discussion about seeded versus uneseeded packages in freezes, but I don't think we need any Universe/Multiverse specfic stuff anymore.
<sistpoty> *nod*
<ScottK> slangasek: I'm about to head out for a while.  The new ubiquity built and should be in the archive in ~20 minutes.  Would you please kick off Kubuntu live i386/amd64 rebuilds once it is so we can get the installer changes smoke tested?
<slangasek> ScottK: ack
<ScottK> Thanks.
<sistpoty> hmpf, just updated the FFe page in the wiki, and don't find the knob to revert it back to the old version (so that the changes can be discussed on the mailing list, and my bad grammar and spelling can be sorted out)
<skaet>  sistpoty, can you bounce me the link to FFe page,  haven't encountered that one yet.
<sistpoty> skaet: https://wiki.ubuntu.com/FreezeExceptionProcess
<sistpoty> (sorry, should have added that to the mail)
<skaet> sistpoty,  thanks!
<slangasek> ScottK: kubuntu images rolled
<ScottK> slangasek: Cool.  Thanks.  Just got back.
<GrueMaster> ScottK: Copying the kubuntu-preinstalled-desktop image over the top of the UNR armel image appears to be working so far.  System is very slow, but I am now in oem-config, which is a good sign.
<ScottK> GrueMaster: Cool.  So we just need to get the vfat problem solved and we should be good, right?
<GrueMaster> Err, no.  oem-config just crashed.  sigh.  I'll file a bug and get back to you.
<GrueMaster> But the vfat issue will need to be fixed for sure.
<ScottK> GrueMaster: Thanks.
 * ScottK hopes for ogra to appear with a fix.
<GrueMaster> he's afk for the day.
<ScottK> Surely if we repeat his nick enough he'll reappear.
<GrueMaster> It's 12am his time.  Doubtful.
<ScottK> Right, then there's also the risk he might not be sober enough to give good advice even if he did appear.
<GrueMaster> heh.
<ScottK> slangasek: Would you please demote kubuntu-mobile to Universe.  It shouldn't be in Main and (as one might expect) isn't installable just with Main.
<GrueMaster> ScottK: http://paste.ubuntu.com/484686/ is the failure, but there is a new version specific to qt/kde.  Will pull that and try again before filing bug.
<cjwatson> ScottK: it seems to be seeded for main though
<ScottK> cjwatson: A while ago I mailed you about trying to figure out how to build two metapackages out of the same source one for Main and on with Universe.  We never got a chance to discuss it.  No doubt we missed something in trying to set it up.
<cjwatson> hmm
<cjwatson> don't suppose that mobile could live in a different seed collection, rather than kubuntu.maverick?
<cjwatson> that's what drives it
<cjwatson> could somebody review debian-installer in the queue?  it's needed to get armel to build
<ScottK> Also didn't figure out how to have a metapackage names kubuntu-mobile that wasn't built off of kubuntu-meta
<cjwatson> 'Task-Metapackage: kubuntu-mobile' at the top of the relevant seed
<ScottK> Right.  Some things are too obvious.
<ScottK> OK.  I'll work on that.
<ScottK> cjwatson: I'll take care of accepting D-I.
<cjwatson> thanks
<ScottK> Done.  That's probably the one time ever D-I will have a trivial enough diff for me to be confident reviewing it.
<ScottK> GrueMaster: That smells like somethe the latest updates should fix.
<ScottK> cjwatson: No doubt you know, but it FTBFS on armel.
<persia> Wouldn't moving kubuntu-mobile to a new seed require landing a patch to cron.germinate in LP?
<persia> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/annotate/head:/cronscripts/publishing/cron.germinate
#ubuntu-release 2010-08-28
<cjwatson> persia: oh lord.  probably.
<cjwatson> ScottK: hate life
 * persia checks the LP patch landing schedule
<persia> OK.  There's a chance of landing that for 13th September, so it's possible to sort for release, but that's likely the earliest it can be done.
<persia> Oops, read that wrong.  Landing 6th September.
<persia> (next window wouldbe 11th october)
<cjwatson> strictly, it only needs LP if you need to build Task headers from it
<cjwatson> if all you need is the metapackage, you can get by without
<cjwatson> ScottK: nngh.  somebody NBSed half the armel kernel udebs when they weren't NBS
<persia> livecd-rootfs uses the task.
<cjwatson> slangasek: do you fancy figuring out how to get the rest of the armel kernel udebs back into the archive?
<cjwatson> persia: but can be easily instructed not to
<slangasek> cjwatson: oh dear
<slangasek> cjwatson: is that my doing?  the only NBS I did was copy'n'pasting of the command the NBS page gives out :/
<persia> cjwatson, I guess, although I don't like that: I remember some missing packages when ubuntu-mid wasn't using a task.  I suppose it can be swapped from task to meta, the seed moved, LP fiddled, and livecd-rootfs moved back.
<cjwatson> it needs to be checked very carefully for kernel udebs
<cjwatson> I think sometimes it outputs too much when the kernel is mid-build on one architecture, aside from the other failings
<slangasek> cjwatson: which accounted for about 80% of a several-hundred-package-long list, sigh
<cjwatson> I basically apply a rule that I never NBS the current kernel version, which is perhaps a rule that should be hardcoded somewhere
 * persia will try to sort out the set of steps required to transition to a new seed, and file a bug outlining them for later discussion.
<cjwatson> regardless, we need to figure out how to get them back
<slangasek> (there were a lot of accumulated udebs in that list)
<slangasek> indeed
<cjwatson> (I usually feed it through xargs -n1 | egrep ... | xargs
<cjwatson> )
<slangasek> you've done udeb recoveries in the past somehow, I think?  Pinging of soyuz folks?
<slangasek> xargs> noted
<cjwatson> it was years ago
<cjwatson> not sure how many soyuz people will be around, but can try
<slangasek> should I just do a no-change upload of the kernel?
<persia> That's 16 hours for armel, and only covers the one kernel (there are several)
<cjwatson> let's see if we can recover without that
<cjwatson> only one kernel is affected afaik
<slangasek> which is the affected, linux?
<cjwatson> yeah
<cjwatson> I haven't exhaustively checked but I think just on armel
<cjwatson> missing packages: block-modules-2.6.35-19-omap-di block-modules-2.6.35-19-versatile-di fat-modules-2.6.35-19-versatile-di firewire-core-modules-2.6.35-19-versatile-di fs-core-modules-2.6.35-19-omap-di fs-secondary-modules-2.6.35-19-omap-di input-modules-2.6.35-19-versatile-di irda-modules-2.6.35-19-omap-di md-modules-2.6.35-19-omap-di md-modules-2.6.35-19-versatile-di message-modules-2.6.35-19-versatile-di ...
<cjwatson> ... mouse-modules-2.6.35-19-omap-di nfs-modules-2.6.35-19-omap-di nic-modules-2.6.35-19-omap-di nic-modules-2.6.35-19-versatile-di nic-usb-modules-2.6.35-19-omap-di pata-modules-2.6.35-19-versatile-di plip-modules-2.6.35-19-omap-di vlan-modules-2.6.35-19-omap-di vlan-modules-2.6.35-19-versatile-di
<persia> I have copies of all those files on my mirror, if someone wants to pull back and check the sigs.
<persia> (as armel udebs)
<cjwatson> no, that is not a problem
<cjwatson> they're all on the Launchpad librarian
<persia> Oh, right.
<cjwatson> they need to have the publishing records restored, that's all
<slangasek> cjwatson: if we don't get a response from soyuz by evening (my time), I think it'll be simpler for me to just do the no-change rebuild that I can shepherd through over the weekend
<slangasek> the build queue appears to be completely empty right nowv
<slangasek> so while it would mean waiting for a rebuild, there at least wouldn't be any contention
<cjwatson> slangasek: jpds was suggesting invoking the batphone, but perhaps you're right that that would be the simplest approach
<cjwatson> slangasek: could you take over any coordination required?  I need to go to bed
<slangasek> cjwatson: absolutely
<cjwatson> thanks
<stgraber> in case someone who knows a bit about the seeding magic is still around, I'd appreciate some help understanding why oem-config-gtk that I added to the dvd seed for edubuntu doesn't get included on the DVD where all other packages in that seed get on it
<stgraber> a local run of germinate seems fine and the logs on people.canonical.com don't show any error (though they don't show the inclusion of oem-config-gtk). The build scripts seem to be using the right revision of the branch, so I really don't get what's happening there.
<stgraber> (it's probably a very simple mistake/misunderstanding but after spending an hour looking at it, I really have no more ideas)
<persia> stgraber, oem-config-gtk doesn't appear to be in any tasks right now.  Maybe it needs a cron.germinate run to happen?
<stgraber> persia: well, that'd be weird because I pushed that seed change on the 8th of August and then another seed change (including gnome-nanny) on the 16th and the change of the 16th worked properly (as in, that package is now on our dvd)
 * lamont plays hardball with the amd64 ppa builders
<lamont> all better
<doko> ubuntu-archive: please consider accepting eglibc and binutils this weekend (no changes for generated code), needed for the linaro cross toolchain
<stgraber> uploading a new LTSP now, ideally that should be in beta as otherwise the LTSP install on ubuntu alternate is simply going to fail
<stgraber> I'm running a test install just now, if the new package works I'll upload it
<stgraber> tested and uploaded
<slangasek> cjwatson: I see that the kernel failed to build on all architectures. <sigh>
<slangasek> ogasawara: ^^ can you help me out?  I tried to do a no-change upload of the kernel to restore some udebs that I had accidentally removed; apparently the kernel doesn't *allow* no-change rebuilds, it complains about missing ABI files
#ubuntu-release 2010-08-29
<ogasawara> slangasek: which kernel failed to build?  I see everything successfully build for 2.6.35-19.26.
<persia> 19.27
<ogasawara> there's a there's a 19.27?
<persia> Some large number of udebs got deleted, so a no-change upload was attemtped to restore them...
<ogasawara> so we now need a 19.28?
<persia> https://launchpad.net/ubuntu/+source/linux/2.6.35-19.27
<persia> Right, and slangasek wanted an explanantion of why 19.27 completely failed to work
<ogasawara> I never uploaded a 19.27 so I 'm not sure where that even came from
<persia> (maybe more stuff ought be automatically calculated from the changelog entry or something)
<persia> Changelog is on that LP page.
<persia> http://launchpadlibrarian.net/54532084/linux_2.6.35-19.26_2.6.35-19.27.diff.gz is the diff
 * persia suspects most of the debian/control changes were unexpected by the uploader
<ogasawara> ok, gimme a few minutes to get the ABI in order and I'll upload a 19.28
<persia> Is there any documentation on what needs doing to allow no-change uploads in the future?  It's a rare need, but sometimes critical for release milestones (like this time)
<ogasawara> persia: basically the ABI directory within the kernel needed to be bumped to the previous upload, ie 2.6.35-19.26 when 2.6.35-19.27 was uploaded.
<ogasawara> I suspect it was still at 2.6.25-19.25 and thus failed the ABI checks
<ogasawara> s/2.6.25/2.6.35/
<persia> Right.  I think that's the bit of information slangasek was requesting (although cleaning up and uploading -19.28 would be much appreciated)
<ogasawara> yep, just want to get our git tree to match and will upload -19.28
<persia> Thank you.
<persia> Could someone accept that please?  Blocks d-i, which blocks beta for some architectures,
<ogasawara> Ah seems slangasek did a 2.6.25-19.28 as well.  So either the one he did or I did should be good to accept.
<persia> His is also ABI clean this time?
<ogasawara> persia: should be, according to his changelog and a quick scan of the diff
<persia> Hm.  Wonder why the bot didn't report it.
<ogasawara> looking at the timestamp it seems the bot's reported his, but not mine.
<persia> That makes me all sorts of confused, because if he was preparing that whilst you were discussing it, I'd think he'd have said something :)
<ogasawara> maybe he was head down getting it done.
<ogasawara> no worries either way.
<persia> yeah
<persia> now just needs an archive-admin around quick enough to take advantage of the relatively quiescent buildds.
 * ogasawara is going to cook some dinner.  I'll check back in a bit to make sure everything is good.
<micahg> is anyone available to push firefox through unapproved?
<slangasek> ogasawara: thanks, accepting yours so I don't cause even further skew from git
<slangasek> micahg: I'll have a look
<micahg> slangasek: thanks
<asac> anyone here? is there a linux-meta-linaro package in the queue?
<asac> please let it in if so ... the omap meta package isnt installable atm and linaro images fail ;)
<asac> gratias
<micahg> slangasek: any luck with Firefox?
<stgraber> pushed a new edubuntu-artwork package, we'd appreciate having it for beta but it's not critical (fixes our splash and icon theme)
<stgraber> something that really should go in though is that ltsp package I uploaded yesterday or beta won't have a working LTSP in Ubuntu Alternate
<stgraber> (as in, users will get a d-i red screen during the install)
<ScottK> stgraber: Did you see my question about the po file changes in the ltsp upload?
#ubuntu-release 2011-08-22
<slangasek> tumbleweed: did you have further comments on whether bug #829709 should get a freeze exception?  You haven't acked or nacked it, just commented on the sync-from-Debian question, and I'm not sure if that means you're evaluating it
<tumbleweed> slangasek: haven't evaluated it
<slangasek> ok
<tumbleweed> sync is probably ok from what I read, though
<tumbleweed> err not sync :)
<slangasek> right - and the sync route + "successfully transitioned to testing" isn't much use when it's not been uploaded to unstable yet
<slangasek> since that takes us into beta freeze at least
<tumbleweed> I how hoping delaying would make him upload to debian, but complaining about poor debian maintainership isn't really ubuntu-releases job.
<tumbleweed> (delaying a day or two)
<slangasek> for MOTU purposes, we obviously want to encourage people to make changes in Debian first, but this is a package actively maintained in Ubuntu whose upstream is the maintainer; I wouldn't like us to put up roadblocks to his Ubuntu maintenance
<tumbleweed> yeah
<slangasek> (syncing with Debian is still desirable - it just isn't kirkland's responsibility per se)
<kirkland> tumbleweed: slangasek: I'll blog up a request for a more active Debian Maintainer, as an aside, so that Debian/Ubuntu might have in sync byobus
<kirkland> (after talking to the current maintainer, of course)
<tumbleweed> ubuntu upstream of debian doesn't tend to be very standardised (and I haven't seen any packages doing this well, yet)
<tumbleweed> kirkland: I do see you've picked up a co-maintainer since the last upload, though
<kirkland> tumbleweed: who's that?
<tumbleweed> anarcat
<kirkland> tumbleweed: as for standardizing ubuntu as an upstream of debian, I'd love to lead the charge on that -- I have over a dozen packages (byobu, powernap, dotdee, ssh-import-id, testdrive, bikeshed, errno, run-one, musica, pictor, bogosec) that I simultaneously upload to Ubuntu and PPAs for each supported Ubuntu release;  I'd love to just upload to Debian at the same time, as users often ask why this stuff isn't in Debian too
<tumbleweed> in the past, there was utnubu, it seems to have died, but could be resurrected. One can just use Debain as upstream (as we do for ubuntu-dev-tools) and a couple of other packages have ubuntu-dev-team as their maintainer http://qa.debian.org/developer.php?login=ubuntu-dev this could be grown into something more useful
<tumbleweed> kirkland: FFe ACKed
<ScottK> kirkland: It should be easy enough with some sponsored uploads to get DM upload rights in Debian for your packages so you can just upload there and sync.
<kirkland> tumbleweed: in those cases, is the same code uploaded to both archives simultaneously?  or to Ubuntu, then sync'd to Debian, or to Debian then sync'd to Ubuntu?
<ScottK> Generally I upload to Debian and then ask for a sync, but if timing is tight for some reason I do dual uploads using syncpackage (that's why it was originally written).
<kirkland> tumbleweed: thanks
<cjwatson> for germinate I upload to Debian first and then sync
<cjwatson> the tools for working in that direction are better than for doing it in the other
#ubuntu-release 2011-08-23
<cjwatson> ScottK: kdenlive/armel removed (belatedly)
<ScottK> cjwatson: Thanks.
<cjwatson> (along with binaries from ktoon and qmmp)
<cjwatson> probably some others to do when I'm more awake
<tumbleweed> grr, more botched dh_python2 transitions. I've posted an announcement on the subject, if someone can moderate it
<pitti> tumbleweed: "FFe for build-system changes"? moderated
<tumbleweed> thanks
<ogra_> slangasek, i'm looking at cdimage code, to add my preinstalled tar.gz and .bootimg files to make-web-indicies, i see you added tar.gz handling, but name the files "UEC/EC2 tarball" ... i would like to make the first part conditional, but there doesnt seem to be any other UEC related code in our tree
<ogra_> ... so i wonder if that code bit is actually used at all on our side, seems the server team has a forked tree of cdimage for the cloud stuff anyway
<cjwatson> we do release publication of cloud images and make-web-indices needs to support that
<cjwatson> so yes, it is used
<cjwatson> hm, that said I can't actually find a real case of that, maybe I'm confused
<cjwatson> still, seeing as I don't know exactly how they're using that, I'd prefer if it were conditional.  Perhaps you could talk with smoser?
<ogra_> just doing that, they seem to have a totally separate tree for everything
<smoser> "totally separate" = "old"
<smoser> it was branched ~ 9.10 release time, and never merged.
<smoser> i'm willing to do a merge, but i need an upstream source
<cjwatson> doko: I'm inclined to remove wvstreams and its (small) reverse build-dep tree on armel, unless you object - see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521473
<cjwatson> basically takes out wvdial, pathfinder, gnome-ppp
<doko> cjwatson, I'm fine with it
<cjwatson> done
<charlie-tca> Can someone please check what is happening to the ubuntustudio images. There have been no images for several days now, only errors showing are:
<charlie-tca> W: Failed to fetch file:/srv/cdimage.ubuntu.com/ftp-universe/dists/oneiric/main/binary-amd64/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> many times in the logs
<cjwatson> as explained many times before the only thing I can do is retry them (which I've now done)
<charlie-tca> Thank you for looking, at least!
<charlie-tca> I know there is little you can do with that, but at least you know to keep trying it.
<cjwatson> hmm, one possible problem does come to mind.  I wonder how to fix it ...
<cjwatson> (if a main-only image is building at the same time, then build-image-set will wait for it to sync without arranging for the universe part of the mirror to catch up)
<charlie-tca> Then it has to be started again, right?
<cjwatson> I mean, a crude fix is trivial, but I don't want to disable the ability to have parallel builds in general
<cjwatson> right, but it can't sync the main part of the mirror because there's an image building at the same time, and if it syncs only the universe part then the same thing might happen but in the other direction
<cjwatson> (i.e. universe newer than main)
<cjwatson> I guess I need to do something like ensuring that the build already in progress has synced a superset of the archive required by the build that's trying to start, or else something completely disjoint (e.g. ports)
<charlie-tca> So, simple terms, if it doesn't build, someone should notify in this channel, to have another build started for it?
<cjwatson> but that sounds really fiddly.  I'm just going to shuffle the cron job times around to try to reduce the incidence of this
<cjwatson> yes
<charlie-tca> Thank you.
<cjwatson> general reminder: *please* use the kernel-overrides script to process new kernel uploads through the NEW queue.  I just found that almost the entire set of linux binaries in lucid-proposed was in universe
<cjwatson> it really doesn't take long at all (much quicker than it used to be) and it avoids mistakes
<cjwatson> charlie-tca: I've moved the ubuntustudio build 12 hours later (or earlier :-) ) to hopefully avoid this
<charlie-tca> Thank you. Let's see what it does
<stgraber> skaet: I just turned the current ltsp-live bug that's critical to Edubuntu into a FFe as the "fix" is a full rewrite. Would be great if you could +1 :) bug 791611
<ubot4> Launchpad bug 791611 in ltsp (Ubuntu) "[FFe] LTSP live doesn't work with new Network Manager (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/791611
 * skaet looking
<stgraber> I'm currently busy testing everything else works for Edubuntu, then will test the new code in the live environment and push the new edubuntu-live with the new version
<stgraber> (My goal is to have Edubuntu feature complete and fully tested by UI freeze so I don't have to touch it till release (and can focus on Ubuntu) :))
<skaet> stgraber,  sounds reasonable.   I've +1'd the change as long as it is in by UI/beta freeze.
<stgraber> skaet: thanks
<cjwatson> could somebody review my debian-installer uploads to lucid-proposed and maverick-proposed?  the kernel team are waiting on that for some SRU verification work
<doko> seb128, any chance to get the colord issue resolved before beta freeze?
<seb128> doko, dunno, ask kees he's the one blocking it
<seb128> RAOF said he will have a version running as its own user tomorrow
<seb128> but I'm not sure if kees had other blocking issues still after that
<kees> if it's running as non-root, I'm fine with it.
<seb128> kees, thanks
<seb128> doko, so should be sorted tomorrow
<doko> seb128, kees: cool, thanks!
<seb128> doko, btw do you know who is maintaining libsigc++?
<seb128> doko, it should be updated for bug #829596
<ubot4> Launchpad bug 829596 in glibmm2.4 (Ubuntu Oneiric) (and 1 other project) "glibmm2.4 version 2.29.11-0ubuntu1 failed to build in oneiric (affects: 1) (dups: 1) (heat: 11)" [High,Confirmed] https://launchpad.net/bugs/829596
<doko> seb128, desktop stack ;-P
<seb128> ok ok :)
<doko> and/or aptitude, so please coordinate with mvo
<seb128> will do
<slangasek> cjwatson: d-i lucid/maverick accepted
<gilir> is someone know why lubuntu daily ISO are not generated since the 18 ?
<slangasek>  console-setup : Conflicts: console-terminus
<slangasek> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/lubuntu/20110823/livecd-20110823-i386.out
<slangasek> if he comes back :)
#ubuntu-release 2011-08-24
<ScottK2> Fun day.  Multiple customer crisis and an earth quake.
<ScottK> Hurricanes and tornadoes I'm prepared for.  Earthquakes not so much.
<nigelb> ScottK: Everything okay? :)
<ScottK> Sure.
<ScottK> Turned out fine, but I was on the 11th floor of a building when it hit and we don't have really serious earthquake related building codes here like in California.
<ScottK> So I didn't know for sure it the story was going to have a happy ending.
<nigelb> heh
<cjwatson> ScottK: phew, narrow escape
<iulian> Uhh.
<cjwatson> ScottK: re libsmokekate3, I notice that it has rdepends outside that source package - libkate-perl and ruby-kate.  Will you sort those out after the smokekde sync builds?
<ScottK> cjwatson: I will.
<Laney> I'm guessing we shouldn't care so much about getting AA pre-approval for NEW (source) syncs from Debian?
<cjwatson> no need for AA approval for that
<Laney> thought so, cheers
<cjwatson> NEW from Debian is fractionally more work than existing packages, but not much as we trust to Debian review
<cjwatson> massively easier than NEW directly in Ubuntu
<ogra_> cjwatson, hmm, something is wonky with the cdimage branch on antimony
<ogra_> (did you commit directly ?)
<cjwatson> no, I committed then changed my mind and uncommitted, but forgot to uncommit the deployed tree as well
<cjwatson> fixed now
<ogra_> ah, thx
<ogra_> yup, works
<cjwatson> sorry about that
<ogra_> np
<ogra_> i make more mess in a week than you do i a cycle :) no need for excuses
<Daviey> ogra_: Did you manage to make the tarball string conditonal?
<ogra_> yes
<Daviey> ogra_: rocking!
<ogra_> should be fine ... if the PROJECT matches uec or uec-server it is now called "Cloud Images tarball" as you asked
<ogra_> err s/uec-server/server-uec/
<ogra_> otherwise its just "filesystem archive"
<Daviey> ogra_: great!
<ogra_> note that this will only affect the release, for renaming in your daily builds you will likely need to change it in your tree
<ogra_> (the naming i mean)
<Daviey> ogra_: Yeah.. utlemming and smoser will be closing the fork eventually. :)
<ogra_> right, just wanted to mention that you need to change it in two places
<Daviey> ogra_: thanks
<charlie-tca> Can someone hit the server to respin the Xubuntu Alternate images please.
<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
<cjwatson> in progress
<charlie-tca> Thank you
<stgraber> can I get a rebuild of Edubuntu? It failed to build last night and I need to test an up to date livefs. Upgrading the latest one is a 500 packages upgrade so that won't work with aufs :)
<cjwatson> stgraber: running
<stgraber> cjwatson: thanks
<astraljava> Hey guys, as I understand it, the image spin for Ubuntu Studio was recently changed. I'd like our seeds updated, so that we could continue testing the images. Normally, TheMuso has uploaded them, but seeing that he's probably asleep at the moment, I wondered if there's anyone else who could do that for us?
<tumbleweed> skaet: I don't think UI freeze matters for new universe packages (wallch), but I do agree that the exception shouldn't be valid forever
<astraljava> cjwatson: I don't suppose you have time to upload Studio's seeds? Pretty please? :D
<charlie-tca> cjwatson: Congratulations!
<ScottK> tumbleweed: I agree.  U/I freeze is "talk to the docs people so they can keep up", so unseeded packages aren't really relevant.
<seb128> could somebody review bug #833172 for dx? it's needed for unity cjk support
<ubot4> Launchpad bug 833172 in xapian-core (Ubuntu) "[FFE] CJK support (affects: 1) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/833172
 * iulian looking.
<iulian> 1.2.7-1 is already in Debian.
<iulian> Oh wait.
<iulian> The patch is not included.
<seb128> the patch is a svn backport, it will be in 1.2.8
<iulian> Indeed. I hope you guys tested it and nothing breaks. If it does, then it will be quite bad.
<seb128> dx has been testing it and some canonical oem team people have been testing it
<seb128> it also got reviewed and included in upstream svn
<iulian> Brilliant. Approved.
<seb128> iulian, thanks
<skaet> tumbleweed,  ScottK,  fair enough,  right now the FFE process says exceptions considered up until beta.  Any objection to taking a pass through the universe ones with open ended FFEs, and date limiting them if they're still open as of Beta Freeze?
<tumbleweed> that sounds good
<cjwatson> astraljava: sure (I did a while back, unsolicited)
<cjwatson> astraljava: not sure what you mean by "the image spin for Ubuntu Studio was recently changed" - I did change the daily build time to reduce the change of clashes
<cjwatson> charlie-tca: thanks :)
<astraljava> cjwatson: Yeah I was referring to the time actually, sorry for the poor wording. That's actually why I asked for the upload, cause I just recently pushed a new commit, and wanted that to be included for the spin this evening. Thanks for your help!
<astraljava> Probably missed today's images, though. Seems my commit hit LP a minute before the amd64 image was created. :) Oh well, there's always tomorrow.
<cjwatson> you've missed todays, yes
<cjwatson> *today's
<astraljava> No prob. Thanks again for your help!
<gilir> cjwatson, is your changes on daily build time affect lubuntu ISO ? the generation stopped since the 18
<charlie-tca> gilir: console-setup : Conflicts: console-terminus
<charlie-tca> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/lubuntu/20110823/livecd-20110823-i38
<charlie-tca> 6.out
<charlie-tca> well, let me fix the link there, then
<charlie-tca> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/lubuntu/20110823/livecd-20110823-i386.out
<charlie-tca> That seems to be the issue
<gilir> ah, I forgot to look at the log, thanks charlie-tca :)
<charlie-tca> No problem
<charlie-tca> Just gave the information to Unit193, so had it handy
<cjwatson> gilir: no, I didn't change Lubuntu's build time.  Would you like to be subscribed to failure notifications?
<cjwatson> (I thought I'd done that, but you're not listed)
<charlie-tca> Took me forever to learn to look in the logs. I thought cjwatson was going to murder me, he had to tell me so many times
<cjwatson> console-setup is fixed
<cjwatson> charlie-tca: heh
 * cjwatson is a pacifist :)
<charlie-tca> That's a really good thing. cjwatson is patient, too.
<jibel> gilir, latest is 24 and fails because ubiquity-frontend-gtk tries to overwrite '/usr/lib/libwebcam.so.0', which is also in package libwebcam0 0.2.1-1
<cjwatson> yeah, that's fixed too, latest upload
<cjwatson> livefs builds are pretty sensitive to the state of the archive
<charlie-tca> gilir: if everything is fixed, you can ask for a build now
<gilir> cool thanks :)
<cjwatson> I've kicked off a Lubuntu build
<gilir> cjwatson, thanks :)
<cjwatson> gilir: should I subscribe you to failure notifications?  if so, tell me an address to use
<charlie-tca> gilir: that's a email tells you when the image fails to build, and gives a log of the failure.
<gilir> cjwatson, yes, that should be perfect, you can use my gilir at ubuntu address
<gilir> cjwatson, also, is it possible to build alternate image ? is there something special to do to the seed or to the ISO build system ?
<cjwatson> gilir: notifications> done
<cjwatson> gilir: it's possible, but I think at this point new images require an FFe ...
<cjwatson> I can take care of the work if you get it approved
<gilir> cjwatson, ok, I can write the FFe, do I need to affect it to a special project or package in launchpad ?
<cjwatson> uh, I guess just lubuntu-meta or something, then reassign it to the ubuntu-cdimage project after approval
<cjwatson> but make sure the ~ubuntu-release team is subscribed
<cjwatson> probably best to have it on an Ubuntu package to start with even if that's a bit artificial, since I'm not sure what searches everyone uses to generate the outstanding FFe list and it's possible that some people use something based on bugs.launchpad.net/ubuntu
<cjwatson> (I think bugs.launchpad.net/~ubuntu-release/+subscribedbugs is canonical though)
<gilir> ok, I'll do that, thank you :)
<slangasek> bugs.launchpad.net/~ubuntu-release/+subscribedbugs picks up any foreign tasks attached to FFe bugs unfortunately
<cjwatson> slangasek: ah, unfortunate ...
<cjwatson> gilir: hmm, bah, less than entirely useful failure mail there
<cjwatson> but at least it tells you it went wrong ...
<cjwatson> (it's usually better than that)
<slangasek> presumably this is the mail on a manual build?
<cjwatson> yeah
<cjwatson> oh, it has a datestamp sync problem doesn't it
<slangasek> yep
<cjwatson> we should really integrate buildlive into the main build-image-set process somehow
<cjwatson> although I suppose it doesn't entirely help because the livefs datestamp may unavoidably be different ...
<slangasek> yeah, exactly :/
<cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/lubuntu/20110824.1/livecd-20110824.1-i386.out - ubiquity again, looks like 2.7.16 failed to build
<astraljava> Is it a known fact that usb installs are a no-go at this moment?
<ScottK> skaet: I think for U/I freeze the important question is included in some flavor doc package or not so it's more like seeded/unseeded than Main/Universe.
<tumbleweed> ScottK: on the other hand, FFes shouldn't be open ended
<tumbleweed> and we shouldn't grant them until they are needed
<ScottK> True, but FFe is always a question of risk versus benefit.
<ScottK> There's no hard and fast.
<tumbleweed> of course, they are, after all, exceptions to the rules
<skaet> ScottK, as long as we manage expectations by setting a window to upload into and don't leave things open ended, my main concern will be addressed.   Some of the packages while not seeded are nice to haves, and knowing if they'll be available, is important.
<ScottK> I'd think the window to upload into was before the freeze, but OK.
<Laney> wallch better be awesome, for the amount of effort it has taken...
<tumbleweed> Laney: you should read the source :(
<tumbleweed> unfortunately a few of us got guilted into looking at it a while ago and now feel committed to see it through...
<ajmitch> tumbleweed: you say that like it's a bad thing :)
<tumbleweed> well, I wish he'd learn faster
<ajmitch> not everyone learns quickly
<Laney> what can we learn from this, though? should people only request NEW ffe when the package is actually ready?
<tumbleweed> which can obviousuly demotivate people from working post FF on something that'll require an exception
<slangasek> astraljava: probably not; installability doesn't get looked at much in the time between milestone testing.  You're trying to install from a daily?
<astraljava> slangasek: Yes, Xubuntu daily, i386. charlie-tca mentioned he had learnt that installing from usb had had shown difficulties. I tried creating the stick first with usb-creator, and then with unetbootin, both of which fail to launch ubiquity.
<astraljava> -had
<cjwatson> there was a report about trouble with the --desktop option
<cjwatson> bug 831812
<ubot4> Launchpad bug 831812 in ubiquity (Ubuntu Oneiric) (and 3 other projects) "ubiquity fails to start when called with '--desktop %k' and libglibmm-2.4-1c2a 2.29.11-0ubuntu1 (affects: 2) (dups: 1) (heat: 16)" [Critical,Triaged] https://launchpad.net/bugs/831812
<Laney> it should be the exception that NEW stuff is asked for after FF, so it's not that unreasonable
<astraljava> cjwatson: Alright, but I also tried to initiate it by Alt+F2, "ubiquity -d", with same results.
 * cjwatson fixes up the ubiquity build failure
#ubuntu-release 2011-08-25
<micahg> do I need an FFe to reseed a package we temporarily dropped due to it being broken?
<micahg> s/we/that was/
<pitti> when was it dropped?
<micahg> pitti: aug 2
<pitti> micahg: hm, that seems a bit on the edge -- better file an FFE, I think
<micahg> if someone could look at bug 833550 in the next couple hours, I'll get this uploaded before beta freeze
<ubot4> Launchpad bug 833550 in xubuntu-meta (Ubuntu) "FFe: Please reseed aisleriot (affects: 1) (heat: 8)" [Wishlist,New] https://launchpad.net/bugs/833550
<pitti> ah, that
<pitti> micahg: yes, that sounds fine
<pitti> bug updated
<micahg> pitti: thanks, maybe I should've been more verbose in my question :)
 * pitti goes to dissect the alternate and see why it's so big
<pitti> ok, so it ships 135 MB of packages which are not in the default installation
<pitti> it should be possible to reduce some of that :)
<pitti> cjwatson: do you still think linux-wlan-ng is good to have on the alternates? it hasn't changed since lucid, does that even work still?
<pitti> not that it's much of an issue size-wise (100 kB), but it might just be cruft these days
<slangasek> I think it still works for the few wireless chipsets that need it
<pitti> ah, good
<pitti> anyway, there: http://cdimage.ubuntu.com/daily/20110825.1/
<pitti> non-oversized alternates
<pitti> (except powerpc, which seems to be a lost cause)
<pitti> actually, we could drop pt/es langpacks there, /me does
<pitti> there, next daily powerpc alternate should be in shape, too
 * cjwatson has another go at updating ubuntustudio-meta, which he tried and failed to do last night due to mirror issues of some kind
<pitti> hey cjwatson, good morning
<cjwatson> mornin'
<cjwatson> phew, I think that's the gnustep transition done
<cjwatson> meh, I should have just uploaded gnudatalanguage rather than trying to test-build it first
 * cjwatson feeds his laptop more hamsters
<cjwatson> astraljava: ubuntustudio-meta uploaded, belatedly
 * ogra_ feels pity for the hamsters ... you surely need to flatten them for the hamster slot, or is your laptop that thick ?
<cjwatson> it's not quite a hoverbook if that's what you're asking
<ogra_> nah, i was just wondering about hamster usability vs. laptops
<Daviey> cjwatson: Use the cloud! :)
 * ogra_ imagines hamsters with parachutes
<Daviey> ogra_: Sounds a worthy experiement.
<ogra_> :)
<ogra_> GRR
<ogra_> so i'm sure i saw a patch for ext4 support in live-build going upstream, why doesnt it produce rootfs files now :(
<ogra_> funnily everything else gets created
<ogra_> ogra@horus:~/devel/live-build-3.0~a24$ grep -r ext4 *
<ogra_> ogra@horus:~/devel/live-build-3.0~a24$
 * ogra_ cries
<Daviey> ogra_: I didn't think your kernel supported ext4 at the moment, anyway?
<Daviey> supported as in config option disabled.
<ogra_> Daviey, hey, i'm not linaro :P
<ogra_> only their vexpress kernel doesnt support ext4, i think all others do
<Daviey> ogra_: Ah.. Yes.. I just blame you for arm related things in ubuntu. :)
<ScottK> pitti: I'd appreciate it if you could accept the updated clamav package I just uploaded for natty-proposed.  It's a minor improvement over the one that's there now (and what I'd like to get verified and into updates).
<pitti> ScottK: sure, will do; I give LP a few more minutes to generate the debdiff
<ScottK> Thanks.
<ScottK> Is there some general FFe the applies to Unity and related stuff?  I say reference to some Unity changes planned for today and I see https://lists.ubuntu.com/archives/ubuntu-devel/2011-August/034015.html but I don't see any related FFes.
<pitti> ScottK: the feature has been in Ubuntu for a while
<ScottK> OK.  0.3.3 isn't.
<pitti> right
<ScottK> Maybe it's just a bugfix update.
<pitti> I haven't see the changes yet, but I hope they just apply fixes
<pitti> right now the "Printer" entry in the menu spawns system-config-printer, which seems fine
<pitti> and "webcam" leads me to software-center to install cheese
<seb128> right, the new version is only bug fix in the 0.3 serie
<seb128> it's just that conor didn't made call for testing before
<seb128> the feature are there since before ff
<ScottK> OK.
<ScottK> Is today's release of unity-2d referred to here: https://lists.launchpad.net/ayatana/msg06327.html also bugfix only?
<pitti> ScottK: would you mind to reupload clamav with -v to catch the previous proposed changelog for #810270 #826828  ?
<ScottK> pitti: I don't mind.  I should have done that.
<pitti> ScottK: thanks, rejecting the current one
<ScottK> pitti: Uploaded.  You should see it in a bit.
<pitti> does any release team member have an opinion about bug 832740?
<ubot4> Launchpad bug 832740 in apport (Ubuntu) "FFE: chroot-less apport-retrace (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/832740
<pitti> it's not the most important bit in the world, but makes crash debugging quite a bit easier/safer, and is not very risky IMHO
<pitti> the proposed apport-retrace has just finished to catch up on ~ 1000 LP bugs, so I call it pretty stable :)
<ScottK> pitti: I'd say put it in
<ScottK> (meant to say that in the bug yesterday, but was stuck with no connectivity at the time)
<pitti> skaet, cjwatson: do you have an opinion on bug 830901 ?
<ubot4> Launchpad bug 830901 in software-center (Ubuntu) "[FFE] Switch default UI from gtk2 to gtk3 (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/830901
<cjwatson> I'd rather excuse myself from that since I know mvo has put lots of work into it and he's on my team, so I don't know if I can be objective
<pitti> the "stability matter" part in me is against it, while part that considers what has upstream's attention now, and my "yay gtk3" parts say "let's try"
<pitti> cjwatson: ok; I don't feel completely unbiased myself, as I have put some work into it, too
<cjwatson> I agree that the banner needs to be fixed
<cjwatson> oh, I should upgrade :)
<pitti> it's a lot less hilarious now, just not any smaller
<mvo> the size is a design decision AFAIK
<cjwatson> it's a bit unfortunate that the categories list doesn't fit by default and there's no way to scroll it
<cjwatson> oh, yes there is, just impossible to see with the dratted minimal scrollbar
<cjwatson> and if you scroll then the banner scrolls too, so that's not so bad
<pitti> mvo: if you'd do the switch now, would the gtk2 variant still be shipped?
<cjwatson> I do *like* the new UI
<mvo> pitti: we can do that, yes, we don't have to
<pitti> mvo: so we could test it in beta-1, and if it causes too many problems/bugs, switch back with an one-line change, right?
<pitti> mvo: that wouldn't help us for python-gmenu, but we need a solution for that anyway
<pitti> (presumably by reintroducing the old source)
<pitti> ScottK: woudl you mind commenting on 832740 for the ack?
<mvo> pitti: right, that is a valid approach I think, get as much exposure as possible for b1 and if the sky falls we can revert
 * ScottK looks
<pitti> mvo: OOI, what changed your mind? in previous meetings tremolux and you usually said "that's for the next cycle"
<ScottK> pitti: Done.
<pitti> ScottK: cheers
<mvo> pitti: we got *awsome* community work behind that
<mvo> pitti: it would not be possible without them
<skaet> pitti, mvo, cjwatson,  +1 to try it for beta-1, and if it causes unexpected/too many issues revert back for beta-2.
<pitti> mvo: ok; go!
<pitti> mvo: updated bug
<pitti> mvo: I'd still like the billboard to be smaller, but oh well
<skaet> mvo,  can you write up an overview for the release notes, and some instructions for the here's how to work around.
<skaet> just in case
<pitti> people could run "software-center" as a workaround, right?
<mvo> skaet: sure, will do
<mvo> pitti: yeah
<seb128> skaet, pitti, cjwatson, mvo, ScottK: would be nice if you go for the gtk3 if you would grant a ffe for didrocks's oneconf as well when he comes back next week
<seb128> he has been porting his work back to gtk2 because we told him that's what oneiric would use
<seb128> he will likely be disappointed if he misses being in Oneiric due to that, he has been trying to get oneconf in for 2 cycles
<pitti> whee, power outage, running on battery/3G now; I might have missed stuff after "pitti | people could run "software-center" as a workaround, right?"
<skaet> seb128, will see where we are then next week and if things aren't too bumpy will let didrocks know.
<seb128> pitti,
<seb128> <mvo> skaet: sure, will do
<seb128>  pitti: yeah
<seb128> <seb128> skaet, pitti, cjwatson, mvo, ScottK: would be nice if you go for the gtk3 if you would grant a ffe for didrocks's oneconf as well when he comes back next week
<seb128>  he has been porting his work back to gtk2 because we told him that's what oneiric would use
<seb128> pitti, that's what you missed
<pitti> seb128: ah, that seems like a logical consequence
 * skaet nods
<kengyu> wonder if anyone has the spare timeslot for review the FFE of bug 833745 for me...
<ubot4> Launchpad bug 833745 in ubuntu "FFe: Sync urfkill 0.2.0-1 (universe) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New] https://launchpad.net/bugs/833745
<kengyu> hope I can make it in time...
<Kaleo> new FFE for Unity 2D: https://bugs.launchpad.net/ubuntu/+bug/833800
<ubot4> Launchpad bug 833800 in ubuntu "[FFE] New upstream release of Unity 2D: 4.2 (affects: 1) (heat: 6)" [Undecided,New]
<seb128> ScottK, ^ you were asking about that
<ScottK> seb128: Thanks.
<Kaleo> :)
 * ScottK thinks pitti would be the best one to review it.
 * pitti is very laggy, for some reason I got about 5 IRC /msg queries in the past 5 minutes
<pitti> must be "west coast getting up" time or so
<pitti> looking
<Kaleo> pitti: I'm sorry if the FFE is not filed properly, I'm fairly new to this
<Kaleo> pitti: I just replied
<seb128> pitti, what's the status on unity-2d? we need a rebuild because of the other unity component updates
<seb128> so either no change rebuild of what we have or the new version
<seb128> the no change rebuild depends if we think we will have 2d sorted in the next few hours or not
<pitti> re
<pitti> meh, yet another power outage
<pitti> Kaleo, seb128: bug 833800  approved, based on it being a feature regression
<ubot4> Launchpad bug 833800 in ubuntu "[FFE] New upstream release of Unity 2D: 4.2 (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/833800
<seb128> pitti, thanks
<Kaleo> pitti: fantastic :)
<seb128> ok
<seb128> the unity stack got updated for beta
<seb128> got it all in on time ;-)
<mdeslaur> what time is beta freeze?
<tumbleweed> freezes are 00:00 UTC unless a time is announced
<seb128> 21utc is the time skaet announce in her email
<mdeslaur> ah, cool, still some time. :)
<mdeslaur> thanks
<pitti> skaet: ah, I just landed the last fix for bug 829186 upstream, dobey is making releases now
<ubot4> Launchpad bug 829186 in usb-creator (Ubuntu) (and 12 other projects) "Mixes static and GI library bindings (affects: 2) (heat: 12)" [Undecided,Fix released] https://launchpad.net/bugs/829186
<pitti> skaet: that was the bug that blocked the newer pygobject
<pitti> so I'm doing the syncs now, better to test this in beta-1
<skaet> thanks Martin. :)
<pitti> and a lot of us were using the packages from experimental
<pitti> for about two weeks, so it should be reasonably safe
<skaet> when will the new langpacks be landing?
<ScottK> Could I get a respin of the Kubuntu arm images after the current publisher run finishes?  They all failed due to archive skew and I think it's all aligned for the moment.
<skaet> ScottK, kubuntu daily-preinstalled and kubuntu-mobile daily-preinstalled?
<ScottK> skaet: Not the mobile ones, just regular Kubuntu.  Thanks.
<pitti> skaet: drat, ubiquity segfaults with new pygobject; I guess that counts as a blocker..
<pitti> skaet: the export should finish tomorrow morning, then I'll build/test/upload them
<pitti> skaet: I can bump the few langpacks which are on the CDs, so we can already have images tomorrow (provided that they are installable after today's huge churn)
<skaet> pitti,  re: ubiquity - yup, drat. :(  bug number?
<pitti> skaet: none yet, I don't even get an apport crash, just see a segfault in strace
<pitti> skaet: I'll add the task to above bug
<skaet> pitti, re: langpacks sounds good.
<pitti> skaet: at this point it might actually be safer to land the pygobject stuff post beta-1, WDYT?
<skaet> pitti,  if it looks like its going to be problematic - yeah, lets push it to day after beta 1
<pitti> skaet: darn, I got everything else fixed.. but c'est la vie
<pitti> skaet: do you plan to freeze the archive at 2100 UTC?
<pitti> skaet: or soft-freeze?
<pitti> (traditionally we used hard freeze for beta, to get peer review)
<skaet> pitti, given the churn going on,  hard freeze
<skaet> so we can get the peer review.
<pitti> agreed
<skaet> pitti,  I'll be around and will ask losa
<skaet> and send out the note
<seb128> pitti, what error? jibel and ev reported a bug earlier today maybe you got unlucky and ran into the same issue?
<pitti> seb128: no, it just doesn't start up at all
<seb128> ok
<pitti> I'm adding print statements everywhere to narrow it down
<astraljava> cjwatson: Thank you so much! :)
<jibel> pitti, seb128 referred to bug 831812, that mterry just fixed. ubiquity didn't start, are you facing a different issue ?
<ubot4> Launchpad bug 831812 in ubiquity (Ubuntu Oneiric) (and 4 other projects) "ubiquity fails to start: Gtk:ERROR:/build/buildd/gtk+3.0-3.1.12/./gtk/gtkcssprovider.c:1275:gtk_css_scanner_new: assertion failed: (data[length] == 0) (affects: 3) (dups: 2) (heat: 24)" [Critical,Invalid] https://launchpad.net/bugs/831812
<pitti> jibel: well, it could be
<pitti> but I'm getting a segfault
<pitti> jibel: symptom is that "sudo ubiquity" just returns immediately and nothing happens
<pitti> and strace sees a SIGSEGV in the child
<pitti> well, maybe I'm chasing a red herring here
<pitti> I guess I'll wait for the GTK 3 fix to build and try again
<astraljava> Could anyone explain what's going in here? http://paste.ubuntu.com/674763/ Basically, Studio images are not building due to "Missing debootstrap-required python3"
<pitti> jibel: no, new gtk doesn't help :/
<jibel> pitti, which arch and are you running on HW or VM ?
<pitti> jibel: VM
<pitti> but ubiquity starts fine on today's live CD (sudo ubiquity)
<pitti> but crashes with pygobject 2.90
<slangasek> astraljava: python3 is no longer a dependency of lsb-release, but is still marked Priority: important; the CD build scripts balk at mismatches here since it means there's an archive inconsistency of some kind and it doesn't trust the output.  I've updated python3's priority now, so the next build should work again, thanks
<astraljava> slangasek: Okay, cool. Thank you!
<seb128> skaet, hey
<skaet> seb128,  yup?
<seb128> skaet, we will play a bit over the margin freeze for unity, I'm about to upload a new bug fix and an unity point update to fix some issues from the tarball rolled earlier
<seb128> skaet, just to let you know
<seb128> "new bug fix" -> "nux bug fix"
<seb128> is that ok?
<skaet> seb128, how much longer
<seb128> rolling the update now, I can upload in a few minutes
<seb128> skaet, 5-10 minutes?
<skaet> ok,  I'll go ping the LOSA after you signal its been updated.
<seb128> thanks
 * Daviey sobs.
 * skaet hands Daviey a tissue
<infinity> Anyone have any qualms about me syncing a (NEW) ocaml binding from sid to fix the fact that liquidsoap has been FTBFS for a month?
<infinity> (All universe stuff)
<infinity> ocaml-voaacenc being the binding in question.
<skaet> infinity, unseeded or not?
<infinity> skaet: Very unseeded.
<infinity> Just tidying up ocaml stuff from top to bottom and noticed liquisoap's been patiently dep-wait on a non-existant binding since it was synced a month ago. :P
<skaet> no qualms from me then.
<infinity> liquidsoap itself needs a sync to fix the FTBFS too, it looks like, but that's not particularly controversial.
<skaet> ScottK,  kubuntu arm images building
<ScottK> Thanks.
<slangasek> Daviey: bug #827831 seems to have been quiet for the past week; when do you think you'll have the evidence you need to decide to go forward with it?
<ubot4> Launchpad bug 827831 in qemu-kvm (Ubuntu) "[FFE] Upgrade qemu-kvm for oneiric to version 0.15 from upstream (affects: 1) (heat: 13)" [Low,New] https://launchpad.net/bugs/827831
<slangasek> Daviey: (I'm thinking of piggy-backing qemu-linaro onto it if it's accepted)
<Daviey> slangasek: Well it seems to be good... Are you looking to do it inside the freeze window, or post beta1?
<slangasek> Daviey: qemu-linaro is unseeded, so can probably go in any time provided that there's an FFe for the new upstream qemu bits
<Daviey> slangasek: Yeah.. The reason i ask is that A) Serge who would be picking up the bits if it goes wrong is on leave this week.. and B) A few of the server team are trying to use that unoffical package to sniff it.. So i planned to really push for it just after beta1.
<slangasek> sure - no particular hurry on qemu-linaro anyway
<Daviey> slangasek: Will keep you in the loop, if you want to sniff his PPA package aswell.. I would be overjoyed :)
<infinity> The point of a beta is the get testing. :P
<infinity> If you're worried it will be FTBFS or uninstallable and break our images, sure, wait, but if you're just worried it might have some bugs to shake out, I say bring it on.
<infinity> But that's just me.
<infinity> So many more people test betas than dailies, after all.
<Daviey> infinity: Yeah, but testing the limbs is pretty importiant, not ripping the heart out and leaving the limbs to dangle.
<slangasek> Daviey: I'm not a good stress-tester of qemu-kvm, I'm currently not using kvm for anything because virt-manager is broken for me ;P
<slangasek> (though maybe I should retest, it's been a few weeks now)
<infinity> (Also, I'm a Xen user, so I might just be trying to sabotage you)
<Daviey> infinity: Considering these are the heart of server at the moment, i'd be pretty frustarted if the server beta is crap because of this.
<infinity> Daviey: There's that, yes.  It's your call.
<Daviey> slangasek: virt-manager has never worked for anyone, has it?
<slangasek> heh
<slangasek> it worked for me at UDS-N
<mdeslaur> uhm...virt-manager is supposed to work...
<mdeslaur> if not, file bugs and/or bug me
<slangasek> sure thing - once I get a chance to try it again :)
<seb128> skaet, ok, uploaded
<slangasek> mdeslaur: vague problem description: failed to create a new profile, using an LVM LV as backing store, with the error "setup failed to retrieve chardev info"
<skaet> thanks seb128
<Daviey> mdeslaur: Yes, sorry - i didn't mean to poo-poo the work you had done.. I think i am tainted from it being really bad ~2 years ago.  Sorry.
<mdeslaur> slangasek: oh, hrm...there may be a bug about using an lvm backing store...I'll take a look at that again when I come back from holiday
<mdeslaur> Daviey: that's alright :)
<skaet> archive is now FROZEN.
<infinity> \o/
<Daviey>  /o\
<infinity> /o/
<ScottK> \o_
<jibel> ~Ã´~
<infinity> I wish I remembered semaphore.
<skaet> lol,  me too.  :)
<ScottK> It's officially been retired (at least by the USN)
* skaet changed the topic of #ubuntu-release to: 11.10-beta1 Freeze is in effect | Oneiric Ocelot Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team with beer  | we accept payment in cash, check or ocelot food | melior malum quod cognoscis
<iulian> Heh, trying to be super op? :)
<skaet> iulian,  just finger fumbles with drop down menus :P
<astraljava> Anyone know how I can bypass the missing platform.oneiric seed while running germinate locally?
<infinity> astraljava: See #-devel.
<astraljava> infinity: Thanks!
<slangasek> mdeslaur: ahh ok, thanks :)
<doko> oops, the php5 should have gone to the ppa ...
<doko> skaet, archive still seems to be open
<slangasek> heh
<slangasek> you touched it last!
 * slangasek wipes his hands and runs away from php5
<doko> bah
<SpamapS> I believe I have a simple resolution to bug 791607 .. which is against eucalyptus (in universe now). Is it ok to upload that fix now during beta freeze?
<ubot4> Launchpad bug 791607 in eucalyptus (Ubuntu Oneiric) (and 1 other project) "Oneiric Eucalyptus fails to start up (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/791607
<doko> slangasek, my test build is better, only fails on amd64 ;-P
<slangasek> SpamapS: unseeded universe packages are fine for bugfix uploads during beta freeze
<slangasek> doko: did you change something, or is it just magic? :)
<doko> slangasek, turned parallel off
<slangasek> ok
<doko> will try another machine later (the last amd64 one was on allspice)
<SpamapS> slangasek: thanks. :)
<skaet> doko, thanks for flagging.   Working with launchpad team to figure out what went wrong.   Archive is marked as frozen.
<micahg> skaet: now it is, wasn't in LP package interface when doko uploaded (checked firefox right afterwards)
<skaet> thanks micahg!
<micahg> skaet: you still might want to chat with them about the delay though
<skaet> doko, when did you do the upload of php5?
<doko> skaet, don't know, best thing would be now - the current build time on i386
 * doko fetches a beer, all php5 builds running ...
<skaet> micahg,  indeed, am trying to figure out what happened.   Was told it was frozen at 2144 UTC
<micahg> skaet: timestamp on the e-mail is 22:30
<skaet> UK time
<skaet> ?
<micahg> UTC, sorry
<doko> the build was start 49min ago
<skaet> micahg, can you bounce me the email?
<skaet> doko,  thanks,  will be digging into it with the LOSA involved tomorrow to see if we can figure out where the glitch came from.
<Daviey> SpamapS: Hang on, is your fix to depend on sun-java6-jre?
<micahg> skaet: https://lists.ubuntu.com/archives/oneiric-changes/2011-August/007865.html
<micahg> Daviey: I just commented on that in -devel :)
<SpamapS> Daviey: no, I was mistaken, I had no fix
<skaet> micahg, thanks.
<SpamapS> Daviey: there's also a bug where eucalyptus-common needs to depend on iptables.. but that wasn't the same bug
<Daviey> SpamapS: I do not believe that moving a package to multiverse, because it depends on a package in multiverse is a valid reason.. Also, i don't think multiverse is allowed to depend on partner.
<Daviey> err, depends on a package in partner is valid - rather
<SpamapS> Daviey: Yeah I'm just wondering what we should do if they can't fix it upstream.
<micahg> Daviey: well, if it's a depends, it would need to be in multiverse for closure (someone can have universe but not multiverse installed and this package would be uninstallable)
<micahg> s/installed/enabled/
<Daviey> micahg: you think multiverse can depend on partner?
<micahg> Daviey: no, where did I say that :)
<Daviey> micahg: so what are you suggesting? :)
<micahg> Daviey: if it's a recommends, it would be ok, if it's a depends, then not (that assumes that it'll run in some way without the package)
<Daviey> micahg: Well a java app will probably need to depend on a java jre :)
<SpamapS> micahg: it will not run w/ openjdk
<SpamapS> I suspect there's a simple patch that would fix this.
<SpamapS> but we're not exactly leaping out of our chairs to patch euca when there's so much going on around openstack.
<Daviey> SpamapS: There was some consideration for euca to move to partner this cycle, but it was favoured not to do so.
<Daviey> I have had some communication this week with euca about resolving these issues.
<micahg> yeah, so that would be a no way for it to work situation :) aside from it moving to partner if feasible (and I see Daviey beat me to it)
<SpamapS> Daviey: ahh, well that would at least work.
<Daviey> I think they are gettng more involved, so i wouldn't spend tooo much time on it.
<SpamapS> Daviey: I just saw it in the beta1 list and figured I'd make sure it was reproducible.
<SpamapS> Daviey: whats blocking carrot/kombu's MIR btw?
<Daviey> SpamapS: That is unblocked as of a few hours ago.
<SpamapS> ahh sweet
 * SpamapS is trying to find things to help w/ :-P
<Daviey> SpamapS: if you want to push on those MIR's (they are not detailed enough), i'd highly appreciate it.
<SpamapS> yeah kombu also pulls in python-anyjson
<Daviey> I added quick notes stating why we now need both and not or.
<doko> slangasek, rebuild did work on i386, the amd64 build did fail again
<slangasek> doko: phooey
#ubuntu-release 2011-08-26
<doko> slangasek, so let the powerpc build get into the archive before you re-upload ;)
<doko> please approve gamin, fixing ftbfs
<doko> cjwatson, no queuebot?
<slangasek> bah, why is gamin still in main? it shouldn't be used on linux anymore, do we have a bug in component-mismatches telling us we want it in main?
<slangasek> hmm, no, libgnomevfs really still links against it
<micahg> slangasek: glib2.0 seems to build-dep on it
<slangasek> "seems" to is right, because it's only on !linux-any :)
<slangasek> but the libgnomevfs dep is real, unfortunately
<micahg> ah, this script breaks out binary deps, but not build deps
<slangasek> doko: accepted gamin
<doko> hrm, why does the md5sum for the sqlite .orig doesn't match, if we only have a -buildX version?
<doko> please approve sqlite, fixing ftbfs (still in main :-/)
<slangasek> doko: done (and hopefully leaving main soon :)
<doko> slangasek, if you're still awake in 1h, please give back unity on arm
<doko> good night
<slangasek> I assume I'll be awake, might even be at a computer :)
<slangasek> g'night
<infinity> doko: I was already going to do it.
<infinity> slangasek: ^
<slangasek> infinity: it's yours then :)
<infinity> Oh, FFS.  You sync one silly package to get it building and realise it now has 4 more build-deps from sid that we don't have.
<ScottK> Test building FTW.
<ScottK> Jusy sayin'.
<infinity> The irony there is palpable, thanks.
<infinity> I can't count the number of times I've typed that over the years. :P
<infinity> ScottK: FFe to add a bunch of ocaml multimedia bindings to universe, kthx? :)
<ScottK> Sigh.  What bug?
<infinity> None yet.  I can file one later.
<infinity> I was planning to skip process, like the cowboy I am.  But fiiiine.
<ScottK> Wife calling.  I'll be back to help with the paperwork later.
<infinity> (I'm tempted to sort out who did the liquidsoap sync a month ago and didn't follow up to see that it built...  It's been missing build-deps ever since)
<micahg> infinity: looks like autosync happiness, but was 3 weeks before the mass autosync happened
<infinity> Weird that said mass sync didn't pick up the new packages it needed to build. :/
<infinity> Oh well.
<infinity> Easy enough to fix.
<infinity> Just irksome.
<micahg> infinity: it could've been an early test :-/
<mdeslaur> There is a new flash package in partner. I'm going to need to upload a new flashplugin-nonfree to oneiric, or it won't be able to upgrade.
<infinity> mdeslaur: Go for it.
<mdeslaur> infinity: thanks
<infinity> mdeslaur: Accepted.
<pitti> Good morning
<doko> please accept libvisual-plugins and libnl3
<pitti> doko: done
 * pitti starts building the beta-1 langpack
<pitti> s
<pitti> export finally done
<pitti> review of at-spi2-core would be appreciated
<slangasek> pitti: libdbi-drivers accepted
<pitti> ah, thanks
<pitti> slangasek: now it's down to php5/amd64
<slangasek> too late for me to look at at-spi2-core, though, someone else will need to grab it
<pitti> always one more thing which holds back cruft..
<pitti> slangasek: ok, thanks; will wait for cjwatson or Daviey; it's a trivial fix
<pitti> slangasek: good night, sleep well!
<cjwatson> doko: well, if you lot will freeze when I'm not watching IRC ...
<pitti> good morning cjwatson
<cjwatson> morning
 * doko welcomes queuebot
 * cjwatson fixes the crontab so that queuebot will do something useful
<doko>  ... and cjwatson
<pitti> new langpacks seem fine, uploading now
<pitti> cjwatson: ^ perhaps you might want to hold back queuebot for this?
<cjwatson> meh
<cjwatson> ok, I'll go kill queuebot for a bit
<jibel> no daily server and alternate images to test this morning.
<pitti> cjwatson: do you have a moment to review the at-spi2-core upload? it'll unbreak natty upgrades
<pitti> (just dropping a conflicts:/replaces:)
<cjwatson> jibel: have you checked logs to see what went wrong?
<cjwatson> pitti: ok
<jibel> cjwatson, yes, if I read it right, python3.2 is missing but required
<jibel> Missing debootstrap-required python3.2
<jibel> Missing debootstrap-required python3.2-minimal
<jibel> CD1 missing some packages needed by debootstrap
<cjwatson> fixed in the archive
<jibel> this is for alternate and for server there is a strange bzr error
<cjwatson> those are usually transient
<jibel> * Fetching branch of http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.oneiric/
<jibel> bzr: ERROR: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.oneiric/.bzr/repository/indices/18fdf185c43208cd2746e3824711d83a.tix is redirected to https://launchpad.net
<cjwatson> transient
<cjwatson> network glitch
<cjwatson> will retry both after my archive fix publishes
<jibel> ok thanks.
<cjwatson> pitti: fine, accepted
<pitti> thanks
<pitti> jibel: ^ do you plan to run another natty->oneiric upgrade test soon? or the auto upgrade tester?
<pitti> jibel: I hope that this will fix the upgrade (bug 828759)
<ubot4> Launchpad bug 828759 in at-spi2-core (Ubuntu Oneiric) (and 1 other project) "package ubuntu-desktop 1.240 failed to install/upgrade: ErrorMessage: dependency problems - leaving unconfigured (affects: 27) (dups: 28) (heat: 246)" [Critical,Fix released] https://launchpad.net/bugs/828759
<jibel> pitti, I can verify the fix this afternoon.
<pitti> jibel: great; it'll need another 2 or 3 hours to build/publish anyway
<doko> ScottK, korundum still ftbfs in the test archive (multiarch issue)
<pitti> cjwatson: all langpacks uploaded and accepted; I bumped build score for the ones that we ship on CDs; so buildbot can resume its duty
<cjwatson> ok
<pitti> https://launchpad.net/ubuntu/oneiric/+queue?queue_state=0 -> this looks new
<pitti> is this "button press sync from launchpad UI"?
<cjwatson> yes
<cjwatson> well, from the API
<cjwatson> don't use the UI
<cjwatson> I mean don't use the +localpackagediffs UI, it doesn't meet our needs, but I've improved syncpackage to handle it
<cjwatson> we'll announce it once a few more bugs have been shaken out
<pitti> I just wondered what to do with it
<pitti> I figure one of the two is redundant
<cjwatson> two people ran syncpackage independently so reject one
<Laney> looks like the same person actually
<Laney> perhaps he was confused by the lack of mail
<Laney> also, LP folks fixed some bugs so the UI isn't that bad now
<cjwatson> still, it'd be better for Ubuntu people to consistently use the API IMO
<cjwatson> same person> yes, you're right, I misread #ubuntu-motu scrollback
<Laney> ah, discussed there indeed
 * cjwatson belatedly clears the sync queue
<Laney> going to sync tangerine and rebuild longomatch to finish that little stack
<Laney> what do people think of syncs for NEW universe leaf packages? up until when should we be accepting those?
<tumbleweed> ah, sorry for that pitti
<pitti> tumbleweed: for what?
<tumbleweed> double sync of that package
<pitti> tumbleweed: oh, no worries
<pitti> tumbleweed: I'm just not sure whether I'm supposed to accept the aweather sync from the queue page
<cjwatson> it's fine to do so if you think the changes are acceptable
<cjwatson> if queuediff can't show you the changes, then you could look at https://launchpad.net/debian/+source/<package>/+changelog or whatever
<pitti> it's a totally new package, so it should be fine
<pitti> accepted
<pitti> shiny!
<ScottK> doko: Thanks.  That's a bit odd as it built locally.
<pitti> oh please, unity armel build, condescend to finish
 * pitti feeds the hamsters
<pitti> C++ and arm really aren't friends
<pitti> cjwatson: "Removed software-center from desktop" (ubuntustudio-meta) -> I guess that's intended, but do you know what they use instead?
<cjwatson> they still have synaptic
<cjwatson> revno: 1275
<cjwatson> committer: Janne Jokitalo (astraljava) <astraljava@kapsi.fi>
<cjwatson> branch nick: ubuntustudio.oneiric
<cjwatson> timestamp: Fri 2011-08-26 00:56:49 +0300
<cjwatson> message:
<cjwatson>   Get rid of software-center, it causes unity to be included
<pitti> ah
<cjwatson> surprised it pulls in unity really, but ...
<pitti> LibO FTBFS fix on the way
<astraljava> cjwatson: Yeah, that's how I interpreted the germinate logs anyway.
<cjwatson> hmm, regarding the software-center gtk2/3 discussion from yesterday, I notice that software-center's gtk2 bindings depend on the NBS python-gmenu
<cjwatson> is that due to be resurrected for oneiric or is it permanently dead?
<ScottK> The kubuntu daily ISO report has had this to say about the DVD for awhile, but it seems to build the livefs OK.  Is this something that needs fixing:
<ScottK> kubuntu/dvd: Uninstallable packages:
<ScottK> gcj-4.5 4.5.3-6ubuntu1 produces uninstallable binaries:
<ScottK>   * gcj-4.5-jdk (amd64 i386)
<ScottK>   * libgcj11-dev (amd64 i386)
<cjwatson> they might be on the non-livefs portion
<cjwatson> in fact they must be if the report says that
<ScottK> OK.  That seems to be from the platform seed.
<cjwatson>  * gcj-4.5-jdk          # keep these here, will be in main in natty
<cjwatson>  * libgcj11-dbg
<cjwatson> doko: ^- do you know what's happening here?
<doko> cjwatson, wasn't this the component mismatch?
<cjwatson> I thought I did a binary promotion there the other day
<cjwatson> it's not on c-m now anyway
<ScottK> Looks like we've got both gcj-4.5 and 4.6 and 4.5 is only because it's directly seeded in the development seed.  Should that be changed to 4.6?
<doko> hmm, I think I use it for armel, or used it
<doko> keep it there for now please. it's a fallback for the armhf bootstrap
<doko> ScottK, are the k3b and kalzium ftbfs reproducible?
<pitti> cjwatson: gnome-menus2 is back in, so the libgnome-menu/python-gmenu NBS should be solved now
<pitti> yep, disappeared from nbs.html
<cjwatson> ah, ok
<cjwatson> doko: see the k3b bug
<ScottK> doko: Yes.
<cjwatson> ScottK: should I just go ahead and upload k3b?
<ScottK> cjwatson: It won't make it worse.
<ScottK> I'd say so.
<cjwatson> that was my thought ...
<cjwatson> can I disregard the Vcs-Bzr field?  the branch referenced there doesn't exist
<ScottK> I don't one negative report, but I'm not sure if it was an "I failed to achieve test conditions" report or "test failed" report.
<ScottK> Let me give you the correct location.
<pitti> cjwatson: I'd like to build new ubuntu desktops, mainly to ensure that they are within size limits now, and before we accept LibO; ok for you, or do you wait for something else?
<cjwatson> oh, can we build alt/server first, I promised jibel I'd do that
<ScottK> cjwatson: It should be at ~kubuntu-packagers/kubuntu-packaging/k3b (and if you wouldn't mind correcting the Vcs-* headers that would be lovely - we just didn't do uploads only for the Vcs-* changes).
<ScottK> If not, we'll deal with it later.
<pitti> cjwatson: they parallelize pretty well, don't they? buildlive is mainly just ssh waiting
<cjwatson> ah, crimsun did it
<pitti> cjwatson: want me to start them all now?
<cjwatson> pitti: true.  please do
<pitti> running
<pitti> with any luck, even powerpc will fit
<pitti> I'd like to accept LibO, is that a bad time for some reason?
<cjwatson> this partman-crypto upload doesn't fix the RC bug, but it fixes an (AFAIK) unreported one whereby encrypted LVM installs totally fail to work in any way shape or form
<pitti> (it will render some uninstallability until -l10n and all arches have built)
<pitti> cjwatson: ah, will review
<cjwatson> (discovered while working on said RC bug)
<pitti> cjwatson, jibel: http://cdimage.ubuntu.com/daily/20110826.1/
<pitti> look, 681 MB powerpc
<cjwatson> whee!
<pitti> we could even add another langpack, but let's adjust that for the final; they aren't so important on the alternates anyway
<jibel> pitti, thanks, smoke tests triggered.
<cjwatson> jibel: if you have encrypted-LVM smoke tests, you can skip them, they'll fail
<pitti> FTR, unity armel fix will land in about 2 or 3 hours, then unity-2d can build, and unscrew armel installability
<cjwatson> dear k3b test-build, kindly finish ever
<jibel> cjwatson, it is not automated yet. I need to find a way to enter the passphrase on boot automatically.
<doko> please accept openbabel
<ScottK> Is LP making diffs correctly?  LO (uploaded an hour ago) still doesn't have one.
<doko> better do it manually for LO
<ScottK> The later uploads don't have one either.
<ScottK> openbable is 16 minutes old, so I'd have expected that to be long enough.
<pitti> jibel: http://cdimage.ubuntu.com/ubuntu-server/daily/20110826.1/
<pitti> http://cdimage.ubuntu.com/daily-live/20110826.1/
<pitti> \o/
<pitti> you can't imagine how wide my grin is now
<pitti> cjwatson: do you need another CD build soon, or can I accept LibO?
<pitti> I'd like it to build over the weekend on arm
<jibel> encrypted home still fail on alternate. why alternate has kernel 3.0.0-9.12 and not 3.0.0-9.14
<cjwatson> pitti: go ahead
<doko> pitti: please accept k3b and openbabel too (build failures)
<pitti> yep, will look
<doko> pitti: lo will ftbfs on armel, gcj-4.6 is not yet built
<stgraber> skaet: as Robert probably won't be around till his Monday (so late Sunday US time) I'll prepare the fix myself. I'm expecting the unity-greeter change to just be a 5-6 lines patch to the vala code.
<skaet> stgraber,  sounds good.
<mdeslaur> Can I upload a simple fix for empathy for bug 828802 and bug 832378?
<ubot4> Launchpad bug 828802 in empathy (Ubuntu) (and 1 other project) "empathy crashed with SIGSEGV in __memcpy_ssse3() (affects: 4) (dups: 1) (heat: 30)" [Medium,Fix committed] https://launchpad.net/bugs/828802
<ubot4> Launchpad bug 832378 in empathy (Ubuntu) (and 1 other project) "empathy crashed with SIGSEGV in g_memdup() (affects: 3) (dups: 2) (heat: 279)" [Medium,Fix committed] https://launchpad.net/bugs/832378
<stgraber> skaet: ok, I attached a patch to bug 834701 which works fine here. As unity-greeter is really not a foundation thing, I think it'd be great if someone from desktop could have a look and if they are happy with the fix, upload it.
<ubot4> Launchpad bug 834701 in unity-greeter (Ubuntu) "greeter regression, no longer allowing flavours to customize the greeter (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/834701
<stgraber> seb128: I just saw your name in the changelog of unity-greeter ;) can you have a look at that bug and the attached patch?
<skaet> stgraber, sounds good.  :)   thanks.
<mdeslaur> ScottK, skaet: can I upload a small crasher fix for empathy?
<ScottK> mdeslaur: Yes.  Worst case it gets held until after beta1, but it'll probably go in now.
<mdeslaur> ScottK: thanks
<stgraber> ScottK, skaet: There you go for the UIFe for edubuntu-artwork: bug 834787
<ubot4> Launchpad bug 834787 in edubuntu-artwork (Ubuntu) "[UIFe] Replacing unity circle-of-friends logo by the Edubuntu logo (distributor-logo.svg) (affects: 1) (heat: 8)" [High,Triaged] https://launchpad.net/bugs/834787
<charlie-tca> I see Ubuntu alternate images were re-spun today. Any chance of doing that for all of us?
<charlie-tca> No alternate images built today
<ScottK> stgraber: Can you get someone from whoever does Edubuntu docs to ack the UIFe?
<stgraber> ScottK: ack
<cjwatson> charlie-tca: I've at least kicked off Xubuntu
<charlie-tca> Thanks
<stgraber> ScottK: (Currently Edubuntu documentation is basically just our website and I'm the one updating these screenshots)
<ScottK> stgraber: Then you get to be the one that ack for Edubuntu docs.
<ScottK> stgraber: UIFe approved.
<stgraber> ScottK: thanks
<seb128> stgraber, I've pinged mterry about it, he knows the code better
<stgraber> seb128: ok, thanks
<pitti> good bye everyone, have a nice weekend!
<pitti> skaet: can you watch the unapproved queue for a bit for urgent updates?
<skaet> pitti,  will do.
<ScottK> gcj-4.5 is gone from Kubuntu after my last seed change, so win.
<ScottK> And it's in component mismatches for demotion now ...
<cjwatson> ScottK: demoted
<ScottK> Progress.
<cjwatson> along with gcc-4.5-source
<ScottK> Very nice.
<cjwatson> gilir: Lubuntu alternate images set up: http://cdimage.ubuntu.com/lubuntu/daily/current/
<ScottK> cjwatson: If it wouldn't interfere with anything else, it'd be nice to have a respin of Kubuntu alternates for i386 and amd64.  I adjusted language packs today and I'd like to make sure I didn't over do it.
<gilir> cjwatson, great ! thanks :)
<cjwatson> ScottK: running (just for all architectures, it's easier)
<jibel> gilir, Lubuntu alternate added to the tracker with a default set of test cases: default install, auto resize and encrypted lvm. Let me know if you want more (or less)
<gilir> jibel, let's keep it like this for the beginning :) thanks :)
<ScottK> cjwatson: Thanks.
<ScottK> cjwatson: I had to make a few adjustments, so if you could do that again, I think we'll be good.
<stgraber> I just sponsored a new apport from bdmurray implementing a duplicate signature for ubiquity. It'd be good to have that for beta1.
<infinity> stgraber: I was following the conversation in #-devel.  Will approve it once it lands in the queue.
<stgraber> infinity: thanks
<bdmurray> infinity, stgraber: thank you both
<doko> fyi, if you see some private builds on the buildds: I'm staging gnat-4.4, gcj-4.4, gcc-4.4, gdc-4.4 builds in a non-virtualized ppa over the weekend, so that these can be copied over consistently to oneiric once all of them are built
<Daviey> If the package tboot (source NEW) is able to be reviewed by an AA, can a release team member ack bug 815752 please?
<ubot4> Launchpad bug 815752 in Ubuntu Oneiric (and 1 other project) "[FFe] [needs-packaging] tboot (affects: 1) (dups: 1) (heat: 18)" [Wishlist,In progress] https://launchpad.net/bugs/815752
<Daviey> (no plan to be seed/MIR)
<stgraber> I'd appreciate it if someone could review that unity greeter. It's pretty much the same patch I had attached before (but a bit cleaner). I'm going to make an edubuntu-artwork upload once this one is in.
<apw> slangasek, about ?  cjwatson asked me to upload linux-backport-modules-3.0.0 for oneiric to get the ABIs in sync.  unfortuantly the upload was rejected due to that package not yet being in the kernel package set.  i wonder if you might have time to sponsor it for me.  its on chinstrap in ~apw/sign
<slangasek> apw: ok, taking a look
<slangasek> OOI, why do you use chinstrap for this, rather than something with a public web interface?
<apw> slangasek, it happens to be there for uploading is all
<stgraber> apw: can you check if you're missing other packages in the kernel packageset? I'm happy to update the list to match the current kernel version.
<slangasek> apw: ah
<apw> stgraber, thanks, checking
<stgraber> apw: oh, actually this package set is owned by the techboard for some reason... but still if you can get a list I can poke the TB to get the packageset updated
<stgraber> apw: current content: http://paste.ubuntu.com/675424/
<apw> stgraber, i think the only one missing at the moment is the lbm package for oneiric
<apw> its one of those chicken-eggs that until it was uploaded just recently it wasn't there to add
<slangasek> apw: uploaded, in the meantime
<apw> slangasek, thanks a lot, i can go get some bevvies now :)
<slangasek> enjoy :)
<jdstrand> ScottK: would it be alright if I performed a sync for for mantis to fix bug #828857? no ubuntu delta
<ubot4> Launchpad bug 828857 in gentoo (and 3 other projects) "MantisBT <1.2.7 search.php multiple XSS vulnerabilities (affects: 1) (heat: 258)" [Low,New] https://launchpad.net/bugs/828857
<jdstrand> ScottK: and hello :)
<ScottK> jdstrand: Yes.
<ScottK> I guess we aren't waiting on the l10n.
 * skaet has to go to appt., will be afk,  back online later.
<slangasek> Daviey: 815752 acked - btw, it's hard to pick process bugs like FFe's out of the list for processing when they're marked 'in progress'; https://wiki.ubuntu.com/FreezeExceptionProcess says FFe requests should be set to state 'new'
<slangasek> doko: why is bug #796769 marked 'high'?  nothing in Debian depends on this, at least, and the source is in universe
<ubot4> Launchpad bug 796769 in gradle (Ubuntu Oneiric) (and 1 other project) "gradle needs a manual build using the unstable binaries (affects: 2) (heat: 9)" [High,Confirmed] https://launchpad.net/bugs/796769
<cjwatson> lamont has already said that bug reports are the worst way to get him to do such things
<cjwatson> and has recommended using RT instead, because otherwise he doesn't get to do them on work time
<slangasek> that too
<Daviey> slangasek: Yup.. thanks
<stgraber> skaet: sorry to add even more UI freeze exception for Edubuntu, I just remembered I missed one change in my last batch of upload. bug 835027
<ubot4> Launchpad bug 835027 in edubuntu-live (Ubuntu) "[UIFe] Add a launcher to the default unity configuration for LTSP-Live (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/835027
<slangasek> ia32-libs, wine1.3 in the queue fix wine uninstallability (from lib32v4l-0 removal)
<slangasek> (wine1.2 coming soon)
<ScottK> slangasek: wine* and ia-32libs accepted.
<stgraber> Attached the debdiff to bug 835027, would be great if someone could review the UI freeze exception. Thanks!
<ubot4> Launchpad bug 835027 in edubuntu-live (Ubuntu) "[UIFe] Add a launcher to the default unity configuration for LTSP-Live (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/835027
<slangasek> ScottK: ta
<stgraber> ScottK: if you have a sec and can review bug 835027 that'd be awesome. I'd like to get rid of all my Edubuntu stuff this weekend so I can focus on Ubuntu next week.
<ubot4> Launchpad bug 835027 in edubuntu-live (Ubuntu) "[UIFe] Add a launcher to the default unity configuration for LTSP-Live (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/835027
<ScottK> stgraber: Done.
<stgraber> ScottK: thanks!
<ScottK> You're welcome.
<ScottL> would someone explain what it means when i see that the queubot says that a package is removed?
<ScottL> it says that rubberband was removed and since ubuntu studio depends on this package i'm a little worried, ya know?
<ScottL> if you do you will be in my top five carbon based, bipedal life forms
<cjwatson> it means that the upload was removed from the queue, either by accepting or rejecting the upload (queuebot doesn't know)
<cjwatson> it never means that the package was removed from the archive, so don't panic
<ScottL> no fair cjwatson, i already considered you in my top five carbon based, bipedal life forms ;)
<cjwatson> heh
<ScottL> i'm glad to hear that, i had already checked launchpad and saw that rubberband had been released 1.5 hours ago and thought as much
<ScottL> skaet, i have a question for you as well, would it be possible ubuntu studio to move to a one year release cycle?  how much trouble would this be for others?
<ScottL> ideally we would want to complete the next LTS before moving to said one-year schedule
<infinity> Having flavours out of sync with Ubuntu proper could prove mildly unpleasant for you.
<infinity> But I guess since your release would be lining up with every second of ours, our freeze won't annoy you THAT much.  Maybe.
<infinity> (Still a bit weird)
<ScottL> strange word that "flavours", i forget if it's officially "flavours" or "derivaties" or "respins"  i have seen "derivatives" on the official ubuntu site
<cjwatson> persia can probably give you an essay on the subject :-)
<infinity> I'm not sure what the marketing spin on it is.
<ScottL> infinity, i don't think the freezes would affect us too much
<infinity> I consider flavours to be "anything built from the primary archive".
<infinity> But naming is meaningless to me. :P
<ScottL> cjwatson, he has before and i know that he _strongly_ prefers "flavours" and not "derivatives"
<infinity> ScottL: I don't see any particular reason why it wouldn't work.  Instead of requesting to release every 12 months, just inform us that you intend to NOT officially realease every second time. :)
<ScottL> infinity, that is quite acceptable :-)
<cjwatson> anyone fancy testing a transcode patch for me, porting to the new libav?
 * cjwatson looks idly at the Ubuntu Studio developer :-)
<infinity> ScottL: And do make sure that you take care to have your packages upgrade cleanly while skipping Ubuntu releases (though, I wish everyone did that anyway)
<cjwatson> oh, bah, transcode is part of mythbuntu not ubuntustudio.  It was a nice try
<ScottL> cjwatson, i'm really less of a developer than a cat herder being the project lead ;)
<ScottL> although i do _some_ minor development though
<ScottL> infinity, you mean make sure the upgrade path is clean, correct?
<ScottL> not trying to split hairs, just making sure i understand your intent
<infinity> ScottL: However you prefer to describe it.  But yes.
<ScottK> ScottL: He prefers to avoid the term derivatives because they aren't derivatives (I do as well).  I sometimes use the term siblings.
<infinity> ScottL: In general, since we should be trying to make sure that upgrades are smooth from LTS to LTS (and not prematurely dropping maintainer script upgrade glue, etc), there shouldn't be an issue.  But some people play fast and loose with the idea that "I can drop upgrade code as soon as a new release is out, wheeee!"
<infinity> ScottL: So, just watch out for the wheee factor. :)
<ScottL> lol
<ScottL> yes, i would prefer to avoid the "weee" factor
<ScottK> ScottL: Upgrade path would be a problem for you since Ubuntu as a project only supports either LTS to LTS upgrades or sequential through every release.  For Kubuntu we did support this ourselves between Hardy and Lucid due to early versions of KDE4 being a bit rough, so it's at least theoretically doable.
<infinity> ScottK: To be fair, what Ubuntu officially supports, and what actually works are pretty different.  It doesn't take a lot more effort to watch out for the aforementioned wheeeee and fix some of the more glaring oopses along the way.
<cjwatson> I would say the main problem would be things bitrotting in the off-release.
<ScottK> infinity: Agreed.  When we did it for Kubuntu it mostly just took some extra testing.
<ScottL> to explain the reasoning behind the request:  our team is small (and getting smaller) and our users really don't require a new, shiny desktop every six months and would prefer not to have one
<ScottK> OTOH, supporting Dapper -> Fiesty upgrades would have been about impossible.
<ScottL> of course we need to divert some resources to back ports then
<ScottK> The trick, of course, is you won't really know if skipping a release is a supportable upgrade path until after you've already skipped the release.
<slangasek> bug #835132> argh
<ubot4> Launchpad bug 835132 in ia32-libs (Ubuntu) "package ia32-libs 20090808ubuntu17 failed to install/upgrade: trying to overwrite '/usr/lib32/libv4l2.so.0', which is also in package lib32v4l-0 0.8.3-2 (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/835132
<ScottL> ScottK, heh, unfortunately true
<ScottK> slangasek: I'll trade you fixing that one for you fix the (unrelated) linking problem in gnuradio so it can build against libqwt-dev.
<infinity> slangasek: Missed a conflict/replace?
<slangasek> infinity: just a Replaces, yeah
<ScottK> Which is why I volunteered to trade.
<slangasek> ScottK: it's just a replaces, but it's on ia32-libs; I don't think that's fair to do to you :)
<slangasek> also, I've already fixed it and am uploading
<slangasek> should reach the queue any hour now
<slangasek> I'm still happy to look at gnuradio, though - bug # / link?
<ScottK> I picked it off the NBS page.  Let me see if there's a bug.
<ScottK> slangasek: 770925
<slangasek> oh fun, an old one no less
<ScottK> Yep.  I just added my comments to it.
<ScottK> It seems like it had no trouble with qwt5 -> qwt6, but getting modern linking right it a different issue.
<slangasek> huh; strange that there was an NMU of gnuradio in June that fixed bunches of issues, but not this one
#ubuntu-release 2011-08-27
<skaet> ScottL,  after reading the backscroll, others have pointed out the issues re: bitrot, etc..  :)   From a logistics point of view, it should be straight forward enough though.
 * ScottK wonders if the queuebot fell asleep.
<slangasek> ScottK: iterating gnuradio is proving wonderfully tedious :P
<ScottK> Glad you're enjoying it ...
<ScottK> ;-)
<slangasek> I blame C++ for much of this
<slangasek> I think the headers are leaking constructor details, leading to library linkages that the consumer test cases really don't care about
<ScottK> Was trying to look at nlkt for qwt6 transition and typed nltk by mistake.  Turns out that needs pysupport -> dh_python2.
<ScottL> skaet, infinity, cjwatson ScottK : re: ubuntu studio one-year release cycle, we still have to get through 11.10 and 12.04 before we would be ready for such a thing but we now know that it is a possibility, thank you for you input
<ScottK> ScottL: You might first consider trying to lightly QA alternate releases and support direct upgrades and see how it goes.  You could even try supporting 11.04 to 12.04 as an experiment.
<ScottL> ScottK, thank you for that excellent suggestion :)
<slangasek> ScottK: so after all the makefile patching, gnuradio FTBFS because swig generates C++ code without the required includes for ptrdiff_t
<slangasek> ah, but swig2.0 does the job
<Daviey> Might be of use: http://people.ubuntu.com/~davewalker/component-mismatches-mir-track.html
<doko_> Daviey, the general suggestion is not quiet correct, a lot of component mismatches are handled by fixing some package to stay in universe
<ScottK> Daviey: As an example of doko_'s point, the solution to the kdesvn one is to fix the kdesdk FTBFS on powerpc.
<ScottK> cjwatson: Debian has introduced a qwt5 package: http://packages.qa.debian.org/q/qwt5.html instead of all the qwt6 related removals (and there will be more) we could just sync that instead.
<slangasek> ScottK: well, gnuradio isn't source-compatible with qwt6 either FWIW :)
<slangasek> finally got through the linker / swig errors, now it fails because QwtDoublePoint no longer exists
<ScottK> slangasek: So approve the qwt5 FFe and sync it.
<ScottK> Then it's all full of win.
<slangasek> ok, will look at that shortly
<ScottK> Bug 835553
<ubot4> Launchpad bug 835553 in ubuntu "FFe: Sync qwt5 5.2.2-1 (universe) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New] https://launchpad.net/bugs/835553
<ScottK> So far ~3/4 of the packages I've looked at needed porting and most of those were non-trivial.
<charlie-tca> Why don't todays images have the latest changes/
<ScottK> What changes?
<charlie-tca> Ubiquity 2.7.17 is still on Xubuntu Desktop for today, and it needs to be 2.7.18 to allow installing 3rd party software duing the installs
<charlie-tca> Trying to resolve bug 653571, which shows fixed-released
<ubot4> Launchpad bug 653571 in ubiquity (Ubuntu Oneiric) (and 1 other project) "ubiquity crashed with DBusException in call_blocking() when the option "Install 3rd party software" is checked. (affects: 113) (dups: 60) (heat: 550)" [High,Fix released] https://launchpad.net/bugs/653571
<ScottK> charlie-tca: https://launchpad.net/ubuntu/+source/ubiquity/2.7.18 - failed to build.
<charlie-tca> Thanks
<Daviey> doko_: Yeah, i get that.. i mainly did that page for my needs, and thought it was useful to share.  I was careful to put "consider" raising a MIR.
<Daviey> but hey, if it's not useful for you aswell.. then don't use it :)
<Daviey> string updated to make it clearer. :/
<slangasek> interesting, Oracle reportedly isn't going to be distributing sun-java6 under the DLJ anymore; I wonder if we'll still have it in partner
<slangasek> that would make a eucalyptus dependency on sun-java6 even more problematic, if the packages no longer exist at all...
<ScottK> Nice.
<Daviey> slangasek: The fact that euca currently only seems to work with sun-java6 is a bug.  Debian will care about this aswell.
<ScottK> Daviey: I do think it's a good accompaniment to the c-m page.  Perhaps the MIR linking bits could be added to c-m.
<slangasek> Daviey: certainly
<slangasek> but "care about" != "get a fix for in a timely manner" :)
<Daviey> ScottK: That was my hope, but i wasn't able to get the c-m.txt generation source when I needed it.  So decided to JFDI.  Tracking the MIR's i need to chase has been a apin.
<Daviey> pain*
<slangasek> oh cute, something has caused gnuradio to install everything to /usr/lib64 instead of /usr/lib
<slangasek> I swear, this software
<Daviey> slangasek: I'm not that hopeful that euca will be resolved in time for Oneiric.  I have been in contact with upstream, and they are /starting/ to get more involved.  However, i'm not expecting it to be stable at release time.
<Daviey> I suspect it's going to be a release note issue.
 * slangasek nods
<Daviey> slangasek: Regarding multiverse depending on partner.. Would that require a manual build, injecting partner into the buildd?
<slangasek> Daviey: oh, it requires it at *build*-time?  Yeah, that's a non-starter
<slangasek> if it were just a runtime dep, we could (*could*) turn a blind eye
<Daviey> Well, i would think jdk would be required for a java build.
<slangasek> yes, but it might be able to build with openjdk and only fail at runtime without sun-java
<Daviey> Lack of clear policy on this kinda blows my mind TBH. :)
<Daviey> slangasek: ack, not tried that TBH.
<slangasek> the questions rarely come up... I think the original AA team all had a shared consensus in their heads that hasn't really been propagated anywhere on paper :)  (Or it's on paper, but only on some web page on www.ubuntu.com whose URL I can never remember, not in any AA/developer documentation)
<slangasek> cjwatson probably knows the page I'm thinking of, as he's the one who's pointed me to it in the past
<Daviey> On a related note, someone was asking about me about ABI stability throughout the supported cycle.  The best response i could give is that ABI compatability is not promised and it's "best judgement of do least harm" by the SRU and security team.
<ScottK> Daviey: post-release we (mostly) promise regression free.  So I think an ABI break would be "bad".
<Daviey> ScottK: I didn't think we ever promised ABI stability, let alone do significant checks for it? I thought the kernel was the only thing checked, and that was not necessarily a blocker (hence our love for DKMS).
<ScottK> Kernel ABI breaks are part of the (mostly).
<ScottK> They are pretty unavoidable.
<ScottK> I think we do promise no hidden ABI breaks (which is why the package name changes).
<slangasek> yes, the SRU team would certainly raise a flag for an ABI-changing update
<slangasek> I think we've had to do an ABI-changing openssl security update *once*, and it was a rather large affair
<Daviey> slangasek: raise a flag is not quite rejecting based on it, is it?
<Daviey> As in, my theory of "best judgement of do least harm" still stands?
<slangasek> Daviey: there has to be a darn good reason why we should let something in that breaks the ABI
<slangasek> such as needing a fundamental ABI change to fix a security vulnerability
<slangasek> anything short of that would almost certainly be rejected
<slangasek> and if we do change an ABI for a security vuln, that carries with it a committment to update all the packages to use the new ABI - so library name change, plus rebuilds of all affected packages
<Daviey> slangasek: so, the famous - bug 559822 was only a year ago.. Was it ever documented /how/ that slipped through?
<ubot4> Launchpad bug 559822 in wxwidgets2.8 (Ubuntu Lucid) (and 3 other projects) "editra is provided by both the editra package and python-wxtools and conflicts (affects: 17) (dups: 2) (heat: 31)" [Undecided,Fix released] https://launchpad.net/bugs/559822
<slangasek> hmm, wasn't famous to me
<slangasek> oh, haha, gnuradio's lib64 detection regressed because we made /lib64 a real dir
<slangasek> Daviey: what is it in bug #559822 that slipped through?  Is it the pgadmin3 breakage ttx mentioned?
<ubot4> Launchpad bug 559822 in wxwidgets2.8 (Ubuntu Lucid) (and 3 other projects) "editra is provided by both the editra package and python-wxtools and conflicts (affects: 17) (dups: 2) (heat: 31)" [Undecided,Fix released] https://launchpad.net/bugs/559822
<Daviey> slangasek: Yes, believe so.
<Daviey> slangasek: according to the SRU wiki page caused, bug 610975
<ubot4> Launchpad bug 610975 in pgadmin3 (Debian) (and 24 other projects) "relocation error with latest wxwidgets2.8 (affects: 100) (dups: 17) (heat: 334)" [Unknown,Fix released] https://launchpad.net/bugs/610975
<slangasek> what SRU wiki page?
<Daviey> https://wiki.ubuntu.com/StableReleaseUpdates#Why .. last example
<slangasek> ah
<slangasek> I suspect what happened there is that one SRU member was aware that it caused regressions, but this information was buried in the bug log and we have no process for flagging it to the attention of other SRU team members that an SRU has other dependencies that need taking care of before publishing
<ScottK> IIRC that's about right.
<slangasek> in this case it was apparently impossible to rebuild wxwidgets2.8 without an ABI change due to toolchain updates
<slangasek> I don't really see any analysis in the bugs to explain what changed that caused disappearance of a symbol other packages were using, though - that's rather unusual
<Daviey> The 'wave a flag' idea kinda falls flat if there is no channel. :)
<ScottK> Daviey: There is a channel.  #ubuntu-devel.
<slangasek> ah, Debian bug 540060
<ubot4> Debian bug 540060 in libwxgtk2.8-0 "error in pgadmin3" [Serious,Open] http://bugs.debian.org/540060
<Daviey> slangasek: The reason this became an issue, is that people are spending time/resouces validating / gainign certification for parts of our stack that needs to be re-acheieved on ABI changes.
<ScottK> slangasek: Are you going to deal with New for qwt5 too?
<Daviey> It was my belief that we could not give promise or warning of ABI changes.
<ScottK> That's accurate.
<Daviey> wow, my spelling is bad.
<ScottK> What we can do is attempt to maintain ABI and fix it when we mess up.
<slangasek> well honestly, d.filoni should have blocked the SRU until the regression was fully understood once he became aware of it
<slangasek> I don't know if that was discussed in post mortem though
<slangasek> ScottK: yessir
<ScottK> Thanks.
<ScottK> The good news is all the Main qwt stuff is on qwt6, so qwt5 can be in Universe with no problem.
<slangasek> Daviey: what parts of the stack are you worried about ABI changes to?
<slangasek> ScottK: right, I see the old binaries are already in universe, so all good
<slangasek> Daviey: we have a *responsibility* to guard against undeclared ABI changes, and to minimize the ABI changes that happen in -updates/-security; in some cases we'll fall short (as we did in the wxwidgets case), but that's a bug, not an acceptable casualty
<slangasek> bah, and the bug came down to a change in binutils' parsing of linker scripts
<slangasek> that should have been fixed in wxwidgets2.8 by fixing the linker script :P
<Daviey> slangasek: This specific issue that was raised to me was related to virtio drivers, and Windows validation.
<slangasek> instead of forcing rebuilds of everything else :/
<Daviey> They need to be blessed by Microsoft.
<slangasek> Daviey: virtio drivers being kernel drivers, or?
<Daviey> slangasek: No, the part provided to the guest.
<slangasek> oh. why would any ABIs change there?
<slangasek> oop, car done getting serviced, afk :)
<Daviey> slangasek: I agree Ubuntu does have a responsibility, but i know I am guilty of not properly checking for ABI changes when i propose SRU updated.  I don't know that the SRU team check deeper, other than visual inspection.
<Daviey> slangasek: In the case of a qemu SRU / security update?
<Daviey> Anyway!  I hear the pub calling, ta-ta.
<ScottK> Sigh.
<Daviey> (The reason i raised that it was related, is more down to documented policy not really being avaliable)
<slangasek> right, the SRU team doesn't scale to reviewing the changes in that kind of detail - to some degree we have to rely on due diligence from the uploaders and that our SRU verification process works as intended
<slangasek> personally, I would be in favor of a rule that no library can be SRUed unless it uses dpkg-gensymbols and bails at build time on a symbol mismatch
<Daviey> ScottK: Sigh?
<ScottK> I think I accepted kde-l10n-ug into Universe when it needed to go in Main.
<Daviey> slangasek: That sir, is something that would probably make people happy.
<ScottK> It can get sorted later.
<cjwatson> slangasek: is http://www.ubuntu.com/project/about-ubuntu/licensing what you mean?  I'm not sure ...  At some point I borged what I thought were the salient points of that into ubuntu-policy
<Daviey> cjwatson: Oo, that is a good page.
<ScottK> cjwatson: Did you see we sorted qwt NBS without having to do mass removals or tons of qwt6 ports?
<cjwatson> ScottK: I saw, yeah, thanks
<ScottK> I'm glad the story has a happy ending.
<Daviey> cjwatson: BTW, did bug 817264 come by you at some point?
<ubot4> Launchpad bug 817264 in ubuntu-policy (Ubuntu) "Policy should be reviewed and/or merged with latest debian-policy (affects: 1) (heat: 4)" [Undecided,New] https://launchpad.net/bugs/817264
<cjwatson> Daviey: no, but it's been on my guilt-list for a while anyway
<cjwatson> I'll assign it to myself, and in my CFT ...
<ScottK> Oh, but with a new -doc package so we get to deal with binary New again anyway ...
<Daviey> cjwatson: Sorry. :(
<cjwatson> I'm not worried about the maintainer address thing given common practices in Ubuntu; I think we can add an exception there
<ScottK> cjwatson: Actually, since qwt5 hit binary New on i386 only (due to the -doc package), could you review it for binary New so the archive isn't out of sync?
<Daviey> cjwatson: I think most developers reference debian-policy rather than ubuntu-policy anyway. :/
<cjwatson> ScottK: ok, just a sec
<ScottK> cjwatson: Thanks.
<cjwatson> Daviey: yeah :-/  although I do see the odd IRC highlight for ubuntu-policy, given that it still has my username in the URL ...
<cjwatson> ScottK: accepted
<ScottK> cjwatson: Great. Thanks.
<slangasek> Daviey: it's something that would make people happy in the long run... in the short term, too few libraries are actually set up that way today
<slangasek> cjwatson: yeah, that might be the page... and I see it gives no guidance on multiverse except in the negative :)
<doko_> please could somebody accept java-common?
<ScottK> doko_: Done.
<doko_> thanks!
<slangasek> doko_: what changes does java-access-bridge need in order to drop the build-dependency on at-spi (bug #790240)?  Or is java-access-bridge not ported to at-spi2, in which case I think we should drop it out of main?
<ubot4> Launchpad bug 790240 in libgail-gnome (Ubuntu Oneiric) (and 9 other projects) "at-spi needs demotion for oneiric (at-spi2-core in main) (affects: 7) (heat: 32)" [Medium,Fix released] https://launchpad.net/bugs/790240
<doko_> slangasek, TheMuso did want to address this
<slangasek> as in, he wants to port it to at-spi2?
<doko_> yes
<slangasek> ok
 * slangasek documents this in the bug
<slangasek> oh how I despise cdbs-simplepatchsys
<ScottK> Ohhh.  There it is.
#ubuntu-release 2011-08-28
<cjwatson> native syncs unfortunately don't show up via queuebot (and that seems non-trivial to fix); I've synced hpodder for an FTBFS fix, and hdbc-sqlite3 because that's a build-dependency of hpodder
<cjwatson> they're in unapproved
<stgraber> jibel: around?
<stgraber> (nothing urgent, just wondering as I got a bunch of bug notification e-mail from you)
<jibel> stgraber, pong
<stgraber> jibel: hey!
<stgraber> jibel: I'm currently trying to bugfix most of the nasty ubiquity bugs and I noticed you're apparently going through the bugs at the moment.
<stgraber> jibel: if you are trying to reproduce some of them, you may want to try with ppa:stgraber/experimental turned on
<stgraber> jibel: it's basically the current ubiquity trunk branch
<stgraber> (though I'm guessing you'll probably be gone soon, getting pretty late in Europe :))
<jibel> stgraber, I was just doing some house keeping and cleaning duplicates of bugs ev fixed in 2.7.18.
<doko> please accept openjdk-7, currently builders have nothing to do ...
<jibel> stgraber, I'll test ubiquity once there is an image with 2.7.18 (2.7.19 actually since 2.7.18 fails to build)
<stgraber> jibel: ok :) I'm hoping ev will fix the tests for 2.7.18 tomorrow morning. I couldn't figure out what's broken with them so for now I'm just building 2.7.18 without running the tests...
<stgraber> (only spent around an hour poking at them, then gave up and started looking at bugs in the actual code :))
<infinity> doko: What's the story with those two readline uploads?
<doko> infinity, making libreadline independent of ncurses
<doko> the python interpreter does load ncurses and ncursesw if you import both readline and the curses module
<infinity> doko: This doesn't upset any of readline's other rdeps?
<doko> infinity, think about it, we build with ld --no-add-needed
<doko> ... but people may want to kill me if I let them know that the only reason for ld --no-add-needed was the readline issue ;)
#ubuntu-release 2012-08-20
<babyface> why no precise daily build on  Aug 18, Aug 19, and Aug 20 ?  The latest build number is 20120817.3,   is it frozen for 12.04.1 release?
<stgraber> yes
<babyface> stgraber, ack. thanks.
<phillw> stgraber: any news on http://iso.qa.ubuntu.com/qatracker/milestones/230/builds/21391/downloads ?
<stgraber> fixed
<tkamppeter> ScottK, hi
<tkamppeter> Anyone around to do an urgent fix on 12.04.1?
<Laney> tkamppeter: you know it's past the final freeze?
<tkamppeter> Laney, I did not know that, so should I simply make a normal SRU out of that? The thing is that all Samsung printers (on USB) will not work with current 12.04.1 state and a small patch will fix that.
<Laney> You'll have to talk to the .1 team (skaet or stgraber) but I expect you should just do a normal SRU, yes.
<Laney> sounds like it could be release noted to me
<Laney> anyway the first steps are common so you can file the paperwork and upload to -proposed either way
<tkamppeter> RAOF, great that you came back (it is late for you?) I have found out that the fix is a small patch.
<tkamppeter> Laney, RAOF, as normal SRU it is not so urgent then. I will ask the user to report a separate bug and as soon as I have the bug number I will do the rest.
<tkamppeter> RAOF, I do not know whether you got my last comments, the problem with the last CUPS SRU is that all Samsung printers (on USB) will not work. The patch is small.
<tkamppeter> RAOF, did you get my last comments?
<RAOF> tkamppeter: No, I didn't get your last message.
<RAOF> tkamppeter: Sorry, my IRC bouncer has gone all doolalley.
<RAOF> tkamppeter: However, we can't leave cups -0ubuntu3 in -updates, given that it's got a regression from -0ubuntu2. Either we fix the regression in -0ubuntu3 and keep the fix for the Canon printers, or we roll back to -0ubuntu2 and unfix the Canon printers.
<cjwatson> bdmurray: could you please rename regression-proposed-bug-search.py to just regression-proposed-bug-search, to match the rest of ubuntu-archive-tools?  I'd do it myself but I don't know if you have a cron job somewhere calling it.
<tkamppeter> RAOF, still there?
<tkamppeter> RAOF, I hope your connection stays stable now.
<tkamppeter> RAOF, 0ubuntu2 breaks all Canons, printing the last page only by half, 0ubuntu3 breaks all Samsungs. I have put up a 0ubuntu4 in my PPA now which fixes all this.
<Laney> IMHO you should get it uploaded to proposed and tested ASAP
<Laney> but I'm no SRU team member
<tkamppeter> RAOF, Laney told me that 12.04.1 is after Final Freeze so I should do 0ubuntu4 as normal SRU.
<tkamppeter> Laney, RAOF, I did not start the actual SRU yet because the original reporter (he is in Brazil, it is still 7am there) hijacked an existing bug report instead of creating a new one. Now I am waiting for him to read my comments, test my fix in the PPA, and open a new bug report.
<Laney> why can't he test it in proposed?
<seb128> tkamppeter, it's end of day where RAOF lives, you should just get it uploaded and get somebody else from the SRU team to ack it
<Laney> SRU regressions are pretty important to fix in a timely fashion
<Laney> is the bugged version on the .1 isos?
<seb128> it's in precise-updates so I guess it's on the candidate .1 iso yes
<seb128> we should get the fix uploaded asap
<seb128> tkamppeter, get the fix uploaded please and let's wait of stgraber or skaet to be online
<tkamppeter> seb128, I will do so,
<tkamppeter> seb128, uploaded. How should I do the SRU procedure now? On the existing bug or should I create a new bug?
<seb128> tkamppeter, use the bug you listed in the changelog of the upload you did
<tkamppeter> seb128, OK, I will reopen the bug and update its description ...
<seb128> tkamppeter, ok open a new bug and use that one for the changelog
<seb128> tkamppeter, you can reupload cups with the new bug reference if you prefer
<tkamppeter> seb128, now I have done everything on bug 1032456.
<ubot2`> Launchpad bug 1032456 in cups "Canon inkjets (and some other printers) print only half of the last page after 20120801 upgrade to v1.5.3-0ubuntu2" [Critical,In progress] https://launchpad.net/bugs/1032456
<phillw> Hi folks, could some one please advise as to against what this bug should be reported...http://pastebin.com/SRLnr5fB
<cjwatson> phillw: Pick one of linux or nvidia-graphics-drivers.  In my distinctly amateur opinion I'd suspect nvidia-graphics-drivers since it could well be fallout from the new X stack.  If you want an actual expert opinion then try #ubuntu-kernel or #ubuntu-x.
<phillw> cjwatson: thanks, I'll go ask there. I don't want to give the wrong information to a tester!
<phillw> cjwatson: just FYI, #ubuntu-x asked that it be filed against xorg, (the nvidia-drivers are not present on the LiveCD), at least we have a starting point! :D
<cjwatson> phillw: ok
<smartboyhw> phillw: How is the Lubuntu testing going for 12.04.1?
<smartboyhw> Sorry, wrong channel
<phillw> smartboyhw: lubuntu 12.04 is not an LTS, we simply lack enough people to commit
<smartboyhw> OK
<smartboyhw> phillw: On the extent to your answer, why isn't Lubuntu 12.04 an LTS?
<stgraber> tkamppeter: SRU regression fix should probably be included on 12.04.1, assuming it can get accepted into -proposed ASAP and you have testers that can verify it quickly too
<stgraber> infinity: if you're already/still around, can you take a look at that cups SRU in the queue? would like it in -proposed for testing ASAP
<stgraber> or any SRU team member ^
<stgraber> skaet: cups upload is an SRU regression, the package is on the media and it fixes printing on Samsung printers, considering it as a reason for respin, just hoping to have it in -proposed, verified and copied by EOD
<tkamppeter> stgraber, seems that the problem now is that no one of the SRU team is in our time zone.
<stgraber> ScottK, cjwatson: can one of you review the cups upload in precise proposed?
<stgraber> (in the unapproved queue for precise-proposed that's)
<skaet> stgraber,   need to understand more details as to whether its a respin reason or not,  since discussion last week pointed to limited scope,  and it can be applied in update.   Depends how much testing has occured at this point.
<cjwatson> It's a regression, and I thought we had zero tolerance for those
<stgraber> skaet: so far none, that's why I want it in -proposed. Bug description says that it regresses all samsung printers
 * xnox has a samsung printer. Is that why I had to readd four times & fiddle with cups to get it to print?
<cjwatson> The diff looks fine to me
<stgraber> xnox: might be yes, apparently the second printed job gives you garbage
<xnox> stgraber: yes!
<stgraber> xnox: bug 995111 (relevant part for Samsung is in the testcase section)
<skaet> stgraber,  if no testing so far, then +1 on respinning.
<ubot2`> stgraber: Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/995111)
<skaet> however,  looking at the iso tracker there does seem to be some.
<xnox> stgraber: funny thing: test page is fine, next job garbage. Readd: skip test page, print one job. (that was 40minutes of my life 3 days ago)
<cjwatson> Aren't we building images from -updates and not -proposed anyway?
<stgraber> skaet: I was saying, no testing of the SRU, not no testing of 12.04.1 (though I refrained from doing any testing today as I noticed this one being a respin candidate)
 * cjwatson accepts since I'm pretty sure this won't affect images until it goes to -updates
<tkamppeter> xnox, you could verify the fix if someone of the SRU people approves the -proposed package.
<skaet> stgraber,  am fine with it going in -proposed.  images are being made from -updates at this point.
<cjwatson> tkamppeter: I just did
<xnox> tkamppeter: sure.
<stgraber> right, we build from -updates, so getting it in -proposed is fine in all cases
<stgraber> tkamppeter,xnox: can you get this tested as soon as possible?
<tkamppeter> xnox, I have subscribed you to the bug now.
<skaet> stgraber,   looks like the iso tracker is showing instances of : https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/946718
<ubot2`> Ubuntu bug 946718 in update-notifier "backend_helper.py crashed with RuntimeError in add_signal_receiver(): To make asynchronous calls, receive signals or export objects, D-Bus connections must be attached to a main loop by passing mainloop=... to the constructor or calling dbus.set_default_main_loop(...)" [High,Triaged]
<xnox> tkamppeter: I only have a samsung printer, not a canon one.
<stgraber> xnox: well, you can at least test the samsung part of the fix, which is the SRU regression
<stgraber> then we need someone with an affected canon to confirm we don't regress that part with that new SRU
<tkamppeter> xnox, please follow the build status on https://launchpad.net/ubuntu/precise/+source/cups/1.5.3-0ubuntu4 and getting to your architecture under Builds. Try to install the new package as soon as possible to give us quick feedback.
<xnox> stgraber: tkamppeter: just to be clear with package version numbers: 0ubuntu2 & 0ubuntu4 should be good on samsung; 0ubuntu3 is bad on samsung?!
<stgraber> that matches my understanding, yes, tkamppeter can confirm for sure
<tkamppeter> xnox, you are absolutely right.
<tkamppeter> xnox, i386 and amd64 of the package are successfully built by our servers now.
<xnox> ok. let me try this
<mvo> would someone have time to sru-review the glib-networking diff in precise-proposed? it unbreaks purchases for certain users
<stgraber> tkamppeter: can you help me figure out exactly what set of samsung printers are affected by this bug?
<stgraber> tkamppeter: does it depend on specific model, the way they're connected to the machine or just the cups driver?
<tkamppeter> stgraber, it is notr sure whether all Samsungs are affected, but users reported similar problems for very different Samsungs. So at least all these users suffer the regression. It happens only if the printer is connected via USB. Network-connected Samsungs do not show the problem.
<tkamppeter> stgraber, the printer driver (SpliX, gdi, PostScript, ...) has no influence on this.
<stgraber> tkamppeter: ok, I did a quick test and couldn't reproduce on my splix samsungs (ML-1520 and ML-1610) but apparently the CPL model at my parent's place is affected (though usually printing over the network so not a big deal)
<xnox> I have CLP-325
<xnox> and with -0ubuntu3 i printed two different jobs in a row with color, two pages each just fine.
<stgraber> the one at my parents' is a CLP-610
<seb128> xnox, isn't that the supposed buggy version?
<stgraber> xnox: you mean ubuntu4?
<xnox> no, I do mean -0ubuntu3, the one that was meant to be buggy.
<stgraber> oh
<xnox> i can't reproduce the regression =/ so obviously mine is not affected =/
<xnox> it is using foo2qpdl thing
<stgraber> hmm, quite annoying that we can't get some kind of list of affected hardware...
<stgraber> saying "any samsung printer printing garbage after the first job" is really quite a bad way of letting people know whether they're affected or not ;)
<xnox> in syslog I can see how usblp0 was removed & handled after each job.
<skaet> s/any/some/  is more accurate, at any rate.   But yes agree would be good to identify which samsung printers are affected.
<xnox> i "suposedly" have the same series printer as the bug reporter of bug 992982
<ubot2`> Launchpad bug 992982 in cups "Network printing fails. Worked before upgrade to 12.04 (dup-of: 973270)" [High,Fix released] https://launchpad.net/bugs/992982
<ubot2`> Launchpad bug 973270 in system-config-printer "Printer does not provide REQUIRED job history." [High,Fix released] https://launchpad.net/bugs/973270
<skaet> tkamppeter, is there a good way of quantifying the affected printers?
<xnox> wait a minute, network printing fails?!
 * xnox has a 28 page document i need to print, doing two pages at a time is both productive and useful
<xnox> ok, I got a test-page printer error remotely.
<xnox> upgrading.
<tkamppeter> xnox, network printing is not affected by the transition ubuntu2/3/4. You need to connect your Samsung to USB. The ubuntu2 will work, ubuntu3 not and ubuntu4 should work again.
<tkamppeter> skaet, assuming that all Samsungs are affected there will be a lot of users, as Samsung makes good laser printers for a rather cheap price.
<skaet> tkamppeter, stgraber's did a test with his home printers,  and 2/3 Samsung's worked fine.
<stgraber> tkamppeter: well, quite clearly not all of them, the old ones I have around here have been printing 10 separate jobs in a row using 1.5.3-0ubuntu3
<skaet> hypothesis is that its the later models.
<skaet> s/later/newer/
<tkamppeter> skaet, that is possible, all these bug reports are about rather new models.
<tkamppeter> stgraber, your Samsung printers are connected via USB?
<stgraber> tkamppeter: yep
<stgraber> tkamppeter: ML-1520 and ML-1610 over USB (6-7 years old black&white laser models)
<tkamppeter> stgraber, seems that your printers are too old to be affected. Problem are possibly only newer printers and then no matter whether bw or color.
<xnox> over the network: 0ubuntu3 _did not_ print test page, 0ubuntu4 _did_ print test page.
<xnox> I have CPL-325 similar to the one of the dupes bug 992982
<ubot2`> Launchpad bug 992982 in cups "Network printing fails. Worked before upgrade to 12.04 (dup-of: 973270)" [High,Fix released] https://launchpad.net/bugs/992982
<ubot2`> Launchpad bug 973270 in system-config-printer "Printer does not provide REQUIRED job history." [High,Fix released] https://launchpad.net/bugs/973270
<tkamppeter> xnox, interesting, the difference between ubuntu3 and ubuntu4 is a small patch on the USB backend. So your printer is connected by its ethernet port? Please try it with the printer connected through USB.
<xnox> tkamppeter: no. My printer is connected via USB to the server running CUPS. I am printing over the network from a laptop.
<tkamppeter> xnox, if you install the test packages ubuntu3 and afterwards ubuntu4 on your server then the test is valid and verifies the SRU.
<xnox> I did.
<stgraber> xnox: right, so what's you're testing is USB printing (with a remote cups server), not network printing (some Samsung like the CLP-*N* have a builtin web server that supports IPP for real network printing)
<tkamppeter> xnox, thenthe Samsung fix in the ubuntu4 SRU is verified.
<stgraber> s/'s//
<xnox> printing directly on my server worked both with ubuntu3 & ubuntu4
<stgraber> xnox: with the same document? (test page)
 * xnox mutters something about "network printing, over the network printing, remote cups, etc..."
<xnox> stgraber: test page & normal document (2 different pages each time, no repeats so far)
<xnox> Simple question: why is https://launchpad.net/ubuntu/+source/cmake/2.8.9-0ubuntu1/+build/3727645 not building
<xnox> & launchpad.net/builders says 0 packages in i386 queue
<tkamppeter> seb128, I am aware of the c2esp problem, as you have already seen, said lib moved to cups-filters
<tkamppeter> seb128, I can contact the upstream of the package.
<seb128> tkamppeter, that would be good
<seb128> tkamppeter, thanks
<infinity> xnox: That is kinda curious...
<xnox> infinity: no-change reupload? =)
<tumbleweed> because the score isn't over 9000?
<tumbleweed> :)
<ogra_> low score empties the queue ?
<skaet> stgraber,  onces the cups fix tests out we'll move it to upgrades and pick it up for any images that choose to respin,  others will get it as a zero day SRU.
<xnox> tumbleweed: that only applies if the source package name is longer than 6 characters & it's in the netbook remix package set.
<xnox> ogra_: i wouldn't think 2555 is low, for a package in main
<ogra_> well, i wouldnt think 5000 is low, depends on the perspective
<xnox> infinity: more interesting is how many other packages are like that.
<ogra_> though i still dont get the connection with the empty queue
<Laney> paging wgrant :P
<Laney> ah, already done in -ops
<wgrant> Yeah
<xnox> ogra_: well at first i386 were busy building what not. now they are doing nothing, yet they could be building cmake...
<wgrant> Can it wait until the morning?
<Laney> cmake is rather urgent, because skew
<wgrant> OK, let me see what I can do now
<Laney> hard to know for others due to not being able to see what they are
<wgrant> Yeah
<wgrant> I might fix cmake now
<xnox> wgrant: please make it build =) https://launchpad.net/ubuntu/+source/cmake/2.8.9-0ubuntu1/+build/3727645
<xnox> wgrant: thanks a *tonne* =)
<wgrant> It's fallout from when there were two buildd-managers running simultaneously due to an unfortunate accident before the DC move
<stgraber> ogra_: I rescored it when it was mentioned, to check if LP would somehow refresh and re-schedule it
<xnox> stgraber: 9000? didn't help =(
<stgraber> xnox: yeah, I know, I didn't bother down-scoring it after I saw it didn't help
<ogra_> as long as it thinks the queue is empty ...
<stgraber> tkamppeter: do you know people you can try to directly ping/email to test on Canon and Samsung printers?
<stgraber> we apparently won't respin for it but it'll be included if we need to respin for something else. However we will allow individual product leads to respin if they want and we certainly want the fix for the regression in -updates ASAP
 * stgraber -> lunch
 * skaet nods
<bjf> infinity: feel like accepting my kernel pkgs?
<wgrant> xnox, Laney: I've requeued all 9 affected builds
<wgrant> And cmake is building on at least i386 now
<Laney> cheers, the archive thanks you
<xnox> wgrant: thank you very much.
<tkamppeter> stgraber, I tried to contact the users per Launchpad message, but as I have only 3 message permission per day I cannot contact 8 users. Can someone raise my permission? Or could it be generally rasied for Canonical employees?
<bjf> any AA feel like accepting the kernel pkgs in the queue?
<infinity> bjf: I'm on it this morning, yes.
<bjf> infinity: thanks
<tkamppeter> stgraber, succeeded to contact two more users by e-mail.
<tkamppeter> stgraber, ScottK, I got confirmation by one user that the new CUPS SRU still fixes the last-page-not-completely-printed problem, the original problem of bug 1032456.
<ubot2`> Launchpad bug 1032456 in cups "Canon inkjets (and some other printers) print only half of the last page after 20120801 upgrade to v1.5.3-0ubuntu2" [Critical,Fix committed] https://launchpad.net/bugs/1032456
<skaet> ScottK, Riddell - if the ducks line up and we get the cups fix moved to -updates today, do you want Kubuntu images respun?
<skaet> scott-work, astraljava, knome, ^  how about for your flavors?
 * skaet knows that Edubuntu wants respinning.  ;)
<stgraber> jibel: any chance you or someone from your team can do a wubi upgrade test? the result on the tracker currently is a bit worrying
<jibel> stgraber, I'll do it tonight if my connection is stable for more than 10 minutes
<utlemming> who is managing the jenkins instance while Mr. Page is away? I have a job whilst testing the cloud images that seems to have gone to lunch and that means that I can't do any further testing
<jibel> utlemming, which job ?
<utlemming> jibel: precise-server-ec2
<utlemming> it should complete in a few hours, it's been hung for over three days
<knome> skaet, what does that fix anyway? :]]
<knome> i'd vote for no respin, but i'll let astraljava have the last word.
<skaet> knome,  fix so that some of the Samsung printers work.
<stgraber> knome: recent samsung printers printing garbage on the second print job
<skaet> we had a regression, with the last cups update
<stgraber> (where "recent" is sadly an unknown set of printers)
<knome> hmh. :|
<skaet> it can be zero day SRU though.
<knome> what does that mean? :)
<skaet> which is what Ubuntu's likely to do.
<stgraber> right, which means that if you have users working with a live environment or don't -updates they won't be able to print
<stgraber> but everyone else will have an update available right after the 12.04.1 release
<knome> that sounds good - but does that still need a respin?
<jibel> utlemming, looking
<knome> skaet, btw, if there's something i should still sign, please remind me; if not and i missed at least one thing, sorry
<utlemming> jibel: thank you kindly
<skaet> Once its in -updates,  people will get it applied,  same way other bug fixes.
<knome> so no respin now?
<stgraber> knome: that's what we're asking you ;) Edubuntu considers that we have enough users using the live media or a usb disk made from the live media that we will respin for this
<jibel> utlemming, can I safely kill them all ?
<stgraber> but the decision is up to you for xubuntu
<jocarter> stgraber: which bug is that?
<skaet> knome,  please review the Release Notes,   and once the testing is finished,  will need you (or someone designated from Xubuntu team) to sign off on https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest/12.04.1 that the images are ready to ship.
<stgraber> jocarter: bug 1032456
<ubot2`> Launchpad bug 1032456 in cups "Canon inkjets (and some other printers) print only half of the last page after 20120801 upgrade to v1.5.3-0ubuntu2" [Critical,Fix committed] https://launchpad.net/bugs/1032456
<knome> aha, right. i'll still say no respin for now, if the update is available later for everybody
<skaet> knome - Release Notes to be reviewed for any updates are at: https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/Xubuntu/
<skaet> any key changes between 12.04 and 12.04.1 should be ADDED to the page,  as should any bugs you want to make sure your users are warned of.
<stgraber> jocarter: I haven't started validating 12.04.1 yet for Edubuntu, so respinning was an easy decision to make ;)
<skaet> :)
<jibel> utlemming, I deleted precise-ec2 that was running for 3 days and ec2-daily which was running for 5 days
<jocarter> ok, well, I'm busy with really boring work at work this week that I'd like to avoid if possible, so if there's something that needs "urgent testing" at some point then that will be nice.
<utlemming> jibel: yikes
<knome> skaet, ok, thanks. i'll take care of that
<knome> skaet, when's the "testing deadline" ?
<stgraber> jocarter: I'll keep that in mind ;) but I tested the images on Saturday so I'm quite confident we won't have anything blow up for Edubuntu at least
<skaet> knome,  testing deadline is EOD Wednesday\
<knome> skaet, oki :)
<skaet> where EOD Wednesday is 2100 UTC.  ;)
<knome> hehe
<knome> yeah, sounds like EOD for me... (0000 here)
<skaet> :)
 * skaet --> lunch,  biab
<jibel> utlemming, for info they were all blocked on "bzr branch lp:~ubuntu-server-ec2-testing-dev/+junk/ec2-automated-tests tests"
<jibel> utlemming, do you want to replay the builds I aborted ?
<utlemming> jibel: interesting....no, I'll kick new ones
<jibel> utlemming, ok
<scott-work> skaet: i'm sorry, i missed the question
<scott-work> oh, skaet, if this a fix for samsung printers then i think ubuntu studio can skip the respin/retest
<jibel> stgraber, I asked for more info, I'm not even sure he did an upgrade
<tkamppeter> stgraber, I have now one user who confirmed Samsung working and another user who confirmed his Canonb continuing to work.
<stgraber> infinity: if you consider that good enough as a verification for the cups SRu regression, can you please release it to -updates? ^
<infinity> stgraber: I'll have a gander at that in a sec.
<infinity> stgraber: Released.
<stgraber> infinity: thanks, I'll wait for the publisher and start respinning Edubuntu
<tkamppeter> infinity, thank you very much.
<infinity> bjf: ^-- You didn't need to copy those again. :P
<infinity> bjf: (I was going to batch all of precise together with the arm kernels)
<bjf> infinity: my bad. i'll back away from the kbd
 * infinity lunches.
<skaet> scott-work,  yup that was the question.   How goes testing?  any surprises/concerns?
<jibel> stgraber, upgrade from Oneiric in Wubi works fine on bare-metal. 32 and 63bit
<jibel> 64bit even
<stgraber> jibel: good to hear, so that was a completely unrelated bug reported on the tracker then
<skaet> :)
<jibel> stgraber, my feeling is that he is talking about an installation not an upgrade. and he's installing Wubi i386 on WindowsXP running in a VM on Windows7
<jibel> he can probably embed more OS but he'll reach a limit at some point
<scott-work> skaet: i don't think anyone has run into any surprises at this point
<skaet> scott-work,  thanks.
<skaet> ScottK,  Riddell - do you want the respin to pick up the CUPs fix for Samsung printers or not?
<ScottK> Dunno.  I've been offline all day.
<skaet> ScottK,  a fix has been move to -updates.   We're not respinning ubuntu for it, but picking it up as 0 day SRU,  Edubuntu's respinning now though, and so wanted to know your preference.
<ScottK> skaet: We've got no current results, so I'd say respin.  I'd wait for a bit to see if Riddell  checks in and has a different opinion.
<skaet> ScottK,  lets time bound this then,  since its late for Riddell,  and coming up on EOD for North America.   If he doesn't say otherwise in next hour,  we plan on respinning.   Fair?
<ScottK> Fair.
<ScottK> I'll be offline for about 90 minutes very shortly.
<skaet> stgraber, ^    Let me know if you want me to kick the images off.
<skaet> ScottK,  ok.   Will let you know outcome when you're back online.
<seb128> skaet, ubuntu doesn't respin with that fix? do we have an idea how much of the samsung printers are broken?
<stgraber> skaet: I'll do it
<stgraber> seb128: that's the problem, we don't really know. I confirmed that old models (6-7 years old) don't seem to be affected, but we don't have a lot of users of the more recent models to get an idea of how many are broken
<skaet> seb128,  it will get picked up as 0-day SRU.
<skaet> (and we can release note it as such)
<seb128> well, lot of people have offline installs
<seb128> is a respin really too much extra work at this point?
<skaet> its not the respin,  its the retesting.
<seb128> well, that's a side effect of the respin
<cjwatson> skaet,Daviey: I just happened to look at https://wiki.ubuntu.com/QuantalQuetzal/ReleaseManifest and noticed that the server images are described as "livecd".  I think this is misleading.  They aren't live images - they use a squashfs to improve base system installation performance, but that's essentially an implementation detail and not the sort of fundamental change suggested by the "livecd" image type.
<cjwatson> We should probably simply call that "server", as before.
<Daviey> cjwatson: err, yeah.. i didn't know it had changed
<skaet> cjwatson,  if Daviey is fine with changing them back, I'm ok with it.
<skaet> Daviey, it was likely me.
<Daviey> oh.. ok
<Daviey> I don't think i care enough either way TBH :)
<cjwatson> I've changed it back to server
<Daviey> super
<xnox> Now that cmake is build and published (due to previous fallout), can somebody please retry ball powerpc & armel builds?
<xnox> https://launchpad.net/ubuntu/+source/ball/1.4.1+20111206-4/+build/3730436
<xnox> https://launchpad.net/ubuntu/+source/ball/1.4.1+20111206-4/+build/3730433
<Daviey> xnox: done
<xnox> Daviey: merci =)
<Daviey> "Start in 20 hours"
<infinity> Yeah, it'll get there.
<infinity> The weekend wasn't kind to us.
<xnox> infinity: Daviey: well armel & powerpc are busy building gcc & thunderbird.... no surprise the acquired backlog ;-)
 * xnox it was empty earlier.... hehe
<infinity> xnox: "empty"?
<infinity> xnox: You mean "nothing was building because the world was broken".
<xnox> infinity: yes, that =)
<infinity> xnox: The ARM and PPC queue haven't been empty since the DC move started last week.
<Daviey> well, the chances of introducing regressions was smaller.. so it's not all bad.
<infinity> cjwatson: Thanks for the override length fixes.
<cjwatson> YW
<stgraber> no reply from Riddell, starting the Kubuntu respin
<stgraber> in progress
 * xnox ponders if fixing bug 947107 quickly wil make it into 12.04.1 release....
<ubot2`> Launchpad bug 947107 in ubiquity "No partition labels in 12.04 partition wizard" [Wishlist,Confirmed] https://launchpad.net/bugs/947107
<stgraber> no
<xnox> stgraber: =(
<stgraber> xnox: unless that's a regression from the 12.04 release, I'd prefer not to have any non-critical installer fix as that'd need rebuild of pretty much everything but core and server and would need full re-testing
<stgraber> so we're looking at >24h just for the rebuild+basic re-test time
<xnox> i see, that *is* stressful.
#ubuntu-release 2012-08-21
<TheLordOfTime> Precise is still frozen, right?
<RAOF> Precise is frozen forevermore.
<TheLordOfTime> i meant for updates.
<TheLordOfTime> then i realized...
<TheLordOfTime> wrong channel.
<TheLordOfTime> :P
 * TheLordOfTime has too many damned channels
<TheLordOfTime> (and the ZNC is slow to join them all)
<infinity> TheLordOfTime: Nothing is being accepted into -updates at this point, so image building is stabilised until 12.04.1's release, but -proposed is vaguely open again.
<TheLordOfTime> right, but nothing will go from -proposed -> -updates until post-12.04.1 release?
 * TheLordOfTime is checking so he can correctly respond to a bug he was subscribed to
<TheLordOfTime> (regarding a program update to Precise)
<infinity> TheLordOfTime: Right, nothing will migrate (unless we find something we critically MUST fix for .1) until after .1 ships.
<TheLordOfTime> that's what i thought
<TheLordOfTime> just wanted to confirm that freeze on -updates was still in place :)
 * TheLordOfTime thought that was still the case, but wanted to confirm :)
<TheLordOfTime> *yawn*  this is why i sometimes hate being subscribed to a package's bugs... you get pinged on ***EVERYTHING*** and everyone sometimes expects you to know the answers :/
<TheLordOfTime> (case in point why i poked around about this)
<TheLordOfTime> anyways, back to bug triaging, thanks infinity for confirming what I suspected, that -updates is still frozen :)
<TheLordOfTime> out of pure curiosity, is there a site or something that would state whether $given_repo is frozen or not?
<TheLordOfTime> so i don't have to poke around to the various teams (Release, Security, MOTU, etc.) about whether its frozen :P
<infinity> Not so much, no, you just need to be on top of the release process.  Or not care. ;)
<infinity> I recommend the latter option to most people.
<TheLordOfTime> :P
<infinity> Upload as if there's no freeze, let us deal with it when we thaw the world.
<TheLordOfTime> well, when you're triaging bugs, and there's questions about whether something can be moved from -proposed to -updates, well....
<TheLordOfTime> you kinda need to know whether there's a freeze :P
<infinity> Well, it's not up to bug submitters/commentors whether things move anyway, even when not in a freeze. :P
<TheLordOfTime> (namely, the people who actually are incessantly annoying and naggy will say "Why isnt this fixed in Precise yet?"  "Why isnt it fixed?"
<infinity> It's up to the SRU team.  And we have a handle on what we're moving and why.
<TheLordOfTime> indeed, however to get the person to stop posting "Why"... :P
<infinity> (Or what we're not moving, right now)
 * TheLordOfTime is one of the contacts for that given package, so...
<TheLordOfTime> anyways, thanks again.  :)
<TheLordOfTime> actually, for a different reason, i wanted to know whether the freeze existed, there was a... "regression" we'll call it... between oneiric and precise's version of php5, and there's a ton of people (including myself) that wanted that fix pushed into precise pre-freeze, but it never happened.  Thank god for my SRU testing PPAs :P
<TheLordOfTime> anyways, i'll leave you all be.
<astraljava> skaet: stgraber: I don't feel there's a need for respins of neither Studio nor Xubuntu, either. Unless I missed any conversations about this, I concur with knome and scott-work.
<njin> hallo mismatch kernel in ubuntu server amd64
<xnox> njin: ogra_ is on it ;-)
<ogra_> well, as much as clicking a retry button on LP means "on it" :)
<njin> xnox, ogra_ thanks
<xnox> ogra_: well, I have no such button, so you win!
<skaet> astraljava, ok.
<skaet> seb128, https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1038573 - who's looking at it?
<ubot2`> Ubuntu bug 1038573 in evolution "Unreadable messages displayed during Lucid -> Precise upgrade" [High,Triaged]
<astraljava> skaet: The only thing that might require a respin for Studio is the possible refresh of -lowlatency, but I haven't heard of this thus far. And yes, I have noted the nearing testing deadline. :)
<skaet> astraljava,  ack.  :)
<seb128> skaet, nobody, shouldn't those bugs be tagged or assigned to our team so we notice them coming?
<seb128> skaet, I will ask cyphermox to have a look since he fixed the similar looking issue the bug is pointing at, maybe his fix needs some tweaking
<skaet> seb128,  depends on who's opening them how well the process is followed.   Thanks for asking cyphermox
<seb128> skaet, thanks for pointing it
<xnox> infinity: https://launchpad.net/builders/ross is calling out for you =)
<xnox> Non-virtual builder in ABORTED state, requires admin to restart
<Laney> xnox: care to ask someone in launchad-ops internal?
<xnox> Laney: ok.
<skaet> stgraber, slangasek - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1039405 -  is there a recommended minimum configuration we should update the release notes to?
<ubot2`> Ubuntu bug 1039405 in ubiquity "Lockups when running vm's with 768MB of memory" [Undecided,New]
<xnox> skaet: I think that when people do "Try Ubuntu -> install" instead of just "Install now"
<xnox> it eats more memory.
<cjwatson> Yes
<xnox> so "Install now" can/should have lower memory footprint.
<xnox> needs testing to determine the limit for both ways of running it.
<skaet> thanks xnox, cjwatson.
<njin> xnox, are you working ov bug 1037515 ?
<ubot2`> Launchpad bug 1037515 in ubiquity "ubiquity-dm crashed with MissingProgramError in run(): No window manager found (tried metacity, xfwm4, matchbox-window-manager, openbox-lubuntu, openbox)" [Medium,Confirmed] https://launchpad.net/bugs/1037515
<xnox> njin: no, I am currently looking into LVM2
<njin> ok, I require in bugsquad then, thanks
<slangasek> cjwatson: do you think there's any action we should take on bug #1039405?  The submitter suggests that ubiquity should fail to start with a warning when it knows it has too little memory
<ubot2`> Launchpad bug 1039405 in ubiquity "Lockups when running vm's with 768MB of memory" [Undecided,New] https://launchpad.net/bugs/1039405
<cjwatson> That's kind of problematic since ubiquity doesn't necessarily know for sure
<cjwatson> 768MB is what I use for my test VMs
<slangasek> ok
<cjwatson> So I don't actually buy that this is a low-RAM case
<skaet> slangasek,  cjwatson,  cross checked earlier with QA and a 1G system does work with "Try Ubuntu"
<slangasek> cjwatson: using "Try Ubuntu"?
<cjwatson> Yes
<Daviey> skaet / stgraber: i don't think we need to respin for bug 1032456
<ubot2`> Launchpad bug 1032456 in cups "Canon inkjets (and some other printers) print only half of the last page after 20120801 upgrade to v1.5.3-0ubuntu2" [Critical,Fix released] https://launchpad.net/bugs/1032456
<slangasek> alright
<cjwatson> I used to use 512MB not that long ago
<cjwatson> If 768MB were now too small, that would be a pretty serious ballooning in not very much time
<skaet> Daviey,  its down as an opportunity target.   Some flavors are picking it up,  others are not.
<skaet> Daviey,   if we respin Ubuntu for other reason's we'll pick it up,  otherwise release note time.
<Daviey> yep, that sounds fine.
<cjwatson> I'm suspicious that all the memory allocation failures there are in fork()
<jibel> skaet, hm ok, I can reproduce 1039405 with 768MB and 12.04.1 amd64 by booting to a live session, and running ubiquity with all the defaults values
<cjwatson> amd64 might have a different limit I guess; I usually use i386
<skaet> thanks jibel.
<cjwatson> amd64 limits aren't a major concern in reality since who has an amd64 box with <1G
<Daviey> cjwatson: erm, does this impact virtual machines?
<Daviey> oh, desktop only.. don't care :)
<ogra_> youre so evil !
<Daviey> well, i do care.. really.. and it is certainly less than ideal.
<smartboyhw> Well, I think that setting a limit for amd64 is better, don't set a limit on i386 I think
<ogra_> :)
<smartboyhw> Hi ogra_
 * xnox typically gives a VM 2 cpu cores and 2 GB or ram and directio to external drive.....
 * tumbleweed typically uses 1GB for my VMs. But at some point, I'll have to bump that...
<jibel> on i386 with 512MB I get page allocation failures from the kernel when it mounts the target FS.
<xnox> jibel: this is with "try ubuntu" right?
<jibel> xnox, right
<cjwatson> Some of this might be better in quantal due to the rewritten console page
<cjwatson> That was a fairly non-trivial memory hog
<cjwatson> Might be worth backporting for .2 if it makes a difference to this kind of thing
<infinity> skaet: Even if you don't respin for the cups bug, there's no reason (IMO) to release note something that has a fix sitting in -updates and doesn't affect the installation.
<stgraber> infinity: it'll affect anyone trying to print from the livefs on an affected system
<stgraber> and apparently people use our live environment for more than running ubiquity...
<infinity> stgraber: People turn livecds into print servers?
 * infinity shrugs.
<infinity> I know my brother uses livecds for pristine/secure web browsing, but people who print web pages are weird (ie: my parents) and almost the exact inverse of the set of people who read release notes. :P
<stgraber> :)
<smartboyhw> ;)
<infinity> But more seriously, if we release note every known bug, it's a phone book that NO ONE will read, that's not what they're for.
 * xnox remembers 7-digit phone numbers they were nice
<smartboyhw> Oh!
<Daviey> xnox: i remember 4 digit phone numbers :)
<xnox> Daviey: stop showing your age, you look much younger than 4 digit numbers ;-)
<tumbleweed> I was going to remember 6 digit phone numbers, but I knew *someone* would one-up me
 * ogra_ had a 4 digit number in his last house
<ogra_> if you move far enough to the countryside they get shorter and shorter :)
 * knome barely remembers his 2-digit age
 * balloons missed the end of the https://launchpad.net/bugs/1039405 conversation
<ubot2`> Ubuntu bug 1039405 in ubiquity "Lockups when running vm's with 768MB of memory" [Undecided,New]
<cjwatson> probably amd64-specific; just splatting in a memory check is the wrong answer; may well be possible to backport keyboard page improvements from quantal for .2
<balloons> cjwatson, ty ;-)
<stgraber> jibel: noticed that nobody did i386 LTSP, I'll take care of it.
<tjaalton> i've uploaded xorg that adds xserver-xorg-video-modesetting to x-x-video-all depends, fixes bug 1039648
<ubot2`> Launchpad bug 1039648 in xorg "kvm/cirrus: X driver will not load when kernel module is loaded" [High,Fix released] https://launchpad.net/bugs/1039648
<tjaalton> means that -modesetting needs to be moved to main
<tjaalton> doubt it would need a MIR..
<xnox> tjaalton: \0/
<jibel> stgraber, I doing mac atm, I can do ltsp right after if you want
<stgraber> jibel: install is running here
 * skaet --> lunch
<jibel_> balloons, skaet alternate on mac is ok, I tested encrypted+lvm and non-encrypted/guided and manual partitioning
<jibel_> no testing desktop images
<jibel_> now
<balloons> jibel, k.. I'm trying to fill in the missng tests as well on the alt images (non-mac of course)
<balloons> jibel, does selecting ftp as mirror fail for you on alt images.
<balloons> I've seen that before.. but it might actually be a bug
<jibel_> balloons, I didn't try to select ftp as mirror, I will test it
<balloons> jibel, trying again with i386 iso..
<balloons> I was using vm.. that MIGHT have caused the issue..
<balloons> ahh.. got it to work now with ftp://mirror.anl.gov/pub/ubuntu
<balloons> jibel, seems like the vmwareeasyinstall testcase is a bit messed up.. I'll update it.. I took new screenshots anyway :-)
<jibel> balloons, how messed up ? there is already all the screenshots on the wiki
<jibel> http://testcases.qa.ubuntu.com/Install/VMWareEasyInstall
<balloons> http://iso.qa.ubuntu.com/qatracker/milestones/230/builds/21389/testcases/591/results
<balloons> most of precise didn't get updated to point to the new testcases it looks like.. I just left it alone
<balloons> but it seems the conversion for this testcase only has 2 steps :-)
<jibel> ah ok. 2 steps are more than enough for this test. 1. select the iso 2. click next until installation is done
<balloons> lol.. it's pretty much it
<balloons> so getting vmware player running required a patch.. how odd
 * balloons not a fan
<knome> vmware... why not use vbox :)
<jibel> balloons, do you use the linux or windows version ? on ubuntu I couldn't install it, python segfaulted during install
<balloons> jibel, on ubuntu
<balloons> I got it to install using a patch
<balloons> knome, I do use vbox :-)
<balloons> this was just to get the vmware easy install testcase covered
<knome> :)=
<balloons> I'd never done it, so ..
<knome> i used to use vmware, but it was a bit too much hassle, and non-open
<balloons> wow.. I can't change the vm settings with player
<balloons> this is weird
 * skaet back
<skaet> thanks jibel.
<knome> welcome
<balloons> ohh biy
<balloons> I crashed ubiquity..
<skaet> balloons,  details please.   That sort of message does tend to get my attention during the ramp up to a release....
<balloons> skaet, heh.. yea.. I shall try and re-create
<balloons> manual install on i386
<balloons> I was just doing it to test rescue mode on i386
<balloons> rescue i386 doesn't like 64bit os's :-)
 * skaet nods
<balloons> same error
<jibel> balloons, can you be more specific ?
<balloons> jibel, yes.. I'm going to try real hardware first.. sorry I don't want to excite anyone just yet :-)
<balloons> skaet, everything is fine :-)
 * skaet steps down the alert level... ;)
<SpamapS> its fine to let unseeded stuff into precise-updates right now, correct?
<stgraber> unseeded is fine, yes
<skaet> SmapapS,  yes, as long as unseeded
<skaet> :)
#ubuntu-release 2012-08-22
<stgraber> ScottK, Riddell: someone reported bug 1039828 for kubuntu upgrades, I noticed something similar while working on another bug for mythbuntu, so if you want to fix it for 12.04.1, I'd be happy to grant an exception for that one
<ubot2`> Launchpad bug 1039828 in fontconfig "package fontconfig-config 2.8.0-3ubuntu9 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/1039828
<stgraber> I believe just uploading a fix to -proposed and getting it copied to -updates before we set the upgrade flag on Thursday should be enough
<stgraber> we probably don't want or even need to respin anything for it
<stgraber> it looks like it may be linked to slangasek's change to get rid of defoma that's only calling rmdir while the directory may still contain something
<stgraber> the rmdir can either be passed to || true or the call changed to an rm -Rf, I haven't spent enough time to figure out which of these two options would be the "right" one for this case
<slangasek> is that code mine?
<stgraber> let me check the diff
<slangasek> if so, please take away my license
<slangasek> as I've clearly been committing under the influence
<stgraber> slangasek: yes, it's in https://launchpadlibrarian.net/102433012/fontconfig_2.8.0-3ubuntu8_2.8.0-3ubuntu9.diff.gz
<stgraber> slangasek: 'rmdir $DEFOMA' where $DEFOMA in kubuntu and mythubuntu's case is non-empty
<stgraber> though according to the changelog, it's a cherry-pick from Debian
<slangasek>   Cherry pick from Debian experimental: Remove defoma support.
<slangasek> right, not my code ;)
<slangasek> stgraber: please use rmdir --ignore-fail-on-non-empty
<stgraber> ok
 * slangasek blahs at the importer failure
<stgraber> I'll push it quickly then, I know I identified this one as being the next problem once we sort out bug 1017001 and it was on my try-to-fix-for-12.04.1-updates list (though it suddenly got a lot more important as kubuntu shows the same problem)
<ubot2`> Launchpad bug 1017001 in apt "package resolvconf 1.63ubuntu14 failed to install/upgrade: ErrorMessage: pre-dependency problem - not installing resolvconf" [Critical,Confirmed] https://launchpad.net/bugs/1017001
 * slangasek nods
<slangasek> as far as 1017001 is concerned, maybe it would help to manually build apt from the release-upgrader-apt source package, to get the debugging info?
<stgraber> yeah, that or patch the upgrader to call apt the way we want... I'll spend some more time on that one tomorrow. I'm almost done with the testing I needed to do for 12.04.1
<stgraber> uploaded fontconfig to precise-proposed. Will check if quantal is also affected
<slangasek> quantal will also be affected, yes
<slangasek> (though with reduced frequency, I expect)
<stgraber> slangasek: uploaded to quantal and updated bug description for SRU. Can you review and let it into -proposed?
<slangasek> stgraber: yes.  Are you planning to have this in on CDs, or just as an immediately-available upgrade?
<stgraber> so far I've seen no evidence of this bug on Ubuntu when using the 12.04.1 media as an upgrade source, so Kubuntu and Mythbuntu may want to respin as it's definitely the case for these but I don't think we'll want to respin Ubuntu alternate for it
<slangasek> stgraber: OOI, when you hit the bug, what was left in the directory?
<stgraber> I can't recall the name of the file, but I remember it wasn't owned by a package
<slangasek> ok
<stgraber> slangasek: id-cache
<slangasek> lovely
<stgraber> it seems to be a pretty long plain text file containing font names, paths and some font related details
<stgraber> and not in an xml-like kind of syntax like fonts.conf
<stgraber> proper xml actually (for fonts.conf), missed the two first lines for some reason
<stgraber> skaet: ^ added to opportunity targets, if we think people with that package (quite a few lucid users apparently) doing LTS-to-LTS upgrades without internet connectivity is an important enough user base to warrant a respin to include the fix, the affected images would be ubuntu alternate, xubuntu alternate and kubuntu alternate
<stgraber> although most of the other images do include that package, they can't be used as update source so won't show the problem
<slangasek> stgraber: oh.  Looking at the error in the bug report description... are we sure this isn't caused by defoma-app failing to compile, and as a result the 'purge' command not running?  Maybe we should be worried about fixing that instead
<slangasek> stgraber: ah, nevermind; bug #990555 shows a case where defoma-app succeeds and the directory is still non-empty.
<ubot2`> Launchpad bug 990555 in fontconfig "package fontconfig-config 2.8.0-3ubuntu9 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1" [Undecided,Confirmed] https://launchpad.net/bugs/990555
<babyface> anybody know why still no new desktop isos for today?
<cjwatson> Have you checked the logs?
<cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/quantal/ubuntu/20120822/livecd-20120822-i386.out
<cjwatson> Same bug as you just brought up in -installer.  xserver-xorg-video-modesettings needs to be moved to main, which may or may not be blocked on an MIR (I haven't been keeping track).
<cjwatson> tjaalton: ^-
<cjwatson> Ah, I see conversation about that at ~18:11 UTC yesterday
<tjaalton> yeah no MIR, don't think it would need one?
<tjaalton> it's the defacto fallback driver if there is a kms driver already initialized
<cjwatson> doko: Hello European MIR person who isn't on holiday.  ^- Do you think I'm OK to promote xserver-xorg-video-modesetting without an MIR?
<cjwatson> The lack of it in main breaks the world :-(
<doko> looking
<babyface> cjwatson, so the build will be kicked out after the bug is fixed?
<tjaalton> a rare beast that it's actually maintained upstream :)
<cjwatson> babyface: Not automatically
<cjwatson> I mean it would automatically happen tomorrow.  We'd probably run a manual build in this case
<tjaalton> meant for hw that have a simple kms driver in the kernel, and don't need any fancy stuff from the ddx
<babyface> cjwatson, ok, I see.  thanks.
<doko> cjwatson, yes, looks ok
<tjaalton> doko: thanks
<cjwatson> doko: OK, thanks - moved to main
<tjaalton> \o/
<ogra_> erm
 * ogra_ just looks at the nusakan crontab ... when were all the preinstalled daily arm builds re-enabled ? 
<ogra_> they should be gone
 * ogra_ checks if the bzr crontab matches the actual one
<cjwatson> If they were meant to be gone, nobody ever committed that to bzr
<ogra_> months ago !
<cjwatson> revision number?
<ogra_> ah, 1459 re-enabled it
<ogra_> and 1439
<ogra_> " generally stop building preinstalled images from quantal on (only ac100 ones will stay that way) and switch kubuntu to live arm images as well"
<cjwatson> it would have been less confusing if that had removed the lines from the crontab as well
<cjwatson> (and 1459 would presumably have had to put them back, but still)
<ogra_> hmm, i'm sure i removed them
<ogra_> might have been during a milestone while the crontab was manually edited and i didnt commit it
<ogra_> or some such
<ogra_> in any case unless we want to roll daily precise arm iamges they should be dropped
<cjwatson> that shouldn't be a problem unless you're editing in place on nusakan, which you mustn't :)
<ogra_> (to free up livefs builder time)
<cjwatson> feel free to amend, anyhoe
<cjwatson> *anyhow
<ogra_> yep
<xnox> During a package built buildd got "Segmentation fault"
<xnox> Can it be investigated or retried?
<xnox> https://launchpad.net/ubuntu/+source/sphinx/1.1.3+dfsg-4ubuntu3
<seb128> xnox, retried, sure
<xnox> not reproducible locally in up-to-date sbuilds (i386,amd64) on amd64 host
<seb128> done
<xnox> seb128: ok thanks. Hope it's not gonna seg fault again =)
<seb128> xnox, I don't think you can get debug infos, out of getting lamont or a buildd admin to manual run the build with a gdb for you
<xnox> seb128: ok.
<mitya57> xnox: successfully built on roseapple :)
<mitya57> seb128: thanks
<cjwatson> slangasek: ^- if you'd care to look that over, that'll make it easier to prepare an efilinux-signed package
<lamont> seb128: I can pull syslog data, which sometimes has tombstones, but otherwise it's just a pain.  I see that the build in question succeeded
<seb128> lamont, it did
<seb128> lamont, but anyway it was xnox's asking, not me, I'm fine with the retry working ;-)
<lamont> yeah
<cjwatson> Come back livecd-rootfs, all is forgiven
<cjwatson> I've just uploaded a giant live-build merge with a huge stack of consequential changes to livecd-rootfs and ubuntu-defaults-builder, because live-build is allergic to providing stable interfaces
<cjwatson> I hope I got it all right, but if you notice any live image building weirdness, please let me know
<stgraber> slangasek: right, in my case I didn't get the compile errors, just the defoma crash
<stgraber> (rmdir failure in the defoma cleanup code of fontconfig-config)
<skaet> stgraber, re: https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/1039828,   if we can get someone to validate it (and the teams affected can retest), would like to get it included in the alternates, since LTS to LTS will be common case.
<ubot2`> Ubuntu bug 1039828 in fontconfig "package fontconfig-config 2.8.0-3ubuntu9 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1" [High,Fix committed]
<skaet> stgraber,  can we get the reporter to retest or find someone else to validate?
<jibel> skaet, I've a very poor connection to the world today and missed the context. What do you need to validate ?
<skaet> jibel,  if you could validate https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/1039828,  it would be appreciated.  its in -proposed
<ubot2`> Ubuntu bug 1039828 in fontconfig "package fontconfig-config 2.8.0-3ubuntu9 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1" [High,Fix committed]
<jibel> skaet, ok I can do it
<skaet> Thanks jibel.  :)
<jibel> yw :)
<stgraber> skaet: I'll do it
<stgraber> or rather, already in the middle of testing it ;)
<skaet> stgraber,  thanks!  :)   I'd like to respin the alternates for ubuntu,  and any flavor that wants their alternates respun, as soon as we know its safe, so we can get the testing done.
<jibel_> skaet, upgrade running
<skaet> thanks jibel_
<skaet> Riddell, ScottK - do you want Kubuntu's alternate's respun to pick up this fix ^
<Riddell> hmm
<stgraber> skaet,Riddell: to be clear, that bug will only show up on machines that have fontconfig-config + have an extra file in /var/lib/defoma/fontconfig.d/ and run an lts-to-lts upgrade WITHOUT internet connectivity
<Riddell> yeah was about to ask that
<stgraber> though, apparently at least mythbuntu and kubuntu 10.04 have an extra file in /var/lib/defoma/fontconfig.d/, so anyone using the media to upgrade without internet connectivity will hit that bug
<Riddell> my feeling is that's not many people
<Riddell> on the other hand I don't mind doing a bit more testing
<stgraber> skaet: fix confirmed
<Riddell> skaet: yes go for it, wouldn't want us to have a bug that others don't :)
<skaet> stgraber,  ok,  will wait for jibel_'s results and then get it copied over, and trigger the respin.
 * skaet notes that mythbuntu hasn't had any testing yet, so adding it to the respin target too.
<stgraber> skaet: there's nothing to respin for mythbuntu, they don't have an alternate image
<skaet> stgraber,  yes, but thought they were affected by this bug.
<skaet> ?
<stgraber> skaet: yeah, they're affected by the bug but they won't need a respin
<stgraber> skaet: once the fix lands in -updates they'll be good
<skaet> stgraber, ok.  thanks.
<slangasek> cjwatson: accepted
<jibel> skaet, stgraber upgrade is ok with fontconfig 2.8.0-3ubuntu9.1
<skaet> thanks jibel
<skaet> :)
<stgraber> ok, so we need it copied to updates
<stgraber> can someone from the SRU team copy fontconfig from -proposed to -updates please?
<cjwatson> Uh, can we get it built on powerpc first please
<cjwatson> Otherwise it'll be hard to fix later
<stgraber> oops, I missed that...
<stgraber> should have rescored yesterday after it got accepted...
<stgraber> rescored now
<stgraber> not that it really made any difference...
<cjwatson> I think it's next in the queue
<stgraber> yeah, once libreoffice and gtk are done building ;)
<skaet> gtk just started, libreoffice has been at it for 11 hours
<skaet> so,  maybe see if we can kill gtk, and get this built?
<stgraber> based on history, libreoffice should be done in 9 hours
<skaet> ie.  gtk's on ross
<stgraber> gtk typically takes a bit over an hour to build
<cjwatson> gtk+3.0 just failed to build
<cjwatson> So it's moot
<cjwatson> fontconfig is building now
<stgraber> yay for that FTBFS!
<skaet> :)
<skaet> yup seeing it on ross now too.
<cjwatson> lamont: powerpc chroots could do with a refresh
<cjwatson> lamont: https://launchpadlibrarian.net/113221890/buildlog_ubuntu-quantal-powerpc.gtk%2B3.0_3.5.12-0ubuntu3_FAILEDTOBUILD.txt.gz is a decent enough chunk of upgrades, and powerpc is backlogged
<seb128> do we need all archs to be built to do a quantal-proposed to quantal copy?
<seb128> speaking of gtk, the proposed version fixes an annoying segfault and I would like to see the fix reaching quantal without being blocked on powerpc to catch up
<Laney> yes
<Laney> oh, it failed to build already
<Laney> so it could be retried in the release pocket?
<Laney> once the world has caught up
<infinity> cjwatson: I'll refresh the chroots in a bit, I was waiting for gcc-4.7 to be in sync across arches, but with the DC move, that's been a lost cause.
<infinity> lamont: ^-- Don't worry about the chroots, I've got it.
<cjwatson> Laney: are you certain (e.g. from experience) that that's possible?
<cjwatson> I haven't got my head around the relevant bits of the copy code enough to be certain of that
<seb128> can I try? ;-)
<Laney> no, I'm guessing
<cjwatson> seb128: If you get it wrong then you need to reupload to get the world back in sync again
<cjwatson> I really can't say I recommend it
<seb128> I'm fine with that but I don't know if others are
<infinity> seb128: I'd rather we just unsnagged PPC and got GTK built in proposed.
<seb128> I don't want to random segfault GTK users in quantal for another day because ppc is not able to keep up
<cjwatson> powerpc's trouble has mostly been because it kept having very long builds aborted due to a Launchpad bug
<infinity> seb128: Yada yada, when it's automated, blah blah, won't let you do things with outdates/ftbfs, etc.
<cjwatson> It'd be more or less caught up if not for that
<infinity> It would have caught up on Saturday if it weren't for that.
<seb128> cjwatson, does gtk qualify for running in that launchpad bug? and is the bug fixed?
<seb128> like is gtk likely going to make it today?
<seb128> infinity, yeah, that day I might just reupload gtk with ppc dropped from the supported archs in the control :p
<infinity> seb128: I'll try to babysit gtk to completion today.
<infinity> seb128: Also, uhm.  No?
<cjwatson> seb128: The bug in question has been worked around procedurally
<seb128> it's ridiculous to keep a buggy gtk for i386 amd64 and armel users blocked on ppc
<cjwatson> As in we've told IS not to reload the firewall without stopping buildd-manager
<seb128> ok
<infinity> cjwatson: Which may or may not end up well-communicated, but I'm hoping.
<seb128> infinity, but I guess at this point I should join others to advocate we stop supporting ppc
<cjwatson> So I would be fairly surprised if gtk didn't make it today
<seb128> that's a discussion for another time though
<seb128> cjwatson, infinity: thanks
<cjwatson> Gosh, it's not as if we have a partner actively trying to support ppc ...
<Laney> https://launchpad.net/ubuntu/+source/fontconfig/2.10.1-0ubuntu3/+build/3735651 score this bad boy up
<cjwatson> But I guess Canonical hates its partners or something
<cjwatson> Laney: done
<Laney> should be it from what I can see
<infinity> seb128: We're buying more PPC hardware (plus, this entire backlog was DC move and LP bug, not the arch itself), so if we could keep the sky is falling hyperbole to a minimum.
<seb128> cjwatson, well, it's a tradeoff and it depends of who we target I think, but if having to support ppc reduces our velocity to get desktop fixes out on main desktop arches it has a cost
<cjwatson> seb128: if this kind of thing annoys you, I recommend you help out with ensuring that Launchpad can handle arch desync
<cjwatson> Rather than just complaining about it
<infinity> seb128: You could have made the same arguments about armel/armhf a few hours ago before they mostly caught up.
<cjwatson> That's much better than hating on $slow_arch_du_jour
<seb128> powerpc is a recurrent problem and it's desktop's userbase is really limited, but yeah there is not only desktop in life I know ;-)
<cjwatson> Laney: agreed
<cjwatson> arm is a recurrent problem in this way too
<seb128> infinity, well, I see the point of support arm desktops and that's something we have active interest in
<cjwatson> we just pretend it isn't
<seb128> it is a problem, but I can see the interest in it
<cjwatson> so the right fix is to make the toolset handle it better
<cjwatson> in an architecture-generic way
<seb128> that's even better yes
<infinity> seb128: Anyhow, if speed is the biggest concern, it's being handled.
<infinity> seb128: PPC should be the fastest arch in the buildd pool again soon (like it was when we first started, so long ago).
<seb128> infinity, blocking important fixes to reach users in a timelined fashion is the issue there
<cjwatson> Let's drop amd64 once it's blocking powerpc fixes
<seb128> so if it's solved, whatever way it's solved I'm happy
<infinity> cjwatson: Sold.
<seb128> lol
<seb128> point taken, sorry for the perceived-non-contructive discussion ... and no, the issue is not only lag, it's the number-of-users-pondered-with-cost which is
<infinity> seb128: Anyhow, I'll poke at scoring and unsnagging the gtk build-dep failure so it builds soonish.
<seb128> but anyway, let's move on
<seb128> infinity, thanks
<Laney> fontconfig is built
<skaet> SpamapS,  would you help with the copy over?
<skaet> (of fontconfig-config from -proposed to -updates)
<stgraber> it's not published in -proposed yet
<infinity> I beg to differ.
<infinity> Did you need it released?
<cjwatson> rmadison agrees with stgraber ...
<lamont> infinity: ta
 * cjwatson checks LP
<stgraber> IIRC copyPackages doesn't like copying non-published binaries
<stgraber> libfontconfig1 | 2.8.0-3ubuntu9.1 | precise-proposed | amd64, armel, armhf, i386
<infinity> rmadison lies. :P
<stgraber> ^ no powerpc there
<cjwatson> Ah, yes, published in LP
<cjwatson> It's fine to copy
<cjwatson> We don't need it on the mirrors to make copying sane
<stgraber> ah right, that's a case where the published state on LP is actually what we want ;)
<infinity> (copied)
<stgraber> skaet: I'll start the respin once it's published in -updates
<skaet> thanks stgraber
<stgraber> skaet: so we have kubuntu and ubuntu that want it, do you know if xubuntu wants it too?
<skaet> stgraber,  no haven't heard back on that one.
<stgraber> knome: ^
<skaet> astraljava, ^ ?  do you awnt a respin of the alternates?
<skaet> want even
<skaet> stgraber,  looks like bug 1036994 still isn't quite resolved.  probably needs to be reopened?
<ubot2`> Launchpad bug 1036994 in ubuntu-defaults-zh-cn "[zh_CN] Language packages not installed completely" [Medium,Fix released] https://launchpad.net/bugs/1036994
<stgraber> skaet: I'll do another test run here, for some reason (past experience?) I don't really trust the test results for the chinese builds
<slangasek> cjwatson: efilinux accepted btw, if you hadn't already seen
<skaet> stgraber, ok.   will forward you the rest of the results I've gotten.
<balloons> skaet, I don't see the respin for fontconfgig in the pad?
<skaet> balloons,  updated it now to move to right column header on the pad.   its bug 1039828
<ubot2`> Launchpad bug 1039828 in fontconfig "package fontconfig-config 2.8.0-3ubuntu9 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1" [High,Fix released] https://launchpad.net/bugs/1039828
<balloons> skaet, ty :-)
<balloons> you plan to pull the opportunity targets?
<stgraber> skaet: for bug 1036994, I can indeed confirm that these now show up though they definitely didn't when I last tried (only thunderbird-locale-zh-cn did back then)
<ubot2`> Launchpad bug 1036994 in ubuntu-defaults-zh-cn "[zh_CN] Language packages not installed completely" [Medium,Fix released] https://launchpad.net/bugs/1036994
<stgraber> skaet: adding these would require an extra 40MB or so of CD space which we don't have
<stgraber> so the best hope is to figure out why they're suddenly being needed
<skaet> stgraber,  ok,  will start the thread off by email with the testers and folks pushing for it, and see if we can figure a path forward.
<stgraber> skaet: that's the 12.04 => 12.04.1 delta for the chinese image: http://paste.ubuntu.com/1161119/
<stgraber> reverting the package additions still gives me the same missing package list, so I'm starting to doubt that the 12.04 image was really any better than what we have currently
<SpamapS> skaet: can I assume from the backscroll that fontconfig was taken care of?
<stgraber> going for lunch now, will try a local respin of the image with the needed packages to see if squashfs does magic and makes 40MB worth of compressed debs fit into the 20MB or so of free space we have
<stgraber> SpamapS: yep
<skaet> SpamapS,  what stgraber said.  :)
<skaet> enjoy lunch stgraber
<jibel> skaet, stgraber what's ETA for new alternates ?
<stgraber> jibel: 30min
<jibel> stgraber, ok, back in 90min
<stgraber> skaet: adding the packages would make the squashfs grow by 41.3MB
<slangasek> stgraber: bug #1036994> perhaps language-selector is returning partial results for different kinds of missing packages, and only after we got thunderbird-locale-zh-cn added does the next batch show up?
<ubot2`> Launchpad bug 1036994 in ubuntu-defaults-zh-cn "[zh_CN] Language packages not installed completely" [Medium,Fix released] https://launchpad.net/bugs/1036994
<slangasek> stgraber: as for not having room, I'm not sure - are we committed to fitting the zh_CN image on a CD?
<slangasek> (that's a question we should ask the folks who own the image)
<stgraber> slangasek: could be... I can't reproduce that behaviour with check-language-support but maybe the UI behaves differently
<slangasek> right
<stgraber> slangasek: Kate started a discussion on whether to move past the 703MB limit as I don't see any other way to get these packages in and still get it fit on the media
<slangasek> in any case, I see those packages listed in the language-selector data, and l-s hasn't changed, so it seems the bug is that they weren't shown before when they should have been
<slangasek> stgraber: ah, perfect
<slangasek> pff, 12.04.1 images need to happen so bug #853060 can get knocked off the top crashers report
<ubot2`> Launchpad bug 853060 in ubuntuone-installer/trunk "ubuntuone-installer crashed with GError in function(): Failed to execute child process "ubuntuone-control-panel-gtk" (No such file or directory)" [Critical,Fix released] https://launchpad.net/bugs/853060
 * slangasek hmms at lillypilly.  Busy machine.
<infinity> slangasek: Yeah, we kinda hammer it.  It might be high time to ask for an ubuntu-archive.canonical.com (or something) that we can redirect people/~ubuntu-archive to and run our scripts in peace.
<slangasek> infinity: not sure it's our hammering that's at issue here; there's a lot of other stuff running too
<ogra_> it isnt by chance also cating as central IRC node ? :)
<ogra_> *acting
<slangasek> zul: hi, what's 'accepted-nominations.py'?  Seems to be wedging a bit on lillypilly
<bjf> ogra_: *many* teams run cron jobs on it that beat on LP
<infinity> slangasek: No, our hammering isn't the only hammering, but moving ours off would give others breathing room, and would make some sense, since the archive-related stuff probably shouldn't be on people anyway.
<zul> is the server team sru tracking stuff
<bjf> infinity: last i asked i was told there was a plan to improve that situation, that was a while ago
<slangasek> zul: you have instances of it running since Aug 19 without completion
<slangasek> zul: and using quite a lot of CPU time
<zul> *sigh* no i wasnt...ill kill il
<skaet> stgraber, based on the discussion with smagoun in email, he'd prefer it to go out oversized, and just document it as USB/DVD image.   thoughts?
<ogra_> bjf, sorry i was trying to be funny and referring to that massive netsplit that occured when slangasek asked first :)
<zul> slangasek: done...cron jobs have been disabled as well
<slangasek> zul: ok, cheers :)
<jibel> latest alternate seems to be broken. kernel version mismatch
<slangasek> zul: I guess http://reports.qa.ubuntu.com/reports/ubuntu-server/sru-report.html is the authoritative location for this now, anyway?
<zul> slangasek: i think so
<jibel> and upgrade from CD failed
<slangasek> zul: ok, cool
<jibel> skaet, stgraber ^
<zul> slangasek: you'll have to check with jamespage though since he is using that report
<slangasek> jamespage: hi, can you confirm that you use http://reports.qa.ubuntu.com/reports/ubuntu-server/sru-report.html these days and not http://people.canonical.com/~chucks/SRUTracker/ ?  the latter was running amok on lillypilly, so has now been disabled
<zul> but i didnt mention hes on vacation this week
<slangasek> zul: ok, then he'll have scrollback :)
<stgraber> skaet: hmm, ok... I don't really care about that image, so if they want it to become a DVD/USB image, I'm fine with it, I can push a new ubuntu-defaults-zh-cn to include the missing packages
<stgraber> jibel: hmm, weird... let me do a few diffs quickly
<stgraber> skaet, jibel: hmm, looks like we lost the previous alternate build...
<skaet> urk... why?
<slangasek> cleanup limit not removed for mastering?
<stgraber> my guess is the cleanup script
<jibel> stgraber, what do you need, I have 20120817.2 but not .3
<slangasek> etc/purge-days doesn't look like it's been changed
<stgraber> jibel: I have them locally, it's just that we don't have a fallback now... so we need it fixed for sure
<balloons> ok, the alt images look to be up again.. i'm zsync'd
<stgraber> infinity, slangasek: so, a diff shows that we're missing linux-image on the media, any idea what happened? (going to go grab the logs now)
<slangasek> stgraber: which media, exactly?
<infinity> stgraber: What he said.
<slangasek> oh, n/m
<slangasek> looking at precise/daily/20120822.2/precise-alternate-i386.list now
<slangasek> sure enough, metapackages are there but not the kernel images
<slangasek> infinity: ^^
<infinity> It's not building from -proposed, is it?
<knome> skaet, ok for me to respin alt
<slangasek> that's supposed to have been disabled (rev 1484)
<skaet> knome,  ok.
<slangasek> ah, that's only the cronjob anyway
<njin> kirkland, are you a devel of testdrive ?
<slangasek> stgraber: it does look like precise-proposed is mentioned in the build log.  How was this kicked off?
<jibel> balloons, skaet I disabled alternate for Ubuntu and Kubuntu on the tracker
<stgraber> knome: ok, adding you to the list once we've figured out what's going on
<balloons> ty jibel
<skaet> thanks jibel
<stgraber> slangasek: DIST=precise for-project ubuntu cron.daily
<infinity> stgraber: Something's definitely using proposed, cause it's picking up a kernel that's only in proposed...
<infinity> stgraber: Then, of course, that goes splat when it doesn't match either d-i or the seeds.
<knome> stgraber, ta
<balloons> skaet, jibel did we pull/we will pull all the opportunity target's on the pad?
<skaet> balloons,  no not necessarily in the images
<balloons> k
<skaet> they will all be available in the 0 day SRU updates though.
<balloons> so my update to the noticeboard should be correct :-)\
<infinity> stgraber: You don't have PROPOSED=1 in your environment or something?
<infinity> (Or whoever did the build...)
<stgraber> infinity: hmm, proposed is definitely disabled in CONF.sh... and I can't spot anything that changed since Monday...
<stgraber> infinity: nope, already checked ;)
<slangasek> stgraber: are you sure this was your build? :)
<slangasek> maybe check whether it's reproducible?
<stgraber> kicking a new one to check...
<stgraber> running (from a clean shell, just in case...)
<slangasek> stgraber: see bin/run-germinate (and history thereof)
<slangasek> it's not that you weren't pulling from proposed before and are now; it's that we've been consistently pulling from proposed for germinate, and this is the first time since we stopped /building/ from proposed that this gives a different result vs. -updates
<infinity> Oh, d'oh.
<infinity> That needs a PROPOSED guard instead of a DIST= guard, and you should be set.
<stgraber> fixing...
<infinity> Well, assuming PROPOSED actually gets exported higher up.
<infinity> If not, that would end up being a no-op and fail with 12.04.2
<stgraber> code updated, waiting for the current build to finish (and produce an equally buggy image), then will respin ubuntu, kubuntu and xubuntu with the fix
<infinity> Yeah, that probably won't work for 12.04.2, I bet.  I suspect PROPOSED doesn't exist in that part of the twisty shell stack at all.
<infinity> But that could be fixed.
<infinity> In fact, if it was fixed, we could ditch the need to edit CONF.sh too.
<infinity> But, I'd rather not experiment right now, just get your fixed images out, and we can play after 12.04.1 ships. :P
 * skaet nods
<stgraber> yeah, I think it'd make sense to always use PROPOSED=1 and skip CONF.sh completely but that can be done for .2, and once that's done, my change to run-germinate should magically work
<infinity> stgraber: Well, it'll magically work if higher-level scripts (build-image-set, or similar) export PROPOSED.
<infinity> stgraber: Which would fix your run-germinate fix, and would also allow CONF.sh to not have to do the same.
<infinity> Anyhow, as much as it all makes sense in my head, I won't touch it while you're trying to release something. :P
<stgraber> skaet: I'll upload a new ubuntu-defaults-zh-cn now with the missing packages, that'll need to get into -proposed, be tested, then moved to -updates before we can respin the chinese images
<skaet> stgraber,  thanks.
<stgraber>   * depends.txt: Dropping ttf-wqy-zenhei was just a tad too little to fix
<stgraber>     oversizedness. Put it back and drop ibus-sunpinyin instead, so that ibus
<stgraber>     will use ibus-pinyin with db-android, as in a normal install. Zhengpeng
<stgraber>     Hou says most people use the googlepinyin module anyway.
<stgraber> skaet: ^ that's from the ubuntu-defaults-zh-cn changelog, so apparently dropping ibus-sunpinyin was done on purpose by Martin to fight oversizedness
<infinity> stgraber: If the PROPOSED checks are actually that convoluted [ "${PROPOSED:-0}" != "0" ] construct everywhere too (which we can check with a fine-toothed grep), then we can stop with the somewhat error-prone adding and removing of PROPOSED in cronjobs, and just have stable releases have PROPOSED=0 in crontab, and flip to 1 when needed.  Much less change for human oopsification, I suspect.
<infinity> s/change/chance/
<stgraber> infinity: only place that's not using that kind of check (using [ "$PROPOSED" = "1" ] instead) is debian-cd/Makefile, the rest looks pretty consistent
<infinity> stgraber: Well, PROPOSED=1 would also match my plan above.
<infinity> stgraber: It's only things that check for it being set/empty that would break.
<stgraber> infinity: my grep against the cdimage, cdimage-deployment and debian-cd branches suggest that we never do [ -n "$PROPOSED" ], so your plan should be fine
<stgraber> skaet: uploaded ubuntu-defaults-zh-cn to -proposed
<stgraber> ok, rebuilding all alternates now
 * stgraber -> upgrading memory in laptop, be back in 10min (hopefully)
 * skaet hopes so too...
 * stgraber is back with 16GB of RAM!
<stgraber> slangasek: so in case you were wondering, contrary to what Lenovo and the DMI pretends, an x201 (x201s in my case) seems perfectly happy with 16GB of RAM (instead of the documented maximum of 8GB)
<skaet> :)
<stgraber> jibel: can you test that new batch?
<stgraber> we seem to have a kernel this time around
<slangasek> stgraber: noted ;)
<skaet> :)
<slangasek> I have my hands full at the moment upgrading my work area to use digital video only
<slangasek> just bought an x200 ultrabase, to discover that it's DP instead of the HDMI I expected... now I have an adapter on order :P
<stgraber> haha, yeah, I have the ultrabase and the DP => DVI adapter, though I'll be ordering a new laptop (x230) this week and so I'll need yet another adapter as that one is coming with mini-DP (though directly on the laptop instead of requiring the docking station which is a nice improvement)...
<stgraber> SpamapS, slangasek, infinity: can one of you review ubuntu-defaults-zh-cn in Unapproved?
<infinity> stgraber: I'll poke it.
 * SpamapS was too slow
<infinity> stgraber: And we're sure everyone's cool with it being oversized?
 * infinity assumes so from scrollback.
<infinity> stgraber: Did you want to do any testing on that once its built, or just want to wing it straight to updates?
<infinity> stgraber: (If I time it just right, I can skip a publisher cycle... Sometimes)
<skaet> infinity,  yes, we're ok with the chinese image being oversized.   Prefered option from OEM.
<stgraber> infinity: only check that should be done is ensuring the extra 4 binaries found their way into the Depends field
<infinity> stgraber: https://launchpad.net/ubuntu/+source/ubuntu-defaults-zh-cn/0.8.4/+build/3737400/+files/ubuntu-defaults-zh-cn_0.8.4_all.deb
<infinity> stgraber: Go forth and dpkg-deb -I
<stgraber> infinity: looks good
<infinity> stgraber: Oh, nevermind, can't cheat the publisher, that trick only works if the source was already published.
<infinity> stgraber: (since, for curious reasons, binaries get published during the short "security-only" run, so there's a window where one can then pocket-copy the whole mess before the full run happens)
<infinity> stgraber: Anyhow, copied now, will make it in the next run. :/
<balloons> ok -- we feeling good on these now :-)
<slangasek> stgraber: if ibus-sunpinyin was removed deliberately, why are you re-adding it, rather than fixing language-support?
<stgraber> slangasek: well, it was removed deliberately to save space but it's apparently still something most users want and that's what all 12.04 users with connectivity have, so just adding it back to the media (after checking that they're fine with it being oversized) seemed like the less risky change at this point
<slangasek> stgraber: where do you see that it's something most users want?
<slangasek> pitti's changelog said the opposite
<stgraber> slangasek: my understanding of that comment is that in an ideal world we'd use ibus-googlepinyin, which we can't as it's not in main. That's also why language-selector still installs ibus-sunpinyin in 12.04 instead of googlepinyin (on quantal)
 * slangasek rereads
<slangasek> stgraber: well, "we can't use it because it's not in main" doesn't make sense; if it's the right one to use, it can be moved to main (I see it's still in universe in quantal)
<slangasek> "ibus-pinyin with db-android, as in a normal install" - what's a "normal install" in this case?
<stgraber> slangasek: oh, I assumed that change in quantal based on the "# replace with ibus-googlepinyin in 12.10" next to it in depends.txt... guess nobody did that change yet
<balloons> any status on this bug? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1040002
<ubot2`> Ubuntu bug 1040002 in linux "lucid upgrade to precise amd64 universe failed: E:Error, pkgProblemResolver::Resolve generated breaks" [Medium,Incomplete]
<slangasek> ah, "a normal install" == that's the method ubuntu-desktop depends on
<slangasek> seems like we ought to list alternatives there, so that the Qin CDs don't have to have *both* included
<stgraber> slangasek: I only have a very limited understanding of the chinese input methods, so we really should talk to someone who has a clue what kind of change we're talking about. I really doubt we should be changing input method in a point release.
<njin> hallo, I've installed Lucid to test the upgrade to precise, but U M won't propose the upgrade, is this expected ?
<njin> iis the upgrade locked ?
<slangasek> stgraber: I agree we shouldn't change it, I just didn't understand that's what pitti's changelog meant the first time around
<slangasek> njin: this is expected, until after 12.04.1 releases and we turn on upgrades for LTS users
<njin> ok slangasek, usefull
<stgraber> slangasek: I'm really wondering how many users will be getting a well working upgrade path to 10.04.4, looking at bug 1040002 ...
<ubot2`> Launchpad bug 1040002 in update-manager "lucid upgrade to precise amd64 universe failed: E:Error, pkgProblemResolver::Resolve generated breaks" [Medium,Incomplete] https://launchpad.net/bugs/1040002
<slangasek> balloons: bug #1040002> nothing should have changed in precise-updates in the past 24 hours to cause this.  Are you sure this isn't some jenkins breakage?
<stgraber> that one seems to have quite a lot of extra packages installed (wine, opencv, ... looking just at the end of apt.log)
<slangasek> stgraber: it's the lucid universe upgrade test, so of course it has extra packages installed?
<stgraber> isn't it the universe upgrade test that uses a random subset of universe?
<slangasek> not random
<jibel> universe includes the maximum number of packages from all the repositories with a desktop file until dpkg explodes
<stgraber> right, I just refreshed my memory by reading install_universe again :)
<stgraber> jibel: do you have a way of checking whether the list changed between the last succesful upgrade and the first failed one?
<jibel> stgraber, the list of packages installed ?
<stgraber> jibel: yep
<jibel> stgraber, the source list doesn't change
<slangasek> the apt-clone_system_state?
<stgraber> ah, indeed, apt-clone_system_state should contain that
<slangasek> however, AFAICS there've been no publications of anything to precise-updates in the past 36h that would have introduced new breaks
<slangasek> stgraber: the working one shows the release-upgrader apt, the broken one does not
<slangasek> (in dpkg-status - first diff I see)
<slangasek> though maybe that's because the failure happened so early it couldn't be pulled in
<slangasek> jibel: is the lucid-universe upgrade job for today in progress?
<jibel> slangasek, it is in the queue and will start after main in approximately 4h45min
<stgraber> skaet: I'm going to turn off purge-old-images completely (to make sure we don't loose any more build), then rebuild the chinese image
<skaet> thanks stgraber - wise
<skaet> stgraber,   new image will go to : http://china-images.ubuntu.com/precise/daily-live/current - right?
<stgraber> yep
<slangasek> micahg: hi, can I ask why you marked bug #997359 as rls-q-incoming?  AFAICS this is an annoyance, but hard to fix and low-impact for users
<ubot2`> Launchpad bug 997359 in libnih "nih uses eglibc private symbol __abort_msg" [High,Confirmed] https://launchpad.net/bugs/997359
<jibel> stgraber, where are the logs for ltsp-client-builder ?
<stgraber> jibel: I believe one is directly in /var/log and the rest should be in installer/syslog
<jibel> stgraber, this is the end of syslog http://paste.ubuntu.com/1161542/
<jibel> there is a file /tmp/ltsperror.txt which is 0byte
<stgraber> jibel: oh, good, that's just quantal, was scared for a minute ;)
<stgraber> I was sort of expecting it to blow up on quantal after the big merge from Debian. I have an upload scheduled for tomorrow, will fix that in it.
<jibel> stgraber, oh phew! I scared myself
<jibel> stgraber, retrying with precise :)
<slangasek> micahg: same question on bug #769601... not sure what the impact is here
<ubot2`> Launchpad bug 769601 in gcc "libstdc++, debug mode: resizing a vector doesn't update capacity" [Medium,Fix released] https://launchpad.net/bugs/769601
<slangasek> (marked 'low', and nobody's said it's breaking any of the handful of packages that depend on g++-4.4)
<skaet> stgraber, have the chinese image rebuilds been triggered yet?
<stgraber> skaet: no
<stgraber> skaet: but they will in a minute
<skaet> :)
 * skaet was just about to ask if you wanted me to.
<stgraber> running
<skaet> thanks
<stgraber> skaet: chinese images built
<skaet> thanks stgraber
<skaet> balloons, stgraber - I updated the notice board, since alternates have built,  and have updated pad
<balloons> thanks skaet .. chasing a rescue mode bug
<skaet> utlemming,  how are the cloud images looking for testing results?
<skaet> can they get added to the tracker?
<utlemming> beautiful
 * skaet likes hearing testing is beautiful.... ;)
<skaet> or rather the tested images are beautiful.
<utlemming> all tests passed, except for two, which were caused by bzr failures
<utlemming> stgraber: can you add these to the tracker? http://cloud-images.ubuntu.com/precise/20120821/
<catbus1> skaet: I can still see the incomplete language support with the latest chinese image. I will get the list of missing packages and comment on the bug
<stgraber> utlemming: sure
<skaet> thanks catbus1,  stgraber, looks like still some ones to add.
<catbus1> skaet: stgraber: check-language-support returns nothing though, which means nothing is missing.
<skaet> catbus1 - could it be that the translations aren't complete for all the strings?  and that's what's being seen?
<cjwatson> no, missing translations won't trigger that
<cjwatson> that's a package-level check
<catbus1> skaet: ^^^
<catbus1> Assuming check-language-support does it right, it seems to me it's a false alarm, there is nothing missing. The missing language support window shouldn't appear.
<skaet> catbus1, cjwatson - ok, thanks.
<cjwatson> The odds are that it's complaining about something like missing translated help files for some application, or missing thesaurus files, or something relatively tangential like that.
<cjwatson> But I can't easily check right now.
<skaet> ok,  something wrong but not that serious.  gotcha.
<stgraber> skaet: will grab the new image to figure out what's going on
<skaet> thanks stgraber
<cjwatson> Basically check-language-support has various packages entered in a matrix of locales / categories (fonts, input methods, etc.) / (for some categories) installed applications, and will complain about packages missing from that.
<cjwatson> This was an improvement over the prior system where we had a pile of language-support-* metapackages, which never really worked right because different flavours had different applications which might need to be enhanced with support packages.
<cjwatson> So we ended up with c-l-s instead, in, er, whichever release followed the UDS in Barcelona I think
<cjwatson> (Does anyone else find that?  I think of a feature and remember what the hotel looked like where we designed it ...)
<stgraber> karmic I believe
<stgraber> yeah, I get that sometimes, then have to spend a few minutes figuring out the release based on the continent and LTS/non-LTS (won't work once we have a LTS release UDS in Europe...) ;)
<ajmitch> or breaking the cycle & having it in Australia again? :)
<cjwatson> Barcelona was memorably visually distinctive with that crazy giant 20-storey atrium or whatever it was in the sleeping accommodation
<stgraber> skaet, cjwatson, catbus1: based on check-language-support, it's prompting because of lack of english support packages
<skaet> lol
<stgraber> specifically: hunspell-en-ca hyphen-en-us libreoffice-help-en-gb libreoffice-help-en-us libreoffice-l10n-en-gb libreoffice-l10n-en-za myspell-en-au myspell-en-gb myspell-en-za mythes-en-au mythes-en-us openoffice.org-hyphenation thunderbird-locale-en thunerbird-locale-en-gn thunderbird-locale-en-us and wbritish
<skaet> sorry,  that seems quite ironic.
<skaet> given we're oversize already - does it make more sense to add,  or just to release note it?
<cjwatson> I certainly don't think it makes sense to add all those.
<stgraber> well, I certainly won't ba adding these to ubuntu-defaults-zh-cn, that just wouldn't make sense ;)
<skaet> :)
<skaet> fair 'nuf
<stgraber> cjwatson: what's the reason why we always have language-pack-en installed on all systems even non-english ones?
<stgraber> (besides making me happy as I can just LANG=en_US.UTF-8 and get the system into a locale I understand)
<stgraber> oh, actually, we now have C.UTF-8 don't we? so I don't even need them for that anymore :)
<cjwatson> It was an agreement dating back to 2004
<cjwatson> I think mdz ruled on it
<stgraber> skaet: confirmed that flushing the English langpacks from the system makes check-language-support happy again
<cjwatson> I'd have to do some archaeology to remember the reasoning
<cjwatson> en_US.UTF-8 might have been a part of it, although I'm not sure it was all
<stgraber> cjwatson: ok, might be worth re-checking, especially now that we have C.UTF-8, stuff hardcoding en_XX.UTF-8 should just be fixed
<stgraber> skaet: so I suppose they can just release note that the DVD image comes with full chinese support and partial english support and that users will be prompted to install the remaining set of english packages post-install. They can choose not to install them or even remove the base english packages if they want.
<skaet> stgraber,  I can live with that.
<Daviey> skaet: I assume arm images are all in order?
<skaet> Daviey,  haven't seen results from netboot armhf omap and omap4 yet.
<skaet> slangasek, infinity - either of you able to help with those?
<catbus1> stgraber: can you comment on the bug so it's clear on the root cause? 1036994
<slangasek> infinity: my panda is busy testing llvmpipe.  can you look at netboot?
<stgraber> catbus1: done
<stgraber> skaet: marked Edubuntu as good to go
<stgraber> even the unsupported 10.04-to-12.04 upgrade worked for it ;)
<skaet> Thanks stgraber.  :)
<skaet> slangasek,  we're also still missing some of the netboot i386 results.
<phillw> skaet: I'm running low on testing.. what do you need for netboot i386 results.?
<phillw> skaet: is a VM okay?
<skaet> phillw,  installing Xubuntu and Kubuntu needed.  http://iso.qa.ubuntu.com/qatracker/milestones/230/builds/21346/testcases
<skaet> slangasek, ^  I think it should be,  but want to cross check.
<skaet> (installing on VM)
<phillw> skaet: I've had a nightmare with 10.04.4 -- 12.04. If there is an up to date set of instructions I can run it via an VM if that is acceptable?
<skaet> phillw, good question.    jibel's offline now, and he did the other netboot test cases.
<skaet> balloons,  you still around?    any  insight?
<phillw> skaet: sorry, cancel me out... it is expected 3 hours for me to recover mt music files from the 1st area of my back up area.
<skaet> phillw,  ok.   Thanks.
<phillw> skaet: the VM on the SII server was made available, I can do more than that :(
<psivaa> skaet, i was able to do the upgrade using you still around?    any  insight?
<psivaa> <phillw> skaet: sorry, cancel me out... it is ex
<phillw> *I cannot*
<psivaa> sorry https://help.ubuntu.com/community/PreciseUpgrades
<skaet> psivaa,  not parsing what you've typed I'm afraid.
<phillw> skaet: too many tasks asked for, we simply do not have enough people to carry them all out.
<skaet> were you able to do the netboot install.
<skaet> psivaa, ^
<psivaa> skaet, sorry it was a bad copy paste. i thought phillw was asking for links with the instruction for lucid- prcise upgrade
<skaet> psivaa,  he was asking if it was ok to do the netboot tests under a VM, and if there were good instructions for doing so.
<phillw> psivaa: no, I tried the the kubuntu 10.04.04 --> 12.04 in VM just to tick the box... it was an epic fail.
<psivaa> skaet, phillw ohh sorry the instructions on the link above for hw i suppose
<phillw> psivaa: do not feel dis-heartened, the instructions were also out dated.
<phillw> psivaa: on QA, we have, IMHO, gone a bridge too far.  The lessons learned are important. I do ask that you be patient as we sort things out.
<psivaa> phillw, ok thanks :)
<psivaa> phillw, the upgrade from 10.04 --> 12.04.01 was ok on hw for me though
<phillw> psivaa: great news,
<psivaa> phillw, going to go off now, enjoy the rest :)
<skaet> good night psivaa,  and thanks. :)
 * skaet --> dinner
#ubuntu-release 2012-08-23
<infinity> slangasek: Ahh, I was ignoring IRC.  I can spin up a netboot or two.
<slangasek> infinity: ta :)
 * infinity notes that his local mirror picked an annoying day to die...
<micahg> slangasek: I marked the nih one to make sure it wasn't missed on the release team's radar, the gcc issue seems to only affect 4.4, was just wondering if this was something that might be worth fixing since apparently the same patch with fuzz applies, no inherent interest from me in either fix
<slangasek> micahg: ok - declining to commit to fixing either then :)
<micahg> slangasek: although, IMHO, the libnih one is just bad and we should fix it since it breaks with every libc upgrade
<slangasek> we've so far not come up with a good way to fix it
<Daviey> a dirty way, surely trumps no-way :)
<micahg> https://bugs.launchpad.net/libnih/+bug/997359/comments/2 doesn't sound as bad as using a private symbol
<ubot2`> Ubuntu bug 997359 in libnih "nih uses eglibc private symbol __abort_msg" [High,Confirmed]
<xnox> Daviey: reboot =)
<infinity> Using private libc symbols should definitely be addressed, IMO.
<infinity> Tis a big no-no.
<micahg> xnox: don't you remember UDS, a reboot costs a million dollars :)
<xnox> micahg: I do. But I'm not sure it's true.
<adconrad> Hrm, my co-lo machine seems to have disappeared from the planet.
<adconrad> slangasek: omap4 done, doing omap now.
<skaet> Daviey,  MAAS (Juju) and MAAS (Server) tests still haven't been marked as run yet for Ubuntu Server.    Any input?
<Daviey> skaet: roaksox is confirming that at the moment.  It's had testing (including from Robbie), but he is validating
 * infinitum goes to find food while his Beagle crunches on the OMAP image.
<skaet> slangasek, infinity, cjwatson, jdstrand - FYI: https://fossology.ist.unomaha.edu is now available.  Am thinking it might be another tool to use for the license checks.
<skaet> or rather I guess I should type infinitum... ^
<infinitum> http://www.fossology.org/projects/fossology might be a better link, instead of someone's hosted copy of it. ;)
<skaet> infinitum,  HP is working with UNO to have a server where folks can just upload packages to be scanned, rather than each having to set up a FOSSology instance.
<xnox> skaet: juju deploy.... =)
<xnox> skaet: you want to scan the whole archive?
<skaet> xnox, hmm... ;)
<xnox> skaet: i am not kidding about whole archive scan. Do you want that? =)
<skaet> xnox,  yup.
<infinitum> Oh, FFS, the d-i initrd grew 1MB too big for omap3.
<infinitum> Or even less.
<infinitum> skaet / slangasek: netboot/omap (not omap4, it's fine for now) fails with #1040393
<infinitum> skaet: Not worth a d-i respin, since omap isn't a supported arch anyway, but I'll fix it for 12.04.2 and in quantal.
<xnox> bug 1040393
<ubot2`> Launchpad bug 1040393 in debian-installer "omap netboot partition too small for flash-kernel backup procedure" [Undecided,New] https://launchpad.net/bugs/1040393
<skaet> infinitum, ok that answers that question.
<infinitum> skaet: Linked in the tracker.
<skaet> infinitum, thanks.   since its not a supported arch, not sure if it deserves a release note or not...  thoughts?
<infinitum> skaet: We'll be spinning a new d-i pretty quickly after 12.04.1 releases anyway, so I'll see about getting it fixed soonish.
<infinitum> skaet: Not worth a release note, IMO.  Please, once d-i is respun, the release notes will be wrong (There's not actually any concept of a "12.04.1 netboot image", people just use "current")
<skaet> fair 'nuf.  :)
<infinitum> Err, no can type.
<infinitum> s/Please/Plus/ makes that make way more sense. :P
<babyface> skaet,  are you around ?
<skaet> babyface, yup
<babyface> skaet, I'm testing the upgrade from lucid 2 precise : I downloaded the 2 iso, and installeded lucid first, and then insert the precise cd, but no upgrade kicked off
<babyface> skaet, anything missed?
<skaet> babyface,  after you installed lucid (assume it was 10.04.4 - yes?)  did you update?
<babyface> skaet, no
<stgraber> babyface: what precise cd did you use?
<babyface> stgraber, http://cdimage.ubuntu.com/precise/daily/20120822.4/precise-alternate-amd64.iso
<babyface> skaet, yes, it is 10.04.4  from http://cdimage.ubuntu.com/lucid/daily/current/lucid-alternate-amd64.iso
<stgraber> ok... you should have seen nautilus popup showing the content of the CD, then a few seconds later a dialog asking you if you want to open a package manager or upgrade
<babyface> stgraber, ok. I will have another try
<stgraber> I don't remember ever having any problem getting nautilus to open when inserting the media, though the upgrade dialog sometimes took a while to show up for some reason
<stgraber> eject/reinsert the alternate media might help
<babyface> stgraber, ack.
<babyface> stgraber, tried many times , can open nautilus every time  after insert the cd/usb key, but can not find the upgrade dialog, is there any way to get the upgrade dialog manually?
<skaet> babyface, https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop#Upgrading_from_Ubuntu_10.04_LTS_to_Ubuntu_12.04_LTS
<babyface> skaet, Thank you. Kate
<slangasek> infinity: good to know, thanks
<slangasek> skaet: fossology> ah, nice
<skaet> Daviey, cjwatson - can you review https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/ChangeSummary/12.04.1 for me?    Feel free to move any bugs I've got wrongly categorized.
 * skaet --> zzz
 * cjwatson starts trawling through today's live-build-induced image build failures :-(
<ogra_> cjwatson, that last omap build looks like FLASH_KERNEL_SKIP isnt set
<ogra_> err omap4
<cjwatson> Hmm, where was that done before
<cjwatson> ?
<cjwatson> The only match I can find in old/new live-build/livecd-rootfs was just for ac100
<ogra_> live-build/auto/build:	Chroot chroot "env FLASH_KERNEL_SKIP=1 update-initramfs -k all -t -u -v"
<cjwatson> That's specific to ac100, look at the context
<cjwatson> So maybe the problem is that update-initramfs is inadequately diverted
<ogra_> well, we need to run it at some point
<cjwatson> I'll get to it, it's about 20th on the list of failures in my inbox :)
<cjwatson> Working through in order
<ogra_> but never want flash-kernel to be executed
<ogra_> cjwatson, reverting http://paste.ubuntu.com/1162322/ in scripts/build/lb_chroot_hacks should fix the flash-kernel issue
<stochastic> hi I'm about to draft the release notes for Ubuntu Studio 12.04.1 and am curious if the Ubuntu release notes are around somewhere yet?
<stochastic> or will there be release notes for 12.04.1?
<cjwatson> ogra_: so, actually, that's not the error
<cjwatson> ogra_: if you search for lb_chroot_hacks in http://people.canonical.com/~ubuntu-archive/livefs-build-logs/quantal/ubuntu-omap4/20120819/livecd-20120819-armhf.out you'll see the exact same output
<ogra_> hmpf
<cjwatson> ogra_: I've already fixed the "Malformed line 3 in source list" bit, so I think that'll cover it
<cjwatson> IMO that's the real error here
<ogra_> hmmm, i should probably have scrolled up a bit :P
 * ogra_ blushes
<cjwatson> There were no fewer than five independent bugs in today's image builds, so it can be a bit hard to keep track
<ogra_> yes, still, i only looked at the end of the log, i didnt even notice the earlier error
<cjwatson> Fixes all uploaded now
<cjwatson> So, bug 648611 is fixed now; as previously discussed on the TB list, I'm going to grant ~ubuntu-sru access to make queue admin changes to the Proposed and Updates pockets in stable releases, and ~ubuntu-release access to make queue admin changes to the Release and Proposed pockets in the development release
<ubot2`> Launchpad bug 648611 in launchpad "ubuntu-sru either have too much or too little permission as queue admins" [High,Fix released] https://launchpad.net/bugs/648611
<cjwatson> And I'll add an entry to NewReleaseCycleProcess to adjust this
<smartboyhw> Well, er, when will 12.04.1 be exactly released?
<Daviey> smartboyhw: it's scheduled for some time today, providing everything goes dandy.
<smartboyhw> Thanks...
<mvo> could someone please reject the freeglut3 package in precise-proposed? I will upload a improved version of it
<seb128> mvo, http://launchpadlibrarian.net/112884864/freeglut_2.6.0-1ubuntu3_source.changes
<seb128> mvo, you mean? e.g freeglut without "3"?
<mvo> seb128: yeah, sorry
<seb128> mvo, no worry, done
<mvo> ta
<seb128> yw
<seb128> ;)
<mvo> ;)
<smartboyhw> seb128 and mvo: If a image is declared ready that means it's the final version and I could install it and say it is official 12.04.1 ISO image?
<seb128> smartboyhw, no, if it's not published and announced it's not official and could change
<smartboyhw> seb128: How about in the ISO QA Tracker?
<smartboyhw> I mean READY.
<seb128> well, QA validated it but it's the release team which takes the decision
<seb128> release team could decide to respin on other factors (even if it's not likely)
<smartboyhw> OK, sure, one build only got ME to test: Ubuntu Studio amd64:) So that's why I'm asking:)
<seb128> you better way it's officially announced
<smartboyhw> ok
<babyface> found some build error here :  http://people.canonical.com/~ubuntu-archive/livefs-build-logs/quantal/ubuntu/20120823/livecd-20120823-amd64.out ,  so there wont be new quantal desktop and server build today?
<cjwatson> babyface: I've uploaded fixes for that; rebuilds later
<cjwatson> but thank you for checking logs :)
<babyface> cjwatson,  thanks. ;)
<cjwatson> I've literally only just finished processing the morning's pile of mailed failures ...
<smartboyhw> cjwatson: :( and :)
<jibel> stgraber, slangasek gema reported bug 1040494. What is your opinion ?
<ubot2`> Launchpad bug 1040494 in update-manager "Unable to perform cdromupgrade without network from Lucid to Precise 12.04.1 AMD64 : E:Could not perform immediate configuration on 'python-minimal'" [Critical,New] https://launchpad.net/bugs/1040494
<Niarf> hi
<Niarf> do you know any hour to release 12.04.1 ?
<stgraber> good mroning
<stgraber> Niarf: when it's ready
<Niarf> ;)
<Niarf> https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule shows 08/23/2012 :)
<stgraber> Niarf: sure, and it's only 9am here
<Niarf> ah ok :)
<cjwatson> We never publish release times to the hour
<cjwatson> Because doing so would be harmful
<Niarf> ^^ sorry, you're in US :)
<cjwatson> Time-based releases are all very well but when it gets to actual release day it's much better to take your time and make sure everything's right
<Niarf> ok :) we have to to wait mailing announce
<Niarf> -to
<stgraber> Riddell: still planning on releaseing powerpc and amd64+mac alternates? I see no result for the current build or any build in the history
<Riddell> stgraber: I never have been very interested in those for 12.04.1
<stgraber> Riddell: ok. Are you happy with the rest of the images and upgrade results? can I mark all of Kubuntu as good to go except for powerpc and amd64+mac?
<Riddell> stgraber: yep I'm happy
<smartboyhw> stgraber: Actually what is good to go now?
<stgraber> utlemming, smoser: hey there, can we get test results for the cloud images?
<smoser> stgraber, i'll see if i can help
<stgraber> ^ sorry for the mess, clicked the wrong button... (marked for re-build instead of ready)
<smartboyhw> stgraber: :)
<stgraber> smoser: thanks
<smartboyhw> stgraber: What is ready now?
<stgraber> Daviey: what's the status of Ubuntu Server amd64, the remaining Netboot (amd64, i386, armhf+omap, armhf+omap4) and the server upgrades? any of these I can mark as ready?
<stgraber> Daviey: well, armhf+omap is bad, so won't be marked ready anyway, but the rest still needs confirmation
<stgraber> knome: any progress on testing the alternates?
<stgraber> superm1: can you sign off on https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest/12.04.1 (I see the images are already marked ready on the tracker, so I assume it's just out of sync)
<smoser> stgraber, i'll get the iso tracker populated
<stgraber> smoser: thanks
<stgraber> smoser: I see that one product doesn't have testcase, I'll quickly tweak that one
<gema_> I have found bug 1040494 and I am not sure we should release with that problem
<ubot2`> Launchpad bug 1040494 in update-manager "Unable to perform cdromupgrade without network from Lucid to Precise 12.04.1 AMD64 : E:Could not perform immediate configuration on 'python-minimal'" [Critical,New] https://launchpad.net/bugs/1040494
<gema_> can someone have a look at it and tell me if there is anything wrong, I have tried upgrading in three slightly different ways and it still fails
<stgraber> gema_: was the 10.04 system up to date
<superm1> stgraber: lemme touch bases with tgm about something first
<gema_> stgraber: yes
<gema_> stgraber: the three times
<stgraber> gema_: ok... wondering how we regressed there as I clearly got that to succeed last week
<stgraber> gema_: restoring my test VM to check whether it was i386 or amd64, that might make enough of a difference to cause that bug...
<gema_> stgraber: there are some passes, I haven't managed to make it to pass once
<gema_> that's why I tried three times
<gema_> stgraber: I am testing on a netbook , btw
<gema_> stgraber: same one that failed on the camera stuff in the past
<stgraber> gema_: can you paste the output of "dpkg -l" somewhere? that should help figure out what's different
<gema_> yep
<gema_> right now it is half way through the install, I mean
<gema_> it's not lucid nor precise
<stgraber> hmm, ok... I'd want the output for the pre-uprade state ideally so I can compare to what I have here
<gema_> ok, I will reinstall lucid
<jibel> I tried to reproduce this morning but couldn't. I tried with cd, usb and from the image copied into the system to upgrade and mounted on a loop device
<jibel> they all passed
<gema_> it may be hw related :?
<stgraber> ok, so something's definitely different on the lucid install, just need to figure out why and see how common it'll be
<balloons> did you update lucid before upgrading/
<balloons> ?
<gema_> yes
<smartboyhw> balloons: Yo
<stgraber> gema_: ok, my test system was 10.04.4 amd64 fully up to date, so in theory it's the same as your install ;)
<stgraber> now that's the theory, we need to figure out what exactly differs
<gema_> ok, I am reinstalling lucid and giving you the dpkg -l after that
<gema_> keep yours to compare just in case
<gema_> it'll take a while
<gema_> it's very slow installing
<jibel> stgraber, you'll have the status in the clone
<jibel> attached to the bug report
<jibel> stgraber, http://paste.ubuntu.com/1162678/
<gema_> that was on my logs, jibel ?
<stgraber> jibel: oh right, always forget that these aren't stripped anymore. awesome, will start the diff now
<jibel> gema_, yes
<gema_> jibel: ack, then I don't need to reinstall just yet
<smartboyhw> o/ What happened to the Ubuntu Server EC2 12.04.1 ISOs?
<jibel> gema_, at least not to run dpkg -i :)
<jibel> -l
<gema_> jibel: ok
<stgraber> gema_, jibel: difference between your system and mine: http://paste.ubuntu.com/1162687/
<stgraber> I'll run another dist-upgrade now to make sure it didn't regress since the last run
<stgraber> jibel: can you perhaps try with the exact same package list as gema to see if we can reproduce it that way?
<jibel> stgraber, on it
<stgraber> gema_: I think we'll need to add a release note regarding network-less upgrades using the alternate media... we've fixed a lot of issues so it should be more reliable than it ever was, but it's still pretty tricky and all the problems we've seen so far have been on very clean systems, I'm a bit worried of what would happen on a system with hundreds of extra packages installed
<gema_> stgraber: agreed
<smoser> stgraber, done.
<stgraber> smoser: still testing ebs and hvm?
<skaet> good morning
<stgraber> hey skaet
<skaet> hiya stgraber
<smartboyhw> hi skaet
<skaet> hiya smartboyhw, thanks for your testing yesterday.
<smartboyhw> skaet: On what?
<smoser> stgraber, hm.. this is strange.
<smoser> my client/scraper didn't seem to work.
<smoser> stgraber, this is strange.
<smoser> i sweare this is what i did before.
<smoser> and we have never run "multi-instance" for ebs
<smoser> https://jenkins.qa.ubuntu.com/job/precise-server-ec2/19/
<smartboyhw> Yeah, been wondering about ec2 servers already
<smoser> ah. i see , utlemming went in behind my script and populated manually himself for alpha3 quantal
<smoser> http://iso.qa.ubuntu.com/qatracker/milestones/226/builds/19470/testcases/1086/results
<utlemming> smoser: guilty
<smartboyhw> I don't think it's guilty
<utlemming> smoser: I never got your script to work for me
<smoser> utlemming, so basically the tests that are in the iso tracker dont match up well with what we actually run
<smoser> well, it would not have populated "multiple instances run" results because, well, we dont run that test
<smoser> i'm not going to chase that at the moment. you can anually mark those if you want. but the script works for me (multiple times, just following the readme at bzr+ssh://bazaar.launchpad.net/~smoser/+junk/jenkins2isotracker/)
<smoser> manually or annually, up to you
<smoser> utlemming, can you run hvm test?
<utlemming> smoser: yeah, wokring on that now
<utlemming> smoser: also Amazon annoucned HVM instances in US-West-2
<utlemming> smoser: that was announced this morning
<utlemming> do we want to add that to the test list or no?
<stgraber> archive admin: please review and merge https://code.launchpad.net/~stgraber/ubuntu-archive-tools/fix-lts-precise/+merge/121005
<smoser> utlemming, well, i think that the iso tracker should be updated to effectively require results for the tets we actually run
<utlemming> right
<smoser> i dont personally see th eneed to run ebs multi-instance. but we can also solve the problem that way.
<cjwatson> stgraber: doing
<cjwatson> stgraber: done
<smartboyhw> stgraber: Testing Xubuntu alternate amd64 now:)
<stgraber> cjwatson: thanks
<stgraber> smartboyhw: I'm reading #ubuntu-testing too, no need to copy everything to -release ;)
<smartboyhw> I know
<stgraber> seb128: hey, apparently you're the backup sign-off for Ubuntu desktop/alternate/dvd and upgrades, do you consider the current 12.04.1 builds as ready?
<seb128> stgraber, I've no idea, I've been swamped with quantal ff this week and I had no time for 12.04.1
<seb128> stgraber, I didn't hear of any issue so I don't nack it
<seb128> if QA and release are happy with it please go for it
<smartboyhw> Actually, how could you guys still deal with FF, while 12.04.1 issues are going!
<seb128> smartboyhw, what issues?
<stgraber> smartboyhw: part of the job description involves being good at multi-tasking
<stgraber> seb128: some lts-to-lts when upgrading without internet connectivity seem to remain
<seb128> stgraber, do you have a bug number?
<stgraber> seb128: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1040494
<ubot2`> Ubuntu bug 1040494 in update-manager "Unable to perform cdromupgrade without network from Lucid to Precise 12.04.1 AMD64 : E:Could not perform immediate configuration on 'python-minimal'" [Critical,New]
<smartboyhw> stgraber: Like
<smartboyhw> seb128: Upgrades?
<smartboyhw> I saw people failing to upgrade from 10.04 to 12.04.1
<skaet> Daviey, we're still missing one of the tests for Ubuntu Server - can we get it executed please.
<skaet> arosales, ^
<seb128> stgraber, seems like a foundation team sort of bug? do we have an idea how frequent the issue is? how do you update without internet? from a local mirror?
<jibel> smartboyhw, and none of them reported a bug and provided the minimum information to troubleshoot it.
<stgraber> seb128: it's for people upgrading using the alternate media as a package source
<seb128> stgraber, I wouldn't consider it as a blocker from the desktop side...
<xnox> seb128: well they can upgrade, it's just they end up with uncofigured package / partitial upgrade & get to keep both pieces.
<stgraber> seb128: I re-tried with a clean 10.04 to 12.04 here with an i386 system and can't reproduce the issue though I'm sure depending on what's installed on the 10.04 system, issues will show up, we simply can't test everything...
<seb128> right
<stgraber> seb128: so yeah, my current point of view is to cleverly cover that in the release announcement, strongly recommending to use a real mirror for upgrades instead of the alternate media
<seb128> +1
<jibel> skaet, stgraber https://wiki.ubuntu.com/QATeam/ReleaseReports/PrecisePoint1TestingReport
<jibel> this is without EC2, that explains the low image coverage
<jibel> I'll refresh the report with it
<stgraber> seb128: so I'll mark Ubuntu as good to go, I don't think we'll have a fix in time and I doubt we'd respin for it. I'll make sure our announcement and release notes cover that case (which thankfully won't exist anymore in 14.04!)
<smartboyhw> Thanks jibel
<seb128> stgraber, thanks
<stgraber> tracker updated, will start pre-publish
<Daviey> skaet: on it
<Daviey> stgraber: hey, do you know how to remove a test from Precise?
<utlemming> smoser: hvm testing done
<Daviey> the outstanding test skaet outlined is for Quantal only.
<stgraber> Daviey: sure, what do you want to see removed?
<Daviey> http://iso.qa.ubuntu.com/qatracker/milestones/230/builds/21387/testcases/1288/results
<stgraber> Daviey: "MAAS (Server)" is quantal-only? didn't we have MAAS in 12.04?
<jibel> gema_, does the error occur at early during the upgrade ?
<Daviey> stgraber: we did, but the test case is totally different
<Daviey> hmm, wait one
<gema_> jibel: yes
<gema_> jibel: right after fetching all the packages
<gema_> or files, rather
<gema_> jibel: definitely before the libc6 configuring screen, I was trying to reproduce on a VM but cannot
<jibel> hm, I'll let it run, but it doesn't crash with the exact same list of packages, upgrade from cd without network
<stgraber> jibel: we just noticed that dail-live images are oversized
<stgraber> by 800K
<smartboyhw> stgraber: Should I go and test i386 image for Xubuntu Alternate?
<stgraber> smartboyhw: busy with other things, if it needs testing, sure go ahead
<smartboyhw> OK
<stgraber> jibel: do you have access to dail-live images before  20120817?
<jibel> stgraber, yes let me look
<stgraber> I'm pretty sure 20120816 was still CD-sized
<cjwatson> Riddell: I'm rejecting a print-manager upload from the quantal accepted queue - looks like a duplicate of a previous version, and it's making the publisher generate an OOPS report every run
<cjwatson> Not quite sure how it got into accepted, but anyway
<jibel> stgraber, finally no, I just have an history of the dev release
<cjwatson> OK, and the next publisher run should actually manage to publish that efilinux binary approved yesterday (sbsigntool wasn't installed on the new ftpmaster machine)
<Riddell> cjwatson: hmm, interesting.  thanks for rejecting
<cjwatson> I suspect it's some kind of ramification of bug 62976
<ubot2`> Launchpad bug 62976 in launchpad "Soyuz should not allow duplicated packages in NEW/UNAPPROVED queue" [Critical,Triaged] https://launchpad.net/bugs/62976
<skaet> Riddell,   we're missing some of the images being tested for Kubuntu,  is there an ETA for when the testing will be done, or should we not release them.
<skaet> amd64+mac and powerpc
<cjwatson> Which is only procedurally critical (because it causes oopses), but in reality not that desperately important
<Riddell> skaet: don't release them
<skaet> Riddell, ack
<arosales> Daviey: did MAAS(server) term out to be only applicable to Quantal as the test case currently tis?
<Daviey> arosales: Yes, it's not something applicable to this point release.
<arosales> Daviey: thanks for taking a look, so we just need the testcase removedthen?
<rsalveti> Daviey: hey, mind reviewing the qemu merge proposal?
<rsalveti> would be nice if we could land the new qemu today still
<slangasek> jibel: bug #1040494> we've done our best to make that upgrade case work, and it's working in more scenarios than it ever has before AFAICS due to this added attention.  I don't think trying to get this working everywhere is something to hold up the point release for.
<ubot2`> Launchpad bug 1040494 in update-manager "Unable to perform cdromupgrade without network from Lucid to Precise 12.04.1 AMD64 : E:Could not perform immediate configuration on 'python-minimal'" [Critical,New] https://launchpad.net/bugs/1040494
<stgraber> jibel: how long would re-testing amd64 and amd64+mac take?
<stgraber> jibel: for ubuntu desktop only
<smartboyhw> What? A retest?
<Daviey> rsalveti: I think hallyn would be better suited TBH.  Thanks for the heads up, can you reach out to him in #ubuntu-sever or -devel please?
<rsalveti> sure
<rsalveti> fabo: ^
<jibel> stgraber, before I run to the mad house you mean ?  2hours for mac, 2hours for amd64
<smartboyhw> jibel: :)
<stgraber> jibel: ok
<stgraber> jibel: if I can get them to fit on a CD again, I'll happily take the regular amd64 as it's kind of my fault for not noticing the images going oversized (though quite surprised nobody noticed the scary warnings on cdimage)
<stgraber> ^ unmarked as ready
<knome> stgraber, we're getting the test ran
<smartboyhw> I'm crazy running Xubuntu alternates:)
<stgraber> skaet: was that you ^ amd64+mac is oversized, so not ready
<skaet> stgraber,  my bd
<skaet> bad, even.
<smartboyhw> stgraber: Xubuntu Alternate Builds tested
<phillw> skaet: has (16:16:02) queuebot: (notice) Builds: Ubuntu Desktop amd64+mac [Precise 12.04.1] has been updated (20120817.3) been tested?
<jocarter> stgraber: what time is the 12.04.1 release?
<skaet> phillw,  I marked it ready by accident
<stgraber> jocarter: same answer as everyone, when it's ready ;)
<jocarter> stgraber: ok great!
<skaet> and then had to mark it back to testing state.
<jocarter> (because I haven't had chance to work on the release annoucnement yet)
<stgraber> jocarter: we have some oversizedness of the live amd64 images
<smartboyhw> stgraber: Mark the Xubuntu alternates ready, I tested it
<phillw> oversize is still a niggling bug... but any release not decided as dvd should fit on one
<stgraber> smartboyhw: I need the sign-off contact to tell me that
<smartboyhw> I will get knome
<smartboyhw> :)
<knome> stgraber, they're done.
<jocarter> stgraber: do you happen to have any stats on how many packages have been updated (or bugs fixed) since 12.04?
<knome> stgraber, can i sign on the i386 with one test not done?
<phillw> smartboyhw:( that means you have followed the iso tracker & signed)
<smartboyhw> :)
<stgraber> knome: yes
<stgraber> jocarter: I believe skaet has that
<jibel> stgraber, skaet sorry, my connection is seriously flaky. what is the decision wrt. oversizeness ?
<knome> ok, great!
<stgraber> jibel: trying to fix it
<jibel> stgraber, ok.
<knome> stgraber, skaet: 12.04.1 testing signed off
<skaet> thanks knomw
<smartboyhw> Thanks knome
<skaet> knome,  please sign off on:  https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest/12.04.1
<knome> skaet, did
<skaet> Daviey, arosales - can you please sign off on https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest/12.04.1
<skaet> slangasek, ^
<arosales> skaet: yes, will do.
<skaet> Riddell,  missing your signoff as well.
<Riddell> signed off!
<skaet> knome,  could someone signoff on the upgrade tests for Xubuntu?
<smartboyhw> skaet: I'm contacting knome on this...
<knome> skaet, when i looked earlier, they were done. what happened? did a respin kill them?
<skaet> knome,  no,  there are just some tests on the tracker that weren't signed off - for upgrades
<knome> mmh..
<smartboyhw> I'll go ask the Mythbuntu team for upgrades
<knome> skaet, i'm not sure if i follow. do you simply mean "not don" ?
<knome> *done
<skaet> knome,   not sure if they were done, and not recorded, or not done
<knome> skaet, ok, so simply, we need to run those tests? :)
<utlemming> stgraber: can we pull the 'EC2 Multiple Instances Run' from the EBS cloud images?
<utlemming> stgraber: that's an invalid test
<skaet> knome,  if they haven't been run yes please.
<knome> skaet, ok, i'll organize that. thanks
<brendand> skaet, release meeting tomorrow?
<skaet> slangasek, infinitum - https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1017001 any further info on this one?
<ubot2`> Ubuntu bug 1017001 in apt "package resolvconf 1.63ubuntu14 failed to install/upgrade: ErrorMessage: pre-dependency problem - not installing resolvconf" [Critical,Confirmed]
<stgraber> ok, so for the oversizedness, I'm not spotting any extra package that was pulled in the pool or in the livefs
<stgraber> so something suddently started using an extra 800K of compressed space...
<skaet> brendand,  not sure yet,  depends how 12.04.1 goes.   please submit summary and we'll follow up on email if we don't have a standing meeting.
<skaet> stgraber,  translations?
<smartboyhw> I think the Mythbuntu guys can't sign off the upgrade testcases:(
<stgraber> skaet: that could be. I have a week old image on a server of mine, will start diffing with that
<stgraber> skaet: I see 3 things so far, "patch" was added to the image (113K uncompressed), the slideshow was updated with new translations (unknown size difference), the langpacks were updated
<stgraber> I'm doing a local test rebuild with the slideshow reverted
<utlemming> skaet: cloud images are ready to go, even though the tracker disagrees (the disagreement is with test cases that need deprecating for EBS volumes)
<stgraber> skaet: ok, the problem isn't patch or ubiquity-slideshow-ubuntu, patch moved from /pool to livefs so actually saved us around 20K. ubiquity-slideshow-ubuntu in turn took the freed 20K
<stgraber> skaet: I'll try rebuilding with the reverted langpacks
<stgraber> skaet: I currently see two quick fixes. 1) drop wubi.exe (we'd losse the UI on Windows by doing that ...) 2) drop a langpack
<skaet> slangasek,  can you weigh in on least impact of the two options that stgraber proposes?  neither are appealing.
<stgraber> I personally think loosing a langpack is the best option of the two
<skaet> utlemming,  ok,  thanks. :)   please get arosales to sign off on the manifest for them.
<stgraber> unless I missed another magical way of finding 800K of compressed space
<skaet> cjwatson, your thoughts?
<cjwatson> Dropping a langpack is pretty much our stock answer to these things
<skaet> ok.   sounds like dropping a langpack it is.
<skaet> :(
<stgraber> preparing the live-build upload for that
<stgraber> (as changing the seed isn't enough post-release)
<cjwatson> One of these days ...
<stgraber> so we have the choice between spanish or portugese, by number of speakers I believe we should drop portugese. /me checks wikipedia
<knome> skaet, just to make sure, isn't it so that the "upgrades" are from 10.04 and 11.10?
<infinity> skaet: stgraber and I looked into 1017001 for a while, and every potential fix just moved the problem around, rather than fixing it.  So, even if it's fixable, it's not happening for .1
<arosales> skaet: manifest testing images signed :-)
<stgraber> right, wikipedia confirms, so we'll be dropping language-pack-pt for the amd64 images
<skaet> thanks arosales
<skaet> stgraber,  other factor is we are producing a chinese image
<skaet> infinity,  understood.
<stgraber> skaet: yeah, though I believe I was last told not to touch the Chinese support in the stock image...
<arosales> skaet: sure, np :-)
<knome> skaet, did you see my question? sorry for pestering...
<skaet> stgraber,  ok,  go with what's safe, and we'll revisit after this, as part of post release feedback to get a prioritize order in future.
<skaet> knome,  yes.
<knome> skaet, thanks. :)
<skaet> (and no worries....   thanks for your patience)
<stgraber> skaet: FWIW I agree that it doesn't make sense to include the chinese langpack on all images when we have a separate image for that language, but yeah, best to rediscuss for 12.10 or 13.04
<stgraber> infinity: I just uploaded http://paste.ubuntu.com/1162910/ to precise-proposed. Can you review it and accept it when it lands in -proposed? We'll also need it deployed on kapok ASAP so I can respin the amd64 images, test them and hopefully still release today. Thanks!
<stgraber> jibel: ETA for new desktop images (amd64 and amd64+mac only) is ~1h
<jibel> stgraber, thanks
<infinity> Yay for copy and pasting.
<xdatap1> skaet, hello. I've build the italian image and performed some tests, we're ready for the release. Do I need to wait the official release or may I send the email to the IS asking to upload it? (it some takes time, btw)
<infinity> stgraber: I'll poke it in a sec.
<xdatap1> skaet, s/it some take time/it takes some time
<stgraber> jibel: as I said, I'll take care of amd64 so you just need to do amd64+mac, so if all goes well, we'll be good to go in 2-3 hours
<jibel> stgraber, ok
<cjwatson> seb128,infinity: Yesterday's discussion tickled a vague memory, so I went and had a look.  lib/lp/soyuz/scripts/tests/test_copypackage.py:TestCopyBuildRecords.test_incremental_binary_copies seems to be exercising the very behaviour we want.
<cjwatson> It might be worth trying with a small package where the consequences of having to reupload aren't too serious.
<seb128> cjwatson, oh, great, thanks
<cjwatson> Unfortunately we can't really try it on dogfood because there are no non-i386 builders there.
<infinity> cjwatson: To be fair, though, that's 99% of the time, NOT a behaviour we want.
<infinity> cjwatson: I mean, we want it to work for emergency situations, and know that it should work, but I don't want people to think we should normally be doing it. :P
<cjwatson> Oh, I agree
<cjwatson> But it's good to have the option
<infinity> cjwatson: As for dogfood, it's easily testable.
<skaet> xdatap1,  please hold off for the release
<infinity> cjwatson: Give me one 64-bit buildd, and we can flip-flop it to create and fix skew at will.
<xdatap1> skaet, ok no problem
<cjwatson> Well.  True.  But we don't have any dogfood builders at all right now.
<infinity> cjwatson: No, true.  I miss ferraz.  *sniff*
<cjwatson> There was a massive kerfuffle yesterday to steal one from production for some LP QA.
<infinity> cjwatson: We could just spin up lp-buildd on mawson.  It's not like it doesn't already run every other LP service.
<cjwatson> Rather you than me. :-)
<infinity> cjwatson: Can't do virtual tests that way, but it's fine for the distro/bare-metal case.
<cjwatson> Fake-virt is possible anyway.
<infinity> Yeah.
<stgraber> infinity: looks like live-build is now built. Let me know when it's on kapok. thanks!
<infinity> stgraber: Already working on it. :P
<stgraber> yay!
<skaet> thanks infinity, stgraber. :)
<slangasek> skaet, stgraber: I'm certainly not thrilled about either option, but it would be better to drop a langpack than to drop wubi IMHO.  Which langpacks do we have on there at present?
<stgraber> slangasek: -en -es -pt -zh-hans
<slangasek> stgraber: on both archs currently?
<stgraber> slangasek: yeah, after we had to drop -de from i386, they're currently in sync
<slangasek> and you're leaning towards removing -pt, not -zh-hans?
<stgraber> slangasek: correct, the live-build infinity is deployed drops -pt
 * xnox thought fr should be in & default
<slangasek> xnox: that's for 12.10
<slangasek> :)
 * skaet reminds xnox this is precise, not quantal :)
<slangasek> pardon
<stgraber> slangasek: I remember being told in the past not to drop -zh and having a quick look at it, ubuntu-defaults-zh-cn doesn't depend on zh-hans
<slangasek> je veux dire, "Ã§a, c'est Ã  12.10"
<xnox> don't we have a chinese image for 12.04.1
<xnox> (as in separate one)
<stgraber> slangasek: "Ã§a c'est pour 12.10"
<slangasek> stgraber: doesn't make any sense to me why you would've been told not to drop it; who told you not to?
<stgraber> xnox: we do
<slangasek> xnox: yes, we do
<slangasek> stgraber: drat, so close ;)
<stgraber> slangasek: I can't remember, that was a couple of cycles ago IIRC. I agree that we should get rid of -zh on the main image and fix the chinese image to depend on these packages...
<stgraber> currently ubuntu-defaults-zh-cn doesn't seem to depend on the langpacks
<slangasek> heh
<slangasek> so the langpacks are on the Qin CD only because they're on the main CD?
<stgraber> that's my understanding
<stgraber> and I agree that's broken
<slangasek> but it does mean additional several times more work to fix it up in time for .1
<slangasek> so I think removing -pt is ok
 * skaet nods
<skaet> I'm adding it to the topics to discuss for a feedback session on this release.
<stgraber> skaet: the whole langpack stuff should indeed be re-discussed. There's no reason why we have language-pack-zh-hans on the main image and I believe there's no more reason to have language-pack-en on the Qin image
<skaet> agreed.
<stgraber> so fixing that situation should make us save space on both images
<slangasek> skaet, stgraber: best to file a bug on ubuntu-defaults-zh-cn and target to .2
<stgraber> slangasek: will do
<Riddell> stgraber: skaet: I'm about to leave for the weekend, anything else you need from me?
<skaet> Riddell,  checking..
<Riddell> https://wiki.kubuntu.org/PrecisePangolin/ReleaseNotes/Kubuntu has been updated
<infinity> stgraber: thedac's done your live-build upgrade on kapok.
<stgraber> infinity: thanks
<skaet> Riddell,  thanks.  :)
<stgraber> jibel_: build running
<stgraber> slangasek, skaet: bug 1040764
<ubot2`> Launchpad bug 1040764 in ubuntu-defaults-zh-cn "ubuntu-defaults-zh-cn should depend on language-pack-zh-hans and any other needed language packs" [High,Triaged] https://launchpad.net/bugs/1040764
<slangasek> stgraber: ta
<knome> skaet, just saying it already; we don't have anything we want to update in the release notes
<skaet> Riddell,  thanks,  not seeing anything.  ScottK the backup to notify when we announce?
<skaet> thanks knome.
<knome> np. running the upgrade tests now too
<Riddell> skaet: he might be on holiday too so nudge shadeslayer and #kubuntu-devel for good luck
<skaet> thanks Riddell.   will let them know in the channel when this one goes out.
<stgraber> skaet: continuing pre-publishing with everything but ubuntu-desktop
<skaet> have a good weekend.
<skaet> Thanks stgraber
<cjwatson> slangasek: I vaguely remember the drama about -zh as well, but unfortunately not the details
<cjwatson> Certainly not a drama I'd be keen to resurrect at short notice
<slangasek> right
<slangasek> seems to me that this should be obsoleted by the Qin image now, but
<shadeslayer> ?
<skaet> shadeslayer, just that you're Riddell's backup until we get the images published ;)
<cjwatson> Actually
<shadeslayer> sure
<cjwatson> I think the previous -zh drama was back when the Qin image was just the normal one with a different language default
<cjwatson> In fact I'm nearly sure
<cjwatson> (language default> in gfxboot, that is)
<skaet> by the way,  have already got the ok for the chinese images to be oversized for precise,  in case it comes up ;)
<cjwatson> I believe that ubuntu-defaults-builder/lib/language-support-hook deals with installing language-pack-blah
<cjwatson> Though worth testing for the zh-hans/zh-hant irregularity
<cjwatson> However I think it's a reasonable working hypothesis that the previous drama stgraber refers to is now in fact obsoleted by the Qin images, and worth testing after .1
<stgraber> skaet: well, they are oversized at this point. Unless they want to get the non-oversized one that's missing a bunch of fonts and ibus-sunpinyin
<stgraber> skaet: might be good to know which one they want released
<balloons> so I have a crash file recieved from debconf after upgrading, but apport won't process it. If I choose to send the report, apport simply closes and writes out a zero byte .uploaded file.. no web browser, no bug filed
<stgraber> skaet: 20120817.1 fits on a CD, 20120822 doesn't
<skaet> stgraber,  agree.   Need to get a lead identified for those images.
<stgraber> btw, pre-publishing done for wubi, ubuntu-alternate and ubuntu-server
<stgraber> will pre-publish desktop once amd64 is done building (going on the assumption that testing will be all good)
 * stgraber quickly grabs some to eat
<skaet> mvo,  can you update the meta release file?
<stgraber> I really hope #is fixes the bandwidth issue between the buildds and nusakan... downloading the squashfs at an amazing 1MB/s...
<stgraber> looks like we cleared 9MB off the squashfs, so sucess on that part!
<cjwatson> Still?  Please report that - my understanding was that that had been fixed
<stgraber> jibel_: built!
<stgraber> updated ubuntu desktop i386 to show the same version number as amd64, confirmed md5sum matches, so keeping all testing results
<stgraber> skaet: pre-published all images
<jibel> stgraber, syncing
<stgraber> I'm already running half of the amd64 tests but can't run much more than 6 installs in parallel on that laptop so if someone wants to help, feel free
<knome> stgraber, i hope you are not talking about *ALL* images ;)
<skaet> knome,   no it was just one ubuntu desktop image that was resized.
<knome> huh :)
<infinity> stgraber: Are you saitsfied with that new live-build, BTW?  manifests check out, etc?
<infinity> stgraber: (I want to release it so kapok's not skewed from reality, if you're cool with the results)
<stgraber> infinity: yep, that saved us 9MB and the images look like they're working
<stgraber> jibel: can you try to pick testcases I'm not already covering with amd64?
<stgraber> jibel: as amd64 and amd64+mac are technically the same livefs, a single pass between the two media will be enough, so if we can reduce the number of installs for you, that'd be great
<infinity> stgraber: released to updates, then.
<stgraber> infinity: thanks
<jibel_> stgraber, i'm on broken internet/non-english
<stgraber> jibel_: awesome, I don't have that one covered with my VMs
<infinity> jibel_: For a second there, I thought "broken internet" was a locale.
<infinity> jibel_: "u want 2 install now?"
<stgraber> buildds => nusakan bandwidth problem has now been solved, so we should be back to getting quick livefs builds
<cjwatson> infinity: opposite: http://www.chiark.greenend.org.uk/~owend/free/guru.html
<infinity> cjwatson: And why hasn't this been committed upstream?
<cjwatson> " On my Debian GNU/Linux 2.1 system" and libc upstream of the time; you have to ask?
<infinity> cjwatson: Fair point. :P
<skaet> slangasek,  stgraber - any reason not to turn on the updates now?  (meta-release file)
 * skaet thought there was some discussion earlier about holding off for a day, but can't remember the outcome.
<slangasek> skaet: no.  We're prepared to roll it back if it turns out users are having problems with the upgrade?
<skaet> slangasek,  will ask mvo to be on standby.
<slangasek> skaet: well, I thought the conclusion was to hold off the announcement until we're confident we don't need to roll back
<stgraber> we know there are bugs but only way to get numbers and more data is to have people hit them... so turning them on and make sure we can very quickly roll back is the plan
<skaet> slangasek, stgraber - ack.
<slangasek> stgraber: did you have any time to look at 1017001 and getting a full apt log out?
<stgraber> the upstart-job mess is the one known bug at this stage but although we can reproduce it, we don't seem extremely close to being able to fix it... (I was hoping to spend some time on it yesterday, that didn't happen unfortunately)
<slangasek> being close to fixing it is separate from whether it's ok to turn on upgrades for users while the bug remains
<slangasek> i.e., if it's going to affect huge numbers of users, we should still turn uploads back off until we can get it fixed
<slangasek> s/uploads/upgrades/
<stgraber> right and we unfortunately don't have any numbers until we turn the upgrades on. So far the reproducer depends on a pretty weird setup (mythbuntu without any update)
<slangasek> yep
<slangasek> though, not all the people who've hit the bug were in that situation... it's just the one we've been able to reproduce
<mvo> slangasek, stgraber, skaet: enabled now and works in my test vm afaict
<stgraber> ok
<slangasek> mvo: cheers
<stochastic> skaet, I was told you're the person to mention that the Ubuntu Studio team sees no real reason to publish release notes on 12.04.1 - though we could be persuaded if needed - so don't hold your breath for them :)
<mvo> yw
<infinity> stgraber: Without any updates?  Doesn't release-upgrader force an upgrade to the tip of $current-updates before upgrading to $new_release?
<infinity> (And if not, why the heck not?)
<stgraber> infinity: it doesn't
<stgraber> no idea
<infinity> Given that, in some oddball cases, the only way we can fix upgrades is to fix old_release, not new_release, that seems like a no-brainer.
<stgraber> FWIW I didn't check that applying the upgrades fixes the upgrade issue, but based on jibel_'s testcase, I assumed it did
 * stgraber quickly checks
<slangasek> infinity: in the general case, this potentially makes the upgrade much slower.  Those packages that need to be pulled from -updates (such as the release-upgrader version of apt itself, for 10.04) are pulled explicitly.
<skaet> stochastic, ok,  if no new bugs you want to warn folks of,  we'll leave them as is.
<infinity> stgraber: I don't actually see how upgrading to -updates would fix this case anyway, unless it just subtly reorders things enough to heisen the bug away.
<slangasek> infinity: can you test that?
<infinity> But in the general case, don't we pretend that we don't support upgrades on non-updates systems?
<infinity> slangasek: stgraber's already running said test, apparently. :P
<infinity> 12:17  * stgraber quickly checks
<infinity> I can't beat Captain VM over there, when he decides to test something.
<slangasek> ok
<skaet> jibel,  did the testing report get mailed out and I've missed it?
 * skaet wants to cross check against the release notes
<jibel_> skaet, no, I posted the link on the channel only
<skaet> jibel_,  can you repost please.   I don't have it in my backscroll.
<jibel_> sure, 1 sec
<skaet> thanks.  :)
<jibel> skaet, https://wiki.ubuntu.com/QATeam/ReleaseReports/PrecisePoint1TestingReport
<skaet> thanks jibel
<stgraber> slangasek, infinity: so far so good (with updates applied), I'm way past the usual explosion point
<jibel> stgraber, last test: I successfully installed a mac with the screenreader
<utlemming> skaet: what's the eta for pulling the switch on the cloud images?
<infinity> stgraber: That could be either a useful data point, or just extra frustrating, I'm not sure which.
<skaet> utlemming,  go ahead and pre-publish them.    We'll be waiting for some data on the updates before the announce will go out.
<slangasek> infinity: it's a useful data point because it means we can bisect the updates, pinpoint the ones that make a difference. and quirk them in update-manager?
<utlemming> skaet: they are pre-published, ready to be made public.
<infinity> stgraber: And unless something in -updates drastically changed to affect this, it seems more likely that applying updates just shifted the bug around so a different set of people will see it. :/
<infinity> slangasek: See above.
<skaet> utlemming,  waiting for some data.
<slangasek> infinity: perhaps
<infinity> slangasek: But absolutely, if something in updates actually FIXED the ordering somehow, we can totally use that as a workaround.
<stgraber> slangasek, infinity: upgrade finished without any error. I'll push the resulting dist-upgrade directory
<infinity> Huh.  Curious.
<stgraber> slangasek, infinity: http://www.stgraber.org/download/bug1017001/dist-upgrade-with-updates/
<stgraber> jibel: do you still have that LTSP failure log from yesterday (quantal)? I'm preparing the next LTSP upload as we speak (trying to get as many of my stuff into quantal before FF...)
<jibel> stgraber, no, I deleted the VM but can reproduce it if you wish
<stgraber> jibel: nah, will try and find your pastebin link in my irc history, that'll be enough
<stgraber> jibel: found it. http://paste.ubuntu.com/1161542/
<infinity> Hrm.  So apt.log is nearly identical in both cases, up until the failed one stops having anything to log.
<stgraber> jibel: looks like you forgot to post the +mac result.
<stgraber> marking amd64 as ready for now, waiting for +mac
<infinity> The only differences are that the upgraded system doesn't install xul-ext-ubufox or python-pycurl, which seems like they'd be red herrings.
<jibel> stgraber, oh right, forgot to press submit
<knome> stgraber, skaet: i'll sign off xubuntu upgrades as ready for my part. all the testcases are now done.
<stgraber> infinity: that's really weird...
<stgraber> knome: ok, thanks
<skaet> thanks knome.  :)
<knome> np. let's hope we have more testers next time,...
 * knome is going to appease the angry wife now
<knome> see you!
<stgraber> skaet: I'm going to sign-off netboot i386 and amd64 as Ubuntu has been marked as good on both
 * phillw can I ask who checked out the AMD-Mac sequence?
<skaet> stgraber,  ack
<infinity> slangasek: Do you remember, off the top of your head, if any of the people reporting the bug had ubuntu-desktop installed?
<slangasek> infinity: no idea
<slangasek> why do you ask?
<infinity> I dunno.  Following a weird hunch that installing python-pycurl mangles the order just enough to magically make it work.
<infinity> Which would be scary.
<infinity> But it's in ubuntu-desktop in lucid and none of the others, it's in all of them in precise.  It's also one of the only two extra packages that gets installed pre-upgrade in stgraber's successful test.
<infinity> xul-ext-ubufox being the other one.
<skaet> stochastic, is there a new Ubuntu Studio web site that should get mentioned?
<obounaim> When Ubuntu 12.04.1 will be released?
<stgraber> obounaim: when it's ready
<obounaim> today?
<stgraber> most likely
<xnox> obounaim: a full day lasts up to 50 hours around the world. 23-Aug has elapsed for about 22 hours so far. We still have plenty of time to "release on 23rd of August" somewhere in the world.
<obounaim> ok
<obounaim> can i ask what are you doing now compiling, testing the image...?
<xnox> obounaim: http://iso.qa.ubuntu.com/qatracker/milestones/230/builds
<xnox> obounaim: testing candidate images, trying to reproduce/resolve bugs which we found recently.
<nessita> hello everyone, I'm about to dput a new release of magicicada to ubuntu (universe), I just wanted to confirm that is ok to do so (freeze is in ~1 hour afaik)
<stgraber> nessita: yep, it's fine
<nessita> stgraber: thanks!
<stgraber> you have 43 minutes ;)
<nessita> :-)
 * infinity lunches while his machine grinds on installing a mythbuntu test base.
<slangasek> bug #1040002 seems to still be manifesting in the latest jenkins test
<ubot2`> Launchpad bug 1040002 in update-manager "lucid upgrade to precise amd64 universe failed: E:Error, pkgProblemResolver::Resolve generated breaks" [Medium,Incomplete] https://launchpad.net/bugs/1040002
<slangasek> and bug #1040830 looks like a user-reported duplicate
<ubot2`> Launchpad bug 1040830 in update-manager "Cannot upgrade from 10.04 to 12.04.1" [Undecided,New] https://launchpad.net/bugs/1040830
<slangasek> jibel: hi, how does one find the list of bug reports with no package?  Do you know?
<Daviey> slangasek: Advanced Search, "Hide bugs with packages specified"
<jibel> slangasek, check 'Hide bugs with package specified' in advanced search or add field.has_no_package=on in the search query in the address bar.
<slangasek> Daviey, jibel: ta
<bjf> slangasek: i did an install from scratch of quantal amd64 server and ended up with the following /etc/network/interfaces: http://pastebin.ubuntu.com/1163284/
<bjf> slangasek: now, it could be somthing wrong on my orchestra server but "em1" doesn't look right and other installs work just fine
<bjf> slangasek: other installs being precise
<slangasek> bjf: why do you think it doesn't look right?  This is biosdevname, see cjwatson's mail to ubuntu-devel/server today
<stgraber> bj	that looks kind of right in the new biosdevname world...
<bjf> slangasek: well, given that "before" i was expecting eth0 and got that and today i get em1 and the interface doesn't come up ... that seems "wrong" to me
<bjf> slangasek: and might catch a few other folks by surprise
<slangasek> ok; I don't know why the interface doesn't come up
<slangasek> but that needs to be debugged separately from the name change, which is deliberate and not likely to be reverted
<slangasek> (this brings us in line with what RH and Fedora are doing, and with what server OEM vendors have been demanding for a while, so that people in datacenters get a clear mapping of Linux network devices to physical chassis)
<bjf> slangasek: well, i'm sharing an orchestra server with the QA team and my preseed is specifying eth0 so ... looks like i need to do some investigation based on cjwatson's email
<slangasek> yep - sorry
<slangasek> that does highlight that this definitely needs to be in the release notes
<bjf> slangasek: no reason to be sorry, it wasn't obvious to me (which it should have been) that colin's email applied to me or how it would
<bjf> slangasek: i'm using the same preseed for multiple series so i may need a Quantal and forward preseed
<dobey> crap. slow test builds/lp can be quite annoying sometimes. :-/
<cjwatson> bjf: either of the first two approaches that I mentioned in my mail is unambiguously superior to preseeding a specific interface name, and will work from 11.10 onwards
<cjwatson> (not really here)
<bjf> cjwatson: thanks, yup i'm coordinating with the QA folks. sorry for my confusion
<cjwatson> I realise it's a change - that's why I pushed back on doing it in 12.04 :)
<cjwatson> (and even with that, I'm still getting questions about backporting this to 12.04.x
<cjwatson> )
<knome> is it out? :]
<skaet> nope
<skaet> knome,  where will you be posting your news?
<knome> xubuntu.org
<skaet> knome, can I use:  Xubuntu: http://xubuntu.org/news/12-04.1-release
<skaet> in the announce email?
<skaet> or should I just go with xubuntu.org/news/
<knome> humm
<knome> news/ is probably better, we're trying to go away from the "Xubuntu [releasenum] released" -style titles :)
<knome> oh, wait
<knome> let me find you a url that actually works
<knome> skaet, it will be posted to: http://xubuntu.org/news/12-04-1-release/
<knome> what are the milestone names again that one can use with work items?
<knome> the howto doesn't give examples, or link to a list
<knome> ubuntu-12.10-beta-1 ?
<skaet> knome,  yes,  beta-1 or beta1 has been used.   I'm good with beta-1
<knome> okay
<knome> if i mark things for beta-1, can i see an overview of what we're targeting for that somewhere?
<skaet> knome,  yes.   ping me tomorrow and I'll walk you through the options.
<jocarter> how are things?
<knome> skaet, okay. i'll do that if i get to organize stuff around. i'm thinking it might be more useful to just work on the items...
<skaet> jocarter,  waiting for some data
<skaet> knome,  possibly,  but marking the ones that aren't going to happen would be useful as well.
<knome> skaet, yeah, we've marked those POSTPONED
<knome> skaet, too much of that for this cycle, but what can you do :(
<skaet> knome.   Thanks.  that will help.
<skaet> (and yes, it happens)
<knome> question: we're going to add some more launchers to the xfce settings manager. do you think that needs FFe or UIFe?
<knome> technically, we're just going to link a few more executables, which means a few more icons will show up at the settings manager, and some will disappear from the settings menu
<skaet> knome,  UIFe probably, since its visible.
<knome> ok, then i'll try to get it done next week
<skaet> knome,  thanks.   Best if you can get it in before we hit beta 1 freeze next thursday if at all possible.
<knome> sure. mr_pouit is excitedly waiting me to file him a reminder-bug :P
<jocarter> skaet: ah ok.
<utlemming> cloud images have been published
<stgraber> skaet, slangasek: hmm, publish-image-set must have lied to me... the files didn't publish to the right paths
<stgraber> looking into it now
<skaet> thanks utlemming.
<skaet> stgraber,  standing by.
<stgraber> skaet: hmm, actually, it might be fine, checking again because the final find | sed failed, so I'm sure something's wrong somewhere
<stgraber> well, the headers actually look good and the files are where they should be (or at least where the 10.04.x ones ended up)...
<stgraber> pushing to the mirrors
<skaet> utlemming,   site mentions 12.04,  not 12.04.1 - is that deliberate?
<utlemming> er, umm, not its not
 * utlemming fixes that
<stgraber> skaet: can you check that your links are working and that the pages they point to all say "12.04.1 LTS"?
 * skaet trying
<stgraber> apparently something magically generated the right headers but I don't like magic, so best to make sure they're actually all good
<utlemming> skaet: fixed
<skaet> stgraber,  spotting same problem on cdimage pages as utlemming just fixed.
<stgraber> skaet: link?
<skaet> stgraber: http://cdimage.ubuntu.com/releases/12.04.1/release/
<skaet> has more than the tested ones on it as well.
<stgraber> skaet: nope, it actually misses all the 12.04.1 at the moment
<stgraber> skaet: oh, that actually just got synced, now it looks right
<stgraber> (12.04.1 is at the bottom of the page)
<skaet> ok,  looking at it now.
<stgraber> slangasek: can you run "point-release-snapshot precise precise.1-security-updates-snapshot" as ubuntu-archive on lillypilly?
<stgraber> jbicha_: We have "File a bug on ubuntu-docs to have https://help.ubuntu.com/community/UbuntuHashes updated." in the PointReleaseProcess, the project no longer accepts bugs apparently, so where/who do I ask for the hashes to be updated?
<utlemming> skaet: has the release announcement gone out yet, or can I send out the refresh announcement?
<stgraber> utlemming: it's not out yet
<slangasek> stgraber: hmm, I suppose I can - we're doing these snapshots on lillypilly now?
<stgraber> we're waiting for mirrors
<stgraber> slangasek: well, the wiki page says so...
<skaet> utlemming,  not sending it out until we know all the links are working.
<slangasek> stgraber: link?
<utlemming> stgraber, skaet: ack
<stgraber> slangasek: https://wiki.ubuntu.com/PointReleaseProcess
<slangasek> stgraber: ok, I see that update is courtesy of cjwatson, that's reasonable
<slangasek> but fwiw the command fails because it tries to create cross-device hardlinks
<stgraber> slangasek: fun...
<slangasek> heh, because /home is on /dev/sda1 and /srv is on /dev/sdb1
<slangasek> stgraber: I recommend not blocking on this
<stgraber> slangasek: yeah, I was doing these in parallel anyway
<stgraber> so we're at the wait for mirrors and torrents step now
 * stgraber checks the torrents
<stgraber> skaet: surprise, torrents don't work ;) "Requested download is not authorized for use with this tracker."
 * skaet is not surprised...   wish she was 
<stgraber> I tried with Edubuntu, will try something from releases.ubuntu.com too, but doubt it'll make any difference
<stgraber> poked #is
<Daviey> stgraber: also, no server http://torrent.ubuntu.com/releases/precise/release/
<Daviey> ahh, that is main release.. but still odd, no server
<Daviey> stgraber: The auth issue, The torrents always take an age to start working.. it could just be that.
<stgraber> Daviey: yeah, though the past 3-4 times the server was also dead or stuck, so hopefully IS can check and give some kind of ETA
<skaet> stgraber, http://releases.ubuntu.com/precise/ has the 12.04 and 12.04-1 images in the directory.   downloads seem to be picking up the 12.04 ones...
<Daviey> yeah, last time they unblocked it... the vanguard had to rely on bash history IIRC
<stgraber> skaet: oh yeah, the links are wrong... fixing
<slangasek> have the 12.04 images been archived off to old-releases?
<stgraber> slangasek: no, my understanding of the wiki page is that we only move the past point release, not the main release
<slangasek> stgraber: that's incorrect; we archive off the .0 as well for space reasosn on the mirrors
<Daviey> stgraber: Has the meta file been pushed?
<stgraber> slangasek: hmm, ok... can you update the wiki, that page is very unclear about that "Find which images from previous point releases on cdimage.ubuntu.com are going to be replaced by this image set, and archive them to old-images" certainly didn't expand to "including .0" in my head...
<stgraber> Daviey: if you mean, the dist-upgrade trigger, yes
<Daviey> stgraber: It's been validated as functional ?
<stgraber> Daviey: my 10.04 VMs asked me to upgrade, so yes
<slangasek> stgraber: corrected - note that this is also meant to be old-releases, not old-images which is an entirely different place
<skaet> stgraber,   looks like the 2 sets of images problems is pervasive.   spotted it in:  http://cdimage.ubuntu.com/edubuntu/releases/12.04.1/release/
<Daviey> we don't have an updated wubi?
<stgraber> slangasek: right, I'm trying to sort the mess and move stuff to old-releases
<stgraber> skaet: yeah, looking at releases.ubuntu.com for now, will look at cdimage afterwards
<skaet> stgraber, thanks.
<Daviey> skaet: Do you know if an updated wubi was created?
<skaet> Daviey,  yes. 20120817.2
<skaet> its on the iso tracker.
<Daviey> so.. even uploaded it to p.c.c on 09 Aug 2012 .. and that is what people have been testing against.
<Daviey> but, http://releases.ubuntu.com/precise/ shows.. 24-Apr-2012
<Daviey> So.. it hasn't been put in.
<Daviey> stgraber: "Archive the old copy of wubi.exe to old-releases, and publish a new one" .. was that step done?
<stgraber> Daviey: releases is in a bit of a mess, that's what I'm working on at the moment
<Daviey> stgraber: if you do with a hand, do ask.
<stgraber> Daviey, slangasek: http://releases.ubuntu.com/precise/ should be good, can you confirm?
<stgraber> if so, I'll start doing the same thing with cdimage
<slangasek> stgraber: looks right to me
<skaet> Daviey,  wubi is on http://releases.ubuntu.com/12.04.1/
<stgraber> ok, let's have some fun with cdimage then
<skaet> stgraber, looks good to me as well.
<Daviey> stgraber: there is a bunch of meta files from the 17th.. is that correct?
<Daviey> ie, they are older than the iso serial
#ubuntu-release 2012-08-24
<Daviey> hmm, actually.. ubuntu-12.04.1-desktop-i386.iso            17-Aug-2012 22:18  695M
<Daviey> but the released serial is 20120823.1
<Daviey> That doesn't seem right
<stgraber> that's perfectly right actually
<stgraber> the respin was only for amd64 and amd64+mac
<stgraber> i386 was kept identical
<Daviey> stgraber: hmm, then why does the iso tracker show 23rd? http://iso.qa.ubuntu.com/qatracker/milestones/230/builds
<stgraber> Daviey: because when you build with ARCHES= the scripts copy the previous build in the new directory
<Daviey> ah, yes
<Daviey> well spotted
<stgraber> slangasek: hmm, cdimage is really a mess when it comes to archiving older images, .htaccess/HEADER.html are out of date for most products and some weren't even archived (maverick and 10.04.2 though 10.04.3 was archived)
<Daviey> stgraber: i did 10.04.3
<slangasek> stgraber: please use old-releases/kubuntu/releases/lucid/release as a model
<Daviey> (and i was hulva confused myself)
<slangasek> but don't worry about the 10.04.2 cleanup for now
<Daviey> stgraber: are you handling wubi?
<stgraber> Daviey: what still needs handling?
<stgraber> the binary is up to date and the old one moved to old-releases
<Daviey> stgraber: the sums need updating
<slangasek> stgraber: would you like me to help shuffle the 12.04.0 stuff out of the way on cdimage.u.c?
<Daviey> (i'm reluctant to fiddle, with other activity ongoing)
<stgraber> Daviey: fixing
<stgraber> slangasek: sure. I started with the tricky ones (these that were never archived before ...), we can split the rest
<stgraber> slangasek: can you take xubuntu, mythbuntu and ubuntu-cloud-live (not even sure whether we need to archive, just saw it in my find)?
<stgraber> Daviey: wubi.exe checksum fixed
<slangasek> stgraber: sure thing (oops, I also just did ubuntu itself, fwiw).  best practice is to archive all of the above, and only worry about shoving stuff off of old-releases if IS complains
<slangasek> stgraber: we probably need to regenerate HEADER.html in each dir... I don't remember offhand the command for that, do you have it handy?
<Daviey> slangasek: for old-releases?
<slangasek> Daviey: well, for both old-releases and full
<slangasek> because currently, the HEADER.html lists both sets of images :)
<Daviey> slangasek: ISTR having to use sed on old-releases.
<Daviey> ah
<stgraber> slangasek: sure, DIST=precise for-project ubuntu make-web-indices . kubuntu-12.04
<slangasek> hmm; if powerpc isn't part of the point release, I guess we should keep the old image in full/
<stgraber> slangasek: you then have to manually modify HEADER.html to replace 12.04.1 by 12.04
<slangasek> stgraber: ack, thanks
<Daviey> yeah, that is what i sed'd
<jocarter> heh
<Daviey> confirming, a couple of torrents i tested are functioning now
<slangasek> stgraber: ubuntu-cloud-live doesn't appear to have a 12.04.1 in the tree, so not moving; xubuntu, mythbuntu, and ubuntu dvd/preinstall/amd64+mac are done
<stgraber> slangasek: ok, I "think" I moved all the remaining ones. Will do a bit of checking on cdimage now
<stgraber> slangasek: hmm, we don't have a 12.04.1 of preinstall either
<slangasek> ah er, preinstalled images were also not part of the point release, moving those back
<slangasek> stgraber: right :)
<stgraber> skaet: any other weirdness that you found?
 * Daviey notes we should probably automate more of this :)
 * skaet +1's Daviey's note
<slangasek> yeah, we should :/
<skaet> stgraber,  let me take a fresh pass.
<slangasek> stgraber: preinstall moved back, so I think my part's done
<Daviey> slangasek: I'm tentatively thinking of making a web crawler to validate the result, regardless.
<skaet> all links from web site are leading to sane places now as far as I can tell.
<slangasek> stgraber: NB: I haven't fixed the checksum files for old-releases yet; was planning for us to do that after we push the button
 * xnox is boggled by all of this manual handling left and right
<xnox> =)
<stgraber> slangasek: ah ok, I did for all of mine
<slangasek> yeah, we've never automated the point release stuff
<slangasek> stgraber: if you've got the command, feel free to do it for ubuntu/mythbuntu/xubuntu too then
<stgraber> slangasek: checksum-directory takes an "old-directory" parameter to just copy them over
<stgraber> slangasek: ok, will do that now
<slangasek> oh, of course it does :)
<stgraber> slangasek: did you already regenerate those on cdimage?
<stgraber> oh, I guess not if you don't know the command
<stgraber> slangasek: looks like you at least missed one 12.04 => precise symlink
<slangasek> mmh yes
<stgraber> slangasek: right, should be all fixed (both cdimage and old-releases). Ran sync-mirrors too
<slangasek> that should be it for nusakan publication then, right?
<stgraber> yep
<slangasek> stgraber: btw, have committed the fix now for the correct size limit on quantal images
<stgraber> slangasek: thanks
<Daviey> utlemming: still around?
<Daviey> smoser: are you around?
<knome> oh, oh, is it out!
<knome> skaet, that would have been 12-04-1-release in the url as i said. :)
<knome> skaet, (we simply can't use dots in slugs, WP does not allow those)
<skaet> knome,
<knome> oh, wait
<knome> when you go to that url, the dot is changed to a dash automatially
<knome> +c
<knome> hurrah!
<skaet> slangasek,  can you nudge ubuntu-anounce to publish?
 * skaet can't remember if you can, or its go to is.
<slangasek> skaet: nothing in the queue
<slangasek> skaet: did you include the magic header?
<skaet> yup
<skaet> first time didn't
<skaet> got rejected.
<slangasek> ok
<slangasek> how long ago?
<stgraber> skaet: https://lists.ubuntu.com/archives/ubuntu-announce/2012-August/000160.html
<pleia2> I'll get it on fridge within an hour or so (I'm on a train, not reliable enough connection right now)
<slangasek> ok :)
<skaet> coolio.   guess I no longer need to do the nudging :D
<skaet> thanks stgraber, slangasek
<slangasek> I wonder if that's a deliberate policy change, or a bug introduced somewhere
<skaet> let me know if you find out.
<jocarter> congrats, release team. I bet you're pretty tired by now :)
<skaet> Thanks to stgraber,  for wethering through this *interesting* one in style.
<knome> tired? we've postponed that until the grave
<knome> :]
<skaet> Thanks Daviey, slangasek for pitching in to get the last bits figure out.
<skaet> knome.  yes indeed.   late night last night too.
<knome> i've had one all-nighter and several nearly all-nighters this cycle, and i'm expecting to see more of them
 * skaet needs to go send out the note that we're in Feature Freeze now too.
<knome> good luck :)
<stgraber> skaet: oh, good, so my LXC upload was actually before feature freeze then ;)
<stgraber> I still need to do an edubuntu-live upload tomorrow but that will only affect Edubuntu and fix a pretty big regression by adding a new feature
<jocarter> knome: hehe
<knome> jocarter, unexpected nick change >:) is that permanent?
<slangasek> the next nick evolution will be 'jokosher'
<knome> will we see a jobacon too?
 * micahg has some Ubuntu Studio specific featureish uploading to do still, but figures that's ok
<micahg> I'd actually like to request an FFe for anything in the sponsorship queue before FF assuming it's processed before beta 1
 * micahg isn't sure if this was brought up yet
<jocarter> knome: yep, pretty much. I put it off for years because nick changes are hard
<jocarter> knome: but recently I just decided to take the plunge. I'm 30 now I can't have nicknames that come from linkin park songs anymore :p
<knome> jocarter, mm-hmm. this is even harder after i tell you that i thought "jo" was a she
<knome> like jo-jo, the supernanny!
<jocarter> slangasek: "jokosher"? over my decomposing body!
<ajmitch> hah
<jocarter> knome: no more like Jojo in the beatles song. I've decided to go with characters from Beatles songs as the naming scheme for my children if I ever have any :p
<jocarter> (so it fits)
<knome> jocarter, hah. me and my sister are kind of named after beatles stuff too. mother idolized/s paul mccartney, and if her first baby would have been a boy, he would've been pauli. but she got a girl, and my sister is pauliina. i am pasi, because, well... it starts with PA
<jocarter> heh
<knome> "and that's not all!"
<knome> especially after her divorce, she's been calling sir paul mccartney our "father"
<xnox> jocarter: phhh... I was thinking to add 'xnox' as my middle name, official in the passport and everything
<xnox> knome: i also got a male variation of my sisters name
<knome> xnox, what's the female variation then? dmitra?
<xnox> knome: dina (full Diana), dima (full Dmitrij)
<jocarter> one day I'll just change my name to a random unpronounceable unicode character.
<knome> xnox, aha! there was one "dimitra" in our childhood playground
<knome> jocarter, what about â
<jocarter> I guess I'll take a Spock sign. Spock crushes scissors.
<knome> i don't think that is an unicode character
<xnox> knome: watch him get on to the unicode committee
<knome> there was one funny athlete in the olympics. he was called "dong dong"
 * jocarter adds it to todo list
<xnox> knome: have you seen the last names at the 100M men final?!
<xnox> =)
<knome> there are many surnames in finland that are actually first names, but really, same for both?
<knome> xnox, *last* names? :)
<xnox> touche
<knome> oh.
<knome> haha
<knome> well, that's not too bad.
<knome> it's meant "happy" anyway.
<xnox> knome: but image "dong dong" & mr. "happy" together =))))
 * Daviey afk, nn
<knome> hah
<knome> ok, at 5am i'm going to bed too
<knome> good night and congrats everybody :)
<skaet> thanks knome
<cjwatson> slangasek: point-release-snapshot> just drop the -l from the cp calls - they don't matter now that we're just copying dists
<slangasek> cjwatson: ok.  why are we now only copying dists?  that was news to me
<cjwatson> because all the pool stuff is retrievable from the librarian, and we're much better now at ensuring that it doesn't get expired
<slangasek> ah, alrighty
<cjwatson> and link-farming pool was actually making a fairly serious dent in cocoplum's disk space
<slangasek> true
<cjwatson> 9% I think
<shadeslayer> ok, so, whom should I contact if the Kubuntu downloads page needs to be updated?
<shadeslayer> it's still pointing to the old 12.04 ISO's
<slangasek> which download page do you mean?
<shadeslayer> this one http://www.kubuntu.org/getkubuntu
<slangasek> Riddell, ScottK: ^^
<shadeslayer> afaik both are away
<slangasek> yeah; I'm assuming one will be by soon
<shadeslayer> doubt it :P
<shadeslayer> ScottK is away on vacation, Riddell went off for the weekend
<slangasek> ok; I don't know who else would be able to help with that, sorry
<shadeslayer> hm
<shadeslayer> I could try and dig up the credentials login as admin to kubuntu.org
<shadeslayer> but I have no idea if I can even change that
<shadeslayer> ah yes, I haz username/pass
<shadeslayer> slangasek: yeah, I can edit, thx anyway :P
<shadeslayer> omap4 armhf link is broken as well
<shadeslayer> O_O
<shadeslayer> no Kubuntu DVD's for 12.04? :O
<smartboyhw> Been wondering: Should someone also change the topic to say that 12.04.1 being released??/
<xnox> http://releases.ubuntu.com/12.04.1/MD5SUMS-metalink is missing, yet present for 10.04
<xnox> wubi uses it =)
<xnox> Daviey is this something you can fix ^^^^
<xnox> ?
<xnox> bug 1041142
<ubot2`> Launchpad bug 1041142 in wubi "http://releases.ubuntu.com/12.04.1/MD5SUMS-metalink HTTP Error 404. Not Found" [Medium,Confirmed] https://launchpad.net/bugs/1041142
<Daviey> xnox: I should be able to..
<xnox> Daviey: ok. I wasn't sure who can do/does this.
<xnox> on 10.04 it also has the GPG signature
<xnox> =/
<Daviey> xnox: The issue is, i'm not sure /how/ to do this precisely, so i'm digging through it
<Laney> Daviey: publish-release:617 looks likely
<Daviey> Laney: no, there is a make-metalink command that looks more likely
<Daviey> :)
<Daviey> ah, that calls that
<Laney> :)
<Laney> this is just the hashes of those files afaict
<Daviey> Laney: i suspect the antics of last night deleted them by accident
<Daviey> I don
<Daviey> 't think publish-release would be wise.
<Laney> I wasn't around to witness the antics, so no clue
<Laney> I'm not suggesting to run the script, but that line demonstrates how to create the file yourself
<Laney> (it doesn't exist for 12.04 either)
<Daviey> well, $ make-metalink --help
<Daviey> Usage: /home/cdimage/bin/make-metalink BASEDIR DIST RELDIR HOST
<Daviey>  e.g.: /home/cdimage/bin/make-metalink /srv/cdimage.ubuntu.com/www/full hardy daily/20080413 cdimage.ubuntu.com
<Laney> you just need to make the MD5SUMS file though
<Daviey> Laney: hmm, well 12.04 is gone now..but it must have been there at some point
<Daviey> Laney: would you rather handle this?
<Laney> i'm as clueless as you :P
<Daviey> heh
<xnox> well MD5SUMS is present
<xnox> are release & cdimage the same?
<xnox> cause the md5sums-metalink is present on the cdimage
<xnox> http://cdimage.ubuntu.com/releases/12.04.1/release/
<xnox> but not on the releases
<Laney> no
<xnox> ok.
<Laney> there's two trees, one for cdimage and one for releases
<Laney> s/s$//
<Laney> no, s/$/s//
<Daviey> ah!
<Daviey> that does make life easier
<Daviey> hmm http://releases.ubuntu.com/precise/
<Laney> Daviey: I'll do md5sums *.metalink > MD5SUMS-metalink in the directory and sign it if you want, then you can review and sync-mirrors?
<Laney> I am fairly confident that is all we need here
<Daviey> wait
<Laney> okey dokey
<Daviey> Laney: i wanetd to check the sums
<Daviey> Seems we are now good
<Daviey> xnox: are you able to verify?
<xnox> one moment.
<Daviey> Laney: I'm thinking of making a crawler to check all these bits.
<Laney> please do; any foolproofery would be good
<xnox> Daviey: looks good to me. will notify the bug reporter.
<Daviey> thanks
<Daviey> slangasek: If i wanted to SRU a standalone NEW package for Precise, (ubuntu-cloud-keyring).. do you consider it to need a tracking bug?
<Daviey> (or any other ~ubuntu-sru ^)
<xnox> skaet: i want to have a chat with you about the installer. Do you have time today? (after release meeting, I guess if that is still going ahead)
<skaet> xnox,  after the release meeting has a window.   release meeting is going ahead.
<xnox> skaet: ok. ping me when you have time. it might take ~30min or more.
<skaet> xnox,  will do.
<xnox> skaet: thanks a lot.
<ara> skaet, ping
<slangasek> stgraber: should purging of old images be re-enabled now?
<stgraber> slangasek: oh, yes, forgot about that, will do it now
<stgraber> done
<slangasek> ta
 * slangasek blinks at today's desktop CD sizes.  What went missing?
<stgraber> old-releases was also out of sync, ara poked me about it earlier. It's syncing now
<slangasek> ok
<skaet> stgraber so the 12.04 images there now?   ara was asking.
<stgraber> skaet: kind of, they're getting there slowly ;)
<skaet> ok
<stgraber> slangasek: http://paste.ubuntu.com/1164677/ but I guess you did that already
<slangasek> stgraber: oh, so ubuntu-desktop is missing ;)
<slangasek> but in exchange, we got two copies of libmetacity-private
<ogra_> \o/
<ogra_> who needs a desktop if he has two WMs
<stgraber> slangasek: even so, the diff looks weird, that surely can't account for 120MB :)
<stgraber> so I guess the livefs must be in a pretty bad state to explain that size drop
<stgraber> half-configured/rc/... packages that would show up on manifest but not actually be installed?
<slangasek> no idea
<slangasek> however, the metacity thing is a package conflict, and could very well explain everything
<seb128> slangasek, we got the conflict resolved since, maybe it's just a matter of kick a respin?
<slangasek> could be
<gema> can you guys point me to the documented release process?
<gema> https://wiki.ubuntu.com/BetaProcess <- I found this, but no mention of respins whatsoever, I am not sure if covers also alphas and release processes
<gema> or just betas
<infinity> gema: /ReleaseProcess covers official releases.
<gema> infinity: thanks
<infinity> gema: And I'm not sure what mention you want of respins.  They're not something that's planned, or in the 12-step program, they just happen if they have to happen, and don't if they don't.
<gema> infinity: since I have been here, they've always happened
<gema> infinity: have you been at any milestone without respins?
<infinity> It's sort of like saying "You gave me directions to drive to your house, but didn't mention that I'd need to swerve to avoid the cat crossing the road".
<infinity> gema: Sure, they usually happen, but it's not something that can be planned.
<gema> infinity: you learnt to drive, right? there are rules  you need to follow if you  drive to my home :)
<gema> infinity: ack
<gema> infinity: I have been asked to suggest changes that I think may help the release process, so I am preparing an email
<gema> I will probably send it next week, since Monday is bank holiday in the uk, and I don't want to drop a bomb and run
<gema> so to speak
<skaet> slangasek,  stgraber - I've gone in to nusakan and turned the precise ubuntu dailies back on.
 * skaet --> lunch
<seb128> hey release team
<seb128> could I get https://bugs.launchpad.net/ubuntu/+source/indicator-messages/+bug/1040259 acked?
<ubot2`> Ubuntu bug 1040259 in thunderbird "FFE: libmessaging-menu transitions for quantal" [High,In progress]
<seb128> not sure what extra infos you might want for it
<balloons> any thoughts on when the images might be stabilizing again.. we've had many failures to build over the past 2 days on quantal
<ogra_> sadly thats pretty normal around freeze dates
<ogra_> everyone does his last minute uploads ... being in a ruch people make mistakes etc
<ogra_> *rush
<Laney> yesterday's across-the-board build failures were due to problems with the image creation tools themselves, not the archive per se
<Laney> and I believe everything affected was rebuilt
<balloons> ok, I think for instance the ubuntu server images still seem to be old
<ogra_> yeah, that too
<ogra_> we had a massive merge of live-build
<balloons> lubuntu and wubi as well
<Laney> that seems weird
<Laney> lubuntu/xubuntu/studio are known as I said in the meeting
<ogra_> lubuntu had a dependency issue
<ogra_> thats resolved now
<balloons> yes.. noted Laney :-)
<balloons> ohh so could they be rebuilt?
<Laney> they don't depend on gtk2 indicators any more?
<ogra_> the dep was dropped from lubuntu-meta
<Laney> i see a spin is in progress
<ogra_> i just tested a handbuilt armhf+ac100 image today
<ogra_> (lubuntu that is)
<Laney> let me try redoing server
<balloons> thanks Laney
<ogra_> balloons, http://people.canonical.com/~ubuntu-archive/cd-build-logs/ and http://people.canonical.com/~ubuntu-archive/livefs-build-logs/ might be of interest for you :)
<Laney> pretty sure he's on the CC list for the spam
<balloons> ogra_, thanks
<balloons> Laney, yes I am :-)
<balloons> but I didn't know about the web archive
<Laney> ah, tis handy to be aware of
<infinity> stgraber: ^
<stgraber> infinity: thanks!
<infinity> stgraber: Your library versioning is a bit curious (or, upstream's, I guess?), but the SOVER is sane, so whatever.
<balloons> I updated the notice board with a brief note mentioning ff and beta causing lots of unstability.. thanks for the info
<ogra_> Fri Aug 24 17:40:50 UTC 2012
<ogra_> zlib::uncompress failed, unknown error -3
<ogra_> read_block: failed to read block @0x9b899f8
<ogra_> ubuntu-server just failed again with this
<ogra_> looks a bit like a chroot issue
<infinity> Which build on which host?
<ogra_> ubuntu-server amd64
<infinity> Erm.
<infinity> The livefs build looks successful to me.
<ogra_> yep
<ogra_> i think its nusakan
<ogra_> http://paste.ubuntu.com/1164851/
<ogra_> thats the end of the log
<Laney> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/quantal/daily-20120824.log
<Laney> but yeah, that
<ogra_> yeah
<ogra_> well, i look at .1 :)
<ogra_> but same error
<Laney> that was me respinning to see if it was transient
<infinity> That's... Curious.
<ogra_> how did you respin, the mail should have your name in the subject for a manual build
<infinity> ogra_: SUDO_USER isn't always set. :P
<Laney> livefs ones do, not sure about cd
<ogra_> infinity, evil !!!
<Laney> I sudo like a person from the 2010s, so SUDO_USER is definitely set :P
<ogra_> oh, right, thats two different scripts, i might have to add the SUDO:USER bit to the other one too :)
<infinity> cdimage@nusakan:~/cdimage/log/ubuntu-server/quantal$ echo $SUDO_USER
<infinity> adconrad
<infinity> cdimage@nusakan:~/cdimage/log/ubuntu-server/quantal$ logout
<infinity> adconrad@nusakan:~$ sudo su - cdimage
<infinity> cdimage@nusakan:~$ echo $SUDO_USER
<infinity> cdimage@nusakan:~$
<ogra_> evil evil evil !
<ogra_> sudo su ... tsk
<infinity> Old habits die hard.
<ogra_> but anway, i'm sure i only added that code snippet to buildlive :)
<infinity> I had to force myself to "sudo -u cdimage -i", and still only remember it because it's in my history.
<ogra_> heh
 * ogra_ adds to his TODO
<infinity> sudo su is wildly more intuitive for someone who's been using UNIX for eons.
<infinity> Since it's basically "no, really, su harder".
<ogra_> yeah, shows mistrust in sudo :P
<infinity> Really odd that it only happens for server...
<ogra_> yep
<infinity> Maybe check-installable needs a set -x and some going over.
<ogra_>         for component in main restricted universe multiverse; do
<ogra_>                 packages="$IMAGETOP/$DIST-$fullarch/CD1/dists/$DIST/$component/binary-$arch/Packages.gz"
<infinity> But without tracing it, I'd assuming that's coming from the zcat.
<infinity> Which makes zero sense.
<ogra_> that part doesnt get executed on desktop., does it ?
<ogra_> there wont be a Packages.gz
<infinity> It will on anything with a pool, or rather, should do.
<ogra_> right
<infinity> And desktop has a small pool.
<ogra_> outside the squashfs ?
<ogra_> well, likely outside, silly qestion
<infinity> Oh, the check gets skipped on live CDs. :P
<ogra_> ogra@anubis:~/Devel/branches/nusakan/cdimage-deployment$ grep installability /tmp/daily-live-20120824.log
<ogra_> ogra@anubis:~/Devel/branches/nusakan/cdimage-deployment$
<ogra_> yeah
<Laney> do we compress with lzma?
<ogra_> i dont thik we do
<Laney> if so, I just googled up http://paste.ubuntu.com/1164863/
<ogra_> breaks rsyncability i think
<ogra_> i guess we wont get around a set -x
<infinity> Laney: We're SUPPOSED to be using gzip, for the reason ogra mentioned, but we may have accidentally switched in the merge.
<ogra_> yeah
<ogra_> that might be indeed
<infinity> Would also account for some of the magical shrinking of the desktop CD...
<Laney> oops
<ogra_> oh, yeah
<ogra_> though why wouldnt it happen on desktop too ?
<Laney> infinity just said that the check is skipped
<ogra_> oh, because the whole thing is skipped, indeed
<infinity> Anyhow, it would be nice to have a newer squashfs-tools on nusakan, but in this case, I'm glad we don't.,
<infinity> I'll hunt this down and fix it, since Colin has the good sense to go on vacation.
<infinity> s/has/had/
 * infinity fires up the local livefs buildd for great justice and fiddling.
<stgraber> really unfortunate that rsync can't work with lzma, seeing that it'd save around 100MB...
<infinity> stgraber: There's nothing stopping someone from a conceptual port of gzip --rsycnable to lzma and xz.
<infinity> But, y'know, spelled correctly.
<slangasek> right, except for the fact that you stand a good chance of an xz --rsyncable not actually being better than gzip --rsyncable
 * ogra_ likes it better with the typo 
<infinity> stgraber: The idea is easily ported to any compressor, really.
<infinity> slangasek: Well, if xz performs better than gzip on 4M chunks (and it seems it does), then you just chops your xz streams into 4M chunks and give it a whirl.  Repeat for smaller chunk sizes until you get a nice balance of reduced rsync traffic and not too much archive bloat?  I dunno.
<infinity> Not that this is me volunteering to even care.
<infinity> And yeah, at the end of the day, you may lose most of that 100MB you gained.
<ogra_> but but .. you seem to have a plan already !
<ogra_> :)
<infinity> Especially given that modern compressors rely heavily on massive dictionaries, and a naive rsyncable implementation could mean a lot of duplicated dictionary data.
<infinity> So, it could take some real thought, actually, to fix THAT part.
<infinity> Maybe we should all just switch back to .Z
 * ogra_ was always scared by capitalized suffixes
<slangasek> I wonder if there are any scripts to mock up a dpkg/apt environment using an apt-clone file, without having to actually install all the packages
<slangasek> bug #1040002 is a horror to reproduce the normal way.... I don't even know how many GB of disk I need in a VM to get all those packages installed, but I have an idea how long it would take :P
<ubot2`> Launchpad bug 1040002 in update-manager "lucid upgrade to precise amd64 universe failed: E:Error, pkgProblemResolver::Resolve generated breaks" [Medium,Incomplete] https://launchpad.net/bugs/1040002
<Daviey> slangasek: I saw words.. but what i saw was.. "I want to do this in the cloud"
<slangasek> Daviey: no, I really don't
<slangasek> I want it to be fast, not take all day for each iteration
<slangasek> a cloud isn't going to make it notably faster :)
<Daviey> slangasek: well, looking at the failures.. it seems to happen really qickly https://jenkins.qa.ubuntu.com/view/Precise/view/Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-universe/ARCH=amd64,LTS=lts,PROFILE=universe,label=upgrade-test/buildTimeTrend
<slangasek> hmm, so it does
<slangasek> I presume that means jenkins has a snapshot image that it uses, that has all the universe packages pre-installed
<slangasek> ... that also shows that the error has cleared itself, so I guess I don't need to worry about reproducing it anyway
<slangasek> Daviey: so, thanks ;)
<Daviey> not quite, cloud 1 legacy 0 .. but i can imagine that as accurate
<xnox> infinity: thanks for accepting sphinxsearch, so maybe now we can deploy geonames-lookup.ubuntu.com with actually packaged & supported software ;-)
<popey> seems that System Settings -> Details doesn't reflect the fact that a user system is 12.04.1, but shows 12.04.
<popey> bug bug 1041369
<ubot2`> Launchpad bug 1041369 in gnome-control-center "System Settings -> Details doesn't match lsb_release -a" [Undecided,New] https://launchpad.net/bugs/1041369
<xnox> Daviey: yeah, got verification Wubi works against the metalink you created =)
<Daviey> xnox: super, thanks
<xnox> Daviey: thank you ;-)
#ubuntu-release 2012-08-25
<slangasek> infinity, stgraber: there haven't been any further reports of 1017001 since flipping the switch, that I can see; it seems it may truly have been specific to users doing strange things like running mythbuntu 10.04 without updates applied.  I think we can take it off our worry list now.
<stgraber> well, that's very good news
<infinity> slangasek: See, and I was just about to say that I ran into it in production.
<infinity> slangasek: And the only solution here was to install the upstart interdependant mess before proceding with the rest.
<infinity> slangasek: That's a pretty big update-manager change, but I wonder if it wouldn't just be the right thing to do. :/
<infinity> It's a short list: upstart initramfs-tools initramfs-tools-bin udev initscripts ifupdown mountall plymouth
<infinity> Upgrading those first seems to make the rest of the process a bit more resilient.
<infinity> (And yeah, I literally JUST ran into this on my powerpc/lucid machine when I upgraded it to precise, and it wasn't mythbuntu)
<infinity> It was, however, a debootstrap + ubuntu-desktop by-hand install, not something from lucid media.
<stgraber> and I guess in your case, was fully up to date before the dist-upgrade
<infinity> stgraber: Yeah, I updated it to -updates before doing the upgrade, cause I didn't want problems. :P
<infinity> All of those packages are Priority:required, so it wouldn't (in theory) do any harm to just force an install of all of them before the rest of the upgrade.
<infinity> Given that if they're not installed, we really think they should be.
<xnox> infinity: does this mean your powerpc machine is now back alive and operational?
 * xnox \0/
<infinity> xnox: My PowerStation is on and being a wind-tunnel again.
<infinity> xnox: It's not my only PPC machine. :P
<xnox> =)))))) nice
<xnox> show off
 * jocarter wonders if infinity, xnox and stgraber ever stop working
<stgraber> infinity: I can't remember if the dist-upgrader actually has a feature to force a given list of packages to upgrade before doing the main upgrade
<infinity> jocarter: For about 28 minutes on Thursday afternoons.
<infinity> stgraber: I'm not sure either, though it seems like a sane thing to be able to do to influence things a bit.
<stgraber> infinity: I know it has a list of packages to ensure are installed post-upgrade and a list of stuff to cleanup
<jocarter> infinity: heh
<stgraber> agreed, if it doesn't support it, it should
<xnox> jocarter: i'm not working. i'm just breaking archive by uploading incompatible versions of mumble ;-)
<stgraber> jocarter: well, at least for me there's a pretty big difference between talking in #ubuntu-release and working ;)
<stgraber> xnox: bah, who uses quantal anyway? :)
<infinity> stgraber: Hrm, there's [PreRequists](sic) in the .cfg, but that's to install from $old_release, not $new_release.
<stgraber> infinity: I also suppose we want the dist-upgrader to use the backported apt to install these packages?
<infinity> stgraber: Possibly.  They'll end up depending on a newer dpkg and libc anyway, I imagine.  I'm not sure apt itself matters much for such a small set.
<infinity> stgraber: But, since the whole thing operates with the release-upgrader-python-apt, the point seems moot.
<infinity> stgraber: Oh, hrm.  Prereqs is actually entirely unclever.  It just uses a separate sources.list and then installs what you asked for.  I wonder if we couldn't just call back into that exact same method for a PreInstall or something that runs between PreReq and Upgrade.
<infinity> Or UpgradeFirst might be a better name for it, so it's obvious it's something you can't go back from.
<infinity> But whatever.
<infinity> Still, this is all a pretty huge potential change for code that's been heavily tested without it. :/
<infinity> And we have exactly one reliable reproducer for the bug, which is about as helpful as using a puppy as a television remote control.
<xnox> don't be cruel to animals!
<infinity> Don't worry, the puppy thinks it's a fun game.  The only harm done is to your sanity when the channel doesn't change, no matter how you rub his tummy.
 * xnox =)
<xnox> infinity: i think you should be on Ubuntu TV design team =)
<xnox> and fix puppy remotes onces and for all!
 * infinity reboots to finish the upgrade and crosses his fingers.
<infinity> Hrm.  "Not a valid ELF image".
<infinity> Thanks, yaboot.
<infinity> That's probably my fault, though.  Cobbled-together cross-grade from YDL to Debian to Ubuntu.
<xnox> it's sad to see installs outliving distributions
<infinity> Ouch, and the old kernel explodes with udev having a sad.
<infinity> *sigh*
<infinity> This'll be fun to recover.
<infinity> For some value of "fun" that involves a Debian CD and some luck.
<infinity> Ah-ha, just needed a newer version of yaboot.
<infinity> The upgrade really should update that. :/
<infinity> Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-29-powerpc64-smp ppc64)
<infinity> I win!
<infinity> Well, I kinda win.  If X wasn't now spinning at 100% and not drawing pretty pictures...
<slangasek> infinity: oh, huh.  was it on a fully-updated system?
<slangasek> ah, you say it was
<infinity> ioctl(7, 0x20006444, 0)                 = -1 EBUSY (Device or resource busy)
<infinity> Really, X?  That's a spiffy infinity loop.
<infinity> infinite, too.
<infinity> Seems my nick has broken my ability to type "infinite".
<infinity> Oh hey, finally.
<infinity> Oh, armel is still building.  Drat.
<infinity> Nobody worry about that linux build in quantal-proposed, I've got a d-i upload queued later to go with it.
<phillw> hot off the press bug 1041532
<ubot2`> Launchpad bug 1041532 in ubiquity "A update process in Ubiquity caused it to crash" [Undecided,New] https://launchpad.net/bugs/1041532
<smartboyhw> Hi. Did phillw give you the bug that I just reported?
<phillw> smartboyhw: yes I did
<smartboyhw> Thanks phillw
<phillw> any release team still awake?
<phillw> I've suggested Ubiquity... http://pastebin.com/Z0wCgj0B
<tumbleweed> the fontocnfig warning is benign
<phillw> tumbleweed: so, what more data do you guys need?
<tumbleweed> no idea wthat the problem is, but this isn't really a support channel
<phillw> he he.. it is the release channel, and this is a 12.10 issue :P
<tumbleweed> #ubuntu+1
<phillw> okies, I'll head there, thanks
<xnox> tumbleweed: known problem new fontconfig became too 'chatty' and picky what it believes are sane font configs shipped with fonts, mostly harmless.
<tumbleweed> yeah. doesn't stop machines from booting, though
<xnox> tumbleweed: yeah, but rather annoying to see them on every application launch from the terminal
<tumbleweed> that's presumably a broken X of some sort
#ubuntu-release 2012-08-26
<Laney> ===== Triggering mirrors =====
<Laney> Sun Aug 26 09:55:43 UTC 2012
<Laney> .manifest has nonexisting /precise/ubuntu-12.04-alternate-amd64.iso
<Laney> what's this?
<Laney> also, can we update P-a-s in lp:~ubuntu-core-dev/packages-arch-specific/ubuntu
<Laney> ?
<stgraber> Laney: oh, that one would be my bad... let me manually cleanup the manifest
<stgraber> should be fixed now
<stgraber> forgot to remove them from the manifest after archiving to old-releases
<Laney> stgraber: thanks
<xnox> infinity: thanks for removing those ;-) finally!
<phillw> stgraber: when ever you have a spare 5 mins, give me a ping
<xnox> Do we respin / release new images for non-LTS releases? E.g. make a point release?
<stgraber> no
<xnox> ok.
<xnox> Laney: request for new version / bug-fix backport. I am not confident about attached patches. Would you merge new point release? bug 973014
<ubot2`> Launchpad bug 973014 in gst-plugins-bad0.10 "gstreamer0.10-plugins-bad, (libgstvideoparsersbad.so), causes a failure to decode many common video files encoded as AVC 1 Baseline - L2.1, Baseline - L1.1 & others" [Undecided,Confirmed] https://launchpad.net/bugs/973014
<Laney> xnox: Seems reasonable on the face of it. Bake it in a PPA for a week or so to get the people moaning on that bug to test and then get your FFe. Maybe ask slomo if he has an opinion too.
<xnox> Laney: I never touched gstreamer, and you seem like somebody who does know a bit about it.
 * xnox is fighting with hundeds of ubiquity bugs in the mean time...
<Laney> not really, I just did some stuff distro like
#ubuntu-release 2013-08-19
<jamespage> Daviey, ^^ backported dkms/module-assistant packages for openvswitch with 3.8 kernel for 12.04.3 as discussed last week
<jamespage> Daviey, includes DEP-8 tests for both packages...:-)
<knome> infinity, hey, you around? :)
<Daviey> jamespage: Super!  Will look shortly, thanks
<jamespage> Daviey, thanks
<sil2100> stgraber: hi! Do you have a moment to NEW a package from the queue? ;)
<sil2100> stgraber: the mediascanner package is needed in the archive by our developers, which want to push some additional packages that depend on it
<smartboyhw> Ubuntu Release Team: Any solutions to solve the consecutively failing Ubuntu Studio saucy images?
<ScottK> smartboyhw: Why are they failing?
<smartboyhw> ScottK, package conflicts
<ScottK> Then fix the conflicts.
 * smartboyhw is not familiar with the failing packages..
<ScottK> The release team doesn't have any magical powers with regard to fixing packages.
<infinity> knome: Am now.
<knome> infinity, hey!
<knome> infinity, an SRU question... we have 1207493
<knome> bug 1207493
<ubot2`> Launchpad bug 1207493 in xubuntu-docs (Ubuntu) "[SRU] Documentation does not match shipped system version (11.10 shipped with 12.04)" [High,Confirmed] https://launchpad.net/bugs/1207493
<knome> infinity, it hasn't been uploaded (yet :() and i was wondering if there was any possibility you could make an exception to the 7-day rule with this documentation package.
<knome> infinity, as you can see, the bug and docs have been ready for some time already, but for a reason or another our uploaders didn't get to upload it by last thu.
<infinity> knome: That's a pretty massive diff.  Was the wholesale backport really necessary?
<knome> infinity, the old documentation is from 2010 or something
<knome> infinity, yes, it's a complete rewrite but it's so much more accurate and fluent that we'd really like to get that in the LTS
<infinity> knome: So, I can already spot one bug in this being a backport.
<infinity> +  * debian/preinst: Dropped, not needed after 12.04 LTS
<knome> okay, we can fix that :)
<knome> skellat, ping ^
<knome> infinity, my main question is that is it worth the hassle now to do these fixes: is it possible to get it in .3?
<infinity> knome: Given that it's "just docs", I'm okay with being fairly loose on the rules here, expecially if the previous ones were essentially useless.  But definitely don't drop any transitional stuff needed (like that preinst)
<knome> sure, i'll make sure that's fixed ASAP :)
<knome> (the other argument is that it only concerns xubuntu...)
<infinity> knome: If you guys get it uploaded, we'll see.  It's not world-ending if it misses the .3 images, though, as it'd be in the archive shortly after.
<infinity> knome: I'm happy to help massage it through if it appears bug-free, though.
<knome> sure, but i'm sure you understand why we want it for .3 (we even did the whole re-rewrite to be accurate for 12.04 in a relatively short time just for .3)
<infinity> knome: *nod*... Get it uploaded (with the preinst thing fixed), and we'll talk. :)
<knome> yep, i'll do that. thanks!
<infinity> knome: We can probably push it through in a day or so, if you promise a bunch of people will install it from proposed, make sure it's not broken, browse the docs a bit, whatever.  However you test words.
<knome> definitely.
<infinity> "Yeahp, those sure look like words".
<knome> heh :)
<sil2100> infinity: hi!
<infinity> sil2100: 'sup?
<infinity> sil2100: mediascanner?
<sil2100> infinity: are you also doing some SRU stuff? Since I need some validation of some old SRU bug - if it sounds SRUable ;)
<sil2100> Since the upstream developer is poking me already since long long what's the status
<sil2100> https://bugs.launchpad.net/unity/+bug/1043627
<ubot2`> Launchpad bug 1043627 in nux (Ubuntu Raring) "[SRU] Add XIM Support to Nux" [Undecided,Confirmed]
<sil2100> infinity: mediascanner got in btw. but thanks for asking ;)
<infinity> sil2100: Ahh, the Xim thing.  Do you have a patch you can attach to the bug too, so we can have a look at how painfully intrusive it looks?
<infinity> sil2100: I'm not opposed to the Xim thing in theory, and it *sounds* like it should be isolated enough to not break other bits if it sucks, but a diff would be nice.
<infinity> sil2100: Oh, hah.  Yeah, mediascanner got in but, in a hilarious twist, it builds on arm/powerpc, but not amd64/i386. :P
<infinity> That's got to be a first.
<sil2100> Ohshit
<sil2100> Maybe the unittests are failing?
<infinity> Yeahp.
<sil2100> Probably a rebuild should work, since those seem flacky ;/ But I thought they disabled the flacky ones
<sil2100> Sucks
<sil2100> infinity: I'll try finding a diff to attach
<infinity> sil2100: I'll give a rebuild a try.  But if it was developed on ARM, you could be the first people ever to have inverse signed char issues? :)
<sil2100> infinity: attached
<sil2100> infinity: (the branches are attached to the bug btw. but diffs might be easily readable for others)
<infinity> sil2100: mediascanner had testsuite hate on the second go too.  You might just want to look into fixing it. :)
 * sil2100 sighs
<sil2100> Let me inform upstream
<sil2100> The sad thing is that PPA's didn't have any problems, local builds too ;)
<plars> slangasek: when do you expect we'll have candidate images for 12.04.3?
<slangasek> plars: heya - was going to talk to you today about this.  I expect it's going to be first thing tomorrow
<plars> slangasek: sounds good :)
<slangasek> which given my failure to coordinate with certification up 'til now, I'm not sure means we'll have a release ready to go by Thursday
<slangasek> but if that timeline is still ok on the QA side, we can still shoot for it
<plars> slangasek: 2 days isn't a lot, and depending on when the image posts, it may be only 1 day or 1.5 days for psivaa who is in the UK, but we'll do what we can as quickly as possible
<slangasek> plars: ack
<slangasek> if we need an extra day, a Friday release should still be fine
<infinity> plars: BTW, I'm letting that precise/omap4 kernel through, despite the QA failure on it, just to clear out the CVE backlog.
<infinity> plars: Hopefully people will still look into the test failures.
<hggdh> phillw: done
<hggdh> bah, wrong channel
<phillw> hggdh: close enough :P
#ubuntu-release 2013-08-20
<ScottK> Looks like nodejs can be synced.  That would fix installability of node-resolve.
<ScottK> Oops, wrong channel.
<smartboyhw> Release Team: When will 12.04.3 builds start appearing in http://iso.qa.ubuntu.com/qatracker ?
<stgraber> slangasek: heya. I'm about to jump on a plane and disappear for 9 hours or so. I created the 12.04.3 milestone on the ISO tracker and checked that nusakan is properly configured for it (first auto-publish + self-rebuild milestone for precise)
<stgraber> slangasek: everything looks good, so once you're ready and have cron turned off, go to http://iso.qa.ubuntu.com/admin/config/services/qatracker/milestones/301/edit and tick "Automatically publish builds listed in the series manifest", then save the milestone
<stgraber> slangasek: from that point on, any build being pushed to the tracker for precise which is listed on http://iso.qa.ubuntu.com/admin/config/services/qatracker/series/1/manifest will automatically show up as part of 12.04.3
<stgraber> slangasek: I'm currently planning on setting up the paperwork (release notes + announcement) tomorrow (wednesday) morning. If you think we should have those earlier, ping me and I'll try to get them done when I arrive home
<infinity> slangasek: -proposed kernels all pushed to -updates, and the matching d-i has been released too.
<bdmurray> Could somebody approve libgksu2-0 in the raring -proposed queue for me?
<slangasek> bdmurray: accepted
<slangasek> infinity: ping
<infinity> slangasek: pong. :P
<slangasek> infinity: pacman
<infinity> slangasek: Ms PacMan was way better.
<slangasek> plars: finally got everything in order, first candidate images should be rolling off the line within the hour
<slangasek> infinity: oh, I didn't copy pciutils over before I started; I don't think that's worth stopping for now fwiw
<infinity> slangasek: Yeah, no pciutils should be fine.  PCI DBs are a purely cosmetic thing anyway.
<infinity> (Though it makes the ISO less pleasant as a debugging tool, but that's a bit of a *shrug*)
<infinity> rtg: *poke*
<rtg> infinity, ?
<rtg> pciutils ?
<infinity> rtg: I noticed that intel-microcode SRU of yours claims (at least, according to upstream) to be a scurity fix.  Can you coordinate with mdeslaur or someone to make that happen as a security release instead of an SRU?
<infinity> rtg: And I'll reject the SRUs.
<infinity> mdeslaur: ^
<rtg> infinity, there was no CVE allocated, plus its a multiverse package. is it really worth it ?
<infinity> rtg: I'd rather not push security fixes only to -updates, personally.  Even for weird multiverse thingees.
<slangasek> plars: alternate images already available now
<infinity> jdstrand, mdeslaur: Opinions?
<mdeslaur> do we have any idea what the "important security fix" is in that?
<plars> slangasek: awesome, thanks for the heads up
<plars> psivaa: ^
<rtg> infinity, mdeslaur: there is no changelog on the ucode download page
<infinity> mdeslaur: You missed "very".  A "very important security fix".  Whatever that means. :P
<plars> slangasek: according to http://iso.qa.ubuntu.com/qatracker/milestones/301/builds/51817/testcases - the alternate images are oversized
<slangasek> plars: nominally; we've agreed to raise the limit rather than try to get them back down to CD size, as that's a lost battle
<mdeslaur> infinity: oh! that's changes _everything_ :)
<mdeslaur> sarnold: could you please handle rtg 's packages ^
<sarnold> mdeslaur: yes
<infinity> rtg: ^-- That would have been rejected anyway, due to the version clash.
<infinity> sarnold: Bug's https://bugs.launchpad.net/intel/+bug/1212497
<ubot2`> Launchpad bug 1212497 in intel "[Feature] update microcode to 20130807 version" [High,New]
<sarnold> rtg: can you provide me with the debdiffs? that's my easiest way forward :)
<sarnold> thanks infinity
<infinity> sarnold: debdiffs of binary blobs don't end well.
<sarnold> infinity: ah. makes sense.
<rtg> sarnold, infinity: so I'm a little confused here. what do you want done with those uploades  (aside from fixing the quantal version) ?
<infinity> rtg: Just hand them to sarnold and let him sort it through the kernel PPA and release them.
<sarnold> rtg: I'd like to rebuild the packages in the security ppa and unembargo them through the usual process
<infinity> Err... The security PPA.
<infinity> I can't brain this morning.  Need sugar.
<rtg> sarnold, ok, lemme get them prepped.
<sarnold> rtg: thanks
<infinity> sarnold, rtg: Thanks.
<infinity> slangasek: Bleh, yeah, the whole world is still a tiny bit oversized.  Did we reach a conclusion on carefactor there?
<slangasek> infinity: pretty sure the consensus was to accept defeat on this front
 * infinity nods.
<infinity> slangasek: We could drop unity from the images instead.
<infinity> Anyone who needs more than glibc, gcc, and perl is probably using their computer wrong anyway.
<slangasek> we could drop acid instead; both are about as helpful for getting us to a point release
<infinity> slangasek: I suppose if we were going to accept defeat, we could have added some langpacks back, but oh well.  There's always .4
<rtg> sarnold, http://kernel.ubuntu.com/~rtg/intel-microcode for p/q/r
<sarnold> rtg: thanks
<rtg> sarlemme know if I've borked the versions
<rtg> sarnold, ^^ (damn tab completion)
<bdmurray> infinity: how was the linux update in raring released?
<bdmurray> infinity: I mean with what tool?
<infinity> bdmurray: With sru-release, hacked up to remove the bug twiddling because of races.  We need to sort that. :/
<infinity> bdmurray: With copies being much (MUCH) faster now, the bug twiddling collides with launchpad's auto-closures and sru-release backtraces itself into oblivion, so I've had to do that.
<infinity> bdmurray: (I assume the complaint is that I didn't unsub all the teams, as the tool would have done)
<bdmurray> infinity: okay, well the phased-update-percentage was set (I have a fix for that) but you want to use change-override to set it to 100% in -updates
<infinity> bdmurray: Oh.  This is about PUP?  Check.  Is that meant to be set by tools or by LP?
<infinity> I may be a bit out of date on my u-a-t branch.
<infinity> Ahh, no.  No changes to sru-release.
<bdmurray> infinity: I meant I'm working on the fix right now, mp forthcoming
<infinity> bdmurray: Is the intent to have sru-release do it, or LP do it?  Having it happen in the copy seems saner and less racy.
<bdmurray> sru-release sets it initially to 10% but should for security updates
<infinity> s/should/shouldn't/
<bdmurray> er should not
<bdmurray> right
<infinity> bdmurray: Will that be wrong in both pockets?
 * infinity looks.
<bdmurray> no
<bdmurray> https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/no-phase-security/+merge/181129
<infinity> Ahh, no.  It's 100 in security, so at least people are getting their updates.  Just from a poor, overloaded server.
 * infinity overrides the world.
<infinity> bdmurray: I assume dep resolution works fine if something at 100% depends on something at 10%?
<infinity> (Not that I'm creating that situation, just curious)
<bdmurray> infinity: that's my understanding
<infinity> Alright, linux, linux-ppc, linux-lowlatency, and matching signed/meta stuff all bumped to 100%
<bdmurray> thanks
<infinity> We do need to have a bit of a think about the bug twiddling races.  Very annoying to have to noop that part of the tool right now.
<infinity> Exponential backoff, I suppose.
<plars> stgraber, slangasek: https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/1214563
<ubot2`> Launchpad bug 1214563 in ltsp (Ubuntu) "ltsp-client-builder: Unable to locate package linux-image-generic-lts-quantal" [Undecided,New]
<slangasek> plars: well then!
<slangasek> how about I fix that
<plars> slangasek: sounds good :)
<plars> slangasek: on the plus side, all the other tests I had been doing on alternate looked good so far
<slangasek> cool
<slangasek> so interestingly, wherever the lts-quantal bit lives, it's not in the ltsp source itself
<slangasek> stgraber: ^^ home yet?  Do you know what we've missed wrt ltsp and enablement stacks?
<stgraber> slangasek: just arrived in Canada but not quite home yet (on my phone). IIRC there's a patch in debian/patches for lts kernels in the precise LTSP source. Extending this to cover the new backport stack should be enough.
<stgraber> slangasek: if you don't have the time to look at it, I should be able to do it in 2-3 hours
<slangasek> stgraber: oh... I saw there was no branch for precise-updates and assumed that meant there was no package either, wah :(
<slangasek> stgraber: ok, I've got it then
<slangasek> infinity, stgraber: ^^ please review/accept ltsp
<bdmurray> slangasek: could you merge https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/no-phase-security/+merge/181129?
<slangasek> bdmurray: done
<infinity> 2> /dev/null > /dev/null
<infinity> Curious construct.
<infinity> slangasek: That patch looks a bit fragile and strangely non-deterministic, but I guess you didn't make it any worse than it already was.
<slangasek> infinity: thanks; I'll respin {k,x,}ubuntu alternates + kubuntu dvd + ubuntu-server once that publishes
<slangasek> oh, except we've already disabled -proposed
<slangasek> infinity: how would you like to play this?  test rebuild with -proposed, or slam it straight into -updates?
<infinity> slangasek: Let me give it a better review (like, a second set of eyes grepping the whole source package), but if it's as obviously correct as it looks, slamming it straight into updates seems fine.
<infinity> slangasek: Yeah, that looks Obviously Correct(tm) to me on a review of the full source.  I say we just let it build and release it.
<slangasek> okie
<infinity> slangasek: iz copied.
<slangasek> infinity: ta
<infinity> slangasek: And now published to ftpmaster.
<slangasek> infinity: and wait-for-package trigger set
<slangasek> plars: 12.04.3 ubuntu/alternate respin imminent
<plars> slangasek: ok
<plars> hmm, server too
<plars> ok
#ubuntu-release 2013-08-21
<seb128> infinity, hey
<seb128> infinity, maybe you can help me ;-)
<seb128> infinity, https://launchpad.net/ubuntu/+source/signon-ui ... do you know how Colin got 0.15daily13.06.12-0ubuntu1 in saucy release?
<seb128> infinity, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html complains about  "out of date on powerpc: signon-ui (from 0.14-0ubuntu2)"
<seb128> infinity, I could delete the binary but the fact that it's still there suggest Colin forced it another way for the previous upload?
<infinity> Lemme look.
<seb128> thanks
<infinity> Looks like Colin forced it.  Naughty.  I'll see about cleaning up a bit more pleasantly.
<seb128> infinity, thanks
<seb128> infinity, good luck, I think the reason Colin forced it was because it was non trivial to clean up nicely
<Laney> he said he wanted to see what it made uninstallable
<infinity> Yeah, it looks like it has no rdeps (anymore) on powerpc.
<infinity> But I'll double-check this harder before I go breaking anything.
<Laney> I thought seb128 said he deleted the ppc binaries yesterday
<infinity> Should migrate in the next run.
<seb128> Laney, signon-plugin-oauth2 and signond I removed
<seb128> Laney, not signon-ui itself
<Laney> ah
<seb128> Laney, sorry if there was a misunderstanding
<Laney> np
<seb128> infinity, Laney: thanks
<infinity> seb128: Erm, deleting the signon PPC binaries isn't clever, unless you also make it stop building on PPC, cause they'll just come back.
<seb128> infinity, I think I just misunderstood what Laney said when he listed the rdepends/recommends, I though I needed to delete those 2 to have signon-ui move to release
<infinity> seb128: Yeah, it's all cleaned up now.
<infinity> seb128: But please get the signon source package to stop being arch:any (or make it fail early in debian/rules on !x86 !arm)
<infinity> seb128: I'd almost prefer the failure thing, as it's easier to track if we ever get a Qt5 that supports more than 2.5 arches, but meh.
<seb128> infinity, right, I'm going to talk to Ken about that
<infinity> (Or make it needlessly build-dep on qt5-declarative, which makes it happily just dep-wait forever)
<infinity> All the debian/control arch hacks we've been doing will be awful to unwind (or add new arches to). :/
<infinity> Build-deps on the missing qt5 bits would have been much more elegant.
<infinity> And I don't think it's too hideous to build-dep on your runtime deps for this purpose.
<infinity> seb128: Aaaand, fixed a little harder.  Should go on the next cycle. :P
<seb128> infinity, thanks!
<xnox> infinity: debian started boost1.54 transition, but i'd want to hold that transition off until next cycle. And deffo out of main.
<ScottK> If someone will kick ^^^ out of New, that'll get it and two other perl modules to migrate.
<stgraber> ScottK: I'll take a look
<stgraber> does anyone know what was used to generate https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/ChangeSummary/12.04.2 ?
<stgraber> slangasek: I'm done setting up https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes for 12.04.3 (moved all the existing ones to -12.04.2 and added all the needed links, updated includes, ...)
<stgraber> I just need to ping IS to get https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop changed as it's currently immutable...
<stgraber> the common wiki page is: https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/CommonInfrastructure
<stgraber> and updated the section about the backport kernel to cover the new 3.8 and lts-raring enablement stack
 * xnox ponders if www.ubuntu.com is also ready for 12.04.3, as it started to encode point-release number on download pages et. al. pinged Peter about it.
<stgraber> announcement draft: http://pad.ubuntu.com/ubuntu-12-04-3-announce
<stgraber> flavors: please make sure the links on the wiki and on the announcement are correct, if not, let me know or just edit in place
<stgraber> Riddell, ScottK, highvoltage, superm1, zequence: ^ (wiki pages for your release notes, download links and announcement URLs)
<highvoltage> merci
<smartboyhw> stgraber, working on the Ubuntu Studio ones...
<Riddell> gotit
 * stgraber adds the usual upgrade products
<xnox> stgraber: does wubi need a bump .2 -> .3, upload and sign?
<stgraber> xnox: that's a good question
 * smartboyhw deletes the Ubuntu Studio upgrade 12.04.3 ones
<stgraber> ah yeah, I should remove all those that weren't LTS before 12.04
<stgraber> ah, actually they can pretty much all go as 10.04 desktop is no longer supported
<stgraber> so only ubuntu server needs lts-to-lts upgrade testing
 * stgraber cleans up
<stgraber> xnox: so I'm not sure, it looks like we've been building wubi images lately, so maybe we should update wubi. I'd prefer to wait for slangasek to show up (any minute now) though.
<stgraber> xnox: either way, I suspect we'll need a respin, either to get a new wubi to work with .3 or to get rid of wubi
<slangasek> I asked ev to look at wubi, I wasn't sure if the point release instructions were still current
<slangasek> xnox: do you know the answer?
<slangasek> do we need a wubi respin?
<slangasek> ... and if so, can you please take care of it (asap)?
<xnox> slangasek: as in, wubi will try to download 12.04.2 metalink & .iso, when executed stand-alone, which I believe will error-out ones we release 12.04.3.
<xnox> slangasek: so last time around metalinks got updated.
<superm1> stgraber: all set
<stgraber> slangasek: oh, and do we care about the world being oversized?
<slangasek> stgraber: no
<stgraber> ok
<slangasek> xnox: what does updating metalinks mean?  is that a wubi rebuild, or what?
<smartboyhw> stgraber, I have changed the link for Ubuntu Studio release announcement
<xnox> slangasek: yeah, sed -i "s/12.04.2/12.04.3/g" * in the wubi/precise branch. Rebuild, scp to ~ubuntu-archive, sign by is, symlink update to "release"
<slangasek> xnox: can you take care of building?
<xnox> slangasek: ok after the meeting
<slangasek> xnox: thanks
<plars> slangasek: are we missing anything? Are there going to be netboot images?
<stgraber> plars: http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-amd64/20101020ubuntu136.13/images/raring-netboot/
<stgraber> plars: http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-i386/20101020ubuntu136.13/images/raring-netboot/
<plars> stgraber: I hadn't seen them show up on the iso tracker
<stgraber> plars: I just added them on it now, but the links will be wrong (should point to those I listed above or you won't get the enablement kernels)
<plars> stgraber: ok, thanks
<knome> infinity, looks like i can't grab an uploader soon enough for the docs SRU. i'm sorry for bothering you - i think you agree it's definitely too late now.
<infinity> knome: Probably too late, yeah, but don't let that stop you from getting it uploaded. :)
<infinity> knome: You might want to just ask to have it added to your packageset so you can upload yourself.
<knome> infinity, "my" packageset? :)
<knome> i personally do not understand enough about packaging.
<knome> or at least, i won't confess i do... :)
<infinity> knome: Oh, heh.  For some reason, I thought you had PPU rights to the xubuntu packageset.  Clearly not.  I blame my having been awake for only 50m this morning.
<knome> nah, i don't, and that's not my goal. we need more people who have, though... and no problem :)
 * knome pours infinity some coffee
<sil2100> Core-dev needed!
<sil2100> http://10.97.0.1:8080/view/cu2d/view/Head/view/Platform/job/cu2d-platform-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_qtubuntu_0.52+13.10.20130821-0ubuntu1.diff <- could any core dev ACK this packaging change for me?
<sil2100> ogra_: ? ^ ;)
<sil2100> infinity: ^ ;)
<ScottK> sil2100: That's not a release team issue.  Please use #ubuntu-devel.
<sil2100> ScottK: k
<bdmurray> slangasek: what do you think about linking to an error report (to watch for it not occuring in the new version) in an SRU bug instead of a test case?
<infinity> bdmurray: If it's so hard to reproduce that errors is about the only way to know if you've fixed the bug, I guess that's fine.
<slangasek> bdmurray: I think that's a thing I've done before :)
<infinity> bdmurray: But a testcase is always better, if one can be cooked up.
<bdmurray> infinity: I tried a bit.
<infinity> (Well, assuming the testcase is a valid reduction of the bug, and not some fabrication that tests the wrong thing :P)
<bdmurray> and the patch is one line
<bdmurray> -                except (IOError, zlib.error) as e:
<bdmurray> +                except (IOError, EOFError, zlib.error) as e:
 * infinity nods.
<infinity> This whole "use errors to track progressions" thing will fail if the people who want -proposed to be NotAutomatic win.
<infinity> Cause then no one will install the proposed versions except, maybe, the one guy who reported the LP bug.
<bdmurray> infinity: which people?
<infinity> You know.  "people".
<infinity> It's come up a few times. :P
<slangasek> people like me :)
<slangasek> but yeah, we can't have it both ways on this one
<slangasek> OTOH, NotAutomatic+ errors + phased-updates, maybe for those cases we just make sure it builds and installs and then throw it straight to -updates
<infinity> (Those cases should be very, very rare, I'm not sure we want to model the archive usage after the corner case)
<infinity> Unless you're suggesting that's how all SRUs should eventually go, which could perhaps be a tenable position when phased-updates proves its mettle.
<pkern> canaries ftw :)
<slangasek> infinity: I'm saying that -proposed should be noautomatic in its own right, and if one of the consequences is that we don't have enough data in errors to know if certain bugs are fixed in -proposed, then we have enough safeguards in place that we shouldn't be afraid to push it out to -updates
<xnox> "autopkgtest for ubiquity 2.15.14: RUNNING (Jenkins: public, private)" but it finished an hour ago.... is that normal?
<xnox> no like at 19:10 the first time.
#ubuntu-release 2013-08-22
<phillw> when bdmurray is away all the bug team scarper... :D
<infinity> superm1: Is anyone doing 12.04.3 testing for mythbuntu?
<infinity> Riddell: Kubuntu 12.04.3 testing seems a bit light.
<infinity> knome: Are Xubuntu 12.04.3 alternates being tested too?
<ara> hello!
<ara> is 12.04.3 release happening today?
<ara> there was some conversations about maybe delaying it?
<ara> wgrant, is the 12.04.3 release happening today?
 * Laney wonders how to unstick RUNNING tests
<seb128> Laney, retry the test in jenkins?
<seb128> Laney, which one is that?
<Laney> how?
<Laney> see glib2.0 @ excuses
<seb128> Laney, e.g http://10.98.0.1:8080/view/Saucy/view/AutoPkgTest/job/saucy-adt-chromium-browser/10/matrix-reloaded/?
<seb128> Laney, click "rebuild matrix"
<Laney> hahaha
<Laney> seriously?
<seb128> well,  that's what pitti told me the other day
<Laney> ok i tried it for glib
<seb128> I did it for chromium
<TheDrums> infinity: Re: Xubuntu: < elfy> kn0me: not getting far with the alternate tests for 12.04.3 -> http://imagebin.org/268366
<superm1> infinity: yeah we'll make sure iso's get checked today
<tkamppeter> jdstrand, you have moved bug 711061 to sarnold and there is still no reaction and we have FF next week. I have already updated to GS 9.09 final.
<ubot2`> Launchpad bug 711061 in openjpeg (Ubuntu) "[MIR] libopenjpeg2" [High,Confirmed] https://launchpad.net/bugs/711061
<diwic> Hi, I uploaded a PulseAudio 12.04 SRU almost a month ago - what is the current waiting time for this to be approved and move into proposed
<diwic> ?
<stgraber> diwic: 12.04 has been frozen for the past couple of weeks in preparation for 12.04.3, and AFAIK that SRU wasn't a blocker for that
<stgraber> diwic: I'd expect things to get back to normal next week
<diwic> stgraber, no, not really, even if it would be nice to have it in 12.04.3, it isn't really a blocker
<jdstrand> tkamppeter: it is at the top of sarnold's list
<diwic> stgraber, it's more a blocker for 12.04.4, but I hope you'll have it through by then ;-)
<stgraber> we definitely should ;)
<diwic> thanks.
<smartboyhw> stgraber, slangasek if we found a mandatory testcase failing, we can't release that image right?
<stgraber> smartboyhw: it's usually up to the product owner
<smartboyhw> stgraber, OK.
<superm1> infinity: things arent' looking that good.  it look like 3.8 caused a problem with our installer https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1215440 so i'll need to investigate
<ubot2`> Launchpad bug 1215440 in ubiquity (Ubuntu) "Mythbuntu 12.04.03 candidate install fails" [Undecided,New]
<smartboyhw> stgraber, then, would it be possible to fix that failing bug if it is found in debian-installer?
<smartboyhw> I don't know about d-i, but you guys most certainly do.
<xnox> do you have a bug #?
<smartboyhw> xnox, Bug 1215418
<ubot2`> Launchpad bug 1215418 in debian-installer (Ubuntu) "Guided install with KVM and encryption failed in Kubuntu 12.04.3 pre-release alternate image" [Undecided,Confirmed] https://launchpad.net/bugs/1215418
<stgraber> superm1: can you get /var/log/upstart/* on that system to see why mysql failed to start?
<superm1> stgraber: it's actually during install that it failed to start in it's bootstrap environment.  i think it is because we had a workaround for bug 663069 in it but that bug has been fixed by 3.8 now
<ubot2`> Launchpad bug 663069 in linux (Ubuntu) ""non-accessable symlink" errors when using aufs-shaddowed read-only root filesystem" [Undecided,Fix released] https://launchpad.net/bugs/663069
<superm1> er maybe not, that should be removed but not hte root failure
<superm1> i'll see if i can get the upstart log
<xnox> stgraber: infinity: seems like kubuntu-alternate is a bit mismatched, upon install I get "no packages matching running kernel 3.2.0-52-generic in archive" and in the cdrom pool there seems to be two versions: linux-meta at 3.2.0.52.62 & linux at 3.2.0-52.78, no idea if it matters.
<xnox> udebs are 3.2.0-37.58
<xnox> uname -a is 3.2.0-52-generic
<xnox> slangasek: ^
<smartboyhw> xnox, that's not jjust Kubuntu-alternate, it's Xubuntu-alternate too
<smartboyhw> I think...
<smartboyhw> Since phillw is testing that and he found the bug there
<xnox> stgraber: infinity: seems like ubuntu switched to enabled stack, and before kernel bumps were done in "ubuntu" seed and inherited "for-free", which is not the case for Kubuntu/Xubuntu alternates anymore since they got a static copies of boot/installer. I'm guessing a kernel bump is needed which i'm not sure how to do.
<xnox> ( update seed, reupload meta, rebuild the cd?! )
<phillw> yikes!
<smartboyhw> yikes~!
<phillw> xnox: should I abort testing until re-spin?
<xnox> well, that "only" affects alternate images, the desktop images should be all fine. Also images that use enablement stack are not affected (ubuntu/edubuntu).
<xnox> which boils down to kubuntu/xubuntu alternates, it's not a bug in d-i.
<xnox> so not respinning the "world"
<phillw> xnox: that's fine. I'll zsync up the xubuntu-alterante-amd64 if it is going to be respun to sort out the kernel mismatch?
<smartboyhw> xnox, can you fix the encryption bug at the same time?
<rtg> sarnold, infinity, jdstrand: uploaded apparmor according to https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1214979/comments/6
<ubot2`> Launchpad bug 1214979 in apparmor (Ubuntu Precise) "Feature buffer full in precise with LTS kernel" [Undecided,In progress]
<phillw> xnox: are the alternates for k/xubuntu going to be respun?
<xnox> phillw: how would i know. (a) i'm not product driver (b) i can't respin anything
<phillw> okies :)
<smartboyhw> phillw, I think knome and Riddell can request for re-spins
<Riddell> except I can never remember how :)
<smartboyhw> Duh
<smartboyhw> Riddell, in the ISO QA Tracker
<smartboyhw> Tick the Kubuntu alternates
<smartboyhw> At the bottom you see "Request for rebuild"
<Riddell> got it thanks
<Riddell> kubuntu and xubuntu alternates rebuilding
<knome> Riddell, thanks :)
<phillw> Riddell: thanks, I can only do lubuntu ones :)
 * smartboyhw can only do Studio and Kylin...
<xnox> Riddell: from the build log looks better.
<xdatap1> Hi guys, do you know if Ubuntu Desktop i386 and amd64 is going to respin again before the 12.04.3 release?
<Riddell> I need to go out for about 3 hours, back about 2000UTC
<infinity> xdatap1: Almost certainly not, unless there's some massive showstopper.
<xdatap1> infinity, thanks
<infinity> xdatap1: slangasek would know for sure, though, this point release is his baby.
<xdatap1> slangasek, Hi, do you know if Ubuntu Desktop i386 and amd64 is going to respin again before the 12.04.3 release? I'm in charge of the italian loco team image and waiting to build the final one
<xnox> infinity: i think i successfully managed to bump kernel installer seeds for kubuntu & xubuntu alternate images. Since they are not using enablement kernels, they need to be bumped individually on precise now that they don't inherit them from platform seeds.
<xnox> infinity: not sure who should do that in the future, but shotgun not me.
<infinity> xnox: I should have caught it, I didn't think about the fact that they had their own installer seed due to not using enablement kernels.
<xnox> infinity: ok. well they have been respun and look good now.
<infinity> xnox: The proper solution is likely to just move them to enablement kernels before .4 and clean up that mess, but if they'd prefer not to, I just need to remember they're unique snowflakes. :P
<xnox> =))))
<xnox> speaking of unique snowflakes.
<infinity> (I know kubuntu wanted to, it's just that no one's done the work to make it so, I have on idea what xubuntu wanted to do)
<infinity> s/on/no/
<xnox> I've updated wubi to stop using disk-preinstalls (which have not been build since 12.04.0), moved the metalinks to 12.04.3, tested on Windows7 and now waiting for IS to sign the new wubi.exe.
<knome> i have no objections on that, as long as it works
<infinity> xnox: Anyhow, thanks for hunting it down and fixing while slangasek and I were asleep. :)
<xnox> infinity: hehe.
<xnox> infinity: so moving xubuntu should be easy, but kubuntu is using pae gernels which don't exist in enablement stacks....
<knome> i think we use pae for 12.04 as well
 * xnox giggles at gernels, I meant kernels
<knome> if that's what you're referring to
<infinity> xnox: Yeah, there would be a few options there.  We could just do a hard cutover and say "if you want -pae kernels install <= 12.04.3), or we could use enablement only on amd64 images (ew) for secure boot.
<xnox> knome: not sure, kubuntu seed has "-generic-pae" and xubuntu seed has "-generic"
<infinity> xnox: But it's really up to the flavours in question to twiddle that, fix their installer support as necessary, and move themselves forward, not much for ubuntu folks to do there, except advise and review.
<xnox> infinity: yeah, agree. I looked into this to buy time, and nobody else seemed to be aroundish
<infinity> xnox: For xubuntu, it should be simple enough, given it's the GTK ubiquity, kubuntu might need to put a bit more effort in, if we failed to abstract the SB stuff well enough.
<knome> if it doesn't matter if xubuntu uses what it uses in 12.04 now, let's not change that
<infinity> knome: It's not world-ending if you stay on 3.2 forever, no, and it's just a matter of me remembering you have a different installer seed. :)
<knome> :)
<infinity> knome: Not moving to enablement kernels means you can't install xubuntu/precise on secureboot machines, but if your users are the types who'd be happy to use Q/R instead for new amd64 hardware (or mess with their BIOSes), it's pretty much a non-issue.
<xnox> knome: sure, it's just ~xubuntu-dev should watch for security&updates uploads of the original ubuntu kernel & bump the ABI numbers when that happens in the seeds.
<knome> i would say it's a non-issue, nobody told they need to do that:)
<knome> xnox, right... so it's either that or move to the new enablement stuff?
<infinity> xnox: I tend to handle all those seed changes, I don't expect them to track them.
<xnox> ok.
<infinity> xnox: I'll just remember next time. :P
<knome> okay. infinity, thanks :)
<xnox> infinity: i shall remind you ;-)
<infinity> (I don't think I ever knew they had a forked installer seed, since it was Colin who did this all for 12.04.2)
<infinity> And knowledge is power.  Or something.
<infinity> So a few more of us know now. :)
<knome> secrets unraveling!
<xnox> infinity: can you add hint to ignore autopkg results for ubiquity 2.15.14, it's stuck "RUNNING" even though it clearly finished and passed.
<infinity> I have better "never have to touch the seeds again" plans for kernel/d-i syncing half done right now in S, and by 14.04, it should be hands-off, so this really is only an issue for one more precise point release and then we can stop faffing about with it, which will be pleasant.
<phillw> bug 1215453 can be marked as working, by xubuntu is in the final stages and that was an early pop-up alert :)
<ubot2`> Launchpad bug 1215453 in xubuntu-meta (Ubuntu) "No Kernel Modules were found" [Undecided,Fix released] https://launchpad.net/bugs/1215453
<phillw> s/by/my
<infinity> xnox: Yeahp, can do.  Inconvenient to have both jibel and cjwatson on vacation at the same time, when they seem to be the only two people who grasp how this all fits together.
<xnox> indeed =)
<knome> vacation? cool.
<phillw> I'll try bug 1215418 next.
<ubot2`> Launchpad bug 1215418 in debian-installer (Ubuntu) "Guided install with KVM and encryption failed in Kubuntu 12.04.3 pre-release alternate image" [Undecided,Fix released] https://launchpad.net/bugs/1215418
<xnox> infinity: actually vacations is a good thing to test bus-factor.
<infinity> xnox: Generally, I agree, sucks when you're testing the shared knowledge of a brand new system/process, though, cause it takes a while to filter that stuff around.
<infinity> xnox: Anyhow, skip hint committed.
<xnox> thanks =) !
<bdmurray> slangasek: do you have any opinion on the verification of bug 1003296?  Its rather weak.
<ubot2`> Launchpad bug 1003296 in samba (Ubuntu Precise) "lightdm crashed with SIGSEGV in _pam_winbind_change_pwd() when password is expiring" [High,Fix committed] https://launchpad.net/bugs/1003296
<slangasek> stgraber, xnox: do you know why the kubuntu precise amd64+mac rebuild is "pending" instead of "current"?
<slangasek> xnox: erm, what's this about wubi not using disk preinstalls?  I thought we were meant to be using those exclusively
<slangasek> xnox: furthermore, there *are* 12.04.2 tarballs on release.u.c
<slangasek> precise/ubuntu-12.04.2-wubi-i386.tar.xz
<bdmurray> Is the release of verified Precise SRUs being held back for the point release?
<stgraber> slangasek: where are you seeing amd64+mac kubuntu precise?
<slangasek> stgraber: kubuntu/precise/daily/20130822//precise-alternate-amd64+mac.iso; whereas the current/ dir symlinks to the 20130820.2 version
<slangasek> bdmurray: yes, please
<stgraber> slangasek: that'd be because they triggered a rebuild on the tracker and only selected amd64 and i386 so only those two got rebuilt
<slangasek> bdmurray: 1003296> I wouldn't consider that a proper verification
<slangasek> stgraber: erm, confusing.  So the image in the 20130822 directory is also the one from 21030820.2, sigh
<stgraber> slangasek: yep, that's what happens with partial rebuilds...
<slangasek> stgraber: if you're on the page already, could you kick a rebuild of amd64+mac?
<stgraber> slangasek: I can but why do we care if they don't intend to relesae it for 12.04.3?
<stgraber> if they do intend to release it, it should be on the manifest and added to the 12.04.3 milestone or it won't be picked up by publish-release
<slangasek> stgraber: ah, if it's not in the manifest then fine
<stgraber> all good then
<slangasek> still, it's very confusing to have the image copied forwarded to $serial+1, have pending symlinked to $serial+1, and have current directory created with symlinks to a mixture of $serial and $serial+1
<stgraber> yep, it can be confusing. I think the tracker is doing the right thing as it asks for rebuilds of what the user selected, the current symlinks also do what you'd expect (point to the latest built version for the given file), it's just the whole carying stuff forward that's a bit odd and we may be able to drop now
<stgraber> (as people should be using /current or know to go look at a previous build if a given file isn't there)
<slangasek> yeah... let's not rush to judgement while in the middle of a milestone release, though
<stgraber> sure, it's the kind of change that cjwatson probably has an opinion on and that should be discussed with the rest of the usual release/cdimage people
<slangasek> xnox: so for the record, we have wubi preinstall candidates: http://cdimage.ubuntu.com/precise/wubi/20130820/ - I think your change to drop disk preinstall support needs to be reverted.
<slangasek> xnox: I'm poking the RT to ask IS to hold off
<stgraber> slangasek: should I get wubi back on the manifest and get those published to the tracker?
<slangasek> stgraber: yes please (why/when was wubi removed from the manifest?)
<slangasek> strange, I can't view the RT
<stgraber> not sure why and no idea when. I didn't tweak the manifest for 12.04.3 so I'm assuming we inherited it from 12.04.2 unless someone did some cleanup in between without actually thinking about wubi
<slangasek> ok
<infinity> stgraber: With current now doing vaguely the right thing, I'd be in favor of serial directories only containing images that belonged to that build set.  Definitely would want Colin's input too, though.
<infinity> (And, of course, that change would make current stop doing the right thing again, so that would need a bit of munging :P)
<xnox> slangasek: there were none on cdimage, are there tarballs for 12.04.3?
<xnox> slangasek: http://cdimages.ubuntu.com/precise/wubi/current/ last modified 16-march-2013
<slangasek> xnox: yes, http://cdimage.ubuntu.com/precise/wubi/20130820/ + http://releases.ubuntu.com/precise/ubuntu-12.04.2-wubi-amd64.tar.xz
<slangasek> xnox: can you please revert that bit quickly?
<xnox> sure.
<slangasek> xnox: thanks :)
<xnox> slangasek: one sec checking something.
<xnox> slangasek: that tarball (i386.tar.xz) says 12.04.2 in /etc/lsb-release, whilst normal desktop.iso has 12.04.3
<slangasek> xnox: so I guess we should respin the tarballs themselves
<slangasek> not sure why that wasn't done already, but kicking off a build right now
<slangasek> ok?
<xnox> slangasek: ok. thanks.
<infinity> Should be DIST=precise SUBPROJECT=wubi for-project ubuntu cron.daily-live --live
<infinity> Maybe you missed it in your last run?
<infinity> Or maybe there's no way to do it from the tracker, and you're not driving manually?
<xnox> yeah, tracker doesn't list wubi as far as I can see.
<slangasek> infinity: I was driving from the console; and I did do a wubi build, so dunno why it had the right contents
<xnox> slangasek: wubi build updated, emailed RT as well.
<slangasek> xnox: thanks!
<xnox> oh and wubi back in the manifest, thanks stgraber.
 * xnox really should read scrollback first, then talk.
<xnox> instead of just highlights.
<slangasek> :-)
<phillw> does wubi need testing? I've got a loan XP machine I can use, but my download speed would be ~3 hours to grab an entire ISO
<phillw> can wubi use an iso on CD?
<xnox> phillw: we want to test the tarballs, not the iso. it can, if you copy wubi off the cd and launch it from the desktop.
<xnox> (whilst having the cd inserted)
<xnox> phillw: it's ok, i can test fast in windows7 VM
<phillw> xnox: okies :)
<rtg> slangasek, linux-goldfish uploaded ^^
<xnox> rtg: \o/ awesome
<xnox> rtg: armhf & i386 ?
<rtg> xnox, I haven't been able to test it, so lemme know if it works. armhf only
<rtg> are you wanting i386 as well ?
<xnox> rtg: ok. cool. Once it's build, I'll test it and will let you know how it goes.
<xnox> rtg: I don't want i386, but plenty of people are thinking about using i386 in the emulator..... we don't have ubuntu-touch-rootfs for i368 yet, so it's of lower priority at the moment.
<rtg> xnox, ok, I'll wait until someone hollers (or bribes me)
<xnox> rtg: ;-) good plan
 * xnox giggles "Windows 7" has turned my desktop black with a sign "This copy of Windows is not genuine" because I opted to not activate it online.  Yet it still offers to download updates =)
<sarnold> xnox: before long it'll start turning off every few hours
<xnox> sarnold: nice. Well I snapshot my install, cause spending ~40 minutes installing + applying updates is a pain.
<sarnold> xnox: good plan :)
 * xnox ubuntu installs in <<8minutes from boot to final login screen on the same VM setup
<xnox> slangasek: infinity: something odd is with wubi build.
<xnox> http://cdimages.ubuntu.com/precise/wubi/20130604/MD5SUMS
<xnox> http://cdimages.ubuntu.com/precise/wubi/20130822/MD5SUMS
<xnox> both are identical.
<xnox> slangasek: verified that updated wubi.exe downloads & does tarball based install.
<slangasek> xnox: so nusakan is lying about having built it? hmph
<slangasek> xnox: anyway, thanks for the verification that wubi.exe itself works; now let's look at some logs
<slangasek> hmm, livefs build dispatched successfully, then the download failed
 * xnox was under impression that wubi tarball builds were killed with fire and we switched / support cd-rom based builds only..... but then that was for post-precise. no idea what happened with precise.
<slangasek> xnox: yes, killed with fire in that we didn't want to continue supporting it as a separate build time going forward and wanted to downplay wubi as an install method... but for precise it's meant to still work
<slangasek> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/precise/ubuntu-wubi/20130822/livecd-20130822-amd64.out looks quite complete and correct
<xnox> agree
<slangasek> the target directories on the livefs builders likewise have correct contents
<slangasek> so something's going pearshaped on nusakan itself
<slangasek> xnox: wubi fixed (manually); now to figure out the source of this bug
<Riddell> kubuntu images all good for me (although not tested wubi)
#ubuntu-release 2013-08-23
<smartboyhw> 12.04.3 still NOT released?
<smartboyhw> slangasek, ^
<phillw> smartboyhw: has there been an announcement? :P
<smartboyhw> phillw, what's the thing holding up 12.04.3? Wubi?
 * smartboyhw has a serious hatred with Wubi
<phillw> Riddell: you okay with i386 alternate for kubuntu? I'm currently downloading it for testing.
<smartboyhw> phillw, I thought you should do desktop:P
<phillw> ahh.. the lubuntu bot has been active :D
<phillw> drat, he's darn good!
<phillw> Riddell: can you mark xubuntu alternate i386 ready for release?
<ScottK> phillw: I can do it, but you aren't a Xubuntu person are you?
<skellat> ScottK: No, phillw is not.
<ScottK> So it should be a Xubuntu product person saying it's ready.
<skellat> ScottK: I've been pinging those who have the power to say so.  The ball is in their court, so to say.
<phillw> ScottK: I'm a lubuntu release manager, but when all tests have been completed and passed, the big bosses can mark as ready. Unit193 is a xubuntu person, but not a release manager.
<TheDrums> bluesabre: Didn't we elect you?
<bluesabre> TheDrums: yes, I think I have release powers now
<skellat> If Xubuntu is the only thing blocking, would we actually get a 12.04.3 release out or would it wait for a few hours anyhow?
<phillw> bluesabre: ScottK TheDrums it is obviously not really for me to tell xubuntu that xubuntu is ready, in my defence I have been liasing getting the repsin done to correct a bug that was found, and another that smartboyhw found in kubuntu to get the very late respins done :)
<phillw> skellat: I believe the straggler is now wubi.
 * TheDrums didn't ping phillw.
 * skellat feels invisible again
<skellat> :-)
<bluesabre> phillw: I've not heard anything against releasing from the xubuntu side, and it looks like all of our tests are passing
 * phillw it has been an interesting excercise as 14.04 is lubuntus 1st LTS so I wanted a practice run with a friendly team :)
<bluesabre> I'll mark our remaining iso as ready
<phillw> bluesabre: If in the same situation with lubuntu, I'd be happy to mark as ready. Only one thing for release notes is that of the cryptoswap reporting an error on 1st boot when using encrypted /home area.
<bluesabre> ah, is that happening on all flavors or just lubuntu?
<phillw> bluesabre: I've seen it mentioned on lubuntu, so was not suprised to see it in xubuntu. The OP can do nothing about it, the system boots up okay and then you don't see the error message again.
<bluesabre> best/worst kind of error :)
<phillw> bluesabre: and royal pain to reproduce!
<stgraber> slangasek: disappearing for today, so if you feel like releasing today, you'll have to take care of the announcement e-mail yourself, otherwise I'll be around tomorrow to take care of that
<infinity> stgraber: Send someone the announce email, and we'll send it out on your behalf. ;)
<infinity> stgraber: Or send it now and I won't moderate it. :P
<infinity> (Hopefully no one else will either)
 * phillw I thought that xnox had done the wubi tests, or is that still being a PITA?
<stgraber> infinity: it's at: http://pad.ubuntu.com/ubuntu-12-04-3-announce (most flavour links 401/403/404 though so some coordination would be needed there)
<infinity> stgraber: Given slangasek's relative silence, I'm guessing the release isn't in the next hour anyway.
<ara> good morning all!
<ara> what's the plan with the release of 12.04.3?
<smartboyhw> Well, at least most likely we have to wait until slangasek awakes.
<NikTh> Hello,
<NikTh> any news about 12.04.3 ? https://launchpad.net/ubuntu/+milestone/ubuntu-12.04.3
<ara> seb128, bonjour!
<ara> seb128, do you have any news about 12.04.3?
<seb128> ara, ola! how are you ?
<smartboyhw> NikTh, aren't released
<seb128> ara, no, I don't, but I'm not in the release team
<smartboyhw> *Not yet
<smartboyhw> Um, slangasek is asleep, that's mostly why
<NikTh> smartboyhw: Do you know when ?
<smartboyhw> The alternates got a late respin
<smartboyhw> And Wubi got fixed
<smartboyhw> NikTh, ask slangasek himself
<ara> seb128, OK, thanks!
<NikTh> Heah.. Ok smartboyhw  , thanks.
<NikTh> This is a bit confusing.. People wait by yesterday the release of 12.04.3 and reviews are online : http://www.youtube.com/watch?v=MXPo1yA4S2w&feature=em-uploademail
<smartboyhw> Oh, not again
<NikTh> The message here [1] indicates that "Ubuntu 12.04.3 released" and giving a link that points to the daily image (which is obviously wrong), why? Because people know the schedule (2013/08/22)
<NikTh> [1] - http://forum.ubuntu-gr.org/viewtopic.php?f=14&t=20877&start=550#p294744
<smartboyhw> Yeah, we are late
<NikTh> People search for a link to download the 12.04.3 , and because it's not exist, the only link they get ( I assume from Google search) is the daily image iso.
<brendand> NikTh, released images are only the ones on releases.ubuntu.com
<brendand> it's a case of people trying too hard
<brendand> maybe cdimage should be renamed to not-released :)
<NikTh> brendand: I know that, but others don't (I guess)
<NikTh> brendand: I don't know, maybe it's a case of people that focused on other projects and finally there are no people for other projects left.
<smartboyhw> brendand, but there are some Ubuntu images there which are officially released...
<brendand> smartboyhw, on cdimage?
<brendand> smartboyhw, is the same image also on releases?
<brendand> smartboyhw, i.e. is there any officially released image that is on cdimage but not releases?
<smartboyhw> brendand, yes
<brendand> smartboyhw, which?
<smartboyhw> brendand, http://cdimage.ubuntu.com/releases/13.04/release/
<smartboyhw> And all the flavours
<brendand> smartboyhw, it depends on your definition of 'officially released' i guess
<smartboyhw> brendand, that page is "officially released"
<brendand> anyway i agree it's not clear for some people
<NikTh> cdimage.ubuntu.com has official released images also. The thing here is the /daily-iso/ . These are not stable images (at least are not considered as such).
<xnox> smartboyhw: brendand: NikTh: 12.04.3 has not been released yet, nor published anywhere. The files actually need to have "12.04.3" in the file-name.
<smartboyhw> xnox, we know
<smartboyhw> But, the people are impatient
<brendand> xnox, well i know, but some people seem to be very much willing to ignore the facts in front of them to get what they want
<NikTh> We know xnox . We know.
<NikTh> xnox:  Did you see the links I gave above ?
<Laney> Jumping the gun happens every release; it's best to not worry about it
<smartboyhw> Well, I remember at the 12.10 release date everybody mentioning the download links of 12.10 at #ubuntu-release-party are kick-banned:P
 * smartboyhw didn't
<NikTh> smartboyhw: brendand : Laney : Expect for the "Jumping the guns" thing this is quite true, lot of people that are interesting about the next point release of the current stable LTS, are remember the schedule release date. Which seems that one more time not been met.
<jamespage> Daviey, ^^ re-introduction of py-juju for saucy
<Daviey> jamespage: oh?
<Daviey> jamespage: why are we bringing it back?
<jamespage> Daviey, no upgrade path yet
<jamespage> Daviey, its officially deprecated for 13.10 - but removing it was a step to far
<jamespage> Daviey, ta
<Daviey> jamespage: well, reviewing the delta from when it was last in the archive was pretty staright forward :)
<jamespage> Daviey, indded
 * smartboyhw wonders when slangasek will be awake
<skellat> smartboyhw: It is still only 6:30 AM on the west coast of the United States.  Give slangasek time.
<smartboyhw> skellat: OK:)
 * smartboyhw doesn't have time concepts for USA.
<slangasek> yeah, give me until at least 7
<smartboyhw> Good morning slangasek:)
<xnox> slangasek: if I remember correctly, in the YouTube interview about ubuntu releases "one stays up, releases, and crashes" or something like that =)))))
<smartboyhw> lol
<slangasek> xnox: that was a while ago, now I have other responsibilities to balance ;)
<xnox> slangasek: wiser & older, just like in the avicii song. I like it =))))
<slangasek> also, am jetlagged
<xnox> slangasek: still or again? =)
<slangasek> still
<slangasek> ara: so I think we'll have the release ready to go out in about 3 hours
<ara> slangasek, thanks!
<slangasek> xnox: are you able to do the actual wubi tests for the tarballs? looks like we don't have those yet, and I'm not sure if plars is set up to test those
<xnox> slangasek: ack, let me run those.
<plars> slangasek: I should be able to, I have a windows partition on a test machine
<xnox> plars: i386 or amd64?
<plars> psivaa: ^ I think you have one too right?
<xnox> plars: i can do amd64-only.
<plars> xnox: amd64
<slangasek> plars: there seems to be an outstanding test case for MAAS (Juju) - do you know if this is applicable to 12.04?
<slangasek> seems like it should be
<slangasek> hum, why do we still have a "JeOS on ESX" test case
<psivaa> plars: i should be able to test both i386 and amd64
<xnox> slangasek: wubi is not signed still.
<plars> psivaa is a testing machine
<plars> !
<plars> :)
<psivaa> :)
<xnox> psivaa: plars: maybe use http://people.canonical.com/~xnox/wubi/precise/wubi-r279-precise.exe ? updated to say "12.04.3" et.al. but it's not signed yet.
<slangasek> xnox: ah.  It can still be tested, right?
<xnox> slangasek: correct. Hence I paste the URL above =)
<xnox> slangasek: it will have a popup "This binary is downloaded from the internet and is not trusted by CIA"
 * slangasek nods
<slangasek> (..."but it is trusted by GCHQ")
<xnox> slangasek: it's tusted by web-of-trust to the .asc file next to it, signed by my keay, with mean-square-distance < 5 to most people =)
<xnox> slangasek: so that would make GCHQ trust it, I think.
 * davmor2 waits for the knock on slangasek 's door, is that a black helicopter in the sky, run! ;)
<slangasek> I only trust binaries signed by Phil Zimmerman
<xnox> slangasek: i choked laughing =)
<rtg> slangasek, your goldfish kernel awaits flushing from the NEW queue
<slangasek> rtg: yep - thanks for the quick turnaround :)  once I have 12.04.3 out of the way I'll process it (if no one beats me to it)
<rtg> oh, I thought the point release was out the door already
<stgraber> can all the flavour leads confirm that the following URLs are correct:
<stgraber>     Kubuntu:       http://www.kubuntu.org/news/12.04.3-release
<stgraber>     Edubuntu:      http://www.edubuntu.org/news/12.04.3-release
<stgraber>     Mythbuntu:     http://www.mythbuntu.org/home/news/12043released
<stgraber>     Ubuntu Studio: http://ubuntustudio.org/2013/08/ubuntu-studio-12-04-3-released/
<slangasek> rtg: I'm a bit behind :)
<xnox> slangasek: signed wubi is in my public_html dir now, not sure where it should move next.
<slangasek> xnox: exact URL?
<xnox> slangasek: i think something like into: ~ubuntu-archive/wubi/precise/ & update stable symlink.
<xnox> slangasek: http://people.canonical.com/~xnox/wubi/precise/wubi-r279-precise-signed.exe
<slangasek> xnox: well, we can push it to ~ubuntu-archive, sure; I don't think that's ever used for anything but testing though?  So I'm more concerned about getting it onto release.u.c
<xnox> slangasek: i think nausacan knows how to fetch it from ~ubuntu-archive. It was hardcoded to fetch from ~ev before, and when ev was out riding motorcycles during raring release it was switched to use ~ubuntu-archive
<smartboyhw> stgraber: That link will 404 for now, but it's correct, it will become good as you release it
<slangasek> xnox: ah, ok
<xnox> slangasek: or some such. cjwatson twiddled it.
<slangasek> ok, copied &symlinkified
 * xnox awaits for magic to happen.
 * smartboyhw awaits for the release to happen.
<slangasek> plars: it looks like we're ready to go except for wubi, and the MAAS (juju) test I mentioned above
<plars> slangasek: having trouble getting anywhere with maas, I got pretty far but I'm not really set up for it here. I asked jamespage yesterday but I don't think he was in a position to try it at the time
<slangasek> ok
<plars> jamespage: is matsubara out? I haven't seen him show up
<slangasek> jamespage: ^^ can you help us with this MAAS (juju) test for 12.04.3?
<plars> slangasek: at least from the install side, the maas stuff is fine. I just couldn't get my nodes up and configured enough to make juju happy, but it's not something I have much experience with
<plars> slangasek: so I think the problem is between the chair and the keyboard rather than a bug in juju or maas
<slangasek> plars: understood.  I would be a lot more comfortable with pushing the release out knowing that juju+maas actually works, however
<plars> indeed
<superm1> stgraber: yeah the URL should already be live
<xnox> Laney: can ADT results from mysql-5.5 5.5.32-0ubuntu2 be hinted to be ignored (never passed?) and upstart be hinted to becuase it did actually pass?
<Laney> xnox: never passed> has someone looked into it at all?
<slangasek> xnox: why do we want to give it a pass?
<slangasek> people should be fixing those adt failures
<slangasek> ... and why does upstart need a hint if it *did* pass? :)
<xnox> slangasek: because britney thinks it's running.
<slangasek> ah, right
<Laney> the jenkins-britney stuff is busted atm and nobody knows how to fix it. :-)
 * slangasek nods
<Laney> dh_holidayfactor
<xnox> slangasek: it should skip mysql failure, since it never passed, thus upstart is not introducing a regression. Similar way britney lets packages through that e.g. never managed to build on some architecture.
<slangasek> xnox: "since it never passed"> I don't believe that's the standard we're supposed to be holding packages too
<slangasek> s/too/to/
<slangasek> the goal should be to have all autopkgtests *passing* routinely, not just being waved through when they fail
<Laney> It's valid for packages to not build on some architectures
<xnox> slangasek: sure, "never passed" should block that package from migrating, and should let the reverse-deps through.
<Laney> for autopkgtests, not so much
<slangasek> xnox: oh, I see
<slangasek> I thought you meant to ignore mysql-5.5 test failures for its own migration
<slangasek> carry on then!
<xnox> slangasek: nope =) just to get upstart through.
<Laney> I'm doing 'force-skiptest'
<Laney> which makes it ignore all of the tests triggered by that upload IYSWIM
<xnox> Laney: btw, I'm loving the new wallpapers =)
<Laney> force-badtest is the other thing
<Laney> oh yeah? approve that MP then :P
<Laney> always impressed by how quickly omgubuntu finds these things
<xnox> Laney: he subscribes to lp:ubuntu-wallpapers merge proposals.
<Laney> evidently
<Laney> xnox: it'd be nice if there were at least a bug for mysql filed with the server team / author of the autopkgtest assigned
<Laney> ;-)
<xnox> Laney: done https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/1216008
<ubot2`> Launchpad bug 1216008 in mysql-5.5 (Ubuntu) "ADT tests failing" [High,Confirmed]
<Laney> â¥
<jamespage> slangasek, plars: looking now
<jamespage> sorry its late
<slangasek> jamespage: thanks!
<plars> jamespage: smoser has been helping me too, he pointed me to some scripts which I was able to use to get things mostly going and configured
<plars> jamespage: but we are both hitting a juju problem at the end
<plars> http://paste.ubuntu.com/6018407/
<plars> jamespage: ^
<jamespage> plars, hmm - I see the same thing
<jamespage> plars, you need a :80 in your MAAS url
<jamespage> ffs
<jamespage> plars, that was not directed at you btw
<plars> ?
<plars> jamespage: yeah, I think I agree with the sentiment
<jamespage> plars, for example :    maas-server: 'http://10.200.0.1:80/MAAS/'
<jamespage> OK
<jamespage>     maas-server: 'http://10.200.0.1/MAAS/'
<jamespage> #bang
<jamespage> plars, OK - I have a server bootstrapping now
<jamespage> plars, very slowly bootstrapping (~6MBps link)
<plars> ok, slangasek, jamepage ^ might be something that should be release noted then?
<slangasek> seems like something that should be part of the MAAS install documentation?
<jamespage> slangasek, plars: I'm guessing its always been like that
<jamespage> juju has not changed for this release and its a juju problem
 * slangasek nods
<jamespage> plars, over the slow bit now - everything hitting local cache!
<smoser> jamespage, thank you.
<plars> jamespage: looks like https://bugs.launchpad.net/ubuntu/+source/juju/+bug/1084514 maybe
<ubot2`> Launchpad bug 1084514 in juju (Ubuntu) "Unable to connect to EC2 instance after bootstrap" [Medium,Confirmed]
<jamespage> plars, nope - thats an ec2 provider issue - this is a maas provider issue
<jamespage> plars, https://bugs.launchpad.net/juju/+bug/972829
<ubot2`> Launchpad bug 972829 in juju (Ubuntu Precise) "maas-server setting requires port even when using http default" [Low,Triaged]
<jamespage> plars, I'll persuade someone to backport that to precise
<smoser> jamespage, i've fixed virtual-maas to add the :80
<jamespage> smoser, great
<jamespage> smoser, fwiw I never testing it on precise - just quantal at the time
<plars> yeah, I know
<smoser> right. well its now mostly fucntional on precise.
<smoser> which is nice.
<plars> but it sounds like everyone uses the new (recommended) stuff rather than run on precise
<plars> so
<jamespage> plars, it should still be functional - thats a minor niggle but a low risk change imho
<jamespage> plars, 97% on bootstrap node
<plars> slangasek: so in that case, though there is a bug here, it doesn't seem to be a regression
<slangasek> plars: ack
<jamespage> plars, juju bootstrap test passed - doing the deploy test now
<plars> jamespage, slangasek: smoser just made it through a run successfully
<jamespage> plars, ack - I'm done as well
<jamespage> deploy is deploying
<slangasek> great!
<smoser> ship it
<plars> jamespage, smoser: thanks a lot for your help
<jamespage> plars, np - sorry it was a little late in the day!
<plars> jamespage: np
<plars> slangasek: Is that it then? or do we still need something else?
<slangasek> plars: nope, that's it - thanks for all your help
<plars> awesome
<plars> have to move locations, need to disconnect for a bit
 * infinity raises his brow.
<infinity> Who NEWed linux-goldfish to main?
<infinity> slangasek: Was that you?  Is there a reason we want it in main?
<slangasek> infinity: yeah, that was me.  If we don't want it in main, it'll fall back out on its own soon enough; but we may find that we want it in main for the SDK
<slangasek> are the kernels for the other reference devices in main?
<infinity> Nope.
<slangasek> ok
<infinity> Because they're effectively unsupportable.
<slangasek> sure
 * infinity tosses goldfish to universe for now, and waits for someone to argue it should be otherwise so he can invoke the security and kernel team for a cage match.
<slangasek> heh
<slangasek> I am disappointed that 'checksum-directory . ~/cdimage/www/full/releases/precise/release .' appears to be reprocessing images.
<slangasek> infinity: you don't happen to know the checksum-directory code, do you?
<infinity> slangasek: Not since the python rewrite.
<infinity> slangasek: Is it doing something angry and wrong?
<infinity> slangasek: If it's doing weird things when you include the previous directory arguments in a silly attempt to save I/O and CPU time, you could just call it without that.
<slangasek> infinity: given the runtime, I get the impression that it's actually re-checksumming some images as I'm archiving them, instead of just using the existing checksums from the OLD_DIRS
<slangasek> right, the problem I'm having is that it's *not* saving I/O and CPU time, or at least not as much as it ought
<infinity> Err, wait, you're re-checksumming while archiving?  We archive in whole directories, why would you need to do that?
<infinity> Anyhow, no idea why it would be hating on your OLD_DIR bits, but that always seemed fragile in both the shell and python versions (in fact, I disabled it in the shell version, due to strange fragility, coming to the conclusion that correct was better than clever)
<slangasek> because we don't archive whole directories for point releases
<slangasek> (never have)
<infinity> Oh, indeed, the point release layout is special.
<infinity> (And wrong, IMO, but whatever.  Still special)
<slangasek> grr, publish-release isn't coping properly with DIST=precise
<phillw> slangasek: update Wubi is not marked ready. Are you not going with it?
<slangasek> phillw: that's the upgrade test case, which doesn't affect publishing.
<phillw> okies :D
<slangasek> ok, published
 * slangasek squints at http://releases.ubuntu.com/12.04.3/. "Desktop cd"?  Who missed their capslock?
<infinity> Huh, it's probably been like that ever since the Python rewrite, I've never noticed.
<slangasek> actually, raring says 'Desktop image' rather than 'Desktop cd'... is that because we admitted to ourselves that it doesn't fit on a CD?
<infinity> Yeah.  For image sizes over the 700MB constraint, it just says image.
<infinity> Which may be why we never noticed the capitalisation thing.
<slangasek> actually, it seems to key on release
<infinity> Cause that would only affect ubuntu/precise and... lubuntu/saucy maybe.
<slangasek> lib/cdimage/tree.py, lines 464 ff.
<phillw> lubuntu saucy should also be CD sized. it is something we strive hard for,
<infinity> Oh, hah.
<infinity> Cute.
<infinity> phillw: Yeah, we're not talking about actual sizes, just the text on the HTML pages.
<phillw> okies, get's over minor heart attack :D
<phillw> s/get's/me get's/
 * infinity wonders why the "< quantal" bit at all, and suspects ditching that for "image" everywhere wouldn't hurt anyone's feelings.
<slangasek> dunno, but this 'titlecase' function is also teh broÄ¸en
<phillw> I'm here learning, so please do excuse my n00b questions, lubuntu will have this 'fun' as of 14.04 so only this and one more to learn via :)
<TheDrums> Not that it matters, but I'd recommend image too since they are hybrid (and USBs being nicer to boot anyway. ;) )
<infinity> Oh, and now I remembered how I was going to get the precise CDs under 700M again: I was going to drop sl-modem-daemon.  Too late now.
<slangasek> stgraber: nearly there; just waiting for the website updates to take
<stgraber> slangasek: ok. I have the e-mail ready here, so just need to hit send and poke infinity to get it through moderation
<infinity> Don't poke too hard, I'm squishy.
<infinity> PLEASE DON'T MAKE ME RUN, I'M FULL OF CHOCOLATE.
 * infinity wonders if it might be time for a Simpsons marathon.
<stgraber> ;)
 * infinity also wonders how many months of vacation he'd have to book to get through all 24 seasons.
<qengho> Hi hi.  For phased updates, where is the "Phased-Update-Percentage" value set?  Can someone point me to an example of it in use?
<qengho> I think I should find it in a archive Packages.gz file, but I don't see it yet.
<stgraber> slangasek: any progress on the website?
<qengho> bdmurray: Got a sec?  Where is a package's Phased-Update-Percentage stored and retrieved from?
<bdmurray> qengho: if there is no phased-update percentage then it will not appear
<bdmurray> qengho: you should be able to find it for the packages listed here http://people.canonical.com/~ubuntu-archive/phased-updates.html
<bdmurray> and yes Packages.gz is the right place to look
<bdmurray> just be sure it is the one from raring-updates
<qengho> bdmurray: er, is "-updates" a condition for the test in update manager, or is it just the only place we'll practically apply those kinds of updates?
<qengho> bdmurray: (I'm "asking for a friend" who is interested in using this mechanism for his software archive.)
<bdmurray> only packages in -updates will have the Phased-Update-Percentage set
<qengho> Right.
<qengho> bdmurray: CC'd you on email reply, so you can tell me I'm wrong. I hope that's okay.
<bdmurray> qengho: yep, that's fine
<darkxst> hi, can I get ddebs enabled on ppa:gnome3-team/gnome3-next
<stgraber> Riddell, ScottK, highvoltage: about to push the announcement out, please make your posts public
<stgraber> infinity: announcement sent
<stgraber> infinity: hmm, I immediately got a "Your message was rejected" back from lists.ubuntu.com...
<slangasek> stgraber: X-Ubuntu magic sekrit header?
<infinity> Oh wait, this is going to ubuntu-announce, not devel-announce, I can't moderate that anyway.
<stgraber> right, that's an e-mail to ubuntu-announce. I think it's the first time I need to send something to that one.
<infinity> stgraber: You need an "X-Ubuntu: random string, vorlon likes to hide jokes in here" header.  And to ask IS to moderate it.
<stgraber> infinity: ok
<slangasek> infinity, stgraber: I can moderate it
<infinity> slangasek: Oh, shiny.  I didn't realize anyone outside IS had mod on that list.
<phillw> has kate left chasing up release notifications etc?
<stgraber> slangasek: ok, so announcement is out and I updated the tracker to mark the milestone as released, anything else?
<slangasek> stgraber: that should do the trick, thanks
#ubuntu-release 2013-08-24
<RAOF> slangasek: You're busy, but at some point I want to pick your brains about why I can't seem to get Ubuntu to secure-boot on this laptop. Just a heads up.
<slangasek> RAOF: ASUS?
<RAOF> slangasek: System76
<RAOF> So this is purely opt-in.
<slangasek> hmm!
<slangasek> which keys does System76 ship in KEK?
<slangasek> +db
<RAOF> None; I've added my own.
<slangasek> oh. your own personal keys, or the Canonical key?
<RAOF> Personal key in the PK, personal, Canonical, and MS keys in KEK & DB
<RAOF> Roughly following https://wiki.ubuntu.com/SecurityTeam/SecureBoot and http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/
<slangasek> and what's the behavior you're seeing?
<RAOF> Windows boots fine, but Ubuntu fails to verify.
<RAOF> sbverify claims that /boot/efi/EFI/ubuntu/grubx64.whatever has a valid signature from the Canonical public key, though.
<slangasek> and you're booting grub directly, or via shim?
<RAOF> Booting to grub directly
<slangasek> well hmm
<slangasek> and you're sure you have the signing key in db, not the CA key?
<RAOF> Hm. I may have the CA key in db.
<slangasek> RAOF: you can dump the var via  /sys/firmware/efi/efivars/db-d719b2cb-3d3a-4596-a3bc-dad00e67656f
<RAOF> Ah, yeah. Got the CA key in there.
<RAOF> I need the signing key instead, I take it?
<slangasek> RAOF: yep
<darkxst> infinity, stgraber, can I get ddebs enabled on ppa:gnome3-team/gnome3-next
<infinity> darkxst: I suspect the people who can twiddle that are all gone for the week.
<RAOF> slangasek: Ta. I'll give that a try after I finish bashing my head on X
<slangasek> :-)
<darkxst> infinity, ok, will try again next week then
<RAOF> To be clear - I'd need the CA key in KEK and the signing key in db, right?
<RAOF> Or just the signing key everywhere?
<infinity> darkxst: Asking through answers.lp.net may get someone to see it if/when they're bored, or just poke me on Monday, and I'll get someone to do it.
<darkxst> infinity, ok thanks, Monday is fine
<slangasek> RAOF: yep, CA key in KEK, signing key in db
<slangasek> that's the standard config
<phillw> If there is someone available, could you tell me the difference between sudo do-release-upgrade and the apt-get update & dist-upgrade route?
<phillw> brian intimated that they are not the same.
<ScottK> They aren't.  The first one uses ubuntu-release-upgrader.  To really understand the difference you probably need to look at the code, but the simple version is it does lots of special casing to make release upgrades smoother.
<ScottK> You could ask that on -devel.  It's nothing to do with the release team.
<phillw> ScottK: thanks, heading there now :)
<Laney> please to promote ubuntu-wallpapers-saucy
<infinity> Laney: Iz done.
<RAOF> slangasek: Thanks; now that I've got the Canonical signing key in db everything works marvelously.
<xnox> Please reject ocaml-estrings from saucy new queue, its orig tarball is full of .... upstream .git/objects
<xnox> slangasek: thanks.
<slangasek> wasna me
<slangasek> some other archive admin working on the weekend and not fessing up :)
<infinity> If only it emailed the uploader so you knew who rejected it.
<xnox> =)
#ubuntu-release 2013-08-25
<xnox> do we really want dgit in saucy already? it's quite new and is rapidly developed.....
 * xnox is setting up daily ppa for those who want to use it.
<xnox> jbicha synced it...
<xnox> infinity: i'm loving the new publisher speed!
#ubuntu-release 2014-08-18
<darkxst> can someone promote tracker to main? didrocks was going to do it, but havent seen him for a while!
<darkxst> bug 1313996
<ubot93> bug 1313996 in Ubuntu GNOME "[MIR] Tracker" [Undecided,New] https://launchpad.net/bugs/1313996
<darkxst> (needed for https://launchpad.net/ubuntu/+source/nautilus/1:3.10.1-0ubuntu13)
<darkxst> infinity, ^^^ can you promote tracker?
<rtg> arges, tboot has been languishing in the Trusty unapproved queue since 7/31. Could you have a look at it ?
<arges> rtg: sure
<arges> rtg: ok so looks like a security/bugfix-mostly update so that's good
<arges> rtg: however, the changelog is messed up as it has utopic entries in it for a trusty release. Can you make it one entry that explains all teh changes in one
<rtg> utopic ? doh!
<arges> rtg: in addition fix_grub-mkconfig_version.patch was dropped. can you mention why this is ok in teh changelog too
<doko> stgraber, ScottK: please overwrite the libaunit autopkg test. it was demoted to -proposed, and shouldn't block glibc
<rtg> arges, tboot resubmitted with requested changes
<arges> rtg: ack
<gaughen> slangasek, arges, infinity - who do I bug to find out if a ffe is likely to get approved?  rbasak filed one for bcache
<doko> stgraber, ScottK, infinity slangasek: please overwrite the libaunit autopkg test. it was demoted to -proposed, and shouldn't block glibc
<doko> stgraber, ScottK, infinity slangasek: please overwrite the bzr autopkg test to unblock glibc
<slangasek> gaughen: bug #?
<arges> rtg: ok, a few more comments (should have caught this earlier) the hg_archival.patch can you fill in the rest of the template. Also you drop /fix-werror-format.patch but that doesn't line up with what teh changelog says.
<rtg> arges, once more into the breach...
<arges> rtg: ok i'll look at in a second
<gaughen> slangasek, 1355890 is the bug
<gaughen> slangasek, we'll have a test plan ready to share by end of day today
<arges> rtg: looks good .. accepted
<rtg> arges, thanks
<slangasek> gaughen: an FFe doesn't require an extensive test plan
<gaughen> slangasek, well I just wanted to let you know it was out there
<slangasek> ok :)
<gaughen> and would be available soon
<gaughen> but good to know
#ubuntu-release 2014-08-19
<tkamppeter> Hi, I only want to tell that I have uploaded a new cups-filters package (1.0.57-1ubuntu1) now which generates an extra binary package (cups-filters-ippusbxd). Please make sure that it gets into Main before Feature Freeze.
<tkamppeter> It will get pulled into default install by a Recommends: in system-config-printer-udev.
<gaughen> slangasek, would you kindly look at https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1338768
<ubot93> Launchpad bug 1338768 in golang-pty-dev (Ubuntu Trusty) "[SRU] Update to 1.0.1 release" [High,New]
<gaughen> rharper, --^
#ubuntu-release 2014-08-20
<Noskcaj> Could anjuta-plugins be RMed till it's fixed in debian? It's stopping anjuta migrating
<mlankhorst> can someone approve xserver-xorg-video-intel?
<tkamppeter> I have submitted a MIR for the "brlaser" printer driver package (bug 1359137). I would like to get it in before FF. The package is super simple and small. Could this be done?
<ubot93> bug 1359137 in brlaser (Ubuntu) "[MIR] brlaser" [High,New] https://launchpad.net/bugs/1359137
<doko> stgraber, Laney, infinity, slangasek: please override the libaunit autopkg test. this package is removed in -release, and has nothing to do with glibc
<Laney> doko: ok, how did all this stuff get broken?
<doko> Laney, it's the broken gnat transition
<doko> Laney, ahh, the nice side effect of this unblock was the migration of gnat-4.9
<Laney> doko: the 'broken' transition migrated?
<doko> gnat-4.9 and all packages already built for 4.9
<bdmurray> slangasek: could we talk about releasing the trusty sru of ubuntu-release-upgrader? not every bug is verified and I think that's okay.
<bluesabre> When is the FF cutoff time? less than an hour?
#ubuntu-release 2014-08-21
<cjwatson> bluesabre: Usually somewhat later on Thursday
<bluesabre> cjwatson: thanks, I've been in panic packaging mode :)
<Riddell> stgraber: you're the iso tracker dude?
<Riddell> stgraber: I added Kubuntu Plasma 5 to isotracker, how do I get it to show up under Utopic Daily ?
<Laney> Riddell: I think you have to have it match etc/qa-products in lp:ubuntu-cdimage and then it should show up after a build
<Laney> semi-educated guess
<Laney> (In that file the product name doesn't contain "Desktop")
<Riddell> doen't seem to help to remove the "Desktop" from isotracker product
<Laney> has a build finished?
<Riddell> not since I added it
<Riddell> maybe I should just be patient
<Laney> 17 22 * * *for-project kubuntu-plasma5 cron.daily-live --live
<Laney> I'd see if it happens after then
<cjwatson> [5~/wg 24
<cjwatson> sigh
<Riddell> queuebot: ooh?
<Riddell> how does this file get edited? http://releases.ubuntu.com/include/kubuntu.css
<cjwatson> by hand, I'm afraid
<cjwatson> happy to plonk in a new version
<Riddell> cjwatson: could you   cp kubuntu.css kubuntu-plasma5.css; sed s,Ubuntu,Oxygen, -i kubuntu-plasma5.css
<cjwatson> Riddell: done
<Riddell> cjwatson: then eye over and pull the change I just commited to ubuntu-cdimage
<cjwatson> Riddell: single-element tuples don't work like that
<cjwatson> ("kubuntu") is just grouping not a tuple, so foo in ("kubuntu") is true if foo is "k" or "u" or "b" or "n" or "t"
<cjwatson> Riddell: also you have a bunch of test failures
<cjwatson> Riddell: I think mostly because you're missing file=header on various print calls, but make sure to use ./run-tests
<cjwatson> for the former problem I would just write 'if self.project == "kubuntu":' etc.
<cjwatson> and save in-tuple for the case where you have more than one
<Riddell> mm ok, that seems unintuitive
<Laney> you need the trailing comma for one-element tuples
<cjwatson> Yeah, that works too, but style in cdimage is usually just to use equality in such cases
<Laney> Sure, just explaining the python syntax
<Riddell> that seems like the sort of unintuitive change in behaviour you'd expect from JavaScript not Python :)
<Riddell> cjwatson: ubuntu-cdimage updated
<cjwatson> Riddell: thanks, but still produces junk on stdout during the tests which indicates missing file=header on print, and there's a test failure if you have pep8 installed
 * Riddell investigates
<Riddell> cjwatson: third time lucky, ubuntu-cdimage updated
<cjwatson> Riddell: great, thanks - deployed
<Riddell> yay
<bdmurray> slangasek: I'd like to release this ubuntu-release-upgrader SRU to trusty although one bug failed verification (the fix for that one is still in the works).
<stgraber> Riddell: sorry, at a conference with pretty bad wifi. If the product exists on the tracker, it should automatically show up with the next build, so long as the cdimage branch contains the proper mapping between internal cdimage product name and qatracker product name.
<stgraber> Riddell: if the mapping doesn't exist or is wrong, you'll see an error message in the iso build log
<Riddell> stgraber: ok I'll check back tomorrow thanks
<stgraber> Riddell: KeyError: "Product 'Kubuntu Plasma 5 amd64' not found"
<stgraber> Riddell: http://people.canonical.com/~ubuntu-archive/cd-build-logs/kubuntu-plasma5/utopic/daily-live-20140820.log
<Riddell> right, and now it has "Kubuntu Plasma 5 amd64" so hopefully that's all good
<stgraber> ok, so the next daily build should just show up then
<slangasek> bdmurray: should we reupload dropping the bug reference from the changelog, to avoid confusion?
<slangasek> gaughen: docker.io accepted into trusty-proposed now
<gaughen> slangasek, thank you!
<bdmurray> slangasek: ah, yeah that'd make sense. can that be done using the same version number or is a new one required?
<slangasek> bdmurray: new one required
<bdmurray> slangasek: ack, I'll get that uploaded then
<slangasek> bdmurray: cheers
<wxl> hey not to be jumpy but are we quite ready to start beta1 testing?
<elfy> beginning of next week wxl - I've not seen the "who's doing beta" mail yet either
<wxl> elfy: ok just don't want to miss it this time XD
<elfy> I'll try and remember to ping you if you like :)
<wxl> elfy: as long as someone does ;)
<elfy> heh
<bdmurray> slangasek: uploaded
<slangasek> bdmurray: looks good, accepted
<bdmurray> slangasek: there is no need to reverify the fixed bugs correct?
<slangasek> bdmurray: based on that diff, I'm happy to skip reverification
<bdmurray> In case anybody is interested I've update the metarelease fiels for the release-upgrader in trusty-updates
<bdmurray> cjwatson: is it expected for packages to exist in -updates and -proposed after a run of sru-release?  see systemd and ubuntu-release-upgrader
<cjwatson> Yes
<bdmurray> for how long?
<cjwatson> We don't have a copyPackage with move semantics yet (I've been working on that, haven't quite finished), so they have to be removed manually
<cjwatson> Until somebody processes the "-proposed cleanup" block in pending-sru.html
<cjwatson> I'll do that now
<bdmurray> cjwatson: got it, thanks!
<cjwatson> You probably haven't noticed since I tend to reflexively process it when I'm bored :)
<bdmurray> well and I've been so buried with the error tracker
<cjwatson> that batch is removed now
#ubuntu-release 2014-08-22
<pitti> hello
<pitti> can we ignore orafce's test failure ("badtest"), to unblock the perl transition?
<pitti> 3.0.7 added new tests which uncovered a crash on i386
<ara> Hello #release
<pitti> I reported it upstream (https://github.com/orafce/orafce/issues/15), but we don't want to hold back 3.0.7 as it's not really a regression
<pitti> Laney: ^ if you could do an override?
<ara> Who is in charge of moving 12.04.4 and 14.04.0 to old-releases?
<doko> did somebody overwrite kde autopkg tests? suddenly everything migrated
<doko> I think we should ignore the mysql-5.5 issue too
<pitti> doko: yes, ScottK added two overrides a few days ago
<ScottK> I just added one more.
<Noskcaj> Is it possible to force a package to build arch:all on amd64? infernal is amd64 only,  but won't migrate because it tries to build the "all" part on i386
<Sarvatt> anyone know whats going on with intel-vaapi-driver on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html ? says out of date on arches its never built on
<Sarvatt> ah it built on those arches in precise
#ubuntu-release 2014-08-23
<Noskcaj> Could someone on the SRU team please look at bug 1308533 and bug 1339911
<ubot93> bug 1308533 in xubuntu-default-settings (Ubuntu) "[SRU] Non-english live-cd: some programs are in English although their name is in Non-english, and vice-versa" [Undecided,Confirmed] https://launchpad.net/bugs/1308533
<ubot93> bug 1339911 in xfce4-clipman-plugin (Ubuntu) "[MRE] Please update xfce4-clipman-plugin to 1.2.6" [Undecided,New] https://launchpad.net/bugs/1339911
<Wellark> sorry to be late in the game, but:
<Wellark> https://bugs.launchpad.net/ubuntu/+source/share-app/+bug/1360670
<ubot93> Launchpad bug 1360670 in share-app (Ubuntu) "drop from archive" [Undecided,New]
<Wellark> https://bugs.launchpad.net/ubuntu/+source/libhud-qt/+bug/1360671
<ubot93> Launchpad bug 1360671 in libhud-qt (Ubuntu) "drop from archive" [Undecided,New]
<Wellark> is it possible to nuke https://launchpad.net/libhud-qt totally off from LP?
<Wellark> (I'm the "owner")
<Wellark> Mirv: I know you are working...
<Wellark> ;)
<Mirv> Wellark: bah!
<Wellark> Mirv: <3
<Mirv> Wellark: nuking projects is a bit hard (maybe some bug against LP would work), but you can add some warning text like I just did to it
<Wellark> would be great if you could mark projects abandoned and LP would generate some nice notice about it
<Mirv> I marked the branch Abandoned an added that note to https://launchpad.net/libhud-qt, not sure if anything else can be done
<Wellark> it's fine
#ubuntu-release 2014-08-24
<teward> who manages the old-releases.ubuntu.com site/repository?  Is that the release team or the mirror admins or canonical sysadmin?
<teward> s/sysadmin/sysadmins/
<cjwatson> cdimage team
<cjwatson> though we don't have control over the machine, we just push content to it (which sometimes fails ...)
<teward> cjwatson, who do i have to poke to get info about it?  there's a question on askubuntu about how quickly/soon data gets moved for EOL releases
<teward> (i.e. archive.ubuntu.com still has saucy, and old-releases doesn't, the question was when it moves over)
<cjwatson> err, basically when we get around to it I think :)  it's unfortunately a manual process right now, https://wiki.ubuntu.com/EndOfLifeProcess has the gory details
<cjwatson> usually me or infinity, but we're both at debconf atm
<teward> cjwatson, 'tis fine, I don't think there's a huge rush, it was a general question.
<teward> cjwatson, thanks for the information.  :)
<infinity> teward: I intentionally helf off on getting our sysadmins to mirror saucy to old-releases as we pushed a naughty post-EOL apt update to saucy.
<teward> ahh
<infinity> teward: But it'll get mirrored "soon" and removed from archive sometime after that.
<teward> infinity, right, that's what I assumed, since all my stuff is either Precise or Trusty already I'm less affected, however some people actually were wondering (on askubuntu).
<teward> thanks to you and cjwatson though for providing the info needed to provide an answer to those people.  :)
#ubuntu-release 2015-08-17
<wxl> could someone check on lubuntu live images? not clear from the logs what exactly failed but it definitely did http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/wily/daily-live-20150816.log
<wxl> actually loks like the issue might actually be blueman
<wxl> https://launchpadlibrarian.net/214636996/buildlog_ubuntu_wily_i386_lubuntu_BUILDING.txt.gz
<cyphermox> wxl: I should be asleep, but I think infinity was fixing it before, rebuilding the metapackage
<cyphermox> If you want a respin, please ask but since it's almost 3am, I'll go get my beauty sleep
<cyphermox> ;-)
<wxl> cyphermox: night cyphermox :)
<wxl> and thank you
<cyphermox> (I don't have access to respin anyway)
<cyphermox> Ttyl
<wxl> it's ok, i can do it
<wxl> for what it's worth, the bluez issues are fixed, but we're having issues with a bunch of other libs. https://launchpadlibrarian.net/214665996/buildlog_ubuntu_wily_amd64_lubuntu_BUILDING.txt.gz
<slangasek> wxl: that looks like an issue that's fixed by clearing out NBS binaries, so I'm doing that now - you may want to trigger another image build after the next publisher run
<slangasek> (well, assuming the removal completes before the next publisher run; it seems to be taking a bit of time to process all the packages...)
<wxl> thsnk slangasek. i'll probably just wait until we get a new image Ã¡ la cron. it's nice to know someone's on it. thanks again!
<infinity> slangasek: Guessing from that massive NBS list and the mail spam that a good chunk of the snag went through while I was in the air?
<Laney> it went in!
<Laney> now who dares to dist-upgrade and reboot? :)
<xnox> python3.5 as default?
<cyphermox> Laney: on it :D
<Laney> nein, unity and everything post-g++5
 * cyphermox tries and has reasonable backups
<cyphermox> guess I should also take a quick look at the image
<xnox> infinity: http://people.canonical.com/~ubuntu-archive/proposed-migration/history.html shows a nice drop.
 * Laney sees this for the first time
<cyphermox> very nice
<slangasek> infinity: yes, a few packages seem to have made it in
<infinity> slangasek: "a few".
<slangasek> barry: do you have some idea why frosted FTBFS in Ubuntu but not in Debian? https://launchpad.net/ubuntu/+source/frosted/1.4.1-1/+build/7385456  (with the g++5 transition through, I'm looking a bit at other stalls in update_excuses)
<barry> slangasek: i'm not familiar w/the frosted package, but 'builtins' is not a built-in module in python 2
<slangasek> barry: right, so why does a build succeed on sid but not on wily?
<slangasek> barry: (translation: how can I make it so the build failure is the Debian maintainer's problem and not ours? ;)
<slangasek> (altertnatively, to make it not a problem at all
<barry> slangasek: unsure.  would have to spend some time on it
<slangasek> barry: ok, probably not worth you spending a lot of time on it
<barry> slangasek: i'll keep a tab open for when i get the transition done
<cyphermox> slangasek: anything I can look at in priority in proposed-migration, or just pick at things to reduce the list?
<barry> cyphermox: wanna look at some python3-defaults blockers? :)
<slangasek> cyphermox: "priorities" might be looking at anything that winds up as a failed easy hint in update_output, if there are any that aren't haskell? :)
<cyphermox> that's what I meant
<slangasek> cyphermox: also, anything left on http://people.canonical.com/~ubuntu-archive/transitions/, and anything on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python3-defaults as barry says
<cyphermox> alright
<barry> cyphermox: if you do want to look at py3def, ping me so we don't overlap
<cyphermox> ok
<cyphermox> slangasek: btw, I can haz multipath-tools review for the trusty SRU? :)
 * cyphermox is looking at mlterm
<cjwatson> phew, another haskell transition out of the way
#ubuntu-release 2015-08-18
<tjaalton> infinity: nvidia 352 in still in NEW, and as I hear now obsolete
<slangasek> cyphermox: looking
<cyphermox> slangasek: (sorry :)
<cyphermox> slangasek: also, you said golang?
<slangasek> cyphermox: yep; let me get up to speed on my mail and I'll find you a link
<cyphermox> alright
<slangasek> cyphermox: the udev rule removal is a backport of a change already in wily?
<cyphermox> slangasek: no, it's an adaptation of how wily works
<slangasek> cyphermox: hrm please expand
<cyphermox> slangasek: things are Very Broken otherwise, system goes up in load due to multipath-tools being called repeatedly on the devices
<cyphermox> (or udev being called repeatedly and failing to speak to the socket
<slangasek> cyphermox: my question is whether the udev rule is dropped in wily
<cyphermox> no, it's still in wily
<cyphermox> multipath doesn't work the same in wily, it's 0.5.0
<slangasek> hmm
<slangasek> ok
<cyphermox> I'm just trying to make things work as best I can backporting just the bits we need
<slangasek> so what's the test case for that change?
<cyphermox> the udev rule specifically?
<slangasek> yes
<cyphermox> *rules
<slangasek> btw bug #1468897 is referenced in the SRU changelog but has no SRU test case
<ubot93> bug 1468897 in multipath-tools (Ubuntu Trusty) "multipath creates binding for Removable(USB) drives" [Medium,In progress] https://launchpad.net/bugs/1468897
<cyphermox> if the socket rule is there, you'll see a ton of errors from udev about the multipath socket which can't be reached, because, AIUI, udev doesn't understand the path
<slangasek> if it's a duplicate of the other, please mark it as a duplicate.  If it's not, please add an explicit test case for it
<slangasek> cyphermox: so that's the existing behavior you see with the udev rule as it sits in trusty-updates today?
<cyphermox> and if the add|change rule is there; you'll see the system come up with >8 load average and multipath being started and finishing repeatedly in processes
<cyphermox> slangasek: with no changes in trusty-updates, things seem to work properly
<cyphermox> ^ that SRU changes how multipath speaks to udev (teaches multipath about udev, in short)
<cyphermox> multipath is expected to receive the events already and handle them itself via multipathd
<slangasek> cyphermox: you said you would see errors from udev becuase udev doesn't understand the path; but this is the existing rule present in trusty-updates; so that doesn't seem accurate
<cyphermox> if you upgrade, you'll see errors, and I didn't see them before
<cyphermox> but I agree, one should already see them
<cyphermox> heh, I guess this makes it another bug, really
<slangasek> cyphermox: so from an SRU standpoint: a) what is the udev rule for, b) how do we test that the thing the udev rule was supposed to do previously, still works after applying the SRU?
<slangasek> cyphermox: I don't need a separate bug report for this but do want an explicit test case
<cyphermox> slangasek: I'll get it on the bug report, it should have been there. In short, simulate paths appearing and disappearing by breaking FC links
<cyphermox> that would be the easiest way to reproduce it
<cyphermox> I asked to get access to hardware for that a while ago, but I didn't get a response
<cyphermox> slangasek: I updated the two multipath bugs.
<apw> did we force something to migrate, as for me the current state of wily-release is uninstallable in a big way
<Laney> apw: example?
<apw> Laney, the info is now in bug #1485970, seems apt could not figure out that it needed to configure libexpat1
<ubot93> bug 1485970 in apt (Ubuntu) "apt-get dist-upgrade falied with a dbus trigger loop due to an unconfigured library (libexpat1)" [Undecided,New] https://launchpad.net/bugs/1485970
<apw> (i think you can take it from that that my uninstallability was falsly reported by apt as it was half way through)
<Laney> apw: ah right, not straight uninstallability then
<apw> Laney, no, it felt like that at first glance, but something all together different in the end
<slangasek> cyphermox: "Some USB 3.0 devices *can* support multipath; users of such custom configurations will see USB devices not being considered as multipath devices" - is there a documented/documentable way for the users of such devices to get the previous behavior?
<cyphermox> no
<slangasek> ok
<cyphermox> there's no way to get the previous behavior back, this is just theoretical
<cyphermox> I'm not sure *how* you would do it but it should be feasible
<cyphermox> but if we do have someone who decides they want to do USB 3.0 multipathed on Trusty, they're prepared for a bad upgrade, because 0.5.0 drops USB completely.
<slangasek> so the consequence is that the multiple paths will show up as separate devices; references to the multipath device will be invalid; and the device will be accessible but lose the redundancy
<slangasek> heh ok
<cyphermox> I just couldn't apply these patches on top without breaking things
<slangasek> infinity: ^^ I would like a second opinion on this
<cyphermox> right, device will be usable but not redundant via /dev/mapper.
<cyphermox> infinity and I discussed this before ,that's why I say USB 3.0 multipath could be done, he brought it up :)
<slangasek> ok, so did he also voice his opinion on whether this is acceptable in an SRU?
<slangasek> thanks for the thorough analysis of regression potential, regardless
<cyphermox> not so much
<cyphermox> (or I don't remember well enough)
<cyphermox> fyi, I understand liblog-any-adapter-perl is a candidate for removal, it was apparently merged into liblog-any-perl, according to the latter's changelog, and I've checked the reverse-depends which seem to be either blocked in proposed, or fixed and transitioned because of alternate depends.
<slangasek> cyphermox: liblog-any-adapter-perl sorted (via a bit of process-removals)
<cyphermox> slangasek: thanks. there was already a bug from micah.
<Riddell> slangasek, doko: if you're doing new reviews could you stop for a sec, some may need rejected?
<slangasek> Riddell: it's not me
<Pici> a/36
<infinity> slangasek: The "you could do multipath on USB" assertion of mine was purely theoretical as an argument for why dropping device classes is probably "wrong", but I can't imagine that it's something people actually do.
<slangasek> infinity: IOW, you're ok with this in an SRU?
<infinity> slangasek: Yeah, I think so.  It was just a complaint that I think the upstream logic is overreaching.
<infinity> slangasek: But, yeah, no real person would mpath over USB in any situation I can think of, except perhaps to test mpath when you don't own enough hard drives. :P
<cyphermox> infinity: you really just need one to test multipath...
<cyphermox> ;)
<infinity> cyphermox: Sorry, more disk controllers. :P
<robru> can somebody remind me how to build touch images? IIRC I was given permission to do this forever ago and I've completely forgotten where/how to do it
<robru> infinity: ^
<cjwatson> iso.qa.ubuntu.com, log in, select wily daily, checkbox left of "Product (Ubuntu Touch)" which should select everything in that section, make sure "Request a rebuild" is selected at the bottom, "Update rebuild status"
<cjwatson> or if you need vivid, ssh -t nusakan sudo -iu cdimage, crontab -l | grep touch, copy and paste the bit beginning with DIST=vivid
<cjwatson> that's nusakan.canonical.com depending on your ssh configuration, requires VPN
<robru> thanks
<robru> cjwatson: is there a wiki for that anywhere?
<infinity> cjwatson: Pretty sure he's not in cdimage (and shouldn't be).
<cjwatson> yeah so you can probably only do the wily one
<robru> darn
<robru> infinity: cjwatson: will one of you be around to do the vivid one a bit later?
<cjwatson> I won't
<infinity> robru: Define "bit".
<robru> infinity: I'm guessing like an hour or two, we're still waiting for one silo to be QAd and published.
<infinity> robru: An hour, yes, two, maybe.
<robru> infinity: alright I'll poke the qa people
<cjwatson> fixing things so that rebuild-requests knows how to kick off vivid touch builds would be mostly a SMOP; basically moving the EXTRA_PPAS variable setting out of crontab and into a config file somewhere
<infinity> cjwatson: We're doing that right noiw.
<infinity> now, too.
<infinity> (not moving things around, just fixing rebuild-requests)
<infinity> robru: stgraber is fixing the world for you right now so you can trigger vivid from iso.qa
<robru> oh sweet
<robru> it's almost ready, hit publish on the silo, just waiting for the PPA to publish the packages
<robru> infinity: I see vivid on the ISO page, is it safe for me to trigger that yet?
<infinity> robru: When do you need to?  Are you ready?
<robru> infinity: yep we're ready
<infinity> robru: If so, then yes, trigger from the tracker.  Both arches, obviously.
<infinity> robru: We're watching for debugging reasons. :)
<robru> infinity: great, thanks for enabling that
<infinity> robru: But it should work.
<robru> infinity: ok I just clicked on the rebuild thing, I don't see any changes in the web interface tho
<robru> oh it does say rebuilding, nm
<robru> 15:59:46 <sil2100> Ok, kicking the build now
<robru> infinity: what happens if the build is kicked twice? ^
<infinity> robru: The one he "kicked" never happened, since it was when we had it all disabled.
<robru> lol
<infinity> sil2100: Perhaps people should ask if a feature is done when someone says they're implementing it on the fly? ;)
<sil2100> What what?
<robru> sil2100: they were enabling vivid builds on iso.qa.u.c so that I could kick a build, and I did
<sil2100> Ah, so it got kicked already? Ok
<sil2100> Does it use the overlay in that case?
<sil2100> I saw a request, didn't see anyone saying 'I kicked the build' so I kicked it
<sil2100> I told Bill explicitly that I'll be back to kick the build
<sil2100> So I didn't even expect anybody to kick it besides me
<sil2100> Anyway, should I terminate the command I ran on nusakan?
<robru> infinity claimed the command you ran didn't do anything. I'm not sure what there is to cancel
<infinity> sil2100: Err, you did it by hand?
<sil2100> I always do it by hand through nusakan
<infinity> sil2100: Please don't?
<sil2100> There was no other option in the past, I got nusakan access just for this purpose - that's what ogra_ and slangasek said I should do
<sil2100> Not sure if that changed but no one informed me that's not the right way to do it
<infinity> Ahh.  Well, they were wrong.  That's a terrible reason to give people access to a machine with sensitive private keys on it.
<infinity> Someone should have pointed out to us that rebuilding this from the web UI should work. :P
<sil2100> Well, now I do much more on nusakan, but that was the original idea
<infinity> (which it now does)
<sil2100> Anyway, should I kill off the command now or just leave it?
<infinity> Just leave it.
<infinity> Just means we can't test our stuff without building again, which might annoy you.
<infinity> But killing annoys things too, so whatever. :P
<sil2100> Sorry for the confusion, but as I said, I explicitly coordinated with the product team manager that I'll be around and that was the plan
<robru> alright I gotta run out, we should sync up on this tomorrow I guess
<robru> bbl
<infinity> sil2100: Oh.  See, robru implied that he would need help with it, hence we fixed it so he wouldn't. :P
<robru> infinity: sil was given access to nusakan forever ago. Ancient history now
<infinity> robru: Yeah.  Just sayin' it was probably wrong back then.  Annoyed with past people.  I'll get over it.
<infinity> (People being given access to nusakan willy-nilly caused me to get IS to actually write policy about sensitive machines)
<sil2100> Well, as said, I use nusakan for much more now and I think that was the deal as well, but the original idea for me getting access was to 'manage and build images'
<sil2100> hah ;)
<infinity> sil2100: "much more"?  system-image stuff, I assume?
<sil2100> Yeah, basically only system-image stuff ;p
<infinity> All of that shouldn't be on nusakan either, but I guess we need all the people who care to figure out and fix that.
<infinity> And by "all of that", I don't mean system image backend things, but the commands one runs to manipulate them, etc.
<infinity> Shouldn't need shell on a machine with two highly sensitive private keys.
<infinity> Rant over.  I should go be not here.
<sil2100> That makes sense indeed
<infinity> In the future, rebuilding from the web UI should work.
<sil2100> Ok, will remember that, although building it from the terminal was so convinient!
<infinity> The web ui is actually more convenient!
<infinity> Don't need a terminal and a screen session.
<cjwatson> I've said this before, but the easy-ish first step to making system-image more sensible is to split it off to a separate user.
<cjwatson> A separate machine would be good too, but is more work.
<cjwatson> Just a separate account removes access to cdimage keys, avoids the crontab awkwardness, etc.
<sil2100> infinity: oh, and while you're here, did you get my e-mail with -proposed britney questions by any chance?
<sil2100> hm, actually I remember you being on a sprint this week
<sil2100> cjwatson: yeah, I suppose that sounds like a sensible solution, a separate machine would require many changes in system-image itself
<cjwatson> Probably not hugely many, but at least more.
<cjwatson> AFAIK there's nothing non-trivial requiring them to share a user, though.
<cjwatson> The transition is a bit awkward and requires coordination with IS, but that should be about it ...
#ubuntu-release 2015-08-19
<sil2100> Dear release team! I disabled the daily rc-proposed auto-builds in cron for OTA-6 - will re-enable it once we have a release
<Mirv> an archive admin preNEW review/ack would be required for https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-028/+sourcepub/5311965/+listing-archive-extra - adds new binary packages mir-platform-graphics-mesa-x4, mir-client-platform-android3, mir-platform-graphics-android4, mirtest-dev, python3-mir-perf-framework, libmirplatform9, mir-client-platform-mesa3, libmirserver33, libmirprotob
<Mirv> uf1, mir-platform-graphics-mesa-kms4
<Mirv> a quick view to the packaging diff at https://ci-train.ubuntu.com/job/ubuntu-landing-028-2-publish/lastSuccessfulBuild/artifact/mir_packaging_changes.diff
<slangasek> infinity: in fact I believe sil2100 was given access to nusakan for management of system-image, for which there's no web ui.  The correct fix there of course is to decouple system-image from nusakan
<tjaalton> I have a skylake gpu hang fix for mesa, but wonder if it could be fast-tracked with the current SRU in progress (bump to 10.5.9, been on proposed for a few weeks now)?
<tjaalton> the patch only affects intel gen9, so no chance of regressing others
<cjwatson> stgraber: would you have a preferred username on nusakan for the system-image bits if I were to, say, request that IS create a new user and chown -R /srv/system-image.ubuntu.com/ to that?
<cjwatson> its sudo access group could start out with the same membership as cdimage, and then be pared down
<ogra_> cjwatson, +1 ... just call it systemimage ? (or systemimg for the shortness)
<ogra_> (i dont think stgraber actually even touches that bit much anymore, its more slangasek and sil2100 nowadays)
<sil2100> cjwatson: I'm +1 on that as well, but would prefer slangasek to state his opinion first
<slangasek> cjwatson: can we vote on the username?
<slangasek> (i.e.: I do not care ;)
<Mirv> a re-request on pre-binNEW reviewing of https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-028/+sourcepub/5311965/+listing-archive-extra - packaging changes at https://ci-train.ubuntu.com/job/ubuntu-landing-028-2-publish/lastSuccessfulBuild/artifact/mir_packaging_changes.diff (approved by a core-dev already)
<Mirv> new binaries are listed at the top of the latter link
<stgraber> cjwatson: I don't really care since I hardly touch system-image those days but if we are to create new role users and sudo permissions, I'd pretty strongly recommend we keep the system-image directory structure to be owned by cdimage but have a role account which has sudo privileges only for the binaries under /srv/system-image/bin (or whatever the real path is, at a conference and VPN sucks), so the members would be able to promote image
<stgraber> but then again, I'm known for being a bit on the paranoid side when it comes to ACLs ;)
<cjwatson> stgraber: If you want privilege separation, it should be yet a third account - it has no business being owned by cdimage, I think
<cjwatson> stgraber: Or owned by system-image but with limited sudo for people who need to promote
<stgraber> cjwatson: yeah, that'd be fine I guess
<sil2100> Hello release team! I would like to apologize for the media-hub upload to vivid that happened just now (3.1.0+15.04.20150819-0ubuntu1) - it was a misconfiguration on the CI Train side
<cjwatson> sil2100: does that mean we should reject it?
<sil2100> cjwatson: yes, if it didn't happen already
<sil2100> Apologies for that
<cjwatson> sil2100: done
<sil2100> Thank you!
<flocculant> xubuntu wily daily appears to have not built today, not sure why, build log doesn't tell me much ...  only recent change that I am aware of is blacklisting 2 LO styles
<flocculant> if someone could perhaps let me know if they can see what's up that would be great
<sil2100> flocculant: hey! I just checked that
<sil2100> flocculant: I suppose it should be good now, the xubuntu seeds seemed to have libxp6 in them but slangasek removed those and uploaded
<sil2100> flocculant: the next xubuntu wily build should work
<sil2100> Everything is installable in a chroot as well, so all is good now
<flocculant> sil2100: awesome - thanks for looking into that for us
<sil2100> You're welcome :)
<flocculant> :)
<Odd_Bloke> Could someone look at accepting cloud-init into {precise,trusty,vivid}-proposed?
<zul> hi, python3-oslo.service is not in main, but python-oslo.service is in main, can python3-oslo.service be promoted as well, its causing sever depwaits
<cjwatson> zul: done
<zul> cjwatson: thanks
#ubuntu-release 2015-08-20
<Mirv> repeating from yesterday, I'd wish for an archive admin to check https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-028/+sourcepub/5311965/+listing-archive-extra like they would if it would be in binNEW queue. packaging changes acked by a core-dev so just needs an approval from an archive admin to approve the new binaries that are listed at the top of https://ci-train.ubuntu.com/job/u
<Mirv> buntu-landing-028-2-publish/lastSuccessfulBuild/artifact/mir_packaging_changes.diff
<Mirv> if the Mir can't be reviewed today, I hope it being in the landing PPA and NEW review requested here counts as same as if it would be in the queue, since otherwise after today we'll need to file FFe...
<tjaalton> anyone to ack mesa (vivid) and mesa-lts-vivid (trusty) for me, urgent skylake bugfix there and don't want to push it through myself
<tjaalton> there's an older sru still in progress, but it's fine to postpone that so that these go in -updates together
<tkamppeter> There are many packages stuck in wily-proposed, like cups and cups-filters. They built correctly on all supported platforms but did not advance to the release for hours. What is happening here?
<cjwatson> https://wiki.ubuntu.com/ProposedMigration
<cjwatson> building everywhere is only one criterion
<cjwatson> anyway, they just migrated it seems
<cjwatson> so not stuck
<tkamppeter> Traffic jam due to FF?
<cjwatson> unlikely
<cjwatson> in fact those packages were waiting for dbus to be ready, which needed https://launchpad.net/ubuntu/+source/dbus/1.9.20-1ubuntu2 - I suspect before that a bunch of tests were breaking
<cjwatson> so business as usual, proposed-migration was holding back a set of things which would/could have been broken.  in future use the links from that wiki page to diagnose things first
<tkamppeter> Thanks.
<tkamppeter> hplip made it into the release now.
<flexiondotorg> cjwatson, deja-dup-caja has been in the wily new queue for some weeks now. Who can I talk to get it approved?
<cjwatson> Somebody else on the archive team, I guess, I'm not doing NEW processing routinely
<flexiondotorg> cjwatson, Is there a channel better suited for this? can you point me a someone please?
<cjwatson> This is the right channel, I don't know what other people's schedules are like though
<flexiondotorg> If someone could kindly review deja-dup-caja I would be most grateful.
<Mirv> also the Mir binNEW-via-PPA please :)
<Odd_Bloke> arges: Stop talking to Brad and accept the cloud-init uploads to proposed!
<arges> Odd_Bloke: i'll take a look
<Odd_Bloke> arges: :)
<arges> Odd_Bloke: bug 1470890, bug 1470880, are these fixed in wily?
<ubot93> bug 1470890 in cloud-init "[SRU] cc_apt_configure does not understand regions" [High,In progress] https://launchpad.net/bugs/1470890
<ubot93> bug 1470880 in cloud-init "[SRU] GCE datasource reports availability zones incorrectly" [High,In progress] https://launchpad.net/bugs/1470880
<Odd_Bloke> arges: I thought so, but let me confirm.
<Odd_Bloke> smoser does releases every so often.
<Odd_Bloke> And releases to the beat of his own drum. :p
<Odd_Bloke> arges: Yes, they are both fixed in wily.
<Odd_Bloke> arges: I think I chose not to mark them as such because I couldn't add the older versions to the bug to keep tracking those...
<arges> Odd_Bloke: ok i'll mark them as such
<arges> Odd_Bloke: ok all done
<Odd_Bloke> arges: You're the best, thanks!
<infinity> bdmurray: Remind me if there's a way to see what error reports *I* have sent to errors.ubuntu.com?
<bdmurray> infinity: you or a system of yours?
<infinity> bdmurray: The latter, obviously, I realise the former is impossible.
<bdmurray> http://errors.ubuntu.com/user/$(cat /var/lib/whoopsie/whoopsie-id) <- something like that
<bdmurray> infinity: ^
<infinity> bdmurray: Excellent, now I just need a firefox plugin that expands $() in URIs.
<infinity> ... as root, apparently.
<infinity> That wouldn't be insecure AT ALL.
<infinity> bdmurray: Okay, cool, thanks.  Just wanted to make sure my recent submissions were part of the large bucket that looked similar at a glance (and they are).
<bdmurray> infinity: great
<barry> infinity: are you still around?
<infinity> barry: Depends who's asking.
<barry> infinity: me, if you are, slangasek if you're not
<infinity> barry: That wasn't a confusing response.  Perhaps more importantly, why are you asking? ;)
<barry> infinity: any chance you could just ignore ubuntu-drivers-common for python3-defaults promotion?  it's the only blocker and it ftbfs for reasons i have no clue about.
<infinity> barry: In wily?
<barry> infinity: yep
<barry> i'll file a bug on u-d-c
<slangasek> infinity: 'firefox http://errors.ubuntu.com/user/$(sudo cat /var/lib/whoopsie/whoopsie-id)' works fine ;)
<infinity> barry: Kay, I found an old autopkgtest result that shows ubuntu-drivers-common from the release pocket being happy with that version of py3-defaults, so that's fine by me.
<barry> infinity: awesome, thanks.  and with that we should finally have py35 as supported.  slangasek ^^
<slangasek> barry: huzzah
<barry> just in time for feature freeze eh?
<infinity> barry: Committed.
<barry> infinity: thanks!
<infinity> slangasek: PS, I'm going to need an FFe for glibc 2.22, since I probably don't have the time to rebase, test, and upload today. :P
<slangasek> infinity: do you have it in git yet?  I bet you could do it if everything was in git
<infinity> slangasek: I'm pretty sure that wouldn't help.
<slangasek> infinity: tests always happen faster for packages that are in git
<infinity> slangasek: Last I checked, git only magically applies commits that already apply, it doesn't have AI.
<rbasak> infinity: I have a merge pending review/sponsorship. It's amavisd-new. Didn't manage to finish reviewing it today as it's non-trivial. Mind if I upload it tomorrow, given that the sponsoree has submitted it already? Or do we consider FF hard for sponsorees at upload time?
<infinity> rbasak: Late and correct is better than rushing to meet a deadline.
<rbasak> infinity: OK, thanks.
<barry> infinity: i'll use that when i ffe django 1.8 to work with py3.5 ;/
<infinity> barry: There's nothing correct about cjango.
<infinity> d...
<barry> you had me at cjango
<slangasek> infinity: why did denneed04 just fail to find packages on the internal mirror? https://launchpad.net/ubuntu/+source/pdf2djvu/0.7.21-2ubuntu1/+build/7822488
<infinity> slangasek: I have no idea.
<infinity> That should never happen.  Ever.
 * infinity scratches his head.
<slangasek> infinity: that's why I'm raising it to you
<slangasek> ok wow, there's an interesting architecture-dependent test failure? https://launchpadlibrarian.net/215154439/buildlog_ubuntu-wily-ppc64el.cuneiform_1.1.0%2Bdfsg-5build2_BUILDING.txt.gz
<infinity> slangasek: Wat.  That debhelper version was overridden in the release pocket a week ago.
<slangasek> "overridden"?
<infinity> slangasek: Superseded.
<slangasek> mmk
 * infinity checks ftpmaster...
<infinity> Err http://ftpmaster.internal wily Release
<infinity> Oh.
<infinity> That's why.
<slangasek> oh hey, that cuneiform build has been broken since 2011. https://bugs.launchpad.net/ubuntu/+source/cuneiform/+bug/791305
<infinity> slangasek: Okay, nothing to see here, just retry the build.
<ubot93> Launchpad bug 791305 in cuneiform (Ubuntu) "cuneiform version 1.1.0+dfsg-1 failed to build on armel" [Undecided,New]
<infinity> slangasek: It hit the race where Releases is downloaded before the dists switch and Packages after.
<slangasek> grr
<infinity> slangasek: The race fixed in apt 1.1 with hashed Releases.
<slangasek> right
 * slangasek syncs apt from experimental
<slangasek> problem solved
<infinity> slangasek: Hence why you had an apt source from a week ago (the one in the chroot already).
<infinity> slangasek: I guess the error would be more obvious if I deleted /var/lib/apt/lists entirely from devel chroots.
<infinity> I keep it in stable ones to save bandwidth/time, since the release pocket never changes.
<cjwatson> oh hai, the release schedule says we should stop auto-syncing now
 * cjwatson adds --dry-run to crontab
<bluesabre> cjwatson: don't suppose you could add shimmer-themes back to the xubuntu packageset? It keeps getting pulled into kubuntu by a recommends in breeze
<cjwatson> bluesabre: can't, you need to ask somebody in ~developer-membership-board
<cjwatson> not been in my wheelhouse for a couple of years
<bluesabre> :)
<bluesabre> thought I'd try to grab you since I saw you, I'll bug micahg some more ;)
<bluesabre> bbiab
<cjwatson> anyone in https://launchpad.net/~developer-membership-board/+members should be able to sort that kind of thing out
<Ukikie> Something cjwatson isn't in control of? :3
<cjwatson> hey, in recent years I've been trying to decrease my load :P
<Ukikie> So they gave you Launchpad. :)
<cjwatson> That was in exchange for stopping doing other stuff :)
<cjwatson> (Quite explicitly; I was burning out)
<Ukikie> That's always rough.
#ubuntu-release 2015-08-21
<Mirv> like on Wed and Thu, I'd like to request preNEW binary review of the new Mir: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-028/+sourcepub/5311965/+listing-archive-extra - packaging changes already acked by a core-dev. a list of the new packages at the top of https://ci-train.ubuntu.com/job/ubuntu-landing-028-2-publish/lastSuccessfulBuild/artifact/mir_packaging_changes.diff
<Mirv> I'd like it to be considered "having been in the queue" (as much as CI Train packages can) before FF so that FFe would not be needed
<zequence> How is wubi.exe included onto the ISOs?
<davmor2> zequence: it sit in a archive and is pulled in aiui
<zequence> davmor2: How can I make it so it isn't included onto Ubuntu Studio ISOs?
<davmor2> zequence: one for slangasek ev or stgraber maybe
<zequence> thanks
<lordievader> Is wubi still supported?
<davmor2> lordievader: no
<lordievader> Good ;)
<Mirv> ^ if the archive admin handling those would be so kind, see the Mir preNEW review request above
<rbasak> I swear I sponsored a cifs-utils merge yesterday but Launchpad doesn't seem to have it and I never got an email back it seems.
<rbasak> I have an .upload file though that says everything was uploaded successfully
<rbasak> Any tips? I could just try re-uploading I suppose.
<cjwatson> 2015-08-20 16:34:15 INFO    Failed to parse changes file '/srv/launchpad.net/ubuntu-queue/incoming/upload-ftp-20150820-163358-019341/ubuntu/cifs-utils_6.4-1ubuntu1_source.changes': GPG verification of /srv/launchpad.net/ubuntu-queue/incoming/upload-ftp-20150820-163358-019341/ubuntu/cifs-utils_6.4-1ubuntu1_source.changes failed: Verification failed 3 times: ["(7, 9, u'No public key')", "(7, 9, u'No public key')", "(7, 9, u'No public ...
<cjwatson> ... key')"]
<cjwatson> did you sign it?
<rbasak> My local version is signed here, and gpg verifies
<cjwatson> I would suggest reuploading then, possibly a weird keyserver glitch
<rbasak> I might have done something stupid like uploaded before signing though
<rbasak> OK, I'll retry - thanks.
<cjwatson> you could verify that by timestamp checks
<cjwatson> .changes vs. .upload
<rbasak> Good point
<rbasak> .changes is older than old .upload.
<rbasak> So it looks like it was signed
<rbasak> It has worked this time.
<rbasak> Thanks!
<cjwatson> ok, cool
<cjwatson> Mirv: AA ack for mir; more new binaries than usual but I've looked things over and they look right to me
<Mirv> thank you, kind sir cjwatson
<coreycb> hello, can an archive admin please promote python(3)-fasteners to main? this will help get some of our openstack packages out of dependency waits.
<cjwatson> coreycb: done
<coreycb> cjwatson, thanks
<cjwatson> also moved python3-{appconf,jingo,oslo.messaging}
<coreycb> cjwatson, great, thank you
<Trevinho> Hi, we've libxpathselect blocked on silo because of autopilot failures (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#xpathselect), however those falures aren't caused by libpathselect change (which is just a rebuild against gcc5)... As you can see in the CI history those failures happened even with previous versions, and
<Trevinho> are all due to AP itself
<flexiondotorg> Laney, I'm happy to help out with Beta 1 just like last time.
<flexiondotorg> Laney, I've replied on the ML and updating the wiki now.
#ubuntu-release 2015-08-22
<Laney> thanks flexiondotorg
<cyphermox> network-manager, I hate you
<ogra_> no worries, it hates you as well
<cyphermox> I know, right?
<cyphermox> doko: looks like it's possibly not even NM, things "magically" worked on ppc64el, still fail on arm64
<Laney> I 'ate you
<Laney> cyphermox: you probably want make check VERBOSE=1
 * Laney is writing a debhelper patch to do this by default
<Laney> they seemed fine with having that
#ubuntu-release 2015-08-23
<Logan> wait what, we're in feature freeze?
<Logan> I never got any notification of this
#ubuntu-release 2016-08-22
<pitti> sergiusens: xenial snapcraft tests are done
<pitti> flocculant: Laney fixed it (thanks!), should be all good now, right? unfortunately this wasn't obvious on ubuntu desktop
<flocculant> pitti: yup all seems fine thanks. And yes, it wasn't obvious anywhere but xubuntu and mate - I did check those, ubuntu, lubuntu and gnome :)
<flocculant> studio would have been broken too - but that appears to have other issues anyway - no dailies since the 18th
<sakrecoer> thanks for bringin it up flocculant . atm there is something with gnupg1
<sakrecoer> but the few times i've tried to install the iso after it build successfully, the installation would fail (Ubuntu-Studio that is)
<Mirv> could someone remove s390x binaries for src:ubuntu-system-settings-online-accounts in yakkety? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-system-settings-online-accounts
<pitti> Mirv: y-release already does not have s390x binaries
<pitti> Mirv: the problem is that the new version in -proposed builds them
<pitti> Mirv: i. e. the package wasn't changed to not build on s390x
<pitti> like that we'd need to manually remove the binaries for every new upload, that's impractical
<pitti> Mirv: you could also make the removed package, like libsystemsettings-dev, a build-depends
<pitti> (nicer than mangling Arch:)
<flocculant> infinity: studio's iso is stuck rebuilding since Saturday. Also has some issues which mean little to me according to the build logs
<flocculant> or Laney if Laney really is being brave and doing b1 for people :p
<Mirv> pitti: right, I was under impression they had already integrated a change like that in this release, but it seems not. I will propose MP myself if they don't have one.
<Mirv> pitti: actually, it seems they already do build depend on libsystemsettings-dev, they just apparently had built this build in a silo at a time when u-s-s was again available
<Mirv> https://launchpadlibrarian.net/273706024/ubuntu-system-settings-online-accounts_0.7+16.10.20160718-0ubuntu1.diff.gz debian/control
<pitti> Mirv: oh, ok; so if we remove those, the next build should work as intended?
<Mirv> pitti: so it would look like to me, as libsystemsettings-dev is unavailable on s390x now
<pitti> Mirv: done
<pitti> Mirv: the version number is odd, though -- July 18 is over a month ago
<Mirv> thank you. and u-s-s itself has now a dependency on upstart to prevent those binaries from resurfacing.
<Mirv> pitti: it languished in a silo for a longer period as the silo had other package that needed fixes and rebuilds while this remained non touched. then QA took its time, and then we delayed the publishing to yakkety in order to get the transition done.
<Mirv> but seems all normal according to ticket logs
<Mirv> also in the middle there was two weeks of "nothing happened" it seems, so upstream was doing something else or on holidays
<pitti> ack
<Mirv> not sure why but I can't see the removal at https://launchpad.net/ubuntu/yakkety/s390x/ubuntu-system-settings-online-accounts
<mvo> hi, quick question - snap-confine appears to be ready for release into xenial-updates, its in there for 9 days and all bugs are verification-done. anything else that needs to happen here?
<mvo> i.e. anytihng we can do to help :)
<pitti> mvo: no, JFDI thing; it wasn't old enough on Friday yet, then weekend :)
 * pitti does a round of releasing
<pitti> hm, all the bugs are still marked unfixed in y
<mvo> pitti: ha! indeed, this weekend thing
<mvo> pitti: oh, let me double check that
<pitti> mvo: e. g. bug 1612684 says that it will be released in 1.0.40 which isn't in y yet
<ubot5> bug 1612684 in snap-confine (Ubuntu) "dies when run in a place that is not inside the snap chroot" [Undecided,New] https://launchpad.net/bugs/1612684
<pitti> so it's not just "missing changelog ref", but actually missing
<mvo> pitti: yes, let me chase that, sorry, I assumed it was already uploaded but was wrong
<Mirv> pitti: it feels your removal didn't work http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-system-settings-online-accounts ( + the https://launchpad.net/ubuntu/yakkety/s390x/ubuntu-system-settings-online-accounts )
<xnox> looks like it needs to be removed again in yakkety-proposed/s390x, or the removal was not published yet.
<sakrecoer> this was brought to my attention: http://people.canonical.com/~ubuntu-archive/cd-build-logs/xubuntu/yakkety/daily-live-20160822.log seems the build was succesfull, but the tracker it is nowhere to find
<sakrecoer> wait.. sorry.. that is not studio ..
<LocutusOfBorg> hi cjwatson sorry for bothering, but I don't think your haskell-werewolf removal worked
<LocutusOfBorg>  libghc-werewolf-dev | 1.0.2.2-1build2 | yakkety-proposed/universe | powerpc
<LocutusOfBorg> it is a removal that affects -proposed only (it built here by error)
<ogra> not enough silver bullets ?
<LocutusOfBorg> I hope to see haskell-migrate later today or something similar, if my guessing is correct
 * davmor2 hands ogra more silver bullets
<LocutusOfBorg> or any other archive admin, removing a package that never landed on yakkety release should be "easy" (for an unknown to me value of easy)
 * apw notes that is two complaints of removals not seeming to have worked ...
<cjwatson> LocutusOfBorg: I never removed haskell-werewolf/powerpc; my logs tell me that the one you asked me for was haskell-http-link-header/powerpc.
<cjwatson> (Removals don't work if they weren't asked for.)
<apw> :)
<cjwatson> LocutusOfBorg: removed now
<sakrecoer> sorry for nagging, but.. any chance ubuntu studio will have an iso ready today/tonight?
<sakrecoer> the error seem to be "gnupg1 : Breaks: gnupg (< 1.4.20-6+exp1) but 1.4.20-6ubuntu1 is to be installed kactivitymanagerd : Breaks: kactivities (< 5.20~) but 5.18.0-0ubuntu1 is to be installed"
<sakrecoer> i'm affraid i'm not very technical, but if there is anything i can do to help make it easier, let me know :)
<apw> the first of those looks a little like they have renamed gnupg to gnupg1 in debian, which will wreak havoc with our delta
<xnox> apw, yeah, and we need to merge new gpg2 to take that.
<xnox> surely kactivitymanagerd should do depend on gnupg for now in ubuntu or some such.
<xnox> or we should just merge new gnupg in place.
<jbicha> Mirv: do you know what specific s390x packages should be removed for qtorganizer5-eds for the evolution 3.22 transition?
<jbicha> xnox: I think it would be better to do the ggp transition after beta 1 (livecd-rootfs uses gpg for instance)
<renatu> Hey guys. Could you remove binaries of sync-monitor from yakkety/sync-monitor. to unblock this silo? https://requests.ci-train.ubuntu.com/#/ticket/1827
<renatu> yakkety/s390x
<robru> pitti: infinity: can you two discuss the correct checkUpload call I should use in the case that the source package is NEW? infinity already chose flashplugin-nonfree/universe when the code was initially written but pitti says this is invalid. I'm not sure what would be correct.
<cjwatson> It's probably a Launchpad bug that sourcepackagename is required there.
<cjwatson> The underlying code allows querying without a sourcepackagename; it's just not declared that way in the webservice interface.
<robru> cjwatson: right, but I still need something to use for now. infinity chose flashplugin-nonfree/universe, pitti says flashplugin-nonfree is in multiverse so this is invalid, but it's been working in production for many months.
<robru> I'm not sure if we should pick a different source package name that's really in universe or just leave it
<pitti> robru: or change universe to multiverse
<pitti> robru: but I think taking an actual universe package is more correct, as train uploads usually don't go into multiverse
<robru> pitti: I don't believe that's correct, the purpose of the test is to ensure that the person has permission to upload to universe, which is the default place for NEW uploads.
<pitti> but yes, flashplugin-nonfree/universe is not a thing
<robru> pitti: but apparently testing if the user has permission to  upload flashplugin-nonfree into universe is successful at determining if the user has permission to upload NEW things into universe.
<pitti> robru: oh -- then please don't call it flashplugin-nonfree, but "i-am-a-new-package" or so
<pitti> semantically, *nobody* should be able to upload flashplugin-nonfree to universe
<robru> pitti: I was under the impression that it needed to be an existing package that could never ever be in main.
<pitti> robru: maybe this is supposed to catch some weird corner case or LP API quirk, but then it deserves a long comment :)
<pitti> like that it looks just plain wrong
<robru> pitti: if "i-am-a-new-package" would have worked then we would have just used the actual name of the package. infinity was the one who came up with this as-is
<pitti> well, I couldn't even say what it *means* to upload flashplugin-nonfree to universe
<pitti> that's simply an invalid question
<pitti> well, that's all what I can say about it :) maybe infinity remembers the specifics, then I suggest documenting this in a comment
 * pitti bids good night
<sergiusens> slangasek hi, mind letting snapcraft into xenial-updates?
<slangasek> sergiusens: done; NB this shouldn't block on me, we have a weekly rotation for the SRU team: https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
<sergiusens> slangasek yeah, sorry, I just lazily picked you as you were up to speed with the status for this
<renatu> pitti, Hi, Could you help me. I need remove binaries of sync-monitor from yakkety/s390x. to unblock this silo? https://requests.ci-train.ubuntu.com/#/ticket/1827
<slangasek> renatu: it's a bit out of pitti's work hours; let me see
<renatu> slangasek, thanks
<slangasek> renatu: resolved.  so the version currently in yakkety-proposed will need to land first, which I think will mean
<slangasek> renatu: landing-053 will need to merge the result of that landing and rebuild?
<slangasek> (I'm assuming sync-monitor 0.2+16.10.20160804-0ubuntu1 is a landing, though I don't easily find the ticket)
<renatu> slangasek, I do not think that we have any sync-monitor pending to land
<renatu> let me re-check
<slangasek> renatu: well, the binaries I just removed are from yakkety-proposed; did someone force-merge a landing that wasn't in yakkety yet?
<slangasek> renatu: https://launchpad.net/ubuntu/+source/sync-monitor/0.2+16.10.20160804-0ubuntu1 look familiar?
<renatu> let me see
<slangasek> appears to be this landing: https://requests.ci-train.ubuntu.com/#/ticket/1643
<renatu> humm yes, this was approved recently
<renatu> ok I will make sure to merge it before land my silo
<slangasek> so someone force-landed it
<renatu> thanks
 * slangasek nods
<slangasek> robru: ^^ seems a bad use of force-merge fwiw, since that landing was stalled indefinitely in yakkety-proposed due to uninstallable s390x binaries
<robru> slangasek: Mirv did that one, it's possible some other issue obscured the s390x issue at the time it was forced?
<slangasek> now running through http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html for other instances of '/s390x unsatisfiable Depends', should let us clear up a few more landings
<slangasek> robru: sure, possible :)
<robru> This s390x thing just won't die
<slangasek> well, as has been noted, the ubuntu phone stack's dependency on upstart needs to be transitioned to systemd
<robru> slangasek: might be easier to just delete all of s390x and start over rather than pick apart all these binaries ;-)
<slangasek> nope
<robru> Heh
 * slangasek wonders who subscribed foundations-bugs to libstring-copyright-perl without filing an MIR
 * slangasek wonders if it was himself
<slangasek> oh hey, haskell stuff migrating?
<sakrecoer> hello, our iso still fails for same reason. we are having troubles finding what is using gpg1, we have no working image to look in... could this have something to do with it? https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/1615039
<ubot5> Launchpad bug 1615039 in gnupg2 (Ubuntu) "[FFe] /usr/bin/gnupg --version should be 2.1" [Undecided,New]
<sakrecoer> our= ubuntustudio
<LocutusOfBorg> haskell is migrating :)
<slangasek> sakrecoer: sakrecoer where are you seeing the error in question?
<renatu> slangasek, hey got the same error again: https://requests.ci-train.ubuntu.com/#/ticket/1827
<sakrecoer> slangasek: here: https://launchpadlibrarian.net/280394054/buildlog_ubuntu_yakkety_i386_ubuntustudio_BUILDING.txt.gz
<sakrecoer> gnupg1 : Breaks: gnupg (< 1.4.20-6+exp1) but 1.4.20-6ubuntu1 is to be installed kactivitymanagerd : Breaks: kactivities (< 5.20~) but 5.18.0-0ubuntu1 is to be installed
<jbicha> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/ubuntustudio
<slangasek> robru: does something need manually rerun so that renatu's landing (https://requests.ci-train.ubuntu.com/#/ticket/1827) doesn't show as 'dep-wait' on an arch that is not out-of-date?
<sakrecoer> thank you jbicha
<robru> slangasek: status job runs every 20 minutes
<slangasek> sakrecoer: what is referencing gnupg1, and why?
<sakrecoer> slangasek: we can't seem to find out. we have no working image to check with.
<robru> slangasek: how long ago did you delete the binaries?
<slangasek> robru: 2 hours ago
<slangasek> sakrecoer: python3-gnupg Depends: gnupg1; this is buggy, looks like it was a bad autosync, right before DIF.
<robru> slangasek: according to https://launchpad.net/ubuntu/+source/sync-monitor/0.2+16.10.20160804-0ubuntu1 s390x is still there
<slangasek> sakrecoer: so someone needs to fix that to depend on gnupg (< 2) in preference to gnupg1
<slangasek> robru: the build record doesn't disappear just because the binaries had been deleted
<sakrecoer> slangasek: ok, any suggestion on a someone succeptible to fix that i can reach out to?
<robru> slangasek: that says that was published 30 minutes ago. what did you delete 2 hours ago?
<slangasek> robru: it was published to yakkety from yakkety-proposed. the deletion of the binaries from s390x 2 hours ago is what /allowed/ it to publish
<jbicha> sakrecoer: deken depends on python-gnupg which depends on gnupg1
<jbicha> found by digging through germinate
<robru> slangasek: I don't know what to tell you. bileto is looking at the package and seeing successful s390x builds and thus reporting the s390x failures in the PPA.
<slangasek> robru: "and seeing successful s390x builds and thus reporting" - ok, then it's a bileto bug ;)
<sakrecoer> thanks you jbicha! :)
<robru> slangasek: I doubt it, this code has been working well for months and I haven't touched it
<sakrecoer> thank you slangasek
<slangasek> robru: what you have just described is a wrong check
<jbicha> sakrecoer: here, let me revert python-gnupg to 0.3.8-2 to see if that fixes things for this week
<slangasek> robru: the package built previously on s390x.  The binaries were then removed.  Bileto needs to know whether the new version of the package is regressing architecture support, which it doesn't know by looking at whether the package previously built, it has to look at whether the built binaries are removed
<robru> slangasek: this is how it's been even since lp:cupstream2distro, no problems for months and months and months. http://bazaar.launchpad.net/+branch/bileto/view/head:/bileto/worker/package.py#L127
<slangasek> robru: telling me that no one has reported this bug to you is not a counterproof
<sakrecoer> thank you very much jbicha !
<robru> slangasek: I'm telling you that it has never failed to correctly determine what arches we care about.
<slangasek> jbicha: why would you revert python-gnupg, instead of just adjusting the dependency as I suggested above?
<robru> slangasek: if getPublishedBinaries is reporting more binaries than there should be, then it's a bug in lp.
<slangasek> robru: ah, you didn't say you were checking getPublishedBinaries, which *is* the correct check AFAIK
<jbicha> slangasek: because they actually changed the code to gpg1 https://launchpadlibrarian.net/279890088/python-gnupg_0.3.8-2_0.3.8-3.diff.gz
<robru> slangasek: ah yes, I said "builds" by mistake, I meant binaries.
<slangasek> jbicha: that sounds like a good reason
<robru> slangasek: maybe you deleted binaries for some binary packages but not all binary packages produced by that source?
<slangasek> robru: the only ones I didn't delete were the architecture: all ones; I suppose that could be the issue, let me see
<slangasek> robru: (I've generally assumed that when removing binaries with -a <arch>, I don't need to remove the arch: all ones - AFAIK they'll just come right back on the next build since the arch: all binaries are published for all archs, so I wouldn't expect bileto to care about this)
<robru> slangasek: hm, shouldn't be arch: all, it does specifically filter out binaries that are architecture_specific=False
<slangasek> ok
<slangasek> then it may simply be that as of the last status job run, LP was still catching up
<jbicha> sakrecoer: done, so we'll just have to retry the iso build tomorrow once germinate has picked up the change
<robru> slangasek: I'm gonna head out for lunch, will follow up later
<sakrecoer> jbicha: you rock! thanks!!! :)
<sakrecoer> i'm signing off, read you tomorrow! o/
<jbicha> sakrecoer: for reference, I used https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntustudio.yakkety/all
<renatu> slangasek, robru, The silo was ok some time ago. But it change to failed recently
<renatu> slangasek, it was ok when you told me that you had deleted the package. But then after I mark it as approved it changed to fail
<renatu> I am not sure if is related with the fact that I marked it as approved
<robru> renatu: no, marking it as approved won't make it start considering more architectures
<robru> slangasek: this is what bileto is seeing in lplib: http://paste.ubuntu.com/23079883/
<slangasek> robru: heh; then perhaps that's a britney bug, because those are the same binaries I removed from yakkety-proposed
<slangasek> robru: so, removing them again :)
<robru> slangasek: thanks
<flocculant> slangasek: not sure who best to point this at (possibly cyphermox) but using iso from today - which had installed perfectly with UK language and UK keyboard - installer crashed when I tried to use French - seem to be a few dupes of this bug, bug 1615847
<ubot5> bug 1615847 in ubiquity (Ubuntu) "Ubiquity crashes with non english setup" [Undecided,New] https://launchpad.net/bugs/1615847
<flocculant> hesitating to set bugs as dupes, but journal errors seem to be the same
<slangasek> "could not convert string to float" lol ok
<flocculant> slangasek: I gave up trying to write the description with a french layout and opted for editing it afterwards:)
<flocculant> anyway - thanks for looking there
 * flocculant wanders off again
#ubuntu-release 2016-08-23
<cyphermox> flocculant: yes, this is a very ugly bug
<slangasek> cyphermox: I can't work out from the code where the formatted strings are coming from, do you know?
<cyphermox> that's what's terrible
<cyphermox> slangasek: looks like they come from apt, which has always been outputting things in a sprintf using '%.4f', but now is setting locale more forcefully
<slangasek> right, I assumed apt but couldn't find where in the python code apt was being invoked :)
<cyphermox> unfortunately, this means including LC_NUMERIC; so your 0.0000 in .4f becomes 0,0000 in fr and es, for example
<cyphermox> it's sometimes python-apt, sometimes called through debconf-apt-progress
<cyphermox> master bug is bug 1611010
<ubot5> bug 1611010 in apt (Ubuntu) "yakkety desktop - non-english installation crashes with /plugininstall.py: ValueError: invalid literal for int() with base 10: ''" [Critical,Confirmed] https://launchpad.net/bugs/1611010
<cyphermox> slangasek: I just wasn't prepared to patch apt directly before talking to juliank or someone else about it, but looks like it ought be be fixed there.
<jbicha> please try a rebuild of Ubuntu Studio's yakkety iso's, germinate does not show gnupg1 now
<Mirv> slangasek: robru: that force-merge was related to the transition and the need to do next landing to OTA-13 for the affected package. it was then added to our backlog list of "monitor migration to release pocket manually", which is why we asked for the removal of the s390x binaries now.
<Mirv> (the backlog list is now quite short http://pad.ubuntu.com/yakkety-pending-landings )
<robru> Mirv: thanks for clarifying
<Mirv> oh, and sync-monitor migrated, great
<Mirv> and someone did the online-accounts too eventually so I think that list might be down to zero, let's see
<slangasek> yeah, I did that one when I was looking through update_excuses output for other stale s390x binaries; those were the only two I saw
<Mirv> slangasek: yeah I asked pitti for it yesterday, he said he did it but apparently something went wrong and they weren't removed. anyway, it unblocked the four pending packages, while sync-monitor was fifth so now the backlog is cleared! thanks!
<pitti> hmm, I did this:
<pitti> remove-package -s yakkety-proposed -b -a s390x -m 'dependencies got removed on s390x' ubuntu-system-settings-online-accounts libonline-accounts-client1 libonline-accounts-client-dev qtdeclarative5-online-accounts-client0.1 qml-module-ubuntu-onlineaccounts-client qml-module-ubuntu-onlineaccounts-client-doc libonline-accounts-plugin-dev ubuntu-system-settings-online-accounts-autopilot
<pitti> (from my bash history)
<pitti> LP didn't raise an error, was that wrong or was there a fluke?
<Mirv> sounds correct, it just didn't seem to happen according to excuses page or when I checked https://launchpad.net/ubuntu/yakkety/s390x/ubuntu-system-settings-online-accounts
<Mirv> hmm
<slangasek> pitti: fwiw, your run doesn't show here: https://launchpad.net/ubuntu/yakkety/s390x/libonline-accounts-plugin-dev/
<slangasek> maybe you forgot to 'y' it?
<slangasek> (or LP bug)
<slangasek> oh, also britney did the thing again where the binaries I just removed from -proposed were copied to yakkety, sigh
<pitti> slangasek: I guess it was me then, or some fluke; I *do* see copy-package be ignored very often (i. e. sru-release, need to run it twice way too often), but I never saw remove-package silently fail that way
<pitti> so I guess I screwed up something
<pitti> but good to know for next time that this the right command in general
<jbicha> Mirv: could you check what's needed for the evolution 3.22 transition to finish? qtorganizer5-eds/s390x at least is a problem
<Mirv> jbicha: well we have pitti here now so maybe he could remove the s390x for it: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtorganizer5-eds - at least manually looking at the excuses page that would seem the only one. I will just need to double check if qtorganizer5-eds has been fixed to not bring back the s390x binaries accidentally.
<Mirv> so yes indeed it doesn't have the binaries and shouldn't be able to bring them back either. the s390x binaries should be removed from the release pocket version of qtorganizer5-eds.
<flocculant> slangasek: sorry - if I'd looked a bit further down the ubiquity bug list I might have seen the one jibel had commented on and not bothered you ;)
<flocculant> cyphermox: yep - not one I'd have seen if one of my testers hadn't said anything to be - ignorance is bliss sometimes
<sakrecoer> greetings, the Studio iso failed again. 'kactivitymanagerd : Breaks: kactivities (< 5.20~) but 5.18.0-0ubuntu1 is to be installed'
<sakrecoer> not sure i understand the germinate link jbicha gave me right, but it seems to be plasma framework and calligra that need kactivities..
<sakrecoer> i have to be afk for an hour now unfortunately.. but will read backlog of course
<Laney> sakrecoer: libkactivities6 has a Recommends on kactivities, which is a package that kactivities-kf5 has dropped
<Laney> yofel: ^- you might be interested in that knowledge
<sakrecoer> thank you Laney :)
<Laney> sakrecoer: #kubuntu-devel is a good place to ask about that
<sakrecoer> Laney: i will do reach out to them, thank you!
<jbicha> please remove qtorganizer5-eds/s390x
<renatu> slangasek, hey could you do another favor? Could you remove address-book-app from yakkety/s390 to unblock this silo: https://requests.ci-train.ubuntu.com/#/ticket/1815
<slangasek> renatu: there are no address-book-app binaries on s390x in yakkety; that silo says "needs a rebuild"?
<renatu> slangasek, hooo, this changed now. Let me re-build it
<renatu> thanks
<slangasek> jbicha: qtorganizer5-eds/s390x removed
<robru> slangasek: we also need indicator-network s390x deleted to unstick http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#indicator-network thanks
<slangasek> robru: done
<robru> slangasek: thanks!
<ginggs_> michi, michi_: hi, would you rebuild storage-framework against the current boost (1.61) please? i think a no-change rebuild should do it
<LocutusOfBorg> question: why can't vcmi migrate to yakkety release?
<LocutusOfBorg> old binaries left on amd64: vcmi-dbg (from 0.98+dfsg-2.1ubuntu2)
<LocutusOfBorg> isn't this stuff autodecrufted magically?
<Laney> not if it's NBS in proposed
<LocutusOfBorg> what does it mean?
<LocutusOfBorg> I did the ddbgsym migration stuff
<LocutusOfBorg> and in fact I see produced:  vcmi 0.98+dfsg-3  and  vcmi-dbgsym 0.98+dfsg-3
<LocutusOfBorg> of course I dropped the -dbg package...
<Laney> actually there's no automatic removal anywhere, but if you drop something and there's a binary left over in -proposed then it'll hold up the migration like this
<LocutusOfBorg> this is the commit https://anonscm.debian.org/cgit/pkg-games/vcmi.git/commit/?id=19efe46c326202a2de9830609b26961a6ea48d69
<Laney> If it's only left over in release then it doesn't, and just gets picked up in the NBS report for someone to act on later
<LocutusOfBorg> so, what Debian does automagically is done manually in Ubuntu?
<Laney> basically you need someone to delete that binary for you
<LocutusOfBorg> because Debian is removing the -dbg packages automatically on autodecruft AFAIK
<LocutusOfBorg> I never saw a migration hold because of a dbg package missing
<ginggs_> michi, michi_: nvm, i think that was a false positive because of what is in control, i looks like it actually built against the current version
<ginggs_> any ~ubuntu-archive around? please decruft supercollider-supernova and remove boost1.58
<Laney> sakrecoer: Are you my release buddy for beta 1 or is that someone else?
<Laney> I'm setting up the stuff now - freeze, ISO tracker milestone, stopping automated builds
<flocculant> Laney: not sure he's about currently - but yes he is and me in the background helping him out where necessary
<Laney> ok
<Laney> flocculant: I see: studio, GNOME, kubuntu, lubuntu - correct?
<flocculant> afaik yes
<flocculant> though I am surprised Mate aren't
<Laney> flexiondotorg: are you in?
<flocculant> Laney: from an old mail "For completeness Ubuntu MATE intend to participate in Alpha 1, Alpha 2, Beta 1 and final beta."
<Laney> cool, thanks
<flocculant> welcome :)
<Laney> tsimonq2: Do you want powerpc this time?
<sakrecoer> Laney: yeah, i am :)
<flocculant> Laney: obviously currently studio won't build - and I assume kubuntu won't either
<sakrecoer> well, i'm guided by tsimonq2 :)
<flocculant> sakrecoer: aah - didn't know you were awake :D
<tsimonq2> Laney: Lubuntu doesn't do PPC for non-LTS
<Laney> ok
<xnox> infinity, has the mark packages in main as 5year support happened in xenial 16.04.1
<Laney> flocculant: Kubuntu seems okay so far https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/kubuntu
<Laney> they must seed some different stuff
<slangasek> LocutusOfBorg: when a binary is in devel and is dropped from the version of package in devel-proposed, proposed-migration figures it out on its own.  But when a new version is uploaded to devel-proposed, and there was a previous unmigrated version already in devel-proposed that didn't migrate yet and built a different set of binaries, the archive admins have to figure it out by hand
<xnox> infinity, and/or do things need to be SRUed to get the 5 year marker?
<sakrecoer> Laney: studio iso still doesn't build though.. waiting for kubuntu user to join and help us with kactivitymanagerd
<LocutusOfBorg> thanks slangasek
<xnox> or shall i just seed the s390-tools?
<slangasek> LocutusOfBorg: (vcmi-dbg removed)
<LocutusOfBorg> thanks
<Laney> sakrecoer: That's fine: you have two days :P
<flocculant> Laney: don't you mean yakkety? https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/kubuntu
<sakrecoer> (and yes, flocculant has been a huge help)
<LocutusOfBorg> next time I'll do a fake upload removing the dbg and then a new upload force-syncd
<LocutusOfBorg> :)
<Laney> flocculant: oh right
<Laney> unlucky then :)
<flocculant> cos studio and kubuntu are having fun with the same things :p
<slangasek> ginggs_: supercollider-supernova> what needs decrufted where? this isn't listed on update_excuses or nbs
<Laney> then they also have two days to fix it
<flocculant> :)
 * flocculant likes the 'we're only doing final beta stance' that we took :D
<ginggs_> slangasek: reverse-depends src:boost1.58 - shows supercollider
<slangasek> ginggs_: and this was removed from Debian?
<xnox> demote to proposed?
<flexiondotorg> Laney, wrestling a large server deployment.
<flexiondotorg> But post and I'll catch you in a bit.
<ginggs_> slangasek: maybe i misread something, i thought these were old binaries left behind
<slangasek> xnox: hisss
<xnox> slangasek, or maybe i should fix it.
<xnox> slangasek, oh weait it looks like it depends on things only on some arches. smells fishy
* Laney changed the topic of #ubuntu-release to: Released: Trusty 14.04.5, Xenial 16.04.1 | Archive: feature freeze, beta 1 freeze | Yakkety Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<slangasek> well what I currently see is that supercollider has different package versions across different archs within yakkety
<slangasek> so... yum?
<ginggs_> slangasek:the supercollider-supernova binaries are only made for amd64, i386 and x32 now
<slangasek> yeah, so how did it get into yakkety before the old binaries were dropped
<xnox> but supercollider is built on all arches in yakkety
<sakrecoer> Laney: this list of particiaption should be accurate https://wiki.ubuntu.com/YakketyYak/Beta1
<Laney> sakrecoer: thx
<slangasek> well, it's mentioned in my force-hint for the Qt transition, but that shouldn't have the same effect as 'force'
<sakrecoer> interesting use of latin :D
<slangasek> ah I see
<slangasek> it's half-NBS :)
<xnox> http://people.canonical.com/~ubuntu-archive/architecture-mismatches.html looks strange too, but not for supercollider.
<slangasek> ginggs_: ok, removing
<ginggs_> slangasek: thanks :)
<xnox> storage-framework has only alternative deps
<ginggs_> xnox, slangasek: so boost1.58 can go now?
<xnox> ginggs_, i think so.
<Laney> Oops
<Laney> Don't know how to remove all those Kubuntu products
<xnox> slangasek, filed bug #1616130
<slangasek> ginggs_: yes, though I'm having a grump that 'remove-package' doesn't give me an option to remove only the source package and leave the binaries for NBS
<ubot5> bug 1616130 in boost1.58 (Ubuntu) "RM boost1.58, superseeded" [Undecided,New] https://launchpad.net/bugs/1616130
<xnox> but it will never be NBS, because there are alternative build-deps on boost1.58
<xnox> e.g. libboost-foo-dev | libboost1.58-foo-dev
<xnox> (as in green in NBS)
<slangasek> xnox: it's NBS as soon as the source is gone ;)
<slangasek> and AFAIK nbs is smart enough to work out alt deps
<tedg> I need an autopkgtest on s390x marked as okay instead of a regression: http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#url-dispatcher
<tsimonq2> stgraber: for the lubuntu-next images, I assume an update to queuebot is needed to add those?
<flexiondotorg> Laney, I'm available if you are.
<Laney> flexiondotorg: Never mind
<flexiondotorg> OK
<Mirv> yofel: hi! there's a whole bunch of kf/etc related autopkgtest issues again in excuses for qtbase-opensource-src and qtdeclarative-opensource-src, many but not all say "cc1: warning: command line option â-std=gnu++11â is valid for C++/ObjC++ but not for C". I'm not sure how to organize getting the Qt updates in, would you like to check the issues and say "please override" to archive admins?
<Mirv> bluez-qt is the only clear easy fix (one symbol change)
<Mirv> the qtbase change specifically doesn't do anything but a configure change affecting powerpc only, so it's essentially a no-change rebuild
<infinity> xnox: Hasn't happened yet, but no things don't need to be reuploaded.
<xnox> ok.
<xnox> infinity, any ETA, and/or may I seed the s390x packages pointlessly until that's done?
<xnox> cause nobody actually cares about the bulk of 9m marked packages =)
<infinity> xnox: Seeding things won't fix anything...
<xnox> i thought it would, as in launchpad would republish xenial-updates whenever that moves, and it would have the new support stanzas.
<xnox> the problem with s390-tools is that it's in main, without actually being seeded into anything.
<infinity> xnox: Oh, it would "fix" updates, yes, but not the release pocket.
<xnox> i / nobody cares about the release pocket either really =)
<infinity> xnox: But is IBM not satisfied with "yes, it's supported, we'll fix the metadata soon"?
<xnox> infinity, i'm pretty sure they do not care about release pocket metadata. they care for $ ubuntu-support-status to not show that s390-tools aka bootloader is supported only until January 2017
<xnox> and thus the metadata in the -updates
<infinity> xnox: Well, we care about both, since we're not going to SRU all of main.
<xnox> well yeah. let's pretend that release + -security is a valid thing, and yeah we'd need to fix release properly to show proper status.
<xnox> and imho s390-tools should be seeded somewhere anyhow.
<xnox> i guess it's a unicorn package that is in boot seed and nowhere else that is in use.
<xnox> it's not like seeding it into supported will change anything, in any of the metas.
<infinity> Sure, it should be in boot.
<infinity> Which is is.
<xnox> it is in bootÂ¸ but boot is not included into supported, hence no 5y badge
<infinity> Right, so that's what I'm fixing.
<infinity> Stop trying to "fix" it with seeds.
<infinity> I guess I can land fix 1 before fix 2 (ie: we can fix the updates pocket today and release later)
<xnox> yeah. "regenerate release pocket" is out of scope for the request.
<xnox> "regenerate release pocket" is part of separate request.
<xnox> surely that is a fix in seed structure then? e.g. supported-installer-common: standard installer -> supported-installer-common: standard installer boot
<xnox> oh, this would fix other bootloaders too.
<xnox> because at the moment grub-efi-amd64-signed is similarly on 9m badge.
<xnox> but that would be broken as well.
<xnox> cause some hwe kernels are not 5yr.
<xnox> i gave up.
<jbicha> oh, I guess evolution 3.22 was just a bit too late for beta 1 but I don't particularly need it in the beta so it'll be ok
<slangasek> tedg: surely indicator-session's autopkgtest is failing because it depends on url-dispatcher which has been removed on s390x, and we should remove indicator-session also?
<renatu> slangasek, now is failing again: https://requests.ci-train.ubuntu.com/#/ticket/1815
<renatu> slangasek, this is the excuses file: https://requests.ci-train.ubuntu.com/static/britney/ticket-1815/landing-049-yakkety/excuses.html
<slangasek> renatu: that shows that there are old s390x binaries in the silo which need to be removed
<slangasek> "from 0.2+16.10.20160822.1-0ubuntu1" tells you that it's not the version that's in the archive
<slangasek> so any trainguard should be able to do this fwiw
<renatu> slangasek, humm ok thanks
<slangasek> renatu: (but I've got this one)
<renatu> slangasek, thanks
<slangasek> $ remove-package -m NBS -s yakkety -A ~ci-train-ppa-service/ubuntu/landing-049 -a s390x -b qtdeclarative5-ubuntu-addressbook0.1 qtdeclarative5-ubuntu-contacts0.1
<slangasek> (done)
<Rosco2> Laney: Ubuntu Studio need ubuntustudio-meta unblocked to hopefully fix Live CD build
<slangasek> tedg: have convinced myself that yes, indicator-session binary should be removed from s390x; done
<tedg> slangasek: Great, thank you!
<stgraber> tsimonq2: nope, queuebot doesn't know anything about the products, it triggers on anything that's on the tracker
<tsimonq2> ok cool, thanks stgraber
#ubuntu-release 2016-08-24
<jbicha> please accept libreoffice/yakkety, it's needed for Ubuntu GNOME, bug 1592572 (it's more broken than just scrollbars)
<ubot5> bug 1592572 in Ubuntu GNOME "[gtk320] No horizontal or vertical scroll bars" [High,Triaged] https://launchpad.net/bugs/1592572
<slangasek> jbicha: done
<jbicha> thanks, now we just need the LO autopkgtests to workâ¦
<sakrecoer> hi.. our ISO failed again..
<sakrecoer> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/ubuntustudio The ubuntustudio-meta update that fixes this is stuck in yakkety-proposed. Could someone unblock it please?
<sakrecoer> Laney, jbicha anyone?
<Laney> sakrecoer: hi, I unblocked it for you, you can trigger a rebuild when rmadison shows you it has migrated
<sakrecoer> Laney: \o/
<sakrecoer> Laney: it is here right? http://iso.qa.ubuntu.com/qatracker/milestones/360/builds check the bockes and press the "Update rebuild status"..
<sakrecoer> s/bockes/boxes
<sakrecoer> oh no... wait.. my eager eyes missed the second line of your chat..
<Laney> at the bottom there is a table which has the title 'Rebuilds'
<Laney> do the thing there
<Laney> oh, well that's going to fail then :)
<sakrecoer> ok.. i canceled the request while waiting for rmadison's signal
<sakrecoer> ..sorry...
<sakrecoer> Laney: ok.. rmadison isn't a user :D i'm looking at man page, but still pretty lost..
<apw> sakrecoer, rmadison -a source ubuntustudio-meta
<LocutusOfBorg> thanks pitti for the removal :)
<LocutusOfBorg> I did some retry for pysam, lets see if I can make it migrate or we have to run against proposed again
<sakrecoer> thanks apw ! :)
<apw> sakrecoer, np, you'll see currently two lines for yakkety ... when the 0.160 moves up a line it is published
<sakrecoer> apw: awesome! thank you for anticipating my question! :)
<Laney> sakrecoer: Although, actually, I think you need to wait for "apt-cache show krita" to stop saying "Task: ubuntustudio-graphics" too
<Laney> Which should happen a little bit after the rmadison output changes
<sakrecoer> Laney: i can't do that from a xenial install right? i haven't been able to get my hands on a studio yakket iso that wouldn't fail at install yet...
<sakrecoer> ..well not since i removed the partition to test 14.04.5 that is...
<Laney> You can keep an eye on http://archive.ubuntu.com/ubuntu/dists/yakkety/universe/binary-amd64/Packages.xz, as one way to do it
<Laney> for example curl -s http://archive.ubuntu.com/ubuntu/dists/yakkety/universe/binary-amd64/Packages.xz | xzcat | grep-dctrl -X -FPackage -sPackage,Task krita
<Laney> grep-dctrl living in the dctrl-tools package
<Laney> (No need to do that more than once every 30 minutes or so)
<Laney> Back shortly.
<sakrecoer> thank you Laney ! :)
<LocutusOfBorg> how can a testsuite run against a package not in Ubuntu? WTH?
<LocutusOfBorg> autopkgtest for pbsuite/15.8.24+dfsg-1: amd64: Pass, armhf: Always failed, i386: Regression â» , ppc64el: Test in progress, s390x: Always failed
<LocutusOfBorg> mmm in proposed :(
<Laney> sakrecoer: You could try a rebuild now
<flocculant> sakrecoer: I triggered it for you
 * Laney crosses fingers and toes and tongue
<flocculant> :p
<sakrecoer> flocculant, Laney oh.. i triggered it at 01.05 pm CEST..
<sakrecoer> thank you guys anyways!!!
<sakrecoer> forgot to mention it here, sorry
<sakrecoer> flocculant, Laney: once the build is done, shoudl i mark them for testing?
<Laney> sakrecoer: It'll happen automatically
<sakrecoer> Laney: nice :) thanks!... last minutes now...
 * sakrecoer touches wood
<sakrecoer> i386 is build \o/ but amd64 status in launchpad is amibuous... https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/ubuntustudio
<sakrecoer> says "currently building" but "when complete" states: "28 minutes ago (estimated)"
<sakrecoer> ah well... i'm too anxious lol :D
<sakrecoer> now!!! "1 minute ago" \o/
<sakrecoer> thank you everyone! flocculant, Laney jbicha and everyone i've been nagging on for this! i'll save the rest of my joy-tears for the release party! :D
<flocculant> :)
<flocculant> sakrecoer: don't forget to test them now :p
<flocculant> jbicha: do you know if there's a ubuntu gnome dev channel?
<jbicha> flocculant: there's #ubuntu-gnome and there's gnome-devel on ubuntu.slack.com
<jbicha> Laney: please unblock ubiquity
<Laney> okay
<Laney> what about libreoffice?
<davmor2> Laney: well it's an open source office suite compatible to microsoft office is that enough info ;)
 * Laney covers davmor2 in syrup and releases the wasps
<jbicha> yes, please unblock LO too, I just installed it from -proposed and the -gtk3 version is much better
<Laney> ok
 * Sweet5hark doesnt know the topic but looks at davmor2 s statement with suspicion.
<davmor2> Laney: what I thought that was a fairly accurate description
<jbicha> (*better than the gtk3 version in regular yakkety at least)
<davmor2> Sweet5hark: Laney said What about libreoffice
<davmor2> Sweet5hark: so I answered
<davmor2> Sweet5hark: I thought it was a pretty good description myself
<Sweet5hark> Laney: Missing context from before I joined, I'd like to request libreoffice 5.2.0-0ubuntu2 to be on the images to save me from an angry mob on non-english speakers.
<Sweet5hark> Laney: also I owe you (and a lot of other people) beer. :/
<Laney> Sweet5hark: Yeah, I did it, thanks
<Sweet5hark> Laney: thank you.
<Laney> Maybe someone could tell the flavours they're getting a free respin
 * Laney is crying at gettext
<flocculant> jbicha: mmk - not that worried tbh, just did some smoketesting for them - no mouse at login screen (kvm) no idea if that's normal  *shrug*
 * flocculant laughs at Laney crying
<Laney> I want to just say "please just use this .mo file"
<xnox> Laney, Nein!
<Laney> python has a nice function for this :-)
<xnox> Laney, except:
<xnox>          pass
<xnox> ?
<Laney> https://docs.python.org/3.5/library/gettext.html#gettext.find
<xnox> nice =)
<Laney> if only I were using python
 * xnox goes back to encoding yaml, in text, in json
<Laney> they wrote their own .mo parser, so the implementation isn't liftable either
<Laney> ho hum
<ginggs_> Laney: there
<ginggs_> Laney: there is a libreoffice-dictionaries as well
<jbicha> Laney: and could you unblock gnome-maps too? the new version is has noticeably less lag
<Laney> ok
<jbicha> Laney: juliank in #ubuntu-devel thinks we should unblock apt as well
<Laney> fine
<Laney> can that be it please?
<xnox> Laney, oh, json is subset of yaml, so i can just encode json in json. Simples =)
<Laney> oh right, I need to generate the locales don't I
<Laney> there must be a better way than this
<zyga> arges: hello, I'd like to ask about the SRU of snap-confine, is there anything required to publish it left?
<arges> zyga: which version?
<zyga> arges: I see that 1.0.38-0ubuntu0.16.04.9 now needs to be verified
<ogra> whats up with the amd64 buildds ? seems half of them are disabled ?
<zyga> arges: there was an earlier version earlier today that had three issues, all verified, I guess that one went in
<ogra> (and my last PPA build wants to wait for 30min before starting)
<arges> zyga: yea i accepted 16.04.8, but 16.04.9 just got into proposed today
<zyga> arges: understood, so it has to sit there for two days and get verified
<arges> zyga: yup
<Laney> respin going
<Laney> apt is held up by autopkgtests
 * ogra taps foot
<ogra> (glaring at amd64 on https://launchpad.net/builders )
<ogra> grrr ... now the ETA for starting my build just jumped to 44min ...
<ogra> can someone please bump the score on https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/10659573
<ogra> ah, back to 9 min ... it seems ot be really unsure :P
<slangasek> ogra: bumped
<ogra> slangasek, thx (i hope it actually builds :) )  ... any idea why the majority of amd64 builders seems disabled ?
<slangasek> no, you'd have to ask lp team
<sakrecoer> "16:51 < Laney> Maybe someone could tell the flavours they're getting a free respin" want me to adress the list about it? anything specific to point at?
<sakrecoer> or rather: antyhing specific to communicate...
<sakrecoer> ah.. food just landed. i'll be back in an hour.
<cjwatson> ogra: I gather lgw01 has been a bit sad lately.  I've kicked off a mass-reset, will see how that goes
<cjwatson> Seems networking-related
<ogra> thx !!
<bdmurray> arges: Could you have a look at that whoopsie upload?
<arges> bdmurray: sutre
<arges> sure
<arges> bdmurray: did the yakkety fix go through already?
<arges> for 1616517
<arges> bug 1616517
<bdmurray> arges: not yet for bug 1616517, but its just adding strings
<ubot5> bug 1616517 in whoopsie (Ubuntu Trusty) "whoopsie does not send fields from some package management application crashes" [High,Triaged] https://launchpad.net/bugs/1616517
<bdmurray> https://bazaar.launchpad.net/~daisy-pluckers/whoopsie/trunk/revision/680
<bdmurray> arges: this should help sort out https://errors.ubuntu.com/problem/fc13839a8f16399991b1e1907d410c7f161d7fc9 which is the number 1 error at the moment
<arges> bdmurray: ok accepted for trusty
<bdmurray> arges: thanks
<tsimonq2> Laney: what was fixed in the recent rebuild?
 * slangasek hrms, wondering why liborcus, libixion, mdds got demoted
<wxl> hey release team. looks like d-i is having trouble with networking. i know server is not participating in beta 1, but this affects them, too. any chance we can get this fixed for beta 1? https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1616400
<ubot5> Launchpad bug 1616400 in debian-installer (Ubuntu) "Lubuntu's alternate i386 installer cannot connect to a network" [Undecided,Confirmed]
#ubuntu-release 2016-08-25
<infinity> wxl: d-i is broken in general currently, I'm working on fixing it right now.
<tsimonq2> thanks a lot infinity ;)
<pitti> apw, infinity: looking at http://people.canonical.com/~ubuntu-archive/nbs.html: don't we need a d-i rebuild for the new (well, not so new any more) kernel?
<pitti> and isn't that a blocker for d-i beta-1 images?
<pitti> Laney: ^
<tsimonq2> (including Lubuntu Alternate which we want to release...)
<mardy> pitti: hi! I've been told that I should contact a SRU member, about this: https://requests.ci-train.ubuntu.com/#/ticket/1669
<mardy> pitti: do you have some time, or can you point me at someone else?
<pitti> mardy: ah; I figure most SRU members tend to ignore these as they are really annoying to review (no LP generated diff, and the one in the PPA is wrong); I'll have a look later
<mardy> pitti: that might explain it :-) Thanks, and let me know if I can help in some way
<pitti> mardy: meh, is it really necessary to shuffle the packaging around so heavily in an SRU?
<pitti> mardy: do the new libaccount-plugin-* binaries ship entirely new functionality, or were these libraries in another binary before? I don't see any Replaces:/Breaks:, so want to make double-sure that this doesn't break upgrades
 * mardy checks
<mardy> pitti: they are new
<mardy> pitti: I think the packaging is more complex than what might seem logical, because there are some bits we also want to use in phone images, but not all (the new libaccount-plugin-* stuff is useful for unity7 only)
<pitti> mardy: the yakkety version is broken (just followed up to #1565772)
<pitti> why does yakkety get a 16.04+ version anyway..
<mardy> pitti: ok, I'll see if I can bump the version
<pitti> same for account-plugin
<pitti> the status in that bug report is *completely* wrecked
<pitti> marked as v-failed for now
<mardy> pitti: mmm... is there something else to be done, beside making sure that the yakkety version is proper?
<pitti> mardy: I don't know -- as I said, the status in that bug is a complete wreck
<pitti> e. g. look at https://bugs.launchpad.net/ubuntu/yakkety/+source/gnome-control-center-signon/+bug/1565772/comments/3
<ubot5> Launchpad bug 1565772 in gnome-control-center-signon (Ubuntu Yakkety) "[SRU] Allow plugins to decide which username to set on new accounts" [Critical,In progress]
<pitti> so this apparently was already uploaded to *xenial* in Ubuntu and fixed, but yet the x task was open and now there was that SRU
<pitti> and the y version is *older* than that comment
<pitti> so I have NFC what happened/landed where and where the bug actually got fixed :(
<LocutusOfBorg> lots of ppc64el are "test in progress", but the test is not in progress, can it be retried? otherwise I guess they won't complete
<LocutusOfBorg> e.g. strip-nondeterminism speech-dispatcher and so on
<pitti> LocutusOfBorg: cf. #u-devel some hours ago, ppc64el was broken; I fixed it, now it's catching up
<LocutusOfBorg> but I don't see them in the queue...
<pitti> wait until the next britney run, I figure they are done but excuses.html hasn't caught up yet
<LocutusOfBorg> ok thanks
<pitti> I did have to kill various dcraw and libreoffice test requests, I'll re-queue them once the current backlog settles
<mardy> pitti: weird indeed. But now, I can definitely see the persion problem for gnome-control-center-signon, so I can fix that hopefully
<pitti> mardy: I also have a feeling that this isn't just a version problem but that the fixes aren't actually in y yet
<mardy> pitti: but it's not clear to me what the issue with account plugins is; it looks like the version numbers are correct here: https://launchpad.net/ubuntu/+source/account-plugins
<mardy> pitti: ok, let me check the actual packages
<mardy> pitti: yakkety seems correct, all the packages are there, with the right files: http://packages.ubuntu.com/source/yakkety/account-plugins
<pitti> mardy: I mean https://launchpad.net/ubuntu/+source/gnome-control-center-signon
<pitti> mardy: this definitively doesn't have the changes from this xenial SRU
<pitti> as xenial and yakkety have the exact same version
<mardy> pitti: mmm... I see different versions, xenial is  0.1.8+16.04.20160201-0ubuntu1  and y is 0.1.9+16.04.20160405-0ubuntu1
<mardy> pitti: and the yakkety version seems correct, at least looking at the changelog
<pitti> ah, right; how did that bump the "real" upstraem version but not +16.04?
<pitti> so if the code is there, then only the version number needs bumping
<mardy> pitti: don't ask me, but could it be that it was a silo with dual landing (vivid overlay + xenial) which we hoped to land for the LTS proper, but then didn't land in time...?
<mardy> pitti: I see that the y package was apparently copied from xenial (so it says), but indeed that version is not in xenial
<mardy> quite messy
<cjwatson> it was probably built before yakkety existed
<mardy> cjwatson: right, indeed
<mardy> Mirv: so, I need to do a no change rebuild on gnome-control-center-signon for yakkety; what is the best way? should I make a dummy MP for and land it via the CI train?
<pitti> mardy: you can probabl commit the new changelog record/tag directly to trunk and skip the MP/train process
<pitti> or maybe you find a typo somewhere for an MP :)
<pitti> W: gnome-control-center-signon source: ancient-standards-version 3.9.3 (current is 3.9.8)
<pitti> mardy: ^ that might be a good thing to bump :)
<Mirv> mardy: you can do even just empty MP (trunk pushed to your own branch, then MP to trunk)
<mardy> pitti: suggestion taken, thanks!
<mardy> Mirv: I'll update the deb standards version as pitti suggested
<Mirv> mardy: sure
<Laney> tsimonq2: pitti: d-i> well, if someone fixes it then they can get a release, but if it's broken in general then I guess that's not going to be for Beta 1.
<infinity> Laney: d-i is fixed in proposed.
<infinity> Laney: It just needs to migrate and have ISOs rebuilt.
<infinity> pitti: ^
<infinity> pitti: It got out of sync because we forced that Qt transition.
<pitti> oh, so it's a question of resolving those two ftbfs
<infinity> pitti: What two FTBFS?
<infinity> pitti: excuses is waaaay behind reality.
<pitti> linker segfaults
<pitti> infinity: https://launchpad.net/ubuntu/+source/debian-installer/20101020ubuntu470 these two
<infinity> pitti: Wrong version.
<infinity> pitti: See above, re: excuses being behind reality.
<infinity> pitti: Like, 7 hours behind.  Might want to look at that.
<infinity> I should be in bed.
<infinity> And I'm going there.
<pitti> ergh, yes, will look
<infinity> Anyhow, if d-i migrates, lubuntu alternate can rebuild and be fine.
<infinity> And NBS will clear out.
<tsimonq2> bug 1611010
<ubot5> bug 1611010 in apt (Ubuntu) "yakkety desktop - non-english installation crashes with /plugininstall.py: ValueError: invalid literal for int() with base 10: ''" [Critical,Fix committed] https://launchpad.net/bugs/1611010
<tsimonq2> we have a fix for that in the images already?
<Laney> Yes
<Laney> Allegedly anyway
<infinity> A workaround in ubiquity.
<infinity> The real fix is in apt, which is still in proposed.
<Laney> That's fine for me.
<Laney> Why T F is britney not running though?
<tsimonq2> also, a regular Lubuntu tester reported bug 1616400
<ubot5> bug 1616400 in debian-installer (Ubuntu) "Lubuntu's alternate i386 installer cannot connect to a network" [Undecided,Confirmed] https://launchpad.net/bugs/1616400
<Laney> 3728     10725  0.6  2.8 981464 927556 ?       S    01:43   2:31  |                       \_ /usr/bin/python3 -u /home/ubuntu-archive/proposed-migration/code/b2/britney.py -c /home/ubuntu-archive/proposed-migration/code/b2/britney.conf.ubuntu.trusty -v --distribution=ubuntu --series=trusty
<infinity> tsimonq2: Yes, that's the same d-i bug that's been brought up several times.
<infinity> tsimonq2: And, as noted 20 lines up, will be fixed by d-i migrating.
<tsimonq2> sorry didn't see that
<Laney> Stabbed, hopefully will work on a re-run
<Laney> it runneth
<pitti> Laney: oh, thanks (was just about to look)
<Laney> pitti: well, looks like it hung retrieving autopkgtest results: http://people.canonical.com/~ubuntu-archive/proposed-migration/log/trusty/2016-08-25/01:42:59.log
<pitti> Laney: it seems precise's python3 already supports the timeout= parameter  for urlopen(), I'll robustify this
<Laney> pitti: great!
<pitti> done, https://git.launchpad.net/~ubuntu-release/+git/britney2-ubuntu/commit/?id=928be985868e
<pitti> testsuite succeeds on snakefruit
<Laney> nicÃ©
<Laney> d-i and apt went in
<yofel> did the kubuntu image builds crash or are they really still building?
<flexiondotorg> tsimonq2, sakrecoer How are things looks from your point of view?
<flexiondotorg> For Beta 1 that is :-)
<tsimonq2> it's coming along :)
<tsimonq2> Lubuntu Alternate needs some help
<tsimonq2> so does Kubuntu
<tsimonq2> but otherwise managing ;)
<flexiondotorg> Is it going to be a late night?
<sakrecoer> flexiondotorg: what tsimonq2 said, need to check with kubuntu to see how its going for them probably
<tsimonq2> well I'm in the US, so it'll most likely stretch to the afternoon :P
<tsimonq2> sakrecoer: they have no images right now
<tsimonq2> it's still rebuilding
<yofel> sakrecoer: our images say "re-building" for what feels like the whole day already?
<flexiondotorg> eeek!
<yofel> I got no build failure mail at least so far, so I'm clueless what's up
<sakrecoer> flexiondotorg: can't say... not enough experience i suppose. over at Ubuntu Studio, the only hardware test of amd64 has failed... trying now without encrypting home
<flexiondotorg> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/kubuntu
<sakrecoer> well.. didni't work without encrypted home...
<yofel> flexiondotorg: so they're not building *right now* ?
<flexiondotorg> The following packages have unmet dependencies:
<flexiondotorg>  kactivitymanagerd : Breaks: kactivities (< 5.20~) but 5.18.0-0ubuntu1 is to be installed
<flexiondotorg>  plasma-desktop : Breaks: kactivities (< 5.21) but 5.18.0-0ubuntu1 is to be installed
<flexiondotorg>  plasma-desktop-data : Breaks: kactivities (< 5.21) but 5.18.0-0ubuntu1 is to be installed
<flexiondotorg> E: Unable to correct problems, you have held broken packages.
<yofel> because http://iso.qa.ubuntu.com/qatracker/milestones/366/builds says so
<flexiondotorg> They failed.
<flexiondotorg> Because of the above umet deps.
<yofel> I know that, I want to know if there is a build in progress
<flexiondotorg> Not that I can see.
<yofel> ok, then just the ISO tracker is broken
<flexiondotorg> Laney, can you confirm there are no kubuntu images building right now?
<flexiondotorg> yofel, We you aware of the broken packages?
<flexiondotorg> s/We/Were/
<yofel> yes, we attempted to fix that yesterday/today by kicking okular off the images
<flexiondotorg> yofel, Sec... just checking something.
<flexiondotorg> OK, https://launchpad.net/ubuntu/+source/kubuntu-meta
<flexiondotorg> Published one hour ago.
<flexiondotorg> So I suggest you cancel the rebuilds in the iso tracker.
<flexiondotorg> And then request builds again.
<yofel> so I said to cancel the builds, and it still says (re-building)
<flexiondotorg> Laney, help please ^^^
<flexiondotorg> yofel, Also check the germinate output.
<flexiondotorg> http://people.canonical.com/~ubuntu-archive/germinate-output/kubuntu.yakkety/
<yofel> well, kubuntu-meta is generated from germinate, so I assume that'll be correct
<flexiondotorg> yofel, Well kactivitymanagerd still appear in the desktop seed.
<flexiondotorg> http://people.canonical.com/~ubuntu-archive/germinate-output/kubuntu.yakkety/desktop
<Laney> yofel: I cancelled it, go request your rebuild
<Laney> tsimonq2: You got new builds a couple of hours ago.
<yofel> flexiondotorg: that's the one that's supposed to appear, but I see the other problem, thanks for the hint
<yofel> so this will need another fixup
<yofel> Laney: thanks!
<tsimonq2> Laney: I'm aware, we have queuebot in #lubuntu-devel, thanks ;)
<flexiondotorg> yofel, yw :-)
<Laney> tsimonq2: Well, you said that it needs some help
<tsimonq2> I did? hm
<tsimonq2> d-i is fixed
<Laney> Okay then.
<Laney> Go get it marked as ready
<tsimonq2> Laney: I don't have access. I'm only sort of an assistant release manager. I do everything a release manager does EXCEPT mark the images as ready and other technical things related to that.
<tsimonq2> Laney: tl;dr I don't have access
<Laney> Do you have someone around to do that?
<tsimonq2> wxl does that, but if the images are tested, afair, he's ok with them being marked as ready
<tsimonq2> so usually I pop in here before he does and somebody from the release team just does it ;)
<tsimonq2> (I get on at like 8 AM my time when he's on at like noon)
<Laney> k
<Laney> So are they ready? :-)
<tsimonq2> desktop is 100% ready
<tsimonq2> we're just waiting on alternate
<tsimonq2> so unless you can mark half of 'em as ready (I don't know, again, I don't have access to that side of things), then no
<Laney> well would you look at that
<tsimonq2> hey that works \o/
<tsimonq2> thanks :)
<tsimonq2> Laney: this was just brought to my attention: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1616400/comments/8
<ubot5> Launchpad bug 1616400 in debian-installer (Ubuntu) "Lubuntu's alternate i386 installer cannot connect to a network" [Undecided,Fix released]
<tsimonq2> Laney: could you take a look?
<tsimonq2> Laney: (Nio's recent comment)
<Laney> tsimonq2: I suspect that's related to pitti's nplan work
<Laney> Probably going to have to release note it
<tsimonq2> Laney: no chance we could get it fixed?
<tsimonq2> I guess we'll have to deal if that answer is no but it would be nice
<pitti> Laney, tsimonq2: nplan does not meddle at all with d-i
<pitti> the only thing that wouldn't currently work with an alternate installer is that NeworkManager wouldn't connect to ethernet devices, but that's *after* installation
<Laney> pitti: you mean?
<pitti> and d-i would have set up /etc/network/interfaces for the ethernet anyway
<Laney> Yes, that's what the comment says
<Laney> if I read it correctly
<pitti> so the net effect should be by and large zero
<pitti> so if the installer itself says "could not connect to network" that's something else
<Nio> o/
<Laney> It's the installed system
<tsimonq2> Hi Nio
<tsimonq2> Nio wrote that comment, ask him ;)
<pitti> oh, that's not what the description says -- but I see comment #8 now, sorry
<Nio> I'm here listening
<pitti> Nio: hello
<pitti> Nio: did you actually configure the ethernet in d-i?
<pitti> Nio: if so, it should have written /etc/network/interfaces with it
<pitti> did it?
<Nio> I let the installer do the default tasks, which has produced a working ethernet connection both during the installation and in the installed Lubuntu system.
<Nio> Now (today's iso file) works during installation, but the installed system does not autoconnect via ethernet, but can connect via Wifi.
<pitti> Nio: right, and I'm asking what /etc/network/interfaces says (and interfaces.d/*) -- d-i is expected to create one for the interface you configured in d-i
<Nio> I'm not very good at networking details, but I can do the things described at https://help.ubuntu.com/community/Lubuntu/Documentation/MinimalInstall#Unmanaged_Wired_Network
<Nio> I noticed that 'managed=false' and changed it to 'true', but it did not help.
<Nio> Let me check that ...
<pitti> Nio: no need to -- just pastebin the contents of /etc/network/interfaces please
<tsimonq2> if it helps, when doing the testcase I just did, I thought it was weird that it claimed it was an unmanaged network interface
<Nio> source /etc/network/interfaces.d/*
<Nio> # The loopback network interface
<Nio> auto lo
<Nio> iface lo inet loopback
<pitti> nothing in /etc/network/interfaces.d/* ?
<Nio> No
<Nio> The directory exists, but is empty, not even any hidden files.
<pitti> Nio: ok, then please put the above file into the bug and reopen it
<pitti> and attach /var/log/installer/*
<pitti> netcfg apparently failed to write an /e/n/i
<pitti> tsimonq2: ^
<Nio> Which above file?
<pitti> /etc/network/interfaces
<Nio> ok
<tsimonq2> pitti: any chance we can get a fix for Beta 1? :)
<pitti> not sure, if you find someone to investigate and work on that, it isn't too hard, and there's still time to respin/retest images..
<pitti> but the chance of that isn't too great, I figure
<tsimonq2> pitti: what's it written in?
<pitti> installer logs are important, thoug
<pitti> tsimonq2: the d-i component/source package is "netcfg" I believe, and it's in C
<pitti> but looking at the logs first should hopefully be instructive
<Nio> how can I reopen the bug report
<Nio> ?
<tsimonq2> Nio: just mark as confirmed
<pitti> I just did
<tsimonq2> oh cool
<tsimonq2> pitti: C...not my strong suit
<infinity> netcfg was recently merged, but I see no obvious reason it would suddenly fail.
<pitti> http://launchpadlibrarian.net/278554355/netcfg_1.135ubuntu6_1.138ubuntu1.diff.gz looks harmless enough anyway
<infinity> Yeah.
<Nio> where is the button to click?
<infinity> If it were python, that indentation change would be scary, but it's not. :P
<infinity> (Also, <3 gcc-6's "misleading indentation" warning)
<Nio> I think I found it - marked confirmed :-)
 * infinity spins up a quick test.
<Nio> Have you got the files you need from the installed system now?
<pitti> Aug 25 14:32:55 netcfg[31980]: DEBUG: No interface given; clearing /etc/network/interfaces
<pitti> Nio: yes, thanks
<tsimonq2> ooh that doesn't look good
<pitti> but earlier on:
<pitti> Aug 25 14:16:36 netcfg[18267]: DEBUG: Writing DHCP stanza for enp3s0
<pitti> Aug 25 14:16:36 netcfg[18267]: DEBUG: Success!
<infinity> Weird.
<pitti> so it apparently is written multiple times, and on the second invocation it lost its state and cleaned the previously written one
<pitti> over 15 minutes later
<xnox> yeah netcfg is weird like that.
<infinity> Seeing if I can reproduce with a mini.iso
<xnox> we force clear things in ubuntu delta, which results in extra debug messages that wipes things before configuring things.
<xnox> i hope i did not screw it up too much.
<pitti> so either we fix whatever causes netcfg to be called twice, or we make it more robust to not trample over an existing /e/n/i?
<infinity> The more curious question is why this suddenly stopped working.
<infinity> Can I blame systemd interface renaming? :P
<infinity> I like to blame it.
<infinity> For everything.
<Nio> I tested with the mini.iso (the i386 version that was current yesterday. It worked - wired network both during installation and in the installed system. (I made a text-only mini system, which I think is overwritten now).
<xnox> infinity, when in doubt blame canada?! =)
<infinity> Nio: Well, that's even more curious.  I can think of no valid reason why a server install or a lubuntu install would differ.
<Nio> Maybe some change since the last mini.iso was uploaded.
<infinity> mini.iso == debian-installer == same thing on the lubuntu CD.
<infinity> The only difference is the packages that get installed.
<Nio> -rw-rw-r-- 1 nio nio 50331648 aug 10 21:03 mini.iso
<infinity> s/packages/extra packages/
<infinity> Oh.  That's an old one indeed.
<infinity> Very.
<infinity> I'm testing with yesterday's.
<Nio> $ md5sum mini.iso
<Nio> ccb12a3f21171bfa7c1fa0fbc34a59ed  mini.iso
<Nio> That was the mini.iso version available yesterday
<Nio> Obviously a new version arrived yesterday
<Nio> -rw-rw-r-- 1 nio nio 50331648 aug 25 11:15 mini.iso
<Nio> $ md5sum mini.iso
<Nio> 04468e5f9d1ba33aaba5f628c800d347  mini.iso
<Nio> infinity: Are you testing it now?
<infinity> Nio: Yes.  Install done, about to reboot.
<tsimonq2> wow that was fast infinity
<infinity> I have a fast laptop.  And very fast internet. :P
<pitti> installing into tmpfs with a proxy FTW :)
<tsimonq2> :D
<tsimonq2> and I thought apt-cacher-ng when using sbuild on /dev/shm was fast :P
<pitti> it is
<tsimonq2> well it is, you're right ;)
<yofel> could someone please push kactivities into yakkety release? That should fix the kubuntu images as that was the last recommend that I could find..
<Nio> Well, we are waiting for the result: Can mini.iso create an installed system with a working ethernet connection.
<infinity> FWIW, the current mini.iso works fine.
<infinity> I get a proper e/n/i with a dhcp entry for ens3
<pitti> infinity: what does the log say, is netcfg running twice?
<xnox> hm, is it buggy mini.iso or the ubiquity.iso -> note that we had patches in ubiquity's patched netcfg which was there to make things nice and use NM rather than ifupdown on "desktops"
<xnox> pitti, most recently twiddled with that.
<yofel> Laney: see above (you're supposedly on duty?)
<pitti> I cleaned up the obsolete /e/n/i and /etc/iftab migration, yes; but these were no-ops already, adn this is d-i
<infinity> pitti: Define "twice".
<infinity> pitti: It clears e/n/i, then writes it.
<infinity> pitti: But I don't see it writing it before that.
<pitti> infinity: as in the logs of that bug report
<infinity> pitti: bug3?
<infinity> pitti: bug#?
<pitti> bug 1616400
<ubot5> bug 1616400 in debian-installer (Ubuntu) "Lubuntu's alternate i386 installer cannot connect to a network" [Undecided,Confirmed] https://launchpad.net/bugs/1616400
<Laney> yofel: okay
<infinity> pitti: Oh, WEIRD.
<infinity> pitti: Kay.  I don't see that second run on finish-install.  /usr/lib/finish-install.d/55netcfg-copy-config is silent here.
<infinity> pitti: But that also hints at where to look.
<infinity> pitti: Bingo.
<infinity> pitti: copy-config checks if NM is installed and, if so, wipes the e/n/i config.
<pitti> oha
<infinity> pitti: So, to follow with your netplan ideals, that should ALSO change the netplan management options.
<infinity> pitti: Then we get what we want in both installers.
<infinity> pitti: Sound sane?
<pitti> infinity: but that would mean that the config in d-i gets ignored entirely
<infinity> pitti: Yes, but it seems that's what we've always done and no one's complained. :P
<pitti> infinity: yes, we could just change/amend that to create the policy snippet to let NM manage devices, but that still sounds conceptually weird
<infinity> pitti: So, I'm fine with maintaining the status quo.
<pitti> as long as it's just DHCP there's not much difference indeed
<infinity> pitti: It actually copies NM configs.  But not sure how that does anything useful since we don't use NM in d-i...
<pitti> right
<pitti> infinity: well, there is still a work item to port netcfg to emit netplan instead of /e/n/i, so that would help too
<pitti> although it was questionable whether we'd actually do that (subiquity et al)
<infinity> Or maybe it's more clever than I think.
<infinity> Looks like it might actually speak NM.
<infinity> pitti: So, I think just tweaking the CONFIG_NM case to also set your nplan configs the same way you do in a ubiquity nm-only world is the right answer.
<infinity> pitti: And, I assume, trivial.
<pitti> infinity: right, pretty well a copy&paste from http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/auto/build#L196
<infinity> pitti: Shiny.  Want my name on the changelog or yours?
<pitti> with substituting chroot with /target or so
<infinity> pitti: (as in, want to fix it, or shall I?)
<pitti> infinity: please go ahead, seems you already found the place to poke
 * infinity nods.
<infinity> Staring at it right now.
<pitti> thanks
<pitti> nice find
<infinity> pitti: http://paste.ubuntu.com/23089317/
<infinity> pitti: Looketh good?
<pitti> infinity: it's a real pleasure to the eyes!
<pitti> thanks muchly
<infinity> Tossed at the queue.
<pitti> infinity: in your mini.iso installed system do you actually have some /etc/NetworkManager/system-connnection/* thing from d-i?
<tsimonq2> so then a respin with this will fix the problems?
<pitti> first needs a d-i rebuild AFAIK
<infinity> pitti: No, cause it was a base install, with no NM.
<infinity> pitti: That block only triggers if NM is installed in /target/
<infinity> pitti: I could redo it with ubuntu-desktop.  Would take longer.
<pitti> should be fine; sorry, I wasn't aware that we wipe the generated /e/n/i in d-i
<infinity> In context, it all makes sense.
<infinity> It didn't when I first saw the chatter in the channel. :P
<Laney> Please handle the unblocks and stuff
<infinity> Yeah, it'll neet a d-i respin first.  For obvious reasons, netcfg is in the d-i initrd.
<infinity> Cause it's sort of needed to find the rest of the bits.
<Laney> Well, I can do netcfg, but will be out for a bit in 90 minutes or so
<infinity> I can unblock both, it's fine.
<Laney> Ta
<wxl> infinity: sounds like you're fixing d-i and we're getting a respin. still planning on releasing today?
<infinity> wxl: Depends, are you planning on testing when the respin happens? :)
<infinity> wxl: (I'm not the one releasing, you'd have to ask Laney, but he seemed on board)
<tsimonq2> yep we have testers good to go :)
<Laney> Do it in the next 2-3 hours
<Laney> I'm going out, and will be back to press some buttons
<Laney> but if you're not ready then, I don't fancy hanging around all night :)
<infinity> Laney: I'll respin for them as soon as it migrates.
<infinity> Laney: If they don't meet your deadline, that's on them.
<tsimonq2> ok by me, right wxl? ;)
<Laney> We could also release the remainder tomorrow
<Laney> (Or they could miss beta 1)
<Laney> I'm looking at kubuntu too
<tsimonq2> yofel: ^
<wxl> sorry i disappeared. i spent like 12,000 hours reading the ubuntu-release backlog. sheesh. you guys talk too much.
<wxl> anyways i guess the questions are:
<wxl>  1. infinity: do you have any guess as to when the migration would be complete?
<wxl>  2. Laney: how long to plan on staying around for?
<Laney> 0 minutes (bye!)
<wxl> Laney: so 2-3 hours or nothing is what you're saying
<Laney> I'll be back later
<wxl> oh well we'll talk about it then :)
<Laney> but not back to hang around, back to publish some images
<wxl> what version of d-i and/or netcfg are we talking about here?
<apw> wxl, netcfg is 1.138ubuntu2 i believe
<wxl> thx apw
<apw> wxl, and i believe d-i was 20101020ubuntu472
<wxl> apw: was or is? looks like 472 came an hour ago
<wxl> looks like nfg is in main but d-i is still in proposed
<infinity> Yeah, it's getting there.  Patience.
<infinity> I'll trigger the rebuilds as soon as it's published.
<wxl> you're the man, infinity
<apw> wxl, that hour is the source publishing, and typically the binaries miss that cycle and fall in the next
<boiko> hello, could you guys please let me know how long this beta1 freeze will last?
<boiko> we have landed a fix related to qt5.6 in telepathy-qt, but it is waiting in proposal
<infinity> boiko: A few more hours.
<boiko> infinity: ok, thanks :)
<infinity> Laney: When you run cron.source for milestones, run it with ALL_PROJECTS="participating projects"
<infinity> Laney: Rerunning for you.
<infinity> Laney: Or, maybe rerunning after the lubuntu ISOs are done, to not block.
<tsimonq2> infinity: any progress on those images? what's going on?
<flexiondotorg> tsimonq2, sakrecoer I've been afk for a bit.
<flexiondotorg> What's the situation?
<tsimonq2> flexiondotorg: we're waiting on Lubuntu and Kubuntu
<Nio> In the meantime I have tested Kubuntu Yakkety amd64. I'm sorry, but it seems to suffer from networking problems too, similar to what we see in Lubuntu alternate as well as what we saw in Lubuntu desktop, a ubiquity crash, when I try to install in Swedish.
<tsimonq2> flexiondotorg: the former of which is waiting on infinity to respin Alternate so we can test
<tsimonq2> flexiondotorg: the latter is being tested now
<tsimonq2> o/ Nio
<tsimonq2> yeah I got that too :/
<sakrecoer> flexiondotorg: no worries, still uncertain about kubuntu..
<Nio> Kubuntu: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1617037
<ubot5> Launchpad bug 1617037 in ubiquity (Ubuntu) "ubiquity crashes in kubuntu beta1 " [Undecided,New]
<sakrecoer> ah.. thank you tsimonq2 :) flexiondotorg: what tsimonq2 said :)
<sakrecoer> (i have infernal lag atm)
<flexiondotorg> Thanks for the update.
<flexiondotorg> Looks like this is going to be a late release?
<tsimonq2> very late
<tsimonq2> wouldn't be surprised if it went into tomorrow :/
<flexiondotorg> Bother
<sakrecoer> flexiondotorg: is there a way to find out the download links at this point? i edited the past ones, but they all give 404 so far.
<sakrecoer> past *release announcement ones
<tsimonq2> well they are going to be 404
<tsimonq2> because we haven't released yet
<tsimonq2> because we're waiting on Kubuntu testers and infinity ;) (or whatever he's waiting on)
<sakrecoer> ok :)
<sakrecoer> flexiondotorg: i have found a quote, but i'm not to sure about who the author is... maybe you guys know better?
<sakrecoer> A. Henry Savage Landor
<flexiondotorg> sakrecoer, For a quote of the author of the quote you have?
<sakrecoer> it goes like this: The Jogpa, in our mad flight, cut off a long lock of the yak 's silky hair. Having secured this, he appeared to be quite satisfied, let go, and sheathed his sword.
<sakrecoer> this guy: https://en.wikipedia.org/wiki/Arnold_Henry_Savage_Landor his invovlement in ww1 makes me doubt.. :/
<tsimonq2> flexiondotorg knows how hard finding Yak quotes is
<tsimonq2> :P
<tsimonq2> he found the ones for Alpha 1 AND 1!
<flexiondotorg> sakrecoer, Looks good :-)
<sakrecoer> ok then :)
<tsimonq2> s/AND 1/AND 2/
<tsimonq2> I want to add a little touch of my own towards the beginning
<flexiondotorg> I've just got in from work, so a bit knackered.
<flexiondotorg> Going to have some food and a rest.
<flexiondotorg> I'll pop back here in an hour or so.
<tsimonq2> ok o/ flexiondotorg
<tsimonq2> sakrecoer: let me know when you're done editing :)
<flexiondotorg> If anyone needs help with testing I can be coerced with promises of beer ;-)
<tsimonq2> flexiondotorg: once infinity spins up the ISOs, Lubuntu Alternate needs help pls ;)
<tsimonq2> flexiondotorg: I don't know if I'll be able to pay you in beer but I'll find something of similiar value ;)
<tsimonq2> *similar
<sakrecoer> tsimonq2: i think that is it. a proof reading is in place, since my notorious typos are infamous :p
<tsimonq2> ok :)
<slangasek> ginggs: reverse-depends tells me laby depends on fpc, does that also need removed? (not listed on LP: #1562480)
<ubot5> Launchpad bug 1562480 in glibc (Ubuntu) "fp-compiler not installable on powerpc since glibc 2.23" [High,New] https://launchpad.net/bugs/1562480
 * ginggs looks
<slangasek> it is possible that reverse-depends is lying to me :)
<ginggs> hmm, i've never heard of laby
<slangasek> Depends: [...] ocaml-nox | java-compiler | c-compiler | c++-compiler | ruby | gprolog | valac | fp-compiler | rhino | guile | python3 | lua
<slangasek> .... ok then
<slangasek> ignoring
<slangasek> sorry for the ping
<ginggs> np
<tsimonq2> sakrecoer, take a look at my edit on the announcement, too cheezy? :P https://wiki.ubuntu.com/YakketyYak/Beta1/ReleaseAnnouncement?action=diff&rev2=10&rev1=9
<tsimonq2> flexiondotorg: ^
<sakrecoer> tsimonq2: \o/ "bos grunniens" .. might bring forth the websearch-fu in many readers :D
<tsimonq2> yeah! :D
<sakrecoer> i think its a little bit cheezy but also quite funny! :D i'd stay neutral on that one if i may :)
<ginggs> slangasek: thanks!
<tsimonq2> flexiondotorg: you're the tiebreaker on this. In or out? :O
<tsimonq2> slangasek: hey, sorry for bothering you, the packages that Lubuntu needed for a respin on Beta 1 Alternate images are in the archive now, would you be able to trigger a rebuild of Lubuntu Alternate please?
<tsimonq2> Adam doesn't seem to be around and we'd like to get those tested
<flocculant> tsimonq2: triggered for you
<tsimonq2> thank you flocculant
<flocculant> welcome
<slangasek> tsimonq2: right, generally meant to be self-serve by the flavor teams :)
<Laney> infinity: What does it do otherwise?
<Laney> What evs
<Laney> I see nobody new is ready
<Laney> Publishing the rest anyway
<tsimonq2> *SIGH* I'd really like to get Lubuntu tested...
<Laney> It can be done later on
<Laney> Either wait to send the announcement, or write "foo and bar will come along shortly, they are just tying their shoelaces"
<wxl> Laney: any chance you can wait for us to test alternate real quick? we've got a team of people ready to go, myself included.
<wxl> Laney: i can't imagine it would take very long.
<Laney> It doesn't matter if I push up the rest in the meantime
<wxl> Laney: especially considering one of them just popped up.
<Laney> Someone else is sending the announcement and you can get them to hold off before doing it
<wxl> someone else beingâ
<tsimonq2> I'm doing the announcement with sakrecoer
<tsimonq2> so we can hold off
<wxl> i mean there's a "someone" online
<Laney> there you go
<wxl> ah ok great
<Laney> the question is if you get it marked ready before I go offline :-)
<wxl> well we just got our builds, so
<Laney> go go go
<sakrecoer> i'm here... but i wont be for more than 2 hours... early morning tomorrow
<wxl> 2 hours is WAY more than enough time
<tsimonq2> sakrecoer: we are working as hard as we can
<sakrecoer> \o/
<tsimonq2> yeah what he said ;)
<wxl> we're all downloading as we speak :)
<sakrecoer> alright! i'm not on the minute eather, so don't extra sweat it if it comes down to timing me ;)
<sakrecoer> s/eather/either
<Laney> infinity: orite, I saw it failed to build
<Laney> I guess this -next thing didn't exist before
<flexiondotorg> tsimonq2, Tiebreaker?
<tsimonq2> flexiondotorg: eh nvm
<flexiondotorg> tsimonq2, Is there anything that needs smoke testing?
<tsimonq2> flexiondotorg: yes pls wxl pays beer
<tsimonq2> flexiondotorg: http://iso.qa.ubuntu.com/qatracker/milestones/366/builds/129632/testcases
<tsimonq2> wxl: sorry, we all have to make sacrifices, you cover flexiondotorg's beer :P
 * flexiondotorg smells beer...
<flexiondotorg> Downloading Lubuntu i386 alternate.
 * wxl passes flexiondotorg a Duff.
<tsimonq2> \o/
<wxl> my download is taking forever and it's really making me mad.
<flexiondotorg> I'd just like to remind everyone I'm still on shortwave radio "broadband", so...
<flocculant> wxl: I'll do a 32bit - almost got iso now
<flocculant> marked as running on tracker
<wxl> cool thx flocculant. pop into #lubuntu-devel for coordination
<flocculant> wxl: what are we looking to make sure is fixed here?
<wxl> flocculant: https://launchpad.net/bugs/1616400
<ubot5> Launchpad bug 1616400 in netcfg (Ubuntu) "Lubuntu's alternate i386 installer cannot connect to a network" [High,Fix released]
<flocculant> wxl: ok so trying to configure keyboard is failing ... my keyboard layout appears to be lt ...
<tsimonq2> flocculant: got a bug that we can link on the release notes?
<flocculant> nvm - got it now
<flocculant> wording is a bit bizarre there - but not worrying right now
<slangasek> ginggs: and there seem to be some other packages needing removal, for reals, not mentioned on the fpc bug... ztex-bmp, winff, view3dscene... ?
<slangasek> not view3dscene, that one's not built on powerpc
<wxl> sakrecoer: Laney: almost there. one last in progress test to finish and then we'll have the mandatory ones done.
<sakrecoer> wxl: great!
<Nio> good night
<wxl> k sakrecoer Laney marked as ready
<sakrecoer> wxl: alright! lets send that mail then! :)
<wxl> sakrecoer: do it! and don't forget to wish linux a happy 25th
<tsimonq2> wait
<tsimonq2> sakrecoer: wait
<sakrecoer> sure!
<tsimonq2> Laney: are we ready?
<Laney> 2 minutes
<tsimonq2> ok
<sakrecoer> ok :) was about to mention that mate,gnome and studio download link still give 404
<Laney> I synced the mirrors
<Laney> everything should be there in 30 minutes or so
<tsimonq2> ok
<sakrecoer> alright :)
 * flexiondotorg is now connect via 3G using my MX4 hotspot.
<flexiondotorg> Because having the radio broadband fail right now, is, is....
<Laney> So yeh, check some of the torrents work and send the mail whenever you want
<Laney> I'm going to unfreeze the archive now
<Laney> thanks all
<flexiondotorg> Thanks Laney
<Laney> if kubuntu get ready then we can push out a beta 1 image for them tomorrow
<Laney> otherwise, I don't think it's a big deal for them to miss this one personally
 * Laney will leave their images uncronned for now
<Laney> other dailies are back on
<Laney> nighty night
<tsimonq2> o/ Laney
<tsimonq2> Laney: thanks a lot for your help :)
<sakrecoer> thanks everyone! :)
<aldomann_> hey, just got the mail from the mailing list about the release
<aldomann_> I was about to make the official anouncement of Ubuntu GNOME 16.10 beta 1, but the link seems to be an empty folder
<aldomann_> http://cdimage.ubuntu.com/ubuntu-gnome/releases/yakkety/beta-1/
<sakrecoer> aldomann_: hit reload ;)
<aldomann_> not seeing the images on http://cdimage.ubuntu.com/ubuntu-gnome/releases/16.10/beta-1/ either
<sakrecoer> aldomann_: odd, i do ..
<sakrecoer> i have to go sleep now thogh! see you soon everyone! thanks for your help and patience!
<flexiondotorg> aldomann_, Ubuntu GNOME has synced now :-)
<aldomann_> nevermind, seeing them now
<flexiondotorg> aldomann_, OK, something odd going on.
<flexiondotorg> Ubuntu GNOME was fully populated a minute ago.
<flexiondotorg> Now just hashes.
<flexiondotorg> And populated again.
<tsimonq2> published! \o/ http://fridge.ubuntu.com/2016/08/25/yakkety-yak-beta-1-released/
<flexiondotorg> tsimonq2, Thanks for organising :-)
<tsimonq2> flexiondotorg: thank sakrecoer, he did most if not all the work :)
<bdmurray> slangasek: ^^ updated apport hook
#ubuntu-release 2016-08-26
<infinity> tsimonq2: Ugh.  Sorry about that.  I made the mistake of contacting a pillow, and passed out.  I'd been up all night. :/
<ginggs> slangasek: sorry, you are right; ztex-bmp and winff got their powerpc binaries copied from xenial. I'll go through 'reverse-depends -b src:fpc' and add the missing packages to the bug
<pitti> infinity, Laney: do you consider the iptables package split in Debian (https://tracker.debian.org/news/788344) a new feature?
 * pitti wonders if it makes sense to merge iptables for bug 1616437 now, or work around it
<ubot5> bug 1616437 in iptables (Ubuntu) "FFE: split out libiptc library" [Undecided,New] https://launchpad.net/bugs/1616437
<Laney> pitti: If you review the iptables changes and they are correct, it's fine by me
<pitti> yes, of course I'll review/test them (not expecting the release team to judge about correct patches, just the scope of changes)
<pitti> thanks!
<infinity> pitti: It's a feature, but not a contentious one, IMO.
<ogra_> infinity, any chance that we get some of the 2/3 disabled amd64 builders back at some point ?
<ogra_> (and could someone bump the score on https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/10668598 and https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/10668601 )
<infinity> ogra_: There's some violence being done to scalingstack.  They'll come back eventually. /
<ogra_> ok
<infinity> ogra_: And bumped a bit.
<ogra_> (thats ongoing for over a week ... would be nice :) )
<ogra_> thanks
<ogra_> we should just build all arch: all packages on ppc64el or s390x ;)
<ogra_> that would drop the load a bit
<infinity> Heh.
<infinity> Create a PPA with only s390x enabled and, presto, your arch:all builds will be on s390x.
<ogra_> heh
<cjwatson> ogra_: Active maintenance has only been ongoing for a day or so, but indeed it was bad before that.  The problem is that a MySQL instance in the innards of scalingstack has accumulated a vast number of rows relating to old instances and needs to be cleared out.  Unfortunately the process of clearing those out appears to be very slow.
<ogra_> they should just use postgres ... then we could blame pitti :)
<pitti> I just asked axino, indeed this seems strange -- "nova delete" doesn't actually remove the db entry, just marks it as "deleted"
 * pitti introduces SQL users to "DELETE FROM" -- et voilÃ , no accumulation of cruft over time!
<cjwatson> pitti: Yes, it's an Openstack issue.
<cjwatson> Though multi-stage deletes are not uncommon in large systems for one reason or another.
<cjwatson> I don't know what nova's rationale is.
<ogra_> can i get bumps for https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core/+build/3655 and https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core/+build/3658 too ?
<cjwatson> ogra_: done
<ogra_> thanks :)
<ogra_> that was the last one for today i hope :)
<sakrecoer> flexiondotorg: tsimonq2 was very helpfull and nice to work with, it wouldn't have been as fun and easy without him :)
<flexiondotorg> sakrecoer, Morning. And Thanks!
<flexiondotorg> For organising us :-)
<sakrecoer> :) it was a pleasure! a good way to get to reach out to the community and get to know more people in fact :)
<sakrecoer> wish you all a nice friday! read you soon!
<bzoltan> cjwatson:  would you please help me with the UITK release from this silo -> https://requests.ci-train.ubuntu.com/#/ticket/1808 it needs a binNEW ack as we have added a new metrics library to enable UI performance monitoring.
<bzoltan> the change is from Loic - https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-094/+sourcepub/6828771/+listing-archive-extra
<cjwatson> bzoltan: sorry, I'm not routinely doing this any more, hopefully some other archive admin can help.
<bzoltan> cjwatson: okey, thanks. No prob... i will find somebody else then
<bzoltan> seb128: maybe you :) ^^^
<ginggs> slangasek: (for when you are back online) it looks like you already removed powerpc binaries for ztex-bmp, winff. Or did I miss something? Is there anything further I should do for fpc powerpc removal?
<bzoltan> pitti:  would you please help me with the UITK release from this silo -> https://requests.ci-train.ubuntu.com/#/ticket/1808 it needs a binNEW ack as we have added a new metrics library to enable UI performance monitoring.
<bzoltan> pitti: the change is from Loic - https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-094/+sourcepub/6828771/+listing-archive-extra
<bzoltan> or slangasek ^
<bzoltan>  it's the final freeze day and I would like to get it in to the OTA
<pitti> bzoltan: train n00b here, what am I supposed to do ?
<bzoltan> pitti: It is a new binary package to the yakkety archive
<pitti> train copies circumvent binary NEW AFAIK
<bzoltan> mayb Mirv knows how to do and what :)
<pitti> bzoltan: FTR, NEW queue is here: https://launchpad.net/ubuntu/yakkety/+queue?queue_state=0 (not in there, and I doubt it will actually appear there)
<Laney> pitti: He's asking you to review it before copying to the archive, because of that bug
<infinity> pitti: Indeed, copies circumventing binNEW is why we require them to get signoff before publishing.
<pitti> yeah, I'm determining the new binaries amongst the gazillion  existing ones and review
 * infinity ponders scouring the earth for caffeine.
<pitti> debian-changelog-line-too-long line 7 (but *shrug)
<pitti> bzoltan: any chance to drop the .la files? some years ago we've went through quite some effort to clean them up
<pitti> they are useless and just cause trouble (extra dependencies, or lintian warnings like this: incorrect-libdir-in-la-file usr/lib/x86_64-linux-gnu/libUbuntuMetrics.la =/usr/lib/x86_64-linux-gnu != /usr/lib/x86_64-linux-gnu
<pitti> (whatever that means)
<pitti> (presumably that extra =)
<pitti> not sure how much precedent there is with other libraries
<pitti> bzoltan: libubuntumetrics5 contains a non-soname specific file: ./usr/lib/x86_64-linux-gnu/qt5/plugins/ubuntu/metrics/libumlttng.so
<pitti> that's a major bug for a library as that will break upgrades on the next soname change
<infinity> Yeah, plugins should never be in an SONAMEd package.
<pitti> that's it mostly; the latter is a rejection reason, the .la file is "meh, pretty please kill them with fire", but could be argued to pass if there's a targetted/assigned bug
<pitti> but while you are fixing the packaging anyway please remove that too
<pitti> https://requests.ci-train.ubuntu.com/#/ticket/1808 doesn't have anythign to record the review?
<pitti> oh, a comment field
<bzoltan> pitti: Would that be OK if I fix it with the next release (next week)? Today is feature freeze for the OTA.
<infinity> bzoltan: It's a rejection.
<pitti> comment added to the ticket
<bzoltan> pitti: ^^ ?
<pitti> bzoltan: it'll be harder to fix then, you need the conflicts:/replaces dance
<bzoltan> pitti:  I am happy to do that dance
<pitti> also, then it wouldn't be subject to NEW review again
<bzoltan> pitti: I promise I will put you as reviewer of the next landing.
<infinity> That's not how this workd.
<pitti> well, why the Friday afternoon rush? it seems so much better to land it properly next week than causing more work for everyone
<infinity> works*
<bzoltan> pitti:  it is a triple landing vivid/xenial/yakkety ... to me the vivid is the priority as it goes to the devices out there
<pitti> FFEs exist for a reason..
<pitti> landing it in a stable release is even worse
<bzoltan> pitti:  it is not a Friday afternoon rush :( that branch is 10 days old. That how long it takes to spin off a UI Toolkit release. Autopilot tests what takes 2 days, autopkgtests that fail randomly, manual QA tests... it is a long process.
<pitti> a feature freeze does not mean "cram in everything half-broken at the last minute", it's a much softer target where exceptions are readily granted immediately afterwards (increasingly less often the longer it goes)
<infinity> bzoltan: You're asked to get reviews for a reason.  The reason isn't to ignore them.
<pitti> hm; seems the binary review should happen  at a much earlier time?
<infinity> bzoltan: You could have had it reviewed before it was ready to copy, for what it's worth.
<infinity> bzoltan: Either way.  Being in a rush doesn't make the review result change.
<infinity> bzoltan: If it does, the process is broken.
<bzoltan> pitti: I agree, but for some reason the provess is like this
<pitti> well, *shrug*, it's a time bomb like that, and I know how things go -- once it's over the fence it tends to be forgotten, and it's *more* work overall to do it twice
<bzoltan> infinity: I appreciate your input. Thank you.
<pitti> all that autopkgtest/QA dance etc. will still have to be done again
<bzoltan> pitti:  No, I do not forget it.
<pitti> bzoltan: well, explain to me how landing that now makes anythign easier?
<bzoltan> pitti:  I do that dance every week :) that is not new. But missing the OTA would be really bad.
<pitti> well, I don't know these circumstances of the release process; you asked me to review it, I pointed out the packaging bug, do with it what you will :)
<infinity> bzoltan: If the bug is OTA-critical (and determined to be such), surely there's a way to escalate and push through a fixed version quickly.
<bzoltan> pitti: Look the description - https://requests.ci-train.ubuntu.com/#/ticket/1808 I have some critical fixes there.
<infinity> bzoltan: If you're implying that both "it needs to land" and "it'll take a week" are true statements, something is wrong.
<pitti> sorry, I need to leave, appointment
<bzoltan> infinity:  yes, the process is difficult and heavy. Not my design, not my process. It is how it is.
<Laney> Something's very wrong if the review isn't allowed to actually bounce the fix back
<bzoltan> Laney:  The problem is that fixing that  "libubuntumetrics5 contains a non-soname specific file: ./usr/lib/x86_64-linux-gnu/qt5/plugins/ubuntu/metrics/libumlttng.so" would put 4-5 days delay on landin. What is OK in the beginning of the OTA period, but at the end IMO it would make sense to be flexible and acept my commitment that it will be fixed next week. Not like I am asking an atomic bomb to pass
<infinity> bzoltan: It shouldn't put a 5 day delay on landing.  That's insane.
<infinity> bzoltan: And reviews aren't in place to argue that reviewers should let it in anyway.  There's no point in the AA review step if it's just going to be ignored.
<bzoltan> infinity: I know, as I said it is not my process, not my rules. I am just working here.
<infinity> bzoltan: So escalate to the right people to make sure that 5 day process can be turned around in a 6 hours instead for your fixed package.
<infinity> bzoltan: There's no reason it has to take that long.
 * infinity feels like he's back at Nokia.
<bzoltan> infinity: I know how it goes... I grew up in easter europe in the 80s :)
 * bzoltan feels like he is back in soviet Hungary
<bzoltan> infinity: Nokia was actually pretty non-flexible organization
<infinity> bzoltan: Yes, hence my comment.
<infinity> Landing in Maemo was an awful experience.
<bzoltan> infinity: same here.. i am not arguing, I am asking flexibility and trust
<infinity> bzoltan: You're arguing with the wrong people.  The problem is in how quickly you can turn around a fix, not with someone rejecting your upload.
<bzoltan> infinity: That one I do know :)
<infinity> It.  Does.  Not.  Take.  5.  Days.  To.  Get.  A.  Package.  Through.  A.  Silo.
<bzoltan> infinity:  read my lips > _IT_DOES_
<infinity> sil2100: ^^  What can be done to give bzoltan an SLA on one fixed landing?
<bzoltan> infinity:  how often do you land a package via CI train?
<sil2100> What's up?
<infinity> bzoltan: Never.  But I've seen quick fixes done by others.
<bzoltan> infinity: I do all the time .. 30-40 a year, so please believe me if I say it takes 4-5 days
<infinity> sil2100: bzoltan's landing has a bug that prompted an AA reject.  He's arguing for it to be let in anyway because citrain is slow and it'll take him a week to land a fix, I'm arguing that he's arguing with the wrong people, cause it shouldn't take more than a day to turn it around, and the rejection was for a valid reason.
<bzoltan> infinity:  I am not arguing... I am asking
<infinity> bzoltan: Asking repeatedly after you've been given a response is called arguing.
<sil2100> Yeah, landing through the train can be fast of slow, like with any package landing to the archive - bigger projects tend to take longer since well, tests, etc. but that's not due to the train ;p
<sil2100> Ouch
<bzoltan> sil2100: specially that it would not be an issue if it were a vivid only landing ...
<sil2100> bzoltan: just for context, which landing request is this about?
<bzoltan> Anyhow the comment from pitti is valid and yes that issue must be address.
<bzoltan> sil2100: https://requests.ci-train.ubuntu.com/#/ticket/1808
<sil2100> bzoltan: I suppose this landing is needed for OTA-13, yes?
<sil2100> bzoltan: so generally if the archive admins reject an upload we need to just respect that and do a rebuild anyway, just want to know if we can somehow still get this fit into our vivid base
<bzoltan> sil2100: yes, it is the main OTA13 UITK
<sil2100> bzoltan: is that libumlttng.so library used already? Is this a completely new thing?
<bzoltan> sil2100: a rebuild and the autopkgtests will eat up the weekend for sure
<bzoltan> sil2100:  it is brand new and no, nothing yet uses it
<sil2100> What I'm worried is, if we anyway got that even just for the vivid-overlay and it got out with OTA-13, I'm worried that some stable users/developers could start using this app and have troubles on ABI changes there
<sil2100> bzoltan: do you guys have a branch for fixing the library so-versioning?
<Mirv> sorry I'm not having brain capacity at the moment since I'm doing other stuff but how does that plugin there differ from eg libqt5gui5 which has a bunch of differently named plugin .so:s bundled?
<Mirv> just point out the visible similarity, I've not even opened the binary package contents of this landing
<sil2100> It was probably missed during archive-admin review? ;p
<bzoltan> infinity:  purely out of curiosity, may I know in how many milliseconds the universe would collapse if a package called libubuntumetrics5 would land in Ubuntu archive what provides a library called libumlttng.so? I really do not challenge yur call... but I wish to learn the reason of your decision. What I respect and accept.
<Mirv> sil2100: that's what's in Debian and has always been, it has at least gone through Debian's NEW queue in the past
<Mirv> but sorry I'm not really here but on free time
<infinity> bzoltan: Sarcasm doesn't change the review either.
<infinity> bzoltan: The point is that packages with an SOVER in the name are so designed to be coinstallable with the next SOVER.
<infinity> Mirv: qt5 upstream stuff is a bit diffeerent, since the SOVER stays lockstep with the Qt major version, and the plugins are in foo/qt5/bar
<infinity> Mirv: In the case of a libsomethingubuntu, I refuse to believe we have the same ABI guarantee (and if other Canonical libraries are any indication, I'm right), so libqt5ubuntuthing5 could be ubuntuthing6 tomorrow, and this all explodes.
<bzoltan> infinity:  I could ask in a corporate lingotyle too that what risks it would represent in a short and long term.
<infinity> bzoltan: The library name itself isn't necessarily an issue, it's the entire path being non-unique between SOVERs of the package.
<infinity> bzoltan: Tacking a "5" on the end of the plugin dir would fix it, for instance.
<bzoltan> infinity:  Sorry, I make jokes... it is Friday evening here, my wife makes apple pie, kids ask me to play and here I am trying to understand packaging policcies
<infinity> bzoltan: Dude.  You've been arguing for more than half an hour when you could have had it fixed and uploaded by now.
<infinity> And it's not just your time you're wasting.
<infinity> And with that, I'm exiting the conversation.
<bzoltan> infinity: Ohh.. version specific path in Qt libs... duuuude :) I am dreaming about that for about 10 years. Not kidding, that is a big issue.
<infinity> This has nothing to do with Qt...
<bzoltan> infinity:  it does
<infinity> ...
<infinity> It doesn't.
<bzoltan> infinity: it is in fact and practice a Qt lib, it will be upstreamed one day to Qt
<bzoltan> infinity:  it is a UITK lib and UITK is a Qt/QML toolkit. Very much Qt. 100% Qt.
<infinity> Upstreamed as "libUbuntuMetrics"?  Seems unlikely.
<infinity> But the version specific path I'm talking about is for the plugin, not the library.
<infinity> usr/lib/x86_64-linux-gnu/qt5/plugins/ubuntu/metrics/libumlttng.so
<infinity> usr/lib/x86_64-linux-gnu/qt5/plugins/ubuntu/metrics5/libumlttng.so
<bzoltan> infinity: to you, maybe... to me. Hmm.. i just talked with Qt folks and yes they are willing to be flexible.
<infinity> See, now the path matches the library SOVER.
<infinity> When you bump to libUbuntuMetrics.so.6, you change that to metrics6, and look at that, unique path.
<infinity> Welcome to how to avoid half an hour of wasted time.
<bzoltan> infinity:  it is 5 like Qt5 and it is in the path usr/lib/x86_64-linux-gnu/qt5
<infinity> bzoltan: So, you're guaranteeing that libUbuntuMetrics.so.5 will never break ABI until Qt6?
<infinity> If not, then you don't understand how to version libraries.
<infinity> And we have a bigger problem. :P
<bzoltan> infinity:  that is the most important pledge a Qt lib must take, yes.. in a major version no ABI breaks
<infinity> How do you guarantee that?  Upstream ABI tracking?  Rejection of MPs that would break ABI?
<bzoltan> infinity: and yes, I do wish that Qt would be packaged in Debian and Ubuntu to use the minor versions in the installation path... so minor releases were co-installable
<infinity> Err, eww.  No.
<infinity> That's madness.
<infinity> And not at all what I was talking about.
<bzoltan> infinity: there is no ABI tracking, sadly... there should be, or it would really cool. We have tests to secure stability.
<infinity> "stability" of.. The ABI?
<apw> is not the point of library minor releases is that they are ABI compatible so that they can replace each other without a build of all the rdeps ?
<infinity> apw: Yes.
<bzoltan> infinity: I am talking about different thing. That is not the point.
<infinity> bzoltan: So.  The bottom line here.  If libUbuntuMetrics-built-against-Qt5 will always have the same ABI, ALWAYS, then there's no bug here.
<infinity> bzoltan: No removed symbols, no changed signatures.
<infinity> bzoltan: If that's definitely true, then you'll never bump the SOVER on it, then the path is fine.
<xnox> bzoltan, even with per minor qt version directories, the thing that infinity is asking still applies. that metrics yesterday compiled against qt5.4 or qt5.5 should use metricsN/libumlttng.so as the last path; and metrics today which has abi break should use metrics(N+1)/libulttng.so to match the abi break in the soname it depends on.
<xnox> or qml functions removed
<xnox> or qml functions changing args/usage
<slangasek> ginggs: yeah, I believe I've removed all the stragglers now, was just wondering if there was some reason those hadn't been on the list - thanks!
<sil2100> bzoltan: ok, so I have a proposition
<bzoltan> xnox:  there is a 5 in the path
<xnox> bzoltan, we are talking about qt5/plugins
<bzoltan> infinity:  Yes, that is the case. Just like with all other Qt packages. Under a major release no ABI breaks are accepted.
<xnox> we are talking about qt5/plugins/ubuntu/metrics1, qt5/plugins/ubuntu/metrics2, qt5/plugins/ubuntu/metrics3, qt5/plugins/ubuntu/metrics4 -> 3 abi breaks, fro three upstream releases of metrics
<bzoltan> xnox:  yes, that is a 5 there :) Is there any other Qt library with a minor version in the path?
<xnox> bzoltan, those that do not break the ABI don't need. clearly metrics have broken the abi and resulted in not being coinstallable any more =)
<bzoltan> xnox:  there is no library with a subversioned path under /usr/lib/*/qt5/plugins
<xnox> bzoltan, is qml plugin abi not broken with abi breaks in the underlaying .so library that it binds?
<xnox> my understanding is that, it is.
<xnox> and so is infinity's.
<bzoltan> xnox:  what metrics? It is a new package called libubuntumetrics5
<bzoltan> xnox: I am not sure I understand you. Or I miss something. It is a lib  under qt5  it does come with an ABI stability pledge. Like all other Qt5 libs.
<xnox> ... but it's not qt upstream?
<xnox> thus it will eventually go out of sync in abi
<xnox> specifically when we triple land it.
<xnox> thus it needs it's own abi, irrespective of qt's abi it is compiled against. to allow room for changing it's abi too, no?
<xnox> bzoltan, is qt-ubuntu-components have "same abi stability pledge" and that was not broken yet? as in no apps had to change?
<bzoltan> xnox:  it will be qt upstream on day and it is super heavily binded to Qt
<bzoltan> xnox:  the UITK does not have its own minor version path either...
<xnox> and what do you do, when uitk components break/change in incompatible ways? Rename them and keep old version?
<xnox> or just bump framework, and break the apps?
<bzoltan> xnox: we do not break apps,if we do that is a bug to be fixed with super high priority
<bzoltan> xnox:  Qt libraries and so UITK libraries are not like other C++ libraries. As I said... not a single Qt library or plugin is installed to minor versioned path. Not one.
<bzoltan> xnox: pitti: infinity: and yes, all library installed under qt5 path does come with a super serious ABI compatibility pledge. That is one of the fundaments of Qt.
<infinity> bzoltan: That's true of upstream Qt.  But what are *you* doing to keep that pledge for this Ubuntu library?
<infinity> bzoltan: If you'll be tracking ABI breaks and rejecting changes that alter it, then like I said, there's no bug here.
<infinity> bzoltan: If you're just assuming that because it's a Qt library it'll magically follow upstream's rules, I don't buy it.
<bzoltan> infinity: I am not assuming anything. I state, under a major version we do not break ABI.
<bzoltan> infinity: we have loads of tests with dozens of applications to cover that.
<infinity> bzoltan: Application tests aren't ABI trackers, unless those applications call into every symbol you expose.
<bzoltan> infinity: with this new package we do not do anything different what we have been doing since the first 0.1 UITK
<bzoltan> infinity: I am totally in to discuss this issue with all of you guys, because you are clearly the best to give advice on this field. But rejecting this landing because of a pratice we have been doing since 2012 without any problem does not sound cool to me.
<slangasek> bzoltan: how are you defining "major version"? major version of Qt?
<bzoltan> slangasek:  yes
<bzoltan> 5.X
<slangasek> bzoltan: so you are asserting that there will never be a libubuntumetrics6 until qt6?
<slangasek> because libubuntumetrics will not break ABI for as long as it's against Qt5?
<bzoltan> and 6 is coming. So we have about 1.5 years to survive like we did for 5 years :)
<bzoltan> slangasek:  yes, that is the idea
<slangasek> it needs to be more than an idea, it needs to be a committment :)
<bzoltan> slangasek:  and yes, I will kick loicm's ass if he changes something to cause ABI break
<bzoltan> slangasek:  I am commited, fully.
<slangasek> bzoltan: ok, thanks for stating this clearly
<bzoltan> infinity: slangasek:  and yes, I have a prototype already to track ABIs under the Qt umbrella
<slangasek> infinity: ^^ does this address the concern to your satisfaction?
<bzoltan> slangasek:  I think infinity's concern is how we guarantee ABI compatibility. We should have a release to release ABI tracking mechanims. What we have, as the UITK releases are tested with the applications built against the previous UITK version. Ifthat makes sense.
<bzoltan> What I am not happy about is that it is Friday night..I am after a massive hurde of releasing this UITK. 2 days of autopilot testing, a day with autopkgtests, 2 rounds of manual QA. And now I do not even have anybody in my team who could review a packaging change. And yes we have a rule that we do not land changes without a review. All of it because of packaging issus what I do promise to fix next week with the next landing. Not like I am going away :)
<flocculant> Laney: did studio et al get turned on again for the tracker - dailies seem hit and miss for those who did b1
<Laney> 29 16 * * *	for-project lubuntu cron.daily; for-project lubuntu cron.daily-live --live; for-project lubuntu-next cron.daily-live --live
<Laney> 17 18 * * *	for-project ubuntustudio cron.dvd --live
<Laney> etc
<Laney> Wait for a full day. :P
<Laney> I wonder if I should turn kubuntu back on
<Laney> yofel: ^-?
<flocculant> Laney: oh my - sorry old chap - and I knew those times too cos I changed the xubuntu one ... long day on the coal face here ;)
<slangasek> bzoltan: it is not the archive admins' fault that you waited until Friday night to request the NEW review of this.  This can be requested at any time during the landing process
<bzoltan> slangasek: I did not know that.
<slangasek> and as previously mentioned, the review is not a rubber stamp
<bzoltan> slangasek: Of curse not. Still I do not think that the issues flagged out here are so severe that can not get fixed in the next landing. Specially that I do promise to do it.
<bzoltan> slangasek:  and minor versioning in a Qt plugin is really something what is not done anywhere. We develop Qt plugins and Qt libs a lot... not a single is numbered. The Qt major version is in the path, that is all.
<infinity> slangasek: Yes, if they're tracking ABI, that addresses the concern.
<infinity> Well, tracking and committing to not changing.
<bzoltan> infinity: is any other project or package what delivers Qt library does any sort of ABI tracking?
<bzoltan> ... rethorical question
<infinity> bzoltan: Upstream does.
<bzoltan> infinity:  the commitment that we do not break ABI means that if that happens then we fix it right away
<infinity> bzoltan: I don't know what other non-upstream Qt libraries do.
<bzoltan> infinity: I do
<infinity> bzoltan: And that's not how ABI tracking works.  You don't fix it after you land it broken.  You catch the break in your testing and don't land it. :P
<infinity> bzoltan: Anyhow, I'm asking you to track ABI.  I don't care what bridge other projects jump off of.
<bzoltan> infinity: As I said, I am happy to discuss this issue with you. But I am not happy to change the rules during a game.
<infinity> No one's changing any rules.
<bzoltan> infinity: you just did
<infinity> I really didn't.
<infinity> Either track ABI or version your path.
<bzoltan> infinity:  nobody was ever requiring the UITK to put minor versions in the path
<bzoltan> infinity: so it is a new rule. logical in a way and very deffendable fo rsure.. but new
<infinity> Not new to me.
<infinity> I don't review every upload.
<bzoltan> infinity: and as I said all functional tests of each new UITK libs are run against apps what are built against the previous UITK.
<bzoltan> infinity: from my point it is a massive change in the rule. We have been lanidng new packags for years under the UITK. Not a single time I have heard that we should add minor versions to the library paths.
<infinity> This isn't a minor version.
<infinity> It's the SOVER of the library.
<bzoltan> infinity: okey, but that does not make my point invalid. New rule in the middle of a game.
<tsimonq2> infinity: pillows are comfy but suck for productivity :P np
<slangasek> bzoltan: this is a standard rule for the archive.  That you were unaware of it is part of why AA review is required.
<slangasek> bzoltan: but as you have confirmed that yes, the ABI will not change until the Qt major version changes, I believe we're all in agreement that we can let this in
<bzoltan> slangasek: but sir, this is how we land library packages since 2012. We always considered the UITK as a Qt plugin and we have not broke a single time any ABI for any app
<slangasek> bzoltan: no, it's *not*, because this is the first time you have uploaded a library binary package with files whose paths were not versioned in a way that was obviously changing in lockstep with your library's soname
<bzoltan> slangasek: I agree. And I have started to work on adding version numbering to the UITK lib paths.
<bzoltan> slangasek: as I have said to infinity and to pitti, I understand their point and it makes sense... I just would not not like to block this UITK landing because of this.
<slangasek> we have already agreed that your committment regarding ABI versioning - which was not obvious from looking at the packaging - is sufficient to let this package into the archive as-is
<bzoltan> slangasek: Thank you
<slangasek> bzoltan: now, as for the mechanics of releasing it, there's still the QA NACK on the landing which needs clarification
<bzoltan> slangasek: It is OK before pitti's comment
<slangasek> is this a result of pitti's review, in which case I can override, or is it something else?
<slangasek> ok
<bzoltan> sil2100:^^
<sil2100> Oh
<slangasek> bzoltan, sil2100: publishing
<bzoltan> slangasek: \o/
<sil2100> slangasek: yes, the silo was +1'ed by QA so it's good to go
<slangasek> woo my first non-jenkins publication
<sil2100> It's smooth
<infinity> Death to jenkins!
<bzoltan> slangasek: sil2100: I and preparing the next landing right away and all pitti's comments will be properly addressed.
<sil2100> I mean, first time I did the non-jenkins publish I was like: "hmmm, there's something different here, not sure what, the buttons look different..."
<infinity> bzoltan: Well, seems the only remaining thing to address is the .la files.
<sil2100> Since I forgot about the rollout
<sil2100> https://trello.com/c/CPjxRFsY/3568-1808-ubuntu-landing-094-ubuntu-ui-toolkit-bzoltan was the ACK from QA
<slangasek> bzoltan: there is no need for you to further change anything because we've established that the ABI isn't changing until the Qt5 upstream soname changes
<slangasek> I was not giving you a free pass on this package going into the archive with bugs we consider blockers, I was agreeing that the package is ok as-is
<slangasek> bzoltan: oh - yes, as infinity says, the .la files should be cleaned up, but that's all
<ginggs> slangasek: thanks for removing the fpc powerpc stragglers!  would you please have another look at removing the wine-development armhf binaries? LP: #1612180
<ubot5> Launchpad bug 1612180 in wine-development (Ubuntu) "Please remove wine-developement binaries on armhf" [Undecided,Confirmed] https://launchpad.net/bugs/1612180
<slangasek> ginggs: I won't have a chance to get to that today
<ginggs> slangasek: np
<jbicha> infinity: daily isos are failing to build because seeds need updating to drop pulseaudio-module-x11 recommends, I'm doing GNOME but maybe you could do the other flavors?
<wxl> jbicha: um, lubuntu, ubuntu, mate, studio, xubuntu all seem to have current isos
<jbicha> maybe new pulseaudio hadn't been published yet, see https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/ubuntu-gnome
<jbicha> it only affects GNOME, Kylin, MATE and regular Ubuntu
<wxl> yeah i see gnome and kylin are behind
<wxl> but mate and ubuntu published today
<wxl> jbicha: https://launchpadlibrarian.net/281132926/buildlog_ubuntu_yakkety_powerpc_lubuntu_BUILDING.txt.gz >>> Setting up pulseaudio (1:9.0-2ubuntu1) ...
<wxl> that's the same version
<jbicha> wxl: apt rdepends pulseaudio-module-x11
<wxl> jbicha: ah you're right. we don't have pulseaudio-module-x11. sorry for wasting your time
<jbicha> wxl: nope, you didn't waste my time :)
<wxl> jbicha: ok well sorry for wasting MY time then XD
<jbicha> lol
<stgraber> this is a tiny fix on top of our current SRU (in proposed), would be great to accept it today so we can get some more testing over the weekend!
<stgraber> (we have obviously confirmed this particular fix to be fine)
<apw> stgraber, done
<stgraber> apw: thanks!
#ubuntu-release 2016-08-27
<jbicha> could we get the kactivities binary removed? maybe it'll help kubuntu build its iso
<jbicha> https://people.canonical.com/~ubuntu-archive/nbs.html
<slangasek> jbicha: removing
<infinity> pitti: Until LP: #1600000 is resolved, could we 's/ resolve//' on nsswitch.conf in the autopkgtest chroots?
<ubot5> Launchpad bug 1600000 in systemd (Ubuntu) "libnss-resolve treats two trailing dots on a domain name incorrectly" [Undecided,Triaged] https://launchpad.net/bugs/1600000
<tsimonq2> infinity: nice bug number :P
<infinity> pitti: You must have done so at an earlier point, since the glibc tests were passing last week, and failing again this week...
<infinity> jbicha: Mass update of seeds and metas done.  Thanks for the heads-up.
#ubuntu-release 2016-08-28
<ogra_> hmm, who is responsible for uec-images.u.c .... ? seems the release/ link got missing on http://uec-images.ubuntu.com/releases/16.04/
<slangasek> ogra_: that's an alias for http://cloud-images.ubuntu.com/releases/16.04/ and is gaughen's team; rcj or Odd_Bloke might know something
#ubuntu-release 2017-08-21
<Laney> slangasek: I added linux to long_tests for lxd; the latest results don't look like a timeout to me now. (You can see --timeout-test=40000 at the top of log output now.)
-queuebot:#ubuntu-release- New: accepted ahven [amd64] (artful-proposed) [2.6-1.2]
-queuebot:#ubuntu-release- New: accepted ahven [armhf] (artful-proposed) [2.6-1.2]
-queuebot:#ubuntu-release- New: accepted ahven [ppc64el] (artful-proposed) [2.6-1.2]
-queuebot:#ubuntu-release- New: accepted ahven [arm64] (artful-proposed) [2.6-1.2]
-queuebot:#ubuntu-release- New: accepted ahven [s390x] (artful-proposed) [2.6-1.2]
-queuebot:#ubuntu-release- New: accepted ahven [i386] (artful-proposed) [2.6-1.2]
-queuebot:#ubuntu-release- New: accepted diceware [amd64] (artful-proposed) [0.9.1-4.1]
-queuebot:#ubuntu-release- New: accepted importmagic [amd64] (artful-proposed) [0.1.7-1]
-queuebot:#ubuntu-release- New: accepted kexi [arm64] (artful-proposed) [1:3.0.2-1]
-queuebot:#ubuntu-release- New: accepted kexi [s390x] (artful-proposed) [1:3.0.2-1]
-queuebot:#ubuntu-release- New: accepted kexi [armhf] (artful-proposed) [1:3.0.2-1]
-queuebot:#ubuntu-release- Unapproved: pcl (xenial-proposed/universe) [1.7.2-14ubuntu1.16.04.1 => 1.7.2-14ubuntu1.16.04.2] (no packageset)
-queuebot:#ubuntu-release- New binary: gsl [s390x] (artful-proposed/main) [2.4+dfsg-6] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gsl [ppc64el] (artful-proposed/main) [2.4+dfsg-6] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gsl [i386] (artful-proposed/main) [2.4+dfsg-6] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gsl [amd64] (artful-proposed/main) [2.4+dfsg-6] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gsl [arm64] (artful-proposed/main) [2.4+dfsg-6] (kubuntu, ubuntu-desktop)
<LocutusOfBorg> good morning, I would like to see curl migrate, and in order to see it I think I need to hint two tests, htslib/i386 and stenographer/ppc64el
<LocutusOfBorg> both of them are regressed in release already, and curl has security fixes in
-queuebot:#ubuntu-release- New binary: gsl [armhf] (artful-proposed/main) [2.4+dfsg-6] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: asterisk [ppc64el] (artful-proposed/universe) [1:13.17.0~dfsg-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: asterisk [amd64] (artful-proposed/universe) [1:13.17.0~dfsg-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: asterisk [i386] (artful-proposed/universe) [1:13.17.0~dfsg-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: asterisk [s390x] (artful-proposed/universe) [1:13.17.0~dfsg-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: asterisk [arm64] (artful-proposed/universe) [1:13.17.0~dfsg-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: asterisk [armhf] (artful-proposed/universe) [1:13.17.0~dfsg-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New source: rdma-core (artful-proposed/primary) [15~rc1+git20170821-0ubuntu1]
-queuebot:#ubuntu-release- New binary: gjs [amd64] (artful-proposed/main) [1.49.90-0ubuntu1] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gjs [ppc64el] (artful-proposed/main) [1.49.90-0ubuntu1] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gjs [i386] (artful-proposed/main) [1.49.90-0ubuntu1] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gjs [arm64] (artful-proposed/main) [1.49.90-0ubuntu1] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gjs [armhf] (artful-proposed/main) [1.49.90-0ubuntu1] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libktorrent [ppc64el] (artful-proposed/universe) [2.0.90-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libktorrent [amd64] (artful-proposed/universe) [2.0.90-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libktorrent [s390x] (artful-proposed/universe) [2.0.90-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libktorrent [i386] (artful-proposed/universe) [2.0.90-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libktorrent [arm64] (artful-proposed/universe) [2.0.90-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libktorrent [armhf] (artful-proposed/universe) [2.0.90-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted asterisk [amd64] (artful-proposed) [1:13.17.0~dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted asterisk [armhf] (artful-proposed) [1:13.17.0~dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted asterisk [ppc64el] (artful-proposed) [1:13.17.0~dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted gsl [amd64] (artful-proposed) [2.4+dfsg-6]
-queuebot:#ubuntu-release- New: accepted gsl [armhf] (artful-proposed) [2.4+dfsg-6]
-queuebot:#ubuntu-release- New: accepted gsl [ppc64el] (artful-proposed) [2.4+dfsg-6]
-queuebot:#ubuntu-release- New: accepted asterisk [arm64] (artful-proposed) [1:13.17.0~dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted asterisk [s390x] (artful-proposed) [1:13.17.0~dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted gsl [i386] (artful-proposed) [2.4+dfsg-6]
-queuebot:#ubuntu-release- New: accepted asterisk [i386] (artful-proposed) [1:13.17.0~dfsg-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted gsl [s390x] (artful-proposed) [2.4+dfsg-6]
-queuebot:#ubuntu-release- New: accepted gsl [arm64] (artful-proposed) [2.4+dfsg-6]
-queuebot:#ubuntu-release- New: accepted libktorrent [amd64] (artful-proposed) [2.0.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libktorrent [armhf] (artful-proposed) [2.0.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libktorrent [ppc64el] (artful-proposed) [2.0.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libktorrent [arm64] (artful-proposed) [2.0.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libktorrent [s390x] (artful-proposed) [2.0.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libktorrent [i386] (artful-proposed) [2.0.90-0ubuntu1]
<LocutusOfBorg> apw, pleeeeeeeease hint virtualbox testsuite, because of virtualbox/kernel merges
<LocutusOfBorg> Error! Module version 5.1.26_Ubuntu for vboxguest.ko
<LocutusOfBorg> is not newer than what is already found in kernel 4.12.0-11-generic (5.1.26_Ubuntu).
<LocutusOfBorg> You may override by specifying --force.
<LocutusOfBorg> (or fix testsuite, even better :p )
 * LocutusOfBorg grabs src:linux
<LocutusOfBorg> mmm I don't understand where the test is located
<apw> the test is located as part of dkms as an autodep8 test
<apw> and that is a valid failure mode for that test in that one case
<apw> LocutusOfBorg, hinted
<LocutusOfBorg> thanks <3
-queuebot:#ubuntu-release- New: accepted gjs [amd64] (artful-proposed) [1.49.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted gjs [armhf] (artful-proposed) [1.49.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted gjs [ppc64el] (artful-proposed) [1.49.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted gjs [arm64] (artful-proposed) [1.49.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted gjs [i386] (artful-proposed) [1.49.90-0ubuntu1]
-queuebot:#ubuntu-release- New binary: budgie-desktop [i386] (artful-proposed/universe) [10.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: budgie-desktop [ppc64el] (artful-proposed/universe) [10.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: budgie-desktop [amd64] (artful-proposed/universe) [10.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: budgie-desktop [arm64] (artful-proposed/universe) [10.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: budgie-desktop [armhf] (artful-proposed/universe) [10.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: budgie-desktop [s390x] (artful-proposed/universe) [10.4-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: binutils (xenial-proposed/main) [2.26.1-1ubuntu1~16.04.4 => 2.26.1-1ubuntu1~16.04.5] (core)
-queuebot:#ubuntu-release- New binary: evolution [ppc64el] (artful-proposed/universe) [3.25.91-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: evolution [i386] (artful-proposed/universe) [3.25.91-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: evolution [s390x] (artful-proposed/universe) [3.25.91-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: evolution [amd64] (artful-proposed/universe) [3.25.91-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: evolution [arm64] (artful-proposed/universe) [3.25.91-0ubuntu1] (ubuntukylin)
-queuebot:#ubuntu-release- New binary: evolution [armhf] (artful-proposed/universe) [3.25.91-0ubuntu1] (ubuntukylin)
<bdmurray> slangasek: I feel like http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#update-notifier is incorrectly marked as a regression
<bdmurray> The u-m autopkgtest passed with 16.04.9 but the failure here is with u-m 16.04.8 which is a version number < the one that passed.
-queuebot:#ubuntu-release- New binary: netty-tcnative-1.1 [ppc64el] (artful-proposed/universe) [1.1.33.Fork26-2] (no packageset)
-queuebot:#ubuntu-release- New binary: honeysql-clojure [amd64] (artful-proposed/universe) [0.8.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: clj-digest-clojure [amd64] (artful-proposed/universe) [1.4.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: clj-time-clojure [amd64] (artful-proposed/universe) [0.14.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: typesafe-config-clojure [amd64] (artful-proposed/universe) [0.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: beckon-clojure [amd64] (artful-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: netty-tcnative-1.1 [arm64] (artful-proposed/universe) [1.1.33.Fork26-2] (no packageset)
-queuebot:#ubuntu-release- New binary: netty-tcnative-1.1 [i386] (artful-proposed/universe) [1.1.33.Fork26-2] (no packageset)
-queuebot:#ubuntu-release- New binary: core-async-clojure [amd64] (artful-proposed/universe) [0.3.443-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ring-codec-clojure [amd64] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: netty-tcnative-1.1 [armhf] (artful-proposed/universe) [1.1.33.Fork26-2] (no packageset)
-queuebot:#ubuntu-release- New binary: prismatic-schema-clojure [amd64] (artful-proposed/universe) [1.1.6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: netty-tcnative-1.1 [amd64] (artful-proposed/universe) [1.1.33.Fork26-2] (no packageset)
-queuebot:#ubuntu-release- New binary: netty-tcnative-1.1 [s390x] (artful-proposed/universe) [1.1.33.Fork26-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: backuppc (xenial-proposed/main) [3.3.1-2ubuntu3.2 => 3.3.1-2ubuntu3.3] (core)
-queuebot:#ubuntu-release- New source: kdav (artful-proposed/primary) [17.04.3-0ubuntu1]
<slangasek> bdmurray: yes, that is a bug in how britney is defining 'regression'.  Should be fixed, but I usually just work around it by re-triggering the test with both packages from -proposed
<slangasek> bdmurray: (which I'm doing now for u-m + u-n)
<slangasek> bdmurray: and one reason for doing this is that we make sure that, having just fixed the autopkgtest for update-manager, we aren't silently letting it regress again with update-notifier
-queuebot:#ubuntu-release- New source: py3c (artful-proposed/primary) [0.8-1]
-queuebot:#ubuntu-release- New: accepted netty-tcnative-1.1 [amd64] (artful-proposed) [1.1.33.Fork26-2]
-queuebot:#ubuntu-release- New: accepted netty-tcnative-1.1 [armhf] (artful-proposed) [1.1.33.Fork26-2]
-queuebot:#ubuntu-release- New: accepted netty-tcnative-1.1 [ppc64el] (artful-proposed) [1.1.33.Fork26-2]
-queuebot:#ubuntu-release- New: accepted netty-tcnative-1.1 [arm64] (artful-proposed) [1.1.33.Fork26-2]
-queuebot:#ubuntu-release- New: accepted netty-tcnative-1.1 [s390x] (artful-proposed) [1.1.33.Fork26-2]
-queuebot:#ubuntu-release- New: accepted netty-tcnative-1.1 [i386] (artful-proposed) [1.1.33.Fork26-2]
-queuebot:#ubuntu-release- New: accepted budgie-desktop [amd64] (artful-proposed) [10.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted budgie-desktop [armhf] (artful-proposed) [10.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted budgie-desktop [ppc64el] (artful-proposed) [10.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted budgie-desktop [arm64] (artful-proposed) [10.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted budgie-desktop [s390x] (artful-proposed) [10.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted budgie-desktop [i386] (artful-proposed) [10.4-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted evolution [amd64] (artful-proposed) [3.25.91-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted evolution [armhf] (artful-proposed) [3.25.91-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted evolution [ppc64el] (artful-proposed) [3.25.91-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted py3c [source] (artful-proposed) [0.8-1]
-queuebot:#ubuntu-release- New: accepted evolution [arm64] (artful-proposed) [3.25.91-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted evolution [s390x] (artful-proposed) [3.25.91-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted evolution [i386] (artful-proposed) [3.25.91-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted beckon-clojure [amd64] (artful-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted clj-time-clojure [amd64] (artful-proposed) [0.14.0-1]
-queuebot:#ubuntu-release- New: accepted honeysql-clojure [amd64] (artful-proposed) [0.8.2-1]
-queuebot:#ubuntu-release- New: accepted ring-codec-clojure [amd64] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted clj-digest-clojure [amd64] (artful-proposed) [1.4.5-1]
-queuebot:#ubuntu-release- New: accepted prismatic-schema-clojure [amd64] (artful-proposed) [1.1.6-1]
-queuebot:#ubuntu-release- New: accepted core-async-clojure [amd64] (artful-proposed) [0.3.443-1]
-queuebot:#ubuntu-release- New: accepted typesafe-config-clojure [amd64] (artful-proposed) [0.1.5-1]
-queuebot:#ubuntu-release- New: accepted kdav [source] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: py3c [amd64] (artful-proposed/universe) [0.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kdav [ppc64el] (artful-proposed/universe) [17.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted py3c [amd64] (artful-proposed) [0.8-1]
-queuebot:#ubuntu-release- New binary: kdav [i386] (artful-proposed/universe) [17.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kdav [amd64] (artful-proposed/universe) [17.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kdav [arm64] (artful-proposed/universe) [17.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kdav [s390x] (artful-proposed/universe) [17.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: kdav [armhf] (artful-proposed/universe) [17.04.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted kdav [amd64] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdav [armhf] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdav [ppc64el] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdav [arm64] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdav [s390x] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kdav [i386] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~16.04.2 => 0.7.9-233-ge586fe35-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~17.04.2 => 0.7.9-233-ge586fe35-0ubuntu1~17.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- New binary: ring-mock-clojure [amd64] (artful-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libi8x [amd64] (artful-proposed/universe) [0.0.5~pre1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: prismatic-plumbing-clojure [amd64] (artful-proposed/universe) [0.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libi8x [i386] (artful-proposed/universe) [0.0.5~pre1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kmime [amd64] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kmime [i386] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kpimtextedit [amd64] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libi8x [ppc64el] (artful-proposed/universe) [0.0.5~pre1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kmime [ppc64el] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kpimtextedit [i386] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kpimtextedit [ppc64el] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5grantleetheme [amd64] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kmime [arm64] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kmime [s390x] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kmime [armhf] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libi8x [arm64] (artful-proposed/universe) [0.0.5~pre1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: kpimtextedit [arm64] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kpimtextedit [armhf] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kpimtextedit [s390x] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted libi8x [amd64] (artful-proposed) [0.0.5~pre1-1]
-queuebot:#ubuntu-release- New: accepted libi8x [i386] (artful-proposed) [0.0.5~pre1-1]
-queuebot:#ubuntu-release- New: accepted prismatic-plumbing-clojure [amd64] (artful-proposed) [0.5.4-1]
-queuebot:#ubuntu-release- New: accepted libi8x [arm64] (artful-proposed) [0.0.5~pre1-1]
-queuebot:#ubuntu-release- New: accepted ring-mock-clojure [amd64] (artful-proposed) [0.3.1-1]
-queuebot:#ubuntu-release- New: accepted libi8x [ppc64el] (artful-proposed) [0.0.5~pre1-1]
-queuebot:#ubuntu-release- New sync: libreoffice-l10n (artful-release/primary) [1:5.3.4-0ubuntu1]
-queuebot:#ubuntu-release- New sync: libreoffice-l10n (artful-proposed/primary) [1:5.4.0-0ubuntu1]
-queuebot:#ubuntu-release- New sync: libreoffice-l10n (artful-release/primary) [1:5.3.4-0ubuntu1]
#ubuntu-release 2017-08-22
-queuebot:#ubuntu-release- New: accepted kpimtextedit [amd64] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kpimtextedit [armhf] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kpimtextedit [ppc64el] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kpimtextedit [arm64] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kpimtextedit [s390x] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kpimtextedit [i386] (artful-proposed) [17.04.3-0ubuntu1]
<doko> three libreoffice-l10n syncs?
-queuebot:#ubuntu-release- New: accepted kmime [amd64] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kmime [armhf] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kmime [ppc64el] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kmime [arm64] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kmime [s390x] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kmime [i386] (artful-proposed) [17.04.3-0ubuntu1]
<doko> and to the *release* pocket?
-queuebot:#ubuntu-release- New: accepted libkf5grantleetheme [amd64] (artful-proposed) [17.04.3-0ubuntu1]
<nacc> doko: i think see the discussion between xnox and seb128 in #ubuntu-devel
-queuebot:#ubuntu-release- New binary: clout-clojure [amd64] (artful-proposed/universe) [2.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ring-anti-forgery-clojure [amd64] (artful-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: akonadi-notes [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kblog [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kimap [amd64] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkgapi [amd64] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kidentitymanagement [amd64] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkgapi [arm64] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkgapi [armhf] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkgapi [i386] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kldap [amd64] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kmailtransport [ppc64el] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kmailtransport [i386] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kmailtransport [amd64] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kmailtransport [arm64] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kmailtransport [s390x] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kmailtransport [armhf] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: cypari2 [ppc64el] (artful-proposed/universe) [1.0.0-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cypari2 [amd64] (artful-proposed/universe) [1.0.0-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cypari2 [arm64] (artful-proposed/universe) [1.0.0-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cypari2 [i386] (artful-proposed/universe) [1.0.0-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cypari2 [armhf] (artful-proposed/universe) [1.0.0-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cypari2 [s390x] (artful-proposed/universe) [1.0.0-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted cypari2 [amd64] (artful-proposed) [1.0.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted cypari2 [armhf] (artful-proposed) [1.0.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted cypari2 [ppc64el] (artful-proposed) [1.0.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted cypari2 [arm64] (artful-proposed) [1.0.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted cypari2 [s390x] (artful-proposed) [1.0.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted cypari2 [i386] (artful-proposed) [1.0.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted clout-clojure [amd64] (artful-proposed) [2.1.2-1]
-queuebot:#ubuntu-release- New: accepted ring-anti-forgery-clojure [amd64] (artful-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New source: libreoffice-l10n (artful-proposed/primary) [1:5.4.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libreoffice-l10n [source] (artful-proposed) [1:5.4.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libreoffice-l10n [sync] (artful-release) [1:5.3.4-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected libreoffice-l10n [sync] (artful-proposed) [1:5.4.0-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected libreoffice-l10n [sync] (artful-release) [1:5.3.4-0ubuntu1]
<fossfreedom_> in the artful excuses for budgie-desktop it is saying there are old-binaries left on each architecture.  Is this something that gets cleaned up automatically or can someone poke it to allow budgie-desktop to migrate from proposed to release? http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_excuses.html#budgie-desktop
-queuebot:#ubuntu-release- New binary: libreoffice [s390x] (artful-proposed/main) [1:5.4.0-0ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: lsvpd (xenial-proposed/universe) [1.7.6-0ubuntu3 => 1.7.6-0ubuntu4] (no packageset)
-queuebot:#ubuntu-release- New binary: libreoffice [ppc64el] (artful-proposed/main) [1:5.4.0-0ubuntu2] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: pulseaudio (xenial-proposed/main) [1:8.0-0ubuntu3.3 => 1:8.0-0ubuntu3.4] (core)
-queuebot:#ubuntu-release- New binary: libreoffice-l10n [amd64] (artful-proposed/main) [1:5.4.0-0ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted akonadi-notes [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kblog [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kimap [amd64] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kidentitymanagement [amd64] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kldap [amd64] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kmailtransport [amd64] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kmailtransport [armhf] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kmailtransport [ppc64el] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libreoffice-l10n [amd64] (artful-proposed) [1:5.4.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted kmailtransport [arm64] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kmailtransport [s390x] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kmailtransport [i386] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkgapi [amd64] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkgapi [armhf] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkgapi [arm64] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkgapi [i386] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: kcalutils [ppc64el] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kalarmcal [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kcalutils [s390x] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kcalutils [i386] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5libkdepim [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5libkdepim [arm64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5libkdepim [armhf] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5libkdepim [i386] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kcalutils [arm64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kcalutils [armhf] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted kalarmcal [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: kcalutils [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
<slashd> For SRU, if someone have some cycle, could you please have a look at the CUPS pkg upload for Xenial ? (LP: #1642966)
<ubot5> Launchpad bug 1642966 in cups (Ubuntu Xenial) "package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1" [High,In progress] https://launchpad.net/bugs/1642966
-queuebot:#ubuntu-release- New source: gnome-shell-extension-appindicator (artful-proposed/primary) [17.10]
-queuebot:#ubuntu-release- New: accepted libreoffice [ppc64el] (artful-proposed) [1:5.4.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted libreoffice [s390x] (artful-proposed) [1:5.4.0-0ubuntu2]
-queuebot:#ubuntu-release- New: accepted gnome-shell-extension-appindicator [source] (artful-proposed) [17.10]
<LocutusOfBorg> fossfreedom_, can I upload the budgie-desktop on debian-mentors and force-sync in Ubuntu?
<LocutusOfBorg> diff shows a gsd.patch and an additional dependency on gnome-settings-daemon-dev,
-queuebot:#ubuntu-release- New binary: gnome-shell-extension-appindicator [amd64] (artful-proposed/none) [17.10] (no packageset)
-queuebot:#ubuntu-release- New: accepted gnome-shell-extension-appindicator [amd64] (artful-proposed) [17.10]
-queuebot:#ubuntu-release- New: accepted kcalutils [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kcalutils [armhf] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kcalutils [ppc64el] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kcalutils [arm64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kcalutils [s390x] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kcalutils [i386] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5libkdepim [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5libkdepim [armhf] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5libkdepim [arm64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5libkdepim [i386] (artful-proposed) [4:17.04.3-0ubuntu1]
<xnox> slangasek, all images should be generated with /etc/resolv.conf pointing to ../run/systemd/resolve/stub-resolv.conf
<xnox> currently all images are generated with /etc/resolv.conf being a regular empty file
<xnox> in xenial, /etc/resolv.conf ends up a symlink to ../run/resolvconf/resolv.conf but i'm failing to find where/how that is done
<xnox> is that achieved by resolvconf maintscripts somehow? cause i am failing to trace that. And e.g. local runs of debootstrap simply end up with a copy of my host /etc/resolv.conf
<xnox> forcing livecd-rootfs feels wrong https://code.launchpad.net/~xnox/livecd-rootfs/force-resolved-stub-resolver/+merge/329358
<xnox> also it seems like i have missed integrating casper with resolved
-queuebot:#ubuntu-release- New binary: libkf5mailimporter [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5pimcommon [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
<xnox> ah
<xnox> $ ls -latr ./live-build/ubuntu-core/includes.chroot/etc/resolv.conf
<xnox> lrwxrwxrwx 1 xnox xnox 29 Aug 14 16:59 ./live-build/ubuntu-core/includes.chroot/etc/resolv.conf -> ../run/resolvconf/resolv.conf
-queuebot:#ubuntu-release- New binary: libkf5mailimporter [arm64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5mailimporter [armhf] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5pimcommon [i386] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5pimcommon [arm64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5pimcommon [armhf] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5mailimporter [i386] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
<xnox> slangasek, should systemd postinst do this? http://paste.ubuntu.com/25369990/
-queuebot:#ubuntu-release- New binary: ktnef [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
<xnox> slangasek, seems like systemd should do that; netcfg should be fixed up to work with stub-resolv.conf; and we still need fixes elsewhere in e.g. debootstrap? livecd-rootfs?
 * xnox is not sure how xenial desktop images have /etc/resolv.conf symlink
-queuebot:#ubuntu-release- New binary: akonadi-calendar [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted akonadi-calendar [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ktnef [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailimporter [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailimporter [armhf] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5pimcommon [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5pimcommon [armhf] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailimporter [arm64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5pimcommon [arm64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailimporter [i386] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5pimcommon [i386] (artful-proposed) [4:17.04.3-0ubuntu1]
<slashd> For RAOF or any SRU folks, I'm resending my request because I'm afraid it was lost between all the "New: accepted ..." lines above --> if someone have some cycle, could you please have a look at the CUPS pkg uploaded for Xenial ? (LP: #1642966)
<ubot5> Launchpad bug 1642966 in cups (Ubuntu Xenial) "package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1" [High,In progress] https://launchpad.net/bugs/1642966
-queuebot:#ubuntu-release- New binary: libkf5gravatar [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted libkf5gravatar [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: kf5-messagelib [i386] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kf5-messagelib [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kf5-messagelib [arm64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: kf5-messagelib [armhf] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
<LocutusOfBorg> doko, since autopkgtests are empty, can I retry all regressions? now systemd sadness should be ok
<LocutusOfBorg> and abi-compliance-checker migrated
<doko> LocutusOfBorg: I'm not release team ;p
<doko> but I assume you can
<LocutusOfBorg> I saw lots of failures due to abi-compliance/debhelper changes, and also systemd on armhf
<LocutusOfBorg> I think it doesn't hurt
<LocutusOfBorg> well, you are not RT, but your opinion is valuable for me
<LocutusOfBorg> I would even do some rebuilds of failed stuff, but you do that already, right?
 * LocutusOfBorg won't retry with --all-proposed
<LocutusOfBorg> Laney, ^^
<Laney> how many are we talking?
<LocutusOfBorg> 700 in total I guess
<LocutusOfBorg> so, around 100 for each arch or something close
<LocutusOfBorg> for now I'm retrying the "test in progresses" because update_excuses shows 67 of them, while autopkgtests has almost zero queue
<LocutusOfBorg> they should clear some kde* sadness
 * LocutusOfBorg thinks it would be nice to have a service that automagically runs stuff against -proposed, and discards the results, just to make you aware of a possible fix there
<LocutusOfBorg> doko, I think I fixed some gnat stuff, while the others are issues in debian too (not sure why the bugs are just normal and not RC)
<LocutusOfBorg> e.g. ahven anet and so on
<LocutusOfBorg> libgnatcoll is obscure to me the reason for the failure
<Laney> why are there stuck tests in progress?
<Laney> that is a bug that you shouldn't just paper over by retrying things
<LocutusOfBorg> Laney, I think there is a bug already open
<LocutusOfBorg> some processes when the infra got upgraded didn't save the status correctly
<LocutusOfBorg> it was discussed here some days ago
<LocutusOfBorg> there was some infra issue, stuff got restarted and apt showed a security update kicked in
<LocutusOfBorg> stuff stuck might be around 10 packages so it I'm pretty sure it is related to that issue, but nobody reckicked them
<Laney> the rabbitmq thing some weeks ago?
<LocutusOfBorg> yes, probably that one
<LocutusOfBorg> I still need to figure out how to search irc logs :/
<LocutusOfBorg> now BNC is adding more complexity to my poor brain
<Laney> I know what you're referring to
<Laney> so if they are requests from 3 weeks or so ago, that's probably okay
<Laney> otherwise it's something I want to know about
<LocutusOfBorg> if you want some examples, autopkgtest for kwin/4:5.10.4-0ubuntu1: amd64: Pass, armhf: Test in progress, i386: Pass, ppc64el: Pass, s390x: Pass
<LocutusOfBorg> 13 days ago
<Laney> don't see it
<LocutusOfBorg> in update_excuses
<acheronuk> against what?
<Laney> which trigger?
<Laney> ok, found it
<LocutusOfBorg> sorry, I wrote it but I didn't send the message, sorry
<LocutusOfBorg> I'm trying to use the query to search a missing result
<Laney> annoying
<Laney> logs don't go back that far
<LocutusOfBorg> :(
<LocutusOfBorg> I retried all of the regressions+running and they are 300 in total
<LocutusOfBorg> I presume in a couple  of hours we will clear them
<LocutusOfBorg> acheronuk, it was qtmultimedia
<LocutusOfBorg> also qtsystems
<acheronuk> I found it in the end!
-queuebot:#ubuntu-release- Unapproved: postfix (trusty-proposed/main) [2.11.0-1ubuntu1.1 => 2.11.0-1ubuntu1.2] (core)
<LocutusOfBorg> requests
-queuebot:#ubuntu-release- New binary: libkf5incidenceeditor [amd64] (artful-proposed/universe) [17.04.3-0ubuntu1] (kubuntu)
<acheronuk> if someone can spare the time, could the new kf5-messagelib binaries be accepted please?
<LocutusOfBorg> Laney, btw, I did merge ben into the transition bzr repo, can you please check it if it still works?
<acheronuk> that is a bit of a bottleneck getting KDE PIM stack built: http://people.ubuntu.com/~rikmills/ka-iron-hand_reports/applications_archive/17.04.3_artful_proposed_migration.pdf
 * LocutusOfBorg moves old/finished transitions to old
<Laney> LocutusOfBorg: it's not going to use that
<Laney> it's using the package from trusty :'(
<LocutusOfBorg> oh ok :( I was interested in some bug fixes and new features
<LocutusOfBorg> the "partial" thing, the index fix and so on :/
<Laney> we should get it updated
<LocutusOfBorg> soo just to be sure, this repo is useless? https://code.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/ben
<Laney> well I think we were using it as the archive's VCS
<Laney> so it's not useless in that sense
<Laney> but it isn't what the people.canonical.com instance is using
<LocutusOfBorg> ack
-queuebot:#ubuntu-release- New: accepted kf5-messagelib [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kf5-messagelib [armhf] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5incidenceeditor [amd64] (artful-proposed) [17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kf5-messagelib [arm64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted kf5-messagelib [i386] (artful-proposed) [4:17.04.3-0ubuntu1]
<acheronuk> thank you ^^^
<LocutusOfBorg> thanks!
<LocutusOfBorg> acheronuk, you should wait for dinstall+publisher before retrying them :)
<LocutusOfBorg> I have the command ready to be ran
<Laney> can you PLEASE make it so that the tests don't all have to be retried every time?
-queuebot:#ubuntu-release- New binary: dcmtk [s390x] (artful-proposed/universe) [3.6.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dcmtk [ppc64el] (artful-proposed/universe) [3.6.2-2] (no packageset)
<LocutusOfBorg> Laney, how? they are automatically run against release, or am I wrong?
-queuebot:#ubuntu-release- New binary: dcmtk [i386] (artful-proposed/universe) [3.6.2-2] (no packageset)
<Laney> at least they can have better dependencies specified so that they don't all run and then fail
<Laney> and have to be retried with all-proposed
<nacc> LocutusOfBorg: i think the point was to try and get them to pass at the beginning :)
<LocutusOfBorg> Laney, you means sourceful changes... ack
<LocutusOfBorg> acheronuk, ^^ :)
 * LocutusOfBorg goes to cry in a corner for dcmtk
<Laney> It's really a problem that all the KDE tests have to rebuild their package
 * Laney says this once a week :-)
<LocutusOfBorg> all the KDE testsuite is a problem I would say
<LocutusOfBorg> what is the point in trying to rebuild stuff? we already need to do it
<LocutusOfBorg> so, they add mostly zero value
<Laney> what GNOME does is good - build the testsuite in a way that can be shipped in a package to be run later on
-queuebot:#ubuntu-release- New binary: dcmtk [amd64] (artful-proposed/universe) [3.6.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: dcmtk [armhf] (artful-proposed/universe) [3.6.2-2] (no packageset)
<LocutusOfBorg> Laney, lots of tests for src:linux fails with ENOSPACE on s390x, can we do something about this?
<LocutusOfBorg> http://autopkgtest.ubuntu.com/packages/l/linux/artful/s390x
<LocutusOfBorg> apw, ^^ FYI
-queuebot:#ubuntu-release- New binary: dcmtk [arm64] (artful-proposed/universe) [3.6.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libkf5mailcommon [amd64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
<LocutusOfBorg> and libkf5mailcommon should unblock all the others k* packages
<fossfreedom_> hi - please could someone please delete the gir1.2-budgie-desktop-1.0 (from budgie-desktop 10.3.1-5) binary in artful proposed to allow budgie-desktop v10.4 to migrate
<fossfreedom_> LocutusOfBorg, thanks for poking the sid package of budgie desktop.  much appreciated
<acheronuk> LocutusOfBorg: mostly. that PIM dep chain is a PITA!
<LocutusOfBorg> fossfreedom_, I changed it a little bit, please confirm it works
<fossfreedom_> will do.  kind of swamped at the mo' - will try asap
<LocutusOfBorg> archive admins: the "delete the gir1.2-budgie-desktop-1.0" is an NBS in proposed
-queuebot:#ubuntu-release- New binary: libkf5mailcommon [i386] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5mailcommon [arm64] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: libkf5mailcommon [armhf] (artful-proposed/universe) [4:17.04.3-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted dcmtk [amd64] (artful-proposed) [3.6.2-2]
-queuebot:#ubuntu-release- New: accepted dcmtk [armhf] (artful-proposed) [3.6.2-2]
-queuebot:#ubuntu-release- New: accepted dcmtk [ppc64el] (artful-proposed) [3.6.2-2]
-queuebot:#ubuntu-release- New: accepted dcmtk [arm64] (artful-proposed) [3.6.2-2]
-queuebot:#ubuntu-release- New: accepted dcmtk [s390x] (artful-proposed) [3.6.2-2]
-queuebot:#ubuntu-release- New: accepted dcmtk [i386] (artful-proposed) [3.6.2-2]
-queuebot:#ubuntu-release- New: accepted libkf5mailcommon [amd64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailcommon [armhf] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailcommon [arm64] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted libkf5mailcommon [i386] (artful-proposed) [4:17.04.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: nut (trusty-proposed/main) [2.7.1-1ubuntu1 => 2.7.1-1ubuntu1.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nut (xenial-proposed/main) [2.7.2-4ubuntu1 => 2.7.2-4ubuntu1.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: nut (zesty-proposed/main) [2.7.4-5ubuntu2 => 2.7.4-5ubuntu2.1] (kubuntu, ubuntu-desktop, ubuntu-server)
<LocutusOfBorg> xnox, I was pretty sure you fixed this issue /data/adttmp/autopkgtest-virt-lxc.shared.15o0ue1p/downtmp/build.xZ4/linux-4.12.0/include/net/netns/conntrack.h:8:10: fatal error: /data/adttmp/autopkgtest-virt-lxc.shared.15o0ue1p/downtmp/build.xZ4/linux-4.12.0/arch/s390/include/linux/netfilter/nf_conntrack_tcp.h: Too many open files in system
<LocutusOfBorg> from http://autopkgtest.ubuntu.com/packages/l/linux/artful/s390x https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/s390x/l/linux/20170822_184815_83d3b@/log.gz
-queuebot:#ubuntu-release- New binary: devhelp [ppc64el] (artful-proposed/main) [3.25.91-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: devhelp [i386] (artful-proposed/main) [3.25.91-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: devhelp [amd64] (artful-proposed/main) [3.25.91-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: devhelp [arm64] (artful-proposed/main) [3.25.91-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: devhelp [s390x] (artful-proposed/main) [3.25.91-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: devhelp [armhf] (artful-proposed/main) [3.25.91-0ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: qpdf [ppc64el] (artful-proposed/main) [7.0~b1-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: qpdf [s390x] (artful-proposed/main) [7.0~b1-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: qpdf [amd64] (artful-proposed/main) [7.0~b1-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: qpdf [i386] (artful-proposed/main) [7.0~b1-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: qpdf [armhf] (artful-proposed/main) [7.0~b1-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted devhelp [amd64] (artful-proposed) [3.25.91-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted devhelp [armhf] (artful-proposed) [3.25.91-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted devhelp [ppc64el] (artful-proposed) [3.25.91-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted devhelp [arm64] (artful-proposed) [3.25.91-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted devhelp [s390x] (artful-proposed) [3.25.91-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted devhelp [i386] (artful-proposed) [3.25.91-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted qpdf [amd64] (artful-proposed) [7.0~b1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted qpdf [i386] (artful-proposed) [7.0~b1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted qpdf [s390x] (artful-proposed) [7.0~b1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted qpdf [armhf] (artful-proposed) [7.0~b1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: qpdf [arm64] (artful-proposed/main) [7.0~b1-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted qpdf [ppc64el] (artful-proposed) [7.0~b1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted qpdf [arm64] (artful-proposed) [7.0~b1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: node-regenerator-transform [amd64] (artful-proposed/none) [0.9.8-1] (no packageset)
<xnox> Laney, we may need lxc clean up on s390x
-queuebot:#ubuntu-release- New binary: qgis [ppc64el] (artful-proposed/universe) [2.14.18+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: qgis [amd64] (artful-proposed/universe) [2.14.18+dfsg-1] (no packageset)
#ubuntu-release 2017-08-23
-queuebot:#ubuntu-release- New binary: qgis [i386] (artful-proposed/universe) [2.14.18+dfsg-1] (no packageset)
<RAOF> slashd: I take it the cups upload is meant to solve the upgrade problem at the same time as the autoshutdown problem?
-queuebot:#ubuntu-release- Unapproved: rejected cups [source] (xenial-proposed) [2.1.3-4ubuntu0.3]
-queuebot:#ubuntu-release- New binary: qgis [s390x] (artful-proposed/universe) [2.14.18+dfsg-1] (no packageset)
<xnox> RAOF, yes, but i don't see that upload in the queue, is there one?
<xnox> oh rejected, why?
<RAOF> Because it needs the 0.2 changelog in the changes file.
<xnox> RAOF, and 0.1
<xnox> that is true.
<RAOF> I guess that too.
<xnox> RAOF, shall i reupload with correct changes?
 * xnox and slashd were working together on this upload to finally fix all the things
<RAOF> xnox: Please do so.
-queuebot:#ubuntu-release- Unapproved: cups (xenial-proposed/main) [2.1.3-4ubuntu0.2 => 2.1.3-4ubuntu0.3] (core)
<slashd> xnox, RAOF what need to be change ?
<xnox> slashd, debuild -S -nc -v2.1.3-4
<xnox> the -v2.1.3-4 such that .changes includes debian/changelog with all of the failed update attempts =)
<xnox> i reuploaded already, see above
<slashd> xnox, ok thanks for jumping on it that quick, I just notice the irc highlight
-queuebot:#ubuntu-release- New binary: qgis [arm64] (artful-proposed/universe) [2.14.18+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cups [source] (xenial-proposed) [2.1.3-4ubuntu0.3]
<slashd> thanks a bunch xnox RAOF
<RAOF> Enjoy!
<RAOF> Yay! Lots of green SRUs available for release!
-queuebot:#ubuntu-release- New binary: qgis [armhf] (artful-proposed/universe) [2.14.18+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: lxd (xenial-proposed/main) [2.16-0ubuntu2~ubuntu16.04.1 => 2.0.10-0ubuntu1~16.04.2] (edubuntu, ubuntu-server)
<stgraber> ^ this one should be pretty easy to review and will fix a very annoying bug in image management for LXD 2.0.10
<stgraber> (also queuebot is confused by backports, it's actually 2.0.10-0ubuntu1~16.04.1 => 2.0.10-0ubuntu1~16.04.2)
-queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-proposed) [2.0.10-0ubuntu1~16.04.2]
<RAOF> stgraber: Enjoy.
<stgraber> RAOF: thanks!
<Laney> xnox: what are you asking for?
<acheronuk> morning. is the reason for not being a valid candidate here the bileto "Grouped with PPA ~ci-train-ppa-service/+archive/ubuntu/2819" part?
<acheronuk> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src
<fossfreedom_> any archive admins around? any chance that gir1.2-budgie-desktop-1.0 in artful proposed can be deleted - its preventing (according to excuses) budgie-desktop 10.4 from migrating.
<apw>  fossfreedom_ ahh nbs in -proposed, will sort that out
<fossfreedom_> cheers
<fossfreedom_> what does "nbs" mean?
<apw> Not-Built-from-Source
<acheronuk> could  pim-storage-service-manager/4:16.12.3-0ubuntu1 be deleted from artful release please? or if not, it's tests ignored? it has been removed/obsoleted from KDE applications 17.04 onwards
<apw> so a package you had in the previous version that you no longer have
<acheronuk> https://community.kde.org/Applications/17.04_Release_Notes
<acheronuk> Tarballs that we do not ship anymore: pim-storage-service-manager
<fossfreedom_> apw - thanks for the info.  jeremy uploaded a new version of ubuntu-budgie-meta - is it "nbs" the reason why it again hasn't migrated - something above s390x build in a previous ubuntu-budgie-meta version according to excuses.
<apw> fossfreedom_, yeah that is what is it saying ... that s390x used to build and had not, so it is broke
<apw> fossfreedom_, though it would then have the same problem with -release
<apw> fossfreedom, hopefully that is all sorted out
<fossfreedom> :)
<acheronuk> bug #1712525
<ubot5> bug 1712525 in pim-storage-service-manager (Ubuntu) "Please remove pim-storage-service-manager from artful" [Undecided,New] https://launchpad.net/bugs/1712525
-queuebot:#ubuntu-release- New: accepted node-regenerator-transform [amd64] (artful-proposed) [0.9.8-1]
-queuebot:#ubuntu-release- New: accepted qgis [arm64] (artful-proposed) [2.14.18+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [i386] (artful-proposed) [2.14.18+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [s390x] (artful-proposed) [2.14.18+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [amd64] (artful-proposed) [2.14.18+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [ppc64el] (artful-proposed) [2.14.18+dfsg-1]
-queuebot:#ubuntu-release- New: accepted qgis [armhf] (artful-proposed) [2.14.18+dfsg-1]
-queuebot:#ubuntu-release- New binary: binutils [s390x] (artful-proposed/main) [2.29-6ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: binutils [ppc64el] (artful-proposed/main) [2.29-6ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: binutils [armhf] (artful-proposed/main) [2.29-6ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: farbfeld [ppc64el] (artful-proposed/universe) [3-4] (no packageset)
-queuebot:#ubuntu-release- New binary: farbfeld [amd64] (artful-proposed/universe) [3-4] (no packageset)
-queuebot:#ubuntu-release- New binary: farbfeld [i386] (artful-proposed/universe) [3-4] (no packageset)
-queuebot:#ubuntu-release- New binary: farbfeld [armhf] (artful-proposed/universe) [3-4] (no packageset)
-queuebot:#ubuntu-release- New binary: farbfeld [arm64] (artful-proposed/universe) [3-4] (no packageset)
-queuebot:#ubuntu-release- New binary: farbfeld [s390x] (artful-proposed/universe) [3-4] (no packageset)
-queuebot:#ubuntu-release- New binary: binutils [arm64] (artful-proposed/main) [2.29-6ubuntu1] (core)
-queuebot:#ubuntu-release- New: accepted farbfeld [amd64] (artful-proposed) [3-4]
-queuebot:#ubuntu-release- New: accepted farbfeld [armhf] (artful-proposed) [3-4]
-queuebot:#ubuntu-release- New: accepted farbfeld [ppc64el] (artful-proposed) [3-4]
-queuebot:#ubuntu-release- New: accepted farbfeld [arm64] (artful-proposed) [3-4]
-queuebot:#ubuntu-release- New: accepted farbfeld [s390x] (artful-proposed) [3-4]
-queuebot:#ubuntu-release- New: accepted farbfeld [i386] (artful-proposed) [3-4]
-queuebot:#ubuntu-release- Unapproved: accepted nut [source] (xenial-proposed) [2.7.2-4ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted nut [source] (trusty-proposed) [2.7.1-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted nut [source] (zesty-proposed) [2.7.4-5ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (xenial-proposed) [1:8.0-0ubuntu3.4]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [0.7.9-233-ge586fe35-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (zesty-proposed) [0.7.9-233-ge586fe35-0ubuntu1~17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted backuppc [source] (xenial-proposed) [3.3.1-2ubuntu3.3]
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (xenial-proposed) [1.3.1-1ubuntu10.14]
-queuebot:#ubuntu-release- Unapproved: gcc-5 (xenial-proposed/main) [5.4.0-6ubuntu1~16.04.4 => 5.4.0-6ubuntu1~16.04.5] (core)
-queuebot:#ubuntu-release- Unapproved: accepted binutils [source] (xenial-proposed) [2.26.1-1ubuntu1~16.04.5]
<cpaelzer> thanks for approving libvirt whoever is active on SRU atm
<cpaelzer> that jeeps it in sync with zesty
<cpaelzer> "keeps" even
-queuebot:#ubuntu-release- Unapproved: rejected python3.5 [source] (xenial-proposed) [3.5.2-2ubuntu0~16.04.2]
-queuebot:#ubuntu-release- Unapproved: python3.5 (xenial-proposed/main) [3.5.2-2ubuntu0~16.04.1 => 3.5.2-2ubuntu0~16.04.2] (core)
-queuebot:#ubuntu-release- New binary: binutils [amd64] (artful-proposed/main) [2.29-6ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: binutils [i386] (artful-proposed/main) [2.29-6ubuntu1] (core)
-queuebot:#ubuntu-release- New: accepted binutils [amd64] (artful-proposed) [2.29-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted binutils [armhf] (artful-proposed) [2.29-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted binutils [ppc64el] (artful-proposed) [2.29-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted binutils [arm64] (artful-proposed) [2.29-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted binutils [s390x] (artful-proposed) [2.29-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted binutils [i386] (artful-proposed) [2.29-6ubuntu1]
<xnox> slangasek, xdelta3 needs promotion to main, used to be in main in xenial as a build-dep http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#lxd
<xnox> https://launchpad.net/ubuntu/+source/xdelta3
<doko> xnox: already done
<xnox> whoop
<xnox> rmadison still has it at artful/universe though :-(
 * xnox twiddles thumbs, goes to do something else
-queuebot:#ubuntu-release- New binary: odil [ppc64el] (artful-proposed/universe) [0.8.0-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: odil [s390x] (artful-proposed/universe) [0.8.0-3ubuntu1] (no packageset)
<acheronuk> hi
<acheronuk> slangasek: I have some more tests against s390x and ppc64el that really should never have run
<acheronuk> (I did not trigger them :P)
<acheronuk> akonadi-calendar/4:17.04.3-0ubuntu1
<acheronuk> libkf5gravatar/4:17.04.3-0ubuntu1
<acheronuk> libkf5mailimporter/4:17.04.3-0ubuntu1
<acheronuk> kdepim-addons/17.04.3-0ubuntu1
<acheronuk> kdepim-addons/16.12.3-0ubuntu1
<acheronuk> can those please be ignored like the others please
-queuebot:#ubuntu-release- New binary: odil [amd64] (artful-proposed/universe) [0.8.0-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: samba (zesty-proposed/main) [2:4.5.8+dfsg-0ubuntu0.17.04.5 => 2:4.5.8+dfsg-0ubuntu0.17.04.6] (core)
-queuebot:#ubuntu-release- New binary: odil [i386] (artful-proposed/universe) [0.8.0-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: samba (xenial-proposed/main) [2:4.3.11+dfsg-0ubuntu0.16.04.9 => 2:4.3.11+dfsg-0ubuntu0.16.04.10] (core)
-queuebot:#ubuntu-release- New binary: odil [armhf] (artful-proposed/universe) [0.8.0-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: odil [arm64] (artful-proposed/universe) [0.8.0-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: samba (trusty-proposed/main) [2:4.3.11+dfsg-0ubuntu0.14.04.10 => 2:4.3.11+dfsg-0ubuntu0.14.04.11] (core)
<slangasek> acheronuk: interesting, the timing of those tests does in fact suggest it's still britney triggering them for some reason
<acheronuk> slangasek: indeed. it is odd
<slangasek> acheronuk: adding hints; btw the version numbers aren't needed here, the hints I add are 'force-badtest akonadi-calendar/all/ppc64el akonadi-calendar/all/s390x'
<acheronuk> slangasek: yes, I realise but forgot and just pasted what I had from my parsing of excuses
<slangasek> acheronuk: anything else that you think I should look at today wrt the Qt+KDE transition?
<slangasek> I don't want to step on your toes or duplicate autopkgtest retries
<acheronuk> not really related, but latest plasm is failing many builds with:
<acheronuk> The following packages have unmet dependencies:
<acheronuk>  sbuild-build-depends-core-dummy : Depends: build-essential but it is not going to be installed
<acheronuk> E: Unable to correct problems, you have held broken packages.
<didrocks> same with others like gnome-boxes on i386
<acheronuk> amd64 seems ok. but other architectures are getting that error
<tkamppeter> Can it be that the proposed-migration process for Artful is down? I have uploaded qpdf and cups-filters and on http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_excuses.html they are both a "Valid candidate" already since yesterday and they still did not arrive in the Artful release.
<acheronuk> e.g: https://launchpad.net/ubuntu/+archive/primary/+sourcepub/8197998/+listing-archive-extra
<acheronuk> build-essential can't be installed on anything but amd64?
<slashd> rbasak, are you around ?
<slangasek> acheronuk: can you give me a pointer to a specific build failure with that?
<acheronuk> https://launchpad.net/ubuntu/+archive/primary/+sourcepub/8197998/+listing-archive-extra
<slangasek> tkamppeter: "valid candidate" only means that there is nothing that prevents this package from being considered for migration.  The system still needs to calculate a coherent set of packages that migrate together without making anything uninstallable.
<acheronuk> https://launchpad.net/ubuntu/+archive/primary/+sourcepub/8198003/+listing-archive-extra
<acheronuk> https://launchpad.net/ubuntu/+archive/primary/+sourcepub/8198008/+listing-archive-extra
<acheronuk> and on......
<acheronuk> slangasek: and as mentioned https://launchpad.net/ubuntu/+source/gnome-boxes/3.25.91-0ubuntu1
<tkamppeter> slangasek, thanks. So due to some complex relationships between packages the whole process is still stuck?
<slangasek> tkamppeter: the relationships are not particularly complex; poppler and qpdf both have new sonames, which means their reverse-dependencies all need to be rebuilt and ready to migrate together
<slangasek> tkamppeter: and since poppler builds qt bits, this all waits for Qt5.9 now
<slangasek> acheronuk: ok, digging into this
<slangasek> doko: do you know that you broke binutils on !amd64?
<acheronuk> slangasek: thanks. apologies but I have to go for a few hrs. I may be able to answer your original question then
<slangasek> doko: I'm removing from -proposed to unblock the world
<doko> slangasek: ack. I only tested amd64 :-/
<slangasek> doko for reference, if you haven't already seen: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#binutils
<doko> ouch
<xnox> slangasek, http://autopkgtest.ubuntu.com/packages/s/stenographer/artful/ppc64el stenographer has regressed in release pocket on ppc64el, probably some dep sneaked in.
<xnox> slangasek, can you bad test that version specifically on ppc64el? stenographer/0.0~git20161206.0.66a8e7e-5 it is in release pocket, and running the test in release pcoket alone fails.
<xnox> this is currently blocking rsyslog migration
<xnox> https://bugs.launchpad.net/ubuntu/+source/stenographer/+bug/1712573
<ubot5> Ubuntu bug 1712573 in stenographer (Ubuntu) "stenographer has regressed in artful-release on ppc64el" [Undecided,New]
<slangasek> xnox: hinted, thanks
-queuebot:#ubuntu-release- New: accepted odil [amd64] (artful-proposed) [0.8.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted odil [armhf] (artful-proposed) [0.8.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted odil [ppc64el] (artful-proposed) [0.8.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted odil [arm64] (artful-proposed) [0.8.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted odil [s390x] (artful-proposed) [0.8.0-3ubuntu1]
-queuebot:#ubuntu-release- New: accepted odil [i386] (artful-proposed) [0.8.0-3ubuntu1]
-queuebot:#ubuntu-release- New binary: console-setup [amd64] (artful-proposed/main) [1.166ubuntu1] (core)
<slangasek> so why was this qt5.9 transition ppa published to -proposed with packages ftbfs? (gammaray/s390x)
-queuebot:#ubuntu-release- New binary: binutils [s390x] (artful-proposed/main) [2.29-6ubuntu2] (core)
<slangasek> xnox: do you care about the (reproducible) gammaray/s390x ftbfs?
-queuebot:#ubuntu-release- New binary: binutils [ppc64el] (artful-proposed/main) [2.29-6ubuntu2] (core)
<LocutusOfBorg> slangasek, actually we think we should just remove gammaray on s390x, because 1) it is rc buggy in debian too 2) it is a leaf package that shouldn't hold the transition
<LocutusOfBorg> I think tsimonq2 has an open bug about that removal
<slangasek> LocutusOfBorg: done; I found no open bug
<LocutusOfBorg> you removed it? thanks!
<slangasek> yeah, removed
<LocutusOfBorg> we want to bring qt in a close state with the Debian one, and gammaray has been source of sadness for toooooo long time :)
<LocutusOfBorg> I'm pretty sure it doesn't even start correctly, if we have this bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864825
<ubot5> Debian bug 864825 in gammaray "gammaray: crashes target program on attach" [Grave,Open]
-queuebot:#ubuntu-release- New source: xfce4-statusnotifier-plugin (artful-proposed/primary) [0.1.0-0ubuntu1]
<LocutusOfBorg> slangasek, qtbase is not listed as candidate for migration, but I don't see any more failed test... is that the silo grouped stuff?
-queuebot:#ubuntu-release- New binary: binutils [armhf] (artful-proposed/main) [2.29-6ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: hfst [ppc64el] (artful-proposed/universe) [3.12.2~r3289-1] (no packageset)
<slangasek> LocutusOfBorg: it looked like the gammaray ftbfs was blocking the group from being considered, yes. I'm not sure how confused britney is now by the fact that gammaray was copied from the ppa, but I retried the s390x build in the main archive... update_excuses no longer lists gammaray as grouped but the packages are still not considered
<LocutusOfBorg> but arent k* packages blockers for this transition?
<LocutusOfBorg> I was wondering about some kde+qt entanglement
<LocutusOfBorg> it is considered now!!!
<slangasek> KDE should only get entangled if there are library transitions; I don't know whether there are any for Qt5.9
<LocutusOfBorg> they are according to britney
<slangasek> entangled != blocked on
<slangasek> a versioned dep will mean qt5.9 has to migrate first before kde; only a lib transition will mean that kde has to migrate together with qt5.9
<LocutusOfBorg> sure
<LocutusOfBorg> Depends: calibre pyqt5 (not considered)
<LocutusOfBorg> but seems considered pyqt5...
<LocutusOfBorg> britney, how sad are you
<LocutusOfBorg> or maybe we can just wait half an hour
<LocutusOfBorg> slangasek, old binaries left on amd64: libmarblewidget-qt5-26 (from 4:16.12.3-0ubuntu2)
<LocutusOfBorg> NBS in proposed
-queuebot:#ubuntu-release- New binary: hfst [amd64] (artful-proposed/universe) [3.12.2~r3289-1] (no packageset)
-queuebot:#ubuntu-release- New binary: hfst [i386] (artful-proposed/universe) [3.12.2~r3289-1] (no packageset)
-queuebot:#ubuntu-release- New binary: binutils [arm64] (artful-proposed/main) [2.29-6ubuntu2] (core)
<slangasek> LocutusOfBorg: cleaned up, thanks
-queuebot:#ubuntu-release- New: accepted hfst [amd64] (artful-proposed) [3.12.2~r3289-1]
-queuebot:#ubuntu-release- New: accepted hfst [ppc64el] (artful-proposed) [3.12.2~r3289-1]
-queuebot:#ubuntu-release- New: accepted hfst [i386] (artful-proposed) [3.12.2~r3289-1]
<LocutusOfBorg> ta
<LocutusOfBorg> sigh, again not considered
<LocutusOfBorg> better wait
<slangasek> a few things are candidates now.  and yes, kde is entangled.
<slangasek> pim-storage-service-manager test failures will need sorting
<slangasek> kcalutils doesn't look pretty
<slangasek> pim-storage-service-manager is broken because /usr/share/ECM/kde-modules/KDECompilerSettings.cmake has wrong detection of 64-bit off_t
<slangasek> xnox: why does new systemd make openssh autopkgtest time out?
<slangasek> hmm, that off_t stuff may be a red herring
<nacc> sbeattie: so i noticed something odd with the importer just now. It seems that `git branch -M` with the new git in 17.10 causes the new branch name to be checked out. THat wasn't the case before. And leads to changes in the working directory (it's not properly checked out as far as I can tell, but your old working tree is forcibly made the new branch's state -- all sorts of wrong). I'm looking into
<nacc> the debdiff now, but do you know if that was intentional?
<slangasek> acheronuk: is pim-storage-service-manager getting an update for 17.04.3?  it doesn't seem to exist at all in Debian
<sbeattie> nacc: hrm, it wasn't intentional by me... my part of the merge was trying to pull in the point release that addressed CVE-2017-1000117
<nacc> sbeattie: yeah, it looks like an upstream change, but i think it might be buggy. will dig
<nacc> sbeattie: i'll report it upstream, i think it's a pretty obvious regression :/
<sbeattie> nacc: thanks and sorry for that. I dunno if xnox saw that in his uploads that mine superceded.
<nacc> sbeattie: definitely not your fault, i was just going off TIL :)
-queuebot:#ubuntu-release- Unapproved: nova (xenial-proposed/main) [2:13.1.4-0ubuntu2 => 2:13.1.4-0ubuntu3] (openstack, ubuntu-server)
<nacc> sbeattie: xnox: just an fyi, reported upstream -- this breaks the importer quite badly (we have an orphan master brannch, which apparently what is broken upstream).
-queuebot:#ubuntu-release- New binary: binutils [amd64] (artful-proposed/main) [2.29-6ubuntu2] (core)
-queuebot:#ubuntu-release- New binary: binutils [i386] (artful-proposed/main) [2.29-6ubuntu2] (core)
<slangasek> acheronuk: found your bug report which you filed about pim-storage-service-manager before I asked ;P
<xnox> slangasek, i do not know why yet. But it is very susspicious given that openssh by itself passes.
<xnox> slangasek, it's as if networkd eats entropy and hence rsa gen fails.
<slangasek> heh
<slangasek> mitya57: hmm, pyqt5 had already built against Qt5.9, but it needed further patches to properly support it?
-queuebot:#ubuntu-release- New: accepted binutils [amd64] (artful-proposed) [2.29-6ubuntu2]
-queuebot:#ubuntu-release- New: accepted binutils [armhf] (artful-proposed) [2.29-6ubuntu2]
-queuebot:#ubuntu-release- New: accepted binutils [ppc64el] (artful-proposed) [2.29-6ubuntu2]
-queuebot:#ubuntu-release- New: accepted binutils [arm64] (artful-proposed) [2.29-6ubuntu2]
-queuebot:#ubuntu-release- New: accepted binutils [s390x] (artful-proposed) [2.29-6ubuntu2]
-queuebot:#ubuntu-release- New: accepted binutils [i386] (artful-proposed) [2.29-6ubuntu2]
<doko> slangasek: if you would like to watch: ^^^ ;)
<slangasek> doko: I'll try to keep an eye out, thanks
-queuebot:#ubuntu-release- New: accepted console-setup [amd64] (artful-proposed) [1.166ubuntu1]
<LocutusOfBorg> slangasek, seems that the patches were the same, just added headers
<LocutusOfBorg> http://launchpadlibrarian.net/334344194/pyqt5_5.7+dfsg-5ubuntu1_5.7+dfsg-6.diff.gz
<LocutusOfBorg> and mipsel support
<slangasek> ah
<slangasek> so that wasn't an autosync
<LocutusOfBorg> a forcesync yes
<acheronuk> slangasek: aha. thanks for picking up that removal bug on pim-storage-service-manager. thought there was something, but it escaped me earlier
<slangasek> acheronuk: n/p
<slangasek> sadly, bugs are always the last place I look :P
<slangasek> kcalutils> I've retriggered all the autopkgtests
<acheronuk> slangasek: bu**er. I just did as well :(
<slangasek> heh
<slangasek> libkgapi, I guess needs ppc64el/s390x removals
<acheronuk> could do with a way of cancelling tests you triggered in cases like that where duplication is caused by a collision of good intentions
<acheronuk> slangasek: yep. it started requiring QtWebEngine as well. so can only build on arches where that builds
<doko> slangasek: I removed the binary packages again. but I think they will be published for one cycle
<doko> I fixed the issue for binutils-for-host, but not for binutils itself
<slangasek> heh, k
<doko> new ones are building
<LocutusOfBorg> sigh, lots of s390x sadness due to build-essential not installable
-queuebot:#ubuntu-release- New binary: binutils [ppc64el] (artful-proposed/main) [2.29-6ubuntu3] (core)
<valorie> possibly silly question, but is there any idea of when Qt5.9 will be released for artful, and thus our Kpackages can also get through?
 * valorie is the release manager for Kubuntu and I'd like to know whether we should bother with beta1 or not
<valorie> without most of our new stuff, there seems little point
<doko> LocutusOfBorg: these need give-backs. naming the packages would help
-queuebot:#ubuntu-release- New binary: binutils [armhf] (artful-proposed/main) [2.29-6ubuntu3] (core)
-queuebot:#ubuntu-release- New binary: binutils [arm64] (artful-proposed/main) [2.29-6ubuntu3] (core)
<LocutusOfBorg> doko, I already have a list and a sleep with a retry ready
<LocutusOfBorg> sleep 3600 && ubuntu-build --batch --retry nss  hfst mediawiki2latex sunpy s390-tools console-setup kdeplasma-addons  khotkeys kmenuedit oxygen plasma-desktop plasma-workspace powerdevil pcb-rnd gnuplot 389-ds-base libosmium net-snmp
<LocutusOfBorg> this is the list :)
<LocutusOfBorg> but as said, already pending
 * LocutusOfBorg goes to sleep
<nacc> LocutusOfBorg: thanks for the net-snmp catch
<nacc> ahasenack: --^
<ahasenack> tl;dr?
<nacc> ahasenack: LocutusOfBorg will retrigger the build once build-essential gets through
<ahasenack> build-essential
<ahasenack> ops
<ahasenack> that was meant for a search box
-queuebot:#ubuntu-release- New binary: soapyremote [ppc64el] (artful-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jimtcl [amd64] (artful-proposed/universe) [0.77-1] (no packageset)
-queuebot:#ubuntu-release- New binary: soapyosmo [ppc64el] (artful-proposed/universe) [0.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jimtcl [ppc64el] (artful-proposed/universe) [0.77-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jimtcl [i386] (artful-proposed/universe) [0.77-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jimtcl [s390x] (artful-proposed/universe) [0.77-1] (no packageset)
-queuebot:#ubuntu-release- New binary: commando [amd64] (artful-proposed/universe) [1.0.0-0.2] (no packageset)
-queuebot:#ubuntu-release- New binary: limesuite [ppc64el] (artful-proposed/universe) [17.06.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: limesuite [amd64] (artful-proposed/universe) [17.06.0+dfsg-1] (no packageset)
<LocutusOfBorg> they should be in place now
-queuebot:#ubuntu-release- New binary: limesuite [i386] (artful-proposed/universe) [17.06.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jimtcl [arm64] (artful-proposed/universe) [0.77-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ros-rosdep [amd64] (artful-proposed/universe) [0.11.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: soapyosmo [i386] (artful-proposed/universe) [0.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: jimtcl [armhf] (artful-proposed/universe) [0.77-1] (no packageset)
-queuebot:#ubuntu-release- New binary: soapyremote [amd64] (artful-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: soapyosmo [amd64] (artful-proposed/universe) [0.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: limesuite [s390x] (artful-proposed/universe) [17.06.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: soapyremote [i386] (artful-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-pathval [amd64] (artful-proposed/none) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-check-error [amd64] (artful-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-syntax-error [amd64] (artful-proposed/universe) [1.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-subarg [amd64] (artful-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: soapyosmo [s390x] (artful-proposed/universe) [0.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: soapyremote [s390x] (artful-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-acorn-jsx [amd64] (artful-proposed/universe) [4.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-shell-quote [amd64] (artful-proposed/universe) [1.6.1+20160617-git72fb5a8ce29b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: limesuite [armhf] (artful-proposed/universe) [17.06.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: soapyosmo [arm64] (artful-proposed/universe) [0.2.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: soapyremote [armhf] (artful-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: soapyremote [arm64] (artful-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: limesuite [arm64] (artful-proposed/universe) [17.06.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: soapyosmo [armhf] (artful-proposed/universe) [0.2.5-1] (no packageset)
<xnox> not my idea uploading partial upload
<xnox> three times
#ubuntu-release 2017-08-24
-queuebot:#ubuntu-release- New binary: binutils [i386] (artful-proposed/main) [2.29-6ubuntu3] (core)
-queuebot:#ubuntu-release- New: accepted soapyosmo [arm64] (artful-proposed) [0.2.5-1]
-queuebot:#ubuntu-release- New: accepted soapyosmo [s390x] (artful-proposed) [0.2.5-1]
-queuebot:#ubuntu-release- New: accepted soapyremote [armhf] (artful-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New binary: binutils [amd64] (artful-proposed/main) [2.29-6ubuntu3] (core)
-queuebot:#ubuntu-release- New: accepted soapyosmo [armhf] (artful-proposed) [0.2.5-1]
-queuebot:#ubuntu-release- New: accepted soapyremote [s390x] (artful-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted soapyremote [arm64] (artful-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted limesuite [amd64] (artful-proposed) [17.06.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted limesuite [armhf] (artful-proposed) [17.06.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted limesuite [ppc64el] (artful-proposed) [17.06.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted limesuite [arm64] (artful-proposed) [17.06.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted limesuite [s390x] (artful-proposed) [17.06.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted limesuite [i386] (artful-proposed) [17.06.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted soapyosmo [amd64] (artful-proposed) [0.2.5-1]
-queuebot:#ubuntu-release- New: accepted soapyosmo [i386] (artful-proposed) [0.2.5-1]
-queuebot:#ubuntu-release- New: accepted node-acorn-jsx [amd64] (artful-proposed) [4.0.1-1]
-queuebot:#ubuntu-release- New: accepted node-pathval [amd64] (artful-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted node-subarg [amd64] (artful-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted soapyosmo [ppc64el] (artful-proposed) [0.2.5-1]
-queuebot:#ubuntu-release- New: accepted node-check-error [amd64] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted node-syntax-error [amd64] (artful-proposed) [1.3.0-1]
-queuebot:#ubuntu-release- New: accepted node-shell-quote [amd64] (artful-proposed) [1.6.1+20160617-git72fb5a8ce29b-1]
-queuebot:#ubuntu-release- New: accepted soapyremote [i386] (artful-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted jimtcl [amd64] (artful-proposed) [0.77-1]
-queuebot:#ubuntu-release- New: accepted jimtcl [armhf] (artful-proposed) [0.77-1]
-queuebot:#ubuntu-release- New: accepted jimtcl [ppc64el] (artful-proposed) [0.77-1]
-queuebot:#ubuntu-release- New: accepted soapyremote [amd64] (artful-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted jimtcl [arm64] (artful-proposed) [0.77-1]
-queuebot:#ubuntu-release- New: accepted jimtcl [s390x] (artful-proposed) [0.77-1]
-queuebot:#ubuntu-release- New: accepted jimtcl [i386] (artful-proposed) [0.77-1]
-queuebot:#ubuntu-release- New: accepted soapyremote [ppc64el] (artful-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New: accepted commando [amd64] (artful-proposed) [1.0.0-0.2]
-queuebot:#ubuntu-release- New: accepted ros-rosdep [amd64] (artful-proposed) [0.11.8-1]
-queuebot:#ubuntu-release- New: accepted binutils [amd64] (artful-proposed) [2.29-6ubuntu3]
-queuebot:#ubuntu-release- New: accepted binutils [armhf] (artful-proposed) [2.29-6ubuntu3]
-queuebot:#ubuntu-release- New: accepted binutils [ppc64el] (artful-proposed) [2.29-6ubuntu3]
-queuebot:#ubuntu-release- New: accepted binutils [arm64] (artful-proposed) [2.29-6ubuntu3]
-queuebot:#ubuntu-release- New: accepted binutils [i386] (artful-proposed) [2.29-6ubuntu3]
-queuebot:#ubuntu-release- Unapproved: gnome-software (xenial-proposed/main) [3.20.5-0ubuntu0.16.04.5 => 3.20.5-0ubuntu0.16.04.6] (ubuntu-desktop)
<xnox> cyphermox, slangasek: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#console-setup do we need to hin console-setup-freebsd over? or do we need not to build it at all?
<cyphermox> xnox: I'm removing it
-queuebot:#ubuntu-release- Unapproved: gnome-software (zesty-proposed/main) [3.22.7-0ubuntu3.17.04.6 => 3.22.7-0ubuntu3.17.04.7] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: oysttyer [amd64] (artful-proposed/multiverse) [2.9.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-cliapp [amd64] (artful-proposed/universe) [1.20170823-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.27.3~14.04 => 2.27.4~14.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.27.3+17.04 => 2.27.4+17.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.27.3 => 2.27.4] (desktop-core, ubuntu-server)
<LocutusOfBorg> doko, missing build on s390x: binutils, binutils-dev, binutils-multiarch, binutils-multiarch-dev (from 2.29-5ubuntu1)
<LocutusOfBorg> slangasek, ^^^ NBS in proposed?
<LocutusOfBorg> slangasek, can we please move to proposed kmymoney for qt to go a little bit further? rationale: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871373
<ubot5> Debian bug 871373 in src:kmymoney "kmymoney: FTBFS: CMakeFiles/Makefile2:4181: recipe for target 'kmymoney/dialogs/settings/CMakeFiles/settings_autogen.dir/all' failed" [Serious,Open]
<xnox> apw, Could you please NBS clean in proposed console-setup-freebsd ?
<xnox> doko, looking at https://launchpad.net/ubuntu/artful/s390x/binutils was the right s390x version got deleted? i thought ...3 was good?
<xnox> doko, or on #ubuntu-devel >_<
<xnox> slangasek, due to bug 1712831 can openvswitch be bad-tested on i386 only?
<ubot5> bug 1712831 in linux (Ubuntu) "4.12.0-11-generic - crashing in infrastructure on i386 openvswitch tests" [Undecided,New] https://launchpad.net/bugs/1712831
<xnox> such that e.g. kmod can migrate
<xnox> cpaelzer, ^^^
 * cpaelzer reading
<cpaelzer> thanks for the ping xnox
<cpaelzer> yeah might be a good temporary workaround, yet we have to make sure it is not forgotten and becomes permanent
<doko> xnox: I'm upload one more. maybe the removal command was run too late?
<cjwatson> doko: you don't need to reupload
<cjwatson> doko: FWIW when removing it's a good idea to specify a version
<cjwatson> doko: but if you haven't uploaded already, we can just copy it back in
<doko> ok, that would be good
<cjwatson> I will do so
<doko> ta
<cjwatson> done
<cyphermox> could someone please let console-setup through? that console-setup-freebsd removal was missing from the merge (my bad), removed again
<cyphermox> it's currently blocked in excuses because consoel-setup-freebsd is missing
<acheronuk> slangasek: now I've had a proper look, I can see 2 more packages that need their old s390x and ppc64 binaries deleted as the new qtwebengine requirement makes them unbuildable there
<acheronuk> kalgebra & ktp-text-ui
<acheronuk> I *think* that is the last of them
-queuebot:#ubuntu-release- Unapproved: tor (zesty-proposed/universe) [0.2.9.10-1ubuntu1 => 0.2.9.11-1ubuntu1] (no packageset)
<doko> and just promoted binutils-s390x-linux-gnu ...
-queuebot:#ubuntu-release- New binary: util-linux [ppc64el] (artful-proposed/main) [2.30.1-0ubuntu4] (core)
-queuebot:#ubuntu-release- New binary: util-linux [s390x] (artful-proposed/main) [2.30.1-0ubuntu4] (core)
-queuebot:#ubuntu-release- New binary: util-linux [arm64] (artful-proposed/main) [2.30.1-0ubuntu4] (core)
-queuebot:#ubuntu-release- New binary: util-linux [i386] (artful-proposed/main) [2.30.1-0ubuntu4] (core)
-queuebot:#ubuntu-release- New binary: util-linux [armhf] (artful-proposed/main) [2.30.1-0ubuntu4] (core)
<doko> should qtubuntu be promoted again?
-queuebot:#ubuntu-release- Unapproved: rejected tor [source] (zesty-proposed) [0.2.9.11-1ubuntu1]
-queuebot:#ubuntu-release- New binary: util-linux [amd64] (artful-proposed/main) [2.30.1-0ubuntu4] (core)
<doko> seeded by supported-kiosk
-queuebot:#ubuntu-release- Unapproved: tor (zesty-proposed/universe) [0.2.9.10-1ubuntu1 => 0.2.9.11-1ubuntu1] (no packageset)
<slangasek> doko: I'm aware of no reason not to re-promote it
-queuebot:#ubuntu-release- New: accepted util-linux [amd64] (artful-proposed) [2.30.1-0ubuntu4]
-queuebot:#ubuntu-release- New: accepted util-linux [armhf] (artful-proposed) [2.30.1-0ubuntu4]
-queuebot:#ubuntu-release- New: accepted util-linux [ppc64el] (artful-proposed) [2.30.1-0ubuntu4]
-queuebot:#ubuntu-release- New: accepted util-linux [arm64] (artful-proposed) [2.30.1-0ubuntu4]
-queuebot:#ubuntu-release- New: accepted util-linux [s390x] (artful-proposed) [2.30.1-0ubuntu4]
-queuebot:#ubuntu-release- New: accepted util-linux [i386] (artful-proposed) [2.30.1-0ubuntu4]
<doko> ok, thenI'm doing it
-queuebot:#ubuntu-release- New: accepted oysttyer [amd64] (artful-proposed) [2.9.1-1]
-queuebot:#ubuntu-release- New: accepted python-cliapp [amd64] (artful-proposed) [1.20170823-1]
-queuebot:#ubuntu-release- Unapproved: accepted tor [source] (zesty-proposed) [0.2.9.11-1ubuntu1]
<slangasek> xnox: for a bug like that I'd rather skiptest openvswitch than bad-test it.  This is dpdk?
<xnox> slangasek, sorry I'm not familiar with skiptest/badtest semantics difference. Whatever is appropriate. What I'm tyring to fix is these two cases:
<xnox> dpdk triggers openswitch which fails on i386
<xnox> kmod triggers openvswithc which fails on i386
<rbasak> Mini FFe request: ahasenack has been working on a squid3 merge but held up by a gcc7 related FTBFS. He's almost ready for sponsorship and upload. The merge would only include one very minor functional change: https://anonscm.debian.org/git/pkg-squid/pkg-squid3.git/commit/?id=710982a8fb26a4a949f48812847cc13b1c17a3ca
<rbasak> But we don't think we'll manage the upload today.
<rbasak> Could a release team member please ack this to upload if within the next week or so?
<rbasak> All other changes that would land are bugfixes.
<rbasak> So this is really a technicality IMHO, but one that requires ~ubuntu-release to ack.
<rbasak> All other changes coming from Debian are at: https://anonscm.debian.org/git/pkg-squid/pkg-squid3.git/log/
<rbasak> From 3.5.23-1 through 3.5.23-5.
<cpaelzer> slangasek: it is openvswitch on i386 - dpdk/kmod are only triggers
<cpaelzer> ah I just see xnox mentioned that, but I wanted to answer fast before the worng one get's skipped
<slangasek> cpaelzer, xnox: http://autopkgtest.ubuntu.com/packages/o/openvswitch/artful/i386 shows it just succeeded
<cpaelzer> ja I hit retry often enough it seems :-/
<cpaelzer> god for me but bad enough for the case, as I've seen kmode retried like 6 times
<cpaelzer> +o
<cpaelzer> slangasek: well I hit retry once, but you see in http://autopkgtest.ubuntu.com/packages/o/openvswitch/artful/i386 what I mean
<slangasek> yes
<xnox> win =)
 * xnox retries harder?!
<slangasek> acheronuk: {kalgebra,ktp-text-ui}/{ppc64el,s390x} removals done
-queuebot:#ubuntu-release- Unapproved: nut (xenial-proposed/main) [2.7.2-4ubuntu1.1 => 2.7.2-4ubuntu1.2] (ubuntu-server)
-queuebot:#ubuntu-release- New binary: audacious [amd64] (artful-proposed/universe) [3.9-1~build1] (lubuntu)
 * ahasenack -> lunch, will read backlog when back
<acheronuk> slangasek: thank you
-queuebot:#ubuntu-release- New binary: audacious [s390x] (artful-proposed/universe) [3.9-1~build1] (lubuntu)
<slangasek> xnox: per email I believe content-hub is to be removed, but I don't see a removal bug for it - can you open one?
<Laney> can someone demote fwupd-tests maybe? component-mismatch but I don't see any reason that it has to be in main.
<Laney> (artful-proposed)
<slangasek> Laney: done
<Laney> thx
<slangasek> (that was probably just binary-follows-source defaulting for a new package)
<Laney> nod, I guessed that was probably it
-queuebot:#ubuntu-release- Unapproved: update-manager (zesty-proposed/main) [1:17.04.6 => 1:17.04.7] (core)
-queuebot:#ubuntu-release- New binary: vala [ppc64el] (artful-proposed/universe) [0.37.90-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [i386] (artful-proposed/universe) [0.37.90-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [amd64] (artful-proposed/universe) [0.37.90-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [s390x] (artful-proposed/universe) [0.37.90-0ubuntu1] (ubuntu-desktop)
<slangasek> qtubuntu uploaded to drop content-hub support
-queuebot:#ubuntu-release- New binary: vala [armhf] (artful-proposed/universe) [0.37.90-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libblockdev [ppc64el] (artful-proposed/universe) [2.11-2] (no packageset)
<slangasek> xnox: ignore previous request, I'm filing the bug
-queuebot:#ubuntu-release- New binary: libblockdev [i386] (artful-proposed/universe) [2.11-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libblockdev [amd64] (artful-proposed/universe) [2.11-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libblockdev [arm64] (artful-proposed/universe) [2.11-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libblockdev [armhf] (artful-proposed/universe) [2.11-2] (no packageset)
-queuebot:#ubuntu-release- New binary: vala [arm64] (artful-proposed/universe) [0.37.90-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted vala [amd64] (artful-proposed) [0.37.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted vala [armhf] (artful-proposed) [0.37.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted vala [ppc64el] (artful-proposed) [0.37.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted vala [arm64] (artful-proposed) [0.37.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted vala [s390x] (artful-proposed) [0.37.90-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted vala [i386] (artful-proposed) [0.37.90-0ubuntu1]
<tkamppeter> How does it work with the -proposed migration? Poppler and QPDF have new sonames, who does all the no-change rebuilds of the reverse-dependencies.
<tkamppeter> ?
<slangasek> hngh, removed webbrowser-app before its revdeps by mistake; hopefully readding means britney won't break artful by trading uninstallables
<slangasek> tkamppeter: some Ubuntu developer who is tracking proposed-migration does the rebuilds.  This is already done for both of those libraries
<tkamppeter> OK, then these two libs (and so also cups-filters) will pass into the release soon?
<tkamppeter> slangasek, or is there something else still blocking them?
<slangasek> tkamppeter: Qt5.9, which I believe I mentioned the other day
<tkamppeter> OK, and this will still need longer time?
<slangasek> yes
<slangasek> it's actively worked on
<tkamppeter> OK.
<slangasek> once again, I am left with doubts as to whether processing these removals is any faster than porting the code. :P
<mitya57> slangasek, I wonât mind if someone ported ubuntu-ui-toolkit, but that requires someone with deep code knowledge, as it heavily uses QML and QML Compiler internals for instance.
<mitya57> slangasek, So thanks for taking care of these removals!
<acheronuk> how did kalgebra 17.04.3 migrate? it depends libqt5core5a (>= 5.9.0~beta)
<slangasek> acheronuk: I don't see that it has migrated; did you get mail saying it did?
<nacc> it's in artful release per rmadison
<acheronuk> https://launchpad.net/ubuntu/+source/kalgebra/4:17.04.3-0ubuntu1
<slangasek> @yay
<acheronuk> Artful 	release 59 minutes ago
<slangasek> that one isn't my fault at least, that's before my webbrowser-app screw-up ;)
<acheronuk> weird
-queuebot:#ubuntu-release- Unapproved: accepted samba [source] (zesty-proposed) [2:4.5.8+dfsg-0ubuntu0.17.04.6]
-queuebot:#ubuntu-release- New: accepted libblockdev [amd64] (artful-proposed) [2.11-2]
-queuebot:#ubuntu-release- New: accepted libblockdev [armhf] (artful-proposed) [2.11-2]
-queuebot:#ubuntu-release- New: accepted libblockdev [ppc64el] (artful-proposed) [2.11-2]
-queuebot:#ubuntu-release- New: accepted libblockdev [arm64] (artful-proposed) [2.11-2]
-queuebot:#ubuntu-release- New: accepted libblockdev [i386] (artful-proposed) [2.11-2]
-queuebot:#ubuntu-release- Unapproved: accepted samba [source] (xenial-proposed) [2:4.3.11+dfsg-0ubuntu0.16.04.10]
-queuebot:#ubuntu-release- Unapproved: accepted samba [source] (trusty-proposed) [2:4.3.11+dfsg-0ubuntu0.14.04.11]
<slangasek> xnox: did you look at the ubuntu-app-launch dep chain? https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1711204/comments/17
<ubot5> Ubuntu bug 1711204 in checkbox (Ubuntu) "Remove ubuntu-ui-toolkit from the archive" [Undecided,In progress]
<doko> slangasek: for https://bugs.launchpad.net/ubuntu/+source/iprutils/+bug/1417608: which package should pull that into main?
<ubot5> Ubuntu bug 1417608 in iprutils (Ubuntu) "[MIR] ppc64-diag needed in minimal for hotplug capabilities" [High,New]
<slangasek> xnox: you mentioned you'd like content-hub to drop libubuntu-app-launch3-dev build-dep, but there are other revdeps
<slangasek> doko: it's already on component-mismatches
<slangasek> (lsvpd)
<xnox> slangasek, i was waiting for the next round of bugs filed by me to be processed first.... https://bugs.launchpad.net/ubuntu/+bugs?field.tag=u8rm
<doko> ahh, -proposed
<slangasek> xnox: well, I need a big picture view at this point of what's been signed off for removal, we don't have time to do these in rounds
-queuebot:#ubuntu-release- Unapproved: rejected proj [source] (xenial-proposed) [4.9.2-2ubuntu1.16.04.1]
<slangasek> ok, what package in the qt transition just got reuploaded and why?
<slangasek> (gsettings-qt)
<mitya57> slangasek, I noticed from update_output.txt that gsettings-qt still depends on qtbase-abi-5-7-1 and reuploaded it.
<slangasek> mitya57: ok.  will go do something else now while waiting for that to clear autopkgtests, thanks
<mitya57> slangasek, sorry for that, but not fixing it would be worse :)
<mitya57> basically the main thing to remove is still ubuntu-ui-toolkit, I can tell it without the britney logs.
-queuebot:#ubuntu-release- Unapproved: accepted lsvpd [source] (xenial-proposed) [1.7.6-0ubuntu4]
<mitya57> slangasek, re indicator-datetime -> ubuntu-app-launch -> libertine -> ubuntu-ui-toolkit chain, I want to break it at indicator-datetime point, which means the remaining three packages should go away.
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (xenial-proposed) [2:13.1.4-0ubuntu3]
<xnox> mitya57, slangasek - shouldn't gsettings-qt just be removed, since it's a touch thing?
<mitya57> xnox, I thought it was going away, and probably that was the reason I didn't include it in 2819 PPA.
<mitya57> But now it is fixed so can be removed later, there are still plenty other removals to do.
-queuebot:#ubuntu-release- Unapproved: powerpc-utils (zesty-proposed/main) [1.3.2-1ubuntu2~17.04 => 1.3.2-1ubuntu3~17.04] (core)
<slangasek> mitya57: in that case, note the other revdeps of ubuntu-app-launch still: url-dispatcher (I think the url-dispatcher upload only addressed u-ui-tk?), autopilot
<slangasek> maybe easier to make ubuntu-app-launch not use libertine?
<mitya57> slangasek, the problem is that I know nothing about ubuntu-app-launch or how to test it. (Which is not the case with indicator-datetime.)
<mitya57> slangasek, But I can try removing libubuntu-app-launch/app-store-libertine.cpp and seeing what happens.
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (zesty-proposed) [3.22.7-0ubuntu3.17.04.7]
<xnox> slangasek, i am working on making ubuntu-app-launch not use libertine
<slangasek> mitya57: ^^
<mitya57> xnox, great, thanks!
 * mitya57 guesses he can stop trying to update indicator-datetime then
<xnox> slangasek, it will may need to force tests through, since it is dropping features.
<xnox> url-dispatcher built
-queuebot:#ubuntu-release- New binary: audacious [amd64] (artful-proposed/universe) [3.9-1ubuntu2] (lubuntu)
<mitya57> xnox, I only just figured out that url-dispatcher is in main and qtquickcontrols-opensource-src is in universe
-queuebot:#ubuntu-release- New binary: audacious [i386] (artful-proposed/universe) [3.9-1ubuntu2] (lubuntu)
<xnox> mitya57, url-dispatcher should be in universe too
<mitya57> xnox, but it is used by all the indicators
<xnox> the only thing in main is:
<xnox> ubuntu-application-api3-desktop
<xnox> ubuntu-application-api3-touch
<xnox> mitya57, guess where all the indicators are...
-queuebot:#ubuntu-release- New binary: audacious [armhf] (artful-proposed/universe) [3.9-1ubuntu2] (lubuntu)
<xnox> $ reverse-depends -c main src:url-dispatcher
<xnox> Reverse-Depends
<xnox> ===============
<xnox> * ubuntu-application-api3-desktop  (for liburl-dispatcher1)
<xnox> * ubuntu-application-api3-touch  (for liburl-dispatcher1)
<xnox> Packages without architectures listed are reverse-dependencies in: amd64, arm64, armhf, i386
<mitya57> OK, liburl-dispatcher1 is not where I added the dependencies
<mitya57> Oh, the indicators themselves got demoted to universe. Nice.
<xnox> slangasek, mitya57 - my acceptance criteria here will be "indicator-datetime still works"
<slangasek> xnox: url-dispatcher? autopilot?
<xnox> for the ubuntu-app-launch upload
<slangasek> xnox: yes - I mean, url-dispatcher and autopilot are also revdeps; but you won't test them?
<xnox> url-dispatcher is in fact dead-weight, all it can do is launch unity8 stuff
<xnox> on unity7 desktop we do not go via url-dispatcher code paths; even if indicators link against it for the touch profile
<mitya57> As I understand libertine was need only for launching X11 apps on MIR. So if you removed only the relevant code paths, then the percent of breakage should be quite low.
<xnox> autopilot - we tore down all the touch infra that uses autopilot, no?
<xnox> mitya57, unittests are failing =/ but i may have dropped too much in the unittest cases
<mitya57> xnox, can you show me your diff?
<mitya57> (maybe push it to bzr?)
<slangasek> xnox: but url-dispatcher was on the to-keep list for mir, isn't that because of the kiosk seed, which is mir-based?
<xnox> http://paste.ubuntu.com/25384930/
<xnox> includes a quick gcc7 fix too
<mitya57> If the kiosk sees used any X11 apps then it will be broken.
<xnox> slangasek, no, url-dispatcher is to keep because indiators-* link against url-dispatcher, and therefore we either need to patch 7 indicators or keep url-dispatcher
<slangasek> ok
<mitya57> ...Otherwise if it uses Touch apps like webbrowser-app it will be broken too
-queuebot:#ubuntu-release- New binary: audacious [ppc64el] (artful-proposed/universe) [3.9-1ubuntu3] (lubuntu)
<xnox> slangasek, or we can upload 7 indicators that drop liburl-dispatcher1 code which may be quicker and cleaner
<xnox> but that would make out of the archive unity8 for ubports project harder
<slangasek> why would ubports use indicators from Ubuntu devel if they have to use Qt from elsewhere?
-queuebot:#ubuntu-release- New binary: audacious [amd64] (artful-proposed/universe) [3.9-1ubuntu3] (lubuntu)
<xnox> true
<mitya57> xnox, diff LGTM
-queuebot:#ubuntu-release- New binary: audacious [i386] (artful-proposed/universe) [3.9-1ubuntu3] (lubuntu)
-queuebot:#ubuntu-release- New binary: audacious [armhf] (artful-proposed/universe) [3.9-1ubuntu3] (lubuntu)
<mapreri> â that thing finally built everywhere, and you can process it from NEW :)
-queuebot:#ubuntu-release- New binary: audacious [s390x] (artful-proposed/universe) [3.9-1ubuntu3] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted postfix [source] (trusty-proposed) [2.11.0-1ubuntu1.2]
 * xnox opens indicator-bluetooth and i'm failing to see _where_ it uses url-dispatcher
-queuebot:#ubuntu-release- New binary: audacious [arm64] (artful-proposed/universe) [3.9-1ubuntu3] (lubuntu)
<xnox> found it.
<mitya57> xnox, indicator-bluetooth looks really easy to fix. Just remove phone.vala and one line that registers the profile. But other indicators like indicator-datetime are not so easy.
<xnox> mitya57, yeah did that.
<xnox> slangasek, alan_g promised me that qtubuntu-desktop will drop dependency on platform-api but it did not
<xnox> slangasek, platform-api declares /links against url-dispatcher and location-service
<xnox> slangasek, can you escalate what the status there is?
<xnox> slangasek, i think we need to remove qtubuntu-desktop from kiosk see and drop qtubuntu et.al.
<xnox> and reintroduce when that is fixed to not depend on the platform-api
<slangasek> xnox: platform-api wasn't on my radar at all for removal yet; if you're fixing url-dispatcher, why do we need to do anything for platform-api?
<slangasek> or did you change your mind on that approach?
<xnox> i didn't change minds
<xnox> i am just annoyed that kiosk did not drop dependencies they said they will drop
<xnox> platform-api is qt-not-blocking but touch-old-stuff-dead-weight
<mitya57> xnox, are you still fixing ubuntu-app-launch, or want to fix all the indicators now instead?
<xnox> https://launchpad.net/ubuntu/+source/ubuntu-app-launch/0.12+17.04.20170404.2-0ubuntu4
<mitya57> great
<xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#url-dispatcher
 * mitya57 hopes indicator-session's autopkgtest does not really test anything related to libertine
 * xnox is patching indicator-session to stop using url-dispatcher meanwhile
<tsimonq2> xnox: nice one (indicator-keyboard)
 * mitya57 wonders if just running ubuntu-app-launch test in dbus-run-session would fix them
<tsimonq2> o/ mitya57 et al :)
 * mitya57 waves to tsimonq2
<mitya57> xnox: indicator-session autopkgtest passes
<tsimonq2> Does it break Feature Freeze if the package update you want in the archive is still in NEW? (I would assume no, but I just want to check, because I really want that new audacious in)
<mitya57> tsimonq2, no if I remember correctly.
<tsimonq2> Ok.
<mitya57> https://wiki.ubuntu.com/FeatureFreeze âFor the purpose of the FeatureFreeze, the upload date matters, i. e. all packages which are in the NEW queue by that time will be processed without the need for an exception.â
<xnox> not sure if this is accurate
 * xnox thought that since proposed-migration the definition of the freeze was "it has migrated"
<mitya57> The âNEW queueâ link on that wiki page points to Saucy queue. :P
<xnox> ah no, we can't drop gsettings-qt because of hud
<tsimonq2> xnox: Then can someone grant Qt 5.9 a FFe? :)
<tsimonq2> :P
<slangasek> xnox: certainly not, since we try to zero out -proposed by release
<xnox> ack
<acheronuk> That page is correct AFAIK. I asked last release or one before
<xnox> slangasek, so, if and when url-dispatcher and ubuntu-app-launch migrate, you should be able to nuke ubuntu-ui-toolkit and all reverse-deps without any side effects.
<xnox> slangasek, i will come back online to double check that; meanwhile i will pack for the trip tomorrow.
<slangasek> xnox: thanks!
<ahasenack> hi guys, I know you are busy, and that's fine. If you have a moment and could take a look at rbasak's ping from earlier today, about a "mini FFe request" about my squid package. I copied it to this pastebin: http://pastebin.ubuntu.com/25385186/
<ahasenack> the MP is actually up (https://code.launchpad.net/~ahasenack/ubuntu/+source/squid3/+git/squid3/+merge/329541), and maybe it will be sponsored before the FF, but maybe not
<slangasek> ahasenack: ack.
<ahasenack> thanks
-queuebot:#ubuntu-release- Packageset: Added linux-kvm to kernel in artful
-queuebot:#ubuntu-release- Packageset: Added linux-meta-kvm to kernel in artful
-queuebot:#ubuntu-release- Packageset: Added linux-kvm to kernel in xenial
-queuebot:#ubuntu-release- Packageset: Added linux-meta-kvm to kernel in xenial
<jbicha> hi, please remove vala 0.37.90 from artful-proposed, we're going to wait until 18.04 for it, sorry about that
<mitya57> slangasek, Qt is a valid candidate again
<slangasek> \o/
<slangasek> jbicha: done
<jbicha> thanks
<mitya57> slangasek, please also remove qtdeclarative-render2d-opensource-src, reasons the same as in Debian #872359
<ubot5> Debian bug 872359 in ftp.debian.org "RM: qtdeclarative-render2d-opensource-src -- ROM; Functionality now included in qtbase 5.9" [Normal,Open] http://bugs.debian.org/872359
<mitya57> And the qt*-opensource-src-gles packages may need removal, I cannot decode whether they block migration or not. In any case support for them was dropped.
<slangasek> it looked like they were blocking migration, yes
<mitya57> slangasek, Do you need a bug for them?
<slangasek> mitya57: yes please
<xnox> slangasek, re:systemd migration blocked by openssh test-suite error it is this https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1712921
<ubot5> Ubuntu bug 1712921 in systemd (Ubuntu) "enabling networkd appears to eat up entropy" [Undecided,New]
<xnox> slangasek, a work-around is to run havegend during openssh test-suite.... because clearly we have never had any major openssh security issues in debian/ubuntu.
<xnox> but the eat up of entropy sounds scary, it may be due to llmnr or aggresive ipv6 refreshes, i'm not yet sure yet.
<slangasek> :/
<mitya57> slangasek, bug 1712924
<ubot5> bug 1712924 in ubuntu-ui-toolkit-gles (Ubuntu) "Please remove Qt -gles packages from archive" [Undecided,New] https://launchpad.net/bugs/1712924
<mitya57> oops, ubuntu-ui-toolkit-gles is already in the other bug, removing it from mine
 * mitya57 goes to sleep, should have done this two hours ago
<slangasek> acheronuk: fwiw the reason kalgebra migrated is because it was already uninstallable; libanalitza7 is somehow missing from artful
<slangasek> acheronuk: it built, as expected, but has been deleted; and I don't know that we have a good audit trail for binary removals
-queuebot:#ubuntu-release- New binary: pythonqt [ppc64el] (artful-proposed/universe) [3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pythonqt [amd64] (artful-proposed/universe) [3.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pythonqt [i386] (artful-proposed/universe) [3.2-1] (no packageset)
<acheronuk> libanalitza7 | 4:16.12.3-0ubuntu1 | artful/universe | s390x
<acheronuk> and as kalgebra didn't build on s390x, that leftover did not stop it?
<acheronuk> kalgbra 17.04 depends properly on it's libanalitza8, so it will sort itself out eventually, but.....
<slangasek> I don't understand the leftover s390x binary at all either
<slangasek> I guess that got published after the other binaries were removed
<acheronuk> that would make sense (ish)
<slangasek> except no, those were all built in March
<acheronuk> the non superseded ubuntu1, yes
<slangasek> oh, if kalgebra didn't built on s390x, yes it wouldn't be uninstallable
-queuebot:#ubuntu-release- New binary: pythonqt [s390x] (artful-proposed/universe) [3.2-1] (no packageset)
<acheronuk> I still don't get how britney thinks that is ok to migrate without a dependant lib, but hell...
<tsimonq2> Could an archive admin please review audacious? I would love for it to land soon... :)
<slangasek> acheronuk: because britney cares about not regressing installability.  If you give it something that's uninstallable, and ask to update, britney says sure why not
-queuebot:#ubuntu-release- New: accepted pythonqt [amd64] (artful-proposed) [3.2-1]
-queuebot:#ubuntu-release- New: accepted pythonqt [ppc64el] (artful-proposed) [3.2-1]
-queuebot:#ubuntu-release- New: accepted pythonqt [i386] (artful-proposed) [3.2-1]
-queuebot:#ubuntu-release- New: accepted pythonqt [s390x] (artful-proposed) [3.2-1]
<acheronuk> right. that does make sense.
<slangasek> tsimonq2: not a priority, vs. fixing qt5.9 migration
<slangasek> tsimonq2: also, this is starting a library transition the day of feature freeze, of a package that hasn't yet cleared Debian NEW.  What testing have you done to confirm the revdeps are buildable?
<slangasek> triggering a no-change rebuild of kjots for kmime/kpimtextedit
<tsimonq2> slangasek: The revdeps build fine in my PPA
<tsimonq2> slangasek: But I see your point
<slangasek> tsimonq2: good to know
<slangasek> I will try to take a look at it once qt is through the chute
<tsimonq2> Ok, thans
<tsimonq2> *thanks
<valorie> slangasek: will that happen today?
<valorie>  qt is through the chute
 * tsimonq2 guesses not
<valorie> :(
<slangasek> hngh, stupid script, accidentally triggered a rebuild of kmailtransport as well
<acheronuk> kjots. is that still alive?
<valorie> no beta 1 for kubuntu then
<tsimonq2> valorie: Well c'mon, it might land within the next few days
<tsimonq2> valorie: Looking at the removal bugs etc. we're getting closer
<valorie> but then all of our uploads have to get through too, or it isn't worth it
<tsimonq2> valorie: That'll all migrate at once.
<tsimonq2> (iirc)
<valorie> there will be nothing new for our users to test
<valorie> well, I'm not announcing anything
<acheronuk> if Qt goes, a few hundred KDE packages will as well
<tsimonq2> valorie: Maybe we should see how the rest of this week and the weekend pans out, it could very well land before the Archive Freeze.
<valorie> if it happens, that will be cool
<tsimonq2> acheronuk: exactly
 * valorie crosses fingers
<cjwatson> slangasek: audit trail for binary removals> exists but is hard to find - you have to remember the URL scheme.  https://launchpad.net/ubuntu/artful/s390x/libanalitza7 in this case
<slangasek> cjwatson: ah, it was doko! :)
<slangasek> doko: ^^ I'm unclear why you removed libanalitza7, which was not NBS in artful and whose removal increased the uninstallable count https://launchpad.net/ubuntu/artful/amd64/libanalitza7
<slangasek> valorie: we're within spitting distance of qt5.9 migrating; I intend to get it before my EOD, because letting it slip another day invites reuploads that slow down the migration
<valorie> oooooo \o/
<valorie> that's great news, slangasek
<valorie> thank you
<acheronuk> valorie: I *think* I have only one broken package that won't migrate
<valorie> NICE
<acheronuk> and that's only because I'm waiting to see if KDE does an upstream fix, so I don't have to break/fix it worse
<valorie> :-)
 * acheronuk glares at cantor
<slangasek> gnucash, libreoffice-pdfimport look worrisome
<jbicha> gnucash was removed from buster (webkit1)
<jbicha> if you like removing stuff there's LP: #1710318
<ubot5> Launchpad bug 1710318 in xiphos (Ubuntu) "Please remove webkit1 rdepends removed from Debian Testing" [Undecided,New] https://launchpad.net/bugs/1710318
<slangasek> so for personal interest, what's a good replacement for gnucash? :P
 * tsimonq2 wonders what it even is :P
<jbicha> I don't know, uh, LibreOffice Calc ? :(
<tsimonq2> !info gnucash
<ubot5> gnucash (source: gnucash): personal and small-business financial-accounting software. In component universe, is extra. Version 1:2.6.15-1 (zesty), package size 2304 kB, installed size 10082 kB
<tsimonq2> ohh k gotcha
<acheronuk> kmymoney?
<acheronuk> I've never used either though....
<tsimonq2> There's a debconf 17 talk somewhere about it, let me find it...
<slangasek> calc> very funny ;-P
<cjwatson> bc
<acheronuk> !info skrooge
<ubot5> skrooge (source: skrooge): personal finance manager for KDE. In component universe, is extra. Version 2.7.0-1 (zesty), package size 1721 kB, installed size 9464 kB
<jbicha> at least I didn't suggest gnome-calculatorâ¦
<cjwatson> I mean I'm sure emacs can do it
<tsimonq2> cjwatson: XD
<tsimonq2> http://meetings-archive.debian.net/pub/debian-meetings/2017/debconf17/business-erp-freelancer-and-personal-acc.vp8.webm - here we go
<jbicha> maybe somebody just needs to snapify gnucash, then it doesn't matter so much that it uses old libraries
<Ukikie> Eww.
<slangasek> tdaitx: what's the right fix for the failing libreoffice autopkgtests (can't find -ljawt at link time)?
<slangasek> /<<PKGBUILDDIR>>/libutopia2_qt/utopia2/qt/bubble.h:56: Error: Namespace declaration lacks Q_NAMESPACE macro.
<slangasek> someone want to fix utopia-documents?
<jbicha> slangasek: I tried, want to remove it instead? LP: #1710317
<ubot5> Launchpad bug 1710317 in utopia-documents (Ubuntu) "utopia-documents FTBFS in artful" [High,New] https://launchpad.net/bugs/1710317
<slangasek> hinted libreoffice failures, which also fixes ubuntu-budgie-desktop
#ubuntu-release 2017-08-25
<acheronuk> ok. late here. goodnight. thank you slangasek and others for the efforts here
<xnox> slangasek, good replacement for gnucash is the new gnucash =)
<xnox> gtk3+ and with webkit reports disabled
<tsimonq2> oooOOOooo
<xnox> slangasek, but i have also started to use the Personal Finance Management apps. Like https://www.pocketsmith.com/
<xnox> which hooks into banks and does most of the things out of the box /o\
<slangasek> xnox: "new gnucash" sounds like a currency revaluation
<xnox> slangasek, if i meant currency revaluation i  would say "hard fork" like all the cool crypto kids
<xnox> slangasek, what's wrong with gnucash? does it need fixing? or like disabling webkit reporting?
<slangasek> xnox: don't know; it ftbfs
<slangasek> but not because of old webkit dep, AFAIK
<xnox> slangasek, libofx6 -> libofx7 transition affecting gnucash homebank kmymoney
<slangasek> yes
<slangasek> and I think we're down to where I can drop libertine + content-hub and let britney make some trades
<slangasek> +ubuntu-ui-toolkit
<slangasek> there we go.  one more publishing run + britney run, and we should be good
<slangasek> off for dinner, back in a few hours to check up
<xnox> slangasek, seems like stuff regressed in release cause 2.6.15 (previous gnucash) also does not build =(
<slangasek> xnox: eh, you uploaded qtubuntu *now*? I thought you were going to wait until the transition finished.
<slangasek> well, NBS binaries removed.
<xnox> yes
<xnox> plus you can remove a lot more packages now
<xnox> slangasek, https://bugs.launchpad.net/ubuntu/+source/qtubuntu-camera/+bug/1712955
<ubot5> Ubuntu bug 1712955 in powerd (Ubuntu) "RM: obsolete product" [Undecided,Triaged]
<xnox> and i think we may be done removing all of unity touch stuff
<tdaitx> slangasek, I took a quick look at libreoffice (http://autopkgtest.ubuntu.com/packages/libreoffice) but I can't see failures due to jawt, only due to a test complaining about gcc-7 warnings, where are you seeing those?
<tdaitx> the configure script does indicate that jawt was found just fine
<slangasek> tdaitx: the test result from the new version of libreoffice in -proposed, libreoffice/1:5.4.0-0ubuntu2
<slangasek> qt5.9 in; phew
<Mirv> congrats slangasek, tsimonq2, mitya57 and everyone!
<xnox> win!
<valorie> pretty encouraging to read the excuses report!
<LocutusOfBorg> thanks you all for the nice transition!
<LocutusOfBorg> qt screwed up britney lol
<LocutusOfBorg> orthanc-wsi/amd64 unsatisfiable Depends: libdcmtk12
<LocutusOfBorg> they have all migrated, but excuses shows a lot of weirdness
<slangasek> LocutusOfBorg: it's because launchpad has acked the copy of the packages but they haven't been published to the archive yet, so britney's input is a bit out of sync
<slangasek> things are looking pretty installable again, so the next britney run should look sane
<acheronuk> \o/
<acheronuk> thank you all :)
<LocutusOfBorg> yep I got it, it was a joke :)
<LocutusOfBorg> I remember how many cycles are needed when haskell migrates
<LocutusOfBorg> :D
<mitya57> \o/ thanks to you all!
<acheronuk> +1
<acheronuk> feels like a huge milestone overcome!
<LocutusOfBorg> mitya57, what about doing the qt merges / syncs now? :)
<LocutusOfBorg> e.g. we can sync qtwebkit-opensource-src and merge qtbase
-queuebot:#ubuntu-release- New binary: audacious [ppc64el] (artful-proposed/universe) [3.9-2~build1] (lubuntu)
-queuebot:#ubuntu-release- New binary: audacious [i386] (artful-proposed/universe) [3.9-2~build1] (lubuntu)
-queuebot:#ubuntu-release- New binary: audacious [arm64] (artful-proposed/universe) [3.9-2~build1] (lubuntu)
-queuebot:#ubuntu-release- New binary: audacious [s390x] (artful-proposed/universe) [3.9-2~build1] (lubuntu)
-queuebot:#ubuntu-release- New binary: audacious [armhf] (artful-proposed/universe) [3.9-2~build1] (lubuntu)
-queuebot:#ubuntu-release- New binary: audacious [amd64] (artful-proposed/universe) [3.9-2~build1] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (zesty-proposed) [2.27.4+17.04]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.27.4]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (trusty-proposed) [2.27.4~14.04]
<LocutusOfBorg> please accept pcscada, it should unblock the gnat transition a little bit further (it is a package rename because it changed the gnat default), leaf package
-queuebot:#ubuntu-release- New binary: pcscada [ppc64el] (artful-proposed/universe) [0.7.3-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: pcscada [amd64] (artful-proposed/universe) [0.7.3-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: pcscada [s390x] (artful-proposed/universe) [0.7.3-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: pcscada [armhf] (artful-proposed/universe) [0.7.3-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: pcscada [i386] (artful-proposed/universe) [0.7.3-1.1] (no packageset)
-queuebot:#ubuntu-release- New binary: pcscada [arm64] (artful-proposed/universe) [0.7.3-1.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pcscada [amd64] (artful-proposed) [0.7.3-1.1]
-queuebot:#ubuntu-release- New: accepted pcscada [armhf] (artful-proposed) [0.7.3-1.1]
-queuebot:#ubuntu-release- New: accepted pcscada [ppc64el] (artful-proposed) [0.7.3-1.1]
-queuebot:#ubuntu-release- New: accepted pcscada [arm64] (artful-proposed) [0.7.3-1.1]
-queuebot:#ubuntu-release- New: accepted pcscada [s390x] (artful-proposed) [0.7.3-1.1]
-queuebot:#ubuntu-release- New: accepted pcscada [i386] (artful-proposed) [0.7.3-1.1]
<mitya57> LocutusOfBorg, there are almost no changes to merge in qtbase. Just symbols and the no-gold thing we already have here.
<mitya57> If Qt 5.9.2 is released early enough, then we may merge it this cycle. Otherwise early next cycle.
<jbicha> please ignore flask-mongoengine/i386 autopkgtests since mongodb doesn't exist on i386 any more
<tsimonq2> :D
 * tsimonq2 just woke up
<tsimonq2> mitya57: I think we'll have a pretty good chance of landing 5.9.2
<tsimonq2> \o/ Mirv xnox valorie LocutusOfBorg slangasek acheronuk mitya57 :D :D :D :D :D
<mitya57> :D
<valorie> bugfixes are awesome, yeah!
<mitya57> Qt 5.9.2 does not even have a branch upstream yet.
<mitya57> So they will definitely not release it in August as planned, middle or end of September at the best.
<tsimonq2> mitya57: But since it doesn't bump ABI (not afaict) and it's a bugfix release, we shouldn't have any problem landing it now that the blocking Unity 8 packages are out of the way.
<mitya57> tsimonq2, it can break ABI, we should be careful.
<tsimonq2> mitya57: ack, but my general point is, it should be *much* easier than doing 5.9.1
<mitya57> Right.
<valorie> are all the other big transitions done?
<valorie> like gcc, etc.
<slangasek> yes
<slangasek> we still have a new glibc upstream version that we need to figure out if it's going to land this cycle; but that should land only if it's not disruptive to the release and there will be build tests ahead of landing to verify this
<slangasek> and that's not a "transition" in the sense of needing to upload a bunch of packages
<fossfreedom> Hi - can I just confirm that we are in freeze now and universe packages like budgie-desktop will no longer sync from Debian unstable ?
<valorie> I meant transition in the sense of "keeping LP busy for days or weeks"
<slangasek> valorie: well, glibc will swamp the autopkgtest infra for a bit
<slangasek> fossfreedom: Debian autosyncs are turned off; I'll send an email later today confirming the freeze
<fossfreedom> excellent - that's good news.  cheers
<slangasek> fossfreedom: budgie-desktop wouldn't sync from Debian anyway, it's an Ubuntu package?
<valorie> thank you so much, release team
<valorie> looking forward to Beta 1 now
<slangasek> now, can anyone explain to me why cantor's autopkgtests are behaving the way they do? :/
<fossfreedom> slangasek, I maintain it via Debian.  Currently in artful I have a later version than in Debian unstable - I don't want that version overwritten when the sync is in play.
<slangasek> difference in testbed packages between last success and first failure (not counting cantor itself): apport, cron, python3-apport, python3-problem-report, resolvconf, ubuntu-minimal
<slangasek> fossfreedom: packages with an Ubuntu delta never auto-sync; and feature freeze doesn't stop an Ubuntu developer from manually merging
<fossfreedom> k - that's ok.  When "B" opens can I just ask for a force-sync ?
<slangasek> sure
<fossfreedom> cheers
<slangasek> Laney: unrelated to the above question about cantor, but I notice that around the 23rd, testbed-packages seems to have gotten a lot bigger on amd64 - bunches of cloud/server-seeded packages that were previously absent have just turned up.  Do you know if this is a result of a deliberate change on the autopkgtest side?
<slangasek> Laney: random example: lvm2, which is not new in the cloud seed but is new in testbed-packages
<slangasek> oh, and I suppose I need to be looking at testsuite-packages, not just testbed-packages, for bisecting this :P
<slangasek> ah now I see, the failing results are from the 4:16.12.3-0ubuntu2 version of the test suite but the binaries installed are from 4:17.04.3-0ubuntu1
<slangasek> tdaitx: openjdk-9-jre-zero shows up on the list of uninstallable packages in artful; do you know anything about this? http://people.canonical.com/~ubuntu-archive/proposed-migration/artful_uninst.txt
<nacc> slangasek: yep, someone reported that earlier today in #ubuntu+1 (jdk-9 being borken in general i think)
<tdaitx> slangasek, is that zero only? I saw reports about -3 being uninstallable, but then matthias released a -4 right after
<slangasek> tdaitx: it's only the -zero package listed as uninstallable.  If this is all fixed already in -proposed, ok - in that case we have an autopkgtest regression to sort out: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#openjdk-9
<tdaitx> I didn't look into that so far, I assumed it was fixed - at the same time, it didn't seem to be related to zero, the whole package was affected... the link you send me is -2, so I don't know if this has been fixed in -4
<nacc> slangasek: fwiw, this was the report in #ubuntu+1: http://paste.ubuntu.com/25390671/
<slangasek> nacc: right, maintainer script failures aren't going to show up on the uninstallable report, which is just static analysis of the dependencies
<nacc> slangasek: oh right
<tdaitx> nacc, slangasek: that is indeed what is supposed to be fixed by -4
<slangasek> -3 being uninstallable, well, that was only ever in -proposed
<nacc> tdaitx: thanks i'll let  them know
<slangasek> nacc: also tell the user not to install from -proposed :)
<tdaitx> I need to take a look about zero
<slangasek> oh, wait
<slangasek> no, there's a mix of -2 and -3 in artful
<nacc> rmadison says -jdk is at -3 in artful/universe
<nacc> yeah
<slangasek>  openjdk-9-jre-zero     | 9~b181-2 | artful/universe          | amd64, arm64, armhf, i386, ppc64el, s390x
<slangasek> yet this package is not listed on http://people.canonical.com/~ubuntu-archive/nbs.html
<tdaitx> hmm, https://launchpad.net/ubuntu/+source/openjdk-9 reports -3 as released and -4 in -proposed
<slangasek> tdaitx: ^^ so this tells me we're not building the binary, but it hasn't been dropped from debian/control, therefore it's not reported as NBS.  Should I just delete the openjdk-9-jre-zero binary package?
<slangasek> retrying that failed munin autopkgtest
-queuebot:#ubuntu-release- Unapproved: nplan (xenial-proposed/universe) [0.23~16.04.1 => 0.26~16.04.1] (no packageset)
<tdaitx> slangasek, yes, delete the zero binary packages, doko disabled those in -4
<slangasek> ok
<tdaitx> sorry for the delay, it was a one line change and I missed it in the first run
<jbicha> please demote prosper to universe to allow texlive-base to migrate to artful, it shows up on components-mismatches-proposed
<slangasek> jbicha: done
<jbicha> thanks, while you're around, could you also ignore libsecret/s390x autopkgtests since we have removed gjs/s390x which it wants for its tests
<slangasek> jbicha: also done
<acheronuk> slangasek: https://bugs.kde.org/show_bug.cgi?id=379404
<ubot5> KDE bug 379404 in maxima-backend "Cantor can't initialize session for maxima backend" [Normal,Confirmed]
<slangasek> righty-o
<acheronuk> and upstream they now set: https://cgit.kde.org/cantor.git/commit/?id=60cc35e0bcf01a8c718a24715ffebdb5f9210092
<acheronuk> so (a) need a fix, or (b) need to disable build and test of that backend
<acheronuk> or (c) leave at 16.12 which seems to work here
<valorie> debian has no fix?
<acheronuk> ah. you ignored that against anything !cantor. fair enough. can wait a bit to see if a fix comes
<acheronuk> valorie: debian packaging has not benn touched for 9 months
<valorie> oh dear
<acheronuk> others distro's may have found a non upstreamed patch. was going to check that out later
<acheronuk> !info cantor unstable
<ubot5> cantor (source: cantor): interface for mathematical applications. In component main, is optional. Version 4:16.08.3-1 (unstable), package size 443 kB, installed size 1597 kB
<slangasek> acheronuk: c) is not an option for release, due to analitza soname change
<slangasek> acheronuk: at least, we'd need to delete the cantor currently in -proposed and reupload a no-change rebuild
<acheronuk> yes, true
<acheronuk> I'll do that somewhere to test over the weekend
-queuebot:#ubuntu-release- Unapproved: apparmor (xenial-proposed/main) [2.10.95-0ubuntu2.6 => 2.10.95-0ubuntu2.7] (core)
#ubuntu-release 2017-08-26
<tsimonq2> slangasek: Update topic?
* slangasek changed the topic of #ubuntu-release to: Released: Xenial 16.04.3, Zesty 17.04 | Archive: fi'tÊÅË friz | Artful Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
-queuebot:#ubuntu-release- New: accepted audacious [amd64] (artful-proposed) [3.9-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted audacious [i386] (artful-proposed) [3.9-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted audacious [arm64] (artful-proposed) [3.9-1ubuntu3]
-queuebot:#ubuntu-release- New: accepted audacious [i386] (artful-proposed) [3.9-1ubuntu3]
-queuebot:#ubuntu-release- New: accepted audacious [s390x] (artful-proposed) [3.9-1ubuntu3]
-queuebot:#ubuntu-release- New: accepted audacious [s390x] (artful-proposed) [3.9-1~build1]
-queuebot:#ubuntu-release- New: accepted audacious [arm64] (artful-proposed) [3.9-2~build1]
-queuebot:#ubuntu-release- New: accepted audacious [i386] (artful-proposed) [3.9-2~build1]
-queuebot:#ubuntu-release- New: accepted audacious [s390x] (artful-proposed) [3.9-2~build1]
-queuebot:#ubuntu-release- New: accepted audacious [armhf] (artful-proposed) [3.9-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted audacious [armhf] (artful-proposed) [3.9-1ubuntu3]
-queuebot:#ubuntu-release- New: accepted audacious [amd64] (artful-proposed) [3.9-1~build1]
-queuebot:#ubuntu-release- New: accepted audacious [armhf] (artful-proposed) [3.9-2~build1]
-queuebot:#ubuntu-release- New: accepted audacious [amd64] (artful-proposed) [3.9-1ubuntu3]
-queuebot:#ubuntu-release- New: accepted audacious [amd64] (artful-proposed) [3.9-2~build1]
-queuebot:#ubuntu-release- New: accepted audacious [ppc64el] (artful-proposed) [3.9-1ubuntu3]
-queuebot:#ubuntu-release- New: accepted audacious [ppc64el] (artful-proposed) [3.9-2~build1]
<tsimonq2> slangasek: clever :P
<LocutusOfBorg> any AA ( slangasek ) if you are around, please kick imms out
<LocutusOfBorg> it is blocking audacious and not really compatible with the new version https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873166
<ubot5> Debian bug 873166 in src:imms "imms: FTBFS against audacious 3.9" [Serious,Open]
<LocutusOfBorg> I could patch it probably, but it is not worth the effort for a dead upstream package (and making it build doesn't mean it will work)
<LocutusOfBorg> remove, move to proposed, as you wish :)
<LocutusOfBorg> is i386 still a thing?
<slangasek> LocutusOfBorg: imms> done
<LocutusOfBorg> thanks!!!
#ubuntu-release 2017-08-27
<Ukikie> I don't suppose an AA could have a look at xfce4-statusnotifier-plugin sitting in NEW?
<tsimonq2> Urgh, Firefox audio is broken again on Lubuntu 16.04 LTS: bug 1710993
<ubot5> bug 1710993 in firefox (Ubuntu) "PulseAudio requirement breaks Firefox on ALSA-only systems after 55.0.1 update" [Undecided,In progress] https://launchpad.net/bugs/1710993
<tsimonq2> We had discussions about it before, when the breaking update was initially released. Well, something changed (I suspect bitrot) and it's broken again.
<tsimonq2> Since 16.04 is the only Lubuntu release we currently support without PulseAudio, I talked to others in the team and pulling in PulseAudio is what the solution for that is.
<tsimonq2> Either way, whether that's an upload to Firefox or lubuntu-meta, that requires an SRU...
<tsimonq2> What would the Release Team prefer, for Lubuntu to add pulseaudio as a hard dep of lubuntu-desktop, or for Firefox to have a hard dep on Pulseaudio?
 * tsimonq2 does one more look at the possibility of fixing ALSA support, unlikely but possible...
-queuebot:#ubuntu-release- Unapproved: docker.io (xenial-proposed/universe) [1.12.6-0ubuntu1~16.04.1 => 1.13.1-0ubuntu1~16.04.1] (no packageset)
<mwhudson> oops
<mwhudson> if any SRU people around can you reject that one? (wrong bug number in changelog)
-queuebot:#ubuntu-release- Unapproved: docker.io (xenial-proposed/universe) [1.12.6-0ubuntu1~16.04.1 => 1.13.1-0ubuntu1~17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: runc (xenial-proposed/universe) [1.0.0~rc2+docker1.12.6-0ubuntu1~16.04.1 => 1.0.0~rc2+docker1.13.1-0ubuntu1~17.04.1] (no packageset)
<mwhudson> oh heavens that's wrong too isn't it
-queuebot:#ubuntu-release- New binary: network-manager [amd64] (artful-proposed/main) [1.8.2-1ubuntu4] (kubuntu, ubuntu-desktop)
#ubuntu-release 2018-08-20
<slangasek> acheronuk, tsimonq2: emacs got its binary promotion. The remaining issue is autopkgtest failures of racket-mode against new emacs.
<mwhudson> racket-mode appears to have no rdeps...
<tsimonq2> slangasek: ack
<tsimonq2> LocutusOfBorg: Debian bug 906714.
<ubot5> Debian bug 906714 in paraview "paraview: FTBFS in Sid" [Serious,Open] http://bugs.debian.org/906714
<tsimonq2> mwhudson: Right, that was my line of thinking.
<acheronuk> tsimonq2: I was wrong. think octave rdep tests do need to be fixed for to make psftools rebuild a candidate :/
<acheronuk> or pfstools demoting to proposed I guess
-queuebot:#ubuntu-release- Unapproved: software-properties (bionic-proposed/main) [0.96.24.32.4 => 0.96.24.32.5] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: geoclue-2.0 [amd64] (cosmic-proposed/main) [2.4.12-1ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted geoclue-2.0 [amd64] (cosmic-proposed) [2.4.12-1ubuntu1]
-queuebot:#ubuntu-release- New binary: nova-lxd [amd64] (cosmic-proposed/main) [18.0.0~a1~git2018081619.bc8d540-0ubuntu1] (ubuntu-server)
<mwhudson> tsimonq2: although still, sed?
<LocutusOfBorg> ./ubuntu-release:force-badtest yorick/2.2.04+dfsg1-7 yorick/2.2.04+dfsg1-9
<LocutusOfBorg> ./laney:force-badtest yorick/2.2.04+dfsg1-9build1/i386
<mwhudson> isome kind of conf.d file would be a lot cleaner
<LocutusOfBorg> anybody, can update the yorick hint to amd64 too?
<LocutusOfBorg> I retried the build some seconds ago, but I don't think it will pass
-queuebot:#ubuntu-release- New: accepted budgie-extras [amd64] (cosmic-proposed) [0.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted budgie-extras [armhf] (cosmic-proposed) [0.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted budgie-extras [ppc64el] (cosmic-proposed) [0.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted cpdb-libs [amd64] (cosmic-proposed) [1.2.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted cpdb-libs [armhf] (cosmic-proposed) [1.2.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted cpdb-libs [ppc64el] (cosmic-proposed) [1.2.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted budgie-extras [arm64] (cosmic-proposed) [0.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted budgie-extras [s390x] (cosmic-proposed) [0.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted cpdb-libs [i386] (cosmic-proposed) [1.2.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted budgie-extras [i386] (cosmic-proposed) [0.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted cpdb-libs [s390x] (cosmic-proposed) [1.2.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted cpdb-libs [arm64] (cosmic-proposed) [1.2.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted budgie-wallpapers [amd64] (cosmic-proposed) [18.10]
-queuebot:#ubuntu-release- New: rejected cpdb-backend-file [source] (cosmic-proposed) [1.0.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted nova-lxd [amd64] (cosmic-proposed) [18.0.0~a1~git2018081619.bc8d540-0ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [4.15.0-1018.19] (no packageset)
-queuebot:#ubuntu-release- New binary: networking-hyperv [amd64] (cosmic-proposed/universe) [7.0.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New source: squid (cosmic-proposed/primary) [4.1-1ubuntu1]
<doko> Laney not online? update_excuses lists a lot of tests running, which are not running ...
<doko> xnox, juliank: ^^^ not sure if you can do something about that. but look at the tests triggered by glibc
<juliank> oh ..., I need a "hide successful runs" option
<juliank> doko: sil2100 I remember something about armhf tests not running or something
<juliank> but most of it seems fine
<doko> "most" doesn't help
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (bionic-proposed/partner) [201.0.0-0ubuntu2~18.04.0 => 212.0.0-0ubuntu1~18.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: chrony (bionic-proposed/main) [3.2-4ubuntu4.1 => 3.2-4ubuntu4.2] (ubuntu-server)
<slashd> sil2100, can you pleae reject gdm3 '3.28.2-0ubuntu1.5' in favor of '3.28.3-0ubuntu18.04.1' in Bionic upload queue ? and accept '3.28.3-0ubuntu18.04.1' ? + gdm3 for Xenial ?
<slashd> dgadomski, ^
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (trusty-proposed/partner) [201.0.0-0ubuntu2~14.04.0 => 212.0.0-0ubuntu1~14.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (xenial-proposed/partner) [201.0.0-0ubuntu2~16.04.0 => 212.0.0-0ubuntu1~16.04.0] (no packageset)
<sil2100> slashd: o/
<sil2100> Ah, finally gdm3
<slashd> sil2100, \o
<ahasenack> hi, about the "new source: squid 4.1" above
<ahasenack> that's replacing/upgrading squid3
<ahasenack> ubuntu used to have a source package called just "squid", without a version number, and then moved to "squid3"
<ahasenack> debian has moved squid (v4) from experimental to unstable, and the new source above is my merge for that
<ahasenack> ubuntu blacklisted squid (no version in the name) a while ago from automatic sync
<ahasenack> how should I proceed?
<LocutusOfBorg> apw, do you have time for a quick question?
<LocutusOfBorg> I fixed mostly all the issues, demoting pfstools to proposed will disentangle octave with all the other transitions
<LocutusOfBorg> and leave only emacs25 failures to us
<LocutusOfBorg> also vdr-plugin-softhddevice should be kicked, it is FTBFS in debian, unmaintained, RC buggy and so on
<LocutusOfBorg> tupi is a dead project since 2014, maybe time to kick it out too https://github.com/KDE/tupi
-queuebot:#ubuntu-release- Unapproved: yaml-cpp (xenial-proposed/universe) [0.5.2-3 => 0.5.2-4ubuntu1~16.04.4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected gdm3 [source] (bionic-proposed) [3.28.2-0ubuntu1.5]
-queuebot:#ubuntu-release- Unapproved: rejected qpdf [sync] (bionic-proposed) [8.1.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (bionic-proposed) [212.0.0-0ubuntu1~18.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (xenial-proposed) [212.0.0-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (trusty-proposed) [212.0.0-0ubuntu1~14.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted gdm3 [source] (bionic-proposed) [3.28.3-0ubuntu18.04.1]
<slashd> dgadomski ^
-queuebot:#ubuntu-release- New binary: paraview [s390x] (cosmic-proposed/universe) [5.4.1+dfsg4-3ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-urllib3 (xenial-proposed/main) [1.13.1-2ubuntu0.16.04.1 => 1.13.1-2ubuntu0.16.04.2] (kubuntu, ubuntu-desktop, ubuntu-server)
<ahasenack> regarding squid (4.1), here is a bileto run: https://bileto.ubuntu.com/#/ticket/3351
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (bionic-proposed/main) [0.130ubuntu3.2 => 0.130ubuntu3.3] (core)
-queuebot:#ubuntu-release- New binary: paraview [ppc64el] (cosmic-proposed/universe) [5.4.1+dfsg4-3ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted bolt [source] (bionic-proposed) [0.4-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-system-monitor [source] (bionic-proposed) [35-1ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted lubuntu-default-settings [source] (bionic-proposed) [0.54.1]
<LocutusOfBorg> also emacs should go in main, and emacs25 to universe?
<tsimonq2> sil2100: Hey :)
<tsimonq2> sil2100: I'm grabbing an ISO to test lubuntu-default-settings now, but once that's done could you waive the seven day aging period>
<tsimonq2> s/>/?/
<tsimonq2> sil2100: The only verification bits that are needed is to confirm that the session is actually gone.
-queuebot:#ubuntu-release- New: accepted networking-hyperv [amd64] (cosmic-proposed) [7.0.0-0ubuntu1]
<tsimonq2> sil2100, apw, slangasek: Could an AA process LocutusOfBorg's request please? We're >< this close to getting Qt to land.
<LocutusOfBorg> qt and lots of other foobar, including re-enabling autosync
<LocutusOfBorg> and doing sndio transition finally
<tsimonq2> ^^^
<slangasek> tsimonq2: which request?
<slangasek> LocutusOfBorg: ?
<tsimonq2> 11:03:50 AM < LocutusOfBorg> also emacs should go in main, and emacs25 to universe?
<slangasek> er
<tsimonq2> LocutusOfBorg: I'm probably talking about something different though?
<slangasek> unless someone reverted something, there's nothing that needs changing there
<tsimonq2> slangasek: But also see his pings to a_p_w above...
<slangasek> emacs is only blocked by the racket-mode autopkgtest failures
<slangasek> pfstools demoted
<tsimonq2> 08:52:23 AM < LocutusOfBorg> also vdr-plugin-softhddevice should be kicked, it is FTBFS in debian, unmaintained, RC buggy and so on
<tsimonq2> ^
<tsimonq2> But otherwise yeah, hunting that racket-node autopkgtest failure.
<acheronuk> [14:59] <LocutusOfBorg> tupi is a dead project since 2014, maybe time to kick it out too https://github.com/KDE/tupi
<tsimonq2> slangasek: But... racket-mode fails against itself?
<tsimonq2> http://autopkgtest.ubuntu.com/packages/r/racket-mode/cosmic/arm64
<tsimonq2> Even when triggered by racket-mode/20180731+0+g948c8aa-2 it fails.
<LocutusOfBorg> yes, all the failures are retried again themselves
<LocutusOfBorg> slangasek, I looked at update_output_notest and saw something interesting wrt emacs
<LocutusOfBorg> so, I can trust you saying "no issues there", but britney confuses me
<slangasek> ok I hadn't checked notest
<slangasek> let me see
<LocutusOfBorg>     * amd64: emacs25, emacs25-lucid, pfsglview, pfstools, pfsview, tupi, vdr-plugin-softhddevice
<LocutusOfBorg> this is the current update_output situation
<LocutusOfBorg> pfstools can go in -proposed for a while (to me) until octave migrates
<LocutusOfBorg> others vdr/tubi "kill them with fire" :)
<tsimonq2> Of *course* I forget to remove QLubuntu.desktop in install file for that lubuntu-default-settings upload, sigh.
<slangasek> right, with notest there are some binaries that are built from emacs25 source which become uninstallable, the fix for that is just to remove emacs25
<slangasek> but not until the transition is ready
<LocutusOfBorg> with 2 removals and emacs25 hint it is ready, right?
<LocutusOfBorg> also paraview is fixed now, but meh, it will migrate later
<LocutusOfBorg> pfstools is leaf package, I think it can live in -proposed for some days
<LocutusOfBorg> (octave is ready to migrate, giings will probably file removal bugs for it)
<slangasek> vdr-plugin-softhddevice removed
<LocutusOfBorg> and tupi?
<slangasek> tupi removed
<LocutusOfBorg> aaaaaaaaand  pfstools kicked in -proposed until octave is sorted?
 * LocutusOfBorg prepares a glass of wine to celebrate
<slangasek> yes
 * acheronuk pours large glass of JD
 * tsimonq2 pours glass of coffee
 * LocutusOfBorg regenerates debian-junior package, to drop tupi recommends
<LocutusOfBorg> slangasek, should we hint emacs to make it migrate?
<slangasek> and for racket-mode, has someone analyzed the failures to confirm whether this is a regression in racket-mode on these archs, or a newly introduced test that fails, or a regression in emacs?
<tsimonq2> slangasek: I think it's a regression in racket-mode.
<tsimonq2> I see test retries against itself which fail.
<LocutusOfBorg> slangasek, on s390x racket mode is dep-wait, so it won't ever pass
<tsimonq2> Wat. O_o
<tsimonq2> Why's it even being tried?
<LocutusOfBorg> I mean, src:racket sorry
<tsimonq2> ohh
<LocutusOfBorg> it has been removed around bionic
<LocutusOfBorg> the first test is probably a copy-paste from bionic
<LocutusOfBorg> arm64 laney some days ago said it was probably worth hinting
<LocutusOfBorg> I can't find the discussion anymore :/ I hope i remember it right
<ginggs> LocutusOfBorg: LP: #1787992
<ubot5> Launchpad bug 1787992 in octave-odepkg (Ubuntu) "Please remove octave-ocs, octave-odepkg" [Undecided,New] https://launchpad.net/bugs/1787992
<ahasenack> hi, could an archive admin please look at my squid-4.1 upload? It's a new source, that replaces squid3
<ahasenack> ubuntu used to have a source package called just "squid", without a version number, and then moved to "squid3"
<ahasenack> debian has moved squid (v4) from experimental to unstable, and the new source above is my merge for that
<ahasenack> it passed dep8 tests, manual tests, upgrade tests: https://code.launchpad.net/~ahasenack/ubuntu/+source/squid/+git/squid/+merge/353097 has details
-queuebot:#ubuntu-release- New binary: blends [amd64] (cosmic-proposed/universe) [0.7.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: paraview [amd64] (cosmic-proposed/universe) [5.4.1+dfsg4-3ubuntu2] (no packageset)
<LocutusOfBorg> slangasek, I rebased  my proposed merge request 3 times or so
<LocutusOfBorg> -force-badtest mariadb-10.1/1:10.1.29-6ubuntu2 mariadb-10.1/1:10.1.34-1
<LocutusOfBorg> +force-badtest mariadb-10.1/1:10.1.29-6ubuntu2 mariadb-10.1/1:10.1.34-1 mariadb-10.1/1:10.1.35-1ubuntu1
<LocutusOfBorg> can you please do it?
<LocutusOfBorg> I don't know how to rebase
-queuebot:#ubuntu-release- New binary: paraview [i386] (cosmic-proposed/universe) [5.4.1+dfsg4-3ubuntu2] (no packageset)
<tsimonq2> Wait, wat? :)
<tsimonq2> oh
<tsimonq2> That wasn't removed... right.
<LocutusOfBorg> demoted to proposed, so not a real issue, but meh, I fixed it
<acheronuk>     got: 17+0: a-3:a-2:a-4:i-2:p-2:s-4
<acheronuk>     * s390x: emacs25, emacs25-lucid
<tsimonq2> So waiting on slangasek to hint? :)
<acheronuk> [17:27] <slangasek> right, with notest there are some binaries that are built from emacs25 source which become uninstallable, the fix for that is just to remove emacs25
<acheronuk> tsimonq2: if that still applies?
<tsimonq2> Right.
-queuebot:#ubuntu-release- New binary: paraview [arm64] (cosmic-proposed/universe) [5.4.1+dfsg4-3ubuntu2] (no packageset)
<slangasek> tsimonq2, LocutusOfBorg: sorry, I'm off today and in the process of vacating a hotel room, I won't be able to look at racket-mode/arm64 for the next 4+ hours, best to find another release team member to follow through
<tsimonq2> infinity, sil2100, stgraber: ^^^
<infinity> tsimonq2: Need context, but sure.
<tsimonq2> infinity: racket-mode failed autopkgtests against itself and is also failing against emacs. It isn't emacs' fault.
<xnox> does it pass against old emacs?
<xnox> (new racket + old emacs)
<tsimonq2> xnox: No.
<xnox> ack
<tsimonq2> Welcome back xnox. :)
-queuebot:#ubuntu-release- New binary: paraview [armhf] (cosmic-proposed/universe) [5.4.1+dfsg4-3ubuntu2] (no packageset)
<infinity> tsimonq2: I don't buy your assertion that racket-mode is regressed in release.
<tsimonq2> infinity: Oh?
<infinity> tsimonq2: Which test result do you base this assertion on? :P
<infinity> tsimonq2: 20170617+0+g9c5bcb7-2 is the release pocket version, I don't see it failing except against the new emacs.
<LocutusOfBorg> triggers
<LocutusOfBorg> ['racket-mode/20170617+0+g9c5bcb7-2']
<LocutusOfBorg> I just issued it :)
<tsimonq2> I was going to say, you have to escape a bajillion things there... :P
<LocutusOfBorg> such versioning is difficult to parse, I was tricked by it too
-queuebot:#ubuntu-release- New: accepted blends [amd64] (cosmic-proposed) [0.7.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted paraview [arm64] (cosmic-proposed) [5.4.1+dfsg4-3ubuntu2]
-queuebot:#ubuntu-release- New: accepted paraview [i386] (cosmic-proposed) [5.4.1+dfsg4-3ubuntu2]
-queuebot:#ubuntu-release- New: accepted paraview [s390x] (cosmic-proposed) [5.4.1+dfsg4-3ubuntu2]
-queuebot:#ubuntu-release- New: accepted paraview [amd64] (cosmic-proposed) [5.4.1+dfsg4-3ubuntu2]
-queuebot:#ubuntu-release- New: accepted paraview [ppc64el] (cosmic-proposed) [5.4.1+dfsg4-3ubuntu2]
-queuebot:#ubuntu-release- New: accepted paraview [armhf] (cosmic-proposed) [5.4.1+dfsg4-3ubuntu2]
<LocutusOfBorg> infinity, you can see the running test, it is looping on "still trying to connect" and will timeout soon
<tsimonq2> infinity: Here's your fail: http://autopkgtest.ubuntu.com/packages/racket-mode/cosmic/arm64
<infinity> Nope.
<infinity> Get:100 http://ports.ubuntu.com/ubuntu-ports cosmic-proposed/universe arm64 elpa-racket-mode all 20180731+0+g948c8aa-2 [105 kB]
<tsimonq2> Darnit.
<LocutusOfBorg> infinity, so no way to test against release pocket?
<LocutusOfBorg> jbicha, can you *please* stop syncing stuff for some hours, so we can make everything migrate?
<LocutusOfBorg> gegl is making the transition look bad again
<LocutusOfBorg>     * amd64: emacs25, emacs25-lucid, exult-studio, forensics-extra-gui, forensics-full, gegl, gimp, gimp-cbmplugs, gimp-dcraw, gimp-dds, gimp-gap, gimp-gluas, gimp-gmic, gimp-gutenprint, gimp-lensfun, gimp-normalmap, gimp-plugin-registry, gimp-python, gimp-texturize, gimp-ufraw, gnome, gnome-photos, gtkam-gimp, libgegl-0.4-0, libgegl-dev, libgimp2.0, libgimp2.0-dev, open-font-design-toolkit, pandora, pct-scanner-scripts,
<LocutusOfBorg> sane, sane-dbg, xsane, xsane-dbg
<LocutusOfBorg> probably only emacs25 is left, I don't know how pandora and similar are entangled
<LocutusOfBorg> doko, you missed to sync python-mockupdb, so python-motor testsuite started to fail
<LocutusOfBorg> (and waiting some hours might not hurt that much, we are close to the end after one month)
<jbicha> LocutusOfBorg: sure
<jbicha> sorry about that
<LocutusOfBorg> no problem, just feature freeze is approaching, lets not delay it further :)
<LocutusOfBorg> fortunately gegl didn't regress autopkgtests ;)
<acheronuk> and we are back at this:
<acheronuk>     got: 18+0: a-4:a-2:a-6:i-2:p-2:s-2
<acheronuk>     * armhf: emacs25, emacs25-lucid
<acheronuk> phew!
<wxl> XD
<wxl> i blame rms
<wxl> try hooking up the foot pedal
<tsimonq2> wxl: hahahahahahaha
<tsimonq2> It's funny to me that Emacs has reverse dependencies though.
<wxl> yeah, like linux
 * wxl ducks
 * tsimonq2 throws the Libre Foot Pedal at wxl
<wxl> fwiw i do occassionally use emacs (for clojure, in so-called "evil" mode-- emphasis on the vi)
<wxl> also i really love org_mode
<ahasenack> hi, me again, hoping to catch people in a better timezone :)
<ahasenack> could an archive admin please look at my squid-4.1 upload? It's a new source, that replaces squid3
<ahasenack> ubuntu used to have a source package called just "squid", without a version number, and then moved to "squid3"
<ahasenack> debian has moved squid (v4) from experimental to unstable, and the new source above is my merge for that
<ahasenack> it passed dep8 tests, manual tests, upgrade tests: https://code.launchpad.net/~ahasenack/ubuntu/+source/squid/+git/squid/+merge/353097 has details
<infinity> ahasenack: I'll have a poke later.
<ahasenack> thanks!
<infinity> ahasenack: I'll be mostly reviewing the delta from debian to ubuntu, and checking that it's all sanely represented in the changelog, so if that's not true, fix it before I get there. :)
<ahasenack> no, that should be good
<ahasenack> and it generates the same binaries
<ahasenack> (debs, I mean)
<ahasenack> the d/changelog looks a bit odd, though, because it doesn't have all the squid3 releases in it
<ahasenack> the ubuntu ones, I mean
<ahasenack> feel free to add comments to that mp or the bug
#ubuntu-release 2018-08-21
<xnox> tsimonq2, https://launchpad.net/ubuntu/+source/fraqtive/0.4.8-7 will never build on arm64 on ubuntu, because it needs gl and we have gles, no?
<xnox> tsimonq2, hence we need to remove arm64 binaries from cosmic-release, no?
<xnox> missing build on arm64: fraqtive (from 0.4.8-6)
<xnox> Depends: fraqtive qtbase-opensource-src
<xnox> Not considered
<tsimonq2> xnox: Yes.
<tsimonq2> You are correct.
<xnox> slangasek, ^^^^
<xnox> drop fraqtive/arm64 from cosmic-release
<xnox> gles
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.34.2 => 2.35] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.34.2+18.04 => 2.35+18.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.34.2~14.04 => 2.35~14.04] (no packageset)
<slangasek> xnox: fraqtive/arm64 removed
<tsimonq2> If emacs is candidate, I'm confused as to what else is left.
<tsimonq2> slangasek: Are you around/awake? Would be good to get a second set of eyes here...
<tsimonq2> Ah, I see your hints commit. Thanks!
<slangasek> tsimonq2: yeah, this is still a dry run which I expect is going to show failures still due to emacs25 binary packages; once I confirm that excluding emacsen-common dtrt, I'll make it a force-hint
<tsimonq2> slangasek: Awesome, thank you!
<slangasek> however, it's looking decreasingly likely that the necessary britney run will complete before I find myself needing to pass out
 * tsimonq2 slides slangasek a coffee
<tsimonq2> We're >< this close. ;)
<slangasek> doesn't help with the fact that I have early morning meetings
<tsimonq2> darn
<tsimonq2> slangasek: Is that a completed Britney run I see? ;)
<slangasek> yeah but it's the one from /before/ my hint was applied
<tsimonq2> ohh
<tsimonq2> I guess I should hit the hay too before my flight in 9 hours... thanks slangasek.
<slangasek> last run took 41min.  So there's still a chance of this finishing before I crash
<tsimonq2> OK
<doko> are syncs already turned off?
<tsimonq2> doko: To get this transition to migrate, yeah.
<doko> ahh, I see
<tsimonq2> I expect another couple of runs before the full DIF.
<tsimonq2> ...assuming the transition migrates ASAP. :P
<slangasek> there was mention of autosyncs being disabled during the transition mess.  I didn't notice mention of it when it was disabled, and no one commented in the crontab...
<tsimonq2> slangasek: L_ocutusOfBorg asked L_aney to turn it off; L_aney changed the topic right after he did it.
<slangasek> ok
<tsimonq2> slangasek: https://irclogs.ubuntu.com/2018/08/16/%23ubuntu-release.html#t09:26 has specifics if it's important to you.
<tsimonq2> ð´ o/
 * tsimonq2 hopes to be surprised with an inbox full of migration notices upon waking up... hehe
<doko> jbicha: pygobject ftbfs
<slangasek> ok that hint definitely didn't get us closer
<slangasek> so it'll have to wait until morning, or for someone else to decipher
<doko> slangasek: is this the combined ffmpeg/qt one?
<slangasek> yes
<doko> can you do something about the autopkg tests marked running, but which are not running?
<slangasek> anyone can, they can retry them
<slangasek> I can't right now, I'm going to bed
<doko> ok, not but not by the UI. will try
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1018.19]
<LocutusOfBorg> ./retry-autopkgtest-regressions --state RUNNING | vipe | xargs -rn1 -P10 wget --load-cookies ~/.cache/autopkgtest.cookie -O-
<LocutusOfBorg> 90 tests rerun
<LocutusOfBorg> slangasek good morning, please can you do the magic?
<LocutusOfBorg> I'll be afk, and feature freeze is getting closer...
<acheronuk> LocutusOfBorg: think Steve is asleep now
<doko> LocutusOfBorg: python-motor's tests still fail
<acheronuk> sil2100: can you perhaps help unstick the Qt/ffmpeg transition?
<acheronuk> or apw?
<acheronuk> sooooooooooooo near!
<sil2100> acheronuk: still not 100% available, but what needs doing?
<acheronuk> sil2100: we have:
<acheronuk>     got: 18+0: a-6:a-2:a-4:i-2:p-2:s-2
<acheronuk>     * amd64: emacs25, emacs25-lucid
<acheronuk> slangasek tried https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/3167
<acheronuk> sil2100: if there is not a clear solution to you quickly, then no worries
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-157.207] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-157.207]
<juliank> When will qtbase-opensource-src migrate?
<juliank> IIRC, it was a valid candidate for some time already
<juliank> but it still is
<acheronuk> juliank: hoping for later today. currently just one thing blocking it
<juliank> ok
<xnox> acheronuk, which is?
<xnox> doko, please promote src:emacs to main in cosmic-proposed.
<xnox> cause it needs to replace src:emacs25
<acheronuk> yes, emacs25 is the last
<doko> xnox: are the dependencies already promoted and bug subscribed?
<doko> anyway, prmoting
<xnox> based on https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html the dependencies are the same as existing emacs25
<xnox> doko, desktop packages is subscribed to src:emacs
<doko> xnox: xaw3dg is still in universe
<doko> I pinged -desktop about that weeks ago :-(
<doko> so somebody demoted emacs in the mean time ...
<xnox> ah, i see that now in http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<xnox> doko, but xaw3dg is only a dep of emacs-lucid aka emacs25-lucid which should stay in universe.
<xnox> doko, i believe we only want emacs-nox and emacs-gtk in main
<slashd> o/ sil2100, was there a specific reason why you didn't approve gmd3 for xenial yesterday ? Anything to do w/ the nvidia driver we discussed a little bit ?
<doko> xnox: demoted, but:
<doko> o emacs: emacs-el emacs-gtk-dbg emacs-lucid emacs-lucid-dbg emacs-nox-dbg
<doko>    [Reverse-Depends: Rescued from emacs, emacs-lucid-dbg]
<doko>    [Reverse-Recommends: emacs-common (MAIN)]
<xnox> doko, demote emacs-lucid-dbg too
<doko> Package: emacs
<xnox> and emacs-lucid on emacs is an alternative dep, not a hard one
<doko> Depends: emacs-gtk | emacs-lucid | emacs-nox
<doko> yes, already done
<xnox> yeah, so we don't need all three in main? or is components missmatches getting confused?
<sil2100> slashd: ah, no, apologies, simply got pulled in to something else, let me pick it up now
<slashd> sil2100, tks I appreciate it, wasn't sure it was made on purpose due to the nvidia driver discussion
<slashd> dgadomski, ^
-queuebot:#ubuntu-release- Unapproved: accepted gdm3 [source] (xenial-proposed) [3.18.3-0ubuntu2.2]
<slashd> dgadomski, ^
<sil2100> All good, accepted
<slashd> sil2100, thank you very much
-queuebot:#ubuntu-release- New source: ndctl (bionic-proposed/primary) [61.2-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- New source: pmdk (bionic-proposed/primary) [1.4.1-0ubuntu1~18.04.1]
<xnox> doko, *sigh* more demotions
<xnox> doko, please demote the transitional packages emacs23-lucid, emacs24-lucid, emacs25-lucid from the src:emacs
<doko> xnox: versions?
<xnox> 1:25.2+1-10
-queuebot:#ubuntu-release- New binary: healpix-cxx [s390x] (cosmic-proposed/universe) [3.40.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: healpix-cxx [ppc64el] (cosmic-proposed/universe) [3.40.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: healpix-cxx [amd64] (cosmic-proposed/universe) [3.40.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: healpix-cxx [i386] (cosmic-proposed/universe) [3.40.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: healpix-cxx [arm64] (cosmic-proposed/universe) [3.40.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: s390-tools [s390x] (cosmic-proposed/main) [2.6.0-0ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: healpix-cxx [armhf] (cosmic-proposed/universe) [3.40.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted s390-tools [s390x] (cosmic-proposed) [2.6.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted healpix-cxx [amd64] (cosmic-proposed) [3.40.0-2]
-queuebot:#ubuntu-release- New: accepted healpix-cxx [armhf] (cosmic-proposed) [3.40.0-2]
-queuebot:#ubuntu-release- New: accepted healpix-cxx [ppc64el] (cosmic-proposed) [3.40.0-2]
-queuebot:#ubuntu-release- New: accepted healpix-cxx [arm64] (cosmic-proposed) [3.40.0-2]
-queuebot:#ubuntu-release- New: accepted healpix-cxx [s390x] (cosmic-proposed) [3.40.0-2]
-queuebot:#ubuntu-release- New: accepted healpix-cxx [i386] (cosmic-proposed) [3.40.0-2]
<wxl> i'm a little green on interpreting the state of migration, but looking at calamares, it seems excuses has it set as a valid candidate. therefore it seems the only thing keeping it is that output is saying calamares-settings-ubuntu-common would break? cuz that seems strange.
<acheronuk> wxl: Depends: calamares qtbase-opensource-src
<wxl> uh that's what i feared
<acheronuk> so when it built, it picked up a dependency on Qt in proposed i.e. 5.11
<acheronuk> so it's stuck with Qt
<wxl> aren't we done with that yet? XD
<acheronuk> if you look at: https://launchpad.net/ubuntu/cosmic/amd64/calamares/3.2.1-1ubuntu3
<acheronuk> it says just that as depends: libqt5core5a (>= 5.11.0~rc1)
<acheronuk> wxl: I'm very temped to be 'done' with it :P
<acheronuk> *tempted
<ginggs> would someone please kick the yorick can along? 'force-badtest yorick/2.2.04+dfsg1-9build1' there are existing hints in ubuntu-release and l.aney's file
<wxl> acheronuk: any way i can be of help with it?
<acheronuk> wxl: now it's in archive admin/release team territory I think
<wxl> acheronuk: meaning problems too thorny for us plebs? :)
<acheronuk> wxl: and requiring superpowers we don't have
<tsimonq2> acheronuk: You mean slangasek territory? ;)
<tsimonq2> Â¯\_(ã)_/Â¯
<xnox> doko, yeah \o/ emacs is a candidate.
<xnox> slangasek,  Version mismatch, kstars 5:2.9.8-0ubuntu1 != 5:2.9.8-1ubuntu1
<xnox> Not using hint
<doko> octave needs to be a candidate as well. I removed some leaf packages, octave-statistics/i386 remains. ignore it?
<xnox> slangasek, please update your mega hint to see what else is stuck....
<ginggs> octave-statistics looks like floating point precision: Abs err 1.7764e-15 exceeds tol 0 by 2e-15
<doko> yep, removing, including a few rdeps
<doko> ginggs: could you file a bug report for Debian?
<ginggs> doko: ack
<sil2100> xnox: should I modify Steve's hint?
<ginggs> btw, octave-statistics was always-fail on i386 http://autopkgtest.ubuntu.com/packages/octave-statistics/bionic/i386 - it's a pity we cannot reset it back to that state
<doko> stgraber: your archive foo isn't go-ing, it's rusting ;p
<tsimonq2> sil2100: Please! :)
<xnox> sil2100, yes please! bump that one version number up please =)
<doko> sil2100: and please ignore the lxd failures. the the ubuntu-devel ML, starting with stgraber's mail
<doko> Apparently successful
<doko> final: atlas,cheetah,fftw3,h5py,hdf5,python-intervaltree-bio,python-numpy,s390-tools
-queuebot:#ubuntu-release- Unapproved: openscap (xenial-proposed/universe) [1.2.8-1 => 1.2.8-1ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: postfix (bionic-proposed/main) [3.3.0-1 => 3.3.0-1ubuntu0.1] (core)
<juliank> doko: I believe there's still some trouble with autopkgtest requests being "lost" (that is, test in progress) and/or the queue display is broken. Is that your opinion too?
<ahasenack> kstenerud: see "unapproved" msg from the bot above
<juliank> I think it's worth investigating this closely once we have import freeze, or a particular case we want to look at
<juliank> I retriggered some tests that are supposedly running
<doko> juliank: yes. somebody advised to give these back, although you can't find the line on update_excuses
<juliank> The machine was rebooted 1d8h ago
<juliank> and we don't have a persistant journal it seems
<juliank> So I think all logging before 1d8h ago is gone
<juliank> ugh, wrong machine
<sil2100> Done
<sil2100> I'll look at the lxd failures in a moment, since Stephane indeed mentioned these will get fixed with the next version
<juliank> So, it seems that, for example, for bzip2 triggering cdebootstrap/0.7.7ubuntu2, this never made it to the lxd worker which controls the arm tests
<juliank> the lxd worker is up since ~5.5 days
<juliank> which seems to be about the time the problems started
<slangasek> xnox: emacs had already been a candidate, what happened?
<slangasek> xnox: I'm not updating my hint, I'm dropping it - has no one looked to figure out what's happening with xemacs21?
-queuebot:#ubuntu-release- Unapproved: accepted ibm-java80 [source] (xenial-proposed) [8.0.5.17-0ubuntu1]
<doko> xnox: emacs-lucid emacs-lucid-dbg still want to promote
<doko> xemacs21 and friends removed
<xnox> slangasek, it was not a candidate this morning.
<xnox> doko, urgh
<slangasek> xnox: ok, I don't know why it wasn't, someone must have re-futzed with things that I had previously fixed
<slangasek> xnox: it was a candidate as of 1am my time :)
<xnox> doko, slangasek - well i just gonna say that componenets missmatches proposed is just wrong, cause emacs-lucid is not in main and nothing wants it in main....
<wxl> i just notice the live cd for lubuntu (and kubuntu, haven't tested others) has an empty menuentry in grub for "boot to first hard disk." what do i change to fix this?
<doko> I demoted it
<doko> the binar
<doko> y
<slangasek> xnox: -dbg packages from sources in main are all auto-promoted, emacs-lucid-dbg depends on emacs-lucid.  This needs an addition to the seed exclusion list
<xnox> diddims
<slangasek> xnox: will you add this or shall I?
<xnox> slangasek, please. i have not touched seeds with git yet
 * slangasek looks at xnox oddly
<wxl> O_O
<xnox> slangasek, i love bzr, did you not know? =) also i've been off for 2 weeks.... =)
 * slangasek waits another year for britney to pick up the xemacs21 removal and the octave block
<wxl> slangasek: you can always fix the qt business while you wait :)
<slangasek> wxl: no, it's precisely the output of the britney run that I'm waiting for in order to confirm the final contents of my force-hint
<wxl> oic :(
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1018.19~16.04.2] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1018.19~16.04.2]
<slangasek> ok, britney output confirmed, force-hint added
<slangasek> qt in an hour or so
<wxl> yay
 * wxl kisses slangasek 
<acheronuk> slangasek: \o/ thank you
<doko> octave fixed as well
<doko> version.h: #define OCTAVE_PATCH_VERSION 1-rc2
<doko> why are upstreams doing release candidates?
<tsimonq2> slangasek: SWEEET.
<acheronuk> 'run britney run'
<acheronuk> did that work? I see final: the list of hinted packages, and success after the force hint
<slangasek> oh? I don't see the force hint output on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt yet
<xnox> i'm looking at http://people.canonical.com/~ubuntu-archive/proposed-migration/log/cosmic/2018-08-21/17:59:38.log
<xnox> there is newly uninstallable emacs25-bin-common what not, fromt eh old emacs25 src
<slangasek> yes, that's expected
<xnox> orce breaks:
<xnox>     * amd64: emacs25-bin-common, emacs25-common, emacs25-el
<xnox>     * arm64: emacs25-bin-common
<xnox>     * armhf: emacs25-bin-common
<xnox>     * i386: emacs25-bin-common
<xnox>     * ppc64el: emacs25-bin-common
<xnox>     * s390x: emacs25-bin-common
<xnox> SUCCESS (596/0)
<xnox> i think it's all in.
<slangasek> yep, it's done.  I'll wait until it publishes and then rip emacs25 out
<acheronuk> slangasek: yeah, I was looking at the whole log
-queuebot:#ubuntu-release- Unapproved: snapcraft (bionic-proposed/universe) [2.42.1+18.04 => 2.43+18.04] (no packageset)
<slangasek> emacs25 removed
<slangasek> hints reverted
<acheronuk_> slangasek: thank you for the help and patience with Qt
<doko_> octave/amd64 unsatisfiable Depends: libqt5core5a (>= 5.11.0~rc1)
<doko_> octave/amd64 unsatisfiable Depends: libqt5widgets5 (>= 5.11.0~rc1)
<doko_> how's that?
<doko_> slangasek: is that fallout?
<doko_> got 95 migration messages
<slangasek> doko_: yeah that's probably because britney is done but the lp publisher hasn't caught up yet
<slangasek> since octave still has a way to go (failing autopkgtests etc), I'm going ahead and reenabling autosyncing now
<slangasek>     Start 1: unittests
<slangasek> 1/1 Test #1: unittests ........................***Failed    1.14 sec
<slangasek> 0% tests passed, 1 tests failed out of 1
<slangasek> thanks, dolfin
<ahasenack> infinity: hi, did you get a chance to look at squid?
<infinity> ahasenack: I didn't, but I will.  Scout's honor.
<ahasenack> infinity: cheers :)
-queuebot:#ubuntu-release- New binary: armadillo [ppc64el] (cosmic-proposed/universe) [1:9.100.5+dfsg-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: armadillo [s390x] (cosmic-proposed/universe) [1:9.100.5+dfsg-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: armadillo [amd64] (cosmic-proposed/universe) [1:9.100.5+dfsg-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: armadillo [i386] (cosmic-proposed/universe) [1:9.100.5+dfsg-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: claws-mail [s390x] (cosmic-proposed/universe) [3.17.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: armadillo [arm64] (cosmic-proposed/universe) [1:9.100.5+dfsg-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: claws-mail [ppc64el] (cosmic-proposed/universe) [3.17.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: armadillo [armhf] (cosmic-proposed/universe) [1:9.100.5+dfsg-1] (kubuntu)
-queuebot:#ubuntu-release- New binary: claws-mail [amd64] (cosmic-proposed/universe) [3.17.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fwupdate-i386-signed [i386] (cosmic-proposed/universe) [12+3] (no packageset)
-queuebot:#ubuntu-release- New binary: fwupdate-amd64-signed [amd64] (cosmic-proposed/universe) [12+3] (no packageset)
-queuebot:#ubuntu-release- New binary: fwupd-amd64-signed [amd64] (cosmic-proposed/universe) [1.1.1+1] (no packageset)
-queuebot:#ubuntu-release- New binary: claws-mail [i386] (cosmic-proposed/universe) [3.17.0-1] (no packageset)
<mwhudson> slangasek: /topic still says autosync disabled
#ubuntu-release 2018-08-22
-queuebot:#ubuntu-release- New binary: claws-mail [arm64] (cosmic-proposed/universe) [3.17.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: claws-mail [armhf] (cosmic-proposed/universe) [3.17.0-1] (no packageset)
* slangasek changed the topic of #ubuntu-release to: Released: Xenial 16.04.5, Bionic 18.04.1 | Archive: open | Cosmic Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melius malum quod cognoscis
<slangasek> mwhudson: fixed
<mwhudson> ta
<mwhudson> and congrats all on unblocking that!
-queuebot:#ubuntu-release- New binary: sndio [s390x] (cosmic-proposed/universe) [1.5.0-2] (kubuntu)
<wxl> lubuntu seems stuck in a rebuild state. tried to cancel to no avail.
-queuebot:#ubuntu-release- New binary: python-async-generator [amd64] (cosmic-proposed/universe) [1.10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-colored [s390x] (cosmic-proposed/universe) [1.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lloconv [s390x] (cosmic-proposed/universe) [6.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-constant-time-eq [s390x] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-hdmedians [s390x] (cosmic-proposed/universe) [0.13~git20171027.8e0e9e3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cookie-factory [s390x] (cosmic-proposed/universe) [0.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-mac [s390x] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pcap [s390x] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-termios [s390x] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-enum-primitive [s390x] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rusticata-macros [s390x] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-new-debug-unreachable [s390x] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ldc [i386] (cosmic-proposed/universe) [1:1.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-threadpool [s390x] (cosmic-proposed/universe) [1.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tokio-executor [s390x] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sndio [i386] (cosmic-proposed/universe) [1.5.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: sndio [ppc64el] (cosmic-proposed/universe) [1.5.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: sndio [amd64] (cosmic-proposed/universe) [1.5.0-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: stomper [amd64] (cosmic-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libnet-server-coro-perl [amd64] (cosmic-proposed/universe) [1.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: fwupd-i386-signed [i386] (cosmic-proposed/universe) [1.1.1+1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-sphinxcontrib.apidoc [amd64] (cosmic-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-em-websocket [amd64] (cosmic-proposed/universe) [0.5.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: lloconv [i386] (cosmic-proposed/universe) [6.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-colored [amd64] (cosmic-proposed/universe) [1.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-aes-key-wrap [amd64] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-gnuplotlib [amd64] (cosmic-proposed/universe) [0.22-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-constant-time-eq [amd64] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-enum-primitive [amd64] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-hdmedians [i386] (cosmic-proposed/universe) [0.13~git20171027.8e0e9e3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-constant-time-eq [i386] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: django-cas-server [amd64] (cosmic-proposed/universe) [0.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cookie-factory [amd64] (cosmic-proposed/universe) [0.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-new-debug-unreachable [i386] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lloconv [amd64] (cosmic-proposed/universe) [6.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rusticata-macros [amd64] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cookie-factory [i386] (cosmic-proposed/universe) [0.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-new-debug-unreachable [amd64] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rusticata-macros [i386] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: pbsuite [amd64] (cosmic-proposed/universe) [15.8.24+dfsg-3] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pcap [i386] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pcap [amd64] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tokio-executor [amd64] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tokio-executor [i386] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted django-cas-server [amd64] (cosmic-proposed) [0.9.0-1]
-queuebot:#ubuntu-release- New: accepted rust-constant-time-eq [amd64] (cosmic-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted rust-cookie-factory [amd64] (cosmic-proposed) [0.2.4-1]
-queuebot:#ubuntu-release- New: accepted rust-new-debug-unreachable [i386] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New binary: manuel [amd64] (cosmic-proposed/universe) [1.9.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-enum-primitive [i386] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-termios [amd64] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted lloconv [amd64] (cosmic-proposed) [6.1.0-2]
-queuebot:#ubuntu-release- New: accepted rust-cookie-factory [i386] (cosmic-proposed) [0.2.4-1]
-queuebot:#ubuntu-release- New binary: python-hdmedians [amd64] (cosmic-proposed/universe) [0.13~git20171027.8e0e9e3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-threadpool [amd64] (cosmic-proposed/universe) [1.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-constant-time-eq [i386] (cosmic-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New binary: rust-mac [amd64] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-rusticata-macros [amd64] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted fwupd-i386-signed [i386] (cosmic-proposed) [1.1.1+1]
-queuebot:#ubuntu-release- New: accepted libnet-server-coro-perl [amd64] (cosmic-proposed) [1.3-2]
-queuebot:#ubuntu-release- New: accepted python-gnuplotlib [amd64] (cosmic-proposed) [0.22-2]
-queuebot:#ubuntu-release- New: accepted python-hdmedians [s390x] (cosmic-proposed) [0.13~git20171027.8e0e9e3-1]
-queuebot:#ubuntu-release- New: accepted ruby-aes-key-wrap [amd64] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-colored [amd64] (cosmic-proposed) [1.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-cookie-factory [s390x] (cosmic-proposed) [0.2.4-1]
-queuebot:#ubuntu-release- New: accepted rust-enum-primitive [s390x] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-new-debug-unreachable [s390x] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rusticata-macros [s390x] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted ldc [i386] (cosmic-proposed) [1:1.11.0-1]
-queuebot:#ubuntu-release- New: accepted python-hdmedians [i386] (cosmic-proposed) [0.13~git20171027.8e0e9e3-1]
-queuebot:#ubuntu-release- New: accepted ruby-em-websocket [amd64] (cosmic-proposed) [0.5.1-2]
-queuebot:#ubuntu-release- New: accepted rust-enum-primitive [amd64] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-pcap [s390x] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-threadpool [s390x] (cosmic-proposed) [1.7.1-1]
-queuebot:#ubuntu-release- New: accepted sndio [amd64] (cosmic-proposed) [1.5.0-2]
-queuebot:#ubuntu-release- New: accepted sndio [ppc64el] (cosmic-proposed) [1.5.0-2]
-queuebot:#ubuntu-release- New binary: ccdiff [amd64] (cosmic-proposed/universe) [0.21-1] (no packageset)
-queuebot:#ubuntu-release- New binary: lloconv [ppc64el] (cosmic-proposed/universe) [6.1.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted lloconv [i386] (cosmic-proposed) [6.1.0-2]
-queuebot:#ubuntu-release- New: accepted rust-constant-time-eq [s390x] (cosmic-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted rust-termios [s390x] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted sndio [i386] (cosmic-proposed) [1.5.0-2]
-queuebot:#ubuntu-release- New binary: ldc [amd64] (cosmic-proposed/universe) [1:1.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-colored [ppc64el] (cosmic-proposed/universe) [1.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-sphinxcontrib.apidoc [amd64] (cosmic-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted rust-tokio-executor [s390x] (cosmic-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New binary: rust-colored [i386] (cosmic-proposed/universe) [1.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-mac [s390x] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New binary: rust-mac [i386] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted stomper [amd64] (cosmic-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted armadillo [arm64] (cosmic-proposed) [1:9.100.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted armadillo [i386] (cosmic-proposed) [1:9.100.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted armadillo [s390x] (cosmic-proposed) [1:9.100.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted claws-mail [arm64] (cosmic-proposed) [3.17.0-1]
-queuebot:#ubuntu-release- New: accepted claws-mail [i386] (cosmic-proposed) [3.17.0-1]
-queuebot:#ubuntu-release- New: accepted claws-mail [s390x] (cosmic-proposed) [3.17.0-1]
-queuebot:#ubuntu-release- New: accepted fwupdate-amd64-signed [amd64] (cosmic-proposed) [12+3]
-queuebot:#ubuntu-release- New: accepted lloconv [s390x] (cosmic-proposed) [6.1.0-2]
-queuebot:#ubuntu-release- New: accepted rust-colored [s390x] (cosmic-proposed) [1.6.1-1]
-queuebot:#ubuntu-release- New: accepted armadillo [amd64] (cosmic-proposed) [1:9.100.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted armadillo [ppc64el] (cosmic-proposed) [1:9.100.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted claws-mail [armhf] (cosmic-proposed) [3.17.0-1]
-queuebot:#ubuntu-release- New: accepted fwupd-amd64-signed [amd64] (cosmic-proposed) [1.1.1+1]
-queuebot:#ubuntu-release- New: accepted python-async-generator [amd64] (cosmic-proposed) [1.10-1]
-queuebot:#ubuntu-release- New binary: python-hdmedians [ppc64el] (cosmic-proposed/universe) [0.13~git20171027.8e0e9e3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-cookie-factory [ppc64el] (cosmic-proposed/universe) [0.2.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-termios [i386] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted armadillo [armhf] (cosmic-proposed) [1:9.100.5+dfsg-1]
-queuebot:#ubuntu-release- New: accepted claws-mail [ppc64el] (cosmic-proposed) [3.17.0-1]
-queuebot:#ubuntu-release- New: accepted sndio [s390x] (cosmic-proposed) [1.5.0-2]
-queuebot:#ubuntu-release- New binary: rust-enum-primitive [ppc64el] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted claws-mail [amd64] (cosmic-proposed) [3.17.0-1]
-queuebot:#ubuntu-release- New binary: rust-constant-time-eq [ppc64el] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted fwupdate-i386-signed [i386] (cosmic-proposed) [12+3]
-queuebot:#ubuntu-release- New binary: rust-threadpool [i386] (cosmic-proposed/universe) [1.7.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-new-debug-unreachable [ppc64el] (cosmic-proposed/universe) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-mac [ppc64el] (cosmic-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-pcap [ppc64el] (cosmic-proposed/universe) [0.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-termios [ppc64el] (cosmic-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-tokio-executor [ppc64el] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rusticata-macros [ppc64el] (cosmic-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-threadpool [ppc64el] (cosmic-proposed/universe) [1.7.1-1] (no packageset)
<slangasek> tsimonq2: hmm looks like the transition has helpfully made muon uninstallable, thereby breaking lubuntu image builds, because muon depends on the removed software-properties-qt
<slangasek> unclear how that was allowed to happen, but there you go
<wxl> ughhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
<wxl> isn't kubuntu using muon too?
<slangasek> I haven't seen; only lubuntu ftbfs so far
<wxl> acheronuk valorie ^^ might want to check kubuntu
<slangasek> anyway this was acheronuk_'s upload "Add breaks/replaces on software-properties-kde"
<slangasek> and software-properties-qt doesn't exist anywhere, it's not "removed"
<slangasek> lala is that in the new queue? checking
-queuebot:#ubuntu-release- New binary: ldc [armhf] (cosmic-proposed/universe) [1:1.11.0-1] (no packageset)
<slangasek> it is not
<wxl> which upload of acheronuk_'s was this?
<slangasek> of muon
<wxl> of muon?
<wxl> ah
<slangasek> and muon was in the megahint; I'm unclear why it wasn't reported as a regression in installability by britney
<wxl> it would make sense that we'd be on -qt
<wxl> we've been trying to -qt everything
<valorie>   uh, will read up
<valorie> hmmm, have muon installed
<wxl> i wouldn't expect a rebuilt on your image would succeed
<wxl> it's not about the recent past. this is news as of today
<wxl> and it's quite possible that if you had it already isntalled it would have no effect
<valorie> right
<wxl> (well, maybe. it'd probably ditch software-properties-kde)
<valorie> well, we provide muon but it is not installed by default
<wxl> might want to check that
<valorie> I also have software-properties-kde according to apt-cache
 * valorie is still on bionic
<wxl> dist-upgrade might remove it
<valorie> I usually use pkcon refresh && pkcon update but I'll try that
<wxl> i think if i were you, the #1 thing i would check is if you can build an image
<valorie> build what image?
<wxl> kubuntu cosmic dailies
<wxl> i.e. go to the iso qa tracker and trigger a rebuild
<valorie> ok
<valorie> sudo apt update && sudo apt full-upgrade ran OK
<valorie> rebuild requested
<sergiusens> slangasek: if around, mind rejecting my snapcraft (2.43+18.04) upload to bionic?
-queuebot:#ubuntu-release- New binary: fwupd-arm64-signed [arm64] (cosmic-proposed/universe) [1.1.1+1] (no packageset)
-queuebot:#ubuntu-release- New binary: fwupd-armhf-signed [armhf] (cosmic-proposed/universe) [1.1.1+1] (no packageset)
-queuebot:#ubuntu-release- New binary: fwupdate-armhf-signed [armhf] (cosmic-proposed/universe) [12+3] (no packageset)
<jbicha> slangasek: did software-properties 0.96.27 go missing or is the publisher just taking a while?
-queuebot:#ubuntu-release- New binary: openms [s390x] (cosmic-proposed/universe) [2.4.0-1] (no packageset)
<slangasek> jbicha: that version is marked as deleted
<slangasek> jbicha: ah, deleted because moved to release
<slangasek> hmm
<jbicha> except it never got there?
<slangasek> right, let's see
<slangasek> resuscitating
<slangasek> publisher certainly shouldn't take that long; not sure why it went missing
<valorie> hmmm, how long does it usually take to rebuild an ISO image?
<valorie> it's been over an hour and it's still "rebuilding"
-queuebot:#ubuntu-release- New binary: openms [ppc64el] (cosmic-proposed/universe) [2.4.0-1] (no packageset)
<jbicha> valorie: the build failed because the updated software-properties went missing, it might work now https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/cosmic/kubuntu
<wxl> jbicha: uh, we found it?
<jbicha> yes
<jbicha> https://launchpad.net/ubuntu/+source/software-properties/+publishinghistory
<wxl> weird
-queuebot:#ubuntu-release- New binary: openms [amd64] (cosmic-proposed/universe) [2.4.0-1] (no packageset)
<wxl> unfortunately i cant trigger a new rebuild because the iso qa tracker is convinced it's still rebuilding those images
-queuebot:#ubuntu-release- New binary: libcorona-perl [amd64] (cosmic-proposed/universe) [0.1004-4] (no packageset)
-queuebot:#ubuntu-release- New binary: openms [i386] (cosmic-proposed/universe) [2.4.0-1] (no packageset)
<tsimonq2> wxl: Then cancel the build before retrying.
<wxl> @tsimonq2: won't let me :(
<wxl> needs someone with super powers
<valorie> hmmm, me either
<valorie> thanks jbicha
<valorie> I cancelled but no change
-queuebot:#ubuntu-release- New: accepted libcorona-perl [amd64] (cosmic-proposed) [0.1004-4]
-queuebot:#ubuntu-release- New: accepted rust-colored [i386] (cosmic-proposed) [1.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-constant-time-eq [ppc64el] (cosmic-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted rust-enum-primitive [i386] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-mac [amd64] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-mac [ppc64el] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-new-debug-unreachable [ppc64el] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-pcap [i386] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-rusticata-macros [i386] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted rust-termios [amd64] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-termios [ppc64el] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-colored [ppc64el] (cosmic-proposed) [1.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-enum-primitive [ppc64el] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-new-debug-unreachable [amd64] (cosmic-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted rust-pcap [ppc64el] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-termios [i386] (cosmic-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted rust-threadpool [i386] (cosmic-proposed) [1.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-tokio-executor [amd64] (cosmic-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted rust-tokio-executor [ppc64el] (cosmic-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted rust-cookie-factory [ppc64el] (cosmic-proposed) [0.2.4-1]
-queuebot:#ubuntu-release- New: accepted rust-pcap [amd64] (cosmic-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted rust-threadpool [amd64] (cosmic-proposed) [1.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-tokio-executor [i386] (cosmic-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted rust-mac [i386] (cosmic-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-threadpool [ppc64el] (cosmic-proposed) [1.7.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rusticata-macros [ppc64el] (cosmic-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted ccdiff [amd64] (cosmic-proposed) [0.21-1]
-queuebot:#ubuntu-release- New: accepted ldc [armhf] (cosmic-proposed) [1:1.11.0-1]
-queuebot:#ubuntu-release- New: accepted manuel [amd64] (cosmic-proposed) [1.9.0-1]
-queuebot:#ubuntu-release- New: accepted python-hdmedians [amd64] (cosmic-proposed) [0.13~git20171027.8e0e9e3-1]
-queuebot:#ubuntu-release- New: accepted ldc [amd64] (cosmic-proposed) [1:1.11.0-1]
-queuebot:#ubuntu-release- New: accepted pbsuite [amd64] (cosmic-proposed) [15.8.24+dfsg-3]
-queuebot:#ubuntu-release- New: accepted lloconv [ppc64el] (cosmic-proposed) [6.1.0-2]
-queuebot:#ubuntu-release- New: accepted python-hdmedians [ppc64el] (cosmic-proposed) [0.13~git20171027.8e0e9e3-1]
-queuebot:#ubuntu-release- New: accepted fwupd-arm64-signed [arm64] (cosmic-proposed) [1.1.1+1]
-queuebot:#ubuntu-release- New: accepted fwupdate-armhf-signed [armhf] (cosmic-proposed) [12+3]
-queuebot:#ubuntu-release- New: accepted openms [i386] (cosmic-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted openms [s390x] (cosmic-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted fwupd-armhf-signed [armhf] (cosmic-proposed) [1.1.1+1]
-queuebot:#ubuntu-release- New: accepted openms [ppc64el] (cosmic-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted openms [amd64] (cosmic-proposed) [2.4.0-1]
<sarnold> ermagerd rust packages
<Ukikie> sarnold: You look rusty.
<sarnold> Ukikie: ura rust!
<sarnold> no, that doesn't really work does it..
-queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu7.4 => 1:2.11+dfsg-1ubuntu7.5] (ubuntu-server, virt)
<RAOF> It's time for another round of Distro vs Language Package Manager!
<acheronuk_> slangasek: nothing wrong with muon now? the software-properties-kde -> software-properties-qt replacement existed in proposed, and if publishing went ok should have been fine
<acheronuk_> hmm. iso tracker still showing lubuntu images as building
<wxl> kubuntu too
<acheronuk_> wxl: kubuntu failed as well
<acheronuk_> software-properties-kde not completely gone out of archive yet?
<acheronuk_> last recommends on the -kde package should be going soon. maybe that residual one is what caused the iso build conflict
-queuebot:#ubuntu-release- Unapproved: openvswitch (xenial-proposed/main) [2.5.4-0ubuntu0.16.04.1 => 2.5.5-0ubuntu0.16.04.1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (bionic-proposed/main) [1.3+18.04ubuntu2 => 1.4+18.04ubuntu2] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-image (xenial-proposed/universe) [1.3+16.04ubuntu2 => 1.4+16.04ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-image [source] (bionic-proposed) [1.4+18.04ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-image [source] (xenial-proposed) [1.4+16.04ubuntu1]
<infinity> Wed, 22 Aug 2018 08:46:58 +0000: Syncing AppStream metadata...
<infinity> rsync: failed to connect to appstream.internal (10.25.234.15): Connection refused (111)
<infinity> rsync error: error in socket IO (code 10) at clientserver.c(128) [Receiver=3.1.1]
<infinity> Oh, and Laney's not here to complain to.
<cjwatson> bet it didn't come up properly after a PS4.5 compute node reboot
<cjwatson> is that causing a publisher failure?
<cjwatson> ... no
<cjwatson> can probably wait until Iain's around then
-queuebot:#ubuntu-release- New binary: poppler [s390x] (cosmic-proposed/main) [0.68.0-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [amd64] (cosmic-proposed/main) [0.68.0-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [ppc64el] (cosmic-proposed/main) [0.68.0-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [i386] (cosmic-proposed/main) [0.68.0-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [arm64] (cosmic-proposed/main) [0.68.0-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: poppler [armhf] (cosmic-proposed/main) [0.68.0-0ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted poppler [amd64] (cosmic-proposed) [0.68.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [armhf] (cosmic-proposed) [0.68.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [ppc64el] (cosmic-proposed) [0.68.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [arm64] (cosmic-proposed) [0.68.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [s390x] (cosmic-proposed) [0.68.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted poppler [i386] (cosmic-proposed) [0.68.0-0ubuntu1]
<LocutusOfBorg> release team, why is automake-1.16 not in cosmic?
<LocutusOfBorg> I don't see it blacklisted...
<LocutusOfBorg> [New] automake-1.16_1:1.16.1-1
<LocutusOfBorg> No previous publications in Ubuntu
<LocutusOfBorg> OK (Y/n)?  y
<LocutusOfBorg>  * Trying to add automake-1.16 ...
<LocutusOfBorg> automake-1.16_1:1.16.1-1 is trying to override modified binary automake_1:1.15.1-3ubuntu2.  OK (y/N)?  n
<LocutusOfBorg> oh... lets do it then!
<LocutusOfBorg> it will go in new queue, so I leave to you the decision :)
<LocutusOfBorg> doko, what is your opinion? ^^
-queuebot:#ubuntu-release- New source: automake-1.16 (cosmic-proposed/primary) [1:1.16.1-1ubuntu1]
-queuebot:#ubuntu-release- New binary: airspyhf [i386] (cosmic-proposed/universe) [1.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: airspyhf [s390x] (cosmic-proposed/universe) [1.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: airspyhf [ppc64el] (cosmic-proposed/universe) [1.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: airspyhf [arm64] (cosmic-proposed/universe) [1.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: airspyhf [armhf] (cosmic-proposed/universe) [1.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-d3-dsv [amd64] (cosmic-proposed/none) [1.0.7-5] (no packageset)
-queuebot:#ubuntu-release- New binary: airspyhf [amd64] (cosmic-proposed/universe) [1.1.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: node-promise-retry [amd64] (cosmic-proposed/universe) [1.1.1-2] (no packageset)
<slashd> o/ rbasak do you have time to approve the upload of 'python-urllib3' for Xenial ? lp771988 thanks in advance
-queuebot:#ubuntu-release- New: accepted airspyhf [amd64] (cosmic-proposed) [1.1.5-1]
-queuebot:#ubuntu-release- New: accepted airspyhf [armhf] (cosmic-proposed) [1.1.5-1]
-queuebot:#ubuntu-release- New: accepted airspyhf [ppc64el] (cosmic-proposed) [1.1.5-1]
-queuebot:#ubuntu-release- New: accepted node-d3-dsv [amd64] (cosmic-proposed) [1.0.7-5]
-queuebot:#ubuntu-release- New: accepted airspyhf [arm64] (cosmic-proposed) [1.1.5-1]
-queuebot:#ubuntu-release- New: accepted airspyhf [s390x] (cosmic-proposed) [1.1.5-1]
-queuebot:#ubuntu-release- New: accepted airspyhf [i386] (cosmic-proposed) [1.1.5-1]
-queuebot:#ubuntu-release- New: accepted node-promise-retry [amd64] (cosmic-proposed) [1.1.1-2]
<LocutusOfBorg> can we please hint license-reconcile to make perl migrate, while waiting for a fix of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905614 ?
<ubot5> Debian bug 905614 in src:license-reconcile "FTBFS: Failed test 'no warnings' with libsoftware-license-perl 0.103013-2" [Serious,Open]
<LocutusOfBorg> it is just a warning
<rbasak> slashd, jamespage: am I right in thinking that bug 1771988 only affects Python 2 in Xenial, but you need that for OpenStack?
<ubot5> bug 1771988 in python-urllib3 (Ubuntu Xenial) "certificate validation with IP address based SAN's fails" [High,In progress] https://launchpad.net/bugs/1771988
<rbasak> Since AFAICT the needed support is already in libraries used in Python 3.5?
<jamespage> rbasak: yes that's correct - its a py2 only problem
<jamespage> the alternative is to fixup ssl in py2 I guess
<rbasak> Your existing approach is reasonable I think
<rbasak> Upstream have solved exactly this problem so might as well cherry-pick that.
<rbasak> I think we should be careful about testing urllib3 on Python 3 also though for SRU verification purposes.
-queuebot:#ubuntu-release- New: accepted automake-1.16 [source] (cosmic-proposed) [1:1.16.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-urllib3 [source] (xenial-proposed) [1.13.1-2ubuntu0.16.04.2]
-queuebot:#ubuntu-release- New: accepted cpdb-backend-file [source] (cosmic-proposed) [1.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: cpdb-backend-file [ppc64el] (cosmic-proposed/universe) [1.0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cpdb-backend-file [s390x] (cosmic-proposed/universe) [1.0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cpdb-backend-file [amd64] (cosmic-proposed/universe) [1.0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cpdb-backend-file [armhf] (cosmic-proposed/universe) [1.0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cpdb-backend-file [arm64] (cosmic-proposed/universe) [1.0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cpdb-backend-file [i386] (cosmic-proposed/universe) [1.0.1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted postfix [source] (bionic-proposed) [3.3.0-1ubuntu0.1]
-queuebot:#ubuntu-release- New: accepted cpdb-backend-file [amd64] (cosmic-proposed) [1.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted cpdb-backend-file [armhf] (cosmic-proposed) [1.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted cpdb-backend-file [ppc64el] (cosmic-proposed) [1.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted cpdb-backend-file [arm64] (cosmic-proposed) [1.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted cpdb-backend-file [s390x] (cosmic-proposed) [1.0.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted cpdb-backend-file [i386] (cosmic-proposed) [1.0.1-0ubuntu1]
<doko> tsimonq2: what happened to the proposal not to rebuild kde packages for the autopkg tests?
<LocutusOfBorg> doko, why not ask acheronuk ?
-queuebot:#ubuntu-release- New binary: llvm-defaults [s390x] (cosmic-proposed/universe) [0.42exp1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-defaults [ppc64el] (cosmic-proposed/universe) [0.42exp1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-defaults [amd64] (cosmic-proposed/universe) [0.42exp1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-defaults [arm64] (cosmic-proposed/universe) [0.42exp1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-defaults [armhf] (cosmic-proposed/universe) [0.42exp1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-defaults [i386] (cosmic-proposed/universe) [0.42exp1] (no packageset)
<doko> LocutusOfBorg: do you have the ok by the mesa maintainer to supported that? ^^^
<LocutusOfBorg> doko, mesa?
<doko> yes
<LocutusOfBorg> I don't get
<doko> it's the only user in main
<doko> did you make a test rebuild?
<LocutusOfBorg> I don't get what you mean
<LocutusOfBorg> I added two new binaries
<LocutusOfBorg> nobody is using them
<doko> ahh, no llvm 7 switch?
<LocutusOfBorg> no
<LocutusOfBorg> I want a "python-clang" tha defaults to "python-clang-6.0" and so on
<LocutusOfBorg> so we can runtime-depends on a meta-package and avoid cmake-extras failing testsuite
<LocutusOfBorg> I will probably add a liblld-dev package too
<LocutusOfBorg> for sure I'll sync llvm-toolchain-7 once it clears new
<LocutusOfBorg> but a transition to it is out of scope, for sure
-queuebot:#ubuntu-release- Unapproved: accepted chrony [source] (bionic-proposed) [3.2-4ubuntu4.2]
<slangasek> acheronuk: yeah, software-properties-qt resurrected successfully, thanks
<acheronuk> slangasek: great. do we happen to know why kubuntu and lubuntu daily cosmic iso are stuck on the iso tracker with status rebuilding, even though they failed?
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.42.1 => 2.43] (no packageset)
<slangasek> acheronuk: no idea
-queuebot:#ubuntu-release- Unapproved: snapcraft (bionic-proposed/universe) [2.42.1+18.04 => 2.43+18.04] (no packageset)
<acheronuk> ok. maybe they'll right themselves when next builds are normally triggered
-queuebot:#ubuntu-release- Unapproved: rejected snapcraft [source] (bionic-proposed) [2.43+18.04]
<slangasek> acheronuk: yeah, they're triggered by cron so there's no reason they wouldn't.  I would figure it's just a problem with error reporting back to the iso tracker
<acheronuk> cool. I'm in no hurry, and I think lubuntu one triggers in the next hr or 3 so we shall see
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.43]
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (bionic-proposed) [2.43+18.04]
<LocutusOfBorg> xnox, do you have any clue about this boost python import failure? https://launchpad.net/ubuntu/+source/python-escript/5.1-7
<LocutusOfBorg> is it what you were referring about the new python 3.7 boost mangling?
<wxl> is there any reason to think that when it's time to rebuild images for lubuntu that the stuck rebuilding status would cause a problem?
<slangasek> no
<slangasek> the cronjob doesn't care about the iso tracker's state
<xnox> LocutusOfBorg, well, it looks like it did not link with boost-python.... has it?
<wxl> @tsimonq2: i see that. would have restarted him, but no docs
<tsimonq2> wxl: ECHAN
<wxl> oh for god's sake
 * wxl goes back to finishing coffee number one
-queuebot:#ubuntu-release- New binary: debspawn [amd64] (cosmic-proposed/none) [0.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: leatherman [s390x] (cosmic-proposed/universe) [1.4.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: leatherman [ppc64el] (cosmic-proposed/universe) [1.4.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: octave-queueing [amd64] (cosmic-proposed/universe) [1.2.5-2] (no packageset)
-queuebot:#ubuntu-release- New binary: leatherman [i386] (cosmic-proposed/universe) [1.4.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: leatherman [armhf] (cosmic-proposed/universe) [1.4.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: leatherman [amd64] (cosmic-proposed/universe) [1.4.2+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: leatherman [arm64] (cosmic-proposed/universe) [1.4.2+dfsg-2] (no packageset)
<slangasek> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/amd64/g/glfw3/20180505_050452_71214@/log.gz ugh what a dumb autopkgtest failure
<LocutusOfBorg> slangasek, you *clearly* speeded over 88Mph
<LocutusOfBorg> you should go back to the future!
<LocutusOfBorg> xnox, debian has a lot of other similar issues, lets wait for them :)
-queuebot:#ubuntu-release- New: accepted debspawn [amd64] (cosmic-proposed) [0.1.0-1]
-queuebot:#ubuntu-release- New: accepted leatherman [arm64] (cosmic-proposed) [1.4.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted leatherman [i386] (cosmic-proposed) [1.4.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted leatherman [s390x] (cosmic-proposed) [1.4.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [arm64] (cosmic-proposed) [0.42exp1]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [i386] (cosmic-proposed) [0.42exp1]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [s390x] (cosmic-proposed) [0.42exp1]
-queuebot:#ubuntu-release- New: accepted leatherman [amd64] (cosmic-proposed) [1.4.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted leatherman [ppc64el] (cosmic-proposed) [1.4.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [armhf] (cosmic-proposed) [0.42exp1]
-queuebot:#ubuntu-release- New: accepted octave-queueing [amd64] (cosmic-proposed) [1.2.5-2]
-queuebot:#ubuntu-release- New: accepted leatherman [armhf] (cosmic-proposed) [1.4.2+dfsg-2]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [ppc64el] (cosmic-proposed) [0.42exp1]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [amd64] (cosmic-proposed) [0.42exp1]
<LocutusOfBorg> xnox,
<LocutusOfBorg> objdump  -T /usr/lib/x86_64-linux-gnu/libboost_python.so   |grep _ZTVN5boost6python17error_already_setE
<LocutusOfBorg> 00000000000432f8  w   DO .data.rel.ro	0000000000000020  Base        _ZTVN5boost6python17error_already_setE
<LocutusOfBorg> I added the link to libbost_python, same errr
<LocutusOfBorg> oh well, it doesn't get added
<LocutusOfBorg> meh
<slangasek>         retryer_test.go:30: expected duration to be between 1 and 2, but received 1.036422058s
<slangasek> can't argue with that
<ahasenack> :)
<slangasek> lol @ http://autopkgtest.ubuntu.com/packages/r/ruby-concurrent/cosmic/armhf , if someone wants to figure out why we're getting a signed hex output only on armhf...
<acheronuk> wxl tsimonq2: your iso built?
<wxl> acheronuk: looks like it. and somehow we're on a .1
<acheronuk> maybe queued a request?
<wxl> maybe
<slangasek> I did a test rebuild yesterday, probably after 0000 UTC
<wxl> so where do i go to fix this issue with the live image's grub screen not having a valid menuentry for booting to the first disk?
<slangasek> the grub menu is created in https://code.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu
<slangasek> tdaitx: is https://launchpad.net/ubuntu/+source/libcommons-lang3-java/3.7-1/+build/14825006 on your radar? also blocks other packages which are dep-wait on the new version
<slangasek> (e.g. surefire)
<tdaitx> slangasek: yes, libcommons java is on my list (it is one of the outdated packages and I saw it stuck in proposed)
<wxl> sigh. between trusty and xenial nothing about the menu entry for booting the first hard disk has changed and yet one works and one doesn't.
<wxl> might be grub itself. trusty likes `localboot 0x80`, current doesn't
<slangasek> wxl: so, the grub boot menu is only shown if you are booting under UEFI.  Perhaps 'localboot 0x80' doesn't mean what it says under UEFI? (considering 0x80 is a BIOS drive identifier)
<slangasek> cyphermox: ^^ any insight?
<wxl> slangasek: i'm also investigating whether or not it's a problem only on virtualbox. thta might be a thing too :/
<slangasek> ah
<slangasek> is the install media attached to the VM as a CD-ROM or as a HD?
<slangasek> that would also make a difference
<wxl> cd
<slangasek> ok, then I'd be surprised if it's virtualbox-specific, especially if it works in trusty but not in xenial
<wxl> probably not, but i won't exclude the possibility.
<wxl> what's weird is i'm NOT using efi mode
<slangasek> you're not using EFI mode, but you get a grub boot menu?
<wxl> yep
<slangasek> BIOS boot should be giving you isolinux
<cyphermox> indeed.
<cyphermox> grub boot menu with the menu list entries, or a prompt?
-queuebot:#ubuntu-release- New binary: ries [amd64] (cosmic-proposed/universe) [2018.04.11-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ries [s390x] (cosmic-proposed/universe) [2018.04.11-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ries [ppc64el] (cosmic-proposed/universe) [2018.04.11-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ries [amd64] (cosmic-proposed) [2018.04.11-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted ries [s390x] (cosmic-proposed) [2018.04.11-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted ries [ppc64el] (cosmic-proposed) [2018.04.11-1ubuntu1]
<wxl> ubuntu: BIOS boot = no menus unless you hit shift and then booting first disk fails; EFI = non-graphical GRUB menu with no option to boot to hard disk
<wxl> lubuntu: BIOS boot = graphical GRUB menu and then booting first disk fails; EFI = non-graphical GRUB menu with no option to boot to hard disk
<cyphermox> that's so very odd
<cyphermox> wxl: can you take screenshot?
<wxl> oh which? :)
<cyphermox> I'm sorry but this is confusing and I want to make sure we're all talking about the same thing :)
<cyphermox> of the boot menu in lubuntu BIOS boot, I think
<wxl> ok. it looks super ugly, so i'll warn you XD
<cyphermox> and then booting the first disk fails is a different thing we'll need to figure out
<wxl> https://share.riseup.net/#j7CtPj7ISAlm4PmsM6eMMw
<cyphermox> ok, yes
<slangasek> that's not grub
<cyphermox> bah
<slangasek> F1-F6 at the bottom are isolinux
<wxl> oh really? ok, that's nuts.
<cyphermox> ok, so 'localboot 0x80' doesn't work
<wxl> ubuntu gets a similar menu IF you hit shift on boot
<cyphermox> wxl: yep
<slangasek> which should also be not-grub
<cyphermox> well, the behavior difference is more important
<cyphermox> wxl: for lubuntu, do you want shift?
<slangasek> that's not the issue he was trying to debug
<wxl> i don
<cyphermox> no, but since we're there.
<wxl> 't really care whether or not it boots to that menu
<wxl> well, we might care
<slangasek> Ubuntu not showing the detailed menu by default is by design
<cyphermox> yep
<cyphermox> you get the little accesibility icon, then it boots to maybe-ubiquity
<wxl> if i had to be put on the spot, i'd say it would be better to stay consistent with everything else (kubuntu is the same as ubuntu)
<wxl> however we don't use ubiquity in cosmic so that might be a thing
<cyphermox> wxl: it's up to you, I had done rework on the timeouts, and didn't change the shift behavior that was already there.
<slangasek> yeah, you'll want to talk to tsimonq2, he landed changes to the lubuntu boot options in cosmic specifically around this
<wxl> so for now, i'd just leave well enough alone unless you want to run the risk of going down a rabbit hole
<cyphermox> ah, well is tsimonq also made changes ;)
<wxl> hahahah
<cyphermox> at least it's not all my fault ;)
<cyphermox> ok, so localboot
<wxl> yep
<slangasek> anyway, 'localboot 0x80' is clearly being written into the isolinux config, not to a grub config, so now I don't feel bad for not recognizing that grub command
<cyphermox> slangasek: that's in fact why it's not in the grub menu either, I couldn't think of a way to do it at the time, aside from really ugly chainloading of some sort
<wxl> yeah and i can't profess to really grok either grub or syslinux/isolinux well at all
<wxl> it would be nice to have the option in the menu for grub, at least for the efi folks
<slangasek> cyphermox: maas has solved this problem w/ netboot grub, we could copy from them now ;)
<wxl> or if it's problematic, just remove it altogether
 * wxl shrugs
<cyphermox> slangasek: yes, I think now it would be mostly copy-pasta
<cyphermox> I'll card that
<wxl> it's surprising no one had noticed this at least over the last two years
<cyphermox> wxl: how did your test of localboot go outside vbox?
<cjwatson> localboot 0x80 has never been totally reliable
<cjwatson> it's a best effort that depends on details of how the BIOS works
<wxl> still working on it. one sec
<cjwatson> historically, it's been reliable enough to be worth including, but not something that's ever been 100%
<cyphermox> cjwatson: I suspect syslinux only because rebuilding now against a new gnu-efi makes syslinux blow up.
<cjwatson> unsurprising I guess
<wxl> look at the sysloinux docs it still seems like localboot 0x80 is the right thing for isolinux
<cyphermox> wxl: virtualbox is special though :)
<wxl> that's why i was thinking it might be the issue
<wxl> cyphermox: failed :(
<cyphermox> boo
<wxl> yeah. it usually helps to blame virtualbox. always sucks when you can't ;)
<cyphermox> I'll have a shot here on some systems, see if it just never works for some reason
<wxl> thanks for the help. if you need anything else from me, let me know
<cyphermox> 18.04 first though
-queuebot:#ubuntu-release- New binary: pushover [s390x] (cosmic-proposed/universe) [0.0.5+git20180420-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: pushover [ppc64el] (cosmic-proposed/universe) [0.0.5+git20180420-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: pushover [armhf] (cosmic-proposed/universe) [0.0.5+git20180420-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: pushover [arm64] (cosmic-proposed/universe) [0.0.5+git20180420-2ubuntu1] (no packageset)
<valorie> hmmm, when is that cron supposed to trigger new cosmic dailies?
<valorie> Kubuntu Desktop amd64 still shows (re-building)
-queuebot:#ubuntu-release- New binary: pushover [amd64] (cosmic-proposed/universe) [0.0.5+git20180420-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: pushover [i386] (cosmic-proposed/universe) [0.0.5+git20180420-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pushover [amd64] (cosmic-proposed) [0.0.5+git20180420-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted pushover [armhf] (cosmic-proposed) [0.0.5+git20180420-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted pushover [ppc64el] (cosmic-proposed) [0.0.5+git20180420-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted pushover [arm64] (cosmic-proposed) [0.0.5+git20180420-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted pushover [s390x] (cosmic-proposed) [0.0.5+git20180420-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted pushover [i386] (cosmic-proposed) [0.0.5+git20180420-2ubuntu1]
#ubuntu-release 2018-08-23
<mwhudson> can someone reject base-files 10.1ubuntu2.2 from bionic UNAPPROVED please
-queuebot:#ubuntu-release- Unapproved: base-files (bionic-proposed/main) [10.1ubuntu2.2 => 10.1ubuntu2.3] (core)
<slangasek> doko: heh, fwiw binutils-mingw-w64 8ubuntu1 apparently has a completely broken library search path (openat(AT_FDCWD, "no/usr/i686-w64-mingw32/lib/libkernel32.dll.a", O_RDONLY) = -1 ENOENT (No such file or directory))
-queuebot:#ubuntu-release- New binary: 389-ds-base [amd64] (cosmic-proposed/universe) [1.4.0.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: 389-ds-base [s390x] (cosmic-proposed/universe) [1.4.0.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: 389-ds-base [i386] (cosmic-proposed/universe) [1.4.0.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: 389-ds-base [ppc64el] (cosmic-proposed/universe) [1.4.0.15-1] (no packageset)
-queuebot:#ubuntu-release- New source: octave-statistics (cosmic-proposed/primary) [1.4.0-2ubuntu1]
-queuebot:#ubuntu-release- New binary: 389-ds-base [arm64] (cosmic-proposed/universe) [1.4.0.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: 389-ds-base [armhf] (cosmic-proposed/universe) [1.4.0.15-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted 389-ds-base [amd64] (cosmic-proposed) [1.4.0.15-1]
-queuebot:#ubuntu-release- New: accepted 389-ds-base [armhf] (cosmic-proposed) [1.4.0.15-1]
-queuebot:#ubuntu-release- New: accepted 389-ds-base [ppc64el] (cosmic-proposed) [1.4.0.15-1]
-queuebot:#ubuntu-release- New: accepted 389-ds-base [arm64] (cosmic-proposed) [1.4.0.15-1]
-queuebot:#ubuntu-release- New: accepted 389-ds-base [s390x] (cosmic-proposed) [1.4.0.15-1]
-queuebot:#ubuntu-release- New: accepted 389-ds-base [i386] (cosmic-proposed) [1.4.0.15-1]
-queuebot:#ubuntu-release- New: accepted octave-statistics [source] (cosmic-proposed) [1.4.0-2ubuntu1]
-queuebot:#ubuntu-release- New binary: octave-statistics [amd64] (cosmic-proposed/universe) [1.4.0-2ubuntu1] (no packageset)
<ginggs> please accept octave-statistics ^
-queuebot:#ubuntu-release- New: accepted octave-statistics [amd64] (cosmic-proposed) [1.4.0-2ubuntu1]
<ginggs> ta!
-queuebot:#ubuntu-release- Unapproved: libvirt (bionic-proposed/main) [4.0.0-1ubuntu8.3 => 4.0.0-1ubuntu8.4] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (bionic-proposed) [4.0.0-1ubuntu8.4]
-queuebot:#ubuntu-release- Unapproved: accepted gpgme1.0 [source] (bionic-proposed) [1.10.0-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (bionic-proposed) [3.28.1-0ubuntu4.18.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted rkhunter [source] (bionic-proposed) [1.4.6-2~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (bionic-proposed/multiverse) [5.2.10-3ubuntu18.04.1 => 5.2.10-3ubuntu18.04.2] (no packageset)
<LocutusOfBorg> please reject it ^^
<LocutusOfBorg> I fixed twice the same old bug :/
<abeato> hey, who is archive admin?
<santa_> doko: re: kde autopkgtests - my idea was moving some autopkgtests to debian/rules but I couldn't complete the research properly yet. I wanted to do it in the beginning of the cosmic cycle but I had to fix our automatic tooling to handle the debian merges first
<santa_> now that we have proper tooling to handle the merges we could try to give it another shot in the next cycle, after doing  the debian merges with the tooling which, by  now, actually works
<lotuspsychje> hey guys we having gnome-shell-common held back when updating system in bionic
<lotuspsychje> anyone working on that?
<lotuspsychje> another user reported tty after a reboot
 * bogusjokes did that
<lotuspsychje> tnx for reporting bogusjokes
<bogusjokes> i checked the apply upgrades box on reboot, it applied gnome-shell and gnome-shell-common from -upgrades, but libmutter-2-0 is stuck on older version so dependency broke and it only boots into tty now
<LocutusOfBorg> tjaalton, syncpackage -f dogtag-pki, right?
<tjaalton> LocutusOfBorg: just did
<LocutusOfBorg> <3
<LocutusOfBorg> lovely thanks
<LocutusOfBorg> this should unblock some stuff :D
<tjaalton> we'll see..
<seb128> lotuspsychje, why is it hold back? could you pastebin a log? what package would be removed if you installed the upgrade?
<lotuspsychje> seb128: https://hastebin.com/logurubimu.rb
<bogusjokes> it needs to be hold back seb128! it applied for me but since it requires a newer version of libmutter-2-0 than is in the -upgrades repository the whole installation breaks if it upgrades, as it did for me
<seb128> lotuspsychje, what happens if you apt install that one?
<lotuspsychje> lets c
<bogusjokes> The following packages have unmet dependencies:
<bogusjokes>  gnome-shell : Depends: libmutter-2-0 (>= 3.28.3-1~ubuntu18.04.1) but 3.28.2-2~ubuntu18.04.1 is to be installed
<lotuspsychje> seb128: https://hastebin.com/elaxagiyiz.rb
<bogusjokes> libmutter-2-0 3.28.3 has to be pushed to -updates archive, since gnome-shell 3.28.3 is there and requires it
<lotuspsychje> better not proceed right? remove ubuntu-desktop?
<seb128> right
<seb128> seems like the SRU team moved gnome-shell alone and they should have been going together
<seb128> I don't think our tools make those case options to the SRU reviewers :/
<seb128> SRU team ^
<bogusjokes> https://paste.ubuntu.com/p/ttT8jBWySx/
<bogusjokes> but might it be a problem with the checkbox for applying updates in gnome when rebooting, since it's hold back with apt and update tool?
<jbicha> sil2100: do you want to push mutter into bionic-updates now or we do we need to phase gnome-shell down to 0%?
<seb128> bogusjokes, that checkbox shouldn't exist/be used, it doesn't work on debian/ubuntu since the offline mode doesn't handle debconf
<seb128> there is a gnome-software SRU in proposed that make it not show, it was displayed by error in some corner cases
<bogusjokes> seb128: well, i sure used it and it applied the gnome-shell updates for my installation :D
<seb128> how is that incompatible with what I wrote?
<bogusjokes> it's not, but it's there, and people use it
<seb128> right, that's a bug which has a fix in bionic-proposed
<bogusjokes> sweet
<seb128> but also the gnome-shell SRU is in a buggy state, which normal apt dist-upgrade users would hit as well
<seb128> that's more the problem and what is urgent to fix
<seb128> infinity, apw, bdmurray_, slangasek, stgraber, sil2100, ^ someone please do something before it hits more users?
<sil2100> I'm around now, let me see the backlog
<sil2100> argh
<sil2100> I guess I'll phase gnome-shell down to 0% since mutter doesn't have 3 bugs verified
<sil2100> But I would prefer if we got mutter out in the nearest 24h
<sil2100> Can anyone help verify mutter?
<sil2100> Ok, two of those are crash fixes, but the monitor one needs verification
<jbicha> since update-manager is the only thing that respects phasing, that still wouldn't help the one who got the update presented in gnome-software :(
<sil2100> Yeah, this is why 24 hours for getting mutter released or I revert gnome-shell
<sil2100> Damn -proposed
<jbicha> Trevinho: are you able to verify the fix for bug 1784398?
<ubot5> bug 1784398 in mutter (Ubuntu Bionic) "Changing monitor settings crashes on meta_window_wayland_move_resize_internal" [Undecided,Fix committed] https://launchpad.net/bugs/1784398
<sil2100> Phasing set to 0
<seb128> jibel, ^can you help?
<seb128> sil2100, those are just e.u.c report, not obvious testing to do/follow, worth case they are not fixed but that's not a reason to block the SRU if there are no regression
<seb128> and verifying those 3 fixes isn't going to tell you if there are no regression
<seb128> so basically what's the point?
<sil2100> That's why I just wanted the monitor one verified
<sil2100> But I guess we can do without that
<sil2100> The change for the monitor one is small enough that I guess I'll just release it as sis
-queuebot:#ubuntu-release- New source: initramfs-tools-devices (cosmic-proposed/primary) [0.1]
<seb128> well, let's see if Trevinho or jibel can help today
<seb128> block it 0% meanwhile
<seb128> and unblock later/tomorrow
<Trevinho> jbicha: mh no, Laney was affected... But I never noticed that
<ogra> abeato, https://launchpad.net/ubuntu/cosmic/+queue now find an archive-admin ;)
<Trevinho> seb128: well that wasn't either a e.u.c was related to a Laney issue at debconf
<Trevinho> seb128: while e.u.c are quite easier as if the package stays in proposed for a couple of weeks we can easily notice that there are no issues for such version. It's not 100% accurate as proposed is used by less people, but in general I'm quite confident in using those stats.
<jbicha> the monitor patch is from the gnome-3-28 branch but hasn't made it into a 3.28 release yet
<Trevinho> in case it won't be the case, we can just re-mark the bug, but otherwise I think it's the best way to go
<Trevinho> jbicha: yep...
 * abeato re-posts https://launchpad.net/ubuntu/cosmic/+queue and waits for slangasek ...
<abeato> ogra, thanks a lot
<ogra> np
<sil2100> Trevinho: ok, I'll take another quick look at e.u.c and if all looks good I'll release mutter as is
<ogra> abeato, did you base your -core package on the PPA one ? (thats far ahead, the archive one has not been touched for at least one release)
<abeato> ogra, no, in the one in the archive I'm afraid
<ogra> if not, we need to sync
<ogra> ouch ... k
<ogra> (given that there wont be an ubuntu-core 18.10 this isnt a biggie indeed
<ogra> )
<abeato> yeah, I forgot about the core ppa :/
<ogra> well, core images will only happen for 16 or 18
<ogra> (which means 18.04)
<ogra> so nothing will break
<ogra> but we should sync that code into the archive nontheless
<Trevinho> sil2100: good, thanks
<ogra> abeato, we need to make sure that -devices gets the latest resize from the PPA right after it got out of NEW though to make sure you use the latest fixes
<abeato> ogra, yup, will upload a debdiff as soon as that happens
<ogra> yeah ... just ping me, happy to sponsor that
<abeato> ogra, but we need -devices in main and it is in universe in the queue
<ogra> yes, all packages enter through universe
<abeato> aha, ok
<ogra> it will need to either go into some seed or some main package needs to depend on it to make it want to move over (and then it also needs manual ACKing)
<ogra> ... but first it needs to go through NEW
<abeato> I see, after it moves in we can make it enter main with the change initramfs-tools-ubuntu-core, that makes it depend on -devices
<abeato> s/change/change in/
<ogra> i uploaded that alongside btw
<ogra> (you should have gotten mail=
<ogra> )
<abeato> nice!
<abeato> but no email yet :p
<ogra> weird, i got them immediately, for both packages
 * ogra wonders if the archive stopped mailing the person in "Changed-By:" ... 
<ogra> or perhaps i just mis-remember ... havent uploaded a deb in ages :)
-queuebot:#ubuntu-release- New binary: golang-github-canonicalltd-raft-test [amd64] (cosmic-proposed/universe) [0.0~git20180628.c3345b5-1] (no packageset)
<ahasenack> hi, sssd now has a component mismatch: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sssd
<ahasenack> python-sss comes from the same source, but is in universe. Could an archive admin please move it to main, where sssd is?
<ahasenack> where sssd-tools* is
<ahasenack> (and sssd)
-queuebot:#ubuntu-release- New binary: vala [s390x] (cosmic-proposed/universe) [0.41.92-0build1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [ppc64el] (cosmic-proposed/universe) [0.41.92-0build1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [i386] (cosmic-proposed/universe) [0.41.92-0build1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [amd64] (cosmic-proposed/universe) [0.41.92-0build1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [arm64] (cosmic-proposed/universe) [0.41.92-0build1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: vala [armhf] (cosmic-proposed/universe) [0.41.92-0build1] (ubuntu-desktop)
<Trevinho> sil2100: thanks for relasing :)
<Trevinho> releasing*
<sil2100> yw!
-queuebot:#ubuntu-release- Unapproved: cryptsetup (bionic-proposed/main) [2:2.0.2-1ubuntu1 => 2:2.0.2-1ubuntu1.1] (core)
-queuebot:#ubuntu-release- New: accepted golang-github-canonicalltd-raft-test [amd64] (cosmic-proposed) [0.0~git20180628.c3345b5-1]
-queuebot:#ubuntu-release- New: accepted vala [arm64] (cosmic-proposed) [0.41.92-0build1]
-queuebot:#ubuntu-release- New: accepted vala [i386] (cosmic-proposed) [0.41.92-0build1]
-queuebot:#ubuntu-release- New: accepted vala [s390x] (cosmic-proposed) [0.41.92-0build1]
-queuebot:#ubuntu-release- New: accepted vala [amd64] (cosmic-proposed) [0.41.92-0build1]
-queuebot:#ubuntu-release- New: accepted vala [ppc64el] (cosmic-proposed) [0.41.92-0build1]
-queuebot:#ubuntu-release- New: accepted vala [armhf] (cosmic-proposed) [0.41.92-0build1]
<tkamppeter> The autopkg tests on the build servers stopped working, only the tests on ppc64el and s390x are actually running.
<xnox> tkamppeter, that is not true
<xnox> tkamppeter, why/how do you assert that?
<xnox> yesterday queues on all arches were above 1.5k, now they are about 0.5k everywhere, so clearly 1000s of tests across all arches have executed over the past 48h
<xnox> based on KPI stats, it is expected to clear over the weekend.
<xnox> private stats are in e.g. https://cdo.okr.canonical.com/d/000000030/ubuntu-foundations?panelId=19&fullscreen&orgId=1
<xnox> ppc64el is simply the fastest/more hardware we have, then s390x, then intel, than arms.
<tkamppeter> On http://people.canonical.com/~ubuntu-archive/proposed-migration/cosmic/update_excuses.html#gutenprint
<tkamppeter> http://people.canonical.com/~ubuntu-archive/proposed-migration/cosmic/update_excuses.html
<xnox> look at http://autopkgtest.ubuntu.com/running where in the queue the tests are....
<acheronuk> tkamppeter: ppc64el and s390x run a great deal quicker than other arches, so they clear their test backlog much sooner. that is all
<tkamppeter> Most tests show amd64: Test in progress, arm64: Test in progress, armhf: Test in progress, i386: Test in progress, ppc64el: Pass, s390x: Pass
<xnox> tkamppeter, yes, because there is 18k of tests to run for KDE stack that was uploaded two days ago.....
<acheronuk> and test in progress includes when they are queued
<tkamppeter> Especially cpdb-libs is stuck in this state since yesterday.
<tkamppeter> xnox, OK, then I understand.
<xnox> tkamppeter, please open http://autopkgtest.ubuntu.com/running and ctrl-f the package you want, to see how much tests are scheduled ahead of it.
<xnox> tkamppeter, there you can also check up as it bubbles up.
<xnox> tkamppeter, some tests do get lost - but wait for the queues to be all empty on http://autopkgtest.ubuntu.com/running to retrigger anything that is "not running, not in the queue to run, in-progress state" but i expect that only by like monday or tuesday.
<xnox> most likely it will just clear by monday.
-queuebot:#ubuntu-release- Unapproved: accepted fonts-liberation [source] (bionic-proposed) [1:1.07.4-7ubuntu0.18.04.1]
<slangasek> seb128, sil2100: is gnome-shell + mutter stabilized now?  Should I be rolling back gnome-shell in the -updates pocket as well?
-queuebot:#ubuntu-release- Unapproved: accepted fonts-liberation2 [source] (bionic-proposed) [2.00.1-7ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: maas (bionic-proposed/main) [2.4.0-6981-g011e51b7a-0ubuntu1~18.04.1 => 2.4.2-7034-g2f5deb8b8-0ubuntu1] (ubuntu-server)
<sil2100> slangasek: should be all good now
<ahasenack> fyi, I'm chasing down the paramiko dep8 failures. They are happening because the tarball is lacking the *.pub files that testsuse. The github paramiko release tarball has them, but the pypi one does not. I'm asking in #paramiko
<ahasenack> https://pastebin.ubuntu.com/p/GKgxv64t2K/ shows the missing files
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (trusty-proposed/main) [4.15.0-1022.22~14.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (trusty-proposed) [4.15.0-1022.22~14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.7]
-queuebot:#ubuntu-release- Unapproved: rejected tkblt [source] (bionic-proposed) [3.2.7-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected base-files [source] (bionic-proposed) [10.1ubuntu2.2]
<tjaalton> could an archive admin remove cockpit-389-ds armhf deb?
-queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (bionic-proposed) [18.04.14.7]
-queuebot:#ubuntu-release- Unapproved: maas (xenial-proposed/main) [2.3.4-6508-g4f77e30-0ubuntu1 => 2.3.5-6511-gf466fdb-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (bionic-proposed) [0.96.24.32.5]
<lotuspsychje> seb128: ping me if i have to test the updates on bionic
-queuebot:#ubuntu-release- Unapproved: accepted cryptsetup [source] (bionic-proposed) [2:2.0.2-1ubuntu1.1]
<lotuspsychje> sil2100 seb128 ok system updating here, new kernels and gnome-shell upgrading lookin good
<seb128> lotuspsychje, thx
<lotuspsychje> +1 for the fix guys
<ahasenack> fix for the paramiko dep8 failures: https://code.launchpad.net/~ahasenack/ubuntu/+source/paramiko/+git/paramiko/+merge/353660
<slangasek> tjaalton: done
<slangasek> abeato: hi, not sure I'm going to have time to look at NEW processing today, sorry
<abeato> slangasek, nw, it is not super-urgent, thanks
<tjaalton> slangasek: thanks
<LocutusOfBorg> jbicha, you might have a guile issue?
<LocutusOfBorg> are you working to port stuff in main to guile 2.2?
<jbicha> LocutusOfBorg: no issue, there's only one package in main using guile :)
<LocutusOfBorg> :)
<LocutusOfBorg> nice!
<LocutusOfBorg> maybe we should merge both guiles now
<infinity> sil2100: What was with the "review" on that bionic/ubiquity upload? :P
<infinity> mwhudson: ^--- and while I'm mentioning it, want to fix that to not include 1MB of accidental package updates from cosmic?
<ahasenack> hi, sssd now has a component mismatch: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sssd
<ahasenack> python-sss comes from the same source, but is in universe. Could an archive admin please move it to main, where sssd{,-tools} is?
<infinity> ahasenack: Done.
<ahasenack> infinity: \o/ thanks
<sil2100> infinity: I thought those happen automatically - and since the package updates landed in -updates already, no harm in pulling those into ubiquity... where actually I forgot to check if those were actually just from -updates
<sil2100> eh, too warm here, I blame it on the heat
<sil2100> My brain tissue has melted
<infinity> sil2100: They were from cosmic. :P
<infinity> And definitely not "automatic", it was mwhudson building in a dirty checkout.
<sil2100> Ok ok, just another fallout of not looking at the sources that were being updated
<sil2100> You got me there, argh
<sil2100> Sorry about that
<sil2100> ...and that would explain why I thought I didn't see the d-i/manifest updated
<sil2100> Uber fail
-queuebot:#ubuntu-release- New binary: grub2 [arm64] (cosmic-proposed/main) [2.02+dfsg1-5ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.3 => 2.02-2ubuntu8.4] (core)
-queuebot:#ubuntu-release- New binary: neutron-fwaas-dashboard [amd64] (cosmic-proposed/universe) [1.3.0-1ubuntu1] (no packageset)
<slangasek> hmm why does MoM only list nagios3 3.5.1.dfsg-2.1ubuntu4?
<slangasek> ah because it was removed from unstable
<slangasek> jbicha: have you gotten notification emails about your zc.lockfile sync being stuck in -proposed for 77 days (because you dropped an Ubuntu delta that is required by revdeps)?
<slangasek> jbicha: I have had my doubts about whether notification emails are properly sent out to people who have done syncs
-queuebot:#ubuntu-release- New binary: grub2 [amd64] (cosmic-proposed/main) [2.02+dfsg1-5ubuntu1] (core)
<mwhudson> infinity: oh ffs
-queuebot:#ubuntu-release- New binary: grub2 [i386] (cosmic-proposed/main) [2.02+dfsg1-5ubuntu1] (core)
<mwhudson> i hate native packages
<mwhudson> infinity, sil2100: uploaded 18.04.14.8
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.14.7 => 18.04.14.8] (core)
-queuebot:#ubuntu-release- New binary: pscan-tfbs [ppc64el] (cosmic-proposed/universe) [1.2.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pscan-tfbs [s390x] (cosmic-proposed/universe) [1.2.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pscan-tfbs [amd64] (cosmic-proposed/universe) [1.2.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pscan-tfbs [armhf] (cosmic-proposed/universe) [1.2.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pscan-tfbs [arm64] (cosmic-proposed/universe) [1.2.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pscan-tfbs [i386] (cosmic-proposed/universe) [1.2.2-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted pscan-tfbs [amd64] (cosmic-proposed) [1.2.2-2]
-queuebot:#ubuntu-release- New: accepted pscan-tfbs [armhf] (cosmic-proposed) [1.2.2-2]
-queuebot:#ubuntu-release- New: accepted pscan-tfbs [ppc64el] (cosmic-proposed) [1.2.2-2]
-queuebot:#ubuntu-release- New: accepted pscan-tfbs [arm64] (cosmic-proposed) [1.2.2-2]
-queuebot:#ubuntu-release- New: accepted pscan-tfbs [s390x] (cosmic-proposed) [1.2.2-2]
-queuebot:#ubuntu-release- New: accepted pscan-tfbs [i386] (cosmic-proposed) [1.2.2-2]
-queuebot:#ubuntu-release- Unapproved: console-setup (bionic-proposed/main) [1.178ubuntu2.6 => 1.178ubuntu2.7] (core)
<slangasek> and I check if the gnucash build failures are reproducible, and it now ftbfs on all archs due to gcc-8 because of course it should
<slangasek> /<<PKGBUILDDIR>>/libgnucash/engine/Account.cpp:575:59: error: âvoid g_type_class
<slangasek> _add_private(gpointer, gsize)â is deprecated [-Werror=deprecated-declarations]
<slangasek>      g_type_class_add_private(klass, sizeof(AccountPrivate));
<slangasek>                                                            ^
<slangasek> ... and the first gtk3 implementation of gnucash is already using deprecated functions
-queuebot:#ubuntu-release- New: accepted grub2 [amd64] (cosmic-proposed) [2.02+dfsg1-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted grub2 [i386] (cosmic-proposed) [2.02+dfsg1-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted grub2 [arm64] (cosmic-proposed) [2.02+dfsg1-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted neutron-fwaas-dashboard [amd64] (cosmic-proposed) [1.3.0-1ubuntu1]
#ubuntu-release 2018-08-24
<slangasek> xnox: s390x is being very unhelpful wrt gnucash
<slangasek> xnox: n/m, it's just guile being segfaulty
<ahasenack> do you guys need any help with some migration or dep8 test?
<ahasenack> man, so many tests in progress
-queuebot:#ubuntu-release- Unapproved: rejected ubiquity [source] (bionic-proposed) [18.04.14.8]
-queuebot:#ubuntu-release- Unapproved: accepted console-setup [source] (bionic-proposed) [1.178ubuntu2.7]
<cjwatson> So, uh, shouldn't we be in Debian import freeze now, per the release schedule?
<cjwatson> Or has that changed?
<acheronuk> tsimonq2 did mention in passing he might ask for FF to be pushed back a week, but I have no clue if anything came of that
<ahasenack> per #topic, we are not in FF yet
<cjwatson> Yeah, I know that, but the release schedule on the wiki says otherwise so something has to give :)
<cjwatson> (also, FF isn't necessarily the same as DIF ...)
<ahasenack> I think there are not enough builders to cope with the huge queue, it will be a while
<ahasenack> just guessing
<cjwatson> That normally isn't a factor, since it's OK for things to land provided they were at least uploaded before the deadline
<ahasenack> I'm counting on that actually
<cjwatson> (You possibly mean autopkgtest runners.  The Launchpad build farm is mostly idle right now.)
<ahasenack> true
-queuebot:#ubuntu-release- New sync: devscripts-el (cosmic-proposed/primary) [40.1]
-queuebot:#ubuntu-release- New sync: dpkg-dev-el (cosmic-proposed/primary) [37.4]
<xnox> slangasek, who cares about guile, when emacs is busted =) please accept above two NEW packages, which got split out of emacs-goodies-el (which i forced synced now)
<xnox> once above is in, i will readd ubuntu suite names to the dpkg-dev-el one
-queuebot:#ubuntu-release- New source: spirv-tools (cosmic-proposed/primary) [2018.2-0ubuntu1]
<teward> did something happen to FeatureFreeze?
<teward> (proxy-requesting because dpb1 posted it in #ubuntu-server)
<ddstreet> slangasek can you approve nodejs upload to bionic please
-queuebot:#ubuntu-release- New: accepted devscripts-el [sync] (cosmic-proposed) [40.1]
-queuebot:#ubuntu-release- New: accepted dpkg-dev-el [sync] (cosmic-proposed) [37.4]
<slangasek> cjwatson: yeah, we should be in DIF now, switch flipped
-queuebot:#ubuntu-release- New binary: devscripts-el [amd64] (cosmic-proposed/universe) [40.1] (no packageset)
-queuebot:#ubuntu-release- New binary: dpkg-dev-el [amd64] (cosmic-proposed/universe) [37.4] (no packageset)
<cjwatson> thanks
* slangasek changed the topic of #ubuntu-release to: Released: Xenial 16.04.5, Bionic 18.04.1 | Archive: Feature Freeze | Cosmic Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melius malum quod cognoscis
<slangasek> xnox: your new emacs-goodies-el has a pile of component-mismatches too
<xnox> slangasek, which i solved by dropping emacs-goodies-el from the seed.
<slangasek> ok
<xnox> slangasek, it's the other ones from new that we will want to keep in main, i.e. the debian/control|changelog modes which are now split out
<jbicha> slangasek: could you promote guile-2.2 to main and once aisleriot migrates, we can demote guile-2.0?
-queuebot:#ubuntu-release- New: accepted devscripts-el [amd64] (cosmic-proposed) [40.1]
-queuebot:#ubuntu-release- New: accepted dpkg-dev-el [amd64] (cosmic-proposed) [37.4]
<xnox> doko, apw - sigh
<xnox> /usr/include/x86_64-linux-gnu/bits/statx.h:25:8: error: redefinition of âstruct statx_timestampâ
<xnox> /usr/include/linux/stat.h:56:8: note: originally defined here
<xnox> ah, infinity ^
<xnox> i think there is misscompat somehow between headers or something
<tsimonq2> infinity, slangasek: Ping, I'd like an opinion on bug 1788904 when someone has the chance.
<ubot5> bug 1788904 in lubuntu-meta (Ubuntu) "Blanket Feature Freeze Exception: Lubuntu's LXQt Transition" [Critical,New] https://launchpad.net/bugs/1788904
<tsimonq2> Basically, I'm asking a policy to be formalized which has seemingly already been in effect for the Ubuntu Desktop Team among others.
<infinity> xnox: I can haz larger example?
<xnox> infinity, sbuild of systemd fails now =)
<infinity> xnox: Oh, that's no big loss.
 * infinity ducks.
<xnox> infinity, so $ sbuild -A -d cosmic systemd_239-7ubuntu4
<xnox> infinity, well you asked for a larger example, afterall =)
<infinity> xnox: Hahaha.  A slightly smaller one? :P
<infinity> xnox: But yeah, looks like statx is new to glibc (and the kernel, probably), and needs all the usual guards.
<infinity> Hate this dance.
<infinity> xnox: Of course, you might also be able to fix it by not including linux/stat.h
<xnox> infinity, #include <linux/stat.h> #include <sys/stat.h> -> is that broken to include both now?
<xnox> and #include <sys/xattr.h>
<infinity> xnox: It's almost always wrong for userspace to include anything in linux/
<infinity> Not always always, but almost always.
<xnox> there is a mega comment saying that we want to use statx() cause it's exposed from v4.11+ and that it might not be there and fallback to something else.
<xnox> i guess if statx is available now in userspace there is no need for linux/stat.h anymore.....
<xnox> infinity, i'm just curious if this is a bug in systemd, or headers, or both.
<infinity> It's certainly possible for glibc and the kernel to guard against this.
<xnox> infinity, i mean i will fix systemd obviously, but not sure if the headers can be "better" (stupid-compatible?!) somehow.
<infinity> On the other hand, Florian was the committer, and he's usually smarter than that.
<infinity> So unless there appears to be a valid reason to want both, the conflict might be intentional.
<xnox> 4/* Missing glibc definitions to access certain kernel APIs */
<xnox> is the heading used for these includes in systemd tree
<infinity> And I don't see any reason to want the kernel version, at a glance.
<xnox> so possibly obsolete now.
<infinity> Unfortunate that an upstream fix will have to have a conditional include.
<infinity> But not world-ending either.
<infinity> include sys/stat, ifndef foo, include linux/statx
<infinity> xnox: I'm assuming Fedora already ran into this, since they probably shipped glibc 2 weeks ago.
<infinity> xnox: Unless they've not rebuilt systemd since.
<infinity> Now, if I could remember how to find fedora sources..
<xnox> i'll propose conditional upstream i think.
<xnox> (systemd)
<infinity> Yeah, I'm going to look at what Fedora's done here for kicks.
<infinity> Ahh, and that's that answer.  systemd in Fedora hasn't been built since mid-July.
<infinity> Oh, wait.
<infinity> xnox: https://src.fedoraproject.org/cgit/rpms/systemd.git/commit/?h=f29&id=5306894742943e5d46ac705a3f2d5db1a48a0a67
<infinity> xnox: Looks like a Googler has already proposed a patch (and F29 is carrying it).
<infinity> xnox: So, cheers.
<xnox> infinity, lovely, cause propose to fedora and not to upstream?
 * xnox checks master again
<infinity> Gah, GitHub is all wonky.
<infinity> WHY.
<infinity> xnox: https://github.com/systemd/systemd/commit/75720bff62a84896e9a0654afc7cf9408cf89a38
<infinity> xnox: Looks upstreamish to me.
<teward> infinity: because GH is owned by Microsoft now?  *shot*  (no but seriously...)
<infinity> teward: I suspect it doesn't particularly relate (except maybe Github higher-ups trying to look "busy" and "useful" to not get "fired" and made "homeless" by their new overlords)
<infinity> Either way, this dashboard landing page madness is... Busy.
<infinity> And useless.
<xnox> infinity, it got replaced by https://github.com/systemd/systemd/commit/9c869d08d82c73f62ab3527567858ce4b0cf1257#diff-969b60ad3d206fd45c208e266ccfed38
<teward> infinity: indeed.  (It's why I've been shifting to other providers, or running my own GitLab instead for my projects, but I digress)
<teward> (I was going to ask "what happened to feature freeze" but I just saw the emails about it, so don't mind me :P )
<infinity> xnox: Fancy.  Definitely a step in the not-silly direction.  Maybe.
<xnox> we have thousands of things in autopkgtest queue backlog still....
<xnox> hence to me FF is a bit meaningless
<infinity> FF isn't about migration, it's about uploads.
<teward> ^ that
<infinity> Certainly not meaningless to say "okay, stop uploading MORE feature changes".
<teward> indeed.  which reminds me, roaksoax has a proposed change to Cosmic that'd alter the package structure, that'd need an FFe review right?
<teward> to Cosmic nginx*
<teward> (at this point it's not yet 'tested' or 'accepted' as working so it didn't get included in the latest uploads I did for it)
<infinity> xnox: Anyhow, based on those two commits, I'd say the systemd community is accepting that it's their bug, and not a bug in the headers.  And Lennart would argue six ways to Tuesday if he even 5% thought it was our bug, so I'm going to call that definitive. :P
<xnox> infinity, he may have been on holiday since july and has not seen this commit yet
<infinity> xnox: He committed the first one.
<infinity>  filbranden authored and poettering committed on Jul 15
<infinity> Oh look, and my build failed on two arches, despite testing it earlier.
 * infinity looks.
-queuebot:#ubuntu-release- Unapproved: rax-nova-agent (bionic-proposed/main) [2.1.15-0ubuntu1~18.04.0 => 2.1.15-0ubuntu1~18.04.1] (no packageset)
<tsimonq2> doko: My updated assessment on the KDE autopkgtest situation is that there's enough library interdependencies that a build needs to be done for autopkgtest accuracy.
<tsimonq2> doko: Alternatively we're exploring just really tightening the autopkgtest deps on the packages, but Santa was working on that and he's been in and out (likely on vac) lately.
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.17.0-9.10] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.17.0-9.10] (core, kernel)
-queuebot:#ubuntu-release- New binary: murano-agent [amd64] (cosmic-proposed/universe) [1:3.5.1-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.17.0-9.10]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.17.0-9.10]
<slangasek> jbicha: guile-2.2 promoted
<slangasek> jbicha: did you see my question about whether you've received britney nagmails about zc.lockfile?
<slangasek> anyone care yet about node + rollup?  or should I just remove the lot from -proposed?
<LocutusOfBorg> slangasek, I care about node+rollup
<LocutusOfBorg> at least after all the work I did
<LocutusOfBorg> let me try to find a way
<LocutusOfBorg> slangasek, is it possible to remove automake-1.15 from archive? useless now
<LocutusOfBorg> NBS
<slangasek> LocutusOfBorg: 'NBS' - it doesn't show up on http://people.canonical.com/~ubuntu-archive/nbs.html , what do you mean?
<LocutusOfBorg> the "automake" binary is now part of src:automake-1.16, migrated in cosmic hours ago
<LocutusOfBorg> so, the src:automake-1.15 is producing nothing, I don't know what is the best wording :)
<slangasek> LocutusOfBorg: sounds like a source package whose removal we would pick up via Debian
<LocutusOfBorg> [2018-08-10] automake-1.15 REMOVED from testing (Britney)
<LocutusOfBorg> oh indeed, still part of unstable, meh
<LocutusOfBorg> ok https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906928
<ubot5> Debian bug 906928 in ftp.debian.org "RM: automake-1.15 -- RoQA; binary package now built by automake-1.16" [Normal,Open]
<slangasek> yah, not worth putting extra effort into those kinds of removals, they'll eventually get reaped
<slangasek> I run process-removals several times between FF and release
<LocutusOfBorg> nice
-queuebot:#ubuntu-release- New sync: debian-el (cosmic-proposed/primary) [37.6]
<xnox> slangasek, one more NEW package needed for the emacs-goodies-el split.... sorry that i missed that one. ^
<slangasek> xnox: done
-queuebot:#ubuntu-release- New: accepted debian-el [sync] (cosmic-proposed) [37.6]
-queuebot:#ubuntu-release- New binary: debian-el [amd64] (cosmic-proposed/none) [37.6] (no packageset)
<slangasek> jbicha: and guile-2.0 demoted
<slangasek> LocutusOfBorg, acheronuk: I see you both retried the kdeconnect/s390x autopkgtest failure; it looks entirely reproducible and looks to me like there's a good chance it's a big-endian bug.  How should we proceed with this?
<jbicha> slangasek: I didn't see your question the first time but I'll take a look at zc.lockfile
<slangasek> jbicha: ok, thanks for looking - and did you previously receive emails?
<slangasek> because I'm trying to figure out if we have a bug generally in not notifying people of stuck force-syncs
<jbicha> I get lots of email from the Release Team :)
#ubuntu-release 2018-08-25
<acheronuk> slangasek: I asked kdeconnect s390x test to be ignored so I don't have to keep a packaging delta skipping it. if not possible, then I'll have to do it in packaging
-queuebot:#ubuntu-release- Unapproved: cockpit (bionic-backports/universe) [173-1~ubuntu18.04.1 => 176-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [173-1~ubuntu16.04.1 => 176-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (bionic-backports) [176-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [176-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New binary: cockpit [s390x] (bionic-backports/universe) [176-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [ppc64el] (bionic-backports/universe) [176-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [s390x] (xenial-backports/universe) [176-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [i386] (bionic-backports/universe) [176-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [ppc64el] (xenial-backports/universe) [176-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [amd64] (bionic-backports/universe) [176-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [i386] (xenial-backports/universe) [176-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [amd64] (xenial-backports/universe) [176-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [powerpc] (xenial-backports/universe) [176-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [arm64] (bionic-backports/universe) [176-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [armhf] (bionic-backports/universe) [176-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [arm64] (xenial-backports/universe) [176-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [armhf] (xenial-backports/universe) [176-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New sync: llvm-toolchain-7 (cosmic-proposed/primary) [1:7~+rc2-1~exp1]
-queuebot:#ubuntu-release- New binary: ironic [amd64] (cosmic-proposed/universe) [1:11.1.0-0ubuntu2] (openstack)
-queuebot:#ubuntu-release- New binary: panko [amd64] (cosmic-proposed/universe) [5.0.0-0ubuntu2] (no packageset)
<LocutusOfBorg> slangasek, I fixed all the poppler failures I think, except for xpdf
<LocutusOfBorg> this package is a sad go
<LocutusOfBorg> we might update to the new release 4.00 but needs work, and I don't plan to do it :)
<jbicha> slangasek: Ubuntu's zc.lockfile changelog entries were included in the Debian update so that's why I synced
<jbicha> but I will probably need some help figuring out how to get our packages to drop the dependency
#ubuntu-release 2018-08-26
<slangasek> acheronuk: so does this kdeconnect s390x failure not point to the package itself being broken on this arch?
<slangasek> jbicha: ah, I see, the last changelog entry explains how namespaces are supposed to be done now, so all of the other python-zc.* packages should be updated to match
<acheronuk> slangasek: as far as I know that kdeconnect failure has bee there for a long time but tests were just skipped in packaging before. number or reports I have seen of brokenness from people running kdeconnect on an ibm mainfraime = 0, and s390x is not an architecture we (kubuntu) could consider that we support in any regard anyway
-queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.14.7 => 18.04.14.8] (core)
<jbicha> slangasek: I didn't know how to fix the zc issue so I emailed the Debian uploader but haven't heard back yet. I'll forward you the email becuase a no-change rebuild isn't enough (yet)
-queuebot:#ubuntu-release- Unapproved: qtdeclarative-opensource-src (bionic-proposed/universe) [5.9.5-0ubuntu1 => 5.9.5-0ubuntu1.1] (kubuntu, qt5)
<slangasek> jbicha: hmm I did a local no-change rebuild of the first of them and it looked correct, but maybe my build env wasn't clean enough
<slangasek> jbicha: the usr/share/python/ns handling at least appears to be there, but it hasn't necessarily shaken the dep on python-zc
<LocutusOfBorg> xnox, can I merge openssl 1.1?
<LocutusOfBorg> (from Debian testing)
<LocutusOfBorg> I have a trivial merge ready to go
<LocutusOfBorg> I would like to grab some CVE fixes
 * LocutusOfBorg will upload in ~15h if nobody complains
<mitya57> LocutusOfBorg: not from unstable please, because of Debian #907015
<ubot5> Debian bug 907015 in src:openssl "openssl version 1.1.1 breaks multiple reverse dependencies; versioned Breaks needed" [Serious,Open] http://bugs.debian.org/907015
<LocutusOfBorg> sure mitya57 this is why I said "merge from testing" :)  openssl - 1.1.0h-4ubuntu1 in my ppa
-queuebot:#ubuntu-release- New sync: node-csv-spectrum (cosmic-proposed/primary) [1.0.0-2]
#ubuntu-release 2019-08-19
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1019.21]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-59.66~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-59.66~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-59.66~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-59.66~16.04.1]
<mwhudson> uh how did the version of golang-github-disintegration-imaging in eoan RELEASE migrate
<mwhudson> it never passed on arm64
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1051.60] (kernel)
<mwhudson> oh no, it did
<mwhudson> go 1.10 vs go 1.11 maybe
<mwhudson> yes
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1051.60]
<cpaelzer> There are currently 13 UFW tests on http://autopkgtest.ubuntu.com/running#pkg-ufw; all are stuck on "Test get_netfilter_capabilities() ..." in the "build-needed" stage. This will not recover due to bug 1840633. It would be great if someone could cancel them. FYI: Since I don't exactly know who can do this I posted this on multiple channels.
<ubot5> bug 1840633 in ufw (Ubuntu) "autopkgtests get stuck in Eoan with iptables 1.8.3" [Undecided,New] https://launchpad.net/bugs/1840633
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1022.25~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1022.25] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.2.0-13.14] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.2.0-13.14] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.2.0-13.14] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1022.25]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.2.0-13.14]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.2.0-13.14]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.2.0-13.14]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1022.25~16.04.1]
-queuebot:#ubuntu-release- New binary: x265 [i386] (eoan-proposed/universe) [3.1.1-2] (kubuntu)
<Laney> cpaelzer: the PPA ones?
-queuebot:#ubuntu-release- New binary: x265 [amd64] (eoan-proposed/universe) [3.1.1-2] (kubuntu)
<cpaelzer> Laney: there are a bunch from PPAs yes
<cpaelzer> Laney: and there is one on I think armhf which is on for 75h
<Laney> ok
<cpaelzer> that as well
<cpaelzer> Until I have found the root cause there might be more to come :-/
<Laney> I'm sshed into an instance which has hung right now
<cpaelzer> Laney: are you ok if I might ming you late ron for more of these aborts?
<Laney> do you want something from it?
<cpaelzer> or is there any self-empowering that I could do it on my own
<cpaelzer> we ones that hang right now are useless IMHO
<Laney> like some debugging information
<cpaelzer> I have some prepared which will report debug info
<Laney> https://paste.ubuntu.com/p/9PxrWRMkJc/
<Laney> ok
<cpaelzer> Laney: well, how much could we get from the current systems?
<Laney> well I can run things ...
<cpaelzer> oh nice
<cpaelzer> so you can actually log in
<Laney> you could probably do the same via canonistack
<cpaelzer> nice to iptables actually is busy there
<cpaelzer> vry useful
<Laney> if it's something that breaks the SSH runner somehow
-queuebot:#ubuntu-release- New binary: x265 [s390x] (eoan-proposed/universe) [3.1.1-2] (kubuntu)
<cpaelzer> the problem is that it is at build time (build-needed from autopkgtest)
<cpaelzer> which is odd, the actual same build on LP infra works fine
<cpaelzer> only in this autopkgcontext it fails
<cpaelzer> but seeing the hanging iptables command is interesting
<cpaelzer> Laney: how could I submit commands against it?
<Laney> via my fingers
<cpaelzer> sure, then the first two thing I'd want to see are
<Laney> or try canonistack (autopkgtest w/ssh runner), like I say - bet it happens there too
<cpaelzer> let me hand you two commands and then I can give ssh runner via canonistack a chance later
<Laney> ok
<cpaelzer> never doen that if there is any docu/script/hint on that I'd appreciate a link
<cpaelzer> 1. cat /proc/25819/wchan
<Laney> no link, it only recently became feasible
<cpaelzer> 2. strace of 25819 (if you can submit semi interactive commands)
-queuebot:#ubuntu-release- New binary: x265 [armhf] (eoan-proposed/universe) [3.1.1-2] (kubuntu)
<cpaelzer> I already thank you for the suggestion, that sounds like the most similar environment that I could get
-queuebot:#ubuntu-release- New binary: x265 [arm64] (eoan-proposed/universe) [3.1.1-2] (kubuntu)
<Laney> wchan is 0
<Laney> strace: https://paste.ubuntu.com/p/5Z745G963k/ <- that repeating endlessly
<cpaelzer> ok so it is really busy
<cpaelzer> Thank you so much
<cpaelzer> back trying ssh runner after lunch ...
<cpaelzer> Laney: you can kill all of those currently up then, they won't complete
-queuebot:#ubuntu-release- New binary: x265 [ppc64el] (eoan-proposed/universe) [3.1.1-2] (kubuntu)
<Laney> juliank might be able to help you with that, think he did it
<juliank> manually running autopkgtest on canonistack?
<Laney> ssh runner
<juliank> I only played with the entire cloud thing
<Laney> ah well
<Laney> Should be doable by copying the first line of an autopkgtest log from autopkgtest.u.c, and removing all the production specific bits about ftpmaster.internal and proxies
<Laney> (ufws are killed)
<juliank> Laney: doesn't it also need an image built though?
<Laney> you can probably use an upstream one
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1056.61] (kernel)
<cpaelzer> Thanks Laney
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1056.61]
<cpaelzer> Laney: juliank: I was wondering if the network rules in this might be important --security-groups autopkgtest@lgw01-14.secgroup
<cpaelzer> do you have a way to query their definition?
<cpaelzer> they don't seem to exist in any place of *stack that I can touch
<Laney> cpaelzer: I doubt it, that's just a firewall at the cloud level - nothing the instances themselves see
<cpaelzer> hmm, ok thanks
<cpaelzer> I didn't get --flavor autopkgtest running nor the special image type, but I fell back to a normal eoan image with m1.mediuam
<cpaelzer> should be pretty similar
<cpaelzer> test is still running
<cpaelzer> lets hope the issue triggers there
<Laney> fingers crossed
<juliank> cpaelzer: It's just copies of the default security group
<juliank> for scaling reasons
<juliank> IIRC
<Laney> something something mumble openstack
-queuebot:#ubuntu-release- Unapproved: amd64-microcode (disco-proposed/main) [3.20181128.1ubuntu1 => 3.20181128.1ubuntu1.1] (core)
-queuebot:#ubuntu-release- Unapproved: amd64-microcode (bionic-proposed/main) [3.20180524.1~ubuntu0.18.04.2 => 3.20181128.1~ubuntu0.18.04.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: amd64-microcode (xenial-proposed/main) [3.20180524.1~ubuntu0.16.04.2 => 3.20181128.1~ubuntu0.16.04.1] (no packageset)
<gpiccoli> Hi SRU vanguard, could you please skip/force-badtest the autopkgtesting for makedumpfile/1:1.6.6-2ubuntu1 (eon-proposed) on ppc64el?
<gpiccoli> Justification can be found here: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/comments/37
<ubot5> Ubuntu bug 1681909 in makedumpfile (Ubuntu Disco) "kdump is not captured in remote host when kdump over ssh is configured" [Medium,In progress]
<gpiccoli> Tnx in advance =)
<gpiccoli> slashd, cascardo  ^
<Odd_Bloke> gpiccoli: Why would the SRU vanguard touch the autopkgtests for the development release?
<gpiccoli> Odd_Bloke, I don't know hehe I thought in pinging them
<Odd_Bloke> (I am neither an SRU vanguard, nor anyone else you might want to talk to, but I suspect you're asking the wrong people. :)
<gpiccoli> Odd_Bloke, is there anybody that can look that?
<gpiccoli> Perhaps Odd_Bloke hehehe
<Odd_Bloke> up enter ;)
<gpiccoli> What I want is an exemptioon for this test, since we may have some form of test infrastructure issue
<gpiccoli> what is "up enter" Odd_Bloke ?
<gpiccoli> probably this is a silly question hehe, sorry if it's the case
<Odd_Bloke> gpiccoli: I just meant "read my last message", apologies for not being clear! :)
<gpiccoli> OK Odd_Bloke, no problem
<slashd> Odd_Bloke, I think what gpiccoli needs is an archive admin for them to let the package through.
<slashd> rbasak, ? Am I right here ^
<rbasak> I think it's ~ubuntu-release
<rbasak> You can file a bug against https://code.launchpad.net/~ubuntu-release/britney/hints-ubuntu
<rbasak> an MP sorry
<slashd> gpiccoli, that should answer your question about how to proceed ^
<slashd> thanks rbasak, much appreciated !
<rbasak> np!
<gpiccoli> tnx slashd, rbasak
<gpiccoli> just confirming with ubuntu-release team: to be able to get the package released before the freeze, I need an exemption in the test failure for ppc64el - the way to this is to fill MP forcing the badtest?
<gpiccoli> vorlon ^
<gpiccoli> Laney ^ too (sorry, forgot to loop you!)
<vorlon> gpiccoli: yes, MP welcome
<gpiccoli> ok vorlon, thanks
-queuebot:#ubuntu-release- Unapproved: opencryptoki (bionic-proposed/universe) [3.9.0+dfsg-0ubuntu1.1 => 3.9.0+dfsg-0ubuntu1.2] (no packageset)
<mdeslaur> can the SRU in bug 1835968 please be released now?
<ubot5> bug 1835968 in ruby2.5 (Ubuntu) "Regression in backported patch for openssl 1.1" [High,Confirmed] https://launchpad.net/bugs/1835968
-queuebot:#ubuntu-release- New binary: mysql-8.0 [s390x] (eoan-proposed/main) [8.0.16-0ubuntu3] (no packageset)
<vorlon> mdeslaur: looking
<vorlon> mdeslaur: released
<mdeslaur> thanks vorlon
-queuebot:#ubuntu-release- New binary: mysql-8.0 [amd64] (eoan-proposed/main) [8.0.16-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: mysql-8.0 [ppc64el] (eoan-proposed/main) [8.0.16-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: python-py2bit [amd64] (eoan-proposed/universe) [0.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-py2bit [s390x] (eoan-proposed/universe) [0.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-py2bit [i386] (eoan-proposed/universe) [0.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-py2bit [arm64] (eoan-proposed/universe) [0.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-py2bit [armhf] (eoan-proposed/universe) [0.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: python-py2bit [ppc64el] (eoan-proposed/universe) [0.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: mysql-8.0 [i386] (eoan-proposed/main) [8.0.16-0ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: wireshark [s390x] (eoan-proposed/universe) [3.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireshark [i386] (eoan-proposed/universe) [3.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireshark [ppc64el] (eoan-proposed/universe) [3.0.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted wireshark [i386] (eoan-proposed) [3.0.3-1]
-queuebot:#ubuntu-release- New: accepted wireshark [ppc64el] (eoan-proposed) [3.0.3-1]
-queuebot:#ubuntu-release- New: accepted python-py2bit [amd64] (eoan-proposed) [0.3.0-2]
-queuebot:#ubuntu-release- New: accepted python-py2bit [armhf] (eoan-proposed) [0.3.0-2]
-queuebot:#ubuntu-release- New: accepted python-py2bit [ppc64el] (eoan-proposed) [0.3.0-2]
-queuebot:#ubuntu-release- New: accepted wireshark [s390x] (eoan-proposed) [3.0.3-1]
-queuebot:#ubuntu-release- New: accepted python-py2bit [arm64] (eoan-proposed) [0.3.0-2]
-queuebot:#ubuntu-release- New: accepted python-py2bit [s390x] (eoan-proposed) [0.3.0-2]
-queuebot:#ubuntu-release- New: accepted python-py2bit [i386] (eoan-proposed) [0.3.0-2]
-queuebot:#ubuntu-release- New: accepted python-alignlib [ppc64el] (eoan-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted x265 [arm64] (eoan-proposed) [3.1.1-2]
-queuebot:#ubuntu-release- New: accepted x265 [i386] (eoan-proposed) [3.1.1-2]
-queuebot:#ubuntu-release- New: accepted x265 [s390x] (eoan-proposed) [3.1.1-2]
-queuebot:#ubuntu-release- New: accepted x265 [amd64] (eoan-proposed) [3.1.1-2]
-queuebot:#ubuntu-release- New: accepted x265 [ppc64el] (eoan-proposed) [3.1.1-2]
-queuebot:#ubuntu-release- New: accepted x265 [armhf] (eoan-proposed) [3.1.1-2]
-queuebot:#ubuntu-release- New: accepted python-alignlib [s390x] (eoan-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New binary: mysql-8.0 [armhf] (eoan-proposed/main) [8.0.16-0ubuntu3] (no packageset)
<lordcirth> Did the root-on-ZFS installer option make it into 19.10? I don't see it in the daily ISO
<Eickmeyer> vorlon: If you can, could you look at raysession? teward uploaded another one, it's binNEW.
-queuebot:#ubuntu-release- New binary: mysql-8.0 [arm64] (eoan-proposed/main) [8.0.16-0ubuntu3] (no packageset)
<teward> *is pinged*
<cyphermox> could anyone please help with pyyaml 5.1.2-1 in eoan-proposed? grr and python-asdf appear to me to be badtest (grr is an unrelated failure, and python-asdf is due to enddianness in tests); salt seems to reliably timeout, I'm not sure how to deal with that
-queuebot:#ubuntu-release- Unapproved: s390-tools (eoan-proposed/main) [2.10.0-0ubuntu2 => 2.10.0-0ubuntu2] (core)
<rbasak> vorlon: ^ that's the last of the binaries for mysql-router from src:mysql-8.0. This adds a binary built from the same source (it was being build anyway). It isn't on the critical path for the MySQL transition but I uploaded it since we want it for Eoan, it's a feature and feature freeze is coming up.
<rbasak> Note that we know about shipping libmysqlrouter*.so*. We're looking into statically linking it instead since it isn't intended that the package supplies a library used externally - it's an internal thing and doesn't really need to be a shared object.
<rbasak> In the meantime we put it in /usr/lib/mysql-router/ to keep it out of the way.
<rbasak> I hope that's OK.
<rbasak> (and /usr/lib/mysql-router/mysqlrouter/ contains plugins for the binary but that's normal)
-queuebot:#ubuntu-release- New: accepted rustc [amd64] (eoan-proposed) [1.36.0+dfsg1+llvm-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [armhf] (eoan-proposed) [1.36.0+dfsg1+llvm-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [ppc64el] (eoan-proposed) [1.36.0+dfsg1+llvm-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [arm64] (eoan-proposed) [1.36.0+dfsg1+llvm-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [s390x] (eoan-proposed) [1.36.0+dfsg1+llvm-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [i386] (eoan-proposed) [1.36.0+dfsg1+llvm-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted mysql-8.0 [amd64] (eoan-proposed) [8.0.16-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted mysql-8.0 [armhf] (eoan-proposed) [8.0.16-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted mysql-8.0 [ppc64el] (eoan-proposed) [8.0.16-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted mysql-8.0 [arm64] (eoan-proposed) [8.0.16-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted mysql-8.0 [s390x] (eoan-proposed) [8.0.16-0ubuntu3]
-queuebot:#ubuntu-release- New: accepted mysql-8.0 [i386] (eoan-proposed) [8.0.16-0ubuntu3]
<vorlon> rbasak: ^^ various lintian messages on mysql-router (with lintian -I), but nothing blocking
-queuebot:#ubuntu-release- New: accepted raysession [amd64] (eoan-proposed) [0.7.2-0ubuntu2]
<vorlon> Eickmeyer: ^^
<Eickmeyer> vorlon: Thanks!!!
<rbasak> Thanks!
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [5.0.0-1017.18~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1017.18] (core, kernel)
#ubuntu-release 2019-08-20
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1017.18]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [5.0.0-1017.18~18.04.1]
<cpaelzer> Laney: bug 1840633 tries to resist to be reproduced outside of autopkgtest-infra build-needed step :-/
<ubot5> bug 1840633 in ufw (Ubuntu) "autopkgtests get stuck in Eoan with iptables 1.8.3" [Undecided,New] https://launchpad.net/bugs/1840633
<cpaelzer> Laney: there are again a bunch of hanging tests that could be killed, but I'd need to ask you to again "run a few commands"
<cpaelzer> This time I'd ask if you could fetch the debug symbols from the PPA which is tested https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3790/+packages and then get a gdb backtrace (or an apport reports or what you prefer) of the hanging iptables process?
<cpaelzer> I feel bad for asking you, but lacking any alternative way to trigger it that would be the next step that I see available to understand what is going on
<RikMills> Morning. If an AA has a few secs, could these 2 removal get done. Thanks LP: #1840744 #1840743
<ubot5> Launchpad bug 1840744 in krecipes (Ubuntu) "Remove krecipes from Eoan" [Undecided,New] https://launchpad.net/bugs/1840744
<RikMills> LP: #1840743
<ubot5> Launchpad bug 1840743 in smokegen (Ubuntu) "Remove smokegen from Eoan" [Undecided,New] https://launchpad.net/bugs/1840743
<Locutusofborg> hello release team! src:hy is not an arch:all package, and removed python-hy package... can anybody please NBS-cleanup-proposed it?
-queuebot:#ubuntu-release- New binary: colord [s390x] (eoan-proposed/main) [1.4.4-1~ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: colord [i386] (eoan-proposed/main) [1.4.4-1~ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: colord [ppc64el] (eoan-proposed/main) [1.4.4-1~ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: colord [amd64] (eoan-proposed/main) [1.4.4-1~ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: colord [arm64] (eoan-proposed/main) [1.4.4-1~ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: colord [armhf] (eoan-proposed/main) [1.4.4-1~ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted colord [amd64] (eoan-proposed) [1.4.4-1~ubuntu1]
-queuebot:#ubuntu-release- New: accepted colord [armhf] (eoan-proposed) [1.4.4-1~ubuntu1]
-queuebot:#ubuntu-release- New: accepted colord [ppc64el] (eoan-proposed) [1.4.4-1~ubuntu1]
-queuebot:#ubuntu-release- New: accepted colord [arm64] (eoan-proposed) [1.4.4-1~ubuntu1]
-queuebot:#ubuntu-release- New: accepted colord [s390x] (eoan-proposed) [1.4.4-1~ubuntu1]
-queuebot:#ubuntu-release- New: accepted colord [i386] (eoan-proposed) [1.4.4-1~ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (disco-proposed) [2.40+19.04]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.40+18.04]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.40]
<cpaelzer> Laney: and in addition to the gdb request of 2h ago, since it hangs on creating a new chain like "iptables -N ufw-tmpsuffix" it would be great if you could also run "iptables -L" and check if any other new "iptables -N ufw-tmpsuffix" will hang as well
<cpaelzer> if it does hang maybe an strace -ff of such a hanging iptables would be helpful as well
<Laney> cpaelzer: be with you in a bit
<RikMills> another Qt4/KDE4 removal if possible LP: #1840762
<ubot5> Error: Could not gather data from Launchpad for bug #1840762 (https://launchpad.net/bugs/1840762). The error has been logged
<RikMills> nice
<tjaalton> RikMills: what's up with kservice tests?
<RikMills> tjaalton: looking...
<RikMills> tjaalton: looks like a regression in upstream code/tests that failed on KDE CI but wasn't fixed by the last release. There is a fix I will try applying. if that doesn't work we can the then current version to be badtested until the next release
<RikMills> *then ask
-queuebot:#ubuntu-release- Unapproved: libio-socket-ssl-perl (bionic-security/main) [2.060-3~ubuntu18.04.1 => 2.060-3~ubuntu18.04.1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: openssl (bionic-security/main) [1.1.1-1ubuntu2.1~18.04.4 => 1.1.1-1ubuntu2.1~18.04.4] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: python2.7 (bionic-security/main) [2.7.15-4ubuntu4~18.04 => 2.7.15-4ubuntu4~18.04] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: python3.7 (bionic-security/universe) [3.7.3-2~18.04.1 => 3.7.3-2~18.04.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby-openssl (bionic-security/universe) [2.0.9-0ubuntu1 => 2.0.9-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libwww-perl (bionic-security/main) [6.31-1ubuntu0.1 => 6.31-1ubuntu0.1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: python3.6 (bionic-security/main) [3.6.8-1~18.04.1 => 3.6.8-1~18.04.1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: ruby2.5 (bionic-security/main) [2.5.1-1ubuntu1.5 => 2.5.1-1ubuntu1.5] (kubuntu, ubuntu-desktop, ubuntu-server) (sync)
-queuebot:#ubuntu-release- Unapproved: python-cryptography (bionic-security/main) [2.1.4-1ubuntu1.3 => 2.1.4-1ubuntu1.3] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: r-cran-openssl (bionic-security/universe) [1.0.1-1ubuntu1.1 => 1.0.1-1ubuntu1.1] (no packageset) (sync)
<tjaalton> RikMills: ok, cool
<mdeslaur> can someone please approve those? ^ they are the openssl syncs to bionic-security
<mdeslaur> s/can/could/
<mdeslaur> oh, actually, looks like I can do it, so never mind
-queuebot:#ubuntu-release- Unapproved: accepted libio-socket-ssl-perl [sync] (bionic-security) [2.060-3~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted openssl [sync] (bionic-security) [1.1.1-1ubuntu2.1~18.04.4]
-queuebot:#ubuntu-release- Unapproved: accepted python2.7 [sync] (bionic-security) [2.7.15-4ubuntu4~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted python3.7 [sync] (bionic-security) [3.7.3-2~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted ruby-openssl [sync] (bionic-security) [2.0.9-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted libwww-perl [sync] (bionic-security) [6.31-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted python3.6 [sync] (bionic-security) [3.6.8-1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted ruby2.5 [sync] (bionic-security) [2.5.1-1ubuntu1.5]
-queuebot:#ubuntu-release- Unapproved: accepted python-cryptography [sync] (bionic-security) [2.1.4-1ubuntu1.3]
-queuebot:#ubuntu-release- Unapproved: accepted r-cran-openssl [sync] (bionic-security) [1.0.1-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: update-manager (xenial-proposed/main) [1:16.04.15 => 1:16.04.16] (core)
<Laney> seb128: moving hint question here, looks like onioncircuit could be skipped and ubuntu-release-upgrader retried? (done)
<seb128> Laney, better channel, indeed, thx
<seb128> Laney, onioncircuit test depends on python-dogtail that got replaced by python3-dogtail (but the tests need more work with python3, I reported to Debian for now)
<Laney> k, but it looks like we should have not called that a regression anyway
<Laney> http://autopkgtest.ubuntu.com/packages/o/onioncircuits/eoan/amd64
<Laney> cpaelzer__: oops, sorry, I forgot to come back to you
<Laney> but good news, I've made that thing happen in Canonistack
<Laney> https://paste.fedoraproject.org/paste/nR6WtTr-HFpMhycWyDCY2w
<Laney> it hung at "Test get_netfilter_capabilities() ...", that's the right place right?
<Laney> I did build an adt image, hmm, hopefully you can use that
<Laney> going to blacklist ufw for now I think
<cpaelzer__> Laney: yes that is the right function
<Laney> cpaelzer__: sorry I ctrl-ced it by mistake, but did you want to try my command?
<cpaelzer__> yeah I'll try to run it
<cpaelzer__> replacing with my canonistack creds of course
<Laney> yes
<Laney> I tried to "share" that adt image I used with you, I think the command to accept that is "openstack image set --accept e9f6a83f-5712-4f03-b655-fa06e1960352"
<Laney> then it should show up in "openstack image list"
<cpaelzer__> Could not find resource e9f6a83f-5712-4f03-b655-fa06e1960352
<cpaelzer__> never had to do anything with openstack image sharing oO
<Laney> try again
<Laney> if not tell me your $OS_PROJECT_NAME, it appears not to validate that
<Laney> ...
<cpaelzer__> still no available
<cpaelzer__> project is "paelzer_project"
<Laney> ah I had prepended a c
<Laney> ok now
<cpaelzer__> still saying it that it can't find it
<Laney> wtf
<Laney> one second
<cpaelzer__> I'm logging into the dashboard as well, in case there is something the console won't show/allow me
<Laney> https://paste.ubuntu.com/p/VMdptD6hCk/
<Laney> maybe there's some latency before you can accept?
<cpaelzer__> it is not in my image list (not even as pending)
<cpaelzer__> lets give it 10 minutes in case it needs to copy to a pool or so
<Laney> shouldn't be until you accept it I don't think
<cpaelzer__> in the dashboard I can select "shared with project" but that view is empty as well
<cpaelzer__> still not available to be accepted
<Laney> dunno
<Laney> sorry :(
<Laney> maybe you can wrangle create-nova-image-new-release yourself
<Laney> or ask IS if they can do it
<Laney> it -> make the share work
<cpaelzer> Laney: I guess you did "openstack image set --shared e9f6a83f-5712-4f03-b655-fa06e1960352" right?
<cpaelzer> and ".. add project ..."
<Laney> right
<cpaelzer> pending is documented as "until I accept it"
<Laney> that's why it shows up in the pending list of shares (my pastebin)
<cpaelzer> I'll ask in #is internally
<Laney> if an admin just wants to make it public temporarily as a workaround they can
<Laney> (mortals don't have permissions for that)
<gpiccoli> vorlon, sorry to annoy, I have a MP for badtest in makedumpfile; it may block the release for eaon before the freeze if not approved. Can you take a look?
<gpiccoli> https://code.launchpad.net/~gpiccoli/britney/hints-ubuntu/+merge/371479
<lordcirth> Did the root-on-ZFS installer option make it into 19.10? I don't see it in the daily ISO
<cpaelzer> Laney: I guess the nova script is the one from https://salsa.debian.org/ci-team/autopkgtest/blob/master/ssh-setup/nova ?
<cpaelzer> well I have autopkgtest checked out anyway
<Laney> cpaelzer: yeah
<cpaelzer> using whatever I have locally atm
<Laney> I have a checkout, not sure if/where the package puts that
<cpaelzer> error: argument <subcommand>: invalid choice: 'network-show'
<cpaelzer> I might need to update my autopkgtest checkout ...
<cpaelzer> Laney: are you on master or some tag?
<cpaelzer> hmm, there are not mcuh differences to that script
<Laney> hmm, hang on, I might have a local hack to that
<Laney> I was playing with it a while ago
<Laney> cpaelzer: -        OUT=$(nova network-show $NET_ID)
<Laney> +        OUT=$(openstack network show $NET_ID)
<cpaelzer> Laney: http://paste.ubuntu.com/p/sNpBTKfwHt/
<cpaelzer> ah ok
<cpaelzer> trying that
<Laney> should send that upstream but I'd need to check it works on trusty
<cpaelzer> should I exchange all the other nova commands with openstack as well?
<Laney> wouldn't bother, if it works - that's the only diff I have
<Laney> (for a patch for upstream I would though)
<cpaelzer> Now it is: http://paste.ubuntu.com/p/gnVxWXkq5w/
<Laney> O_O
<cpaelzer> If you don't know I can throw in some more debug tomorrow
<cpaelzer> it is the nva script that breaks, and scripts are easy to debug
<cpaelzer> Laney: just to check - if it works I have an instacne up that I can login with my key right?
<Laney> yeah
<Laney> you should be able to 'set -x' in the nova script
-queuebot:#ubuntu-release- Unapproved: sane-backends (disco-proposed/main) [1.0.27-3.2ubuntu1 => 1.0.27-3.2ubuntu1.1] (desktop-core, ubuntu-server)
<Laney> but autopkgtest buffers the output so don't be alarmed if you don't get anything immediately
<Laney> ah, one thing - autopkgtest gets grumpy if the instance doesn't have your locale
<Laney> best to run in C.UTF-8
-queuebot:#ubuntu-release- Unapproved: sane-backends (bionic-proposed/main) [1.0.27-1~experimental3ubuntu2.1 => 1.0.27-1~experimental3ubuntu2.2] (desktop-core, ubuntu-server)
<Locutusofborg> Laney, we have a lot of "neutral" -> "fail" stuff in proposed pocket... would you mind badtesting in case I give you a list?
<cpaelzer> you mean when starting autopkgtest with the ssh runner I should be in C.UTF-8 locally ?
<Laney> yeah
<cpaelzer> ok, thanks
<Laney> I think you would have an explicit error about that though
<Laney> IIRC
<Laney> so it might not be this problem
<xnox> apw:  please force-badtest linux-oem-osp1 for any version, into eoan hints. It is a copy-up v5 kernel targetting bionic toolchain, and it FTBFS in eoan now and blocking proposed migration. Thus it seems to me that we shouldn't care about rebuild test for it, in eoan.
<xnox> (~= oracle kernels, although that FTBFS was kind-of-ish real and affected generic kernels too and was fixed by patching source code)
<Laney> cpaelzer: I could presumably just ssh-import-id you on an instance I run too
<cpaelzer> Laney: if that is allowed I'm fine with that as well
<Laney> don't see why not
<cpaelzer> I want/need to debug the broken case in the only environment where it breaks without consuming too mcuh of your time
<Laney> I can just set it running and then come back in a few minutes once it gets to the broken bit
<cpaelzer> great
<cpaelzer> I'm EOD anyway, leave me a login and I'll work on it tomorrow
<Laney> ok
<Laney> see you
<Laney> cpaelzer: ssh ubuntu@10.48.131.170
<Laney> hope it doesn't time out
<vorlon> gpiccoli: merged, thanks
<gpiccoli> thank you vorlon =)
<gpiccoli> slashd, cascardo ^
-queuebot:#ubuntu-release- Unapproved: accepted openldap [source] (disco-proposed) [2.4.47+dfsg-3ubuntu2.2]
-queuebot:#ubuntu-release- Unapproved: accepted openldap [source] (bionic-proposed) [2.4.45+dfsg-1ubuntu1.4]
-queuebot:#ubuntu-release- Unapproved: accepted openldap [source] (xenial-proposed) [2.4.42+dfsg-2ubuntu3.7]
-queuebot:#ubuntu-release- Unapproved: accepted uw-imap [source] (disco-proposed) [8:2007f~dfsg-5ubuntu0.19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted uw-imap [source] (bionic-proposed) [8:2007f~dfsg-5ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (disco-proposed) [20190801-0ubuntu1~19.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (bionic-proposed) [20190801-0ubuntu1~18.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (xenial-proposed) [20190801-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- Unapproved: lttng-modules (bionic-proposed/universe) [2.10.5-1ubuntu1.2 => 2.10.5-1ubuntu1.3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted amd64-microcode [source] (disco-proposed) [3.20181128.1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted stress-ng [source] (bionic-proposed) [0.09.25-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (bionic-proposed) [2:17.0.11-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted opencryptoki [source] (bionic-proposed) [3.9.0+dfsg-0ubuntu1.2]
<cpaelzer> Laney: thanks - login works
-queuebot:#ubuntu-release- Unapproved: accepted psmisc [source] (xenial-proposed) [22.21-2.1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted snapd-glib [source] (xenial-proposed) [1.49-0ubuntu0.16.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted lttng-modules [source] (bionic-proposed) [2.10.5-1ubuntu1.3]
-queuebot:#ubuntu-release- New binary: python-networkx [amd64] (eoan-proposed/main) [2.2-1ubuntu2] (ubuntu-server)
<bdmurray> RAOF: Are you coming to the SRU team meeting?
-queuebot:#ubuntu-release- New sync: llvm-toolchain-9 (eoan-proposed/primary) [1:9~+rc2-1~exp1]
<RikMills> LP: #1840743
<ubot5> Launchpad bug 1840743 in smokegen (Ubuntu) "Remove smokegen from Eoan" [Undecided,New] https://launchpad.net/bugs/1840743
<RikMills> LP: #1840744
<ubot5> Launchpad bug 1840744 in krecipes (Ubuntu) "Remove krecipes from Eoan" [Undecided,New] https://launchpad.net/bugs/1840744
<RikMills> LP: #1840762
<ubot5> Launchpad bug 1840762 in baloo (Ubuntu) "Remove baloo from Eoan" [Undecided,New] https://launchpad.net/bugs/1840762
<RikMills> is anyone could process those, many thanks :)
<RikMills> *if
<RAOF> bdmurray: ah, crap. Sorry.
<bdmurray> RAOF: no big deal, I only asked since you'd responded yes
<RAOF> Yeah, I do intend to come.
<RAOF> But: (a) I need to set a better reminder, and (b) remember to cancel when I'm sick ð
<vorlon> RikMills: generally no reason to file a separate bug in Ubuntu for a package being removed from Debian
<bdmurray> mwhudson: Did you do any testing of partman-base for bug 1828558 like requested in comment #10?
<ubot5> bug 1828558 in partman-base (Ubuntu Disco) "installing ubuntu on a former md raid volume makes system unusable" [Undecided,Fix committed] https://launchpad.net/bugs/1828558
<mwhudson> bdmurray: no
<mwhudson> bdmurray: i can easily enough though
#ubuntu-release 2019-08-21
<FourDollars> rbasak: Could you help to SRU https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=systemd?
-queuebot:#ubuntu-release- New binary: bitshuffle [amd64] (eoan-proposed/universe) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-hansrodtang-randomcolor [amd64] (eoan-proposed/universe) [0.0~git20160512.d27108b-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bitshuffle [i386] (eoan-proposed/universe) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-gopkg-go-playground-colors.v1 [amd64] (eoan-proposed/universe) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bitshuffle [s390x] (eoan-proposed/universe) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-networkx [amd64] (eoan-proposed) [2.2-1ubuntu2]
-queuebot:#ubuntu-release- New binary: bitshuffle [arm64] (eoan-proposed/universe) [0.3.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: bitshuffle [armhf] (eoan-proposed/universe) [0.3.5-1] (no packageset)
<FourDollars> rbasak: Hi, could you help to approve https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=systemd?
<RikMills> vorlon: ack. I thought someone told me the opposite once, but fair enough
<GunnarHj> Anybody who can override the sane-backends autopkgtest regression? Given all the overrides already there, it looks like somebody just forgot to do it for gscan2pdf/armhf:
<GunnarHj> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sane-backends
<Laney> cpaelzer: looks like it timed out eventually
<cpaelzer> oh
<cpaelzer> did the instance go away
<cpaelzer> Laney: what you gave me for debugging still is good for me
<cpaelzer> if you can leafe it up
<cpaelzer> leave
<cpaelzer> I submitted an RFC patch and a lot of text upstream and I assume that when they get back to me I will need to continue checking/testing things on this instance
<Laney> it's timed out here
<Laney> if the instance is still there, cool
<cpaelzer> yeah, so far it is
<cpaelzer> but ppc64 cleanup is slow
<cpaelzer> if it dies I might get in touch with you once there is feedback from upstream
<Laney> don't think it'll go down by my action
<Laney> just tell me when you're finished
<Laney> good that it helped
<cpaelzer> it did, thanks ++
-queuebot:#ubuntu-release- New binary: libgdata [s390x] (eoan-proposed/main) [0.17.10-1~ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libgdata [arm64] (eoan-proposed/main) [0.17.10-1~ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libgdata [armhf] (eoan-proposed/main) [0.17.10-1~ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New sync: llvm-toolchain-9 (eoan-proposed/primary) [1:9~+rc2-1~exp1]
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-9 [sync] (eoan-proposed) [1:9~+rc2-1~exp1]
-queuebot:#ubuntu-release- New: rejected llvm-toolchain-9 [sync] (eoan-proposed) [1:9~+rc2-1~exp1]
-queuebot:#ubuntu-release- New binary: libgdata [amd64] (eoan-proposed/main) [0.17.10-1~ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libgdata [i386] (eoan-proposed/main) [0.17.10-1~ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-27.28] (core, kernel)
-queuebot:#ubuntu-release- New binary: libgdata [ppc64el] (eoan-proposed/main) [0.17.10-1~ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-27.28] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-27.28] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-27.28]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-27.28]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-27.28]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1018.19] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1015.15] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: shadow (bionic-proposed/main) [1:4.5-1ubuntu2 => 1:4.5-1ubuntu2.1] (core)
-queuebot:#ubuntu-release- Unapproved: shadow (disco-proposed/main) [1:4.5-1.1ubuntu2 => 1:4.5-1.1ubuntu2.1] (core)
-queuebot:#ubuntu-release- Unapproved: shadow (xenial-proposed/main) [1:4.2-3.1ubuntu5.4 => 1:4.2-3.1ubuntu5.5] (core)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1018.19]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1015.15]
-queuebot:#ubuntu-release- Unapproved: lttng-modules (bionic-proposed/universe) [2.10.5-1ubuntu1.3 => 2.10.5-1ubuntu1.3] (no packageset)
-queuebot:#ubuntu-release- New: accepted libgdata [amd64] (eoan-proposed) [0.17.10-1~ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgdata [armhf] (eoan-proposed) [0.17.10-1~ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgdata [ppc64el] (eoan-proposed) [0.17.10-1~ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgdata [arm64] (eoan-proposed) [0.17.10-1~ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgdata [s390x] (eoan-proposed) [0.17.10-1~ubuntu1]
-queuebot:#ubuntu-release- New: accepted libgdata [i386] (eoan-proposed) [0.17.10-1~ubuntu1]
-queuebot:#ubuntu-release- Unapproved: mesa (bionic-proposed/main) [19.0.8-0ubuntu0~18.04.1 => 19.0.8-0ubuntu0~18.04.2] (core, xorg)
-queuebot:#ubuntu-release- New binary: gcc-9 [i386] (eoan-proposed/main) [9.2.1-3ubuntu1] (core)
<lordcirth> Did the root-on-ZFS installer option make it into 19.10? I don't see it in the daily ISO
<xnox> lordcirth:  if it's on phoronix, it must be true =))))) right?! =)))))
<xnox> lordcirth:  we have canary images that do install desktop root-on-zfs, but that's not the default image, but rather an experiment of the underlying tech
<lordcirth> xnox, ah, ok. So it definitely won't be in the official 19.10 ISO?
<xnox> lordcirth:  i made no forward looking statements =) we do time based releases, so we will know what's on the official 19.10 iso.... when it is published in 2019 October.
<xnox> lordcirth:  nobody has a time-machine )
<xnox> lordcirth:  nobody has a time-machine =)
<xnox> lordcirth:  i only explained to you why you don't see it on the current daily iso.... i have no idea the status of that work or plans otherwise.
<lordcirth> xnox, but feature freeze is tomorrow according to: https://wiki.ubuntu.com/EoanErmine/ReleaseSchedule
<xnox> lordcirth:  feel free to play with the canary image off cdimage
<lordcirth> So isn't that the deadline for it to be merged?
<xnox> lordcirth:  and then there are FFe
<xnox> lordcirth:  featurefreeze does not mean that development and merging features stops, simply that one needs more reviews and featurefreezeexcpetion approval.
<lordcirth> Ok, I see.
<xnox> lordcirth:  most flagship things we ever shipped, always landed post FF =)))))
<lordcirth> lol
<xnox> lordcirth:  see https://wiki.ubuntu.com/FreezeExceptionProcess
<doko> apw: linux-oem (4.15.0-1050.57 to 4.15.0-1051.60)
<doko> linux-oem-tools-4.15.0-1051/amd64 unsatisfiable Depends: libbinutils (<< 2.30.1)
<apw> doko, damn
<xnox> doko:  apw: argh
<xnox> doko:  apw: did we not get rid of that dep, by statically linking before?!
<xnox> or was it something else.......
<apw> it was a bug in something which meant we were using it for demangling in perf, when we should not
<xnox> you lost me with that sentence
 * xnox smiles and nods
<doko> apw, xnox: it's only in this variant
<apw> doko, ok so ... i am going to guess we have a missing build-dep
<doko> apw: is this a package built on bionic, and then copied?
<xnox> doko:  yes
<xnox> intentionally
<apw> doko, yes, and it is broken if it is using binutils for anything linking wise
<vorlon> Locutusofborg: uh so mdeslaur has closed LP: #1839596 as wontfix, and you uploaded https://launchpad.net/ubuntu/+source/imagemagick/8:6.9.10.23+dfsg-2.1ubuntu5 which reverted the security update; please reconcile this with the security team
<ubot5`> Launchpad bug 1839596 in imagemagick (Ubuntu Eoan) "imagemagick 8:6.9.10.23+dfsg-2.1ubuntu3 broke reverse-deps" [Critical,Won't fix] https://launchpad.net/bugs/1839596
<vorlon> (the package is stuck in -proposed anyway due to an MIR right now, but we definitely don't want the MIR to unstick it and have it land unexpectedly in eoan release)
-queuebot:#ubuntu-release- New binary: llvm-toolchain-9 [amd64] (eoan-proposed/universe) [1:9~+rc2-1~exp1] (no packageset)
-queuebot:#ubuntu-release- New: accepted llvm-toolchain-9 [amd64] (eoan-proposed) [1:9~+rc2-1~exp1]
-queuebot:#ubuntu-release- Unapproved: net-snmp (disco-proposed/main) [5.7.3+dfsg-5ubuntu1 => 5.7.3+dfsg-5ubuntu1.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: net-snmp (bionic-proposed/main) [5.7.3+dfsg-1.8ubuntu3.1 => 5.7.3+dfsg-1.8ubuntu3.2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: net-snmp (xenial-proposed/main) [5.7.3+dfsg-1ubuntu4.2 => 5.7.3+dfsg-1ubuntu4.3] (desktop-core, ubuntu-server)
#ubuntu-release 2019-08-22
-queuebot:#ubuntu-release- New source: wlcs (eoan-proposed/primary) [1.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted rust-pem [armhf] (eoan-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-pem [s390x] (eoan-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-pem [i386] (eoan-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted bitshuffle [amd64] (eoan-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted bitshuffle [armhf] (eoan-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted bitshuffle [s390x] (eoan-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted golang-gopkg-go-playground-colors.v1 [amd64] (eoan-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-pem [ppc64el] (eoan-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted bitshuffle [arm64] (eoan-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted golang-github-hansrodtang-randomcolor [amd64] (eoan-proposed) [0.0~git20160512.d27108b-1]
-queuebot:#ubuntu-release- New: accepted bitshuffle [i386] (eoan-proposed) [0.3.5-1]
-queuebot:#ubuntu-release- New: accepted rust-pem [arm64] (eoan-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New binary: rust-debcargo [s390x] (eoan-proposed/universe) [2.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-debcargo [amd64] (eoan-proposed/universe) [2.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-debcargo [amd64] (eoan-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-debcargo [s390x] (eoan-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New binary: rust-syntect [i386] (eoan-proposed/universe) [3.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syntect [ppc64el] (eoan-proposed/universe) [3.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syntect [amd64] (eoan-proposed/universe) [3.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-debcargo [ppc64el] (eoan-proposed/universe) [2.4.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-syntect [armhf] (eoan-proposed/universe) [3.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-debcargo [ppc64el] (eoan-proposed) [2.4.0-1]
-queuebot:#ubuntu-release- New: accepted rust-syntect [amd64] (eoan-proposed) [3.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-syntect [i386] (eoan-proposed) [3.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-syntect [armhf] (eoan-proposed) [3.2.0-1]
-queuebot:#ubuntu-release- New: accepted rust-syntect [ppc64el] (eoan-proposed) [3.2.0-1]
-queuebot:#ubuntu-release- New binary: rust-syntect [arm64] (eoan-proposed/universe) [3.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-syntect [arm64] (eoan-proposed) [3.2.0-1]
-queuebot:#ubuntu-release- New binary: rust-bat [amd64] (eoan-proposed/universe) [0.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bat [i386] (eoan-proposed/universe) [0.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bat [s390x] (eoan-proposed/universe) [0.11.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bat [ppc64el] (eoan-proposed/universe) [0.11.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: systemd (disco-proposed/main) [240-6ubuntu5.3 => 240-6ubuntu5.4] (core)
-queuebot:#ubuntu-release- New binary: golang-github-nicksnyder-go-i18n.v2 [amd64] (eoan-proposed/universe) [2.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: transip [amd64] (eoan-proposed/universe) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-abdullin-seq [amd64] (eoan-proposed/universe) [0.0~git20160510.d5467c1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-terra-farm-udnssdk [amd64] (eoan-proposed/universe) [1.3.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-centurylinkcloud-clc-sdk [amd64] (eoan-proposed/universe) [0.0.2+git20161004.f62483c-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-ziutek-mymysql [amd64] (eoan-proposed/universe) [1.5.4+git20170206.23.0582bcf-1] (no packageset)
-queuebot:#ubuntu-release- New binary: znc-push [i386] (eoan-proposed/universe) [1.0.0+git20190521.78d0385-1] (no packageset)
-queuebot:#ubuntu-release- New binary: znc-push [amd64] (eoan-proposed/universe) [1.0.0+git20190521.78d0385-1] (no packageset)
-queuebot:#ubuntu-release- New binary: znc-push [ppc64el] (eoan-proposed/universe) [1.0.0+git20190521.78d0385-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bat [amd64] (eoan-proposed/universe) [0.11.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: znc-push [armhf] (eoan-proposed/universe) [1.0.0+git20190521.78d0385-1] (no packageset)
-queuebot:#ubuntu-release- New binary: znc-push [arm64] (eoan-proposed/universe) [1.0.0+git20190521.78d0385-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bat [i386] (eoan-proposed/universe) [0.11.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: znc-push [s390x] (eoan-proposed/universe) [1.0.0+git20190521.78d0385-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bat [ppc64el] (eoan-proposed/universe) [0.11.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bat [s390x] (eoan-proposed/universe) [0.11.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-bat [arm64] (eoan-proposed/universe) [0.11.0-2] (no packageset)
-queuebot:#ubuntu-release- New: rejected wlcs [source] (eoan-proposed) [1.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: rust-bat [armhf] (eoan-proposed/universe) [0.11.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-bat [arm64] (eoan-proposed) [0.11.0-2]
-queuebot:#ubuntu-release- New: accepted rust-bat [i386] (eoan-proposed) [0.11.0-2]
-queuebot:#ubuntu-release- New: accepted rust-bat [s390x] (eoan-proposed) [0.11.0-2]
-queuebot:#ubuntu-release- New: accepted rust-bat [armhf] (eoan-proposed) [0.11.0-2]
-queuebot:#ubuntu-release- New: accepted znc-push [s390x] (eoan-proposed) [1.0.0+git20190521.78d0385-1]
-queuebot:#ubuntu-release- New: accepted rust-bat [ppc64el] (eoan-proposed) [0.11.0-2]
-queuebot:#ubuntu-release- New: accepted golang-github-centurylinkcloud-clc-sdk [amd64] (eoan-proposed) [0.0.2+git20161004.f62483c-1]
-queuebot:#ubuntu-release- New: accepted golang-github-ziutek-mymysql [amd64] (eoan-proposed) [1.5.4+git20170206.23.0582bcf-1]
-queuebot:#ubuntu-release- New: accepted znc-push [amd64] (eoan-proposed) [1.0.0+git20190521.78d0385-1]
-queuebot:#ubuntu-release- New: accepted znc-push [armhf] (eoan-proposed) [1.0.0+git20190521.78d0385-1]
-queuebot:#ubuntu-release- New: accepted znc-push [ppc64el] (eoan-proposed) [1.0.0+git20190521.78d0385-1]
-queuebot:#ubuntu-release- New: accepted golang-github-terra-farm-udnssdk [amd64] (eoan-proposed) [1.3.4-1]
-queuebot:#ubuntu-release- New: accepted znc-push [arm64] (eoan-proposed) [1.0.0+git20190521.78d0385-1]
-queuebot:#ubuntu-release- New: accepted rust-bat [amd64] (eoan-proposed) [0.11.0-2]
-queuebot:#ubuntu-release- New: accepted znc-push [i386] (eoan-proposed) [1.0.0+git20190521.78d0385-1]
-queuebot:#ubuntu-release- New: accepted golang-github-abdullin-seq [amd64] (eoan-proposed) [0.0~git20160510.d5467c1-1]
-queuebot:#ubuntu-release- New: accepted rust-bat [amd64] (eoan-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New: accepted rust-bat [ppc64el] (eoan-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New: accepted transip [amd64] (eoan-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-nicksnyder-go-i18n.v2 [amd64] (eoan-proposed) [2.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-bat [s390x] (eoan-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New: accepted rust-bat [i386] (eoan-proposed) [0.11.0-1]
-queuebot:#ubuntu-release- New source: wlcs (eoan-proposed/primary) [1.1.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libvirt (bionic-proposed/main) [4.0.0-1ubuntu8.12 => 4.0.0-1ubuntu8.13] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: libvirt (disco-proposed/main) [5.0.0-1ubuntu2.4 => 5.0.0-1ubuntu2.5] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: qemu (disco-proposed/main) [1:3.1+dfsg-2ubuntu3.3 => 1:3.1+dfsg-2ubuntu3.4] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu7.17 => 1:2.11+dfsg-1ubuntu7.18] (ubuntu-server, virt)
<Laney> is libvpx going to get migrated today?
<Laney> We have the new GNOME update prepared in a silo and I didn't want to entangle it with ongoing stuff in proposed
<Laney> also, why was ffmpeg/armhf a badtest? http://autopkgtest.ubuntu.com/packages/f/ffmpeg/eoan/armhf doens't make it look so
<Laney> cyphermox:
<doko> component mismatches are out of date, last run yesterday afternoon
<doko> cjwatson: ^^^ where would I have to look?
<cjwatson> ubuntu-archive@snakefruit, almost certainly stale process following router maintenance
<cjwatson> though I don't see one
<cjwatson> of course it's possible somebody cleared it just before I looked, so wait a bit I guess
-queuebot:#ubuntu-release- New binary: thrift [s390x] (eoan-proposed/universe) [0.11.0-4ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: thrift [amd64] (eoan-proposed/universe) [0.11.0-4ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: thrift [i386] (eoan-proposed/universe) [0.11.0-4ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: thrift [ppc64el] (eoan-proposed/universe) [0.11.0-4ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: thrift [arm64] (eoan-proposed/universe) [0.11.0-4ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: thrift [armhf] (eoan-proposed/universe) [0.11.0-4ubuntu2] (no packageset)
<cyphermox> Laney: to unblock stuff; libvpx, ffmpeg et al. ffmpeg rebuilt to the previous version (was 4.1.4, we reverted that) still segfaults in the sbc codec
<vorlon> cyphermox: and then I re-copied the 4.1.4 ffmpeg and hinted it since it was the same failure
<vorlon> so now it's a candidate
<cyphermox> great
<vorlon> Trying easy from autohinter: anope/2.0.6-1build2 apophenia/1.0+ds-7ubuntu1 apr-util/1.6.1-4build1 argus-clients/1:3.0.8.2-5 asterisk/1:16.2.1~dfsg-2build1 bacula/9.4.2-2ubuntu2 baresip/0.6.1-1build2 cacti-spine/1.2.2-1build1 cl-sql/6.7.0-1.1build2 coturn/4.5.1.1-1.1build1 courier-authlib/0.69.0-2build2 cppdb/0.3.1+dfsg-8ubuntu1 ctn/3.2.0~dfsg-6build2 cvm/0.97-0.1build2
<vorlon> cyrus-sasl2/2.1.27+dfsg-1build2 dbf2mysql/1.14a-5.1build2 double-conversion/3.1.5-2 dovecot/1:2.3.4.1-5ubuntu2 emboss/6.6.0+dfsg-7ubuntu1 evqueue-core/2.1-1build2 exim4/4.92.1-1ubuntu1 ffmpeg/7:4.1.4-1build1 gambas3/3.13.0-1ubuntu1 gammu/1.40.0-1build1 gdal/2.4.2+dfsg-1build1 gearmand/1.1.18+ds-3build3 gentle/1.9+cvs20100605+dfsg1-8 gerbera/1.1.0+dfsg-3build2 gnokii/0.6.31+dfsg-2ubuntu9
<vorlon> gnuais/0.3.3-8build2 gnunet/0.10.1-5.1build2 gnustep-sqlclient/1.8.1-3build4 godot/3.0.6-2build1 grass/7.6.1-3build1 gst-plugins-bad1.0/1.16.0-2ubuntu2 gst-plugins-good1.0/1.16.0-2ubuntu2 handbrake/1.2.2+ds1-1build1 hoel/1.4.8-4build2 http-parser/2.9.2-2 hydra/9.0-1build1 icinga2/2.10.5-1build1 insighttoolkit4/4.12.2-dfsg1-4ubuntu10 inspircd/2.0.27-1ubuntu2 isc-kea/1.5.0-2ubuntu1
<vorlon> jabberd2/2.7.0-1build2 kamailio/5.2.3-1build2 kannel/1.4.5-3ubuntu1 kannel-sqlbox/0.7.2-5build2 kdb/3.1.0-5build3 kodi/2:17.6+dfsg1-4ubuntu4 kopanocore/8.7.0-3build1 lcd4linux/0.11.0~svn1203-2build3 lcgdm/1.13.0-1 libapache-mod-log-sql/1.100-16.3build2 libapache-mod-musicindex/1.4.1-3build2 libdbd-mariadb-perl/1.11-3ubuntu1 libdbd-mysql-perl/4.050-2build1 libdbi-drivers/0.9.0-6ubuntu2
<vorlon> libgda5/5.2.8-1build3 libgit2/0.27.7+dfsg.1-0.2build1 libheif/1.5.0-1build1 libodb-mysql/2.4.0-5ubuntu1 libopendbx/1.4.6-13build3 libpreludedb/4.1.0-2ubuntu5 libreoffice/1:6.3.0-0ubuntu1 libterralib/4.3.0+dfsg.2-11build2 libtoxcore/0.2.10-1build1 libvpx/1.8.1-2 libzdb/3.1-0.2ubuntu1 lua-dbi/0.7.2-1ubuntu1 lua-sql/2.3.4-1build2 lyricue/4.0.13.isreally.4.0.12-0ubuntu3 mailutils/1:3.6-1build1
<cyphermox> wrong window?
<vorlon> mediastreamer2/1:2.16.1-4ubuntu1 minieigen/0.50.3+dfsg1-8build1 motion/4.2.2-1build1 mydumper/0.9.5-1build2 mysql-8.0/8.0.16-0ubuntu3 mysql-connector-c++/1.1.12-4ubuntu1 mysql-ocaml/1.2.1-1ubuntu1 mysqltcl/3.052-3build2 mysqmail/0.4.9-10.2build2 mythtv/2:30.0+fixes.20190817.5cde0578d8-0ubuntu1 ntopng/3.8+dfsg1-2.1build3 ocserv/0.12.2-3build1 opendnssec/1:2.1.3-3build1 opensips/2.2.2-3.1build1
<vorlon> opensmtpd-extras/5.7.1-4build2 orthanc-mysql/2.0-2build2 pam-mysql/0.8.0-1ubuntu3 pdns/4.1.6-3build1 perdition/2.2-3.1 pike8.0/8.0.702-1build1 pmacct/1.7.2-3build1 poco/1.9.2-3ubuntu1 postfix/3.4.5-1build1 postfix-gld/1.7-8build1 proftpd-dfsg/1.3.6-6build1 pure-ftpd/1.0.47-3build1 purple-matrix/0.0.0+git20180325-1build2 pvpgn/1.8.5-2.1build1 python-httptools/0.0.11-1.1
<vorlon> python-mysqldb/1.3.10-2ubuntu1 qsf/1.2.7-1.3build3 qt4-x11/4:4.8.7+dfsg-7ubuntu3 qtbase-opensource-src/5.12.4+dfsg-4build1 qxmpp/1.0.0-4build1 redland/1.0.17-1.1build1 rmysql/0.10.17-2 rsyslog/8.1901.0-1ubuntu3 ruby-dataobjects-mysql/0.10.16-2ubuntu4 ruby-http-parser.rb/0.6.0-4build2 ruby-mysql2/0.5.2-1ubuntu2 sludge/2.2.2-2build1 slurm-llnl/18.08.6.2-1build1 soci/3.2.3-2ubuntu3 sope/4.0.8-1
<vorlon> sphinxsearch/2.2.11-2build1 stardict/3.0.6-0.2build1 tang/7-1build1 tango/9.2.5a+dfsg1-2build2 tarantool-lts/1.5.5.37.g1687c02-1build2 tcpflow/1.5.2+repack1-1build1 tntdb/1.3-4build1 trafficserver/8.0.3+ds-4 trojan/1.12.3-1build1 ulogd2/2.0.7-1build1 utox/0.17.0-1build2 virtualbox/6.0.10-dfsg-5 vlc/3.0.8-2 voms-mysql-plugin/3.1.7-2build1 vtk6/6.3.0+dfsg2-2build7 vtk7/7.1.1+dfsg1-12build2
<vorlon> w1retap/1.4.4-3ubuntu1 x265/3.1.1-2 xine-lib-1.2/1.2.9-1build3 zabbix/1:4.0.4+dfsg-1build1 zoneminder/1.32.3-2build1
<vorlon> only a few things broken by it
<vorlon> :)
<cyphermox> yeah
<cyphermox> I was wondering if you were copy-pasting in the wrong window suddenly
<cyphermox> update-output-helper is usefulish
<vorlon> my irc client has built-in protections against me accidentally doing massive pastes
<vorlon> so you know that when I do it it's because I'm being a jerk
<cyphermox> heh
<cyphermox> I've been copy-pasting the list that goes under that in my terminal, hoping to not wrongly paste in IRC
<cyphermox> vorlon: fyi, not ffmpeg/libvpx but grr was removed from testing, seems like a good candidate for removal. it needs lots and lots of love, more like a major update
<vorlon> qtwebengine-opensource-src at the root of a lot of it
<vorlon> ah.  it's because x265 got reuploaded, and the ffmpeg I synced back hadn't been rebuilt against the new libx265.
<vorlon> gonna play some silly archive tricks again to pick up 4.1.3-1build1 again which /was/, then reupload 4.1.4
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1015.15~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1041.43] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [5.0.0-27.28~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [5.0.0-27.28~18.04.1] (kernel)
<cyphermox> uh, wow
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [5.0.0-1015.15~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [arm64] (bionic-proposed/main) [5.0.0-27.28~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [5.0.0-1015.15~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [5.0.0-27.28~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [5.0.0-27.28~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1015.15~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [arm64] (bionic-proposed) [5.0.0-27.28~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1041.43]
<vorlon> Laney: do you know why we have a non-empty autopkgtest queue for cosmic/arm64?  I guess we should just manually flush those?
-queuebot:#ubuntu-release- New binary: r-bioc-qusage [amd64] (eoan-proposed/universe) [2.18.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-fitdistrplus [amd64] (eoan-proposed/universe) [1.0-14-2] (no packageset)
<vorlon> any time the armhf queue would like to drain would be just fine
-queuebot:#ubuntu-release- New: accepted r-bioc-qusage [amd64] (eoan-proposed) [2.18.0-1]
-queuebot:#ubuntu-release- New: accepted r-cran-fitdistrplus [amd64] (eoan-proposed) [1.0-14-2]
<vorlon> LocutusOfBorg: do you know what the prognosis is for the ghc transition?  I see haskell-hashable is incompatible with the new version and needs sourceful changes and that this holds up a lot of stuff
<teward> vorlon: question of curiosity, during FF are NEW packages still considered?
<teward> or are they 'frozen' i.e. barred as well?
 * teward doesn't know the answer hence asking
<vorlon> teward: they're not "frozen", they just tend to be a low priority
<vorlon> focus tends to be on taking all the stuff stuck in -proposed already and squeezing it through the sausage grinder
<teward> makes sense
<teward> vorlon: thanks
<wxl> on that subject, are there any particular special policies surrounding new packages or do they just get treated like any normal upload?
<wxl> this is probably what i'm looking for, eh? https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<vorlon> no special policies
<vorlon> new packages tend to be "safe" because you can't regress what wasn't there
<wxl> XD
<vorlon> but again, low priority
<wxl> ok thanks!
 * vorlon sees more qt4 stuff going through process-removals, wonders when we'll be done
 * RikMills feels it has no end
-queuebot:#ubuntu-release- New source: lubuntu-update-notifier (eoan-proposed/primary) [0.1]
<teward> vorlon: probably 'never' ;)
-queuebot:#ubuntu-release- New binary: r-cran-seurat [ppc64el] (eoan-proposed/universe) [3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-seurat [s390x] (eoan-proposed/universe) [3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-seurat [i386] (eoan-proposed/universe) [3.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-seurat [amd64] (eoan-proposed/universe) [3.0.2-1] (no packageset)
<RikMills> I'm hoping it can all be gone for the next LTS, but past hopes have come to naught
<RikMills> at least all qt4 is now off the Kubuntu iso!
-queuebot:#ubuntu-release- New binary: r-cran-seurat [armhf] (eoan-proposed/universe) [3.0.2-1] (no packageset)
<teward> vorlon: i know it's on the low priority queue but Lubuntu wants that lubuntu-update-notifier lol
<vorlon> RikMills: well, I just assigned you a bug about an Ubuntu-specific revdep that you can decide what to do with, to help the process along :)
<teward> somehow i've been coopted into multiple dev teams xD
<vorlon> heh
-queuebot:#ubuntu-release- New binary: r-cran-seurat [arm64] (eoan-proposed/universe) [3.0.2-1] (no packageset)
<RikMills> vorlon: I just got the email
<RikMills> plasma-mediacenter is dead as a dodo
-queuebot:#ubuntu-release- New: accepted r-cran-seurat [amd64] (eoan-proposed) [3.0.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-seurat [armhf] (eoan-proposed) [3.0.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-seurat [ppc64el] (eoan-proposed) [3.0.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-seurat [arm64] (eoan-proposed) [3.0.2-1]
-queuebot:#ubuntu-release- New: accepted r-cran-seurat [i386] (eoan-proposed) [3.0.2-1]
<vorlon> RikMills: subscribe ubuntu-archive, turn it into a removal bug, and I'm happy to oblige
-queuebot:#ubuntu-release- New: accepted r-cran-seurat [s390x] (eoan-proposed) [3.0.2-1]
<RikMills> vorlon: done
-queuebot:#ubuntu-release- New: accepted thrift [amd64] (eoan-proposed) [0.11.0-4ubuntu2]
-queuebot:#ubuntu-release- New: accepted thrift [i386] (eoan-proposed) [0.11.0-4ubuntu2]
-queuebot:#ubuntu-release- New: accepted thrift [s390x] (eoan-proposed) [0.11.0-4ubuntu2]
-queuebot:#ubuntu-release- New: accepted thrift [armhf] (eoan-proposed) [0.11.0-4ubuntu2]
-queuebot:#ubuntu-release- New: accepted thrift [ppc64el] (eoan-proposed) [0.11.0-4ubuntu2]
-queuebot:#ubuntu-release- New: accepted thrift [arm64] (eoan-proposed) [0.11.0-4ubuntu2]
<vorlon> I feel like 'geneatd' should be the name of an atd implementation that used ml to train its parser for NLP
<RikMills> past convention says feature freeze is NOW
-queuebot:#ubuntu-release- New binary: gcc-9-cross-ports [ppc64el] (eoan-proposed/universe) [9ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gcc-9-cross-ports [ppc64el] (eoan-proposed) [9ubuntu1]
* vorlon changed the topic of #ubuntu-release to: Released: Bionic 18.04.3, Disco 19.04 | Archive: Feature Freeze | Eoan Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melius malum quod cognoscis
<tsimonq2> vorlon: Ready for one big "just axe literally all of Qt 4" request? :P
-queuebot:#ubuntu-release- New binary: gnuradio [s390x] (eoan-proposed/universe) [3.8.0.0-2] (no packageset)
<vorlon> tsimonq2: probably not, as those become unwieldly to manage bug tasks on?
<tsimonq2> Â¯\_(ã)_/Â¯
<tsimonq2> I'll just convert existing "please port to Qt 4" to "remove pls"
<vorlon> right, that's probably reasonable
<tsimonq2> vorlon: Let's just say I've already tried the "let's put it all in one bug" approach...
<tsimonq2> Somehow I managed to do it.
<seb128> don't do that please, it spams to no end people subscribed to any of the component even if the thing they care about is fixed
<tsimonq2> seb128: I know now.
<tsimonq2> Early 2018 tsimonq2 did not.
<seb128> or if it's not fixed they get the spam/comments/activity for any of the others
<tsimonq2> We're on the same page :)
<seb128> good :-)
<teward> archive admins: reject lubuntu update notifier please from NEW
<teward> Blame Simon
<teward> I am gonna drag him out back later.
<tsimonq2> heh
<teward> And deal with him later.
-queuebot:#ubuntu-release- New binary: gnuradio [amd64] (eoan-proposed/universe) [3.8.0.0-2] (no packageset)
<tsimonq2> teward: My point to you was not that it's bad, it was that uploading something to NEW that I had an outstanding review on before I had a chance to review changes wasn't particularly collaborative.
-queuebot:#ubuntu-release- New: rejected lubuntu-update-notifier [source] (eoan-proposed) [0.1]
<teward> That could have been directed privately simon
<teward> Rather than a call out here.
-queuebot:#ubuntu-release- New: accepted gnuradio [amd64] (eoan-proposed) [3.8.0.0-2]
-queuebot:#ubuntu-release- New: accepted gnuradio [s390x] (eoan-proposed) [3.8.0.0-2]
<tsimonq2> teward: Well, you did publicly ask for a reject :)
<teward> Thanks for the rejects AAs.
<teward> tsimonq2: rejects yes.  Callout about why?  No.
<teward> Common Courtesy applies here
<teward> And that was failed by you
<teward> E:NotHappy
<tsimonq2> Let's not get into it here.
<teward> Agreed.  Weâll shoot each other in PM :P
-queuebot:#ubuntu-release- New binary: gnuradio [ppc64el] (eoan-proposed/universe) [3.8.0.0-2] (no packageset)
<tsimonq2> vorlon: axing Qt 4> https://lists.ubuntu.com/archives/ubuntu-devel/2019-August/040783.html emailed :)
<vorlon> well, apparently reverse-depends lied to me about src:rust-num-traits
<vorlon> because virtual packages?
-queuebot:#ubuntu-release- Unapproved: util-linux (disco-proposed/main) [2.33.1-0.1ubuntu2 => 2.33.1-0.1ubuntu3] (core)
<Eickmeyer> vorlon, tsimonq2: Not sure, but saw two reverse deps on that list you emailed. I know one of them is likely carla, so I could probably fix that and upload since the project was ported to Qt 5 some time ago. Of course, I'm not 100% sure that's the hangup.
<tsimonq2> Eickmeyer: Please do ASAP.
<Eickmeyer> vorlon, tsimonq2: Additionally, I definitely don't have any idea where the hangup is in ubuntustudio-publishing, so that will require some time looking through the seed, unless there's a faster way.
<tsimonq2> Eickmeyer: The transition tracker will update with a Qt 4 removal tracker Soon, that should show you which level it's at.
<tsimonq2> https://people.canonical.com/~ubuntu-archive/transitions/
-queuebot:#ubuntu-release- Unapproved: util-linux (bionic-proposed/main) [2.31.1-0.4ubuntu3.3 => 2.31.1-0.4ubuntu3.4] (core)
<Eickmeyer> tsimonq2: ack
<vorlon> scribus
<tsimonq2> vorlon: You wouldn't happen to know offhand if the transition tracker is hourly cron, would you?
<vorlon> I would not
<tsimonq2> ack
<Eickmeyer> vorlon, tsimonq2: Yikes. scribus is synced from Debian, so it needs to be dealt with there.
#ubuntu-release 2019-08-23
<tsimonq2> Eickmeyer: It'll be removed mid next month anyway: https://bugs.debian.org/875180
<tsimonq2> Eickmeyer: You're welcome to make a case to sync from Experimental.
<Eickmeyer> tsimonq2: I was just in the process of checking on the status of a Qt 5 port, but maybe you could tell me for sure just offhand?
-queuebot:#ubuntu-release- Unapproved: util-linux (xenial-proposed/main) [2.27.1-6ubuntu3.7 => 2.27.1-6ubuntu3.8] (core)
<tsimonq2> Eickmeyer: mapreri says in the bug that there's scribus-ng in Experimental that's "stable" but not prod-ready.
<Eickmeyer> tsimonq2: *le sigh*
<Eickmeyer> tsimonq2: Well, at least we have some time before we have to go down that road as this doesn't affect Eoan. In the meantime, I'm going to nuke the Qt 4 dep in carla and see what happens in my PPA before I do an actual upload.
<tsimonq2> Eickmeyer: That's your call. Give the new scribus a test and see if Mattia's just being on the safe side (wouldn't be unlike him to be extra cautious, he was a sponsor of mine pre-MOTU :) ) or if it's really unstable.
<tsimonq2> Eickmeyer: doesn't effect Eoan> Please don't procrastinate though. :P
<tsimonq2> Wimpress: ^ Qt 4 removal also affects Ubuntu MATE.
<Eickmeyer> tsimonq2: Of course not, but 1) I'm technically on vacation this week, and 2) other reasons.
<tsimonq2> Eickmeyer: Alright.
<tsimonq2> Eickmeyer: That was the point of the email, to communicate that some gears should start moving here. :)
<Eickmeyer> tsimonq2: I'm just lucky I have some time to look at carla atm.
<tsimonq2> Eickmeyer: No worries, get it done when you can.
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu10.26]
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (disco-proposed) [240-6ubuntu5.4]
-queuebot:#ubuntu-release- New binary: gcc-9-cross [ppc64el] (eoan-proposed/main) [10ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gcc-9-cross [amd64] (eoan-proposed/main) [10ubuntu1] (ubuntu-desktop)
<tsimonq2> Eickmeyer: https://people.canonical.com/~ubuntu-archive/transitions/html/qt4-rm.html
-queuebot:#ubuntu-release- New binary: gcc-9-cross-ports [i386] (eoan-proposed/universe) [9ubuntu1] (no packageset)
<Eickmeyer> tsimonq2: ack, and dep in carla is now removed (UNRELATED: You and I are in the same time zone rn).
<tsimonq2> Eickmeyer: Oh yeah?
<tsimonq2> The best timezone.
<Eickmeyer> CST. Dallas. Sis-in-law's wedding.
<Eickmeyer> *CDT
<tsimonq2> Nice!
<tsimonq2> Congrats to them :)
<Eickmeyer> She says thanks. Wedding is Tuesday.
 * Eickmeyer goes back to lurk mode
-queuebot:#ubuntu-release- New binary: gcc-9-cross [i386] (eoan-proposed/main) [10ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New source: lubuntu-update-notifier (eoan-proposed/primary) [0.1]
<tsimonq2> vorlon: ^^ easy package, it's Lintian-clean.
-queuebot:#ubuntu-release- New binary: gcc-9-cross-ports [amd64] (eoan-proposed/universe) [9ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gcc-9-cross-ports [amd64] (eoan-proposed) [9ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-9-cross [amd64] (eoan-proposed) [10ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-9-cross-ports [i386] (eoan-proposed) [9ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-9-cross [ppc64el] (eoan-proposed) [10ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-9-cross [i386] (eoan-proposed) [10ubuntu1]
<LocutusOfBorg> hello, looks like somebody accepted gnuradion everywhere modulo ppc64el... can you please accept it too?
<vorlon> rbalint: it looks like your systemd ppa is killing the armhf test runners
-queuebot:#ubuntu-release- New: accepted gnuradio [ppc64el] (eoan-proposed) [3.8.0.0-2]
<vorlon> LocutusOfBorg: ^^
<vorlon> rbalint: removing netplan.io seems ill-advised.  https://paste.ubuntu.com/p/kPJ67gyy8F/  I'll flush the rest of these tests from the queue so that the rest of the tests can run
<LocutusOfBorg> thanks!
<vorlon> doko: cctools has been ftbfs for 233 days in -proposed with compiler errors about failed inlining; but this error isn't reproducible in Debian, including with libc6-dev from experimental.  How do I see what's different in the compiler defaults between Debian and Ubuntu?
<LocutusOfBorg> vorlon, kicking out sagemath sagetex from eoan to proposed will probably make a lot of stuff migrate, e.g. texlive and so on
<LocutusOfBorg> they are utterly broken
<vorlon> LocutusOfBorg: utterly broken> evidence?
<LocutusOfBorg> sagemath has 4 rc bugs
<LocutusOfBorg> for different failures
<LocutusOfBorg> they don't build because of new readline, new python, new gcc
<LocutusOfBorg> and test failures
<vorlon> ok
<doko> vorlon: glibc
<LocutusOfBorg> the new release works, but needs another set of dependencies
<LocutusOfBorg> and debian maintainer is slowly adapting it
 * LocutusOfBorg finds that debian tracker is down
<vorlon> doko: so there's a relevant glibc difference between the 2.29 in disco/eoan and in experimental?
<doko> vorlon: I didn't look
<doko> hmm, but if it's 233 days, then it's not a glibc version difference
-queuebot:#ubuntu-release- New binary: gcc-defaults [s390x] (eoan-proposed/main) [1.184ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: gcc-defaults [armhf] (eoan-proposed/main) [1.184ubuntu1] (core)
<tsimonq2> https://bazaar.launchpad.net/~ubuntu-transition-trackers/ubuntu-transition-tracker/configs/revision/718 too
-queuebot:#ubuntu-release- New binary: gcc-defaults [amd64] (eoan-proposed/main) [1.184ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: gcc-defaults [i386] (eoan-proposed/main) [1.184ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: gcc-defaults [arm64] (eoan-proposed/main) [1.184ubuntu1] (core)
-queuebot:#ubuntu-release- New binary: gcc-defaults [ppc64el] (eoan-proposed/main) [1.184ubuntu1] (core)
-queuebot:#ubuntu-release- New: accepted gcc-defaults [amd64] (eoan-proposed) [1.184ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-defaults [armhf] (eoan-proposed) [1.184ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-defaults [ppc64el] (eoan-proposed) [1.184ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-defaults [arm64] (eoan-proposed) [1.184ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-defaults [s390x] (eoan-proposed) [1.184ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-defaults [i386] (eoan-proposed) [1.184ubuntu1]
<LocutusOfBorg> vorlon, is it possible to remove deal.ii on arm64 please?
<LocutusOfBorg> I spent at least one week trying to fix the failure, no luck, old gcc, old binutils, less parallelism, another linker
<LocutusOfBorg> Debian has similar failures on ppc64el...  and meh: 925668
<LocutusOfBorg> we should make some transition move forward, and deal.ii is blocking 6 transitions
<LocutusOfBorg> Trying easy from autohinter: dijitso/2019.1.0-2 dolfin/2019.1.0-4 fenics/1:2019.1.0.2 ffc/2019.1.0.post0-2 fiat/2019.1.0-2 getdp/3.0.4+dfsg1-1build1 hypre/2.16.0-4 mshr/2019.1.0+dfsg1-4 petsc/3.11.3+dfsg1-2 petsc4py/3.11.0-2 pybind11/2.3.0-2 slepc/3.11.2+dfsg1-1 slepc4py/3.11.0-2 sundials/3.1.2+dfsg-3build3 ufl/2019.1.0-2
<LocutusOfBorg> this one will go if we remove one single binary
<LocutusOfBorg> I suspect ginggs will fix the failures in a Debian upload eventually :D
<LocutusOfBorg> if this one migrates, I can focus then on haskell and finish ocaml
<LocutusOfBorg> (ocaml needs few removals too, I filed bugs already)
-queuebot:#ubuntu-release- New binary: gcc-defaults-ports [ppc64el] (eoan-proposed/universe) [1.184ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: gcc-defaults-ports [arm64] (eoan-proposed/universe) [1.184ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: gcc-defaults-ports [amd64] (eoan-proposed/universe) [1.184ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: gcc-defaults-ports [i386] (eoan-proposed/universe) [1.184ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected mesa [source] (bionic-proposed) [19.0.8-0ubuntu0~18.04.2]
-queuebot:#ubuntu-release- New: accepted gcc-defaults-ports [amd64] (eoan-proposed) [1.184ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-defaults-ports [i386] (eoan-proposed) [1.184ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-defaults-ports [arm64] (eoan-proposed) [1.184ubuntu1]
-queuebot:#ubuntu-release- New: accepted gcc-defaults-ports [ppc64el] (eoan-proposed) [1.184ubuntu1]
<doko> sforshee, apw: is this something which can be solved by retrying?
<doko> II: dkms-build downloading nvidia-430 (nvidia-kernel-source-430_430.40-0ubuntu1_amd64.deb)
<doko> --2019-08-23 01:19:43--  http://ftpmaster.internal/ubuntu/pool/restricted/n/nvidia-graphics-drivers-430/nvidia-kernel-source-430_430.40-0ubuntu1_amd64.deb
<doko> Resolving ftpmaster.internal (ftpmaster.internal)... 91.189.89.99
<doko> Connecting to ftpmaster.internal (ftpmaster.internal)|91.189.89.99|:80... connected.
<doko> HTTP request sent, awaiting response... 404 Not Found
<doko> 2019-08-23 01:19:43 ERROR 404: Not Found.
<apw> doko, nope
<apw> doko, it needs that bit turning off ... i think sforshee is working on that ... if that is hte last failure i can hint it
-queuebot:#ubuntu-release- Unapproved: smc-tools (disco-proposed/universe) [1.2.0-0ubuntu1 => 1.2.0-0ubuntu1.1] (no packageset)
<doko> apw: it is, for gcc-9, afaics
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (disco-proposed) [2.33.1-0.1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (bionic-proposed) [2.31.1-0.4ubuntu3.4]
-queuebot:#ubuntu-release- Unapproved: accepted util-linux [source] (xenial-proposed) [2.27.1-6ubuntu3.8]
<LocutusOfBorg> Laney, can you please blacklist tests for: rust-byteorder rust-rayon rust-derive-more rust-doc-comment rust-quick-xml ?
<LocutusOfBorg> they are all result of "hey we suck at going from neutral to bad, so we consider them bad now and dh-cargo is blocked"
<LocutusOfBorg> the last three packages have been patched by me to just hide the issue, but I would like to sync them again
<Laney> badtest?
<LocutusOfBorg> ignore forever
<Laney> that would not normally be blacklist
<Laney> but no, not me, sorry, I'm at guadec right now
<LocutusOfBorg> Laney, I think badtest yes
<LocutusOfBorg> https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/3810
<LocutusOfBorg> same as here
<LocutusOfBorg> apw, ^^ can you please add rust-byteorder rust-rayon rust-derive-more rust-doc-comment rust-quick-xml to that list?
<mitya57> Can someone please process bug 1840190? We really donât want *two* qt4 webkit sources in Eoan, ideally we want none of them.
<mitya57> no bot, so: https://bugs.launchpad.net/ubuntu/+source/qtwebkit-source/+bug/1840190 [qtwebkit-source] Remove from eoan archive
<LocutusOfBorg> mitya57, actually the old qtwebkit-source should be binary free
<LocutusOfBorg> so, an old cruft around that shouldn't hurt too much, binaries have been taken over by qtwebkit
<LocutusOfBorg> there might be some -dbg package probably
<LocutusOfBorg> but meh
<mitya57> LocutusOfBorg: I am right now looking at what still uses qt4 webkit in Eoan. There are just a few packages that use it directly (https://people.canonical.com/~ubuntu-archive/transitions/html/qtwebkit-rm.html) but some other are using it indirectly (e.g. via pyside).
<mitya57> I hope we will be able to remove them all from Eoan, so I decided to start from a low hanging fruit first :)
<LocutusOfBorg> :)
<mitya57> LocutusOfBorg: do you mind if we remove qutim? You touched it last
<mitya57> Or if you care, maybe you can update it from 0.2.0 (released in 2009) to a newer release from https://github.com/euroelessar/qutim/releases?
<LocutusOfBorg> I don't really care, I just no-change rebuilt to pick up new webkit
<LocutusOfBorg> you should probably ask somebody who worked on it, no change rebuilds doesn't count :P
<mitya57> From the changelog, I think the only person who realy cared about it was Maia Kozheva, but that was in 2010. So filing RM :)
<mitya57> Done @ https://bugs.launchpad.net/ubuntu/+source/qutim/+bug/1841178
<ubot5> Launchpad bug 1841178 in qutim (Ubuntu) "Please remove qutim from Eoan archive" [Undecided,New]
<doko> rbasak: are you trying to do a php transition?
<doko> php7.3 doesn't have a subscriber
<rbasak> doko: yes, and sorry, I've subscribed ~ubuntu-server now.
<doko> apw: did you override anything gor the linux autopkg test?
<apw> doko, not as yet, sorry missed your reply
<apw> doko, done
<doko> ta
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [5.0.0-1018.19~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [5.0.0-1018.19~18.04.1]
-queuebot:#ubuntu-release- New binary: featherpad [amd64] (eoan-proposed/universe) [0.11.1-1~build1] (lubuntu)
<vorlon> doko: right, so my question was where's the right place to look for differences in compiler options used between Debian and Ubunut
<vorlon> LocutusOfBorg: deal.ii> that gcc-9 build failure doesn't show up on https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20190614-gcc9-eoan.html so doesn't seem to be a good rationale for removal.  And it's an Ubuntu-specific build failure - you mention Debian having a similar failure on ppc64el, but the package is up-to-date on ppc64el in Debian.  However, I think a rationale that
<vorlon> satisfies me here is that it's a leaf package blocking transitions, which justifies removal, and if we removed it it would come right back in from Debian without the arm64 binary
<vorlon> LP: #1841209 for the desktop image builds now being broken after yesterday's migration
<ubot5> Launchpad bug 1841209 in libreoffice (Ubuntu) " libreoffice-help-common : Depends: libjs-normalize.css but it is not installable" [High,New] https://launchpad.net/bugs/1841209
<vorlon> I have no idea why this wasn't caught by britney on the frontend, a main->universe dependency should've kept libreoffice from being a candidate
<LocutusOfBorg> vorlon, in debian no builds with gcc-9 defaults have been done yet
<LocutusOfBorg> but tomorrow ginggs will do one :)
<LocutusOfBorg> so, you can't easily say if Debian is broken or not...
<LocutusOfBorg> in any case I hope tomorrow to have an answer to you
<vorlon> LocutusOfBorg: no, but I can say that deal.ii doesn't ftbfs in *Ubuntu* with gcc-9
<ginggs> i will be uploading deal.ii tomorrow, or as soon as trilinos is built
<ginggs> ^ in debian
<LocutusOfBorg> vorlon, meh, gcc changed a lot since that rebuild
<ginggs> LocutusOfBorg: didn't deal.ii ftbfs with gcc 8 in your ppa?
<LocutusOfBorg> yes ginggs
<LocutusOfBorg> also deal.ii version changed
<LocutusOfBorg> that is my best bet then
<LocutusOfBorg> so the new deal.ii version is broken on arm64?
<ginggs> LocutusOfBorg: not in debian with gcc 8 as default
<LocutusOfBorg> some combo of different factors, for sure
 * vorlon sorts out pcc-libs + pcc, is a stupid circular dep that requires deleting pcc to rebootstrap
<LocutusOfBorg> vorlon, I did sourceful fixes for haskell levels 2-3 and 4
<LocutusOfBorg> this requires lot of time
 * vorlon nods
<vorlon> LocutusOfBorg: are you fixing these in Ubuntu or Debian?  Where are the Debian maintainers on this?
-queuebot:#ubuntu-release- New binary: pcc-libs [amd64] (eoan-proposed/universe) [1.2.0~DEVEL+20180604-2.1] (no packageset)
-queuebot:#ubuntu-release- New binary: pcc-libs [i386] (eoan-proposed/universe) [1.2.0~DEVEL+20180604-2.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pcc-libs [amd64] (eoan-proposed) [1.2.0~DEVEL+20180604-2.1]
-queuebot:#ubuntu-release- New: accepted pcc-libs [i386] (eoan-proposed) [1.2.0~DEVEL+20180604-2.1]
<RikMills> vorlon: new debian sysbench in proposed now excludes building on armhf, so can we lose that binary in release?
<vorlon> RikMills: having confirmed that Debian has also dropped the armhf binary from the archive, yes
<vorlon> (done)
<LocutusOfBorg> vorlon, both, at the same time
<vorlon> ok
<LocutusOfBorg> I'll sync later tonight them, but ,meh, they are the same
<LocutusOfBorg> modulo one, I did a mistake "0.2.0.5-8~builld1" (double l"
<LocutusOfBorg> also, two builds, were stuck on s390x during testsuite
<LocutusOfBorg> I just disabled the testsuite and didn't forward in Debian
<LocutusOfBorg> I'll see how they fix it, and they are called ubuntu1
<LocutusOfBorg> haskell-prettyprinter-ansi-terminal	and haskell-terminal-progress-bar	
<LocutusOfBorg> if you want to have a look!
<LocutusOfBorg> build was killed after 120 minutes
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/haskell-terminal-progress-bar/0.4.1-1build1/+build/17368818
<LocutusOfBorg> (btw reverse-deps are good)
<marcustomlinson> vorlon: re: bug 1841209
<ubot5> bug 1841209 in libreoffice (Ubuntu) " libreoffice-help-common : Depends: libjs-normalize.css but it is not installable" [High,In progress] https://launchpad.net/bugs/1841209
<marcustomlinson> vorlon: could you sponsor the upload for me?
<vorlon> marcustomlinson: link to upload?
<marcustomlinson> vorlon: https://drive.google.com/drive/folders/1NeNKRY3Rex3SXgcTTKlRloCZr0_S-QNw?usp=sharing
<vorlon> marcustomlinson: (does this also drop the gstreamer bad/ugly?)
<marcustomlinson> vorlon: yes
<vorlon> excellent
<vorlon> marcustomlinson: why the jump from 0ubuntu1 to 0ubuntu5?
<marcustomlinson> vorlon: the desktop team has been stacking builds here: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3762/+packages
<marcustomlinson> for ff
<vorlon> ok
<vorlon> marcustomlinson: changelog has the wrong syntax for bug closures (missing the # before the bug #)
<vorlon> marcustomlinson: what is the effect on the usability of the help to have normalize.css absent?
<marcustomlinson> vorlon: sorry I'll fix that now
<marcustomlinson> vorlon: no effect, there is a builtin fallback for when the normalize.css package is not found
<marcustomlinson> vorlon: have you uploaded already? Can I reuse 0ubuntu5?
<marcustomlinson> vorlon: or are you just saying the syntax is wrong, fix it in vcs, and now watch the bugs manually
<vorlon> marcustomlinson: please reuse the number and reupload :)
<vorlon> and then I'll sponsor
<marcustomlinson> vorlon: ok loading...
<marcustomlinson> vorlon: ok update, same link
<marcustomlinson> *updated
<vorlon> marcustomlinson: ok.  .changes file also built with the wrong -v version (we want the changes for all versions since the one currently in eoan), but I will fix that up on my side and upload
<marcustomlinson> thank you so much vorlon. sorry for the pain
-queuebot:#ubuntu-release- Unapproved: cloud-init (disco-proposed/main) [19.1-1-gbaa47854-0ubuntu1~19.04.1 => 19.2-21-ge6383719-0ubuntu1~19.04.1] (core, edubuntu, ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [19.1-1-gbaa47854-0ubuntu1~18.04.1 => 19.2-21-ge6383719-0ubuntu1~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [19.1-1-gbaa47854-0ubuntu1~16.04.1 => 19.2-21-ge6383719-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<coreycb> vorlon: i'd really like to clear out these eoan-proposed openstack packages but i'm having a hard time finding what the issue is
<coreycb> vorlon: i'm assuming there's a py2 binary that's been removed that is still being used as a dependency
<blackboxsw> tjaalton: or vorlon(backup SRU), if possible, we'd have cloud-init in queue for (xenial|bionic|disco)-proposed  that we'd like to start testing if we get a chance to approve today
<vorlon> blackboxsw: by any reasonable measure it's past eod for tjaalton; I'll try to take a look this afternoon
<coreycb> vorlon: if you have any tips let me know. i've been looking at a few different reports but not making progress (nbs and update_output.txt)
<vorlon> coreycb: give me a package name to key off?
<coreycb> vorlon: a simple one from https://people.canonical.com/~ubuntu-archive/nbs.html is python-aodhclient
<blackboxsw> thx vorlon, I just don't like pinging 'the backup' in my primary SRU request :)
<vorlon> coreycb: well, nbs is different than proposed-migration
<vorlon> coreycb: what's a package that's currently stuck in proposed?  since aodh doesn't seem to be there
<coreycb> vorlon: i want to figure out what's blocking the ones that are listed as candidate here: http://michael.hudsondoyle.geek.nz/team-summary.html#ubuntu-openstack
<vorlon> coreycb: ok - fwiw that report now officially lives at https://people.canonical.com/~ubuntu-archive/proposed-migration/eoan/update_excuses_by_team.html#ubuntu-openstack
<coreycb> ok thanks
<vorlon> coreycb: alright, some of these are clearly chicken-and-egg issues, the line 'trying: python-oslo.messaging python-futurist nova python-os-service-types python-openstacksdk senlin python-keystoneauth1 python-neutronclient python-keystoneclient python-osc-lib python-os-client-config python-glanceclient python-cinderclient ceilometer python-novaclient watcher python-openstackclient python-amqp kombu'
<vorlon> in update_output fails mostly because it makes a bunch of packages, which are already NBS and only held in because they're build-dependencies of the old versions, uninstallable
<vorlon> coreycb: so I'll clear some of that out by hand, but e.g. python-celery is listed as being made uninstallable and is not NBS
<vorlon> coreycb: these are not NBS, so require further investigation: python-celery python-flower python-heatclient python-keystonemiddleware python-mistralclient python-swiftclient
<coreycb> vorlon: awesome thanks so much. i'll take a closer look at those.
<vorlon> coreycb: flower has a removal bug LP: #1838213, that will also unblock celery
<ubot5> Launchpad bug 1838213 in twitter-bootstrap (Ubuntu) "remove twitter-bootstrap from eoan" [Undecided,New] https://launchpad.net/bugs/1838213
<coreycb> vorlon: great
<vorlon> ah and flower just got removed from unstable today so I'll run that through
<RikMills> I assume mysql-5.7 is going to be removed completely soon?
<vorlon> I can't speak to the timeline on that
<vorlon> I expect it would be removed before release
<RikMills> right. 'soon' is before release for me
<RikMills> KDE akonadi doesn't work with 8 at the moment, so if can't depend on 5.7 we have to switch to mariadb
<doko> vorlon: well, we have the two new hardening flags in eoan now, which are not yet in unstable
<vorlon> doko: remind me which ones those are, so I can test reverting them?
<doko> apw (or vorlon): please ignore the linux autopkg test for gcc-defaults (as done for gcc-9)
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (disco-proposed) [19.2-21-ge6383719-0ubuntu1~19.04.1]
<doko> vorlon: see u-d ("New gcc hardening defaults in eoan (-fstack-clash-protection + -fcf-protection)")
<doko> but if the package is that long in -proposed, then it's certainly not that one
<vorlon> right
<vorlon> ok
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (bionic-proposed) [19.2-21-ge6383719-0ubuntu1~18.04.1]
<vorlon> coreycb: python-heatclient should be unblocked now that python-senlinclient is removed
<vorlon> python-keystonemiddleware is blocked by nova autopkgtest on armhf
<vorlon> python-mistralclient should be unblocked now that python-troveclient is removed
<coreycb> vorlon: great. ok will take a look. i'll chat with dan watkins about simplestreams as it depends on python-swiftclient.
<coreycb> vorlon: thanks should cover everything. thanks again.
<vorlon> ok
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [19.2-21-ge6383719-0ubuntu1~16.04.1]
<blackboxsw> woot! thx Mr V
<vorlon> RAOF: lintian -I points out that the wlcs debian/copyright has some wrong filenames... I think that should be tests/xdg* instead of xdg*
-queuebot:#ubuntu-release- New: accepted wlcs [source] (eoan-proposed) [1.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted featherpad [amd64] (eoan-proposed) [0.11.1-1~build1]
-queuebot:#ubuntu-release- New binary: wlcs [amd64] (eoan-proposed/none) [1.1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: wlcs [i386] (eoan-proposed/none) [1.1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: wlcs [ppc64el] (eoan-proposed/none) [1.1.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: wlcs [armhf] (eoan-proposed/none) [1.1.0-0ubuntu1] (no packageset)
<ginggs> LocutusOfBorg: spoiler alert: deal.ii built on arm64 with gcc 9 on debian porterbox
-queuebot:#ubuntu-release- New binary: wlcs [arm64] (eoan-proposed/universe) [1.1.0-0ubuntu1] (no packageset)
<vorlon> tsimonq2: so, uh
<vorlon> tsimonq2: licensecheck on lubuntu-update-notifier clearly picks up that the files are licensed under GPL-3+
<vorlon> tsimonq2: and your debian/copyright claims GPL-2+
-queuebot:#ubuntu-release- New: rejected lubuntu-update-notifier [source] (eoan-proposed) [0.1]
<vorlon> LocutusOfBorg: deal.ii is no longer blocked by the ftbfs... just by its autopkgtests all failing
<Odd_Bloke> powersj: coreycb has reached out to me asking for a new upload of simplestreams to drop a Build-Depends on python-swiftclient.  I've prepared this (https://paste.ubuntu.com/p/Qwhjps6M6R/) but need a sponsor again.  Who should I bug?
<powersj> Odd_Bloke, coreycb is there a bug?
<powersj> if not, please file one and attach your patch
<coreycb> Odd_Bloke: thanks wasn't expecting such a quick turn-around
<coreycb> powersj: no it just unblocks python-swiftclient from eoan-proposed but I can
<coreycb> Odd_Bloke: powersj: https://bugs.launchpad.net/ubuntu/+source/simplestreams/+bug/1841277
<ubot5> Launchpad bug 1841277 in simplestreams (Ubuntu) "please drop python-swiftclient BD" [Undecided,New]
-queuebot:#ubuntu-release- New: accepted wlcs [amd64] (eoan-proposed) [1.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted wlcs [armhf] (eoan-proposed) [1.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted wlcs [ppc64el] (eoan-proposed) [1.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted wlcs [arm64] (eoan-proposed) [1.1.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted wlcs [i386] (eoan-proposed) [1.1.0-0ubuntu1]
<powersj> Odd_Bloke, can you update your patch. Do we actually need to drop python-glanceclient as well?
<Odd_Bloke> powersj: No, but we can.  I tried dropping keystoneclient and that _does_ cause problems.
<powersj> coreycb, thanks for the bug, I'll get someone to upload probably monday
<coreycb> powersj: that'll work
<coreycb> Odd_Bloke: hmm yeah we'll have to drop keystoneclient too
<Odd_Bloke> coreycb: We have reverse deps on the Python 2 packages which mean we can't just remove them, so that one is harder to address.
<Odd_Bloke> powersj: Patch attached (and also pushed to the ubuntu/devel branch of the repo).
<coreycb> Odd_Bloke: ok. we've deopped all py2 openstack pkgs in eoan.   maybe we can chat more next week.
<coreycb> dropped
<ginggs> vorlon, LocutusOfBorg: seems a bit odd that the deal.ii autopkgtest pulls in libp4est-1.1 and libp4est-2.2
<vorlon> maybe retry with --all-proposed?
<ginggs> vorlon: ack, doing...
<Odd_Bloke> coreycb: I'm out next week, so you probably need to talk to powersj.
<coreycb> Odd_Bloke: ok enjoy
<ginggs> vorlon: al-proposed did it, but please 'force-badtest deal.ii/9.1.1-3/arm64' for now
<vorlon> ginggs: done
<ginggs> vorlon: thanks!
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-60.67] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-60.67] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1020.22] (no packageset)
-queuebot:#ubuntu-release- New binary: mir [ppc64el] (eoan-proposed/main) [1.4.0-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mir [i386] (eoan-proposed/main) [1.4.0-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mir [armhf] (eoan-proposed/main) [1.4.0-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: mir [arm64] (eoan-proposed/main) [1.4.0-0ubuntu1] (ubuntu-desktop)
#ubuntu-release 2019-08-24
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1020.22]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-60.67]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-60.67]
-queuebot:#ubuntu-release- New sync: rlottie (eoan-proposed/primary) [0~git20190721.24346d0+dfsg-2]
#ubuntu-release 2019-08-25
-queuebot:#ubuntu-release- New: accepted rtl8821ce [source] (eoan-proposed) [5.2.5.2.1.30816.20190425-0ubuntu1]
-queuebot:#ubuntu-release- New binary: rtl8821ce [amd64] (eoan-proposed/none) [5.2.5.2.1.30816.20190425-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-language-python [amd64] (eoan-proposed/universe) [0.5.6-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-language-python [amd64] (eoan-proposed/universe) [0.5.6-2] (no packageset)
-queuebot:#ubuntu-release- New sync: mysql++ (eoan-proposed/primary) [3.2.5-1]
#ubuntu-release 2020-08-17
<mwhudson> oh maybe google-guest-agent just needs a mir
<mwhudson> rbalint: why is there no MIR for google-guest-agent?
<RAOF> Hm. I'm not actually sure where you're looking :)
<mwhudson> RAOF: https://people.canonical.com/~ubuntu-archive/proposed-migration/log/groovy/2020-08-16/22:07:05.log
<RAOF> You might be a more proficient britney-whisperer than me ;)
<mwhudson> i guess it's in update_output.txt too?
<mwhudson> ah yes https://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt, search for "Trying easy from"
<mwhudson> i wonder what is making the gce-compute-image-packages in release uninstallable
<mwhudson> oh json-c
<mwhudson> ok so the ways forward here are 1) to delete the gce-compute-image-packages from proposed (and probably google-compute-engine-oslogin) and upload a rebuild of gce-compute-image-packages
<mwhudson> 2) promote google-guest-agent to main
<mwhudson> 3) wait for vorlon or doko or someone to wake up
<mwhudson> RAOF: thoughts? :) ^
<mwhudson> i guess 1) is probably better
<mwhudson> it'll annoy balint but i think it's just a matter of fixing changelogs and reuploading
<RAOF> (1) seems like a reasonable way forward?
<mwhudson> RAOF: can you perform the nuking then?
<RAOF> Why would we need to remove google-compute-engine-oslogin? You're just going to upload a no-change-rebuild for gce-compute-image-packages for json-c, right?
<mwhudson> RAOF: because the version of gce-compute-image-packages in release builds packages that are built by the version of google-compute-engine-oslogin in proposed
<mwhudson> RAOF: let me check version numbers before you do anything though
<RAOF> Oh! It's a separate source package now; I missed that.
<mwhudson> RAOF: yes, version numbers mean google-compute-engine-oslogin has to go
<mwhudson> RAOF: yeah, extra confusion! i wonder if this is why excuses.html is opaque about this
<RAOF>  mwhudson Ok, done. Let's get icu migrated, and please coordinate with balint!
<mwhudson> RAOF: thanks!
<mwhudson> i wonder if i need to wait for a publisher run before uploading or anything
<mwhudson> i guess i'll find out!
<mwhudson> so far so good
-queuebot:#ubuntu-release- New binary: qgis [amd64] (groovy-proposed/universe) [3.10.9+dfsg-1ubuntu1] (no packageset)
<mwhudson> debian-cloud-images/amd64 has unsatisfiable dependency
<mwhudson> would be nice if it said which
<mwhudson> oh fai
<mwhudson> care factor: low
<vorlon> mwhudson: well I tried a force hint on gce-compute-image-packages but britney doesn't seem to care; cc: Laney
<mwhudson> vorlon: i figured it out, RAOF to the rescue
<mwhudson> well RAOF and some patience
<mwhudson> haha oh god
<mwhudson> vorlon: https://people.canonical.com/~ubuntu-archive/proposed-migration/log/groovy/2020-08-17/00:08:21.log
<RAOF> ð¤
<mwhudson>   File "/home/ubuntu-archive/proposed-migration/code/b2/britney2/excusefinder.py", line 622, in find_actionable_excuses
<mwhudson>     assert valid == {x for x in excuses if excuses[x].is_valid}
<mwhudson> AssertionError
<mwhudson> vorlon: is this your fault?
<mwhudson> i.e. is this because of your hint
<mwhudson> ubuntu-archive: feel like cherry-picking https://salsa.debian.org/release-team/britney2/-/merge_requests/50 or somethign like that into our britney?
 * mwhudson lunches
<mwhudson> things are moving!
<mwhudson> although not json-c?
<mwhudson> so icu and json-c were not entangled after all?
<mwhudson> anyway json-c should go next time
<mwhudson> wtf https://launchpad.net/ubuntu/+source/kamailio/5.4.0-2
-queuebot:#ubuntu-release- New source: new-session-manager (groovy-proposed/primary) [1.3.2-0ubuntu1]
<mwhudson> oh i think britney ran while a dep was being published maybe?
-queuebot:#ubuntu-release- New source: dragonfly-reverb (groovy-proposed/primary) [3.2.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: qgis [arm64] (groovy-proposed/universe) [3.10.9+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New source: geonkick (groovy-proposed/primary) [2.3.6-0ubuntu1]
-queuebot:#ubuntu-release- New binary: qgis [armhf] (groovy-proposed/universe) [3.10.9+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gtk [armhf] (groovy-proposed/universe) [3.0.33-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: gloox [s390x] (groovy-proposed/universe) [1.0.24-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gloox [amd64] (groovy-proposed/universe) [1.0.24-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gloox [ppc64el] (groovy-proposed/universe) [1.0.24-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gloox [armhf] (groovy-proposed/universe) [1.0.24-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gloox [arm64] (groovy-proposed/universe) [1.0.24-2] (no packageset)
-queuebot:#ubuntu-release- New binary: gloox [riscv64] (groovy-proposed/universe) [1.0.24-2] (no packageset)
<cpaelzer> so many mails of things accepted now, that must mean ICU transitioned over the weekend
<cpaelzer> \o/
<mwhudson> cpaelzer: yep, after some encouragement
-queuebot:#ubuntu-release- New source: google-compute-engine-oslogin (groovy-proposed/primary) [20200507.00-0ubuntu2]
<mwhudson> rbalint, ubuntu-archive:  google-compute-engine-oslogin is back in NEW
<LocutusOfBorg> hello, nobody can accept haskell-gi-gtk and haskell-gi-gdkx11 please?
-queuebot:#ubuntu-release- New binary: haskell-gi-gtk [riscv64] (groovy-proposed/universe) [3.0.33-1build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gloox [amd64] (groovy-proposed) [1.0.24-2]
-queuebot:#ubuntu-release- New: accepted gloox [armhf] (groovy-proposed) [1.0.24-2]
-queuebot:#ubuntu-release- New: accepted gloox [riscv64] (groovy-proposed) [1.0.24-2]
-queuebot:#ubuntu-release- New: accepted gloox [arm64] (groovy-proposed) [1.0.24-2]
-queuebot:#ubuntu-release- New: accepted gloox [ppc64el] (groovy-proposed) [1.0.24-2]
-queuebot:#ubuntu-release- New: accepted gloox [s390x] (groovy-proposed) [1.0.24-2]
-queuebot:#ubuntu-release- New: accepted ocamlviz [arm64] (groovy-proposed) [1.01-4]
-queuebot:#ubuntu-release- New: accepted ocamlviz [ppc64el] (groovy-proposed) [1.01-4]
-queuebot:#ubuntu-release- New: accepted ocamlviz [s390x] (groovy-proposed) [1.01-4]
-queuebot:#ubuntu-release- New: accepted ocamlviz [amd64] (groovy-proposed) [1.01-4]
-queuebot:#ubuntu-release- New: accepted ocamlviz [riscv64] (groovy-proposed) [1.01-4]
-queuebot:#ubuntu-release- New: accepted ocamlviz [armhf] (groovy-proposed) [1.01-4]
-queuebot:#ubuntu-release- New: accepted nurpawiki [arm64] (groovy-proposed) [1.2.3-11]
-queuebot:#ubuntu-release- New: accepted nurpawiki [riscv64] (groovy-proposed) [1.2.3-11]
-queuebot:#ubuntu-release- New: accepted nurpawiki [armhf] (groovy-proposed) [1.2.3-11]
-queuebot:#ubuntu-release- New: accepted nurpawiki [s390x] (groovy-proposed) [1.2.3-11]
-queuebot:#ubuntu-release- New: accepted nurpawiki [amd64] (groovy-proposed) [1.2.3-11]
-queuebot:#ubuntu-release- New: accepted nurpawiki [ppc64el] (groovy-proposed) [1.2.3-11]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdkx11 [amd64] (groovy-proposed) [3.0.9-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdkx11 [s390x] (groovy-proposed) [3.0.9-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdkx11 [ppc64el] (groovy-proposed) [3.0.9-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdkx11 [arm64] (groovy-proposed) [3.0.9-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdkx11 [riscv64] (groovy-proposed) [3.0.9-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gtk [arm64] (groovy-proposed) [3.0.33-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gtk [ppc64el] (groovy-proposed) [3.0.33-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gtk [s390x] (groovy-proposed) [3.0.33-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gdkx11 [armhf] (groovy-proposed) [3.0.9-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gtk [armhf] (groovy-proposed) [3.0.33-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gtk [amd64] (groovy-proposed) [3.0.33-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gtk [riscv64] (groovy-proposed) [3.0.33-1build1]
<Laney> nice one mwhudson!
<vorlon> mwhudson: looks to me like google-compute-engine-oslogin conflicts with the previous publication; did you use copy-package?
<vorlon> (done now)
-queuebot:#ubuntu-release- New: rejected google-compute-engine-oslogin [source] (groovy-proposed) [20200507.00-0ubuntu2]
<mwhudson> vorlon: no i reuploaded
<vorlon> mwhudson: right, that doesn't work :)
<mwhudson> vorlon: where do you copy-package from?
<vorlon> mwhudson: "opy-package -b -e 20200507.0-0ubuntu2 --force-same-destination --auto-approve -s groovy-proposed -y google-compute-engine-oslogin" (the auto-approve is AA-only though)
<mwhudson> vorlon: gce-compute-packages needs the same trick when google-compute-engine-oslogin has published so i can practise :)
<mwhudson> vorlon: ok
<mwhudson> vorlon: did you see the traceback i think you hint was causing up above?
<vorlon> mwhudson: yah but it's 1am here so I'll have to look in the morning
<Laney> that'll be hard to reproduce
<mwhudson> vorlon: fair, i was wondering why you are still around
<Laney> and probably hard to reason about after the fact
<mwhudson> Laney: force something that isn't migrating because of component mismatches maybe?
<mwhudson> actually if i copy the new gce-compute-packages in it might start happening i guess
<mwhudson> given the hint is still there
<mwhudson> (if thats what is causing it)
<Laney> p'raps, but I guess we /don't/ want to force it in now :p
<mwhudson> right
-queuebot:#ubuntu-release- New: accepted qgis [amd64] (groovy-proposed) [3.10.9+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [armhf] (groovy-proposed) [3.10.9+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [s390x] (groovy-proposed) [3.10.9+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [arm64] (groovy-proposed) [3.10.9+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted qgis [ppc64el] (groovy-proposed) [3.10.9+dfsg-1ubuntu1]
<Laney> I was thinking we could do something like save the archive state in https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses/groovy/
<mwhudson> ah maybe
<mwhudson> wouldn't that be rather huge?
<Laney> laney@snakefruit:/home/ubuntu-archive/proposed-migration/data$ du -hs groovy groovy-proposed/
<Laney> 484M	groovy
<Laney> yeah not small :(
<Laney> 24M	groovy-proposed/
<mwhudson> you could get fancy and store diffs to previous or something but ehh
<Laney> commit them to git ;-)
<mwhudson> yes
<Laney> accidental not terrible idea?
<mwhudson> Laney: yes, i think so
<Laney> I'll file it, unlikely to work on it myself right away though
<Laney> ... & dropped that force hint
<Laney> https://bugs.launchpad.net/britney/+bug/1891871
<ubot5> Ubuntu bug 1891871 in britney "Save archive state along with excuses/output" [Undecided,New]
<mwhudson> oh huh i just copied the old gce-compute-image-packages back, which looses the changelog for the version i uploaded today
<mwhudson> ah well, it's not very interesting
<mwhudson> *loses
-queuebot:#ubuntu-release- New binary: evolution-data-server [s390x] (groovy-proposed/main) [3.37.90-1] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: evolution-data-server [i386] (groovy-proposed/main) [3.37.90-1] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: evolution-data-server [amd64] (groovy-proposed/main) [3.37.90-1] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: haskell-gi-dbusmenugtk3 [s390x] (groovy-proposed/universe) [0.4.8-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: evolution-data-server [ppc64el] (groovy-proposed/main) [3.37.90-1] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: haskell-gtk-strut [s390x] (groovy-proposed/universe) [0.1.3.0-2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gtk-hs [s390x] (groovy-proposed/universe) [0.3.8.1-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-dbusmenugtk3 [ppc64el] (groovy-proposed/universe) [0.4.8-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-vte [s390x] (groovy-proposed/universe) [2.91.25-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-vte [ppc64el] (groovy-proposed/universe) [2.91.25-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gtk-strut [ppc64el] (groovy-proposed/universe) [0.1.3.0-2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gtk-hs [ppc64el] (groovy-proposed/universe) [0.3.8.1-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-dbusmenugtk3 [arm64] (groovy-proposed/universe) [0.4.8-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gtk-strut [arm64] (groovy-proposed/universe) [0.1.3.0-2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-vte [amd64] (groovy-proposed/universe) [2.91.25-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-dbusmenugtk3 [amd64] (groovy-proposed/universe) [0.4.8-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gtk-hs [arm64] (groovy-proposed/universe) [0.3.8.1-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gtk-strut [amd64] (groovy-proposed/universe) [0.1.3.0-2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gtk-hs [amd64] (groovy-proposed/universe) [0.3.8.1-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-dbusmenugtk3 [armhf] (groovy-proposed/universe) [0.4.8-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: evolution-data-server [armhf] (groovy-proposed/main) [3.37.90-1] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: haskell-gtk-strut [armhf] (groovy-proposed/universe) [0.1.3.0-2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: evolution-data-server [arm64] (groovy-proposed/main) [3.37.90-1] (i386-whitelist, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: haskell-gi-vte [arm64] (groovy-proposed/universe) [2.91.25-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gtk-hs [armhf] (groovy-proposed/universe) [0.3.8.1-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-vte [armhf] (groovy-proposed/universe) [2.91.25-1build1] (no packageset)
<LocutusOfBorg> Unpacking dh-python (4.20200804ubuntu1) ...
<LocutusOfBorg> dpkg: error processing archive /var/cache/apt/archives/dh-python_4.20200804ubuntu1_all.deb (--unpack):
<LocutusOfBorg>  trying to overwrite '/usr/share/debhelper/autoscripts/postinst-pycompile', which is also in package python2 2.7.17-2ubuntu4
<LocutusOfBorg> doko, ^^
 * LocutusOfBorg fixes so sphinx can proceed a little bit
<mitya57> LocutusOfBorg: this is Debian #968046
<ubot5> Debian bug 968046 in dh-python "dh-python: missing Breaks+Replaces: python2 (<< 2.7.18)" [Serious,Open] http://bugs.debian.org/968046
<mitya57> And thanks for helping with sphinx migration :)
-queuebot:#ubuntu-release- New: accepted evolution-data-server [amd64] (groovy-proposed) [3.37.90-1]
-queuebot:#ubuntu-release- New: accepted evolution-data-server [armhf] (groovy-proposed) [3.37.90-1]
-queuebot:#ubuntu-release- New: accepted evolution-data-server [ppc64el] (groovy-proposed) [3.37.90-1]
-queuebot:#ubuntu-release- New: accepted evolution-data-server [arm64] (groovy-proposed) [3.37.90-1]
-queuebot:#ubuntu-release- New: accepted evolution-data-server [s390x] (groovy-proposed) [3.37.90-1]
-queuebot:#ubuntu-release- New: accepted evolution-data-server [i386] (groovy-proposed) [3.37.90-1]
<LocutusOfBorg> yep, I added the bug reference when I uploaded it on groovy
<LocutusOfBorg> I need sphinx to migrate because of libcdio entanglement
 * LocutusOfBorg afk for few hours
<LocutusOfBorg> vorlon, about rgain3, the last blocker for the other big transition, we might have got an API/ABI breakage
<LocutusOfBorg> https://github.com/chaudum/rgain/issues/29
<LocutusOfBorg> since the package is new, out from testing because of Debian bug: #968186, what about kicking it out from release pocket?
<ubot5> Debian bug 968186 in python3-rgain3 "python3-rgain3: API is potentially about to break" [Serious,Open] http://bugs.debian.org/968186
<LocutusOfBorg> btw please wait before copying back ghc and nodejs so we can finish this transition
<LocutusOfBorg> haskell is probably waiting only for autopkgtests
<LocutusOfBorg> (and some new queue processing)
<LocutusOfBorg> mwhudson, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/a/astropy/20200817_063057_4388e@/log.gz
<LocutusOfBorg> didn't your fix work?
<mwhudson> LocutusOfBorg: i just uploaded another go
<LocutusOfBorg> thanks!
<mwhudson> hm is that the last thing blocking sphinx?
<mwhudson> LocutusOfBorg: on +1 stuff again tomorrow (starting in like 9 hours) so feel free to ping here with things that need attention
-queuebot:#ubuntu-release- New binary: haskell-gtk-strut [riscv64] (groovy-proposed/universe) [0.1.3.0-2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-dbusmenugtk3 [riscv64] (groovy-proposed/universe) [0.4.8-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-vte [riscv64] (groovy-proposed/universe) [2.91.25-1build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gi-gtk-hs [riscv64] (groovy-proposed/universe) [0.3.8.1-1build1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-gi-dbusmenugtk3 [amd64] (groovy-proposed) [0.4.8-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-dbusmenugtk3 [armhf] (groovy-proposed) [0.4.8-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-dbusmenugtk3 [riscv64] (groovy-proposed) [0.4.8-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gtk-hs [amd64] (groovy-proposed) [0.3.8.1-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gtk-hs [armhf] (groovy-proposed) [0.3.8.1-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gtk-hs [riscv64] (groovy-proposed) [0.3.8.1-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-vte [amd64] (groovy-proposed) [2.91.25-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-vte [armhf] (groovy-proposed) [2.91.25-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-vte [riscv64] (groovy-proposed) [2.91.25-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gtk-strut [amd64] (groovy-proposed) [0.1.3.0-2build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-dbusmenugtk3 [arm64] (groovy-proposed) [0.4.8-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-dbusmenugtk3 [s390x] (groovy-proposed) [0.4.8-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gtk-hs [ppc64el] (groovy-proposed) [0.3.8.1-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-vte [arm64] (groovy-proposed) [2.91.25-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-vte [s390x] (groovy-proposed) [2.91.25-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gtk-strut [armhf] (groovy-proposed) [0.1.3.0-2build1]
-queuebot:#ubuntu-release- New: accepted haskell-gtk-strut [riscv64] (groovy-proposed) [0.1.3.0-2build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-dbusmenugtk3 [ppc64el] (groovy-proposed) [0.4.8-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gtk-hs [s390x] (groovy-proposed) [0.3.8.1-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gtk-strut [arm64] (groovy-proposed) [0.1.3.0-2build1]
-queuebot:#ubuntu-release- New: accepted haskell-gtk-strut [s390x] (groovy-proposed) [0.1.3.0-2build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-gtk-hs [arm64] (groovy-proposed) [0.3.8.1-1build1]
-queuebot:#ubuntu-release- New: accepted haskell-gtk-strut [ppc64el] (groovy-proposed) [0.1.3.0-2build1]
-queuebot:#ubuntu-release- New: accepted haskell-gi-vte [ppc64el] (groovy-proposed) [2.91.25-1build1]
-queuebot:#ubuntu-release- Unapproved: gnome-shell (bionic-proposed/main) [3.28.4-0ubuntu18.04.3 => 3.28.4-0ubuntu18.04.5] (desktop-extra, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: haskell-gtk-sni-tray [amd64] (groovy-proposed/universe) [0.1.6.0-2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gtk-sni-tray [s390x] (groovy-proposed/universe) [0.1.6.0-2build1] (no packageset)
<Laney> dear sync-mirrors, please sync the mirors, thanks
-queuebot:#ubuntu-release- New binary: haskell-gtk-sni-tray [ppc64el] (groovy-proposed/universe) [0.1.6.0-2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-termonad [amd64] (groovy-proposed/universe) [3.1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gtk-sni-tray [arm64] (groovy-proposed/universe) [0.1.6.0-2build1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-gtk-sni-tray [armhf] (groovy-proposed/universe) [0.1.6.0-2build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-botocore (xenial-proposed/universe) [1.16.19+repack-1ubuntu0.16.04.1 => 1.16.19+repack-1ubuntu0.16.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu26.2 => 2.04-1ubuntu26.3] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (focal-proposed/main) [1.142.4 => 1.142.5] (core)
<juliank> xnox: ^ grub goodness
<Laney> huh, one lunch later and it still didn't sync the updated SHA256SUMS.gpg
-queuebot:#ubuntu-release- New binary: haskell-gtk-sni-tray [riscv64] (groovy-proposed/universe) [0.1.6.0-2build1] (no packageset)
<Laney> ok there it is
-queuebot:#ubuntu-release- New binary: haskell-termonad [armhf] (groovy-proposed/universe) [3.1.0.0-1] (no packageset)
<xnox> juliank:  yeay!
-queuebot:#ubuntu-release- New binary: hamster-time-tracker [amd64] (groovy-proposed/none) [3.0.2-2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: base-files (focal-proposed/main) [11ubuntu5.1 => 11ubuntu5.2] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: base-files (bionic-proposed/main) [10.1ubuntu2.9 => 10.1ubuntu2.10] (core)
-queuebot:#ubuntu-release- Unapproved: base-files (xenial-proposed/main) [9.4ubuntu4.12 => 9.4ubuntu4.13] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (focal-proposed/main) [1.450.1 => 1.450.2] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (bionic-proposed/main) [1.417.4 => 1.417.5] (core)
-queuebot:#ubuntu-release- Unapproved: ubuntu-meta (xenial-proposed/main) [1.361.4 => 1.361.5] (core)
-queuebot:#ubuntu-release- New: accepted haskell-gtk-sni-tray [amd64] (groovy-proposed) [0.1.6.0-2build1]
-queuebot:#ubuntu-release- New: accepted haskell-gtk-sni-tray [arm64] (groovy-proposed) [0.1.6.0-2build1]
-queuebot:#ubuntu-release- New: accepted haskell-gtk-sni-tray [ppc64el] (groovy-proposed) [0.1.6.0-2build1]
-queuebot:#ubuntu-release- New: accepted haskell-gtk-sni-tray [s390x] (groovy-proposed) [0.1.6.0-2build1]
-queuebot:#ubuntu-release- New: accepted haskell-gtk-sni-tray [armhf] (groovy-proposed) [0.1.6.0-2build1]
-queuebot:#ubuntu-release- New: accepted haskell-gtk-sni-tray [riscv64] (groovy-proposed) [0.1.6.0-2build1]
-queuebot:#ubuntu-release- New: accepted hamster-time-tracker [amd64] (groovy-proposed) [3.0.2-2]
-queuebot:#ubuntu-release- New: accepted haskell-termonad [armhf] (groovy-proposed) [3.1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-termonad [amd64] (groovy-proposed) [3.1.0.0-1]
<Eickmeyer> ubuntu-archive: I am going to be unavailable for the better part of two weeks fairly soon due to a large relocation. Right now, I have five NEW sources awaiting review: geonkick, dragonfly-reverb, new-session-manager, jack-mixer (all for Ubuntu Studio) and plasma-wallpaper-dynamic (for KDE Plasma). Can we get these reviews expedited?
-queuebot:#ubuntu-release- New: rejected motd-news-config [source] (groovy-proposed) [1]
<LocutusOfBorg> vorlon, rgain3 ping :)
<LocutusOfBorg> this should be the last haskell/libcdio/x264 blocker
-queuebot:#ubuntu-release- New binary: taffybar [amd64] (groovy-proposed/universe) [3.2.2-1] (no packageset)
<mwhudson> yay sphinx migrated
<LocutusOfBorg> yep
-queuebot:#ubuntu-release- Unapproved: glibc (focal-proposed/main) [2.31-0ubuntu9 => 2.31-0ubuntu9.1] (core, i386-whitelist)
<seb128> Eickmeyer, it's a bit of a weird choice to have the packaging under another license than the source? why not having the debian/ dir as GPL3+ on new-session-manager (also weird pick as a project name but I guess that's not your doing)
<seb128> Eickmeyer, also some of the copyright holders you listed are not mentioned in the source?
-queuebot:#ubuntu-release- New binary: taffybar [ppc64el] (groovy-proposed/universe) [3.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: taffybar [arm64] (groovy-proposed/universe) [3.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: taffybar [s390x] (groovy-proposed/universe) [3.2.2-1] (no packageset)
<Eickmeyer> vorlon: Are you around? seb128 had some questions that you didn't ask. I don't know what he's getting at, but those people were mentioned in the git repository. I didn't drum-up those people from nowhere.
<Eickmeyer> Either way, new-session-manager is in source NEW. I can always relicense debian/* under GPL-3+ in the future, so I'm sure that's not a blocker.
 * Eickmeyer is just getting tired of the back/forth with hours in-between
-queuebot:#ubuntu-release- New binary: taffybar [armhf] (groovy-proposed/universe) [3.2.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: taffybar [riscv64] (groovy-proposed/universe) [3.2.2-1] (no packageset)
<vorlon> LocutusOfBorg: yep, rgain3 removed
<vorlon> Eickmeyer: if you've determined the list of copyright holders is correct, it's fine for NEW even if they're not named elsewhere is the source
#ubuntu-release 2020-08-18
<vorlon> sergiodj: hi, so this is tedious, sorry; I'm doing a license review now of telegraf for NEW, and I've found that vendor/gopkg.in/mgo.v2/ is listed as BSD-2-Clause for the license, but various things under vendor/gopkg.in/mgo.v2/internal are not BSD-2-clause - they're either 3-clause or Apache-2.0 and this isn't mentioned anywhere
<vorlon> sergiodj: and vendor/github.com/Azure/go-autorest/autorest appears to be Apache-2.0, but listed as Expat
<vorlon> sergiodj: vendor/github.com/aws/aws-sdk-go/internal/sync/singleflight/: BSD-3-clause?
<vorlon> sergiodj: vendor/github.com/couchbase/goutils/: listed as Expat, the only license hits from licensecheck appear to be apache-2.0
<vorlon> sergiodj: vendor/github.com/go-redis/redis/internal: Apache-2.0, not BSD-2-Clause
<vorlon> sergiodj: vendor/github.com/soniah/gosnmp/: BSD-3-clause, not BSD-2-clause
<vorlon> sergiodj: oops, ignore that last one, it's an "or" license
<vorlon> sergiodj: however, vendor/github.com/streadway/amqp/ appears to be BSD-2-clause, not Expat?
<vorlon> sergiodj: the rest looks correct; let me know your feedback on the above
<Eickmeyer> vorlon: Yes, it was determined that all of those people had a hand in the project.
<vorlon> LocutusOfBorg: hmm mpd is listed in update_excuses as 'grouped with ppa 4208', but that ppa seems to have migrated
<vorlon> LocutusOfBorg: s/migrated/been abandoned/
-queuebot:#ubuntu-release- Unapproved: ceph (bionic-proposed/main) [12.2.13-0ubuntu0.18.04.2 => 15.2.3-0ubuntu3] (desktop-core, ubuntu-server)
<sergiodj> vorlon: I will address these ASAP, thanks for looking.  I relied a lot on the licensecheck's output, and tried to keep things organized as much as I could, but unfortunately at some point during the day I spent doing this I probably did these mistakes.  argh
<sergiodj> vorlon: OK, feedback (as I go):
<sergiodj> vendor/github.com/Azure/go-autorest/autorest is correctly listed as Apache-2.0 (not as Expat) in d/copyright
<sergiodj> vendor/github.com/go-redis/redis/internal: I don't know if this directory is entirely Apache-2.0; there's no LICENSE file there.  the only file that's explicitly Apache-2.0 is vendor/github.com/go-redis/redis/internal/singleflight/singleflight.go, so I'm only going to list it in d/copyright, OK?
<sergiodj> vendor/github.com/streadway/amqp/: ah, good catch, the missing "*" fooled me
<sergiodj> vorlon: I've updated the rest of d/copyright accordingly.  thanks again for the review.  in the interest of time, I'll rebuild the package and ask for sponsorship again, and then I'll ping you tomorrow as soon as it's uploaded.  please let me know if you find anything else that needs attention
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-114.115~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-114.115~16.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-114.115~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-114.115~16.04.1]
-queuebot:#ubuntu-release- New binary: libportal [s390x] (groovy-proposed/universe) [0.3+git20200327-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libportal [ppc64el] (groovy-proposed/universe) [0.3+git20200327-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libportal [amd64] (groovy-proposed/universe) [0.3+git20200327-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libportal [arm64] (groovy-proposed/universe) [0.3+git20200327-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libportal [armhf] (groovy-proposed/universe) [0.3+git20200327-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libportal [riscv64] (groovy-proposed/universe) [0.3+git20200327-1] (no packageset)
<LocutusOfBorg> vorlon, looks like evertyhing has migrated thanks
<LocutusOfBorg> just in time for a new round of haskell stuff
-queuebot:#ubuntu-release- New: accepted libportal [amd64] (groovy-proposed) [0.3+git20200327-1]
-queuebot:#ubuntu-release- New: accepted libportal [armhf] (groovy-proposed) [0.3+git20200327-1]
-queuebot:#ubuntu-release- New: accepted libportal [riscv64] (groovy-proposed) [0.3+git20200327-1]
-queuebot:#ubuntu-release- New: accepted libportal [arm64] (groovy-proposed) [0.3+git20200327-1]
-queuebot:#ubuntu-release- New: accepted libportal [s390x] (groovy-proposed) [0.3+git20200327-1]
-queuebot:#ubuntu-release- New: accepted libportal [ppc64el] (groovy-proposed) [0.3+git20200327-1]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [s390x] (bionic-proposed/main) [5.4.0-44.48~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [amd64] (bionic-proposed/main) [5.4.0-44.48~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [ppc64el] (bionic-proposed/main) [5.4.0-44.48~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oem-5.6 [amd64] (focal-proposed/main) [5.6.0-1022.22] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-5.4 [arm64] (bionic-proposed/main) [5.4.0-44.48~18.04.1] (no packageset)
<LocutusOfBorg> taffybar accept from new please?
<sil2100> LocutusOfBorg: looking
-queuebot:#ubuntu-release- New: accepted taffybar [amd64] (groovy-proposed) [3.2.2-1]
-queuebot:#ubuntu-release- New: accepted taffybar [armhf] (groovy-proposed) [3.2.2-1]
-queuebot:#ubuntu-release- New: accepted taffybar [riscv64] (groovy-proposed) [3.2.2-1]
-queuebot:#ubuntu-release- New: accepted taffybar [arm64] (groovy-proposed) [3.2.2-1]
-queuebot:#ubuntu-release- New: accepted taffybar [s390x] (groovy-proposed) [3.2.2-1]
-queuebot:#ubuntu-release- New: accepted taffybar [ppc64el] (groovy-proposed) [3.2.2-1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [amd64] (bionic-proposed) [5.4.0-44.48~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [ppc64el] (bionic-proposed) [5.4.0-44.48~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [arm64] (bionic-proposed) [5.4.0-44.48~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-5.4 [s390x] (bionic-proposed) [5.4.0-44.48~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-5.6 [amd64] (focal-proposed) [5.6.0-1022.22]
<LocutusOfBorg> thanks
<juliank> I want to SRU memtest86+ focal
<juliank> but it has an ubuntu2 in proposed that should be removed
<juliank> and I guess the right version would be 1.1, but do I need to use 2.1 now?
<Laney> it would be nice to people who are on 2
<tjaalton> and needs an AA to remove from proposed?
<Laney> doesn't look that important to remove it to me, I guess it can just be superseded with a new upload
<juliank> ok
<tjaalton> right
<Laney> just drop the LP bug reference :>
<juliank> Just not including the last changelog entry in the changes file does the trick too
<juliank> but um might be confusing to see the changelog entry in there
<juliank> So I guess I'll just drop it
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (focal-proposed/main) [5.4.0-1023.23] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: memtest86+ (focal-proposed/main) [5.01-3.1ubuntu2 => 5.01-3.1ubuntu2.1] (desktop-core, ubuntu-server)
<juliank> woof!
-queuebot:#ubuntu-release- Unapproved: mate-common (focal-proposed/universe) [1.24.0-1ubuntu1 => 1.24.2-0ubuntu0] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mate-desktop (focal-proposed/universe) [1.24.0-2 => 1.24.1-0ubuntu0] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: libmatekbd (focal-proposed/universe) [1.24.0-1 => 1.24.1-0ubuntu0] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: libmatemixer (focal-proposed/universe) [1.24.0-1 => 1.24.1-0ubuntu0] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: libmateweather (focal-proposed/universe) [1.24.0-1 => 1.24.1-0ubuntu0] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: marco (focal-proposed/universe) [1.24.0-1ubuntu1 => 1.24.1-0ubuntu0] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mate-settings-daemon (focal-proposed/universe) [1.24.0-1 => 1.24.1-0ubuntu0] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mate-session-manager (focal-proposed/universe) [1.24.0-2ubuntu1 => 1.24.1-0ubuntu0] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mate-menus (focal-proposed/universe) [1.24.0-1 => 1.24.1-0ubuntu0] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mate-panel (focal-proposed/universe) [1.24.0-2 => 1.24.1-0ubuntu0] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mate-notification-daemon (focal-proposed/universe) [1.24.0-1 => 1.24.1-0ubuntu0] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: mate-control-center (focal-proposed/universe) [1.24.0-1 => 1.24.1-0ubuntu0] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mate-applets (focal-proposed/universe) [1.24.0-1 => 1.24.1-0ubuntu0] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mate-calc (focal-proposed/universe) [1.24.0-1 => 1.24.1-0ubuntu0] (ubuntu-mate, ubuntukylin, xubuntu)
-queuebot:#ubuntu-release- Unapproved: mate-media (focal-proposed/universe) [1.24.0-1 => 1.24.1-0ubuntu0] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mate-power-manager (focal-proposed/universe) [1.24.1-0ubuntu1 => 1.24.2-0ubuntu0] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: caja-extensions (focal-proposed/universe) [1.24.0-1 => 1.24.1-0ubuntu0] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: engrampa (focal-proposed/universe) [1.24.0-2 => 1.24.1-0ubuntu0] (ubuntu-mate, ubuntukylin, xubuntu)
-queuebot:#ubuntu-release- Unapproved: eom (focal-proposed/universe) [1.24.0-1 => 1.24.1-0ubuntu0] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: mate-sensors-applet (focal-proposed/universe) [1.24.0-1 => 1.24.1-0ubuntu0] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: mate-terminal (focal-proposed/universe) [1.24.0-2ubuntu1 => 1.24.1-0ubuntu0] (ubuntu-mate, ubuntukylin)
-queuebot:#ubuntu-release- Unapproved: accepted memtest86+ [source] (focal-proposed) [5.01-3.1ubuntu2.1]
<LocutusOfBorg> vorlon, time to restore nodejs 12?
<sil2100> juliank: hey! The grub2 focal SRU's diff is quite huge due to patches moving around, it's really hard to review - did some of those patches have to be renamed?
<LocutusOfBorg> vorlon, did you play with some i386 seeds?
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/ffmpeg/7:4.3.1-2ubuntu1/+build/19846675
<LocutusOfBorg> looks like lzop is not installable anymore...
<juliank> sil2100: It's what the tool does!
<juliank> sil2100: People didn't add patch names to the patches so they got numbered
<juliank> sil2100: The diff really is not super helpful, maybe it helps to look at the git diff instead
<coreycb> hi, please can someone from the SRU team reject ceph 15.2.3 from the bionic unapproved queue?
<sil2100> juliank: yeah, will do that then!
<sil2100> ;)
<Laney> LocutusOfBorg: copy-package with --force-same-destination and --include-binaries, no need to ping v_orlon for that question imho :-)
 * ricotz was wondering where nodejs 12 went
<seb128> ricotz, Steve mentioned it on a +1 discussion on ubuntu-devel, he reverted to facilate the icu transition, it can probably be restored now
<ricotz> seb128, hey, thanks
<Laney> LocutusOfBorg: (if you can upload the package you can do that, fwiw)
<LocutusOfBorg> I'll try thanks
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (focal-proposed) [2.04-1ubuntu26.3]
<Laney> paste the command for review if you want
<LocutusOfBorg> ./copy-package --from=ubuntu --to=ubuntu --from-suite=groovy --to-suite=groovy-proposed --include-binaries --version 12.18.2~dfsg-1ubuntu1 nodejs --force-same-destination
<LocutusOfBorg> it doesn't work
<Laney> you can do better than "it doesn't work"!
<LocutusOfBorg> Could not find source 'nodejs/12.18.2~dfsg-1ubuntu1' in groovy
<Laney> from groovy-proposed no?
<LocutusOfBorg> it worked <3
<Laney> good thing about this is that it should find the old test results
<Laney> hopefully...
<RikMills> that is interesting to know!
<LocutusOfBorg> thanks! I always wondered how to do that... nice to know, I'll use now :p
<Laney> not sure if it is dangerous to teach you this :p
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (focal-proposed) [1.142.5]
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu26.3 => 2.04-1ubuntu26.3] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (focal-proposed/main) [2.04-1ubuntu26.3 => 2.04-1ubuntu26.3] (core)
<Eickmeyer> seb128: RE: copyright holders: I did, in fact, determine all of those people had a hand in the project. vorlon said it was a non-issue, same with the license. I can always update the license in a future upload.
-queuebot:#ubuntu-release- New source: telegraf (groovy-proposed/primary) [1.15.1+ds1-0ubuntu1]
<sergiodj> vorlon: telegraf has just been uploaded (thanks kanashiro) with the changes to d/copyright
-queuebot:#ubuntu-release- Unapproved: rejected flatpak [sync] (eoan-proposed) [1.4.4-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [source] (eoan-proposed) [1.2.13-0~ubuntu19.10.1]
-queuebot:#ubuntu-release- Unapproved: rejected fwupd-signed [source] (eoan-proposed) [1.10.3ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected adobe-flashplugin [source] (eoan-proposed) [1:20200714.1-0ubuntu0.19.10.1]
-queuebot:#ubuntu-release- New: rejected python-infoblox-client [source] (eoan-proposed) [0.4.22-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected python-purestorage [source] (eoan-proposed) [1.17.0-0ubuntu1]
-queuebot:#ubuntu-release- New: rejected python-masakariclient [source] (eoan-proposed) [5.4.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted vmfs6-tools [amd64] (eoan-backports) [0.1.0-3~ubuntu19.10.1]
-queuebot:#ubuntu-release- New: accepted vmfs6-tools [armhf] (eoan-backports) [0.1.0-3~ubuntu19.10.1]
-queuebot:#ubuntu-release- New: accepted vmfs6-tools [ppc64el] (eoan-backports) [0.1.0-3~ubuntu19.10.1]
-queuebot:#ubuntu-release- New: accepted vmfs6-tools [arm64] (eoan-backports) [0.1.0-3~ubuntu19.10.1]
-queuebot:#ubuntu-release- New: accepted vmfs6-tools [s390x] (eoan-backports) [0.1.0-3~ubuntu19.10.1]
-queuebot:#ubuntu-release- New: accepted vmfs6-tools [i386] (eoan-backports) [0.1.0-3~ubuntu19.10.1]
<Eickmeyer> ubuntu-archive: Right now, I have five NEW sources awaiting review: geonkick, dragonfly-reverb, new-session-manager, jack-mixer (all for Ubuntu Studio) and plasma-wallpaper-dynamic (for KDE Plasma). Can we get these reviews expedited? If there are issues, I'd rather fix them sooner rather than be notified when I don't have access do to my relocation.
<Eickmeyer> *due
<sil2100> Eickmeyer: let me take a look at jack-mixer in a moment
<Eickmeyer> sil2100: :)
<Eickmeyer> sil2100: That should be an easy one as it's reintroducing an application that was removed due to Python2. It's a Python3/GTK3 port.
<sil2100> Oh, I like that! Looking at it now
<sarnold> hello -release pals, I'm curious why eoan appears to still be getting updates? https://lists.ubuntu.com/archives/eoan-changes/2020-August/date.html
<sil2100> sarnold: that's uh, part of the archive closing
<sil2100> sarnold: we were cleaning out -proposed
<sil2100> (that's the last you'll see of eoan!)
-queuebot:#ubuntu-release- New: accepted jack-mixer [source] (groovy-proposed) [13-0ubuntu1]
<sarnold> sil2100: aha! thanks
<sil2100> sarnold: oh, and apologies for pushing memcached to eoan-security, that was eh, an accident
<sil2100> So I removed it afterwards
<sil2100> Eickmeyer: accepted! Will wait for the binaries to pop up and accept those too
<Eickmeyer> sil2100: Thanks so much!
-queuebot:#ubuntu-release- New binary: jack-mixer [amd64] (groovy-proposed/none) [13-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: jack-mixer [s390x] (groovy-proposed/universe) [13-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: jack-mixer [arm64] (groovy-proposed/universe) [13-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: jack-mixer [armhf] (groovy-proposed/universe) [13-0ubuntu1] (no packageset)
<seb128> Eickmeyer, was jack-mixer picked up again upstream? why not getting it through Debian?
-queuebot:#ubuntu-release- New binary: jack-mixer [riscv64] (groovy-proposed/universe) [13-0ubuntu1] (no packageset)
<Eickmeyer> seb128: Debian appears to be unaware of the change in ownership/repository. I was directly notified.
-queuebot:#ubuntu-release- New binary: jack-mixer [ppc64el] (groovy-proposed/universe) [13-0ubuntu1] (no packageset)
<sforshee> ubuntu-archive: can someone help get nbs cleared on linux, linux-meta, linux-signed, and linux-restricted-modules in groovy-proposed?
-queuebot:#ubuntu-release- Unapproved: accepted python-botocore [source] (xenial-proposed) [1.16.19+repack-1ubuntu0.16.04.2]
<Eickmeyer> sil2100: Looks like we've got binaries.
<apw> sforshee, nbs wacke
<sforshee> thanks apw
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (focal-proposed) [5.4.0-1023.23]
<RAOF> arnatious: Hey there! Are you aware that the pyflakes/pycodestyle/flake8 SRU is sitting in -proposed because it triggered a bunch of autopkgtest regressions?
<RAOF> arnatious: It's not going to migrate into -updates until those are fixed, and fixing them - or, at least, organising fixes for them - is the responsibility of the SRUer.
-queuebot:#ubuntu-release- New binary: open-iscsi [s390x] (groovy-proposed/main) [2.1.1-1ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: open-iscsi [amd64] (groovy-proposed/main) [2.1.1-1ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: open-iscsi [armhf] (groovy-proposed/main) [2.1.1-1ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: open-iscsi [ppc64el] (groovy-proposed/main) [2.1.1-1ubuntu1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: open-iscsi [arm64] (groovy-proposed/main) [2.1.1-1ubuntu1] (ubuntu-desktop, ubuntu-server)
<vorlon> bdmurray: closing eoan bugs by hands, rather than using close-EOL-bugs from ubuntu-archive-tools?
<Eickmeyer> ubuntu-archive: Right now, I have five NEW sources awaiting review: geonkick, dragonfly-reverb, new-session-manager, (all for Ubuntu Studio) and plasma-wallpaper-dynamic (for KDE Plasma). Can we get these reviews expedited? If there are issues, I'd rather fix them sooner rather than be notified when I don't have access due to my relocation.
<Eickmeyer> s/five/four
-queuebot:#ubuntu-release- New binary: open-iscsi [riscv64] (groovy-proposed/main) [2.1.1-1ubuntu1] (ubuntu-desktop, ubuntu-server)
<sforshee> ubuntu-archive: there's still a problem for linux-signed in groovy-proposed, we've disabled signing for arm64 because bug 1862279 makes it impossible for us to test it, and update_excuses complains about the missing arm64 build
<ubot5> bug 1862279 in grub2-signed (Ubuntu) "arm64 Secure Boot fails w/ "error: cannot load image."" [Undecided,Confirmed] https://launchpad.net/bugs/1862279
<sforshee> it also looks like nbs is still set there
<sforshee> vorlon: linux-restricted-modules is also dependent on nvidia-graphics-drivers-450, blocked by your bug 1889111
<ubot5> bug 1889111 in nvidia-graphics-drivers-450 (Ubuntu) "nvidia-450 can't promote until linux+linux-restricted-modules is rebuilt against it" [Undecided,New] https://launchpad.net/bugs/1889111
<bdmurray> vorlon: No, I updated the script. https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/close-EOL-use-title/+merge/389491
#ubuntu-release 2020-08-19
<Eickmeyer> ubuntu-archive: Right now, I have four NEW sources awaiting review: geonkick, dragonfly-reverb, new-session-manager, (all for Ubuntu Studio) and plasma-wallpaper-dynamic (for KDE Plasma). Can we get these reviews expedited? If there are issues, I'd rather fix them sooner rather than be notified when I don't have access due to my relocation.
<RAOF> I'm looking at dragonfly-reverb now.
<Eickmeyer> Thanks, RAOF . Unfortunately, the concerns you had that we deferred are still going to be there.
<RAOF> Eickmeyer: That was the âis the SIL open font license OK with thisâ question, right?
<RAOF> Maybe I'll just look at one of the others first ð
<RAOF> Eickmeyer: for plasma-wallpaper-dynamic, src/lib /* is under LGPL-3+, not GPL-3+
<Eickmeyer> RAOF: ok, can fix.
<Eickmeyer> teward: ^
<RAOF> It *might* be nice to have a symbols file, but this is C++ so that's purely aspirational. Maybe you should be invoking `dh_makeshlibs` directly and passing it an explicit version?
<Eickmeyer> RAOF: I don't understand much of that.
<RAOF> Eickmeyer: You're shipping a shared library; that means that *something* needs to tell the tools what package dependencies should be generated for things which link to that library.
<RAOF> That is `dh_makeshlibs`, which will generate a `.shlibs` file for you (and also get any `.symbols` file processed)
<Eickmeyer> Doesn't dh automatically do that or am I mistaken?
<RAOF> The `shlibs` file will say something like âlibfoo 1 libfoo1 (>= 1.2.3)â, for âlibfoo has SOVERSION 1 and the package dependency to add to something which links to that is âlibfoo (>= ...)ââ
<RAOF> Yeah, as of debcompat 12 it will add âlibfoo (>= $Upstream-Version)â.
<Eickmeyer> Ok, I'm using debcompat 13 for this.
<RAOF> Yeah, this is not in any way reject worthy.
<RAOF> This is just me preferring explicit over implicit in something that's reasonably recently changed debhelper defaults.
<Eickmeyer> Ok, I see.
<RAOF> Ok, and I don't think the lintian override is justified. `usr/bin/kdynamicwallpaperbuilder` *should* have a manpage, and it's better to have a lintian warning to that effect than to silence the warning.
<RAOF> Other than that, it's just the missing LGPL-3+ bit.
-queuebot:#ubuntu-release- New: rejected plasma-wallpaper-dynamic [source] (groovy-proposed) [3.3.3-0ubuntu1]
<Eickmeyer> RAOF: I already have it fixed. As far as the manpage, I can notify upstream.
<Eickmeyer> I've been told that, in the past, if something doesn't have a manpage, to override the warning and justify it in the comment of the override.
<RAOF> You're also welcome to write one yourself. I don't mind the lack of a manpage.
<Eickmeyer> I can also notify upstream.
<RAOF> Hah! Here's where we need to socialise what the actual policy is more, clearly :)
<RAOF> Yeah. If there's a manpage upstream that's even better (as everyone gets it).
<Eickmeyer> If you look at geonkick you'll notice that it also has no manpage, but upstream has been notified (and as of today has one).
<RAOF> (It looks like you could possibly just run `ronn` against `src/tools/builder/README.md` to generate the manpage)
<Eickmeyer> Oh, didn't know that.
<Eickmeyer> RAOF: Reupload coming your way.
<RAOF> To be clear, I don't know what that would look like. I was just sure there was a markdown-to-man converter :)
<RAOF> I, personally, prefer lintian to generate a missing-manpage warning when there's a binary that's legitimately user-facing and is missing a manpage than for the package to contain a lintian-override to silence that warning, but others may have other ideas.
-queuebot:#ubuntu-release- New source: plasma-wallpaper-dynamic (groovy-proposed/primary) [3.3.3-0ubuntu1]
<Eickmeyer> RAOF: ^ There's your new upload.
<Eickmeyer> With the copyright issue fixed.
<Eickmeyer> RAOF: Did you want to approve that with the d/copyright issue fixed?
-queuebot:#ubuntu-release- New: accepted plasma-wallpaper-dynamic [source] (groovy-proposed) [3.3.3-0ubuntu1]
<RAOF> Ah, nit that I didn't pick up last time: the MIT license that code uses is more correctly spelt [âExpatâ](https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name) (see the note under the table)
<RAOF> I'll just file that as a wishlist bug.
<Eickmeyer> Sounds good. I can fix that very quickly once it's in the archive as I'm seeding it, so it should get added to my packageset.
-queuebot:#ubuntu-release- New binary: plasma-wallpaper-dynamic [amd64] (groovy-proposed/universe) [3.3.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: plasma-wallpaper-dynamic [s390x] (groovy-proposed/universe) [3.3.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: plasma-wallpaper-dynamic [arm64] (groovy-proposed/universe) [3.3.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: plasma-wallpaper-dynamic [armhf] (groovy-proposed/universe) [3.3.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: plasma-wallpaper-dynamic [ppc64el] (groovy-proposed/universe) [3.3.3-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: plasma-wallpaper-dynamic [riscv64] (groovy-proposed/universe) [3.3.3-0ubuntu1] (no packageset)
<RAOF> xnox: Didn't I reject microcode-initrd last week because (a) debian/copyright claims GPLv3 but the script is GPLv2+ and (b) debian/copyright misses hmh@debian.org from the copyright holders?
<RAOF> Why is it back again with the same debian/copyright?
<RAOF> Is there something I'm missing here?
-queuebot:#ubuntu-release- New: accepted geonkick [source] (groovy-proposed) [2.3.6-0ubuntu1]
-queuebot:#ubuntu-release- New binary: geonkick [s390x] (groovy-proposed/universe) [2.3.6-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: geonkick [amd64] (groovy-proposed/universe) [2.3.6-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: geonkick [arm64] (groovy-proposed/universe) [2.3.6-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: geonkick [armhf] (groovy-proposed/universe) [2.3.6-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: geonkick [riscv64] (groovy-proposed/universe) [2.3.6-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: geonkick [ppc64el] (groovy-proposed/universe) [2.3.6-0ubuntu1] (no packageset)
<juliank> RAOF: The script now says GPL3 too
<juliank> RAOF: And hmh was added
<juliank> RAOF: Orig script was GPL-2 or later, but clearly xnox took the "or later" part and licensed the new work as GPL-3
<RAOF> Hmm. It's possible that the answer to the question 'am I missing something' could be 'I'm not actually reviewing the current package in the queue'
<juliank> :)
<xnox> RAOF: i thought I fixed all the things you pointed out, unless i am confused.
<xnox> RAOF:  let me download all the things to double check.
<RAOF> I'm EOD, but it's entirely possible I was accidentally reviewing a stale copy.
<LocutusOfBorg> hello ubuntu-archive, please kick haskell-shake out from release, Debian bug: ##966835.
<LocutusOfBorg> Debian bug: #966835
<ubot5> Debian bug 966835 in src:haskell-shake "haskell-shake needs source upload for new haddock interface" [Serious,Open] http://bugs.debian.org/966835
<LocutusOfBorg> but it FTBFS now :D
<kanashiro> rbasak: re LP #1881196: last time we talked about this postfix SRU you told me to do the verification work and do not worry about the sbuild "regression" (not introduced by postfix). I did that, should I do something else? Or just wait for some SRU team member to take a look at it?
<ubot5> Launchpad bug 1881196 in postfix (Ubuntu Bionic) "[SRU] postfix tls deploy-server-cert fails with "can't shift that many"" [Undecided,Fix committed] https://launchpad.net/bugs/1881196
-queuebot:#ubuntu-release- Unapproved: accepted muffin [source] (focal-proposed) [4.4.3-1ubuntu0.1]
<rbasak> kanashiro: your explanation in the bug is fine. It would be helpful but not required to file an appropriate hinting MP
<rbasak> (from https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions)
<rbasak> This is the "not a real regression" case I think?
<kanashiro> yes, it matches the "not a real regression" scenario
<kanashiro> this SRU is laying around for more than a month, I just want to make sure it will land at some point :)
<sforshee> ubuntu-archive: I'm still looking for some help resolving the issues blocking linux-signed for groovy
<rbasak> coreycb: there are two ceph uploads in the Bionic queue. The latest one looks like it was intended for Groovy? I just wanted to check before rejecting that one.
<coreycb> rbasak: yes please reject that, thank you
<rbasak> Done, thanks. Looking at the Focal ceph upload first.
-queuebot:#ubuntu-release- Unapproved: rejected ceph [source] (bionic-proposed) [15.2.3-0ubuntu3]
<rbasak> kanashiro: understood. I'm reviewing the upload queues first. I'll spend some time on postfix when I'm done.
<rbasak> coreycb: got time to chat about this ceph SRU to Focal to save time round-tripping through the bug?
<rbasak> Do you have a link to the upstream commit please? The dep3 header only has the commit hash
<rbasak> And I think the addition of debian/control.orig is spurious and should be removed?
<rbasak> Also there seems to be no regression potential discussion in the bug?
<coreycb> rbasak: are you reviewing bug 1868364 ?
<ubot5> bug 1868364 in ceph (Ubuntu Bionic) "[SRU] rgw: unable to abort multipart upload after the bucket got resharded" [High,Triaged] https://launchpad.net/bugs/1868364
<coreycb> sorry you said focal
<coreycb> checking
<rbasak> No https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1891567
<ubot5> Ubuntu bug 1891567 in ceph (Ubuntu Focal) "[SRU] ceph_osd crash in _committed_osd_maps when failed to encode first inc map" [Critical,Triaged]
<rbasak> Right thanks
<coreycb> rbasak: control.orig does appear to be spurious. I'll fix that up and re-upload.
<coreycb> rbasak: I will fix up the other things as well and let you know when I'm done. thanks for the review.
<rbasak> Thanks!
<coreycb> rbasak: ceph is so much fun. I have a riscv64 build going for almost 24 hours now.
<rbasak> Is that ceph that is fun, or riscv64? :)
<rbasak> I hear kanashiro also enjoys riscv64 :-P
<coreycb> maybe both :) arm only takes like 8 hours. it's a 'get it right the first time' kind of package.
<kanashiro> you have to have many side tasks while working on riscv64 issues :P
-queuebot:#ubuntu-release- New binary: linux-signed-dell300x [amd64] (bionic-proposed/universe) [4.15.0-1001.3] (no packageset)
<xnox> apw:  trademarks in package names?
<xnox> well, to be fair "linux" is a trademark too
<xnox> vmware uses it too, so i guess that's fine.
<cjwatson> nominative use surely.
<sforshee> sil2100: any chance you could help out with unblocking linux-signed in groovy?
<sil2100> sforshee: hey! How can I help?
<sforshee> sil2100: we've removed arm64 singed kernels for now because grub issues prevent us from testing them, and update_excuses is complaining about missing arm64 binaries for linux-signed
<sforshee> vorlon: I think bug 1889111 should be satisfied by the linux-restricted-modules in groovy-proposed, can you confirm?
<ubot5> bug 1889111 in nvidia-graphics-drivers-450 (Ubuntu) "nvidia-450 can't promote until linux+linux-restricted-modules is rebuilt against it" [Undecided,New] https://launchpad.net/bugs/1889111
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (bionic-proposed) [12.2.13-0ubuntu0.18.04.3]
<sforshee> vorlon: note that linux-restricted-modules is blocked by nvidia-graphics-drivers-450
<Eickmeyer> sil2100: Were you going to approve jack-mixer's binaries?
<Eickmeyer> ubuntu-archive: Only two left! dragonfly-reverb and new-session-manager, both are reuploads to fix minor issues vorlon found. As far as NEW binaries, we have geonkick and jack-mixer for Studio (sil2100 was going to take care of that one) and plasma-wallpaper-dynamic for KDE Plasma/Kubuntu. I'd appreciate the help!
<sil2100> Eickmeyer: ok, that's embarrasing! I ran lintian on them yesterday to sanity check them and... didn't push the button
<sil2100> :(
-queuebot:#ubuntu-release- New: accepted jack-mixer [amd64] (groovy-proposed) [13-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted jack-mixer [armhf] (groovy-proposed) [13-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted jack-mixer [riscv64] (groovy-proposed) [13-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted jack-mixer [arm64] (groovy-proposed) [13-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted jack-mixer [s390x] (groovy-proposed) [13-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted jack-mixer [ppc64el] (groovy-proposed) [13-0ubuntu1]
<Eickmeyer> sil2100: No worries, I thought I caught you before EOD to remind you, but I was wrong. :)
<sil2100> sforshee: looking
<vorlon> sforshee: if nvidia-graphics-drivers-450 and linux-restricted-modules are now in sync in -proposed, the block-proposed bug should simply be closed
-queuebot:#ubuntu-release- Unapproved: ceph (focal-proposed/main) [15.2.3-0ubuntu0.20.04.1 => 15.2.3-0ubuntu0.20.04.2] (desktop-core, ubuntu-server)
<sforshee> vorlon: ack, thanks
<vorlon> rolling forward postgresql-12
<xnox> sil2100: where are 20.04.0 images?
<vorlon> mwhudson: cherry-picked your britney2 change
<sil2100> xnox: you mean the GA 20.04 images?
<vorlon> rolling forward dovecot
<vorlon> rolling forward grcompiler
<sil2100> xnox: if yes, those are on old-images - and before you ask, yes, you can't get them right now as the syncing of old-releases is broken and waiting for IS
<sil2100> ;)
-queuebot:#ubuntu-release- New: rejected telegraf [source] (groovy-proposed) [1.15.1+ds1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted telegraf [source] (groovy-proposed) [1.15.1+ds1-0ubuntu1]
-queuebot:#ubuntu-release- New binary: telegraf [s390x] (groovy-proposed/none) [1.15.1+ds1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: telegraf [amd64] (groovy-proposed/none) [1.15.1+ds1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: telegraf [ppc64el] (groovy-proposed/universe) [1.15.1+ds1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (focal-proposed/main) [0.8.3-1ubuntu12.3 => 0.8.3-1ubuntu12.4] (core)
-queuebot:#ubuntu-release- New binary: telegraf [armhf] (groovy-proposed/universe) [1.15.1+ds1-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: rejected open-iscsi [amd64] (groovy-proposed) [2.1.1-1ubuntu1]
-queuebot:#ubuntu-release- New: rejected open-iscsi [armhf] (groovy-proposed) [2.1.1-1ubuntu1]
-queuebot:#ubuntu-release- New: rejected open-iscsi [riscv64] (groovy-proposed) [2.1.1-1ubuntu1]
-queuebot:#ubuntu-release- New: rejected open-iscsi [arm64] (groovy-proposed) [2.1.1-1ubuntu1]
-queuebot:#ubuntu-release- New: rejected open-iscsi [s390x] (groovy-proposed) [2.1.1-1ubuntu1]
-queuebot:#ubuntu-release- New: rejected open-iscsi [ppc64el] (groovy-proposed) [2.1.1-1ubuntu1]
-queuebot:#ubuntu-release- New binary: telegraf [arm64] (groovy-proposed/universe) [1.15.1+ds1-0ubuntu1] (no packageset)
<sergiodj> vorlon: thanks
-queuebot:#ubuntu-release- Packageset: 6878 entries have been added or removed
<coreycb> rbasak: I assume you're EOD but just wanted to let you know ceph is re-uploaded and regression potential section added for the focal SRU
<Eickmeyer> ubuntu-archive: Only two left! dragonfly-reverb and new-session-manager, both are reuploads to fix minor issues vorlon found. As far as NEW binaries, we have geonkick for Studio and plasma-wallpaper-dynamic for KDE Plasma/Kubuntu. I'd appreciate the help!
-queuebot:#ubuntu-release- New binary: bandage [amd64] (groovy-proposed/universe) [0.8.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-relational-record [s390x] (groovy-proposed/universe) [0.2.2.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-relational-record [amd64] (groovy-proposed/universe) [0.2.2.0-4] (no packageset)
<rbasak> coreycb: thanks!
<rbasak> I've run out of time today, but I'll try to catch up tomorrow
-queuebot:#ubuntu-release- New binary: golang-github-bsipos-thist [amd64] (groovy-proposed/universe) [1.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-xorcare-pointer [amd64] (groovy-proposed/universe) [1.1.0+git20200211.75cc9bc-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-grafana-grafana-plugin-model [amd64] (groovy-proposed/universe) [0.0~git20190930.1fc953a-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-aws-partitions [amd64] (groovy-proposed/universe) [1.354.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-crewjam-httperr [amd64] (groovy-proposed/universe) [0.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-uniform-notifier [amd64] (groovy-proposed/universe) [1.13.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-path-expander [amd64] (groovy-proposed/universe) [1.1.0-1] (no packageset)
<sforshee> sil2100: any progress on linux-signed?
-queuebot:#ubuntu-release- New binary: commonmark [amd64] (groovy-proposed/universe) [0.9.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-timberio-go-datemath [amd64] (groovy-proposed/universe) [0.1.0+git20200323.74ddef6-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-faraday-middleware-aws-sigv4 [amd64] (groovy-proposed/universe) [0.3.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-unparser [amd64] (groovy-proposed/universe) [0.4.7-1] (no packageset)
-queuebot:#ubuntu-release- New binary: golang-github-hashicorp-terraform-plugin-test [amd64] (groovy-proposed/universe) [1.3.0+git20200503.328f99a-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-rspec-junit-formatter [amd64] (groovy-proposed/universe) [0.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-anima [amd64] (groovy-proposed/universe) [0.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-wait-for-it [amd64] (groovy-proposed/universe) [0.2.1-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected ceph [source] (focal-proposed) [15.2.3-0ubuntu0.20.04.2]
-queuebot:#ubuntu-release- New binary: haskell-relational-record [ppc64el] (groovy-proposed/universe) [0.2.2.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-relational-record [arm64] (groovy-proposed/universe) [0.2.2.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-relational-record [armhf] (groovy-proposed/universe) [0.2.2.0-4] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-relational-record [riscv64] (groovy-proposed/universe) [0.2.2.0-4] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-relational-record [riscv64] (groovy-proposed) [0.2.2.0-4]
-queuebot:#ubuntu-release- New: accepted commonmark [amd64] (groovy-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-timberio-go-datemath [amd64] (groovy-proposed) [0.1.0+git20200323.74ddef6-1]
-queuebot:#ubuntu-release- New: accepted haskell-relational-record [armhf] (groovy-proposed) [0.2.2.0-4]
-queuebot:#ubuntu-release- New: accepted ruby-anima [amd64] (groovy-proposed) [0.3.1-2]
-queuebot:#ubuntu-release- New: accepted ruby-wait-for-it [amd64] (groovy-proposed) [0.2.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-hashicorp-terraform-plugin-test [amd64] (groovy-proposed) [1.3.0+git20200503.328f99a-1]
-queuebot:#ubuntu-release- New: accepted haskell-relational-record [ppc64el] (groovy-proposed) [0.2.2.0-4]
-queuebot:#ubuntu-release- New: accepted haskell-relational-record [arm64] (groovy-proposed) [0.2.2.0-4]
-queuebot:#ubuntu-release- New: accepted ruby-rspec-junit-formatter [amd64] (groovy-proposed) [0.4.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-crewjam-httperr [amd64] (groovy-proposed) [0.2.0-1]
-queuebot:#ubuntu-release- New: accepted golang-github-xorcare-pointer [amd64] (groovy-proposed) [1.1.0+git20200211.75cc9bc-1]
-queuebot:#ubuntu-release- New: accepted ruby-faraday-middleware-aws-sigv4 [amd64] (groovy-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-uniform-notifier [amd64] (groovy-proposed) [1.13.0-2]
-queuebot:#ubuntu-release- New: accepted golang-github-grafana-grafana-plugin-model [amd64] (groovy-proposed) [0.0~git20190930.1fc953a-1]
-queuebot:#ubuntu-release- New: accepted ruby-path-expander [amd64] (groovy-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-aws-partitions [amd64] (groovy-proposed) [1.354.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-unparser [amd64] (groovy-proposed) [0.4.7-1]
-queuebot:#ubuntu-release- New: accepted bandage [amd64] (groovy-proposed) [0.8.1-2]
-queuebot:#ubuntu-release- New: accepted haskell-relational-record [amd64] (groovy-proposed) [0.2.2.0-4]
-queuebot:#ubuntu-release- New: accepted golang-github-bsipos-thist [amd64] (groovy-proposed) [1.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-relational-record [s390x] (groovy-proposed) [0.2.2.0-4]
-queuebot:#ubuntu-release- Unapproved: linux-firmware (focal-proposed/main) [1.187.2 => 1.187.3] (core, kernel)
<sforshee> vorlon: I'm guessing sil2100 might be eod, would you be able to look at the missing binaries problem for linux-signed in groovy-proposed? We intentionally disabled signing for arm64 because grub fails to boot signed arm64 kernels, therefore we cannot test them to verify that lockdown is being enabled under secure boot
<LocutusOfBorg> yay new nodejs upload
<LocutusOfBorg>  lzop | 1.04-1build1 | groovy           | source, amd64, arm64, armhf, ppc64el, riscv64, s390x
<LocutusOfBorg> vorlon, ^^ i386 please? ffmpeg
<LocutusOfBorg> I mean, do_ko did a no change rebuild to bring i386 back, but it isn't there...
-queuebot:#ubuntu-release- New: accepted linux-signed-dell300x [amd64] (bionic-proposed) [4.15.0-1001.3]
<vorlon> LocutusOfBorg: hmm we looked at lzop once before, didn't we? why did it go away again
<LocutusOfBorg> who knows... :/
<vorlon> ok, I'll investigate
<LocutusOfBorg> thanks
<vorlon> sforshee: fwiw you should be able to test with the eoan grub IIRC; and also the groovy grub should be fixed for arm64 soon AIUI (cc: juliank )
<mwhudson> vorlon: thanks, that probably ensures we will never see the crash again
<vorlon> :()
<vorlon> :)
<sforshee> vorlon: when I talked to dannf about it he said that no release had a fully functional signed arm64 boot chain, so the best I could hope for was to find some combination of shim/grub from different releases that might work
<sforshee> and I didn't go to the effort of trying to figure that all out
<vorlon> sforshee: it's correct that no release has a fully functional secureboot chain; shim is now functional in groovy (and needs to be SRUed back to all releases - not sure where we stand with that), I *think* grub worked in eoan at release time so you could cherry-pick the binary for testing and grub will be working soon in groovy so it would be lovely to have a working linux-signed to go with it
-queuebot:#ubuntu-release- New binary: ruby-bullet [amd64] (groovy-proposed/universe) [6.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-aws-sdk-core [amd64] (groovy-proposed/universe) [3.104.3-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-morpher [amd64] (groovy-proposed/universe) [0.2.6-1] (no packageset)
<vorlon> sforshee: why are ppc64el and s390x also showing as dropped?
<sforshee> vorlon: they aren't dropped, those binaries do contain the version name so they don't exist in the new build
<sforshee> *version in the package name
<vorlon> ah, checking
<sforshee> I'll try to get a signed arm64 kernel tested for the next upload
<sforshee> vorlon: we'll no doubt need a d-i upload too
-queuebot:#ubuntu-release- Unapproved: alsa-ucm-conf (focal-proposed/main) [1.2.2-1ubuntu0.1 => 1.2.2-1ubuntu0.2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-puma-worker-killer [amd64] (groovy-proposed/universe) [0.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: open-iscsi [s390x] (groovy-proposed/main) [2.1.1-1ubuntu2] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: open-iscsi [ppc64el] (groovy-proposed/main) [2.1.1-1ubuntu2] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: open-iscsi [amd64] (groovy-proposed/main) [2.1.1-1ubuntu2] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: open-iscsi [arm64] (groovy-proposed/main) [2.1.1-1ubuntu2] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- New binary: open-iscsi [armhf] (groovy-proposed/main) [2.1.1-1ubuntu2] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: alsa-lib (focal-proposed/main) [1.2.2-2.1ubuntu1 => 1.2.2-2.1ubuntu2] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: pulseaudio (focal-proposed/main) [1:13.99.1-1ubuntu3.5 => 1:13.99.1-1ubuntu3.6] (desktop-core, i386-whitelist, ubuntu-server)
<vorlon> sforshee: ok, so making britney completely happy wrt the binary disappearing from arm64 would seem to require me removing the arm64 kernel from groovy release, which of course we don't want to do; so I'll try a force hint here instead
<Eickmeyer> ubuntu-archive: Only two left! dragonfly-reverb and new-session-manager, both are reuploads to fix minor issues vorlon found. As far as NEW binaries, we have geonkick for Studio and plasma-wallpaper-dynamic for KDE Plasma/Kubuntu. Please accept these soon!!!! :)
-queuebot:#ubuntu-release- New binary: open-iscsi [riscv64] (groovy-proposed/main) [2.1.1-1ubuntu2] (ubuntu-desktop, ubuntu-server)
<seb128> Eickmeyer, hey, I know that you are eager to see those reviews finished but please stop repeating the same messages several times a day
<Eickmeyer> It's the only way any work gets done.
<vorlon> it's really not
<Eickmeyer> If that's true, then why did it take me sending that email for them to even get looked at in the first place?
<Eickmeyer> After a month of wait?
<Eickmeyer> Basically, my time is short. I need these packages reviewed or I'll run out of time to fix issues as they arise.
<Eickmeyer> The two source NEW are re-reviews, and of course, get bumped to the back of the line because they were rejected initially. That doesn't seem to be fair. The others are binary NEW and should be a quick click of a button.
-queuebot:#ubuntu-release- New: accepted open-iscsi [amd64] (groovy-proposed) [2.1.1-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted open-iscsi [armhf] (groovy-proposed) [2.1.1-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted open-iscsi [riscv64] (groovy-proposed) [2.1.1-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted open-iscsi [arm64] (groovy-proposed) [2.1.1-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted open-iscsi [s390x] (groovy-proposed) [2.1.1-1ubuntu2]
-queuebot:#ubuntu-release- New: accepted open-iscsi [ppc64el] (groovy-proposed) [2.1.1-1ubuntu2]
<vorlon> Eickmeyer: my expectation for new-ession-manager was that both the source and binary package names would be changed, not just the binary name.  Do you mind if I fix this up and reupload?
<Eickmeyer> vorlon: That's fine.
-queuebot:#ubuntu-release- New: rejected new-session-manager [source] (groovy-proposed) [1.3.2-0ubuntu1]
-queuebot:#ubuntu-release- New binary: linuxaudio-new-session-manager [amd64] (groovy-proposed/none) [1.3.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: linuxaudio-new-session-manager [s390x] (groovy-proposed/none) [1.3.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: linuxaudio-new-session-manager [arm64] (groovy-proposed/universe) [1.3.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: linuxaudio-new-session-manager [armhf] (groovy-proposed/universe) [1.3.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: linuxaudio-new-session-manager [riscv64] (groovy-proposed/universe) [1.3.2-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted plasma-wallpaper-dynamic [amd64] (groovy-proposed) [3.3.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-wallpaper-dynamic [ppc64el] (groovy-proposed) [3.3.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-wallpaper-dynamic [arm64] (groovy-proposed) [3.3.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-wallpaper-dynamic [s390x] (groovy-proposed) [3.3.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-wallpaper-dynamic [armhf] (groovy-proposed) [3.3.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted plasma-wallpaper-dynamic [riscv64] (groovy-proposed) [3.3.3-0ubuntu1]
-queuebot:#ubuntu-release- New binary: linuxaudio-new-session-manager [ppc64el] (groovy-proposed/universe) [1.3.2-0ubuntu1] (no packageset)
<rbasak> People are asking if 18.04 is supposed to prompt for LTS upgrade now that 20.04.1 is out
<rbasak> https://www.reddit.com/r/Ubuntu/comments/icv4d4/any_idea_why_so_many_articles_about_20041_release/
<rbasak> Am I right in thinking that the switch hasn't been switched yet?
<sarnold> rbasak: I'm 90% sure that the 20.04 upgrade will only be offered once focal is removed from https://changelogs.ubuntu.com/meta-release-development
<sarnold> rbasak: I haven't heard why that hasn't happened yet, though
<rbasak> Ah
<rbasak> And I guessed https://changelogs.ubuntu.com/meta-release-lts, and that doesn't list Focal.
<rbasak> Assuming that's the switch, it hasn't been switched :)
<rbasak> Thanks!
<sarnold> rbasak: hah, I don't think I've seen this one before :)
<sarnold> perhaps this release requires two switches to be flipped, as it were..
<rbasak> Without looking at the code or someone claiming they know for sure we're both speculating. But my speculation agrees with yours :)
<RikMills> the release upgrader in normal mode with LTS only updates selected, checks the meta-release-lts
-queuebot:#ubuntu-release- New binary: golang-github-cryptix-wav [amd64] (groovy-proposed/none) [0.0~git20180415.8bdace6-1] (no packageset)
<RikMills> https://discourse.ubuntu.com/t/focal-fossa-20-04-1-lts-point-release-status-tracking/17604
-queuebot:#ubuntu-release- New binary: ruby-morpher [amd64] (groovy-proposed/universe) [0.2.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-indexed-profunctors [amd64] (groovy-proposed/none) [0.1-1] (no packageset)
<RikMills> "Upgrades from 18.04 to 20.04.1 are still disabled as we are working through a few upgrade blockers"
-queuebot:#ubuntu-release- New binary: haskell-binary-instances [amd64] (groovy-proposed/none) [1.0.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-contravariant-extras [amd64] (groovy-proposed/none) [0.3.5.1-1] (no packageset)
<RikMills> rbasak: see the above discourse link
<RikMills> I assume the blocker info is still accurate
-queuebot:#ubuntu-release- New binary: haskell-binary-instances [arm64] (groovy-proposed/universe) [1.0.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-indexed-profunctors [arm64] (groovy-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-binary-instances [s390x] (groovy-proposed/universe) [1.0.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-contravariant-extras [arm64] (groovy-proposed/universe) [0.3.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted microcode-initrd [source] (groovy-proposed) [1]
-queuebot:#ubuntu-release- New binary: haskell-contravariant-extras [s390x] (groovy-proposed/universe) [0.3.5.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: microcode-initrd [amd64] (groovy-proposed/none) [1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-indexed-profunctors [armhf] (groovy-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-indexed-profunctors [s390x] (groovy-proposed/universe) [0.1-1] (no packageset)
<rbasak> RikMills: thanks!
-queuebot:#ubuntu-release- New binary: haskell-indexed-profunctors [riscv64] (groovy-proposed/universe) [0.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-binary-instances [s390x] (groovy-proposed) [1.0.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-contravariant-extras [s390x] (groovy-proposed) [0.3.5.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-indexed-profunctors [riscv64] (groovy-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-contravariant-extras [arm64] (groovy-proposed) [0.3.5.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-indexed-profunctors [s390x] (groovy-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-indexed-profunctors [armhf] (groovy-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted golang-github-cryptix-wav [amd64] (groovy-proposed) [0.0~git20180415.8bdace6-1]
-queuebot:#ubuntu-release- New: accepted haskell-binary-instances [arm64] (groovy-proposed) [1.0.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-indexed-profunctors [amd64] (groovy-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted ruby-morpher [amd64] (groovy-proposed) [0.2.6-1]
-queuebot:#ubuntu-release- New: accepted ruby-puma-worker-killer [amd64] (groovy-proposed) [0.1.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-binary-instances [amd64] (groovy-proposed) [1.0.0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-indexed-profunctors [arm64] (groovy-proposed) [0.1-1]
-queuebot:#ubuntu-release- New: accepted haskell-contravariant-extras [amd64] (groovy-proposed) [0.3.5.1-1]
-queuebot:#ubuntu-release- New: accepted ruby-morpher [amd64] (groovy-proposed) [0.2.6-2]
-queuebot:#ubuntu-release- New: accepted ruby-aws-sdk-core [amd64] (groovy-proposed) [3.104.3-2]
-queuebot:#ubuntu-release- New: accepted ruby-bullet [amd64] (groovy-proposed) [6.1.0-1]
-queuebot:#ubuntu-release- New binary: haskell-contravariant-extras [armhf] (groovy-proposed/universe) [0.3.5.1-1] (no packageset)
#ubuntu-release 2020-08-20
<vorlon> sergiodj: fwiw telegraf appears to be built without pie enabled, according to lintian
-queuebot:#ubuntu-release- New: accepted telegraf [amd64] (groovy-proposed) [1.15.1+ds1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted telegraf [armhf] (groovy-proposed) [1.15.1+ds1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted telegraf [s390x] (groovy-proposed) [1.15.1+ds1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted telegraf [arm64] (groovy-proposed) [1.15.1+ds1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted telegraf [ppc64el] (groovy-proposed) [1.15.1+ds1-0ubuntu1]
<sergiodj> vorlon: I will look into that, thanks for the heads up
-queuebot:#ubuntu-release- New: accepted geonkick [amd64] (groovy-proposed) [2.3.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted geonkick [armhf] (groovy-proposed) [2.3.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted geonkick [riscv64] (groovy-proposed) [2.3.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted geonkick [arm64] (groovy-proposed) [2.3.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted geonkick [s390x] (groovy-proposed) [2.3.6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted geonkick [ppc64el] (groovy-proposed) [2.3.6-0ubuntu1]
-queuebot:#ubuntu-release- New binary: ruby-aws-sdk-cloudformation [amd64] (groovy-proposed/universe) [1.41.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-generic-lens-core [amd64] (groovy-proposed/universe) [2.0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-generic-lens-core [s390x] (groovy-proposed/universe) [2.0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-aws-sdk-kms [amd64] (groovy-proposed/universe) [1.24.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-generic-lens-core [arm64] (groovy-proposed/universe) [2.0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-generic-lens-core [armhf] (groovy-proposed/universe) [2.0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-generic-lens-core [ppc64el] (groovy-proposed/universe) [2.0.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: haskell-generic-lens-core [riscv64] (groovy-proposed/universe) [2.0.0.0-1] (no packageset)
<LocutusOfBorg> vorlon, just for heads up, lzop has been added and removed to bootstrap lintian, the problem is that lzop is also a runtime dependency of lintian, so removing it is a sad story
-queuebot:#ubuntu-release- Unapproved: qemu (focal-proposed/main) [1:4.2-3ubuntu6.4 => 1:4.2-3ubuntu6.5] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: accepted alsa-lib [source] (focal-proposed) [1.2.2-2.1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted alsa-ucm-conf [source] (focal-proposed) [1.2.2-1ubuntu0.2]
-queuebot:#ubuntu-release- Unapproved: accepted pulseaudio [source] (focal-proposed) [1:13.99.1-1ubuntu3.6]
-queuebot:#ubuntu-release- Packageset: Removed commonmark-bkrs from i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added commonmark to i386-whitelist in groovy
-queuebot:#ubuntu-release- Unapproved: secureboot-db (xenial-proposed/main) [1.4~ubuntu0.16.04.1 => 1.4.1~ubuntu0.16.04.1] (core)
-queuebot:#ubuntu-release- Unapproved: secureboot-db (bionic-proposed/main) [1.4~ubuntu0.18.04.1 => 1.4.1] (core)
-queuebot:#ubuntu-release- Unapproved: secureboot-db (focal-proposed/main) [1.5 => 1.6~20.04.1] (core)
<Laney> restoring lzop for qtbase-opensource-src
-queuebot:#ubuntu-release- Unapproved: fonts-noto (focal-proposed/main) [20200323-1 => 20200323-1build1~ubuntu20.04.1] (desktop-core, personal-gunnarhj, ubuntu-server)
-queuebot:#ubuntu-release- Packageset: Added lzop to i386-whitelist in groovy
-queuebot:#ubuntu-release- Unapproved: language-selector (focal-proposed/main) [0.204 => 0.204.1] (core, personal-gunnarhj)
<ricotz> Laney, can you restore libtext-xslate-perl:i386 too?
<ricotz> https://launchpad.net/ubuntu/+source/ffmpeg/7:4.3.1-2ubuntu1/+build/19846675
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1094.104] (kernel)
<rbasak> sil2100: o/ I'm just looking at the ceph and apport SRUs as these are half done from my shift yesterday
<sil2100> rbasak: ok, thanks for the heads up o/ I'm doing kernel SRUs anyway right now
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (bionic-proposed) [2.20.9-0ubuntu7.17]
-queuebot:#ubuntu-release- Unapproved: util-linux (focal-proposed/main) [2.34-0.1ubuntu9 => 2.34-0.1ubuntu9.1] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (focal-proposed) [15.2.3-0ubuntu0.20.04.2]
<Laney> ricotz: lemme see
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1051.55~16.04.1] (kernel)
<Laney> done
<Laney> same one is required for qt too
<Laney> I should check if there's any more, let me do that
<Laney> hard to tell because of lintian
<Laney> ubuntu-archive what do we normally do with perl deps like the one blocking lintian on excuses?
<Laney> iirc there's some kind of lightweight procedure for that
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (focal-proposed) [2.04-1ubuntu26.3]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (focal-proposed) [2.04-1ubuntu26.3]
<seb128> Laney, that's a MIR team question, https://wiki.ubuntu.com/MainInclusionProcess has an exception section only for fonts
<seb128> there is a note in the maintenance section but no special process afaik
<seb128> afaik foundations owns to do the MIR work for lintian
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1093.103~16.04.1] (kernel)
<Laney> well if I can clear it out during +1 because there is in fact a procedure then it would be good to do that, hopefully there is and someone remembers / can document it
<Laney> feel free to reply if you're on the MIR team and know something good re: that
<xnox> I love this! "Rejected: Symbolic link for debian/copyright not allowed"
-queuebot:#ubuntu-release- Packageset: Added libtext-xslate-perl to i386-whitelist in groovy
<ricotz> Laney, thank you, seems ffmpeg needs a kick later
-queuebot:#ubuntu-release- Unapproved: zfs-linux (bionic-proposed/main) [0.7.5-1ubuntu16.9 => 0.7.5-1ubuntu16.10] (core)
<Laney> ricotz: no, it will auto retry
<ricotz> Laney, ah it did, and failed :\
<Laney> bah, ok, now it really fails to build due to lintian
<Laney> more bootstrapping required
-queuebot:#ubuntu-release- Packageset: Added libdata-messagepack-perl to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added libmouse-perl to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added libproc-processtable-perl to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added libtext-levenshteinxs-perl to i386-whitelist in groovy
<Laney> ok lintian looks installable on i386 now
<Laney> happy days
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1094.104]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1093.103~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1051.55~16.04.1]
<vorlon> wahoo
<vorlon> wgrant, cjwatson: has there been a known regression in launchpad handling of multiarch-annotated build-dependencies?  both :native and :any exist in the archive, but https://launchpad.net/ubuntu/+source/gdbm/1.18.1-5ubuntu3 fails weirdly
<vorlon> juliank: ^^ or is this an apt change?
<juliank> vorlon: not aware of anything
<vorlon> sil2100, bdmurray: why does http://cdimage.ubuntu.com/releases/19.10/release/ (and http://cdimage.ubuntu.com/releases/19.10.1/release/) exist with no images in the directory?
<vorlon> (reported via a misdirected mail to https://launchpad.net/~ubuntu-release/+mailinglist-moderate which goes nowhere)
<vorlon> aaaaand why does http://old-releases.ubuntu.com/releases/19.10/ still exist when it's removed from ancientminister
<sil2100> Looking!
<sil2100> vorlon: ok, so that's not yet finished, I was waiting to get info about the archival of images before I proceeded since there's the source images there still
<vorlon> ok
<sil2100> So I'll move them along with the rest of cdimage stuff
<vorlon> oh, and releases.ubuntu.com/19.10 redirected me to old-releases, so that's by design
<vorlon> (and I didn't notice the url had changed when I copy-pasted ;)
<sil2100> Darn sneaky redirects ;)
<sil2100> Anyway, pinky promise I'll finish the archivals tomorrow
<sil2100> Since today I am finishing up appliances release
<vorlon> ok
<cjwatson> vorlon: I don't think it's possible for that to be a Launchpad regression; it's just calling sbuild there
<cjwatson> vorlon: "but it is not installable" generally means that the dependency target *exists* but is itself uninstallable
<cjwatson> vorlon: (possibly in combination with other build-dependencies)
<cjwatson> vorlon: apt has never been verbose about the actual root cause of this type of problem without drilling down
<vorlon> cjwatson: hmm, I can't reproduce any build-dep uninstallability locally with apt :/
<vorlon> cjwatson: but a retry of the package in the main archive again failed, whereas https://launchpad.net/~vorlon/+archive/ubuntu/ppa/+build/19856882 succeeded in installing the build-deps without the multiarch annotation...
<vorlon> cjwatson: right, the problem here is me forgetting the semantics of M-A: foreign + :any / :native until I double-checked https://wiki.ubuntu.com/MultiarchCross - so I'm just doing an invalid thing here
<cjwatson> vorlon: OK :)
<cjwatson> And yeah, I always have to look those up too
<sforshee> vorlon: I'm not very experienced at reading update_output.txt, but I think nvidia-graphics-drivers-450 cannot migrate in groovy because it breaks some l-r-m packages copied forward from focal. Is there anything we can do about that?
<sforshee> short of getting all of those kernels updated in groovy ...
<ginggs> sforshee: i think someone needs to clear the block-proposed tag from LP: #1889111
<ubot5> Launchpad bug 1889111 in nvidia-graphics-drivers-450 (Ubuntu) "nvidia-450 can't promote until linux+linux-restricted-modules is rebuilt against it" [Undecided,Invalid] https://launchpad.net/bugs/1889111
<sforshee> ginggs: the bug status in invalid now, and update_excuses isn't saying anything about it being blocked, so that isn't the problem
<sforshee> it looks like it's because it's now providing nvidia-kernel-common-440 and is outside the versions required in the depends: of those copy forward packages
<Eickmeyer> vorlon: How are the linuxaudio-new-session-manager binaries looking?
<Eickmeyer> Also, RAOF had deferred on dragonfly-reverb because he had questions about it regarding distribution of fonts in a .cpp format (I think?).
-queuebot:#ubuntu-release- New binary: haskell-generic-lens-core [amd64] (groovy-proposed/universe) [2.0.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-aws-sdk-cloudformation [amd64] (groovy-proposed/universe) [1.41.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-markdown-it [amd64] (groovy-proposed/universe) [10.0.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-aws-sdk-kms [amd64] (groovy-proposed/universe) [1.24.0-3] (no packageset)
-queuebot:#ubuntu-release- New binary: netgen [amd64] (groovy-proposed/universe) [6.2.2006+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted haskell-generic-lens-core [amd64] (groovy-proposed) [2.0.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-generic-lens-core [armhf] (groovy-proposed) [2.0.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-generic-lens-core [riscv64] (groovy-proposed) [2.0.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-generic-lens-core [amd64] (groovy-proposed) [2.0.0.0-2]
-queuebot:#ubuntu-release- New: accepted ruby-aws-sdk-cloudformation [amd64] (groovy-proposed) [1.41.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-aws-sdk-kms [amd64] (groovy-proposed) [1.24.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-generic-lens-core [arm64] (groovy-proposed) [2.0.0.0-1]
-queuebot:#ubuntu-release- New: accepted haskell-generic-lens-core [s390x] (groovy-proposed) [2.0.0.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-aws-sdk-cloudformation [amd64] (groovy-proposed) [1.41.0-2]
-queuebot:#ubuntu-release- New: accepted haskell-generic-lens-core [ppc64el] (groovy-proposed) [2.0.0.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-aws-sdk-kms [amd64] (groovy-proposed) [1.24.0-3]
-queuebot:#ubuntu-release- New: accepted node-markdown-it [amd64] (groovy-proposed) [10.0.0+dfsg-1]
#ubuntu-release 2020-08-21
-queuebot:#ubuntu-release- New binary: libreoffice [amd64] (groovy-proposed/main) [1:7.0.1~rc1-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: node-prosemirror-markdown [amd64] (groovy-proposed/universe) [1.4.4-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-aws-sdk-s3 [amd64] (groovy-proposed/universe) [1.48.0-3] (no packageset)
-queuebot:#ubuntu-release- Packageset: Added libdata-section-simple-perl to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added libdevel-checkcompiler-perl to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added liblocale-us-perl to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added libmodule-build-xsutil-perl to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added libpath-class-perl to i386-whitelist in groovy
-queuebot:#ubuntu-release- Packageset: Added libregexp-common-perl to i386-whitelist in groovy
-queuebot:#ubuntu-release- New: accepted linuxaudio-new-session-manager [amd64] (groovy-proposed) [1.3.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted linuxaudio-new-session-manager [armhf] (groovy-proposed) [1.3.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted linuxaudio-new-session-manager [riscv64] (groovy-proposed) [1.3.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted linuxaudio-new-session-manager [arm64] (groovy-proposed) [1.3.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted linuxaudio-new-session-manager [s390x] (groovy-proposed) [1.3.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted linuxaudio-new-session-manager [ppc64el] (groovy-proposed) [1.3.2-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted haskell-contravariant-extras [armhf] (groovy-proposed) [0.3.5.1-1]
-queuebot:#ubuntu-release- New: accepted node-prosemirror-markdown [amd64] (groovy-proposed) [1.4.4-1]
-queuebot:#ubuntu-release- New: accepted ruby-aws-sdk-s3 [amd64] (groovy-proposed) [1.48.0-3]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (focal-proposed) [0.8.3-1ubuntu12.4]
-queuebot:#ubuntu-release- Unapproved: accepted zfs-linux [source] (bionic-proposed) [0.7.5-1ubuntu16.10]
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (focal-proposed) [1.187.3]
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-meta [source] (xenial-proposed) [1.361.5]
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (focal-proposed) [1:4.2-3ubuntu6.5]
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (focal-proposed) [11ubuntu5.2]
-queuebot:#ubuntu-release- New binary: base-files [amd64] (focal-proposed/main) [11ubuntu5.2] (core, i386-whitelist)
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (bionic-proposed) [10.1ubuntu2.10]
-queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (xenial-proposed) [9.4ubuntu4.13]
-queuebot:#ubuntu-release- New binary: base-files [amd64] (bionic-proposed/main) [10.1ubuntu2.10] (core)
-queuebot:#ubuntu-release- New binary: base-files [amd64] (xenial-proposed/main) [9.4ubuntu4.13] (core)
 * Laney gently helps the haskell transition along with a -validity fix
-queuebot:#ubuntu-release- New binary: termtosvg [amd64] (groovy-proposed/universe) [1.1.0+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure-5.4 [amd64] (bionic-proposed/main) [5.4.0-1023.23~18.04.1] (no packageset)
<mdeslaur> So the libreswan autopkgtest is now failing because it looks like launchpad now knows about "needs-internet", but internet access isn't complete...does launchpad support "open-internet-access" or do I drop the test completely?
<mdeslaur> s/launchpad/the autopkgtest infrastructure/
<mdeslaur> Laney: ^ perhaps you know?
<Laney> mdeslaur: open-internet-access is still just a proposal, I don't think we have a way to say the equivalent yet
<Laney> It looks from a quick reading like that test might want to be skippable and exit 77 if the ping fails, or something like that?
<mdeslaur> Laney: is 77 a special exit codes? where can I see where those are documented?
<Laney> mdeslaur: https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst "skippable"
<mdeslaur> Laney: ah, perfect, just what I needed. Thanks!
<Laney> np
<mdeslaur> ebarretto: ^
<Laney> that feels upstreamable too, ideally
<mdeslaur> yeah
<ebarretto> mdeslaur, ack, thanks! thanks Laney too!
<Laney> np!
<Laney> LocutusOfBorg: thx for uploading that patch
<Laney> I forgot how debian-haskell works, should probably leave that group
<Laney> or maybe somneone did already
<Laney> removed me*
-queuebot:#ubuntu-release- New: accepted netgen [amd64] (groovy-proposed) [6.2.2006+dfsg-1]
-queuebot:#ubuntu-release- New: accepted termtosvg [amd64] (groovy-proposed) [1.1.0+dfsg-2]
<ricotz> hi, please retry ppc64el and s390x for https://launchpad.net/ubuntu/+source/libreoffice/1:7.0.1~rc1-0ubuntu1
<Laney> ricotz: I will, I just asked Launchpad people (on an internal channel) about these ones to see if there's something for them to look at first
<didrocks> cjwatson: hey, once you get some time, Iâm puzzled to see why germinate against groovy-proposed output lines like golang-google-api-dev                               | golang-google-api                     | Rescued from golang-google-api                   | Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>                |         3587748 |           93367
<didrocks> golang-google-api is in universe, I donât find anything in any seed and itâs only against proposed
<didrocks> (rationale is: this one and some others are showing up as root nodes on component-mismatches)
<ricotz> Laney, ty
<Laney> ricotz: It looks like there's a problem with the buildds though so it might struggle to finish until that's sorted out
<Laney> but we'll see
<Eickmeyer> Not sure if it's related, but I'm having a similar problem with germinate at the moment.
<Eickmeyer> https://paste.ubuntu.com/p/r45dTCXJNZ/
<Eickmeyer> Nevermind, seems to be working now.
<cjwatson> didrocks: This is legitimately extremely confusing, but I think it *might* be because golang-goprotobuf in -proposed has gained a dependency on golang-google-protobuf-dev, or similar?  Basically a bunch of golang stuff ends up in the build-sources closure of the supported-cloud seed and that then activates the "Extra-Include: ... *-dev" seed in supported
<cjwatson> didrocks: I think it might be worth adding "Extra-Exclude: golang-*-dev" to override that for golang, since the "include all *-dev packages from otherwise-supported things" rule doesn't make as much sense for lang
<cjwatson> *golang
<cjwatson> Eickmeyer: Certainly unrelated.  But where did you see that?
<Eickmeyer> cjwatson: Output from updating the ubuntustudio-meta source, but it went away. I think it was just a burp in the git server.
<didrocks> cjwatson: that makes sense, Iâll look at the Extra-Exclude indeed as golang package are special in that regards. Thanks for looking!
<ahasenack> vorlon: hi, tjaalton accepted my base-files sru, but a) the NEW package needs to be accepted; b) it needs to go into main; c) I missed the bug number in d/changelog of ubuntu-meta's x and b upload (focal has it, but wasn't accepted). And I think he is EOD now
<tjaalton> right, i'm off already for today, can handle them on monday if needed
<ahasenack> thanks
<LocutusOfBorg> Laney, thenks you to for providing the patch, otherwise all the work would have been useless :)
<LocutusOfBorg> but next time please just commit on git and upload
<LocutusOfBorg> (I added you to the team)
-queuebot:#ubuntu-release- New binary: libreoffice [ppc64el] (groovy-proposed/main) [1:7.0.1~rc1-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected secureboot-db [source] (bionic-proposed) [1.4.1]
-queuebot:#ubuntu-release- Unapproved: rejected secureboot-db [source] (xenial-proposed) [1.4.1~ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected secureboot-db [source] (focal-proposed) [1.6~20.04.1]
<Laney> LocutusOfBorg: It confuses me with the package plan and stuff, I'm scared of breaking it because I forgot how all that works and I don't fancy re-learning
<Laney> but thanks
<bdmurray> vorlon: Could you update the autopkgtest-cloud worker configurations?
<vorlon> bdmurray: done
<bdmurray> vorlon: thanks!
<vorlon> Eickmeyer: hmm so I understood we were redoing dragonfly-reverb in order to fix the debian/copyright warnings from lintian... and lintian -I still shows a bunch of them
<LocutusOfBorg> Laney, I just do and commit on git, and git tag version...
<LocutusOfBorg> nothing more :) I know they have stuff but meh, I don't care
<cjwatson> Eickmeyer: There were some performance problems earlier today, indeed, worked around by repacking a particularly heavy repository
<vorlon> juliank: grub2 has a grubzfs-testsuite autopkgtest regression focal that I believe had a matching one in groovy fixed by an update to grubzfs-testsuite.  Should we be SRUing this in focal?
#ubuntu-release 2020-08-22
<Eickmeyer> cjwatson: Ok, that explains it.
<Eickmeyer> vorlon: I'll look again, but I didn't get such warnings when I tried it.
<ginggs> I've bootstrapped fpc on ppc64el in a PPA https://launchpad.net/~ginggs/+archive/ubuntu/sru/+packages  - how can I get it into the archive?
<Eickmeyer> vorlon: Figured out what I did wrong. I was using lowercase I, not uppercase.
<Eickmeyer> vorlon: I fixed it. Not sure if you want to wait for teward to reupload or if you just want to grab the last two commits at https://code.launchpad.net/dragonfly-reverb.
-queuebot:#ubuntu-release- New binary: libreoffice [s390x] (groovy-proposed/main) [1:7.0.1~rc1-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: ilmbase [amd64] (groovy-proposed/universe) [2.5.3-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: ilmbase [s390x] (groovy-proposed/universe) [2.5.3-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: ilmbase [ppc64el] (groovy-proposed/universe) [2.5.3-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: pysiogame [amd64] (groovy-proposed/universe) [4.20.01-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ilmbase [i386] (groovy-proposed/universe) [2.5.3-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: ilmbase [arm64] (groovy-proposed/universe) [2.5.3-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: ilmbase [armhf] (groovy-proposed/universe) [2.5.3-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: ilmbase [riscv64] (groovy-proposed/universe) [2.5.3-2] (i386-whitelist, kubuntu)
<juliank> vorlon: yes it'll come
-queuebot:#ubuntu-release- Unapproved: kazam (focal-proposed/universe) [1.4.5-3 => 1.4.5-3ubuntu0.1] (no packageset)
<ginggs> fpc 3.2.0+dfsg-7build6 is pending here for some time https://launchpad.net/ubuntu/+source/fpc/+publishinghistory
<ginggs> does something need unblocking?
-queuebot:#ubuntu-release- New binary: libreoffice [arm64] (groovy-proposed/main) [1:7.0.1~rc1-0ubuntu1] (ubuntu-desktop)
<LocutusOfBorg> please help britney coming back
-queuebot:#ubuntu-release- New binary: cfitsio [s390x] (groovy-proposed/universe) [3.490-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: cfitsio [ppc64el] (groovy-proposed/universe) [3.490-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: cfitsio [arm64] (groovy-proposed/universe) [3.490-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: cfitsio [amd64] (groovy-proposed/universe) [3.490-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: cfitsio [armhf] (groovy-proposed/universe) [3.490-2] (kubuntu)
-queuebot:#ubuntu-release- New binary: cfitsio [riscv64] (groovy-proposed/universe) [3.490-2] (kubuntu)
<teward> vorlon: did yuo ever reject dragonfly-reverb out of NEW?  Because Eickmeyer has an updated one he wants me to upload but it'll conflict with what's in NEW currently (so can an archive admin reject the current dragonfly-reverb in Groovy NEW outright)
<Eickmeyer> ubuntu-archive: ^
#ubuntu-release 2020-08-23
<cjwatson> teward,Eickmeyer: there should be no need for that to block another upload
<cjwatson> (1) you could bump the version (2) even if you didn't, uploads in NEW don't (currently) consume the version number until they're actually accepted
<teward> ah nice
-queuebot:#ubuntu-release- New source: dragonfly-reverb (groovy-proposed/primary) [3.2.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: cfitsio [amd64] (groovy-proposed/universe) [3.490-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: cfitsio [s390x] (groovy-proposed/universe) [3.490-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: cfitsio [ppc64el] (groovy-proposed/universe) [3.490-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: cfitsio [arm64] (groovy-proposed/universe) [3.490-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: cfitsio [armhf] (groovy-proposed/universe) [3.490-3] (kubuntu)
-queuebot:#ubuntu-release- New binary: cfitsio [riscv64] (groovy-proposed/universe) [3.490-3] (kubuntu)
<LocutusOfBorg> vorlon, please https://launchpad.net/ubuntu/+source/libdata-messagepack-perl/1.00-4/+build/19866308
<LocutusOfBorg> not sure if we have to stop building it on i386, or restore msgpack-c there...
<LocutusOfBorg> for sure somebody seems dropping i386 binaries without prior checking if they are still used or not?^
-queuebot:#ubuntu-release- Unapproved: gnome-flashback (focal-proposed/universe) [3.36.3-0ubuntu1 => 3.36.4-0ubuntu1] (edubuntu)
<Eickmeyer> vorlon: Feel free to reject the first upload of dragonfly-reverb in the queue, the second one that teward uploaded should have all of the necessary fixes.
-queuebot:#ubuntu-release- New binary: libplacebo [amd64] (groovy-proposed/universe) [2.72.0-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: ayatana-indicator-sound [amd64] (groovy-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libplacebo [arm64] (groovy-proposed/universe) [2.72.0-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: libplacebo [i386] (groovy-proposed/universe) [2.72.0-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: libplacebo [armhf] (groovy-proposed/universe) [2.72.0-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: libplacebo [s390x] (groovy-proposed/universe) [2.72.0-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: ayatana-indicator-sound [s390x] (groovy-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ayatana-indicator-sound [arm64] (groovy-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ayatana-indicator-sound [armhf] (groovy-proposed/universe) [0.8.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libplacebo [ppc64el] (groovy-proposed/universe) [2.72.0-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: libplacebo [riscv64] (groovy-proposed/universe) [2.72.0-2] (i386-whitelist, kubuntu)
-queuebot:#ubuntu-release- New binary: ayatana-indicator-sound [ppc64el] (groovy-proposed/universe) [0.8.0-1] (no packageset)
