#ubuntu-release 2010-09-20
<slangasek> ScottK: right - sorry, wound up afk in there before it showed up in the queue, and then it looks like cocoplum got a kernel security reboot :)
<slangasek> doko: looking
<ScottK> Nice.  In any case it's accepted and IIRC he pre-queued the respins
<ScottK> lamont: It looks like https://launchpad.net/ubuntu/+source/gworldclock/1.4.4-9ubuntu1/+build/1961565 could (still) stand to be shot in the head.
<ScottK> Ah.  Looks like it finally died. lamont: nevermind or thanks as applicable.
<ScottK> slangasek and doko: looking into libfvm a bit more, I find http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591346 which seems to me like the problematic conflicts is not policy compliant.  Thoughts?
<ubot4> Debian bug 591346 in hdf5 "Allow the installation of libhdf5-serial and libhdf5-openmpi at the same time" [Serious,Open]
<ScottK> FWIW, if it helps anyone's motivation to review the pending inkscape upload, it would help with NBS to get it accepted.
<cjwatson> ScottK: inkscape> looking
<cjwatson> yep, looks ok.  diff more comprehensible when one looks at packaging-only
<cjwatson> I don't understand this libcpan-meta-perl upload.  What FTBFS is it fixing?  The last upload built fine, and http://qa.ubuntuwire.com/ftbfs/ doesn't list it.  It seems to be due to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586275, but that doesn't seem to be biting us.
<ubot4> Debian bug 586275 in sbuild "sbuild: alternative build-deps and Provides do not work correctly" [Important,Open]
 * cjwatson wades through the enormous ubuntu-docs diff
<cjwatson> gst-plugins-good0.10: asked slomo in #ubuntu-devel for a version without changelog formatting errors
<jdstrand> hey, so there is a security vulnerability in bzip2. I have pocket copyied the following to maverick: bzip2 1.0.5-4ubuntu1, clamav 0.96.1+dfsg-3ubuntu5.1, and dump 0.4b43-1build1
<jdstrand> bzip2 and clamav are in main and dump in universe
<cjwatson> thanks
<cjwatson> that's OK at the moment
<jdstrand> I haven't adjusted overrides for dump or the two binaries of clamav in universe yet, as they haven't shown up where I could see them to do that
<jdstrand> in case people are wondering, dpkg no longer statically links bzip2, so I won't be touching it
<barry> i have a small fix to computer-janitor that i'd like to get a freeze exception for: https://bugs.edge.launchpad.net/ubuntu/+source/computer-janitor/+bug/434431
<ubot4> Launchpad bug 434431 in computer-janitor (Ubuntu) (and 1 other project) "Computer Janitor (GTK) does not have a panel icon (affects: 7) (dups: 1) (heat: 42)" [Low,Fix committed]
<barry> cjwatson: i have a fix for bug 433431 in computer janitor.  is it okay to upload?
<ubot4> Launchpad bug 433431 in aptdaemon (Ubuntu) "aptd crashed with error in connect() (dup-of: 424793)" [Undecided,New] https://launchpad.net/bugs/433431
<ubot4> Launchpad bug 424793 in aptdaemon (Ubuntu) "aptd crashed with error in connect() (affects: 63) (dups: 64) (heat: 24)" [High,Fix released] https://launchpad.net/bugs/424793
<stgraber> Just pushed two ltsp-cluster packages to universe, that's a bugfix so the service starts in Maverick, no bug linked as nobody noticed it yet ;)
<robbiew> barry: hmm
<barry> robbiew: just askin' ;)  it's minor so okay to defer to n
<robbiew> barry: those are always the toughest...easy to slip in, improves experience..but breaks UI freeze for a rather trivial issue...hmmm
<barry> robbiew: that's why you and skaet are here :)
<robbiew> the patch is trivial
<robbiew> I think it's worth fixing...cjwatson, thoughts?  -> "barry: i have a small fix to computer-janitor that i'd like to get a freeze exception for: https://bugs.edge.launchpad.net/ubuntu/+source/computer-janitor/+bug/434431"
<ubot4> Launchpad bug 434431 in computer-janitor (Ubuntu) (and 1 other project) "Computer Janitor (GTK) does not have a panel icon (affects: 7) (dups: 1) (heat: 42)" [Low,Fix committed]
<cjwatson> I think that's fine
<barry> cjwatson: thanks.  do i need to do anything other than just dput it as normal?
<cjwatson> just upload.  (reason I think it's fine is that I doubt people will have taken screenshots involving an obviously broken icon)
<cjwatson> (not for docs, anyway)
<barry> cjwatson: +1, thanks
<cjwatson> do notify the doc team just in case though
<barry> cjwatson: +1
<bdrung_> do i need a release team ack for sponsoring a bug fix sync (bug #637443)?
<ubot4> Launchpad bug 637443 in ndiswrapper (Ubuntu) "Sync ndiswrapper 1.56-3 (main) from Debian incoming/unstable (main) (affects: 2) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/637443
<cjwatson> sponsoring as in giving an ack?
<cjwatson> you don't need a release team ack provided you let ubuntu-archive do the sync
<cjwatson> barry: ... and, if you hadn't explicitly closed the bug by hand, it would have been closed with the changelog :)
<barry> cjwatson: gotta remember to be more patient next time :)
<bdrung_> how high will be the change to get a freeze exception for ubuntu-dev-tool 0.103?
<ScottK> bdrung_: Is it bug fix or really features?  Usually that one's not too hard to get an exception for.
<bdrung_> ScottK: some bug fixes and many new scripts (= new features)
<bdrung_> ScottK: http://packages.qa.debian.org/u/ubuntu-dev-tools/news/20100920T093212Z.html
<ScottK> bdrung_: File an FFE that includes something to the effect that these have been tested by someone other than the person that wrote the script.  I'd leave out any for which that isn't the case.
<robbiew> whew...loads of ubuntuone related requests today
<ScottK> robbiew: Isn't Monday before RC the target for uploading fixes?
<ScottK> You sound somehow suprised.
<robbiew> heh...never surprised...especially when it comes to fixes for u1 ;)
<bdrung_> ScottK: done: bug #643691
<ubot4> Launchpad bug 643691 in ubuntu-dev-tools (Ubuntu) "FFe: Please sync ubuntu-dev-tools 0.103 (universe) from Debian experimental (main) (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/643691
<Laney> You should probably test that the LP API using tools work fine against production
<ScottK> bdrung_: ^^^
<bdrung_> Laney: do you have a list of the LP API using tools?
<Laney> bdrung_: No, sorry.
<Laney> bdrung_: You can probably grep for "ubuntutools.lp"
<Laney> I don't envisage any problems as the API version was specified too
<Laney> so maybe just testing a selection of them is enough?
<jpds> u-d-t probably needs a testsuite.
<Laney> yeah. But that would have to run against staging so wouldn't exercise this particular change.
<Laney> but for other reasons, sure.
<Laney> we really ought to actually do this splitting out of stuff tooâ¦
<bdrung_> some tool are hard to test automatically.
<bdrung_> for example i can't imagine a test for syncpackage.
<doko> ScottK: Riddell around, or do you take care about the kde component mismatches?
<ScottK> doko: I try to, but I haven't looked recently.  I have to ask someone else to change stuff anyway, so usually I leave it for others.
<Riddell> I'll take a look tomorrow
<doko> just thought you might be interested in the dvd builds
<doko> Riddell: is linphone needed for kubuntu? see bug #595173
<ubot4> Launchpad bug 595173 in linphone (Ubuntu Maverick) (and 5 other projects) "[MIR] linphone (affects: 1) (heat: 8)" [High,Incomplete] https://launchpad.net/bugs/595173
<Riddell> doko: no, just a couple of libraries from the same source package
<doko> Riddell: so just demote the binary linphone package?
<ScottK> doko: Pushed your rebuilds through.
<Riddell> doko: yes
<micahg> cjwatson: are you still around?
<cjwatson> micahg: hi
<micahg> cjwatson: hi :), chrisccoulson mentioned that you said someone needed to look at lightning, we were unsure if you meant from the release team or peer review
<cjwatson> hm?  I don't remember saying that
<cjwatson> you sure it was me?
<micahg> oh, ok, well, that's what he said...anyways, if not, can we get an ack on 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: 356)" [Unknown,Unknown] https://launchpad.net/bugs/531867
<chrisccoulson> cjwatson, i asked you last week about bug 531867, and i remember you saying it needs to be reviewed by somebody
<chrisccoulson> at least i think that's what you said ;)
<cjwatson> which channel was this in?  I can go back and look at logs
<cjwatson> if you have a date/time, so much the better
<chrisccoulson> [17:39] <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
<chrisccoulson> from friday
<chrisccoulson> i suppose my original question might help too :)
<chrisccoulson> [17:38] <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)
<cjwatson> ah
<cjwatson> it's still not the most urgent thing on my list ;-)
<chrisccoulson> cjwatson - that's ok :)
<chrisccoulson> i think micahg was asking if it needed to be reviewed by somebody on the release team, or if it could be peer reviewed by somebody else
<cjwatson> ffe approved anyway
<cjwatson> an archive admin will need to review the actual package
<chrisccoulson> cjwatson, thanks
 * micahg hugs cjwatson
#ubuntu-release 2010-09-21
<cjwatson> could somebody review my grub2 upload?
<ogra> can someone let jasper-iniramfs through ?
<ogra> (i'd really like to have it on tomorrows images)
<cjwatson> ogra: looking
<ogra> thanks
<ogra> its the same upload as before, just with the typo fixed
<cjwatson> accepted
<ogra> thanks :)
<micahg> could someone please look at bug 631221
<ubot4> Launchpad bug 631221 in calendarserver (Ubuntu) "FFe: Sync calendarserver 2.4.dfsg-2 (universe) from Debian unstable (main) (affects: 10) (dups: 2) (heat: 366)" [Wishlist,New] https://launchpad.net/bugs/631221
<ara> morning!
<cjwatson> micahg: done
<ogra> hrm .... http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100921/
<ogra> antimony agrees www/full/ doesnt have them either
 * ogra would have said we have a space prob, but apparently there are 96G free atm
<ogra> uuuh
<ogra> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-netbook/maverick/ports_daily-preinstalled-20100921.log
<ogra> ===== Building Ubuntu-Netbook daily CDs =====
<ogra> Tue Sep 21 03:14:35 UTC 2010
<ogra> .: 5: CONF.sh: not found
<ogra> ===== Publishing =====
<cjwatson> was that a by-hand build of any kind?
<cjwatson> so antimony was just upgraded to lucid; I'll check whether it's related to that
<ogra> no, thats a cron build
<ogra> the normal daily
<cjwatson> looks like a bash/dash thing, will fix by backporting from upstream
<ogra> nromal daily has it too, yeah
<ogra> (x86 i mean)
<cjwatson> fixed
<cjwatson> ARCHES='armel+omap armel+omap4' for-project ubuntu-netbook cron.ports_daily-preinstalled, right?
<cjwatson> I'll rerun yours first as a reward for reporting it ;-)
<ara> Riddell, around?
<Riddell> hi ara
<Riddell> ara: are you able to edit the test cases?
<Riddell> for Kubuntu Desktop i386 and Kubuntu Desktop amd64 I'd like "Live Session" replaced with "Live Session Desktop" and "Live Session Netbook"
<ara> Riddell, hello
<ara> Riddell, yes, I can do thtat
<ara> so, you want a new testcase?
<Riddell> ara: yes
<ara> we need to modifiy the text then
<Riddell> ara: also for images "Kubuntu Netbook Arm (omap)" should be "Kubuntu Mobile Arm (omap)"
<ara>                                                                                                                                                                                                                                                                                                                                                                                                                                                                        
<ara>                                                                                                                                                                                                                                                                                                                                                                                                                                                                        
<ara>                                                                                                                                                                           
<ara> Riddell, how we distinguish Kubuntu Live Session Desktop and Netbook
<ara> ?
<ara> Riddell, also, I pinged you to ask you one thing :)
<Riddell> ara: well they look different, one looks like a typical desktop setup while the other looks like a netbook setup.  which starts up depends on the hardware you have
<ara> Riddell, that's the thing we need to determined
<ara> we need a proper testcase, so people aren't confused
<Riddell> ara: if the session works
<Riddell> does the workspace start up, can you launch applications, can you launch the installer
<Riddell> is it translated, do the plasmoids all work, can you connect to the network etc
<ara> Riddell, that's not what I mean, I meant the distinction on launching one hting or the other
<ara> i.e., which is the size limit?
<ara> when does a desktop becomes a netbook and vice-versa?
<Riddell> ara: the netbook workspace starts if you have no CD drive, have a battery and a screen < 700 pixels high
<Riddell> otherwise it starts the desktop workspace
<ara> OK :)
<ara> that's what I needed :)
<ara>  Riddell, I am getting the plymouth text mode with text "Ubuntu 10.10" (and purple colour). where do I filed the bug?
<ara> (in Kubuntu, I mean)
<Riddell> is bug 613636
<ubot4> Launchpad bug 613636 in plymouth (Ubuntu) "Kubuntu Maveric ISOs show purple "Ubuntu 10.10" boot splash instead of the blue Kubuntu one. (affects: 1) (heat: 80)" [Undecided,Confirmed] https://launchpad.net/bugs/613636
<ara> OK, thanks
<Riddell> maybe I should look at that today
<Riddell> ara: also need "Kubuntu Desktop Arm (omap)" with "Live Session" test case
<ara> with both?
<Riddell> ara: how do you mean?
<Riddell> we need both "Kubuntu Mobile Arm (omap)" and "Kubuntu Desktop Arm (omap)"
<ogra> cjwatson, merci :)
<sistpoty|work> cody-somerville: are you ok to act as ubuntu-release delegate for xubuntu for this cycle again?
<sistpoty|work> oh, and does anyone happen to know wether seb128 is on vac? he and cody are the only persons on my list from whom I haven't got a confirmation yet
<cjwatson> I vaguely remember seb128 being on vacation, yes
<sistpoty|work> oh, hm. what do we do with gnome then?
<sistpoty|work> maybe just not delegate gnome for this cycle and try to get it sorted out early for natty?
<ogra> sistpoty|work, for urgent requests try didrocks, though note that he is overworked already
<sistpoty|work> ogra: would be ok for me
<doko> what do we do with the libcairo-perl test failures, just ignore them?
<doko> ogra: OOo now built in maverick, should be downloadable in about 20min. please can you check it?
<ogra> doko, oh, didnt GrueMaster contact you yet ?
<ogra> he was tasked with the kakadu tests
<doko> ogra: no
<ogra> yesterday actually
<ogra> bah
<doko> anyway, it's now in the archive
<ogra> ok
<doko> still building for lucid
<ScottK> Riddell: Is libosip2 supposed to be in Universe?
<ScottK> (it's in the Kubuntu package set)
<Riddell> ScottK: I'm onto it
<Riddell> doko moved it there
<ScottK> I can accept it into Main when I review it if you want?
<Riddell> presumably to revoke kees MIR and get me to add a .symbols file, which I'm doing now
<Riddell> ScottK: yes please do
<ScottK> OK.
<ScottK> Still waiting for the diff.
<doko> Riddell: no, I didn't move it there ... really please keep an eye on component mismatches that you introduce when promoting stuff
<Riddell> shrug, someone did, after I'd already moved it to main with bug 595162
<ubot4> Launchpad bug 595162 in libosip2 (Ubuntu) "[MIR] libosip2 (affects: 1) (heat: 40)" [Undecided,Fix released] https://launchpad.net/bugs/595162
<ScottK> Riddell: Done.
<Riddell> ScottK: kdesdk needing review too while you're in the mood
<ScottK> Yep.  Waiting for the diff.
<doko> Riddell: preparing libexosip too?
<Riddell> doko: yes
<doko> Riddell: ok, closing these bug reports. wasn't aware of these, and didn't demote it myself (if it was ever promoted)
<ScottK> Riddell: libexosip should get promoted too when I review/accept it?
<doko> ScottK: yes, see bug #595165
<ubot4> Launchpad bug 595165 in libexosip2 (Ubuntu) "[MIR] libexosip2 (affects: 1) (heat: 40)" [Undecided,Fix released] https://launchpad.net/bugs/595165
<ScottK> Riddell: For kdesdk - When you added back poxml, you dropped some antlr related files for it's .install file.  Shouldn't those get put back too?
<ScottK> Riddell: libexosip accepted too.
<Riddell> ScottK: no those files don't exist in our build
<ScottK> OK.
<Riddell> not sure why they do in Debian's, but they're not needed
<ScottK> Riddell: Accepted that one too.
<Riddell> maybe they have different antlr packaging
<stgraber> That pidgin upload simply includes a tested upstream patch to fix Bonjour support (in current maverick, a user can't initiate a new Bonjour conversation).
<ScottK> Riddell: FYI, quassel just did a security release.  I'm packaging it now.
<Riddell> ScottK: thanks, anything needing done for lucid or older?
<ScottK> Riddell: Yes.  See Bug 629774.
<ubot4> Launchpad bug 629774 in quassel (Ubuntu) "Undisclosed ctcp based DoS vulnerability (affects: 1) (heat: 262)" [Undecided,Confirmed] https://launchpad.net/bugs/629774
<Riddell> no CVE number?
<ScottK> Not AFAIK.
<ScottK> I don't think they felt like doing the paperwork.  They just mailed vendor-sec.
<doko> now looking at bug #597254 ...
<ubot4> Launchpad bug 597254 in srtp (Ubuntu) "[MIR] srtp (affects: 1) (heat: 40)" [Undecided,New] https://launchpad.net/bugs/597254
<Riddell> srtp has the troublesome property of not building locally for me :(
<ScottK> Riddell: ^^^ quassel security fix for you.
<sistpoty|work> ScottK: did you send a mail to u-d-a regarding final freeze for unseeded universe yet?
<ScottK> sistpoty|work: I did.  It's in the moderation queue.
<ScottK> Maybe robbiew has been busy.
<sistpoty|work> ah, k, thanks
 * Riddell moves  kubuntu-mobile  to main
<robbiew> ScottK: I don't have access to u-d-a moderation :/
<ScottK> Shoot.  Who does?
<ScottK> cjwatson: Do you?
<robbiew> ack...I believe he does
<cjwatson> yes
<cjwatson> ScottK: moderated
<ScottK> cjwatson: Thanks.
<sistpoty|work> \o/
<ogra> ScottK, sistpoty|work, you should offer a deal ... uploads get only approved if an FTBFS gets fixed additionally on a 1:1 relationship ;)
<sistpoty|work> heh
<persia> What happens to folk who mostly upload FTBFSs?  Are credits transferable?
<ogra> only collectable i'd say
<ogra> turns FTBFSers automatically into universe sponsors ;)
<persia> heh
<doko> please consider llvm-2.8, llvm-defaults and opengtl (bug #632727)
<ubot4> Launchpad bug 632727 in opengtl (Ubuntu Maverick) (and 11 other projects) "FFe: include llvm 2.8 and corresponding package in maverick (affects: 1) (heat: 8)" [Medium,In progress] https://launchpad.net/bugs/632727
<doko> Riddell: srtp not accepted. can we demote linphone? the ortp library should be built separately
<Riddell> doko: that won't help, libortp8 depends on libsrtp
<doko> ohh joy ...
<smoser> hi. https://bugs.launchpad.net/ubuntu/+source/ec2-api-tools/+bug/644074 i'm wondering if there is enough info there, or whatelse i would need to add to get that bug accepted for FFE.
<ubot4> Launchpad bug 644074 in ec2-api-tools (Ubuntu) "upgrade ec2-api-tools to 1.3-57419 (api version 2010-08-31) (affects: 1) (heat: 8)" [Medium,In progress]
<sistpoty|work> smoser: have you tested the new features yet?
<doko> can I sync python-imaging from unstable? see bug #622388
<ubot4> Launchpad bug 622388 in python-imaging (Debian) (and 1 other project) "_imagingcms.so missing in python-imaging (affects: 2) (heat: 10)" [Unknown,Unknown] https://launchpad.net/bugs/622388
<sistpoty|work> doko: ACK
<doko> sistpoty|work: thanks, synced
<micahg> cjwatson: thanks
<Cimi> hi
<smoser> sistpoty|work, sorry, yes, tested some of them.
<sistpoty|work> smoser: ok for me then, but please keep an eye open for regressions
<smoser> ok, so i'm ok to upload ?
<sistpoty|work> smoser: yep
<ScottK> sistpoty|work: If you want me to push accept on packages you've reviewed the diff on, just give me a ping.
<sistpoty|work> ScottK: ok, will do
<sistpoty|work> however right now, I'll be heading home :)... cya
<ScottK> That's some fast reviewing.
<zul> hi can someone approve the upload for landscape-client FFE please (LP: #641264)
<doko> Riddell: kdesvn: kdesvn-kio-plugins libsvnqt6
<doko>    [Reverse-Depends: kdesdk, kdesvn-kio-plugins]
<ScottK> slangasek: I'd appreciate it if you'd ack ^^^ clamav.  See Bug #644707 for details.
<ubot4> Launchpad bug 644707 in clamav (Ubuntu) "FFe for clamav 0.96.3 (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/644707
<slangasek> ScottK: accepted
<ScottK> slangasek: Thanks.
#ubuntu-release 2010-09-22
<ogra> hmm, did someone turn off image autobuilds ? i got no images butu i also got no failre mails
 * ogra checks on antimony
<Riddell> images seem to be building today
<ogra> hmm, nothing obvious and a manual build seems to be running fine
<ogra> weird
<sistpoty|work> cjwatson: can you moderate my mail regarding delegates to u-d-a please?
<cjwatson> sistpoty|work: dodne
<cjwatson> done
<sistpoty|work> thanks cjwatson
<bdrung_> is bug #640682 ok?
<ubot4> Launchpad bug 640682 in ibus-unikey (Ubuntu) "Please sync 0.5-2 from debian unstable (affects: 2) (heat: 22)" [Undecided,New] https://launchpad.net/bugs/640682
<micahg> could someone please look at bug 631836
<ubot4> Launchpad bug 631836 in activeldap (Ubuntu) "FFe: Sync activeldap 1.2.2-1 (universe) from Debian unstable (main) (affects: 2) (dups: 1) (heat: 255)" [Wishlist,New] https://launchpad.net/bugs/631836
<doko> Binary only promotions to main
<doko>  ------------------------------
<doko>  o libgl1-mesa-dri-experimental                                         {mesa}
<doko>    [Reverse-Depends: libgl1-mesa-dri-experimental-dbg]
<doko> cjwatson: ok to demote these?
<cjwatson> YM promote?
<cjwatson> er, I think so, but I was holding off on that one because I vaguely recall there being a bug about it
<cjwatson> anyone know?
<doko> well, the eperimental doesn't encourage me
<Riddell> yes there was a bug
<Riddell> bryce wanted it in universe
<Riddell> bug 638097
<ubot4> Launchpad bug 638097 in mesa (Ubuntu) "Universe binary demotion request for libgl1-mesa-dri-experimental (affects: 1) (heat: 491)" [Undecided,Fix released] https://launchpad.net/bugs/638097
<Riddell> moved libgl1-mesa-dri-experimental-dbg to universe
<doko> Riddell: libgl1-mesa-dri-experimental too?
<Riddell> yes
<cjwatson> Riddell: I think it needs seed mangling to make sure it stays there
<cjwatson> given that it's showing up in component-mismatches
<Riddell> even now that libgl1-mesa-dri-experimental-dbg is also demoted?
<cjwatson> yes.  component-mismatches does not consider what is currently in main, it considers what it thinks should be in main and compares
<cjwatson> you shouldn't close such a bug until component-mismatches says that you can demote the package
<cjwatson> I'll sort it out
<Riddell> I see, the -dbg package gets pulled in because it's -dbg and it needs an Extra-exclude
<cjwatson> right, that's what I'm doing now
<bdrung_> can a release team member have a look at bug #645339?
<ubot4> Launchpad bug 645339 in mozilla-devscripts (Ubuntu) "Drop transitional and removed packages from Recommends (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/645339
<cjwatson> bdrung_: is it a good idea to drop these recommends in maverick?  I'd have thought it would be generally good to keep them for partial upgrades and the like
<cjwatson> bdrung_: for the purposes of NBS, we can consider these as false positives ...
<micahg> cjwatson: they were all transitional packages in Lucid
<cjwatson> bdrung_: I don't actually object to the change I suppose, but you shouldn't do it if NBS is the only reason
<cjwatson> bdrung_: ok
<cjwatson> then I guess it's fair enough
<bdrung_> cjwatson: the NBS is mostly the reason (having useless items in recommends). one benefit of rebuilding (all) extension is to let them pick up the benefits of the newer version of mozilla-devscripts
<bdrung_> cjwatson: and it will make sure that coming SRUs won't hit any issues (and SRUs will come once firefox-4.0 comes to maverick)
<cjwatson> what other benefits?
<cjwatson> you only list one changes
<cjwatson> change
<cjwatson> IOW, what set of changes am I accepting here if I ack rebuilding all the extensions?
<cjwatson> your bug didn't mention that there was an ulterior motive
<micahg> bdrung_: firefox-4.0 isn't coming to maverick
<bdrung_> micahg: really? will maverick EOL before firefox 3.6 EOL?
<micahg> bdrung_: well, we'll jump to 4.1 probably, but everything will need updates most likely
<bdrung_> cjwatson: some changes in mozilla-devscripts 0.21
<micahg> bdrung_: we have 0.23 in maverick
<cjwatson> I think the implication is that extensions haven't been rebuilt for a while?
<cjwatson> but I'd really prefer somebody to actually be clear about this
<bdrung_> yes, some packages may weren't rebuild after the release of m-d 0.23
<bdrung_> yes, some packages may weren't rebuild after the release of m-d 0.21
<bdrung_> cjwatson: before releasing m-d 0.21 i did a rebuild test with all extensions.
<cjwatson> I can see the changelog but I don't have the background to work out what it all means for extensions.  Please try to explain in plain English in the bug what the effects of rebuilding extensions will be
<bdrung_> cjwatson: it will add a configuration file in /etc/xul-ext (if has a config file) and will install the extension into /usr/share/xul-ext/<package> instead of /usr/share/xul-ext-<package>
<cjwatson> in the bug, please?
<bdrung_> cjwatson: done
<bdrung_> can a release team member have a look at bug #643691? ubuntu-dev-tools should be ready now.
<ubot4> Launchpad bug 643691 in ubuntu-dev-tools (Ubuntu) "FFe: Please sync ubuntu-dev-tools 0.103 (universe) from Debian experimental (main) (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/643691
<ScottK> bdrung_: Does this have the fixes for the problems found in yesterday's testing?
<bdrung_> ScottK: yes
<ScottK> OK.  I'll have a look.
<bdrung_> ScottK: and even more bug fixes
<ScottK> bdrung_: Approved.
<bdrung_> ScottK: thanks
<ScottK> No problem.
<ScottK> bdrung_: Since you're going to be uploading this in Debian now, I'll warn you that it is quite normal for people to commit a lot of not tested, barely functional changes to u-d-t, so I wasn't suprised the testing found problems.  Be careful.
<bdrung_> ScottK: ok, i will remember that.
<ScottK> Several cycles ago I got annoyed by it and started testing it.  Once I had upwards of a dozen bugs filed I got tired and quit.
<bdrung_> ScottK: the package needs test suites
<bdrung_> cjwatson: we still have the ACK for m-d from you?
<doko> cjwatson: is it ok to accept the llvm-defaults binaries in NEW?
<cjwatson> bdrung_: for m-d itself, but I haven't acked the extensions rebuild yet.  will look in a bit
<cjwatson> doko: I never accept binaries from something I uploaded.  I can have a look at yours after dinner
<doko> cjwatson: no. just wanted you to review them
<ScottK> Is the queuebot off on purpose?
<cjwatson> ScottK: no, it dies if something goes wrong with my connection
<cjwatson> I should probably make it wait for a while and retry
<ScottK> Thanks.
<cjwatson> hm, arguably I should make it not do that on startup, too
<doko> not unbusy
<cjwatson> maybe I ought to run it on chiark or something
<cjwatson> don't like running irc bots on company equipment
<Daviey> Hi friendly release team.  jdstrand has uploaded a fix for bug #628055... (^^ from queue-bot).  Would it be possible for that to be accepted in time for daily iso build?
<ubot4> Launchpad bug 628055 in libvirt (Ubuntu Maverick) (and 3 other projects) "Instances don't start correctly on 32bit systems with large disk files (affects: 2) (heat: 12)" [High,Fix committed] https://launchpad.net/bugs/628055
<Daviey> (Justification, currently UEC on i386 is pointless)
<ScottK> Looking.
<jdstrand> its more than just UEC, but that is probably more than enough
<jdstrand> s/its/it's/
<Daviey> oh yeah, sure.
<Daviey> jdstrand, I don't see any other teams sponsoring you at the bar, for uploading that...   So UEC is the prime target :)
<jdstrand> hehe
<bdrung_> any archive admin here?
<jdstrand> bdrung_: it is not my day, but what do you need?
<bdrung_> jdstrand: i like to get mozilla-devscripts 0.24 synced (ACKed in bug #645339)
<ubot4> Launchpad bug 645339 in ubufox (Ubuntu) (and 1 other project) "Drop transitional and removed packages from Recommends (affects: 1) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/645339
<ScottK> Daviey (and jdstrand): Accepted.
<Daviey> ScottK, \o/
<Daviey> Thanks ScottK
<jdstrand> ScottK: thanks :)
<ScottK> Daviey: You're welcome. (jdstrand too).
<jdstrand> bdrung_: I can do that
<bdrung_> jdstrand: why?
<jdstrand> bdrung_: because you asked me to?
<jdstrand> I suppose I don't have to...
<bdrung_> jdstrand: it's the second time this day that i misread something
<jdstrand> :)
<bdrung_> which inverted the meaning :)
<jdstrand> bdrung_: so just so we are clear. you *would* like me to tend to bug 645339?
<ubot4> Launchpad bug 645339 in ubufox (Ubuntu) (and 1 other project) "Drop transitional and removed packages from Recommends (affects: 1) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/645339
<bdrung_> jdstrand: yes :)
<jdstrand> bdrung_: done
<bdrung_> jdstrand: thanks
#ubuntu-release 2010-09-23
<asantoni> ScottK: Freeze exception bug filed for Mixxx - https://bugs.launchpad.net/ubuntu/+source/mixxx/+bug/645804
<ubot4> Launchpad bug 645804 in mixxx (Ubuntu) "Fix visual artifact due to Qt bug or upgrade to 1.8.0.1 final (affects: 1) (heat: 10)" [Undecided,New]
<asantoni> I tried to make it as complete as possible, followed the FreezeExceptionProcess wiki page closely (you said to ping you when that stuff's all done)... Thanks for your attention!
 * ScottK looks
<ScottK> asantoni: This one is on the Ubuntu Studio ISO?
<ScottK> asantoni: Does this fix any of the other open mixxx bugs? https://bugs.launchpad.net/ubuntu/+source/mixxx
<ScottK> asantoni: Do you monitor Ubuntu mixxx bugs (are you subscribed to them)?
<asantoni> ScottK: I believe it's part of the Ubuntu Studio ISO, as mixxx is part of the ubuntustudio-audio metapackage
<asantoni> The 1.8.0.1 release fixes like 50 bugs on Launchpad
<ScottK> asantoni: Yes.  That would mean it was.
<asantoni> if you check the bzr log that's attached, you'll find many references to Launchpad bugs that were fixed since the RC
<ScottK> OK.
<ScottK> It's 3:30 AM here, my eyes glazed over part way through.
<asantoni> I don't monitor Ubuntu bugs, but I will and I can sort through the existing bugs (most of them are probably fixed)
<asantoni> no problem!
<ScottK> asantoni: If I'm going to let this in, then I want to make sure someone from the development team is monitoring the Ubuntu mixxx bugs to react to any regressions that appear.
<asantoni> Ok, I've subscribed our whole team
<ScottK> Excellent.
<ScottK> asantoni: I've approved the FFe.  You'll still need to find a sponsor to upload it to the Ubuntu archive.
<ScottK> I subscribed the sponsors team, so someone should look at it eventually, but you're welcome to be more proactive.
<asantoni> Thanks, will do!
<cjwatson> doko: accepted llvm-defaults binaries
<ttx> ScottK: here it is ^
<ScottK> ttx: Thanks.  Looking.
<jdstrand> ScottK: what do you think about my debdiff for bug #641243? it would be nice to fix for maverick, but I've not gotten any feedback
<ubot4> Launchpad bug 641243 in evolution-data-server (Ubuntu) "camel-lock-helper not sgid mail; can't lock /var/mail files (affects: 2) (dups: 1) (heat: 16)" [Undecided,Triaged] https://launchpad.net/bugs/641243
<ScottK> I guess my thought is meh, it's Evolution.  No one really uses that.  Let me look.
<jdstrand> hehe
<jdstrand> I know a few that do ;)
<ScottK> jdstrand: If I understand the bug, it would be a regression not to fix that, so it should go in.
<jdstrand> ScottK: you do understand the bug
<jdstrand> I'll upload
<jdstrand> ScottK: fyi-- uploaded evolution-data-server and clamav
<jdstrand> I just did clamav, so it'll be a minute
<cjwatson> ara: were you planning on starting wubi upgrade testing?
<cjwatson> I vaguely recall asking you to hold off for a bit
<ara> cjwatson, it is ongoing, I think jibel did an upgrade
<ara> jibel, did you?
<ara> cjwatson, i don't have a machine with windows, I cannot test it myself
<jibel> right, amd64
<cjwatson> I just wanted to let you know that I did a lucid->maverick test yesterday and it finally worked
<cjwatson> jibel: did it work?
<ara> cjwatson, great to know
<jibel> cjwatson, yes flawlessly. It failed the previous week.
<cjwatson> great - I shall get the fix for bug 581760 into lucid-proposed in my copious free time, then
<ubot4> Launchpad bug 581760 in grub2 (Ubuntu Maverick) (and 3 other projects) "[Wubi] when updating it advices to install grub on all partitions (affects: 1) (heat: 6)" [High,Fix released] https://launchpad.net/bugs/581760
<cjwatson> that's a relief
<Riddell> ScottK: your favourite package up again for review ^^
<stgraber> can someone please reject nanny ? .diff.gz isn't clean. It's going to be re-uploaded.
<stgraber> thanks
<highvoltage> hey, would someone with access please reject my nanny upload? I need to upload a new version and don't want to delay it too much!
<cjwatson> just upload
<cjwatson> two packages with the same version can exist in the queue at once
<cjwatson> I've rejected it anyway, though
<highvoltage> cjwatson: great, thanks!
<stgraber> oh, interesting, I didn't know that it was possible to have the same version twice in the queue
<ScottK> https://bugs.launchpad.net/~ubuntu-release is down to one page.  Someone else's turn .....
<iulian> Hm, I guess it's my turn.
<iulian> OK, I tihkn that's all for today.
<iulian> think even.
#ubuntu-release 2010-09-24
<lamont> mass giveback done per request from doko, just fyi < skaet / slangasek
<ScottK> Oh my.
<skaet> lamont, thanks for the head's up.
<lamont> not that much, actually.
<lamont> now that I've really done the giveback. :-(
<lamont> arm was the winner at 112 jobs
<ogra> lamont, acorn reboot ping :)
<ogra> lamont, it's hanging once again
<lamont> ogra: bbg3 boards aren't remotely rebootable. :-(
<lamont> well, powerstabable
<ogra> lamont, yeah, i know, seems Nafallo already cared when i pinged anyway
<ScottK> I'd appreciate it if another release team member would double check this, but doesn't the pm-utils upload need a b-d on dpkg-dev added to use dpkg-vendor?
<ogra> lamont, cjwatson, would http://paste.ubuntu.com/499635/ seem suitable for you to fix bug 600478 ?
<ubot4> Launchpad bug 600478 in livecd-rootfs (Ubuntu Maverick) (and 2 other projects) "livecd.sh should remove foreign subarch headers during livefs build (affects: 1) (heat: 47)" [Medium,Confirmed] https://launchpad.net/bugs/600478
<lamont> ogra: does that want to override, instead of appending?
<lamont> ogra: otherwise, I'm head deep in some other stuff atm... testing would be love, etc...
<ogra> lamont, right, on amrel images we currently end up with all linux-headers packages for all subarches
<ogra> and we only want the one for the actual subarch we build
<lamont> ah, yeah.  that's a somewhat stab-in-the-face approach, but may well be right.
<lamont> I haven't really reviewed it
<ogra> i'll run a testbuild ... takes only 90min
<ogra> (once my babbage boots)
<cjwatson> ScottK: perhaps a versioned b-d, but it may not matter since lucid had dpkg-vendor in its dpkg-dev
<ScottK> cjwatson: Right, but AFAICT, it doesn't b-d on dpkg-dev at all, so I don't see how the change could work?
<cjwatson> ScottK: is it using it at build time, rather than run time?
<cjwatson> ScottK: dpkg-dev is build-essential ...
<ScottK> Ah.  OK.
<ScottK> That was the bit I was missing.
<cjwatson> has to be given things like dpkg-source :-)
<ScottK> cjwatson: Thanks.
<cjwatson> if you catch things using dpkg-vendor at run-time, that's almost definitely a bug
<cjwatson> anyone care to eyeball bug 634554 for me?  I think the upstream update is appropriate for maverick
<ubot4> Launchpad bug 634554 in fuse (Fedora) (and 4 other projects) "fuse mounts hang on xattr retrieval with auditd (affects: 4) (heat: 28)" [Unknown,Unknown] https://launchpad.net/bugs/634554
 * cjwatson lobs it at the queue
<ScottK> I'm not qualified to review the code diff, but from the changelog it sounds reasonable.
 * cjwatson nods.  Thanks.
<cjwatson> ntfs-3g still works ;-)
<cjwatson> the rest of the queue is either my uploads or stuff I'm too closely involved with to review
<cjwatson> also, the sysvinit and mountall uploads are coupled; not strongly enough to justify a dependency relationship, but if sysvinit goes in without mountall then there'll be a bit of error noise at boot
<doko> cjwatson: why does gs-common show up as a candidate for demotion? it's used as a b-d, but it's a virtual package?
<ScottK> cjwatson: When you have a couple of minutes, I have an idea for a platform related LP change I'd like to run by you.
<cjwatson> doko: presumably germinate always picks something else
<cjwatson> ScottK: sure
<ogra> ok, my livecd-rootfs headers fix works fine ...
 * ogra commits and uploads
<ScottK> cjwatson: It occurred to me that it would possibly be useful for non-archive admin members of the release team (such as sistpoty and iulian) to have access to the unapproved queue for the development release (like I do by virtue of being an archive admin).
<ScottK> cjwatson: I chatted with wgrant about it and it's apparently feasible to do this.  We might also want similar for -proposed for ubuntu-sru members that aren't archive-admins.
<doko> cjwatson, ev: libutouch-grail1-udeb utouch-grail-tools xserver-xorg-video-fbdev-udeb demotions ok? installer stuff
<cjwatson> ScottK: agreed, I think ubuntu-release should have queue admin access
<cjwatson> doko: yes, for now (though I want to look at those for later)
<ScottK> cjwatson: Thanks.  How about ubuntu-sru for -proposed?
<cjwatson> ScottK: fine by me, it makes sense
<ScottK> OK.  Great.  I'll talk to wgrant to see if we can make it happen.
<cjwatson> that would be wonderful, thanks
<ScottK> cjwatson: I have a question about your language-selector upload.  The comment right before the line that's changed is "# rename is atomic".  AFAICT that's true of os.rename and also true of shutil.move if it's src and dst are on the same file system, but not if they aren't.  I'm not sure if we care, but I thought it was worth a mention to doublecheck.
<ScottK> doko: About your axis upload - I don't find that we have a package named libservlet2.5-java-gcj (just 2.4).
<doko> well, then we should build it, or drop libjava-axis-gcj
<doko> so better build it for 2.5 at this stage
<cjwatson> ScottK: good question.  let me see if it matters
<cjwatson> hm, yes, it does, we're doing it on /etc/default/locale
<ScottK> Thanks.
<cjwatson> so I think instead we want something like:
<cjwatson> try:
<cjwatson>     os.rename(out.name, fname)
<cjwatson> except OSError:
<cjwatson>     shutil.move(out.name, some_name_on_same_fs)
<cjwatson>     os.rename(some_name_on_same_fs, fname)
<ScottK> Want me to reject it then?
<cjwatson> actually maybe that's nonsense, perhaps we should just create the tempfile on the same fs to start with
<cjwatson> yes please
<ScottK> DOne.
<ScottK> doko: I'll defer to you on how best to fix it, but your current upload would make the package uninstallable.  How about if I reject it and you upload again once it's sorted?
<cjwatson> I think perhaps http://paste.ubuntu.com/499706/
<doko> ScottK: no, please let it stay, I'll upload a new libservlet2.5
<ScottK> doko: OK.
<ScottK> cjwatson: I think so, but I'm only looking at the changes, I don't understand the surrounding code.
<cjwatson> I've confirmed correct behaviour with strace
<cjwatson> the purpose of the function is to search-and-replace an existing file and write a replacement version of it
<cjwatson> it's basically just glorified sed -i
<doko> ScottK: re-uploaded axis, just dropping the dependency
<ScottK> cjwatson: OK.  I'll accept it when it hits the queue.
<ScottK> doko: OK.  I'll reject the first one and then look at that one.
<cjwatson> ScottK: reuploaded.  thanks again for catching that
<ScottK> cjwatson: You're welcome.  The real thanks go to whoever wrote the comment.
 * ScottK would have never thought twice about it otherwise.
<cjwatson> 178.2.12 michael.vogt@ubuntu.com 20100519
<ScottK> Right, well I don't think I've ever seen anything he did that wasn't done well.
<mvo> cjwatson: thanks a lot for this language-selector fix, funny co-incidence, I got bitten by the bug today and you already fixed :)
<doko> cjwatson, slangasek: do the linaro packages need some seeding?
<cjwatson> mvo: heh, well it was mostly due to seeing the merge proposal
<cjwatson> doko: beats me
 * persia would prefer not to see linaro packages seeded, and have the long-delayed discussion about how to represent multiple support entities at UDS
<cjwatson> lamont: can you confirm whether bug 642344 is on your to-do list?
<ubot4> Launchpad bug 642344 in libspring-2.5-java (Ubuntu Maverick) (and 1 other project) "libspring-2.5-java needs an initial manual build (affects: 1) (heat: 3380)" [High,Confirmed] https://launchpad.net/bugs/642344
<doko> cjwatson: one more installer related demotion: libmtdev1-udeb mtdev-tools
<cjwatson> that's ok too
<smoser> i guess i should have brought this up before upload. there is a cloud-utils upload with fixes bug 621473 and bug 646823. they're both trivial fixes, with the dependency being more serious.  diff is at http://paste.ubuntu.com/499759/ diff is
<ubot4> Launchpad bug 621473 in cloud-utils (Ubuntu) "uec-run-instances - passing multiple launchpad ids results in all of them failing (affects: 1) (heat: 116)" [Undecided,New] https://launchpad.net/bugs/621473
<ubot4> Launchpad bug 646823 in cloud-utils (Ubuntu) "uec-run-instances requires paramiko but isn't a depends (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/646823
<ttx> smoser: targeting them to maverick
<ScottK> smoser: Accepted.
<smoser> thank you
<ScottK> You're welcome.
<lamont> cjwatson: interestingly, it's on Ng's todo list
<lamont> cjwatson: rt41455
<lamont> cjwatson: we're testing some documentation while we're at it
<doko> didn't you do this already with fpc? ;p
<slangasek> doko: if you mean in components-mismatches, there's no reason for these u-boot packages to be in the Ubuntu seeds right now AFAICS
<doko> ok
<slangasek> just don't demote u-boot-linaro-omap4-panda, which the ARM team is using :)
<doko> slangasek: and u-boot-linaro-ca9x4-ct-vxp u-boot-linaro-mx51evk u-boot-linaro-omap3-beagle ?
<slangasek> those are used in linaro images, not in official Ubuntu ones; they can all be demoted
<ScottK> slangasek: What would you think about recasting the Linaro release freeze is a period to do ISO builds and testing from the Maverick archive and then make it any flavor or derivative that wants to take advantage of it can use it and uploads should be coordinated with them?
<ScottK> Although I'm not on the SRU team, so I didn't reply to the list, I think to the extent we can make this a generic Ubuntu thing and not special treatment for one derivative, it's a good idea.
<ScottK> I doubt it actually affects what we'll do, but I think it's a better message.
<cjwatson> that does make a certain amount of sense
<cjwatson> a derivative stabilisation period
<slangasek> ScottK: it becomes an n-way coordination problem for the SRU team to figure out what should or shouldn't be let through, so if n ends up being large we would need some better tools; but sure, I think it makes sense to treat it that way
<ScottK> I'm pretty sure n=1 for this cycle, so we can get smarter if it gets bigger.
<slangasek> right :)
<ogra> cjwatson, any idea why the dove and omap4 kernels want to go to universe ? looking at supported-kernel-common in the seeds it seems dove for example was never there but it never wanted to move to universe before either
<cjwatson> no
 * ogra wonders if he should just add both to supported-kernel-common
<cjwatson> look at germinate output and figure it out from there
<ogra> oh, i guess i see the prob
<ogra>  * ${Kernel-Stem}-dove [armel]
<ogra>  * ${Kernel-Stem}-omap [armel]
<ogra>  * ${Kernel-Stem}-omap4 [armel]
<ogra> Kernel-Stem is only linux or linux-image ... but omap4 and dove have linux-ti and linux-mvl
<ogra> (in the boot seed)
<cjwatson> should be ${Kernel-Stem}-mvl-dove etc. then
<ogra> right
<ogra> no
<ogra> actually :)
<ogra> the that wont work with linux-image
<skaet> ScottK, slangasek - any thoughts on where the derivative stabilization period should be documented?   wondering if this is a good topic for UDS, after we go through a cycle?
<ScottK> Unfortunately we won't have gone through a cycle until after UDS.
<skaet> well,  we'll be part way through at least ;)
<slangasek> ogra: eh - why are the binary metapackages not named consistently with the kernel packages!
<cjwatson> ogra: in fact, the original was just fine
<cjwatson> linux-dove | 2.6.32.409.1 |      maverick | armel
<ogra> slangasek, i didnt name them ...
<cjwatson> linux-image-dove | 2.6.32.409.1 |      maverick | armel
<cjwatson> linux-image-2.6.32-410-dove | 2.6.32-410.26 |      maverick | armel
<ScottK> I think we ought to have a release team BOF session at UDS, but I don't think think particular issue needs a full session.
<cjwatson> only the source package is -mvl-dove, and the source package name is entirely irrelevant to germinate
<slangasek> ogra: I guess you'll have to list ${Kernel-Stem}-ti-omap4 and ${Kernel-Stem}-omap4 both to get the desired result
<cjwatson> slangasek: no, he's just got it wrong :)
<skaet> ScottK, including JamieBennett too I think.
<cjwatson> ${Kernel-Stem}-ti-omap4 will have no effect as far as I can see
<cjwatson> the metapackages are linux-omap4 and linux-ti-omap4
<ScottK> skaet: Certainly, although my focus was around the Ubuntu release team, I think having other there is great too.
<slangasek> skaet: I agree with ScottK; we should discuss things more generally
 * ogra is confused, doko pinged me about tehse packages being on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<slangasek> cjwatson: ah, ok
<cjwatson> ogra: somebody needs to update the dove metapackage to the current version, that's all
<skaet> slangasek, ScottK,  cool.
<cjwatson> haven't checked what's happening with omap but I imagine it's similar
<ogra> cjwatson, oh, ok
<ogra> well, omap should be up to date
<ogra> (omap4 that is)
<cjwatson> anyway, please check germinate output etc. rather than guessing.
<chrisccoulson> thanks to whoever approved lightning :)
<slangasek> ogra, cjwatson: platform/installer lists the old ABI version for omap4.
<ogra> but the proper one for dove
<ogra> oh my
 * ogra fixes 
<ogra> not only the old abi version btw
<ScottK> doko: We should have a new drizzle update on Monday that will actually build.  I'd rather not accept this one and then wait for the new one on Monday if you're OK with that?
<doko> ScottK: I don't care, just cleaning up NBS
<ScottK> OK. I'll reject this one and we'll let next week's upload clean it up.
<ScottK> Thanks.
<sistpoty> ScottK: can you send a follow-up mail to u-d-a wrt sugar?
<ScottK> sistpoty: Do you thin it needs it?  I cc'ed lfaraone and I don't think anyone else really needs to care.
<sistpoty> ScottK: I guess it doesn't have mach practical impact, but I think it would be good for the sake of transparency
<ScottK> I can see that, but I think it's a very minor point for a u-d-a mail.
<sistpoty> ok, agreed (and it can be read on ubuntu-release list anyways)
<ScottK> Great.
<ogasawara> skaet: just fyi bug 647071
<ubot4> Launchpad bug 647071 in linux (Ubuntu Maverick) (and 1 other project) "0-day Maverick Kernel Upload (affects: 1) (heat: 10)" [High,Triaged] https://launchpad.net/bugs/647071
<skaet> ogasawara, thanks for the heads's up
<doko> ScottK: 647079 again, ok to sync idzebra?
<ScottK> doko: Yes.
<skaet> ogasawara, looks good.  Only one weird thing from my perspective,  I see you set the milestone to maverick-updates, but its not showing up when I display it.
<skaet> ogasawara, not being picked up in the maverick-updates milstone search...   hmph.   will see what I can do.
<skaet> ogasawara, heh.   yup that worked.   search is picking it up.   all good.  action done ;)
<doko> ScottK: ^^^ needed to build with qalculate version in maverick
<ScottK> doko: OK.
<ScottK> doko: Accepted.
#ubuntu-release 2010-09-25
<ScottK> Down to 50 bugs/bug tasks on the release team list and AFAIK, none of them waiting for release team action.
<ScottK> \o/
<bdrung_> ScottK: by removing bug #645339 from the list ;) (btw, it doesn't require any action from u-release or u-archive any more)
<ubot4> Launchpad bug 645339 in webfav (Ubuntu) (and 18 other projects) "Drop transitional and removed packages from Recommends (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/645339
<ScottK> bdrung_: In part.
<ScottK> I could have left that in and there still wouldn't be any bugs waiting on release team review, which is the important bit.
<bdrung_> ScottK: it's better to not have ubuntu-release subscribed
<ScottK> I agree (unless some specific issue comes up, which I don't expect).
<cjwatson> OMG, I just noticed that checkrdepends doesn't check Pre-Depends
 * cjwatson is rewriting it in Python anyway; probably just as well!
 * doko_ mumbles to make it python3 compatible ...
<cjwatson> doko_: get back to me when there's a python3-apt :-/
<cjwatson> or a python3-debian, come to that
<doko_> cjwatson: I have a patch for that for unstable, but the maverick version is too different ...
<doko_> we'll get these for natty
<wgrant> cjwatson: So you're happy with per-pocket and per-status queue admin perms?
<cjwatson> per-status?
<wgrant> cjwatson: Well, I guess that's not necessary if you want -release to be able to accept from NEW too.
<cjwatson> I'm not sure what you mean by per-status
<wgrant> cjwatson: Well, -release should clearly be able to accept from UNAPPROVED, but it's not clear that they should be able to handle NEW.
<cjwatson> oh, I see
<cjwatson> ideally that would be per-status, yes
<cjwatson> I'd prefer to be able to say clearly that NEW packages all go through ubuntu-archive
<wgrant> Right, that was the plan.
<cjwatson> libdvdread> commented on the associated bug - most of the Recommends should just be removed
<bdrung_> where can i see which package is on which seed?
<ScottK> bdrung_: http://people.canonical.com/~ubuntu-archive/germinate-output/ is probably not exactly what you were looking for, but might be close enough.
<bdrung_> ScottK: is there no tool that maps a package name to a seed list?
<ScottK> There is one that maps it to package set.
<ScottK> Thats edit_acl.py in https://code.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk
<ScottK> That may be close enough.
<ScottK> (depending on your needs)
<iulian> ScottK: Please accept mythbuntu-live-autostart as well.
<ScottK> iulian: I will if you want (I didn't know you were reviewing it), but please see the question I just asked superm1 on #ubuntu-motu.
 * iulian looks.
<iulian> OK.  I will leave it to you then. :)
<ScottK> (that or feel free to tell me what I missed when I was reviewing)
<iulian> ScottK: I think you haven't missed anything.  I just don't see the artwork changes in the diff.
<iulian> So, the question you've just asked was a good one.
<ScottK> OK.  Thanks.
<iulian> s/was/is/
<cjwatson> bdrung_: you can just run germinate locally and slice and dice the output whichever way you like
<cjwatson> libdvdread rejected at uploader's request
<bdrung_> ScottK: does the FFe for gnash applied to 0.8.8-5 too?
<bdrung_> ScottK: http://packages.debian.org/changelogs/pool/main/g/gnash/current/changelog
<ScottK> bdrung_: If the difference between what I approved and this is bugfix, yes.
<bdrung_> ScottK: there's one "new feature": Renamed mozilla-plugin-gnash package to browser-plugin-gnash.
<bdrung_> ScottK: i have tested the upgrade and it works
<ScottK> bdrung_: OK.  Ack for that then.
<ScottK> So the answer is it didn't, but I've now extended it.
<bdrung_> ScottK: thanks. can you state that on bug #636667?
<ubot4> Launchpad bug 636667 in gnash (Ubuntu) "FFe: Sync gnash 0.8.8-5 (universe) from Debian experimental (main) (affects: 1) (heat: 10)" [Wishlist,New] https://launchpad.net/bugs/636667
<ScottK> bdrung_: I'm just leaving.  Please just copy/paste the IRC log into the bug.  That will do.
<bdrung_> ScottK: k, thx
<cjwatson> lp_archive@cocoplum:~$ time cron.NBS
<cjwatson> real    0m55.616s
<cjwatson> the phrase "that's more like it" comes to mind
<cjwatson> (previously scaled linearly with a large constant term according to the number of packages, so could easily take 20 minutes or more - I saw it take upwards of an hour sometimes)
<cjwatson> to anyone using checkrdepends on cocoplum, please note that the suite is now given as an option rather than as a weird second argument
<ScottK> Nice.
<cjwatson> cron.NBS now runs hourly
<cjwatson> (from ~lp_archive/dak/cron.sync, for those following along on cocoplum)
<cjwatson> this rewrite should also make it feasible to check whether kernel udebs are built into the current d-i build, but I haven't got round to that yet
<stgraber> hmm, seems like we have some broken language-packs again
<stgraber> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/edubuntu-dvd/20100925/livecd-20100925-amd64.out
<stgraber> language-pack-kde-an, language-pack-kde-ht, language-pack-kde-sc and language-pack-kde-tk
<stgraber> ArneGoetje: ^
<ScottK> cjwatson: I accepted libdvdread after the recommends were fixed per your comment in the bug.
<cjwatson> ScottK: thanks
<cjwatson> stgraber: I think you want dpm for that nowadays
<stgraber> cjwatson: oh right, old habits ;)
<doko__> cjwatson: all the ruby packages in nbs seem to be false positives
#ubuntu-release 2010-09-26
<doko_> http://people.canonical.com/~ubuntu-archive/NBS/libpetsc3.0.0-dev doesn't work with a rebuild. requires ucf and dolfin syncs from unstable
<doko_> ScottK: ^^^
<ScottK> doko_: Updating ucf at this point seems a little scary.  If we're going to do that, we ought to have a proper FFe think as it touches too many packages.
<micahg> do I need a UiF exception for bug 636014
<ubot4> Launchpad bug 636014 in flashgot (Ubuntu) "xul-ext-flashgot Enhances: thunderbird but synopsis mentions only Firefox (affects: 1) (heat: 234)" [Undecided,New] https://launchpad.net/bugs/636014
<doko_> ScottK: care to take a look at dolfin to work with the ucf in maverick?
<ScottK> doko_: Not particularly (myself).  I don't have an opinon on ucf other than it's too core a package for just an IRC ack by me.  I'd like someone else in the release team like slangasek or cjwatson to consider it.
<micahg> ScottK: did you see my question above?
<ScottK> micahg: I did, but didn't have time to look into it.  If it's just a package description change, then no.
<micahg> ScottK: k, even though it shows in software center
<ScottK> micahg: It only shows if you've selected that package, right?
<micahg> ScottK: yes, AFAIK
<ScottK> Should be fine.
<micahg> ScottK: great, thanks
#ubuntu-release 2011-09-19
<ScottK> cjwatson: I'd ask Daviey.  I haven't been following dovecot stuff.
<pitti> Good morning
<pitti> if anyone is awake, I uploaded glib2.0 2.29.92, as part of GNOME 3.1.92 which is due today. I tested it a bit last night and now, and compared to our git snapshot from Thursday it only fixes a couple of more bugs. We already had the big bug fix backported
<pitti> if we want it in the beta, it would be better to accept it now, as the test suite takes a while on armel
<pitti> but an armel FTBFS doesn't cause arm images to become uninstallable, so it's reasonably safe
<pitti> (the current version FTBFSed as well, need to investigate this)
<pitti> infinity, NCommander: ^ WDYT about the glib update? it's not really critical for b2, but would be good to have the current libs for .92; the apps will follow today, and some might depend on .92
<pitti> +GLIB_NEW_REQUIRED=2.29.2
<pitti> ah, there we go already, just packaging anjuta
<pitti> ignore me, .2 != .92
<infinity> pitti: I'm fine with it.
<infinity> pitti: Accepted.
<pitti> infinity: ok, cheers
<pitti> so http://people.canonical.com/~ubuntu-archive/testing/oneiric_probs.html doesn't look too bad, although the recent nova upload seems to have broken
<pitti> Daviey: ^ is that critical for the server images?
<pitti> rejecting at-spi2-atk, needs fixing; told TheMuso
<sladen> hello all.  could I draw your attention to bug #844049 and bug #841885 ;  one of these reverts the "power-cog" icon in the top-right back to an earlier single item design.  This should not impact screenshots much if it's not covered.  The other change enlarges the percentage coverage for the desktop.svg icons.  This shouldn't impact screenshots significantly either, because it's the same thing, just enlarged
<ubot4> Launchpad bug 844049 in ubuntu-mono (Ubuntu) (and 1 other project) "UIFe: Indicators - Device indicator icon looks like it has an emblem (affects: 2) (heat: 12)" [Undecided,Confirmed] https://launchpad.net/bugs/844049
<ubot4> Launchpad bug 841885 in ubuntu-mono (Ubuntu) (and 1 other project) "UIFe: New show-desktop icon looks too small (affects: 4) (heat: 24)" [Undecided,Confirmed] https://launchpad.net/bugs/841885
<sladen> these are none-code updates and existing svg icons, and should be low impact
<Daviey> pitti: I believe that the nova issue is due to components-mismatch of socat.
<pitti> Daviey: right, that would be it
<Daviey> cjwatson: I do not believe dovecot has undergone any documented testing in oneiric to date, which means that by testing a new upstream version /works/, it's an improvement on the current known status. :)
<Daviey> pitti: blocked on security review btw.
<pitti> sladen: followed up to both bugs
<sladen> pitti: ta
<cjwatson> Daviey: this is dovecot-metadata-plugin rather than dovecot, for clarity
<Daviey> cjwatson: Ah.
<cjwatson> rmadison should be up to date again, thanks to sysadmin (re discussion last night)
<ogra_> cjwatson, could your live-bvuild and seed changes to support usb key builds have had any unexepected sideeffects ? for daily-preinstalled we seem to only get 1.6G big iso images suddenly
<ogra_> i could understand how the format changed to iso, but i definitely dont get why a seed seems to be used that makes us end up with 1.6G content
<cjwatson> ogra_: unexpected side-effects are always possible, but if I were you I would trace the problem step by step rather than trying to guess at a cause
<ogra_> well, i dont see changes in debian-cd/cdimage that could have any influence on live-build's behavior in that regard
<sladen> skaet: can you track bug #840593
<ubot4> Launchpad bug 840593 in indicator-datetime (Ubuntu) (and 1 other project) "Indicator-datetime month/year navigation does not work [regression] (affects: 12) (dups: 4) (heat: 74)" [Undecided,Confirmed] https://launchpad.net/bugs/840593
<ogra_> hmm, so the isos are not on the live builders at least ... but the ext3 images are still 1.5G
 * ogra_ thinks there are two probs 
<jibel> sladen, it is a dupe of bug 807509 which is already tracked
<ubot4> Launchpad bug 807509 in ido (Ubuntu Oneiric) (and 3 other projects) "Cannot click on Calendar to select another day, month or year (affects: 44) (dups: 7) (heat: 248)" [High,Triaged] https://launchpad.net/bugs/807509
<lamont> skaet: when you're around...  would you like freshened oneiric chroot tarballs before or after beta2?
<lamont> I notice that the dist-upgrade time has become significant again
<sladen> jibel: double plus good++
<pitti> lamont: how long does that take? it's fairly quiet right now, so we can do with some partial buildd outage right now
<lamont> pitti: it's no outage at all - it's just uploading new tarballs to launchpad
<pitti> lamont: the "OMGneedthisbuilt" phase usually starts later in the day/tomorrow, at that point faster chroots would certanily be appreciated
<lamont> OTOH, the lp-buildd rollout that's going to happen this morning, that's a rolling outage.
<pitti> lamont: ah, I thought you are asking because you have to take down buildds for that
<lamont> nah - it's just a change, and y'all are near a deadline, so I like to check rather than jfdi
<lamont> the lp-buildd rollout was discussed here friday
<pitti> seems fine to me
<cjwatson> I think you can JFDI at the moment
<lamont> cjwatson: ok.  being vanguard this week so I'll sneak it in after I get done w/ the current triage pass, in all likelihood
<lamont> right.  world on manual for a lp-buildd upgrade then
<Laney> ]
<Laney> ops
<lamont>   linux-powerpc64-smp: Depends: linux-image-powerpc64-smp (= 2.6.35.24.18) but 2.6.35.30.23 is installed
<lamont> not amused
 * ogra_ cries ... i dont seem to be able to find out why we have 1.5G images, the livefs build logs dont install anything unusal, the seeds seem fine but still we have 1.5G images on the livefs builders
<ogra_> i dont get wheer the extra gig comes from
<ogra_> hmm, they are probably not to big at all ... just not compressed
 * ogra_ slaps forehead
<pitti> ogra_: all good then, or is the lack of compression a bug by itself?
<ogra_> the lack of compression is a debian-cd bug, just looking nto it
<pitti> ^ rejecting ltsp as per stgraber's request (broken)
<stgraber> pitti: uploaded another one that should fix everything wrap-and-sort messed up
 * pitti starts working on https://bugs.launchpad.net/~ubuntu-archive, should help to reduce the FTBFS bug list, too
<skaet> good morning
<pitti> hey skaet
<skaet> heya pitti,   all the bits for gnome uploaded?
<pitti> skaet: some, tarballs still being wrapped upstream
<pitti> skaet: we package them as they come in
<skaet> pitti,  fair enough.    What's still left?
<pitti> skaet: evolution-data-server currently being packaged, otherwise most apps didn't get an update yet
<pitti> pretty harmless so far (translation updates and minor bugs), though, except for glib2.0 which got some nice fixes for critical bugs
 * skaet nods
<skaet> from the backscroll,  looks like there are still some concerns on the ARM side.
<stgraber> skaet: Just got the e-mail from the tracker telling me Edubuntu got added. We'll want that new ltsp for beta2 so I won't even bother testing the current builds (I tested yesterday's and they were fine)
<skaet> stgraber,  fair enough,  marking them pending ltsp upload for rebuild.
<stgraber> skaet: thanks
<GrueMaster> skaet: Yea, we're gearing up for another respin.  Issues with the image build/publish scripts have apparently plagued us since Beta 1 (I was doing server testing so didn't notice daily build issues).
<slangasek> anyone here using the nouveau drivers?
<pitti> hey slangasek, how are you
 * slangasek waves to pitti
<pitti> slangasek: ah, still no feedback on nvidia? darn
<pitti> I was hoping we could put that change into b2
<slangasek> yes, I would really like that change in b2
<Laney> I think I am, can maybe test in 4 hours
<slangasek> and if we're not going to get it, I should at least upload the *other* plymouth changes that I have staged, which are needed to have logging working again
<slangasek> (I'd really like plymouth to be debuggable in beta2...)
<infinity> cjwatson: Around?
<cjwatson> yes
<cjwatson> CXXFLAGS += -O9 ... # things that inspire confidence
<infinity> cjwatson: Could use a sanity-check review of 'bzr diff /home/adconrad/debian-cd/' on antimony.
<cjwatson> i.e. "don't gzip things that are already gzipped"?
<infinity> cjwatson: Sanity tested the syntax in /srv/cdimage.ubuntu.com/scratch/ubuntu/daily-preinstalled/debian-cd/armel+ac100/Makefile
<infinity> cjwatson: Yeah.
<cjwatson> lose the second and third @ (the ones inside the if), and put 'set -e; ' before the if
<cjwatson> but otherwise LGTM
<infinity> cjwatson: Oh, fair enough.  I was annoyed already that I did it in shell, until I realised there seems to be no make anywhere in that Makefile.
<cjwatson> oh and I'd use grep -q rather than redirecting
<cjwatson> but nits
<infinity> cjwatson: re-review?
<slangasek> infinity: is giving dpkg an internal copy of dpkg.cfg.d/multiarch still on your radar for this cycle, or should I take a look myself?
<cjwatson> my usual idiom is 'set -e; if ...' or 'set -e; for ...', but that's fine too
<cjwatson> (I don't think it matters in the if cas)
<cjwatson> *case
<infinity> cjwatson: In the if case, set -e would do nothing, so yeah.
<infinity> cjwatson: (Or if it did, I'd be deeply concerned)
<infinity> slangasek: Erk.  If you have the time, please do.  I'm still happy to look at it, though.
<cjwatson> in the for case I'm never quite sure and prefer to avoid the question rather than looking it up :)
<slangasek> infinity: I will try to make the time so we can get it in before beta2... we're still getting bug reports from folks saying nspluginwrapper doesn't work, where the answer is "you didn't read the assigned reading"
<cjwatson> much like the way I only ever change IFS according to a strictly defined idiom I decided was safe after much thought once
<infinity> cjwatson: I try (ish) to fit whatever I see in the target sources.  But debian-cd's "make" (and I use that term loosely) made me throw my hands in the air and just type.
<infinity> It's deceptive.  It starts out looking a lot like a makefile too.
<cjwatson> it's much better upstream nowadays, it's just that the merge is a nightmare
<infinity> I can imagine.
<cjwatson> and obviously breaking cdimage is not high on my list of things to do
<scott-work> infinity: sorry to bother you, are you writing up some information about the live build process?
<infinity> scott-work: Well, the spec is assigned to me.  Currently, there's been little done with it, though.  Perhaps we'll actually figure out what information people want/need and try again soon. :/
<scott-work> infinity: i ask because ubuntu studio would like to move to a live image and shnatsel in particular though this would be extremely helpful
<scott-work> infinity: has the process changed recently?
<scott-work> s/though/thought
<infinity> scott-work: The underlying way we build livefses changed this cycle (from livecd-rootfs to live-build), but otherwise, it's business as usual.
<cjwatson> It hardly matters since the process for derivatives that we build centrally is "ask the CD image team to switch things over and give a good explanation".
<cjwatson> (But we aren't going to do it for Oneiric!)
<infinity> scott-work: The problem with the documentation of it all is that it bounces between either docs that say "1) learn to program 2) grab the code and mangle it" and "Here's a nice list of people to contact about how to get things done".  I suspect we need some happy medium.
<cjwatson> infinity: speaking of live-build, want me to backport the patch for bug 803547?
<ubot4> Launchpad bug 803547 in live-build (Ubuntu Oneiric) (and 2 other projects) "live-build lacks EXT4 support for binary image types (affects: 1) (heat: 10)" [High,Confirmed] https://launchpad.net/bugs/803547
<scott-work> cjwatson: haha, no we aren't planning this for oneiric!  heavens no
<infinity> cjwatson: Oo.  ext4 performs a lot better on flash, AIUI, it might be shiny.  Not sure if switching our images a few weeks before release is sane, but has anyone accused ubuntu-arm of sanity before?
<cjwatson> well, it's a beta-2 milestoned bug which is why I noticed
<cjwatson> if that's not sane, I don't object to you pushing it back and we'll get it in a merge for P
<cjwatson> but one or the other :)
<infinity> cjwatson: Yeah, if you can merge cleanly, I think we'd be all over it.
<cjwatson> mkay
 * cjwatson has a go at that then
<infinity> I *think* we sprinkled enough s/ext3/ext3|ext4 in other tools to make it kinda work if we decide to swap, but I should double-check that.
<scott-work> cjwatson: by "cd image team" i believe you mean the team who is responsible for that derivative, i.e. in this case ubuntu studio?
<infinity> scott-work: I believe he was referring to ~ubuntu-cdimage
<infinity> cjwatson: Oh, hah.  I should probably be re-added to that team, BTW. :P
<infinity> cjwatson: Having my LP membership reflect UNIX permissions might be sane.
<slangasek> hmm
<slangasek> cjwatson: in bug #853738, the submitter says a clean beta1 install did not give him multiarch support
<ubot4> Launchpad bug 853738 in nspluginwrapper (Ubuntu) "nspluginviewer is missing in amd64 (affects: 1) (heat: 6)" [Undecided,Incomplete] https://launchpad.net/bugs/853738
<infinity> slangasek: That's disconcerting.
<slangasek> hence me flagging it :)
<cjwatson> merp
<cjwatson> scott-work: yeah, what infinity said
<infinity> The dpkg conffile would sort of paper over that anyway.  But if the installer really isn't consistently writing the file, that's unpleasant.
<cjwatson> as in the team that actually has power to do something about this
<cjwatson> infinity: oh yes.  Reactivated
<infinity> cjwatson: Danke.
<cjwatson> slangasek: asked for more info
<scott-work> cjwatson, infinity:  hmmm, i believe i'm confused about the process for moving ubuntu studio to a live image, i had viewed this as we needed to do all the leg work on package and seed manipulation based on previously used processes, is this not the case?
<cjwatson> no; somebody would need to prepare appropriate live and ship-live seeds, granted, but the task of actually switching to build a live image falls to ubuntu-cdimage
<cjwatson> infinity: uploaded.  dinnertime now
<scott-work> it sounds like we should do some homework to know what changes we need to make and then perhaps talk to someone wiht ~ubuntu-cdimage
<scott-work> with
<pitti> good night everyone
<infinity> cjwatson: Cheers.
<skaet> pitti, are all the gnome bits that are planned to be uploaded,  done?
<ScottK> Daviey: Would you mind re-uploading backuppc using -v with dpkg-buildpackage so all the relevant changelog entries get into .changes?
<slangasek> cron up there is a bugfix-only change; not at all critical for beta, but wanted for final
<skaet> slangasek, ack
<skaet> infinity, NCommander, daily builds have been disabled now.
<ScottK> skaet: Kubuntu will need to be respun for qtwebkit, quassel, and image sizing.
<infinity> skaet: Kay.  I'm spinning some armel stuff to shake out all the image-building bugs we've had over the last few weeks.
<infinity> skaet: Everything should be shiny once this is done. :P
<Daviey> ScottK: ah, good catch.
<ScottK> :-)
<ScottK> Daviey: I'll reject the current one.
<Daviey> ta
<skaet> infinity,  ack,  did ogra_ 's fix to debian-cd get resolved or is that still pending?
<infinity> skaet: I fixed up debian-cd and cdimage, we should be good.
<skaet> infinity, coolio.
<slangasek> skaet: where do we sit on candidate images?  I have verification that turning on flicker-free for lightdm passes smoke testing, so I'd really like this plymouth upload in for beta2 so we get further testing of that, as well as fixes for logging support
<skaet> slangasek,  we haven't started spinning the candidates yet.   Smoke testing only until now.
<skaet> If the fixes are ready,  ok to upload and we'll pull them in.
<slangasek> ack
<slangasek> plymouth uploaded
<ScottK> Daviey: There's a lot to review for backuppc.  Given there's a security fix in there, I'm inclined to just push it in.  Has anyone on server team tested this package?
<ScottK> Actually it's not so bad.
<pitti> skaet: the main one we are still waiting for is gnome-control-center; the bulk is in, though
<slangasek> pitti: care to review plymouth?
<infinity> I can look.
<pitti> slangasek: looks fine, accepted
<infinity> I love it when the changelog is more verbose than the changes.
<pitti> live-build accepted, too
<pitti> wow @ five-digit bug (in cron)
<infinity> skaet: Verified that my debian-cd/cdimage fixes DTRT, removing point [5] from the etherpad.
<pitti> slangasek: ^ do you think the cron update is important for b2? or was that just queueing up the fix?
<pitti> slangasek: ah, you said in backscroll, nevermind
<slangasek> pitti: not important for b2, just queuing; but if there's a window, we might as well take it now
<slangasek> IMHO
<slangasek> (very low risk)
<infinity> (famous last words)
<skaet> pitti,  so,  ok to start rebuilds from your perspective.
<skaet> ?
<Daviey> ScottK: Allison is the unoffical lover of that package.
<pitti> skaet: not yet, some stuff is still building/publishing
<infinity> skaet: Waiting on plymouth, at least.
<skaet> pitti,  http://pad.ubuntu-uk.org/ubuntu-release
<Daviey> ScottK: If it does blow up, she will glue it back together, i'm sure.
 * pitti asks rodrigo about control-center
<skaet> infinity,  ack. :)   just trying to find out if the gnome stuff [2] is satisfied,  which sounds like not.
<pitti> skaet: e-d-s done, pad updated
<skaet> pitti, thanks
<skaet> Daviey - so you want spins without socat?
<infinity> ev: Thanks for the f-k catch.
<infinity> I guess we'll need a d-i rebuild to pick that up for omap netinst. :/
<pitti> skaet: we just got another bunch from GNOME, working on them now
<skaet> pitti,  thanks!
<pitti> skaet: is it super-urgent yet that we have to do the "cut off point"?
<slangasek> pitti, seb128: have pushed fixes to the upstart jobs for gdm and lightdm to bzr; I haven't heard any reports that can conclusively be linked to this, but a change early in oneiric reverted pitti's fix for bug #615549 from maverick without explanation
<ubot4> Launchpad bug 615549 in kdebase-workspace (Ubuntu Maverick) (and 5 other projects) "gdm/kdm starting too early for DRM modules to load, no video (affects: 66) (dups: 10) (heat: 131)" [High,Fix released] https://launchpad.net/bugs/615549
<slangasek> pitti, seb128: since I don't know of any bug reports related to this, it's hard to evaluate the risk of taking this change - but it does seem to be an accidental change that may cause regressions vs. natty, so I'm inclined to say we should have this in for release
<seb128> slangasek, no objection from me to get it in
<slangasek> seb128: have you seen any bug reports that look like they might be related to this (i.e., a resurgence of 615549)?
<seb128> not that I can remember no
<pitti> these look just fine to me
<ev> infinity: don't thank me, thank ubiquity's shell syntax checking on build
<skaet> pitti,  re: cut off point.  Yes,  we're running out of time to recover from accidental regressions, so need to start getting the formal candidates built.
<cjwatson> infinity: we'll need one anyway - stgraber stpotted an IPv6 problem in netcfg
<cjwatson> wretched executable bits
<slangasek> plymouth's kernel commandline handling makes baby Jesus cry
<slangasek> also me
<NCommander> skaet: thanks
<jibel> I've been pinged by a lubuntu tester, there is no image available in http://cdimage.ubuntu.com/lubuntu/daily-live/20110919/ but images are on the tracker.
<cjwatson> jibel: have you checkd the build logs?
<pitti> reading the ubiquity diff doesn't tell me much, but I guess we want that
 * ScottK thinks we do.
<jibel> cjwatson, the following error appears in cd-build-logs
<jibel> make: *** [apt-update] Error 100
<jibel> ERROR WHILE BUILDING OFFICIAL IMAGES !!
<jibel> in http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/oneiric/daily-live-20110919.log
<cjwatson> transient then.  I'll kick a rebuild
<jibel> ok thanks
<slangasek> anything I can help reviewing right now?
<Daviey> skaet: It really doesn't matter either way, the nova issue is server-ship only.
<pitti> skaet, infinity: I updated the [2] condition in the pad for the packages we are waiting for (currently being worked on by seb128 and rodrigo)
<bdrung> what's the status of bug #851659?
<ubot4> Launchpad bug 851659 in jenkins (Ubuntu) (and 4 other projects) "[FFE] Sync asm3 3.3.2-1 (universe) from Debian unstable (main) (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/851659
<skaet> thanks pitti
<SpamapS> Any respins happening for server stuff after 20110919 ? About to start testing the iso's..
<ScottK> Think so.
<SpamapS> so hold off? :-/
<ScottK> Testing is always good.
<SpamapS> that RAID1 test takes 45 minutes because of all the reboots and re-syncs .. I only want to do it 2 more times (this one and RC) ;)
<Daviey> SpamapS: We have nothing urgent requring a respin?
<stgraber> there'll be a new netcfg to fix ipv6
<pitti> infinity, skaet: nautilus uploaded, that was the last one we care about which we can get
<pitti> the others will trickle in tomorrow (but are not that visible in the desktop), and control-center is blocked
<pitti> I updated the pad with the version to wait for (building, publishing)
<skaet> thanks for the update pitti.
<pitti> I'd like to hit the sack now, anything else you need from me?
<skaet> pitti,  nothing comes to mind,  sleep weel.
<infinity> pitti: Go sleep.
<skaet> well even
<pitti> so, good night!
<skaet> :)
<jibel> lubuntu desktop 20110919.1 posted to the tracker
<infinity> slangasek: Want to give a quick sanity review to that jasper upload?
<infinity> slangasek: http://paste.ubuntu.com/693316/ for the diff.
<skaet> thanks jibel
<infinity> slangasek: Or just accept it blind, because I'm oh so pretty.
<infinity> slangasek: I'm game for either.
<cjwatson> the combination of netcfg and isc-dhcp I'm uploading now has been tested in a whole bunch of IPv4/IPv6 combinations by stgraber
<cjwatson> it'll need a debian-installer upload after
<slangasek> infinity: looks sane to me, accepting
<cjwatson> I'd've used blkid instead these days, but meh
<cjwatson> less likely to be removed in future
<infinity> cjwatson: fstype is used all over initramfs-tools anyway.  If and when that changes, jasper can too (or, maybe it'll be gone by then anyway... A man can dream)
<cjwatson> initramfs-tools uses fstype in three places and blkid -s TYPE in four
<infinity> I was going with the claim in comments that fstype was somehow "more robust" or some such.
<infinity> And it works for this use-case.
<cjwatson> yeah, it's fine for now
<infinity> But I'm happy to switch it out.
<cjwatson> nah, leave it if you've tested it
 * infinity nods.
<cjwatson> just a comment for the future
<infinity> I didn't mean I'd switch it out before the next publisher run.  Just "sometime".
<cjwatson> I think blkid used to suck more than it does now
<cjwatson> slangasek: multiarch> oh bugger
<cjwatson> guess what apt-setup-udeb's Architecture line is
<cjwatson> I suppose I'd better make that Arch any
<infinity> Oh, d'oh.  It was building on i386 and skipping some amd64 special-casing?
<cjwatson> yup
<infinity> I guess that somehow beats the opposite, where every arch would now have i386 as a foreign arch. :P
<seb128> ^ would be nice to still get that gnome-control-center in if we can, I think pitti is off for the night so if anyone wants to ack it
<seb128> then we are done for desktop updates
<infinity> seb128: Done.
<seb128> infinity, thanks
<infinity> cjwatson: Accepted.
<infinity> Oh look, canonical-kernel-team/ppa is eating the buildds again. :/
<micahg> skaet: I won't be able to get chromium in until late tonight, so I'd say not to hold up for it, but pick it up if there's a respin
<skaet> micahg,  gotcha,  thanks for the clarification.
<ScottK> Anyone looking into the ubiquity FTBFS?
<slangasek> cjwatson: heh, doh
<infinity> Ugh, indicator SOVER bump?
<infinity> Or something?
<infinity> If no one's fixing ubiquity already, I can.  Looks like a missing build-dep.
<ScottK> Yes.  Please.
<ScottK> You might check in #ubuntu-installer first to make sure though.
<slangasek> skaet: I've targeted bug #779382 to beta-2; it prevents users who use a 2d Ubuntu desktop and who have opted in to an update-notifier option that figured prominently in the Lucid release notes from receiving any further notifications on their desktop about package updatse
<ubot4> Launchpad bug 779382 in update-notifier (Ubuntu Oneiric) (and 8 other projects) "update-notifier not visible under unity (affects: 13) (dups: 2) (heat: 68)" [Medium,Confirmed] https://launchpad.net/bugs/779382
<slangasek> skaet: since this is a behavior change between beta-1 and beta-2 (nominally a bugfix in unity-2d to bring its behavior in line with unity-3d), I think it's critical that we get this fixed in the archive for beta-2 so that anyone upgrading to beta-2 doesn't get stuck there
<skaet> slangasek,  understood.   should it be medium priority then?
<slangasek> skaet: that's the bug bot being arbitrary - the task on unity is marked 'Critical' :)
<skaet> slangasek,  ok,  that makes more sense. :)
<infinity> Testing the build-dep fix for ubiquity locally.  If this passes, I'll upload.
<skaet> infinity,  thanks.
<infinity> Looks like ev already fixed it in bzr and forgot to upload. :P
<infinity> So, I'll just upload his (identical) fix, if this passes.
 * infinity taps his foot while the build grinds.
<infinity> Maybe I should eat something while this is going on.
<infinity> Oh, well, that's pleasant.  Fixing the build-dep issue just leads to the testsuite failing later.
<infinity> That might be why ev hasn't uploaded yet. :P
 * ScottK wonders why the failing one got uploaded.
<Daviey> Please can someone review dnsmasq, introduces a new binary package.
<Daviey> I uploaded it.
<Daviey> (the dnsmasq is blocking another bug.)
<cjwatson> argh, should've tested apt-setup building with -B
<infinity> cjwatson: lacking a binary-arch target? :/
<cjwatson> well, similar, it's a bit different with dh(1)
<infinity> Initiating build ca0a9b23ee55ba8966f57b9c3e65bcf9c423c28f with 0 processor cores.
<infinity> That seems oddly appropriate for an ARM system.
<slangasek> Daviey: +ifeq ($(DEB_BUILD_ARCH_OS),linux) - technically wrong :)  should be DEB_HOST_ARCH_OS...
<Daviey> slangasek: Ah! Well spotted, Stolen directly from the Debian package, is it worth changing that cherrypick for something which seems to provide the same end result?
<cjwatson> only if you were planning on cross-building the package using a kfreebsd system
<slangasek> Daviey: nah, it makes no difference at all for us, it only matters for those who are cross-building from Linux to non-Linux ports (of which the latter, we have none :)
<cjwatson> or vice versa, yes
<infinity> Daviey: You might want to inform the Debian maintainer that it's wrong.  For us, it probably doesn't matter.
<Daviey> The best part is, we don't really care about !linux arch :)
<slangasek> right, what infinity said
<cjwatson> it's good to be in the habit of remembering the build/host distinction though
 * Daviey adds it to his todo to raise a Debian bug tomorrow.
<slangasek> dnsmasq debian/rules makes me sad
<slangasek> Daviey: why does dnsmasq-utils Conflicts: dnsmasq (<<2.40)?
<slangasek> +Requires dnsmasq 2.40 or later and may not work with other DHCP servers.
<slangasek> maybe that's why.  But then shouldn't it be a depends?
<cjwatson> or at least Breaks
<sladen> hello all.  Based on conversations with Mark I've filed  https://bugs.launchpad.net/ubuntu-font-family/+bug/854264  I haven't subscribed ubuntu-release as there is nothing to actually review yet
<ubot4> Launchpad bug 854264 in ubuntu-font-family "UVFe & FFe: New upstream version of Ubuntu Font Family ~0.80 (affects: 1) (heat: 6)" [Undecided,New]
<infinity> slangasek: "may not work with"... I guess they think it could possibly, if you will it to?
<slangasek> hey, anything's possible :)
<slangasek> sladen: is adding new font files the main difference for this new upstream version?  Is there an estimated disk space impact for these new files?
<slangasek> if they're not going to be enabled in the default experience, we should presumably not break our backs making room for them on the CD...
<sladen> slangasek: my estimate is 900 kB compressed.  Obviously if CD space is that tight(tm) it would have an impact on viability of the request, which I could then convey back up the chain
<slangasek> space is always that tight :)
<sladen> slangasek: I also haven't uploaded the community wallpapers yet, so there's always the option of trading 3-4 of those for the space
<sladen> slangasek: which is horse-trading that could be done internally within the Product Stategy Dept.
<cjwatson> sladen: I'm going to start recommending rather soon that anyone asking for more CD space figure out what should be removed to make room
<infinity> We can just remove English.
<cjwatson> sladen: so if you could figure out a trade-off, that would be good
<cjwatson> infinity: -.-- --- ..- / ..-. .. .-. ... -
<cjwatson> sladen: right now, any "free" space you see is essentially by luck
<infinity> I don't speak morse, but I'm going to assume that was rude and assure you that I'm currently flipping off my monitor.
<sladen> cjwatson: yeah, can do, but wouldn't want to accidently volunteer up that space prematurely such that it gets vacuumed by other stuff ;-)
<cjwatson> well, it's not like it's super-strictly audited, but sure
<cjwatson> could somebody review netcfg and isc-dhcp, please?
<Daviey> slangasek: Yeah, not quite sure.. I wondered if 2.40 provided the binary or something.. either way, didn't seem to be an issue for us.
<Daviey> slangasek: it is on my todo to poke that.
<infinity> netcfg looks sane...
<Daviey> slangasek: you'll also notice i included the manpages without patching, or putting them in debian/ .. I didn't want to introduce a patch system, and also wanted to keep it as similar to the debian package as possible
<Daviey> (new upstream version ships the manpages)
<Daviey> <-- keeping life simple for future merge/sync.
<infinity> cjwatson: Does that "keep old nameservers" logic exist in netcfg for v4 as well?
<infinity> cjwatson: (I notice you added it for v4 and v6 to isc-dhcp, but only v6 in netcfg..)
<Daviey> who uses v4 these days? :)
<infinity> Everyone?
<cjwatson> infinity: isc-dhcp's dhclient-script deals with that bit
<cjwatson> we only need to deal with it for v6 in netcfg because we override the dhclient-script in the v6 case
<slangasek> Daviey: given that versioned conflicts are a major source of upgrade problems, I would prefer to see that turned into a Depends: instead before I accept it
<infinity> cjwatson: Ah-ha.  Then both look reasonable to me.
<Daviey> slangasek: if people are upgrading from prior to hardy to oneiric directly, they deserve pain.
<cjwatson> infinity: thanks
<slangasek> Daviey: oh, I hadn't noticed that 2.40 was that old. ack, accepting then - that just goes in the bucket of "issues that should be flagged to the Debian maintainer"
<Daviey> slangasek: along with buring debian/rules
<Daviey> Thanks!
<Daviey> \o/
<slangasek> er, though now that I look more closely I'm not sure if I should actually accept the binaries out of new before beta-2
<slangasek> since dnsmasq-base is a recommends: of network-manager
<Daviey> slangasek: well, i wanted it on beta2 - due to the new upload of nova we are planning tommorow.
<slangasek> (which seems dubious to me, but there it is; the package impacts the desktop CDs)
<Daviey> well it's essentially a no-change rebuild for the desktop, right?
<slangasek> skaet: ^^ are we in a window where dnsmasq can be accepted for beta-2, which requires a rebuild of the desktop?  server team is rather keen to have this new package in for beta-2
<infinity> Desktop still needs rebuilds anyway.
<Daviey> so if desktop don't respin before then, it's ok - if they do - it should be no-change.
<slangasek> infinity: ah. what's the trigger for those?
<skaet> slangasek, opportunistic at this point.   waiting for d-i update from cjwatson before the rebuilds start.
<infinity> slangasek: Right now, I'd say the LCD is ubiquity building.
<infinity> (And d-i for alternates)
<infinity> So, y'know.  Installers.  No big whoop.
<infinity> Who needs those?
<skaet> :P
<slangasek> ah, ubiquity not fixed yet? ok
<infinity> Colin's abusing it.
 * slangasek nods
<infinity> Because Irish people don't sleep.
<infinity> Or maybe that's Cambridge grads.
<Laney> I had another stab at libproxy and it works now. Needs some fixes still (what to do with the external modules? separate binary packages?); further eyes appreciated git://anonscm.debian.org/users/laney/libproxy.git
<infinity> So, I suspect we can replace all our triggers in the Pad with just two "ubiquity and debian-installer", and if people can get minor fixes in before those big two land, fine. :P
<infinity> What I won't say out loud is that, while I'm waiting on those to filter through, I'm toying with changing the default FS on the ARM images.
<infinity> *cough*
<cjwatson> Cambridge certainly did bad things to my sleep cycle
<cjwatson> I've got the ubiquity tests passing; what I need to check now is whether my changes to upower integration still actually work
 * skaet notes remark about default FS... sighs heavily. 
<Daviey> infinity: Changing it to? And on the arm server deliverables aswell?
<infinity> Daviey: ext4, and across the board.  It's a more tested codepath these days.  Assuming the installers DTRT, which we're smoketesting right now.
<infinity> If they don't, I can roll it back in a matter of seconds.  No archive turnaround.
<Daviey> infinity: I'm sure it won't make IO speed on the pandaboards any worse..  what could?
<infinity> *smirk*
<Daviey> I believe the unsupported arm cloud images deliverable is already ext4 btw.
<infinity> cjwatson: I assume we have no urge to change the wubi target to ext4?
<Daviey> bug 854189 probably needs release noting.. macbooks are not playing well with the default of using EFI, requires manual steps to use legacy BIOS mode.
<ubot4> Launchpad bug 854189 in xorg (Ubuntu) "nvidia binary driver gives black screen (affects: 1) (heat: 6)" [Undecided,Invalid] https://launchpad.net/bugs/854189
<cjwatson> infinity: strong urge to leave wubi alone
 * infinity nods.
<cjwatson> I'm pretty sure I have a fix for bug 774089.  What do people think?
<ubot4> Launchpad bug 774089 in grub2 (Ubuntu) (and 2 other projects) "Booting fails 3 times, works every fourth time after new install of Natty Narwhal amd64 on Macbook Pro (affects: 22) (heat: 137)" [Undecided,Confirmed] https://launchpad.net/bugs/774089
<infinity> Works every... Fourth time?
<cjwatson> symptoms vary
<cjwatson> some people have reported bricking
<cjwatson> although we released natty with it because there seemed little alternative at the time
<infinity> No, the reason this fascinates me is that my netbook has a similar issue.
<cjwatson> the fix is to install in BIOS mode
<cjwatson> which wasn't happening because we were failing to detect that these were Macs when they were booted in EFI mode
<cjwatson> if your netbook is broken-EFI then I suppose it's possible it's related
<infinity> It really isn't. :P
<Daviey> cjwatson: dmidecode doesn't work under EFI?
<infinity> I'm sure it's not related.  Just curious.
<cjwatson> Daviey: we embed a cut-down copy of dmidecode for space reasons
<cjwatson> ... from before mjg59 fixed it to handle EFI
<cjwatson>  * I (Colin Watson) copied this in reduced form rather than using dmidecode
<cjwatson>  * directly because the d-i initrd is tight on space and this is much
<cjwatson>  * smaller (1.8KB versus 46KB, at the time of writing).
<Daviey> Do we still spin a amd64+mac iso? I'm on an X-less system atm.
<cjwatson> yes.
<cjwatson> because there's a sizeable subset of Macs where the amd64 image simply does not boot at all.
<cjwatson> but not all of them apparently.
<Daviey> If that is the SATA issue, i thought i fixed that?
<Daviey> (now in mainline kernel)
<cjwatson> no, it isn't.
<Daviey> ah
<cjwatson> it's a failure in their EFI implementation
<Daviey> cjwatson: whilst i hate special casing hardware like this, would shipping the bloated dmideocode (not worring about oversizing) be a suitable fix?
<Daviey> Perhaps i don't fully grasp the issue.
<cjwatson> I already have a fix
<Daviey> i'll shuddup.
<cjwatson> I appreciate the concern about code duplication, and will concede that I've just exposed the obvious failing in it, but I still think it's worthwhile to keep the size down
#ubuntu-release 2011-09-20
<infinity> slangasek: Since we're still in a "need to rebuild the world" state anyway, I'm going to leak your cron change through.
<slangasek> infinity: ok
<cjwatson> that said, I believe this is going to require at least a fix to grub-installer, so I'm going to hold off on 774089 for beta-2 and try to fix it for final
<cjwatson> just going to run ubiquity through pbuilder before uploading
<cjwatson> will be able to upload d-i after this publisher run finishes
<skaet> cjwatson,  goodness.  :)
 * skaet goes to grab some dinner,  biab
<cjwatson> seriously tired.  going for temporary caffeine boost
<Daviey> cjwatson: The other fix for that is bed.  Maybe ask freenode to k-line you, during silly-hours.. bit like gamblers stop-limits.
<infinity> ^
<cjwatson> I fully intend to go to bed but I don't have a lot of option except to finish this, otherwise the whole image build pipeline is delayed
<cjwatson> since nobody else was around who knew how to fix ubiquity and it had been left broken
<Daviey> :(
<infinity> One of these days, everything EXCEPT the installer will be broken.
<infinity> And Colin will point and laugh.
<infinity> Just wait.
<cjwatson> I look forward to it
<Daviey> sensible people will join in the laughter.
<Daviey> whereas platform will be pulling their hair out.
<cjwatson> err, hold off a moment on accepting d-i (uploaded).  The publisher still seems to be running, rather later
<cjwatson> than usual
<infinity> Argh.  Stupid thinko.
<cjwatson> ?
<infinity> cjwatson: Well, you get your wish, I had to fix jasper, so I'm switching to blkid. :P
<ScottK> sladen: It's more than just the Ubuntu images that are affected by the font package getting bigger.
<cjwatson> heh
<infinity> cjwatson: http://paste.ubuntu.com/693424/ <-- Sane?
<infinity> cjwatson: Err, ignore the typo in the changelog.
<infinity> s/full/full path/
<cjwatson> looks fine, but don't trust my judgement at this point
<infinity> Fixed locally. :P
<cjwatson> The publisher's finished now, so debian-installer is safe to accept
<cjwatson> Dunno what took it so long.
<infinity> cjwatson: Well, I'm mostly looking for "hey, you have obvious quoting fail" or sometihng, if I break the logic, that's my own fault.
<cjwatson> well I'd probably do "/dev/${ROOTPART}" out of paranoia, but I can't imagine how a device node could realistically end up with a space in it
<cjwatson> also looks like the versioning scheme for that package should be 0.60 not 0.59ubuntu1 </nitpick>
<infinity> Oh, yeah.  Local env issue.  Changelog fixed.
<cjwatson> and ubiquity uploaded
<infinity> And I'll anallify the quoting.
<infinity> Makes vim's highlighting happier anyway.
 * infinity glares at duplicity for breaking his dupload tab-completion.
<slangasek> d-i accepted
<infinity> Dangit, I'll be a cycle late for jasper.
<infinity> Oh well.  I had no plans tonight.
<slangasek> do you want me to hold the publisher?
<slangasek> that sounds like a yes
<infinity> slangasek: if you want to do a manual run, sure.
<infinity> cjwatson: ubiquity still going through local testing?
<infinity> Oh, no, you said it was uploaded.
<infinity> I can't read.
<infinity> And there it is.
<infinity> slangasek: May as well hold the publisher until both ubiquity and jasper build, I guess, then we can get on with images.
<slangasek> infinity: yep. are you reviewing/accepting ubiquity?
<infinity> I'm tempted to accept it blind, but I think I'll wait for a diff to look for obvious oopses.
<infinity> Oh look, a diff.
<infinity> That level of copy and pasting can't possibly be wrong!
 * infinity accepts.
<infinity> And I'll accept my own jasper upload, based on cjwatson's review.
<cjwatson> It can't have taken four goes to get it right, then. :-)
 * cjwatson edits reality
<cjwatson> jasper> yeah, ack from me
<infinity> cjwatson: When you get tired, you suffer deja vu more frequently.  You only fixed it once.
<slangasek> infinity: poke me if you notice things are ready to publish before I do?  I'm intermittently aware of my surroundings (scrambling to get out the door, here)
<infinity> slangasek: Sure.  I can drive the publisher, if you're on your way out.
<infinity> Vroom, vroom.
<infinity> I'm an excellent publisher.  Dad lets me publish in the driveway.
<slangasek> infinity: ah, I'll gladly turn it over to you then
<slangasek> doing some more reboot testing instead, in that case
<infinity> Oh dear.  I've just gone full Rainman mode over here.  I just said (yes, out loud), "Uh oh, packages on the highway!"
 * cjwatson sends infinity to fly Qantas
<cjwatson> Right, crashing.  Don't expect me around too early tomorrow.
<infinity> G'night. :)
<Daviey>  /win 22
 * infinity goes to find some food, back in an hour.
<ScottK> http://people.canonical.com/~ubuntu-archive/testing/oneiric_probs.html seems a tad optimistic (empty).
<ScottK> I know there's at least one problem I haven't fixed yet.
<ScottK> ^^^ That one.
<ScottK> Not beta2 critical (fixes armel installabliity for kalzium-dev), but since we haven't rolled dvds yet, it might be nice if someone could review.
<charlie-tca> maybe I marked this one too low? bug 854198
<ubot4> Launchpad bug 854198 in ubiquity (Ubuntu) "Cannot change keymap language again after double clicking on a language (affects: 1) (heat: 8)" [Medium,Triaged] https://launchpad.net/bugs/854198
<infinity> charlie-tca: Curious bug, but probably not a beta blocker.
<infinity> Release blocker, likely.
<infinity> Hey neat, I'm finally about to get powerpc buildd time.
<infinity> ScottK: Accepted.
<ScottK> Thanks.
<skaet> ubiquity i386 published, but amd64+armel still pending.... drat.
<infinity> skaet: I'm waiting on ppc to build, and then publishing the lot.
<charlie-tca> Well, I tried...
<infinity> skaet: I' happy to turn the crank on a new set of images tonight before I go to bed.
<skaet> infinity, fair 'nuf.   have at it.
<skaet> :)
<infinity> skaet: Or we can make pitti do it when he wakes up. ;)
<skaet> infinity,  heh,  I suspect he and NCommander will need to publish them.  :)
<infinity> Well, they publish themselves.  But post to the tracker and such, yeah.
<skaet> point to infinity,  yes, post to tracker.
<skaet> infinity, any images you're aware of that I shouldn't mark as rebuilding?
<infinity> I intend to just rebuild the world.  People who think they don't want rebuilds are, at this point, wrong.
<infinity> Given that we've touched every installer we ship. :P
<skaet> was wondering that core might not need it, but *shrug*
<skaet> all marked for rebuilding now.
<infinity> server and edubuntu might want Yet Another Rebuild later, when they sort out their other bits, but building now to smoketest won't kill anyonw.
<infinity> Nor anyone.
<skaet> yuppers.
<infinity> Oh, I could skip core.  But it takes about 3 minutes to build.
<infinity> So, meh.
<infinity> I intend to copy-and-paste lazily.
<infinity> ScottK: Are you happy with everything under point [6] at http://pad.ubuntu-uk.org/ubuntu-release?
<skaet> okie.   update the pad when you start,  and details of what's left when you call it a night.
 * skaet figures probably time to call it a night...   
<infinity> Wuss. ;)
<infinity> (G'night)
<skaet> :)  yup.
<skaet> g'night.
<slangasek> infinity: publisher is still down; did everything get published that we were waiting for, and should I unblock the publisher again?
<micahg> is someone fixing gnome-control-center?
 * slangasek assumes so and re-enables the cronjob
<infinity> slangasek: I'm hand-cranking it in 2 or 3 minutes.
<infinity> slangasek: And then going back on auto.
<slangasek> ah, ok
 * slangasek disables again :)
<slangasek> and afk again for about 45min
<infinity> Although, the cronjob is close enough to "in a few minutes". :P
<slangasek> pff, how do we go all cycle with no one filing bugs about the dots-over-text bug *until* I diagnose the issue, open a bug report and start working on a fix and *then* the duplicate bugs come in
<infinity> Quantum entanglement?
<infinity> Publisher crontab back on, it more or less lines up with when I wanted it anyway.
<pitti> Good morning
<infinity> Morning, Martin.
<infinity> I was going to start a respin of literally everything (except ubuntu-core, I just did that) when the next publisher run is done.
<infinity> But then I was going to bed. :P
<infinity> So, if you'd like to do that instead, so you can babysit it...
<pitti> infinity: sure, can do; so everything except core, check
<pitti> infinity: any particular package version I should check for?
<infinity> Going to use the evil wait-on-package script?
<infinity> Let me find something from this run. :)
<infinity> Short memory is short.
<pitti> infinity: not necessarily
<pitti> infinity: just making sure that I don't trigger too early
<infinity> Heh.  kalzium on all arches should be a good enough indicator.
<pitti> I had cases where the package I was waiting on appeared a whole hour after I expected it
<infinity> Or ubiquity.
<pitti> infinity: roger; ubuntu images certainly don't block on that one, though?
<infinity> See above. ;)
<pitti> ah, that's a good one
<infinity> Pretty much everything's blocking on something until this run's over.
<infinity> (Except core, since it has no installer and no... packages)
<pitti> infinity: alright, will do; so sleep well!
<infinity> I doubt I'll be sleeping just yet. :)
<infinity> But at least I don't have to babysit the World's Nastiest Shell Loop.
<infinity> So, I call this a win.
<infinity> Assuming you execute the blocks of doom from the Pad (minus core), I guess server-preinstalled will be up first.  I might stay up long enough to test that.
<infinity> Since I did a bad, bad thing, and changed the preinstalled default filesystem during a freeze.
<infinity> *cough*
<pitti> yes, the pipelines were hard enough to put together, I don't reinvent it every time :)
<ScottK> infinity: Looking
<infinity> Oh, sweet.  I pilot on Wednesday.
<infinity> "Your patch is awesome, but we're in a hard freeze for beta, muahahaha."
<infinity> ^-- Practice.
<micahg> infinity: 1/3 of the current queue is unseeded, so plenty to do :)
<micahg> and 19 SRU requests (might be some overlap)
<ScottK> infinity: It's fine.
<infinity> ScottK: [6] is all happy?  Yay.
<infinity> Well, except potential size issues.  But you can revisit that.
<ScottK> infinity: Won't know about if the seed changes work until after the rebuild, but yeah.
<ScottK> Yep.
<infinity> Kay. Well, if you don't feel like reading backscroll, we're respinning the world as soon as this publisher run's over.
<infinity> So, you'll have shiny things to be annoyed by in the morning.
<ScottK> infinity: There's edubuntu and ubuntu-studio still in queue to build for powerpc, on the off chance we care.
<ScottK> https://launchpad.net/ubuntu/oneiric/+builds?build_text=buntu&build_state=pending&arch_tag=all
 * stgraber wonders why edubuntu-fonts is arch any and not arch all...
<pitti> darn, gnome-control-center was FTBFS on !i386 due to arch desync
 * pitti gives back
<pitti> I'll build kubuntu first, so that it has some time
<stgraber> ok, edubuntu-fonts is just a meta package... I'll poke highvoltage to get that fixed in 12.04, that source package should be dropped and edubuntu-fonts generated from our seeds and edubuntu-meta
<stgraber> anyway, no point in uploading a new arch all package just now but will need fixing
<pitti> infinity: would it be okay for you if I upload colord to add the missing liblcms2-dev dependency to libcolord-dev? this causes FTBFS
<pitti> infinity: if we want to spin images now, we have to live with control-center being out of date, but it's not the end of the world; I'd just like to avoid further FTBFSes due to that
<infinity> pitti: Go ahead.  And there's no massive rush on respinning, should just happen on your watch, so we all have stuff to test "soon".
<pitti> infinity: right; I'll try to shuffle the queue to start with kubuntu etc.
<pitti> ^ single targetted patch, fixes regression in .92
<pitti> NCommander: you apparently still have a backgrounded nano process on antimony on an index.html from August 4; can you please kill this?
<pitti> ubiquity is published, kalzium still behind
<ScottK> kalzium only affects the Kubuntu dvd.
<pitti> ah, ok; starting with server and kubuntu desktop then
<ScottK> It affects edubuntu too, FYI.
<pitti> *nod*
<pitti> eh, seems cron.daily is broken, it returns immediately without any error message
<slangasek> well, it helpfully sent errors in email
<pitti> ah, there
<pitti> ok, that's better
<pitti> http://cdimage.ubuntu.com/kubuntu/daily/20110920.6/ posted
<pitti> ScottK: ^ FYI
<ScottK> Thanks.
<pitti> http://cdimage.ubuntu.com/ubuntu-server/daily/20110920.2/ posted
<pitti> *mumble* publisher taking over an hour these days *whine*
<infinity> Yeah, it's gotten ridiculous. :/
<pitti> is that because process-death-row has been running for two days now?
<pitti> (eating IO, or what not)
<infinity> Wait, is it still running?
<infinity> That sounds ungood.
<infinity> LP people might want to know about that.
 * pitti starts some more builds, kalzium published
<slangasek> hmm, I was going to ask whether the publisher is actually that slow or if contents-generation just overran, but contents-generation has been failing since Sep 11
<pitti> ok, livefs builds fail, too
 * pitti pokes for logs
<pitti> "E: Invalid Release Signature (key id 40976EAF437D05B5)"
<pitti> WTF?
<infinity> Mirrors need a re-trigger, or the publisher did Something Bad?
<pitti> lamont, infinity: ^ do you happen to know if anything changed there since yesterday? it fails right away in debootstrap
 * slangasek files bug #854449 about the broken Contents generation
<ubot4> Launchpad bug 854449 in launchpad "generate-contents-files.py failing on Ubuntu archive since September 11/12 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/854449
<pitti> ok, then I'll just wait a bit until the publisher comes to a rest
<infinity> I retriggered the mirrors for good measure anyway.
<pitti> wow, publisher finished after 75 mins
<pitti> *sigh*, does any of the images *not* fail?
<infinity> In theory, none of them should. :P
<infinity> But if the mirror signature issue is plaguing you, nothing will work.
<pitti> http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/20110920/
<pitti> wohoo
<pitti> (posted)
<infinity> Successful live-based images aren't exciting if the livefs failed...
<infinity> Since it just uses yesterday's.
<pitti> no, I mean my alternate build attempts all silently failed
<pitti> (will check logs in a bit)
<pitti> are we even doing armel+ac100?
<pitti> and imx51?
<infinity> For mx5...
<pitti> the tracker seems to have all these added (disabled, though)
<infinity> And ac100.
<infinity> For daily-preinstalled.
<infinity> ubuntu, that is.
<infinity> No other flavour.
<infinity> You'll get all the right defaults if you just run the scripts. :P
<infinity> (honest)
<pitti> infinity: I mean for the tracker
<pitti> Ubuntu Desktop armel+ac100 (rebuilding...)
<pitti> ^ these
<infinity> pitti: mx5 and ac100 should be on the tracker for ubuntu-preinstalled.
<pitti> so we do those, ok; I think we didn't for b1
<infinity> Yeah, that.
<pitti> server ac100, too? because the cron job didn't build those
<infinity> Also, that preinstalled server image looks suspiciously like it contains a current livefs...
<infinity> Like, it may be okay!
<infinity> pitti: No, server is only omap/omap4.
<infinity> pitti: If the tracker lists ac100/mx5 for anything other than ubuntu desktop, it's wrong.
<infinity> (And I thought I went over this 12 hours ago with skaet... Hrmph)
<pitti> ok, removing alternate mx51 and server ac100 from the tracker
<pitti> ScottK: are we doing kubuntu preinstalled and/or kubuntu-mobile preinstalled?
<pitti> can start a build now if we want them
<pitti> infinity: ok to accept the unity upload? it whitelists update-notifier for the systray to make slangasek get updates again
<pitti> infinity: it was a rather unnoticed (by us) behaviour change in unity-2d after b1
<pitti> no other changes
 * pitti takes the bullets and accepts
<pitti> otherwise some beta-2 users might be stuck, not ever getting updates again
<pitti> ScottK: starting those builds, I'll just post them; let's see what sticks
<infinity> pitti: Err.  It's a fix in the library?
<pitti> infinity: it's just a configuration change, there's a gsettings key for the whitelist
<infinity> Kay..
<infinity> Was just curious how a unity upload would fix unity-2d.
<pitti> if it doesn't make it to the images, it's not the end of the world, but as I have queued the ubuntu images last in the chain anyway, it might just make it
<pitti> infinity: ah, it's in unity-common, which ships the gsettings schema
<infinity> Mmkay.
<pitti> /usr/share/glib-2.0/schemas/com.canonical.Unity.gschema.xml, systray-whitelist FYI
<infinity> So, it turns out that there's a point where you have enough bandwidth that downloading a 600MB image is faster that zsyncing a 10% delta.
<infinity> And I'm at that point.
<pitti> heh, nice
<infinity> s/that z/than z/
<infinity> I'm actually oddly disappointed by this.
<pitti> http://cdimage.ubuntu.com/xubuntu/daily/20110920.1/ posted
<pitti> seems kubuntu arm isn't happy, failed
<pitti> kubuntu-mobile, too
 * infinity waits for logs.
<infinity> Or, I could force an update. :P
<pitti> kubuntu dvd build failed again on invalid release file, will try again later
<infinity> kubuntu-mobile was the same failure (bad sig)
<infinity> And kubuntu-preistalled.
<infinity> So frustrating. :/
<pitti> it has always been a gamble, but I don't remember it being that hard
<infinity> In theory, it should never break.
<infinity> dists/ on ftpmaster is always consistent.
<pitti> anyway, I'll keep trying and post 20110920.257, if it ever condescends to build
<infinity> So, the only way for it to break is for syncproxy and beyond to have issues.
<infinity> I think you want "consents".
<infinity> Though I like "condescends". :P
<pitti> I actually mean it that way :) you have to address it very carefully and properly, otherwise it's grumpy and fails
<infinity> Ahh, how I've missed awkward German English constructs. ;)
<pitti> so is that bad grammar?
 * pitti checks dictionary "to condescend to do sth." seems valid
 * pitti runs anonftpsync manually and crosses fingers
<pitti> damn you, mirror
<infinity> pitti: That usage certainly exists (or existed?), but either it's only used in countries I never hang out, or it's archaic.
<slangasek> I would tend to prefer 'deign'
<infinity> pitti: (The more common meaning of "to condescend" is to talk down to someone, or treat them as an inferior)
<pitti> infinity: ah, might be; I think I heard it first in the last song of "Cats"
 * infinity is down with deign.
<pitti> but apart from that, anonftpsync didn't help
<infinity> Forcing a trigger from cocoplum might.
<pitti> infinity: ah, the language barrier again -- what is "force a trigger from cocoplum" in shell?
<infinity> Hahah.
<infinity> lp_publish@cocoplum:~$ /srv/launchpad.net/codelines/current/cronscripts/publishing/distro-parts/ubuntu/finalize.d/90-trigger-mirrors
<infinity> (Which I just did)
<infinity> pitti: After that, when syncproxy (91.189.92.172) stops suckling on port 873 on cocoplum, you should be good to go to re-sync from antimony.
<infinity> (At least, I think that's antimony's upstream mirror... I lose track of everything around this time of day)
<pitti> tcp    63999      0 91.189.90.15:873        91.189.92.172:50934     ESTABLISHED -
<pitti> wthis one, I suppose
<infinity> Yeah, that's antimony's mirror, I'm not losing it.
<infinity> (antimony's upstream, that is)
<infinity> Well, for non-ports.
<infinity> For ports, it's... ports.
<infinity> 91.189.92.175
<pitti> that just has a TIME_WAIT one, so is being closed?
<infinity> And ports just finished.
<Daviey> infinity: is that an ssh trigger?
<infinity> It's a bit sad that I find the easiest way to remember the ANONFTPSYNC magic environment variable for config files is to "grep anonftpsync /src/cdimage.ubuntu.com/bin/*"
<infinity> Daviey: Yeah.
<infinity> s/src/srv/
<Daviey> How come we are on .2?  We've had 3 spins today?
<infinity> Mirror issues.  See above. :P
<infinity> We've not had more than one successful spin of anything today, but it's taking some effort to get 1 of everything.
<Daviey> ah!
<Daviey> Hmm, we need some more duct tape.
<infinity> Or WD-40.
<pitti> ah, seems the cocoplum mirror push finished, running anonftpsync again
<infinity> Alright, server-preinstalled with ext4 seems to work correctly, I think it's bedtime for me now.
<infinity> If I can sleep. :P
<pitti> erk, did the DC just fell off the planet?
<infinity> I still see it.
<infinity> Maybe it's you that no longer exist?
 * pitti dissolves into a logic cloud
<pitti> LP and chinstrap both don't respond right now
<pitti> I think it wants to tell me "go have breakfast at last, dammit" or so
<infinity> Possibly. :P
<infinity> I never got around to breakfast today.
 * pitti bows to the higher deity of interweb tube failure and toddles off
<sladen> ScottK: yeah, there may be a case for splitting it into multiple binary packages to allow for selective shipping  It would be good to have some feedback if that might be necessary
<sladen> ScottK: do you have specific examples in mind?
<infinity> sladen: Say, is it intentional that items on my desktop recently developed nearly-unreadable grey text, instead of... Whatever it was before that I could see?
<pitti> yay, DC back for me, and kubuntu dvd build doesn't fall over right away
<pitti> ... and there it goes again; my provider seems to hate me today
<pitti> infinity: would you mind starting this in screen:
<pitti> echo kubuntu preinstalled && buildlive kubuntu daily-preinstalled && (for-project kubuntu cron.daily-preinstalled &) && echo kubuntu-mobile preinstalled && buildlive kubuntu-mobile daily-preinstalled && for-project kubuntu-mobile cron.daily-preinstalled
<jibel> skaet, I confirm the desktop upgrade issue bug 854490
<ubot4> Launchpad bug 854490 in cups (Ubuntu Oneiric) (and 1 other project) "update from natty to oneiric hangs on libpam0g upgrade and cups reload (affects: 1) (heat: 8)" [Critical,New] https://launchpad.net/bugs/854490
<infinity> Sure...
<infinity> pitti: Running.
<pitti> infinity: thanks, I see them (can log into the DC again)
 * infinity finally passes out.
<infinity> See you all in the morning, or some approximation thereof.
<pitti> infinity: sleep well!
<infinity> Thanks.  I'll be back in ~8 hours. ;)
<mvo> skaet: I can confirm 854490 as well and we have some idea what the problem is now
<mvo> jibel: heh, I knew that there would be a bugreport already about the cups thing, nothing escapes your hawk eyes :-)
<jibel> mvo, :) I'm running the upgrade with debug mode enabled now.
<jibel> mvo, BTW there is also bug 853688 that affects upgrades
<ubot4> Launchpad bug 853688 in gcj-4.4 (Ubuntu Oneiric) (and 1 other project) "Natty to Oneiric - failed to calculate the upgrade with gcj-4.4-jre installed (affects: 12) (dups: 5) (heat: 52)" [High,Triaged] https://launchpad.net/bugs/853688
<mvo> jibel: thanks! I put some info into #854490, see comment #11 and #13 for the cause of the issue
<mvo> jibel: I got one report about a dpkg failure for duplicated changelogs:
<mvo> Unpacking libglib2.0-0:i386 (from .../libglib2.0-0_2.29.92-0ubuntu1_i386.deb)
<mvo> +...
<mvo> dpkg: error processing
<mvo> +/var/cache/apt/archives/libglib2.0-0_2.29.92-0ubuntu1_i386.deb (--unpack):
<mvo>  './usr/share/doc/libglib2.0-0/changelog.Debian.gz' is different from the same f
<mvo> +ile on the system
<mvo> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
<mvo> jibel: have you seen anything like this? iirc that was a dpkg bug that got fixed in oneiric, but I may misremember
<jibel> mvo, nope. nothing that I remember.
<seb128> mvo, I've seen those errors
<seb128> mvo, it's bug #835625
<ubot4> Launchpad bug 835625 in apt (Ubuntu Oneiric) (and 1 other project) "apt may try to unpack a foreign-arch multiarch library before the native package is at a multiarch version, prohibited by dpkg (affects: 6) (dups: 5) (heat: 54)" [High,Fix released] https://launchpad.net/bugs/835625
<seb128> slangasek, ^ btw I'm not sure there is no bug there, we got several duplicates about this change.Debian.gz being differents
<mvo> seb128: hrm, hrm, the problem here of course is that its the old apt calculating the ordering
<pitti> seb128: changelog being different> that's not just from locally built/installed debs?
<seb128> pitti, no
<seb128> I will not pretend I understand the bug, but we got several bugs from people doing natty to oneiric dist-upgrades
<seb128> the bug title suggest that somebody understands what the issue is though " try to unpack a foreign-arch multiarch library before the native package is at a multiarch version, prohibited by dpkg"
<pitti> eek, kubuntu alternate amd64 is uninstallable, nevermind; I'll rebuild it
<pitti> (http://cdimage.ubuntu.com/kubuntu/daily/20110920.6/report.html)
<pitti> http://cdimage.ubuntu.com/kubuntu/daily-live/20110920/ posted
<pitti> http://cdimage.ubuntu.com/kubuntu/daily-preinstalled/20110920/ posted
<Daviey> is apport-retracer working?
<pitti> Daviey: i386 and dup checker should, amd64 is down ATM
<pitti> I'm working on that on the side
<ScottK> sladen: Kubuntu ships the Ubuntu font. I assume other flavors do too.
<ScottK> pitti: We're doing kubuntu preinstalled for omap/omap4.
<pitti> ScottK: thanks for confirming; I posted them (mobile still building)
<ScottK> K.
<Daviey> pitti: thanks
<pitti> at last! http://cdimage.ubuntu.com/kubuntu/daily/20110920.8/
<pitti> Daviey: ^ ... and you were complaining about .2 :)
<Daviey> pitti: I want a .42!
<pitti> don't say that too loudly :) mirrors and publisher have been so naughty today, it might actually happen
<Daviey> heh
<NCommander> pitti: killed (didnt see your ping earlier)
<pitti> NCommander: thanks
<pitti> note to whoever accepted gtimelog: it will be uninstallable until pango1.0 is accepted as well (no big deal, though)
<pitti> that can happen after b2
<ogra_> shriek
<ogra_> something changed last night in debian-cd it seems ... and that broke ac100
 * ogra_ curses loudly
<Daviey> ogra_: aiui infinity changed the default for arm images to ext4, could that be related?
<ogra_> he changed a lot more (and broke a lot more)
<ogra_> grmbl
<cjwatson> ev: please push your release commit of lupin to bzr
<cjwatson> (bound branches!)
<ev> cjwatson: will do
<ev> oh, it is bound, but I hadn't done the actual debcommit -r yet
<ev> done now :)
<cjwatson> ah
<cjwatson> I have an 'ubuntu-release' script to stop me forgetting that
<cjwatson> http://paste.ubuntu.com/693683/
<Daviey> Interesting, never used debrelease
<ev> cjwatson: neat, will poach
<ev> thanks
<ogra_> cjwatson, hmm, is it correct that bin-compress_images overwrites the .type file ? publish-release really gets confused by this for tarballs
<cjwatson> no idea
<cjwatson> this stuff is totally your team's problem :)
<ogra_> infinity added code to suppress the actual gzip call for already gzipped files
<ogra_> but the original code still rewrites .type which makes all images end up as img.gz
<ogra_> hmm, k
 * ogra_ will wait for infinity ... i think that behavior is wrong in general not actually arm specific
<pitti> NCommander: are you sure?
<pitti> cdimage  21674  0.0  0.0  10440   208 pts/2    T    Aug04   0:00 nano index.html
<pitti> NCommander: ^ still seems alive
<pitti> state "T" seems like Ctrl-Z'ed without bg'ing it
<pitti> i. e. an fg in your screen session should bring it back
<pitti> ev: do we need this lupin upload in b2? it's got no bugs attached, so I don't know about the impact
<ev> pitti: without it, Wubi installs will always boot, but they'll never have a proper grub configuration
<pitti> and which images does this affect? only the wubi one, or desktop images, too?
<ev> but they'll be fixed on first update
<ev> just Ubuntu wubi images
<pitti> wubi isn't built/published yet, but a lot of desktop images are already
<ev> it doesn't affect Kubuntu wubi or anything else
<pitti> ev: ah, that's fine then
<pitti> ev: accepted, will wait for this for the wubi image build (that still needs a bit anyway)
<ev> okay, cool
<ev> wubi also is missing swap. I'm working on that now, but it'll be a post-b2 thing.
<nigelb> 49
<nigelb> err, sorry!
<pitti> http://cdimage.ubuntu.com/daily/20110920.4/ posted
<ogra_> would someone mind if i ran a cron.daily-preinstalled for ac100 ? (i need to check a fix)
<ogra_> (or could someone do it who drives the builder anyway)
<pitti> ogra_: let me check, before lunch I still had three images building
<pitti> ogra_: but I haven't started ubuntu preinstalled builds yet, that's still in my pipe
<ogra_> k, i only need the cdimage run, no new livefs
<pitti> was waiting for control-center and ubiquity
<ogra_> should be quick
<pitti> we need a new livefs, though?
<ogra_> why ?
<pitti> ogra_: did you already build on a few hours ago?
<ogra_> i need to test a fix in debian-cd, livefs sits on the livefs builder already
<pitti> oh, does it? not from me
<ogra_> i dont plan to publish that
<ogra_> no idea how old that livefs is
<pitti> my queue is: edubuntu/ubuntu dvd, ubuntu desktop+dvd, ubuntu preinstalled
<ogra_> hmm, i would like to have it tested before you actually do a preinstalled build
<ogra_> the test takes 10-12min ... a full build will take hours
<pitti> posting http://cdimage.ubuntu.com/kubuntu-mobile/daily-preinstalled/20110920/
<pitti> ogra_: ok, then go ahead please
<ogra_> thx
<pitti> ogra_: and let me know when I can start the full one
 * pitti will rebuild core and ubuntu desktop/DVD in the meantime
<ogra_> running, should be done soon (and shouldnt interfere with anything you do anyway)
<ogra_> pitti, thanks, done (seems i need to rm the broken img.gz files, they seem to stick from former builds)
<pitti> ogra_: working then? can I queue the ubuntu desktop preinstalled builds?
<ogra_> wait a sec, it seems infinity switched debian-cd to ext4 over night but forgot some places
<ogra_> while ac100 now works the others complain about the lack of an ext4 filesystem
<ogra_> i guess buildlive wasnt switched
<pitti> sure, waiting for your word then
<ogra_> yeah, as i thought, still builds ext3 rootfses
 * ogra_ fixes
<ogra_> ohm, he swuitched already but after the last livefs build, thats why we have no ext4
<ogra_> pitti, all fine, was justa  race between his commit and the last buildlive ... go ahead
<pitti> ogra_: running
<pitti> posted http://cdimage.ubuntu.com/daily-live/20110920/
<pitti> jibel: ^ FYI
<stgraber> good morning
<pitti> ev: argh, booting the i386 CD just gives an ubiquity error
<ev> rubbish
<pitti> ev: AttributeError: "NoneType" object has no attribute "set_online_state"
<ev> will pull down the CD now and fix
<pitti> ev: known, or want a bug?
<ev> bug please
<cjwatson> oh good, that doesn't look like it was my fault
<pitti> ev: bug 854706
<ubot4> Launchpad bug 854706 in ubiquity (Ubuntu) "ubiquity crashed with AttributeError in set_state(): 'NoneType' object has no attribute 'set_online_state' (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/854706
<pitti> seb128, ev: is it deliberate that the desktop does not have an "Install 11.10" icon any more? ubiquity is just in the launcher now
<seb128> pitti, I don't know about this change
<ev> thanks
<pitti> ev: followed up; only happens when the machine is offline
<ev> seb128: that's not purposeful. Perhaps someone broke casper?
<ev> err pitti :)
<seb128> pitti, ls ~/Desktop ?
<pitti> uh, it's there
<pitti> ubiquity-gtkui.desktop
<pitti> why the heck isn't it displayed?
<pitti> examples icon is there, although with dark grey text, hard to read
<seb128> pitti, is it bug #854401
<ubot4> Launchpad bug 854401 in nautilus (Ubuntu Oneiric) (and 2 other projects) "the text on desktop icons doesn't adapt to the background color (affects: 6) (dups: 1) (heat: 32)" [High,Confirmed] https://launchpad.net/bugs/854401
<pitti> seb128: OnlyShowIn=GNOME;XFCE;
<seb128> pitti, yeah, the text color issue is "known", I've pinged upstream
<seb128> pitti, oh, need to have Unity added
<seb128> Unity is different from GNOME since oneiric
<pitti> ev: ^ want a bug for adding "Unity" to OnlyShowIn as well?
<pitti> or JFDI?
<pitti> I confirmed that this fixed it
<pitti> weird, how did we not get that in b1
<ev> pitti: by all means, JFDI. Working on a fix for 854706 now
<stgraber> pitti: do we have an edubuntu build scheduled? I was a bit surprised not to get my usual e-mail from the tracker this morning :) though based on the above, if there isn't one building at the moment, I'd rather wait for these ubiquity fixes.
<pitti> ev: I can't commit to lp:ubiquity, so I'm afraid for JFDI you have to do the change
<pitti> stgraber: yes, it's in the pipeline
<ev> pitti: sure thing
<pitti> stgraber: it's building already; I won't post it, I guess
<pitti> stgraber: (unless you want to)
<stgraber> pitti: ok. I'll rsync it anyway and do some tests on LTSP but won't do as much testing as an actual beta2 candidate
<pitti> stgraber: I'll ping you once it's built
<stgraber> pitti: thanks
<pitti> jibel: http://cdimage.ubuntu.com/dvd/20110920/ is ready for smoke-testing, but won't publish to tracker due to bug 854706
<ubot4> Launchpad bug 854706 in ubiquity (Ubuntu Oneiric) (and 1 other project) "ubiquity crashed with AttributeError in set_state(): 'NoneType' object has no attribute 'set_online_state' (affects: 1) (heat: 10)" [High,New] https://launchpad.net/bugs/854706
<jibel> pitti, ack.
<pitti> ScottK: ^ I'm not sure whether this affects Kubuntu as well
<stgraber> pitti, ev: I commited the .desktop fix
<ev> stgraber: thanks
<pitti> stgraber: merci
<skaet> good morning
<stgraber> good morning skaet
<utlemming> jamespage: ping
 * skaet catches up on the backscroll,  whew, busy day. 
<jamespage> hey utlemming
<skaet> mvo,  thanks for confirmation on bug 854490.  Any update on bug 848659?
<ubot4> Launchpad bug 854490 in pam (Ubuntu Oneiric) (and 1 other project) "update from natty to oneiric hangs on libpam0g upgrade and cups reload (affects: 6) (dups: 1) (heat: 22)" [Critical,Confirmed] https://launchpad.net/bugs/854490
<ubot4> Launchpad bug 848659 in update-manager (Ubuntu Oneiric) (and 1 other project) "Upgrade from natty fails with 64-bit oneiric beta cd (affects: 1) (heat: 8)" [High,New] https://launchpad.net/bugs/848659
<utlemming> jamespage: I believe your the one that I hit up on adding the daily build of oneiric to the tracker?
<pitti> hey skaet, good morning
<jamespage> utlemming: hrm - sorry I can't do that but I can kick off the automated testing when required - jibel are you able to ^^
<utlemming> jamespage: getting my names crossed....can you kick the automated testing for the 20110920 daily build?
<skaet> hey pitti, busy day for you I see.
<jamespage> utlemming, sure - will do
<pitti> skaet: yeah :)
<skaet> pitti, am having problems since last night accessing ether pad,  is it working ok for you?
<ogra_> skaet, yeah, we are coordinating in #ubuntu-keep-pitti-busy
<ogra_> :)
<pitti> skaet: it often times out here, but so far I was able to keep it up with the reconnect button
<skaet> ogra_, lol
<skaet> ogra_,  are there things on your must fix list today for ARM?  (saw some angst on the backscroll, but not sure if its sorted now or not)
<skaet> pitti, yeah, in again now.  was seeing crashes/fails to find last night as I left though,  so might be prudent to keep a periodic screen scrape. :/
<ogra_> skaet, i will know once the current build finishes
<ogra_> waiting idly for that atm
<skaet> ogra_, gotcha.
<pitti> skaet: current builds are ubuntu preinstalled arm, and ubuntu chinese
 * skaet crosses fingers for ogra_ 
<pitti> but the current dvd/chinese builds are in vain, for above bug
<skaet> pitti, which bug?   (there are a few of them up there ;) )
<pitti> skaet: bug 854706, see pad
<ubot4> Launchpad bug 854706 in ubiquity (Ubuntu Oneiric) (and 1 other project) "ubiquity crashed with AttributeError in set_state(): 'NoneType' object has no attribute 'set_online_state' (affects: 2) (heat: 14)" [High,Confirmed] https://launchpad.net/bugs/854706
<skaet> pitti,  thanks!
<slangasek> seb128, mvo: it's not bug #835625; 835625 is about trying to unpack a Multi-Arch: same package while a Multi-Arch: none one is still installed, the bug you're seeing is about the contents of the Multi-Arch: same packages being different - which means, according to Multi-Arch, that one of the packages has wrong contents.  Maybe there's still a package manager bug, but if so it's a different bug
<ubot4> Launchpad bug 835625 in apt (Ubuntu Oneiric) (and 1 other project) "apt may try to unpack a foreign-arch multiarch library before the native package is at a multiarch version, prohibited by dpkg (affects: 6) (dups: 5) (heat: 54)" [High,Fix released] https://launchpad.net/bugs/835625
<skaet> pitti,  is someone actively looking into 854706?  not clear from the bug assignments...
<jibel> skaet, ev is on it
<seb128> slangasek, ok, I'm just saying that the changelog.Debian.gz is the same between i386 and amd64 (checked from the .debs) and that several user ran into in the issue, it seems during natty to oneiric dist-upgrades
<jibel> skaet, <ev> pitti: by all means, JFDI. Working on a fix for 854706 now
<seb128> slangasek, the first bug we used to track it is bug #839744 but Torsten dupped it from the other one
<ubot4> Launchpad bug 839744 in glib2.0 (Ubuntu) "package libglib2.0-0 2.29.16-0ubuntu3 [modified: usr/share/doc/libglib2.0-0/changelog.Debian.gz] failed to install/upgrade: ErrorMessage: './usr/share/doc/libglib2.0-0/changelog.Debian.gz' is different from the same file on the system (dup-of: 835625)" [Undecided,Confirmed] https://launchpad.net/bugs/839744
<ubot4> Launchpad bug 835625 in apt (Ubuntu Oneiric) (and 1 other project) "apt may try to unpack a foreign-arch multiarch library before the native package is at a multiarch version, prohibited by dpkg (affects: 6) (dups: 5) (heat: 54)" [High,Fix released] https://launchpad.net/bugs/835625
<ev> just updated the bug to reflect that I'm working on it
<ev> (done now, just testing the hell out of it)
<skaet> thanks ev
<slangasek> seb128: one possible explanation for this is that /usr/share/doc/libglib2.0-0/changelog.Debian.gz is a symlink on their system due to some previous upgrade issue
<skaet> thanks jibel.
<slangasek> seb128: also note at the top of bug #839744 that the changelog file is listed as "modified"
<ubot4> Launchpad bug 839744 in glib2.0 (Ubuntu) "package libglib2.0-0 2.29.16-0ubuntu3 [modified: usr/share/doc/libglib2.0-0/changelog.Debian.gz] failed to install/upgrade: ErrorMessage: './usr/share/doc/libglib2.0-0/changelog.Debian.gz' is different from the same file on the system (affects: 2) (heat: 12)" [Undecided,Confirmed] https://launchpad.net/bugs/839744
<seb128> slangasek, right, same on bug #839744
<ubot4> Launchpad bug 839744 in glib2.0 (Ubuntu) "package libglib2.0-0 2.29.16-0ubuntu3 [modified: usr/share/doc/libglib2.0-0/changelog.Debian.gz] failed to install/upgrade: ErrorMessage: './usr/share/doc/libglib2.0-0/changelog.Debian.gz' is different from the same file on the system (affects: 3) (dups: 1) (heat: 22)" [Undecided,Incomplete] https://launchpad.net/bugs/839744
<slangasek> seb128: I see you marked 843836 as a duplicate too, and that has nothing to do with upgrades; were you meaning to dupe it to a different bug?
<seb128> slangasek, yes, probably a tab-by-one error, fixing it, thanks for pointing it ;-)
<seb128> btw can be interesting for people there:
<seb128> http://mail.gnome.org/archives/desktop-devel-list/2011-September/msg00127.html
<seb128> it's the first draft of next GNOME cycle, https://live.gnome.org/ThreePointThree#Schedule
<seb128> 3.4.1 would be for april 16
<seb128> which would be nice to get in the lts if we can
<ev> would someone remind doing peer review on http://paste.ubuntu.com/693820/ and http://paste.ubuntu.com/693821/ . It's a small change, but I'd rather prefer a second set of eyes on any change I make to pciutils :)
<pitti> ev: http://paste.ubuntu.com/693820/ > how does that work?
<pitti> ev: at least with dh_install, *.dirs files are usually not necessary at all
<pitti> but even if you have the dir, don't you need to modify an *.install file or debian/rules to actually install it there?
<ev> ah, indeed
<ev> apols, I did that quickly and apparently without thinking clearly
<pitti> ev: http://paste.ubuntu.com/693821/ > I think that needs to be something like "usr/sbin/biosdevname sbin/"
<cjwatson> biosdevname to /sbin> implementation details aside, I endorse this product or service
<pitti> ev: if upstream make install installs to /usr/sbin/
<cjwatson> or configure --sbinidir
<pitti> ev: or configure with a --bindir
<cjwatson> with spelling and everything
<skaet> cloud images (20110920) have been posted to tracker.
<Daviey> \o/
<skaet> :)
<jamespage> utlemming, running now - litmus test across all regions was OK
<utlemming> jamespage: glady to hear :)
<jamespage> results will appear here - > https://jenkins.qa.ubuntu.com/job/oneiric-server-ec2/
<jamespage> in about 1.5 hours
<pitti> skaet: can you take over the coordination now? I'm in desktop meeting and will call it a day soon
<skaet> pitti,  can do
<pitti> skaet: right now we are mainly waiting for a new ubiquity, and then respin everything desktop-y
<pitti> skaet: my ubuntu arm preinstalled images shouldn't take too long any more, I'll still post them when they are done
<skaet> pitti, sounds good.   I'll let you post those last and then set up do the respin the images when ubiquity lands.
<skaet> slangasek,  what's the outlook on bug 854490?  (would like to include it in the next set of respins)
<ubot4> Launchpad bug 854490 in pam (Ubuntu Oneiric) (and 1 other project) "update from natty to oneiric hangs on libpam0g upgrade and cups reload (affects: 6) (dups: 1) (heat: 22)" [Critical,Confirmed] https://launchpad.net/bugs/854490
<jibel> ev, could you look at bug 854717 before any respin.
<ubot4> Launchpad bug 854717 in ubiquity (Ubuntu Oneiric) (and 1 other project) "Broken panel icons and dialog style during ubiquity-dm and OEM install/final user configuration (affects: 1) (heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/854717
<slangasek> skaet: haven't had a chance to look into it yet; it's possible we can improve the pam logic, but I think something's seriously wrong with cups if it hangs like this
<ev> jibel: will do
<skaet> slangasek, understood.  Will ping and see where we are before the next respin.
<pitti> slangasek: do you have an idea how to avoid it?
<pitti> slangasek: it tries to start cups while it's libraries and daemon are being upgraded/unpacked/unconfigured
<pitti> no amount of Depends: can rectify this, AFAICS
<pitti> slangasek: would it be hard to apply the "ignore if it is not already running" logic that it applies to gdm to also apply to all other services?
<slangasek> pitti: why does cups hang when things are not yet upgraded?  if /usr/sbin/cupsd fails to run, it should fail quickly... even hitting the respawn limit shouldn't take very long
<slangasek> pitti: I'm not keen on "check if it's running, then start"; gdm is a special case because we have to use 'reload' instead of 'restart', the same logic would not be appropriate in general
<pitti> slangasek: according to mvo's tests, it actually should fail quickly, with a symbol error
<pitti> slangasek: oh, wow; I actually expected that to be fairly uncontroversial
<pitti> trying to start a daemon from an unconfigured package with unconfigured dependencies is prone to fail, and not really necessary either -- it will restart itself once it's configured
<slangasek> well, it basically means we're bypassing the invoke-rc.d policy interfaces that exist for a reason
<slangasek> so I want to be sure I understand why we need to bypass them before doing so
<pitti> well, we could also fix this in invoke-rc.d to not start a daemon if the package isn't configured
<mvo> slangasek: it fails quickly, but there seems to be no respawn limit
<pitti> but that seems harder to do
<slangasek> it may be that we should just get rid of the "invoke-rc.d $foo stop" / "invoke-rc.d $foo start" and replace it with restart
<slangasek> mvo: there's a default respawn limit
<pitti> and even if we work around it in cups, we don't want to apply workarounds to the other 20 packages
<mvo> slangasek: how big is that?
<mvo> slangasek: thats in upstart itself, right?
<pitti> and it would be a work around no matter what; we can't suddenly introduce the expectancy that a packagae will DTRT when not being configured
<slangasek> mvo: "Default COUNT is 10. Default INTERVAL is 5 seconds." - so this should hang the upgrade for 50 seconds max
<slangasek> mvo: yes
<pitti> that only exists for essential pacakges
<slangasek> pitti: I'm *not* expecting that the package will start when not configured
<pitti> slangasek: asked the other way around, why does the postinst need to start services which are not running in the first place?
<slangasek> I'm expecting that it not hang indefinitely
<slangasek> it doesn't!
<mvo> interessting, I'm pretty sure that I waited (way) longer then 50s
<pitti> I thought the idea of that was to restart *running* services to make them use the new libpam
<slangasek> it is, but that doesn't mean I agree with the hammer you've chosen :)
<slangasek> please let me think through this horrid code for a bit
 * mvo runs the test again with a stop-watch and more patience ;)
<pitti> mvo: I wonder if the problem is that upstart doesn't notice that cupsd has failed, and then runs the post-start script?
<pitti> because that tries to talk to the daemon, and might cause long timeouts
<slangasek> invoke-rc.d restart doesn't help; this is defined to try to start the service if not already running
<pitti> right, I think we need to ask invoke-rc.d <service> status
<slangasek> I'm still really of the opinion that we should not have to care in the postinst about whether the service is configured yet.  invoke-rc.d is supposed to protect us from starting services that should not be started by policy, and trying to start an unconfigured service should fail gracefully
<slangasek> and 'status' is an optional init script target
<jibel> slangasek, mvo I waited way longer than 50s like I had time to have lunch.
 * pitti needs to leave for an hour or two, will check in again later
<slangasek> pitti: ^^ so we can't do a wholesale switch to 'status' without reviewing whether each one of these services implements the target
<pitti> slangasek: I see; so as an approximation we might rather check if the package is configured then?
<slangasek> pitti: might it not be easier to fix whatever's causing cups to hang, which we should fix anyway?
<pitti> slangasek: it might, but who tells us that the very same problem doesn't apply to the other services it tries to restart?
<slangasek> calling dpkg a couple dozen times isn't going to make the upgrade any faster :)
<slangasek> pitti: the fact that this code has been in place for years and this is the first time anyone's reported a problem :)
<pitti> as I said, we can certainly work around this in cups, but we still need to check an upgrade with the others
<slangasek> it's not a "workaround".  'invoke-rc.d cups start' should not hang indefinitely, regardless of whether the package is configured; that it does is a bug in the cups package somewhere
<pitti> I still think it's wrong to try and start unconfigured packages, but if you say it's too hard to fix in libpam0g, I'm ok with looking into cups here specifically
<pitti> added a cups task
<pitti> will look into this tomorrow morning, so hopefully we have something working for b2
<pitti> and crossing fingers that it doesn't affect other packages
<pitti> (cups' upstart script also hasn't changed for ages, so it's probably just bad luck that we got this particular unpack order now)
 * slangasek nods
<pitti> anyway, good night! see you tomororw
<slangasek> g'night :)
 * slangasek has a poke at cups himself
<slangasek> pitti, mvo: at least some of the slow-down is caused by the post-start script; upstart sees cups as started, then stopped, so it waits for the post-start script to finish running before it tries to respawn
<slangasek> oh, and this means it never hits the respawn limit
<slangasek> because the respawn limit is defined as COUNT respawns in INTERVAL seconds, and the post-start script takes 10 seconds to run
<mvo> slangasek: fwiw, its running on in my auto-upgrade tester (or rather its not running ;) I will have dinner and see if anything happens when I come back
<slangasek> mvo: ok. I've reproduced the problem locally by manually hamstringing cupsd
<slangasek> mvo, pitti: cups library interdependencies are wrong.  pam *already* only restarts services that dpkg reports as installed; new libcupsmime1 has been unpacked without deconfiguring cups, but somehow breaks the old version of cups.
<slangasek> sounds like libcupsmime1 dropped symbols without an appropriate soname change
<ScottK> pitti: I think it does.
<skaet> ogra_,  how are the ARM images looking?  Is there something that goes on the must fix & respin list - or should some images be posted for further testing?
<ogra_> skaet, still waiting
<ogra_> we havent had successfull builds for desktop since august 30th
<Ursinha> jesus
<skaet> ogra_, ack.
<ogra_> Ursinha, i doubt he can help :)
<ogra_> unless he is a soyuz coder ;)
<Ursinha> ogra_, heh
<Ursinha> ogra_, what's the problem?
<GrueMaster> I wouldn't say that.  Send him a panda.
<Ursinha> soyuz? ugh
<Ursinha> lol
<ogra_> *giggle*
<Ursinha> ogra_, you said soyuz, anything wrong with Launchpad?
<ogra_> Ursinha, lets go to #ubuntu-arm, i dont want to spam the channel
<Ursinha> sure
<GrueMaster> Ursinha: Between pool skew and mirror issues, we haven't had a desktop image since Beta 1.  Unfortunately I was buried in server testing to notice.
 * infinity sees one today, and one yesterday, at least...
<stgraber> pitti: is 20110920 the edubuntu images you said were building this morning? (just want to check I can smoke test these)
<jamespage> utlemming: https://jenkins.qa.ubuntu.com/job/oneiric-server-ec2/8/
<jamespage> ec2 testing completed - only a couple of issues
<slangasek> mvo: uhoh, I've gone full circle and now think bug #854490 is an apt bug ;)
<ubot4> Launchpad bug 854490 in pam (Ubuntu Oneiric) (and 3 other projects) "update from natty to oneiric hangs on libpam0g upgrade and cups reload (affects: 6) (dups: 1) (heat: 24)" [Critical,Invalid] https://launchpad.net/bugs/854490
<slangasek> because in the log, the cups package has never been deconfigured... but it's definitely broken
<slangasek> libcups2 declares a Breaks: on old cups already
<slangasek> hmm, but libcups2 *hasn't* been unpacked yet
<smoser> slangasek, skaet bug 854927 seems of high to critical priority to me
<ubot4> Launchpad bug 854927 in openssl (Ubuntu) "wget, curl can't verify certificates (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/854927
<kirkland> smoser: slangasek: +1, I found this this morning in ec2
<kirkland> smoser: slangasek: no https from the command line == bad for beta :-(
<skaet> smoser, ack.  thanks for flagging
<slangasek> smoser, kirkland: is this a regression vs. beta-1?
<kirkland> slangasek: yes, this is a regression since yesterday
<kirkland> slangasek: or thereabouts
<smoser> it is demonstratable regression on ec2 instances.
<slangasek> uh
<kirkland> slangasek: i'm reproducing here on my up-to-date oneiric laptop, wget https://google.com
<slangasek> well, we haven't changed openssl in the past 24 hours; the last update was 6 days ago?
<kirkland> http://paste.ubuntu.com/693943/
<kirkland> slangasek: i was thinking maybe it was blocked/queued until recently?
<slangasek> kirkland: no, my laptop shows libssl1.0.0 was upgraded on my system 4 days ago
<kirkland> slangasek: do you have an up-to-date oneiric?  can you wget https://google.com?
<kirkland> slangasek: note the "https"
<Daviey> erm
<Daviey> I'm not sure i can reproduce this
<slangasek> kirkland, smoser: can you give me a package delta between the working/non-working images, please?
<kirkland> looks like wildcard certs are the problem
<smoser> slangasek, working on it.
<Daviey> http://pb.daviey.com/YLVR/
<kirkland> slangasek: smoser: wget https://www.google.com works, but not google.com
<Daviey> ah yes
<kirkland> hmm
<slangasek> kirkland: so did google change the certs on their side?
<Daviey> smoser: on your bug report, www failed?
<kirkland> okay, https://launchpad.net
<Daviey> https://launchpad.net WFM
<ev> jibel: I've had a look at that bug, but I'm not going to be able to fix it tonight, so I've uploaded ubiquity as is.
<kirkland> slangasek: I'm wrong about my local laptop being affected
<kirkland> slangasek: ec2 images, though definitely are
<smoser> i can verify failure of www.google.com on a CanoniStack instance right now
<kirkland> Daviey: yeah, sorry about that
<Daviey> smoser: i cannot.
<slangasek> kirkland: are you missing ca-certificates from the ec2 images, then?
<utlemming> I've confirmed it outside EC2 on virtualbox VM -- same story
<smoser> my local laptop is affected
<ev> jibel: it appears to happen in regular ubiquity as well.  Probably something we're missing from the ubiquity-dm session or a race condition.
 * Daviey suspects the cers are missing
<slangasek> openssl doesn't ship any CA policy
<Daviey> certs
<ev> jibel: though I've only been able to reproduce it in oem mode
<kirkland> slangasek: $ dpkg -l | grep cert
<kirkland> ii  ca-certificates                 20110502+nmu1                           Common CA certificates
<kirkland> ii  ssl-cert                        1.0.28                                  simple debconf wrapper for OpenSSL
<slangasek> that all comes from the ca-certificates package
<Daviey> ubuntu@server-972:~$ dpkg -l | grep cert
<Daviey> ii  ca-certificates                  20110502+nmu1                           Common CA certificates
<Daviey> smoser: I cannot reproduce this in an upgraded oneiric instance.
<Daviey> It sounds to me like an issue with the latest cloud image builds missing someting.
<slangasek> kirkland: strace -ff -e file wget https://launchpad.net 2>&1 | grep usr/lib/ssl ?
<kirkland> slangasek: http://paste.ubuntu.com/693945/
<Daviey> slangasek: http://pb.daviey.com/okGB/
<utlemming> Daviey: I would agree -- expect my VirtualBox instance is a Beta1 Server that was installed ISO and upgraded
<smoser> i only see failure with google.com on local system.
<smoser> so yes, that would seem to indicate not a global issue.
<smoser> and user failure to report that. but it does reproduce with www.google.com on ec2 instance.
<slangasek> kirkland: you get different behavior than me or Daviey
<slangasek> (I see what Daviey sees)
<slangasek> kirkland: I notice that the stat size is completely off
<kirkland> b5534824873e947df1c3e07bedfd688e  /usr/lib/ssl/certs/55a10908.0
<kirkland> lrwxrwxrwx 1 root root 19 2011-09-20 01:34 /usr/lib/ssl/certs/55a10908.0 -> ca-certificates.crt
<Daviey> Those who are seeing this, please can you confirm the history of the install?  daily AMI from what day?
<Daviey> utlemming: you seeing it from iso install, dated?
 * slangasek blinks
<kirkland> -rw-r--r-- 1 root root 240312 2011-09-20 01:32 /usr/lib/ssl/certs/ca-certificates.crt
<slangasek> yes, that's not normal
<slangasek> the hash symlinks normally point to the individual certs
 * kirkland is still getting used to Ubuntu Monospace ...  he just read "yes, that's not moral"
<kirkland> slangasek: how are these installed/generated?  I find this puzzling:
<kirkland> ubuntu@domU-12-31-39-04-9C-3B:~$ dpkg -S /usr/lib/ssl/certs/ca-certificates.crt
<kirkland> dpkg-query: no path found matching pattern /usr/lib/ssl/certs/ca-certificates.crt
<highvoltage> I thought that that is called dyslexia?
<utlemming> ISO 2011-08-31, and upgraded. Seen on daily 2011-09-20. Checking others now
<kirkland> Daviey: i'm running the current day's AMI
<slangasek> kirkland: /usr/lib/ssl/certs is a symlink to /etc/ssl/certs, the contents of which are managed by the ca-certificates package
<slangasek> ugh, mixed spaces/tabs, slap slap
<kirkland> slangasek: in a makefile or something?
<slangasek> no, in the postinst
<slangasek> making it difficult to read
<smoser> ok
<smoser> http://paste.ubuntu.com/693953/
<smoser> is the data i have.
<smoser> 20110914 works, 20110918 fails
<smoser> package diff at pastebin
 * Daviey raises again that if we had a snapshot archive like Debian have, we could bisect this automatically.
<slangasek> smoser: oh. nothing more recent than 20110914?
<smoser> i'll try bisect, slangasek
<slangasek> ok, yes, this is a regression in openssl; I can recreate the issue by running c_rehash manually
<kirkland> openssl *has* changed in smoser's list
<smoser> i can try a 15 and an 18
<smoser> err.. 15 and 17
<slangasek> (which wouldn't get run on an upgrade because there was nothing in need of rehashing)
<mvo> slangasek: I can have a close look into the cups issue tomorrow morning (in ~ +12h). but I think its best to workaround in libpam0g or cups for now
<utlemming> singe 16 was broken due to a armel build failing...
<slangasek> mvo: I'm not sure how to sanely work around it in either place.  Maybe the new libcupsmime1 should also say it Breaks: cups?
<Daviey> utlemming: arm failure breaks the supported arches?
<Daviey> slangasek: Are you driving the ssl issue?
<smoser> ok. 20110915 pass, 20110917 fail
<smoser> getting diff of those
<slangasek> Daviey: yeah, I can; I'm close to a workaround via ca-certificates
<Daviey> rocking
<slangasek> cjwatson: ^^ when you're around, maybe you can comment on the behavior change in c_rehash suddenly preferring ca-certificates.crt as a target and blowing up
<smoser> http://paste.ubuntu.com/693959/
<slangasek> Daviey, smoser, kirkland: do we need to fix this for upgrades from these images, or do we only care about fixing it on new images?
<mvo> slangasek: yeah, I can muck around a bit and see if I can get it to work
<slangasek> mvo: ok, thanks
<Daviey> slangasek: Not many people use oneiric ec2 images, so the support of them can be weak... however, this also hits people who installed the daily iso for the last 6 days, on all flavours?
<Daviey> Desktop aswell?
<smoser> slangasek, well i would hope we'd support someone upgrading from beta-1.
<smoser> admittedly there are not likely a lot of people who would care though.
<slangasek> smoser: this doesn't affect people upgrading from beta-1
<Daviey> smoser: upgrades are not the issue, it's fresh installs
<slangasek> it *only* affects people who installed in the window since the last openssl upgrade
<smoser> can those people fix themselves ?
<smoser> i would think it would be ok if there were a documented work around for those 6 days of install
<slangasek> I'm not sure where to document a workaround... or whether it's worth the effort, considering we're talking about people installing from random dailies
<smoser> well, for hte cloud-images, i think its ok to ignore it.
<smoser> but really, if someone did a install of the isos, and their ssl is busted, and the "fix" is reinstall, that sucks.
<utlemming> if you're installing from dailys, lets face it, you like pain. I would suggest we put it in the bug.
<slangasek> lp:ubuntu/ca-certificates contains a tentative fix; I'm afk for a few minutes, can people put that change through its paces?
<slangasek> to fix an existing install, it should be sufficient to run update-ca-certificates --fresh with the new package
<Daviey> bah, might it just be easier to include that in the postinst if people are upgrading from that package?  It can be dropped when openssl is next uploaded after this.
<Daviey> FWIW, i don't care that much for the 6 day window.
<Daviey> People should expect some manual work-arounds pre-release.
<smoser> i tihnk its < 6 day window too
<smoser> 20110915 daily build PASS
<smoser> 20110917 daily build FAIL
<smoser> so worst case its 20110916 -> 20110921 window.
<Daviey> meh
<smoser> so current desktop isos would be affected?
<smoser> and server isos ? or am i missing something.
<Daviey> smoser: It should be all flavours, surely.
 * utlemming confirms fix
<smoser> utlemming, did you build a binary ?
<utlemming> smoser: yes, through pbuilder
<utlemming> installed it and then ran "update-ca-certificates --fresh"
<smoser> and that fixes issue ?
<utlemming> yes, I verified it on two instances and I'm doing a couple more for good measure
<slangasek> Daviey: yeah, we can probably call that from the postinst; but it's a heuristic, and I'm always wary of heuristics when trying to land an urgent fix
<skaet> Daviey, can you review the latest nova upload in the pending queue, and determine if you want it accepted and included in the next server build?
<utlemming> smoser, slangasek: I tested the fix on 6 instances that had the problem. After updating and running update-ca-certificates, the problem goes away
<Daviey> sure
 * Daviey lols at seeing "skype (source)" in the queue.
<zul> Daviey:  it contains some fixes needed for juju as well
<Daviey> zul: ack
<Daviey> can squid be accepted please?
<skaet> Daviey, yeah looks straight forward.  accepted
<Daviey> ta
<Daviey> zul: nova-2011.3~rc~20110920.r1192/debian/nova_sudoers seems to have introduced a tab vs space issue?
<zul> yeah it should be fine
<skaet> doko,  why is there a binutils in queue - bug number I'm spotting is bug: 690194, which doesn't look like release blocker.  Am I misunderstanding something?
<Daviey> zul: didn't we want to add the flag True for force_dhcp_release ?
<Daviey> (as in, the whole reason we got dnsmasq-utils into beta2?)
<zul> Daviey: crappers..are you sure?
<Daviey> zul: can you confirm, perhaps i missed something?
<skaet> doko, and bug 778292,  which is down as medium
<ubot4> Launchpad bug 778292 in gcc-4.6 (Ubuntu Oneiric) (and 5 other projects) "undefined reference to `pow' when building with -flto (affects: 4) (heat: 24)" [Medium,Invalid] https://launchpad.net/bugs/778292
<zul> daviey: that branch only contained the debian/control and the sudoers change
<zul> perhaps i missed something
<Daviey> zul: Yeah, the merge from Vish didn't include the conf file change.
<Daviey> (it defaults to False.)
<Daviey> we want True
<sbeattie> slangasek: behavior change in c_rehash is likely due to the patch that fixed http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628780
<ubot4> Debian bug 628780 in openssl "Wrong hash link to cacert.org.pem and wron certificat hash handling at all" [Important,Fixed]
<zul> Daviey: ok gimme a sec
<slangasek> sbeattie: aha, thanks for the pointer
<Daviey> zul: fancy resolving the tab vs space?
<slangasek> ca-certificates uploaded; can someone review please?
<slangasek> infinity: ^^ ?
<infinity> slangasek: On it.
<slangasek> skaet: ^^ that's the fix for bug #854927; ca-certificates is on all images, so a respin seems to be in order
<ubot4> Launchpad bug 854927 in openssl (Ubuntu Oneiric) (and 3 other projects) "c_rehash creating bogus links to ca-certificates.crt (affects: 2) (heat: 10)" [High,Triaged] https://launchpad.net/bugs/854927
<infinity> Well, on it when it lands...
<Daviey> zul: is the lack of not declaring a --bridge an issue?
<skaet> slangasek,  yup.
<slangasek> (since this is a major problem for cloud images and they can't release beta2 with it)
<zul> Daviey: no
<Daviey> zul: grep for, 'WARNING! ACHTUNG! Setting the bridge to br100 '
<Daviey> ok
<doko> skaet, it's not marked as a blocker. it's a regression fix for our ld --as-needed default
<infinity> slangasek / skaet: Any qualms about letting in that new light-themes?  It's not particularly RC, but the broken desktop text is certainly something that will make Beta screenshots awful. :P
<infinity> (And I assume we're rebuilding anyway for other reasons)
<skaet> infinity,  I was wondering about that too.   ok, by me.
<zul> Daviey: ok uploading
<skaet> infinity, and yes we're rebuilding.  see: ubiquity fix, and ca-certificates
<infinity> +nmu1ubuntu1 ... That version needs more icky.
<infinity> I, err... Uhm.
<infinity> slangasek: lolwut?
<slangasek> ?
<infinity> +       if [ "$2" = 20110502+nmu1 ]; then
<infinity> +         update-ca-certificates --fresh
<infinity> +       else
<infinity> +         update-ca-certificates --fresh
<infinity> +       fi
<slangasek> sih
<slangasek> sigh
<slangasek> thanks :)
<slangasek> infinity: please reject, I'm reuploading with -v
<infinity> Rejectified.
<infinity> The info box really needs to not say "OK: <package>" on rejects.  I keep having little heart attacks.
 * skaet makes note of rejectified,   plans to use it with twirling images.
<infinity> skaet: Rejectificated is also useful.  It all depends on how hard you press the button.
<slangasek> ca-certificates reuploaded
<slangasek> should I stall the publisher for a few minutes?
<Laney> FYI I got some kind of libproxy working but I think it is probably too much too hard at this time
<infinity> slangasek: With how long it's been taking, I would.
<slangasek> done
<Daviey> slangasek: Are we planning a respin in the next 2 hours?
<Daviey> s/respin/twirl
<infinity> slangasek: Also, congrats on missing the upload queue by 5 seconds.
<slangasek> heh
 * infinity goes for a smoke for the next 3 minutes.
<ScottK> Sigh.  Kubuntu desktop just grew by 5MB.
<ScottK> Trimmed.
<skaet> ScottK.  okie.  adding it to the respin list.
<doko> o kdesvn: kdesvn-kio-plugins libsvnqt6
<doko>    [Reverse-Depends: kdesdk, kdesvn-kio-plugins]
<doko> ScottK, ^^^ still on your list?
<infinity> slangasek: Accepted.
<slangasek> ta
<ScottK> doko: It's an artifact of kdesdk FTBFS on powerpc which I've got no hardware to work on.  michahg said he might take a shot at it on the porter box, but it needs someone with hardware.
<ScottK> The powerpc hardware I had access to died.
<doko> ahh, ok
<ScottK> It's probably a reasonably tractable FTBFS is someone with hardware would take alook.
<infinity> ScottK: I could give you remote access to my firewall, if you promise to be a Good Boy.
<ScottK> Does it have a oneiric chroot that you could install the build-deps for kdesdk into?
<infinity> slangasek: Please don't publish until ubiquity's built all over.
<slangasek> ack
<infinity> Which should actually be really soon...
<infinity> ScottK: It could do.  I have the technology.
<Daviey> skaet: can the topmost nova be accepted, and the prior one be rejected please?
<skaet> Daviey,  go ahead, you know them better than me. :)
<Daviey> skaet: I'm not an archive-admin. :)
<Daviey> I assume ~ubuntu-release was an archive admin.. seems not.
<Laney> that reminds me
 * Laney repings
<skaet> Daviey, hmm. thought that ubuntu-release had the perms.   going in now.
<skaet> topmost: 2011.3~rc~20110920.r1192-0ubuntu2 - accepted.
<Daviey> ta
<Laney> I guess nobody reads ubuntu-archive@, eh?
<Daviey> Laney: you mean the most noisest list ever?
<skaet> 2011.3~rc~20110920.r1192-0ubuntu1 - rejected
<Daviey> ta
<Laney> that's why He invented procmail
<Daviey> Laney: do you filter out SRU acceptance crap?
<ScottK> skaet: There's an open bug asking to get ubuntu-release access to the unapproved page in LP.
<Daviey> Laney: things like, https://lists.ubuntu.com/archives/ubuntu-archive/2011-September/043772.html really don't interest me.
<skaet> ScottK, if you can find the bug number at some point,  I'll add it to the list of ones I'm discussing with the launchpad team.
<ScottK> Sure.
<Laney> Daviey: I'm not subscribed to that list, but I have some heavy duty filters for other ones
<Laney> on the order of Launchpad? => Blah/bulk
<Laney> launchpad gives you headers, but they can only go so far
<Daviey> Laney: well yes, we all do that.. but what i am saying is that ~ubuntu-archive isn't the most interesting of reads, at the best of times.
<Daviey> The only time i look at it, is when someone mentions something that makes me look.
<Laney> sometimes people do need to mail the archive administrators though, and for that there is no other list
<infinity> Meh.  We need to replace all our old arm buildds with more Pandas.  This ubiquity build is taking longer than I expected.
<infinity> (And just when we have enough Pandas, maybe we'll get real server hardware!)
<ScottK> skaet: Bug #648611
<ubot4> Launchpad bug 648611 in launchpad "Queue admin permissions need pocket and status granularity (affects: 1) (heat: 1)" [High,Triaged] https://launchpad.net/bugs/648611
<slangasek> infinity: is there an eta for that build?  You want me to keep waiting?
<skaet> Thanks ScottK,  added it to my tracking
<slangasek> ah, it's on dh_builddeb, that's promising
<infinity> slangasek: That's deceptive.  It's d-i, it builddebs about 4000 times.
<slangasek> ah, heh.
<slangasek> so, no ETA?
<infinity> Not sure.  I could look at an old build log and see where we are. :P
<infinity> Can't respin armel without it, though (like, not at all, since it causes skew with oem-config)
<skaet> slangasek, infinity, while we're waiting for the arm builder, could you check the pad and confirm I've got the state of what needs to be rebuilt accurate?
<skaet> http://pad.ubuntu-uk.org/ubuntu-release
<GrueMaster> I would also suggest rebuilding kubuntu for arm (unless they don't want to release).  They will need the ubiquity fixes and the jasper-initramfs fixes.
<infinity> skaet: I'm not sure what the archive skew bit's meant to be about.  Was that just Oliver having a bit of a fit earlier? :P
<GrueMaster> But not my call.
<infinity> skaet: It can probably be boiled down to "everything but ubuntu-core needs rebuilding due to ubiquity and ca-certs"
<skaet> infinity,  yes, wasn't sure if there were problems, since he was waiting for a rebuild.
<skaet> infinity,  yeah, that's what its looking like.
<GrueMaster> And netinstall.  We don't need it respun.
<infinity> skaet: Yeah, I saw him freaking out in backscroll.  Most of the issues this morning were actually mirror issues, but many other scapegoats were found. ;)
<infinity> GrueMaster: netinstall == d-i upload, not an image.
<skaet> GrueMaster, netinstall?  or you mean netboot?
<infinity> skaet: Same thing.
<skaet> coolio. :)
<infinity> netinst and netboot are just ways of saying "those random little pxe and mini iso images that d-i spits out".
<GrueMaster> what he said.
<GrueMaster> I look at what iso.qa lists for Arm.  Everything but core and netboot. to respin.
<infinity> Dear buildd with the unpronouncable hostname, please build ubiquity faster.  No love, Adam.
<skaet> LOL
<GrueMaster> Do the kubuntu guys have someone to test their images?  If not, I will need to plan for it (after my regular testing).
<skaet> ScottK ^^
<ScottK> Not for omap/omap4, afaik.
<ScottK> I'll check though.
<infinity> slangasek: Ooo, we're in the home stretch.
<slangasek> does that mean it'll be done before the next regularly scheduled publish? :)
<infinity> Yeah, yeah.
<infinity> I may have SLIGHTLY miscalculated that based on not realising that it was building on a babbage...
<infinity> Still armel images take the longest to build, it sort of makes sense to get the archive in order for them first, and then queue up the world.
<infinity> Ish.
<ScottK> Got one maybe for omap.
<ScottK> He's checking to see the status of the system.
<skaet> infinity,  just talked to rbelem,  kubuntu mobile images aren't going to be published with beta 2.   Removing them from the ISO tracker.
<infinity> skaet: This doesn't hurt my feelings.
<slangasek> skaet: I don't see anything missing from the pad, but I'm not sure that I would either
<skaet> slangasek,  thanks.
<infinity> Well, honestly, if you just run pitti's rebuild blocks of doom, minus the two "ubuntu-core" bits at the beginning of the preinstalled block, you should be good to go. :P
<infinity> Assuming nothing fails.
<slangasek> ubiquity armel accepted, publisher now running
<infinity> \o/
<slangasek> well yes, I'm not sure if those are "pitti's rebuild blocks of doom" or if they're modified :)
<skaet> :)
<infinity> If they're modified, he'll be grumpy.
<infinity> He took a while writing those pipelines. :P
<slangasek> mine were better, less duplication of code :)
<skaet> mine had timestamps, so I could gather stats.  ;)
<infinity> Kids, kids.
<infinity> You can each bring me a beer.
<infinity> And then someone can write a parser for etc/crontab and have a proper script on antimony to rebuild the world. :P
<slangasek> that would be slow compared to the current scripts
<slangasek> the cronjobs wouldn't interleave
<infinity> Well, I implied a "good" parser.
<infinity> One smart enough to know how to do what the current mess does, but adapt.
<infinity> Also, as sarcastic as this suggestion is, with crontab being stuffed as full as it is these days, this does get worse every release.
<infinity> I remember when "rebuild the world" meant "Ubuntu alternate and live for three arches".
<infinity> And we whined about how long THAT took.
<slangasek> we could, hmm, stop letting it get more stuffed?
<infinity> I like this idea.
<infinity> We could drop everything but Xubuntu.
<infinity> All in favour?
<skaet> heh, yeah,  there are all those arm images ;)
 * skaet just wants to not build what doesn't get tested, as a starter. 
<skaet> Daviey, https://launchpad.net/ubuntu/+source/nova/2011.3~rc~20110920.r1192-0ubuntu2/+build/2796534
<Daviey> skaet: hmm.
<Daviey> So it's Dep-wait.
<skaet> its Dependency wait on vernadsky - retry?
<Daviey> Please don't assume it wasn't build tested.
<infinity> skaet: No point retrying.
<Daviey> The reason it's now depwait, is that nova has been promoted to main since the last build
<Daviey> The dep it is waiting on is still universe, and i've already chased the MIR.
<infinity> ^
<infinity> skaet: It'll retry itself when that MIR is sorted.
<Daviey> infinity: jdstrand is trying to grok the complex package, it was only recently handed over to him from the previous person undertaking the MIR.
<infinity> Daviey: Seems a bit odd that you got nova promoted before it's build-deps though. :P
<skaet> Daviey wasn't assuming it wasn't build tested. ;)  just wondering if temporary glitch.  universe -> main would explain it.
<Daviey> We either pre-promote it, and make doko shout at us - or just hold out for jdstrand to finish. :)
<Daviey> no pressure jdstrand :P
<infinity> Please don't pre-promote it.
 * doko is wondering why people wait with MIR's until the last  minute ...
<Daviey> doko: Is that a general assumption, or specific to this one?
<Daviey> MIR opened 2011-06-23 fwiw.
<doko> Daviey, people very often cry for pre-promotion, and don't realize that the MIR is incomplete on their side. yes, for some this seems to be business as usual
<Daviey> I'm sure i have been, and will be in the future guilty of that.
 * Daviey pre-apologises
<highvoltage> it's impossible to pre-apologise.
<slangasek> nah; it would be impossible to pre-metalogize, but that's not a word :)
<slangasek> publisher claims to be done
<infinity> Thanks to the magic of language evolution, it is now.
<slangasek> skaet: ^^ are you driving the respins?
<infinity> Probably better if one of us does, she has Big Plans tonight.
<skaet> infinity,  can you do the honors.  Would rather you're able to watch it.
<infinity> I'll flip a coin for it.
<skaet> or slangasek.
<skaet> :)
<infinity> slangasek: My coin says it's your turn.  But it could be wrong.
<slangasek> heh
<slangasek> infinity: would appreciate it if you could do it, I was intending to be off-line doing flicker-free boot debugging
<infinity> I'm happy to, if you and Patty have plans tonight.  And no, making plans hastily in the next 5 minutes doesn't count. ;)
<infinity> Oh, or if you're working on other work crap.  Sure.  I'll respin.
<skaet> infinity,  I'll go ahead and mark the iso tracker that the respins have started.
<slangasek> infinity: thanks
<infinity> Alright.  Any last words from anyone?
<slangasek> klatuu verata oneiricto
<infinity> *snicker*
<stgraber> yeah! might have something to test for Edubuntu tonight then (for some value of tonight I guess)
<infinity> Hrm.  Going to skip wubi and chinese-edition from the loop, unless anyone has arguments against that?
<infinity> And, they're off.
<infinity> And our first round of livefs builds fail.
<infinity> Huzzah.
<infinity> Oh, FFS.
<infinity> E: Invalid Release signature (key id 40976EAF437D05B5)
<infinity> *headdesk*
<slangasek> which means we need to stab the mirroring?
<infinity> slangasek: Wait... How did you run the publisher?
<slangasek> copying the command in lp_publish's crontab
<infinity> slangasek: That shouldn't be a mirror at all... livefs builds (unless broken), should be pulling from ftpmaster.internal.
<infinity> Which should NEVER be broken.
<slangasek> /srv/launchpad.net/codelines/current/cronscripts/publish-ftpmaster.py -d ubuntu -q
<infinity> LPCONFIG=ftpmaster-publish
<infinity> ?
<slangasek> oh bah
<slangasek> this setting of env vars at the top of crontabs, it is not a thing of good
<slangasek> running again
 * infinity wonders how this broken signature situation affects alternates, if at all...
 * jdstrand doesn't feel any added pressure. I'm getting to all these this week and actively working on them now
<infinity> jdstrand: Would you feel more pressure if Daviey repeatedly poked your forehead while you worked?
 * jdstrand sorta feels that way already :P
<jdstrand> seriously though, I got all this this week, and am working on them this week
<infinity> The correct answer is "every time someone bugs me about something, it loses an hour in my queue".
<infinity> Which, given the expense of context switches, is likely true.
<infinity> So, shoo.
<infinity> Stop being bugged.
<Laney> ScottK: is there any precedent for bouncing wishlist FFes to backports?
<slangasek> infinity: ok, publisher done again
<infinity> slangasek: With 38% more keysigning?
<slangasek> maybe?
<infinity> slangasek: Or, releasesigning, rather.
 * infinity asks a livefs builder.
<slangasek> that's an annoying failure mode.
<infinity> It's an annoying variable to have to set.  We used to have per-machine configs that got symlinked on LP rollout.
<infinity> Apparently, that was effort, so now it's all in variables in crontabs.
<infinity> And I weep.
<infinity> Okay, no failures yet, we'll call it good.
<infinity> On the plus(?) side, debian-cd seems to completely ignore sigs for alternates (this could really be seen as a bug), and just blissfully downloads unverifiable packages and re-signs them with the cdimage key.
<infinity> I guess if we don't have a trusted path to our own internal archive, we have bigger problems, but that still feels broken. :P
<infinity> It probably doesn't help that someone has LPCONFIG=ftpmaster in lp_publish's bashrc...
 * infinity fixes.
<infinity> slangasek: ^-- That should make it less error-prone, I hope. :P
<skaet> infinity, publisher crontab re-enabled?
<infinity> Maaaaybe.
<infinity> (apparently, yes)
<slangasek> infinity: heh, ok
<skaet> :)
<skaet> infinity,  am going to need to leave now for a while.
<infinity> skaet: Mmkay.
 * skaet passes baton to infinity to keep an eye on those images and bugs. 
<skaet> :)
<skaet> Thanks!
<sC> are the ubuntu studio images being respun again?  the beta images are showing a line through them in the QA website
<sC> argh
<ScottL> ah, better
<infinity> ScottL: Everything's being respun, yeah.
<charlie-tca> yes, all images are being respun
<ScottL> oh, okay...thank you
#ubuntu-release 2011-09-21
<infinity> Alternates re-spun, if someone who knows how the ISO tracker works wants to post them. :P
<stgraber> infinity: all of them or just ubuntu?
<infinity> stgraber: The whole shebang.
<infinity> stgraber: live/desktop/preinstall/whatever images are still grinding away, but alternates should all be ready.
<stgraber> ok, posting them on the tracker
<slangasek> are none of the live images done yet?
<stgraber> infinity: I'm guessing that includes server too. What about the omap and omap4 build for server, was that part of it too?
<stgraber> nevermind, I see them on cdimage
<stgraber> posting
<mdeslaur> bug 855171 may be worth mentioning in here
<ubot4> Launchpad bug 855171 in nss (Ubuntu) (and 1 other project) "libnss3.so went missing after upgrade (affects: 2) (heat: 12)" [Undecided,Confirmed] https://launchpad.net/bugs/855171
<stgraber> infinity: ok, I think I got them all, only left disabled on the tracker are the upgrades (not sure why so didn't re-activate), desktop builds and dvd builds
<slangasek> mdeslaur: can you attach an apt term.log, which is generally more usable than a dpkg.log?
<slangasek> (/var/log/apt/term.log)
<slangasek> the file's missing here too, how incredibly rude.
<slangasek> convenient that I hadn't rebooted yet, I guess
<mdeslaur> slangasek: attached
<slangasek> thanks
<slangasek> mdeslaur: do you know when you last had it
<slangasek> ?
<mdeslaur> I had it when I booted the laptop just before doing the dist-upgrade
<mdeslaur> so, whatever you see that's dated the 20th is when it happened
<mdeslaur> bbl
<slangasek> I am going to be annoyed if this turns out to be a knock-on effect of running update-ca-certificates
<slangasek> which is looking likely
<slangasek> yep
<slangasek> arrrgh
<doko_> slangasek, is there something wrong with java-ca-certificates update?
<slangasek> doko_: yes, the do_cleanup() function is nuking the system libnss3
<slangasek> doko_: can you have a look at it?
<doko_> slangasek, ok, first thing tomorrow morning. not now, just too tired
<slangasek> tomorrow morning is too late
<slangasek> if you're not free to do it now, that's fine; but this is eating users' systems in realtime
<slangasek> no nss3 == no network-manager
<doko_> gaah
<infinity> stgraber: Thanks.
 * infinity goes to make some food.
<doko_> slangasek, there was a suggestion to drop the libdir setting in nss.cfg. openjdk does have the multiarch path on the default libpath.
<slangasek> doko_: should we take this to #ubuntu-devel?  RAOF is also looking at it there, probably better to not have too many people working on it in parallel
<doko_> ok
<infinity> Failed to fetch http://ftpmaster.internal/ubuntu/pool/main/c/ca-certificates/ca-certificates_20110502+nmu1ubuntu2_all.deb  403  Forbidden
 * infinity blinks.
<infinity> slangasek: Did I miss a memo?
<slangasek> infinity: yes
<slangasek> look up
<infinity> Oh.
<infinity> Ugh.
<infinity> So, all these images are useless? :P
<slangasek> you can use them as virtual coasters
<infinity> I need a virtual microwave to make them crackly.
<stgraber> infinity: btw, you should now have admin rights on the tracker
<infinity> stgraber: Shiny, I suppose that means I'd need to learn how to make it go, then.
<infinity> Anyhow, with ca-certificates in standard, that invalidates every image except for core.  Woo.
 * infinity kills the builds that were in progress still...
<charlie-tca> ooops ;(
 * GrueMaster weeps for humanity
<slangasek> infinity: ca-certificates-java uploaded
<slangasek> infinity: please to reviewing
<slangasek> or if you prefer, I'll accept it myself (but then I should probably test it first)
<infinity> slangasek: I'll review when it lands..
<slangasek> so
<slangasek> ca-certificates-java doesn't affect all the images
<slangasek> but I think ca-certificates should gain a Breaks: on the old version of ca-certificates-java to enforce the upgrade in tandem
<slangasek> actually, Conflicts:
<infinity> Which then affects all images.
<slangasek> yep
<slangasek> infinity: you're holding the baton; what do you think?
<infinity> I think I have a date tonight, but the baton is relocatable. ;)
<infinity> I do think we should respin for it, though.
<slangasek> for -java, yes
<doko_> hmm, ca-certificates-java should only be on DVD images
<slangasek> -java tested locally, confirmed that I still have libnss3.so
<infinity> slangasek: I may be coming into this discussion late, but how is it ever a good idea (even with this lovely guard in place) for a random package to delete libraries?
<doko_> infinity, because it did create the link
<infinity> (The code looks to do what it wants to, though)
<infinity> doko_: Ahh, it's a symlink (or, it is when we want it dead)?
<infinity> A -L guard might have made that more obvious too.
<doko_> infinity, it's a hard coded value in nss.cfg, but we need it to run the update
<slangasek> doko_: it's on {kubuntu,ubuntu,edubuntu} DVDs and ubuntu-server, but the question is if we want to update ca-certificates as well for all the users who might have -java installed locally and be affected
 * infinity nods.
<slangasek> infinity: right, it's meant to only be cleaning up symlinks created in this same script
<slangasek> but it, ah, missed
<infinity> slangasek: Check.
<doko_> slangasek, if it's safer this way, fine
<slangasek> the damn thing is, I *saw* the ca-certificates-java error backtrace when I was preparing the ca-certificates update, and assumed it was an innocuous pre-existing problem... I should have followed up on that error earlier :/
<infinity> slangasek: I'm just going to go on record as saying that's one hell of an ugly and opaque shell script for something that appears to accidentally nuke files, but it looks like it should do what it says on the tin, so accepted.
<infinity> (Well, until the next time something weird happens)
<slangasek> infinity: thanks.  so, you still hold the baton, what would you like to do?  I can prep a ca-certificates upload with the Conflicts quickly enough...
<infinity> slangasek: Well, the conflict is sane anyway, I think.
<slangasek> and if you need to pass the baton off to me, I can take it
<infinity> slangasek: Personally, I think that warrants a rebuild.
 * slangasek nods
<slangasek> done then
<slangasek> since the breakage was introduced in a narrow range of versions in oneiric, I'll probably make it an == conflict to not complicate natty->oneiric upgrades
<infinity> slangasek: I already killed the arm builds, which take longer than everything else combined, so it's not like this makes things worse.
<slangasek> yep
<slangasek> ca-certificates uploaded
<infinity> slangasek: There was only one broken -java version?
<slangasek> infinity: in Ubuntu, yes
<infinity> Handy.
<slangasek> :)
<slangasek> publisher running
<slangasek> (or jogging in place)
<micahg> ^^ that can wait until after beta 2, it's an FTBFS fix, but part of the ubuntustudio packageset
<micahg> any objections from the release team for me to use the buildds for mozilla updates (all short ATM, will ask again before the long Firefox 7 ones)
<infinity> micahg: Any chance you can do them serially?
<infinity> I don't really feel like putting buildds on manual, not when I'm not sure how long I'll be up.
<micahg> infinity: the buildd manager will max out at 60% for the PPA
<micahg> so that's 1 for the 2 arch ones, 3 for i386
<infinity> When did this happen?
<micahg> *2 per arch
<infinity> Cause I've seen two ppa builds on the powerpc buildds before.
<micahg> infinity: a year or so ago?
<micahg> infinity: I'll only be using one PPA
<micahg> it's per PPA
<infinity> If you're sure you'll only eat one ppc buildd, go nuts. :P
<infinity> I wasn't aware of this new shiny.
<micahg> yeah, I'm sure :)
<infinity> Of course, the kernel ppa will come bite me anyway.
<micahg> I can't speak for the kernel team, anyways, my builds should only be 1.5 hrs at most on PPC
<micahg> infinity: and since I don't need them until next week, I won't be upset if someone kills it
<infinity> Mmkay.
<pitti> ah, seems the netsplit has been fixed, according to global notice
<pitti> jibel: so seems we can continue talking here
<pitti> jibel, ev, cjwatson: I debugged bug 854717 and suggested a workaround
<ubot4> Launchpad bug 854717 in ubiquity (Ubuntu Oneiric) (and 1 other project) "Broken panel icons and dialog style during ubiquity-dm and OEM install/final user configuration (affects: 2) (heat: 12)" [Critical,Confirmed] https://launchpad.net/bugs/854717
<ev> pitti: thanks! I'll make that change momentarily.  Reviewing your other patch now, though I don't think it's quite right. If you call stop_debconf while a page is running, you'll rip debconf from under its feet.
<ev> I'll have a think about it
<pitti> ev: right, I wasn't sure whether it's correct to call stop afterwards; but as it was stopped before, it seemed safer to stop it again
<pitti> unless it's safe to have it there all the tiem?
<pitti> ev: I'm reading i-power source right now
<pitti> ev: but it seems that i-power is pretty tightly woven to g-s-d's power plugin; unfortunately it doesn't use upower directly
<ev> and actually, I'll just disable that code path for now, as we're not actually using ubiquity/online just yet
<ev> okay
<pitti> so, it's still unclear why the earlier g-s-d fails to set the theme
<pitti> if I disable ubiquity-dm's g-s-d launching, I just have one, but it doesn't set the theme either, so it's not just a race between two gsd's
<seb128> pitti, is there anything in .xsession-errors? the usual reason is "there is a xsettings manager already running"
<ev> hmm
<pitti> seb128: partially; but see the bug trail
<seb128> pitti, which is what we had in natty where the gdm g-s-d was not exiting before the session one starts for some users
<pitti> seb128: /var/log/installer/dm doesn't have any messages about the g-s-d spawned by i-power
<pitti> presumably becuase it's dbus activated, and thus its stdout/err isn't connected anywhere
<pitti> which is a pity, as as it's a pain to see what's wrong with it
<seb128> well, feel free to ping jjardon about indicator-power questions
<seb128> he wrote it and he knows his stuff ;-)
<pitti> oh, yes
<seb128> he's on #ubuntu-desktop
<pitti> at the end of the day it seems to be a g-s-d problem, though
<pitti> the one spawned by i-power should be able to set the theme as well
<pitti> seb128: ^ or should it? does it need to be spawned by the session, or depend on environment variables?
<pitti> .. like the session dbus, perhaps?
<pitti> ah, no, it's spawned _by_ the session dbus, so that's definitively there
<seb128> pitti, I see no reason it should fail to set the theme
<seb128> it's basically just reading the gsettings value and applying the xsettings
<pitti> seb128: right; but it does
<pitti> so I think that's the root of the bug
<seb128> can you change g-s-d by a wrapper which call g-s-d 2>&1>/tmp/log or something?
<seb128> to get the g-s-d output
<seb128> bonus if you call it with --debug
<pitti> seb128: nice idea
<seb128> you might want to include the pid number of something in the log name if you have 2 g-s-d running
<pitti> I just patch away ubiquity's g-s-d spawning
<seb128> ok
 * pitti has become pretty used to break=casper-bottom, hacking up the root fs, and then booting :)
<seb128> ;-)
<pitti> ev: I love the "value set" window title of ubiquity :)
<ev> pitti: yeah, my most recent commit fixes that :)
<ev> yay copy and paste
<pitti> nice
<pitti> ev, seb128: ah, see https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/854717/comments/12
<ubot4> Launchpad bug 854717 in ubiquity (Ubuntu Oneiric) (and 3 other projects) "Broken panel icons and dialog style during ubiquity-dm and OEM install/final user configuration (affects: 2) (heat: 12)" [Critical,Confirmed]
<pitti> seb128: so, it seems that g-s-d stays running, but doesn't do anything when it can't register?
<seb128> seems like a bug, I would expect it to just exit
<pitti> seb128: but even if we fix that, indicator-power would just fail
<seb128> pitti, do we need indicator-power in the install mode?
<pitti> so a longer-term fix would be either to make i-power use upower directly (currently discussing with jjardon)
<pitti> or to start g-s-d earlier than the panel in ubiquity-dm
<seb128> I would go the g-s-d way
<pitti> seb128: not crucial I think
<pitti> seb128: but reading the g-s-d code it doesn't seem crucial that it registers; it should just go on
<seb128> it doesn't make sense to make efforts to write unity desktop code without GNOME
<seb128> i.e g-s-d is a basis desktop components nowadays we shouldn't try to fight to not have to use it, it's a waste of efforts
<pitti> ev: long story short, I think we can just disable libupower.so in panel.c for b2; does that sound ok to you?
<ev> pitti: works for me, will do now
<pitti> seb128: I was mainly curious, as I don't think the g-s-d plugin provides anything that upower doesn't
<pitti> seb128: and ubiquity-dm is a very case where we want the indicator without unity
<seb128> right, just convenient apis it seems
<pitti> seb128: I suspect that jjardon might have missed the existence of libupower-glib, though
<seb128> pitti, well, without unity yes, but maybe g-s-d can be running
<pitti> right, it should be running
<pitti> cf. the other solution I suggested
<pitti> start g-s-d, then the panel
<seb128> that would be my preferred solution
<seb128> pitti, libupower-glib, maybe he missed it, but why is g-s-d duplicating that logic rather than using libupower-glib as well?
<ev> right, uploading a new ubiquity now
<seb128> pitti, it's the same person who wrote upower, gpm and the gsd power code, there is probably a reason why it's done the current way ;-)
<pitti> seb128: g-s-d does use libupower-glib
<seb128> pitti, but anyway, not a topic for now and there, better to take that offline with jjardon
<seb128> pitti, well jjardon said the g-s-d code to copy would be non trivial so I assume it's not only a few calls to libupower-glib
<pitti> seb128: yeah, as I said this wasn't meant to be a blame or a bug, I was just curious why it's using g-s-d, as I didn't see a real reason to
<seb128> pitti, should be let some of small applications in if we are going to respin?
<seb128> things like eog, etc
<seb128> or better to after beta2?
<pitti> I let oneconf in, as this was small and focused
<pitti> but now we have about zero margin for errors :/
<seb128> ok
<pitti> seb128: if you have something in the queue which fixes a major bug and has a safe fix, that's fine
<seb128> checking the queue
<seb128> pitti, couchdb-glib would be nice
<seb128> it fixes contacts syncing I think
<pitti> hm, no bug for this?
<pitti> seb128: we won't respin alternates, BTW
<seb128> ok
<seb128> is couchdb-glib on the CD?
<seb128> no bug> hum, right, I just saw that rodrigo fixed it and chrisccoulson tested the fix yesterday
<pitti> seb128: ah, seems not; so shoudl be fine
 * pitti accepts
<seb128> danke
<seb128> pitti, everything else doesn't seem worth taking the risk
<seb128> so better to delay the others to after beta2
<pitti> *nod* thanks for checking
<pitti> ev: seems the window title fix is not in that upload?
<pitti> ev: if that's intended it's fine, the upload looks good; just wondering whether there was something wrong with a commit
<cjwatson> slangasek: ack, when my brain is working well enough to understand openssl code, I'll take a look
 * pitti accepts ubiqity, to give it a chance to build before the next publisher
<ev> pitti: the window title fix is not setting self.custom_title to the return value of self.db.set
<pitti> aah ;)
<ogra_> pitti, when did you start the armel builds (my log has a time skew and i need to know when i need to look after downloading them)
<pitti> hey ogra_
<pitti> ogra_: at 07:23 UTC, i. e. 09:23 CEST
<ogra_> thanks !
<pitti> ogra_: the first two builds are done, the second two are building
<ogra_> so its anothe 3-4h
<ogra_> yeah
<ogra_> its ~3h per arch
<pitti> after that I'll build server, then kubuntu
<ogra_> good
<pitti> ogra_: no, 1.5/2 h
<ogra_> then someone did something to the buildd :)
<pitti> ogra_: well, the second pair could very well take longer :)
<ogra_> it used to be 3h/flavour for two arches
<ogra_> so i assumed twice the time for 4 arches :)
<ogra_> indeed i'm happy if its faster ;)
<pitti> ogra_: yeah; what do we care if the builders sweat more now :)
<cjwatson> oh, whoops, I just accepted isdnutils and then realised it's in the ubuntustudio package set
<ogra_> well, i would love to have builders in the cluster that we can just randomly assign in situations like milestones :)
<cjwatson> hopefully we can disregard that for image preparation purposes; it was a build fix
<pitti> cjwatson: also, we don't currently plan to rebuild it
<pitti> but if ISDN stops working, nobody really should notice
<ScottK> pitti: I'd like to get kdepim-runtime in even if we can't get it on some/all Kubuntu images since it fixes a data loss bug.  I'd appreciate if you would review/accept.
<pitti> ScottK: looks fine, accepted
<ScottK> pitti: Thanks.
<pitti> ScottK: no worries, I can shuffle the build queue to build kubuntu a bit later, so that this has some time to publish
<ScottK> Great.
<pitti> ScottK: noted so on the pad
<pitti> at last! ubiquity 2.7.34
 * pitti starts the build queue of doom
<pitti> jibel: so what was the thing with the "total failure" you mentinoed this morning with the alternate CD? the tracker seems have successes?
<pitti> mvo, jibel: FYI, I just re-enabled the upgrade tests; should work better now with cups
<pitti> ogra_: desktop builds on the buildds just finished, BTW; sycamore took 4:15 hours in total, annonaceae took 3:40
<jibel> pitti, I re-ran all the tests both manually and automatically and it passed. I don't know what happened during the night, maybe an infrastructure or network  problem.
<jibel> I'll retry upgrades.
<ogra_> pitti, wow, thats a lot less than i expected (still way to long though, we will add more builds next release)
 * ogra_ waits for them to publish
<pitti> ogra_: they could be built on different builders perhaps?
<ogra_> we have two builders and four subarches
<pitti> ogra_: will still take a bit, cron.daily-preinstalled is running
<ogra_> we already share them between two machines, but i fezar we noeed more next release
 * ogra_ really doesnt want to hit 6h build times for one flavour 
<cjwatson> ideally we need something that doesn't involve code on antimony having to explicitly select a builder
<cjwatson> I'd rather have something that dispatches to an idle builder if available and sends us a completion indication when it's done (which we would probably just block on)
<cjwatson> in some ways it would be easier if livefses were actual LP build jobs
<cjwatson> that would be a big enough chunk of work to require escalation through LP stakeholders though
<pitti> ogra_: http://cdimage.ubuntu.com/daily-preinstalled/20110921/
<ogra_> yay
 * ogra_ syncs
<pitti> ogra_: will we release mx5?
<pitti> if so, we need a new product in the tracker, we only have imx51 (unless that's the same)
<ogra_> pitti, well, that rebuild was only for mx5 :)
<ogra_> i'll ask janimo, he owns mx5
<ogra_> i know we want to release it ...
<pitti> building server and kubuntu preinstalled now
<pitti> http://cdimage.ubuntu.com/daily-live/20110921.1/ published for testing
<pitti> jibel: can we rename "Ubuntu Desktop armel+imx51" to "Ubuntu Desktop armel+mx5"?
<ogra_> and there is janimo :)
<pitti> hello janimo, how are you?
<janimo> pitti, hi, should have the same type of testing as the omap flavours so wherever it fits in the iso tracker namespace
<pitti> janimo: is imx51 == mx5?
<janimo> pitti, mx5 is a more generic name for a kernel (and eventually image)
<janimo> that works with mx53 and the older mx51 too
<janimo> but for now we only test on mx53
<pitti> so I'll just add it as armel+imx51, and ask jibel to rename it in the DB
<janimo> pitti, what we test on now is imx53
<ogra_> well, the arch name is mx5
<janimo> imx51 is an older subarch
<ogra_> we usually use the subarch names
<pitti> jibel: right, but we only have an "armel+imx51" product; as I said, we ought to rename it in the db to match the image names
<janimo> ok
<ogra_> yeah, that should be fine
<pitti> janimo: thanks
<janimo> pitti, thanks for adding it :)
<ogra_> janimo, you will need a tracker account btw (since you will liekly want to note down test results)
<janimo> ogra_, I knew there was a trap somewhere when you asked whether I want it to be on the tracker :)
<ogra_> haha
<ogra_> yeah, it was a diplomatic trick ;)
<ogra_> but seriously, the person owning a subarch should indeed have a tracker account to note down test results :)
<janimo> I did not intend to own it, just for it to be on the tracker. But yes, I'll get an account
<ogra_> you should tell david :)
<ogra_> i think he assume you own it
<ogra_> *assumes
<janimo> well my panda is fried, I guess I was bound to get closer to my MX53
<jibel> pitti, I'd rather add a new product, it is a preinstalled image and test case is different from the former imx51
<pitti> jibel: ah, ok; do we already have defined test cases, or do we just copy the ones from ac100/omap?
<jibel> ogra_, is the testcase for mx5 http://testcases.qa.ubuntu.com/Install/ARM/PreinstalledImage like omap/ac100 ?
<ogra_> its the same desktoip testcase for all desktop images
<ogra_> (we dont build mx5 server or other images)
<pitti> jibel, janimo, ogra_: ok, I delete the imx51 image from the tracker then, don't get scared
 * ogra_ wont :)
<ScottK> Actually, AIUI our mx5 is mx53 only now, so calling it mx51 would be a mistake.
<jibel> added product ubuntu desktop mx5  and posted build 20110921
<pitti> jibel: cheers
<pitti> infinity, cjwatson, skaet: FYI, I just updated publish-image-set.py for the armel architecture list du jour, so please bzr update before you run this
<ScottK> pitti: Would you please sync thaweb 3.0.12-1 from Debian non-free.  There's an upload in queue that doesn't have origin set correctly and so I'd rather get it done as a proper sync.
<pitti> ScottK: ack
<ScottK> Thanks.
<pitti> ScottK: did you already reject it?
<ScottK> pitti: I did.
 * pitti can't see it
<pitti> ah
<pitti> ScottK: who requested it?
<ScottK> Just a sec
<cjwatson> pitti: ta
<ScottK> "Ø£Ø­ÙØ¯ Ø§ÙÙØ­ÙÙØ¯Ù (Ahmed El-Mahmoudy)" <aelmahmoudy@sabily.org>
<cjwatson> stgraber: is POSTing to /qatracker/admin/addbuild (including hardcoding/scraping of milestone and testcase numbers) still the best way for a client script to post new builds to iso.qa?
<pitti> ScottK: done
<ScottK> Thanks.
<lamont> cjwatson: mvo skaet: the current workaround for the archive slew is as follows:
<lamont> when ftpmaster triggers syncproxy, the mirroring script now waits 25 minutes after it finishes syncing before removing the lockfile, blocking any subsequent trigger for 25 minutes beyond the ~ 20 minutes it takes for the script to run.
<lamont> this sucks, but it at least means that the triggered mirrors get a chance to get a consistent copy in their rsync
<lamont> and gives us a little time to test and deploy something that will eliminate the slew entirely (COW is my friend)
<cjwatson> could be worse, as workarounds go.  thanks
<lamont> that was kind of the thinking
<lamont> but it does mean that if you're doing rapid & manual publisher runs, you can get out your marker and scratch out "rapid"
<lamont> sadly, this is all futurespeak, since the current run started before the change to the script
<cjwatson> You say that as if the publisher is likely to finish inside 25 minutes anyway
<lamont> heh
<cjwatson> I suspect what went wrong here was manual mirror triggers to force out ca-certificates munging
<cjwatson> lamont: and I guess http://archive.ubuntu.com/ubuntu/pool/universe/d/diffutils/diff_2.8.1-18_all.deb being AWOL is another instance of this?
<lamont> cjwatson: every instance will be one where there is a symlink between components
<lamont> and any of them has a reasonable liklihood of being b0rked
 * cjwatson nods
<pitti> ah, I guess that mirror desync might be why the current live builds are failing? (hash sum mismatch)
<lamont> pitti: verily
<lamont> pitti: and at this point, I'm forecasting that it'll all be better about 40 minutes after the current (10 min old) publisher run finishes on cocoplum
<pitti> lamont: that sounds fine, thanks; I'll just run the cron.daily-live's then
<cjwatson> verily> have I mentioned a friend of mine's suggestion for fixing the problem that True/False Yes/No etc. don't line up in source code?
<cjwatson> which was to use VERILY and NOWISE
<cjwatson> and this has the bonus that it allows for tristates: VERILY NOWISE MAYHAP
<lamont> cjwatson: LOL
<pitti> and OHCRAP for error conditions
<cjwatson> not quite in the right register, I feel :-)
<pitti> cjwatson: that must be from the FORTH age
<cjwatson> although I always liked dpkg's error function naming
<pitti> heh, yes
<pitti> fortunately few people ever see this
<cjwatson> ohshit for die-with-error-message; ohshite for die-with-error-message-and-errno
<pitti> http://cdimage.ubuntu.com/ubuntu-server/daily/20110921/ posted (including arm)
<pitti> Daviey: ^ FYI
<lamont> cjwatson: your last one violates your 6 character specification... maybe switch to latin?
<lamont> heh
<cjwatson> stgraber: oh, and do you think it's generally better to hardcode testcase numbers (e.g. 114) or testcase names (e.g. "Ubuntu Server EC2 EBS (Europe) amd64")?
<stgraber> good morning, sorry for being a bit late my ISP decided to change my IP and so I had to spend half an hour updating DNS/IPSEC/IPv6 so that I get something working again...
<stgraber> cjwatson: testcase number shouldn't change as often as the name. Using /addbuild is currently the best way of doing it when you don't have access to limequat.canonical.com
<cjwatson> just thinking of writing an autoposter for cdimage
<stgraber> cjwatson: otherwise, I guess we could run a small service on limequat that pushes new entries directly in the DB (with a small internal only service)
<cjwatson> I guess that means hardcoding a load of testcase numbers in cdimage code?
<cjwatson> presumably we should also have a role user for cdimage
<stgraber> why do you need testcase number? don't you just need product number and milestone number?
<stgraber> oh, nevermind just read the backscroll properly ;) you're indeed talking about product number (though as testcase number)
<stgraber> so yeah, using the product number "Ubuntu Alternate amd64" should be safe and a lot more readable
<cjwatson> it's called "isota_case"
<stgraber> these don't change too often and when they do, they're usually different enough that you'd want to check your code anyway
<cjwatson> but right, I mean products
<pitti> they just changed a few hours ago, btw (imx51 -> mx5)
<pitti> and we did some changes during beta-1, too
<pitti> publish-image-set.py has quite some bzr history for these
<doko> is heimdal on the images? or could it be approved? change to the -dev package only
<cjwatson> pitti: from cdimage's point of view, mx5 was already a different product from imx51
<cjwatson> and in that case, we got a new product number as well as a new product name, anyway
<cjwatson> so that's moot
<ogra_> ev, http://paste.ubuntu.com/694452/ any idea ? is it because we dont have an oem user on armel ?
<ogra_> (looks like it treis to query NM)
<stgraber> cjwatson: http://paste.ubuntu.com/694453/
<stgraber> cjwatson: I guess that's something I'd need to export whenever I get an API into that thing :)
<ev> ogra_: already fixed in the new ubiquity
<ogra_> bah
<ogra_> then thats not in the current armel build
<ogra_> pitti,^^^
<pitti> ogra_: erk, you need ubiquity on the preinstalled ones?
<pitti> ogra_: sorry, then we need a respin
<pitti> so far my mental model was "no ubiquity for preinstalled"
<ogra_> pitti, yes, all preinstalled (including server) use oem-config
<ogra_> which nowadays is ubiquity :)
 * ogra_ wonders who said we dont use it 
<pitti> there were cases of ubiquity bugs where in previous releases we didn't need to rebuild the armels
<pitti> but presumably because of bugs which didn't affect oem-config
<ogra_> yeah, but thats just because they didnt affect arm
<ogra_> or oem-config, right
<ogra_> the fun is that i just got a success report from a user for the same image
<ogra_> the error doesnt look like he could have gotten past it
<pitti> ogra_: it only crashes if you are offline
<pitti> if you are connected to a network, it works
<pitti> so it's quite possible
<ogra_> well, given i have wlan and it crashes before i get even access to NM ...
<ogra_> he might have a faster system (my rootfs goes to very slow USb media)
<pitti> I disabled the ubuntu desktop armels in the tracker
<ogra_> oh, i also noted that g-s-d got really really crashy on startup
<seb128> use apport and send a bug
<seb128> didn't get a g-s-d issue in weeks there
<ogra_> it had to do several attempts while i saw the generic theme and icons
<ogra_> eventually it started though
<pitti> ogra_: during oem-config, or the actual session?
<ogra_> i dont have that on my upgraded oneiric install
<pitti> ogra_: during oem-config> that was fixed
<ogra_> pitti, ubiquity-dm i think
<pitti> ogra_: yep, fixed in ubiquity .34
<ogra_> ah, good
<ogra_> so that last rebuild was kind of a waste of time :)
<ogra_> well, jani will probably disagree, at least we got mx5 images
<jibel> cjwatson, I already does the match here http://reports.qa.ubuntu.com/reports/isotesting/oneiric/report.html to track which image is ready for testing
<jibel> my problem was that limequat doesn't have access to people.canonical.com to discover which image is ready
<jibel> but if you can push a file to limequat with the flavor, buildnumber and name of the iso/image, it could be imported periodically and update the tracker.
<utlemming> skaet: can we add the latest Oneiric daily build to tracker? http://uec-images.ubuntu.com/oneiric/20110921.1/
<skaet> utlemming, ok, will do.
<utlemming> skaet: thank you kindly
<pitti> hey skaet
<skaet> heya pitti
<skaet> how go the builds?
<pitti> slowly :)
<pitti> skaet: mirroring problems, and general slowness of arms
<pitti> skaet: we had to do another ubiquity upload this morning
<skaet> pitti, yup,  etherpad let me see that.
 * skaet wonders why the pad won't let me see it after 10pm *shrug*
<pitti> skaet: builtin bedtime mode?
<skaet> pitti,  meh,  fustration mode is more like it.   :P
<skaet> ah well.
<skaet> pitti, so we have confirmation all the certificate issues have been resolved now?
<pitti> skaet: ca-certificates? we have a fix in the archive, but nobody said yet "yes, it's fixed now"
<pitti> that reminds me, someone else ran into that; didrocks, was that you?
<pitti> didrocks: libnss3 missing?
<cjwatson> >>> import isotracker
<cjwatson> >>> isotracker.product_code('Edubuntu DVD amd64')
<cjwatson> u'3'
<cjwatson> >>> isotracker.product_code('Edubuntu DVD i386')
<cjwatson> u'4'
<cjwatson> getting there
<didrocks> pitti: indeed, just had it
<pitti> didrocks: which versino of ca-certificates{,-java} did you upgrade from and to?
<didrocks> pitti: let me see what version I had before rebooting
<didrocks> checking
<stgraber> cjwatson: cool! once I've got some time to work on the tracker and get some kind of API implemented it should be quite trivial to just update that python module then
<skaet> stgraber, cjwatson.  :D  excellent news.
<stgraber> cjwatson: if you want a role account for cdimage, just register one on the tracker and let me know the username so I can make it an admin
<didrocks> pitti: so I booted successfully this morning (nss3 there). Then upgraded ca-certificates:i386 (20110502+nmu1, 20110502+nmu1ubuntu3) and ca-certificates-java:i386 (20110912ubuntu1, 20110912ubuntu2). After rebooting, no nss3
<pitti> didrocks: right, fix went into -java 20110912ubuntu3
<skaet> utlemming, http://uec-images.ubuntu.com/oneiric/20110921/ shows log.stdout.stderr - where do you want me refreshing the tracker from?
<didrocks> pitti: yeah, I updated it before rebooting in fact: ca-certificates-java:i386 (20110912ubuntu2, 20110912ubuntu3)
<didrocks> pitti: but I guess the file was already removed
<pitti> right
<pitti> if you install ubuntu2, you are doomed, I'm afraid
<didrocks> so can't really confirm the fix
<pitti> well
<didrocks> can try downgrading
<pitti> didrocks: you could downgrade to the old version
<didrocks> doing then
<pitti> then install nss3, and upgrade again?
<didrocks> downgrading ca-certificates-java to 20110912ubuntu1, isn't it?
<didrocks> then reboot, then upgrade to 20110912ubuntu3
<pitti> yeah
<didrocks> andd check the file
<didrocks> doing
<pitti> shouldn't really need a reboot
<pitti> just reinstall of nss3
<utlemming> skaet: http://uec-images.ubuntu.com/oneiric/20110921.1/  -- you're missing the .1
<didrocks> pitti: reinstalled is already done, otherwise, I won't be online :)
<skaet> utlemming,  thanks!
<utlemming> skaet: :)
<cjwatson> is it just me or is iso.qa refusing connections right now?
<stgraber> cjwatson: works here
<Laney> wfm
<pitti> oh, look! mirrors work again, ubuntu DVD built
<pitti> ^ lamont :)
 * pitti builds the other missing live images then
<didrocks> pitti: works here, still have the file after the upgrade
 * didrocks updates the bug
<lamont> pitti: cool
<cjwatson> works now for me, must have been transient
<Daviey> cjwatson: it was done for a period, along with all the other sites on the box
<cjwatson> ah
<skaet> utlemming, ok should be published.
<pitti> http://cdimage.ubuntu.com/dvd/20110921/ posted
<jamespage> are there current/outstanding issues with archive mirrors?  I'm seeing 403 errors on all ec2 regions during litmus testing prior to testing 20110921.1
<Daviey> 403?!  That is unrelated to the other issues,  i believe
<Daviey> I suspect the ec2 mirrors are just broken.
<cjwatson> Daviey: same thing I believe; alternates between 404 and 403
<cjwatson> jamespage: I think this is what lamont has been working on
<jamespage> cjwatson: OK - I'll hold off the full test and can re-run the litmus test as and when required to validate its good
<Daviey> cjwatson: ah, ok.
<lamont> jamespage: I'm going to guess you don't want to wait up to 3 hours for that,right?
<jamespage> lamont: not really
<jamespage> the full test run takes another 1.5 hours after tha
<jamespage> so if we can get it fixed now that would be great
<jamespage> :-)
<pitti> ogra_: staring new ubuntu preinstalled build
<pitti> "starting", too
<ogra_> thx
<lamont> jamespage: triggered all 5 regions.  they'll come current sometimeish
<jamespage> lamont: thankyou
<pitti> http://cdimage.ubuntu.com/xubuntu/daily-live/20110921.2/ posted
<charlie-tca> Thank you
<pitti> http://cdimage.ubuntu.com/mythbuntu/daily-live/20110921.1/ posted
<pitti> http://cdimage.ubuntu.com/lubuntu/daily-live/20110921.1/ posted
<cjwatson> is there a product I could harmlessly post something to on iso.qa for testing?
<pitti> cjwatson: ubuntu netbook perhaps?
<cjwatson> anyone object to that?
<cjwatson> I guess it might cause some spurious mails; I'd like something nobody is subscribed to
<pitti> cjwatson: Netboot arm imx51 perhaps?
<cjwatson> stgraber: is anyone subscribed to ^- that?
<stgraber> cjwatson: checking
<GrueMaster> Probably me.  Filters activated.  Fire at will.
<pitti> http://cdimage.ubuntu.com/kubuntu/daily-preinstalled/20110921/ posted
<pitti> nice, after hours of waiting they now come in in hordes
<jpds> Poor will.
<stgraber> cjwatson: two users are subscribed, checking who they are
<stgraber> cjwatson: GrueMaster and plars
<cjwatson> ok, I guess they can both cope
<GrueMaster> plars likes mail.  Have fun.
<cjwatson> GrueMaster: can you let plars know to ignore this?
<cjwatson> excellent, that worked
<cjwatson> $ ./post-image-to-iso-tracker.py 'Ubuntu Netbook armel+imx51' 20110921
<GrueMaster> yes, I'll ping him.  Or can you just unsubscribe him?
<cjwatson> I already posted and have removed it agan
<cjwatson> *again
<cjwatson> committed to ubuntu-archive-tools; hopefully I haven't broken post-amis-to-iso-tracker.py
<stgraber> cjwatson: yeah!
<pitti> http://cdimage.ubuntu.com/kubuntu/daily-live/20110921.1/ posted
<cjwatson> skaet: do you want to specify exactly when cdimage should auto-post images to the tracker?  you suggested that it should post an image that was marked rebuilding, but I wonder if perhaps we should be posting anything during certain time periods, or something like that
<skaet>  cjwatson,  yeah, we should probably all come up with some heuristics.   certainly when the iso-tracker is primed for a release (ie. switched over to beta 2 from beta 1),  might be part of the heuristic
<skaet> I figured it it was marked for rebuild it was obvious something was expected, and a change was expected.
<skaet> One thing I'm worrying about is an image gets built and "stomps" on something that wasn't expected to be updated.
<cjwatson> mm, cdimage doesn't really know whether isotracker's default release is an imminent one or not
<cjwatson> yeah
<cjwatson> experimental builds
<skaet> indeed.   maybe just keeping it when the tracker is expecting a build for now?   Then work on some heuristics together either on list, or at UDS?
<cjwatson> maybe just a CDIMAGE_POST_QA environmenet variable?
<skaet> that could be an option too.
<cjwatson> if you set to non-empty, the image gets auto-postd
<cjwatson> since all of these builds are getting done manually anyway
<cjwatson> you have to remember to unset it at the end of a build pass
<skaet> yeah, that could work.   remembering to unset it though could be triggered by the release being done?
<cjwatson> can't see how that could unset environment variables in people's shells :-)
<skaet> ah yeah, I was thinking it might be something on cdimage - but that's not what is happening today. :)
<GrueMaster> What is the status of armel rebuilds?  I heard earlier that we were respinning (yet again) due to oem-config issues?
<pitti> GrueMaster: it's running
<pitti> GrueMaster: kubuntu and server are already up to date and in the tracker
<GrueMaster> ok.  kubuntu is low on my list, but will pull separately for testing.
<pitti> GrueMaster: pad and tracker are both up to date
<cjwatson> phew.  are we still going?
<cjwatson> oh, blast, echan
<pitti> cjwatson: we are still going as well, anyway :)
<pitti> skaet, infinity: as noted on the pad, kubuntu DVD, edubuntu DVD, and ubuntu preinstalled images are currently building, the rest is built/published
<pitti> no known blockers/breakage
<pitti> skaet, infinity: can I hand over the baton back to you? I'd like to go to Taekwondo this evening
<pitti> already skipped on Monday, and I can really use some exercise, I think :)
<skaet> pitti,  thanks.   yes,  baton accepted.  :)
<pitti> skaet: can you add the images to the tracker as they come in? kubuntu ETA 10 mins, edubuntu ETA 30 mins, ubuntu preinst ETA 3 h
<skaet> pitti, sure will do.
<skaet> pitti,  by the way,  the latest updates seem to resolve most of the crashes I was seeing yesterday.  \o/
<pitti> thanks; good night everyone!
<pitti> skaet: nice
 * skaet reinstalling natty now, and trying to do upgrade from there. 
<pitti> skaet: oh, kubuntu DVD just coming in, adding
<pitti> infinity: will you do the pre-publishing later today, when some u/k desktop images testing results?
 * pitti waves
 * skaet waves back to pitti
<infinity> pitti: Been a while since I did that, but I'm sure I can dust off the skills.
<cjwatson> are there any install-from-USB test reports on the tracker?
<jamespage> lamont, all regions aside from us-east-1 now look OK
 * lamont takes a quick peek
<charlie-tca> So, after all that time, software center did not get the fix for Xubuntu. It is unusable by Xubuntu users in Oneiric.
<cjwatson> mvo: ^-
<cjwatson> urgh, bits of iso.qa are painful to screen-scrape
<cjwatson> like the front page
<infinity> charlie-tca: What's wrong with it in Xubuntu?  Not that I use SC, but starting it up, it seems fine...
<infinity> (Other than being unthemed because it's GTK3, and I'm using a GTK2-only theme...)
<charlie-tca> in a fresh install with the latest images, it crashes
<mvo> charlie-tca: its waiting in the queue
<charlie-tca> It will not start
<infinity> Weird.  I wonder why it works here.
<charlie-tca> mvo: I know
<charlie-tca> but I would have thought after waiting all night for images, we might have gotten it in
<charlie-tca> infinity: it will not start at all, 32bit and 64bit installs on hardware
<skaet> mvo,  is that what's fixed by the new update-manager that's just gone on the queue?
<mvo> skaet: u-m is a different fix, its not urgent (at all)
<skaet> mvo,  thanks.
<infinity> skaet: This is software-centre we're talking about.
<infinity> I wish someone had told me how broken it was yesterday, I would have pushed it through before the last world rebuild. :/
<charlie-tca> The best I could suggest now is updates, since I am running out of hours already to get things tested.
<skaet> infinity:  gotcha.
<charlie-tca> I have to plan 6-8 hours for all the images
<infinity> charlie-tca: Updates?
<charlie-tca> yeah, sudo apt-get dist-upgrade right after installing?
<infinity> Oh, yeah.
<infinity> I thought you meant "oneiric-updates", and I was about to point out that this is a beta, not final. :P
<charlie-tca> sorry, bad wording
<infinity> But yes, SC broken on Xubuntu probably isn't the end of the world for a beta, just unfortunate.
<infinity> And not install-path-critical, so yes, updating tomorrow would fix it.
<charlie-tca> I agree, and we still include Synaptic Package Manager by default, too.
<utlemming> Automated testing for cloud-images is currently blocked due to EC2 mirrors in US-East being out. IS will be looking at that shortly.
<skaet> ScottK,  kubuntu dvd posted
<jamespage> utlemming: just testing again now
<jamespage> utlemming: https://jenkins.qa.ubuntu.com/job/oneiric-server-ec2-adhoc/ looking OK now
<jamespage> will kick off the full run
<skaet> mvo, jibel - fresh update from natty is stumbling into crash on update.  Can anyone else confirm?
<skaet> (issue is gnome-settings-daemon crashed with SIGSEGV in g_simple_asynch_result_complete())
<charlie-tca> yup
<charlie-tca> confirmed on Xubuntu, bug 832603
<ubot4> Launchpad bug 832603 in gnome-settings-daemon (Ubuntu Oneiric) (and 2 other projects) "gnome-settings-daemon crashed with SIGSEGV in g_simple_async_result_complete() (affects: 601) (dups: 75) (heat: 2762)" [High,Triaged] https://launchpad.net/bugs/832603
<jibel> skaet, bug 832603
<jibel> skaet, excuse my slow brain. charlie-tca was faster
<utlemming> jamespage: thanks for kickign testing again
<skaet> :)
<jamespage> utlemming, np
<skaet> jibel, charlie-tca - thanks.
<jamespage> if we see specific issues with mirrors we can always re-run tests individually
<skaet> jibel, charlie-tca - have marked mine as a duplicate of that one then.
<cjwatson> I have a cdimage patch to do iso.qa posting based on an environment variable, but I guess I should hold off until after beta-2
<cjwatson> besides, pretty much EOD now anyway
<skaet> stgraber,  edubuntu dvd posted
<stgraber> yeah!
 * stgraber startings zsyncing
<ScottK> Are the current Kubuntu desktop/alternates ones we want testing on?
<highvoltage> stgraber: I've been meaning to ask, when you removed some of those gnome admin packages, did you remove the slides too or are they still there?
<ScottK> It looks like desktop is current.
<cjwatson> skaet: oh, hmm, when rebuilding an image whose hash matches something on the iso.qa list it would probably be helpful to automatically mark it as rebuilding, right?
<cjwatson> well, if we're going to post a new one anyway
<skaet> cjwatson,  yeah that would be very helpful indeed.
<stgraber> highvoltage: removed the slides too
<highvoltage> ah great
<ScottK> skaet: Is there any image building going on right now?
<infinity> All I see building is some arm preinstalled images.  But I'm not sure what others have been up to.
<ScottK> ev: Bug #855763 looks like it's exploding almost exactly where you changed stuff in the last upload.  Ideas?
<ubot4> Launchpad bug 855763 in ubiquity (Ubuntu) "installer crashed (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/855763
<ev> ScottK: just fixed on trunk.  Apols for that.  I did test the KDE frontend stuff, so I'm baffled as to how that slipped through.
<ScottK> ev: OK.  I just confirmed it.
<ScottK> I guess we'll need an upload and respins for it.
 * GrueMaster hears the word "respins" and cringes.  No armel desktop testing has happened since Beta 1.
<ScottK> skaet: ^^^ That's a blocker.
<ScottK> GrueMaster: You don't use Ubiquity do you?
<GrueMaster> oem-config
<ScottK> Oh.
<GrueMaster> Which is part of ubiquity.
<ScottK> Yeah.
<GrueMaster> And I'm still waiting on the last desktop respin to finish.
<skaet> ScottK, ack.
<ScottK> skaet: While we're waiting for that, Kubuntu alternate respins would be nice to pick up the kdepim data loss fix if there's builders available.
<skaet> ev, can we live with just respinning the Kubuntu images?
<GrueMaster> Guess I can do a netboot install and start testing from that.
<skaet> ScottK,  ok, will kick it off now.
<skaet> ScottK,  just to double check which package version should the data loss fix be in?
<ScottK> skaet: 4:4.7.1-0ubuntu3.
<ScottK> I checked and it's already on the dvd/desktop images (not that that helps)
<skaet> ScottK,  ok, its kicked off.   Will look for it in about 30 minutes.
<slangasek> GrueMaster: if it's a matter of you being blocked on doing any smoke testing of ARM images, we can certainly make sure that we get some images out for you to test even if we know they won't be final for beta-2; would that help?
<slangasek> (I believe ubiquity is currently in a consistent state in the archive, so we shouldn't have to worry about that breaking the actual image building)
<GrueMaster> slangasek: There are images being built now.  It just takes several hours between respins.
<GrueMaster> And as I said, worst case I do a netboot install and revert to app testing.
<skaet> GrueMaster, per pitti's estimate,  the images should be emerging from the builder shortly.   Will flag you directly as soon as I spot them.
<GrueMaster> Thanks skaet.
<skaet> ScottK,  kbuntu alternates (20110921) posted.
<ScottK> Thanks.
 * skaet drums fingers waiting for arm builders....
<micahg> skaet: am I ok to upload some mozilla builds now to the security PPA?
<skaet> micahg, as long as they can be killed off if testing throws up a blocker.
<skaet> esp on the arm side.
<micahg> skaet: yep, no problem (don't need the arm/powerpc until next tuesday)
<micahg> the others are fine to kill as well if needed
<skaet> micahg, ok.
<micahg> these are still <1hr except on armel though, I'm still waiting on the firefox 7 builds and will check in again before uploading those (4.5hr+ on every arch)
<ScottK> The armel rebuild test is done, so getting armel builders should be less of an issue than it has been recently.
<micahg> yeah, half of them are free ATM
<infinity> GrueMaster: I see some new daily-preinstalled images.
<infinity> GrueMaster: Yeah, all 4 look there.
<GrueMaster> ok.  Pulling.  Hope the bandwidth is decent this time.  Last pull took 4 hours.
<infinity> skaet / slangasek : Are we headed into another respin cycle here soon?  Looks like ARM's previous run is all done, so we have stuff to smoketest.
<skaet> infinity,  GrueMaster - just posted the latest images fresh off the ARM builders to the iso tracker.
<infinity> Oh, looks like we still need a new ubiquity?
<slangasek> sounds like it
<slangasek> ev: you said the kubuntu fix is on trunk? Are you preparing an upload today?
<infinity> In that case, can we pull in software-center to make Xubuntu happy? :P
<slangasek> sounds appropriate to me
<skaet> infinity, we can pull in software-center.   Just not sure if charlie-tca will have bandwith to test the updated image.
<infinity> zsync is a beautiful thing.
<infinity> Well, when it works.
<GrueMaster> I'm still wondering what the last respin was about.  I have the 20110921 desktop running on panda and while there are visual glitches, it is running smoothly.
<skaet> re: ubiquity,  can it just be a kubuntu spin,  or is there a need for all the images.   It wasn't clear to me.
<stgraber> isn't the new ubiquity a kde-only fix?
<infinity> GrueMaster: Sanity respin, since ubiquity keeps getting revved, probably.
<skaet> stgraber,  that was my understanding.
<infinity> And an LP timeout.  Twice.
 * infinity goes to accept the old fashioned way.
<infinity> There.
<slangasek> hmm, was ubiquity in the queue already? I didn't see it
<infinity> charlie-tca: software-center accepted, BTW.  Xubuntu respins, yay?
<infinity> slangasek: No.
<skaet> slangasek,  ev:  please post scope of respin when its known.   My preference is to just redo Kubuntu unless compelling reason otherwise.
<stgraber> skaet: there's also a fix for bug 848000 in the branch but I wouldn't think it's worth rebuilding for that
<ubot4> Launchpad bug 848000 in ubiquity (Ubuntu) "Shouldn't show "should be plugged in" when on a desktop (affects: 1) (heat: 6)" [Low,Fix committed] https://launchpad.net/bugs/848000
<slangasek> infinity: so it's the software-center that you accepted?
<infinity> slangasek: Yeah.
 * skaet looking
<charlie-tca> o
<stgraber> skaet: so current ubiquity trunk contains: bugfix for bug 848000 and bug 855763 + a new unit test
<ubot4> Launchpad bug 855763 in ubiquity (Ubuntu Oneiric) (and 1 other project) "installer crashed (affects: 2) (heat: 10)" [Critical,Confirmed] https://launchpad.net/bugs/855763
<infinity> charlie-tca: Your o is missing the \/ around it.  Armless man cheering?
<charlie-tca> I would go with skaet on this
<infinity> charlie-tca: Oh, as in you don't have time to test the fix you wanted? ;)
<charlie-tca> If we need to respin, gereat1
<charlie-tca> if not, I would wait
<infinity> charlie-tca: We're respinning some/all anyway for ubiquity.
<charlie-tca> okay
<infinity> charlie-tca: So... You get software-center. :P
<charlie-tca> go for it, then
<charlie-tca> Yay!
<skaet> charlie-tca,  :)
<slangasek> skaet: the usual compelling reason is to have consistency between the images and the archive at the point of the milestone; I also see a fix for bug #848000 on trunk, which benefits Ubuntu but isn't a major issue.  The fix for bug #855763 definitely only affects KDE.
<ubot4> Launchpad bug 848000 in ubiquity (Ubuntu) "Shouldn't show "should be plugged in" when on a desktop (affects: 1) (heat: 6)" [Low,Fix committed] https://launchpad.net/bugs/848000
<ubot4> Launchpad bug 855763 in ubiquity (Ubuntu Oneiric) (and 1 other project) "installer crashed (affects: 2) (heat: 10)" [Critical,Confirmed] https://launchpad.net/bugs/855763
<infinity> slangasek: I'm pretty anal about the consistency thing, but I'll concede that since we don't snapshot the archive for pre-release milestones, it's not like it actually matters either.
<slangasek> skaet: if we're pressed for time on testing and don't want to respin the world, kubuntu-only respins are viable here
<infinity> Well, I may have just committed to Xubuntu too. ;)
<skaet> slangasek,  ok will definitely mark down kubuntu and xubuntu for respin when the ubiquity lands.   I'd like to get a read from jibel on testing impact before those get posted.
<slangasek> infinity: right; it's annoying to not be able to use jigdo for milestone alternates, but the window when you can do that is diminishingly small anyway
<infinity> slangasek: Well, it's also good practice for "real" releases.  Saying "we don't have time to test X again, so let's no refresh the image" is not the right answer. :P
<Daviey> people use jigdo?
<skaet> re: read from jibel, is whether he has bandwidth to do a retest on ubuntu images in time as well.   Will build them after kubuntu and xubuntu, and then hold off on posting.
<infinity> Daviey: With a local mirror, it's insanely nice.
<Daviey> infinity: with a *local* mirror, wget should be pretty damn fast :)
<stgraber> skaet, slangasek: want me to upload the current ubiquity? not sure if ev is still around
<infinity> Daviey: Well, yes.  Hence why jigdo's awesome.  (As in, I keep a local package mirror, but not ISOs)
<charlie-tca> I only have one desktop test done anyway
<slangasek> Daviey: a local package mirror doesn't making wget'ing of images fast
<slangasek> stgraber: yes please
<Daviey> oh. i thought infinity was talking about a local iso mirror.
<infinity> Daviey: Local ISO mirroring is just insanity unless you're a QA dude who tests every day.  *glances at GrueMaster*
<skaet> stgraber,  what slangasek said.  and thanks!
<Daviey> infinity: Last cycle, i did rsync the server iso's daily.. but not bothered this cycle.
<stgraber> ubiquity uploaded. Generating the debdiff locally shows a change in d-i/source/tzsetup/debian/common.templates (included source package), wiped my local copy of d-i/source/ and re-updated it and it's still there, so I guess that was a problem in a previous upload
<skaet> stgraber,  thanks.   slangasek, can you review?
<slangasek> looking
<slangasek> do we want the one from 6 minutes ago or the one from 11 minutes ago?
<skaet> stgraber, ^^
<infinity> The one with .gitignore vomit all over it seems suspect.
<infinity> And yet, that's the newer one. :)
<infinity> slangasek: gitignore aside, without a response from stgraber, I'd be inclined to take the newer one, since it only addresses the bugs and doesn't randomly regen/change a debconf template.
 * stgraber goes to look at the queue
<stgraber> hmm, weird, I didn't see evan's upload in the branch
<slangasek> it wasn't there when you uploaded... his is the newer upload
<stgraber> I think it'd be best to go with my upload so that it matches what's in the branch
<slangasek> stgraber: hmm, I've just accepted ev's because as infinity says, random changes to debconf templates are troubling
<slangasek> especially unreviewable ones like changes to a 2000-item list
<stgraber> stgraber@arkose-tmpW3TJ50:~/data/code/ubiquity$ md5sum current-tz/tzsetup-0.26ubuntu10/debian/common.templates ubiquity/d-i/source/tzsetup/debian/common.templates tmp/ubiquity-2.7.34/d-i/source/tzsetup/debian/common.templates
<stgraber> 533f96595d0e372bf970dce026f5add8  current-tz/tzsetup-0.26ubuntu10/debian/common.templates
<stgraber> 533f96595d0e372bf970dce026f5add8  ubiquity/d-i/source/tzsetup/debian/common.templates
<stgraber> 2b607e6faffa4794d6aa284435a32822  tmp/ubiquity-2.7.34/d-i/source/tzsetup/debian/common.templates
<stgraber> first one is the md5 of that debconf template from tzsetup itself, second is the ubiquity on my system (the one I uploaded earlier), third is the one in the last ubiquity upload (evan's system)
<stgraber> not sure if there's any potential impact, but "mine" seems to be the right one
<slangasek> stgraber: well... too late to un-accept :/  could you fix up the branches so that it gets properly imported on the next upload?
<infinity> So, speaking of not respinning for package consistency.
<stgraber> the included sources aren't in the branch but on the uploader's system (you basically need to run "fakeroot debian/rules update" to get them, then run debuild -S -sa to build the source package).
<infinity> Who feels good about a no-change rebuild upload of nss, just to force updates on poeple who lost their libraries?
<infinity> skaet / slangasek ^
<stgraber> ev: ^ (apparently you've got something weird in d-i/source)
<skaet> infinity, am not sure about the implications of that.   what is scope of rebuild needed?
<infinity> skaet: Well, if we don't care deeply about the images and the archive having identical package versions, it means little to beta, really.
<infinity> skaet: But the version rev will force an update on people who had their libnss3 library deleted by ca-certificates yesterday, without them having to hunt for support, manually download a package, etc.
<micahg> I'd actually like to update nss before final, but was going to bring that up after release tomorrow
<infinity> micahg: Well, there still seems to be a bit of a support panic with people who have no idea WTF has gone wrong.  A quick version bump would kill a lot of that.
<slangasek> infinity: if there's enough noise about it to be on your radar, I think a no-change rebuild of it would be best
<micahg> infinity: yeah, I'm ok with that, was just thinking out loud, sounds like a no change rebuild wouldn't be so bad(it's pretty fast too)
<infinity> Yeah, it's speedy.
<skaet> infinity, ok by me then.
<infinity> I'll just bump it now.
<jbicha> I think it breaks network-manager so people might have to chroot anyway or use a wired connection but it seemed better to tell people to upgrade than to go find a .deb to install
<slangasek> jbicha: the point is to get it to the archive so that it fixes itself for users who haven't already rebooted
<jbicha> slangasek: yes :)
<infinity> Uploaded.
<charlie-tca> skaet: release overview updated for Xubuntu
<skaet> thanks charlie-tca
 * infinity daringly accepts his own upload.
 * Daviey watches the world implode.
<stgraber> wow, I didn't remember the qatracker module being such a mess ;) spent the last 30 minutes porting it from the current Drupal 4/5-ish code over to Drupal 7 and it finally loads though will need all of the DB interaction rewritten
<stgraber> considering how easy it's to write a Drupal 7 module, I might just as well rewrite it, keeping the DB as it's (that part was easy to port)
<skaet> ScottK,  do you want the Kubuntu ARM images rebuilt?
<ScottK> No.
<skaet> okie,  just checking.
<ScottK> I doubt anyone is using kmail on armel and I'm sure GrueMaster has enough testing to do already without me adding to his trouble.
 * GrueMaster twitches.
<doko> skaet, would you mind, if I set the milestone 11.10 for ftbfs issue for packages in universe which are in package sets? (5 packages)
<skaet> doko, for 5 packages, sure
<lamont> skaet: slangasek: so about this publisher thang...  I'm trying to understand why, if we publish hourly, we get publisher triggers for archive on syncproxy every 30 minutes
<lamont> and more to the point, I'd like to see that timeframe doubled for at least a little while
<slangasek> lamont: ask the LP folks?
<slangasek> lamont: it's really "every 30 minutes", not "twice back-to-back in a publisher run"?
<lamont> it's one crontab entry that triggers at 03 * * * *
<lamont> so yeah, I'll go ask the lp folks
<slangasek> Daviey: hmm, you guys opted not to do the FFe for qemu-kvm?  I guess that means I'm on my own for sorting out qemu-linaro then? :)
<lamont> the issue right now is that every other sync request causes ZOMG email to all of us and gets dropped on the floor... so... yeah
<slangasek> lamont: yeah, we don't exactly control the contents of that cronjob
<slangasek> as in, I can't even work out where the actual code for the cronjob is without hurting my brane
<skaet> lamont, any options for improving this part of the cycle would be very welcome.
<slangasek> lamont: well, I take that back.  looking at publish_ftpmaster.py, I do see that we're calling runFinalizeParts() twice, once for the "quick" security sync and once for the full-distro sync.  The first one should be a very small sync; is the problem we're having that it isn't?
<slangasek> lamont: should /srv/launchpad.net/codelines/current/cronscripts/publishing/distro-parts/ubuntu/finalize.d/90-trigger-mirrors have different handling based on SECURITY_UPLOAD_ONLY?
<slangasek> (if so, what should the difference be?)
<slangasek> ^^ makes gtalk plugin work on amd64
<skaet> stgraber, do you want edubuntu added to the respin list?
<stgraber> skaet: yeah, still have plenty of time to re-test, so let's be up to date!
<skaet> stgraber, ok, adding in.
<skaet> anyone else what the latest ubiquity?
<infinity> lamont: That's two triggers from the same script.  I'm sure I've answered this before...
<infinity> lamont: And it's been like that for years.
<infinity> slangasek: Making it not trigger on sec_up_only sort of defeats the entire purpose of the quick-turnaround security run. :)
<slangasek> infinity: unless the mirrors lamont is having problems from are not the mirrors used for mirroring security?
<infinity> slangasek: Well, everything passes through syncproxy.
<infinity> slangasek: And I have a sneaking suspicion that's where the angry mails are coming from.
<slangasek> infinity: does it?  There are three mirrors being triggered in that script
<slangasek> I don't know which machine does what, but there's clearly more than one
<infinity> Everything public-facing passes through syncproxy? :)
<slangasek> ok
 * skaet waiting on built ubiquity 2.7.35 to show up on archive now.... speaking of mirrors. 
<infinity> Everything but armel should be fine.
<skaet> builds started for all except armel.   see pad for details.
<skaet> thanks infinity
<infinity> skaet: Just desktop CDs, I hope?
<infinity> skaet: (Well, if you were basing it on ftpmaster having the files you wanted)
<skaet> infinity, yes, just desktop cd/dvds (see pad).   waiting on armel.
<infinity> Oh, did I miss the memo on DVDs no longer being live/alternate hybrids?
<infinity> (Let me guess, that changed 3 years ago, and I wasn't paying attention)
<slangasek> it changed this cycle
<skaet> :)
<lamont> slangasek: its archive and security mirrors that are affected by the issue
<slangasek> lamont: ok, well, see infinity's comments... the double-pulse per hour is expected then due to the security "quick-run".  If that's not actually serving the intended function, it's easy enough for LP to disable the extra pulse and just do it all in one go...
<slangasek> see also the discussion elsechan of whether there's cruft on the filesystem that needs cleaning up
<infinity> lamont: Yeah.  We can disable the quick sec run.  Though there was a valid reason for it (not wanting to have to wait 45 minutes to push out something that's actually critical)
<slangasek> however, if overlapping runs means you're usually waiting 1h15 instead, there's a clear lesser evil
<infinity> lamont: There's also the part where IS has been laughing at LP for 6+ years about the publisher being so slow that it can't run twice an hour like dinstall did.  Might not want to lose face there. ;)
<infinity> (no pressure)
<lamont> slangasek: having LP disable it for the rest of oneiric would probably be best
 * lamont must run for a while
<skaet> ScottK, kubuntu daily-live  20110921.2 posted
<skaet> charlie-tca, xubuntu desktop (20110921.2) posted
<charlie-tca> skaet: that was there hours ago, already
<charlie-tca> It was posted when infinity called for the respin
<stgraber> charlie-tca: 21.3 just got appeared
<charlie-tca> That's what I was looking for
<charlie-tca> Thank you both, it is getting complicated now
<stgraber> charlie-tca: I guess you want 20110921.3 on the tracker right?
<charlie-tca> yes, I think so. That's the one we were waiting for
<stgraber> ok, added
<charlie-tca> thank you
<stgraber> skaet: updated TechnicalOverview. I'll ask highvoltage to check I didn't forget anything.
<ScottL> skaet, i'll get the technical overview tonight, i promise ;)
<skaet> Thanks stgraber,  ScottL.  :)
<skaet> charlie-tca,  sorry 21.3 is what I was looking at and then posted 21.2.   Thanks for fixing stgraber!
 * skaet figures its time got go get some dinner...
#ubuntu-release 2011-09-22
<charlie-tca> no problem, skaet
<charlie-tca> I just had to make sure we get the latest one to sync
<skaet> :)
<skaet> ubuntu desktop 20110921.2 posted
<skaet> stgraber, am stepping away for dinner... (really this time),  edubuntu's currently on the builder so should emerge next.
 * skaet --> dinner, biab
<stgraber> skaet: ok
<highvoltage> stgraber: didn't we also get a newer gbrainy?
<highvoltage> or is that still in ubuntu by default? even if it's still included in ubuntu by default, it's not explicitely mentioned there so perhaps we should
<highvoltage> (I updated the page)
<skaet> stgraber, highvoltage  new edubuntu dvd (20110922) posted
<ScottK> skaet: Thanks.
<skaet> ScottK, kubuntu dvd's building now,  will be next out
<ScottK> OK.
<highvoltage> thanks skaet
<skaet> :)
<highvoltage> stgraber: can you bring those images that you downloaded to the office tomorrow? it will be faster for me to sync from them than from my old ones
<charlie-tca> and the software center fixed worked. and the images are working
<stgraber> highvoltage: sure, I'll have them both on my laptop in the next 10 minutes or so
<stgraber> highvoltage: tech overview looks good, thanks for the changes
<GrueMaster> skaet: Ubuntu-armel omap/omap4 testing is finished.  I'm leaving the ac100 to ogra and the mx5 to janimo.  Downloading kubuntu omap/omap4 images now, hope to post results in the next couple of hours (slow download).
<skaet> GrueMaster,  ok.   There are about to be a new set of images for arm emerging from the builders.   Do you want me posting them?
<GrueMaster> Ugh, why?
<skaet> GrueMaster, ubiquity fixes.
<skaet> just a sec.
<GrueMaster> If the sole purpose is to be in sync, then no.  I didn't run into issues with this batch of images.  Or are these kubuntu images?
<skaet> it was primarily for kubuntu,  https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/855763
<ubot4> Launchpad bug 855763 in ubiquity (Ubuntu Oneiric) (and 1 other project) "installer crashed (affects: 3) (dups: 1) (heat: 18)" [Critical,Fix released]
<skaet> but there was another minor fix that was made at the same time
<skaet> We don't have kubuntu arm images built with the fix,  but if you want them, I can add them to the queue.
<GrueMaster> So, these images are kubuntu only?
<skaet> images coming off are ubuntu right now (with kubuntu fix) for consistency.
<skaet> infinity, NCommander - won't be updating the ARM images on the iso tracker based on GrueMaster comments ^^.
<GrueMaster> Problem I am having is it is taking me hours to download each image respin, even with zsync.  If I have to test them, I will, but it will take a while.  No guarantees on getting them done before 9am PST (1500 UTC).
<skaet> GrueMaster.  understood.  Will let NCommander and infinity voice an opinion if they disagree, otherwise we'll go with what you've tested.
<GrueMaster> So, was kubuntu being respun with these fixes?
<skaet> GrueMaster, no it wasn't.  ScottK didn't indicate it was needed,  but if your testing indicates it does.  let me know ASAP.
<skaet> I'll be monitoring this channel and will start a spin off.
<ScottK> GrueMaster: I'm willing to defer to your judgement (and availability to retest, so no one with omap/omap4 has appeared)
<ScottK> GrueMaster: If the right answer is respin and release Kubuntu images late after you get a chance to test, I'm fine with that too.
<GrueMaster> ScottK: I am still pulling down the images.  zsync was a bit behind on my side, and I'm currently looking at ~1-2 hours before I can test 20110921.
<ScottK> OK.
<skaet> ScottK, GrueMaster - once the ubuntu arm images come off the builder, I'll proactively start off a Kubuntu set, so the option will be there later tonight.
<skaet> your choice or not, to pick it up.  ie. if sniff test yields problems pick up the latest, and get someone awake to post to iso tracker.
<GrueMaster> skaet: Sounds good.  Can we keep all of these respins in reserve, just in case we don't need them?
<skaet> exactly
<GrueMaster> ok
<skaet> ScottK,  kubuntu DVD 20110922 posted
<ScottK> Thakns.
<ScottK> Thanks even
<skaet> :)
<skaet> ubuntu dvd 20110922 posted
<stgraber> 80% of the way through porting qapkgstatus (status.qa.ubuntu.com) to Drupal 7, the code is a lot cleaner, safer and faster :)
<stgraber> once I'm done with that one I should be familiar enough with Drupal 7 to port the qatracker relatively easily (still expect it to take a week or so to actually do it)
<GrueMaster> ScottK: Testing kubuntu now.  Had a failure on beaglexm (omap) and it seems to have recovered.  No failure on panda (omap4) so far.  May not need the respin.  Will let you know more details on beaglexm as soon as I can.
<ScottK> Thanks.
<GrueMaster> Beaglexm may be memory related as we apparently turned off making a swap file some time ago.  Could be hitting oom issues.
<GrueMaster> As soon as I created a swap file on the beagleXM, the loadaverage started dropping from 4.95 (now around 2.08 and slowly dropping) and swap usage shot up to over 200M.
<skaet> GrueMaster, ScottK,  I've started off the kubuntu arm rebuilds IF you need them.   Should be a couple of hours before they're available.
<GrueMaster> Ok, this may be interesting.  The beagleXM oem-config crash on initial boot is the same as bug 855763, but I didn't see it in omap4.
<ubot4> Launchpad bug 855763 in ubiquity (Ubuntu Oneiric) (and 1 other project) "installer crashed (affects: 3) (dups: 1) (heat: 18)" [Critical,Fix released] https://launchpad.net/bugs/855763
<GrueMaster> Doublechecking logs on omap4 now.
<skaet> GrueMaster, infinity, NCommander, ogra_  - the ubuntu arm pre-installed images are publishing now,  should be available IF you need them under 20110922.
<GrueMaster> Nope, not seeing it on omap4, which is odd.
<GrueMaster> skaet: Thanks.
<GrueMaster> I don't think we will (and with current download speeds I am seeing, they wouldn't be available to me until well after midnight my time).
<GrueMaster> As to kubuntu-armel, I don't know what to say.  On omap, I see the bug, on omap4 I don't.  I'll compare manifests to see if they match.
<skaet> GrueMaster,  ok.  Sorry about the download speeds. :P
<GrueMaster> Both match.  Not sure what to think now.
<GrueMaster> Meh, not your fault.  When you have a popular product...
<GrueMaster> :P
<GrueMaster> Other than the results I have already posted, I haven't seen any other issues.
<GrueMaster> On the kubuntu installer bug, I only saw it on beaglexm and it recovered without issue.  Didn't see it on omap4 (Panda).  I don't think a respin is necessary.
<skaet> fair enough.   ok,  I think we have the image set we'll be going with on the iso tracker unless jibel raises some flags in the morning.
<skaet> pitti,  when you get in, could you go ahead and pre-publish the current images?
<skaet> pitti, do NOT update the iso tracker to the latest ARM (ubuntu and kubuntu pre-installed) images, looks like tonights builds of them won't be needed.
 * skaet --> time to go do the zzz thing.
<skaet> g'nite all.
<GrueMaster> Night skaet.
<pitti> Good morning
<pitti> hey skaet
<pitti> skaet: eek, we forgot to do that? doing right now then, we'll have to do a release very late then
<pitti> skaet: arm images> understood
<pitti> infinity: we have a script "publish-image-set.py" now which figures out all the commands for you, feeding from teh tracker
<pitti> infinity: still awake by any chance?
<pitti> there is a lubuntu 20110921.2 build, but tracker has 20110921.1
<pitti> is that intended?
 * pitti also runs cron.source now, it takes ages
<pitti> infinity, skaet: images prepublished
<pitti> now let the world mirror
<stgraber> ok, finally got Drupal 7 to authenticate against LP and grant access rights on my local ISO tracker based on team membership! that's it for tonight, see you all tomorrow.
<pitti> sleep well, stgraber
<ScottK> GrueMaster: I get a crash in oem-config too (on i386).
<ScottK> pitti: Kubuntu i386 alternate is out of date for ubiquity.  The impact is Bug #855763 is still present and so oem-config fails.  I don't think it's worth a respin, but that image won't have oem-config.
<ubot4> Launchpad bug 855763 in ubiquity (Ubuntu Oneiric) (and 1 other project) "installer crashed (affects: 3) (dups: 1) (heat: 18)" [Critical,Fix released] https://launchpad.net/bugs/855763
<pitti> ScottK: ok, so we'll release-note that this image won't have oem-config?
<ScottK> Yes, unless there's some other reason to respin.
<pitti> ScottK: at this point, do you still see anything in the Kubuntu images which might need a respin?
<pitti> looks like edubuntu images didn't get any testing yet
<pitti> so better not unfreeze just yet
<pitti> s/unfreeze/flush the queue/
<pitti> (I just learned we are going to stay frozen)
<infinity> pitti: I didn't pre-publish earlier because there was still respinning going on, and then I had to go out. :/
<pitti> infinity: ah, np; we'll just have to do the release a little later in the day
<pitti> infinity: at some point today we need to decide when we are at the "point of no return" for flushing unapproved; I think due to untested edubuntu that we are at that point yet, but I hope we can get some tests today
<pitti> we shouldn't flush unapproved on a friday
<infinity> pitti: Friday's the best time to do everything!
<pitti> I'm accepting cogl; it'll land in binNEW, so doesn't affect images
<pitti> I want to get it built now, so that the other stuff in the queue can already build against it (see bug 856179)
<ubot4> Launchpad bug 856179 in mutter (Ubuntu) (and 6 other projects) "[FFe] cogl 1.8.0 with soname bump (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/856179
<pitti> jibel: bonjour
<jibel> pitti, good morning
<pitti> jibel: do you guys test edubuntu as well, or is that done by stgraber only?
<pitti> jibel: apparently there was a late respin last night
<jibel> pitti, stgraber does it, I can help after ubuntu.
<pitti> jibel: wuold it help if I downloaded the kubuntu amd64 image and test that a bit (which will take a while), or is that part of your automatic setup anyway?
<pitti> it has zero results right now, and thus I'm a little worried
<jibel> pitti, that would help. We only test ubuntu automatically
<jibel> I've a couple of bugs to file against ubuntu and I can start testing derivatives in half an hour or so.
<pitti> jibel: ok, then how about you start with edubuntu after ubuntu, and I'll test kubuntu amd64 now
<jibel> pitti, ok
<pitti> ok, first kubuntu amd64 desktop install finished, looking good
 * jibel starting edubuntu i386
<pitti> infinity: still online or asleep?
<pitti> ok, kubuntnu desktop amd64 5/7 pass; can't test wubi, haven't tested netbook
<pitti> (although kvm also just has 768 pixels in height)
<jibel> pitti, I'll try wubi and netbook after edubuntu. Kubuntu DVDs pass
<jibel> edubuntu i386 + LTSP: pass
<pitti> yay
<jibel> stgraber, I fail at LTSP live, networl-manager tries to manage the secondary interface and shuts it down before the client connects.
<jibel> *network
<ScottK> pitti: As of when I went to sleep, I wasn't aware of any show stoppers for Kubuntu.
<pitti> ScottK: ah, good; I just tested the amd64 desktop one, and it works just fine
<ScottK> Great.
<pitti> one nitpick is that oem-install mode doesn't install missing langpack
<pitti> s
<pitti> but that applies to ubuntu just as well, I figure
<jibel> pitti, same on ubuntu.
<jibel> and there's a problem with the language selector notification when a language is incomplete after installation too. I'll troubleshoot after B2.
<pitti> cjwatson: so it seems our b2 images are as good as they are going to be
<pitti> jibel ^ any remaining major bugs which have a chance of being fixed?
<cjwatson> I'll take your word for it - I've been somewhat out of it this milestone cycle (illness + ADSL problems)
<pitti> uh, get well soon then!
<pitti> (both you personally and your interweb tube)
<pitti> cjwatson: I'm a bit anxious to review/clean unapproved, there's quite some fixes there, and I wouldn't want to flush the whole thing on a Friday
<ScottK> I think it would be good for someone to check and see if Bug 856055 is just me/my system or a general problem.
<ubot4> Launchpad bug 856055 in memtest86+ (Ubuntu) "Memtest run from DI installer menu never finishes (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/856055
<pitti> and it requires some coordination for the cogl binNEW
<ScottK> pitti: We've got one more week between Beta 2 and final this time, so no rush.
<cjwatson> the engineer reckons ADSL is fixed now (and it does look better), and I think the cold is subsiding too
<cjwatson> pitti: I can certainly help with unapproved today
<cjwatson> ScottK: ok
<pitti> I missed last week's meeting due to holiday, but I understand that we'll remain frozen for the whole remaining oneiric time?
<cjwatson> so I understand
<pitti> that's going to be a lot of handholding, but oh well
<ScottK> We are.
<pitti> ScottK: I suppose that shouldn't be different between u/kubuntu? I can test the current memtest on my 10v here
<ScottK> pitti: It'd be really odd if it were different.
<jibel> pitti, no major bug that could be fixed and tested in the next hours.
<ScottK> I'd be curious how long it takes to run if it does.
<pitti> erk, confirmed; no progress at all
<ScottK> OK.
<ScottK> That's probably worth a release note.
<pitti> I'll try on my workstation, brg
<pitti> brb even
<ScottK> Looks like amd64+mac testing is minimal this time.
<ScottK> (for multiple flavors)
<pitti> ScottK: works fine on my X201
<cjwatson> works in KVM
<pitti> so we can representatively claim that it is broken on 33% of systems out there :-P
<ScottK> OK.  Hardware specific then.
<pitti> oh, "Informations"? must have been a German who wrote this :)
<pitti> although I've heard it from other people as well
<ogra_> hmm, so oem-config doesnt get removed after install
<pitti> you and your weird singular forms!
<ogra_> Sep 22 12:20:32 localhost ubiquity: debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable
<ogra_> hmm, i guess thats the issue
<ogra_> everything else in the log looks fine
<pitti> ScottK: release ntoed
<ScottK> Thanks.
<pitti> ogra_: in my recent kubuntu desktop oem install mode that worked, neither oem-config nor ubiquity are installed
<jibel> ogra_, similar symptoms then bug 349469
<ubot4> Launchpad bug 349469 in debconf (Ubuntu) "debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable (affects: 523) (dups: 396) (heat: 3404)" [Medium,Triaged] https://launchpad.net/bugs/349469
<ogra_> pitti, well, 820514
<ogra_> bug 820514 even
<ubot4> Launchpad bug 820514 in ubiquity (Ubuntu Oneiric) (and 1 other project) "oem-config-remove-gtk not found during preinstalled desktop initialization (affects: 1) (dups: 1) (heat: 18)" [High,Incomplete] https://launchpad.net/bugs/820514
<ogra_> but that doesnt seem to be actually my issue
<ogra_> pitti, your bug talks about people using two package managers at the same time ... i dont even have access to a package manager in ubiquity-dm :)
<ogra_> thats an ubiquity homemade issue i think
<pitti> "my" bug?
<ogra_> 349469
<ogra_> oh, sorry, that was jibel
<pitti> ah
<cjwatson> jibel: please don't do "similar symptoms" with that class of bug
<cjwatson> it's not worthwhile and is confusing
<cjwatson> because the symptom is "two things tried to talk to debconf at once", and that doesn't come anywhere close to uniquely identifying a cause
<jibel> cjwatson, understood.
 * ogra_ files bug 856293
<ubot4> Launchpad bug 856293 in ubiquity (Ubuntu Oneiric) (and 1 other project) "oem-config not removed after install on preinstalled desktop images due to debconf.dat being locked (affects: 1) (heat: 6)" [Medium,New] https://launchpad.net/bugs/856293
<jibel> wubi is broken on kubuntu. filing a bug.
<ScottK> Except for desktop amd64+mac, I'm pretty comfortable with where Kubuntu is.
<pitti> edubuntu seems fine, too
<pitti> and ubuntu
<pitti> xubuntu almost complete, mythbuntu has a successful test, lubuntu complete
<pitti> I think we can call these "beta-2" and start reviewing unapproved to unblock further development
<pitti> cjwatson, ScottK, jibel ^ any objection?
<ogra_> arme seems fine as well
<ogra_> *arm even
<pitti> ogra_: is the oem-config removal bug a race condition, or reproducible? if so, should we release-note it?
<ogra_> pitti, we could, it happened every time i tested ac100 but i dont have any debug data
<ogra_> apart from that one debconf.dat line there is nothing in the logs
<pitti> ogra_: does the installed system actually work? I suspect it breaks late enough that the only effect is the extra packages
<ogra_> right, i even guess apt-get autoremove would wipe them
<cjwatson> I don't see anything on the iso.qa bug list that I consider a showstopper
<cjwatson> so no objection from me
<pitti> ok; I'll start with some "safe" ones, just in case
<pitti> like clutter, which is only on xubuntu, and not being used for anything but quadrapassel (the game)
<ogra_> oh, i think mx5 shouldnt be released, that waits for a missing kernel config option
<ogra_> (working fine beyond that, but not supporting ext4 when the images default to it is somewhat a showstopper :) )
<pitti> heh
<pitti> ogra_: ok, I'll remove it from the tracker then?
<pitti> so that publish-image-set doesn't pick it up?
<ogra_> ah, i thought it need to be on the tracker
<ogra_> i exoplicitly asked jani to add it, if publish-Ã¶release depends on it though, yeah, remove it
<pitti> cjwatson: FYI, please keep apt in the queue for now; I accepted pkgbinarymangler which blacklists libapt's translations, that should publish first
<pitti> ogra_: not "depend", it'll just publish everything which isn't disabled in the tracker
<ogra_> ah
<pitti> ERROR: Cannot handle image Ubuntu Core armel (20110920.1)
<pitti> oops, I guess that needs fixing, too
<ogra_> hmm, i thought adam had added that last milestone
<cjwatson> pitti: OK
<pitti> fixed in ubuntu-archive-tools
<cjwatson> pitti: I asked for that apt upload so I do want it fairly soon mind :-)
<pitti> cjwatson: if it's urgent, we can also do another rebuild after wards
<ogra_> pitti, where do i find ubuntu-archive-tools (for the next time we add a new image format) ? is that publically accessible fro non ubuntu-archive people ?
<cjwatson> nah, xdeb isn't release-critical in any sense
<cjwatson> ogra_: bzr co lp:ubuntu-archive-tools
<ogra_> thx !
 * ogra_ suspects it will not know about .bootimg files yet
<ogra_> ah, it doesnt look at file suffixes at all
<cjwatson> pitti: are we holding off on kerneloops for a bit?
<pitti> cjwatson: disabling it seems a little premature to me
<cjwatson> right
<pitti> not sure whether the kernel team actually wants to have it stopped already, apw?
<pitti> ogasawara: ^
<pitti> ok, 'nuff staring at diffs for nwo
<pitti> I accepted everything which I trust enough to not break another image build
<cjwatson> I'm still going, I'll deal with the rest
<pitti> also, I want pkgbinarymanger and vala-0.14 to publish first
<cjwatson> ah, heh, I did accept a couple of vala packages ...
<pitti> there are some valaish things in the queue which I'd rather build against the current one, just to ensure that they don't ftbfs or so
 * cjwatson will avoid those for a while then
<pitti> cjwatson: ok; no worries, it didn't change syntax or abi or anythign, it was just being cautious
<cjwatson> gnome-games and libgee
<cjwatson> yeah, probably best leave most of the rest for now then
<cjwatson> the buildds have plenty to chew on
<pitti> heh, was just gonna say
 * pitti takes a break, lawn needs mowing, and seems we are finally out of catastrophes \o/
<cjwatson> actually I think I'll accept binutils too: it looks safe, fixes build failures, and shouldn't break anything if skewed
<pitti> cjwatson, infinity, skaet: FYI, my cron.source run finished, so that will be fine for publishing
<stgraber> jibel: hmm, that's ltsp live from Edubuntu's DVD?
<cjwatson> pitti: good
<jibel> stgraber, yes, full installation + ltsp passed with the same network setup.
<stgraber> jibel: that's really weird that network manager even tries to touch the interface post-install as the installer generates a /etc/network/interfaces entry for it
<stgraber> jibel: oh, ok, I see, post-install is fine but not live
<stgraber> jibel: let me try it here quickly, I didn't see any problem yesterday...
<jibel> stgraber, yes post-install is fine but not live
<ogasawara> cjwatson, pitti: precedence in previous releases indicated we've turned off kerneloops around beta-2 so I told bdmurray to go ahead and disable it
<Laney> charlie-tca: I guess bug #836324 is a P-thing now?
<ubot4> Launchpad bug 836324 in blueman (Ubuntu) "FFe: Sync blueman 1.22~bzr707-1 (universe) from Debian experimental (main) (affects: 1) (heat: 17)" [Wishlist,New] https://launchpad.net/bugs/836324
<ScottK> pitti: Sounds fine.
<stgraber> jibel: LTSP live seems fine here. An "LTSP" connection gets added and set to the interface selected in the LTSP live dialog, once the dialog disappears I can boot a thin client just fine.
<stgraber> jibel: Just checking, did you use the LTSP live configuration dialog (from the launcher) and selected the right network interface (eth1 in my case), then waited for it to disappear? at this point Network Manager should be happy with both interfaces connected...
<stgraber> jibel: unless you're testing on real hardware with a crossover cable, then Network Manager won't like the interface link state changing 10 times during the thin client boot
<jibel> stgraber, I used the LTSP live from the launcher but the dialog never disappeared. When I select eth1 (which is the internal NIC) it changes back to eth0. I'm trying again.
<stgraber> jibel: oh, that's weird. How much RAM do you have on that system?
<jibel> stgraber, 1G, what's the minimum requirement ?
<stgraber> jibel: with LTSP, usally 768M though we recommend 1G so you should be fine
<charlie-tca> Laney: why? we can't do an FFe now?
<Laney> You want to change defaults this late? Also, no progress on the requested testing.
<charlie-tca> We may have to change defaults this late, since at this late date, Xubuntu has no bluetooth
<Laney> well, consider this a poke then :-)
<charlie-tca> Thank you. I do appreciate that.
<ogasawara> cjwatson, pitti: after chatting with bdmurray I'm fine if we hold off on disabling kerneloops until around final freeze
<ScottK> Laney: Did you request the monodevelop-* syncs?
<Laney> not me guv'nor
<Laney> probably directhex
<ogasawara> cjwatson, pitti: I assume it can just be held in the queue or bdmurray can re-upload
<ScottK> Ah, no.
<Laney> but I think we want them. Is there a problem?
<ScottK> Yeah.  It was.
<ScottK> Do they need an FFe?
<Laney> nafaik
<ScottK> Something like 2.6-1 sounds like a new feature release, but OK.
<cjwatson> ogasawara: holding in the queue should be fine
<ScottK> Just checking.
<Laney> I think we had the prereleases before
<ScottK> Accepting based on "Laney said so."
<Laney> yeah, 2.5.92 â should be bug fixes then
<Laney> ta
<ScottK> OK.  Done.
<ScottK> pitti: The LO update looks non-trivial, so if it's going in, I think sooner better than later (and no, that doesn't mean I'm volunteering to review it).
<pitti> ScottK: yes, I agree; I just didn't want to block the buildds with it just yet
<pitti> ogasawara: understood, thanks
<ScottK> OK.  Makes sense.
<ScottK> BTW, I have a tester lined up for Kubuntu amd64+mac, so we may get to release those.
<ScottK> powerpc has no tester ATM, so that's a no go for us.
<pitti> hello skaet, good morning
<skaet> good morning pitti.   :)
<pitti> skaet: so, images look fine, and we started flushing unapproved
<skaet> yup, spotted that surge.
<pitti> skaet: so, bug 856405 might require some further explanation
<ubot4> Launchpad bug 856405 in ubuntu-meta (Ubuntu Oneiric) (and 1 other project) "Add Ubuntu One packages back to default install and CD (affects: 1) (heat: 8)" [High,New] https://launchpad.net/bugs/856405
<pitti> skaet: I'd like to do the seed changes now and upload -meta, so that these packages will be on tomorrow's CDs again
<chrisccoulson> pitti - gnome-settings-daemon uploaded :)
 * chrisccoulson waves goodbye to several seconds of startup time :)
<pitti> skaet: in short, there was some back and forth with the U1 team, and they tried to introduce the concept of the u1-installer
<pitti> skaet: but all it does is to just install the very packages that we have shipped in natty and before
<pitti> skaet: so we don't have these in the default install and in the live session for testing them, for no good reason
<pitti> skaet: so we had a phone call last week to clarify what the purpose of these was, and it turned out that it was something between mis-communication, the installer concept not being finished yet, and us wanting them back
<pitti> skaet: I was part of the call and have argued for putting them back for weeks, so I feel too biased to making the call now
<ScottK> Seems to me like they should either go back right now or not at all.
<pitti> yes, that was my thought
<pitti> was too late for b2 unfortunately
<Laney> ho boy
<pitti> but many people (including desktop team) have htese packages installed all the time anyway
<Laney> do we revert the disabling U1 patches?
<pitti> Laney: what do you mean?
<Laney> for example the banshee extension was on the CD by virtue of a recommends
<ScottK> I'm not unbiased either as I think integration of proprietary web services isn't appropriate for the default install (I lost that argument long ago), so I'm not one to express an opinion for either way either.
<pitti> Laney: it'll be put back through seeds; does anything need to be patched for this? that'd be strange
<pitti> as software should certainly work with the package being installed right now, too
<Laney> no, seeding will work
<Laney> why would you do that rather than having banshee recommend it again though?
<pitti> Laney: doesn't matter much, but explicit seeding seems cleaner to me
<pitti> also, it avoids having to change packages for this
<pitti> also, makes it easier for derivatives to not ship it, etc.
<pitti> (cf. ScottK's argument above)
<pitti> Laney: so by "patch" you meant the Recommends: removal, not source patch?
<Laney> yeah, "change", whatever you want to call it
<pitti> ah, ok
<skaet> pitti, sorry for the pause,  am checking some things.
<stgraber> skaet: Edubuntu looks good to go. Only bug that was found is a ltsp-live problem that jibel found, can't reproduce it for now, will start poking at it now.
<Laney> looks like some U1 stuff was re-seeded a few days ago anyway?
<skaet> pitti,  agree with you and ScottK,  if its going to go in,  best now.    What will this do to the image space?  (ie. what's going to drop off?)
<pitti> skaet: nothing; it's 360 kB
<skaet> pitti,  goodness.
<pitti> skaet: would you mind sending your formal +1 to the bug, so that we have a paper trail? I just sent my view of the regression potential, etc.
<Laney> or supported-desktop-extra is just to keep stuff in main?
<skaet> pitti,  will do.
<pitti> skaet: that's what I meant with "there was no reason to drop them" :)
<pitti> Laney: righht
<pitti> Laney: I'll drop it from there again, for cleaning up the redundancy
<Laney> ack
<Laney> I'm a bit surprised that there was a miscommunication though; the intention seemed quite clear
<skaet> pitti, which seeds will be getting the change?  (CD, DVD, ...)  is it going to go on the ARM ones?
<pitti> skaet: it's "desktop", so all ubuntu ones: desktop, alternate, preinstalled, DVD
<pitti> skaet: doesn't affect any of the derivatives, they have their own seed
<skaet> pitti,  ok, just wanted to check if it was going to be consistently applied, so am fine.
<ScottK> dnspython and iotop have an FFe that needs review/approval: Bug #856478
<ubot4> Launchpad bug 856478 in iotop (Ubuntu) (and 1 other project) "FFe: Let's get python-support off of ScottK's server (affects: 1) (heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/856478
<pitti> ScottK: just accepted
<pitti> erm, approved
<ScottK> Cool.
 * pitti likes the bug title
<ScottK> python-central is already gone.
<skaet> pitti,  comments added.
<pitti> skaet: ah, thanks; -meta uploaded now
<pitti> skaet: will we have a meeting tomorrow?
<ogra_> oh, gooood question :)
<pitti> (not that I'm pushing for one, I'll have a holiday)
<skaet> pitti,  yes there will be a meeting tomorrow.
 * skaet started on the agenda for it yesterday.  
<skaet> pitti,  who's rep from desktop then?
<pitti> skaet: seb128 kindly stepped up for questions, etc.
<pitti> skaet: I updated https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus with the report, RC bugs, etc.
<skaet> pitti,  could you take a pass at the desktop bugs in http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-mgr-o-tracking-bugs.html,  and make sure you agree that those listed under the desktop team make sense to be.   I'll cross check with your DesktopTeam/ReleaseStatus later, after the release is out.
<skaet> also,  check you agree with the priorities on the desktop ones too.
<pitti> skaet: I did actually, most of them are mentioned on our report page
<skaet> pitti,  :)  goodness.
<skaet> thank you.
<Daviey> slangasek: Hmm. Just seen your qemu question..  Are you still planning to do it for qemu-linaro?
<slangasek> Daviey: well, I may have mentioned earlier that I was hoping to piggy-back onto your FFe so I didn't have to do the paperwork ;)
<Daviey> Whilst the testing proved that it was a viable candidate, we really don't have the time to dedicate to fixing to fallout if it goes bang.
<Daviey> For something so core to the server product.
<slangasek> I think an update for qemu-linaro would be the best course of action, but I'm not sure we get enough benefit for me to justify going through a proper FFe
<Daviey> slangasek: so myself and hallyn did use it from a PPA for over a week, and it did look good.
<Daviey> Nothing obviously regressed.
<slangasek> Daviey: does that mean if I proposed a qemu-linaro new upstream version for FFe, you would approve it with your ubuntu-release hat on without me going through the upstream changelog?
<ScottK> Suddenly the downside of being on the release team emerges ...
<ScottK> ;-)
<slangasek> well :)
<slangasek> he doesn't need to sell *me* on the update, after all :)
<ScottK> No, I was thinking for him.
<ScottK> Now he's got to sit there and make a decision ...
<infinity> Decisions before noon are hard.
<Daviey> slangasek: I did go through the changelog, and there are a few nice new features.
<Daviey> One reason i was keen for us to consier it - is that t is most likely the release for the LTS.. whilst it's bad karma to test drive it in a release, for server LTS, it would have been useful.
<Daviey> </selfish>
<Daviey> It's had very little exposure in Debian, with rc2 still in experimental and nothing in Sid.. didn't hep confidence.
<Daviey> hallyn, our qemu guru wouldn't have been able to dedicate time to fixing an explosion.
<Daviey> ... not to mention, everything is broken enough already :)
<slangasek> sure, I understand
<slangasek> but for qemu-linaro, what do you think?
<Daviey> slangasek: I don't think that is a bad idea, really.  I don't know that people use qemu-linaro for anything other than experimetal stuff, do they?
<slangasek> it's used for all the arm emulation people are doing
<Daviey> As in, is it at the core of anyones deployment?
<slangasek> certainly not "experimental" - but probably development-only
<Daviey> Yeah.. That sounds like a reasonable target audience to through something less tested, than the rest of it.
<Daviey> Perhaps i'm being maverick.
<Daviey> slangasek: I wish there was a 'decent' qemu-system-arm machine, something with plenty of RAM.
<Daviey> Using it during this cycle, all the options seemed to be balancing fail.
<slangasek> I personally only use it in user emulation mode
<slangasek> because the system emulation overhead is irrelevant for my needs
 * Daviey continues going OT, and asks if upstart works with tat now.
<slangasek> no idea
<cjwatson> speaking of late updates, what do people think about a significant xdeb update?
<cjwatson> http://paste.ubuntu.com/695191/ so far
<cjwatson> I haven't actually checked but I have a rather strong suspicion that it's basically busted in oneiric right now anyway
<cjwatson> and AFAIK it's only used by a small community of people working on cross-building, who want to be current anyway
<slangasek> cjwatson: yeah, I think xdeb is an easy decision on that basis
<Daviey> cjwatson: universe and popcon is reporting 153 installs.
<slangasek> if the new version works for the 4 people using it, we should take that one :)
<stgraber> Daviey: you mean running upstart using qemu's userspace emulation?
<stgraber> Daviey: if so, it doesn't and very likely won't for quite a while still
<cjwatson> Daviey: boggle
<cjwatson> that's 149 more than I expected
<Daviey> stgraber: tah
<stgraber> Daviey: that's because upstart uses ptrace() to follow the forks of the process and qemu-arm uses ptrace to catch the syscalls made by the binaries you're running
<Daviey> cjwatson: That is probably GrueMaster turn-and-burning fresh installs 145 times. :)
<stgraber> Daviey: and you can't ptrace something twice, so upstart fails
<cjwatson> Daviey: ... with xdeb?
<cjwatson> that would be astonishing
<stgraber> Daviey: though one hack I've done that works relatively well is to run an x86 upstart in an ARM container and then have everything else being armel
<slangasek> cjwatson: 150 machines sitting at TI that they don't know are phoning home? :)
<Daviey> That popcon is based on ALL, so goes back to Maverick.
 * GrueMaster hears his name
<stgraber> slangasek: btw, any plan on making libnih multi-arch? :) that'd make it a lot easier to run armel containers on x86 (as we can then simply install upstart:amd64 in the container and be done with it)
<stgraber> (not that I actually need that, I have arm boards where I can run actual arm containers, but would probably be fun to have for some people)
<slangasek> stgraber: why do you need it multiarched to install upstart:amd64?  Can't you just install upstart:amd64 + libnih:amd64?
<slangasek> (no, no plans currently)
<slangasek> ah, ureadahead and mountall also need it; is that the issue?
<stgraber> slangasek: yep, that'd be the issue
<stgraber> though I guess I could use the x86 version of these as well, but the goal is to have as little of these as possible...
<slangasek> stgraber: well, then you get into plymouth depending on mountall, and, and...
<slangasek> so yeah, libnih ought to get multiarched
<slangasek> feel free :)
<skaet> ScottL,  what's the status on the testing of Ubuntu Studio Alternate?   do we know the images are good?
<skaet> stgraber,  does Edubuntu upgrade ok?
<pitti> good night everyone!
<pitti> good luck with the rest of the release
<skaet> thanks for your help pitti.   good night.
<charlie-tca> skaet: I tested studio 64, then the tracker updated, but the image had not changed.
<charlie-tca> updating tracker for it
<skaet> charlie-tca, if image didn't change we shouldn't have lost results.  weird.    Ok,  thanksfor confirming its ok.  :)
<charlie-tca> I agree. But at least the 64bit image worked
<skaet> :)
<Laney> I'd like to approve bug 856579; would anyone mind reviewing in binNEW?
<ubot4> Launchpad bug 856579 in banshee-community-extensions (Ubuntu) "[FFe] Merge banshee-community-extensions 2.2.0-1 from Debian Unstable (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/856579
<Laney> (new packages from Debian)
<Laney> ScottK: ^ since you offered (for unapproved, but ...) :-)
<ScottK> Laney: If it's just bug fixes, it doesn't need FFe.
<Laney> it adds new packages
<ScottK> Oh
 * ScottK reads again
<Laney> I want to ack it, just need someone for NEWing
<ScottK> Yeah.  That's fine.
<Laney> ty
<ogra_> did anyone else get 4 mails for each upload that was released from the queue or is my evo wonky ?
<ogra_> (mails to -changes i mean)
<stgraber> skaet: not sure someone actually tested upgrades. I can start one in a VM now though.
<skaet> stgraber,  thanks.
<slangasek> is this changed recommends in deja-dup expected / approved?
<slangasek> (components-mismatches)
<stgraber> skaet: ETA for upgrade testing is at > 3 hours (takes a while to grab the images, then upgrade, then dist-upgrade). Will report in the tracker anyway.
<skaet> stgraber,  ok,  we'll update the release notes if there are issues after.
<Daviey> Desktop has no known-issues?
<ScottK> kde-baseapps is mine ^^^, so I'd appreciate if someone else could review/approved.
<skaet> Daviey,  pitti didn't add any, but I agree there are some that need mentioning.   I'll be adding those after jibel finishes his edits.
<jibel> skaet, done
<skaet> jibel thanks.
<charlie-tca> skaet: studio does install; ran encrypted LVM, now doing entire disk
<skaet> charlie-tca,  ScottL owes you several beverages of your choice.
<jibel> skaet, for desktop there is bug 832603, bug 852012, bug 854124
<charlie-tca> Yeah, maybe. Sometimes help is good
<ubot4> Launchpad bug 832603 in gnome-settings-daemon (Ubuntu Oneiric) (and 2 other projects) "gnome-settings-daemon crashed with SIGSEGV in g_simple_async_result_complete() (affects: 641) (dups: 88) (heat: 2980)" [Critical,Triaged] https://launchpad.net/bugs/832603
<ubot4> Launchpad bug 852012 in unity-2d (Ubuntu Oneiric) (and 2 other projects) "unity-2d-panel assert failure: *** glibc detected *** unity-2d-panel: corrupted double-linked list: 0x094bc9b0 *** (affects: 21) (dups: 21) (heat: 178)" [Critical,Triaged] https://launchpad.net/bugs/852012
<ubot4> Launchpad bug 854124 in glib2.0 (Ubuntu Oneiric) (and 2 other projects) "opening the system settings preferred application dialog breaks the defaults (affects: 2) (dups: 1) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/854124
<skaet> jibel,  ack.  There are some critical DX ones I'll probably add as well.
<jibel> skaet, if you go this way its worth mentioning the windows stacking issue in unity (bug 805087) and bug 850320
<ubot4> Launchpad bug 805087 in unity (Ubuntu Oneiric) (and 2 other projects) "Dash and launcher appear underneath windows (affects: 91) (dups: 21) (heat: 430)" [Critical,Fix committed] https://launchpad.net/bugs/805087
<ubot4> Launchpad bug 850320 in unity-2d (Ubuntu Oneiric) (and 2 other projects) "bad memory leak in unity-2d-panel (affects: 5) (dups: 1) (heat: 28)" [Critical,Fix released] https://launchpad.net/bugs/850320
<doko> accepted glance. one more step for the MIR
<Daviey> can a AA please promote glance, based on bug 801299
<ubot4> Launchpad bug 801299 in glance (Ubuntu) "[MIR]glance (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/801299
<Daviey> hanks
<Daviey> thanks
<ScottK> skaet: If we can save the Kubuntu amd64+mac image, I have someone who may test it.
<skaet> infinity, jibel, ^^
<infinity> ScottK: Oh, I may have published it anyway... I didn't even notice the 1 missing test.
<skaet> ScottK, infinity,  it is published.
<ScottK> amd64+mac desktop got ~no testing for Ubuntu or Kubuntu.
<ScottK> I don't think we should be publishing then.
<ScottK> then/them
<ScottK> Oh, wait.
<skaet> ScottK,  amd64+mac got testing for Ubuntu
<ScottK> Kubuntu did too since I last looked
<skaet> heh, that's ok then.
<ScottK> skaet: Nevermind. I think both Kubuntu and Ubuntu are OK to go.
<ScottK> Yes.
<ScottK> Sorry for the confusion.
* skaet changed the topic of #ubuntu-release to: Beta 2 released!   (Archive freeze remains 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
<slangasek> infinity: where do the package lists for the preinstalled desktop images live?  (bug #820514)
<ubot4> Launchpad bug 820514 in ubiquity (Ubuntu Oneiric) (and 1 other project) "oem-config-remove-gtk not found during preinstalled desktop initialization (affects: 1) (dups: 1) (heat: 18)" [High,Incomplete] https://launchpad.net/bugs/820514
<slangasek> skaet: hurrah!
<charlie-tca> Thank you for all your time, skaet
<skaet> Thank you all!   Team effort indeed.  :)
<charlie-tca> Should also say thank you greatly to the rest of these people, too!
<charlie-tca> All your hard work is appreciated!
<skaet> Thanks to infinity who got all the bits out the door, welcome back to the release team!    :)
<ScottK> doko: ^^^ should fix python-omniorb.
<infinity> slangasek: Same place as everyone else's?
<slangasek> infinity: which is the seed being used?
<infinity> I think it's the same as everyone else now.  But let me double-check that.
<infinity> slangasek: Yeah, it's just ubuntu-live.
<infinity> Or, should be. :P
<infinity> slangasek: Stopped forking long ago.
<infinity> slangasek: We bring in oem-config via jasper.  But I'm not sure I agree with the assessment that oem-config should be blindly trying to run oem-config-remove-gtk just 'cause some other GTK package exists. :P
<slangasek> infinity: excellent!  You disagree, you can follow up on the bug instead of it remaining incomplete indefinitely :-)
<infinity> If by "follow up", you mean "reassign to ubiquity", you bet!
<slangasek> well, as long as it's not hanging in incomplete :)
<infinity> We need a "very complete" status.
<charlie-tca> Isn't that "Triaged"?
<infinity> "So confirmed, that I just broke something unrelated."
#ubuntu-release 2011-09-23
<wgrant> slangasek, cjwatson: Since skaet doesn't seem to be around, is there any problem with doing an LP fastdowntime rollout during the usual window (in around 7 hours)? The 0802 publisher run will be skipped.
 * ScottK doesn't know of any reason it would be a problem.
<wgrant> We avoided them Mon-Thu due to beta. But I assume it's fine now.
<slangasek> wgrant: I also don't know of any reason
<wgrant> slangasek: Thanks.
<slangasek> infinity: I think you may have misunderstood bug #820514
<ubot4> Launchpad bug 820514 in ubiquity (Ubuntu Oneiric) (and 1 other project) "oem-config-remove-gtk not found during preinstalled desktop initialization (affects: 1) (dups: 1) (heat: 14)" [High,Confirmed] https://launchpad.net/bugs/820514
<slangasek> infinity: it's not "selecting something to execute"; it's "you have ubiquity present, but not the package providing the script that cleans up after ubiquity in oem-config mode"
<slangasek> infinity: if you have ubiquity-frontend-gtk, and you want to use oem-config, you're meant to have oem-config-gtk *to clean up ubiquity*.  Is there a reason oem-config-gtk can't be seeded here?
<ScottK> I'm curious if there's some special rule requiring every other ubiquity upload to FTBFS?
<micahg> must be one of those hard coded launchpad things
<infinity> slangasek: Err, what?  oem-config-gtk is the GTK frontend to oem-config.  How is calling that from the command-line ever going to yield useful results?
<infinity> slangasek: Both oem-config-remove and oem-config-remove-gtk do exactly the same thing (though the shell version sure is more readable), but oem-config-remove-gtk is a pygtk application.  The bug is that it's trying to call the pygtk app from debconf frontend.
<ScottK> Could lack of oem-config-remove cause a hang on shutdown after prepare for shipping?
<hyperair> ScottK: ping. could you ack an upload of banshee please? there's a unity lens bugfix thing
<hyperair> yeah, that.
<ScottK> I was just looking at the queue.
<ScottK> Speaking of which ...
<hyperair> :)
<hyperair> speaking of which?
<ScottK> infinity or slangasek: Would one of you please accept kde-baseapps.  It's hurting me to watch it languish there.
<ScottK> hyperair: Waiting for Launchpad to generate the diff for review.
<hyperair> alright
<infinity> ScottK: Didn't you hear?  We're dropping kubuntu for final.
<ScottK> Great.  More free time for me.
<slangasek> infinity: ah - then *I* misunderstood, I thought oem-config-remove-gtk did different things on cleanup
<infinity> slangasek: Not from what I can tell in reading them.  Unless "different things" means "fires up python and a ton of pretty GUI bindings".
<slangasek> heh
<infinity> slangasek: The actual package removal list in each is identical.
<slangasek> ok then
<infinity> ScottK: Accepted.
<ScottK> Thanks.
<infinity> ScottK: Oh, and to answer your other question, it could be the same bug we're seeing on preinstalled systems, if you have a GUI/live-ish seed installed, but you're using the texty oem-config to boot/prepare/shutdown.
<ScottK> The problem I'm having is the shutdown hangs.
<infinity> ScottK: If you do your prepare from a GUI, one would hope that the GUI removal bits would work on prepare.  But hey, that could be broken too. :P
<ScottK> There is no KDE version of the GUI removal bits.
<infinity> ScottK: Hanging can certainly be a symptom of being unable to call stuff.  Or entirely unrelated. ;)
<ScottK> Shuts down just fine, every time without oem-config running.
<infinity> After it hangs and you reboot, do you still have some packages installed that you shouldn't?
<ScottK> Didn't check.
<infinity> If so, could very well be a similar issue.
<ScottK> Good point.
<ScottK> infinity: If you're feeling brave, the python-defaults upload should fix some FTBFS.
<ScottK> And if it breaks the world, it'll give doko_ something to play with when he wakes up ....
<ScottK> Cool.  Thanks.
<ScottK> doko_: ^^^ python-omniorb should build now.  If not, complain to POX.
<ScottK> ~now
 * ScottK holds his nose and accepts banshee
<ScottK> (accepted it since you asked, but I think the idea behind the patch is quite unfortunate on many levels)
<doko_> ScottK, still ftbfs
<Daviey> Can i ask for a second opinion on bug 852479 ? The delta is *huge*, but fixes Security, High and Medium bugs.
<ubot4> Launchpad bug 852479 in asterisk (Ubuntu) "Merge asterisk 1:1.8.4.4~dfsg-2 (universe) from Debian unstable (main) (affects: 1) (heat: 6)" [Wishlist,In progress] https://launchpad.net/bugs/852479
<Daviey> We quite like aligning as close as possible with Debian on this package, and I really don't fancy the time it takes to cherrypick the Security and High fixes.
<Daviey> Universe package.
<Daviey> but semi-supported.
<ScottK> doko_: Rats.  Please ask POX then.
<ScottK> Daviey: In general, I think it's better to release slightly broken than with known security issues, so without knowing any details, I'd be inclined to say go for it.
<Daviey> ScottK: that was my thoughts, thanks.
<Daviey> Please can an AA promote glance based on bug 801299 MIR approval, thanks
<Daviey> (it's blocking nova builds)
 * Daviey notes that https://wiki.ubuntu.com/StandingFeatureFreeze should probably be updated or dropped.
<ScottK> Gnome is the only thing that applies to, so updating should be easy enough.
<ev> pitti: heads up: pygobject 3 breaks ubiquity as custom widgets instantiated via GtkBuilder no longer have their __init__ methods called.
<ev> https://bugzilla.gnome.org/attachment.cgi?id=194787 fails on a fully up to date system as well
<jdstrand> Daviey: I am not on the release team so I have no authority, but my opinion is *please, please* update the asterisk source. asterisk maintenance is hard enough without having to backport fixes
<Daviey> jdstrand: already uploaded and published :)
<jdstrand> perfecto!
 * jdstrand hands Daviey a gold start
<jdstrand> star
<Daviey> \o/
<Laney> ^ please accept
<cyphermox> could someone please ack the network-manager-applet upload?
<ScottK> Laney: Done.
<Laney> thanks
<seb128> could somebody review thunderbird-couchdb from NEW?
<seb128> it's required to have u1 contact syncing with tb
<seb128> which is something we want to work out of the box in Oneiric (the package is late but it was blocked on couchdb to start working which it didn't do for most of Oneiric)
<skaet> seb128, +1 on that.   If another member of the release team with more familiarity doesn't beat me to it,  I'l take a pass on it after the meeting today.
<seb128> skaet, thanks!
<jbicha> hi, could we get pitivi pushed through?
<ScottK> jbicha: Done
<jbicha> thanks
<cyphermox> ScottK: could you please release network-manager-applet?
<ScottK> cyphermox: I took a glance at it and it's way too much diff for me to be comfortable with reviewing/accepting.
<cyphermox> ah ok
<Daviey> Is the release meeting on today?
<cyphermox> I had discussed this shortly with pitti, much of the diff is that a library for the wireless and mobile dialogs was split out of the nm-applet binary so that they could be used by gnome-control-center
<skaet> Daviey,  ypu
<skaet> yup even.
<Daviey> ugh.. better prepare. :)
<Daviey> ScottK: Hmm, not sure how that blueprint got missed from the overview
<Daviey> gah
<Daviey> (I hate the blueprint tracker btw :)
<ScottK> Dunno.
<ScottK> There you go.  More reason it doesn't reflect reality.
<skaet> Daviey,  just add it to the topic, and it will start to track
<Daviey> skaet: yes, but i'm not sure *how* it got missed.
<skaet> Daviey,  fair 'nuf. :)   will let you and robbiew sort it.
<didrocks> ScottK: skaet: can you please look at oneconf in the queue? It's simply a timer change (I set it to 30s in the post beta2 version for debugging and forgot to remove it before upload), that will enable to not hurt the server too much during the week-end ;)
<ScottK> diff is still pending
<didrocks> ScottK: just for next time I don't annoy you before the diff is there, what page are you using to get the diff? not https://launchpad.net/ubuntu/oneiric/+queue?queue_state=1&queue_text=, the package page? diff is on it: https://launchpad.net/ubuntu/+source/oneconf/0.2.6.6
<ScottK> didrocks: Just accepted.  https://launchpad.net/ubuntu/oneiric/+queue?queue_state=1
<ScottK> It wasn't there when I'd looked before.
<ScottK> It takes some time for LP to generate them.
<didrocks> ScottK: thanks! but you just check on the package page, isn't it?
<didrocks> like https://launchpad.net/ubuntu/+source/oneconf/0.2.6.6
<ScottK> No.  The diff is on the +queue page.
<didrocks> ah indeed, the line is just missing until it's generated, thanks for the info :)
<ScottK> Seems like we lost the queue bot.
<ScottK> cjwatson: ^^^
<cjwatson> huh
<cjwatson> flood alert
<cjwatson> thanks for the note, I'd missed that
<infinity> So... Much... Purple... Text.
<Daviey> please can an AA accept cloud-init.
 * infinity looks.
<Daviey> Yes, including a Licence as a patch is wrong IMO..
<infinity> Heh.
<infinity> Rather.
<Daviey> and carrying every damn upstream patch, rather than cutting a new release is wrong.
<infinity> Oh well, it looks otherwise sane.
<infinity> cjwatson: grub seems to have a much larger diff (postinst.d, etc) than the changelog would suggest.
<infinity> cjwatson: The changelog clash between you and mvo in the diff would suggest perhaps a disgareement between your local copy and the archive reality?
<Daviey> Is this really being tracked as release crtiical https://launchpad.net/bugs/852583 ?
<infinity> Daviey: Hey, cosmetic things are important.  If you had buggered icons in the default install (say, the Ubuntu logo was green), it would be RC, right?  Now, pretend you're blind. ;)
<Daviey> infinity: did you make an assumption that I wasn't?
<infinity> Daviey: I'm not sure we've met.  But it's a fair assumption to make of the general population.
<infinity> Either way, I'm not sure it's RC either, but it's also a simple and non-intrusive fix.  Someone should just upload it.
<infinity> (Then again, I wouldn't care if logos were the wrong colour either, as long as no one messes with my terminals)
<Daviey> infinity: You know we are defaulting to orange/purple split for termianls?
<Daviey> Ubuntu branding.
<infinity> </3
<ScottK> Terminals are still nicely black by default in Konsole, so do whatever you want elsewhere ...
<infinity> cjwatson: I'm going to reject that grub upload because of my above comments, re: dropped/clashed revisions.
<cjwatson> infinity: hmm
<cjwatson> yes, you're right about disagreement
 * cjwatson goes to resolve
<cjwatson> hah, what fun
<cjwatson> my version was tagged in bzr and everything!  I must have missed the reject mail
<cjwatson> or maybe the upload broke
<cjwatson> no .upload file locally, I guess something went wrong such that my ubuntu-release script didn't actually upload it
<infinity> FWIW, when working from a VCS, I tend to still apt-get source and debdiff against the previous version.
<infinity> Usually to make sure I didn't introduce cruft from my working copy, but it avoids this sort of thing too.
<cjwatson> I normally do, I'd just forgotten that anyone else was insane enough to upload grub
<infinity> Hahaha.  That's fair. :)
<skaet> cjwatson, am working through the thunderbird-couchdb patch,  and there's a /debian/copyright file, that has me wanting to cross check what the usual and reasonable is here.
<ScottK> skaet: Can you pastebin it somewhere?
<skaet> The fix part seems straight forward,   but do I need to do an audit of the original package now too,  to ensure the debian copyright is ok?
<skaet> ScottK,  doing...
<cjwatson> where's this?  don't see it in the queue
<infinity> skaet: tb-couchdb in NEW?
<cjwatson> there are scripts to help with licence checking
<infinity> skaet: We do tend to audit NEW packages to make sure debian/copyright actually jives with reality.
<skaet> infinity,  yup.
<infinity> And yes, apparently there are now scripts to help with that.
<infinity> (I feel old)
<skaet> it was weird it was added with a patch.
<cjwatson> err
<skaet> cjwatson,  coolio.   link please.
<cjwatson> it looks perfectly normal to me
<cjwatson> it's in the Debian diff
<infinity> Yeah...
<skaet> cjwatson yes,  whats weird to me is why it wasn't in the original.
<infinity> skaet: The orig shouldn't have a debian directory at all.
<skaet> rather than showing up in the diff,  with a limited fix.
<infinity> skaet: diff.gz == The debian packaging.
<infinity> skaet: orig.tar.gz == the upstream tarball.
<cjwatson> We would not expect debian/copyright to be upstream.
<skaet> yah,  that makes sense.   Thanks for the explanation.
<cjwatson> and I don't know what you mean by "limited fix"
<ScottK> We would, in fact, be annoyed if it was.
<cjwatson> the script I'm referring to is 'licensecheck', but it doesn't seem to understand this particular set of files very well, so probably needs by-hand inspection
<infinity> Wow, this is really triple-licensed?  Whacky.
<cjwatson> still, it looks correct to me
<skaet> cjwatson,  it was my misunderstanding.   After the above explanation, it makes more sense now.
<cjwatson> fairly straightforward tri-licensed Mozilla stuff
<micahg> infinity: most of the mozilla products are
<infinity> micahg: Yeah, but this isn't from Mozilla upstream.
<cjwatson> and the copyright file syntax looks fine
<infinity> micahg: I guess it makes sense to be in line with, though.
<skaet> cjwatson,  I'll do the by-hand inspection,  no worries.    Just needed to be educated a bit it seems.
 * skaet knows license inspecting by hand only too well.... :P
<ScottK> grep -ir copyright *less
<cjwatson> the packaging looks OK, although I trust somebody has a good reason for why it needs to have hardcoded dependencies on specific library versions
<ScottK> err
<ScottK> grep -ir copyright * | less
<cjwatson> presumably because no shlibdeps facility is available; I guess we just have to bump it manually
<GrueMaster> erm, problem with the ubuntu-core naming at http://cdimage.ubuntu.com/ubuntu-core/releases/oneiric/beta-2/.  ubuntu-core-11.10-beta2-core* .  core is redundantly duplicated.
<cjwatson> ah, yes, javascript ctypes binding
<cjwatson> GrueMaster: file a bug on the ubuntu-cdimage project, please, explaining how you'd like to iit to look instead
<cjwatson> *like it to
<infinity> GrueMaster: Yeah, I know.  It was like that in beta-1 as well.  I might muck with the release scripts before release to make it prettier.
<cjwatson> (my preference would be to drop the first "core")
<infinity> cjwatson: That's my preference too.
<infinity> cjwatson: Just means futzing with for-project (or just using for-project ubuntu to publish instead of ubuntu-core)
<cjwatson> look at server - we do the same for that
<cjwatson> should preferably follow the same pattern
<infinity> Server is for-project ubuntu, I believe.
<infinity> IIRC.
<GrueMaster> We seem to hit this problem with every new image.  We had the same problem with desktop & server iirc.
<cjwatson> yes, but there are hardcoded bits in various scripts to help
<cjwatson> GrueMaster: no, not every new image.  (trust me.)
<infinity> So, yeah.  SHould probably just drop core from for-project, and do it the same.
<infinity> GrueMaster: Just images that don't follow standard schemes (and preinstalled was equally different)
<cjwatson> yeah, preinstalled still bites me occasionally.
<GrueMaster> Also, there are no manifest files for the preinstalled-[server|desktop] images.
<cjwatson> manifest files are produced by the livefs builds
<cjwatson> I think
<cjwatson> do the preinstalled builds produce them?
<infinity> They do.
<cjwatson> hmm
<infinity> We don't publish manifests for releases.
<infinity> Not for ISOs either.
<infinity> This isn't new.
<cjwatson> *blink*
<cjwatson> we certainly do for livefseslive CD images
<cjwatson> cf. http://releases.ubuntu.com/natty/
<infinity> Oh wait, yeah.
<infinity> *blink*
<infinity> Where was I looking last time I thought this was true? :P
<cjwatson> and the code seems to try to fetch the manifest unconditionally ...
<infinity> No, you're right.
<GrueMaster> And http://cdimage.ubuntu.com/releases/oneiric/beta-2/ has manifests for everything but armel atm.
<infinity> Hrm.
<cjwatson> ah, but publish-release is more conditional about it
<infinity> p-r only does it for certain exts?
<cjwatson> notice they're on http://cdimage.ubuntu.com/daily-preinstalled/current/
<cjwatson>         if [ "$TYPE" = live ] || [ "$TYPE" = desktop ] || \
<cjwatson>            [ "$TYPE" = netbook ] || [ "$TYPE" = mid ] || \
<cjwatson>            [ "$TYPE" = moblin-remix ] || [ "$TYPE" = uec ] || \
<cjwatson>            [ "$TYPE" = server-uec ] || \
<cjwatson>            ([ "$TYPE" = dvd ] && [ -e "$base.manifest" ]); then
<cjwatson> (feel free to vomit)
<infinity> Vomiting, sir.
<cjwatson> let me turn that into a case statement...
<infinity> Why the test at all?
<infinity> manifests only exist if produced, and if produced, we want them?
<cjwatson> I wanted to error if they should be there but weren't
<infinity> Ah.
<infinity> Still ew, but at least understood now. :P
<GrueMaster> personally, I can't think of a reason not to have manifests with the images (except netinstall...maybe).  They are a very convenient way of determining what package version is in an image.
 * infinity still wonders what he was once looking at that led him to believe we have no manifests in simple/releases.
<infinity> Maybe I just glanced at alternates, and wasn't awake.
<infinity> GrueMaster: No, I agree, they're quite handy.
<skaet> hmm..   after scanning the files,   went to accept the package and got a FAILED: thunderbird-couchdb (The source thunderbird-couchdb - 0.0.1-0ubuntu1 is already accepted in ubuntu/oneiric and you cannot upload the same version within the same distribution. You have to modify the source version and re-upload.)
<cjwatson> GrueMaster: you don't need to persuade us :)
<infinity> skaet: Maybe Colin beat you to it. :)
<cjwatson> I did not
<cjwatson> maybe it was uploaded twice?
<skaet> I'm not seeing if from the bot....   maybe.   I'll go check what's in the archive.
<cjwatson> the bot wouldn't say
<cjwatson> I don't think
<infinity> https://launchpad.net/ubuntu/+source/thunderbird-couchdb/0.0.1-0ubuntu1
<cjwatson> pretty sure it shoves everything into a hash or some such
<cjwatson> you need to look at the actual records in LP
<infinity> Already built, with binaries in NEW.
<infinity> Though that was only a few minutes ago.
<infinity> So, maybe your ACCEPT onthe web form just triggered twice.
<infinity> And the second (rightly) failed.
<skaet> infinity,  weirdness, but that seems to explain what I'm seeing.
<infinity> (The publishing record was created 6.5 minutes ago)
<cjwatson> GrueMaster: future preinstalled-* releases will have manifests
<GrueMaster> ok
<GrueMaster> thanks
 * skaet needs to watch how hard she presseses down on key board it seems. :P
 * GrueMaster goes and retrives them from prior daily image dirs for now.
<skaet> thanks for the help infinity, cjwatson, ScottK
<cjwatson> GrueMaster: some images don't have .manifest files but have listings in other formats due to not being live filesystems; I like to use different extensions when the file format is different
<infinity> Do we have anything other than .list and .manifest?
<GrueMaster> hrm.  Not really a good idea.  The manifest should just list packages and versions contained in an image, regardless of image type.
 * skaet heads for lunch
<GrueMaster> Doesn't make much sense for different names.
<infinity> GrueMaster: .list is actually a file list (think alternate ISOs)
<infinity> Though having a manifest of the debs in an alternate ISO wouldn't be an awful idea.  *shrug*
<GrueMaster> If it boots and runs something, it should have a manifest of the stuff used to make it boot and run stuff.  Even if it just boots and installs debs from a pool somewhere.
<infinity> diff from 7.0.9-0.0.ubuntu1 (in Ubuntu) to 9.4.2.0-0oneiric1 <-- Welcome to things I don't want to read.
<GrueMaster> Makes debugging boot issues a little easier, especially when trying to determine what file may have caused an issue.
<cjwatson> GrueMaster: there really are differences relevant to me
<cjwatson> GrueMaster: d-i images don't have anything preinstalled, and the set of packages and versions you get out of them is highly variable and not easily computable by cdimage; furthermore the .list file, which contains a list of all files in the image, is useful in its own right and supplies that information
<GrueMaster> fair enough.
<cjwatson> I suppose infinity's right, there would be worse things than having bits of .list extracted into .manifest
<cjwatson> it seems redundant to me but if people find it useful it's possible
<cjwatson> but it should be everything, not an attempt to define which bits are needed to boot and run stuff, IMO
<cjwatson> well, all debs
<infinity> Yeah, I would envision it as a manifest of every *deb in the image, munged to match the dpkg -l output format in the live manifests.
<infinity> Then you could diff alternate and live for package differences, say.
<infinity> That might be vaguely handy to someone.
<cjwatson> yeah, true
 * infinity opts out of reviewing acroread today, and hopes someone else does it.
<ScottK> infinity: You could just say "Meh, partner" and accept.
<infinity> I at least like to give partner stuff a once-over to make sure it's not full of maintainer script fail.
<infinity> But yes, there's a certain element of "plug my nose and accept".
<infinity> Now, a binary package with no maintainer scripts, and shipping one file.  That, I'm happy to review. :P
<infinity> (Yay, tb-couchdb)
<seb128> thanks to whoever newed it
<seb128> tb-couchdb
<infinity> It was a group effort.
<seb128> there is also caribou in NEW if somebody wants to get to it ;-)
<infinity> Yeah, I saw that...
<jbicha> caribou was ffe bug 845300
<seb128> it has a ffe approved and got sponsored by pitti before but it had an issue, I just sponsored a hopefully fixed version from jbicha
<seb128> who just just commented while I was typing ;-)
<infinity> Heh.
<infinity> I don't suppose there's a diff somewhere between the rejected one and this?
<seb128> it's needed to fix gnome-shell which is not installable and build-deping on caribou
<infinity> So I don't have to review from scratch. :P
<seb128> jbicha, ^ ;-)
<ScottK> Or just take the current package, add one really awful thing at random, diff that and hand it in ....
<infinity> ScottK: You're in rare form today. ;)
<cjwatson> echo 'Just ask infinity' >debian/copyright
<jbicha> infinity: http://bazaar.launchpad.net/~jbicha/+junk/caribou/revision/2
<infinity> jbicha: Does that include whatever it was Martin "fixed" before the last upload?
<infinity> (I'm assuming the two DEP fields)
<cjwatson> echo '#! /bin/sleep 2147483647' >debian/rules
<infinity> jbicha: Also, why was the first rejected? :P
<jbicha> infinity: he fixed debian/copyright
<jbicha> we rejected it because Debian wanted to change some things first to avoid having to mess with Conflicts/Replaces fun
<infinity> Ahh, so it wasn't on grounds of incompetence, just to avoid version rev mess.
<infinity> Check.
 * infinity goes about kicking the tires.
<jbicha> infinity: it works in Unity or Fallback, I can't figure out how to get it to run in gshell though :(
<jbicha> maybe it's conflicting with onboard
<infinity> jbicha: I'm kicking the tires on the packaging, not the upstream source.  If it's buggy, that's your problem. :P
<jbicha> :)
<seb128> ^ nm-applet, I rejected it on cyphermox's request
<seb128> he will upload it again with a replaces fix
<infinity> jbicha / seb128: Seems sane (and it was good that you waited on the module split, that would have been gross to fix), accepted.
<infinity> jbicha: If it procceds to FTBFS, I expect you'll fix it yesterday? ;)
<seb128> thanks
<jbicha> infinity: yes, thanks
<jbicha> infinity: can we get the NEW caribou packages pushed too?
<seb128> infinity, can we get the other packages in the queue reviewed?! ;-)
<infinity> Yes, yes.
<infinity> My laptop is busy dying a painful death, I'm working at half capacity here on an ARM netbook with a UK keyboard. :P
<cjwatson> I'll attack it shortly
<cjwatson> just trying to finish with the three independent Xen-installation blockers I've been fixing today
<infinity> I'm already on it.
<infinity> And accepted.
<skaet> cjwatson, infinity - accepted a couple of the ones that looked fairly straightforward.
<cjwatson> grub-installer is a fairly large diff, but it halves the delta against Debian, most of the changes are me deliberately upstreaming stuff to Debian in somewhat different ways, I figured the translation improvements would be good, and we want the preseeding fix from 1.68
<cjwatson> on balance it looked better to merge than to cherry-pick
<cjwatson> the only actual new feature is mipsel/loongson-2f support, which is irrelevant for us :)
<cjwatson> ah, slight tweak though ...
<infinity> cjwatson: Is there any chance that anything in d-i might turn on binfmt_misc support, ever?
<infinity> cjwatson: Or, I guess, while grub-installer is running, which seems less likely. :P
<cjwatson> infinity: I wouldn't like to rule it out I suppose, but I haven't thought of a reason for it
<infinity> cjwatson: (Just pondering if your umount might fail)
<cjwatson> Why?
<cjwatson> Would it go wrong if binfmt_misc were enabled before grub-installer runs?
<cjwatson> Seems not, it would have to be specifically enabled in the target system for that to go wrong, wouldn't it?
<cjwatson> This code does run in ubiquity as well, so binfmt_misc might well be enabled in the primary system, but surely not in the /target chroot
<infinity> Yeah, seems pretty unlikely.
<infinity> I think I'm still chafing from binfmt_misc hatred on the buildds recently. ;)
<cjwatson> Yeah, thought that might be the case ...
 * cjwatson gives grub a second go, and starts working on the SRU bits of that
 * infinity raises an eyebrow at the pedantic sentence-spacing fixes. 
<infinity> Nice to know someone cares deeply about that. :P
<infinity> And clever abuse of shell-quoting with the ensure-active call.  That almost seems too clever.
<infinity> (THank god it's commented)
<cjwatson> Heh, what happened there was that I wrote the original Ubuntu-specific code years ago, and did the Debian code (where I finally got round to doing it right, using libparted) this year
<infinity> Looks good to me, though, from the POV of how unreviewable a change that large is.
<cjwatson> and in between, I changed my personal style to be two-spaces-after-full-stop
<cjwatson> so yeah, pedantry
 * slangasek goes through the archive adding half-width non-breaking spaces
<infinity> ...
<cjwatson> ensure-active> actually that probably doesn't matter since ensure-active.c tests *argv[2]
<cjwatson> I think it may have mattered in an earlier version of the code
<infinity> Oh balls, I just accepted grub instead of grub-installer.  Fat fingers ahoy.
<slangasek> infinity: you know you envy the French !
<infinity> cjwatson: Reassure me that the grub upload was mvo's + your changes in the last one? :)
<cjwatson> infinity: better review it quick!
<cjwatson> yes, I checked that this time
<cjwatson> http://paste.ubuntu.com/695834/
<infinity> cjwatson: Lovely.
<cjwatson> I'm not sure any GRUB Legacy change counts as lovely, but
<slangasek> the "full deletion" one does :)
<infinity> The diff was what I expected it to be this time, and readable to boot.  Lovely enough for a Friday afternoon.
<infinity> All will be erased with beer soon enough.
<cjwatson> slangasek: Xen :-/
<slangasek> pshaw
<cjwatson> Give me a solid month without distractions to port GRUB 2 to Xen ...
<slangasek> heh
<infinity> Will pv-grub2 really be that much work?
<cjwatson> (Actually it's probably not quite that bad, but the "distractions" bit killed me this cycle)
<cjwatson> I have a complete design for it now and I think it's straightforward, there's just a tedious bit of writing a xenstore client at the start
<cjwatson> It's probably actually a week of uninterrupted coding timee
<infinity> Can't cargo-cult bits from the current pv-grub?
<infinity> Or is it vile?
<cjwatson> It's vile, and upstream would prefer one that's absolutely definitely licence-clean anyway
<cjwatson> And the design has to be entirely different really
<cjwatson> We actually get better security properties from the new design
<cjwatson> No parsing *at all* in the host
<cjwatson> (It's marginal, but still)
<infinity> Oh filterdiff, marry me and have my babies.  Thanks in advance.
<cjwatson> Anyway, it goes: xenstore client, block driver, (optionally network driver if you can be bothered), boot shim, and then some utility code to chainload itself - you keep one grub2 image in the host filesystem and one in each guest, so that the host doesn't have to read the guest filesystem and the grub2 image in the guest that parses its grub.cfg can be precisely in sync with it
<infinity> TImeouts in +queue really need to stop...
 * infinity goes back to doing this the pleasant way until IS takes away our shell access.
<cjwatson> I've asked them for an API client
<slangasek> gdm there is part of a fix for plymouth corruption on shutdown
<slangasek> (needs a corresponding lightdm change, and a plymouth upload that's blocked on both)
<charlie-tca> Need approval on bug 857718 for Xubuntu to get the latest version of garcon
<charlie-tca> http://pad.lv/857718
<slangasek> Hmm, Xubuntu team isn't authorized to approve its own FFes this cycle?
<charlie-tca> Not to my knowledge
<charlie-tca> Is mr_pouit on the approval list?
<slangasek> well, I guess I didn't see any discussion on ubuntu-release this cycle of delegating FFe approvals... so no
<charlie-tca> Then we can't do it ourselves
<slangasek> yeah... that definitely seems like a bug, though; if he's done all this testing, who am I to say no (and why should he need to ask)
<infinity> ^
<infinity> Politics aside, though, it looks good to me.
<charlie-tca> Thank you both.
<micahg> even with FFe delegations, one was not supposed to approve one's own FFe
<infinity> micahg: No, hence the mention of team delegation.
<infinity> Either way, long discussion, not relevant this instant.
<infinity> slangasek: Accepted.
<slangasek> ta
#ubuntu-release 2011-09-24
<cjwatson> I just uploaded debian-installer for the new kernel ABI; it would be good if somebody could accept it reasonably soon so that I can sync up the seeds
<ScottK> cjwatson: Accepted.
<cjwatson> thanks
 * cjwatson pokes the seeds
<Daviey> Would be good to be able to trace who accepted packages, so i know who to stab. :)
#ubuntu-release 2011-09-25
<zul> hmmmm?
<ScottK> Daviey: What's the issue?
<ScottK> cjwatson: queue bot is lagging again ...
<infinity> Daviey: What are we stabbing people for?
<infinity> Daviey: (But I agree, I'd love an audit trail)
<micahg> ScottK: queuebot isn't lagging, it's AWOL
<ScottK> I was being polite.
<micahg> heh
<micahg> is anyone around that can accept firefox?
 * micahg looks for infinity 
<cjwatson> ScottK: sigh.  I'm running it in a loop now ...
<cjwatson> (until somebody gets round to teaching it to reconnect)
<micahg> cjwatson: if you could accept firefox please, it's a very annoying regression
<cjwatson> not really here, but let me look quickly
<cjwatson> $(MOZ_PREFIX)/lib/$(MOZ_APP_NAME)-addons/distribution isn't a directory is it?
<micahg> hmm, probably is
<cjwatson> looks like it is.  that's going to cause inconsistency between fresh installs and upgrades, although I suppose that's sort of the point of the bug?
<cjwatson> (only backwards)
<micahg> I think that's what he was trying to fix initially, let me find the original commit
<cjwatson> chrisccoulson: I assume you know that the fundamental problem is that dpkg deliberately won't replace directories by symlinks or vice versa by itself
<cjwatson> so what will happen if somebody initially installed with 7.0+build2+nobinonly-0ubuntu1 (which will have $(MOZ_PREFIX)/lib/$(MOZ_APP_NAME)-addons/distribution as a directory and $(MOZ_LIBDIR)/distribution as a symlink) and then upgrades to 7.0+build2+nobinonly-0ubuntu2?  I think you'll get the exact same problem only in reverse
<cjwatson> because now they're going to have a dangling symlink in $(MOZ_LIBDIR)/distribution
<cjwatson> so I'm not sure I should accept this; I think you need to fix it properly to avoid causing even more complexity in maintainer scripts
<cjwatson> the usual fix is to move aside the directory or symlink you're trying to replace in the preinst (assuming that you know no other package is shipping anything in there), and remove it completely in the postinst
<cjwatson> and if you're feeling industrious, do a bit more work to make rollback work properly
<cjwatson> you can look at groff-base for example code that I worked out carefully once
<cjwatson> (it has code in the postrm too)
<micahg> cjwatson: thanks
<cjwatson> not rejecting for now, but I'd definitely prefer to see a cleaner fix in one go rather than having to ensure a clean upgrade from both dodgy versions
<chrisccoulson> hi cjwatson, oh, i was aware of the problem of replacing a directory with a symlink, but i didn't realize it was the case when doing it the other way around too :/
<chrisccoulson> i reverted the change because it's sunday morning and i'm meant to be on vacation, but if it's still not going to work right then i guess i'll have to fix it :/
<chrisccoulson> cjwatson, how involved have you been with ubuntu-defaults-builder?
<infinity> chrisccoulson: Are you planning to address Colin's symlink/directory concerns?  If so, I think I'll reject Firefox to avoid someone else mistakenly accepting it later and making your upgrade path even harder to deal with. :P
<infinity> Or maybe I'll just go to sleep, an hope for the best.
<chrisccoulson> infinity, yes, fixing it now
<chrisccoulson> trying to juggle that and fathering duties isn't easy ;)
<chrisccoulson> ah, someone accepted it, just as i uploaded a new version
<Laney> oops
<charlie-tca> Can we turn daily builds back on?
<charlie-tca> No new images since beta2 candidates
<charlie-tca> for anyone.
<infinity> charlie-tca: Dailies back on.
<charlie-tca> Thank you
<jbicha> micahg: ^ gdb-doc builds now in my pbuilder
<micahg> jbicha: thanks
#ubuntu-release 2012-09-17
<ScottK> infinity: Thanks.
<sladen> skaet et al; am I okay to upload  bug #1048600  -docs okayed it 3 days ago
<ubot2> Launchpad bug 1048600 in ayatana-design "[FFe] Restore "Ubuntu Medium" weights in Ubuntu's binary .deb" [Critical,Fix committed] https://launchpad.net/bugs/1048600
<psivaa> cjwatson, installer media-info still says Alpha, is that intended?
<xnox> psivaa: beta1 image or dailies?
<xnox> please check both.
<xnox> (the two are build with different parameters)
<psivaa> xnox, i noticed on daily quantal, did not check the official beta 1 thogh
<xnox> psivaa: dailies have interesting things like "Install RELEASE" =)
<Laney> bah
<Laney> sladen: breaking qt disturbs me
<popey> Laney, medium font enabling?
<Laney> that linked bug
<Laney> bug 744812
<ubot2> Launchpad bug 744812 in fontconfig "FontConfig/Qt stack choke on Ubuntu Medium font meta-data (No medium in Inkscape and too bold in Qt apps)" [Undecided,Confirmed] https://launchpad.net/bugs/744812
<psivaa> xnox, i dont know if i am missing something but http://cdimage.ubuntu.com/releases/12.10/beta-1/ does not have any amd64 or i386 images?
<Laney> psivaa: releases.ubuntu.com
<xnox> psivaa: yes, there are on releases.
<psivaa> Laney, xnox thanks :)
<sladen> Laney: Unity-2D was the primary Qt app that was broken; but most apps have trouble with advanced fonts with more than 4 weights.  (Though this isn't the fault of the fonts).
<Laney> so we can expect more trouble? :-)
<sladen> if trouble == ill-designed font selection dialogues?
<Laney> probably a subset
<Laney> or â
<tumbleweed> Laney: surely 0ad and 0ad-data go together?
<Laney> yes?
<tumbleweed> you asked for a separate request
<Laney> then the sponsor won't miss the request to sync the other one
<tumbleweed> anyway, I'm inclined to accept it. Just having a brief look
<Laney> yeah, do
<tumbleweed> not reviewing 0ad-data diffs, though :)
<Laney> I didn't expect that to need a separate review
<Laney> just its own little buglet
<tumbleweed> agreed
<tumbleweed> can an archive-admin unblacklist sensors-applet? bug 1049343
<ubot2> Launchpad bug 1049343 in ubuntu "FFe: Sync sensors-applet 3.0.0-0.2 (universe) from Debian testing (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1049343
<iulian> Ugh, huge diffs, my favourites.
<didrocks> sladen: available to make the upload of the ubuntu font or should I do it?
<cjwatson> psivaa: Yes, it's intended for dailies except when we're actually preparing beta candidates.  (We forgot to flip it for beta-1 though.)
<psivaa> cjwatson, ok, was just in the process of double checking for the official beta 1
<cjwatson> It's part of the process docs for preparing a beta - we just screwed up.
<cjwatson> Not desperately important though :-)
<psivaa> yea true, may be will become ok for beta 2
<psivaa> cjwatson, just wondering if you need any further information for bug 1051388 before i go onto destroy the vm
<ubot2> Launchpad bug 1051388 in ubiquity "CRITICAL **: unable to create directory '/root/.cache/dconf': Permission denied. dconf will not work properly. message on amd64 vm installation" [Undecided,New] https://launchpad.net/bugs/1051388
<cjwatson> psivaa: in general we don't spend much effort on fixing messages that only appear in terminal output and that have no practical effect
<cjwatson> psivaa: we don't need anything else but it's low-priority
<psivaa> cjwatson, agree i saw a similar bug, just reported not to miss anything ::
<psivaa> :)
<xnox> psivaa: it's a bug in dconf.... and critical is a bit misleading since it doesn't crash nor burst into flames.
<psivaa> xnox, yes it was a little alarming at the time of that installation coz my hardware is not that powerful and the installation seemed very slow, and at times seemed hung.
<xnox> psivaa: the reason why your installation hang is unknown, but it's interesting that it was a networkless install and in the end of the syslog there are messages of "not being able to resolve host ubuntu"
<psivaa> yep that was going to be my next question, it correctly detected during the inital stage that there is no network
<psivaa> xnox, i.e.  when it laid the checked conditions for available memory, power source and network connection.
<henrix> infinity: regarding bugs #1047350 and #1046423 do you have any idea why the linux-headers packages just vanished?
<ubot2> Launchpad bug 1047350 in linux-lts-backport-natty "linux-lts-backport-natty: 2.6.38-16.67~lucid1 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1047350
<ubot2> Launchpad bug 1046423 in linux-lts-backport-oneiric "linux-lts-backport-oneiric: 3.0.0-26.42~lucid1 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1046423
<henrix> infinity: is there any way to recover them, or the solution is to just go ahead with a respin?
<dobey> hey all, can i get someone to poke at https://bugs.launchpad.net/ubuntu/+source/ubuntuone-installer/+bug/1048669 ?
<ubot2> Launchpad bug 1048669 in ubuntuone-control-panel "[FFe] Drop ubuntuone-installer package from archive" [High,Fix released]
<Laney> dobey: weren't you looking at that with infinity?
<dobey> Laney: i was discussing the other bug, which was about adding ubuntuone-client-data (which likely won't happen at this point, as some unexpected things have come up on our side)
<Laney> oh, well that's why I skipped over it, sorry
<dobey> Laney: i am not sure this bug actually needs an FFe; and ubuntuone-client and ubuntuone-control-panel no longer recommends/depends on ubuntuone-installer (so it's off the image now anyway)
<dobey> so ubuntuone-installer can be pulled from the archive without any issues now, afaik
<Laney> all that's left is executing the removal?
<dobey> as far as i understand, yep. i guess an archive admin has to do that
<Laney> I don't know what people expect FFe for
<Laney> someone else tell me :P
<Laney> dobey: btw, have you noticed the "headline" amount of available space being wrong in the u1 control panel?
<dobey> yeah i'm not sure this needs an FFe. i guess we might have needed one for adding ubuntuone-client-data to some deps, but i think that would be separate still as well.
<Laney> here it says that I'm using 100% of 5GiB but I should have 205 ("Account information" gets it right)
<dobey> Laney: i have not
<Laney> k
<dobey> Laney: does https://one.ubuntu.com/account/ say the right thing for you?
<dobey> hrmm, so mine says the wrong thing in both places it seems
<Laney> no
<Laney> but it knows about the extra subscription
<Laney> just not included in "Your storage"
<Laney> (well, it's in the list but not the total)
<dobey> Laney: i think that is a server issue
<dobey> right
<Laney> ok
<Laney> shall I file a bug somewhere?
<dobey> i'm poking someone about it right now
<Laney> awesome
<dobey> Laney: are you an archive admin too?
<Laney> no
<Laney> t yet ;-)
<dobey> ah ok
<dobey> heh
<Laney> just subscribe the archive admins
<Laney> and set it Confirmed I think
<dobey> Laney: should i drop the [FFe] bit?
<Laney> if you like, but I doubt it will concern the processing AA :P
<dobey> ok, confirmed and subscribed ubuntu-archive
<dobey> thanks laney
<Laney> kein problem
<doko> looking at websockify in NEW #1048679, looks ok, but needs the FFe. anyone care for a review?
<Laney> bounce it back to the uploader and ask for him to file it
<Laney> same with anerd afaics
<doko> Laney, well, the request for the FFe is in the bug report. why bounce it back?
<Laney> which bug report?
<Daviey>  < doko> looking at websockify in NEW #1048679 ...
<Laney> I don't see that on the release team's list
<Daviey> They haven't e subscribed by the seems of it
<doko> subscribed
<Daviey> In anyway, this isn't really a Feature at all
<Daviey> A current main project was broken into 2
<Daviey> (Upstream)
<Daviey> Hmm, that was my understanding.. anyway
<Daviey> Laney: are yoiu taking it?
<Laney> nah, you do it
<Laney> I'm being DoSed by Unity :P
<Daviey> My shoulders became all angled earlier, it seemed. :)
<Laney> how 'bout that
<iulian> That shouldn't require an FFe in my opinion but on the other hand it still remains a new package that has to go through the NEW queue and be processed by archive admins.
 * iulian shrugs.
<ScottK> New packages need FFe, specifically because AA's aren't generally supposed to have to deal with New in this part of the cycle.
<doko> iulian, did you read the report?
<iulian> doko: Nop.
<iulian> ScottK: Indeed.
<iulian> doko: Well Daviey said that so I commented on what he said.
<Daviey> Hmm, Ok.  I expected to NEW it myself TBH.
<Daviey> thanks.
<doko> anerd rejected from NEW, because it doesn't clean the binaries, included in the source instead
<Laney> ask him for the paperwork too when you mail please
<Laney> who wants to take a Unity FFe?
<Laney> bug #713423 bug #876017 bug #1046461
<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
<ubot2> Launchpad bug 876017 in unity "[FFE][UIFE] Window management - We should be able to close windows in spread mode" [Medium,Fix committed] https://launchpad.net/bugs/876017
<ubot2> Launchpad bug 1046461 in shotwell "[UIFe] [FFe] UOA integration needs to support multiple accounts" [Undecided,New] https://launchpad.net/bugs/1046461
<Laney> take your pick
 * Laney glances at iulian and Daviey
<Daviey> Laney: assign me one
<stgraber> bug 876017 is waiting for a screenshot last I checked
<ubot2> Launchpad bug 876017 in unity "[FFE][UIFE] Window management - We should be able to close windows in spread mode" [Medium,Fix committed] https://launchpad.net/bugs/876017
<Laney> true, it is
 * Laney is Incompleting tuff so that people don't keep looking at it
<highvoltage> sounds tuff.
<Laney> well... jbicha: did you mean that to be a blocker or was it for your info?
<jbicha> Laney: stgraber: no, that's not a blocker
<Laney> cool
<jbicha> it is nice for UIFE's to come with a screenshot so we can see what changed though :)
 * Laney has been asking for a lot of nice things on release team bugs :P
<Laney> stgraber: want to take one of the first two?
<stgraber> Laney: I'll take 876017
<Laney> ok
<Laney> thanks
<Laney> these are the ones that popey said were important for his team and weren't blocked on receiving some information / resolved already
<iulian> Laney: I'll take the third one.
<Laney> I assigned it to Daviey, but I'm sure he won't mind you stealing it :-)
<iulian> Oh did you?
<stgraber> popey: when you have a sec, I commented in bug 876017 asking for a few details. I'd also appreciate (but won't block on) having a screenshot before/after the change. Thanks
<iulian> Daviey can take it then. :)
<ubot2> Launchpad bug 876017 in unity "[FFE][UIFE] Window management - We should be able to close windows in spread mode" [Medium,Fix committed] https://launchpad.net/bugs/876017
<Laney> heh
<iulian> If he's really busy with something else, then I shall take it.
<Daviey> i can't do it for the next hour and 20
<iulian> Daviey: You don't mind if I steal it from you, do you?
<iulian> jbicha: Have you tried that modified patch (06_uoa.patch)?
<jbicha> iulian: no, I guess I could though
<iulian> jbicha: That'd be nice.
<popey> stgraber, thanks
<Laney> phew
<Laney> I feel like we got something of a handle on the release team's queue
<iulian> We are in need of solutions, Laney... solutions!
<Laney> so there's a group of four UIF exceptions that don't seem particularly pressing
<Laney> bug #1049239 bug #1049236 bug #1049235 bug #1049231
<ubot2> Launchpad bug 1049239 in unity-greeter "[UIFe] Add drop shadow under greeter menu bar" [Undecided,New] https://launchpad.net/bugs/1049239
<ubot2> Launchpad bug 1049236 in unity-greeter "[UIFe] The indicator bar at the top of the Unity greeter should be exactly the same height as the indicator bar in the desktop after the user is logged in (24px)" [Undecided,New] https://launchpad.net/bugs/1049236
<ubot2> Launchpad bug 1049235 in unity-greeter "[UIFe] The greeter's session change indicator should only be displayed if more than one session is installed" [Undecided,New] https://launchpad.net/bugs/1049235
<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
<Laney> opinions?
<stgraber> they don't seem particularly pressing though mterry is poking quite regularly about them, especially the last one
<Laney> that might be transitive poking
<jbicha> iulian: shotwell fails to build now http://paste.ubuntu.com/1211325/
<mterry> stgraber, :)  sorry, not particularly Important for quantal, just small change I hoped to squeeze in
<iulian> jbicha: Gah. Could you please attach that to the bug report?
<mterry> (design thinks they are important though)
<Laney> qrfvta guvaxf n ybg bs guvatf :C
 * iulian nods.
<stgraber> ;)
<mterry> snark aside, it does look better with the changes.  I didn't mean to be obnoxious, just wanted an answer one way or the other before we got too far past UIF
<Laney> yeah it's just that we have a large number of changes
<Laney> exceptions to review I mean
<mterry> Laney, fair enough.  I have no objection if these are low on your list
<infinity> mterry: Will you accept a verbal rubber-stamp?
<mterry> infinity, I guess?  If that means I can push to quantal
<infinity> mterry: I'm not sure I "get" the user/pass gap one, but the rest all look/seem like obviously correct consistency fixes to me, not "UI changes".
<mterry> infinity, the gap one is just that I moved the user name down 12 pixels
<Laney> You might want to make jbicha aware if it impacts his screenshots
<infinity> jbicha: ^
<mterry> Laney, jbicha was aware of them originally.  reminding is always good
<infinity> Oh, wait.  He alwready signed off.
<infinity> already, too.
<Laney> oh, good
<mterry> infinity, maybe I have a strict definition of UI change, but it would look different in screenshots (like no ubuntu session logo)
<infinity> mterry: In the name of lightweight and lazy, feel free to quote me from IRC, with this uniquely identified password that NO ONE COULD REPRODUCE EVER: "platypus", and upload away.
<Laney> UIF doesn't have the bug fix/no bug fix distinction as I understand it (because the point is to allow people to make documentation and other visual stuff based off what we're shipping)
<infinity> mterry: No, your strict definition of UI change for the sake of the docs team is perfectly reasonable.  For the sake of FFe, though, none of those things are features, IMO, they're bugfixes.
<Laney> hunter2 is a better password
<mterry> infinity, heh, OK.  Thanks.  Sorry if I was a pain  :)
<infinity> mterry: Nope, all good.  It's only a pain if we keep talking about it. ;)
 * Laney is happy that 4 things get to go away from the list :-)
<Laney> (and that Ubuntu gets better, of course!)
<TheLordOfTime> anyone know if Debian's iceweasel package is related to Ubuntu's firefox package at all?
<infinity> We forked the packaging eons ago.  If they relate at all now (other than sharing some patches back and forth), it's likely coincidental.
<infinity> chrisccoulson would know better, though.  Maybe he's been working more closely with Debian than our previous mozilla maintainers have.
<TheLordOfTime> well i ask because of a request in launchpad to tie a debian bug for iceweasel to a bug in ffox that has an upstream fix and a Wishlist/Triaged on Ubuntu
<TheLordOfTime> i'm not even certain the two are related
<TheLordOfTime> join #launchpad if you want :P
<TheLordOfTime> that's where this discussion is happening
<infinity> Getting it fixed in iceweasel won't get it fixed in Ubuntu, if that's the question.  We don't merge from iceweasel.  But if Mike fixes it in Debian with a backported patch, I'm sure you could point Chris at it to fix it.
<infinity> That said, we pull new upstream versions as they're released, so if it's fixed upstream, we'll get it soon.
<TheLordOfTime> infinity, mind hopping into #launchpad for me and explaining that?
<infinity> I suppose?
<plars> skaet: I was looking a bit further and found more discussion of minimum system requirements here: https://help.ubuntu.com/12.04/serverguide/preparing-to-install.html which answers my question about the disk space for server
<plars> skaet: in the past, it seems that 1G was sufficient for all tasks selected, however right now it's barely sufficient for the base system (to get that working, you even need to manually partition and *not* use swap, because you need the entire gig for install)
<Daviey> iulian: I assume you took it?
<plars> Daviey: ^ also
<plars> anyone happen to know if 1G was really sufficient for all tasks in 12.04? (/me is doubtful of this)
<iulian> Daviey: Yup.
<iulian> I'll take care of it.
<stgraber> plars: for 32bit, yes, for 64bit, mostly
<plars> stgraber: for 64bit, 1G is barely enough if you use all of it for install, and select no tasks in quantal
<plars> skaet, Daviey: Any feedback on the 1G minimum for Ubuntu server?
<skaet> plars,  I'm not sure if this is expected or not,  so defering to Daviey to weigh in if it should be a bug or not.   At any rate,  the serverguide/preparing-to-install.html should probably get updated to reflect current reality.
<skaet> infinity,  https://bugs.launchpad.net/ubuntu-cdimage/+bug/950477 - any update?
<ubot2> Launchpad bug 950477 in ubuntu-cdimage "md5sums are not accurate for daily arm images" [Critical,Incomplete]
<skaet> do we still have this problem?
<cjwatson> Only Lubuntu seems to still have daily-preinstalled.
<cjwatson> cjwatson@nusakan:~/cdimage/www/full/lubuntu/daily-preinstalled/20120917$ md5sum -c MD5SUMS
<cjwatson> quantal-preinstalled-desktop-armhf+ac100.bootimg: OK
<cjwatson> quantal-preinstalled-desktop-armhf+ac100.tar.gz: OK
<cjwatson> I think I got this with the Python rewrite if nothing else.  It substantially rearranged the handling of checksums in general.
<cjwatson> I'll close it after the TB meeting finishes.
<infinity> ScottK: All the KDEish stuff in precise-proposed seems to be v-done and well-aged, should we do a massive release today to clean up the pending SRU page?
<infinity> ScottK: (I'd JFDI, since it's my day, but not sure if you were waiting on something specific before doing the update)
<ScottK> infinity: There are a couple that aren't quite aged yet.
<ScottK> libksane and kdenetwork.
<infinity> ScottK: Oh, I didn't see the new kdenetwork upload.
<cjwatson> I possibly ought to ensure that all pre-existing files have correct checksums.
<infinity> ScottK: (I was happy to let libksane slide)
<ScottK> infinity: If you could look at kdenetwork and see if it's OK, then I'd be good with pushing them all.
<Laney> what's happening with the (precise) image build failures that are coming in?
<ScottK> libksane and kdenetwork are just breaks/replaces so I don't think aging them is important.
<Laney> is this some known failure mode? E: Failed getting release file http://archive.ubuntu.com/ubuntu/dists/precise/Release
<Laney> at debootstrap
<infinity> cjwatson: If you're going to sum them to check, then there's not much point in the caching/reusing thing at all, and we may as well just run the sums on the whole directory every time.
<infinity> Laney: Could be some firewall rules got tightened.
<cjwatson> infinity: As far as I know the new code doesn't sum them to check.
<cjwatson> infinity: "all pre-existing files have correct checksums" - I meant me manually checking things like precise release
<infinity> cjwatson: Oh, right.
<infinity> cjwatson: I think I did all of precise post-release, haven't checked point-releases though.
<cjwatson> I think I just managed to avoid some stupid corner case that was too painful to debug in shell.
<infinity> (I may have done everything in www/ when I did the precise checks, but I don't recall for sure now)
<cjwatson> I rewrote that entire section of code from scratch in a more Pythonic kind of style, and it has a load of unit tests
<cjwatson> It still has a slightly nasty bit incorporating s/// expressions
<infinity> ScottK: The diff for kdenetwork seems perfectly reasonable, but doing an upgrade test to make sure it actually does what people expect would be nice.
<cjwatson> Which *cough* calls out to sed, but you didn't see that code
<infinity> ScottK: And I'm not sure what "friendly" package manager kubuntu uses, but if it's update-manager, a conflict won't actually let you upgrade at all, it'll just put the package on hold.
<infinity> ScottK: (Until you use something more violent, like apt-get dist-upgrade)
<infinity> cjwatson: Yay for forking instead of doing it in Python.  That's what, well, all of my Python looks like. :P
<cjwatson> infinity: I couldn't think of a way to do that little bit natively without unreasonable pain
<ScottK> infinity: This'll only come up on release upgrades, so I think that's fine.
<infinity> ScottK: It won't come up on post-release upgrades that were left in a sad state?
<ScottK> I suppose.
<infinity> ScottK: ie: I already upgraded from 10.04 to 12.04, and that old package is still installed, and now I upgrade to the SRU.  What happens?
<ScottK> You need to dist-upgrade
<infinity> ScottK: Or was it just completely broken anyway, due to the file overlap?  Which, I suppose it would be.
<ScottK> Muon (the KDE thing) will tell you that.
<infinity> Alright.
<ScottK> Then it's clickety click.
<infinity> ScottK: Then someone just doing a quickie lts->lts test to verify would be nice, I guess.  I'll concede the "already upgraded, now SRU" thing probably isn't a concern, cause they were already broken.
<ScottK> Actually it's more complicated.  The package only existed in Maverick, so it's sequential upgrades that are the problem.
<ScottK> LTS to LTS is fine.
<infinity> ScottK: Oh, that's a bit irksome to test.
<ScottK> Yes.
<ScottK> Which is why I didn't do it.
<skaet> infinity - we likely to get the fix for: https://bugs.launchpad.net/ubuntu/+source/live-build/+bug/859552?
<ubot2> Launchpad bug 859552 in live-build "[FFe] Wubi should use ext4 disk images" [Undecided,Triaged]
<infinity> skaet: That's up to ev and the strange win32 build of e2fsprogs that wubi uses.
<infinity> ev: ^
<scott-work> is there a reason the ubuntu studio images are building (and failing) for precise? am i asking an exceedingly silly question?
<stgraber> scott-work: looks like something's wrong with the build machines.
<stgraber> scott-work: Laney poked IS about it already
<scott-work> stgraber: thank you :)
<xnox> infinity: skaet: well I have a work item to learn/automate wubi building + e2fsprogs is kind of my thing nowadays.... maybe I should look into that.
<skaet> thanks xnox
<infinity> xnox: If you can sort out how to get wubi using a current and built-from-source-reproducibly version of e2fsprogs, that would be swell.
<stgraber> oh yeah, fixing that one would be neat. Last cycle I managed to get wubi to work with ext4 but sadly there was no source matching the .exe I found somewhere on the internet, so not something we really wanted to ship (or actually, would be allowed to ship)
<xnox> infinity: i used to have plenty of 'experience' (read vodoo magic & pixie dust) to make random builds for mingw platform, that is "reproducible" builds for Windows ;-)
<xnox> infinity: would lp.net allow uploads for a mingw-w64 arch? =)))))
<infinity> xnox: Yeah, we might want to revisit if we think mingw would pass an MIR, and you could just add e2fsprogs-win32 to the i386 build.
<stgraber> actually, thinking about it, why do we even need e2fsprogs in wubi?
<xnox> or do I have to hack up arch all packages?
<stgraber> IIRC it's for e2fsresize, but we can easily do that on first boot, can't we?
<infinity> stgraber: e2resize, I think.
<xnox> don't we have all the pre-install magic for arm?
<infinity> stgraber: Doing it on first boot is doable (see jasper), but it has to be done from the initrd, which makes things more fragile.
<xnox> "all figured out" (tm)
<infinity> stgraber: Cause you then have to regen the initramfs after.
<stgraber> infinity: well, I'm pretty sure I prefer to debug something going wrong in the initramfs than in a windows version of e2resize...
<infinity> stgraber: I was going to examine live-resizing at one point to try to avoid that, but I suspect it's safer to do on an unmounted filesystem, no matter what people say.
<stgraber> infinity: yeah, I've been doing online resize a few times and it usually works fine, though I don't remember ever doing it on the root partition with a lot of files open...
<stgraber> infinity: I guess doing it from a very early upstart job, blocking the rest of the boot on it should be safe and definitely easier to debug
<infinity> stgraber: Well, doing it from the initrd isn't hard to debug.
<infinity> stgraber: It's just the fiddly part about removing the magic and regenerating the initrd after you've successfully booted once.
<infinity> stgraber: Which isn't all that tough, either.
<infinity> stgraber: So, we COULD do all of that.  Pretty big post-FF feature, though.
<infinity> (From a QA/testing perspective)
 * xnox always did online resizes (no downtime) even with drdb & hearbeat, lvm + raid..... without a hitch. Maybe I just got lucky all ~30 odd times ?!
<stgraber> infinity: can't we use a trick like checking for the number of mounts on the partition and call e2resize if == 0? that should avoid the whole re-generating a new initramfs part of the process
<xnox> increase, as online shrinking is not supported.
<infinity> stgraber: Ew.  No, I'd rather the logic just wasn't in there.
<mcasadevall> /join #TDRevolution
<mcasadevall> bah
<ogra_> stgraber, infinity, just regenerate the initrd from the running initrd, not that hard ...
<ogra_> a few bind mounts and a chroot call
#ubuntu-release 2012-09-18
<Laney> looks like python3-virtkey needs to be promotd
<Laney> O gentle archive admin
<Laney> didrocks: ^ perhaps you could do this (to get daily images today)? python-virtkey probably then falls out I guess (but didn't verify)
<didrocks> Laney: ok, it's python-virtkey -> python3-virtkey basically?
<Laney> yeah, for onboard
<didrocks> doing
<Laney> excellent
<didrocks> done and no reverse-depends for python-virtkey
<didrocks> moving to universe
 * Laney wonders when the ipmitool situation will be cleaned up
<Laney> just checking quantal_probs
<Laney> thanks btw
<xnox> Do I need FFe for fixing bug 1052040
<ubot2> Launchpad bug 1052040 in ubiquity "[regression] ubiquity greeter does not have overlay scrollbars in quantal, but it did in precise" [Medium,Fix committed] https://launchpad.net/bugs/1052040
<xnox> see attached screenshots.
<xnox> well... not FFE, but rather UIFE
<Laney> xnox: you should ask #ubuntu-docs or their ML if it's in any screenshots
<Laney> but otherwise consider it approved from my pov
<iulian> xnox: If it is a regression and you guys didn't want to change it, then I'd consider it a bug fix.
<xnox> Laney: well... it's on here http://www.ubuntu.com/download/help/install-ubuntu-desktop
<iulian> Oh, I'm too slow this morning.
<Laney> it is
<xnox> Laney: * Cannot join #ubuntu-docs (Channel is invite only).
<Laney> -doc?
<Laney> I guessed TBH
<Laney> maybe they don't have a channel, if so just mail the list instead
<iulian> #ubuntu-doc seems to be genuine.
<Laney> \m/
 * xnox is confused about Laney \m/
<Laney> http://thumbs.dreamstime.com/thumblarge_530/1282035293x7EkQE.jpg
<iulian> He doesn't want to show his head, only feet. It's sort of like a Laney 2.0, cyberman.
<iulian> Oh, was wrong.
 * xnox is not down with the kids
<iulian> OK, uni time, ta-ta.
<babyface_> why no quantal  desktop isos today ?
<babyface_> anybody know this ?
<Laney> component mismatch
<Laney> will be fixed soon
<babyface_> Laney,  are you talking to me ?
<Laney> yes
<babyface_> Laney, ok, got it. thanks.
<Laney> onboard depended on a package in universe which we just promoted to main this morning
<Laney> babyface_: respinning now
<Laney> babyface_: should be there now
<balloons> ping cjwatson
<cjwatson> balloons: best to include a reason please
<balloons> cjwatson, sorry mate. I wanted to chat with you about the tech board summary.. Specifically, I wanted more information on the nvidia drivers decision(s)
<balloons> when will the changes occur -- and it looks like both precise and quantal will get new -experimental packages for nvidia/fglrx. Will these also show in jockey?
<cjwatson> I'm mainly the secretary here :-)  Talk to bryceh and pitti about implementation details
<balloons> cjwatson, thanks.. will do
<cjwatson> wg 27
<cjwatson> oops
<xnox> Can somebody look at bug 1042649
<ubot2> Launchpad bug 1042649 in ubiquity "[FFe] [UIFe] Manual Partitioning Crypt" [Undecided,New] https://launchpad.net/bugs/1042649
<xnox> ?
<xnox> it is now ready to be uploaded and it was previously discussed at the release meetings.
<xnox> I have notified doc & translation teams before, but will notify them again, once this is uploaded.
<stgraber> xnox: well, they need to ack prior to upload
<xnox> stgraber: ok. Before or after FFe is granted?
<stgraber> well, at least the doc team should
<stgraber> xnox: before
<xnox> ok.
<stgraber> we can still review the FFe but the best we can give you is a conditional +1 on doc + translation approving it
<stgraber> xnox: planning to land that for beta2 I guess?
<xnox> stgraber: yes.
<xnox> stgraber: I am also planning to land lvm2-advanced before beta2 (bug 1042647) but that is not ready yet.
<ubot2> Launchpad bug 1042647 in ubiquity "[FFe] [UIFe] Manual Partitioning LVM" [High,Confirmed] https://launchpad.net/bugs/1042647
<xnox> stgraber: well I emailed the ubuntu doc team mailing list. there was no response last time though....
<stgraber> xnox: try to poke jbicha on IRC
<xnox> stgraber: ok.
<stgraber> he doesn't seem to be online at the moment, but he's usually not too far away
<knome> stgraber, any ETA when bug 1039158 is pushed to production?
<ubot2> Launchpad bug 1039158 in ubuntu-qa-website "Add css to have dl/dt/dd show as numbered list for testcases" [Wishlist,Fix committed] https://launchpad.net/bugs/1039158
<knome> stgraber, i mean, the fix, not the bug ;]
<stgraber> knome: fixing other things first, hopefully before beta2
<knome> stgraber, ok, no hurry, just wondering :)
<knome> stgraber, but it would be nice to get it in before beta freeze
<stgraber> knome: well, the tracker isn't subject to beta freeze but yeah, should be rolled out before the weekend
<knome> stgraber, i know... but it affects the testing experience, and we might to some cooperation with a local uni, and we might get up to 60 testers
<knome> anyway, bbl
<Laney> ogra_: any chance we can get that linux-ti-omap4 copied to release?
<cjwatson> Laney: infinity's on it (#ubuntu-installer)
<cjwatson> assuming you mean quantal
<Laney> sure do
<Laney> cheers
<ogra_> Laney, right, infinitys job rather than mine
<ogra_> he eats kernels for breakfast ;)
<infinity> Om nom nom.
<Laney> Flickerless panda plz
<infinity> I'll flicker your panda.
<infinity> And because I haven't been mesmerised by it yet this morning, it's time for: http://lucifer.0c3.net/~adconrad/loose-pandas.gif
 * Laney hopes no children are watching
<ogra_> hahahahaha
<ogra_> thats like my 5 (!) racoon babies that visit me every evening :)
<ogra_> (we never had 5 before ... 2 in max, seems leaving my garden alone improved the ecosystem for racoons)
<cjwatson> infinity: That's fifty shades of awesome
<skaet> Laney, https://bugs.launchpad.net/ubuntu/+source/unity-lens-music/+bug/1049593 - could you check that your concerns have been addressed?
<ubot2> Launchpad bug 1049593 in ayatana-design "[FFE][UIFE]Dash - Finesse the placement, movement and behaviour of the 12.10 Dash " [Critical,Fix committed]
<Laney> skaet: what do you think?
<skaet> Not answering the regression question, but much more detail provided on the fixes associated with this.
<skaet> Lots of the contents in the description seem like fixes to me.
<Laney> yep
<Laney> still misses -doc notification
 * Laney tries and fails to tab complete jbicha
<skaet> yeah,  haven't seen him since earlier this morning.
 * Laney wonders about a dash sprint taking place after UIF ;-)
<ogra_> Laney, to get clean ?
<Laney> ?
<ogra_> http://arch9.okr.ro/auctions/2009/06/20/238872979-3315892-500_500.jpg
<Laney> haha
<didrocks> tssss ogra_ :)
<Laney> we don't have that over here
<ogra_> con bicarbonato !
<Laney> so the joke kind of passed me by :P
<ogra_> :)
<xnox> is that how the blur effect is done?!
<xnox> =)
<didrocks> in France, it's "Dash 2 in 1" :)
<ogra_> haha
<skaet> Laney,  getting comments on the fallback plan added now.
<Laney> by drinking it?
<ogra_> didrocks, same in germany :)
<Laney> skaet: you might as well ask them to mail the docs team while you're at it
<didrocks> it's not like if I didn't pointed them almost 100x times about the process page for both FFe and UIFe
<skaet> Laney, didrocks. done.
<didrocks> skaet: thanks
<skaet> didrocks, https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1042323 - is this ready to land for beta 2,  can't tell.
<ubot2> Launchpad bug 1042323 in compiz "[FFE] Port GTK Window Decorator to GSettings" [High,Fix released]
<cjwatson> Laney: can I just unsubscribe ubuntu-archive from bug 1046649, since backporters can process backports themselves now?  or is there any other fixup I need to do?
<ubot2> Launchpad bug 1046649 in precise-backports "Please backport fonts-cns11643 98.1-1 (multiverse) from quantal" [Undecided,Confirmed] https://launchpad.net/bugs/1046649
<skaet> jbicha, could you look over https://bugs.launchpad.net/ubuntu/+source/unity-lens-music/+bug/1049593 and comment on impact?
<ubot2> Launchpad bug 1049593 in ayatana-design "[FFE][UIFE]Dash - Finesse the placement, movement and behaviour of the 12.10 Dash " [Critical,Fix committed]
<cjwatson> I'm confused about why ubuntu-release was ever subscribed to that bug in the first place.
<Laney> cjwatson: he said -release but meant -archive AFAICS
<Laney> and yeah, just remove the subscription unless you particularly fancy uploading it
<Laney> NCommander: ^ you should just upload it
<Laney> (using backportpackage to prepare the package for you)
<cjwatson> Laney,NCommander: OK, done
<Laney> cheers
<jbicha> skaet: I looked at it & wasn't happy about how huge of a bug it was, can you let my email response to ubuntu-release through?
<skaet> jbicha, will do
<Laney> jbicha: thatnks for that mail
<skaet> Laney, https://bugs.launchpad.net/unity/+bug/713423 -- not sure I'm following wha you're still looking for on this one.  The questions you asked seem to have been answered.
<ubot2> Launchpad bug 713423 in ayatana-design "[FFe/UIFe] Unity launcher gets cluttered when having multiple partitions and/or external volumes attached" [High,Fix committed]
<Laney> skaet: does it have uife?
<skaet> Laney, https://bugs.launchpad.net/unity/+bug/713423/comments/21
<ubot2> Launchpad bug 713423 in ayatana-design "[FFe/UIFe] Unity launcher gets cluttered when having multiple partitions and/or external volumes attached" [High,Fix committed]
<Laney> good
<Laney> I wasn't necessarily still looking for anything
<Laney> well, he didn't say when it could land :-)
<skaet> He said it was ready to land now.
<skaet> but they're blocking on FFe approval,  so I'm trying to get it resolved.  :)
<Laney> oh
<Laney> let me approve it quickly
<skaet> Thanks.  :)
<Laney> i'm busy fixing a different build failure atm, so my brain isn't really in release mode
<skaet> Thanks
<Laney> doko: speaking of that, please take drift off the blacklist
<Laney> it is fixed and I'm going to NMU it
<doko> Laney, ok
<xnox> skaet: Laney: I got +1 from documentation teams for bug [FFe & UIFe] 1042649 and bug [UIFe] 1052040
<xnox> are those ok to be uploaded from release team point of view?
 * xnox kinda had an ok from stgraber earlier, but I'm not sure if it counts.
<xnox> and kinda from skaet / release team meeting
<xnox> but not explicit.
<xnox> hence poking about it again =)
<knome> in non-clear issues, i'll just interpret to be the best alternative for me ;]
<skaet> xnox,  backed up looking at 2 issues ahead of you.   Will check those next if someone doesn't beat me to it. ;)
<Laney> UIFe fine, FFe I'm not so sure, I'll let stgraber decide
<Laney> given the *cough* fun at b1
<xnox> Laney: in theory, if it lands now & fun repeats it will be fixed by friday. Not landing it on friday and having the fun all the way to next tuesday.
<xnox> Laney: for example I will not consider uploading it Thursday afternoon or later. I'll upload it into ppa or -proposed.
<xnox> Laney: I didn't like b1 at all...
<Laney> well, fun happened last time when people started testing the installer in earnest
<Laney> i.e. next week
<Laney> I assume you still need a code review to land it anyway?
<xnox> Laney: true, if I find someone to review it. The usual suspects for partman are very busy. (colin, stephan, ... not sure who else)
<Laney> I dunno, it just makes me wary
<Laney> but I defer to someone else rather than nacking
<xnox> Laney: you reserve the right to say "i told you so" ;-)
 * xnox ponders if quantal beta1 will be reminded to me every time i make freeze exception requests.
<jbicha> skaet: by your comment on bug 1005682, I presume you want us to revert to WebKit 1.8 since 1.9.2 as a development snapshot isn't really supportable
<ubot2> Launchpad bug 1005682 in webkit "FFE: Update webkit to 1.9.91" [Wishlist,In progress] https://launchpad.net/bugs/1005682
<jbicha> I guess the Release Team shouldn't have been subscribed anyway until newer WebKit versions didn't FTBFS
<skaet> jbicha,  yes,  the commentary in the bug pointed that it would be safer to stay with 1.8 at this point.
<Laney> erm
<Laney> did it break ABI since 1.8?
<infinity> Yeah, reverting webkit sounds like a lot more trouble than it's worth.
<jbicha> Laney: um, probably? you're welcome to dig through the diff at https://launchpad.net/ubuntu/+source/webkit/1.9.2-1ubuntu1
<infinity> Laney: Everything would absolutely have to be rebuilt, if it was rebuilt against 1.9
<infinity> Laney: As for *API*, I'm less sure.  Seems to be conflicting reports about epiphany, or are we just shipping an old version?
<skaet> Laney,  infinity - what's in the archive right now is webkit_1.8.1 - I was just trying to advocate we stay at it, rather than approve the update.
<Laney> Dunno. It sound like a pain in the backside.
<infinity> Oh.
<jbicha> skaet: no, a developer snapshot 1.9.2 is currently in the archive
<Laney> https://launchpad.net/ubuntu/+source/webkit/1.9.2-1ubuntu4 that's what we have currently
<infinity> skaet: Err, yeah.  It's 1.9.2
<infinity> skaet: You're looking at precise.
<infinity> I think the sane way forward here is probably forward, with a hard commitment for the desktop team to update quantal to 1.10 final, even if it lands post-release.
<skaet> infinity,  was looking: http://archive.ubuntu.com/ubuntu/pool/main/w/webkit/?C=M;O=D
<infinity> But if reverting really is painless, that would do.
<infinity> skaet: https://launchpad.net/ubuntu/+source/webkit
<jbicha> all we need is to magically get WebKit 1.9 to build in quantal :)
<infinity> skaet: Much easier to decipher than a directory full of files.
<skaet> infinity, yup, see it now.
<infinity> jbicha: Oh.  It stopped building at some point?
<jbicha> I believe the current version builds, it's future snapshots that aren't buildable yet
<infinity> Ahh, right.  Following the bug breadcrumbs.
<jbicha> infinity: We're stuck with a developer snapshot of Epiphany until we get the newer WebKit as the dependency was bumped
<skaet> infinity, Laney - please comment on path of least risk on the bug.   I'm definitely leaning to least risk at this point.
<infinity> Well, if someone can make a snapshot build, pushing to 1.10 sounds less painful than reverting and rebuilding the world.
<infinity> And less "risky", in the sense that it's closer to what people have been testing.
<infinity> Reverting to old software (when it interacts with other new things) doesn't magically mean you get to be as bug-free as precise.
<Laney> and it might not just be a matter of rebuilding everything (if new stuff depends on new stuff)
<skaet> infinity,  yeah, understood.   micahg,  what's possible?
<cjwatson> how big is the reverse dep tree anyway?
<jbicha> Mageia was also having trouble getting WebKit 1.9 to build
<infinity> 140 reverse build-deps.  Not sure how far down the tree that gets one.
<cjwatson> ow
<cjwatson> and those are all on 1.9 already?
<infinity> And not sure how many things have been rebuilt against the new ABI (and thus need a rebuild) versus need the new API (thus needing a revert as well) and how many wouldn't need to be touched.
<infinity> A versioned rdep scan would be more accurate for the ABI-rebuild question, the API one's a bit tougher.
<infinity> And might just be epihany, if we're lucky.
<Laney> I gave it back in the PPA, you never know.
<skaet> infinity, Laney - have reset it back to inprogress for quantal,  based on the above comments.   If one of you encounters micahg while I'm offline, can you discuss this further with him and see what the path of least pain is here?
<knome> skaet, it's not too funny when we're past FFe and suddenly our image jumps up 6MB of gnome dependencies... :/
<cjwatson> In case anyone wonders, the new upstream releases of libpipeline and man-db I just synced are bugfix-only, mainly to defend against near-future glibc and automake changes.
<knome> cjwatson, thanks for reviewing indicator-sound
<cjwatson> Not sure that was me actually
<knome> skaet, looks like it's the onboard stuff, that depends on mousetweaks, and depends on much more gnome stuff
<knome> skaet, this. is. not. funny. after. FFe.
<skaet> knome.  agreed.
<knome> thanks. (ed: that was the very very mild version i forwarded to release team)
 * skaet needs to break away from IRC so she can catch up on todays mail.   *sigh*
<cjwatson> knome: bug 1041303, apparently
<ubot2> Launchpad bug 1041303 in onboard "Feature freeze exception request: Plz update Onboard to 0.98.0 targeted at quantal" [Medium,Fix released] https://launchpad.net/bugs/1041303
<cjwatson> (I had no involvement - just for reference)
<knome> well yeah. it sucks. is some action going to be taken or is it just going to be left as is?
<cjwatson> I don't know - have you talked with the people who proposed the update in the first place?
<cjwatson> that's probably better than going through -release in the first instance
<knome> no, because we just found this out a few minutes ago
<cjwatson> right, but you had time to talk to the release team ;-)
<knome> sure.
<knome> i thought the release team was on top of things like this (as you were - thanks)
<cjwatson> just saying, if you're asking about action then it's generally best to talk to relevant developers first
<cjwatson> rather than "pre-escalating" if you will
<knome> i don't really know how to proceed anyway - what is it that i'm actually able to do myself? should i ask them to revert the whole package as it affects us, or simply dropping the dependency (which they seem to need)
<knome> ok, comment added to the bug
<knome> is there something else we can do?
<Laney> if mousetweaks is a problem then it is a recommends, so may be able to be removed
<Laney> I suggest you talk to the uploader.
<knome> how do i check who is the uploader?
<Laney> the bug says
<Laney> but file a /new/ one, instead of commenting on this old done one.
<Laney> Maybe mousetweaks itself could get fixed.
<knome> yeah, maybe, but before b2freeze? i doubt so.
<Laney> Who knows?
<cjwatson> knome: you should explain the problem to them and have a conversation about it
<cjwatson> rather than pre-specifying possible solutions if you aren't sure
<knome> sending an email.
<Laney> TheMuso is someone to speak to about mousetweaks, judging from the changelog.
<jbicha> oh I guess you could change the dependency back to mousetetweaks (misspelled) ;)
<knome> jbicha, i'd laugh at that if it was earlier in the cycle, but it's <2 days to beta 2 freeze and this brings 6MB more packages to our already oversized ISO.
<knome> somebody on the release team, maybe approver, wants a CC of the mail to be on top of the issue?
<Laney> I think you'll be happier if you speak to TheMuso on IRC
<knome> idle for 18 hours.
<knome> Laney, PM'ing, if he doesn't reply soon (>2am here), i'll send the mail and add you both to the CC.
<Laney> don't bother adding me
<knome> can you explain why?
<Laney> I can't speak to the merits of the change you're asking for, so I don't see what point me receiving an email about it has
<knome> you approved the FFe?
<knome> TheMuso said he doesn't know anything about the packaging.
<knome> ok, he's demoting mousetweaks to suggests.
<Laney> did you ask him about the g-c-c recommends from mousetweaks?
<knome> no, i didn't
<Laney> I'd have thought that would be a better first place to look
<knome> i have no idea about the packaging, the requirements, or anything else regarding to this issue either.
<Laney> perhaps some investigation would reveal that it could be Enhances.
<knome> perhaps
<Laney> I'll leave you with that
<Laney> night.
<knome> sleep tight
<knome> too bad i'm not competent to investigate that
#ubuntu-release 2012-09-19
 * micahg is catching up on backscroll
<micahg> infinity: jbicha: Laney: I'm all for keeping 1.8 in quantal as that'll make us standardized on 1.8 in the stable releases for the time being
<micahg> but I'll leave it to the desktop team to make the call on which version they think is best suited
<micahg> but IMHO, staying on 1.9.2 isn't an option as if there's any breakage between 1.9.2 and 1.10.0, we'd have to deal with that in a security update which I'd like to avoid
<Laney> micahg: the problem is it's not "keeping", it's "reverting to"
<Laney> wow
<Laney> looks like upstream ship a patched make to get around "Argument list too long"
<Laney> ship as in with jhbuild, not in their tarballs :P
<xnox> Laney: is the patch written in XSLT and XPATH to better integrate with jhbuild? =)
<Laney> iulian: you still handling bug #1046461?
<ubot2> Launchpad bug 1046461 in shotwell "[UIFe] [FFe] UOA integration needs to support multiple accounts" [Undecided,New] https://launchpad.net/bugs/1046461
<iulian> Laney: I am, yes. I'm waiting for a successful build.
<Laney> sounds like there's a patch?
<iulian> That patch is not working because of http://redmine.yorba.org/issues/5803.
<Laney> that's what I am referring to
<Laney> the "fix" to add --enable-deprecated
<popey> skaet, were we not having another catchup meeting today?
<Laney> popey: this afternoon
<iulian> Laney: Right but the patch wasn't updated.
<iulian> I mean, the attached patch in launchpad.
<iulian> 06_uoa.patch
<iulian> Laney: Having said that, I'm happy with the change, I just want to make sure that the changes do what they are meant to do.
<Laney> well, if you want, you can very easily take it yourself to test
<iulian> jbicha volunteered to test it. He was the one who spotted the build failure.
 * Laney shrugs
<Laney> I am just aware of the fact that B2 freeze is tomorrow
<iulian> Okey dokey. I shall test that myself later on today if jbicha doesn't beat me to it.
<hallyn> jdstrand: hi - so re bug 1040033 how do you feel putting that into q?
<ubot2> Launchpad bug 1040033 in qemu-kvm "Fresh VM installs via preseeded oneiric isos sometimes fail with filesystem issues" [Critical,Triaged] https://launchpad.net/bugs/1040033
<hallyn> (i'm queesy)
<jbicha> hallyn: is that somewhere between quantal and wheezy?
<highvoltage> nice catch, jbicha
<hallyn> ouch
<skaet> popey,  Double checked the invite and you weren't there.  Inadvertant mistake on my part.  fixed now.
<xnox> hallyn: for what it's worth there were similar reports against ubiquity when installing quantal in the vm (as part of iso testing) with files disappearing.
<xnox> hallyn: but I don't think I paid attention to them much, e.g. tag hardware-error & 'oh it works fine now' comments
<popey> skaet, thanks
<jdstrand> hallyn: well, upstream has released 1.2 and we have an 1.1rc with a major known bug? I would highly consider 1.2 for maintenance reasons alone. If it passes test-qemu.py and test-libvirt.py, seems like something we should pursue
<hallyn> jdstrand: test-qemu.py had some failures for me - but i couldn't fgure out what they meant (or repruduce by hand)
<hallyn> while we straighten that out, do i need a bug to request FFE for jumping to 1.2?
<hallyn> or do i just ask here?
<jdstrand> hallyn: is it actually adding features? or is 1.2 just a collection of bug fixes over 1.1rc?
<hallyn> jdstrand: i dunno, i counted 6k commits and assumed there was a feature in there somewhere
<jdstrand> that's a lot of commits. I think you need a bug
<hallyn> ok
<hallyn> jdstrand: it adds seccomp support, actually.  feature.
<jdstrand> hallyn: ah yes, but a good one :)
<hallyn> jdstrand: bug 1052932
<ubot2> Launchpad bug 1052932 in qemu-kvm "[FFE] merge upstream v1.2.0" [Critical,New] https://launchpad.net/bugs/1052932
<hallyn> I'll set up another laptop to do some heavy manual testing...
<jdstrand> hallyn: ack. commented in the bug
<plars> From what I understand, some recent changes may have made it so that we can no longer support upgrade from cdrom (no-network upgrades for example)
<plars> Can someone confirm this is true?
<cjwatson> Yes, since we no longer publish alternate CDs containing .debs
<cjwatson> And you can't upgrade from the desktop CD
<cjwatson> Well, not the same way
<plars> cjwatson: ok, thanks
<cjwatson> You can do an "upgrade" (mad handwave) which is actually an install over the top that attempts to preserve user data and some semblance of the extra packages you had installed
<cjwatson> But not an upgrade by packages
<skaet> cjwatson,  any way to translate that mad handwave into some written guidance (ask ubuntu question?)   I suspect this question will come up again.
<xnox> skaet: it's actually called Re-install while preserving user data and configs
<xnox> "In-place"
<xnox> it is our answer to "you should have separate /home to support reinstalls without loosing your data" when you have a single partition only.
<skaet> plars, balloons - do we have a QA test that tries this ^ ?
<skaet> thanks xnox
<xnox> skaet: I think we have a bug report that 12.10 doesn't offer it for 12.04 installed on disk =/
<skaet> xnox,  if you can find the bug number for it,  that would be good.   Definitely something we'll want to document in beta 2 Technical Overview notes as a known issue.
<xnox> skaet: bug 1050562
<ubot2> Launchpad bug 1050562 in ubiquity "Upgrading Ubuntu 12.04.1 from iso isn't given as an option" [High,Confirmed] https://launchpad.net/bugs/1050562
<cjwatson> skaet: probably ought to be documented somewhere, ideally as an alternative link on http://www.ubuntu.com/download/desktop/upgrade - not sure I have time at the moment though
<plars> skaet: indeed, I don't think we do right now, but I think we should certainly test this in place of not having cdrom upgrades
<plars> balloons: can we add this to the isotracker, even though we know it has a problem with it right now?
<gema> micahg: o/
<balloons> skaet, hmm.. I'm not sure we have a specific case for it
<balloons> plars, yes, bugs or not if we have a valid testcase we can add it
<skaet> balloons,  can you work with plars to get one written and added?
<balloons> skaet, plars yes, give me a couple mins to finish up meeting
<skaet> thanks.
<micahg> skaet: so, the issue was brought up that QA shouldn't tag stuff that isn't supported with the rls tracking tag, so, I was thinking that RC items that aren't supported still need to be tracked somehow, this was previously done with targeting/milestoning I believe (usually someone committed to fixing it though)
<micahg> now that I think about it, while we've had milestoning in the past, Ubuntu doesn't seem to have the same type of RC bug concept that Debian does (in that a package with an RC bug can't be released as stable), I don't think we should necessarily go that far, but I think it would be nice if have a way to flag any package with an RC bug so that people interested can work on those RC bugs before the release
<micahg> (well, actually, it would be nice to remove RC buggy packages before release, but we've have to make sure the RC bugs are validly RC)
<skaet> micahg, https://wiki.ubuntu.com/RCBugTargetting - has the  new tagging flow incorporated.   If a bug is part of the release but not release critical,  it can be handled by targetting to as series, but putting rls-q-notfixing tag on it.
<gema> skaet: QA cannot tag a bug as rls-q-notfixing
<gema> skaet: what do we know if it needs to be fixed?
<micahg> skaet: we have different levels of RC those, we have RC with a team behind it, RC on an image, RC in the archive
<skaet> gema,  agreed QA should be using the tag rls-q-incoming.    Development should either target to series and decide if rls-q-notfixing is appropriate or not.
<micahg> skaet: the problem is for packages without a specific team behind them
<micahg> which inherently won't use/review the rls-* tags
<gema> didrocks: ^^ see skaet's answer?
<gema> didrocks: are you happy with that?
<didrocks> skaet: in that case, don't expect me to triage rls-q-incoming for now
<skaet> micahg,  those actually do show up in the tracking report - in the "other" section.
<didrocks> skaet: I have more than enough work with all the PS stuff + assignement to the team
<didrocks> doing papework to reject components on universe is silly IMHO
<micahg> skaet: how are the packages associated with teams?
<didrocks> like I cleaned the -incoming one yesterday evening
<skaet> didrocks,  you sholdn't be seeing universe packages,  only desktop ones.
<didrocks> got 16 this morning
<didrocks> skaet: there were and that was what I raised
<didrocks> like indicator-weather
<skaet> hmm...   we may need to review the list then of what's going to desktop, and what shouldn't be.
<micahg> skaet: where's this list again?
<skaet> micahg,  its a googledoc spreadsheet.
<gema> skaet: can we see it?
<skaet> gema,  its pulled into the arsenal project
<gema> skaet: dunno what that project is
<micahg> I'd like to bring up that "other" category in the MOTU meetings, ideally we can find some volunteers to wade through the list
<skaet> micagh,  that would be great!   :)
<micahg> but we have to be able to see the doc :)
<skaet> gema, micahg:  https://launchpad.net/arsenal/2.x
<micahg> this is run locally?
 * gema -> meeting
<skaet> http://bazaar.launchpad.net/~bryce/arsenal/2.x/files/head:/reports/package-team-mappings.csv is a copy
<cjwatson> I used to be able to see that doc on docs.google.com (now drive) but I don't seem to be able to find it any more
<cjwatson> as usual google docs is a great way of losing stuff :-(
 * skaet grumbles about drive conversion as well.
<cjwatson> well, it wasn't great before either
<balloons> ok plars, so this testcase in question is specific to re-using my home partition.. really it's an extension of the manual partitioning testcase
<balloons> we don't actually track what you do when you hit 'manually' partition, so the testcase is a bit wide open. We have some ambiguity in our testcases.. this is another case of that it sounds like
<cjwatson> hmm
<cjwatson> so the package-team-mapping spreadsheet I can find has coq mapped to universe
<cjwatson> why is it showing up on foundations lists?
<cjwatson> FWIW skaet's URL above should be https://bazaar.launchpad.net/~bryce/arsenal/2.x/view/head:/reports/package-team-mapping.csv (s/mappings/mapping/)
<cjwatson> hm, stale cache maybe?
<micahg> also has indicator-weather in desktop
<doko> jibel, skaet, cjwatson: unsure about 1003910. I can't reproduce this, and don't understand jelmer's comment about python3.
<cjwatson> well, it's true enough, follow the packages.* links
<cjwatson> perhaps a dh_python[23] problem that mis-substituted shebangs?
<cjwatson> although it only seems to be subunit-notify that's 3.2
<cjwatson> so maybe he misread something
<jibel> doko, I can't reproduce it either on a fresh installation of Quantal.
<jibel> doko, the shebang line changed from "/usr/bin/python3.2" in subunit 0.0.7+bzr162-1 to "/usr/bin/env python" in 0.0.8+bzr176-1 which fixed the problem
<doko> jibel, ahh, ok
<cjwatson> plars: So, bug 1050595.  The 128MB install died before partitioning so this isn't relevant - but in the 256MB log I see that you have no swap configured.  Why's that?  With low-memory install tests we should definitely ensure that some swap is present; d-i only makes any effort to conserve memory before the point when swap is brought up.
<ubot2> Launchpad bug 1050595 in lowmem "Ubuntu Server installation with 128M ram hangs" [Undecided,New] https://launchpad.net/bugs/1050595
<plars> cjwatson: I was testing the bare minimum requirements, which was 1G of disk and 128M ram, and had already determined that the only way 1G was possible (even with a base system) was to manually partition and use all for /. I've already referred this to the server team and jamespage is looking into it
<cjwatson> OK, but the bug here is only about memory
<cjwatson> The disk requirements definitely need to include provision for sufficient swap space
<plars> cjwatson: I'll give it a try with swap also
<cjwatson> Anyway, it won't help the 128M case, but 256M with swap should work
<cjwatson> Since the OOMs don't start until after when swap should have been configured
<plars> cjwatson: at the time I opened it, it was still unclear as to whether 1G should just barely fit like that, but it could be that the disk space is the bigger issue
<cjwatson> We should expand disk before skimping on memory, certainly
<jbicha> um, I guess Design really wants bug 1049593 approved any way
<ubot2> Launchpad bug 1049593 in unity "[FFE][UIFE]Dash - Finesse the placement, movement and behaviour of the 12.10 Dash " [Critical,Fix committed] https://launchpad.net/bugs/1049593
<xnox> doko: and in the mean time dh_python3 dropped shebang rewritting "bug/feature"
<doko> xnox, thanks for the pointer
<doko> Laney, cjwatson: could somebody look at the libjpeg-turbo FFe (new version, but almost all changes are bug fixes). I'd like to get this in before the beta.
<infinity> doko: Did someone get to your libjpeg-turbo FFe?
<infinity> doko: Oh, I see, it's tied up with the SRU bug.
<infinity> doko: FFe approved.
<iulian> Laney: I've got to do more work than I expected with shotwell so I cannot fully test it today unfortunately. Vala 0.17.6 is also needed apparently.
<iulian> It would be nice if we could get it in before the freeze.
<iulian> jbicha: Fancy testing shotwell with that patch applied? It builds fine with --enable-deprecated.
 * iulian -> gone.
<skaet> jbicha, around?
<jbicha> skaet: yes
<xnox> skaet: just filed bug 1053030 not sure if I did everything right to cause attention for the release notes.
<ubot2> Launchpad bug 1053030 in ubiquity "highly confusing UI on desktop panda when no external storage is attached" [High,Confirmed] https://launchpad.net/bugs/1053030
<stgraber> xnox: I guess the same would apply to any system that doesn't have some kind of storage attached?
<xnox> stgraber: true.
<stgraber> though it's weird that it passes the prepare step
<stgraber> it should get stuck on the prepare step as it doesn't have enough space for installation
<xnox> stgraber: but there is =) because it's a 8GB sd-card
<xnox> and the first two partitions are only ~1GB
<skaet> thanks xnox.   something's not working properly with milestoning release notes project to quantal.   Will look into it later.
<stgraber> ah, that's the problem then ;) we shouldn't consider the install media when evaluating if there's enough space on the system
<xnox> stgraber: apperantly not, as cjwatson pointed out there are OEM systems that install that way from USB back on to USB.
<xnox> so we should "support it"
<jbicha> it used to be easily possible to boot from an ISO on the hard drive (say if you had grub already installed) & use that to install to the same hard drive
<jbicha> for the last few releases, that use case has been broken without hacking it to work
<jbicha> I used to do that since Startup Disk Creator hasn't been very reliable in development cycles
<stgraber> xnox: ?? surely you can't install to your install media, there's no way that'd work.
<stgraber> I'm not saying we should blacklist all non-local devices, I'm saying we need to blacklist the device that's mounted to /cdrom as that one can't possibly be used to install the system
<xnox> stgraber: sure you can, if it's pre-partitioned =)
<stgraber> xnox: yes, and then the check would succeed
<stgraber> xnox: In the case of a partitioned media, you'd only blacklist the partition on which /cdrom sits
<xnox> stgraber: somehow it succeeds even though I don't have remaining space partitioned. And d-i locks only the /cdrom
<xnox> but then lets me modify it anyway....
<stgraber> I can't remember exactly what the check looks at. I know it's not looking at available partitioned space, otherwise you couldn't install on a new disk (which would be kind of bad).
<xnox> stgraber: let me partition it correctly and see how ubiquity behaves
<stgraber> one trick would be to take device size - size of /cdrom parittion
<stgraber> so if the /cdrom partition takes the whole device, you would have 0 bytes left so the check would fail, but if you pre-partitioned and gave /cdrom 1GB, then you'd have enough space and ubiquity would let you continue
<xnox> cause currently it flat out does not expect that d-i will not ask 'autopartitioning' question and start with 'manual choose partition' question. Breaks the state machine =)
<cjwatson> stgraber,xnox: intended behaviour is that you should be able to partition anything after the installation-medium partition; it doesn't have to be pre-partitioned
<cjwatson> I don't consider it important for it to provide autopartitioning in such a case, though - I think it would be OK for that to be manual-only
<cjwatson> perhaps that was broken by the installer redesign in maverick, which started deriving more complex UI from the partman state machine
<xnox> cjwatson: but surely biggest_free should be doable in this case
<ogra_> cjwatson, well, it still tries to update the partition table while the install medium is mounted and usually fails
<ogra_> (if you try to create a partition behind the install media one)
<xnox> ogra_: and if it fails it tells you to reboot, which is fine.
<ogra_> fine apart from the fact that it made me first think this was a possible procedure
<cjwatson> xnox: in principle yes; but I don't remember whether that's how it behaves, and it wouldn't be a big deal if it weren't
<ogra_> it doesnt iirc, you get and error and apport
<xnox> =(
<ogra_> (try it, since you seem to have such a setup running atm)
<xnox> can somebody please explain why is it not possible sometimes to update partition table of the install media when it is mounted?
 * xnox  is probably missing some fundamental point here, but it's 2012 and linux kernel at 3.5, why can we still not do this ?!
<ogra_> well, theoretically it should be ...
<ogra_> (i know i used blockdev's rereadpt option on mounted devices in the past and that worked flawless)
<cjwatson> ogra_: as described, that's a bug I'm not familiar with.  libparted is supposed to disregard remove/add failures when the new partition is unchanged
<cjwatson> libparted/arch/linux.c:_disk_sync_part_table if you want to look into it
<ogra_> well, its a while ago that i tried it last actually, i might misremember the error popping up
<ogra_> though i think one of the balloons community army filed such a bug
<cjwatson> ok, so do check facts first before going on a debugging expedition :)
<ogra_> heh, indeed
<ogra_> xnox, bug 1042930
<ubot2> Launchpad bug 1042930 in ubiquity "partition size error during install of Quantal on Panda board" [Undecided,Confirmed] https://launchpad.net/bugs/1042930
<stgraber> skaet: just figured out what was broken with product owners on the tracker. Next roll out will be working again with edubuntu-release being the only team setup for now
<skaet> stgraber,  glad its figured out.  :)
<stgraber> it was a pretty weird bug in the ACL checking, kind of surprised we didn't have other problems because of it... anyway, the fix is also making the ACL checks twice as fast (not that they were particularly slow)
<phillw> skaet: do you have a couple of minutes?
<skaet> phillw, am otp right now,  will ping when I get off.
<phillw> ta
<xnox> skaet: Fedora releases alpha 18 with "redesigned installer" and a following release note "The Anaconda installer for Fedora 18 Alpha will format the entire disk unless custom partitioning is selected."
<xnox> if only we did releases like that....
<doko> infinity, thanks
<jbicha> xnox: epic release note, and they pushed back the release date 3 weeks
<skaet> jbicha,  https://wiki.ubuntu.com/DocumentationTeam/ReleaseSchedule,  do you want me to update it with the latest?
<Laney> doko: that is for you
<doko> however cares about nvidia packages ... https://launchpad.net/ubuntu/+source/nvidia-texture-tools/2.0.8-1+dfsg-2build1/+build/3762795
<doko> whoever even
#ubuntu-release 2012-09-20
<doko_> Daviey, who did approve the python-tablib MIR?
<doko_> afaics, there even wasn't one
<doko_> ohh, I see, just cliff-tablib was promoted
<rsalveti`> infinity: another FFe: bug 1053212
<ubot2> Launchpad bug 1053212 in qemu-linaro "[FFe] merge qemu-linaro v12.09, based on upstream v1.2.0" [High,New] https://launchpad.net/bugs/1053212
<rsalveti`> current qemu-linaro is quite old already, based on 12.03
<rsalveti`> new qemu linaro is also based on upstream 1.2
<rsalveti`> which is a stable release, fixing a few arm specific patches as well
 * Laney sees a curiously emboldened ubuntu one ;-)
<Laney> Riddell: have you upgraded to the new ttf-ubuntu-font family and noticed anything breaking?
<Riddell> Laney: oh is it in?  I'll try that now
<Laney> yeah
<Laney> please just update the bug with anything that got broken
<Laney> I believe I need to accept that NEW backport fonts-cns11643 into multiverse explicitly, is that right?
<Laney> and is it just a matter of passing -c multiverse to queue accept?
<Laney> (IOW: do I need to care about -x -p?)
<Daviey> doko: i believe so..
<doko> Daviey, my bad, see my follow-up
<Daviey> hah, i was confused aswell :)
<cjwatson> Laney: use queue override
<cjwatson> -c -x -p don't do anything for accept
<Laney> ok
<Laney> do I need to specify them all?
<cjwatson> but is it not already in the right component?
<cjwatson> it certainly looks like it
<Laney> it is in Q
<cjwatson> you only need to specify ones which are wrong in queue info
<Laney> does that mean it will end up right in precise-backports?
<Laney> ah, yeah, looks right
<cjwatson> 'queue -s precise-backports info' says
<cjwatson>          | * fonts-cns11643/98.1-2~ubuntu12.04.1 Component: multiverse Section: fonts
<Laney> i see it
<cjwatson> so yeah, that's fine, you can just accept if you're happy with the rest of it
<Laney> ta
<tjaalton> ubuntu-sru members here? fix for bug 819304 has been on the queue for two weeks
<ubot2> Launchpad bug 819304 in gvfs "gvfsd-cdda crashed with signal 5 in _g_dbus_oom()" [Low,In progress] https://launchpad.net/bugs/819304
<Daviey> would some consider NEW reviewing ubuntu-cloud-keyring for precise-proposed?  Does it constitute an SRU?
<ScottK> A new package is definitely an SRU.
<ScottK> FYI, thanks to the recent "improvements" in the Ubuntu fonts, Kubuntu is dropping them for Quantal.
<jbicha> by the way, UIFE requests definitely must not be private bugs
<jbicha> these bugs have to be seen by the entire documention & translator teams before they are approved
<stgraber> Laney: for bug 1048600, do you recommend a revert because of the regressions (u1 and kde/qt) or do you know who to nag to get these solved ASAP?
<ubot2> Launchpad bug 1048600 in ayatana-design "[FFe] Restore "Ubuntu Medium" weights in Ubuntu's binary .deb" [High,Fix committed] https://launchpad.net/bugs/1048600
<Laney> I don't know of any serious attempts at debugging
<Laney> sladen: ^ do you?
<Laney> stgraber: I think we should revert it before candidate builds begin. Perhaps letting it run for a while to get information is a useful exercise, I'm not sure.
<Laney> There's also the comment #3 issue.
<stgraber> right...
<Laney> Perhaps we should have some kind of collective release team decision...
<sladen> Laney: I didn't manage to allocate a solid undisturbed week to it while @canonical.  I've been avoiding Ubuntu stuff over this summer.  When I'm back and motivated again, yes, I'm planning to have a go.  popey et al I believe have been asked to do something about it
<stgraber> Laney: ok, I re-opened the bug and commented that we'll likely revert if the regressions aren't fixed by the time we start spinning the first b2 images.
<sladen> ScottK: of course, it would be nicer to fix Qt :)
<ScottK> sladen: Sure, but one I know how to do and the other I don't.
<stgraber> Laney: oh, well, I didn't see the "collective release team decision" part before re-opening the bug and commenting :)
<skaet> Laney,  lets get as much data today as possible,  then add it to the agenda for tomorrow's meeting.
<ScottK> It seems rather late in the cycle to be intentionally breaking stuff to me.
<popey> in the event we managed to find someone to look at the bugs surfaced by bug 1048600, would it be possible to re-revert it back in later?
<ubot2> Launchpad bug 1048600 in ayatana-design "[FFe] Restore "Ubuntu Medium" weights in Ubuntu's binary .deb" [High,Fix committed] https://launchpad.net/bugs/1048600
<Laney> I think it's a more likely target for R
<Laney> but that would be a matter for the SRU team
<jbicha> popey: no, major UI tweaks really need to land today
<jbicha> or 3 weeks ago, but you get the idea
<stgraber> jbicha: I was going to say by Monday for that specific one as asking for resolution today doesn't seem possible. My understanding is that once fixed, there would be no UI change vs what we had before, so no screenshot to update, correct?
<jbicha> I'm redoing screenshots this weekend so could we get EVERYTHING straightened out by tomorrow please
<Laney> we'll make the determination at the release meeting
<jbicha> it's like UserInterfaceFreeze was 3 weeks ago, but today is like ReallySeriousUserInterfaceFreeze or something :|
<jbicha> at least there isn't any text that would need to be written for a font change
<stgraber> jbicha: can you use the previous font package for the screenshots? surely we don't want to include screenshots using the wrong font?
<stgraber> if it's too difficult, then I'd recommend we revert by 21:00 UTC today and accept a fixed version till Monday whenever-we-start-spinning UTC
<stgraber> popey: do you think you can get someone to fix/workaround that regression by Monday (probably around noon your time)?
<highvoltage> stgraber: the change for edubuntu, is it very specifically a space-in-unity-launcher thing for you?
<highvoltage> stgraber: imho it's more than that and I'd like to keep edubuntu a free system as far as possible with as little adware (for lack of a nicer word) as far as humanly possible
<Laney> err
<Laney> https://launchpadlibrarian.net/116683619/libunity-webapps_2.3.3-0quantal1_2.3.5-0ubuntu1.diff.gz â unity-webapps-runner-amazon.c
<Laney> it already went in?!?!?!
<stgraber> highvoltage: I just want them to make it technically possible to revert it and the release team to be prepared for us reverting it. The actual reasons why I want to revert these aren't relevant (and would likely have started an off-topic discussion in the bug)
<Laney> popey: can you comment on this in the bug please?
<popey> stgraber, i honestly don't know
<Laney> or get someone to
<popey> i have reached out to a community guy who knows fonts, asked him to take a look, and he has said he will, he's at a conf today though
<Laney> the webapps one, not the font one
<stgraber> Laney: is that actually the change adding these launchers to the default unity launchers? If so, the changelog is rather confusing...
<popey> oh, sorry.
<Laney> stgraber: no, I think it just builds them
<Laney> still definitely a Feature
<stgraber> right...
<Laney> but the changelog is interesting, yes
<popey> Laney, sorry, what do you want me to comment on?
<Laney> popey: https://bugs.launchpad.net/webapps-applications/+bug/1046840/comments/23
<ubot2> Launchpad bug 1046840 in Ubuntu Quantal "[UIFE][FFE] Install Amazon and Ubuntu One Music Store webapp items in the launcher by default" [High,New]
<Laney> jbicha: you coming to UDS?
<jbicha> Laney: no, sorry I won't be able to attend in person this time
<Laney> ah, that's unfortunate
<Laney> I want a What Are Freezes For session, at which your attendance would have been appreciated
<jbicha> ok, I'm signing off to take care of other responsibilities, I'll check in a bit later
<Laney> bye
<Daviey> anyone on ~ubuntu-sru want to take a package?
<Daviey> :)
<highvoltage> stgraber: I get a ubiquity error that it can't install grub to /dev/vda and I can't find the LP bug, are you aware of an existing bug for that?
<stgraber> highvoltage: nope. Is that today's build?
<highvoltage> stgraber: yep
<highvoltage> (well, the current one)
<stgraber> highvoltage: can you post /var/log/syslog and /var/log/installer/* somewhere?
<stgraber> cjwatson: looks like the python port regressed the size detection for Edubuntu's armhf DVD build. It's now reporting oversizedness
<cjwatson> stgraber: ok, give me a bit
<highvoltage> stgraber: http://paste.ubuntu.com/1216905
<highvoltage> stgraber: http://paste.ubuntu.com/1216907
<stgraber> cjwatson: looks like size_limit_extension() overrides size_limit() for all ARM images to 1024 * 1024 * 1024 which isn't correct for Edubuntu. Special casing in there would probably do it (as ugly as it's ...)
<cjwatson> oh, blah, right, thanks
<cjwatson> I'll fix that up
<stgraber> highvoltage: ok, thanks. Looks like something's wrong with grub-installer or related magic. Kind of odd we didn't hear about that yet...
<stgraber> highvoltage: is that in kvm or vbox?
<highvoltage> stgraber: kvm
<cjwatson> that explains why the edubuntu override was in a funny place anyway :-/
<cjwatson> stgraber: I fixed that this morning
<cjwatson> just needs a ubiquity rebuild which I'll do in a bit
<cjwatson> highvoltage: ^- so consider it handled
<cjwatson> stgraber: we did hear about it BTW, it was escalated from a jenkins failure
<stgraber> cjwatson: oh, indeed, for some reason I missed that in the #ubuntu-installer backlog...
<stgraber> cjwatson: ah, do we still get e-mails for jenkins failure somewhere? I remember we used to get these to the foundations mailing-list but that seems to have stopped (or I blacklisted it and can't remember doing so...)
<cjwatson> I haven't seen them for a while (though I thought that was just autopkgtest, but I haven't seen those either)
<cjwatson> maybe it was just switched on for precise?
<cjwatson> stgraber: fixed the Edubuntu sizelimit regression now
<cjwatson> (with a test)
<stgraber> cjwatson: thanks
<stgraber> cjwatson: oh, right, might have been just autopkgtest
<pgraner> stgraber, cjwatson: https://lists.ubuntu.com/mailman/listinfo/ubuntu-testing-notifications
<pgraner> ^^^^ Jenkins failures
<hallyn> jdstrand: who should i ping about the FFE for qemu-kvm?  I think i'd be nice to get it in before today's freeze while we shake out the hot-unplug bug
<mardy> iulian: hi! Do you have a spare minute?
<infinity> hallyn: I can look at it in a sec.  Throw me a bug number.
<infinity> hallyn: Does it relate vaguely to the qemu-linaro FFe that rsalveti pinged me about last night? :P
<infinity> hallyn: (At least, would then end up being vaguely in lockstep, version/feature-wise?)
<infinity> hallyn: Cause I'm all for them not being wildly out of sync.
<jdstrand> hallyn: #ubuntu-release. I don't consider the CVE regression to be a blocker for the ffe. that is just a bug fix that should be fixed before release
<infinity> I also wish someone would sort out how to just pick one good source, and build all the packages from there, instead of doing it all twice...
<jdstrand> hallyn: heh, we are in #ubuntu-release (ETOOMANYCONVERSATIONS)
<infinity> jdstrand: We sure are!
<rsalveti> infinity: bug 1052932 and bug 1053212
<ubot2> Launchpad bug 1052932 in qemu-kvm "[FFE] merge upstream v1.2.0" [Critical,New] https://launchpad.net/bugs/1052932
<ubot2> Launchpad bug 1053212 in qemu-linaro "[FFe] merge qemu-linaro v12.09, based on upstream v1.2.0" [High,New] https://launchpad.net/bugs/1053212
<rsalveti> yeah, in the past qemu-linaro had a bunch of additional patches on top of the upstream tree
<hallyn> rsalveti: thanks :)
<hallyn> i was trying to find it still
<rsalveti> but something to check again
<rsalveti> np
<hallyn> infinity: i suspect due to main inclusion issues we can't combine the trees completely, but i'd like to discuss at uds how to do it better
<infinity> rsalveti, hallyn: Right, I'll look at both in a sec.  It'll probably be a blanket approve/deny for both, since having them at similar versions seems sane.
<rsalveti> infinity: yup
<rsalveti> thanks
<infinity> hallyn: Main Inclusion will become less of a thing fairly soon.
<hallyn> rsalveti: maybe we can try keeping the qemu-kvm and qemu-linaro trees somewhat in sync for the lifetime of quantal :)
<hallyn> infinity: ohrly
<stgraber> hallyn: we're trying to kill the main/universe separation (archive reorg), making slow progress but not being terribly far from it anyway
<cjwatson> really been trumped by other things this cycle
<cjwatson> (as ever)
<rsalveti> yeah, the additional patch list is still huge hehe
<Laney> any installer people want to look at xnox's bug #1042649?
<ubot2> Launchpad bug 1042649 in ubiquity "[FFe] [UIFe] Manual Partitioning Crypt" [High,New] https://launchpad.net/bugs/1042649
 * Laney abstained
<hallyn> jdstrand: ^ i'm curious how security team handles that
<xnox> Laney: it's so late on a thursday evening, and people generally expect friday morning image to be milestone testing worthy, I'm inclined at nacking this for beta-2.
<Laney> xnox: If it's nacked for b2 it's probably nacked for Q
<xnox> :'(
<Laney> is there a ubiquity upload coming for anything else?
<xnox> cjwatson is doing one now
<Laney> I see
<xnox> to upload grub fix
 * Laney hugs xnox
<Laney> we'll get through this!
<skaet> cjwatson, can you look at the FFe ^ and comment?
<xnox> Laney: we dropped alternate images already, yet this and the advanced lvm are critical and were assumed to be "landing soon" when alternates were dropped.
<cjwatson> bit frazzled this afternoon ...
<cjwatson> but xnox is correct on that point at least
<cjwatson> we really need this for q
<cjwatson> it's basically a serious full-system regression if we don't
<xnox> Laney: nacking adv-crypt & adv-lvm FFe means we have to bring back alternatives.
<Laney> heh
<xnox> (alternate cds)
<skaet> infinity,  ^ can you help out with the review?
<cjwatson> that actually doesn't look too bad, though I want to look at the code
 * xnox is not volunteering to test all alternatives.
<cjwatson> UI complexity is minimal, considering
<Laney> get it reviewed and get QA prepared to test it
<skaet> UI has a+1 on it already
 * cjwatson reviews code
<balloons> xnox, anything else in the pipe your going to ffe?
<xnox> bug 1024649 and bug 1042647
<ubot2> Launchpad bug 1024649 in openclipart "openclipart-libreoffice package should not recommend libreoffice package" [Wishlist,Won't fix] https://launchpad.net/bugs/1024649
<ubot2> Launchpad bug 1042647 in ubiquity "[FFe] [UIFe] Manual Partitioning LVM" [High,New] https://launchpad.net/bugs/1042647
<xnox> bug 1042649 and bug 1042647
<ubot2> Launchpad bug 1042649 in ubiquity "[FFe] [UIFe] Manual Partitioning Crypt" [High,New] https://launchpad.net/bugs/1042649
 * xnox got 2 & 4 wrong way around =)
<Laney> no release team on that other one
<Laney> oh, no branch
<Laney> no code?
<xnox> Laney: UI bits and strings landed in beta1
<xnox> but hidden
<xnox> hooking up partman logic, I have some code locally but it's not done yet.
<Laney> hmm
<xnox> shoudl adv-crypto be uploaded into -proposed such that balloons / QA can test it?
<xnox> or a PPA?
<Laney> not proposed
<xnox> without affecting beta2 testing.
<Laney> well, not proposed for testing
<ScottK> xnox: quantal-proposed exists soley to avoid archive skew.  For testing, us a PPA.
<cjwatson> adv-crypto - let's just do it for beta-2.  the complexity here is not such that I think it would be difficult to hide again if it turns out to be impossible to fix nits
<cjwatson> I've reviewed the code branch, it looks fine
<Laney> I think that if it's to go ahead that you should just put it in
<ScottK> Or that.
<skaet> thanks cjwatson
<xnox> and if QA is happy testing: milestone/daily-image + upgrade ubiquity then land.
<skaet> balloons, plars ^?
<balloons> I can't commit much time today to help sadly.. unity team is doing there own last minute landings :-)
<cjwatson> xnox: less confident in LVM without being able to see the code
<xnox> well jibel did amazing ubiquity testing & great bugs.
<Laney> xnox: cheers
<xnox> cjwatson: sure. I understand.
<Laney> I'll do a test install with it tomorrow
<popey> Laney, ScottK where have the reports of the font breaking 'all of qt' come from?
<balloons> I am happy to do what I can to help land.. just it would be best to have plars or jibel or etc on point on this
<popey> I have a qt app open (fontmatrix) and the font looks fine. I appreciate it looks wrong in some other apps like libreoffice and vlc though.
 * skaet --> lunch, biab
<cjwatson> xnox: can you do an upload more or less straight away with that, then?  doesn't seem to be a reason to wait
<Laney> popey: who says it breaks all of Qt?
<xnox> cjwatson: ok. yeah that branch is ready.
<cjwatson> that> adv-crypto I mean
<xnox> cjwatson: yes, me to adv-crypto branch =)
<xnox> s/to/too/
<xnox> I am interested how bug 1053112 will affect beta2
<ubot2> Launchpad bug 1053112 in gtk+3.0 "ubiquity crashes when orca is running" [High,Confirmed] https://launchpad.net/bugs/1053112
<plars> xnox, skaet: if someone can give me a heads up when it lands, I can give it a try
 * Laney just started LO to test and has no menu bar
<xnox> cause gtk+3.0 upload means respin of everything but kubuntu/server&cloud?
<popey> Laney, seemed the implication
<Laney> I don't know what the precise impact is
<popey> from what sladen said above along with "all kde" apps being broken, and the last comment from scott
<infinity> cjwatson: Are you on top of reviewing/approving both of xnox's bugs in backscroll?
<xnox> infinity: crypt reviewed & approved, lvm nothing to review yet =)
<cjwatson> yeah, what he said
<cjwatson> I'm happy to review adv-lvm once code appears
<xnox> thanks.
<cjwatson> (but I don't know if that will be in time)
<infinity> Ahh.  Check.
<cjwatson> I sort of feel less urgent about adv-lvm than adv-crypto
<infinity> I'll go look at qemu-* instead.
<cjwatson> adv-crypto is important on the desktop; adv-lvm very nice to have but I think smaller audience
<xnox> infinity: =)))))
<cjwatson> I think that's the priority ordering we had anyway
<infinity> hallyn: Uhm, yeah, looking at what we're shipping right now, I think moving to a stable release is a no-brainer from the ongoing maintenance perspective.
<infinity> hallyn, rsalveti: Approved for both, please upload ASAP.
<xnox> cjwatson: the adv-crypto is interesting from security point of view, for example d-i goes to quite extends to prevent leaking passwords. And appart from gtk hide behind asterisks I'm not doing anything special.
<xnox> but then again we allow pre-seeding LUKS password and debian doesn't.....
<cjwatson> you're putting them straight through to the password type in debconf though, right?
<xnox> and pre-seeding is very plain-test =)
<cjwatson> yeah, but only logged in debug mode
<cjwatson> it might be worth including the red warning we have on the user/password page in debug mode that passwords will show up in the log
<cjwatson> or possibly had; I can only find it in the KDE frontend right now ...
<xnox> cjwatson: yes, apart from I do not believe I clear them from GtkEntry after doing so, and there is a period of time between entry -> and d-i asking for it and I don't know what's happening during that time. E.g. is gtk fool-proof?
<cjwatson> also check the logs in non-debug mode and make sure the password isn't leaked there
<cjwatson> I'm not concerned about clearing it from GtkEntry as long as it isn't displayed or logged
<xnox> nope, it's not in the logs in != debug
<cjwatson> the whole installer runs as root anyway
<cjwatson> (well, near enough)
<xnox> ok =)
 * xnox runs as root apart from reading ~/.config/pangorc *giggles*
<phillw> sorry for intruding, but are any of you guys having problem with lp today? (can't upload to ppa's for >8h now)
<Laney> #launchpad is probably a better venue for PPA questions
<Laney> someone else made a similar complaint there recently
<phillw> Laney: the OP has tried, no one about :/
<phillw> thanks for you time.
<Laney> ping the contacts in the topic
<hallyn> infinity: thanks!  pushing
<infinity> rsalveti: ^-- You too, I hope.  Flex that new core-dev muscle. ;)
<rsalveti> infinity: yup, thanks :-)
<cjwatson> ok, so heads-up on another late change: we are preparing a signed version of grub2 for use with secure boot
<infinity> \o/
<cjwatson> this is a fairly small change on top of the existing packaging at this point, and I'm preparing the upload now
<cjwatson> I'll be posting to ubuntu-devel@ a little later about it, and Rick's doing a blog post as well
<cjwatson> but thought I was going to need to upload in time for the freeze and thus wanted to keep this channel informed
<stgraber> oh, we're going with a signed grub2 instead of a minimal bootloader? (I guess ubuntu-devel post will cover that, I can wait)
<dobey> skaet: ping
<skaet> Laney,  could you have a look at: https://bugs.launchpad.net/ubuntuone-client/+bug/1042343
<ubot2> Launchpad bug 1042343 in ubuntuone-client/trunk "[FFE] [UIFE] Ubuntu One integration with Q sync indicator" [High,Fix committed]
<skaet> ?
<skaet> dobey,  ?
<Laney> looks fine
<dobey> skaet: i was just going to ask about that, in relation to your comment on bug #1053482
<ubot2> Launchpad bug 1053482 in unity "[FFe] [UIFe] Install indicator-sync by default" [Undecided,New] https://launchpad.net/bugs/1053482
<Laney> they will need another one to include indicator-sync by default
<Laney> oh yeah that
<dobey> although if the u1 one is 'approved' now, then nevermind. it will suck that we can't have the Recommends: for the sync menu bits, though
<Laney> I don't think that one has any UIF implications
<Laney> (as the UI isn't exposed)
<dobey> well, it will pull a couple packages into the default image
<dobey> and isn't really useful if the other piece isn't there
<ralsina> dobey: it is sort-of-useful, just not by default. Better than not having it.
<dobey> Laney: but is 1042343 approved now then?
<Laney> dobey: when can you upload it?
<Laney> are all of the new deps in main?
<xnox> bug 1042649 uploaded
<dobey> yes, the sync indicator is in main already, just not in default install
<ubot2> Launchpad bug 1042649 in ubiquity "[FFe] [UIFe] Manual Partitioning Crypt" [High,Fix released] https://launchpad.net/bugs/1042649
<Laney> xnox: you beauty
<dobey> i can upload ubuntuone-client within an hour, for sure
<Laney> dobey: so, say, today before 2100 UTC
<dobey> yes
<xnox> Laney: i'm ubiquity and I know it. =)
<Laney> dobey: there, done
<skaet> Thanks Laney.
<Laney> np
<dobey> thanks
<knome> testing deadline is 12UTC release day, or?
<stgraber> there's no such thing as a testing deadline
<knome> aha, so 21UTC?: P
<xnox> the sign-off?
<knome> well, that too
<xnox> go/no-go
 * xnox thought it was 12UTC
<knome> can somebody confirm? :)
<knome> skaet?
<hallyn> dyslex-chan
<skaet> knome,  when you say release day - you mean 12.10 or 12.10 beta 2?
<knome> skaet, beta2 this time
<skaet> knome,  all testing and documentation in the TechnicalOverview should be done by 1200 UTC on 9/27 - unless unexpected circustances force a VERY late respin,  and then we'll reset the time.
<knome> skaet, mhmm, ok, thanks
<knome> kind of bad timing, but no can do
<dobey> Laney: uploaded
<balloons> xnox, so did we respin an images with the ubiquity changes you ffe'd?
<stgraber> balloons: it's not fully built and published yet
<xnox> what he said =)
 * balloons awaits sync
<stgraber> highvoltage: can you log out of iso.qa.ubuntu.com, login again and check that you have admin access for the Edubuntu images?
<stgraber> I tested on my local instance but with a ton of hacks to try to make it think I was you ;)
<stgraber> highvoltage: that you let you mark images for rebuild/disable/ready/removed, have admin access on all results assigned to these builds and enter the admin UI to change product specific settings and manually push new builds
<stgraber> s/that you/that should/
<highvoltage> ok, the site seems to be a little slow atm
<stgraber> highvoltage: should be better now, doing some cleanup on the box, seems like a lot of things are poking at the DB...
<highvoltage> stgraber: where would I see those options? at the results?
<stgraber> highvoltage: well, first thing you should see is on the SSO page, you should see an edubuntu-release tick box that you need to tick
<highvoltage> stgraber: I did
<stgraber> highvoltage: then after that, you should see checkboxes on http://iso.qa.ubuntu.com/qatracker/milestones/219/builds
<highvoltage> stgraber: ah yes, I see them
<stgraber> highvoltage: you should also have an Administration link in the menu on the left
<highvoltage> (I didn't realise they'd be waaaaay at the bottim)
<highvoltage> stgraber: yep, I do
<highvoltage> and I see the Edubuntu products in there and only them.
<stgraber> good
<skaet> https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview - is ready for content to start getting added for Beta 2 now.
<jbicha> I got a reluctant +1 from translators for bug 1053189 can RT take a look?
<ubot2> Launchpad bug 1053189 in system-config-printer "UIFE: Rename "Print Settings" to "Printers"" [Low,New] https://launchpad.net/bugs/1053189
<skaet> jbicha,  will do.   Can you take a look at: https://bugs.launchpad.net/firefox/+bug/1053578 ?
<ubot2> Launchpad bug 1053578 in firefox "[FFE] [UIFE] add chromeless mode to Firefox" [Undecided,New]
<skaet> jbicha, approved.
<jbicha> and I +1'd as well
<highvoltage> /win 28
<highvoltage> (fffuuuuu)
<hggdh> the current image for server arm-omap4 says it is based on the 2012-09-18 packages ("base-installer: Found label 'Ubuntu-Server 12.10 _Quantal Quetzal_ - Alpha armhf+omap4 (20120918)'". Is this really what we should expect for today?
<skaet> hggdh,  nopen a bug.   It should say beta
<Laney> I think we change it to beta next week
<Laney> that's OFFICIAL in debian-cd/CONF.sh afaik
<Laney> stgraber: confirm/deny
<stgraber> Laney: right, will be set to Beta when we start spinning
<stgraber> I'm not sure why it was reverted to Alpha though but I remember it being mentioned on IRC by cjwatson, so I guess it's correct ;)
<Laney> well, a) we never set it to Beta-1
<stgraber> (might make more sense to use Daily between milestones instead of Alpha)
<Laney> b) bzr log indicates that it is set such in between betas anyway
<infinity> Oh crap.  I'm the Engineer on duty for this beta, aren't I?
<infinity> La la la.
<balloons> Does anyone know if all the iso's are affected by this? http://launchpad.net/bugs/1053362
<ubot2> Launchpad bug 1053362 in ubuntu "daily iso: bootloader install failed" [Undecided,Confirmed]
<cjwatson> balloons: it's already fixed
<balloons> cjwatson, ty
<cjwatson> when I'm not in the pub I'll dup it and stuff
<phillw> cjwatson: is it a full respin for all?
<Laney> it's not respinning time yet.
<phillw> Laney: but best not to attempt testing builds on the iso-tracker until re-spin has taken place?
 * infinity might futz with OFFICIAL now, and call the dailies over the weekend Beta-2.
<cjwatson> I think call them Beta
<infinity> I'm cool with that too.
<infinity> Was just looking at what we did in precise.
<skaet> +1
<cjwatson> Check what we did for precise, but I think that the obvious thing broke Wubi or something.
<Laney> yeah, precise was Beta-2
<Laney> "Beta 2" broke wubi
<infinity> Beta-2 was what we did in precise.
<Laney> at least from the log
<infinity> Spaces were BAD.
<cjwatson> Really?  OK.
<Laney> Less IRC more beer
<infinity> But I'm cool with just "Beta" as well.  Not that it matter greatly, it's just a hint to testers that they might have the right image.
<infinity> Or, vaguely, within a week. :P
<infinity> There.  Beta wins.
<skaet> thanks infinity. :)
<infinity> And now I return to (mostly) ignoring Beta stuff until Monday. :P
<Laney> can we haz freeze?
<infinity> Laney: I'll freeze the archive later.
<infinity> Oh, wait.  It's in 5m, isn't it?
<infinity> Fine.  I'll freeze nao.
<Laney> you have The Power?
<infinity> I does.
<infinity> skaet: Did you have a freeze announcement prepped?  (or do we care?)
<skaet> infinity,  In the works.    Some of the things that should have been announced a couple of days ago need to be included as well.
<infinity> skaet: Right, well.  We're frozen.  HAND.
* infinity changed the topic of #ubuntu-release to: Quantal Quetzal Beta 1 released! | Archive: Frozen for Beta 2 | http://pad.ubuntu.com/ubuntu-release | Quantal Quetzal Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or birdseed | melior malum quod cognoscis
<skaet> infinity,  btw - pad has been prep'd and ready for input earlier
 * infinity goes back to arguing with silly compilers in universe.
<SpamapS> Could somebody take a look at this upstream changelog and ACK it for a beta freeze exception? Many of these changes were made at our request... http://ceph.com/docs/master/_downloads/v0.48.2argonaut.txt
<SpamapS> (we already have 0.48.1 in quantal)
<SpamapS> and its all bugfixes so I dont' think its really a "feature freeze" exception
<Laney> upload it and get it reviewed in the queue
<Laney> worst case it stays until after the freeze lifts
<stgraber> SpamapS: upstream changelog looks reasonable. Someone will do a full review once it's in the queue
<stgraber> anyway, that thing isn't actually seeded right?
<stgraber> I see it as in main because of the supported seed, so not actually affecting beta2
<Laney> some libraries are on kubuntu
 * stgraber reads seeded-in-ubuntu's output again
<stgraber> gah, yeah, missed these two
<Laney> anyway, it's the usual hard freeze thing. bug fix releases should just be uploaded and reviewed in the queue
<SpamapS> thanks!
 * SpamapS goes to upload
 * Laney eyes that
 * infinity looks at the libunity-webapps dance, and wonders if whoever's doing that is now done...
<Laney> good job we had the freeze
<infinity> Clearly just in the nick of time.
<skaet> infinity, Laney - am in discussions with mterry on them.
<infinity> That discussion could totally happen in public, I'm sure. ;)
<skaet> infinity,  yeah,  it could.   my bad.
<skaet> mostly it was upload the the wrong spot, then accidental delete,  re-upload,  now stable  and needing review, to decide if we can resolve: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1040313
<ubot2> Launchpad bug 1040313 in libunity-webapps "[FFE] Update WebApps to support Firefox" [High,Confirmed]
<skaet> Laney,  if you're still feeling awake enough,  could you take a look through the code and determine if the libunity-webapps is safe enough to go in?
 * skaet --> dinner,  back on later
<phillw> if there is a -release person who is not too stressed out, could I borrow them for about 2 minutes to explain what http://people.canonical.com/~ubuntu-archive/seeds/lubuntu.quantal/live means in terms of what language packs it is loading, thanks.
<xnox> phillw: nothing =) you need to look at the unrollled / parsed output. But it goes something like that: include the en/es/de/fr and if there is enough space try to include more from the second list.
<xnox> phillw: but I'm just a trainee with seeds =)
<phillw> thanks xnox
<phillw> we still trying to work out why the iso's are over sized as most of the ppc people have macs with CD only.
<xnox> phillw: please see http://people.canonical.com/~ubuntu-archive/seeds/lubuntu.quantal/STRUCTURE to note which bits are included.
<xnox> phillw: also I find it is easier to mount the iso / unpack as if preparing for remastering. then you can chroot into it, and see which packages are installed & space it takes.
<xnox> and uninstall them & then see again how big it is.
<phillw> xnox: thanks a ton, I think that is what the tester was looking for, but I know very little (read zero) about how the iso's are made :)
<xnox> phillw: https://help.ubuntu.com/community/LiveCDCustomization#Obtain_the_base_system
<xnox> debootstrap full working system in a folder, pack it into squashfs, compress, add it to the iso & put stuff around it such that (i) iso boots (ii) loop mounts into that squashfs
<infinity> phillw: Moving things from the top list to the bottom list would get them off PPC.
<xnox> phillw: the installation is more or less: copy all files from squashfs into partitioned target drive & clean up
<infinity> phillw: That said, the PPC ISO isn't oversized.
<infinity> phillw: So, I'm a bit confused as to what the complaint is.
<xnox> infinity: so both lists are included on != Powerpc
<xnox> ?
<infinity> xnox: Yes.
 * xnox fail
<xnox> phillw: sorry if I confused you.
<infinity> phillw: The only way the PPC ISO could be "oversized" is if you have people burning CDs on 10-year-old 650MB media.  Can people even buy those anymore?
<infinity> phillw: On 700MB media, there should be a ton of space left over.
<phillw> infinity: that depends a lot on if you call 1kb 1,000 or 1,024.
<infinity> phillw: So, yeah.  Before one goes trying to shrink them, you might want to figure out exactly who thinks 689MB is oversized, and why.
<infinity> phillw: It would depend on that if we hadn't already done the math. :P
<phillw> infinity: can you just pop onto #lubuntu-offtopic for a couple of minutes, please>
<xnox> phillw: what drinks does #lubuntu-offtopic serve? =))))
<phillw> xnox: it is where I'm chatting to a PPC tester, I cannot bring him in here to discuss testing as you guys need the channel to get the release ready.
<infinity> Apparently, it offers awkward silence.
<phillw> infinity: 790769664 Jul 24 19:08 quantal-alternate-powerpc.iso
<phillw> that was the A3
<infinity> Oh.
<infinity> You were talking about live seeds.
<infinity> Which has NOTHING to do with alternates.
<infinity> So, I was looking at the desktop/live ISO. :P
<infinity> Which isn't oversized.
<phillw> the tester is on #ubuntu-testing. xnox if you have time, can we have a chat on there. I'm really uncomfortable about chatting about stuff not 100% release related on this channel.
<infinity> Chatting seems to have run its course.
#ubuntu-release 2012-09-21
<skaet_> jbicha,  spotted https://bugs.launchpad.net/unity-lens-files/+bug/1046774 that appears to be missing your +1,  can you take a look at it?   translations is ok.
<ubot2> Launchpad bug 1046774 in unity-lens-files "[UIFe] Add filesystem icons to unity-lens-files" [Medium,Fix committed]
 * skaet_ scrubbing through the UIFe/FFes
<skaet_> infinity,  are you aware of any further progress on https://bugs.launchpad.net/ubuntu/+source/webkit/+bug/1005682
<ubot2> Launchpad bug 1005682 in webkit "FFE: Update webkit to 1.9.91" [Wishlist,In progress]
<jbicha> skaet_: done
<skaet_> thanks jbicha
<infinity> skaet_: I think the best way forward on 1005682 for now is to do a whole lot of nothing until someone can make the new upstream build.  Reverting doesn't seem like a much better option than moving forward.
<infinity> skaet_: And I'll stand by that even if we have to bump the upstream version post-release to 1.10
<mardy> iulian: ping
<didrocks> infinity: hey
<didrocks> infinity: I discussed yesterday with skaet_ seeing powerpc not being at its best to have everything migrating from -proposed to the quantal pocket in time for the iso spinning
<didrocks> infinity: I did the copy this morning (and also promoted unity-lens-shopping to main), so after a publisher run, is it possible to have an iso respin?
<infinity> didrocks: Err, wait, what?
<infinity> didrocks: We really could have waited for PPC to catch up.
<didrocks> infinity: oh? didn't know, wasn't clear there was a way to wait when talking to skaet_ yesterday
<infinity> didrocks: What do you mean no way to wait?
<infinity> didrocks: We wait by... Not promoting stuff until it's built on all arches. :P
<didrocks> infinity: hum, sorry, but that's what I did, isn't it?
<didrocks> infinity: I waited for all arch to be built to copy to quantal and then promoting unity-lens-shopping
<infinity> didrocks: Oh, that's not what I got from your message in backscroll.
<infinity> didrocks: I misread you. :P
<didrocks> infinity: sorry, my fault surely :)
<didrocks> so I waited for everything to be built
<didrocks> even powerpc
<infinity> didrocks: Anyhow, which ISO(s) are you looking to respin?  Just ubuntu desktop?
<didrocks> that's why I did the copy and promotion only this morning :)
<didrocks> infinity: yeah, ubuntu-desktop, maybe edubuntu as well as it's using unity AFAIK?
<infinity> didrocks: ubuntu-desktop builds in 19 minutes via cron anyway.
<infinity> 7:31 UTC.
<didrocks> infinity: ah, excellent then! I thought the schedule was way earlier
<infinity> And edubuntu probably won't have any testers tonight anyway, so I suspect it can wait unless someone complains later. :P
<didrocks> thanks :)
<didrocks> ok
<infinity> (We haven't disabled cron, and I won't until Monday, so dailies should be fine for now)
<infinity> But you'll get ubuntu-desktop quite soon.
<didrocks> excellent, thanks :)
 * infinity decides it's bed time before he has any more knee-jerk reactions to misread IRC messages. ;)
<didrocks> infinity: heh, have a good night :)
<iulian> Morning.
<iulian> mardy: Contentless pings are of no use.
<mardy> iulian: hi! They can be useful indeed :-)
<mardy> iulian: I wrote you a couple of lines yesterday evening, I can re-paste them if you don't find them
<knome> ogra_, hey, are you still the person to contact about hwdb.ubuntu.com?
<iulian> mardy: Did you? Can't see them in my backscroll. Please do.
 * iulian goes to make some tea.
<iulian> Be right back.
<mardy> iulian: it's about https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/1046461
<ubot2> Launchpad bug 1046461 in shotwell "[UIFe] [FFe] UOA integration needs to support multiple accounts" [High,New]
<mardy> iulian: I got the patch ready (and submitted as a merge request), but we first need a green signal from the release team
<ogra_> knome, nope
<ogra_> knome, try cr3 or someone from his team (canadian TZ)
<knome> ogra_, ok, thanks
<iulian> mardy: OK briliant. It looks good. You can go ahead and upload but it won't get in until beta 2 is released.
<mardy> iulian: that's fine. Thanks!
<mardy> iulian: will you please write a comment on the bug itself? I'm not going to do the upload myself, so I need a proof of the approval
<iulian> mardy: You can just paste that in the bug report.
<mardy> iulian: silly me, thanks :-)
<cjwatson> ^- above grub2 fixes the use of the stupid URL http://gb.archive.ubuntu.com/ubuntu/dists/quantal/main/uefi/grub-efi-amd64-amd64/ (it'll be .../grub2-amd64/ now)
<Laney> cjwatson: looking, care to trade for ^?
<Riddell> balloons: on the ISO testers what's the meaning of "run once", that reads the same as mandatory to me since they only need to be done once per image
<cjwatson> Laney: sure
<Laney> cjwatson: I assume that whatever consumes that URL is updated accordingly. LGTM.
<cjwatson> Laney: Nothing consumes it yet
<cjwatson> I haven't uploaded grub2-signed yet
<cjwatson> I noticed the mad URL when preparing that :-)
<cjwatson> gtk+3.0 accepted
<Laney> merci
<psivaa> cjwatson, during my i386 p2q upgrade on a vm after the reboot at the end, i get 'error: file not found.' and prompts for grub rescue>
<psivaa> is this known already? i dont know how to get the logs from here, also this the fist time, if you'd like i could run another upgrade
<cjwatson> no, don't erase the evidence
<cjwatson> https://www.gnu.org/software/grub/manual/grub.html#GRUB-only-offers-a-rescue-shell
<cjwatson> may help get to the point where you have logs
<psivaa> right thanks, ill follow that and see if i could get the logs
<cjwatson> "error: file not found" is characteristic of GRUB 1.99 from precise
<cjwatson> Usually, anyway
<cjwatson> So my suspicion is that GRUB was installed to the wrong device for some reason, probably because the precise installation was misconfigured
<cjwatson> We uncover some of these misconfigurations basically any time we make a non-trivial change to GRUB
<Laney> is it possible to detect them?
<cjwatson> If I knew how I already would have done
<cjwatson> But not really given the crap PC architecture
<psivaa> this is on a vm and entire disk was used for installation
<cjwatson> Manually or using some helper tool?
<psivaa> that is the precise installation
<cjwatson> I mean, did you drive the installer manually
<psivaa> the precise was manually installed
<cjwatson> OK, that's somewhat concerning
<cjwatson> You might need to attach a live image to the VM and boot using that
<cjwatson> And then send me /var/cache/debconf/config.dat from the VM's normal disk
<cjwatson> And a listing of /boot/grub
<psivaa> in fact this was a clone of another vm, but this is a full clone, not a linked one though
<psivaa> right ill do that
<Riddell> cjwatson: is http://cdimage.ubuntu.com/cdicons/ in revision control somewhere?  I want to add this to it http://starsky.19inch.net/~jr/tmp/kubuntu-img.png
<cjwatson> Riddell: No, manually maintained
<cjwatson> Riddell: I've dropped that in for you
<cjwatson> (and on releases too)
<Riddell> thanks
<cjwatson> stgraber: Do you know what's going on with the mysterious edubuntu-dvd/quantal/i386 failure that looks like a success?
<cjwatson> psivaa: I don't want copies of the files under /boot/grub - I want a listing of the contents of /boot/grub
<cjwatson> psivaa: i.e. 'ls -l /boot/grub'
<Laney> ^- that is for discussion before being accepted
<Laney> back in 60
<psivaa> cjwatson, https://pastebin.canonical.com/75013/
<cjwatson> psivaa: Right, thanks.  Will follow up by mail
<psivaa> cjwatson, ack
<ahasenack> hi, can I get someone to upload the package from bug #1053057 please? It's critical for us. Not critical for quantal, but for the SRU I need to make and this is the first step
<ubot2> Launchpad bug 1053057 in landscape-client "Client queues up lshw calls if talking to old server" [Critical,Fix committed] https://launchpad.net/bugs/1053057
<ahasenack> actually, it's in quantal-proposed already I was told
<ahasenack> or
<ahasenack> well, in the "limbo"
<ahasenack> needs approval
<ahasenack> sorry for not using the right terms
<cjwatson> Oh, sure, I can move that since it's built
<cjwatson> Let me just do some checks
<ahasenack> cjwatson: thanks
<cjwatson> ahasenack: copied to quantal
<ahasenack> cjwatson: thanks a lot
<balloons> Riddell, well.. I suppose the idea is between respins they only have to be run-once.. lol.. honestly your right
<Riddell> balloons: oh I see
<balloons> the only other option is to have only 1 person run them.
<balloons> when we do our package testing and we have a run-once, we don't need multiple results from everyone for it.. I guess..
<knome> i thought run-once is once per milestone
<balloons> knome, right I agree.. The trouble is that we do run them for every iso
<balloons> err.. for every respin
<balloons> by definition, I suppose we're saying we don't "have to", but in practice it ends up being the same
<knome> balloons, :)
<knome> there should be some indicator if that test was already ran, if it's under a milestone
<knome> (eg. not daily)
<balloons> knome, hmm.. indeed. It's one of the issues we had with the 'cadence' week ideas as well. That is to say, over the course of a week, try and get every testcases ran; no matter which daily you ran it on
<knome> :)
<knome> sounds good
<balloons> lol.. does this mean we file a bug report for such a thing?
<knome> maybe
<cjwatson> babyface_: Can you kick a jenkins retry of quantal-core-armhf_default for bug 1053892?  I can't reproduce it locally, and there's reason to believe that it may have been transient (though I know you saw it twice)
<ubot2> Launchpad bug 1053892 in Ubuntu Quantal "failed to install quantal-core-armhf_default(20120921): some packages(mountall:amd64, upstart:amd64, iproute:amd64) have have unmet dependencies" [High,Confirmed] https://launchpad.net/bugs/1053892
<cjwatson> Well, you saw it twice only a couple of hours apart
<jibel> cjwatson, it was transient, it occurs when versions of gcc on amd64 and armhf are different i.e each time a new version of gcc is uploaded. I'll close it.
<stgraber> cjwatson: nope, I saw it yesterday but hadn't had a chance to look at it yet...
<skaet_> mvo,  could you do the GnomeAppInstallDesktopDatabaseUpdate (if you haven't already)?
<mvo> skaet_: thanks, the extraction is running right now, hopefully ready before my EOD
<skaet_> thanks mvo :)
<mvo> yw!
<cjwatson> jibel: right, that's roughly what I thought, just wanted to have a new run to confirm it.  Thanks
<stgraber> cjwatson: I'd also have to check, but it looks like even though we're getting a failure, the .iso contains the new squashfs...
<cjwatson> stgraber: I wondered if it was a failure in the LTSP bit at the end
<stgraber> cjwatson: it looks like it but the resulting squashfs looks good. I'll have a look at the code right after the mksquashfs in livecd-rootfs
<stgraber> cjwatson: do you have a way to know when it started failing? I don't have enough e-mail history and the logs aren't really helping here...
<cjwatson> memory says yesterday
 * Laney looks
<Laney> looks like today is the first instance of this
<stgraber> looking at ./live-build/auto/build the only case where it'd cause that output (without another error) is if mksquashfs would return non-zero without printing an error...
<cjwatson> Laney: I'm nearly certain this is at least the second such mail I've seen
<Laney> the first instance in the last couple of days
<ogra_> omap4 failed every day since a while
<Laney> perhaps 20120919/amd64 is similar
<stgraber> started a livefs-only build of Edubuntu (all arches) to get up to date logs on what's going on with i386 and armhf (hoping amd64 is still good)
<cjwatson> ogra_: that's an actual failure with you know a reason and stuff
<cjwatson> ogra_: this one has no obvious reason which is why I'm asking
<ogra_> cjwatson, some are, others are just cut off
<cjwatson> ogra_: oh, yeah, ok, the last one was cut off
<ogra_> wednesday too
<ogra_> Unpacking lintian (from .../lintian_2.5.10.2_all.deb) ...
<ogra_> Selecting previously unselected package linux-firmware.
<ogra_> Unpacking linux-firmware (from .../linux-firmware_1.93_all.deb) ...
<ogra_> thats where the wed. one ends for me
<skaet> cjwatson, ogra_,   in the desktop weekly,  they mention that foundation's XDG_RUNTIME_DIR support still didn't land.   Is there an ETA?
<cjwatson> skaet: I don't know - slangasek was doing that
<ogra_> skaet, cant say, its slangasek who implements it and he is on vac. this week
<cjwatson> He was active on it before being on vac
<ogra_> (i mentioned that there are no updates for it, in our report
<ogra_> )
<cjwatson> jdstrand: Could you review the grub2/amd64 binaries in unapproved?  I changed the tarball name to result in a more sensible URL on archive.u.c
<jdstrand> ok
<skaet> thanks cjwatson, ogra_.   didrocks, ^,  guess we'll need to get the latest from slangasek when he's back from vacation.
<didrocks> yeah, I was waiting anxiously ogra_'s report :)
<ogra_> didrocks, sorry that it didnt have any good newes for you :(
<ogra_> *news
<didrocks> ogra_: well, don't shoot the messenger, right? :)
<ogra_> :)
<jdstrand> cjwatson: done
<cjwatson> ta
<stgraber> edubuntu-dvd-i386 on cardamom.buildd finished at 2012-09-21 14:15:40 (success)
<stgraber> cjwatson: looks like whatever the problem was it's either happening randomly, disappeared or for some reason doesn't happen with manual builds...
<cjwatson> freaky
<ogra_> skaet, urgh ... it just struck me that i had changed the seeds for LibO inclusion on arm but forgot to upload -meta, mind if i do that (if not i can also revert the seed change, we should just not have a discrepancy during beta here)
<cjwatson> meta uploads are quick
<skaet> ogra_  please do the upload.   rather have things consistent at this point.
<ogra_> indeed, but i want to make sure i dont step on anyones toes
<skaet> thanks.  :)
<jbicha> skaet: https://wiki.ubuntu.com/ReleaseTeam#Weekly_Meeting isn't at 1600 UTC today, right?
<skaet> jbicha, stale data from standard time.  its at 1500
<smartboyhw> 20 minutes later
<skaet> fixed
<hggdh> who creates the daily images for arm (specifically armhf-omap4)?
<cjwatson> cdimage team
<cjwatson> well, I mean, cron mostly
<hggdh> the current armhf-omap4 install fails with "no kernels found". Under which component should I open the bug?
<ogra_> server or desktop ?
<hggdh> server
<ogra_> d-i
<hggdh> k
<ogra_> though probably not worth a bug since it will fix itself with the next d-i upload
<ogra_> (there was an upload of the kernel yesterady, d-i will need to pick that up)
<xnox> ogra_: can we fail daily build if d-i != kernel?
<xnox> ubiquity handles it ok.
<ogra_> not sure how easy that is
<xnox> ogra_: you are building squashfs already, it could check.
<hggdh> ogra_: actually, I have been seeing it for the last 3 days, but it took me a while to discard test code errors
<hggdh> ogra_: bug 1054143
<ubot2> Launchpad bug 1054143 in debian-installer "armhf-omap4: 20120921 daily server image fails to install with "no kernels found"" [High,New] https://launchpad.net/bugs/1054143
<ogra_> 3.5.0-210.16 was uploaded on tue.
<hggdh> ah
<ogra_> hmm, and there was a d-i upload bumping the abi
<ogra_> also on tue.
<xnox> yeah, infinity did it?! yes or no?
<bjf> infinity, bug 1047242
<ubot2> Launchpad bug 1047242 in linux "linux: 3.2.0-31.50 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1047242
<ogra_> xnox, yeah, he did
<ogra_> so that should all have been fine
<bjf> infinity, are we past the friday, no-copy, time
<hggdh> and -17 uploaded yesterday, and -18 today
<ogra_> yeah, but they are all not abi bumps
<ogra_> could be that the archive always went out of sync with the image right after the images were built or so ...
<hggdh> it could. Weirder things have happened
<hggdh> :-)
<ogra_> oh, wait
<ogra_> linux-meta-ti-omap4 (3.5.0.210.9) quantal-proposed; urgency=low
<ogra_>   * Ubuntu-3.5.0-210.16
<ogra_> so there is the reason for todays breakage
<ogra_> meta doesnt point to the recent one
<ogra_> in any case you boot with .16 in your syslog
<ogra_> and it downloads bits from .17
<ogra_> hggdh, i guess you can blame ppisati for not uploading to -proposed
<hggdh> heh
<infinity> bjf: Nah, Friday morning is fine. ;)
<infinity> ogra_: Hrm?  meta points to the recent one.  The changelog is a lie.
<infinity> ogra_: Since meta only points to 3.5.0-210, not 210.16 specifically. :P
<ogra_> infinity, meta wasnt uploaded after .17
<ogra_> oh, k
<infinity> ogra_: Yes, see above.  meta points to the ABI, not the specific build.
<cjwatson> xnox: cdimage attempts to but doesn't always manage
<infinity> bjf: Any idea why https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/1047347 still isn't done?
<ubot2> Launchpad bug 1047347 in kernel-sru-workflow/security-signoff "linux-ti-omap4: 2.6.38-1209.26 -proposed tracker" [Undecided,In progress]
<bjf> infinity: looking
<xnox> cjwatson: ok. =(
<cjwatson> xnox: (fail the build if d-i and the kernel don't match, that is)
<infinity> bjf: Oh, just caught jjo's comment.
<cjwatson> ogra_: -meta doesn't affect the "no kernels found" message anyway
<cjwatson> ogra_: that message pertains to udebs, not debs
<infinity> jjohansen: Can we get a sign-off on 1047347 despite the broken changelog?
<herton> bjf, infinity: yeah, told ppisati about the ti-omap4 on natty too, waiting on jjohansen as well to see if it will need a respin or it can get signed-off
<infinity> herton: Check.
<bjf> herton, we're not respinning just for a changelog typo
<herton> bjf, hmmok
<infinity> herton: My personal recommendation would be to fix the changelog in git, so it's correct in the next release, but let the current package slide.
<infinity> herton: But, meh.
<herton> infinity, no next release, hopefully this is the last one (natty going EOL)
<infinity> Oh, true dat.
<xnox> can I just add stuff to ubuntu-release pad things to be considered for respins?
<xnox> e.g. bug 1053112
<ubot2> Launchpad bug 1053112 in ubuntu "ubiquity crashes when orca is running" [High,Confirmed] https://launchpad.net/bugs/1053112
<infinity> Even less reason to care about the typo, then.
<infinity> xnox: Sure.
<jbicha> skaet: opened bug 1054167
<ubot2> Launchpad bug 1054167 in unity "Unity launcher for Quantal Beta 2 has too many items, scrolls off the screen on 1366x768" [Undecided,New] https://launchpad.net/bugs/1054167
<skaet> jbicha,  thanks!
<cjwatson> xnox: but note that the cron jobs haven't been disabled yet, and likely won't be until Monday
<cjwatson> xnox: So if you fix it today then you don't need to bother
<xnox> cjwatson: I see.
<infinity> xnox: Yes, there's also that. ;)
<xnox> yeah, but they still need to be accepted =)
<infinity> We have people who can do those sorts of things.
<infinity> Top Men.
<infinity> https://www.youtube.com/watch?v=yoy4_h7Pb3M
<Laney> xnox: we got that: https://launchpad.net/ubuntu/+source/at-spi2-atk/2.5.92-0ubuntu2
<xnox> Laney: hmm...
<xnox> cjwatson: why did this upload https://launchpad.net/ubuntu/+source/at-spi2-atk/2.5.92-0ubuntu2 did not close the bug report?
<xnox> oh, wait it was in ubuntu project and not against the right package at the time.
<Laney> it wasn't o
<Laney> yes
<infinity> xnox: Because the bug report was in the wrong package.
<infinity> Jinx, and such.
 * xnox give an old man to think out loud ! =)
<skaet> infinity,  with your beta 2 hat on, could you prioritize a review of: webapps-applications 2.4.6-0ubuntu1, webapps-greasemonkey 2.3.1-0ubuntu1, unity-firefox-extension 2.3-0ubuntu1 - would like to make sure there is no problems from the perspective of including them in the archive.
<infinity> skaet: Yeah, I was getting there.
<infinity> You'll note I've been doing queue things this morning. :P
<skaet> thanks infinity,   we're using https://bugs.launchpad.net/ubuntu/+source/libunity-webapps/+bug/1040313 for tracking this,  so if there are any issues,  could you please note it there.
<ubot2> Launchpad bug 1040313 in libunity-webapps "[FFE] Update WebApps to support Firefox" [High,Confirmed]
<popey> skaet, bug 1054204
<ubot2> Launchpad bug 1054204 in libreoffice "Libreoffice chooses incorrect font weight" [Undecided,New] https://launchpad.net/bugs/1054204
<skaet> thanks popey
<skaet> infinity, Laney, jbicha - design has weighed in on https://launchpad.net/bugs/1054167,  and we'll be going with it as is.
<ubot2> Launchpad bug 1054167 in unity "Unity launcher for Quantal Beta 2 has too many items, scrolls off the screen on 1366x768" [Undecided,Confirmed]
<skaet> (or rather as it will be after the pieces land in the archive)
<Laney> ok
<skaet> chrisccoulson, is https://bugs.launchpad.net/globalmenu-extension/+bug/1051152 the greasemonkey issue you're concerned about?
<ubot2> Launchpad bug 1051152 in globalmenu-extension "Firefox 16 beta crash in nsIContent::SetAttr with greasemonkey installed" [Critical,Fix committed]
<olli> skaet, chrisccoulson I have asked desrt to look at that one
<olli> hasn't replied yet
<skaet> thanks olli
<skaet> mterry,  is there an eta when you'll have the ubuntu-meta upload ready?
 * skaet sees he's not in the channel.... 
<mterry> skaet, sorry, was in shower
<mterry> skaet, so am still tracking down with webapps dev team some usability/integration issues I'm seeing with everything installed together.  The ubuntu-meta upload is simple enough to do once things are in the archive
<olli> skaet, mterry, finally heading for lunch, bbiab
<skaet> ok olli,  thanks for letting us know.
<infinity> mterry: So, in light of issues being found, does that mean you want me to hold off on the NEW review of all of this stuff?  That was going to be a chunk of my afternoon.
<mterry> infinity, this seems to be bugs-with-integration/migration-for-existing-users not working.  Not sure that should necessarily stop NEW, but should stop FFe
<infinity> mterry: Well, they're part and parcel, since letting it through NEW sort of defacto grants the FFe.
<mterry> infinity, OK.  Then hold off
<mterry> infinity, sorry for scheduling snafu
<infinity> You're not the only one trying to push scary changes late, I'll get over it.
<infinity> Which reminds me, I need to look at kmod this afternoon too.
<mterry> infinity, or, I suppose you could do the review work itself, but not push the button.  Whatever works best for you
<infinity> Where's apw when I need him?  Silly timezones.
<infinity> mterry: I have enough on my plate for now that I'm happy to just put it on hold until I'm told it's ready.  But if I find a spare moment, I can review for generic packaging/license/etc stuff.
<mterry> infinity, OK!  Will let y'all know when I have fixes in place
<skaet> mterry, infinity - please let jbicha know explicitly when they go through,  since he's trying to get the screenshots done, and this is a pre-req.
<skaet> mterry,  does it make sense for him to potentially do them out of your PPA?
 * mterry tries to hug jbicha without getting close enough for him to land a punch
<mterry> skaet, depends what he needs screenshots of.  jbicha, poke me when you're around and depending on your needs, you may be able to use my PPA
<skaet> thanks mterry,  am not sure of the details,  we'll need it from jbicha
<skaet> infinity,  what's your availability tonight/this weekend?
<infinity> skaet: I'm vaguely having a life most of the weekend.  Improv festival and other shenanigans.
<skaet> infinity,  could you check through the packages then this afternoon,  to make sure there are no other surprises that need addressing.
<Laney> zul: Daviey: Say, these quantums that got uploaded. They the ones that bug #1046432 was about?
<ubot2> Launchpad bug 1046432 in quantum "FFE for quantum" [High,Incomplete] https://launchpad.net/bugs/1046432
<zul> Laney: yeah
<infinity> skaet: I'll try to make time shortly to at least give them a once-over for obvious crack.
<Laney> zul: you decided not to bother with the FFe then? :/
<skaet> infinity,  thanks.
<zul> Laney: wha?
<zul> Ah ok..yeah i need to provide more info
<Laney> well, the uploads happened before it was granted
<Laney> not sure there's much point in providing the information now ...
<jbicha> mterry: so the new webapps might not land tonight? what's the ppa link?
<mterry> jbicha, https://launchpad.net/~mterry/+archive/ppa  (building now)
<mterry> or at least publishing now
<jbicha> oh, we're getting nethack? awesome
<mterry> jbicha, heh
<mterry> jbicha, that's for natty
<skaet> infinity, mterry, Laney - I've update http://pad.ubuntu.com/ubuntu-release with the latest status I'm aware of,  re the issues being worked, and bugs under investigation.   Please update as the problems with webapps gets resolved.
<skaet> infinity,  Laney,  stgraber,  cjwatson -  I'm going to be traveling/offline for next 24 hours.   will check the backscroll when I'm back near a connection.
<stgraber> ok
<mterry> ok.  so far I know of a migration script for webapps-applications, a new libunity-webapps to add affiliate codes, and 3 bug fixes for uncertain packages
<skaet> mterry,  thanks.   what about the ubuntu-meta?   anyhow,  please make sure all the elements are listed on the pad.ubuntu.com/ubuntu-release - so we can make sure they all get through together as needed.  :)
<skaet> stgraber, infinity, Laney,  cjwatson - if mterry's code lands while I'm offline,  please help get it landed after review.
<mterry> skaet, that too, but I was going to upload that after everything else hit the archives.  Else I'd have to manually edit it rather than rely on its update script, but if it's easier to have it as one dump, I can do that
<skaet> mterry,  when fixes are ready,  and coordinate with the release team in this channel for the prefered approach.
 * skaet --> travel now
<cjwatson> mterry: I'd definitely prefer ubuntu-meta only to be done by way of its update script
<mterry> cjwatson, yar
<mterry> we can drop in everything, update meta, then drop it in
<infinity> The meta ./update scripts probably need to take a --proposed switch.
<infinity> But, for now, waiting a few publisher cycles isn't world-ending. :P
<cjwatson> libunity-webapps looks fine - accepted
<cjwatson> infinity: are we taking this new -ti-omap4 kernel from quantal-proposed?  It changes ABI, but I suppose we ought to refresh d-i anyway really
<cjwatson> I promoted gcc-defaults
<infinity> cjwatson: Yeah, I had planned to take it.
<cjwatson> OK
<infinity> cjwatson: d-i could use a refresh to pick up the non-ABI-changing bits in the master kernel anyway.
<infinity> cjwatson: I'll promote and do a d-i upload later tonight before I piss off for the weekend.
<cjwatson> Also to pick up my rescue change.
<infinity> All the more reason.
<infinity> Promoted gtk as well.
<cjwatson> That didn't depend on the new (broken) glib2.0?
<cjwatson> I am Jack's lack of britney
<infinity> cjwatson: I don't see how it would.
<cjwatson> You never know :-)
<infinity> The new one only changed packaging.
<infinity> If that broke ABI, I'm impressed.
<infinity> And a bit disturbed. :P
<cjwatson> But, yeah, doesn't seem to
<cjwatson> Oh, huh, glib2.0 in -proposed is no worse in terms of building on ARM than in release
<cjwatson> So I guess in theory we could promote that
<cjwatson> I kind of wanted to hear from pitti though
<infinity> slangasek: Just for you (kmod) ---^
<infinity> cjwatson: Err, ugh.  Who promoted it when it wasn't built on all arches? >:(
<infinity> Too many fingers in this pie.
<Laney> no, it was uploaded to release in error in the first place
<infinity> Oh, was it?  Check.
<infinity> Indeed.  Okay, that somehow annoys me slightly less.
<infinity> In that proper machinery will someday solve this. :P
<cjwatson> I've also done archive processing on all the MIRs that could be done.
<Laney> that makes it sod's law
<infinity> Laney: As in "if you don't like the law, sod off"?
<mterry> Hello again
<mterry> OK, I think we're ready.  Let me get package names and version numbers
<mterry> libunity-webapps 2.3.8-0ubuntu2
<infinity> mterry: You're dangerously close to the end of my week here. ;)
<Laney> as in "Oh, I cocked up and uploaded it to the wrong place. Oh look, now it's broken. Yippee!"
<mterry> webapps-applications 2.4.6-0ubuntu2
<Laney> If he uploaded to proposed in the first place it would have all worked. :P
<infinity> cjwatson: Hah, you NBS faster than I do.
<mterry> webapps-greasemonkey 2.3.1-0ubuntu1
<mterry> unity-firefox-extension 2.3.2-0ubuntu1
<mterry> EOL
<cjwatson> infinity: Yes, I'm a real fast copy and paste monkey
<mterry> webapps-greasemonkey didn't actually have a recent release, but the other three did
<mterry> olli, ^
<cjwatson> infinity: (Also, props for being bothered to remember how to find binary publishing history)
 * cjwatson wonders how all of this blindingly new webapps stuff is at version 2.x already
<knome> they got to be, it's web 2.0 now.
<infinity> cjwatson: Binary publishing history what now?  What did I do today when I was napping?
<cjwatson> infinity: Well, either that or you just guessed I did the NBS processing.
<infinity> cjwatson: Or I copy-and-monkeyed and it told me "no".
<cjwatson> Right, but you guessed it was me and not somebody else :-)
<cjwatson> (Accurately, though)
<infinity> cjwatson: Oh, right.  That was a safe bet without looking. :P
<cjwatson> I wonder if I can ingest enough coffee to be able to sort out bug 1036616 before I go to bed
<ubot2> Launchpad bug 1036616 in launchpad "Custom uploads cannot be effectively staged in a PPA" [Low,Triaged] https://launchpad.net/bugs/1036616
<cjwatson> Incidentally, https://lists.ubuntu.com/archives/ubuntu-devel/2012-September/035912.html is relevant to this channel
<infinity> cjwatson: \o/
<olli> mterry, infinity, cjwatson, Laney skaet asked me to ping you guys on the successful webapps upload which mterry did
<olli> is there anything left to do or are you guys taking it from here?
<infinity> olli: We'll take it from here until we tell you you've done it wrong.
<infinity> olli: Sound good? :)
<Laney> SenÃµr Conrad is on the case
<olli> infinity, wfm
<infinity> Si.
<olli> infinity, this should imho take care of https://bugs.launchpad.net/ubuntu/+source/libunity-webapps/+bug/1040313
<ubot2> Launchpad bug 1040313 in libunity-webapps "[FFE] Update WebApps to support Firefox" [High,Confirmed]
<olli> and https://bugs.launchpad.net/ubuntu/+source/libunity-webapps/+bug/1053578 as mentioned in "issues" in the release pad
<ubot2> Launchpad bug 1053578 in libunity-webapps "[FFE] [UIFE] add chromeless mode to Firefox" [High,Triaged]
<phillw> cjwatson: I hope so, when the dust settles I would appreciate a bit of your time for ppc - if you could pencil some thing into your over loaded diary.
<mterry> olli, infinity: and https://bugs.launchpad.net/webapps-applications/+bug/1046840
<ubot2> Launchpad bug 1046840 in unity "[UIFE][FFE] Install Amazon and Ubuntu One Music Store webapp items in the launcher by default" [High,Fix released]
<olli> and the trigger "webapps" should imho also be resolved
<mterry> olli, it will not fix chromeless mode remember
<mterry> olli, that isn't working and we decided to not fix
<olli> true
<cjwatson> phillw: go ahead
<infinity> Right, copying linux-ti-omap4 to -release, and going for food.  d-i upload later when the archive settles.
<infinity> Then weekend.
<olli> mterry, thanks again for your help
<mterry> yup, thanks everyone for still being around on a Friday
<olli> release & doc & translation team, thanks for your patience with this one
<cjwatson> Laney: Your ~ is apparently excessively greased and slipped sideways.
<phillw> cjwatson: Adam gave the best he knew on the ppc issues, something happened after A3 that has crippled things :(
<infinity> Err, what?
<Laney> seÃ±or?
<infinity> I thought we just talked about oversized, not crippling issues.
<Laney> sáº½nor?
 * Laney can't make any others work
<phillw> infinity: btw, you asked to be reminded to put lubuntu iso's on a diet :)
<infinity> Laney: SeÃ±or.
<cjwatson> Oversizedness doesn't seem crippling.  I'd have thought most powerpc machines that could still run *buntu had DVD drives anyway.
<infinity> phillw: Yeah, I'll poke at that for you on Monday.
<cjwatson> ^- grub2-signed 1.1 totally not b2-critical, just wanted it off my disk
<phillw> cjwatson: it is not the oversize
<infinity> cjwatson: None of the current PPC dailies are actually oversized anyway.
<cjwatson> phillw: then you might want to be just a little more specific
<infinity> cjwatson: (Though some other lubuntu images are, and I'll balance those later for them)
<phillw> cjwatson: if you get chance, can you have a read of the bugs?
<cjwatson> phillw: what bugs?
<phillw> cjwatson: sorry me email is down, I'm going to pull up the QA meeting logs... takes me a couple of minutes
 * mterry signs off
<phillw> cjwatson: I cannot access them, balloons should be coming on soon to give the numbers
<balloons> 1040544 1040526 1044180
<balloons> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1040544
<ubot2> Launchpad bug 1040544 in ubiquity "Installer dialog does not come up on PPC" [Undecided,Confirmed]
<balloons> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1040526
<ubot2> Launchpad bug 1040526 in linux "Graphics dithered on Desktop image" [Medium,Confirmed]
<balloons> https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1044180
<ubot2> Launchpad bug 1044180 in lightdm "Screen Freeze on Bootup - Lubuntu 12.10 PPC Alternate Aug 30 Build" [Undecided,Confirmed]
<phillw> balloons: thanks
<phillw> 1040256 is not a priority!
<cjwatson> Sorry, I can't help with bug 1040544, which is the only one there that's really in my general area.  It seems to be something to do with window management or X or the kernel's graphics drivers, rather than a problem with ubiquity itself.
<ubot2> Launchpad bug 1040544 in ubiquity "Installer dialog does not come up on PPC" [Undecided,Confirmed] https://launchpad.net/bugs/1040544
<cjwatson> You need to find some kind of graphicsy person.
<phillw> cjwatson: can I ask what happened between A3 and B1?
<phillw> we had ppc working at A3, Adam suggests that it was a kernel change?
<cjwatson> I have no idea.  That's too wide a range for me even to begin to guess.
<cjwatson> I'm not aware of any specific "hey, let's break powerpc" change ...
<phillw> something happened between A3 and beta 1.
<cjwatson> Remember that this could be an emergent effect of any one of thousands of changes to quite a number of packages.
<cjwatson> It's not much use to try guessing that way.
<cjwatson> There was probably a new X stack in there, if memory serves
<phillw> cjwatson: is there any way to get the A3 shrunk to standard CD size?
<cjwatson> But I expect there were also quite a few kernel changes
<phillw> then, at least, the testers could add in stuff one step at a time?
<cjwatson> We can't build alpha-3 any more; we no longer have that archive.
<cjwatson> So no, not unless you want to go stripping stuff out by hand.
<phillw> cjwatson: I have the iso on the server.
<cjwatson> Surely there must be somebody with Radeon and a DVD drive.  Lots of Macs used to fit that description.
<phillw> I really don't know about this area, all I have ensured is that the milestone A3 iso's are still there.
<cjwatson> Re bug 1040526, I can certainly amend CD docs as needed, but I would really strongly prefer to have authoritative directions from somebody who knows about kernel graphics and/or X, rather than effectively passing on guesswork
<ubot2> Launchpad bug 1040526 in linux "Graphics dithered on Desktop image" [Medium,Confirmed] https://launchpad.net/bugs/1040526
<cjwatson> I'm afraid I don't know about this area either.  Sorry.
<cjwatson> You might try #ubuntu-x or #ubuntu-kernel, although probably more during working hours of some kind.
<cjwatson> They might at least know how to debug it.
<cjwatson> The tail of 1040526 suggests that switching powerpc to GRUB might be helpful, but there's no way I can squeeze that in for 12.10 - and it's not like alpha-3 was using GRUB.
<phillw> cjwatson: one of the things that was suggested, and crazy as it seems... could we revert back to an on-size A3? Before the changes to kernal / install etc were made?
<cjwatson> No.
<cjwatson> Completely impossible.
<cjwatson> Reverting individual packages is one thing (although the whole X stack for a problem on one architecture, not so much)
<cjwatson> Reverting the whole archive - not possible
<phillw> hmm. okies.. as the b1 was a fail from day one, I was hoping to plead regression.
<cjwatson> You can plead all you like, but I'm afraid it is well beyond difficult and into totally and utterly infeasible.  Sorry.
<phillw> it is only ppc, and only lubuntu (as we're the only ones doing it)
<cjwatson> We can't revert just one architecture and just one flavour like that.
<cjwatson> You guys wanted to be part of the Ubuntu archive :-)
<cjwatson> Means you have to play by the rules, which include building off the current archive
<phillw> okies, lubuntu and ppc to me, are two different teams.
<cjwatson> Doesn't matter
<cjwatson> Anyway, alpha-3 would be unreleaseable for other reasons
<phillw> cjwatson: so, it appears that a ppc for 12.10 is not possible... too many bugs & no resolutions possible?
<cjwatson> You can certainly try assembling images by hand based on that, although it isn't going to be quick
<cjwatson> I would not like to make such a judgement four weeks out
<cjwatson> I am simply saying that *I* can't help
<cjwatson> And I gave you directions to two different channels which include people likely to be quite clueful about this stuff
<cjwatson> So you should really follow those up (on Monday, probably) before giving up
<phillw> Thanks, I will ask there, but the fact the kernel was changed does fill me with dread.
<cjwatson> It shouldn't.  That's kind of the job of #ubuntu-kernel.
<cjwatson> FWIW my suspicions would fall on the X stack for preference, but that may not be worth much as this is not my field.
<phillw> cjwatson: and, personally, please do not think I'm giving you a hard time. I just would really like a ppc out for 12.10
<cjwatson> Ask people who know :-)
<cjwatson> I don't think you're giving me a hard time - I just genuinely can't help any more than the attempts I've already made (which in retrospect were indeed likely to be invalid if these problems are Radeon-specific)
<phillw> I'll go and make my self unpopular on their channels :P
<cjwatson> If the X or kernel teams say that this is going to need a boot parameter workaround, I'm more than happy to either install that by default on the images or document it for some users, depending on what's appropriate
<cjwatson> But normally, boot parameters aren't the solution we prefer
<phillw> cjwatson: do you mind if I cc this chat to the ppc testers?
<cjwatson> Not at all
<phillw> again, thanks
<cjwatson> It's publicly logged anyway
<cjwatson> Or will be when the bot catches up
<phillw> the L-QA people do not hang about on here, i'm always the messenger to be shot :P
<phillw> so, far, so good :D
<cjwatson> There's no problem with people lurking and such
<phillw> I do keep telling them that, some have only just got used to being on -testing.
<phillw> as they are also told when the -release pad goes up, so they can see what is happening for respins etc.
#ubuntu-release 2012-09-22
<cjwatson> infinity: reviewing
<cjwatson> Yep, clearly fine, accepted
<rsalveti> infinity: ^ :-)
<cjwatson> Laney: hmm, so I copied emacs24 to quantal seeing that it had built, and then noticed that it has an uninstallable in quantal-proposed, whoops
<cjwatson> Laney: looking at it, I see there's an emacs binary package clash between emacs23 and emacs24, which we need to fix (there's a "failed to upload" for emacs23/i386 as a result)
<cjwatson> Laney: Rob Browning has uploaded emacs-defaults in Debian to deal with this, which is a sane fix
<cjwatson> Laney: but do we want to take its default of emacs23, or switch to emacs24?
<cjwatson> oh, haha, I think this answers the question
<cjwatson> Package: emacs
<cjwatson> Source: emacs24
<cjwatson> Version: 24.1+1-2ubuntu1
<cjwatson> Depends: emacs23 | emacs23-lucid | emacs23-nox
<cjwatson> bizarre but that's fairly clearly 23 - I'll sync in emacs-defaults then once I've dealt with the corresponding changes to emacs23 and emacs24
<cjwatson> Laney: ^- if you could review those plus the emacs24 which should appear shortly, that would be great
<apw> as requested i have pushed a lowlatency respin to match linux master ...
<Laney> cjwatson: hmm, wasn't there an emacs23 in -proposed which dropped the 'emacs' package?
<Laney> (moving forward is also reasonable too, of course)
<jbicha> hmm, I think i installed the right packages for the webapps stuff but clicking Amazon or U1MusicStore just opens my normal Firefox, not the chromeless thing
<jbicha> except that I get a second Amazon icon or second U1Music icon in my launcher if that page is open in Firefox :(
<jbicha> & in alt-tab
<Laney> jbicha: where have you got your packages from?
<jbicha> Laney: https://launchpad.net/~mterry/+archive/ppa
<Laney> hmm
<jbicha> I should have tried it yesterday when he was still around, I just didn't think that things would still be broken
<Laney> not sure I'm afraid
<Laney> you could try fishing everything out of the queues
<cjwatson> Laney: no, it was just a security fix; that was the version that failed to upload
<cjwatson> Laney: the same security fix was the other non-trivial change in Debian, so really no reason not to merge, I thought
<Laney> cjwatson: I'm referring to https://launchpadlibrarian.net/116855995/emacs23_23.4%2B1-3ubuntu3_23.4%2B1-3ubuntu4.diff.gz
<cjwatson> oh, err, I didn't see that
<cjwatson> I think my change is better because reducing delta :)
<Laney> haha
<Laney> it is. The issue was being bothered to do it, but you were, so yay
<cjwatson> And I do think we should switch to emacs-defaults - less error-prone design
<Laney> if someone can NEW -defaults then I'll accept both emacsen
<Laney> gosh, my house is rather cold this afternoon
 * tumbleweed is sitting next to a fire (but then it *is* winter here, although beautifully sunny too)
<Laney> where are my Serious Socks?
<Laney> beer. beer helps.
<iulian> "Serious Socks" haha. :)
 * iulian likes his fluffy pink socks.
<cjwatson> Laney: Maybe I should just NEW my own sync, if nobody else is around?
<Laney> I don't know how ruley the rule is
<cjwatson> It essentially amounts to unapproved processing in the case of a sync, and if I'm proxying that for you *shrug*
<Laney> realistically it's a sync, so it'd be waved through anyway
<cjwatson> Quite
<cjwatson> And it's -proposed
<cjwatson> Done
<Laney> ta
<olli> when do you guys expect a beta2 image?
<Laney> monday is when they will start being 'candidates'
<Laney> what are you after? :-)
<olli> need to do a fresh install, just curious if I should wait for a b2 image or go with b1 and upgrade
<olli> guess I will go with the latter
<olli> :)
<Laney> you might as well use a daily image
<popey> Once things are all green in http://people.canonical.com/~ubuntu-archive/pending-sru.html , what triggers the move from -proposed to -updates?
<popey> e.g. unity + unity2d + nux :D
<Laney> it's manual
<popey> ah
<popey> Who do I need to buy beer for?
<Laney> someone on the SRU team
<popey> ok, ta
<Laney> np
 * popey cuddles up to ScottK 
<Laney> that famous unity lover
<popey> :D
<highvoltage> heh
<Laney> the phantom reviewer
<xnox> Laney: who can upload into backports?
<xnox> Laney: to the point of it landing in new/unapproved at least?
<Laney> technically the same as the main archive
<Laney> but you should not, it is for backporters only
<xnox> Laney:  so for bug 999771
<ubot2> Launchpad bug 999771 in myunity "myunity incorrectly parses lsb-release" [Undecided,New] https://launchpad.net/bugs/999771
<xnox> Laney: I added precise backports, and then I should probably also target precise but not quantal.
<Laney> the distro task isn't relevant for backports
<Laney> but you probably want to SRU it too
<xnox> Laney: yeah cause sru+backport need the fix.
<infinity> Laney: I'm not a phantom!
<infinity> Not my fault LP still has no audit trail on the queues. :P
 * infinity kicks off yet another clang build and goes away again.
<jbicha> yay, webapps
<bkerensa> yay Amazon Search Results!
<bkerensa> :D
 * xnox actually likes them!
<jbicha> xnox: have you bought a dishwasher yet?
<xnox> jbicha: nope
<bkerensa> xnox: Well they dont bother me but -offtopic is getting flooded by people unhappy about this
<bkerensa> =/
<highvoltage> oh dear, why did I even peak in there.
<stgraber> :)
<bkerensa> highvoltage: someone had a script earlier that was saying "Ad sponsored by Amazon"
<bkerensa> =/
#ubuntu-release 2012-09-23
<rsalveti> infinity: qemu-linaro for armel failed to upload due: qemu-system_1.2.0-2012.09-0ubuntu1_armel.deb: deb contents timestamp check failed: E:Tar checksum failed, archive corrupted
<rsalveti> infinity: just I just trigger a rebuild?
<skaet_> plars, balloons - I just updated my quantal system to pick up the latest packages, and now am no longer able to get to the global menu bars for applications.   Are either of you seeing reports of this from others or could this be a problem specific to my system?  Global menus were working fine prior to me updating tonight.
<skaet_> I've opened bug:1054850 to track the issue.
<skaet_> If anyone else is seeing this issue,  could you please confirm the bug.
<bkerensa> skaet: I am not seeing it and I just updated about 4 minutes ago
<iulian> skaet_: I've just upgraded now and am affected by it too.
 * iulian switches back to xmonad.
 * iulian accepts rakudo.
<tumbleweed> aww, you beat me
<tumbleweed> gah, lp doesn't like that one
<tumbleweed> shell loop time
<Laney> which?
<Laney> banshee?
<tumbleweed> yeah
<Laney> weird, the problem is usually bug closing and that only closes 5
<tumbleweed> no joy yet
<tumbleweed> one has a handful of duplicates...
<Laney> maybe just wait for that LP deployment on Monday
<Laney> (or whenever)
<tumbleweed> yeah
<skaet_> thanks iulian.   I've marked it as confirmed then.     It might be the same as https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1053288,  but that one had no comments since 9/20,   and there were uploads on Friday that could be interacting.
<ubot2> Launchpad bug 1053288 in unity "Broken UI and no window management" [Critical,Confirmed]
<cjwatson> tumbleweed: if it's not urgent, leave it until the next LP deployment so we can use it as a test case
<skaet_> popey,  do you have any further data on the broken UI and missing global menus as reported in 1053288 and 1054850?
<popey> hi skaet
<popey> for bug 1053288 I think Laura had staging enabled, so had a bit of a strange setup compared to most
<ubot2> Launchpad bug 1053288 in unity "Broken UI and no window management" [Critical,Confirmed] https://launchpad.net/bugs/1053288
<skaet_> that could be.    For 1054850,  its coming purely from the main archive.
<skaet_> coming from a staging environment would explain om26er's comments on the bug.   But what I was seeing definitely wasn't coming from anything experimental.
<skaet_> popey,  can you please work with olli to find the right people to start digging into this today
<popey> ok
<skaet_> thanks.   I'm going to be leaving for the airport in an hour,  and won't be online for most of the day in North America.
<knome> skaet_, what do you think are the possibilities to get an ACK for a B2Fe today?
<skaet_> pgraner, infinity,  ^ please help.
<tumbleweed> cjwatson: it isn't - leaving it
<knome> thanks
<skaet_> knome,  depends on the detail?    what's the bug number?
<knome> skaet_, there's no bug yet, but the details are ready: we'd really like to update our themes with bugfixes + push a recolored USC icon to our icon theme
<knome> skaet_, doesn't affect others
<knome> skaet_, (at most US, but i'm quite certain they want these fixes too)
<skaet_> knome,  open a bug for FFe/UIFe,  if its limited to you,  yeah,  we can look at getting it reviewed and in.   Am assuming your docs folk are ok with it?
<cjwatson> tumbleweed: OK.  It'll take a little extra ops work after the deployment (adding a cron job and setting a feature flag), but I'll make sure that happens
<skaet_> (ie,  no screenshots to redo)
<knome> skaet_, docs folks eg. me, yeah i'm happy with it
<knome> skaet_, i'll file the bug in a minute.
<tumbleweed> hypera1r: FYI ^^^
<cjwatson> Excellent to have a known-previously-bad test case, actually.  wgrant and I had hoped this freeze would provide useful confirmatory data.
<cjwatson> Decent hope of being able to remove nearly 2000 LoC from LP on Friday ;-)
<tumbleweed> do you have a 2k sized feature in mind to fill the gap? :)
<cjwatson> Most of my near-term stuff will be net negative
<cjwatson> Maybe I can trade some of it for Adam's livefs buildd work
<cjwatson> I want to get chroot management sorted out in a bit, but that will probably end up negative by way of removing the old script
<tumbleweed> so we've still lost you to lp for the forseeable future?
<cjwatson> No, the guts of this project are done
<cjwatson> Just some loose ends
<cjwatson> But I want to keep my hand in because it's handy to have somebody whose main focus is Ubuntu who's comfortable working on LP
<tumbleweed> absolutely
<cjwatson> (not the only one anyway; I know e.g. Brian and Bryce have contributed a fair bit)
<hypera1r> tumbleweed: what?
<iulian> hypera1r: It was about banshee. Read the scrollback.
<hypera1r> iulian: um, about the launchpad bug closing problem?
<tumbleweed> yeah, we're going to leave the upload unapproved until the LP fix for that lands next week
 * iulian nods.
<hypera1r> oh i see.
<hypera1r> okay
<hypera1r> sure
<knome> release team, bug 1043506
<ubot2> Launchpad bug 1043506 in xubuntu-artwork "12.10.5 xubuntu default settings - ubuntu software center icon is the same as Synaptic" [Undecided,Confirmed] https://launchpad.net/bugs/1043506
<iulian> knome: You said earlier there was no bug filed.
<iulian> Anyway, -release subscribed.
<knome> iulian, yeah, i didn't know there was, and i filed a dup few minutes ago... :)
<iulian> Could you please mark that as a duplicate then?
<knome> sure
<knome> eh, it is marked :)
 * knome has started losing track of everything, running xubuntu, preparing training lectures and working with clients at the same time
<olli>  iulian, seems the webapps, unity, WM issues are resolved?
<olli> https://bugs.launchpad.net/ubuntu/+source/indicator-appmenu/+bug/1054850
<olli> https://bugs.launchpad.net/libunity-webapps/+bug/1053288
<ubot2> Launchpad bug 1054850 in indicator-appmenu "after applying latest updates, global appmenus are not appearing on the top of screen." [Critical,Confirmed]
<ubot2> Launchpad bug 1053288 in unity "Broken UI and no window management" [Critical,Confirmed]
<olli> couldn't quite tell how, was there an updated libunity-webapps pkg?
<xnox> queue bot is asleep
<phillw> xnox: it appears he has been poked into being awake :)
#ubuntu-release 2013-09-16
<doko> ScottK, dh-python seems to be stuck in proposed
<cjwatson> doko: I'm working on that right now
<cjwatson> doko: Also all the other things with unsatisfiable Depends: foo:any
<cjwatson> Just preparing a precise-amd64 chroot so I can build something to sync to lillypilly to test
<cjwatson> doko: Any plans to fix the python2.7 and python3.3 autopkgtests?
<doko> cjwatson, ahh, forgot about these ... maybe not today, but tomorrow
<cjwatson> Thanks
 * cjwatson curses the sheer number of places that need to be fixed for :any in britney
<tumbleweed> :/
<cjwatson> Oh, this looks betetr
<cjwatson> *better
<cjwatson>  <li>Maintainer: Debian Python Modules Team
<cjwatson> -<li>alembic/i386 unsatisfiable Depends: python:any (>= 2.7.1-0ubuntu2)
<cjwatson>  <li>Valid candidate
<barry> any chance someone could free up nose2 from the new queue?  it was uploaded before ff but it's been sitting in new for a while now and i'd love to get this into saucy
<cjwatson> I think I've unwedged :any dependencies now, after way more effort than that should have been.  Monitoring proposed-migration ...
<cjwatson>  finish: [alembic,avahi,cherrypy3,dh-python,frog,gnucash,gourmet,graphviz,ibus-hangul,ibus-xkbc,cobbler,meld,python-cliff,python-django,python-drizzle,python-pip,python-virtualenv,python-whoosh,pywapi,qtpim-opensource-src,sabnzbdplus,schooltool,schooltool.lyceum.journal,schooltool.gradebook,schooltool.cando,terminator,ubuntu-touch-meta,xpra]
<cjwatson> there we go, much better
<jokerdino> any archive admin feeling charitable enough to take a look at this FFe? bug 1226059
<ubot2`> Launchpad bug 1226059 in unity-tweak-tool (Ubuntu) "[FFe] Please sync unity-tweak-tool 0.0.5 from upstream git" [Undecided,New] https://launchpad.net/bugs/1226059
<cjwatson> s/archive admin/release team member/
<smartboyhw> jokerdino, "The new version is focused on bug fixes only and has no new features." I'm not sure if that requires a FFe.
<cjwatson> if the reporter wants release team attention then they should subscribe ~ubuntu-release ...
<jokerdino> cjwatson: aw, oops
<jokerdino> i was looking at https://wiki.ubuntu.com/SyncRequestProcess
<Laney> you want
<Laney> !ffe
<ubot2`> Feature Freeze Exception. See https://wiki.ubuntu.com/FreezeExceptionProcess for the freeze exception process.
<jokerdino> right. So I unsubscribe ubuntu-sponsors and subscribe ubuntu-release then?
<stgraber> ah, I was wondering why terminator only migrated a few minutes ago, but looking at the scrollback completely explains it :) thanks cjwatson
<sgran> hi all
<jokerdino> i ..uh am confused a little. Scott says it is not a FFe. What is the next course of action?
<jokerdino> Do I get a sponsor or something?
<smartboyhw> jokerdino, yes, you get a sponsor. It is of course not a FFe-.-
<sgran> I'm less familiar with what is ok in ubuntu for things like -updates or -proposed for LTS, so I just wanted to ask
<jokerdino> I pretty much did the same thing for syncing 0.0.4 last cycle.. :/
<Laney> The Fs in FFe stand for Feature Freeze; you don't need an exception for updates which only contain bug fixes
<Laney> so go straight to ubuntu-sponsors in that case
<sgran> open-iscsi in precise has a hack to make it not start on hosts with / on iscsi, since it gets it wrong
<sgran> this makes it impossible to run diskless compute nodes with openstack
<sgran> (which just so happens to be what I'm doing at work ...)
<sgran> a newer version does the right thing, the hack is removed, and all is well with the world
<jokerdino> Laney: can i reset the bug status then? Scott set it to invalid.
<sgran> I'm just curious if there is an avenue for the newer version to make it into precise, in some description
<tumbleweed> sgran: how complex is the patch that does the right thing?
<sgran> the difference between the version that is in precise and the version that works is quite large
<sgran> I have not even tried to track down a single patch that fixes the issues in precise - there was lots of upstream work on this area in the meantime
<sgran> in debian, I would start working with the maintainer to put this in backports, as it's too invasive for stable proper
<sgran> I don't know what the options are in ubuntu
<tumbleweed> we have backports too, which is appropriate for new versions like this
<Laney> backports would be an option
<Laney> jokerdino: sure, do that
<sgran> great, how would I go about starting that ball rolling?
<Laney> !backports
<ubot2`> If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
<sgran> thanks
<Laney> https://wiki.ubuntu.com/UbuntuBackports â tl;dr: apt-get install ubuntu-dev-tools; requestbackport -d precise -s <whatever> open-iscsi
<Laney> sgran: â
<sgran> Laney: perfect, thanks
<Laney> np
<jbicha> oh
<jbicha> that gnome-disk-utility upload was intended for a ppa so gilir could test it first
<jbicha> ScottK: if you're here I assume you want to kill it since the ffe wasn't approved yet
<jbicha> ooh, it failed to build anyway, hmm
<ScottK> jbicha: It's gone.
<Noskcaj> My latest update has installed the ubuntu touch web browser. I'm on xubuntu 13.10 amd64.
<Noskcaj> I have since installed it and it's dependencies
<skellat> cjwatson: Might Noskcaj have encountered click packages accidentally being dragged in with his scenario?
<Noskcaj> Also, will i need an FFe to merge the latest audacity 2.0.3-1 to 2.0.4-1ubuntu1? I've already prepared the branch
<cjwatson> skellat: Not possible
<cjwatson> skellat: (a) apt doesn't know about click packages so can never install them; (b) the Ubuntu Touch web browser is not currently being shipped on touch devices as a click package anyway
<stgraber> that reminds me I need to figure out how system-image and ubuntu-system-settings somehow got into the Edubuntu DVD image
#ubuntu-release 2013-09-17
<cjwatson> doko: ruby2.0 - is that really a good idea at this point?  won't it require lots of changes to module packages?
<doko> cjwatson, just the core package, which shouldn't require any changes
<cjwatson> doko: well, if it doesn't have a decent set of modules, is there a point in providing it for saucy?
<cjwatson> doko: I guess I'm looking for your reasoning
<doko> well, my reasoning is having it there for experimentation, like we had python3.0 packages before (without any set of modules). but certainly it can wait
<cjwatson> doko: hmm.  well, ok, but you get to clear up any excitement in -proposed that results from it :)
<doko> cjwatson, ok, moving the exitement to saucy :-)
<Jack_Yu> cjwatson, hi
<cjwatson> Jack_Yu: yes?
<cjwatson> (you can just say what you want straight away rather than waiting for me to reply)
<Jack_Yu> cjwaston, would please help to mark the FFE request at bug #1226492 ?
<ubot2`> Launchpad bug 1226492 in UbuntuKylin "[FFE]upload fcitx-qimpanel into archive" [High,New] https://launchpad.net/bugs/1226492
<cjwatson> Jack_Yu: If you want attention for an FFe request, please subscribe ubuntu-release to it
<Jack_Yu> cjwatson, :)
<Jack_Yu> cjwatson, done:0
<cjwatson> Jack_Yu: I'm afraid I don't really have time to look this over just now, but if you subscribe ubuntu-release to it, it will go into the queue
<Jack_Yu> cjwatson, OK, thanks.
<cjwatson> doko: if you're feeling energetic about ruby, there's a pile of ruby-* modules stacked up in -proposed with a collection of odd build failures associated with them :-(
<doko> cjwatson, ok, looking after the python builds
<jamespage> hey release team
<jamespage> I'm preparing an upload for 1.14.0 of juju-core - this is the stablization release for the 1.13.x series currently in saucy.
<jamespage> its bug fixes only (but still quite a large diff) - can I get an ack here please?
<tumbleweed> if it's bug fixes only, it doesn't require an FFe
<tumbleweed> 1.14.0 is a odd version for a bugfix only release
<jamespage> tumbleweed, its a 'stable' release
<jamespage> they get cut from the previous interim release (1.13.x)
<jamespage> features now get developed in 1.15.x series
<jamespage> tumbleweed, the slightly unusual versioning was why I was looking for an ack here
<tumbleweed> we don't care too much about the version, it's about the contents
<jamespage> tumbleweed, OK, I'll go ahead and upload then
<jamespage> ta
<tumbleweed> np
 * tumbleweed should catch up with my email so I can actually review FFes
<cjohnston> cjwatson: this isn't completely your realm, but I think it's somewhat relevant to the things you do.. If you get a minute to take a look at bug #1225442
<ubot2`> Launchpad bug 1225442 in Ubuntu Website "Checksums/keys should be hosted officially and on HTTPS" [Undecided,New] https://launchpad.net/bugs/1225442
<cjwatson> cjohnston: It's a FAQ
<cjwatson> cjohnston: At some point I'll find the last time I answered this and copy/paste
<cjohnston> :-)  thanks
<cjwatson> jibel: Do you remember how the rsync access control for autopkgtest submissions on 10.189.74.2 works?  We have a new archive offload box being set up to get things off lillypilly; I've confirmed that we can rsync off 10.189.74.2 but am not sure whether we'll be able to rsync on there
<cjwatson> jibel: And I kind of don't really want to submit a job just to find out
<cjwatson> jibel: Also, is there anything on that host that pulls things from lillypilly by name or IP?
<cjwatson> cjohnston: Actually not quite so much of a FAQ as I thought now that I've read it more carefully.  Replying
<cjohnston> Thanks cjwatson :-)
<jibel> cjwatson, you can verify it works from the new box by rsyncing a file to 10.189.74.2/adt/in/ as long as the file doesn't end with .state. Nothing is pulled from lillypilly
<cjwatson> jibel: seems to work, please clean up adt/saucy/in/foo :-)
<jibel> cjwatson, and I see it too :) removed
<doko> jamespage, any update on https://bugs.launchpad.net/ubuntu/saucy/+source/mysql-5.5/+bug/1162139 ?
<ubot2`> Launchpad bug 1162139 in mysql-5.5 (Ubuntu Saucy) "mysql-5.5 still built using GCC-4.4, should be built with the default GCC" [Critical,Triaged]
<sil2100> Hello everyone! Anyone from the SRU team can help with reviewing https://bugs.launchpad.net/unity/+bug/1043627 for SRU?
<ubot2`> Launchpad bug 1043627 in nux (Ubuntu Raring) "[SRU] Add XIM Support to Nux" [Undecided,Confirmed]
<sil2100> (precise)
<sil2100> infinity: (again) ^
<knome> hey robert_ancell
<knome> robert_ancell, thanks for helping us out with bug 1204486 - we now have at least a workaround, we think
<ubot2`> Launchpad bug 1204486 in LightDM GTK+ Greeter "Unable to select alternate languages at login screen" [Undecided,Confirmed] https://launchpad.net/bugs/1204486
<robert_ancell> knome, np
<adam_g> anyone more familiar with workings of udev + lvm able to weigh in on the regression potential of the patch on bug 1223576 ?
<ubot2`> adam_g: Error: Could not gather data from Launchpad for bug #1223576 (https://launchpad.net/bugs/1223576). The error has been logged
<jbicha> ScottK: is there anything else you need for bug 1092719?
<ubot2`> jbicha: Error: Could not gather data from Launchpad for bug #1092719 (https://launchpad.net/bugs/1092719). The error has been logged
#ubuntu-release 2013-09-18
<slangasek> ScottK, Riddell: so it looks like kubuntu active images are still being built, but haven't been released in a while.  Are those still a going concern?
<xnox> adam_g: looks good.
<adam_g> xnox, nice
<adam_g> xnox, you want me to prepare a proper debdiff? EOD here in a few but will tomorrow
<xnox> adam_g: nah, it's ok =)
<xnox> admins: Please promote python3-repoze.lru to main, the source and python2 are in main and the python3 package is now needed to build python3-routes from routes(main) src package now.
<xnox> it's in components-mismatches-proposed.txt =)
<xnox> I don't think I need to fill out M.I.R. for it.
<adam_g> xnox, thanks, a lot. if it helps speed things along at all. http://people.canonical.com/~agandelman/lvm2_2.02.95-6ubuntu4.1.debdiff and there is a raring package built in https://launchpad.net/~gandelman-a/+archive/cinder
<knome> just FYI: it's highly likely xubuntu will need a bunch of sponsored uploads, or exceptions to freezes
<jamespage> doko_, rbasak is dealing with the mysql gcc-4.4 bug you pinged about
<doko> jamespage, yes, thanks, he did ping me yesterday
<Riddell> slangasek: there's a new version of active from upstream to be FFe'ed today so I'll let you know later
<lool> Hi there, would I need a FFE to add some multi-arch headers to valac?
<lool> I'm trying to resolve a cross-build issue, but it's not trivial to unconfuse APT about multiarch headers without uploading
<lool> I'd like to add Multi-Arch: foreign to valac and valac-0.20 as I believe any architecture of this package on the build machine is good to generate code for the host system
<lool> (NB: arch: all and arch: any respectively)
<lool> there are some very old multi-arch headers on that package already, but seemed to be incomplete IIUC
<cjwatson> I think an FFe might be worth it to record the analysis of whether it's safe; in particular it's not totally obvious to me that vapigen/vala-gen-introspect are safe
<cjwatson> Since GI files are often arch-specific, IIRC
<cjwatson> It'd need considerable care with --cc options and the like too, wouldn't it?
<lool> debdiff http://paste.ubuntu.com/6123553/
<lool> cjwatson: that's indeed possible; I haven't actually tried it
<cjwatson> You should be able to preinstall valac:$DEB_BUILD_ARCH in the chroot, manually install all other build-deps, and debuild -d -aarmhf -B
<cjwatson> Or something along those lines
<lool> ok
<cjwatson> I'd definitely recommend ensuring that this isn't a difficult blind alley before adding M-A headers, based on past experience with getting this wrong :)
<cjwatson> If it's confirmed to work then indeed the risk is low
<lool> cjwatson: Ack; I was trying to make a step into that blind alley and then see how that works, but you're right I can just try with -d
<lool> :-)
<Laney> check with mbiebl too
<slangasek> Riddell: ok :)
<rbasak> What's the current turnaround for FFes? I'm waiting on bug 1194632 and am concerned that I have omitted doing something I should have causing it to be missed.
 * cjwatson looks at that one
<cjwatson> rbasak: approved
<rbasak> cjwatson: thank you!
<cjwatson> (though with a comment)
<rbasak> cjwatson: next question then. It's KVM related, and seeded-in-ubuntu reports it's seeded in ubuntu-server only. May I have another exception, please?
<rbasak> ack on the comment
<rbasak> (ie. ubuntu-upload-permission tells me I can't upload)
<cjwatson> rbasak: done
<rbasak> Thanks!
<doko> cjwatson, is this still the python3 uninstallability issue?
<doko> https://launchpadlibrarian.net/150600712/buildlog_ubuntu-saucy-armhf.python3-stdlib-extensions_3.3.1-0ubuntu2_FAILEDTOBUILD.txt.gz
<cjwatson> doko: python3-all-dev isn't Multi-Arch: allowed
<doko> hmm, it did build before ...
<doko> cjwatson, looks like a broken merge :-/
<cjwatson> A merge?  python3-defaults is in sync with Debian
<cjwatson> I see file has the same problem
 * doko grumbles at ScottK 
<cjwatson> Oh, you mean a merge into Debian
<doko> apparently he did decide to drop the changes :-/
<slangasek> never attribute to malice what can be adequately explained by fatfingering a manual merge?
<slangasek> hmm, so why does c-m no longer say anything at all about ubuntu-ui-toolkit?  I poked in the Extra-Exclude for -examples, but was expecting to see the rest of the bits still listed there
<cjwatson> ScottK: Is anyone looking at language-pack-kde-en's unsatisfiable dependency on calligra-l10n-engb?  It's been like this for a month.
<cjwatson> Riddell: ^- Maybe I should have directed that at you as the last uploader ...
<cjwatson> See http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#language-pack-kde-en
<Riddell> cjwatson: oh hmm didn't I fix that?
<Riddell> cjwatson: will take a look
<cjwatson> thanks
<jbicha> Riddell: that's bug 1224797
<didrocks> cjwatson: sorry for the stupid question, but if I have libfoo1 in main transitionning to libfoo2, libfoo2 needs a manual promotion or this is automagic?
<cjwatson> didrocks: It's automatic once the reverse-dependencies are migrated
<didrocks> cjwatson: ok, sounds good then, thanks!
<didrocks> so it does know about library transition
<cjwatson> Let us know which so we can keep an eye on it
<cjwatson> Yes
<cjwatson> Very much so :)
<didrocks> (because in the case something in main add a dep on another binary package in universe, where the source is in main, it doesn't do this auto promoition)
<didrocks> thanks cjwatson for the confirmation :)
 * didrocks still afraid if Mir bumps the ABI every 4h
<didrocks> but at least, one less issue
<cjwatson> Sigh
<cjwatson> 16:39 <didrocks> so it does know about library transition
<cjwatson> 16:39 <cjwatson> Let us know which so we can keep an eye on it
<cjwatson> 16:39 <cjwatson> Yes
<cjwatson> 16:39 <cjwatson> Very much so :)
<didrocks> 17:39:38   didrocks | (because in the case something in main add a dep on another binary package in universe, where the source is in
<didrocks>                     | main, it doesn't do this auto promoition)
<didrocks> 17:41:00   didrocks | thanks cjwatson for the confirmation :)
<didrocks> 17:41:11          * | didrocks still afraid if Mir bumps the ABI every 4h
<didrocks> 17:41:22   didrocks | but at least, one less issue
<cjwatson> proposed-migration indeed doesn't understand componnts
<cjwatson> *components
<ochosi> cjwatson: ping
<cjwatson> ochosi: hi.  please include content with pings so we don't need to spend time round-tripping
<ochosi> cjwatson: oh, sure! sorry bout that then
<ochosi> cjwatson: i've noticed that there is a logout-delay issue in many flavors (if not all, only tested xubuntu personally though, but others have confirmed other DEs), do you have any clue how that could be debugged or what could be the culprit?
<cjwatson> Sorry, I don't
<cjwatson> Not really my field
<ochosi> ok, no worries
<ochosi> it's just that i'm not the right person so i thought i'd keep asking around
<ochosi> so in case anyone else has an idea or knows who to talk to best, here's the bugreport: #1227212
<ochosi> oh, no bot? well here: https://bugs.launchpad.net/upstart/+bug/1227212
<xnox> bug 1
<rbasak> OK. Who upset the bot?
<xnox> rbasak: reported on #ubuntu-irc that ubot2` seems to be asleep =)
<lool> is it worth relaunching the desktop livefs build since it failed for some days and the fix is in the archive now?
<lool> (libunity-webapps lost its dep on webbrowser-app)
<adam_g> bdmurray, ^ that cinder fixes a regression in the package you accepted last. if you could take a look it would most appreciated
<infinity> adam_g: Accepted.
<adam_g> infinity, thanks
<doko> cjwatson, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says that codespeak-lib autopkgtest is failing, however the jenkins package shows that it succeeds
<doko> or isn't it yet run? because the last run is from Sep 18
<cjwatson> doko: I'm not totally sure, but I think there's some confusion because there was a sync of 1.4.15-1 which was later deleted
<cjwatson> doko: I *think* I've cleared it for the next run
<doko> thanks, will see if I'm still awake later. else I'll give the test rebuilds tomorrow
<cjwatson> (I edited ~ubuntu-archive/proposed-migration/autopkgtest/work/adt.request.saucy and removed the bogus entry, being careful to ensure proposed-migration wasn't running at the time)
<bluesabre> hello everyone
<bluesabre> with UIF just around the corner and our main packagers away, I've updated xubuntu's shimmer-themes package.  Normally a debdiff is sufficient for package updates, would that still be the case for a set of gtk-themes, or would it be more involved?
<bluesabre> for reference, https://launchpad.net/ubuntu/+source/shimmer-themes
#ubuntu-release 2013-09-19
<jbicha> bluesabre: tarballs would be better since there are binaries (the .png's)
<bluesabre> jbicha, thanks
<jbicha> bluesabre: or you can push to a bzr branch if you prefer
<bluesabre> thanks jbicha!  I've done just that
<knome> on the same note of "xubuntu uploaders away", we also need our docs uploaded, bug 1227275
<knome> if somebody is willing to sponsor, it's appreciated
<ScottK> doko_: I certainly didn't drop anything on purpose.
<ScottK> cjwatson: I'll ask.
<shadeslayer> cjwatson: Riddell already fixed it yesterday I think
<doko_> cjwatson, python3-defaults still not migrated. python-csb is listed as failing, however failing forever, see debian report 711376
<cjwatson> doko_: forced, http://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/373
<cjwatson> it's still not happy about codespeak-lib either
<cjwatson> doko_: trying to work this out as I think it's a proposed-migration bug - will take a few minutes
<cjwatson> doko_: I think I've fixed it for the next run ...
<doko_> thanks \o/
<cjwatson> doko_: accepted: python3-defaults
<doko> cjwatson, https://launchpad.net/ubuntu/+source/ruby-multi-xml/0.5.4-0ubuntu2/+build/5032194  should I try to cancel?  seems to build on amd64, but apparently not on i386
<cjwatson> doko: Yes, I think so
<cjwatson> It's not stuck in buildd-manager or anything
<doko> now in state Cancelling
<cjwatson> 2013-09-19 10:47:37+0000 [QueryProtocol,client] Processing finished ABORTED build PACKAGEBUILD-5032194 (i386 build of ruby-multi-xml 0.5.4-0ubuntu2 in ubuntu saucy PROPOSED) from builder komainu
<cjwatson> so the cancel worked
<cjwatson> I don't know how the ftbfs pages will show that :)
<knome> so, are the freezes landing today as in the schedule or is there some kind of delay?
 * smartboyhw thinks there is some kind of delay, as mentioned in a mail
<knome> no confirmation to the mail sent by kate yet
<smartboyhw> I think the Beta2Freeze will probably go next Monday.. (Not sure about UIFreeze and DocFreeze)
<cjwatson> smartboyhw: I wasn't aware that such a change had been agreed.  Are you referring to an agreement or are you guessing?
<cjwatson> knome: Hardly surprising, Adam's at the Plumbers conference.  I'll see about getting a mail out
<knome> cjwatson, cheers. (btw, i personally wouldn't mind at all postponing all the freezes until monday.)
<smartboyhw> cjwatson, sorry, I confused it with the Alpha freezes (the new structure is still not getting in my head).
<smartboyhw> kudos.
<Laney> I thought there was agreement about Monday freezes, but less clarity about what to freeze
<cjwatson> Laney: OK, do you have a reference for that?
<Laney> cjwatson: Just going from what people said in the thread
<Laney> there was no vote or anything like that
<cjwatson> I only see Kate saying that, and there's no reasoning given?
<cjwatson> Unless I'm looking at the wrong thread
<Laney> The one that I started
<Laney> forgot what I called it
<cjwatson> Any idea when or what list?
<Laney> oh yeah it was about blocks but it got into freeze dates a bit
<Laney> on ubuntu-release
<Laney> Message-ID: <20130904154121.GB11027@iota>
 * Laney refreshes memory
<cjwatson> Ah, right
<cjwatson> Reading
<Laney> Kylin wanted a longer one but didn't say how long exactly
<cjwatson> Right, I had totally missed this thread, sorry
<Laney> np
<cjwatson> I don't think any of this discussion affects UI freeze, though
 * smartboyhw would rather prefer 3-day freeze for Beta 1 and 7-day freeze for Final Beta, but he's got no deciding rights
<Laney> no not that, but the beta freeze
<cjwatson> or doc string freeze
<cjwatson> smartboyhw: I'm finding the arguments in the thread for switching to Monday for beta freeze (inc. final beta) pretty persuasive
<ogra> wasnt that already decided ?
<cjwatson> ogra: Kind of, apparently I missed it
 * ogra thought he saw a discussion about exactly that in here ... and there was agreement for monday 
<ogra> was a while ago already ... a few weeks
<Laney> I guess it's at the "do it and see if anyone screams" stage
<ogra> heh
<Laney> seems sensible to me
<cjwatson> I'll edit the schedule/process now
<Laney> but as for /what/ to freeze on Monday, I'm less clear
<Laney> Maybe it's moot-ish if Ubuntu is participating
<cjwatson> Indeed
<cjwatson> I think we're fine to freeze core packages for final beta freeze
<Laney> is ubuntu-touch doing it?
<knome> anybody know people who could sponsor some uploads then? :)
<smartboyhw> knome, that's #ubuntu-devel :P
<mdeslaur> infinity: so, my systemd upload is stuck in -proposed because of arm64...the queue says 12 days, is that accurate?
<cjwatson> mdeslaur: No it's not
<Laney> no it's not
<cjwatson> Nothing is blocked due to arm64
<Laney> you're waiting on the upstart test
<cjwatson> See the "(but arm64 isn't keeping up, so nevermind)" comment there
<mdeslaur> cjwatson: ah, right...how do I know I'm waiting for the test?
<cjwatson> "autopkgtest for upstart 1.10-0ubuntu1: RUNNING (Jenkins: public, private)"
<mdeslaur> ah, right
<cjwatson> I'm not too sure what's going on there - it's been running since Monday
<mdeslaur> ok, sorry, seems I lack coffee this morning
<cjwatson> jibel: ^- do you know what's up with the upstart autopkgtest?
<cjwatson> It appears to have passed on amd64 but has hung shutting down?
<cjwatson> And i386 failed
<cjwatson> jodh: Do you know if the upstart autopkgtest failure on i386 is transient?  http://10.98.0.1:8080/view/Saucy/view/AutoPkgTest/job/saucy-adt-upstart/ARCH=i386,label=adt/71/console if you have VPN access
<cjwatson> jodh: http://paste.ubuntu.com/6127979/
<jibel> cjwatson, I've already seen this when adt crashes after the end of the test, when the alarm has already been reset. In that case it runs forever if there are some stalled processes. I'll kill it.
<jibel> it happens sometimes with tests that use dbus-launch
<cjwatson> Any opinions on freeze time on Monday, or shall I basically make it start of European day?
<sil2100> cjwatson: hello! We pushed 2 new touch-related packages to the archive just now, they're in the NEW queue - Didier is aware of those, they had been, so to say, preNEWed by him - could you move them forward? Those are clickmanager-plugin and click-update-manager
<cjwatson> Laney: Also, we're doing a migration block for final beta, not an upload block, right?
<cjwatson> sil2100: OK, I had a bit of an interrupt storm, I'll try to get to it
<Laney> cjwatson: I thought so
<cjwatson> Laney: Yeah, BetaProcess is gratuitously out of date
<sil2100> cjwatson: super big thanks :)
<Laney> ah yea
<Laney> h
<Laney> I should have reviewed Kate's new page :-/
<cjwatson> It was out of date on this before the rework too
<cjwatson> would be nice if we had a canonical script to generate the block
<ScottK> cjwatson: With no unblock of migration after the beta is out, I would hope.
<cjwatson> ScottK: I think that's what we did last cycle, isn't it?
<ScottK> Yes.
<Laney> I have a script that parses seeded-in-ubuntu's data
<ScottK> cjwatson: It's one of those things we end up doing every cycle, but it seems like it's never part of the "standard" way things are going so we end up relitigating it twice a year.
<Laney> broke it a bit while playing with the new suggestion
<cjwatson> ScottK: it's in the process now; hopefully that will stick a bit better
<skaet> Laney,  since you were working the opt-in beta with me,  would still appreciate your input as to what really makes sense and what should be dropped.    :-)
<skaet> cjwatson,  agreed, it was out of date.
<Laney> yeah, will try to look soon
<Laney> thanks for working on it
<ScottK> cjwatson: Thanks.
<skaet> ScottK,  since Kubuntu's usually one of the "opt-in"s,  yours and Riddell's input on https://wiki.ubuntu.com/BetaProcess, would be good for that column.
 * ScottK really wasn't involved this time.
<cjwatson> I've left ReleaseCandidateProcess alone for now, since I forget whether we're using a hard freeze for final
<cjwatson> So start of EU day on Monday is fine by people?
 * skaet nods, but figures ScottK's got historical perspective, and may have opinions.
<Laney> Didn't we use a block-all source last time for RC/final?
<Laney> start of day seems fine
<cjwatson> Possibly.  I forget
<skaet> cjwatson,  sees like that's the consensus, but probably worth a discussion at vUDS, based on how it goes this time.
<cjwatson> what, for start of EU day?
<cjwatson> I think that's a bit minor for UDS time :)
<skaet> :-)
<Laney> I will clean this script up and get it into u-a-t
<skaet> start of EU day is fine.   I was ref'ing the prior comment
<cjwatson> oh, right, I think there is prior consensus on that, I just don't remember it right now
<Laney> not the biggest expert in apt_pkg though
<cjwatson> (to go back to ScottK's comment about relitigating; I think we've agreed it before but I just got hit with about three parallel things to do)
<skaet> does anyone know if mvo is still the right person to do the GnomeAppInstallDesktopDatabaseUpdate?    He didn't respond to my email last time,  and we probably want to make sure its done before final beta.
<cjwatson> No, he's not
<cjwatson> I'll see if I can figure out how to do it, modulo said interrupt storm
<skaet> cjwatson,  understood.  thanks.
<cjwatson> http://paste.ubuntu.com/6128057/  any comments?
<cjwatson> some of the things suggested for the mail in BetaProcess no longer really make sense given the -proposed workflow, so I made some up on the fly :)
 * skaet looking
<skaet> cjwatson,  agreed, hence overdue for that scrub.   One thought,  possibly add a link to: https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule  so folks can see the upcoming events?
<cjwatson> also http://paste.ubuntu.com/6128074/
<cjwatson> ok
<cjwatson> added
<cjwatson> See https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule for the rest
<cjwatson> of the schedule in the run-up to Ubuntu 13.10.
<skaet> one to the doc and translation folks looks fine.
<cjwatson> thanks, sent that one
<cjwatson> I have to go and help with childcare for a bit now, so I'll look over any other comments and send the main announcement when I get back (<1hr)
<doko> nice, icon and noweb can be demoted
<jibel> cjwatson, jodh FTR upstart test was blocked by bug 1227610
<skaet> dam,  following up from our earlier discussion on the translations.   I'm not seeing seb128 or jasonwarner online.    Is there anyone else you can recommend to help with "Notify DavidPlanella (ubuntu-translation-coordinators) to coordinate a fresh set of language packs which will be exported, uploaded, and built in time for beta."
<skaet> dpm, ^ ??
<dpm> I generally coordinated with pitti, who did the actual uploads, but neither him nor I have much time to work in translations, as we've moved to other roles
<skaet> dam,  pitta's here at the conference with me,  so I'll see if I can track him down and see if he's willing to help this time.    Looks like this is a gap then, that we'll need to figure out a solution for longer term.
 * skaet detests the auto correct on this systemâ¦. must figure out how to turn it off.  :-P  sorry dpm.
<dpm> no worries, I got what you meant :)
<cjwatson> skaet: I believe seb128 is on holiday
<RAOF> Are we going to get glamor-egl through NEW?
<cjwatson> jibel,jodh: OK.  I think that only explains amd64, though, not the i386 failure I asked jodh about
<cjwatson> sent the freeze announcement
<cjwatson> RAOF: yup
 * Laney imagines a pitti bread
<RAOF> cjwatson: Woot! Thanks.
<skaet> cjwatson, am heading downstairs to linux conf now, will only be online sporadically.   Will see if I can find pitti re: translations.
<cjwatson> translations were done fairly recently
<cjwatson> he may not need to bother
<skaet> ok,  we need to update that step in the checklist with a new contact.
<cjwatson> RAOF: looks like libglamor-dev could reasonably be M-A: same, FWIW
<RAOF> cjwatson: I'll fix that in git.
<cjwatson> RAOF: ta
<jbicha> hi, could gnome-documents/armhf be removed? it depends on libgdata to be built with goa support but that was disabled on armhf to try to reduce what dependencies need to be installed on the Ubuntu Phone images
<infinity> cjwatson: I was considering an archive freeze, not a migration block, but perhaps this needs more discussion, as no one seems to quite agree. :P
<cjwatson> infinity: Ah, consensus here appeared to be a migration block
<cjwatson> That's my personal preference too I think
<infinity> cjwatson: I do think there needs to be a point where we take control and actually reject uploads.  That's hard to do with a migration block.
<infinity> cjwatson: OTOH, the autolander makes archive freezes suck because of opaque copies. :/
<infinity> cjwatson: Which are basically my for/against on the matter.
<cjwatson> infinity: For final freeze, I agree; for alphas/betas, I don't think it's necessary
<pitti> hey all
<pitti> as per skaet's request: automatic langpack uploads disabled, will upload fresh -base packs on Monday for final beta (I requested an LP export, shold arrive by Mon)
<slangasek> infinity: I'm +1 for the britney block approach
<slangasek> fwiw
<Laney> for beta and/or final?
<slangasek> for beta
<slangasek> for final, we need to deal with quiescing -proposed somehow
<slangasek> either with a freeze controlling what goes in, or by communicating a plan to kick stuff back out of -proposed that fails to migrate
<infinity> Well, we carry some things over at times, but we need a way to prevent stupid uploads at the upload phase, not later.
<infinity> Rejects are better than rollbacks.
<slangasek> infinity: well, accepting into -proposed also gives us the option of diverting to t* at opening anything that we don't accept into saucy release; it's the same amount of review for the release team either way, but one option saves the uploader a second upload
<infinity> slangasek: Diverting to T is what I meant by "carrying over", but I don't want to accept something that I would never accept into S in the first place, because if they need to fix what's in release we need to punt the proposed one.
<infinity> (Plus people blatantly ignoring FF, etc...)
<slangasek> I think the case where they need to fix what's in release and have nonrelease crap in -proposed is a minority case, and we shouldn't optimize our process around that
<infinity> I think you underestimate the number of things we've traditionally had to reject in the last few weeks of release. :)
<infinity> Anyhow, I'm fine with beta being just a britney block and seeing how that goes, and I suspect we're all agreed at this point that final freeze should be an archive freeze.
<infinity> If that split turns out to be a Bad Idea, we can revisit for 14.04.
<infinity> (Or choose to be more conservative because it's an LTS, or whatever)
<stgraber> slangasek: pushed the fix for bug 1181789 to lp:~ubuntu-core-dev/ubuntu/raring/upstart/raring/
<xnox> cool. thanks.
<slangasek> stgraber: thanks!
<slangasek> infinity: it's not underestimating things that need rejected, only estimating that the number of things that need to be rejected in a timely fashion to make room for *release-worthy* upgrades to take their place is quite small
<slangasek> but regardless, yes, I'm fine with an archive freeze for FF
<lool> sorry, trying to track when the archive publisher run will be done and when the next britney run occurs; would someone be so kind to tell me when both of these start + finish in cron format, I'll make note of it here to stop wondering  :-)
<lool> nevermind, cjwatson just helpfully jumped in to explain in another chan
<cjwatson> well, I didn't answer as for cron
<infinity> The publisher has been running fine, but lillypilly seems less happy.
<cjwatson> the cron job is 03-58/5 (lp:lp-production-crontabs pepo-lp_publish) but it doesn't actually run every five
<cjwatson> that's "attempt to run every five if not already running"
<infinity> Either way, it's run several times since the last britney run.
<cjwatson> the publisher will flip the state of the upload to Published in the UI when it starts, but it isn't visible until the end, so that time span is pretty reliably the duration of the publisher
<cjwatson> i.e. about 20 mins for a run including the devel release pocket
<infinity> cjwatson: The britney run that's been running for an hour; could this be an issue? :P
<infinity> 1002      6950  0.0  0.0  12336  1504 ?        S    20:09   0:00 /bin/bash ./britney merge stats
<cjwatson> Yeah, it indeed could
<cjwatson> An hour, seriously?  FFS
<infinity> ScottK / Riddell: If I dropped the ancient ti-omap4 kernel, pvr-omap4, and the *-omap-revert X server/drivers from the archive, thus effectively killing the ability to have a kubuntu-omap4 image, would you care?
 * cjwatson nukes it from orbit
<infinity> ScottK / Riddell: That whole stack is somewhere between unsupportable and lolz, I'd much rather we just drop it entirely.
<lool> noting cron details
<Riddell> infinity: I'd care but I'd be convincable
<Riddell> infinity: but server has omap4 too?
<infinity> Riddell: omap4 for server can be done with the -generic kernel, since it doesn't need a decent graphics driver.
<infinity> Riddell: That's potentially doable for kubuntu too, if you guys don't care about having any acceleration.
<infinity> (Entirely impossible for Ubuntu Desktop, since we rely on working GL/EGL)
<infinity> Riddell: Basically, supporting the quantal kernel and a reverted X server forever is just not a tenable solution.
<infinity> Nooooo!
<infinity> cjwatson: gcc-4.8 failed on kijo...
<infinity> cjwatson: Oh, lolz.  150m timeout.
 * infinity headdesks.
<cjwatson> sigh
<cjwatson> any prospect of that new kernel?
<infinity> Pestering dannf every day. :P
<cjwatson> bdmurray: thanks for partman-basicfilesystems; note that it's part of a set with partman-efi
<cjwatson> (and a forthcoming grub2)
<bdmurray> cjwatson: okay, getting there
<cjwatson> infinity: I guess we could bump the timeout just for arm64 and try again.  Dunno if it's worth it ...
<infinity> cjwatson: Or just on kijo01, since it's defined in .sbuildrc (which is puppeted, but IS could override it).
<cjwatson> yeah
<cjwatson> I suppose it might as well be doing something
<infinity> cjwatson: I'm not sure it's worth the effort if we think we're getting a fixed kernel soon.
#ubuntu-release 2013-09-20
<Mirv> hmm. bug #1219695 and the last comments.
<Mirv> ie. it seems the Touch multimedia team would like to have a qtmultimedia fork in with different package names.
<Mirv> I start to think it's not related to Qt 5.1.1 FFe as such, but it doesn't sound it would automatically fall under the generic touch FFe either at least without further discussing
<Mirv> since it's both Qt 5.1.1, but not really (the upstream 5.0.2 version stays in archives). it's touch specific, but it's a fork of upstream sources.
<ScottK> Mirv: I'd suggest ask for a new FFe.  You'll need an archive admin to volunteer to New it in any case.
<Mirv> ScottK: ok, sounds sensible
<ScottK> Mirv: Would you please mark the 5.1.1 FFe tasks invalid.
<Mirv> ScottK: ok
<Mirv> ScottK: or won't fix, as you did for qtbase and qtdeclarative?
<ScottK> Yes.  That's what I meant.  Sorry.
<ScottK> Even more sign I should be sleeping now.
<Mirv> (done)
<Noskcaj> Can someone look at bug 1221913 please?
<asac> cjwatson: hi
<asac> cjwatson: we have a whole desktop lot in our CI staged
<asac> cjwatson: i assume it was supposed to land yesterday and just waits there... can you check the === unity ==== stack changes here: http://people.canonical.com/~platform/cu2d/results
<asac> and tell me if you want to reject anything of that?
<asac> search for ==== unity ====
<cjwatson> asac: It doesn't look like anything there breaks UI freeze, with the possible exception of the unity-scope-mediascanner change - but at worst that looks like a reasonable bug-fix and it's only in a single scope
<cjwatson> asac: Do you know of any UI changes I've missed?
<cjwatson> (I mean, of the kinds that would show up in screenshots)
<asac> ok ... i didnt pay much attention to desktop, so i dont have a good understanding, but i will find someone to tell me
<asac> dont worry then
<cjwatson> I'm OK with the rest of it
<knome> this has been bugging me for a few cycles already, so here's the thing: does anybody think there is any reason to prefer the *visual* formatting in https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule over https://wiki.ubuntu.com/PasiLallinaho/ReleaseScheduleReformatting ?
<cjwatson> Not a bad idea; the text towards the bottom of the original gets increasingly hard to read.
<knome> exactly
<cjwatson> The visited-link colour on the darkest red here actually makes my eyes hurt trying to read it.
<knome> if there are other thing you think might make it more legible/useful (visually), feel free to point out
<knome> *things
<cjwatson> I think you should go ahead and make that change, also to TSeries/ReleaseSchedule
<cjwatson> In fact wouldn't hurt to change historical schedules as well
<cjwatson> You can put r=cjwatson in the commit message if you like
<knome> ok, i'll do that
<knome> cheers :)
<knome> (btw, we have one UIFe coming... bug 1228098, but that's not completely prepared yet)
<Mirv> I've helped the multimedia team to craft FFe of a co-installable alternate qtmultimedia version which would bring GStreamer 1.0 support as long as a released upstrea version does not yet have it https://bugs.launchpad.net/ubuntu/+bug/1227987
<Mirv> I will however leave it to sergiusens hands now soon for today
<knome> cjwatson, done for S and T
<cjwatson> thanks
<knome> cjwatson, will go through the historical ones when i have extra time
<Laney> Mirv: that's more than just GStreamer 1.0 porting, isn't it?
<Laney> otherwise why does it mention mir?
<Mirv> sergiusens: ^
<sergiusens> Laney, let me get jhodapp on here
<Laney> no need, you can reply in the bug
<jhodapp> sergiusens, here
<sergiusens> jhodapp, Laney just said to reply in the bug for the FFe explaining all the changes in QtMultimedia
<sergiusens> wrt to the Mir symbols and such
<Laney> ScottK: do you have an opinion about this?
<jhodapp> sergiusens, so reply to this one? https://bugs.launchpad.net/ubuntu/+bug/1227987
<Laney> jhodapp: It's because I think there might be a bit more than just porting to gst 1.0 APIs
<jhodapp> Laney, yes there is more, I added a new renderer control
<jhodapp> sergiusens, the package is close...I just tested with it and I get audio playback but no video
<sergiusens> jhodapp, awesome, let's go back to #phablet
<jhodapp> k
<jbicha> please remove the binary for gnome-documents/armhf
<attente> hello, is there anyone i can talk to about this FFe? https://bugs.launchpad.net/unity-greeter/+bug/1228207
<knome> cjwatson, oneiric, raring and precise are fixed. quantal was okay with no dark red, so i left it as is.
<cjwatson> knome: thanks
<knome> cjwatson, unless stgraber gets to it first, we need bug 1228098 ACK'd (we have an uploader today)
<stgraber> knome: approved
<stgraber> knome: (as your doc team is fine with that and it won't be a problem there)
<knome> cheers :)
<cjwatson> heh, in-flight collision
<cjwatson> do see my comment though
<stgraber> well, at least we agreed :)
<stgraber> oh, and good point about ubiquity
<infinity> *cough*
<knome> yeah, we need to look at ubiquity. thanks for catching that...
<knome> cjwatson, we need to change the name in ubiquity as well. UIFe still ACK'd? :)
<knome> or stgraber, or infinity...
<cjwatson> Yes
<knome> also, question: are *new* shortcuts (binding media keys) considered under FFe or not?
<knome> or, FF
<knome> while we update the our default-settings package, would be good to get those in as well. can file a FFe bug if needed.
<stgraber> knome: can you give me the new name?
<knome> stgraber, just a sec, i'll confirm that
<knome> stgraber, xubuntu-wallpaper.png in the same directory as the previous one.
<stgraber> knome: so /usr/share/xfce4/backdrops/xubuntu-wallpaper.png, correct?
<infinity> jibel: Want to help me navigate jenkins and divine why the nova tests seem to have been failing?
<knome> stgraber, correct. :)
<infinity> jibel: Oh, nevermind, I think I found it.
<stgraber> knome: I pushed the fix to the ubiquity packaging branch. Let me know once the new wallpaper is in the archive and I'll look into uploading ubiquity.
<knome> stgraber, thanks, i'll do that
<knome> can anybody confirm my question re: shortcuts a while ago?
<ochosi> hi everyone, can someone please take a look at this FFe? https://bugs.launchpad.net/ubuntu/+source/xubuntu-default-settings/+bug/1228356
<ochosi> (and ideally ACK it ;))
<ochosi> stgraber: knome is afk, but the xubuntu-artwork pkg with the new wallpaper has just been uploaded
<stgraber> ochosi: ok
<ochosi> stgraber: thanks for updating ubiquity!
<ochosi> this will be the last time this has to be changed, pinky-promise
<stgraber> cjwatson: so I see you commited the reiserfs change to ubiquity, should I just refresh the builtin source packages or do we need anything else before that's uploadable?
<ochosi> stgraber: maybe that's asking too much, but if you have time to look at the FFe i posted above, we'd have an uploader around tonight (and it should be a trivial FFe)
<attente> hello, is there anyone i can talk to about this FFe? https://bugs.launchpad.net/unity-greeter/+bug/1228207
<ochosi> attente: are you working on unity-greeter? cause i spotted a small bug...
<attente> ochosi, not actively, only for the bug i just posted
<ochosi> ah ok
<ochosi> stgraber: thanks a lot!!
#ubuntu-release 2013-09-21
<ScottK> Laney: I asked a couple of questions in the bug.
<Noskcaj> Can someone remove ubuntu-PPC from this iso trancker since it's not built any more
<cjwatson> stgraber: just a 'debian/rules update' should be fine
#ubuntu-release 2013-09-22
<Noskcaj> Is there any chance we could sync a newer version of lintian? saucy's version is already 3 releases old
<smartboyhw> Noskcaj, I think we want it stable?
<smartboyhw> That can wait for T
<Noskcaj> ok
<slangasek> infinity: seems cardamom is down?
<knome> hmmf, somebody can confirm if keyboard shortcut changes are suspect to freezes?
<cjwatson> slangasek: Yeah, I asked #is about that on Saturday morning, no response as yet
<infinity> slangasek / cjwatson: cardamom is coming back up (London) Monday morning.  Someone tried to reboot it and got it in a state that needed remote hands.
<slangasek> cjwatson, infinity: ok
<micahg> is cardamom down the source of the non-generated CD images?
<debfx> ScottK: is saucy-backports already open? (or is it not too late to sync a new multiverse package?)
<slangasek> micahg: yes
<micahg> great, thanks
#ubuntu-release 2014-09-15
<Adri2000> is it possible that the checksums in there https://cloud-images.ubuntu.com/vagrant/trusty/current/ are not correct?
<Adri2000> tried trusty-server-cloudimg-amd64-vagrant-disk1.box twice and I don't get the expected sha256sum
<pfsmorigo> infinity: hi, do you know what we can do about https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1346851 ?
<ubot93> Launchpad bug 1346851 in debian-installer (Ubuntu) "Ubuntu 14.10 VNC mode installation hangs at the installer screen "Select a language"" [Undecided,New]
<shijing> @cjwatson bug#1112878 still exist
<shadeslayer> shijing: cjwatson dupe of 1325801
<shijing> yes
<mlankhorst> infinity: just to be clear, I had an ok for mesa FFE upload right?
<mlankhorst> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1364003
<ubot93> Launchpad bug 1364003 in mesa (Ubuntu) "[FFE] mesa 10.3" [High,New]
<Laney> not in that bug at any rate
<mlankhorst> yeah which is why I was asking
<mlankhorst> fwiw mesa 10.3.0~rc3 is available in debian-experimental and ppa:canonical-x/x-staging :P
<Laney> ochosi_: you xubuntu guys are organised ;-)
<elfy> we have to be, others come along and try to unorganise us :p
<Laney> 'being disruptive'
<elfy> lol
<infinity> mlankhorst: You had an okay iff you're sure there will be a 10.3.1 (or better) in time to slide in before release, and it you've proven that it doesn't break kwin/kubuntu.
<infinity> pfsmorigo: Hrm.  I didn't even know there was a VNC installation method.  Way to test things I don't use. ;)
<infinity> pfsmorigo: Oh, there isn't.  You just mean you're using VNC as your KVM console.
<infinity> pfsmorigo: So, did this  used to work at some point, and is there any reason to suspect it's Ubuntu's fault, rather than the virsh/vnc setup you're using?
<pfsmorigo> infinity: this came from our test team. I'll try to reproduce it later
<infinity> pfsmorigo: I don't doubt that it can be reproduced by following their exact steps.  My curiosity is if there's an assertion here that following those steps worked in the past (say with 14.04).
<infinity> pfsmorigo: Cause other than the kernel perhaps detecting the OF keyboard devices differently (which we would bounce back to you), I can't think of how this could have regressed, so I'm assuming this configuration never worked.
<pfsmorigo> infinity: good point
<infinity> pfsmorigo: So, if you can both reproduce it and verify if it does or doesn't behave the same with a 14.04 ISO, we can start playing the blame game.
<infinity> pfsmorigo: I'll admit to having never used the kvm vnc interface on my machines, I just test with serial (and, indeed, I disable vga/keyboard entirely, so my OF doesn't even have those device nodes), so it's possible it never worked at all on a (faked) "real console", but I'm having a harder time believing it regressed.
<hallyn> infinity: hi, could you consider bug 1367422 ?
<ubot93> bug 1367422 in libvirt (Ubuntu) "[FFE] Upgrade to 1.2.8" [High,New] https://launchpad.net/bugs/1367422
<hallyn> it'll allow apparmor-protected libvirt containers in utopic
<infinity> hallyn: ... and the two test regressions?
<infinity> hallyn: Is that just bad stdout parsing, or something that will actually affect other packages?
<mlankhorst> infinity: ok, I'll try kwin :P
<mlankhorst> but I thought ScottK was checking too
<infinity> mlankhorst: I thought he might have, but no one told me one way or the other if there were results. :P
<infinity> mlankhorst: I'd like you two to sort that out before you sign off on it.
<infinity> mlankhorst: Cause it's too late in the cycle to accidentally break other flavours.
<infinity> mlankhorst: (And if compiz and kwin are both happy, you're probably in good shape for feature coverage)
<hallyn> infinity: things needing updating in the testsuite i believe
<hallyn> will re-run and confirm
#ubuntu-release 2014-09-16
<bluesabre> release-team, just want to verify with you all... we (xubuntu) have been carrying the development releases of xfce4-power-manager (1.3.x) for utopic, and the stable release (1.4.0) is now available. It consists of bug fixes.  Since the version number is a leap to stable, just want to get the stamp of approval.
<tumbleweed> bluesabre: we care about contents, not version numbers. If the contents are only bug fixes, and there is no cause to suspect incompatibilities, you're good to go
<bluesabre> tumbleweed: thanks, I figured as much. Didn't want to have to "apologize to the release team" ;)
<ScottK> bluesabre: How's it work with upower 0.99?
<bluesabre> ScottK, the depends would have to be swapped to >= 0.99, otherwise fine...
<bluesabre> though the Xubuntu team is currently opposed to the transition to upower 0.99 this late in the utopic cycle
<ScottK> I'm wondering since you Xubuntu folks reacted pretty strongly.
<ScottK> I got that.
<ScottK> I didn't know if it was based on actual testing and problems or fear alone.
<bluesabre> Mainly the risk of possible regressions. We have a limited testing group and the updated upower is largely untested in the xfce components (patches were only added very recently)
<bluesabre> Also, the updated gnome stack has the potential of other untested components landing as well
<bluesabre> (untested for us anyway)
<bluesabre> So from project lead, qa lead, and technical lead, we are all vary wary of the changes that the transition may bring
<bluesabre> *very
<bluesabre> ochosi_ ^
<ScottK> Right, so what's the impact on Gnome of not updating?
<ScottK> Maybe they'd be motivated to help testing Xubuntu to mitigate your risk?
<bluesabre> Right, and it clearly has a significant impact on them, so this would be good for further discussion with both teams
<bluesabre> The xubuntu team was really only made aware of this potential change recently, and indeed, the bug report only updated to [FFe] status 3 days ago
<skellat> ScottK, bluesabre: The impact on Gnome is that they miss landing GNOME 3.12 well after Feature Freeze too
<skellat> They would still ship 3.8 components
<ScottK> Not 3.10?
<skellat> ScottK: We were told they would be stuck at the same components they shipped in UG14.04
<ScottK> OK.
<ScottK> Do they want to update at this point?
<skellat> We were informed that upower was the last thing they needed to land GNOME 3.12 so they could have it in 14.10
<skellat> Pardon me, one of the last things
<mlankhorst> morning
<mlankhorst> infinity: hm as far as I can tell I didn't break kwin
<mlankhorst> seems to work just fine, but I'll try the other drivers too just to be sure
<mlankhorst> compiz 32-bits seems to work too
<jzheng> hi SRU team (not sure who is still online)
<jzheng> there is an SRU for ubuntukylin-theme in https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text= for a long time. So I wonder if anyone from SRU team can have time to help approve it? It is for Ubuntu Kylin 14.04
<infinity> mlankhorst: That's good news, then.
<jamespage> those three are covered under bug 1369927
<ubot93> bug 1369927 in golang-context (Ubuntu) "[FFe] Sync docker.io 1.2.0 from Debian unstable" [High,Confirmed] https://launchpad.net/bugs/1369927
<mlankhorst> yeah
#ubuntu-release 2014-09-17
<mlankhorst> infinity: could you give me the ok now to upload mesa then?
<jamespage> Laney, any chance you have time to review the FFe's for the syncs of the python-xstatic packages I emailed on ubuntu-release@l.u.c about yesterday? I'd like to get everything lined up for the MIR asap
<Laney> jamespage: will take a look at the queue this afternoon
<jamespage> Laney, ack
<jamespage> ta
<arges> cjwatson: can you take a look at seabios in the trusty unapproved queue (i uploaded that one)? I'm looking at some of the other SRUs since I was out yesterday. thanks
<cjwatson> sure
<cjwatson> arges: can I trade you for grub2/precise?
<cjwatson> (which I sponsored)
<arges> cjwatson: sure
<cjwatson> arges: ta
<cjwatson> arges: ^- that's just tagging along with grub2
<arges> cjwatson: does that need to be accepted ?
<cjwatson> yep, to make things installable for UEFI users
<cjwatson> well UEFI Secure Boot
<didrocks> barry: didn't get a chance to thanks you about nose-core fix btw! soâ¦ thanks! :)
<barry> didrocks: yw! :)
<barry> didrocks: now i just have to get you to switch to nose2 :)
<didrocks> barry: maybe at the device sprint? (I'll be away for 3 weeks just before it)
<barry> didrocks: +1
<didrocks> let's do this then :)
<barry> didrocks: maybe i should give a talk on nose2?
<didrocks> barry: would love it! I don't really know the difference TBH, and I guess I'm not the only one interested
<barry> didrocks: i'll put it on the spreadsheet
<didrocks> sweet
<Laney> jamespage: sorry, I timed out
<Laney> perhaps someone to the west could look
<arges> cjwatson: the intel-microcode version for trusty in -proposed seems to cause issues. should I remove that package from -proposed (since I'm unsure an update will overwrite it anytime soon)
<cjwatson> arges: that sounds sensible, though bdmurray is better at handling such things than I am
<lool> cjwatson: would you have some LP super powers?
<lool> to remove random bzr branches for instance
<lool> cjwatson: also, would you mind removing the 14.09 NM block hint? not needed anymore
<cjwatson> lool: I don't have relevant superpowers over branches
<cjwatson> lool: block removed
<lool> cjwatson: thanks
<infinity> mlankhorst: Yes, do it. :P
<mlankhorst> oke
<mlankhorst> tomorrow morning, I've tested most combinations now for 10.2.6 and 10.3~rc3
<infinity> mlankhorst: Oh, while I'm approving FFes for you, did you pull that Altivec patch I asked you about?
#ubuntu-release 2014-09-18
<mlankhorst> morning
<mlankhorst> infinity: oops, I'll check
<infinity> mlankhorst: http://lists.freedesktop.org/archives/mesa-dev/2014-August/064711.html if you need a reminder.
<infinity> mlankhorst: Please and thankyou.
<mlankhorst> thanks for reminding, I'll upload mesa later today, only need to test snb for regressions still
<rbasak> ^^ bcache-tools NEW in Utopic, for FFe bug 1355890. It should be trivial to review.
<ubot2> bug 1355890 in Ubuntu "[FFe] bcache-tools" [Undecided,Triaged] https://launchpad.net/bugs/1355890
<ubot93> bug 1355890 in Ubuntu "[FFe] bcache-tools" [Undecided,Triaged] https://launchpad.net/bugs/1355890
<rbasak> Please can an AA reject percona-* from Utopic NEW? With the mysql 5.6 issues, we've decided to defer this cycle, as we're already late.
#ubuntu-release 2014-09-19
<ScottK> rbasak: Done.
<rbasak> ScottK: thanks!
<bluesabre> Release team, the Xubuntu team has filed for UI Freeze Exception for...
<bluesabre> xubuntu-default-settings: https://bugs.launchpad.net/ubuntu/+source/xubuntu-default-settings/+bug/1371554
<ubot2> Launchpad bug 1371554 in xubuntu-default-settings (Ubuntu) "[UIFe] Xubuntu Default Settings Minor UI Updates" [Undecided,New]
<ubot93> Launchpad bug 1371554 in xubuntu-default-settings (Ubuntu) "[UIFe] Xubuntu Default Settings Minor UI Updates" [Undecided,New]
<bluesabre> xubuntu-artwork: https://bugs.launchpad.net/ubuntu/+source/xubuntu-artwork/+bug/1371555
<ubot2> Launchpad bug 1371555 in xubuntu-artwork (Ubuntu) "[UIFe] Xubuntu Default Wallpaper for Utopic" [Undecided,New]
<ubot93> Launchpad bug 1371555 in xubuntu-artwork (Ubuntu) "[UIFe] Xubuntu Default Wallpaper for Utopic" [Undecided,New]
<bluesabre> Please let me know if these can be approved, so that we might be able to upload today.
<ScottK> bluesabre: As long as Xubuntu and it's docs people are OK with it, those seem fine.
<ScottK> bluesabre: Who's the right Xubuntu person to officially ack those for Xubuntu?
<elfy> ScottK: if one of the xubuntu release team is sufficient then bluesabre is one, as am I
<bluesabre> I've also invited slickymasterWork to this channel, our current docs lead
<ScottK> elfy: Should be.  Thanks.
<ScottK> bluesabre and elfy: Approved.
<bluesabre> thanks ScottK
<elfy> thanks ScottK
<jamespage> please could a member of the release team review the sync requests that require FFe's that I emailed about on ubuntu-release a few days ago
<jamespage> really want to get out next horizon upload in so we can test in-archive and kickoff the MIR process
<jamespage> Laney, cjwatson, Daviey: ^^ maybe one of you nice folks could help me out?
<cjwatson> not me today sorry
<Laney> Maybe ScottK as a python person?
<ScottK> Laney: They should all be fine.
<Laney> I felt a bit uneasy about the plan to rebundle the things, but maybe that's just me
<ScottK> As long as it's sync'ed from Debian, I wouldn't worry.
<Laney> They want to undo the unbundling that Debian did
<ScottK> Oh.
<ScottK> Then no.
<Laney> Because it would require MIRing nodejs and maybe other things, so I can see where they're coming from somewhat
<Laney> Ho hum
<ScottK> OK.
<ScottK> Well then I have ENOTIME to look at it and form an opinion.
<Laney> I feel like maybe it's okay as a this-cycle-only thing
<Laney> Someone give a second opinion
<cjwatson> infinity: fractionally more than a trivial bump, but could you have a look at d-i/trusty-proposed please?  should unbreak trusty images.
<cjwatson> we're not in the habit of bumping d-i in stables often enough really
<jamespage> Laney, not sure this is a this-cycle-only thing - my perspective is that the security team don't want to widely support lots of JS libraries in Ubuntu main but I'll let jdstrand respond on that point
<jdstrand> we would prefer to not support lots of js libraries in main. xstatic doesn't actually save us from that, but we can contain the situation better by updating the MIR requirements to not allow the use of those xstatic libraries
<jdstrand> the situation we are in is far from ideal
<jdstrand> we could embed all those xstatic libraries in horizon I suppose...
<jdstrand> but that seems like a lot of pain
<infinity> cjwatson: Ick, unicode quotes in changelog.
<infinity> cjwatson: Accepting.
<cjwatson> infinity: oh, I copied and pasted from the Debian changelog and didn't notice :)
<cjwatson> thanks
<infinity> Err, I didn't check before accepting, is that building against the -updates kernel or the -proposed one?
<infinity> Oh good, proposed.
<cjwatson> should be yeah
<infinity> That kernel's due to hit updates on Monday, so I'll slide d-i in with it.
<sil2100> Hey! I filled in a quick FFe for touch packages: LP #1371635
<ubot2> Launchpad bug 1371635 in Ubuntu "[FFe] standing freeze exception in utopic for Ubuntu Touch-specific packages" [Undecided,New] https://launchpad.net/bugs/1371635
<ubot93> Launchpad bug 1371635 in Ubuntu "[FFe] standing freeze exception in utopic for Ubuntu Touch-specific packages" [Undecided,New] https://launchpad.net/bugs/1371635
<sil2100> Could anyone from the release team check if it makes sense? It's my first big FFe like this
<Laney> sil2100: You should check those "for some reason" packages with seeded-in-ubuntu
<Laney> I know for example that ofono is in kubuntu-plasma5
<Laney> s/for some reason/somehow/ :)
<sil2100> Right! Flavors, I just compared with the main desktop manifest in those cases
<sil2100> And also compared with the old script for generating this list that came from slangasek
<sil2100> But I guess it didn't take flavors into account as well
<ScottK> Also, because of RTM, I thought we decided not to do a blanket FFe this time.
<infinity> cjwatson: Argh.  In another call, it was pointed out to me that there's a keystone flavour in d-i in trusty.  Your upload only bumped master, not keystone.
<sil2100> There was a discussion about that, but due to the policy we are forcing that anything that lands to RTM needs to land in ubuntu, an FFe is really useful
<infinity> sil2100: I guess I missed the discussion that led to this conclusion.  The only times it came up that I was aware, people felt that having the extra level of review/oversight would be a good thing, not a bad thing.
<didrocks> sil2100: you should take my last year script, it took the flavors and reasons into account
<didrocks> (it was based on cjwatson's one)
<sil2100> infinity: there was a mailing list discussion regarding that, and the final decision seemed to be 'yes, we fill-in an FFe' - I also confirmed it with slangasek that this was what we wanted
<infinity> sil2100: Fair enough.
<sil2100> didrocks: ah! I see it, the additional seeded-in-ubuntu part - I'll run it through the list that I have generated
<sil2100> I suppose it'll take time to run though
<Laney> umm
<Laney> you know that generate-freeze-block uses the same data as seeded-in-ubuntu?
<sil2100> Ah, ok, then the list from generate-freeze-block is enough then
<Laney> It's the manually added stuff you should be looking at
<sil2100> Anyway, it might be good to discuss some of the ones that I added anyway
<Laney> I think you should at least put those in a separate section
<sil2100> But I guess things like ofono should have only bugfixes anyway
<sil2100> Right
<sil2100> Not sure about click and such
<Laney> what does s-i-u say about that?
<sil2100> cjwatson: do you think we need the blanket FFe for click?
<sil2100> Laney: it's in ubuntu-core for instance
<Laney> hmm, I disclaim any clue about that
<sil2100> click (from click) is seeded in:
<sil2100>   ubuntu-core: daily-preinstalled
<sil2100>   ubuntu: supported
<sil2100> Supported here as well I guess...
<infinity> I think that ubuntu-core thing is a weird overload from system-image.
<infinity> The ubuntu-core tarball certainly doesn't contain click (nor is it defined by a seed).
<infinity> Too many things named "core", none of which relate. :/
<ScottK> core-core.
<cjwatson> sil2100: I don't care either way; happy to ask individually
<cjwatson> infinity: doh
<cjwatson> infinity: you fixing?
#ubuntu-release 2014-09-21
<knome> FYI, we plan to do a documentation upload for xubuntu 14.10 (bug 1372085). it's ok from docs team point of view, but if there's any objections or question, i'm here to answer them :)
<ubot2> bug 1372085 in xubuntu-docs (Ubuntu) "[DSFe] Xubuntu Documentation for 14.10" [Undecided,New] https://launchpad.net/bugs/1372085
<ubot93> bug 1372085 in xubuntu-docs (Ubuntu) "[DSFe] Xubuntu Documentation for 14.10" [Undecided,New] https://launchpad.net/bugs/1372085
<knome> hmm, bot overload!
<xnox> above ^ with bibletime rebuild should allow sword to migrate.
<Noskcaj> hgsubversion and tortoisehg don't work properly with our current mercurial version, i'll make an FFe to fix them today
#ubuntu-release 2015-09-14
<flocculant> morning - are people aware that wily dailies are not working too well since the end of last week? bug 1495017
<ubot93> bug 1495017 in ubiquity (Ubuntu) "ubiquity crashed with dbus.exceptions" [Medium,Confirmed] https://launchpad.net/bugs/1495017
 * darkxst fires my QA team, no one told me about that flocculant , even though I seem comments from some of them on the bug!
<flocculant> darkxst: I didn't check your image as I saw comments - so I assume it's an issue for you too
<flocculant> I do try and doublecheck a few images when I see things like this on Xubuntu
<darkxst> pitti, how can this even happen on a dbus call interface="(unset)" see ^ bug
<pitti> darkxst: err, context?
<pitti> darkxst: but no idea about an unset interface -- could you try and ask smcv?
<darkxst> ubiquity is crashing apparently, see bug 1495017
<ubot93> bug 1495017 in ubiquity (Ubuntu) "ubiquity crashed with dbus.exceptions" [Medium,Confirmed] https://launchpad.net/bugs/1495017
<flocculant> it's not apparent - it really is :)
<darkxst> flocculant, it may not be ubiquity's fault though
<flocculant> you can get it to run - once you've got to the desktop
<darkxst> that sounds racy
<flocculant> darkxst: ack
<pitti> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 7 matched rules; type="method_call", sender=":1.18" (uid=999 pid=1733 comm="/usr/bin/python3 /usr/lib/ubiquity/bin/ubiquity --") interface="(unset)" member="GetDevices" error name="(unset)" requested_reply="0" destination=":1.6" (uid=0 pid=1437 comm="/usr/sbin/NetworkManager --no-daemon ")
<pitti> darkxst: ^ that looks quite straightforward?
<pitti> darkxst: i. e. I suppose the new NM changed its policy somehow?
<darkxst> what, NM got updated? that slipped past me!
<darkxst> pitti, all makes sense now
<pitti> I updated the bug
<pitti> darkxst: yeah, it was stuck in -proposed for several weeks
<darkxst> I had the flu for several weeks
<darkxst> pitti, looks like it was ported to gdbus
<darkxst> NM that is
<darkxst> but that would be after 1.0.4 release ;(
<jamespage> doko, all new binaries for gf-complete are now built ^^
<davmor2> jamespage: that sounds so Weird Science if you manage to build a complete gf
<ogra_> now i feel old
<davmor2> ogra_: why because you got that or you realised the film was in the 80's so is 30 years old?
<ogra_> yeah ... *sniff*
<flexiondotorg> infinity, Please could you update ubuntu-mate-meta for me?
<infinity> flexiondotorg: I think I can manage that.
<flexiondotorg> infinity, Many thanks.
 * infinity wonders idly why pull-lp-source is exploding.
<infinity> Oh.  Because python really doesn't like cwd not existing.
<cyphermox> I'm trying to sponsor mate-netspeed, but I'm getting a reject: mate-netspeed 1.10.2+dfsg1-1 in stretch (same version already has published binaries in the destination archive)
<cyphermox> any idea what might be the issue? I'm specifying to pick it from unstable and send it to wily-proposed
<cyphermox> (this is a sync)
<infinity> That's a reject from soyuz?
<infinity> Huh.  So it is.
<infinity> cjwatson, wgrant: ^-- WTF, mate.
<infinity> cyphermox: Oh.
<infinity> cyphermox: https://launchpad.net/ubuntu/+source/mate-netspeed/+publishinghistory
<infinity> cjwatson, wgrant: Nevermind.  britney broke it.
<cyphermox> ah
<infinity> cyphermox: It was synced weeks ago, and broke on migration.
<infinity> cyphermox: I'll copy it back into proposed.
<cyphermox> yes, that would certainly explain it
<infinity> cyphermox: And let britney migrate it again.
<cyphermox> thanks
<cyphermox> and let it explo
<cyphermox> de again.
<cyphermox> :)
<infinity> Hahaha.  No, it's totally broken.  That's why britney broke it.
<infinity> cjwatson, wgrant: Reping.  https://launchpad.net/ubuntu/+source/mate-netspeed/1.10.2+dfsg1-1 is a mess ... What happened there?
<infinity> cyphermox: Path of least resistance will be to upload a build1.
<cyphermox> ok
 * infinity really wants to know how soyuz created those duplicate build records...
<bdmurray> infinity, slangasek: I forget did we have ubuntu-release-upgrader skip an EoL release? Maybe that was to allow Raring to Trusty upgrades?
<slangasek> bdmurray: I think we did have to deal with this previously, yes, though I wouldn't remember the details of how
<bdmurray> Does it seem like people upgrading from Trusty should not be upgrading to Utopic and then Vivid?
<slangasek> yes
<bdmurray> I guess I've just added to my own TODO list.
<slangasek> ;)
<wgrant> infinity: https://bugs.launchpad.net/launchpad/+bug/682692
<ubot93> Launchpad bug 682692 in Launchpad itself "Some PPAs have duplicated builds" [High,Triaged]
<wgrant> infinity: But in this case it was probably just two simultaneous copies.
<infinity> bdmurray: I think we discussed that, in light of the 9mo release schedule (and to better prepare us for lts->lts), the release upgrader should be capable of upgrading to the "latest" release, skipping in between.  I don't know that we made that happen, though.
<infinity> The latest within a supported set of upgrade paths, that is.  Not that quantal should be able to upgrade to wily or any such madness.
<bdmurray> Okay, that's what I was sort of remembering too.
<infinity> bdmurray: My take is, that, given we have to support 14.04->16.04, we're actually making our lives easier by making sure 14.04->15.10 (for instance) works.  Since we'll know we have the right bits in place for 16.04.
<infinity> Or most of the right bits.
#ubuntu-release 2015-09-15
<sil2100> Hello! I'm looking for some ubuntu archive admins that could help approving the addition of new binary packages in a landing that's waiting for approval in the CI Train
<sil2100> The packaging diff already got approved by kenvandine, we now need someone to +1 the new binary packages that will appear after publishing
<sil2100> The packaging diff:
<sil2100> https://ci-train.ubuntu.com/job/ubuntu-landing-010-2-publish/80/artifact/unity-scopes-api_packaging_changes.diff
<cyphermox> if someone could review this network-manager SRU ^, it's long overdue :)
<tjaalton> could someone ack the new binaries of mesa-lts-vivid for trusty-proposed
<pitti> tjaalton: done
<tjaalton> pitti: nice, thanks
<utlemming> hi all...question on the backports process. I've upload open-vm-tools for {trusty,vivid}-backports and its sitting in the queue. The wiki is unclear as to who approves. Is it the release team or the backports team?
<utlemming> or can an SRU team member approve it?
<infinity> utlemming: Backports are the backport team, but the more interesting question would be why are you using backports for that?
<infinity> utlemming: Backports isn't appropriate for anything we'll end up "supporting" (ie: if you're putting it in images, or encouraging customers to use it).
<utlemming> infinity: oh, no way am I putting that in images. I just backported it because people are asking about it.
<infinity> utlemming: Kay.  So, yeah, backports are the backports team, I don't touch 'em.
<doko> can't find any email about the rejection of binutils 2.24-5ubuntu14 for trusty. can I re-read the reason ?
#ubuntu-release 2015-09-16
<micahg> utlemming: we're working on getting some more help for backports
<flexiondotorg> Laney, if you have a sec I'd like to discuss some package updates that I've been asked to seek UI freeze exceptions for.
<sil2100> Quick heads up - I'm disabling the system-image importer for a short moment
<sil2100> It's back up if anything
<flexiondotorg> Laney, can I request a moment of your time please?
<Laney> flexiondotorg: One second please
<flexiondotorg> Sure
<Riddell> bug 1488843 could do with going into vivid-updates if someone has the powers for that
<ubot93> bug 1488843 in ubuntu-release-upgrader (Ubuntu Vivid) "SRU: upgrader kde frontend fails to start" [Critical,Fix committed] https://launchpad.net/bugs/1488843
<Laney> flexiondotorg: At your service
<flexiondotorg> Cheers
<flexiondotorg> I got some updated that require UI exemptions.
<flexiondotorg> Can you take a look and potentially sign off?
<flexiondotorg> First up is - https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1493274
<ubot93> Launchpad bug 1493274 in ubuntu-mate-welcome (Ubuntu) "ubuntu-mate-welcome 1.0.3.2 update [debdiff attached]" [Undecided,New]
<flexiondotorg> Ubuntu MATE Welcome is not currently translated. I'll be opening that up in 16.04.
<flexiondotorg> I did submit these before the UI freeze in an effort to dodge UI expemtions.
<Laney> flexiondotorg: does the ubuntu docs team do anything with ubuntu mate?
<flexiondotorg> No.
<Laney> flexiondotorg: OK, I think it's fine then if you're not invalidating the work of anyone else
<flexiondotorg> Thanks. Can you ack that bug please?
<flexiondotorg> I have one other to discuss as well.
<Laney> I did
<flexiondotorg> Thanks.
<Laney> I just commented on plank if it's that one
<flexiondotorg> Well, I want that too. But here is the other.
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1493065
<ubot93> Launchpad bug 1493065 in ubuntu-mate-artwork (Ubuntu) "ubuntu-mate-artwork 15.10.3 new release [debdiff attached]" [Undecided,New]
<flexiondotorg> Minor change.
<Laney> k
<Laney> You know the release team isn't subscribed to this
<Laney> so we wouldn't have seen it
<flexiondotorg> Yeah, I wasn't sure when/if I shouild subscribe the release-team.
<Laney> It would be preferable to do this that way instead of synchronously on IRC
<flexiondotorg> OK, understood. Will do in future.
<darkxst> Laney, probably a TB Question, but I have been wondering if UiFe for flavour specific stuff, couldnt be delegated to the relevant flavour team leads
<darkxst> s/couldnt/could/
<Laney> darkxst: Perhaps. You probably want to keep a way of avoiding messing up the work of people working on documenting and translating things, but maybe the main RT doesn't have to be involved for flavours.
<Laney> darkxst: Bring it up on ubuntu-release@ if you want to talk about a change
<flexiondotorg> Laney, Can you just cast a quick eye over https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1493034
<ubot93> Launchpad bug 1493034 in ubuntu-mate-settings (Ubuntu) "ubuntu-mate-settings 15.10.2 bugfix release [debdiff attached]" [Undecided,New]
<flexiondotorg> I don't think it needs an UI or FF exemption.
<darkxst> Laney, ok, will do
<Laney> flexiondotorg: It probably does since you're changing the scrollbars
<flexiondotorg> Laney, Understood.
<flexiondotorg> It is OK?
<Laney> Sure
<flexiondotorg> Basically, they are alway displayed now.
<flexiondotorg> Laney, thanks for helping. I'll sub the RT in future for such exemptions.
<flexiondotorg> I'd like those update in the next beta so I can focus on bug hunting after that.
<flexiondotorg> Laney, do you require any flavour assistance for the next bet?
<flexiondotorg> *beta?
<tjaalton> infinity: so, new mesa-lts-vivid adds renamed libosmesa6* packages, but it doesn't solve installability of the libosmesa6 library, because all the reverse deps are versioned, and Provides isn't
<sil2100> Hey guys! Is there any archive admin around to help us out with a review of a CI Train landing that introduces new binary packages (soname bump)? The packaging has been already reviewed by kenvandine, but we still need the archive admin approval:
<sil2100> https://ci-train.ubuntu.com/job/ubuntu-landing-010-2-publish/80/artifact/unity-scopes-api_packaging_changes.diff <- the packaging diff
<sil2100> Thanks o/
<infinity> tjaalton: I don't have any context there.  What was the bug you were trying to fix?
<tjaalton> infinity: well it's part of bug 1424466, but an internal request to allow installing libosmesa6's rdeps
<ubot93> bug 1424466 in apt (Ubuntu Trusty) "Devel package not installable in 14.04.2 (mesa-lts-utopic" [Undecided,Confirmed] https://launchpad.net/bugs/1424466
<tjaalton> there's only one way to fix it in trusty that I can see, which is to build osmesa separately like on precise, and starting from w+1 rely on versioned Provides
<tjaalton> mesa upstream no longer has machinery for static builds
<tjaalton> uh no, it's bug 1424059
<ubot93> bug 1424059 in mesa-lts-utopic (Ubuntu) "libosmesa6 conflicts with libglapi-mesa-lts-utopic" [Undecided,Confirmed] https://launchpad.net/bugs/1424059
<jamespage> doko, ^^ those two :-) pretty please :)
<doko> jamespage, python-magnumclient accepted. for a MIR approval please check to run the testsuite for python3 as well
<jamespage> doko, ack will do
<doko> for debian acceptance, ... there are a lot of copyright holders missing in debian/copyright
<doko> jamespage, castellan looks ok, runs the tests for all versions
<jamespage> doko, thanks for the NEW processing - much appreciated...
<bdmurray> slangasek: I think bug 1258639 mostly covers the same case we were talking about the other day regarding upgrading from T to V.
<ubot93> bug 1258639 in ubuntu-release-upgrader (Ubuntu Saucy) "need to support upgrades from 12.10 to 13.10" [High,Fix released] https://launchpad.net/bugs/1258639
<slangasek> bdmurray: looks like it, yes
<bdmurray> I'll see if similar changes work for upgrading from T to V then.
#ubuntu-release 2015-09-17
<mwhudson> argh can someone tell me why gccgo-go_1.2.1-0ubuntu4 was rejected from trusty?
<mwhudson> oh no, wait a minute
<tjaalton> is it possible to drop a package from -proposed which added new packages (mesa-lts-vivid), or should I make a new upload?
<ogra_> can anyone explain to me what /srv/cdimage.ubuntu.com/www.prev/simple/vivid  is exactly for ? ( infinity, cjwatson, slangasek ?) ... the snappy release instructions tell me to copy the images there (bfore they tell me to copy them into the actual folders for release.u.c and cdimage.u.c/releases/ )
<Laney> insurance
<ogra_> looks to me like a preview folder, but given i copy the same images into the release channels immediately after that seems strange
<Laney> in case you mess up
<ogra_> ah, thanks !
<Laney> use cp -l so you don't actually create multiple copies
<Laney> if the instructions don't say that already
<ogra_> Then push the images to /srv/cdimage.ubuntu.com/www.prev/simple/vivid (updating MD5SUMS, SHA1SUMS and SHA256SUMS).
<ogra_> thats all i have :P
<ogra_> hmpf
<ogra_> Laney, just to be sure: /srv/cdimage.ubuntu.com/bin/checksum-directory /srv/cdimage.ubuntu.com/www.prev/simple/vivid/
<ogra_> is the right thing to update the checksums ?
<ogra_> oh, i see a metalink file so probably rather /srv/cdimage.ubuntu.com/bin/checksum-directory --metalink /srv/cdimage.ubuntu.com/www.prev/simple/vivid/
 * ogra_ tries that 
<ogra_> ah, no snappy in the metalink file ... good that i checked :P
<cjwatson> ogra_: wat
<cjwatson> ogra_: nothing should ever be copied *to* www.prev
<ogra_> oh
<cjwatson> your instructions are deluded
<ogra_> sorry then
<cjwatson> www.prev is a backup
<cjwatson> manually created, of the state before a given publishing attempt
<cjwatson> can I see your instructions please?
<ogra_> well, does it do any harm that i did cope tzhem there now ?
<ogra_> *copy
<ogra_> https://trello.com/c/PUpWXouz/89-stable-release-checkpoints
<cjwatson> no, but www.prev may have rm -rf run on it at any time
<ogra_> well, i didnt really get why i shold copy them there at all
<cjwatson> you shouldn't
<ogra_> thats why i asked
<ogra_> but wont do any harm either and i dont care if they get deleted
<ogra_> just wasted some time
<cjwatson> right, just delete .prev from that
<ogra_> if you look at the checklist at the last checkmark thats weird too i think
<cjwatson> no that looks fine
<ogra_> not really sure why we release in two places there
<cjwatson> the checklist duplicates some bits of the prose above
<cjwatson> I don't think you're meant to execute everything in prose and then execute the checklist
<cjwatson> that wouldn't make sense, since the checklist starts with creating a milestone
<ogra_> a bug milestone ...
<cjwatson> whatever
<ogra_> anyway, doing the last bit now, thanks for chiming in
<cjwatson> anyway, .../www/simple/15.04 is a symlink to vivid, so those are identical
<cjwatson> and yes, checksum-directory is the correct tool to use to update checksums
<ogra_> oh, do i need --metalink for the official dirs ?
<cjwatson> please make sure the checklist says that since otherwise people try to edit stuff by hand or something
<cjwatson> no
<ogra_> thx
<cjwatson> you aren't releasing anything that involves metalinks
<cjwatson> if you're copying from a directory that already has checksums, you can make checksum-directory faster by telling it that old directory
<cjwatson> don't know if you are or not
<ogra_> nope
<ogra_> and i like then to be generated by the right tool
<ogra_> *them
<cjwatson> sure, it's just if cdimage was already responsible for generating earlier versions
<ogra_> well, the img.xz files get generated on someones desktop and scp'ed over
<flexiondotorg> cyphermox, Can I request some sponsoring please?
<flexiondotorg> cyphermox, I have the required UI exemptions now.
<cyphermox> flexiondotorg: sure, but give me a moment, I'm finishing up juggling some usb-creator drama
<flexiondotorg> cyphermox, Hah. Been watching the email from the ML roll in :-)
<flexiondotorg> cyphermox, Here come the bug references.
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1493065
<ubot93> Launchpad bug 1493065 in ubuntu-mate-artwork (Ubuntu) "ubuntu-mate-artwork 15.10.3 new release [debdiff attached]" [High,Triaged]
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1493274
<ubot93> Launchpad bug 1493274 in ubuntu-mate-welcome (Ubuntu) "ubuntu-mate-welcome 1.0.3.2 update [debdiff attached]" [High,Triaged]
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1493034
<ubot93> Launchpad bug 1493034 in ubuntu-mate-settings (Ubuntu) "ubuntu-mate-settings 15.10.2 bugfix release [debdiff attached]" [Undecided,New]
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/python-caja/+bug/1496925
<ubot93> Launchpad bug 1496925 in python-caja (Ubuntu) "Sync python-caja 1.10.0-2 (universe) from Debian unstable (main)" [Undecided,New]
<flexiondotorg> Posting them now because it's nearly time for me to read bedtime stories to my daughter ;-)
#ubuntu-release 2015-09-18
<tjaalton> infinity: still around? could you remove mesa-lts-vivid from trusty-proposed, or should I upload a revert? mesa in the trusty queue is the proper fix for bug 1424059
<ubot93> bug 1424059 in mesa (Ubuntu Trusty) "libosmesa6 conflicts with libglapi-mesa-lts-*" [High,In progress] https://launchpad.net/bugs/1424059
<infinity> tjaalton: I can remove it.
<tjaalton> cool
<flexiondotorg> cyphermox, Thank you very much for sponsoring last night.
<flexiondotorg> cyphermox, Sorry I'd messed up ubuntu-mate-settings, I really appreciate that you correct my mistake.
<sil2100> seb128: hey! Maybe you could take a look and give a +1 to a bunch of new binary packages introduced by a train landing? :) The packaging changes themselves have already been signed off by Ken
<sil2100> seb128: https://ci-train.ubuntu.com/job/ubuntu-landing-010-2-publish/80/
<sil2100> seb128: it's a big diff... and it has a lot of fancy stuff in it
<seb128> sil2100, hey, I guess I could, why do you use that channel rather than normal dev ones? I saw your ping the other day but I assumed you specifically wanted somebody from the release team for those
<sil2100> seb128: it's basically a soname bump + the script to generate wily and vivid packages from one source
<sil2100> seb128: yeah, might not be the right place indeed, I always think archive-admin stuff is closely related to release ;p
<seb128> it's not ;-)
<knome> hello release team, i thought i'd ask here for a potential fast ack before filing a bug
<knome> so - we need an upload for the xubuntu docs, including some string changes (freeze yesterday) - it's only affecting us and we'd like to avoid paperwork - anybody can ack this live? :)
<knome> lunch time now - i'll be back later :)
<pitti> knome: seems fine to me, but please notify the translator ML (if you didn't yet)
<knome> pitti, i won't, because those strings aren't translatable (yet) - but sure, we'll take care of things we need to, as always :)
<knome> actually nvm, i misspoke, so i'll just send a mail :P
<knome> actually nvm the nvm, we're translating upstream, not the package, so the strings have been translatable for a while already
 * knome facepalms and backs off
<bluesabre> knome: stop picking on pitti :P
<knome> :)
<knome> thanks bluesabre for the upload!
#ubuntu-release 2015-09-19
<flocculant> texlive-lang-chinese apparently has us in Task
<flocculant> oh boo - wrong channel :)
#ubuntu-release 2015-09-20
<bluesabre> Release team, please review https://bugs.launchpad.net/ubuntu/+source/shimmer-themes/+bug/1497228 and https://bugs.launchpad.net/ubuntu/+source/xfpanel-switch/+bug/1497753
<ubot93> Launchpad bug 1497228 in shimmer-themes (Ubuntu) "[UIFe] shimmer-themes 2.0.2" [Undecided,New]
<ubot93> Launchpad bug 1497753 in xfpanel-switch (Ubuntu) "[FFe] xfpanel-switch 1.0.2" [Undecided,New]
#ubuntu-release 2016-09-19
<slangasek> doko: was there an FFe for this readline soname transition?
<pitti> tsimonq2: I don't have an explicit dependency list of britney2, but ImportErrors should hopefully make it clear enough?
<pitti> tsimonq2: https://wiki.ubuntu.com/ProposedMigration/LocalSetup documents the setup otherwise
-queuebot:#ubuntu-release- New sync: libsquish (yakkety-proposed/primary) [1.13-2]
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.15 => 2.15.1] (desktop-core, ubuntu-server)
<handsome_feng> Hi, Good Monring everyone! Can anybody help me to upload my new package to archive ? I have file a bug in launchpad:  https://bugs.launchpad.net/ubuntukylin/+bug/1609207 Thank you in advance!
<ubot5`> Ubuntu bug 1609207 in Ubuntu Kylin "[needs-packaging] ubuntu-kylin-wizard" [High,Triaged]
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.15 => 2.15.2] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.15.1]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.15.2]
<handsome_feng> seb128: Hi, Seb,I'm the member of Ubuntu Kylin, Can you help me to upload my wizard package to archive ? I have file a bug in Launchpad: https://bugs.launchpad.net/ubuntukylin/+bug/1609207 Thank you !  :)
<ubot5`> Ubuntu bug 1609207 in Ubuntu Kylin "[needs-packaging] ubuntu-kylin-wizard" [High,Triaged]
<seb128> handsome_feng, hey, sorry but I'm quite busy, maybe try with the patch pilot from the day or using ubuntu sponsors?
<handsome_feng> seb128: Ok, I will try that, thank you all the same !!
-queuebot:#ubuntu-release- Packageset: Added mythes-it to personal-gunnarhj in yakkety
-queuebot:#ubuntu-release- Packageset: Added mythes-sv to personal-gunnarhj in yakkety
<seb128> handsome_feng, no worry, good luck finding a sponsor
-queuebot:#ubuntu-release- New binary: appstream [ppc64el] (yakkety-proposed/main) [0.10.1-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: appstream [amd64] (yakkety-proposed/main) [0.10.1-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: appstream [i386] (yakkety-proposed/main) [0.10.1-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: appstream [arm64] (yakkety-proposed/main) [0.10.1-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: appstream [armhf] (yakkety-proposed/main) [0.10.1-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Packageset: 266 entries have been added or removed
-queuebot:#ubuntu-release- New binary: appstream [s390x] (yakkety-proposed/main) [0.10.1-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: appstream [powerpc] (yakkety-proposed/main) [0.10.1-1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Packageset: Added accountsservice to personal-gunnarhj in yakkety
-queuebot:#ubuntu-release- Packageset: Added language-selector to personal-gunnarhj in yakkety
-queuebot:#ubuntu-release- Packageset: Added libreoffice-dictionaries to personal-gunnarhj in yakkety
-queuebot:#ubuntu-release- Packageset: Added openoffice.org-hyphenation to personal-gunnarhj in yakkety
-queuebot:#ubuntu-release- Packageset: Added ubuntu-docs to personal-gunnarhj in yakkety
-queuebot:#ubuntu-release- New sync: miral (yakkety-proposed/primary) [0.1.0+16.10.20160919-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted miral [sync] (yakkety-proposed) [0.1.0+16.10.20160919-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted appstream [amd64] (yakkety-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted appstream [armhf] (yakkety-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted appstream [powerpc] (yakkety-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted appstream [s390x] (yakkety-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted appstream [arm64] (yakkety-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted appstream [ppc64el] (yakkety-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted appstream [i386] (yakkety-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted libsquish [sync] (yakkety-proposed) [1.13-2]
-queuebot:#ubuntu-release- New binary: libsquish [ppc64el] (yakkety-proposed/none) [1.13-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libsquish [amd64] (yakkety-proposed/none) [1.13-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libsquish [i386] (yakkety-proposed/none) [1.13-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted libsquish [amd64] (yakkety-proposed) [1.13-2]
-queuebot:#ubuntu-release- New: accepted libsquish [ppc64el] (yakkety-proposed) [1.13-2]
-queuebot:#ubuntu-release- New: accepted libsquish [i386] (yakkety-proposed) [1.13-2]
-queuebot:#ubuntu-release- New binary: libsquish [arm64] (yakkety-proposed/none) [1.13-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libsquish [armhf] (yakkety-proposed/none) [1.13-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted libsquish [arm64] (yakkety-proposed) [1.13-2]
-queuebot:#ubuntu-release- New: accepted libsquish [armhf] (yakkety-proposed) [1.13-2]
-queuebot:#ubuntu-release- New binary: libsquish [s390x] (yakkety-proposed/none) [1.13-2] (no packageset)
-queuebot:#ubuntu-release- New binary: libsquish [powerpc] (yakkety-proposed/none) [1.13-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted libsquish [powerpc] (yakkety-proposed) [1.13-2]
-queuebot:#ubuntu-release- New: accepted libsquish [s390x] (yakkety-proposed) [1.13-2]
-queuebot:#ubuntu-release- Unapproved: backuppc (xenial-proposed/main) [3.3.1-2ubuntu3 => 3.3.1-2ubuntu3.1] (core)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-11.12] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-11.12]
<doko> slangasek: why do you promote geoclue, while it still recommends iio-sensors-proxy? http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<slangasek> doko: why would I not?
<slangasek> what does it help to have two levels of packages on the component-mismatches graph instead of one?
<doko> slangasek: because the MIR team usually only promotes complete package sets
<slangasek> the MIR team does not promote anything, the archive admins do
<doko> well, I don't see any value with this promotion
<slangasek> it reduces the noise on the component-mismatches report
<doko> just encourages the involved parties to further ignore the outstanding issue
<doko> plus you wouldn't do that in the first place if it would be a dependency, but not a recommendation
<slangasek> wouldn't do what in the first place?
<slangasek> I'm not concerned about people 'ignoring' the outstanding issue as a result of the promotion being done
<slangasek> OTOH, I am noticing now that this MIR was marked 'fix committed' but I can't make out who the bug subscriber is for geoclue-2.0
<slangasek> doko: so maybe the MIR team would like to sort that part out, so that it's clear who's *responsible* for fixing the outstanding issue ;)
<tsimonq2> pitti: figured it out, thanks though :)
#ubuntu-release 2016-09-20
<Mirv> slangasek: hmm so qt3d-opensource-src got removed completely from Ubuntu because it was moved to experimental in Debian? and so did qt3d-opensource-src-gles, but that one you reuploaded?
<Mirv> I'm not sure what was on purpose and what not. regardless, we are planning to make Qt3D 5.6 available to app developers, similar to our snapshot git releases of qtpim, qtsystems and qtfeedback that have been included on the phones and tablets from the beginning.
-queuebot:#ubuntu-release- Unapproved: qemu (xenial-proposed/main) [1:2.5+dfsg-5ubuntu10.4 => 1:2.5+dfsg-5ubuntu10.5] (ubuntu-server, virt)
<xnox> what is the URL for the backup seed-in-ubuntu instance?
<apw> xnox, they are listed here: http://ubuntuqa.tblwd.org/
<Laney> shall we move those over to snakefruit or something?
<handsome_feng> Hi, Laney, Sorry to trouble you. Could you please help me to upload my new wizard package ? I have file a bug in launchpad: https://bugs.launchpad.net/ubuntukylin/+bug/1609207
<ubot5`> Ubuntu bug 1609207 in Ubuntu Kylin "[needs-packaging] ubuntu-kylin-wizard" [High,Triaged]
<Laney> bleh, he went
<apw> yeah that is somewhat annoying
-queuebot:#ubuntu-release- Unapproved: davical (xenial-proposed/universe) [1.1.4-1ubuntu1 => 1.1.4-1ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: awstats (xenial-proposed/main) [7.4+dfsg-1 => 7.4+dfsg-1ubuntu0.1] (ubuntu-server)
<Laney> trying: appstream isenkram appstream-generator limba
<Laney> did britney always do this?
<Laney> put transitions in without (auto) hinting them
<smb> I would highly appreciate if someone on the release team could look at bug 1621618 and in case there is still something missing, let me know.
<ubot5`> bug 1621618 in xen (Ubuntu) "[FFE Yakkety] Upgrade to Xen 4.7" [High,In progress] https://launchpad.net/bugs/1621618
<Trevinho> bdmurray: I'm continuosly receiving email about possible regressions in libunity... Which are not. I don't know why, but these issues were mostly caused by vala itself. But still nothing new
<slangasek> Mirv: I didn't remove qt3d-opensource-src-gles, I demoted it to -proposed
<Mirv> slangasek: and what about qt3d-opensource-src?
<slangasek> Mirv: since it's Ubuntu-specific, I felt it was better to keep it around in -proposed for reference than to remove it completely.  But qt3d-opensource-src, I removed because Debian says it's not stable yet; why would you want to give this to app developers via 16.10?
<Mirv> slangasek: the similar way we provide nonstable qtpim, qtfeedback and qtsystems in our products - developers want it, it's available. by not stable means API is not stable, but qt3d has seen multiple releases unlike those other three modules which we have only git snapshots for and still use them.
<Mirv> but qt3d is not necessary either, but there is a lot of interest towards it
<Mirv> we've been shipping it in Ubuntu since 2014, so removing it at this point is a bit weird
<Mirv> correction, January 2013
<slangasek> Mirv: if you wanted to reintroduce the package to yakkety (reupload, or copy-package), I wouldn't block it, but it doesn't seem like a good idea to me
<Mirv> slangasek: I don't need it for anything, but people have wanted to play around with it for years now. I just don't get why remove it now after 3.5 years, when it's pretty usable and stable (even if technolgoy preview), but I see there can be multiple points of view.
<Mirv> bzoltan: ^ if you have opinion on removing or keeping qt3d from Ubuntu
<slangasek> Mirv: removed because we track removals from Debian; but it's not an absolute
<slangasek> if it's clear that the package is being used in Ubuntu we won't remove without discussion
<slangasek> this one is not seeded, had no reverse-depends aside from the gles variant
<Mirv> right, they started shipping it 2.5 years after us, when upstream released the first (preview) version. we were shipping the version 1 and now later this rewrite of it.
<Mirv> anyway, it will be back latest for 17.04 with Qt 5.7 where it's no longer called a preview
<Mirv> it used to be part of ubuntu-sdk-libs-dev dependencies but now that package was removed from yakkety so indeed no reverse dependencies
<slangasek> Mirv: so should we pull the package back in?
<Mirv> slangasek: I think it'd be nice, but not mandatory. it's for playing around, and as it was part of ubuntu-sdk-libs-dev lots of 16.04 users have it installed.
<Mirv> anyway, I need to go now
<slangasek> Mirv: copied back in; hopefully this worked right, copy-package gave me no output about binaries being included
-queuebot:#ubuntu-release- Unapproved: python-pylxd (xenial-proposed/main) [2.0.0-0ubuntu1 => 2.0.5-0ubuntu1] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ntp (xenial-proposed/main) [1:4.2.8p4+dfsg-3ubuntu5.1 => 1:4.2.8p4+dfsg-3ubuntu5.2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected python-pylxd [source] (xenial-proposed) [2.0.5-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: python-pylxd (xenial-proposed/main) [2.0.0-0ubuntu1 => 2.0.5-0ubuntu1] (ubuntu-server)
<bzoltan> slangasek:  the qt3d was collecting dust for some time, but since KDAB started to invest in it and started to maintain it for real it has improved and now it is a first class citizen of the Qt modules. It is good that we include it in our offering.
<wxl> is beta 2 not going up today?
<wxl> infinity: i guess you're in charge of beta 2? what's the word?
 * rbasak wasn't aware of a freeze
<Laney> Beta 2's on the schedule for this week
<Laney> Usually coincides with freezage
<wxl> Laney: it's on the schedule to *release* this week
<wxl> on the 22nd for that matter
-queuebot:#ubuntu-release- Unapproved: kbd (xenial-proposed/main) [1.15.5-1ubuntu4 => 1.15.5-1ubuntu5] (core)
<infinity> wxl: RCs and freezing and such will happen soonish.  We've been trying to squeeze a kernel in under the wire.
<wxl> infinity: works for me. thx!
<infinity> apw: ^ what's the status on that?
<acheronuk> so in reality actual beta freeze is in advance of the date here? https://wiki.ubuntu.com/YakketyYak/ReleaseSchedule
<infinity> acheronuk: The freeze obviously has to happen before the release, the schedule just seems to be missing the usual (Mon) or (Tue) to indicate that the freeze isn't on Thursday.  Oops.
<apw> infinity, the kernel in the pocket is pretty close, we're missing a couple of patches which really ought to go in, but not in "iso affecting" paths
<infinity> apw: If it won't affect boot, install, or dkms, I think we're safe.
<acheronuk> infinity: I did wonder. Thanks
<apw> i believe not, there is an esoteric networking issue, and some overlayfs in userns bits needing wiggling
<infinity> apw: Kay.  Odds of said wiggling happening by EOW, so we can just slip an update in right after beta?
<apw> for sure that, oh but hang on ... xnox reported a udeb issue with crypto ...
<apw> xnox, what was the scope of the failure there ...
<apw> we can cirtainly have a "day 0" kernel for thursday/friday, but we need to circle on xnox's issue i guess
<infinity> *nod*
<apw> a crypto module missing in udebs ...
-queuebot:#ubuntu-release- Unapproved: klibc (trusty-proposed/main) [2.0.3-0ubuntu1.14.04.1 => 2.0.3-0ubuntu1.14.04.2] (core)
<artmello> hey guys. we have a silo for gallery that is failling the automated signoff with a missing deps in s390x for yakkety: https://requests.ci-train.ubuntu.com/#/ticket/1819
<artmello> this seems to be related with missing upstart there. someone can help me to get gallery build removed from s390x/yakkety? so we can have this silo approved
-queuebot:#ubuntu-release- Unapproved: klibc (xenial-proposed/main) [2.0.4-8ubuntu1.16.04.1 => 2.0.4-8ubuntu1.16.04.2] (core)
<infinity> artmello: I'm not familiar with that UI so much, but where does it say *why* the automated signoff failed?
<infinity> Oh.
<infinity> britney.
-queuebot:#ubuntu-release- Unapproved: golang-petname (xenial-proposed/main) [2.3-0ubuntu1~16.04 => 2.4-0ubuntu1~16.04] (kubuntu, ubuntu-desktop)
<artmello> infinity: on the Automated Test Results you have the excuses files
<artmello> infinity: this is the one for yakkety https://requests.ci-train.ubuntu.com/static/britney/landing-088/yakkety/excuses.html
<infinity> artmello: Right.  So, that was removed from yakkety, and it probably shouldn't be built on arches that don't have upstart.
<infinity> artmello: An artificial build-dep on upstart would "fix" that.
<slangasek> correct
<slangasek> artmello: so this needs to be fixed in the landing, it's not something the archive team can fix
<artmello> slangasek: right, I think some similar fix was done by ubuntu-system-settings. is that correct kenvandine?
<kenvandine> content-hub
<kenvandine> we had a direct depends on upstart i think
<infinity> Would have to be a build-dep, not a dep, if the goal is to not build it.
<kenvandine> true, it was actually a build dep on ubuntu-app-launch
<kenvandine> gallery-app has a depends on content-hub which is no longer building on s390x
<infinity> Can we just remove upstart usage from that stack instead? :P
<kenvandine> ok, so i guess just add the build dep
<kenvandine> infinity, that would be pretty significant ;)
<infinity> kenvandine: Yup, but we're also not maintaining upstart, so... Whee.
<kenvandine> indeed
<infinity> (And it's not like we haven't had warning of this since about vivid)
<kenvandine> yeah, ubuntu-app-launch basically wraps upstart
<kenvandine> but i'm sure tedg has a plan :)
<kenvandine> world domination, if nothing else
<artmello> ok, so should I add the build dep to gallery-app?
<infinity> My plan is to stare whistfully out the window at the dreary, rainy afternoon sky, and will a hamburger to come to me, since I don't feel like going out there to go to the hamburger.
<infinity> artmello: Yup.
<wxl> sudo apt -y install hamburger
 * kenvandine wants a hamburger now
<artmello> infinity: thx
<infinity> I guess I could be one of "those people" who drives his car two blocks for lunch.
<wxl> i installed the lunch package which depends on the main-course virtual package, which tacos provides as well as hamburger
<infinity> It cancels out if I scowl at myself in the rearview mirror and judge myself, right?
<wxl> tacos were a good choice
<wxl> infinity: don't you have one of those delivery service things?
<infinity> I'm frugal.  (read: cheap)
<wxl> infinity: well, then you shouldn't drive.
<infinity> Driving two blocks is a lot cheaper than paying someone to do the same. :)
<slangasek> he lives in Calgary, he pretty much just wipes a rag on the ground and squeezes it into his tank to gas up
<wxl> not when you consider all the factors involved, such as the affect on long term maintainence, insurance costs, etc.
<wxl> and the cost on health
<wxl> more likely to get injured in a car than just about anything else
<wxl> for that matter, if you were so frugal, you'd get rid of the car altogether
<infinity> slangasek: I don't know where you're hearing your rumours, but I assure you, we're far classier than that.  I get my gas out of the kitchen faucet.
<infinity> wxl: I don't like in a city where being carless is practical.  I drive rarely.
<infinity> s/like/live/
<wxl> bah. it's not like you live in America :)
<infinity> North America...
<wxl> oh, so Canada, US, same-same?
<infinity> And my part is less densely populated than their part. :P
<infinity> Basically the same from that POV, yeah.  North Americans view distance much differently from Europeans.
<infinity> In that we have a lot of it.  With nothing in the middle.
<infinity> But also, the rain stopped, so I can stop with this debate, and walk to my burger.
<wxl> Well, to me, Canada seems *a bit* more with it.
<wxl> Good luck :)
<infinity> wxl: As a people, we're likely slightly more environmentally-conscious (slightly), but the layout of the country as a whole, and some cities specifically mean we still can't be Europe. :P
<infinity> wxl: I live in a very walkable neighbourhood, and prefer not to drive when I don't have to, but I still pretty much have to own a car to get some things done, or waste years of my life on awful public transit because *good* public transit requires either (a) a densely-populated area or (b) trillions in infrastructure spending to make your sparsely-populated areas connect, and we've got neither.
<infinity> wxl: To put it in perspective a bit, I live in a city with an eigth of the population of London, but more than twice the area.
<infinity> wxl: And the next nearest city worth mentioning is 300km away.
 * infinity burgers now.
<flocculant> is that like frying tonight?
 * tsimonq2 wonders if infinity picked up on the fact that wxl works for a bike company and dislikes cars :P
<wxl> tsimonq2: to be fair, we live in a car-centric world here in North America. thinking outside that box is something we rarely do.
<tsimonq2> I agree
<tsimonq2> but to be fair, you live in Oregon, where puming your own gas is illegal :P
<tsimonq2> *pumping
<wxl> not sure that's relevant, but ok.
<tsimonq2> well I've heard that in Portland, bikes are used just as much as cars, if not more
<nacc> portland's traffic doesn't seem to indicate that is really true, but it's what people like to say here
<wxl> it's not really true
<wxl> bike use is ever increasing in portland, which has some of the hightest bike use
<wxl> but the car traffic there is truly deplorable
<wxl> i.e. for all the improvement, it's still far behind
 * nacc lives in portland, and can only agree
<nacc> and i don't even commute anywhere! :)
 * wxl used to live there and left because of that fact!
<nacc> heh
<wxl> tsimonq2: btw here's why the oregon legislature has decided to disallow self-service fueling http://www.oregonlaws.org/ors/480.315
<slangasek> on paper anyway
<wxl> yeah
<wxl> this one goes into a little more history https://www.quora.com/Why-does-Oregon-have-attendants-at-gas-stations/answer/Rick-Hamell#
<xnox> apw, infinity - my crypto modules missing in udebs results in not able to mount ext4 which means cannot smash continue repeatedly to finish installation, on s390x.
<xnox> where smashing enter is actually ".\n" SCLP SEND
<xnox> s390x only as far as I understand.
<xnox> sorry, i was out for volleyball
-queuebot:#ubuntu-release- Unapproved: accepted golang-petname [source] (xenial-proposed) [2.4-0ubuntu1~16.04]
<xnox> bug 1625728
<ubot5`> bug 1625728 in linux (Ubuntu Yakkety) "fails to mount ext4 due to missing crypto-crc32 modules in the udeb" [Critical,Fix committed] https://launchpad.net/bugs/1625728
<tsimonq2> infinity: when you get a moment, please take a look at the email just sent to ubuntu-release@l.u.c
#ubuntu-release 2016-09-21
-queuebot:#ubuntu-release- Unapproved: snap-confine (xenial-proposed/main) [1.0.38-0ubuntu0.16.04.10 => 1.0.41-0ubuntu2~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New sync: gnome-2048 (yakkety-proposed/primary) [3.22.0-1]
<flocculant> infinity: Xubuntu have an issue with coming back from suspend - it appears to unlock, but then we're stuck with a blank screen and seemingly only way is to stop and start lightdm, we will not be releasing Final Beta in that state (unlikely anything to fix it will happen in a day and a bit) bug 1622303
<ubot5`> bug 1622303 in light-locker (Ubuntu) "Fails to unlock/ resume to black screen" [Undecided,Confirmed] https://launchpad.net/bugs/1622303
<flocculant> s/suspend/suspend or lock
<sil2100> slangasek: thanks for the zeromq3 changes! Will forward them to the snapshot part and then upstream, as you said
-queuebot:#ubuntu-release- New source: wine (yakkety-proposed/primary) [1.8.4-1ubuntu1]
-queuebot:#ubuntu-release- New binary: plasma-discover [amd64] (yakkety-proposed/universe) [5.7.5-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Yakkety Beta 2] (20160921) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate powerpc [Yakkety Beta 2] (20160921) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Yakkety Beta 2] (20160921) has been added
<infinity> flocculant: I'd like you to participate in the Beta all the same.  Maybe we can get it fixed in time, maybe not, but the more testing you can do, even if you don't release with the milestone, the better shape we'll be in to figure out how to move forward for release.
-queuebot:#ubuntu-release- Unapproved: dovecot (xenial-proposed/main) [1:2.2.22-1ubuntu2 => 1:2.2.22-1ubuntu2.1] (ubuntu-server)
<seb128> hum
<seb128> https://wiki.ubuntu.com/YakketyYak/ReleaseSchedule was listing beta freeze for the 22th
<seb128> that's tomorrow not today
-queuebot:#ubuntu-release- Unapproved: gnat (yakkety-proposed/universe) [6.1ubuntu1 => 6.1ubuntu2] (no packageset)
<infinity> seb128: Beta is the 22nd, freeze is before.
<seb128> the wiki table is confusing then
<infinity> seb128: It probably should have had a (Tues) on it.
<seb128> yeah
<infinity> The wiki table is indeed confusing.
<infinity> Anyhow, we have yet another kernel (and, thus, a respin) coming, so if you had something that should make the ISOs, you're probably in luck.
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Yakkety Beta 2] (20160921) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Yakkety Beta 2] (20160921) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Yakkety Beta 2] (20160921) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Yakkety Beta 2] (20160921) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Yakkety Beta 2] (20160921) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Yakkety Beta 2] (20160921) has been added
<seb128> the unity8 session? ;-)
<seb128> there are still MIRs behing reviewed so that's probably for after beta now...
<seb128> which is a bit crazy
<infinity> seb128: Well, it's not the default session, so it's not as crazy as it could be. :P
<seb128> that's a good way to look at it ;-)
<Laney> [FFe] Switch default session to Unity 8 for 16.10
<Laney> Oops, meant to type that into Launchpad.
<infinity> Laney: DENIED.
-queuebot:#ubuntu-release- Unapproved: accepted gnat [source] (yakkety-proposed) [6.1ubuntu2]
<shadeslayer> infinity: yeah table is indeed confusing, I thought the freeze was tomorrow and uploaded Plasma 5.7.5
<shadeslayer> so I think Kubuntu will probably require a respin too
-queuebot:#ubuntu-release- Unapproved: apt (yakkety-proposed/main) [1.3~rc4ubuntu1 => 1.3] (core) (sync)
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Yakkety Beta 2] (20160921) has been added
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Yakkety Beta 2] (20160921) has been added
<davmor2> infinity: oh you're about did you move or do you just not sleep?
<Laney> Well
<Laney> laney@snakefruit:~$ /home/ubuntu-archive/bin/chdist apt-cache yakkety-proposed-amd64 show unity8-desktop-session | grep-dctrl -s Package,Task .
<apw> davmor2, he is in and out i think
<Laney> Package: unity8-desktop-session
<Laney> Task: ubuntu-desktop, ubuntu-usb, edubuntu-desktop, edubuntu-usb
<Laney> That wasn't supposed to happen
<Laney> seb128: ^- I think that it needs to be undone
<davmor2> infinity: can you add netboot when you are in again please to the final beta I'll hit it now and mark it up after.
<seb128> Laney, it's only a recommends is that going to create any issue?
<infinity> davmor2: There'll be a new netboot sometime later today.  Better to focus your current testing on ISOs, if you could, since they usually require more pain to fix when you find bugs. :P
<Laney> it's going to try to install everything with Task: ubuntu-desktop
<seb128> did we do the change wrong or why is that an issue?
<seb128> Steve said we should do that and it shouldn't create problems for the iso build
<Laney> I thought it would be ignored for task generation but it's not
<infinity> Of course it's not ignored for task generation.
<infinity> But what's the intent here?
<davmor2> infinity: like I'm going to find bugs, I'll see if hardware detection is working today or not ;)
<Laney> Why is it of course?
<Laney> To get component-mismatches to show the state
<Laney> But not to make an unbuildable image
<infinity> Laney: It's not unbuildable.
<infinity> Laney: Why would it be?
<infinity> Laney: Think it through.  If the images were built with all components, it would work fine.  If they're not (and they're not), it'll still work fine, since we can't read task headers we don't have.
<Laney> Ok
<Laney> I thought that the part that made the list had all components enabled
-queuebot:#ubuntu-release- Unapproved: dbus-test-runner (yakkety-proposed/universe) [15.04.0+15.10.20151002-0ubuntu1 => 15.04.0+16.10.20160906-0ubuntu1] (no packageset) (sync)
<infinity> Of course, having stuff in task: ubuntu-desktop and in universe is sick and wrong and needs fixing ASAP, but it won't affect the current images.
-queuebot:#ubuntu-release- Unapproved: unity8-desktop-session (yakkety-proposed/universe) [1.0.13+16.10.20160809-0ubuntu1 => 1.0.13+16.10.20160919-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dbus-test-runner [sync] (yakkety-proposed) [15.04.0+16.10.20160906-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted unity8-desktop-session [sync] (yakkety-proposed) [1.0.13+16.10.20160919-0ubuntu1]
<shadeslayer> infinity: is it alright if I upload Frameworks 5.26 too? it's been tested by the kubuntu devs for a week or so now
<infinity> shadeslayer: You can upload whatever you like.  It'll get stuck in a queue for review anyway. :P
<shadeslayer> infinity: heh ok :D
<infinity> shadeslayer: But yeah, if the implication is that your beta is pointless without this stuff, get it in.
<shadeslayer> infinity: yeah, the idea is to have the latest bugfix of things in
<shadeslayer> infinity: can you also accept Plasma 5.7.5 ?
<shadeslayer> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<shadeslayer> I can give you a list of things to accept
<infinity> shadeslayer: A bunch of it isn't even built yet.
<flocculant> infinity: of course :)
<shadeslayer> infinity: right, when its done I meant :)
<shadeslayer> infinity: http://paste.ubuntu.com/23210986/
<shadeslayer> is what I have
<cjwatson> Laney: It depends how germinate is run.  The germinate run that builds Task headers in the archive has all components enabled.  The germinate run that happens as part of image builds doesn't necessarily (depends on flavour).
<infinity> cjwatson: Less about germinate in this case, actually, and more about which components are enabled in the chroot when livecd-rootfs builds the task install list.
<Laney> It does something like apt-cache dumpavail | grep-dctrl <stuff> IIRC
<Laney> With an amazing number of backslashes
<infinity> All the backslashes.
<infinity> But yeah, point stands that if all components were enabled, it would work, and if they weren't, it would still work. ;)
<infinity> Cause it can't read task headers it doesn't have.
<cjwatson> infinity: Well, yeah, those two things have to be in sync or weird stuff will happen.
<infinity> shadeslayer: Uhh, this plasma-discover upload is insane. :P
<infinity> shadeslayer: Transitional packages with no dependencies are exactly 100% useless.
<cjwatson> Incidentally the older I get the more I think tasks were probably a mistake.
 * shadeslayer looks
<Laney> Well I misremembered that the grep-dctrl was happening outside the chroot to catch this kind of thing and make image builds fail
<Laney> cjwatson: Do tell
<cjwatson> We wanted them for auto-install marking I think, but they're arguably counterproductive for that.
<infinity> shadeslayer: The real problem is that where plasma-discover "Breaks: plasma-discover-private, plasma-discover-updater", that should be a Conflicts.
<cjwatson> And they're actively painful for point releases.
<shadeslayer> infinity: looking into it
<cjwatson> (Due to it being impossible to remove Task headers from the release suite)
<infinity> shadeslayer: Package frontends will read Conflict/Replaces (the pair together) as "bump off these packages in favour of the new one".
<shadeslayer> indeed thosse can be dropped
<cjwatson> If I were doing it again I'd probably just use metapackages throughout; and it might be worth attempting to switch to those.
<infinity> shadeslayer: Though, if plasma-discover itself wasn't on the system before, then keeping breaks/replaces as is, but making the transitional packages actually depend on plasma-discover is the better option. :P
<shadeslayer> let me check other places
<infinity> cjwatson: Yeah, I've been edging in that direction.  The problem with metapackages is the unwieldly amount of hinting one needs in the image build process because not all flavours are the same.
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Yakkety Beta 2] (20160921) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Yakkety Beta 2] (20160921) has been added
<shadeslayer> well, one would not install plasma-discover-private by it's own tbh
<infinity> cjwatson: But, as you note, I need to do that for point releases anyway, so...
<cjwatson> And I think that would probably be easier if we didn't have to fix quite so many mistakes post-release.
<cjwatson> Tasks let us do a bit more hinting at the seed level, but all that needs to be at least somewhat in sync with apt's behaviour anyway.
<cjwatson> And it's just all too complex to understand.
<infinity> cjwatson: The hinting will always be necessary, since one can't divine how to resolve all alt deps, and each flavour has a preference that can't be codified in the dpkg deps.
<cjwatson> Right, but that could possibly just live in the metapackage.
<cjwatson> Maybe.
<infinity> cjwatson: But yeah, not sure how to really make "apt-get install task" and "apt-get install task^" match.  Would be nice.
<infinity> Perhaps a re-engineering of the whole mess would be in order if anyone had that magic time thing.
<cjwatson> Since apt will install all the immediate deps of the metapackage first and then try to fix broken deps after that, I think.
<infinity> It will, more or less.  That's essentially how my hinting works.
<cjwatson> s/will install/will mark for install/
<infinity> I hint some + and some - (dep and conflict, I guess), then everything else.
<infinity> Most of the hints can be expressed negatively, which is slightly more elegant for image builds, but doesn't work at all for metapackages, since we then can't install two flavours at once.
<cjwatson> I certainly wouldn't rule out that some packages might have to be fixed/reengineered/whatever.
<infinity> Yeah.
<cjwatson> But I think it might be worth it for eliminating a bit of the image build process that like three people understand.
<infinity> I don't like what installing tasks does for autoremove.
<infinity> That's my biggest complaint.
<acheronuk> shadeslayer: I would not install plasma-discover at all. It's a POS
<infinity> People get a bunch of library cruft from installing with our live images.
<infinity> acheronuk: Not a helpful statement.
<cjwatson> The original idea was that apt would remember that you'd installed the task, but AFAIK that never happened.
<cjwatson> I mean specifically the task rather than all its pieces.
<infinity> cjwatson: It might have.  We stopped using apt's task install feature.
<infinity> cjwatson: You converted it to evil.
<acheronuk> shadeslayer: santa_ was trying to sort dist-upgrade issues on discover with his changes
<cjwatson> Indeed.
<acheronuk> infinity: sorry
<cjwatson> But I think auto-marking didn't work right even before that.
<acheronuk> discover is just a pain at the best of times :/
<infinity> cjwatson: Yeah, I'm pretty sure you're right.
<shadeslayer> acheronuk: that's not the issue here
<infinity> cjwatson: Cause I think I introduced my linux-headers unmarking hack before you perpetrated your evil.  I think.
-queuebot:#ubuntu-release- Unapproved: apt (yakkety-proposed/main) [1.3~rc4ubuntu1 => 1.3] (core) (sync)
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Yakkety Beta 2] (20160921) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Yakkety Beta 2] (20160921) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Yakkety Beta 2] (20160921) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Yakkety Beta 2] (20160921) has been added
<xnox> infinity, so we will have kernel respin of the world for final beta?
<xnox> 474 & 4.8.0-11.12 is no good on s390x =/
<mardy> pitti: I need an archive admin to get approval on a package, do you have some time?
<infinity> xnox: Yes.  Your s390x fix is working through the sausage factory.
<xnox> win =)
<xnox> i'll get the ketchup ready
<Laney> Sounds like there's a sausage party coming up
-queuebot:#ubuntu-release- Unapproved: rejected apt [sync] (yakkety-proposed) [1.3]
<mardy> seb128: or do you? (5 lineas up ^)
<seb128> mardy, you should share the secret package name that needs review ;-)
<infinity> seb128: That takes half the fun out of it.
<mardy> seb128: the request is "please do binNEW pre-review on the account-plugin-mcloud binary package in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-059/+sourcepub/6844940/+listing-archive-extra" (no idea what that means :-) )
<seb128> mardy, let me look
<seb128> mardy, the packaging looks fine but you would need a FFe to land that new feature in yakkety
<mardy> seb128: OK, I'll file it
<seb128> thanks
-queuebot:#ubuntu-release- New: accepted plasma-discover [amd64] (yakkety-proposed) [5.7.5-0ubuntu1]
<seb128> or just update the bug you used in the changelog to be the ffe
<seb128> mardy, ^
-queuebot:#ubuntu-release- Unapproved: accepted apt [sync] (yakkety-proposed) [1.3]
<mardy> seb128: oh, good idea
-queuebot:#ubuntu-release- Unapproved: blktap-dkms (yakkety-proposed/universe) [2.0.93-0.7ubuntu1 => 2.0.93-0.7ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted blktap-dkms [source] (yakkety-proposed) [2.0.93-0.7ubuntu2]
<pitti> mardy: re from lunch, seems seb128 already reviewed it?
<pitti> seb128: FWIW, FFEs for binNEW is mostly just "find an archive admin to review it"; (but doesn't hurt to have a paper trail of course)
<mardy> pitti: yep, thanks anyway
<mardy> seb128: added the FFe info to bug 1587282
<ubot5`> bug 1587282 in account-plugins (Ubuntu) "create online-account plugin for cmcc mcloud" [Undecided,New] https://launchpad.net/bugs/1587282
<seb128> mardy, thanks
-queuebot:#ubuntu-release- Unapproved: gvfs (yakkety-proposed/main) [1.28.2-1ubuntu1 => 1.28.2-1ubuntu2] (ubuntu-desktop)
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Yakkety Beta 2] (20160921) has been added
-queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Yakkety Beta 2] (20160921) has been added
-queuebot:#ubuntu-release- Unapproved: openjdk-9 (yakkety-proposed/universe) [9~b134-2ubuntu1 => 9~b136-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-9 [sync] (yakkety-proposed) [9~b136-1]
<wxl> infinity: Lubuntu desktop images for final beta are missing
<davmor2> infinity: meh still not finding the bcmwl driver for the wifi on the dell xps13
<davmor2> infinity: okay weirder still ubuntu-drivers list show both the intel-microcode and the bcmwl-kernel-source
<davmor2> infinity: I am wondering if this is maybe an upstart vs systemd userland issue maybe?
<lamont> dear kind release team.... I'd really really really like to get 1621615 1229458 and 1621507 into the beta... OTOH, they touch, um, things.
<lamont> thoughts? kthx
<apw> bug #1621615
<ubot5`> bug 1621615 in cloud-init (Ubuntu) "network not configured when ipv6 netbooted into cloud-init" [Undecided,New] https://launchpad.net/bugs/1621615
<lamont> cyphermox: your input on that would be a good thing
<apw> bug #1229458
<ubot5`> bug 1229458 in MAAS "grubnetx64.efi tftp client does not work over ipv6" [High,Confirmed] https://launchpad.net/bugs/1229458
<apw> bug #1621507
<ubot5`> bug 1621507 in isc-dhcp (Ubuntu) "initramfs-tools configure_networking() fails to dhcp ipv6 addresses" [High,In progress] https://launchpad.net/bugs/1621507
<lamont> apw: grub2, initramfs-tools, etc. :/
<lamont> tbf, none of that is uploaded yet
<lamont> and all of it is targeting SRU to xenial
<apw> i'd say get it uploaded then we can consider it from the queue as presumably you will be uploading it after beta either way
<lamont> and, amazingly, lets one netboot into an iscsi-root in an ipv6-only environment..  How was this not a thing for linux in the 90s, I do not know.
<apw> lamont, are those all independant as well ?
<lamont> initramfs-tools depends (I believe) on iproute2 and isc-dhcp (that's how the ipv6 config is done), cloud-init is independent (just adds checking for vars that the new initramfs-tools et al actually populate for ipv6, ditto iscsi (don't ask why iscsi is the package that writes resolv.conf in this use-case... it causes crying)
<lamont> grub2 is independent of all of it
<lamont> apw: it's down to confirming a thing or 3 this morning, with the goal being to upload during the US day today... and then I saw the beta freeze email, so I came with hat in hand before stuffing the queue with "WTF ARE THESE JONES" packasge
<lamont> that is, we're close to claiming readiness
-queuebot:#ubuntu-release- Unapproved: accepted gvfs [source] (yakkety-proposed) [1.28.2-1ubuntu2]
<davmor2> cyphermox, infinity: assigned it to ubiquity for now as I can't figure out which layer under it is not installing the package https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1626108
<ubot5`> Ubuntu bug 1626108 in ubiquity (Ubuntu) "Ubiquity session isn't setting up 3rd party hardware drivers" [Undecided,New]
<davmor2> jibel: ^
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Yakkety Beta 2] (20160921) has been added
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop powerpc [Yakkety Beta 2] (20160921) has been added
<cyphermox> davmor2: that's next on my list after I'm done with lamont's stuff and shim
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Yakkety Beta 2] (20160921) has been added
<davmor2> cyphermox: awesome stuff
<davmor2> infinity: just to cheer you up that will need a respin across the board when cyphermox fixes it :)
<cyphermox> if only I could remember why it's broken from cycle to cycle.
<davmor2> cyphermox: last time it didn't show stuff up in ubuntu-drivers list this time it does but just isn't installing them
<cyphermox> ok
<cyphermox> well, I'll look
<cyphermox> how do you currently reproduce this?
<davmor2> cyphermox: so I'm assuming something lower down or ubiquity isn't launching ubuntu-driver or whatever the tool it triggers is called
<davmor2> cyphermox: I'll setup a new live session if you need me to run anything I can do it straight away
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Yakkety Beta 2] (20160921) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Yakkety Beta 2] (20160921) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop powerpc [Yakkety Beta 2] (20160921) has been added
-queuebot:#ubuntu-release- Unapproved: isc-dhcp (yakkety-proposed/main) [4.3.3-5ubuntu13.1 => 4.3.3-5ubuntu14] (core)
<davmor2> cyphermox: obviously I can't give you access cause you know dell xps only has wifi ;)
<wxl> infinity: cancel that ping
-queuebot:#ubuntu-release- Unapproved: accepted dovecot [source] (xenial-proposed) [1:2.2.22-1ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: openjdk-9 (yakkety-proposed/universe) [9~b136-1 => 9~b136-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted openjdk-9 [source] (yakkety-proposed) [9~b136-1ubuntu1]
<cyphermox> davmor2: well what I meant was which drivers; maybe I have an old box here that can reproduce the issue
<davmor2> cyphermox: dell xps 13 broadcom wifi is what is struggling but it isn't installing the intel-microcode either on the installed system
<cyphermox> ok
<davmor2> cyphermox: it worked last week so something changed between Fridays and Tuesdays image
<cyphermox> err, ok
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (yakkety-proposed/main) [0.125ubuntu3 => 0.125ubuntu4] (core)
<cyphermox> lamont: initramfs-tools and isc-dhcp: ^
<lamont> ack
<cyphermox> lamont: since you more or less did code review of those by commenting on my bugs previously, you also know about the general idea of what they do
<davmor2> cyphermox: I didn't do a fresh install on Monday as I was confirming a bunch of stuff for willcooke so friday was my last clean install
<lamont> cyphermox: true
-queuebot:#ubuntu-release- Unapproved: accepted ntp [source] (xenial-proposed) [1:4.2.8p4+dfsg-3ubuntu5.2]
<davmor2> cyphermox: and then I did one late last night when I hit the issue.
<cyphermox> ok
-queuebot:#ubuntu-release- Unapproved: accepted davical [source] (xenial-proposed) [1.1.4-1ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted awstats [source] (xenial-proposed) [7.4+dfsg-1ubuntu0.1]
<coreycb> hello release team, we have a late bump that is required for ceilometer in yakkety to python-pbr 1.10.0 .  upstream ceilometer has moved to a new ceilometer-api binary (removed the old one) which supports different args than the older version.
<coreycb> the new python-pbr would fix this but it has quite a few rdepends
<smb> pitti, stgraber, I would highly appreciate if one of you could look at bug 1621618 and in case there is still something missing, let me know. Won't go on the ISO but still I would rather get this out sooner than too late.
<ubot5`> bug 1621618 in xen (Ubuntu) "[FFE Yakkety] Upgrade to Xen 4.7" [High,In progress] https://launchpad.net/bugs/1621618
<coreycb> for reference, bug 1626006
<ubot5`> bug 1626006 in ceilometer (Ubuntu) "wsgi_script based ceilometer-api binary does not support the same CLI arguments as console_script version" [High,New] https://launchpad.net/bugs/1626006
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (xenial-proposed) [1:2.5+dfsg-5ubuntu10.5]
<pitti> smb: replied
<smb> pitti, thanks a lot
<sergiusens> pitti is a Recommends enough to trigger an autopackage test for reverse dependency testing?
<slangasek> infinity: nusakan's ftp mirror is failing to get updated; it's 5 days out of date right now. any idea why?
<slangasek> no logs from rsync attempts over the past days either
<coreycb> pitti, hi, would you be ok an exeception for the openstack pbr issue above?
<coreycb> *with an
-queuebot:#ubuntu-release- Unapproved: libvirt (xenial-proposed/main) [1.3.1-1ubuntu10.2 => 1.3.1-1ubuntu10.3] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.15.2 => 2.15.2ubuntu1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted backuppc [source] (xenial-proposed) [3.3.1-2ubuntu3.1]
<pitti> sergiusens: not ATM, but that does sound like a good idea; mind filing a bug against "britney"?
<sergiusens> sure thing
<sergiusens> thanks
<sakrecoer> hello, ubuntu studio still hasn't got an entry on the iso tracker, i'm not sure why. but then again, we would realy like to have this uploaded for testing: https://bugs.launchpad.net/ubuntustudio/+bug/1624690
<ubot5`> Ubuntu bug 1624690 in ubuntustudio-lightdm-theme (Ubuntu) "[UIFe/FFe] Please upload ubuntustudio-default-settings" [Undecided,New]
<sakrecoer> as in, if it is possible to have it uploaded in time, we will need a respin
<sergiusens> pitti fwiw, LP: #1593148 already exists :-)
<ubot5`> Launchpad bug 1593148 in britney "trigger tests for reverse-recommends dependencies" [Low,Triaged] https://launchpad.net/bugs/1593148
<pitti> sergiusens: ah :)
<slangasek> sergiusens: snapcraft -> snap-confine would be an artificial recommends anyway, right? if you're adding an artificial package relationship, might as well use the one that's currently supported :)
-queuebot:#ubuntu-release- Unapproved: pay-service (yakkety-proposed/universe) [15.10+16.10.20160816.1-0ubuntu1 => 15.10+16.10.20160825-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: unity-scope-click (yakkety-proposed/universe) [0.1.1+16.10.20160808-0ubuntu1 => 0.1.1+16.10.20160920.1-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted unity-scope-click [sync] (yakkety-proposed) [0.1.1+16.10.20160920.1-0ubuntu1]
<seb128> there is a stack of things on http://people.canonical.com/~ubuntu-archive/component-mismatches.svg which are colored white but used to be in main so should be yellow
<ginggs> could i bug someone to process wine from yakkety NEW please?
<seb128> should the old MIR bugs be set back to fix released to fix commited to help with the overview
<seb128> or is that not needed?
<pitti> cyphermox: about http://launchpadlibrarian.net/285799523/initramfs-tools_0.125ubuntu3_0.125ubuntu4.diff.gz - do we even have dhclient in the initrd? mine doesn't, and I don't see any i-t script which would install it
<pitti> cyphermox: also, doesn't that store its lease file somewhere in /var where we wouldn't find it any more after pivoting, and is a lot slower than ipconfig?
<pitti> ^ IOW, not something I dare to accept for beta
<pitti> oh, that would be the dhclient upload after that -- but i-t at least needs a versioned dependency then
<pitti> (or Breaks: rather, we don't want to pull isc-dhcp into every installation)
-queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (yakkety-proposed) [0.125ubuntu4]
<cyphermox> err, what?
<cyphermox> we have isc-dhcp in every install anyway?
<cyphermox> (it's in minimal)
<cyphermox> the "slower than ipconfig" is something that we'll just have to deal with if it's true, as ipconfig can't do IPv6; and I don't think the lease file not being carried over is a big deal, you would get the lease back once you ask for it again as NM or ifupdown or systemd-networkd starts (since the server knows what it handed out)
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (xenial-proposed) [1.3.1-1ubuntu10.3]
-queuebot:#ubuntu-release- Unapproved: postgresql-common (yakkety-proposed/main) [175build1 => 175ubuntu1] (kubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cups (yakkety-proposed/main) [2.2.0-1 => 2.2.0-2] (core) (sync)
-queuebot:#ubuntu-release- New: accepted gnome-2048 [sync] (yakkety-proposed) [3.22.0-1]
-queuebot:#ubuntu-release- New: accepted wine [source] (yakkety-proposed) [1.8.4-1ubuntu1]
<pitti> cyphermox: no, it's Priority: important, and on a desktop only NM needs it -- and that depends: shouldn't even be there
<pitti> cyphermox: (Debian dropped it already, it's a Recommends: now; NM has a builtin fallback)
<pitti> cyphermox: also, it needs to be versioned, as new i-t with older isc-dhcp-client would render your system unbootable
<pitti> only NM aside from the metapacakge of course, but we can't require that to be installed in every cloud instance or container
-queuebot:#ubuntu-release- Unapproved: ubuntu-touch-meta (yakkety-proposed/universe) [1.283 => 1.284] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-touch-meta [source] (yakkety-proposed) [1.284]
-queuebot:#ubuntu-release- New binary: gnome-2048 [ppc64el] (yakkety-proposed/none) [3.22.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cloud-init (yakkety-proposed/main) [0.7.8-3-g80f5ec4-0ubuntu1 => 0.7.8-4-g970dbd1-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- New binary: gnome-2048 [amd64] (yakkety-proposed/none) [3.22.0-1] (no packageset)
<cyphermox> pitti: sorry, I'm not quite following. so what change do you want? I'm not doing this out of the blue, this is driven by a MAAS requirement that IPv6 netbooting works. I don't really see another way to go about it
-queuebot:#ubuntu-release- New binary: gnome-2048 [arm64] (yakkety-proposed/none) [3.22.0-1] (no packageset)
<pitti> cyphermox: i-t needs to Breaks: isc-dhcp-client (<< your_new_version) at least
<ginggs> thanks for processing wine, whomever you are :)
<pitti> cyphermox: as otherwise you are generating an initramfs that calls dhclient without installing it
<cyphermox> that I totally agree with, I just thought you meant something more
-queuebot:#ubuntu-release- New binary: gnome-2048 [i386] (yakkety-proposed/none) [3.22.0-1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnome-2048 [armhf] (yakkety-proposed/none) [3.22.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: ldb (yakkety-proposed/main) [2:1.1.26-1ubuntu3 => 2:1.1.26-1ubuntu4] (core)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Yakkety Beta 2] (20160921) has been added
-queuebot:#ubuntu-release- New binary: gnome-2048 [powerpc] (yakkety-proposed/none) [3.22.0-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted containerd [source] (xenial-proposed) [0.2.3-0ubuntu1~16.04]
<pitti> cyphermox: well, I actually did, like storing the lease, etc. -- but I figured then that this isn't important as we don't currently do it with ipconfig either
<mapreri> could somebody ignore src:diffoscope autopkgtests?  They are only tests issues, code actually workâ¦
<cyphermox> pitti: right
-queuebot:#ubuntu-release- New: accepted gnome-2048 [amd64] (yakkety-proposed) [3.22.0-1]
<cyphermox> pitti: the lease is known by the server too, you'd get the same IP if you request it after
-queuebot:#ubuntu-release- New: accepted gnome-2048 [armhf] (yakkety-proposed) [3.22.0-1]
-queuebot:#ubuntu-release- New: accepted gnome-2048 [powerpc] (yakkety-proposed) [3.22.0-1]
-queuebot:#ubuntu-release- New binary: gnome-2048 [s390x] (yakkety-proposed/universe) [3.22.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gnome-2048 [arm64] (yakkety-proposed) [3.22.0-1]
-queuebot:#ubuntu-release- New: accepted gnome-2048 [ppc64el] (yakkety-proposed) [3.22.0-1]
<cyphermox> except maybe on ipv6, due to the DUID
-queuebot:#ubuntu-release- New: accepted gnome-2048 [i386] (yakkety-proposed) [3.22.0-1]
-queuebot:#ubuntu-release- New: accepted gnome-2048 [s390x] (yakkety-proposed) [3.22.0-1]
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (xenial-proposed) [1.12.1-0ubuntu7~16.04]
<pitti> cyphermox: so then the remaining thing is that in principle you could remove isc-dhcp-client on such a system and then break your boot, but that might well fall into the "don't do that then" class :)
<pitti> which just leaves the Breaks:
<cyphermox> yeah
-queuebot:#ubuntu-release- New binary: wine [i386] (yakkety-proposed/universe) [1.8.4-1ubuntu1] (no packageset)
<cyphermox> the don't do that class is covered by the other options you can use to still run ipconfig, until we remove it entirely
<pitti> cyphermox: I guess eventually we want to put netplan/networkd into the initrd, this puts its state into /run which cleanly gets transitioned into the root fs
-queuebot:#ubuntu-release- Unapproved: qemu (yakkety-proposed/main) [1:2.6.1+dfsg-0ubuntu3 => 1:2.6.1+dfsg-0ubuntu4] (ubuntu-server, virt)
-queuebot:#ubuntu-release- New binary: docker.io [amd64] (xenial-proposed/universe) [1.12.1-0ubuntu7~16.04] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-pbr (yakkety-proposed/main) [1.8.0-4.1ubuntu1 => 1.10.0-0ubuntu1] (ubuntu-desktop, ubuntu-server)
<slangasek> "built-in fallback"> wut
<slangasek> we certainly shouldn't be using multiple dhcp client implementations, NM should be using isc-dhcp consistently
-queuebot:#ubuntu-release- New binary: wine [powerpc] (yakkety-proposed/universe) [1.8.4-1ubuntu1] (no packageset)
<pitti> well, it's still achingly slow, I see why people want to not use it
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.15.2ubuntu1]
<cyphermox> slangasek: I don't know that NM has any built-in implementation of dhcp
-queuebot:#ubuntu-release- New binary: wine [arm64] (yakkety-proposed/universe) [1.8.4-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: dm-writeboost (yakkety-proposed/universe) [2.2.3-1 => 2.2.3-1ubuntu1] (no packageset)
<slangasek> pitti: sure, so let's fix that there in the right place, not work around it selectively for desktop
-queuebot:#ubuntu-release- Unapproved: accepted dm-writeboost [source] (yakkety-proposed) [2.2.3-1ubuntu1]
<lamont> can someone smack cloud-init past the freeze marker?
<lamont> brb
<ginggs> wine amd64 build was successful but upload failed: wine_1.8.4-1ubuntu1_all.deb: Version older than that in the archive. 1.8.4-1ubuntu1 <= 1:1.6.2-0ubuntu15 :(
<ginggs> what can we do about that?
<apw> i thought that wine upload had renamed those packages to wine-something to avoid that
<apw> "Replace package wine with wine-stable. Needed for the transition to a
<apw>     0-epoch in the version number.
<apw> and indeed the changelog claimsso
<slangasek> lamont: I see no cloud-init on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html; can you clarify what needs smacking?
<slangasek> ginggs: right, you can use a different binary name, or you can add an epoch. epochs are forever
<slangasek> lamont: ah, in the unapproved queue, right. checking
<slangasek> lamont: cloud-init accepted
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (yakkety-proposed) [0.7.8-4-g970dbd1-0ubuntu1]
<ginggs> apw, slangasek: thanks, going to double check on that.  Is removal of the offending package an option (provided all the necessary breaks/replaces are in place?)
<apw> ginggs, an option to achieve a reset of the epoch ?
<lamont> slangasek: sorry for the unclarity there
<lamont> thanks
<lamont> cyphermox: I'm going to stay hands-off on your changes
<slangasek> lamont: the fault is mine for being oblivious to how the freeze is being managed ;P
<lamont> heh
<slangasek> (or the fault is infinity's, for insisting on freezing the queue when we can block things in proposed-migration instead ;)
<cjwatson> removal of the offending package doesn't do anything to cause users doing a dist-upgrade to get the correct new version installed
<lamont> slangasek: if you let it into -proposed, then you have to supersede it to get something in after a compropmise is reached.
<apw> cjwatson, by the looks of things the intent is to use breaks/replaces/conflicts to throw wine off while replacing it with wine-stable, and then sometime after 18.04 transition back to wine ...
<apw> but to do that the wine transitional would have to have a real binary version above those in the archive currently, i make no comment on whether this will work
<ginggs> apw, cjwatson: i meant removing the old package to allow the new one into the archive.  maybe the solution here is just not to build a wine package, all it does is depend on wine-stable
<apw> it is not clear how that one would help transition people unless it has a higher binary version (which can differ from the source) than the archive
<apw> even if the old was replaced with that, the people with an existing package would think theirs was newer and not update
<cjwatson> ginggs: that's what I'm saying, we don't generally do that because the purpose of this check is to protect against client problems
-queuebot:#ubuntu-release- Unapproved: address-book-app (yakkety-proposed/universe) [0.2+16.10.20160913-0ubuntu1 => 0.2+16.10.20160920-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: address-book-service (yakkety-proposed/universe) [0.1.2+16.10.20160908-0ubuntu1 => 0.1.2+16.10.20160920-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: buteo-syncfw-qml (yakkety-proposed/universe) [0.1+15.10.20151008-0ubuntu1 => 0.1+16.10.20160919-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted buteo-syncfw-qml [sync] (yakkety-proposed) [0.1+16.10.20160919-0ubuntu1]
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Yakkety Beta 2] has been updated (20160921.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Yakkety Beta 2] has been updated (20160921.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Yakkety Beta 2] has been updated (20160921.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Yakkety Beta 2] has been updated (20160921.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Yakkety Beta 2] has been updated (20160921.1)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Yakkety Beta 2] has been updated (20160921.1)
<lamont> slangasek: so... about my favorite thing to hate this month...
<lamont> the changes that cyphermox is stuffing through, along with a couple others, actually allow you to netboot ipv6 with an iscsi-root (bug 1621515 and bug 1621507)
<ubot5`> bug 1621515 in Ironic "[RFC] DRAC: get progress after submitting set_bios_config request" [Wishlist,Fix released] https://launchpad.net/bugs/1621515
<ubot5`> bug 1621507 in isc-dhcp (Ubuntu) "initramfs-tools configure_networking() fails to dhcp ipv6 addresses" [High,In progress] https://launchpad.net/bugs/1621507
<lamont> slangasek: strong preference would be to have them _IN_ the beta
<lamont> with the exception of the change in initramfs-tools (and the introduction of isc-dhcp), it's all "if this variable that nothing previously set is set, then do things for ipv6"
<cyphermox> initramfs-tools should reappear shortly, I did the upload already
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (yakkety-proposed/main) [0.125ubuntu3 => 0.125ubuntu4] (core)
<slangasek> lamont: there was discussion upscroll about this between pitti and cyphermox; I'm unsure if there was a conclusion that changes were needed to the packages currently in the queue
<lamont> the initramfs-tools change is to use isc-dhcp rather than klibc's ipconfig, which we're all confident is a good thing, but would love to have a WIDE exposer to
<slangasek> right, that
<lamont> slangasek: the conclusion was that cyphermox was fixing his badness, I thought. :D
<cyphermox> slangasek: pitti was asking about a Breaks I've added.
<slangasek> k
<lamont> slangasek: my request is that once pitti and cyphermox are all good with it, that we release cloud-init, open-iscsi, isc-dhcp, and initramfs-tools into the beta.
 * slangasek nods
<slangasek> which pitti has the power to do
<slangasek> but is also going to be EOD
<lamont> cyphermox: and I believe that we're addressing the klibc part of 1621507 by stabbing it in the face, yes?
<cyphermox> that initramfs-tools upload includes the Breaks pitti wanted, I didn't get a review for isc-dhcp.
<cyphermox> lamont: no, the klibc part of bug 1621507 will be for laterz
<ubot5`> bug 1621507 in isc-dhcp (Ubuntu) "initramfs-tools configure_networking() fails to dhcp ipv6 addresses" [High,In progress] https://launchpad.net/bugs/1621507
<cyphermox> well, we're not using it for dhcp, but it still may be used for other things, and I'm not willing to break other people's possibly very outdated and broken ways of netbooting by only allowing dhclient
<cyphermox> or at least, not this late in the cycle, etc. etc.
<lamont> cyphermox: I was referring only to the whole configure_networking() change for dhcp, but yeah
<cyphermox> yeah, for dhcp we don't use ipconfig/klibc anymore.
<cyphermox> early in Z I'd get back to my spreadsheet and try to quickly stab klibc off the initramfs.
-queuebot:#ubuntu-release- Unapproved: walinuxagent (xenial-proposed/main) [2.1.3-0ubuntu4.1 => 2.1.3-0ubuntu4.2] (ubuntu-cloud, ubuntu-server)
<sergiusens> slangasek given LP: #1593148 and LP: #1626121 (even though it might not have directly caught this bug), I would like to take up on your offer to at least temporarily add the adt triggers you mentioned
<ubot5`> Launchpad bug 1593148 in britney "trigger tests for reverse-recommends dependencies" [Low,Triaged] https://launchpad.net/bugs/1593148
<ubot5`> Launchpad bug 1626121 in Snappy "snap-confine causes Segmentation fault" [Critical,In progress] https://launchpad.net/bugs/1626121
-queuebot:#ubuntu-release- Unapproved: python-django (yakkety-proposed/main) [1.8.7-1ubuntu6 => 1.8.7-1ubuntu7] (ubuntu-server)
<sakrecoer> hi, the ubuntustudio 64-bit failed 2 hours ago, but there is still no buildlog to be found.
<sakrecoer> slangasek: i'm told you might know what is going on. :)
<slangasek> sakrecoer: which build log are you looking for?
<sakrecoer> slangasek: the one for the failed 64bit iso: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/ubuntustudio/
<slangasek> cyphermox: I think we should stab klibc off the initramfs this cycle as part of this, rather than leaving everyone with larger initramfs for release
<cyphermox> slangasek: I'll be happy to, I just didn't forsee it as getting the priority
<slangasek> sakrecoer: ok, that's the launchpad build log that's missing, I can't help with that; you'd need wgrant or cjwatson most likely
<slangasek> cyphermox: bigger initramfs impacts boot speed for everyone; boot speed is a priority :)
<cyphermox> what I meant by my comment before is that it's rather easy to complete the work from where I left it w/r/t removing klibc; just need to continue making sure none of the bits it provides are being used
<cyphermox> fair enough
<cjwatson> sakrecoer: seems to be repeatedly crashing the builder; dunno why
<sakrecoer> slangasek, cjwatson, is there anywhere else where we can see a log of what is going on?
<cyphermox> slangasek: then I'll chalk this up not too far down my todo list, just after that new shim we need and checking out davmor's issue with the third-party drivers.
<sakrecoer> else as in, not launchpad log?
<cjwatson> sakrecoer: no, the failure is precisely that the builder crashes and so LP can't retrieve the log from it.  you'd have to either reproduce locally with the right livecd-rootfs setup, or retry the build and hope that you can spot the problem in the logtail by repeatedly reloading
<slangasek> sergiusens: fwiw the p-m autopkgtest special casing lives in git+ssh://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu, autopkgtest.py if you want to raise an MP
<cjwatson> somebody reported this with another livefs build earlier today as well.  has livecd-rootfs or live-build changed recently?
<slangasek> livecd-rootfs has changed, yes
<sergiusens> thanks
<slangasek> cjwatson: infinity landed a change to use a different kernel for powerpc64; but that seems unlikely to be causing this crash
<slangasek> likewise live-build
<sakrecoer> slangasek: i'm more instrested in having an ISO than the log :)
<sakrecoer> cjwatson ^
<slangasek> so, the previous ubuntustudio image build 22 hours ago succeeded
<sakrecoer> seems so, yes.
<slangasek> we can try building again, but if cjwatson says the builders are repeatedly crashing, that may not be productive
<cjwatson> don't let me stop you trying, as long as you give up after a while :)
<sakrecoer> cjwatson, slangasek: can the one that build 22h be a release candidate for beta2?
<sakrecoer> build 22h *ago
<flocculant> I think the problem for people like me and sakrecoer is if we hit rebuild on the tracker - that's already showing as rebuilding - we're not sure it's really doing it and nor are we sure wew're making a situation worse
<cjwatson> sakrecoer: not my decision
<cjwatson> flocculant: slangasek is certainly able to poke it manually
<flocculant> cjwatson: ack
<sakrecoer> yes, flocculant pinpoint my concern..
<cjwatson> I don't think you're going to be making it worse, but it may indeed not help
<slangasek> flocculant, sakrecoer: you would see whether or not it's doing it from that launchpad page, https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/ubuntustudio/
<cjwatson> it's not very clear what could have caused this; it could be something like out-of-memory
<cjwatson> or out of disk space on the builder, which is known to cause fairly catastrophic failures
<slangasek> sakrecoer: it's probably not useful to release the 22-hours-ago image for beta, it has the 4.4 kernel on it
<cjwatson> though I think the latter results in a hang, not a crash like this
<cjwatson> so yeah, throw it back against the wall and see what happens
<sakrecoer> slangasek, cjwatson: alright, i'll hit respin on the tracker and touch some wood then :)
<slangasek> I wonder if the ubuntustudio xenial builds are also dead
<slangasek> sakrecoer: no
<slangasek> sakrecoer: I have already triggered a rebuild
<sakrecoer> ok :) thank you slangasek !
<slangasek> sorry, guess I wasn't clear that I was doing that
<slangasek> cjwatson: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntustudio/+build/76141 ? "estimated finish" + "currently building" + link to build log
<cjwatson> there are some partial-crash states that can do that
<cjwatson> or possibly it's still gathering the build
<cjwatson> 2016-09-21 17:50:54+0000 [HTTP11ClientProtocol,client] Grabbing file: livecd.ubuntustudio-dvd.squashfs (http://lcy01-28.lcy01.scalingstack.ppa:8221/filecache/186b80aa79ef7edbe24fa58fbe8b9e7ab026a1e2)
<cjwatson> hmm
 * cjwatson asks for a buildd-manager restart just in case it's confused
-queuebot:#ubuntu-release- Unapproved: irssi (yakkety-proposed/main) [0.8.19-1ubuntu1 => 0.8.19-1ubuntu2] (core)
<ginggs> cjwatson, apw: so the reason we still have a wine 1:1.6.2-0ubuntu15 in the archive, is because the new wine1.6 package hasn't migrated yet, and the reason for that is is depends on the new wine-stable packages. if the old wine binary package was removed from the archive, then the new wine source package would go into the archive and both would migrate.
 * Ukikie raises eyebrow.
<cjwatson> slangasek,sakrecoer: ok, so a buildd-manager restart seems to have helped, that may have been the problem
<ginggs> cjwatson, apw: when upgrading, the old wine package is removed, as can be seen from the install log in comment #52 of LP: #1558480
<ubot5`> Launchpad bug 1558480 in wine1.6 (Ubuntu) "[FFe] Transition from src:wine1.6 to src:wine from Debian" [High,Triaged] https://launchpad.net/bugs/1558480
<cjwatson> ginggs: if the wine binary package is not intended to remain installed, it should be removed
<cjwatson> ginggs: (from the archive)
<cjwatson> ginggs: I'm not prepared to wind versions backwards in release suites, pretty much no matter what the argument :)
<cjwatson> ginggs: that is, the conclusion I'm drawing from your argument so far is that you should stop building a wine binary package
<ginggs> cjwatson, apw: ok, so the new wine binary package is only there for people who have never had wine installed and just want to do 'apt-get install wine' and expect it to work
<sakrecoer> thank you cjwatson!
 * sakrecoer still crossing fingers
<cjwatson> ginggs: at this point I don't think I can do anything other than repeat myself, sorry, so I'm bowing out of this conversation
<ginggs> cjwatson, apw: I think it is safe for us to drop it then, and they will just have to do 'apt-get install wine-stable' instead.
<cjwatson> you are not going to persuade me to make the version of a binary package in a release suite go backwards
<cjwatson> you could always make wine's version number be higher, though I don't know what the consequences would be.
<cjwatson> (note that it is not strictly required for the version of a binary package to be identical to the version of the source package that generates it)
<cjwatson> anyway, dinner
<ginggs> cjwatson: thanks
<cjwatson> (dh_gencontrol -pwine -- -v<overridden-version> or some such, probably computed with the aid of dpkg-parsechangelog)
<cyphermox> davmor2: ok, I think I see what's wrong on the desktop daily
<davmor2> cyphermox: \o/
<cyphermox> davmor2: looks like despite what is configured in polkit, we don't get access to NetworkManager, or to install the packages for ubuntu-drivers
<davmor2> cyphermox: I blame pitti bound to be his fault ;)
<cyphermox> I have no idea whose fault it is, but it looks wrong. we shouldn't have to click anythign special to be able to run this in the installer
<cyphermox> davmor2: can you confirm that if you start ubiquity via 'sudo ubiquity' in a terminal things behave correctly? looks that way to me anyway
<davmor2> cyphermox: sure give me 2 seconds
<davmor2> cyphermox: I'm not seeing any change for wifi on installed system or live cd
<davmor2> cyphermox: you are just running sudo ubiquity right no options or anything?
<flexiondotorg> infinity, Just a head up.
<flexiondotorg> MATE Desktop 1.15.1 is currently in the Yakkety archive. It is a development release.
<flexiondotorg> MATE 1.16 is being announced tomorrow.
<flexiondotorg> So I'll be bumping all of MATE in the coming days.
-queuebot:#ubuntu-release- Unapproved: update-notifier (yakkety-proposed/main) [3.172 => 3.173] (ubuntu-desktop, ubuntu-server)
<dobey> hi, can someone on release team please let pay-service through the UNAPPROVED queue? the upload was fixes for the MIR review, and i don't think it's been seeded yet?
<cyphermox> davmor2: indeed no extra options, I can get the wifi connected and the packages (intel-microcode) appear to be installed
<davmor2> cyphermox: whats the md5sum of your image lets makes sure we are both on the same version
<cyphermox> 95c23e02a129237414d99ac6f91b65ce
<cyphermox> davmor2: I doubt that would make much of a difference
<davmor2> cyphermox: nope they are the same but it was worth a double check to be sure :)
<davmor2> cyphermox: dpkg -l | grep intel shows intel-gpu-tools, libdrm-intel, xserver-xorg-video-intel and dpkg -l | grep bcmwl shows nothing thats on the installed system
<davmor2> cyphermox: anything else you'd like me to try?
-queuebot:#ubuntu-release- Unapproved: snapcraft (yakkety-proposed/universe) [2.17+16.10.1ubuntu3 => 2.18+16.10] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (yakkety-proposed) [2.18+16.10]
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.17 => 2.18] (no packageset)
-queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.15.2+16.10.2 => 2.15.2+16.10.3] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted irssi [source] (yakkety-proposed) [0.8.19-1ubuntu2]
 * davmor2 calls it a night cyphermox if there is anything you want me to test just send me a mail and I'll catch you tomorrow
<dobey> hmm
<slangasek> dobey: yeah, I'm not sure why pay-service isn't getting auto-accepted; accepting now
<dobey> slangasek: thanks!
-queuebot:#ubuntu-release- Unapproved: accepted pay-service [sync] (yakkety-proposed) [15.10+16.10.20160825-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted address-book-app [sync] (yakkety-proposed) [0.2+16.10.20160920-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted address-book-service [sync] (yakkety-proposed) [0.1.2+16.10.20160920-0ubuntu1]
<slangasek> infinity, stgraber: ^^ why were these packages not auto-accepted?  They're not yet on any image
<infinity> slangasek: They're seeded in desktop.
<infinity> slangasek: Not on images only due to their being in universe still, but they *are* seeded. :/
<slangasek> infinity: ok, so it's pulled via the unity8-desktop-session change, ack
<slangasek> that's not unreasonable and I'll keep hand-accepting, thanks
<slangasek> (but for some reason 'seeded-in-ubuntu' gives a different answer)
<infinity> seeded-in-ubuntu may well still be working off old data while ubuntuwire is being recovered.
<infinity> It didn't even work yesterday, so this is progress. :P
<slangasek> http://ubuntuqa.tblwd.org/seeded.json.gz
<slangasek> is what it's pointed at
<infinity> Which is an old backup, yes.
<slangasek> so maybe that's not updated at the same frequency as usual, or maybe it's just normal lag, yes
<stgraber> maybe the backend for seeded-in-ubuntu should be moved to snakefruit, it should have all the needed bits on disk already so could generate the data pretty quickly (would also make the checks by the auto-accept script much faster)
<slangasek> alternatively, maybe we can figure out how to run that without it having to be on the privileged box of doom ;)
<stgraber> yeah, though snakefruit has the advantage of having all the right bits on disk and knowing when to trigger updates. I'd certainly agree that we could do with a separate role account on snakefruit just for bits that actually do need the ubuntu-archive LP creds.
<stgraber> speaking of which, LP is throttling auto-accept it looks like...
<stgraber>     At least 6 queries/external actions issued in 0.13 seconds OOPS-8e4956c456ad405f5ab34b3896926396
<stgraber> seeing a few similar entries in the log
<infinity> We should probably move all the ubuntu-dev-tools web services into the Canononical DC, but I don't think anyone's ever stepped up to offer a path forward for that.
<infinity> But we rely too heavily on seeded-in-ubuntu and reverse-depends, at least, for them to have downtime.
-queuebot:#ubuntu-release- Unapproved: accepted postgresql-common [source] (yakkety-proposed) [175ubuntu1]
<stgraber> actually, just a single oops, so hopefully just a one time glitch, will ping LP folks if I see more of that in the log
-queuebot:#ubuntu-release- Unapproved: accepted ldb [source] (yakkety-proposed) [2:1.1.26-1ubuntu4]
<tumbleweed> infinity: it's not an old backup, there's a cron job
<tumbleweed> but also, ubuntuwire is back
<tumbleweed> slangasek: yeah, I had no idea what the cron frequency was, so it was almost certainly different
<tumbleweed> tying that to publishes wolud be nice
<tumbleweed> and hosting it at canonical obviously :P
<infinity> tumbleweed: Yeah, I noticed ubuntuwire was back.
<infinity> (thanks!)
<apw> infinity, did the cowboy get reverted ?
<infinity> tumbleweed: I assume the generation scripts for the seeded and reverse-dep services are pretty simple?
<slangasek> oh yay, cancelling my wrapper scripts for seeded and revdeps :)
<infinity> apw: Probably not.  Go for it.
<tumbleweed> infinity: fairly. reverse-deps is a bit more complex (and doesn't understand some of the modern dependency qualifiers)
<infinity> slangasek: Note that seeded-in-ubuntu still won't tell you about fallout from unity8-desktop-session, I suspect it's taking components into account or something.
<slangasek> infinity: "path forward"> so if someone created a charm for those services and wrapped them in a mojo spec, it would be straightforward for Foundations to own that
<apw> infinity, and ripped
<infinity> apw: Ta.
<infinity> slangasek: Charming them implies a dists mirror for each one too, which is likely why stgraber was suggesting we just dump them on snakefruit.
<tumbleweed> https://bazaar.launchpad.net/~stefanor/+junk/reverse-deps/view/head:/update-rdepends.py - hairy ugly sql for performance
<tumbleweed> seeded in ubuntu is far simpler: https://bazaar.launchpad.net/~stefanor/+junk/ubuntu-seeded-packages/view/head:/update.py
<tumbleweed> err, no,  the complex DB structure in reverse-depends was for database size. otherwise I would have used a flatter schema
<slangasek> infinity: yeah, I think we would want to have a shared nova volume for the dists mirror instead
<infinity> slangasek: That could be a good first step to charming up a lot of archive-reports, yeah.
<infinity> (which is where this stuff would fit in the current world order)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-14.15] (core, kernel)
<slangasek> hmmm can a nova volume actually be shared, though
<slangasek> I guess you might have to resort to swift for sharing
<infinity> slangasek: Dunno.  But it would only need to be r/o to all services using it, and r/w to the mirror service that gets triggered.
<slangasek> or else run all the related charms on a single unit
<infinity> slangasek: So, there should be a way to make that work, somehow.
<infinity> slangasek: Or that, yeah.
<slangasek> unless someone wants to volunteer to maintain an nfs server in prodstack
<infinity> *shudder*
<infinity> Actually, nfs for r/o data isn't the worst option.
<infinity> But probably also not the best. :P
<infinity> slangasek: This isn't me committing just yet, but it would be an interesting project to see what one can do with relations.
<infinity> slangasek: Cause, ideally, the r/w mirror service would trigger all the related microservices to do their thing after each mirror pulse, emulating the monolithic archive-reports cronjob.
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-14.15]
 * slangasek nods
<infinity> slangasek: And, obviously, in a juju-perfect world, adding a microservice should be as simple as declaring a relationship to the mirror service and Bob's your uncle.
-queuebot:#ubuntu-release- New: accepted wine [arm64] (yakkety-proposed) [1.8.4-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted wine [powerpc] (yakkety-proposed) [1.8.4-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted wine [i386] (yakkety-proposed) [1.8.4-1ubuntu1]
<santa_> infinity: hi
<santa_> infinity: regarding the plasma.discover issue with xenial -> yakkety dist-upgrades I re-tested again the solution with metapackages and it seems it doesn't work anymore here, so I figures out a different solution https://paste.kde.org/pyt0a2bvv
<santa_> * figured
<infinity> santa_: Erm, that doesn't make much sense either.
<infinity> santa_: Isn't the goal to have the two old packages removed on upgrade?
<infinity> santa_: I'd expect something like this: http://paste.ubuntu.com/23213525/
-queuebot:#ubuntu-release- Unapproved: cups-filters (yakkety-proposed/main) [1.11.3-0ubuntu1 => 1.11.4-0ubuntu1] (desktop-core, ubuntu-server)
<santa_> infinity: well, the idea is also removing the transtionals, but the important part is the conflicts. let me re-paste to show the "serious" diff
<santa_> commit 5e362c8de89256b27f62334659bace4e407ec8e1
<santa_> Author: JosÃ© Manuel SantamarÃ­a Lema <panfaust@gmail.com>
<santa_> Date:   Wed Sep 21 22:47:31 2016 +0200
<santa_>     Drop transitional packages, use Conflicts against python3-aptdaemon.pkcompat.
<santa_> diff --git a/debian/changelog b/debian/changelog
<santa_> index 794047f..49e688d 100644
<santa_> --- a/debian/changelog
<santa_> +++ b/debian/changelog
<santa_> @@ -1,3 +1,14 @@
<santa_> +plasma-discover (5.7.5-0ubuntu2) UNRELEASED; urgency=medium
<santa_> +
<santa_> +  * plasma-discover now Conflicts against python3-aptdaemon.pkcompat, without
<santa_> +    this apt-get would want to remove plasma-discover while upgrading from
<santa_> +    xenial to yakkety.
<santa_> +  * Drop transitional dummy packages plasma-discover-private and
<santa_> +    plasma-discover-updater because the above solution is the one which actually
<santa_> +    works.
<cjwatson> santa_: Please use paste.ubuntu.com next time.
<santa_> +
<santa_> + -- JosÃ© Manuel SantamarÃ­a Lema <panfaust@gmail.com>  Wed, 21 Sep 2016 22:40:54 +0200
<santa_> +
<santa_>  plasma-discover (5.7.5-0ubuntu1) yakkety; urgency=medium
<santa_>  
<santa_>    [ Philip MuÅ¡kovac ]
<santa_> diff --git a/debian/control b/debian/control
<santa_> index 1b08d04..00ca3f5 100644
<santa_> --- a/debian/control
<santa_> +++ b/debian/control
<santa_> @@ -51,6 +51,7 @@ Depends: appstream (>= 0.8),
<santa_>           qml-module-qtgraphicaleffects,
<santa_>           ${misc:Depends},
<santa_>           ${shlibs:Depends}
<santa_> +Conflicts: python3-aptdaemon.pkcompat
<santa_>  Breaks: libmuon (<< 4:5.6),
<santa_>          muon-discover (<< 4:5.5.3a),
<santa_>          muon-notifier (<< 4:5.5.3a),
<santa_> @@ -95,24 +96,6 @@ Description: Discover software manager suite (common data files)
<santa_>   This package contains data files shared by various parts of the
<santa_>   Discover suite.
<santa_>  
<santa_> -Package: plasma-discover-private
<santa_> -Architecture: all
<infinity> ...
<santa_> -Section: oldlibs
<santa_> -Priority: extra
<santa_> -Depends: ${misc:Depends}
<santa_> -Description: Transitional package plasma-discover-private
<santa_> - This is a transitional package for plasma-discover-private and can safely be
<santa_> - removed.
<santa_> -
<santa_> -Package: plasma-discover-updater
<santa_> -Architecture: all
<santa_> -Section: oldlibs
<santa_> -Priority: extra
<santa_> -Depends: ${misc:Depends}
<santa_> -Description: Transitional package plasma-discover-updater
-queuebot:#ubuntu-release- Unapproved: cups (yakkety-proposed/main) [2.2.0-1 => 2.2.0-2] (core) (sync)
<santa_> - This is a transitional package for plasma-discover-updater and can safely be
<santa_> - removed.
<santa_> -
<santa_>  Package: muon-discover
<santa_>  Architecture: all
<santa_>  Section: oldlibs
<santa_> ugh
<santa_> sorry
<santa_> I meant to use paste bin
<santa_> cjwatson: yes, it was an accident, I tought I was pasting the pastebin link, sorry
<santa_> infinity: https://paste.kde.org/pezttjezs
<infinity> santa_: Okay, slightly better, but one thing you should still change, then.
<santa_> ok, what is it?
<infinity> santa_: The Breaks/Replace from p-d to p-d-private and p-d-updater should be Conflicts/Replaces.
<infinity> santa_: That'll hint frontends to consider completely removing the old packages.
<santa_> oh well, that came from debian
<infinity> santa_: (ie: just move those two packages from Breaks to Conflicts)
<infinity> santa_: Yeah, most DDs don't seem to understand dpkg relations any better than most UDs. :P
<santa_> that's tricky sometimes
<infinity> santa_: Breaks/Replaces is for file takeover, Conflicts/Replaces is for whole package takeover.
<santa_> I wasn't aware, I used to use transitional packages + versioned Breaks/Replaces. godd to know
<santa_> * good
<infinity> santa_: If you were keeping the transitionals, versioned B/R would be correct.
<infinity> santa_: Since you're effectively keeping the transitional installed, but moving the files.
<infinity> santa_: But without the transitionals, when the goal is total removal of the old packages, Conflicts is correct.
<santa_> ah, ok. I get you
<santa_> so, I will rebuild the thing once again, let's hope it works
<infinity> santa_: Otherwise, seems sane enough.  Can't be worse than the current version, where the transitionals do literally nothing. ;)
<santa_> when I tested, aparently it worked. not today
<santa_> I guess I did something wrong when testing
<infinity> We all do.
<infinity> Being too close to the solution never helps.
<infinity> (Hence the value in review and QA being other people)
<infinity> santa_: Another nice way to remember when to use Conflicts and Breaks is whether or not the correct expression should be versioned.
<santa_> yeah
<infinity> santa_: So, say I'm moving a file from A to B, but want both to be installed (like in a transitional, or just shuffling packaging around), it's versioned, and thus breaks.
<infinity> santa_: But in a case where you want the packages to not coexist ever, it's unversioned, and a conflict.
<santa_> yeah I maded that ones a lot of times
<santa_> so the conflicts/breaks to take over a package ... should be ... unversioned, right?
<infinity> Conflicts/Replaces
<infinity> Should be unversioned, though versioned doesn't hurt.
<infinity> The only reason to version it would be if you think those packages may come back some day and bite you. :P
<infinity> But if they're gone for good, it should be unversioned, ideally.
<santa_> ok, and yes I meant replaces
<infinity> Makes apt think a tiny bit harder when it's versioned and doesn't need to be, but it's not world-ending.
<infinity> santa_: I suspect the real confusion for most people is the meaning of Replaces, because it does double-duty.
<infinity> santa_: On its own (or with a Breaks, which is more correct now that we have Breaks), it means "I'm overwriting some files", but with Conflicts, it means "I'm taking over this package entirely, make it go away".
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (yakkety-proposed) [2.15.2+16.10.3]
<infinity> dpkg could probably do with a few more relationships to avoid having the tuples. :P
<infinity> But oh well.
<slangasek> flocculant, sakrecoer: ubuntustudio build never finished (same problem again on the buildds), retrying again now that the buildd manager stuff should be fixed
<santa_> infinity: I'm going to test this https://paste.kde.org/psrnwmiea any other suggestion?
<slangasek> infinity, cyphermox: so the problem with the mirroring was a stale cronjob that had been hanging around since right after the system booted, which had a record in etc/.build-image-set-pids.  As long as there is any existing entry in that file when multipidfile.held() is called, sync_local_mirror() will do nothing but "wait for the mirror to sync", which only tries to take a lock - and if it
<slangasek> succeeds in taking the lock it thinks everything's hunky-dory
<cjwatson> It's possible I cleared one lock and forgot to clear the other; sorry
<slangasek> infinity, cyphermox: in short, lib/cdimage/build.py:sync_local_mirror() does not in any way ensure that the ftp mirror is up to date
<cjwatson> FWIW multipidfile could be improved in this regard (it wasn't possible with semaphore, but is with multipidfile)
<cjwatson> It could fairly easily do a kill(pid, 0) on each to see if it's still alive
<slangasek> cjwatson: I don't think the problem was clearing of stale lockfiles.  the pids listed there were all running
<cjwatson> Not perfect but there's at least some probability that it would handle the reboot case
<cjwatson> Must have been a pid collision in that case
<slangasek> the problem is that, if there's always at least one pid listed there due to a process running, all the later jobs assume that the first one took care of getting it an up-to-date mirror
<slangasek> cjwatson: the problematic one was a pid that had genuinely been running since shortly after reboot
<cjwatson> Yeah, but if the first run went "oh, all these pids are stale" and ditched them, that would help in at least some cases
<slangasek> but anyway, the current logic is subject to a failure that, if we had no gaps in time when there was not a running job, the ftp mirror is never updated
<cjwatson> This is basically a necessary failure mode in supporting parallel builds; the game is to make it as unlikely as possible
<slangasek> cjwatson: why do we not have each build unconditionally rerun the sync upon taking the lock?
<cjwatson> Because then it might sync under the feet of another build and cause chaos
<slangasek> right
<cjwatson> The current code guarantees that the mirror does not change during a build
<slangasek> we have byhash sources available now, I think, yes?
<infinity> I generally manually sync the mirror when doing milestones (and definitely final releases) anyway.
<cjwatson> For some suites
<infinity> But it's definitely suboptimal for dailies.
<slangasek> infinity: as of my morning, the mirror was 6 days out of date
<infinity> slangasek: Yeah, I forgot to do it (see: generally) for last night's respin.
<slangasek> k
<infinity> Though I also knew there was another respin coming.
<infinity> Yay, kernel. :/
<wxl> another respin yay
<slangasek> cjwatson: which suites lack byhash?  ones that we still build for?
<wxl> so i assume we're going to delay release until friday then?
<infinity> As for the "if we have back-to-back jobs, it'll never update" issue, that would be papered over by stopping the staggered cron madness and just doing everything in parallel at one specific time.
<infinity> Then the machine would be (hopefully) guaranteed idle for some chunks.
<infinity> But that's not a solution, just a bandaid.
<cjwatson> slangasek: trusty-updates
<infinity> cjwatson: We don't build trusty anymore.
<cjwatson> ah
<slangasek> infinity: the only kernel issue I'm aware of is the one that affects cloud images only; were there other kernel issues warranting respins more generally?
<cjwatson> maybe it's tolerable then
<infinity> Last point release was a month ago.
<infinity> slangasek: s390x no worky.
<slangasek> infinity: right
<cjwatson> I don't think back-to-back jobs are the issue, anyway.
<cjwatson> nusakan doesn't do so much that there aren't some occasions when a build starts and is the only one legitimately running.
<infinity> No, in practice, back-to-back jobs haven't been a big issue, it's just a potential issue with the locking method.
<cjwatson> If it's locked for six days, it's confused, not too busy.
 * infinity nods.
<slangasek> cjwatson, infinity, cyphermox: so it seems to me that having sync_local_mirror always do a --no-delete rsync in the parallel builds case would give better behavior
<slangasek> cjwatson: indeed
<slangasek> but a more graceful failure would be nice :)
<cjwatson> Wait, we actually do test for PID existence in multipidfile anyway.
<cjwatson> So apparently I thought of that.
<cjwatson> We could also have the locking mechanisms ignore locks older than system uptime.
<slangasek> in this case it really wasn't
<cjwatson> It was the first time it ran.
<slangasek> the process was alive, and had been dawdling since the 12th
<cjwatson> Which process?
<slangasek> pid 29869, which I've since killed
<cjwatson> I mean which image build
<infinity> slangasek: With trusty out of the way, a --no-delete on parallel builds would indeed seem reasonable.
<infinity> Well.  Hrm.
<slangasek> cjwatson: it's out of scrollback now, but I /think/ it was a kubuntu build
<infinity> Maybe not that reasonable, though.
<infinity> The way I do a milestone build is to literally run them *all* in parallel.
<infinity> That shouldn't trigger 10 rsyncs all competing.
<cjwatson> Hm, yes, http://people.canonical.com/~ubuntu-archive/cd-build-logs/kubuntu/yakkety/daily-live-20160912.log suggests being stuck.
<cjwatson> OK, if it was genuinely a stuck build then fine, but I would contend that nobody noticing a stuck build (or it timing out by itself) for a week is also a problem
<infinity> Yeah, I don't disagree with that assertion.
<slangasek> infinity: they wouldn't need to compete, they would each take the lock first before syncing... and a bit of extra time spent checking that there's nothing to sync is surely better in the general case than having the last-scheduled livefs build wind up with a non-matching apt pool, say
<cjwatson> You could easily have been confused in six months instead when nusakan ran out of disk space.
<slangasek> heh
<slangasek> yes, timeout would also be good
<infinity> slangasek: But we also want consistency through the life of a build.  by-hash doesn't actually solve that.
<infinity> slangasek: As in, if I germinate against the archive, then you update it, then I do debian-cd things against the new archive, Packages has changed.
<slangasek> infinity: --no-delete sync + byhash does, surely?
<slangasek> ah
<slangasek> because there's no build-local apt cache
<slangasek> ho-hum
<infinity> Right, by-hash only solves a world where you apt-get update once and never again, and that's your authoritative source for all things.
<cjwatson> I think the bit that failed to time out here is probably tracker_set_rebuild_status.
<infinity> But we operate directly on the Packages files, not an apt list archive.
<cjwatson> Since there was lots of other failed-to-contact-tracker noise around the same time.
<slangasek> infinity: ok
<infinity> Anyhow, I do agree that not noticing a stuck build is really the more interesting problem. :P
<cjwatson> So maybe that's enough information for somebody to insert a timeout.
<cjwatson> Also perhaps there should be a watchdog of some kind for the whole build.
<santa_> infinity: last patch I pasted works, I will try convince someone to sponsor the upload, any objections?
<cjwatson> cdimage.osextras.run_bounded exists already; not sure what would happen if you tried running the entire build inside it, but it's perhaps worth trying.
<infinity> santa_: That looks good to me, indeed.
<cjwatson> (Or indeed cdimage/bin/kill-after, for crontab purposes)
<cjwatson> Probably better for cdimage.build to apply it to itself though, if you're taking that route
 * infinity thinks it might be shawarma time.
<slangasek> http://www.shawarmageddon.com/
<infinity> slangasek: I... Just.... Wow.  Road trip?
<slangasek> I was mad to learn that Reno got that name before Portland managed to
<infinity> slangasek: I've never considered Reno cool in any way, this is upsetting my world view.
 * infinity -> food.
<cjwatson> Mine's a falafel wrap and a crimson death.  I accept deliveries.
-queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-meta (yakkety-proposed/universe) [0.68 => 0.69] (ubuntugnome)
 * xnox spies with a little eye a working kernel
<tsimonq2> xnox: good stuff!
-queuebot:#ubuntu-release- Unapproved: debian-installer (yakkety-proposed/main) [20101020ubuntu474 => 20101020ubuntu475] (core)
 * tsimonq2 spots with a little eye an email with the subject "[yakkety] linux 4.8.0-14.15 uploaded (ABI bump)"
<xnox> slangasek, infinity - debian-installer uploaded, diff already generated.
<xnox> please accept and then i'll test the d-i bits as soon as they are built on s390x. then it should be good to go.
<tsimonq2> somebody should change the topic here
<tsimonq2> s/beta 1/final beta/
<marco-parillo> I see the first release candidates for Beta 2 are up. http://iso.qa.ubuntu.com/qatracker/milestones/367/builds I have tested the live ISO. How likely will there be a re-spin tomorrow? That way I reduce the number of installs I try.
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (yakkety-proposed) [20101020ubuntu475]
<slangasek> xnox: done
* slangasek changed the topic of #ubuntu-release to: Released: Trusty 14.04.5, Xenial 16.04.1 | Archive: feature freeze, final beta freeze | Yakkety Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis
<slangasek> marco-parillo: likely
#ubuntu-release 2016-09-22
<marco-parillo> TY
 * xnox emerges from bubble bath, just in time for hot chocolate and fresh d-i
<xnox> so nice accepted queue allows downloads
<xnox> Apart from:
<xnox> Sep 21 19:25:00 debootstrap: dpkg: warning: parsing file '/var/lib/dpkg/status' near line 4 package 'dpkg':
<xnox> Sep 21 19:25:00 debootstrap:  missing description
<xnox> Sep 21 19:25:00 debootstrap: dpkg: warning: parsing file '/var/lib/dpkg/status' near line 4 package 'dpkg':
<xnox> Sep 21 19:25:00 debootstrap:  missing maintainer
<xnox> Sep 21 19:25:00 debootstrap: dpkg: warning: parsing file '/var/lib/dpkg/status' near line 4 package 'dpkg':
<xnox> Sep 21 19:25:00 debootstrap:  missing architecture
<xnox> things look fine....
<infinity> That's normal.
<infinity> debootstrap fakes the dpkg entry on the first pass.
<xnox> ah.
<xnox> maybe it should fake better?! =)
<xnox> nevermind.
<slangasek> cjwatson, infinity: not sure how long it's sensible for a livefs build to be paused at 'remove-build', but: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/yakkety/ubuntustudio/+build/76157
<xnox> infinity, slangasek - 4.8.0-14.15 is good, and debian-installer 20101020ubuntu475 are good. Did automated preseed install in z/vm. Will do another one in an LPAR now.
<xnox> on s390x that is.
<infinity> slangasek: It's not paused at remove-build.
<infinity> slangasek: Note that it's already got the full build log, it's just sucking down the livefs.
<slangasek> k
<infinity> slangasek: Which can take a while, depending on network oddities.
<infinity> (Admittedly, I've been annoyed by how we don't give reasonable feedback there either)
<infinity> It should probably not show the log tail at all, and be in a "downloading results" state or something.
-queuebot:#ubuntu-release- Unapproved: fruit (yakkety-proposed/universe) [2.1.dfsg-6 => 2.1.dfsg-7] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted fruit [sync] (yakkety-proposed) [2.1.dfsg-7]
<infinity> That's a state that used to last under a minute for most builds, so no one really noticed, but with ddebs and livefses and builders in other DCs, etc, things can seem "hung" there for a very long time, and it's certainly not intuitive.
-queuebot:#ubuntu-release- Unapproved: openbabel (yakkety-proposed/universe) [2.3.2+dfsg-2.3 => 2.3.2+dfsg-2.4] (kubuntu) (sync)
<slangasek> infinity: clearly we should switch to using rsync for copying the livefses out of the builders
<infinity> I suppose we could actually use zsync, if we could reliably identify an ancestor.
<infinity> And if twisted's httpd supports range requests.
<slangasek> ok I should stop nerdsniping infinity
<xnox> meanwhile lpar install works too
 * xnox -> Zzzzz
<infinity> xnox: Excellent, thanks for testing.
<infinity> Will wait for more autopkgtest love and then let that kernel/d-i through.
<mwhudson> infinity: twistd's http server does support range requests! i implemented it!
<mwhudson> for static.Files anyway
<mwhudson> can someone release docker.io from xenial NEW? (there is a new docker-doc package)
<xnox> does zope support http/2 ?
<mwhudson> xnox: i don't think zope implements http itself, so that's really a question about whatever it's using for that
<mwhudson> (and i don't know what that is)
<infinity> mwhudson: That may prove useful to know some day.
<mwhudson> not for me i hope :)
-queuebot:#ubuntu-release- Unapproved: xfce4-session (yakkety-proposed/universe) [4.12.1-3ubuntu2 => 4.12.1-3ubuntu3] (xubuntu)
<mwhudson> oh, the Range header support?
<infinity> mwhudson: Yeah.
<mwhudson> it was part of a secret plan to not use apache for bazaar.launchpad.net that never really got anywhere
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Yakkety Beta 2] (20101020ubuntu475) has been added
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Yakkety Beta 2] (20101020ubuntu475) has been added
-queuebot:#ubuntu-release- Builds: Netboot armhf [Yakkety Beta 2] (20101020ubuntu475) has been added
-queuebot:#ubuntu-release- Builds: Netboot i386 [Yakkety Beta 2] (20101020ubuntu475) has been added
-queuebot:#ubuntu-release- Builds: Netboot powerpc [Yakkety Beta 2] (20101020ubuntu475) has been added
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Yakkety Beta 2] (20101020ubuntu475) has been added
-queuebot:#ubuntu-release- Builds: Netboot s390x [Yakkety Beta 2] (20101020ubuntu475) has been added
<Ukikie> If anyone asks, Xubuntu does not need a respin for the xfce4-session upload.
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Yakkety Beta 2] (20160921.2) has been added
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Yakkety Beta 2] has been updated (20160921.2)
<infinity> Ukikie: No, but you'll get one for a new kernel.
<Ukikie> infinity: And you really think we need a newer one?  I was considering dropping it, we don't need any kernels!
<Ukikie> OK, I'll go somewhere else now..
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.18]
-queuebot:#ubuntu-release- Unapproved: cups (yakkety-proposed/main) [2.2.0-1 => 2.2.0-2] (core) (sync)
<Ukikie> infinity: Been presuming syncing gcalcli would be too late at this point, right?
-queuebot:#ubuntu-release- Unapproved: gnome-multi-writer (yakkety-proposed/universe) [3.21.92-1 => 3.22.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-multi-writer [sync] (yakkety-proposed) [3.22.0-1]
-queuebot:#ubuntu-release- Unapproved: flatpak (yakkety-proposed/universe) [0.6.10-1 => 0.6.11-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted flatpak [sync] (yakkety-proposed) [0.6.11-1]
-queuebot:#ubuntu-release- Unapproved: linuxinfo (yakkety-proposed/universe) [2.4.1-1 => 2.4.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted linuxinfo [sync] (yakkety-proposed) [2.4.2-1]
<pitti> slangasek, cyphermox, lamont: meh, seems nobody else reviewed the changes over night; FWIW, not too happy about using isc-dhcp in the initrd for this (longer-term I think we want to run netplan/networkd from the initrd already), and it's awfully late/intrusive for the beta, but having it do the exercises in -proposed is okay still
-queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (yakkety-proposed) [4.3.3-5ubuntu14]
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (yakkety-proposed) [0.125ubuntu4]
-queuebot:#ubuntu-release- Unapproved: rejected cups [sync] (yakkety-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- Unapproved: rejected cups [sync] (yakkety-proposed) [2.2.0-2]
<infinity> pitti: Does networkd also require systemd?
<infinity> pitti: Cause I'm pretty opposed to the dracut solution of a full blown init in the initrd.
<pitti> infinity: no, it doesn't
<infinity> What's the big complaint about dhclient, other than the random grumblings about speed?
<infinity> It does a better job at being standards-compliant than just about anything else, at least.
<pitti> infinity: mostly just that we are just moving away from it on server/cloud at least
<pitti> (and upstream NM as well)
<pitti> and for things like open-iscsi it makes much more sense to configure stuff once rather than these eternal special snowflake code in initrd
<pitti> infinity: anyway, wrt. coordinating this with beta -- do you want me to unblock/land this as soon as britney is content with it?
<pitti> (I hope it was tested with netboot)
<infinity> pitti: I'll be around for a bit, babysitting some kernel migration, so let me know when it looks goodish, and we'll make a call then.
<pitti> cyphermox: why hooks/zz-dhclient btw? I don't see a particular reason why this needs to run after zz-busybox-initramfs, particular as that one documents that it wants to be last
<Skuggen> pitti: Hi
<pitti> hey Skuggen
<Skuggen> pitti: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mysql-5.7 I think the two in progress runs are stuck. Any tips on what I should do?
<Skuggen> They're both (always failed)
<pitti> Skuggen: yes, please just ignore them -- they are blacklisted as they break s390x testbeds, and britney ignores them
<pitti> Skuggen: it's fine to land, other than the beta freeze block
<Skuggen> Ah, then I guess I should request an unblock for it. It's got an important security update
<pitti> meh, new kernel consistently breaks systemd's tests now
<doko> infinity: is there a chance to rebuild the chroot images for yakkety?
<doko> pitti: same for the autopkg test images now that linux 4.8 is in?
<pitti> doko: how do you mean?
<pitti> tests run with 4.8 now, yes
<pitti> (as soon as it landed)
<doko> The following packages were automatically installed and are no longer required:
<doko>   linux-headers-4.4.0-9136 linux-headers-4.4.0-9136-generic
<doko> Use 'apt autoremove' to remove them.
<pitti> yeah, that'll go away as soon as the next cloud image gets built
<doko> ahh, ok
<pitti> I use whichever is most recent and then dist-upgrade and reboot
-queuebot:#ubuntu-release- Unapproved: stress-ng (yakkety-proposed/universe) [0.06.16-1 => 0.06.17-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted stress-ng [sync] (yakkety-proposed) [0.06.17-1]
-queuebot:#ubuntu-release- Unapproved: ldb (yakkety-proposed/main) [2:1.1.26-1ubuntu4 => 2:1.1.26-1ubuntu5] (core)
-queuebot:#ubuntu-release- Unapproved: accepted ldb [source] (yakkety-proposed) [2:1.1.26-1ubuntu5]
<sakrecoer> thankd slangasek and infinity :) the ubuntu studio iso seems to be build and in the tracker now \o/
-queuebot:#ubuntu-release- Unapproved: pygobject (yakkety-proposed/main) [3.21.92-1 => 3.22.0-1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: khtml (yakkety-proposed/universe) [5.24.0-0ubuntu2 => 5.24.0-0ubuntu3] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: libabw (yakkety-proposed/main) [0.1.1-2ubuntu2 => 0.1.1-4ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: wine (yakkety-proposed/universe) [1.8.4-1ubuntu1 => 1.8.4-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted wine [source] (yakkety-proposed) [1.8.4-1ubuntu2]
<flexiondotorg> infinity, You available to talk yaboot?
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/yaboot/+bug/1606089
<ubot5`> Ubuntu bug 1606089 in yaboot (Ubuntu) "unable to boot after 'entire disk' install (16.10, ppc)" [Undecided,Confirmed]
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1607128
<ubot5`> Ubuntu bug 1607128 in ubiquity (Ubuntu) "'entire disk' install crashes (16.10, ppc)" [Undecided,New]
<flexiondotorg> I notice yaboot has in excuses and has been for some months.
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1607128
<ubot5`> Ubuntu bug 1607128 in ubiquity (Ubuntu) "'entire disk' install crashes (16.10, ppc)" [Undecided,New]
<flexiondotorg> https://launchpadlibrarian.net/282065209/buildlog_ubuntu-yakkety-powerpc.yaboot_1.3.17-2ubuntu1_BUILDING.txt.gz
<flexiondotorg> http://metadata.ftp-master.debian.org/changelogs//main/y/yaboot/yaboot_1.3.17-4_changelog
<infinity> flexiondotorg: Yeah, I need to fix one of yaboot's build-deps.  It's not been the top of my list, but will do.
<flexiondotorg> Anything I can do to help?
<infinity> Probably not.
<infinity> It's ultimately a dpkg bug.  But I might work around it elsewhere for now to unstick all that.
<flexiondotorg> OK
<acheronuk> khtml is in the upload queue, but unapproved. I assume that will eventually go in when things unfreeze?
-queuebot:#ubuntu-release- New binary: wine [amd64] (yakkety-proposed/universe) [1.8.4-1ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-meta [source] (yakkety-proposed) [0.69]
<pitti> cyphermox, infinity: FTR, the multipath-tools test with/for the new initramfs-tools consistently breaks networking on rebooting the test instances; that's why the test is just looping and never finishes
<pitti> happens on all three clouds and arches
<infinity> pitti: Fun...
-queuebot:#ubuntu-release- Unapproved: accepted khtml [source] (yakkety-proposed) [5.24.0-0ubuntu3]
<pitti> so if you are sure that this doesn't break stuff (particularly things like iscsi), we can certainly override it, but I'd like to get some more "it works!" and "yes, force everything into the beta" confirmation
<infinity> pitti: Yeah, I'm not convinced myself yet either.
-queuebot:#ubuntu-release- Unapproved: accepted xfce4-session [source] (yakkety-proposed) [4.12.1-3ubuntu3]
 * pitti runs it again without -proposed on the infra, maybe it's the new kernel too (that already caused at last three regressions, wouldn't totally surprise me)
-queuebot:#ubuntu-release- Unapproved: accepted qemu [source] (yakkety-proposed) [1:2.6.1+dfsg-0ubuntu4]
<davmor2> infinity, cyphermox: did you manage to resolve the policykit issue that was stopping 3rd party drivers installing?
<infinity> davmor2: I'm not sure I was aware of the issue to start with.
<davmor2> infinity: but I tagged you in on the bug report yesterday and everything ;) https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1626108
<ubot5`> Ubuntu bug 1626108 in ubiquity (Ubuntu) "Ubiquity session isn't setting up 3rd party hardware drivers" [Undecided,New]
<davmor2> infinity: critical regression
-queuebot:#ubuntu-release- Unapproved: docker.io (xenial-proposed/universe) [1.12.1-0ubuntu7~16.04 => 1.12.1-0ubuntu12~16.04] (no packageset)
<pitti> apw: I found out the cause of bug 1626394 -- 4.8 dropped CONFIG_ATA=y and now builds them as a module; that means that we now *always* require an initrd to boot
<ubot5`> bug 1626394 in systemd (Ubuntu) "4.8 dropped CONFIG_ATA=y (breaks systemd's TEST-08-ISSUE-2730 upstream test)" [Undecided,In progress] https://launchpad.net/bugs/1626394
<pitti> apw: from a POV of "don't break existting installs" and boot speed POV I don't think this is desireable
<pitti> apw: was that a deliberate policy decision (must have initrd), or an error? i. e. shoudl the linux task be "wontfix" or triaged?
<apw> pitti, i am inclined to say that was an error, especially if something is relying on it
<apw> pitti, in general we have always said (in my opinion) in ubuntu that an initrd is "required" but ... making life hard is also undesirable
<pitti> we certainly do install one by default (well, not sure about snappy, but I figure it does too), but so far you could actually boot without one just fine
<pitti> and conceptually, > 95% of installations (especially if you count in cloud instances) really don't need one
<apw> pitti, right on a very limited subset of hardware which likely includes some virtual hardware ... i think that one is wrong regardless of why it was done
<apw> pitti, though cloud h/w needs virtio instead in the main, but anyhow, i've added that issue to the pile
<pitti> apw: you need an initrd with encrypted root and for zfs and the like; and for root= with a UUID/label (which is simple enough to switch off while you disable initrd)
<pitti> apw: yeah, I didn't check which additional drivers beyond CONFIG_ATA are required; I figure at least some CONFIG_PATA_* ones
<apw> pitti, yep, i am pretty sure we claim you always need it, and are wrong, and we definaly made it worse and we very likley should not
<pitti> although the only one that we enabled in 4.4 was CONFIG_PATA_SIS=y
<apw> a long time back we picked 4 which were the most common to build in, so i think we should be making sure that list is the same
<apw> pitti, i've hijacked your bug adding that request
<pitti> apw: virtio certainly does sound interesting; the initrd is one of the biggest chunks of wasted time in cloud instances (bug 1592684)
<ubot5`> bug 1592684 in cloud-init (Ubuntu) "Add MODULES=dep initramfs configuration" [Wishlist,Triaged] https://launchpad.net/bugs/1592684
<pitti> apw: please do,  it's meant to be used as a kernel bug, unless you would say "it's intended, deal with it"
<pitti> apw: happy to close the systemd task as wontfix and keep the britney override on amd64 until then
<apw> pitti, i think we're in the wrong here, but if not i'll get back to you.  i see a beta + day 0 kernel in our future, especially if we nail this kworker thing today
<pitti> apw: yeah, not that urgent; it was hidden behind another regression in the systemd tests, so I didn't see it until today
<pitti> apw: i. e. this is absolutely not beta critical
<apw> pitti, ack on that ...
<infinity> pitti: We've had a lot of discussions about minimizing or removing the initrd, but it's certainly current Ubuntu policy that one is required, and you're on your own if you go without.
<infinity> And there's always an annoying balance between what you build in to allow initrdless and what's bloat to people who don't need it.
<pitti> infinity: yes, I know; hence I was asking whether that was an explicit policy change now
<apw> pitti, and we might come back and say that but i do not recall us changing the default set this cycle
<pitti> apw: thanks; let me know, if you wontfix the linux task, I'll change the qemu tests in systemd to cope (and force an initrd)
<pitti> i. e. I'm not worried much about these tests themselves, more like the effect of actually breaking boot without initrd
<pitti> cyphermox: multipath-tools still tests fine in y-release (without -proposed), so definitively some regression there and not the kernel
-queuebot:#ubuntu-release- Unapproved: kboot-installer (yakkety-proposed/main) [0.0.1ubuntu9 => 0.0.1ubuntu10] (core)
<lamont> pitti: infinity: I know that I have used it to netboot maas images, and I plan to roll things from yakkety-proposed this AM once I actually hit the office
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-15.16] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: emacs24 (yakkety-proposed/main) [24.5+1-6ubuntu3 => 24.5+1-7ubuntu1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gcc-snapshot (yakkety-proposed/universe) [20160902-1ubuntu1 => 20160922-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-snapshot [source] (yakkety-proposed) [20160922-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: software-properties (yakkety-proposed/main) [0.96.24.6 => 0.96.24.7] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-15.16]
<tkamppeter> I have a problrm with syncpackage. Itry to sync the bugfix-patched cups 2.2.0-2 into yakkety, syncpackage accepts without error message but I do not get a mail telling that it was uploaded to yakkety-proposed, no moderator approval-needed nor rejection. And I can repeat the syncpackage without error messages that I have already done it.
<tkamppeter> How do I get this bug fix into yakkety?
<infinity> tkamppeter: It's in the queue, it's just a bug that you don't get mails on copies.
<infinity> https://launchpad.net/ubuntu/yakkety/+queue?queue_state=1&queue_text=
<tkamppeter> infinity, so it is waiting for approval now due to the fact that we are after beta freeze?
<infinity> tkamppeter: Yeahp.
-queuebot:#ubuntu-release- Unapproved: cups (yakkety-proposed/main) [2.2.0-1 => 2.2.0-2] (core) (sync)
<tkamppeter> infinity, thanks, seems all OK then. Seems that I have to open this channel before syncing to get an confirmation message.
<tkamppeter> infinity, will the mail notifications get fixed soon?
<infinity> tkamppeter: It's been a bug for years, so I doubt it. :P
<infinity> tkamppeter: Also, rejecting one of those, cause we don't need two. :)
<tkamppeter> infinity, I got mail notifications on syncs up to some days ago.
<infinity> tkamppeter: The bug is a lack of mail notification when a sync is held in a queue (ie: new or unapproved)
<infinity> tkamppeter: You get a mail when it's accepted.
-queuebot:#ubuntu-release- Unapproved: rejected cups [sync] (yakkety-proposed) [2.2.0-2]
<tkamppeter> infinity, the additional sync now was simply a test to see what happens.
<tkamppeter> infinity, OK, then I know that all is OK. Thanks.
-queuebot:#ubuntu-release- Unapproved: debian-installer (yakkety-proposed/main) [20101020ubuntu475 => 20101020ubuntu476] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (yakkety-proposed) [20101020ubuntu476]
<xnox> because efi =) lovely
<pitti> oh, that would explain why I'm chasing ever-looping tests because of reboot failures
 * pitti already has wondered why yakkety tests seem to crumble away like mad
<pitti> hm, acually not that, ubuntu/ubuntu-yakkety-daily-amd64-server-20160918-disk1.img just genuinely refuses to boot on lcy01
<davmor2> pitti: in kvm with uefi the latest images refuse to boot it looks to me like it is trying to boot from BOOTx64.efi which then produces a black screen and nothing else
<davmor2> pitti: grubx64.efi if I select boot from file just does nothing with secureboot enabled I need to disable secureboot and then sometimes you'll get lucky and it will boot
<davmor2> pitti: yey on hardware it boots, however digging into issue I just noticed that there is no EFI entry for the installed system so cyphermox and co won't be too happy
<xnox> pitti, davmor2 you did notice https://launchpad.net/ubuntu/+source/linux/4.8.0-15.16 published two hours ago with EFI boot fix for bug #1626158
<ubot5`> bug 1626158 in cloud-images "image won't boot after upgrading to yakkety's 4.8 kernel because efi" [Critical,Confirmed] https://launchpad.net/bugs/1626158
<xnox> together with d-i in proposed
<davmor2> xnox: checking to see if there is a current image with it on
<davmor2> xnox: so it isn't on the current images yet which is why I still see it then
<xnox>  /o\
<xnox> Odd_Bloke, can you pre-respin cloudimages with yakkety-proposed kernel by any chance?
 * xnox will pronounce EFI as iffy from now on
<davmor2> xnox: oh hang on is it only in proposed?
<xnox> davmor2, fixed one, yeah.
<pitti> xnox: hmm, for me it's that they don't get any DHCP response, so I suppose that's something else
<davmor2> xnox: okay let me grab that image then
<xnox> davmor2, /me is talking about kernel package, no idea about cloudimages....
<davmor2> xnox: I was grabbing from current which is what we test for release
<davmor2> xnox: oh so might not of hit the cdimage infrastructure at all then
<xnox> davmor2, check manifests of packages to see what it has.
<xnox> well, kernel must be published and migrate to release; then images are usually respun to include things.
<davmor2> xnox: on cdimage proposed we have linux-generic-4.8.0-11.12
<davmor2> xnox: yeah only I think it has to be manually now because of the freeze infinity would know though
<infinity> davmor2: Yeah, new images with the new kernel will happen in a couple of hours, likely.
<pitti> oh, kernel 4.8 just boot slooooooooow in scalingstack as well apparently
<pitti> sorry, don't rely on getting any testing results soon; I'm fighting broken 4.8, broken images, and broken networking
<pitti> i. e. if you want to land the -proposed kernel soon, force it in
<infinity> pitti: I was hoping to see *some* results (ie: to prove it installs and boots), but was indeed planning to skip most of the testing based on visual review of the delta.
<pitti>       ââcloud-init.service @9.467s +1min 55.581s
<pitti> so what's that now
<Odd_Bloke> xnox: infinity: AFAIK, we're waiting for the new kernel to land to announce beta cloud images.
<infinity> Odd_Bloke: Do you need the new cloud-init too?
<infinity> Oh, I see, that's tied up with the initramfs-tools changes we might not land.
<Odd_Bloke> infinity: I didn't know about the new cloud-init, but it sounds like you do. :p
<xnox> Odd_Bloke, server/desktop/d-i are yet to be fully published, or boot tested.
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Yakkety Beta 2] has been updated (20101020ubuntu476)
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Yakkety Beta 2] has been updated (20101020ubuntu476)
-queuebot:#ubuntu-release- Builds: Netboot armhf [Yakkety Beta 2] has been updated (20101020ubuntu476)
-queuebot:#ubuntu-release- Builds: Netboot i386 [Yakkety Beta 2] has been updated (20101020ubuntu476)
-queuebot:#ubuntu-release- Builds: Netboot powerpc [Yakkety Beta 2] has been updated (20101020ubuntu476)
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Yakkety Beta 2] has been updated (20101020ubuntu476)
-queuebot:#ubuntu-release- Builds: Netboot s390x [Yakkety Beta 2] has been updated (20101020ubuntu476)
<pitti> infinity: some results are coming in now
<pitti> infinity: note "Unblock request by adconrad ignored due to version mismatch: 4.8.0.14.23"
<infinity> pitti: Right, I haven't unblocked the new one yet. :P
-queuebot:#ubuntu-release- Unapproved: attica-kf5 (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: bluez-qt (yakkety-proposed/universe) [5.24.0-0ubuntu2 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: baloo-kf5 (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: breeze-icons (yakkety-proposed/universe) [4:5.24.0-0ubuntu1 => 4:5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: frameworkintegration (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kactivities-stats (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: karchive (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kbookmarks (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kcodecs (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kconfig (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: extra-cmake-modules (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kapidox (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kcmutils (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kconfigwidgets (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kactivities-kf5 (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kcompletion (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kauth (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kcoreaddons (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdbusaddons (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kded (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdesignerplugin (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdewebkit (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kcrash (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdelibs4support (yakkety-proposed/universe) [5.24.0-0ubuntu2 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdeclarative (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdesu (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdnssd-kf5 (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kemoticons (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kglobalaccel (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: khtml (yakkety-proposed/universe) [5.24.0-0ubuntu3 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kiconthemes (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kimageformats (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kio (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kitemviews (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kjs (yakkety-proposed/universe) [5.24.0-0ubuntu4 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdoctools (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kguiaddons (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kidletime (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kitemmodels (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kfilemetadata-kf5 (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kinit (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ki18n (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kjobwidgets (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kjsembed (yakkety-proposed/universe) [5.24.0-0ubuntu2 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: knewstuff (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: knotifyconfig (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kparts (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kplotting (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kross (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kservice (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ktextwidgets (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kwallet-kf5 (yakkety-proposed/universe) [5.24.0-0ubuntu2 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kwidgetsaddons (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kmediaplayer (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kpackage (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kpty (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ktexteditor (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kwayland (yakkety-proposed/universe) [4:5.24.0-0ubuntu1 => 4:5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: knotifications (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: krunner (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kwindowsystem (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kpeople (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kunitconversion (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kxmlgui (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: modemmanager-qt (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: oxygen-icons5 (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: solid (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: threadweaver (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kxmlrpcclient (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: plasma-framework (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: networkmanager-qt (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: sonnet (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
<cyphermox> davmor2: so you were saying that sometimes you managed to boot the installer in EFI?
<davmor2> cyphermox: on hardware I can on kvm I can't
<cyphermox> (or always just a black screen? seems like more likely that it never boots, and always gives you black
<cyphermox> I can't here on my Thinkpad.
<cyphermox> my screen isn't black, but that's because I have shim debugging enabled
<davmor2> I have to select the grubx64.efi file, if it boots from the bootx64.efi it just locks up
<shadeslayer> clivejo: ^^ you'll need to talk to the release team to get the frameworks approved
<clivejo> I thought the FFe was approved?
<cyphermox> davmor2: how do you select the grubx64.efi file??
<cyphermox> do you mean you get dropped to the EFI Shell and then go boot?
<davmor2> cyphermox: boot from file in efi
<cyphermox> is that in a VM or in hardware?
<cyphermox> I'm guessing Dell hardware?
<davmor2> cyphermox: hardware, it's a temp thing, you just setup a connection call grub.efi and point it at the usb pendrive \EFI\boot\grubx64.efi save it and then boot from that
<cyphermox> ok
<cyphermox> alright, that confirms to be you can't boot the image at all
<davmor2> \o/
<cyphermox> ie. if you could by using bootx64.efi in some other weird way, it would mean I have two issues to deal with in shim rather than just one.
<davmor2> cyphermox: by the way what changed between Thursday and now to break it all?
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Yakkety Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Yakkety Beta 2] has been marked as ready
<cyphermox> davmor2: did the booting thing really only change on thursday? I expect it's broken since the last shim upload.
<cyphermox> so, looks like since about 2016-08-08
<davmor2> cyphermox: I had thursdays image installed on kvm and hardware with no monkeying about let me see if it is still on the server and test it
<cyphermox> I have Sep 8 too I can give that a shot
<cyphermox> otoh, even if that's the case, shim is clearly broken. the bug was clearly identified and is fixed upstream, etc.
<acheronuk> clivejo: https://bugs.launchpad.net/ubuntu/+source/plasma-desktop/+bug/1625392/comments/5
<ubot5`> Ubuntu bug 1625392 in plasma-desktop (Ubuntu) "[FFe] KDE Frameworks 5.26.0 into the Yakkety Archive" [Undecided,Triaged]
<acheronuk> so what else does the release team need?
-queuebot:#ubuntu-release- Unapproved: python-pip (xenial-proposed/universe) [8.1.1-2ubuntu0.2 => 8.1.1-2ubuntu0.3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: flashcache (yakkety-proposed/universe) [3.1.3+git20150701-4 => 3.1.3+git20150701-4ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted flashcache [source] (yakkety-proposed) [3.1.3+git20150701-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: kboot-installer (yakkety-proposed/main) [0.0.1ubuntu9 => 0.0.1ubuntu10] (core)
<gQuigs> hi there, I think this bug https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/1575614 is blocking a new network-manager from landing in xenial
<ubot5`> Ubuntu bug 1575614 in network-manager (Ubuntu Xenial) "[SRU]Can't select secret key for TLS auth for 802.1X authentication" [Low,Fix committed]
-queuebot:#ubuntu-release- Unapproved: gnome-chess (yakkety-proposed/universe) [1:3.21.90-1 => 1:3.22.0-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: gnome-tetravex (yakkety-proposed/universe) [1:3.21.90-1 => 1:3.22.0-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: quadrapassel (yakkety-proposed/universe) [1:3.21.90-1 => 1:3.22.0-1] (desktop-extra) (sync)
<gQuigs> should that specific patch just be reverted?
-queuebot:#ubuntu-release- Unapproved: libphonenumber (yakkety-proposed/universe) [7.1.0-4ubuntu1 => 7.1.0-5ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: mediaplayer-app (yakkety-proposed/universe) [0.20.5+16.04.20160428-0ubuntu1 => 0.20.5+16.10.20160921-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-keyboard (yakkety-proposed/universe) [0.100+16.10.20160818-0ubuntu1 => 0.100+16.10.20160921-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted mediaplayer-app [sync] (yakkety-proposed) [0.20.5+16.10.20160921-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: bluez-qt (yakkety-proposed/universe) [5.24.0-0ubuntu2 => 5.26.0-0ubuntu1] (kubuntu)
<wxl> we getting rebuilds?
<ginggs> Would someone please approve the arch:amd64 and arch:all wine packages in yakkety NEW?
<wxl> s/build/spin/
<jderose> infinity: i didn't find any existing bug about this, but the Yakkety Server ISO is having troubles, doesn't find the cdrom/iso - https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1626622
<ubot5`> Ubuntu bug 1626622 in debian-installer (Ubuntu) "yakkety server: fails to detect and mount CD-ROM" [Undecided,New]
<wxl> oh jeez. this is going to be a fun day.
<jderose> wxl: isn't every day a fun day? :P
<wxl> jderose: oh yeah. it's extra special when you walk into work and the power's been down long enough to make the power supplies flip out >:(
<wxl> s/power supply/ups/
<wxl> meanwhile we have impending respins (supposedly)
<wxl> every freaking package known to man seems to be broken XD
<wxl> and now the server! aigh
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-39.59] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-39.59]
<slangasek> jderose: that image shows as having the 4.8.0-11 kernel in the package pool; a rebuild of that image should fix it; I'm not sure if one is scheduled, checking before I kick one off
<jderose> slangasek: cool, thanks! just wanted to make sure ya'll were aware of it at least, if you weren't already :)
<nacc> so i sponsored an upload of a fix for python-django (1.8.7-1ubuntu7), i got an e-mail back saying it was 'waiting for approval', but i'm not sure where to look for it, and the link in the e-mail (https://launchpad.net/ubuntu/+source/python-django/1.8.7-1ubuntu7) doesn't seem to exist
<slangasek> ok, no rebuild currently running, and no mention by infinity of a respin schedule in scrollback afaics, so I'll go ahead and kick off a rebuild now
<slangasek> jderose: fwiw the image you just tested also has not been promoted to 'current'
<slangasek> nacc: https://launchpad.net/ubuntu/yakkety/+queue
<wxl> slangasek: there was some discussion about a respin yesterday but no particulars mentioned yet
<jderose> slangasek: ah, i guess it hasn't. i was misled by the timestamps here - http://cdimages.ubuntu.com/ubuntu-server/daily/
<nacc> slangasek: ah ha! i think i must have typo'd before, i did search unapproved before, thanks! so at this point, is it just timing due to the beta freeze? or what's the normal process?
<slangasek> nacc: timing for beta freeze, yes; if you think this is a change that should land in beta (because it's somehow beta relevant), or you think it's particularly low risk despite being on the CD, ask the release team to let it through
<nacc> slangasek: got it, thanks
<nacc> jgrimm: --^
<jgrimm> slangasek, nacc:  there is no pressing need for that fix in the beta.  low risk, but i'm not convinced worth your time vs getting beta out the door
<slangasek> jgrimm, nacc: the queue has to be flushed at some point, and apw reminded me there's also a proposed-migration block. I've accepted it now
-queuebot:#ubuntu-release- Unapproved: accepted python-django [source] (yakkety-proposed) [1.8.7-1ubuntu7]
<jgrimm> slangasek, cool cool. thanks
<nacc> slangasek: thanks
-queuebot:#ubuntu-release- Unapproved: account-plugins (yakkety-proposed/main) [0.13+16.10.20160830.1-0ubuntu1 => 0.13+16.10.20160831-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-system-settings-online-accounts (yakkety-proposed/universe) [0.7+16.10.20160718-0ubuntu1 => 0.7+16.10.20160830.2-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: signon-plugin-oauth2 (yakkety-proposed/main) [0.23+16.04.20151209-0ubuntu1 => 0.24+16.10.20160818-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: libertine (yakkety-proposed/main) [1.4+16.10.20160908-0ubuntu1 => 1.4.1+16.10.20160914-0ubuntu1] (no packageset) (sync)
<flocculant> infinity: just so you are aware, just talked with bluesabre (our tech lead and council chair) we are definitely NOT releasing this beta
<flocculant> and he's marked the bug critical
<apw> flocculant, could you drop the bug number in here next to that statement for the logs
<flocculant> bug 1622303
<ubot5`> bug 1622303 in light-locker (Ubuntu) "Fails to unlock/ resumes to black screen" [Critical,Confirmed] https://launchpad.net/bugs/1622303
<flocculant> :)
<flocculant> apw: one of those bugs I remember the number for currently and assume everyone knows exactly what I'm talking about :p
-queuebot:#ubuntu-release- Unapproved: accepted cups [sync] (yakkety-proposed) [2.2.0-2]
-queuebot:#ubuntu-release- Unapproved: accepted python-pbr [source] (yakkety-proposed) [1.10.0-0ubuntu1]
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Yakkety Beta 2] has been updated (20160922)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Yakkety Beta 2] has been updated (20160922)
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Yakkety Beta 2] has been updated (20160922)
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Yakkety Beta 2] has been updated (20160922)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Yakkety Beta 2] has been updated (20160922)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Yakkety Beta 2] has been updated (20160922)
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Yakkety Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Yakkety Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop powerpc [Yakkety Beta 2] has been marked as ready
<slangasek> jderose: confirmed that the 20160922 ubuntu-server image has the correct kernel udebs in it; it has not been promoted yet to 'current', so smoketests are probably still running
<jderose> slangasek: awesome, thank you very much!
<jderose> slangasek: out of curiosity, how are these smoketests run? under QEMU, etc?
<slangasek> jderose: ah, jibel would have the details
<cyphermox> jderose: wanna test a fixed up shim (but unsigned, so it won't work with Secure Boot enabled)?
<jderose> jibel: how are the smoketests run? also, is the code for them publicly available?
<jderose> cyphermox: heck yeah i want to test it! :D
<cyphermox> https://launchpad.net/~canonical-foundations/+archive/ubuntu/shim/+files/shim_0.9+1474479173.6c180c6-0ubuntu1~mtrudel1_amd64.deb
<cyphermox> jderose: essentially the tests are run in VMs spun up with a custom test harness
<jderose> cyphermox: ah, so a deb... what's the best way to remaster an iso to update just this package?
<cyphermox> I would open it in file-roller and just go get the shimx64.efi file in /usr/lib/shim
<cyphermox> then replace just that file in the iso image
<jderose> cyphermox: okay, thanks. didn't know file-roller could do that. i've been using isomaster to add fallback.efi
<cyphermox> jderose: the smoketests code is available, let me get you the link
-queuebot:#ubuntu-release- Unapproved: accepted kbd [source] (xenial-proposed) [1.15.5-1ubuntu5]
-queuebot:#ubuntu-release- Unapproved: accepted klibc [source] (xenial-proposed) [2.0.4-8ubuntu1.16.04.2]
<cyphermox> jderose:  lp:ubuntu-test-cases/server
<jderose> cyphermox: awesome, thanks! and i'll get to testing your shim build soon, have to finish up on other quick thing first
-queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (yakkety-proposed) [3.173]
<slangasek> bdmurray, cyphermox: if we're switching to isc-dhcp in the initramfs, is fixing bug #1624014 in SRU worth doing as opposed to getting the isc-dhcp switch done?
<ubot5`> bug 1624014 in klibc (Ubuntu Trusty) "Wrong bit set in klibc PXE dhcp/bootp flags" [High,In progress] https://launchpad.net/bugs/1624014
<powersj> slangasek, I may be wrong, but the manifest for the pending iso appears to be the same as yesterdays. The result is the the tests won't run automatically.
<lamont> cyphermox: maas ipv6 with yakkety proposed "works" for values of "works" that include "dies because the kernel overlay fs isn't writable either" -- unrelated to our changes.
<lamont> http://paste.ubuntu.com/23216762/
<cyphermox> slangasek: yes, bootp still goes through ipconfig if you set things up just right
 * lamont still needs to find the actual bug #, but +1 from me to the various packages
<bdmurray> slangasek: that's a follow up to a previous SRU so I think its worth doing right asap
<cyphermox> (well, in truthfulness, dhcp too, again, if you set your command-line parameters just right)
<slangasek> powersj: oh, that sounds like a buggy check, then, since either of the .list or the .manifest might change and warrant a re-test
<slangasek> bdmurray: ack
<slangasek> cyphermox: "just right" - you mean if you don't remove klibc entirely from your system? :)
<cyphermox> that, but you also need to set ip= when booting
<powersj> slangasek, I'll take that down as something to look into, for now do you want me to kick them off manually?
<cyphermox> and use the weird format that klibc expects
<slangasek> powersj: sounds good!
<xnox> is there going to be a respin with -15 kernel, 476 d-i?
<xnox> or shall the current server images with -14 kernel be tested?
<xnox> (as in is -15 aimed for beta-2, or as a post-beta-2 update?)
<xnox> i guess we need -15, because efi
<xnox> sigh
<lamont> cyphermox: when you have packges in xenial-proposed, I'll get further down the path I really care about.
<jderose> cyphermox: quick question: so i need to copy shim.efi to /EFI/BOOT/BOOTx64.EFI?
-queuebot:#ubuntu-release- Unapproved: accepted klibc [source] (trusty-proposed) [2.0.3-0ubuntu1.14.04.2]
<cyphermox> jderose: yes. the file should actually be named shimx64.efi, and you want to copy it to EFI/BOOT/BOOTx64.EFI
<bdmurray> slangasek: What will happen if I accept dkms into -proposed when there is one already? From the SRU report - "remove-package -y -m "moved to -updates" -s trusty-proposed -e 2.2.0.3-1.1ubuntu5.14.04.8 dkms"
<jderose> cyphermox: gotcha, thanks. and in a production ISO, it would actually be shim.efi.signed that gets copied to this location, right?
<cyphermox> yep
<cyphermox> this time I just don't have it signed yet -- we're doing some testing before I ship it to MS so that we don't get something signed that we can't use because it's broken
<jderose> cyphermox: right, understood
<davmor2> cyphermox: how we looking?
<jderose> cyphermox: hmm, so first test under qemu + ovfm: no hardware exception, but it's still going directly to Shell>, isn't booting the installer. have you been able to test this yet? if so, what's your experience been?
<cyphermox> do you have the fallback in there as well?
<cyphermox> you definitely don't want it to be included
<jderose> cyphermox: no, i don't
<cyphermox> I haven't exactly been testing that
<jderose> cyphermox: i'll try a few qemu command permutations, see if i can coax it into worknig
<davmor2> jderose: what version of Ubuntu are you on in Yakkety there is an updated OVFM that uses a separate vars file so you need to specify them both or it does crazy things :)
<jderose> davmor2: right now i'm still using xenial for the host (which also requires a separate vars files or it does crazy things). i need to test under a yakkety host too, just in case that magically works :)
<davmor2> jderose: no just making sure you were aware of the change, in xenial I was still using the old bios.bin and it worked fine but not in yakkety :)  So just double checking that to rule it out
<cyphermox> that wouldn't break things this way
<jderose> davmor2: yup, as it turns out i'm highly aware of that change because i had to work through it during xenial dev :D http://blog.system76.com/post/139138591598/howto-qemu-w-ubuntu-xenial-host-uefi-guest
<davmor2> jderose: I wish I'd of seen that before I found it digging around in some fedora post in the end
<davmor2> jderose: nice write up by the way :)
<jderose> davmor2: yeah, still pretty difficult to find up-to-date and correct examples for this stuff. thanks!
<cyphermox> jderose: you get dropped to the shell because the remastering is breaking the boot
<davmor2> jderose: what happen if you use isomaster
<jderose> cyphermox: ah, okay. btw, this first test i test using isomaster as i knew how to use it already, so that could be the problem. but do you expect it to break in the same way using file-roller?
<cyphermox> file-roller is just to extract the shim from its deb package
<jderose> cyphermox: ah, okay. is there something more correct than isomaster that i should try?
<cyphermox> I'm not sure, I rarely have to do this
<jderose> cyphermox: i'm in the same boat, except i've never had to do this :P
<cyphermox> I have an old script that should more or less do the right thing, if I can find it again
<jderose> infinity: O great master of the ISO... any recommendations on this? :)
<cyphermox> jderose: there: http://paste.ubuntu.com/23216958/
<cyphermox> to do this I copy everything off the CD image into a directory tree I can modify and go nuts
<cyphermox> then run make_ubuntu_Iso.sh $dir  and it should make a pretty CD
<jderose> cyphermox: awesome, thanks... trying it now
<cyphermox> unsure if this will boot any better though, I recall there was something slightly wrong with it, but it mostly worked.
<cyphermox> oh, you'll still be missing files
<cyphermox> ah
<cyphermox> you need xorriso and isolinux
<cyphermox> then replace isohdpfx.bin with the full path from isolinux: /usr/lib/ISOLINUX/isohdpfx.bin
<davmor2> trying here too
<cyphermox> that big command in the script is basically taken from debian-cd after some copy-pasting the various bits and bobs
<jderose> cyphermox: can you give me a quick invocation example for this script?
<cyphermox> http://paste.ubuntu.com/23216990/
<jderose> cyphermox: thanks!
<cyphermox> heh, doesn't seem to work, but I think I know why, it's more embedded crap
<jderose> cyphermox: so --squashfs isn't needed, it take it?
<jderose> hehe
<cyphermox> no
<cyphermox> squashfs is for when I'm putting new stuff in the squashfs :)
<cyphermox> ok, I think it's that pesky efi.img file under boot/grub :/
<cyphermox> I was kind of expecting that was for the weird Mac EFI implementation though
<jderose> cyphermox: is it using hard offsets to positions within the ISO or something like that?
<cyphermox> (but since the CD now doesn't just kick me back to the boot selection but instead is stuck again at a "blank" screen with the shim version numbers, I think I'm hitting the old shim still)
<jderose> all this is making me realize how strikingly little i know about how the ISO is structured, built, and works :)
<cyphermox> jderose: efi.img is being written somwhere else to the disk in a small EFI partition just for that
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (vivid-proposed/main) [3.19.0-70.78] (core, kernel)
<jderose> cyphermox: i see boot/grub/efi.img, but are you saying it exists elsewhere also, mabye on a partition that file-roller doesn't understand how to extract?
<cyphermox> no, that's not what I'm saying
<cyphermox> that file is passed as a parameter to xorriso, and gets written to the final image as a separate partition
<cyphermox> that definitely fixes it... the more you know...
<cyphermox> fwiw to fix that I went in boot/grub, and used mcopy:
<cyphermox> mcopy -i efi.img ../../EFI/BOOT/BOOTx64.EFI ::EFI/BOOT/BOOTx64.EFI
<cyphermox> effectively putting the new shim that I had already copied to EFI/BOOT/BOOTx64.EFI into that efi.img file to replace the existing BOOTx64.EFI there.
<jderose> okay, gotcha
<cyphermox> I think when you run isomaster, it breaks things because it doesn't write that partition in the resulting image
<slangasek> bdmurray: since old and new dkms binary package names are the same, accepting the new one should lead to launchpad superseding the old ones with no problems.  kernels are different and special
<cyphermox> jderose: see, I think that's the part that "wasn't working" last I used this script to do weird stuff, and now it's figured out
<cyphermox> that image now boots correctly in EFI and BIOS.
<jderose> cyphermox: so when prompted by mcopy... do i want to o)verwrite, O)verright-all, or something else?
<cyphermox> overwrite or overwrite-all should do the same, you're only copying one file :)
<jderose> cyphermox: k, thanks. and the script here http://paste.ubuntu.com/23216958/ is still what i should use, or did you modify it since?
<cyphermox> the only modification was the new path to isohdpfx.bin
<jderose> cyphermox: er, where is this isohdpfx.bin file coming from, or what should the new path be?
<jderose> er, never mind, think i figured it out
<jderose> cyphermox: sweet, it's working for me under qemu + ovfm now! I'll test on physical uefi hardware shortly
<cyphermox> jderose: great
<jderose> cyphermox: so assuming the shim fix seems solid enough to justify getting it signed by MS, can that happen in time for 16.10? for me, at least i have a way to work around this issue for imaging mastering, so i'm all good. but i'm still curious
<cyphermox> I pushed it to a PPA already, I'll file the paperwork so that it gets sent for signing
-queuebot:#ubuntu-release- Unapproved: accepted cups-filters [source] (yakkety-proposed) [1.11.4-0ubuntu1]
<flexiondotorg> It is looking like a Friday release for 16.10 beta now?
<jderose> cyphermox: okay, finished sanity checking my customized iso on a boat load of UEFI hardware... all launched the installer pre-boot menu fine. two systems had issues booting into the full installer, but i think that's due to unrelated issues i'll have to track down later.
<wxl> flexiondotorg: if we're not, someone's going to get choked.
<jderose> cyphermox: but to the extent my customized iso is representative of a properly mastered iso with a fixed shim packaged, your fix seems solid
<cyphermox> ok
<flexiondotorg> wxl, OK, I'll make coffee and get some match sticks ;-)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Yakkety Beta 2] has been updated (20160922)
-queuebot:#ubuntu-release- Builds: Ubuntu Desktop i386 [Yakkety Beta 2] has been updated (20160922)
-queuebot:#ubuntu-release- Unapproved: hplip (yakkety-proposed/main) [3.16.7+repack0-1 => 3.16.7+repack0-1ubuntu1] (desktop-core, ubuntu-server)
<flexiondotorg> cyphermox, What was fixed in those new Ubuntu iso? Do flavours need to consider respinning?
<cyphermox> I don't know what the difference it
<cyphermox> *is
<cyphermox> slangasek: ^
<slangasek> cyphermox: that one is the respin against the current package pool
<cyphermox> ok
<flexiondotorg> slangasek, So Unity 8 stuff?
<slangasek> that was the only reason *I* had for triggering that respin, and that was probably image-specific
<slangasek> no
<slangasek> time-of-image-build and ftp-mirror-skew stuff
<flexiondotorg> slangasek, Thanks.
<sakrecoer> do i understand right? no respin for flavours?
<wxl> this respin thing is going to make me crazy
<flexiondotorg> wxl I've missed some of the goings on today.
<flexiondotorg> Can you catch myself and sakrecoer up on the status.
<wxl> flexiondotorg: i've been here the whole time and still can't figure it out XD
<flexiondotorg> llol
<wxl> i've heard we should, we will, we won't, we might
<wxl> i don't even know.
<sakrecoer> me too, and i don't really get it either lol
<flexiondotorg> So, Ubuntu MATE is good to go. For the record.
<sakrecoer> we are too, but... not if there is a respin
<sakrecoer> we=ubuntu studio sorry
<flexiondotorg> Right, so you're asking because you can't afford to do the testing again, right?
<wxl> we got a couple more tests to do
<wxl> hey sakrecoer you might want to mark yourself as ready if you're good.
<sakrecoer> ok, cheers wxl ! :)
<wxl> ta :)
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Yakkety Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD i386 [Yakkety Beta 2] has been marked as ready
<sakrecoer> i'm off for now, thanks everyone! touching wood (my head) for everything to work out all good for everyone!
<sakrecoer> o/
-queuebot:#ubuntu-release- Unapproved: quadrapassel (yakkety-proposed/universe) [1:3.21.90-1 => 1:3.22.0-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Unapproved: tali (yakkety-proposed/universe) [1:3.21.90-1 => 1:3.22.0-1] (desktop-extra) (sync)
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Yakkety Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Yakkety Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Unapproved: account-plugins (yakkety-proposed/main) [0.13+16.10.20160830.1-0ubuntu1 => 0.13+16.10.20160831-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: libphonenumber (yakkety-proposed/universe) [7.1.0-4ubuntu1 => 7.1.0-5ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libertine (yakkety-proposed/main) [1.4+16.10.20160908-0ubuntu1 => 1.4.1+16.10.20160914-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: signon-plugin-oauth2 (yakkety-proposed/main) [0.23+16.04.20151209-0ubuntu1 => 0.24+16.10.20160818-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-keyboard (yakkety-proposed/universe) [0.100+16.10.20160818-0ubuntu1 => 0.100+16.10.20160921-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-system-settings-online-accounts (yakkety-proposed/universe) [0.7+16.10.20160718-0ubuntu1 => 0.7+16.10.20160830.2-0ubuntu1] (no packageset) (sync)
<mwhudson> can someone pretty please release docker from the xenial unapproved queue?
<slangasek> powersj: wrt your follow-up on bug #1626622, can you also attach dmesg?
<ubot5`> bug 1626622 in debian-installer (Ubuntu) "yakkety server: fails to detect and mount CD-ROM" [Critical,New] https://launchpad.net/bugs/1626622
<slangasek> powersj: infinity and I are wondering if the remaining issue is related to the nls module issue that breaks fat partition mounting
<slangasek> or if there's something else needing further investigation
<slangasek> mwhudson: looking
<powersj> slangasek, yeah I'll have to reproduce locally as those logs are from the automated run
<mwhudson> slangasek: tia
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (xenial-proposed) [1.12.1-0ubuntu12~16.04]
<mwhudson> aaaaaaaaaaaaaaaaargh
<mwhudson> slangasek: can you delete that again? :)
<slangasek> well, yes, I can
<slangasek> mwhudson: done (and make up your mind ;)
<mwhudson> slangasek: ok, uploaded a new version, hopefully this one doesn't head straight into depwait
-queuebot:#ubuntu-release- Unapproved: accepted openbabel [sync] (yakkety-proposed) [2.3.2+dfsg-2.4]
<mwhudson> ok, *now* i've uploaded a new version
-queuebot:#ubuntu-release- Unapproved: docker.io (xenial-proposed/universe) [1.12.1-0ubuntu7~16.04 => 1.12.1-0ubuntu12~16.04.1] (no packageset)
<flexiondotorg> I've just upload ubuntu-mate-welcome 16.10.8. If someone could approve it please.
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-welcome (yakkety-proposed/universe) [16.10.7 => 16.10.8] (ubuntu-mate)
<flexiondotorg> The Ubuntu MATE have got a bit behind, this is a large collection of fixes and tweaks that has resulted from testing over recent days.
<flexiondotorg> infinity, ^
-queuebot:#ubuntu-release- Unapproved: nagios3 (yakkety-proposed/main) [3.5.1.dfsg-2.1ubuntu1 => 3.5.1.dfsg-2.1ubuntu2] (ubuntu-server)
<powersj> https://paste.ubuntu.com/23218086/
<powersj> slangasek, ^
<nacc> doko: --^ the above nagios3 should fix the ftfbs
<nacc> *ftbfs
#ubuntu-release 2016-09-23
<slangasek> powersj: thanks. dmesg output there shows no cdroms detected; which suggests a separate kernel issue from the ones we knew about :/
<slangasek> powersj: looks like this is inside of a VM, how is the CD set up - virtio?
<infinity> slangasek: virtio did indeed go modular between 4.4 and 4.8.  Could be yet another missing module in a udeb.
<infinity> Or a missing udeb in the initrd.
 * infinity looks.
<infinity> virtio-modules-udeb is included in the cdrom initrd.  But it could be missing modules.
<infinity> Hrm, no.  virtio-udeb looks complete to me.
<infinity> -16 in the kernel team PPA has some more potentially relevant fixes, though.
<infinity> Like re-enabling CONFIG_ATA...
<infinity> powersj: A dump of the qemu commandline would be quite helpful there.
<slangasek> I imagine he's replicating the qa smoketest
<slangasek> so wherever that code lives, again
<slangasek> this may mean that the actual qemu commandline is somewhere in utah
<cyphermox> yep
<infinity> Well, if he has access to the host, it's in "ps"
<infinity> Which is the CLI I really want to see, not some libvirt xml or something.
<slangasek> yes, if he's not EOD
<infinity> Ds E?
<cyphermox> I think the command-line might have been 2016-09-22 13:47:50,824 utah-21462-yakkety-server-amd64 INFO: Boot command line is: netcfg/get_hostname=utah-21462-yakkety-server-amd64 log_host=192.168.122.1 log_port=0 DEBCONF_DEBUG=developer debconf/priority=critical
<infinity> The qemu commandline, not the kernel commandline.
<slangasek> right
<cyphermox> oh, right :)
<powersj> slangasek, qemu-system-x86_64 -enable-kvm -boot d -hda vdisk.img -cpu host -m 1024 -cdrom yakkety-server-amd64.iso -serial mon:stdio
<powersj> that is probably not what the qa smoke test uses, but what I have been using to do installs with preseeded isos, so just copied it over today for this
-queuebot:#ubuntu-release- Unapproved: gsfonts (yakkety-proposed/main) [1:8.11+urwcyr1.0.7~pre44-4.2ubuntu1 => 1:8.11+urwcyr1.0.7~pre44-4.3] (desktop-core, ubuntu-server) (sync)
<nacc> doko: --^ taht should fix the gsfonts ftbfs as well
<cyphermox> powersj: the smoke tests run something very similar, but it's in ugly xml
<cyphermox> infinity: ide cdrom.
<slangasek> so indeed that sounds like the next kernel fixes it
<infinity> Seems likely indeed.
<cyphermox> fwiw I went to look at config/utah/default-vm.xml in utah source; that gets rewritten to something-default-bridged-vm.xml but the cd bits don't change.
<powersj> slangasek, infinity, anything else you'd like me to run before I jet off again?
<slangasek> powersj: sounds like you've given us enough to reproduce the problem, thanks
<powersj> ok!
<slangasek> doko: pygobject sync, looks like that's nothing that needs an FFe, it's just the stable release?  should I release it from unapproved for you?
-queuebot:#ubuntu-release- Unapproved: accepted libabw [source] (yakkety-proposed) [0.1.1-4ubuntu1]
-queuebot:#ubuntu-release- New binary: libabw [ppc64el] (yakkety-proposed/main) [0.1.1-4ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libabw [amd64] (yakkety-proposed/main) [0.1.1-4ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libabw [arm64] (yakkety-proposed/main) [0.1.1-4ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libabw [armhf] (yakkety-proposed/main) [0.1.1-4ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libabw [i386] (yakkety-proposed/main) [0.1.1-4ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libabw [s390x] (yakkety-proposed/main) [0.1.1-4ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: libabw [powerpc] (yakkety-proposed/main) [0.1.1-4ubuntu1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-software (yakkety-proposed/main) [3.20.1+git20160617.1.0440874.ubuntu-xenial-0ubuntu2 => 3.20.1+git20160923.1.0c571f1-0ubuntu1] (ubuntu-desktop)
<rcj> infinity, yakkety cloud builds are failing for powerpc.  I'm seeing "No kernel output for powerpc64-smp!" in the livecd-rootfs output.
<rcj> And maybe that's the relevant failure, and maybe it isn't.  I'm not 100%
<rcj> cjwatson, ^
<rcj> wgrant, ^
<rcj> :)
<wgrant> rcj: Do you have a build link?
<rcj> wgrant, https://launchpad.net/~cloudware/+livefs/ubuntu/yakkety/cpc/+build/76265
<wgrant> rcj "cp: cannot stat '/usr/bin/qemu-powerpc-static': No such file or directory" looks like the fatal line to me.
<wgrant> Why's it trying to cross when it's native?
<rcj> oh, that is or'ed with 'true'
<wgrant> Fri, 23 Sep 2016 01:48:23 +0000: arch: powerpc rel: yakkety host_arch: ppc
<wgrant> Fri, 23 Sep 2016 01:48:23 +0000: qemu_arch=powerpc cross=true
<rcj> You'll see that traceback is followed by "BUILD FAILED; continuing without blocking" so we trapped on the exit and exit'ed 0
<rcj> I'm leaving the maas bit in there so they can see that particular error and fix it.
<wgrant> Ah, indeed.
<wgrant> The kernel thing probably is fatal.
<wgrant> rcj: The powerpc64-smp flavour doesn't exist in yakkety.
<wgrant> powerpc-smp and powerpc64-emb do.
<wgrant> I haven't followed the flavour changes this cycle, so I'm not sure what the intent is.
<rcj> Maybe our livecd-rootfs is old?
<gaughen_> rcj, this worked the other day though right?
<wgrant> livecd-rootfs (2.432) yakkety; urgency=medium
<wgrant>   * Use the virtual kernel for the powerpc64 cpc images (LP: #1625368)
<ubot5`> Launchpad bug 1625368 in Ubuntu CD Images "Rename powerpc64-smp kernel to generic" [Undecided,New] https://launchpad.net/bugs/1625368
<wgrant> Do you have that change?
<wgrant> https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1625368
<wgrant> I suspect you're missing that.
<gaughen> rcj, we have a successful daily from 0918
<rcj> wgrant, that would do it.
 * gaughen nods
<rcj> wgrant, so I'll try that, so what are your thoughts on this arm64 failure... https://launchpad.net/~cloudware/+livefs/ubuntu/yakkety/cpc/+build/76263
<wgrant> rcj: Hm, is flash-kernel needed now that the images are UEFI?
-queuebot:#ubuntu-release- Unapproved: gnome-software (xenial-proposed/main) [3.20.1+git20160617.1.0440874.ubuntu-xenial-0ubuntu1~16.04.1 => 3.20.1+git20160923.1.0c571f1-0ubuntu1~xenial1] (ubuntu-desktop)
<wgrant> Oh, it's removing the kernel, huh.
<wgrant> Why is it removing the kernel
<rcj> it's creating a squashfs for container deployment (lxd and others)
<wgrant> Ah
<wgrant> When did that appear to break?
<wgrant> There are no recent relevant changes to flash-kernel.
<rcj> It last worked on sept20th
<rcj> https://launchpad.net/~cloudware/+livefs/ubuntu/yakkety/cpc/+build/76008
<wgrant> rcj: Oh, the kernel hook might be dodgy.
<wgrant> It's not passing in the abi, I suspect.
<wgrant> To zz-flash-kernel
 * wgrant checks.
<infinity> rcj: Is this in a livecd-rootfs fork?
<infinity> rcj: Cause the archive version doesn't reference powerpc64-smp.
<infinity> rcj: Ahh, I see wgrant got there.
 * xnox says 20101020ubuntu476 is good on s390x. no cdroms, and no efi either.
<rcj> infinity, yes.  We were told to run production from a fork because lp:livecd-rootfs trunk wasn't considered stable by foundations.
<infinity> rcj: Err, really?
<infinity> *blink*
 * gaughen once again nods
<infinity> I'd really rather you get everything into trunk and not use a fork.
<xnox> infinity vs slangasek
<rcj> infinity, we're not forked with changes, we're just running older code so as not to be at tip
<xnox> infinity, some bits of gaughen & rcj are proprietary.
<infinity> rcj: Yeah, which leads to this. :/
<gaughen> xnox, sssh nobody is supposed to know about  my bionic pinky
<infinity> Oh well.
<rcj> infinity, but clearly that's not well known since we didn't know to move forward to pick up a commit with 'cpc' in the title
<rcj> infinity, so we're not syncing from trunk often enough.
<gaughen> yup, sounds like we need to revisit the frequency, but I think that's a discussion for after  final beta
<rcj> and we're back at r1386, so this will be fun tonight.
<rcj> gaughen, absolutely
<wgrant> rcj: I can't obviously see why flash-kernel is broken. It looks like it for some reason wasn't running the trigger in the successful build.
<wgrant> It should have always failed.
<wgrant> AFAICS
<wgrant> Oh, there's an exit 0 there.
<rcj> wgrant, This is the hook http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-cpc/hooks/032-root-squashfs.binary
<rcj> wgrant, where?
<wgrant> Removing linux-image-extra-4.8.0-15-generic (4.8.0-15.16) ...
<wgrant> run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.8.0-15-generic /boot/vmlinuz-4.8.0-15-generic
<wgrant> Why is removal of -extra executing postinst.d?
<wgrant> That's the thing that is newly firing the trigger that eventually causes the failure during removal of the next package.
<rcj> infinity, and we're updating from released packages, so we wouldn't get your change yet anyhow. :/
<wgrant> It seems deliberate, in control-scripts/extra-post, hm.
<wgrant> Oh
<wgrant> rcj: So the breakage is because linux-image-extra-$version is being installed now.
<wgrant> I wonder if the linux linux-image-$version Recommends it.
<wgrant> There's an underlying bug in the triggers that's been there for a while, but it's only tickled now because linux-image-extra's removal is refiring the postinst trigger.
<wgrant> Or the 4.4 arm64 linux-image-generic didn't depend on linux-image-extra, I suppose.
<wgrant> rcj: So you can either get flash-kernel's zz-flash-kernel to not die in these conditions, or avoid installing linux-image-extra in the first place.
<bjf> gaughen, here
<bjf> gaughen, reading
<wgrant> I imagine this is reproducible on any yakkety arm64 system by installing flash-kernel and linux-image-generic, then removing linux-image-*
<bjf> infinity, how is kernel? do i need to call in reinforcements?
<wgrant> Which will cause the flash-kernel trigger to be queued by linux-image-extra-*'s removal, then uninstall linux-image-*, then run the trigger and crash.
<bjf> wgrant, arm64 needs linux-image-extra now .. that's a recent change
<infinity> rcj: Oh, if you're having issues with arm64, you need to s/generic/virtual/
<infinity> But f-k being triggered twice is also a bug.
<wgrant> This is just flash-kernel's hackish existence finally biting.
<wgrant> Seems to not enjoy life when rerun without any kernels installed.
<gaughen> thanks bjf
<infinity> gaughen: Note that he means generic now depends on extra, but you guys should switch to virtual.
<infinity> rcj: ^
<gaughen> infinity, arm64 using generic is an intentional change, afaik
<gaughen> well not a change, it's been using generic for a while now
<gaughen> and I don't think we should make that switch to virtual today/tomorrow
<rcj> gaughen, infinity: I'm looking for 'bzr blame' right now to see if we have a reason
<infinity> gaughen: Yes, because virtual didn't used to exist.
<infinity> gaughen: The virtual/extra split is new.
<infinity> Should be the same as the fix I did for powerpc.
<gaughen> aaah okay
<infinity> rcj: ^
<rcj> infinity, thank you
<rcj> infinity, Shall I submit an MP for lp:livecd-rootfs  to drop that for arm64?  Or is it better from foundations?
<infinity> rcj: Don't care who does it.
<infinity> rcj: I can commit and upload in ~15m.
<rcj> infinity, I would be grateful
<infinity> rcj: r1444.
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (yakkety-proposed/main) [2.432 => 2.433] (desktop-core)
<rcj> infinity, Thank you
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (yakkety-proposed) [2.433]
-queuebot:#ubuntu-release- Unapproved: kdeclarative (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdbusaddons (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
<slangasek> infinity: yes, because running from lp:livecd-rootfs leads to regressions on their side that we can't debug and have no CI for.  They should have a gate, which they control, for when they take new code from trunk
<slangasek> and if it happens to be a gate downstream from the existing gate we already have (i.e. proposed-migration), even better for us
-queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (xenial-proposed) [1.12.1-0ubuntu12~16.04.1]
-queuebot:#ubuntu-release- New binary: docker.io [amd64] (xenial-proposed/universe) [1.12.1-0ubuntu12~16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted kboot-installer [source] (yakkety-proposed) [0.0.1ubuntu10]
<slangasek> is it a bug that packages seeded as 'supported' are not being auto-accepted?
-queuebot:#ubuntu-release- Unapproved: accepted emacs24 [source] (yakkety-proposed) [24.5+1-7ubuntu1]
<infinity> slangasek: Sure, running trunk itself isn't ideal, but being in sync with the archive would be nice.
<infinity> slangasek: *shrug*
<slangasek> infinity: yes, the dial may have been turned too far the other way ;)
<infinity> slangasek: And if they were actually using the archvie version itself (ie: not a PPA fork), then this bug would have been fixed.
<infinity> So, would be nice to see if we could get there.
<infinity> Secret sauce could live in another package that dumps hooks in, or similar.
<pitti> good morning!
<rcj> infinity, it's the archive version and we have a recipe that adds in our additional hooks.  And slangasek is right, the dial is turned too far back
<slangasek> xnox: should these software-properties changes not require an FFe?
-queuebot:#ubuntu-release- Unapproved: accepted attica-kf5 [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: qtmir (yakkety-proposed/universe) [0.4.8+16.10.20160906-0ubuntu1 => 0.4.8+16.10.20160909-0ubuntu1] (ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: qtmir-gles (yakkety-proposed/universe) [0.4.8+16.10.20160906-0ubuntu1 => 0.4.8+16.10.20160909-0ubuntu1] (ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-settings-components (yakkety-proposed/universe) [0.9+16.10.20160818.1-0ubuntu1 => 0.9+16.10.20160909-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: unity-api (yakkety-proposed/universe) [7.118+16.10.20160830-0ubuntu1 => 7.119+16.10.20160909-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: unity8 (yakkety-proposed/universe) [8.14+16.10.20160831.3-0ubuntu1 => 8.14+16.10.20160922-0ubuntu1] (ubuntu-qt-packages) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-system-settings (yakkety-proposed/universe) [0.4+16.10.20160913-0ubuntu1 => 0.4+16.10.20160916-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: unity-system-compositor (yakkety-proposed/universe) [0.7.1+16.10.20160824-0ubuntu1 => 0.7.1+16.10.20160909.1-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-settings-components [sync] (yakkety-proposed) [0.9+16.10.20160909-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted unity-system-compositor [sync] (yakkety-proposed) [0.7.1+16.10.20160909.1-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted baloo-kf5 [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<rcj> infinity, bjf, wgrant: fun fact, I don't see a linux-virtual for arm64 @ https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/bootstrap/+build/10939754
<rcj> So it's true that arm64 just gained an linux-image-extra package and dependency which causes us to hit the flash-kernel bug but we can't use the virtual kernel yet, and the commit to livecd-rootfs from infinity has the build die when it can't find linux-virtual
<doko> slangasek: pygobject should be covered by the gnome ffe, plus it should fix the ftbfs
-queuebot:#ubuntu-release- New: accepted libabw [amd64] (yakkety-proposed) [0.1.1-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted libabw [armhf] (yakkety-proposed) [0.1.1-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted libabw [powerpc] (yakkety-proposed) [0.1.1-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted libabw [s390x] (yakkety-proposed) [0.1.1-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted libabw [arm64] (yakkety-proposed) [0.1.1-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted libabw [ppc64el] (yakkety-proposed) [0.1.1-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted libabw [i386] (yakkety-proposed) [0.1.1-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted wine [amd64] (yakkety-proposed) [1.8.4-1ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted nagios3 [source] (yakkety-proposed) [3.5.1.dfsg-2.1ubuntu2]
<flexiondotorg> infinity, Can you accept ubuntu-mate-welcome 16.10.8 please.
<pitti> flexiondotorg: that diff is unreviewable; you tested it?
<pitti> well, it'll be blocked in -proposed anyway, accepted
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-welcome [source] (yakkety-proposed) [16.10.8]
<flexiondotorg> pitti, Yes, it has been tested over 3 days. Most of the changes are as a result of the testing.
<flexiondotorg> pitti, What is the process for getting ubuntu-mate-welcome from proposed to release at this stage in the cycle? I don't recall.
<pitti> flexiondotorg: coordinate with whomever does the image respins for mate, and  ask anyone in ~ubuntu-release to add a britney unblock hint
<pitti> flexiondotorg: if you do the image rebuilds/testing coordination, that'll be particularly easy :)
<flexiondotorg> pitti, It isn't required for Beta 2 image.
<pitti> oh, ok
<flexiondotorg> Just available for updates is fine.
<pitti> then no further action is required
<flexiondotorg> Perfect. Thanks.
-queuebot:#ubuntu-release- Unapproved: atomix (yakkety-proposed/universe) [3.22.0-0ubuntu1 => 3.22.0-1] (edubuntu) (sync)
<Saviq> hey, can we plaease have qtmir, qtmir-gles, ubuntu-system-settings, unity-api, unity8 pushed through the unapproved queue? thanks
-queuebot:#ubuntu-release- Unapproved: hitori (yakkety-proposed/universe) [3.20.0-1 => 3.22.0-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted hitori [sync] (yakkety-proposed) [3.22.0-1]
-queuebot:#ubuntu-release- New sync: xdg-desktop-portal (yakkety-proposed/primary) [0.3-1]
-queuebot:#ubuntu-release- Unapproved: debian-handbook (yakkety-proposed/universe) [8.20160826 => 8.20160922] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted debian-handbook [sync] (yakkety-proposed) [8.20160922]
-queuebot:#ubuntu-release- Unapproved: kdesignerplugin (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: eiciel (yakkety-proposed/universe) [0.9.11-2 => 0.9.11-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted eiciel [sync] (yakkety-proposed) [0.9.11-3]
-queuebot:#ubuntu-release- Unapproved: tablix2 (yakkety-proposed/universe) [0.3.5-3ubuntu1 => 0.3.5-3.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted tablix2 [sync] (yakkety-proposed) [0.3.5-3.1]
-queuebot:#ubuntu-release- Unapproved: root-tail (yakkety-proposed/universe) [1.2-3ubuntu1 => 1.2-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: petris (yakkety-proposed/universe) [1.0.1-8ubuntu2 => 1.0.1-9] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted petris [sync] (yakkety-proposed) [1.0.1-9]
-queuebot:#ubuntu-release- Unapproved: accepted root-tail [sync] (yakkety-proposed) [1.2-4]
-queuebot:#ubuntu-release- Unapproved: elk (yakkety-proposed/universe) [3.99.8-4ubuntu1 => 3.99.8-4.1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted elk [sync] (yakkety-proposed) [3.99.8-4.1]
<apw> xnox, are you intending that NotShownIn change in software-properties, i don't see it in the changelog
-queuebot:#ubuntu-release- Unapproved: rejected libertine [sync] (yakkety-proposed) [1.4.1+16.10.20160914-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected quadrapassel [sync] (yakkety-proposed) [1:3.22.0-1]
-queuebot:#ubuntu-release- Unapproved: kded (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: rejected libphonenumber [sync] (yakkety-proposed) [7.1.0-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: kdelibs4support (yakkety-proposed/universe) [5.24.0-0ubuntu2 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdeclarative (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
<jbicha> apw: yes, it's intentional https://code.launchpad.net/~jbicha/software-properties/use-gi-require_version/+merge/304193
<davmor2> Morning all
-queuebot:#ubuntu-release- Unapproved: ceilometer (yakkety-proposed/main) [1:7.0.0~rc1-0ubuntu2 => 1:7.0.0~rc2-0ubuntu1] (openstack, ubuntu-server)
<Odd_Bloke> apw: slangasek: infinity: We're proposing https://code.launchpad.net/~rcj/livecd-rootfs/yakkety_arm64/+merge/306599 to get arm64 builds working again; this simply switches us back to the generic kernel and skips the flash-kernel calls when we are constructing the squashfs.
<Odd_Bloke> (I don't really know who else to ping, but this is blocking beta cloud images being built.)
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (yakkety-proposed/main) [2.433 => 2.434] (desktop-core)
<apw> Odd_Bloke, given the risk profile of the various options it seems reasonable to me, that ^^ is your merge, i'll let someone else review it again
-queuebot:#ubuntu-release- Unapproved: firefox (yakkety-proposed/main) [48.0+build2-0ubuntu1 => 49.0+build4-0ubuntu1] (kubuntu, mozilla, ubuntu-desktop)
<infinity> Odd_Bloke: Given you build from a fork, and using -virtual is the right thing going forward, not sure why you'd revert my change on trunk.
<infinity> (Also, virtual will exist momentarily)
<Odd_Bloke> infinity: Oh, OK, I got the impression we wouldn't have -virtual until the next kernel (which I assumed to not be landing in time for beta).
<davmor2> infinity: so we need to wait on cyphermox shim to get signed, land in the iso and then respin again right is that the last thing we are waiting on then? I'm going to test that the 3rd party drivers thing is gone in the meantime
<infinity> davmor2: Err, what?
<infinity> davmor2: "waiting on shim to get signed" is a thing that can take months.
<apw> a microsoft signing?  those take weeks
<Odd_Bloke> infinity: (We're only forked insofar as we point at a specific version of the archive's livecd-rootfs; we try not to merge things there unless there's a very compelling reason to.)
<davmor2> infinity: oh so we are just stuck with a none boot iso then
<infinity> davmor2: In what scenario?
<davmor2> infinity: securebooted machines
<Odd_Bloke> infinity: (And I've just opened up an MP for our tooling to keep that "fork" up-to-date hourly in development releases, so we should never see this sort of issue again once that's merged)
<infinity> Odd_Bloke: Why only "in development releases"?
<infinity> Odd_Bloke: I'd really like you to benefit from bugfixes without a manual step. :P
<Odd_Bloke> infinity: We have SLAs with partners for released releases; perhaps I'm being overcautious. :)
<infinity> Odd_Bloke: The reason this all happened was because you were tracking *trunk* before.  The answer isn't to freeze at a point in time, but to track the archive instead.
<davmor2> infinity: https://bugs.launchpad.net/ubuntu/+source/debian-cd/+bug/1624096
<ubot5`> Ubuntu bug 1624096 in shim (Ubuntu) "yakkety: backport (or rebase to) fix eliminating a double-close in shim" [High,In progress]
<apw> davmor2, why don't the older releases suffer the same issue?  do we no longer have a fallback.efi or something ?
<Mirv> repeating Saviq's request to allow qtmir, qtmir-gles, ubuntu-system-settings, unity-api, unity8 in from yakkety unapproved queue
<infinity> apw: No, the commit with the double-free is new.
<xnox> jbicha, apw, mis-merged changelog entry. I guess i should fix it up and reupload. please reject current software properties.
<apw> infinity, oh we have missmatched shim was not expecting that, cyphermox implies in the bug we can work round it by shipping a fallback.efi ?
<infinity> No, we can't.
<infinity> Read more bug.
-queuebot:#ubuntu-release- Unapproved: rejected software-properties [source] (yakkety-proposed) [0.96.24.7]
<infinity> Anyhow, there's precious little we can do about it for beta2, except document it.
<apw> xnox, ^
<davmor2> jibel: ^
<infinity> I'm somewhat concerned that the Microsoft signing might not happen before GA, and we'll have to figure out a way to revert to the old shim without reverting any functionality...
<infinity> Which sounds "fun".
 * infinity is so glad that our release process gates on a 3rd party's code review and signing.
-queuebot:#ubuntu-release- Unapproved: solid (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: sonnet (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kunitconversion (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kwayland (yakkety-proposed/universe) [4:5.24.0-0ubuntu1 => 4:5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kwallet-kf5 (yakkety-proposed/universe) [5.24.0-0ubuntu2 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: software-properties (yakkety-proposed/main) [0.96.24.6 => 0.96.24.7] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: kjsembed (yakkety-proposed/universe) [5.24.0-0ubuntu2 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: knewstuff (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: knotifyconfig (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kmediaplayer (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: knotifications (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kinit (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kitemmodels (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kio (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: account-plugins (yakkety-proposed/main) [0.13+16.10.20160830.1-0ubuntu1 => 0.13+16.10.20160831-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: breeze-icons (yakkety-proposed/universe) [4:5.24.0-0ubuntu1 => 4:5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: frameworkintegration (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kactivities-stats (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: signon-plugin-oauth2 (yakkety-proposed/main) [0.23+16.04.20151209-0ubuntu1 => 0.24+16.10.20160818-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: bluez-qt (yakkety-proposed/universe) [5.24.0-0ubuntu2 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kactivities-kf5 (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ubuntu-system-settings-online-accounts (yakkety-proposed/universe) [0.7+16.10.20160718-0ubuntu1 => 0.7+16.10.20160830.2-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: extra-cmake-modules (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: pygobject (yakkety-proposed/main) [3.21.92-1 => 3.22.0-1] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: ki18n (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kidletime (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kinit (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kitemmodels (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kjobwidgets (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kjsembed (yakkety-proposed/universe) [5.24.0-0ubuntu2 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: knewstuff (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kiconthemes (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kio (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kjs (yakkety-proposed/universe) [5.24.0-0ubuntu4 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: knotifications (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kimageformats (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kmediaplayer (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kitemviews (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: account-plugins (yakkety-proposed/main) [0.13+16.10.20160830.1-0ubuntu1 => 0.13+16.10.20160831-0ubuntu1] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: signon-plugin-oauth2 (yakkety-proposed/main) [0.23+16.04.20151209-0ubuntu1 => 0.24+16.10.20160818-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-system-settings-online-accounts (yakkety-proposed/universe) [0.7+16.10.20160718-0ubuntu1 => 0.7+16.10.20160830.2-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libertine (yakkety-proposed/main) [1.4+16.10.20160908-0ubuntu1 => 1.4.1+16.10.20160914-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ubuntu-keyboard (yakkety-proposed/universe) [0.100+16.10.20160818-0ubuntu1 => 0.100+16.10.20160921-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: kdesu (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdnssd-kf5 (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kemoticons (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kglobalaccel (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdewebkit (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kfilemetadata-kf5 (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kdoctools (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: kguiaddons (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
<Odd_Bloke> infinity: apw: I'll be grabbing some lunch soon; can you ping me when we have a -virtual for arm64 that I can build against?
<davmor2> infinity, pitti: good news we have 3rd party drivers \o/
<pitti> davmor2: party!!!!
<davmor2> Now to see if they install on the system too
<pitti> davmor2: so the cdimage mirror is up to date again, good
<davmor2> pitti: sounds it
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Yakkety Beta 2] has been disabled
-queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Yakkety Beta 2] has been disabled
<davmor2> \o/ I can haz Wifi on the installed system too \o/
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (yakkety-proposed) [2.434]
-queuebot:#ubuntu-release- Unapproved: kdesignerplugin (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal [sync] (yakkety-proposed) [0.3-1]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (yakkety-proposed/main) [4.8.0-16.17] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (yakkety-proposed) [4.8.0-16.17]
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal [ppc64el] (yakkety-proposed/none) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal [amd64] (yakkety-proposed/none) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal [i386] (yakkety-proposed/none) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal [arm64] (yakkety-proposed/none) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal [armhf] (yakkety-proposed/none) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (vivid-proposed) [3.19.0-70.78]
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal [powerpc] (yakkety-proposed/none) [0.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: xdg-desktop-portal [s390x] (yakkety-proposed/none) [0.3-1] (no packageset)
<ChrisTownsend> Hey, could anyone tell me why the recent libertine upload was rejected?
<apw> ChrisTownsend, the reason was in the reject email ... but i believe that was becasue it was in there twice
<davmor2> cyphermox: the fact that there is no efi entry for ubuntu in the bios I assume is because of shim right?  IE install the system drop into UEFI look at boot options and there is no Ubuntu option that is normally there pointing to shimx64.efi on the harddrive
<apw> ChrisTownsend, yes, livertine is still sitting in the queue
<ChrisTownsend> apw: I didn't get an email.  Oh, I haven't seen the other one.
<ChrisTownsend> apw: Bileto had me all worried with it's status saying REJECTED.
<ChrisTownsend> apw: Thanks!
<ogra_> livertine ? is your brain already at beer o'clock ?
<cyphermox> davmor2: no
<cyphermox> davmor2: if you don't have the ubuntu entry in the EFI firmware after install is at this point most likely to be because you started qemu wrong ;)
<davmor2> cyphermox: oh weird it shows when there is no usb pendrive in the xps 13, let me check it when I finish this install it might just not be permanently there now
<davmor2> cyphermox: this is on Hardware
<cyphermox> oh, on a Dell?
<cyphermox> you may be hitting another firmware bug
<davmor2> cyphermox: yeap it boots from the harddrive no issues, it just doesn't show in the menu is that the infamous old there is no BOOT.efi file in BOOT or something
<cyphermox> I'm not sure it happens on all Dell BIOS but I've seen one be very unhappy about adding our boot entry and just removing it after a reboot
<cyphermox> davmor2: yes
<davmor2> cyphermox: that's fine then I can live with that one it boots which it is the important thing
<cyphermox> we'll fix that one too though
<davmor2> cyphermox: thems fighting words
<cyphermox> well, it's been on my list for a while, and it involves the fallback.efi
<davmor2> cyphermox: okay so it show ubuntu when there is no pendrive but the minute I boot with a pendrive in it only shows the efi entries on the pendrive which is a bit weird but I assume that is a dell firmware issue so I don't care enough at this point :)
-queuebot:#ubuntu-release- Unapproved: unity-scope-click (yakkety-proposed/universe) [0.1.1+16.10.20160920.1-0ubuntu1 => 0.1.1+16.10.20160922-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted unity-scope-click [sync] (yakkety-proposed) [0.1.1+16.10.20160922-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: kdesignerplugin (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
<cyphermox> davmor2: great
-queuebot:#ubuntu-release- Unapproved: unity8-desktop-session (yakkety-proposed/universe) [1.0.13+16.10.20160919-0ubuntu1 => 1.0.13+16.10.20160921-0ubuntu1] (no packageset) (sync)
<davmor2> willcooke: oh interesting mini.iso netboot installs install unity8-desktop-session too no wonder it took so much longer to install :)
<willcooke> hmm
<willcooke> that doesnt sound like it should be there
-queuebot:#ubuntu-release- Unapproved: accepted unity8-desktop-session [sync] (yakkety-proposed) [1.0.13+16.10.20160921-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: kdesignerplugin (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
<davmor2> willcooke: netboot install from archive don't forget
<willcooke> ah, right
-queuebot:#ubuntu-release- Unapproved: postgresql-common (yakkety-proposed/main) [175ubuntu1 => 176+git1] (kubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: heat (xenial-proposed/main) [1:6.0.0-0ubuntu1.1 => 1:6.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted pygobject [sync] (yakkety-proposed) [3.22.0-1]
<jderose> infinity: as far as the shim signing... would a reasonable plan be to only land the new shim package if it gets signed in time, otherwise keep the current one?
<jderose> or mabye that's already the plan, wasn't quite sure what you meant by "we'll have to figure out a way to revert to the old shim without reverting any functionality..."
<cyphermox> jderose: the argument is that not being able to boot the CD images on EFI is kinda bad
-queuebot:#ubuntu-release- Unapproved: unadf (yakkety-proposed/universe) [0.7.11a-3 => 0.7.11a-3+deb7u1] (no packageset)
<jderose> cyphermox: agreed. what's your assessment of the percentage of hardware effected by this? i know you mentioned you had a laptop that wouldn't boot. by luck, no System76 products seem "crushingly" effected by this (the memory corruption doesn't cause a hardware exception, doesn't prevent booting)
-queuebot:#ubuntu-release- Unapproved: accepted unadf [source] (yakkety-proposed) [0.7.11a-3+deb7u1]
-queuebot:#ubuntu-release- Unapproved: kdesu (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
<cyphermox> well, for starters all thinkpads
<cyphermox> otoh it could just have been blocking boot becuase I have shim debugging enabled
<jderose> cyphermox: but i am a bit concerned about the potential security issue here... memory corruption is happing silently, and who knows what fun opportunities that might open
<cyphermox> but I'm not willing to take a guess to find out at release time :)
<cyphermox> oh of course
<jderose> cyphermox: "effects all thinkpads" <-- that's a pretty strong data point right there :)
<cyphermox> that's why infinity suggested reverting
<jderose> cyphermox: ah, okay, so you did land the new shim package then?
-queuebot:#ubuntu-release- Unapproved: accepted bluez-qt [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<cyphermox> I suppose we could cheat and use the old shim on the CD, but then the source for that shim wouldn't be anywhere
<cyphermox> jderose: when I say old and new I mean "new" being the one currently in the archive, and old the one before that
<jderose> yeah, true
<jderose> ah, okay
<cyphermox> the new new shim is in the grinder now.
<jderose> i guess we could also just say, "go home secure boot, you're drunk" and return to the glory days of not depending on microsoft :P
<cyphermox> not really, because it probably won't boot any better with secure boot disabled
<infinity> jderose: I meant revert to the version before the bug was introduced.
<cyphermox> I don't remember what the state was for SB on my laptop when I tried to boot these images
<cyphermox> infinity: if you care, shim signing is RT #95907
<jderose> infinity: ah, okay. hmm... so this would need a new epoch in the version then? that doesn't seem terribly difficult... but is it?
<apw> cyphermox, the source for that would be in an old release still no ?
<infinity> jderose: Not an epoch, just an ugly version. :P
<apw> cyphermox, presumably we use a .is. version ?
<cyphermox> apw: yes, since we haven't copied it to all releases yet
<cyphermox> well, last signing only took a few days, I see no reason for it to take much longer
<jderose> infinity: ah, i always thought the epoch was the way one wouldn't likely handle needing to go backward version wise. but i've never had to do this, nor i'm i familiar with the debian policy on this matter
<cyphermox> last signing took two weeks.
<cyphermox> jderose: for that we do something like 1.2.really.1.1 and be done with it
<jderose> cyphermox: okay, gotcha
<cyphermox> because we're likely to go to 1.3 next
<cyphermox> epochs are forever.
<jderose> gotcha, just like diamonds :P
<ogra_> but epochs arent girls best friends i fear
<jderose> hehe
<cyphermox> my rules are 1) if you think you need to use epoch, you're wrong, don't use epoch 2) if you still think you need it, refer to 1), and 3) maybe you need it in this one very special circumstance, but make sure there is no other option first
<jderose> cyphermox: thanks, i'm adding that to my permanent record of packaging wisdom
<ogra_> 4) screw it, just invent a new package name and add -ng :P
<cyphermox> ahaha
<cyphermox> ^ what if you're wrong and get back to 1) ?
<ogra_> you're screwed ?
<infinity> Burning an epoch on a temporary revert is silly.  Using them when upstream versions change permanently is sane.
-queuebot:#ubuntu-release- Unapproved: accepted breeze-icons [source] (yakkety-proposed) [4:5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted extra-cmake-modules [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted frameworkintegration [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected kactivities-kf5 [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kactivities-stats [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: debian-installer (yakkety-proposed/main) [20101020ubuntu476 => 20101020ubuntu477] (core)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (yakkety-proposed) [20101020ubuntu477]
-queuebot:#ubuntu-release- Unapproved: openssl (yakkety-proposed/main) [1.0.2g-1ubuntu8 => 1.0.2g-1ubuntu9] (core)
<acheronuk> Hi. can I ask why? 'rejected kactivities-kf5'. Thanks
<xnox> reject reasons should be in the email to the uploader.....
<slangasek> acheronuk: because debian/control was broken. the uploader received mail
-queuebot:#ubuntu-release- Unapproved: accepted kapidox [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<acheronuk> slangasek: thank you. I'll talk to him
-queuebot:#ubuntu-release- Unapproved: accepted karchive [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kauth [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kbookmarks [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kcmutils [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kcodecs [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Builds: Netboot amd64 [Yakkety Beta 2] has been updated (20101020ubuntu477)
-queuebot:#ubuntu-release- Builds: Netboot arm64 [Yakkety Beta 2] has been updated (20101020ubuntu477)
-queuebot:#ubuntu-release- Builds: Netboot armhf [Yakkety Beta 2] has been updated (20101020ubuntu477)
-queuebot:#ubuntu-release- Builds: Netboot i386 [Yakkety Beta 2] has been updated (20101020ubuntu477)
-queuebot:#ubuntu-release- Builds: Netboot powerpc [Yakkety Beta 2] has been updated (20101020ubuntu477)
-queuebot:#ubuntu-release- Builds: Netboot ppc64el [Yakkety Beta 2] has been updated (20101020ubuntu477)
-queuebot:#ubuntu-release- Builds: Netboot s390x [Yakkety Beta 2] has been updated (20101020ubuntu477)
-queuebot:#ubuntu-release- Unapproved: accepted kcompletion [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: unity-scopes-api (yakkety-proposed/universe) [1.0.6+16.10.20160617-0ubuntu2 => 1.0.7+16.10.20160921-0ubuntu1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: unity-scopes-shell (yakkety-proposed/universe) [0.5.7+16.10.20160624.2-0ubuntu2 => 0.5.8+16.10.20160921-0ubuntu1] (no packageset) (sync)
<flexiondotorg> infinity, How is the release looking from your point of view?
-queuebot:#ubuntu-release- Unapproved: accepted openssl [source] (yakkety-proposed) [1.0.2g-1ubuntu9]
-queuebot:#ubuntu-release- Unapproved: kdnssd-kf5 (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
<nacc> working the ftbfs of pacemaker per doko's last e-mail, was wondering if anyone could quikly glance at http://paste.ubuntu.com/23221134/ for sanity?
<nacc> i'm not sure why it changed from dist to site-packages, but i verified this in the sbuild environment as well
<cjwatson> that really doesn't seem right
<cjwatson> should be /usr/lib/python3/dist-packages/
<nacc> yeah it's weird
<cjwatson> perhaps a missing/misconfigured dh_python3 call?
<nacc> there's no  mention of python in the debian/rules file at all, otehr than this one line
<nacc> which is also strange :)
<cjwatson> well, dh often handles stuff automatically
<nacc> cjwatson: from teh build log: http://paste.ubuntu.com/23221146/
<davmor2> infinity: i386 done, amd64 done, netboot for i386 and amd64 done, 1 major issue is the shim that needs a note other than that the only other things are minor or aesthetic as far as I can tell so over to you
<infinity> flexiondotorg: Messy.
<acheronuk> if something is rejected in the queue for small error in control file, can it be corrected and uploaded with the same original version?
<infinity> flexiondotorg: So, I'm considering a potention respin of literally everything to stuff the new kernel in, but if I do that, the kernel team will be on the hook for smoketesting everyone's ISOs so the flavours don't have to.
<tsimonq2> a lot of Kubuntu things will migrate when beta freeze is undone, we're holding our breath...
<cjwatson> nacc: yeah, that's not unusual but the packaging helpers are supposed to move stuff to the right place
<cjwatson> nacc: would need to see the full log
<tsimonq2> it would also be nice to have hardinfo uploaded, so Lubuntu is wanting that as well
<tsimonq2> fun stuff
<slangasek> acheronuk: if it was in the queue when it was rejected, yes you can reuse the version number
<davmor2> infinity: say what now????
<infinity> davmor2: what not????
<slangasek> infinity: why respin everything for new kernel instead of releasing as-is those images that already passed?
<infinity> s/not/now/
<nacc> cjwatson: http://paste.ubuntu.com/23221157/
<acheronuk> slangasek: ty. I guessed that was the case, but confirmation is appreciated
<davmor2> slangasek: let it land as an update
<davmor2> infinity: ^ even sorry slangasek
<cjwatson> nacc: ah, maybe needs --with python3
<cjwatson> (and care!)
<infinity> slangasek: Consistency, binary images matching source images, same kernel bugs apply to everyone.  But yeah, I'm willing to fudge it on a beta.
-queuebot:#ubuntu-release- Unapproved: gnome-software (yakkety-proposed/main) [3.20.1+git20160617.1.0440874.ubuntu-xenial-0ubuntu2 => 3.20.1+git20160923.2.7374bdc-0ubuntu1] (ubuntu-desktop)
<nacc> cjwatson: ack, i'll dig into it more
<flexiondotorg> infinity, OK.
<flexiondotorg> I can smoke test Ubuntu MATE and Ubuntu.
<slangasek> infinity: are there any of these kernel bugs that we think are a problem on those images we haven't already respun for?
<cjwatson> nacc: those SyntaxErrors in the log don't look great either
<flexiondotorg> If a respin happens.
<flexiondotorg> But not PowerPC.
<nacc> cjwatson: yeah, i wonder if it only is python2 compatible in practice?
<davmor2> infinity: whatever it is it can't be worse that not being able to boot it
<infinity> davmor2: Not being able to boot is actually not the worst bug a kernel can have, by far. :P
<flexiondotorg> infinity, If a respin is on the cards on chance ubuntu-mate-welcome can be moved from proposed to release?
<infinity> Unbootable is the ultimate in security.
<ogra_> and saves power !
<infinity> flexiondotorg: If, yes.  Still mulling it all over.
<flexiondotorg> s/on/any/
<ogra_> green kernel
<slangasek> yes, "ohai I set your GPU on fyur" is a worse kernel bug
<nacc> cjwatson: ah, looks like very recently they made it python2 and python3 compatible in the source, but probably not packaged yetd. Also, note this is a delete line, in particular, because we don't actually ship the python files
<davmor2> ogra_: no it doesn't it spins up the system and leaves it in a loop of some sort so it would use more power ;)
-queuebot:#ubuntu-release- Unapproved: gnome-software (xenial-proposed/main) [3.20.1+git20160617.1.0440874.ubuntu-xenial-0ubuntu1~16.04.1 => 3.20.1+git20160923.2.7374bdc-0ubuntu1~xenial1] (ubuntu-desktop)
<ogra_> pffft
<davmor2> ogra_: snappy fixes it though right ;)
<ogra_> definitely !
<Odd_Bloke> Then you can rollback from the kernel that leaves your system in a loop to one that just doesn't boot!
<ogra_> yeah, aint we great ?
<infinity> slangasek: Anyhow, I'm going to wait for a tiny bit more testing to roll in, promote the new kernel, and respin server for the "it can't even smoketest" thing.
<infinity> slangasek: And then we can take a decision on skew versus retesting, blah blah.
<infinity> Also, I need food of some sort.
<slangasek> infinity: ok
<slangasek> infinity: fwiw xnox and I kind of agree that using ATA for the smoketests is probably not the best anyway, since that's not a representative test
<infinity> slangasek: I don't disagree.
<slangasek> of course, fixing that may not be faster than respinning with the new kernel
<slangasek> powersj: ^^ not a blocker for beta AIUI, but IMHO the server smoketests should be changed to use something closer to a "default" libvirt config instead of one that trips over this particular ATA driver problem
<powersj> slangasek, ok I believe that means modifying utah to use something different. Is there a suggested qemu command line option or libvit change?
<davmor2> infinity: oh and don't forget to mention that unity8 is on by default yet :(
<davmor2> isn't on even
<slangasek> powersj: xnox might be able to provide some input there
<slangasek> powersj: but he may be EOD; so perhaps log a bug against whatever's the right place for utah, and subscribe him?
<slangasek> davmor2: "on by default"?
<powersj> slangasek, yep, I have avoided messing with utah so far :)
 * wxl quickly marks Lubuntu as ready to avoid having to retest because of this silly respin idea
<davmor2> slangasek: unity8 session will be on the final desktop image but the mir's didn't finish yet so it isn't on in the beta
<slangasek> powersj: I do see from the scripts that utah is driving qemu via libvirt, so it'll be all xml
<davmor2> slangasek: unless you do netboot installs
<slangasek> davmor2: you said "on by default", it's not going to be the default...
<slangasek> just making sure we're on the same page :)
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate amd64 [Yakkety Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Yakkety Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Yakkety Beta 2] has been marked as ready
-queuebot:#ubuntu-release- Builds: Lubuntu Alternate i386 [Yakkety Beta 2] has been marked as ready
<davmor2> slangasek: and then underneath said isn't on even :)
<slangasek> infinity: is there a release notes page up btw?
<davmor2> slangasek: I missed the n't
<nacc> cjwatson: sending a fix for the syntax errors upstream
-queuebot:#ubuntu-release- Unapproved: accepted kconfig [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<xnox> powersj, davmor2, slangasek - to get sample configs (qemu command line) I would use vm-manager to graphically change cdrom from IDE bus to SATA bus, or SCSI bus. Then it uses e.g. -device scsi-cd,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0,bootindex=1
<xnox> not sure what we want to test, most people dd the iso to a usb stick these days and boot. so maybe providing a usb device to the VM might be a more realistic example =)
<xnox> together with scsi cdrom boot test.
<davmor2> xnox: I use hardware mostly, there's no easy way to test nvidia and amd setups and amd cpu vs intel cpu
<xnox> true.
<xnox> davmor2, and what bus do normal machines use for cdrom these days?
 * xnox has not had a CDROM for 6 years now
<davmor2> xnox: sata on the whole
<xnox> and i believe qemu defaults to IDE for cdroms
<xnox> which is a mismatch with reality
<powersj> Is there a plan to get the often default, IDE cdrom to work?
<slangasek> powersj: yes, the next kernel should fix that
<powersj> slangasek, great!
<slangasek> it's just a bad smoketest because only people using qemu from the commandline, and booting the server ISO instead of a cloud image, are affected
<slangasek> (affected by this default)
<davmor2> xnox: you can change it with the -drive command but I have to go now so you would need to look it up
-queuebot:#ubuntu-release- Unapproved: accepted kconfigwidgets [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtmir-gles [sync] (yakkety-proposed) [0.4.8+16.10.20160909-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-system-settings [sync] (yakkety-proposed) [0.4+16.10.20160916-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted unity8 [sync] (yakkety-proposed) [8.14+16.10.20160922-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted qtmir [sync] (yakkety-proposed) [0.4.8+16.10.20160909-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted unity-api [sync] (yakkety-proposed) [7.119+16.10.20160909-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: animals (yakkety-proposed/universe) [201207131226-1build1 => 201207131226-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: libweather-com-perl (yakkety-proposed/universe) [0.5.3-2 => 0.5.3-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: ndiswrapper (yakkety-proposed/universe) [1.60-2 => 1.60-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted animals [sync] (yakkety-proposed) [201207131226-2]
-queuebot:#ubuntu-release- Unapproved: accepted ndiswrapper [sync] (yakkety-proposed) [1.60-3]
-queuebot:#ubuntu-release- Unapproved: kdesu (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted libweather-com-perl [sync] (yakkety-proposed) [0.5.3-3]
-queuebot:#ubuntu-release- Unapproved: kdesignerplugin (yakkety-proposed/universe) [5.24.0-0ubuntu1 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted kcoreaddons [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kcrash [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kdbusaddons [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<nacc> cjwatson: so did some digging and it seems like pacemaker's cts/Makefile has that path hardcoded at build-time. BUt we end up not shipping any of the cts (which is the testsuite) for pacemaker in any package. So is it reasonable to just not build it at all?
-queuebot:#ubuntu-release- Unapproved: accepted kdeclarative [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<cjwatson> nacc: sorry, you're well past what I know about pacemaker (~nothing) at this point
<nacc> cjwatson: yeah, kinda in the same boat :)
<nacc> cjwatson: thanks for your guidance so far, though!
<nacc> it feels like a lot of work just to delete a bunch of files to have it put the files in right place -- but it's probably good to do it right now
<nacc> barry: would you be a good reference for a dh_python3 question? :)
-queuebot:#ubuntu-release- Unapproved: accepted kded [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: snapcraft (yakkety-proposed/universe) [2.18+16.10 => 2.18.1+16.10] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (yakkety-proposed) [2.18.1+16.10]
-queuebot:#ubuntu-release- Unapproved: kdelibs4support (yakkety-proposed/universe) [5.24.0-0ubuntu2 => 5.26.0-0ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: ghostscript (yakkety-proposed/main) [9.19~dfsg+1-0ubuntu4 => 9.19~dfsg+1-0ubuntu5] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted kdelibs4support [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: zeromq3 (yakkety-proposed/universe) [4.1.5-2ubuntu3 => 4.1.5+git20160811+2fc86bc-0ubuntu2] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: unity-scopes-api (yakkety-proposed/universe) [1.0.6+16.10.20160617-0ubuntu2 => 1.0.7+16.10.20160921-0ubuntu2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: zmqpp (yakkety-proposed/universe) [3.2.0-0ubuntu4 => 4.1.2-0ubuntu1] (no packageset) (sync)
<barry> nacc: possibly :)
-queuebot:#ubuntu-release- Unapproved: accepted kdesignerplugin [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<nacc> barry: so i'm trying to fix the ftfbs of pacemaker, which is due to a line like `rm -r debian/tmp/usr/lib/python2.7/dist-packages/cts`. This doesn't work with python3, obviously, and ends up failing the build with no-arch-all builds. When i looked in the schroot, though, the resulting path was debian/tmp/usr/lib/python3.5/site-packages/cts -- rather than the expected
<nacc> debian/tmp/usr/lib/python3/dist-packages/cts. And I'm not sure I understand why. The package currently doens't use dh_python{,3} and really I just need to `rm` the correct directory (no python files are shipped)
<barry> nacc: i believe that one of the things that dh_python3 does is exactly that move (after verification) of .../python3.5 -> .../python3.  it will only do that after it checks that the contents of .../python3.X is the same for all X (and we've run into rare cases where that doesn't happen, so you still end up with python3.4, python3.5, etc. directories.  not on ubuntu though because right now we only have 3.5, but think about e.g. when 3.6
<barry> is released
<barry> nacc: so dh_python3 is doing that and if you're not using it, you have to fiddle with things manually
<nacc> barry: ah i see, so i could in theory invoke dh_python3 from rules and it might dtrt?
<barry> nacc: in theory :)
<barry> nacc: the only thing is to get the timing right
-queuebot:#ubuntu-release- Unapproved: accepted kdesu [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kdewebkit [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<nacc> barry: right, that's what i'll need to read up on :) after build but before install seems to be the right place
<barry> nacc: it *might* be after install, because without that things might not be in right place.  i don't remember exactly, but you can probably figure it out with some experimentation
<nacc> barry: yeah, the issue is the rm is being done as the first thing in override_dh_install
<nacc> barry: but i think you've pointed me in the right direction :)
<barry> nacc: cool, good luck!  i'll need to do a quick reboot in a few moments, but i'll be back (hopefully :) if you have more questions
<nacc> barry: thanks!
<slangasek> acheronuk: extra-cmake-modules has been failing its autopkgtests since May; is someone taking responsibility for this? http://autopkgtest.ubuntu.com/packages/e/extra-cmake-modules/yakkety/armhf
-queuebot:#ubuntu-release- Unapproved: accepted kdnssd-kf5 [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: probert (yakkety-proposed/universe) [0.0.7 => 0.0.9] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted probert [source] (yakkety-proposed) [0.0.9]
<acheronuk> slangasek: I'm relatively new with that side of things, but I will check..
<slangasek> acheronuk: ok :)
-queuebot:#ubuntu-release- Unapproved: subiquity (yakkety-proposed/universe) [0.0.15 => 0.0.18] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted subiquity [source] (yakkety-proposed) [0.0.18]
-queuebot:#ubuntu-release- Unapproved: accepted kdoctools [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kemoticons [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<nacc> barry: ok, i think i figured out why, at least, dh_python{2,3} wasn't already being used. There are no python{,3}- packages, nor are there any with ${python3:Depends}. To be clear, this is a really weird case. Upstream has set of python files under cts/ which are used for testing only. They are not intended to be shipped by any debian/ubuntu package. My original debdiff works for this case, but looks
<nacc> weird.
<slangasek> beta release notes skeleton up: https://wiki.ubuntu.com/YakketyYak/ReleaseNotes
<slangasek> cyphermox: ^^ can you please make sure the no-uefi-on-qemu bug gets documented there?
<tkamppeter> Hi, I have uploaded Ghostscript (not yet approved) and need to do another fix in it now. How to proceed? Simply upload Ghostscript again with the same release number?  Or with the release number +1?
-queuebot:#ubuntu-release- Unapproved: accepted kfilemetadata-kf5 [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<barry> nacc: so it's an app but not a library?
<nacc> barry: not sure how to answer that, the underlying code that's being rm'd in the install target is an application (called cts afaict)
<barry> nacc: if it's shipping files under cts/ and importing them under that package name but doesn't intend for that to be a public api importable by third parties, then yeah dh_python3 may not be entirely useful, although i have used it in those cases
<nacc> barry: i think that's the source of confusion. No files under cts/ are to be shipped
<slangasek> tkamppeter: you can reuse the version number and I'll dump the one currently in the queue
<nacc> that's what the one line in the override_dh_install effectively is doing (afaict), it's deleting any such potential files
<jderose> slangasek: i can add the bit about qemu+uefi no-go to the notes, since i filed the bug. on it now...
<barry> nacc: okay, then it makes sense.  probably just want to rm ../python3.*/dist-packages?
<tkamppeter> slangasek, OK, let us do it this way. Thank you.
<barry> nacc: ie you don't care which version of python3 was used
-queuebot:#ubuntu-release- Unapproved: rejected ghostscript [source] (yakkety-proposed) [9.19~dfsg+1-0ubuntu5]
<jderose> slangasek: cyphermox says it effects most thinkpads also, so i'll mention that also
<nacc> barry: i'd say so, except 'it' (whereby i mean `make`) has put them in python3.5/site-packages
<cyphermox> jderose: don't worry, I'm listing it as soon as the wiki lets me through
<slangasek> huh
<slangasek> lucky we didn't get this SRUed into xenial yet, then
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (xenial-proposed/main) [0.122ubuntu8.1 => 0.122ubuntu8.2] (core)
<barry> nacc: ah, right it's probably not using setuptools
<barry> nacc: ie, our hacked version thereof :)
<nacc> barry: correct, it's not
<slangasek> lamont, cyphermox: ^^ so one of you has uploaded, then - thanks ;)
<jderose> cyphermox: ah, okay. or we could have one more person racing for the lock to add fun :) just kidding, it's all you
<barry> nacc: that's why it doesn't end up in dist-packages
<nacc> barry: so i wonder if it could do 'rm debian/tmp/usr/lib/python*/*packages/cts' ?
<cyphermox> 503...
<nacc> barry: that would catch either case?
<nacc> barry: and also the case for python2 if that was to be the case on debian?
<barry> nacc: yep, and yep
<nacc> barry: ack, let me try that then
<nacc> barry: thanks for being patient and helping clarify!
<barry> nacc: yw!
<lamont> slangasek: working through it
<cyphermox> slangasek: when I said affects thinkpads, I meant that it doesn't only fail to boot the ISO on qemu, but also on actual hardware.
<slangasek> cyphermox: yes, that's what I understood you to mean
<cyphermox> so SRUing that to other releases wouldn't have been an issue... except for building the dailies
<lamont> slangasek: and thanks to smoser, we can test trivially from -proposed!!  /me owes that man a $BEVERAGE
<slangasek> but that means nobody's run yakkety on a thinkpad in a month?
<cyphermox> no
<slangasek> oh, the bug only applies when shim == /EFI/boot/bootx64.efi?
<cyphermox> yes
<slangasek> gotcha
<barry> yikes, i just noticed that kernel 4.8.0-15 hangs during boot in my vm, but 4.4.0-9136 works okay
-queuebot:#ubuntu-release- Unapproved: isc-dhcp (xenial-proposed/main) [4.3.3-5ubuntu12.2 => 4.3.3-5ubuntu12.3] (core)
<slangasek> so it affects people running ubuntu-core on their thinkpads ;)
<barry> i see 4.8.0-16.17 is in proposed though, so i wont start bisecting until that lands and is tested
<cyphermox> slangasek: and it seems dependent on the actual firmware too, as jderose has it working on hardware, from what I understand
<cyphermox> slangasek: probably
<slangasek> barry: what sort of vm?
<cyphermox> slangasek: I expect Dell hardware might break too.
<barry> slangasek: fusion 8.5
<cyphermox> (but I don't have Dell EFI harware)
<slangasek> barry: 4.8.0-15 is still likely to go out as the beta kernel for a number of flavors
<barry> slangasek: maybe i should look more closely then.  i always take a snapshot when dist-upgrading, so i can revert and bisect the package list.  it just takes a while
-queuebot:#ubuntu-release- Unapproved: open-iscsi (xenial-proposed/main) [2.0.873+git0.3b4b4500-14ubuntu3 => 2.0.873+git0.3b4b4500-14ubuntu3.1] (ubuntu-desktop, ubuntu-server)
<slangasek> cyphermox: while you're editing, please fix the missing '>' at the end of 'Less Popular Ubuntu Images' :)
<cyphermox> done.
-queuebot:#ubuntu-release- Unapproved: accepted kglobalaccel [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- New binary: linux-signed-lts-trusty [amd64] (precise-proposed/main) [3.13.0-97.144~precise1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-97.144] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: accepted kguiaddons [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<nacc> barry: http://paste.ubuntu.com/23221902/ , thoughts?
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-trusty [amd64] (precise-proposed) [3.13.0-97.144~precise1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-97.144]
<barry> nacc: i'd put that comment in d/rules instead of d/changelog, but otherwise +1
<gaughen> barry, could you try what's in -proposed?
<gaughen> slangasek, do you think that would be useful ^^. cloud-images is going to go out with the kernel in proposed, so I'd like to have an idea if there's trouble lurking sooner rather than later.
<barry> gaughen: can do, but i want to narrow down the package set first.  generally on boot problems i restore a known good snapshot (if i've been smart enough to capture ;) and then narrow it down to the 1 or 2 offending packages.  if it's linux i'll try proposed
<gaughen> awesome
-queuebot:#ubuntu-release- Unapproved: cloud-init (yakkety-proposed/main) [0.7.8-4-g970dbd1-0ubuntu1 => 0.7.8-8-g0439d8a-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)
<lamont> slangasek: smoser's tossing a new upload of cloud-init at xenial-proposed, and beyond that it's my uploads of isc-dhcp, open-iscsi, and initramfs-tools.
<lamont> slangasek: as always, thank you for your assistance.
<lamont> oh haha.
<lamont> dammit cyphermox
-queuebot:#ubuntu-release- Unapproved: ghostscript (yakkety-proposed/main) [9.19~dfsg+1-0ubuntu4 => 9.19~dfsg+1-0ubuntu5] (desktop-core, ubuntu-server)
<lamont> slangasek: I owe you a new initramfs-tools with the Breaks.
<slangasek> mmk
-queuebot:#ubuntu-release- Unapproved: accepted khtml [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<flexiondotorg> Any decision on if there is a respin coming?
<nacc> barry: ack! good point :)
<slangasek> acheronuk: why does your ki18n upload replace the python:any dep with python?
<tkamppeter> slangasek, Ghostscript is re-uploaded now.
<lamont> slangasek: actually... thoughts?  initramfs-tools will break isc-dhcp << 4.3.3-5ubuntu12.3, and also 4.3.3-5ubuntu13.early... can I even capture that in Breaks: ?
-queuebot:#ubuntu-release- Unapproved: accepted ki18n [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.18 => 2.18.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.8-1-g3705bb5-0ubuntu1~16.04.1 => 0.7.8-8-g0439d8a-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
<slangasek> lamont: you can have disjoint sets of versions in breaks... Breaks: isc-dhcp (<< 4.3.3-5ubuntu12.3), isc-dhcp (= 4.3.3-5ubuntu13)
<slangasek> addressing it for knock-off builds of 4.3.3-5ubuntu13 isn't critical
<slangasek> tkamppeter: cheers
<lamont> slangasek: oh, goodl
<nacc> barry: does this seem better? http://paste.ubuntu.com/23221941/
<barry> nacc: looks great!
-queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.2]
-queuebot:#ubuntu-release- Unapproved: rejected isc-dhcp [source] (xenial-proposed) [4.3.3-5ubuntu12.3]
-queuebot:#ubuntu-release- Unapproved: cloud-initramfs-tools (yakkety-proposed/main) [0.28ubuntu1 => 0.29ubuntu1] (edubuntu, ubuntu-server)
<sergiusens> slangasek when you have time can you look into letting snapcraft 2.18.1 into xenial-proposed (yakkety is still running though)
-queuebot:#ubuntu-release- Unapproved: accepted kiconthemes [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: pacemaker (yakkety-proposed/main) [1.1.15-1ubuntu1 => 1.1.15-1ubuntu2] (ubuntu-server)
<nacc> doko: --^ should fix pacemaker
<slangasek> sergiusens: I can commit to getting it reviewed today; or do you need a queue jump so I can unblock you before your EOD?
<nacc> i'm sending the same to debian as i type
<cjwatson> nacc: oh, you know what, in my earlier remarks I totally failed to notice that that was on a rm command
<nacc> cjwatson: it's ok :) i should have made that clearer!
<nacc> cjwatson: still learned something about dh_python3, so it's all good :)
<sergiusens> slangasek your EOD is fine; I am EOD 7 minutes ago :-)
<cjwatson> nacc: so I apologise for the confusion - I agree that just turning that into a wider glob seems right
<slangasek> sergiusens: copy
<nacc> cjwatson: np! thanks!
-queuebot:#ubuntu-release- Unapproved: accepted kidletime [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kimageformats [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<slangasek> infinity: linux 4.8.0.16 is currently lingering in -proposed.  that's the one needed for fixing server, correct?  Were you planning to bypass autopkgtests to promote it, or are we waiting for those to clear?
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (xenial-proposed/main) [0.122ubuntu8.1 => 0.122ubuntu8.2] (core)
-queuebot:#ubuntu-release- Unapproved: open-iscsi (xenial-proposed/main) [2.0.873+git0.3b4b4500-14ubuntu3 => 2.0.873+git0.3b4b4500-14ubuntu3.1] (ubuntu-desktop, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: isc-dhcp (xenial-proposed/main) [4.3.3-5ubuntu12.2 => 4.3.3-5ubuntu12.3] (core)
<acheronuk> slangasek: looks like that python change was a result of a script meant to bump frameworks build deps for all our frameworks. I'm checking to see if that was an unintended side effect
<lamont> slangasek: all 4 are in the queue
-queuebot:#ubuntu-release- Unapproved: accepted kinit [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<slangasek> acheronuk: ok, cheers.  next up, kio has "Remove a couple of deprecated symbols".  Why is removing these symbols not an ABI-breaking change requiring a binary package name change?
<slangasek> (the whole point of symbols files is to guard against accidentally breaking your reverse-dependencies)
<barry> gaughen: okay, so it's definitely the kernel.  upgrading all other packages gives me a usable system.  will try proposed now
<barry>  
-queuebot:#ubuntu-release- Unapproved: accepted kitemmodels [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected open-iscsi [source] (xenial-proposed) [2.0.873+git0.3b4b4500-14ubuntu3.1]
<acheronuk> slangasek: the author of that commit is the same person I need to ask on the other, so I will deal with that tomorrow OK? He's gone out for a few 'refreshments' and is not best placed to respond right now
<slangasek> acheronuk: ok
-queuebot:#ubuntu-release- Unapproved: accepted kitemviews [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<slangasek> lamont: your isc-dhcp upload has debian/initramfs-tools cruft in the diff
<lamont> sigh
<slangasek> lamont: er, sorry, hangon
<slangasek> lamont: it's not cruft, it's just me jumping to conclusions before reading all the way through ;)
<lamont> haha
 * lamont does the debdiff anyway
<lamont> yeah - that looks just like I expect it to
<slangasek> ok, so the thing I still don't like about this is that we're making everyone's initramfs .5MB bigger (uncompressed) in SRU
<slangasek> if we were dropping klibc in the same go, that would be a fair trade
<lamont> fair point..  I understand killing klibc with fire is in-plan, at least..
 * lamont cannot speak to the decision process involved there..
-queuebot:#ubuntu-release- Unapproved: accepted kjobwidgets [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kjs [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<slangasek> cyphermox, lamont: can one of you explain /run/net-eth0.conf to me, briefly?  what consumes that?
<lamont> cloud-init
<lamont> it's a bunch of config vars which then get sourced and used
<slangasek> ok
<slangasek> and did something else do this elsewhere, before dhclient?
<lamont> and open-iscsi (hahahaha *sob*) is the one that creates resolv.conf
<lamont> I. Don't. Even.
<lamont> klibc's ipconfig
<lamont> the change was "use dhclient, and make the output look like ipconfig did  it"
<slangasek> so, no, klibc's ipconfig did not do this
<lamont> with the logical change being the s/4/6/
<slangasek> the code is in /usr/share/initramfs-tools/scripts/functions
<lamont> ok. that
 * lamont was fuzzy on what exactly did the writing
<lamont> I do know that it went from synchronous to async (now done in dhclient hooks)
<slangasek> this leaves me wondering if dhclient is the right package to own this, or if it belongs in initramfs-tools
<barry> gaughen: 4.0.8-16 from -proposed is *not* happy.  i can't tell exactly wheere it's hanging but the last thing on my console is "Started Bluetooth service".  now it's just sitting there
<bjf> apw, ^
<barry> gaughen: happy to report bug, do more analysis, etc if you can point me to the right incantations
<barry> or apw :)
<bjf> barry, we need a bug
<barry> bjf: okay.  can't ubuntu-bug it obviously.  file on linux-meta or linux?
<bjf> barry, do any of the 4.8 kernels work for you?
<barry> bjf: nope
<bjf> barry, "linux"
<barry> 4.4 does tho
<slangasek> lamont: oh - nope, you're right, it's ipconfig spitting this out and initramfs-tools is just picking it up once available
-queuebot:#ubuntu-release- Unapproved: accepted kjsembed [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<barry> bjf, apw, gaughen LP: #1627198
<ubot5`> Launchpad bug 1627198 in linux (Ubuntu) "4.4.8 kernels do not complete boot process on VM" [Undecided,New] https://launchpad.net/bugs/1627198
<barry> i'll be around for a while so ping me if you need more information
-queuebot:#ubuntu-release- Unapproved: accepted kmediaplayer [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<slangasek> lamont, cyphermox: the Breaks: ensure that if there is a dhclient available, it's the one that has the initramfs hook support.  The Breaks: do not guarantee that dhclient is available.  I guess we're ok with this because isc-dhcp-client is in minimal?
<lamont> that's my thinking - I verfied that I was conssitent with yakkety
<slangasek> and if it's ok to not use Depends: because we know isc-dhcp-client is always available, is there really any reason not to make it a versioned Depends: anyway?
<lamont> slangasek: I would have no objection
<Saviq> can someone please push qtmir, qtmir-gles, ubuntu-system-settings, unity-api, unity8 through the unapproved queue?
<slangasek> Saviq: I can, but it'll be a bit; somewhat contended, sorry
<lamont> esp if we don't care about the one-off in current yakkety
<lamont> and just go >= isc-dhcp.$UPLOAED
<Saviq> slangasek, as long as it happens...
<slangasek> lamont: maybe still keep the Breaks: (=)
<lamont> ah, works
<slangasek> cyphermox: ^^ thoughts?
-queuebot:#ubuntu-release- Unapproved: accepted knewstuff [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<lamont> slangasek: so...
<lamont> Depends: initramfs-tools-core (= ${binary:Version}), linux-base, ${misc:Depends}, isc-d
<lamont> hcp-client (>= 4.3.3-5ubuntu12.3)
<lamont> Breaks: ... isc-dhcp-client (<< 4.3.3-5ubuntu12.3), isc-dhcp-client (= 4.3.3-5ubuntu13)
<lamont> yes?
-queuebot:#ubuntu-release- Unapproved: accepted knotifications [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<slangasek> lamont: or just Breaks: isc-dhcp-client (= 4.3.3-5ubuntu13)
<lamont> slangasek: oh, right,k because of the versiuoned dep.  doh
<lamont> so just the equals
 * slangasek nods
<lamont> you wann push the mulligan button then?
-queuebot:#ubuntu-release- Unapproved: accepted knotifyconfig [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<lamont> slangasek: say when and I'll re-upload initramfs-tools
-queuebot:#ubuntu-release- Unapproved: open-iscsi (xenial-proposed/main) [2.0.873+git0.3b4b4500-14ubuntu3 => 2.0.873+git0.3b4b4500-14ubuntu3.1] (ubuntu-desktop, ubuntu-server)
<lamont> and open-iscsi should have bug # now
<slangasek> lamont: yah, since cyphermox isn't weighing in, go for it
<slangasek> (initramfs-tools)
<lamont> pay no attention to the duplicate isc-dhcp upload then
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (xenial-proposed/main) [0.122ubuntu8.1 => 0.122ubuntu8.2] (core)
-queuebot:#ubuntu-release- Unapproved: isc-dhcp (xenial-proposed/main) [4.3.3-5ubuntu12.2 => 4.3.3-5ubuntu12.3] (core)
<infinity> slangasek: I was planning to hint in -16 once I had a few results to say it wasn't entirely broken.
<slangasek> infinity: results of what sort?
<infinity> slangasek: Some autopkgtest results that show it installs and reboots and one or two dkms modules still work, that sort of thing.
<slangasek> infinity: mmk. so is x86 autopkgtest stalled? a lot of 'Test in progress' there
<infinity> slangasek: I'd say kde ate the queue. :/
<slangasek> hmm
<slangasek> those were all released after linux-meta, I thought
<slangasek> apw: ^^
 * lamont afk
<valorie> we ate the queue?
<valorie> oh my
<slangasek> not really
<slangasek> I think the runners are AWOL
<slangasek> infinity: http://autopkgtest.ubuntu.com/running shows precisely 2 running amd64 tests and 0 for i386
<slangasek> so our runners are missing
<slangasek> pitti: halp
<infinity> slangasek: That seems suboptimal indeed.
<infinity> slangasek: We can just smoketest this x86 the old fashioned way.
<infinity> ogasawara: *bat signal*
-queuebot:#ubuntu-release- Unapproved: tickcount (yakkety-proposed/main) [0.1-0ubuntu17 => 0.1-0ubuntu18] (ubuntu-server)
<infinity> slangasek: Spinning up two VMs to smoketest amd64 and x86, then will unblock.
<infinity> s/x86/i386/
<slangasek> infinity: ack
<tsimonq2> :O
<infinity> amd64 installs/reboots and looks good.
<ogasawara> infinity: ack
<infinity> Bonus points, that was on an old skool ATA qemu interface, not virtio.
-queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.2]
<tsimonq2> y'all need netboot testing?
<tsimonq2> I can help
<infinity> And i386 same story.  So hinting.
<slangasek> infinity: cheers
<slangasek> lamont: sorry, I should get better at doing single pass reviews
<slangasek> +       set -x
<slangasek> lamont: ^^ is that really expected?
<slangasek> looks like development cruft that should've been dropped
<slangasek> cyphermox: ^^?
-queuebot:#ubuntu-release- Unapproved: rejected open-iscsi [source] (xenial-proposed) [2.0.873+git0.3b4b4500-14ubuntu3.1]
-queuebot:#ubuntu-release- Unapproved: rejected isc-dhcp [source] (xenial-proposed) [4.3.3-5ubuntu12.3]
<slangasek> lamont: lastly... LP: #1621507 includes no test case or regression risk analysis
<ubot5`> Launchpad bug 1621507 in isc-dhcp (Ubuntu) "initramfs-tools configure_networking() fails to dhcp ipv6 addresses" [High,In progress] https://launchpad.net/bugs/1621507
-queuebot:#ubuntu-release- Unapproved: accepted kpackage [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<slangasek> Saviq: ah, so you had asked about putting them through the unapproved queue... they did go through the queue already and are just stalled in proposed now, I thought you were asking after the latter
<Saviq> slangasek, yeah, but that happened just around the time I asked you, or at least that was their status then - I saw they're in proposed now, thanks
<slangasek> Saviq: actually they were accepted about 3 hours before you asked <shrug> :)
<slangasek> but no worries
<Saviq> yeah, must've been stale data on my side
-queuebot:#ubuntu-release- Unapproved: accepted libphonenumber [sync] (yakkety-proposed) [7.1.0-5ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-keyboard [sync] (yakkety-proposed) [0.100+16.10.20160921-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-keyboard [sync] (yakkety-proposed) [0.100+16.10.20160921-0ubuntu1]
#ubuntu-release 2016-09-24
<ogasawara> slangasek, infinity: so where has 4.8.0-16 gone?  I'm not seeing it in proposed or the release pocket.
<tsimonq2> !info linux-generic
<ubot5`> linux-generic (source: linux-meta): Complete Generic Linux kernel and headers. In component main, is optional. Version 4.4.0.38.40 (xenial), package size 1 kB, installed size 12 kB
<tsimonq2> !info linux-generic yakkety
<ubot5`> linux-generic (source: linux-meta): Complete Generic Linux kernel and headers. In component main, is optional. Version 4.8.0.15.24 (yakkety), package size 1 kB, installed size 12 kB
<tsimonq2> !info linux-generic yakkety-proposed
<ubot5`> linux-generic (source: linux-meta): Complete Generic Linux kernel and headers. In component main, is optional. Version 4.8.0.16.26 (yakkety-proposed), package size 1 kB, installed size 12 kB
<tsimonq2> ogasawara: you sure ^
<tsimonq2> ?
<infinity> ogasawara: It's migrating.
<infinity> ogasawara: There's a weird limbo between the copy and delete where it doesn't list as "published" anywhere.
<ogasawara> tsimonq2, infinity: thanks, am seeing it now
<cyphermox> slangasek: indeed, I'll remove that
<lamont> slangasek: not sure how I would write a test case that was anything like a unit-test.  Regression risk analysis all comes down to initramfs-tools changes (everything else is just accepting the new ENV vars from it)
<lamont> cyphermox: I think you're the best (only?) one to do the regression analysis on initramfs-tools
<lamont> slangasek: uh, yeah... I should drop the set -x
 * lamont gives cyphermox an odd look
<lamont> slangasek: new initramfs in bound.
 * lamont is starting to regret jumping on this handgrenade.
 * lamont goes to read up on the SRU process so that he can comply
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (xenial-proposed/main) [0.122ubuntu8.1 => 0.122ubuntu8.2] (core)
<lamont> slangasek: for other hilarity, it turns out that the target for testing is "enlist, commission, and then deploy yakkety"  which means needing working ivp6 netboot in initramfs in images for both xenial (enlist, commission), and yakkety (deploy)
<slangasek> <cough>
<lamont> so what I'm saying is, don't let me slow down the beta!
<slangasek> :-)
-queuebot:#ubuntu-release- Unapproved: rejected initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.2]
-queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (xenial-proposed) [4.3.3-5ubuntu12.3]
<lamont> slangasek: cyphermox 1621507 updated.  any comments/changets welcome
<lamont> slangasek: I promise to pester smoser until one of us does a full writeup for his cloud-init upload
<lamont> and I think that klibc/ubuntu (xenial and yakkety) wants to be 'wontfix' on bug 1621507, but I'll leave that to cyphermox next week
<ubot5`> bug 1621507 in isc-dhcp (Ubuntu) "initramfs-tools configure_networking() fails to dhcp ipv6 addresses" [High,In progress] https://launchpad.net/bugs/1621507
<lamont> slangasek: I'll plan on rolling new xenial stuff from -proposed first thing in the morning, assuming all 4 packages are waiting for me there.
<lamont> xenial that is.. the ones in yakkety-proposed were decidedly yummy when I tested them earlier today
<lamont> with that, I'm gone for a while
<slangasek> I think klibc wants to be "let's figure out how to ditch this from the initramfs"
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.2]
<slangasek> ogasawara, apw: linux published, ubuntu-server now respinning; ETA 50 minutes for images
<ogasawara> slangasek: thanks, I've got the troops on standby
-queuebot:#ubuntu-release- Unapproved: accepted open-iscsi [source] (xenial-proposed) [2.0.873+git0.3b4b4500-14ubuntu3.1]
<slangasek> lamont: hmm, looking at the cloud-init SRU now, and I see that it's "New upstream snapshot" with changes for which we have no SRU bugs
-queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Yakkety Beta 2] has been updated (20160924)
-queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Yakkety Beta 2] has been updated (20160924)
-queuebot:#ubuntu-release- Builds: Ubuntu Server i386 [Yakkety Beta 2] has been updated (20160924)
-queuebot:#ubuntu-release- Builds: Ubuntu Server powerpc [Yakkety Beta 2] has been updated (20160924)
-queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Yakkety Beta 2] has been updated (20160924)
-queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Yakkety Beta 2] has been updated (20160924)
<slangasek> bdmurray: dkms> you mention that 'apport version 2.5.3 returns the package name', does that mean we don't need to maintain support for the old string because it's obsolete since before trusty?
<slangasek> ogasawara: ^^ ubuntu server builds
<ogasawara> slangasek: thanks, will start testing
<ogasawara> slangasek: just to confirm, we only need testing for Ubuntu Server respins?  or do we expect others.
<slangasek> ogasawara: server only
<ogasawara> slangasek: ack
<slangasek> bdmurray: (right, that's exactly what the bug log says - accepting)
-queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (xenial-proposed) [2.2.0.3-2ubuntu11.3]
<ogasawara> slangasek: fyi...bjf and I are grabbing amd64 and i386 ubuntu server
<slangasek> ogasawara: ok. were you expecting to smoke test the other architectures also?  I'm not sure if infinity intended -16 for all archs, I guess I neglected to ask
<slangasek> but we certainly don't want to release them as beta without at least a minimal re-test
-queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (trusty-proposed) [2.2.0.3-1.1ubuntu5.14.04.9]
<ogasawara> slangasek: I don't think we have access to the other arches, at least I don't here.  I was actually hoping Foundations did?
<slangasek> ogasawara: doesn't bjf have a stable of machines? can they be borrowed for smoketesting?
<slangasek> I have access to ppc64el and s390x, but I'm also the only one around right now AFAIK :)  and I don't think I have any arm64
<lamont> slangasek: if you're more inclined, I can give you a minimal change from what's currently in -proposed
<slangasek> lamont: yeah, the one currently in the queue isn't being accepted by me as-is without explanations (see my ping of smoser on -devel), so if you can give me one without all the extras that'd be keen
<lamont> yeah
<lamont> sure
<lamont> cloud-init_0.7.8-1-g3705bb5-0ubuntu1~16.04.2_source.changes <-- slangasek
<slangasek> ogasawara, infinity: on reflection, it's *only* amd64 and i386 that are gated by the smoketests anyway; if we had good manual tests of previous images on the other archs, I think we should withdraw the 20160924 images there in favor of the already-tested ones
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.8-1-g3705bb5-0ubuntu1~16.04.1 => 0.7.8-1-g3705bb5-0ubuntu1~16.04.2] (edubuntu, ubuntu-cloud, ubuntu-server)
<slangasek> hmmm except
<ogasawara> slangasek: did we have good manual tests of the previous images?
<slangasek> the images have been garbage collected already
<slangasek> grr
<slangasek> so much for that idea
<slangasek> ogasawara: it does seem retesting is necessary
<ogasawara> slangasek: bug filed here https://launchpad.net/bugs/1627233
<ubot5`> Ubuntu bug 1627233 in linux (Ubuntu Yakkety) "Missing cdrom drivers in debian installer" [Critical,Confirmed]
<slangasek> FYI, with the latest ubuntu-server respin still not being installable, we are not going to be able to release final beta today.  Things are more or less on hold until Monday
-queuebot:#ubuntu-release- Unapproved: accepted kparts [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (xenial-proposed) [0.7.8-1-g3705bb5-0ubuntu1~16.04.2]
-queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (xenial-proposed) [0.7.8-8-g0439d8a-0ubuntu1~16.04.1]
<slangasek> lamont: reuploaded cloud-init because no bug in changelog; LP: #1621615 now also needs SRU template
<ubot5`> Launchpad bug 1621615 in cloud-init "network not configured when ipv6 netbooted into cloud-init" [Medium,In progress] https://launchpad.net/bugs/1621615
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.8-1-g3705bb5-0ubuntu1~16.04.1 => 0.7.8-1-g3705bb5-0ubuntu1~16.04.2] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted kpeople [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<slangasek> wxl: so as far as lubuntu being marked 'ready', it appears that somehow the alternate CDs were never respun against the 4.8 kernel.  So while they have not been plagued by the installation failures that the ubuntu-server images have, they also do not have the release kernel on them and I don't think are appropriate to release as final beta
<slangasek> wxl: (those installation failures are still being worked out, and thus there's no point in respinning lubuntu alternate yet - but I expect we will need to do that before releasing them)
<wxl> slangasek: i am literally on my way to dreamland, but come tomorrow i'm sure we can work something out :)
<slangasek> wxl: righty-o.  I don't know that we'll have a fixed kernel tomorrow either (I don't believe we will), so that may rather be a "monday" thing
<wxl> slangasek: sounds good. talk soon!
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [0.7.8-1-g3705bb5-0ubuntu1~16.04.2]
-queuebot:#ubuntu-release- Unapproved: accepted kplotting [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kpty [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kross [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.18.1]
-queuebot:#ubuntu-release- Unapproved: accepted krunner [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kservice [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ktexteditor [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted ktextwidgets [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kunitconversion [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal [arm64] (yakkety-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal [ppc64el] (yakkety-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal [amd64] (yakkety-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal [i386] (yakkety-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal [s390x] (yakkety-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal [armhf] (yakkety-proposed) [0.3-1]
-queuebot:#ubuntu-release- New: accepted xdg-desktop-portal [powerpc] (yakkety-proposed) [0.3-1]
-queuebot:#ubuntu-release- Unapproved: accepted kwallet-kf5 [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- New sync: xdg-desktop-portal-gtk (yakkety-proposed/primary) [0.3-1]
-queuebot:#ubuntu-release- Unapproved: easytag (yakkety-proposed/universe) [2.4.2-1 => 2.4.2-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted easytag [sync] (yakkety-proposed) [2.4.2-2]
-queuebot:#ubuntu-release- Unapproved: accepted kwindowsystem [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted kxmlgui [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: seahorse-nautilus (yakkety-proposed/universe) [3.11.92-1 => 3.11.92-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted seahorse-nautilus [source] (yakkety-proposed) [3.11.92-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-mediaplayer (yakkety-proposed/universe) [0~git20160509-3 => 0~git20160830-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-mediaplayer [sync] (yakkety-proposed) [0~git20160830-1]
-queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-top-icons-plus (yakkety-proposed/universe) [15-3 => 17-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-top-icons-plus [sync] (yakkety-proposed) [17-1]
-queuebot:#ubuntu-release- Unapproved: seahorse-sharing (yakkety-proposed/universe) [3.8.0-0ubuntu1 => 3.8.0-0ubuntu2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted seahorse-sharing [source] (yakkety-proposed) [3.8.0-0ubuntu2]
<lamont> slangasek: adding thetemplate now
<lamont> slangasek: 1621615 now has SRU template
<lamont> slangasek: (or whoever is AA and awake..) my needs: cloud-initramfs-tools 0.29ubuntu1 in yakkety-proposed.  Rolling xenial images now (for testing when I get back in 2-3 hours), unsure if I need a newer-than-xenial-proposed grub2, but we'll see.  <-- cyphermox?
<lamont> slangasek: thanks for fixing the cloud-init changelog for me.  sigh. :/
<lamont> bbl
-queuebot:#ubuntu-release- Unapproved: openscenegraph-3.4 (yakkety-proposed/universe) [3.4.0+dfsg1-1ubuntu1 => 3.4.0+dfsg1-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted openscenegraph-3.4 [sync] (yakkety-proposed) [3.4.0+dfsg1-4]
<acheronuk> slangasek: you asked about kio symbols yesterday. the guy who dropped them is still offline, but I note our debian upstream kde packaging has the as optional=depreciated. does that help?
<slangasek> acheronuk: 'optional=depreciated' - no, that doesn't explain why it's ok to drop the symbol without an soname change
-queuebot:#ubuntu-release- Unapproved: accepted kxmlrpcclient [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<lamont> I hate it whne the internet connection dies
#ubuntu-release 2016-09-25
-queuebot:#ubuntu-release- Unapproved: accepted modemmanager-qt [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted networkmanager-qt [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted oxygen-icons5 [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted plasma-framework [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted solid [source] (yakkety-proposed) [5.26.0-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted sonnet [source] (yakkety-proposed) [5.26.0-0ubuntu1]
<acheronuk> slangasek: kio - would syncing with debian changes for this be ok? https://anonscm.debian.org/cgit/pkg-kde/frameworks/kio.git/commit/debian/libkf5kiowidgets5.symbols?id=49dc81bc436d920ce3997ecccac0a92303e906b2
-queuebot:#ubuntu-release- Unapproved: yosys (yakkety-proposed/universe) [0.6-6build1 => 0.6-7] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted yosys [sync] (yakkety-proposed) [0.6-7]
-queuebot:#ubuntu-release- Unapproved: git-build-recipe (yakkety-proposed/universe) [0.3.2 => 0.3.3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted git-build-recipe [sync] (yakkety-proposed) [0.3.3]
<pitti> slangasek: hmm, they pretty much all time out waiting for ssh, and console-log has tons of "genirq: Flags mismatch irq 4. 00000000 (serial) vs. 00000080 (goldfish_pdev_bus)"
<wgrant> scalingstack?
<pitti> wgrant: no, it's the -16 kenrel
<pitti> it's completely and utterly busted on scalingstack, indeed
<pitti> -15 still works
<pitti> bug 1627052
<ubot5> bug 1627052 in linux (Ubuntu Yakkety) "4.8.0-16.17: genirq: Flags mismatch serial vs goldfish_pdev_bus" [Medium,Fix committed] https://launchpad.net/bugs/1627052
<pitti> I removed today's adt image, and restarted everything
<pitti> meh, too late, yesterday's already has -16
-queuebot:#ubuntu-release- Unapproved: nautilus-wipe (yakkety-proposed/universe) [0.2.1-3 => 0.2.1+git20160709-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted nautilus-wipe [sync] (yakkety-proposed) [0.2.1+git20160709-2]
-queuebot:#ubuntu-release- Unapproved: thermald (yakkety-proposed/main) [1.5.3-3 => 1.5.3-4] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: brasero (yakkety-proposed/universe) [3.12.1-1ubuntu4 => 3.12.1-1ubuntu5] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gnome-backgrounds (yakkety-proposed/universe) [3.21.91-1 => 3.22.0-2] (desktop-extra, ubuntugnome) (sync)
-queuebot:#ubuntu-release- Unapproved: python-tidylib (yakkety-proposed/universe) [0.2.4~dfsg-2 => 0.2.4~dfsg-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted python-tidylib [sync] (yakkety-proposed) [0.2.4~dfsg-4]
-queuebot:#ubuntu-release- New sync: qtwebchannel-opensource-src (yakkety-proposed/primary) [5.6.1-1]
-queuebot:#ubuntu-release- Unapproved: clamtk (yakkety-proposed/universe) [5.20-1 => 5.21-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted clamtk [sync] (yakkety-proposed) [5.21-1]
-queuebot:#ubuntu-release- Unapproved: dc3dd (yakkety-proposed/universe) [7.2.641-3 => 7.2.641-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted dc3dd [sync] (yakkety-proposed) [7.2.641-4]
-queuebot:#ubuntu-release- Unapproved: libinstpatch (yakkety-proposed/universe) [1.0.0-4 => 1.0.0-5] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libinstpatch [sync] (yakkety-proposed) [1.0.0-5]
-queuebot:#ubuntu-release- Unapproved: nbc (yakkety-proposed/universe) [1.2.1.r4+dfsg-1 => 1.2.1.r4+dfsg-4] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted nbc [sync] (yakkety-proposed) [1.2.1.r4+dfsg-4]
-queuebot:#ubuntu-release- Unapproved: qtquickcontrols-opensource-src (yakkety-proposed/main) [5.6.1-2build1 => 5.6.1-3] (kubuntu, qt5, ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: qtile (yakkety-proposed/universe) [0.10.6-2 => 0.10.6-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted qtile [sync] (yakkety-proposed) [0.10.6-3]
-queuebot:#ubuntu-release- Unapproved: request-tracker4 (yakkety-proposed/universe) [4.2.13-1 => 4.2.13-2] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted request-tracker4 [sync] (yakkety-proposed) [4.2.13-2]
<pitti> ok, I built some custom images with removed linux-meta, so they shouldn't dist-upgrade to 4.8.0-16
 * pitti reenables i386 and amd64 tests
<pitti> infinity, slangasek, apw: http://autopkgtest.ubuntu.com/ â incoming x86 results! \o.
<pitti> \o/ even
<pitti> and the PPA -17 kernel boots too
<pitti> not sure if the DKMS tests will actually work now with these h4x0red images (no metapages any more etc.), and the others (like systemd or lxc) won't tell us much as they won't actually dist-upgrade to -17
<pitti> so we'll need to shoehorn that in as well
<pitti> apw: http://people.canonical.com/~kernel/status/adt-matrix/canonical-kernel-team--unstable/yakkety-linux-meta.html â yay, these tests actually work against 4.8.0-17
<pitti> and by and large succeeed
<pitti> apw: so I'd say, land it in -proposed
<pitti> this hack worked better than I expected :)
 * pitti lets the machinery grind away, see you tomorrow morning
<pitti> apw, slangasek: FYI, I added a "test reboot after dist-upgrade" step to the cloud image build step, to avoid generating broken images; curious that in all those years we never had a completely broken kernel in devel-release :)
<apw> pitti, that is in part because normally adt gates the kernel ...
<mwhudson> any release team people here? can you release docker.io 1.12.1-0ubuntu12~16.04.1 from NEW on amd64?
<mwhudson> and reject the older docker.io i guess
<mwhudson> not release team
<mwhudson> archive admins
-queuebot:#ubuntu-release- Unapproved: partimage (yakkety-proposed/universe) [0.6.8-2.2ubuntu1 => 0.6.9-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted partimage [source] (yakkety-proposed) [0.6.9-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: ext4magic (yakkety-proposed/universe) [0.3.2-5 => 0.3.2-6] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted ext4magic [sync] (yakkety-proposed) [0.3.2-6]
-queuebot:#ubuntu-release- Unapproved: burp (yakkety-proposed/universe) [1.4.40-2 => 1.4.40-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted burp [sync] (yakkety-proposed) [1.4.40-3]
-queuebot:#ubuntu-release- Unapproved: libsquish (yakkety-proposed/universe) [1.13-3 => 1.14-1] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libsquish [sync] (yakkety-proposed) [1.14-1]
-queuebot:#ubuntu-release- Unapproved: gpsd (yakkety-proposed/universe) [3.16-2 => 3.16-3] (kubuntu) (sync)
-queuebot:#ubuntu-release- Unapproved: partimage (yakkety-proposed/universe) [0.6.9-1ubuntu1 => 0.6.9-3~build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted partimage [source] (yakkety-proposed) [0.6.9-3~build1]
-queuebot:#ubuntu-release- Unapproved: ubuntu-mate-welcome (yakkety-proposed/universe) [16.10.8 => 16.10.9] (ubuntu-mate)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-40.60] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-40.60]
#ubuntu-release 2017-09-18
<slangasek> doko: how does new cairocffi not require an FFe?
<tsimonq2> slangasek: On the safe side before sponsoring something... new translations don't need an FFe right?
<slangasek> tsimonq2: they do not
<tsimonq2> Ok, thanks slangasek
<doko> LocutusOfBorg: Binary only movements to main
<doko>  -----------------------------
<doko>  o libturbojpeg libturbojpeg0-dev                              {libjpeg-turbo}
<doko>    [Reverse-Depends: Rescued from libjpeg-turbo, libturbojpeg0-dev]
<doko> having this legacy API in main is something I want to really avoid :-/
<LocutusOfBorg> doko, I don't get it, if it is the new binary I introduced, I think it can live in universe...
<doko> Package: libturbojpeg0-dev
<doko> Conflicts: libjpeg-turbo8-dev
<doko> why?
<LocutusOfBorg> because I would like to make openjpeg syncable after 18.04, so I'm preparing the conflicts fields
<LocutusOfBorg> turbojpeg, whatever is called :)
<doko> LocutusOfBorg: no, you can't sync it in any case
<doko> I explained it to you before.
<doko> Ubuntu has the jpeg8 compat bits turned on, Debian has jpeg6
<LocutusOfBorg> I mean, sync the package names, with the jpeg compatibility layer added
<LocutusOfBorg> yep, sure
<LocutusOfBorg> but at least we can have the "progs" and other sub-binaries in sync
<doko> but it doesn't mean that we should support this api everywhere
<LocutusOfBorg> I don't parse this sentence
<LocutusOfBorg> maybe we can ask debian to switch to jpeg8 too
<doko> this is a legacy API, please read the docs
<doko> so I'll remove the conflicts now
<LocutusOfBorg> sorry I'm lost in the ldc merge, I don't follow exactly
<LocutusOfBorg> I'm happy to read them if you provide a link, and feel free to remove the conflict if you find it useless
<doko> it's called README, found in the sources
<LocutusOfBorg> will look while fixing ldc (I hope)
<LocutusOfBorg> doko, the change in turbojpeg broke dcm2niix /build/dcm2niix-1.0.20170818/console/nii_dicom.cpp:44:13: fatal error: turbojpeg.h: No such file or directory
<xnox> LocutusOfBorg, are you aware of Ubuntu feature freeze policy at all? just like in debian one should not be introducing new packages, merging new upstream releases, doing package reorgs, transitions, etc.
<doko> LocutusOfBorg: does this package build with the standard jpeg?
<xnox> LocutusOfBorg, one should only focus on bug-fixes.
<xnox> LocutusOfBorg, can you not wait until after 17.10 ships?
<LocutusOfBorg> xnox, I don't think I reorganized stuff, and I think I didn't break Ffe...
<LocutusOfBorg> sure, a lot of stuff is waiting for 17.10, right now I'm syncing gcc-7 build fixes
<LocutusOfBorg> doko, no
<LocutusOfBorg> it is using headers only provided by turbojpeg.h
<LocutusOfBorg> it can build without turbojpeg support
<LocutusOfBorg> doko, it uses something like "tjDecompress2"
<doko> can, or cannot?
<LocutusOfBorg> it can build without that support, it cannot use jpegturbo without that header
<LocutusOfBorg> so, if you want to remove that feature, go ahead, I don't know how much of features it will loose
<doko> I'm still trying to find out why the new packages are pulled into main, even with out the Conflicts
<xnox> slangasek, shouldn't libgles1-mesa | 17.0.7-0ubuntu0.16.04.2 | xenial-proposed  | all be published into xenial such that it is installable with libglapi-mesa that is at 17.* version in xenial-updates?
<sdeziel> hello *, I'd like to know if there is something to do to move tor from xenial-proposed to -updates? https://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#tor
<sdeziel> it currently says it's blocked due to a freeze
<LocutusOfBorg> sdeziel, xenial might take some days more, because $LTS
<LocutusOfBorg> I think next time a RT member is around, he will release it
<sdeziel> LocutusOfBorg: OK, I didn't know the baking period was longer on LTS
<LocutusOfBorg> it is at least one week, with no upper bound I would say
<LocutusOfBorg> probably it isn't longer, maybe no RT folk has got time to look and release it
<LocutusOfBorg> but it wouldn't surprise me to see a time higher for LTS releases
<apw> sdeziel, everything in stables is "blocked for freeze"
<LocutusOfBorg> *an higher time
<apw> sdeziel, that is not the report we use to work out what to release
<LocutusOfBorg> because the archive is closed
<sdeziel> I'm not sure I know what stables refers to in that context
<apw> sdeziel, stables == "not the development release"
<LocutusOfBorg> something that has been released
<sdeziel> ah
<sdeziel> this specific package comes with security fixes which is why I'd rather have it land in -updates sooner than later
<apw> sdeziel, if it has security fixes it likely should have been built in the security PPA and released to -security, but
<LocutusOfBorg> maybe pinging the person who accepted it is the best chance you have
<apw> sdeziel, it looks to be ready to release to my eye
<sdeziel> apw: it's in universe so I'm not sure that applies then
<sdeziel> ?
<LocutusOfBorg> sdeziel, universe has community providing security fixes
<LocutusOfBorg> and people looking at them
<LocutusOfBorg> same as main, just changes *who* provides support
<LocutusOfBorg> and security updates have higher priority, automatic installation, so for CVE fixes better use them
<sdeziel> LocutusOfBorg: OK, I thought that the security PPA was only for packages in main, my bad
<LocutusOfBorg> maybe you can ask on #ubuntu-hardened
<apw> that may well be true, sanyhow i can release that
<LocutusOfBorg> but for CVEs always better ask to security team before trying a microSRU
<sdeziel> apw: that would be nice indeed
<sdeziel> LocutusOfBorg: duly note
<sdeziel> there will be more of those now that the package is using the upstream LTS version so thanks for providing input on the process
<apw> sdeziel, on its way
<sdeziel> apw: thanks!
<stgraber> apw, Laney, slangasek: can one of you please review https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1715278?
<ubot5> Ubuntu bug 1715278 in lxc (Ubuntu) "[FFe] LXC 2.1" [Undecided,New]
<stgraber> it's been waiting for two weeks now :(
<apw> stgraber, if it is all backwardscompatible as claimed it seems ok to my eye
<jbicha> sdeziel: there are -security updates for universe packages, I've done a few
<stgraber> apw: yeah, lib is fully backward compatible and CLI is too. Config is where we made changes but it accepts the old config and issues warnings for things that will go away in 3.0
<jbicha> they don't publish USNs for universe -security updates but except for that, I believe it's the same
<sdeziel> jbicha: yeah, that's probably what got me confused
<beisner> hi bdmurray - i think this one is verif done for xenial-proposed.  can you do the honors into xenial-updates?  https://bugs.launchpad.net/neutron/+bug/1668410
<ubot5> Ubuntu bug 1668410 in neutron "[SRU] Infinite loop trying to delete deleted HA router" [Medium,In progress]
-queuebot:#ubuntu-release- New binary: libxbean-java [amd64] (artful-proposed/universe) [4.5-6] (no packageset)
<apw> stgraber, will we have 3.0 in BB, and how will xenial upgrades be handled
<stgraber> apw: we will indeed have 3.0 in the next LTS. Upstream ships a lxc-update-config tool which will convert the configs. I expect we'll update the tool a bit to allow for a "-a" flag and then show a debconf warning telling users to run that post-upgrade.
<stgraber> apw: we could auto-run it, but the problem is that we don't necessarily know where their containers are :)
<apw> it sounds like you need 2.1 in xenial ... too
<apw> stgraber, ^
<stgraber> apw: it will be in -backports for those interested but I don't believe we want to push a non-LTS LXC release down to xenial. Xenial users should stick to 2.0.x and when doing the LTS to LTS upgrade, we'll have them run lxc-update-config to upgrade to the new format.
<stgraber> it's also going to be limited to actual LXC users. Anyone who uses LXD won't have to deal with that as LXD will auto-generate the right format based on liblxc versions.
<apw> stgraber, ack thanks
<apw> stgraber, approved (details in bug)
<stgraber> apw: thanks
<bdmurray> apw: slangasek gives me the impression you and infinity are working on fixing secureboot kernels shipping two vmlinuz files is that correct?
-queuebot:#ubuntu-release- New: accepted libxbean-java [amd64] (artful-proposed) [4.5-6]
<smoser> infinity, you are sru team member...
<smoser> for today
<smoser> cloud-init has xenial and zesty uploads in queue that are in need of processing
<sil2100> smoser: I can look at this in a moment
-queuebot:#ubuntu-release- Unapproved: accepted python3.5 [source] (zesty-proposed) [3.5.3-1ubuntu0~17.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted python3.5 [source] (xenial-proposed) [3.5.2-2ubuntu0~16.04.3]
<smoser> sil2100, thanks!
<sil2100> smoser: I think for clarity, once this is released to -updates, we'll have to revert the 'Fix Released' fields of all the series in bug LP: #1691489
<ubot5> Launchpad bug 1691489 in cloud-init "fstab entries written by cloud-config may not be mounted" [Medium,Confirmed] https://launchpad.net/bugs/1691489
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (zesty-proposed) [0.7.9-233-ge586fe35-0ubuntu1~17.04.2]
<sil2100> smoser: btw. when preparing uploads, you don't have to target them to xenial-proposed, xenial is fine
<sil2100> It looks better in the changelogs then
<sil2100> (for the future)
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [0.7.9-233-ge586fe35-0ubuntu1~16.04.2]
<smoser> sil2100, i always felt like xenial-proposed "looked better"
<smoser> (personal preference)
<sil2100> To each his own, I guess! ;)
<doko> is sysvinit-utils still supposed to be essential in artful?
<xnox> doko, no... is it?
<xnox> doko, well, some init scripts source it, so maybe it still is essential.
<slangasek> xnox: mesa/xenial, appears to be waiting for verification on LP: #1709823?
<ubot5> Launchpad bug 1709823 in mesa (Ubuntu Xenial) "Installation of libgles1-mesa (12.0.6-0ubuntu0.16.04.1) failed" [Undecided,Confirmed] https://launchpad.net/bugs/1709823
<slangasek> xnox: sounds like it's a pretty easy thing for you to verify :)
<infinity> doko: I see no reason why it wouldn't be essential.
<infinity> doko: At the very least, the binaries would need to move to another essential package, if someone objected to it being essential just based on the package name.
<infinity> (Or it would need to demote in both Debian and Ubuntu with a full archive sweep for references to said binaries)
<doko> infinity: I just saw it pulled into build-essential, and Debian didn't do it
<infinity> doko: It's Essential in Debian too...
<infinity> Of course, build-essential shouldn't include Essential packages, since that would be redundant.
<doko> well, look at http://launchpadlibrarian.net/337444978/build-essential_12.1ubuntu2_12.4ubuntu1.diff.gz
<infinity> doko: Oh, well, that is literally a list of essential packages.  I'm just curious why it was wrong before.
<infinity> Oh, hrm.
<infinity> No, it wasn't essential before.
<infinity> But it *is* in sid too.
<infinity> Ahh.
<infinity> It was transitively Essential before.
<infinity> Someone just tagged it correctly.
<infinity> doko: ^
<infinity> doko: So, "yes, it's supposed to be Essential".
<infinity> Or, "it always way, but implicitly, and now it's explicit".
-queuebot:#ubuntu-release- New source: tomcat8.0 (artful-proposed/primary) [8.0.46-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted tomcat8.0 [source] (artful-proposed) [8.0.46-0ubuntu1]
<xnox> slangasek, verified
<slangasek> xnox: ok - despite the previous comment suggesting verification didn't work?
<doko> infinity, slangasek: what's the todo list for glibc at this point? autopkg test failures are still twisted, why3, click
<xnox> slangasek, i just did it freshly.
<infinity> doko: Processing click removals right now.  twisted, I'll ignore when everything else is green (not ignoring the new twisted to let it in, just ignoring the failure to let glibc in), so that leaves why3.
<xnox> slangasek, at the moment i do not care about installability of third-party software; what i do care about is that on uptodate xenial-updates we have a package which is not installable due to conflicts.
<xnox> slangasek, with proposed enabled it is installable.
<xnox> slangasek, regressing installable count is very bad, britney should have caught this for xenial, no?
<doko> xnox: did you look at wh3/s390x?
<slangasek> xnox: we don't use britney for promotion
<xnox> doko, no.
<slangasek> xnox: are you going to?  that's one of the last remaining blockers for glibc, we need to know what the path forward is
<doko> slangasek: has no rdepends. remove?
<xnox> slangasek, it passes with 4 out of 5 backends.
-queuebot:#ubuntu-release- New binary: tomcat8.0 [amd64] (artful-proposed/universe) [8.0.46-0ubuntu1] (no packageset)
<xnox> slangasek, so even if has regressed with z3 backend, one can use the other 4 backends.....
<xnox> slangasek, most likely a bug in z3 rather than why3
<slangasek> xnox: so you're arguing for a badtest?
<slangasek> or an upload to disable/xfail the test?
<xnox> slangasek, could do that.
-queuebot:#ubuntu-release- New: accepted tomcat8.0 [amd64] (artful-proposed) [8.0.46-0ubuntu1]
<xnox> slangasek, i'll try rebuilding z3 and check if that helps at all.
<slangasek> xnox: ok.  then I conclude that the current version should be badtested for right now
<slangasek> and if that badtest hint can be dropped due to the next version, hurray
<slangasek> doko, infinity: what's the current situation with libhybris?
<slangasek> did anyone talk to morphis?
<xnox> slangasek, there is still click which needs removing.... https://bugs.launchpad.net/ubuntu/+bugs?field.tag=u8rm and gcc-4.7
<doko> no, you said you wanted to do that? at least that was my impression when I asked last ...
<infinity> slangasek: Last week, xnox claimed the plan was to drop it (obviously, with code changes required to do so).
<infinity> xnox: I'm removing things right now.
<slangasek> xnox: infinity says he was following through on click
<xnox> infinity, and somebody did upload pulseaudio to drop things
<xnox> or not
<xnox> i am confused
<infinity> xnox: gcc-4.7 can't be removed yet.  But I actioned the rest of that bug.  On to the click stuff now.
<slangasek> doko: I try to be explicit if I am committing to follow up on something ;) all I said was that morphis might be interested in helping with libhybris
<xnox> infinity, why can gcc-4.7 not be removed yet? note the brain deadness of reverse-depends, and doko shipping the same binary package out of three source packages, with only latest being actually installable
<slangasek> infinity: what still blocks gcc-4.7?
<xnox> infinity, all of gcc-4.7 and gcc-4.7-arm* crosses can be removed.
<infinity> xnox: Because things still build-depend on it.
<infinity> xnox: Unless you're asserting (incorrectly) that newer gcc provides gcc-4.7/g++-4.7 :P
<xnox> infinity, all of these packages are to be removed, as per RM bugs.
<xnox> gcc-4.7-armel-cross <- has phatom reverse-depends
<slangasek> but you have not listed what those packages are, in the gcc-4.7 removal request
<xnox> slangasek, hm.
<slangasek> u-boot-linaro?
<infinity> xnox: Dude.  Don't make incorrect assertions.  There are not removal bugs for all the r-build-deps.
<xnox> https://bugs.launchpad.net/ubuntu/+source/u-boot-linaro/+bug/1717232
<ubot5> Ubuntu bug 1717232 in u-boot-linaro (Ubuntu) "RM: duplicate package" [High,Triaged]
<infinity> cloog-ppl-gcc4, gmp-gcc4, ppl-gcc4
<xnox> let me tag things
<slangasek> ok, so the bug exists; but cross-linking the reports helps us do this faster
<infinity> Now, I imagine those should all be removed.  But there aren't bugs.
<slangasek> and ensures we're looking at the same things
<doko> adding
<infinity> doko: Add tasks to LP: #1717229 for those, if they should go.
<ubot5> Launchpad bug 1717229 in gmp-gcc4 (Ubuntu) "RM: obsolete product" [Undecided,New] https://launchpad.net/bugs/1717229
<infinity> Hah, proof task was added, thanks bot. ;)
<xnox> infinity, yeah all of those are "this is gcc4.7 toolchain pieces, chicken, egg"
<xnox> you see, all bugs were totally filed ;-)
<infinity> xnox: Except, there's no obvious indicator of that without someone saying it.
<xnox> ps no need to look at bug history
 * infinity keeps removing.
<doko> $ reverse-depends src:libhybris
<doko> Reverse-Depends
<doko> ===============
<doko> * libmedia-hub-client5          (for libmedia1)
<doko> * liboxideqtcore0               (for libhybris)
<doko> * liboxideqtcore0               (for libandroid-properties1)
<doko> * media-hub                     (for libmedia1)
<doko> * telepathy-ofono-ril-mc-plugin  (for libhybris-utils)
<doko> * unity-system-compositor       (for libandroid-properties1)
<doko> * urfkill [amd64 armhf i386]    (for libandroid-properties1)
<doko> * urfkill [amd64 armhf i386]    (for libhybris)
<doko> that looks like more ...
<infinity> Different stack.
<infinity> But yes, those need addressing, or hybris needs fixing.
<doko> do we agree that we can remove libhybris?
<infinity> Not yet, no.
<infinity> We very much don't agree.
<infinity> I think most of us agree that we *should* remove it.  Once the rdeps are fixed.
<slangasek> how about giving the active libhybris upstream a heads up and finding out if they want to do the work to keep it, before us doing the work to remove it?
<doko> did upstream ever care about the arm soft-float/hard-float bits?
<infinity> slangasek: Because "upstream might support it" isn't a good enough reason to have the shim existing, if our stacks no longer actually need it?
<infinity> It's not like this is something that will regress functionality for a user if we remove it.
<xnox> look, all of the libhybris reverse depends have RM bugs filed (just now) https://bugs.launchpad.net/ubuntu/+bugs?field.tag=u8rm
<infinity> xnox: Erm.
<xnox> and building pulseaudio to drop a (forgotten) build-dep
<slangasek> urfkill should not be dropped because of libhybris.
<infinity> xnox: And are those bugs signed off on by the people who should do so?
<xnox> slangasek, why is it not seeded then?
<xnox> slangasek, please seed it appropriately.
<slangasek> xnox: no
<slangasek> urfkill should not be dropped /because of libhybris/
<xnox> slangasek, is urfkill generic, or the thing we wrote from scratch.
<slangasek> using "we want to nuke libhybris" as a rationale for removing urfkill is wrong
<slangasek> it's generic and we didn't write it
<xnox> slangasek, i'm pretty sure we did rewrite it from scratch and abuse the name =/
<xnox> unless i am very confused.
<slangasek> not to my knowledge
<xnox> why not force ync with debian then?
<slangasek> because we're ahead of Debian in versions
<doko> https://www.freedesktop.org/wiki/Software/urfkill/ -> Development happens in git. and this link pointing to cvs ...
<doko> there is no 0.6 release, so this is basically a fork
<slangasek> xnox: anyway, my core point is the same as infinity's here - just filing bugs requesting removal because we're in a hurry to get rid of libhybris isn't sufficient wrt procedure
<xnox> slangasek, without touch, there is little sense to build VCS snapshot of urfkill with hybris enabled.
<slangasek> so disable hybris support in urfkill!
<doko> sure, we can wait with promoting glibc to -release until the last day before the release as well
<slangasek> but don't just file blanket removal requests for revdeps without analysis
<doko> if people didn't care until now, when will they?
<infinity> We are the people currently caring.
<slangasek> doko: what have you done to inform people that there is an issue they need to care about?
<infinity> Disabling hybris in urfkill can't be that hard.
 * xnox test builds
<infinity> Bye-bye, gcc-4.7.
<slangasek> doko: libhybris only just broke with glibc 2.26.  it's not reasonable to expect that someone knows there's a build failure in a package they care about /without us telling them/.
 * xnox fixes urfkill FTBFS on something from his half of the decade
<infinity> slangasek: OTOH, it only "just broke" because I didn't update gcc last cycle.  Its design is to break every 6 months.
<infinity> slangasek: So I can see some argument here that the hybris-using crowd should have probably had a plan to stop using hybris well before now (or keep on top of maintenance in the distro).
<doko> slangasek: I think it is reasonable to drop these packages if we decided to drop the product. sure, urfkill might have some value to keep. but are there any other packages which need keeping without touch?
<infinity> Failing the latter, forcing the former is the only sane option.
<xnox> infinity, slangasek - i thought even we built hybris in the device tarball and did not use ubuntu archive one.....
<infinity> s/gcc/glibc/
<xnox> doko, pulseaudio, which is now uploaded.
<infinity> xnox: I mean, we clearly use the archive one for something, even if it's just to link against at build-time.
<xnox> (bogus build-dep that was not removed)
<xnox> infinity, true.
<infinity> Grr, why were the click removals three bugs? :P
<infinity> ... and none of them are for click.
<xnox> infinity, because one should remove leaf things first.
<cyphermox> I wrote that urfkill libhybris crap IIRC, I'm happy to get rid of it
<slangasek> I'm filing a bug against libhybris about the FTBFS
<infinity> xnox: You filed all the gcc-4.7 stuff in one bug, despite there being interdeps. ;)
<xnox> uploaded urfkill to not have libhybris stuff.
<cyphermox> oh ok then
<xnox> infinity, well cause click ones were filed with automated scripts; and gcc stuff was by hand due to circular build-deps on itself.
<infinity> xnox: Fair enough.  Well, leafy things going away as we speak.  Gimme a bug for the tree.
<xnox> infinity, and click is hard to check, because of the bogus python3-click
<infinity> It is indeed.
<xnox> also i see unity-scopes-api sutff
<infinity> libusermetrics is still there.
<xnox> and we are back to url-dispatcher stuff =/
<infinity> Woo.
<xnox> via unity-scopes-api -> url-dispatcher -> indicator-*
<infinity> All roads lead to indicators.
<infinity> Thanks, Ted.
<slangasek> https://bugs.launchpad.net/ubuntu/+source/libhybris/+bug/1718030
<ubot5> Ubuntu bug 1718030 in libhybris (Ubuntu) "libhybris fails to build with glibc 2.26" [Undecided,New]
<infinity> xnox: libusermetrics has no rdeps, unless it's on someone's protected list, it might be a candidate for thwacking.
<infinity> unity-scopes-api is definitely ickier.
<infinity> And probably just needs the click bits excised.
<infinity> Rather than the package dropped.
<xnox> infinity, i think unity-scopes-api was a unity8 thing, not unity7 thing thus can be removed.... once indicators are fixed.
<xnox> or that.
<xnox> https://bugs.launchpad.net/ubuntu/+source/libusermetrics/+bug/1718027
<ubot5> Ubuntu bug 1718027 in libusermetrics (Ubuntu) "RM: obsolete product" [Undecided,Triaged]
<infinity> xnox: Sure, it may be that its ultimate fate is deletion, but I suspect the faster path today is to see about disabling the click bits.
<xnox> 3/4 indicators to go....
<xnox> infinity, cause we do have mandate to ship indicators
<doko> xnox: upload why3. test was already ignored on ppc64el
<slangasek> I've badtested why3/s390x now, it won't block now
<infinity> Kay, so let's finish unwinding click.  Grabbing the unity-scopes-api source to see if there's an obvious solution.
<infinity> How does that have 18MB of source?  Sheesh.
<xnox> infinity, does it include an embedded copy of systemd? if not, it's not that bad....
<doko> slangasek: you may want to skip the autopkg tests for build-essential and python-defaults (and python3-defaults) if capacity is needed. all of these are dependency packages anyway
<doko> not 20mb testsuite
<infinity> Hrm, click stuff is ALL over in this.
<xnox> infinity, yeah, i would have expected as much
<xnox> infinity, maybe we can make url-dispatcher not depend on libunity-scopes1.0 and then nuke unity-scopes-api with click?
<infinity> xnox: That's where I was heading.
<infinity> That looks to require some hefty surgery too.
<slangasek> this all seems like useful surgery over the long term, but all of this is just for a single test failure of click on ppc64el, correct?
<slangasek> which we could badtest and not treat as a blocker for glibc here and now
<infinity> Well, yes.  We could badtest that test for now.
<infinity> And then skiptest glibc to get over the twisted hump.
<slangasek> and file a bug and make it some other team's problem to eliminate their own obsolete deps
<infinity> Does that team exist?
<infinity> Anyhow, if we address those two test issues, we're just back to hybris.
<slangasek> infinity: it's either the mir team or the desktop team
<slangasek> not sure which
<slangasek> but yes, if tracing the revdeps leads us to something seeded / not removable, then there is a team that should be on the hook for it
<infinity> slangasek: Well, url-dispatcher is "seeded", but only indirectly.
<infinity> Not removable, it certainly is currently.
<infinity> Anyhow, fine with badtesting click on an arch where no one would ever had used it.
<infinity> So, it's a regression, but not one that anyone will see.
 * infinity does that now.
<infinity> Done.
<xnox> slangasek, infinity - what is the story with ofono? it is a generic thing right?
<infinity> Which leaves just twisted, which I would badtest if it was the old version, but someone re-ran against the new version, whose test failure is legit.
<xnox> hm ofono in debian is on 1.18 and we are on 1.17
-queuebot:#ubuntu-release- Unapproved: unattended-upgrades (xenial-proposed/main) [0.90ubuntu0.7 => 0.90ubuntu0.8] (desktop-core, ubuntu-server)
<infinity> doko: http://paste.ubuntu.com/25567940/ <-- Wat.
<infinity> Oh, hrm.  Is my mirror out of date?
<xnox> infinity, i did same paste to doko in msg too =)
 * xnox calls it a day
<infinity> Oh no, it's not.
<infinity> Ahh, I see the bug.
<infinity> I think.
<nacc> infinity: yeah a double definition?
<nacc> infinity: rather than a remove/add
<infinity> nacc: Or, the inverse.
<infinity> Anyhow, removing that one, since it build-deps on itself.
<nacc> infinity: err, right (i see a add in the debdiff, rather than a remove/add)
<infinity> nacc: http://paste.ubuntu.com/25567979/ <-- That match your read on what's broken?
 * infinity test.
<infinity> s
<infinity> Yep, that fixes it.
<nacc> infinity: yeah
<doko> ahh, thanks for fixing :-/
<infinity> doko: Thankfully, nothing build-depends on python, so no harm done.
<infinity> Oh, wait. ;)
<infinity> Now just waiting for the publisher to get around to deleting the old version.
<doko> indeed, only python3 ;)
#ubuntu-release 2017-09-19
<jbicha> I think I'm going to need help with LP: #1718085 tomorrow (or at least this week)
<ubot5> Launchpad bug 1718085 in ubuntu-gnome-meta (Ubuntu) "FFe: Transition to ubuntu-desktop and provide vanilla-gnome-desktop" [Undecided,New] https://launchpad.net/bugs/1718085
<jbicha> apologies for not doing it sooner, my excuse is that agreeing on a name (even an apparently simple one) is hard
<infinity> jbicha: Can I bikeshed that name? :P
<jbicha> sure but it might not change the name ;)
<Ukikie> Speaking of, did anyone look into how notification-daemon slipped into every ISO?
<slangasek> ... no?  which ISO are you expecting it to not be in?
<Ukikie> slangasek: Xubuntu, Ubuntustudio, Lubuntu and likely Kubuntu, Ubuntu MATE.  The former ship xfce4-notifyd which provides notification-daemon (expected, same as the last many releases) and I presume KDE and MATE provide something as well.
<slangasek> cyphermox: nplan autopkgtests regressed again?
<LocutusOfBorg> doko, I want to see if the llvm fixes are all in debian, I already have a merge ready for the python change (llvm 3.9) http://launchpadlibrarian.net/337517278/llvm-toolchain-3.9_1%3A3.9.1-13ubuntu7_1%3A3.9.1-16.diff.gz I couldn't find references in changelog for the FUZZER change, maybe not needed anymore
 * LocutusOfBorg good morning btw
<LocutusOfBorg> also ldc should be fixed now
<LocutusOfBorg> will appear in some minutes in new queue
-queuebot:#ubuntu-release- New binary: ldc [amd64] (artful-proposed/universe) [1:1.4.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ldc [ppc64el] (artful-proposed/universe) [1:1.4.0-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: ldc [i386] (artful-proposed/universe) [1:1.4.0-1ubuntu1] (no packageset)
<LocutusOfBorg> doko, stuff seems to build better with the new ldc https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/debhelper/+build/13392398
<LocutusOfBorg> what is your opinion? it is FTBFS on armhf, but at least if we remove binaries there we can finish the transition
<xnox> bdmurray, i believe i have fixed up templates on all the sru bugs =/
<doko> LocutusOfBorg: you could do a test build for powerpc on trusty and xenial to see if it is still needed
<LocutusOfBorg> doko, context please?
<LocutusOfBorg> llvm?
<doko> well, that's what you asked?
<LocutusOfBorg> yep, I was wondering about ldc, the second question
<LocutusOfBorg> actually that FUZZER variable was tested but never defined
<doko> better keep armhf and fix it for th next release
<LocutusOfBorg> so, in each case, the sync -f has not changed the status quo
<LocutusOfBorg> for armhf, I pushed an llvm 5.0 that might fix it
<LocutusOfBorg> -opt_flags = -g -O2
<LocutusOfBorg> +opt_flags = -g1 -O2
<LocutusOfBorg> +ifneq (,$(filter $(DEB_HOST_ARCH),arm64 ppc64el))
<LocutusOfBorg> +  opt_flags = -g1 -O2
<LocutusOfBorg> +endif
<LocutusOfBorg> maybe you didn't want to change opt_flags regardless of the architecture?
<LocutusOfBorg> otherwise the if test would have been useless
<doko> why? did you find out what caused the explosion of the debug symbol size?
<apw> that is an odd if, it has the same value both ways
<apw> LocutusOfBorg, ^
<LocutusOfBorg> ^^ that one, the first line
<apw> as in you reverted the first line
<apw> of that existing diff ?
<LocutusOfBorg> AFAIK the explosion of debug symbol size has been a thing in arm64 and ppc64el
<LocutusOfBorg> so, using -g1 only there should be the exact thing to do
<LocutusOfBorg> the above is the diff between the current ubuntu and the current debian
<LocutusOfBorg> (me, discard the latest sentence)
<LocutusOfBorg> the current debian is "good"
 * LocutusOfBorg wrt the if statement
<LocutusOfBorg> http://launchpadlibrarian.net/337530714/llvm-toolchain-5.0_1%3A5.0-1ubuntu2_1%3A5.0-2~build1.diff.gz
<doko> no, you are wrong, it' see for s390x as well, even for debian. so please don't speculate
<LocutusOfBorg> look at the above diff for 5.0
<LocutusOfBorg> it is enabled in +ifneq (,$(filter $(DEB_HOST_ARCH),amd64 arm64 ppc64el s390x))
<doko> well, you just said: "the explosion of debug symbol size has been a thing in arm64 and ppc64el"
<doko> which is wrong
<LocutusOfBorg> you are right, sorry! I was meaning "for a subset of the whole architecture list", and now debian has that list embedded into the rules file
<sergiusens> slangasek any update on the armhf network errors?
<cyphermox> slangasek: it's possible, but I did run it twice on amd64 before uploading, and both passed no problem. admittedly not against proposed, because proposed was otherwise broken atm (python xml). I'll have a look, given that it passes without proposed, it ought to be a fairly simple debugging session
<jbicha> sil2100: does this look ok? https://code.launchpad.net/~jbicha/ubuntu-cdimage/drop-ubuntu-gnome-artful/+merge/330983
<acheronuk> Ukikie: seems notification-daemon is on the Kubuntu iso also. trying to work out how to evict it!
<cjwatson> acheronuk: I think it will work if you explicitly seed plasma-workspace in kubuntu.artful/desktop rather than relying on it being pulled in via dependencies.
<cjwatson> acheronuk: At the moment, germinate hasn't yet worked out that plasma-workspace is going to be pulled into desktop at the point when it's resolving dependencies (well, Recommends) of libnotify4 while expanding desktop-common, so it picks the real package rather than realising that the Kubuntu-ish replacement is wanted.
<acheronuk> cjwatson: yeah, I'm just weaving my way through those depends and recommends
<acheronuk> lets try that then. see what germinate things on the next iso build
<acheronuk> *thinks
<sil2100> jbicha: commented on it
<cjwatson> acheronuk: The important bit is explicitly seeding things that you want to be picked instead of the default.
<acheronuk> cjwatson: indeed. thanks for pointing that out. saved me some time puzzling.....
<cjwatson> I'm not entirely sure what the problem is in the Xubuntu case.  xfce4-notifyd in core should suffice.
<rbasak> slangasek: could you accept the python-certbot-nginx binNEW for Xenial please?
<cyphermox> slangasek: I re-ran the nplan autopkgtests, currently waiting in the queue. the failure looked like something about the infra though -- as if the tests had been run on the host somehow, and the modules/directories were not cleaned up afterwards -- mac80211_hwsim should never be on any system to begin with, unless it ran the tests and exploded midway :)
<ogra_> cyphermox, did you see my comment regarding the console-setup udev rule ?
<cyphermox> ogra_: I did
<ogra_> good
<ogra_> someone should at least test if it doesnt break initrd input ... (not sure if it does or does not, but we used to install the rule there)
<cyphermox> well, if it did, it's still being in the way now. I'm sure there is a better way to handle this
<cyphermox> that said, my current thought is why the hell did things need to start using tty1 for graphical, and why can't wayland handle the input correctly anyway?
<Laney> it does handle it correctly?
<Laney> Xorg has the same problem - you can't change the console mode underneath it
<slangasek> rbasak: done
<slangasek> cyphermox: ok cool
<cyphermox> Laney: things were working fine under X
<Laney> no, they worked fine under lightdm/Unity because it was on tty7
<Laney> start an X session from GDM and reproduce this bug
-queuebot:#ubuntu-release- New: accepted python-certbot-nginx [amd64] (xenial-proposed) [0.14.2-0ubuntu0.16.04.1]
<Laney> it happens there too
<cyphermox> partly because things were running on tty7, but I would wager it was also jigling the console modes differently
<Laney> No
<Laney> It's K_OFF, and then when you get K_UNICODE it breaks
<cyphermox> I can't begin to explain why you'd see your password in clear text on the screen when it crashes then.
<Laney> That does explain why you see that
<cyphermox> and that^ makes me very scared on it
<rbasak> slangasek: thanks!
<Laney> ...don't switch the keyboard mode...
<cyphermox> Laney: not the right place to discuss this in any case.
<Laney> k
<cyphermox> slangasek: any idea what that issue with nplan might have been?
<slangasek> cyphermox: nope!
<cyphermox> yipee.\
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (xenial-proposed) [229-4ubuntu20]
<Laney> cyphermox: did you try to reproduce this locally?
<Laney>   File "/tmp/autopkgtest.OH8cTq/build.rJx/nplan-0.28/tests/integration.py", line 104, in create_devices
<Laney>     raise SystemError('mac80211_hwsim module already loaded')
<Laney> SystemError: mac80211_hwsim module already loaded
<cyphermox> of course I did, it works locally when not using -proposed (because there was another issue with python xml yesterday)
<cyphermox> this is specifically the kind of failure you see if the test previously ran but was killed before the end
<cyphermox> (ie. cleanup didn't run)
<Laney> that paste was from my machine
<cyphermox> why would this happen though?
<cyphermox> did you use lxc as the runner or qemu?
<Laney> qemu
<cyphermox> err
<cyphermox> with proposed?
<Laney> nplan from proposed
<cyphermox> --apt-pocket=proposed or not?
<Laney> no
<Laney> proposed=src:nplan
<cyphermox> because I had nplan build locally, in that qemu.
<cyphermox> ie. autopkgtest -U -s . -- qemu ~u/adt-artful-amd64-cloud.img
<Laney> autopkgtest.u.c doesn't do it like that
<cyphermox> I know that
<Laney> ok
<cyphermox> but it's the closest I can emulate  "netplan from proposed" without uploading it to proposed.
<cyphermox> furthermore, that has always worked fine until now; so I had no reason to do otherwise.
<jbicha> sil2100: I resubmitted the cdimage change (not sure if it sent you an email or not)
<Laney> if you want the actual package from proposed, then --apt-pocket=proposed=src:nplan is the way to ask for that
<Laney> you can see the autopkgtest invocation used near the top of the logs; that helps when reproducing failures
<cyphermox> Laney: that's fine once something is in proposed
<Laney> this broken nplan is?
<cyphermox> my point was, I tested this locally before uploading, and the autopkgtests were passing with no issues, so I have no idea why it would fail in the infra.
<Laney> ok, well I came in where there was a claim that the infrastructure was broken and a retry was issued - at that point it was possible to reproduce the same failure without needing local packages
<cyphermox> I can't reproduce the failure here.
<cyphermox> http://paste.ubuntu.com/25573075/
<cyphermox> this is admittedly *not* the same command as you provided, but it *is* the same package being used (it's logged as nplan 0.28)
<cyphermox> I'm not claiming that the infra is broken, just trying to figure out where something is different so I know why it works here, but doesn't work in autopkgtests.ubuntu.com
<cyphermox> or why it fails for you
<cyphermox> ugh, that paste is incomplete
<cyphermox> this here is complete: http://paste.ubuntu.com/25573084/
<slangasek> sergiusens: I've done some quick smoketests and hammering the DNS server from inside with lookups in a loop was not enough to trigger the problem. :/ I'll go ahead and badtest snapcraft/armhf now to let it through, and continue tugging at that problem
<slangasek> sergiusens: oh, or somebody already did let it through which is also good
<slangasek> (but didn't badtest it, which is bad)
<slangasek> (badtest added)
<Laney> cyphermox: sorry, team meeting --- here's three commands which failed in the same way for me https://paste.ubuntu.com/25573149/, not sure if that's helpful
<Laney> it's also a fresh image built 30 minutes ago or so
<apw> slangasek, how would they have let it through without a badtest/skiptest
<cyphermox> Laney: ta. I have an idea, perhaps I know what this is
<slangasek> apw: because proposed-migration remains completely advisory for SRUs; we need to change sru-release to write hints instead of doing copy-package in order to change this
<apw> slangasek, derp in a stable release, of course
<jbicha> slangasek: please update your badtest for (artful) flapak/ppc64el and add s390x (since it's NBS on s390x), also please update the badtest for ostree (L_aney's hint file)
<doko> glibc is now only stopped by the libhardware/libhybris stack
<slangasek> jbicha: fixing the autopkgtest failure is something any Ubuntu dev has access to do; updating the hint is something only the release team can do; why not fixing the flatpak/ppc64el test failure instead?
<slangasek> and why did flatpak 0.8.7-5 run tests on s390x if there are no binaries :P
<sergiusens> slangasek thanks, I wasn't even aware it went through! We can certainly look into it live next week and get some proper data to pin point the problem
<slangasek> sergiusens: yeah... it's confusing, as I said I have seen more lookup failures on armhf than elsewhere, but they've seemed pretty infrequent - not enough for me to expect snapcraft to fail continuously
<jbicha> flatpak only passed 4 times in its history on ppc64el on Ubuntu so it seems more likely that some change in the infrastructure helped it pass
<Ukikie> acheronuk: Yeah it looks like a regression somewhere as the package is everywhere, even when an acceptable alternative is seeded.
<slangasek> infinity, xnox: were either of you still working the libhybris dep chain?
<ahasenack> hi, for some reason ubuntu-advantage-tools v8 is in artful/universe instead of main (https://launchpad.net/ubuntu/+source/ubuntu-advantage-tools), could someone "push" it over to main, like it is in all other ubuntu releases before AA?
<ahasenack> I don't know what happened there, also why it is showing "published 3h ago" when it built back in Aug 22nd
<slangasek> ahasenack: it's in universe instead of main because we haven't yet seeded it in ubuntu-minimal
<slangasek> someone probably demoted it as a component-mismatch
<slangasek> (which was not wrong; it's on me for not having seeded it before now)
<doko> slangasek: please could you skip the autopkg tests for python3-defaults? the queue gets large. I see the the ones for build-essential are almost done, and the ones for python-defaults aretriggerring almost the same packages as python3-defaults
<doko> so autopkg tests for universe packages can catch up
<xnox> slangasek, why would you want to work on the libhybris dep chain?
<slangasek> xnox: it's still blocking glibc.  Is there an agreed path forward?  Is someone working on resolving this?
<xnox> slangasek, i do not see it blocking glibc
<xnox> slangasek, just need to wait for britney to migrate it, as far as i can tell.
<xnox> slangasek, publisher is slow
<slangasek> xnox: did you look at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt ?
<xnox> yes
<xnox> slangasek, did you look at https://launchpad.net/ubuntu/+source/libhybris/0.1.0+git20151016+6d424c9-0ubuntu26 ?
<slangasek> heh
 * xnox likes to call & raise
<slangasek> xnox: you didn't close LP: #1718030 in the changelog :)
<ubot5> Launchpad bug 1718030 in libhybris (Ubuntu) "libhybris fails to build with glibc 2.26" [Undecided,New] https://launchpad.net/bugs/1718030
<xnox> slangasek, it's not like it would have made a different until after the package migrates....
<doko> slangasek, ahasenack: sorry, yes I demoted it
<slangasek> xnox: are you sure I'm not scraping changes emails for bug references?
<slangasek> ;)
<slangasek> xnox: thanks for the fix
<xnox> slangasek, if you were scrapping changes emails, you would have noticed that i uploaded libhybris ;-)
<slangasek> xnox: not if I was filtering for bugs I care about!
<slangasek> it's plausible
<xnox> deniability
<xnox> anyway. publisher is so slow
<slangasek> publisher, or britney?
<slangasek> publisher says it's published.  britney doesn't show it moving
<xnox> it's not yet even in rmadison output
<slangasek> rmadison is post-publisher
-queuebot:#ubuntu-release- Unapproved: cockpit (zesty-backports/universe) [148-1~ubuntu17.04.1 => 150-2git1~ubuntu17.04.1] (no packageset)
<xnox> ... and the builds finished building 1h ago, hence i blame publisher for the delays
<slangasek> doko: I only see long 'huge' queues of autopkgtests, not regular queues.  It's fine for these autopkgtests to run as low-priority jobs, unless there are things queued behind these in the 'huge' queue that you care about?
<xnox> britney doesn't notice things until they are in rmadison. Maybe imprecise timing, but that is my perception from how things look to me.
-queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [148-1~ubuntu16.04.1 => 150-2git1~ubuntu16.04.1] (no packageset)
<slangasek> doko: also, dumping the tests is different than letting python3-defaults through before the tests are done; is the latter what you care about?
<xnox> doko, do you need that package to start archive rebuild or something?
<doko> slangasek: sure, fine. please lower the priority and enjoy yourself looking at the logs ;p
<slangasek> xnox: britney talks to ftpmaster.internal directly.  rmadison data is generated from ftpmaster.internal.
<doko> xnox: I've given up on that. will do the tst rebuild with -proposed enabled :/
<slangasek> doko: they are already in the low-priority queue
<xnox> doko, or is that the fix for parsing that debian file?
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [150-2git1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (zesty-backports) [150-2git1~ubuntu17.04.1]
<doko> xnox: no, it's just a version bump
<xnox> doko, yeah anything that triggers more than a few tests automatically ends up in a different queue in the autopkgtests.
<xnox> it's round robin across ubuntu, ppas, upstream, and "things that triggered a lot of tests". To not starve "small" upgrades, by the "large ones".
<xnox> but i think it does not do round-robin across releases
<slangasek> I think it is
<xnox> thus one has to wait for xenial to be drained before artful is tested.
<xnox> hm, ok.
<slangasek> doko: I'm not opposed to doing something here to expedite.  what I'm asking is that we be clear about what we're doing, and the rationale.  Clearing the autopkgtest queues doesn't make python3-defaults migrate any faster; adding a skiptest hint for python3-defaults would make it migrate faster
<doko> slangasek: well, it's not that these autopkg tests would catch anything which is not already in the release pocket
<slangasek> doko: ok, but what is it that you are trying to accomplish? "empty autopkgtest queues" is not a goal that gets me out of bed
<slangasek> is something that you care about blocked / slow?
<xnox> slangasek, hm so new publisher run does not start until after a britney run finishes? i would have thought that is decoupled.
<xnox> slangasek, such that things in -proposed can publish multiple times whilst britney is running
<doko> lol, 1pm in bed?
<xnox> shhh
<slangasek> xnox: they are decoupled.  I was only saying that if you want to know when britney will see it, looking in rmadison has false-negatives
<slangasek> doko: a saying
<doko> slangasek: britney runs are currently slow, for whatever reason
<slangasek> yes.  maybe they're slow because they're trying to check a lot of autopkgtest results
<xnox> slangasek, so a run 20 minutes ago, did not notice libhybris that finished 1h ago and published 57 minutes ago?
<xnox> although it may be a lie that it published 57 minutes ago, could have been just the source publication
<slangasek> xnox: the 'generated' timestamp is near the end of the britney run, not the start, fwiw
<xnox> looking at the current running log at http://people.canonical.com/~ubuntu-archive/proposed-migration/log/artful/2017-09-19/20:20:05.log
<xnox> britney run that "started" 20 minutes ago
<slangasek> xnox: right, new update_excuses up and still no libhybris; I'll dig if time allows, but I have a call in 10 minutes
<xnox> slangasek, and now that that britney is done, new libhybris appeared in rmadison, and i suspect next run of britney will have the new libhybris.
<xnox> it does feel like britney locks and block ftpmaster.internal
<slangasek> it doesn't
<xnox> migrating \o/
<doko> wonders still happen
<slangasek> uh
<slangasek> arpack++ now shows up as a regression under glibc, where did that come from?
<slangasek> skiptested, so not fatal, but
<slangasek> oh, because it passed for the first time with new openblas, so it's a retroactive regression ;P
<doko> now finally clang demoted to universe. we really should take more care about auto promotions to main
<infinity> xnox: \o/
<tsimonq2> Release team: I'd like to do a change to gdebi that's all in one upload. One change (that I've already made locally) fixes a bug that Ubuntu MATE was having, the other thing that I would like to do is port away from the obsolete, insecure framework kdesudo and instead use kdesu for gdebi-kde. kdesudo has already been removed in Debian because it's KDE 3 and hasn't been touched upstream since
<tsimonq2> 2011. Can I JFDI or do you want me to file a bug for the FFe for the kdesudo port?
<tsimonq2> I just don't know if it deserves an FFe.
<tsimonq2> I'd consider it a bugfix in the sense that kdesu is generally more secure and has less bugs, but a feature in the sense that it's porting to a new framework.
<tsimonq2> Thoughts?
<nacc> if someone from the release team could review the FFE at LP: #1658469, I'd appreciate it.
<ubot5> Launchpad bug 1658469 in apache2 (Ubuntu) "[FFe] mod_http2 is not available in Apache" [Low,Triaged] https://launchpad.net/bugs/1658469
<tsimonq2> (actually, might work better as separate gdebi upload, let's get that out of the way)
<tsimonq2> (bugfix)
-queuebot:#ubuntu-release- New binary: cockpit [amd64] (xenial-backports/universe) [150-2git1~ubuntu16.04.1] (no packageset)
#ubuntu-release 2017-09-20
<stgraber> filed an FFe for LXD 2.18, nothing too crazy in that one. We'd like it to be the LXD release for 17.10. https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1718342
<ubot5> Ubuntu bug 1718342 in lxd (Ubuntu) "[FFe] LXD 2.18" [Undecided,New]
<LocutusOfBorg> doko, did you demote llvm-toolchain-4.0 to universe? if so, please demote the proposed one too :)
-queuebot:#ubuntu-release- New: accepted cockpit [amd64] (xenial-backports) [150-2git1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New binary: fast5 [amd64] (artful-proposed/universe) [0.6.2-6] (no packageset)
-queuebot:#ubuntu-release- New: accepted fast5 [amd64] (artful-proposed) [0.6.2-6]
<smb> sil2100, if you happen to have one (or two) more spare cycles, could you have a look at ubuntu-fan in the zesty unapproved queue?
<sil2100> smb: hey, I can try have a look at it before going out
<smb> sil2100, its not a urgent rush but its lingering there since 2 weeks
<sil2100> smb: if I won't make it today (since I'm taking a half day off in the afternoon) I'll review it tomorrow for sure if no one beats me to it
<smb> sil2100, ack that is early enough (and I am afraid I don't think there will be many trying to beat you there)
-queuebot:#ubuntu-release- Packageset: Added linux-aws to kernel in trusty
-queuebot:#ubuntu-release- Packageset: Added linux-meta-aws to kernel in trusty
<sil2100> smb: commented on bug LP: #1714969, would be grateful for the usual SRU-annoying bits ;)
<ubot5> Launchpad bug 1714969 in ubuntu-fan (Ubuntu Zesty) "Backport remaining delta" [Low,In progress] https://launchpad.net/bugs/1714969
<smb> sil2100, ok, I try to add something
<sil2100> Thanks!
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-97.120] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-36.40] (core, kernel)
-queuebot:#ubuntu-release- New binary: opencv [s390x] (artful-proposed/universe) [3.2.0+dfsg-1~exp2] (kubuntu)
-queuebot:#ubuntu-release- New binary: opencv [ppc64el] (artful-proposed/universe) [3.2.0+dfsg-1~exp2] (kubuntu)
-queuebot:#ubuntu-release- New binary: opencv [i386] (artful-proposed/universe) [3.2.0+dfsg-1~exp2] (kubuntu)
-queuebot:#ubuntu-release- New binary: opencv [amd64] (artful-proposed/universe) [3.2.0+dfsg-1~exp2] (kubuntu)
-queuebot:#ubuntu-release- New sync: wildfly-common (artful-proposed/primary) [1.2.0-1]
-queuebot:#ubuntu-release- New: accepted wildfly-common [sync] (artful-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New binary: wildfly-common [amd64] (artful-proposed/none) [1.2.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted wildfly-common [amd64] (artful-proposed) [1.2.0-1]
-queuebot:#ubuntu-release- New binary: opencv [armhf] (artful-proposed/universe) [3.2.0+dfsg-1~exp2] (kubuntu)
-queuebot:#ubuntu-release- New binary: opencv [arm64] (artful-proposed/universe) [3.2.0+dfsg-1~exp2] (kubuntu)
-queuebot:#ubuntu-release- New: rejected opencv [amd64] (artful-proposed) [3.2.0+dfsg-1~exp2]
-queuebot:#ubuntu-release- New: rejected opencv [armhf] (artful-proposed) [3.2.0+dfsg-1~exp2]
-queuebot:#ubuntu-release- New: rejected opencv [ppc64el] (artful-proposed) [3.2.0+dfsg-1~exp2]
-queuebot:#ubuntu-release- New: rejected opencv [arm64] (artful-proposed) [3.2.0+dfsg-1~exp2]
-queuebot:#ubuntu-release- New: rejected opencv [s390x] (artful-proposed) [3.2.0+dfsg-1~exp2]
-queuebot:#ubuntu-release- New: rejected opencv [i386] (artful-proposed) [3.2.0+dfsg-1~exp2]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-36.40]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-97.120]
-queuebot:#ubuntu-release- New sync: wildfly-client-config (artful-proposed/primary) [1.0.0-1]
<LocutusOfBorg> doko, this should unblock your jboss-xnio sync ^^
<doko> ahh, one more wild fly
<LocutusOfBorg> yep :)
-queuebot:#ubuntu-release- New: accepted wildfly-client-config [sync] (artful-proposed) [1.0.0-1]
<LocutusOfBorg> in the meanwhile I'm fixing sikulix
-queuebot:#ubuntu-release- New binary: wildfly-client-config [amd64] (artful-proposed/none) [1.0.0-1] (no packageset)
<LocutusOfBorg> doko, ^^
-queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (xenial-proposed) [0.90ubuntu0.8]
-queuebot:#ubuntu-release- New: accepted wildfly-client-config [amd64] (artful-proposed) [1.0.0-1]
<acheronuk> hi release team. we have had some delays getting sufficient votes for our 2017 wallpaper competition votes. so now we are there do we need a FFE to add those as a say "kubuntu-wallpaper-artful" sub package to our settings package?
<jbicha> acheronuk: I'm not release team, but I
<jbicha> 'm thinking UIFe not FFE https://wiki.ubuntu.com/FreezeExceptionProcess#UserInterfaceFreeze_Exceptions
<infinity> acheronuk: Wallpaper is very much userinterface, not feature, and if it only affects your flavour (which it does), the question isn't up to the Ubuntu release team, but just the Kubuntu folks.
<infinity> acheronuk: ie: if you can get it in and get all your docs and slideshows updated to match, it's your call.
<LocutusOfBorg> ok no sikulinux idea
<doko> what is an "unknown" version in autopkg tests?
<LocutusOfBorg> doko, sadness in autopkgtestsuuite
<LocutusOfBorg> sadness in infra, e.g. systemd not running correctly, container issue or something similar
<LocutusOfBorg> Laney, ^^
<Laney> look at the log
<Laney> if it looks transient, retry
<LocutusOfBorg> but "unknown" means autopkg didn't get some result, right?
<Laney> it failed very early in the setup process
-queuebot:#ubuntu-release- Unapproved: linux (trusty-proposed/main) [3.13.0-132.181 => 3.13.0-133.182+nvmemsi] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: rejected linux [source] (trusty-proposed) [3.13.0-133.182+nvmemsi]
<slangasek> well. figured out a fix for the gnucash build failure, and am now irritated at bad test suites.
-queuebot:#ubuntu-release- New binary: gnucash [s390x] (artful-proposed/universe) [1:2.6.17-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnucash [ppc64el] (artful-proposed/universe) [1:2.6.17-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnucash [amd64] (artful-proposed/universe) [1:2.6.17-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnucash [i386] (artful-proposed/universe) [1:2.6.17-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnucash [arm64] (artful-proposed/universe) [1:2.6.17-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: gnucash [armhf] (artful-proposed/universe) [1:2.6.17-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted gnucash [amd64] (artful-proposed) [1:2.6.17-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnucash [armhf] (artful-proposed) [1:2.6.17-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnucash [ppc64el] (artful-proposed) [1:2.6.17-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnucash [arm64] (artful-proposed) [1:2.6.17-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnucash [s390x] (artful-proposed) [1:2.6.17-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted gnucash [i386] (artful-proposed) [1:2.6.17-1ubuntu1]
<slangasek> LocutusOfBorg: I don't see any FFe bug references in this upload of ldc, why is this coming into artful-proposed now?
<slangasek> Laney: did we get any more quota for autopkgtest as part of the cloud redeploy?
<slangasek> tdaitx: do you know what this jre detection failure is during autopkgtests on armhf? http://autopkgtest.ubuntu.com/packages/k/kazoo/artful/armhf
<infinity> slangasek: If I had to guess, I'd assume it's to move up to llvm 5.0 instead of 3.9(!), which seems like a solid goal.
<infinity> But indeed, since libphobos2-ldc72 seems to be seeded on one flavour (budgie), it does need at least a cursory nod.
<slangasek> autopkgtest [18:19:01]: ERROR: "mkdir -p /tmp/autopkgtest.Wsh83W" failed with stderr "error: not found
<slangasek> well ok then
-queuebot:#ubuntu-release- Unapproved: update-manager (zesty-proposed/main) [1:17.04.7 => 1:17.04.8] (core)
-queuebot:#ubuntu-release- Unapproved: update-manager (xenial-proposed/main) [1:16.04.9 => 1:16.04.10] (core)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (trusty-proposed/main) [0.103ubuntu4.7 => 0.103ubuntu4.8] (core)
<slangasek> infinity, apw: linux currently blocked in devel-proposed by a missing d-i bump?
<infinity> slangasek: Yeahp, will do now.
<infinity> Probably should have tested that in a PPA first, since it's a new upstream, but hey, let's be crazy.
<slangasek> something something autopkgtests
<infinity> slangasek: Oh, no, it's not functionality I'm worried about, just straight up FTBFS.
<infinity> slangasek: It's actually remarkably hard to get the kernel packaging in a state where d-i builds but doesn't work.
<infinity> (Would involve dropping some built-in modules, which I'd hope kernel tests would have caught)
<slangasek> ah
<infinity> Lucks like I got looky.
<infinity> Or apw had tested previously and fixed the issues before I found them.
#ubuntu-release 2017-09-21
<slangasek> jbicha: did you see my follow-up question to you in https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1715030/comments/6 ?
<ubot5> Ubuntu bug 1715030 in mozplugger (Ubuntu) "Please remove firefox from artful on ppc64el" [Undecided,Incomplete]
<jbicha> slangasek: I think Chris already answered that for mozplugger. I believe mozplugger is a plugin and Flash is the only plugin allowed in Firefox now
<jbicha> I think it's broken in Debian now too
<jbicha> maybe it does something in Epiphanyâ¦
<tsimonq2> Can someone please remove kdeplasma-addons from zesty-proposed? I accidentally messed up the upload.
<tsimonq2> I think acheronuk said something on the weekend, idk.
<tsimonq2> More details are on bug 1715219, I'll upload a fixed version very shortly after it's removed.
<ubot5> bug 1715219 in kdeplasma-addons (Ubuntu Zesty) "Missing dependency" [High,In progress] https://launchpad.net/bugs/1715219
<slangasek> jbicha: ah, I suppose it does count as a plugin, doesn't it - thanks for pointing out the obvious, I'll remove + blacklist now
<slangasek> jbicha: any chance you want to file a bug on it in Debian, then?
<slangasek> tsimonq2: why does it need removed?  you can just mark the SRU bug verification-failed, and upload the fixed package at earliest opportunity
<tsimonq2> slangasek: oh
<tsimonq2> Fair
<tsimonq2> I'll do that then
<tsimonq2> Thanks slangasek
-queuebot:#ubuntu-release- Unapproved: kdeplasma-addons (zesty-proposed/universe) [4:5.9.5-0ubuntu0.2 => 4:5.9.5-0ubuntu0.3] (kubuntu)
<slangasek> acheronuk: kcrash 5.38.0-0ubuntu1, still fails its autopkgtests?
-queuebot:#ubuntu-release- New sync: node-babylon (artful-proposed/primary) [6.18.0-1]
-queuebot:#ubuntu-release- New: accepted node-babylon [sync] (artful-proposed) [6.18.0-1]
-queuebot:#ubuntu-release- New sync: node-pretty-ms (artful-proposed/primary) [3.0.0-1]
-queuebot:#ubuntu-release- New sync: node-rollup-plugin-replace (artful-proposed/primary) [2.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-pretty-ms [sync] (artful-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-rollup-plugin-replace [sync] (artful-proposed) [2.0.0-1]
-queuebot:#ubuntu-release- New binary: node-rollup-plugin-replace [amd64] (artful-proposed/none) [2.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New sync: node-rollup (artful-proposed/primary) [0.47.4-3]
-queuebot:#ubuntu-release- New: accepted node-rollup [sync] (artful-proposed) [0.47.4-3]
-queuebot:#ubuntu-release- New binary: node-pretty-ms [amd64] (artful-proposed/none) [3.0.0-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted node-pretty-ms [amd64] (artful-proposed) [3.0.0-1]
-queuebot:#ubuntu-release- New: accepted node-rollup-plugin-replace [amd64] (artful-proposed) [2.0.0-1]
<LocutusOfBorg> slangasek, I know it https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=ca-certificates-java&archive=no&pend-exc=pending-fixed&pend-exc=fixed&pend-exc=done&sev-inc=critical&sev-inc=grave&sev-inc=serious&repeatmerged=yes
<LocutusOfBorg> pick one :) they are all the same, openjdk depending on ca-certificate-java, that depends on openjdk
<LocutusOfBorg> depending on which is configured before, there is a failure or not
<LocutusOfBorg> don't really know how to fix it
<slangasek> ugh
<slangasek> LocutusOfBorg: if it's genuinely a circular dependency between two packages that both have maintainer scripts, either one should figure out how to not require a maintainer script, or the binary packages should just be merged
<LocutusOfBorg> slangasek, doko is the maintainer, not me :)
<LocutusOfBorg> I'm just trapped by that bug too :/
<LocutusOfBorg> not sure why only armhf spots that bug, maybe slowl architecture, but interesting this happens in Debian too
<LocutusOfBorg> and makes things sad
-queuebot:#ubuntu-release- New sync: amp (artful-proposed/primary) [0.6-2]
-queuebot:#ubuntu-release- Unapproved: vlan (trusty-proposed/main) [1.9-3ubuntu10.4 => 1.9-3ubuntu10.5] (core)
-queuebot:#ubuntu-release- Unapproved: vlan (xenial-proposed/main) [1.9-3.2ubuntu1.16.04.3 => 1.9-3.2ubuntu1.16.04.4] (core)
-queuebot:#ubuntu-release- Unapproved: vlan (zesty-proposed/main) [1.9-3.2ubuntu2.17.04.2 => 1.9-3.2ubuntu2.17.04.3] (core)
<doko> slangasek, tdaitx: this started after "cleaning up the openjdk packaging", I suspect this has something to do with the architecture identification changing with the hotspot implementation
<acheronuk> slangasek: kcrash 5.38 fails the same way 5.37 in release started to before any of 5.38 was uploaded: https://autopkgtest.ubuntu.com/packages/kcrash/artful/amd64
<doko> I know why I didn't want to touch this area ...
<acheronuk> slangasek: so kcrash looks like a regression in release rather than a new issue in 5.38. I would also note the test passes fine locally
-queuebot:#ubuntu-release- New sync: node-irregular-plurals (artful-proposed/primary) [1.2.0-2]
-queuebot:#ubuntu-release- New: accepted node-irregular-plurals [sync] (artful-proposed) [1.2.0-2]
-queuebot:#ubuntu-release- New binary: node-irregular-plurals [amd64] (artful-proposed/none) [1.2.0-2] (no packageset)
-queuebot:#ubuntu-release- New binary: node-plur [amd64] (artful-proposed/none) [2.1.2-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-psych [amd64] (artful-proposed/universe) [2.2.4-6build1] (no packageset)
<LocutusOfBorg> doko, ^^ I successfully bootstrapped it, if you accept I'll wait to migrate and revert
<slangasek> acheronuk: yes, it is the same crash as in release; but it's the uploader's responsibility to resolve this and make the package releasable.  If you can't reproduce it locally, why not disable the test?
<LocutusOfBorg> after jruby is built
-queuebot:#ubuntu-release- New: accepted node-irregular-plurals [amd64] (artful-proposed) [1.2.0-2]
-queuebot:#ubuntu-release- New: accepted node-plur [amd64] (artful-proposed) [2.1.2-2]
<acheronuk> slangasek: I was considering disabling it, but was having a last try at working out an alternative.
<slangasek> ok
<acheronuk> same with kdelibs4support
-queuebot:#ubuntu-release- New sync: node-parse-ms (artful-proposed/primary) [1.0.1-2]
-queuebot:#ubuntu-release- New: accepted node-parse-ms [sync] (artful-proposed) [1.0.1-2]
-queuebot:#ubuntu-release- New binary: node-parse-ms [amd64] (artful-proposed/none) [1.0.1-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted node-parse-ms [amd64] (artful-proposed) [1.0.1-2]
<doko> slangasek: python-defaults and python3-defaults autopkg tests still seem to be priotized. is this correct? if yes, can we lower the priority again?
<slangasek> doko: they're still in the low priority "huge" queue; they are ahead of anything else in that low priority queue (so for example, twisted, atlas, openblas).  which packages' tests should take priority right now?
<doko> slangasek: openblas atlas, maybe twisted
<slangasek> ok, let's see
<slangasek> oh; and we definitely shouldn't continue running tests for a version of python3-defaults that's superseded in -proposed :/
<slangasek> doko: ok, python3-defaults tests dumped (except those currently running), now to re-queue them
<doko> \o/
<slangasek> hmm, not sure if the API changes have been deployed to let me dump these into the huge queue instead of the regular queue
<slangasek> alrighty, requeued by the non-api method
<Laney> slangasek: not yet, I'm told soon
<LocutusOfBorg> please accept ruby-psych
<apw> slangasek, i don't think i finished those branches, damn
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-fan [source] (zesty-proposed) [0.12.4~17.04.1]
<sil2100> smb: hm, no ubuntu-fan for xenial yet?
<smb> sil2100, that is because its not uploaded yet... probably could... and there might be a task asking apw to sponsor
 * apw looks up ... could be indeed
<smb> apw, or maybe not. cannot see anything
<smb> probably fell through some cracks
<smb> apw, I prepared a new card now for looking at the source pkg I prepared. once that looks good to you I'd push the tree and you could upload it
-queuebot:#ubuntu-release- New: accepted amp [sync] (artful-proposed) [0.6-2]
-queuebot:#ubuntu-release- New: accepted ruby-psych [amd64] (artful-proposed) [2.2.4-6build1]
-queuebot:#ubuntu-release- New binary: amp [i386] (artful-proposed/none) [0.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: amp [ppc64el] (artful-proposed/none) [0.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: amp [amd64] (artful-proposed/none) [0.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: amp [s390x] (artful-proposed/none) [0.6-2] (no packageset)
-queuebot:#ubuntu-release- New binary: amp [armhf] (artful-proposed/none) [0.6-2] (no packageset)
<jibel> hi, is there anything missing to release gnome-software 3.20.5-0ubuntu0.16.04.6 to xenial-updates?
-queuebot:#ubuntu-release- New binary: amp [arm64] (artful-proposed/none) [0.6-2] (no packageset)
-queuebot:#ubuntu-release- New: accepted amp [amd64] (artful-proposed) [0.6-2]
-queuebot:#ubuntu-release- New: accepted amp [armhf] (artful-proposed) [0.6-2]
-queuebot:#ubuntu-release- New: accepted amp [ppc64el] (artful-proposed) [0.6-2]
-queuebot:#ubuntu-release- New: accepted amp [arm64] (artful-proposed) [0.6-2]
-queuebot:#ubuntu-release- New: accepted amp [s390x] (artful-proposed) [0.6-2]
-queuebot:#ubuntu-release- New: accepted amp [i386] (artful-proposed) [0.6-2]
-queuebot:#ubuntu-release- New binary: tortoisehg [amd64] (artful-proposed/universe) [4.3.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted tortoisehg [amd64] (artful-proposed) [4.3.1-1]
<LocutusOfBorg> why are ubuntu chroots still mentioning perl 5.24? aren't them regenerated from time to time?
<cjwatson> both of these things can be true :-)
<cjwatson> infinity: ^-
<LocutusOfBorg> 123 upgraded, 13 newly installed, 0 to remove and 0 not upgraded.
<LocutusOfBorg> installing them everytime for every build is really time consuming, and polluting logs :)
<cjwatson> some day we'll do the rainbows-and-unicorns project of building buildd chroots as livefs builds in LP and then it'll be much easier to refresh regularly
-queuebot:#ubuntu-release- New sync: elvish (artful-proposed/primary) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted elvish [sync] (artful-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New binary: python-pygal [amd64] (artful-proposed/universe) [2.4.0-1] (no packageset)
<doko> Laney: did you override the autopkgtest for gvfs/1.34.0-0ubuntu1 in the recent past? like
<doko> # the remaining failures aren't glib's fault
<doko> force-skiptest glib2.0/2.53.6-1ubuntu2
<doko> now blocks other packages too
<LocutusOfBorg> this should unblock pytest-catchlog unbuildability/brokeness ^^ and meh, I want the python3 package too :)
<Laney> http://autopkgtest.ubuntu.com/packages/g/gvfs/artful/i386
<Laney> that version of glib ran against a different gvfs, and it passed
<doko> but how did gvfs migrate then?
<Laney> it passed its own tests
-queuebot:#ubuntu-release- New: accepted python-pygal [amd64] (artful-proposed) [2.4.0-1]
<doko> slangasek: since about an hour, publisher runs seem to be at usual speeds now. again, it's a feeling, but it was slow including this morning
<apw> doko, most of the runs since 4am my time have been about the 40-50m mark, one was 1:10
<doko> apw: it was was others observed as well yesterday, in that binaries accepted only appeared one run later as usual
-queuebot:#ubuntu-release- New binary: elvish [s390x] (artful-proposed/universe) [0.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: elvish [amd64] (artful-proposed/universe) [0.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: elvish [ppc64el] (artful-proposed/universe) [0.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: elvish [arm64] (artful-proposed/universe) [0.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: elvish [i386] (artful-proposed/universe) [0.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: elvish [armhf] (artful-proposed/universe) [0.10.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted elvish [amd64] (artful-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted elvish [armhf] (artful-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted elvish [ppc64el] (artful-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted elvish [arm64] (artful-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted elvish [s390x] (artful-proposed) [0.10.1-1]
-queuebot:#ubuntu-release- New: accepted elvish [i386] (artful-proposed) [0.10.1-1]
<infinity> cjwatson: That particular unicorn is on my TODO.
<infinity> cjwatson: Though I do also enjoy that chroot upgrades catch fun package bugs more often than one would expect.
<gaughen> aw, I forgot that my chat highlights on unicorn :-)
<LocutusOfBorg> infinity, do you have examples of such failures during chroot updates?
<LocutusOfBorg> of course I wouldn't do a chroot update the day that there is a new perl out, or a new debhelper or dpkg
<LocutusOfBorg> I just recreated my pbuilder chroot, and they decreased from 250MB to 100MB
<infinity> LocutusOfBorg: Well, most recently was python3-defaults (though that was caught in proposed, so would have been caught even with more frequent updates), but we've had many in the past where an upgrade from a few months ago to today broke, but not from yesterday to today.
<infinity> LocutusOfBorg: Not saying that's a valid reason for the chroots being stale, just a cute side-effect.
<LocutusOfBorg> debian does them weekly IIRC
<LocutusOfBorg> and I agree that they might be painful
<LocutusOfBorg> but installing 100MB of packages at each build is... slow
<infinity> Not terribly.
<LocutusOfBorg> and now we are past freeze, so they should be some stability
<infinity> Not compared to build-deps for most packages.
<infinity> But you're not telling me anything I don't know, either. :P
<LocutusOfBorg> :)
<LocutusOfBorg> well, they are poisoning the logs, I do meld them when I find regressions, and that upgrade at the begin takes a lot of place
<infinity> Honestly, the only person who usually has a resonable argument for chroot staleness is doko, who wants the old build-essential kicked out when gcc bumps versions, so people with undeclared build-deps on old-gcc will FTBFS.
<infinity> "poisoning the logs" is a bit strong.
<infinity> It's some extra bits at the top.
<LocutusOfBorg> I hope you got the right meaning
<LocutusOfBorg> what is annoying is that "(Reading database ... 30%
<LocutusOfBorg> (Reading database ... 35%
<LocutusOfBorg> "
<cjwatson> That's just an apt bug IMO; it shouldn't say that when stdout isn't a terminal.
<infinity> Yes, that's an annoying apt "feature" that showed up a year or two ago.
<infinity> juliank and I had a chat about it once and why it is the way it is.
<cjwatson> I fixed a similar thing in debconf a couple of months ago.
<LocutusOfBorg> just to be clear to what I mean, look at https://launchpadlibrarian.net/337787137/buildlog_ubuntu-artful-amd64.libpng1.6_1.6.32-2_BUILDING.txt.gz
<infinity> I think there's some switch I can mangle to turn that off (at the loss of some other functionality that I probably don't care about), I should look into that.
<infinity> LocutusOfBorg: We know what you mean.
<LocutusOfBorg> 1837 useless lines before the builds starts
<LocutusOfBorg> and 1276 for the actual build :)
<LocutusOfBorg> that would be awesome!
<cjwatson> (Actually, sorry, "Reading database" is dpkg, not apt.)
<LocutusOfBorg> why debian is not adding that lines?
<doko> infinity: well, saving 10-15 seconds for every build adds ... but now that all the updates are in place, please could you regenerate these?
<infinity> cjwatson: It's dpkg, but it's dpkg doing so because apt has started telling dpkg it has a controlling terminal when it doesn't.
<cjwatson> Oh right, yeah.
<doko> LocutusOfBorg: because they don't upgrade the chroot
<infinity> doko: Yeah, updates are happening soon.
<cjwatson> doko: That doesn't actually explain the lack of "Reading database" when installing build-deps.
<LocutusOfBorg> because the second one is inside sbuild?
<doko> ahh, these ...
<cjwatson> I think the answer is that Debian has a more recent version of sbuild that sets DPkg::Use-Pty=false.
<cjwatson> Dpkg, rather
<infinity> cjwatson: Is that in the new sbuild?
<infinity> cjwatson: If so, I'll put it in the chroot configs, so we get it for upgrades too.
<infinity> (And don't need a new sbuild)
<cjwatson> infinity: Yes, added in 0.69.0.  Can we please cherry-pick the sbuild fix instead?
<infinity> cjwatson: Well, we can cherrypick the sbuild fix too if you want, but the upgrades happen outside sbuild.
<cjwatson> I don't like stuff being done in chroot configs when it could be done somewhere more visible.
<cjwatson> True, but we could put that in launchpad-buildd.
<infinity> *shrug*
<infinity> Then we should move all the chroot configs into lp-buildd.
<infinity> Which then makes the chroots less reproducible for people using them outside lp-buildd.
<cjwatson> I don't think it would be terrible to duplicate configs, necessarily ...
<cjwatson> Dpkg::Use-Pty=false was apparently added as part of the huge sbuild refactoring to decouple chroot access
<cjwatson> 668e86dbfe5d14defe54926cf58dec2dc39d876f
<infinity> chroot-autobuild$ cat etc/apt/apt.conf.d/99buildd
<infinity> APT::Get::AllowUnauthenticated "1";
<infinity> APT::Install-Recommends "0";
<infinity> DPkg::Options {"--force-unsafe-io";};
<infinity> That's our current "special" congfig.
<infinity> Oh, and can I ditch the top one now?
<infinity> I think I can.
<infinity> You inject the keys now.
<cjwatson> Uh, well
<cjwatson> It's not totally reliable in all cases
<cjwatson> Yet
<infinity> Oh. :/
<infinity> That's discouraging.
<cjwatson> I mean it should be, mostly, but there are cases like local development setups where I don't think it entirely works right yet.
<cjwatson> I'd definitely like to get there.
<infinity> Anyhow, I can add Use-Pty to that, and we can also make lp-buildd write out 99buildd, overwriting whatever the chroot defaults are, if you like.
<infinity> Though, that's problematic if we need to special-case it per target.
<infinity> (ie: if that didn't exist in trusty's apt)
<cjwatson> apt doesn't care about nonexistent config keys
<infinity> No?  That's handy.
<juliank> It's also confusing that we don't care about them. I'd rather have warnings for unknown keys eventually.
<cjwatson> Special-casing per target is easy in launchpad-buildd, anyway.
<infinity> juliank: Then I need an APT::Config-Warn=false key. ;)
<cjwatson> Wouldn't be the first time.
<infinity> cjwatson: Yeah, we've done it in the past.  I don't like it, though.
<infinity> I mean, when I can help it.
<cjwatson> I would like it more if we had cdimage-style version comparison
<infinity> Yes, and I don't want to cargo-cult that around either.
<infinity> As useful as it is.
<juliank> Currently there is strictly typed config backend stuff, but it's only turned on in tests (see configure-index or whats it called for the config config format)
<cjwatson> It would certainly have to be done a bit differently in order to avoid having to upgrade launchpad-buildd for every new series.
<cjwatson> Could use distro-info, I suppose, but I kind of want to minimise buildd's dependencies on that kind of thing.
<infinity> cjwatson: Well, buildd-manager, being connected to the actual LP DB, has a real view of all the series, and their order of appearance, it could pass a dict.
<cjwatson> This is true.
<cjwatson> We already send flags for some things.
<cjwatson> (Though I wouldn't want to do this in the same way; this kind of thing doesn't need proper columns in the DB.)
<infinity> cjwatson: Or, if we're okay with magic numbers, it could just pass DIST_SEQ=19 and we know that 19==trusty, and do our comparisons on integers.
<infinity> (19 isn't trusty, but I'm too lazy to count)
<cjwatson> I'm not OK with magic numbers for this. :-)
<cjwatson> 19 is trusty if you're 0-based
<infinity> Closer than I thought.
<infinity> And no, I don't dig magic numbers.
<infinity> But an indexed array of series is a tiny amount of data lost in the noise, if we really wanted to have that on the buildds for $reasons.
<LocutusOfBorg> thanks, really thanks for caring and trying to fix it :) kudos to all of you for this!
<cjwatson> The other thing about buildd setup is that I'm trying to move things gradually towards the point where it's easier to run a test build locally via actual launchpad-buildd code.
<cjwatson> You can do it today, but it's still a fair bit of setup.
<cjwatson> So I don't want to make it *too* dependent on buildd-manager information for correct functioning.
<infinity> Fair.
<infinity> Point's moot right now anyway, as the one reason we envisioned needing version comparisons isn't an issue.
<infinity> But something to think about for the next time we think we care.
<doko> python-twisted-core/amd64 unsatisfiable Depends: python-automat (>= 0.6.0)
<doko> python3-twisted/amd64 unsatisfiable Depends: python3-automat (>= 0.6.0)
<doko> why? this dependency was good enough to run all it's tests ...
<cjwatson> doko: main vs. universe
<cjwatson> doko: it's in c-m-proposed
<doko> ahh, and it still sees 0.5 in release/universe
<doko> so this should go away, and then the autopkg tests run again \o/
<doko> now looking at the virtualbox autopkg test failure ... did anybody look at those before?
<LocutusOfBorg> doko, ping me for vbox
<LocutusOfBorg> Running module version sanity check.
<LocutusOfBorg> Error! Module version 5.1.28_Ubuntu for vboxvideo.ko
<LocutusOfBorg> is not newer than what is already found in kernel 4.13.0-11-generic (5.1.28_Ubuntu).
<LocutusOfBorg> apw, ^^ please ignore it
<LocutusOfBorg> the kernel has already the module builtin, so the dkms one can't be installed
<LocutusOfBorg> this is a bug that is in dkms, that should ignore and not error out when the module is already available and provided
<LocutusOfBorg> anyhow, ignoring is fine
<LocutusOfBorg> (that test works when virtualbox has an higher version than the kernel one, and fails when kernel folks merge the version)
-queuebot:#ubuntu-release- Unapproved: maas (trusty-proposed/main) [1.9.5+bzr4599-0ubuntu1~14.04.1 => 1.9.5+bzr4599-0ubuntu1~14.04.2] (ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected vlc [source] (zesty-proposed) [2.2.6-6~ubuntu17.04.1]
-queuebot:#ubuntu-release- Unapproved: aodh (zesty-proposed/main) [4.0.1-0ubuntu0.17.04.1 => 4.0.2-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ceilometer (zesty-proposed/main) [1:8.0.2-0ubuntu0.17.04.1 => 1:8.1.1-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cinder (zesty-proposed/main) [2:10.0.4-0ubuntu1 => 2:10.0.6-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted partitionmanager [source] (zesty-proposed) [3.0.0-1ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: heat (zesty-proposed/main) [1:8.0.2-0ubuntu1 => 1:8.0.4-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: keystone (zesty-proposed/main) [2:11.0.2-0ubuntu1 => 2:11.0.3-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted partitionmanager [source] (xenial-proposed) [1.2.1-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted kdeplasma-addons [source] (zesty-proposed) [4:5.9.5-0ubuntu0.3]
-queuebot:#ubuntu-release- Unapproved: accepted vlan [source] (zesty-proposed) [1.9-3.2ubuntu2.17.04.3]
-queuebot:#ubuntu-release- Unapproved: neutron-fwaas (zesty-proposed/main) [1:10.0.1-0ubuntu1 => 1:10.1.0-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: sahara (zesty-proposed/universe) [1:6.0.0-0ubuntu1 => 1:6.0.2-0ubuntu1] (openstack)
-queuebot:#ubuntu-release- Unapproved: accepted vlan [source] (xenial-proposed) [1.9-3.2ubuntu1.16.04.4]
-queuebot:#ubuntu-release- Unapproved: accepted vlan [source] (trusty-proposed) [1.9-3ubuntu10.5]
-queuebot:#ubuntu-release- Unapproved: nova (zesty-proposed/main) [2:15.0.6-0ubuntu1.1 => 2:15.0.7-0ubuntu1] (openstack, ubuntu-server)
<stgraber> can I get a quick review of https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1718342 ? nothing crazy in there and would love to upload before the sprint
<ubot5> Ubuntu bug 1718342 in lxd (Ubuntu) "[FFe] LXD 2.18" [Undecided,New]
-queuebot:#ubuntu-release- New: rejected calc-stats [source] (artful-proposed) [1.2-0ubuntu1]
<doko> finally \o/
-queuebot:#ubuntu-release- New source: calc-stats (artful-proposed/primary) [1.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: neutron (zesty-proposed/main) [2:10.0.2-0ubuntu1.1 => 2:10.0.3-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (trusty-proposed) [1.2.2-0ubuntu13.1.23]
-queuebot:#ubuntu-release- Unapproved: rejected maas [source] (trusty-proposed) [1.9.5+bzr4599-0ubuntu1~14.04.2]
-queuebot:#ubuntu-release- New binary: gnome-getting-started-docs [amd64] (artful-proposed/main) [3.26.0-0ubuntu1] (personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: gnome-user-docs [amd64] (artful-proposed/main) [3.26.0-0ubuntu1] (personal-gunnarhj, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: accepted maas [source] (trusty-proposed) [1.9.5+bzr4599-0ubuntu1~14.04.2]
<slangasek> stgraber: looking
<slangasek> stgraber: btw, can you explain why introspecting docker/run/systemd/resolve/resolv.conf and grepping out fe80 is a "better" way to handle detecting DNS?
<slangasek> /run/systemd/resolve/resolv.conf seems like an implementation detail to me rather than a public interface; and I don't know why fe80 is showing up here in the first place
<stgraber> slangasek: so the reason why I did it that way is because fe80 was showing up in systemd-resolve --status but it was rather annoying to filter out
<stgraber> slangasek: as --status is meant to be user readable with fancy formatting and stuff. The underlying file OTOH can be trivially parsed to drop the odd fe80 and then look for a "real" DNS server
<slangasek> stgraber: right, not being able to just grep -v the line because of multiple nameservers on the line would be annoying, I can see that.  But why is the fe80 there to begin with?
<slangasek> the tests clearly passed just one revision earlier, and I've never seen this fe80 before
<stgraber> slangasek: my guess is that it has to do with netplan recently re-enabling IPv6 (which is a good thing)
<stgraber> slangasek: the docker test failure showing up lines up pretty well with that nplan upload
<stgraber> I'm still confused as to why resolved would ever consider/show a link-local address for a dns server though
<slangasek> stgraber: well, see parallel discussion in #ubuntu-devel where a LL ipv4 address is exactly what you expect to see in some clouds :)  But I don't know where the ipv6 one is coming from...
<slangasek> I was wondering what lxd had changed to start advertising this into containers - but I guess not
<stgraber> slangasek: LXD didn't change, but nplan until a couple of days ago would turn off IPv6 entirely on all interfaces it manages
<stgraber> slangasek: which is likely why mwhudson didn't see the fe80 craziness when he added that code to the docker.io adt
<stgraber> slangasek: then cyphermox fixed the nplan issue, re-enabling IPv6 on nplan managed interfaces by default (for SLAAC), causing this thing to show up
<slangasek> sure
<slangasek> but when you say "fe80 craziness"
<stgraber> slangasek: my guess is that something (most likely networkd) is parsing the RA and extracing the RDNSS field, which dnsmasq most likely populates with both link-local and global IPv6 addresses of the DNS server
<slangasek> this is a container, launched via lxd
<slangasek> so... there shouldn't be any "craziness" there that's not of lxd's doing? :)
<slangasek> ah, dnsmasq
<slangasek> ok
<stgraber> none of that is new, but in the past we didn't have networkd extracting that stuff and the switch to networkd happened at the same time as nplan turned off ipv6
<slangasek> stgraber: ok, but then you still have the situation that fe80 is showing up in the list but is not working for DNS resolution (else you would not have needed to grep it out)
<slangasek> is the problem that this is recorded as link local without corresponding interface routing info?
<slangasek> is this a systemd bug?
<stgraber> let me re-check an older log, I may have an idea of what's actually happening (and it may not be a systemd bug after all)
<slangasek> ok
<stgraber> hmm, "temporary failure resolving", ok, so my theory that DNS was functional but DHCPv4 wasn't, causing a missing IPv4 route to ftpmaster.internal, is wrong.
<stgraber> so yes, it does look like we somehow hit a case where systemd-networkd had received a DNS server for the interface through a RA but is unable to send DNS requests to it
<stgraber> which would point at a systemd-resolved bug
<slangasek> stgraber: would you mind opening a bug report on systemd then, so we can discuss it next week w/ xnox?
<stgraber> http://paste.ubuntu.com/25588197/ that confirms that the dnsmasq side of things is fine, DNS resolves through all 3 addresses
<stgraber> yeah, I'll file a systemd bug
<slangasek> ta
<stgraber> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1718771
<ubot5> Ubuntu bug 1718771 in systemd (Ubuntu) "Incorrect handling of link-local IPv6 DNS servers" [Undecided,New]
<slangasek> LocutusOfBorg: where are these virtualbox autopkgtests triggered from?  no Testsuite in debian/control, no debian/tests
<stgraber> slangasek: I hope this resolved thing didn't distract you from the LXD 2.18 FFe ;)
<slangasek> stgraber: no moreso than the half dozen other things I'm trying to juggle ;-)
<stgraber> :)
<slangasek> stgraber: it'll be a little while longer, I think perhaps you would like me to have breakfast before I review an FFe
-queuebot:#ubuntu-release- New source: calc-stats (artful-proposed/primary) [1.4-0ubuntu1]
<stgraber> slangasek: that's some pretty late breakfast, isn't it called lunch at this point? :)
<LocutusOfBorg> slangasek, please ask apw and look at discussion on #-devel :)
<LocutusOfBorg> not sure who and how are triggered
<dpb1> hi guys -- would love some release-team ffe approval on this one: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1658469
<ubot5> Ubuntu bug 1658469 in apache2 (Ubuntu) "[FFe] mod_http2 is not available in Apache" [Low,Triaged]
<slangasek> stgraber: it's still breakfast if it's the first meal.  also, eggs ;)  anyway, while I'm doing that, would you like to trade and review LP: #1567597 ?
<ubot5> Launchpad bug 1567597 in Snappy "[FFe] implement 'complain mode' in seccomp for developer mode with snaps" [Medium,Confirmed] https://launchpad.net/bugs/1567597
<apw> slangasek: virtual box is dkms, so autodep8
<stgraber> slangasek: yeah, I can take that one
<nacc> cyphermox: i also updated the corresponding MIR back to new: LP: #1687454
<ubot5> Launchpad bug 1687454 in nghttp2 (Ubuntu) "[MIR] nghttp2" [Undecided,New] https://launchpad.net/bugs/1687454
<slangasek> apw: where does that autodep8 live?
<slangasek> undiscoverable triggers offend me
<apw> the autodep8 script is in dkms, triggered direct in Britney I assume
<apw> the virtual box specific failure is because of the kernel containing those drivers too
<apw> and lob had a suggestion to change versioning in kernel
<apw> to make them not clash and trigger that issue
<slangasek> ok, and virtualbox gets triggered because it has autodep8 via dkms (in britney2, yes), and depends on python3.6
<slangasek> if we're going to hard-code it in britney, we could at least refine it to not retrigger the tests when $random_binary_package that causes us to be triggered is not the dkms package. :P
<slangasek> otherwise, I'd certainly prefer having this declared in debian/control
<slangasek> dpb1: the MIR bug does not show as approved
<slangasek> dpb1: also, process-wise, using for an FFe a bug that's already in a 'triaged' state can theoretically cause it to fall under the radar
<slangasek> dpb1: I've acked the overall design, but it blocks on MIR team signoff still
<jbicha> anyone besides Laney want to review some UIFe's? LP: #1717946 LP: #1718083 LP: #1715869 LP: #1713712
<ubot5> Launchpad bug 1717946 in ubuntu-meta (Ubuntu) "UIFe: Drop xterm and xdiagnose from default install" [Undecided,Confirmed] https://launchpad.net/bugs/1717946
<ubot5> Launchpad bug 1718083 in gnome-control-center (Ubuntu) "UIFe: Add Additional Printer Settings button" [Undecided,New] https://launchpad.net/bugs/1718083
<ubot5> Launchpad bug 1715869 in gnome-control-center (Ubuntu) "UIFe: It should say 'Position on screen' not 'Screen position' in Dock panel in 3.25.x" [Low,New] https://launchpad.net/bugs/1715869
<ubot5> Launchpad bug 1713712 in gnome-shell-extension-ubuntu-dock (Ubuntu) "[UIFe, FFe] Provide Unity Launcher API" [Medium,New] https://launchpad.net/bugs/1713712
<slangasek> apw: replied to your comment on LP: #1714968 at sil2100's request
<ubot5> Launchpad bug 1714968 in Ubuntu "[needs-packaging] [FFE] Please include uvp-monitor in Ubuntu" [Wishlist,New] https://launchpad.net/bugs/1714968
<apw> slangasek: thanks will look it over again with that in mind tommorrow
<slangasek> batch requeuing of failed autopkgtests now
<slangasek> (those referenced from britney - so only a few dozen per arch)
<slangasek> looks like all the weirdness with cups driver autopkgtests timing out is resolved
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-133.182] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.10.0-36.40~16.04.1] (kernel)
#ubuntu-release 2017-09-22
-queuebot:#ubuntu-release- New binary: linux-signed-lts-xenial [amd64] (trusty-proposed/main) [4.4.0-97.120~14.04.1] (kernel)
<tjaalton> I have a bit of a problem with tomcat8 vs tomcat8.0 and don't know how to best solve it
<tjaalton> libtomcatjss-java needs libtomcat8.0-java
<tjaalton> but with the current package it doesn't get upgraded, replacing libtomcat8-java with 8.0-java
<tjaalton> I guess putting P/C/R: libtomcat8-java would solve it, but then all upgrades would get libtomcat8.0-java, which is not desirable since it's supposed to be temporary to allow dogtag/tomcatjss to work until they've been ported to new tomcat..
<tjaalton> hmm, and now dist-upgrade worked without changes.. I'll poke it some more
<slangasek> tjaalton: Conflicts/Replaces, without Provides, should be enough to tell apt to prefer the replacing package
<tjaalton> slangasek: okay, I had a package which recommended libtomcat8-java and removing that made dist-upgrade work fine
<tjaalton> shouldn't have had that installed in the first place. fresh install seems to work fine now at least
<slangasek> ok
<slangasek> jbicha: what did you want to do about gnome-core on ppc64el? (firefox)
<slangasek> sergiusens: I see snapcraft autopkgtests failing in artful, which looks like actual bugs in snapcraft (bundling a subset of glibc libraries in the snaps, which are then incompatible with the new libc.so.6 on the system); do you concur?
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.10.0-36.40~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-lts-xenial [amd64] (trusty-proposed) [4.4.0-97.120~14.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-133.182]
-queuebot:#ubuntu-release- New binary: glewlwyd [ppc64el] (artful-proposed/universe) [1.1-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: glewlwyd [s390x] (artful-proposed/universe) [1.1-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted glewlwyd [ppc64el] (artful-proposed) [1.1-2ubuntu1]
-queuebot:#ubuntu-release- New: accepted glewlwyd [s390x] (artful-proposed) [1.1-2ubuntu1]
-queuebot:#ubuntu-release- New binary: glewlwyd [armhf] (artful-proposed/universe) [1.1-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted glewlwyd [armhf] (artful-proposed) [1.1-2ubuntu1]
-queuebot:#ubuntu-release- New binary: ubuntukylin-wallpapers [amd64] (artful-proposed/universe) [17.10.2] (ubuntukylin)
-queuebot:#ubuntu-release- New: accepted gnome-getting-started-docs [amd64] (artful-proposed) [3.26.0-0ubuntu1]
-queuebot:#ubuntu-release- New: accepted ubuntukylin-wallpapers [amd64] (artful-proposed) [17.10.2]
-queuebot:#ubuntu-release- New: accepted gnome-user-docs [amd64] (artful-proposed) [3.26.0-0ubuntu1]
-queuebot:#ubuntu-release- New sync: aether-ant-tasks (artful-proposed/primary) [1.0.1-1]
-queuebot:#ubuntu-release- New: accepted aether-ant-tasks [sync] (artful-proposed) [1.0.1-1]
<doko> $ apt-cache show linux-tools-4.13.0-11|grep Depends
<doko> Depends: libaudit1 (>= 1:2.2.1), libbinutils (>= 2.29), libbinutils (<< 2.30), libc6 (>= 2.14), libdw1 (>= 0.157), libelf1 (>= 0.144), liblzma5 (>= 5.1.1alpha+20120614), libnuma1 (>= 2.0.11), libpci3 (>= 1:3.5.2-1), libslang2 (>= 2.2.4), libudev1 (>= 183), libunwind8, zlib1g (>= 1:1.1.4), linux-tools-common
<doko> apw: ^^^ your binutils upper dependency is wrong. whatever relies in linux-tools on that is now broken in the release pocket
-queuebot:#ubuntu-release- New binary: aether-ant-tasks [amd64] (artful-proposed/none) [1.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted aether-ant-tasks [amd64] (artful-proposed) [1.0.1-1]
-queuebot:#ubuntu-release- New binary: python3.7 [s390x] (artful-proposed/none) [3.7.0~a1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python3.7 [ppc64el] (artful-proposed/none) [3.7.0~a1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python3.7 [i386] (artful-proposed/none) [3.7.0~a1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python3.7 [amd64] (artful-proposed/none) [3.7.0~a1-1] (no packageset)
<apw> doko, da'fuk ... how on earth did that happen
<apw> doko, will look into it and get it sorted out
<doko> apw: because you have 2.30 as an upper dependency
<apw> doko, those are auto-dependencies, not ones we type
<apw> it would have had to be built against the old version somehow
<doko> ohh, it's an issue in binutils ;)
<doko> but anywa, you should get tigher deps with a rebuild
-queuebot:#ubuntu-release- New binary: python3.7 [arm64] (artful-proposed/none) [3.7.0~a1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python3.7 [armhf] (artful-proposed/none) [3.7.0~a1-1] (no packageset)
<apw> doko, why are the ones there wrong? given the current version falls in that gap ?
<apw> doko, is that not a major version clamp and intended as is ?
<doko> no, it's the change of the soname, and that changes often
<doko> you can avoid it by statically linking libbfd
<doko> read the package description, it's not a stable ABI
-queuebot:#ubuntu-release- New: accepted python3.7 [amd64] (artful-proposed) [3.7.0~a1-1]
-queuebot:#ubuntu-release- New: accepted python3.7 [armhf] (artful-proposed) [3.7.0~a1-1]
-queuebot:#ubuntu-release- New: accepted python3.7 [ppc64el] (artful-proposed) [3.7.0~a1-1]
-queuebot:#ubuntu-release- New: accepted python3.7 [arm64] (artful-proposed) [3.7.0~a1-1]
-queuebot:#ubuntu-release- New: accepted python3.7 [s390x] (artful-proposed) [3.7.0~a1-1]
-queuebot:#ubuntu-release- New: accepted python3.7 [i386] (artful-proposed) [3.7.0~a1-1]
<apw> doko, ok, anyhow, they are supplied by binutils i believe, so a rebuild is sufficient to sort that out, right ?
<apw> i may have a minor update i can justify uploading
<doko> yes
<Ukikie> 3.7?  Huh.
<apw> t'is an alpha i assume, and us not be using it
<fossfreedom_> quick question - for universe packages with no specific ubuntu changes - is sync'ing with debian unstable still occurring? Reason for the question - tlp is an older version in artful compared to unstable and I'm wondering why that is.
<cjwatson> fossfreedom_: No, that stopped at Debian import freeze.  See https://wiki.ubuntu.com/ArtfulAardvark/ReleaseSchedule
<fossfreedom_> ok. thanks.
<cjwatson> Syncs can still be done manually by syncpackage if they're appropriate for the freeze state or have an exception
<fossfreedom_> cjwatson: thanks - looks like it was uploaded around the time of the  freeze date.  no worries. it will be pulled in for 18.04
<cjwatson> Indeed.
-queuebot:#ubuntu-release- Unapproved: cockpit (zesty-backports/universe) [150-2git1~ubuntu17.04.1 => 151-1~ubuntu17.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [150-2git1~ubuntu16.04.1 => 151-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [151-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (zesty-backports) [151-1~ubuntu17.04.1]
<jbicha> slangasek: I'll just have gnome-core use epiphany-browser on ppc64el since chromium-browser isn't available there either
<doko> jbicha, slangasek: I asked pat to schedule a session about firefox/rust/cargo maintenance. I think at least on architectures where we don't support firefox we can build with external dependencies like Debian is doing it. but lets see next week for that
<jbicha> doko: it's likely that webkit2gtk 2.20 (March 2018) will have a build-dependency on gcc-6, how are you thinking we'll handle that?
<sergiusens> slangasek I am sort of off today, can look at it tomorrow or ask elopio to start today if there is rush
<doko> jbicha: is that the deprecated webkit?
<jbicha> (since we have been backporting new webkit2gtk releases to 16.04 LTS as security releases)
<jbicha> no
<jbicha> deprecated webkit doesn't get new releases
<doko> and it cannot be built with GCC 7?
<jbicha> it can build with gcc-7 but gcc-6 & gcc-7 aren't in xenial currently
<doko> well, package a new gcc-mozilla then ... but then do it with gcc-7 because that will be the one in the next lts
<jbicha> ok, thanks
<ahasenack> slangasek: thanks for moving ubuntu-advantage-tools to main
<coreycb> hello release team, can we demote python-zunclient from main to universe? At this point it is just listed as a Build-Depend and Suggests.
<jbicha> coreycb: it's already in universe https://launchpad.net/ubuntu/+source/python-zunclient/+publishinghistory
<jbicha> https://people.canonical.com/~ubuntu-archive/madison.cgi?package=python-zunclient
<coreycb> jbicha: ah, great. i got a proposed-migration warning this morning so maybe it was handled today.
-queuebot:#ubuntu-release- Unapproved: python-oslo.middleware (zesty-proposed/main) [3.23.1-0ubuntu1 => 3.23.1-0ubuntu1.1] (openstack, ubuntu-server)
<elopio> ping doko . Sergio tells me there are snapcraft issues in artful. Do you have a link?
<ogra_> elopio, (from #snappy )
<ogra_> oko> snapcraft autopkg test failure: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/amd64/s/snapcraft/20170922_010609_57ea7@/log.gz
<ogra_> <doko> output: {{{b'/snap/godd/x1/bin/godd: relocation error: /snap/godd/x1/lib/x86_64-linux-gnu/libpthread.so.0: symbol __mmap, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference\n'}}}
<ogra_> <doko> but it's built with glibc-2.26 ...
<elopio> huh, this is running the snaps, not building them.
<nacc> ogra_: interesting that's the error i got with my artful build of classic snap too
<nacc> (for a different library)
<ogra_> nacc, yeah, see the discussion from #snappy :) i mentioned that ...
<nacc> ogra_: ah sorry
<ogra_> but unlikely to be actually related i think
<ogra_> especially since the above happens during build
<nacc> ogra_: isn't the output from running hte pyhooks snap?
<nacc> ogra_: or running any snap i this case?
<ogra_> might be
<nacc> ogra_: i'll read the logs a bit myself and see the backlog in #snappy
 * ogra_ actually looks at the log 
<ogra_> well, there wasnt much beyond the above and me saying "ah. i ahve seen that but only with classic on artful"
<nacc> heh
<nacc> ogra_: ok :)
<ogra_> the snaps failing in the test are non-classic though
<nacc> yep, understood -- tbh, my snap (well, the wrapper snapd ends up calling in my snap) is a lot like a non-classic snap. Except for it's write permissions.
<nacc> so I *could* see it being similar, in terms of what library is from where and why
<nacc> but again, i don't see how it would work with non-classic snaps either, if built on artful
<nacc> i guess i don't konw what's built where :/
<nacc> i would assume the snapcraft tests actually build the snap?
<ogra_> thats a question for elopio i guess
<nacc> yeah, it looks like it builds it (aroudn the middle of the log). I think it has to build it on the host, but it's not clear from the logs
<nacc> elopio: --^ ?
<elopio> nacc: yes, the test builds and runs snaps.
<ogra_> elopio, it builds them on artful using artful deps ?
<ogra_> that cant work ...
<ogra_> (especially after the libc update)
<slangasek> sergiusens: well, I think it's perhaps a "rush" in the sense that it might show that snapcraft, or the core snap, is currently broken on top of artful
<ogra_> (since it will run them on top of the xenial core afterwards)
<nacc> yeah, this is the same issue my classic snap has
<nacc> it feels like this is another argument for "don't build on artful" :)
<nacc> if it also affects confined snaps :)
<ogra_> slangasek, nah ... that has never really worked (if it did, tha was by sheer luck) and should never have been promoted as "supported"
<slangasek> nacc: well, it's at least an argument for "don't put half of glibc in your runtime and the other half in your snap"
<ogra_> do never ever build snaps with host dependencies unless you are on xenial ... thats the only meme here
<slangasek> but what's unusual is that the snapcraft testsuite errors reference only GLIBC_2.25... which is not the xenial, zesty, or artful version
<ogra_> and the reason for snapcraft cleanbuild to exist
<ogra_> yes, thats a bit weird indeed
<nacc> ogra_: good poinnt, so i think if the snapcraft dep8 tests did cleanbuilds, they might pass
<nacc> ogra_: although that would potentially required nested lxd on all archs where it runs
<ogra_> yes, for sure
<ogra_> since the lib versions match the core version the snaps are executed on
<nacc> slangasek: the issue is glibc is blacklisted (at least that's what we think) so none of it is in the snap
<ogra_> right
<ogra_> the libc version in use comes from the core snap
<nacc> slangasek: so building on artful leaves link-time dependencies to be satisfied by core, which is xenial, regardless of where your snap built
<slangasek> nacc: libpthreads, libdl are part of glibc; they are showing up as symbol mismatches
<nacc> slangasek: hrm
<nacc> slangasek: maybe it's not a good ennough blacklist :)
<slangasek> so it's possible libc is blacklisted but the other bits are not
<nacc> slangasek: yeah, in my case (git-ubuntu) it was libdl that threw the error
<slangasek> mind you, not /all/ of the test failures were this - but at least some of them are lolwut why are you splitting glibc
<ogra_> https://launchpadlibrarian.net/337868387/core_16-2.27.6+git381.783a1f9_amd64.manifest
<ogra_> libc-bin	2.23-0ubuntu9
<ogra_> libc6:amd64	2.23-0ubuntu9
<ogra_> libc6:i386	2.23-0ubuntu9
<ogra_> hmmmmm
<ogra_> mmm
<ogra_> m
<ogra_> slangasek, but we are not splitting it
<ogra_> the one shipped in core is mandatory
<slangasek> ogra_: have you looked at the errors in the log?
<ogra_> and snapcraft has code to prevent the libc package to ever end up inside a snap app package
<ogra_> yes
<slangasek> there are paths referring to libdl.so and libpthreads inside the snap being tested
<ogra_> i see the mention of 2.25
<slangasek> which means these libraries have not successfully been blacklisted from exclusion from the application snap
<ogra_> ah
<ogra_> yeah
<ogra_> so thats the issue then (still though ... why do they link against 2.25 ?)
<ogra_> hmm
<nacc> is the bug i snapcraft (not the link, but the libc blacklist) that snapcraft/internal/libraries._get_system_libs looksl ike this: http://paste.ubuntu.com/25593456/
<nacc> that's a hardcoded only libc.so.6
<ogra_> well, snapcraft explicitly denies installation of libc6
<ogra_> $ dpkg -S /lib/x86_64-linux-gnu/libpthread.so.0
<ogra_> libc6:amd64: /lib/x86_64-linux-gnu/libpthread.so.0
<ogra_> and also:
<ogra_> ls -l /snap/core/current/lib/x86_64-linux-gnu/libpthread.so.0
<ogra_> lrwxrwxrwx 1 root root 18 Sep 12 08:36 /snap/core/current/lib/x86_64-linux-gnu/libpthread.so.0 -> libpthread-2.23.so
<ogra_> so there shouldnt be a libpthread.so.0 inside the godd snap
<nacc> ogra_: ah ok
<ogra_> because of the blacklist
<ogra_> and the one from core should be used
<ogra_> the question is how did it sneak into the godd snap
<nacc> ogra_: where is the blacklist implementation? repo/_base:_fix_symlink ?
<nacc> ogra_: i'm not seeing that many references to libc in the source
<ogra_> not sure, sergiusens or kyrofa would know
<ogra_> there is a txt file somewhere that snapcraft parses
<ogra_> but at the same time it also walks ldd output for the built binaries
<ogra_> and i think the txt file (the actual blacklist) applies to deb package names ...
<ogra_> not sure if there is any verification against deb contents for the blacklisting
<elopio> snapcraft/internal/repo/manifest.txt
<ogra_> yeah
<ogra_> and that only lists deb names
<slangasek> coreycb: strange that you got an email about python-zunclient, that seems to have been in response to me fixing the component on the version in -proposed... taking it /off/ of component-mismatches.  Well, another thing to debug at some point
<coreycb> slangasek: interesting, ok
<elopio> There's also libraries/16.04
<nacc> elopio: libdl.so.2 is listed twice? is that file generated?
<ogra_> well
<ogra_> that lists 16.04 versions
<ogra_> hmm, but the link versions
<nacc> i'm very cofused by snapcraft/internal/libraries.py
<nacc> if you're building on 17.10
<nacc> it wo't find any libs file
<elopio> nacc: should be: libraries/generate_lib_list.py
<nacc> or does it generate it if it's not there?
<nacc> i wonder if that's this bug? no libraries file found, so only libc.so.6 is excluded
<elopio> nacc: and yes, that's what I was trying. Making a libraries/17.10, and see what happens on artful.
<nacc> elopio: _get_system_libs specifically
<nacc> elopio: yep
<elopio> but well, I'm very lost on this code too. For this, we need kyrofa or sergiusens.
<ogra_> i guess kyrofa actually
<ogra_> iirc he wrote that bit and the ldd crawler
<ogra_> grep pthread /home/ogra/Devel/branches/snapcraft/libraries/16.04
<ogra_> libpthread.so.0
<ogra_> libpthread.so.0
<ogra_> also interesting that this is listed twice inn a row
<nacc> ogra_: yeah lots of dupes in that file
<ogra_> seems others actually follow the symlink and list link as well asbinary lib
<ogra_> which might be because libpthread-2.23.so actually has a dash in the version ? (wild guess)
<ogra_> well, whatever ...  we'll need kyrofa
<nacc> so it seems like there might need to be two independent fixes (IMO, not konwing anythign about snapcraft): 1) there should be lib lists for all supported build targets; 2) the fallback for only excluding libc.so.6 itself is too narrow and will almost always (with libc mismatches) lead to issues like this -- it should be all libraries provided by libc
<nacc> (the bin pkg)
<ogra_> well ... 1) there is only one build target :)
<ogra_> thats the whole point
<nacc> ogra_: true, so the the artful self-tests need to use cleanbuild as well :)
<ogra_> yeah
<nacc> *artful snapcraft dep8 tests
<ogra_> elopio, do you know if there is a reason behind not using cleanbuild in that test ?
<ogra_> (and thus pulling in artful deps that will clash with the core snap anyway)
<ogra_> (even beyond this libc issues that will cause probs, but perhaps there is some valid reason to actually build native on artful)
<elopio> ogra_: mainly, that we couldn't use lxc until recently. But also, I think one of our goals is to be able to build snaps in any distro and use them in any distro.
<elopio> I'm not totally sure about that last one. Now that our container builds story is getting a lot better, I think it could make sense to always build in x.
<sergiusens> there are two things at play here, the package blacklist and then there's the thing i have been wanting to get rid of for ages but brings in some breakage, there's library collecting from the host so you don't need to bring in the equivalent stage-packages entry for everything that would be satisfied by a build-packages entry
<ogra_> ellwell, the last one will definitely not work until we have base snaps for all possible releases and distro combos
<ogra_> elopio, ^^
<ogra_> sergiusens, well, even if your blacklist works using artful libs inside of snaps that run on top of a xenial core screams for breakage
<ogra_> sergiusens, that can work once there are base snaps and an artful-base exists .. but not before
<ogra_> the test should just use cleanbuild if possible
<elopio> with libraries/17.10, godd works built and run in artful.
<ogra_> matter of luck :)
<nacc> yeah, it seems like you're just not hitting some ABI change, right?
<ogra_> (though its is go ... that will behave better anyway ... if your snap includes actual libs via stage-packages that can quickly fall apart)
<nacc> but it's possible to get an ABI change in any of this that might break an app?
<sergiusens> ogra_ the only requirement we were given for anything other than xenial (and in future, not built using a proper base) is that people should be allowed to experiment
<elopio> ogra_: I wasn't saying it was a good solution, just reporting on my experiment :)
<ogra_> sergiusens, sure ... and keep the pieces
<nacc> elopio: if nothing else, that fix allows people to continue to usupported experiment
<ogra_> sergiusens, but surely nothing you should use in an official test
<ogra_> anyway, myth solved \o/
<nacc> the implication is, also, though that there is a missing unit or integration test for this, right?
<sergiusens> ogra_ the tests were fine as they allowed us to know where we standed, now I need to sit down and think
<sergiusens> nacc what is missing?
<ogra_> heh, thats another way to put it indeed :)
<nacc> sergiusens: a snap was allowed to build using components of libc from a distribution and nnot the core snap
<nacc> sergiusens: and ship said components in their sap
<nacc> *snap (my n key is struggling!)
<sergiusens> nacc oh, that is what we were told to allow and not worry about
<ogra_> lol
<nacc> who in the world said that?
<nacc> it can't work...
<ogra_> well
<sergiusens> nacc I'd rather not mention ;-)
<nacc> ok, it *might* work in some cases :)
<ogra_> it would work if you included *all* of libc
<nacc> yeah
<nacc> you can't include part of it, that's the point slangasek was making
<ogra_> the issue here is that only pieces of the libc package were included
<ogra_> i.e. not libc itself
<nacc> ogra_: yep
<ogra_> but libpthread
<ogra_> and libdl
<nacc> well everythingn but libc.so.6 :)
<ogra_> right
<nacc> elopio:
<nacc> elopio'
<sergiusens> ogra_ ah, ic; that can be fixed
<nacc> bah! that filelist fix will fix that, at least
<sergiusens> nacc I would rather just not auto include anything :-)
<ogra_> sergiusens, nut that wont help with other libs that are linked against a newer libc ... which will fall apart equally
<sergiusens> this is a perfect excuse for that
<ogra_> s/nut/but/
<nacc> sergiusens: what do you mean by auto include?
<ogra_> (unless the actual libc they link against gets included fully in the snap indeed)
<sergiusens> and just raise en error with missing libraries that people will figure out with stage-packages or not
<sergiusens> nacc say you say `build-packages: [licurl-dev]`, this would install -dev and libcurl on the host; if you noticed, you don't need to add a `stage-packages: [libcurl]` entry because we crawl the host for libraries to make things easier; I have disliked this feature since forever and given the no break policy we just left it there and added an entry t
<sergiusens> o not do this. It seems it would be beneficial for everyone that this not be done automatically at all and raise an error with the missing libraries you have. Anyhow, this is getting snapcraft specific, not sure if worth discussing on #ubuntu-release anymore
<nacc> sergiusens: +1 on being as explicit as possible
<nacc> ogra_: but this still does't explain the wrong GLIBC version in the logs, right?
<doko> slangasek: the reason that you see GLIBC_2.25 is that this is the symbol version. glibc 2.26 didn't have any new symbols compared to glibc-2.25.
<nacc> doko: ah that makes sense
<nacc> doko: so it is the 2.26 version of the other libs showing that
<nacc> doko: thanks!
<slangasek> doko: aha, check
<doko> what *might* happen is that you see https://sourceware.org/bugzilla/show_bug.cgi?id=22150
<ubot5> sourceware.org bug 22150 in ld "[2.29 Regression] ld.bfd keeps a version reference in .gnu.version_r for symbols which are optimized out" [Normal,Resolved: fixed]
<doko> or LP: #1715641
<ubot5> Launchpad bug 1715641 in dpkg (Ubuntu) "network-manager built against glibc-2.26 requires GLIBC_2.25 symbol yet doesn't depend on recent enough glibc" [Undecided,Triaged] https://launchpad.net/bugs/1715641
<doko> if that was built with a binutils (<< 2.29-12)
<doko> but I didn't investigate that
<nacc> doko: i think we understand (to some degree) why this is happenning to snaps
<doko> I think you'll have some fun with glibc-3.0, when glibc starts dropping deprecated symbols ... and keeping the soname
<nacc> doko: ugh
<nacc> doko: yeah :)
<infinity> Eh?  We won't drop symbols and keep the soname.
<infinity> That would be madness.
<nacc> infinity: that's what i would have thought, but i was trusting doko :)
<doko> infinity: that's the long term plan for glibc-3.0, yes. speak with upstream, carlos and florian
<infinity> doko: That's a curious new take on things.  I will indeed talk with Carlos.
<infinity> It's always in the past been understood that dropping symbols would be libc7.
<doko> but the next versions will be .27 and .28 ...
<slangasek> doko: the bogl ftbfs is some sort of toolchain bug; an inline function disappears and generates "undefined reference" when building with -Os
#ubuntu-release 2017-09-23
<apw> inline functions can always disappear no?
<slangasek> apw: yes, but then they also shouldn't generate undefined references in the exact same .c file :)
<doko> slangasek: does building with -fgnu89-inline help?
-queuebot:#ubuntu-release- New binary: python-defaults [amd64] (artful-proposed/main) [2.7.14-2ubuntu1] (core)
-queuebot:#ubuntu-release- New: accepted python-defaults [amd64] (artful-proposed) [2.7.14-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: apt (zesty-proposed/main) [1.4.6~17.04.1 => 1.4.8] (core)
-queuebot:#ubuntu-release- New binary: qtbase-opensource-src [ppc64el] (artful-proposed/main) [5.9.1+dfsg-10ubuntu1] (kubuntu, qt5, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: qtbase-opensource-src [amd64] (artful-proposed/main) [5.9.1+dfsg-10ubuntu1] (kubuntu, qt5, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: qtbase-opensource-src [s390x] (artful-proposed/main) [5.9.1+dfsg-10ubuntu1] (kubuntu, qt5, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: qtbase-opensource-src [i386] (artful-proposed/main) [5.9.1+dfsg-10ubuntu1] (kubuntu, qt5, ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: qtbase-opensource-src [armhf] (artful-proposed/main) [5.9.1+dfsg-10ubuntu1] (kubuntu, qt5, ubuntu-desktop)
#ubuntu-release 2017-09-24
-queuebot:#ubuntu-release- New binary: qtbase-opensource-src [arm64] (artful-proposed/main) [5.9.1+dfsg-10ubuntu1] (kubuntu, qt5, ubuntu-desktop)
-queuebot:#ubuntu-release- New: accepted qtbase-opensource-src [amd64] (artful-proposed) [5.9.1+dfsg-10ubuntu1]
-queuebot:#ubuntu-release- New: accepted qtbase-opensource-src [armhf] (artful-proposed) [5.9.1+dfsg-10ubuntu1]
-queuebot:#ubuntu-release- New: accepted qtbase-opensource-src [ppc64el] (artful-proposed) [5.9.1+dfsg-10ubuntu1]
-queuebot:#ubuntu-release- New: accepted qtbase-opensource-src [arm64] (artful-proposed) [5.9.1+dfsg-10ubuntu1]
-queuebot:#ubuntu-release- New: accepted qtbase-opensource-src [s390x] (artful-proposed) [5.9.1+dfsg-10ubuntu1]
-queuebot:#ubuntu-release- New: accepted qtbase-opensource-src [i386] (artful-proposed) [5.9.1+dfsg-10ubuntu1]
<mitya57> ^^^ The new binary package libqt5sql5-ibase was wrongly accepted into main, please move it to universe if possible.
<cjwatson> default for source package in main, I guess.  moving
<cjwatson> er I think somebody did it already?
<cjwatson> mitya57: https://launchpad.net/ubuntu/artful/amd64/libqt5sql5-ibase
<mitya57> cjwatson, thatâs what I thought. Thanks for looking!
-queuebot:#ubuntu-release- New binary: kubuntu-settings [amd64] (artful-proposed/universe) [1:17.10ubuntu3] (kubuntu)
-queuebot:#ubuntu-release- New: accepted kubuntu-settings [amd64] (artful-proposed) [1:17.10ubuntu3]
<juliank> Oh, I still need to bump the apt version to 1.5 and sync it. There's not really any change since 1.5, except moving a translator comment back where it belongs; but it looks odd to release with ~rc4 :D I guess I just do the Debian part now, and sync over ASAP - queue is freezing tomorrow sometime, right?
#ubuntu-release 2018-09-17
<slangasek> mfo: libuv1> a very thorough patch explanation.  Please file this patch upstream in the Debian BTS and adjust the patch header to include Bug-Ubuntu: and Bug-Debian: references (in accordance with https://dep-team.pages.debian.net/deps/dep3/) and I will gladly sponsor
-queuebot:#ubuntu-release- Unapproved: cross-toolchain-base (bionic-proposed/main) [25ubuntu6 => 25ubuntu7] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gcc-7-cross (bionic-proposed/main) [20ubuntu4 => 21ubuntu0.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gcc-8-cross (bionic-proposed/main) [9ubuntu2 => 18ubuntu0.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: gcc-8-cross-ports (bionic-proposed/universe) [6ubuntu3 => 9ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gcc-defaults (bionic-proposed/main) [1.176ubuntu2 => 1.176ubuntu2.1] (core)
-queuebot:#ubuntu-release- Unapproved: gcc-defaults-ports (bionic-proposed/universe) [1.176ubuntu1 => 1.176ubuntu1.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (bionic-proposed) [1:6.0.6-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice-l10n [source] (bionic-proposed) [1:6.0.6-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: cross-toolchain-base-ports (bionic-proposed/universe) [21ubuntu3 => 22ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: gcc-7-cross (bionic-proposed/main) [20ubuntu4 => 21ubuntu0.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected gcc-7-cross [source] (bionic-proposed) [21ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7-cross [source] (bionic-proposed) [21ubuntu0.1]
<sbeattie> why did golang-1.7 come back into cosmic?
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross [source] (bionic-proposed) [18ubuntu0.1]
<doko> synced?
<cjwatson> odd auto-sync / proposed-migration race possibly?
<cjwatson> auto-sync doesn't sync previously-removed packages of its own volition
<LocutusOfBorg> I think doko did the remove while autosync was running?
<cjwatson> could be, should be discoverable from auto-sync logs
<LocutusOfBorg> nack, logs seems to be it didn't get autosyncd?
<LocutusOfBorg> *say
<cjwatson> the LP publication history seems to think auto-sync did it, but I haven't checked in detail
<LocutusOfBorg> I see what LP says, but I can't find references here http://people.canonical.com/~ubuntu-archive/auto-sync/2018-05-05/
<apw> LocutusOfBorg, that publishing history says it was removed from proposed by britney, removed from release by doko, and copied into release by britney in that order; so think that is an overlap
<apw> LocutusOfBorg, the autosync would not necessarily have been that day
<LocutusOfBorg> oh... ok
<LocutusOfBorg> but I don't get how the same version can be in both pockets at the same time, but I'm not AA and I don't want to know probably :)
<apw> a version can be in multiple pockets, that is pretty normal
<apw> look at anything in -security and -updates
<LocutusOfBorg> yes, but this shouldn't be normal for -proposed and -release, modulo when brintey and publisher are running...
<cjwatson> could be while it was running, or could be that the post-move removal failed
<cjwatson> *post-copy
<cjwatson> the proposed-migration logs should make that clear
-queuebot:#ubuntu-release- Unapproved: gcc-8-cross-ports (bionic-proposed/universe) [6ubuntu3 => 9ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rejected gcc-8-cross-ports [source] (bionic-proposed) [9ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02+dfsg1-5ubuntu4 => 2.02+dfsg1-5ubuntu4] (core)
<mfo> slangasek, thanks for reviewing. sure, the new debdiff in LP now has both Bug-Ubuntu and Bug-Debian tags. o/
<mfo> LP #1792647
<ubot5> Launchpad bug 1792647 in libuv1 (Ubuntu) "libuv1 calls readlink() with buffer size zero for /proc/self (nodejs test-case failure on s390x and LXD)" [Undecided,New] https://launchpad.net/bugs/1792647
-queuebot:#ubuntu-release- Unapproved: gcc-7-cross-ports (bionic-proposed/universe) [16ubuntu4 => 17ubuntu0.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-8-cross-ports [source] (bionic-proposed) [9ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-7-cross-ports [source] (bionic-proposed) [17ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (trusty-proposed/universe) [20180510+dfsg1-0ubuntu3~14.04.3 => 20180905+dfsg1-0ubuntu1~14.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: gce-compute-image-packages (xenial-proposed/universe) [20180510+dfsg1-0ubuntu3~16.04.1 => 20180905+dfsg1-0ubuntu1~16.04.0] (ubuntu-cloud)
-queuebot:#ubuntu-release- Unapproved: cross-toolchain-base (bionic-proposed/main) [25ubuntu6 => 26ubuntu0.1] (ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: rejected cross-toolchain-base [source] (bionic-proposed) [25ubuntu7]
-queuebot:#ubuntu-release- Unapproved: accepted cross-toolchain-base [source] (bionic-proposed) [26ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted cross-toolchain-base-ports [source] (bionic-proposed) [22ubuntu0.1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-defaults [source] (bionic-proposed) [1.176ubuntu2.1]
-queuebot:#ubuntu-release- Unapproved: accepted gcc-defaults-ports [source] (bionic-proposed) [1.176ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: cross-toolchain-base-ports (bionic-proposed/universe) [22ubuntu0.1 => 22ubuntu0.2] (no packageset)
-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: gce-compute-image-packages (xenial-proposed/universe) [20180510+dfsg1-0ubuntu3~16.04.1 => 20180905+dfsg1-0ubuntu1~16.04.0] (ubuntu-cloud)
<mdeslaur> doesn't look like the publisher ran in the past 5 hours, is something wrong? (ie: privoxy in trusty-security isn't showing up...)
-queuebot:#ubuntu-release- Unapproved: accepted cross-toolchain-base-ports [source] (bionic-proposed) [22ubuntu0.2]
<mdeslaur> (showing up in http://archive.ubuntu.com/ubuntu/pool/universe/p/privoxy/ , for example)
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (bionic-proposed) [20180905+dfsg1-0ubuntu1~18.04.0]
<infinity> mdeslaur: Publisher has definitely been running.
<mdeslaur> infinity: any idea why the binaries aren't showing up?
<infinity> mdeslaur: Mirrors could be broken.
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (bionic-proposed) [20180905+dfsg1-0ubuntu1~18.04.0]
<infinity> mdeslaur: Looks like archive frontends haven't updated since 7am UTC.
<mdeslaur> hrm
-queuebot:#ubuntu-release- Unapproved: rejected gce-compute-image-packages [source] (xenial-proposed) [20180905+dfsg1-0ubuntu1~16.04.0]
<mdeslaur> infinity: who do I bug about that?
<infinity> mdeslaur: Wait, are you in Belgium?
<mdeslaur> was just thinking there may be a transparent proxy here
<mdeslaur> one sec, looking
<infinity> (base)adconrad@nosferatu:~$ host archive.ubuntu.com
<infinity> archive.ubuntu.com has address 10.155.0.2
<infinity> mdeslaur: ^
<infinity> mdeslaur: That's not the real archive. :P
<mdeslaur> ARGH
<mdeslaur> infinity: sorry for the trouble
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1020.21~16.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1020.21~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (xenial-proposed) [20180905+dfsg1-0ubuntu1~16.04.0]
-queuebot:#ubuntu-release- Unapproved: accepted gce-compute-image-packages [source] (trusty-proposed) [20180905+dfsg1-0ubuntu1~14.04.0]
-queuebot:#ubuntu-release- Unapproved: grub2 (cosmic-proposed/main) [2.02+dfsg1-5ubuntu4 => 2.02+dfsg1-5ubuntu4] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (cosmic-proposed) [2.02+dfsg1-5ubuntu4]
-queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (cosmic-proposed) [2.02+dfsg1-5ubuntu4]
<wxl> can anyone explain to me why xfsprogs is not in the lubuntu images? it's in our seeds..
<wxl> https://git.launchpad.net/~lubuntu-dev/ubuntu-seeds/+git/lubuntu/tree/live#n32
<jbicha> wxl: it's already in https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/tree/live-common#n3
<jbicha> you're missing jfsutils too
<tsimonq2> Wat. I just looked in debian-cd, ubuntu-cdimage, and livecd-rootfs and I can't find anything.
<tsimonq2> infinity, slangasek: Either of you have any ideas? ^
<slangasek> have you walked germinate output?
<slangasek> and compared build logs?
<tsimonq2> I have compared build logs, but I'll look at Germinate now. It seems to be including the live-common seed but for some reason not the packages inside. Peeking at Germinate.
<tsimonq2> It's in here: https://people.canonical.com/~ubuntu-archive/germinate-output/lubuntu.cosmic/all
<tsimonq2> slangasek: Perhaps there's another log file that I'm missing?
<slangasek> tsimonq2: the image build logs?
<slangasek> those are the ones I meant
<tsimonq2> slangasek: There's no output when "Resolving live-common dependencies ..." is outputted, but I also see xfsprogs as being in the "d-i-requirements" file, and with the line "! Duplicated seed: xfsprogs".
<tsimonq2> There is no other relevant output it seems.
<tsimonq2> (I'm looking at https://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/cosmic/daily-live-20180917.log )
<slangasek> isn't this a question of the livefs contents, since it's in the live-common seed
<slangasek> ?
<slangasek> so you'd need to drill down into the livefs log
<slangasek> otherwise I'm afraid I won't be able to help with this now, it's after midnight in local TZ
<tsimonq2> Alright.
<tsimonq2> slangasek: There doesn't seem to be anything relevant in there either; it would be good to get your thoughts when you wake up.
<slangasek> the next thing I would tend to suggest is to look at STRUCTURE to make sure there aren't any differences relative to other flavors that don't have this problem
<slangasek> and also probably check if lubuntu-meta needs updating
<slangasek> I do see that jfsutils has a task header for all the other live tasks but not for lubuntu
<tsimonq2> Already there, and I'll do a quick lubuntu-meta update now to confirm.
<slangasek> so archive metadata is wrong, so why
<tsimonq2> Which is why my first instinct was to check the tooling for Lubuntu-specific hacks. :P
<jbicha> um, check the tasksel package
<tsimonq2> Good idea.
<jbicha> wxl: I think tasksel not being updated for the new lubuntu is the problem
-queuebot:#ubuntu-release- Unapproved: accepted ibm-java80 [source] (xenial-proposed) [8.0.5.20-0ubuntu1]
#ubuntu-release 2018-09-18
<infinity> stgraber: Why does the lxd 'track' debconf question default to "latest" instead of "3.0"?  I'd think the latter is the behaviour you'd want if people don't know which to select (or install noninteractive).
<stgraber> infinity: it does 3.0 when installed on a LTS release of Ubuntu, 3.x otherwise. That matches what we were doing with the LXD releases as debs
<infinity> stgraber: Ahh.  Okay.
<infinity> stgraber: Except.  What if I install on 19.10 and upgrade to 20.04? :P
<infinity> stgraber: Also, neat:
<infinity> ==> Running migration from Deb to Snap
<infinity> error: The following packages depend on [lxd lxd-client]: juju-2.0
<infinity> dpkg: error processing archive /tmp/apt-dpkg-install-0xjWRT/08-lxd_1%3a0.3_all.deb (--unpack):
<infinity>  new lxd package pre-installation script subprocess returned error exit status 1
<stgraber> I'm starting to seriously consider removing that particular migration check given that it keeps finding deprecated packages on people's systems :)
<stgraber> I don't actually know whether the juju-2.0 deb can use the LXD snap so not sure if I should whitelist that particular one or not
<infinity> Hrm, I seem to have juju deb and snap installed anyway.
<infinity> What a mess
<infinity> stgraber: Maybe help them migrate too? :P
<stgraber> juju-2.0 deb got removed from the archive in 17.10 I think, so yeah, no idea what that does :)
<infinity> stgraber: You're TIL.
<infinity> uju-core (2.0.2-0ubuntu2) zesty; urgency=medium
<infinity>   * Update debian/tests/setup-lxd.sh to support LXD storage API.
<infinity>  -- StÃ©phane Graber <stgraber@ubuntu.com>  Fri, 17 Feb 2017 00:17:30 -0500
<stgraber> oh so 17.04 then, not 17.10
<stgraber> IIRC I'm also the one who processed its removal
<infinity> stgraber: Right, this is the problem that occurs with deb->snap without migration. :P
<infinity> (And I remember arguing at the time that it would leave users dead-ended)
<stgraber> yep
<stgraber> it's unfortunate that it's the LXD migration noticing that because there are more pleasant ways to handle those kind of things than another package failing in preinst :)
<stgraber> it's gonna confuse a bunch of people for sure
<stgraber> especially during 18.04 -> 20.04
<infinity> stgraber: Purging juju debs and trying again, I now get:
<infinity> => Running sanity checks
<infinity> error: The source server is running a more recent version than the destination.
<infinity> dpkg: error processing archive /var/cache/apt/archives/lxd_1%3a0.3_all.deb (--unpack):
<infinity>  new lxd package pre-installation script subprocess returned error exit status 1
<stgraber> oh, you selected 3.0?
<infinity> I did.
<stgraber> I was actually right about to fix that :)
<stgraber> one sec
<infinity> It was an option .:P
<infinity> I can pick the other.  Sec.
<stgraber> cosmic has 3.0.2, 3.0 snap has 3.0.1
<stgraber> I'm about to promote 3.0.2 to stable
<infinity> Ahh.
<infinity> Okay.
<infinity> Do that.
<infinity> I can try again in 10m.
<stgraber> done
<infinity> Oh, but now I need to refresh it manually, I tihnk.
<infinity> There we go.
<infinity> stgraber: Better.
<infinity> stgraber: But yeah, maybe helping the juju people with proper migration would be nice.
<infinity> stgraber: (and maybe getting that SRUed back to bionic too...)
<stgraber> yeah, an empty transitional package with a debconf message and no lxd depends would fix that particular issue and maybe un-confuse some users
<infinity> stgraber: Something that actually installs the snap would be even better.
<stgraber> https://bugs.launchpad.net/juju/+bug/1793074
<ubot5> Ubuntu bug 1793074 in juju "Leftover pre-snap Juju causing upgrade issues" [Undecided,New]
<cjwatson> (Also bear in mind that some people use juju from the juju team's PPA)
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1019.22]
<infinity> cjwatson: Wait, they still maintain the deb in a PPA, but not in the archive?
<infinity> cjwatson: That's all kinds of special.
<infinity> juliank: 91.189.88.149
<sil2100> Argh, the langpack instance is hanged
<cjwatson> infinity: I think it's disrecommended, I just haven't migrated away yet (no doubt along with many others)
<tjaalton> armhf binaries for 389-ds-base, 389-ds-base-dev, 389-ds-base-libs should be removed to let 389-ds-base to migrate.. I missed this arch the last time
<apw> stgraber, i selected latest and it ate my machine leaving me with lxd demandind a epoch 0 version and lxd-client demanding a epoch 1 version and not resolving
<apw> stgraber, i had to remove lxd to get the installation to complete
<stgraber> apw: do you have a log of that apt session?
<stgraber> apw: errors from preinst can be pretty confusing, the version mismatch thing is usually an indication that something went wrong in preinst like that juju-2.0 thing that infinity ran into
<stgraber> apw: you said the install completed after you removed lxd, did you mean lxd-client?
<apw> stgraber, i removed both, and in error purged both, so that didn't do any of my containers any good
<apw> i tried to remove just lxd-client and it wouldn't
<apw> the primary issue seemed to be related to
<apw> error: The following packages depend on [lxd lxd-client]: python3-libertine-lxd
<stgraber> apw: ah, python3-libertine-lxd, wtf is that
<apw> dunno but it was most unhappy to be removed
<stgraber> rmadison can't even find any record of this thing
<stgraber> looks like a leftover xenial thing maybe
<apw> now that becomes a good question
<stgraber> apw: so you tried removing python3-libertine-lxd manually and apt was pretty upset by that too?
<apw> yeah i had to remove that, lxd and lxc-client together
<apw> which is when i mad a sad a purged
<stgraber> hmm, ok, so that may be a bit of a problem... so far everyone that ran into this kind of issue has been able to either use "apt remove --purge -f <whatever>" or "dpkg --purge <whatever>" to clear the package after they've confirmed they don't completely depend on it
<stgraber> anyway, I think I'm now of the opinion that our migration code shouldn't do this check when run from within preinst because well, whether it passes or not doesn't matter that much, you need to upgrade anyway
<stgraber> so I'll change that check to be non-fatal when it's run inside preinst, it'll still log the packages that may need manual attention but that should fix the actual upgrade failures
<stgraber> apw: do you still have anything under /var/lib/lxd post-purge?
<stgraber> apw: if you do or if you were using zfs or lvm for your containers, we may still be able to recover them with a bit of work
<apw> stgraber, na, looks like you did an awsome job of cleaning up
<Odd_Bloke> stgraber: FWIW, juju-2.0 is still produced in the Juju PPA, which I'm using.
<stgraber> Odd_Bloke: interesting, anyway, the change I just pushed to the snap (waiting for build + CI still) will turn this into a warning, so won't break upgrades at least
<Odd_Bloke> OK, cool.
<Odd_Bloke> I just removed Juju. :p
<slangasek> mfo: why does the new libuv1 fail its autopkgtest on armhf?
<mfo> slangasek, hi. thanks for the libuv1 upload. would you mind triggering a nodejs rebuild for s390x on cosmic-proposed, so it picks up the libuv1 change and passes the FTBFS/test-case failure?  the other archs shouldn't need rebuilds, since this is a runtime-only change, but up to you.
<mfo> slangasek, nice timing :)
<mfo> slangasek, i'll check, one sec.
<slangasek> mfo: nodejs/s390x retrying
<mfo> slangasek, thanks.
<mfo> slangasek, the libuv1 autopkgtest failures in armhf are errors in uv_{tcp,udp}_bind() (non-zero return status). looking at libuv/src/unix/{fs,tcp,udp}.c, it doesn't look like there's any relation between the udp/tcp-bind and the fs realpath calls.   i see you already requested a re-test which failed too, so that's interesting and i'll try to go w/ some emulation here to reproduce it.. but for now, is it possible for you to request the previous version
<mfo> (1.22.0-3) to be re-tested? (i.e., trying to confirm whether it's something else in the armhf environment that's causing this between 08-28 and 09-17)
<seb128> doko, looking at the summary of changes on https://github.com/libjpeg-turbo/libjpeg-turbo/releases it looks like https://bugs.launchpad.net/ubuntu/+source/libjpeg-turbo/2.0.0-0ubuntu1 should have required a ffe?
<ubot5> Error: ubuntu bug 2 not found
<seb128> "Overhauled the build system to use CMake on all platforms, and removed the autotools-based build system."
<seb128> "Added AVX2 SIMD implementations of the colorspace conversion, chroma downsampling and upsampling, integer quantization and sample conversion, and slow integer DCT/IDCT algorithms."
<seb128> looks like non trivial/bugfix changes
<ahasenack> hi, do we know who synced tdb with debian today, or yesterday? tdb (1.3.15-4 to 1.3.16-1)
<cjwatson> ahasenack: https://launchpad.net/ubuntu/+source/tdb/+publishinghistory does
<seb128> ahasenack, I did
<cjwatson> (answer: seb128)
<ahasenack> cjwatson: it says "archive robot" sponsored it
<cjwatson> ahasenack: second entry, not first
<cjwatson> the second is the copy from -proposed to release
<ahasenack> ah, the deleted one
<cjwatson> *the first is the ...
<ahasenack> ok, I was afraid it would trigger a rebuild of other packages like samba and sssd, but since it migrated, maybe not
<seb128> ahasenack, no reason it would, there are little changes between the versions
<seb128> ahasenack, also unsure why desktop owns that one, but if some other team has interest in it I would be happy to hand that one over
<ahasenack> I think ldb is the one that retriggers many
<seb128> we have no real interaction or knowledge of that one, but it's on our report which is why I updated it
<ahasenack> but was there a particular reason to do it after feature freeze?
<ahasenack> I'm also not sure why it would be a desktop pkg
<seb128> ahasenack, the changes looked like bugfixes only, which is good candidate to get post ff
<ahasenack> ok
<ahasenack> rhythmbox, pulseaudio, are in the rdepends list, maybe that's why it's desktop
<seb128> likely, I'm just unsure we are the ones knowing it best/using it most
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-drivers-common [source] (bionic-proposed) [1:0.5.2.1]
<mfo> slangasek, ping. the armhf emulation is taking forever here, not even past debootstrap yet.  does autopkgtest allow you to request a re-test of the previous version (1.22.0-3) ?  i tried by changing the request URL, but it failed as i dont have access.
<ginggs> mfo: i've triggered libuv1/1.22.0-3
<mfo> ginggs, thanks!  it takes a while (maybe finish?) to show up in some page, like this one?
<mfo> https://autopkgtest.ubuntu.com/packages/libuv1/cosmic/armhf
<ginggs> mfo: it's only been running for 2 min 50, should take about 10 min in total to run, then maybe another 10 min or so to appear on that page
<mfo> ginggs, ah ok. and i just learned about this running.json file (linked in the main page) i see it there, w/ some logging, cool. thanks again. :)
<slangasek> mfo: I've retriggered a test for the release version of libuv1 now
<slangasek> ginggs: you can't trigger a test against the release version of a package that way when there's a version in proposed (http://autopkgtest.ubuntu.com/packages/libu/libuv1/cosmic/armhf)
<ginggs> slangasek: :o - so how to do it then?
<slangasek> ginggs: see my faked-up trigger
<mfo> slangasek, thanks!  ok, so the 1.22.0-3 run finished, and the failures are the same between release/proposed. not too bad!  does that impact this upload to -proposed?
<slangasek> ginggs: and there may be some changes soon to make it easier to do this
<mfo> (failures: search for 'not ok' in the logs)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (bionic-proposed/main) [0.130ubuntu3.3 => 0.130ubuntu3.4] (core)
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (xenial-proposed/main) [0.122ubuntu8.12 => 0.122ubuntu8.13] (core)
<slangasek> mfo: I will mark this as a badtest to let the package migrate
<ginggs> slangasek: thanks, so what made you pick binutils, would glibc have worked too?
<mfo> slangasek, ok, great. thank you.
<mfo> ginggs, thanks o/
<ginggs> mfo: yw! not that i did anything useful
<mfo> ginggs, lol, i undertand, but no worries, thanks for being willing to help. that does count, i think :)
<slangasek> ginggs: I picked binutils as one that is unlikely to have a version in -proposed at any given time
<ginggs> slangasek: ah, ok!
<tsimonq2> I should probably mention that before the beta I plan on doing a patch version bump Qt transition, which doesn't break feature freeze but does need a convenience ABI virtual package bump.
<tsimonq2> Please voice objections soon if you have them.
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [ppc64el] (bionic-proposed/universe) [4.18.0-8.9~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (bionic-proposed/universe) [4.18.0-8.9~18.04.1] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (bionic-proposed) [4.18.0-8.9~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [ppc64el] (bionic-proposed) [4.18.0-8.9~18.04.1]
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.4 => 2.02-2ubuntu8.5] (core)
-queuebot:#ubuntu-release- Unapproved: grub2-signed (bionic-proposed/main) [1.93.5 => 1.93.6] (core)
<mfo> slangasek, hey. when you're back around, could you please review/sponsor another nodejs test-case fail/fix in LP #1793226 ?  following your request on the previous one, I already submitted to Debian (BTS 909151) and included Bug-Debian/Bug-Ubuntu tags in the patch. :)  Thanks again!
<ubot5> Launchpad bug 1793226 in node-cloneable-readable (Ubuntu) "'Uncaught TypeError: nextTick is not a function' with node-process-nextick-args 2.0.0" [Undecided,In progress] https://launchpad.net/bugs/1793226
#ubuntu-release 2018-09-19
<slangasek> mfo: sponsoring; note that you have to run 'update-maintainer' as well to set the maintainer field correctly in debian/control per Ubuntu policy, debuild bails for me because my own DEBEMAIL matches ubuntu.com but you probably didn't get the error
-queuebot:#ubuntu-release- Unapproved: update-manager (xenial-proposed/main) [1:16.04.13 => 1:16.04.14] (core)
-queuebot:#ubuntu-release- Unapproved: update-manager (bionic-proposed/main) [1:18.04.11.4 => 1:18.04.11.5] (core)
-queuebot:#ubuntu-release- Unapproved: accepted appstream [source] (bionic-proposed) [0.12.0-3ubuntu1]
<LocutusOfBorg> any AA around?
<LocutusOfBorg> ldc is close to migration, needs one kick and one trivial removal...
<apw> details please
<LocutusOfBorg> sambamba kicked out to proposed (upstream is working, but so far they failed)
<LocutusOfBorg> libundead removed from armhf (the new ldc gained arm64 full support, while armhf never worked so far)
<LocutusOfBorg> and then we should be good to go
<LocutusOfBorg> btw apw for the armhf removal, details here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908920
<ubot5> Debian bug 908920 in ftp.debian.org "RM: libundead [armhf] -- RoP; FTBFS, miscompilation, rdeps never built." [Normal,Open]
<LocutusOfBorg> sambamba is going out from testing too https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907489
<ubot5> Debian bug 907489 in src:sambamba "sambamba FTBFS" [Serious,Open]
<LocutusOfBorg> so, nothing ubuntu specific and already broken since a while
<LocutusOfBorg> and since the new ldc has now good arm64 support (and reverse deps builds on arm64), I really think we should make it migrate :)
<LocutusOfBorg> (I don't know why libbiod is shown but meh)
<LocutusOfBorg> probably because of sambamba needing a kick
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (bionic-proposed/main) [1:0.5.2 => 1:0.5.2.1] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-drivers-common [source] (bionic-proposed) [1:0.5.2.1]
* gaughen changed the topic of #ubuntu-release to: Released: Xenial 16.04.5, Bionic 18.04.1 | Archive: Feature Freeze | Cosmic Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melius malum quod cognoscis
* gaughen changed the topic of #ubuntu-release to: Released: Xenial 16.04.5, Bionic 18.04.1 | Archive: Feature Freeze | Cosmic Release Coordination | Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melius malum quod cognoscis. Steve was wrong.
-queuebot:#ubuntu-release- New binary: nvidia-cuda-toolkit [amd64] (cosmic-proposed/multiverse) [9.1.85-4ubuntu1] (no packageset)
<mfo> slangasek, thanks!  ok, i'll check for update-maintainer in the future. debuild indeed didn't bail here.
-queuebot:#ubuntu-release- Unapproved: accepted apport [source] (bionic-proposed) [2.20.9-0ubuntu7.4]
-queuebot:#ubuntu-release- Unapproved: fwupd (bionic-proposed/main) [1.0.6-2 => 1.0.9-0ubuntu1] (desktop-core)
<superm1> hi, in the bionic queue there should be two fwupd uploads pending, can the older one please be removed?  the newer one includes an extra fix that has been made available since the first was uploaded
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (bionic-proposed) [1:0.5.2.1]
<rbasak> superm1: done
-queuebot:#ubuntu-release- Unapproved: rejected fwupd [source] (bionic-proposed) [1.0.9-0ubuntu1]
<superm1> rbasak, appreciated
<cpaelzer> infinity: when you accept squid-4 in new (thanks btw) please also get rid of https://launchpad.net/ubuntu/+source/squid3/3.5.27-1ubuntu2 in cosmic-proposed
<cpaelzer> it is affected by the FTBFS that the squid4 upload of ahasenack fixes and I can rebase my fix on top of that after squid-4 fully migrated
-queuebot:#ubuntu-release- New: accepted nvidia-cuda-toolkit [amd64] (cosmic-proposed) [9.1.85-4ubuntu1]
-queuebot:#ubuntu-release- New: accepted octavia [amd64] (cosmic-proposed) [3.0.0-0ubuntu2]
<ginggs> would someone please 'force bad-test pandas/pandas/0.23.3-1fakesync1ubuntu1' - I believe it has regressed in -release http://autopkgtest.ubuntu.com/packages/p/pandas/cosmic/ppc64el (if I triggered that correctly)
<ginggs> err 'force-badtest pandas/0.23.3-1fakesync1ubuntu1'
<ginggs> would someone please RM ppc64el binaries for kicad?  ANAIS
<slangasek> ginggs: I will remove; but do you know why it dropped architectures? undocumented in the debian changelog
<slangasek> ginggs: n/m, found it [8cfc758]
<ginggs> slangasek: thanks, yes boost:context
<jbicha> slangasek: could you remove sysprof/cosmic/s390x ? it only built because we ignored build tests failures in a previous upload
-queuebot:#ubuntu-release- Unapproved: accepted snapd-glib [source] (xenial-proposed) [1.33-0ubuntu0.16.04.1]
<slangasek> jbicha: this will introduce a ftbfs for gnome-builder on s390x; removing that would make gnome-devel uninstallable; do you want to propose an appropriate method for unwinding that?
-queuebot:#ubuntu-release- Unapproved: gnome-software (bionic-proposed/main) [3.28.1-0ubuntu4.18.04.3 => 3.28.1-0ubuntu4.18.04.4] (ubuntu-desktop)
<jbicha> slangasek: sysprof isn't required for gnome-builder on s390x https://salsa.debian.org/gnome-team/gnome-builder/blob/debian/master/debian/control.in#L41
<slangasek> jbicha: ah ok
<slangasek> jbicha: done
<jbicha> :)
<superm1> robert_ancell_, if you're bringing in gnome-software as an SRU to bionic did you also include the patch for bug 1719797 at the same time?  I just redid the upload of fwupd's SRU to have the fwupd half of that fix
<ubot5> bug 1719797 in gnome-software (Ubuntu) "Firmware update seemingly not working" [Low,Triaged] https://launchpad.net/bugs/1719797
<robert_ancell_> superm1, it's not in there - can you propose the change for bionic?
<superm1> robert_ancell_, as in nominate for series?
<robert_ancell_> yes
<superm1> sure
-queuebot:#ubuntu-release- Unapproved: accepted maas [source] (xenial-proposed) [2.3.5-6511-gf466fdb-0ubuntu1]
<ginggs> would someone please 'force-badtest pandas/0.23.3-1fakesync1ubuntu1' ? - i believe it has regressed in release http://autopkgtest.ubuntu.com/packages/p/pandas/cosmic/amd64
<ginggs> it slipped through the cracks in debian too https://ci.debian.net/packages/p/pandas/testing/amd64/
<ginggs> i suspect the upload of python2.7
<mfo> slangasek, hello. nodejs stuff again. :) if you could please review/sponsor the patch in LP 1793367.  this should fix the build & autopkgtest of node-mime-types on cosmic on all architectures.  thanks! (p.s., i think we're almost done w/ this stuff.)
<ubot5> Launchpad bug 1793367 in node-mime-types (Ubuntu) "node-mime-types FTBFS with node-mime 2.3.1" [Undecided,In progress] https://launchpad.net/bugs/1793367
-queuebot:#ubuntu-release- New binary: equinox-framework [amd64] (cosmic-proposed/universe) [4.7.3-2] (no packageset)
<mfo> slangasek, and the last one is LP 1793392, also reported to Debian.  could you please check this one as well?
<ubot5> Launchpad bug 1793392 in node-unicode-data (Ubuntu) "autopkgtest failures due to missing node-unicode-10.0.0" [Undecided,In progress] https://launchpad.net/bugs/1793392
<mfo> slangasek, with these last 2, hopefully the two 'Regressions' affecting all archs for nodejs rdeps in the update_excuses pages should be resolved. :)
<jbicha> mfo: let's just sync the new node-mime-types version, ok?
-queuebot:#ubuntu-release- New sync: librda (cosmic-proposed/primary) [0.0.1-1]
<jbicha> never mind, node-mime-types was sponsored instead
#ubuntu-release 2018-09-20
<handsome_feng> Hi, Could someone here help me to upload the new packages? They have been approved: LP: #1792261 LP: #1792265 LP: #1792267 LP: #1792269 Thanks in advance!
<ubot5> Launchpad bug 1792261 in Ubuntu Kylin "[FFe] ukui-greeter" [Undecided,Triaged] https://launchpad.net/bugs/1792261
<ubot5> Launchpad bug 1792265 in Ubuntu Kylin "[FFe] ukui-biometric-auth" [Undecided,Triaged] https://launchpad.net/bugs/1792265
<ubot5> Launchpad bug 1792267 in Ubuntu Kylin " [FFe] ukui-biometric-manager" [Undecided,Triaged] https://launchpad.net/bugs/1792267
<ubot5> Launchpad bug 1792269 in Ubuntu Kylin " [FFe] biometric-authentication" [Undecided,Triaged] https://launchpad.net/bugs/1792269
<cjwatson> infinity: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/cosmic/buildd exists
<xnox> lamont, hey https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1793092 =) please check, and let me know if you have any questions.
<ubot5> Ubuntu bug 1793092 in openssl (Ubuntu) "[FFe] openssl 1.1.1" [Undecided,New]
<ginggs> would someone please "force-badtest kicad/5.0.0+dfsg1-2/ppc64el' since the ppc64el binaries were removed?
<infinity> cjwatson: Ta.
<slangasek> ginggs: done
<infinity> cjwatson: Sizes look plausibly similar to bionic, that's a good sign.
<LocutusOfBorg> xnox, what about using bileto to see how openssl behaves with rdeps/autopkgtests?
<infinity> cjwatson: Will get to the comparing later today.
-queuebot:#ubuntu-release- Unapproved: pcl (bionic-proposed/universe) [1.8.1+dfsg1-2ubuntu2 => 1.8.1+dfsg1-2ubuntu2.18.04.1] (no packageset)
<ginggs> slangasek: thanks, and...
<ginggs> would someone please 'force-badtest pandas/0.23.3-1fakesync1ubuntu1' ? - i believe it has regressed in release http://autopkgtest.ubuntu.com/packages/p/pandas/cosmic/amd64
<ginggs> it slipped through the cracks in debian too https://ci.debian.net/packages/p/pandas/testing/amd64/ - i suspect it was the python2.7 upload
<cjwatson> infinity: cheers
-queuebot:#ubuntu-release- New: accepted squid [source] (cosmic-proposed) [4.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted cockpit [amd64] (bionic-backports) [173-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [armhf] (bionic-backports) [173-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [ppc64el] (bionic-backports) [173-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [amd64] (bionic-backports) [176-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [armhf] (bionic-backports) [176-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [ppc64el] (bionic-backports) [176-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [arm64] (bionic-backports) [173-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [s390x] (bionic-backports) [173-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [i386] (bionic-backports) [176-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [i386] (bionic-backports) [173-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [s390x] (bionic-backports) [176-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [arm64] (bionic-backports) [176-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- New: accepted equinox-framework [amd64] (cosmic-proposed) [4.7.3-2]
-queuebot:#ubuntu-release- New sync: eclipse-platform-ui (cosmic-proposed/primary) [4.7.3-1]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-ui [sync] (cosmic-proposed) [4.7.3-1]
-queuebot:#ubuntu-release- New: accepted librda [sync] (cosmic-proposed) [0.0.1-1]
-queuebot:#ubuntu-release- New binary: librda [ppc64el] (cosmic-proposed/none) [0.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: librda [s390x] (cosmic-proposed/none) [0.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: librda [amd64] (cosmic-proposed/none) [0.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: librda [armhf] (cosmic-proposed/none) [0.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: librda [arm64] (cosmic-proposed/none) [0.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: librda [i386] (cosmic-proposed/none) [0.0.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted librda [amd64] (cosmic-proposed) [0.0.1-1]
-queuebot:#ubuntu-release- New: accepted librda [armhf] (cosmic-proposed) [0.0.1-1]
-queuebot:#ubuntu-release- New: accepted librda [ppc64el] (cosmic-proposed) [0.0.1-1]
-queuebot:#ubuntu-release- New: accepted librda [arm64] (cosmic-proposed) [0.0.1-1]
-queuebot:#ubuntu-release- New: accepted librda [s390x] (cosmic-proposed) [0.0.1-1]
-queuebot:#ubuntu-release- New: accepted librda [i386] (cosmic-proposed) [0.0.1-1]
-queuebot:#ubuntu-release- New sync: eclipse-platform-resources (cosmic-proposed/primary) [4.7.3-1]
-queuebot:#ubuntu-release- New sync: eclipse-platform-runtime (cosmic-proposed/primary) [4.7.3-2]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-resources [sync] (cosmic-proposed) [4.7.3-1]
-queuebot:#ubuntu-release- New: accepted eclipse-platform-runtime [sync] (cosmic-proposed) [4.7.3-2]
<slangasek> xnox: comment added
-queuebot:#ubuntu-release- Unapproved: git (bionic-proposed/main) [1:2.17.1-1ubuntu0.1 => 1:2.17.1-1ubuntu0.2] (core)
-queuebot:#ubuntu-release- Unapproved: accepted git [source] (bionic-proposed) [1:2.17.1-1ubuntu0.2]
<infinity> ahasenack: With squid accepted, is there a plan to get it re-merged with Debian before release?
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.8 => 2.525.9] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (bionic-proposed) [1:18.04.11.5]
-queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (xenial-proposed) [1:16.04.14]
-queuebot:#ubuntu-release- Unapproved: cross-toolchain-base-ports (bionic-proposed/universe) [22ubuntu0.2 => 22ubuntu0.3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.9]
-queuebot:#ubuntu-release- Unapproved: rejected open-vm-tools [source] (bionic-proposed) [2:10.3.0-0ubuntu1~18.04.2]
<mfo> slangasek, jbicha: thanks for your help w/ the nodejs stuff recently.  i see nodejs w/ openssl 1.0 is now in cosmic-release. \o/  thanks again.
<juliank> Laney: https://code.launchpad.net/~juliank/autopkgtest/+git/development/+merge/355422
<Laney> thx
<Laney> Looks like we didn't merge britney since 2016
<LocutusOfBorg> hello, somebodu please fix ocfs2-tools hint
<LocutusOfBorg> force-badtest ocfs2-tools/1.8.5-3ubuntu1/s390x ocfs2-tools/1.8.5-5ubuntu1/s390x ocfs2-tools/1.8.5-6ubuntu1
-queuebot:#ubuntu-release- Unapproved: cloud-initramfs-tools (xenial-proposed/main) [0.27ubuntu1.5 => 0.27ubuntu1.6] (edubuntu, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-initramfs-tools (bionic-proposed/main) [0.40ubuntu1 => 0.40ubuntu1.1] (edubuntu, ubuntu-server)
<slangasek> Laney: https://code.launchpad.net/~vorlon/britney/+git/britney2-ubuntu/+merge/355423
<ahasenack> infinity: hey, I hit an interesting issue with the squid-4 migration. squid3(src) produces a squid-dbg binary package, manually (it's in d/control), but the new squid-4(src) uses the automatic generation of dbgsym packages
<ahasenack> infinity: so there is nothing obsoleting or replacing squid-dbg. I thought about using dh_strip's --dbgsym-migration, and am running a test with that, but that adds the breaks/replaces to all dbgsym packages that are produced
<ahasenack> I'm not sure it will help. I'm trying with a new ppa build to see what will happen in an upgrade. Ah, and the other bit of info is that while before there was only one squid-dbg, now with dbgsym each subpackage gets its own dbgsym of course
<oSoMoN> can someone review and merge https://code.launchpad.net/~osomon/britney/hints-ubuntu-libreoffice/+merge/355442 please?
<slangasek> ahasenack: requires some manual surgery.  Is squid3 source package to be removed for 18.10?
-queuebot:#ubuntu-release- New source: vim-julia (cosmic-proposed/primary) [0.0~git20180821.120a0b6-0ubuntu1]
<wxl> cjwatson: it was suggested a while back that you're the best resource for grokking isolinux. lubuntu is having a problem in that its logos don't seem to show at all, which is unfortunately a problem relative to them simply being fuzzy :/ https://code.launchpad.net/~wxl/debian-cd/ubuntu/+merge/353762
<lamont> xnox: was that openssl thing really to me?  I'll look at it later today
-queuebot:#ubuntu-release- New sync: aom (cosmic-proposed/primary) [1.0.0-2]
<mfo> slangasek, ah! _one_ nodejs autopkgtest fix for Bionic now (it's the only one listed in the pending-sru page), node-tap in LP 1793612, please. :) thanks!
<ubot5> Launchpad bug 1793612 in node-tap (Ubuntu) "node-tap in bionic fails autopkgtests due to timeouts" [Undecided,In progress] https://launchpad.net/bugs/1793612
#ubuntu-release 2018-09-21
-queuebot:#ubuntu-release- Unapproved: rejected gnome-software [source] (xenial-proposed) [3.20.5-0ubuntu0.16.04.12]
<doko> Laney: any idea about the 12h build? http://autopkgtest.ubuntu.com/packages/c/cross-toolchain-base/cosmic/amd64
<Laney> not really
<Laney> sorry
-queuebot:#ubuntu-release- Unapproved: cockpit (bionic-backports/universe) [176-1~ubuntu18.04.1 => 178-1~ubuntu18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (bionic-proposed) [3.28.1-0ubuntu4.18.04.4]
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (bionic-backports) [178-1~ubuntu18.04.1]
-queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [176-1~ubuntu16.04.1 => 178-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [178-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New binary: cockpit [s390x] (xenial-backports/universe) [178-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [ppc64el] (xenial-backports/universe) [178-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [powerpc] (xenial-backports/universe) [178-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [armhf] (xenial-backports/universe) [178-1~ubuntu16.04.1] (no packageset)
<slangasek> mfo: if node-tap autopkgtest failures in bionic are a bug in the tests, it's fine to do an SRU to fix the tests but not a priority.  I'm going to mark the node-test/bionic test failures ignored; if you want LP: #1793612 SRUed please adjust the bug description accordingly
<ubot5> Launchpad bug 1793612 in node-tap (Ubuntu) "node-tap in bionic fails autopkgtests due to timeouts" [Undecided,In progress] https://launchpad.net/bugs/1793612
-queuebot:#ubuntu-release- New binary: cockpit [amd64] (xenial-backports/universe) [178-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [arm64] (xenial-backports/universe) [178-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: cockpit [i386] (xenial-backports/universe) [178-1~ubuntu16.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted cross-toolchain-base-ports [source] (bionic-proposed) [22ubuntu0.3]
<xnox> lamont, no, it was for steve =) sorry
<xnox> infinity, apw, Laney, tumbleweed, slangasek, stgraber, sil2100 - please check https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1793092 and reach a consensus on it please. And if you have any questions can discuss that either in person, or here...
<ubot5> Ubuntu bug 1793092 in openssl (Ubuntu) "[FFe] openssl 1.1.1" [Undecided,New]
<xnox> or on the bug
-queuebot:#ubuntu-release- Unapproved: accepted horizon [source] (bionic-proposed) [3:13.0.1-0ubuntu2]
<mfo> slangasek, oops, fixed the SRU template in LP 1793612, sorry. thanks for the reminder.   ok, so since a bug in node-tap tests only, it doesn't block the sru of _nodejs_ in bionic?
<ubot5> Launchpad bug 1793612 in node-tap (Ubuntu Bionic) "node-tap in bionic fails autopkgtests due to timeouts" [Undecided,New] https://launchpad.net/bugs/1793612
-queuebot:#ubuntu-release- New source: vulkan-tools (cosmic-proposed/primary) [1.1.82.0+dfsg1-0ubuntu1]
-queuebot:#ubuntu-release- New source: vulkan-validationlayers (cosmic-proposed/primary) [1.1.82.0-0ubuntu1]
<tjaalton> I've uploaded some NEW stuff to cosmic ^, they need spirv-tools and vulkan-loader from the same queue
<tjaalton> vulkan upstream split the repo in four, vulkan-headers is in already but I've merged the headers back in vulkan-loader, so src:vulkan-headers can be removed (will file a bug)
<tjaalton> aand discussions with the desktop team to add mesa-vulkan-drivers to ubuntu-desktop depends would mean libvulkan1 should be promoted, but best to get the new packaging in first
<seb128> tjaalton, do you think you could turn https://bugs.launchpad.net/ubuntu/+source/vulkan/+bug/1742711 into a proper MIR formatted bug so we can get it in the review queue?
<ubot5> Ubuntu bug 1742711 in vulkan (Ubuntu) "Move Vulkan packages from Universe to Main" [Undecided,Confirmed]
<tjaalton> seb128: yes, but it would be src:vulkan-loader once the new packaging is accepted :)
<tjaalton> but I can use the current pkg for now
<seb128> yeah, if you write the content there is only to reassign to the new source
<slangasek> mfo: correct, now that you've highlighted it I've marked the node-tap test failure as non-blocking for the SRU
<tjaalton> right
<mfo> slangasek, ok, thanks!
-queuebot:#ubuntu-release- Unapproved: ledmon (bionic-proposed/universe) [0.79-2build1 => 0.90-0ubuntu1~18.04.1] (no packageset)
-queuebot:#ubuntu-release- New: accepted cockpit [amd64] (xenial-backports) [173-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [armhf] (xenial-backports) [173-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [powerpc] (xenial-backports) [173-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [s390x] (xenial-backports) [173-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [arm64] (xenial-backports) [176-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [i386] (xenial-backports) [176-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [ppc64el] (xenial-backports) [176-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [amd64] (xenial-backports) [178-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [armhf] (xenial-backports) [178-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [powerpc] (xenial-backports) [178-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [arm64] (xenial-backports) [173-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [ppc64el] (xenial-backports) [173-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [armhf] (xenial-backports) [176-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [s390x] (xenial-backports) [176-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [i386] (xenial-backports) [178-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [s390x] (xenial-backports) [178-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [i386] (xenial-backports) [173-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [powerpc] (xenial-backports) [176-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [ppc64el] (xenial-backports) [178-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [amd64] (xenial-backports) [176-1~ubuntu16.04.1]
-queuebot:#ubuntu-release- New: accepted cockpit [arm64] (xenial-backports) [178-1~ubuntu16.04.1]
#ubuntu-release 2018-09-22
<LocutusOfBorg> any AA please remove old binaries left on amd64: libc++-8-helpers (from 1:8~svn340819-1)
<LocutusOfBorg> NBS proposed only, part of llvm-toolchain-snapshot
<LocutusOfBorg> easy removal
<LocutusOfBorg> also please make ldc migrate (I asked above)
<LocutusOfBorg> also....https://code.launchpad.net/~paelzer/britney/hints-ubuntu-ocfs2-cosmic-bump/+merge/355482
<tsimonq2> infinity: wxl will be filling in as Release Manager for now while I am under the weather.
<tsimonq2> (i.e. for the Beta this week.)
#ubuntu-release 2018-09-23
-queuebot:#ubuntu-release- New binary: eclipse-platform-runtime [amd64] (cosmic-proposed/universe) [4.7.3-2build1] (no packageset)
#ubuntu-release 2019-09-16
-queuebot:#ubuntu-release- New sync: gnome-shell-extension-caffeine (eoan-proposed/primary) [0~git20190409-2]
<RikMills> cjwatson: the libreoffice build in proposed has been building on arm64, armhf for ~2.5 days, and seems stuck? can something be done there?
<RikMills> or maybe vorlon?
<cjwatson> RikMills: All I can do is cancel it (which I've done).  Looks like a pkgbinarymangler bug maybe
<RikMills> cjwatson: thanks! I assume a retry?
<LocutusOfBorg> I don't think a retry will help (except for deleting build logs...)
<cjwatson> Er, yeah, don't just stab retry.
<cjwatson> Unlikely to be transient.
<RikMills> if that is the case, can it be removed from proposed for now? it is blocking tests on other packages
<cjwatson> I'll leave decisions about that to somebody else
<RikMills> vorlon?
<LocutusOfBorg> RikMills, looks like the testsuite is leaving some spurious process...
<LocutusOfBorg> a quick and dirty solution might be to not run testsuite on arm* (leaving autopkgtests do their job), 2) see if Debian has patches, or launch gencontrol dh override with some "ps aux" command and see which are the processes
<LocutusOfBorg> I'm doing the latter in ppa
<cjwatson> I wouldn't have expected that to cause the pkgbinarymangler errors I was seeing
<LocutusOfBorg> oops indeed
<LocutusOfBorg> this line Scanning for processes to kill in build PACKAGEBUILD-17762183
<LocutusOfBorg>  is because you killed it?
<cjwatson> Yes
<LocutusOfBorg> oops my bad
<cjwatson> So please put a bit more thought in rather than stabbing testsuites which don't relate
<cjwatson> pkgstriptranslations: updating translation tarball libreoffice_6.3.1-0ubuntu1_arm64_translations.tar.gz...done
<cjwatson> gzip: stdin: unexpected end of file
<LocutusOfBorg> in any case disabling the testsuite in a ppa helps having faster debug...
<cjwatson> that's the first suspicious thing I see, but I'm mostly listening to a presentation so there may well be something before that
<cjwatson> or it could be a parallelisation problem in the packaging machinery
<cjwatson> or something else I haven't worked out
<LocutusOfBorg> lol yes
<LocutusOfBorg> dh_builddeb.pkgbinarymangler: dpkg-deb --build debian/.debhelper/uno-libs3/dbgsym-root debian/.debhelper/scratch-space/build-uno-libs3 returned exit code 2
<cjwatson> marcustomlinson: ^- you probably want to look into this one way or another?
<vorlon> RikMills: did you talk to the uploader of the stuck libreoffice package about what's needed here?  (marcustomlinson)
<vorlon> looks like cjwatson already covered this
<RikMills> vorlon: yeah. waiting to see what they say. I was a bit hasty earlier
<vorlon> ok, so you don't want me to delete it yet?
<RikMills> vorlon: would that lose the logs? if not, then removing would be ok I guess, as this version is going nowhere
<vorlon> RikMills: it does not remove the logs
<vorlon> RikMills: I also don't see any other packages in -proposed blocked by libreoffice
<vorlon> is it causing a build failure of some revdep on arm*?
<RikMills> vorlon: ok, so if it does no harm that way, then I would like it gone
<RikMills> it is causing libreoffice test against kio in proposed to fail
<RikMills> which is holding back 10 other kf5 packages
<vorlon> RikMills: that doesn't sound right.  kio would be tested against the version of the package in release, not proposed, unless someone triggered it differently
<RikMills> vorlon: test of libreoffice in release against kio in -proposed https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/arm64/libr/libreoffice/20190915_215212_d3f9b@/log.gz
<vorlon> RikMills: so, it is possible for you to rerun the test using the libreoffice from release + the kde stack, but you have to write the trigger to pull in all of the kde library dependencies together from -proposed
<RikMills> hmmmm
<RikMills> I'll give that a go in a bit
<vorlon> RikMills: yes, that log shows autopkgtest being unable to cherry-pick just kio from -proposed, so it falls back to pulling everything to -proposed, you have to search in the logs to see this
<vorlon> autopkgtest: WARNING: package ure is not installed though it should be
<vorlon> autopkgtest: WARNING: Test dependencies are unsatisfiable with using apt pinning. Retrying with using all packages from eoan-proposed
 * RikMills nods
<RikMills> vorlon: as far as I can tell on last try, all the kf5 components fetched from -proposed have since gone to -release. so I *think* just a plain retry might now work
<vorlon> RikMills: ok.  if that still doesn't work, I'm not opposed to removing libreoffice, but I'm in meetings right now so can't get to it just now
<RikMills> vorlon: sure. there is no great hurry. :)
<vorlon> Laney, juliank: hey, which version of autodep8 is used for generating the debian/tests/control on autopkgtest.u.c?  I got lost trying to figure that out, and I want a version that includes the fix for Debian bug #940001
<ubot5> Debian bug 940001 in autodep8 "Source: python-foo + Binary: python3-foo + Binary: python-foo-common -> bad" [Normal,Fixed] http://bugs.debian.org/940001
<Laney> vorlon: it's in a checkout in the home directory on the workers
<Laney> you need to `make install` it IIRC
<vorlon> Laney: so where's the hook for that?  I didn't find references to it in autopkgtest-cloud
<vorlon> and you say "home directory on the workers", which are ephemeral?
<Laney> the worker controller
<Laney> 'git grep autodep8' shows what is done in the install hook
-queuebot:#ubuntu-release- New binary: pocketsphinx [i386] (eoan-proposed/universe) [0.8.0+real5prealpha+1-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: pocketsphinx [amd64] (eoan-proposed/universe) [0.8.0+real5prealpha+1-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: pocketsphinx [ppc64el] (eoan-proposed/universe) [0.8.0+real5prealpha+1-5ubuntu1] (no packageset)
<LocutusOfBorg> please accept it, no rdeps ^^ fixing build failure and sphinxbase migration
<LocutusOfBorg> oops doko I copy-pasted your signature, so it seems uploaded by you... sorry for that!
-queuebot:#ubuntu-release- New binary: pocketsphinx [armhf] (eoan-proposed/universe) [0.8.0+real5prealpha+1-5ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: pocketsphinx [arm64] (eoan-proposed/universe) [0.8.0+real5prealpha+1-5ubuntu1] (no packageset)
<LocutusOfBorg> please remove it from s390x, Debian already removed it ^^
<vorlon> Laney: huh.  I swear I looked for the autodep8 directory on the cloud worker and did not find it.  Ok, thanks
-queuebot:#ubuntu-release- Unapproved: pulseaudio (bionic-proposed/main) [1:11.1-1ubuntu7.3 => 1:11.1-1ubuntu7.4] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: pocketsphinx [i386] (eoan-proposed/universe) [0.8.0+real5prealpha+1-5ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: pocketsphinx [ppc64el] (eoan-proposed/universe) [0.8.0+real5prealpha+1-5ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: pocketsphinx [arm64] (eoan-proposed/universe) [0.8.0+real5prealpha+1-5ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: pocketsphinx [armhf] (eoan-proposed/universe) [0.8.0+real5prealpha+1-5ubuntu2] (no packageset)
-queuebot:#ubuntu-release- New binary: pocketsphinx [amd64] (eoan-proposed/universe) [0.8.0+real5prealpha+1-5ubuntu2] (no packageset)
<LocutusOfBorg> doko, FYI readelf is utterly broken on 32 bit
 * LocutusOfBorg opens a bug, wrt abi-monitor segfault and test regression
<LocutusOfBorg> for people interested in the abi-monitor regression, https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1844119
<ubot5> Launchpad bug 1844119 in binutils (Ubuntu) "readelf crash on 32bit, leading to abi-monitor testsuite regression" [High,Confirmed]
<LocutusOfBorg> doko, does the above bug ring a bell?
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (disco-proposed) [2.578.8]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (bionic-proposed) [2.525.30]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.51]
<amurray> LocutusOfBorg: thanks - this is blocking my curl upload too
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-435 (bionic-proposed/primary) [435.21-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-430 (bionic-proposed/restricted) [430.26-0ubuntu0.18.04.2 => 430.50-0ubuntu0.18.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted dpkg [source] (bionic-proposed) [1.19.0.5ubuntu2.3]
-queuebot:#ubuntu-release- Unapproved: accepted dpkg [source] (disco-proposed) [1.19.6ubuntu1.2]
-queuebot:#ubuntu-release- Unapproved: gnome-software (disco-proposed/main) [3.30.6-2ubuntu4.19.04.1 => 3.30.6-2ubuntu4.19.04.2] (ubuntu-desktop)
<LocutusOfBorg> I know amurray unfortunately my binutils foo is quite low, I did all my best to at least trace it down to a package
-queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-430 [source] (bionic-proposed) [430.50-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: gnome-software (bionic-proposed/main) [3.28.1-0ubuntu4.18.04.10 => 3.28.1-0ubuntu4.18.04.11] (ubuntu-desktop)
-queuebot:#ubuntu-release- New source: networking-mlnx (bionic-proposed/primary) [1:12.4.0-0ubuntu0.18.04.1]
-queuebot:#ubuntu-release- Unapproved: networking-mlnx (disco-proposed/universe) [1:13.1.0-2 => 1:14.0.1-0ubuntu0.19.04.1] (no packageset)
-queuebot:#ubuntu-release- New binary: ibus [s390x] (eoan-proposed/main) [1.5.21-1~exp2ubuntu1] (desktop-core, input-methods)
-queuebot:#ubuntu-release- New binary: ibus [i386] (eoan-proposed/main) [1.5.21-1~exp2ubuntu1] (desktop-core, input-methods)
-queuebot:#ubuntu-release- New binary: ibus [amd64] (eoan-proposed/main) [1.5.21-1~exp2ubuntu1] (desktop-core, input-methods)
-queuebot:#ubuntu-release- New binary: ibus [ppc64el] (eoan-proposed/main) [1.5.21-1~exp2ubuntu1] (desktop-core, input-methods)
-queuebot:#ubuntu-release- New binary: ibus [armhf] (eoan-proposed/main) [1.5.21-1~exp2ubuntu1] (desktop-core, input-methods)
-queuebot:#ubuntu-release- New binary: ibus [arm64] (eoan-proposed/main) [1.5.21-1~exp2ubuntu1] (desktop-core, input-methods)
<infinity> Laney, vorlon: Could I get one of you to upgrade the kernel on the armhf autopkgtest hosts, so I can verify a bug fix?
<vorlon> infinity: done
<Laney> nice
<Laney> I was just going to do that
<Laney> umm
<Laney> the machines look kind of hosed dpkg-wise
<Laney> ok fixed
<vorlon> Laney: hosed dpkg-wise> hmm what happened?  unattended-upgrades in progress when I rebooted, and the reboot wasn't adequately blocked?
-queuebot:#ubuntu-release- New sync: python-hdf5storage (eoan-proposed/primary) [0.1.15-1]
<ginggs> vorlon: mind if i steal your pandas merge?
<vorlon> ginggs: has it become a merge now?  did Debian fix the ftbfs?
<ginggs> vorlon: yes, I dropped some of your cherry picks, took some from debian
<vorlon> ginggs: ok, go for it
<ginggs> and ended up with something that builds https://launchpad.net/~ginggs/+archive/ubuntu/testing/+sourcepub/10550282/+listing-archive-extra
<ginggs> vorlon: ack, thanks.  I still want to do some testing, so probably only tomorrow
-queuebot:#ubuntu-release- New binary: spoa [amd64] (eoan-proposed/universe) [3.0.1-1] (no packageset)
#ubuntu-release 2019-09-17
-queuebot:#ubuntu-release- New sync: ruby-gnome (eoan-proposed/primary) [3.3.8-2]
-queuebot:#ubuntu-release- New: accepted ppxfind [sync] (eoan-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted ruby-gnome [sync] (eoan-proposed) [3.3.8-1]
-queuebot:#ubuntu-release- New: accepted ppxlib [sync] (eoan-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: rejected ruby-gnome [sync] (eoan-proposed) [3.3.8-2]
-queuebot:#ubuntu-release- New: accepted gnome-shell-extension-caffeine [sync] (eoan-proposed) [0~git20190409-2]
-queuebot:#ubuntu-release- New: accepted python-hdf5storage [sync] (eoan-proposed) [0.1.15-1]
-queuebot:#ubuntu-release- New: rejected pocketsphinx [amd64] (eoan-proposed) [0.8.0+real5prealpha+1-5ubuntu1]
-queuebot:#ubuntu-release- New: rejected pocketsphinx [armhf] (eoan-proposed) [0.8.0+real5prealpha+1-5ubuntu1]
-queuebot:#ubuntu-release- New: rejected pocketsphinx [ppc64el] (eoan-proposed) [0.8.0+real5prealpha+1-5ubuntu1]
-queuebot:#ubuntu-release- New: rejected pocketsphinx [arm64] (eoan-proposed) [0.8.0+real5prealpha+1-5ubuntu1]
-queuebot:#ubuntu-release- New: accepted spoa [amd64] (eoan-proposed) [3.0.1-1]
-queuebot:#ubuntu-release- New: rejected pocketsphinx [i386] (eoan-proposed) [0.8.0+real5prealpha+1-5ubuntu1]
-queuebot:#ubuntu-release- New binary: gnome-shell-extension-caffeine [amd64] (eoan-proposed/none) [0~git20190409-2] (no packageset)
-queuebot:#ubuntu-release- New binary: ppxfind [i386] (eoan-proposed/none) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppxfind [amd64] (eoan-proposed/none) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppxlib [i386] (eoan-proposed/none) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppxfind [arm64] (eoan-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppxlib [amd64] (eoan-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppxfind [s390x] (eoan-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppxfind [armhf] (eoan-proposed/universe) [1.3-1] (no packageset)
-queuebot:#ubuntu-release- New binary: python-hdf5storage [amd64] (eoan-proposed/universe) [0.1.15-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppxlib [s390x] (eoan-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppxlib [arm64] (eoan-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ppxlib [armhf] (eoan-proposed/universe) [0.8.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-gnome [s390x] (eoan-proposed/universe) [3.3.8-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted pocketsphinx [amd64] (eoan-proposed) [0.8.0+real5prealpha+1-5ubuntu2]
-queuebot:#ubuntu-release- New: accepted pocketsphinx [armhf] (eoan-proposed) [0.8.0+real5prealpha+1-5ubuntu2]
-queuebot:#ubuntu-release- New: accepted pocketsphinx [ppc64el] (eoan-proposed) [0.8.0+real5prealpha+1-5ubuntu2]
-queuebot:#ubuntu-release- New: accepted pocketsphinx [arm64] (eoan-proposed) [0.8.0+real5prealpha+1-5ubuntu2]
-queuebot:#ubuntu-release- New: accepted pocketsphinx [i386] (eoan-proposed) [0.8.0+real5prealpha+1-5ubuntu2]
-queuebot:#ubuntu-release- New binary: ruby-gnome [i386] (eoan-proposed/universe) [3.3.8-1] (no packageset)
-queuebot:#ubuntu-release- New binary: ruby-gnome [amd64] (eoan-proposed/universe) [3.3.8-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted ppxfind [arm64] (eoan-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted ppxfind [i386] (eoan-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted ppxlib [amd64] (eoan-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted ppxlib [armhf] (eoan-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted ppxlib [s390x] (eoan-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted ruby-gnome [amd64] (eoan-proposed) [3.3.8-1]
-queuebot:#ubuntu-release- New: accepted ruby-gnome [s390x] (eoan-proposed) [3.3.8-1]
-queuebot:#ubuntu-release- New: accepted ppxfind [armhf] (eoan-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted ppxlib [arm64] (eoan-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted python-hdf5storage [amd64] (eoan-proposed) [0.1.15-1]
-queuebot:#ubuntu-release- New: accepted ppxfind [s390x] (eoan-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted ruby-gnome [i386] (eoan-proposed) [3.3.8-1]
-queuebot:#ubuntu-release- New: accepted ppxlib [i386] (eoan-proposed) [0.8.1-1]
-queuebot:#ubuntu-release- New: accepted gnome-shell-extension-caffeine [amd64] (eoan-proposed) [0~git20190409-2]
-queuebot:#ubuntu-release- New: accepted ppxfind [amd64] (eoan-proposed) [1.3-1]
-queuebot:#ubuntu-release- New: accepted ibus [s390x] (eoan-proposed) [1.5.21-1~exp2ubuntu1]
-queuebot:#ubuntu-release- New: accepted ibus [amd64] (eoan-proposed) [1.5.21-1~exp2ubuntu1]
-queuebot:#ubuntu-release- New: accepted ibus [armhf] (eoan-proposed) [1.5.21-1~exp2ubuntu1]
-queuebot:#ubuntu-release- New: accepted ibus [ppc64el] (eoan-proposed) [1.5.21-1~exp2ubuntu1]
-queuebot:#ubuntu-release- New: accepted ibus [arm64] (eoan-proposed) [1.5.21-1~exp2ubuntu1]
-queuebot:#ubuntu-release- New: accepted ibus [i386] (eoan-proposed) [1.5.21-1~exp2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted cogl [source] (disco-proposed) [1.22.2-6ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (bionic-proposed) [3.28.4-0ubuntu18.04.2]
<cpaelzer> RAOF: bdmurray: http://launchpadlibrarian.net/439539273/rdma-core_17.1-1ubuntu0.1_17.1-1ubuntu0.2.diff.gz is waiting in the SRU queue for quite a while but literally a rather small change to review
<cpaelzer> I usually leave SRU queue up to your time available, but since I have had affected people start bugging me on various channels I wanted to ask if one of you could suqeeze that in todays rather filled sprint day?
<bdmurray> cpaelzer: I may be able to
-queuebot:#ubuntu-release- Unapproved: gnome-software (bionic-proposed/main) [3.28.1-0ubuntu4.18.04.10 => 3.28.1-0ubuntu4.18.04.12] (ubuntu-desktop)
<cpaelzer> thank you bdmurray
-queuebot:#ubuntu-release- Unapproved: initramfs-tools (xenial-proposed/main) [0.122ubuntu8.14 => 0.122ubuntu8.15] (core)
-queuebot:#ubuntu-release- New binary: debhelper [amd64] (eoan-proposed/main) [12.6.1ubuntu1] (core)
-queuebot:#ubuntu-release- New: accepted debhelper [amd64] (eoan-proposed) [12.6.1ubuntu1]
<LocutusOfBorg> vorlon, can you please add the bug link https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1844119 to the abi-monitor hint?
<ubot5> Launchpad bug 1844119 in binutils (Ubuntu) "readelf crash on 32bit, leading to abi-monitor testsuite regression" [High,Confirmed]
<vorlon> LocutusOfBorg: no, because I don't care why it's broken
<vorlon> :)
<LocutusOfBorg> ok :) I just like to remember to drop hints when they become useless but I get your point
<LocutusOfBorg> btw alt-ergo was hinted on armhf, somebody wrongly removed it
<LocutusOfBorg>  https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/3795
-queuebot:#ubuntu-release- Unapproved: qemu (disco-proposed/main) [1:3.1+dfsg-2ubuntu3.4 => 1:3.1+dfsg-2ubuntu3.5] (ubuntu-server, virt)
<RikMills> Laney, vorlon, release team et al. Have you seen that proposed migration runs are crashing as of just after 10am today?
<Laney> nope
<Laney> Looks like it's due to rbalint's change that infinity reviewed
<Laney> I was going to look but evidently got beaten
<Laney> :-)
<rbalint> Laney, RikMills do you have some log?
<RikMills> rbalint: https://people.canonical.com/~ubuntu-archive/proposed-migration/log/eoan/2019-09-17/
<RikMills> all those since just after 10am
<vorlon> I've touched the missing file per infinity's suggestions over my shoulder
<RikMills> latest run now seems to have got past the crash point
 * RikMills crosses fingers
<Laney> for all series?
<Laney> I'd have preferred a fix in the code
<vorlon> infinity agrees and plans to fix it when back at computer
<rbalint> Laney, we are all in a meeting, will happen in a few 10 minutes, sorry for the breakage
<vorlon> and no, so far I only touched it for eoan-proposed
<Laney> ok
<LocutusOfBorg> ruby-gnome can't migrate because of ruby-gnome2 old package, but ruby-gnome replaces ruby-gnome2...
<LocutusOfBorg> so removing src:ruby-gnome2 (transitional package) will make everybody happy
<LocutusOfBorg> is this possible?
<Laney> seb128 knows and is going to do it
<seb128> indeed, sorry morning got busy, I do that next
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (disco-proposed) [3.30.6-2ubuntu4.19.04.2]
-queuebot:#ubuntu-release- Unapproved: rejected gnome-software [source] (bionic-proposed) [3.28.1-0ubuntu4.18.04.11]
-queuebot:#ubuntu-release- Unapproved: accepted gnome-software [source] (bionic-proposed) [3.28.1-0ubuntu4.18.04.12]
<rbalint> RikMills, Laney update_excuses is operational again, we just had to deploy everything and wait a bit
<RikMills> rbalint: :)
<rbalint> now there is a new update-excuse(-<release>) tag which makes the bug show up on update-excuses, like the example bug on puppet: https://people.canonical.com/~ubuntu-archive/proposed-migration/eoan/update_excuses.html#puppet
<tdaitx> Laney: hey, steve told me to get your feedback (and then mailing list) on a possible improvement for rendering/loading speed for update excuses
<tdaitx> how do you feel about:
<tdaitx> 1. removing the direct link to log.gz from all autopkgtests that "Pass"
<tdaitx> 2. same as above but only if it autopkgtests is "Pass" for all arches
<tdaitx> 3. if autopkgtest is "Pass" for all arches, remove even the arch elements (and their links)
<tdaitx> rendering is improved significantly: about 2x for #1, 3x for #2, 5x for #3 (it is dependent on how many "Pass" are the, but usually we have a lot
<tdaitx> note: simply hidding the Pass/arch elements through css or html attributes don't help nearly as much as actually removing them from the html
<vorlon> tdaitx: I didn't specify ordering, sorry if that wasn't clear :)
<tdaitx> vorlon: indeed, I just wanted to collect Laney's argument before I bring this to the mailing list
-queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [19.2-24-ge7881d5c-0ubuntu1~16.04.1 => 19.2-36-g059d049c-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [19.2-24-ge7881d5c-0ubuntu1~18.04.1 => 19.2-36-g059d049c-0ubuntu1~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: cloud-init (disco-proposed/main) [19.2-24-ge7881d5c-0ubuntu1~19.04.1 => 19.2-36-g059d049c-0ubuntu1~19.04.1] (core, edubuntu, ubuntu-cloud)
<tsimonq2> infinity: Just a heads up that I consider bug 1842382 to be an RC bug for the 19.10 beta.
<ubot5> bug 1842382 in linux (Ubuntu) "/proc/self/maps paths missing on live session (was vlc won't start; eoan 19.10 & bionic 18.04 ubuntu/lubuntu/kubuntu/xubuntu/ubuntu-mate dailies)" [Undecided,Triaged] https://launchpad.net/bugs/1842382
<tsimonq2> infinity: Differing opinions/additional eyes are welcome.
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [5.0.0-1020.21~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1044.46] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-64.73] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (bionic-proposed/main) [4.15.0-1044.70] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gke-5.0 [amd64] (bionic-proposed/universe) [5.0.0-1017.17~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [5.0.0-29.31~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1056.65] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-64.73] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-29.31] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1020.21] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [5.0.0-1020.21~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-64.73]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-64.73]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (bionic-proposed) [4.15.0-1044.70]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-5.0 [amd64] (bionic-proposed) [5.0.0-1017.17~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1056.65]
-queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1044.46]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-29.31]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [5.0.0-29.31~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1020.21]
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1017.17] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [5.0.0-29.31~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-29.31] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1025.28] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-29.31] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [arm64] (bionic-proposed/main) [5.0.0-29.31~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-164.192] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [arm64] (bionic-proposed) [5.0.0-29.31~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1025.28]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-29.31]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [5.0.0-29.31~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-29.31]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1017.17]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-164.192]
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-64.73~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-64.73~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1059.64] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1044.46] (kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1059.64]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-64.73~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1044.46]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-64.73~16.04.1]
#ubuntu-release 2019-09-18
<cpaelzer_> rbasak: http://launchpadlibrarian.net/439539273/rdma-core_17.1-1ubuntu0.1_17.1-1ubuntu0.2.diff.gz if you have a chance for some SRU today
<cpaelzer_> rbalint: https://wiki.archlinux.org/index.php/Modalias
-queuebot:#ubuntu-release- Unapproved: accepted rdma-core [source] (bionic-proposed) [17.1-1ubuntu0.2]
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (bionic-proposed/main) [1:0.5.2.3 => 1:0.5.2.4] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [19.2-36-g059d049c-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (bionic-proposed) [19.2-36-g059d049c-0ubuntu1~18.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (disco-proposed) [19.2-36-g059d049c-0ubuntu1~19.04.1]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.51 => 2.408.52] (desktop-core)
<fossfreedom> Quick question, I would like to sync a new version of the gtk arc-theme from unstable to eoan.  Does themes fall under the uife process? Basically gnome-shell 3.34 and xfce4.14 fixes
<doko> sforshee: is the riscv64 build fix in 5.3.0-12.13 ?
-queuebot:#ubuntu-release- Unapproved: keystone (disco-proposed/main) [2:15.0.0-0ubuntu1.1 => 2:15.0.0-0ubuntu1.2] (openstack, ubuntu-server)
<bryyce> I think we've got all the blockers cleared for finishing the php7.3 transition.  Can an archive admin help in dropping 7.2?  C.f. LP: #1842520
<ubot5> Launchpad bug 1842520 in php7.2 (Ubuntu) "Remove "php7.2" from Eoan, which has transitioned to php7.3" [Undecided,New] https://launchpad.net/bugs/1842520
-queuebot:#ubuntu-release- Unapproved: keystone (bionic-proposed/main) [2:13.0.2-0ubuntu1 => 2:13.0.2-0ubuntu2] (openstack, ubuntu-server)
<LocutusOfBorg> fossfreedom, go for it :)
<LocutusOfBorg> only new features are not allowed, bugfixes are good to go
<LocutusOfBorg> and when the person who syncs is also the debian maintaner, we presume he knows even better his stuff
<ahasenack> vorlon: hi, just checking, will php7.2 also be removed from proposed? I see you removed the one in universe, but proposed is still there, is it just lagging?
<infinity> cjwatson: Do you want to reupload that livecd-rootfs with -v2.408.50 or wait in queue for the previous SRU to get verified?
<vorlon> ahasenack: ah, that was overlooked; removing now
<ahasenack> vorlon: thanks!
<cjwatson> infinity: Oh right, forgot about that, I'll reupload
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.51 => 2.408.52] (desktop-core)
<infinity> cjwatson: Ta.
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (xenial-proposed) [2.408.52]
-queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.15]
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.52]
-queuebot:#ubuntu-release- New binary: rustc [s390x] (eoan-proposed/universe) [1.37.0+dfsg1+llvm-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-165.193] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-30.32] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-30.32] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-30.32] (core, kernel)
-queuebot:#ubuntu-release- New binary: rustc [ppc64el] (eoan-proposed/universe) [1.37.0+dfsg1+llvm-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: rustc [amd64] (eoan-proposed/universe) [1.37.0+dfsg1+llvm-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (disco-proposed) [5.0.0-30.32]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (disco-proposed) [5.0.0-30.32]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (disco-proposed) [5.0.0-30.32]
-queuebot:#ubuntu-release- Unapproved: grep (bionic-proposed/main) [3.1-2 => 3.1-2build1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted grep [source] (bionic-proposed) [3.1-2build1]
-queuebot:#ubuntu-release- New binary: rustc [i386] (eoan-proposed/universe) [1.37.0+dfsg1+llvm-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [5.0.0-1021.22~18.04.1] (kernel)
<LocutusOfBorg> vorlon, I just saw your imagemagick ping because mentioned on another channel, sorry for that
<LocutusOfBorg> next time please forward it again in case I missed it, my bnc sometimes eats messages
<LocutusOfBorg> apologizes
<rbalint> hi, i just would like confirmation that wireshark sync to next upstream point release does not need FFe since they are mostly bugfix releases and we also follow them in security updates
<rbalint> if no one objects i'll sync it when it migrates to Debian testing
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-165.193]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [5.0.0-1021.22~18.04.1]
<cyphermox> hi; please remove node-prismjs; it's blocked on non-existing node-clipboard, had RC bugs in Debian on that, only in unstable and blocked there for >200 days
<LocutusOfBorg> sforshee, linux-signed FTBFS and now nothing in the eoan archive can build... I retried the failed builds, lets see what happens
<LocutusOfBorg> (the error was after 1 minute of build about not being able to retrieve SHA256SUM hashes)
<LocutusOfBorg> ok now a give-back seems to have worked, I blame some network glitch...
-queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-12.13] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.3.0-12.13] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-12.13] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-12.13] (core, kernel)
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.3.0-12.13]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.3.0-12.13]
-queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.3.0-12.13]
-queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (eoan-proposed) [5.3.0-12.13]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (disco-proposed/main) [5.0.0-1021.22] (core, kernel)
-queuebot:#ubuntu-release- New binary: rustc [armhf] (eoan-proposed/universe) [1.37.0+dfsg1+llvm-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (disco-proposed) [5.0.0-1021.22]
-queuebot:#ubuntu-release- New binary: rustc [arm64] (eoan-proposed/universe) [1.37.0+dfsg1+llvm-1ubuntu1] (no packageset)
<vorlon> LocutusOfBorg: no worries.  so what's the answer on imagemagick?  Should we revert the revert of the security fix?
-queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1023.25] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (bionic-proposed/main) [4.15.0-1026.29] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1057.66] (kernel)
<LocutusOfBorg> vorlon, I already did
<LocutusOfBorg> I thought there was no hurry since the MIR was still ongoing
<LocutusOfBorg> but I happily reverted it now, and I'm uploading in my ppa a list of packages that depends on imagemagick, and I'll give security team a full review of what FTBFS because of this change
#ubuntu-release 2019-09-19
<bluesabre> release team, anybody interested in ack'ing https://bugs.launchpad.net/ubuntu/+source/catfish/+bug/1844464?  (xubuntu, budgie, studio all A-OK) If so, I can trigger a sync from unstable
<ubot5> Launchpad bug 1844464 in catfish (Ubuntu) "[FFe] Include catfish 1.4.10 in eoan (xubuntu, ubuntu-budgie, ubuntu-studio)" [Undecided,New]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1023.25]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (bionic-proposed) [4.15.0-1026.29]
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1057.66]
-queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-65.74] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-65.74] (core, kernel)
<vorlon> LocutusOfBorg: cheers :)
-queuebot:#ubuntu-release- Packageset: Added language-pack-szl-base to langpack in eoan
-queuebot:#ubuntu-release- Unapproved: nat-rtsp (bionic-proposed/universe) [0.7+1.g2ea3cb6-1ubuntu1~18.04.1 => 0.7+1.g2ea3cb6-1ubuntu1~18.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: xtables-addons (bionic-proposed/universe) [3.0-0.1ubuntu2 => 3.0-0.1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (bionic-proposed/main) [5.0.0-30.32~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [arm64] (bionic-proposed/main) [5.0.0-30.32~18.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (bionic-proposed/main) [5.0.0-30.32~18.04.1] (kernel)
<cking> hi there, thermald for bionic has been stuck in -proposed "due to block request by freeze" https://launchpad.net/ubuntu/+source/thermald/1.7.0-5ubuntu5 - can this be promoted sometime soon?
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-65.74~16.04.1] (kernel)
<Laney> cking: that's misleading - the real status of the SRU is what is shown on https://people.canonical.com/~ubuntu-archive/pending-sru.html
-queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-65.74~16.04.1] (kernel)
<cking> Laney, now I'm more confused :-/  - so is it chugging through the system and will be released sometime? (how can I tell?)
<infinity> cking: Based on pending-sru, it has a metric whackton of bugs that haven't been verified.
<infinity> cking: green good, blue bad.
<cking> infinity, ah, the blue ones are historical bugs that have already been verified in the past - i screwed up because  I accidentally uploaded the package with the entire old history.
<infinity> cking: Ah-ha.
<infinity> cking: Released.
<cking> infinity, thanks, \o/
<infinity> cking: I note on the bug that the task is still open for the devel series.  Is that a paperwork bug on your part, or a missing upload?
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (bionic-proposed) [5.0.0-30.32~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (bionic-proposed) [5.0.0-30.32~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-65.74]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [arm64] (bionic-proposed) [5.0.0-30.32~18.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-65.74]
<bluesabre> infinity: thanks a bunch!
-queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu7.18 => 1:2.11+dfsg-1ubuntu7.19] (ubuntu-server, virt)
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-drivers-common [source] (bionic-proposed) [1:0.5.2.4]
-queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (bionic-proposed/main) [1:0.5.2.3 => 1:0.5.2.4] (desktop-core, ubuntu-server)
-queuebot:#ubuntu-release- New binary: binutils-mipsen [amd64] (eoan-proposed/universe) [4~c4ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New binary: binutils-mipsen [i386] (eoan-proposed/universe) [4~c4ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- New: accepted binutils-mipsen [amd64] (eoan-proposed) [4~c4ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [amd64] (eoan-proposed) [1.37.0+dfsg1+llvm-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [armhf] (eoan-proposed) [1.37.0+dfsg1+llvm-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [ppc64el] (eoan-proposed) [1.37.0+dfsg1+llvm-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted binutils-mipsen [i386] (eoan-proposed) [4~c4ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [i386] (eoan-proposed) [1.37.0+dfsg1+llvm-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [arm64] (eoan-proposed) [1.37.0+dfsg1+llvm-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted rustc [s390x] (eoan-proposed) [1.37.0+dfsg1+llvm-1ubuntu1]
<vorlon> Laney, juliank: https://code.launchpad.net/~ddstreet/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/369620
-queuebot:#ubuntu-release- Packageset: Added language-pack-gnome-szl to langpack in eoan
-queuebot:#ubuntu-release- Packageset: Added language-pack-gnome-szl-base to langpack in eoan
-queuebot:#ubuntu-release- Packageset: Added language-pack-szl to langpack in eoan
<LocutusOfBorg> [14:38:46] <LocutusOfBorg> ruby-gnome can't migrate because of ruby-gnome2 old package, but ruby-gnome replaces ruby-gnome2...
<LocutusOfBorg> [14:39:02] <LocutusOfBorg> so removing src:ruby-gnome2 (transitional package) will make everybody happy
<LocutusOfBorg> [14:39:40] <LocutusOfBorg> is this possible?
<LocutusOfBorg> everyday I look at ruby-gnome sadness
<LocutusOfBorg> and everyday I forget why it doesn't build
<LocutusOfBorg> can any AA please fix it?
<vorlon> LocutusOfBorg: I thought seb128 said he was taking care of it
<vorlon> seb128: ^^ ping
<seb128> vorlon, LocutusOfBorg, ruby-gnome migrated
<seb128> https://launchpad.net/ubuntu/+source/ruby-gnome
<seb128> no?
<vorlon> seb128: right, seems so, so you were only taking care of migrating ruby-gnome and not removing the ruby-gnome2 source?
<seb128> vorlon, I was waiting for the migration to happen because it felt wrong to remove the binaries before that happened, they would have gone missing
<vorlon> ack
<seb128> doing now
<seb128> thx for the reminder, I just got busy with other things here and didn't though it was urgent
<vorlon> no urgency for me :)
<LocutusOfBorg> yes, thanks! I admit I didn't check ruby-gnome, I had a tab open in my browser, with a build failure log of gnome2
<LocutusOfBorg> thanks for fixing it twice then
<seb128> LocutusOfBorg, vorlon, old name removed
<LocutusOfBorg> do you think we can kick out unanimity, because of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939506 and see a transition finish?
<ubot5> Debian bug 939506 in src:unanimity "unanimity ftbfs in unstable" [Serious,Open]
<LocutusOfBorg> second question, is it possible to cleanup NBS-proposed django-ajax-selects package?
<LocutusOfBorg> seb128, I also can't find references of your command on https://launchpad.net/ubuntu/+source/ruby-gnome2 page... does it take some more time?
<seb128> LocutusOfBorg, https://launchpad.net/ubuntu/+source/ruby-gnome2/+publishinghistory
<seb128> see the top entry
<LocutusOfBorg> Deleted 32 seconds ago by Sebastien Bacher
<LocutusOfBorg> yes, so I just didn't wait too much :)
<LocutusOfBorg> thanks!
<seb128> np!
<vorlon> LocutusOfBorg: removing unanimity has a knock-on effect of making pbgenomicconsensus build-deps unsatisfiable; I would not want to kick unanimity out to finish this transition before Debian had taken a decision that this is the right tradeoff
<LocutusOfBorg> oh, I missed it because I did only search for -b unanimity, instead of -b  python-consensuscore2
<LocutusOfBorg> makes sense, thanks
<LocutusOfBorg> in any case autoremoval already started...
<LocutusOfBorg> vorlon, I did upload a "little patch" for unanimity, if somebody has more c++ skill I think it can be fixed up, but I failed to parse the syntax of the failure
<vorlon> fwiw -b src:unanimity
<LocutusOfBorg> I stopped doing src:foo because sometimes it fails, but I don't remember when...
<vorlon> also fwiw once it does get autoremoved it would show up on the new report https://people.canonical.com/~ubuntu-archive/proposed-migration/eoan/rcbuggy-problem-packages.html (h/t mwhudson)
<LocutusOfBorg> I wasn't aware of such awesome page
<LocutusOfBorg> thanks
<vorlon> it's recent and not yet publicized
<vorlon> mwhudson: ^^ do you want to announce that to ubuntu-release@lists?
<LocutusOfBorg> doko, I'm trying to fix it up once more your gtk-d transition (ldc), but I think we should at some point kick armhf binaries out, same failure in Debian apparently?
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (bionic-proposed/main) [5.3.0-12.13~18.04.2] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [ppc64el] (bionic-proposed/main) [5.3.0-12.13~18.04.2] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [arm64] (bionic-proposed/main) [5.3.0-12.13~18.04.2] (kernel)
<LocutusOfBorg> rapmap is now an amd64 only package... reverse-dependencies are amd64only too...
<LocutusOfBorg> NBS cleanup please?
<vorlon> Laney, juliank: is ./worker-config-production/worker-bos01.conf redundant obsoleted by worker-config-production/worker-bos01-ppc64el.conf and should be removed?
<vorlon> LocutusOfBorg: done
<Laney> think so
<Laney> it's all obsolete in the new world order though
<Laney> so don't sweat too much over it
<LocutusOfBorg> thanks
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (bionic-proposed) [5.3.0-12.13~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [ppc64el] (bionic-proposed) [5.3.0-12.13~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [arm64] (bionic-proposed) [5.3.0-12.13~18.04.2]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-65.74~16.04.1]
-queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-65.74~16.04.1]
-queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (xenial-proposed/main) [4.15.0-1060.65] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (xenial-proposed/main) [4.15.0-1026.29~16.04.1] (kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (disco-proposed/main) [5.0.0-1018.18] (core, kernel)
-queuebot:#ubuntu-release- New binary: linux-signed-oracle [amd64] (disco-proposed/main) [5.0.0-1003.4] (core)
-queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (disco-proposed) [5.0.0-1018.18]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (disco-proposed) [5.0.0-1003.4]
-queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (xenial-proposed) [4.15.0-1060.65]
-queuebot:#ubuntu-release- New: accepted linux-signed-oracle [amd64] (xenial-proposed) [4.15.0-1026.29~16.04.1]
#ubuntu-release 2019-09-20
<mwhudson> vorlon: yes i guess i shuld
<mwhudson> vorlon: did you deploy the latest change to https://people.canonical.com/~ubuntu-archive/proposed-migration/eoan/rcbuggy-problem-packages.html ?
<doko> cjwatson: https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg  I demoted doxygen yesterday, and the -doc package wants to pull it again into main. Now I can add an extra exclude, but I'm wondering how many other packages like that do we have in main ...
<cjwatson> I don't know, sorry, somebody else will have to investigate
<doko> ok
<vorlon> mwhudson: I had not deployed the latest changes; done now
<mwhudson> vorlon: good that means i don't have to debug why they weren't working
<vorlon> doko: fwiw I did check that there are a number of packages that declare Built-Using: doxygen, but it seems none in main (Built-Using would be a way that things might get non-obviously pulled into main by germinate)
<RAOF> Oh, I should probably add Built-Using: doxygen to the mir packaging!
<mdeslaur> could someone please release python-django, the remaining autopkgtest failures are caused by broken tests
<vorlon> RAOF: why?
<RAOF> vorlon: The mir-doc package is doxygen-built, and probably therefore includes bits of doxygen.
<vorlon> hmm
<vorlon> and are there licensing or security reasons to need to track which version of doxygen it is embedding bits from?
<RAOF> Hm. mir-doc appears to embed a jquery, that would have to have come from the doxygen package? That's maybe a plausable target for security tracking?
<RAOF> It is not obvious to me whether or not we need to track it for licencing reasons.
<marcustomlinson> vorlon: could I ask you to please remove libreoffice and libreoffice-l10n 1:6.2.7-0ubuntu0.19.04.1 from the Disco unapproved queue
<marcustomlinson> oh right, tjaalton ^
<tjaalton> marcustomlinson: sure
<marcustomlinson> thanks
<tjaalton> done
-queuebot:#ubuntu-release- Unapproved: rejected libreoffice-l10n [source] (disco-proposed) [1:6.2.7-0ubuntu0.19.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected libreoffice [source] (disco-proposed) [1:6.2.7-0ubuntu0.19.04.1]
-queuebot:#ubuntu-release- Unapproved: v4l2loopback (bionic-proposed/universe) [0.10.0-1ubuntu1.1 => 0.10.0-1ubuntu1.2] (no packageset)
<doko> sforshee, apw: again re-introduced :-(  linux: Depends: libbinutils (>= 2.32.51.20190905), libbinutils (<< 2.32.51.20190906)
<doko> linux-tools-5.3.0-10
<doko> and -12
<LocutusOfBorg> vorlon, FYI I tried to fix bzr sadness, but the testsuite depends on python packages e.g. meliae you removed some time ago already from eoan
<LocutusOfBorg> I think the best solution *might* be to land this bileto https://bileto.ubuntu.com/#/ticket/3810
<LocutusOfBorg> but for sure I need an ack, I can open a bug later
<LocutusOfBorg> (bug opened)
-queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1045.47] (kernel)
<LocutusOfBorg> anybody please bump this hint to 0.7.9? ./ubuntu-release:force-badtest reprotest/0.7.8/i386
<LocutusOfBorg> xnox, was the installer meant to point at kernel -12? https://launchpad.net/ubuntu/+source/debian-installer/20101020ubuntu587
<vorlon> LocutusOfBorg: I don't understand your bzr changelog, how did test removal breakn the reverse-deps?
<vorlon> Laney, juliank: '/var/lib/dpkg/info/bacula-sd.postinst: 20: cannot create /tmp/bacula-sd.conf.ucftmp-evOGJc5OsD: Permission denied' is a surprising error (http://autopkgtest.ubuntu.com/packages/b/bacula/eoan/amd64)
#ubuntu-release 2019-09-21
<LocutusOfBorg> vorlon, test removals means, the bzr test package "python-bzrlib.tests"
<LocutusOfBorg> vorlon, why did you sync breezy? :)
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/1844827
<ubot5> Launchpad bug 1844827 in bzr (Ubuntu) "[Ffe] bzr" [Undecided,New]
<LocutusOfBorg> it was part of this bileto...
<LocutusOfBorg> it needs a transition...
<LocutusOfBorg> anybody please bump this hint to 0.7.9? ./ubuntu-release:force-badtest reprotest/0.7.8/i386
<LocutusOfBorg> I think we should hint this test on i386 http://autopkgtest.ubuntu.com/packages/p/python-meshio/eoan/i386 lowering the threshold just to fix i386 precision issues, makes the whole testsuite worse...
<LocutusOfBorg> the assert is about 0,000007112 < 0,000003128
<xnox> LocutusOfBorg:  yes, i know, made a typpo =)
<xnox> LocutusOfBorg:  i think new one is up now
<LocutusOfBorg> :-)
<LocutusOfBorg> xnox, looks like amd64 is still sad
<xnox> argh
-queuebot:#ubuntu-release- Unapproved: csh (disco-proposed/universe) [20110502-4 => 20110502-4ubuntu0.19.04.1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: csh (bionic-proposed/universe) [20110502-3 => 20110502-3ubuntu0.18.04.1] (no packageset)
<vorlon> LocutusOfBorg: breezy> because the breezy autopkgtests regressed due to removal of python-meliae were showing up elsewhere, and the changes to the package don't appear to require an FFe.  Why would I not sync it?
#ubuntu-release 2019-09-22
<LocutusOfBorg> vorlon, (please note, I still try to learn, this is not a complain, because I find difficult to know the line from ffe or not), "Provides: bzr, bzr-stats, bzr-email, bzr-upload, bzr-git, bzr-fastimport"
<LocutusOfBorg> this is in the diff, basically breezy is trying to replace bzr and everything else, that now are just transitional and dummy packages
<LocutusOfBorg> can you please than ack the Ffe so we can finish that? I don't know if the provides wins over a real package, but we should probably sync them all?
<mapreri> Can I get a SRU member to look at LP: #1841619 ?  /cc infinity
<ubot5> Launchpad bug 1841619 in dehydrated (Ubuntu Disco) "dehydrated: Missing ID field for new registrations" [High,In progress] https://launchpad.net/bugs/1841619
 * mapreri is sad that the SRU procedure now requires manual pinging to specific peopleâ¦
<rbasak> mapreri: people do process the queue on a rota, but many of us were sprinting last week so were unavailable
<mapreri> rota â rotation?
<rbasak> Right
<mapreri> I seeâ¦  but I uploaded exactly two weeks ago, so I assumed I missed all rotations of the week before as well :(
<rbasak> I try to process in FIFO order but don't always get to everything.
<mapreri> ack
<vorlon> LocutusOfBorg: the Provides: don't force the other real packages out of the archive; unless they're actually incompatible with the original implementations (in that case, the Provides: are wrong in both Debian and Ubuntu), I don't think this is a problem on its own
<vorlon> LocutusOfBorg: can you link me to the FFe in question?
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/1844827
<ubot5> Launchpad bug 1844827 in bzr (Ubuntu) "[Ffe] bzr" [Undecided,New]
-queuebot:#ubuntu-release- New source: virtualbox-ext-pack (eoan-proposed/primary) [6.0.12-2~build1]
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (xenial-proposed/multiverse) [5.1.38-0ubuntu1.16.04.1 => 5.1.38-0ubuntu1.16.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (bionic-proposed/multiverse) [5.2.32-1~ubuntu18.04.1 => 5.2.32-1~ubuntu18.04.2] (no packageset)
-queuebot:#ubuntu-release- Unapproved: virtualbox-ext-pack (disco-proposed/multiverse) [6.0.6-1 => 6.0.6-1ubuntu1.19.04.1] (no packageset)
