#ubuntu-release 2010-09-13
<ogra> lamont, acorn is down again :/
<ev> I'd greatly appreciate a review on bug 636945
<ubot4> Launchpad bug 636945 in ubiquity-slideshow-ubuntu (Ubuntu) "Freeze exception for ubiquity-slideshow-ubuntu 24 (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/636945
<lamont> ogra: correct.
#ubuntu-release 2010-09-14
<ScottK> slangasek: I'd appreciate it if you took another look at the Mesa FFe.  RAOF thinks he's answered all the questions and is waiting for approval/rejection.
<slangasek> ScottK: "I'll test swrast on my nouveau system" -- he didn't report these results in the bug?
<ScottK> slangasek: I'll ping him. Thanks.
<wgrant> 9
<ogasawara> apw: is bug 635379 similar to the i915 lockups you were seeing?
<ubot4> Launchpad bug 635379 in linux (Ubuntu) "intel i945 GPU lockup, requires reboot to restore X (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/635379
<apw> ogasawara, if i915 is reporting a GPU lockup then no its not, mine is something in the driver losing the dev_mutex
<apw> bug #568138
<ubot4> Launchpad bug 568138 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "[arrandale] deadlock in i915_gem_madvise_ioctl (affects: 11) (dups: 1) (heat: 60)" [Medium,Confirmed] https://launchpad.net/bugs/568138
<ev> If anyone has spare cycles, I'd appreciate a review of bug 637410
<ubot4> Launchpad bug 637410 in ubiquity (Ubuntu) "UI free exception request for ubiquity 2.3.18 (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/637410
<ScottK> slangasek: I'm uploaded mesa.  It will (unfortunately) hit binary New, so I'd appreciate it if you would keep and eye out for it and release it when it does.
<slangasek> ScottK: ack
<ScottK> Thanks.
<slangasek> cjwatson: where does your lintian backport on cocoplum build from?  It seems there's been an apt upgrade
<cjwatson> I'm honestly not sure.  We should probably rebuild it now that cocoplum runs lucid
<cjwatson> I think it's still worth having a modern lintian there
<slangasek> in that not rebuilding it results in it not running, yes :)
<slangasek> oh, looks like current lintian has a lucid-backports, I can probably just unpack that maybe
<nigelb> robbiew: now that's an awesome mail for final freeze :p
<robbiew> heh
<nigelb> exceptions requring confirmation bit is particularly amusing ;)
 * robbiew didn't want to favor one religious deity over another ;)
<robbiew> slangasek: cjwatson: so the more I look at example-content...the more I think it's contents need to be reassessed for value
<cjwatson> that's usually the case, yes :)  maybe next cycle for a full reassessment though?
<robbiew> aye
#ubuntu-release 2010-09-15
<ScottK> slangasek: mesa's in New on all 4 archs now....
<slangasek> ScottK: got it
<ScottK> Thanks.
<slangasek> ScottK: accepted now; sorry, got held up rejecting pacemaker
<ScottK> slangasek: Thanks.
<apw> skaet, when is the freeze going into effect for RC ?
<apw> (and hi!)
<robbiew> apw: FinalFreeze is tomorrow
<apw> robbiew, so at midnight tonight local we freeze ?
<apw> (go into freeze mode)
<robbiew> apw: ah...well, technically yes
<apw> robbiew, ok thats what i needed to know ... thanks
<robbiew> apw: np
<apw> robbiew, fyi people are saying netbook is throwing a white screen and is unusble, over on #ubuntu-devel
<robbiew> apw: I think the latest mesa update broke it
<slangasek> robbiew: broke what?  the freeze?
<robbiew> slangasek: broke clutter
<slangasek> hmm
<slangasek> certainly possible... what hardware do people see this on?
<robbiew> slangasek: I think conversations are being held on #ubuntu-x
<robbiew> slangasek: jump to #ubuntu-x
<slangasek> skaet: I'm puzzled by the ubuntu release notes task on bug #552613 - what's to be release-noted?
<ubot4> Launchpad bug 552613 in xmlbeans (Ubuntu Maverick) (and 4 other projects) "[MIR] xmlbeans (affects: 1) (heat: 10)" [Wishlist,Won't fix] https://launchpad.net/bugs/552613
<skaet> slangasek: noted from bug it should be revisted for Natty, but when asked how to flag it so it doesn't disappear into morass, was advised to flag it to release notes as mechanism to use as workaround.  Intuitively I was hoping for a release class of "future" or "Natty" to tag it against.   Better suggestion?
<skaet> slangsek:  agree that nothing needs to be documented in release notes on this.   Its a kludge.
<slangasek> skaet: huh, who told you to use /that/ as a workaround :P  the release-notes project is used for tracking actual pending issues in the release notes, I would've closed this bug as invalid if I had come across it doing release notes work :)
<slangasek> skaet: I would suggest using the 'later' milestone
<slangasek> which exists for this purpose, though we are perhaps not as diligent as we should be in revisiting such issues after a release
<robbiew> slangasek: I told her to subscribe release notes,  but I assumed it was a bug that we wouldn't be able to address in 10.10...not a Wishlist,Won't fix issue :/
<slangasek> ah, k :)
<skaet> slangasek:  is the 'later' milestone documented somewhere?
<slangasek> skaet: heh, probably not; I look to cjwatson for that precedent
 * skaet wants to check she understands the semantics of when it should be used.   
<skaet> slangasek:  will follow up with cjwatson then when see him next ;)
<lamont> skaet: when we're gonna fix the bug "later"... it comes from warty days, when lots and lots of things were "yeah, yeah... NOT NOW"
<lamont> but never really used like it could/should be, IMO
<skaet> :)
<slangasek> I think "later" is "when I get to the bottom of my todo list, I'll revisit"... 'nuf said
<bjf> i'm having an issue with grub-pc not installing (both a dist-upgrade and now an install from iso) is this a know issue?
<bjf> i'm trying to install to a two disk raid
<bjf> i'm getting "grub-install /dev/sda" failed however I don't believe I have a '/dev/sda'
<bjf> this is with maverick server amd64, today's iso
<doko> good to see all the buildd
<doko> ... buildds blocked by mozilla-security ...
<cjwatson> skaet: I'm not sure it's documented unfortunately.  It exists as a milestone due to LP limitations - ideally we'd just create an empty natty distroseries and start targeting bugs to it, but unfortunately LP gets a bit confused if you try that
<cjwatson> contrary to what lamont said, my memory is that the later milestone was invented in the edgy cycle
<cjwatson> indeed you can tell this from the fact that it's attached to the edgy distroseries (the namespace for milestones within a distribution is flat): https://launchpad.net/ubuntu/edgy/+milestones
<skaet> cjwatson:  thanks.   an empty natty distroseries is what I was hoping for initially as well.
<cjwatson> anyway, the semantics are "should be revisited after release and probably attached to the next series"
<cjwatson> or thus I remember them being anyway
<cjwatson> bjf: not known, could do with a report with full logs
<skaet> yup,  I was looking through that earlier today.    There's alot of cruft in the later queue that should probably be cleared out if we're going to start using it as the "next release"  in a standard fashion though.
<bjf> cjwatson: it's from an iso install, how do I get logs?
<bjf> cjwatson: note, i successfully installed to this same configuration some time ago, am trying an older iso
<cjwatson> bjf: text mode or graphical?
<bjf> cjwatson: it's server, so text mode
<cjwatson> bjf: go back to the main menu and select "save debug logs"
<bjf> cjwatson: ok, am in the middle of an install now, will do if I have the same problem, if I don't I'll go the dist-upgrade route and hit it again
<cjwatson> it could be related to the change in grub2 1.98+20100804-4ubuntu6
<cjwatson> I haven't done a RAID test since then
<bjf> cjwatson: an install using the daily server iso from 09/05/2010 worked
<bjf> cjwatson: that's Sep. 05 :-)
<skaet> cjwatson:  thanks. will use the semantics as the working definition for now.  :)   Have added it to list of topics to revisit a bit after release is out, to get it a little more standardized and integrated into the processes.
<bjf> cjwatson: am happy to try a dist-upgrade, anything special you'd like me to do?
<cjwatson> bjf: a log from the current CD image would probably be better-controlled and easier to read
<cjwatson> with the current CD image, put DEBCONF_DEBUG=developer on the kernel command line
<cjwatson> skaet: *nod*
<nigelb> 26
<bjf> cjwatson: so a new install of the sept. 05 iso with DEBCONF_DEBUG=developer on the kernel command line?
<cjwatson> no, current iso
<cjwatson> unless that's a problem for you
<bjf> cjwatson: no problem, just want to get you what you want
<cjwatson> nigelb: 42
<nigelb> cjwatson: 101010
<bjf> cjwatson: so today's iso it is
<cjwatson> dear archive admins who might think of processing NBS: please don't remove the -21 kernel, we're still using it
<cjwatson> (done the things that can easily be done right now)
 * slangasek acks
<bjf> cjwatson: where will the logs be?
<bjf> cjwatson: am installing now
<cjwatson> bjf: "save debug logs" from the main menu will show them
<bjf> cjwatson: ok
<cjwatson> bjf: or you can switch to tty2, run 'anna-install openssh-client-udeb', then use scp to copy out /var/log/syslog and /var/log/partman
<cjwatson> those are the two I actually need
<lamont> cjwatson: edgy, warty, 'tever... something ending in a 'y' :-)
<lamont> take my comment to be "a long time ago"
<doko> lamont: see bug #630511 :-/
<ubot4> Launchpad bug 630511 in python3.1 (Ubuntu Maverick) (and 2 other projects) "Support for multiprocessing broken in python3.1 (affects: 1) (heat: 8)" [Critical,Triaged] https://launchpad.net/bugs/630511
<lamont> doko: was getting to that one
<doko> I can work around it, but the main problems are the undiscovered things
<lamont> doko: when building for release N, the *^%&*)%)^(^_) package should really not query the underlying kernel to decide what code it should generate.
<doko> lamont: you're dreaming, how do you intent to face reality?
<lamont> given that I have no way to run other than one kernel to build all of the distroarchseries, which one would you prefer me to break?
<bjf> cjwatson: i'm trying to get you the logs, cant switch to vt2 or any vt at this point
<doko> I assume that running the N-1 kernel would make things better. Can we discuss this / start a blueprint about this with the soyuz guys at UDS?
<bjf> cjwatson: am booting from a usb key, is that mounted such that I can write the logs back to it?
<bjf> cjwatson: nevermind, put the files onto another usb disk
#ubuntu-release 2010-09-16
<bjf> cjwatson: i'm going to leave this system in this partially installed state in case you need any other info
<Laney> I didn't know f-spot being demoted to universe was part of the plan.
<lamont> doko: that guarantees at least 6 months of running an unsupported kernel, you realize.. building jaunty today on intrepid's kernel would be such a case
 * lamont will ponder
<doko> lamont: would you care, if you could run it on a virtual buildd?
<bjf> cjwatson: bug 640033
<ubot4> bjf: Bug 640033 on http://launchpad.net/bugs/640033 is private
<doko> lamont: and why not use the distro kernel once a release is released?
<bjf> hmmm, it shouldn't be
<bjf> cjwatson: bug 640033
<ubot4> Launchpad bug 640033 in grub-installer (Ubuntu) "maverick daily server iso (Sept. 15, 2010) fails to install grub on raided drive set (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/640033
<lamont> doko: we already know that several packages do not build in virtual builders
<lamont> anyway, family calling me to dinner
<doko> lamont: -> UDS
<wgrant> Uh, ew.
<wgrant> Ew ew.
<cjwatson> bjf[afk]: you didn't tell me you had dm-raid, rather than proper raid :-)  that's known-broken right now
<bjf> cjwatson: sorry about that :-)
<bjf> cjwatson: when will that be fixed? :-)
<cjwatson> "soon"
<cjwatson> it regressed due to an lvm2 update; reverting that wouldn't be a good plan, so we need to adapt
<bjf> hmm
<robbiew> FYI.../me will be requesting a freeze of the archive VERY soon ;)
<nhandler> Do you guys think we could squeeze in an upload of lernid before the release? It is in universe and not seeded. Changes are also pretty minor.
<cjwatson> universe stuff that isn't on CDs can keep going in for a while yet
<nhandler> Great
<cjwatson> right, apparently bug auto-closing is fixed.  now I guess I get to write a bit of launchpadlib to go and look for all the stuff that wasn't auto-closed ...
<ogra> robbiew, dare you !
<cjwatson> goodness me there have been a lot of uploads in the intervening time, he says as it hasn't got out of the 'a's yet
<cjwatson> wait, no, wrong date
 * ogra wants that armel queue to go on a diet !
<Daviey> How much time do we have before final freeze? :)
<ttx> depends on how hot the coffee can stay in robbiew thermos
 * Daviey will buy robbiew a new kettle if it helps! :)
<robbiew> Daviey: technically it was at midnight UTC today
<ttx> right, we all know whath /that/ means
<Daviey> robbiew, not what i wanna hear! :O
<robbiew> Daviey: would 17:00 UTC work for you?
<Daviey> robbiew, If that isn't causing problems for anyone, then yes, it really, really would
 * Daviey has been fixing a "5 minute" bug, that has been taking hours.
<robbiew> Daviey: okay...17:00 UTC it is
 * robbiew will send an email 
<Daviey> robbiew, Let me know when you want to collect the beer.
<robbiew> heh
<ttx> I thought it was a kettle.
<ogra> with beer ?
 * ogra imagines a big cannibal tribe kettle
<thisfred> ohai
<skaet> robbiew,  17:00 UTC is only for Daviey?  or are others permitted?
<robbiew> lol
<robbiew> others are permitted
<robbiew> the freeze will go into effect at 17.00UTC for all
<skaet> cool.
<robbiew> I mean I like Daviey...but he's not THAT special
<robbiew> :P
<ogra> unless someone else bribes more :)
<Daviey> my mummy said i am special.
<robbiew> and you are....to her
<skaet> lol
<ogra> Daviey, http://image22.webshots.com/23/1/76/80/355917680EWuyhU_fs.jpg
<iulian> Hmm, my mum thinks I'm stupid.
<thisfred> We (canonical online services) have a rather important bugfix for couchdb that we'd still like to get into maverick. Bug #422178
<ubot4> Launchpad bug 422178 in couchdb (Ubuntu) (and 1 other project) "CouchDB needs to properly enable SSL support (affects: 2) (heat: 10)" [Undecided,In progress] https://launchpad.net/bugs/422178
<thisfred> A new package is building on LP with that bugfix
<Daviey> ogra, \o/
<robbiew> thisfred: okay
<robbiew> if you don't make it by 17.00 utc, it can still be considered for the release, but would need review/approval by the release team
<iulian> thisfred: Looking.
<thisfred> awesome, we should be able to make that
<iulian> Have you got a package ready to upload?
<iulian> Ah, it's still building.
<thisfred> iulian: it's building now
<ogra> it really adds more excitement to just upload it without testbuild at 16:58 UTC :)
<thisfred> (The only reason for that is that the bug number wasn't in the changelog yet)
<thisfred> ogra: hopefully we can arrange something like that for natty, unfortunately this time the fix came in too early ;)
<ogra> gah, yeah, your team seems to be not busy enough !
 * ogra makes a note to add a lot of armel specific requests for online services during natty
<thisfred> I'll forward that as a suggestion to my evil overlords
<ogra> heh
<iulian> thisfred: Is chef-server-api affected by this change?  I see that python-couchdb only suggests couchdb so it shouldn't cause any trouble.
<thisfred> iulian: I have not looked at chef-server, but i doubt it, since that uses couchdb as a local datastore it looks like?
<ogasawara> robbiew: I was waiting to upload linux-meta till armel and powerpc finished building (which will be a while).  But I can upload it now if that's preferred, else I can ping the release team for approval after.
<thisfred> iulian: so it should not have run into the original problem
<iulian> thisfred: Alrighty.
<thisfred> iulian: the bug this fixes is that replication from a couchdb on another machine over SSL was broken
<iulian> thisfred: OK, I'm fine with it then.  Approved.
<thisfred> iulian: awesome, thank you!
<iulian> thisfred: Don't mention it.  Please upload it asap.
<thisfred> as soon as it's built, I will get someone to do just that
<iulian> Excellent.
 * cjwatson writes a little launchpadlib program to go through all bugs that were closed since the Launchpad breakage that stopped bug auto-closure, check if the appropriate bug task isn't fix-released, and present him a bug log and the option to close each one
<cjwatson> this won't do my karma any harm
<cjwatson> bug 502871> example of results
<ubot4> Launchpad bug 502871 in alarm-clock (Ubuntu) "Invalid MimeType in desktop file (affects: 1) (heat: 20)" [Undecided,Fix released] https://launchpad.net/bugs/502871
 * ogra hand closed most of his 
<cjwatson> so did I, but it gets tedious and I bet many people didn't
<ogra> yeah
<cjwatson> so I'll clean up after everyone in bulk
<cjwatson> (the reason it has to be interactive is that I need to catch the situation where there's been chat on the bug after the point when the bug ought to have been auto-closed which indicates that the bug needs to stay open)
 * iulian likes robbiew's e-mails. :)
<robbiew> iulian: heh
<robbiew> ogasawara: hmmm....not sure which would be better, tbh.
<ogasawara> robbiew: it might be less work for the release team later if I just upload it now
<robbiew> yeah
<robbiew> ogasawara: go ahead
<robbiew> who cares about armel anyway
<robbiew> (j/k)
<robbiew> but seriously, I agree...upload away
<ogasawara> heh
<ogasawara> ack
<ScottK> robbiew: I like how you avoided using the wrong release name by not using one at all.
<robbiew> :)...I'm learning
<nigelb> ScottK: He's smart, we all agree :D
<thisfred> ok, couchdb is built (though not yet published) which brings me to the next issue: I don't have a sponsor with bandwidth to do the upload for me. Seems like everyone's busy for some reason...
<nigelb> ScottK: Also, now that mail can be reused without changes except date :D
<iulian> thisfred: What about the last uploader?
<thisfred> actually it *is* published now
<thisfred> I think that was statik, he's since ascended...
<ev> anyone mind terribly if I kick off new desktop CDs?  There's a bug in today's that prevents bootloader installation.
<cjwatson> fine by me
<ev> okay, cool, on it now
<thisfred> iulian: yeah, both statik and kenvandine are overloaded with other things atm.. :(
<thisfred> also statik is no longer on our team
<robbiew> thisfred: but he still has the "power" :)
<thisfred> robbiew: he does, but he's off "managing" ;)
<cjwatson> actually, I could do with a new server build too.  I'll kick that off in parallel
<iulian> thisfred: Arghht.  You need a core-dev then.  I don't have upload privileges to main.
<thisfred> iulian: statik is doing it after all
<robbiew> :)
<iulian> thisfred: Excellent.
<iulian> Heh. :)
<robbiew> yeah..."managing" isn't THAT hard
<robbiew> heh
<iulian> Indeed.
<thisfred> just call him a manager to his face, and he'll get mad and do it ;)
<robbiew> t-minus one hour
<cjwatson> ogra: FYI, queuebot should no longer have the bug where it only notices the first version of a package in the queue
<cjwatson> which you reported in the beta cycle
<ogra> ah, sweet
<\sh> robbiew: would you like to make the Maverik +2 Release an "Ubuntu 11.11.11 -> The "Cologne Carnival" Release? ;)
<cjwatson> nooooo
<robbiew> what cjwatson said
<\sh> that's sad...we could have celebrated the release in Cologne starting at 11:11am german time with a lot of KÃ¶lsch ;)
<ogra> \sh, i doubt non germans understand the pun :)
<\sh> ogra: well, yes :)
<cjwatson> I think I must be missing it too
<nigelb> \sh: that needed a little googling
<\sh> the carnival season starts on the 11th of November at 11:11am German Time...and most people in cologne are starting to getting mad, drunk and happy :)
<Daviey> robbiew, You have my permission to freeze the archive :P
<robbiew> Daviey: heh
<skaet> 5 minutes to go....
 * ogra shivers
<\sh> ogra: Don't Panic !
<ogra> well ... i have the feeling io forgot something important all the time
<ogra> i got my towel though
<skaet> lol
<\sh> ogra: your mice ;)
 * ogra hears the chruchbell outside 
 * skaet waiting for Robbie to be official...
<iulian> Heh.
<robbiew> I can feel it coming in the air tonight, Oh Lord
<robbiew> I've been waiting for this moment, all my life, Oh Lord
<robbiew> Can you feel it coming in the air tonight, Oh Lord, Oh Lord
<skaet> hold on?
<robbiew> frozen!
<iulian> Yay!
<\sh> "Shout It Shout It Shout It Out Loud!" ;)
<ogra> no more "putting tongue tip on pole" now :'-( sniff
<kenvandine> yay... now i can go to lunch :)
<ev> Can someone let ubiquity-slideshow-ubuntu 25 through?  I forgot to update the pot files before uploading the freeze-approved version 24.
 * highvoltage wonders if anyone will find the hhgttg easter eggs hidden in edubuntu
<highvoltage> robbiew: btw, did you know that Phil Collins played that to Richard Branson on a tape he recorded while he was still a taxi driver?
<robbiew> highvoltage: no...no I did not
<robbiew> heh
<highvoltage> robbiew: yep, he forced him to listen to it and RB liked it and signed a record deal. that was quite lucky :)
<slangasek> I didn't know Richard Branson was a taxi driver
<highvoltage> no, I meant when Phil Collins was a taxi driver
<slangasek> oh ;)
<robbiew> slangasek: hey...can you tend to poor ev's request about ubiquity-slideshow-ubuntu 25? :)
<sbeattie> Was that before or after Phil Collins was in Genesis?
<highvoltage> my english seems to have gotten even worse among the french canadians :)
<slangasek> robbiew: ooking
<slangasek> robbiew: looking
<robbiew> slangasek: thnx
<skaet> sbeattie,  got to have been before...   no need to taxi drive after Genesis.
<slangasek> in the beginning there was the cab
<highvoltage> sbeattie: I'm not sure, pity they don't mention it on Phil's wiki page, I read about it in Richard Branson's book, "Screw it, let's do it again"
<sbeattie> skaet: right, but "In the Air Tonight" was post-Genesis... /me smells an urban legend, of which there are a few about that song.
<highvoltage> skaet: yeah I believe that was the start of his musical career
<highvoltage> (and sorry for all the noise on the channel :) )
 * skaet suspects urban legand too...
<highvoltage> they don't mention it on http://en.wikipedia.org/wiki/In_the_Air_Tonight ... weird, I wouldn't suspect that they'd lie in the book. I'll have to look it up again and mail the publisher a [citation needed] :)
<slangasek> ev: accepted
<ev> slangasek: I owe you liquor
<ev> thanks
<slangasek> heh :)
<ScottK> No queuebot?
<cjwatson> it's here; I'll have to look at why it isn't picking anything up
<robbiew> whew...thought I forgot to do something again :P
<cjwatson> ScottK: seems to be nothing in the unapproved queue ...
<ScottK> cjwatson: Not at the moment.  I've processed the ones that have arrived.
<ScottK> That and slangasek got one.
<cjwatson> well, I don't see why it wouldn't be working; so I'll check next time I notice that the queue's non-empty
<ScottK> cjwatson: Queue is non-empty.
<doko> ScottK: please approve python3-defaults and python3.1
<cjwatson> ScottK: ah, stale lock.  cleared, should sort itself out soon
<doko> or cjwatson ;)
<slangasek> I can take the python review
<slangasek> yuck, ntfs-3g soname change in NEW?
<cjwatson> pitti gave it an FFe
<slangasek> ok
#ubuntu-release 2010-09-17
<iulian> queuebot is alive!
<cjwatson> excellent
<wgrant> How does queuebot work?
<wgrant> There's no convenient interface.
<wgrant> Unless it runs queue frequently.
<cjwatson> there's a horrible cron job on cocoplum that runs queue frequently and publishes it to http://people.canonical.com/~ubuntu-archive/queue/
<wgrant> aHA.
<cjwatson> I would be more than happy to replace it with API access if it existed ;-)
<cjwatson> (nowadays, it caches the downloaded files from the queue to avoid hammering LP too much)
<wgrant> Yeah... the API is slow, but not as slow as queue.
<cjwatson> publish-queue runs once every two minutes; for some reason queuebot then checks once a minute
<cjwatson> queuebot itself is in lp:ubuntu-archive-tools as ubuntu-release-bot
<wgrant> The API almost exposes enough.
<wgrant> But not quite.
<cjwatson> everything except the password
<wgrant> Can't get the source name out of a PackageUpload.
<cjwatson> if that's ever fixed, let me know and I'd be happy to rewrite queuebot to use it
<Daviey> Hi friendly release team!  I wondered on the possibility of bug 631103 getting a FFe.  The regression potential seems kinda low, the patch was proposed well before FF; but seems he was let down by the sponsoring system.  Screencasts users seem to depend on this feature, which is a regression from Lucid.
<ubot4> Launchpad bug 631103 in ffmpeg (Debian) (and 1 other project) "[patch] maverick ffmpeg "Unknown input format: 'x11grab'" (affects: 6) (heat: 32)" [Unknown,Unknown] https://launchpad.net/bugs/631103
<doko> cjwatson, pitti: May I accept these 'build1' no change uploads?
<cjwatson> doko: yes, go ahead
<iulian> Daviey: Stefan has just approved it.
<Daviey> great!
<doko> cjwatson: looking at component-mismatches:
<doko> libcrypt-des-ede3-perl: libcrypt-des-ede3-perl
<doko>    [Reverse-Build-Depends: libcrypt-cbc-perl]
<doko> libcrypt-des-perl: libcrypt-des-perl
<doko>    [Reverse-Build-Depends: libcrypt-cbc-perl]
<cjwatson> stuff in that section requires an MIR
<doko> libcrypt-rijndael-perl: libcrypt-rijndael-perl
<doko>    [Reverse-Build-Depends: libcrypt-cbc-perl]
<cjwatson> if there's been an MIR, then they can be promoted
<doko> well, asac and I think this is a circular b-d which can be demoted
<cjwatson> uh
<cjwatson> no, germinate wouldn't see if it were purely circular.
<cjwatson> libcrypt-blowfish-perl build-depends on libcrypt-cbc-perl
<doko> libcrypt-cbc-perl b-d on libcrypt-blowfish-perl
<cjwatson> that's not why
<cjwatson> libcrypt-blowfish-perl is in the supported-development-common seed
<doko> the  libcrypt-blowfish-perl  b-d on libcrypt-cbc-perl
<doko> ahh, ok
<cjwatson> without a particularly good reason apparently, so if you think it can be removed, feel free
<cjwatson> :q
<cjwatson> oops
 * cjwatson checks bzr blame quickly
<cjwatson> been there since revision 1, no explanation
<cjwatson> go ahead and unseed it if you like
<doko> ok
<doko> cjwatson: do the current Binary only promotions to main look ok to do?
<cjwatson> anyway, it may be useful to know that it's impossible for promotions to be purely due to circularity; that script doesn't care what's currently in main, but rather it looks at the seeds and decides what should be in main, and then compares
<doko> ok
<cjwatson> kubuntu-mobile may not be workable yet
<cjwatson> the others should be fine
<cjwatson> assuming that they aren't listed as reverse dependencies of something in the top section
<doko> well, linphone-dev is, but the source already is in main
<sistpoty|work> [continue from -meeting]: ah, there: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-April/000701.html
<cjwatson> I suspect Mozilla should be updated since asac is doing Linaro now; the others look OK from my memory
<cjwatson> of course that's "up until FinalFreeze"
<cjwatson> so it's probably kind of moot now
<sistpoty|work> oh, heh, right
<cjwatson> of course this is quite a long final freeze this time round
<cjwatson> so I expect we'll have a lot of exception requests to deal with ...
<sistpoty|work> and we used to have a later date for final freeze in universe than in main for lucid
<cjwatson> oh yes, well, I think in practice that's still the case isn't it?
<cjwatson> we're just unable to freeze the archive separately
<sistpoty|work> I think so, yes
<sistpoty|work> (otoh, I can't really tell, as I can't shove packages through the queue)
<skaet> sistpoty|work, will you be handling the issueing of the delegation note,  or should it come from robbiew at this point?
<robbiew> I'm sure sistpoty|work can handle it
<chrisccoulson> on the subject of freezes and mozilla, cjwatson, what is the chances of me getting a new package in to universe at this stage? (well, resurrecting an old one to be more precise)
<chrisccoulson> bug 531867
<ubot4> Launchpad bug 531867 in iceowl (Debian) (and 1 other project) "[FFe] [needs-packaging] Lightning 1.0 Beta for Thunderbird 3 (affects: 95) (dups: 5) (heat: 357)" [Unknown,Unknown] https://launchpad.net/bugs/531867
<skaet> robbiew, agree.   just making sure I understand where it should be coming from.
<cjwatson> chrisccoulson: it'll depend on whether somebody has time to review it; it won't be the most urgent thing on anyone's list, I think
<sistpoty|work> skaet, robbiew: can do... maybe we should also define a date for final freeze for universe? how about 4th october?
<robbiew> sistpoty|work: have we done that in the past...I can't remember
<sistpoty|work> robbiew: yes
<robbiew> I think the 4th is a good date then
<sistpoty|work> robbiew: https://lists.ubuntu.com/archives/ubuntu-release/2010-April/000044.html
<robbiew> week from release
<ScottK> sistpoty|work: I think it can be later than that.
<sistpoty|work> ScottK: what do you suggest?
<ScottK> sistpoty|work and robbiew: I'd check with slangasek to be sure, but I think that we can go up to ~36 hours before release.
<ScottK> Err.
<ScottK> Let me step back.
<ScottK> That should be the deadline for no more uploads at all.
<cjwatson> grr, wubi regression
<ScottK> I think final freeze two days before that is sufficient.
<cjwatson> that would be my fault then :-/
<sistpoty|work> ScottK: that would be october 6 or 7?
<robbiew> let's do the 6th then
<ScottK> robbiew: Noon UTC on the 6th?
<robbiew> sounds good to me
<robbiew> ScottK: can you shoot an email to u-d-a announcing that?
<ScottK> Final, final upload deadline for unseeded uploads is Noon UTC on the 9th.
<ScottK> Yes.
<ScottK> robbiew: I'd like to hear fro slangasek first to make sure he thinks that's sane.
<skaet> robbiew,  I'll go make the the necessary changes to the release checklists to reflect this for future.
<robbiew> ScottK: sure...sounds reasonable
<robbiew> as I'm not sure how much us releasing on a Sunday vs Thursday would affect things
<ScottK> For unseeded packages I think it doesn't.  It's just tie for mirror sync.
<ScottK> tie/time
<ScottK> skaet: We are still in a bit of a learning process on when unseeded packages need to freeze.  It used to be that security uploads were managed outside soyuz and it took three days to do that, so that was the driver for cutting off uploads.  Now it's just time for mirror sync and I think 24 hours is sufficient for that.
<ScottK> So I suggested setting the final package upload deadline at 36 hours prior to the start of release day to give us 12 hours to fix any last minute OMGWTFBBQ type problems.
 * ScottK pokes at slangasek some more.
<skaet> ScottK, sounds good.   Will add that, unless slangasek has new input.
<astraljava> Q: Our project lead seems to be unavailable for release delegate meet about to happen on #u-devel, is it possible for me to fill in temporarily?
<ScottK> astraljava: What project?
<astraljava> ScottK: Ubuntu Studio.
<ScottK> Sure
<ScottK> sistpoty|work: ^^^
<astraljava> ScottK: Thanks :)
<slangasek> ScottK, skaet: sounds sane to me
<ScottK> skaet and robbiew^^^
<slangasek> ScottK: fwiw, I think part of the reason for freezing with some lead time is to give us some slack in the event of buildd problems in that window
<sistpoty|work> astraljava: ScottL just pinged me on -devel
<robbiew> ScottK: ack
<astraljava> sistpoty|work: Ok good, scratch that. :)
<sistpoty|work> :)
<slangasek> 36-hour cutoff gives us a full day to find and fix any buildd issues that would otherwise cause the just-uploaded source package to not have matching binaries in the release
<skaet> slangasek, ScottK:  fair enough.   thanks.
<ScottK> Point of clarification: Does this apply just to unseeded Universe/Multiverse packages or to any package that doesn't appear on an ISO?
<ScottK> There are Main packages that also aren't on an ISO?
<sistpoty|work> we used to keep main separate for lucid
<ScottK> slangasek: ^^^ thoughts?
<ScottK> Right, but I'm not sure we need to.
<ScottK> It's the fact that packages are on an ISO that drives the earlier deadline not that they are in Main.
<cjwatson> this is true, though I wonder whether it's worth the extra effort of deciding
<ScottK> I consider it as something to think about as we evolve towards the archive reorg plan.
<ScottK> Any time we say "Main" or "Universe" we ought to be thinking about if we really should be or not.
<slangasek> ScottK: I think that's the release manager's call... I always went with "unseeded universe/multiverse" intentionally, rationale being that any package in main, on an ISO or not, has a greater risk of breaking the build for something that *is* on an ISO, and all has to be buildable at release-time so that it gets security support
<ScottK> slangasek: OK.  That makes sense.
<ScottK> skaet: ^^^
<robbiew> I like this approach
<robbiew> going with "unseeded universe/multiverse"
<skaet> I'll defer to those with experience ;)
<skaet> sounds reasonable to me as well though.
<robbiew> ok, so as "Acting Release Manager" I would like to go with "unseeded universe/multiverse", because I'm always scared about breaking the ISO :)
<skaet> lol
<robbiew> ...but I'm not scared to do re-spins the day of release :P
 * skaet rolls her eyes, and looks forward to london.
<ScottK> OK.  Drafting it up.
<doko> cjwatson, ScottK: may I have permission for an OOo upload this weekend (and accept it), build is done on i386, but I'd like for the armel test build to finish before I upload
 * ScottK defers to cjwatson.
<cjwatson> we're far enough out that OOo isn't much of a problem, but it would still be better if upload/accept were by different people
<cjwatson> speaking of which, I'd appreciate somebody reviewing my initramfs-tools upload :-)  that fixes at least part of what's wrong with Wubi right now
<doko> ok, I'll try to ping somebody
<cjwatson> I'll be around at some point over the weekend I'm sure
<doko> is the php5/netcat component mismatch a bug in the tool?
<cjwatson> why would it be?  php5 Build-Depends: netcat
<doko> and netcat-openbsd is in main, providing netcat
<cjwatson> ah, well, real packages usually win
<cjwatson> easiest fix would be to have php5 Build-Depends: netcat-openbsd | netcat, indicating a preferred alternative
<doko> we patch it anyway, so I'll change that
<doko> $ queue diff initramfs-tools|less
<doko> Initialising connection to queue new
<doko> Running: "diff initramfs-tools"
<doko> Unknown Action: diff
<doko> Aborting current transaction
<cjwatson> lp:ubuntu-archive-tools ./queuediff -s maverick initramfs-tool
<cjwatson> +s
<ScottK> robbiew: Sent.  So it should be in the moderation queue.
<doko> o python3-stdlib-extensions: python3-gdbm python3-gdbm-dbg python3-tk python3-tk-dbg
<doko>    [Reverse-Depends: Rescued from python3-stdlib-extensions, idle3, python3-gdbm-dbg]
<doko> cjwatson: ^^^ ok to promote with source? python3 versions
<cjwatson> doko: I think those are fine since they're just python3 versions of stuff already in main for python2
<doko> ok
<doko> cjwatson:  initramfs-tools, the change ignores errors, so it shouldn't have sid effects
<cjwatson> sid effects?
<cjwatson> oh, side-effects, right
<cjwatson> yeah, -f was just in case some initramfs hook had already put /etc/mtab in there
<doko> oops, sid effects =)
<sistpoty> ok, I mailed everyone from the list of delegates where I don't have an ok yet :)
<skaet> sistpoty, Thanks.  :)
<sistpoty> yw
<slangasek> ScottK: could I bother you to review that binutils upload for me?  Needed to let u-boot-linaro build with ~ in the upstream version number...
 * slangasek takes a couple others for review
<ScottK> Looking.
<doko> plus vorbis-tools ...
<ScottK> slangasek: Accepted.
<slangasek> ScottK: ta
<ScottK> doko: Yours too.
<ScottK> You're welcome.
<sistpoty> robbiew, skaet: btw, why aren't you a member of ubuntu-release?
<robbiew> well...I'm only acting :)...don't want folks getting any ideas
<robbiew> heh
<sistpoty> pfft :P
<robbiew> as for skaet...makes sense for her, but she needs to be an official Ubuntu member 1st ;)
<robbiew> i'm sure she'll get there VERY soon :P
<sistpoty> heh, ok... just would like to get reality reflected in launchpad *g*
<skaet> heh
<robbiew> sistpoty: feel free to add me (if you have the rights)...I won't mind ;)
<sistpoty> robbiew: I fear you'll have to ask cjwatson for that (he's admin) ;)
<robbiew> sistpoty: heh...I'm thinking I can get him to approve me :P
<sistpoty> heh
<cjwatson> "Colin, hate to tell you this, but you're fired.  Unless ..."
<sistpoty> haha
<robbiew> lol
<sistpoty> so nice, that I'm from the community and can include *that* quote when sending the announcement about delegates: "robbiew: ...but I'm not scared to do re-spins the day of release :P"
<cjwatson> so, I don't mind adding you for the duration you're acting; anyone mind?
<robbiew> puhleeese...the last thing I'd do is threaten to fire cjwatson if he didn't give me MORE work/responsibility
<cjwatson> hope you're scared to do respins the day of THIS release
<cjwatson> given that nobody will be around ;-)
<sistpoty> haha
<robbiew> heh...well, technically all we have to do is switch the website on sunday
<robbiew> we can have it ready before then ;)
<slangasek> ready and published? :)
<cjwatson> mm, except for the way that's way more than just a single command ;-)
<cjwatson> I suppose we could have it ready to run sync-mirrors
<cjwatson> that might not be a hideously bad idea
<robbiew> yeah...that's what I meant
<cjwatson> we'd be committed at that point though
<robbiew> have the ISOs done by Saturday
<robbiew> hell..we could "release" Sunday at 00:00 UTC :)
<robbiew> or 00:10:10 UTC for the fun of it
<slangasek> nothing like trusting your release publishing to an at job
<robbiew> who went with this stupid 10.10.10 sunday thing anyway
<robbiew> lol
<cjwatson> robbiew: added
<robbiew> damn it...now I don't have an excuse to ignore doko's FFes
<robbiew> :P
<sistpoty> robbiew: that's your task list now: https://bugs.launchpad.net/~ubuntu-release/+subscribedbugs :P
 * robbiew creates skaet's ubuntu membership page now
<robbiew> (j/k)
<sistpoty> haha
<doko> sistpoty: how can you add to this list?
<sistpoty> doko: subscribe ubuntu-release
<sistpoty> doko: or did you mean ubuntu-release members?
<sistpoty> (if the latter, I can't)
<ogasawara> per bug 641618, can I get an archive admin to approve the linux package ^^
<ubot4> Launchpad bug 641618 in linux (Ubuntu Maverick) (and 1 other project) "Maverick Kernel Freeze Exception (affects: 1) (heat: 10)" [High,Confirmed] https://launchpad.net/bugs/641618
<doko> new kernel? hey, there wasn't even a new compiler upload ...
#ubuntu-release 2010-09-18
<doko> please accept gcc-snapshot too, has time to build over the weekend, and builds on armel now
<doko> please accept openmsx coq sunpinyin, fixing build failures on armel
<ScottK> doko: Done.
<ogasawara> per bug 641618, can I get an archive admin to approve the linux package
<ubot4> Launchpad bug 641618 in linux (Ubuntu Maverick) (and 1 other project) "Maverick Kernel Freeze Exception (affects: 1) (heat: 10)" [High,Confirmed] https://launchpad.net/bugs/641618
#ubuntu-release 2010-09-19
<ScottK> lamont: It looks like https://launchpad.net/ubuntu/+source/gworldclock/1.4.4-9ubuntu1/+build/1961565 could stand to be shot in the head.
<ScottK> That's likely all I'll have time for for a while.  Someone else's turn.
<doko> cjwatson: ^^^
<ScottK> cjwatson or slangasek: If you are around - I asked Riddell to review the (now updated) kubuntu-meta upload and respin kubuntu-mobile after it's in.  He doesn't seem to be around, so I'd appreciate it if one of you could do that.
<slangasek> ScottK: looking
<ScottK> I just reuploaded it with some more changes so it may not actually be in the queue just yet.
<slangasek> ok
<ScottK> Weird.  It should have shown up by now.
<doko> ScottK: did you find out, why libmedc-dev is not installable?
<ScottK> doko: I did.  It's conflicting hdf5 variants.  I need to run right now.  I can give you details in about an hour.
<doko> slangasek: please could you approve the OOo upload? checked i386 and armel test builds. that it can start building on armel ...
<ScottK> slangasek: Riddell snuck in and took care of it.
<ScottK> Thanks though.
<ScottK> doko: libfvwm build-deps on libhdf5-serial-dev and libmedc-dev.  libmedc-dev depends on libmedc1 which depends on libhdf5-openmpi-1.8.4 which conflicts with libhdf5-serial-1.8.4.
<ScottK> I'm sure there's a better way to solve that one, but I don't feel I know enough about hdf5 to try and sort out the details.
#ubuntu-release 2011-09-12
<cjwatson> Respinning Ubuntu alternate, Ubuntu server, Kubuntu alternate, and Edubuntu DVD due to out-of-sync kernel versions
<cjwatson> (I shouldn't have bothered respinning Edubuntu DVD.  Never mind.)
<cjwatson> ignore those last CD build failures; still working on Chinese image code :-/
<jdstrand> ScottK: hey, is it ok to sync mantis for 3 security fixes? (bug #848124)
<ScottK> jdstrand: Sure.
<jdstrand> ScottK: thanks!
<Laney> syncs which introduce new (udeb) packages: FFe or no?
<cjwatson> what udebs?
<Laney> matchbox-window-manager-udeb
<cjwatson> fine as long as it stays in universe
<Laney> aye aye
<cjwatson> (Ubuntu d-i will ignore udebs in universe)
<cjwatson> guess I should process that sync request
<Laney> will close the ftbfs
<cjwatson> except it looks wrong.  it claims lots of stuff was applied in Debian when it wasn't
 * cjwatson follows up to the bug
<Laney> should be mergable
<cjwatson> or maybe the changes can be discarded because they were from the early days of the Ubuntu mobile project and I suspect they aren't using matchbox any more; but I'd like to see an explicit decision there rather than pretending it doesn't exist :)
<Laney> this is definitely an exercise in how to find unmaintained packages
<cjwatson> mm, though it's not the case that everything on that list is long-term unmaintained
#ubuntu-release 2011-09-13
<ogra_> cjwatson, hmm, i'm lost in debian-cd ... seemingly the environment doesnt get reset if i run cron.daily-preinstalled ... CONF.sh sets PREINSTALLED_IMAGE_FILESYSTEM to ext3 ... later build_all.sh sets it to rootf.tar.gz if there is an ac100 build, seems that var never gets reset if subsequent subarches are built, any suggestion where i can reset it reliably in that loop ?
<cjwatson> ugh, nasty!
<ogra_> yes
<cjwatson> definitely don't pull stunts like that in build_all.sh
<ogra_> hmm, where else could i change it
<cjwatson> you only use the value in one make target; just decide its value there instead
<ogra_> in the Makefile you mean ?
<cjwatson> yes
<ogra_> hmm, k
<cjwatson> I'm also fairly unconvinced about the existence of a variable which can take values "ext3" and "rootfs.tar.gz", but ...
<ogra_> well, its the same image type (preinstalled), the implementation just varies based on HW capabilities
<ogra_> we somehow need to represent that
<cjwatson> sure, what I mean is that "ext3" and "rootfs.tar.gz" hardly seem to be of the same conceptual type
<ogra_> (and it didnt really feel right to add a subarch check to Makefile)
<cjwatson> I would add a subarch check to Makefile if I were you
<ogra_> they are both preinstalled
<ogra_> but ext3 ends up in a two partition image while the tarball is a two file image
<ogra_> enforced by the fact that we are targeting an anrdoid device where you need to flash the kernel/bootimg first
<cjwatson> I don't want to have a long debate about it, it just feels weird
<ogra_> well, i could have invented a completely new image type but we use the same process for both of them
<ogra_> i will revisit that in P (and also try to get all that env variable crap a bit cleaner into a config file so you dont need to chack code for it)
<ogra_> *hack
 * ogra_ tries another mx5 build with the changes applied
<ogra_> grrr
 * ogra_ hates the fact that shell in Makefiles effectively turns into perl and scatters some semicolons over the place
<janimo> Can someone please promote the u-boot-linaro-mx53loco binary to main? It's source is already there
<infinity> janimo: I can do it.
<janimo> infinity, thanks
<ogra_> cjwatson, hmm, exporting in Makefile did definitely not work
<cjwatson> ogra_: diff please
<ogra_> http://paste.ubuntu.com/688412/
<ogra_> results in:
<ogra_> + [ ac100 = ac100 ]
<ogra_> + export PREINSTALLED_IMAGE_FILESYSTEM=rootfs.tar.gz
<ogra_> + export CDIMAGE_COMPRESS=
<ogra_> + [ ! -e /srv/cdimage.ubuntu.com/scratch/ubuntu/daily-preinstalled/preinstalled/armel+ac100.ext3 ]
<ogra_> + echo No filesystem for armel+ac100!
<ogra_> No filesystem for armel+ac100!
<ogra_> (the ext3 in the check uses PREINSTALLED_IMAGE_FILESYSTEM for the suffix)
<cjwatson> you handle CDIMAGE_COMPRESS in build_all.sh so you still have to set it there
<ogra_> exporting doesnt get handed over ?
<cjwatson> not to the parent process!
<ogra_> well, it fails on the wrong file suffix though, i could even use the compressing code and not gzip in live-build
<cjwatson> export means that the environment variable is passed on to child processes
<cjwatson> there is no way in Unix to non-consensually modify the environment of a parent process
<ogra_> but i need it to recognize the tarball
<cjwatson> stop.  wait.
 * ogra_ waits
<cjwatson> the problem is that $(PREINSTALLED_IMAGE_FILESYSTEM) is a *make* variable not a shell variable
<ogra_> so i dont export but just set it ?
<cjwatson> you could use $$PREINSTALLED_IMAGE_FILESYSTEM instead and that would avoid the problem, but I think this would be clearer:
<cjwatson> http://paste.ubuntu.com/688417/
<cjwatson> export/set> not the point
<cjwatson> although it is true that you do not need to export it because it isn't needed in child processes; but the point was that you were referring to the variable using the syntax from the wrong language :-)
<ogra_> ah, cool, now i get it
<ogra_> yeah, mixed language is a pain (see above i *always* forget the semicolons)
<cjwatson> that's why I think my version is clearer, because you're doing more in make and less in shell
<cjwatson> and don't have to worry about whether you're exporting the variable in the same subshell as where it's referenced
<ogra_> yeah, applied that way and running a testbuild already
<ogra_> though i find it a bit sad that i have subarch special casing in two places now :)
<ogra_> yay, looks good, its downloading the tarball
<hggdh> cjwatson: can you please have a peek on bug 849172? Then please tell me what else you might need
<cjwatson> hggdh: already fixed
<cjwatson> dudped
<cjwatson> *duped
<hggdh> cjwatson: you, sir, are my hero :-)
<cjwatson> mvo did half of it
<hggdh> mvo: you are also my hero
<cjwatson> eglibc fix just uploaded, so that'll take a while to build
 * hggdh is quite free with hero assignments
<skaet> cjwatson, infinity -  would like to do some manual test image builds on antimony this afternoon.   Any concerns?
<cjwatson> skaet: no.  DEBUG=1 will cause it not to publish anything and to dump all the output to your terminal.  CDIMAGE_NOPUBLISH=1 will simply cause it not to publish anything.
<skaet> cjwatson,  thanks.
<lamont> skaet: cjwatson: about to cut syncproxy over, btw
<skaet> lamont,  approx. timing?
<lamont> approximately 20 seconds from now
<lamont> or 2 seconds ago, either way
<skaet> heh
<infinity> Yay new syncproxy!
<mvo> hggdh: I always wanted to be a hero (and a lumberjack too) \o/
<hggdh> mvo: there you go, my pleasure. And, BTW, thank you :-)
<mvo> yw!
<micahg> mvo is a hero for uploading the fix for the weird apt bug that was breaking alternate build dependencies more so than normal
<hggdh> micahg: indeed :-)
#ubuntu-release 2011-09-14
<paultag> Hey release-ers. I was working with someone in Debian, and he requested a FFe (LP: #849167) which closes RC bug LP: #820983. It's a bugfix only upload, but it requires dropping the ubuntu1 patch (which failed to fix what it was intended to fix). Can someone triage, please?
<ScottK> If it's bugfix, it doens't need release team review.
<paultag> ScottK: Is there any chance you could fill me in on some of the process? I was just helping a friend, and I don't really know how to handle the paperwork
<ScottK> Subscribe ubuntu-sponsors to the bug and someone will review.
<paultag> ScottK: cheers
<Laney> we ask for FFe for dh_python2 transitions, but what about others? (CDBS â dh in this case)
<pitti> Laney: I guess it could be argued that they need an FFE, but personally I don't care much
<pitti> it's a matter of debdiffing the binaries to check the result
<maxb> Would someone be able to tell me what is unusual about ubuntu/pool/universe/libc/libcdio/libiso9660-7_0.81-4_amd64.deb ?  It appears to be a 404 on archive.ubuntu.com, a 403 on gb.archive.ubuntu.com, but accessible on de.archive.ubuntu.com
<Laney> pitti: thought as much, ta
<cjwatson> maxb: the only unusual thing I can see is that it's a symlink into main
<maxb> Hmm... so that would explain the 403 if gb.a.u.c is configured with a http server that won't follow symlinks
<maxb> It's a 404 on archive.ubuntu.com even changing universe to main
<jpds> Last sync failed.
<jpds> maxb: OK now?
<maxb> Yes, that works - thanks
<jussi> Anyone know when skaet usully arises from her slumbers?
<nigelb> jussi: Somewhere around when Texas wakes up :)
<ScottK> Laney: I think build system changes are feature changes that should be reviewed, but OTOH if someone forgets to ask, I'm not going to go hunt them down unless they break something.
<davmor2> jussi: I'm gonna say approximate 14:00-ish gmt
<jussi> davmor2: excellent, thank you
<davmor2> jussi: most of the states are online between 14:00-16:00 so somewhere around then at any rate :)
<jussi> ok
<ScottK> I guess I should go back to bed then.
<slangasek> I definitely should
<davmor2> ScottK: you slangasek and persia ar eall androids so use UTC I'm sure of it :D
<davmor2> see ^
<ScottK> Sleep is for the weak.
<davmor2> sleep is something you do when you die right?
<ScottK> There's even a song about that.
<davmor2> ScottK: there are several with the line in :)
<davmor2> so it must be true the song said so
<ScottK> No doubt, but it's the title of a Frank Zappa song.
<ogra_> \o/
<davmor2> ScottK: Indeed,  and also sung by Meatloaf, bon jovi, guns'n'roses, some bond theme has it I'm sure oh and others
<nigelb> I'm glad I'm not the only person awake all night.
<davmor2> nigelb: you're a rank amateur at it ;)
<nigelb> I'm not sure if I wwant to be pro :P
<lamont> slangasek: cjwatson skaet (anyone)... any armel livecd images planned in the next hour or 2? I need to do some work on annonaceae
<slangasek> speaking only for myself and the crontab, no
<lamont> slangasek: ta
<cjwatson> me neither
<lamont> buildd's ssh auth keys file is currently disabled, fwiw
<cjwatson> would like the x86 ones to keep working though
<lamont> purely an armel activity
<lamont> total of 5 arm boxes are getting better disks, and I need to migrate things, starting with 4 of the lp-buildds
<lamont> *aceae.buildd
<lamont> (for many, but not all, values of "*")
<ogra_> lamont, well, i was just fiddling with mx5 images but i will wait for infinity anyway
<ogra_> and worst case i can switch to sycamore for the moment
<lamont> ogra_: once the rsync finishes, it's a couple commands and a reboot
<ogra_> yeah, no hurry, i'm stuck anyway
<ogra_> (somehow mx5 is convinced it builds a DVD and not a preinstalled image and i cant find out why)
<lamont> lucky you
<ogra_> heh, yeah
<lamont> in a different question, wtf does the lucid arm redboot world think that fsck can be omitted from the initramfs?
<ogra_> muight be cjwatson's fault though i think there was something about the usb key stuff he fixed last night ... and that i end up with 1.6G ext3 files from live-build is suspicious
<ogra_> lamont, how do you mean ?
<lamont> gonna need some bigger CDs
<ogra_> redboot doesnt do anything with the initrd but loading it
<lamont> ogra_: buildd reboots with errors on /dev/sda1, fails to boot, because fsck.ext2 is missing
<ogra_> everything else is kernel
<lamont> seems to be localized to the bbg3 machines
<ogra_> uh, oh
<lamont> ergo "armel redboot world"
<ogra_> yeah
<lamont> but yeah, absolutely nothing to do with redboot itself
<ogra_> i thought you mean redboot does anything with the initrd it shouldnt
<lamont> it unpacks it.  that's not nothing. :p
<ogra_> shouldnt mountall pull that into the initrd ?
<ogra_> fsck i mean
<lamont> one would expect something to.  I'll check into lucid's mountall
<lamont> zcat < /boot/initrd.img-2.6.35-24-omap | cpio -t | grep fsck
<lamont> 24033 blocks
<lamont> iz fact on bbg3 boards and beaglexm
<ogra_> wow
<cjwatson> ogra_: mountall is not run from the initrd
<ogra_> i thought mountall is what ships the fsck parts into initrd
<cjwatson> no, nothing does
<ogra_> oh
<cjwatson> there is a wishlist somewhere for making the initramfs generally more useful for recovery which would include fsck
<cjwatson> but it's a feature
<cjwatson> mountall runs from the real system not the initramfs
<cjwatson> bug 512349
<ubot4> Launchpad bug 512349 in baltix (and 2 other projects) "include filesystem repair facilities in initramfs (affects: 3) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/512349
<ogra_> ah, k
<lamont> cjwatson: it's a personally annoying feature when you have to have someone physically in the data center to reboot the machine
<ogra_> lamont, what are the exact fs errors you see ?
<lamont> /sbin/fsck.ext2 /dev/sda1
<lamont> e2fsck 1.41.11 (14-Mar-2010)
<lamont> ext2fs_check_if_mount: Can't check if filesystem is mounted due to missing mtab file while determining whether /dev/sda1 is mounted.
<lamont> /dev/sda1 contains a file system with errors, check forced.
<lamont> and no actual errors
<lamont> during the run
<lamont> anyway, buttercup and kaylaberry are back in the game now that I've fscked them
<ogra_> hmm, sad, i was hoping for RTC relations
<cjwatson> normally the initramfs can still do a read-only mount and the lack of fsck should not block it
<cjwatson> perhaps there's a 'rw' argument telling it not to do that?
<ogra_> hmm, could be that there is no ro on the cmdline
<ogra_> but that should still default to ro, no ?
<cjwatson> yes
<cjwatson> though I haven't checked lucid, only oneiric
<lamont> having a machine that refuses to boot until someone manually gets fsck into the initramfs and runs it strikes me as something closer to a bug than a feature
<ogra_> we surely never set rw explicitly
<ogra_> lamont, whats your cmdline ?
<lamont> console=ttymxc0,115200n root=UUID=ff4d3b1f-c1f2-4a63-859c-71395c87e61c
<ogra_> looks fine
<ogra_> not that then
<cjwatson> lamont: point is that the absence of fsck from the initramfs should not cause that bug
<lamont> maybe I'll see if I can reproduce it on the home-panda
<cjwatson> fsck is not meant to be required in the initramfs for booting
<cjwatson> oh, *finally*, a working zh_CN livefs build
<cjwatson> only about ten attempts later
<cjwatson> now I can see what the output looks line
<cjwatson> *like
<ogra_> GRRR ... why is *every* armel package on the ftbfs list i look at a GL issue
<ScottK> ogra_: I see a lot of /usr/include/GL/glext.h:5072:19: error: conflicting declaration 'typedef ptrdiff_t GLintptr' - Is that what you're hitting?
<cjwatson> that's standard GL vs. GLES, AIUI
<ogra_> ScottK, yes, i saw that in several packages
<ogra_> right
<ScottK> /usr/include/GL/glew.h has the same typedef.
<ogra_> but often needs more than just changes of the build dep sadly
<ScottK> I have no frickng clue why there's anything armel specific in there.
<ogra_> GLES vs GL
<ScottK> Hmmm.  Is mesa-common-dev GLES on armel?
<ogra_> not armel specific ... GPU specific :)
<ScottK> I see.
<ogra_> there is a specific gles lib iirc
<ScottK> Yes.
<ScottK> In the case I'm looking at it's not installed.
<ScottK> Oh, wait.  It is.
<ogra_> well, usually you need to change the build-dep, change configure to use GLES if possible and then clean up the fallout for missing or different declarations
<cjwatson> it'd be helpful if https://wiki.ubuntu.com/ARM/FTBFS discussed this for more than the Qt case
<mvo> pitti: I have a merge proposal for a update-manager httplib2 change, but it would add python-httplib2 to update-manager-cores and via that to ubuntu-standard - is that something acceptable at this point? the caching is greatly improved with that branch but its not OMG critical
<pitti> mvo: that sounds like it would restructure some code from e. g. urllib to python-httplib2?
<pitti> mvo: as for the dependency, that's mainly a question for the server guys (Daviey)
<mvo> pitti: yeah, the code itself is fine, I'm mostly concerned about the new dependency at this point, I will eventually merge it for P, I'm pretty certain about that
<micahg> pitti: you should've rejected my dh_python2 conversions due to the extraneous X-Python-Version field since there was no minimum specified before :)
 * micahg just got yelled at in #debian-python...
 * micahg guesses that goes beyond the call of duty for the release team review though
<ScottK> micahg: They are not required, but they don't actually hurt beyond making the source very slightly larger.
<micahg> ScottK: that was the impression I had, but #debian-python said otherwise
<lamont> cjwatson: for tracking, where should I file the (lucid/maverick at least) bug about needing ext2 for boot?  (note that the machines in question were not installed via the normal install processes, so it's likely pebcak)
<lamont> s/ext2/fsck/
<ScottK> micahg: I saw.  I'm not quite as pedantic as some other people.
<cjwatson> lamont: not sure, I guess initramfs-tools for starters
<lamont> ok
 * ogra_ wonders if febootstrap is what he suspects
<charlie-tca> Can we try a respin of Xubuntu Alternate images. There are no errors in the log, but the install fails and there was an email notiification for a fail
<cjwatson> what did the notification say?
<cjwatson> ah, well, if nothing else report.html is non-empty
<pitti> micahg: sorry, missed that
<charlie-tca> xubuntu/daily: Uninstallable packages:
<cjwatson> has abiword installability been fixed then?
<charlie-tca> abiword 2.8.6-0.3ubuntu2 produces uninstallable binaries:
<charlie-tca>   * abiword (amd64 i386)
<charlie-tca>   * abiword-plugin-grammar (amd64 i386)
<charlie-tca>   * abiword-plugin-mathview (amd64 i386)
<charlie-tca>   * libabiword-2.8 (amd64 i386)
<charlie-tca> xubuntu-meta 2.137 produces uninstallable binaries:
<cjwatson> (http://cdimage.ubuntu.com/xubuntu/daily/current/report.html)
<charlie-tca>   * xubuntu-desktop (amd64 i386)
 * cjwatson checks in chdist to see if that's actually been fixed
<charlie-tca> yes, that is the notification
<micahg> pitti: well, according to ScottK it's YMMV, so not your fault
<charlie-tca> Why doesn't http://people.canonical.com/~ubuntu-archive/cd-build-logs/xubuntu/oneiric/daily-20110914.log show anything?
<micahg> cjwatson: it installed fine on my ubuntu-desktop oneiric setup
<cjwatson> because it's not a CD *build* failure
<micahg> *abiword
<cjwatson> the images built successfully, they just contain uninstallable pieces
<cjwatson> it's often useful to have the output anyway
<charlie-tca> So, file a bug with the logs?
<cjwatson> no
<cjwatson> micahg: agreed, it seems fine in chdist
<cjwatson> I'll respin now
<charlie-tca> Thank you
<micahg> cjwatson: thansk
<micahg> *thanks
<lamont> slangasek: cjwatson skaet (anyone)... annonaceae is back over to all y'all, fwiw
<slangasek> thanks :)
<lamont> mucking about with archive/i386 - manualized
<lamont> should be back in a couple min
<lamont> and we're back
<charlie-tca> I need yet another respin. Something is wrong with the mirrors or server because it refuses to allow abiword to work.
<charlie-tca> Please respin Xubuntu Alternates again
<Laney> phwoar, nbs looks good
<Laney> nice
<cjwatson> charlie-tca: it's not clear that respinning will help, then
<cjwatson> I don't want to respin if nobody understands the problem
<charlie-tca> cjwatson: okay
<charlie-tca> bug 850172 for Xubuntu failing to install
<ubot4> Launchpad bug 850172 in debian-installer (Ubuntu) "Xubuntu Oneiric Alternate images fail to find abiword dependencies when building images (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/850172
<charlie-tca> failure on two different hardware systems
<cjwatson> hm, no local copy of xubuntu-oneiric-alternate-i386.iso
<cjwatson> UNLEASH THE JIGDO
<hyperair> hi. is it feasible to sync a libgpod 0.8.2 from debian at this point?
<cyphermox> hi, could someone please ack https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/849994 ?
<ubot4> Launchpad bug 849994 in network-manager (Ubuntu) "FFE: add NetworkManager DUID support (affects: 1) (heat: 8)" [Undecided,New]
 * cjwatson goes to see if he can decipher the Xubuntu failure before falling asleep
<charlie-tca> thank you very much, but sleep might be more important
<cjwatson> I have fairly frequent insomnia, it may be important but it's not always an option :-/
<cjwatson> might as well do something useful with it
<charlie-tca> Then again I will say "Thank you very much". Your help is very much appreciated.
#ubuntu-release 2011-09-15
<cjwatson> Link from /srv/cdimage.ubuntu.com/ftp-universe/pool/universe/w/wv/libwv-1.2-3_1.2.4-2ubuntu3_i386.deb to /srv/cdimage.ubuntu.com/scratch/xubuntu/daily/tmp/oneiric-i386/CD1/pool/universe/w/wv/libwv-1.2-3_1.2.4-2ubuntu3_i386.deb failed: No such file or directory
<cjwatson> hmm
<cjwatson> that source file exists on disk with a newer change time; I don't understand this but I suppose it's possible that a respin will in fact fix it
<cjwatson> true of all the missing files (there are three; libwv-1.2-3, screensaver-default-images, tango-icon-theme-common)
<cjwatson> maybe more fallout from the new syncproxy or something
<cjwatson> ubuntu-server preinstalled is currently building so I'm hesitant to respin; at this point I think it might be best left to tomorrow morning's cron job
<stgraber> would be great if someone could review bug 850550 (ideally I'd like to do the changes tomorrow morning), thanks!
<ubot4> Launchpad bug 850550 in ubiquity-slideshow-ubuntu (Ubuntu) (and 1 other project) "[UIFe] [FFe] Removal of sabayon, pessulus and nanny from the Edubuntu 11.10 seed (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/850550
<gador> I have a question. I fixed a bug (https://bugs.launchpad.net/ubuntu/oneiric/+source/ihu/+bug/770906) but got the BetaFreeze email now.
<ubot4> Launchpad bug 770906 in ihu (Ubuntu Oneiric) (and 1 other project) "ihu version 0.6.0-2ubuntu2 failed to build on amd64 with GCC-4.6/oneiric (affects: 1) (heat: 8)" [High,Confirmed]
<gador> Since I used the next debian version as a basis, should the fix still be merged in the main branch?
<gador> didrocks, you seemed to be awake: I just a question concerning Beta Freeze. Maybe you could help me?
<didrocks> gador: sure
<gador> I fixed a bug (https://bugs.launchpad.net/ubuntu/oneiric/+source/ihu/+bug/770906) but got the BetaFreeze email now
<ubot4> Launchpad bug 770906 in ihu (Ubuntu Oneiric) (and 1 other project) "ihu version 0.6.0-2ubuntu2 failed to build on amd64 with GCC-4.6/oneiric (affects: 1) (heat: 8)" [High,Confirmed]
<gador> Since I used the next debian version as a basis, should the fix still be merged in the main branch?
<didrocks> gador: the beta freeze is this evening, 21 UTC, so you still have time today  :)
<didrocks> gador: do you know if the new version is introducing features?
<didrocks> or bug fixes only
 * micahg was hoping a release team member would answer, but there are major changes to the debian/rules files which from recent requests by the release team would require an FFe w/build logs just to verify the sanity of the changes
<gador> didrocks, I don't think so. At lease nothing is stated in the changelog
<gador> No new features, I mean
<gador> But I can only propose a merge (Which I did). So if you think what I did is ok, could you merge the branch?
<didrocks> micahg: the rules change are pretty easy
<didrocks> yeah, it's only a new bug fix in debian
<didrocks> gador: I guess if you can get it sponsored by the patch pilot today, it should be fine :)
<gador> didrocks, patch pilot?
<didrocks> gador: a sponsor to push it to ubuntu (not sure to have the time to do a lenghty review)
<ScottK> If you redid the build system, please ask for an FFe.
<didrocks> ScottK: it would be a sync from debian which did the change from debhelper5 to debhelper 7 (the new one is mostly the debhelper 7 boiler plate)
<gador> didrocks, and how would I get a sponsor to look at it today? The only thing I did until now with other bug fixes was to propose the merge and someone looked at it at some point in time.
<ScottK> didrocks: Still want an FFe and a debdiff.
<didrocks> gador: so you have to file the FFe for ScottK (if it isn't acked, it will stay in the FTBFS state) and try to ping the patch pilot on #ubuntu-devel or wait for him to have a look (the patch pilot is a sponsoring programm where everyone try to take some time for doing those kinds of review)
 * micahg will try to pilot before the freeze
<ScottK> This isn't really a "will it get in" FFe, but a "we want an extra level of review" FFe.
<gador> micahg, thanks :-)
<micahg> gador: you still need to get the FFe though
 * micahg still has his own FFes to file
<gador> micahg, so I only need to file a new "bug" in launchpad with the necessary information?
<micahg> gador: and subscribe ubuntu-release
<micahg> gador: also update the merge proposal to close that bug
<gador> micahg, what exactly do you mean?
<micahg> gador: let
<gador> micahg, I added the LP : bug# in the changelog, so it should close the bug when the branch get merged
<micahg> gador: yep
<gador> micahg, ok, I will file the bug from work (I need to get going now) Thanks for the help!
<micahg> gador: thanks for the fix
<gador> didrocks and ScottK , thanks to you, too ;-)
<gador> sure
<didrocks> yw :)
<mvo> could somene from the releae team have a look at the ui freeze exception #850217 please? design updated the default banner of software-center, got a ok from the docs team already
 * cjwatson will be flicking the switch to move package descriptions from Packages to Translations-en (bandwidth saving for multiarch) later today
<mvo> could somene from the releae team have a look at the ui freeze exception #850217 please? design updated the default banner of software-center, got a ok from the docs team already - its the only missing blocker for doing a new upload with a bunch of fixes
<ogra_> hmm, did the cron jobs not run ? i got no images but also got no failure mails
<ogra_> no build logs either :(
 * ogra_ doesnt get it ... seems the livefs build works for ac100 and mx5 but isnt attempted for any of the omap/omap4 images ... and cron.daily-preistalled doesnt seem to run at all
 * ogra_ looks at bin/default-arches
<ogra_> cjwatson, ogra@antimony:~/branches/cdimage-private$ ALL_DISTS=oneiric CDIMAGE_ROOT=/srv/cdimage.ubuntu.com bin/default-arches ubuntu dail-preinstalled oneiric
<ogra_> amd64 amd64+mac i386 powerpc
<ogra_> hmm
<ogra_> that should definitely spit out something different i think
<ogra_> (unless we started building preinstalled for x86 and ppc systems at least :) )
<cjwatson> ogra_: you apparently can't type "daily". :-)
<cjwatson> $ ALL_DISTS=oneiric CDIMAGE_ROOT=/srv/cdimage.ubuntu.com bin/default-arches ubuntu daily-preinstalled oneiric
<cjwatson> armel+ac100 armel+mx5
<cjwatson> ubuntu                  daily-preinstalled      oneiric-                armel+ac100 armel+mx5
<cjwatson> so it's doing what you told it to do
<ogra_> not really, it should also spit out omap
<ogra_> and omap4, but yes, i seemingly cant type
<ogra_> ubuntu                  daily-preinstalled      oneiric-                armel+ac100 armel+mx5
<ogra_> *                       daily-preinstalled      maverick-               armel+omap armel+omap4
<ogra_> thats what is in /etc/default_arches
<ogra_> err s/_/-/
<cjwatson> No, they don't add that way.
<ogra_> do i need to drop the dash from oneiric in the first line ?
<ogra_> hmm, at the top the file says i should put more specific matches first, i thougth thats what it means
<cjwatson> It picks *one* line and uses the entries from that.
<ogra_> hmm, tricky
<cjwatson> If they added the way you suggest then it would be hard to drop architectures.
<ogra_> so i need separae lines for sever core and desktop then
<ogra_> *separate
<cjwatson> Be specific
<ogra_> yes
<cjwatson> No, be specific about what you mean by what you just said
<ogra_> oh, well, we used to have just the second line and i usually just add to it, but that will build all possible preinstalled flavours
<ogra_> for ac100 and mx5 i only want desktop
<ogra_> and indeed only for oneiric
<ogra_> that made me create the top line
<cjwatson> Then you don't need separate lines.  'ubuntu daily-preinstalled oneiric- armel+ac100 armel+mx5 armel+omap armel+omap4' will do it.
<cjwatson> Other flavours will fall back to the less specific match '* daily-preinstalled maverick- armel+omap armel+omap4'
<ogra_> but then the cronjob builds server too
<ogra_> which i'l like to avoid on ac100 and mx5
<cjwatson> default-arches does not govern which cron jobs are run
<cjwatson> How about you enumerate every single image you want built and I will do the right thing
<ogra_> no, but it will return ac100 and mx5 as allowed arches for it
<cjwatson> No it won't
<cjwatson> ubuntu-server != ubuntu
<cjwatson> the 'ubuntu' project in cdimage is just desktop/alternate
 * ogra_ is referring to the original line that has just a * in the beginning
<cjwatson> Which doesn't list ac100 and mx5
<ogra_> that got me all flavours for all possible preinstalled arches in the past
<ogra_> (when i added the two new arches)
<cjwatson> Please just list every flavour you want and let me encode it
<cjwatson> every image, I mean
<ogra_> k
<mvo> cjwatson: could you comment on bug #850217 (ui-freeze-exception) please? or should I wait for kate ?  its hopefully just a formatlity
<ubot4> Launchpad bug 850217 in software-center (Ubuntu) "ui freeze exception for default banner (affects: 1) (heat: 10)" [Medium,Confirmed] https://launchpad.net/bugs/850217
<cjwatson> mvo: yes, will do
<mvo> great, thanks a lot!
<ogra_> omap3/4, ac100 and mx5 - preinstalled desktop
<ogra_> omap3/4 - preinstalled server
<ogra_> omap3/4 - netinst (shouldnt matter here)
<ogra_> cjwatson, ^^^
<mvo> I have some pending fixes in apt too, http://paste.ubuntu.com/689860/ that should be fine, right? just fixes, no need for a FFe?
<infinity> mvo: \o/ to the removal of binary caches on clean and update.
<cjwatson> ogra_: then it's as I said, and I've committed and deployed the appropriate change
 * ogra_ checks to understand 
<ogra_> aha, why dont you specify server explicitly on the second line ?
<ogra_> guessing that would work too, right ?
<infinity> ogra_: Because there's no point in having a specific match.
<ogra_> k
<ogra_> well, at least i understand my mistake now
<ogra_> cjwatson, thanks so much
<cjwatson> ogra_: There's no need; desktop is the one that's out of the ordinary, and everything else can use a default
<cjwatson> I try not to be excessively specific
<ogra_> yeah
<cjwatson> oh yes, infinity said that too
 * ogra_ somewhat misinterpreted "specific" here :)
<cjwatson> mvo: software-center> +1
<mvo> woooh, thanks
<cjwatson> Long descriptions should move to Translations-en after the next publisher run
<cjwatson> With any luck
<mvo> nice, thats going to be interessting :)
<cjwatson> 'apt-get clean' - what does that do to startup times?  doesn't that mean that every time you ask it to remove cruft from /var/cache/apt/archives/, it then has to build its package list caches from scratch?
<cjwatson> and for 'apt-get update', I thought it rebuilt the caches anyway?
<cjwatson> I assume we're talking about /var/cache/apt/{pkgcache,srcpkgcache}.bin here?
<cjwatson> I'm OK with the rest of it, although slightly nervous about the resolver change and curious what testing's been done on that
<mvo> it sill slightly increase the startuptime on the first run after apt-get clean, but the cache is rebuild automatically so that should not be a huge issue
<mvo> but yeah, the apt-get update one I'm not sure about, given that apt will rebuild the cache anyway automatically after the update
<infinity> It really won't.
<infinity> Not until this change.
<infinity> Trust me, I banged my head on that wall for two days a month or two ago.
<mvo> the resolver one is currently doing a test run in a VM for natty -> oneiric
<mvo> infinity: hm, it should unless there are i-m-s only hits
<infinity> If the update gave you a new Packages file, it will rebuild, but if you did something like, say, change the order of sources.list, the binary cache stays intact, and is now "backwards".
<infinity> At which point, I bug you about bugs that don't exist.
<infinity> Remember? :P
<mvo> infinity: iirc I fixed this one (sources.list timestamp check)
<infinity> Oh, true.  You did fix that one case.
<infinity> Did you also check preferences?  And .d?  And..? :)
<mvo> but I agree, there may be more cases and rebuilding is not that expensive (comapred to the download work it needs to do)
<infinity> I dunno.  Making update take more time sucks a bit on slow machines, but...
<mvo> it does check .d, not sure about preferences â¦
<infinity> I'm less convinced about deleting the caches on clean, TBH.
<infinity> I expect "update" to do work.
<infinity> I expect clean to just wipe out archives.
<infinity> But meh.
<mvo> ok, this all sounds controversial enough to just leave it out for oneiric
<mvo> thanks for the feedback!
<infinity> I dunno.  The resolver change, if it does what I think it does, sounds worth it, if it passes some solid testing.
<infinity> (Though any resolver change is scary)
<mvo> true, but the auto-upgrade-tester makes it at least easier to test common scenarios
<mvo> I will just cherry pick instead of taking the full merge
<infinity> Upgrades are getting more and more painful, and multiarch just made that a ton worse.  I suspect that resolver change (again, if I'm reading the intent correctly there) will actually help a lot.
<ev> I'm going to respin the Ubuntu desktop CD once ubiquity is published, so long as there are no prior complaints
<smspillaz> hi - can I get the release team to look at an FFE/UIFe that's been pending for a few days now ?
<smspillaz> https://bugs.launchpad.net/ayatana-design/+bug/837545
<ubot4> Launchpad bug 837545 in compiz (Ubuntu) (and 2 other projects) "Spread - center the workspace switcher to account for the launcher and pane (affects: 1) (heat: 10)" [Undecided,New]
<smspillaz> the explanation of what's changed and everything is on the bug
<smspillaz> skaet: ^ (sorry for bugging you! :))
<ogra_> lamont, hmm, i see a lot  annonaceae live builds in antimonys process list, but looking at annonaceae there doesnt seem to be anything building ...
 * ogra_ wonders if the ssh key changed with yesterdays changes
<ogra_> or something like that
<smspillaz> skaet: pitti ?
<skaet> smspillaz, hiya.
<smspillaz> skaet: hi!
<smspillaz> skaet: I need the release team to have a look at some stuff I've been doing in the workspace switcher
<smspillaz> desktop can't sign it off as the diff is quite large
<smspillaz> (it's a uife)
<skaet> smspillaz, is there a bug and pointer to details?
<smspillaz> sure
<smspillaz> https://bugs.launchpad.net/ayatana-design/+bug/837545
<ubot4> Launchpad bug 837545 in compiz (Ubuntu) (and 2 other projects) "Spread - center the workspace switcher to account for the launcher and pane (affects: 1) (heat: 10)" [Undecided,New]
<skaet> hmm,  looks like docs has ok'd it so that's one question answered ;)
<njpatel> Anyone from the doc team who can grant a poor soul a UIFe?
<skaet> smspillaz,  are all the pieces tested and ready to go in?  or is there still waiting on compiz part?   can't tell from the description.
<smspillaz> skaet: tested - we've have 3 dx people test them
<smspillaz> skaet: and it works fine
<smspillaz> skaet: and it doesn't depend on anything else in compiz
<skaet> smspillaz, want to cross check a few more things.  will get back to you in 30 mins or so.
<smspillaz> skaet: np
<cyphermox> hi, could someone please ack https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/849994 ?
<ubot4> Launchpad bug 849994 in network-manager (Ubuntu) "FFE: add NetworkManager DUID support (affects: 1) (heat: 8)" [Undecided,New]
<skaet> smspillaz, ok,  have gone in and acked it.   If you can't make the upload deadline of beta freeze 2100,  we probably should hold off though.
<smspillaz> skaet: how long have I got
<stgraber> smspillaz: 21:00 UTC
<smspillaz> ok :)
<skaet> smspillaz, please coordinate with didrocks to make sure any of his changes necessary to enable this, as well as yours, land before 2100.   Don't want this to cause breakage right now.
<smspillaz> sure thing
<skaet> :)
<charlie-tca> cjwatson: anything happening to bug 850172 ?
<ubot4> Launchpad bug 850172 in debian-installer (Ubuntu) "Xubuntu Oneiric Alternate images fail to find abiword dependencies when building images (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/850172
<cjwatson> depends, does total confusion count?
<charlie-tca> sure, it is a state I am in most of the time :)
<cjwatson> I tried again and it's still returning link errors on the same a handful of files saying "no such file or directory", except that I've checked and the files exist
<charlie-tca> so, it just doesn't like us no more, huh?
<cjwatson> charlie-tca: I'm going to have to trace it, but have run out of time for now - it's still on my plate though
<micahg> do we need an FFe for adding hardening to packages?
<cjwatson> I personally don't think so
<cyphermox> could someone please ack bug 849994; for DHCPv6 DUID support in NM
<ubot4> Launchpad bug 849994 in network-manager (Ubuntu) "FFE: add NetworkManager DUID support (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/849994
<micahg> cjwatson: are you planning a sync run before beta 2 freeze or should I use the API for stuff that needs to go in?
<cjwatson> micahg: I probably can, but you should use the API anyway
<cjwatson> unless you've already requested it
<micahg> cjwatson: ok, didn't want to add more work for you, will use API for stuff that needs to go in before beta 2
<micahg> thanks
<cjwatson> although my link to LP is really really slow today so maybe some other archive admin could run the sync queue?
<micahg> I'm still waiting on the sync credit bug to be fixed (don't need the credit, but it's how I watch for regressions), these are all xubuntu packages, so I have others to poke me if they break
<stgraber> slangasek, skaet: for bug 575469, the change in the upstart job to make it work without changing initramfs-tools doesn't seem to work. If it's something we want by freeze time, I'd have to revert to changing initramfs-tools (that's assuming the FFe is accepted)
<ubot4> Launchpad bug 575469 in newt (Ubuntu Oneiric) (and 3 other projects) "[UIFe] [FFe] recovery mode mounts filesystems read-write rather than read-only (affects: 2) (heat: 16)" [Undecided,Invalid] https://launchpad.net/bugs/575469
<stgraber> I spent a bit of time with jhunt earlier discussing it, for some reason cjwatson's suggested upstart job works on his setup but it reliably fails for me in an Oneiric VM installed from yesterday's daily...
<stgraber> so I don't know what you prefer, either revert to changing initramfs-tools or wait till we figure out why upstart doesn't work for me (and for sure missing the freeze time)
<skaet> stgraber,  lets let slangasek weigh in on this one.
<skaet> my preference is to revert at this point, but he may be more comfortable going for the fix.   Not sure.
<stgraber> also, with my ipv6 hat on now ;) would be great if someone from the release team could go and review bug 849994 so cyphermox can get it uploaded before the freeze
<ubot4> Launchpad bug 849994 in network-manager (Ubuntu) "FFE: add NetworkManager DUID support (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/849994
<stgraber> that missing "feature" in network-manager was really a bug (as it wouldn't be rfc compliant without it) but still, there's the FFe :)
<cyphermox> thanks stgraber
<skaet> Daviey, ^^ can you review 849994?
<Daviey> skaet: That simple patch is huge, i'd be happier if someone closer to network manager reviewed it tbh.
<cyphermox> hmm.
<Daviey> cyphermox: did pitti look at that, do you know?
<cyphermox> not that I know
<cyphermox> hold on, trying to get upstream to review it nao
<Daviey> cyphermox: oh cool, if it's in upstream - makes it less daunting.
<stgraber> if that counts at all, I did look at it :) cyphermox did the implementation based on discussions we had with upstream
<cyphermox> well, it's not in upstream now, but the lead dev can chime in :)
<stgraber> the actual implementation is what we agreed with Dan (upstream for NM) on the mailing-list
<stgraber> most of the code is to generate the DUID itself and escape it, the changes in the existing code are relatively limited (update existing broken lease files and call the generation code).
<stgraber> the change only applies to dhcpv6 which isn't too common yet and I can confirm that the DUID is indeed valid (as in, my home dhcpv6 server is happy with it) and constant (was the goal of the change)
<cyphermox> waiting for the email back from dcbw or a message in #nm
<cyphermox> Daviey: http://mail.gnome.org/archives/networkmanager-list/2011-September/msg00146.html btw
<slangasek> stgraber: for bug #575469, is there an implementation of the initramfs-tools approach ready for review?
<ubot4> Launchpad bug 575469 in newt (Ubuntu Oneiric) (and 3 other projects) "[UIFe] [FFe] recovery mode mounts filesystems read-write rather than read-only (affects: 2) (heat: 16)" [Undecided,Invalid] https://launchpad.net/bugs/575469
<stgraber> slangasek: yeah, that was my initial implementation. I'd use it with Colin's suggested changes
<slangasek> stgraber: so this would use all the same boot arguments for grub, but implement it by interposing recovery-menu before upstart?  and could still reasonably support running mountall by hand with --no-events?
<stgraber> I'd have the grub debdiff updated to set "startup-event=recovery" instead of "recovery". the initramfs-tools change will send that as --startup-event=recovery to upstart
<stgraber> upstart will then emit "recovery" instead of "startup"
<stgraber> friendly-recovery will be "start on recovery"
<stgraber> the mountall call in friendly-recovery will run with --no-events to avoid starting everything
<stgraber> and the post-start script of friendly-recovery will do a "initctl emit startup" to trigger the usual boot sequence on resume
<slangasek> I'd rather we still had 'recovery' as the boot argument
<slangasek> startup-event=recovery is excessively verbose for something users may be trying to edit / input at boot time
<stgraber> ok, I can make the initramfs-tools change look for "recovery" and set --startup-event=recovery on the init command line then
<slangasek> and that way the naming isn't tied to the specific implementation
<slangasek> yep, I think that would be best
<slangasek> now, if friendly-recovery isn't installed at all, this means the boot will hang?
<slangasek> since upstart will only emit an event nothing is listening for, so no jobs ever start
<stgraber> no, because the change to grub sets "single" instead of "recovery" when friendly-recovery isn't installed
<stgraber> so you'll boot in single boot and get dropped into a root shell
<slangasek> and the grub config is forcibly regenerated when friendly-recovery is installed/removed?
<stgraber> no, boot it definitely should, adding that to my list
<slangasek> ok
<stgraber> calling update-grub on postinst and postrm should do the trick
<slangasek> I haven't reviewed the initramfs-tools patch yet (please give a direct pointer when you have that done), but with those two concerns taken care of and provided you've tested this both with and without friendly-recovery installed, for normal, recovery, and single-user modes, I'm satisfied that we should proceed
<slangasek> IFF it can all land today
<stgraber> slangasek: https://launchpadlibrarian.net/79349232/initramfs-tools.debdiff
<stgraber> Coling recommended exec run-init ${rootmnt} ${init} "$@" ${STARTUP_EVENT:+--startup-event=$STARTUP_EVENT}
<stgraber> instead of the two lines at the end
<slangasek> looks good to me
<stgraber> ok, working on updated patches now
<ScottK> slangasek: Would you please demote digikam to Universe.  I've already removed it from the Kubuntu dvd and kubuntu-full.
<skaet> Daviey, 831496 - anything more about to land?
<astraljava> Hello all, on behalf of ubuntustudio-devel, may I ask someone privileged to upload ubuntustudio-meta, please? We made some modifications on the seeds. Thanks!
<Daviey> skaet: If i could work out how to add an empty task, yes :)
<slangasek> ScottK: the 'showfoto' binary is also unseeded from kubuntu-full?
<slangasek> (or maybe that's the one you mean anyway - but just to clarify)
<ScottK> slangasek: No.  Missed that one.  I'll fix it.  In the meantime, I'd  appreciate it if you'd go ahead and demote it.
<slangasek> ScottK: ok, will do
<stgraber> slangasek: updated patches attached to the bug
<stgraber> will start a ppa build now, not sure if I'll have the result before freeze time though
<ScottK> Seed fixed.  Meta in a moment.
<slangasek> what time is freeze o'clock today?
<stgraber> 21:00 UTC
<slangasek> tight indeed
<slangasek> stgraber: Breaks: upistart (<< 1.3-0ubuntu9) <-- opa
<stgraber> oops
<slangasek> stgraber: friendly-recovery also needs an update-grub call in the postrm
<stgraber> doh, forgot a bzr add... Let me get you a new debdiff for friendly-recovery
<slangasek> ok
<slangasek> if ! grep -q "recovery" /proc/cmdline; then
<slangasek> possibly redundant now, but also safe to leave it
<slangasek> and it better future-proofs the job
<stgraber> slangasek: https://bugs.launchpad.net/ubuntu/+source/friendly-recovery/+bug/575469/+attachment/2409475/+files/friendly-recovery.debdiff
<ubot4> Launchpad bug 575469 in newt (Ubuntu Oneiric) (and 3 other projects) "[UIFe] [FFe] recovery mode mounts filesystems read-write rather than read-only (affects: 2) (heat: 16)" [Undecided,Invalid]
<stgraber> yeah, and also avoids cases where someone would do: "start friendly-recovery" or "initctl emit recovery" on a booted system
 * slangasek nods
<slangasek> debian/friendly-recovery.symlinks> not idiomatic, is this for use with dh_link?
<slangasek> (filename should be debian/friendly-recovery.links, if so)
<stgraber> oops, /me fixes
<stgraber> yeah, that's for dh_link
<slangasek> and the upstart job even handles the case when the package is in conffiles state, nice
<slangasek> stgraber: aside from the last round of touch-ups, have you had a chance to test these changes out together?
<ScottK> FYI there will be a large number of no change KDE uploads to fix a problem with .desktop file translations.  Sorry.
<stgraber> slangasek: there are all done building on amd64 in my PPA, will test them now in a VM
<ScottK> slangasek: kubuntu-meta updated too.
<slangasek> ok
<slangasek> ScottK: spiff
<cyphermox> Daviey: I got good review from upstream despite there will be cleanup needed
<micahg> any opinion about bug 846483 and needing any exceptions? icons seem to be broke w/out them
<ubot4> Launchpad bug 846483 in ubuntustudio-icon-theme (Ubuntu) "icons do not play nice with XFCE (affects: 3) (heat: 14)" [Undecided,Confirmed] https://launchpad.net/bugs/846483
<Daviey> cyphermox: Being kinda desktop centric, i'd be happier if pitti looked at it.  Does it need to be on the iso tommorrow?
<cyphermox> Daviey: I guess not.
<cyphermox> stgraber: ^^ ?
<cyphermox> you're the one who wanted this to be in yesterday ;)
<ScottK> micahg: From the title it sounds like a bug.
<Daviey> micahg: screenshot before and after would certainly help.
<doko> skaet, slangasek: there is a buffer overflow in the gcc multiarch patch. please expect uploads for g{cc,cj,dc,nat}-4-.{4-6}-*
<micahg> Daviey: let me grab the updater to answer questions
<skaet> doko, what triggers the buffer overflow
<skaet> ?
<skaet> doko,  also, what is the bug number?
<micahg> falktx: Daviey was wondering if we can get screenshots of before and after for the icon theme change, is that possible?
<falktx> let me check
<doko> no bug number
<doko> gcc/gcc.c
<doko>        if (path == NULL)
<doko>         {
<doko>           len = paths->max_len + extra_space + 1;
<doko> -         if (suffix_len > multi_os_dir_len)
<doko> -           len += suffix_len;
<doko> -         else
<doko> -           len += multi_os_dir_len;
<doko> +         len += MAX (MAX (suffix_len, multi_os_dir_len), multiarch_len);
<doko>           path = XNEWVEC (char, len);
<doko>         }
<doko>  
<falktx> micahg: basically, because of the xfce change, lots of icons were not covered (xfce uses different names than gnome)
<micahg> Daviey: ^^
<falktx> micahg: this new version deletes the old icons and now depends on elementary ones
<slangasek> doko: what's the actual impact of this bug?  It does seem to have taken a while to notice; are we getting broken packages output as a result, or is there just a random risk of the compiler segfaulting (on select archs / with select options)?
<Daviey> falktx: So this provides the same experience of Alpha 2?  A change in XFCE broke it recently?
<falktx> micahg: Daviey: the old ones were just bad, and arrange them for xfce would be just too much work
<slangasek> doko: or to put it another way: what's the damage if we hold the update until after beta2 is out, given that we are about to enter freeze?
<falktx> Daviey: ubuntustudio used gnome, now it uses xfce
<Daviey> Ah.
<falktx> Daviey: ^this change broke the icons, as xfce needs different ones
<stgraber> slangasek: test in a VM looks good. recovery menu showed up with read-only filesystem, remount in read/write worked without starting any service, the various entries work and resuming does too
<falktx> Daviey: the updated branch will remove all old icons except the branding, and make it dependant on elementary
<falktx> Daviey: I hope it's clear enough...
<doko> slangasek, I don't know. it was noticed on mipsel-linux and kfreebsd-i386, but I don't see any reason why it should trigger on other archs
<Daviey> falktx: Out of interest, when did UbuntuStudio switch from gnome to xfce?
<falktx> Daviey: earlier this cycle, just about alpha-2/3
<doko> or should not
<slangasek> doko: what string is multiarch_len measuring?
<falktx> Daviey: micahg: is it possible to update the package now?
<falktx> or is it too late for beta-2?
<doko> slangasek, the multiarch_dir
<stgraber> slangasek: just saw your comment in the bug, will start uploading now. 20:59 UTC :)
<Daviey> falktx: do you need a sponsor?
<micahg> Daviey: I can sponsor, just need to know if I need a release ack or not
<Daviey> micahg: Just commented, seems fair.
<SpamapS> I have a fix for bug 791607 .. euca is demoted tho, so is it even subject to beta freeze?
<ubot4> Launchpad bug 791607 in eucalyptus (Ubuntu Oneiric) (and 1 other project) "Oneiric Eucalyptus fails to start up (affects: 1) (heat: 12)" [High,In progress] https://launchpad.net/bugs/791607
<slangasek> doko: what surprises me about this is that I would also expect it to affect all architectures, and result in an immediate segfault... if we're not seeing massive compiler segfaults yet then the impact seems to be very specific to the memory layout of the build.  We should fix the overflow, but it doesn't seem urgent to fix before beta for the default compiler.  Do you disagree?
<Daviey> SpamapS: everyfink is subject to b2 freeze.
<Daviey> SpamapS: With this, i'd be happy with a fix 5 mins before B2 is announced. :)
<ScottK> Daviey: Sort of.  Unseeded packages can still be uploaded, they just need a manual push from the release team.
<doko> slangasek, I do disagree. it's just luck that we are not hit
<SpamapS> Daviey: graziano's patch appears to work
<Daviey> SpamapS: rocking!
<stgraber> ok, I guess I'm done with uploads for today, now to make sure nothing breaks and start poking at ubiquity bugs again ;)
<doko> skaet, didn't see any feedback, so I assume you are ok
<skaet> doko,  I'm reluctant to go forward with this since this is the first we're seeing it, and we're now in beta freeze.
<Daviey> doko: On another note, Do you have another archive rebuild scheduled?
<doko> skaet, fine with this as well. just want to trade my arse for yours ;=P
<ScottK> Daviey: First one isn't done yet (still going on armel)
<Daviey> still 10 days?
<Daviey> 4 days \o/
<doko> Daviey, no, unless you can convince management to have any productive outcome on this
<doko> skaet, slangasek: any opinions? ^^^
<slangasek> doko: what do you mean by productive outcome?
<doko> slangasek, we had about ~800 uploads ater the test rebuild. Im fine if you do acknowledge that these uploads don't have any effect on the test rebuild
<SpamapS> Daviey: ok with graziano's patch I get a normal Euca system.. should I upload it?
<slangasek> doko: sorry, I don't get it.  I'm sure that the 800 uploads will have had an effect - *hopefully* all positive, but maybe some negative, which would be the point of doing another test, I think?
<astraljava> Hey guys, I created a new branch for our team (~ubuntustudio-dev), on which we depend on in the desktop seed. Do I need to file an FFe because of the new package?
<Daviey> SpamapS: Hell.. Yes..
<Daviey> SpamapS: I am overjoyed!
<SpamapS> Daviey: as am I
<doko> slangasek, Daviey I'm fine to start another rebuild. including the rescoring for the last rebuild
<SpamapS> Daviey: now we just need to strip out the "Ubuntu Enterprise Cloud" bits ;)
<doko> slangasek, if it's not needed, please just tell me
<Daviey> SpamapS: Ah, good point.  Being that it was in such a mess, that kinda got lost.  We should probably remove the UEC branding patch and images..
<Daviey> doko: Server certainly cares about FTBFS's, it's a good entry point for our massive community. :)
<SpamapS> Daviey: will open a bug for that, should be fine to upload that during beta.
<Daviey> SpamapS: Yeah, i don't think we need to still support the image-store, so should be quite easy to cut 'n shut.
<SpamapS> bug 851351 opened
<ubot4> Launchpad bug 851351 in eucalyptus (Ubuntu) "Remove "Ubuntu Enterprise Cloud" branding from Eucalyptus packages. (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/851351
<SpamapS> should e target that to 11.10?
<Daviey> SpamapS: makes little difference really.. If it's not done by b2, the milestone will be ported across anyway. :)
<Daviey> SpamapS: Are you looking to do that?  Now you are a euca expert?
 * SpamapS swears an oath to squirt Visine into Daviey's coffee
<SpamapS> Daviey: I'd be perfectly fine with handling that, as much of a Eucalyptus *NOVICE* as I am. :)
<Daviey> SpamapS: The rest of the team have forgotten everything about it now, which makes you the most experienced with it. :)
<Daviey> And now touched-it-last.. wow, you just signed up for so much pain.
<stgraber> oops, that last fix didn't make it in time apparently (.links file being the wrong way around)
 * SpamapS goes to find food for lunch and some dried worms to garnish Daviey's lunches
<NCommander> doko: building GCC is a 1.25 day event. so far our luck being holding pretty well, and I think I'd be much more confortable if the upload happened after we came out of B2 as that gives up a few weeks to fix anything that might break
<NCommander> on armel
<Daviey> \o/
<doko> NCommander, that's fine. I could stage these in a PPA if demanded
<NCommander> doko: that would be preferable, then we can simply binary copy them into archive if everything looks sane
<doko> but unortunately I don''t get any response :-/
<NCommander> ^- skaet, your opinion
<NCommander> doko: ?
<Daviey> wait, we can now binary copy from PPA to archive?
<NCommander> Daviey: we've been able to do that for years from unvirtualized PPAs
<NCommander> that's how the security team does their releases
<Daviey> interesting, i thought that was still wishlist.
<doko> the point is that you have to be trusted.
 * NCommander does believe there are SOME limitations on copying from virtualized PPAs :-/
<NCommander> anyway, I need to get something to eat, so I'll be back later
<skaet> doko, NCommander,  I'd like to explore the PPA approach a bit more.   What are the downsides?
<doko> skaet, what do you expect for a go or no-go?
<Daviey> Interesting concept, The PPA could be called 'Ubuntu experimental' where developers stage uploads which are still alpha.
<skaet> doko,  I don't understand why we don't use the PPA option more often, so figure there must be some downsides.
<doko> skaet, why should we?
<skaet> doko, risk management for pervasive changes
<doko> skaet, so why don't we use for the kernel across architectures?
<doko> s/use/use it/
<ScottK> Non-canonical people aren't allow access to unvirtualized PPAs AIUI, so it'd be a Canonical only PPA.
<doko> to upload yes, to access no
<slangasek> also, it's more manual work to copy from a ppa instead of pushing straight to the archive
<slangasek> so in most cases the extra effort probably outweighs any risk we're mitigating?
<skaet> doko, for the stable kernels are copied -proposed, and tested for 2 weeks before they go to -updates,  which is the same concept.
<doko> skaet, fine, but we are not talking aboout -updates
<slangasek> NCommander: "fix up anything that might break" - this is literally a change to the size of a buffer being malloc()ed to contain the name of a path; there is no impact on code generation
<slangasek> while I can see not wanting to risk having the build started during beta freeze and finish after milestone candidates are rolled with the result that libgcc and friends are out-of-date on the beta CD before we even get started, there's no reason for there to be anything than breaks and needs fixing
<ScottK> And exactly right now would be the time to do it so that if there is a problem there's actually time to react.
 * skaet pondering hard
<skaet> doko,  how long will the builds take across all the architectures?
<doko> skaet, if I use my buildd admin powers on armel, about 36h
<doko> s/use/misuse/
<slangasek> that implies building all of the different packages in parallel, yes?
<doko> this is for the default only.
<doko> I don't care when the non-defaults reach the archive
<skaet> doko, if we're going to do it, it all needs to be build and settled down before Sunday night, otherwise we run into the libgcc issue that slangasek points out.
<doko> skaet, please could you elaborate on the libgcc issue?
<slangasek> doko: libgcc out of date on the CD before we've even released the milestone
<slangasek> it breaks jigdo, means everyone sees "updates available" at all points during the milestone testing
<slangasek> we ideally want to avoid that
<doko> slangasek, how will be a driver change affect libgcc?
<slangasek> doko: it's not that it breaks anything, it's just that we want milestone CDs to contain up-to-date packages
<slangasek> doko, skaet: but it sounds like the conclusion is that we want gcc-4.6 uploaded to the freeze queue ASAP; and as long as "ASAP" is before end of day tomorrow, and the armel buildds are in good shape with no backlog, we can accept this and get it built easily by that deadline
<skaet> slangasek,  yes,  I think that's where we're ending up.
<slangasek> and if the upload and accept happen today, that even buys us enough time for a *second* armel build if the buildd gets 95% done and then falls over ;P
<skaet> Should I assume we're also also doing the gcj, gnat, gdk at the same time? Or do we want to start them now.
<doko> finally, thanks! I'll do this the first thing tomorrow morning
<doko> skaet, I'd like to delay these over the weekend, when the buildd loads are ower
<doko> s/ower/lower/
<skaet> doko,  ok.
<skaet> doko,  for the 4.4 we wait until after beta2 is out.
<skaet> ?
<slangasek> maybe do 4.4 opportunistically if it's clear that there are spare buildds and it won't impact the milestone?
<doko> skaet, thanks, so to summarize: I'l upload gcc-4.6 tomorrow morning, and anything else when I think the load doesn't effect any other builds?
<slangasek> and it doesn't impact the CDs anyway, so if we have to kill a 4.4 build to free up a buildd it's not the end of the world
<slangasek> doko: hard freeze, so you can certainly *upload* the others whenever you like
<doko> I'm fine to have any other build killed besides gcc-4.6
<skaet> doko,  do a cross check before uploading the other pieces, as we may have something in planning about to hit, but yes.
<slangasek> skaet: uploading doesn't hurt us, release team still has to accept the upload by hand... :)
<skaet> slangasek, yeah just realized that after I typed it. :)
<doko> skaet, sorry, didn't understand the cross remark
<skaet> doko,  no matter,  slangasek correctly points out, release team will need to let them in to start building.  We're hard frozen.
<skaet> and based on what you're saying, as long as gcc 4.6 is built, others can be killed off at need.
<doko> thanks for confirming.
<doko> just want to use the idle time on weekends
 * skaet nods
 * skaet is worried about the arm builds though, and not sure how much idle time there will be. 
<doko> skaet, slangasek , we do have 17 armel buildds. so he buildds will pick up main builds with the first priority. it's the abolute build time which matters. and even then,  a fix in the driver doesn't change anything in code generation.
<skaet> doko,  thanks for explanation.  Problem is that the arm buildds are broken right now, and we still don't have all the pieces for some of the images built.  Ncommander's trying to get it sorted.
<doko> skaet, sorry, didn't know. care to send a pointer?
<skaet> doko, pointer in pm.
<infinity> doko / skaet : The ARM buildd issue is with image builders, not package buildds.  Using build time on the package buildds shouldn't be a big deal, as long as it's done sanely.
<skaet> inifinity,  thanks for explanation.
* ChanServ changed the topic of #ubuntu-release to: beta 2 freeze in effect | http://pad.ubuntu-uk.org/ubuntu-release | 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
<SpamapS> eucalyptus FTBFS on armel..
#ubuntu-release 2011-09-16
<chrisccoulson> could someone approve that please? ^^^ :-)
<slangasek> chrisccoulson: accepted
<chrisccoulson> slangasek, thanks
<slangasek> ScottK: did you need someone else to wave the kde no-change builds through?
<YokoZar> Can I get my wine1.3 upload approved?  It removes a binary package and I figure the sooner we get that out of the archive the less problems we get.
<slangasek> YokoZar: this looks like a new upstream release that's subject to feature freeze; has this been ok'ed already by ubuntu-release?
 * NCommander debugs antimon
<NCommander> y
<NCommander> why are we building an iso for mx5?
<NCommander>  oneiric-preinstalled-desktop-armel+mx5.iso            14-Sep-2011 04:02  1.5G  Preinstalled desktop CD for Freescale i.MX5x computers (standard download)
<NCommander> thats wrong in like 5 different ways
<YokoZar> slangasek: Err, no, but I can vouch for it being better since I've been testing them all cycle
<YokoZar> I'll mark the bug
<YokoZar> fwiw I've always felt that Wine point releases generally fall under the "only bugfixes" general exception
<stgraber> oops, seems like that update-grub call in friendly-recovery's postinst is failing quite miserably in the livefs chroots...
<stgraber> apparently memtest86 installs fine when checking for /boot/grub/grub.cfg too, guess I'll do that too then
<stgraber> uploaded
<micahg> skaet: don't we get another week of being unfrozen after beta 2 before final freeze?
<skaet> micahg, yes
 * skaet wonders if one of her recent emails was unclear... sigh.
<micahg> just checked, same wording was in the beta 1 freeze notice...
<micahg> This line prompted the question: From now on,  all uploads to the archive and any user user interface
<micahg> changes will have to be approved manually by the release team.
<skaet> good point,  was only until beta 2 comes out.
<skaet> when beta 2 is announced, please remind me to send something out to set the context for the last few weeks.   probably needed.
<micahg> skaet: I will try to remember :)
<skaet> micahg, me too.   But I suspect I'll need to be reminded.  :)
<stgraber> would be nice to have that friendly-recovery change reviewed as soon as LP generated the diff. It's currently making livefs builds fail :(
<skaet> stgraber, done
<stgraber> skaet: thanks
<stgraber> skaet: I'm guessing pretty much all the livefs failed to build?
<skaet> stgraber, thanks for the fix. :)
<stgraber> skaet: I'm only getting the e-mails for Edubuntu
<skaet> stgraber: ??
<skaet> do we have problem with one of the mail lists?
<stgraber> no, I was just wondering if you indeed got a lot of livefs build failures in your inbox. I'm only marked as a contact for Edubuntu dvd so I never get the others.
<skaet> I've been working through the launchpad bugs all day, and yeah there are lots of failures to worry about.
<skaet> http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-mgr-o-tracking-bugs.html
<stgraber> ouch, that's a pretty long list of foundations... I guess I'll be doing some more ubiquity bug fixing then.
<skaet> stgraber,  yes please.
<skaet> :)
<ScottK> slangasek: Please feel free to wave them through, but generally I can get it, I was just away at a social engagement tonight.
<ScottK> skaet: Now I'm confused.  IIRC, last cycle we left the queue frozen between beta 2 and final freeze.  Are you saying we're going to do it differently this time?
<skaet> ScottK,  there's one more week right now between beta 2 and final freeze, that wasn't there in Natty
<ScottK> Did I miss where this was discussed?
<ScottK> If the queue is opened up, then I think that reduces the value of the Beta 2 testing since anything can get in between the two freezes.
<skaet> ScottK, lets talk about it tomorrow in the meeting then.  If the other members of the release team agree, I'm fine with leaving it frozen,  balancing work on approving each fix, against getting as many fixes in as possible.   Bug list is rather intimidating right now.
<infinity> I tend not to make the meetings (clashes with another meeting I have), but for the record, I'm in favour of just keeping us frozen until release at this point.  It's more work for -release and -archive, but I agree with the idea of keeping control on what gets in from here on in.
<infinity> (Unless people reject my uploads, then I think this whole idea is madness)
<infinity> :P
<infinity> skaet / ScottK : --^
<skaet> infinity, noted. :)
<micahg> ScottK: sorry, my memory must be faulty then, I was just trying to be consistent across releases
<ScottK> No problem. We'll get it sorted tomorrow.
<skaet> Agenda bugs sorted for the meeting tomorrow.
<skaet> https://wiki.ubuntu.com/ReleaseTeam/Meeting/2011-09-16
<skaet> for those who want an early look at it.
 * skaet --> zzz
<Laney> ^ fixes an oversight I made
<ogra_> NCommander, if you would read your backlogs regulary you would know why there is an iso for mx5 ... it was largely discussed in #ubuntu-arm when it showed up :)
<ogra_> (and yes, its a mistake)
<cjwatson> Laney: accepted, though I'm slightly confused why that showed up as an upload rather than a sync
<Laney> because I did syncpackage
<Laney> --no-lp
<Laney> I sometimes do that when uploading to Debian and Ubuntu simultaneously otherwise I risk forgetting
<cjwatson> ah
<cjwatson> I make notes :)
<Laney> yeah
<Laney> the home â work context switch can enbadden my mind though
<Laney> anyway, thanks
<didrocks> cjwatson: hey, can you accept the oneconf upload please? I start to get quite some duplicate because of a crash on unavailable apps.ubuntu.com
<cjwatson> didrocks: done
<didrocks> cjwatson: thanks a lot :)
<mvo_> would be good if someone could review/allow the apt upload, I'm afraid without it translationed package descriptions are broken
<cjwatson> mvo_: accepted, thanks - sorry for the delay
<mvo_> no worries
<mvo_> and thanks!
<doko> cjwatson, please have a look at gcc-4.6
<cjwatson> mkay
<cjwatson> you know one of these days queue diff generation will be responsive enough to be useful
<cjwatson> doko: pleasantly readable, thanks.  accepted
<jdstrand> skaet: hey-- I may be a few minutes late to the release meeting
<jdstrand> skaet: I think I'll be on time, but may not
<skaet> jdstrand,  ok, will move you to the end of the round table then, no worries.
<lamont> fwiw, pandafarm coming offline to add two more lp-buildds to it
<doko> cjwatson, please have a look at gcc-4.4. -9 is more or less -8ubuntu2. once that's approved, I plan to upload {gcj,gnat,gdc}-4.4 over the weekend
<ScottK> I'd appreciate it if someone would accept kubuntu-meta.  Kubuntu dvd's won't build without it.
<tumbleweed> skaet: I've twisted Laney's arm to represent MOTU tonight
<Laney> please put me ~first though, because I have an important date with a pint of beer
<skaet> thanks for the head's up tumbleweed - will put Laney on the agenda then.
<tumbleweed> Laney: :)
<skaet> Laney,  ok,  you can swap with jdstrand,  he's going to be late.   :)
<nigelb> Laney: tsk
<Laney> groovy
<nigelb> too less :P
<cjwatson> doko: accepted, thanks
<Laney> nigelb: hey, the pub has a new brewery on. it's out of my hands really
<nigelb> Laney: :)
<lamont> and pandafarm back online, I'll be adding the other two lp-buildds $LATER (need to finish the installs on them)
<jdstrand> skaet: I'm actually here
<jdstrand> skaet: I did say I *might* be late ;)
<jdstrand> skaet: but I don't mind swapping
<skaet> :)
<charlie-tca> cjwatson: to further add misery, Xubuntu alternate images install today
<cjwatson> charlie-tca: that adds perplexity, but not misery
<cjwatson> and the errors appear to have gone away from the log, too
<charlie-tca> Oh, well, okay
<charlie-tca> Ah, well, tomorrow is another day ;)
<charlie-tca> This is the first day this week they worked
<ScottK> slangasek: We're going to have to take kamoso off the dvd due to digikam as well (thus the pending kubuntu-meta upload).  I'd appreciate it if you would accept kubuntu-meta and demote kamoso as we've got an upload of it to do and need it out of main first so it doesn't get stripped.
<slangasek> ack, poking
<ScottK> Thanks.
<slangasek> ScottK: all done
<ScottK> slangasek: Thanks.
 * Laney found out today that libproxy is a bit broken and outdated
<Laney> do people think it's too late now to get the new upstream in? there's a minor api break and new soname that i'd need to check out
<micahg> hi skaet, there was just a new major chromium release with security fixes, it's the default browser now for mythbuntu, lubuntu, would this be ok to get uploaded before Monday?
<infinity> Laney: New API *and* new SOVER?  What could possibly go wrong?
<Laney> :-)
<ogasawara> skaet, could I get the linux-backports-modules-3.0.0-11.3 package approved in the queue.  It's only an ABI bump to match the current kernel in the archive.
<Laney> luckily it has very few revdeps
<Laney> basically it currently will crash your app if you are using a PAC ile
<slangasek> heh, my interpretation of the facts is slightly different
<slangasek> "OMG it has revdeps in main"
<Laney> :P
<infinity> Laney: Is the PAC fix backportable?
<Laney> I have no idea
<slangasek> Laney: no chance of cherry-picking the crasher fix?  (What's a PAC file?)
<Laney> but upstream sound a bit stroppy that we are still on the 0.3.x series
<Laney> (https://bugs.launchpad.net/ubuntu/+source/libproxy/+bug/547106)
<ubot4> Launchpad bug 547106 in libproxy (Debian) (and 1 other project) "Please upgrade libproxy to 0.4.x (affects: 6) (heat: 38)" [Unknown,New]
<infinity> slangasek: PAC files are how many/most large corporate networks configure proxy support remotely.
<infinity> slangasek: So, y'know, no big deal.
<Laney> it's moved on somewhat, so I don't know how easy it would be to tease out
<slangasek> heh
<Laney> it does seem a rather chunky update though
<cjwatson> ogasawara: we should definitely have the new lbm for archive consistency
<Laney> http://paste.debian.net/130422/
<infinity> Laney: Ugh.  This discussion goes all the way back to 2010?
<Laney> one of Those, yes
<cjwatson> infinity: large corporate networks and weirdos like me
<infinity> cjwatson: Seriously?
<cjwatson> yeah, it means I can configure my browser to auto-detect and I don't have to change proxy by hand when going between home and elsewhere
<infinity> Laney: I think there's no question we should have upgraded to 0.4.x long ago.  I think it's unfortunate that we're discussing it this close to release. :P
<infinity> Laney: But if you're willing to hand-massage the revdeps and take ownership of the fallout...?
<Laney> I only found out today when a semi-angry user came onto IRC
<cjwatson> though admittedly I sometimes turn off auto-detect on untrusted wifi anyway since I'm not convinced I want my browser executing javascript handed to me by an untrusted network
<cjwatson> but ANYWAY
<infinity> cjwatson: But a good idea, in theory, right? ;)
<cjwatson> right
 * Laney would support more apps using libproxy in the future though
<Laney> consistent proy support, yay
<Laney> working x keys too
<Laney> infinity: I'll look at it over the weekend
<cjwatson> if the new libproxy can fix my keyboard, I'm all for it :P
<infinity> I'm kinda hoping the new libproxy can make me soup.
<cjwatson> no, that's libsoup.  HTH
<Laney> now I have to sample the delights of http://www.maypolebrewery.co.uk/
<infinity> I hear they now depend on each other.
<Laney> good day.
<micahg> Laney: you know there's no more xulrunner, right?
<hyperair> wait, what? no more xulrunner?
<micahg> hyperair: we axed it about a month ago, not supportable under rapid release
<hyperair> ah right. i knew that.
<Laney> LALALA CAN'T HEAR YOU
<cjwatson> argh scons
<cjwatson> why do you have to have pointless abstraction around everything
<infinity> I don't much care why scons does any of the things it does, but I do wonder why people use it.
<slangasek> you used to maintain PHP, I wouldn't think you'd need to ask ;P
<infinity> I've reformed.
<nigelb> TO use ruby instead? ;)
<cjwatson> infinity: I shouldn't have to say this, but it wasn't my idea
<infinity> cjwatson: That seemed like a safe assumption to make.
<cjwatson> I think people use it because they want to be unable to cross-compile their software without taking excessive quantities of prescription medication
<cjwatson> but maybe that's just me
<skaet> ogasawara, approved.
<skaet> micahg, ok by me if the mythbuntu and lubuntu leads are comfortable picking it up.
<skaet> gilir, ^
<infinity> cjwatson: That's just unfair to the thousands of hard-working non-prescription drug vendors around the world who feed the rest of the Free Software world.
<micahg> skaet: just asked superm1 in #mythbuntu-dev as well
<gilir> skaet, micahg ok for me
<micahg> gilir: thanks
<Daviey> skaet: Do you know if cdimage has been fixed to not purge candidate ISO's?
<Daviey> (aka, delete-released-images fun)
<cjwatson> no, cdimage doesn't know what the candidates are
<skaet> Daviey, no
<cjwatson> we'll just have to be more alert and temporarily bump purge-days where necessary
<skaet> Daviey, now that you're on the release team, feel free to help us figure out how to get this part a little more robust. ;)
<Daviey> It's currently 3 days?
<cjwatson> http://paste.ubuntu.com/690961/
<cjwatson> I think the test is > rather than >=
<cjwatson> we can't increase it generally right nw because we're getting uncomfortably close to disk limits again
<cjwatson> *now
<Daviey> cjwatson: So, one i have a candiate - would it be bad to just chmod?
<Daviey> candidate*
<cjwatson> I would really prefer you didn't.
<Daviey> We've had images go awol twice now, at the hour of release.
<cjwatson> We should have a way to nominate a candidate from a shell on antimony, which could then maintain a local file listing the candidates and purge-old-images could respect that.
<Daviey> (One being for B1, the other for Maverick final release cloud images, for the same reason)
<cjwatson> I have no idea whether just chmodding would (a) work or (b) cause other problems, and I don't particularly want to find out.
<Daviey> Well yeah, that was why i was asking :)
<Daviey> I don't mind committing to working on that issue btw.
<cjwatson> What I'd need is a script that posts a candidate to iso.qa, given some appropriate authentication.  I can deal with integrating it into cdimage (although not for B2).
<infinity> Having a way to mark and save candidates would be nice.  On the other hand, if you think that a new build will break your image, your candidate's a bit useless, IMO.
<infinity> (In the sense that "we'll just ship something old because the archive is now broken" is a pretty bad place to be in)
<cjwatson> Yep, agreed.
<cjwatson> It's an emergency fallback.
<infinity> Yeahp.
<infinity> And also just to save on testing if the image actually doesn't change.  Which is valuable.
<infinity> But I suspect things might change between now and, say, Tuesday. ;)
<Daviey> infinity: Well, i see your point.. but we have to have a snapshot that can be QA'd.
<infinity> Daviey: Yes, I realise that.  See above.
<infinity> Daviey: Anyhow.  Some way to mark them would be shiny, I agree.  Bonus points if it can export a candidate manifest (maybe a dotfile) that we can pull to auto-populate the ISO tracker.
<infinity> (Which, I guess, is the opposite direction from how cjwatson was going...)
<infinity> And his probably makes more sense, so non-cdimage people can mark cadidates for their products.
<Daviey> cjwatson: So, cdimage queries iso tracker to see if it shouldn't delete?
<cjwatson> no, it should have a local copy
<cjwatson> I don't want it reliant on network when building images
<cjwatson> well, not that network
<cjwatson> You can, as of now, 'export CDIMAGE_NOPURGE=1' to prevent a manual image build from purging old images
<cjwatson> That should suffice for the time being
<cjwatson> A candidate manifest would do if we can pull it reliably.  I'd like to have a way to push from cdimage too, but maybe that isn't reuired
<cjwatson> *required
<cjwatson> We can then pull it from cron or something
<cjwatson> And just keep the last version if iso.qa is inaccessible
<infinity> archive-team.internal seems like a good place to pull from iso.qa, and then publish to cdimage?
<cjwatson> If you like
<Daviey> Hmm.. iso tracker doesn't host the iso.. so what purposes does posting it there have?
<infinity> If we don't want cdimage to be reliant on yet another sketchy remote host.
<cjwatson> I have no idea what archive-team.internal is
<cjwatson> Daviey: it lets people register tests
<infinity> cjwatson: p.c.c/~u-a :)
<cjwatson> oh right
<cjwatson> sure
<Daviey> cjwatson: Ah, so when we enter freeze - all builds appear on the iso tracker automagically?
<cjwatson> Daviey: no, they're posted manually right now
<skaet> Being able to auto-populating the ISO tracker and saving a copy that's on the ISO tracker off somewhere has a certain appeal,  and it unifies with the manifest and test results that way.
<cjwatson> though it would help if there were a way for them to be posted automatically; it's tedious manual work right now
<infinity> Daviey: Product owners should post their candidates to the ISO tracker (as they do now), but the difference would be that cdimage would now refuse to purge those.
<infinity> Daviey: You fail to nominate, we might purge, not our problem? ;)
<Daviey> cjwatson: Yes, i understood it to be manual - but you'd like it to do it for all, when we ramp up to release ?
<cjwatson> infinity: product owners don't typically post right now
<infinity> cjwatson: I guess a way to do one batch post at the beginning of a freeze/release cycle would be cool.
<cjwatson> it's normally the person building the images
<cjwatson> Daviey: in general yes
<infinity> cjwatson: I know, I was living in a fantasy world while verbally speccing that.  Product owners should be the ones nominating candidates...
<infinity> (In theory)
<Daviey> infinity: I think i'm missing how them being on the iso tracker would stop it purging, if it doesn't query the remote resource?
<Daviey> It seems two different issues?
<cjwatson> Daviey: we should pull a manifest of candidates every so often and check that
<cjwatson> rather than having to block while actually building the new image
<Daviey> cjwatson: ahhh
<infinity> Daviey: It wouldn't query during purge, obviously we'd consolidate the info and keep a local cache.
<Daviey> does the iso tracker currently expose that data?
<cjwatson> no idea
<cjwatson> I mean it's on the front page and could be HTML-scraped
<cjwatson> whether there's a more sensible mechanism, I don't know
<stgraber> iso tracker has a parsable export
<Daviey> The 'API' (i hate calling it that), has worked pretty well for the coud images, http://cloud-images.ubuntu.com/query/
<cjwatson> and of course all the names the ISO tracker has for things are gratuitously different from cdimage's
<stgraber> (not documented though :))
<Daviey> stgraber: Have a URL handy?
<stgraber> Daviey: yep, hang on a sec
<cjwatson> so there would be some ridiculously tedious thing to map them into the right form, much as there is in publish-image-set
<stgraber> Daviey: http://iso.qa.ubuntu.com/qatracker/dllist
<stgraber> Daviey: a bit empty at the moment
<cjwatson> I'd have to see what it looked like with real content ...
<stgraber> if you don't mind me adding the current daily of Edubuntu (low number of subscribers), you'll see the real content for that image
 * cjwatson -> dinner
<stgraber> oh, actually I can just change it in the DB for a few minutes, that way no e-mail get sent at all
<stgraber> Daviey: look now
<Daviey> stgraber: ah neat!
<infinity> Oh, that's quite usable, I suspect.
<Daviey> stgraber: Can the date stamp be added as a field?
<cjwatson> oh, yeah, that's not bad
<stgraber> yeah, adding stuff in there should be pretty easy, getting the changes deployed may take a while though
<cjwatson> Daviey: cdimage wouldn't need that
<Daviey> cjwatson: just query the hash?
<cjwatson> it can trivially construct the URL and just compare when deciding whether to purge an image
<cjwatson> wouldn't even need that
<cjwatson> I suppose the hash is an option too
<Daviey> good thinking that man.
<cjwatson> stgraber: cool, thanks, that should actually be doable
<cjwatson> anyway, really dinner
<cjwatson> I can maybe have a go at that next week in my CFT
<Daviey> Dandy.
<Daviey> I am concerned how many beer tokens i now owe cjwatson .
<adconrad> Grr, my co-lo machine's network is being DoSed...
<adconrad> stgraber: Would it break anything to add a magic EOF string to that list?
<adconrad> stgraber: So we could determine if an empty document was actually an empty list, rather than a broken webserver returning an empty document?
<adconrad> stgraber: That would be about all that would be required to make it a robust enough thing for us to use it to do filesystem matches and purge with impunity.
<stgraber> adconrad: I don't think anyone is actually using that page at the moment, so adding an EOF string should be fine as long as it doesn't respect the format of the other lines (so it'd likely get skipped by existing parsers, if there's any)
<infinity> Yeah, something simple like "=== end of list ===" or whatever.  Just something we can match on to see if we actually got a list, or something broken.
<stgraber> or maybe have it return something when the list is actually empty? I think it'd actually be easier to implement (looking at the (ugly) code)
<stgraber> so we know that if it's empty and doesn't contain the magic string, it's because something failed
<stgraber> or are you worried of getting a partial list too?
<infinity> Partials are a possible issue that this would solve too, yeah.
<infinity> Mostly, this is just more discoverable, though.
<infinity> Only returning a magic string on an empty list requires an API doc.  Returning it at the end of the list unconditionally is discoverably simple to write against.
<stgraber> updated the DB to fix the existing netboot images in dllist
<infinity> Why no hashes for the ARM netboots?
<cjwatson> Daviey: I'm not :-)
<cjwatson> infinity: doesn't much matter since cdimage isn't going to be purging those anyway
<infinity> cjwatson: No, was just a curiosity. :)
<stgraber> well, I'm rather wondering where the hashes for the non-arm ones come from ;)
<infinity> Hah.
<cjwatson> should be up a couple of levels
<cjwatson> e.g. http://archive.ubuntu.com/ubuntu/dists/oneiric/main/installer-i386/current/images/MD5SUMS
<cjwatson> basically go up until you hit images/
<infinity> Looks like that md5 is for netboot/gtk/netboot.tar.gz ... No sure how useful that is, but whatever.
<cjwatson> it lists all of them
<stgraber> ok, and it's using the one for "./netboot/gtk/netboot.tar.gz" instead of "netboot/mini.iso" or "netboot/netboot.tar.gz"
<cjwatson> oh right, you mean iso.qa is using the wrong one
<infinity> cjwatson: No, I mean on iso... Yeah.
<stgraber> has been way too long since I wrote that code... ;)
<infinity> stgraber: Has it fallen into "so old, it embarrasses you" or "so old, you don't understand your own black magic", or a bit of both?
<stgraber> well, the current ISO tracker was a PHP project for one of my programming classes 4 years ago ;)
<stgraber> so I guess, the answer would be, both ;)
<stgraber> maybe I'll see if I can spend a bit of time of the 12.04 cycle improving the ISO tracker a bit. Upgrading it to a supported version of Drupal and getting the LP integration finally working would be a good start ;)
<stgraber> then maybe get a basic API would be nice (did plenty of that with weblive, so easy enough to re-use for the iso tracker)
<stgraber> that shouldn't take much more than 1 or 2 weeks of work and I guess would be useful for quite a few
<skaet> stgraber, very useful indeed.   yes please.
<stgraber> I'll make sure we have a blueprint for UDS. I know we discuss replacing it entirely at every UDS for the past 3 years but that still didn't happen, so maybe fixing it is a better and cheaper option ;)
<skaet> :)   sounds good.
<cjwatson> evolution not revolution
<infinity> ^
<infinity> We reinvent enough wheels around here. :P
<nigelb> stgraber: Or rewrite in Django :-)
 * nigelb runs fast.
<lamont> doing a little debugging on arm, manualizing for buildd selection with anger
<davmor2> nigelb: was that an offer to spearhead the new django version???  stgraber looks like your off the hook dude ;)
<nigelb> davmor2: Technically, that would be ISD's job......
<nigelb> I won't be at UDS to get to that hook anyway ;-)
<charlie-tca> remote participation lets you have action items, too
<nigelb> heh, I think I took enough action items last time to lsat a yar.
<nigelb> *year
<stgraber> well, we've been talking about a rewrite in python for the last 3 years and it's still no there. So for now I'll stick with making the php one a bit more usable ;)
<stgraber> if ISD has time to rewrite something that covers all the current usecase, I have no problem with that ;)
<nigelb> I love how davmor2 went totally silent there :P
<davmor2> nigelb: Not an ISD project at all it's a QA tool and they'll like pass it back to stgraber :P
<stgraber> davmor2: good thing I don't work for QA then ;)
<nigelb> heh
<nigelb> Seriously though, If I had more time I'd love to help.
<davmor2> stgraber: I didn't say you did, I said they'd pass it back yo you ;)
<nigelb> But alas there's only 24 hours in a day.
<davmor2> nigelb: no there aren't there are 36 how long do you sleep man ;)
<stgraber> anyway, I don't think 12.04 is really the time where we'd like to switch to a completely different tool, so I'll have a look at how much changes I can make by alpha-1 and hopefully then just do a few bugfixes after that.
<stgraber> that's the tricky thing with the ISO tracker, it needs to work starting with alpha-1, not feature freeze ;)
<nigelb> stgraber: We could spec it and target it for 12.10.
 * nigelb ponders
<stgraber> nigelb: I don't think it needs speccing, we already have at least 2 complete blueprints on it ;) it needs implementation
<nigelb> stgraber: Oh. lol. Okay.
<nigelb> I agree with you that we probably don't want to swtich before 12.04.
<stgraber> nigelb: https://wiki.ubuntu.com/QATeam/Specs/TestTracker
<lamont> back on auto
 * skaet --> appt,  back on later tonight.
<infinity> cjwatson: Is there a reason you haven't shoved that curl through binary NEW for the xmlrpc-c/udeb business, or were you just hoping for a less biased set of eyes?
<Daviey> infinity: I don't know if cjwatson saw it, i uploaded it.
<NCommander> skaet: when do we plan to disable the crontabs? I think we're back up to full armel image building capabilities after a test last night and lamont fixed the root cause this morning
<stgraber> I guess we at least need to let everything build tonight as all the livefs failed yesterday
<NCommander> might be easier to just do that in manual mode TBH
<infinity> skaet had planned to just let the dailies keep going all weekend.
<infinity> Given that we know we're getting an influx of new GNOME suff on Monday anyway. :/
<NCommander> oh lovely
<skaet> infinity, NCommander - lamont has a fix for https://bugs.launchpad.net/launchpad/+bug/851934,  we're trying to figure out least impact for deploying it.
<ubot4> Launchpad bug 851934 in launchpad "umount-chroot fails to umount the chroot (affects: 1) (heat: 6)" [Undecided,New]
<lamont> infinity: NCommander so... the fun bug where things seem to take a minute to die...
<lamont> I just proposed a merge (lp:~lamont/launchpad/bug-851934) that at least keeps it from killing arm boards
<lamont> the question of the day is, do we want to roll that lp-buildd to the buildds on monday (US), or do we want to wait until after beta2
<NCommander> skaet: ugh, what a headache :-/
<lamont> with the attendant challenge that llvm may knock over the pandafarm
<infinity> lamont: Assuming that loop doesn't have any syntax errors (have you at least locally tested to make sure it DTRT?), I can't see how rolling it out would do any harm.
<infinity> lamont: Still, fixing this in the process killing script sounds saner, if we can figure out WTF is going wrong.
<lamont> infinity: it's live on ain and shedir, and llvm built on ain
<lamont> in terms of my work load, I'm going to let someone else take the "figure out what llvm is doing to sbuild-package" task
<infinity> lamont: Ahh, kay.  Your merge proposal said it was untested. ;)
<lamont> yeah - I need to update the bug
<lamont> and actually, I pushed the branch, but I haven't actually done the merge req yet.. :*
<infinity> lamont: I'm all for rolling it out all over then, if it's working.  But your call really.  You get to fix the world if if breaks because the patch isn't in place. ;)
<lamont> true dat.
<infinity> Still grumpy that this is happening at all, mind you.  I assume the bug appears on all arches, the others are just fast enough to not get hit by the race here, whatever that race may be.
<lamont> but it's "roll out everywhere" because someone will doubtlessly go get the world current wrt package installs, just like we do all the time
<lamont> we have only seen the bug on PANDA
<lamont> oh, that could be
<lamont> but haven't seen it on any other arm boards than panda
<infinity> Yeah, doesn't mean much that it's only happened on Panda.
<lamont> SMP+slow would be sufficient to explain that
<infinity> Could be an SMP-specific race dealing with processes falling out of proc before closing fds, or who knows what.  Either way, it's worth someone looking into.
<infinity> Probably worth keeping the bug open even after your patch lands, with a big "this is a workaround, not a fix" comment.
<lamont> https://code.launchpad.net/~lamont/launchpad/bug-851934/+merge/75831 <-- comments  on the merge, if  you would?
<lamont> "only a workaround" comment added to the bug
<infinity> The kill script is pretty anal about not exiting until everything's (supposedly) dead, according to proc, so this is still disconcerting.
<infinity> Given the reproducibility, though, this might be debuggable locally.  Maybe.
<infinity> Happy birthday to me?
<infinity> lamont: What prompted you to test with llvm-defaults and llvm-py?  Neither has been uploaded or built in ages...
<lamont> those were the packages that doko's rebuild of oneiric/arm did that knocked over the buildds
<infinity> Ahh.
<lamont> at least I'm guessing that's where they came from
<infinity> Probably.
<infinity> That would make some sense.
<lamont> but the packages were identified based on the logfiles of dead buildds
<infinity> Well, defaults is a quick build.  And I'm assuming it's just the act of installing build-deps that breaks it, since the build itself doesn't seem to do much.
<infinity> So, this might not be TOO painful to track.
<lamont> *shrug*
 * infinity fiddles.
<lamont> https://launchpad.net/~lamont/+archive/non-virt/+build/2789423
<lamont> for your package copying fun
<infinity> It's days like today that I remember why I have a local mirror...
<slangasek> ^^ that friendly-recovery isn't critical for beta, but it's required for friendly-recovery to be usable on cryptsetup-using systems
<infinity> slangasek: We haven't stopped the daily cronjobs yet, if it makes a shiny new feature actually testable/usable on certain systems, I'm all for it. :P
<skaet> :)
<slangasek> infinity: I think friendly-recovery was broken before as well
<slangasek> on cryptsetup
<slangasek> it's just the first time I've tested it in a couple of years :)
<infinity> slangasek: Not broken sounds better than broken.  But what do I know? :P
<slangasek> :)
<slangasek> I also have a fix so that we can get boot logs out of plymouth, after months of this being broken
<slangasek> but waiting for the results of lightdm flicker-free before uploading
<lamont> I must say, I like the pandas better with the stupid usb patch
<infinity> Yeah, a whopping 20MB/s throughput feels fast after 5...
<infinity> Sadly, it's still awfully slow. :P
<lamont> watching mkfs run is a sure reminder
<infinity> ...
<infinity> I don't like this bug.
<infinity> lamont: fuser, lsof, and walking proc/*/root (the method used by lp-buildd) find nothing using chroot/proc ... Yet, it's "busy".  \o/
#ubuntu-release 2011-09-17
<lamont> is there anything mounted under chroot/proc?
<infinity> Oh, derp.
<infinity> llvm-* build-deps on binfmt-support.  Of course.
<infinity> Now I feel silly.
<lamont> so umount-chroot is just broken, because it assumes that reversing the contents of /proc/mounts (which is somewhat random) will give a nicely ordered list
<infinity> lamont: So, we just need smarter umount ordering, probably.
<lamont> just loop
<infinity> lamont: Walk tree depths.
<lamont> it's saner than trying to order
<infinity> (or loop)
<lamont> and life is short.  feel free to update the bug?
 * lamont lets the panda fsck
<lamont> 210GB disk... sigh
<infinity> You know, screw sorting, I bet if you just inverted the list from the grep /proc/mounts, it would solve it.
<infinity> And much more elegantly.
<lamont> we already do that...
<lamont> and that's probably because we needed it _that_ order
<infinity> I don't see it inverted.
<lamont> maybe that's just my brain messing with me
<infinity> This is essentially what lp-buildd does:
<infinity> root@shiva:~# grep oneiric-llvm /proc/mounts | cut -d\  -f2 | xargs -r -n 1 echo
<infinity> /srv/chroot/oneiric-llvm/proc
<infinity> /srv/chroot/oneiric-llvm/dev/pts
<infinity> s/echo/umount/ for the real deal.
<infinity> /srv/chroot/oneiric-llvm/proc/sys/fs/binfmt_misc
<infinity> Invert that list, bug fixed.
<lamont> for now.  the ordering in /proc/mounts isn't exactly scientific
<infinity> It's FIFO.
<infinity> Sure, a package could mount -o=remount /proc in its postinst and mess with you, but... Eww?
<infinity> (I guess you could keep the loop too, but still invert the list)
<infinity> Anyhow, commented on the bug and the merge request.
<infinity> Reversing the order would be more efficient, but the loop is probably a safe catch-all anyway.
<infinity> lamont: The plus side is that there's no "underlying issue" or processes cleverly hiding from us, just a bit of umount PEBKAC, so I'm that much happier about your hack.  It will DTRT. :P
<lamont> heh
<lamont> thanks for digging into it
<lamont> in other news, chort.buildd will shortly be another panda builder
<infinity> \o/
<lamont> so if the panda isn't at 115200, what speed should I try?
<infinity> That's the only speed it should be...
<lamont> that's sad
<infinity> lamont: Actually, regarding the same bug.  No complex heuristics are required.  Piping a "sort -r" between the cut and xargs will DTRT.
<infinity> lamont: Cause paths sort quite nicely. :P
<lamont> for the non-pathological case, yes
<infinity> Build me a case where it fails?
<lamont> ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ <-- I do not like it when hitting return several times gets me that..
<infinity> I'm having BBS flashbacks.
<lamont> they're only slightly faster than some of them
<lamont> for the real BBS experience, you want a beaglexm or a bbg3
<infinity> And a copy of LORD.
<lamont> will that even run on arm?
<infinity> Under freedos under qemu, sure!
<infinity> Or something equally convoluted.
<infinity> Well, time to go have a birthday.  I'll be around here and there on the weekend for releaseish stuff.
<NCommander> infinity: happy birthday
<infinity> Danke.
<lamont> infinity: I just realized that serial console is somewhat overrated
<lamont> until it isn't. :(
<cjwatson> infinity: curl> I hadn't noticed it, but yeah, I'm probably biased.  If you want to, that'd be great
<cjwatson> infinity: on the umount thing, maybe umount -l would be helpful as well?
<infinity> cjwatson: Already did overrides and accepted the two new udebs.
<infinity> cjwatson: As for the umount thing, I'm leaving it in the hands of lamont and the launchpad team at this point, I've commented more than enough on the bug. :P
<cjwatson> ta
<astraljava> Hello folks, I recently added a new bzr branch for a package (lightdm-theme) for our team, ~ubuntustudio-dev. We'd like to include it in oneiric, still. Does it need an FFe?
<ScottK> astraljava: Technically yes, but on matters of flavor branding we'll approve whatever you all want, so whoever is the ubuntu studio lead just needs to say it should go in.
<astraljava> ScottK: Thanks, just a minute ago I got a response on -devel, though, that I should file an FFe. It's here: http://pad.lv/852623
<scott-work> ScottK: hi, ScottL here (ubuntu studio project lead) asking about getting a lightdm theme into the repos
<scott-work> ScottK: anything special we would need to do?
<ScottK> scott-work: Ack in the bug that you want it (I approved it for the release team based on that and then subscribe ubuntu-sponsors/find someone to upload it.
<scott-work> ScottK: aye
<lamont> cjwatson: umount -l feels way too much like a total hack to me.
<lamont> 18 arm builders are making a bit of a dent in the rebuild test
#ubuntu-release 2011-09-18
<Daviey> slangasek / cjwatson: When you get a moment, could you consider bug 853255?  Thoughts on a sync+delta or introducing a delta to include a new binary package based on current contrib/ app.  Neither have been tested, that is one for tomorrow.
<ubot4> Launchpad bug 853255 in dnsmasq (Ubuntu Oneiric) (and 1 other project) "FFe: Merge dnsmasq 2.58-3 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New] https://launchpad.net/bugs/853255
<cjwatson> doko: I'd appreciate it if you could review my clang upload - should appear in unapproved soon
<cjwatson> WTF, why is lillypilly's mirror so abysmally out of date
 * cjwatson RTs
<doko> cjwatson, looks fine. but I hate it if upstream's conditionalize on release names rather than features
<cjwatson> doko: I know, the configuration handling there is really sucky, I just didn't want to attempt a proper fix at this point
<cjwatson> risk of error seemed higher than the stupid fix
<stgraber> just uploaded a new ltsp fixing bug 838845 (missing fonts). The fix is simply to install all the same ttf-* packages as a regular ubuntu desktop into the ltsp chroot.
<ubot4> Launchpad bug 838845 in ldm (Ubuntu) "Chinese glyphs (and potentially some other languages) aren't rendered properly in ldm (affects: 1) (heat: 5)" [Medium,Triaged] https://launchpad.net/bugs/838845
<stgraber> I used wrap-and-sort to make the diff more readable (as the dependency list is pretty long), a clean diff is at: http://paste.ubuntu.com/692570/ (LP will show both wrap-and-sort changes + dependencies changes)
<cjwatson> confirmed that that clang change fixes libdispatch
<cjwatson> well, confirmed on i386 at least
<infinity> stgraber: Sounds vaguely sane.  The reordering of stuff in debian/*.install makes the diff a pain to read, though...
<infinity> stgraber: Also, assuming we merge with Debian's ltsp package (do we?), wrap-and-sort's going to make that a bit confusing/painful, unless they do the same.
<stgraber> infinity: we don't merge from Debian
<stgraber> infinity: http://paste.ubuntu.com/692570/ is the diff after the wrap-and-sort. I also did it in two stage in the bzr branch to make it relatively easy to diff
<cjwatson> ScottK: do you think dovecot-metadata-plugin should just be updated to a new upstream to fix bug 831179?  I'm pretty sure http://hg.dovecot.org/dovecot-metadata-plugin/rev/fc360cf4ef81 fixes the FTBFS, but I'm not sure I fancy extracting just the autotools bits
<ubot4> Launchpad bug 831179 in dovecot-metadata-plugin (Ubuntu Oneiric) (and 1 other project) "dovecot-metadata-plugin version 0.0.1~hg144-0ubuntu1 failed to build in oneiric (affects: 1) (heat: 4)" [High,Confirmed] https://launchpad.net/bugs/831179
<stgraber> infinity: Debian (Vagrant Cascadian) and Ubuntu (me) share part of our packaging and try to reduce our delta from time to time but LTSP is meant to be heavily integrated into the distros so I doubt we'll ever get to the point where we can just sync from Debian (we do for ltspfs, ltsp-docs and hopefully for ldm next cycle)
<Laney> libproxy made me a) sad and b) stressed
<Laney> not sure I'll finish it in time
<stgraber> Laney: what's wrong with it?
<Laney> many bindings that I'm not sure how to package correctly
<Laney> strange module system
<Laney> also it didn't appear to work, but that could have been user error
<Laney> stgraber: git://anonscm.debian.org/users/laney/libproxy.git give that a go if you fancy some fun
<Laney> my dpkg-shlibdeps hax are wrong and a better solution should be found
<Laney> night!
#ubuntu-release 2012-09-10
<babyface_> failed to install quantal desktop iso(build:20120909) with a popup window showing: the installer encountered an unrecoverable error. A desktop session will now be run so that you may investigate the problem or try installing again
<babyface_> and I filed a bug : 1048477
<Daviey> cjwatson: Did you see server sqaushfs's failed today?  Are you working on that as part of the kernel bundling fixes?
<Daviey> (Mornin' btw)
<Daviey> It looks related.
<psivaa> Daviey, Im not sure if this is what you are already referring to, but the report.html for quantal server has some entries
<Daviey> psivaa: no, that is a c-m issue i believe
<cjwatson> Daviey: only just started so I haven't seen it, but yes of course I'll clean up my own breakage :)
<psivaa> c-m issue?
<cjwatson> component-mismatches
<cjwatson> Though report.html is irrelevant when the live filesystems failed to build before that stage
<Daviey> cjwatson: muchas gracias
<psivaa> cjwatson, understand, thanks
<cjwatson> psivaa: looking at it though, this is one of the cases where non-empty report.html won't render the entire image unusable, just the MaaS bits
<psivaa> cjwatson, yes i noticed that our other server tests passed without any issues
<cjwatson> Daviey: livecd-rootfs 2.85 should fix it
<Daviey> super!
<cjwatson> babyface_: will look
<Laney> there were bugs over the weekend about ubiquity not launching
<Laney> xnox might remember numbers (we were at the global jam)
<Laney> in only-ubiquity mode; IIRC it was fine from the live session
<cjwatson> maybe, but nothing relevant fixed in bzr so I might as well debug it
<xnox> looking at it now, the only relevant bits are in /var/log/installer/dm
<xnox> GDBus gives many warnings
<xnox> and then there is Backtrace from X =/
<xnox> could be changes on the -desktop =/
<babyface_> no quantal alternate isos today?   the automated tests on quantal alternate isos was started due to there is change in :http://cdimage.ubuntu.com//daily/current/SHA256SUMS, but I didn't find any iso, why?
<xnox> cjwatson: Laney: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1048541
<ubot2> Launchpad bug 1048541 in ubiquity "[Master] Installation failed: The installer encountered an unrecoverable error" [High,Confirmed]
<xnox> cjwatson: Laney: X errors https://launchpadlibrarian.net/115365735/UbiquityDm.txt
<xnox> babyface_: didn't we drop alternate CDs ?!
<Laney> trolyes
<Laney> erm, "yes"
<cjwatson> I was about to say that, but we haven't actually done so yet AFAICS
<babyface_> xnox, yes, I know this,  so we wont have the alternate iso from today ?
<cjwatson> But you might as well stop testing Ubuntu alternate images permanently
<cjwatson> They aren't targeted for release
<Laney> I thought we fixed cron
<babyface_> cjwatson,  ack. thanks.
 * Laney looks
<cjwatson> No
<Laney> yeah that was xubuntu
<cjwatson> babyface_: There are images on the master system so it must be a mirroring problem of some kind *shrug*
<cjwatson> I've poked it in case it helps
<cjwatson> I suspect cdimage.u.c must be out of space
<babyface_> cjwatson, ok,  when  will we drop alternate iso?  is it good time to stop testing them from today?
<cjwatson> babyface_: I don't know exactly when we'll drop them but there's no reason you need to wait for that.  Please stop testing them today.
<babyface_> cjwatson,  ack. thanks.
<cjwatson> We certainly aren't going to put effort into fixing any bugs you find so there's no point :-)
<babyface_> cjwatson, ;)
<cjwatson> babyface_: I've sorted out the (probably) out-of-space problem on cdimage.ubuntu.com too
<babyface_> cjwatson, ah, yes, there are alternate isos again.  btw, I stopped all the automated test on alternate isos just now.
<cjwatson> Thanks.
<Daviey> cjwatson: I noticed that server images at least, are not being garbaged
<Daviey> http://cdimage.ubuntu.com/ubuntu-server/daily/
<cjwatson> Oh yes, I turned off purge-old-images around beta
<Daviey> is that still required ?
 * cjwatson reverts that
<Daviey> groovy
<cjwatson> I'll just let it autopurge next time rather than doing anything manually
<Daviey> right
<dobey> do we need an FFe to drop a package out of the archive? or to drop binary packages?
<tumbleweed> you need an FFe to do anything risky
<tumbleweed> dropping leaf binary packages (with good cause) should be fine
<tumbleweed> s/binary//
<dobey> i want to do this: https://bugs.launchpad.net/ubuntu/+source/ubuntuone-installer/+bug/1048669
<ubot2> Launchpad bug 1048669 in ubuntuone-control-panel/trunk "Drop ubuntuone-installer package" [High,In progress]
<dobey> :)
<tumbleweed> that seems FFe-worthy. Add some diffs to the bug and you'll get some review
 * Laney remembers angst around the introduction of that
<tumbleweed> yeah (also post FF, IIRC :P )
<dobey> it was a necessary evil at the time
<xnox> is ubuntu-one stuff the only bit that uses Qt on the Ubuntu Desktop CD, now that unity-2d is gone?
<xnox> or does e.g. landscape client does as well?
<xnox> is landscape-client included or is it installer again?
<xnox> what is the status on porting ubuntu-one to python2?
<dobey> python3?
<cjwatson> you can ask germinate this kind of question ...
<xnox> yes =)
<xnox> cjwatson: how do I use germinate?
<micahg> umm, won't the ubuntuone client still be there which needs Qt
<cjwatson> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.quantal/rdepends/ALL/libqtcore4
<dobey> partial porting for Q. dirspec is ported; and a bunch of work has been done on ubuntu-sso-client
<dobey> micahg: yes it needs Qt
<cjwatson> in this case grep for desktop seed and bend your brain around the tree display
<cjwatson> but briefly: appmenu-qt, checkbox-qt, software-center -> oneconf -> python-dbus -> python-qt4-dbus, possibly others 'cos I got bored
<xnox> so unity-2d "transitional" packages reverse depend on libqtcore4.... seems odd.
<cjwatson> only indirectly, by way of including support for global menu bars for Qt applications
<cjwatson> I don't see that unity-2d is at all related directly
<cjwatson> it just shows up because it depends on unity which recommends indicator-appmenu which recommends appmenu-qt
<xnox> hmm maybe my brain bending skills are not mature enough yet ;-)
<xnox> right. ok. so we do need qt.
<dobey> yes we need qt
<xnox> and do we have landscape-full-client on cd now?
<xnox> s/cd/ISO/
<dobey> i don't think so, but it doesn't use qt does it
<xnox> still would be nice to have. Well, I would want it.
<dobey> oh
<dobey> and i don't think it's ported to python3 yet either because it possibly uses twisted?
<dobey> anyway, i guess i'll have to FFe :-/
<xnox> good luck & have fun :-/
<jbicha> that new ubuntut online accounts stuff requires Qt too
<bjf> infinity, linux-lts-backport-natty 2.6.38-15.66~lucid1 (bug 1036914)  and  linux-lts-backport-oneiric 3.0.0-25.41~lucid1 (bug 1036577) are all ready for -updates
<ubot2> Launchpad bug 1036914 in linux-lts-backport-natty "linux-lts-backport-natty: 2.6.38-15.66~lucid1 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1036914
<ubot2> Launchpad bug 1036577 in linux-lts-backport-oneiric "linux-lts-backport-oneiric: 3.0.0-25.41~lucid1 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1036577
<infinity> bjf: Shiny, thanks.
<bjf> infinity: oh no, thank _you_
<micahg> infinity: can you release my chromium into precise-proposed please?
<infinity> micahg: Done.
<micahg> infinity: thanks
<psivaa> server report.html contains quite a number of entries just in case it has not been noticed
<cjwatson> psivaa: it's a reporting bug
<cjwatson> well, hm
<cjwatson> no, image build bug
<psivaa> cjwatson, ok, can i assume the issue will be looked at?
<cjwatson> I think I've fixed it - respinning to see
<psivaa> ok thanks
<cjwatson> which probably means the server test I was in the middle of is pointless:)
<cjwatson> psivaa: looks better now (when it finishes mirroring) - not empty but these problems at least don't look like image build bugs
<psivaa> cjwatson, thanks, will see how the tests go
<plars> cjwatson: the issue psivaa reported earlier seems to have become worse with the 20120910.2 build
<infinity> bjf: ^-- I already copied those an hour or so ago.
<bjf> infinity: my bad. checked the SRU page, checked the ppa, didn't see anything from queuebot here so ... i'll look harder next time
<infinity> bjf: Yeah, queuebot doesn't have much to say when I copy kernels, since they don't hit the queue. :P
<infinity> bjf: But I did update the tracking bugs appropriately, at least.
<skaet_> slangasek, infinity, cjwatson - have updated the crontab to remove ubuntu alternate from the daily builds.
<skaet_> (cdimage commit rev 1498)
#ubuntu-release 2012-09-11
<babyface_> anybody know why is there no new built precise desktop iso on Sep 10?
<cjwatson> plars: the issue psivaa reported was "report.html is very long", and it became shorter :-P
<cjwatson> plars: I do still intend to check it manually
<cjwatson> babyface_: unclear; probably not worth investigating now, we'll just see if today's works
<babyface_> cjwatson, yes, let's see if today's works
<sil2100> Hello!
<sil2100> I would like to propose an FFE for a feature that somehow completely got missed in all the FF-haste we had...
<sil2100> https://bugs.launchpad.net/ubuntu/+source/indicator-appmenu/+bug/1048992 <-
<ubot2> Launchpad bug 1048992 in indicator-appmenu "[FFE] Support for webapps in the indicator-appmenu package" [Undecided,New]
<sil2100> The features even landed in trunk before FF it seems, but there was no official new release since that time, so it missed FF
<psivaa> cjwatson, reported a bug on d-i for quantal server install failures, bug 1049011
<ubot2> Launchpad bug 1049011 in debian-installer "Quantal server installation fails on a vm at partman-md stage, " [Undecided,New] https://launchpad.net/bugs/1049011
<cjwatson> psivaa: Yeah, I'm in the middle of fixing it.  It's not in partman-md, it just looks like it
<psivaa> cjwatson, ohh ok, hope you'd change the title accordingly then?
<cjwatson> I already did
<psivaa> cjwatson, just saw thanks :)
<Laney> psivaa: it's rls-q-incoming not q-rls-incoming, btw
 * cjwatson will fix
<psivaa> Laney, ohh ok, sorry about that
<cjwatson> I'll respin in an hour or two once those fixes are published
<cjwatson> And retest
<psivaa> ok, hope our automated tests could verify that too
<knome> has ubiquity thrown "unrecoverable error"s for other, or is it just xubuntu?
<xnox> knome: duplicate. try images from 2012-09-11 should be ok.
<knome> xnox, which bug number should i use?
<knome> i mean, for reporting on ISO tracker
<knome> and do you know if the problem is xubuntu-specific or all flavors
<xnox> we know that ubiquity-gtk is borked, and we fixed it, so all images that used ubiquity-gtk were borked between friday and yesterday.
<knome> ok
<knome> huh :)
<knome> so, did you have a bug number for that? :)
<xnox> bug 1048211
<ubot2> Launchpad bug 1048211 in udisks2 "udisks2-inhibit crashes if udisks2 is not running" [Critical,Fix released] https://launchpad.net/bugs/1048211
<knome> thanks
<xnox> knome: it shouldn't be there on the 20120911 image... which one were you testing?
<knome> 10 i suppos
<knome> i zsynced
<knome> how do i check the image date?
<knome> i think i just got the 10
<knome> that must be it, because i was reporting to 10 too, that's why i couldn't send the report
<knome> cjwatson, https://code.launchpad.net/~ochosi/ubiquity/quantal-proposed/+merge/123041 should be correct now.
<xnox> knome: well there is 9/11 image available http://cdimage.ubuntu.com/xubuntu/daily-live/20120911/
<knome> xnox, probably wasn't when i zsynced
<knome> xnox, that was a while ago
<xnox> fair enough. just wanted to check in case the fix regressed.
 * xnox is trying 9/11 now.
<knome> yeah
<psivaa> cjwatson, I reported Bug 1049062 on update-manager-core for obsolete config files, affecting our daily tests
<ubot2> Launchpad bug 1049062 in update-manager "Obsolete config files for update-manager-core are left after precise2quantal server upgrades" [Undecided,New] https://launchpad.net/bugs/1049062
<cjwatson> psivaa: possibly the least interesting of the jenkins tests :)
<psivaa> cjwatson, that could be true, but seeing the failure every day made me raise the bug,
<cjwatson> Oh, sure
<cjwatson> It just has no end-user impact
<cjwatson> The only reason to worry about fixing it is to make the tests go green
<cjwatson> It's a valid bug certainly, but not OMG-now priority
<psivaa> i agree, may be we should think of what to do with the tests
<cjwatson> Meh, not really worth arguing about it either - I'll have a look
<cjwatson> Well, I take it back, while obsolete conffiles themselves are unimportant, in this case they pointed to some functionality being lost on upgrade
<psivaa> ohh ok, green balls mean less investigation time for us :), and thanks for looking at it cjwatson
<cjwatson> fixed now
 * cjwatson tests the server respin
<plars> cjwatson: right, I hadn't checked the file yet when I sent that, and later saw it was just a few packages.  Realistically, what do you see as the best way to handle things from report.html? Should a bug be filed for each package, or is there a preferred approach to dealing with problems found there?
<cjwatson> plars: It requires analysis
<cjwatson> plars: Filing a bug for each package will certainly be massive overkill
<plars> cjwatson: I suspected as much
<cjwatson> plars: I would recommend talking to the +1 maintenance team du jour: https://wiki.ubuntu.com/PlusOneMaintenanceTeam
<cjwatson> (search for schedule)
<cjwatson> well, "Schedule (12.10)"
<cjwatson> plars: Or this channel
<cjwatson> Because sometimes it'll be an image build issue that we know about
<cjwatson> I don't think right now there's a terribly sensible way to handle this in terms of bugs
<plars> cjwatson: ok, skaet had mentioned that too, but since you seemed to be handling with psivaa I wanted to ping you to find out if you preferred to be made aware of things there too
<cjwatson> In this case it related to something I was doing to image builds
<plars> cjwatson: understandable, just want some path to resolution for it
<cjwatson> You can't particularly know that in advance and I'm certainly not going to watch bugs on all packages to find out :-)
<cjwatson> So why not just make your standard process be to ask here; that will generally be good enough
<psivaa> cjwatson, any idea when we would be getting the precise server images with d-i updated with new kernel verison?
<cjwatson> I thought I saw mail that that had been copied into precise-updates today
<cjwatson> So should be tomorrow
<psivaa> ahh ok, thanks very much
<mterry> skaet, so that remote-login feature.  It was to be disabled-by-default because we thought that's what the security team requested.  Turns out that was not true.  Mind if I turn it on by default today?
<skaet> mterry, can they comment to that effect in the bug?  (and what's the bug number again please ;) )
<mterry> skaet, bug 1040221
<ubot2> Launchpad bug 1040221 in unity-greeter "FFe request: Provide remote login options" [Medium,Fix released] https://launchpad.net/bugs/1040221
<skaet> mterry,  seeing jdstrands comment now.   thanks.   ok by me, as long as we revisit if issues emerge.
<mterry> skaet, awesome
<cjwatson> OK, the server images should actually work again now
<skaet> :)
<Daviey> woot
<Daviey> thnaks cjwatson
<cjwatson> Has anyone had a chance to think about bug 1046890 as yet?
<ubot2> Launchpad bug 1046890 in grub2 "[FFe] grub2 2.00" [Undecided,Confirmed] https://launchpad.net/bugs/1046890
<stgraber> cjwatson: looking
<skaet> cjwatson,  to back it out if we see too many regressions?
<skaet> also,  is it all ready to land now?
<cjwatson> Difficult, but I suppose we could use a horrible version like 2.00+really1.99-blah
<cjwatson> There are no libraries with shlibdeps or anything
<cjwatson> Not quite.  I want to debug the dmraid problem that Robert Collins reported; I want to make sure I have changes to a couple of related packages prepared; and I want to issue some kind of call for testing from the PPA.
<cjwatson> But I wanted to make sure I wasn't just completely on a hiding to nothing before putting further work into the FFe.
<skaet> getting a  cleaner version would certainly be a good thing.   Question is timing enough to react if there are issues encountered.
<cjwatson> balloons: ^- Speaking of which, I could do with community testing of the above
<cjwatson> My feeling is that the devil we know is not actually particularly good in this case, given all the arcane gettext-related crashes :-/
<cjwatson> (in 1.99)
<stgraber> cjwatson: will you have it ready before beta2 freeze (next Thursday)?
<cjwatson> Yes, I think actually by the end of this week.
<skaet> cjwatson, stgraber - ok by me as long as we have a fallback to revert to before beta 2 freeze, if there are more "surprises" than anticipated.
<stgraber> cjwatson: commented and approved
<cjwatson> Thanks; I'm going to post a CFT to ubuntu-devel now, with a caveat about dmraid
<skaet> thanks stgraber.
<balloons> cjwatson, hmm
<balloons> ok, so pretty straightforward..  I see your ppa
<ochosi> hey folks, i'm aware you might be super-busy at the moment, but i quickly wanted to ask whether any of you could take a quick peek at my merge-request for ubiquity (it's really just a one-liner and only affects launching xfce's window-manager)..?
<ochosi> would be nice if xubuntu's installer wouldn't look corrupted anymore in beta2
<ochosi> (here's the link: https://code.launchpad.net/~ochosi/ubiquity/quantal-proposed/+merge/123041)
<cjwatson> balloons: How does http://paste.ubuntu.com/1198987/ look?
<stgraber> ochosi: #ubuntu-installer is usually a better place for these
<stgraber> ochosi: anyway, looking at it now
<stgraber> ochosi: oh, looks trivial enough. Can you add a debian/changelog entry too?
<ochosi> stgraber: oh, thanks. i wasn't aware of that. will go there next time!
<ochosi> stgraber: ah ok, didn't know i should. in what form? shall i push another commit to the branch or attach the changelog-entry?
<cjwatson> balloons: Oh, I'll expand the "please mail me" paragraph a little to ask for version and platform too
<balloons> cjwatson, so do you feel given the nature of changes it would be best to target some specific folks, instead of an overall call?
<balloons> or are you comfortable enough with the changes we can push it out to everyone, with the warning supplied
<stgraber> ochosi: another commit is easier for the merge
<ochosi> stgraber: ok, will quickly do that now
<stgraber> thanks
<ochosi> well thanks for looking at it so promptly!
<cjwatson> balloons: It's more that since it's a change that could in principle affect a large number of people (at least on non-ARM platforms) I don't want to bias the reporting in advance
<cjwatson> There isn't a particular set I'm looking for feedback from, although perhaps I should say something that this isn't for the faint of heart?
<cjwatson> I mean, pre-release boot loader packages in general rather than this update in particular
<balloons> yes.. that's what I mean.. we could target the message towards that audience
<cjwatson> So I think that audience certainly includes ubuntu-devel, but maybe not (say) all of Planet Ubuntu
<balloons> I could specifically ask several folks who are more than capable of doing this well and giving feedback
<cjwatson> Absolutely, that would be great if you have ideas; that's why I asked you :-)
<balloons> rather than a full on testing event on the tracker
<balloons> I think that's what we're looking for here
<balloons> although, before you actually release, we should broadcast the change.. when it hits quantal, we'll get the full on testing from everyone.. heh ;-)
<ochosi> stgraber: do i have to re-do the merge-request or is it enough that i just pushed the changelog?
<stgraber> ochosi: just pushing is enough to have it update
<ochosi> stgraber: ok, so far that's done. if i made a mistake or you need anything else from me just let me know (sry, i'm a bit new to these merge-requests)
<cjwatson> balloons: http://paste.ubuntu.com/1199006/
<cjwatson> balloons: Oh, yeah, I certainly want testing *before* pushing to quantal
<balloons> right... so I'll specifically ask some folks to test this round, and I'll pass your instructions to them.
<balloons> it will be more intimate.. if you feel that's enough then we'll push to quantal, and of course, it will get more testing when it lands :-)
<balloons> on the next reboot for everyone
<stgraber> ochosi: merged
<balloons> we could also go for a round II of publicized testing after the initial feedback from folks
<cjwatson> OK, https://lists.ubuntu.com/archives/ubuntu-devel/2012-September/035887.html
<ochosi> stgraber: thanks a lot!! that's one less thing for me to worry about now :)
<cjwatson> Also, folks here may be interested: I have secured permission to release my Python rewrite (in progress) of the cdimage tools
<balloons> cjwatson, ok, I'll pass along your note.. after some initial feedback, let me know if you want to open up a full campaign and we'll do so
<cjwatson> So once that's complete, which I'll try to do ASAP, we'll no longer have a separate deployment branch of cdimage, just a small separate branch somewhere with stuff like passwords and e-mail addresses that's genuinely private
<stgraber> cjwatson: yay!
<Laney> hoorah
<stgraber> so people will be able to run the same magic as we are :)
 * Laney updates grub in celebration
<cjwatson> I plan to move it to be hosted properly on LP in the process so that people will be less confused about how to commit
 * xnox ponders to upgrade to grub2 and then migrate to UEFI and possibly ditch initramfs luks....
 * xnox books a couple of hours on the weekend
<cjwatson> I have *not* tested the LUKS stuff in any way at all :-)
<TheLordOfTime> if I created a debdiff which was accepted into precise-proposed for SRU verification testing, and I was affected by the bug, am I allowed to self-verify that the built package in -proposed works?
<TheLordOfTime> (for a given bug)
<cjwatson> It would be nice to know that it at least works no worse than previously
<xnox> cjwatson: ok. i will prepare recovery boot first, cause it's my working machine with luks+lvm
<stgraber> I'll probably be upgrading to the grub from the PPA to see if it works better than 1.99 here (UEFI with the video mode not being handled properly)
<xnox> I was waiting out for 2.00 to try UEFI on my supposedly-UEFI-compliant laptop
 * xnox heard all sorts of claims about these Latvian laptops....
<cjwatson> GRUB 2.00 worked with DM-RAID in my test VM, so I think it may be specific to Robert's striped DM-RAID setup
<dobey> hi all. can i a get a release teamer to look at a couple FFe bugs? bug #1048669 and bug #1047606 thanks
<ubot2> Launchpad bug 1048669 in ubuntuone-control-panel/trunk "[FFe] Drop ubuntuone-installer package from archive" [High,Fix committed] https://launchpad.net/bugs/1048669
<ubot2> Launchpad bug 1047606 in ubuntu "[needs-packaging] [FFe] ubuntuone-client-data" [Wishlist,New] https://launchpad.net/bugs/1047606
<fginther> infinity, greetings. can you tell me why eog and evince were unapproved from oneiric-proposed? I've been working with cnd on the libgeis renaming work.
<infinity> fginther: Hrm.  Was a while ago, and I discussed it with cnd at the time.  Let me see if I can resurrect them and see why.
<fginther> infinity, thank you
<infinity> fginther: Or, wait... Do you mean "why did I reject uploads a week or two ago" or "why are the current uploads in the unapproved queue"?
<fginther> infinity, "why are the current uploads in the unapproved queue"
<infinity> fginther: Because that's where uploads to stable releases go.
<infinity> fginther: They look fine, I'll review and accept in a second.
<stgraber> unapproved here means "waiting for review", not "rejected"
<fginther> infinity, my apologies, I thought they wen to the "new" queue
<stgraber> new is only for new sources or binaries (that don't exist in the target archive)
<infinity> fginther: Nah, nothing in stable releases should be "new", generally, you're just in the strange position of having been uploading stuff to stable releases that wasn't there before. :P
<fginther> infinity, Ah, that explains it. Thank you.
<TheLordOfTime> if I created a debdiff which was accepted into precise-proposed for SRU verification testing, and I was affected by the bug, am I allowed to self-verify that the built package in -proposed works? (for LP Bug 1014044)
<ubot2> Launchpad bug 1014044 in php5 "PHP5-FPM not reporting errors to web server (nginx)" [Medium,Fix committed] https://launchpad.net/bugs/1014044
<infinity> TheLordOfTime: Yeah, if you've verified the actual binaries from the archive DTRT (rather than, say, your own test build), it's perfectly reasonable for you to do the verification.
<TheLordOfTime> infinity:  only systems running my test builds were mission-critical-fix-needed servers
<TheLordOfTime> i tested on my local create-then-destroy VM(s) which i use for testing stuff, as well as this laptop specifically
<TheLordOfTime> (the testing from precise, that is)
<infinity> Yeahp, that works for me.  The patch was entirely confined to the FPM SAPI, if I recall from when I reviewed it, so that's a pretty small set of people who would even know how to test it effectively.
<TheLordOfTime> yep
<TheLordOfTime> well...
<infinity> And it's wildly unlikely to magically break anything else.
<TheLordOfTime> the nginx team tries to push to get FPM used instead of cgi or what not
<TheLordOfTime> so i tend to use that
<infinity> Yeah, I'm sure it's seeing more use lately.  That said, a bug like this is sort of proof positive of the smallish user base.
<infinity> It never would have made a release version in apache2filter, for instance.
<TheLordOfTime> mhm
<TheLordOfTime> fixed that bug, marked it verification-done
<TheLordOfTime> and i think the segfault bug that the SRU included a fix for was also verification-done'd
<infinity> Anyhow, short story, I'm happy with you self-verifying.  Doubly-so, if you're testing in a production environment where you can spot regressions under load.
<infinity> Beats someone like me doing a testbed install and muddling around.
<TheLordOfTime> well, when the people running their sites say "PHP is fubaring, what're the error logs saying?"
<TheLordOfTime> I can't say "um... there are no logs..."
<TheLordOfTime> so i say i'm working on it :P
<TheLordOfTime> took a damn long time for me to notice that bug though
<TheLordOfTime> normally i see those kinds of bugs crazily quickly
<TheLordOfTime> ... in retrospect, i should have tagged that as a regression, because it was introduced in Precise (a regression between Oneiric and Precise)
<TheLordOfTime> infinity:  the real issue with the SRU was two-fold: (1) it fixed two bugs, and (2) the second bug (segfault) was a lot harder to test, and explosivity factor of that was unknown.
<TheLordOfTime> so...
<TheLordOfTime> (that's my interpretation of potential issues, of course)
<TheLordOfTime> infinity:  also, when you happen to see any emails from my @ubuntu.com address, feel free to ignore, when i sent that, you weren't online :P
<infinity> TheLordOfTime: ;)
<xnox> fginther: "unapproved" == "not approved yet / to be approved"
<balloons> cjwatson, I noticed today's daily still has
<balloons> "installing something over here, but this is so long it does not fit" string :-) Was this intended to be replaced
<balloons> ?
<fginther> xnox, thanks. infinity straighten me out
<xnox> balloons: my fault, fixed in trunk.
<xnox> balloons: pending next deployment.
<balloons> xnox, ok.. I guess no bug report needed then eh?
<xnox> balloons: I thought that string is not visible, I changed it to much longer one to test layout !English  which sometimes is very long.
<xnox> balloons: yeah no need ;)
<balloons> also xnox, while I have you.. It's interesting that the installer doesn't go to the partition screen or confirm the disk to install to, if there's only one disk
<xnox> balloons: I have one more fix for the top crasher, need to test a bit more and will upload a release.
<xnox> balloons: see bug reports, this is intended behaviour. Or do you have concerns?
<xnox> The button does say "Install Now" vs "Continue" =)
 * xnox filed a bug report to update test cases.
 * balloons is updating them now :-)
<xnox> =))))
<balloons> I only see a continue, and not "install now" when selecting it
<balloons> not concerns persay, just confirming intended behavoir
<balloons> and of course, the tests need to reflect it
<xnox> Hmm... if clicking that bottom right leads to starting installation, it should say "install now" and not "continue"
<xnox> that is a bug =)
<balloons> in this case, it's an "erase quantal and reinstall"
<balloons> it says continue
<xnox> with one disk that should say "Install Now"
<xnox> =(
<balloons> right.. one disk
<balloons> ok, dentist is calling.. ugh.. I'll bbl and file a bug for it
<xnox> ok.
<balloons> thanks xnox !
<knome> balloons, bug for the dentist? o.O
<balloons> knome, ohh yes!
<balloons> lol
<balloons> knome, btw, a tangent.. did you see your logo made it onto a cupcake?
<knome> i didn't!
<balloons> https://plus.google.com/104307250302998042813/posts/aMB1wGb4G8P
<balloons> :-)
<knome> cool
<knome> we probably should have lunch/dinner together some day on uds
<balloons> knome.. you bet
 * knome just made sure all his stuff will fit into the backpack along with the laptop, so no luggage \o/
<knome> anyway, we shouldn't populate this channel with this chat... :)
 * tumbleweed would love to nack all these unity FFes until it actually runs in my VM
<tumbleweed> I hope somebody is looking at that stuff
<skaet> tumbleweed, have started looking at some of them
 * tumbleweed is getting worried. People in the Loco have started upgrading and nobody has had anything good to say, yet
<Laney> someone lost their window manager mid-upgrade at the global jam
<Laney> that was un-fun
 * tumbleweed is busy helping someone with a broken nvidia
<stgraber> Laney: yeah, I had a few people getting similar problems... I may even be willing to spend some time next cycle to split the upgrade process into "download the stuff" and "install the stuff", where the first part would be done from the regular user session and the second part would be done from a minimal user session where there's not much that can crash
 * infinity recalls having this conversation not long ago...
<stgraber> because really, who actually manages to work during a dist-upgrade anyway? (with half the desktop randomly blowing up)
<stgraber> infinity: around two weeks ago I believe ;)
<Laney> it also took about 3 hours
<infinity> Three hours for an OS upgrade isn't world-ending.
<infinity> Crazy breakage is less pleasant.
<dobey> skaet: you're looking at FFes now? are any ubuntuone ones on your list?
<Laney> I'd say having a release upgrade put you out of action for that long is pretty bad
<infinity> Laney: Really?  Have you ever upgraded, well, any other desktop OS?
<Laney> well, not recently enough to be able to assert timings with any authority
<tumbleweed> still, the release upgrade could totally be done from a daemon that doesn't die if X does
<Laney> but I don't remember it taking that long.
<Laney> (OSX would have been the last one I did)
<infinity> OSX has a lot less software in the "core system" that they actually upgrade.
<infinity> So does Windows, for that matter, but any time they've offered an upgrade path, it's always been a nightmare, and a day-long process.
<dobey> Windows OS upgrades are fun. 6 hours of reboots!
<Laney> I don't think our bar should be to be as bad as Windows upgrades :-)
<infinity> Not that I'm saying we can't improve, we absolutely can, but I don't think we're doing particularly poorly either, when it comes to timing.
<infinity> We could definitely improve the "it all goes to poop, halp!" experience, though. :P
<tumbleweed> yeah, that's the low hanging fruit
<Laney> also, conffile prompts mid-upgrade
<infinity> Laney: Ones due to bad packaging, or legit ones, but you want them clustered at the beginning or end?
<Laney> the latter
<infinity> Laney: The former are definitely bugs.  The latter, I agree we should be able to do better somehow.
<Laney> bugs should just be fixed
<Laney> but if we do the latter then the former is a bit less annoying
<skaet> infinity,  could you take a look at https://bugs.launchpad.net/ubuntu/+source/ubuntuone-installer/+bug/1048669 and https://bugs.launchpad.net/ubuntu/+bug/1047606 ?  If they can land in the next day or so,  I think they should be ok - but wanted to make sure the archive aspects are all considered properly.
<ubot2> Launchpad bug 1048669 in ubuntuone-control-panel/trunk "[FFe] Drop ubuntuone-installer package from archive" [High,Fix committed]
<infinity> skaet: Looking.
<infinity> dobey: I'm a bit confused about why we still need an ubuntuone-installer.desktop, if we're dropping the installer in favour of just, like, installing the client.
<dobey> infinity: because we can't rename the file, as it will break the default list for unity launcher; and will thus break for people on upgrade as well
<infinity> dobey: Oh, does it double for launching the client as well?
<dobey> infinity: it just launches the control panel directly now, yes.
<infinity> dobey: Fair enough.  A bit messy that it has a silly name, but not world-ending.
<dobey> infinity: before, it launched the installer, which if control panel was already installed, would just run it
<dobey> infinity: yeah, i wish we could migrate the default apps stuff easily
<infinity> dobey: Both those FFe bugs look fine to me, is the -data thing a new source package, or just a new binary built from some other U1 source?
<dobey> infinity: new source package
<infinity> dobey: Upload away, then, so we can give it a once-over in the queue.
<dobey> great, thanks
<infinity> dobey: And do make sure it has sane Breaks/Replaces for u1installer.
<infinity> dobey: Or maybe even a Conflicts, given that we want installer to go the heck away.
<dobey> yep. already have breaks/replaces of ubuntuone-installer in ubuntuone-control-panel in our daily builds even :)
<infinity> dobey: Yeah, but this -data bug implies that it'll ship the installer.desktop, so it'll need a Replaces as well (or, like I said, maybe just a hard Conflict to force removal)
<dobey> infinity: ah. i need to update the description for that, sorry. it was going to, then i realised there is no point for it, and just put that file in ubuntuone-control-panel instead
<infinity> Check.
<dobey> was going to and even built a package, and lintian complained about .desktop without the binary in the same package, and i was like "oh, duh, why did i do that?" :)
<skaet> thanks infinity
<infinity> Right, okay, I'm really going to lunch now. :P
<stgraber> cjwatson: I just upgraded using your PPA and the first dist-upgrade failed: http://paste.ubuntu.com/1199608/
<stgraber> cjwatson: not sure if that /video.lst is something wrong in the new grub2 or something else
<stgraber> cjwatson: calling apt-get install --reinstall on the linux-image package succeeds, so I guess it may have been some weirdness when having both a kernel and the new upgrade installing at the same time
 * stgraber reboots to see if the new shiny grub at last boots that system :)
<stgraber> cjwatson: ok, so all good except that problem during the upgrade. System boots fine and I'm not getting the video mode error anymore (instead getting the aubergine screen from grub for a second)
<cjwatson> stgraber: Thanks - possibly an ordering issue then.  Could you mail that to me so that I have a record of the problems all in one place?
<cjwatson> It's probably ordering between grub-install and grub-mkconfig.
<stgraber> cjwatson: sure, will do once I have something better than my phone to send that :)
#ubuntu-release 2012-09-12
<infinity> Oh, thank god, I was worried we might go a whole month without a poppler ABI bump.
<infinity> I wonder if maybe we should rename PlusOneMaint to PopplerAndEDSMaint.
<doko> just staff two people from -desktop for the team, there's not much to do for -foundations
<infinity> I dunno, we had a nasty poppler API transition earlier this cycle, where the best porting work was done by a member of the kernel team.
<infinity> Clearly, we need more kernel people.
<psivaa> Just in case it has not been noticed, the report.html for quantal server contains 9 packages, though they are not affecting our daily automated tests
<xnox> psivaa: I am curious which report do you mean. Can you please give a full link?
<psivaa> xnox, http://cdimage.ubuntu.com/ubuntu-server/daily/current/report.html
<xnox> I see. cool thanks.
<psivaa> xnox, just for the information though
<cjwatson> psivaa: yep.  they're all listed on http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html, so it isn't an image build problem.
<cjwatson> psivaa: I suspect that http://people.canonical.com/~ubuntu-archive/component-mismatches.txt explains a fair few of them
<cjwatson> Probably ignorable for now.
<Laney> infinity: doko_: Is it unreasonable to expect the uploader to care about transitions they start?
<Laney> He did do some, actually.
<psivaa> cjwatson, i see the connection now, thanks, will check them as well in the future.
<sil2100> Hello!
<sil2100> I have a new UIFe proposition
<sil2100> https://bugs.launchpad.net/unity-asset-pool/+bug/1049594 <- would be grateful if someone could check it out in their free time :)
<ubot2> Launchpad bug 1049594 in unity-asset-pool "[UIFe] Unity lens category icons need update" [Undecided,New]
<sil2100> Thanks!
<knome> cjwatson, i hear indicator-sound is still stuck in NEW (re: bug 1048217). any specific reason?
<ubot2> Launchpad bug 1048217 in ubuntu "[FFe] Re-introduce indicator-sound-gtk2/ido-gtk2" [Undecided,Triaged] https://launchpad.net/bugs/1048217
<jbicha> any idea what this "undefined video mode" error is, it shows up after the isolinux press any key screen but before plymouth starts http://imgbin.org/index.php?page=image&id=9478
<jbicha> I started seeing it in images I was building last night, and it's in the daily images today
<xnox> jbicha: nope. seen the same thing. File a bug? but not sure which package though.....
<cjwatson> knome: not got round to it
<cjwatson> I'll sort it out today
<knome> cjwatson, ok, cool. just checking :)
<cjwatson> jbicha: That message is from the kernel
<cjwatson> arch/x86/boot/video.c:332:              printf("Undefined video mode number: %x\n", mode);
<cjwatson> knome: currently quite confused in branch hell, https://twitter.com/colmmacuait/status/245834286735974400
<knome> cjwatson, strength and honour with that :)
<knome> any release team member: can we have an ACK for a UIFe for bug 1043170 (we have our old wallpaper on plymouth, and we're uploading a new wallpaper without tiny dots in the bottom-right corner, since lightdm nor plymouth scales them well)
<ubot2> Launchpad bug 1043170 in xubuntu-default-settings "Update Xubuntu wallpaper for Quantal" [High,Fix released] https://launchpad.net/bugs/1043170
<knome> correction: plymouth has the new wallpaper too, only-ubiquity doesn't. so we need to change the wall on lightdm and plymouth to dotless, and replace the only-ubiquity with a new one.
<knome> we'll take care of any screenshots that might have slipped in official docs or so, but i hardly think that has happened :)
<cjwatson> knome: Ack.
<knome> cjwatson, thanks
<knome> ok, we need another UIFe to upload our installer slideshow; we've dropped gnumeric from our default seed and we need to change our "office" slide: bug 1049658
<ubot2> Launchpad bug 1049658 in ubiquity-slideshow-ubuntu "[Xubuntu] Office slide needs to be updated" [Undecided,New] https://launchpad.net/bugs/1049658
<Laney> knome: you should be subscribing the release team
<Laney> pinging on IRC isn't the most efficient method
<knome> subscribed
 * Laney blinks at the amount of Unity exception requests
 * knome is happy xubuntu doesn't have loads (this time)
<knome> (maybe)
<knome> :P
<knome> well, that should be it really
<knome> post-beta1 cleanup
<knome> while we didn't even have beta1 ;)
<Laney> do you have working images now?
<knome> i'm told we have, but i haven't had time/been able to confirm that myself
<Laney> cool
<knome> yeah, there's still some hope...
<skaet> SpamapS,  looks like precise-proposed just got flooded with translations.   Could you see if you can get it sane?
<mvo> could someone from the release team please look at #1035207 ? its a FFe and its open for some days already and it would be great to get feedback on it
<stgraber> bug 1035207
<ubot2> Launchpad bug 1035207 in aptdaemon "[FFe] passwordless install of webapps (based on repo whitelist)" [High,In progress] https://launchpad.net/bugs/1035207
<stgraber> mvo: when would this be uploaded?
<mvo> stgraber: once I get a approval :)
<stgraber> mvo: ok, and all of mdeslaur's concern are addressed by what you're planning on uploading?
<mvo> stgraber: I think so,  I can double check with him
<mvo> stgraber: or you can mandate that he approves in addition whatever is easier
<stgraber> mvo: gave a conditional +1
<mdeslaur> stgraber, mvo: I've commented in the bug, the aptdaemon part is fine, as it doesn't contain the whitelist file itself
<mvo> mdeslaur: \o/
<mvo> thanks
<mdeslaur> np
<mterry> Hello!  John Lea requested a few UI changes to the greeter for 12.10.  It's 4 changes, you can see them linked from bug 1049231.  I've got a test package in a PPA (linked from that bug too).
<ubot2> Launchpad bug 1049231 in unity-greeter "[UIFe] The gap between the user name and password entry is too large in the greeter" [Undecided,New] https://launchpad.net/bugs/1049231
<ogra_> i guess by that time you should talk to the doc team too ... screenshots etc
<mterry> ogra_, shouldn't I get UIFe approval first, before bothering them?
<ogra_> well, doesnt UIFe involve talking to them ?
 * ogra_ isnt sure
<mterry> jbicha, ^ any comment on the above 4 greeter changes linked to that bug
<Laney> yes, you should mail them first
<mterry> Laney, ah first...  I thought after
<dobey> infinity: have attached new package files to https://bugs.launchpad.net/ubuntu/+bug/1047606
<ubot2> Launchpad bug 1047606 in Ubuntu Quantal "[needs-packaging] [FFe] [UIFe] ubuntuone-client-data" [Wishlist,New]
 * ogra_ thought at the same time :)
<Laney> https://wiki.ubuntu.com/FreezeExceptionProcess#UserInterfaceFreeze_Exceptions
 * Laney eyes the number of unity changes
<Laney> s/changes/exceptions/
<infinity> dobey: Just go ahead and upgrade it, I can review it from the NEW queue.
<infinity> dobey: s/upgrade/upload/
 * infinity needs coffee.
 * TheLordOfTime gives infinity coffee
<TheLordOfTime> :p
<dobey> infinity: i am not motu, so i can't upload it?
<infinity> dobey: Oh, derp.  Okay, I'll have a look at it and sponsor it if it looks sane.
<dobey> infinity: great, thanks
<mterry> Laney, ogra_: OK, ubuntu-doc posting linked to in main UIFe bug
<ogra_> :)
<infinity> stgraber: queuebot appears to be having a hissy fit parsing the queue again, while I'm accepting a mess of things.
<infinity> stgraber: (I'm accepting langpacks, it's flipping out about.. Everything else)
<infinity> I got all excited that maybe someone had reviewed and accepted eglibc. :P
<stgraber> infinity: killed for now
<stgraber> infinity: that's really weird, I'm not getting any traceback on queubot's side, so it looks like it's just getting partial data from Launchpad when the queue changes while it contains a lot of entry
<infinity> stgraber: Yeah, I wasn't implying that it was necessarily queuebot's "fault", it may well be the API giving you lousy results.
<infinity> stgraber: All done, you can let it back in.
<skaet> infinity,  re: we'll need to double check with dpm-afk on those translations before they are moved from precise-proposed to -updates.   From discussions I had with him earlier today,  he was surprised that they were there,  and was investigating.
<skaet> SpamapS ^
<infinity> skaet: We require some sort of manual verification before they move to -updates anyway, so this isn't new.
<infinity> skaet: But if the whole upload was a mistake in general, we can also just remove them from -proposed.
<skaet> infinity,  yup.   just wanted it visible in the channel that there was some questions about them.
<SpamapS> ACK
<skaet> :)
<plars> Daviey: ping
<Daviey> plars: HELLO!
<plars> Daviey: ubuntu-server doesn't seem to be installable with 128M currently, lots of ooms, trying 256M now which seems to get further, but hitting unmet deps when trying to install the kernel headers so it doesn't finish
<Daviey> that is less than cool.
<Daviey> ah
<plars> I can do some bisection to find a number in the middle if you think it's worth it
<Daviey> I suspect 12.10 has higher requirements than 12.04 had, due to the squashfs changes.. but I haven't tested.
<Daviey> plars: Well, currently I have no data on what to recommend for 12.10.. so that would be helpful.
<Daviey> plars: what image failed to install due to headers?
<plars> Daviey: 20120912
<plars> current
<Daviey> damn
<plars> Daviey: with 128 it seems to get stuck around running partman
<Daviey> I'm concerned that it workjed in Jenkins
<Daviey> https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-server-amd64_default/
<Daviey> Oh!  This only happens with lowmem?
<plars> Daviey: yes, was about to say... I was running with 256 when I hit that
<plars> but there was no oom
<Daviey> plars: can you automate testing different values?
<Daviey> or rather, script it?  It would be good to add to Jenkins long term, when we have a settled figure
<plars> Daviey: not easily at the moment, mostly due to my own unfamiliarity with the automation at the moment, but it's not hard to try
<Daviey> plars: Have you toyed with UTAH?
<plars> Daviey: what I'm working on at the moment is a test for the minimum supported system requirement
<plars> Daviey: so that's the end goal, but my branch of ubuntu-server-iso-testing with a couple of changes in place to do that with 128m seemed to be getting stuck so I tried it locally
<xnox> plars: Daviey: did you set lowmem bootime option to the debian-installer?
<plars> Daviey: I thought what you were requesting was an ad-hoc script to go test with 1M increments or something
<xnox> ... although 128MB doesn't sound that lowmem to me...
<plars> xnox: I'm just booting with kvm -m ### at the moment
<Daviey> plars: there is a kernel command line option called lowmem
<plars> hmm.. hadn't heard of it, I found https://help.ubuntu.com/community/Installation/LowMemorySystems but oddly it doesn't seem to mention it
<Daviey> I don't think it will change anything TBH
<Daviey> jamespage: do you have thoughts on using UTAH for automated min memory spec testing?
 * xnox has no clue what it actually does. I was just poking installer boot options once I found it
<plars> Daviey: I'll be looking into that too, but I haven't really had a chance to look into utah much yet, and we aren't converting to it in the lab until after quantal is done
<jamespage> Daviey: possible definately
<jamespage> if it can be preseeded then I think we can use a minimal KVM configuration to test it
<plars> Daviey: at the moment, my bigger concern is making sure that we have 1. correct values for minimum system requirements, and 2. that we test them with current infrastructure, then that we get it working with utah so that we are ready for next cycle
<Daviey> jamespage: certainly indefinitely ?
<plars> that's exactly what I'm doing right now with ubuntu-server-iso-testing
<jamespage> my only concern would be that squeezing the utah stuff into a minimum spec KVM might be to much
 * Daviey has NFI ;)
<plars> Daviey: TBH, that's a concern for tomorrow, for today I'd rather stick to - should 128 really be the minimum? or should it be extended?
<Daviey> plars: Yah
<plars> Daviey: and skaet sent me to ask you on that
 * skaet nods
<TheLordOfTime> where do i ask questions about the SRU docs?
<Daviey> TheLordOfTime: here would often be ok, depending on traffic
<Daviey> otherwise #ubuntu-deverl
<Daviey> err, -devel
<Daviey> plars: I think 192MB would be a more reasonable minimal TBH
<TheLordOfTime> https://wiki.ubuntu.com/StableReleaseUpdates#sun-java.2A  <-- isn't this incorrect?  i thought sun-java* were removed after 11.04 (it says the binaries are still shipped in multiverse)
<plars> Daviey: that was going to be the next thing I would try :)
<Daviey> plars: In Lucid timeframe, we decided to switch the cloud images smallest option from 128 to 192, due to issues (bug 544292).. But that was for a running machine, rather than the installer - which i'd expect to be more intensive TBH
<ubot2> Launchpad bug 544292 in eucalyptus "Increase m1.small memory to 192 MB" [Wishlist,Fix released] https://launchpad.net/bugs/544292
<plars> Daviey: unless you said "no, 128 is it, file a bug if it ooms with 128M"
<plars> Daviey: yeah, it couldn't be serving *too* much if di was the most intense thing it ever ran
<Daviey> TheLordOfTime: i believe you to be correct.
<Daviey> plars: well, from my experience, a high proportion of servers sit near idel.. The 'expensive' time is install & boot, as it's actually being hammered.
<TheLordOfTime> Daviey:  iirc my 11.04, that was the last version to ship a sun java 6 version, but i may be wrong on that.  it was somewhere around there that occurred
<Daviey> jamespage / doko: You are more familiar with this i suspect.. ( TheLordOfTime's issue )
<TheLordOfTime> its more of a documentation issue, rather than package issues, but hey, i notice random things like this ;)
<micahg> 8.04 is the only repo left with java in multiverse
<TheLordOfTime> micahg:  then the documentation on SRU special cases needs changing, it says 9.04 and later have binaries in multiverse
<micahg> the wiki is correct though for WIW
<TheLordOfTime> it is?
<micahg> 8.04 doesn't have desktop support any more thugh
<micahg> *though
<TheLordOfTime> so when 8.04 goes EOL, then the docs will probably need revising, I assume.
<micahg> yeah
<micahg> TheLordOfTime: it says before 9.04 had them in multiverse
<TheLordOfTime> micahg:  ah, i see, i misread.
<micahg> well, technically they were in multiverse until 9.10
<micahg> what it says is the ones in multiverse before 9.04 were the only ones
<TheLordOfTime> I see, I misread.
<TheLordOfTime> thanks for clearing that one up :P
<plars> Daviey: oh, I see the reason for the headers failing... it's not an unmet dep... looking further up, it ran out of space with 1G, though to be fair let it do a swap partition.  Let me redo that
<plars> no swap on this one, and I'll make sure that goes in the preseed
<TheLordOfTime> unrelated, but what's the general turnaround time for getting an SRU from -proposed to -updates when verification-done is tagged on the bug(s) that'd be fixed by the SRU?
<micahg> TheLordOfTime: after ~7 days of being in -proposed
<Daviey> TheLordOfTime: is there a particular one annoying you?
<TheLordOfTime> Daviey:  not annoying me per se, might be annoying some people, but its not high-priority
<TheLordOfTime> so no need to poke it up, was curious about the general turnaround time is all
<TheLordOfTime> :)
<SpamapS> hrm.. what happened to grub2 1.99-21ubuntu3.2 ?
<SpamapS> Just accepted 3.3 but now noticing 3.2 is not in -updates or -proposed
<micahg> Deleted in precise-proposed on 2012-06-06 (Reason: wrong solution to #1009294)
<SpamapS> Ok, so the next upload should be based on 3.1 not 3.2?
 * SpamapS notes that UDD should be banished from -updates and -proposed as its likely what caused this
<micahg> well, I would think reverting 3.2 and then adding on top
<SpamapS> I hit accept before thinking about what was between 3.1 and 3.3 ... now I'm thinking that should be rejected..
 * micahg defers to SRU people like infinity
<SpamapS> I think I need to also delete this one from -proposed, and ask the users to base off -updates and fix lp:ubuntu/precise-proposed/grub2
<micahg> I wouldn't manually "fix" the UDD branch
<Daviey> I don't think it's a big deal, based on 3.1 OR 3.2+reversed-patch->&changelog explaining reversal.. Really either way comes down to a changelog message.  Providing it doesn't include something that clearly sucked.
<SpamapS> Daviey: 3.3 includes 3.2
 * micahg would think you now need a 3.4 which includes the reversion of 3.2 and -v on what's in updates
<SpamapS> actually I like that solution better
<SpamapS> "fail forward" :)
<Daviey> SpamapS: Have you accepted the binaries or just the sourcE?
<Daviey> uhh
<SpamapS> Daviey: there's no accepting of binaries AFAIK .. unless you mean moving to -updates. I just accepted the source into -proposed.
<Daviey> yeah, iw as being daft. Sorry.
<SpamapS> I'll just upload a reverted 3.2, 3.4, myself
<micahg> yeah, if you hurry, it'll supersede the amd64 and powerpc builds
<micahg> hurry ~= 15-20 min :)
<dobey> infinity: i guess you didn't find anything to complain about with ubutnuone-client-data? :)
<infinity> dobey: No, it's just been a busy morning.  I'll get to complaining (or uploading) later.
<TheLordOfTime> infinity:  mind a privmsg?
<infinity> TheLordOfTime: No need to ask.
<balloons> njin found this bug -- not sure how many images are affected by it just yet. But the daily images just flat out are not booting
<balloons> https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1050006
<ubot2> Launchpad bug 1050006 in casper "Undefined video mode number: 0" [Undecided,Confirmed]
<jbicha> balloons: yeah, I reported bug 1049650 earlier today
<ubot2> Launchpad bug 1049650 in linux "Regression: "Undefined video mode" with 3.5.0-14.16" [Medium,Incomplete] https://launchpad.net/bugs/1049650
<jbicha> after the 30 second wait, the image did seem to boot for me
<kanliot> If there is no documentation for mode 0, how do you know it is a bug?
<balloons> jbicha, ok, let me see
<balloons> ahh.. new background ;-)
<SpamapS> would appreciate it if somebody else on the SRU/release team sanity checked my grub2 upload to precise-proposed
<infinity> SpamapS: Wait, that's a revert of a revert?
<infinity> SpamapS: My head hurts.
<TheLordOfTime> heh
<infinity> Or... A revert of a revert of a revert.. I think.
<SpamapS> infinity: mine too
<SpamapS> http://www.youtube.com/watch?v=VW27kyh7PVM
<infinity> SpamapS: Diffing from 3.1 to 3.4 makes it obviously correct, accepted.
<SpamapS> infinity: ty
<cjwatson> Daviey,plars: the installer includes a "lowmem" package which has experimentally-determined values for memory limits at various stages; tweaking those will change the behaviour
<cjwatson> so you shouldn't assume that current memory behaviour in d-i is immutable
<cjwatson> There's specific advice in lowmem/README on how to update those levels
<cjwatson> And the hacks that are currently performed in lowmem situations
<cjwatson> I would also say that a failure at 128M represents a significant change only over about two years well in excess of my expectations of natural drift, so deserves investigation in its own right
<Daviey> cjwatson: wait, it's in limits of your expectations of natural expansion ?
<infinity> Daviey: That's not how I'd read "well in excess of my expectations of natural drift".
<cjwatson> Daviey: I am surprised that d-i fails at 128M, and think that's worth investigating in itself.
<Daviey> ok, thanks. wanted to check.
<cjwatson> I don't think squashfs is necessarily all that directly related, since the high-water-mark for d-i memory use is supposed to be immediately before swap is enabled.
<cjwatson> Which is before we mount the squashfs and start trying to copy files off it.
<Daviey> well, i'll see what plars results are.. but also might try to gauge the entire process.
<cjwatson> As I say, the README file in the lowmem source package has specific advice on measuring this, which is likely to be better than what you or I or plars would come up with off the top of our heads.
<cjwatson> Because it's advising on the particular points that affect the behavioural changes in lowmem.
<plars> Daviey, cjwatson: from my initial 10 sec skim of a checkout of lowmem, the readme seems to suggest that low memory conditions should be detected automatically, so thee shouldn't be anything for me to adjust for enabling this right?
<plars> I'm booting in a VM with 128M
<plars> Daviey: oh, also I did some experiments in jenkins earlier and even with 196M, I was getting lots of OOMs during installation, with 256M too
<plars> need to look into that a bit more still, will try to do that later this evening if I have time
<cjwatson> plars: Indeed, normally.  The point of the lowmem= option is to find out easily whether the additional optimisations carried out by lowmem would help in a particular case.
<Daviey> plars: is this a heavily loaded host, where the VM is running ?
<plars> Daviey: not that I'm aware of, but I would have to check with retoaded to be sure
<Daviey> plars: would be interesting to see that
<Daviey> plars: do you know what machine it's running on?
<cjwatson> lowmem=1 and lowmem=2 enable progressively more low-memory optimisations.
<cjwatson> (These are also automatically enabled below certain hardcoded thresholds.)
<plars> Daviey: wazn
<plars> Daviey: my job was the only thing running at the time as far as jenkins is concerned, but I can't speak to what else might be going on with that system
 * plars has to go afk for a bit, will try to look into it a bit more later
#ubuntu-release 2012-09-13
<Mirv> hi! could someone ack or no-ack bug #1047067? we'd very much like to start proper testing of compiz 0.9.8.2 soon and include the patch.
<ubot2> Launchpad bug 1047067 in compiz "[FFE][UIFE][regression] workspace switcher layout needs adjustments" [Medium,In progress] https://launchpad.net/bugs/1047067
<Mirv> it's essentially a regression fix
<Mirv> to bring back 12.04 behavior
<Laney> what seed (branches) are used for the china images?
<Laney> nm
<bencer> hi, anybody could have a look at this? https://bugs.launchpad.net/ubuntu/+source/zentyal-samba/+bug/1043654 we have been waiting already some days without reply, thanks!!
<ubot2> Launchpad bug 1043654 in zentyal-samba "[FFe] New version of zentyal-samba" [High,Confirmed]
<cjwatson> Right, I'm about to start landing/deploying the first third or so of the Python rewrite of cdimage, and I'll do an Ubuntu desktop respin to test
<cjwatson> If I'm lucky and my existing test cases are sufficiently good, nobody will notice
<cjwatson> But in the real world some of you will probably get some error mail
<Laney> didrocks: ^ could you NEW u-s to main and remove u-d-s please?
<didrocks> Laney: sure, looking
<Laney> if it checks out, of course
<Laney> I pushed the seed change, needs refreshing after that
<didrocks> Laney: ok, source NEWed in main, I trust you on the C/R as you experimented it ;)
<Laney> it works as long as u-d-s is removed :-)
<didrocks> Laney: ok, and ubuntu-default-settings removed (thanks for the arch:all change btw), so they get published in the same publisher run
<didrocks> Laney: you will take care of refreshing ubuntu-meta once the promotion in main is published?
<Laney> I didn't do that, someone else must have done it in bzr
<Laney> yeah sure
<didrocks> Laney: I remember mentionning it to jbicha, wasn't sure he has done it :)
<didrocks> Laney: thanks!
<cjwatson> Gosh, that actually seems to have worked
<cjwatson> Didn't try a full build, just for-project ubuntu cron.daily-live, but still, that'll have gone through the whole rewritten publish-daily
 * ogra_ applauds
<Daviey> cjwatson: is there a documented list of changes,improvements ?
<cjwatson> * Test suite
<cjwatson> ..
<cjwatson> It's intended to be otherwise feature-equivalent right now
<cjwatson> I have enough to do with a rewrite without extending it as well :-)
<Daviey> cjwatson: is this the seeds to integration with Offspring?
<cjwatson> That's not the primary driver, although it may help that later
<cjwatson> (Or it may not; Offspring may well just use a subprocess interface)
<cjwatson> It's more that some things have reached the point of being unchangeable without a test suite
<cjwatson> And some things have been pushing the boundaries of being sensible to do in shell for a while
<Daviey> right
<Daviey> Is it also now easier to test code on a local machine?
<cjwatson> ./run-tests
<Daviey> i don't just mean pass tests.. i mean do feature work?
<Daviey> as in, will it create an output :)
<cjwatson> No
<cjwatson> But for practically all feature work (once the rewrite is actually complete) it should be possible to write unit tests
<Daviey> super
<cjwatson> Remembering that most changes to image *content* have nothing to do with cdimage
<cjwatson> (Ironically you can't yet do ./run-tests on nusakan because its unittest is too old, but maybe that will help persuade people to stop committing stuff on nusakan)
<cjwatson> The other driver for this is that I have permission to kill off the private code branch of cdimage and open-source everything as long as it goes along with being in Python with a test suite
<Daviey> oooooor, just people committing without running tests b:(
<cjwatson> I have a rusty nail here for such purposes
<cjwatson> I'll be moving the primary hosting to LP at some point, which will make it more or less impossible to commit from nusakan
<Daviey> cjwatson: You underestimated the will of wrongdoers
<cjwatson> Daviey: Well, speaking of which, I found (and committed) an uncommitted change in the deployed tree on nusakan which added a certain dave.walker@canonical.com to etc/notify-addresses
<cjwatson> I wonder who might have done that?
 * xnox Daviey-- for being naughty
<ogra_> lol
<Daviey> cjwatson: hmm, that is odd... because stgraber told me he committed it. :/
<Daviey> Oh wait, stgraber uncommited it.
<Daviey>  <stgraber> Daviey: looks like you manually commited something on nusakan (etc/notify-addresses) preventing pulling the new revisions of cdimage-deployment... I "fixed" it by uncommiting your change for now
<Daviey> 12:58 -!- cjwatson [~cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has quit [QUIT IN DISGUST]
<Daviey> cjwatson: I'd like to work out what happend.. I thought i committed it to /srv/cdimage.ubuntu.com/bzr/private/cdimage tree..
<Daviey> stgraber says he uncommitted something manually commited
<Daviey> it's not unlike me to mess up, but i'd like to work out how.
<cjwatson> There was no sign of a commit there
<cjwatson> But it's hard to tell now
 * cjwatson doesn't really feel like messing around with bzrlib to find uncommitted revisions :)
<Daviey> Lets just draw it up that i suck.
<xnox> cjwatson: $ bzr heads ?
<knome> i know that "irc is not the optimal place to ask" (yeah right), but could a release team member give us an ack on bug 1049658
<ubot2> Launchpad bug 1049658 in ubiquity-slideshow-ubuntu "[Xubuntu] Office slide needs to be updated" [Undecided,New] https://launchpad.net/bugs/1049658
<knome> (for UIFe)
<cjwatson> xnox: ah yes
<cjwatson> Well, I can only see an uncommit from stgraber on 2012-06-07, which was to crontab and doesn't seem related
<Laney> it's not optimal because it interrupts people rather than letting them get to it when they're in the right context.
<rtg> infinity, doko: bug #1049650 indicates a binutils regression. Any thoughts on reverting the most recent update ?
<ubot2> Launchpad bug 1049650 in linux "Regression: "Undefined video mode" with 3.5.0-14.16" [Medium,In progress] https://launchpad.net/bugs/1049650
<doko> rtg, as already said on -kernel: I'll provide you with (some) toolchain builds
<rtg> doko, oh, I thought your suggestion to use https://launchpad.net/ubuntu/quantal/+source/binutils/2.22.90.20120816-2ubuntu1 _was_ your tool chain build
<doko> rtg, well, first trying to find out if it's a binutils or gcc issue, then trying to locate the issue
<rtg> doko, then you're agreed now that it is a binutils issue ?
<slangasek> toolchain, at least
<slangasek> could still be a gcc regression tripped by a binutils change?
<doko> yes, looking into this.
<rtg> ok, I'll leave it to the experts.
<doko> rtg, how can the kernel package be used to just build this one binary?
<rtg> doko, I don't understand what you're asking. I updated binutils in my local chroot, then built and booted the resulting kernel.
<doko> rtg, I was asking for a smaller testcase than building the complete package including n kernels
<slangasek> because that's a limiting factor for those of us who don't have kernel team hardware ;)
<rtg> well, doko has access to kernel team HW IIRC
<slangasek> and access to install new binutils for testing?
<rtg> but there are shortcuts to the build process that only build the kernel binary without headers and udebs, etc.
<rtg> slangasek, uh, thats more difficult
<slangasek> right, and I think that's what doko wants
<slangasek> the shortcut
<rtg> fakeroot debian/rules clean; fakeroot debian/rules binary-generic
<doko> rtg: two binutils packages in my home on chinstrap. please check the newer one first, the older one only if the newer one doesn't work. afk now for some hours, will be back later tonight
<rtg> doko, ack
<rtg> doko, binutils_2.22.90.20120907-3_amd64.deb first ?
<doko> rtg, yes, reverted a commit, which is the only touching generic files. everything else is arch specific in the update
<doko> and the older is one is just the 2.22.90.20120816-2ubuntu1 rebuilt with recent gcc
<rtg> doko, ok, will do
<doko> have to run
<rtg> doko, binutils_2.22.90.20120907-3_amd64.deb seems to have done the trick. The kernel boots at least.
<rtg> (quantal-amd64)rtg@salmon:~/ubuntu/ubuntu-quantal$ dpkg -l|grep binutils
<rtg> ii  binutils                             2.22.90.20120907-3
<cjwatson> GRUB 2.00 uploaded, whee
<plars> Daviey: of interest... I get OOM with 256M, but not with 512.  Would logs showing the oom be useful? It sounds to me like the fact that I'm getting these OOMs, and failing to install completely with 128M would be a bug rather than an indication we should raise the minimum right?
<cjwatson> Are you following the directions in lowmem/README?
<cjwatson> If not, please do, it would be more helpful than raw figures with full installs
<plars> cjwatson: it's not clear to me what you're suggesting I do from that README.  It seems to indicate how it can be simulated if you don't actually boot with low amounts of memory and you want to simulate the behavior with lower amounts of RAM, but in my case, I'm controlling the ram with kvm
<dobey> mterry: ^^ is taht ubuntu-sso-client upload to precise-proposed yours?
<mterry> dobey, yeah
<doko> Riddell, please remind http://people.canonical.com/~ubuntu-archive/nbs.html (attica)
 * Laney eyes twisted
<Laney> doko: did you have FFe for that?
<doko> Laney, bug fixes only
<Laney> https://launchpadlibrarian.net/115528804/twisted_12.0.0-1ubuntu1_12.2.0-1.diff.gz ?
<doko> Laney, while you are here, why the difference in haskell armhf/armel build failures
<Laney> there is definitely a bug in the compiler, but for armel failing when armhf builds, check if the buildd in question is on precise
<Laney> now, I clearly see "Features" in that diff...
<Laney> when does twisted become installable again?
<doko> in about 2h. why do you need to depend on this catch-all python-twisted package?
<doko> if can't explain it, call it a compiler error ...
<doko> if you can't explain it, call it a compiler error ...
<balloons> So when I install today's daily on a machine which has 12.04.1, I am not given the option to upgrade. In addition, if I choose to install 12.10 alongside 12.04, I cannot chose the encryption or lvm options. This all seems correct, except me not being able to upgrade via the cd. Is this intended because of the LTS, because it's not final cd, or something else?
<Laney> if the compiler segfaults, I'll call it a compiler error
<Laney> but nice attempt at trolling me
<doko> sorry, didn't see the bug report
<xnox> balloons:  I was pondering about that as well. I'm not sure why. There are ~ bug reports about os_prober and missing fuse udeb
<xnox> balloons: it should offer to upgrade (well lifecd style upgrade which is reinstall while preserving files)
<balloons> xnox, right.. I thought so.. :-)
<ogra_> funnily i get upgrade notifications for every arm SD card i plug into my 12.04 desktop :)
<xnox> lol
<balloons> xnox, so heh, do you want a new bug on this?
<xnox> balloons: yeah....
 * xnox how did I end up being the $installer dev?!
<ogra_> you grabbed all these bugs :)
 * xnox reassigns a few xnox -> ogra_
<balloons> xnox, ohh you are?! Excellent, I've got more to assign you! :-)
 * xnox /0\
 * xnox where is the UTF characters head-desk when you need it
<TheLordOfTime> lol...
<Laney> doko: btw, it's not me depending on python-twisted, but kubuntu, ubuntu-server and ubuntustudio
<Laney> so if it's buggy to do that take it up there :-)
<mterry> Friendly poke about UIFe bug 1049231 and friends (unity-greeter ui nits)
<ubot2> Launchpad bug 1049231 in unity-greeter "[UIFe] The gap between the user name and password entry is too large in the greeter" [Undecided,New] https://launchpad.net/bugs/1049231
<doko> rtg: http://sourceware.org/ml/binutils/2012-09/msg00159.html
<plars> xnox: since you're now officially the install expert... :)
<xnox> hm?
<plars> xnox: any idea why, if I have a 1GB disk, and select LVM, the max it wants to use is 813MB?
<plars> it seems to want to leave about 200MB on the floor
<xnox> plars: 1GB is actually less in real units and then -5% reserved for root ~= 813?!
<plars> xnox: I seem to recall seeing what it came up with at one point and seeing about 200M unpartitioned space after this though, let me see
<xnox> 953.674 - 5% = 905.35 no clue
<xnox> so we are missing 92 MB
<xnox> plars: oh when you do autopartition it creates separate /boot partition outside lvm?!
<xnox> on my machine it's 300 MB but I'm not sure if I manually adjusted it.
<plars> xnox: the 5% doesn't come into play until you format though, I'm talking about the partitioner saying it can only do 813MB of the 1G disk
<plars> hmm, maybe that's it, let me see what it gives me
<balloons> xnox, trying to file that bug.. I found two more
<balloons> yikes
<xnox> balloons: i will read them in my bug-mail tomorrow morning with coffee
<xnox> ;-)
<balloons> :-) technically one is apport related, the other is almost certainly only apport
<xnox> lol
<doko> infinity, do you understand https://launchpadlibrarian.net/115821556/buildlog_ubuntu-quantal-armhf.binutils_2.22.90.20120913-1ubuntu1_FAILEDTOBUILD.txt.gz ?
<balloons> cjwatson, so the new grub2 package - -where all is it going to propagate to (image wise?)? Will I need to manually upgrade myself, or will I be automatically upgraded?
<Laney> hmm
<Laney> the china images I respun earlier didn't get pushed to http://china-images.ubuntu.com/quantal/daily-live/
<Laney> ah
<Laney> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-chinese-edition/quantal/daily-live-20120913.1.log
<doko> rtg, slangasek: new binutils now pubished for amd64, i386. still building on the other archs. afk now
<Laney> seems it needs to download from ubuntu-zh_CN/
<slangasek> doko: thanks for the fix :)
<Laney> cjwatson: ^ looks like UBUNTU_DEFAULTS_LOCALE doesn't make it through somehow
<infinity> doko: Dunno.  Cosmic rays, or lamont messing with things.
<doko> infinity, context? otoh lamont is good enought as an excuse ;-P
<infinity> doko: Context being that lamont's been upgrading Pandas to precise today, and ain was on that list.
<Laney> oh, /that's/ what it was
 * Laney yays
<infinity> doko: So, it's entirely possibly that what appeared to be file corruption was just external influence.
<infinity> doko: Then again, still could have been cosmic rays and a random bit flip. ;)
<doko> good to know
<lamont> infinity: ain was down for several weeks before finally getting a fresh install today
<lamont> infinity: that was the bad burn when we were testing pxeboot
<infinity> lamont: Oh, right.  Well, no idea what doko's buildus interruptus was, but no big deal.
<lamont> well, I did toss 5 others through the chomper this morning, since we were messing with PB01
#ubuntu-release 2012-09-14
 * infinity wonders idly why sru-report exploded...
<knome> hey skaet
<skaet> hiya knome
<infinity> cjwatson: Did you want to verify bug #1038961 at some point, so we can release those apt updates?
<ubot2> Launchpad bug 1038961 in apt "Maximum override line length is too short" [High,Fix committed] https://launchpad.net/bugs/1038961
<ScottK> Right.  That one.
<cjwatson> plars: the README advises on specific things that should be measured in order to adjust the lowmem thresholds in d-i
<cjwatson> balloons: pretty much everywhere, and it will be automatically upgraded
<cjwatson> Laney: hmm.  probably a regression from python rewrite / private branch merge.  thanks, I'll have a look
<cjwatson> infinity: I'd love to verify that bug but haven't had time yet.  I have a to-do item for it ...
<ogra_> cjwatson, seems our current kernel and initrd dont boot in 64M (there were some ltsp people testing with 64M clients, they seem to not have enough ram left to mount /)
<cjwatson> Laney: ah - regression due to the awkward config kludge that's in place to mediate between shell and python during the transition.  I've updated the whitelist so it should work now; retrying
<cjwatson> ogra_: lovely :-/
<cjwatson> Laney: yeah, that's working now
<Laney> cjwatson: good news
<Laney> cjwatson: now bad news, I have a grub rescue prompt :-)
<cjwatson> on upgrade?
<cjwatson> https://www.gnu.org/software/grub/manual/grub.html#GRUB-only-offers-a-rescue-shell
<cjwatson> follow that and then get me a bug report :)
<Laney> yep
<Laney> will do
<cjwatson> gosh, apparently no other bug reports about grub 2.00 yet
<Laney> popey reported that he got a rescue shell in #-uk
<Laney> not sure if that turned into a bug
<popey> it didnt
<popey> i have two disks in this machine, may be user error
<cjwatson> most grub bugs with multiple disks are user error :)
<cjwatson> sudo debconf-show grub-pc
<ogra_> so change the user !
 * xnox is lucky with lvm & using stable device-mapper names to actually boot ;-)
<popey> cjwatson, http://paste.ubuntu.com/1204374
<xnox> even after resizing and splicing my LUKS partition in half everything just worked =) grub2.00 win =)
<popey> i have 12.04 on one partition and 12.10 on another
<cjwatson> popey: now check whether /dev/disk/by-id/ata-SAMSUNG_HD103SI_S1VSJ90B701831 actually corresponds to the disk you're booting from
<cjwatson> popey: on multiple-disk machines I normally advise installing GRUB to the MBRs of all the disks to avoid confusion
<popey> cjwatson, well, i had to change the boot order in bios to make it boot
<cjwatson> excellent sign of user error, yes :)
<popey> :)
<Laney> heh
<cjwatson> sudo dpkg-reconfigure grub-pc
<popey> it doesnt offer which disks to install onto
<cjwatson> continue through all the other prompts, and select the MBRs of all non-removable disks when prompted for where to install GRUB
<cjwatson> err
<cjwatson> sudo DEBCONF_DEBUG=developer dpkg-reconfigure grub-pc
<popey> still doesnt
<cjwatson> I didn't say it would
<cjwatson> but it should provide a debugging trace
<popey> ah :D
<cjwatson> (if a command with extra debugging changes behaviour, that would be a surprise in itself!)
<popey> http://paste.ubuntu.com/1204378
<cjwatson> odd.  let me clear out a few other things and then have a proper look
<popey> ta
<Laney> what should the prefix be?
<Laney> (something)/boot/grub?
<cjwatson> on my system it's (hd0,msdos5)/boot/grub.  you can tab-complete the first bit
<cjwatson> (well, or any of it really)
<Laney> "file not found"
<Laney> a possibly pertinent piece of information is that this is a macbook pro (with rEFIt)
<cjwatson> oh, of course, you can't tab-complete while the prefix is busted
<cjwatson> should still be possible to set a correct one though - you might have to guess
<cjwatson> 'ls' should work I think
<Laney> (hd0,gpt4) is the only one that doesn't give me unknown filesystem
<Laney> and that is file not found
<cjwatson> hmm
<cjwatson> might be worth reinstalling grub from a live image as per my mail to -devel, and debugging from there
<Laney> ok
<cjwatson> oh, heh, core.img moved
<cjwatson> popey: this'll involve a new upload to fix up dpkg-reconfigure - can you manage in the interim?
<popey> yeah, its fine
 * xnox was on the safe side and manually run grub-install & --recheck a few times before rebooting...
<ogra_> we should just all switch to u-boot :)
<cjwatson> :-P
<ogra_> standardize on one bootloader across all arches etc *grin*
<Laney> gah
<Laney> error: can't find command 'linux'\nerror:  can't find command 'initrd' (today's daily)
 * Laney retreats to b1
<cjwatson> eh, after doing what with today's daily?
<Laney> "Try Ubuntu without installing"
<cjwatson> tf
<cjwatson> wtf
<cjwatson> afaik that grub image hasn't even been rebuilt against 2.00
 * cjwatson hates life
<Laney> GNU GRUB version 2.00-3ubuntu1
<cjwatson> patch piloting today is not obviously happening
<Laney> could it be me?
<cjwatson> oh, d-i was rebuilt, just not by me :)
<cjwatson> ok, so maybe that makes a degree of sense
<cjwatson> b1 good idea for now but clearly I need to fix that urgentlyl
 * cjwatson moves his pilot shift to Monday
 * Laney is suddenly glad for 100mbit internet
<Laney> hahaha oh dear
<Laney> I have some horrible broken lightdm greeter on b1 instead of a desktop
<ogra_> fun
<Laney> it's a sign
<Laney> to get a new laptop
<Laney> cjwatson: ok, looks like I was installing to a partition. After downgrading and installing 1.99 properly, it upgraded fine.
<cjwatson> hm, ok; seems a bit non-ideal though
<cjwatson> installing to a partition is fairly common among Mac users
<cjwatson> how big is /boot/grub/i386-pc/core.img
<cjwatson> ?
<Laney> when it was broken I was getting errors that grub-install couldn't find that
<Laney> let's see
<cjwatson> would be easier to see all the errors than to play twenty questions, then :)
<Laney> didn't record it all, I'm afraid
<Laney> but that one was:
<Laney> # grub-install /dev/sda
<Laney> source_dir doesn't exist. Please specify --target or --directory
<Laney> core.img is 26393
<cjwatson> uname -m, and does /sys/firmware/efi exist?
<Laney> x86_64, and no it doesn't
<cjwatson> might you have been booted in EFI mode when you previously ran grub-install?
<Laney> however now yopu mention
<Laney> yes
<Laney> that was the option offered to me
<cjwatson> looks like the current grub-install uses the x86_64-efi platform if booted in EFI mode
<cjwatson> which seems kind of sane
<cjwatson> but if you only have grub-pc installed then that won't work
<cjwatson> option offered> when booting an image you mean, or something else?
<Laney> yes
<Laney> it presented the USB drive as "EFI device" or something like that
<cjwatson> usually dual-capable BIOSes offer both
<cjwatson> but who knows about insane Macs
<Laney> perhaps there is a way
<Laney> anyway it's a separate issue to the initial problem
<cjwatson> so maybe grub-install needs to fall back to i386-pc if x86_64-efi isn't installed
<cjwatson> yeah, but the more confusion I can fix the better
<Laney> I wonder if OSX still boots
<xnox> well rEFIt should have offered both options: bios & PC boot.....
<cjwatson> bios *is* PC boot, I hope
<cjwatson> ym efi and pc boot?
<xnox> yes efi & PC boot
<xnox> rEFIt often is confused on grub upgrade, especially if you manage to install it on both sda & sda4
<xnox> e.g. partition and mbr. One will work while the other one will always give a fizzy fit.
<Laney> It offers to boot "Legacy OS", but it doesn't work. Just boots from the hard drive.
<Laney> and Mac OS does still work. happy days
<cjwatson> I suspect legacy OS just chainloads the MBR or something
<Laney> I don't know what it does, but it's only there when the USB drive is present
<Laney> hm, is it intentional that the grub menu has no timeout now?
<cjwatson> No
<cjwatson> But are you testing in kvm here?
<Laney> no, the mac
<cjwatson> Dunno then
<cjwatson> Bug me
<Laney> let me check I didn't accidently press a key
<Laney> ah, it was recordfail
<cjwatson> oh, by no timeout you mean "sits there" not "boots without waiting"
<cjwatson> yeah, likely recordfail
<Mirv> release team ack/no-ack needed still regarding Unity 6.6 for bugs #713423 #1043915 and #876017
<ubot2> Launchpad bug 713423 in unity "[FFe/UIFe] Unity launcher gets cluttered when having multiple partitions and/or external volumes attached" [Medium,Confirmed] https://launchpad.net/bugs/713423
<highvoltage> hello
<psivaa> cjwatson, when i run ubuntu-bug grub2, the pop-up window says grub2(not installed)! is this an expected behaviour?
<cjwatson> I expect it's true
<cjwatson> grub2 is a transitional package - you probably have either grub-pc or grub-efi-amd64 installed, depending on details of the platform
<cjwatson> grub-pc => BIOS, grub-efi-amd64 => UEFI
<psivaa> ahh ok, grub-pc is the one on mine, thanks
<knome> stgraber, hey. we need UIFe for bug 1049658, and possibly need you to update the translations and do some magic.
<ubot2> Launchpad bug 1049658 in ubiquity-slideshow-ubuntu "[Xubuntu] Office slide needs to be updated" [Undecided,New] https://launchpad.net/bugs/1049658
<stgraber> knome: granted
<stgraber> knome: please push to lp:ubiquity-slideshow-ubuntu
<knome> stgraber, i will, just a sec
<knome> urgh, diverged branches
<knome> stgraber, should be done now
<mterry> Friendly poke about bug 1049231 and friends
<ubot2> Launchpad bug 1049231 in unity-greeter "[UIFe] The gap between the user name and password entry is too large in the greeter" [Undecided,New] https://launchpad.net/bugs/1049231
<knome> stgraber, will you take care of the rest?
<stgraber> knome: yep, just waiting on an update from highvoltage as we might also want to bundle an update to the edubuntu slideshow. Once I know more I'll update the translations and upload.
<knome> stgraber, ok, thanks a lot :)
<jamespage> iulian, is there anything I can do to help unblock bug 1043654 ?
<ubot2> Launchpad bug 1043654 in zentyal-samba "[FFe] New version of zentyal-samba" [High,Confirmed] https://launchpad.net/bugs/1043654
<iulian> jamespage: Oh that one. I shall have another look at it in a few moments. I haven't been satisfied with the information provided so far.
<iulian> What's it doing in precise-proposed?
<iulian> Argh.
<jamespage> iulian, different bug
<iulian> Oh I see.
<iulian> zentyal is poorly maintained at the moment I must say. It'd be nice if bencer could take more care of it.
<bencer> iulian: why do you think is poorly maintained?
<iulian> bencer: Because of the issue we've got now.
<bencer> iulian: i think is explained in the issue, we didn't reach the freeze with the package ready
<bencer> and we were focused on upstream bugfixing rather than uploading broken ubuntu packages
<bencer> now packages are ready
<bencer> i don't see the problem uploading now
<bencer> seriously, blocking this only makes having a broken package status
<bencer> instead of allowing to upload a new package which is compatible with the other ones already in the archive
<iulian> bencer: I was having comment #10, paragraph 2 in my mind when I said that. You were supposed to test the packages before uploading to the archive.
<iulian> But that's not important now. It's been done already.
<bencer> iulian: yes, i know, the upload was a bit messy, you are right
<bencer> but was also my first upload, i didnt make everything perfect first time, i've realized about my mistakes there
<jamespage> iulian, zentyal has certainly suffered over the last few releases, but bencer is trying to step up to make things better
<jamespage> but he is new to alot of the processes - how can we move this forwards?
<iulian> jamespage: Very happy to hear that. I've just approved it now.
<jamespage> iulian, much appreciated
<iulian> I hope it doesn't break anything else. There are loads of new features in there.
<bencer> just to confirm, we can upload new packages containing *only bugfixes* without ffe and until the final freeze, right?
<bencer> thanks a lot iulian & jamespage
<tumbleweed> bencer: yes
<iulian> bencer: Correct.
<bencer> ok, one more question
<bencer> these latest packages 2.3.x packages containing only bugfixes
<bencer> have been renamed to 3.0
<tumbleweed> the version isn't important, it's the content
<bencer> when we released the stable yesterday, should be okey to upload the packages with  the 3.0 version number, or we should stick to 2.3?
<bencer> ok, cool, then going to upload the ones approved on this ffe, and i will upload the new 3.0 after that, before the final freeze
<bencer> thanks everybody!
<iulian> bencer: That's fine. Make sure to update your Depends as well. :)
<bencer> sure
<tumbleweed> bencer: it usually makes sense to close the bug from the upload
<bencer> tumbleweed: yup, just i got aware of that
<bencer> going to close manually and i will take that in account in the future
<mterry> skaet, could I get a look at UIFe bug 1049231?
<ubot2> Launchpad bug 1049231 in unity-greeter "[UIFe] The gap between the user name and password entry is too large in the greeter" [Undecided,New] https://launchpad.net/bugs/1049231
<micahg> skaet: Bug #1044657 probably should've been highlighted in teh release meeting but wasn't
<ScottK> Is there any way we could expedite getting the fix for Bug #1044657 uploaded?  It's blocking switching Kubuntu back to LO by default.
<ubot2> Launchpad bug 1044657 in libreoffice "[regression] Missing LO menus when not run in Unity" [High,Fix committed] https://launchpad.net/bugs/1044657
<infinity> micahg: It probably needs to be hilighted to Sweetshark more than the release meeting.
<infinity> micahg: (As in, if he preps an upload, I'll happily review and sponsor it)
<ScottK> I guess the problem is he broke LO and then went on vacation.
 * micahg forgot about the revert regressions rule, so apparently there's some process breakdown
<ScottK> So it's left broken and I guess based on the fix committed status there's an option to move forward, but we ought to move forward or back.
<infinity> If I could find this mysterious commit that supposedly fixes it, I'd JFDI.
<ScottK> That would be lovely.
<infinity> Oh, he was referencing an upstream commit.
<infinity> Curious.
<ScottK> Yeah.  http://www.mail-archive.com/libreoffice@lists.freedesktop.org/msg39638.html
 * infinity nods.
 * ScottK refers infinity back to his previous JFDI comment ...
<infinity> But.  But.  Birthday weekend!
<infinity> Oh, sweet merciful spaghetti monster.  Never visit someone with slow internet, never visit someone with slow internet...
<TheLordOfTime> lol
<infinity> Or never download LibO sources.
<skaet> lol
<stgraber> highvoltage, knome: ubiquity-slideshow-ubuntu uploaded (xubuntu changes, edubuntu changes and translation update)
<jbicha> micahg: except that the previous LibreOffice was unusable too :( bug 1041354
<ubot2> Launchpad bug 1041354 in libreoffice "unity-panel-service uses ~100% CPU when libreoffice-gtk is installed and enabled" [High,Fix released] https://launchpad.net/bugs/1041354
<highvoltage> stgraber: awesome
<infinity> jbicha: Yeah, I think the only way forward here is forward.
<jbicha> lol
<infinity> jbicha: Say, do you want to sort out this mess with the upstream unitymenus stuff? ;)
<infinity> My guess, based on the next commit being "Fixed crashes when executing some menu actions", is that we just want to be using the "latest upstream" for this particular bit, not cherrypicking fixes.
<jbicha> infinity: no, good luck finding someone to do it though :)
<infinity> Hrmph.
<infinity> I'll just do it in the background.  It's all download/compile/upload for hours/days anyway, there's no actual WORK.
<infinity> Just lots and lots of waiting.
<infinity> And cursing.
<Laney> heh
<Laney> IIUC there's a branch for the menus stuff, so it should be possible to just take head of that, yeah.
<infinity> Laney: Yeah, I'm slowly working on that.
<infinity> Or, rather, my computer is, I'm not doing much to help.
<highvoltage> compiling!
<infinity> Downloading.  Not as cool as compiling.
<highvoltage> ah
<Laney> someone needs the cloud!
<infinity> Oh, that's a fair point.  I could be doing this elsewhere.
<infinity> Derp.
#ubuntu-release 2012-09-15
<ScottK> He almost had it right.
#ubuntu-release 2012-09-16
<ScottK> quantal-desktop-armhf+omap is still showing up on http://cdimage.ubuntu.com/kubuntu/daily-live/current/.  It's stale since July, so someone who can should probably remove it.
<infinity> ScottK: Can do.
<infinity> ScottK: Images removed.  Not going to bother to update indexes, it'll self-solve the next build/.
<doko> infinity, gcc-4.7 failed to build for the third time in a row (running the tests), without leaving any error log. do you know what happens?
<infinity> doko: Ugh.  That would be lp-buildd timing out.
<infinity> doko: I'll talk to wgrant about seeing what we can do. :/
<TheLordOfTime> 12.10 is under freeze right?
<TheLordOfTime> that includes new packages for main/universe/multiverse?
<stgraber> the whole archive is feature frozen
<TheLordOfTime> i assume then that an exception would need to be issued for even a new package?
<stgraber> yes
<TheLordOfTime> (with a likelihood  of that being near zero)
<stgraber> it's not unlikely that a freeze exception would be granted if the package isn't intended to get on one of the media and won't conflict with anything existing in the archive
#ubuntu-release 2013-09-09
<pkern> tzdata in precise is ancient. ):
<Laney> pkern: marga is going to do the update it seems
<Laney> you both pointed it out at the same time
<seb128> pkern, we are discussing it on #ubuntu-desktop
<Laney> should be more on top of that though
 * Laney looks for an announce list
<pkern> Laney: Yeah, we're in the same room. ;)
<Laney> heh
<seb128> ok, tzdata updates sponsored
<seb128> if somebody of the SRU team could review those today ^
<seb128> it fixes bug #1222345
<ubot2`> Launchpad bug 1222345 in tzdata (Ubuntu Raring) "Wrong DST dates in Israel" [High,In progress] https://launchpad.net/bugs/1222345
<seb128> infinity, cjwatson, slangasek, stgraber, bdmurray, ScottK, RAOF, Daviey: ^ (sorry for the direct ping but precise to raring are currently buggy, dst ended up when it shouldn't have)
<pkern> lucid is as buggy, fwiw.
<Laney> yeah, should be done too
<seb128> right, added that one to the list, marga is going to do it as well, thanks for pointing it out
<ScottK> seb128: I can look at it in probably half an hour or so.
<seb128> ScottK, thanks
<ScottK> seb128: The precise upload looks like it was supposed to be the one for lucid based on version and debian/changelog entries that got dropped.
<ScottK> tzdata (2013d-0ubuntu0.10.04) precise; urgency=low
<seb128> ScottK, shrug, thanks, indeed (well, there was 2 uploads to precise, rejecting the buggy one)
<seb128> ScottK, done, only the correct one is left in the precise queue
<ScottK> Found the good one.  Much better.
<ScottK> seb128: Are you doing lucid too?
<seb128> ScottK, yes, I'm going to reupload that buggy one with the correct changelog target, thanks for catching it
<zul> can i get an archive admin to review dogpile.cache and dogpile.core in binary-new, keystone is pretty broken without them (https://bugs.launchpad.net/ubuntu/+bug/1222802)
<ubot2`> Launchpad bug 1222802 in Ubuntu "FFE: dogpile.core and dogpile.cache" [Undecided,New]
<infinity> seb128: Thanks for the tzdata stuff, I was actually going to do that today.
<xnox> infinity: any opinions on executing bug #1213463
<ubot2`> Launchpad bug 1213463 in groundcontrol (Ubuntu) "Please remove bzr-gtk source and binary from saucy" [Undecided,Confirmed] https://launchpad.net/bugs/1213463
<infinity> xnox: It leaves a sour taste in my mouth that we're not willing to maintain it, but meh.  Happy to remove it if it has no rdeps.
<xnox> infinity: well, there is groundcontrol that does lp.net screenscraping (which probably also suffered from bit-rot)
<infinity> Yeah, I'm seeing that.
<xnox> infinity: imho, it's more important to get the maintainance release of bzr into the archive though with all the bugfixes it has accumulated.
<xnox> infinity: but you do know how liberal my approaches to removals are ;-)
<infinity> xnox: As a general rule, I prefer not to remove packages but, in this case, it'll either push someone to fix them, or they'll just disappear.  Meh.
<ScottK> seb128: All in.  Thanks.
<seb128> ScottK, thanks for the reviews!
<seb128> ScottK, infinity: can we get those copied to updates before a week if we get the verification done?
<ScottK> Yes.
<xnox> infinity: i've raised the issue with jelmer, and he said should be removed.
<infinity> Absolutely.
<infinity> xnox: I already removed them.
<xnox> \o/
<infinity> Oh man, someone accepted code-of-conduct-signing-assistant?
<infinity> Fun...
<ScottK> pkern: What time is it supposed to be in Israel right now?
<Laney> google tells me 16:34
<ScottK> Thanks.
<ScottK> Quantal works.
<ScottK> err Raring
<xnox> the bug will start in 3 weeks time...
<ScottK> Oh.
<ScottK> Right.
<Laney> https://wiki.ubuntu.com/StableReleaseUpdates#tzdata
<Laney> that tells you how to verify tzdata srus
<seb128> ScottK, https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1222345/comments/16
<ubot2`> Launchpad bug 1222345 in tzdata (Ubuntu Raring) "Wrong DST dates in Israel" [High,Fix committed]
<ScottK> Laney: Thanks.
<ScottK> seb128: Thanks.  I read that and then forgot about it.
<ScottK> OK, verified that correctly and it's right.
<seb128> excellent!
<ScottK> precise is good too.
<rsalveti> slangasek: ScottK: sorry if someone asked this already, but would you mind checking bug 1220588 (FFe)? we're trying to land the gst-plugins-bad support for touch (using the hardware decoders from android) this week, and for that we'd need gst 1.1.4
<ubot2`> Launchpad bug 1220588 in gstreamer1.0 (Ubuntu) "[FFe] Update GStreamer stack to 1.1.4" [Undecided,New] https://launchpad.net/bugs/1220588
<infinity> rsalveti: Approved.  Please close the bug once it's all uploaded.
<rsalveti> infinity: awesome, thanks!
<rsalveti> Laney: ^
<Laney> ty
<Laney> rsalveti: If you've time you can upload/sync what's in the PPA except for libav
<Laney> rsalveti: Otherwise I'll get to it tomorrow
<rsalveti> Laney: sure
<Laney> Would be good for jhodapp's stuff to turn up quite soon, btw
<rsalveti> Laney: yeah, that's what we want to get going this week (we're in a sprint in lexington atm)
 * Laney nods
<Laney> rsalveti: did the hybris fix come in?
<jbicha> Laney: it looks like the Ubuntu GNOME iso cronjob is still disabled?
<Laney> is it?
<Laney> lemme see
<Laney> yes, yes it is
<Laney> fixed
<seb128> ScottK, thanks a lot of helping on those tzdata SRUs!
<ScottK> You're welcome.
<Laney> jbicha: in time for your spin today, so I'll let it happen automatically
<ScottK> I just released p - r.  I forgot to mash accept on Lucid, so I'll test/release that once it's published.
<zul> infinity: ping https://bugs.launchpad.net/ubuntu/+bug/1222802
<ubot2`> Launchpad bug 1222802 in Ubuntu "FFE: python-dogpile.core and python-dogpile.cache" [Undecided,New]
<infinity> zul: Can you fix the things mterry pointed out and reupload?
<zul> infinity: sure
<infinity> I'll do a quick NEW review here.
<infinity> zul: Can you replace the unicode Â¨ in debian/control with the ascii " instead too?
<infinity> zul: Not sure if that'll cause any issues in any packaging frontends, but it's a bit nonstandard.
<zul> in dogpile.cache?
<infinity> zul: cache has the weird quotes in the long/short description, core has inconsistent quoting in its descriptions.
<zul> infinity: k fixed locally
<ScottK> Lucid's tested and released, so tzdata emergency is over.
<ScottK> pkern (and marga): Thanks.
<superm1> could someone help me understand why the mythtv upload from a few days ago hasn't migrated out of proposed?
<Laney> superm1: did you check http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html ?
<superm1> ah no, didn't know about it.  so it's because armhf and powerpc failed
<superm1> i'm not really sure how to go about fixing either of those though
<cjwatson> Are they basically permanent build failures?
<pkern> ScottK: I wonder why tzdata is not monitored more actively. But that's no question for you. ;)
<pkern> ScottK: Thanks for acting that quickly.
<ScottK> You're welcome.
<cjwatson> powerpc looks easily enough fixable by including <byteswap.h>
<ScottK> I suspect the answer is pitti used to do it and no one picked it up when he switched positions.
<superm1> cjwatson: ah i'm happy to try that and see if it improves things (and kick it upstream if so)
<superm1> i don't think armhf is a permanent build failure either
<cjwatson> I don't know where QGLContext comes from OTTOMH but doesn't seem horribly difficult to look for
<cjwatson> mythtv has enough reverse-dependencies that I do think it'd be better to tidy up properly if possible
<infinity> The armhf failure is probably a GL/GLES confusion.
<zul> can an archive admin review python-troveclient please  https://bugs.launchpad.net/ubuntu/+bug/1221981
<ubot2`> Launchpad bug 1221981 in Ubuntu "[FFe] [needs-packaging] New package python-troveclient" [Wishlist,Triaged]
<infinity> zul: Is that also going to main, or just universe initially?
<zul> thats going into main again
<zul> ill get adam_g to follow up with mterry
<seb128> could somebody force chromium-browser in?
<seb128> update_excuse has "autopkgtest for chromium-browser 29.0.1547.65-0ubuntu1: FAIL (Jenkins: public, private) "
<seb128> but seems those tests have never been green
<Laney> If you file a bug and about them and assign it to qengho ;-)
<qengho> noooooo!!!!
<qengho> Ah, alright.
<seb128> lol
<Laney> we shouldn't be happy with tests that never pass
<seb128> nobody is happy about those I think
<qengho> I should disable them until I have time to work them out.  I thought the simple tests would be a good starting point, and not cause problems.
<xnox> well, I thought it's an achievement to get it build on armhf as it is =)
<xnox> qengho: only if they finish with: 2>&1 || true
<Laney> hrhr
<seb128> Laney, qengho: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1222895
<ubot2`> Launchpad bug 1222895 in chromium-browser (Ubuntu) "the autopkgtests need to be fixed" [High,Confirmed]
<Laney> merci monsieur
<seb128> de rien ;-)
<qengho> seb128: "Thanks."
<seb128> qengho, you're welcome :p
<Laney> k, hinted in
<seb128> thanks
<qengho> I should work on my french with this team. It's the only other language I have more than a few hundred words of in my head, and I never get to use it.
<qengho> ...which means it's probably down to far less than a few hundred now.
<cjwatson> infinity: are you doing the weekly release mumble from lex?
<infinity> cjwatson: I... Hrm... Maybe if I can find a room.
<infinity> Let me see.
<slangasek> infinity: no more bzr-gtk?!  sadness
<infinity> slangasek: Yeah, it's really hurting my feelings.
<infinity> (die, die, die)
<slangasek> :(
<infinity> slangasek: You're welcome to fix it.
<sil2100> infinity: hello! By any chance, were you able to take a look at the XIM SRU bits for nux/unity raring? Sorry for being so annoying about that ;)
<zul> what does "xxx has no binaries on any arch " mean?
<cjwatson> zul: Didn't build anywhere, usually
<zul> cjwatson:  launchpad is complaning about "Some binary packages for this source are not yet published in the repository"
<cjwatson> what package?
<zul> python-dogpile.cache
<cjwatson> binary NEW
<cjwatson> processed now
<zul> cool thanks
<zul> cjwatson:  can check python-lesscpy as well please?
<cjwatson> zul: what's to check?  it's in saucy
<zul> cjwatson:  arrgh ok sorry about that
<cjwatson> np
<slangasek> infinity: bzr-gtk is so fragile I can't even get bzr merge-upstream to work on it, so yeah, guess I'm not saving it.
<superm1> the armhf failure seems resolvable for now at least by turning off VAAPI for that build until upstream can sort it out, but PPC isn't just a matter of including byteswap.h, it's already actually done and that code hasn't changed AFAICT since last successful build.  maybe toolchain changes have caused this behavior i'm wondering
<smoser> hey all.
<smoser> release team question.
<smoser> openstack havana will release same day as ubuntu 13.10 (october 17).
<smoser> so we're guaranteed to have a zero day sru for openstack components (at least in version-name).
<smoser> i'm wondering what the correct path is to make the release / SRU team aware of this, as we want to ship SRU to 13.10 as soon as possible after tarballs arrive for openstack havana
<stgraber> just upload to saucy-proposed as soon as you have the packages ready
<stgraber> anything in there usually gets turned into a 0-day SRU on release day (after we cleanup anything in there that failed to migrate to saucy before release)
<stgraber> so you're likely to have the new openstack in -proposed at release time (or very shortly after) and into -updates after the usual SRU validation process
<smoser> stgraber, well, can i / should i open place holder bugs ?
<smoser> and i'd kind of like uber-fast-path in possibly unlikely case that these are simple release renames.
<stgraber> smoser: yes, it's going to be a standard SRU as far as validation is concerned, so the same workflow applies there
<stgraber> smoser: getting it released early is possible and will be up to the SRU team, if the diffs only show a simple version change, I think that'd be reasonable
<smoser> yeah. ok. so i suspct at some point i will open SRU bugs for 13.10. probably sooner than later.
<smoser> just to have those ready to fill in with additional information.
<rtg> xnox, I uploaded linux-meta-goldfish if you would be so kind as to NEW it when it appears in the queue.
<ogra_> infinity, (or cjwatson) could one of you take a look why autopilot doesnt seem to migrate out of proposed ? the excuses page says "Valid Candidate", while there is a dep-wait on ppc (but thats there longer already and former uploads odf autopilot seem to have migrated nontheless)
<infinity> ogra_: There's no dep-wait on powerpc.  It builds on PPC and is uninstallable.
<infinity> ogra_: libautopilot-qt was upgraded from a recommends to a depends, and it's not available on PPC.
<infinity> ogra_: So, if that dependency is true, autopilot-touch shouldn't be built on PPC.
<ogra_> infinity, well, it seems to hold back autopilot, not autopilot-touch
<ogra_> https://launchpad.net/ubuntu/+source/autopilot-qt/1.3+13.10.20130814-0ubuntu1/+build/4875820
<ogra_> (and https://launchpad.net/ubuntu/saucy/+source/autopilot/1.3.1+13.10.20130906.1-0ubuntu1 for autopilot itself)
<ogra_> oh, ignore that :P
<ogra_> (indeed it also holds back -touch, but also all other binaries)
<zul> can someone get python-troveclient out of binary-new please?
<zul> its pending publication
<infinity> ogra_: Yeah, sources move as a whole. :P
<ogra_> infinity, i forwarded the info to doanac ... he owns autopilot
<ScottK> Keep the old one and reject the new one?
<ScottK> And that one rejected the old and kept the new.
<ScottK> Surely one of those is wrong.
#ubuntu-release 2013-09-10
<cjwatson> Could somebody binary-NEW gradle so that I can get it out of the proposed-migration lists?  I rebootstrapped it yesterday.
<cjwatson> Oh, wait, somebody did that yesterday.  Never mind.
<sil2100> cjwatson: hello! Sorry to poke you about that already, but any luck with getting d-i migrated and the new images rebuilt?
<cjwatson> sil2100: It's just waiting for an autopkgtest at this point, as far as I can see
<cjwatson> http://10.98.0.1:8080/view/Saucy/view/AutoPkgTest/job/saucy-adt-linux/97/ARCH=amd64,label=adt/console
<cjwatson> I'm keeping an eye on it but would rather let the test run to completion
<sil2100> cjwatson: right, thanks! Let's wait for it to complete then
<cjwatson> Also http://10.98.0.1:8080/view/Saucy/view/AutoPkgTest/job/saucy-adt-linux/ARCH=i386,label=adt/97/console
 * cjwatson goes for breakfast rather than compulsively staring at the running test
 * czajkowski hands cjwatson a bacon butty and a bucket of tea
<jibel> sil2100, I upgraded manually the kernel to 3.11.0-6 on the test machines for the daily-release. Tests should be running again.  They will just take more time because the containers will be upgraded on each run.
<sil2100> jibel: \o/ That's awesome!
<jibel> sil2100, seb128 tests are back to green with the new kernel. end of incident
<sil2100> jibel: that's a relief, thanks guys!
<zul> hi can i get neutron-vpn-agent and neutron-metering-agent out of the queue (they are new binaries introduced with the neutron upload) https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1223342
<ubot2`> Launchpad bug 1223342 in neutron (Ubuntu) "[FFE] neutron-vpn-agent and neutron-metering-agent" [Undecided,New]
<Laney> That FFe isn't granted
<rtg> xnox, linux-meta-goldfish is still in NEW
<infinity> rtg: I can poke at that.
<rtg> infinity, thanks
<infinity> rtg: No tools?
<rtg> infinity, uh, can't remember. lemme check.
<infinity> rtg: Well, there's no tools metapackage, at any rate. :P
<infinity> rtg: There's a tools package generated from linux-goldfish.
<rtg> infinity, right, I'm trying to remember if the goldfish kernel _has_ tools. I might not have done them yet
<infinity> https://launchpad.net/ubuntu/saucy/+package/linux-goldfish-tools-3.4.0-0
<rtg> too many freaking android kernels...
<infinity> apw: Did all that tools renaming business happen yet?
 * infinity suspects not.
<infinity> Anyhow, whatever...
<apw> infinity, heh no, i have that branch sitting here to pull up to the tip and commit
<infinity> rtg: Accepting it anyway, you can add tools bits later.
<apw> infinity, once i have this cve-autotriage die
<apw> done i'll get it freshened
<rtg> infinity, likely manta has the same issue. I guess I just never noticed.
<apw> rtg, i think we need to get this all sorted together, i have the master fixes which are a pre-req so it makes sense for me to marshall the lot together
<rtg> apw, do you have it written down somewheres so I can wrap my head around it ?
<rtg> apw, shall I wait on fixing the meta packages ? It appears at least 2 of the Nexus kernel meta packages don't have a tools binary
<infinity> rtg: The others have the tools meta with the "wrong" name anyway, as we'd previously discussed, so may as well wait on Andy's stuff.
<rtg> infinity, you and apw may have talked about it, but I don't know the details.
<infinity> I think you were involved initially, and then he and I whiteboarded it during some sprint or other.
<rtg> I'll go patch some kernels or something for a bit
<infinity> He might have a photo. :)
<apw> infinity, yeah that rings a bell, but the commit has the naming in the commentary thankfully
<jibel> cjwatson, neutron tests fails because python-jsonrpclib is uninstallable. Britney correctly identified this issue but requested a test anyway, would you know why?
<jibel> python-jsonrpclib  is not in the archive
<rsalveti> didrocks: mind checking libhybris? package split to move the media library in it's own package, so we can make the gst-plugins-bad package depend on just libmedia, instead of bringing the entire hybris
<didrocks> rsalveti: sure, let me have a look
<rsalveti> didrocks: awesome, thanks
<didrocks> rsalveti: don't get used to it, remember that normally I'm in European time :p
<rsalveti> didrocks: I know, but I can do a hard ping here :P
<didrocks> heh ;)
<didrocks> rsalveti: libmedia1 deps on libhybris-common1 without any version, is that wanted?
<didrocks> (libhybris-common1 is a weird name btw, but I guess there is a rationale)
<rsalveti> didrocks: yup
<rsalveti> didrocks: yeah, that's the linker basically
<rsalveti> our custom and common linker
<didrocks> ah ok ;)
<didrocks> rsalveti: approved then, you need those in main I guess?
<didrocks> (the rest of the source is in main)
<rsalveti> didrocks: yeah
<rsalveti> didrocks: thanks
<didrocks> yw ;) button pushed
<rsalveti> awesome
<didrocks> infinity: around? it seems we have a deletion in the ppa for 30 minutes that's still not deleted (the other archs are)
<cjwatson> which ppa
<cjwatson> ?
<didrocks> cjwatson: ~ubuntu-unity/daily-build
<didrocks> cjwatson: shouldn't you sleep btw? ;)
<cjwatson> and which package?
<cjwatson> I plan to soon
<didrocks> platform-api
<cjwatson> I'm not seeing platform-api anywhere - where are you seeing it?
<cyphermox> cjwatson: http://ppa.launchpad.net/ubuntu-unity/daily-build/ubuntu/dists/saucy/main/binary-armhf/Packages
<didrocks> cjwatson: it seems to still be published on armhf $
<didrocks> ^
<didrocks> (it disappeared as it should on the other archs)
<cjwatson> oh, it mustn't have fully loaded
<cjwatson> one sec while I investigate
<didrocks> thanks ;)
<cjwatson> so, you hit a race, you deleted the source in between the armhf binary being accepted and it being published
<didrocks> argh, so we could have wait forever :)
<cjwatson> the fix is to delete it again
<didrocks> oh ok
<cyphermox> alright, doing now
<cjwatson> you probably won't have UI for it, but you can use the API
<cjwatson> $ lp-shell production devel
<cjwatson> >>> lp.load("/~ubuntu-unity/+archive/daily-build/+sourcepub/3478225").requestDeletion(removal_comment="re-deleting due to binary publication race")
<cyphermox> it was still there..
<cjwatson> or remove-package from lp:ubuntu-archive-tools
<cjwatson> ok
<cyphermox> yup, got removed, though I had the remove-pacakge command ready
<cjwatson> good
<cyphermox> cjwatson: thanks, have a good night :)
<didrocks> stgraber: around? we'll need in some time someone who knows how to trigger a phone image build
<stgraber> didrocks: I'm going out now to buy some food but I should be back in < 1 hour and can trigger a build then
<didrocks> stgraber: it will take more than an hour anyway, take your time!
<didrocks> thanks
#ubuntu-release 2013-09-11
<kees> this time with bugs! :)
<infinity> It's sendmail, does it ever not have bugs?
<kees> infinity: har har, I menat this time I'm uploading a -proposed package with actual LP bugs linked :)
<kees> I actually worked with upstream to fix one of them. they were extremely helpful, actually.
<infinity> Not my fault you meant the wrong thing.  I interpreted correctly.
<kees> :)
<didrocks> stgraber: still alive? :)
<stgraber> didrocks: yep
<didrocks> stgraber: infinity is wondering which image is the real touch image
<didrocks> meaning the unflipped one
<didrocks> or flipped
<didrocks> too tired to think
<didrocks> the one we care about :)
<stgraber> the only one listed in the crontab? :)
<stgraber> 02 8,20 * * *   for-project ubuntu-touch cron.daily-preinstalled --live
<stgraber> the other touch entry clearly says system-image and that's the hourly importer script, so if you want a new image, just run what I pasted above and it'll automatically get imported to system-image next time that cron hits (every :01)
<stgraber> ah, well, looks like infinity figured it out before I said that on IRC (looking at the timestamp on nusakan), so I guess I'm done for tonight
<smartboyhw> Laney, see latest comment on the bug. But now I'm wondering if I need a FFe, the commits look more like bugfixes-.-
<Laney> always good to check what the changes are first
<smartboyhw> Laney, so, you going to approve my FFe, or it shouldn't have been a FFe at all?
<Laney> don't know, haven't looked again
<Laney> will do in a bit unless somebody else does first
<smartboyhw> Laney, OK
<didrocks> cjwatson: hey, are you still around?
<seb128> didrocks, not sure what you need but you might be able to grab infinity in lexington
<didrocks> seb128: already asked, he doesn't have access to those logs
<seb128> k
<didrocks> the binary copy doesn't work
<didrocks> we are screwed
<didrocks> asac will kill all of us
<slangasek> what are you binary copying?  (not that I have any access)
<seb128> didrocks, it's surprising that infinity doesn't have access ... is that a launchpad thing?
<seb128> would wgrant or StevenK have access?
<infinity> It's a log host I've just never asked for access to.  I should get some.
<infinity> I'd also need to sort out which log I'd need to look at. :P
<infinity> But the first step is to actually try to do some copies manually and see if they break.
<infinity> Cause if not, I blame cup2whateverthingee
<cjwatson> infinity: You really should get carob access.  It's very handy.
<cjwatson> unity-mir 0.1+13.10.20130911.1-0ubuntu1 in saucy (Cannot copy DDEBs to a primary archive)
<cjwatson> appears to have been the problem, FWIW
<cjwatson> infinity: (Plus, if you had carob duty, we'd have coverage in all timezones, when you're on NA time.)
<cjwatson> s/carob duty/carob access/  # not sure where that came from
#ubuntu-release 2013-09-12
<cjwatson> ddebs> Ah, now that I catch up on one of the sysadmin channels I see it was handled there.
<slangasek> stgraber: you have bug #1181789 assigned to yourself for raring; do you still mean to follow through on it
<ubot2`> Launchpad bug 1181789 in upstart (Ubuntu Raring) "second call of 'initctl start' leads to fork instead of exec ('mount: / is busy' during shutdown)" [Critical,Triaged] https://launchpad.net/bugs/1181789
<slangasek> ?
<infinity> cjwatson: Agreed on carobness.  However I go about that.
<stgraber> slangasek: ah yeah, I suppose I should SRU that.
<stgraber> slangasek: it's one of those tasks I opened because the bug is bad and really should be SRUed, but AFAIK nobody other than me reported it on raring so it's not very pressing.
<slangasek> stgraber: no, there were lots of other reports of this issue in raring (see the now-duped bug); if you're not going to SRU it, please tell me and I'll take care of it.
<xnox> slangasek: stgraber: we should push out raring sru with all the fixes that needed to go in. as far as I remember raring sru never validated.
<cjwatson> infinity: According to RT#53566 you should actually have carob access already ...
<cjwatson> infinity: As in, it's supposed to be based on ubuntu_archive group membership, which you have
<xnox> Which kylin seeds are authoritative? lp:~ubuntukylin-members/ubuntukylin/ubuntukylin-meta or lp:~ubuntukylin-members/ubuntu-seeds/ubuntukylin.saucy ?
<smartboyhw> xnox, I heard that seeds will be used at 14.04 LTS
<smartboyhw> So, probably the first link
<smartboyhw> (For Kylin)
<cjwatson> I sincerely hope it's the second
<cjwatson> Maintaining metapackages by hand in bzr is daft
<smartboyhw> I actually questioned them before
<xnox> cjwatson: both have recentish commits =/
<cjwatson> Send them to me, I can supply clue on these matters :)
<xnox> cjwatson: i guess they do maintain something for their precise spins.
<infinity> cjwatson: Ahh, well, then maybe I just need to figure out what that means and use it. :P
<infinity> cjwatson: I do indeed have access to the machine.
<cjwatson> infinity: Logs are in /srv/launchpad.net-logs/production/<blah>
<cjwatson> infinity: You may want to lift ~cjwatson/bin/rtail (which I cargo-culted from wgrant, in turn)
<cjwatson> infinity: Stuff in /home/archvsync/scripts/ shows where the logs are rsynced from, in cases where you can't wait for the regular rsyncs
<infinity> cjwatson: Shiny.  This should prove handy.
<cjwatson> The copy logs from yesterday were in production/ackee/launchpad/celeryd-production_launchpad_job.log*
<cjwatson> And of course you'll probably like production/alphecca/buildd-manager.log*
<infinity> Very tempted to symlink alpaca to alphecca.
<cjwatson> It's owned by archvsync, you can't :P
<cjwatson> Though I guess you have a homedir
<tumbleweed> what needs to be kicked to get ncbi-tools6 to migrate? It's complaining about libvibrant6 being out of date, but I don't see that in Packages
<cjwatson> Oh, I think last time I looked at that it was proposed-internal NBS
<cjwatson> Let me have a poke
<tumbleweed> I'd understand libvibrant6a being NBS, but libvibrant6 is long gone
 * tumbleweed has no idea what proposed-internal NBS means :P
<cjwatson> So
<cjwatson> We track not-built-from-source (NBS) binaries in saucy
<cjwatson> http://people.canonical.com/~ubuntu-archive/nbs.html
<tumbleweed> yes
<cjwatson> And if a binary is in saucy but not in saucy-proposed, proposed-migration assumes that the NBS binaries are removed when deciding whether the source can be migrated
<tumbleweed> right
<cjwatson> But, there is a corner case here
<cjwatson> Let's say we have version 1 in saucy, version 2 in saucy-proposed which never migrated, and now version 3 in saucy-proposed which is trying to migrate
<cjwatson> If version 2 built a binary not in version 3, we don't track that
<cjwatson> So the binary needs to be checked by hand and removed from saucy-proposed
<tumbleweed> ah, that's possibly the case here
<cjwatson> It's basically an awkward side-effect of -proposed being a partial suite
<cjwatson> It's exactly the case here
<cjwatson> ncbi-tools6 | 6.1.20120620-2 | saucy/universe | source
<cjwatson> ncbi-tools6 | 6.1.20120620-5 | saucy-proposed/universe | source
<cjwatson> libvibrant6 | 6.1.20120620-3 | saucy-proposed/universe | amd64, armhf, i386, powerpc
<cjwatson> libvibrant6-dbg | 6.1.20120620-3 | saucy-proposed/universe | amd64, armhf, i386, powerpc
<tumbleweed> aah, libvibrant6 was never removed from -proposed
<tumbleweed> that makes sense
<cjwatson> Exactly
<cjwatson> Just checking for rdepends now
<cjwatson> tumbleweed: removed, thanks
<tumbleweed> cjwatson: thank you
<stgraber> slangasek,xnox: oh, apparently I'm not subscribed to bugs for the upstart package in Ubuntu, that'd explain why I didn't see any bug trafic.
<stgraber> slangasek: I believe at the time we had an SRU in proposed so that's why I didn't upload it directly, though I see that's no longer the case, so I'll at least push the cherry-pick to the branch and update the bug with a testcase (not sure if it has the SRU headers already)
<xnox> right. and we might be missing a few other bug-fixes on the SRU that should go in.
<cjwatson> stgraber: ^-
<stgraber> looking
<stgraber> cjwatson: there you go ^
<infinity> cjwatson: Want to add any-ppc64el to debian/control upstream so we don't forget later?
<infinity> cjwatson: Hrm, and any-x32 ... How did no one complain about that yet?
<infinity> I suppose I have commit, don't I.  Maybe I'll do that.
<infinity> Not a branch: "bzr+ssh://bzr.debian.org/bzr/pkg-grub/branches/2.00/"
<cjwatson> Uh, are you sure upstream configure would handle that?
<infinity> grump.
<cjwatson> bzr+ssh://bzr.debian.org/bzr/pkg-grub/trunk/grub/
<infinity> cjwatson: Oh, fair point on the ppc64el thing, might need to check.  (Though, it should work with a sufficiently new config.{sub,guess})
<infinity> cjwatson: But I'm confused that no one's complained about the missing x32...
<cjwatson> Anyway it needs a bit more than a control tweak - there'll be stuff in rules and files in debian/ too.
<infinity> Yeah, so I'm seeing upon a grep.
<infinity> I'll poke it $later, it's certainly not urgent.
<cjwatson> I can do it nowish.
<infinity> For 14.04, I need to make some time to see if I can switch to grub2 on all yaboot subarches.
<infinity> I certainly don't want to bring up any new PPC ports with yaboot.
<cjwatson> What's x32 in config.{guess,sub} speak?
<infinity> x86_64-linux-gnux32
<infinity> I believe.
<cjwatson> infinity: Actually, I've uncommitted my ppc64el change.  This needs actual build-testing first, because configure.ac does need to be updated.
<infinity> cjwatson: Yeah, hence my "$later" thing.
<cjwatson> Ditto I'd really rather be able to see whether x32 works first.
<infinity> cjwatson: Yeah, don't worry about it.  It was an observation in passing when I saw the arches in .dsc
<infinity> cjwatson: x32 doesn't matter deeply to me, but I can test it in Debian sometime.  And ppc64el, I'll argue with it when we have a port.
<infinity> (The latter will definitely happen due to my previously-mentioned not wanting to have another yaboot port)
<cjwatson> It's probably just a matter of powerpc64-* -> powerpc64-*|powerpc64le-* and similar in configure
<infinity> Probably.
<cjwatson> Oh, heck, it might be more than that, maybe the ELF relocator needs porting
<infinity> And x32 might be a zero issue thing, since it's x86_64, and the ILP32 part doesn't factor in for the bootloader bit, just for the userspace tools.
<cjwatson> Yeah, just install it via multiarch
<cjwatson> Might be nice to build it though
 * infinity nods.
<cjwatson> Wouldn't be too surprising to find a wrong type size somewhere though
<slangasek> stgraber: yes, 1.8-0ubuntu1.2 had a regression, bug #1199778; so we should get a re-SRU... :)
<ubot2`> Launchpad bug 1199778 in upstart (Ubuntu Raring) "upstart crashes if re-exec'ed with active chroot sessions" [Undecided,New] https://launchpad.net/bugs/1199778
<stgraber> slangasek: ok, if I push the bugfix for the restart bug to the branch and update the bug report with the SRU paperwork, can you or xnox take it from there?
<xnox> ok, by me.
<slangasek> stgraber: yes
<slangasek> stgraber, cjwatson: so I'm happy to see that bug #1187233 is indeed resolved in saucy with the new shim-signed, which means it's time for me to start worrying about SRUs.  I'm considering that the best option might be: 1) pull back the gnu-efi source; 2) verify that all revdeps (including shim) build in precise with the updated gnu-efi; 3) pull back sbsigntool; 4) binary copy shim from saucy (so we don't have to submit a new binary to 
<ubot2`> Launchpad bug 1187233 in OEM Priority Project "Grub2 fails on ASUS X201E with secure boot is enabled" [High,Confirmed] https://launchpad.net/bugs/1187233
<slangasek> ... reupload shim-signed, with the build-deps adjusted for sbsigntool
<slangasek> does that sound reasonable / possible?
<cjwatson> Yeah, unless you think you can figure out a gnu-efi backport
<infinity> Does your sbsigntool alignment fix also apply to kernel signing?  Should we make sure the new version is on ftpmaster?
<infinity> We've had this discussion, I think.  Was the concensus just "meh, wait until ftpmaster is upgraded to precise"?
<cjwatson> Not sure what the timescale on that's going to be.  Might be better to push to lucid-cat.
<slangasek> infinity: we don't care about the sbsigntool alignment except in the case where we're trying to reproduce the MS-signed output
<slangasek> the current sbsigntool already produces perfectly valid signed objects that work fine
<slangasek> so yes, I don't care about pushing this back to lucid-cat
<infinity> Mmkay, so it's not producing buggy output, per se, just slightly weird output?
<slangasek> not even weird, just not identical to MS
 * infinity nods.
<infinity> Though, "identical to MS" seems like what you want for SB stuff.
<slangasek> cjwatson: "does anyone feel desperately that we have to keep this or shall I just go ahead and drop it" - surely those are not mutually exclusive!
<cjwatson> maybe not well-phrased :)
<stgraber> xnox: is lp:~ubuntu-core-dev/ubuntu/raring/upstart/raring the right branch to use for the upstart raring SRU?
<xnox> stgraber: yes, it is.
<stgraber> cjwatson: did you upload grub2-signed? I can't remember seeing it on saucy-changes
<cjwatson> Oh, no, I'll go and do that now
<tjaalton> could someone have a look at glamor-egl in NEW, phoronix is making fun of us still not supporting 3d on newest radeons..
<tjaalton> it was uploaded before FF
<tjaalton> (barely=
<tjaalton> )
<cjwatson> stgraber: done
<barry> hi folks.  i have one package that entered new before ff (nose2) and two packages i submitted ffe's on (pip and virtualenv).  i don't mean to be a noodge (and will happily wait patiently) but i just want to make sure they aren't waiting on something from me.
<rsalveti> in case someone has the time to review another FFe :-), bug 1224665
<ubot2`> Launchpad bug 1224665 in gst-plugins-bad1.0 (Ubuntu) "[FFe] Android media support over hybris for gst-plugins-bad1.0" [Undecided,New] https://launchpad.net/bugs/1224665
<rsalveti> needed for touch to have hardware decode & rendering support in gstreamer, using the android video hal (over libgstagefright)
<Laney> rsalveti: what is [i386 armhf] about?
<rsalveti> Laney: it uses hybris (android), so it can only be tested in i386 and armhf because we only have android devices for those archs
<rsalveti> that's why I didn't enable it for all archs
<Laney> sorry, got to leave - no time to review
<Laney> but what would the harm be in building it everywhere it can? (seems that means !ppc)
 * Laney leaves it for others
<rsalveti> Laney: wouldn't cause any harm I guess, but I know it could only work i386 and armhf as of now
<infinity> I'm fine with the arch restriction for now.
#ubuntu-release 2013-09-13
<barry> slangasek: LP: #1223483 is back in New (and any thoughts on LP: #1223001)?
<ubot2`> Launchpad bug 1223483 in python-virtualenv (Ubuntu) "[FFe] sync 1.10.1 from Debian" [Undecided,New] https://launchpad.net/bugs/1223483
<ubot2`> Launchpad bug 1223001 in python-pip (Ubuntu) "[FFe] sync python-pip 1.4.1 from debian" [Undecided,New] https://launchpad.net/bugs/1223001
<rbasak> https://wiki.ubuntu.com/FreezeExceptionProcess says that "we expect requesters to have an updated package already prepared and tested!", but AIUI recently we have been asked to request FFes as early as possible, and it's useful to get an ack before doing the work. Is the documentation still accurate?
<slangasek> barry: sorry, hadn't gotten to 1223001 yet, spent all last night arguing with the Debian upstart update :)
<barry> slangasek: i hope you won! :)
<slangasek> rbasak: I think that's always been fuzzy
<slangasek> barry: except for the part where I'm now blocked by a libnih upstream change :)
<barry> ouch ;)
<utlemming> slangasek: we have a critical SRU for Cloud-init for Windows Azure. See https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1224684
<ubot2`> Launchpad bug 1224684 in cloud-init (Ubuntu Precise) "[SRU] cannot sudo, prompted for password on 12.04 Windows Azure" [Critical,Confirmed]
<utlemming> slagasek: any chance we could fast track this?
<slangasek> utlemming: I imagine so.  is it uploaded?
<slangasek> I see that it is
<utlemming> slangasek: just going to say it was :)
<rbasak> slangasek: thanks. I'll prepare one.
<slangasek> utlemming: so what makes this an Azure-specific issue?
<utlemming> slangasek: if you look at the code, it is in the data-source.
<utlemming> slangasek: I validated that the impact is only on Azure
<slangasek> utlemming: ok.  put differently, why is this not handled in a common codepath?
<utlemming> slangasek: ah, simply because user creation is only done for Azure on 12.04. The default user on 12.04 is built by the build system, but for Windows Azure the default cloud user is not applicable.
<slangasek> ah, interesting
<slangasek> ok, accepted into -proposed
<utlemming> slangasek: most appreciated
<thomi> Hello release team, could I ask someone to ack this FFE please? https://bugs.launchpad.net/autopilot/+bug/1212833
<ubot2`> Launchpad bug 1212833 in Autopilot "[FFE] Add support for launching click packages" [Critical,In progress]
<thomi> cjwatson: I wonder if you could take a look at that? It's kind of important for the touch guys... or maybe tell me who I can poke?
<infinity> thomi: Approved, close the bug(s) when you upload, please.
<thomi> infinity: will do, thanks
<roaksoax> could someone please reject djorm-ext-pgarray from precise-proposed. I mistakenly uploaded it :(
<roaksoax> ery much appreciated
<infinity> roaksoax: Done.
<roaksoax> infinity: awesome thank you
<bdmurray> On a saucy cd .disk/info still says Alpha
<infinity> bdmurray: Well, some of us haven't had a beta release yet. :)
<bdmurray> infinity: oh yeah, that's a good point I guess
<stgraber> balloons: was the milestone still marked as testing?
<adam_g> does a new debian merge require a FFe if the upstream version doesn't change?
<slangasek> adam_g: if you're merging new features, yes.  If you're merging bugfixes, no.
<infinity> adam_g: It's the same basic rules as an SRU or security update, or any similar conservative policy.
<infinity> adam_g: If it's just bugfixes, go to town.  If it changes/removes/adds behaviour, you need an FFe.
<adam_g> infinity,  http://paste.ubuntu.com/6103024/  is the log of upload in question. looks like it should have one filed
<infinity> adam_g: That looks potentially scary, yes.  Also, did you mean to rename the source package? :P
<infinity> adam_g: An FFe bug with a debdiff from 2.02.98-1ubuntu5 to 2.02.98-6ubuntu1 for easy reviewing would be nice.  I'd like to unwind some of those changelog entries and see what they actually do.
<adam_g> infinity, oh dont worry there are very descriptive bugs corresponding to them, ie http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712049
<ubot2`> Debian bug 712049 in lvm2 "lvm2 - udev monitor sync stuff is still racey" [Serious,Fixed]
<adam_g> infinity, not sure what you mean wrt source package renaming?
<infinity> adam_g: Your changelog entry has s/lvm2/lvm1/ :P
<adam_g> uhm
<adam_g> im blaming pastebin
<stgraber> I'm going to force LXC through as https://jenkins.qa.ubuntu.com/job/saucy-adt-lxc/45/ARCH=i386,label=adt/ failed because of some kind of archive race
<stgraber> (same on amd64 succeeded)
<Laney> I retriggered it
<Laney> don't think p-m will notice that though
<jbicha> Laney: if you're here, can you mark Beta 1 as released on the iso tracker?
<Laney> oh yeah
<Laney> I didn't do that because of something to do with cloud images
<Laney> but I think they did that
<utlemming> Laney: ?
<utlemming> Laney: there supposed to be marked as ready, and they were released
<Laney> it's fine
<infinity> rsalveti: Yay for multiarching libeeze out of the box, boo for missing the multi-arch headers in debian/control.
<infinity> rsalveti: Please fix on the next upload.
<Laney> Oh what, someone else did it
<Laney> I hauled myself up and got a 2fa device and everything
#ubuntu-release 2013-09-14
<jbicha> you can kill nemo-fileroller from the new queue as it's already been synced from debian
<rsalveti> infinity: sure, thanks
<jbicha> http://extras.ubuntu.com/ubuntu/dists/ is missing the devel>saucy symlink that the other official apt repos have
<cjwatson> jbicha: Yeah, I know, but I may need to redo the implementation of devel anyway (you get warnings from apt if you actually try to use it), so I'm not worrying about completing coverage just yet.
<stgraber> cjwatson: I saw the apt warnings here when testing it too, though I assumed we'd change apt to ignore those rather than change the implementation to generate new Release files
<stgraber> cjwatson: doing the latter will make it harder to revert from devel to whatever's the current release since the plan there was to look for the series name in Release
<stgraber> cjwatson: (unless we can easily add a new entry in Release to tell us what the real series is)
<jbicha> ScottK: could you maybe look at bug 1092719 since Laney's out for a few days?
<ubot2`> Launchpad bug 1092719 in gnome-disk-utility (Ubuntu) "FFe: Update gnome-disk-utility to 3.8" [Wishlist,Confirmed] https://launchpad.net/bugs/1092719
#ubuntu-release 2014-09-08
<cjwatson> After mass give-back on ppc64el: 240 failed, 300 dep-wait (from 275/322).  Not bad
<zul> hi can i get an ubuntu-archive admin ack for FFE for python-hurry.filesize (#1365652), python-xstatic-angular-cookies (#1365647),
<zul> python-xstatic-jquery-ui (#1365645), python-xstatic-angular-mock (#1365641),
<zul> python-xstatic-jquery.quicksearch (#1365639) python-xstatic-bootstrap-datepicker (#1365632) they are straight syncs from debian which is needed for horizon
<rbasak> Can someone process percona-* in Utopic NEW please? We've had them in there since feature freeze.
<gaughen> slangasek, cjwatson, infinity would  you pretty please help with rbasak's request above?  infinity feel free to tell him rbasak that he needs to submit his core application in order for you to push them through ;-)
<cjwatson> just about to go for dinner here
<rbasak> It's not today-urgent, but has been languishing for a while. Percona (upstream) are keen to see it land.
<rbasak> (they worked very hard with us to make feature freeze)
<slangasek> having a look
<slangasek> Pre-Depends: multiarch-support, ${misc:Pre-Depends}
<slangasek> rbasak: ^^ multiarch-support should not be hard-coded here
<slangasek> percona-server-client-5.6, what a package name :)
<slangasek> rbasak: why is percona-server-common-5.6 a package at all?  It appears to be empty and just depends on mysql-common
<rbasak> jamespage, georgelorch: ^^
 * rbasak hasn't actually touched this package at all.
<slangasek> jamespage, georgelorch: debian/rules on percona-server-5.6 is a real mess; do you know that dh_install is never called, and therefore debian/libperconaserverclient18.1.install and debian/percona-server-test-5.6.install are never looked at?  (Instead, the package is using dh_movefiles, which has been deprecated upstream for at least 5 years)
<jamespage> georgelorch, are you OK to respond to slangasek's feedback please?
<jamespage> slangasek, sorry - at a sprint this week - will try to respond as much as I can
<rcj> Did libapt-pkg-dev=1.0.1ubuntu2.2 for trusty get stuck in proposed?  libapt-pkg4.12=1.0.1ubuntu2.2 was released and an install of libapt-pkg-dev on trusty breaks
<rcj> stgraber, infinity ^
<rcj> To install libapt-pkg-dev I first have to downgrade apt on the Trusty daily image.
<rcj> Which is breaking deploy of juju-gui with trusty daily images.
<slangasek> georgelorch: debian/percona-server-client-5.6.{dirs,docs} are empty and should not exist; debian/percona-server-client-5.6.lintian-overrides is overriding things which are outstanding problems with the package, please don't do this - lintian-overrides should only be used to suppress wrong warnings from lintian
<slangasek> georgelorch: likewise, debian/percona-server-common-5.6.lintian-overrides is overriding a real issue (namely, that the package appears to serve no purpose and should not exist, in favor of depending directly on mysql-common)
<slangasek> georgelorch: debian/percona-server-server-5.6.lintian-overrides: is lintian really reporting "possible bashisms" in a script that has #!/bin/bash?  that should be fixed in lintian
<georgelorch> jamespage, slangasek, yes I can address these issues. Re: percona-server-common, there was some history there that either predated my involvement or I've long since forgotten why it was added. IIRC the Maria DB package has the same thing so could also be a possibility that it has same issue. So do these need to be addressed immediately or can they wait for another product release as we have some upstream updates coming
<georgelorch>  soon?
<slangasek> georgelorch: percona-server-common, the right point to address binary packages that should not exist is at archive accept time
<georgelorch> ok slangasek, I will take care of these and submit another build for rbasak to upload.
<slangasek> georgelorch: this one is also a no-go: percona-server-server-5.6: statically-linked-binary ./usr/sbin/mysqld
<slangasek> binaries mustn't be statically linked against libraries from other packages
<slangasek> (which at a minimum includes libc)
<georgelorch> slangasek, IIRC that is not something that can be easily fixed as it requires changes to upstream Percona Server build process and also exists in other packages (MariaDB 5.5)
<georgelorch> specifically it is the static link of libmysqlclient (libperconaserverclient)
 * georgelorch is trying to remember details of things that were decided months ago
<slangasek> $ file /tmp/mariadb/usr/sbin/mysqld
<slangasek> /tmp/mariadb/usr/sbin/mysqld: ELF 32-bit LSB shared object, Intel 80386, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x7212f597c46b0b2952a61215a252f745a070ce6b, stripped
<slangasek> georgelorch: ^^ that's mariadb; it is not statically linked
<slangasek> perhaps it's also not statically linked in percona-server-server-5.6 either - I'm only looking at the lintian overrides, not the output of a build
<georgelorch> slangasek, ahh, they must have fixed it since last I looked at this error
<slangasek> but it is always wrong to override such lintian errors
<georgelorch> slangasek, jamespage put it to me like this, if it is an upstream product/build issue, then an override is appropriate until it can be fixed by upstream. If it is an override due to lazy packaging, well, then, it needs to be fixed.  We do have bugs filed against Percona Server for all overrides.
<georgelorch> btw slangasek, I do appreciate very much the feedback
<slangasek> georgelorch: well, I disagree quite strongly with that; being an upstream build/product issue does not excuse hiding said issue
<georgelorch> slangasek, as I understand it, the intention is not to hide the issue, but to allow the package to pass through various automation when there are known issues with upstream. if you are telling me that all of these must be addressed before it can be accepted, well then I guess I need to go back to the drawing board w/ jamespage and rbasak to try and get things fixed accordingly.
<slangasek> georgelorch: I don't know what automation that would refer to, but any automation that encourages maintainers to suppress legitimate lintian errors with overrides is broken
<slangasek> a lintian override should be used only when the maintainer determines that the lintian error is a false positive
<slangasek> it should not be used to suppress useful information about the status of the package with respect to archive policy
<georgelorch> ahh slangasek, that is certainly a bit different than what I have come to understand, thanks for the clarification
<georgelorch> slangasek, just to be clear, the fact that the issues exist is obviously something we need to address, but your primary objection is to the overrides correct? Meaning that the package _could_ be accepted with some of the existing issues (upstream) as long as they weren't hidden by the lintian-overrides. Or, are you saying that all issues need addressing, packages must pass lintian 100% and no overrides at all before yo
<georgelorch> u will accept the packages?
<slangasek> georgelorch: I'm saying that the messages need to not be suppressed with lintian overrides. Whether fixing the issues would be a blocker for inclusion in the archive would be taken on a case-by-case basis; I would probably consider the static linking one a blocker to be fixed, but it sounds like it's already been fixed
<georgelorch> ack slangasek, thanks for the clarification again...the static linking IIRC would be the most difficult to fix but you may be correct in that it has been fixed and we simply never removed the override
<jdstrand> infinity: hi! would you mind looking at the FFe for bug #1362199?
<ubot93> bug 1362199 in apparmor-easyprof-ubuntu (Ubuntu) "[FFe] apparmor abstract, anonymous and netlink socket mediation" [Critical,In progress] https://launchpad.net/bugs/1362199
<jdstrand> infinity: for now, just need to approve the userspace bits. they are well-tested on generic and touch kernels
<jdstrand> infinity: (the kernel bits will come later this week)
<jdstrand> infinity: this feature is required for touch, but benefits server in particular
<infinity> jdstrand: Hrm.  apparmor FFes seem to be becoming a pattern.  Should I get someone from the security team to explain to you why last-minute changes are harder to support than mature code? ;)
<jdstrand> infinity: this is much less last minite than the last one :)
<infinity> jdstrand: :)
<infinity> jdstrand: Will give it a read in a bit.
<jdstrand> infinity: but, this is the last 'we can't ship without this feature' apparmor feature for touch
<jdstrand> infinity: thanks
<Saviq> hey, can someone please have a look at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity8
<Saviq> it says the two adt runs regressed due to unsatisfiable dependencies, but doesn't say which?
<kgunn> asac: in case you check in who would be good to see about unity8 being stuck ^
<kgunn> someone in US timezone maybe...or an aussie
<infinity> Saviq: Looking.
<Saviq> infinity, thanks
<asac> kgunn: yeah you found the right channel here. in ci-eng slangasek and folks can also help. robru should also know who to talk to in such cases etc.
<kgunn> ta
<mattgriffin> gaughen, slangasek thanks for the packaging feedback for my colleague georgelorch
<cjwatson> rcj: "rmadison libapt-pkg4.12" disagrees that 1.0.1ubuntu2.2 was released; it is only in trusty-proposed
<infinity> Saviq: Still around?
<infinity> Saviq: I wonder if this might not be adt freaking out about something on stderr during dependency installation.
<infinity> Setting up usermetricsservice:amd64 (1.1.1+14.10.20140908-0ubuntu1) ...
<infinity> method return sender=org.freedesktop.DBus -> dest=:1.7 reply_serial=2
<infinity> ^-- That looks suspiciously weird.
<infinity>    uint32 1
<Saviq> infinity, that didn't change though, was there in previous successful runs, too
<infinity> Saviq: I don't see that output on a previous successful run.
<Saviq> infinity, https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-qtcreator-plugin-ubuntu/236/ARCH=amd64,label=adt/console
<infinity> Oh, or I'm blind.
<Saviq> infinity, it's no question that that looks suspicious, as that means it's calling dbus in post-install, which is probably not the best thing to do, but doesn't seem to be the reason
<infinity> Right, looking harder.
<infinity> Aaand, can't reproduce.
<infinity> This might need someone with more familiarity with the adt infra to debug (like pitti or jibel)
<jdstrand> infinity: fyi, I'm going to step away for a bit, but will be back later. if you have questions, feel free to leave them in backscroll or ask tyhicks/sbeattie about the userspace and jjohansen about the kernel
<jdstrand> infinity: (I am of course referring to the apparmor FFe)
<infinity> jdstrand: Yeah, I was JUST about to ask about the wording here.
<infinity> "When used with a compatible kernel, 'unix' and 'network netlink' rules are supported. When used without a compatible apparmor userspace (eg, on a trusty system with an utopic backport kernel), abstract, anonymous and fine-grained netlink socket mediation is not enforced (ie, you can use this userspace with an old kernel without any issues)."
<jdstrand> ok, I can wait on stepping away if you are looking at it
<infinity> jdstrand: That implies new kernel and old userspace are fine, but the last bracketed thing says the opposite.
<infinity> jdstrand: Obviously, both are desired, but it's a bit muddy about that. :P
<jdstrand> infinity: it is meant to convery that a new userspace and kernel is fine, a new userspace and old kernel is fine, and an old userspace and new kernel is fine
<jdstrand> convey*
<jdstrand> that is how we roll
<jdstrand> :)
<infinity> jdstrand: Right.  As long as all three combinations are well-tested, I'm cool with this in theory.
<jdstrand> seriosuly though-- if I get the ack, I need to land the userspace with an old kernel. that is well tested. we are aware of lts kernels so a new kernel will work with an old userspace, and of course we want the new kernel to work with the new userspace. we are finalizing the kernel bits, tbut the userspace is ready
<jdstrand> all combinations are tested. the first is ready to land now. we have more testing on the latter two, and will of course have that done when we do the pull request
<infinity> jdstrand: Commented on the bug.
<jdstrand> infinity: ok, I commented. I forgot the Breaks bit this time. thanks for the reminder
 * jdstrand fixes
#ubuntu-release 2014-09-09
<jamespage> slangasek, for reference the review I did of ps-5.6 was based alot on comparison with the mysql-5.* packaging, as that is the common ancestor
<jamespage> slangasek, thankyou for your review and feedback as well - I've looked at alot of mysql packaging for the different variantin the last month and have probably become a little blind to some of the legacy niggles in the packaging
<Saviq> jibel_, hey, could you please have a look at the unity8 stuck in proposed http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity8
<jibel_> Saviq, looking
<Saviq> jibel_, the adt runs complain about missing test dependencies, but don't mention which
<Saviq> jibel_, I wonder if it was something intermittent
<jibel_> Saviq, http://paste.ubuntu.com/8297482/ shows which deps are blocking. I'm checking why.
<jibel_> Saviq, pitti already retried the jobs less than 2 hours ago
<Saviq> jibel_, oh ok :|
<jibel_> Saviq, there is a problem with the version of liboxideqt-qmlplugin
<jibel_> Saviq, The following packages have unmet dependencies:
<jibel_>  webapp-container : Depends: liboxideqt-qmlplugin (>= 1.2.0) but 1.2.0~bzr683-0ubuntu1 is to be installed
<jibel_> Saviq, and
<jibel_> The following packages have unmet dependencies:
<jibel_>  ubuntu-system-settings-online-accounts : Depends: liboxideqt-qmlplugin (>= 1.2.0) but 1.2.0~bzr683-0ubuntu1 is to be installed
<jibel_> E: Unable to correct problems, you have held broken packages.
<Saviq> jibel_, right https://launchpad.net/ubuntu/+source/webbrowser-app/0.23+14.10.20140908-0ubuntu1
<Saviq> and https://launchpad.net/ubuntu/+source/ubuntu-system-settings-online-accounts/0.4+14.10.20140908-0ubuntu1
<Saviq> jibel_, it looks like they miss ~ in that dependency, as there's no oxide-qt on the horizon
<jibel_> Saviq, right, the ~ in the version of liboxide available in the repo makes it inferior to 1.2.0
<Saviq> jibel_, they come from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-002
<Saviq> that's dbarth's silo, trying to find out what's going on then
<Saviq> jibel_, on another topic, did you see the "dash fails to start" yesterday? I was unable to reproduce on two devices, different images...
<Saviq> when it was there, I was getting it all the time, now I have not seen it whole day yesterday when flashing/testing and then when explicitly tried to repro
<jibel_> Saviq, not recently and I reboot the device several times a day. any idea what could have *fixed* it?
<Saviq> jibel_, unfortunately not, I went back to rtm#17 when I'm sure it was happening and no more
<zul> cjwatson: hi can i get an ubuntu-archive admin ack for FFE for python-hurry.filesize (#1365652), python-xstatic-angular-cookies (#1365647),
<zul>  python-xstatic-jquery-ui (#1365645), python-xstatic-angular-mock (#1365641),
<zul> they are straight syncs from debian and is needed for horzon in openstack
<slangasek> jamespage: my pleasure :)
<jamespage> slangasek, I don't think their stuff is actually statically linked - but their overrides are foobar
<slangasek> right, that's my current understanding
<jamespage> slangasek, it has the normal embedded-library stuff that mysql insists on as well
<cjwatson> zul: should be fine, processing
<slangasek> right - that's a different set of overrides though
<zul> cjwatson: thanks
<jamespage> slangasek, indeed
<jamespage> slangasek, georgelorch is working on this now
<cyphermox_> could someone please have webbrowser-app re-tested in proposed? oxide-qt is now at the correct version, so I'd expect the autopkgtest for qtcreator-plugin-ubuntu to pass
<cyphermox_> I think ubuntu-system-settings-online-accounts could also be let in despite the missing dependency on liboxideqt-qmlplugin (>= 1.2.0) on powerpc,ppc64el, and arm64
<infinity> Ideally not.
<infinity> cyphermox_: If it depends on something that's not available on an arch, please don't build it on that arch, rather than making uninstallable counts go up.
<cyphermox_> infinity: I would tend to agree, but I'm getting to this conclusion in a complicated way
<cyphermox_> infinity: can you chime in on #ubuntu-ci-eng?
<cjwatson> cyphermox_: are you saying we should retry the qtcreator-plugin-ubuntu autopkgtest?
<cyphermox_> cjwatson: wait, no
<cyphermox_> let me look at this harder first
<cyphermox_> cjwatson: no, there's something wrong, but it will take me more time to figure it out; for now I need to brb
<cjwatson> I'm tempted to retry anyway on the basis that it can't hurt and the error is incomprehensible.  I can't reproduce the install failure with the packages that appear to be relevant in chdist.
<cjwatson> Certainly past the previous failure now.
<cjwatson> There, a pass
<cyphermox_> so it's not just me, the error was incomprehensible
<cyphermox_> cjwatson: thanks
#ubuntu-release 2014-09-10
<darkxst> hmm, I can't reproduce the tracker autopkgtest failure locally in adt-run, could someone give it a bump to try run tests again
<darkxst> hmm, I can't reproduce the tracker autopkgtest failure locally in adt-run, could someone give it a bump to try run tests again
<mlankhor1t> can someone accept fglrx-installer NEW in -proposed?
<LocutusOfBorg1> mlankhorst, do you think this change is not important for ubuntu?
<LocutusOfBorg1> http://anonscm.debian.org/cgit/pkg-xorg/xserver/xorg-server.git/commit/?id=21fe63a69724224c25c929199e1947accb3c3ca9
<LocutusOfBorg1> just wondering why of the upload of 1.16.0-1 instead of -2 (if I understand correctly)
<mlankhorst> I was waiting on doko's feedback at the time, then decided to upload anyway. but using -2 should be doable, package that depends on it is still in NEW. :P
<LocutusOfBorg1> :)
<LocutusOfBorg1> thanks
<mlankhorst> after the xorg transition I'll get around to it
<LocutusOfBorg1> thanks! :D
<mlankhorst> can xserver-xorg-video-sis and xf86-video-msm be removed from the archive? first one has been removed from debian, second one needs to be removed from debian still, debian bug 754221
<ubot2> Debian bug 754221 in xf86-video-msm "xf86-video-msm: FTBFS against xserver 1.16" [Serious,Open] http://bugs.debian.org/754221
<ubot93> Debian bug 754221 in xf86-video-msm "xf86-video-msm: FTBFS against xserver 1.16" [Serious,Open] http://bugs.debian.org/754221
<mlankhorst> if that's fixed I think that should be all for transitioning to work
<debfx> except virtualbox?
<mlankhorst> yeah I don't have rights for that
<mlankhorst> it needs a rebuild only bump
<debfx> mlankhorst: I'll take care of that
<mlankhorst> thanks
<cyphermox_> could someone please re-run the utopic-adt-network-manager test to unblock network-manager? seems like it failed on i386 only, but this is something I'm already aware of and requires fixes (in progress) in urfkill
<mlankhorst> oh can xserver-xorg-video-msm xserver-xorg-video-sis, glamor-egl and nvidia-173 be removed?
<mlankhorst> glamor-egl moved to xorg-server now, nvidia-173 is EOL'd by nvidia, -sis is removed by debian and -msm doesn't build in debian, will be replaced by freedreno
#ubuntu-release 2014-09-11
<mlankhorst> morning
<DalekSec> Hello.  samdump2 3.0.0-2 from Debian fixes the one in proposed.
<infinity> DalekSec: Thanks for the heads up, syncing.
<DalekSec> Thank you.
<hallyn> hi - if someone could take a look at / approve the libvirt FFE (bug 1367422), that'll finally enable apparmor-protected libvirt-lxc containers.
<ubot93> bug 1367422 in libvirt (Ubuntu) "[FFE] Upgrade to 1.2.8" [Undecided,New] https://launchpad.net/bugs/1367422
#ubuntu-release 2014-09-12
<Laney> cjwatson: thanks for fixing cdimage/kylin for me
<cjwatson> np
<lool> Hey, would someone mind giving back the autopkgtests for network-manager on i386: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-network-manager/lastBuild/?
<lool> they failed only on i386, and I suspect it's just racy
<lool> (passed on amd64)
<cjwatson> sure, let me just switch VPN
<cjwatson> I only know how to give them back on all arches
<cjwatson> hopefully that'll do
<Laney> was there an upload to fix it?
<Laney> ubuntu-devel chatter earlier suggested it was a real failure
<cjwatson> oh yes, indeed it did
<cjwatson> lool: so no, see #ubuntu-devel scrollback
<lool> ack, found the logs now; thanks
<ogra_> stgraber, we might want to promote an rtm image today ... iirc there was something with empty target channels i will have to regard ?
<stgraber> ogra_: can't think of any obvious problem with copying between 14.09-proposed and 14.09, let me know if something goes wrong
<ogra_> (rtm never had a promotion before)
<ogra_> stgraber, thanks, just wanted to make sure in advance
<zul> can someone figure out whats going on with python-oslo.utils, it is in main but there is no debs when i look at the archive for it
<slangasek> zul: rmadison shows that the binaries are all in universe, and http://people.canonical.com/~ubuntu-archive/component-mismatches.txt shows that there's nothing holding the source in main
<zul> slangasek: yeah its a new dependency of keystone
<zul> which currently ftbfs
<slangasek> zul: well, so worry about fixing the ftbfs, and when that's fixed component-mismatches will tell us to DTRT
<slangasek> until then, the source shouldn't have been promoted to main anyway, because now it just shows up on c-m going the wrong direction
<zul> slangasek: erm https://launchpad.net/ubuntu/+source/keystone/1:2014.2~b3-0ubuntu1/+build/6330454
<slangasek> zul: oh, well then
<slangasek> zul: yes, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt shows the correct info
<slangasek> (and when do we get python3 openstack? :)
<zul> slangasek: its being worked on :)
<Laney> I just realised that making the huge wallpapers package native might not have been the best idea
<Laney> will change that back soon. :-)
<Noskcaj> Can someone please look at https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1330037
<ubot93> Launchpad bug 1330037 in xfce4-settings (Ubuntu) "[SRU] upower 0.99.1 transition" [Undecided,In progress]
<stgraber> Noskcaj: why would you want to SRU that?
<Noskcaj> crap *FFe
 * Noskcaj quietly walks away
<Noskcaj> The only thing that isn't ready is ubuntu-system-settings, since it's patch needs a refresh
#ubuntu-release 2014-09-13
<ogra_> stgraber, is there something wrong with import-images ? there was a touch rootfs build about 1.5h ago and it was still not picked up
<ogra_> hmm, and it looks like the nightlies werent either
<ogra_> thats the utopic-proposed channel
<ogra_> hmm, seems like only krillin and mako are affected
#ubuntu-release 2015-09-08
<doko> Laney, or anybody else, please could you set up a transition tracker for ruby2.2? see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789077 for the ben file
<ubot93> Debian bug 789077 in release.debian.org "transition: ruby2.2" [Normal,Open]
<Laney> doko: I added you to the team, have fun :)
<doko> Laney, go away ;-P
<Laney> looks like there were some iterations to the file after the first post in that bug, probably get the one that was actually used
<Laney> is this a good idea after feature freeze?
<doko> Laney, this is just about *adding* 2.2 support, not making it a default. this is clean-up not made by the server team unfortunately
<Laney> doko: Is there a risk it introduces new build failures for example?
<Laney> I remember adding python 3.5 as supported :)
<doko> Laney, wasn't me who prepared that ;p
<doko> but seriously, this happens when people don't do this kind of work before the freeze
<Laney> Are you saying it's half done already?
<doko> looking at the debian tracker, yes. the outstanding things for debian were the libstdc++6 related packages
<Laney> In Ubuntu I mean
<doko> well, everything, which was uploaded since June ...
<Laney> ah, https://launchpad.net/ubuntu/+source/ruby-defaults/1:2.1.5.1ubuntu1
<utlemmin`> slangasek, infinity: any reason why dh-python is a requirement of python3?
<slangasek> utlemmin`: it's an annoying crutch for packages that should build-depend on dh-python but don't
<slangasek> (which I learned at the DebConf Python BoF)
<utlemmin`> slangasek, infinity: we're seeing a massive bloat in our cloud images because dh-python Depends libdpkg-perl, which now has a compiler dependency, so GCC is getting installed on wily cloud images
<slangasek> wat
<utlemmin`> slangasek: libdpkg-perl recommends libfile-fcntllock-perl which recommends a compiler
<utlemming> slangasek: so, I'm pretty sure we don't want that
<slangasek> utlemming: that's a horribly broken recommends from libfile-fcntllock-perl then
<infinity> Yeah, indeed.
<infinity> libdpkg-perl should not be bringing in a compiler, and nor should random perl modules.
<infinity> We can fix this.  We have the technology.
<utlemming> infinity: shall I file a bug?
<infinity> utlemming: Nah, I'm on it.
<slangasek> http://bugs.debian.org/783760
<ubot93> Debian bug 783760 in libfile-fcntllock-perl "libfile-fcntllock-perl: autopkgtest failure: File::FcntlLock::Inline needs cc" [Normal,Fixed]
<infinity> Yeah, that should be a suggests at best, I think.
<infinity> Or we should make dpkg use a different perl module. :P
<infinity> For now, I'll just drop it to a suggests.
<infinity> # Package for file locking with fcntl(2) in which the binary layout of
<infinity> # the C flock struct is determined via compiling and running a C program
<infinity> # each time the package is loaded
<infinity> WAT.
<infinity> That's super efficient.
<infinity> utlemming: Fix uploaded.
<infinity> Well, "fix".
<infinity> The proper fix is more involved (guessing the fcntl bits at build time and including that in the package).
<infinity> utlemming: Not that I don't also agree that the dh-python thing is somewhat madness, but libdpkg-perl is a thing a lot of people want anyway (say, for debsums), so that makes dh-python irrelevant to the discussion, IMO.
<utlemming> infinity: that's fair....the dh-python is the head of the dep chain that caused the bloat, which is why I asked.
#ubuntu-release 2015-09-09
<cyphermox> infinity: hello sir.
<infinity> cyphermox: Guten Tag.
<cyphermox> infinity: there's skiboot in trusty queue, if you have time for reviewing things, please :)
<cyphermox> and ^^ ibmpmlinux for partner.
<infinity> cyphermox: I can haz skiboot for vivid too?  I assume these are straight backports from wily?
<cyphermox> yes, we should haz skiboot on vivid too...
<infinity> cyphermox: ^-- Both accepted.
<infinity> That sure built fast...
<infinity> cyphermox: Hrm.  Looking at the build log, it seems this package intends/wants to build big-endian, but since you didn't build-dep on a cross-compiler, it's building LE.  Was that intentional, or an oops?
<cyphermox> I think that's intentional, and it seemed to work from my testing on two different machines... but given that I have very little knowledge on how precisely it's supposed to work, it's hard to say if I missed something
<infinity> cyphermox: Well, it'll limit the usefulness a bit, but that depends on IBM's usecases.  Most (all?) PPC firmware is big-endian intentionally, because that works on all hardware and emulated environments, while LE is a crap-shoot of "it might work, sometimes".
<cyphermox> fwiw, I didn't make the initial packaging, I expect there was a conscious decision to build little-endian too
<cyphermox> wait
<cyphermox> this doesn't build the firmwares though
<cyphermox> just opal-prd.
<infinity> cyphermox: I'm not sure if it was conscious effort, or an accident.  You have to stare at the logs to realise it's *trying* to cross, then falling back to native when it can't.
<infinity> cyphermox: Oh, this isn't the skiboot firmware bits, just a userspace tool?
<cyphermox> it's all from the same large source, but for now it just builds the opal-prd userspace tool
<infinity> cyphermox: Okay.  So, the userspace tool should absolutely be native-endian, while the firmware shouldn't be.  Their build system seems to conflate the two.
<cyphermox> hmm
<infinity> cyphermox: If and when we get around to building both from the same source, we should decouple those.
<infinity> cyphermox: So that firmware can be BE and userspace is native-endian of current userspace (and respect cross, if crossing).
<infinity> cyphermox: But not an issue for today.
<cyphermox> OK
<infinity> Firmware should also be freestanding, which can be BE even without a cross toolchain.
<infinity> Because gcc is smart that way.
<infinity> (See grub2)
<infinity> So, if you're spending real time on this one with upstream, suggest they fix that up, but this is fine for now.
<cyphermox> alright
 * infinity accepts the binaries.
#ubuntu-release 2015-09-10
<cyphermox> could someone please review https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1493934 ? I've filed it since since FF, NetworkManager has been stuck in proposed for various reasons and has yet to transition to release -- autopkgtests blocked promotion, there were some build failures, etc.
<ubot93> Launchpad bug 1493934 in network-manager (Ubuntu) "[FFE] NetworkManager 1.0.4" [Undecided,New]
<cyphermox> all of those are resolved now in this upload I'd like to do
<infinity> cyphermox: Declined, based on logs showing that it installs in French.
<cyphermox> crap
<cyphermox> I thought we had agreed French was the new default language? :)
<infinity> cyphermox: But, more seriously, I already verbally approved NM 1.x a couple of weeks ago, right?
<cyphermox> maybe.
<cyphermox> just being extra thorough, paperwork, etc.
<infinity> cyphermox: So, I'm fine with this, and all the happier that you took the time to make it all happy and get it tested, rather than jamming it in just to make a deadline.
<cyphermox> alright; uploading now.
<infinity> cyphermox: I assume the next upload fixes the autopkgtest issues?
<cyphermox> yes
<cyphermox> it fixed two bugs which unbreak autopkgtests, along with other tweaks to the autopkgtests from pitti -- namely, reducing timeouts to make them take less time and still work
<infinity> cyphermox: Bug commented on, please close with/after upload.
#ubuntu-release 2015-09-11
<jamespage> pls could I request a release team review of https://bugs.launchpad.net/ubuntu/+source/passlib/+bug/1494644
<ubot93> Launchpad bug 1494644 in passlib (Ubuntu) "[FFe] sync python-passlib 1.6.5-1 from Debian unstable" [High,New]
<infinity> jamespage: For future refernce, when checking rdeps of a source package, you want "src:passlib", unless that's the only binary it produces...
<infinity> jamespage: That picks up cloud-installer as one you didn't check, for instance.
<jamespage> infinity, urgh - apologies
<infinity> jamespage: Anyhow, cloud-installer is entirely Ubuntu-specific, so I assume you'll make a note of testing that one and fix it if you break it?
<jamespage> infinity, well indeed I would
<infinity> jamespage: Assuming that is true, I'm fine with the FFe, and will do the unblacklisting and such.
<jamespage> infinity, ta
<jamespage> infinity, theres a source package rename involved as well
<infinity> jamespage: Yeah, I got that bit. :)
<jamespage> prob why it was blacklisted but not 100% sure
<infinity> jamespage: I'll make sure the old one goes away.
<infinity> Lemme see if the blacklist has a rationale.
<infinity> # cjwatson, 2012-06-01
<infinity> # Temporary blacklist entries for quantal, requiring manual resolution due
<infinity> # to conflicts with existing Ubuntu-versioned binaries.
<infinity> alsa-base
<infinity> lxde-metapackages
<infinity> nx-libs-lite
<infinity> pysmbc
<infinity> ^--- So, looks like it was part of some temp hacks and never revisited.  Yay.
<infinity> python-passlib
<cjwatson> If those don't conflict any more it's fine to remove, certainly.
<infinity> jamespage: So, to be clear, you think whatever Ubuntu delta we had in 'passlib' is now useless, and python-passlib as-is in Debian is the way and the light?
 * infinity bets it was an ancient python-support->dh-python migration that never got revisited.
<infinity> But the current python-passlib looks modern and sane.
<jamespage> infinity, afaict we never actually took passlib from Debian (despite what the changelog says)
<jamespage> I suspect it's early openstack stuff that just got missed in re-syncing later
<jamespage> looking at the initial packager
<jamespage>  -- Monty Taylor <mordred@inaugust.com>  Fri, 09 Sep 2011 14:37:56 -0700
<jamespage> infinity, yes I do think python-passlib as-is in Debian is the way and the light
<jamespage> (just incase that was not clear)
<infinity> jamespage: Right, fixing the world, then.
<infinity> cjwatson: I'm assuming sync-blacklist updating is cronned to frontends or something.  Any idea what the schedule is? (don't look it up if you don't know off the top of your head, I can just wait)
<cjwatson> infinity: */5
<cjwatson> (minutes)
<infinity> Kay.  Ta.
 * infinity twiddles a thumb or two.
<cjwatson> Or just ssh -t snakefruit sudo -iu ubuntu-archive update-sync-blacklist
<jamespage> infinity, cloud-installer is supercedeed by the 'openstack' package in the NEW queue (just checked with stokachu)
<infinity> jamespage: Oh, good, would be nice to file a removal request for that for when I review/accept openstack then.
<jamespage> stokachu, ^^ please do :-)
<infinity> jamespage: Since this is syncing to main as a new source, can you make sure it has a bug subscriber?
<infinity> jamespage: Whatever team you sub to openstacky things.
<jamespage> infinity, I can indeed
<infinity> jamespage: Should be in LP now, if you want to do that for me.
<jamespage> infinity, done
<infinity> jamespage: Ta.
<infinity> And I think that's three hats I just shuffled on that request.
<infinity> My head is confused.
<jamespage> lol
<infinity> jamespage: Go on, SRU it, make it 4.
<jamespage> infinity, as much as I'd like to see a full-brain inversion today....
<infinity> That sounds like something the bmezine glossary would have an entry for.
<infinity> Ran 1813 tests in 152.622s
<infinity> That's some impressive coverage for a small python module.
<stokachu> jamespage: ok cool
#ubuntu-release 2016-09-12
<LocutusOfBorg> pitti, ping, please autopkgtest for ignition-transport/1.3.0-4: amd64: Regression â» , armhf: Always failed, i386: Always failed, ppc64el: Always failed, s390x: Always failed
<LocutusOfBorg> ignition-transport has a autpkgtestuite that runs well with protobuf3, and this is the last protobuf blocker for migration
<LocutusOfBorg> doko_, ^^^
<LocutusOfBorg> for your happiness :)
<LocutusOfBorg> protobuf should be run against ignition proposed, and vice-verssa
 * LocutusOfBorg exit
<pitti> Logan: done
<pitti> Logan: sorry, tab failure
<flocculant> pitti: you know anything about images and archive sync lock? or will that be someone else later in the day
<pitti> flocculant: I'm afraid I don't
<flocculant> okey doke :)
<LocutusOfBorg> please accept mia from new, the rdeps are already in place thanks
<LocutusOfBorg> thanks pitti and thanks irclogs service :)
<LocutusOfBorg> mmm pitti I'm not sure it worked retrying against -proposed...
<pitti> LocutusOfBorg: well, it's still in the queue
<pitti> http://autopkgtest.ubuntu.com/running#queue-ubuntu-yakkety-amd64
<LocutusOfBorg> oh thanks, I though the queue wasn't visible with the new service
<LocutusOfBorg> lets see if protobuf can migrate today
<apw> LocutusOfBorg, it was awol for a while (queues) and are now back with us
-queuebot:#ubuntu-release- Unapproved: init-system-helpers (xenial-proposed/main) [1.29ubuntu2 => 1.29ubuntu3] (core)
-queuebot:#ubuntu-release- Packageset: Added libmatemixer to ubuntu-mate in yakkety
<LocutusOfBorg> cjwatson, FYI, when a build goes ENOSPACE seems to be stuck forever https://launchpad.net/ubuntu/+source/insighttoolkit4/4.10.0-dfsg1-3ubuntu1/+build/10712957
<cjwatson> Yeah, known
<cjwatson> Just cancel it, at some point I'll get round to working out how to test my fix for that in launchpad-buildd
<LocutusOfBorg> thanks
<LocutusOfBorg> if you need a tester, I'm here :)
<cjwatson> LocutusOfBorg: No, I don't mean manual testing.
<LocutusOfBorg> ok thanks
<LocutusOfBorg> btw, many packages started failing for ENOMEM or some other similar issues
<LocutusOfBorg> I usually "fix" them by reducing parallellism in ubuntu, or by retrying them e.g. https://launchpad.net/ubuntu/+source/mia/2.4.3-2ubuntu1
<LocutusOfBorg> arm64 built after three retries
<LocutusOfBorg> I don't want such delta from Debian, but seems the infra has some issues :(
<flocculant> anyone about who's got the power to fix the iso's and tracker, nothing landed for anyone since the 10th :)
<cjwatson> Depends.  What's broken?
<flocculant> cjwatson: for those I've looked at > lockfile: Sorry, giving up on "/srv/cdimage.ubuntu.com/etc/.lock-archive-sync" Couldn't acquire archive sync lock!
<cjwatson> Oh, reboot damage
<flocculant> at least Xubuntu and Ubuntu are like that currently, gnome and lubuntu were yesterday
<cjwatson> Should be fixed now
<flocculant> cjwatson: thanks :) - Xubuntu is probably stuck re-building from Saturday (manually) I assume that'll sort itself when the next one builds?
<cjwatson> Should do
<flocculant> k - thanks again :)
<LocutusOfBorg> bye protobuf! /cc doko_
<LocutusOfBorg> still some rebuilds are missing, but fcl migrated
<LocutusOfBorg> but should we really rebuild stuff such as dialer-app address-book-app camera-app to have protobuf3 migrate?
 * LocutusOfBorg fixes libphonenumber, that seems a blocker for the transition to end
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-367 [source] (xenial-proposed) [367.44-0ubuntu0.16.04.2]
<sergiusens> infinity what are my options to get snapcraft-2.17 allowed into xenial-proposed?
<apw> sergiusens, i see the yakkety version is failing its self-tests ?
<sergiusens> apw yes, because snapd in yakkety is older than in xenial
<apw> sergiusens, erp ... that isn't menat to happen
<sergiusens> apw our xenial tests pass just fine fwiw https://github.com/snapcore/snapcraft/pull/787 (View Details there)
<sergiusens> apw and right, that's why I ask, what are my options :-)
<apw> sergiusens, i've asked (i hope) for a test of the yakkety one with the proposed snapd, which might clear that regression out
<sergiusens> apw oh, is that possible from my end?
<sergiusens> I "hope" it works, I am not sure, cjwatson do you know? ^
<cjwatson> sergiusens: Well, apw said he's already triggered it.  It's not possible from your end
<cjwatson> But archive admins can request that kind of thing
<cjwatson> Assuming apw is talking about autopkgtests
<sergiusens> cjwatson right, I was thinking of the key work you've done on snapd, I've been told that gpg transistions was one of the cultprits
<sergiusens> cjwatson yeah, he is, well yeah, I assume as much
<cjwatson> sergiusens: I don't see gpg failures in the log?
<cjwatson> sergiusens: There was a lot of noise about the gpg transition, but it shouldn't actually break anything in snapd
<apw> i am talking about adt indeed, though in the new world it is hard to tell if it has worked
<apw> yep the failure i see in yakkety is using snap --force-something which is not present in the one in -release
<sergiusens> good to know Colin (avoiding over pinging triggers now)
<sergiusens> yeah, --force-dangerous was an unexpected surprise for us
<ogra_> sergiusens, like ...everything ... related .... to ... snaps  ?
<ogra_> (like having "grade: " added to snap.yaml in the ubuntu-core snap on release day ... and the store choking on it :P )
<ogra_> the wonderful inter-team communication in snappy is resulting in a constant flow of suprises :)
<cjwatson> Also everything is a huge rush and communication is the first thing to go
<ogra_> yeah, sadly ... and it usually bites
<sergiusens> ogra_ funny thing about grade was that it was a store folk contribution ;-)
<ogra_> heh, yeah
<ogra_> i still dont know what it is suppposed to do :)
<sergiusens> cjwatson btw, why did it work at all given the dependency on snapd (>= 2.14.2~)? Maybe that is a pitti question
<cjwatson> sergiusens: That dependency is only on integrationtest, and I think it's snapstest that failed
<cjwatson> Er, integrationtests / snapstests respectively
<sergiusens> yeah, I got it
<sergiusens> thanks
<cjwatson> snapstest has a tighter dep now
<cjwatson> But maybe that wasn't in that release?
<cjwatson> Haven't looked very closely
<apw> sergiusens, ok there is now a yakkety ADT run which appears to have the yakkety-proposed version of snapd, but the tests appear to fail still
<apw> Get:44 http://ftpmaster.internal/ubuntu yakkety-proposed/main amd64 snapd amd64 2.14.2+gitcc9d039-0ubuntu5 [7,665 kB]
<sergiusens> apw where are those logs?
<apw> sergiusens, http://autopkgtest.ubuntu.com/packages/s/snapcraft/yakkety/amd64
<apw> sergiusens, note the one at the top with twin triggers
<sergiusens> apw great, snapd 2.14 in xenial has `--force-dangerous` while snapd in yakkety has just `--dangerous` :-(
 * sergiusens blames ogra_
<ogra_> haha+
<ogra_> sergiusens, xenial-proposed should have --dangerous too
<ogra_> yay for stable APIs
<apw> ogra_, there is no snapd in xenial-proposed
<ogra_> well, there will be :)
<sergiusens> ogra_ 2.14 in xenial does NOT have `--dangerous`
<ogra_> (i havent invented that option btw)
<ogra_> complain to gustavo
<sergiusens> ogra_ 2.14 is in xenial-updates!
<ogra_> i know that trunk has --dangerous
<ogra_> and that it is supposed to land ASAP
<ogra_> (if it doesnt get renamed inbetween :P )
<apw> ogra_, without backwards compatibility ?
<apw> sergiusens, it sounds like we need to work out what is meant to be where here
<ogra_> apw, really ask sommeone who is in charge ... i'm suffering the same way as you do
<ogra_> afaik it is a gustavo thing
<ogra_> though perhaps he is also just the messenger
<sergiusens> apw I have no words
 * sergiusens is jus upset
<sergiusens> just*
<apw> sergiusens, just trying to help
<sergiusens> apw and I appreciate that :-) I am not upset at you, just the situtation really
<sergiusens> apw if I upload tests that use --dangerous instead of --force-dangerous to yakkety will you trigger that magic to use snapd from proposed?
<apw> sergiusens, can do
-queuebot:#ubuntu-release- New binary: wireshark [ppc64el] (yakkety-proposed/universe) [2.2.0+g5368c50-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireshark [s390x] (yakkety-proposed/universe) [2.2.0+g5368c50-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireshark [i386] (yakkety-proposed/universe) [2.2.0+g5368c50-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireshark [powerpc] (yakkety-proposed/universe) [2.2.0+g5368c50-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireshark [amd64] (yakkety-proposed/universe) [2.2.0+g5368c50-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.7~bzr1256-0ubuntu1~16.04.1 => 0.7.7-31-g65ace7b-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- New binary: wireshark [armhf] (yakkety-proposed/universe) [2.2.0+g5368c50-1] (no packageset)
<elopio> sergiusens: ah, I remember why I wasn't in this channel. queuebot triggers a notification for me on every message.
-queuebot:#ubuntu-release- New binary: clblas [amd64] (yakkety-proposed/universe) [2.10-4] (no packageset)
-queuebot:#ubuntu-release- New binary: clblas [ppc64el] (yakkety-proposed/universe) [2.10-4] (no packageset)
-queuebot:#ubuntu-release- New binary: clfft [i386] (yakkety-proposed/universe) [2.12.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: clblas [i386] (yakkety-proposed/universe) [2.10-4] (no packageset)
-queuebot:#ubuntu-release- New binary: clfft [ppc64el] (yakkety-proposed/universe) [2.12.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: clfft [amd64] (yakkety-proposed/universe) [2.12.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: clfft [armhf] (yakkety-proposed/universe) [2.12.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: clfft [s390x] (yakkety-proposed/universe) [2.12.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: clblas [arm64] (yakkety-proposed/universe) [2.10-4] (no packageset)
-queuebot:#ubuntu-release- New binary: clfft [powerpc] (yakkety-proposed/universe) [2.12.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: clblas [s390x] (yakkety-proposed/universe) [2.10-4] (no packageset)
-queuebot:#ubuntu-release- New binary: clblas [powerpc] (yakkety-proposed/universe) [2.10-4] (no packageset)
-queuebot:#ubuntu-release- New binary: wireshark [arm64] (yakkety-proposed/universe) [2.2.0+g5368c50-1] (no packageset)
-queuebot:#ubuntu-release- New binary: clblas [armhf] (yakkety-proposed/universe) [2.10-4] (no packageset)
-queuebot:#ubuntu-release- New binary: clfft [arm64] (yakkety-proposed/universe) [2.12.2-1] (no packageset)
<sergiusens> apw if you don't mind, the latest snapcraft is already published in yakkety-proposed
-queuebot:#ubuntu-release- New sync: libcmrt (yakkety-proposed/primary) [1.0.6+dfsg1-1]
-queuebot:#ubuntu-release- New binary: winff [amd64] (yakkety-proposed/universe) [1.5.3-7ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected init-system-helpers [source] (xenial-proposed) [1.29ubuntu3]
-queuebot:#ubuntu-release- Unapproved: init-system-helpers (xenial-proposed/main) [1.29ubuntu2 => 1.29ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.4]
#ubuntu-release 2016-09-13
-queuebot:#ubuntu-release- New: accepted clblas [amd64] (yakkety-proposed) [2.10-4]
-queuebot:#ubuntu-release- New: accepted clblas [armhf] (yakkety-proposed) [2.10-4]
-queuebot:#ubuntu-release- New: accepted clblas [powerpc] (yakkety-proposed) [2.10-4]
-queuebot:#ubuntu-release- New: accepted clblas [s390x] (yakkety-proposed) [2.10-4]
-queuebot:#ubuntu-release- New: accepted clfft [arm64] (yakkety-proposed) [2.12.2-1]
-queuebot:#ubuntu-release- New: accepted clfft [i386] (yakkety-proposed) [2.12.2-1]
-queuebot:#ubuntu-release- New: accepted clfft [ppc64el] (yakkety-proposed) [2.12.2-1]
-queuebot:#ubuntu-release- New: accepted libcmrt [sync] (yakkety-proposed) [1.0.6+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted mia [arm64] (yakkety-proposed) [2.4.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted mia [i386] (yakkety-proposed) [2.4.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted clblas [arm64] (yakkety-proposed) [2.10-4]
-queuebot:#ubuntu-release- New: accepted clblas [ppc64el] (yakkety-proposed) [2.10-4]
-queuebot:#ubuntu-release- New: accepted clfft [armhf] (yakkety-proposed) [2.12.2-1]
-queuebot:#ubuntu-release- New: accepted clfft [s390x] (yakkety-proposed) [2.12.2-1]
-queuebot:#ubuntu-release- New: accepted mia [armhf] (yakkety-proposed) [2.4.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted mia [ppc64el] (yakkety-proposed) [2.4.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted winff [amd64] (yakkety-proposed) [1.5.3-7ubuntu1]
-queuebot:#ubuntu-release- New: accepted wireshark [arm64] (yakkety-proposed) [2.2.0+g5368c50-1]
-queuebot:#ubuntu-release- New: accepted wireshark [i386] (yakkety-proposed) [2.2.0+g5368c50-1]
-queuebot:#ubuntu-release- New: accepted wireshark [ppc64el] (yakkety-proposed) [2.2.0+g5368c50-1]
-queuebot:#ubuntu-release- New: accepted clblas [i386] (yakkety-proposed) [2.10-4]
-queuebot:#ubuntu-release- New: accepted clfft [powerpc] (yakkety-proposed) [2.12.2-1]
-queuebot:#ubuntu-release- New: accepted mia [powerpc] (yakkety-proposed) [2.4.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted wireshark [amd64] (yakkety-proposed) [2.2.0+g5368c50-1]
-queuebot:#ubuntu-release- New: accepted wireshark [powerpc] (yakkety-proposed) [2.2.0+g5368c50-1]
-queuebot:#ubuntu-release- New: accepted clfft [amd64] (yakkety-proposed) [2.12.2-1]
-queuebot:#ubuntu-release- New: accepted mia [s390x] (yakkety-proposed) [2.4.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted wireshark [s390x] (yakkety-proposed) [2.2.0+g5368c50-1]
-queuebot:#ubuntu-release- New: accepted mia [amd64] (yakkety-proposed) [2.4.3-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted wireshark [armhf] (yakkety-proposed) [2.2.0+g5368c50-1]
-queuebot:#ubuntu-release- New: accepted android-platform-build [amd64] (yakkety-proposed) [1:6.0.1+r55-2]
-queuebot:#ubuntu-release- New: accepted mia [armhf] (yakkety-proposed) [2.4.3-2]
-queuebot:#ubuntu-release- New: accepted mia [powerpc] (yakkety-proposed) [2.4.3-2]
-queuebot:#ubuntu-release- New: accepted mia [s390x] (yakkety-proposed) [2.4.3-2]
-queuebot:#ubuntu-release- New: accepted android-platform-build [i386] (yakkety-proposed) [1:6.0.1+r55-2]
-queuebot:#ubuntu-release- New: accepted mia [ppc64el] (yakkety-proposed) [2.4.3-2]
-queuebot:#ubuntu-release- New: accepted mia [i386] (yakkety-proposed) [2.4.3-2]
-queuebot:#ubuntu-release- New binary: libcmrt [amd64] (yakkety-proposed/none) [1.0.6+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: libcmrt [i386] (yakkety-proposed/none) [1.0.6+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted libcmrt [amd64] (yakkety-proposed) [1.0.6+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted libcmrt [i386] (yakkety-proposed) [1.0.6+dfsg1-1]
<sergiusens> apw hi there, any luck with triggering the snapcraft/amd64/yakkety tests using snapd from -proposed?
<apw> sergiusens, will check if it took
<apw> sergiusens, yes it is, so we should know in an hour
<sergiusens> apw greatly appreciated!
<doko_> is there anybody running auto-demotions for packages in the release pocket without looking at the proposed pocket?
<doko_> see https://bugs.launchpad.net/bugs/1619213 as an example
<ubot5> Ubuntu bug 1619213 in python-os-vif (Ubuntu) "[MIR] python-os-vif" [High,Fix committed]
<doko_> slangasek, infinity, seb128, cjwatson, pitti, whoever? ^^^
<cjwatson> Not I
<seb128> not me, I didn't demote anything this cycle
<pitti> I sometimes demote stuff on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt, could have been me
<pitti> I'll check c-m-proposed next time, s orry
<apw> sergiusens, that seems to have failed with "error: unknown flag `force-dangerous"
<sergiusens> apw oh, I wanted to hide my shame http://launchpadlibrarian.net/283981083/snapcraft_2.17+16.10.1_2.17+16.10.1ubuntu1.diff.gz
<ogra_> oh the fun
<apw> for: 2.17+16.10.1ubuntu1 triggered: snapcraft/2.17+16.10.1ubuntu1 snapd/2.14.2+gitcc9d039-0ubuntu5
<sergiusens> apw I uploaded 2.17+16.10.1ubuntu2
<apw> sergiusens, oh ok
<apw> sergiusens, i'll wait for that to publish and wack some re-tests in
<sergiusens> apw thank you for your patience!
<ogra_> you should send a bill to the creators of --force-dangerous ... and allow them to only reject it if they opick the right arg out of --dangerous/--force-dangerous ... and they only get one try ;)
-queuebot:#ubuntu-release- Unapproved: xorg-server (xenial-proposed/main) [2:1.18.3-1ubuntu2.3 => 2:1.18.3-1ubuntu2.4] (desktop-core, xorg) (sync)
<slangasek> doko_: there is definitely /someone/ running those auto-demotions, because licensecheck's deps keep getting kicked out.  but it's not me - I guess it was pitti.  I got the memo about checking both :)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20160712.1-0ubuntu0.14.04.1 => 1:20160913.1-0ubuntu0.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20160712.1-0ubuntu0.16.04.1 => 1:20160913.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (precise-proposed/partner) [1:20160712.1-0ubuntu0.12.04.1 => 1:20160913.1-0ubuntu0.12.04.1] (no packageset)
-queuebot:#ubuntu-release- New sync: libzmf (yakkety-proposed/primary) [0.0.1-2]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (precise-proposed) [1:20160913.1-0ubuntu0.12.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20160913.1-0ubuntu0.14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20160913.1-0ubuntu0.16.04.1]
<slangasek> qa.ubuntuwire.com down, or is it me?
<ogra_> seems down
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [0.7.7-31-g65ace7b-0ubuntu1~16.04.1]
<jbicha> yeah, /usr/bin/reverse-depends doesn't work either now :(
<slangasek> yes, that's what I was trying to use
-queuebot:#ubuntu-release- Unapproved: juju-mongodb3.2 (xenial-proposed/universe) [3.2.4-0ubuntu1.2 => 3.2.9-0ubuntu1~16.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: openipmi (xenial-proposed/main) [2.0.18-0ubuntu11 => 2.0.18-0ubuntu11.1] (ubuntu-server)
<tumbleweed> slangasek: it seems the physical host under ubuntuwire is down. Can spin up another reverse-deps instance somewhere if we need it
<jbicha> tumbleweed: http://qa.ubuntuwire.org/ftbfs/ is important too
<tumbleweed> hrm, I have one of those running, I think?
<tumbleweed> nope, it appears not
<slangasek> tumbleweed: as you can imagine, I can find ways to manage without it, but it's a high profile service and I'm sure we'd love to have it back :)
-queuebot:#ubuntu-release- New: accepted libzmf [sync] (yakkety-proposed) [0.0.1-2]
-queuebot:#ubuntu-release- New binary: libzmf [i386] (yakkety-proposed/none) [0.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libzmf [ppc64el] (yakkety-proposed/none) [0.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libzmf [amd64] (yakkety-proposed/none) [0.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libzmf [arm64] (yakkety-proposed/none) [0.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libzmf [armhf] (yakkety-proposed/none) [0.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libzmf [powerpc] (yakkety-proposed/none) [0.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted libzmf [amd64] (yakkety-proposed) [0.0.1-2]
-queuebot:#ubuntu-release- New: accepted libzmf [armhf] (yakkety-proposed) [0.0.1-2]
-queuebot:#ubuntu-release- New: accepted libzmf [powerpc] (yakkety-proposed) [0.0.1-2]
-queuebot:#ubuntu-release- New: accepted libzmf [arm64] (yakkety-proposed) [0.0.1-2]
-queuebot:#ubuntu-release- New: accepted libzmf [ppc64el] (yakkety-proposed) [0.0.1-2]
-queuebot:#ubuntu-release- New: accepted libzmf [i386] (yakkety-proposed) [0.0.1-2]
-queuebot:#ubuntu-release- New binary: libzmf [s390x] (yakkety-proposed/universe) [0.0.1-2] (no packageset)
<mwhudson> can someone reject juju-mongodb3.2 3.2.8-0ubuntu3~16.04 from xenial unapproved please?
<mwhudson> (that's the older of the two juju-mongodb3.2s in the queue :-p)
#ubuntu-release 2016-09-14
-queuebot:#ubuntu-release- Unapproved: ifupdown (xenial-proposed/main) [0.8.10ubuntu1 => 0.8.10ubuntu1.1] (core)
-queuebot:#ubuntu-release- New sync: svn2git (yakkety-proposed/primary) [2.3.2-2]
<apw> mwhudson, done
-queuebot:#ubuntu-release- Unapproved: rejected juju-mongodb3.2 [source] (xenial-proposed) [3.2.8-0ubuntu3~16.04]
<mwhudson> apw: ta
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.17]
-queuebot:#ubuntu-release- Unapproved: accepted init-system-helpers [source] (xenial-proposed) [1.29ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted ifupdown [source] (xenial-proposed) [0.8.10ubuntu1.1]
<LocutusOfBorg> hi virtual builders, do you mind showing up your status here? :) https://launchpad.net/builders
-queuebot:#ubuntu-release- Unapproved: accepted etcd [source] (xenial-proposed) [2.2.5+dfsg-1ubuntu1]
<cjwatson> LocutusOfBorg: uh, what do you mean?
<LocutusOfBorg> Architecture 	Builders 	Queue
<LocutusOfBorg> powerpc 	8 	empty
<LocutusOfBorg> s390x 	28 	empty
<LocutusOfBorg> and where are amd64, arm64, ppc64el and so on?
<LocutusOfBorg> I can see them only for ppa builds
<LocutusOfBorg> not for official builds
<LocutusOfBorg> or they are merged all together
<apw> LocutusOfBorg, they share the same pool now
<LocutusOfBorg> so, in  [ppa] Virtual build status  I would like to see an added image "[Official]"
<LocutusOfBorg> the image is misleading then :)
<cjwatson> LocutusOfBorg: Yes, they're all merged.
<cjwatson> LocutusOfBorg: "Official" would not make sense.
<cjwatson> The image choices probably do need to be revised, but I think not that way.
-queuebot:#ubuntu-release- Unapproved: rejected xorg-server [sync] (xenial-proposed) [2:1.18.3-1ubuntu2.4]
<apw> LocutusOfBorg, they are called Virtual Builders ... which is correct
-queuebot:#ubuntu-release- Unapproved: rejected xorg-server [source] (xenial-proposed) [2:1.18.4-0ubuntu0.1]
<cjwatson> Possibly we just need to relabel the images, since they're pretty arbitrary anyway.
<apw> ^^ these two are overlapping and tjaalton is going to resolve and resubmit same
-queuebot:#ubuntu-release- New: accepted libzmf [s390x] (yakkety-proposed) [0.0.1-2]
-queuebot:#ubuntu-release- New: accepted svn2git [sync] (yakkety-proposed) [2.3.2-2]
<LocutusOfBorg> yes, I don't have a strong opinion, but I was really mislead by such images :)
<LocutusOfBorg> thanks
<bzoltan> hi, I would like to ask for promoting the qml-module-ubuntu-components-labs package from the universe because I would like to introduce a dependency on it
<Mirv> what bzoltan means is that there is now a dependency for it http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html
-queuebot:#ubuntu-release- New: accepted subiquity [source] (yakkety-proposed) [0.0.15]
-queuebot:#ubuntu-release- New binary: svn2git [amd64] (yakkety-proposed/none) [2.3.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: subiquity [amd64] (yakkety-proposed/universe) [0.0.15] (no packageset)
-queuebot:#ubuntu-release- New: accepted subiquity [amd64] (yakkety-proposed) [0.0.15]
-queuebot:#ubuntu-release- New: accepted svn2git [amd64] (yakkety-proposed) [2.3.2-2]
<bzoltan> pitti: ^
<willcooke> Hi gang.  The release date on this page says 20th Oct:  https://launchpad.net/ubuntu/yakkety
<willcooke> Can that be updated?
<cjwatson> willcooke: You mean on the ubuntu-16.10 milestone?  Updated.
<willcooke> thanks cjwatson
<pitti> bzoltan: I see it on http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt; moved to main
<bzoltan> pitti: thank you
-queuebot:#ubuntu-release- Unapproved: accepted libgweather [source] (trusty-proposed) [3.10.2-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted python3.4 [source] (trusty-proposed) [3.4.3-1ubuntu1~14.04.4]
-queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (trusty-proposed) [4.2.4-7ubuntu12.7]
-queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (precise-proposed) [4.1.ESV-R4-0ubuntu5.11]
-queuebot:#ubuntu-release- Unapproved: accepted openipmi [source] (xenial-proposed) [2.0.18-0ubuntu11.1]
-queuebot:#ubuntu-release- Unapproved: accepted libgweather [source] (xenial-proposed) [3.18.2-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted juju-mongodb3.2 [source] (xenial-proposed) [3.2.9-0ubuntu1~16.04]
-queuebot:#ubuntu-release- Unapproved: xorg-server (xenial-proposed/main) [2:1.18.3-1ubuntu2.3 => 2:1.18.4-0ubuntu0.1] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-meta (xenial-proposed/universe) [1.154 => 1.154.1] (ubuntu-mate)
-queuebot:#ubuntu-release- Unapproved: opencryptoki (xenial-proposed/universe) [3.4.1+dfsg-1ubuntu3 => 3.4.1+dfsg-1ubuntu4] (no packageset)
-queuebot:#ubuntu-release- Unapproved: libica (xenial-proposed/universe) [2.6.1-1ubuntu1 => 2.6.1-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New source: openscenegraph-3.4 (yakkety-proposed/primary) [3.4.0+dfsg1-1ubuntu1]
<tjaalton> apw: new xorg-server uploaded with the xmir update on top of 1.18.4 et al
-queuebot:#ubuntu-release- Unapproved: linux-firmware (xenial-proposed/main) [1.157.3 => 1.157.4] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (xenial-proposed) [1.157.4]
-queuebot:#ubuntu-release- Unapproved: accepted libica [source] (xenial-proposed) [2.6.1-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: rejected xorg-server [source] (xenial-proposed) [2:1.18.4-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: xorg-server (xenial-proposed/main) [2:1.18.3-1ubuntu2.3 => 2:1.18.4-0ubuntu0.1] (desktop-core, xorg)
-queuebot:#ubuntu-release- Unapproved: accepted opencryptoki [source] (xenial-proposed) [3.4.1+dfsg-1ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-meta [source] (xenial-proposed) [1.154.1]
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (xenial-proposed) [2:1.18.4-0ubuntu0.1]
<jbicha> arges: please reject gnome-calendar 3.20.3-0ubuntu0.1 (xenial), upstream released a 3.20.4 I'll upload instead
<arges> jbicha: ok
-queuebot:#ubuntu-release- Unapproved: rejected gnome-calendar [source] (xenial-proposed) [3.20.3-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted golang-gopkg-lxc-go-lxc.v2 [source] (xenial-proposed) [0.0~git20160803.0.f8a6938-0ubuntu1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted runc [source] (xenial-proposed) [1.0.0~rc1-0ubuntu1~16.04]
-queuebot:#ubuntu-release- Unapproved: gnome-calendar (xenial-proposed/main) [3.20.2-0ubuntu0.1 => 3.20.4-0ubuntu0.1] (desktop-extra, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-calendar [source] (xenial-proposed) [3.20.4-0ubuntu0.1]
<ginggs> hi, would someone process openscenegraph-3.4 in yakkety NEW please?
<bdmurray> slangasek: I'm thinking about releasing livecd-rootfs for Xenial early - seem reasonable? LP: #1621393
<ubot5> Launchpad bug 1621393 in cloud-images "xenial64 image (20160907.1.0) has a broken (empty) /etc/resolv.conf" [Undecided,New] https://launchpad.net/bugs/1621393
<slangasek> bdmurray: yes, fine by me
<ogra_> slangasek, bdmurray note that the phonee overlay uses its own livecd-rootfs, if a new one goes to xenial-proposed the one in the overlay needs a versionn bump to stay newer else images fail to build (i had to deal with that last week)
<slangasek> well
<slangasek> that's why they should stop forking packages like this and SRU them instead
<ogra_> indeed, but it is how it is :)
<ogra_> if you dont want jibel to knock on your door tomorrow, take it into account ;)
<slangasek> they can raise an MP to get their changes properly included in xenial
<slangasek> "you can't SRU this package, it has special undocumented requirements because of an external PPA" - um no
<ogra_> you know that nobody does that if lukasz isnt around ...
<ogra_> i didnt say you cant SRU ... i was just warning that it needs a version bump in the PPa
<sergiusens> ogra_ they should just use glorious epochs and be done with it ;-)
<slangasek> ogra_: and bumping the version without merging the SRUed changes makes the merge harder
<slangasek> ogra_: I should make you own this SRU to fix it up ;)
<ogra_> sergiusens, lol
<slangasek> ogra_: uploaded to stable overlay, and this time /also/ committed to branch for SRU queuing
<ogra_> slangasek, haha, i have a big livecd-rootfs ahead already, no thanks :)
<ogra_> (once i'm done dropping all the crap from the PPA one)
<ogra_> (and our livecd-rootfs is even worse ... at some point someone synced yakkety into the snappy-dev PPA ... now there is a yakkety base  with 41 additions that needs to be made SRU ready for xenial ... fun all over :) )
-queuebot:#ubuntu-release- Unapproved: walinuxagent (xenial-proposed/main) [2.1.3-0ubuntu4 => 2.1.3-0ubuntu4.1] (ubuntu-cloud, ubuntu-server)
<flocculant> stgraber: hi - the iso tracker appears to be losing track of reported bugs again > http://iso.qa.ubuntu.com/qatracker/milestones/360/builds/131079/testcases/1300/results for instance shows bug rreported beginning of August - still not on the 'Bugs to look for' list
-queuebot:#ubuntu-release- Unapproved: rejected walinuxagent [source] (xenial-proposed) [2.1.3-0ubuntu4.1]
-queuebot:#ubuntu-release- Unapproved: walinuxagent (xenial-proposed/main) [2.1.3-0ubuntu4 => 2.1.3-0ubuntu4.1] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (xenial-proposed) [2.1.3-0ubuntu4.1]
-queuebot:#ubuntu-release- Unapproved: accepted python3.5 [source] (xenial-proposed) [3.5.2-2~16.04]
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.7-31-g65ace7b-0ubuntu1~16.04.1 => 0.7.7-31-g65ace7b-0ubuntu1~16.04.2] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [0.7.7-31-g65ace7b-0ubuntu1~16.04.2]
-queuebot:#ubuntu-release- New sync: adwaita-qt (yakkety-proposed/primary) [0.5-1]
#ubuntu-release 2016-09-15
-queuebot:#ubuntu-release- New binary: urdfdom [ppc64el] (yakkety-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: urdfdom [amd64] (yakkety-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: urdfdom [i386] (yakkety-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: urdfdom [s390x] (yakkety-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: urdfdom [powerpc] (yakkety-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: urdfdom [armhf] (yakkety-proposed/universe) [1.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: urdfdom [arm64] (yakkety-proposed/universe) [1.0.0-2] (no packageset)
<LocutusOfBorg> please accept urdfdom, fixing a FTBFS with one reverse dependency
<LocutusOfBorg> only kido should need a rebuild
-queuebot:#ubuntu-release- New: accepted urdfdom [amd64] (yakkety-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted urdfdom [armhf] (yakkety-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted urdfdom [powerpc] (yakkety-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted urdfdom [arm64] (yakkety-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted urdfdom [s390x] (yakkety-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted urdfdom [i386] (yakkety-proposed) [1.0.0-2]
-queuebot:#ubuntu-release- New: accepted urdfdom [ppc64el] (yakkety-proposed) [1.0.0-2]
<cjwatson> LocutusOfBorg: .
<LocutusOfBorg> thanks
<LocutusOfBorg> I'm not sure where is the best place to report launchpad failures
<LocutusOfBorg> but reverse-depends seems not working, and I guess because ubuntuwire is down qa.ubuntuwire.org/rdepends/
<cjwatson> that's not a Launchpad failure
<cjwatson> qa.ubuntuwire.org is something somebody else (tumbleweed IIRC) maintains
<LocutusOfBorg> so, ubuntu-dev-tools relies on external websites and services :(
<cjwatson> correct
<Ukikie> And py2. :3
<bluesabre> Hello release team! Xubuntu would like to include the latest greybird-gtk-theme (lp 1623855), I've already checked with others in our docs, release, and QA subteams, can I get an ACK to go ahead and upload this one today?
<ubot5> Launchpad bug 1623855 in greybird-gtk-theme (Ubuntu) "[UIFe] Greybird 3.20.1" [Undecided,New] https://launchpad.net/bugs/1623855
<jibel> slangasek, ogra_ I asked Lukasz to SRU the changes in livecd-rootfs when he is back from holidays
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.7-31-g65ace7b-0ubuntu1~16.04.2 => 0.7.8-1-g3705bb5-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [0.7.8-1-g3705bb5-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- New sync: ruby-sys-filesystem (yakkety-proposed/primary) [1.1.7-1]
<LocutusOfBorg> -mahimahi (0.93-1 to -)
<LocutusOfBorg>     Package not in unstable, will try to remove
<LocutusOfBorg> rmadison has a different opinion
<LocutusOfBorg> also that "-" is making the link 404
-queuebot:#ubuntu-release- Unapproved: qemu (trusty-proposed/main) [2.0.0+dfsg-2ubuntu1.27 => 2.0.0+dfsg-2ubuntu1.28] (ubuntu-server, virt)
-queuebot:#ubuntu-release- New sync: ruby-hamlit (yakkety-proposed/primary) [2.7.0-1]
-queuebot:#ubuntu-release- New sync: ruby-sys-filesystem (yakkety-proposed/primary) [1.1.7-1]
<bdmurray> cyphermox: so shim-signed is good to be released to precise?
<cyphermox> bdmurray: I believe so
<tumbleweed> cjwatson: I don't maintain the machine, I just maintain some services running on it. #ubuntuwire is the best place to discuss problems with the machine
<cyphermox> bdmurray: could you please also reject grub2 in xenial-proposed queue? I'll upload another with some other fixes
-queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.4]
<cyphermox> ta
<jderose> infinity: yakkety will no longer install under QEMU in UEFI mode... what package should i file a bug against for this?
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (trusty-proposed) [2.0.0+dfsg-2ubuntu1.28]
<doko> please override the libreoffice/i386 autopkg test triggered by gcc-6; if at all, that's unrelated to one c++ fix and a installability fix, and I'd like to start the test rebuilds
<doko> slangasek, infinity, pitti: ^^^
<pitti> doko: hinted
<doko> ta
<sergiusens> bdmurray hi there, mind letting snapcraft-2.17 into xenial-updates?
<bdmurray> sergiusens: okay, might you be able to answer a snappy question while you are here?
-queuebot:#ubuntu-release- New: accepted adwaita-qt [sync] (yakkety-proposed) [0.5-1]
-queuebot:#ubuntu-release- New: accepted ruby-hamlit [sync] (yakkety-proposed) [2.7.0-1]
-queuebot:#ubuntu-release- New: rejected ruby-sys-filesystem [sync] (yakkety-proposed) [1.1.7-1]
-queuebot:#ubuntu-release- New: accepted openscenegraph-3.4 [source] (yakkety-proposed) [3.4.0+dfsg1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted ruby-sys-filesystem [sync] (yakkety-proposed) [1.1.7-1]
<infinity> jderose: If you can't sort out which package is to blame, start with the installer (ubiquity or d-i, depending on your install method), and we'll triage from there.
<jderose> infinity: cool. it's happening with both desktop and server, so seems like d-i is probably a better initial target. thanks!
-queuebot:#ubuntu-release- New binary: adwaita-qt [ppc64el] (yakkety-proposed/none) [0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-hamlit [ppc64el] (yakkety-proposed/none) [2.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: adwaita-qt [i386] (yakkety-proposed/none) [0.5-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-hamlit [i386] (yakkety-proposed/none) [2.7.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-hamlit [amd64] (yakkety-proposed/none) [2.7.0-1] (no packageset)
<sergiusens> bdmurray sure
-queuebot:#ubuntu-release- New binary: adwaita-qt [amd64] (yakkety-proposed/none) [0.5-1] (no packageset)
<bdmurray> sergiusens: I know you can use source-tag with a git repo but is there anyway to grab the latest release e.g. https://github.com/rg3/youtube-dl/releases
<sergiusens> bdmurray err, no; is there a canonical way to figure it out without any magic?
<bdmurray> sergiusens: I don't see snapcraft in the queue https://launchpad.net/ubuntu/xenial/+queue?queue_state=1
<sergiusens> bdmurray strange, I see it here http://people.canonical.com/~ubuntu-archive/pending-sru.html
<bdmurray> sergiusens: ah, I misunderstood into -proposed vs into -updates
-queuebot:#ubuntu-release- New binary: ruby-hamlit [s390x] (yakkety-proposed/universe) [2.7.0-1] (no packageset)
<bdmurray> sergiusens: are these normally released after less than 7 days in -proposed?
-queuebot:#ubuntu-release- New binary: adwaita-qt [s390x] (yakkety-proposed/universe) [0.5-1] (no packageset)
<sergiusens> bdmurray yes, we have an exception for day == 1
<sergiusens> bdmurray we release every or every other week
<bdmurray> sergiusens: I didn't see that in the SnapcraftUpdates wiki page
<Ukikie> jderose: I was unable to get it to boot with qemu+ovmf even.
<jderose> Ukikie: hmm, interesting. what are you using for the host OS? Xenial, Yakkety, something else?
<sergiusens> bdmurray hmmm, slangasek where should we document the 1 day of stabilization thing?
<jderose> Ukikie: for me it's broken with a Xenial host + Yakkety guest, but I haven't yet tried a Yakkety host + Yakkety guest.
<bdmurray> sergiusens: slangasek is out today and tomorrow perhaps we should just do it in that SnapcraftUpdates page
<sergiusens> bdmurray ok, sounds good, maybe arges knows as he was in the conversations
<jderose> Ukikie: er, yeah, you were *unable* to get it to boot. yup, that's my experience... i'm using QEMU + OVMF
<bdmurray> sergiusens: there seems to be a history of it, I just think we should document it for others too
<Ukikie> jderose: Xenial host, ovmf from xenial or what I used to use to test secure boot was working too.  It still works on the older ISOs, just none of the Yakkety ones.
-queuebot:#ubuntu-release- New: accepted adwaita-qt [amd64] (yakkety-proposed) [0.5-1]
-queuebot:#ubuntu-release- New: accepted adwaita-qt [ppc64el] (yakkety-proposed) [0.5-1]
-queuebot:#ubuntu-release- New: accepted ruby-hamlit [amd64] (yakkety-proposed) [2.7.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-hamlit [ppc64el] (yakkety-proposed) [2.7.0-1]
<jderose> Ukikie: okay, yeah, that's exactly matching my experience. well, except i haven't tried it with secure boot enabled.
-queuebot:#ubuntu-release- New: accepted adwaita-qt [i386] (yakkety-proposed) [0.5-1]
-queuebot:#ubuntu-release- New: accepted ruby-hamlit [i386] (yakkety-proposed) [2.7.0-1]
-queuebot:#ubuntu-release- New: accepted adwaita-qt [s390x] (yakkety-proposed) [0.5-1]
-queuebot:#ubuntu-release- New: accepted ruby-hamlit [s390x] (yakkety-proposed) [2.7.0-1]
<sergiusens> bdmurray do you mind editing? I don't want people to later see my name and it not being accepted
<Ukikie> jderose: (I have a different ovmf version too that I can try, IIRC it was needed for secure boot.)  Also noted that -hda fat:/home/unit193/hda/  didn't mount correctly in new ovmf versions (esc during the ovmf logo, boot from internal shell.)
<bdmurray> slangasek: I updated the SnapcraftUpdates wiki page regarding waiving the 7 days of aging but the reasoning behind it might make it more informative.
<jderose> infinity: Ukikie: I filed a bug - https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1624096
<ubot5> Ubuntu bug 1624096 in debian-installer (Ubuntu) "yakkety: desktop and server ISOs wont boot under QEMU in UEFI mode" [Undecided,New]
<Ukikie> jderose: Great!  Subbed.
<jderose> :)
<sergiusens> Thanks bdmurray. Are we good to release?
<bdmurray> sergiusens: I did already
-queuebot:#ubuntu-release- New binary: openscenegraph-3.4 [ppc64el] (yakkety-proposed/universe) [3.4.0+dfsg1-1ubuntu1] (no packageset)
<sergiusens> Thanks then!
-queuebot:#ubuntu-release- New binary: openscenegraph-3.4 [s390x] (yakkety-proposed/universe) [3.4.0+dfsg1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-sys-filesystem [amd64] (yakkety-proposed/universe) [1.1.7-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted openscenegraph-3.4 [ppc64el] (yakkety-proposed) [3.4.0+dfsg1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted ruby-sys-filesystem [amd64] (yakkety-proposed) [1.1.7-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted openscenegraph-3.4 [s390x] (yakkety-proposed) [3.4.0+dfsg1-1ubuntu1]
-queuebot:#ubuntu-release- New binary: openscenegraph-3.4 [amd64] (yakkety-proposed/universe) [3.4.0+dfsg1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: dkms (xenial-proposed/main) [2.2.0.3-2ubuntu11.2 => 2.2.0.3-2ubuntu11.3] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: dkms (trusty-proposed/main) [2.2.0.3-1.1ubuntu5.14.04.8 => 2.2.0.3-1.1ubuntu5.14.04.9] (kubuntu, ubuntu-desktop)
<tsimonq2> hello release team
<tsimonq2> I'm trying to run britney2 locally by following https://wiki.ubuntu.com/ProposedMigration/LocalSetup
<tsimonq2> when running britney.py I'm getting thrown this:
<tsimonq2>   File "/home/ubuntu/britney2-ubuntu/autopkgtest.py", line 30, in <module>
<tsimonq2>     import amqplib.client_0_8 as amqp
<tsimonq2> ImportError: No module named 'amqplib'
-queuebot:#ubuntu-release- New: accepted openscenegraph-3.4 [amd64] (yakkety-proposed) [3.4.0+dfsg1-1ubuntu1]
<tsimonq2> I'm not sure what to do as I have it installed already
<tsimonq2> I figured I should ask here as you guys use this in production
<wxl> you SURE you have amqplib installed?
<apw> the right python version of the library ?
<wxl> i mean that's a pretty fundamental part of the whole thing
<tsimonq2> yes
<tsimonq2> but 1.0.2 is in the archive and pip :/
<wxl> pip list | grep amqplib
 * tsimonq2 uninstalls all related packages from the archive and pip and tries to install 0.8 specifically
<tsimonq2> $ pip list | grep amqplib
<tsimonq2> amqplib (1.0.2)
<wxl> yeah you should be able to install the specific version with pip
<tumbleweed> if the error is "No module named 'amqplib'" it doesn't sound like the wrong version
<tsimonq2> interesting... http://paste.ubuntu.com/23184075/
<wxl> pip install amqplib==version
<tsimonq2> I'll just keep the version installed from the archive
<tsimonq2> so it WAS installed
<tsimonq2> theory, I'm running with python3...
<wxl> yes but not the specific version required
<wxl> so run with python2.7 :)
<tsimonq2> import apt_pkg
<tsimonq2> ImportError: No module named apt_pkg
<tsimonq2> argh
<tsimonq2>   File "britney.py", line 192, in <module>
<tsimonq2> (you get it)
<tsimonq2> oh I know
<tsimonq2> looking at http://stackoverflow.com/questions/67631/how-to-import-a-module-given-the-full-path#67692 now
<wxl> this is definitely python 3 https://git.launchpad.net/~ubuntu-release/+git/britney2-ubuntu/tree/INSTALL
<tumbleweed> and your paste was definitely python 2.7
<wxl> yup sure was
<tsimonq2> tumbleweed: same when running with python3 so *shrug*
<tsimonq2> I mean the error I was intitially getting
<wxl> try using pip3, tsimonq2
<tumbleweed> tsimonq2: so, that was bare pip, outside a virtualenv
<tumbleweed> why di dyou even need pip?
<tsimonq2> I uninstalled everything via pip
<tumbleweed> it looked like the dependencies were all in the archive
 * tsimonq2 nods
<tumbleweed> so, if you have python3-apt installed, it should be able to import apt_pkg
<tsimonq2> python3-apt is already the newest version (1.1.0~beta1build1).
<tsimonq2> well I installed python-apt and it works
<tsimonq2> now this
<tsimonq2>     from urllib.parse import quote, urlencode
<tsimonq2> ImportError: No module named parse
<tsimonq2> I'll wash, rinse, and repeat
<tumbleweed> this sounds like python 2, not 3
<tumbleweed> are you running "python britney.py" ? because that obviously won't use python 3
<tumbleweed> ./britney.py should, though, because it has a python3 shebang
<tsimonq2> $ python2.7 britney.py -c britney.conf --series=yakkety -v
 * tsimonq2 tries *again* with python3
<tumbleweed> well that's not going to work
<tsimonq2>     import amqplib.client as amqp
<tsimonq2> ImportError: No module named 'amqplib'
<tumbleweed> I mean, the python2.7 bit :)
<tumbleweed> python3-amqplib
<tsimonq2>   File "/home/ubuntu/britney2-ubuntu/autopkgtest.py", line 30, in <module>
<tsimonq2>     import amqplib.client as amqp
<tsimonq2> ImportError: No module named 'amqplib.client'
<tsimonq2> WOW I'm stupid, thanks, progress
<tsimonq2>   File "./britney.py", line 903, in _read_packages_file
<tsimonq2>     pkg = intern(pkg)
<tsimonq2> TypeError: intern() argument 1 must be str, not None
<tsimonq2> fun fun fun :/
<tumbleweed> didn't have the packages file it wanted?
 * tsimonq2 downloads everything one more time
<tsimonq2> still can't get it to work
<tsimonq2> I'm stuck on that one error
<tsimonq2> that page should be a bit more verbose if I'm missing something
<tumbleweed> you ran britney-indexes?
<tsimonq2> yes I did
<tumbleweed> and it put the right things in the data dir
<tsimonq2> I guess this might help: http://paste.ubuntu.com/23184175/
<tumbleweed> does data/yakkety-proposed/Packages_amd64 look sane?
<tsimonq2> tumbleweed: it's a binary file...
<tsimonq2> O__O
<tsimonq2> oh ok
<tsimonq2> I guess it's expected
<tsimonq2> tumbleweed: no, it doesn't look sane :P
<tumbleweed> right, probably not unxzed ? which britney-indexes is supposed to do
<tumbleweed> err gz
<tsimonq2> aha!
<tsimonq2> that's it I think
<tsimonq2> pitti: bug in Britney it seems ^
<tumbleweed> you got no errors from britney-indexes?
<tumbleweed> that's not a bug in britney, but in britney-indexes, if anything
<tsimonq2> oooh it's running
<tsimonq2> it also makes me a bit mad I can't select two PPAs at once :/
<tsimonq2> FileNotFoundError: [Errno 2] No such file or directory: 'data/yakkety/state/age-policy-dates'
<tsimonq2> argh :(
<tsimonq2> http://paste.ubuntu.com/23184323/
#ubuntu-release 2016-09-16
-queuebot:#ubuntu-release- Unapproved: docker.io (xenial-proposed/universe) [1.11.2-0ubuntu5~16.04 => 1.12.1-0ubuntu8] (no packageset)
<mwhudson> ups
<mwhudson> can someone reject that ^
<apw> mwhudson, done
<mwhudson> apw: thanks
-queuebot:#ubuntu-release- Unapproved: rejected docker.io [source] (xenial-proposed) [1.12.1-0ubuntu8]
<mwhudson> apw: you're my favourite SRU queue rejecter!
<apw> i have my uses it seems
<tumbleweed> cjwatson, doko, slangasek: temporary home: http://ubuntuqa.tblwd.org/
<pitti> tsimonq2: what are you trying to do? at first sight it just looks like you are missing  britney'2 dependencies, such as python3-amqplib?
<pitti> tsimonq2: err, Packages_* are supposed to be plain files, not compressed
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.14.2~16.04 => 2.15] (desktop-core, ubuntu-server)
 * apw is handling ^
<bluesabre> pitti, can I go ahead and upload greybird-gtk-theme? It's a bugfix release and has been ack'd by the Xubuntu docs, release, artwork, and QA teams (lp 1623855)
<ubot5`> Launchpad bug 1623855 in greybird-gtk-theme (Ubuntu) "[UIFe] Greybird 3.20.1" [Wishlist,New] https://launchpad.net/bugs/1623855
<pitti> bluesabre: erm, sure; you don't need my permission :)
<pitti> (already acked by docs and release teams)
<bluesabre> wasn't sure if we needed to ack up to the ubuntu release team or if our own subteams were enough
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.15]
<apw> tumbleweed, cheeky i know, is there seeded-in-ubuntu info on there too ?
<apw> tumbleweed, and ignore me and assume i can't read
-queuebot:#ubuntu-release- New sync: ruby-babel-transpiler (yakkety-proposed/primary) [0.7.0-1]
<LocutusOfBorg> some gitlab-ruby stuff ^^
-queuebot:#ubuntu-release- New sync: ruby-sprockets-es6 (yakkety-proposed/primary) [0.9.1-1]
-queuebot:#ubuntu-release- New sync: ruby-prof (yakkety-proposed/primary) [0.15.9+dfsg1-1]
<LocutusOfBorg> ^^ and we should be good
-queuebot:#ubuntu-release- New sync: keeper (yakkety-proposed/primary) [0.1.0+16.10.20160915.3-0ubuntu1]
<LocutusOfBorg> pitti, ruby-devise-async is utterly broken, and needed only by gitlab. Since the new gitlab in proposed is not using it anymore, I propose you to demote it to proposed (or ignore the autpkgtestsuite), and help me in make gitlab migrate :)
<LocutusOfBorg> removing from the archive might be even better :)
<LocutusOfBorg> and will be removed from debian in some days too https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837644
<ubot5`> Debian bug 837644 in ruby-devise-async "ruby-devise-async is not compatible with devise >= 4.0" [Serious,Open]
-queuebot:#ubuntu-release- New: accepted keeper [sync] (yakkety-proposed) [0.1.0+16.10.20160915.3-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ruby-prof [sync] (yakkety-proposed) [0.15.9+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted ruby-babel-transpiler [sync] (yakkety-proposed) [0.7.0-1]
-queuebot:#ubuntu-release- New: accepted ruby-sprockets-es6 [sync] (yakkety-proposed) [0.9.1-1]
-queuebot:#ubuntu-release- New sync: ruby-babel-source (yakkety-proposed/primary) [5.8.35-1]
-queuebot:#ubuntu-release- New binary: ruby-prof [armhf] (yakkety-proposed/none) [0.15.9+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-prof [i386] (yakkety-proposed/none) [0.15.9+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-prof [amd64] (yakkety-proposed/none) [0.15.9+dfsg1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-prof [s390x] (yakkety-proposed/none) [0.15.9+dfsg1-1] (no packageset)
<xnox> tumbleweed, temporary change dns too? to unbreak the world...
<xnox> is there a way to make an upload, in such a way that it is forced to go through review queue? (even though it normally would not)
<apw> none that i know of... nice thought i would be ... people in my team who wnat that feature tend to upload it to a PPA and ask for review there
<xnox> yeah.... i want to upload something that should not be trusted =)
<pitti> LocutusOfBorg: kicked to -proposed
<rbasak> xnox: in our team, we'd probably import it into git and then file an MP against it.
<rbasak> xnox: I can import a package for you if you'd like to do that.
<xnox> it's ok
<pitti> xnox: but no new binary or so?
<pitti> xnox: I suppose asking someone to review from a git branch and/or PPA is most practical then
<xnox> ack. will do.
<LocutusOfBorg> ta
<xnox> pitti, qemu is stuck in proposed on systemd autopkgtest failure and nova.
<xnox> nova used to not be there, i'll check that.
<xnox> but the systemd failure is weird to me... does the systemd autopkgtest do nested qemu and my update breaks that?
<pitti> xnox: it does use nested qemu, for the "upstream" tests; but that's fine, it's the fsck test that failed
<pitti> plymouth-start did not run, hmm
<pitti> xnox: so, for sure unrelated to qemu, need to investigate
<xnox> ack retried nova test because results are all PASS but cleanup failed.
<pitti> it's been doing that for a few days already
<pitti> xnox: hm, that should be a tmpfail; mind filing a bug against autopkgtst with a pointer to the log?
<pitti> i. e. those should auto-retry
<xnox> i might be impatient =)
<pitti> xnox: oh, it's fine to manually retry, I just mean for the future
<pitti> xnox: filed bug 1624406, will hint over systemd
<ubot5`> bug 1624406 in systemd (Ubuntu) "systemd-fsck test started to fail" [High,In progress] https://launchpad.net/bugs/1624406
<xnox> tah!
<pitti> LocutusOfBorg: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ruby-devise is a valid candidate now, but still blocked on some transition
<pitti> xnox: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qemu â really close now!
<pitti> xnox: did you retry nova/amd64 too?
<xnox> no idea where it went
<pitti> xnox: so you did? hang on
<xnox> sso did do it
<LocutusOfBorg> pitti, we need ruby* accepted from new queue
<LocutusOfBorg> and demoting ruby-handlebars-assets might be appreciated :)
<LocutusOfBorg> so, demoting handlebars, accepting the three packages in new, migration!
<LocutusOfBorg> (handlebars has one rdep, diaspora)
<pitti> xnox: hmm, no trace of it anywhere
-queuebot:#ubuntu-release- New: accepted ruby-babel-source [sync] (yakkety-proposed) [5.8.35-1]
-queuebot:#ubuntu-release- New: accepted ruby-prof [armhf] (yakkety-proposed) [0.15.9+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted ruby-prof [s390x] (yakkety-proposed) [0.15.9+dfsg1-1]
<pitti> LocutusOfBorg: ^
-queuebot:#ubuntu-release- New: accepted ruby-prof [amd64] (yakkety-proposed) [0.15.9+dfsg1-1]
-queuebot:#ubuntu-release- New: accepted ruby-prof [i386] (yakkety-proposed) [0.15.9+dfsg1-1]
<LocutusOfBorg> <3 pitti
<pitti> LocutusOfBorg: WDYM with "demoting"? it already is in universe
<pitti>  ruby-handlebars-assets | 2:0.21.0-5 | yakkety/universe          | source, all
<LocutusOfBorg> demoting to proposed
<pitti>  ruby-handlebars-assets | 2:0.23.0-3 | yakkety-proposed/universe | source, all
<LocutusOfBorg> or remove, in debian the new version is in non-free
<LocutusOfBorg> I'm wondering if you did some mistake in letting it be in universe
<LocutusOfBorg> bugs.debian.org/830987
<pitti> LocutusOfBorg: ruby-babel-source is in Debian main, WDYM?
<pitti> oh, -handlebars; no idea, did I let that in?
<pitti> LocutusOfBorg: anyway, if it has reverse dependencies then we can't just remove it, the reverse depends need to be fixed first
<LocutusOfBorg> move both on multiverse :) or demote also diaspora?
<LocutusOfBorg> the popcon is "1"
-queuebot:#ubuntu-release- New binary: ruby-babel-source [amd64] (yakkety-proposed/none) [5.8.35-1] (no packageset)
<pitti> bah, diaspora also has a gazillion reverse depends
<LocutusOfBorg> oh...
 * pitti wants reverse-depends back
<pitti> ok, not that bad
<LocutusOfBorg> I'm using coccia since reverse-depends is not in place
<LocutusOfBorg> even if it is
<pitti> $ change-override -S -c multiverse diaspora diaspora-installer ruby-handlebars-assets
<pitti> (in contrib in Debian)
<pitti> LocutusOfBorg: and once that's published, move hte three to -proposed?
<LocutusOfBorg> sure
<LocutusOfBorg> if you mean the three now in multiverse
<LocutusOfBorg> but they are broken in Debian, and needs fixing there before ubuntu
<LocutusOfBorg> incompatible with the other ruby stuff
<LocutusOfBorg> babel-source is in new
<pitti> LocutusOfBorg: no, it's not :)
<LocutusOfBorg> this unblocks ruby-sprockets-es6 and ruby-babel-transpiler. Once they are cleared from new, everything migrates (if everything is good)
<LocutusOfBorg> :)
-queuebot:#ubuntu-release- New: accepted ruby-babel-source [amd64] (yakkety-proposed) [5.8.35-1]
<pitti> LocutusOfBorg: I think I moved everything now, now needs another publisher cycle
<LocutusOfBorg> thanks
-queuebot:#ubuntu-release- New binary: ruby-babel-transpiler [amd64] (yakkety-proposed/universe) [0.7.0-1] (no packageset)
<LocutusOfBorg> pitti, ^^
-queuebot:#ubuntu-release- New: accepted ruby-babel-transpiler [amd64] (yakkety-proposed) [0.7.0-1]
<LocutusOfBorg> pitti, ruby-sprockets (universe) is still doing autopkgtest against ruby-handlebars-assets (multiverse) <-- is that normal?
<jbicha> pitti: does "Confirmed" mean you approved the uife for bug 1623855?
<ubot5`> bug 1623855 in greybird-gtk-theme (Ubuntu) "[UIFe] Greybird 3.20.1" [Wishlist,Confirmed] https://launchpad.net/bugs/1623855
<apw> the process says triaged means approved
<jbicha> right, that's why I'm clarifying what pitti meant
<tumbleweed> xnox: DNS is in the same hands as the server that's down
<tumbleweed> pitti: there's a temporary reverse-depends on http://ubuntuqa.tblwd.org/
<tsimonq2> pitti: I want to get a britney setup running locally to test Kubuntu packages before we whip up an FFe so we are absolutely 100% sure it breaks nothing
<tsimonq2> pitti: (britney2)
<tsimonq2> pitti: is there a dep list for britney2 that I'm missing?
-queuebot:#ubuntu-release- New binary: ruby-sprockets-es6 [amd64] (yakkety-proposed/universe) [0.9.1-1] (no packageset)
<LocutusOfBorg> pitti, last one I hope :D
-queuebot:#ubuntu-release- New: accepted ruby-sprockets-es6 [amd64] (yakkety-proposed) [0.9.1-1]
#ubuntu-release 2016-09-17
<flocculant> infinity: we've had a few issues over the last few weeks - this one appears to affect Ubuntu/Xubuntu/Studio/ and then I stopped looking
<flocculant> bug 1622303
<ubot5`> bug 1622303 in light-locker (Ubuntu) "Fails to unlock/ resume to black screen" [Undecided,Confirmed] https://launchpad.net/bugs/1622303
<flocculant> sorry and all that :(
<flocculant> infinity being anyone from outside of Xubuntu caring ;)
-queuebot:#ubuntu-release- New sync: libi8x (yakkety-proposed/primary) [0.0.2-2]
-queuebot:#ubuntu-release- New sync: i8c (yakkety-proposed/primary) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted i8c [sync] (yakkety-proposed) [0.0.3-1]
-queuebot:#ubuntu-release- New: accepted libi8x [sync] (yakkety-proposed) [0.0.2-2]
-queuebot:#ubuntu-release- New binary: libi8x [ppc64el] (yakkety-proposed/none) [0.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libi8x [amd64] (yakkety-proposed/none) [0.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libi8x [arm64] (yakkety-proposed/none) [0.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libi8x [armhf] (yakkety-proposed/none) [0.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libi8x [i386] (yakkety-proposed/none) [0.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted libi8x [amd64] (yakkety-proposed) [0.0.2-2]
-queuebot:#ubuntu-release- New: accepted libi8x [armhf] (yakkety-proposed) [0.0.2-2]
-queuebot:#ubuntu-release- New: accepted libi8x [ppc64el] (yakkety-proposed) [0.0.2-2]
-queuebot:#ubuntu-release- New: accepted libi8x [arm64] (yakkety-proposed) [0.0.2-2]
-queuebot:#ubuntu-release- New: accepted libi8x [i386] (yakkety-proposed) [0.0.2-2]
-queuebot:#ubuntu-release- New binary: libi8x [s390x] (yakkety-proposed/none) [0.0.2-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted libi8x [s390x] (yakkety-proposed) [0.0.2-2]
<LocutusOfBorg> pitti, good morning, everything has migrated!
<LocutusOfBorg> more general question, in Debian I moved thanks to unit193 virtualbox-ext-pack from non-free to contrib (it is just a downloader)
<LocutusOfBorg> so, can you please move from multiverse to universe?
<LocutusOfBorg> I just sync'd the change in yakkety
-queuebot:#ubuntu-release- New source: readline (yakkety-proposed/primary) [7.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted readline [source] (yakkety-proposed) [7.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: readline [ppc64el] (yakkety-proposed/none) [7.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: readline [i386] (yakkety-proposed/none) [7.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: readline [amd64] (yakkety-proposed/none) [7.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: readline [arm64] (yakkety-proposed/none) [7.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: readline [armhf] (yakkety-proposed/none) [7.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: readline [s390x] (yakkety-proposed/none) [7.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: readline [powerpc] (yakkety-proposed/none) [7.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted readline [amd64] (yakkety-proposed) [7.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted readline [armhf] (yakkety-proposed) [7.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted readline [powerpc] (yakkety-proposed) [7.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted readline [s390x] (yakkety-proposed) [7.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted readline [arm64] (yakkety-proposed) [7.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted readline [ppc64el] (yakkety-proposed) [7.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted readline [i386] (yakkety-proposed) [7.0-0ubuntu1]
#ubuntu-release 2016-09-18
<estan> hi folks. if i were to prepare an SRU for the cmake package with https://gitlab.kitware.com/ben.boeckel/cmake/commit/f6c5958047ee8a9084bf230a6c1acb4801cb2b93 , do you think it would be accepted..?
<estan> it fixes https://gitlab.kitware.com/cmake/cmake/issues/16049 (original Mantis report: https://cmake.org/Bug/view.php?id=16049)
<estan> the problem is that when using AUTORCC in a CMake project, the qrc_*.cpp.o target will always be considered out-of-date, leading to a re-link despite no changes.
<estan> (kind of defeats one of the strengths of Ninja, it's fast no-op build time :/)
<estan> the fix seems non-invasive and self-contained.
<estan> or would it be better to simply request an SRU to update cmake to 3.5.2, which includes the fix, in xenial (already in yakkety)?
<estan> i started by filing a bug report at least: https://bugs.launchpad.net/ubuntu/+source/cmake/+bug/1624832
<ubot5`> Ubuntu bug 1624832 in cmake (Ubuntu) "AUTORCC-generated resources always out-of-date with Ninja" [Undecided,New]
-queuebot:#ubuntu-release- New binary: i8c [amd64] (yakkety-proposed/universe) [0.0.3-3] (no packageset)
-queuebot:#ubuntu-release- New: accepted i8c [amd64] (yakkety-proposed) [0.0.3-3]
-queuebot:#ubuntu-release- New binary: gdb [i386] (yakkety-proposed/main) [7.11.90.20160917-0ubuntu2] (core)
-queuebot:#ubuntu-release- New: accepted gdb [i386] (yakkety-proposed) [7.11.90.20160917-0ubuntu2]
-queuebot:#ubuntu-release- New binary: gdb [powerpc] (yakkety-proposed/main) [7.11.90.20160917-0ubuntu2] (core)
-queuebot:#ubuntu-release- New: accepted gdb [powerpc] (yakkety-proposed) [7.11.90.20160917-0ubuntu2]
#ubuntu-release 2017-09-11
<LocutusOfBorg> slangasek, can you please update your givaro hint?
<slangasek> LocutusOfBorg: I *could*, but it would really be better if someone would fix the failing autopkgtest since it's trivial
<LocutusOfBorg> slangasek, allow stderr?
<ginggs> LocutusOfBorg, slangasek: looks like https://wiki.ubuntu.com/GCC7
<LocutusOfBorg> I don't get the issue, should the package be fixed or is it a gcc bug?
<ginggs> LocutusOfBorg: well with GCC 6, it was a warning of an upcoming ABI break, so allow-stderr was sufficient
<ginggs> but now that we now have GCC 7.2, I'm not sure if we need to rename/rebuild libraries/ transition
<ginggs> LocutusOfBorg: I've add givaro to the wiki
<LocutusOfBorg> I don't think to be the right person to solve this, I'm giving up :)
<LocutusOfBorg> slangasek, please kick ruby-dep-selector, needs sourceful upload, blocking geocode migration, RC buggy in debian #870306
<ubot5`> Debian bug 870306 in src:ruby-dep-selector "ruby-dep-selector FTBFS with libgecode-dev 5.1.0-2" [Serious,Open] http://bugs.debian.org/870306
-queuebot:#ubuntu-release- Unapproved: accepted flashcache [source] (xenial-proposed) [3.1.3+git20150701-2ubuntu3]
<LocutusOfBorg> hello doko, I need some automake-1.15 fixes that are only in Debian... how do you feel about a merge?
<LocutusOfBorg> or anybody else, do you foresee an issue with an automake merge? 1.15 to 1.15.1 seems a bugfix only release
 * LocutusOfBorg open bugs
<cpaelzer> sorry to bother you - anybody time to consider FFE in bug 1706248 for approval (hanging around 11 days now)?
<ubot5`> bug 1706248 in slof (Ubuntu) "[FFE] SLOF dhcp request doesn't include client architecture code 93" [Medium,Confirmed] https://launchpad.net/bugs/1706248
<ahasenack> hi, any update on glibc going through excuses and thus unblocking other packages? like bind9?
-queuebot:#ubuntu-release- New sync: flake8-docstrings (artful-proposed/primary) [1.1.0-1]
<LocutusOfBorg> this is a new leaf package, feel free to reject in case you don't like it ^^ :) it is a style checker
-queuebot:#ubuntu-release- Unapproved: snapcraft (zesty-proposed/universe) [2.33+17.04 => 2.34+17.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.33 => 2.34] (no packageset)
<sergiusens> sil2100 mind allowing those in? ^
<sil2100> sergiusens: hey, on it in a minute
<doko> ahasenack: are all autopkg tests for packages maintained by you or your team succeeding and not blocking?
<ahasenack> doko: is that a general question, or a follow-up question to my bind9/glibc remark?
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (zesty-proposed) [2.34+17.04]
<sergiusens> thanks sil2100
<doko> ahasenack: I didn't see your bind9 issue. just making sure that other packages are in good shape for the migration
<doko> I don't know if there are any ...
<ahasenack> doko: bind9 is stuck for a few days because of the glibc upload
 * doko goes fixing apw's debian-installer upload ...
<doko> ahasenack: you know update_excuses?
<ahasenack> yes, I'm looking at http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_excuses.html
<doko> good
<sil2100> sergiusens: hmm, I see two uploads of snapcraft 2.34 for xenial
<sil2100> sergiusens: one from 13 minutes ago and one 20 hours ago
<sil2100> sergiusens: I guess the newest one is preferred?
<acheronuk> I'm look at the kcreenlocker regression on for glibc. so far on some quick testing, the regression doesn't seem to break my screenlocker on real hardware or a VM
<acheronuk> *looking
<LocutusOfBorg> doko, are you ok with an automake merge?
<LocutusOfBorg> it should be only fixes, no new features, and I'm interested in perl foo fixes and something else to fix games
<LocutusOfBorg> (some autoreconf odering issue=
<sergiusens> sil2100 yes, the latest one, on Sunday I asked for the one from 20 hours ago to be nuked :-)
<sil2100> Ah ;)
<sil2100> Ok
<sergiusens> I guess it got lost in the stream of messages ;-)
-queuebot:#ubuntu-release- Unapproved: rejected snapcraft [source] (xenial-proposed) [2.34]
<doko> LocutusOfBorg: sure, but how many autopkg tests will that trigger?
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.34]
<LocutusOfBorg> doko, how can I find the number out?
<LocutusOfBorg> queues are empty right now, this might even be a good time
 * LocutusOfBorg uploads
<LocutusOfBorg> Laney, question: how can I find out how many autopkgtests a package foo triggers?
<slangasek> LocutusOfBorg: ruby-dep-selector has reverse-build-depends which is why I hadn't kicked it out already.  What should happen to ruby-solve and berkshelf?  I don't want to trade p-m queue size for ftbfs
<slangasek> LocutusOfBorg: automake 1.15.1> I absolutely see an issue with that, half the archive uses automake at build-time and that can introduce an unknown number of build failures
<doko> slangasek: do we know which autopkg tests were ignored the last time when perl and glibc migrated?
<slangasek> doko: I didn't skiptest anything for perl
<slangasek> doko: oh, yes I did - but it was only systemd
<slangasek> doko: and I don't see a recent glibc skiptest
<doko> then this sounds like still a lot of things to do ...
<slangasek> yes
<LocutusOfBorg> slangasek, I went to the 20k diff for automake, 99% is copyright updates, 0.5% is the braces escapes, one is the ubuntu patch
<LocutusOfBorg> some new tests
<LocutusOfBorg> I know people are using it, this is why I asked here before, and I'm pretty sure we will be fine
<LocutusOfBorg> >What should happen to ruby-solve and berkshelf?
<LocutusOfBorg> they are going out from buster too
<LocutusOfBorg> speaking for glibc/curl, xandikos on amd64 and i386 ; casync on i386 have been regressed in release, so maybe an hint is appreciated
<LocutusOfBorg> (that automake is in Debian testing since 2.5 months or so, the last upload merged part of the Ubuntu delta, this is also why I care, other than two bugfixes I need)
<slangasek> LocutusOfBorg: unless you're planning to do a rebuild test and show that the new automake doesn't regress buildability, nack on this merge during freeze, which only unblocks a single package from -proposed
<LocutusOfBorg> how can I do in a ppa?
<LocutusOfBorg> I tested it, but I can't rebuild the whole ubuntu archive
<slangasek> you'd hit a size limit doing it in a ppa
<slangasek> you could discuss with doko how to include this in a rebuild test
<slangasek> but I don't see this as a priority at all for 17.10
<LocutusOfBorg> so, please kick it out from proposed then
<LocutusOfBorg> but as usual, I quickly fixup regressions
<acheronuk> slangasek: hi. would you be able to look at bug #1716381
<ubot5`> bug 1716381 in plasma-framework (Ubuntu Artful) "[FFe] KDE Frameworks 5.38.0 into the Artful Archive" [Undecided,New] https://launchpad.net/bugs/1716381
<LocutusOfBorg> acheronuk, I think tsimonq2 is asking for a qtbase-* foo too, so maybe you can do them together?
<acheronuk> LocutusOfBorg: no heard anything on that, but we could coordinate if so. still would like a decision in principle on just this anyway
-queuebot:#ubuntu-release- New sync: pantomime-clojure (artful-proposed/primary) [2.1.0+dfsg-1]
-queuebot:#ubuntu-release- New sync: ring-ssl-clojure (artful-proposed/primary) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted flake8-docstrings [sync] (artful-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted ring-ssl-clojure [sync] (artful-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted pantomime-clojure [sync] (artful-proposed) [2.1.0+dfsg-1]
<acheronuk> LocutusOfBorg: and there are only a few frameworks that would require a rebuild for a Qt update, so I would perhaps rather get this through soon
<slangasek> acheronuk: done
<sil2100> slangasek: hello! Could you later review the google sdk packages at partner?
<sil2100> (unapproved)
<slangasek> sil2100: that didn't go away while I was on vacation? ;)
<acheronuk> slangasek: thank you. :)
-queuebot:#ubuntu-release- New binary: pantomime-clojure [amd64] (artful-proposed/none) [2.1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ring-ssl-clojure [amd64] (artful-proposed/none) [0.3.0-1] (no packageset)
<sil2100> slangasek: no, apparently partner is still a thing ;p
<slangasek> sil2100: which releases?
<sil2100> zesty and xenial
<sil2100> And trusty
<slangasek> sil2100: should 169 be copied from artful-proposed to artful?
<sil2100> slangasek: I'd say not yet, I tested it myself but maybe the google folks would like to try it as well
<sil2100> And I'll poke them once we have all series in -proposed
<slangasek> k
<sil2100> slangasek: thanks!
<slangasek> sil2100: do you want to fix the spelling of 'backport' in the zesty changelog?
<acheronuk> slangasek: just so I don't have an unfortunate misunderstanding, is "This looks sensible to me", an ok to upload later?
<sil2100> slangasek: oh, did I mess up?
<slangasek> acheronuk: yes
<acheronuk> slangasek: TY :)
<slangasek> acheronuk: the marking it 'triaged' is also what this means :)
<sil2100> Oh god
<sil2100> slangasek: yeah, let me quickly re-upload ;p
 * acheronuk looks for the "doh!" emoticon
<acheronuk> missed that
-queuebot:#ubuntu-release- New sync: flake8-polyfill (artful-proposed/primary) [1.0.1-1]
-queuebot:#ubuntu-release- Unapproved: rejected google-cloud-sdk [source] (zesty-proposed) [169.0.0-0ubuntu1~17.04.0]
<slangasek> sil2100: same spelling in xenial
<sil2100> slangasek: yeah, I need all 3 fixed
<sil2100> On it now
<slangasek> ok
<LocutusOfBorg> something is needed to finish the clojure flake work ^^
-queuebot:#ubuntu-release- Unapproved: rejected google-cloud-sdk [source] (xenial-proposed) [169.0.0-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- Unapproved: rejected google-cloud-sdk [source] (trusty-proposed) [169.0.0-0ubuntu1~14.04.0]
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (xenial-proposed/partner) [163.0.0-0ubuntu1~16.04.0 => 169.0.0-0ubuntu1~16.04.0] (no packageset)
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (zesty-proposed/partner) [163.0.0-0ubuntu1~17.04.0 => 169.0.0-0ubuntu1~17.04.0] (no packageset)
<sil2100> slangasek: re-uploaded, sorry for the hiccup
-queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (trusty-proposed/partner) [163.0.0-0ubuntu1~14.04.0 => 169.0.0-0ubuntu1~14.04.0] (no packageset)
-queuebot:#ubuntu-release- New: accepted pantomime-clojure [amd64] (artful-proposed) [2.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted ring-ssl-clojure [amd64] (artful-proposed) [0.3.0-1]
-queuebot:#ubuntu-release- New: accepted flake8-polyfill [sync] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (zesty-proposed) [169.0.0-0ubuntu1~17.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (xenial-proposed) [169.0.0-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted google-cloud-sdk [source] (trusty-proposed) [169.0.0-0ubuntu1~14.04.0]
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.12 => 2.02~beta2-36ubuntu3.13] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (xenial-proposed/main) [1.66.12 => 1.66.13] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.13]
-queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (xenial-proposed) [1.66.13]
-queuebot:#ubuntu-release- New binary: flake8-polyfill [amd64] (artful-proposed/none) [1.0.1-1] (no packageset)
<slangasek> cyphermox: grub2/zesty on its way also?  and is it possible to spell out a "how to test under pmem" test case that's less opaque?  (if not, I understand)
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.12 => 2.02~beta2-36ubuntu3.13] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (xenial-proposed) [2.02~beta2-36ubuntu3.13]
-queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.13 => 2.02~beta2-36ubuntu3.13] (core)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-95.118~14.04.1] (kernel)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (xenial-proposed) [2.02~beta2-36ubuntu3.13]
<LocutusOfBorg> another round of closure/flake fixes ^^, this should unblock other three packages and then finish
-queuebot:#ubuntu-release- New binary: ring-defaults-clojure [amd64] (artful-proposed/universe) [0.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted flake8-polyfill [amd64] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted ring-defaults-clojure [amd64] (artful-proposed) [0.3.1-1]
<cyphermox> slangasek: no, it's not, sadly
<cyphermox> but yeah I'll upload the same thing for zesty
-queuebot:#ubuntu-release- New binary: trapperkeeper-metrics-clojure [amd64] (artful-proposed/universe) [0.4.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-95.118~14.04.1]
-queuebot:#ubuntu-release- New binary: flake8-docstrings [amd64] (artful-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (zesty-proposed/main) [2.441.4 => 2.441.5] (desktop-core)
-queuebot:#ubuntu-release- New: accepted flake8-docstrings [amd64] (artful-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted trapperkeeper-metrics-clojure [amd64] (artful-proposed) [0.4.2-1]
-queuebot:#ubuntu-release- New binary: trapperkeeper-status-clojure [amd64] (artful-proposed/universe) [0.7.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted trapperkeeper-status-clojure [amd64] (artful-proposed) [0.7.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.14 => 2.408.15] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (zesty-proposed) [2.441.5]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.15]
-queuebot:#ubuntu-release- New binary: puppetdb [amd64] (artful-proposed/universe) [4.4.1-1] (no packageset)
#ubuntu-release 2017-09-12
 * slangasek reruns colord/armhf autopkgtest w/ new valgrind
<didrocks> sil2100: hey, glib2.0 is stuck in proposed due to the flaky nplan autopkgtests which almost never succeed: http://autopkgtest.ubuntu.com/packages/n/nplan/artful/amd64. It seems that people are just override them for now, mind handling glib2? (unsure if you can ;))
<sil2100> didrocks: I don't think I can, looks like you'll need to poke someone from the release team (probably) ;p
<Laney> there's a new glib2.0 to merge btw :-)
<didrocks> I may handle the merge, but maybe let's get that one in first?
<doko> Laney: do we have a status about the failing glibc and perl autopkg tests?
<Laney> what kind of status?
<Ukikie> Unfortunatly the new glib2.0 does't fix all the mounts on the desktop. :/
<doko> who looked at which failing tests, don't want to duplicate work
<Laney> no status maintained by me - usually I would think the uploader would track its migration
<Laney> probably at some point we declare bankruptcy on the tests and use a force-skiptest to get it in
<Laney> ideally once the uploader has analysed all the failures
<acheronuk> I'm looking at the kscreenlocker one. so far with gblic from proposed and/or a kscreenlocker build againsta that, I have no real world kscreenlocker error on my hardware or a VM
<acheronuk> but I have emailed the upstream KDE maintainer to try to get his opinion
<Laney> didrocks: hinted it
<doko> Laney: http://autopkgtest.ubuntu.com/packages/p/profnet/artful/amd64  looks like this was overridden the last time that glibc migrated? so maybe mark that as always fail?
<didrocks> Laney: thanks! will handle the merge later on then ;)
<LocutusOfBorg> would be nice to wait for autopkgtests to slow down before merging new stuff :)
<Laney> KDE :(
<Laney> doko: looks like the new profnet in proposed is better maybe
<Laney> tried against that one
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.13.0-10.11] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20170808.1-0ubuntu0.14.04.1 => 1:20170912.1-0ubuntu0.14.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (zesty-proposed/partner) [1:20170808.1-0ubuntu0.17.04.1 => 1:20170912.1-0ubuntu0.17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20170808.1-0ubuntu0.16.04.1 => 1:20170912.1-0ubuntu0.16.04.1] (no packageset)
<flocculant> hi release team - not sure how this has happened but I'll not be able to fix the issue - we have an item in our daily set (Xubuntu Core) which I set up once a cycle currently just so we have somewhere to report tests. It's currently set at rebuilding for some reason. Can you unset that please - it never ever builds as our normal desktop iso's do anyway :)
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20170912.1-0ubuntu0.14.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20170912.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (zesty-proposed) [1:20170912.1-0ubuntu0.17.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.13.0-10.11]
<Laney> acheronuk_: Can you please give me a list of tests that you requested all-proposed runs on so that I can drop the original requests?
<Laney> Having duplicate several hour runs is pretty abusve to the infrastrucure IMO
<Laney> <insert weekly complaint about KDE tests>
<acheronuk_> only ones that failed. I did not duplicate any as far as I know
<Laney> run, fail, run again?
<acheronuk_> run triggered by britney, fail as FW stack is not finished building so test deps not satifiable or other reason, wait until the whole stack is build, then run against all proposed as that is what is required for framworks
<Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/armhf/k/kcalc/20170911_191157_35f35@/log.gz
<Laney> autopkgtest: WARNING: Test dependencies are unsatisfiable with using apt pinning. Retrying with using all packages from proposed
<Laney> still failed
<acheronuk_> that was not me retrying
<acheronuk_> and the reason that failed against all-propose with the pinning, is because the frameworks stack was still building
<Laney> You don't need to retry with all-proposed=1 because it falls back automatically if necessary
<acheronuk_> I do as I need the rest for frameworks to test against. the temporaily unsatifiable test deps halfway through tha stack build is a seperate issue
<Laney> If you need a complete stack then that should be expressed using package dependencies
<Laney> If you retry using all-proposed=1, you can make things pass tests and then they may migrate.
<Laney> Then users might get an untested situation on their machines
 * Laney is writing an emai
<Laney> l
<acheronuk> Laney: ack and understood on that email. sorry for the bad timing with the current tests
<LocutusOfBorg> sigh perl, there are CVE fixes in the -8 upload in Debian :(
<slangasek> casync autopkgtest regression is a real bug in the casync code; one-liner fix
<slangasek> infinity, doko: cryfs regresses with glibc 2.26 because it wants to use CHAR_WIDTH as a variable name and that's now a glibc define.  Is this a standard define, and is this an expected behavior change?
<infinity> slangasek: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=a292f45acdf0a35266e4f1dd1e51b95ca5325d2a certainly seems deliberate, yes.
<slangasek> ok
<slangasek> badtest'ing
<infinity> const unsigned CHAR_WIDTH = 1;
<infinity> Because "1" was too hard to type.
<infinity> slangasek: Looks like more recent versions have done s/CHAR_WIDTH/CHAR_SIZE/g
<infinity> slangasek: I'll just upload a cherrypick of that.
<infinity> https://github.com/fmtlib/fmt/commit/abbefd71666055daac9e14e78262620f9e845850
<slangasek> infinity: k
<infinity> And by cherrypick, I mean backport, because apparently they decided to change their brace style.  Weird.
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.15 => 2.408.16] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: gdebi (trusty-proposed/main) [0.9.5.3ubuntu2 => 0.9.5.3ubuntu3] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.15 => 2.408.16] (desktop-core)
 * tsimonq2 scratches head, no rejection but it's on there twice? ^^^^^
<tsimonq2> *shrug*
<infinity> tsimonq2: People sometimes get impatient and upload more than once.
<infinity> Or, in slangasek's case, they upload two different things and I assume plan to self-reject the first. :P
<slangasek> infinity: it's being discussed with bdmurray
<slangasek> and I'm going to self-reject *both* of them, so take that
<infinity> Heh.
<infinity> slangasek: https://launchpad.net/ubuntu/+source/cryfs/0.9.7-1ubuntu1 <-- Should address the previous conversation.
<slangasek> righty-o
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (xenial-proposed) [2.408.16]
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (xenial-proposed) [2.408.16]
<juliank> um, I think apt 1.4.6~17.04.1 should finally be accepted into zesty-updates, it's spent 47 days in -proposed now
<tsimonq2> infinity: :P
<juliank> there's the usual sbuild autopkgtest failures but we also saw those with postfix/3.1.4-4ubuntu1
<tsimonq2> infinity: ok, cool, I was just curious for the sake of future reference
<juliank> and randomly before
<juliank> paired with unattended-upgrades of course
<juliank> (42 days old)
<juliank> Hmm, do we have no unattended-upgrades with --no-download in zesty-proposed, did we miss that?
 * juliank is confused
<juliank> hmm no, 2.3 is in proposed, but pending-sru.html lists 2.2
<juliank> oops, wrong column
<slangasek> juliank: I do not ignore autopkgtest regressions as reported by proposed-migration, but I do accept MPs against lp:~ubuntu-sru/britney/hints-ubuntu-zesty :)
<slangasek> aka: if the sbuild autopkgtest is bad and you can demonstrate this, we should hint it as bad for everyone, not just ignore it for this current SRU
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.15 => 2.408.16] (desktop-core)
<juliank> slangasek: It only fails occasionally
<juliank> It's kind of odd
<slangasek> juliank: then we can still badtest it as 'flaky', or you can retry it until it succeeds
<slangasek> juliank: also, there is an sbuild SRU currently in zesty-proposed which purports to fix this
<slangasek> so another option is 1) do the SRU verification for the linked bugs, 2) release sbuild SRU, 3) retry apt-triggered autopkgtest
<juliank> slangasek: Or we retrigger with apt/1.4.6~17.04.1 and sbuild/0.71.0-2ubuntu2?
<slangasek> that too, but that's more manual and the sbuild SRU should get verified+released regardless
<juliank> slangasek: bug 1566590 has neither a zesty tag nor an SRU bug description
<ubot5> bug 1566590 in sbuild (Ubuntu) "s390x environment is weird" [Undecided,Fix released] https://launchpad.net/bugs/1566590
<juliank> but is listed on pending-sru
<juliank> But it's not in the changelog
<slangasek> yeah, I was reaching that conclusion
<slangasek> so I'll happily ignore that one
<slangasek> and the verification for LP: 1686064 appears to be "did the autopkgtests pass?"
<ubot5> Launchpad bug 1686064 in sbuild (Ubuntu Zesty) "sbuild ADT test can only pass in devel series" [Medium,Fix committed] https://launchpad.net/bugs/1686064
<juliank> slangasek: So, since the test passed, the bug can be marked as verified
<juliank> yeah
<slangasek> ok, released
<juliank> slangasek: While you're around, do you have an opinion on the apt 1.4.7 (or well, the upcoming 1.4.8) "sync" from stretch? syncpackage would be optimal, but does not create a diff; syncpackage --no-lp probably does because I'd upload a changes myself. I could also edit the changelog and s/stretch/zesty/, but that's sort of boring extra work for no gain.
<juliank> If it's synced changelog still says stretch rather than zesty, but oh well, as long as it lands in the right place...
<juliank> (I modified syncpackage a bit to keep the original .dsc signature too, so the files have the same hashes)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.16]
<slangasek> juliank: well, reviewing SRUs without a queue diff is a nuisance, and likely slows down the processing.  But there's no policy against it
<juliank> slangasek: Right, but if I do --no-lp and upload the changes myself, I'd think there would be a diff. The major question is if somebody would hate changelog mentioning stretch instead of zesty, really.
<slangasek> I don't know
<slangasek> for me, it wouldn't even register as part of SRU processing
<infinity> juliank: I have no issues with a byte-identical sync, but indeed, manually uploading the source instead of doing a copyPackage() LP sync would give us a diff.
<slangasek> RAOF: hi there, would you mind releasing the apparmor xenial SRU today?  I've got the autopkgtest regressions sorted
<RAOF> sure
<slangasek> RAOF: ta
<bdmurray> slangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/phased-updater-more-emails/+merge/330628
#ubuntu-release 2017-09-13
<RAOF> xnox: Are you aware of the autopkgtest failures for apt/zesty-proposed? From a quick look they appear to be due to a real behaviour change.
<nacc> RAOF: there was discussion between slangasek and juliank about that being fixed with sbuild?
<nacc> RAOF: about 6 hours ago, i think
<RAOF> nacc: oooh, ta. Didn't notice the sbuild task.
<nacc> RAOF: np, i wasn't involved, just remembered seeing it go by
<slangasek> nacc, RAOF: yeah, I'm retrying those autopkgtests now that sbuild is in -updates
-queuebot:#ubuntu-release- Unapproved: mdadm (xenial-proposed/main) [3.3-2ubuntu7.2 => 3.3-2ubuntu7.3] (core)
<tsimonq2> slangasek: Is the information here sufficient for an FFE in your eyes? https://bugs.launchpad.net/ubuntu/+source/pupnp-1.8/+bug/1716117
<ubot5> Ubuntu bug 1716117 in pupnp-1.8 (Ubuntu) "pupnp-1.8 1.8.1 should not be released with artful" [Undecided,New]
<tsimonq2> (it's the Debian Maintainer and someone involved with upstream saying that the version in Artful is buggy and shouldn't be shipped, but that changes should be synced from Debian, it technically breaks Feature Freeze so I want to ask before syncing)
<slangasek> tsimonq2: yes. commented to that effect on the bug.
<tsimonq2> slangasek: ack, thank you
-queuebot:#ubuntu-release- New binary: pupnp-1.8 [ppc64el] (artful-proposed/universe) [1:1.8.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pupnp-1.8 [amd64] (artful-proposed/universe) [1:1.8.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pupnp-1.8 [armhf] (artful-proposed/universe) [1:1.8.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pupnp-1.8 [s390x] (artful-proposed/universe) [1:1.8.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pupnp-1.8 [arm64] (artful-proposed/universe) [1:1.8.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: pupnp-1.8 [i386] (artful-proposed/universe) [1:1.8.2-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted pupnp-1.8 [amd64] (artful-proposed) [1:1.8.2-2]
-queuebot:#ubuntu-release- New: accepted pupnp-1.8 [i386] (artful-proposed) [1:1.8.2-2]
-queuebot:#ubuntu-release- New: accepted pupnp-1.8 [arm64] (artful-proposed) [1:1.8.2-2]
-queuebot:#ubuntu-release- New: accepted pupnp-1.8 [ppc64el] (artful-proposed) [1:1.8.2-2]
-queuebot:#ubuntu-release- New: accepted puppetdb [amd64] (artful-proposed) [4.4.1-1]
-queuebot:#ubuntu-release- New: accepted pupnp-1.8 [armhf] (artful-proposed) [1:1.8.2-2]
-queuebot:#ubuntu-release- New: accepted pupnp-1.8 [s390x] (artful-proposed) [1:1.8.2-2]
-queuebot:#ubuntu-release- Unapproved: rejected mdadm [source] (xenial-proposed) [3.3-2ubuntu7.3]
-queuebot:#ubuntu-release- Unapproved: mdadm (xenial-proposed/main) [3.3-2ubuntu7.2 => 3.3-2ubuntu7.3] (core)
-queuebot:#ubuntu-release- Unapproved: cryptkeeper (trusty-proposed/universe) [0.9.5-5.1ubuntu3 => 0.9.5-5.1ubuntu3.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: plymouth (zesty-proposed/main) [0.9.2-3ubuntu15 => 0.9.2-3ubuntu15.1] (core)
-queuebot:#ubuntu-release- Unapproved: plymouth (xenial-proposed/main) [0.9.2-3ubuntu13.1 => 0.9.2-3ubuntu13.2] (core)
<didrocks> good morning
 * slangasek waves
<acheronuk> morning. on glibc, I have no response to my email to upstream KDE dev about the kscreenlocker test regression. I will try again this afternoon if they happen to be around on IRC today.
<LocutusOfBorg> didrocks, do we have voting results? :)
<didrocks> LocutusOfBorg: hum, on what? sorry, out of context
<LocutusOfBorg> DMB
<LocutusOfBorg> but that was a general question
<didrocks> I don't manage the DMB vote
<didrocks> (nor applied to it ;))
<LocutusOfBorg> somebody told that in the voting mail your name was somewhere inside
 * LocutusOfBorg already deleted the email, don't care :)
<LocutusOfBorg> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_31d21ec25959d7d2
<LocutusOfBorg> here they are
<doko> where can I see the test overrides? had mbuffer on ppc64el on my list, but now it's overridden
<LocutusOfBorg> bzr branch bzr+ssh://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/
<LocutusOfBorg> grep mbuffer . -R
<LocutusOfBorg> ./vorlon:force-badtest mbuffer/20161115-1/ppc64el
-queuebot:#ubuntu-release- Unapproved: accepted plymouth [source] (zesty-proposed) [0.9.2-3ubuntu15.1]
-queuebot:#ubuntu-release- Unapproved: accepted plymouth [source] (xenial-proposed) [0.9.2-3ubuntu13.2]
-queuebot:#ubuntu-release- New binary: edk2 [amd64] (artful-proposed/universe) [0~20170911.5dfba97c-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted edk2 [amd64] (artful-proposed) [0~20170911.5dfba97c-1]
<xnox> doko, i am subscribed to the hints-ubuntu branch and get email about it =) very useful to spy on ~ubuntu-release
-queuebot:#ubuntu-release- Unapproved: libvirt (trusty-proposed/main) [1.2.2-0ubuntu13.1.22 => 1.2.2-0ubuntu13.1.23] (kubuntu, ubuntu-desktop, ubuntu-server, virt)
<LocutusOfBorg> maybe the bot here can write something when an hint is changed, or a transition is opened on tracker
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (vivid-proposed/main) [3.19.0-93.101] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-35.39] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.13.0-11.12] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.13.0-11.12]
<slangasek> xnox: is the systemd zesty/armhf autopkgtest failure a test bug that's fixed in artful? or something else?  (been failing since February, and apparently no one has bothered to annotate this, just pushed SRUs through around it :/ )
<xnox> slangasek, so we noticed zesty/armhf autopkgtest failures; improved on them in artful (via upstream bug report and code changes; and added arch-specific skips in debian/tests/); backported that to zesty, but alas that was not enough to fix zesty/armhf
<slangasek> ok
<xnox> slangasek, so further investigation fix-up of zesty/armhf is outstanding
<slangasek> I'm also trying to understand if the zesty-updates/ppc64el failure is a flaky test or something actually fixed in zesty-proposed
<slangasek> diff tells me the answer is 'flaky'
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-96.119] (core, kernel)
<acheronuk> FYI on glibc kscreenlocer test regression. just waiting for upstream to decide on final patch. https://bugs.kde.org/show_bug.cgi?id=384651
<ubot5> KDE bug 384651 in general "kscreenlocker fails SeccompTest with glibc 2.26" [Major,Confirmed]
<acheronuk> *kscreenlocker
<bdmurray> doko: bug 1695093 is missing the standard SRU template although I can kind of guess at the test case
<ubot5> bug 1695093 in Linux "arm64: "unsupported RELA relocation: 275" loading certain modules" [Medium,In progress] https://launchpad.net/bugs/1695093
<bdmurray> doko: and bug 1709727 has a blank regression potential
<ubot5> bug 1709727 in gcc-6 (Ubuntu Zesty) "asan causes hangs on arm64" [Undecided,Triaged] https://launchpad.net/bugs/1709727
<doko> bdmurray: asan is not used in any package afaik. having the timeouts replaced by suceeding tests in the testsuite seems to be better
<doko> bdmurray: and the first one, that should be tested by dannf (and already was with test build)
<doko> actually, tome is using it ...
<bdmurray> doko: I'm saying the bugs are missing SRU information per the SRU policy point 3 here https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<doko> bdmurray: what should I write? that this will regress if the kernel is uploaded again without 48bit-vma support?
<doko> wondering how the kernel SRU looked like when this was changed in the release ...
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-96.119]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-35.39]
<slangasek> doko: you should write things down so that the SRU team doesn't have to know everything you know to tell if the SRU is successful or failed
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (zesty-proposed/main) [2.441.5 => 2.441.6] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.16 => 2.408.17] (desktop-core)
<slangasek> rbasak, arges: hi, does one of you have time to look at the xenial/zesty livecd-rootfs SRUs in the queue above?  These are critical path for getting cloud images building again in LP; if neither of you has time I will self-accept, but I would prefer another set of eyeballs if possible
<bdmurray> I think rbasak is on holiday
<nacc> bdmurray: yeah, until next week (and only partial next week, i beleive)
<slangasek> ok
<slangasek> bdmurray: do you have a minute to look?
<bdmurray> slangasek: sure, just a moment
<doko> slangasek: could you have a look at the pcs autopkg test failure triggered by python2.7?  you looked at that package before ...
<slangasek> doko: checking
<slangasek> doko: very different error than what I was fixing before; I was just fixing the proxy env handling on the package, this new error seems to care about something else.  But let's see
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (zesty-proposed) [2.441.6]
<cjwatson> slangasek: (they shouldn't in fact be critical-path now; I fixed this issue in two different ways on the principle of defence in depth, one of which was in launchpad-buildd and is already deployed)
 * bdmurray stops then
<slangasek> cjwatson: hmm; rcj tells me image builds are still failing
<cjwatson> slangasek: ah, depends what the change is
 * cjwatson goes to check
<cjwatson> there have been several different failures
<slangasek> cjwatson: this is related to us not unwinding our own submounts, it's not the lxd dev bind mount thing
 * bdmurray starts again
<cjwatson> ah, that
<cjwatson> yeah, I think vanilla images are OK but not CPC
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.17]
<slangasek> unfortunately there was a change already staged for SRU when this came in, so that landed and revealed some more brittleness in the cpc sauce
<slangasek> which is now being made less brittle
<cjwatson> right, it could have been done just in CPC, but I agree it's probably better to fix here
<cjwatson> slangasek: er, isn't the umount_partition change wrong though?
<slangasek> not to my knowledge! :)
<cjwatson> slangasek: teardown_mountpoint umounts everything under $mountpoint, but not $mountpoint itself, so that's a significant change in behaviour, probably not for the better
<cjwatson> slangasek: (it also now involves two udevadm settle calls, though that's a minor point)
<slangasek> cjwatson: ah - the point is that there are some times when the top-level dir is not a mount point (because e.g. it's a source dir for mksquashfs); so we now have a function which is symmetric with setup_mountpoint, to only tear down the bits /under/ that dir
<cjwatson> slangasek: I agree, but that's not where umount_partition is used
<cjwatson> slangasek: teardown_mountpoint makes sense for those cases and I agree with its introduction
<cjwatson> slangasek: but e.g. in live-build/ubuntu-cpc/hooks/032-disk-image.binary, umount_partition must umount $mountpoint as well or the following rmdir will fail
<slangasek> cjwatson: ah. we leave the 'umount -R $mountpoint' in place below that
<cjwatson> slangasek: that's not what I see in http://launchpadlibrarian.net/336881284/livecd-rootfs_2.441.5_2.441.6.diff.gz ?
<cjwatson>  umount_partition() {
<cjwatson>      local mountpoint=${1}
<cjwatson> -    mv resolv.conf.tmp "$mountpoint/etc/resolv.conf"
<cjwatson> -    umount -R $mountpoint
<cjwatson> +    teardown_mountpoint $mountpoint
<slangasek> looking
<slangasek> it looks correct on xenial
<slangasek> yeah, zesty's is borked
<cjwatson> also trunk
<acheronuk> is there a problem publishing from proposed to release? getting multiple instances of unsatisfiable deps
<slangasek> cjwatson: thanks - clearly rcj and I had a blindspot
<cjwatson> lucky I happened to look at zesty :)
<cjwatson> the /var/{cache,lib}/apt divergence is odd, but I assume that's due to existing weirdness
<slangasek> yes
<rcj> slangasek, cjwatson: I screwed up the patch on trunk and zesty when I tried to apply it from xenial.
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (zesty-proposed/main) [2.441.6 => 2.441.7] (desktop-core)
<slangasek> ^^ self-accepted
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (zesty-proposed) [2.441.7]
<acheronuk> Ok. I hope sorted now. sorry to interrupt you 2. Usually publishing delays on seem to make things uninstalable for a few mins, but that was nearly an hr
<slangasek> acheronuk: http://people.canonical.com/~ubuntu-archive/proposed-migration/artful_uninst.txt will generally show the current state
<acheronuk> slangasek: thank you :)
<acheronuk> that reminds me that I need to make a decision on cantor :/
<slangasek> doko: badtest; it looks for /etc/init.d/networking to know if 'lsb:networking' is available; so pacemaker-cli-utils is now buggy
<slangasek> doko: actually it's one step down from pcs though, so probably skiptest here
<doko> slangasek: if you skiptest, please could you ignore the test failures for twisted? twisted itself is blocked (free is working on that), so that python2.7 with dropping the _fpectl extension can migrate?
<doko> bdmurray: bug descriptions are updated
<slangasek> doko: yes, I'll see what I can sort out.  FWIW there's a new pacemaker in -proposed also, which ftbfs; I can't tell if it fixes this problem or not since I can't find any references to /etc/init.d/networking in pacemaker source
<nacc> slangasek: which problem?
<slangasek> nacc: pcs autopkgtest fails because crm_thingy resource yadda lsb:networking tries to look at /etc/init.d/networking, which is from ifupdown and no longer exists
<nacc> slangasek: ah
<doko> armhf only?
<slangasek> timing of the run vs. availability of ifupdownless image?
<slangasek> I can reproduce the specific failure here on amd64 in an ifupdownless chroot
<nacc> slangasek: isn't that from src:pcs itself?
<nacc> slangasek: it's tests seem to do some lsb:networking stuff?
<slangasek> $ crm_resource --show-metadata lsb:networking
<slangasek> Metadata query for lsb:networking failed: -2
<slangasek> nacc: ^^
<slangasek> strace on that shows it trying to access /etc/init.d/networking
<slangasek> this is independent of pcs
-queuebot:#ubuntu-release- Unapproved: accepted gcc-5 [source] (xenial-proposed) [5.4.0-6ubuntu1~16.04.5]
<slangasek> but I haven't pinned this down in source yet
<nacc> slangasek: i think lrmd_api_get_metadata -> lsb_get_metadata -> LSB_ROOT_DIR
<nacc> include/crm/services.h:#    define LSB_ROOT_DIR "/etc/init.d"
<nacc> presuming it's a lsb:networking query?
<slangasek> y
<slangasek> so does this mean 'lsb' always just looks at /etc/init.d?
<nacc> slangasek: if it isn't given an absolute path (e.g. lsb:/etc/networking would look there)
<nacc> slangasek: but for lookup by type, i think so
<slangasek> ok so it is a pcs bug
<slangasek> nacc: thanks, badtesting pcs then
<nacc> the above is in src:pacemaker, but it's all so intertwined :)
<nacc> slangasek: np
<slangasek> doko: I'm not sure I understand what you're asking for wrt twisted.  You said twisted is blocked and free is working on it; if twisted is blocked, what is helped by ignoring its test failures?
<slangasek> doko: the one last thing I do see blocking python2.7 is this darn openvswitch/i386
<doko> jamespage: told me that this is caused by some setup issue, nplan if I correctly remember
<slangasek> however, openvswitch/i386 has had passing tests in between the failures
<doko> hrm, twisted doesn't show up there anymore ...
<doko> strange
<doko> so twisted is not a blocker for python2.7
<slangasek> according to http://autopkgtest.ubuntu.com/packages/t/twisted/artful/amd64 twisted was only being tested for -defaults, not for 2.7
<slangasek> "conveniently"
<doko> hahaha
<doko> also was wondering about the little amount of libjpeg-turbo dependencies ... another dependency package issue
-queuebot:#ubuntu-release- New: accepted python-certbot [amd64] (xenial-proposed) [0.14.2-0ubuntu0.16.04.1]
<robert_ancell> Who can I bribe to get snapd-glib out of the trust NEW queue? bug 1698984
<ubot5> bug 1698984 in snapd-glib (Ubuntu) "Add snapd-glib to Ubuntu 14.04 LTS" [Wishlist,Fix committed] https://launchpad.net/bugs/1698984
<slangasek> jamespage: AIUI we're still waiting for an openstack team decision on xclip vs. xsel on LP: #1713617
<ubot5> Launchpad bug 1713617 in xclip (Ubuntu) "[MIR] python-pyperclip, xclip" [High,Incomplete] https://launchpad.net/bugs/1713617
<slangasek> robert_ancell: I might be amenable to bribing on Friday :)
<robert_ancell> slangasek, (bribe may delayed until NY)
<jamespage> slangasek: yeah sorry I'll get that sorted now
-queuebot:#ubuntu-release- New binary: python-certbot-apache [amd64] (xenial-proposed/universe) [0.14.2-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-certbot-nginx [amd64] (xenial-proposed/universe) [0.14.2-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted python-certbot-apache [amd64] (xenial-proposed) [0.14.2-0ubuntu0.16.04.1]
<slangasek> LocutusOfBorg: puma 3.6.0-1build1, what prompted that?  The existing package was FTBFS, so not much point in a no-change rebuild...
#ubuntu-release 2017-09-14
<sergiusens> slangasek hey there! Mind if we let snapcraft into xenial- and zesty-updates? armhf adt failures are timeouts in different locations and different network failures on different runs
<slangasek> sergiusens: I don't want to skip these without an understanding of the failures (and why a retry wouldn't fix).  The most recent test run on both xenial and zesty failed with a ProxyErro; do we have an issue with the proxy in the DC?
<slangasek> what is meson and why is it terrible?
<sergiusens> slangasek they usually fail randomly like this on armhf, not the first time we bring it up
<Ukikie> It's the latest fad to replace autotools as a buildsystem, python based.  debhelper supports it, more or less.
<slangasek> sergiusens: "timeout" is not the same thing as "network error"
<sergiusens> slangasek is the meson question for me? Everyone is moving to meson these days
<slangasek> sergiusens: no, that's a question for the aether in response to yet another autopkgtest failing randomly because meson falls over randomly
<Ukikie> (FSVO "everyone", the hip ones like systemd and GNOME are moving at least.)
<sergiusens> slangasek meson in artful changed its limitations, targets cannot start with `meson-`
<sergiusens> in case it helps
<Ukikie> sergiusens: Did you see meson got cross support?  Looks like debhelper is getting it soon too.
<sergiusens> slangasek ok, I said timeouts incorrectly, it is things like this that fail "fatal: unable to access 'https://github.com/jocave/simple-make-filesets.git/': Could not resolve proxy: squid.internal"
<sergiusens> and "<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0xf6b29d30>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution"
<sergiusens> it is very common on armhf for us
<slangasek> ok
<sergiusens> maybe too many adt tests run on the same machine saturating the network driver (I am just making this up) :-)
<slangasek> I know I've seen more name resolution errors for armhf than on other archs
<slangasek> I chalked that up to discrete infrastructure events
<sergiusens> slangasek fwiw, the tests did pass before we merged and tagged the release
<slangasek> if we're seeing that consistently, I want to make sure we are following up on that before I start overriding autopkgtest failure
<slangasek> s
<slangasek> so, I'll dig into this but it will take me a while this evening; I'm now afk
<sergiusens> slangasek fwiw, the armhf adt test that passed I usually run during the weekend
<sergiusens> which brings in "load" as a possible root cause
<sergiusens> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-snapcraft-daily/xenial/armhf/s/snapcraft/20170909_191306_ef78d@/log.gz and https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-snapcraft-daily/zesty/armhf/s/snapcr
<sergiusens> aft/20170910_005841_ef78d@/log.gz fwiw
<slangasek> infinity: libhybris is going to need porting for glibc 2.26; it has revdeps, a strict versioned dep on libc6, and ftbfs with 2.26.
<slangasek> I see there's still an active upstream at https://github.com/libhybris/libhybris; maybe morphis can help with this
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.17 => 2.408.18] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (zesty-proposed/main) [2.441.7 => 2.441.8] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.18]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (zesty-proposed) [2.441.8]
<infinity> slangasek: Ugh.  How did we not kill hybris in a fire when phone stuff went away?
<infinity> slangasek: Or, more to the point, can we petition for its violent removal on the grounds of it never having been a good idea, and certainly not sanely supportable? :P
<slangasek> infinity: hybris is a thing of beauty, you infidel
<slangasek> infinity: anyway, it has revdeps, so pick your poison
<slangasek> it's possible that the mir team are legitimately still using it
<slangasek> hard to tell; but at least, it wouldn't be that quick to chase down
<infinity> slangasek: You and I define beauty slightly differently.
<LocutusOfBorg> slangasek, you completely right, the problem has been a typo in rmadison
<LocutusOfBorg> I was trying to fix undertaker, and libpuma-dev is not provided by src:puma but src:aspectc++
<LocutusOfBorg> damn
 * LocutusOfBorg goes fixing them now that he is awake
<LocutusOfBorg> puma, aspectc++, libsoap-site-perl, libauthen-captcha-perl, undertaker should be all fixed now
-queuebot:#ubuntu-release- New binary: puma [ppc64el] (artful-proposed/universe) [3.6.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: puma [s390x] (artful-proposed/universe) [3.6.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: puma [amd64] (artful-proposed/universe) [3.6.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: puma [armhf] (artful-proposed/universe) [3.6.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: puma [arm64] (artful-proposed/universe) [3.6.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: puma [i386] (artful-proposed/universe) [3.6.0-1ubuntu1] (no packageset)
<cpaelzer> hi, the current migration of a bunch of dpdk fixes in artful (17.05.2-0ubuntu1) is blocked by bug 1712831
<ubot5> bug 1712831 in linux (Ubuntu Artful) "4.12.0-11-generic - crashing in infrastructure on i386 openvswitch tests" [High,Triaged] https://launchpad.net/bugs/1712831
<cpaelzer> There isn't an ETA on this issue yet, so I wanted to ask if one could hint the autopkgtest of openvswitch on i386 to be non-gating
<cpaelzer> If you can make depends then this is true for kernels >=4.12
<acheronuk> kscreenlocker all passed for glibc now
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-132.181] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-132.181]
<LocutusOfBorg> [12:06:16] <BTS> libgit2 0.26.0+dfsg.1-1.1 uploaded by Ximin Luo (infinity0) https://tracker.debian.org/libgit2
<LocutusOfBorg> folks,what is your opinion wrt libgit2?
<LocutusOfBorg> maybe we can do it for 18.04
<juliank> rbalint: I believe unattended-upgrades.service should gain a Before=apt-daily.service, so that when shutting down, and apt-daily.service is already running, unattended-upgrades.service stops after it.
<juliank> oops, wrong channel
 * doko goes fixing gcc-3.3 :-/
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-96.119~14.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.10.0-35.39~16.04.1] (kernel)
<cpaelzer> reasking if one could please make dpdk pass migration in artful, blocked on i386 autopkgtest by kown kernel bug since 4.12 (bug 1712831)
<ubot5> bug 1712831 in linux (Ubuntu Artful) "4.12.0-11-generic - crashing in infrastructure on i386 openvswitch tests" [High,Triaged] https://launchpad.net/bugs/1712831
<LocutusOfBorg> doko, get rid of it? I read debian bug: #855851 do you have examples of reverse-deps?
<ubot5> Debian bug 855851 in src:gcc-3.3 "gcc-3.3: still in stretch" [Wishlist,Open] http://bugs.debian.org/855851
<LocutusOfBorg> doko, you are on a roll :) thanks for the llvm fix!
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-96.119~14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.10.0-35.39~16.04.1]
<sergiusens> slangasek so what is the plan of action on those snapcraft armhf failures? Do I have to run until it is green?
<sergiusens> I re-triggered earlier today and waiting on the results
<chiluk> Hey one of the ubuntu-release guys, to comment on https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1712925 in regards to my FFE?  Today is UI freeze and I do have UI changes.
<ubot5> Ubuntu bug 1712925 in haproxy (Ubuntu) "FFE: HAproxy dropping connections (RST) during config reload / support seamless reload" [Undecided,New]
<nacc> heh "updated software is available since 17.10 was released". Excellent!
<chiluk> stgraber, laney, langasek ^^ can one of you approve or reject my FFE. I should be ready to upload it today. It's baked enough in our infrastructure at indeed that I feel confident with it now.
<Laney> cpaelzer: done
<Laney> chiluk: I'd rather one of the others TBH, and you spelt slangasek wrong ;-)
<chiluk> woops...
<chiluk> I guess it's just been too long.
<slangasek> sadly I still got the highlight
<chiluk> yet ignored it... I see where I stand.
<slangasek> been in a meeting, dude :)
<chiluk> I figured ... I just miss being part of all the fun.
<bdmurray> sil2100: Could you review my network-manager uploads in the -proposed unapproved queue?
<sil2100> bdmurray: sure, I'll do that after the meetings no problem
<chiluk> thanks a ton slangasek.
<smoser> slangasek, http://autopkgtest.ubuntu.com/packages/o/open-iscsi/artful/amd64 can you let open-iscsi through in artful
<smoser> that came in under https://code.launchpad.net/~smoser/ubuntu/+source/open-iscsi/+git/open-iscsi/+merge/330315
<smoser> read the description there to see why it is right to let it in.
<stgraber> speaking of FFes that would be nice to process soon-ish, can someone take a look at https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1715278 ?
<ubot5> Ubuntu bug 1715278 in lxc (Ubuntu) "[FFe] LXC 2.1" [Undecided,New]
<sergiusens> slangasek so there are three runs for each of zesty and xenial on armhf failing due to network errors in different tests, can we consider adding up the three runs and consider it a pass and let them into -updates? Maybe a question for sil2100 as he's on guard. FWIW, this is also not the first time we've asked or done this.
<slangasek> smoser: fwiw the quicker path for me to unblock this is pointing out that the hint for the old version (as seen in lp:~ubuntu-release/britney/hints-ubuntu/) still applies
<slangasek> smoser: hinted
<slangasek> sergiusens: I said yesterday that I wanted to identify a path to resolving these network issues before I was willing to ignore the failures; you are now pressuring me again to ignore the failures, when nothing has changed here.  If you're not going to take the CI gate seriously, why are you wasting compute time running these tests on armhf?
<sergiusens> slangasek sorry, I think I just misunderstood what the path was given my first message of the day :-) I'll sit and wait then
-queuebot:#ubuntu-release- Unapproved: debian-installer (xenial-proposed/main) [20101020ubuntu451.14 => 20101020ubuntu451.15] (core)
<Laney> I'd be much obliged if someone would binNEW review the new wallpapers once they pop up
 * Laney is squeezing in on the right side of UIF
<Laney> well, assuming I didn't mess up :P
<smoser> slangasek, well... that would imply that this "bad test" was in fact bad. when in fact at this point the truth is that the OS is bad.
<smoser> but thanks for the link to hints-ubuntu
-queuebot:#ubuntu-release- New binary: ubuntu-wallpapers [amd64] (artful-proposed/main) [17.10.0-0ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (zesty-proposed) [1.4.4-1ubuntu3.2]
<bdmurray> tjaalton: Were you still planning on upload the sssd part of the fix for bug 1641203?
<ubot5> bug 1641203 in sssd (Ubuntu Xenial) "SSSD can't process GPO from Active Directory when it contains lines with no equal sign" [Medium,Triaged] https://launchpad.net/bugs/1641203
-queuebot:#ubuntu-release- Unapproved: kexec-tools (xenial-proposed/main) [1:2.0.10-1ubuntu2.3 => 1:2.0.10-1ubuntu2.4] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (zesty-proposed) [2:15.0.6-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: crash (xenial-proposed/main) [7.1.4-1ubuntu4.1 => 7.1.4-1ubuntu4.2] (core) (sync)
<tjaalton> bdmurray: well, 1.13.5 is not out yet :p
<tjaalton> i'll poke upstream
-queuebot:#ubuntu-release- Unapproved: accepted libc++ [source] (xenial-proposed) [3.7.0-1ubuntu0.1]
<bdmurray> xnox: Can you add some SRU information to bug 1600000?
<ubot5> bug 1600000 in systemd (Ubuntu Xenial) "libnss-resolve treats two trailing dots on a domain name incorrectly" [Low,In progress] https://launchpad.net/bugs/1600000
<bdmurray> xnox: Bug 1715131 too
<ubot5> bug 1715131 in systemd (Ubuntu Xenial) "networkd add support for Bridge Priority, AgeingTimeSec and DefaultPVID" [Undecided,In progress] https://launchpad.net/bugs/1715131
-queuebot:#ubuntu-release- Unapproved: accepted mdadm [source] (xenial-proposed) [3.3-2ubuntu7.3]
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (xenial-proposed) [20101020ubuntu451.15]
-queuebot:#ubuntu-release- New binary: ldc [ppc64el] (artful-proposed/universe) [1:1.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ldc [amd64] (artful-proposed/universe) [1:1.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ldc [i386] (artful-proposed/universe) [1:1.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted puma [amd64] (artful-proposed) [3.6.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted puma [armhf] (artful-proposed) [3.6.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted puma [ppc64el] (artful-proposed) [3.6.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted ubuntu-wallpapers [amd64] (artful-proposed) [17.10.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted puma [arm64] (artful-proposed) [3.6.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted puma [s390x] (artful-proposed) [3.6.0-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted puma [i386] (artful-proposed) [3.6.0-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted gdebi [source] (trusty-proposed) [0.9.5.3ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted cryptkeeper [source] (trusty-proposed) [0.9.5-5.1ubuntu3.1]
-queuebot:#ubuntu-release- New binary: ldc [armhf] (artful-proposed/universe) [1:1.3.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted ldc [amd64] (artful-proposed) [1:1.3.0-2]
-queuebot:#ubuntu-release- New: accepted ldc [i386] (artful-proposed) [1:1.3.0-2]
-queuebot:#ubuntu-release- New: accepted ldc [armhf] (artful-proposed) [1:1.3.0-2]
-queuebot:#ubuntu-release- New: accepted ldc [ppc64el] (artful-proposed) [1:1.3.0-2]
<doko> I'm curious about: Depends: gcc-snapshot glibc (not considered)
<doko> because the dependencies don't show a dependency on glibc (>= 2.26)
-queuebot:#ubuntu-release- Unapproved: mdadm (xenial-proposed/main) [3.3-2ubuntu7.3 => 3.3-2ubuntu7.4] (core)
<infinity> doko: Looks like armhf has a 2.26 dep.
<doko> ohh, only looked at amd64 and i386
-queuebot:#ubuntu-release- Unapproved: accepted mdadm [source] (xenial-proposed) [3.3-2ubuntu7.4]
<xnox> bdmurray, yes.
<bdmurray> xnox: thanks, feel free to ping me when its ready for review
<xnox> bdmurray, ok, thank you.
-queuebot:#ubuntu-release- Unapproved: accepted kexec-tools [sync] (xenial-proposed) [1:2.0.10-1ubuntu2.4]
-queuebot:#ubuntu-release- Unapproved: python3.5 (xenial-proposed/main) [3.5.2-2ubuntu0~16.04.2 => 3.5.2-2ubuntu0~16.04.3] (core)
-queuebot:#ubuntu-release- Unapproved: python3.5 (zesty-proposed/main) [3.5.3-1ubuntu0~17.04.0 => 3.5.3-1ubuntu0~17.04.1] (core)
<infinity> bdmurray: A previous SRU for that bug was rejected for not having a testcase in the bug.
<infinity> bdmurray: Any chance of doing a tiny bit o' boilerplate?
<bdmurray> infinity: I'm aware and doing that now
<infinity> bdmurray: \o/
<wxl> hey infinity i've recently cleaned and noticed i've been hiding this PowerMac G5 from myself. i remember you had some interest in it if it runs. is that still the case?
#ubuntu-release 2017-09-15
<infinity> wxl: Probably less interest than I used to have, given than we've dropped support.
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (vivid-proposed) [3.19.0-93.101]
<acheronuk> morning. some possible weirdness with s390x tests? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kcoreaddons
<acheronuk> whating https://autopkgtest.ubuntu.com/running it seems that those are constantly starting over, and never completing?
<acheronuk> *watching
<jbicha> please ignore flatpak/ppc64el autopkgtests http://autopkgtest.ubuntu.com/packages/f/flatpak/artful/ppc64el
-queuebot:#ubuntu-release- New binary: retro-gtk [amd64] (artful-proposed/universe) [0.12.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: retro-gtk [ppc64el] (artful-proposed/universe) [0.12.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: retro-gtk [i386] (artful-proposed/universe) [0.12.0-2] (no packageset)
<jbicha> approved ffe for retro-gtk is LP: #1714807
<ubot5> Launchpad bug 1714807 in retro-gtk (Ubuntu) "[FFe] Update gnome-games-app to 3.26 (and retro-gtk to 0.12)" [Undecided,Fix released] https://launchpad.net/bugs/1714807
-queuebot:#ubuntu-release- New binary: retro-gtk [armhf] (artful-proposed/universe) [0.12.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: retro-gtk [s390x] (artful-proposed/universe) [0.12.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: retro-gtk [arm64] (artful-proposed/universe) [0.12.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted retro-gtk [amd64] (artful-proposed) [0.12.0-2]
-queuebot:#ubuntu-release- New: accepted retro-gtk [armhf] (artful-proposed) [0.12.0-2]
-queuebot:#ubuntu-release- New: accepted retro-gtk [ppc64el] (artful-proposed) [0.12.0-2]
-queuebot:#ubuntu-release- New: accepted retro-gtk [arm64] (artful-proposed) [0.12.0-2]
-queuebot:#ubuntu-release- New: accepted retro-gtk [s390x] (artful-proposed) [0.12.0-2]
-queuebot:#ubuntu-release- New: accepted retro-gtk [i386] (artful-proposed) [0.12.0-2]
-queuebot:#ubuntu-release- Unapproved: walinuxagent (trusty-proposed/main) [2.2.16-0ubuntu1~14.04.1 => 2.2.17-0ubuntu1~14.04.1] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (zesty-proposed/main) [2.2.16-0ubuntu1~17.04.1 => 2.2.17-0ubuntu1~17.04.1] (ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: walinuxagent (xenial-proposed/main) [2.2.16-0ubuntu1~16.04.1 => 2.2.17-0ubuntu1~16.04.1] (ubuntu-cloud, ubuntu-server)
<ginggs> would someone please 'force-skiptest gyoto' or whatever is needed, it takes *hours* and has never passed - see debian #869980
<ubot5> Debian bug 869980 in src:gyoto "gyoto: test suite times out" [Normal,Open] http://bugs.debian.org/869980
<slangasek> ginggs: if it's never passed, it wouldn't be a blocker now either, though?
<slangasek> ginggs: and indeed, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html only has one reference to it, where it shows as 'always-failed'
-queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (xenial-proposed) [2:1.18.4-0ubuntu0.5]
<ginggs> slangasek: yup, it's not a blocker, it's just an incredible waste of resources
<ginggs> http://autopkgtest.ubuntu.com/packages/g/gyoto/artful/amd64 6 to 9 hours a pop
<slangasek> ginggs: force-skiptest doesn't stop the tests from being tried
<slangasek> there is a blacklist in autopkgtest that we could add it to
<ginggs> slangasek: oh, ok.  i was confused by the name
<ginggs> slangasek: would you consider updating the hints for casync to 2.1ubuntu1 and possibly ignoring i386 as well?
<slangasek> ginggs: not without analysis, because the bug I was hinting for in casync 2-1 is what I /fixed/ in 2-1ubuntu1
<ginggs> slangasek: ok, thanks
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (zesty-proposed) [2.2.17-0ubuntu1~17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (xenial-proposed) [2.2.17-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (trusty-proposed) [2.2.17-0ubuntu1~14.04.1]
<bdmurray> apw, infinity: steve tells me you two are working on making sure that there aren't two vmlinuz files for secureboot kernels. Is there a bug for that?
-queuebot:#ubuntu-release- Unapproved: accepted crash [sync] (xenial-proposed) [7.1.4-1ubuntu4.2]
<wxl> infinity: yay i'll get rid of it :)
<slangasek> time to send it freegeek's direction :P
<wxl> slangasek: i'm a little farther south so it will go to nextstep, but, yes, same idea :)
<jbicha> slangasek: could you ignore autopkgtest failure for flatpak/ppc64el ? http://autopkgtest.ubuntu.com/packages/f/flatpak/artful/ppc64el
<jbicha> they accidentally started passing (!) ;)
<acheronuk> wish I could get some to do that!
<ginggs> would someone please 'force badtest python-scipy/0.18.1-2ubuntu4/i386' - one test is failing due to floating point tolerance
<LocutusOfBorg> do you think it is possible to force-badtest mariadb-10.1/10.1.26-1: on ppc64el and s390x? it is regressed in release
<LocutusOfBorg> also flatpack seems really regressed in release, blocking security fixes for libarchive
<jbicha> flatpak didn't regress, the autopkgtests accidentally started working briefly (this happened earlier on other arches)
<slangasek> ginggs: I show a passed test for python-numpy w/ latest lapack+atlas?
<slangasek> jbicha: why did this flatpak test start succeeding / failing? what server is returning this '503 unavailable'?
<slangasek> (anyway, hint added)
<ginggs> slangasek: ok, i think i missed something - running another test now
<slangasek> hmmmm why did sru-review not set verification-needed tags on LP: #1717306?
<ubot5> Launchpad bug 1717306 in walinuxagent (Ubuntu Zesty) "waalinuxagent 2.2.17" [Undecided,Fix committed] https://launchpad.net/bugs/1717306
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.9-233-ge586fe35-0ubuntu1~16.04.1 => 0.7.9-233-ge586fe35-0ubuntu1~16.04.2] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-233-ge586fe35-0ubuntu1~17.04.1 => 0.7.9-233-ge586fe35-0ubuntu1~17.04.2] (edubuntu, ubuntu-cloud, ubuntu-server)
<ginggs> slangasek: i'm not seeing what you are seeing. http://autopkgtest.ubuntu.com/packages/p/python-scipy/artful/i386 0.18.1-2ubuntu4 	lapack/3.7.1-3ubuntu2 atlas/3.10.3-4 openblas/0.2.20+ds-3 python-numpy/1:1.12.1-3.1ubuntu4 python-scipy/0.18.1-2ubuntu4 	2017-09-15 19:43:57 UTC 	1h 16m 10s 	fail
<ginggs> slangasek: FAIL: test_orthogonal.test_j_roots / AssertionError:
<ginggs> Not equal to tolerance rtol=1e-15, atol=2e-13
<ginggs> slangasek: it has been failing that way since 2017-08-05 when atlas got a no-change rebuild when we switched to GCC 7
<slangasek> ginggs: oh sorry, you said scipy and I was looking at numpy
<slangasek> ginggs: so, I'm not willing to overlook a floating point tolerance regression to let in packages that are entirely numbers
<doko> one more point to drop i386 ...
<slangasek> sure
<slangasek> which would be more appropriate than badtesting it
<doko> please reconsider that, that's the last one having the _pyFpe references in the -release pocket
<doko> slangasek: glibc is now left with casync, twisted, why3 and click
<doko> - twisted: can we ignore that one for glibc without letting twisted migrate?
<doko> - click: I think somebody else asked to ignore the failing test on ppc64el
<infinity> doko: twisted just looks like the testsuite needs adjusting for the fact that TLSv1 is disabled?
<doko> - why3: I think xnox promised to have a look. otoh, I'm happy to look at what requires removal
<doko> infinity: yes, free said he was working on it
<doko> - casync: you wanted to have a look
<xnox> sigh that
<infinity> doko: Anyhow, I think it's clear that the twisted (both old and new) and casync failures aren't glibc's fault, so while I'd like to see them fixed, I'll be happy to skip past them after why3 and click are understood/fixed.
<infinity> (That's with a release team hat on, not a glibc maintainer who wants his package to migrate :P)
<doko> infinity: are you ok, if I investigate how to remove click on ppc64el?  it's obsolete anyway, so this looks more productive
<doko> xnox: ^^^
<infinity> doko: Yeah, that wouldn't bug me terribly.  I don't think it would ever have had users on ppc64el anyway.
<doko> infinity: in that case, please ignore, and we save both valuable time
<infinity> doko: But it might be nice to know why/how it broke, to ease our minds that it's not actually a toolchain bug somewhere.
<doko> I'm sure we have more imprtant toolchain issues to resolve
<infinity> I vew glibc/gcc/binutils autopkgtest results more as a wide net to try to catch issues that might crop up elsewhere, rather than just "let's make all the tests pass or go away".
<doko> sure, but not for corner cases like ocaml on s390x
<infinity> doko: Anyhow, looks like the click rdep chain is pretty shallow, so removals aren't the worst answer.  If it's also made to not build on ppc64el anymore.
<infinity> In fact, it looks like it's just libusermetrics?
<infinity> Ahh, and a few more in build-deps.
<infinity> click-systemd, click-apparmor, unity-scopes-api...
<infinity> But entirely manageable, and I don't think any ppc64el click packages ever existed, so the packaging toolchain is clearly not in use.
<infinity> (Same argument could be made for dropping it from s390x too, IMO, and just letting it live on x86/arm* until it dies entirely)
<xnox> infinity, i filed removal bugs for src:click in artful.
<doko> just make sure that calc-stats relies on it ...
<infinity> xnox: Well, that would be even better.
<xnox> infinity, https://bugs.launchpad.net/ubuntu/+bugs?field.tag=u8rm
<xnox> infinity, with "importance" used to sort how to remove things. There are mutually reversencing things.
<infinity> xnox: I'd certainly prefer total removal, if that's agreed on by whomever needs to do the agreeing.
<xnox> infinity, yes yes yes. jdstrand was begging to have click removed.
<infinity> Heh.
<infinity> doko: ^-- Well, there you go.  Self-solving problem.
<xnox> if you or slangasek could process https://bugs.launchpad.net/ubuntu/+bugs?field.tag=u8rm then click and gcc-4.7 can be removed
<infinity> xnox: I don't suppose hybris is on your hit list?
<doko> infinity: so you can override it and then we remove it for a?
<doko> hybris is obsolete with ubuntu-touch
<infinity> doko: I'll do the removals, if britney isn't smart enough to notice, then I'll hint it too.
<infinity> hybris has rdeps that aren't being removed, so while I agree it should be obsolete, it needs code changes to tear it out, I believe.
<xnox> infinity, libhybris too but that needs fixing first....
<infinity> xnox: Well, the time is now.
<infinity> xnox: Cause hybris has a strict versioned glibc dep, so it either needs to be ported or torn out, and I'd really prefer the latter.
<xnox> infinity, sure please process these https://bugs.launchpad.net/ubuntu/+bugs?field.tag=u8rm and then i will continue my crusade.
<slangasek> yes, libhybris is uninstallable with new glibc and unbuildable with new everything
<xnox> sigh, ok
<infinity> xnox: Yeahp, I have that open in a browser, will process the current set tonight, with a bit of wine and some glee.
<infinity> The emotion, not the television show.
<doko> ahh, I got the perl bug fix message, but not yet the migration message
<slangasek> so someone has analyzed the remaining casync failures and confirmed they're not glibc-induced?
<slangasek> is that someone also adding a badtest hint?
<doko> slangasek: sorry, I had the impression you would do that
<slangasek> doko: well, I said I was going to look, and I have time to do so right now, but infinity also asserted that it's not glibc's fault
<slangasek> and... those are some interesting combinations of autopkgtest triggers on the retry?
<doko> anyway, it's time to leave for me for the day
<infinity> slangasek: I've asserted that it was failing before glibc was uploaded.
<infinity> slangasek: Your build failure fix appears to have been necessary, but then the failure that -1ubuntu1 see is the same that -1 saw before glibc was updated.
<infinity> (Which leads to the annoying reality that we probably want to let -1ubuntu1 in, despite it not passing its tests)
<slangasek> right, and that failure seems to be "have a thing that's not a thing"
<infinity> So, I think we badtest -1ubuntu1 and let it slide in.
<slangasek> yeah, working on that now
<infinity> With a bit of nose-pinching.
<slangasek> done
<slangasek> nice coincidence that the testsuite is reliable on the container archs
<infinity> Reliable, or not run?
<infinity> Huh, reliable.
<infinity> Well, that's backwards.
<cjwatson> click/ppc64el is almost certainly something wrong with its horrible LD_PRELOAD wrapper, in case you're wondering; it's the sort of thing that might break even with legit toolchain changes.
<cjwatson> I wouldn't lose too much sleep over it.
<slangasek> infinity: ah it actually self-disables the nbd test if it can't modprobe nbd. which it can't. because container.
<slangasek> cjwatson: yeah, but I dug in and couldn't figure out why it was failing; it could actually be a glibc regression
<slangasek> cjwatson: e.g. when I added a debugging printf() into the module init function, the segfault went away
<cjwatson> I'm pretty sure I've had that before with real clickpreload bugs
<slangasek> k
<cjwatson> It's painful to debug
<cjwatson> gdb is probably a better place to start if you want to dig
<slangasek> that is where I started ;)
<cjwatson> did you get a backtrace?
<slangasek> not a meaningful one
<infinity> Given the complete lack of regressions elsewhere, I'm kinda okay with the "ignore it cause we're removing it" path.
<cjwatson> I think I've also had luck divining things from valgrind before
<cjwatson> Dunno how well that works on ppc64el
<slangasek> there was a bit of gdb, a bit of LD_DEBUG=, and a bit of valgrind, and I didn't manage to find anything that gave me a clue
#ubuntu-release 2017-09-16
<LocutusOfBorg> can you please kick vdr-plugin-osdteletext out from artful?
<LocutusOfBorg> I can't fix it, I'm fixing the others
<LocutusOfBorg> also vdr-plugin-infosatepg
<LocutusOfBorg> vdr-plugin-epgsync vdr-plugin-skinenigmang and vdr-plugin-remoteosd
<LocutusOfBorg> they are all RC buggy in Debian, out of stretch, and blocking vdr migration (I fixed a bunch of the failures by using the old deprecated api, such plugins needs rewriting)
-queuebot:#ubuntu-release- Unapproved: borgbackup (xenial-proposed/universe) [1.0.7-0ubuntu1.16.04.1 => 1.0.11-0ubuntu1.16.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: borgbackup (zesty-proposed/universe) [1.0.10-2 => 1.0.11-0ubuntu1.17.04.2] (no packageset)
<LocutusOfBorg> is anybody caring about mariadb-10 failures / regressions in release (ppc64el, s390x)
<LocutusOfBorg> they are blocking libdbi-perl
-queuebot:#ubuntu-release- Unapproved: vlc (zesty-proposed/universe) [2.2.4-14ubuntu2.2 => 2.2.6-6~ubuntu17.04.1] (mozilla, mythbuntu, ubuntu-mate)
<tsimonq2> Oh bah
<tsimonq2> Someone please reject that vlc upload ^^^^^^
 * tsimonq2 accidentally forgot to close the bug in the changelog :/
-queuebot:#ubuntu-release- Unapproved: partitionmanager (xenial-proposed/universe) [1.2.1-0ubuntu1 => 1.2.1-0ubuntu1.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: partitionmanager (zesty-proposed/universe) [3.0.0-1 => 3.0.0-1ubuntu0.1] (kubuntu)
<tsimonq2> acheronuk: bug 1715576 ^^^^^^
<ubot5> bug 1715576 in partitionmanager (Ubuntu Zesty) "Fix crash when clicking cancel button, which may cause data loss" [Critical,Fix committed] https://launchpad.net/bugs/1715576
#ubuntu-release 2017-09-17
-queuebot:#ubuntu-release- Unapproved: lubuntu-default-settings (xenial-proposed/universe) [0.46 => 0.46.1] (lubuntu)
-queuebot:#ubuntu-release- Unapproved: indicator-sound-gtk2 (xenial-proposed/universe) [12.10.0.1-0ubuntu5 => 12.10.0.1-0ubuntu5.16.04.1] (no packageset)
<acheronuk>  tsimonq2 :)
<acheronuk> Could someone please delete this from Zesty proposed please? https://launchpad.net/ubuntu/+source/kdeplasma-addons/4:5.9.5-0ubuntu0.2
<acheronuk> that upload was not made or prepared by me (I didn't know it had been done), and the fix it was trying to do is achieve is wrong. the added dependency should be a runtime one, not a build dep
<acheronuk> I did push changes to git in preparation, could be a mix up. an upload made when not pulling the latest packaging updates from git
 * acheronuk shakes head at the brain fade 11 days can bring!
 * tsimonq2 requested that in bug report
<tsimonq2> acheronuk: Also, packaging mistake on my part, apologies
<acheronuk> well, a team effort I think :P
<tsimonq2> heh :P
<acheronuk> I guess you grabbed the earlier source, and did not realise it had been corrected
<tsimonq2> yep
<tsimonq2> It happens, at least it was caught
<acheronuk> it happens. it has been caught. lesson learned to communicate more comprehensively on such matters, so it's clear exactly what from where (revision or ppa version) the correct changes are
<acheronuk> lol. echo
 * acheronuk wonders why he is even here at ~ 8am on a Sunday morning!
<LocutusOfBorg> infrastructure question. do we have services running on http://localhost:5233/ ?
<LocutusOfBorg> I'm looking at xandikos autopkgtests failures, and this might make sense (they fail for timeout on amd64 and i386 only)
<LocutusOfBorg> can anybody ignore the testsuite on libanyevent-httpd-perl/ppc64el? it is already ignored on s390x and others
-queuebot:#ubuntu-release- New sync: golang-github-smartystreets-go-aws-auth (artful-proposed/primary) [0.0~git20160722.0.2043e6d-1]
-queuebot:#ubuntu-release- New sync: libmpack-lua (artful-proposed/primary) [1.0.6-1]
-queuebot:#ubuntu-release- New: accepted golang-github-smartystreets-go-aws-auth [sync] (artful-proposed) [0.0~git20160722.0.2043e6d-1]
-queuebot:#ubuntu-release- New: accepted libmpack-lua [sync] (artful-proposed) [1.0.6-1]
<ginggs> would someone please remove clapack from artful? LP: #1717799
<ubot5> Launchpad bug 1717799 in clapack (Ubuntu) "[RM] obsolete, duplicated functionality" [Undecided,New] https://launchpad.net/bugs/1717799
#ubuntu-release 2018-09-10
<cpaelzer> hi, could one of the SRU Team cancel open-iscsi (by smoser) from the Bionic unapproved queue please?
<cpaelzer> we want to do some fixup
<cpaelzer> infinity: sil2100: ^^ highlighting as i'm seeing your name on for today
-queuebot:#ubuntu-release- Unapproved: rejected open-iscsi [source] (bionic-proposed) [2.0.874-5ubuntu2.2]
<slangasek> cpaelzer: ^^ done
<cpaelzer> thanks slangasek
<acheronuk> slangasek: could I perhaps get an ok for LP: #1791501 ?
<ubot5> Launchpad bug 1791501 in plasma-framework (Ubuntu) "[FFe] KDE Frameworks 5.50.0 into Cosmic Archive" [Undecided,New] https://launchpad.net/bugs/1791501
-queuebot:#ubuntu-release- Unapproved: pcl (bionic-proposed/universe) [1.8.1+dfsg1-2ubuntu2 => 1.8.1+dfsg1-2ubuntu2.18.04.1] (no packageset)
-queuebot:#ubuntu-release- New sync: r-cran-mitools (cosmic-proposed/primary) [2.3-1]
-queuebot:#ubuntu-release- New sync: r-cran-kmi (cosmic-proposed/primary) [0.5.4-1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (bionic-proposed/main) [1:0.5.2 => 1:0.5.2.1] (desktop-core, ubuntu-server)
<slashd> o/ sil2100 could you please accept the upload of nginx for Bionic ? (the dependency addition we talked last week)
<sil2100> slashd: o/ Looking in a minute!
<slashd> sil2100, thanks
-queuebot:#ubuntu-release- Unapproved: accepted nginx [source] (bionic-proposed) [1.14.0-0ubuntu1.1]
<slashd> sil2100, thanks again ^
<sil2100> yw o/
-queuebot:#ubuntu-release- Unapproved: ipxe (bionic-proposed/main) [1.0.0+git-20180124.fbe8c52d-0ubuntu2 => 1.0.0+git-20180124.fbe8c52d-0ubuntu2.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (bionic-proposed) [1:18.04.26]
-queuebot:#ubuntu-release- New binary: gdcm [s390x] (cosmic-proposed/universe) [2.8.7-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (trusty-proposed) [2.02~beta2-9ubuntu1.16]
-queuebot:#ubuntu-release- New binary: gdcm [ppc64el] (cosmic-proposed/universe) [2.8.7-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: gdcm [i386] (cosmic-proposed/universe) [2.8.7-2ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: lxcfs (bionic-proposed/main) [3.0.1-0ubuntu2~18.04.1 => 3.0.2-0ubuntu1~18.04.1] (edubuntu, ubuntu-server)
<teward> slashd: I forgot I had an autohighlight for 'nginx' in here :|
<teward> sil2100: thank you for the assist with the Bionic upload of nginx, and for the FFe for Cosmic.
-queuebot:#ubuntu-release- New binary: gdcm [amd64] (cosmic-proposed/universe) [2.8.7-2ubuntu1] (kubuntu)
<sil2100> teward: yw!
<wxl> infinity: looks like the tb needs another re-up? :/
<infinity> wxl: Sure does.
<wxl> infinity: i'll give you another month then....................
-queuebot:#ubuntu-release- Unapproved: lxc (bionic-proposed/main) [3.0.1-0ubuntu1~18.04.2 => 3.0.2-0ubuntu1~18.04.1] (ubuntu-server)
<tsimonq2> slangasek: That saods2 failure against libxml2 looks like something you were working with, badtest?
<slangasek> saods2 is flaky
<slangasek> have you retried?
<tsimonq2> ack
<tsimonq2> no
<acheronuk> infinity or slangasek: if you have a chance, could you maybe ok LP: #1791501 ?
<ubot5> Launchpad bug 1791501 in plasma-framework (Ubuntu) "[FFe] KDE Frameworks 5.50.0 into Cosmic Archive" [Undecided,New] https://launchpad.net/bugs/1791501
<slangasek> can I delegate decisions about Kubuntu-desktop-specific FFes to someone on that team, instead?
<acheronuk> slangasek: can you?
<slangasek> yes, who wants that responsibility and is trusted by the Kubuntu devs to hold it? :)
<acheronuk> slangasek: well, I'm Kubuntu Council and Kubuntu dev, and I hopefully consider the impact of what I request. or if you want someone else, then maybe tsimonq2 ?
<acheronuk> s/hopefully/do
<infinity> acheronuk: Entirely okay with you and Simon doing it as a committee, so long as you partially recuse yourself when it's a feature you're arguing for.
<acheronuk> that seems fair
<infinity> acheronuk: But the act of explaining to another human (even one who you're pretty sure will agree) as to why the FFe is needed and what the negative impact might be will tend to lead you both in a sane direction.
<acheronuk> indeed
-queuebot:#ubuntu-release- Unapproved: lxd (bionic-proposed/main) [3.0.1-0ubuntu1~18.04.1 => 3.0.2-0ubuntu1~18.04.1] (edubuntu, ubuntu-server)
<acheronuk> ok. I'll double check tsimonq2 is ok with that situation, but assuming he is then I'll take that as the current position. thanks
<infinity> acheronuk: Just do remember to not use each other as a rubber stamp, but actually go through the formal process of arguing your case and identifying potential gotchas.
<acheronuk> understood
<infinity> acheronuk: Don't really care deeply if that's well documented publicly (but FFe bugs are nice for backreference), but the important bit is that you talk about it enough to convince yourself that you're not making version numbers more important than sanity/stability.
<infinity> acheronuk: Or, at the very least, that you understand the potential bad and are blocking off time to commit to dealing with it if it all goes sideways. :P
<acheronuk> of course
<santa_> acheronuk, slangasek: that was in the past the role of the kubuntu release manager i.e. Riddell or am I mistaken?
<slangasek> santa_: at various points in time it was handled by Riddell or ScottK, but it was a delegation from the Ubuntu Release Team rather than a result of a particular role within the Kubuntu community alone
<tsimonq2> infinity, slangasek: I would argue for the Kubuntu Council to have the permissions, but Rik and I (as a recently elected member) are the only two on the KC with the expertise. I'm fine going through the process, but it will mostly be Rik asking for my signoff because he does most of the KDE-specific work these days. It would be great if you could let Rik sign off on LXQt FFE stuff for me to make
<acheronuk> santa_: Riddell was/is at least a core dev and archive admin, as well as perhaps whatever equivalent of release team was then. so I think had fairly blanket autonomy
<tsimonq2> it equal. :P
<tsimonq2> acheronuk: Right.
<acheronuk> that seems a fair balance
<tsimonq2> Up to the Release Team though.
<tsimonq2> But Qool.
<tsimonq2> :P
<santa_> slangasek: ack
<santa_> tsimonq2: iirc the role of the KC isn't making _technical_ decisions, or am I missing something?
<tsimonq2> infinity, slangasek: If it's okay with you both I would like to write something formal and get ratification from the Release Team officially, but I would also like to know if this only applies to FFes or similar freezes like UIFes.
<tsimonq2> santa_: Well, which other board do we have?
<tsimonq2> The KC is the "catch-all".
<tsimonq2> Both of us are in ~kubuntu-dev, so it works out.
<santa_> tsimonq2: well, that's not an excuse to give the KC extra powers it shouldn't have
<acheronuk> well, I think here it is more important that the release team can delegate to people they see fit, KC or not. the fact that we are both KC is bonus, but not required
<santa_> +1
<tsimonq2> santa_: The KC is the final catch-all for Kubuntu.
<acheronuk> no, it's not. for example KC have no say on membership of Kubuntu devel
<acheronuk> s/say/vote
<santa_> well, if you want to give the KC extra powers, you can always change the constitution https://kubuntu.org/kubuntu-council-constitution/
<santa_> although I have to admit that "The purpose of the council is to make decisions and govern Kubuntu." is a bit vague
<tsimonq2> That's why I said catch-all.
<tsimonq2> That's already clear in where governance comes from.
<tsimonq2> In more vague cases it defaults to the KC.
<acheronuk> in cases where it is the release team delegating a decision, it's more important that the recipients of that have the ability and knowledge to assess the case, and is not really appropriate to be left to whoever manages to get elected on the KC
<acheronuk> could be a case where KC makeup has no-one who has the required experience
<santa_> +1 + I don't think the point 2. should be used as an excuse to get 'unlimited' powers, the KC isn't a "technical board" and many members aren't qualified to make technical decisions
<acheronuk> for now I think we should just go with the fact that we have 2 people the release-team are prepared to delegate to, and to not over complicate it more than that
-queuebot:#ubuntu-release- Unapproved: grub2 (trusty-proposed/main) [2.02~beta2-9ubuntu1.15 => 2.02~beta2-9ubuntu1.16] (core)
<slangasek> tsimonq2: well that would be the first time we bothered writing anything up and ratifying it any more officially than agreeing on IRC that you're delegated
<slangasek> i.e. I don't think you need to write anything
<acheronuk> ^^ I agree
<acheronuk> IRC logs with record this very soon ;)
<acheronuk> *will
<tsimonq2> slangasek: ack
<tsimonq2> slangasek: To be clear, is it OK for Rik to ACK lubuntu-desktop FFes?
<slangasek> tsimonq2: in what capacity?  I wouldn't ok that as part of a kubuntu delegation
<tsimonq2> slangasek: I pinged above with a more verbose answer but tl;dr I don't do much KDE-specific maintenance, so if you're giving both me and him an OK, KDE is 500+ packages and Lubuntu is much less, can he review my FFes?
-queuebot:#ubuntu-release- Unapproved: cloud-init (trusty-proposed/main) [0.7.5-0ubuntu1.22 => 0.7.5-0ubuntu1.23] (ubuntu-cloud, ubuntu-server)
<tsimonq2> Niiiiiiice, proposed is hovering at 400 packages. \o/
 * tsimonq2 goes candidate hunting.
<tsimonq2> slangasek: saods9> ., do I just keep retrying until it passes? :P
<slangasek> tsimonq2: ayup
<tsimonq2> Â¯\_(ã)_/Â¯
<tsimonq2> OK
<slangasek> tsimonq2: what was this about a more verbose answer wrt Lubuntu?  I don't seem to see it.  Anyway, I am not delegating to a non-release-team member, non-Lubuntu developer the FFe reviews of Lubuntu changes
<tsimonq2> ack
<tsimonq2> :P
<ginggs> would someone please consider LP: #1791359 ?
<ubot5> Launchpad bug 1791359 in octave (Ubuntu) "FFe: Sync octave 4.4.1-1 (universe) from Debian experimental (main)" [Wishlist,New] https://launchpad.net/bugs/1791359
<slangasek> ginggs: questions added to bug
<ginggs> slangasek: thanks. i've asked sebastien, and will reply on the bug, but no, i haven't done rebuilds or autopkgtests
<tsimonq2> gtk+3.0 should be candidate once gyoto/1.2.0-4ubuntu4/i386 passes its test (it's just a timeout it seems; I doubt it's related to gtk+3.0).
<tsimonq2> I can't seem to tell if breezy/3.0.0~bzr7096-1 is OOM, Python error, both, or just bad code...
<tsimonq2> It's throwing OverflowError: Python int too large to convert to C long
<ginggs> tsimonq2: gyoto/i386 passed
<tsimonq2> ginggs: ack, cool.
<tsimonq2> linux/4.18.0-7.8/s390x seems to be flaky; it returns exit code 253 most of the time which makes sense.
<ginggs> tsimonq2: i retried gyoto a couple of hours ago, and it looks like you retried again in the delay between the autopkgtest finishing and the results appearing
<tsimonq2> ginggs: Ah darn, ack.
<mwhudson> i hate that lag
<tsimonq2> Is it just a publisher lag?
<mwhudson> no idea
<tsimonq2> OK.
<slangasek> tsimonq2: that's not an OOM; if you've got an int that's too large to convert to a long, that number is not being used as the size of an array on any of our architectures
<tsimonq2> slangasek: Could you please remove ruby-compass? It's no longer in Testing (Debian bug 876608) and it's blocking a minor (semver) version bump of ruby-sass. The Debian bug notes that it's dead upstream.
<ubot5> Debian bug 876608 in ruby-compass "ruby-compass (build) depends on ruby-sass (< 3.5), but 3.5.1-2 is in unstable" [Serious,Open] http://bugs.debian.org/876608
<tsimonq2> slangasek: OK.
<slangasek> tsimonq2: compass-bootstrap-sass-plugin, ruby-compass-rails?
<slangasek> tsimonq2: nanoc which build-depends on ruby-compass?
<ginggs> slangasek: i don't expect a reply from sebastien about octave until tomorrow, but I looked, and some symbols were dropped from liboctinterp.so which is shipped along with liboctave.so in liboctave6.  surely this means debian wouldn't (shouldn't) revert the soname bump?
<slangasek> ginggs: perhaps. is the soname versioning entirely a Debian thing?
<tsimonq2> slangasek: compass-bootstrap-sass-plugin depends on "ruby-compass | ruby-sass" so it's fine.
<tsimonq2> slangasek: ruby-compass is a recommends of nanoc and can be removed.
<slangasek> tsimonq2: ruby-compass is a build-dependency of nanoc
<tsimonq2> O_o
<slangasek> alternate depends> cool, wouldn't it be neat if reverse-depends told me that ;)
<tsimonq2> nanoc> ack, so now I'm confused as to why Debian thinks that's cool O_o
<tsimonq2> ruby-compass-rails probably needs an axe too; Debian bug 875612 caused removal from testing.
<ubot5> Debian bug 875612 in ruby-compass-rails "ruby-compass-rails: ruby-compass obsolete and now broken" [Serious,Open] http://bugs.debian.org/875612
<tsimonq2> Oh, so the nanoc in -proposed no longer build deps on it apparently.
<tsimonq2> Syncing the latest Debian upload over your patch, which includes your patch and fixes some other tests as well (plus std-ver bump etc.)
<tsimonq2> .
<tsimonq2> I'll chase that to migration and then we *should* be good.
<tsimonq2> I'll file a bug on that alternate rdep and ruby-compass-rails can probably go in the meantime unless I'm missing something there.
<slangasek> ok
<ginggs> slangasek: it doesn't appear so (i checked recent commits in salsa) and at least the Arch packages have the same sonames
<slangasek> ginggs: ok. seems strange to me that they would bother bumping the soname upstream for a binary incompatibility only with a pre-release version, but at least that accounts for it.  Anyway, I would want to know about rebuild tests before signing off
<ginggs> slangasek: ack, I'll do PPA rebuilds
<tsimonq2> slangasek: ftr https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908544
<ubot5> Debian bug 908544 in ruby-bootstrap-sass "compass-bootstrap-sass-plugin depends on ruby-compass which has been removed from testing" [Normal,Open]
#ubuntu-release 2018-09-11
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (trusty-proposed/main) [4.15.0-1023.24~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (trusty-proposed) [4.15.0-1023.24~14.04.1]
-queuebot:#ubuntu-release- New sync: r-cran-rdflib (cosmic-proposed/primary) [0.1.0+dfsg-1]
<xnox> tsimonq2, oooh oooh. if there are flakey results, i want to look at them.
<xnox> cking, there appears to be a sysfs ubuntu_stress_smoke_test.stress-smoke-test failure on s390x
<xnox> is it known? should it be skipped / XFAILED on s390x?
<xnox> https://paste.ubuntu.com/p/VYfR9StC5Y/ is the relevant bit
<cking> xnox, it's an on-going issue, I'm working on that at the moment, so let's skip that for now
<xnox> cking, thank you!
<xnox> oooooh i think there are bad logs cloning things
<cking> xnox, can you remind me what kernel that was with, I want to check if it matches what I think should be happening with that test on s390x
<xnox> cjwatson, does https://paste.ubuntu.com/p/QJXJyYQZCF/ looks at all plausible match for the twisted bug you mentioned the other day? However based on timestamps it looks like it just hang there for half an hour; and it's totally legit to kill half an hour connections..... I wonder if git.launchpad.net can be bypassed in squid.internal, if that matters at all.
<xnox> cking, that would be 4.18.0-7-generic what's currently in cosmic-release
<cking> xnox, ah, that's good, phew, that's what I expected
<cjwatson> xnox: Shortly after I mentioned that Twisted bug, I mentioned that I thought it was a red herring.
<cjwatson> xnox: It's possible that it was the clone using a lot of memory on the server end and being slow / getting killed.  We had some problems with that recently.
<xnox> cjwatson, ack, thanks. sorry i missed previous red herring.
<cjwatson> xnox: While it's possible the squid matters somehow, it doesn't seem very likely to me.
<xnox> well, this clone should not take 25min, even across the ocean. and most of the time it doesn't. it feels like something somewhere is keeping the connection open, with actual pack request lost.
<xnox> with the connection eventually closed.
<xnox> cjwatson, can we somehow trace logs on cloning that repo from lp, on the other end? =)
<cjwatson> What timezone are those logs in?
<cjwatson> They have a stupid time format so I don't want to assume UTC.
<xnox> cjwatson, let me correlate those with what i know to be UTC
<cjwatson> Ah, found it
<xnox> end time 2018-09-10 03:21:35 UTC, duration 2h 28m 42s; approximate start time 2018-09-10 00:52:51 UTC - that's for all of the tests, let me narrow down the window when this clone was started
<cjwatson> At that time there was a problem with the backend
<cjwatson> 2018-09-10 02:25:29+0000 [Uninitialized] Backend connection failed
<cjwatson>         Traceback (most recent call last):
<cjwatson>         Failure: twisted.internet.error.ConnectionRefusedError: Connection was refused by other side: 111: Connection refused.
<cjwatson> Logs are full of that sort of thing, so everything would've been failing
<xnox> everything is terrible =))))) oh well
<cjwatson> And stuff like this from the backend:
<cjwatson> 2018-09-10 02:25:29+0000 [-] [request-id=898f6e33-d3eb-47c2-bc4c-001540cb3865] [PackBackendProtocol] Connection lost.
<cjwatson>         Traceback (most recent call last):
<cjwatson>         Failure: twisted.internet.error.ConnectionLost: Connection to the other side was lost in a non-clean fashion.
<cjwatson> Where the "connection" is a Twisted-ish way of saying "pipe to git child process"
<xnox> thank you for translating =)
<cjwatson> I think this is just a scaling problem
 * xnox never did twisted
<cjwatson> Unfortunately the git backend is not very scalable right now
<cjwatson> I already proposed a session for my team in Brussels to work out what we need to do to fix that
<cjwatson> So this is ammunition
<xnox> i can actually dig into these at http://autopkgtest.ubuntu.com/packages/linux/cosmic/s390x but most of "x fail" are git clone from launchpad fail, if there is at least one green pass for a given version number.
<xnox> not all, but roughly half.
<xnox> hence for like the lifetime of bionic we had s390x blacklisted.
<cjwatson> It doesn't surprise me that kernel clones would be particularly likely to hit problems
<xnox> cjwatson, but lp uses git binary right? it doesn't use anything custom like dulwich? i believe github uses libgit2.
<xnox> apw, cking - i wonder; if git clone of the linux tree fails, if we should be falling back on `pull-lp-source`
<cjwatson> The backend is the git binary, yes
<xnox> ack
<cjwatson> Though libgit2 is involved at other levels, mainly for the internal API
<cjwatson> git protocol traffic is passed through various layers of custom Twisted-based code, but the actual upload-pack / receive-pack protocol is handled by the git binary
<apw> xnox, why am i cloning the git repo ?
<apw> this seems like a strange thing to be doing, unless i need something big to mangle
<cjwatson> Yeah, pull-lp-source would also be weird considering that autopkgtest *already gives you the source*
<xnox> apw, to call $ make to compile all the self-tests which are in the linux source tree.... despite being in the linux kernel source tree as provided by autopkgtest already
<apw> xnox, so it sounds like the correct fix is to add some kind of 'detect you already have the kernel source'
<xnox> apw, and for some reason, it is done from a git clone of the .../cosmic repo, master branch, rather than what is already unpacked. maybe that's simply how the tests got ported onto autopkgtest.
<apw> xnox, well one advantage of that is we can 'fix' tests without uploading things
<xnox> apw, that would be easy to do, there are environment variables that tell you that. Shall I write that up in the bug report to improve the "setup" stage?
<apw> xnox, yes please
<xnox> cjwatson, do you use the v2 protocol stuff in git? https://opensource.googleblog.com/2018/05/introducing-git-protocol-version-2.html
<xnox> somehow it's "better"
<cjwatson> not yet, no
<cjwatson> but the scaling problems are mostly memory not bandwidth atm; I don't know whether the new protocol does much about that
<xnox> i wonder if the fact that we try to do shallow clones here with --depth 1 is actually causing more memory problems here, instead of cloning the full master branch, or even the full repo.
<cjwatson> I've added a Trello card for the bits I think we need to do to support v2
<jbicha> please remove sysprof/s390x/cosmic, it only built because the previous version ignored build tests failures
<sil2100> slangasek, infinity: hey! Would be nice if you announced somewhere that some non-release people have been delegated to approve Kubuntu FFe's - I almost switched the plasma one back from 'Triaged' since I thought this is some kind of a illegal activity ;)
<apw> sil2100, i assume it was approved by one of the project leads for kubuntu
<apw> those are documented somewhere arn't they ?
<sil2100> apw: well, yes, but I guess FFe's normally are only to be approved by ubuntu-release members, not flavour release members from what I know
<Laney> indeed
<apw> sil2100, i was under the impression that things in the flavour seed, and not on other images were their responsibility
<apw> but as there is confusion i defer to infinity
<sil2100> Anyway, I'm all good about anything as long as it's made visible to the other release members
<sil2100> If not for Laney I wouldn't have known about this
<sil2100> And I'd just cause unnecessary trouble
<tsimonq2> sil2100: See the IRC discussion from yesterday.
<tsimonq2> I proposed it but they determined an announcement to be not necessary.
<tsimonq2> I was only given the go-ahead (with Rik) to approve Kubuntu FFEs; Lubuntu FFEs still need Release Team approval. :P
<sil2100> tsimonq2: strange decision not to announce, could cause some small chaos by accident
<sil2100> tsimonq2: as for Lubuntu, please update the bug description to include what I requested ;p
<tsimonq2> sil2100: My backlog is getting very large these days. :P
<tsimonq2> sil2100: So, "when I can."
<sil2100> tsimonq2: ok! ;)
<tsimonq2> sil2100: I just updated the FFe docs; feel free to peer review.
<tsimonq2> I'll do that Lubuntu bug next. ;)
<tsimonq2> (w.u.c/FreezeExceptionProcess)
<tsimonq2> infinity, slangasek: ^
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20180814.1-0ubuntu0.18.04.2 => 1:20180911.1-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20180814.1-0ubuntu0.16.04.2 => 1:20180911.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20180814.1-0ubuntu0.14.04.2 => 1:20180911.1-0ubuntu0.14.04.1] (no packageset)
<chrisccoulson> hi, could somebody please approve the adobe-flashplugin partner uploads for trusty -> bionic? (and also be around to copy them to the release pocket once they're ready)
<chrisccoulson> see https://wiki.ubuntu.com/ArchiveAdministration#Handling_updates_to_partner
<apw> chrisccoulson, ok
-queuebot:#ubuntu-release- Unapproved: open-iscsi (bionic-proposed/main) [2.0.874-5ubuntu2.1 => 2.0.874-5ubuntu2.2] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20180911.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20180911.1-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20180911.1-0ubuntu0.14.04.1]
<apw> chrisccoulson, ^
<chrisccoulson> apw, awesome, thanks!
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.2-1 => 1.1.2-1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.2-1 => 1.1.2-1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.2-1 => 1.1.2-1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-340 (bionic-proposed/restricted) [340.106-0ubuntu3 => 340.107-0ubuntu0.18.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: fwupd (cosmic-proposed/main) [1.1.2-1 => 1.1.2-1] (desktop-core)
-queuebot:#ubuntu-release- New binary: octave [s390x] (cosmic-proposed/universe) [4.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave [ppc64el] (cosmic-proposed/universe) [4.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New source: vulkan-loader (cosmic-proposed/primary) [1.1.82.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ostree (bionic-proposed/universe) [2018.4-2 => 2018.8-0ubuntu0.1] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: flatpak (bionic-proposed/universe) [0.11.7-0ubuntu0.1 => 1.0.1-0ubuntu0.1] (ubuntugnome)
<slangasek> LocutusOfBorg: er, you have 10 ppa builds of llvm-toolchain-7 going, in a ppa for which the source has apparently been un-published?
<slangasek> including 7 for superseded versions, which I am now cancelling
-queuebot:#ubuntu-release- New binary: octave [armhf] (cosmic-proposed/universe) [4.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: octave [arm64] (cosmic-proposed/universe) [4.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gdcm [amd64] (cosmic-proposed) [2.8.7-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted gdcm [ppc64el] (cosmic-proposed) [2.8.7-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted octave [arm64] (cosmic-proposed) [4.4.1-1]
-queuebot:#ubuntu-release- New: accepted octave [ppc64el] (cosmic-proposed) [4.4.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-kmi [sync] (cosmic-proposed) [0.5.4-1]
-queuebot:#ubuntu-release- New: accepted r-cran-rdflib [sync] (cosmic-proposed) [0.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted gdcm [i386] (cosmic-proposed) [2.8.7-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted octave [armhf] (cosmic-proposed) [4.4.1-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mitools [sync] (cosmic-proposed) [2.3-1]
-queuebot:#ubuntu-release- New: accepted gdcm [s390x] (cosmic-proposed) [2.8.7-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted octave [s390x] (cosmic-proposed) [4.4.1-1]
-queuebot:#ubuntu-release- New binary: r-cran-mitools [amd64] (cosmic-proposed/none) [2.3-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: fwupd (bionic-proposed/main) [1.0.6-2 => 1.0.9-0ubuntu1] (desktop-core)
<tsimonq2> slangasek: Thanks for ruby-compass.
<tsimonq2> slangasek: thepeg can probably go too.
-queuebot:#ubuntu-release- New sync: r-cran-redland (cosmic-proposed/primary) [1.0.17-9-1]
<acheronuk> slangasek: I assume 'all-proposed' retries on amd64/ppc64el being unable to install a kernel again is due to linux-signed FTBFS?
<slangasek> acheronuk: linux-signed FTBFS would certainly trigger it. what series are we talking here?
<acheronuk> slangasek: cosmic linux-signed (4.18.0-7.8 to 4.18.0-8.9)
<slangasek> acheronuk: ok. accepting the UEFI binaries now so that we can get that unstuck
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [amd64] (cosmic-proposed) [1.1.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [armhf] (cosmic-proposed) [1.1.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [arm64] (cosmic-proposed) [1.1.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted fwupd [i386] (cosmic-proposed) [1.1.2-1]
<acheronuk> slangasek: thank you :)
-queuebot:#ubuntu-release- Unapproved: accepted shim [sync] (xenial-proposed) [15+1533136590.3beb971-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (xenial-proposed) [1.33.1~16.04.2]
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.18.0-8.9] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.18.0-8.9] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.18.0-8.9]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.18.0-8.9]
-queuebot:#ubuntu-release- Unapproved: plymouth (bionic-proposed/main) [0.9.3-1ubuntu7 => 0.9.3-1ubuntu7.18.04.1] (core)
-queuebot:#ubuntu-release- New sync: ufolib2 (cosmic-proposed/primary) [0.1.3-1]
#ubuntu-release 2018-09-12
-queuebot:#ubuntu-release- New sync: r-cran-redland (cosmic-proposed/primary) [1.0.17-10-1]
-queuebot:#ubuntu-release- Unapproved: apport (bionic-proposed/main) [2.20.9-0ubuntu7.3 => 2.20.9-0ubuntu7.4] (core)
-queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu7.5 => 1:2.11+dfsg-1ubuntu7.6] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.34.2 => 2.35.2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (trusty-proposed) [2.35.1~14.04]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.35.1]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (trusty-proposed) [2.35~14.04]
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.35]
<apw> ^ clearing the decks for a 2.35.2 across the board
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.35.1+18.04 => 2.35.2+18.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.34.2~14.04 => 2.35.2~14.04] (no packageset)
<LocutusOfBorg> slangasek, thanks!
<LocutusOfBorg> I usually unpublish the binaries when I'm only interested in the build logs :)
 * apw will handle the snapd's ^
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-136.162] (core, kernel)
<xnox> slangasek, is something odd happening with the iso production? on s390x it looks like an out of date d-i is being used, as if mirror is stale?
<xnox> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/cosmic/daily-20180912.log -> Using MD5 sums from d-i: /srv/cdimage.ubuntu.com/ftp/dists/cosmic/main/installer-amd64/20101020ubuntu551/images/MD5SUMS
<xnox> however current d-i is 20101020ubuntu552
<xnox> thus e.g. initrd has v4.17 modules, not v4.18 and things fail
-queuebot:#ubuntu-release- Unapproved: open-vm-tools (bionic-proposed/main) [2:10.3.0-0ubuntu1~18.04.1 => 2:10.3.0-0ubuntu1~18.04.2] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- New binary: ganeti [amd64] (cosmic-proposed/universe) [2.16.0~rc2-6ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ganeti [amd64] (cosmic-proposed) [2.16.0~rc2-6ubuntu1]
-queuebot:#ubuntu-release- New: accepted r-cran-redland [sync] (cosmic-proposed) [1.0.17-10-1]
-queuebot:#ubuntu-release- New: accepted ufolib2 [sync] (cosmic-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-mitools [amd64] (cosmic-proposed) [2.3-1]
-queuebot:#ubuntu-release- New: rejected r-cran-redland [sync] (cosmic-proposed) [1.0.17-9-1]
-queuebot:#ubuntu-release- New binary: r-cran-redland [s390x] (cosmic-proposed/universe) [1.0.17-10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-redland [ppc64el] (cosmic-proposed/universe) [1.0.17-10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ufolib2 [amd64] (cosmic-proposed/universe) [0.1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-redland [i386] (cosmic-proposed/universe) [1.0.17-10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-redland [amd64] (cosmic-proposed/universe) [1.0.17-10-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-136.162]
-queuebot:#ubuntu-release- New binary: r-cran-redland [arm64] (cosmic-proposed/universe) [1.0.17-10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: r-cran-redland [armhf] (cosmic-proposed/universe) [1.0.17-10-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-340 [source] (bionic-proposed) [340.107-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- New binary: r-cran-kmi [amd64] (cosmic-proposed/universe) [0.5.4-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted r-cran-redland [amd64] (cosmic-proposed) [1.0.17-10-1]
-queuebot:#ubuntu-release- New: accepted r-cran-redland [armhf] (cosmic-proposed) [1.0.17-10-1]
-queuebot:#ubuntu-release- New: accepted r-cran-redland [ppc64el] (cosmic-proposed) [1.0.17-10-1]
-queuebot:#ubuntu-release- New: accepted ufolib2 [amd64] (cosmic-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted r-cran-redland [arm64] (cosmic-proposed) [1.0.17-10-1]
-queuebot:#ubuntu-release- New: accepted r-cran-redland [s390x] (cosmic-proposed) [1.0.17-10-1]
-queuebot:#ubuntu-release- New: accepted r-cran-redland [i386] (cosmic-proposed) [1.0.17-10-1]
-queuebot:#ubuntu-release- New: accepted r-cran-kmi [amd64] (cosmic-proposed) [0.5.4-1]
-queuebot:#ubuntu-release- New binary: r-cran-rdflib [amd64] (cosmic-proposed/universe) [0.1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted r-cran-rdflib [amd64] (cosmic-proposed) [0.1.0+dfsg-1]
-queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [0.6.5.6-0ubuntu24 => 0.6.5.6-0ubuntu25] (no packageset)
<LocutusOfBorg> slangasek, do you mind commenting on https://github.com/lvc/abi-compliance-checker/pull/80#issuecomment-420523736 ?
<gitbot> lvc issue (Pull request) 80 in abi-compliance-checker "Run packing commands in a subprocess" [Open]
-queuebot:#ubuntu-release- Unapproved: accepted openvswitch [source] (xenial-proposed) [2.5.5-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted binutils [source] (xenial-proposed) [2.26.1-1ubuntu1~16.04.7]
<acheronuk> sil2100: could I please get a packageset update for Kubuntu?
<slangasek> xnox: yes, it appears the cdimage mirror on nusakan is 9 days out of date
<slangasek> xnox: no, 3 days
<slangasek> from the 9th ;)
<slangasek> I'm running an anonftpsync by hand now to see what's up
<xnox> slangasek, kill stale locks maybe?
<xnox> happened before
<slangasek> xnox: no, rsync is now running
<slangasek> there's a design bug where if image builds on nusakan take too long and overlap, the sync never happens in order to not destabilize an in-progress image build
<slangasek> so that could be it
<slangasek> but I'm waiting to see what happens with rsync
<slangasek> xnox: an rsync succeeded and the mirror is now up to date; I would have to crawl logs of the previous builds to see why this didn't happen on its own before now
-queuebot:#ubuntu-release- Unapproved: binutils (bionic-proposed/main) [2.30-20ubuntu2~18.04 => 2.30-21ubuntu1~18.04] (core)
-queuebot:#ubuntu-release- Unapproved: accepted ipxe [source] (bionic-proposed) [1.0.0+git-20180124.fbe8c52d-0ubuntu2.1]
<xnox> slangasek, ok.
<slangasek> xnox: yeah I looked at the logs and they all have the telltale 'parallel build; waiting for mirror to sync' line.  It would be nice if we could have this fixed someday, perhaps we need to make local hardlink farm copies of the mirror under a lock :P
<slangasek> because currently the lock is held for the duration of any image build and there are a lot of those and they take real time
<xnox> slangasek, given by hash mirrors, they need not hold a lock, if they resolve and use by hash mirrors, no?
<xnox> or is that not synced?
<slangasek> interesting point
<slangasek> that's probably the better path forward
<slangasek> ftp/dists/cosmic/by-hash/SHA256/ is there
<slangasek> I haven't looked details of how to consume by-hash though, and this is all in the debian-cd codebase
<slangasek> so probably not the quickest thing to retrofit
<slangasek> xnox: do you have a pointer handy for details on consuming by-hash?
<xnox> slangasek, i do this -> grab http://archive.ubuntu.com/ubuntu/dists/cosmic/InRelease, take sha256sum of it, from then on, i know that i can get _that_ version of it from http://archive.ubuntu.com/ubuntu/dists/cosmic/by-hash/SHA256/a2efba58cb8b5fc07bb2e4afb29a26593741780d8f285b0e6421174e07d8246b
<xnox> where a2ef... is the sha256sum of it.
<xnox> slangasek, but i have no idea what the apt-archive url / env variable spec is to point and lock onto that.
<xnox> only walk it....
<slangasek> right
<xnox> juliank, ^
<slangasek> and also I don't know if debian-cd is using apt or walking things directly :)
<xnox> juliank, is there a url spec for by-hash fetching things?
<xnox> or maybe cjwatson given there was some planning/work to have this in launchpad
<slangasek> good news, we are using apt
<xnox> slangasek, as far as i understand, there is no need to do anything then, just drop the locks.
<xnox> slangasek, you are free to update the mirror, whilst builds are in progress, and as long as InRelease is updated atomically everything should be able to fetch things without any hashsum missmatches
<xnox> slangasek, if the apt you are using is new enough....
<xnox> slangasek, nousakan is on bionic, right?! =)
<slangasek> xenial
<xnox> http://manpages.ubuntu.com/manpages/xenial/man5/sources.list.5.html -> seems to have By-Hash option, so yeah, should be fine.
<cjwatson> xnox: It's covered by https://wiki.debian.org/DebianRepository/Format
<xnox> nice!
<slangasek> so it's not just a no-op, you have to specify Acquire-By-Hash
<cjwatson> you do need to make sure that mirror sync passes are done correctly
<slangasek> oh, or perhaps Acquire-By-Hash is set in the archive
<xnox> slangasek, http://archive.ubuntu.com/ubuntu/dists/xenial/InRelease has Acquire-By-Hash set
<slangasek> right
<cjwatson> I *think* cdimage.build.anonftpsync gets it right though
<slangasek> but then we also do things like FILES=`find -L $MIRROR/dists/$SUITE/ -name Sources.gz` in tools/grab_md5
<cjwatson> Yeah, its two-stage stuff looks right
<cjwatson> It would not remotely surprise me to find that there was ancient stuff in debian-cd that needs to be cleaned up
<xnox> slangasek, urgh
-queuebot:#ubuntu-release- Unapproved: rejected zfs-linux [source] (xenial-proposed) [0.6.5.6-0ubuntu25]
<slangasek> xnox: anyway, turning this into a card now and depending on how the image build times look over the next few days maybe it becomes a sprint topic
-queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [0.6.5.6-0ubuntu24 => 0.6.5.6-0ubuntu25] (no packageset)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (bionic-proposed/main) [0.7.5-1ubuntu16.3 => 0.7.5-1ubuntu16.4] (core)
<bdmurray> slangasek: Do you see anything strange with the zfs-linux upload for xenial-proposed?
-queuebot:#ubuntu-release- New binary: glyphslib [amd64] (cosmic-proposed/universe) [3.0.2-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gcc-8 (bionic-proposed/main) [8-20180414-1ubuntu2 => 8.2.0-1ubuntu2~18.04] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: gcc-7 (bionic-proposed/main) [7.3.0-16ubuntu3 => 7.3.0-27ubuntu1~18.04] (core) (sync)
<slangasek> bdmurray: deleting the header of debian/patches/2203-Allow-mounting-datasets-more-than-once.patch is a bit odd, but non-functional. is that what you mean?
<bdmurray> slangasek: Yeah, so by "non-functional" you mean the patch isn't getting dropped?
<slangasek> bdmurray: yes; it's only dropping the header from the patch, not the code changes
<slangasek> still doesn't really belong in an SRU, but it's not going to regress the package
<cking> slangasek, bdmurray - it was my fault, I somehow messed up the header to that commit
-queuebot:#ubuntu-release- Unapproved: rejected zfs-linux [source] (xenial-proposed) [0.6.5.6-0ubuntu25]
-queuebot:#ubuntu-release- New binary: libreoffice-dictionaries [amd64] (cosmic-proposed/main) [1:6.1.0~rc2-3] (personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [0.6.5.6-0ubuntu24 => 0.6.5.6-0ubuntu25] (no packageset)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [0.6.5.6-0ubuntu24 => 0.6.5.6-0ubuntu25] (no packageset)
-queuebot:#ubuntu-release- New: accepted glyphslib [amd64] (cosmic-proposed) [3.0.2-3]
-queuebot:#ubuntu-release- New: accepted libreoffice-dictionaries [amd64] (cosmic-proposed) [1:6.1.0~rc2-3]
-queuebot:#ubuntu-release- Unapproved: python3.6 (bionic-proposed/main) [3.6.5-3 => 3.6.6-1~18.04] (core)
-queuebot:#ubuntu-release- Unapproved: python3.7 (bionic-proposed/universe) [3.7.0~b3-1 => 3.7.0-1~18.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected zfs-linux [source] (xenial-proposed) [0.6.5.6-0ubuntu25]
-queuebot:#ubuntu-release- Unapproved: rejected syslinux [source] (bionic-proposed) [3:6.03+dfsg1-2ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: syslinux (bionic-proposed/main) [3:6.03+dfsg1-2 => 3:6.03+dfsg1-2ubuntu0.18.04.1] (core)
#ubuntu-release 2018-09-13
<stgraber> hmm, so the latest LXD upload effectively switches from 3 binary packages per-arch to a single arch-all package, is there any way to make proposed-migration happy enough with that so it starts running autopkgtests?
<stgraber> looking at docs, looks like the solution to unstick this is to remove those binaries from the release pocket, but that'd break people at this point...
<stgraber> (I'm fine doing the package removal from the release pocket once I know that the new package will migrate within the hour, but right now I specifically don't want it to migrate yet I want adt to do its thing)
-queuebot:#ubuntu-release- Unapproved: qemu (xenial-proposed/main) [1:2.5+dfsg-5ubuntu10.31 => 1:2.5+dfsg-5ubuntu10.32] (ubuntu-server, virt)
<apw> stgraber, do those break the originals ?
<apw> etc
<apw> stgraber, could you not make both of those going away binaries transitionals, and would this both allow this to migrate _and_ effectivly deinstall the now redundant packages
<apw> then they would be removable in -release in a subsequent upload
<apw> as nothing is in them
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-159.209] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-136.162~14.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-136.162~14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-159.209]
<cpaelzer> sil2100: you are on SRU duty right now correct?
<cpaelzer> I wanted to ask if you could cancel 1:2.11+dfsg-1ubuntu7.6 from bionic unapproved
<cpaelzer> it is good, but I have two more changes complete and want to minimize how often people have to update
<cpaelzer> so I'd want to bundle those two more changes and re-upload
<cpaelzer> but be careful, there also is an upload in xenial-unapproved, do not cancel that one (it is unrelated)
<sil2100> cpaelzer: ok!
<cpaelzer> thank you sil2100
<sil2100> Done ;)
-queuebot:#ubuntu-release- Unapproved: rejected qemu [source] (bionic-proposed) [1:2.11+dfsg-1ubuntu7.6]
<doko> LocutusOfBorg: your automake 1.16 update broke dozens of builds ...
<LocutusOfBorg> doko, can I see them?
<doko> e.g. newt. currently running the test rebuild
<LocutusOfBorg> juliank, ^^ please merge it?
<juliank> um
<juliank> better cancel the automake update?
<LocutusOfBorg> after it has been removed from the archive and the new package migrated?
<juliank> Well, I don't know what you did
<LocutusOfBorg> migrated 20 days ago...
<LocutusOfBorg> juliank, followed the change from automake 1.15 to 1.16
<LocutusOfBorg> and some bad programs doing bad things, hardcoding stuff, breaks
<rbasak> sil2100, bdmurray: I didn't manage to get back to gnome-software in Xenial unapproved yesterday. I'll finish it off now.
<LocutusOfBorg> juliank, I can steal newt if you want
<LocutusOfBorg> the fix is two lines
<juliank> I'd like to figure out why you merge automake 1.16 after the feature freeze
<LocutusOfBorg> I asked here, and I got "ok to go"
<LocutusOfBorg> because there was still time to fixup stuff
<juliank> Well, ok
<LocutusOfBorg> and there aren't new "features" in new automake, just bugfixes
<LocutusOfBorg> stuff is not breaking because of actual changes, but because "export AUTOMAKE 1.15" and similar
<cjwatson> Did you?  I see you asking, but no explicit yes
<juliank> So packages have missing Depends: automake (<< 1.16)
<cjwatson> Well, it would have required somebody to process NEW, but that's a different headspace
<juliank> (that's what they should have so you can actually notice them)
<juliank> Can someone run a search for 1.15 in the archive?
<juliank> so we know what breaks?
<LocutusOfBorg> juliank, do you have any idea about how to do it?
<LocutusOfBorg> cjwatson, actually automake has been uploaded in early august in debian, for some reasons really obscure to me, it didn't get autosyncd
<LocutusOfBorg> and it was 24 hours after the freeze, yes
<juliank> I think security team has a script for greeping source packages
<LocutusOfBorg> oh... lets move there maybe
<cjwatson> Doesn't seem obscure, you even pasted the reason
<cjwatson> <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
<cjwatson> Sources that would produce binary packages that currently have Ubuntu deltas don't get autosynced for what I would hope would be entirely clear reasons
<LocutusOfBorg> ok so I don't remember anymore after 20 days, and my irc history doesn't go that far
<LocutusOfBorg> cjwatson, probably I remember "why the hell the delta is a stupid 2 line autopkgtestsuite and nobody ever pushed it to debian in years"
<LocutusOfBorg> and then I filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906919
<ubot5> Debian bug 906919 in automake-1.16 "automake-1.16: please enable testsuite [PATCH]" [Important,Open]
<sil2100> rbasak: ok!
<sil2100> rbasak: thanks for the heads up
<juliank> LocutusOfBorg: FWIW; I don't see anybody responding to you, but someone did let it pass NEW
<LocutusOfBorg> btw, the "dozen" might be actual 3 packages
<LocutusOfBorg> https://codesearch.debian.net/search?q=1%5C.15+path%3Adebian%2Frules
<cjwatson> Sounds like doko has more examples?
<LocutusOfBorg> I hope so
<LocutusOfBorg> and the package above results in the search
<juliank> libjpeg9: export AUTOMAKE = automake-1.15
<juliank> ugh
<juliank> Should add a lintian check "hardcoded autotools versions"
<juliank> ekg2
<juliank> icecast2 are the others
<LocutusOfBorg> newt "libjpeg9?" (not sure) ekg2 and icecast2
<LocutusOfBorg> yes, exactly
<juliank> When bumping to 1.16, it would make sense to add proper Build-Depends: automake (<< 1.17)
<juliank> so things get noticed more easily
<cjwatson> Or just unhardcode
<LocutusOfBorg> do you care to file a bug?
<juliank> That would be nicer
<LocutusOfBorg> right now I'm fixing ekg2 to stop hardcoding
<juliank> How?
<juliank> Are you using dpkg to query version of automake and then sed it correclty?
<juliank> i.e. AM_VERSION=$(shell dpkg-query -f '\${source:Upstream-Version}' -W automake | egrep -o '^[0-9]+\.[0-9]+')
<juliank> or just hardcode AUTOMAKE = automake
<juliank> well, remove the vars
-queuebot:#ubuntu-release- Unapproved: rejected freshplayerplugin [source] (xenial-proposed) [0.3.9-0ubuntu0~16.04.1]
-queuebot:#ubuntu-release- Unapproved: freshplayerplugin (xenial-proposed/multiverse) [0.3.4-3ubuntu0.1 => 0.3.9-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted freshplayerplugin [source] (xenial-proposed) [0.3.9-0ubuntu0.16.04.1]
-queuebot:#ubuntu-release- Unapproved: metacity (bionic-proposed/universe) [1:3.28.0-1 => 1:3.28.0-1ubuntu0.1] (ubuntu-desktop)
<LocutusOfBorg> juliank, the latter
<LocutusOfBorg> ekg2 is fixed for real now
<juliank> I send the $(shell) invocation to Debian for newt
<juliank> I did not check quoting, though
<LocutusOfBorg> thanks!
<LocutusOfBorg> icecast2 is good now
<rbasak> sil2100, bdmurray: gnome-software looks good to me, except that there's one change with no bug reference that enables a patch that was supposed to be added in a previous SRU but never functionally landed (missing from series). The changelog says "Add patch that seemed to get missed in 3.20.5-0ubuntu0.16.04.10". That previous upload listed two bugs that were marked verification-done, but AFAICT that
<rbasak> was false since the patch was never enabled. So should I ask for those two bugs to be reopened and the changelog to include them so they can be reverified? Opinions?
<rbasak> I don't see robert_ancell online - out of time zone I guess.
<juliank> It's actually
<juliank> AM_VERS:=$(shell dpkg-query -f '$${source:Upstream-Version}' -W automake | egrep -o '^[0-9]+\.[0-9]+')
<LocutusOfBorg> what about dropping that variable?
<LocutusOfBorg>         cp /usr/share/automake-$(AM_VERS)/install-sh ./install-sh
<LocutusOfBorg> seriosly because of this^
<LocutusOfBorg> ?
<juliank> LocutusOfBorg: Well, it's clearly needed here
<LocutusOfBorg> cp /usr/share/automake-*/install-sh ./install-sh
<juliank> Replacing $(AM_VERS) with * would work sometime
<juliank> but not if you have automake-1.11 installed I guess
<LocutusOfBorg> yes I know it doesn't with automake 1.11 and 1.15
<LocutusOfBorg> I'm trying to find if --add-missing or whatever works
<LocutusOfBorg> you know, there is some obscure automake stuff
<LocutusOfBorg> for this
<juliank> bug 908739
<ubot5> bug 908739 in Odoo Addons (MOVED TO GITHUB) "web : compagin ugly screen" [Low,Fix released] https://launchpad.net/bugs/908739
<juliank> in debian
<juliank> https://bugs.debian.org/908739
<ubot5> Debian bug 908739 in src:newt "newt: Do not hardcode automake version" [Normal,Open]
<juliank> there we go
<LocutusOfBorg> nice!
<LocutusOfBorg> I hope to find a better solution btw :)
<juliank> I don't know why I had to use $(strip) around the dpkg-query | egrep
<juliank> or why I did not use cut -1-2 -d.
<juliank> oh well, this probably works better in case of an alpha or stuff
<LocutusOfBorg> juliank, please
<LocutusOfBorg> AUTOMAKE_FLAGS="--add-missing --copy"
<LocutusOfBorg> end of the story
<juliank> LocutusOfBorg: Tell the bug report
<LocutusOfBorg> mmm didn't work :/
<juliank> :)
 * LocutusOfBorg tries with a bigger hammer
<juliank> LocutusOfBorg: Where does _FLAGS come from?
<juliank> AUTOMAKE=automake --add-missing --copy
<juliank> is what I'd do
<juliank> that's what autoreconf(1) documents
<juliank> LocutusOfBorg: Ah, duh, there's no automake in the build
<juliank> only a Makefile.in, no Makefile.am
<juliank> LocutusOfBorg: That said, it seems wrong to have the file in the first place
<juliank> I mean, Makefile.in defines an install-sh target for install shared library
<doko> cpaelzer: online? pmdk
<juliank> and the Makefile does not use install-sh
<juliank> I mean, it uses AC_PROG_INSTALL in configure
<juliank> but then it has to use $(INSTALL), not install
<LocutusOfBorg> I feel so dirty
<LocutusOfBorg> but doing this works
<LocutusOfBorg> AUTOMAKE=/usr/bin/automake --add-missing --copy --foreign
<LocutusOfBorg> $(AUTOMAKE) || true
<LocutusOfBorg> in configure, because automake fails, but after having copied the file :)
<juliank> FWIW, python-newt should be called python-snack, it provides a snack module, no newt module
<juliank> LocutusOfBorg: The cp is cleaner than that, though
<LocutusOfBorg> sure juliank :) I want to hide in a cave
<juliank> LocutusOfBorg: Patching out the check for AC_PROG_INSTALL is even easier
<juliank> Since Makefile.in does not use $(INSTALL)...
<juliank> I think it's a bug in autoconf
<juliank> autoconf should copy install-sh as needed
<juliank> It can't rely on libtool or automake to do it
<LocutusOfBorg> I confirm, removing PROG_INSTALL works... mind to update the bug report? :)
<LocutusOfBorg> and do the upload if you can, so I can focus on libjpeg9
<LocutusOfBorg> (the last one for me)
<juliank> LocutusOfBorg: I already did the newt merge so we're good for now, I'm not introducing a delta for this
<juliank> s/introducing/increasing/
<LocutusOfBorg> ack but maybe adding a patch to the bug report?
<juliank> Well, he can remove a line himself
<juliank> I also reported a bug to merge the built -> build change in python{3,}-newt
<juliank> :)
<LocutusOfBorg> nice, indeed!
<juliank> LocutusOfBorg: Probably file an RC bug in Debian then with the libjpeg9 fix
<LocutusOfBorg> libjpeg9 is fine without anything of that hardcoding https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/15453009
<LocutusOfBorg> sure, an RC is what I plan to do
<cpaelzer> doko: I was out for lunch
<cpaelzer> what is up with pmdk?
<cpaelzer> would be ahasenack btw, but he is out until the sprint
<cpaelzer> doko: saw your questions on the bug
<cpaelzer> all the questions are fine to be answered at the sprint next week I think
<cpaelzer> thanks for taking a look
<cpaelzer> jemalloc being bundled in there is interesting, didn't realize that before
<cpaelzer> I'm not trying to half-answer the questions, I'm sure it will be better if I do so together with ahasenack
<LocutusOfBorg> juliank, debian bug: #908741
<ubot5> Debian bug 908741 in src:libjpeg9 "libjpeg9: do not hardcode automake version" [Serious,Open] http://bugs.debian.org/908741
<doko> http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20180911-cosmic.html
<doko> LocutusOfBorg: ^^^
<LocutusOfBorg> why is pkg-stripfiles so slow since yesterday? https://launchpad.net/ubuntu/+source/ekg2/1:0.4~pre+20120506.1-14ubuntu1/+build/15452901
<LocutusOfBorg> hours to finish a job of seconds...
<LocutusOfBorg> doko, ack
<doko> of course, not yet finished
<LocutusOfBorg> I only found one possible, I looked at all main logs
<LocutusOfBorg> (only logs where failure was in every architectures, since autoreconf is a problem everywhere)
<LocutusOfBorg> juliank, dpkg fails for a similar reason, do you think it is sane to change aclocal.m4 into ./aclocal.m4:[am__api_version='1.16'
<LocutusOfBorg> ./aclocal.m4:m4_if([$1], [1.16], [],
<LocutusOfBorg>  ?
<juliank> aclocal should be regenerated
<juliank> Is dpkg not running dh-autoreconf or overriding aclocal?
<LocutusOfBorg> debian/rules:	autoreconf -v -i
<LocutusOfBorg> no aclocal overrides
<LocutusOfBorg> nice, works  in debian...
<juliank> odd stuff
-queuebot:#ubuntu-release- Unapproved: gnome-flashback (bionic-proposed/universe) [3.28.0-1ubuntu1.1 => 3.28.0-1ubuntu1.2] (edubuntu)
<doko> jbicha, seb128: why isn't xdg-desktop-portal seeded anywhere?
<jbicha> doko: my guess is that we're waiting for bug 1750069 to be approved
<ubot5> bug 1750069 in xdg-desktop-portal-gtk (Ubuntu) "[MIR] xdg-desktop-portal-gtk" [Undecided,Confirmed] https://launchpad.net/bugs/1750069
<doko> ahh, ok
<doko> jamespage: any update on https://bugs.launchpad.net/aodh/+bug/1737989 ?
<ubot5> Ubuntu bug 1737989 in ujson (Ubuntu) "[MIR] ujson?" [Undecided,Incomplete]
<stgraber> apw: so yeah, I can introduce two empty packages just to make britney happy, seems like a bit of a hack though as those wouldn't be transitional packages, they'd literally be empty packages
<stgraber> apw: they wouldn't be transitional because the "lxd" package does not actually provide the content of lxd-tools
<apw> stgraber, except in essence it does, because the installation of lxd installs the snap which brings you the contents, in some sense
<acheronuk> only a temporary requirement anyway ^^ ?
-queuebot:#ubuntu-release- Unapproved: accepted nautilus [source] (bionic-proposed) [1:3.26.4-0~ubuntu18.04.1]
<stgraber> apw: well, that's true for the lxd-client package and lxd package, that isn't true for the lxd-tools package which has no equivalent post-deb
<stgraber> anyway, that's easy enough to do so I'll just add two transitional packages for now and then make a subsequent upload on Monday to remove them both from the archive
<rbalint> hi, do i need FFe for LP: #1317164 and LP: #1791931 ?
<ubot5> Launchpad bug 1317164 in update-manager (Ubuntu) "Show reason of TransactionFailed and let the user try again instead of crashing" [High,In progress] https://launchpad.net/bugs/1317164
<ubot5> Launchpad bug 1791931 in update-manager (Ubuntu) "Update-manager crashes in _show_transaction due to packages being already removed" [High,In progress] https://launchpad.net/bugs/1791931
<rbalint> the first one is a bit of a user interface improvement but prior crashes were not considered to be u-m issues per the bug's old text
<rbalint> i guess that's a no for requiring FFe :-)
-queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu7.5 => 1:2.11+dfsg-1ubuntu7.6] (ubuntu-server, virt)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-35.38] (core, kernel)
<acheronuk> sil2100: hi. is there any chance you could do the cosmic packageset update for Kubuntu?
<sil2100> acheronuk: hey! Yes, the scripts are running
<sil2100> Will take a moment I suppose
<acheronuk> sil2100: great. thanks. sorry to ping more than once
<acheronuk> sil2100: got your email. can I see the diff anywhere to check?
<acheronuk> if not I've saved my current one and will diff when it updates
-queuebot:#ubuntu-release- Unapproved: accepted python3.6 [source] (bionic-proposed) [3.6.6-1~18.04]
<sil2100> acheronuk: http://paste.ubuntu.com/p/pkGrpwbDZk/
-queuebot:#ubuntu-release- Packageset: 448 entries have been added or removed
-queuebot:#ubuntu-release- Unapproved: accepted python3.7 [source] (bionic-proposed) [3.7.0-1~18.04]
<acheronuk> slangasek: thanks. what I needed is in, and nothing vital dropped :)
<slangasek> acheronuk: was that directed at sil2100 ?
<acheronuk> slangasek: yup. apologies
<doko> slangasek, ogra: https://bugs.launchpad.net/ubuntu/+source/ubuntu-core-meta/+bug/1572539  where should that be seeded?
<ubot5> Ubuntu bug 1572539 in ubuntu-core-meta (Ubuntu) "[MIR] ubuntu-core-libs" [Critical,Fix committed]
<ogra> doko, probably just in supported ... though i'm not sure the archive package has even the recent packagelist
<ogra> not sure who worked on that
<ogra> (the bug is 2 years old and i have moved teams twice since i filed it ... with each move moving me further away from any archive related work sadly)
-queuebot:#ubuntu-release- Unapproved: accepted binutils [source] (bionic-proposed) [2.30-21ubuntu1~18.04]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-35.38~16.04.1] (kernel)
<slangasek> stgraber: the snapd we rather badly need for fixing regressions in cosmic is blocking on lxd autopkgtest failures; "accept4: too many open files; retrying in 1s" --> timeout.  Do you know what this is?
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-35.38~16.04.1] (kernel)
<tsimonq2> infinity, slangasek: Could wxl please get livefs FTBFS nag emails as well?
<tsimonq2> Also, gilir left the project, I don't know if he still wants to be nagged. :P
<stgraber> slangasek: hi, sorry, was in a meeting, looking now
<slangasek> tsimonq2: email address?
<tsimonq2> slangasek: wxl@ubuntu.com
<slangasek> tsimonq2: added.  and if gilir doesn't want to be nagged, he knows where to find us
<tsimonq2> slangasek: ack :)
<tsimonq2> Thanjs.
<tsimonq2> *Thanks
<stgraber> slangasek: all 3 failures appaear to be some kind of race in clustering code, amd64 was retried and is now green, just retried the other two
<stgraber> slangasek: so snapd isn't breaking LXD (not sure why it even triggered the lxd test in the first place), feel free to hint if urgent
<slangasek> o
<slangasek> ok
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-35.38~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-35.38~16.04.1]
-queuebot:#ubuntu-release- New: accepted protobuf [amd64] (xenial-proposed) [2.6.1-1.3ubuntu1]
-queuebot:#ubuntu-release- New: accepted protobuf [ppc64el] (xenial-proposed) [2.6.1-1.3ubuntu1]
-queuebot:#ubuntu-release- New: accepted protobuf [arm64] (xenial-proposed) [2.6.1-1.3ubuntu1]
-queuebot:#ubuntu-release- New: accepted protobuf [s390x] (xenial-proposed) [2.6.1-1.3ubuntu1]
<wxl> slangasek: is that something another user could do on their own? (sign up for livefs failure notices)
<slangasek> it is not
<slangasek> the configuration currently lives in the private 'production' branch for cdimage
<slangasek> this bit probably doesn't need to be private, but otoh you also probably don't want notification emails from any other random people who try to run cdimage
<wxl> right. sounds good
<wxl> in other news it seems that the lubuntu bionic alternate images haven't built since april.. uhhh?
<wxl> and the amd64 died due to unmet depends with linux. i'm assuming this will resolve itself once 4.15.0-35.38 migrates? https://launchpadlibrarian.net/388239221/buildlog_ubuntu_bionic_amd64_lubuntu_BUILDING.txt.gz
<slangasek> alternate> are they supposed to be building?  there are no emails about build failures, so that appears to be intentional
<wxl> (amd64 desktop)
<slangasek> it resolves itself when linux+linux-signed+linux-meta are all built and published in -proposed
<wxl> slangasek: i would expect the alternates to continue to build. we're certainly on the hook to continue to support them for bionic :)
<slangasek> yet no one mentioned them being absent for the point release?
<wxl> weird. they were in the original release. let me look into that further
<stgraber> slangasek: oh, just thought of something for the magic lxd deb-to-snap package, I need a Pre-Depends on snapd don't I? For the unlikely case where snapd isn't already installed.
<slangasek> the history is in lp:ubuntu-cdimage; infinity dropped lubuntu alternate builds on 2 May, and enabled bionic daily builds in a later commit the same day
<stgraber> we have a Depends right now, but that won't be good enough since we do things from preinst
<slangasek> stgraber: you need a pre-depends only if you need to talk to snapd from the deb's preinst package; do you?
<slangasek> ok then yes
<wxl> like i said, i'll investigate further. no worries on that front, slangasek.
<wxl> thanks for your help :)
<infinity> wxl: Look back, we don't do the alternates for point releases, because representing the changes in the seeded sets for the HWE stack is somewhere between difficult and impossible.
<infinity> wxl: This isn't new. :P
<wxl> infinity: tsimonq2 reminded me. i disabled them. he should have done that, but he's a bad boy, as i'm sure you already know
<tsimonq2> But I thought infinity had access to do that. :P
<tsimonq2> wxl: So don't blame me, blame Adam. :P
<wxl> oh no, you had access, too, mr. release manager :)
<tsimonq2> You're supposed to regularly looking at the tracker, Mr. QA Lead. ;)
<wxl> i'm too busy sorting through all the bugs you make :)
 * wxl *slap fight*
 * tsimonq2 *slap fight*
<tsimonq2> Love you too, wxl.
<wxl> https://v.gd/zMrzy3
<tsimonq2> You're the short one. :P
<wxl> whatever. that hat looks ridiculous.
<tsimonq2> hahahahahaha
<tsimonq2> wxl: I would propose we have #ubuntu-release-offtopic but I don't think anyone would join. :P
<wxl> XD
<wxl> it would give adam something else to roll his eyes at
<tsimonq2> Â¯\_(ã)_/Â¯
<teward> *rolls eyes*
 * tsimonq2 throws teward into /dev/null
<slangasek> Laney: do you know why amd64,arm64,i386 are taking so long to clear the autopkgtest backlog?
<slangasek> they're now a full day behind the other archs, which is exceptional
<tsimonq2> slangasek: Thoughts on vnstat's arm* tests? Seems like somethingbadtestable.
<tsimonq2> *something badtestable
-queuebot:#ubuntu-release- Unapproved: fonts-liberation2 (bionic-proposed/main) [2.00.1-5 => 2.00.1-7~18.04.1] (kubuntu, personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: fonts-liberation (bionic-proposed/main) [1:1.07.4-5 => 1:1.07.4-7~18.04.1] (desktop-core, personal-gunnarhj)
-queuebot:#ubuntu-release- Unapproved: accepted fonts-liberation [source] (bionic-proposed) [1:1.07.4-7~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted fonts-liberation2 [source] (bionic-proposed) [2.00.1-7~18.04.1]
<mfo> slangasek, sil2100: hey, tomorrow could one of you please review the nodejs openssl change for cosmic? (the issue of abi breakage w/ upstream nodejs) there's a debdiff in LP #1779863, which fixes that plus the test-case failure seen in all archs in the version currently in cosmic-proposed.  thanks!
<ubot5> Launchpad bug 1779863 in nodejs (Ubuntu Cosmic) "Ubuntu nodejs package isn't ABI compatible with mainline nodejs." [Medium,In progress] https://launchpad.net/bugs/1779863
<slangasek> tsimonq2: it didn't look badtestable to me, it looked like a version in -proposed that had regressed the tests on these archs.  What do you see that suggests otherwise?
<slangasek> mfo: done
<mfo> slangasek, thanks! :) that was fast.
<slangasek> mfo: ftbfs on s390x
<slangasek> possibly going to ftbfs elsewhere and s390x is just first
<mfo> slangasek, hm. i'll go check it.
<tsimonq2> slangasek: vnstat's arm* tests> I say that because the tests have regressed in the same way as all other arches.
<slangasek> tsimonq2: from what I see, we previously had a test, that made buggy assumptions about the host interface names so only passed on some architectures; now we have a different test, which makes different buggy assumptions, and is broken on all archs.
<slangasek> "test is now equally crappy on all architectures" is not in this case a reason to badtest, I think
<mfo> slangasek, just checked the nodejs ftbfs on s390x.  it is s390x specific and not a regression. looking at the build logs of the *previous* version (...ubuntu1), that test-case failure already happened in s390x and only in s390x.  the other test-case failure in all archs has been fixed in this upload (ubuntu2).  i'm happy to debug it on s390x and see if i can fix that too.. do you know where/whom can i get access to s390x within Canonical?
<tsimonq2> slangasek: ack, makes sense.
<slangasek> mfo: when you say 'not a regression', nodejs 8.11.2~dfsg-1 certainly built on s390x.  as for access, let me see what I can do; we unfortunately don't have a porter box set up the way we do for other archs
<mfo> slangasek, yes, that is the previous-previous version.  i mean it's not a regression caused by this upload. :)
<mfo> slangasek, it turns out that 8.11.2~dfsg-1 was built back on May iirc, then 8.11.2~dfsg-1ubuntu1 is recent (and had these test-case failures). then 8.11.2~dfsg-1ubuntu2 (this upload) should resolve the test-case failure that is common to all archs (e.g., ppc64el built successfully), but this s390x specific test-case failure I hadn't seen yet, but it is present in the build log of 8.11.2~dfsg-1ubuntu1 (previous version). that's what I mean :)
<slangasek> mfo: fair enough; still keeps the package from reaching the release pocket anyway
<mfo> slangasek, right, i undertand. that's why i'm offering to debug it. :)  and thanks for checking on s390x access, i understand it might be hard to get, unfrotunately.
<mfo> slangasek, i have to leave for the day, but can continue working on this tomorrow. thanks again for your help.
-queuebot:#ubuntu-release- Unapproved: accepted plymouth [source] (bionic-proposed) [0.9.3-1ubuntu7.18.04.1]
#ubuntu-release 2018-09-14
<slangasek> ok seriously, what's going on with the autopkgtest queues? who put the handbrake on our x86 cloud?
<slangasek> and also somehow arm64
<mwhudson> arm64 comes pre-handbraked
<slangasek> mwhudson: yes, but compare https://cdo.kpi.canonical.com/d/000000030/ubuntu-foundations?panelId=19&fullscreen&orgId=1&from=1536109870476&to=1536242063433 to https://cdo.kpi.canonical.com/d/000000030/ubuntu-foundations?panelId=19&fullscreen&orgId=1&from=1536593296201
<slangasek> is this the fault of a new toolchain?
<mwhudson> does grafana do derivatives
<mwhudson> the work rate on those two seems approximately the same?
<mwhudson> about 20 jobs / hour on arm64
<slangasek> ah, fair point
<slangasek> https://cdo.kpi.canonical.com/d/000000030/ubuntu-foundations?panelId=19&fullscreen&orgId=1&from=1535119606275&to=1535447022050 shows a much higher work rate, but maybe the tests aren't comparable
<jbicha> slangasek: is it affected by the archive rebuild in progress?
<slangasek> not directly
<slangasek> it'd be affected in terms of noisy neighbor behavior on the clouds
<Laney> slangasek: I'd check with scalingstack people; could be L1TF hitting performance or something (for x86). Also I would expect the rate to pick up once the KDE tests are through - they are mostly not very nice tests as they are C++ projects which rebuild themselves which takes ages.
<wgrant> There's a test rebuild ongoing, and overcommit is much worse than is traditional due to L1TF, yes
 * Laney said the magic word
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7 [sync] (bionic-proposed) [7.3.0-27ubuntu1~18.04]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8 [sync] (bionic-proposed) [8.2.0-1ubuntu2~18.04]
-queuebot:#ubuntu-release- Unapproved: appstream (bionic-proposed/main) [0.12.0-3 => 0.12.0-3ubuntu1] (desktop-core)
<bluesabre> Release team, can you please approve of the Xubuntu UIFe for the latest elementary-xfce? https://bugs.launchpad.net/ubuntu/+source/elementary-xfce/+bug/1792555 I've got some additional acks on the way as well
<ubot5> Ubuntu bug 1792555 in elementary-xfce (Ubuntu) "[UIFe] elementary-xfce 0.13-1" [Undecided,New]
<Ukikie> Note that while this switches the theme from being svgs to pngs, this is actually what xubuntu-icon-theme did, only difference is optipng thrown in too.
<bluesabre> thanks Ukikie
<mfo> sil2100, hey! could you please trigger a rebuild of nodejs in cosmic-proposed for ARM 64 and i386? there's a test-case failure that seems to intermittent (parallel/test-net-listen-after-destroying-stdin), which I'm investigating, so a rebuild would help.   note that s390x also FTBFS, but due to another test-case which i'm still working on.
<sil2100> mfo: ok o/
<mfo> sil2100, thanks o/
<sil2100> mfo: done, fingers crossed for success this time
<mfo> sil2100, heh, right. btw, do you happen to know whether it's possible to download the sbuild schroot used by LP somewhere?  it's being too hard to reproduce this testcase failure in a number of environemnts, including a sbuild cosmic schroot running on xenial (as LP), so i'm trying to get the environment even closer.
<cjwatson_> apt install sbuild-launchpad-chroot
<cjwatson> Or you can fetch it directly using the manage-chroot tool in lp:ubuntu-archive-tools
<cjwatson> Or from the chroot_url links in https://api.launchpad.net/devel/ubuntu/cosmic/amd64 etc.
<mfo> cjwatson, great, thank you!
<tkamppeter> Ghostscript is hanging in -proposed on the ocrmypdf autopkgtest, but ocrmypdf is only in Universe.
<tkamppeter> Current Ghostscript is an important security updated. What should we do here?
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-35.38] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: gdm3 (bionic-proposed/main) [3.28.3-0ubuntu18.04.1 => 3.28.3-0ubuntu18.04.2] (ubuntu-desktop)
<ginggs> tkamppeter: https://github.com/jbarlow83/OCRmyPDF/commit/517b385fe5cb2195023100a807e6f18dc7e6faea#diff-b61a6d542f9036550ba9c401c80f00ef
<ginggs> tkamppeter: i'm going to try cherry-picking that
-queuebot:#ubuntu-release- Unapproved: zfs-linux (xenial-proposed/main) [0.6.5.6-0ubuntu24 => 0.6.5.6-0ubuntu25] (no packageset)
<tkamppeter> ginggs, thank you very much in advance.
<ginggs> tkamppeter: that fixed one of the three failing tests, I'll look at the others soon
<tkamppeter> OK, thanks.
<tkamppeter> Another problem I am running into: cpdb-libs hangs in -proposed due to its autopkgtest failing only on arm64 and I have no way to debug it as the porter box for arm64 is broken. Can one make an exception here? AFAIR it never passed on this arch.
<Laney> that seems to be not a true statement: http://autopkgtest.ubuntu.com/packages/c/cpdb-libs/cosmic/arm64
<Laney> those results to me look like 1.2.0-0ubuntu4 is broken and 1.2.0-0ubuntu2 works
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-35.38]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-35.38]
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (bionic-proposed/universe) [20180510+dfsg1-0ubuntu4~18.04.1 => 20180905+dfsg1-0ubuntu1~18.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02+dfsg1-5ubuntu3 => 2.02+dfsg1-5ubuntu3] (core)
-queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02+dfsg1-5ubuntu3 => 2.02+dfsg1-5ubuntu3] (core)
<slangasek> Laney, wgrant: ok.  So L1TF is still affecting performance that gravely even now that intel-microcode updates are released?
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (cosmic-proposed) [2.02+dfsg1-5ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (cosmic-proposed) [2.02+dfsg1-5ubuntu3]
-queuebot:#ubuntu-release- Unapproved: ibm-java80 (xenial-proposed/partner) [8.0.5.17-0ubuntu1 => 8.0.5.20-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: octavia [amd64] (cosmic-proposed/universe) [3.0.0-0ubuntu2] (no packageset)
<wgrant> slangasek: intel-microcode only makes the L1 flush a bit more efficient; it doesn't mitigate the L1 flush's effects or make SMT usable (and we deployed the new microcode long before Ubuntu released it)
<wgrant> The permanent loss of SMT is the big problem
<wgrant> That's an easy >60% hit to capacity
<slangasek> ok
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [4.15.0-1024.25] (kernel)
<mfo> slangasek, hey, good news.  the nodejs s390x test-case failure on cosmic-proposed is fixed with the libuv1 debdiff in LP #1792647.  can i ask you for a review/upload when you have a chance, please?
<ubot5> Launchpad bug 1792647 in libuv1 (Ubuntu) "fix nodejs test-case failure on s390x and LXD" [Undecided,New] https://launchpad.net/bugs/1792647
 * mfo back later.
#ubuntu-release 2018-09-15
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [4.15.0-1024.25]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1024.25~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [4.15.0-1020.21] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1024.25~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1020.21]
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1019.22] (kernel)
#ubuntu-release 2018-09-16
-queuebot:#ubuntu-release- Unapproved: horizon (bionic-proposed/main) [3:13.0.1-0ubuntu1 => 3:13.0.1-0ubuntu2] (openstack, ubuntu-server)
<bluesabre> Release team, please approve https://bugs.launchpad.net/ubuntu/+source/elementary-xfce/+bug/1792555 so we can get our icon updates out to cosmic testers :)
<ubot5> Ubuntu bug 1792555 in elementary-xfce (Ubuntu) "[UIFe] elementary-xfce 0.13-1" [Undecided,New]
#ubuntu-release 2019-09-09
<vorlon> LocutusOfBorg: confirmed, firewalld hinted now
<mwhudson> vorlon: http://michael.hudsondoyle.geek.nz/rcbuggy-problem-packages.html
-queuebot:#ubuntu-release- New sync: taffybar (eoan-proposed/primary) [3.0.0-2]
<LocutusOfBorg> vorlon, taffybar has been fixed ^^
-queuebot:#ubuntu-release- New binary: ldc [i386] (eoan-proposed/universe) [1:1.17.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ldc [amd64] (eoan-proposed/universe) [1:1.17.0-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted freeipa [amd64] (eoan-proposed) [4.8.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted freeipa [armhf] (eoan-proposed) [4.8.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted freeipa [ppc64el] (eoan-proposed) [4.8.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ldc [amd64] (eoan-proposed) [1:1.17.0-2]
-queuebot:#ubuntu-release- New: accepted freeipa [arm64] (eoan-proposed) [4.8.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted freeipa [s390x] (eoan-proposed) [4.8.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted freeipa [i386] (eoan-proposed) [4.8.1-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ldc [i386] (eoan-proposed) [1:1.17.0-2]
-queuebot:#ubuntu-release- Unapproved: rejected net-snmp [source] (disco-proposed) [5.7.3+dfsg-5ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: accepted net-snmp [source] (disco-proposed) [5.7.3+dfsg-5ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: rejected net-snmp [source] (bionic-proposed) [5.7.3+dfsg-1.8ubuntu3.3]
-queuebot:#ubuntu-release- Unapproved: accepted net-snmp [source] (bionic-proposed) [5.7.3+dfsg-1.8ubuntu3.3]
-queuebot:#ubuntu-release- Unapproved: rejected net-snmp [source] (xenial-proposed) [5.7.3+dfsg-1ubuntu4.4]
-queuebot:#ubuntu-release- Unapproved: accepted net-snmp [source] (xenial-proposed) [5.7.3+dfsg-1ubuntu4.4]
<LocutusOfBorg> update output notest shows ghc as successful
<doko> LocutusOfBorg: do you know which tests are blocking?
<LocutusOfBorg> doko, yes
<LocutusOfBorg> https://github.com/spatialaudio/nbsphinx/issues/317
<gitbot> spatialaudio issue 317 in nbsphinx "pdf / svg generation issue with new pandoc" [Open]
<LocutusOfBorg> only this one
<LocutusOfBorg> I'm working on it
<doko> ta
<doko> too many rdepends to remove
<LocutusOfBorg> I see, unfortunately
<LocutusOfBorg> mmm I syncd antlr, dropping python-antlr, no reverse-dependencies, not shown on https://people.canonical.com/~ubuntu-archive/nbs.html but not migrating
<LocutusOfBorg> anything wrong I did on my side?
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-62.69~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-62.69~16.04.1]
<LocutusOfBorg> doko, you should probably sync stdx-allocator gir-to-d and after it dinstalls glib-d
<LocutusOfBorg> can I do it?
<doko> sure
<LocutusOfBorg> they should make the build progress a little more
<LocutusOfBorg> doko, gobject-introspection might be broken on armhf...
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/glib-d/2.1.0-1/+build/17743399
<LocutusOfBorg> _DT20_D7gobject10TypeModule10TypeModule9__mixin1316completeTypeInfoMFE7gobject1c5types5GTypePS7gobject1c5types9GTypeInfoPS7gobject1c5types15GTypeValueTableZv
<LocutusOfBorg> I can't demangle that symbol with c++filt
<doko> Laney: ^^^
<Laney> try asking ricotz
<LocutusOfBorg> I don't even know where that symbol comes from, and why it comes double
<LocutusOfBorg> oh... might be a gtk-d internal symbol
<Laney> but some debugging first would be nice I guess
<LocutusOfBorg> d language, why you so funny?
 * LocutusOfBorg goes back to ghc
<doko> Laney: duplicty wants to pull in python2 again into main, depending on python-lockfile ...
<doko> Laney: duplicity also needs a MIR for libb2 via rsync
<LocutusOfBorg> oh, libb2! that package uploaded only once on 2015 by a person who disappeared and a sponsor who disappeared, and I had to patch 6 times to make it suitable for stable...
<LocutusOfBorg> it might be in a good shape now, but meh
<tjaalton> did autopkgtests stop installing recommends?
<tjaalton> in eoan
<doko> did they ever install recommends?
<doko> LocutusOfBorg: you did a libb2 team upload without changing the maintainer ...
<tjaalton> doko: well, noticed because freeipa tests fail due to ssl-cert is not installed, and I assume it was previously pulled in by apache2
<tjaalton> could be some other package relaxed the dep
<doko> that sounds more plausible
<LocutusOfBorg> doko, it wasn't a real team upload, it was a collab-maint package
<LocutusOfBorg> anyway, I'm thinking to revert llvm-defaults to 8...
<LocutusOfBorg> https://launchpadlibrarian.net/441260638/buildlog_ubuntu-eoan-amd64.meson_0.51.2-1_BUILDING.txt.gz
<LocutusOfBorg> looks like llvm-9 is totally broken
<tjaalton> sigh
<tjaalton> and I'd need it for mesa
<LocutusOfBorg> oh... wait
<LocutusOfBorg> syncd from experimental
<LocutusOfBorg> tjaalton, this might make you happy too
<LocutusOfBorg> did you already try ~exp3?
<tjaalton> no
<LocutusOfBorg> we discussed that some days ago on #debian-llvm channel
<tjaalton> yes
<LocutusOfBorg> something bad is happening with gcc-9
<tjaalton> mesa builds fine with exp3
<LocutusOfBorg> lovely!
<Laney> doko: you probably want to tell seb128, I've not been handling that one
<Laney> or x_nox who was also looking into it
<doko> seb128: ^^^
<doko> Laney: I am abusing you as a messenger ;p
<doko> xnox is away today
<Laney> I do make a very nice secretary
<doko> foundations is in need of secretaries ...
<seb128> doko, duplicity is in universe why would it pull anything in main?
<seb128> doko, I will have a look to the depends, but someone needs to sort out the ppc64el issue :/
<doko> seb128: https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<seb128> doko, speaking about MIR can we get the rygel one unblocked?
<doko> seb128: looks incomplete according to the svg
<seb128> doko, well it's blocked on the MIR team to do the review from what I know...
<doko> seb128: well according to the svg a MIR for gupnp-av is missing. did you even look at the svg?
<seb128> doko, gupnp-av is  bug #1785629 but it expired due to the MIR team process of marking incomplete things not for the current cycles, which got closed by launchpad expiration
<ubot5> bug 1785629 in gupnp-av (Ubuntu) "[MIR] gupnp-av" [Undecided,New] https://launchpad.net/bugs/1785629
<seb128> doko, ^ it's there, just a process/tooling issue
<doko> well, you changed it from expired to new a minute ago ... not a tooling issue
<seb128> doko, well, it shouldn"'t have been closed in the first place, that process of marking incomplete things that are not incomplete is what did lead to have it expire
<seb128> doko, anyway, next refresh will give you the right color on the svg now :)
<seb128> doko, which bring back to the initial question, can we get the MIR team side unblocked? security team did ack those components and the first review comments were addressed, it should be good to og
<doko> it's not just the svg, but an expired issue is just not seen by the MIR team
<seb128> right
<seb128> don't mark bugs incomplete when they are not was my suggestion to that problem
<seb128> use a tag to skip-this-cycle or something instead maybe?
<seb128> anyway
<seb128> as said next refresh will have the correct status
<seb128> can we get back to the main topic and get the reviews unblocked?
<seb128> at least rygel and gupno-dlna got a +1 from security and I think just need MIR team to have another look but should be good to go
<xnox> seb128:  a package in main, used to dynamically install all of that.
<xnox> seb128:  the reason for it, in the past was python2, now that it is python3 it should be in main.
<xnox> seb128:  i will check what else is missing, and yeah we might skip it for now, but we really ought to bring it into main....
<xnox> and yes, at conference today
<seb128> xnox, right, well first step would be to have someone debugging what is wrong on ppc64el
<xnox> upstream is notified, in multiple bugs about ppc64el
<xnox> no idea why they are not enabling all arches in their nightly ppa
<xnox> they have regressed upstream arch support
<seb128> xnox, they are, but they seem to either not care or not be able to debug (they probably don't have access to a ppc64el system)
<doko> seb128: there is a recent thread on debian-private about access to that kind of hardware
<seb128> doko, thx for the pointer, I can try to talk to them but my impression was just that they probably have 0 user on that arch and they have no interest in debugging an issue specific to it
<seb128> doko, I don't understand that duplicity/python-lockfile reference on c-m-p
<seb128> $ dpkg -I duplicity_0.8.03-0ubuntu1_amd64.deb | grep lockfile
<seb128>  Depends: libc6 (>= 2.4), librsync2 (>= 1.0.0), python3 (<< 3.8), python3 (>= 3.7~), python3-fasteners, python3-future, python3:any (>= 3.5~), python3-lockfile, gnupg | gnupg1
<seb128> the packaging/deb reference correctly to python3-lockfile
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (disco-proposed) [3.6-1ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (bionic-proposed) [3.6-1ubuntu0.18.04.3]
-queuebot:#ubuntu-release- Unapproved: accepted sosreport [source] (xenial-proposed) [3.6-1ubuntu0.16.04.3]
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (disco-proposed/main) [1:19.04.16.6 => 1:19.04.16.7] (core)
<xnox> seb128:  it's via doc package which is recommended by python3 package, and itself depends on the python2 package
<xnox> doko:  ^ (same thing again)
<seb128> xnox, ah, thx
<xnox> seb128:  doko: excluded python-lockfile-doc from the seeds now. should go away on next report update.
<seb128> xnox, thx!
<LocutusOfBorg> please accept taffybar from eoan queue, it has been removed to fix haskell transition, but has been fixed in the meanwhile
<LocutusOfBorg> vorlon, ^^
<LocutusOfBorg> I'm uploading the last fix for haskell before migration
<fossfreedom> Hi - is there anything awry with the daily builds?  Our last two daily builds haven't completed successfully.  Any thoughts? https://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-budgie/eoan/
<RikMills> fossfreedom: I see a build for today here: http://cdimage.ubuntu.com/ubuntu-budgie/daily-live/current/
<RikMills> yesterdays livefs build failed without a log
<fossfreedom> thx. aarghhh... browser cache.  correct - all ok.  sorry for the noise
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1019.20] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1019.20]
-queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (bionic-proposed) [237-3ubuntu10.29]
#ubuntu-release 2019-09-10
-queuebot:#ubuntu-release- New sync: ocaml-charinfo-width (eoan-proposed/primary) [1.1.0-1]
-queuebot:#ubuntu-release- New sync: ocaml-stdcompat (eoan-proposed/primary) [10-1]
-queuebot:#ubuntu-release- New: accepted taffybar [sync] (eoan-proposed) [3.0.0-2]
<LocutusOfBorg> I noticed something was FTBFS on -proposed pocket because of missing cmake (probably uninstallable)
<LocutusOfBorg> I'm retrying something, now that haskell is gone
<LocutusOfBorg> also, there was stuff stuck since months on proposed, with fixes in debian unstable, I syncd it
-queuebot:#ubuntu-release- New binary: quickfix [s390x] (eoan-proposed/universe) [1.15.1+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: taffybar [amd64] (eoan-proposed/none) [3.0.0-2] (no packageset)
<LocutusOfBorg> (the total queue size shouldn't change, because it was already there)
-queuebot:#ubuntu-release- New binary: quickfix [amd64] (eoan-proposed/universe) [1.15.1+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: quickfix [i386] (eoan-proposed/universe) [1.15.1+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: taffybar [i386] (eoan-proposed/none) [3.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: quickfix [ppc64el] (eoan-proposed/universe) [1.15.1+dfsg-2] (no packageset)
<LocutusOfBorg> e.g. taffybar has been removed few days ago because of haskell ^^ its just a fixed comeback
-queuebot:#ubuntu-release- New binary: taffybar [s390x] (eoan-proposed/none) [3.0.0-2] (no packageset)
<LocutusOfBorg> quickfix was FTBFS on i386 due to glibc/new gcc with test failures, but the library looks like not used in the archive, probably just internal
<LocutusOfBorg> snakemake was not even installable because of python crash during apt
<LocutusOfBorg> so all reverse-deps (e.g. embree were FTBFS because of it)
<LocutusOfBorg> and so on
-queuebot:#ubuntu-release- New binary: quickfix [arm64] (eoan-proposed/universe) [1.15.1+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: quickfix [armhf] (eoan-proposed/universe) [1.15.1+dfsg-2] (no packageset)
-queuebot:#ubuntu-release- New binary: taffybar [arm64] (eoan-proposed/universe) [3.0.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: taffybar [armhf] (eoan-proposed/universe) [3.0.0-2] (no packageset)
<Ukikie> xfce4-sntray-plugin because it's got a very low popcon, leaf package, and fixes ftbfs with the version of vala-panel that's in eoan.
-queuebot:#ubuntu-release- New binary: igdiscover [amd64] (eoan-proposed/universe) [0.11-3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (bionic-proposed/main) [2.40+18.04 => 2.41+18.04] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: snapd (disco-proposed/main) [2.40+19.04 => 2.41+19.04] (core)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.40 => 2.41] (desktop-core, ubuntu-server)
<LocutusOfBorg> igdiscover was the one failing to install its build-dependencies because of SyntaxError: duplicate argument 'stay_on_remote' in function definition (src:snakemake)
<LocutusOfBorg> any AA please? https://bugs.launchpad.net/ubuntu/+source/samtools/+bug/1843387
<ubot5> Launchpad bug 1843387 in samtools (Ubuntu) "samtools: please remove i386 binary, already gone in Debian" [Undecided,New]
<Laney> some problem with request.cgi giving false errors atm
<Laney> it's being looked into
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [4.15.0-1042.45] (kernel)
<juliank> request.cgi should be working again. We started calling flask.escape on all inputs, but accidentally on None and flask.escape(None) = Markup("None"), which was not None.
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1042.45]
-queuebot:#ubuntu-release- New: accepted igdiscover [amd64] (eoan-proposed) [0.11-3]
-queuebot:#ubuntu-release- New: accepted quickfix [arm64] (eoan-proposed) [1.15.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted quickfix [i386] (eoan-proposed) [1.15.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted quickfix [s390x] (eoan-proposed) [1.15.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted taffybar [arm64] (eoan-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New: accepted taffybar [i386] (eoan-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New: accepted quickfix [amd64] (eoan-proposed) [1.15.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted quickfix [ppc64el] (eoan-proposed) [1.15.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted taffybar [armhf] (eoan-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New: accepted quickfix [armhf] (eoan-proposed) [1.15.1+dfsg-2]
-queuebot:#ubuntu-release- New: accepted taffybar [s390x] (eoan-proposed) [3.0.0-2]
-queuebot:#ubuntu-release- New: accepted taffybar [amd64] (eoan-proposed) [3.0.0-2]
<juliank> Laney: ok, more work needed, as flask.escape() first calls str() or something
<juliank> Laney: So doing except .. as e: invalid(e) fails right now
<Laney> which case is that?
<juliank> I'll just call str() in invalid I guess
<Laney> invalid release or something?
<Laney> yes
<juliank> Laney: All the checking raises ValueError which we catch and call invalid()
<Laney> right
<Laney> I guess either stringify in there or always pass invalid() a string
<juliank> Laney: should be fixed now, same branch as before
<juliank> Laney: I call str() in invalid(), as that's how you'd expect it to work
<juliank> I mean, you can print() an exception, you should be able to pass it to invalid() to
<juliank> *too
<Laney> makes sense
<juliank> ValueError: Unknown release eofejifejoan
<juliank> love that
<Laney> did you want to reply to the original bug btw?
<Laney> say that the subsequent problem got fixed
<juliank> oh yeah
<Laney> then he can come back with the next instance of it :>
<doko> vorlon, cjwatson: did you find out what happens with the generated of component mismatches? again out of date
<cjwatson> I wasn't looking at this
<juliank> If anyone sees any more errors from request.cgi, please ping me!
<juliank> I'll be checking in with error.log from time to time
<juliank> but not _that_ often
<cjwatson> Sometimes I have stuff to say about why some bit of the archive-reports infra is the way it is, but in general I can't be on the hook for operating it any more
<Laney> don't see any hung processes
<Laney> archive-reports is doing an auto-sync dry run at the minute, but hasn't been running very long
-queuebot:#ubuntu-release- New binary: rust-ansi-term [armhf] (eoan-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ansi-term [s390x] (eoan-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ansi-term [i386] (eoan-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ansi-term [amd64] (eoan-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-indexmap [amd64] (eoan-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ansi-term [arm64] (eoan-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-indexmap [i386] (eoan-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-ansi-term [ppc64el] (eoan-proposed/universe) [0.12.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-indexmap [s390x] (eoan-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-indexmap [arm64] (eoan-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-xoshiro [amd64] (eoan-proposed/universe) [0.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-indexmap [armhf] (eoan-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-xoshiro [i386] (eoan-proposed/universe) [0.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-xoshiro [s390x] (eoan-proposed/universe) [0.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-subtle [i386] (eoan-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-subtle [amd64] (eoan-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-subtle [s390x] (eoan-proposed/universe) [2.1.1-1] (no packageset)
<LocutusOfBorg> I'm trying to cleanup the rust proposed packages...
-queuebot:#ubuntu-release- New binary: rust-rand-xoshiro [arm64] (eoan-proposed/universe) [0.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rand-xoshiro [armhf] (eoan-proposed/universe) [0.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-indexmap [ppc64el] (eoan-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-subtle [armhf] (eoan-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-subtle [arm64] (eoan-proposed/universe) [2.1.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-ansi-term [amd64] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ansi-term [armhf] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ansi-term [ppc64el] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted rust-indexmap [amd64] (eoan-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-indexmap [armhf] (eoan-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-indexmap [ppc64el] (eoan-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ansi-term [arm64] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ansi-term [s390x] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted rust-indexmap [i386] (eoan-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-ansi-term [i386] (eoan-proposed) [0.12.0-1]
-queuebot:#ubuntu-release- New: accepted rust-indexmap [s390x] (eoan-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-indexmap [arm64] (eoan-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New binary: rust-rand-xoshiro [ppc64el] (eoan-proposed/universe) [0.3.1-2] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-subtle [ppc64el] (eoan-proposed/universe) [2.1.1-1] (no packageset)
<LocutusOfBorg> please NBS cleanup libquickfix16 :)
-queuebot:#ubuntu-release- New: accepted rust-rand-xoshiro [amd64] (eoan-proposed) [0.3.1-2]
-queuebot:#ubuntu-release- New: accepted rust-rand-xoshiro [armhf] (eoan-proposed) [0.3.1-2]
-queuebot:#ubuntu-release- New: accepted rust-rand-xoshiro [ppc64el] (eoan-proposed) [0.3.1-2]
-queuebot:#ubuntu-release- New: accepted rust-subtle [amd64] (eoan-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-subtle [armhf] (eoan-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-subtle [ppc64el] (eoan-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-xoshiro [arm64] (eoan-proposed) [0.3.1-2]
-queuebot:#ubuntu-release- New: accepted rust-rand-xoshiro [s390x] (eoan-proposed) [0.3.1-2]
-queuebot:#ubuntu-release- New: accepted rust-subtle [i386] (eoan-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rand-xoshiro [i386] (eoan-proposed) [0.3.1-2]
-queuebot:#ubuntu-release- New: accepted rust-subtle [s390x] (eoan-proposed) [2.1.1-1]
-queuebot:#ubuntu-release- New: accepted rust-subtle [arm64] (eoan-proposed) [2.1.1-1]
<cjwatson> LocutusOfBorg: done
<LocutusOfBorg> ta
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-10.11] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.3.0-10.11] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-10.11] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-10.11] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.3.0-10.11]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.3.0-10.11]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.3.0-10.11]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (eoan-proposed) [5.3.0-10.11]
<cpaelzer> lvm2 tries to confuse me, it now has Recommends: thin-provisioning-tools whcih shoudl trigger MIR in bug 1828887
<ubot5> bug 1828887 in thin-provisioning-tools (Ubuntu) "[MIR] thin-provisioning-tools" [Undecided,In progress] https://launchpad.net/bugs/1828887
<cpaelzer> but it went straight to -release - what am I missing?
-queuebot:#ubuntu-release- New binary: printrun [amd64] (eoan-proposed/universe) [2.0.0~rc5-1] (no packageset)
<cpaelzer> doko: apw: is one of you around atm to take an AAs look at this?
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20190813.1-0ubuntu0.18.04.1 => 1:20190910.1-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20190813.1-0ubuntu0.16.04.1 => 1:20190910.1-0ubuntu0.16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (disco-proposed/partner) [1:20190813.1-0ubuntu0.19.04.1 => 1:20190910.1-0ubuntu0.19.04.1] (no packageset)
<apw> cpaelzer, i am not sure that component missmatches is a blocker to promotion; to release of eoan yes
<apw> cpaelzer, also the reports which should be whining about it, are not
<cpaelzer> yeah I haven't seen it in https://people.canonical.com/~ubuntu-archive/component-mismatches
<ahasenack> I also have a component mismatch question, about https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php-defaults
<ahasenack> I think those php7.3 packages should be in main, like their php7.2 counterparts are (and 7.2 will soon be dropped)
<apw> those reports all last updated around 3am utc so ... that sounds broken
<cpaelzer> oh that is am
<cpaelzer> I silently expected 4pm +2H TZ offset
-queuebot:#ubuntu-release- New binary: printrun [s390x] (eoan-proposed/universe) [2.0.0~rc5-1ubuntu1] (no packageset)
<cpaelzer> I'm unsure what to do now, I have an approved MIR and a package in main with a dependency
<apw> cpaelzer, it has no am/pm suffix so it is '24 hour clock' or 'military time'
<cpaelzer> but this outdated report might be related
-queuebot:#ubuntu-release- New binary: printrun [amd64] (eoan-proposed/universe) [2.0.0~rc5-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: printrun [i386] (eoan-proposed/universe) [2.0.0~rc5-1ubuntu1] (no packageset)
<cpaelzer> my upload just is an hour old (or two)
-queuebot:#ubuntu-release- New binary: printrun [arm64] (eoan-proposed/universe) [2.0.0~rc5-1ubuntu1] (no packageset)
<apw> cpaelzer, i don't think you need to do anything, if it has an approved MIR, then we would find out that at the same time we find out there is a missmatch
<cpaelzer> well, I'd want to see the actual promotion of the packages happen to feel like I can forget about it
<cpaelzer> but I'm fine waiting another day
-queuebot:#ubuntu-release- New binary: printrun [armhf] (eoan-proposed/universe) [2.0.0~rc5-1ubuntu1] (no packageset)
<cpaelzer> and see if reports recover
-queuebot:#ubuntu-release- New binary: printrun [ppc64el] (eoan-proposed/universe) [2.0.0~rc5-1ubuntu1] (no packageset)
<cpaelzer> ahasenack: I'll stop talking and leave this space for you and your php-defaults question
-queuebot:#ubuntu-release- New: accepted printrun [amd64] (eoan-proposed) [2.0.0~rc5-1]
-queuebot:#ubuntu-release- New: accepted printrun [amd64] (eoan-proposed) [2.0.0~rc5-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted printrun [armhf] (eoan-proposed) [2.0.0~rc5-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted printrun [ppc64el] (eoan-proposed) [2.0.0~rc5-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted printrun [arm64] (eoan-proposed) [2.0.0~rc5-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted printrun [s390x] (eoan-proposed) [2.0.0~rc5-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted printrun [i386] (eoan-proposed) [2.0.0~rc5-1ubuntu1]
<ahasenack> ok, https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed is the correct report, and it suggest moving these php7.3 packages to main
<LocutusOfBorg> thanks to whoever accepted printrun, this will make finally cairosvg migrate!
<LocutusOfBorg> vorlon, FYI, I'm syncing rust-rand, because according to https://github.com/rust-lang/rust/issues/58516 it is "fixed" (workaround) in wasm-bindgen
<gitbot> rust-lang issue 58516 in rust "LLVM ERROR: Undefined temporary symbol when compiling wasm-bindgen-macro-support on powerpc64+powerpc64le linux" [A-Llvm, C-Bug, O-Powerpc, T-Compiler, Open]
<cjwatson> printrun> YW
-queuebot:#ubuntu-release- New sync: rust-c2-chacha (eoan-proposed/primary) [0.2.2-1]
<Laney> I'll take a look at component-mismatches now
<LocutusOfBorg> btw, I would appreciate an AA helping me understand what is blocking antlr
<LocutusOfBorg> for some reasons now update_output is clear
<LocutusOfBorg> got it
<LocutusOfBorg> I just uploaded ghc 8.8.1 to Debian experimental, can you *please* blacklist haskell to avoid people being sad?
<apw> ba
<apw> ahasenack, i thought that sounded familiar, the whole thing was in main the other week and i pulled back the ones in 7.2 which were in universe ... and now they are all in universe again, sigh
<rbasak> No these are src:php-defaults this time I think?
<ahasenack> src:php-default builds, say, php-dev, which pulls in php7.3-dev
<ahasenack> last time it was from src:php7.3. For example, bin:php7.3-imap comes from src:php7.3-imap, but is pulled in by bin:php-imap, which comes from src:php-defaults
<ahasenack> phew
<ahasenack> so php-imap is in universe (correct), php7.3-imap is also in universe (correct)
<rbasak> It isn't stuck on php-imap though?
<rbasak> php-ldap is in main (wrong I think) but php7.3-ldap is in universe (correct I think)
<cjwatson> LocutusOfBorg: there'll be no auto-syncs until after eoan releases, and certainly not from experimental.  I don't see why this is urgent
<ahasenack> rbasak: I just used php-imap as an example of what apw fixed a week or two ago
<ahasenack> rbasak: he said "that sounded familiar"
<rbasak> Ah
<LocutusOfBorg> cjwatson, I want to avoid manual errors :)
<LocutusOfBorg> and more important, myself forgetting to ask it
<LocutusOfBorg> :)
<vorlon> doko: previously component-mismatches was not running due to a stale lockfile (with a timestamp in July!) causing a failure at an earlier stage of the archive-reports run.  That stamp file is not there now, so if the c-m report isn't being run, someone will have to dig through it again to see what's failing, given that there's no real error output from archive-reports
<vorlon> LocutusOfBorg: how does rust-wasm-bindgen being fixed justify syncing a new upstream version of rust-rand?
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20190910.1-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (disco-proposed) [1:20190910.1-0ubuntu0.19.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20190910.1-0ubuntu0.16.04.1]
<LocutusOfBorg> can anybody please kick libmojo-ioloop-readwriteprocess-perl out from eoan?
<LocutusOfBorg> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939460
<ubot5> Debian bug 939460 in src:libmojo-ioloop-readwriteprocess-perl "libmojo-ioloop-readwriteprocess-perl: FTBFS and autopkgtest failures with mojo 8.23" [Serious,Open]
<LocutusOfBorg> this makes something migrate...
<bryce> apw, ahasenack what needs done to resolve the unsatisfied php7.3 depends for php-defaults?
-queuebot:#ubuntu-release- Unapproved: s390-tools (eoan-proposed/main) [2.11.0-0ubuntu1 => 2.11.0-0ubuntu1] (core)
<rbasak> bryce: scroll back a bit :)
<vorlon> doko: component-mismatches just updated, did you do something by hand?
<doko> no
<vorlon> ok
<doko> I don't even know where to look ...
<blackboxsw> hello bdmurray or RAOF. We have just completed the SRU validation process for cloud-init v. 29.2.24 Xenial, Bionic and Disco. https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1841099
<ubot5> Launchpad bug 1841099 in cloud-init (Ubuntu Disco) "SRU cloud-init (19.1.1 to 19.2.24): Xenial, Bionic, and Disco" [Undecided,Fix committed]
<blackboxsw> if there is time today for an SRU review that would be excellent
<bryce> vorlon, when you get a chance, https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed has some php7.3* packages that need moved to main.  All the corresponding 7.2 versions of the packages are currently in main:  https://paste.ubuntu.com/p/GmRSQtgyqN/.  This should help clear php-defaults from https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php-defaults
<bryce> vorlon, and thanks for tending to django-python
<vorlon> bryce: php7.3 inaries promoted
<bryce> vorlon, awesome, thank you again!
<vorlon> coreycb: python-oslo.config inary removed, that should let python-oslo.i18n in... getting closer
<coreycb> vorlon: great, thanks!
-queuebot:#ubuntu-release- New binary: wireguard [s390x] (eoan-proposed/none) [0.0.20190905-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireguard [amd64] (eoan-proposed/none) [0.0.20190905-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireguard [i386] (eoan-proposed/none) [0.0.20190905-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireguard [ppc64el] (eoan-proposed/universe) [0.0.20190905-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted wireguard [amd64] (eoan-proposed) [0.0.20190905-1]
-queuebot:#ubuntu-release- New: accepted wireguard [ppc64el] (eoan-proposed) [0.0.20190905-1]
-queuebot:#ubuntu-release- New: accepted wireguard [i386] (eoan-proposed) [0.0.20190905-1]
-queuebot:#ubuntu-release- New: accepted wireguard [s390x] (eoan-proposed) [0.0.20190905-1]
-queuebot:#ubuntu-release- New binary: wireguard [arm64] (eoan-proposed/universe) [0.0.20190905-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wireguard [armhf] (eoan-proposed/universe) [0.0.20190905-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted wireguard [arm64] (eoan-proposed) [0.0.20190905-1]
-queuebot:#ubuntu-release- New: accepted wireguard [armhf] (eoan-proposed) [0.0.20190905-1]
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1054.63] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1054.63]
-queuebot:#ubuntu-release- Unapproved: bluez (disco-proposed/main) [5.50-0ubuntu2 => 5.50-0ubuntu2.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: bluez (bionic-proposed/main) [5.48-0ubuntu3.1 => 5.48-0ubuntu3.2] (ubuntu-desktop)
<vorlon> cute, python-os-api-ref autopkgtest regression is an autodep8 bug
<vorlon> LocutusOfBorg: and rust-rand is dep-wait.
#ubuntu-release 2019-09-11
<vorlon> force-badtest autopkgtest/5.10ubuntu1/amd64 autopkgtest/5.10ubuntu1/i386
<vorlon> yay
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-release-upgrader [source] (disco-proposed) [1:19.04.16.7]
<Laney> vorlon: When removing packages per-architecture, can you start looking at reverse test-deps too please?
<Laney> dbus-test-runner/ppc64el broken by bustle removal
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (disco-proposed/main) [1:19.04.16.6 => 1:19.04.16.7] (core)
<LocutusOfBorg>  Suggests: bustle
<LocutusOfBorg> Laney, ^^ you mean that?
<LocutusOfBorg> its not even a real dependency... :/
<Laney> LocutusOfBorg: I said test-deps
<LocutusOfBorg> so, the real build has no bustle support, and the test builds with it...
<LocutusOfBorg> Laney, I was saying that the test is enabling features that nobody can use?
<Laney> it's perfectly valid for a test to use its own dependencies
<LocutusOfBorg> and I agree, but why test a feature that is not really built and used in the archive?
<LocutusOfBorg> anyhow, I wish I could have a way with reverse-depends to pick up tests/control packages...
<Laney> packages don't exist only to serve the Ubuntu archive
<Laney> If a package offers a feature, it is legitimate to test that it works
<LocutusOfBorg> it would be legitimate to build it too in the archive, unless I'm missing something obvious...
<LocutusOfBorg> I'm not saying that "testing the matrix of various configurations" is something useless to do, but it is something that upstream should do, not Ubuntu :)
<Laney> you're muddying the waters by attacking this case btw
<LocutusOfBorg> this case is my fault, so I want to understand and possibly help to fix it
<Laney> OK, you can use dbus-test-runner with bustle if you want to, it had a test to check that this functionality worked, bustle was removed so the test can't be run any more
<LocutusOfBorg> ok, so we can change the test to not run with bustle? I wish I could fix bustle, I asked for help, but there is no upstream activity
<LocutusOfBorg> even the new release is building a little bit more, but not up to the end
<Laney> I mean that's what the test is, it's called 'with-bustle' ...
<Laney> I'm not particularly saying that it was wrong to remove this binary (I don't know the case)
<Laney> more asking for tests to be checked in the same way that in-archive reverse-build and reverse-binary deps are
<LocutusOfBorg> [11:20:59] <LocutusOfBorg> anyhow, I wish I could have a way with reverse-depends to pick up tests/control packages...
<LocutusOfBorg> this is why I said this ^^ I would like to avoid next time the same issue, to have a way to do it
<Laney> laney@disco:~$ xzcat /srv/mirrors/ubuntu/dists/eoan/*/source/Sources.xz | grep-dctrl -FTestsuite-Triggers -sPackage bustle
<Laney> Package: dbus-test-runner
<LocutusOfBorg> thanks
<LocutusOfBorg> now I have to find a way to download that file
<Laney> you might want to use something like chdist
<LocutusOfBorg> Laney, it might be looking bad, but it works https://paste.ubuntu.com/p/W9KVdRzhGQ/
-queuebot:#ubuntu-release- New binary: webkit2gtk [amd64] (eoan-proposed/main) [2.26.0-1ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted s390-tools [s390x] (eoan-proposed) [2.11.0-0ubuntu1]
-queuebot:#ubuntu-release- New source: salt-pylint (eoan-proposed/primary) [2019.6.7-1ubuntu1]
<LocutusOfBorg> ^^ this is a leaf new package, please accept it, I would like to finish the pylint sadness in the archive
<LocutusOfBorg> (it might be not needed, but the Debian tracker shows it)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-63.72] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-63.72] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-63.72]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-63.72]
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1021.23] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1021.23]
<vorlon> Laney: is there an index of reverse test-dep that I can refer to?
<Laney> vorlon: not that I know of
<Laney> well, unless you count Sources.xz Testsuite-Triggers
<vorlon> Laney: do you think we should extend reverse-depends to cover those?
<Laney> vorlon: sounds reasonable, maybe reverse-depends -t or similar?
<Laney> (britney is also triggering for direct reverse binary dependencies too, but you're already checking that as part of the usual process)
<vorlon> tumbleweed: ^^ I forget, is there a way to report bugs on the reverse-depends service?
<tumbleweed> not really. Should move it to a launchpad project
<tumbleweed> there: https://bugs.launchpad.net/reverse-depends
-queuebot:#ubuntu-release- New: accepted webkit2gtk [amd64] (eoan-proposed) [2.26.0-1ubuntu1]
<vorlon> tumbleweed: cool, LP: #1843614 filed
<ubot5> Launchpad bug 1843614 in reverse-depends "reverse-depends service should report test-reverse-dependencies as well" [Undecided,New] https://launchpad.net/bugs/1843614
<vorlon> tumbleweed: interestingly, I see the latest commit on https://code.launchpad.net/~stefanor/reverse-depends/reverse-deps says "cover pre-depends", but my recent experience was that reverse-depends multiarch-support did not report the list of packages that needed fixing
<vorlon> coreycb: currently looks like python-microversion-parse, python-pbr, stevedore are critical-path for removing another chunk of the graph
-queuebot:#ubuntu-release- New binary: virtualenvwrapper [amd64] (eoan-proposed/universe) [4.8.4-4] (no packageset)
<coreycb> vorlon: thanks i'll take a look
<RikMills> Hi, could qtwebengine-opensource-src package 5.9.8 be removed from bionic-proposed please?
<RikMills> the last comment on LP: #1830807 requests this
<ubot5> Launchpad bug 1830807 in qtwebengine-opensource-src (Ubuntu Bionic) "Update to bug-fix release Qt 5.9.8 to fix security issues in qtwebengine in Bionic" [Undecided,Fix committed] https://launchpad.net/bugs/1830807
<RikMills> its presence in proposed will cause some of the things I am getting ready for SRU to FTBFS
<vorlon> RikMills: doing
<vorlon> RikMills: done
<RikMills> thanks!
<coreycb> vorlon: python-pbr reverse depends opens a bag of worms
<coreycb> vorlon: do we need to remove python-pbr in eoan?
<vorlon> coreycb: if we don't remove it, it'll be ftbfs due to missing build-depends
<vorlon> that's probably a reasonable tradeoff
<coreycb> vorlon: ok i didn't really look to see if its (Build-)Depends have already been removed. so yeah i guess we need to do that work this cycle.
<vorlon> coreycb: having one or two packages ftbfs due to missing build-deps is better than leaving NBS packages around at release time, so I am willing to draw a line there and we can burn down python-pbr revdeps if time allows
<coreycb> vorlon: that sounds like a good plan then
<ahasenack> hi, just letting you know I'm looking at the red ruby-ferret on arm64 now, the only red that is blocking ruby2.5 from migrating
<ahasenack> "you" == "the collective you"
<bryce> ahasenack, "all y'all" ;-)
<ahasenack> works :)
-queuebot:#ubuntu-release- Unapproved: rejected asterisk [source] (bionic-proposed) [1:13.18.3~dfsg-1ubuntu4build1]
-queuebot:#ubuntu-release- Unapproved: rejected mailsync [source] (bionic-proposed) [5.2.2-3.1build1.18.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected prayer [source] (bionic-proposed) [1.3.5-dfsg1-4build2]
-queuebot:#ubuntu-release- Unapproved: rejected asterisk [source] (disco-proposed) [1:16.2.1~dfsg-1build1]
-queuebot:#ubuntu-release- Unapproved: rejected mailsync [source] (disco-proposed) [5.2.2-3.1build1.19.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected prayer [source] (disco-proposed) [1.3.5-dfsg1-6build0.19.04.1]
<vorlon> coreycb: I uploaded python-diskimage-builder (revdep of stevedore), and this reveals that the openstack package build scripts are only half magic; the package has manual update-alternatives maintainer script code, but because we're no longer building the python module, the files in the packages are installed to different locations
<vorlon> coreycb: Debian dealt with this by just dropping the maintainer scripts when dropping python2.  I'm following suit, but this makes the package not sanely upgradealbe.
<coreycb> vorlon: thanks. it seems like it should be ok. pkgos-dh_auto_install won't create the /usr/bin/python{2|3}- prefixed files unless it is installing for both py2 and py3.
<coreycb> so in eoan it'll install /usr/bin/dib-block-device but in disco it would install /usr/bin/python{2|3}-dib-block-device and point the alternative /usr/bin/dib-block-device at one of those
<vorlon> coreycb: the reason it won't upgrade cleanly is that after upgrade the alternatives will still be in the database, and best case those'll be floating around in the dpkg database forever, worst case their presence will prevent the package from being upgraded at all
<coreycb> vorlon: will the prerm script from the old package get run before the package is upgraded?
<vorlon> it will, but I believe I saw that the old prerm script only removed the alternatives if the package was being removed, not upgraded
<coreycb> vorlon: alright yeah just noticed that
-queuebot:#ubuntu-release- New: accepted virtualenvwrapper [amd64] (eoan-proposed) [4.8.4-4]
#ubuntu-release 2019-09-12
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.29 => 2.525.30] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.50 => 2.408.51] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (disco-proposed/main) [2.578.7 => 2.578.8] (desktop-core)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-163.191] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1043.45] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1043.45]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-163.191]
-queuebot:#ubuntu-release- Unapproved: kdeplasma-addons (bionic-proposed/universe) [4:5.12.8-0ubuntu0.1 => 4:5.12.9-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ksysguard (bionic-proposed/universe) [4:5.12.8-0ubuntu0.1 => 4:5.12.9-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kwin (bionic-proposed/universe) [4:5.12.8-0ubuntu0.1 => 4:5.12.9.1-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: milou (bionic-proposed/universe) [4:5.12.8-0ubuntu0.1 => 4:5.12.9-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-desktop (bionic-proposed/universe) [4:5.12.8-0ubuntu0.1 => 4:5.12.9.1-0ubuntu0.1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-workspace (bionic-proposed/universe) [4:5.12.8-0ubuntu0.1 => 4:5.12.9-0ubuntu0.1] (kubuntu)
<RikMills> sil2100: New plasma SRU for bionic ^^. You'll be please to see that this time due to the very small number of sources with changes worth having, I have cherry-picked just 6
<sil2100> RikMills: I like such new upstream releases!
<RikMills> sil2100: I thought as much! Plasma 5.12 also now goes in emergency bugfix mode only. no new 'scheduled' releases
-queuebot:#ubuntu-release- Unapproved: accepted kdeplasma-addons [source] (bionic-proposed) [4:5.12.9-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted ksysguard [source] (bionic-proposed) [4:5.12.9-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted kwin [source] (bionic-proposed) [4:5.12.9.1-0ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted milou [source] (bionic-proposed) [4:5.12.9-0ubuntu0.1]
<slashd> o/ sil2100, (re: lp1843036) all good on my side if it's still okay for an early release.
<sil2100> slashd: excellent
<sil2100> slashd: will proceed in a moment
<slashd> sil2100, thanks
-queuebot:#ubuntu-release- Unapproved: accepted plasma-desktop [source] (bionic-proposed) [4:5.12.9.1-0ubuntu0.1]
<sil2100> slashd: btw. wanted to poke you about LP: #1838771
<ubot5> Launchpad bug 1838771 in apt (Ubuntu Disco) "http:Fix Host header in proxied https connections" [Medium,Fix committed] https://launchpad.net/bugs/1838771
<sil2100> slashd: Julian verified it via the autopkgtest, but before proceeding I would like you - if possible - to confirm the fix is working at least for one series
<sil2100> On a closer-to-real environment
<sil2100> Of course if it's not easily doable, I can accept things as they are if you're fine with it as well
<slashd> sil2100, let's see if I can recreate the issue easily, I'll ping you in a couple of mintes
<slashd> minutes ^
<sil2100> slashd: thanks!
<slashd> sil2100, look good to me with testing the test case
-queuebot:#ubuntu-release- Unapproved: accepted plasma-workspace [source] (bionic-proposed) [4:5.12.9-0ubuntu0.1]
<rbalint> sil2100, could you please merge this for next systemd upload?: https://code.launchpad.net/~rbalint/britney/autopkgtest-eoan-hints/+merge/372682
-queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (disco-proposed) [2.6.1-4ubuntu2.3]
-queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (bionic-proposed) [2.3-3ubuntu9.6]
<RikMills> sil2100: wow. thank you for the quick turnaround on plasma. I was genuinely not expecting that until maybe next week
<slashd> thanks sil2100 for net-snmp and apt.
 * Laney wants to join in
<Laney> thanks sil2100!
 * sil2100 feels bad now that he didn't do anything for Laney today but still got thanked
<sil2100> slashd, RikMills: yw!
<sil2100> Laney: need anything by any chance? ;p
<Laney> haha
<Laney> no, there's no debt system here
<sil2100> rbalint: on it
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [5.0.0-1019.20~18.04.1] (kernel)
<rbalint> sil2100, could you please check this, too? LP: #1843755
<ubot5> Launchpad bug 1843755 in systemd (Ubuntu) "[FFe] Please accept systemd 242 to Eoan " [Undecided,New] https://launchpad.net/bugs/1843755
<sil2100> rbalint: will try, but not sure if I'll have the capacity today
<rbalint> sil2100, thanks, no problem
<vorlon> ok so I'd seen a number of packages ftbfs when trying to do a naive drop of python2 because the distutils buildsystem required the python2 'pyversions' command - but python-openstackdocstheme dropped python2 in this way, and builds fine from source in Debian
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [5.0.0-1019.20~18.04.1]
<vorlon> anyone know what we're missing between sid and eoan for this and if it's safe to copy?
<vorlon> looks like there's a new debhelper in unstable
<doko> missing dh-python b-d?
<vorlon> no; dh-python doesn't pull in python / pyversions
<vorlon> and the build-dep is there
<vorlon> and the same package builds fine in sid, *not* in eoan
<vorlon> oh wait, pull-lp-source gave me the wrong version; let me retest this
<vorlon> ok, yeah, the Debian maintainer worked around this by neutering the dh_auto_* targets in debian/rules
<rbasak> sil2100: fyi, I'm reviewing libvirt in the Bionic SRU queue - carried over from yesterday, and I have the context from the previous qemu review
<rbasak> If it looks good I'll accept it today
<sil2100> rbasak: ok, thanks for the heads up! I'm done with my shift for today I guess
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (bionic-proposed) [4.0.0-1ubuntu8.13]
<didrocks> is there any issue in ppa uploads? /me tried 15 minutes ago to upload something to a ppa and no email of accept/denial
<didrocks> (retried to reupload 5 minutes ago -> nothing here)
<cjwatson> didrocks: should ask that in #launchpad
<didrocks> right, sorry cjwatson
<cjwatson> didrocks: but looks like a keyserver outage
<didrocks> cjwatson: thanks, keep me posted if I need to reupload
<cjwatson> I'll get the failures reprocessed once stuff's back
<didrocks> perfect, thanks
<rbalint> sil2100, maybe vorlon could take a look at the systemd FFe above?
<vorlon> rbalint: launchpad is timing out on me, but I'm in the process of trying to comment and mark the bug incomplete, because I don't think your FFe request includes compelling rationale for why this is an important update, nor analysis wrt the actual upstream changes about what the risks are of this update
<vorlon> ok, now the comment has gone through
<vorlon> coreycb: https://people.canonical.com/~ubuntu-archive/nbs.html is looking excitingly short now; don't know if it's worth revisiting python-pbr revdeps for 19.10?
<coreycb> vorlon: oh yeah that's looking a whole lot better
<coreycb> vorlon: realistically we will probably punt pbr until next cycle unless we get pushed to do it this cycle
<vorlon> fair enough
<coreycb> vorlon: thanks again for helping me with all the proposed migrations
<vorlon> sure thing
<LocutusOfBorg> vorlon, hello, I finally fixed nbsphinx, the package regressed because of pandoc
<LocutusOfBorg> unfortunately it needs a little tiny python script to work, and I uploaded it in Debian new and Ubuntu
<LocutusOfBorg> https://launchpadlibrarian.net/442049218/sphinxcontrib-svg2pdfconverter_0.1.0-1~ubuntu1_source.changes
-queuebot:#ubuntu-release- New source: sphinxcontrib-svg2pdfconverter (eoan-proposed/primary) [0.1.0-1~ubuntu1]
<LocutusOfBorg> I would appreciate if you could have a look, it is made of two python scripts, that calls imagemagick and friends to convert svg to png
<LocutusOfBorg> https://ftp-master.debian.org/new/sphinxcontrib-svg2pdfconverter_0.1.0-1.html
<sergiusens> is there a way to get reverse/test deps autopkgtests to get redone with a newer package (ref: snapcraft -> ubuntu-image to use the newer ubuntu-image)
<vorlon> sergiusens: click the 'retry' button, given that current ubuntu-image is in the release pocket
<vorlon> (the 'recycle' icon)
<LocutusOfBorg> we should probably rekick automatically tests if the package in question has migrated...
<vorlon> no
<vorlon> because the previous test wouldn't have had ubuntu-image as the trigger
-queuebot:#ubuntu-release- New: accepted fwupdate [sync] (eoan-proposed) [12-6]
-queuebot:#ubuntu-release- New: accepted ocaml-stdcompat [sync] (eoan-proposed) [10-1]
-queuebot:#ubuntu-release- New: accepted ocaml-charinfo-width [sync] (eoan-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted rust-c2-chacha [sync] (eoan-proposed) [0.2.2-1]
-queuebot:#ubuntu-release- New: accepted sphinxcontrib-svg2pdfconverter [source] (eoan-proposed) [0.1.0-1~ubuntu1]
<LocutusOfBorg> vorlon, I mean, if there is a failing autopkgtest about a version of a package that is outdated, because a new version is in release, can't we just automatically retry the test?
<LocutusOfBorg> the trigger changes, but at least we have a fresh run against the new "baseline" in release pocket
<LocutusOfBorg> I know, something else might change and break/fix it, not the package itself...
<LocutusOfBorg> like firewalld, it is not triggered on nftables updates, but each time nftables is updated... it breaks
<LocutusOfBorg> I wish we had a way to force tests in some way
<LocutusOfBorg> thanks for accepting the stuff!
<vorlon> so the long-term plan is to have rolling baseline re-tests of everything in the archive
<vorlon> but that would test against the release pocket *only*, it wouldn't help a new snapcraft in -proposed migrate
<vorlon> and we shouldn't automatically retest a package in -proposed with a failing autopkgtest every time one of its dependencies updates in the release pocket
-queuebot:#ubuntu-release- New binary: llvm-defaults [amd64] (eoan-proposed/universe) [0.48.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-defaults [ppc64el] (eoan-proposed/universe) [0.48.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-defaults [i386] (eoan-proposed/universe) [0.48.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-defaults [arm64] (eoan-proposed/universe) [0.48.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-defaults [s390x] (eoan-proposed/universe) [0.48.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: llvm-defaults [armhf] (eoan-proposed/universe) [0.48.2ubuntu1] (no packageset)
<sergiusens> thanks vorlon
<sergiusens> wasn't sure that would cause the desired effect as the line with the failure explicitly mentions the previous version of the package was used
-queuebot:#ubuntu-release- New binary: fwupdate [amd64] (eoan-proposed/universe) [12-6] (lubuntu)
-queuebot:#ubuntu-release- New binary: fwupdate [armhf] (eoan-proposed/universe) [12-6] (lubuntu)
-queuebot:#ubuntu-release- New binary: fwupdate [i386] (eoan-proposed/universe) [12-6] (lubuntu)
-queuebot:#ubuntu-release- New binary: ocaml-charinfo-width [i386] (eoan-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-charinfo-width [s390x] (eoan-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-stdcompat [s390x] (eoan-proposed/universe) [10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-stdcompat [amd64] (eoan-proposed/universe) [10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-charinfo-width [ppc64el] (eoan-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: fwupdate [arm64] (eoan-proposed/universe) [12-6] (lubuntu)
-queuebot:#ubuntu-release- New binary: ocaml-charinfo-width [amd64] (eoan-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-charinfo-width [armhf] (eoan-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-stdcompat [armhf] (eoan-proposed/universe) [10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-stdcompat [ppc64el] (eoan-proposed/universe) [10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-stdcompat [arm64] (eoan-proposed/universe) [10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-charinfo-width [arm64] (eoan-proposed/universe) [1.1.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ocaml-stdcompat [i386] (eoan-proposed/universe) [10-1] (no packageset)
-queuebot:#ubuntu-release- New binary: sphinxcontrib-svg2pdfconverter [amd64] (eoan-proposed/universe) [0.1.0-1~ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted fwupdate [arm64] (eoan-proposed) [12-6]
-queuebot:#ubuntu-release- New: accepted ocaml-charinfo-width [arm64] (eoan-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-stdcompat [arm64] (eoan-proposed) [10-1]
-queuebot:#ubuntu-release- New: accepted ocaml-stdcompat [i386] (eoan-proposed) [10-1]
-queuebot:#ubuntu-release- New: accepted ocaml-charinfo-width [amd64] (eoan-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-stdcompat [armhf] (eoan-proposed) [10-1]
-queuebot:#ubuntu-release- New: accepted ocaml-charinfo-width [armhf] (eoan-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-stdcompat [ppc64el] (eoan-proposed) [10-1]
-queuebot:#ubuntu-release- New: accepted fwupdate [amd64] (eoan-proposed) [12-6]
-queuebot:#ubuntu-release- New: accepted fwupdate [i386] (eoan-proposed) [12-6]
-queuebot:#ubuntu-release- New: accepted ocaml-charinfo-width [ppc64el] (eoan-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-stdcompat [amd64] (eoan-proposed) [10-1]
-queuebot:#ubuntu-release- New: accepted fwupdate [armhf] (eoan-proposed) [12-6]
-queuebot:#ubuntu-release- New: accepted ocaml-charinfo-width [s390x] (eoan-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-charinfo-width [i386] (eoan-proposed) [1.1.0-1]
-queuebot:#ubuntu-release- New: accepted ocaml-stdcompat [s390x] (eoan-proposed) [10-1]
-queuebot:#ubuntu-release- New: accepted sphinxcontrib-svg2pdfconverter [amd64] (eoan-proposed) [0.1.0-1~ubuntu1]
<vorlon> jamespage: you were the last uploader of python-ibm-db-sa (in 2015) which is python2-only and removed in Ubuntu. any reason to keep it?
#ubuntu-release 2019-09-13
-queuebot:#ubuntu-release- New sync: ppxfind (eoan-proposed/primary) [1.3-1]
-queuebot:#ubuntu-release- New sync: ppxlib (eoan-proposed/primary) [0.8.1-1]
<LocutusOfBorg> two little ocaml libraries that helps ppx ^^ be shiny again (the new release had a ton of compatibility fixes with old and new ocaml)
<jamespage> vorlon: no lets drop it
-queuebot:#ubuntu-release- New binary: python-vulndb [amd64] (eoan-proposed/universe) [0.1.3-1] (no packageset)
<LocutusOfBorg> vorlon, can you please restore the alt-ergo permanent hint? it is still needed... https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/3795
<LocutusOfBorg> was it dropped by mistake?
-queuebot:#ubuntu-release- New: accepted python-vulndb [amd64] (eoan-proposed) [0.1.3-1]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [amd64] (eoan-proposed) [0.48.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [armhf] (eoan-proposed) [0.48.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [ppc64el] (eoan-proposed) [0.48.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [arm64] (eoan-proposed) [0.48.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [s390x] (eoan-proposed) [0.48.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted llvm-defaults [i386] (eoan-proposed) [0.48.2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: libreoffice (disco-proposed/main) [1:6.2.6-0ubuntu0.19.04.1 => 1:6.2.7-0ubuntu0.19.04.1] (ubuntu-desktop)
<vorlon> jamespage: python-ibm-db-sa dropped, cheers
-queuebot:#ubuntu-release- Unapproved: libreoffice-l10n (disco-proposed/main) [1:6.2.6-0ubuntu0.19.04.1 => 1:6.2.7-0ubuntu0.19.04.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: wolfssl [amd64] (eoan-proposed/universe) [4.1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [s390x] (eoan-proposed/universe) [4.1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [i386] (eoan-proposed/universe) [4.1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [arm64] (eoan-proposed/universe) [4.1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [armhf] (eoan-proposed/universe) [4.1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [ppc64el] (eoan-proposed/universe) [4.1.0+dfsg-1] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [amd64] (eoan-proposed/universe) [4.1.0+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [s390x] (eoan-proposed/universe) [4.1.0+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [i386] (eoan-proposed/universe) [4.1.0+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [ppc64el] (eoan-proposed/universe) [4.1.0+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [arm64] (eoan-proposed/universe) [4.1.0+dfsg-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: wolfssl [armhf] (eoan-proposed/universe) [4.1.0+dfsg-1ubuntu1] (no packageset)
#ubuntu-release 2019-09-14
<Ukikie> â Fixes CVEs, very few users so it's good.
-queuebot:#ubuntu-release- Unapproved: cockpit (disco-backports/universe) [199-1~ubuntu19.04.1 => 202.1-1~ubuntu19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (disco-backports) [202.1-1~ubuntu19.04.1]
-queuebot:#ubuntu-release- Unapproved: cockpit (bionic-backports/universe) [199-1~ubuntu18.04.1 => 202.1-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (bionic-backports) [202.1-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New binary: thunderbird [s390x] (eoan-proposed/main) [1:68.0+build6-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: cvc3 [s390x] (eoan-proposed/universe) [2.4.1-5.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cvc3 [amd64] (eoan-proposed/universe) [2.4.1-5.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cvc3 [ppc64el] (eoan-proposed/universe) [2.4.1-5.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cvc3 [i386] (eoan-proposed/universe) [2.4.1-5.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: thunderbird [amd64] (eoan-proposed/main) [1:68.0+build6-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: thunderbird [i386] (eoan-proposed/main) [1:68.0+build6-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: thunderbird [ppc64el] (eoan-proposed/main) [1:68.0+build6-0ubuntu1] (mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: cvc3 [arm64] (eoan-proposed/universe) [2.4.1-5.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: cvc3 [armhf] (eoan-proposed/universe) [2.4.1-5.2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted cvc3 [amd64] (eoan-proposed) [2.4.1-5.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted cvc3 [armhf] (eoan-proposed) [2.4.1-5.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted cvc3 [ppc64el] (eoan-proposed) [2.4.1-5.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted wolfssl [amd64] (eoan-proposed) [4.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted wolfssl [armhf] (eoan-proposed) [4.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted wolfssl [ppc64el] (eoan-proposed) [4.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted wolfssl [amd64] (eoan-proposed) [4.1.0+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted wolfssl [armhf] (eoan-proposed) [4.1.0+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted wolfssl [ppc64el] (eoan-proposed) [4.1.0+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted cvc3 [arm64] (eoan-proposed) [2.4.1-5.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted cvc3 [s390x] (eoan-proposed) [2.4.1-5.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted wolfssl [i386] (eoan-proposed) [4.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted wolfssl [arm64] (eoan-proposed) [4.1.0+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted wolfssl [s390x] (eoan-proposed) [4.1.0+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted cvc3 [i386] (eoan-proposed) [2.4.1-5.2ubuntu1]
-queuebot:#ubuntu-release- New: accepted wolfssl [s390x] (eoan-proposed) [4.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted wolfssl [arm64] (eoan-proposed) [4.1.0+dfsg-1]
-queuebot:#ubuntu-release- New: accepted wolfssl [i386] (eoan-proposed) [4.1.0+dfsg-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted thunderbird [amd64] (eoan-proposed) [1:68.0+build6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted thunderbird [ppc64el] (eoan-proposed) [1:68.0+build6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted thunderbird [i386] (eoan-proposed) [1:68.0+build6-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted thunderbird [s390x] (eoan-proposed) [1:68.0+build6-0ubuntu1]
#ubuntu-release 2019-09-15
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.29 => 237-3ubuntu10.30] (core)
-queuebot:#ubuntu-release- New sync: ruby-gnome (eoan-proposed/primary) [3.3.8-1]
